A2Aとは、異なるAIエージェント同士が安全に連携するための共通仕様のことです。

複数のAIに仕事を渡す運用を、事務所としてどこまで許すかを決めていますか。この記事では、2026年3月12日に安定版となったA2Aプロトコルv1.0の内容を読み解き、士業事務所がエージェント同士の連携を業務へ入れるときの委任範囲の決め方を整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、仕様の内容は策定主体の公表資料で確認しています（出典: A2A Protocol Ships v1.0）。

v1.0が何を変えたのか 事務所が気にすべき4つの追加機能

結論から言えば、v1.0の主眼は新機能の追加ではなく、企業が実運用で使える水準へ仕様を締め直したことです。事務所の立場では、複数のベンダーのAIを組み合わせて使う前提が現実的になったという意味を持ちます。

A2Aは、異なるAIエージェントが互いの能力を見つけ、通信し、業務を委任するための公開仕様です。技術運営委員会にはAWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNowの代表が参加しています。v1.0は最初の安定版として位置づけられ、公表日は2026年3月12日です（出典: A2A Protocol Ships v1.0）。

企業向けに追加されたのは4点です。第一が異種環境への対応で、複数のプロトコルバインディングとバージョン交渉により、特定のベンダーや基盤に縛られずに連携できます。第二がマルチテナント対応で、ひとつの接続点で複数のエージェントを安全に扱えます。第三が署名付きエージェントカードで、エージェントの身元とメタデータを暗号的に検証できます。第四がセキュリティ姿勢の改善で、現在の実務に合わなくなった古い方式が取り除かれています。

このうち、士業事務所にとって直接効くのが第三の署名付きエージェントカードです。相手のエージェントが名乗っているとおりの主体かを、やり取りを始める前に確かめられます。事務所の外のエージェント、たとえば顧問先の社内システムが動かすエージェントと接続する場面では、この検証の有無が信頼の土台になります。

Linux Foundationは、A2Aが公開から1年で150を超える組織の支持を得て、主要クラウド基盤へ組み込まれ、複数の業界で本番運用に入っていると公表しています（出典: The Linux Foundation A2A Protocol Surpasses 150 Organizations）。2026年8月には、A2AがAgentic AI Foundationへ参加することも公表されました。MCPと同じ財団の下に並んだことで、両者を組み合わせる設計が語りやすくなっています。

MCPとの関係は、公表資料の中で明示されています。MCPは個々のエージェントの内側でツールや文脈を統合するために使われ、A2Aはエージェント同士の通信と調整に焦点を当てます。多くのシステムは両方を使い、エージェントの内側にMCP、エージェント同士の間にA2Aという役割分担になるという整理です。仕様の全体像を横断的に見ておきたい場合は、関連する4仕様の並びを別稿にまとめています（AAIFの4仕様が出そろった 士業事務所のツール選定7判断軸）。

委任範囲を決める7つの判断軸 有資格者の判断をどこに残すか

結論を先に置くと、エージェント同士の連携を業務へ入れるときに決めるのは技術設定ではなく、どの判断を機械に渡さないかの線です。士業の業務では、この線が資格の意味そのものと重なります。

第一の判断軸は、委任する作業の種類です。資料の収集、一次的な整理、形式面の点検はエージェントに渡しやすい作業です。一方で、法令の当てはめ、顧問先への回答の確定、書面の最終確認は有資格者の判断が要る部分です。この二つを作業レベルで書き出し、どちらに属するかを一件ずつ決めます。

第二の判断軸は、連鎖の深さです。A2Aはエージェントが別のエージェントへ業務を委任する構造を扱います。三段、四段と連鎖すると、最初の指示がどう変質したかを追いにくくなります。事務所の運用では、連鎖の段数に上限を置く設計が扱いやすいところです。

第三の判断軸は、相手方の身元確認です。署名付きエージェントカードが使える場合は、検証を必須の手順として組み込みます。検証できない相手とは接続しないという線を、最初に引いておきます。

第四の判断軸は、データの流れです。エージェント同士がやり取りする内容に、顧問先の情報がどこまで含まれるかを設計します。連携の便利さに引きずられて、何でも渡す設計になりやすいので、渡す項目を列挙する形で管理します。

第五の判断軸は、結果の受け取り方です。v1.0では、ポーリング、ストリーミング、ウェブフックのいずれかで結果を受け取れます。事務所の運用では、処理が終わったことを人が気づける形にしておくのが要点です。自動で次の工程へ流れる設計にすると、途中の確認が抜けます。

第六の判断軸は、記録の粒度です。どのエージェントがどの指示を受け、何を返したかを追えるようにしておきます。士業の業務では、後から顧問先や監督官庁に経緯を説明する場面があるため、記録は成果物と同じくらい重要になります。

第七の判断軸は、止め方です。想定外の動きをしたときに、どこで止めるかを決めておきます。連携が深いほど、止める操作の設計が難しくなります。導入の設計段階で、緊急停止の手順を書いておく形が現実的です。

