Anthropic、Simon Willison、そしてステートレスMCPへの転換

Anthropicは2024年にMCPを導入したが、その後Simon Willisonはターミナルツールのほうが柔軟だと判断した。しかし、2026年7月28日の仕様は、その評価の一部を覆した。プロトコルセッションを廃止し、リモートMCP呼び出しを自己完結したリクエストへと変えたためだ。

この変更によりWillisonは再び関心を寄せ、mcp-explorerとdatasette-mcpという2つのプロジェクトが生まれた。さらに重要なのは、リモートMCPサーバーが通常のHTTPサービスよりデプロイしにくかったというアーキテクチャ上の弱点に対処したことだ。

したがって、AnthropicとSimon Willisonをめぐるこの話は、単なるプロトコル更新ではない。MCPがコマンドラインツールとの競合をやめ、より防御可能な役割に落ち着けるかどうかの試金石である。Skillsは既存ソフトウェアの使い方をエージェントに教える手段として依然魅力的であり、一方のステートレスMCPは、構造化されたリモートツール、検出、認可、共有インフラを提供する。

ステートレスMCPは、すべてのリクエスト経路からセッションを取り除く

新仕様は、MCPを接続中心のプロトコルからリクエスト中心のプロトコルへと変える。

Model Context Protocolは、AIエージェントが外部ツールを検出し、呼び出すための標準インターフェースを定義する。Anthropicは2024年11月にこれを導入し、開発者はデータベース、ブラウザー、コミュニケーションプラットフォーム、業務アプリケーション向けのサーバーをすぐに多数開発した。

従来のバージョンでは、通常のツール呼び出しの前に初期化プロセスが必要だった。クライアントとサーバーはプロトコルバージョン、機能、識別情報を交換する。このネゴシエーションによって、以降のメッセージで維持されるべきコンテキストが確立されていた。

HTTPサーバーはMcp-Session-Idを発行することもできた。クライアントは後続のリクエストでその識別子を返す。この仕組みにより、一連の呼び出しは、特定のクライアントとサーバーインスタンス間で継続する一つの会話のように扱われた。

この設計はインフラ面の影響を生んだ。ロードバランサーは関連する呼び出しを正しいインスタンスへルーティングするか、セッションデータを共有ストレージに置く必要があった。運用者には、期限切れ、再接続、復旧、クリーンアップに関するポリシーも必要だった。

最終版の2026-07-28改訂では、必須のinitializeハンドシェイクが廃止された。プロトコルレベルのセッションと、それに関連するヘッダーも削除された。各リクエストには、独立して解釈するために必要な情報が含まれるようになった。

公式のMCPリリースでは、この改訂をプロトコル開始以来最大の変更と説明している。ステートレスな中核に加え、拡張機能、改訂されたTasksサポート、認可の変更、正式な機能ライフサイクルが導入された。

クライアントは現在、ツール呼び出しを直接送信できる。リクエストには、プロトコルバージョン、メソッド、ツール名、クライアント情報、関連する機能が含まれる。互換性のあるサーバーインスタンスであれば、以前のやり取りに依存せずに処理できる。

この変更では、必要に応じてクライアントがサーバー機能を要求できるserver/discoverも追加された。検出のために、すべての呼び出し元がプロトコルセッションを作成・維持する必要はなくなった。

これは、すべてのアプリケーションが状態を捨てなければならないという意味ではない。ブラウザー自動化サービス、ショッピングカート、データベーストランザクション、調査ワークフローは、呼び出しをまたいで情報を保持できる。

違いは、その情報がどこに存在し、どのように参照されるかにある。セッションの背後に隠すのではなく、サーバーは明示的な識別子を返せる。モデルは後続の呼び出しでその識別子を渡す。

たとえばブラウザーサーバーは、インスタンスの起動後にbrowser_idを返せる。後続のツールは、ページ遷移、ページのキャプチャ、ブラウザーの終了時にその値を受け取れる。データベースツールも、トランザクション識別子に同じパターンを適用できる。

採用されたセッションレス提案では、こうした値を明示的な状態ハンドルと説明している。これは新しいMCPデータ型ではない。アプリケーションの状態を可視化する、通常のツール入力と出力である。

