Claude Code が刷新された「Projects」機能をリリース：1つの会話がリーダーとなり、複数のクラウドスレッドを自動展開して並行作業、PCを閉じても止まらない

Claude の旧版 Projects（claude.ai のチャットや Cowork 内のプロジェクト）では、プロジェクトは会話と参照用ファイルをひとまとめにするだけの場所にすぎず、スレッドもコーディネーターも存在しませんでした。複数の Claude Code セッションを同時に実行しようとすれば、どのセッションに何をさせるかを決め、各セッションの冒頭で同じ背景情報を繰り返し説明し、どれが完了してどれが自分の回答を待っているかを一つひとつ確認して回るといった調整作業を、すべて人間自身がこなさなければならなかったのです。何日もかかり、複数のコードリポジトリにまたがるような作業であれば、開発者自身がまさにそのスケジューラー役を務めることになっていました。

Anthropic は Claude Code の Web 版（claude.ai/code）とデスクトップアプリにおいて、新設計の「Projects」機能をリリースしました。現在は Pro および Max サブスクリプションユーザー向けのパブリックベータとして提供されています。今回の刷新における核心的な転換は、「静的なフォルダ」から「チームリーダー」への進化です。プロジェクト全体が継続的に稼働する中央の会話に統合され、ユーザーがその会話内で目標を提示すると、Claude がコーディネーター役を務めて要件を自動で複数の並行稼働スレッド（thread）に分解します。

ここでのスレッドとは単なるバックグラウンドコマンドではなく、各スレッドの本質は独立したクラウドセッションとしての Claude Code です。それぞれが専用のコンテキストウィンドウを保持し、クラウド上の独立したサンドボックスと Git ブランチで並行してコードを記述し、テストを実行し、必要に応じて PR を作成します。そしてPCを閉じてオフラインになっても、処理はそのまま動き続けます。

Projects の主な機能：

• 1つの会話からタスクを割り振り：タスク、バグ報告、追加指示をすべて同じプロジェクト会話に投入すると、Claude がその場で回答するか、新規スレッドを立ち上げるか、あるいはすでにその領域を担当しているスレッドへ転送するかを判断します。
• 複数スレッドが並行動作し、PCを閉じても継続：各スレッドは独立したクラウドセッション（Claude Code）であり、独自のコンテキストウィンドウ、コードのコピー、ブランチを持ちます。
• 必要なときだけユーザーを呼出：Overview パネルがステータスごとにスレッドをグループ化し、判断待ちで停止したスレッドは Waiting on you に分類され、デスクトップアプリでは通知も届きます。
• 背景情報とメモリを共有：すべての新規スレッドは同一のプロジェクト指示（Project instructions）、リポジトリ、プロジェクトメモリを引き継いで開始されるため、Claude に記憶させた決定事項は以降のスレッドにも共有されます。
• PR を自律的にフォロー：スレッドが PR を作成するとそのまま監視を続け、CI が失敗したりレビュー指摘が入ったりした場合は自ら修正をプッシュし、チェックを通過してから報告します。
• スケジュール実行が可能：作業の一部をルーティン（routine）として登録し、スケジュールに基づいてプロジェクト内で自動実行させることができます。
• コード生成にとどまらない活用：コードリポジトリがなくても利用可能で、ドキュメントをアップロードしてスレッドに調査やレポート作成を行わせ、成果物を Library に格納できます。

運行メカニズム：複合メッセージはどのように複数並行スレッドに分解されるのか？

公式のリリース動画では、ある朝の業務シナリオが実演されています。ユーザーは checkout-service という名称のサービスプロジェクトにおいて、3つの要求を含む複合指示を一度に入力しました。デプロイ #4812 の後に /checkout エンドポイントの p99 レイテンシが倍増したため原因を突き止めて修正すること、金曜日のリリースノートを下書きすること、そしてついでに stripe-node（Stripe の Node.js SDK）を v15 にアップグレードすることの3点です。

プロジェクト内では、メインの会話にいる Claude がコーディネーターを務め、各スレッドの細かな手順ではなく報告される結果を把握します。Claude はメッセージの振り分けを自律的に決定します。手短でシンプルな質問は通常その会話内で直接回答し、新たな作業には新規スレッドを立ち上げるか、その領域ですでに作業しているスレッドに引き継がせます（その際、誰に転送したかも明確に伝えます）。1つのメッセージに互いに無関係な複数の事柄が含まれている場合は、独立した複数のスレッドに分解します。もしその割り振りが意図と異なる場合は、指示を出して調整させることが可能です。

