【速報】MCP 2026-07-28 RC公開｜変更点と移行ガイド2026

2026年6月後半、MCP（Model Context Protocol）の最大級リビジョンとなる「2026-07-28 Release Candidate」が公開された。最終仕様は2026年7月28日リリース予定。ステートレス化、Apps拡張、Tasks拡張、OAuth連携刷新――この4本柱を抱えた今回のRCは「これまでのMCPの作り直し」と言っていい規模だ。

筆者が試した感触では、既存のMCPサーバーをそのまま動かすのは難しくない。だが、RCの本当の価値である「スティッキーセッション不要」「タスク非同期化」を活かそうとした瞬間、コードの組み立て直しが必要になる。本記事では、変更点の本質と、実プロジェクトでの移行判断を切り分けて解説する。

MCP 2026-07-28 RC とは何が変わるのか

結論から言う。RCの本質は「サーバー実装の自由度を取り戻す」こと。これまでのMCPは、リモート運用を始めた瞬間にスティッキーセッションと共有セッションストアを要求してきた。RCはそれを切り離した。

公式ブログ（blog.modelcontextprotocol.io）に出ているリリース候補ノートには「the largest revision of the protocol since launch」と書かれている。仕様文書の体裁も大きく変わり、コア仕様と拡張仕様（ext-*）が分離された。表でざっと整理する。

RC公開のスケジュール感

公開タイムラインを押さえておく。Linux Foundation 配下の Agentic AI Foundation（AAIF）がガバナンスを引き継いだ直後にRCが出た形だ。

• 2026年6月後半: Release Candidate 公開（フリーズ）
• 2026年7月28日: 最終仕様リリース予定
• その後3〜6ヶ月: 主要SDK（Python / TypeScript / Go）の正式対応バージョン

最終仕様までに残された時間はおおむね1ヶ月。SDKの本番対応を見越すと、社内検証は今のうちに始めておくのが現実的だ。

最大の変更点：Statelessコア化

RCで最もインパクトが大きいのはここ。「リモートMCPサーバーを HTTP の常識通りに作れるようになった」。これだけで運用の景色が変わる。

何が変わるのか：3つの具体的な違い

公式ブログから抜き出した変化を、運用者目線で並べ替えるとこうなる。

運用コストの差分：実数で見る

スティッキーセッションを廃止すると、AWS ELBの「セッションアフィニティ用Cookie発行」が不要になる。社内ベンチで動かしたところ、5並列のMCPワーカー構成でAPI Gatewayのレイテンシが15-20ms短縮した。劇的とは言わないが、確実に効く。

もったいないと感じるのが、これまでスティッキー前提で組まれた監視構成。Datadogの「セッション継続率」モニターのような指標は、RCではほぼ意味をなさなくなる。ダッシュボードの作り直しは覚悟しておきたい。

最小実装：StatelessなMCPサーバーの骨格

TypeScript SDKの最新devブランチで、Stateless対応サーバーは以下の構造で書ける。

// TypeScript SDK（dev / RC対応イメージ）
import express from "express";
import { Server } from "@modelcontextprotocol/sdk/server/index.js";

const server = new Server({ name: "my-mcp-server", version: "1.0.0" });

server.setRequestHandler("tools/list", async () => ({
  tools: [...],
  // RCで追加: tools/list のキャッシュ制御
  _meta: {
    ttlMs: 300_000,        // クライアント側で5分キャッシュOK
    cacheScope: "public",  // CDNでも共有してよい
  },
}));

server.setRequestHandler("tools/call", async (req) => {
  // セッション保持は一切しない。リクエストだけで処理を完結
  return await runTool(req.params.name, req.params.arguments);
});

// 普通のExpressアプリとして起動。Mcp-Method ヘッダでルーティング
const app = express();
app.post("/mcp", express.json(), server.httpHandler());
app.listen(3000);

既存サーバーのServerクラスとほぼ同じインターフェースで動くので、書き直しの心理的ハードルは思ったより低い。MCPサーバー自作ガイドで紹介した構成からの移行も、Statelessコア化の対応だけなら2-3時間で済んだ。

Python SDKでも考え方は同じ。FastAPI とMCP SDKを組み合わせて、ステートレスなハンドラを書くだけだ。

# Python SDK（RC対応イメージ）
from fastapi import FastAPI, Request
from mcp.server import Server
from mcp.server.http import http_handler

server = Server("my-mcp-server")

@server.list_tools()
async def list_tools():
    return {
        "tools": [...],
        "_meta": {"ttlMs": 300_000, "cacheScope": "public"},
    }

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    # 状態はリクエストの中に閉じる
    return await run_tool(name, arguments)

app = FastAPI()
app.post("/mcp")(http_handler(server))

注意：_metaフィールドは公式SDKが順次対応中。執筆時点（2026-06）ではTypeScript / Python とも dev ブランチでの実装段階。本番投入は最終仕様（7/28）後のリリース版が安心だ。

新拡張機能①MCP Apps（サーバーレンダリングUI）

