MCP 2026-07-28 移行ガイド: ステートレスサーバー

要約: MCP 2026-07-28 はプロトコルレベルのセッションと必須の初期化ハンドシェイクを削除しました。プロダクションチームは隠れたセッション依存を見つけ、リクエスト単位のプロトコルメタデータを採用し、Multi Round-Trip Requests（MRTR）を実装し、ゲートウェイポリシーを更新し、レガシー動作を廃止する前に新プロトコルをカナリア展開してください。

2026年7月28日にリリースされた Model Context Protocol 仕様は、リモートトランスポート対応が追加されて以来、MCP における最大のアーキテクチャ変更を導入しました。

プロトコルはステートレスなリクエスト／レスポンスコアを採用しました。必須だった initialize および notifications/initialized のやり取りは削除され、Mcp-Session-Id は廃止され、各リクエストが処理に必要なプロトコル情報を持ち運びます。

同時に、Multi Round-Trip Requests、HTTP ルーティングヘッダー、キャッシュ可能な一覧レスポンス、より厳格な認可挙動、拡張フレームワーク、正式な非推奨ライフサイクルも導入されています。プロトコルレベルの詳細は、MCP 2026-07-28 リリース発表（公式）と完全な仕様の変更履歴を参照してください。

これらの変更により、標準的な HTTP インフラの背後でリモート MCP サーバーをスケールしやすくなります。ただし、既存アプリケーションが自動的にステートレスになるわけではありません。

本番サーバーは依然として、メモリ内ワークスペース、スティッキーなルーティング、セッションに紐づく認証情報、長寿命のストリーム、サーバー主導の対話などに依存している可能性があります。本ガイドは、それらの依存を見つけて置き換えることに焦点を当てます。

より入門的な実装手順については、移行を始める前にClaude Code 向けに MCP サーバーを作成する方法を参照してください。

誰が移行する必要があるか？

必要な作業量は、システムにおける MCP の使われ方によって異なります。

リクエスト間の状態を保持しないローカルサーバーは、SDK のアップグレードと互換性テストのみで済む可能性があります。

セッション、OAuth、ストリーミング、サーバー主導のリクエストを使用するリモートデプロイでは、段階的な移行が必要です。

MCP 2026-07-28 で何が変わったか？

1. 既存実装の監査

アップグレード前に、クライアント、サーバー、ゲートウェイ、デプロイ設定から古いプロトコル前提を検索します。

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

次の質問に回答してください：

1. 初期化完了までサーバーは呼び出しを拒否しているか？
2. セッション ID はユーザー、資格情報、ワークスペース、会話の選択に使われているか？
3. 別のサーバーインスタンスが、最初のインスタンスが開始したワークフローを継続できるか？
4. ロードバランサーはセッションアフィニティを要求しているか？
5. ツールは確認を要求する前に副作用を実行していないか？
6. ゲートウェイはメソッドやツールの識別にボディを解析していないか？
7. OAuth 資格情報は発行した認可サーバー情報なしで保存されていないか？
8. クライアントは SSE の再接続やメッセージ再配送に依存していないか？
9. ツールやリソースの一覧は接続ごとに変わらないか？
10. どの非推奨機能が本番トラフィックを受けているか？

アプリケーションが Mcp-Session-Id の背後に何を保存しているかを理解するまでは、Mcp-Session-Id を削除しないでください。

ヘッダーを削除しながら状態をローカルメモリに保持したままのサーバーは、開発中は動作しても、複数インスタンスにリクエストが分散されると断続的に失敗する可能性があります。

2. 隠れたセッション状態の置換

MCP 2026-07-28 で削除されるのはプロトコルレベルのセッションであり、アプリケーション状態ではありません。

呼び出し間で必要な状態は、次のいずれかのパターンを使用してください。

明示的ハンドル

あるツールからサーバー発行のハンドルを返し、後続の呼び出しでそれを必須引数にします。

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

後続のリクエストは通常の引数としてハンドルを渡します：

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

これにより依存がツールコントラクトで可視化され、互換性のある任意のサーバーインスタンスがリクエストを処理できるようになります。

共有ストレージ

以下の場合はデータベース、分散キャッシュ、オブジェクトストア、耐久タスクシステムを使用します：

• 複数のワーカーが同一状態を必要とする
• ワークフローが再起動に耐える必要がある
• ハンドルには大きすぎる状態である
• ワークフローが単一リクエストより長い
• トランザクションまたは単回使用の挙動が必要

保護された requestState

MRTR は、不透明な requestState 値を返し、クライアントは元のリクエストを再試行する際にそれをエコーできます。

この値はクライアントを経由するため、HMAC または認証付き暗号で保護してください。認証済みプリンシパル、元の操作、重要なパラメータ、有効期限、リプレイ防止が必要な場合はノンスにバインドします。

