目次
何が起きたのか — RCロックと7/28の最終公開
2026年5月21日、MCPの次期仕様 2026-07-28 のリリース候補がロックされた(✅ blog.modelcontextprotocol.io)。最終仕様は2026年7月28日に公開予定。RCから最終版までの約10週間は、SDKメンテナーとクライアント実装者が変更を実ワークロードに対して検証する期間で、SDKのTier制度の下、Tier 1 SDKはこの期間内に対応を出荷することが期待されている。
この改訂はローンチ以来最大規模であり、2026年ロードマップに掲げられた目標——『一般的なHTTPインフラでスケールするステートレス・コア』『MCP AppsによるサーバーレンダリングUIやTasksによる長時間処理を含むExtensions』『OAuth/OpenID Connect運用により近い認可』——を一気に実装する。背景には、コミュニティのフィードバックと本番テレメトリが繰り返し示してきた摩擦点がある:ステートフル・セッションとロードバランサーの非互換、不明瞭なタスクのライフサイクル、ガバナンスのボトルネック、エンタープライズのコンプライアンス・ギャップだ。
MCP仕様2026-07-28 RC 早わかり
(2026年)
(予定)
ウィンドウ
猶予(最短)
① Stateless Core — ステートフル・セッションとの決別
最大の変更はプロトコル・コアのステートレス化だ。新しいコアは、特別なインフラを必要とせず通常(commodity)のHTTPインフラ上でステートレスに動作する。具体的には、サーバー起点のリクエスト(server-initiated requests)は『サーバーがクライアントのリクエストを能動的に処理している間にのみ発行できる』ようになり、これが必須化される。
従来のMCPはステートフルなセッションを前提としており、複数インスタンスにトラフィックを分散するロードバランサーとの相性が悪かった。これは2026年ロードマップで筆頭に挙げられた摩擦点だ。ステートレス・コアにより、SaaSベンダーは『普通のWebサーバーをスケールさせる』のと同じ感覚でMCPサーバーを水平スケールできる。エンタープライズ規模のデプロイに向けた、最も実務的な改善である。
② Extensionsフレームワーク — 仕様を壊さず拡張する
Extensionsフレームワークは、新しい機能をオプトインの拡張として出荷し、そこで安定させてから(もし必要なら)仕様本体に取り込む仕組みだ。これにより、コアを薄く・安定的に保ちながら、実験的な機能を本番で検証できる。MCP AppsやTasksは、この枠組みの上に乗る最初の主要な拡張群である。
③ Tasks拡張 — 長時間ワークフローを安全に
Tasks拡張は、長時間実行される処理をステートレスモデルに合わせて再設計したものだ。サーバーは tools/call にタスクハンドルで応答でき、クライアントは tasks/get・tasks/update・tasks/cancel でそれを駆動する。
// 概念図: tools/call がタスクハンドルを返す
client → tools/call → server
server → { "task": "t_123" } (即時にハンドルを返す)
client → tasks/get t_123 → "running"
client → tasks/get t_123 → "completed" + result
// 必要なら tasks/cancel t_123 で中断Tasksは2025-11-25に実験的なコア機能として導入されたが、本番利用で十分な再設計が必要と判明し、仕様本体ではなく拡張(Extension)に置くのが適切と判断された。これは『一度コアに入れたものを、現場の知見に基づいて拡張へ移す』という、健全なフィードバックループの表れでもある。
④ 認可強化 — OAuth/OIDCへの接近
RCには、OAuthおよびOpenID Connectのデプロイにより近づく認可が含まれる。エンタープライズのコンプライアンス・ギャップという摩擦点に応える変更で、MCPのセキュリティ姿勢を大きく前進させる。既存のIDプロバイダやSSO基盤との統合がしやすくなり、企業が安心してエージェントを本番投入できる土台になる。
⑤ 非推奨ポリシー — 12ヶ月の予測可能性
すべての機能に Active(有効)・Deprecated(非推奨)・Removed(削除) のライフサイクルが与えられ、非推奨化から最短でも12ヶ月の猶予を置いてから削除される。仕様が予告なく壊れる不安を減らし、ベンダーが計画的にMCP対応へ投資できる予測可能性を提供する、地味だが極めて重要な変更だ。
日本SaaSのAEOへの示唆 — KanseiLink実測の視点
KanseiLinkの225+サービス実測データの観点から、この仕様変更は日本SaaSのエージェント対応(AEO)を底上げするプラス要因が大きい。
| RCの変更 | 日本SaaSへの示唆 | 評価 |
|---|---|---|
| Stateless Core | セッション維持やロードバランサーで苦労していたSaaSのMCP実装が楽に。水平スケールが容易化。 | 追い風 |
| 認可強化(OAuth/OIDC) | SmartHR・freee・kintone等、既にOAuthを採用する国内SaaSがそのまま乗りやすい。 | 追い風 |
| Tasks拡張 | 年末調整・給与計算・月次締めなど長時間ワークフローを安全に扱う土台。 | 追い風 |
| 非推奨ポリシー | 仕様破壊の不安が減り、ベンダーが計画的に投資できる。 | 予測可能性 |
| 10週間の検証窓 | SDK/クライアント対応が出揃うまで、本番採用は段階的に。 | 要観察 |
KanseiLink実測では、verified(成功率80%超・実証済み)バッジを持つ日本SaaSはまだ少数だ。認可強化はOAuthを採用する国内SaaSにとって『追加コストの少ない』対応であり、Tasksは年末調整のような季節性ワークフローを抱えるHR/会計SaaSに直接効く。この仕様改訂を機にMCP対応を進めるベンダーが、AEOグレードで先行者利益を取れる局面に入っている。
RCはあくまで候補であり、最終仕様は7月28日公開。10週間の検証期間中はSDKやクライアントの対応が出揃わない可能性がある。エンタープライズ本番では、Tier 1 SDKの対応出荷を確認しつつ、既存のステートフル実装からの移行を段階的に進めるのが安全だ。
FAQ
Q1. MCP仕様2026-07-28はいつ正式版になりますか?
リリース候補が2026年5月21日にロックされ、最終仕様は2026年7月28日に公開予定です。その間の約10週間はSDKメンテナーとクライアント実装者の検証期間で、Tier 1 SDKはこの期間内に対応を出荷することが期待されています。
Q2. 既存のMCPサーバーは作り直しが必要ですか?
非推奨ポリシーにより、非推奨化された機能でも最短12ヶ月の猶予があります。ステートフル前提の実装はステートレス・コアへの移行を計画する価値がありますが、いきなり全面書き換えではなく、SDK対応の出荷を見ながら段階的に進めるのが妥当です。
Q3. Tasksがコアから拡張に移ったのはなぜですか?
Tasksは2025-11-25に実験的なコア機能として導入されましたが、本番利用で十分な再設計が必要と分かり、仕様本体ではなく拡張(Extension)に置くのが適切と判断されました。Extensionsフレームワークの『拡張で安定させてから必要ならコアへ』という思想に沿った動きです。
Q4. 日本のSaaSはまず何から対応すべきですか?
既にOAuthを採用しているなら認可強化との整合は比較的容易です。長時間ワークフロー(年末調整・月次締め等)を持つサービスはTasks拡張の検討価値が高い。まずはKanseiLink等で自社の現状成功率・認証方式を把握し、ステートレス・コアへの移行計画を立てるのが出発点です。
本記事のMCP仕様2026-07-28 リリース候補に関する記述(RCロック日2026-05-21、最終公開予定2026-07-28、約10週間の検証ウィンドウ、Tier 1 SDKの出荷期待、Stateless Core/Extensions/Tasks/MCP Apps/認可強化/12ヶ月の非推奨ポリシー)は、Model Context Protocol公式ブログ(blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate)および2026年ロードマップ(blog.modelcontextprotocol.io/posts/2026-mcp-roadmap)、The New Stack等の二次解説を2026-05-25時点でWebSearch確認した内容に基づきます。本稿は将来予定(forward-looking)を含み、最終仕様の内容・公開日は変更される可能性があります。「日本SaaSへの示唆」「先行者利益の局面」はKanseiLinkの225+サービス実測データに基づく分析・見解であり、各サービスベンダーの公式見解ではありません。本番採用の判断は公式仕様の最新版とSDK対応状況をご確認ください。