この可視性はエージェントにとって重要だ。オーケストレーターは、あるハンドルをサブエージェントと共有しつつ、別のハンドルを分離しておける。また、後の作業のために識別子を記録したり、認可された別プロセスに渡したりもできる。

一覧操作には別の利点もある。ツールとリソースが曖昧なセッションに応じて変化できなくなるため、クライアントは検出結果をより安全にキャッシュできる。これにより、短命なエージェント間での繰り返し呼び出しが減る。

ステートレスMCPは、一般的なHTTP操作にもより自然に対応する。リモートサーバーは、標準的なラウンドロビン負荷分散、通常のゲートウェイルーティング、リクエスト単位の認証、確立済みのオブザーバビリティシステムを利用できる。

この組み合わせがWillisonの関心を再び呼び起こした。今回の更新は、単にハンドシェイクを短縮しただけではない。以前はすべてのデプロイとクライアント実装に影響していた、アーキテクチャ上の前提を取り除いたのである。

AnthropicとSimon Willisonの評価転換が重要な理由

Willisonが再び関心を示したことは重要だ。彼の以前の批判は、コーディングエージェントの利用者の間で起きていたMCP離れという実際の変化を捉えていたからである。

MCPは2025年の大半を通じて強い注目を集めた。その価値提案は理解しやすかった。サーバーインターフェースを一度実装すれば、同じツールを複数の互換AIクライアントに公開できる。

しかし同時期に、コーディングエージェントも進化していた。安定したターミナルアクセス、より優れたシェル操作、ドキュメントを調査する能力の向上を得た。多くはライブラリをインストールしたり、curlで従来型のAPIを呼び出したりできるようになった。

これは直接的な課題を生んだ。十分に文書化されたコマンドラインプログラムは、すでに合成可能なツールインターフェースを提供している。エージェントはプロトコルアダプターなしで、コマンドを組み合わせ、出力をリダイレクトし、小さなスクリプトを書き、エラーを調査できる。

Skillsはこの道筋を強化した。スキルとは、エージェントにタスクの実行方法を教えるための、指示、スクリプト、参照資料のパッケージである。所有者にMCPサーバーの運用を求めずに、既存APIの使い方を説明できる。

Willisonは2025年の振り返りで、その懐疑論を要約した。コーディングエージェントについては、MCPよりもコマンドラインユーティリティとライブラリを好んだ。これらの選択肢は、別のサービス層を避けながらモデルにより大きな自由度を与えるからだ。

この批判は、構造化されたツール呼び出しに価値がないというものではなかった。より難しい問いは、MCPがセッション、トランスポート管理、クライアント互換性対応、コンテキストのオーバーヘッドを正当化するだけの追加価値を提供するかどうかにあった。

ステートレスMCPはその差を縮める。小規模なリモートツールは、エージェントクライアント向けの機械可読な契約を保ちながら、従来のWebエンドポイントに近い振る舞いができるようになった。

WillisonのステートレスMCP分析は、この変更を2つの実験に結び付けている。1つ目は、MCPサーバーをより簡単に検査・理解できるようにするmcp-explorerだ。2つ目は、新しいアプローチをDatasetteに適用するdatasette-mcpである。

Datasetteは、構造化データの探索と公開のためのWillisonのオープンソースシステムだ。すでにWebインターフェースとAPIを通じてデータベースを公開している。MCPは、ツールを利用する言語モデル向けに特化して設計された別の接点を提供する。

この組み合わせは示唆に富む。Datasetteのデプロイは本質的にリモートであり、構造化され、複数ユーザーで共有される。エージェントの横にインストールする開発者向けユーティリティほど、ローカルのコマンドラインモデルには自然に収まらない。

MCPサーバーは、クライアントが理解できるスキーマを使ってデータベースツールを公開できる。エージェントはクエリを送信する前に、利用可能な操作を確認できる。サーバー運用者は認証、権限、制限、実装詳細の制御を維持する。

このため、AnthropicとSimon Willisonの比較は、MCP対Skillsというほど単純ではない。スキルはAPIのクエリ方法をエージェントに教えられる。MCPは、そのAPIを検出・呼び出しするための共有契約を多くのクライアントに提供できる。

