MCP 2026-07-28 スペックリリース：ステートレスコアへの大きな移行

iconMetaEra
共有
AI summary icon概要
KuCoinは、MCP 2026-07-28のリリースにより、ステートレスなコア設計への大規模なプロトコル更新を発表しました。新しい仕様ではセッションベースのインタラクションを削除し、インフラコストを削減してスケーラビリティを向上させます。エンタープライズ認証のためにOAuth 2.0およびOIDCのサポートが追加され、公式拡張フレームワークも導入されました。開発者は破壊的変更のため移行が必要です。この更新には新たなトークン上場も含まれ、トレーダーの選択肢が拡大します。
MCPはもはやメーカーのプラグインインターフェースのようには見えず、公共のパイプのように見え始めている。パイプはより頑強になるが、より大人しくなるだろう。

記事執筆者、出典：0x9999in1、ME News



要約

  • 2026 年 7 月 28 日，MCP 发布第五版规范 2026-07-28、プロトコル誕生以来最大規模の改訂と公式に位置づけられた。核心的な変更は一つだけ：プロトコル層のセッションを削除すること。
  • initialize/initialized 握手没了，Mcp-Session-Id 请求头没了。每个请求自带协议版本、客户端身份和能力声明，写在 _meta 里。任何请求可以落在任何一台实例上，一个普通的轮询负载均衡就够。
  • これはパフォーマンスの最適化ではなく、アーキテクチャの誤りです。スタイクセッションと共有セッションストレージは、MCPサーバーのスケール時に最も高額なコストの一部でした。
  • 状態は消えていない。それはトランスポート層からツールパラメータに移され、「明示的なハンドル」と呼ばれるようになった。モデルはそれを認識でき、制御できる。
  • インタフェース（MCP Apps）と長時間タスク（Tasks）がバージョン管理拡張フレームワークに正式に統合され、コアプロトコルは新たな機能の追加による肥大化を避けます。認証はリアルワールドのOAuth 2.0およびOIDCに準拠し、エンタープライズ向けホスト型認可拡張も同日安定版に移行しました。
  • 実際の資金がかかるコストです：これは breaking change です。Roots、Sampling、Logging と従来の HTTP+SSE 伝送が一斉に非推奨となり、公式には少なくとも 12 か月の移行期間が与えられています。
  • 一言で言えば：MCPはもはやメーカーのプラグインインターフェースではなく、公共のパイプのように見え始めている。パイプはより頑丈になるが、より大人しくなるだろう。

一、削除された那两行が、今回の改版の重みである

まず、直感に反する事実をお伝えします。

今回「史上最大のアップデート」と呼ばれる更新で、最も重要な部分は追加されたものではなく、削除されたものである。

initialize と initialized のこのハンドシェイクは、MCPが2024年11月に誕生した日から存在していました。Mcp-Session-Id このリクエストヘッダーは、リモートMCPが導入された後のすべてのデプロイメントソリューションの基盤でした。7月28日、この2つが同時に削除されました。

新しいリクエストはどんな感じですか？とてもシンプルです。

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

メソッド名とツール名はHTTPヘッダーに移動しました。ゲートウェイ、レートリミッター、WAFはもはやJSONペイロードを解析して呼び出しの目的を推測する必要がなく、ヘッダーを見れば済みます。プロトコルバージョン、クライアント情報、機能宣言はすべて_metaに含めてリクエストと共に送信されます。サーバーの機能を事前に確認したい場合は、新たにserver/discoverを追加しましたが、これは必須ではなく、オプションです。

これは何を意味するのでしょうか？MCPサーバーがついに通常のHTTPワークロードになったということです。

NetlifyのアプリAI副社長Sean Robertsの言葉は非常に明確です：ステートレスなコアにより、MCPはセッション管理を回避する必要のない、第一級のHTTP負荷となりました。Cloudflareの表現はさらに強烈で、このバージョンにより、AgentインフラストラクチャがWebの他の部分と同じように、ステートレスで、キャッシュ可能で、ルーティング可能で、グローバルにスケーラブルになり始めました。

標準的なメーカーの宣伝文句のように聞こえる。しかし今回は異なり、それらが具体的に同じ事実を述べているからだ：セッションが消えたため、Lambdaが動作し、Workersが動作し、エッジノードが動作する。

二、粘性会话は、Agentのスケーリングにおける実際の壁である

なぜこれほど厳しい対応をするのですか？

古いモデルには避けられない物理的制限がありました：セッションはハンドシェイクを処理するインスタンスに固定されます。

