この画像はエントリの内容ををNano Banana Proのインフォグラフィックスとなります

なぜ今さら"規格"の話が大事なのか

2025年はAIエージェントの年になるって予想がいろいろ出ていましたよね。2026年1月現在の振り返ってみると、少なくともAIエージェントの年になり得る条件はだいぶ整ってきたという印象でしょうか。

その核にあるのが エージェント周辺の標準化（プロトコル整備） です。

MCP　…　エージェントが 外部ツール／データ にアクセスするための標準化
A2A　…　エージェント同士が 安全に協調 するための標準化

この2つによって、チャットで便利から一段進んで、業務としての"自動化" を設計しやすくなります。ここが私の技術的な興味で一番ワクワクするポイントですね😊

MCP = "AI界のUSB-C" って何を標準化してるの？

MCP（Model Context Protocol）は、エージェントが外部システムに接続する方法を共通化するための考え方です。
よく｀USB-C｀に例えられますが、技術的には以下のような感じではないでしょうか。

MCPがない世界

つまり、M×N問題で詰む世界になります🥲

例えば、「会計DB＋複数SaaSから月次レポート生成」みたいな処理を考えてみると、MCPがない場合はこんな苦労が積み上がっていきます。

連携先ごとに 個別実装（API差分、認証、データ構造） が必要
接続先が増えるほど組み合わせが爆発（M×N問題）
連携先の仕様変更に追随し続けないといけない
管理点が増えるほど 監査・統制 がどんどん難しくなる

まとめると、エージェントを"賢くする"以前に、つなぎ込みがボトルネックになっちゃうんですよね🙄 これ、実務でAI導入しようとすると本当によくぶつかる壁なのではないでしょうか。

MCPがある世界

つまり、窓口と入館証の仕組みが存在する世界とも言えます。

MCPでは外部システム側がMCPサーバ（受付窓口）として振る舞います。
このモデルの良さは、接続が増えても窓口が増えるだけで済み、連携する際の差分を吸収しやすくなります。

さらに重要なのが 権限（入館証）とログ の考え方。

エージェントが どのデータ／期間／帳票にアクセスできるか を絞れる
やりとりのログを残して、問題があったら追跡できる

業務適用では便利さよりも統制（ガバナンス）が勝つ場面が多いので、ここは実装価値が高いです。経験上、この権限とログの部分がちゃんとしてないと、結局本番運用で使用できない状況に至ってしまいます。

A2A = エージェント同士をつなぐ"共通言語"

A2A（Agent2Agent）は、Googleが2025年4月に発表したプロトコルです。
要するに異なる会社・異なるフレームワークで作られたエージェント同士を、安全につなぐための共通言語です。

ここでのキーワードは 相互運用性（interoperability）でしょうか？

ベンダーが違っても
実装フレームワークが違っても
インターネット越しに安全にやりとりできる

単一エージェントが全部やるのではなく、複数の専門エージェントが役割分担する マルチエージェント が設計しやすくなります。

考えてみると、これってWeb APIの世界で長年やってきたことと同じ方向性ですよね。RESTで接続方法を標準化してきたように、エージェントの世界でも同じことが起きている、といえます。

MCPとA2Aはどう噛み合うのか

この2つの関係を整理すると、こうなります。

MCP　…　エージェント → 外部ツール／データ（縦方向の組み合わせ）
A2A　…　エージェント ↔ エージェント（横方向の組み合わせ）

つまり、"縦軸"が整うと単体のエージェントの実用性が上がり、"横軸"が整うと専門エージェントの協調ができるというものです。そして、両方の軸が揃うと業務を分解・委譲・合成 する構成が現実的になります。

個人的にはこの縦軸と横軸の整理がスッと入ってきて、人に説明するときも使いやすいなと思ってます。

具体例で考えてみる

具体例で考えてみましょう。社員が出張手配をマルチエージェントで依頼するケースが以下となります。

例：「来月の海外出張の計画を参照して、航空券とホテルを予約し、関係者に通知して」

このとき汎用エージェントは全部自分で実行せず、オーケストレーション役（調整役） になります。

依頼をサブタスクに分解
- 航空券検索・予約
- ホテル検索・予約
- 社内出張申請
- 関係者通知
各タスクを"専門エージェント"に委譲（ここで A2A）
専門エージェントが外部APIやDBを呼ぶ（ここで MCP）
実行結果をA2Aで報告（旅程表などの成果物＝アーティファクトが返る場合も）

この流れが成立すると、人間が関わるポイントを減らし、複雑な業務を完了できる可能性が出てきます。

プロトコルがあっても"意味"は揃わないという落とし穴

ここが技術的に一番重要なポイントかも😊

A2AやMCPという技術が揃うことでつながることのハードルは大幅に下がります。

注意が必要なのは、プロトコルは通信の枠（フォーマット・手順）であって、意味（セマンティクス）そのものを自動で統一してくれるわけではない点です。

先程の例で考えると、「予約して」という一言でも、解釈が割れます。

予約＝仮押さえ？確定購入？
上限金額は？例外条件は？
社内規程（承認、利用可能な航空会社、クラス制限）をどう扱う？
失敗したら再試行？代替案提示？人に確認？

プロトコルで"送受信"ができても、前提のズレが残ると、最悪の場合は「勝手に確定してしまった」「規程違反で監査に引っかかった」みたいな事故が発生します。

これ、まさに私の研究でもでてくる話ですが「言葉にできていない前提」が一番厄介なんですよね。いわゆる非機能要件ですね。

自然言語→構造化→実行という実務の定石

先程でてきた、セマンティクス問題をつぶす方法は、だいたいこんな方向に落ち着きます。

パラメータを型で固定　…　上限金額、確定前確認の要否、優先条件（時間／価格／直行便など）
成果物を構造化して返す　…　テキスト旅程だけでなく、日時・便名・金額・規程チェック結果などをJSON等で返す
ガードレールを明文化　…　「上限超えたら必ず人に確認」「確定購入は人の承認が必要」など
監査できるログ設計　…　いつ誰がどのデータにアクセスし、どんなアクションを実行したかを追えるようにする

つまり、A2A/MCPが普及すると接続のコストは下がり、意味の設計＝業務ルールの明文化と構造化 が重要になります。これってRAGの世界でも同じで、どんなデータを、どういう粒度で、どう構造化して持っておくかが最終的な精度を決めるのと似た構図といえます。

企業にとってどう考えるか？

現在（2026年1月）時点の話となりますが…

多くの企業は、まず「チャット型AIの定着」からロードマップを作ってきたはずです。ただ今後、MCPやA2Aのような基盤が整ってくると、エージェント活用の実用化が進んでいく可能性が高くなります。運用の準備をしていないとまた数年乗り遅れることもあり得るので、このあたりは早めに動くのがいいのではないでしょうか？

現時点で考えておく必要があるのは、技術と運用をセットで捉えることです。