はじめに
MCP（Model Context Protocol）の解説記事は世の中にたくさんありますが、「Memory Server を実装/運用している側にとって、4月の変更は何が嬉しいのか」を中心に書かれたものを見かけなかったので、自身の整理も兼ねてまとめます。
🎯 想定している読者
- 自前のMCP Memory Serverを実装・運用している、または検討している方
- Claude DesktopやCursor、WindsurfからMCP経由でメモリを参照しているが、出力の打ち切りや待ち時間に違和感を感じている方
- マネージドの Memory Server を採用しようとしていて、評価軸をアップデートしたい方
なお、本記事ではAnthropic公式の Memory MCP server（知識グラフ型）と、Mem0系のOpenMemory、私たちが運用している Memorylake のような第三者の Memory Server を区別せずに「Memory Server」とまとめて呼びます。純粋な設計の話に集約したいためです。
Claude Code 4月の変更ポイント（4つ）
公式のリリースから、Memory Server の挙動に直結するのは以下の4つです。
| 変更項目 | 旧仕様 | 新仕様 |
|---|---|---|
| ツール単位の出力上限 | 制限により切り詰め必須 | 500,000文字 |
| MCPサーバ接続 | シリアル（直列） | 並行接続（パラレル） |
| ツール探索 | 全ツール定義をSystem Promptに常駐 | Tool Search（必要に応じて検索） |
| ツール読み込み | セッション開始時にロード | Lazy loading（必要時にロード） |
それぞれ単体ではそこまでインパクトが大きく見えないのですが、Memory Server の場合、この4つが組み合わさると設計の前提が大きく変わります。 順に見ていきます。
① 出力上限 500,000文字
今回、これが一番大きい変更です。
たとえば「先週何をやっていたか思い出させて」というクエリに対して、本来 Memory Server 側は次のようなペイロードを返したいはずです。
- 関連する会話の要約
- 関連ドキュメントからの抜粋（出典付き）
- イベントのタイムライン
- ユーザの好み・規則メモ（stable memory）
ただ、旧仕様だと出力上限のせいで切り詰めて「要点だけ」を返す設計にせざるを得ませんでした。リッチに返したくても、抜粋や出典を削ってサイズを合わせる、というジレンマが常にありました。
500,000文字あれば、上記をまとめて返しても余裕があります。 検索結果と原文抜粋を両方含めても破綻しません。
注意：「とりあえず全部詰める」は逆効果
出力上限が増えたからといって、モデルが全部読んでくれるわけではなく、Attention（注意力）の問題は別途残ります。返すなら「構造化されたフォーマット」が必須です。
私が実装で意識している返し方の構造は、だいたい次のような形です。
「ヘディング（見出し）、出典、タイムスタンプ」
これらが入っていると、モデルが要約や再利用をする際に拾いやすくなります。逆に、500K近くを散文の塊で返すと、容量に収まってもうまく活用してもらえません。
② MCPサーバの並行接続
旧仕様だと、Claude は登録されたMCPサーバを順番に呼んでいました。「Memory Server に問い合わせ」→「戻ってきてから GitHub MCP に問い合わせ」というシリアル動作です。
並行接続に対応したことで、1ターン内で複数MCPサーバが並列に呼び出されるようになりました。Memory Server の recall と Filesystem の読み込みが同時に走る形になるので、レイテンシ視点でもユーザー体験が明確に変わります。
⚠️ ハマりどころ：レート制限（Rate Limit）の見直し
個人的に一番引っかかったところです。Memory Server がIPベースのレート制限を持っているとして、旧仕様では「1ターンに1回」呼ばれることを前提に設定していたはずです。
新仕様では、複数のツール経由で1ターンに3〜5回呼ばれる可能性があります。
マネージドのMemory Serverを使っている場合は、提供側のレート制限ポリシーが新仕様を前提にしているか確認しておくのが安全です。
③ Tool Search
Claude が「今のタスクに必要なツール」を検索して呼び出せるようになりました。
旧仕様では、登録されたツールの説明は全部 System Prompt に常駐していたため、ツールが多くなるとプロンプト容量（Prompt Budget）を食いつぶしてしまう問題がありました。Memory Server だけで10個以上のツールを公開しているケースもあったので、これは地味に効きます。
Memory Server 側で対応・意識すべきこと：
-
ツール名は自己説明的に（
search_memory,fetch_memory,list_projectsなど） - Description は短くし、検索でヒットしやすい単語を含める
- 5〜10個に厳選する（不要なものは公開しない）
※ tools_v2_internal_legacy_workaround のような名前は Tool Search で全くヒットしないので、命名規約は早めに整えておくのがおすすめです。
④ Lazy loading
ツールスキーマが「必要になってから」読まれるようになりました。Tool Search との合わせ技で、未使用のツール定義がプロンプト容量を奪わなくなります。
Memory Server 側に追加で対応することは特にありません。普段通り tools を登録しておけば、Claude 側が必要なときに引いてくれます。
Memory Server 設計への影響（まとめ）
4月の変更で前提が変わるのは、突き詰めると以下の2点です。
1. 「切り詰めて返す」設計から「構造化されたリッチな payload を返す」設計へ
- 旧: 容量に収まる範囲で最小限を返す（最小化問題）
- 新: モデルが消化できる範囲で、構造化された最大限有用なものを返す（最適化問題）
Memory Server の recall ロジック自体を見直す価値があるレベルの変化です。
2. 「シリアル前提」の挙動を捨てる
レート制限、トランザクション境界、キャッシュ戦略など、すべて「並行で呼ばれる」前提に書き直す必要があります。並行になることで、依存先（ベクトルDBやグラフDB）への呼び出しもスパイクするため、サーキットブレーカーや依存ごとのバジェット管理が以前より重要になります。
動作確認について
手元で簡単に確認するなら、Claude Desktop の config を新仕様用に書き換えて、旧クエリと同じものを投げ直すのが手っ取り早いです。
開発者ツールでMCPのリクエストログを見ると、memory と filesystem への問い合わせがほぼ同時刻で発火しているのが確認できます（旧仕様だとここがシリアルでした）。
なお、ここで測るべきは「速度」ではなく「想起の完全性（Recall Completeness）」だと思っています。速度の改善はプロバイダ・負荷状況で揺れますが、「本当に必要な情報がレスポンスに含まれているか」は設定変更の効果を判断する一番素直な指標です。
おさらい：実運用の落とし穴（Tips）
実運用に近いところで踏みやすい落とし穴を3つにまとめます。
-
散文の塊は500Kでも読まれない
大きい payload を返せるからといって、構造化を怠ると逆効果です。マークダウン等で適切に構造化しましょう。 -
並行接続でレート制限を踏む
1ターン3〜5回呼ばれる前提に、APIのRate Limit上限を引き上げる必要があります。 -
Secret は一度しか表示されない
API Key 系の Memory Server を採用する場合、初回生成時に確実にバックアップを取る運用を徹底しましょう。
おわりに
出力上限 500K + 並行接続の2つによって、Memory Server が返せる payload の「量」と「速度」が両方広がりました。Tool Search と Lazy loading も、ツール数が多い環境では確実にプロンプト容量の節約に効いてきます。
ちなみに私たちは Memorylake の MCP Server 側で、現在進行系で同様の整理を行っています。クロスモデル前提（ChatGPT / Claude / Gemini が同じ Memory を共有する）で運用しているため、この並行接続の挙動と500K出力上限はかなりありがたいアップデートでした。
Memory Serverを開発・運用されている方の参考になれば幸いです。