そのため、全員が同じことをするしかなくなります。粘性セッションを開いて負荷分散が各クライアントをどのサーバーに割り当てるかを記憶するか、Redisなどの共有ストレージを設けてセッション状態をすべてのインスタンスが読み取れるように保存するかです。

この二つの道はどちらも通じる。しかし、どちらも隠れた税金を支払うことになる。

セッションの保持は、スケーリングを複雑にします。インスタンスをオフラインにする際、その上で維持されていたセッションは切断されてしまいます。トラフィックが急増した際に新たに起動したインスタンスは、古いセッションを受け継げず、負荷は常に不均等になります。共有ストレージの道はさらに高価です。本質的には「クライアントの名前を記憶する」だけの要件に対して、ステートフルなミドルウェアを導入し、その高可用性を確保しなければなりません。

規模が小さいときは問題ではありません。規模が大きくなると問題になります。

数字を見れば、規模がどのように拡大したかがわかります。2025年12月、MCPが誕生して1周年のとき、SDKの月間ダウンロード数は9700万回でした。2026年7月の今回のリリースでは、Anthropicが発表した数字は月間ダウンロード数が4億回を超え、公式ブログでは「5億に近い」とされており、1年間で4倍の成長を遂げました。TypeScriptとPythonの両方のSDKの累計ダウンロード数は、それぞれ10億回の壁を突破しました。

Anthropicの自社Claudeコネクタディレクトリには、現在950以上のMCPサーバーがリストされています。観測性ベンダーのHoneycombのデータは、Agentが実際に作業を行っていることをより明確に示しています：彼らの月間インタラクティブクエリの約20%がAgentによって発信されています。

半年で4倍。このような曲線下では、あらゆるアーキテクチャ上の「隠れた税」が明確なコストとして拡大される。

したがって、公式な表現は「開発者から最も要望の高い機能の一つ」です。私たちが変更したいのではなく、本番環境で動かしている人々がもはや我慢できなくなったのです。

三、状態は消えず、モデルの眼前に移された

ここには明確に説明しなければならない誤解があります。

プロトコルがステートレスであることは、あなたのアプリケーションがステートレスであることを意味しません。

規格で示された代替案は明示的なハンドルです。ツールが呼び出し間で状態を保持する必要がある場合は、ツールが識別子（例： basket_id）を返し、モデルがこのIDをパラメータとして次の呼び出しに渡します。

公式ブログのこの文は、このドキュメントの中で最も興味深い文だと私は思います。彼らは、状態をトランスポート層に隠すよりも、このハンドルをモデルが見ることができ、ツール間でそれをつなげられる方が効果的であると発見しました。

ちょっと立ち止まって、この言葉の重みを考えましょう。

過去の設計ロジックは：状態はインフラの問題であり、モデルは気にする必要がないというものだった。現在のロジックはその逆だ：状態はモデルの推論チェーンの一部であり、隠してしまうとモデルの判断が不正確になる。

隠された状態はモデルを馬鹿にする。この結論はアーキテクチャの美学から導かれたものではなく、一年半にわたる本番障害から抽出されたものである。

同じ発想が、サーバーが自発的にリクエストを送信する仕組みにも適用されました。過去には、ツールが実行中に「この3つのファイルを削除してもよろしいですか？」とユーザーに確認する必要があり、SSEストリームを継続して保持してリクエストをクライアントにプッシュしていました。ステートレス化後、このストリームはなくなり、代わりにマルチラウンドトリップリクエスト（MRTR）が採用されました。

メカニズムは複雑ではありません。サーバーは「入力が必要」の結果タイプを返し、質問と一段落の requestState を付加します。クライアントは回答を収集し、inputResponses と変更しない requestState を伴って、元の呼び出しを再送信します。継続に必要なすべての情報が requestState に含まれているため、この再試行が別のマシンで実行されても継続できます。

Supabaseの製品責任者であるInian Parameshwaranは、正直にこう語った：elicitationのサポートは長い間彼らのロードマップに載っていたが、Supabase MCPがもともとステートレスで動作するため、実現できなかった。MRTRの後で可能になり、ツールはプロジェクトを構築する前にコストを確認でき、データを削除する前に一度確認できるようになった。

ここで、仕様文書では重点的に述べられていないが、実装では必ず遭遇するポイントを挙げます：requestStateはクライアントが保持し、返送します。これは本質的に信頼境界の外にあります。サーバーがこれを信頼できる入力として直接デシリアライズすると、自ら脆弱性を開いてしまうことになります。署名、暗号化、有効期限の設定——この3つの対策は、まもなくコミュニティの標準的な実装となると私は判断しています。これは私の見解であり、仕様の要件ではありません。