デモでは、Claude がこれらを3つの独立した作業であると認識し、画面上に3枚のスレッドカードを生成して並行してタスクを割り振りました。1つ目のタスクは残り 7 コミットの範囲内で問題のあるコミットを二分探索し、2つ目のタスクは v4.11 以降にマージされた 23 件の PR を検索して変更点の要約を開始し、3つ目のタスクは 6 ファイルにおける SDK 呼び出し箇所を更新します。このとき右側の Overview パネルには、3つのスレッドが Working ステータスとして表示されます。

各スレッドが進捗している最中に別のアイデアが浮かんでも、全体を整理し直す必要はありません。例えばユーザーが30分後、メインの会話で「あ、それとリリースが月曜に変更になったので、ノートに明記しておいて」と何気なく追加の指示を出したとします。コーディネーターはこの情報がどのタスクに属するかを自動判別し、リリースノート作成スレッドへ直接転送します。該当スレッドは自身の独立セッションで転送メッセージを受け取り、その場でリリース日を月曜（9 月 22 日）に変更し、コードフリーズのリマインドを金曜にずらします。コードの調査を進めている他の2つのスレッドには一切影響を与えません。

タスク完了時の成果物の引き渡しも、それぞれの役割に応じて行われます。パフォーマンス問題を調査していたスレッドは、最終的に原因が QuoteService 内の N+1 クエリであることを突き止め、自動的にバッチクエリへと修正し、GitHub 上に新しいブランチをプッシュして PR #4821 を作成しました。メインの会話にはただちに「PR #4821 を作成済み、CI もパス」という完了報告が届きます。

スレッドが自身の判断だけでは進められない技術的な分岐点に遭遇した場合は、自動的に停止して人間の入力を待ちます。stripe-node をアップグレードするスレッドは、6 ファイルを更新した後にコントラクトテストを実行したところ、42 件のテストのうち 41 件がパスし、最後の1件がダウンストリームの webhook-lambda がまだ Node 18 で稼働しているために失敗しました（stripe-node v15 では Node 18 のサポートが終了しているため）。このスレッドは無闇に推測したりテストを回避したりせず、ステータスを Waiting on you に切り替え、Lambda ランタイムを Node 20 にアップグレードする（推奨オプション）か、stripe-node v14 に固定するかのトレードオフ案をユーザーに提示しました。

補足しておくと、スレッドはモデルが対応している場合、デフォルトで auto mode で動作し、大半のツール呼び出しはユーザーへの確認なしに実行されます。あるスレッドが本当にユーザーの承認を必要とする場合、そのプロンプトはそのスレッド内部にのみ表示され、スレッドはその中で回答が得られるまで待機し続けます。もしプロジェクト会話側で Claude に「続けて」と伝えても、その指示はスレッド内部には届きません。スレッド専用の入力欄で送信したメッセージはそのスレッドへ直接届きますが、プロジェクト会話で送信した追加メッセージは、Claude がそのスレッドに関連するものと判定した場合にのみ転送されます。公式デモでも、ユーザーは stripe-node のスレッドを直接開き、その内部の入力欄で意思決定を返信していました。

プロジェクト会話の右側にある Overview パネルでは、スレッドのステータスが以下の6つのグループに整然と分類されます：

• Ready for review：PR が作成され、レビュー待ちのスレッド。
• Waiting on you：ユーザーの返信や承認を待っているスレッド、または実行に失敗したスレッド。
• Working：現在処理を実行中のスレッド。
• Landing：PR が承認されたか、マージ待ちのキューに入っているスレッド。
• Idle：実行が完了し、何も待機していないアイドル状態のスレッド。
• Resolved：完了済みとしてマークされたスレッド（ユーザー自身による手動マーク、PR マージなどの最終ステップ完了後に Claude がマーク、または1週間アクティビティがない場合に自動マーク）。

デスクトップアプリを使用している場合、スレッドでエラーが発生した際やユーザーの入力が必要になった際、あるいは Claude がプロジェクト会話で発言した際にデスクトップ通知が表示されるため、画面を常時見守る必要はありません。Web ブラウザでは、Overview ボタンに表示されるインジケーターによって、自分を待っているスレッドの存在を確認できます。

冒頭の朝のシナリオに戻ると、4つのスレッドはこれらのグループ間を以下のように遷移していました：

公式リリース動画のコマ送り分析に基づく整理・時刻は画面上の表示時間

ある朝のシナリオ：3つのタスクはどう割り振られ、どの瞬間に人間の判断が必要になったか

