もし10個のスレッドを開いて、アカウントの1日の利用枠の上限にぶつかった場合、その10個のスレッド内で既に動いていた作業は中断されたり、データが失われたりするのか?
失われることはない。公式の説明によれば、枠の制限によって一時停止したスレッドは待機状態に入るのであって、終了させられたり消去されたりするわけではない——ファイル、ツールの状態、会話履歴はすべて保持され、枠が回復した後(翌日のリセットであれ、自分でプランを調整した場合であれ)、そのスレッドは一時停止した箇所から自動的に再開し、改めて開き直す必要はない。
つまり200の上限にぶつかることが実際にもたらす影響は時間的な遅延であり、作業成果の損失ではない。より実務的に影響を受けるのは、むしろ「今日得られると想定していた結果が、枠が回復するまで先延ばしになる」という時間のずれだ。もしタスクに明確な時間的プレッシャー(今日中に必ず何らかの成果を提出しなければならないなど)がある場合、この遅延自体が計画に織り込むべきリスクであり、「データが失われない」というだけで完全に安心すべきではない。
なぜレビュー負担の複雑さは、スレッド数に単純に比例して直線的に増えるのではなく、「二乗に近い形」で増えるのか?
もし各スレッドが完全に独立していて、互いに無関係であれば、レビューの負担は確かに直線的になるはずだ——最初のdiffを見終えるのにかかる時間は、2番目もだいたい同じくらいで、合計時間は1件あたりの時間にスレッド数を掛けたものになる。しかし実際にはたいていそうはならない。もし複数のスレッドが同じ大きな目標から分割されたサブタスクであれば、それらの間には暗黙の関連性がある可能性が高い——例えば2つのスレッドが同じ共通ロジックに触れていたり、あるスレッドの前提が、別のスレッドの変更によってちょうど覆されてしまったりすることがある。
この場合、それぞれのdiffを個別にレビューして終わりというわけにはいかず、「これらの変更をまとめたときに、互いに矛盾しないか」を確認するために追加の時間を費やす必要がある。この照合作業は、理論上スレッドのすべてのペアについて一度ずつ確認する必要があり、スレッド数が増えるにつれて、ペアの組み合わせの数はスレッド数自体よりも速く増えていく。これこそが、複雑さが単純な直線的増加ではなく二乗に近い形で増える理由だ。
もしサブスクリプションプランの枠が十分にあり、200の上限にもまだ近づいていない場合、安心して一度に多くのスレッドを開いても大丈夫ということなのか?
完全にそうとは言えない——枠が十分にあるということは、「技術的には」多くのスレッドを同時に走らせることができるというだけであって、そうすることが実際のワークフローにとって最善の選択であるとは限らない。枠は比較的客観的で数値化できる制限だが、レビューの負担は別の次元の制限であり、両者は互いに相殺されない。たとえ使い切れないほどの枠があったとしても、実際に丁寧にレビューできるdiffの数は、自分が毎日レビューに費やせる時間と集中力によって制限される。
より実践的な判断方法は、「枠は十分か」と「自分はレビューしきれるか」を2つの独立した問いとして、それぞれに答えを出すことだ。両方の答えが肯定的である場合にのみ、一度に多くのスレッドを開く価値がある。もし枠は十分だがレビューが追いつかない場合、通常の結果は複数の変更が誰にも丁寧に確認されないまま積み重なってしまうことであり、これはむしろ「ある問題がメインラインにマージされたが気づかれなかった」というリスクを高めてしまう。このリスクは、枠に余裕があるからといって自動的に消えるわけではない。
実務上、あるタスクが複数の並行スレッドに分割するのに適しているかどうかを判断する具体的な方法はあるか?
比較的実用的な判断基準は、まずそのタスク自体が「互いに独立していて、変更範囲が重複しない」複数のサブタスクに分割できるかを見ることだ。Anthropic自身の例——API、ウェブ、モバイルという3つの別々のリポジトリで、それぞれ同じ非推奨のエンドポイントを退役させる——は、分割に適した良い例だ。3つのリポジトリ自体が独立しているため、スレッド同士は本質的に互いに干渉せず、レビューも各リポジトリの変更がそれぞれ正しいかを確認するだけでよく、互いの矛盾を照合する必要がない。
逆に、タスクの性質が「同じリポジトリ内の同じ中核ロジックに対して、いくつかの異なる最適化を試みる」といったものであれば、表面的には複数のスレッドに分割できるように見えても、実際には変更範囲が大きく重複するため、レビュー時にはむしろどのバージョンがより良いか、互いに矛盾する点がないかを比較するのに多くの労力を費やすことになる。この種のタスクは通常、一度に並行して展開するのではなく、順を追って一度に1つのスレッドで処理する方が適している。「スレッドを多く開けば開くほど速い」という考えを盲目的に追い求めることは、むしろ全体の進捗を遅らせる可能性がある。
Claude Code Projectsが再設計された形でリリースされて以来、Anthropicは明確なハードリミットを設定している。1アカウントあたり1日最大200の新しいスレッドまで、すべてのプロジェクトを合算してだ。多くの報道がこの数字に言及しているが、通常はついでに触れる程度で、それ以上の議論はされていない——この上限が実際にはどう理解すべきものなのか、どんな状況でこの数字自体に到達する前に別のボトルネックに先にぶつかるのか、という点だ。
この上限は「アカウントごと、1日ごと、すべてのプロジェクトを合算」で計算されるものであり、「プロジェクトごとにそれぞれ200」ではない。もし複数のプロジェクトを同時に走らせている場合、スレッド数は同じ枠を共有する——つまり3つのプロジェクトすべてでスレッドを頻繁に使っている場合、1つのプロジェクトだけを走らせている場合よりも枠が早く尽きてしまい、複数のプロジェクトの間で自分で優先順位をつける必要がある。各プロジェクトが独立して200枠を持っているわけではない。
公式の説明によれば、利用制限に達して一時停止したスレッドは、直接失敗したり消えたりするのではなく、待機し、その後自動的に再開する——つまりこの200という数字が実際に引き起こすのは「遅延」であって「作業の消失」ではない。実務上、あなたの利用パターンが1日のうちに集中して多くのスレッドを開くものであれば、この上限に先にぶつかる可能性が高い。利用が数日に分散していて、毎日いくつか開く程度であれば、通常この線に実際にぶつかることは少ない。
200はアカウントレベルのハードリミットだが、実務上ほとんどの人はもっと早く別の制限にぶつかる——自分のProまたはMaxプラン自体の利用枠だ。すべてのスレッドは完全なClaude Codeクラウドセッションであるため、通常1つのセッションを開くのと同じペースで枠を消費し、プロジェクト配下のスレッドだからといって安くなるわけではない。つまり同時に10個のスレッドを開いて並行実行すれば、独立した10個のセッションを同時に開くのとほぼ同じ枠を消費することになる。ほとんどのサブスクリプションプランにとって、この消費ペースは200の上限よりもずっと早く実感させられるものであり、200はむしろ理論上の上限であって、ほとんどの人が実際にぶつかる最初の壁ではない。
枠よりもさらに見落とされやすいボトルネックは、「レビュー」というプロセス自体にかかる人的コストだ。以前は1つのスレッドの結果だけを見ればよかった。今、5個、10個の並行スレッドを同時に開いた場合、確認する必要があるのは5件、10件のそれぞれ独立したdiff、それぞれの実行ロジック、それぞれに存在しうる問題だ。しかも各スレッドはそれぞれの前提に基づいて独立して作業するため、タスクの分割が十分に明確でなければ、重複した、あるいは矛盾した前提に基づいて作られた複数の結果を受け取ることになりかねない。レビューの複雑さはスレッド数に比例して直線的に増えるのではなく、二乗に近い形で増える。なぜならこれらの結果同士に矛盾がないかも照合しなければならないからだ。
より実践的な判断方法は、残りの枠がどれくらいか、あるいは200の上限までどれだけ余裕があるかを見ることではなく、まず自分に問いかけることだ。もしこれらのスレッドが同時に結果を報告してきたら、自分にはそれを一つひとつ丁寧にレビューする時間と気力があるだろうか、と。もし答えがノーであれば、たとえ枠に十分な余裕があり、200の上限にはまだ遠くても、並行スレッドを開きすぎること自体が、自分がさばききれないレビューの積み残しを生み出してしまう——実際の効果は、むしろスレッド数を少なくして一つひとつを真剣にレビューするやり方よりも悪くなる。