MCP（Model Context Protocol）とは？APIとの違いからツールサーチまで

LLM（大規模言語モデル）に社内データベースやGitHub、Slackなどの外部ツールを連携させようとしたとき、ここ最近「MCP」という言葉を急速に目にするようになりました。Anthropicがオープンソース規格として発表したプロトコルですが、最初に聞いた時は「既存のWeb APIやFunction Callingと何が違うんだろう？」と不思議に思っていました。

気になって調べてみたところ、MCPは単なる「新しい便利ライブラリ」ではなく、AIが外部世界とやり取りするための通信標準を統一しようというオープンな取り組みのようです。今回は、なぜMCPがここまで注目されているのか、従来のAPIと何が違うのか、そして運用上で見えてきた新しい課題と最新の進化について整理してみました。

1. なぜ今MCPがここまで話題になっているのか

これまでAIモデルに外部データや操作を連携させようとすると、いわゆる「N × M問題」が発生していました。N種類のAIモデル（Claude、ChatGPT、Gemini、ローカルLLMなど）と、M種類の外部サービス（GitHub、PostgreSQL、Notion、Slack、ローカルファイルなど）が存在する場合、組み合わせごとに固有の連携コードや統合レイヤーを書く必要があったためです。

開発者側からすると、Claude Desktop用、Cursor用、自作のAIチャット用と、アプリやクライアントが変わるたびにコネクタを書き直さなければならず、非常にメンテナンスの手間がかかっていました。この掛け算構造を解決するために提案されたのが、MCP（Model Context Protocol）です。

MCPは、AIクライアント（ホスト）とデータソース/ツール（サーバー）の間に統一のインターフェースを差し込みます。これにより、コネクタの開発が「1 × (N + M)」になり、一度MCPサーバーを作ってしまえば、MCPに対応したあらゆるAIクライアントから共通で利用できるようになります。

調べてみて印象的だったのは、Anthropicが自社製品だけに閉じず、最初からオープン規格として仕様を公開し、TypeScriptやPythonなどのSDKを整備している点です。すでにClaude DesktopやCursor、Windsurfをはじめ、様々なAIクライアントが対応を進めており、WebにおけるHTTPのようなインフラ層の標準規格を目指している雰囲気を感じます。

2. APIとの違いと、直接使わせようとした時に起きる問題

「でも外部システムを呼び出すなら、既存のREST APIやOpenAPI仕様書があるじゃないか」と思うかもしれません。実際、従来のFunction CallingでもOpenAPIのスキーマをJSON化してプロンプトに流し込み、AIに呼び出させることが可能でした。しかし、既存のAPIをそのままAIに使わせようとすると、いくつか固有の問題にぶつかります。

最大の理由は、一般的なREST APIは「人間（プログラマー）」が読むドキュメントとコードを前提に設計されているからです。認証方法、エンドポイントのURL設計、エラーコードの意味、レスポンスのネスト構造などはサービスごとにバラバラです。これをAIに解釈させようとすると、次のような課題が顕在化します。

コンテキストトークンの消費（Context Bloating）： APIの仕様書やリクエスト形式をプロンプトに大量に載せる必要があり、それだけで数千〜数万トークンを費やしてしまいます。コストが跳ね上がるだけでなく、肝心の会話文脈が押し出されてしまいます。
ツール選択の精度低下： 連携したいAPIが増えてエンドポイントが数十〜数百個になると、LLMが「どのAPIを選ぶべきか」で混乱し、引数の渡し間違いや全く無関係なAPIを呼び出すエラーが増加します。
状態変更や通知の受け取り不可： REST APIは基本的に一問一答のHTTPリクエストです。サーバー側のデータ構造が変わったり、処理が完了したという非同期イベントをAI側に通知する仕組みを別途組む必要があります。
認証と権限管理の煩雑さ： 各サービスごとにAPIキーの渡し方が異なり、ユーザーの安全な承認フロー（「このファイルを削除していいですか？」といった確認）をプロトコルレベルで標準化しづらい課題がありました。

従来のREST APIとMCPの違いを比較表に整理すると、設計思想の違いがはっきり見えてきます。

比較項目	従来のREST API / Web API	MCP (Model Context Protocol)
主な対象読者	人間の開発者・自作プログラム	AIモデル（LLM）およびAIクライアント
通信仕様・フォーマット	サービスごとに自由（HTTP/REST, GraphQL等）	JSON-RPC 2.0 に基づく完全統一標準
データと機能の整理	エンドポイントとHTTPメソッド（GET/POSTなど）	Resources / Prompts / Tools に抽象化
コンテキスト効率	OpenAPI等のスキーマ全体を渡すため肥大化しやすい	動的な一覧取得・要約・オンデマンド読み込みに対応
リアルタイム通知	WebhookやWebSocket等を個別実装	プロトコルレベルでサーバーからの通知（Notification）をサポート

3. MCPの正体は「AIに優しい統一仕様書」

