そもそもMCPとは何か

MCP（Model Context Protocol）は、LLMアプリケーションと外部システムをつなぐための共通プロトコルだ。MCP自体がLLMなのではなく、AIアプリケーションが外部の操作やデータを発見し、呼び出すための接続規格である。

中心となるPrimitiveは、AIが実行できる操作を表す tools、読み取れるデータを表す resources、再利用可能なプロンプトを表す prompts である。MCPはJSON-RPC 2.0をメッセージ形式の基礎としている。

Function Callingが「モデルがどの関数をどんな引数で選ぶか」を扱うのに対し、MCPは「その機能をどう公開し、発見し、認証し、呼び出すか」を標準化する。Host、Client、Serverという責務分担も、この接続層を実装するためのものだ。

最大の変更：StatefulからStatelessへ

2025年までのMCPでは、Clientが最初に initialize を送り、ServerのCapabilityとVersionを確認し、notifications/initialized で初期化完了を通知した。Streamable HTTPでは Mcp-Session-Id を使って、その後の通信を同じセッションに結びつけることもできた。

2026-07-28 では、initialize / initialized と Mcp-Session-Id が廃止された。各リクエストの _meta に、Protocol Version、Client情報、Client Capabilityを載せる。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": { "q": "example" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

その結果、あるClientの連続したリクエストを同じServer Instanceへ固定する必要がなくなった。普通のround-robin Load Balancerの背後に複数のMCP Serverを置き、どのインスタンスでも処理できる。Remote MCPをCloud Run、Lambda、Workers、Kubernetesなどで運用する際、sticky sessionやセッション共有ストアへの依存を減らせる。

Discoveryはserver/discoverへ

初期化ハンドシェイクがなくなった代わりに、Serverは server/discover を実装する。Clientはこれを呼べば、対応VersionやCapabilityを先に確認できる。ただし、Clientが必ず最初に呼ぶ必要はない。いきなり tools/list や tools/call を送ることもできる。

対応していないVersionなら、Serverは対応Versionを含む UnsupportedProtocolVersion 系のエラーを返せる。Clientはその情報を使い、旧Versionへフォールバックできる。つまりVersion Negotiationは「接続開始時の一度きりの儀式」から「個々のRequestと通常のエラー処理」へ移った。

Streamable HTTPが普通のHTTP基盤に近づいた

Streamable HTTPは、単一のMCP endpointに対するPOSTが基本になった。2025-eraに存在した独立したGET stream endpointとprotocol-level sessionは削除された。Responseは単一JSON、またはそのRequestに閉じたSSE streamとして返る。

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

Mcp-Method と Mcp-Name がHTTP Headerに現れることで、GatewayがJSON bodyを深く解析せずに操作を識別できる。Tool単位のrouting、rate limit、ACL、audit、metrics、WAF ruleを既存のHTTP Infrastructureで構築しやすくなった。

Server→Client RPCをMRTRへ置き換える

旧MCPには、処理途中でServerからClientへ elicitation/create、sampling/createMessage、roots/list を送る仕組みがあった。しかしServer-initiated requestは、開いたままの双方向streamを必要とする。

2026-07-28のMRTR（Multi Round-Trip Requests）は、これを複数回の通常Request/Responseへ分解する。Serverが追加情報を必要とすると、resultType: "input_required" と inputRequests を返す。ClientはユーザーやHostから回答を得て、元と同じ操作を inputResponses 付きで再送する。

Resultは complete か input_required かを明示するため、Hostは処理をState Machineとして扱いやすい。重要なのは、ServerがClientへ逆向きRPCを開始するのではなく、Clientが常に次のRequestを主導する点である。

短い対話はMRTR、長い処理はTasks

MRTRは確認や不足パラメータの補完に向く。一方、動画生成、大規模分析、デプロイ、巨大Repository解析のようにすぐ終わらない処理はTasks Extensionが担当する。

Tasksは2025-11-25ではexperimentalなCore機能だったが、2026-07-28では io.modelcontextprotocol/tasks という公式Extensionへ移った。新しいLifecycleではServerがTask化を判断し、Clientが tasks/get で状態を取得する。Sessionなしでは安全にscopeを定めにくい tasks/list は削除された。

