ベンダーロックを超えるMCP ─ Function Callingとの比較で分かる利点

API地獄に疲れた開発者へ
Function Callingの現実
MCPのアプローチ
Function Calling vs MCP 比較
パフォーマンス懸念は杞憂か？
歴史の再演 ─ SOAPからREST、そしてMCPへ
ベンダーロックを超える未来

API地獄に疲れた開発者へ

生成AIをシステムに組み込みたい──そう考えたとき、まず立ちはだかるのが「Function Calling」です。
ユーザーからの自然文をLLMが解釈し、必要な外部ツールを呼び出す。確かに便利な仕組みです。
しかし、実際に触ってみた開発者の多くは、こう感じているのではないでしょうか。

ベンダーごとに定義方法が微妙に違う
JSONで延々と関数仕様を書くのがつらい
仕様変更が入るたびにコードを修正しなければならない
せっかく書いた関数呼び出しが、別のLLMでは再利用できない

「動かすたびに仕様を覚え直す」──この小さな負担が積み重なることで、Function Callingはかえって開発者を疲弊させています。
そして、もしあなたがOSSやローカルLLMの世界に足を踏み入れているなら、ベンダー依存の大きさに一層の閉塞感を覚えるはずです。

ここで登場するのが MCP（Model Context Protocol）。
各社バラバラに乱立するFunction Callingを、共通規格として再定義する試みです。
SOAPからREST、そしてGraphQLへとつながるAPI進化の歴史を思い出してみてください。
その延長線上に「MCP」という新しいレイヤーが現れようとしています。

Function Callingの現実

Function Calling は、各社が「LLMに外部ツールを扱わせるための仕組み」として導入してきました。
OpenAI、Anthropic、Google──名前は違えどやっていることは似ています。
しかし実際にコードを書くと、その「似ているはず」がむしろ厄介さを生んでいるのです。

冗長な定義

たとえば OpenAI の Function Calling では、関数のシグネチャを JSON Schema 形式で細かく記述します。

{
  "name": "get_weather",
  "description": "指定された都市の天気を返す",
  "parameters": {
    "type": "object",
    "properties": {
      "location": { "type": "string", "description": "都市名" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["location"]
  }
}

一見シンプルに見えますが、引数が増えれば数十〜数百行に膨らみます。
型定義を厳密に書けるのは利点ですが、LLMのバージョンやAPIの更新で再記述が必要になります。

ベンダーごとの差異

Anthropic では JSON Schema ではなく「tool use」という形式を採用しており、記法が微妙に異なります。
Google の Gemini API も独自の定義を持っており、結局ベンダーごとに覚え直し。
OSS系やローカルLLM環境では、そもそもこれらの仕様に追随できていないことが多い。

ベンダーロックの現実

こうして書いた Function Calling は、そのままでは他ベンダーのLLMに移植できません。
「せっかく作った関数を、別の環境で再利用できない」──これは開発者にとって大きな心理的負担です。

MCPのアプローチ

MCP（Model Context Protocol）は、まさにこの「ベンダーごとの差異」「コードの再利用不可」という問題を解消するために提案された共通規格です。

共通レイヤーとしてのMCP

役割は「LLMと外部ツールの間に共通の言語を置く」こと。
LLMがどのベンダーであろうと、ツールを呼び出す際のインターフェイスが揃います。
これにより「一度作ったツールは、別の環境でも動かせる」未来が開けます。

シンプルな宣言

MCPでのツール定義は、Function Callingに比べてぐっと簡潔です。
例として「天気を取得するツール」を宣言すると、以下のようになります。

{
  "name": "get_weather",
  "description": "指定された都市の天気を返す",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": { "type": "string" },
      "unit": { "type": "string" }
    },
    "required": ["location"]
  }
}

OpenAI Function Calling の例と似ていますが、ベンダー依存の部分が排除され、より抽象的で移植性の高い形になっています。

開発者にとっての意味

