2026-07-28仕様で実際に何が変わったのか
プロトコルレイヤーからセッションが消失
initialize/initializedのやり取りは廃止されました。サーバーはオプションとして機能検出のための新しいserver/discover RPCを実装できますが、必須ではありません。リクエストパスにおいて事前のハンドシェイクは想定されておらず、通信上でリクエスト同士を紐付けるものはありません。
仕様書では、これが何を意味し、何を意味しないのかが直接的に述べられています。「プロトコルレベルのセッションを廃止したからといって、アプリケーションをステートレスに強制するわけではありません。サーバーがコール間で状態を維持する必要がある場合は、ツールから明示的なハンドルを発行し、モデルにそれを引数として返させてください。」
これを2回読み返してください。プロトコルは状態の管理をあなたに差し戻し、そのメカニズムを提示しました。それは、モデルによって渡され、アプリケーションによって理解される「明示的なハンドル」です。ハンドルとはポインタです。そのポインタが指し示す先が、あなたが依然として構築しなければならない部分です。
ステートレス化に伴い追加されたもの
今回のリリースは、単なる機能の削減だけではありません：
- Multi Round-Trip Requests (MRTR) により、サーバーは永続的な接続なしで、実行の途中でクライアントにリクエストを返すことができます。
Mcp-MethodおよびMcp-Nameによるヘッダーベースのルーティングにより、ゲートウェイはJSONボディをパースすることなくフィルタリングとルーティングを行えます。- キャッシュ可能なリスト結果により、リストおよび読み取りレスポンスに
ttlMsとcacheScopeが追加され、クライアントはサーバーが許可する限りtools/listをキャッシュできるようになります。 - Tasksは、AWSの貢献により、ポーリングベースの操作を伴う信頼性の高い長期実行ワークフローのための正式な拡張機能として、実験的コアから昇格しました。
- MCP Appsも同じ正式な拡張機能フレームワークに加わりました。
- 最低12ヶ月の非推奨期間（deprecation window）が適用されるようになり、Roots、Sampling、Logging、およびDynamic Client Registrationが非推奨となりました。
- Tier 1 SDK（TypeScript、Python、Go、C#）のアップデート版がリリースされ、Rust SDKはベータ版となっています。
すでに Claude で稼働中
Anthropicは同日、Claudeアプリ、Claude PlatformおよびAPI、Claude Code全体で新しい仕様のサポートをリリースしました。これには、会話内のインタラクティブなUIのためのMCP Apps、EntraやOktaなどのアイデンティティプロバイダー向けのOAuth 2.0/OIDCに準拠したエンタープライズ管理の認証、公開コネクタ用のオブザーバビリティダッシュボード、そしてリサーチプレビュー版のMCPトンネルが含まれます。Claudeのコネクタディレクトリには、現在950以上のMCPサーバーが掲載されています。
つまり、これは様子見できるような仕様変更ではありません。あなたのエージェントがClaude Codeやコネクタと通信しているなら、その足元はすでにステートレスなコアに移行しています。
なぜステートレス化がエージェントの記憶喪失の原因でも治療法でもないのか
セッションは決してメモリではなかった
MCPセッションは、接続が維持されている間（数分、時には数秒）しか持続しませんでした。エージェントの記憶喪失は、まったく異なる時間軸で発生します。明日の朝、次のスプリント、あるいはチームメイトが同じ顧客について3回目に質問するときなどです。古いステートフルな世界であっても、クライアントを閉じればセッションが知っていたことはすべて失われていました。
セッション状態はトランスポートの帳簿管理にすぎませんでした。メモリとは、あなたの仕事の蓄積された結論です。この2つを混同していたため、開発チームは決して永続性を保証していないレイヤーに対して永続性を期待し続けてしまったのです。
実際に何が壊れるのか
実際にセッション状態に依存していたパターンは、パニックが示唆するよりも限定的です。ツール呼び出しの間に中間状態をメモリに蓄積していたサーバー、セッションIDをキーとするハンドシェイク由来のキャッシュ、そしてクライアントを特定のワーカーに固定するためにスティッキーセッションを必要としていたゲートウェイなどです。これらは再構築が必要ですが、リモートサーバーを単純なラウンドロビン負荷分散の背後に配置できるようになるというメリットもあります。
壊れないもの：接続の外部に耐久性のある状態をすでに保存していたすべてのものです。あなたのナレッジがデータベース、ファイルストア、またはメモリサービスに存在していた場合、7月28日の変更はリコール（想起）に何の影響も与えず、むしろデプロイをシンプルにしました。
メモリは今後どこに存在すべきか
仕様書の回答（ハンドルを発行し、モデルにそれを返させる）は、正しくもあり、不完全でもあります。状態をどのように参照するかは示していますが、状態がどこに存在すべきか、どのような形状をとるべきか、あるいは3つの異なるモデル上の5つの異なるエージェントがそれをどのように共有すべきかは示していません。それこそが、あなたが今所有しているレイヤーであり、偶然ではなく意図的に構築する価値のあるものです。
開発チームが頼りがちな回避策
巨大なコンテキストウィンドウ
最先端モデルは現在、数百万トークン単位のコンテキストウィンドウをアピールしており、それをメモリとして扱いたくなる誘惑に駆られます。しかし、それはメモリではありません。コンテキストウィンドウは、モデルが「このターン」で読み取ることができる範囲にすぎません。何をそこに入れるかを決定し、毎ターンそれらのトークンに対して支払いを行い、次回はまた空の状態で開始する必要があります。検索に適用される同様の区別については、RAGがメモリではない理由を参照してください。
各ツールの組み込みメモリ
Claude、ChatGPT、そしてほとんどのエージェントフレームワークは、現在独自のメモリ機能を搭載しています。それぞれが真に有用ですが、同時に完全にサイロ化されています。コーディングエージェントがデプロイパイプラインについて学んだことは、インシデントレポートを起草するアシスタントには届きません。また、タスクをより安価なモデルにルーティングした際、それらのメモリが引き継がれることもありません。
ハンドルと自作データベースの組み合わせ
これは仕様書が指し示している道であり、一部のチームにとっては正しい選択肢です。しかし、これは抽出、保存、検索ランキング、スコープ設定、有効期限、およびマルチエージェントのアクセス制御を自ら実装することを意味します。さらに、周囲のプロトコルが進化し続ける中で、これらを維持管理していく必要があります。メモリ自体が自社製品であるなら価値はありますが、製品に至るまでの配管（インフラ）にすぎない場合は、非常にコストがかかります。
解決策：セッションを超えて存続するメモリレイヤーをエージェントに提供する
仕様書のアドバイスを永続的な形にするには、セッション、再起動、モデルの切り替えによって失われないサービスにメモリを配置することです。MemoryLakeは、まさにその役割のために構築されています。現在どのクライアントが接続されているかに関係なく、エージェントがMCPまたはAPIを介して読み書きできる単一のメモリレイヤーを提供します。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを送信できます。このステップの何ものもセッションに依存しません。これこそが重要なポイントです。
ステップ 2: 最初のメモリをアップロードする
アーキテクチャのメモ、ランブック、顧客のコンテキスト、過去の決定事項など、エージェントが常に必要とするドキュメント、画像、ファイルをドロップします。これこそが、ハンドルが指し示すべき状態（ステート）です。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、およびその他のエージェントに、MCPまたはAPIを介してそのメモリへのアクセスを許可します。2026-07-28のコア仕様のもとでは、各コールは独自のアイデンティティを持ち、同じメモリに到達します。スティッキールーティングも、維持すべきセッションも不要です。クライアント固有のウォークスルーについては、Claude Codeにメモリを追加する方法を参照してください。サーバーを開発している場合は、ステートレスなMCPサーバーのためのメモリが実装者側の内容をカバーしており、MCP Tasksのためのメモリが長期実行ワークフローをカバーしています。
実務において何が変わるのか
「説明し直す」コストを計算してみましょう。あなたの常時コンテキスト（技術スタック、規約、現在の優先事項、すでに決定された事項など）が2,000トークンあり、あなたやエージェントがそれを1日に20回再送信するとします。これは毎日40,000トークン、月に約120万トークンを、すでに述べたことを再確認するためだけに費やしていることになります。トークン料金は些細な問題です。実際に感じるコストは、すべてのセッションの開始時に行われる4〜5分間の再ブリーフィングと、誰もそれを面倒がって行わなかったときにエージェントが犯すミスです。
永続的なメモリレイヤーは、これをセッションごとの「税金」から、1回限りの書き込みへと変換します。また、マルチエージェントの作業に一貫性をもたらします。2つのエージェントが会話の書き起こし（トランスクリプト）ではなくメモリを共有する場合、2番目のエージェントは1番目のエージェントの結論から開始できます。この問題については、マルチエージェントメモリで別途詳しく読む価値があります。
ステートレスなMCP世界におけるメモリのベストプラクティス
トランスクリプトではなく結論を保存する
生のログは際限なく肥大化し、検索の精度も低下します。「キューモードがインプロセスメモリを破損したため、チャット履歴にはRedisではなくPostgresを選択した」という情報は保存する価値があります。しかし、そこに至るまでの40通のメッセージは不要です。
接続ではなく、作業にメモリを紐付ける
セッションは廃止されました。誤ってセッションを再構築しないようにしてください。メモリのスコープをプロジェクト、リポジトリ、顧客、またはタスクに設定します。これらは、どのクライアントが呼び出しているかに関係なく、来月になっても同じ意味を持つものです。
意図的に整理し、バージョン管理を行う
古いメモリは、メモリが全くない状態よりも悪影響を及ぼします。エージェントがそれを信頼してしまうからです。事実に所有者と有効期限を設定し、ある決定が以前の決定を上書きした場合はそれを記録して、両方の情報がプール内に混在しないようにします。
結論
2026年7月28日にMCPがステートレスになったことは、エージェントのメモリを削除したわけではありません。プロトコルがメモリを保持しているという幻想を終わらせただけです。セッションはトランスポートであり、リコール（想起）ではありませんでした。仕様書は現在そのように明記しつつ、あなたにメカニズム（明示的なハンドル）を渡し、その実体をあなたに委ねています。
この変更をアップグレードと感じるチームは、メモリがすでに接続の外部に存在しているチームです。デプロイはよりシンプルになり、リコール能力は維持され、エージェントは前のエージェントが中断したところから再開できます。この変更を損失と感じるチームは、セッションが代わりに記憶してくれることを期待していたチームです。このレイヤーを一度構築することは、説明し直す税金を永遠に支払い続けるよりも安上がりです。