Claude Code Projects 入門、コーディネーターと並列スレッドの使い方

Posted at 2026-10-21

はじめに

Claude Code で機能追加と調査とリファクタリングを同時に進めたいとき、これまではセッションを複数開いて指示を出し分け、どの作業をどこまで任せたかを自分で覚えておく必要がありました。並列にすること自体は難しくありません。負担として残るのは、「誰に何を振ったか」「どの決定を全員に伝えたか」を人間が抱え続けることです。

Anthropic が 2026 年 9 月 17 日に公開した Projects の再設計は、この振り分けと取りまとめを Claude 側のコーディネーターに任せる仕組みです。目標を 1 つ伝えると、コーディネーターが作業を切り分けて複数のワーカースレッドを並列に起動し、出てきた成果をレビューして組み立てます。

では、並列スレッドはどこで動き、コードはどう合流し、決定事項はどうやって全スレッドに行き渡るのでしょうか。この 3 点を押さえずに使い始めると、使用量の急増とレビュー待ちの PR の山に同時に向き合うことになります。

対象読者は、既に Claude Code を使っていて、複数の作業を並列に進めたい個人開発者・チームの方です。

Projects は 2026 年 9 月時点でベータ提供中で、一部の Pro / Max 利用者から段階的に展開されています。本記事は公式ブログと報道記事に基づく解説で、実機での動作検証は含みません。公式ブログに記載がなく報道にのみある情報は、その都度「二次報道」と媒体名を明記しています。

この記事で解決できること

コーディネーター・ワーカースレッド・共有メモリ・ファイルライブラリの関係を把握できます
公式ブログが示す流れに沿って、プロジェクトを立ち上げる 5 つの段階を押さえられます
既存の Agent Teams・Dynamic Workflows とどう使い分けるかを判断できます

前提条件

Claude Code のクラウドセッションを利用できる Pro / Max プラン（ベータ・段階展開中）
接続するリポジトリ、またはドキュメント類
2026 年 9 月時点ではクラウド実行のみ（ローカル実行は公式が「近日」提供予定と説明）

TL;DR

目標とリポジトリを渡すと、コーディネーターが作業を分割して並列スレッドに割り振れるようになります
各スレッドは独立したクラウドセッションとして専用ブランチで作業し、成果は PR として戻ってきます
決定事項は共有メモリ、生成物はファイルライブラリに集まるため、スレッド間の伝言を手作業で管理せずに済みます
その代わり使用量の消費は速く、2026 年 9 月時点ではクラウド実行に限られます

Projects の構成

公式ブログの説明を構成要素ごとに整理すると、次の表のとおりです。

構成要素	役割（公式ブログの説明に基づく）
コーディネーター	依頼の範囲を決め、作業を委任し、並列スレッドを調整し、出力をレビューして完成物を組み立てる
ワーカースレッド	それぞれが独立した Claude Code のクラウドセッション。専用のブランチとリポジトリのコピーで作業し、PR の作成やテストの実行まで担う
共有メモリ	すべてのスレッドが追記し、参照する。プロジェクトの詳細を蓄積し、複雑なプロンプト設計の必要を減らす
ファイルライブラリ	ユーザーが追加したファイルと、Claude が生成したアーティファクト（成果物）を 1 か所に集める

ざっくり言うと、コーディネーターは作業を割り振るリーダー、ワーカースレッドは担当者、共有メモリはチームの議事録、ファイルライブラリは共有フォルダにあたります。

コードの合流は Git の通常の流れに乗ります。公式ブログによると、複数のスレッドが同じコードに手を入れた場合、その重なりは他の PR と同じくマージコンフリクトとして解決されます。Projects 独自の自動統合があるわけではなく、ブランチと PR という既存の仕組みがそのまま合流点になります。

さらに各スレッドは、任された作業を必要に応じてサブエージェント・ループ・ワークフローへ分割できると公式ブログは説明しています。Projects が最上位で目標を分け、その下のスレッドがさらに細かく並列化する入れ子の構造です。

手順: 5 つの段階でプロジェクトを立ち上げる

公式ブログの記述を、筆者が手順として並べ直すと、プロジェクトの立ち上げから運用までは次の 5 段階になります（公式が 5 段階の手順として定義しているわけではありません）。

1. ゴールを設定する

