Claude Code、
PCを閉じても働き続ける。
Anthropicが「Claude Code Projects」を再設計し、ベータで再公開しました。ひとつの会話から複数のクラウド上エージェントスレッドを並列に走らせ、ノートPCを閉じてもタスクは止まりません。何が変わり、誰にとって意味があるのかを一次情報から読み解きます。
「閉じたら止まる」を
前提から外す
Anthropicは2026年9月17日、Claude Code内の「Projects」機能を再設計してベータ公開したと発表しました（MarkTechPost、The Verge）。
先月まで、Claude Codeは基本的に個人のローカル端末上で1セッションずつ動かすツールでした。ターミナルやPCを閉じれば処理はそこで止まり、長時間かかるタスクは端末をつけっぱなしにする必要があったのです。
新しいProjectsは、ひとつの継続的な会話が「コーディネーター」として目標を受け取り、それを複数のワーカースレッドに分解してクラウド上で並列実行する「コーディネーター＋ワーカースレッド」の2層アーキテクチャを採用します(The Decoder)。各ワーカースレッドは独自のブランチとリポジトリのコピーを持つ、それ自体がフル機能のClaude Codeクラウドセッションです。重要なのは「速くなった」ことより、エージェントの実行単位が人間のセッションから切り離されたという設計思想の転換にあります。
The Decoderは今回の再設計を、単発の機能追加ではなく「Claude Codeを自律的なコーディングへ段階的に押し進める」一連の取り組みの一部として位置づけています。並列エージェントのワークフローが増えるほど、「人が張り付いて操作するAIツール」から「目標だけ渡して結果を受け取る運用」へと、コーディング支援の重心が動いていくことになります。
| これまでのClaude Code | Claude Code Projects（新） |
|---|---|
| ローカル端末で1セッションずつ実行 | クラウド上で複数スレッドを並列実行 |
| PCやターミナルを閉じると停止 | 閉じても処理が継続 |
| 進捗確認はローカルの画面のみ | チャットやスマホからも進捗を確認・指示 |
| 作業ブランチは1本 | スレッドごとに専用ブランチ＋リポジトリのコピー |
目的を伝えれば、Claudeが並列のスレッドを差配する。
それは、あなたがノートPCを閉じたあとも働き続ける。
コーディネーターが、仕事を配る
単一の会話が「進行管理役」となり、複数のクラウドセッションへタスクを割り振ります。
1つの会話に目標を書く
「APIのレート制限対応、Web移行、モバイル側の検証を進めて」のように、ひとつの継続的な会話に大まかな目標を伝えます。
コーディネーターが分解・割り当て
Claudeが要求の範囲を見極め、新規または既存のワーカースレッドへタスクを割り振ります。各スレッドは独自ブランチと独自のリポジトリコピーを持ちます。
並列で実装・テスト・PR作成
各スレッドはコード変更、テスト実行、プルリクエスト作成までをクラウド上で完結させます。進捗はチャットやスマートフォンからも追跡・指示できます。
誰に、どう効くか
職種によって、恩恵の受け方も注意点も変わります。
エンジニア
APIの修正・Web移行・モバイル対応のような、独立性の高い複数タスクを同時に前進させられます。自分は設計や難所のレビューに集中できます。
経営・事業
開発チーム全体のスループットを底上げできる一方、スレッドごとにフルセッション分の利用枠を消費するため、費用対効果はチームでの利用実績を見て判断すべき段階です。
PM・進行管理
複数タスクの並列進行を1つのチャットとスマートフォンから見渡せます。誰が何を待っているかを都度ローカル画面に張り付かず確認できるようになります。スタンドアップ前の状況確認のような、細切れの進捗把握に向いています。
次に何をすべきか
ベータは2026年9月17日、クラウドセッションを使うClaude Pro/Maxの一部ユーザーから提供が始まり、今後数週間で対象を広げたのち、Team・Enterprise向けにも展開される見込みです。ローカル環境での実行対応も準備中とされています。
対象ユーザーへの推奨アクションは3つです。第一に、実務の1タスクで試すこと。API修正とドキュメント更新のような、互いに独立した作業から始めると効果を測りやすくなります。第二に、利用枠を事前に確認すること。ワーカースレッドはコーディネーターの会話と別に、モデルと計算量（Effort）をそれぞれ選べるため、常時Opus・高Effortで全スレッドを回す前提にしないことが重要です。第三に、競合しやすい変更は避けて割り振ること。同じファイルを複数スレッドが触る設計にすると、通常のマージコンフリクト対応が必要になります。
楽観だけでは語れない
第一の限界はコストです。各ワーカースレッドはそれ自体がフルセッションとして扱われるため、並列数を増やすほど利用枠の消費は単一セッションより速く進みます。数を増やせば増やすほど良い、という単純な話ではありません。
第二に、提供範囲がまだ限定的という点です。今回のベータは、既にクラウドセッションを利用しているPro/Maxの一部ユーザーが対象で、Web・デスクトップ版に既存のProjectsを持つユーザーは当面対象外とされています。ローカル実行への対応も今回時点では未提供です。
第三に、並列化がすべてのタスクに向くわけではないことです。密結合した変更を複数スレッドに分けると、結局は人間によるマージ調整の手間が発生します。恩恵が大きいのは、profiling対象のエンドポイントを分担する、API・Web・モバイルの移行を並行して進めるといった、もともと分割可能な仕事です。タスクを渡す前に「このワークはスレッド間で競合しないか」を一段見積もる習慣が、これまで以上に必要になります。