プロジェクト checkout-service。各時刻の左側は会話内で起きた出来事、右側は同時刻における Overview 内の4つのスレッドの所属グループ。この時点で状態が変わったスレッドには「変化」を表示。

1. 9:12

   ユーザー · プロジェクト会話

   「デプロイ #4812 の後、/checkout の p99 が倍増した。原因を突き止めて修正してほしい。それと金曜のリリースノートの下書きを作成し、stripe-node を v15 にバンプしてくれ」

   Claude · プロジェクト会話

   3つのスレッドに分割して同時着手：「了解しました。3 つのスレッドで進めます。確認が必要な点があれば随時お知らせします。」

   • Workingp99 のデグレ修正問題のあるコミットを二分探索中、残り 7 件
   • Workingリリースノートの作成v4.11 以降にマージされた 23 件の PR を確認
   • Workingstripe-node を v15 にアップグレード6 ファイル内の SDK 呼び出しを変更
   • Idlepg ドライバを 8.13 にアップグレード以前のタスク、PR #4790 はマージ済み

2. 9:41

   ユーザー · プロジェクト会話

   「あ、それとリリースが月曜に変更になったので、ノートに明記しておいて」

   Claude · プロジェクト会話

   「リリースノートの作成」スレッドのみに転送し、同スレッドが日付を変更してスレッド内で確認。他の2つのスレッドには影響を与えない。

   • Workingp99 のデグレ修正問題のあるコミット a3f9c12 を特定：QuoteService 内の N+1 クエリ
   • Workingリリースノートの作成転送メッセージを受信：リリース日を 9月22日（月）に変更、コードフリーズのリマインドを金曜に移動
   • Workingstripe-node を v15 にアップグレード
   • Idlepg ドライバを 8.13 にアップグレード

3. 9:58

   Claude · プロジェクト会話

   p99 スレッドが完了：PR #4821 を作成済み（QuoteService の N+1 問題を再度バッチ化）、CI もパス。

   stripe-node スレッドは判断待ちで一時停止：v15 は Node 18 を非サポート、一方 webhook Lambda はまだ Node 18 で稼働しており、42 件のコントラクトテストのうち最後の 1 件で停止。

   • Resolvedp99 のデグレ修正PR #4821 作成済み · CI パス
   • Workingリリースノートの作成
   • Waiting on youstripe-node を v15 にアップグレード停止：Lambda がまだ Node 18
   • Idlepg ドライバを 8.13 にアップグレード

4. 約 10:02

   ユーザー · stripe-node スレッド自身の入力欄

   「Lambda を Node 20 にアップグレード」を選択。

   スレッドから2つの選択肢が提示されていた：Lambda をアップグレードし、infra/webhook-lambda.tf の1行を変更して再デプロイしテストを再実行する（スレッドの推奨）；または stripe-node v14 に留まり、インフラには手を加えないがメジャーバージョンが1つ遅れた状態にする。

   • Resolvedp99 のデグレ修正
   • Workingリリースノートの作成下書き完了、レビュー提出準備中
   • Workingstripe-node を v15 にアップグレードwebhook Lambda を Node 20 に移行し、コントラクトテストを再実行
   • Idlepg ドライバを 8.13 にアップグレード

5. 10:09

   Claude · プロジェクト会話

   月曜のリリースノートの準備が完了：変更点は 23 件、冒頭に 2 件の破壊的変更を記載。

   動画はここで終了し、この時点の Overview は表示されていない。

アーキテクチャの考察：これは「Claude Tag」を Claude Code に移植したものなのか？

新バージョンの Projects がリリースされた後、ある要約として「Projects は Claude Tag のアーキテクチャを Claude Code に導入し、プロジェクトごとにメモリを管理するエージェントを配備してタスクにサブエージェントを割り振ることで、プロアクティブなアクションとスケジュール実行を実現している」という見解が見られました。

構造の観点から見ると、この要約には根拠があり、両者の階層構造はほぼ一対一で対応しています：

