MCP「2026-07-28」仕様公開——ステートレス化でAIエージェント接続が激変

MCP「2026-07-28」仕様公開——ステートレス化でAIエージェント接続が激変

要点: Model Context Protocol（MCP）の新仕様「2026-07-28」が2026年7月28日に正式公開され、従来の双方向ステートフル設計から、各リクエストが自己完結する「リクエスト/レスポンス型ステートレス」設計へと根本的に転換しました。共有セッションストアやスティッキーセッションが不要になり、ロードバランサー経由の任意サーバーやサーバーレス・エッジ環境へのMCPサーバーデプロイが現実的になります。AnthropicはClaudeへの本仕様統合を発表しており、MCPサーバーを持つこと自体がGEO/LLMO対策の新しい選択肢として、より多くの企業にとって現実的になりました。

最終更新日: 2026年7月29日

何が起きたのか

MCPとは何か——AIエージェントと外部ツールをつなぐ標準プロトコル

Model Context Protocol（MCP）は、Claude・ChatGPT・Perplexity Computer・GeminiといったAIエージェントが外部のツール・データソース・APIに接続するためのオープンな標準プロトコルである。AIエージェントが「検索する」「回答を生成する」だけでなく、外部システムに実際にアクセスして情報を取得したり、タスクを代行実行したりする際の共通言語として機能してきた。Anthropicが公開しているデータによれば、Claudeだけで現在950以上のMCPサーバーが提供されており、AIエージェントのエコシステムにおいてMCPはすでに事実上の標準として定着している。

「2026-07-28」仕様は何を変えたのか——ステートフルからステートレスへ

Model Context Protocol Blogが2026年7月28日に公開した記事「The 2026-07-28 Specification」によれば、今回のアップデートはMCP史上最大の仕様変更にあたる。従来のMCPは「双方向ステートフル」プロトコルとして設計されていた。クライアントとサーバーはinitialize/initializedという一連のハンドシェイクを経てセッションを確立し、その後はMcp-Session-Idヘッダーによってセッション状態を維持し続ける必要があった。これはローカル環境で単一のクライアントと単一のサーバープロセスが1対1で通信する用途には適していたが、複数のサーバーインスタンスにリクエストを分散させたい、あるいはサーバーレス関数のように毎回異なる実行環境でリクエストを処理したいという分散システムの要求とは相性が悪かった。

新仕様「2026-07-28」では、この設計が「リクエスト/レスポンス型ステートレス」プロトコルへと転換された。各リクエストは自己完結した情報を持つように変更され、プロトコルバージョン・クライアント識別情報・機能（capabilities）情報といった、これまでハンドシェイクやセッション状態として保持されていた情報は、リクエストごとに付与される_metaフィールドに含められるようになった。Tech Timesの報道（2026年7月27日付）でも、この変更は「セッション」という概念そのものをプロトコルの中核から取り除くものとして報じられており、MCP誕生以来最大の設計変更と位置づけられている。

この変更が実務上どのような意味を持つかは明確だ。従来はセッションIDに紐づく状態を保持するために、サーバー側でRedisなどの共有セッションストアを用意し、同一クライアントからのリクエストは常に同じサーバーインスタンス（あるいは同じ状態を参照できるインスタンス）で処理される「スティッキーセッション」を組む必要があった。新仕様ではリクエストごとに必要な情報が自己完結しているため、こうした仕組みが不要になる。任意のサーバーインスタンスが、単純なラウンドロビン方式のロードバランサー経由でリクエストを処理できるようになる。これにより、MCPサーバーをKubernetesのようなオーケストレーション環境や、Cloudflare WorkersやAWS Lambdaのようなサーバーレス・エッジインフラにデプロイすることが、設計上自然な選択肢になった。

必要に応じて、クライアントは新しく追加されたserver/discoverというRPCを用いて、実際にツール呼び出しを行う前にサーバーの機能を事前に発見できるようになっている。ハンドシェイクという固定の手順を踏まなくても、必要なタイミングで必要な情報だけを取得できる設計だ。

Multi Round-Trip Requests（MRTR）——確認や追加情報が必要な場合の新方式