MCPの核となっているのは、AIにとって分かりやすい形にツールやデータを整理・カプセル化する仕組みです。具体的には、MCPは外部のリソースや機能を次の3つの概念に分類して扱います。

Resources（リソース）： ファイルの内容、データベースのレコード、ログデータなど、AIが会話の文脈（コンテキスト）として読み取るための読み取り専用データです。URI指定（例: file:///logs/app.log や postgres://users/schema）でアクセスできます。
Prompts（プロンプト）： サーバー側が提供する再利用可能な指示用テンプレートです。ユーザーが特定の操作をしたい時に、最適なシステムプロンプトや文脈設定を自動的に組み立ててくれます。
Tools（ツール）： 「データベースに書き込む」「GitHubでIssueを作成する」「シェルコマンドを実行する」といった副作用を伴う実行可能なアクションです。引数のフォーマットはJSON Schemaで明確に指定されます。

通信の裏側では、堅牢で実績のある JSON-RPC 2.0 プロトコルが使われています。たとえば、MCPクライアントがサーバーに対して利用可能なツール一覧を問い合わせる際のリクエストとレスポンスの例を見てみます。

// クライアントからのリクエスト (tools/list)
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

// サーバーからのレスポンス例
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "search_database",
        "description": "社内データベースをSQLクエリで検索します",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": { "type": "string", "description": "実行するSQLクエリ" }
          },
          "required": ["query"]
        }
      }
    ]
  }
}

このように、あらゆる外部システムが同じフォーマットで自分の持ち札（リソースやツール）を返してくれるため、AI側は特別な個別パース処理を書く必要がありません。また、クライアントとサーバーの通信軸はローカル環境（stdin/stdout）でもネットワーク経由（SSE: Server-Sent Events）でも動く設計になっています。

実効ロジックをLLM側に無理に学習させるのではなく、「ツールの定義と実際の処理はサーバー側が担い、AIには扱いやすいインターフェースだけを見せる」というアプローチは、非常にクリーンで合理的だと感じます。

4. 新たな課題「ツールの増えすぎ問題」と最新の進化（ツールサーチ）

非常に便利なMCPですが、エコシステムが広がり多数のMCPサーバーを登録できるようになると、今度は別の問題が持ち上がってきました。それが「MCPサーバーが増えすぎて、結局コンテキストウィンドウが圧迫される」という問題です。

たとえば、GitHub、Slack、PostgreSQL、GDrive、Local Filesystemなど、10個のMCPサーバーを接続したとします。各サーバーが15個ずつツールを持っていた場合、合計150個ものツール定義（JSON Schema）が会話の冒頭でプロンプトに注入されることになります。これでは、いくら規格が統一されていてもトークン消費が跳ね上がり、AIの判断精度も落ちてしまいます。

この課題に対応するため、MCPの仕様やAIフレームワーク側で導入されているのがDynamic Tool Discovery（動的ツール発見）や「Tool Search（ツールサーチ）」と呼ばれる技術です。

具体的なアプローチとしては、以下のような進化が進んでいます。

遅延読み込み（Deferred Loading）： 最初からすべてのツール詳細を読み込まず、ツールの名前と軽い概要だけを把握しておき、実際に必要になったタイミングで詳細な引数スキーマを取得する仕組みです。
ツールサーチツール（Tool Search Tool）： 利用可能な大量のツール群をベクトル検索（セマンティック検索）などでインデックス化しておき、ユーザーの質問に関連する上位3〜5個のツールだけを動的に選出してコンテキストに載せる手法です。
プログラム経由のツール呼び出し（Programmatic Tool Calling）： 自然言語の対話だけでツールを呼ぶのではなく、コード実行サンドボックス内で必要なツールを探索・スクリプト実行させることで、やり取りのトークン数を大幅に節約する試みです。

ツールが増えれば増えるほど、すべてを暗記（常時プロンプト保持）させるのではなく、「必要な時に図書室の検索機で調べて持ってくる」というアプローチに進化しているのは面白い流れです。

5. これからのAIエージェント開発とMCPの関わり

MCPについて調べていくと、単に「ローカルのAIアプリでファイルを開くための仕組み」にとどまらず、将来的なAIエージェントのインフラとして基盤を固めつつあることが分かります。

最近では、自社のSaaSやWebサービスのAPIをMCPサーバーとしてラップして公開する動きも増えてきました。これまで人間が画面操作したり、開発者がcURLで叩いていた機能を、MCPサーバーとして提供することで「AIエージェントから即座に利用できるサービス」へと進化させられるためです。

個人的には、セキュリティや権限管理のレイヤー（誤って危険なツールが実行されないための人間による承認フロー）がプロトコルに組み込まれている点も、実務で使う上で重要だと感じました。APIを直で渡す場合の不安感が、MCPの標準仕様によってかなり和らぐ印象です。

今後、様々なAIツールや開発環境を触る機会が増える中で、MCPに対応しているかどうかはツール選定の大きな基準の一つになっていきそうです。ツールサーチをはじめとする最新の仕組みを含め、エコシステムがどう発展していくのか引き続き注目していきたいと思います。

リンク