こんにちは、Lena です。MCP を初めて誰かに説明しようとしたとき、少し違和感がありました。
「AI をツールにつなぐ」と言い続けていたのですが、技術的には正しいのに、水面下で実際に起きていることは捉えきれていませんでした。話を聞いていた人はうなずいてから、「じゃあプラグインみたいなもの？」と聞いてきました。私は言葉を失いました。それも完全には当てはまらないから。
「動くことは分かる」と「どう動くか分かる」のあいだ — そこに少し腰を据えたいのがこの記事です。堅い技術解説というより、MCP サーバーが実際にどう振る舞うか、私が観察してきたことを一歩ずつたどるような感じで。
MCP が解決しようとした問題
なぜモデルとツールの統合は、これまでカスタムだらけだったのか
MCP ができる前は、言語モデルを外部ツールにつなぐたびに、毎回カスタムの統合を書く必要がありました。GitHub には独自の形式がありました。 データベースにもそれぞれのやり方がありました。API ごとに別プロジェクトでした。
単一の統合が難しいというわけではありません。積み重なりの問題で — どれも互いに話せず、モデルが「ここで何ができる？」と標準的に問う手段もなかった。つなぎは全部手織りでした。
Model Context Protocol は Anthropic のその答えです。2024 年 11 月にオープンソース化され、共通言語 — どの AI アプリケーションもカスタム配線なしでツールプロバイダーにつなげる標準化されたクライアント・サーバー型プロトコルを導入しました。2025 年中頃には OpenAI と Google DeepMind が採用しました。その後、Linux Foundation プロジェクトである Agentic AI Foundation の傘下に移りました。
その動きは少し意味があります。一社の標準から、より共有されたものへと変わり始めた。実務で何が変わるかまだ完全にははっきりしませんが、気づき続けています。
MCP のアーキテクチャ：動く三つの要素
MCP サーバーはどう動くのか と聞かれたとき、私がいちばんはっきりしている出発点は三つの部分です。それぞれ役割が違い、混乱はだいたいそれらを一つにまとめてしまうところから来ます。
MCP Host（AI アプリ）
ホストは、実際に使っているアプリケーションです — Cursor、Claude Desktop、AI 拡張の入った VS Code。ユーザーが見て触るものです。
ホストはセキュリティの仲介者です。 モデルのコンテキストウィンドウを管理し、どのツールが使えるかを決め、LLM に戻す内容を制御します。ツール呼び出しを自ら実行するわけではありません — アクセスだけを司ります。カスタムのエージェント基盤を作らない限り、ほとんどの開発者はホストのロジックを書きませんが、ホストがモデルが届く範囲と届かない範囲を決める、という点は理解しておく価値があります。
MCP Client（ホストに組み込まれる）
クライアントはホストが作ります。ホストと各 MCP サーバーのあいだに置かれ、接続を管理します。典型的には MCP サーバーごとに MCP クライアントが一つ — それぞれが専用のセッションを維持します。
クライアントはケイパビリティの交渉を行い、メッセージを往復させ、トランスポートの詳細を抽象化します。ホストは、サーバーが stdio なのか HTTP なのかを知る必要はありません。それはクライアントの仕事です。
MCP Server（ツールの提供者）
サーバーには、実際の能力が置かれています。ツール、リソース、プロンプト — 作られた目的に応じて何を提供するかを公開します。GitHub の MCP サーバーはリポジトリ操作を、Postgres のサーバーはクエリ関数を公開します。サーバーはだいたい一つの統合ドメインに絞られます。
もっとよく見て驚いたのは、サーバーは単なるプログラムだということです。ホストと同じマシン上でローカルに動いても、インターネット上のどこかでリモートに動いてもかまいません。変わるのはプロトコルではなくトランスポートだけです。
ツール呼び出しが実際に起きるまで
頭の中で少しずつずれていた部分を、一歩ずつ書き出すまで正しく捉えられなかったのがここです。
ステップ 1：サーバーが利用可能なツールを通知する
クライアントが初めてサーバーに接続するとき、ハンドシェイクがあります。クライアントは initialize リクエストを送ります。サーバーはプロトコル版と、提供するケイパビリティの一覧 — どのツールがあるか、名前、入力スキーマ、説明 — で応答します。これを ケイパビリティ交渉（capability negotiation） と呼びます。
クライアントはそれらのツール定義をモデルのシステムプロンプトに埋め込みます。LLM が何が使えるか知るのはこの仕組みです。魔法ではなく、構造化されたコンテキストです。
ステップ 2：モデルがツールを使うと判断する
モデルがリクエストを処理していてツール呼びが適切だと判断すると、構造化された呼び出しを出します — ツール名と渡したい引数です。モデルはツールを直接呼びません。 構造化された指示を出力し、ホストが解釈します。
ステップ 3：クライアントがサーバーに呼び出しを送る
クライアントはその構造化された呼び出しを受け取り、正しいサーバーへ JSON-RPC 2.0 上の tools/call リクエストとして転送します。これがワイヤフォーマットです — メソッド名、パラメータ、相関のための一意の ID を持つ辞書です。
ステップ 4：サーバーが実行して結果を返す
サーバーは実際の関数を実行します — データベースクエリ、API 呼び出し、ファイル読み取り、作られた目的に応じた何でもです。構造化されたレスポンスを返します。何かがうまくいかない場合は、生の例外ではなく型付きのエラーを返します。よくできたサーバーは、モデルが何が失敗し、なぜ失敗したかを理解するのに役立つエラーメッセージを返します — リカバリーに効きます。
ステップ 5：モデルが結果を取り込む
結果はクライアントとホストを経由してモデルのコンテキストに戻ります。モデルは会話の一部として読み、そこから続けます。
…うん、何をしているか見えてきました。各ステップは意図的に分離されています。モデルはツールに直接触れません。あいだには常にレイヤーがあります。
トランスポート層：サーバーとクライアントの話し方
stdio（ローカル）と HTTP/SSE（リモート）
Stdio トランスポートは標準入力と標準出力のストリームを使います。ホストがローカルの MCP サーバーをサブプロセスとして起動するとき — npx my-mcp-server を実行するような場合 — クライアントとサーバーはそれらのストリームへの書き込みと読み取りで通信します。ネットワークは介在しません。レイテンシのオーバーヘッドもありません。同じマシン上のプロセス間通信にすぎないので速いです。
Streamable HTTP トランスポート（リモートサーバー向けの現行標準。2025 年 3 月のプロトコル更新で規定）は、クライアントからサーバーへのメッセージに HTTP POST を使い、ストリーミング応答にはオプションで Server-Sent Events を使います。Cloudflare や Vercel のようなプラットフォーム上でホストされ、多数のクライアントに同時に応えるリモートサーバーがこれを使います。
古い HTTP+SSE 形式（2024 年 11 月の仕様）ではエンドポイントが二つ必要でした。新しい Streamable HTTP 仕様はそれを一つのエンドポイントにまとめました。古いドキュメントを読むときは知っておくとよいです — パターンは変わっています。
レイテンシとセキュリティへの意味
ローカルの stdio サーバーは速く、攻撃面も小さいです。それと話せるのはホストのプロセスだけです。リモートサーバーはネットワークのレイテンシを招き、認証が必要です。2025 年 7 月の調査では、インターネットに晒された MCP サーバーのうち認証がまったくないものが約 2,000 件にのぼることが分かりました — 誰でもツール一覧にアクセスできました。2025 年 6 月の仕様更新では MCP サーバーを OAuth Resource Server として分類するなど一部に対応しましたが、実装のばらつきは残っています。
その詳細は頭に残りました。プロトコルはセキュリティのパターンを定義できますが、強制はできません。公式の MCP セキュリティ文書に推奨事項がまとまっています — 機微なデータを扱うものをデプロイする前に読む価値があります。
多くの開発者が見落とすレイヤー
成功したツール呼び出しのあとに何が起きるか
しばらく私を混乱させていたのはここです：成功したツール呼び出しだけでは、何も永続化されません。
結果はそのセッションのモデルのコンテキストに戻ります。モデルはそれを使って応答を生成し、先に進みます。しかしツールが呼ばれたという事実 — モデルが取った具体的な経路、選んだ入力、得た結果 — は会話ウィンドウの中にしかありません。セッションが終われば消えます。
MCP サーバーは知識を蓄積しません。過去のセッションに基づいて応答が上手くなるわけではありません。新しい接続は毎回同じ初期状態から — ハンドシェイク、ケイパビリティ一覧、白紙です。
なぜ「接続」は「能力の持続」と同じではないのか
「接続は能力の持続（capability persistence）ではない」と言うとき、指しているのはこれです。
MCP サーバーに接続すると、モデルはツールへのアクセスを得ます。以前どうそのツールを使ったか、何がうまくいき何が失敗したかという記憶をモデルに与えるわけではありません。サーバーは過去のセッションに関係なく、毎回同じケイパビリティを公開します。
これは考え続けています。欠陥というより設計上の境界線です。プロトコルが扱うのは通信と実行です。その実行の出力を — 保存するか、学習に使うか、先へ運ぶか — はまったく別のレイヤーです。
…まだ掘れる余地はありそうです。これは考え続けます。
FAQ
- MCP サーバーとは具体的に何ですか？
MCP サーバーは、Model Context Protocol を通じて AI エージェントにツール、リソース、プロンプトを公開する軽量なプログラムです。言語モデルからの構造化されたリクエストを、実際の操作 — データベースクエリ、API 呼び出し、ファイル読み取り — に翻訳し、結果を標準化された形式で返します。AI アプリと同じマシン上でローカルに動かしても、HTTP 越しにリモートで動かしてもかまいません。
- MCP はどのトランスポートプロトコルを使いますか？
MCP は二つのトランスポート機構をサポートします。Stdioは標準入出力ストリームを使い、同一マシン上のローカル通信向け — 速く、ネットワークのオーバーヘッドはありません。Streamable HTTP（リモートサーバー向けの現行標準）は HTTP POST と、ストリーミングにはオプションで Server-Sent Events を使います。どのトランスポートでも、メッセージの土台は JSON-RPC 2.0 です。
- MCP サーバーは別の MCP サーバーを呼べますか？
プロトコル上は可能です。MCP クライアントは複数のサーバーへの接続を同時に維持できます — データベース用、ファイルアクセス用、外部 API 用など、同じセッションの中で。あまり一般的でなく、現行実装でもあいまいなのは、サーバーが別のサーバーに対するクライアントとして振る舞うパターンです。そのパターンも存在しますが、複雑さが増し、セキュリティ境界の推論が難しくなります。
プロトコルはまだ形を変えています。仕様は 2024 年 11 月のリリース、2025 年 3 月の更新、そして今アクティブに使われているもののあいだですでに意味のある変更を経ています。あと一つか二つのバージョンでアーキテクチャがどう見えるか — 正直まだ分かりません。でももっと学んでいきます。