ツールを一度作れば、異なるLLM環境でもそのまま使える可能性が高まる。
仕様変更やバージョンアップに振り回されにくい。
ローカルLLM（Ollama や LM Studio）にも同じプロトコルで対応できる。

つまり MCP は、Function Calling が「便利だけど閉じた仕組み」にとどまっていたのを、オープンで再利用可能な仕組みへと引き上げるアプローチなのです。

Function Calling vs MCP 比較

両者を横並びで見てみると、その思想と利便性の差がよく分かります。

Function CallingとMCPの比較図。Function Callingは各ベンダー独自の実装で互換性に課題があり、ロックインの懸念がある。一方MCPはLayer7の共通規格として、ベンダー横断の互換性とエージェント間連携を可能にする。

コード量と表現力

Function Calling
- JSON Schemaで詳細を記述するため、複雑な関数では数十〜数百行に膨らむ。
- 厳密な型定義は可能だが、記述の負担が大きい。
MCP
- 必要最小限の宣言で済む。
- 抽象化により、ツールの追加や変更に柔軟に対応できる。

再利用性

Function Calling
- ベンダー固有仕様。OpenAIで作ったものはAnthropicやGoogleに持ち込めない。
MCP
- 共通プロトコルとして設計されているため、同じ定義を複数環境で利用可能。

拡張性

Function Calling
- 各社が独自に拡張しているため、横の互換性は乏しい。
MCP
- 標準化を前提に拡張可能。OSSやローカルLLMにも波及しやすい。

依存度

Function Calling
- 完全にベンダー依存。API更新のたびに追随必須。
MCP
- ベンダーをまたいで利用可能。依存度を抑えられる。

パフォーマンス

Function Calling
- ベンダー直結のためオーバーヘッドは最小。
MCP
- 共通レイヤーを経由するぶん理論上は僅かな遅延があるが、実際はLLM推論に比べ誤差レベル。
- 利便性による恩恵が圧倒的に勝る。

パフォーマンス懸念は杞憂か？

抽象化レイヤーを設けると「遅くなるのでは？」という疑問は当然浮かびます。
Function Callingはベンダー直結ですから、最小限のオーバーヘッドで動作します。
一方で MCP は共通プロトコルを経由するぶん、追加の処理が入ります。

しかし、その正体は JSONのシリアライズ／デシリアライズ や ルーティング といった軽微なものです。
計測すればミリ秒単位で、LLM本体の推論時間（数百ms〜数秒）に比べれば 誤差の範囲 といえます。

むしろ MCP がもたらすメリットは、開発効率と運用効率の大幅な向上です。

一度作ったツールを複数の環境で再利用できる
ベンダー依存の学習コストを抑えられる
標準化ゆえに将来の拡張や互換性に強い

これはちょうど、SOAPからRESTへ移行した時代にも繰り返された議論です。
「抽象化は遅い」と言われながらも、結局は使いやすさと普及の波が勝ち、RESTが標準となりました。
MCP も同じ道を歩もうとしています。

歴史の再演 ─ SOAPからREST、そしてMCPへ

APIの世界は、常に「標準化と抽象化」をめぐるせめぎ合いの歴史でした。

SOAP（2000年代）
厳格な仕様でエンタープライズを席巻。しかし複雑で扱いづらく、Web開発者には敬遠された。
REST（2010年代）
HTTPをそのまま利用できるシンプルさで爆発的に普及。
「使いやすさが標準を制する」ことを証明した。
GraphQL（2015〜）
クライアント主導で必要なデータだけを取得できる仕組み。
RESTの過不足を解決する手段として広まった。
Function Calling（2023〜）
各社がLLMにツールを扱わせるため導入。だが仕様が乱立し、再び「互換性の壁」が立ちはだかる。
MCP（2024〜）
その壁を吸収する「Layer7の共通規格」として登場。
Function Callingをより抽象化し、ベンダーを越えた再利用を可能にする。