修正を続けるほど正解を壊す。コードエージェントに必要な停止設計
コードエージェントが一度正しいpatchへ到達しても、そこで終わるとは限りません。
テスト結果を渡し、「もう一度改善して」と頼む。もっと考えれば、もっと良くなるように見えます。ところがLooping Is Not Reliabilityの実験では、現在の実行traceを使った条件の正解率が1回目のrevisionで82.0%だったのに、2回目には67.3%へ落ちました。
一度でも正解した割合は増えています。それでも、現在手元にあるcodeは悪化している。宝を見つけた回数は増えたのに、帰り道で落としているわけです。agentも宝箱にセーブ機能が要ります。
この論文が扱うのは、agentに正解を探させる方法ではありません。見つけた正解を保持し、現在のcodeに対応する証拠だけを使い、誤った完了を防ぐorchestration設計です。
古い問題。best scoreだけでは運用の失敗を隠す
code generationの評価では、pass@kやbest-of-kがよく使われます。複数回試して、そのどこかで正解すれば能力を測れます。
しかし実際のcoding agentは、proposalを出して終わりではありません。testを実行し、logを読み、codeを直し、再びtestし、最後にどの状態を採用するか決めます。
ここでは2種類の確率が同時に動きます。
- 間違った状態から正しい状態へ移る修正率
- 正しい状態から間違った状態へ戻る破壊率
現在のcodeが高い確率で正しいなら、修正率より破壊率の影響が大きくなります。つまり「revisionを増やすほど成功候補は増える」と「最終提出物が良くなる」は同じ意味ではありません。
論文はこれをproposal searchとcompletion reliabilityに分けます。前者は正解を一度でも作れたか。後者は正解状態を保持し、その状態に対する証拠で検証し、適切な条件で停止できたかです。
900 trajectoryが示した正解の非固定性
最初の実験は30個のHumanEval repair taskを使います。Qwen2.5-7B-Instructに3回のforced revisionを行わせ、6種類のevidence条件と5 seedを組み合わせました。合計は900 trajectory、2700 revisionです。
current trace条件の現在正解率は次のように動きました。
- revision 1: 82.0%
- revision 2: 67.3%
- revision 3: 69.3%
一方、一度でも正解したever-correctは82.0%、84.7%、85.3%と増えています。revision 3では16.0%が「途中で正解したが、その後に失った」trajectoryでした。
これは「loopは常に悪い」という結果ではありません。current binary条件は70.0%、70.0%、72.0%でした。stale trace条件は68.7%、71.3%、66.0%、evidence unavailableは68.7%、68.7%、70.7%です。
深さだけでは方向が決まりません。何を証拠として渡し、どの状態に対する証拠か、agentがどう反応するかで遷移が変わります。
古いtraceは正しいcodeを壊す
free-running trajectoryだけを比べると、evidenceによって途中のcode状態そのものが変わります。そこで論文は、同一のwrong stateとcorrect stateを固定し、evidenceだけを差し替えるcommon-state interventionを行いました。
対象は27 task、Qwen2.5の7Bと14B、合計2430 branchです。
14B replicationでは、correct stateへcurrent traceを渡した場合に壊れたのは4/135でした。wrong stateから得たstale traceを渡すと34/135です。差は22.2 pointで、task-cluster 95% CIは8.9から37.0、6比較のHolm補正後もp=0.0337でした。
ここで重要なのは、stale traceが嘘とは限らないことです。過去のcodeでは本当に起きたfailureでも、現在のcodeには対応しません。logの内容だけでなく、どのcode hashとtest suiteから生まれたかが必要です。
また、modelを大きくすれば単純に解決するわけでもありません。14Bのwrong startではevidence unavailableが126/135を修正し、current traceの120/135を上回りました。情報量と効用は単調に増えません。
別modelのjudgeを置くだけでは独立にならない
論文はverifierも調べています。70% coverageへ揃えたretrospective比較では、Qwen 14B verifierのriskは4.1%、DeepSeek 6.7Bは24.0%でした。
別familyのmodelをjudgeに置けば独立した確認になる、とは限りません。必要なのはfamily名ではなく、採用するcoverageでのfalse acceptanceと、verifier間の誤りの重なりです。
同じfamilyでも誤りが強く重なる場合があります。別familyでも片方のriskが高ければ、二重確認の価値は下がります。人間で言えば、違う部署から判子を2個もらっても、片方がほぼ見ていないなら安心材料にはなりません。
中心アイデア。自由文loopを小さなtransactionへ変える
論文が提案するevidence-bound typed loop contractは、次の4つを分離します。
1. evidenceをcode状態へ結び付ける
evidence envelopeにcode_hash、suite_hash、execution_id、payloadを持たせます。
現在のcode hashと一致しないevidenceは、直接Patchの根拠にしません。testを再実行してRefreshするか、Keepするか、Escalateします。
2. actionを型にする
agentの返答を自由文のまま扱わず、Keep、Patch(code)、Escalate(reason)へ分けます。
「修正不要」と「codeを返せなかった」は別の状態です。parseできない返答で正しいcheckpointを上書きしないことが重要です。
3. last-known-good checkpointを守る
設定したgateを通ったcodeとevidence hashを保存します。新しいproposalがinvalidまたはrejectなら、正しい状態を保持するかcheckpointへ戻します。
これによりparserやprotocolの失敗に対しては、正しさを固定状態にできます。ただしtestが見逃したbugまでは守れません。
4. 完了時にfresh certificationを行う
提出する状態へtestを再実行し、別の古い結果を流用しません。完了判断にはcoverage、risk、abstention、costも記録します。
StateSealを実務へ移す最小形
論文のreference implementationであるStateSealは、既存agentの外側にadmission brokerを置きます。agentはisolated worktreeでproposalを作り、brokerがstate identityを再計算し、agent processの外でverifierを走らせ、checkpointを保存してからreceiptを発行します。
論文の記載では、frozen snapshotで35個のdeterministic failure-injection caseが通り、Go、Python、Node.js fixtureも3/3で通っています。ただし、これはmechanismが仕様どおり動くconformance evidenceです。修正能力の向上やverifierの正しさを示すeffectiveness evidenceではありません。
AICompanyが小さく試すなら、まず次のtransactionだけで十分です。
- worktreeのtree hashとtest suite hashを計算する。
- test結果へ両hashとexecution IDを付ける。
- agentはKeep、Patch、Escalateのどれかを返す。
- Patchは別worktreeでfresh testする。
- gateを通るまでlast-known-goodを上書きしない。
- 最終提出前に同じ状態をもう一度certifyし、receiptを残す。
この設計はLLMを賢くしません。古いlog、壊れたparser、retry競合によって、すでに正しいcodeを失う経路を減らします。
guardは安全性と修正力を交換する
540 rolloutのprospective comparisonでは、correct startを壊したのはbaselineが13/135、guarded executionが0/135でした。一方、wrong startからのrepairは100/135から93/135へ減りました。
つまりguardは無料ではありません。正解保持は改善しても、役に立つ修正をrejectできます。事前定義されたunsafe-completion superiorityとsound-completion non-inferiorityのjoint criterionは通りませんでした。
運用では、次を別々に測る必要があります。
- preservation: 正しい状態を失わないか
- competence: 間違いを直せるか
- certification: 完了判断は正しいか
- liveness: rejectばかりで止まらないか
- cost: test回数、token、時間が増えすぎないか
安全側へ倒して何も提出しなければ、observed errorはゼロにできます。しかし仕事もゼロです。ゼロにはいろいろ種類があります。
どこまで信用できるか
結果には明確な限界があります。
第一に、forced revisionは自然なadaptive agentそのものではありません。「必ず続けたら何が起きるか」を測るstress testです。
第二に、HumanEval taskは学習データに含まれる可能性があります。common-state studyは7Bでwrongとcorrectの両状態を観測できた27 taskに限定されます。
第三に、repository実験は9個のPython projectから24 bug、4 coder stack、1 scaffoldです。accepted completionはstackごとに5、12、6、4と少なく、repository factorialやcomponent ablationの多くはHolm補正後に有意ではありません。
第四に、private suite、raw trajectory、full lineageは公開されていません。論文が案内するStateSeal artifact URLも、2026年8月3日の監査時にはHTTP 401を返し、sourceとcase catalogをこちらで独立確認できませんでした。
したがって「このcontractでcoding agentが安全になる」とは言えません。言えるのは、状態不一致のevidence、checkpoint上書き、古いtest結果での完了というfailure modeを、監査可能な機械的ルールへ変えられることです。
結論。iterationではなくadmissionを設計する
Looping Is Not Reliabilityの価値は、self-correctionへ悲観論を投げることではありません。iterationが作るのはproposalであり、reliabilityは別の層で設計する必要があると示したことです。
coding agentを実務へ入れるなら、revision回数を増やす前に確認したいことがあります。
そのtest結果は、今のcodeに対するものか。正しいcheckpointを保持しているか。最後に採用する状態をfresh testしたか。reject率と修正率を同時に見ているか。
賢いmodelを待たなくても、この4点はorchestratorで始められます。agentの頭脳だけでなく、提出物を守る台帳を作る。今回の論文が教える実務の一歩は、そこです。
参照
【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能