この2つのアプローチは連携も可能だ。スキルは、MCPサーバーをいつ使うべきかを説明し、そのドメイン概念を解説したり、複数ツールにまたがるワークフローを提供したりできる。MCPはリモート実行の境界を担える。

この分担により、MCPがあらゆるエージェント操作に対する万能な答えになるべきだという圧力は減る。ローカルコマンドはローカルのままでよい。ライブラリは柔軟なコーディングタスクに対応できる。Skillsは運用上の知識をパッケージ化できる。

MCPは、サーバーが実行を制御し、複数クライアントが同じ検出可能なインターフェースを必要とする場面で、より明確な役割を得る。エンタープライズデータ、ホスト型検索、共有サービス、認証された業務システムは、このパターンに適している。

したがって、プロトコルの簡素化は競争上の問いを変える。開発者は、すべてのツールにMCPラッパーが必要かどうかを問う必要がなくなる。代わりに、リモート機能が標準化された検出と呼び出しの恩恵を受けるかを問える。

これは、初期のMCPに対する最も広い解釈よりも控えめな約束だ。しかし、より信頼できる。標準は、その境界が明確になった後に有用になることが多い。

ステートレスリクエストにより、MCPは一般的なクラウドインフラに適合する

MCP 2.0が重要なのは、一般的なデプロイ経路から特殊な調整を取り除くためだ。

採用されたステートレス提案は、従来の初期化モデルにおける3つの問題を指摘している。セッションはスケーリングを複雑化し、障害復旧を弱め、両側の実装作業を増やした。

3つのサーバーインスタンスで動作するリモート検索ツールを考えてみよう。セッション指向の設計では、後続の呼び出しが初期化を処理した同じインスタンスを必要とする場合がある。基本的なラウンドロビン負荷分散では、その結果を保証できない。

運用者はスティッキールーティングでこの問題を解決できる。セッションデータを共有サービスに保存することもできる。だが、どちらの方法も運用上の状態、追加の障害モード、新たな監視要件を持ち込む。

スティッキーセッションでは、作業の配分が不均一になり得る。共有ストアは別の依存関係を作る。サーバーの再起動によってローカル状態が無効になり、クライアントは障害を検出して初期化をやり直さなければならない場合がある。

新しいリクエストモデルでは、正常な任意のインスタンスが互換性のあるツール呼び出しを処理できる。ゲートウェイは接続履歴ではなく、メソッドとツールメタデータに基づいてルーティングできる。

この変更により、サーバーレスでのデプロイもより現実的になる。需要に応じてインスタンスを起動・停止するプラットフォームは、リクエストが以前のリクエストのメモリに依存しない場合に最もよく機能する。

サーバーには、本当に永続すべきアプリケーション状態のための永続ストレージが依然として必要だ。ステートレスMCPはデータベース、オブジェクトストア、ブラウザーワーカー、ジョブキューをなくすものではない。プロトコル状態がそれらに付随しなければならないという前提を取り除くのである。

長時間実行される操作は、拡張機能ベースのモデルに収まるようになった。サーバーはタスクハンドルを返し、クライアントは後から明示的な操作を通じてそのタスクを確認、更新、キャンセルできる。

この違いは重要だ。隠れたセッション状態は、ワークフローをトランスポート上の関係に結び付ける。タスクハンドルはワークフローを、他の認可済みコンポーネントが管理できるアドレス指定可能なリソースへと変える。

Multi Round-Trip Requestsは、別の難しいケースに対応する。一部のツールは、完了前にユーザーまたはクライアントから追加情報を必要とする。従来の実装では、そのやり取りは確立済みセッションに関連付けられていた。

新設計では、サーバーはクライアントリクエストを処理している間に限り、サーバー起点のリクエストを行える。相関データはリクエストとレスポンスのサイクルを通じて伝達され、恒久的なプロトコルセッションを回避する。

これは一部の振る舞いを制限する。サーバーは、起点となった呼び出しのはるか後に予期せずクライアントへ連絡することはできない。この制約は柔軟性を下げるが、ユーザープロンプトにより明確な起点とライフサイクルを与える。

