MCP（Model Context Protocol）の2026-07-28リリース候補が、公式ブログで公開されました。これはローンチ以来もっとも大きな改訂で、変更点の中心は「プロトコル層のステートレス化」です。結論から言えば、これまで接続のたびに必要だったinitializeハンドシェイクとMcp-Session-Idによる状態管理がなくなり、1回のリクエストが必要な情報をすべて自分で運ぶ形へ変わります。あわせて画面を返す「MCP Apps」、長時間処理の「Tasks」拡張、OAuth／OIDCに寄せた認証強化、機能の廃止手順を定めるdeprecationポリシーが加わりました。この記事では、2025-11-25版からの差分を表で整理し、自作のMCPサーバーがサイト制作や社内ツール開発でどう書き換わるかまで、実際のヘッダーとメソッド名つきで解説します。
この記事の要点
- 2026-07-28版の核心はステートレス化です。
initialize／initializedハンドシェイク（SEP-2575）とMcp-Session-Id（SEP-2567）が廃止され、各リクエストが_metaと3つのHTTPヘッダーで自己完結します。 - サーバー描画UIの「MCP Apps」、長時間処理の「Tasks」拡張、
iss検証など6件のOAuth／OIDC整合、Roots／Sampling／Loggingを非推奨にするdeprecationポリシーが同時に入りました。 - セッションが消えたことで、自作サーバーをスティッキールーティングなしの普通のロードバランサ配下で動かせるようになり、認可は毎リクエスト検証する設計へ移す必要が出ます。
01MCP 2026-07-28リリース候補とは？何が変わったのか
MCP 2026-07-28リリース候補とは、AIと外部ツールをつなぐオープンプロトコルであるMCPの、次期仕様の最終手前の版です。公式ブログはこれを「ローンチ以来もっとも大きな改訂」と位置づけており、最大の変更はプロトコルをステートレスにしたことにあります。ステートレスとは、サーバーがリクエスト間の状態を覚えず、1回の呼び出しに必要な情報がその都度すべて含まれる、という設計です。
2026-07-28版の変更は大きく5つ
編集部が公式ブログと仕様の該当箇所を確認したところ、今回の改訂は次の5つに整理できます。第一にステートレス化で、初期化のやり取りとセッションIDが消えました。第二にサーバーが画面を返す「MCP Apps」の追加です。第三に長時間処理を扱う「Tasks」がコア機能から拡張へ移りました。第四にOAuth／OIDCへ寄せた認証の強化、第五に機能の廃止手順を定めるdeprecationポリシーの新設です。いずれも「新しくなりました」で終わる話ではなく、サーバーを自分で書く側の実装に直接響きます。
なぜステートレス化が中心なのか
これまでのMCPは、接続の最初にinitializeで握手し、サーバーが発行するMcp-Session-Idを以降のリクエストに付けて会話を続ける設計でした。この方式はローカルで1対1に使う分には自然ですが、リモートでサーバーを共有公開すると、同じセッションを同じインスタンスへ運ぶ「スティッキールーティング」や共有セッションストアが必要になります。今回の改訂は、その状態管理そのものをプロトコルから外し、HTTPの一般的な運用に寄せることを狙っています。
02これまで（2025-11-25）との差分【比較表】
まず、直前の安定版である2025-11-25と2026-07-28リリース候補で、実装者に関わってくる違いを一覧にします。料金の話ではなく、接続の作り方・使える場所・廃止対象が変わる改訂です。次の表は公式ブログと仕様の記載から編集部が整理したものです。
| 項目 | 2025-11-25（これまで） | 2026-07-28 RC（今回） | 実務での意味 |
|---|---|---|---|
| 接続の初期化 | initialize／initializedで握手 |
握手を廃止（SEP-2575）。server/discoverで機能取得 |
接続確立の往復が減り、実装が単純になる |
| セッション管理 | Mcp-Session-Idヘッダーで状態保持 |
プロトコル層のセッション廃止（SEP-2567） | スティッキールーティングが不要になる |
| 1リクエストの中身 | 初回に渡した情報を以降は省略 | 毎回_metaにクライアント情報とバージョンを同梱 |
どのサーバーインスタンスでも処理できる |
| 必須HTTPヘッダー | プロトコルバージョン程度 | MCP-Protocol-Version／Mcp-Method／Mcp-Name |
本文を開かずに経路制御・レート制限ができる |
| Tasks（長時間処理） | 実験的なコア機能 | 拡張へ移動。作成はサーバー主導、tasks/list削除 |
長時間ジョブの扱いが本番向けに再設計された |
| 画面を返す機能 | なし | MCP Apps（SEP-1865）でサンドボックスUIを提供 | ツールが結果に加えて操作画面を返せる |
| Roots／Sampling／Logging | 利用可能 | 非推奨（SEP-2577）。最短12カ月後に削除 | 依存していると移行計画が必要になる |
| リソース欠落時のエラー | 独自コード-32002 |
JSON-RPC標準の-32602へ（SEP-2164） |
エラー判定を標準コードに寄せられる |
表のとおり、変わるのは「値段」ではなく「つなぎ方」です。とくに上4行のステートレス関連は、リモートでサーバーを公開している人ほど設計の見直しにつながります。
03ステートレス化とは？initializeとMcp-Session-Idはどうなるのか
ステートレス化とは、サーバーがリクエスト間の状態を覚えない設計へ移すことです。今回、接続開始のinitialize／initializedハンドシェイクと、会話を紐づけるMcp-Session-Idヘッダーが廃止されます。代わりに、クライアント情報とプロトコルバージョンを毎リクエストの_metaフィールドへ入れ、サーバーの機能はserver/discoverメソッドで取得します。
毎リクエストで何を送るのか
各リクエストは、HTTPヘッダーにMCP-Protocol-Version: 2026-07-28、呼び出す操作を示すMcp-Method、対象の名前を示すMcp-Nameの3つを付けます。本文側では_metaにio.modelcontextprotocol/clientInfoやclientCapabilitiesを同梱します。これにより、ロードバランサやゲートウェイは本文を開かずにヘッダーだけで振り分けやレート制限を判断できます。
↓ Mcp-Session-Id 発行
↓ 同じIDを付けて継続
同じサーバーへ固定送信
↓ _meta に情報を毎回同梱
↓ 3つのヘッダーで経路制御
どのインスタンスでも処理可
状態はどこへ行くのか
プロトコルから状態が消えても、業務上の状態そのものが不要になるわけではありません。編集部が仕様を確認したところ、状態をどこに置き、誰がアクセスを検証するかは実装者の責任になります。つまり、必要な状態は自分のデータストアへ持ち、認可は毎リクエストで検証する、という作りへ寄せることになります。あわせて、リスト取得やリソース読み取りの結果にはttlMsとcacheScopeを付けられるキャッシュ制御（SEP-2549）が入り、HTTPのCache-Controlに近い運用ができます。
04MCP Appsとは？サーバー描画UIで何ができるのか
MCP Apps（SEP-1865）とは、サーバーが返したHTMLを、ホスト側がサンドボックス化したiframe内で描画する仕組みです。これまでのMCPはテキストや構造化データを返すのが基本でしたが、今回の拡張でツールが「操作できる画面」を結果として返せるようになります。データの可視化や、複数項目の入力フォームのような用途が想定されています。
安全性はどう保たれるのか
UIテンプレートはツールが事前に宣言し、ホストがprefetch・キャッシュ・セキュリティレビューを行える形になっています。描画されたUIからの操作も、通常のツール呼び出しと同じJSON-RPCで通信し、同じ監査経路を通ります。画面を足しても、通信と権限の筋道は既存のツール呼び出しと共通に保たれる設計です。
UIテンプレート宣言
sandboxed iframe
→ 通常のtools/callへ
05Tasks拡張と、非推奨になる3機能（Roots・Sampling・Logging）
Tasksは、時間のかかる処理を扱うための仕組みです。2025-11-25では実験的なコア機能でしたが、本番利用を経た再設計のため拡張へ移されました。サーバーはtools/callにタスクの識別子（task handle）で応答でき、クライアントはtasks/get・tasks/update・tasks/cancelで進行を操作します。タスクの作成はサーバー主導になり、セッション廃止に伴って一覧取得のtasks/listは削除されました。
非推奨になるのはどの機能か
deprecationポリシー（SEP-2577）により、注釈的な位置づけだった3機能が非推奨になります。次の表のとおり、それぞれに代替の考え方が示されています。非推奨はすぐ使えなくなる意味ではなく、削除まで最短12カ月の猶予がある段階です。
| 非推奨になる機能 | 理由 | 示された代替 |
|---|---|---|
| Roots | 注釈的な機能だったため | ツールのパラメータ、リソースURI、サーバー設定 |
| Sampling | 同上 | LLMプロバイダのAPIを直接統合 |
| Logging | 同上 | stdioのstderr、構造化はOpenTelemetry |
各機能は「Active → Deprecated → Removed」の順で扱われ、削除まで最短12カ月が確保されます。仕様がFinalに至る前に、これらの移行シナリオがconformance suite（適合性テスト）に用意される点も定められました。依存している場合は、この猶予のあいだに置き換え先を決めておくのが安全です。
06認証はどう強化されたか？OAuth／OIDC整合の6変更
認証は、OAuthとOpenID Connectの一般的な運用へ近づける形で、6件のSEPが入りました。どれも独自仕様を減らし、既存の認可基盤にそのまま載せやすくする方向です。細部は次の表にまとめます。
| 変更点 | 対応SEP | 内容 |
|---|---|---|
| iss パラメータ検証 | SEP-2468 | RFC 9207に沿って発行者を検証し、mix-up攻撃を防ぐ |
| application_type 宣言 | SEP-837 | 動的クライアント登録時にOIDCのクライアント種別を指定 |
| 認可サーバーとの結合 | SEP-2352 | 登録資格を発行者に紐づけ、サーバー移行時は再登録 |
| リフレッシュトークン | SEP-2207 | OIDC型の認可サーバーからの要求手順を明文化 |
| スコープの累積 | SEP-2350 | ステップアップ時の権限の積み上がりを明確化 |
| .well-known 発見 | SEP-2351 | ディスカバリのsuffixの使い方を明確化 |
ステートレス化で認可を毎リクエスト検証する設計に寄るため、この認証まわりの明確化は運用の土台になります。既存のOIDC基盤を持っているなら、そこへ寄せられるぶん自作の認可コードを減らせる方向です。
07自作MCPサーバーはどう書き換わるか【制作・自社ツール開発の実践】
ここからは、編集部が普段のサイト制作と社内ツール開発でMCPサーバーを自作している立場から、2026-07-28版で実際に何を書き換えるかを具体的に示します。題材は「自分たちの制作ルールや案件データをAIへ渡す小さなMCPサーバー」を、サーバーレス環境（関数実行基盤）へ置く構成です。
これまでの作り：セッションを持つ設計
従来は、接続のたびにinitializeで握手し、返ってきたMcp-Session-Idを保持していました。サーバーレスでインスタンスが複数に増えると、同じセッションを同じインスタンスへ運ぶスティッキー設定か、セッションを共有ストアに置く工夫が要ります。小さな社内ツールでも、この一手間が地味に重くのしかかっていました。
今回の作り：1リクエストで完結させる
2026-07-28版では、握手とセッションをやめ、毎回のリクエストに必要情報を載せます。クライアントが送るリクエストは、ヘッダーと_metaにバージョンとクライアント情報を含めた次の形になります。
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_design_rule
{
“jsonrpc”: “2.0”,
“id”: 1,
“method”: “tools/call”,
“params”: {
“name”: “get_design_rule”,
“arguments”: { “topic”: “lp-first-view” },
“_meta”: {
“io.modelcontextprotocol/protocolVersion”: “2026-07-28”,
“io.modelcontextprotocol/clientInfo”: {
“name”: “in-house-client”,
“version”: “1.0.0”
},
“io.modelcontextprotocol/clientCapabilities”: {}
}
}
}
サーバー側は、Mcp-Methodヘッダーで処理を振り分ける素直な関数に整理できます。次は、制作ルールを返すツールを1つだけ持つ最小の擬似コードです。認可を毎リクエストで検証する点が、これまでとの一番の違いです。
export async function handler(req) {
// 1. まず認可をこのリクエスト単体で検証する
const token = req.headers[“authorization”];
if (!verifyToken(token)) return unauthorized();
// 2. ヘッダーだけで操作を判定（本文を開く前に振り分け可）
const op = req.headers[“mcp-method”]; // “tools/call”
const name = req.headers[“mcp-name”]; // “get_design_rule”
// 3. 状態は自前ストアから引く（セッションは持たない）
if (op === “server/discover”) return listTools();
if (op === “tools/call” && name === “get_design_rule”) {
const { topic } = req.body.params.arguments;
return ok(loadRuleFromStore(topic)); // 例：制作ルールを返す
}
return invalidParams(); // -32602
}
制作・自社ツール開発での利点
この作りにすると、サーバーを普通のラウンドロビンのロードバランサ配下へそのまま置けます。LP制作で使う「自社のデザインガイドラインを引くサーバー」や、案件の進行データを返す社内ツールを、スティッキー設定なしのサーバーレス関数として並べられるわけです。デプロイのたびにインスタンスが入れ替わっても、各リクエストが自己完結しているので取りこぼしが起きにくくなります。移行の手順は、(1)initialize依存コードを外す、(2)3つのヘッダーを送る／読む、(3)server/discoverを実装する、(4)非推奨の3機能を使っていれば代替へ寄せる、の4点が起点になります。なお、公開するサーバーには認証情報や社内の非公開URLを直接埋め込まず、環境変数と認可検証で切り離す前提です。
08この変更でアウトプットにどんな差が出ると想定されるか
ここは実測値ではなく、公式が示した仕様差からの想定として書きます。もっとも大きいのは「サーバーの置き場所の自由度」です。セッションを持たない仕様になったことから、これまでスティッキールーティングや共有ストアが前提でリモート公開をためらっていた小さな自作サーバーでも、サーバーレスへ載せやすくなると想定されます。
運用と開発の工程はどう変わると想定されるか
ヘッダーで操作を判別できる仕様差から、ゲートウェイでの経路制御やレート制限を本文解析なしで組める、と想定されます。結果として、ツール単位でのアクセス制御や監視の設定が、これまでより素直に書けると考えられます。一方で、認可を毎リクエストで検証する責任が実装者側へ移るため、初期化時に一度だけ認証していた作りは、リクエストごとの検証へ組み替える手間が増えると想定されます。いずれも「◯◯という仕様差から、△△の工程でこう変わる」という想定であり、実際の速度や工数は自分の環境で測り直すのが確実です。
09いつ本番で使えるのか？移行の進め方
2026-07-28版は現時点でリリース候補で、この日付が最終仕様の公開日として示されています。リリース候補は仕様が固まった段階の版ですが、各クライアントやSDKの対応状況は個別に確認するのが安全です。今日から本番のすべてを切り替えるというより、対応が整ったところから順に寄せていく進め方が現実的です。
移行で最初にやることは何か
最初の一歩は、自分のサーバーがinitializeとセッションに依存している箇所の洗い出しです。そのうえで、3つの必須ヘッダーの送受信、server/discoverの実装、Roots・Sampling・Loggingの利用有無の確認、という順で進めると漏れが出にくくなります。削除まで最短12カ月の猶予があるため、非推奨機能はいきなり動かなくなるわけではありませんが、猶予のあいだに置き換え先を決めておくと後が楽になります。MCPそのものの基礎をおさらいしたい場合はMCPとは？仕組みと使い方の図解を、実際につなぐサーバーの具体例は日本特化のMCPサーバー6選をあわせて参考にしてください。
10よくある質問
MCP 2026-07-28版で一番大きい変更は何ですか？
プロトコル層のステートレス化です。接続開始のinitializeハンドシェイクと、状態を紐づけるMcp-Session-Idヘッダーが廃止され、各リクエストが_metaと3つのヘッダーで自己完結する形へ変わりました。これにより、スティッキールーティングなしでサーバーを分散配置しやすくなります。
既存のMCPサーバーはそのまま動きますか？
そのままでは動かない箇所が出ます。initializeやセッションに依存している実装は、3つの必須ヘッダーの対応とserver/discoverの実装へ組み替えが必要です。Roots・Sampling・Loggingを使っている場合も、非推奨に伴う移行の検討対象になります。
Roots・Sampling・Loggingはいつ使えなくなりますか？
非推奨になった段階で、削除までは最短12カ月の猶予が定められています。すぐに動かなくなるわけではありませんが、SamplingはプロバイダのAPI直接統合へ、LoggingはstderrやOpenTelemetryへ、といった代替が示されているため、猶予のあいだに寄せておくのが安全です。
MCP Appsを使うと何ができますか？
ツールが結果に加えて操作画面を返せるようになります。ホストがサンドボックス化したiframe内でサーバー提供のHTMLを描画し、その画面からの操作は通常のツール呼び出しと同じ経路で扱われます。データの可視化や複数項目の入力フォームなどが想定されています。
ステートレス化で認証はどうなりますか？
認可を毎リクエストで検証する設計へ寄ります。あわせてiss検証やapplication_type宣言など、OAuth／OIDCに整合する6件の変更が入りました。既存のOIDC基盤があるなら、そこへ寄せることで自作の認可コードを減らせる方向です。
MCPの基本から知りたい場合はどこを読めばよいですか？
まずプロトコルの全体像とメソッドの流れを押さえるのが近道です。仕組み・3プリミティブ・接続手順はMCPとは？の解説で図解しています。そのうえで本記事の差分を読むと、2026-07-28版で何が変わったかがつかみやすくなります。
11まとめ：今から準備しておくこと
2026-07-28版へ動くかどうかは、「リモートでMCPサーバーを共有公開したいか」で判断が分かれます。ステートレス化によって、これまでスティッキールーティングや共有ストアが障壁になっていた自作サーバーを、普通のロードバランサ配下へ置きやすくなるからです。逆にローカルで1対1に使うだけなら、恩恵は限定的です。
最初の準備としては、手元のサーバーがinitializeとセッションに依存している箇所を洗い出し、3つの必須ヘッダーとserver/discoverへの対応、そしてRoots・Sampling・Loggingの利用有無の確認から始めるのが安全です。認可は毎リクエストで検証する設計へ寄せておくと、正式版が来たときの切り替えが軽くなります。プロトコルの基礎はMCPとは？の図解、実際につなぐサーバー例は日本特化のMCPサーバー6選で確認できます。