AIエージェントのガバナンス実装
―― MCP / A2A / Skillsで"観察と介入"を設計する
ガバナンスは規則を書くことではない。執行される仕組みを設計することだ。 人間組織に成立してきたその論理は、AIエージェントを前にして根本的な再設計を要求している。
- 執行 ＝ 観察（ログ/トレース）＋ 介入（停止/承認/権限制御）：ルールを書くだけでは執行できない。
- MCP＝ツール実行の統制点、A2A＝委任の統制点、Agent Skills＝権限境界：三標準は「執行の神経系」として機能する。
- ツール数・ステップ数の上限は普遍定数ではない：τ-bench等のベンチマーク＋社内回帰テストで、使用モデルごとに決定・更新する。
導入：なぜ「AIガバナンス」は執行できないのか
2024年以降、「AIガバナンス」という言葉が急速に普及した。企業はAI利用ポリシーを策定し、欧州ではAI Act（EU AI規制法）が成立し、各国の規制当局がガイドラインを相次いで発行した。しかし現場に目を向けると、奇妙な事態が起きている。ルールは書かれているが、守られている保証がない。それ以前に「守られているかどうかを確認する手段」が存在しないケースが多い。
これは単なる運用の怠慢ではない。人間を対象として設計されてきたガバナンスの枠組みが、AI――とりわけ自律的に行動するAIエージェント――に対してそのまま適用できない、という構造的な問題である。
AIガバナンスの問題は「何を禁止するか」ではなく、「禁止したことが実際に執行されるか」にある。執行の仕組みがなければ、ガバナンスは単なる文書になる。そしてAIエージェントに対してその執行を行う技術的手段は、いまようやく標準化が始まったばかりである。
本稿は、AIガバナンスを「規則の設計」ではなく「執行力の設計」として論じる。具体的には、現在急速に標準化が進んでいるMCP（Model Context Protocol）・A2A（Agent-to-Agent Protocol）・Agent Skillsという三つの技術標準が、ガバナンス執行においてどのような役割を果たし得るのかを、実務的な設計論として展開する。
論じる前に、一つの直感的な類比を提示する。人間組織の管理論には「スパン・オブ・コントロール（管理限界）」という概念がある。一人の管理職が実効的に監督できる直属部下の数には、認知的上限がある。組織規模が大きくなると、非公式ネットワークだけでは統治できなくなり、階層的なルール体系と委任の仕組みが必要になる。AIエージェントにも、まったく同じ論理が、しかし異なるメカニズムによって適用される。そしてその「管理限界」を把握するための道具が、ベンチマークである。
02 · DEFINITIONS問題設定・用語定義 ―― 人間ガバナンスとの断絶点
ガバナンスの三層構造
ガバナンスは一般に、①規則の設定（Policy）、②観察・監視（Observability）、③介入・是正（Intervention）の三層で構成される。人間組織ではこれが、就業規則・管理報告・人事制度という形で実装される。この三層がすべて機能して初めてガバナンスが「執行される」。
現在の「AIガバナンス」の多くは①に集中しており、②③が著しく弱い。AIエージェントが何百ものAPIコールをバックグラウンドで実行している間、管理者は実質的に何も観察できていない。これが「執行できないガバナンス」の根本原因である。
AIエージェントの定義とガバナンス上の本質
ここで言うAIエージェントとは、LLM（大規模言語モデル）を推論エンジンとして、外部ツール・データ・他のエージェントと相互作用しながら、複数ステップにわたるタスクを自律的に遂行するシステムを指す。単なるQ&Aシステムや文章生成AIとは区別される。
ガバナンス上で重要なのは「副作用」の存在である。エージェントはメール送信、データベース更新、コード実行、外部APIの呼び出しといった不可逆的な副作用を持つ行動を取り得る。これを管理者が認識できない状態で連鎖的に実行されると、ガバナンス上の重大リスクが生じる。
あるSaaS企業が「CRMのデータを参照し、顧客向けレポートを生成してメールで送信する」AIエージェントを運用していた。エージェントはCRM検索・レポート生成・メール送信の3ツールにアクセスできた。
ある日、CRMのフィルタ条件がプロンプトの解釈ミスで緩み、エージェントは「全顧客」にテスト用レポートを2,400件送信した。送信は2分以内に完了しており、監視ダッシュボードを誰も確認していなかったため、人間が気づいたのは顧客からの問い合わせが届いてからだった。
根本原因：メール送信（不可逆・外部影響）に対してHuman-in-the-Loopが設定されておらず、ツール呼び出しログも事後参照しか想定されていなかった。ガバナンスの①規則は存在していたが、②観察と③介入が機能していなかった典型例である。
HUMAN GOVERNANCE
- 失敗の原因：意図的違反・判断ミス・情報不足
- 観察手段：報告書・会議・監査
- 是正手段：フィードバック・処分・研修
- 管理限界：認知・時間に起因する上限
- 責任主体：個人に帰属可能（法的責任あり）
AI AGENT GOVERNANCE
- 失敗の原因：確率的誤推論・ハルシネーション
- 観察手段：ログ・トレース・スパン（未整備が多い）
- 是正手段：ツール制限・Guard Rails※・停止
- 管理限界：ツール数・ステップ数・委任深度
- 責任主体：開発者・運用者・利用者に分散（曖昧）
※ Guard Rails（ガードレール）：入力・ツール・出力を制約する安全装置の総称。プロンプトフィルタリング、ツールアクセス制御、出力検査などが含まれる。
AIへのガバナンス執行は「事後の懲罰」ではなく、「事前の設計制約」＋「リアルタイムの監視・停止」の組み合わせで成立する。この非対称性を理解していない組織は、規則を書いても執行できない。
背景構造：MCP・A2A・Agent Skillsと、ガバナンスへの接続
2024年末から2025年にかけて、AIエージェントの相互運用性を実現するための標準プロトコルが整備されてきた。これらは単なる技術仕様ではなく、ガバナンス執行の「神経系」として機能し得る。各プロトコルがガバナンスにどう関係するかを順に論じる。
MCP（Model Context Protocol）― ツールアクセスの集中管理点
MCP = LLMが外部ツールを呼ぶための「共通コネクタ規格」（= USB-Cのようなもの）。Anthropicが2024年11月に公開したオープンソースプロトコル。
MCP（Model Context Protocol）は、LLMと外部ツール・データソースを接続するための標準仕様である。それ以前、各AIシステムは独自のAPI連携を構築しており、「同じツールでもシステムによって接続方法が異なる」という断片化が生じていた。MCPはその標準化を目指す。
構造的にはJSON-RPC 2.0ベースのClient-Server通信で、Serverは「Resources（読み取り専用データ）」「Tools（副作用を伴う実行）」「Prompts（再利用テンプレート）」の三種を提供できる。
ガバナンスの観点から重要なのは、MCPがツールアクセスの集中管理ポイントを生み出す点である。すべてのツール呼び出しがMCPサーバーを経由するならば、そこにアクセス制御・ログ記録・監査機能を集約できる。これはガバナンスの「第②層（観察）」を技術的に支える基盤になり得る。
MCPを介さないツール呼び出し（独自API直接連携）が残存する限り、ガバナンスのブラインドスポットが生まれる。MCPへの移行は単なる技術標準化ではなく、可視化インフラの整備として位置づけるべきである。
A2A（Agent-to-Agent Protocol）― 委任連鎖の構造化
A2A = エージェント同士が依頼と結果をやりとりする「共通メッセージ規格」（= 業務委任の郵便ルール）。Googleが2025年4月に発表。
A2A（Agent-to-Agent Protocol）は、異なるエージェント間の相互通信を標準化するプロトコルである。MCPが「AIシステム→ツール」の接続を扱うのに対し、A2Aは「AIエージェント→別のAIエージェント」という委任の連鎖を定義する。
A2Aにおける重要な概念がAgent Cardである。各エージェントは自身の能力（スキル）、認証方式、エンドポイントを記述したAgent Cardを公開する。オーケストレーター（調整役）はこれを読み込んで、サブエージェントに適切なタスクを委任する。
（分析）
（コード生成）
（メール送信）
ガバナンス上のリスクは、この委任の連鎖が深くなると、監督者から何が行われているかが見えなくなる点にある。オーケストレーターが5つのサブエージェントに委任し、各サブエージェントが3つのツールを呼び出すと、最終アクション数は15になる。人間の組織でいえば、社長が5人の部長に指示を出し、部長が3人の部下に再委任した結果、現場で何が起きているかを社長が把握できなくなる状態に相当する。
Agent Skills ―― 能力の宣言的定義
Agent Skills = エージェントが「できること」を機械可読な形式で宣言する「職務記述書」（= 権限のホワイトリスト）。A2Aプロトコルの中核要素。
Agent Skillsの重要性は「能力の明示的な境界設定」にある。スキルとして宣言されていない行動はとれない設計にすることで、エージェントの行動範囲を構造的に制限できる。これはホワイトリスト型のアクセス制御と同じ論理だ――「できないことを列挙（ブラックリスト）」よりも「できることだけを宣言（ホワイトリスト）」する方が、ガバナンスとしてはるかに強固である。
注意すべきは、「プロンプトで禁止を伝える」方式との本質的な違いである。プロンプトによる制約は確率的な制約であり、LLMが解釈を誤れば迂回される。Agent Skillsのような構造的定義は、確率に依存しない「論理的な壁」として機能する。
| 標準 | 開発主体 | ガバナンス層への貢献 | 採用状況 |
|---|---|---|---|
| MCP | Anthropic | ②観察（ツールログの集中管理） ③介入（アクセス制御） |
実用段階 |
| A2A | ②観察（委任連鎖の可視化） ①規則（Agent Cardによる境界設定） |
普及途上 | |
| Agent Skills | A2A仕様内 | ①規則（ホワイトリスト型制限） ③介入（スキル外行動のブロック） |
普及途上 |
AIの能力限界を定量的に把握する ―― ベンチマーク論
ガバナンス設計において最も見落とされがちな問いが、「そのAIは何ができて、何ができないのか」の定量的把握である。人間組織の管理論で一人の管理職の部下数に経験的な上限が語られる背景には、認知科学と組織行動学の研究蓄積がある。AIエージェントの「管理限界」にも、同様の実証的根拠が必要だ。
「プロンプトでうまくいった」が証拠にならない理由
多くの組織が「テストで問題なかったので大丈夫」という判断をする。しかしこれは、分布外入力（Out-of-Distribution Input）への脆弱性を見落としている。開発者が想定した入力にしか対応できていない可能性を排除できない。
もう一つの問題は、LLMの性能がコンテキスト長・ツール数・推論ステップ数の増加に伴って非線形に劣化することである。「3ステップなら正確に動く」エージェントが「10ステップでは誤りを累積させる」という現象は広く報告されており、これを無視したガバナンス設計は根拠を持たない。
「AIの性能はコンテキスト中盤で低下し、長い文書の中央部分の情報を見落としやすい」――これを "Lost in the Middle" 問題と呼ぶ（Liu et al., 2023）。ガバナンス上の含意は明確だ：長い実行履歴（多ステップのタスク）は、エラーの蓄積リスクを高める。
ガバナンス設計に関連するベンチマーク群
「初期ガードレール」の数値とその位置づけ
AgentBench・GAIA・τ-benchの実験データから、現在の主要モデル（GPT-4oクラス、Claude 3.5/3.7クラス）で確認されている性能劣化パターンをもとに、以下を設計上の初期叩き台として提示する。これらは「普遍定数」ではない。
（10超で選択精度が劣化する傾向）
（エラー累積が増加）
（委任観察の実用上限）
ベンチマークで再評価
上記の数値は「現世代モデルでの経験的傾向から導いた初期ガードレールの叩き台」であり、モデル・タスク・ツールの組み合わせによって大幅に変わる。Claude 3.7 Sonnet の Extended Thinking（強化推論）など、内部ステップが外部から見えない設計のモデルでは、外観上のステップ数と内部処理の複雑さが乖離する。したがって、実際に使用するモデル×実際のタスクでの τ-bench 相当の社内回帰テストを実施し、その結果を根拠に上限値を設定するというプロセスが不可欠だ。「本稿の数字を固定値として使う」のではなく、「この問いを持って自社でテストする」という使い方が正しい。
ベンチマークの限界 ―― 何を測れていないか
グッドハートの法則――「測定値が目標になると、それはよい測定値でなくなる」――は、AIベンチマークにも適用される。①ベンチマーク汚染（訓練データへのリーク）、②分布外タスクへの汎化失敗、③「正解を出す能力」と「不確かなとき安全に停止する能力」の混同、④短時間タスクから長時間実行への外挿の不確実性、という四つの限界が知られている。特に③は、ガバナンス上重要である。高スコアのモデルが「停止すべき場面で自信過剰に前進する」ことは性能指標に現れにくいが、実害は大きい。
05 · FRAMEWORK & PRACTICE実践への落とし込み ―― 執行可能なガバナンス設計
判断基準：ガバナンス強度をどう決めるか
すべてのAIエージェントに同一のガバナンス水準を適用することは、過剰規制か過少規制のどちらかを必ず生む。ガバナンス強度は「タスクの副作用の不可逆性」と「エラーの影響範囲」の二軸で決定するのが基本的な判断基準である。
| 影響範囲：内部のみ | 影響範囲：外部に波及 | |
|---|---|---|
| 可逆的アクション | 低強度ガバナンス 例：内部データ読み取り、ドラフト生成 |
中強度ガバナンス 例：Webスクレイピング |
| 不可逆的アクション | 中強度ガバナンス 例：DBへの書き込み、内部メール |
高強度ガバナンス 例：外部API実行、顧客連絡、金融取引 |
PACEフレームワーク for AI Governance Execution
人間組織の管理論との対応関係
| 人間組織の原則 | 知見の根拠 | AIエージェントへの対応 | 根拠 |
|---|---|---|---|
| スパン・オブ・コントロール（認知的制約から発生） | 組織行動学の研究蓄積（枠組みのみ借用） | 直接管理サブエージェント上限の設定 | AgentBench実験・実装経験値で個別決定 |
| 規模拡大で非公式統治が限界に達する | 社会的ネットワーク研究 | 複数エージェント連携には構造的ガバナンスが必要 | 委任連鎖の観察不可能性 |
| 委任には説明責任と報告義務 | プリンシパル-エージェント理論 | A2Aの委任履歴記録・ログ義務 | EU AI Act Art.13, 14（透明性） |
| 不可逆的決定は上位承認を要する | 組織の意思決定権限設計 | 不可逆アクション前のHuman-in-the-Loop | NIST AI RMF「GOVERN 1.7」 |
| 能力評価なく権限付与しない | 採用・昇進の適性審査慣行 | デプロイ前のベンチマーク評価義務 | EU AI Act Art.9（リスク管理） |
人間組織との類比は「考え方の枠組みを借りる」ためのものであり、「人間の経験則の数字をそのままAIに当てはめる」ためのものではない。AIの管理限界はAI固有の実証評価（ベンチマーク＋社内回帰テスト）によって決定されなければならない。
チェックリスト：デプロイ前・運用中の確認事項
◆ 設計フェーズ（デプロイ前）
◆ 運用フェーズ（継続的モニタリング）
限界・注意点 ―― 万能解はなぜ存在しないか
技術標準の断片化問題
MCPはAnthropicが、A2AはGoogleが主導しており、MicrosoftはAIF（AI Foundry）とAutoGenを、OpenAIはAssistants APIを推進している。現時点では「すべてのエージェントがMCPとA2Aに準拠している」という状況は存在せず、各フレームワーク（LangChain・AutoGen・CrewAI等）の対応も進行中である。ガバナンスを技術標準に依存しようとすると、未対応領域でブラインドスポットが生まれる。
2025年時点で完全準拠のエコシステムは存在しない。ガバナンス設計は「技術標準の完成を待つ」ではなく、「現在の断片化を前提としたプロキシ層・ミドルウェア実装」と並行して進める必要がある。
「能力の上限」はモデルとともに動く
本稿で示した数値はガイドラインであり固定値ではない。Extended Thinking（強化推論）機能の登場は、外から見えるステップ数と内部処理の複雑さを乖離させる。これは「ガバナンス設計における能力評価はモデルアップデートのたびに再実施される継続的プロセス」であることを意味する。
責任の帰属問題
マルチエージェントシステムで問題が生じた際、責任はオーケストレーター設計者か、サブエージェントの開発者か、モデル提供者か、ガバナンス設計者か。EU AI Actはリスク分類と透明性義務を定めているが、マルチエージェント連携における責任分担は解釈の余地が大きく残る。実践的には「技術的なガバナンス実装」と「Human Accountable Ownerの指名」をセットで進めることが不可欠だ。技術が責任を自動的に生成することはない。
「守らせる」ことと「賢くある」ことのトレードオフ
ガバナンス制約を厳格にするほど、エージェントの自律性と柔軟性は制限される。これは根本的なトレードオフであり、ガバナンス強化と業務価値の均衡点はリスク許容度と業務要件によって決まる。「できるだけ制限する」も「できるだけ自律させる」も、それ自体では答えではない。適切な均衡点の設定こそが設計者の本質的な仕事である。
07 · CONCLUSIONまとめ：思考の軸
AIガバナンスの本質的課題は「何を禁止するか」ではなく「禁止したことをどう執行するか」にある。執行のためには、①規則の構造的実装（Agent Skillsによるホワイトリスト定義）、②観察インフラの整備（MCPによるツール呼び出しの集中ログ、A2Aによる委任履歴の可視化）、③能力限界の定量的把握（ベンチマークによる継続的評価）、④組織的な責任帰属（Human Accountable Ownerの指名）の四つが揃う必要がある。
管理限界を認識せずに委任の連鎖を深くすることは、組織でも、AIシステムでも、同じ構造的失敗を生む。設計の知恵は、能力の限界を直視しながら、その中で最大の価値を引き出す均衡を見つけることにある。
人間組織の管理論が蓄積してきた「委任と責任の構造」という知見は、AIエージェントの設計にそのまま適用はできないが、類比的思考の枠組みとして有効である。重要なのは、人間組織の論理をAIに「当てはめる」のではなく、AIのメカニズムの違いを正確に理解した上で「翻訳する」ことだ。そしてその翻訳の精度を担保するのが、ベンチマークによる実証的評価である。
技術標準（MCP・A2A・Agent Skills）は現在進行形で策定・更新されている。本稿で提示したフレームワークとガードレール数値は「今日の叩き台」として使い、使用するモデルとシステムの変化に合わせて継続的に更新することを強く推奨する。
