偉大なるAIエージェントプロトコル競争：Function Calling vs. MCP vs. A2A
最近AI開発の世界を注視しているなら、おそらくあることに気づいているでしょう。今や誰もがAI Agentsについて話しています。単なる賢いチャットボットではなく、ツールを使い、APIを呼び出し、さらには互いに協力できる本格的な自律プログラムです。LangChainとOpenAIは、「AI Agents」の定義をめぐって議論まで行いました。
しかし、本格的なAI Agentシステムを構築し始めるとすぐに、大きな悩みに直面します。Agentがツールと、あるいは互いに連携するための明確で普遍的な方法が存在しないのです。
現在、AIエージェントアーキテクチャの未来を定義しようとして、3つの主要なアプローチが競い合っています。
Function Calling: OpenAIの先駆的なアプローチ — LLMに若手開発者のようにAPI呼び出しを行わせる
MCP (Model Context Protocol): モデルやサービスを横断する標準ツールキットインターフェースを作ろうとするAnthropicの試み。
A2A (Agent-to-Agent Protocol): 異なるAgent同士が会話し、チームとして働くことを可能にするGoogleの最新仕様。
OpenAI、Anthropic、Googleといった主要なAIプレイヤーは皆、これらの標準を定義する者が将来のエージェントエコシステムを形作ると静かに賭けています。
基本的なチャットボットを超えるものを構築する開発者にとって、これらのプロトコルを理解することは、単に流行についていくためだけではありません。将来のつらい書き直しを避けるためでもあります。
この記事で取り上げる内容は次のとおりです。
Function Callingとは何か。なぜツール利用を可能にしたのか — しかしなぜそれだけでは不十分なのか。
MCPが、ツールとモデルのための本物のプロトコルを作ることで、この混乱をどのように解消しようとしているのか。
A2Aが、Agentを単独行動ではなくチームのように連携させることで何を追加するのか。
（誇大宣伝を追いかけて時間を無駄にせずに）これらを実際にどのように使うべきか。
Function Calling: 成長痛を抱える先駆者
OpenAIによって普及し、現在ではMeta、Googleなどにも採用されているFunction Callingは、LLMを外部ツールに接続する最初の主流アプローチでした。自然言語のリクエストに基づいてAPI呼び出しを書く方法をLLMに教えるようなものだと考えてください。
図1- Function callingワークフロー (Credit @Google Cloud)
図1: Function callingワークフロー (Credit @Google Cloud)
ワークフローは単純です。
ユーザーが質問する（「シアトルの天気は？」）
LLMが外部データが必要だと認識する
事前定義されたリストから適切な関数を選択する
JSON Schemaに従ってパラメータを整形する: 5
{
"location": "Seattle",
"unit": "celsius"
}
アプリケーションが実際のAPI呼び出しを実行する
LLMが返されたデータを応答に組み込む
開発者にとって、Function Callingは、AIに従うことのできるAPIレシピ集を与えるような感覚です。単一モデルを使うシンプルなアプリケーションであれば、ほぼプラグアンドプレイです。アプリケーション構築にFunction callingを使う方法についてさらに学ぶには、以下の記事をご覧ください。
しかし、スケールする際には大きな欠点があります。モデル間の一貫性がないことです。各LLMプロバイダーはFunction callingを異なる方法で実装しています。ClaudeとGPTの両方をサポートしたいですか？ その場合、別々の関数定義を維持し、異なるレスポンス形式を処理する必要があります。
これは、キッチンにいるシェフごとに、レストランの注文を別の言語で書き直さなければならないようなものです。このM×N問題は、モデルやツールを追加するにつれて急速に扱いにくくなります。
Function Calling には、複数ステップの関数チェーンに対するネイティブサポートもありません。ある関数の出力を別の関数に渡す必要がある場合、そのオーケストレーションは自分で処理することになります。
MCP (Model Context Protocol): AI とツールのためのユニバーサル翻訳機
MCP (Model Context Protocol) は、まさにこれらのスケーリング上の課題に対処します。Anthropic が支援し、Claude、GPT、Llama などのモデル全体でサポートが広がっている MCP は、LLM が外部ツールやデータソースとやり取りするための標準化された方法を導入します。
MCP の仕組み
MCP は「AI ツールのための USB 標準」のようなものだと考えてください — 互換性を保証するユニバーサルインターフェースです。
ツールは標準化された形式を使用して自分の機能を通知し、利用可能なアクション、必要な入力、期待される出力を説明します
AI モデルはこれらの説明を読み取り、ツールの使い方を自動的に理解できます
アプリケーションは一度統合するだけで、AI エコシステム全体で互換性を得られます
MCP は、煩雑な M×N の統合問題を、より扱いやすい M+N の問題へと変換します。
MCP アーキテクチャ
MCP は、4 つの主要コンポーネントを持つクライアントサーバーモデルを使用します。
Figure 2- The MCP architecture (Credit @Anthropic)
図 2: MCP アーキテクチャ (Credit @Anthropic)
MCP Hosts: ユーザーが AI とやり取りするアプリケーション（Claude Desktop や AI 強化型コードエディタなど）
MCP Clients: ホストとサーバー間の通信を管理するコネクタ
MCP Servers: MCP 標準を通じて機能を公開するツール実装
Data Sources: 情報を提供する基盤となるファイル、データベース、API、サービス
Function Calling が、異なるシェフに対して複数の言語を話さなければならないようなものだとすれば、MCP はキッチンにあるユニバーサル翻訳機のようなものです。ツールを一度定義すれば、MCP 互換のどのモデルでもカスタムコードなしでそれらを使用できます。これにより、アプリケーションに新しいモデルやツールを追加する際の限界費用が劇的に削減されます。統合の頭痛の種に対処してきた者としては、これは耳に心地よい話です。
A2A (Agent-to-Agent Protocol): AI エージェントのためのチームコーディネーター
Function Calling と MCP がモデルとツールの相互作用に焦点を当てている一方で、Google が導入した A2A (Agent-to-Agent Protocol) は、別の課題に取り組みます。複数の専門化されたエージェントをどのように効果的に協調させるか？
AI エージェントのアーキテクチャがより複雑になるにつれ、単一のエージェントがすべてを処理すべきではないことはすぐに明らかになります。文書要約に特化したエージェント、データベースクエリに特化した別のエージェント、ユーザーインタラクションに特化したさらに別のエージェントがあるかもしれません。
A2A は、異なる Agents が以下を行えるようにする、軽量でオープンなプロトコルを定義します。
互いを発見し、自分の機能を通知する、
最適な Agent にタスクを動的に委任する、
進捗を調整し、リアルタイム更新を安全に共有する。
Figure 3- How A2A works (credit @Google)
図 3: A2A の仕組み (credit @Google)
A2A は、タスクを管理する「client」エージェントと、それを実行する「remote」エージェントの間の通信を促進します。Function Calling がエージェントにツールへのアクセスを与えるものだとすれば、A2A はエージェントが効果的なチームを形成できるようにします。
ソフトウェアエンジニアを採用する場合を考えてみましょう。採用マネージャーは、自分のエージェントに特定の基準に合う候補者を見つけるよう指示できます。このエージェントはその後、専門エージェントと協力して候補者を調達し、面接をスケジュールし、身元調査を進めます — すべて統一されたインターフェースを通じて行われます。
クイック比較: Function Calling vs MCP vs A2A
これらのプロトコルを競合するものと見なしたくなりますが、実際にはエージェントエコシステムというパズルの異なる部分を解決しています。
Function Calling はモデルを個々のツールに接続します（限定的だがシンプル）
MCP は、異なるモデル間でのツールアクセスを標準化します（よりスケーラブル）
A2A は、独立したエージェント間の協調を可能にします（より高レベルのオーケストレーション）
| Function Calling | MCP | A2A | |
|---|---|---|---|
| 解決すること | モデル → API 呼び出し | モデル → ツールアクセス、標準化済み | エージェント → エージェントの協調 |
| 適している用途 | シンプルなリアルタイムクエリ | スケーラブルなツールエコシステム | 分散型マルチエージェントワークフロー |
| 課題 | 標準がなく、マルチモデル対応が煩雑 | サーバーをセットアップする必要がある | まだ初期段階で、サポートが限定的 |
| 現実世界の例え | AI に電話のかけ方を教えること | あらゆるスマートアプリが任意のデータベース/API に簡単にアクセスできること | ボットのチームが同僚のように一緒に働くこと |
アーキテクチャの観点では、MCP は「私のエージェントはどのツールを使えるのか？」に答え、A2A は「私のエージェント同士はどう連携できるのか？」を扱います。
これは、複雑なソフトウェアを構成する方法に似ています。明確に定義されたインターフェースを持つ個々のコンポーネントを、より大きなシステムへと組み合わせるのです。効果的なエージェントエコシステムには、ツールインターフェース（Function Calling/MCP）とエージェント間通信（A2A）の両方が必要です。
これが開発者にとって意味すること
では、AI を使って開発する開発者として、これらの競合する標準にどう向き合うべきでしょうか？
シンプルなアプリケーションの場合: Function Calling は、LLM アプリケーションにツール利用を追加する最短ルートであり続けます。特に、1つのモデルプロバイダーだけを使っている場合に有効です。
モデル横断の互換性が必要な場合: MCP の採用を検討してください。統合作業を重複させることなく、より広範なモデルサポートを得られます。
複雑なマルチエージェントシステムの場合: A2A に注目しておきましょう。エージェントエコシステムが成熟するにつれて、重要な存在になる可能性があります。
賢い戦略は、これらのアプローチを階層的に組み合わせることかもしれません。素早いプロトタイピングには Function Calling を使い、より高いスケーラビリティのために MCP アダプターを実装し、マルチエージェントワークフローには A2A オーケストレーションを使うのです。
今後の展望
「AI Agent」を何が構成するのかをめぐる議論は、いまも進化し続けています — OpenAI、Anthropic、LangChain のような企業間で議論されることさえあります。
しかし定義がどうであれ、ひとつ明らかなことがあります。Function Calling、MCP、A2A のような標準は、次世代の AI アプリケーションの基盤を築いています。
開発者にとって、これらのパターンを早期に理解することは、自分の仕事を将来にわたって通用するものにするための投資です。これは、単なるデモから本番対応のシステムへと進む方法です — 大規模に現実の問題を解決するようなシステムへ。エージェントエコシステムは急速に発展しており、今これらのプロトコルを基盤に構築することは、次に来るものに向けてアプリケーションを位置づけることを意味します。
あなたはどう思いますか？AI プロジェクトではどのプロトコルを使っていますか？ひとつの標準が勝ち残ることに賭けていますか、それともマルチプロトコルの未来に備えていますか？
その他のリソース
読み続けて
Vector Lakebase: End the AI Data Silo
Learn how Vector Lakebase unifies vector search, data lakes, and AI data operations so teams can serve RAG and agents without copy-and-sync pipelines.
Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure
Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.