• タスク受付とタスク実行の階層分離：Claude Tag では、Slack チャンネルごとに独自のセッションが存在してトップレベルのメッセージを処理します。調査やツール呼び出し、長期的な会話が必要なタスクに直面すると、メッセージ下の Slack スレッド内に専用の作業セッション（dedicated session）を起動します。Claude Code のプロジェクトでも同様に、プロジェクト会話内の Claude がコーディネーターとしてタスク受付を担い、実際の作業は立ち上げられた各スレッドが実行します。
• 独立したサンドボックスとライフサイクル：Claude Tag の各スレッドは独立した一時的なクラウドサンドボックス内で動作します。同一チャンネルの2つのスレッドは2つの独立したセッションであり、状態を直接共有しません。サンドボックスはスレッドが休止すると解放され、新たな返信があると再構築されます。プロジェクト内の各スレッドも同様に独立したクラウドセッションであり、それぞれの Git ブランチ上で作業を行い、対話の合間にはサンドボックスが一時停止され、再開時に復帰します。
• タスクを跨いだメモリ：Claude Tag が公開チャンネルで得た知見はワークスペース共有メモリとして保存され、プライベートチャンネルでは個別に保持されます。プロジェクト内の各スレッドも、同一のプロジェクトメモリを共有します。
• スケジュールおよびフォローアップ機構：Claude Tag はスケジュールに基づくタスク実行や、PR を追跡して変更時にアクションを起こす機能をサポートしています。プロジェクトでも同様にルーティン（routine）をサポートしており、スレッドは PR 作成後に自動でステータスを監視して修正対応を行います。

ただし、公式ドキュメントやブログでは「Claude Tag のアーキテクチャを Claude Code に持ち込んだ」という表現は採用されていません。公式ドキュメントにおける Claude Tag は、「複数人が Slack チャンネル内で一緒にタスクを振り、共同で誘導する」際により適したプロダクト形態と位置付けられています。両者の違いは下表の通りです。また、前述の要約に含まれる「メモリを管理するエージェント」「サブエージェント」「プロアクティブなアクション」という3点についても修正が必要であり、それぞれ後述の3つの小節で解説します。

最も根本的な違いは「誰のものか」にあります。Claude Tag はチーム向けであり、Slack チャンネルに常駐します（最近のアップデートでは、チャンネル全体を読んでから発言すべきかを判断するようになりました）。チャンネル内の全員が直接タスクを指示したり途中で返信して誘導したりでき、管理者が一括設定したサービスアカウントを利用します。

一方、Claude Code の新版プロジェクトは現時点では完全に個人専用です。タスクを送信したりスレッドを確認したりできるのはあなただけであり、スレッドはあなたの個人の GitHub プッシュ権限と claude.ai に連携されたコネクタを使用し、スレッドの記録を共有するオプションもありません。

メモリについて：コーディネーターは唯一の書き込み者ではない

「エージェントを1つ配備してメモリを管理する」という表現は半分しか正しくありません。プロジェクトにおいて、プロジェクトメモリ（project memory）はコーディネーターが独占して書き込むものではなく、プロジェクト会話内でも任意のスレッド内でも、Claude に対し特定の要件や決定事項、ハマりやすい落とし穴を記憶させたり忘れさせたりすることができます。あるスレッドのやり方を修正した際は、ついでにその修正内容を Claude に記憶させておくと、以降のスレッドはその知見を持った状態で作業に着手できます。さらに、Claude はコーディネーションの好みに関する要望（報告の頻度や並行数の好みなど）も自律的にプロジェクトメモリへ保存します。

プロジェクトメモリに蓄積されるのは、長期的なビジネス背景や意思決定です。例えば、リリースが金曜日に延期されたこと、なぜエクスポート機能を廃止したのか、請求サービスに手を加える前にまず誰に相談すべきか、といった内容です。

プロジェクトメモリについて、把握しておくべき点がさらに3つあります：

1. いつでも確認・メンテナンスが可能：メモリファイルは Project settings > Memory 内の Auto memory の下に一覧表示され、いつでも内容の閲覧、編集、削除が可能です。
2. ローカルメモリおよびリポジトリルールから独立：ローカルマシンの Claude Code が持つ自動メモリ（auto memory）とは別系統のストレージであり、リポジトリ内の CLAUDE.md とも分離されています。リポジトリ固有のコーディング規約は CLAUDE.md に記載し、そのプロジェクト固有のビジネス背景や意思決定ログはプロジェクトメモリに書き込みます。
3. 重要情報は確実にメモリへ書き込む必要がある：プロジェクト会話は長期間にわたって運用されるため、過去の会話履歴全体を読み込むのではなく、直近のメッセージ、直近のスレッド、およびプロジェクトメモリのみに基づいて動作します。したがって、絶対に失ってはならない情報は、必ずプロジェクトメモリに入れる必要があります。

