Claude Code、Projectsを再設計 - コーディネーターが並列スレッドを指揮する形に

Anthropicが2026年9月17日、Claude Codeのプロジェクトをベータで公開した。ゴールとリポジトリを設定するとコーディネーターが作業を切り出し、各スレッドが独立したブランチでPRを開く。並列で走るため使用上限に早く達すると明記されている。

Claude Anthropic coding AI-agents multi-agent developer-tools

Anthropicは2026年9月17日、Claude Codeのプロジェクト機能を作り直し、ベータで提供を始めた¹。ゴールとリポジトリを指定すると、Claudeが依頼の範囲を切り出し、作業を委任し、並列に走るスレッドを調整し、出力をレビューして成果をまとめる、という構成になっている。

同社はこれまでのやり方を、複数セッションをまたぐ作業では利用者が自分で仕事を分け、引き継ぎをやりくりし、結果を縫い合わせる必要があった、と説明している。今回は「何を終わらせたいか」を書けばClaudeが仕事の管理側に回る、というのが売りだ。スマートフォンからも進行を操作でき、利用者がPCから離れたあとも動き続ける。

スレッドが手を動かし、コーディネーターが差配する

プロジェクトは、作業をするスレッドと、それを差配するコーディネーターで構成される¹。

プロジェクトを始めるときに選ぶのはゴールと、リポジトリまたは文脈だ。Claudeは着手できそうな作業を先に提案する。クラウド環境、コネクター、プラグイン、指示、モデルはプロジェクト単位で設定できる。進行はプロジェクトのメインチャットで見守ることもでき、個々のスレッドに入って細部を確認・修正することもできる。Anthropicは、参謀長（chief of staff）に指示を出すようにプロジェクト内のClaudeに状況を伝えれば、新規または既存のスレッドに仕事を振り分けると書いている。

内部の作りは明快だ。各スレッドはClaude Codeのクラウドセッションそのもので、自分用のブランチとリポジトリの複製を持つ¹。コーディネーターが作業の整理は担うが、複数のスレッドが同じコードに触れた場合、その重なりは通常のPRと同じくマージ衝突として解決される。各スレッドはさらに、サブエージェント・ループ・ワークフローを使って割り当てられた仕事を細かく割ることもできる。

リポジトリが接続されていればスレッドはPRを開いてテストを走らせ、ドキュメントが与えられていれば読んで下書きを書く。示されている例は具体的だ。アプリの決済フローのp75レイテンシを下げるというゴールを置き、各エンドポイントのプロファイル、最適化の検証、PRの作成を並列スレッドで進める。あるいはAPI・Web・モバイルの3つのリポジトリをつなぎ、廃止予定のv1エンドポイントを畳むというゴールを置くと、Claudeはリポジトリごとにスレッドを立てて呼び出し側を移行し、テストを走らせ、PRを開き、どれを先にマージすべきかを伝える¹。

共有メモリとライブラリが、スレッドをまたいで積み上がる

Anthropicはこの機能を、1回の応答では終わらず複数の部分に分かれる長時間・エージェント的なワークフロー向けだと位置づけている。

そのための仕掛けが2つある。ひとつは共有メモリで、すべてのスレッドがそこに書き足し、そこから読み出す。複雑なプロンプト設計の必要を減らすとされる。覚える内容としてAnthropicが挙げているのは、リリースが金曜に動いたこと、エクスポート機能を落とした理由、課金サービスに手を入れる前に誰に確認すべきかといった類のものだ。利用者の働き方や連絡の好みも記憶し、確認の頻度、新しいスレッドを立てる頻度、更新の詳しさを指定できる。

もうひとつはライブラリで、利用者が追加したファイルとClaudeが生み出した成果物を集める。関連資料を見つけやすくし、新しい作業が過去の成果の上に積めるようにするためだとしている。

この「コーディネーター＋並列の下位エージェント＋共有コンテキスト」という構図は、Cursorが9月10日にベータ公開したProjectsとよく似ている。ただし設計の詳細は同じではない。Cursorはコーディネーターが自分ではコードを書かないと明示していたが、今回のAnthropicの説明ではコーディネーターの役割に「出力のレビュー」と「成果の組み立て」が含まれ、書かないとは書かれていない。逆にAnthropic側は、スレッドが独立したブランチとリポジトリの複製を持ち、衝突は普通のマージ衝突になるという点をはっきり書いている。

衝突の扱いを明示したことには前段がある。Anthropic自身が8月に公開した実験では、30体のエージェントのうち18体が同じブランチ名を作るなど、似たエージェント同士が同じ判断に行き着く失敗の型が示されていた。今回の設計は、その問題を「レビュー可能なマージ衝突に落とす」形で受け止めたものと読める。

並列で走る分、上限には早く触れる

導入前に確かめたいのは提供範囲と消費のほうだ。

初日の対象は、Claude Codeでクラウドセッションを使っており、かつWebやデスクトップに既存のプロジェクトを持っていないPro・Max契約者の一部に限られる¹。その後1週間かけて同じプランのClaude Code利用者へ広げ、Claude全体とTeam・Enterpriseプランへの展開はその後になる。Pro・Maxでまだ使えない場合は待機リストに登録できる。既存のプロジェクトはこれまで通り動き、chatとCoworkへ展開が広がる段階で更新される。The Vergeは、提供範囲が後にCoworkと通常のClaudeチャットにも広がるとしている²。

消費については、Anthropicが自ら注意を書いている。プロジェクトは複数のスレッドを同時に走らせ、そのそれぞれが完全なClaude Codeセッションであるため、使用上限に早く達しうるという¹。対策として、プロジェクト単位の使用状況を確認でき、コーディネーターのチャットとワーカースレッドのそれぞれにモデルとeffortのレベルを選べるようになっている。

ここは9月14日に週次上限の算定方式が変わった直後という時期を踏まえて読んだほうがいい。同じプランのまま並列度を上げれば、上限に触れるまでの時間は当然短くなる。最初から本番の移行作業を丸ごと任せるより、スレッド数とモデル・effortの組み合わせを絞って小さな作業で消費の感覚をつかむ順序になる。

もうひとつの制約は実行場所だ。スレッドは現時点ではクラウドで動き、自分のマシン上でローカルのツールやコードと並べて、自社ネットワークの内側で動かせるようにするのは「ごく近いうち（very soon）」とされている¹。手元の環境や社内ネットワークに依存する作業を前提にしている場合、現状では対象を選ぶ必要がある。

長く走るエージェントの管理をツール提供側が引き受ける動きは、OpenAIがCodexのハーネスをマネージドで提供するAgents APIをパブリックベータにしたのと同じ方向にある。利用者の手元に残るのは、どのゴールを与え、どこまで確認するかの設計だ。使用上限とレビューの線引きを先に決めておけるかどうかで、この機能の使い勝手は分かれる。