Claude Projects 刷新で何が変わったか｜並列スレッドが PR を開く仕組みと導入可否の判断基準

2026 年 9 月 17 日、Anthropic が Projects の刷新を発表しました。ファイルと会話をまとめておく入れ物から、作業が続くかぎり使い続ける 1 つの会話へ、位置づけそのものが変わっています。

ただ、この話を検索で追いかけると最初に混乱が起きます。「Claude Projects」で調べて出てくる解説の多くは、claude.ai のチャットにある従来の Projects の使い方です。公式ヘルプも 1 ページの中に新旧を併記しており、冒頭で新バージョンに触れたあと「この記事の残りの部分では、プロジェクトの現在のバージョンについて説明しています」と断って旧版の説明に戻ります。同じ名前で別の機能が 2 つ動いている状態です。

この記事で扱うのは Claude Code の Projects です。ナレッジベースに資料を置いて会話をまとめる旧 Projects をお探しなら、Anthropic 公式ヘルプが正確です。以下は、公式ブログと公式ドキュメントで確定している記述だけを根拠に、仕組みと導入可否の判断材料を整理します。以降、刷新後の Claude Code の Projects を「プロジェクト」と呼びます。

何が変わったのか — フォルダから 1 つの会話へ

刷新後のプロジェクトは、関連する作業をまとめて投げ込む場所です。公式ブログの説明では、Claude が依頼の範囲を定め、作業を委譲し、並列スレッドを調整し、出力をレビューし、完成した成果物を組み立てます。原文は "Claude scopes the request, delegates the work, coordinates parallel threads, reviews the outputs, and assembles the finished result." です。

分かりやすいのは、公式ドキュメントが置いている「プロジェクトを使わない場合」との対比のほうです。プロジェクトを使わずに複数のセッションを走らせる場合、調整は自分でやることになります。どのセッションに何をさせるかを決め、同じ前提を毎回書き直し、どれが終わってどれが返事を待っているかを見に行く。この 3 つを Claude 側へ移したのが今回の変更です。

作業を配る側のエージェントを置く、という構造そのものは Claude に固有のものではありません。Claude の発表の 1 週間前にあたる 2026 年 9 月 10 日には、Cursor が同じ型の機能を公開しています。委譲の構造とは何かについては Cursor Projects の解説記事で扱ったので、この記事では繰り返しません。ここからは Claude 側の仕様と、自社で使えるかどうかの判断に絞ります。

スレッドとコーディネーターの役割分担

プロジェクトは 2 つの層でできています。1 つはプロジェクトの会話で、ここにいる Claude がコーディネーターとして働きます。送られてきた内容を受け取り、何をスレッドにするかを決め、起動したスレッドを追跡します。もう 1 つがスレッドで、これは 1 つ 1 つが独立したクラウドセッションです。公式ブログの表現では、各スレッドはリポジトリの複製と専用のブランチを持つ Claude Code のクラウドセッションになります。

ここで先に押さえておきたい記述が 1 つあります。公式ドキュメントは、コーディネーターについて "It sees what threads report back, not every step they take." と書いています。コーディネーターが把握しているのはスレッドの報告であって、スレッドが踏んだ全ステップではありません。何が見えていないかが仕様として明示されているので、どこまで任せるかを決めるときの手がかりになります。

flowchart TB
  U["依頼・バグ報告・仕様変更"] --> C["プロジェクトの会話<br/>コーディネーター"]
  C --> T1["スレッド A<br/>複製 + 専用ブランチ"]
  C --> T2["スレッド B<br/>複製 + 専用ブランチ"]
  C --> T3["スレッド C<br/>複製 + 専用ブランチ"]
  T1 --> P1["PR"]
  T2 --> P2["PR"]
  T3 --> P3["PR"]
  P1 --> O["Overview<br/>レビュー待ち / 返答待ち / 実行中"]
  P2 --> O
  P3 --> O

スレッドはさらに内側で分割されます。公式ブログは、大きな割り当てを早く終わらせるために、スレッドがサブエージェント・ループ・ワークフローを使って作業をさらに分けられると説明しています。サブエージェントをどう設計するかは Claude Code のサブエージェント設計パターンに整理しました。

リポジトリを接続すると何が自動で起きるのか

スレッドがコードを変更するとき、指示がなければ次のように進みます。ブランチはリポジトリの既定ブランチから新しく切られます。PR は、依頼すれば開きますし、バグ修正のような具体的な変更では自分から開くこともあります。

PR が開いたあとの挙動は、任せたあとの手離れを一番左右します。スレッドはその PR を auto-fix を有効にした状態で見張ります。ほかのクラウドセッションで auto-fix を切っていても、プロジェクトのスレッドでは有効です。CI が失敗すれば修正を push し、レビューコメントにも対応し、チェックが通ってレビューできる状態になるとスレッド内で報告します。PR を開くタイミングや起点のブランチを変えたい場合は、依頼文かプロジェクト指示に書きます。