公式ブログのデモアニメーションでは、Launch readiness というプロジェクトが月曜日から木曜日にかけて進展していく様子が紹介されています。リリース日は当初 timeline.csv に基づいて 10 月 14 日 と定められていましたが、その後 21 日、28 日 と2度にわたって延期され、変更のたびに同期更新されてメモリへ蓄積されていきました。ユーザーが「Add pricing to it」といった追加要求を出すと、コーディネーターはそれを既存の Partner email スレッドに自動的に紐付けます。数日を経るにつれて、生成された成果物（Results）や下された決定事項（Decisions）が会話の下に幾重にも積み上がっていきます。

実行主体について：スレッドは完全なクラウドセッションであり、軽量なサブエージェントではない

タスクの実行者を「サブエージェント」と呼ぶと、機能面での混同を招きやすくなります。Claude Code の現行アーキテクチャにおいて、subagents（サブエージェント）と呼ばれる機能は、同一セッション内部で派生して特定の補助タスクを自身のコンテキストで実行し、メインセッションに要約を返す委任ワーカーを指します。

一方、プロジェクト内で立ち上がるスレッドは、それぞれが完全な機能を備えた独立したクラウドセッション（cloud session）です。各スレッドは独自のコードコピーと独自のコンテキストウィンドウを持ちます。大規模なタスクに対応する必要がある場合、各スレッド自身が必要に応じて内部でサブエージェント、ループ実行機構（loops）、ワークフロー（workflows）を呼び出して工程を分割し、大規模な作業をより迅速に完了させることができます。

プロアクティブなアクションについて：トリガー条件と厳格な境界

ユーザーが感じる「プロアクティブなアクション」、すなわち自発的な行動には、公式設計において明確なトリガー条件と実行境界が存在します：

• 初回プロジェクトの初期探索：最初のプロジェクトを作成した後、ユーザーが先にメッセージを送信しなければ、Claude が自発的に1巡目の処理を行います。プロジェクト内に読み取り可能なリポジトリがある場合は、変更を加えない読み取り専用の探索スレッドを立ち上げて現状を確認した上で次のステップを提案したり、直近のクラウドセッションに基づいてセットアップ推奨事項（Setup recommendations）を提示し、追加を推奨するリポジトリや作成を推奨するルーティン、自身が立ち上げ可能なスレッドをリストアップしたりします。この初回探索もプランの利用枠を消費します。
• ルーティン（Routines）：作業の一部をスケジュールに組み込んでルーティン（routine）とすることができます。これはプロジェクト内でスレッドの形式で実行され、Routines タブに表示されます。なお、プロジェクト外で個別に作成されたルーティンは、従来どおり独立して実行されます。
• ブランチ監視と自己修復：スレッドが PR を作成すると、他のクラウドセッションで auto-fix（自動修復）が有効になっているかどうかにかかわらず、その PR を自発的に監視し続けます。CI ビルドが失敗したりリポジトリにレビュー修正の指摘が入ったりすると、スレッドは自動的に起床して修正コミットをプッシュし、チェックを通過して PR のレビュー準備が整った段階でユーザーに報告します。

その自律性を理解する上では、以下の安全性およびコストに関するルールに注意する必要があります：

• 並行スレッド数に固定の上限はない：システムはタスクの必要性に応じて適切な数のスレッドを立ち上げます。会話内で「同時に動かすのは最大2つまでにして」と指示しても、それは調整上の好みにすぎず、システムの厳格なハードリミットではありません。並行数の制限を正確に記述し、最初からすべてのスレッドに適用させたい場合は、プロジェクト指示に明記する必要があります。唯一の厳格な数量制限は、すべてのプロジェクトを合算して 1 日あたり新規 200 個のスレッドまでという制限です。
• 承認ルールはリポジトリ内に記述する：前述の通り、ユーザーの承認を求めるプロンプトはスレッド内部にのみ表示されます。すべてのスレッドに対して特定のコマンドを確認なしで許可したい、あるいは特定のコマンドを一律で禁止したい場合は、リポジトリの .claude/settings.json に権限ルールを記述する必要があり、これは単一リポジトリのプロジェクトでのみ有効です。
• クォータ上限到達時は自動リトライされ、次周期のウィンドウを消費する：スレッドやプロジェクト会話が5時間または週単位の利用上限に達した場合、システムは自動リトライを継続し、クォータが回復すると処理を再開します。これはユーザーが何の発言もしなくても、次の周期の利用枠ウィンドウを直接消費することを意味します。新しいウィンドウが自動消費されるのを防ぎたい場合は、スレッド内で Stop をクリックするか、プロジェクト全体を直接一時停止（Pause）する必要があります。（ルーティンによって起動されたスレッドは例外で、利用制限に達すると待機リトライせず即座にエラー停止します。）

