メインコンテンツまでスキップ

Projects: コーディネーターと並列スレッド

上級

2026 年 9 月 17 日、Anthropic は Projects を作り直しました。旧来の Project はフォルダでした。ファイル、指示、そしてそれらを共有する大量のチャット。新しい Project は組織図です — 「作業を行うスレッドと、それらを指揮するコーディネーター」。

これは聞こえるより大きな変化です。Project はもはやコンテキストを置く場所ではありません。あなたの代わりに作業を実行するものです。メインのプロジェクトチャットで成果を記述すると、Claude がそれを範囲づけし、分割し、並列のスレッドへ委譲し、戻ってきたものをレビューし、結果を組み立てます。

What you'll learn
  • スレッドとは実際に何なのか — そして「自分専用のブランチ上で動く Claude Code のクラウドセッション」という一文が鍵である理由
  • コーディネーターがサブエージェントのオーケストレーターとどう違うのか、そしてそれぞれがふさわしい場面
  • 現在の Claude Code で作業を並列に走らせる 4 つの方法と、その選び分け
  • Projects が利用上限をより速く消費する理由と、それを制御する 2 つのモデル／エフォートのダイヤル
  • あなたのアカウントにまだ再設計版が見えないかもしれない理由を説明する対象条件

1 枚の図で見るアーキテクチャ​

重要な要素は 3 つあり、混同しやすいものです:

  • コーディネーターはメインのプロジェクトチャットです。Anthropic の言い方は、チーフ・オブ・スタッフにブリーフィングするようなもの。必要なことを伝えると、新規または既存のスレッドへ作業をルーティングします。
  • スレッドは軽量なワーカーではありません。「内部的には、各スレッドは自分専用のブランチとリポジトリのコピー上で動く Claude Code のクラウドセッションです」。独自のコンテキストウィンドウ、独自のツール、そして担当分が十分大きければサブエージェント、ループ、ワークフローを起動する能力を備えた完全なセッションです。
  • 共有メモリとライブラリは、ファンアウトが断片化しないよう保つものです。すべてのスレッドが同じメモリプールから引き出し、ライブラリは「あなたが追加したファイルと Claude が生成した成果物を集める」ので、出力が閉じたセッションの中で死ぬのではなく見つけられる状態に保たれます。

リポジトリを接続しておけば、スレッドは自分でプルリクエストを開き、テストを実行します。スマートフォンを含め、どこからでも監視と舵取りができます。

それ以外のすべてを決める一文​

各スレッドは、自分専用のブランチとリポジトリのコピー上で動く Claude Code のクラウドセッションです。

これは 3 つの別々のコミットメントとして読んでください:

  1. 専用のセッション → 専用のコンテキストウィンドウ。スレッドは、1 つのセッション内のサブエージェントのようにコンテキスト予算を共有しません。ファンアウトが親のウィンドウを食い潰すことはもうありません。
  2. 専用のブランチ → スレッドは互いのファイルを上書きできません。分離はプロンプトの規律ではなく git によって強制されます。その代償として、統合はマージ時へ移ります。
  3. 専用のリポジトリのコピー → スレッドはテストを実行し、依存関係をインストールし、物を壊すことができます。あなたのマシンにも、他のスレッドにも触れずに。

その 3 点目は現在の天井でもあります。スレッドはクラウドでのみ動きます。Anthropic は「あなたのマシン上で、ローカルのツールやコードと並んで、ネットワークの内側で動くのは間もなく」と述べていますが、それが到着するまでは、ローカルのサービス、VPN 経由でしか届かないホスト、未公開の依存関係を必要とするものは Projects の外に留まります。

4 種類の並列性から選ぶ​

Claude Code は今や、一度に複数のことをする方法を 4 つ提供しています。それらは互換ではなく、間違ったものを選ぶことがここでの最もよくある失敗です。

仕組み誰がオーケストレートするか分離コンテキスト最適な用途
サブエージェント1 つのセッション内の、あなたのメインエージェント同じ作業ツリーセッションの上限を共有。同時 20、深さ 3 が上限単一タスク内での読み取りと調査のファンアウト
ワークツリーあなたが手動で別のブランチ + ディレクトリ、ローカル自分で開始する別々のセッション見守り制御したいローカルの並列作業
セッション間メッセージングあなたが、セッションを名前で指定して各セッションがすでに持っているもの独立すでに動いているセッション同士の調整
プロジェクトスレッドClaude が、コーディネーターから別のブランチ + リポジトリのコピー、クラウド上スレッドごとに独立範囲づけ、分割、組み立てを任せたい大きな担当作業

誠実な経験則:

  • 作業が 1 セッションに収まり、主に読み取りであればサブエージェントを使う — セットアップ不要で最も安い。
  • 自分のマシン上で一歩ずつ監督したいならワークツリーを使う。
  • 分割の仕方が自分には明らかで、自分で決めたいなら、ワークツリーかメッセージングを使う。Projects が価値を持つのは、まさに分解そのものが難所であるとき。
  • 担当作業が大きく、分割が自明でなく、ターミナルにつきっきりになるよりスマートフォンから様子を見たいなら、Projects を使う。

セットアップする​

Guided walkthrough1 of 6
  1. 成果と、関連するリポジトリまたはコンテキストを最初に選びます。コーディネーターは両方を使って最初の作業スライスを提案するので、曖昧なゴールは曖昧な委譲を生みます。

コストモデル、率直に​

