## アクセス制御 (RBAC)

「誰が何を実行できるか」を、実装可能でテスト可能、監査可能な権限モデルに変換し、権限があいまいな一文に劣化し、実装が一貫しなくなるのを防ぎます。

適用シナリオ:
- マルチロールシステム (運用/レビューア/財務/コンプライアンス/管理者/外部コラボレーター)
- 権限がページ領域/ボタン、API、および操作/アクションレベルに到達する必要がある場合

コアコンセプト:
- ロール (Role): 権限のバンドル (例: 配車担当者、ドライバー、財務、管理者)
- 権限キー (Permission key): 最小の付与可能なアクション (例: `order:approve`、`dispatch:revoke`)
- リソース (Resource): 権限が適用される対象 (ページ、API、機能、メニュー、データエンティティ)
- アクション (Action): リソースに対する操作 (read/create/update/delete/approve/export)

RBACテーブル形式 (各機能の `rbac.md` に直接記述することを推奨):

ロールテーブル:
| ロール | 責任 / 境界 | 一般的な操作 | 備考 |
|---|---|---|---|
| Admin | ... | ... | ... |

権限キーテーブル (フロントエンドとバックエンドの単一の信頼できる情報源):
| 権限キー | 名前 | リソースタイプ | リソースパス | アクション | 説明 | 関連API | UIコントロールポイント |
|---|---|---|---|---|---|---|---|
| order:approve | 注文の承認 | Page/Button | /orders/{id}#approve | approve | ... | POST /api/orders/{id}/approve | 注文詳細 - 承認ボタン |

ロールと権限のマトリックス (許可 / 拒否 / 条件付き):
| 権限キー | Admin | Reviewer | Operator | 条件 (例: データスコープ / ステータス) |
|---|---|---|---|---|
| order:approve | 許可 | 許可 | 拒否 | ステータスが保留中の場合のみ。組織スコープのデータのみ |

実装の提案:
- エンドツーエンドで権限キーを使用する: UIのゲーティングとバックエンドの承認は、同じ権限キーを共有する必要があります。「フロントエンドでのみ非表示」または「バックエンドでのみエラー」に依存しないでください。
- 権限をシナリオ/ケースにバインドする: シナリオでトリガーするロールをマークします。受け入れテストケースは、許可/拒否のコピーと、権限がない場合のデフォルトのランディングページをカバーする必要があります。
- デフォルトで拒否: マトリックスで明示的に許可されていないものはすべて拒否され、一貫したエラーコードとメッセージが表示されます。
- 条件付きは実行可能である必要があります: 条件を実装可能なフィールド (データスコープ、組織/テナント、ステータス、所有権、タイムウィンドウ) として表現し、フリーテキストとしては表現しないでください。