Claude Codeのサブエージェントがメモリを共有しない理由
隔離（アイソレーション）こそが、価値ある機能である
まずは、サブエージェントの本来の目的から整理しましょう。Claude Codeのドキュメントでは、サブエージェントのユースケースを、メインの会話を検索結果やログ、二度と参照しないファイル内容で埋め尽くしてしまうような「サイドタスク」として説明しています。「サブエージェントは独自のコンテキストでその作業を行い、要約のみを返します」。それぞれが「カスタムシステムプロンプト、特定のツールへのアクセス権、独立した権限を持つ、独自のコンテキストウィンドウ内で実行されます」。
これは優れたトレードオフであり、崩すべきではありません。1万行のテスト出力は適切な場所に留まり、メインの会話には3行の要約だけが届きます。しかし、この仕組みが意味することに注目してください。サブエージェントが作業の過程で理解したこと（エラーラッパーの存在、命名規則の癖、2つのモジュール間の不整合など）は、すでに消え去ったコンテキストウィンドウの中にしか存在しません。戻ってきたのは要約であり、その要約はサブエージェントが「伝える価値がある」と判断したものに限られます。
メインの会話のメモリは境界を越えない
Claude Codeには、デフォルトで有効になっている自動メモリ（auto memory）機能があります。ここでは、Claudeが作業を進めながら、ビルドコマンド、デバッグの洞察、発見した好みなどを独自のメモとして書き込みます。これらはリポジトリごとに ~/.claude/projects/<project>/memory/ 以下に保存され、すべての会話の開始時に MEMORY.md インデックスとしてロードされます。
「すべての会話」と書きましたが、サブエージェントの会話は例外です。ドキュメントにははっきりとこう記されています。「メインの会話の自動メモリは、サブエージェントにはロードされません」。唯一の例外は、親の会話とシステムプロンプトをそのまま引き継ぐ「フォーク（fork）」です。したがって、先週の火曜日にメインセッションがこのリポジトリについて学んだことは、今日あなたが起動したサブエージェントの目の前には存在しないのです。
各サブエージェントのメモリは個別のディレクトリに保存される
サブエージェントは独自のメモを保持することができ、これは有効にする価値があります。サブエージェントの定義に memory フィールドを追加すると、会話をまたいで存続する永続的なディレクトリが割り当てられます。ドキュメントでは、これを「コードベースのパターン、デバッグの洞察、アーキテクチャの決定など、時間をかけて知識を蓄積する」場所と説明しています。利用可能なスコープは3つあります。user は ~/.claude/agent-memory/<name-of-agent>/ に書き込み、project は .claude/agent-memory/<name-of-agent>/ に書き込んでバージョン管理（Git）を通じて共有可能、local は .claude/agent-memory-local/<name-of-agent>/ に書き込んでGitの管理対象外とします。
これらのパスを注意深く読んでみてください。私たちの疑問に対する答えは、このディレクトリ名にあります。メモリはエージェント名ごとにスコープされています。レビュアーエージェントが蓄積した知識はレビュアーのフォルダにあり、テスト作成エージェントには独自のフォルダがあります。両者が共通して読み込む「共有フォルダ」は存在しません。また、この機能には2つの便利な仕様（と、それに伴う制限）があります。サブエージェントのシステムプロンプトには、その MEMORY.md の最初の200行または25KBのいずれか早い方が含まれます。そして、この仕組み全体が自動メモリの一部であるため、autoMemoryEnabled または CLAUDE_CODE_DISABLE_AUTO_MEMORY で自動メモリをオフにすると、memory フィールドは一切機能しなくなります。
2つの組み込みサブエージェントは CLAUDE.md もスキップする
もう一つ、多くの人を驚かせるギャップがあり、これもドキュメントに明記されています。「ExploreとPlanは、調査を迅速かつ低コストで行うために、CLAUDE.mdファイルと親セッションのgitステータスをスキップします。それ以外のすべての組み込みおよびカスタムサブエージェントは、両方をロードします」。
Exploreは、コードベースを読みに行くサブエージェントです。開発ルールを最も知っておいてほしいエージェントであるにもかかわらず、意図的にそれを読み込まないようになっています。これはパフォーマンスを考慮した合理的な判断ですが、メインの会話に提供される調査結果は、開発基準を読んでいないエージェントによって行われたものであることを意味します。
そして、そのメモリはマシンから外に出ない
自動メモリはローカルマシンに限定されています。ドキュメントは明確です。リポジトリ内のすべてのワークツリーとサブディレクトリは1つのディレクトリを共有し、「ファイルはマシン間やクラウド環境間で共有されません」。エージェントごとのディレクトリも同様です（project スコープのものをコミットしない限り）。
つまり、エージェントチームが蓄積した知識は、1台のノートPC上のエージェントごとのフォルダに存在し、意図的にコミットしない限り、他のツールやチームメンバーからは見えません。ビルドコマンドを記録するだけならこれで十分ですが、「なぜ特定のモジュールに触れてはいけないのか」といった重要な理由を共有するには不十分です。
よく試されるアプローチとその限界
すべてを `CLAUDE.md` に書き込む。 最初のステップとしては正しく、ExploreとPlanを除くすべてのサブエージェントに届きます。制限はサイズです。ドキュメントでは、ファイルが長くなるとコンテキストを消費し、指示への追従性が低下するため、1ファイルあたり200行未満に抑えることを推奨しています。4つのサブエージェントが学んだことをすべて収められるほど肥大化した CLAUDE.md は、誰も従わないルールブックになってしまいます。
サブエージェントのプロンプトを長くする。 固定の指示には有効ですが、新しい発見には対応できません。エラーラッパーの存在を知った後にテスト作成エージェントに伝えることはできますが、そもそも「レビュアーは知っていたが、あなたは知らなかった」という状況を解決したいはずです。
サブエージェントにファイルへの書き出しを指示する。 「学んだことを notes/review-findings.md に保存して」。これは効果的であり、実質的にメモリ機能を手動で構築しているようなものです。しかし、エージェントが4人になり、ファイルが4つになり、誰がどれを読むべきかのルールがなくなると破綻します。
代わりにフォーク（fork）を使用する。 フォークは親の会話とシステムプロンプトを引き継ぐため、「これまでの議論を知らない」という問題は解決します。しかし、本来得られるはずだったコンテキストの節約効果は失われます。自分の思考を並行して進めるには適していますが、ノイズの多いタスクを隔離するには不適切なツールです。
エージェントごとのメモリを有効にして、それで十分だと期待する。 この機能自体は有効にすべきです。ドキュメントでも、バージョン管理を通じて知識を共有できるように project スコープが推奨されています。ただし、これを「共有の脳」として期待してはいけません。これはエージェントごとのノートであり、ドキュメントでもまさにそのように説明されています。
実行するサブエージェントの数を減らす。 3回ほど矛盾に直面すると、この結論に行き着く人がいます。確かに機能はしますが、大きな損失です。エージェント間の連携不足を避けるために、余計なコンテキストコストを支払うことになります。
解決策：すべてのエージェントが参照できる単一のストアを提供する
隔離（アイソレーション）は維持すべきです。変えるべきなのは、「隔離されたコンテキスト」と「隔離された知識」が現在同一視されている点であり、これらは切り離すことができます。
機能する構成は、メインの会話とすべてのサブエージェントが読み書きでき、エージェントごとのメモリを置き換えるのではなく、その横に並ぶ「共有ストア」です。1つのタスクを超えて重要な発見（エラーラッパー、決定事項、非推奨のヘルパーなど）はそこに保存され、すべてのエージェントが同じバージョンを参照します。エージェントごとのメモリは、そのエージェントの専門領域に真にローカルな情報を保持し続けます。
MemoryLake は、そのためのメモリレイヤーです。決定事項、開発ルール、ソースドキュメントが保存される単一のストアであり、MCPを介して Claude Code やそのサブエージェント、Codex、そしてAPI経由で ChatGPT からもアクセスできます。エージェントごとのノートを増やすのではなく、複数の読者が存在する1つの記録を作成します。
ステップ 1: APIキーを作成する
キーを生成すれば、約30秒で最初のリクエストを送信できます。セッションに直接貼り付けるのではなく、環境変数やシークレットマネージャーに保存してください。
ステップ 2: 最初のメモリをアップロードする
エージェントが何度も再発見しがちなドキュメント、画像、ファイルをアップロードします。開発ルール、アーキテクチャの決定、ルールの背景にある障害報告書、APIコントラクト、「触るな危険」リストとその理由などです。要約ではなく、ソースそのものをアップロードしてください。要約はサブエージェントがすでに提供しているものであり、その情報の圧縮こそが解決すべき問題だからです。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、その他のAIエージェントに、MCPまたはAPI経由でメモリへのアクセス権を付与します。Claude Codeは、CLAUDE.md ファイルと並行してMCP経由でこれを読み込みます。また、サブエージェントごとにアクセスのスコープを設定することも可能です。ドキュメントによると、サブエージェントの mcpServers フィールドにインラインでMCPサーバーを宣言すると、そのツールの説明がメインの会話のコンテキストに一切入り込まなくなります。サブエージェントはツールを利用できますが、親エージェントは利用しません。これにより、親のコンテキストを消費することなく、レビュアーとテスト作成エージェントに同じメモリを提供できます。
実務における変化
第一の変化は、発見がそれを生み出したタスクよりも長生きすることです。レビュアーがエラーラッパーに気づいて共有ストアに書き込み、テスト作成エージェントが1時間後にそれを読み込みます。お互いを見ることができない2つのエージェントの間で、あなたが伝言板になる必要はありません。
第二に、CLAUDE.md を十分に短い状態に保つことができます。指示への追従性が低下するサイズまでファイルを肥大化させる代わりに、固定のルールはファイルに残し、蓄積された詳細は検索（retrieval）に移行します。これは、セッションごとにコードベースを再読み込みするエージェントのコストが高くなるのと同じ理由です。知識は存在していますが、エージェントが探す場所にないだけなのです。
第三に、知識がノートPCの寿命を超えて存続します。自動メモリやエージェントごとのメモリは設計上ローカルマシンに限定されていますが、共有ストアを使用することで、チームが必要とする部分（決定事項、理由、開発ルール）が、1人の開発者のローカルファイルではなくなります。これにより、同僚が「なぜここが触れないのか」をあなたに直接尋ねる必要がなくなり、システムに問いかけることができるようになります。
そして、これは Claude Code がネイティブに行うことと衝突しません。自動メモリはリポジトリごとにビルドコマンドやデバッグメモを書き込み続け、エージェントごとのメモリは各サブエージェントの専門知識を蓄積し続けます。どちらも、本来不向きな「信頼できる唯一の情報源（System of Record）」になる必要はありません。この役割分担こそが、1つのメモリ上で複数のエージェントを動かすことを可能にする仕組みです。
サブエージェントメモリのベストプラクティス
エージェントごとのメモリを project スコープで有効にする
ドキュメントでは memory: project が推奨されていますが、これには正当な理由があります。このディレクトリはバージョン管理の対象となるため、サブエージェントが蓄積した知識をホームディレクトリに閉じ込めることなく、チームでレビューできるようになります。local は、本当にコミットすべきではないメモにのみ使用してください。
メモリの読み書きを明示的に指示する
ドキュメントでもまさにこれが推奨されています。作業を開始する前にメモリを参照し（「以前に見たパターンがないかメモリを確認して」）、終了した後に更新する（「学んだことを保存して」）ようサブエージェントに促します。さらに良いのは、これらの指示をサブエージェント自身のMarkdown本文に記述しておくことで、あなたが意識しなくても自己メンテナンスが行われるようにすることです。
MEMORY.md はインデックスとして保ち、倉庫にしない
ロードされるのは MEMORY.md の最初の200行または25KBまでです。これを超える内容はセッション開始時にロードされません。1つのエントリーにつき1行に抑え、詳細はトピックファイルに逃がし、Claudeが必要に応じて読み込めるようにします。静かに溢れてしまうメモリインデックスは、短いインデックスよりも厄介です。なぜなら、コンテキストに入っていると誤解してしまうからです。
Explore は開発ルールを読んでいないと仮定する
ExploreとPlanは設計上 CLAUDE.md をスキップするため、彼らの調査結果が開発ルールを考慮していると思わないでください。調査結果を元にコードを編集する場合は、実行時に該当するルールを再提示するか、Exploreがクエリできる共有メモリを提供するのが、より永続的な解決策になります。
メモリを強制力のある設定と混同しない
Claude Codeのドキュメントには、指示ファイルや自動メモリは「コンテキストであり、強制された設定ではない」とあり、厳格な準拠は保証されないと明記されています。常に真であるべきこと（生成されたファイルには絶対に触れない、常にリンターを実行するなど）は、フックやCIチェックに記述すべきです。メモリは「知る」ためのものであり、フックは「保証する」ためのものです。メモリをコンプライアンスツールとして売り込もうとする人がいれば、それは誇大広告です。
発見だけでなく、その理由も書き残す
「決済モジュールはカスタムエラーラッパーを使用している」という事実は、後に疑問を持たれる可能性があります。「決済モジュールは、アップストリームのクライアントがステータスコードを握り潰してしまうため、カスタムエラーラッパーを使用している（3月の障害を参照）」という事実であれば、次のエージェントや次のエンジニアから疑問を持たれても、その妥当性を維持できます。
まとめ
Claude Codeのサブエージェントがメモリを共有しないのは、コンテキストを共有しないからであり、その隔離こそが機能の本質です。それぞれが独自のウィンドウで動作し、要約のみを返します。メモリの状況は「メモリが全くない」というよりも、もう少し複雑です。エージェントごとに、その名前に紐づいたディレクトリ（user、project、またはlocalスコープ）に永続的なメモリを持たせることができます。存在しないのは「共有の場」です。メインの会話の自動メモリはサブエージェントにロードされず、エージェントごとのディレクトリはお互いを参照せず、ExploreとPlanは CLAUDE.md を完全にスキップし、そのすべてが1台のマシン内に留まります。
したがって、隔離は維持したまま、共有の部分を解決しましょう。エージェントごとのメモリを project スコープで有効にし、MEMORY.md はインデックスとして保ち、Exploreはルールを読んでいないものとして扱い、複数のエージェントにとって重要な知識は、全員が参照できる1つのストアに集約します。そうすれば、2番目のエージェントは最初のエージェントが学んだことから作業を開始でき、あなたがサブエージェント間の伝言板になる必要はなくなります。