Claude CodeのProjectsは今使うべき？ 対象条件と、並列スレッドの分け方
ミオ｜AI大好きな後輩
【重複購入のご注意】この記事は「ミオ｜AI大好きな後輩」がnoteで販売している同名記事（Claude CodeのProjectsは今使うべき？ 対象条件と、並列スレッドの分け方）と同じ内容です。すでにnoteで購入・閲覧できる方は重複購入にご注意ください。
Claude CodeのProjectsが作り直され、1つのプロジェクトが1つの会話になりました（2026-09-17付の公式ブログ。Xの告知は日本時間9-18未明、本稿は10-5に原文を確認し直しています）。Claudeが作業をスレッドへ分け、並列に走らせます。スレッドは通常、独立したブランチとリポジトリのコピーを持つクラウドセッションです（手元のコンピュータで動かす場合は下の「対象と、向かない人」で扱います）。複数リポジトリの例では、リポジトリごとにスレッドが作られ、移行・テスト・PR作成まで進み、マージの順序もClaudeが教えます。公式ブログ / 公式発表 / 公式ドキュメント
プロジェクトからスレッドへ分かれて並列に走る流れ（クラウドで動くスレッドの場合）。図の「衝突」は、変更が重なった場合にマージ時に現れるという意味で、同じコードを触れば必ず起きるという意味ではありません
製品が見るところと、見ないところ。 公式ドキュメントは、新しい作業は新しいスレッドか、その領域ですでに作業中のスレッドへ渡されると書いています。一方で公式ブログは、同じコードを触るスレッドがあれば重複は通常のPRと同じマージ衝突として解決されると書いています。手元で動かすスレッドについては、2つのスレッドが同じフォルダで同時に作業すると互いの変更を上書きしうる、と公式ドキュメントにあります。スレッドのカードには衝突の解消をそのスレッドへ指示するボタン（Resolve conflicts）がありますが、重なったときにどちらの変更を正とするかの判断は残る——これが筆者の読みです。公式ドキュメント
本稿の立場：筆者は、公式ブログとXの告知を9-20と10-5に、公式ドキュメントの全文を9-20と10-5に取得し、9-27時点の記述は該当箇所の引用で見て、版ごとの記述を突き合わせています。手元でスレッドを動かす節は、9-20の公式ドキュメントには無く、9-27時点の記述にはあります。有料部の4つの問い・6つの状態の判定・記入シートは、これらの記述から筆者が組み立てた設計提案です。筋が通っているかは下の例で確かめてください。
対象と、向かない人：ベータは、クラウドセッションをすでにPro/Maxで使っていて、claude.ai のチャットまたは Cowork に既存のプロジェクトを持っていない一部の利用者から始まりました。Team・Enterpriseにはまだ提供されていません。スレッドは通常クラウドで動きますが、ローカルのデータベースやVPN内のAPIのように手元のコンピュータにしかないものが要るタスクは、Remote Control を通じてそのスレッドだけ手元で動かせます。手元のコンピュータには Claude Code v2.1.280 以降が要り、そのスレッドはコンピュータが起きている間だけ動きます。アカウントで Require trusted devices を有効にしていると、手元では動かせません。9-17付の公式ブログは10-5時点でも手元での実行を「近日提供」と書いていますが、公式ドキュメントは手順まで載せています（公式ドキュメント / 提供範囲）。次のどれかに当てはまるなら役に立ちません——Pro/Maxでクラウドセッションを使っていない、Team・Enterpriseである、すべてのタスクが手元のマシンを必要とする（一部のタスクだけなら対象です）、独立して進められる作業が複数ない。 提供は段階的に広がるので、可否は自分の画面で確認してください。公式ブログは、並列で走る分だけ使用量の上限に届くのが速くなりうるとも注意しています。
対象に入っている人に必要なのは、投げる前にスレッドの境界を決めておくことです。
例：非推奨のv1 APIを廃止し、webとmobileの呼び出しをv2へ移す
- 並列にする判断：3つとも触る箇所が別リポジトリで重なりません。apiが削除するコードは既にリポジトリにあり、待つのはweb・mobileが終わったことだけです。実装は3つとも並列で進められます
- 適用を待つ判断：v1削除を適用するのは、web・mobileがマージされて配置・配布され、旧版からのv1アクセスが観測期間中ゼロになった後です
「並列にするか」と「適用を待つか」は別の判断です。 混ぜると、書けるコードを書かずに待つことになります。
自分の作業がどの判定に落ちるかは、どう決めるのか。有料部で渡すのは、投げる前に埋める記入シートです。上の例のapi（v1削除）なら、こう埋まります——実行場所＝クラウド／問い1（重なる編集予定のファイル）＝無し／問い2＝当たる。ただし2bで、待つ条件はwebのマージと配置、mobileのマージと配布、旧版アクセスの観測ゼロ／問い3（予定外に触る共有設定）＝無し／判定＝実装は並列・マージと適用の順序だけ直列。残る欄は、ゴール、つなぐリポジトリ、候補ごとの編集予定パス、波の割り当て、並列度の初期値と増減条件、完了の判定条件、停止時の扱いです。判定は分ける・実装は並列でマージと適用の順序だけ直列・分けないの3つで、6つの状態それぞれの判定と理由、並列度の決め方と記録する6欄、手元のマシンで動かすスレッドの扱い（作業ツリーを分ける Worktree の有無、PRを開かせる指示の置き場所）、決めた境界を指示で守らせる書き方、記入例2件（上のapiの形と、問い1で分けないに落ちた形）を付けます。自分の作業がどの判定に落ちるかは、このシートを上から埋めれば決まります。
この記事の販売者