クライアントが変更せずに返したという理由だけで、署名されていない requestState を信用しないでください。

3. 自己完結型リクエストとディスカバリの採用

最新の MCP リクエストは、プロトコルコンテキストを _meta に含みます。

Streamable HTTP のツール呼び出しは次のようになります：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

新しいプロトコルを対象とするサーバーは server/discover を実装し、対応バージョン、機能、サーバーアイデンティティを広告する必要があります。クライアントは別の操作の前に呼び出したり、レガシーフォールバックが必要かどうかの判断に使えます。

レスポンスコントラクトは、公式の server/discover documentation を参照してください。

TypeScript SDK のバージョンネゴシエーション

TypeScript SDK のアップグレードのみでは、クライアントが新プロトコルへ自動移行されるわけではありません。

v2 SDK を使うクライアントは明示的にオプトインする必要があります：

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

自動モードでは、SDK は server/discover でプローブし、レガシーサーバーに到達した場合は古い初期化フローへフォールバックできます。

いまだに @modelcontextprotocol/sdk v1 を使用しているチームは、まず公式のTypeScript SDK v1→v2 移行ガイドに従ってください。既に v2 を使用しているチームは、別途用意された2026-07-28 プロトコル対応ガイドを参照してください。

4. サーバー発リクエストを MRTR に置換

従来の MCP 実装では、elicitation/create、sampling/createMessage、roots/list のようなリクエストをサーバーからクライアントに送信できました。

新プロトコルはこのモデルを Multi Round-Trip Requests に置き換えます。

フローは以下のとおりです：

1. クライアントが元のリクエストを送信する。
2. サーバーが resultType: "input_required" を返す。
3. クライアントが要求された情報または承認を収集する。
4. クライアントが新しい JSON-RPC ID を使って元の操作を再試行する。
5. 再試行には inputResponses と元の requestState を含める。
6. サーバーがリクエストを完了させるか、次のラウンドを開始する。

レスポンス例：

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

クライアントが元の操作を再試行：

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

本番の MRTR 実装では、以下を定義してください：

• 最大ラウンド数
• リクエスト状態の有効期限
• キャンセルと拒否の挙動
• レスポンススキーマ検証
• すべての再試行における認可チェック
• リプレイ防止
• 副作用のべき等性
• クライアントが要求機能をサポートしない場合の挙動

購入、削除、クレジット控除、外部書き込みを input_required を返す前に完了させることは避けてください。

段階的な操作や冪等性キーを使用し、再試行でアクションが重複しないようにします。完全な対話モデルは公式のMRTR 仕様を参照してください。

5. ゲートウェイ、キャッシュ、認可の更新

インフラ変更は密接に関連しているため、まとめてテストするべきです。

MCP ルーティングヘッダーの検証

Streamable HTTP の POST リクエストには次が含まれます：

• MCP-Protocol-Version
• Mcp-Method
• Mcp-Name

これらのヘッダーにより、ゲートウェイはすべての JSON ボディを解析せずにトラフィックをルーティング、メータリング、認可、レート制限できます。

例えば次のような制御が可能になります：

• ツール固有のレート制限
• 一覧系と実行系メソッドのポリシー分離
• 高コストツール向けの専用ワーカープール
• 高リスク操作へのアクセス制限
• ツールごとのレイテンシ／エラーメトリクス
• インフラコストのアトリビューション

これらの値はクライアントが供給する点は変わりません。ポリシー適用前に JSON-RPC ボディと照合してください。

Mcp-Name で低リスクツールを装いながら、ボディで別ツールを呼び出すようなリクエストは許容してはいけません。ヘッダーとボディの不一致は拒否し、ログに記録すべきです。

認可対応のキャッシュキーを使用

新プロトコルでは、次のキャッシュ可能な結果に ttlMs と cacheScope が追加されました：

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

キャッシュキーには通常、以下を含めます：

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

TTL が未満でも、ユーザーやテナントをまたいでプライベートキャッシュエントリを再利用しないでください。

決定的なツール順序も重要です。安定したカタログは不要なキャッシュミスを避け、ツール定義をプロンプトに挿入する場合にモデルのプロンプトキャッシュ再利用を改善する可能性があります。

OAuth 発行者ハンドリングの強化

認可移行の間は次を実施します：

• 返却された iss を、そのフローで記録した発行者と照合して検証
• 保存するクライアント資格情報を発行者でキーイング
• 資格情報を他の認可サーバーで再利用しない
• DCR 中に適切な application_type を設定
• 新規統合で Client ID Metadata Documents に備える

Dynamic Client Registration は後方互換のために利用可能ですが、推奨登録方法としては非推奨です。

6. 通知、Tasks、非推奨機能の移行

