すべてのスレッドが書き込む記憶を中心に再構築されるClaude Projects — 既存のプロジェクトの移行は後回しに（2026年）

1日違いで公開された2つの投稿は、どちらも「作業がどこに存在するべきか」に関するものでした。

プロジェクトに関する投稿は2026年9月17日付です。そこでは2層構造が説明されています。「プロジェクトには、作業を行うスレッドと、それらを指示するコーディネーターがあります。」各スレッドは軽量なタスクではありません。Anthropicは具体的に述べています。「内部的には、各スレッドは独自のブランチとリポジトリのコピーで動作するClaude Codeクラウドセッションです。」

各スレッドが独自のコピーを持つため、コードの衝突には文書化された解決パスが用意されています。「コーディネーターが作業を整理しますが、いずれかのスレッドが同じコードで作業する場合、重複は他のPRと同様にマージコンフリクトとして解決されます。」スレッドはさらに細分化することもできます。「大規模な割り当てをより早く完了するために、必要に応じてサブエージェント、ループ、ワークフローを使用して、委任された作業をさらに細かく分割できます。」その細分化によってコンテキストがどこに残されるかは、それ自体が疑問であり、私たちはサブエージェントが共有するものと共有しないもので取り上げました。

次にコンテキストのセクションです。Anthropicは、プロジェクトを「長期実行型またはエージェント型のワークフロー：1回の返信よりも長くかかり、複数の部分からなる作業」のために構築されたものと位置づけ、記憶を累積的なものとして説明しています。「時間の経過とともに、Claudeはプロジェクトの詳細についてより多くを学び、それを作業に適用します。」挙げられている例は、コードではなく意思決定です。「Claudeは、リリースが金曜日に移動したこと、エクスポートが廃止された理由、または課金サービスに触れる前に誰に確認すべきかを記憶できます。」これに加えて、「プロジェクトには、追加したファイルやClaudeが生成したアーティファクトを収集するライブラリが含まれるようになりました。」

ロールアウトに関する文言は、ほとんど誰も引用しなかった部分です。Anthropicの言葉を借りれば、アクセスは「Claude Codeでクラウドセッションを使用しており、ウェブやデスクトップに既存のプロジェクトがない、一部のClaude ProおよびMaxサブスクライバー」向けに開始されました。すでにプロジェクトを使用している場合、この条項はあなたに関係します。そして、続く一文には次に何が起こるかが書かれています。「ProおよびMaxプランの既存のプロジェクトは、現在と同様に機能し続けます。ロールアウトがチャットやCoworkに拡大するにつれて、それらをアップグレードします。」

2026年9月16日付の2つ目の投稿は、その1日前に発生した構造的に同一のイベントです。「本日より、Claude Coworkとチャットは1つのClaudeに統合されます。」Anthropic自身によるその理由の説明は、これまでにないほど明確に問題を指摘しています。「私たちは、より大きな作業のための別の場所としてCoworkを、ビジュアルな作業のためにDesignを構築しました。人々は両方を使用し、イライラする部分はタスクがどちらに属するかを決定することだと教えてくれました。一方で開始したことが、もう一方には引き継がれなかったのです。」

これは、ベンダーが自社のコンテナ間でコンテキストが渡されなかったことを、ローンチ投稿に自ら書き残したということです。解決策も同様に明白に述べられています。これらのインターフェースができることは、現在「すでに持っているコンテキスト、スキル、コネクターを使用して、どの会話からでも利用可能」であり、すでにCoworkを利用している人々にとっては、「チャット、プロジェクト、アーティファクト、コネクター、スキルなど、すべてが残した場所にあります。」

書き手が誰かが変わります。 これまで、プロジェクトにコンテキストが蓄積されるのは、主にユーザーがそこに物を入れたからでした。再設計されたプロジェクトでは、すべてのスレッドが作業しながら共有記憶に追加していきます。書き手側は1人から多数になり、その書き手は人ではなくセッションです。作業を割り振るコーディネーターはエージェントチームと同じ形をしており、そのコンテキストがどこに着地するかは、エージェントチームが共有するもので取り上げた疑問です。

読み取りが行われる場所が変わります。 Anthropicは2つのレベルでの検査について説明しています。「メインのプロジェクトチャットで進捗を監視してガイドすることも、個々のスレッドに飛び込んで詳細を調査し、方向性を指示することもできます。」したがって、見るべき場所は存在します。習慣化すべきことは、それを見ることです。共有記憶は、一度設定すれば済む設定パネルではなく、現在進行形の作業成果物（アーティファクト）なのです。

コストプロファイルが変わります。 「プロジェクトは一度に複数のスレッドを実行でき、それぞれが完全なClaude Codeセッションです。このため、プロジェクトはより早く利用制限に達する可能性があります。」Anthropicはこれに制御機能を組み合わせています。「プロジェクト固有の使用状況を確認し、コーディネーターチャットやワーカースレッドで使用されるモデルやエフォートレベルを選択できます。」