変更通知も、旧HTTP GET endpoint上の自由な通知ではなく、Clientが通知種別を選んで接続する subscriptions/listen streamへ整理された。

小さなCoreと独立して進化するExtensions

2026-07-28では、Coreに機能を増やし続けるのではなく、任意機能をExtensionsへ切り出す仕組みが正式化された。Extensionはreverse-DNS形式のIDを持ち、ClientとServerのCapability内にある extensions mapで対応を広告し、Core Specificationとは独立してVersion管理できる。

公式Extensionには、長時間処理を扱うTasks、会話内にsandboxed iframeのInteractive HTML UIを表示するMCP Apps、Enterprise Managed Authorizationなどがある。MCP AppsではToolがUI templateを事前宣言し、Hostがprefetch、cache、security reviewを行える。UIからの操作もHostを通るため、直接のTool Callと同じ監査・同意経路に乗せられる。

これはMCPが「AIからAPIを呼ぶ規格」だけでなく、「AI Applicationと外部Applicationを統合する基盤」へ広がっていることを示している。

Cache HintがProtocolに入った

tools/list、prompts/list、resources/list、resources/read、resources/templates/list などのcache可能なResultには、ttlMs と cacheScope が加わった。Clientは「いつまで再取得しなくてよいか」「認証Contextをまたいで共有できるか」をServerのHintに基づいて判断できる。

List Resultにはdeterministicな順序も求められる。同じTool集合でも順番が毎回変わると、LLMへ渡すPrompt Prefixも変わり、Prompt Cacheのhit率を下げる可能性がある。安定したTool Listは、Network CacheだけでなくLLM側のCache効率にも寄与する。

OAuthはWeb標準へさらに揃えられた

MCP Serverは引き続きOAuth Resource ServerとしてAccess Tokenを検証し、Authorization Serverは別に置ける。2026-07-28では、実運用で重要な次のhardeningが入った。

• RFC 9207に従い、Authorization Responseの iss を検証し、Authorization Server mix-up attackを防ぐ。
• Client Credentialを発行元Issuerに結びつけ、別のAuthorization Serverへ使い回さない。
• Dynamic Client Registration（DCR）をdeprecatedとし、Client ID Metadata Documents（CIMD）を標準的な方向とする。

DCRは互換性のため現時点で動作するが、新規実装が依存すべき設計ではない。MCP独自のOAuth運用を増やすより、OAuth・OIDC ecosystemの標準的なDiscoveryとMetadataへ寄せる流れである。

Deprecatedになった機能

Roots、Sampling、Loggingは2026-07-28でdeprecatedになった。ただし即時削除ではなく、このVersionではWire behaviorも型もCapabilityも残る。正式なLifecycle Policyにより、deprecatedから削除可能になるまで最低12か月の期間が設けられる。

さらにToolの inputSchema と outputSchema はJSON Schema 2020-12へ拡張された。入力は引き続きobjectをrootとするが、oneOf、anyOf、allOf、条件、$ref、$defs などを利用できる。structuredContent もobjectだけでなく任意のJSON valueを扱える。

旧MCPとの差分を一枚で確認する

実装・移行時のチェックリスト

公式Tier 1 SDKであるTypeScript、Python、Go、C#は2026-07-28に対応している。ただし、後方互換やdefault negotiationの挙動はSDKごとに異なり得るため、「SDKをv2へ上げたから自動的に新Protocolだけを話す」と決めつけない方がよい。

まとめ

MCP 2026-07-28を一言で表すなら、「AI向けの状態を持つ双方向Session Protocol」から「AI向けに拡張されたStateless Web Protocol」への再設計である。

実務上の効果は明確だ。Session共有なしで水平scaleしやすくなり、既存のLoad BalancerやGatewayを活用でき、HeaderだけでTool単位のRouting・認可・観測ができる。一方、双方向RPCや暗黙のSession Stateに依存していた実装は、MRTR、Tasks、明示的なHandleへ考え直す必要がある。

今回の変更は単なるAPI追加ではない。Remote MCPを特殊な常時接続基盤から、通常のWeb Infrastructureに自然に置けるProtocolへ変えるものだ。この設計思想を掴むことが、個々の差分を暗記するより重要である。