ステートレス化に伴い、従来のセッションを前提とした「対話的なやり取り」をどう表現するかという課題が生じる。これに対応するのが、新仕様で導入された「Multi Round-Trip Requests（MRTR）」という仕組みだ。サーバー側がユーザーの確認や追加のパラメータ入力を必要とする場合、通常の結果を返す代わりにresultType: "input_required"という応答を返す。クライアント側はこれを受けて、必要な情報をユーザーから収集した上でinputResponsesとしてサーバーに送り返す。セッションという継続的な接続状態に頼らずに、複数回のやり取りを要する処理を実現する仕組みとして設計されている。

ヘッダベースルーティングとキャッシュ対応レスポンス

分散環境での運用を前提とした改良は他にもある。1つは「ヘッダベースルーティング」だ。Mcp-Method・Mcp-Nameという専用のHTTPヘッダーが新設され、ゲートウェイやプロキシがリクエストのJSONボディを解析しなくても、どのメソッド・どのツールへのリクエストかをヘッダー情報だけで判別し、適切な宛先へルーティングできるようになった。JSONボディのパースはCPUコストがかかる処理であり、大量のリクエストを捌くゲートウェイにとってこの変更は運用効率に直結する。

もう1つは「キャッシュ対応レスポンス」だ。tools/listのような、比較的更新頻度の低い情報を返すレスポンスに対して、ttlMs（キャッシュの有効期間をミリ秒で指定）とcacheScope（キャッシュの適用範囲）という属性が付与されるようになった。クライアント側はこの情報を使って、同じ問い合わせを毎回サーバーに送るのではなく、一定期間はローカルにキャッシュした結果を再利用するといった最適化戦略を組み立てられるようになる。

Tasks拡張——非同期の長時間実行操作を正式にサポート

これまで実験的なコア機能として位置づけられていた非同期タスクの仕組みは、新仕様でio.modelcontextprotocol/tasksという正式な拡張（Extension）に昇格した。MCPは元々、Extensions Frameworkという形で、コアプロトコルに含めるべきか判断が難しい機能を正式な拡張として独立管理できる仕組みを持っている。Tasks拡張はその枠組みの中で、ポーリングベースのtasks/getと、新たに追加されたtasks/updateという2つの操作をサポートする。画像生成やレポート作成、大規模なデータ処理など、即座にレスポンスを返せない長時間実行の操作を、ステートレスなリクエスト/レスポンス型のプロトコルの上でどう扱うかという課題に対する回答がこのTasks拡張だ。クライアントは処理の開始をリクエストした後、tasks/getで進捗を定期的にポーリングし、完了時に結果を取得する。

MCP Apps拡張——サーバー定義のインタラクティブUIをチャット内にレンダリング

もう1つの正式拡張が「MCP Apps」だ。これは、MCPサーバー側が定義したインタラクティブなHTML UIを、チャットインターフェース内でサンドボックス化した状態でレンダリングする仕組みを整備するものだ。従来のMCPはテキストベースのツール呼び出し・レスポンスが中心だったが、MCP Appsによって、たとえば予約フォームやダッシュボードのような対話的なUI要素をAIエージェントとの会話の中に直接埋め込むことが、標準化された形で可能になる。

認可（Authorization）の強化——RFC 9207準拠とCIMDへの移行

セキュリティ面では、認可の仕組みが大きく強化された。まず、RFC 9207（OAuth 2.0 Authorization Server Issuer Identification）に基づくissuer検証が必須化された。これにより、認可サーバーのなりすましやトークンの誤った宛先への送出といったリスクへの対策が標準として組み込まれる。

クライアント登録の方式についても変更があり、これまでのDynamic Client Registration（DCR）から、Client ID Metadata Documents（CIMD）への移行が進められている。あわせて、OAuth 2.1およびOpenID Connectへの準拠が必須化された。エンタープライズ利用を意識した拡張として、Enterprise Managed Authorization（EMA）という拡張も新たに追加されており、Microsoft EntraやOktaといった企業向けID基盤との連携を簡素化することを目的としている。

非推奨機能——Roots・Sampling・Loggingとレガシートランスポート