スレッドが実行される場所は、まだ変わりません。 「スレッドは現在クラウドで実行されています。ローカルのツールやコードと並行して、ネットワークの背後にあるマシン上で実行することは、非常に近いうちに提供される予定です。」

既存のプロジェクトは、今日すぐには変わりません。 現在と同様に機能し続け、後でアップグレードされます。そこにはギャップが存在します。あなたが今使っているプロジェクトは、まだ見ぬ変換プロセスの手前側にあります。

プロジェクトが永続的な記録になるわけではありません。 プロジェクトは、一連の作業がアクティブである間にそれが存在する場所です。意思決定の背後にある推論は、意思決定そのものよりも価値があり、コンテナよりも長生きします。これは、私たちがなぜ長いコンテキストウィンドウが記憶ではないのかで描いた区別です。

「共有記憶があるから、もうメモを書く必要はない」 投稿には、共有記憶によって「複雑なプロンプトエンジニアリングの必要性が減る」と書かれていますが、これはプロンプトに関する主張であり、あなたの記録に関する主張ではありません。Anthropicが例として挙げているもの（移動されたリリース、廃止されたエクスポート、確認すべき担当者）は、まさに次の四半期に自分の言葉で読み返せるように、どこかに書き留めておきたい事柄です。

「並行スレッドは単にセッションが速くなっただけだ」 各スレッドは、独自のブランチとリポジトリ of コピーを持つ完全なクラウドセッションです。これはタブとは異なる作業単位であり、Anthropic自身が利用制限について言及していることがその証拠です。

「コードと記憶はどちらもマージされる」 Anthropicは1つの解決メカニズムを明示的に説明しており、それはコードに関するものです。重複は「他のPRと同様にマージコンフリクトとして解決されます。」共有記憶については、同じページで異なる関係が説明されています。すべてのスレッドがそこに「追加し、そこから引き出す」というものです。これらは2つの異なる設計であり、一方が両方をカバーしていると仮定するのではなく、2つの異なる設計として理解することが重要です。別のベンダーも同様の分割に達しており、これについてはCursor Projectsで次のエージェントに届くもので検証しました。

「私のプロジェクトは自動的に新しいものに移行する」 ロールアウトがチャットやCoworkに拡大するにつれて、Anthropicのスケジュールに沿ってアップグレードされます。それまでの間は、現在と同様に機能し続けます。Anthropicはまた、Coworkの投稿で組織向けのスケジュールも示しています。「エンタープライズ管理者は、組織に変更が適用される少なくとも30日前に通知を受け取ります。」

「これはセッションをブランチするのと同じだ」 違います。ブランチは、別のパスを進むために1つのセッションをコピーするものです。プロジェクトは、1つの目標に対して多くのセッションを実行します。ブランチのケースについては、リモートのClaude Codeセッションのフォークで別途詳しく説明しました。

目標は、共有記憶を避けることではありません。再設計の途中にあるコンテナの中に、自分のコンテキストのどちら半分を置いておいてよいかを知ることです。

ステップ 1：スレッドが始まる前に決定事項を書き留める

目標を設定してプロジェクトに作業を分散させる前に、スレッドが推測するにはコストがかかりすぎる3〜4つの事柄を書き留めておきます。すでに除外した制約、チームが合意した規約、特定の人物に確認せずに誰も触れてはならないサービスなどです。Anthropic自身が挙げているプロジェクト記憶の例は、まさにこの種の事実であり、それらが重要であることを示しています。それらを保存している製品を開かなくても読み返せる場所に書き留めておきましょう。

ステップ 2：サマリーだけでなく、スレッドを読む

Anthropicが説明する両方のレベルを活用してください。プロジェクトチャットは作業がどこにあるかを示し、個々のスレッドは何をどのような根拠で結論付けたかを示します。スレッドの結論がチームが従うべき決定事項になったら、自分の言葉で1文にまとめてコピーしておきます。スレッドの中にしか存在しない結論は、後で再び導き出さなければならなくなる結論です。

ステップ 3：アップグレード後も残るコピーを保持する

既存のプロジェクトは現在も機能し続けており、後でアップグレードされます。その変換後に再説明するのが面倒なものはすべて、すでにプロジェクトの外に存在している必要があります。これは、ツールの切り替えを乗り切るための規律と同じであり、Claude Codeセッション間でのコンテキストの持ち越しで説明されているものと同じです。

その分割された永続的な半分は、プロジェクトやスレッド、あるいはベンダーのコンテナではないどこかに存在する必要があります。MemoryLakeは、特定の製品の構造から独立し、接続するすべてのAIアシスタントから読み取り可能な、意図的に意思決定を書き込むためのストアです。エントリーはあなた自身の言葉で書き込みます。Anthropicのシステムや他のベンダーのストアから読み取られたり、そこに書き込まれたり、削除されたりすることはありません。プロジェクト、スレッド、ライブラリは完全にそれぞれの管理下に置かれたままです。

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