従来の HTTP GET 通知パスと resources/subscribe／resources/unsubscribe は subscriptions/listen に置き換えられました。

クライアントは長寿命の POST レスポンスストリームを開き、必要な通知カテゴリにオプトインします。リクエスト固有の進捗とログ通知は、それを記述するリクエストのレスポンスストリームに紐づいたままです。

マルチインスタンスデプロイでは、あるサーバーインスタンスで生成された通知が別のインスタンスに接続された購読に届く必要がある場合、共有イベントバスを使用します。

Tasks 拡張

長時間処理はコアの実験的プロトコルから次へ移動しました：

io.modelcontextprotocol/tasks

この拡張は以下を使用します：

• tasks/get によるポーリング
• tasks/update によるクライアントからサーバーへの更新
• 耐久タスクハンドル
• subscriptions/listen によるオプトイン更新

従来の tasks/result と tasks/list パターンは新実装に持ち込まないでください。

非推奨機能

以下の機能は非推奨です：

非推奨機能は非推奨期間中は利用可能ですが、新規実装で採用すべきではありません。MCP のライフサイクルポリシーは、最低12か月の非推奨期間を提供しますが、すべての機能の確定削除日が同一であることを意味しません。

廃止期限を設定する前に、公式の非推奨機能レジストリを確認してください。

7. 安全な移行のロールアウト

クライアント、サーバー、ゲートウェイ、キャッシュ、認可を、観測なしの1リリースで変更しないでください。

推奨移行順序

1. プロトコルバージョン、SDK、セッション、SSE トラフィック、DCR クライアント、非推奨メソッドの棚卸し
2. 非本番 SDK のアップグレード
3. server/discover とバージョンネゴシエーションの追加
4. 隠れたセッション依存の置換
5. MRTR の実装とセキュリティ対策
6. 検証済みルーティングヘッダーとスコープ付きキャッシュの追加
7. 認可発行者境界のテスト
8. レガシーパスと並行してモダンプロトコルをカナリア展開
9. テレメトリの確認後にのみ旧挙動を廃止

カナリア中の互換性

Modern client + modern server
→ Use MCP 2026-07-28

Modern client + legacy server
→ Probe and fall back when supported

Legacy client + dual-version server
→ Continue on the legacy path

Unsupported combination
→ Return a clear protocol-version error

新しい MCP 仕様のリリースは、エコシステム全体の一斉切り替えではありません。クライアント、サーバー、SDK、ホストプラットフォームは異なる速度で移行します。

記録すべきテレメトリ

成功するワンショットの tools/call だけでは移行を測定できません。繰り返しタイムアウトし、不必要な入力を要求し、外部書き込みを重複させるワークフローは、本番では依然として失敗です。

MCP アーキテクチャにおける CometAPI の位置づけ

MCP はモデル API の代替ではありません。両レイヤーは異なる統合課題を解決します。

典型的な本番アーキテクチャは次のようになります：

Application or agent
        ↓
MCP clients and servers
Tools, resources, approvals, tasks
        ↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models

MCP は、エージェントがツールやコンテキストと対話する方法を標準化します。モデルの価格、プロバイダ資格情報、推論エンドポイント、プロバイダフェイルオーバーは標準化しません。

この分離は、非推奨となった Sampling 機能から移行する際に特に有用です。MCP サーバーまたはそれを消費するエージェントが引き続きモデル推論を必要とする場合、アプリケーションは旧来の MCP Sampling フローに依存するのではなく、モデル API を直接呼び出せます。

統一モデルゲートウェイが役立つ場面

統一モデルゲートウェイは、次の場合に運用作業を減らせます：

• 複数の MCP サーバーが異なるモデルプロバイダへのアクセスを必要とする
• ツールごとに異なるモデルが必要
• プロバイダ固有の統合を書き直すことなくモデルを切り替えたい
• 資格情報、使用量、課金を一元管理したい
• MCP トランスポート変更からモデルアクセスを独立させたい

CometAPI は OpenAI 互換エンドポイントを提供し、MCP アプリケーション背後のモデルアクセス層として使用できます。これにより、モデルプロバイダロジックを MCP のツール・リソース・タスクオーケストレーションから切り離せます。

例えば、MCP ツールはアプリケーションの他の場所で使用しているのと同じ OpenAI 互換クライアントを通じてモデルを呼び出せます：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

MCP サーバーはツールコントラクト、認可、状態、結果処理を担当します。モデルゲートウェイはモデル選択、プロバイダアクセス、推論レスポンスを担当します。

これらのレイヤーを分離することで、実務上の利点が2つあります：

1. MCP クライアントとサーバーは、モデル統合レイヤーを変更せずに新プロトコルへ移行できる。
2. モデルプロバイダを変更しても、MCP ツールやトランスポートの設計を改める必要がない。

