MCP（Model Context Protocol）とは？
MCPは、大規模言語モデル（LLM）が外部のツールやサービスとやりとりするための標準的な接続プロトコルです。
これまで各社モデルごとに独自の「function calling」が存在し、同じ機能でも呼び出し方がバラバラでした。MCPはその“方言”を吸収し、共通の規格として統一を目指しています。
- 位置づけ：OSI参照モデルで言えば Layer7（アプリケーション層）
- 役割：LLMと外部サービスを橋渡しする「共通配線図」
- 形式：JSON-RPCに似た明示的なリクエスト／レスポンス構造
- メリット：
- ツール開発者は「一度MCP対応」すれば、複数のLLMに利用される
- ユーザーはモデルを切り替えても同じ方法でツールを呼び出せる
- エコシステム全体の整合性が高まり、エージェント開発が容易になる
かつてREST APIがWebサービスの共通言語となったように、MCPは「AIと外部サービスをつなぐ新しい共通言語」になろうとしています。
AI時代の配線史 ─ SOAPからMCPまでの進化
- SOAP（2000s）：厳格な仕様、企業用途で普及
- REST（2010s）：HTTPベースのシンプルなAPI、民主化の起点
- GraphQL（2015〜）：効率的なクライアント主導のデータ取得
- Function Calling（2023〜）：各社ベンダー独自のLLMツール呼び出し
- MCP（2024〜）：それらを吸収する「Layer7共通規格」
function callingとは何か
大規模言語モデル（LLM）は、当初「テキストを入力すればテキストを返す」だけの存在でした。
しかし、実務では「外部の情報を参照したい」「データベースを更新したい」「ツールを呼び出したい」といった要求が次々に生まれ、テキスト生成だけでは限界が見えてきました。
そこで登場したのが function calling です。
仕組みの概要
- 関数仕様をJSON Schemaで定義
例：{ "name": "getWeather", "description": "指定された都市の天気を返す", "parameters": { "type": "object", "properties": { "city": {"type": "string"} }, "required": ["city"] } } - LLMはこの仕様に従い、適切な引数を埋めて出力
出力例：{ "name": "getWeather", "arguments": {"city": "Tokyo"} } - アプリケーション側が受け取り、実際のAPI（天気APIなど）を叩く
メリット
- LLMを単なる会話相手から「外部サービスの司令塔」に進化させられる
- コード生成やシステム操作を安全に制御できる
- OpenAI、Anthropic、Dolphin3など主要モデルが実装を進めている
限界
- ベンダーごとに方言がある
- OpenAIのfunction calling
- Anthropicの「tool use」
- Dolphin3独自の関数出力
- 同じ「天気API」を呼ぶのにも、モデルが違えば呼び出し形式も違う
- 結果、開発者は「モデル依存コード」に縛られてしまう
図解にするなら：
[ユーザー] → [LLM] → (JSON出力) → [アプリ側でAPI呼び出し] → [結果をLLMに戻す]この構図が function callingの基本フローです。
ただしここに「ベンダーごとに微妙に違う方言」という摩擦が積み重なり、次章の MCP が必要になるわけです。
MCPの正体
MCPとは何か
MCP（Model Context Protocol） は、複数のLLMが外部ツールやサービスと連携するための 共通の通信規格 です。
「LLMが外部ツールを呼び出す」という目的自体は function calling と同じですが、最大の違いは ベンダーごとの方言を吸収し、標準化された仕組みを提供する 点にあります。
OSIモデルでの位置づけ
MCPは、ネットワークの世界でいうところの アプリケーション層（Layer7） に相当します。
- 下位層：モデル推論や通信手段（HTTP、WebSocketなど）
- Layer7（MCP）：ツール呼び出しの共通プロトコル
- 上位層：ユーザーアプリやエージェントフレームワーク
つまり、MCPは「AIと外部サービスをつなぐ共通言語」であり、HTTPがWebの世界を統一したように、MCPはAI時代の標準規格を目指しているのです。
実際のやりとり（イメージ）
MCPの通信は、JSON-RPC風のリクエスト／レスポンス形式で行われます。
ユーザーが天気を尋ねる場合
User: 東京の天気を教えて
↓
LLM: MCP仕様に従って getWeather(city="Tokyo") を提案
↓
MCPサーバー: 実際に天気APIを呼び出し、結果を返す
↓
LLM: ユーザーに自然言語で回答ポイント：
- LLMが違っても「getWeather」という呼び出し形式は共通
- ツール開発者は「一度MCP対応すれば」複数のLLMに利用される
REST APIとの比較
- REST API：サービス同士をつなぐ共通言語としてWebを席巻
- MCP：AIとサービスをつなぐ共通言語として広がりつつある
- 歴史は繰り返す──かつてRESTがSOAPを駆逐したように、MCPも各社function callingのバラつきを統一する可能性がある
MCPとfunction callingの違い
目的は同じ、仕組みは違う
どちらも「LLMが外部ツールを呼び出す」ための仕組みですが、立ち位置と適用範囲が異なります。
function calling は各ベンダーが用意した“方言”であり、MCPはそれを統一する“共通語”です。
比較表
| 項目 | function calling | MCP |
|---|---|---|
| 提供者 | 各ベンダー（OpenAI, Anthropic, Dolphin3など） | オープン規格（モデル横断） |
| 位置づけ | モデル固有の機能 | OSIモデル Layer7に相当する共通プロトコル |
| 形式 | JSON Schemaベース（ただし方言あり） | JSON-RPC風で統一 |
| 互換性 | モデルごとに実装が異なる | 1つの実装で複数LLMに対応 |
| 開発者負担 | モデルごとに接続コードを書く必要 | MCP対応すれば一度で済む |
| 歴史的たとえ | サイトごとのREST API仕様 | HTTPそのもの |
図解イメージ
従来：
[ツールA] ← OpenAI function calling
[ツールA] ← Anthropic tool use
[ツールA] ← Dolphin3独自関数
MCP後：
[ツールA] ← MCP → どのモデルでも同じ呼び方実務への影響
- 開発者：MCP対応すれば、OpenAIでもAnthropicでもオープンウェイトでも使える
- ユーザー：モデルを切り替えても同じツールがそのまま動く
- エコシステム：function callingの“乱立”を整理し、開発コストを大幅に下げる
MCPが変える実務と未来
ツール開発者にとっての意味
従来、ツールをAIから使えるようにするには「OpenAI用」「Anthropic用」「Dolphin用」など、モデルごとに実装を分ける必要がありました。
MCPが広がれば、その負担は劇的に減ります。
- 一度MCP対応すれば、複数モデルで利用可能
- 小規模開発チームでも「AI対応サービス」を容易に公開できる
- LLMを活用したプロダクトの開発コストが下がり、市場参入が容易になる
エージェント開発の加速
MCPは単なる「関数呼び出し」ではなく、エージェント基盤の共通配線として機能します。
- LLMが「どのツールを使うべきか」を選び、呼び出し、結果をまとめて返す
- MCPによってツール群を横断的に扱えるため、複数LLMを切り替えて動かすハイブリッド・エージェントも現実味を帯びてくる
- 「モデルは変わるが、使うツールは同じ」という柔軟な設計が可能に
企業利用の広がり
企業が自社サービスをAI経由で使ってもらう流れも、MCPによって加速します。
- かつて「REST APIを公開すれば、他サービスやアプリに組み込まれた」ように
- 今後は「MCP対応すれば、複数AIアシスタントから呼び出される」時代へ
- これは AIアプリのマーケットプレイス に直結する動きとなる
歴史的アナロジー
- SOAPからRESTへの移行でWeb開発が一気に民主化された
- RESTからGraphQLへの進化で効率がさらに高まった
- 同じように、function calling（乱立期） → MCP（統一期） という流れが始まりつつある
未来の展望
- マルチモーダルMCP：画像認識や音声処理も同じ規格で呼び出せるようになる
- セキュリティ強化：認可スコープや権限管理がMCP標準で組み込まれる
- AI時代の新しい標準化戦争：REST APIと同じように、MCPが「共通言語」となるか、別規格が割り込むかは今後数年で決まる
課題と展望
標準化はまだ途上
MCPは構想としては魅力的ですが、すべてのモデルやツールが対応しているわけではありません。
- OpenAIやAnthropicのfunction callingは既に広く使われているが、完全にMCPに統一されてはいない
- Dolphin3などのローカルLLMも対応を模索中で、実装の成熟度には差がある
- 結果として「MCP対応済み／未対応」のツールが混在する状態が続く
セキュリティと権限管理
MCPが普及すれば、LLMが直接外部システムを叩けるようになります。
- 認証・認可の仕組みをどう組み込むかが大きな課題
- REST APIと同じく スコープ付きのアクセス制御 が不可欠
- 「AIが勝手に操作するリスク」を避けるための監査ログも重要になる
日本語エコシステムへの波及
国内の中小企業や個人開発者にとっても、MCPはチャンスです。
- 英語のAPI設計がハードルだった時代と違い、MCPは“AIの共通言語”として浸透する
- 自社サービスをMCPに対応させれば、グローバルAIアシスタントから呼び出される可能性が広がる
- つまり 「日本発サービスがAI経由で世界に露出する」 新しい道が開ける
未来のロードマップ
- 短期：各モデルが独自function callingとMCPを併用
- 中期：主要エージェントフレームワークがMCP準拠に移行し、統一化が進む
- 長期：マルチモーダル対応（画像・音声・センサー）を含む「AI総合バス」として発展
- REST APIがWebの基盤となったように、MCPは「AI時代の標準プロトコル」へと進化する可能性が高い
まとめ
function callingはAIに外部ツールを扱わせる第一歩だった。
しかし、その乱立は開発者に負担を強いてきた。
MCPはその壁を取り払い、Layer7に新しい共通配線図を描こうとしている。
歴史は繰り返す。SOAPがRESTに取って代わられたように、そしてRESTがWebを席巻したように──
MCPは、AIと外部サービスを結ぶ新しい「共通言語」になるのかもしれない。
