AIエージェントの認可モデル設計——RBAC・ABAC・ReBAC 選択指針

マルチエージェント構成を本番展開した直後、コードレビューエージェントが本番データベースのレコードを削除していたことに気づく——これはロール設計の構造的失敗であり、RBAC 単体に頼った認可モデルが崩壊したときの典型的な症状だ。AIエージェントは「人間の代理」ではなく、タスク中に権限スコープが動的に変化する新しい主体であり、従来の認可モデルをそのまま適用できない。

本稿ではエージェントガバナンスの実装で最初に突き当たる認可モデルの選定について、RBAC・ABAC・ReBAC それぞれの技術的な役割と限界を整理し、実装可能な多層設計パターンを示す。

なぜRBACだけでは足りないのか

RBACはエージェントを「静的なロール」として扱うため、単一タスク中に読み取りから書き込みへ権限が変化するエージェントの実態と乖離する。

RBAC（Role-Based Access Control）は主体にロールを割り当て、そのロールが許可する操作セットを定義する方式だ。人間の組織構造とよく対応し、「閲覧者」「編集者」「管理者」のような階層で直感的に管理できる。しかしAIエージェントに適用すると3つの問題が発生する。

Confused Deputy 問題：エージェントはユーザーのOAuthトークンを継承し、フル権限で動作することが多い。プロンプトインジェクション攻撃が混入したとき、攻撃者の指示を受けたエージェントが「完全に認証されたコール」として悪意ある操作を実行する。

ロールスラッシング：エージェントの操作パターンは動的なので、静的なロール設計は「一巨大ロール」か「タスクごとのロール頻繁切替」に収束しやすい。前者はアクセス過剰、後者は監査ログの爆発と競合状態を生む。

タスクスコープの欠如：「PR 作成」サブタスク中のエージェントは /tmp 配下の読み書きで十分なはずだが、RBAC でこれを表現するにはタスクの組み合わせ分だけロール定義が必要になる。

RBACの問題を補う最初の手段はツールインターフェース自体に権限を埋め込むことだ。汎用の manage_github ツール1本を与えるより、open_pull_request / read_file / list_issues という3本の狭いツールに分け、デフォルトは読み取り専用、書き込みはタスクスコープ内でのみ許可して完了後に失効させる。

ABACで実行時の動的制御を加える

ABACは「今このエージェントが・この文脈で・このリソースに・この操作をして良いか」を属性の組み合わせで評価し、RBACでは表現できない動的制約を実現する。

ABAC（Attribute-Based Access Control）はアクセス要求の許否を、主体・リソース・環境の属性を組み合わせたポリシーで評価する。「誰が（principal）」だけでなく「何を（resource）」「どの状態で（context）」を同時に評価できる点がRBACとの根本的な違いだ。

AIエージェントに有効なABAC 制約の例：

評価軸	属性例	制約例
principal	エージェントID、タスクID	サブエージェントは親タスクのスコープ外を触れない
resource	データ分類（機密度）、テナントID	`CONFIDENTIAL` は同一テナントのみ
environment	リスクスコア、呼び出しチェーンの深さ	深さ3以上のサブエージェントは書き込み不可

OPA（Open Policy Agent）や Cerbos などのポリシーエンジンはこのABACポリシーをコードとして管理し実行時に評価する。「実行前の最終判断」のみを外部化する設計が重要で、全業務フローをポリシーエンジンに委ねようとするとポリシーが肥大化する。

``rego # OPA: エージェント書き込みの動的制御 allow { input.principal.type == "agent" input.action == "write" input.principal.task_depth <= 2 input.resource.tenant_id == input.principal.tenant_id input.context.risk_score < 0.7 }``

RBACとABACの役割分担は「RBACが構造的な外枠、ABACが動的な内枠」で機能させるのが現実的だ。コード生成エージェントは本番DBを削除できない（RBAC）、かつ現在のタスクコンテキストと一致するリソースのみアクセス可能（ABAC）という二重構造となる。

ReBACで委譲チェーンと所有関係を扱う

ReBACはエージェント→サブエージェント→ツール→リソースの委譲チェーンを関係グラフで表現し、RBACが苦手とするリソース単位の権限継承と委譲の深さ制限を実現する。

