メインコンテンツへスキップ

9.5.2 MCP プロトコル概要

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

この節の位置づけ

ここまでに、あなたはすでに次を学びました：

  • Function Calling
  • ツール統合
  • Agent システムアーキテクチャ

これらの能力は、どれも同じ問いに答えています：

モデルはどのように安全かつ安定して外部ツールに接続するのか？

MCP の価値は、この問題をさらに一歩前へ進めることにあります：

ツール接続を、より統一されたプロトコルとして実現する。

学習目標​

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

なぜ MCP が必要なのか？​

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

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

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

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

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

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

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

プロトコルの意味とは？​

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

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

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

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

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

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

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

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

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

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

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

という点です。

MCP の最も重要な役割​

Client​

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

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

実際のシステムでは、client はよく次のいずれかです：

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

Server​

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

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

Tool​

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

  • search_docs
  • read_file
  • run_sql

Transport​

Transport は、client と server がメッセージをどうやり取りするかを決めます。
たとえば：

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

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

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 と Function Calling の関係は？​

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

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

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

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

たとえば：

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

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

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

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

より正確に言うと、

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

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

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

特に向いているケース​

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

たとえば：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MCP と Function Calling を 1 つの概念として混ぜてしまう​

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

まとめ​

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

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

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

練習​

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