Claude Codeに、大きな開発目標をひとつ渡すだけでClaudeが作業を並列で進めるベータ機能「Projects」が加わりました。作業を計画して割り振るClaudeであるコーディネーターが目標をタスクに分解し、タスクごとに別のスレッドを立ち上げます。各スレッドはそれぞれ独立したClaude Codeセッションで、クラウド上の専用Gitブランチで動きます。狙いは、大きな仕事で必要だった手作業の調整、つまりサブエージェントの設定、複数のターミナルセッションの並行運用、worktreeの手動管理をなくすことです。ProjectsはProプランとMaxプランの利用者に順次提供されています。
通常のセッションとの違い
Projectsは3つの要素で構成されます。
| 要素 | 役割 |
|---|---|
| Project | 作業スペースとなる、継続するひとつの会話 |
| コーディネーター | 会話の中で目標をタスクに分け、すべてのタスクを割り振る |
| スレッド | 1つのタスクを担う独立したClaude Codeセッション。クラウド上の専用Gitブランチで動く |
最大の変化は、これまで別々のターミナルセッション、サブエージェント、worktreeを使って人が手作業で行っていた調整を、コーディネーターが引き受ける点です。
スレッドはクラウドで動くため、ノートPCを閉じても処理は続き、進み具合はスマートフォンからも確認できます。Chrome DevToolsのように自分のPCにしかないツールが必要なタスクは、そのスレッドだけをローカル環境に引き寄せられます。
この機能が向いているのは、複数のセッションや複数のリポジトリにまたがる目標です。例として、サポートが終了したパッケージを複数のリポジトリにまたがるアプリケーションから取り除く作業や、APIエンドポイントを変更してバックエンド、Webフロントエンド、モバイルアプリを同時に更新する作業が挙げられます。
▲ スレッドに作業を振り分けるコーディネーター
プロジェクトを作成する
デスクトップアプリかWebでClaudeタブを開き、「New project」を選びます。設定画面で決めるのは、名前、目標、プロジェクトが作業できるリポジトリやフォルダーの3つです。
性能が落ちたWebサイトを例にすると、次のようになります。
- 名前： Site Performance
- 目標： モバイルとデスクトップの両方でp75 LCPを2.5秒未満、CLSを0.1未満にする
- リポジトリ： マーケティングサイトとAPI
LCP（Largest Contentful Paint）はページの主要なコンテンツが表示されるまでの時間、CLS（Cumulative Layout Shift）は読み込み中にレイアウトがどれだけずれるかを示す指標です。どちらもページ体験の指標群であるCore Web Vitalsに含まれます。「p75」は訪問の75％がその数値を満たすという意味です。目標を測定できる数値で書いておけば、Claudeにとって完了の基準がはっきりします。
プロジェクトを作成するとメインの会話が開き、コーディネーターがあいさつとともに次の手順を提案します。
問題の報告から8つの並列スレッドへ
例では、コーディネーターへの依頼で症状をそのまま伝えました。マーケティングサイトのCore Web Vitalsが1カ月にわたって悪化し、モバイルのp75 LCPは4.1秒、CLSは0.28に達し、ページ遷移が遅いという声がユーザーから続いているという内容です。依頼は「調査して修正してほしい」という一文で締めくくりました。
Claudeは2つのコードベースを確認してボトルネックをたどり、優先順位を付けた計画を返しました。
- クライアント側のページ遷移
- 最適化されていない画像
- ページコンテンツのキャッシュ
- スクリプトの遅延読み込み
- Webフォントの事前読み込み
- JavaScriptバンドルの分割
- バナー表示領域の確保
- アセットの圧縮
開発者が計画を承認すると、Claudeは修正項目ごとに1つずつ、8つのワーカースレッドを一斉に起動しました。各スレッドは経過時間とGitブランチ名を示すカードとして表示されます。
スレッドを指揮する
スレッドは完全に自律して動けますが、人はいつでも中身を見て制御できます。
- 確認する： スレッドのカードをクリックすると、Claudeのリアルタイムのターミナル出力、変更中のコード、現在のステップが表示されます。
- 方向を変える： スレッドに直接指示を入力して優先順位を変えたり、すぐに止めたりできます。例では、画像最適化のスレッドに、ヒーロー画像は優先読み込みの画像として残すよう指示しました。
- 滞りを解消する： Threadsサイドバーに、実行中のワーカーと、人の入力を待って止まっているワーカーが表示されます。
作業を終えたスレッドは、GitHubにプルリクエストを自動で作成するか、公開する前にまず確認を求めます。例の修正には、34個の画像タグに幅と高さを明示する作業も含まれていました。スレッドはその後も自分のプルリクエストを見守ります。変更のたびに自動で走るビルドとテストである継続的インテグレーション（CI）のチェックを監視し、失敗したテストを直し、レビュー担当者の指摘に対応します。コーディネーターのフィードにはすべてのプルリクエストの状況がまとめられ、承認した変更は会話から直接マージできます。
例のプロジェクトの結果は次の通りです。
| 指標 | 修正前 | 目標 | 修正後 |
|---|---|---|---|
| モバイルのp75 LCP | 4.1秒 | 2.5秒未満 | 2.2秒 |
| デスクトップのp75 LCP | 記載なし | 2.5秒未満 | 1.4秒 |
| CLS | 0.28 | 0.1未満 | 0.08 |
▲ 修正後の性能指標
Library：すべてのスレッドが共有する成果物
Projectsには、Claudeが作成する文書などの成果物であるアーティファクトを置くLibraryタブがあります。例では、解決した問題と修正前後の数値をまとめたポストモーテムの作成をClaudeに依頼しました。Claudeは、モバイルLCP、デスクトップLCP、CLSを比較する棒グラフ入りのレポートを作成しました。
Libraryは、プロジェクトが継続して使う共有フォルダーとして機能します。生成した文書のほか、アップロードしたモックアップや技術仕様も置けます。現在のスレッドも今後のスレッドもここにある内容を読み、更新できるため、後のタスクは先のタスクが積み上げた文脈から始められます。
コネクターとルーティンで継続的にチェックする
コネクターは、プロジェクトを外部の開発ツールや監視ツールにつなぎます。Environment設定でSentryコネクターを有効にすると、Claudeが実際のユーザーのテレメトリーとエラーログを直接照会できます。
ルーティンは、定期的に繰り返す作業を追加する機能です。例では、毎日午後5時にマーケティングサイトのCore Web VitalsとエラーログをSentryから取得し、悪化したものがあれば調査して修正する、というひとつの指示で設定しました。毎日のチェックで性能の悪化が見つかると、Claudeは調査専用のスレッドを立ち上げ、レビューできる修正を入れたドラフトのプルリクエストを作成します。これにより、事後のデバッグがバックグラウンドで動く先回りのチェックに変わります。
使用量とコストを抑える
各スレッドは完全なClaude Codeセッションなので、複数を並列で動かすと、ひとつの会話よりはるかに速くプランの利用上限を消費します。Claude Codeチームの推奨は、いくつかの設定に集約されます。
| 設定 | 推奨 | 理由 |
|---|---|---|
| コーディネーターのeffort | Low | 役割は振り分けと計画で、深い推論ではない |
| スレッドの既定モデル | Sonnet 5.5 | 範囲が明確なタスクには十分 |
| 難しいスレッド | Opus 5.5 | 大きなモデルは複雑な作業に限って使う |
| 動作ルール | 同時実行スレッド数の上限、コーディング前の概要提出 | 想定外にスレッドが一気に増えるのを防ぐ |
モデルとeffortのレベルは、General設定でコーディネーターとスレッドに別々に設定でき、軽量なHaiku 4.5も選べます。コーディネーターをLowより上げても調整の質が目に見えて上がることはほとんどなく、主にトークンのコストが増えるだけのようです。スレッド数の上限のようなルールはコーディネーターとの会話に書き込みます。例では同時実行を5スレッドまでに制限しました。
すべてに適用したい基準は、プロジェクトメモリーに置きます。設定にあるMEMORY.mdファイルに、現在と今後のすべてのスレッドが引き継ぐコーディング規約や好みを書きます。入力できるのは最大16,000文字です。
まず試すときの手順
Projectsは、プロンプトひとつで終わる小さな作業よりも、リポジトリをまたぎ多くの段階を踏む目標で効果が大きいとみられます。最初は次の手順が妥当です。
- 複数のリポジトリやセッションにまたがる目標をひとつ選び、測定できる数値で書く。
- 関係するリポジトリをすべて接続し、コーディネーターの計画を確認してから承認する。
- コーディネーターのeffortをLowにし、スレッドの既定モデルをSonnet 5.5にして、同時実行スレッド数の上限を決める。
- チームのコーディング規約をMEMORY.mdに書き、すべてのスレッドが従うようにする。
- 同じチェックを繰り返すなら、コネクターとルーティンで自動化する。
Projectsはまだベータ版のため、機能や画面は変わる可能性があります。スレッドを増やすほど利用枠の消費も速くなるので、大きな目標を任せる前に、小さく明確な目標から始めるのが賢明です。