七つの判断軸のうち、第一の作業の種類だけは技術の話ではありません。ここは有資格者が決める部分で、外注もツールも代われません。残りの六つは、決めた線を守るための仕組みという位置づけになります。

委任範囲を書き出す作業は、次のようなプロンプトで下書きを作れます。

あなたは士業事務所の業務設計を支援するアシスタントです。
以下の業務を工程に分解し、それぞれについて分類してください。

【業務】顧問先からの労務相談への一次回答
【分類軸】
A. AIエージェントに委任できる作業
B. 有資格者が判断する作業
C. 判断が分かれるため事務所で決める作業

出力形式:
1. 工程名
2. 分類（A/B/C）
3. その分類にした理由（1文）
4. Cに分類した場合、決めるべき論点

制約:
- 法令の解釈や適法性の評価はしない
- 一般的な業務設計の観点として書く
- 表は使わず番号付きの箇条書きで

接続先の点検には、次の形が使えます。

以下のエージェント連携の構成を読み、確認すべき点を挙げてください。

【構成】（エージェント名 / 役割 / 委任元 / 委任先 / 扱うデータ）
（貼付）

出力してほしいもの:
- 委任の連鎖が3段以上になっている経路
- 身元検証の手順が明記されていない接続
- 処理結果を人が確認する工程が入っていない経路

制約:
- 貼り付けた構成に書かれていない情報を補わない
- 各項目に理由を1文添える
- 結論の断定ではなく、確認すべき論点として書く

権限の設計そのものは、MCP側の議論と地続きです。事務所内のツール接続でどこまで権限を与えるかは、別稿で項目に分けて整理しています（MCP連携の権限設計 士業事務所が詰める7項目）。

顧問先のエージェントと接続する前に決める3点

結論から言えば、外部のエージェントと接続する設計で最初に決めるのは、こちらから出す情報の範囲です。相手が顧問先であっても、他の顧問先の情報が推測できる形で出るのは避けたい状況です。

士業の秘密保持は各業法に置かれています。弁護士については弁護士法第23条が職務上知り得た秘密を保持する権利と義務を定め、税理士については税理士法第38条が正当な理由なく税理士業務に関して知り得た秘密を他に洩らし、または窃用してはならない旨を定めています。社会保険労務士については社会保険労務士法第21条に同趣旨の規定があります。エージェント同士の連携でデータが事務所の外へ流れる設計を考えるときは、これらの規定との関係が論点になります。

第一に決めるのは、出す情報の項目です。エージェント間の通信は自動で進むため、人が都度判断する機会がありません。出してよい項目をあらかじめ列挙し、それ以外は通さない設計にしておく形が扱いやすいところです。

第二に決めるのは、相手方のエージェントが何をするかの理解です。署名付きエージェントカードには、そのエージェントが提供する能力が記載されます。接続前にこれを読み、想定していない用途に使われないかを確認します。顧問先の社内で運用されているエージェントの場合、顧問先の情報システム部門に用途を確認する流れを入れておくと、認識のずれを避けられます。

第三に決めるのは、同意の取り方です。顧問先のデータを扱うエージェントと接続するなら、その旨を委任契約や個別の合意に書いておく運用があります。書き方は事務所ごとに異なりますが、どのデータがどこへ流れるかが読み取れる粒度にしておくと、後から説明を求められたときに答えられます。相手方が上場企業であれば、自社の情報セキュリティ規程で外部との自動連携を制限している場合があるので、規程の確認を受任時の手順に入れておく事務所もあります。

もうひとつ押さえておきたいのが、AIベンダー側のデータ利用方針です。Anthropicは商用サービスの入出力を既定でモデルの訓練に使用しない旨を利用規約に明記しています（出典: Anthropic Commercial Terms of Service）。OpenAIはビジネス向けプランについて、既定で顧客のビジネスデータを訓練に使用しないと公表しています（出典: OpenAI Enterprise privacy）。エージェント連携では、経路上の複数の事業者にデータが渡ることがあるため、それぞれの方針を確認する手間が増えます。

連携設計で起きやすい3つの失敗と、その手前で止める方法

ひとつ目は、移行を一度に行う失敗です。v1.0では相互作用のプロトコルに互換性のない変更が入っています。ただしエージェントカードは後方互換の形で拡張され、旧版と新版の両方への対応を同時に表明できるようになりました（出典: A2A Protocol Ships v1.0）。段階的に移せる設計になっているので、一斉切替を狙わず、接続ごとに順次移すほうが安全です。

ふたつ目は、自動化の範囲を広げすぎる失敗です。エージェント同士が連携すると、人が介在しない工程が長くなります。長くなるほど、誤りが下流へ伝播したときの影響が大きくなります。士業の業務では、有資格者の確認を挟む位置を先に決め、その位置を動かさない運用にしておくのが要点です。