今回の仕様改定で、Roots・Sampling・Loggingという3つの機能が非推奨（deprecated）となった。ただし、これらは即座に廃止されるわけではなく、「最低12ヶ月」は動作し続けることが保証されている。最短の削除時期は2027年7月であり、既存のMCPサーバー・クライアント開発者には計画的な移行のための猶予期間が設けられている。あわせて、従来のレガシーHTTP+SSE（Server-Sent Events）トランスポートについても、正式に非推奨として扱われることになった。

各SDKの対応状況とAnthropic/Claudeの対応

新仕様への対応状況について、TypeScript・Python・Go・C#のTier 1 SDKはすでに2026-07-28仕様に対応済みであることが確認されている。Rust SDKについてはベータという位置づけで対応が進められている。

Anthropicは自社ブログ「MCP 2026-07-28 spec: stateless core, coming to Claude」で、この新仕様をClaudeに統合していく方針を発表した。前述の通りClaudeは現在950以上のMCPサーバーを提供しているが、新仕様への対応にあわせて、チャット内に対話的なUIを直接レンダリングするMCP Apps、管理者が組織全体でコネクタを一括プロビジョニングできるエンタープライズ認証機能、MCPサーバーの利用状況を可視化する可観測性ダッシュボード、そしてプライベートネットワーク内のツールへ安全にアクセスするための「MCPトンネル」といった機能が新たに追加される予定だ。Anthropicはこれらのサポートを「近日中にClaudeプロダクト全体で展開予定」としている。

仕様策定の経緯——Agentic AI Foundation（AAIF）による解説

今回の仕様変更の技術的背景を詳しく解説しているのが、Agentic AI Foundation（AAIF）だ。AAIFのブログ記事「MCP 2026-07-28: From Local Tool to Distributed Protocol」では、MCPが当初「ローカルで動くツール」としての性格が強かったのに対し、今回の仕様改定によって「分散システムの一部として設計されたプロトコル」へと役割を拡張したと位置づけている。AAIFは別記事「MCP Is Growing Up」でも、MCPというプロトコルがプロトタイプ的な段階から、エンタープライズの本番運用に耐える基盤へと成熟していくプロセスを論じている。今回のリリース候補版は2026年5月に公開され、コミュニティからのフィードバックを経て、2026年7月28日に最終版として正式リリースされた。

aiseo-llmo.com ユーザーへの影響

MCPサーバー保有がGEO/LLMO対策の新しい選択肢になった

これまでのLLMO/GEO対策は、主に「AIの回答テキストにどう引用・推薦されるか」という観点に軸足を置いてきた。構造化データの整備、FAQ形式のコンテンツ設計、専門性の高い一次情報の提供などは、いずれもAIが検索・生成の過程で自社コンテンツを「読んで引用する」ことを前提にした施策だ。

しかし、Claude・ChatGPT・Perplexity Computer・GeminiのようなAIエージェントが外部ツールに接続してタスクを代行実行する動きが急速に広がる中で、「AIエージェントが自社サイト・自社APIをツールとして直接呼び出し、ユーザーに代わって予約や検索、比較、購入手続きといったタスクを実行できるか」という、従来とは異なる戦場が生まれつつある。これは本サイトで以前取り上げたAI Mode・Gemini 3・MCP標準化が変える検索の未来と2026年の対策や、A2Aプロトコル時代にAIエージェントへ自社を発見させる準備【2026年版】でも指摘してきた「エージェント経由の発見・実行」という論点そのものだ。

今回の「2026-07-28」仕様によるステートレス化・サーバーレス対応・キャッシュ対応・非同期タスクの標準化（Tasks拡張）は、企業が自社のMCPサーバーを構築・運用する際のハードルを技術的に引き下げるものだ。従来はセッション状態を保持するための共有ストア（Redisなど）を用意し、スティッキーセッションを前提としたインフラ構成を組む必要があった。ステートレスな新仕様であれば、Cloudflare WorkersやAWS Lambdaのようなサーバーレス環境、あるいはKubernetes上でオートスケールするコンテナ群といった、より一般的でコストを抑えやすいインフラ構成の上でMCPサーバーを運用できる。これは、これまで「MCPサーバーを持つほどのエンジニアリングリソースはない」と考えていた中堅・中小規模の企業にとっても、「自社のツール・データをMCPサーバーとして公開し、AIエージェントから直接呼び出してもらう」という選択肢を、より現実的なコストで検討できるようになったことを意味する。