プロジェクトを始めるときは、最初に目標（ゴール）を 1 つ決めます。公式ブログの例は「アプリのチェックアウトの p75 レイテンシ（全リクエストの 75% がその時間内に収まる応答時間）を下げる」というものです。この目標に対して、Claude が各エンドポイントをプロファイルし、最適化案をテストし、並列スレッドでそれぞれ PR を開く流れが示されています。

ゴールには範囲と完了条件まで書いておくと、コーディネーターが分割の単位を決めやすくなります。公式の例を下敷きにすると、たとえば次のような書き方が考えられます。

目標: チェックアウト API の p75 レイテンシを下げる
範囲: チェックアウト関連のエンドポイントに限定する
進め方: エンドポイントごとにプロファイルし、改善案ごとに別スレッドで PR を作る
完了条件: 既存テストがすべて通り、PR 本文に計測方法と改善前後の値が書かれている
確認先: 決済まわりの仕様判断はメインチャットで人間に確認する

これは指示文の書き方の一例で、特定の書式が要求されているわけではありません。「エンドポイントごと」のように変更範囲が重ならない分け方を先に示しておくと、後述するマージコンフリクトも減らせます。

2. リポジトリとコンテキストを選ぶ

次に、目標と一緒にリポジトリやコンテキストを選びます。何を接続するかで、スレッドが担える作業が変わります。

接続するもの	スレッドが担う作業（公式ブログの説明）
リポジトリ	PR を開き、テストを実行する
ドキュメント	内容を読み取り、下書きを作る

接続するものは目標に直接関わる範囲から始め、必要に応じて足していくと、各スレッドの作業範囲を把握しやすくなります。

3. 環境・コネクタ・プラグイン・指示・モデルを設定する

公式ブログによると、プロジェクトごとにクラウド環境・コネクタ・プラグイン・指示・モデルを設定できます。あわせてプロジェクト単位の使用量を確認でき、コーディネーターのチャットとワーカースレッドのそれぞれについて、モデルと effort（推論にかける労力の度合い）を選べます。

既定値については、二次報道（implicator.ai）が「ワーカースレッドは Opus・高 effort、コーディネーターの会話は低 effort が既定」と伝えています。公式ブログにはこの記述がないため、実際の既定値は設定画面で確かめてください。

指示（instructions）には、全スレッドに共通する前提を書いておくと、スレッドごとに同じ説明を繰り返さずに済みます。たとえば次のような項目です。

テストの実行コマンドと、PR 前に通すべきチェック
ブランチ名や PR 本文の書式
触ってはいけないディレクトリや、人間の確認が必要な判断

4. メインのプロジェクトチャットで進捗を見守る

プロジェクトが動き出したら、メインのプロジェクトチャットで進捗を確認し、方向を修正します。公式ブログは、プロジェクトへの依頼を「chief of staff（首席補佐官）に指示するように」伝えれば、コーディネーターが新規または既存のスレッドへ作業を振り分けると説明しています。

コーディネーターの自律度も調整できます。二次報道（DevOps.com）によると、チェックインの頻度、新しいスレッドを立ち上げる積極性、更新で伝える情報の細かさを制御できます。最初はチェックインを多めにして、分割の仕方がゴールの意図に合っているかを確かめてから自律度を上げていく運用が考えられます。

5. 個別スレッドで詳細を確認・操作する

細部を確認したいときは、個々のスレッドに入って中身を見て、指示を出せます。スレッドの成果はブランチと PR として残るため、最終的な取り込み判断は通常のコードレビューと同じ手順で行います。

スレッドがさらにサブエージェントやワークフローへ作業を分けている場合も、入口はそのスレッドです。「プロジェクト全体の方向はメインチャット、個別の実装判断はスレッド」と話しかける先を使い分けると、指示の食い違いを減らせます。

共有メモリとファイルライブラリの使いどころ

公式ブログによると、すべてのスレッドが共有メモリに追記し、共有メモリから情報を引き出します。これにより、複雑なプロンプトエンジニアリングの必要が減るとされています。二次報道（DevOps.com）は、締め切り・技術的な決定・コミュニケーションの好み・「リリースが金曜に移った」といった事実がスレッドをまたいで保持されると伝えています。

共有メモリに残しておくと効くのは、スレッドの外で決まり、スレッドの作業を左右する情報です。