四、拡張フレームワーク：プロトコルが「太らない」ことを学び始める

二番目の真の賭けは、拡張フレームワークが慣例から制度へと変わったことである。

逆DNS命名、通过 extensions 进行能力协商、独立的 ext-* 仓库由授权维护者管理，版本独立于核心规范。听起来很枯燥，但它解决的是所有成功协议都会遇到的问题：核心日益臃肿。

この2つの拡張が正式に承認されました。

MCPアプリは、サーバーがインタラクティブなインターフェースを直接会話に送り込むことができます。プレーンテキストでも構造化JSONでもなく、サンドボックス内のiframeで実行される完全なHTMLインターフェースです。チャート、フォーム、セレクターなども可能です。重要な設計は、ツールが事前にUIテンプレートを宣言することで、クライアントが事前取得でき、何かをレンダリングする前にセキュリティチェックを実施できる点です。インターフェース上の操作は、依然として通常のツール呼び出しのJSON-RPCチャネルを通じて行われます。

タスク：もう一方の問題の処理：時間のかかるタスク。実験的機能から公式拡張に昇格し、ライフサイクルはステートレスに再設計されました：tools/call はタスクハンドルを返し、クライアントは tasks/get でポーリングし、新しい tasks/update と tasks/cancel を使用します。

值得注意的是 tasks/list が削除されました。理由は明確です：セッションがない場合、「すべてのタスクを一覧表示」の操作は安全ではなく、どのユーザーの「すべて」を指すのか定義できません。

この拡張機能はAWSが提供しました。AmazonのAgentic AI副社長であるSwami Sivasubramanianは、新しい仕様とステートレスコアがBedrock AgentCoreに組み込まれたと述べています。Microsoft側では、Foundryエンジニアリング副社長のTina Schuchmanが、MCPにより統合が数十件から数千件に拡大したと説明し、Foundry toolboxは単一のMCPエンドポイントを通じてツールを統合し、ガバナンス、認証、可観測性を一元管理していると述べています。

あるプロトコルが、AWS、マイクロソフト、Google Cloud、Cloudflare によってすべて、基盤の上に構築されるために使用されている。これはもはやどの企業のプラグイン仕様でもない。

五、本当の課題は接続ではなく、アイデンティティである

公式ブログには、正直な自己告白が一つある：過去一年、実装者たちと話し合った結果、認可が最も時間を費やした部分だった。

このバージョンでは、6つのSEPが認可に追加され、すべて地味だが必要なものでした。認可サーバーはRFC 9207に従ってissパラメータを返す必要があり、クライアントはcodeを交換する前にこれを検証しなければなりません。この対策は認可サーバーの混同攻撃を防ぎます。クライアントは動的登録時にapplication_typeを宣言する必要があり、デスクトップおよびCLIアプリのlocalhostコールバックが無理由で拒否されることはありません。クレデンシャルは発行したissuerにバインドされ、認可サーバー間で再利用できません。

より重要なのは、動的クライアント登録（DCR）が公式に廃止され、方向性がクライアントIDメタデータドキュメント（CIMD）にシフトしていることです。DCRは現在も使用可能で、後方互換性は維持されていますが、今後のバージョンでは削除される予定です。

同じ日、エンタープライズ向け託送認証拡張（EMA）が安定版に移行しました。これは、ステートレスよりも企業ITにとってより大きな意味を持つ可能性があります。

従来のモデルでは、各従業員が各サーバーに対して個別に認証を行う必要がありました。入社時には、手動で一つずつサービスに接続する必要がありました。セキュリティチームは統一されたポリシーを実行できず、権限は各ユーザーが自らクリックして設定されるため、集中管理も監査の追跡も不可能でした。さらに悪いことに、業務アカウントと個人アカウントが混在しており、企業IDの使用を強制する仕組みがありませんでした。

EMAは、企業自身のIDプロバイダーを意思決定者として機能させます。基盤には、IdPがシングルサインオン時に発行するID-JAGアサーションが使用され、クライアントはこれをMCPサーバーの認可サーバーへのアクセストークンに交換します。ユーザーは、どのサーバーの同意ページも経由しません。

Oktaが最初にサポートされたIdPであり、Cross App Accessを経由しています。クライアント側ではClaude全体とVS Codeが接続済みです。サーバー側ではAsana、Atlassian、Canva、Figma、Granola、Linear、Supabaseが既にサポートされており、Slackは現在対応中です。Linearのエンジニアリング責任者であるTom Moorの評価はとても可愛らしいです：一度ログインするだけで、すべてのMCPコネクタが自動的に設定される。これはまるで魔法のようです。

