AIAI開発横丁AI Dev Yokocho
メニュー
Search the alley

記事を検索

2文字以上でタイトル・カテゴリ・タグを検索できます。

MCP 2026-07-28仕様はどう変わる？RC・ステートレス化・移行時の確認点

MCP 2026-07-28のRelease Candidateとdraft仕様を確認し、stateless core、initialize・sessionの変更、server/discover、Extensions、Tasks、MCP Apps、認証強化、既存実装の移行判断を整理します。正式版公開済みと断定せず、個人開発者が今すぐ変更する範囲を分けます。

公開 2026.07.28 / 更新 2026.07.28

この記事のポイント

  • 2026-07-28の正式版公開済みとは断定せず、公開されているRC・draft・GitHubの進捗を分けて読む
  • プロトコル層のstateless化でinitialize・initializedとMcp-Session-Idの扱いが変わる
  • Tasks、MCP Apps、Extensionsは仕様上の機能と、各クライアント・SDKの対応状況を分ける
  • 移行前にSDK、クライアント、認証、conformance、既存サーバーの実装範囲を確認する

結論：大きな変更だが、全利用者が今日一斉移行する話ではない

MCP 2026-07-28は、statelessなプロトコルコア、Extensions、Tasks、MCP Apps、OAuth・OpenID Connectに近づけた認証強化、正式なdeprecation policyをまとめた大きな改訂です。一方、RCからfinalへ変わる可能性と、SDK・クライアントが同じ速度で対応するとは限らない点が残ります。既存のMCP Serverが動いているなら、まず対応表と検証環境を作り、本番の接続方式を先に変えない判断も正解です。

観点2025-11-25系2026-07-28 RC / draftで確認できる変更移行前の確認
接続の状態プロトコル層のstateful connectionstatelessなself-contained requestを中心にするSDKが新旧transportをどう扱うか
初期化initialize / initialized handshakehandshakeとMcp-Session-Idを外し、request単位で情報を渡す方向clientInfo、capability、version negotiationの実装
発見接続時のcapability negotiationserver/discoverで必要時に能力を取得する設計対応メソッドとcacheの扱い
長時間処理Tasksは実験的なcore機能Tasks extensionとしてtask handle、get、update、cancelを使う方向旧Tasks APIを使っていないか
UI標準coreの中心ではないMCP Appsがsandboxed iframeのserver-rendered UIとして整理hostのsandbox、consent、監査

stateless化は、アプリケーションの状態を消すことではない

公式説明でいうstatelessは、MCPのプロトコル層が接続sessionを管理しないという意味です。買い物かごやブラウザの状態が必要なアプリケーションは、ツールの引数として明示的なhandleを返し、次の呼び出しで渡す設計にできます。隠れたsessionに依存していた実装は、状態をどこで持ち、誰が渡し、期限や権限をどう確認するかをコードと監査ログに出す必要があります。

server/discover、Extensions、Tasks、MCP Appsを混同しない

要素仕様上の役割個人開発者が見るべき実装差
server/discoverサーバーの能力を必要な時に取得するサーバーとクライアントの対応version、cache、失敗時のfallback
Extensionscoreの外側で機能を個別に進化させる枠組み両端が明示的に対応し、negotiationするか
Tasks長時間処理をhandleで追跡し、更新・取消するextension旧experimental APIとの違い、cancelと権限の設計
MCP Appshostがsandboxed iframeでUIを表示するextensionUI表示とtool callのconsent・監査が同じ線上にあるか

認証強化は、APIキーを置き換えるだけの話ではない

RCの認証変更には、authorization responseのiss検証、OIDCのapplication_type、issuerに結びついたcredential、refresh token、scopeの積み上げ、well-known discoveryの整理が含まれます。これは認証サーバーとクライアントの実装を確認する話であり、仕様名を設定ファイルへ貼り付ければ安全になる話ではありません。個人開発では、まずサーバーごとの認証方式、scope、tokenの保管場所、再認証、ログに残す情報を表にします。

移行前チェックリスト

  • RC・draft・finalのどれを実装対象にするか、URLと確認日を記録する
  • MCP client、server、SDKの対応versionと互換性を確認する
  • initialize / initialized / Mcp-Session-Idを前提にした実装箇所を洗い出す
  • sessionを外した後も必要な状態を、明示的なhandle・期限・権限で設計する
  • server/discover、Mcp-Method、Mcp-Name、cacheの扱いをgatewayと一緒に検証する
  • Tasksを使う場合は旧APIとの違い、cancel、途中入力、権限を確認する
  • MCP Appsを使う場合はiframe、UI action、consent、監査ログを分けずに確認する
  • OAuth/OIDCのissuer、iss、scope、refresh token、再認証をテストする
  • conformance test、SDKのtier、既存の接続先を確認してから段階的に切り替える

今すぐ変更しない方がよいケース

対応SDKがまだRCを正式サポートしていない、接続先が2025-11-25前提、認証のテスト環境がない、本番のrollback手順がない場合は、仕様を読んだだけでtransportを変更しない方が安全です。新仕様を理解することと、本番を移行することは別の作業として扱います。

よくある質問

MCP 2026-07-28は正式版ですか？

2026-07-28に確認した時点では、公式GitHub Releasesが2026-07-28 RCをPre-releaseとして表示し、仕様リリースmilestoneも完了していません。この記事では正式版公開済みとは断定せず、RC・draft・SDK対応を分けています。

既存のMCP Serverはすぐ壊れますか？

互換性はclient、server、SDK、transport、認証の組み合わせで変わります。既存実装が旧仕様に依存している箇所を洗い出し、検証環境で新旧を比較してから移行します。

statelessなら長時間タスクは使えなくなりますか？

Tasksはstatelessモデルに合わせたextensionとして整理されています。task handle、状態取得、更新、取消をクライアントとサーバーが対応しているか確認する必要があります。

関連記事