9.5.2 MCP プロトコル概要

MCP クライアントサーバーメッセージフロー図

学習目標

単独で書くツール接続コードがすぐに乱れやすくなる理由を理解する
MCP が解決しようとしている核心問題を理解する
client、server、tool、transport の役割を区別できるようになる
最小限の MCP 風メッセージ例を読めるようになる
MCP の適用シーンと限界に対する正しい直感を身につける

なぜ MCP が必要なのか？

まず「プロトコルがない」場合に何が起きるかを見る

もし Agent システムに 3 つのツールを接続するとします：

検索
ファイルシステム
データベース

最も起こりやすいのは、次のような状況です：

ツールごとに API の形式が違う
ツールごとにパラメータの書き方が違う
エラー処理もそれぞれ別実装になる
クライアントが変わるたびに適応層を作り直す必要がある

最初は何とか我慢できると思うかもしれません。ですが、ツールが増えると、システムはすぐにこうなります：

ツールを 1 つ増やすたびに、たくさんの接着コードが増える。

プロトコルの意味とは？

プロトコルの意味は、「名前を立派にすること」ではありません。本質は次の通りです：

異なるシステムが、共通のルールに従って情報をやり取りできるようにすること。

たとえるなら、次のようなものです：

USB に対する周辺機器
HTTP に対する Web リクエスト
SQL に対するデータベース問い合わせ

MCP が目指しているのは、まさにこれです：

ツール接続の世界における「統一された差し込み口」

MCP は何に答えているのか？

まずは 3 つの問いにまとめられます：

クライアントは、サーバー上にどんなツールがあるかをどう知るのか？
クライアントは、それらのツールをどう統一形式で呼び出すのか？
ツールの呼び出し結果やコンテキストは、どう返すのか？

つまり、MCP が関心を持っているのは、ある特定のツールそのものではなく、

クライアントとツールサーバーが、どう安定してやり取りするか。

という点です。

MCP の最も重要な役割

クライアント（Client）

クライアントは起点となる側です。通常、次の役割を担います：

ツールを見つける
ツールを選ぶ
呼び出しを開始する
結果を受け取る

実際のシステムでは、クライアントはよく次のいずれかです：

Agent フレームワーク
チャットクライアント
IDE プラグイン

サーバー（Server）

サーバーは能力を提供する側です。通常、次の役割を担います：

ツールを公開する
呼び出しリクエストを受け取る
ツールの処理を実行する
結果を返す

ツール（Tool）

ツールは、サーバーが公開する具体的な機能です。たとえば：

search_docs
read_file
run_sql

トランスポート（Transport）

トランスポートは、クライアントとサーバーがメッセージをどうやり取りするかを決めます。たとえば：

標準入出力
ローカルプロセス通信
ネットワーク接続

まずは一言で覚えておきましょう：

client はツールを使うかどうかを決め、server はツールを提供する。

まずは最小限の MCP 風メッセージを見る

MCP 風のやり取りは、通常かなり明確な構造を持ちます。ここでは、直感をつかむために簡略化した JSON-RPC 風メッセージを見てみましょう。

request = {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list",
    "params": {}
}

response = {
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "tools": [
            {"name": "search_docs", "description": "コース資料を検索する"},
            {"name": "get_weather", "description": "天気を調べる"}
        ]
    }
}

print(request)
print(response)

想定出力：

{'jsonrpc': '2.0', 'id': 1, 'method': 'tools/list', 'params': {}}
{'jsonrpc': '2.0', 'id': 1, 'result': {'tools': [{'name': 'search_docs', 'description': 'コース資料を検索する'}, {'name': 'get_weather', 'description': '天気を調べる'}]}}

この例で最も大事なのはフィールド名ではなく、構造の感覚

この例が教えているのは次の点です：

リクエストとレスポンスは対になっている
各メッセージには明確な method 名がある
result フィールドはただの文字列ではなく、構造化データである

これが、プロトコルがもたらす安定性です。

なぜ「ツール発見」が大きな問題なのか？

プロトコルがないと、クライアントは通常、あらかじめ次を固定で書いておく必要があります：

ツール名
パラメータ形式
戻り値の形式

その結果、次のような問題が起きます：

クライアントとサーバーが強く結びつく
ツールセットが変わるたびにコード修正が必要になる

MCP の重要な価値の 1 つは、次の考え方です：

まず発見して、それから呼び出す。

つまり、クライアントは事前にすべてのツール詳細を固定しておく必要はありません。代わりに、プロトコルを通して次のように問い合わせられます：

どんなツールがありますか？
それぞれのツールはどう説明されますか？

これにより、ツールのエコシステムはより柔軟になります。

MCP と関数呼び出しの関係は？

