AIエージェントの権限管理が新市場に｜Arcade.dev資金調達から見るMCP/A2A時代の発注要件

結論：AIエージェント市場の次の主戦場は「認可」である

AIエージェントの導入テーマは、モデル性能やプロンプト設計だけではなくなっている。企業が本番導入で直面する本質的な問いは、AIがどの業務ツールを、誰の権限で、どこまで実行できるのかである。

2026年6月、Wall Street Journalは、AIエージェントの認可・実行制御に取り組むArcade.devが6,000万ドルを調達したと報じた。報道によれば、同社はAIエージェントが企業アプリケーション、データベース、ツールへ安全にアクセスするための認可技術を扱い、MCPやA2Aのような連携プロトコルとも関係する領域に取り組んでいる。

本記事では、Arcade.devの個別製品を推奨するのではない。重要なのは、この報道が示す市場の変化である。

これまでの企業AI導入は、「どのLLMを使うか」「RAGをどう作るか」「どの業務を自動化するか」が中心だった。これからは、AIエージェントが実際に業務システムを操作するため、認可、権限、監査ログ、承認、停止条件、MCP/A2A接続が発注要件になる。

MCP/A2Aで何が変わるのか

MCP公式ドキュメントでは、MCPはAIアプリケーションを外部システムへ接続するオープン標準であり、データソース、ツール、ワークフローへ接続して情報取得やタスク実行を可能にすると説明されている。つまりMCPは、AIが社内ファイル、DB、SaaS、検索、計算、業務APIへ触るための接続面である。

GoogleのA2A発表では、A2AはAIエージェント同士が安全に情報交換し、企業プラットフォームやアプリケーション上で協調して行動するためのオープンプロトコルとして説明されている。同発表では、A2Aがエンタープライズグレードの認証・認可をサポートする設計であることも述べられている。

整理すると、役割は次のようになる。

領域	役割	発注時に見るべきこと
MCP	AIエージェントと外部ツール・データの接続	ツールごとの権限、入力検証、ログ、承認
A2A	AIエージェント同士の連携	エージェントID、相手先認証、委任範囲、責任分界
認可基盤	AIが実行してよい操作を制御	実行時ポリシー、最小権限、監査、停止条件
監査ログ	後から説明できる証跡を残す	プロンプト、参照データ、ツール呼び出し、承認者

MCP/A2Aが広がるほど、AIは「回答するソフト」から「他のソフトを動かす実行主体」になる。そこで必要になるのが、AIエージェント専用の認可設計である。

Arcade.dev報道から読む市場のサイン

WSJ報道の重要点は、資金調達額そのものではない。AIエージェント導入のボトルネックが、モデルではなく認可とガバナンスに移りつつある点である。

報道では、Arcade.devがもともと診断AIエージェントを作ろうとしていたが、実運用ではAIに強い権限を渡せないという課題に直面し、認可技術へ軸足を移した経緯が紹介されている。これは中小・中堅企業にもそのまま当てはまる。

たとえば、次のような会話が現場で起きる。

現場の要望	実装上の壁
AIにCRMを見て営業メールを作らせたい	顧客情報、商談金額、担当者権限をどう制御するか
AIに請求書を確認させたい	会計データ、個人情報、支払先情報をどう扱うか
AIにチケットを起票させたい	自動起票、担当者変更、優先度変更の権限をどう分けるか
AIに社内DBを調査させたい	読み取り専用、更新禁止、クエリ制限をどう担保するか
複数エージェントを連携させたい	どのエージェントが誰に委任したかをどう追跡するか

この壁を越えない限り、AIエージェントはPoCで止まる。逆に、この壁を越えた企業から、AIを実業務に組み込める。

AIエージェント認可で分けるべき5層

AIエージェントの権限管理は、「アクセスできる/できない」だけでは粗すぎる。最低でも5層に分けて設計する。

1. エージェントID

まず、AIエージェントそのものを識別する。どのエージェントが、どの部署の、どの業務目的で、どの環境で動いているのかを台帳化する。

人間IDに紐づけて動かす場合も、エージェント固有の識別子、実行ログ、所有者、停止手順は必要である。

2. ユーザー委任

AIがユーザーの代わりに動く場合、どのユーザーの権限をどこまで委任するのかを決める。ユーザーが閲覧できるものをAIもすべて見てよい、という設計は危険である。

委任は、時間、業務、データ種別、操作種別で絞る。

3. ツール権限

AIが呼び出すツールごとに、読み取り、作成、更新、削除、送信、外部連携を分ける。MCPサーバーを作る場合も、ツール単位で実行可能な操作を明示する。

4. 実行時ポリシー

AIが実行しようとした瞬間に、ポリシーを評価する。たとえば「契約金額が一定以上なら人間承認」「個人情報を含む場合は外部送信禁止」「営業時間外の大量実行は禁止」のようなルールである。

ポリシー文書だけでは足りない。実行時に技術的に止められる必要がある。

5. 監査ログ

AIの入力、参照データ、ツール呼び出し、出力、承認者、エラー、停止理由を残す。特にA2Aのように複数エージェントが連携する場合、どのエージェントが誰に委任し、どの操作を実行したかを追える必要がある。

RFPに入れるべきAIエージェント権限管理要件

AIエージェント開発やMCP/A2A連携を外注する場合、RFPに「AIエージェントを作る」とだけ書くと、認可・ログ・承認が見積もりから漏れる。最低限、次の要件を入れる。

