Claude Codeがうまくいかない時の型｜2回失敗で1段上げる運用規約

同じタスクで失敗が続いたとき、次に何を上げるか——モデルか、考える深さか、それとも指示か。この判断を毎回その場の勘で下すと、対応がぶれて原因も残らない。結論から言えば、失敗時の対応は都度判断にせず規約にするのがよい。筆者は「同一タスクで2回失敗したら effort、次にモデルの順に1段上げる」と定め、成果物に書いている。本稿はその規約の中身と、手戻りを既定表へ還元する運用を実物で整理する。

エスカレーション規約の中身

筆者の配分計画は、運用規則の節にこう書いている。

エスカレーション: 同一タスク2回失敗で effort → モデルの順に1段上げる。常態化したら本表を更新

肝は「2回」である。1回の失敗では動かさない。LLM の出力には毎回わずかな揺らぎがあり、一度の失敗はたまたま外しただけかもしれない。同じ指示で二度続けて失敗して初めて、それは偶然の揺らぎではなく構造的な不足——effort かモデルが足りていない——と見なせる。1回で上げれば揺らぎに振り回され、上げすぎたコストが常態化する。

規約は昇格だけではない。降格も同じ表に書く。デバッグの行には、原因不明のうちは opus・xhigh に振り、「原因特定後の修正は sonnet ＋ medium へ降格」と明記してある。高い推論を「原因特定」という影響度の高い局面にだけ集中させ、確定後の修正には振らない。上げる規約と下げる規約が対になって初めて、配分は締まる。

規約はコマンドに埋め込む形でも運用している。公開ツール「国会議事録 AI要約」の実装コマンドには、テスト失敗時に同じエージェントへ修正を委譲する手順があり、その回数を「最大2回まで。それ以上はユーザーに報告」と定めている。上限に達したら人間へエスカレーションする、という最終段まで規約に含める考え方である。

effort が先、モデルが後の理由

なぜ effort が先でモデルが後なのか。これはモデルと effort を独立した2軸で設計する話と地続きである。出力が浅い・詰めが甘い・考慮漏れが多いなら、足りないのは考える量で、同じモデルのまま effort を上げれば済む。一方、前提を取り違える・設計を誤る・込み入った依存を追い切れないなら、能力の上限に達しているのでモデルを上げるしかない。多くの失敗はまず前者を疑うのが妥当で、順序を effort → モデルに固定しておくと、失敗のたびに「どちらを上げるか」で迷わなくなる。切替コストにも差がある。effort はセッション内の一操作で戻せるが、モデル切替は文脈の載せ替えに近く、しかも effort 非対応の haiku を経由して切り替えると effort 設定が消える——モデル切替後は effort を確認せよ、という注意も実物の計画に書いてある。安く戻せる方から試すのが理にかなっている。

手戻りを既定表に還元する

規約の末尾「常態化したら本表を更新」が、この運用のかなめである。同じ箇所で毎回昇格しているなら、それはもう偶発ではなく、既定の配分が間違っている合図だ。そのときは昇格を繰り返すのをやめ、既定表そのものを書き換える。判断の結果を表へ還元するために、計画には変更履歴表を持たせている。

| 日付 | 変更 | 理由（実績データ） |
| 2026-07-13 | v1 初版（writer を opus 固定） | AdSense 不承認理由がコンテンツ品質のため |
# … 以降の変更行が続く（2列目=変更内容、3列目=それを裏づける実績）

理由の列に「実績データ」と明示してあるのがポイントで、変更の根拠を実績に縛る。さらに、波及しやすいタスクには昇格条件を事前に書き込んでおく運用もある。CMS を自作している未公開プロジェクトの表には、特定タスクに「手戻り2回で opus 昇格」と印を付けてあり、セッションログビューワのプロジェクトにも「詰まったら opus + xhigh へ昇格」の事前指定がある。規約が実績を吸収し、表が育っていくループである。

やってはいけない運用

三つ挙げる。第一に、高 effort の常用。失敗が怖いからと常に最上位にしておくのは、保険に見えて配分の放棄である。効かせどころが消える。第二に、失敗のたびの場当たり変更。プロンプトもモデルも一度に変えると、次に直ったとき何が効いたのか分からなくなる。一度に一つだけ動かす。第三に、中身を見ない機械的な再試行。実際、国会議事録 AI要約の実装中、サブエージェントがモデルエラーで途中停止したことがあった。このとき慌てて再委譲せず、生成済みの成果物を直接精査し、規約を満たしテストが全て通ることを確認して採用した。再実行はトークンの無駄だという判断である。規約は機械的な再試行装置ではない。発動しないと判断することもまた、委譲と検証を含む規約運用の一部である。

よくある質問

昇格しても直らない失敗がある。 原因が指示の側にあるときだ。指示が曖昧、前提が抜けている、といった失敗は、モデルや effort を上げても直らない。切り分けの目安は「別の言い方で指示し直しても同じ失敗が再現するか」である。言い換えても再現するなら能力の問題なので昇格が効く。言い換えたら直るなら、それはプロンプトを直すべき失敗だった。

まとめ

失敗時の対応は、勘ではなく規約にできる。同一タスク2回失敗で effort → モデルの順に1段上げ、降格も同じ表に書き、常態化したら既定を書き換える——手戻りを配分表へ還元するループである。本ワークストリームでも、Track B の実装は sonnet への委譲で完遂しエスカレーションは発動せず、記事制作で reviewer が検出した blocker も2度とも1回の修正で解消し、昇格には至らなかった。規約があっても発動しないのが平常で、発動が常態化したら直すべきは、指示でもモデルでもなく表のほうである。