魔術的な部分は体験ではなく、ガバナンスにある。意思決定がようやくIdP管理コンソールに戻り、すべてのコネクターに監査チェーンが貫かれている。

しかし、私は言葉を完全に述べなければなりません：ステートレスとEMAは、アイデンティティとスケールに対応していますが、エージェントのセキュリティのすべてを解決するわけではありません。シスコの『2026年AIセキュリティ現状』レポートに掲載されているその2つの数値は、依然としてそこにあります。83%の組織がエージェント機能を導入する計画を立てていますが、自分たちが準備ができていると感じているのは29%だけです。プロンプトインジェクション、ツール記述のポイズニング、エージェントが横断移動の跳躍板として利用されるといった問題は、プロトコルがセッションを削除したからといって消えることはありません。

好消息是、Mcp-Method と Mcp-Name が導入されたことで、ゲートウェイの戦略実行コストが低下しました。規則では、ヘッダーとボディが一致しないリクエストをサーバーが拒否することも求められており、これによりルーティングとセキュリティの不一致が防がれました。これは防御姿勢の実質的な改善です。しかし、これ以上ではありません。

六、代償：これは破壊的変更であり、請求書は発行済みです

利益だけを語って、損失には触れないのは好きではありません。

このバージョンはブレイキングチェンジレベルです。Roots、Sampling、Logging の3つの機能が一斉に非推奨状態となります。従来のHTTP+SSEトランスポートも正式に非推奨となります。仕様では、ActiveからDeprecated、そしてRemovedへの形式的な機能ライフサイクルポリシーが新たに設けられ、各ステージは最低12ヶ月以上継続されます。

その他、些細だが影響のある変更として、ツールの入出力スキーマが現在、完全なJSON Schema 2020-12語彙をサポートしています。oneOf、anyOf、および条件文が使用可能になりました。また、「リソースが見つかりません」のエラーコードは、カスタムの-32002から標準的なJSON-RPCの-32602に変更されました。コード内で-32002をハードコーディングしている場合、この部分を変更する必要があります。

セッション識別子に依存する開発者こそ、移行コストが最も高い場所だと、公式が明言しました。

したがって、スケジュールをもう一度おさらいしましょう。候选版のリリースは5月21日に固定され、正式リリースは7月28日で、その間にはSDKメンテナーとクライアント実装者向けにちょうど10週間の検証期間が設けられました。4つのTier 1 SDK（TypeScript、Python、Go、C#）は当日すべて新バージョンをサポートし、Rust SDKはベータ版でした。

10週間の公開検証ウィンドウ＋12か月の廃止移行期間＋標準化SEPは、一貫性テストスイートに該当するシナリオが存在しなければ確定できない。この3つが組み合わさったことが、私が今回の改訂で最もプロフェッショナルだと考える点だ。

それは破壊的変更をごまかすことも、破壊的変更をコミュニティに丸投げすることでもありません。

一貫性の要件が特に重要です。今後、標準の軌道に新しい機能を追加したい場合は、まずテスト可能なシナリオを書き出してください。これは「設計意図」と「実装事実」を結びつける方法であり、多くのプロトコルは大きな失敗を経てようやく学びました。

興味深いことに、移行により正の収益ももたらされました。オープンソースフレームワーク mcp-use の背後にある Manufact の最高技術責任者、エンリコ・トニアトは、新しい SDK v2 を用いてクライアントとサーバーを分離した結果、パッケージサイズが約83%削減され、速度が25%向上したという具体的な数値を提示しました。

一次架构瘦身，顺便把包也瘦身了。这种事情不常有。

七、私の判断

では、このリニューアルをどう思いますか？

私の最初の判断は、これは誤りであり、見事な誤りの認めであるということでした。

MCPの初期の双方向ステートフル設計は、ローカルシナリオに基づいて構築された。エディタがローカルで動作するサーバーに接続し、一度ハンドシェイクして接続を維持するのは、完全に合理的だ。問題はリモートMCPが登場した後、このモデルがクラウド環境に持ち込まれ、誰もがそれにパッチを当て始めたことにある。ステイクセッションはパッチであり、Redisにセッションを保存することもパッチであり、エリシテーションのために長時間接続を確立することもパッチである。

パッチが多すぎれば、基礎を変えるべきだ。プロトコルの共同発明者であるDavid Soria Parraは、このバージョンが過去18か月の教訓をすべて取り入れたと述べている。核心メンテナーのNick Cooperはより的確に、MCPは1歳半で、数十年にわたるWebプロトコル設計の経験を吸収し、より成熟したプロトコルへと進化していると語っている。