既存にMCPサーバーを持つ企業・開発者への影響

一方で、すでに自社のMCPサーバーを構築・運用している企業やチームにとって、今回の仕様改定は無視できない移行対応を伴う。第一に、旧来のステートフル設計（initialize/initializedハンドシェイクやMcp-Session-Idによる状態管理）に依存したコードは、新仕様のステートレス設計とは前提が異なるため、セッション依存のロジックがどこにどれだけ存在するかの棚卸しが必要になる。第二に、Roots・Sampling・Loggingという3機能が非推奨になったことで、これらの機能に依存した実装を持つサーバー・クライアントは、最短で2027年7月までに代替手段への移行を計画する必要がある。「最低12ヶ月」の猶予があるとはいえ、移行作業自体は決して軽くないため、早期の棚卸しが望ましい。第三に、認可周りの変更（RFC 9207準拠のissuer検証必須化、DCRからCIMDへの移行、OAuth 2.1・OpenID Connect準拠の必須化）は、企業がAIエージェント向けにAPIアクセスを提供する際の認証基盤の見直しを迫るものであり、特にエンタープライズ向けにコネクタを提供している企業にとっては優先度の高い対応事項になる。

業種別の実務インパクト

• EC・小売: 商品検索・在庫確認・注文処理といったAPIをMCPサーバーとして公開する動きが今後広がりやすい業種だ。ステートレス化によりサーバーレス環境での運用が容易になったことで、トラフィックの繁閑差が大きいEC事業者にとっては、常時稼働のインフラを維持するコストを抑えながらAIエージェント経由の注文・比較検討フローに対応できる可能性がある。
• SaaS・BtoBソフトウェア: 自社製品のAPIをMCPサーバーとして公開し、ユーザーがClaudeやChatGPTのようなAIエージェント経由で自社ツールを操作できるようにする動きは、SaaS業界ではすでに一定数見られる。エンタープライズ顧客を持つSaaS事業者にとっては、今回追加されたEnterprise Managed Authorization（EMA）拡張により、顧客企業のEntra/Oktaなどと連携した認可フローを組みやすくなる点が実務上のメリットになりうる。
• メディア・パブリッシャー: 記事コンテンツや検索機能をMCPサーバーとして提供する動きはまだ発展途上だが、Tasks拡張による非同期処理の標準化は、AIエージェントが「大量の記事を横断的に調査してレポートを作成する」ような長時間実行タスクをメディア側のサーバーに依頼する際の基盤になりうる。
• BtoB企業（見積もり・問い合わせ対応など）: MRTR（Multi Round-Trip Requests）の標準化により、「AIエージェントがユーザーに代わって見積もり条件を確認しながら手続きを進める」といった、複数回のやり取りを要する業務プロセスをMCPサーバー側で表現しやすくなった。問い合わせ対応や見積もり業務をAIエージェント経由で受け付けたい企業にとっては、実装の選択肢が広がったといえる。

いずれの業種においても、MCPサーバーを持つこと自体が直接的にAI検索での引用順位を上げるわけではない点には注意が必要だ。今回の変更が意味するのは、あくまで「MCPサーバーの構築・運用コストが下がったことで、AIエージェントに自社サービスを直接呼び出させるという選択肢の実現可能性が上がった」ということであり、GEO/LLMO対策全体における位置づけは、既存の構造化データ整備やコンテンツ最適化と並ぶ「もう一つの選択肢」として理解するのが妥当だ。

今すぐできる対応策

これからMCPサーバー構築を検討する企業向けチェックリスト