並列のスレッドが同じコードを触った場合は、通常の PR と同じ git のマージコンフリクトとして表面化します。特別な調停の仕組みが増えるわけではなく、これまでのレビュー運用の中で解決する形です。

任せたあとに自分が何を見ればよいかは、Overview ペインのスレッド一覧に集約されます。公式ドキュメントが挙げている分類は次のとおりです。

分類	入っているスレッド
Ready for review	PR が開いていて、レビューを待っている
Waiting on you	返答か承認を待っている、または失敗した
Working	まだ実行中
Landing	PR が承認済み、またはマージ待ちのキューに入っている
Idle	終わっていて、何も待っていない
Resolved	完了として扱われた。自分で印を付けるか、Claude が付けるか、1 週間の無活動で付く

デスクトップアプリでは、Claude が会話に投稿したとき、スレッドがエラーになったとき、スレッドが入力を求めたときに通知が出ます。ブラウザでは通知が出ないので、Overview ボタンに付くドットを見ることになります。

ベータで自社が使えるか — 前提条件と制約

ここが判断の分かれ目です。公式ドキュメントの前提条件と制約を、確認する順に並べます。

確認項目	公式ドキュメントの記述
プラン	Pro または Max。Team と Enterprise ではまだ使えない
リポジトリの所在	GitHub.com のみ。GitHub Enterprise Server・GitLab・Bitbucket は対象外
GitHub の権限	接続した GitHub アカウントに push 権限があり、Claude GitHub App がインストールされていること
組織のリポジトリ	インストールを完了できるのは組織のオーナーのみ。オーナー以外が試みると承認依頼が送られる
SAML SSO	強制している組織では、GitHub を接続し直して Claude アプリを認可するまで非公開リポジトリが表示されない
使える場所	claude.ai/code・デスクトップアプリ・モバイルアプリ。ターミナルの CLI では使えない
使えない経路	Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry
共有	プロジェクトは 1 ユーザーのもの。他のユーザーと共有できず、スレッドの記録にも共有の選択肢が無い
組織統制	ベータ期間中は、プロジェクトに対する組織レベルの統制が無い

/web-setup で GitHub をつないでいる場合の注意も書かれています。そのトークンはほかのクラウドセッションがリポジトリへ届くには足りますが、プロジェクトのスレッドには足りません。Claude GitHub App のインストールが別途要ります。

FIXIT

社内のリポジトリが GitHub Enterprise Server なんだけど、それでも試せるの？

Hayate

試せません。前提条件に例外は書かれていません。

FIXIT

じゃあ会社としては何もできないの？

Hayate

使い分けの目安で言うと、公開リポジトリか検証用の 1 本で先に触るのが速いです。判断材料はそれで集まります。

日本の事業会社が導入判断で最初に引っかかるのは、リポジトリの所在と、共有・組織統制の 3 行でしょう。とくに共有の扱いは、旧 Projects と突き合わせると変化の向きが分かります。チャット側の旧 Projects は、Team と Enterprise で表示可能・編集可能といった権限レベルを付けた共有ができ、個別・一括・組織全体への共有まで備えています。 刷新後のプロジェクトには、それがまだありません。同じ名前の機能でありながら、共有と統制の面ではベータ期間中に限って選択肢が狭まります。全社展開の設計そのものは Claude Code の全社導入ガイドに、監査の観点は Compliance API で追える範囲にまとめています。

もう 1 つ、作業が失われうる制約があります。スレッドのサンドボックスはターンとターンの間で一時停止し、再開時に戻ります。再開できなかった場合、スレッドは新しい複製から続きを始めるため、コミットしていない変更は失われることがあります。公式ドキュメントは、長い作業では途中経過をコミットして push するよう Claude に指示しておくことを勧めています。

リポジトリから読み込まれるものにも条件が付きます。各スレッドはプロジェクトの全リポジトリを複製し、そのすべてから CLAUDE.md・skills・plugins を読みます。一方で、権限ルールと hooks と env は、スレッドが起動したディレクトリの .claude/settings.json からしか読まれません。リポジトリが 1 つのプロジェクトではそのリポジトリの中が起点になりますが、複数リポジトリのプロジェクトでは複製したリポジトリ群の親ディレクトリが起点になるため、どのリポジトリの設定も読まれません。権限ルールを効かせたいなら、プロジェクトは単一リポジトリで作る必要があります。

利用枠を消費する経路と、その下げ方