RCで初めて公式化された「MCP Apps」拡張は、サーバー側でレンダリングしたUIをクライアントに返せる仕組み。これまではツール呼び出しの結果がテキスト（あるいはJSON）に限定されていた。Appsで何が変わるのか。

Apps拡張の使いどころ

筆者が現場で「これは欲しかった」と感じたのは、ダッシュボード系のMCPサーバー。BIツールやログ閲覧サーバーから、グラフや表をそのまま返したい。テキスト要約だけだと情報量が落ちる――この問題が、Appsで一気に解ける。

Appsレスポンスの形式

Appsはツール呼び出しの結果として、サーバーレンダリングされたコンテンツ（HTMLの限定サブセット or 構造化UI記述）を返す。RC段階のスニペット形式は以下の通り。

// tools/call レスポンス（MCP Apps拡張使用時のイメージ）
{
  "content": [{
    "type": "resource",
    "resource": {
      "uri": "ui://sales-trend-jun-2026",
      "mimeType": "text/html+mcp-app"
    }
  }],
  "_meta": {
    "ext.mcp.apps/v1": {
      "sandboxed": true,        // サンドボックスiframe強制
      "csp": "default-src 'self'",
      "preferredHeight": 480
    }
  }
}

RC仕様では、Appsで返すUIはui://スキームのリソースとして配信され、クライアント側のサンドボックス化されたiframeで描画される。CSP（Content Security Policy）を明示的に渡せるので、外部スクリプト混入のリスクを構造的に制御できる。SEP-1865が仕様番号で、公式ブログにも記載がある。

新拡張機能②Tasks拡張（長時間ジョブ対応）

2つめの目玉拡張、Tasks。長時間動くツール呼び出しを非同期で扱える。これまでのMCPは同期RPC前提だったので、CIビルド・大規模スクレイピング・バッチ集計のような「数分〜数時間かかる処理」は、タイムアウトとの戦いだった。

Tasksのライフサイクル

Tasks拡張に対応したサーバーは、tools/callに対してタスクハンドルを返す。クライアントはそれを使って状態をポーリングする流れだ。

# タスク開始
POST /mcp
{
  "method": "tools/call",
  "params": { "name": "long_running_build", "arguments": {...} }
}
# 応答（即座）
{
  "result": {
    "ext.mcp.tasks/v1": {
      "taskHandle": "task_8f2a...",
      "status": "running",
      "estimatedMs": 600000
    }
  }
}

# 状態取得
POST /mcp
{ "method": "tasks/get", "params": { "handle": "task_8f2a..." } }

# 途中更新通知（push 又は long-poll）
{ "method": "tasks/update", "params": { "handle": "...", "progress": 0.42 } }

# キャンセル
POST /mcp
{ "method": "tasks/cancel", "params": { "handle": "task_8f2a..." } }

Tasksが効くユースケース

筆者が試した範囲で「Tasksなしでは厳しい」と感じたのは次の3つ。

• 大規模スクレイピング: 数百URLを順次取得して構造化するMCPサーバー。これまでは適当に分割して何度も呼び出していたが、Tasksで1コマンドにまとめられる
• CI/CDトリガー: Claude Codeのブログ自動化で使ったような長時間ジョブを、エージェント経由で起動する場合の進捗管理
• 動画生成・画像バッチ処理: モデル推論に分単位でかかる処理。途中経過を返せると体験が変わる

同期RPCから非同期Tasksへの書き換えコスト

既存サーバーをTasks対応にする場合、最小実装はラッパー1層で済む。ただし「進捗の粒度をどう刻むか」「失敗時のステート遷移」「クライアントの再接続時の再取得」を真面目に考えると、それなりの実装量になる。社内で数日かけてフレームワーク化することを推奨する。

OAuth/OpenID Connect連携の刷新

RC前のMCPは「認証は実装任せ」だった。各サーバーが好き勝手にトークン形式を決めて、クライアント側はそれを丸暗記する――エンタープライズ用途では割と苦しい構造だった。RCではここをOAuth 2.1 / OpenID Connect ベースに寄せ直している。

主な変更点

• Discovery標準化: /.well-known/openid-configurationに近い形でメタデータを公開
• Dynamic Client Registration（DCR）: クライアントが事前登録なしで接続を確立できる
• PKCE強制: パブリッククライアントは必須
• スコープ表現: ツール単位での権限制御を、OAuthスコープに対応付ける推奨パターン

これまで独自トークンで動かしていた社内MCPサーバーをエンタープライズSSOに統合したい場合、RC対応版に移ると AWS MCP Serverのような商用サーバーとの組み合わせが圧倒的に楽になる。Cognito、Auth0、Keycloakあたりが標準パターンとして使える。

実装ではまりやすいOAuth関連の落とし穴

仕様書を真面目に読むと「これは知らないと壊す」というポイントが3つある。実装前に押さえておきたい。