横断比較：Claude Code における5つの並行モードをどう選ぶべきか？

1週間前に Cursor も同名の Projects をリリースし、こちらもコーディネーターがクラウド上で計画を立て、複数のエージェントにタスクを割り振る形態を採っています。Claude Code 自身に立ち戻ると、現在複数のタスクを同時に実行する方法は合計5つ存在します。

多くの開発者がこれらの概念で混乱しがちです。その核心的な違いは、「誰がタスクのスケジューリングを行うのか」、そして「コードがローカルとクラウドのどちらで動作するのか」という2点に集約されます：

留意すべき点として、複数のセッションやサブエージェントを同時に動作させると、トークン消費量は倍増します。

Claude Code のセッション間メッセージングを使えば、自身で立ち上げた複数のセッション間で発見や状態をやり取りできますが、どのセッションを立ち上げ、誰に何をさせ、いつ完了とするかは、依然として人間自身が管理する必要があります。新版プロジェクトの変化は、「セッションの立ち上げ、タスクの割り当て、進捗の追跡」という煩雑なスケジューリング作業を、プロジェクト会話内の Claude に完全に委ねられるようになった点にあります。

プロジェクトが適しているのは、単一セッションよりも目標期間が長く、次々と新しいタスクが発生する長期的な作業です。例えば複数リポジトリにまたがる目標、継続的にバグが投入されるサービス、単一セッションの枠を超える大規模な開発や移行、あるいはコードを書かない純粋なドキュメント作成作業（リポジトリの代わりにファイルを直接アップロードすると、スレッドが整理した成果物を Library タブに格納します）などです。一方、以下の4つのケースでは、他の方式を採用する方が適しています：

• 1つのセッションで完了できる単一タスク（例：不安定なログインテストの修正）：自身でクラウドセッションを1つ立ち上げるだけで十分です。
• ローカルマシンからしかアクセスできないツールやサービスが必要な場合（例：ローカルデータベース、デバイスシミュレータ、VPN 背後のエンドポイント）：ローカルセッションを使用するか、Agent 画面（agent view）で複数同時に実行します。ローカルファイルのみが必要な作業であれば、プロジェクトに直接アップロードすれば対応可能です。
• 決まった時間に繰り返され、対話を必要としないタスク（例：毎週月曜日に依存関係レポートを発行する）：個別のルーティン（routine）を単独で作成します。
• 複数人で Slack チャンネルから Claude にタスクを振り、一緒に誘導する場合：Claude Tag を使用します。

利用量：デフォルトはすべて Opus で、単一セッションより消費が早い

新プロジェクトのデフォルト設定では、プロジェクト会話およびすべてのスレッドがデフォルトで Opus モデルを使用します。その際、スレッドはデフォルトで高い思考強度（High effort）が有効になっており、コーディネーター会話は低い思考強度に設定されています。

プロジェクトは他の Claude Code セッションと同じプラン枠を消費しますが、消費速度は格段に上がります。稼働中の各スレッドはそれぞれ完全なセッションであり、複数を同時に動かせば同時にクォータを消費します。プロジェクト会話自身も、スレッドの報告を読み取り次のステップを判断するためにトークンを消費します。さらに、アイドル状態でありながら PR を監視しているスレッドは、CI の失敗や新たなレビュー指摘を受けると再び起動され、追加でクォータを消費します。そのため、Pro サブスクリプションのユーザーは、プロジェクトを動かす日はプランの上限により早く達することを想定しておく必要があります。ただし、プロジェクト内で稼働中のスレッドがなく、監視対象の PR もなく、新たなメッセージもない場合、プロジェクトがアイドル状態の間はクォータを消費しません。アーカイブされたプロジェクトも消費を発生させません。

プロジェクトの消費量を抑制・管理したい場合は、以下のアプローチが有効です：

• Project settings > Usage で、スレッド別・モデル別のトークン消費量や、プロジェクト会話自身の消費状況を確認する。
• キャッシュ有効期限（Pro および Max プランのクォータ内では 1 時間）を超えてアイドル状態にあった古いスレッドに追加のメッセージを送信すると、処理前に会話全体を再度読み直すことになります。そのため、新しいタスクについては、肥大化した古いスレッドを再起動するよりも、Claude に全く新しいスレッドを立ち上げさせる方がトークンの節約につながることが多いです。
• 一般設定（General）で、スレッドやプロジェクト会話のモデルを小さめのものに変更するか、思考強度（effort）を引き下げる。
• プロジェクト会話で Claude が立ち上げるスレッド数を抑えるよう指示するか、ちょっとした質問にはその場で直接回答させ、安易に新しいスレッドを立ち上げないようにする。