ReBAC（Relationship-Based Access Control）は Google の内部システム「Zanzibar」を起源とし、主体とリソースの関係性（owner・editor・viewer・delegated_agent 等）をグラフとして管理してアクセス判断を行う方式だ。OSSとしては OpenFGA・SpiceDB（Authzed）・Permify・Ory Keto がある。

マルチエージェント構成でReBACが特に有効な3場面：

委譲チェーンの深さ制限：(human) → (orchestrator) → (subagent_A) → (subagent_B) という4段委譲で、Bが元の人間から委譲された範囲を超えていないかを検証する。RBACのロールではこのチェーンを追跡できないが、ReBACの関係グラフは委譲の深さと範囲を自然に表現する。

リソース単位の権限継承：ドキュメント階層（プロジェクト→フォルダ→ファイル）で上位への権限が下位に継承されるモデルを表現できる。「このフォルダに invited された」という関係性が「配下ファイルの editor 権限を持つ」という結論を導く。

テナント境界の明示的検証：マルチテナント環境でエージェントが「テナントAのリソース」にアクセスできるのは、「テナントAの member である」という関係性があるときのみ、とポリシー式に明示するとクロステナントアクセスをアーキテクチャ的に防止できる。

ただし ReBAC は判断の事後説明が困難という弱点がある。監査ログには関係グラフの評価パスを記録する設計が必須になる。

3モデルの組み合わせ方——PDPを中心に置く

本番エージェント環境の認可基盤は「RBAC→ReBAC→ABAC」の3層で設計し、Policy Decision Point（PDP）をMCPゲートウェイ層に集中させることでblast radiusを最小化する。

3つの認可モデルは役割分担が明確で、以下のように使い分ける：

モデル	担当	評価タイミング
RBAC	エージェント種別×操作カテゴリの構造的境界	静的（デプロイ時定義）
ReBAC	委譲チェーン・テナント所属・リソース所有関係	半動的（関係グラフの更新時）
ABAC	実行時のリスク・文脈・数量制限などの動的制約	動的（リクエストごと）

PDPはエージェントがツールを呼ぶ前の認可チェックポイントとして機能し、MCPゲートウェイに統合することで、各MCPサーバーが個別に認可判断を持つ分散型設計より安全な構成になる。エージェントのIDトークン、タスクスコープ、リソースID、委譲チェーンをすべてPDPに渡し、3層のポリシーを順に評価する。

段階的な導入としては、まずRBACで操作カテゴリの境界を確立し（フェーズ1）、テナント・委譲関係が複雑化した段階でReBACを追加し（フェーズ2）、本番監視からリスクスコアが計算できる段階でABACの動的制約を加える（フェーズ3）という順序が現実的だ。

規模別の留意点（SMB / エンタープライズ）

中小企業（SMB）：初期はRBAC＋ツールレベルスコープで十分なケースが多い。エージェントが10本以下かつテナント境界が存在しない内部システムであれば、OPAを用いた軽量ABACで「タスクID・エージェント種別・リソース分類」の3属性をチェックするポリシーから始めるのが現実的だ。OpenFGAの導入は認可デバッグの経験を積んでから検討する。AIエージェント運用管理サービスではポリシー設計と監査ログ基盤の初期構築を支援している。

エンタープライズ：マルチテナント・複数チーム・組織横断のエージェント連携が前提となる環境では、3層（RBAC + ReBAC + ABAC）の同時設計が求められる。A2Aプロトコルで組織をまたいだサブエージェント委譲が発生する場合、委譲チェーンの深さ制限をReBACスキーマに明示し、PDPが各ゲートウェイで評価する構成が必要だ。監査証跡にはReBAC評価パスを含め、コンプライアンス監査に対応できる形で保存する。大規模展開の認可基盤設計は RDEサービスで対応している。

参考

まとめ

AIエージェントの認可設計で「どのモデルを選ぶか」への答えは「組み合わせて使う」だ。RBACが構造的な操作境界を設け、ReBACが委譲チェーンとリソース所有関係を検証し、ABACが実行時の動的制約を加える。3層のPDPをMCPゲートウェイに集中させることで、プロンプトインジェクション攻撃が混入しても blast radius を最小化できる。

認可基盤の設計から監査体制の構築まで、Kuuのエージェントガバナンス支援サービスにご相談ください。