なぜ Claude Code のエージェントチームはコンテキストを共有しないのか、そしてその解決策 (2026)

まず前提として：これは実験的機能であり、デフォルトではオフです

何よりもまず、エージェントチームは明示的に有効にしない限り無効化されています。ドキュメントには「実験的であり、デフォルトで無効」という警告があり、設定または環境変数で CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を設定することで有効になります。「この変数が設定されていない場合、セッション開始時にチームはセットアップされず、チームディレクトリも作成されず、Claude はチームメイトをスポーンしたり提案したりしません」。

したがって、これは期待外れのバグではありません。ドキュメント化された制限を持つ初期段階の機能であり、コンテキストの境界線は設計上の決定によるものであって、見落としではありません。

共有されるのは「協調」であり、「会話」ではない

アーキテクチャのセクションによると、チームは「チームリード」「チームメイト」「共有タスクリスト」「メールボックス」で構成されています。メールボックスは ~/.claude/teams/{team-name}/inboxes/{agent-name}.json にあるJSONファイルです。タスクリストは ~/.claude/tasks/{team-name}/ 以下に保存されます。

これら2つの要素（タスクとメッセージ）が、共有される基盤のすべてです。チームメイトはタスクのステータスを確認し、対応可能な作業を割り当て、名前を指定して互いにメッセージを送信できます。しかし、お互いの思考プロセスや、あなたの思考プロセスを見ることはできません。

ドキュメントでも直接比較されているサブエージェント（subagents）と比較してみましょう。サブエージェントは独自のコンテキストウィンドウを持ち、呼び出し元に結果を報告します。一方、チームメイトは独自のコンテキストウィンドウを持ち、「完全に独立」しており、上長に報告するのではなく、お互いにメッセージを送り合います。どちらのモデルもコンテキストを隔離しています。チームは単に通信チャネルを追加しただけです。

スポーンプロンプトがブリーフィングのすべて

これが実務上の影響であり、ルールとして覚えておく価値があります。チームメイトに知っておいてほしいことは、スポーンプロンプトに含めるか、ロードするファイルに書き込むか、後からメッセージで送信するかのいずれかでなければなりません。

ドキュメントのベストプラクティスにもそう書かれています。チームメイトはプロジェクトコンテキストを自動的にロードしますが、「リードの会話履歴は継承しない」ため、「スポーンプロンプトにタスク固有の詳細を含める」必要があります。ドキュメントの例にあるスポーンプロンプトは数文の長さで、モジュール、重点領域、トークン保存のアプローチ、出力フォーマットを指定しています。

実際にそのブリーフィングを書くのが誰であるかに注目してください。それは、あなたとの会話を自分なりに要約したリードエージェントです。すべてのチームメイトの初期知識は、あなたが交わした議論について、別のモデル（リード）が関連性があると判断した内容でフィルタリングし、要約したものです。

チームメイトが受け取るのは「プロジェクト」のコンテキストであり、「あなた」のコンテキストではない

この違いは重要です。チームメイトは作業ディレクトリから CLAUDE.md を読み込み（ドキュメントでも「CLAUDE.mdは正常に動作する」と確認されています）、さらにプロジェクトやユーザー設定から MCP サーバーとスキルを読み込みます。

つまり、コミットされたファイル形式の知識は伝播します。それ以外のものは伝播しません。チャットで言及した制約、1時間前にリードに与えた修正、ターミナルを開く前のミーティングで下した決定。これらはファイルに存在しないため、チームには一切届きません。

サブエージェントの定義をチームメイトのタイプとして使用する場合、関連する注意点があります。ドキュメントによると、定義の skills や mcpServers のフロントマターフィールドは「その定義がチームメイトとして実行されるときには適用されません」。チームメイトは通常のセッションと同様に、プロジェクトやユーザー設定からスキルと MCP サーバーをロードするためです。

チームメイトが学んだことは、チームの終了とともに消え去る

チームはセッションスコープです。チーム名はセッションから派生し（session- にセッションIDの最初の8文字を加えたもの）、「セッション終了時にチーム設定ディレクトリは削除されます」。タスクリストのディレクトリはローカルに保持され、アップロードされることはありません。保持期間は、トランスクリプトに使用するのと同じ cleanupPeriodDays によって管理されます。

つまり、タスクは残りますが、チームは残りません。何も蓄積されません。今朝、あなたのエラーハンドリングの規約を学んだレビュアーのチームメイトは、午後には消えており、明日のレビュアーは同じスポーンプロンプトからやり直すことになります。また、実行中のチームメイトに対するセッションの再開機能もありません。/resume や /rewind を実行してもチームメイトは復元されず、リードは「すでに存在しないチームメイトにメッセージを送信しようとする」可能性があります。

メッセージはテキストであり、意図的に「低信頼」として扱われる

メールボックスが知識を伝達できると思うかもしれません。確かに文章を運ぶことはできますが、システムはその文章を疑うように設計されています。