実装の詳細は、CometAPI クイックスタート、API ドキュメント、マルチモデル AI アプリガイドを参照してください。

MCP 2026-07-28 移行チェックリスト

クライアント

• 互換 SDK にアップグレード
• 最新のバージョンネゴシエーションを有効化
• server/discover をサポート
• すべてのリクエストにプロトコルメタデータを含める
• resultType を処理
• MRTR をサポート、または明示的に拒否
• 再試行では新しい JSON-RPC ID を使用
• requestState を保持して返却
• OAuth 発行者を検証
• 資格情報を発行者単位で保管
• キャッシュヒントに従う
• 必要に応じて subscriptions/listen をサポート

サーバー

• モダンリクエストの初期化ゲートを削除
• Mcp-Session-Id への依存を除去
• server/discover を実装
• 隠れた状態をハンドルまたは共有ストレージに置換
• resultType を返却
• サーバー発リクエストを MRTR に置換
• requestState を保護
• すべての inputResponses を検証
• 副作用に冪等性を追加
• 決定的な一覧を返却
• 控えめなキャッシュヒントを公開
• 長時間処理を Tasks 拡張へ移行

ゲートウェイとインフラ

• MCP リクエストヘッダーを検証
• ヘッダーとボディを照合
• 不要なスティッキールーティングを削除
• 複数インスタンス間でリクエストをテスト
• 認可境界でキャッシュを分割
• 必要な場合は共有通知バスを追加
• レガシー／非推奨トラフィックを追跡
• カナリア中のロールバックパスを維持

FAQ

MCP 2026-07-28 とは？

MCP 2026-07-28 は 2026年7月28日にリリースされた Model Context Protocol 仕様です。ステートレスなプロトコルコア、Multi Round-Trip Requests、HTTP ルーティングヘッダー、キャッシュ可能な結果、認可変更、拡張、正式な非推奨ライフサイクルを導入します。

Mcp-Session-Id は削除されたか？

はい。新しい Streamable HTTP プロトコルでは Mcp-Session-Id は使用しません。

アプリケーションは、明示的ハンドル、共有ストレージ、耐久タスク、保護されたリクエスト状態値を通じて状態を保持できます。

MCP の初期化ハンドシェイクは削除されたか？

はい。最新のリクエストでは initialize と notifications/initialized のやり取りは不要です。

サーバーは server/discover を実装する必要がありますが、クライアントは毎回呼び出す必要はありません。

ステートレスな MCP はツールが状態を保持できないという意味か？

いいえ。ステートレスとはプロトコル層を指します。

ツールは依然として状態を保存できますが、処理が隠れたトランスポートの親和性や特定のサーバープロセスに依存してはなりません。

MRTR とは？

Multi Round-Trip Requests は、常時開いた双方向接続上でのサーバー発リクエストを送らずに、サーバーが追加のクライアント／ユーザー入力を要求できる仕組みです。

サーバーが input_required を返し、クライアントが要求された応答を付与して元の操作を再試行します。

HTTP+SSE は直ちに削除されるか？

いいえ。直ちに削除ではなく非推奨です。

新サーバーは Streamable HTTP を使用し、既存システムは残存する HTTP+SSE トラフィックを計測して移行してください。

TypeScript SDK v2 クライアントは自動的に MCP 2026-07-28 を使用するか？

いいえ。TypeScript v2 SDK で新プロトコルを使用するには、明示的なバージョンネゴシエーション設定が必要です。

モダンとレガシーの両サーバーで動く必要があるクライアントでは自動ネゴシエーションを使用してください。

最終提言

MCP 2026-07-28 は、リモート MCP インフラのスケーリング、ルーティング、キャッシュ、可観測性を容易にします。主要な移行リスクは、ヘッダーやハンドシェイクの削除そのものではありません。それらに依存していた隠れたアプリケーション状態と対話ロジックです。

新プロトコルをデプロイする前に：

初期化と Mcp-Session-Id への依存をすべて洗い出してください。

1. 必要な状態を明示的ハンドルまたは共有ストレージへ移す。
2. MRTR を有効期限、リプレイ防止、冪等性付きで実装する。
3. MCP ヘッダーを JSON-RPC ボディと照合して検証する。
4. キャッシュをテナントと認可スコープで分割する。
5. OAuth 発行者検証を強化する。
6. 非推奨機能とレガシートランスポートのトラフィックを計測する。
7. レガシーとモダンのプロトコルパスをカナリアで並行提供してから廃止する。

移行は単なる SDK アップグレードではなく、インフラ変更として扱ってください。

MCP レイヤーがステートレスかつ可観測になったら、モデルアクセスは別インターフェースの背後に置いてください。これにより、ツールプロトコルとモデルプロバイダ層を独立に進化させることができます。