要件	RFPに書くべき内容
エージェント台帳	エージェント名、目的、所有者、実行環境、利用ID、接続先を一覧化する
非人間ID管理	サービスアカウント、APIキー、OAuthアプリ、MCPサーバーを人間IDと分けて管理する
ツール単位の権限	読み取り、作成、更新、削除、送信、外部連携を操作単位で分ける
委任制御	ユーザー権限をそのまま継承せず、業務・時間・データ・操作で制限する
実行時ポリシー	高リスク操作、個人情報、外部送信、大量実行を実行時に止める
人間承認	送信、削除、契約変更、決裁、顧客影響のある操作は承認フローを持つ
監査ログ	プロンプト、参照データ、ツール呼び出し、出力、承認者、停止理由を保存する
テスト	プロンプト注入、過剰権限、誤委任、外部送信、ログ欠落を受入テストに入れる
停止手順	エージェント単位、ツール単位、接続先単位で即時停止できる

この表がRFPに入っていない場合、AIエージェントは動いても、監査と統制が後回しになる。

ベンダー選定で見るべき質問

AIエージェント開発会社、MCPサーバー開発会社、SaaSベンダー、AI基盤ベンダーに対して、次の質問をする。

1. AIエージェントごとのIDを分けられるか
2. 人間ユーザーの権限をそのままAIへ渡さず、委任範囲を絞れるか
3. MCPツールごとに読み取り、更新、削除、送信を分けられるか
4. A2A連携時に、相手エージェントの身元と委任範囲を検証できるか
5. プロンプト注入や外部文書からの悪意ある指示を想定したテストを行うか
6. 実行時にポリシー違反を止められるか
7. 監査ログは人間の操作とAIの操作を分けて記録できるか
8. 顧客環境内で動かせるか、外部送信されるデータは何か
9. 事故時にエージェント、ツール、APIキーを即時停止できるか
10. 検収時に、権限・ログ・承認・停止条件を証跡付きで確認できるか

価格やモデル性能より先に、この10問へ答えられるかを見るべきである。

中小・中堅企業は何から始めるべきか

最初から専用の認可製品を導入する必要はない。まずは、AIエージェントを業務システムへ接続する前に、次の順番で整理する。

1. 接続先を3種類に分ける

区分	例	初期方針
低リスク	公開FAQ、社内規程、マニュアル	読み取り中心で開始
中リスク	CRM、チケット、見積、在庫	人間承認付きで開始
高リスク	会計、人事、契約、個人情報、削除操作	初期は自動実行しない

2. AIに許す操作を4段階に分ける

検索、要約、分類、下書きまでを第1段階にする。起票、通知、タグ付けを第2段階にし、更新、送信、削除、決裁は第3段階以降に回す。

3. 監査ログを先に決める

AIのログは後付けしにくい。PoCの段階から、プロンプト、参照データ、ツール呼び出し、出力、承認者を残す。

4. 最初の1業務で検証する

いきなり全社のMCP/A2A基盤を作らない。問い合わせ分類、見積依頼の一次整理、社内FAQ検索、チケット起票案など、低リスクで効果測定しやすい1業務から始める。

GXOが支援できること

GXOでは、AIエージェントの業務実装を、AI開発だけでなく、権限設計、MCP/API連携、監査ログ、承認フロー、RFP作成まで含めて整理する。

• AIエージェント導入前の権限棚卸し
• MCPサーバー/API連携の発注要件整理
• A2A/マルチエージェント連携のリスク整理
• RFPへの認可・監査・承認・停止条件の記載
• ベンダー比較時の質問表作成
• PoCから本番化への検収基準設計
• FDE+ ReadyによるAI導入前チェック

AIエージェントは「作れるか」より、「安全に業務へ接続できるか」で差がつく。Arcade.devの資金調達報道は、その市場が立ち上がり始めたサインとして読むべきである。

→ AIエージェント権限管理のRFPを相談する

→ FDE+ ReadyでAI導入前チェックを行う

まとめ

• AIエージェント市場の次の主戦場は、モデル性能ではなく認可、権限、監査、実行制御である。
• MCPはAIと外部ツール・データの接続、A2Aはエージェント同士の連携を扱う。どちらも発注時には認可とログが重要になる。
• AIエージェント開発のRFPには、エージェント台帳、非人間ID管理、ツール単位の権限、実行時ポリシー、人間承認、監査ログ、停止手順を入れる。
• ベンダー選定では、価格やモデル性能より先に、AIが何を実行でき、どこで止められ、後から説明できるかを確認する。
• 中小・中堅企業は、低リスクな1業務から始め、MCP/A2Aの前に接続先、操作権限、ログ、承認を整理すべきである。

関連記事

• AIエージェント時代のゼロトラスト｜ユーザーではなくエージェントが最弱リンクになる
• AIエージェント導入前に確認すべきMCP・ツール権限の設計
• AIエージェント導入はPoCから業務実装へ｜最初の1業務を選ぶ7つの基準
• Microsoft 365 CopilotのSearchLeak報道から考える｜社内AI導入前に確認すべき権限棚卸し
• MCPで社内システムをAIエージェントに繋ぐ

参考資料

• Wall Street Journal「Arcade.dev Raises $60 Million to Secure AI Agents」 https://www.wsj.com/cio-journal/arcade-dev-raises-60-million-to-secure-ai-agents-5d07eff4

• Model Context Protocol公式ドキュメント「What is the Model Context Protocol?」 https://modelcontextprotocol.io/docs/getting-started/intro

• Google Developers Blog「Announcing the Agent2Agent Protocol (A2A)」 https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

• arXiv「AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A」 https://arxiv.org/abs/2603.24775

AIエージェントを業務システムへ接続する前に、RFPへ認可・監査・承認・停止条件を入れませんか。

AIエージェント権限管理のRFPを相談する

FDE+ ReadyでAI導入前チェックを行う