これまでAIエージェントは「人が指示し、ツールを叩く」存在だった。ところが2026年8月、その前提が静かに更新された。エージェントが、別のエージェントに仕事を委任できる機能が、企業がすでに使っているプラットフォームの標準機能としてGA（一般提供）に進み始めたのだ。Microsoft 365 Copilotの「連携エージェント（connected agents）」、そしてGoogleのGemini EnterpriseにおけるA2Aエージェント管理——いずれも、エージェントが単独で完結するのではなく、別のベンダー・別のチームが作ったエージェントに仕事を振ることを前提にした更新である。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業のAI導入を「PoCから本番・全社へ」日々支援している。その現場感からすると、この連携GAは待望であると同時に、新しい統制課題の号砲でもある。エージェントが同僚を呼べるようになると、「誰が・誰に・どこまで任せてよいか」という問いが一気に前景化するからだ。本稿では何がGAになったのかを一次情報で確認し、そこで開く「委任の統制」の空白を整理する。
何がGAになったのか——「エージェントが同僚を呼ぶ」が製品既定に
今回の動きの中心にあるのは、エージェント同士をつなぐ相互運用プロトコル A2A（Agent2Agent） だ。A2AはGoogleが2025年に公開し、同年 Linux Foundation に寄贈されて中立の標準として運営されている。2026年には安定版（v1系）に到達し、1周年時点で150を超える組織が支持、Microsoft・AWS・Salesforce・SAP・ServiceNowなどが本番運用に採用している。A2Aが「エージェント同士が発見し、仕事を委任し合う」共通言語として広く定着したことが、今回の製品GAの前提になっている。
その標準が、企業の日常ツールに実装され始めた。
- Microsoft 365 Copilotの「連携エージェント」: Agent 365 に公開したエージェントを、Microsoft 365 Copilot Chat の中から他のエージェントが呼び出す「連携エージェント」として使える機能が、2026年8月にGAへ向けて順次展開されている。ここで条件になっているのがA2Aプロトコルの実装だ——連携エージェントとして呼ばれるには、A2Aで「自分に何ができるか」を公開し、タスクを受け取れる必要がある。
- Gemini Enterprise の A2A/A2UI 管理: Googleは Gemini Enterprise で、A2A（および画面連携のA2UI v0.9）を用いたエージェントの登録・管理をGAにした。管理者は外部・社内のA2Aエージェントを一元的に登録し、Gemini Enterprise 内で使わせられる。
A2AとMCP（Model Context Protocol）は競合ではなく補完関係にある。MCPは「エージェント↔ツール／データ」をつなぐ縦の接続、A2Aは「エージェント↔エージェント」をつなぐ横の連携だ。仕組み（エージェントカード＝/.well-known/agent.jsonでの能力公開、タスク単位の委任）を詳しく知りたい方は、A2Aの基礎解説記事を参照してほしい。本稿はその「次」——GAで現実になった委任を、どう統べるかに絞る。
要するに、これまで「概念」「開発者向けSDK」の段階にあったエージェント間連携が、2026年8月に情報システム部門が管理するプラットフォームの標準機能へと降りてきた。ここからが本題だ。
「つなぐ」と「任せてよい」は別問題——委任グラフという新しい統制面
エージェントAがエージェントBに仕事を委任し、Bがさらに外部のエージェントCを呼ぶ——連携が当たり前になると、業務は単発のツール呼び出しではなく、**エージェントからエージェントへ枝分かれしていく“委任の連鎖（委任グラフ）”**になる。ここで統制の問いが根本的に変わる。
これまでのAIエージェント統制は、主に「エージェント↔ツール」の一点（MCPゲートウェイなど）を関所にすればよかった。だが委任グラフでは、関所の外で、エージェント同士が勝手に仕事を回し合う。しかも相手は自社が作ったとは限らない。研究者はこの構図を端的にこう指摘する——
自社の統制境界（ガバナンス・ペリメータ）の内側で動くエージェントが、境界の外側で動く外部エージェントにタスクを委任し得る。そして、そこで何が伝えられ、何が認可されたのかの監査記録が残らないことがある。（Governance Gaps in Agent Interoperability Protocols, arXiv:2606.31498）
つまり、A2Aが「つなぐ」を解決した一方で、「その委任は許されているのか」「何を渡したのか」「どこまで代理していいのか」を記録し統べる仕組みは、プロトコルの外に置き去りにされている。ツール接続の統制を固めた企業でも、委任グラフの統制はほぼ手つかず、という状態になりやすい。
最も危ういのは越境委任だ。社内の承認・監査を通ったエージェントであっても、そのエージェントが外部のエージェントへ一部の仕事を委任した瞬間、統制境界の外に出る。人間の組織なら「外注に再委託する際の情報持ち出し」に相当する行為が、エージェント同士ではミリ秒単位で、承認も記録もなく起こり得る。
プロトコルは「能力」を語り、「権限」を語らない
なぜこの空白が生まれるのか。答えはシンプルで、A2AもMCPも、そもそも企業統制のレイヤーを名乗っていないからだ。A2Aのエージェントカードが宣言するのは「このエージェントに何ができるか（能力）」であって、「このエージェントに何を任せてよいか（権限）」ではない。両者は似て非なるものだ。
前掲の研究は、エージェント連携に必要なガバナンス要件を6つの観点——メンバーシップ（誰が輪に入れるか）・熟議・投票・反対意見の保全・人間へのエスカレーション・監査／再現（audit/replay）——で棚卸しし、既存の相互運用プロトコル群では投票や反対意見の保全が軒並み欠落し、統制に必要なプリミティブを完全には備えていないと結論づけている。研究者の言葉を借りれば、**エージェント共同体のガバナンスは「プロトコル内の欠けた機能」ではなく、「相互運用標準の“上”に載るべき、欠けた1層」**なのだ。
この構造は、実務者にとってはむしろ朗報でもある。プロトコルの成熟を待つ必要はなく、統制は自社側の一層で握ればよいという意味だからだ。実際、A2A自体も「エージェントBがエージェントAの代理として、限定されたスコープで動く」委任権限（delegation-of-authority）のモデルを育て始めているが、組織として「誰に・何を・いくらまで任せるか」を決めるのは、依然として企業側の責務であり続ける。
判断軸はシンプルにできる。「接続できるか（Can it connect?）」はプロトコルの問題、「委任してよいか（May it delegate?）」は組織の問題。前者はA2A/MCPが解く。後者は、自社の統制レイヤーでしか解けない。
企業が今から握るべき4つの制御点
委任グラフを統べるために、連携GAのいま押さえるべき制御点を4つに整理する。
| 制御点 | 問い | 実装の要点 |
|---|---|---|
| ID（同一性） | そのエージェントは「誰」か | 各エージェントに人間と混ぜない専用IDを与え、来歴を辿れるようにする |
| 委任ポリシー | 誰が誰に任せてよいか | 「AはBに委任可、ただし外部エージェントへの再委任は不可」を明文化・強制する |
| スコープ／予算上限 | どこまで・いくらまで代理させるか | 委任に権限スコープと消費上限を付け、越えたら止める |
| 委任チェーンの監査 | 何が・どこへ・何のために渡ったか | 越境を含む連鎖全体を、後から再現できる形で記録する |
参考になるのが、MicrosoftがAgent 365 をエージェントの統一レジストリ兼コントロールプレーンに据え、Entra の Agent ID でエージェントに同一性を与える設計だ（2026年5月1日にエージェントレジストリがEntraからAgent 365へ集約された）。組織内の全エージェントを一覧・管理する「レジストリ＋ID」の型は、上表の①②を支える土台になる。ただし重要なのは、この4点はどのベンダーのエージェントにも一律に効かせる必要があるという点だ。特定プラットフォーム内でしか効かない統制は、越境委任の前で穴になる。
homula の観点——「縦はMCP、横はA2A」を、統制つきの一層で束ねる
homula の実装思想は、この「プロトコルの上に載る統制レイヤー」の考え方とそのまま重なる。
- 接続（縦）: Agens は MCP を活用したエンタープライズ向け統合プラットフォームで、200以上のツールと構築ゼロで接続できる。エージェントを業務の文脈とツールにつなぐ「縦」を、個別開発なしで最短化する層だ。
- 統制（横の委任を含む）: Agens Control は承認フロー・DLP・5年分の監査ログ・RBAC を提供する。これはまさに、A2A/MCPが語らない「誰が・誰に・どこまで任せてよいか」を組織のポリシーとして強制し、越境を含む連鎖を記録に残すための一層だ。上表の②③④——委任ポリシー、スコープ／予算、委任チェーンの監査——を、プロトコルの外側から一律に効かせる。
- 定着: AIエージェント・ブートキャンプは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結する。連携をいきなり全開にするのではなく、「どの委任から解禁するか」を業務単位で見極めるところから始められる。
homula はこれらを、戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化 まで一気通貫で支援する。活用技術は n8n / Dify / LangGraph などベンダー中立で選ぶため、特定プラットフォームのエージェントに閉じない——委任が複数ベンダーをまたぐ時代に、統制もまたベンダー横断で効かせられることが要点になる。派手な自動化より、「任せてよい委任」を一つずつ増やしていく設計の方が、連携フェーズでは効いてくる。
まとめ
2026年8月の連携GAが示したのは、AIエージェントが「単独で働く道具」から「互いに仕事を委任し合う同僚」へと変わったことだ。Microsoft 365 Copilotの連携エージェント、Gemini EnterpriseのA2A管理——エージェント同士がベンダーやテナントを越えてつながることは、もう例外ではなく既定になった。
だが「つなぐ」の解決は、「任せてよい」の解決ではない。プロトコルは能力を語り、権限を語らない。委任グラフという新しい統制面では、ID・委任ポリシー・スコープ／予算・委任チェーンの監査を、プロトコルの“上”に載る自社の一層で握る必要がある。特に越境委任——承認を通ったエージェントが外部へ再委託する瞬間——を記録し統べられるかが、分岐点になる。連携を止める必要はない。止めるべきは、統制のない委任だ。
自社のどの業務から、エージェント連携を「統制つきで」解禁できるか。委任のポリシー設計と監査の型づくりから、無理のない一歩を一緒に描きませんか。