MCP 2026-07-28仕様とは 1リクエスト化で何が変わるか

LLM（大規模言語モデル）を使ったエージェントに外部ツールを接続する仕組みとして、MCP（Model Context Protocol、モデル・コンテキスト・プロトコル）を検討中、あるいはすでに実装済みのエンジニアに向けた内容です。2026年7月28日付で公開されたMCP仕様の変更点と、実際に手を動かして確認する方法を整理しました。

MCPはAnthropicが2024年11月に発表した、LLMエージェントに外部ツール（検索・DB操作・ファイル処理など）を標準的な形で提供するためのプロトコルです。2025年に大きな注目を集めた一方で、ターミナルとcurlを使わせる「エージェントハーネス」型の実装（AnthropicのSkillsなど）に人気を奪われた時期もありました。今回の仕様変更は、MCP誕生以来もっとも大きな変更とされており、この設計変更を機に改めて実装の見直しを検討する価値があります。

ステートフルからステートレスへ、何が変わったのか

従来のMCP（便宜上「レガシーMCP」と呼びます）は、ツールを1回呼び出すのに2回のHTTPリクエストが必要でした。

1回目はinitializeメソッドでセッションを開始し、レスポンスからMcp-Session-Idを受け取ります。2回目のリクエストで、そのセッションIDをヘッダーに付けてtools/callを送る、という流れです。

# 1回目: セッション初期化
POST /mcp
{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25", "clientInfo":{"name":"my-app"}}}

# 2回目: ツール呼び出し(Mcp-Session-Idが必須)
POST /mcp
Mcp-Session-Id: 1868a90c-3a3f-4f5b
{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

2026-07-28仕様では、これが1回のHTTPリクエストに集約されました。セッションIDの発行と受け渡しが不要になり、クライアント情報は_metaフィールドの中に含める形に変わっています。

POST /mcp
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app"}}}}

この変更は単なるリクエスト削減にとどまりません。サーバー側がセッションIDとバックエンドプロセスの対応関係を保持する必要がなくなり、どのリクエストもどのサーバーインスタンスが受けても処理できる、いわゆるステートレス(状態を持たない)な設計に近づいたことが本質です。

なぜこれがML基盤の設計に効いてくるのか

Webバックエンドの設計経験がある方なら、ステートフルなセッション管理の面倒さには覚えがあるはずです。ロードバランサーの「スティッキーセッション」(同じクライアントを同じサーバーに固定する仕組み)や、Redisなどにセッション情報を外出しする構成は、スケールする際にほぼ必ず必要になっていました。

レガシーMCPのサーバー実装は、まさにこの問題を抱えていました。セッションIDをキーにサーバー側の状態(接続中のツール一覧やコンテキストなど)を保持する必要があり、水平スケール時にはどのインスタンスが該当セッションを持っているかをルーティングする仕組みが要りました。

ステートレスMCPでは、この状態管理コストがまるごと消えます。Kubernetes上でMCPサーバーをオートスケールする構成や、サーバーレス関数(AWS LambdaやCloud Run)としてMCPツールをデプロイする構成とも相性が良くなります。エージェント基盤をマイクロサービス化して複数チームでツールを分担運用するような設計では、この単純化の恩恵は特に大きくなります。

もう一つの角度は、モデルの選定に関わる部分です。エージェントにターミナルとcurlを渡して自由に操作させる方式は、強力なモデル(推論能力の高いフロンティアモデル)でないとうまく運用できません。一方でMCPツールは呼び出せる操作があらかじめ定義されているため、ローカルPCで動く比較的小さなモデルでも扱いやすいという特性があります。監査のしやすさ(どのツールが何回呼ばれたかをログで追いやすい)という観点でも、無制限なシェルアクセスより統制が効きます。

実際に動かして確認する方法

MCPサーバーの挙動を手元で確認したい場合、Pythonのuvxコマンド(uvが提供する、インストール不要でPythonツールを実行できる仕組み)を使ったCLIツールで検証できます。

# MCPサーバーが公開しているツール一覧を取得
uvx mcp-explorer list https://agentic-mermaid.dev/mcp

# 特定ツールの入出力スキーマを確認
uvx mcp-explorer inspect render_svg

# 実際にツールを呼び出す
uvx mcp-explorer call \
  https://agentic-mermaid.dev/mcp \
  render_svg \
  -a source 'graph TD; A-->B' \
  -a options '{"padding":24}'

listサブコマンドを実行すると、ツール名・引数のシグネチャ・説明文がまとめて返ってきます。JSON Schema(入出力の型を定義する仕様)で定義された引数が読めるため、実装済みのMCPサーバーがどんな操作を公開しているか、コードを読まずに把握できます。

自分のプロジェクトが今回の変更の影響を受けるかどうかは、まずMCPクライアント・サーバーそれぞれのライブラリのバージョンと、対応しているプロトコルバージョン文字列を確認するところから始めます。リクエストヘッダーのMCP-Protocol-Versionに2026-07-28が指定できるか、逆にinitializeハンドシェイクを前提にした自前のセッション管理コードが残っていないかを見直す価値があります。

もし独自にMCPサーバーを実装している場合、セッションIDに紐づけて状態を保持しているコードがあれば、それがレガシー仕様への依存箇所です。ステートレス仕様への移行では、そうしたセッション状態をリクエストの_meta情報や、呼び出しごとに完結するステートレスな設計に置き換えられるかどうかが検討ポイントになります。

押さえておきたいポイント

MCPのステートレス化は、RPC(遠隔手続き呼び出し)の設計として見ると、gRPCやREST APIが長年採用してきた「1リクエスト1完結」の考え方にMCPが追いついた変更とも言えます。

セッションIDによる状態管理が不要になったことで、MCPサーバーはロードバランサー配下でのスケールがしやすくなり、監査もしやすい統制されたツール呼び出しとして、小規模モデルでも運用しやすい選択肢になりました。

今日から確認できることとしては、次の3点が挙げられます。

利用中のMCPクライアント・サーバーライブラリが2026-07-28のプロトコルバージョンに対応しているか、リリースノートやCHANGELOGを確認する
自前実装のMCPサーバーにセッションID依存のコードが残っていないか、initializeハンドシェイクの扱いを見直す
uvx mcp-explorerのようなCLIツールで、実際に公開ツールの一覧・スキーマ・呼び出し結果を手元で確認してみる

エージェント基盤にツールを追加する設計を検討している段階なら、シェルアクセス型とMCP型のどちらが自分のユースケースに合うか、モデルの能力と監査要件の両面から比較しておくと、後々の設計変更コストを抑えられます。