種類	例
日程の変更	リリース日が変わった、締め切りが前倒しになった
取りやめた判断とその理由	ある機能を今回のスコープから外した理由
確認先	仕様の最終判断を誰に仰ぐか
技術的な決定	採用したライブラリや、避けると決めた実装方式

記憶の実体については、二次報道（implicator.ai）が、メモはファイルとして保存され、新しいスレッドは MEMORY.md というインデックスを読むと伝えています。公式ブログは「共有メモリ」とだけ説明しており、この具体的な仕組みには触れていません。

構造上の注意として、共有メモリに入った前提は全スレッドが参照するため、誤った前提も同じように広がります。方針を変えたときはメインチャットで明示的に伝え直し、古い決定が残らないようにしておくと安全です。

ファイルライブラリは、ユーザーが追加したファイルと Claude が生成したアーティファクトを集める場所です。公式ブログは、資料を探しやすくし、後続の作業が過去の成果の上に積み上がるようにする目的を挙げています。仕様書や計測結果のように複数のスレッドが参照する資料をここに置いておくと、スレッドごとに同じ資料を渡し直さずに済みます。

使用量と上限の注意点

Projects で最も気をつけたいのは使用量です。公式ブログは、プロジェクトが複数のスレッドを同時に動かし、その 1 つ 1 つが完全な Claude Code セッションであるため、使用量の上限に早く達しうると明記しています。報道（XenoSpectrum）も、複数スレッドで自律エージェントが同時にコードを書くことで、通常の対話型チャットよりはるかに速く上限に達すると指摘しています。

公開情報の数値と提供状況を出典の種類ごとに並べると、次のとおりです。

項目	内容	出典
公開日	2026 年 9 月 17 日	公式ブログ
提供形態	ベータ。既存のプロジェクトを持たない一部の Pro / Max のクラウドセッション利用者から開始	公式ブログ
展開予定	翌週にかけて Claude Code の Pro / Max 利用者へ拡大し、その後 Team / Enterprise、チャット・Cowork へ	公式ブログ・Unite.AI
ローカル実行	近日提供予定	公式ブログ
同時スレッド数	固定の上限なし	二次報道（implicator.ai）
新規スレッド数	1 サブスクリプションあたり、全プロジェクト合計で 1 日 200 件が唯一の強制上限	二次報道（implicator.ai）

同時スレッド数に固定の上限がない一方で、1 スレッドが 1 セッション分の使用量を消費するため、並列数はそのまま消費速度に効きます。最初は並列数の少ない小さな目標で始め、プロジェクト単位の使用量を見ながら規模を広げていく進め方が現実的です。

導入判断の観点

ここからは公式の仕様説明と報道から導いた考察で、実機検証に基づくものではありません。

向くタスクと向かないタスク

Projects の並列単位は「スレッド＝専用ブランチ＝PR」です。したがって、作業を PR 単位に独立して切り出せるかどうかが向き不向きを分けます。

分類	タスクの例	理由
向く	エンドポイントやモジュールごとに独立した改善	スレッドと PR の単位にそのまま分かれ、変更範囲が重なりにくい
向く	調査とドキュメントの下書きを並行させる作業	ドキュメント接続時は読み取りと下書きに対応している
向く	数日にわたり決定事項が積み上がる作業	前提の伝言を共有メモリが肩代わりする
向かない	1 つのファイルに変更が集中する修正	並列にしてもマージコンフリクトが増えやすい
向かない	機密コードを外部クラウドへ送れない環境	2026 年 9 月時点ではクラウド実行のみ
向かない	PR をレビューする人手が足りないチーム	成果が PR として並ぶため、レビューが律速になる

最後の行は見落とされやすい観点です。DevOps.com の記事では、アナリストが「並列で動かせることは売り込みやすいが、信頼を得るのは、すべてのスレッドが誰かのレビューする PR として着地する点だ」という趣旨を述べています。同じ記事は、何を委任し、いつマージし、何を完了とみなすかというコーディネーションの判断が、デモより雑然としたコードベースで人間のテックリード並みに持ちこたえられるかを論点に挙げています。

