Access control matrix

Purpose

権限が場当たりに増え、誰が何にアクセスできるか誰も把握できない状態を防ぐ。 ロール・リソース・操作を一枚の表に展開し、最小権限を一覧で検証できる状態にする。

Use When

• ロール（権限グループ）を設計・再編するとき
• RBAC / 行レベルセキュリティを整理するとき
• 「権限が複雑になりすぎた」と感じたとき
• auth-boundary-check の結果を体系的な表に落とすとき

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• ロール一覧: 想定する利用者の種別
• リソース一覧: 保護対象（テーブル・API・画面・機能）
• 操作: 読み取り / 作成 / 更新 / 削除 / 公開 等
• 業務ルール: 「この役割はここまで」という方針

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: マトリクス上で最も危ういセルはどこか
2. 根拠: その論点をそう判断した理由
3. アクセス制御マトリクス: ロール × リソース × 操作（許可/拒否/条件）
4. 含意: 権限構造が示す管理負荷・拡張性
5. 改善案: ロール統廃合・継承・条件付き権限の整理
6. 代替案: 別の権限モデル（属性ベース ABAC 等）
7. 判断材料: 権限確定に必要な人間の確認事項

Review Lens

• 目的妥当性: 各権限が業務上の必要性と一致するか
• 範囲の過不足: 過剰権限・権限不足のセルがないか
• 中長期リスク: ロール増殖で管理不能にならないか
• LAB全体との整合性: LMS / 自動化 / B2B 展開の権限要件と整合するか
• 非エンジニア理解可能性: マトリクスを関係者に説明できるか
• 他LLM移植耐性: 判断が特定認証製品の前提に依存していないか

Instructions

1. ロールとリソースを軸に取り、空のマトリクスを作る
2. 各セルを「許可 / 拒否 / 条件付き」で埋める
3. 条件付きセルは条件（所有者のみ・同一組織のみ等）を明示する
4. 過剰権限（業務に不要な許可）を洗い出す
5. ロールの統廃合・継承で簡潔にできないか検討する
6. 不明なルールは推測せず、確認事項として明示する

Guardrails

• 空欄を残さない（許可/拒否を明示する）
• 「管理者は全部許可」を無検証で置かない
• ロールを安易に増やさない（統廃合を優先）
• 権限確定の最終判断は人間に委ねる

LAB Cross-Check

観点	状態	備考
自動化フロー	—	自動化用アカウントの権限を最小化したか
データ / 認証 / ログ	—	行レベル権限・権限変更ログと整合するか
実装 / 運用フロー	—	権限付与・剥奪の運用手順があるか
非エンジニア理解可能性	—	マトリクスを関係者に説明できるか
会員共有 / 再利用耐性	—	マトリクス設計が他機能にも転用できるか
他LLM移植耐性	—	判断が特定認証製品に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。

• 要件: 確定したアクセス制御マトリクス
• 成功条件: 権限が想定通りに機能すると判断する基準
• 失敗条件: 権限の穴・過剰付与を検知する基準
• 実行範囲: 変更してよいロール・ポリシー定義
• 影響範囲: 権限変更が波及する機能・利用者
• ロールバック方針: 権限変更が問題を起こした場合の戻し方
• コスト比較: 権限モデルごとの実装・運用コスト

Further Reading

• auth-boundary-check skill — 個別の認証・認可境界の確認
• data-model-review skill — 行レベル権限を支えるデータ設計
• audit-log-design skill — 権限変更・アクセスの監査記録
• glossary.md — 手動境界等の用語定義