あるエージェントが別のエージェントにメッセージを送信すると、「Claude Code は受信側エージェントに対し、そのメッセージがあなたからではなく、別の Claude セッションから送信されたものであることを伝えます」。チームメイトは「あなたの代わりに権限プロンプトを承認したり、同意を提供したりすることはできません」。また、アクションを拒否されたチームメイトが「チェックを回避するために別のチームメイトにそれを転送する」こともできません。自動モードでは、分類器が転送された承認の主張を信頼できない入力として扱い、配信前に各メッセージをレビューし、一部を完全にブロックします。

これは正しいセキュリティ設計ですが、同時にメールボックスが知識の伝達経路ではなく、単なる協調チャネルであることを意味します。また、実務上の仕様として、全員に連絡するには受信者ごとに1通ずつメッセージを送信する必要があることも知っておく価値があります。

そして、再構築には実際のコスト（トークン）がかかる

ドキュメントには、エージェントチームは「単一のセッションよりも大幅に多くのトークンを消費する」と明記されており、アクティブなチームメイトの数に比例して増加します。ほとんどのワークフローでは 3〜5 人が推奨されています。これらのトークンが消費される理由の一部は、各チームメイトが同じ理解を再構築するために、それぞれ独立して同じファイルを読み込むためです。これは、共有ストアがあれば一度で解決できる問題に対して、非常にコストのかかるアプローチをとっていることになります。

巨大なスポーンプロンプトを書く。 ドキュメントに記載されている解決策であり、ある程度は機能します。しかし、セッションごとにチームメイトごとのブリーフィングを手動で作成することになり、そのブリーフィングは会話を圧縮したものになります。その結果、チームメイトが判断を下すためにまさに必要としているタイミングで、制約の背景にある理由が抜け落ちてしまいます。

すべてを `CLAUDE.md` に書き込む。 チームメイトが実際にそれを読み込むため、直感としては正しいです。制限はサイズです。指示ファイルは短く保つことが推奨されています。長いファイルはコンテキストを消費し、一貫して従われにくくなるためです。4人のチームメイトが必要とするすべてを詰め込んだ CLAUDE.md は、結局誰にも従われなくなります。

リードに発見事項を中継させる。 機能はしますが、リードがボトルネックになり、あるチームメイトが学んだことを別のチームメイトが読めるように書き直すためにトークンを消費することになります。また、スポーンプロンプトと同様に情報が欠落しやすくなります。

各チームメイトのトランスクリプトを自分で読む。 可能です。パネルでチームメイトを選択して Enter キーを押すと、直接表示してメッセージを送信できます。軌道修正には便利ですが、仕組みとしては役に立ちません。あなたが統合レイヤーになってしまうからです。

代わりにサブエージェントを使用する。 場合によっては適切です。サブエージェントはコストが低く、結果を報告するため、作業者同士が会話する必要がない場合はドキュメントでも推奨されています。ただし、知識の共有は解決しません。サブエージェントも同様に隔離されています（メールボックスすらありません）。

リポジトリにスクラッチファイルを置いておく。 最も効果的な回避策であり、正しい解決策を自前で実装した形です。どのアージェントのコンテキストの外にもあり、全員が読み書きできる場所です。人々が独自にこの方法にたどり着くことが多いのは注目に値します。

隔離は維持してください。独立したコンテキストウィンドウがあるからこそ、5人のエージェントチームが互いの出力に埋もれることなく並行して作業でき、低信頼のメッセージングルールがあなたを保護しているのです。

修正すべきなのは、「隔離されたコンテキスト」が現在「隔離された知識」を意味してしまっている点です。これらは切り離すことができます。すべてのコンテキストウィンドウの外側に、チーム用のストアを提供しましょう。リードが制約や決定事項をそこに書き込み、チームメイトは作業開始時にそれを読み込み、発見したことを書き戻します。そうすれば、翌日の次のチームは、新しいスポーンプロンプトからではなく、前のチームが学んだことから作業を開始できます。

MemoryLake はそのためのメモリレイヤーです。決定事項、制約、ソースドキュメントを1つのストアにまとめ、すべてのチームメイトから MCP 経由で、また Codex や API 経由の ChatGPT からアクセスできます。タスクリストが作業を調整し、ストアが知識を運びます。

ステップ 1: API キーを作成する

キーを生成し、約30秒で最初のリクエストを送信できます。セッションに直接貼り付けるのではなく、環境変数やシークレットマネージャーに保存してください。

ステップ 2: 最初のメモリをアップロードする

チームメイトが何度も再発見しがちなドキュメント、画像、ファイルを投入します。理由付きのアーキテクチャ決定、インシデントの報告書、API コントラクト、規約、すでに却下したアプローチのリストなどです。要約ではなく、ソース自体をアップロードしてください。スポーンプロンプトはすでに要約であり、そこが理由を失ってしまうレイヤーだからです。

ステップ 3: AI とエージェントを接続する

Claude、Codex、OpenClaw、その他の AI エージェントに、MCP または API 経由でメモリへのアクセス権を付与します。チームメイトは通常のセッションと同様に、プロジェクトやユーザー設定から MCP サーバーをロードするため、サーバーを一度設定するだけで、すべてのチームメイトに同じストアを提供できます。チームメイトごとのセットアップは不要で、リードが中継を覚えているかどうかに依存することもありません。