着手前に整えておくべき3つの準備

長期的な作業をプロジェクトに委ねる前に、GitHub の権限、スレッドが使用可能なツール、複数リポジトリ運用時のルールという3つのポイントで最も詰まりやすくなります。

GitHub：Claude GitHub App の導入が必須

ターミナルで Claude Code を実行する際、開発者はよく /web-setup を介してターミナルから GitHub に接続し、トークンを取得します。そのトークンがあれば他のクラウドセッションからコードベースにアクセスできますが、プロジェクトのスレッドが利用するには不十分です。プロジェクト内のスレッドは完全にクラウド上で動作するため、対象リポジトリに公式の Claude GitHub App がインストールされている必要があり、かつユーザーの GitHub アカウントがリポジトリに対する push 権限を持っている必要があります。リポジトリが SAML SSO を有効化している組織に属している場合は、組織レベルのシングルサインオン認可も明示的に完了していなければなりません。リポジトリに Claude GitHub App がインストールされていない場合、スレッドは起動前にエラーとなり、立ち上げることすらできません。

ローカル環境のツールはスレッドに一切引き継がれない

スレッドはクラウド上のクリーンな環境で動作するため、ローカルの Claude Code にインストールされているスキル、MCP サーバー、プラグイン、ツール類は一切引き継がれません。タスクで特定のツールや拡張機能が必要な場合は、以下の方法で補う必要があります：

• スキル、サブエージェント、カスタムコマンド：プロジェクトに関連付けられたコードリポジトリにコミットします（例：.claude/skills/、.claude/agents/、.claude/commands/）。スレッド起動時のクローン処理で自動的に読み込まれます。また、ユーザーの claude.ai アカウントで有効化されているスキルも自動で読み込まれます。
• プラグイン（Plugins）：Project settings > Plugins で追加します。新規スレッドが起動するたびに読み込まれます。
• MCP サーバー：スレッドは claude.ai アカウントに連携されたコネクタ（connectors）を通じて MCP ツールを取得します。すべてのスレッドでそのまま利用可能であり、プロジェクトごとに再設定する必要はありません。ただし特に注意が必要な点として、プロジェクト会話自体はいかなるコネクタも保持していないため、コネクタを必要とする作業はスレッドへタスクとして割り当てて実行させる必要があります。
• コマンドラインツールとパッケージ：クラウド環境のセットアップスクリプト（setup script）内でインストールします。
• 社内ネットワークアクセスと環境変数：社内 API やプライベートパッケージリポジトリへのアクセスが必要な場合、あるいは API 認証情報が必要な場合は、クラウド環境（Environment）でネットワークアクセスのドメインホワイトリスト、環境変数、API 認証情報を設定します。

複数リポジトリ：リポジトリ内の権限ルールや hooks は無効化される

プロジェクトは複数のコードリポジトリの関連付けをサポートしていますが、単一リポジトリと複数リポジトリとでは、リポジトリ内設定の適用ルールが異なります。

複数のリポジトリを関連付けた場合、各リポジトリの CLAUDE.md、.claude/ 以下のスキル、サブエージェント、コマンド、および各リポジトリの settings.json で有効化されているプラグインは通常通り読み込まれます。あるプラグインに関して2つのリポジトリで設定が競合する場合は、Project settings > Plugins での設定が優先されます。

無効になるのは、各リポジトリの settings.json で定義された権限ルール（permission rules）、hooks、および env 環境変数です。複数リポジトリの場合は一律で適用されず、有効化されたプラグインに付属する hooks のみが実行されます。その理由は、複数リポジトリ環境では、スレッドがすべてのリポジトリのクローン先ディレクトリの親階層から起動するため、いずれのリポジトリの当該ファイルも読み込まないからです。

したがって、複数リポジトリのプロジェクトでは、共通の規約はプロジェクト指示（Project instructions）に記載し、環境変数はクラウド環境側で設定する必要があります。なお、Project settings で変更した指示、リポジトリ、プラグイン、環境は、新しく立ち上げられるスレッドにのみ適用され、すでに実行中のスレッドには影響しません。

現時点におけるその他の制限