ツールの発見も、ルーティングとキャッシュが容易になる。仕様では、メソッドとツールのメタデータをHTTPヘッダーに追加する。ゲートウェイは、すべてのリクエスト本文を解析しなくても、そのメタデータを検査できる。

サーバーは、リスト応答にtime-to-live値を付与できる。クライアントは、短命なサブエージェントごとに同じリストを要求する代わりに、許可された期間内でツール情報を再利用できる。

セッションレス提案は、従来の挙動では、サブエージェント数とサーバー数の積に比例して発見トラフィックが繰り返し発生し得ると警告している。ステートレスなリストにより、オーケストレーターはそのコストを回避するための、より良い基盤を得られる。

これは、エージェントシステムがより分散化するにつれて重要になる。1件のユーザーリクエストが、プランナー、複数の専門ワーカー、検証役を起動することがある。各分岐で初期化と発見を繰り返せば、レイテンシーとトラフィックが増える。

改訂されたプロトコルでは、ツール定義にJSON Schema 2020-12を全面的に採用している。JSON Schemaは、必須フィールド、型、検証ルールを含む構造化データを記述するための標準語彙だ。

より豊かなスキーマは、より正確な入力と出力を記述できる。これによりクライアントは、呼び出しの検証やインターフェース構築に役立つ情報を得られる。また、曖昧に書かれたツール説明への依存も減らせる。

拡張機能は、アーキテクチャ上の分離を実現するもう一つの形態だ。MCP Appsはサーバーレンダリング型のインターフェースを提供でき、Tasksは長時間の操作を扱う。これらの機能は、あらゆる能力をプロトコルの中核に押し込むことなく進化できる。

正式なライフサイクルでは、機能の非推奨化から最短でも12か月間は削除しない。この明確な断絶の後、移行作業がなくなるわけではないが、実装者にはより明確な計画期間が与えられる。

公式のTypeScriptガイダンスは、移行には依然として意図的な作業が必要であることを示している。SDK migration guideによれば、新しいワイヤーフォーマットには、既存のすべてのアプリケーションを黙って変更するのではなく、明示的な採用が必要となる。

この慎重さは妥当だ。新しい仕様を公開しただけで相互運用性が生まれるわけではない。クライアント、サーバー、ゲートウェイ、SDKは同じ詳細を実装し、実際のワークロードで検証しなければならない。

それでも、この仕組みは具体的な弱点に対処している。MCP固有のセッション機構を、クラウドチームが一般的なHTTPサービスですでに使っているパターンに置き換えるものだ。

明示的な状態は新たなセキュリティと信頼性の課題を生む

ステートレスMCPはインフラ上の摩擦を減らす一方、ツール設計、認可、エージェントのメモリにより大きな責任を移す。

明示的なハンドルにより、状態は可視化され、持ち運び可能になる。こうした利点は同時に、機密性の高い識別子が現れ得る場所を広げる。ハンドルは、チャット履歴、プロンプト、ログ、トレース、クリップボードの内容、サブエージェント間のメッセージに入り込む可能性がある。

サーバーは、識別子を知っていることだけを十分な認可と見なしてはならない。呼び出しごとに、ハンドルと認証済みのIDの両方を検証すべきだ。

これは、多くの文書・プロジェクトサービスで使われる設計に似ている。リソースIDはオブジェクトを特定し、現在の認可コンテキストが、呼び出し元がそれを読み取ったり変更したりできるかを決める。

認証のないサービスは、より難しい問題に直面する。その場合、予測困難なハンドルはベアラートークンのように機能し得る。それを入手した者は誰でも、ハンドルの有効期限が切れるまで基盤となる状態にアクセスできる。

セッションレス仕様は、こうしたケースでは高エントロピーの識別子と有効期間の制限を推奨している。この推奨は実装ガイダンスにとどまる。MCPはワイヤーレベルのハンドル型を定義していないためだ。

ここには強制のギャップが生じる。クライアントは、返された文字列のうちどれが生きた状態を表すのかを自動的には認識できない。ツール名や説明が役割を伝えない限り、browser_idは他の値と変わらない。