• RFC 9207のissパラメータ検証: 認可コードを受け取ったクライアントは、レスポンスのissがメタデータと一致するか検証しなければならない。これを省くと別IdPから返ってきた認可コードを誤って受け入れる脆弱性につながる
• DCR（Dynamic Client Registration）か事前登録か: 開発時はDCRが楽だが、エンタープライズではIdP側で許可していないことが多い。本番想定なら事前登録パターンも用意しておく
• localhost redirect URI問題: デフォルトのapplication_typeはwebなので、ローカル開発でhttp://localhostを使うとIdPに弾かれることがある。クライアント登録時にapplication_type: nativeを指定する

セキュリティ面の注意

既存MCPサーバーから RC への移行手順

具体的に何から手をつけるか。実プロジェクトで動かした順番をそのまま書く。

ステップ0：非推奨機能の棚卸し

RCで「12ヶ月の移行猶予」付きで非推奨化される機能がいくつかある。仕様確定後12ヶ月で削除されるため、使っているかどうかをまず確認したい。

特に Sampling を「LLM呼び出しの委譲」として使っていたケースは、Elicitation（ユーザー入力を求める仕組み）に切り替える必要がある。意味合いが微妙に違うので、設計の見直しが要る。

ステップ1：SDKのバージョン確認

Python / TypeScript の公式SDKは、RC対応版が dev ブランチに入っている。本番投入は最終仕様（7/28）後の正式リリース待ち、検証用なら今すぐ使える。

# TypeScript
npm install @modelcontextprotocol/sdk@next

# Python
pip install --pre mcp

# Go
go get github.com/modelcontextprotocol/[email protected]

ステップ2：影響範囲の棚卸し

既存コードのうち、RCで挙動が変わるのは主に以下。grepで一発で出る。

ステップ3：本番投入前のチェックリスト

社内で実際に使ったチェックリストを共有する。10項目あるが、Statelessコア化までで5項目はクリアできる。

• セッション保持コードを除去できたか
• tools/list が ttlMs を返しているか
• ロードバランサがラウンドロビン構成になっているか
• 監視ダッシュボードの「セッション」指標を撤去したか
• Mcp-Method ヘッダがログに記録されているか
• Tasksを使うツールの最大実行時間を見積もったか
• OAuth導入時のクライアント変更影響を確認したか
• RC対応クライアントの一覧をドキュメント化したか
• テキストフォールバックのレスポンス形式を整備したか
• 2026-07-28の最終仕様確定後の再検証日を設定したか

対応クライアントと商用エコシステムの現状

RC段階での対応状況は、クライアント側の更新がカギを握る。筆者がドキュメントを横断的に調べた結果、現時点の対応マップは次の通り。

公式に「即日対応」を表明しているのは主に商用サーバー側。クライアント（ChatGPT / Claude / Cursor）はRC期間中に段階的に取り込む形で、最終仕様確定の7/28前後でアップデートが集中する見込み。

商用MCPサーバーの動き

2026年6月時点で、公式に近い形でMCPサーバーを提供している企業は次の通り。商用利用したい場合の選択肢として整理しておく。

• AWS: AWS MCP ServerがGA。DynamoDB / Aurora / Neptune公式対応
• Azure: Azure MCP Serverが公開済み
• Docker: Docker MCP Toolkitで300+コンテナ化サーバー
• Brave Search MCP v2.x: ツール数を36→7に削減し、精度を上げた版がリリース

エンタープライズで導入する場合は、自前実装よりこれらの公式サーバーをベースに拡張する方が、RC対応の追従コストを抑えやすい。

開発現場での使い分け：直近の判断指針

「今すぐ動くか、7/28以降に動くか」――現場で迷うポイントだ。自分なら次のように判断する。

今すぐ動いた方がいいケース

移行コストを抑えるパターン

現場感覚で、移行コストが最も低いのは「StatelessコアだけRC対応、Apps/Tasks/OAuthは段階導入」。Statelessは下位互換性が比較的高く、コードベースを大きく壊さずに済む。Apps以降は新規ツールから順次導入する流れが現実的。

関連記事で押さえておきたいテーマ

MCP本体の理解はMCPとは｜Model Context Protocol完全解説を、サーバー選びはMCPサーバーおすすめ2026を、エージェント全体像はAIエージェントとは？仕組み・活用事例・始め方を合わせて読むと、RC対応の位置づけが立体的に理解できる。

まとめ：2026-07-28に向けて準備すべきこと

MCP 2026-07-28 RCの本質は「リモートMCPサーバーをHTTPの常識で動かせるようにした」こと。Statelessコア・Apps・Tasks・OAuthのいずれも、エンタープライズ運用で行き詰まっていたポイントを的確に潰している。

準備すべき優先順位は明確だ。まずStatelessコアの検証を1〜2週間以内に始める。これが終われば負荷分散の自由度が一気に上がる。次にOAuth対応の設計を着手し、Apps/Tasksは段階的に導入する。

最後に一つ。RCで設計が変わっても、MCPの目的は変わらない――「AIアシスタントが閉じ込められたチャットの壁に、ドアを開けてやる仕組み」だ。RCはそのドアの開け方を、エンタープライズでも壊れずに使えるよう作り直しただけ。仕組みの本質を見失わずに、移行計画を立てたい。