0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

MCP 2026仕様RC解説 — ステートレス・MCP Apps・Tasks移行ガイド

0
Last updated at Posted at 2026-06-29

はじめに

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ヶ月後）

今すぐ確認すること

  1. initializeハンドシェイクへの依存を洗い出す: セッションIDを使っているコードを検索
  2. 廃止機能の使用状況を確認: Roots・Sampling・Loggingを使っているか調べる
  3. 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サポートの進捗を追いながら移行準備を進めることをおすすめします。

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?