失敗したコードAIをすぐ強いモデルへ送るな。35%の費用で解決率を上げたCodeRescue
コード生成AIがテストに失敗した。ここで多くのシステムは、安いモデルを諦めて強いモデルへ処理を渡します。能力が足りなかったのだから、より賢いモデルを呼ぶ。筋は通っています。
ところが、2026年7月21日に公開された論文「CodeRescue」は、この定石に小さくない穴を見つけました。失敗には、エラーログを見せれば安いモデルでも直せるもの、最初から考え直せば解けるもの、本当に強いモデルが必要なものが混在しています。全部を同じ出口へ送るのは、病院の受付で全員をいきなり救急外来へ案内するようなものです。さすがに待合室が泣きます。
論文の主要実験では、失敗後に常に強いモデルへ切り替える方式の解決率は68.6%、平均回復費用は7.22ミリドルでした。CodeRescueを平均2.56ミリドルの予算で動かすと、解決率は71.7%へ上がりました。費用は常時切替の約35%です。
安くしたのに成績も上がった。鍵は、モデルの強さではなく「失敗後に何をさせるか」を選んだことにあります。
従来の二択では、失敗ログの価値を捨ててしまう
一般的なモデルカスケードは、最初に安いモデルを試し、自信が低い場合や失敗した場合だけ高価なモデルへ切り替えます。費用管理としては合理的です。ただしコード生成には、普通の文章生成と違う特徴があります。
生成したコードを実行できるため、失敗が追加情報を生むのです。
- コンパイルエラーなら、文法や型の局所修正で済むかもしれない
- 不正解なら、境界条件の見落としかもしれない
- タイムアウトなら、アルゴリズムから考え直す必要があるかもしれない
同じ「失敗」でも、次に必要な計算は違います。強いモデルへの切替だけでは、エラーログを受け取った小型モデルが安く修正できる可能性を捨てます。一方で、何度も小型モデルに粘らせればよいわけでもありません。深い能力不足なら、安い試行を積み上げても時間と費用が増えるだけです。
CodeRescueが解こうとしたのは、この中間の判断です。
3つの回復行動を選ぶ
CodeRescueは、小型モデルの初回コードが実行に失敗した後、次の3行動から1つを選びます。
- 修正（reflect）：問題文、実行結果、標準エラーを小型モデルへ渡し、現在の解法を局所的に直す
- 再計画（replan）：現在の案を捨て、小型モデルに別の方針で最初から解かせる
- 上位切替（escalate）：問題と失敗情報を強いモデルへ渡す
ルーターが見るのは、問題文、判定結果、標準エラーに加え、ベンチマーク名、難易度、アルゴリズムタグです。失敗したコードそのものは入力しません。Qwen3.5-4Bを使い、過去の実行履歴から「成功した行動のうち最も安いもの」を教師ラベルとして学習します。
ここで面白いのは、3行動が単純な強さ順ではないことです。論文が校正用とテスト用の失敗例をまとめて調べると、安価な修正か再計画だけで解ける失敗が28%、上位モデルだけで解ける失敗が45%、どちらでも解ける失敗が27%でした。
つまり、安い行動は弱い上位互換ではありません。失敗によっては、強いモデルへ丸投げするより、元の小型モデルへ具体的なエラーを返した方が適切です。実行可能な環境では、能力だけでなくフィードバックとの相性が効きます。
予算が変わってもルーターを学習し直さない
実運用では、使える予算が固定とは限りません。無料枠、通常枠、急ぎの案件で許容費用は変わります。予算ごとにルーターを再学習する設計は扱いにくいでしょう。
CodeRescueは、各行動に対するルーターのスコアから、費用に比例したペナルティを引きます。概念的には次の式です。
選択値 = 成功しそうな度合い - 費用ペナルティ × 行動費用
費用ペナルティを大きくすれば修正や再計画が選ばれやすくなり、小さくすれば上位モデルへの切替を許しやすくなります。論文はこのペナルティをConformal Risk Control（CRC）で校正しました。
CRCの役割は、保留した校正データを使い、指定した平均回復予算に収まる運用点を選ぶことです。同じ学習済みルーターのまま、予算だけを変えられます。
ただし、ここは誤解しやすい点です。CRCが保証するのは、交換可能性などの仮定の下での平均回復費用です。解決率71.7%を将来も保証するものではありません。品質向上はテストデータで観測された実験結果です。
5つのコードベンチマークで何が起きたか
研究チームはAPPS、TACO、BigCodeBench、LiveCodeBench、CodeContestsの5ベンチマークを使いました。小型モデルはGPT-5.4-nano、上位モデルはGPT-5.4です。約27,300問へ初回試行を行い、回復用の学習データを作りました。
最終的な学習データは4,656例です。校正用360例とテスト用360例は問題IDが重ならないように分離されています。テスト結果は次の通りです。
| 回復方法 | 解決率 | 平均費用 | |—|—:|—:| | 常に修正 | 27.5% | 1.24ミリドル | | 常に再計画 | 45.3% | 1.59ミリドル | | 常に上位モデルへ切替 | 68.6% | 7.22ミリドル | | 二値カスケード | 63.6% | 2.56ミリドル | | CodeRescue（予算2.56ミリドル） | 71.7% | 2.56ミリドル | | CodeRescue（費用制約なし） | 81.7% | 5.51ミリドル |
同じ2.56ミリドルでも、単純な二値カスケードは63.6%、3行動を選ぶCodeRescueは71.7%でした。差は8.1ポイントです。費用を抑えたことだけでなく、回復の種類を分けたことが効いています。
さらに、費用制約なしのルーターは81.7%を解き、常時上位モデルの68.6%を13.1ポイント上回りながら、平均費用は7.22から5.51ミリドルへ下がりました。上位モデルが常に最善ではないという論文の中心主張を、かなり分かりやすく示す結果です。
別のGemini-2.5-FlashとGemini-2.5-Proの組でも同じ枠組みを試しています。ただしこちらはデータが小さく、著者も移植性の確認と位置づけています。主要な証拠はGPTの実験です。
CodexやOpenCodeへ持ち込むなら
ここからは論文の報告ではなく、AICompanyによる実装案です。
いきなりQwen3.5-4Bを学習しなくても、回復ルーティングの考え方は小さく試せます。まず、エージェントの各失敗で次を記録します。
- タスク種別と規模
- 失敗種別（コンパイル、テスト不合格、タイムアウトなど）
- 標準エラーの短い特徴
- 選んだ回復行動
- 成功または失敗
- 追加トークン、実行時間、API費用
そのうえで、最初は単純な規則にします。
“text 構文エラーや単一テスト失敗なら修正 同じ原因で2回失敗したら再計画 複数モジュールへ波及する失敗や能力不足なら上位モデルへ切替 残予算を超える行動は選ばない “
この規則の結果を数週間ためれば、どの失敗にどの行動が安く効いたかを集計できます。その後に分類器や小型LLMルーターへ置き換える方が安全です。
ただし、この簡易版にCRCの統計保証はありません。また、強いモデルへ送る判断を遅らせると、重大な変更で時間を浪費する可能性があります。費用だけでなく、締切、変更範囲、セキュリティ重要度も制約へ加えるべきです。
この研究でまだ分からないこと
第一に、論文が選ぶのは最初の失敗後の1回だけです。実際のコードエージェントは、修正、テスト、再修正を何度も繰り返します。複数手の途中でいつ上位モデルへ切り替えるかは未解決です。
第二に、対象はプログラミング問題が中心です。SWE-benchのようなリポジトリ規模の保守、依存関係の更新、UI変更、長時間の探索で同じ改善幅が出るとは限りません。
第三に、学習ラベルは「成功した行動のうち最も安いもの」です。各行動が成功する確率を校正しているわけではありません。データ分布が変われば、ルーターも費用校正も見直す必要があります。
第四に、公開実装はデータ生成、学習設定、CRC計算まで含みますが、公開直後でコミットは1件、リリースはありません。再現可能な材料はある一方、第三者追試の蓄積はこれからです。
結論
CodeRescueの価値は、「小型か大型か」というモデル選びを、「失敗後に何をするか」という回復行動の選択へ広げたことです。
テストや実行ログを持つコードエージェントでは、失敗は単なる不正解ではなく、次の判断材料です。修正で済む失敗、再計画が必要な失敗、上位モデルでなければ難しい失敗を分ければ、費用と解決率を同時に改善できる余地があります。
本番へそのまま持ち込める完成形ではありません。それでも、失敗したら反射的に最強モデルを呼ぶ設計を見直すには十分な証拠です。AIエージェントの次のコスト競争は、安いモデルを使うことより、失敗後の一手を無駄にしないことから始まるのかもしれません。
参考資料
【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能