1. 自社のどの機能をツール化する価値があるか棚卸しする: 商品検索、在庫確認、予約受付、見積もり計算など、AIエージェントに代行実行させる価値のある業務プロセスを洗い出す。すべての機能をMCP化する必要はなく、ユーザーが繰り返し行う定型的な操作から優先的に検討するのが現実的だ。
2. ステートレス設計を前提にインフラを検討する: 新仕様がステートレスを前提としている以上、これから構築するMCPサーバーは最初からステートレス設計で作ることが望ましい。サーバーレス環境（Cloudflare Workers、AWS Lambdaなど）やコンテナベースのオートスケール構成など、リクエストごとに独立して処理できるインフラを検討する。
3. Tier 1 SDK（TypeScript / Python / Go / C#）から選定する: 2026-07-28仕様に対応済みのTier 1 SDKを使えば、新仕様に準拠したサーバーを最初から構築できる。自社の既存スタックとの親和性を踏まえてSDKを選ぶ。
4. 認可周りをOAuth 2.1・OpenID Connect準拠で設計する: 新仕様で必須化されたRFC 9207準拠のissuer検証、CIMDベースのクライアント登録を前提に認可フローを設計する。エンタープライズ顧客への提供を見据える場合は、EMA拡張によるEntra/Okta連携も検討する。
5. 非同期処理が必要な機能はTasks拡張を活用する: 即座にレスポンスを返せない処理（大量データ処理、レポート生成など）がある場合、独自の非同期処理を実装するのではなく、標準化されたTasks拡張（tasks/get・tasks/update）を利用することで、クライアント側との互換性を確保しやすくなる。
6. tools/list等のキャッシュ戦略を設計時から組み込む: ttlMs・cacheScopeを適切に設定することで、クライアント側の不要な問い合わせを減らし、サーバー負荷とレイテンシの両方を抑えられる。

既存にMCPサーバーを運用している場合の移行手順

1. セッション依存コードの棚卸し: initialize/initializedハンドシェイクやMcp-Session-Idヘッダーに依存した実装がどこにあるかをコードベース全体で洗い出す。共有セッションストア（Redisなど）への依存箇所、スティッキーセッションを前提としたロードバランサー設定も対象に含める。
2. 非推奨機能（Roots・Sampling・Logging）の利用箇所を洗い出す: 自社サーバー・クライアントの実装がこれら3機能にどの程度依存しているかを確認する。「最低12ヶ月」の猶予（最短削除時期2027年7月）があるとはいえ、代替手段への移行計画を早期に立てておくことが望ましい。
3. 段階的な移行計画を立てる: 新仕様と旧仕様を一定期間並行運用しながら、クライアント側の対応状況を見ながら段階的に移行するアプローチが現実的だ。SDKが新仕様に対応していることを確認した上で、まずは新規機能から新仕様準拠で実装し、既存機能を順次移行していく進め方が考えられる。
4. 認可基盤の見直し: DCRからCIMDへの移行、OAuth 2.1・OpenID Connect準拠への対応状況を確認する。特にエンタープライズ顧客向けにコネクタを提供している場合は、EMA拡張の導入検討も含めて優先度を上げて対応する。
5. レガシーHTTP+SSEトランスポートからの移行: 正式に非推奨となったレガシートランスポートを使い続けている場合、新しいトランスポート方式への移行スケジュールを検討する。

GEO/LLMO担当者としての視点

MCPサーバーの技術的な構築・運用は主にエンジニアリングチームの領域だが、GEO/LLMO担当者としては、自社がMCPサーバーを持つべきかどうかの意思決定に関与する視点を持っておくことが重要になる。具体的には、自社の検索流入・問い合わせ・購入プロセスのうち、AIエージェントに代行実行させる価値のあるものは何かを整理し、エンジニアリングチームと共有すること、そして既存の構造化データ・コンテンツ最適化施策との優先順位をどう配分するかを経営層・開発チームと議論することが、実務上の第一歩になる。

よくある質問

Q1. MCPの「2026-07-28」仕様とは何ですか？

Model Context Protocolの新しい正式仕様で、2026年7月28日に公開されました。従来の双方向ステートフル設計から、各リクエストが自己完結するステートレス設計へと根本的に転換した、MCP史上最大の仕様変更です。

Q2. ステートフルからステートレスへの転換で何が変わりましたか？

従来はinitialize/initializedハンドシェイクとMcp-Session-Idヘッダーでセッション状態を管理していましたが、新仕様ではプロトコルバージョンやクライアント情報を各リクエストの_metaフィールドに含める形になりました。これにより共有セッションストアやスティッキーセッションが不要になり、任意のサーバーインスタンスがロードバランサー経由でリクエストを処理できます。

