Anthropic MCP 史上最大の仕様変更

Anthropicが7月28日、MCPの仕様変更を発表しました。
最大の変更は、MCPが「接続を維持するセッション型プロトコル」から、原則ステートレスなHTTPリクエスト／レスポンス型へ変わったことです。

一言でいうとこれまでのMCPは、AIクライアントとMCPサーバーが接続を確立し、その接続状態を維持しながら処理する仕組みでした。
今後は、各リクエストが必要な情報を自分で持ち、どのMCPサーバーインスタンスでも処理できる仕組みになります。

つまり、MCPが特殊なAI専用接続基盤から、通常のWeb APIに近い運用可能なプロトコルへ変わるということです。

何が変わったのか

■1. セッションが原則なくなる

旧仕様では最初にinitializeを実行し、サーバーからMcp-Session-Idを受け取り、その後のリクエストに付け続ける必要がありました。

新仕様では以下が廃止されます。

- initialize / initializedハンドシェイク
- Mcp-Session-Id
- MCPプロトコル側で管理するセッション

クライアント情報や対応機能は、各リクエストの_metaに含めます。

※ 変化のイメージ

旧MCP

```
Claude
↓ initialize
MCP Server A
↓ session_id発行
Claude
↓ 以後ずっとServer Aへ接続
MCP Server A
```

新MCP

```
Claude
↓ tools/call
MCP Server A / B / Cのどれでも処理可能
```

■2. 普通のクラウド構成で動かせる

セッションを持たなくなるため、MCPサーバーは次の環境へ置きやすくなります。

- Cloud Run
- AWS Lambda
- Cloudflare Workers
- Vercel Functions
- Netlify Functions
- Kubernetes
- 通常のロードバランサー配下

従来必要だったものが大幅に減ります。

- Sticky Session
- 共有セッションDB
- 常時起動プロセス
- 特定サーバーへの固定ルーティング
- 長時間SSE接続

普通のラウンドロビン型ロードバランサーで水平分散できるようになります。

■3. 状態が必要な処理は「明示的なID」で管理する

ステートレス化しても、ブラウザ操作や買い物カゴなどの状態を持つ処理が不可能になるわけではありません。

例えばサーバーが、

```
{
"browser_id": "browser-123"
}
```

を返し、次のツール呼び出しでモデルがそれを渡します。

```
{
"browser_id": "browser-123",
"url": "https://example.com"
}
```

つまり、状態が暗黙のセッション内部に隠れるのではなく、モデルが認識できる明示的なハンドルになるということです。

これはエージェント設計上かなり重要です。

- 状態を別エージェントへ引き継げる
- ワークフローを途中から再開できる
- 実行記録を追跡しやすい
- 複数ツール間で同じ状態を共有できる
- 障害復旧しやすい

■4. 長時間処理は「Tasks拡張」になる

長時間かかる処理は、MCPコアに組み込むのではなく、正式なTasks Extensionとして分離されました。

例えば、

- 大量ファイルの解析
- 動画生成
- 長時間リサーチ
- データ移行
- コード生成とテスト
- 複数段階の業務処理

などです。

サーバーは通常のtools/callに対して、処理結果ではなくtask handleを返せます。
その後、クライアントが以下を実行します。

- tasks/get
- tasks/update
- tasks/cancel

旧実験仕様に存在したtasks/listは削除されました。セッションなしでは安全なスコープ管理が難しいためです。

■5. MCP Appsが正式な拡張になる

MCPサーバーは、ツールだけでなくインタラクティブなUIも返せるようになります。
例えば、

- 承認画面
- データ入力フォーム
- KPIダッシュボード
- 検索結果一覧
- ファイル選択画面
- タスク進捗画面
- 差分レビュー画面

UIはサンドボックス化されたiframe内で動き、UIから行われる操作もMCPの監査・承認経路を通ります。
MCPは単なる「AIからAPIを呼ぶ規格」ではなく、AIエージェント向けのバックエンド＋UI配布プロトコルに近づきます。

■6. OAuth・OIDCが企業利用向けに強化される

認証仕様も強化されています。
主な変更は以下です。

- OAuth認可レスポンスのiss検証
- OpenID Connectのapplication_type明示
- 認可サーバーごとのクライアント登録情報の分離
- Refresh Token取得方法の明確化
- Step-up認証時のscope蓄積ルール
- .well-known discovery仕様の明確化

Entra ID、Oktaなどの企業IdPと接続しやすくなります。

■7. MCP通信をルーティング・キャッシュ・追跡できる

HTTPヘッダーに次の情報が追加されます。

- MCP-Protocol-Version: 2026-07-28
- Mcp-Method: tools/call
- Mcp-Name: search

ロードバランサーやAPI Gatewayが、JSON本文を解析せずに、

- ツール別ルーティング
- レート制限
- アクセス制御
- 監査
- 利用量計測

を行えます。

また、tools/listなどには以下が追加されます。

- ttlMs
- cacheScope

ツール一覧をキャッシュできるため、毎回同じ一覧を取得する必要がなくなります。

OpenTelemetryのtraceparent等も標準化され、ClaudeからMCPサーバー、さらにその先のAPIまで一つの分散トレースとして追跡できます。

廃止方向になる機能

以下は非推奨になりました。

- 機能今後の代替
- Roots ツール引数、Resource URI、サーバー設定
- Sampling LLMプロバイダーAPIへの直接接続
- Logging stderrまたはOpenTelemetry

ただし、即座に削除されるわけではありません。最低12か月の非推奨期間が設定されます。

■実務的な結論

エンドユーザーが直ちに体感する変化は限定的です。主要な変化はMCPサーバーの開発・運用側にあります。

ただし長期的には、次の変化を促します。

- MCPサーバーがサーバーレスで大量に提供される
- 企業内MCPをロードバランサー配下で運用できる
- 長時間タスクが標準化される
- MCP内に業務UIを埋め込める
- OAuth・監査・権限管理が企業基盤に統合される
- エージェント処理の中断・再開・移管が容易になる

要するに、MCPは、ローカルでClaudeにツールを追加する仕組みから、企業規模でAIエージェント、業務システム、UI、長時間タスクを接続する標準基盤へ変わりつつあります。

https://claude.com/blog/bringing-mcp-2026-07-28-to-claude

中西将史