この 2 つの概念は、かなり混同されやすいです。

関数呼び出しは「モデル層の構造化された呼び出し能力」に近い

関心があるのは次の点です：

モデルが構造化された呼び出し意図を出力できるか

たとえば：

{
  "name": "search_docs",
  "arguments": {"query": "返品ポリシー"}
}

MCP は「システム層のツール接続プロトコル」に近い

関心があるのは次の点です：

client と server がどうやってツールを見つけるか
どうやってツールを説明するか
どうやってツールを呼び出すか
どうやって結果を返すか

より正確に言うと、

関数呼び出しは「モデルが構造化された呼び出しをどう出すか」を解決し、MCP は「システムがツール接続をどう標準化するか」を解決します。

両者は一緒に使えますが、同じものではありません。

MCP はどんな場面に向いているのか？

特に向いているケース

ツールの種類が多い
クライアントの種類が多い
ツール接続方法を統一したい
将来的にツールのエコシステムを拡張したい

たとえば：

IDE アシスタント
デスクトップ Agent
企業内ツールプラットフォーム

必ずしも MCP を使う必要がないケース

もし次のような用途なら：

小さなスクリプト
2〜3 個の内蔵ツール
複数クライアントからの接続需要がない

その場合は、ローカルのツール呼び出し層を直接書くだけで十分なこともあります。

なので、MCP を「必ず使うもの」と考えるのではなく、次のように理解しましょう：

ツールのエコシステムと接続の複雑さが増すほど、プロトコル化の価値は高くなる。

もっと身近な比喩：MCP は「ツール用の電源タップ」

こう考えるとわかりやすいです：

tool は 1 つ 1 つの家電
client はそれらを使う人
MCP は共通の電源タップと接続規格

もし共通の電源タップがなければ：

家電ごとに差し込み口が違う
つなぐたびに毎回適応が必要になる

共通の電源タップがあれば：

新しい家電を接続しやすい
利用側は毎回新しいルールを覚えなくてよい

これが、プロトコルの持つエンジニアリング上の価値です。

初心者がよくハマる落とし穴

MCP を特定のツールライブラリだと思ってしまう

違います。まずはプロトコルとやり取りの約束事です。

MCP があれば自動でツールを使えると思ってしまう

そうではありません。プロトコルが解決するのは接続層です。呼び出し方針、権限、評価は、引き続き自分で設計する必要があります。

MCP と関数呼び出しを 1 つの概念として混ぜてしまう

関係はありますが、レイヤーが違います。

残す証拠

このページを終えたら、この証拠カードを残します。

機能: サーバーが公開するリソース、Prompt、またはツール
契約: スキーマ、通信方式、権限、エラー形式
呼び出しトレース: 探索、呼び出し、応答、失敗時の処理
失敗確認: 互換性のないスキーマ、認証不足、安全でないツール、またはサーバーエラー
統合アクション: 自律化を追加する前にサーバー契約を確認する

まとめ

この節で最も重要なのは、「プロトコル」という言葉を覚えることではなく、次を理解することです：

MCP の核心的価値は、クライアントとツールサーバーの間における、発見・説明・呼び出し・結果交換を、より統一されたシステム契約にすること。

この直感さえつかめれば、後でアーキテクチャ、server、client、エコシステムを学ぶときに、単にたくさんの API 名を見ているだけだとは感じなくなるはずです。

練習

client、server、tool、transport がそれぞれ何の役割を担っているか、自分の言葉で説明してみましょう。
「ツール発見」そのものが、なぜプロトコル化する価値があるのか考えてみましょう。
システムに固定の 2 つのツールしかない場合、なぜ今すぐ MCP を導入しなくてもよいのか考えてみましょう。
自分の言葉で、MCP と関数呼び出しの違いを説明してみましょう。

解法と解説

妥当な答えはこうです。client はユーザー目標を受け取り、いつ能力を呼び出すかを決める側です。server は契約つきで能力を公開する側です。tool は実行可能な 1 つの能力です。transport は発見、呼び出し、応答を運ぶ通信経路です。
ツール発見を標準化する価値があるのは、安全に呼び出す前に client が「何が使えるか」「有効な引数は何か」「エラーはどう返るか」「権限境界はどこか」を知る必要があるからです。
固定ツールが 2 つだけなら、手書き統合のほうが単純で、デバッグしやすく、保守コストも低いことがあります。MCP は、ツールが増える、変わる、複数チームから来る、発見と契約を再利用したい、という段階で効きます。
Function Calling は多くの場合、モデルが構造化された関数呼び出しを選ぶための仕組みです。MCP は外部能力を発見して呼び出すための、より広い client-server プロトコルです。併用できますが、レイヤーは違います。