Q3. なぜステートレス化がサーバーレス・エッジ環境へのデプロイを可能にするのですか？

サーバーレス関数は基本的に呼び出しごとに独立した実行環境で処理されるため、継続的なセッション状態の保持を前提とする設計とは相性が悪いためです。各リクエストが自己完結するステートレス設計であれば、Cloudflare WorkersやAWS Lambdaのような環境でも自然にMCPサーバーを動かせます。

Q4. Multi Round-Trip Requests（MRTR）とは何ですか？

サーバーがユーザーの確認や追加パラメータを必要とする場合に、resultType: "input_required"という応答を返し、クライアントがinputResponsesで回答を送り返す新しい仕組みです。ステートレスなプロトコル上で、複数回のやり取りを要する対話的な処理を実現します。

Q5. Tasks拡張とは何ですか？

非同期の長時間実行操作を扱うための正式な拡張（io.modelcontextprotocol/tasks）です。ポーリングベースのtasks/getと新しいtasks/updateをサポートしており、従来は実験的なコア機能だったものが、この仕様改定で正式拡張に昇格しました。

Q6. 非推奨になった機能はいつまで使えますか？

Roots・Sampling・Loggingの3機能は非推奨になりましたが、最低12ヶ月は動作し続けることが保証されています。最短の削除時期は2027年7月とされており、計画的な移行が可能です。レガシーHTTP+SSEトランスポートも正式に非推奨となりました。

Q7. AnthropicはClaudeにこの新仕様をどう反映しますか？

Anthropicは2026-07-28仕様をClaudeに統合すると発表しています。チャット内に対話的なUIを直接レンダリングするMCP Apps、組織全体でコネクタを一括プロビジョニングできるエンタープライズ認証、可観測性ダッシュボード、プライベートネットワーク内ツールへの安全なアクセスを実現するMCPトンネルなどが追加される予定で、サポートは近日中にClaudeプロダクト全体で展開予定とされています。

Q8. MCPサーバーを持つことはGEO/LLMO対策として有効ですか？

MCPサーバーを持つこと自体が直接的にAI検索での引用順位を上げるわけではありませんが、「AIエージェントが自社サイト・APIをツールとして直接呼び出し、タスクを代行実行できるか」という新しい戦場において、選択肢を持てることを意味します。今回のステートレス化・サーバーレス対応により構築・運用のハードルが下がったため、より多くの企業にとって現実的な選択肢になったと言えます。

Q9. 既にMCPサーバーを運用している場合、何から手をつければよいですか？

まずセッション依存コード（initialize/initializedハンドシェイクやMcp-Session-Idヘッダーへの依存箇所）を棚卸しし、次に非推奨機能（Roots・Sampling・Logging）の利用状況を確認することが優先です。あわせて認可基盤（RFC 9207準拠のissuer検証、CIMDへの移行、OAuth 2.1・OpenID Connect準拠）の見直しも計画に含める必要があります。

Q10. どのSDKが2026-07-28仕様に対応していますか？

TypeScript・Python・Go・C#のTier 1 SDKはすでに対応済みです。Rust SDKはベータという位置づけで対応が進められています。これからMCPサーバーを構築する場合は、対応済みのTier 1 SDKから選定するのが現実的です。

関連記事

• LLMO完全ガイド——AI検索時代の最適化戦略の全体像
• AI検索最適化（AIO/LLMO）完全ガイド
• AI Mode・Gemini 3・MCP標準化が変える検索の未来と2026年の対策
• A2Aプロトコル時代にAIエージェントへ自社を発見させる準備【2026年版】
• Perplexity Computerとは？マルチモデルAIエージェントの実像とLLMOへの影響
• llms.txtは必要か不要か？Google公式見解とエージェントコマースの結論
• 用語集: LLMO（大規模言語モデル最適化）
• 用語集: GEO（生成エンジン最適化）
• 用語集: AIO（AI Overviews）
• 用語集: グラウンディング（Grounding）
• Perplexity「Personal Computer」Windows対応——検索からエージェント基盤へ
• ChatGPT Adsに新広告「ビジネスエージェント会話広告」判明——クリックでAI会話へ