ダッシュボードからキーを生成します。これにより、コーディネーターチャット、ターミナルセッション、そして全く異なるアシスタントが、それぞれ独自のコピーを保持することなく、同じ事実のセットにアクセスできるようになります。

ステップ 2：最初の記憶をアップロードする

Anthropic自身の例が示している4つのカテゴリから始めましょう。移動した日付、不採用にした事項、特定のサービスの所有権、および遵守を期待する規約です。それぞれの横に理由を追加します。理由があることで、将来のスレッドがすでに却下した提案を再び行ってくるのを防ぐことができます。

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

ツールをこのレイヤーに向けることで、文字起こしから再構築するのではなく、作業開始時にそれらの事実がロードされるようにします。そして、唯一の確実なテストを実行します。別のアシスタントに、決定事項の1つを答えるよう求めてみてください。もし答えられたなら、あなたの推論はもはや1つの製品の形状に縛られていません。

第1の変化は、「これがどのインターフェースに属するか」という疑問に2度答える必要がなくなることです。Anthropicは自社製品からその疑問を取り除き、その答えを出すためにこれまではコンテキストが犠牲になっていたと明言しました。同じ論理が1つ上のレベルにも適用されます。ある事実が複数のツールにまたがって重要である場合、それはたまたま開いたツールの中に置かれるべきではありません。

第2に、プロジェクトの記憶は、信頼するものではなくレビューするものになります。多くのスレッドがそこに書き込みます。スレッドの結論を読むことは、問題が発生したときに行う監査ではなく、今や作業の一部です。

第3に、決定事項と記録の違いが運用可能になります。プロジェクトは、進行中の取り組みをまとめるのに非常に優れています。なぜそれを選んだのかという記録は、異なる寿命を持つ異なるアーティファクトであり、今回の再設計は、両方を同じ場所に保存していたことに気づく良い機会です。

第4に、アップグレードが不安なものではなくなります。既存のプロジェクトは現在も機能し続け、後で変更されます。重要なものすべてに外部コピーがあれば、その変換作業は丸一日かかる仕事ではなく、単なる通知の確認で済みます。

最初は目標を狭く設定する。 Anthropicの「チーフ・オブ・スタッフに説明するようにプロジェクトでClaudeに指示を出せば、新規または既存のスレッドに作業をルーティングする」というフレームワークは、指示が十分に具体的でルーティングが明白な場合に最も効果的です。

プロジェクト固有の使用状況を早めに確認する。 一度に複数の完全なクラウドセッションを実行することは、これまでとは異なる消費パターンです。Anthropicはコーディネーターとワーカースレッドの制御を個別に文書化しています。

ライブラリはアーカイブではなくインボックスとして扱う。 ライブラリは、追加したファイルやClaudeが生成したアーティファクトを収集します。作業中に物を見つけるのには便利ですが、結論づけた内容の整理された記録とは異なります。

ルールだけでなく理由も書く。 「確認なしで課金システムに触るな」というルールは、時間が経つと形骸化します。「確認なしで課金システムに触るな。照合ジョブが特定の時間に実行され、6月にスキーマ変更で破損したため」という理由は、引き継ぎを乗り越えます。

コンテナの外にコピーを1つ保持する。 Anthropicは2日間で2つのコンテナを移行しました。これは製品が向上している証拠ですが、同時に、永続的な事実をコンテナではない場所に保管しておくべき理由でもあります。

Claude Projectsの再設計は、プロジェクトの定義における本質的な変化です。チャットが付属した単なるフォルダではなく、コーディネーター、並行クラウドセッション、ライブラリ、そしてすべてのスレッドが寄与する記憶を備えた会話です。Anthropicは、コードの重複がマージコンフリクトとして解決されること、スレッドが実際のコストを伴う完全なセッションであること、スレッドは当面クラウドで実行されることなど、見落としがちな部分を含めてその全容を文書化しました。

心に留めておくべき2つの文は、すでに持っているものに関するものです。既存のプロジェクトは「現在と同様に機能し続け」、Anthropicは「ロールアウトがチャットやCoworkに拡大するにつれて、それらをアップグレード」します。これについて問題は何一つありません。それは単に、コンテキストが置かれている場所の形状に対する、予定された変更にすぎません。

その前日、Anthropicはなぜコンテナが重要なのかを説明しました。人々はタスクがどこに属するかを決定し続けなければならず、「一方で開始したことが、もう一方には引き継がれなかった」からです。これは、今月公開された問題提起の中で最も明確なものです。実用的な対応は、より良いコンテナを選ぶことではありません。コンテナよりも長生きする事実を、自分が管理するどこかに保管し、コンテナの改善を見守ることです。