はじめに

Model Context Protocol（MCP）の次期仕様リリース候補（RC）が、2026年5月21日にロックされました。最終仕様の公開は2026年7月28日 を予定しており、今後10週間がSDKメンテナと実装者にとっての検証ウィンドウとなります。

今回のRCは、プロトコルの発足以来最大の仕様改訂 です。プロトコルのステートレス化、サーバー側インタラクティブUIの「MCP Apps」、非同期処理の「Tasks Extension」、そして既存機能の段階的廃止と移行ガイドが盛り込まれています。

本記事では、開発者が即座に対応すべき変更点と、7月28日の最終仕様公開に向けて準備すべき内容を解説します。

この記事で解説すること

ステートレスプロトコルへの転換とAPIの変更点
MCP Appsと Tasks Extensionの概要
Roots・Sampling・Loggingの廃止と移行方法
タイムラインと開発者が取るべきアクション

対象読者

MCP対応のAIエージェントやクライアントを開発しているエンジニア
MCP対応サーバーを運用している開発者・企業

前提知識

MCPの基本的な仕組み（ツール呼び出し、リソース、Streamable HTTPトランスポート）
JSON-RPCの基礎

TL;DR

MCPがステートレス化。initialize/initialized ハンドシェイクと Mcp-Session-Id ヘッダーが廃止
MCP Apps：サーバー側がサンドボックスiframe内のHTML UIを提供できる新Extension
Tasks Extension：tools/call がタスクハンドルを返し、tasks/get/tasks/update/tasks/cancel で非同期制御
Roots・Sampling・Loggingが廃止予定（12ヶ月移行ウィンドウ）
最終仕様公開: 2026年7月28日

1. ステートレスプロトコルへの転換

1-1. 最大の変更点：セッションの廃止

従来のMCPは、クライアント接続時に initialize/initialized ハンドシェイクを行い、Mcp-Session-Id ヘッダーでセッションを維持していました。スケールアウトには「スティッキールーティング」または「共有セッションストア」が必要でした。

RCでは、これらがすべて廃止されます。

"any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer."
— MCP 2026-07-28 Release Candidate（2026-05-21）

1-2. クライアントメタデータの移動

セッション確立時に一度だけ送っていたクライアント情報は、毎リクエストの _meta フィールドに移動します。

従来（セッション確立時）:

{
  "method": "initialize",
  "params": {
    "clientInfo": { "name": "my-app", "version": "1.0" },
    "protocolVersion": "2025-11-25"
  }
}

RC（毎リクエストの_meta）:

{
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": { "query": "MCP stateless" },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app",
        "version": "1.0"
      }
    }
  }
}

1-3. 新しいHTTPヘッダー

Streamable HTTPトランスポートでは、ボディを検査せずに操作タイプをルーティングできる2つのヘッダーが追加されます（SEP-2243）。

ヘッダー	値の例	用途
`Mcp-Method`	`tools/call`	ロードバランサーによるメソッドベースルーティング
`Mcp-Name`	`search`	ツール・リソース名によるルーティング

プロトコルバージョンはHTTPヘッダーではなく、毎リクエストの _meta フィールド（io.modelcontextprotocol/protocolVersion）で伝播します。

これにより、通常のラウンドロビンロードバランサーをそのまま使用できます。

1-4. 多段階リクエストの仕組み

ステートレスモデルでは、サーバーが追加入力を必要とする場合に InputRequiredResult を返します。

{
  "resultType": "inputRequired",
  "inputRequests": {
    "confirm": {
      "type": "boolean",
      "prompt": "この操作を実行しますか？"
    }
  },
  "requestState": "eyJ0eXAi..."
}

クライアントは元のリクエストに inputResponses と requestState を付けて再送します。

2. MCP Apps Extension（SEP-1865）

2-1. 概要

MCP Appsは、MCPサーバーがサンドボックス化されたiframe内でインタラクティブなHTML UIを提供できるExtensionです。ツールがUIテンプレートをあらかじめ宣言することで、ホストはプリフェッチ・キャッシュ・セキュリティレビューを実行後にレンダリングします。