並列化で速くなるのは変更を生み出す側で、取り込む側（レビューとマージ）は人間のペースのままです。導入前に「1 日に何本の PR をレビューできるか」を見積もり、それを並列数の目安として扱うと、レビュー待ちの PR が積み上がる事態を避けやすくなります。

Agent Teams・Dynamic Workflows との使い分け

Claude Code には、既に Agent Teams（複数の Claude Code インスタンスをチームとして協調させる機能。公式ドキュメント上は実験的機能で既定では無効）と Dynamic Workflows（オーケストレーションスクリプトを生成してサブエージェントを並列実行する機能）があります。3 つはいずれも並列化の仕組みですが、並列にする単位と成果の戻り方が異なります。

観点	Projects	Agent Teams	Dynamic Workflows
並列の単位	スレッド（独立したクラウドセッション・専用ブランチ）	チームメイト（独立した Claude Code インスタンス）	サブエージェント（生成されたスクリプトが起動）
協調の仕組み	コーディネーターが委任・レビュー・取りまとめを担い、共有メモリで前提を共有	共有タスクリストとチームメイト間のメッセージ、リードによる管理	スクリプトが各サブエージェントの結果を集約
成果の戻り方	スレッドごとのブランチと PR	リードのセッションに集まる	最終レポートとしてセッションに返る
想定しやすい時間軸（考察）	決定事項を持ち越しながら数日続く目標	1 つのセッション内での議論・検証	1 回で終わる大規模な一括処理

判断の目安は次のとおりです。

1 回の調査・監査・移行を一度に片付けたい場合は Dynamic Workflows
1 つの問題を複数の視点で議論・検証したい場合は Agent Teams
数日かけて複数の PR を並行して進め、決定事項を持ち越したい場合は Projects

3 つは置き換えの関係ではなく、入れ子にできる点にも注目しておくと設計の幅が広がります。公式ブログによると Projects の各スレッドはサブエージェント・ループ・ワークフローに作業を分割できるため、Projects で目標を PR 単位に分け、スレッドの中でさらに並列処理を使うという階層的な構成が仕様上とれます。

使用量とデータの置き場所

ワーカースレッドの既定が高 effort であるという二次報道が正しければ、スレッドを増やすほど消費が大きくなります。調査のように軽い作業のスレッドは、モデルと effort を見直す余地があります。

データの置き場所については、XenoSpectrum が、機密コードの外部クラウドへの送信を禁じる企業にとって現状のクラウド限定は導入障壁になると指摘しています。こうした組織では、公式が「近日」とするローカル実行の提供後に改めて評価するのが現実的です。

よくある疑問

Q1: Projects の新しい画面が表示されない

段階展開中です。公式ブログによると、ベータは Claude Code でクラウドセッションを使っている Pro / Max 利用者のうち、既存のプロジェクトを持たない一部から始まり、翌週にかけて対象が広がります。Team / Enterprise はその後の展開です。

Q2: 既存のプロジェクトはどうなるのか

公式ブログによると、Pro / Max の既存プロジェクトはこれまでどおり動作し、展開がチャットと Cowork に広がる段階でアップグレードされます。

Q3: ローカルのツールや社内ネットワークの内側で動かしたい

現時点ではスレッドはクラウドで動きます。公式ブログは、手元のマシン上でローカルのツールやコードと並べて動かす機能を「近日」提供するとしています。

Q4: 2 つのスレッドが同じファイルを変更したらどうなるのか

通常の PR と同じくマージコンフリクトとして扱われます。コンフリクトを減らすには、ゴールを書く段階で「エンドポイントごと」「モジュールごと」のように、変更範囲が重ならない分け方を指定しておくのが有効です。

導入前に確認する 3 点

Projects は、目標を渡せば分割・並列実行・取りまとめまでを Claude が担う方向へ Claude Code の使い方を広げる機能です。一方で、成果の取り込みと使用量の管理は利用者の側に残ります。導入前に次の 3 点を確認しておくと、判断がぶれにくくなります。

ゴールを「スレッド＝ブランチ＝PR」の単位に、変更範囲が重ならない形で分けられるか
並列に出てくる PR をレビューする体制があるか
コードをクラウドへ送ってよいか、使用量に余裕があるか

この 3 点がそろう作業から小さく始め、プロジェクト単位の使用量とレビューの負荷を見ながら並列数を広げていくのが、ベータ期間中の堅実な入り方です。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up