• 利用窓口とプラットフォームの制限：claude.ai/code の Web 版、デスクトップアプリ、および Claude モバイルアプリでのみ利用可能です。ターミナル CLI は現時点で未対応であり（CLI 内の claude project コマンドはローカルディレクトリの状態管理用であり、本機能とは全く無関係です）、Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry などのサードパーティプラットフォーム経由でも利用できません。
• クラウド実行限定：ローカルセッションをプロジェクトに参加させることはできず、スレッドはクラウド上でのみ動作します。公式によれば、ローカルワークフローへの対応も「まもなく」提供予定とされています。
• 個人専有および所属の固定：プロジェクトは作成した個人ユーザーのみに帰属し、他者との共有はできません。スレッドのログにも共有オプションはなく、ベータ期間中は組織レベルのガバナンス機能もありません。また、スレッドはそれを起動したプロジェクトに厳格に帰属し、プロジェクト間で移動やコピーを行うことはできません。
• コミットされていない変更が失われるリスク：スレッドのサンドボックスは対話の合間に一時停止され、再開時に復帰します。万が一復帰できなかった場合、スレッドは新規のクローンから作業を引き継ぐため、未コミットの変更は失われます。長時間のタスクでは、段階的にコミットしてリモートブランチへプッシュするよう指示に含めておく必要があります。

まとめ：最初の長期プロジェクトをどう始めるか？

新版プロジェクトではセッションの立ち上げ、タスクの割り振りと追跡がコーディネーターに委ねられたため、人間が注力すべきポイントは「ルールを明確に記述できているか」「環境を適切に整えられているか」「納品された成果物をどう検証するか」へと移行しました。

新しいプロジェクトへ本格的にまとまったタスクを投入する前に、公式ガイドに沿って初期設定と検証を行っておくことを推奨します：

1. プロジェクト指示（Project instructions）の作成：最大 16,000 文字の指示スペースを活用し、各新規スレッド向けのキックオフブリーフィングとして整備します。どのコードベースとブランチで作業を行うか、PR の命名規則、スレッドが作業完了前に自身でどう検証するか（例：make test や make lint を実行し、最終報告にサマリーを添付するなど）、依存関係や認証情報の不足時に勝手な推測やモックの作成を行わないこと、スレッド内で事前にユーザーの許可を得なければならない操作はどれか、などを明確に記述します。単一リポジトリ固有のルールについては、リポジトリの CLAUDE.md に記載します。
2. 小規模なタスクでテスト実行し結果を確認する：まずは小規模な実際の作業を投入するか、Claude が提案する推奨スレッドをクリックして起動してみます。完了後、スレッドを開いてどのように報告がなされ、ブランチ上で具体的にどんな変更が行われたかを確認します。誤った前提を置いていたりアクセス権限が不足していたりした場合は、速やかに指示や環境設定へ戻って修正します。
3. スレッドのモデルと思考強度を確認する：Project settings > General を開き、Thread model と Thread effort を確認します。新しいプロジェクトではデフォルトですべてのスレッドが Opus モデルの高い思考強度（High effort）で稼働するため、プランの枠を最も速く消費します。タスクの複雑度に応じて、小さめのモデルに変更するか思考強度を引き下げます。
4. 最初は制約を設けてすり合わせ、期待通りに動いたら緩和する：プロジェクト会話において、まずはスレッドの提案（propose threads）を行わせ、人間が確認して承認してから起動するように指示し、同時に稼働させるスレッド数も制限しておきます。何回か回してみて、タスクの分解や報告のスタイルが期待に完全に沿っていることを確認できてから、これらの制約を解除します。

誰が今すぐ利用できるのか

• 現在：パブリックベータとして、クラウドセッションの利用経験があり、かつ claude.ai のチャットや Cowork 内に旧版プロジェクトを持っていない Pro および Max ユーザー向けに先行展開されています。
• 少し後：旧版プロジェクトを利用したことのあるユーザーへは、旧プロジェクトからのスムーズな移行を考慮して少し遅れて展開されます。
• 今後1週間：さらに多くの Pro および Max の Claude Code ユーザーへと拡大され、その後に Claude 全体、ならびに Team および Enterprise プランへと展開される予定です。
• 自身のアカウントに届いているかの確認方法：claude.ai/code のサイドバーやデスクトップアプリの Code タブに Projects が表示されていない場合は、まだアカウントに届いていません。ウェイトリストに登録して待つことができます。
• 利用場所：Web（claude.ai/code）、デスクトップアプリ、ならびに iOS / Android の Claude モバイルアプリ。
• 旧プロジェクトの扱い：引き続き利用可能であり、新しい体験がチャットや Cowork へ拡大されるタイミングで一括アップグレードされる予定です。