概念

三段階ロール権限（担当・責任者・管理者）

担当・責任者・管理者の3段階で権限を分け、判定をコード1か所に集約する権限設計

Kurage の業務システム群で共通して使われている権限モデル。利用者を 担当 / 責任者 / 管理者 の3つに分け、それぞれ「自分の分だけ」「部署分＋承認」「全社」という粒度の違う操作範囲を与える。

3つのロール

ロール	見える範囲	できること
担当	自分が持っている分だけ	自分の日報・架電・予定・タスクの入力と閲覧
責任者	自分の部署の分	部署メンバーの記録の閲覧＋承認（稟議・休暇届・経費精算など）
管理者	全社	アカウント管理・社員マスタ・設定変更・全データの閲覧

この3段階は kurage-vibe-groupware で明示されており、土台の kurage-vibe-groupware-core がユーザー認証（社員番号＋パスワード／Google Workspace／Microsoft 365）・アカウント管理・社員マスタ・共有スケジュールと併せて引き受ける。その上の業務アプリ（日報・点検記録など）は「定義ファイル1枚」を apps/ に置くだけで増やせるが、権限の判定だけは土台側の共通部分に残る。

設計の要点

判定はコードの1か所だけ

kvgwc の説明にある通り、権限判定のロジックはコードの1か所に集約される。アプリごとに if ($role === 'admin') を書き散らさない。これは self-contained-php-app の「全部読めるサイズ」という思想と表裏で、読むべき場所が1か所なら検証もできる。

ロールは「範囲」と「行為」に分解される

「責任者」は単に偉いのではなく、部署という範囲と承認という行為の組で定義される。範囲は所属（社員マスタ）から決まり、行為は approval-workflow の経路（決めた順番で承認に回す）と結びつく。フォームの項目と承認の経路は画面から決められるため、ロールは固定の列挙ではなく経路定義とセットで運用される。

経路とロールは別物

稟議書・休暇届・経費精算は「決めた順番で承認に回る」のであって、常に管理者が最終承認者とは限らない。ロールはあくまで「誰がその操作をしてよいか」の上限を定め、実際の順序は申請の種類ごとの経路が決める。

宣言した範囲の外は触れない

config-declared-scope と同じ発想で、担当は自分が持っている記録の外に出られない。kdbagent が「設定で宣言した表・列・操作だけを触らせ、宣言外はブラウザからもコマンドからも MCP 経由でも実行できない」とするのと同型で、できないことを設定とコードの両方で保証する。

使われている製品

kurage-vibe-groupware — グループウェア本体。3ロールを明示
kvgwc — 土台。認証・アカウント・社員マスタ・共有スケジュールを担当
kurage-teleapo-crm — 担当ごと・日ごと・リストごとの架電数・通話数・アポ数を集計する単位がロールの範囲と一致する
kurage-hr-post — 「職」を主語にするが、参照範囲はロールに従う
kurage-line-crm — 参照専用モードを別途用意し、送信のような取り消せない操作は既定で無効

なぜ3段階か

saas-subscription-replacement の文脈では、kintone やサイボウズのようなグループウェアの権限設定は細かく作れるが、中小企業が実際に使うのは「自分の分／部署の分／全部」の3段階にほぼ収まる。設定項目を増やさず、この3つに名前を与えたほうが運用が回る。

また three-tier-role-permission は tenant-isolation とは別の軸である。テナント分離が「会社Aと会社B」を分けるのに対し、こちらは1社の中で「誰が何を見てよいか」を分ける。kurage-memo のマルチユーザー（メモはユーザーごとに完全分離）は後者の最小形と見なせる。