三つ目は、記録を残さずに運用を始める失敗です。エージェント同士のやり取りは高速で、後から再現するのが難しくなります。何をどの順で記録するかを、接続を作る時点で決めます。記録がなければ、想定外の結果が出たときに原因を特定できず、顧問先への説明も組み立てられません。

導入と維持にかかる費用と工数、誰が持つか

費用は、エージェントを動かす基盤と、各エージェントが使うAIモデルの利用料が中心です。エージェント同士のやり取りが増えるほど、モデルの呼び出し回数も増えます。一度の依頼で何回のやり取りが発生するかを試算しておかないと、想定より支出が膨らみます。

工数の中心は、委任範囲の設計です。技術的な接続そのものは開発側の作業ですが、どの作業を渡してどの作業を残すかは事務所が決めます。業務ごとに工程を分解し、分類していく作業に、まとまった時間が要ります。この作業は一度やれば資産になるので、最初の一業務に丁寧に時間をかける価値があります。

維持の面では、仕様の更新に追随する担当を決めておきます。A2Aは公開から短い期間で安定版に到達しており、今後も更新が続く見込みです。MCP側の更新とあわせて見ておくと、両方の変更が事務所の運用に及ぼす影響を一度に把握できます（MCP新ロードマップの5領域を士業事務所はどう読むか 導入前の7確認）。

エージェント連携が当たり前になったとき、事務所の何が問われるか

今後の論点は、責任の所在をどう説明するかに集約されていきます。エージェントが別のエージェントへ委任する構造では、最終的な出力に至る経路が長くなります。顧問先に対して、誰の判断でこの結論になったのかを説明する場面で、経路の記録がそのまま答えになります。

もうひとつの論点は、顧問先側からの接続要求です。大企業が社内のエージェント基盤を整えるほど、外部の専門家事務所にも同じ形での接続を求めてくる可能性があります。対応できるかどうかが取引条件に影響する場面が出てくると、事務所側にも準備が要ります。ただし現時点では、日本の士業事務所でこの水準の連携が必要になるケースは限られます。いま決めておくべきは、技術を入れるかどうかではなく、どの判断を機械に渡さないかという線のほうです。この線は技術が変わっても動かない部分なので、先に決めておく価値があります。

よくある質問

A2AとMCPはどちらを入れればよいですか

役割が異なるため、どちらかを選ぶ関係ではありません。公表資料では、MCPは個々のエージェントの内側でツールや文脈を統合するために使われ、A2Aはエージェント同士の通信と調整に焦点を当てると整理されています（出典: A2A Protocol Ships v1.0）。事務所で複数のAIを連携させる段階になってからA2Aを検討する順番が現実的です。

小規模な事務所にA2Aは要りますか

現時点では、単一のAIツールを使っている段階の事務所に必要性は薄いところです。複数のエージェントを別々のベンダーで運用し、それらを連携させたい段階になって初めて意味が出ます。まずは委任範囲の線引きを紙の上で決めておくことが、将来どの技術を入れるにしても効きます。

署名付きエージェントカードとは何ですか

エージェントの身元とメタデータを暗号的に検証できる仕組みで、v1.0で導入されました。組織の境界を越えたやり取りの前に信頼を確立する目的で設けられています（出典: A2A Protocol Ships v1.0）。相手が名乗っているとおりの主体かを確かめる手段として使われます。

旧版から移行するとき、一度に切り替える必要がありますか

エージェントカードが後方互換の形で拡張され、旧版と新版の両方への対応を同時に表明できるようになっています。これにより、一度の切替ではなく段階的な移行が可能と説明されています（出典: A2A Protocol Ships v1.0）。

エージェントに顧問先への回答を任せてよいですか

可否は、回答の性質と事務所の設計によって変わります。有資格者の判断を要する部分を機械に渡す設計は、責任の所在を説明しにくくなる点が論点になります。一次的な情報整理までをエージェントに任せ、回答の確定は有資格者が行う構成を採る事務所があります。

連携の記録はどのくらい残せばよいですか

保存期間を定める公的な基準は、この仕様に関しては見当たりません。事務所としては、業務記録の保存期間に合わせる形が扱いやすいところです。顧問先から経緯を問われる可能性がある期間を目安に置く運用が採られています。

顧問先のシステムと直接つなぐことはできますか

技術的には可能ですが、接続の前に確認する事項が増えます。相手方の情報システム規程、身元検証の手段、出す情報の範囲、記録の取り方の四つを、接続を作る前に書面で確認しておく形が現実的です。

参考文献

• A2A Protocol Ships v1.0: Production-Ready Standard for Agent-to-Agent Communication
• The Linux Foundation A2A Protocol Surpasses 150 Organizations
• e-Gov法令検索 弁護士法第23条
• e-Gov法令検索 税理士法第38条
• e-Gov法令検索 社会保険労務士法第21条
• Anthropic Commercial Terms of Service

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/