そのため、オーケストレーターは、どの識別子がコンテキスト圧縮後も保持されなければならないかを常に把握できるとは限らない。また、どの値にクリーンアップが必要か、あるいは別のサブエージェントに渡すべきでないかを判断するのにも苦労する可能性がある。

モデルは通常、ファイルパス、コミットハッシュ、URL、トランザクション識別子を扱う。それでも、ハンドルを誤ってコピーしたり、省略したり、長い会話が要約された際に失ったりすることがある。

セッション状態にも関連する弱点があった。クライアントは一貫しない有効期間を用い、多くは切断後にセッションを復元しなかった。セッションを廃止すればこうした問題は明示化されるが、状態管理が自動化されるわけではない。

クリーンアップにも未解決の詳細がある。セッションの終了はかつて、リソースを解放するための理論上のシグナルを提供していた。実際のクライアントはしばしば、セッションを頻繁に終了しすぎたり、終了が遅すぎたり、無関係なページ再読み込み後に終了したりした。

明示的なワークフローには、独自の有効期限と破棄ポリシーが必要だ。ブラウザーサービスは、アイドルタイムアウトを強制しつつ、close_browserを提供するかもしれない。タスクサービスは、完了した結果を定められた期間保持するかもしれない。

後方互換性は、導入期の運用上の複雑さを増す。セッションIDに依存する既存サーバーは、状態モデルを変更せずに新しいプロトコル改訂を受け入れることはできない。

必要に応じて、クライアントとSDKは旧来の改訂版をネゴシエートできる。これは段階的な移行を可能にするが、開発者がテストすべき2つの挙動経路も生み出す。

一部の能力は、ステートレスHTTPのもとでは直接的でなくなる。自発的な通知や長期にわたるサーバー主導のインタラクションは、独立したリクエストにはそれほど自然に収まらない。拡張機能とリスニング機構が、その役割を担う必要がある。

また、セッションがなくなるだけで、すべてのMCP統合が効率的になる保証もない。設計の悪いスキーマはコンテキストを消費し得る。大規模なツールカタログはモデルを混乱させる可能性がある。不明瞭な説明は、依然として誤った呼び出しを引き起こし得る。

Skillsやコマンドラインツールは、この点で利点を維持する。コーディングエージェントは、多くの場合、大きなリモートツールカタログを読み込まずにプログラムのヘルプ出力を調べ、短いスクリプトを書ける。

ローカルツールは、機密データをユーザーのマシン上にとどめることもできる。リモートMCPのデプロイには、ローカル実行では回避できる認証、ネットワーク露出、ロギング、サービス可用性の懸念が伴う。

MCPはプロンプトインジェクションも解決しない。ツールを利用できるエージェントは、トランスポートがステートフルかどうかにかかわらず、非公開情報、信頼できない入力、外部通信を組み合わせる可能性がある。

サーバー運用者は権限と出力を制約しなければならない。エージェントの構築者は、どのツールを併用可能にするかを制御しなければならない。ユーザーには、重要な結果を招く操作に対する明確な承認境界が必要だ。

これらの制約は、Anthropic Simon reversalを最も強く解釈する見方に異議を唱える。Willisonが再び関心を示したことは、アーキテクチャ変更を裏付けるものであり、すべてのMCP実装や提案されたすべてのサーバーを保証するものではない。

mcp-explorerとdatasette-mcpは、実務上の疑問を明らかにする有用な初期実験だ。クライアントは一貫してツールを発見できるか。スキーマは理解しやすいか。認証と状態ハンドルは実際のワークフローを通じて維持されるか。

ステートレスMCPを支持する最も強い根拠は、相互運用性の証拠から生まれる。独立したクライアントがカスタムパッチなしで独立したサーバーに接続でき、運用者が一般的なインフラを使ってそれらをデプロイできるべきだ。

その証拠が増えるまで、MCP 2.0は完成した勝利ではなく、より優れた基盤にとどまる。プロトコルは摩擦の大きな要因を一つ取り除いた。結果として生じるシステムが安全で理解可能なままであるかは、依然として実装者にかかっている。