費用については、倍率のような数字は公表されていません。公式ドキュメントが書いているのは、プロジェクトは単一のセッションより早く枠を使うこと、とくに Pro では実行した日に上限へ早く届くと考えておくべきこと、の 2 点です。

枠を使う要素として挙げられているのは次の 3 つです。

1. 走っているスレッド。1 つ 1 つが完全なセッションで、同時実行数に固定値は無い。会話で伝えた同時実行数の上限は、強制力のある設定ではなく、希望として扱われる。強制されるのは、全プロジェクト合計で 1 日 200 件という新規スレッドの上限のみ
2. プロジェクトの会話。コーディネーターがスレッドの報告を読み、次を決めるためにトークンを使う
3. PR を見張っているスレッド。待機中でも、CI が失敗したりレビューコメントが付いたりすると起き直して枠を使う。止めたい場合は、そのスレッドに対して PR の監視をやめるよう伝える

走っているスレッドも、見張っている PR も、新しいメッセージも無いプロジェクトは、放置していても枠を使いません。アーカイブしたプロジェクトも同じです。

下げ方として公式ドキュメントが挙げているのは 3 つです。1 つ目は既定値の見直しで、新規プロジェクトはスレッドが Opus の high effort、会話が Opus の low effort で始まります。最大のモデルが要らない作業では、モデルか effort を下げられます。2 つ目は古いスレッドの扱いです。キャッシュの有効期間 (Pro と Max では 1 時間) を超えて放置したスレッドに追加の依頼を回すと、そのスレッドの会話全体を読み直してから作業が始まります。新しい作業なら、新しいスレッドを立てるほうが消費が少ないことがあります。3 つ目は、同時に走らせるスレッドを減らすことと、小さな質問はスレッドを起こさずコーディネーターに答えさせることです。

上限に達したときの挙動も把握しておく価値があります。スレッドは自分で再試行を続け、上限がリセットされると自動で継続します。放置すると、次の利用枠を自分から使い始めます。 待たせたくなければ、スレッドの Stop を押すか、プロジェクトごと一時停止します。例外が 1 つあり、routine が起動したスレッドは待たずに上限エラーでターンを終えるため、リセット後に自分でメッセージを送ることになります。なお、使用クレジット (usage credits) を有効にしていないかぎり、上限を超えて消費されることはありません。プラン側の枠そのものについては 2026 年 9 月の週次上限の変更を参照してください。

いつ自分のところに来るのか

公式ドキュメントは、パブリックベータの対象を Pro と Max とし、段階的な提供だと明記しています。始まっているのは、クラウドセッションを使ったことがあり、claude.ai のチャットや Cowork に既存のプロジェクトを持たないアカウントからです。旧 Projects を持っていないことが初期の条件に含まれている点は、見落としやすいので確認しておいてください。公式ブログは、発表から 1 週間のうちに Pro と Max の Claude Code 利用者へ広げ、そのあと Team と Enterprise に向かうと説明しています。

自分に届いているかどうかは、claude.ai/code のサイドバーか、デスクトップアプリのコードタブに Projects が出ているかで確かめられます。出ていなければ順番がまだ回っていない状態で、公式のウェイトリストに登録できます。既存のチャット側 Projects は、刷新が届くまで今までどおり使えます。

ローカルでの実行については、公式ブログが "Threads run in the cloud today; running on your machine alongside your local tools and code and behind your network is coming very soon." と書いています。時期は示されていません。

Cursor Projects と何が違うか

1 週間差で出た 2 つの「配る側のエージェント」を、公表されている範囲だけで並べます。どちらが優れているかではなく、いま公表されている情報の量と種類が違うという事実として読んでください。

軸	Claude Projects (2026-09-17)	Cursor Projects (2026-09-10)
実行場所	クラウドセッション。ローカル実行は時期未定	クラウド上の専用マシン
手元での実行	ローカルセッションはプロジェクトに入れられない	テストが必要なときコーディネーターがローカルを起動する
起動条件	会話への投稿と routine によるスケジュール	Slack チャンネルの監視・スケジュール・PR の追跡
同時実行の上限	固定値は無い。新規スレッドは 1 日 200 件	作業に必要なだけ並列で実行する
既定のモデル設定	スレッドは Opus の high effort、会話は Opus の low effort	記載が無い
対象プラン	Pro と Max。Team と Enterprise は未提供	全ユーザーへ順次ロールアウト。プラン要件の記載が無い
リポジトリの前提	GitHub.com のみ。Claude GitHub App が必要	記載が無い
料金の公表	利用枠を使う要素と上限が公表されている	料金の記載が無い

この表から言えるのは、判断に使える情報が現時点では Claude 側に多い、ということだけです。Cursor 側の詳細は Cursor Projects の解説に、3 ツールを横に並べた選定の観点は Claude Code・Cursor・GitHub Copilot の比較にまとめています。

