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

> AIエージェントはタスク中に権限が変化するため静的なRBACだけでは機能しない。ABAC・ReBACとの組み合わせによる多層認可設計パターンと実装指針を解説する。

- Canonical: https://kuucorp.com/blog/agent-authorization-rbac-abac-rebac-design/
- Date: 2026-07-17
- Last modified: 2026-07-17
- Publisher: Kuu株式会社 (https://kuucorp.com)

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

本稿では [エージェントガバナンス](/glossary/agent-governance/) の実装で最初に突き当たる認可モデルの選定について、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エージェント運用管理サービス](/services/ai-ops/) ではポリシー設計と監査ログ基盤の初期構築を支援している。

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

## 参考

- [RBAC Is Not Enough for AI Agents: A Practical Authorization Model](https://tianpan.co/blog/2026-04-20-rbac-ai-agents-authorization)
- [RBAC vs ReBAC for AI Agents: Best Authorization Model](https://www.permit.io/blog/rbac-vs-rebac-for-ai-agents)
- [AI Agent 時代における認可技術の比較](https://zenn.dev/ishiguchi/articles/20250110-ai-agent-authorization-comparison)

## まとめ

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

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