第二の判断：今回の改訂の真の分岐点の意義は、技術ではなくガバナンスにある。

タイムラインをもう一度確認しましょう。2024年11月25日、AnthropicがMCPをオープンソース化しました。2025年12月9日、MCPはAnthropic、Block、OpenAIが共同で立ち上げ、Google、Microsoft、AWS、Cloudflare、Bloombergが支援する新設のAgentic AI Foundation（Linux Foundation傘下）に寄付されました。八か月後、最初のメジャーバージョンがリリースされました。

単一のメーカーが発明したプロトコルが、委員会の膠着状態に陥るのではなく、公開後に最も痛い手術を完了したという事実自体が、オープンガバナンスの有効性を実証している。

エコシステムプラットフォームのリストからも、重点が変わったことがわかります。Figmaはデザインとコードの統合について語り、Intuitは1億人の消費者と企業顧客に信頼できる財務インテリジェンス体験を提供することについて語り、Zoomは会議のインテリジェンスを安全にAIプラットフォームに届けることについて語っています。これらは開発者向けの玩具のような言葉ではなく、製品ラインの言葉です。

三つ目の判断、私が最も言いたいのは：プロトコルが成熟するには代償が必要であり、その代償は「逆らえない」ことだ。

ステートレス、ルーティング可能、キャッシュ可能、トレース可能。W3C Trace Context は、_meta 内の固定キー名を介して伝送され、OpenTelemetry 互換の分散トレーシングを即座に利用できます。これらの用語は、HTTP、REST、gRPC の進化史の中ですべて目にしたことがあるでしょう。

MCPは、あなたが話さないパイプになりつつあります。今日のTCPがどれほど興奮するかを誰も話さないのと同じです。

これは良いことでしょうか？私は良いことだと思います。データ層での勝利は、最も印象的なデザインではなく、最も壊れにくいものに属します。セッションが削除された瞬間、MCPはある種の洗練を諦め、輪番負荷分散の背後で水平に拡張する能力を得ました。

エージェントのスケーリングを妨げているのは、モデルの知能の有無ではない。誰もやりたがらないような課題、つまり会話データをどこに保存するか、アイデンティティをどう継承するか、接続が切断された後もタスクが維持されるか、1万人の従業員が1000台のサーバーに接続する際に何回同意ボタンを押す必要があるか、といった点が課題である。

このバージョンでは、これらの出来事を大幅に前倒ししました。

興奮感については、パイプはその提供を担当していません。パイプの役割は、あなたが見ていなくても漏れないようにすることだけです。

引用元

  1. Model Context Protocol ブログ、「The 2026-07-28 Specification」、2026 年 7 月 28 日。https://blog.modelcontextprotocol.io/posts/2026-07-28/
  2. Model Context Protocol ブログ、「Enterprise-Managed Authorization: Zero-touch OAuth for MCP」、2026年。https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
  3. AnthropicのClaude、「ClaudeにMCP 2026-07-28を導入」、2026年7月28日。https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
  4. MCP Servers ブログ、「The 2026-07-28 MCP Specification: A Stateless, Extensible Future」、2026 年。https://blog.mcpservers.org/posts/mcp-spec-2026-07-28
  5. Linux Foundation、"Linux Foundation、Agentic AI Foundationの設立を発表"、2025年12月9日。https://linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
  6. Anthropic、「Model Context Protocolの寄付とAgentic AI Foundationの設立」、2025年12月。https://anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
  7. Cisco、「State of AI Security 2026」、2026年。https://blogs.cisco.com/ai/cisco-state-of-ai-security-2026-report
  8. IT之家、発売以来最大のアップデート：MCP 2026-07-28 スペックリリース、ステートレスなコアへ移行、2026年7月29日。https://www.ithome.com/0/983/102.htm
出典:原文を表示
免責事項: 本ページの情報はサードパーティからのものであり、必ずしもKuCoinの見解や意見を反映しているわけではありません。この内容は一般的な情報提供のみを目的として提供されており、いかなる種類の表明や保証もなく、金融または投資助言として解釈されるものでもありません。KuCoinは誤記や脱落、またはこの情報の使用に起因するいかなる結果に対しても責任を負いません。 デジタル資産への投資にはリスクが伴います。商品のリスクとリスク許容度をご自身の財務状況に基づいて慎重に評価してください。詳しくは利用規約およびリスク開示を参照してください。