最初の違いは、スポーンプロンプトが短く、より洗練されることです。会話全体をブリーフィングに圧縮する代わりに、このチームメイトが何を担当するかを記述し、残りはストアを指し示すだけで済みます。情報の欠落が減り、入力の手間も省け、すべてのチームメイトで共通化できます。

2つ目は、発見したことがチームの枠を超えて残ることです。デバッグ担当のチームメイトが「再試行エンドポイントが冪等ではない」と学んだ場合、それがストアに保存され、明日のチームに引き継がれます。現状では、その発見はセッションとともに破棄されるコンテキストウィンドウの中に留まってしまいます。

3つ目は、並行作業において、同じコンテキストを5回も再導出する必要がなくなることです。各チームメイトが取得された制約を読み込む方が、コードベースを読み込んで推測するよりも劇的に安価です。これは、チームが大幅に多くのトークンを消費するというドキュメントの警告を考慮すると重要であり、セッションごとにコードベースを再読するエージェントにとっても極めて重要です。

そして、これは Claude Code がすでに提供している機能と調和します。CLAUDE.md は恒久的なルールを保持し続け、オートメモリはローカルのメモを保持し、タスクリストは調整を続けます。これらがいずれも「信頼できる唯一の情報源（system of record）」になる必要はありません。そもそも、オートメモリはそれを書き込んだマシンから離れることはできないため、情報源にはなり得ないのです。

誰かをスポーンする前に制約を書き出す

あなたとリードが40分かけて結論に達したなら、その結論はチームメイトが読める場所に存在する必要があります。スポーンする前の10分間の執筆が、3人のチームメイトが却下された設計をそれぞれ独立して再発明するのを防ぎます。

スポーンプロンプトは「教育」ではなく「役割」に焦点を当てる

このチームメイトが何を担当するのか、「完了」の定義は何か、そしてコンテキストをどこで探すべきかを記述します。プロンプトでプロジェクト全体を教えようとすると、ブリーフィングが600語になっても、本当に重要なことを見落とす結果になります。

チームメイトに予測可能な名前を付ける

リードはスポーン時に各チームメイトに名前を付け、どのチームメイトもその名前で他のチームメイトにメッセージを送信できます。後で参照できるように、スポーン指示の中でリードに彼らを何と呼ぶべきかを伝えてください。また、全員に連絡するには受信者ごとに1通のメッセージが必要であることを忘れないでください。

知識の移動をメッセージに依存しない

メールボックスはテキストであり、受信メッセージはあなたからではなく別の Claude セッションから送信されたものとして扱われ、権限の主張は明示的に信頼されません。メッセージは「認証モジュールが完了しました」といった協調のために使用し、事実の伝達にはストアを使用してください。

セッション再開時にチームが存続しないことを想定する

/resume や /rewind は実行中のチームメイトを復元しません。リードはすでに存在しないチームメイトにメッセージを送信しようとする可能性があります。その場合は、新しいチームメイトをスポーンするように指示し、新しいチームメイトが古いチームメイトの学んだことを読み取れるようにしてください。

まずは 3〜5 人のチームメイトで、読み取り専用の作業から始める

ドキュメントで推奨されている内容であり、失敗パターンとも一致します。協調のオーバーヘッドとトークンコストはチームの規模に比例して増加し、並行して実装を行うとファイルの競合が発生しやすくなります。レビュー、調査、競合する仮説のデバッグこそが、チームがそのコストに見合う価値を発揮する領域です。

これらを「強制力」と混同しない

指示ファイルやメモリはコンテキストであり、強制された設定ではありません。フォーマット、保護されたパス、main への直接プッシュの禁止など、すべてのチームメイトの出力で必ず守るべきルールがある場合は、フックや CI に設定してください。そうすれば、個々のエージェントが何を読み込んだかに依存せず、すべてに適用されます。

Claude Code のエージェントチームがコンテキストを共有しないのは、チームメイトが設計上独立しているためです。それぞれが独自のコンテキストウィンドウを持ち、プロジェクトコンテキスト（CLAUDE.md、MCPサーバー、スキル）をロードし、「リードの会話履歴は引き継がれません」。彼らが共有するのはタスクリストとメールボックスであり、メールボックスはエージェント間のメッセージを、同意プロセスなどにおいて意図的に「信頼できないもの」として扱います。チーム自体はセッションスコープであり、セッション終了時に設定ディレクトリは削除され、実行中のチームメイトはセッション再開時に存続せず、あるチームから次のチームへと何も蓄積されません。

したがって、隔離は維持したまま、共有方法を改善しましょう。すべてのチームメイトが読み書きできるストアに制約や決定事項を書き込み、スポーンプロンプトは教育ではなく役割に焦点を当て、タスクリストに協調を任せます。そうすれば、5人のエージェントは、あなたの会話を5通りに圧縮したものではなく、プロジェクトに対する単一の共通理解に基づいて作業できるようになります。