自前の並列運用は要らなくなるのか

worktree や tmux で複数セッションを回してきたなら、ここが一番気になるところだと思います。公式ドキュメントは近い機能との棲み分けを明記しており、結論から言えば用途が違うので残ります。

worktree は、手元の並列セッション同士が同じ作業コピーを上書きしないための仕組みです。スレッドは各自がクラウドのサンドボックスに複製を作って専用ブランチで作業するので、worktree を必要としません。agent team は 1 つのタスクのためにチームを立ち上げ、そのタスクとともに終わります。agent view はローカルセッションを並べて追う画面で、コーディネーターがありません。プロジェクトが持ち込んだのは並列そのものではなく、セッションの起動と追跡を Claude 側が担い、どのセッションも同じリポジトリ・指示・メモリから始まるという点です。自前でオーケストレーションを組んだときに何が要るかは Orca で Claude Code と Codex を組ませた記録に書きました。

手元に残る作業も明示されています。ローカル DB、実機のエミュレータ、VPN の内側にある API のように、手元のマシンからしか届かないものを使う作業は、プロジェクトに入れられません。ローカルセッションか agent view の領域です。ファイルだけが必要なら、プロジェクトにアップロードする選択肢があります。

逆に、プロジェクトが向くとされている作業は、日本の開発現場の言葉に直すと次のとおりです。

• 全リポジトリを新しい lint 設定に揃えるような、1 つの目的が複数リポジトリにまたがる作業
• 1 つのサービスに届くバグ報告やスタックトレースを、届くそばから投げ込む受け皿
• 1 セッションでは終わらない移行や、仕様書 1 本からの構築
• コード以外の資料、たとえば契約書の束や問い合わせログの書き出しに、何度も質問を投げる作業

まだ公表されていないこと

判断を急ぐ前に、公表されている範囲の外側を確認しておきます。2026 年 9 月 18 日の時点で、次の項目は公式ブログにも公式ドキュメントにも記載がありません。推測で埋めずに、更新を待つ領域です。

• Team と Enterprise への提供時期。公式ブログは初期のロールアウトのあととだけ書いています
• ローカル実行の提供時期。"coming very soon" の表現にとどまります
• ベータ期間中に組織レベルの統制が追加されるかどうか
• 日本語 UI の対応状況
• 1 日 200 件の上限を超えたときに何が表示され、いつ回復するか

FIXIT の運用 — 任せる先を増やす前に、戻ってくる場所を 1 つにする

私たちは AI 駆動開発のクリエイティブスタジオとして、複数のコーディングエージェントを並列で走らせる体制を実務で回しています。難所のレビューは上位モデルに寄せ、数で回す調査は軽いモデルに振り分ける、といった使い分けも同じ枠組みの中にあります。

その運用ではっきりしているのは、並列数を増やしたときに最初に詰まるのは実装側ではなくレビュー側だ、ということです。同時に何本も走らせれば、レビューの対象も同じ本数だけ同時に届きます。Claude Projects の Overview がスレッドを状態で分けているのは、レビューが詰まる問題への答えだと読めます。任せる先を増やす前に、戻ってきたものを見る場所と担当を 1 つに決めておきます。 順序を逆にすると、速くなったはずの工程が確認待ちで止まります。

もう 1 つは、既定値を最初に触る習慣です。何を最大のモデルでやり、何を下げるかを先に決めておくほうが、あとから請求を見て驚くより安く済みます。

今日から準備できること

ベータの順番がまだ回っていなくても、進められることがあります。1 つ目は、プロジェクト指示に相当する前提を各リポジトリの CLAUDE.md へ寄せておくことです。スレッドは手元の Claude Code の設定を引き継がず、リポジトリに置かれたものを読みます。2 つ目は、Claude GitHub App の組織承認を先に取っておくことです。組織オーナーの操作が要るため、必要になってから動くと待ち時間が発生します。3 つ目は、権限ルールと hooks が単一リポジトリのプロジェクトでしか適用されない前提で、どのリポジトリを 1 本のプロジェクトにまとめるかを考えておくことです。

最初の一歩としておすすめするのは、公開リポジトリか検証用のリポジトリを 1 本選び、そこだけでプロジェクトを作ってみることです。本番のコードを出す判断は、共有と組織統制が入ってからで間に合います。先に確かめるべきは、自社の依頼の書き方でスレッドが適切に分かれるかどうかです。

複数の AI 開発ツールを併用する体制づくりや、ガードレールの設計から進めたい場合は AI 開発ツール定着支援をご覧ください。自社のリポジトリ構成とレビュー体制に合わせた進め方は、お問い合わせから個別にご相談いただけます。