MCP 2.0後に開発者が注目すべきこと

次の試金石は、リポジトリ数の再びの急増ではなく、SDK、実際のサーバー、クライアント全体での導入だ。

最初のシグナルは、2026-07-28改訂版に対する実装カバレッジだ。公式SDKには、発見、リクエストごとのメタデータ、明示的な能力、Tasks、認可の挙動に対する一貫したサポートが必要となる。

バージョンラベルだけでは不十分だ。開発者は適合性の結果とクロス言語テストを注視すべきだ。Pythonサーバー、TypeScriptクライアント、マネージドゲートウェイは、同じリクエストとエラーについて一致しなければならない。

強力なSDK間互換性は、MCPが現在、安定したリモートツール境界を提供するという主張を強める。永続的な不一致は、開発者をクライアント固有のアダプターへと戻してしまい、この主張を弱める。

2つ目のシグナルは、本番サーバーがステートフルなワークフローをどう移行するかだ。ブラウザー自動化、トランザクション、ショッピングカート、長時間のリサーチジョブは、明示的なハンドルにとって厳しい試験となる。

成功した移行では、信頼できるクリーンアップ、リクエストごとの認可、ハンドルの受け渡し、コンテキスト圧縮が示されるべきだ。また、エージェントが識別子を失ったり繰り返したりした場合に何が起きるかも文書化すべきだ。

こうしたパターンが再利用可能になれば、明示的な状態は曖昧なセッションより優れた抽象化に見えるだろう。すべてのサーバーが互換性のないライフサイクル規則を発明するなら、プロトコルは複雑さを減らすのではなく移しただけになる。

3つ目のシグナルは、MCPとSkillsの関係だ。エージェントプラットフォームは、ローカルコマンド、スキルに導かれたAPI呼び出し、リモートMCPサーバーのどれを選ぶのかを示すべきだ。

明確な選択ルールは、より限定的な論旨を強める。MCPは共有されたリモート能力を担い、Skillsは指示とローカルワークフローをパッケージ化することになる。

重複が続けば、保守作業が重複する可能性がある。ツール所有者は、同じ能力のためにAPI、CLI、スキルパッケージ、MCPサーバー、クライアント固有の統合を必要とするかもしれない。

開発者は、その重複を不可避なものとして扱うべきではない。スキルはMCPサーバーを参照でき、MCPサーバーは既存のAPIをラップできる。有用な問いは、どのインターフェースが永続的な契約を担うかだ。

データツールについては、Willisonの実験が具体的な観察対象となる。DatasetteはすでにWeb APIを通じて構造化情報を提供している。datasette-mcpは、エージェント向けの契約が発見性と安全なクエリを改善するかどうかを試せる。

ナレッジワークフローを構築するチームも、同様の選択に直面する。ローカルの文書やノートは、多くの場合、非公開で検索可能なエンジニアリングナレッジベースに適している。共有ビジネスシステムには、認証されたリモートツールのほうが適しているかもしれない。

重要なのは、共通プロトコルによって接続が容易になったからといって、1つのエージェントに無制限のツール群を与えないことだ。標準化は統合作業を減らすが、権限設計の代わりにはならない。

Anthropic Simon Willison reversalが価値を持つのは、それが真の懐疑の時期を経たものだからだ。MCPはブランディングによって再び注目を集めたのではない。そのメンテナーは、批評家がデプロイ済みのシステムで指摘できた構造的な負担を取り除いた。

プロトコルはこのように進化すべきだ。失敗した仮定から得た証拠を吸収し、責任範囲を絞り、一般的な操作をより考えやすくする必要がある。

今後3か月間、実際に使っているクライアントとサーバーを調べてほしい。最終改訂版をサポートしているか、アプリケーション状態をどう表現しているか、認可が各ハンドルに追随しているかを確認しよう。

次に、その結果を最も単純な代替手段と比較する。ローカルコマンドのほうが明確なままなら、それを使い続ければよい。多くのエージェントが1つの統制されたリモート能力を必要とするなら、ステートレスMCPを試し、相互運用性が依然として失敗する箇所を記録しよう。