UI内のアクションはすべてMCPで使われているのと同じJSON-RPCベースプロトコルを通じてホストに伝達されます。

2-2. 利用シナリオ

データ可視化: ツール結果をインタラクティブなチャートとして表示
フォームUI: 複数ステップの入力フローをUIで実現
ダッシュボード: 複数リソースの状態をリアルタイム表示

2-3. Extensionのネゴシエーション

Extensions全般は、逆DNSスタイルの識別子で管理されます。

{
  "method": "initialize",
  "params": {
    "extensions": {
      "io.modelcontextprotocol.ext-apps": {
        "version": "1.0"
      }
    }
  }
}

3. Tasks Extension（SEP-2663）

3-1. Tasks Extensionの設計思想

従来、TasksはMCPコアの実験的機能でした。RCではExtensionとして独立し、ステートレスモデルに合わせてライフサイクルが再設計されています。

旧設計との主な違い:

tasks/list が削除（セッションなしでは安全にスコープできないため）
タスク作成はサーバー主導（クライアントがExtensionを広告し、サーバーがタスクとして扱うか判断）

3-2. タスクライフサイクル

1. tools/call → { resultType: "task", taskId: "task-abc123" }
2. tasks/get  → { status: "running", progress: 0.5 }
3. tasks/get  → { status: "completed", result: { ... } }

利用可能なメソッド：

メソッド	説明
`tasks/get`	タスクのステータス・結果を取得
`tasks/update`	長時間タスクへの中間入力を提供
`tasks/cancel`	タスクのキャンセルリクエスト

3-3. Pythonサーバー実装例（概念）

from mcp.server import Server
from mcp.server.models import TaskResult

server = Server("my-agent")

@server.tool()
async def long_running_analysis(data: str):
    """長時間実行される分析タスク"""
    # Tasks Extensionが有効な場合、サーバーはタスクハンドルを返せる
    # 実際の処理はバックグラウンドで実行
    task_id = await server.create_task(
        handler=_analyze_data,
        args={"data": data}
    )
    return TaskResult(task_id=task_id)

async def _analyze_data(data: str):
    # 実際の分析処理（時間のかかる処理）
    ...

Tasks ExtensionはSDKレベルのサポートが必要です。Tier 1 SDKは10週間の検証ウィンドウ内でサポートを実装予定です。上記コードの TaskResult クラスや create_task() メソッドは概念的な実装例であり、実際のSDK APIは検証ウィンドウ完了後に変わる可能性があります。最終仕様（2026-07-28）公開後にSDKの公式ドキュメントを参照してください。

4. 廃止予定機能と移行ガイド

3つの機能が「廃止予定」（deprecated）としてアノテーションされました。12ヶ月の移行ウィンドウが設けられており、2027年7月までは引き続き動作しますが、早期移行が推奨されます。

4-1. Roots → ツールパラメータ / リソースURI

廃止理由: Rootsはセッションベースのコンテキスト共有に依存しており、ステートレス設計と相性が悪い。

旧	新
`roots/list` でファイルシステムのルートを共有	ツールの `inputSchema` パラメータとして渡す、またはリソースURIを利用

移行例（ツールパラメータ方式）:

@server.tool()
async def read_file(
    path: str,
    root: str = "/workspace"  # ← rootをパラメータとして明示
) -> str:
    full_path = f"{root}/{path}"
    ...

4-2. Sampling → LLMプロバイダーAPI直接連携

廃止理由: MCPを経由したLLM呼び出しは責任の境界が不明確。クライアントが直接LLMプロバイダーのAPIを呼ぶ設計が望ましい。

移行方法: サーバー側でLLMを呼び出す必要がある場合は、Anthropic API・OpenAI API等を直接呼び出す。

import anthropic

client = anthropic.Anthropic()

# MCPサーバーからLLMを呼び出す場合（Samplingの代替）
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}]
)

4-3. Logging → stderr / OpenTelemetry

