minorrunaway-loopunverifiedcollected
/code-reviewが10体に分かれ、5時間分の上限を4分で使い切った（未検証の報告）
push前に自動で走るClaude Codeの `/code-review` が、1体ではなく10体のサブエージェントを同時に立ち上げた。1回目は5時間の利用上限を8分で、2回目は4分で使い切り、10体とも途中で止まった。
原因
筆者によれば、同じ日に3つの変更が重なった。モデルがOpus 5からOpus 5.5へ、effortがhighからmaxへ、デスクトップアプリが2.1.275から2.1.280へ上がった。任せる判断がうまくなったモデルと、広がったレビューの範囲に、同時実行20体という既定の上限が重なって、一気に分かれたとみている。どれが引き金だったかは切り分けていない。
結果
2回で26体が立ち上がり、うち16体は終わる前に止まった。新しいモデルが出て3日で、その週の上限を使い切った。筆者の見積もりでは、API料金に換算して1回あたり約31ドル分で、Proプランの範囲に収まった。会話全体の利用のうち約40%がサブエージェントだった。
対策
筆者は複数体でのレビューをやめ、正しさだけを見る1体のサブエージェントに置き換えた。この1体は、実際のバグを2件見つけた。同時実行数の上限を下げる、自動で呼ばれないようにする、effortを下げる、はまだ試していない。モデル・effort・アプリの版は一度に1つずつ変え、並列数には必要になる前に上限をかけておく。
何が起きたか
筆者はプログラマーではない小さな会社の経営者で、Claude Codeに、push の前に
毎回 /code-review を自動で走らせていた。2026年9月23日、そのレビューが
突然、いつもの1体ではなく10体のサブエージェントを同時に立ち上げた。
8分後には、5時間分の利用上限がなくなっていた。
現場の混乱
次の回はもっとひどかった。上限は4分で尽き、10体とも途中で止まって、 使える結果は何も残らなかった。2回で26体が立ち上がり、16体が途中で 打ち切られた。新しいモデルが出て3日で、その週の上限はもう使い切っていた。 筆者が気づいたのは、上限の減り方がいつもより速かったからで、その後 Claude自身に会話の記録を読ませて、本当に並列で動いていたことを確かめた。
原因
その日は3つが同時に変わっていた。モデル（Opus 5からOpus 5.5）、effortの 設定（highからmax）、アプリの版である。筆者の見立てでは、新しいモデルは 仕事を分けて任せる判断をしやすく、max の effort はレビューの対象を広げ、 既定では20体まで同時に動かせるので、止めるものがなかった。3つが一緒に 変わったため、どれが決め手だったかは分からない。
対策
筆者は複数体でのレビューをやめ、正しさだけを見る1体のレビュー用 サブエージェントを書いた。見るのは、1行ずつの読み込み、動作の変化、 ファイルをまたいだ追跡、言語特有の落とし穴、値の扱いの5つ。範囲を 絞ったこのレビューは、元のコードが見落としていた本物のバグを2件 見つけた。同時実行数の上限を下げる、自動のレビューを止める、effortを 下げる、は試していない。
エージェントを自動化する人にとっては、二つの習慣がこの損失を小さく できた。モデル・effort・版は一度に1つずつ変え、急な変化の原因が 見えるようにすること。そして、賢くなったモデルが使える余地をすべて 使い切る前に、並列で動くエージェントの数に低い上限をかけておくこと。