TL;DR
- 権限が不明瞭なままだと承認遅延・責任回避・インシデント拡大を招く。
- 変更種別 × 役割の二次元マトリクスで「誰が何を承認するか」を一覧化する。
- 例外運用は期限付きで記録し、事後レビューで再発防止へ接続する。
はじめに
AIエージェントがコードを書き、PRを出し、デプロイまで自動化される時代。便利な反面、「この変更は誰が最終承認するのか」「AIが出した結果の責任は誰が取るのか」が曖昧なまま運用されているチームは少なくありません。
権限設計が曖昧な組織では、以下のような問題が繰り返し起こります。
- 承認遅延: 誰に聞けばいいかわからず、意思決定がたらい回しになる
- 責任回避: インシデント発生時に「自分の管轄外」と全員が主張する
- 過剰権限: AIエージェントに広すぎる権限を与え、意図しない変更が本番に到達する
本記事では、親記事で示した統治全体像のうち「権限設計」にフォーカスし、実装可能なレベルまで具体化します。
権限マトリクスの基本構造
二次元マトリクスの設計方法
権限マトリクスは、縦軸に変更種別、**横軸に役割（ロール）**を置き、各セルに承認可否を定義するシンプルなフレームワークです。
| 変更種別 | AIエージェント | 開発者 | テックリード | PO/PM |
|---|---|---|---|---|
| ドキュメント修正 | 自律実行可 | 承認不要 | — | — |
| テストコード追加 | 自律実行可 | セルフ承認 | — | — |
| 非本番コード変更 | ドラフトのみ | セルフ承認 | 通知のみ | — |
| 本番コード変更 | ドラフトのみ | レビュー必須 | 承認必須 | 通知 |
| インフラ変更 | 実行不可 | 起案のみ | レビュー必須 | 承認必須 |
| データスキーマ変更 | 実行不可 | 起案のみ | 二重承認 | 承認必須 |
このマトリクスの要点は3つです。
- AIエージェントの自律範囲を限定する — 影響度が低い変更のみ自律実行を許可し、本番影響がある変更はドラフト止まりにする
- 承認者を一意に決める — 「テックリードが承認」のように責任者を明確化し、たらい回しを防ぐ
- 段階的に権限を強化する — 初期は厳しめに設定し、実績に応じて緩和する
MCPを使ったツール権限の制御方法について、より技術的な実装を知りたい場合はこちらも参照してください。
マトリクス運用のアンチパターン
権限マトリクスを作っても、以下のパターンに陥ると形骸化します。
- 全部「承認必須」にする: 承認がボトルネックとなり、速度が出ない。結果としてルールを迂回する文化が生まれる
- マトリクスを更新しない: チーム構成や技術スタックが変わっても権限表が放置され、現実と乖離する
- 口頭で例外を許す: 記録のない例外が積み重なり、監査不能になる
ガードレール設計の実践
権限マトリクスを「絵に描いた餅」にしないために、技術的なガードレールとセットで運用します。
最低限の3つのガードレール
| ガードレール | 目的 | 実装例 |
|---|---|---|
| 本番影響変更は人間承認必須 | 重大インシデントの防止 | GitHub Branch Protection + CODEOWNERS |
| データ破壊リスクは二重承認 | 不可逆操作の安全弁 | PR に2名以上の Approve を要求 |
| 監査ログの自動保存 | 事後検証・コンプライアンス | CI/CD パイプラインにログ出力ステップを組み込む |
これらのガードレールは、権限マトリクスの「承認必須」「二重承認」を技術的に強制する仕組みです。ルールが存在しても、ツール側で制御しなければ人的ミスで突破されます。
エスカレーション条件の設計と合わせて運用すると、「AIが判断に迷ったら止まる」仕組みも整います。
👉 人間へのエスカレーション設計：AIエージェントに「止まる勇気」を持たせる条件
ガードレール導入の優先順位
すべてを一度に導入するのは現実的ではありません。以下の順序で段階的に導入することを推奨します。
- Branch Protection の有効化（即日対応可能）
- CODEOWNERS ファイルの設定（1日以内）
- 監査ログの自動保存（CI/CD パイプライン改修、1週間目安）
- 二重承認ルールの運用開始（チーム合意後）
例外運用のルール化
なぜ例外運用が必要か
緊急障害対応やセキュリティパッチなど、通常の承認フローを待てないケースは必ず発生します。「例外を禁止する」のではなく、「例外を安全に許可する仕組み」を設計することが重要です。
例外運用の3原則
例外対応は以下の3つの原則で管理します。
- 期限付き許可: 例外権限は最大72時間とし、自動失効させる
- 記録の義務化: 誰が、いつ、なぜ例外を行使したかをチケットに記録する
- 事後レビュー必須: 例外行使後48時間以内にポストモーテムを実施し、再発防止策を検討する
このサイクルを回すことで、例外対応が「闇ルール」ではなく「追跡可能な運用」になります。
リリース判断基準との連携については、兄弟記事で詳しく解説しています。
👉 リスクベースリリース運用：AI生成変更を安全にマージする基準
権限設計の効果を測る
権限マトリクスを導入したら、その効果を定量的に把握することが重要です。以下の指標を週次で確認します。
- 承認リードタイム: PR作成から承認完了までの平均時間（目標: 4時間以内）
- 例外行使件数: 月あたりの例外対応件数（減少傾向が健全）
- 権限違反検知数: ガードレールが防いだ unauthorized な操作の件数
これらのKPI設計と学習ループの全体像は、こちらの記事で体系的に整理しています。
まとめ：権限設計はAI活用の速度と安全性を守る土台
権限マトリクスとガードレールは、AIエージェント活用の「アクセル」と「ブレーキ」の両方を担います。
今日から始められる3ステップ:
- 変更種別 × 役割の権限マトリクスを作成する
- Branch Protection と CODEOWNERS で技術的にガードレールを敷く
- 例外運用の3原則（期限・記録・事後レビュー）をチームで合意する
権限設計は一度作って終わりではなく、チームの成長とAIエージェントの能力向上に合わせて継続的にアップデートしていくものです。
全体像に戻る: AIエージェント開発のデリバリー統治（親記事）
