MEMORY.mdに書き込まれる内容は、Claudeが自動的に何を記憶するか決めているのか、それとも自分から特定の事項を覚えておくよう依頼できるのか?
Anthropic自身の例(「リリースは金曜日に延期になった」「請求関連のコードに触れる前に誰に確認すべきか」)から見ると、こうした情報は会話の中で自然に浮かび上がり、Claudeが決定レベル・ルールレベルの内容だと判断して自らインデックスに書き込んでいるように聞こえる——これはこの仕組みが自動化寄りであり、毎回「これを覚えておいて」と明確に指示しなければ機能しないものではないことを示唆している。
とはいえ、逆に言えば、何かが自分にとって本当に重要である場合、より慎重なやり方は、やはり対話の中でそれを明確に伝えることであり、Claudeが自動的にその重要性を判断してMEMORY.mdに書き込んでくれると仮定しないことだ。これは結局のところClaudeが能動的に維持しているインデックスであり、現時点ではその完全な判断ロジックを文書で直接確認する手段がない。ある重要な決定が記憶されていなかったと後になって気づくよりは、その場で明確に伝えておく方が、記憶漏れのリスクを下げられる。
なぜ「メモリ」と「コードのコンテキスト」は2つの別々の継承経路を辿るのか、いっそ同じインデックスにまとめてしまえばいいのではないか?
この2つはそもそも性質が異なる。コードのコンテキスト(リポジトリ自体、CLAUDE.md、スキル、プラグイン)は、各スレッドが作業を実行する際に実際に操作、編集、テストする必要がある素材そのものだ。この種のコンテンツは容量が大きくなる可能性があり、通常各スレッドは並行実行時に互いに干渉しないよう、完全で独立したコピーを必要とする。もしこうした内容もMEMORY.mdのようなインデックスファイルに詰め込んでしまえば、インデックス自体が肥大化して非効率になり、「各スレッドが独自の作業コピーを持つ」という並行実行の基本前提が失われてしまう。
メモリ(MEMORY.mdインデックス内の内容)はその逆で、その価値はまさに「軽量で、スレッド間で共有され、継続的に蓄積される」という点にある。この種の決定レベルの情報は通常短く、後続のすべてのスレッドに見える必要があるが、コードのように各スレッドが独自の複製を持つ必要はなく、そうすべきでもない(複数のコピーはむしろ情報の非同期化というリスクを生む)。この2つが異なる仕組みに分かれているのは、「共有すべきか」「独立したコピーを持つべきか」という2つの問いに対する答えがちょうど正反対だからだ。
もし自分のプロジェクトが複数のリポジトリにまたがっている場合、権限ルールが起動ディレクトリ内でしか有効にならないという事実は、実際にどんな具体的な影響をもたらすのか?
実際の影響はこうだ。1つのリポジトリ内で設定した権限ルール(特定のdenyルール、あるhookなど)は、同じプロジェクト内の他のリポジトリに自動的には及ばない。もしスレッドが別のリポジトリのディレクトリから起動された場合、そのリポジトリでも対応するルールを個別に設定しない限り、最初のリポジトリで設定したルールには縛られない。つまり複数リポジトリのプロジェクトでは、権限ルールがどれだけ厳格に機能するかは、「すべての」リポジトリで個別に設定を行っているかどうかにかかっており、一度設定すればプロジェクト全体を保護できるというものではない。
実務上より安全なやり方は、まず自分のプロジェクトがいくつのリポジトリをカバーしているかを棚卸しし、それぞれについて個別に権限ルール、hooks、envが期待通りに設定されているかを確認することであり、1つのリポジトリでルールを設定したからといって、プロジェクト全体に同じ防御が適用されていると仮定しないことだ。この仮定は単一リポジトリのプロジェクトでは成り立つが、プロジェクトが複数のリポジトリにまたがった瞬間に成り立たなくなる。
コーディネーターがスレッドの実行過程の一つひとつを見られず、報告された結果しか見えないことは、実際に作業の進捗を監督する上で問題にならないのか?
これは、プロジェクトの対話だけを見ている場合、把握できるのは「このスレッドが今どの段階にいるか、最終的に何を報告したか」といった高いレベルの進捗であって、「先ほど3つの方法を試し、最初の2つは失敗した」といった実行レベルの詳細ではないことを意味する。結果さえわかればいいというほとんどの状況では、このレベルの情報で十分であり、すべてのステップを見張る必要はない。
しかし、あるスレッドの結果が期待通りでなかったり、なぜそのスレッドが特定の選択をしたのかを理解する必要がある場合、コーディネーター層の情報だけでは不十分だ——その場合、そのスレッドを能動的に開いて初めて、完全な実行過程と途中の試行錯誤を見ることができる。したがって、より実践的な監督習慣は、コーディネーターの対話を「進捗を確認するためのダッシュボード」として扱い、ダッシュボードに表示された結果に疑問がある場合、あるいは結果自体をより詳しく精査する必要がある場合にのみ、個別のスレッドを開いて詳細を確認することだ——並行実行されるすべてのスレッドを最初から最後まで見張る必要はなく、現実的にもそれは不可能だ。
Claude Code Projectsは2026年9月17日、再設計された形でリリースされた。核心となる考え方は、プロジェクトを一つの継続的な対話へと変え、Claudeがコーディネーターとして機能し、実際の作業を並行して実行される複数のスレッドに振り分けるというものだ。多くの報道が今回のアップデートには「共有メモリがある」と伝えているが、その共有メモリが具体的にどう機能するのか——データはどこに保存されるのか、何が書き込まれるのか、新しく開かれたスレッドはそれをどう読み取るのか——この記事ではその仕組み自体に焦点を当てる。
ClaudeはMEMORY.mdという名のインデックスファイルを通じてプロジェクトメモリを読み書きする。これは「AIがあなたを覚えている」といった抽象的な概念ではなく、実際に存在し、Claudeが能動的に書き込み、読み取るテキストファイルだ。Anthropic自身の例は具体的だ。「リリースは金曜日に延期になった」、あるいは「請求関連のコードに触れる前に誰に確認すべきか」——こうした決定事項やルールに関する情報がこのインデックスに書き込まれ、個々のスレッドの会話履歴に散らばって、そのスレッドの終了とともに消えてしまうことはない。
すべての新しいスレッドは、開始した瞬間にいくつかの固定されたコンテキストのカテゴリーを自動的に引き継ぎ、毎回改めて説明する必要はない。プロジェクト配下のすべてのリポジトリとアップロードされたファイル、最大16,000文字のプロジェクト指示(コーディネーターとすべての新しいスレッドが同じものを受け取る)、そしてMEMORY.mdインデックスを通じて読み書きされるプロジェクトメモリだ。それに加えて、各スレッドはプロジェクトリポジトリの完全なコピーをそれぞれ複製し、そこからCLAUDE.md、スキル、プラグインを読み込む——つまりメモリ(決定レベルの情報)とコードのコンテキスト(リポジトリ自体)は2つの別々の継承経路であり、それぞれ異なる仕組みが担当している。
公式ドキュメントは、誤解されやすい点を特に指摘している。権限ルール、hooks、env環境変数の挙動は、スレッドが起動したディレクトリから有効になる——つまり、あなたのプロジェクトが単一のリポジトリのみを含む場合、これらのルールは想定通りに機能する。しかし、あなたのプロジェクトが複数のリポジトリにまたがる場合、これらのルールはすべてのリポジトリに自動的に適用されるわけではなく、スレッドが実際に起動した特定のディレクトリ配下でのみ有効になる。これはMEMORY.mdインデックスの動作ロジックとは異なる——メモリはプロジェクト全体のレベルで共有されるのに対し、権限ルールはディレクトリの範囲に基づいて適用される。この2つは同じメンタルモデルで理解すべきではない。
コーディネーター(プロジェクトの対話そのもの)とスレッドの間で、情報は対称的に流れているわけではない——コーディネーターはあなたが送った内容を読み取り、簡単な質問にはその場で答え、新しいスレッドを開くかどうかを決める。しかしコーディネーターが見ているのはスレッドが「報告してきた結果」であって、スレッドが実行途中で踏んだすべてのステップではない。つまりプロジェクトの対話だけを見ていると、スレッドが裏でどんな試行錯誤をしたのか、どんな回り道をしたのかは見えず、最終的に報告された結論だけが見える。実行の詳細を見るには、そのスレッドを個別に開く必要がある。
MCPツールへのアクセスは、あなた自身のclaude.aiアカウントのコネクタを通じて提供され、プロジェクトの対話自体にはコネクタがない——つまりMCPツールを必要とする作業は、必ずスレッドに委ねなければならず、コーディネーターの層自体はMCPツールを直接呼び出すことができない。これはまた、「コーディネーターは委任するだけで、実際に作業を行うのはスレッドだ」という役割分担が、単なるタスク管理上の設計選択ではなく、ツールアクセス自体のアーキテクチャによって直接制約されていることも説明している。