Anthropic はこれについて率直です。「Projects は利用上限により速く達し得ます」。理由はアーキテクチャから導かれます。すべてのスレッドが完全な Claude Code のクラウドセッションなので、5 スレッドは 1 セッションを 5 分割したものではなく、おおよそ 5 セッション分の消費が同時に走っている状態です。

ダイヤルは 2 つあり、それがコストの物語のすべてです:

Pro tip
  • コーディネーターのモデル／エフォート — 範囲づけ、レビュー、組み立てを行います。多く読んで少なく書くので、能力の高い推論が効きます。
  • スレッドのモデル／エフォート — これはスレッド数で掛け算されます。ここを一段下げることが、できる中で最もレバレッジの高いコスト変更です。
  • プロジェクトごとの使用量が個別に見えるので、グローバルな上限から推測しなくてもプロジェクトのコストが分かります。

そこから導かれるパターン: コーディネーターは鋭く保ち、ワーカーは釣り合いを取る。 テストの作成、マイグレーション、ドキュメントの一括修正といった機械的な作業を低いエフォートのスレッドに委譲し、コーディネーターは高いエフォートでレビューする。これで、掛け算された支出のごく一部で品質のほとんどが得られます。これはサブエージェントを安いモデルにルーティングするのと同じ経済であり、それを 1 階層上に適用したものです。

まだ使えないかもしれない理由​

このベータのゲートは異様に具体的で、単純なパーセンテージ展開だと思い込む人を引っかけます。ローンチ時、アクセスが与えられたのは:

Claude Code でクラウドセッションを使っていて、かつウェブまたはデスクトップに既存のプロジェクトを持っていない、選ばれた Claude Pro と Max の購読者

3 つの条件があり、すべて必須です:

条件なぜ効いてくるのか
Pro または Max プランTeam と Enterprise は、コンシューマー向け展開のあとに続く
Claude Code ですでにクラウドセッションを使っているローカル専用のユーザーは、どれだけヘビーに使っていても第一波には入らない
ウェブまたはデスクトップに既存のプロジェクトがない意外な条件 — 旧 Projects の早期でヘビーなユーザーであることが、ローンチ時にはむしろ資格を失わせた

3 つ目のルールが罠です。長年の Projects ユーザーこそ、再設計版を目にする可能性が最も低いのです。既存プロジェクトの移行パスがまだ出荷されていなかったからです。既存のプロジェクトは展開期間中も動き続けます。アクセスのない Pro と Max のユーザーはウェイトリストに参加できます。Anthropic は、アクセスは「今後 1 週間かけて」それらのプランのより多くの Claude Code ユーザーへ、次いで Claude の残りへ、さらに Team と Enterprise へ広がると述べました。

よくある間違い​

  • コーディネーターをプロンプト入力欄として扱うこと。 これは委譲者です。成果と制約を与えてください。順序立てた手順のリストを渡すなら、単一セッションのほうが上手くやることに対してオーケストレーションのオーバーヘッドを払うことになります。
  • スレッドがあなたのローカル状態を共有すると思い込むこと。 スレッドが持つのはリポジトリのクラウドコピーです。コミットしていないローカルの変更、ローカルの env ファイル、localhost 上のサービスはそこにありません。
  • 分離が競合を取り除くのではなく先送りするだけだと忘れること。 スレッドごとのブランチが保証するのは、実行中にスレッド同士が互いを潰さないことです。同じモジュールに触れる 3 つの PR がきれいにマージされることは保証しません。可能な限りモジュール境界に沿ってスレッドを切ってください。
  • スレッドのエフォートをコーディネーターと同じ水準のままにすること。 その設定はスレッド数で掛け算されます。担当作業の途中で上限に達する最速の方法です。
  • 自分のマシンを必要とする作業に使うこと。 ローカルネットワークやローカルツールへの依存があるものは、ローカルスレッドが出荷されるまでワークツリーに属します。

これが示すもの​

Projects は、Anthropic が分解そのものを製品にした最初の場所です。サブエージェントは、あなたが定義したタスクの中でモデルにファンアウトさせるものでした。Project はモデルにタスクの定義を求めます。Anthropic が公開することを選んだコントロール — チェックインの頻度、新しいスレッドをどれだけ積極的に開くか、コーディネーターとワーカーで別々のエフォート — はすべてどれだけの自律性を委譲するかのつまみであり、エージェント製品全般がどこへ向かっているかについての有用なシグナルです。この設計がぶつかる制約が生成ではなくレビューである理由は、検証のボトルネックを参照してください。

Check yourself

0/3
  1. プロジェクトのスレッドとは、技術的には何ですか?
  2. なぜ Projects は単一セッションより速く利用上限に達するのですか?
  3. ローンチ時、アカウントをベータの対象外にした条件はどれですか?
Key takeaways
  • Project は今やフォルダではなくオーケストレーション層である: コーディネーターが範囲づけして委譲し、スレッドが実行する。
  • スレッドは自分専用のブランチとリポジトリのコピーを持つ完全なクラウドセッション — 独立したコンテキスト、自分の PR、自分の消費。
  • 分解そのものが難所のときは Projects に手を伸ばし、分割がすでに分かっているときはサブエージェントかワークツリーに手を伸ばす。
  • スレッドのエフォートはスレッド数で掛け算され、コーディネーターのエフォートは掛け算されない。別々に調整すること。
  • スレッドは現時点でクラウド専用なので、ローカルツールやプライベートネットワークを必要とするものは当面ワークツリーに留まる。

次へ​

出典と参考文献​