これまでClaude Projectsは、会話やファイル、指示をプロジェクト単位でまとめる「入れ物」として使う場面が中心でした。
2026年9月17日の刷新では、この役割が大きく変わっています。
新しいProjectsでは、ユーザーが大きな目標を伝えると、Claudeが作業を分解し、複数のthreadを並列で動かし、結果をまとめます。
Anthropicは「複数セッションを自分で分割し、引き継ぎ、最後に結合する」手間を減らす設計として説明しています。
新Projectsの中心はcoordinatorです。ユーザーは中央の会話で目標を伝え、coordinatorが必要な作業を判断します。
個別作業はthreadへ振り分けられ、それぞれが独立して進みます。
たとえばWebアプリの速度改善なら、API、フロントエンド、データベースなどを別threadで調べ、並列に修正案やPRを作るといった使い方ができます。
従来の長時間タスクでは、調査、実装、テスト、レビューを1つの会話へ詰め込むと、会話が長くなり重要な前提が埋もれやすくなります。
新Projectsは、作業をthreadへ分けながらcoordinatorが全体を把握することで、1つのチャットへすべてを押し込む必要を減らします。
特に独立して進められる仕事では、複数threadが同時に動くため、人が順番に依頼するより待ち時間を減らせる可能性があります。
一方、前の結果が出ないと次へ進めない直列タスクでは、並列化の効果は限定的です。
各threadは単なるサブチャットではなく、完全なClaude Code cloud sessionとして動きます。
公式ブログでは、coordinatorが依頼の範囲を整理し、作業を委任し、並列threadの出力をレビューして最終成果へまとめると説明しています。
ユーザーはcoordinatorだけを見ることも、必要なthreadへ直接入り個別に指示することもできます。大きな仕事を「1つの長い会話」に押し込まず、作業単位へ分けながら全体文脈を維持するのが狙いです。
threadは、担当範囲が明確で成果物を個別に確認できる単位へ分けると扱いやすくなります。
開発なら「API」「フロントエンド」「テスト」「ドキュメント」、調査なら「競合」「市場データ」「一次情報確認」「最終要約」のように切り分ける方法があります。
反対に、同じファイルや同じ判断を複数threadへ同時に任せると、重複作業や競合が増えます。
coordinatorへ最初に「最終成果物」「優先順位」「変更してよい範囲」を渡し、独立性の高い作業だけ並列化するのが基本です。
新Projectsでは、各threadがshared memoryへ情報を追加し、別threadもそこから参照できます。
たとえば「リリース日が金曜へ変わった」「請求サービスを触る前に担当者へ確認する」といったプロジェクト固有の判断を蓄積できます。
libraryは、ユーザーが追加したファイルとClaudeが生成した成果物をまとめる場所です。
新しいthreadを始めるたびに必要資料を手動で貼り直す負担を減らします。
threadを完全に独立させるだけでは、片方で判明した重要事項を別のthreadが知らない問題が起きます。
shared memoryは、プロジェクト全体で維持したい前提や判断を共有するために使われます。
たとえば「公開日は金曜日」「請求処理には承認が必要」「このAPIは変更しない」といった情報をプロジェクト全体で持てれば、別threadが古い前提で作業を進めるリスクを減らせます。
libraryがファイルや成果物の置き場なのに対し、shared memoryは継続して参照したい判断や文脈の共有に近い役割です。
現在のthreadはクラウドで動きます。そのため、ユーザーがPCから離れても処理を続けられ、スマートフォンから進捗を確認・操作できます。
一方、現時点ではローカルPCのツールや社内ネットワークの内側へ直接つなぐ構成は今後の対応予定です。
クラウド実行の便利さと、アクセスできる環境の制限を分けて考える必要があります。
複数threadは、それぞれ完全なClaude Code cloud sessionとして動くため、thread数を増やすほど利用上限も消費しやすくなります。
簡単な確認まで別threadへ分けると、並列化のメリットより消費量が大きくなる可能性があります。
まず2〜3本の独立した作業から始め、どの程度時間短縮になるかを見るのが現実的です。
重要度が低い作業や短い確認はcoordinatorの会話内で済ませ、大きな成果物を伴う仕事だけworkerへ渡すと、利用枠を使いやすくなります。
開発では複数リポジトリの変更、性能調査、テスト、PR作成を並列化しやすくなります。
調査系では、競合調査、資料収集、検証、要約を別threadに分け、coordinatorが最終レポートへまとめる使い方が考えられます。
ただし、すべてを並列にすれば速くなるわけではありません。
前工程の結果が出ないと次へ進めない仕事は、threadを増やしても待ち時間が残ります。
Anthropic公式は、Claude Codeの新Projectsをベータとして提供しています。
2026年9月17日時点では、cloud sessionsを利用する一部のPro/Maxユーザーから段階的に提供されています。
全Pro/Maxへ即時提供されたと断定するのは正確ではありません。
Anthropicは今後、Claude全体やTeam、Enterpriseなどへ展開する方向を示していますが、提供時期や条件は変更される可能性があります。
利用可能なアカウントではProjectsを作成し、まず大きなゴールをcoordinatorへ伝えます。
作業を細かく指示しすぎるより、完成条件、優先順位、触ってはいけない範囲を明確にすると分解しやすくなります。
進行中は中央のcoordinatorで全体状況を確認し、必要な場合だけ個別threadへ入ります。終了後は成果物がlibraryに残り、次の依頼で再利用できます。
Anthropicは、複数threadがそれぞれ完全なClaude Code sessionとして動くため、Projectsは利用上限へ早く到達する可能性があると明記しています。
並列数を増やすほど無料で処理能力が増えるわけではありません。
また、GitHubや外部サービスへ権限を与える場合は、threadが並列に変更を進める前に承認範囲を決める必要があります。
重要な本番環境への変更は、人のレビューを残す設計が安全です。
開発用途では、各threadは単なる会話の分岐ではありません。
Anthropic公式によると、それぞれが独立したClaude Code cloud sessionとして、自分用のブランチとリポジトリのコピー上で作業します。
リポジトリを接続していればテストを実行し、Pull Requestを開くこともできます。
ただし、複数threadが同じコードを変更すれば競合は自動的に消えるわけではありません。
Anthropicは、重複した変更は通常のPull Requestと同じようにmerge conflictとして解決すると説明しています。
並列化しやすいのは、API、Web、モバイル、テストなど作業範囲を分けやすいタスクです。
Projectsではクラウド環境、connectors、plugins、instructions、modelをプロジェクト単位で設定できます。
さらに、coordinatorの会話とworker threadで使うモデルやeffort levelを選べます。
全threadで最上位モデルを使うのではなく、調整役と実作業で設定を変えることで、利用上限とのバランスを取りやすくなります。
thread自身も必要に応じてsubagents、loops、workflowsへ作業を細分化できます。
つまり新Projectsは「coordinator→thread」の二層だけではなく、threadの内部でも複数の処理を組み合わせられる構造です。
2026年9月17日の初期ベータは、Claude Codeのcloud sessionsを使う一部Pro/Maxユーザーが対象です。
Anthropicは、Webやデスクトップに既存Projectがないユーザーから開始し、Pro/Maxの既存Projectsは展開が広がるまで従来どおり動くと案内しています。
対象プランでも表示されない場合は、機能差ではなくロールアウト待ちの可能性があります。
今後はClaude全体、Team、Enterpriseへの展開も予定されていますが、現時点で一斉提供日が確定しているわけではありません。
導入可否を判断するときは、契約プランだけでなくアカウントに新Projectsが有効化されているかを確認する必要があります。
従来Projectsで使っていた資料や指示は、新しい仕組みでも「プロジェクト全体の前提」として価値があります。
ただし、新Projectsでは資料を置くだけでなく、どの作業をcoordinatorが管理し、どれをthreadへ委任するかという設計が加わります。
最初から複雑な自動化を作るより、「競合調査を3領域に分ける」「Webアプリの3箇所を別threadで調べる」など、結果を人が比較しやすい仕事から試すと違いを把握しやすいです。
ProjectsはAIを増やす機能というより、複数の作業単位を一つのゴールへまとめる管理レイヤーとして見ると理解しやすくなります。
新Projectsでは、最初の依頼を細かい作業手順の羅列にするより、「最終的に何を完成させたいか」「優先順位」「変更してはいけない範囲」「完了条件」をまとめて伝える方がcoordinatorが分解しやすくなります。
たとえば「このWebアプリを高速化して」だけではなく、「主要画面の表示速度を改善し、既存API仕様は変更せず、テストを通し、変更点をPR単位で整理する」と伝えれば、調査、フロントエンド、バックエンド、テストなどへthreadを分ける判断材料が増えます。
一つの判断を順番に積み上げる必要がある仕事は、threadを増やしても速くなりにくいです。
たとえば要件が確定してから設計し、その設計が終わってから実装するような工程では、前段の結果待ちが残ります。
また、複数threadが同じファイルや同じ仕様を同時に変更すると、統合作業が増える可能性があります。
並列化は「同時に動かせる独立作業」を見つけることが前提であり、単にAIの数を増やすこととは異なります。
Claude Projectsの刷新は、フォルダ整理機能の改善というより「複数AI作業を束ねるワークスペース」への変更です。
coordinatorが仕事を分解し、cloud sessionを並列に動かし、shared memoryとlibraryで知識と成果をつなぎます。
一方、現時点ではベータで対象ユーザーが限定され、並列実行は利用上限も消費します。
まずは独立性の高い2〜3作業を並列化し、どこまで自動で任せられるか確認する使い方が現実的です。
.png){kind=logo}