廃止理由: MCP専用のLoggingよりも業界標準の観測性ツールへの移行を推奨。

移行先	用途
`stderr`（stdioトランスポート）	シンプルなローカルデバッグ
OpenTelemetry	構造化ログ・トレーシング（本番環境推奨）

5. その他の主要な変更

5-1. キャッシュ制御

リスト・リソース読み取りのレスポンスに ttlMs と cacheScope が追加されます（HTTPの Cache-Control に相当）。

{
  "result": {
    "tools": [ ... ],
    "ttlMs": 300000,
    "cacheScope": "private"
  }
}

5-2. 分散トレーシング（W3C Trace Context）

すべての _meta フィールドにW3C Trace Contextが伝播します。OpenTelemetryとのエンドツーエンドのトレース接続が実現します。

{
  "_meta": {
    "traceparent": "00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01",
    "tracestate": "vendor=value",
    "baggage": "userId=alice"
  }
}

5-3. エラーコードの変更

変更点	旧コード	新コード
リソース未検出エラー	`-32002`（MCP独自）	`-32602`（JSON-RPC標準 Invalid Params）

5-4. JSON Schema 2020-12サポート

ツールの inputSchema・outputSchema がJSON Schema 2020-12の全機能に対応します。

{
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "oneOf": [
          { "type": "string" },
          { "type": "array", "items": { "type": "string" } }
        ]
      }
    }
  }
}

5-5. 認証強化（OAuth 2.0/OIDC準拠）

6つのSEP（Specification Enhancement Proposals）により、OAuth 2.0とOpenID Connectへの準拠が強化されます。

RFC 9207準拠の iss パラメータ検証（クライアント側必須）
Dynamic Client Registration時のOpenID Connect application_type 宣言
認証情報を発行元認可サーバーの issuer にバインド

6. タイムラインと開発者が取るべきアクション

日付	イベント
2026-05-21	RC仕様ロック（本記事執筆時点）
2026-07-28	最終仕様公開
2027-07月頃	Roots・Sampling・Loggingの削除（廃止12ヶ月後）

今すぐ確認すること

initializeハンドシェイクへの依存を洗い出す: セッションIDを使っているコードを検索
廃止機能の使用状況を確認: Roots・Sampling・Loggingを使っているか調べる
Tasks ExtensionのSDKサポートを待つ: Tier 1 SDKのリリースノートを追う

ドラフト仕様の確認方法

# ドラフト仕様（JSON Schema）
curl https://modelcontextprotocol.io/specification/draft | jq .

# 変更ログ（2025-11-25との差分）
open https://modelcontextprotocol.io/specification/draft/changelog

RC期間中は破壊的変更が入る可能性があります。本番環境への適用は最終仕様（2026-07-28）の確認後を推奨します。

まとめ

変更カテゴリ	内容	対応優先度
ステートレス化	initialize廃止、_metaへのクライアント情報移動	高（破壊的変更）
MCP Apps	サーバー側HTML UI Extension	中（新機能）
Tasks Extension	非同期タスクの標準化	中（新機能）
Roots廃止	ツールパラメータ/リソースURIへ移行	高（廃止予定）
Sampling廃止	LLMプロバイダーAPIへ直接移行	高（廃止予定）
Logging廃止	stderr/OTelへ移行	中（廃止予定）
エラーコード変更	-32002 → -32602	高（破壊的変更）

今回のRCは「プロトコル発足以来最大の改訂」と位置付けられており、水平スケールの容易化・Extension体制によるプロトコルの進化など、エンタープライズ用途での利用を大きく後押しする内容となっています。最終仕様（2026-07-28）までの10週間で、SDKサポートの進捗を追いながら移行準備を進めることをおすすめします。

参考リンク

MCP 2026-07-28 Release Candidate — 公式RC発表ブログ（2026-05-21）
MCP ドラフト仕様 — RC仕様書
MCP 2026ロードマップ — 優先開発領域の詳細（2026-03-05更新）
MCP GitHub Discussions — SEP一覧・議論