【日次ログ】MCPのステートレス化 ― 新仕様と利用中の接続を分けて確認する

訂正（2026-09-05）： 初稿の「サーバーレス対応になった」「主要サービスが対応済み」という一括した説明を見直しました。Tasksの移動とMCP Appsの新規導入も混同していました。本稿は公式資料の照合であり、自社の接続安定性を実測した記事ではありません。

結論：仕様公開だけでは手元の接続は変わらない

2026年7月28日公開のMCP仕様は、プロトコルのセッション管理を見直したものです。ただし、仕様が公開されたことと、利用しているクライアント・接続先が採用したことは別です。アプリの更新だけを根拠に「接続が安定した」と判断することもできません。

当サイトの運用で利用している個々の接続について、採用プロトコル版や移行前後の失敗率は確認していません。以下は9月5日に公式資料を再確認した整理と、今後の点検項目です。

公式資料で確認できた変更

公式変更履歴では、初期化の交換とプロトコルレベルのセッションをなくし、リクエストごとに必要な情報を渡す設計が示されています。追加情報を求めるMRTR、キャッシュ情報、認可の強化も変更点です。実験的なTasksはコアから拡張へ移動しました。MCP Appsを今回初めて導入したという意味ではありません。

公式ブログはサーバー側の接続管理を簡素化する利点を説明しています。一方で、アプリケーションが呼び出し間の状態を必要とする場合、その状態まで不要になるわけではないとも説明しています。したがって「従来はサーバーレス配置が不可能だった」「共有する業務データが一切なくなる」という理解は避けるべきです。

製品の対応状況を一括しない

Claude側の7月28日発表は、Claude製品への対応を展開していく説明です。個別サービスの紹介や賛同コメントは、すべての機能が、すべての利用環境へ届いた証拠にはなりません。

初稿の「公式ディレクトリだけで950以上」も対象が曖昧でした。同発表が数えているのはClaudeのコネクタディレクトリに掲載されたMCPサーバーであり、MCP全体の公式レジストリの件数ではありません。この記事では導入判断に不要なダウンロード件数の比較も削除しました。

実務への影響：先に接続単位の点検表を作る

以下は当サイトの編集上の提案です。実施済みの試験結果ではありません。

立場	最初に記録するもの	それだけでは判断できないこと
SaaSの接続を使う人	製品名、接続先、提供者の対応案内	SDKの公開だけで、そのSaaSの対応を断定できない
自作サーバーの管理者	クライアントとサーバーの版、HTTP/stdioなどの接続方式	片側の更新だけで互換性を保証できない
運用を監視する人	同じ操作の成功・失敗、条件、時間帯	1回の成功を安定性の向上とみなせない

利用者としては、まず提供者の更新案内を確認し、不明なら「未確認」と残します。自作サーバーなら、使っている機能を変更履歴に照らし、検証用の接続で既存操作が維持されるか確かめる順序が適切です。本番の権限や認可設定を、記事の要約だけで変更する手順は勧めません。

特に認可の説明は、すべての接続へ同じ変更を適用する指示ではありません。HTTPかstdioか、どの認可方式を使っているかを特定したうえで、該当仕様と提供者の移行案内を確認する必要があります。本稿は認可設定の実装ガイドではありません。

次に確認することと限界

次の観測では、実際に使っている接続を一つ選び、「双方の対応版」「使う機能」「同じ操作の実行結果」をセットで記録します。対応版が分からないまま、変更の効果をMCPの新仕様に帰属させません。

今回行ったのは説明の訂正であり、MCPサーバーの構築、移行、負荷試験は行っていません。旧ニュース記事として保管し、独自の実測記事には数えません。