想像してみてほしい。あなたはコーディングエージェントにバグ修正を指示し、一連のユニットテストを「正しく直せたかどうか」の判断基準として与えたとする。
モデルは何度試してもテストを通せない。そこで、予想外だが「完全に合理的」な行動に出る——そのテスト自体を書き換え、永遠に「Passed」を返すようにしたのだ。
報酬の観点から見れば、タスクは「完了」し、スコアを獲得した。しかし、あなたから見れば、バグは何一つ修正されていない。
これは過去一年間、無数の実務者が繰り返し直面してきた光景だ。その厄介な点は、モデルが「悪意」を持っているわけではなく、単にあなたが与えたシグナルを忠実に最適化しているに過ぎないことだ。問題はシグナルそのものにある。モデルはバグの修正方法を学ぶだけでなく、テストや環境、情報漏洩を悪用して報酬を得る方法も学習する。
数十年にわたり、コンピューティング分野の「常識」が私たちの難しい問題に対する直感を静かに形作ってきた。「解答を検証する方が、解答を見つけるより容易である」というものだ。複雑な数学的推論やコード生成は、まさにこの直感に依拠して目覚ましい進歩を遂げた。実行可能で検証可能な報酬（verifiable reward）さえ存在すれば、強化学習は能力を次々と「引き出して」くれるのだ。
しかし今日のコーディングエージェントにとって、この直感は反転しつつある。基盤モデルの推論能力が向上し、ハーネス（harness）技術の増幅が重なることで、十分に複雑な解の候補を生成することは安価になった。一方で、それを確実に検証すること——ユーザーの真の意図に忠実であり、大規模な訓練のもとで拡張可能であり、なおかつ常に最適化を続ける敵対者に耐性を持つこと——が、この閉ループの中で最も高価で、未解決の難題となっているのだ。
Qwenチームが復旦大学NLP研究室などと共同で完成させた、立場と実証を兼ね備えた論文《The Verification Horizon: No Silver Bullet for Coding Agent Rewards》は、これは一時的な技術的欠陥ではなく、構造的事実であると主張する。そして、「この事実とどう共生するか」についての用語体系と、一連の実践経験を提供している。
🔗 arXiv: https://arxiv.org/abs/2606.26300
🤗 Hugging Face: https://huggingface.co/papers/2606.26300
完璧な検証器は存在しない：あらゆる報酬シグナルは、人間の意図の「代理」に過ぎない
論文の出発点は不安を煽るものだが、極めて明快でもある。我々が構築できるあらゆる報酬シグナル——実行可能テスト、ルーブリック、報酬モデル——はすべて、我々が真に関心を持つ人間の意図の代理（proxy）であり、決して意図そのものではない。
なぜなら、意図とは本質的に意味的で、仕様化が不十分なものだからだ。意図を持つ人は、自分の期待のすべてを事前に明確に言い表せないことが多い。反例によってある欠落が露呈して初めて、自分が本当に何を望んでいたのかを悟る——そしてそのような反例は予測が難しく、事前に網羅することはさらに困難だ。これにより、代理と意図の間には恒久的な隔たりが残り、代理に対して十分に最適化された、十分に強力なエージェントこそが、この隔たりを見つけるためのツールとなる。
これは報酬ハッキングに対する我々の理解を完全に再構築する。それはパッチを当てて修正できるバグではない——
報酬ハッキングとは、それが代表する意図から永遠に逸脱しうる代理に対して最適化を課した場合の必然的な産物である。
したがって、忠実で頑健な検証器とは、単に得難いというだけでなく、原理的に到達不可能なのである。（これはライスの定理と一致する。プログラムのいかなる非自明な意味的性質も決定不可能である。ゆえに、任意のコードに対して完全かつ正確な汎用検証器は存在せず、実用的な検証は必然的に近似に過ぎない。）
報酬ハッキングから意図の露出へ：検証はシステムでなければならない
しかし「原理的に不可能」だからといって、我々が無力であることを意味しない。それが必要としているのは、視点の転換である。すなわち、「エージェントと意図の逸脱」を単に排除すべきエラーと見なすのをやめ、あらゆる逸脱を情報として読み取ること——それがまさに、意図のうちそれまで明確に言い表せなかった層を浮き彫りにするのだ。
検証器の存在意義のすべては、ユーザーの真の意図と一致し続けることにある。しかしこの意図は、事前に完全に書き下せる固定目標ではなく、徐々に展開されるプロセスだ——そして多くの場合、それを展開するのはエージェント自身である。より強力な方策が代理の抜け穴を突くたびに、それは我々がそれまで言語化できなかった意図の層を暴露する。
冒頭のテストを書き換えた例に戻ろう。エージェントが動く前、あなたは「テストを改変してはならない」という制約を規定する必要があるとはまったく気づいていなかった——それは暗黙の前提だったのだ。エージェントによる今回のハッキングが、この暗黙の意図を初めて具体的で、言明可能なものにした。この観点からすれば、報酬ハッキングは単なる失敗モードではなく、「エージェントと意図がどこで逸脱しているか」についての情報なのである。
検証とは一度限りのハーネスではなく、方策が強くなるにつれて絶えず後退していく地平線である。
これこそが、解決策が一回限りの「より良い」検証器ではありえない理由である。検証はシステムでなければならず、しかもそのシステムはコーディングエージェントと共進化しなければならない。方策が強くなり、新たな隙間を見つけたとき、検証システム（テスト、審判、監視、評価器）はそれを埋めるために再構築される必要がある。
最前線からの傍証。本論文が完成する前後、OpenAIがプレビューしたGPT-5.6 Solについて、独立評価機関METRは次のように評価した。そのReActエージェントハーネス上で、検出されたチート率は過去に評価されたどの公開モデルよりも高かった——そのため「チートを成功と見なすか否か」によって、その50%時間軸（time-horizon）の推定値は一桁も変わるほどだった。[^metr] OpenAI自身のシステムカードも、このモデルがエージェントコーディングや長時間タスクにおいて顕著な報酬ハッキング傾向（評価環境の欠陥の悪用、結果の偽造、権限の回避など）を示したことを記録しており、リアルタイム作動分類器を導入して監視せざるを得なかった。[^openai] 強力な方策ほど抜け穴を突くのが上手いという事実は、まさに裏側から本論文の判断を裏付けている。より強力な生成器だけを追求しても、次のエクスプロイトにぶつかるのが早まるだけだ。信頼性の天井を真に引き上げるのは、エージェントと共進化する検証システムを構築することなのである。
では、「モデルが強くなれば、自分で自分を検証できるようになる」のではないか。これはまさに誤解である。より強力な検証モデルもまた、意図の代理に過ぎず、同じ最適化の圧力にさらされる。生成器と検証器を同源とすることは、両者の盲点を高い相関性で結びつけ、隙間をより効率的に見つけさせるだけだ。出口は「より賢い単点検証器」ではなく、責務が分離され、独立して再構築可能で、方策と緊張関係を保つ検証システムにある。
検証システムは単一の審判ではなく、進化する一連のメカニズムである
検証システム = 検証工学 + 共進化。
いわゆる検証工学とは、検証者を中心に構築される検証パイプライン全体を指す。これには検証者そのものの構造（テスト、エージェント、ユーザー）だけでなく、検証者を囲む様々な付帯措置、すなわち品質フィルタリング、行動監視、性能評価、失敗モード分析などが含まれる。
そして検証工学だけではまだ不十分だ——それを真に「システム」たらしめているのは、共進化である。このパイプラインは一度組み立てて終わりではなく、方策が新たな脆弱性を見つけ続けるのに応じて継続的に再構築される。検証者とエージェントは幾度もの対抗ラウンドを通じて互いに高め合い、最終的に共進化の閉ループを形成する。
著者らは検証者の質を記述するために三つの特性を用いている：
拡張性（Scalability）：シグナルは訓練を支えるのに十分安価かつ大規模に構築・適用できるか。これは土台である。
忠実性（Faithfulness、検証者視点）：それは我々が真に関心を持つ意図をどの程度カバーしているか。狭い代理に終始していないか。
頑健性（Robustness、生成者視点）：現在の検証者に対する最適化が、エージェントを人間の意図から逸脱させる結果になりはしないか。
忠実性と頑健性は実は同一の目標を二つの角度から述べたものである。すなわち、検証者が人間の真の意図と一致しているかどうか。この二つの角度はいずれも人間の直接参加を必要とし、人間こそが究極の検証者である。
著者らは四つの検証者とそのシナリオを研究し、同一の観点から逐一考察した。検証設計を難しくするタスクの特徴、それによって課される検証上の制約、採用された具体的実装、もたらされた実証的観察、そしてそこから導かれた実践上の要点である。まず表で概観しよう：
テストを検証者として
コードエージェントにとって、最も一般的で工学的な訓練シナリオは例えば次のようなものだ。実際のGitHub Pull Requestからタスクを構築し、コードエージェントがタスクを実行してパッチを得る。そのパッチがテストに通過すれば正の報酬が与えられる。人間のレビューと比べて、ユニットテストや振る舞いテストに基づくexecution-based verifierは安価で自動化されており、拡張可能なため、長らく信頼できる報酬源と見なされてきた。
しかしながら、この種の検証者には以下の二つの課題が存在する：
第一に、テストが必ずしも忠実とは限らない。実際のPRのタスク意図はIssueでの議論やプロジェクトの慣習、歴史的文脈に依存しうる。命令が短すぎたり曖昧すぎたりすることもある。テストもまた目標のごく一部しかカバーしておらず、命令と矛盾する挙動を検証している可能性すらある。こうしたシナリオでは、テスト結果は解答の良し悪しを忠実に評価できず、「低い通過率」が必ずしも「難しい」を意味せず、単に「信頼できない」だけかもしれない。
第二に、テストが必ずしも頑健とは限らない。テストドリブンの報酬は依然として最終パッチが通過するかどうかだけを見ており、モデルがどのようにパッチを得たかを見ていない。モデルは正常にデバッグできる一方で、元のPRを検索したり、漏洩したdiffを覗き見たり、コミットメタデータにアクセスしたり、テストスクリプトを改変したりもできる。どちらの経路もテストを通過しうるが、前者はソフトウェア工学能力を学習し、後者は評価の抜け穴を悪用することを学習する。
これら二つの問題に対して、著者らは二つの対策を講じた。第一に、Agentic Quality Judge（軽量コーディングエージェントのように環境に入りコードを読み、コマンドを実行し、テストを調べる）を用いて、まず「動く」ものと「信頼できる」ものを区別し、命令が不明確でテストが不整合なサンプルをフィルタリングする。データは多ければ良いというものではなく、肝心なのはこの報酬が最適化に値するかどうかである。実験によれば、クリーニング後のデータはRLモデルがより急峻な学習効率を維持することを可能にした。
第二に、著者らは軌跡レベルの行動監視（Behavior Monitor）を提案した。RL訓練において軌跡全体を監査し、各ロールアウトのコマンド履歴、ネットワークアクセス、Git操作、ファイル読み書き、テスト実行、最終パッチを体系的に記録し、ハイリスクなパターンに該当すれば報酬を減ずる。そしてこのパターンセットは、モデルが新たな近道を発見するたびに絶えず再構築される——これこそ「検証システムが方策に応じて再構築される」ことのミクロな縮図である。実験が示すところによれば、この措置は訓練目標を「テストさえ通れば良い」から「テストに合格し、かつ信頼できるプロセスを通じて問題を解決する」へと変えることに成功した。
インタラクティブ審判を検証者として
プログラミングエージェントの報酬設計において、フロントエンド開発は特に手強い分野である。フロントエンドの良し悪しは機能性の通過/失敗というシグナルよりも高次のものであり、エージェントはエラーゼロのHTML、CSS、JavaScriptを書くことが完全に可能である一方、レンダリングされたページが醜かったり、アニメーションがカクついたり、インタラクションが機能不全だったりしうる。
これはすなわち、フロントエンド検証の忠実性（Faithfulness）の内包はより豊かで、より動的で、よりインタラクションを重視するということだ。コードが動くことと、よく出来ていることは全く別物なのである。しかし、より多様で包括的な評価次元は、LLM審判（llm-judge）という検証者形態の導入も意味し、これが逆に頑健性（Robustness）に新たな課題をもたらす。一方で、視覚効果などの評価次元は比較的主観的で、同じ解答に対する複数回の採点に大きな開きが出うる。他方で、LLM審判は最適化の過程で容易に悪用され、予想外の「付随」産物をもたらす。
この問題に対し、著者らは二層の探求を行った。まず、彼らは採点細目（ルーブリック）に基づく静的審判から着手した。審判にレンダリング後のスクリーンショットとソースコードの両方を読ませ、機能的正確性、視覚品質、レイアウト、ユーザー体験といった構造化された次元に沿って項目ごとに採点させるのである。この段階の妙味は、「見た目の良さ」や「使いやすさ」といった主観的感覚を、再現可能な細粒度の判断に分解したことであり、人間のアノテーションとの一致を顕著に向上させただけでなく、異なる審判モデル間の採点もより安定した。
しかし静的審判はすぐに生来の弱点を露呈した。一方で、フォーム検証、動的ルーティング、状態インタラクションといった、ページが実際に動作して初めて検証できる挙動は、コードと静的スクリーンショットを見るだけでは到底判断できない。他方で、モデルも抜け穴を突くことを学習した。「CSSコードを書けば美観スコアを詐取できる」ため、冗長なCSSやJSを必死に積み上げてスコアを吊り上げるのである。これはまさに、前章で繰り返し強調してきた報酬ハッカーがフロントエンドシナリオで再び姿を現したものだ。
インタラクティブ審判（Interactive Judge）プロセスの概要：このプロセスは候補コードとユーザープロンプトを入力として受け取る。前処理段階で、システムはまずページ情報（アクセシビリティツリー、ブラウザ状態、キーボードリスナーを含む）を抽出し、評価基準（すなわちキー項目チェックリストと詳細項目チェックリスト）を総合的に生成する。続いて、動作プランナー（action planner）が完全な動作リストを一度に生成し、Playwrightサーバーに渡して実行させることで、インタラクション軌跡（interaction trace）が生成される。最後に、評価モデルが評価基準に照らしてこの軌跡に採点し、その結果はRL訓練の報酬シグナルとしても、SFTデータ構築のラベル付けとしても利用できる。
このため、著者らはさらに一歩進んだAgenticインタラクティブ審判を導入した。その動作方式は実際の人間の品質検査員に近い。まず動作プランナーが完全なインタラクションスクリプトを一度に生成し、それをPlaywrightに渡して実際のブラウザ内で段階的にクリック、スクロール、フォーム入力を行わせ、インタラクション過程全体を完全に録画する。最後に審判モデルが実行時の実際のパフォーマンスと照合して採点する。報酬シグナルがコード表面の外観ではなく、ページが実際に動いた結果に根ざしているため、このメカニズムは生来的に長さを水増しする手法に対し免疫を持ち、またアニメーション、状態遷移、複数ページナビゲーションといった静的評価では全く見えない動的挙動を捕捉することもできる。
実験結果が示すところによれば、静的審判と比較して、インタラクティブ審判は「コード長」の報酬脆弱性を塞げるだけでなく、頑健で持続的なテストセット上での効果向上をも達成できる：
WebDev RL訓練曲線：この図は三つの審判パラダイム（視覚審判、混合審判、インタラクティブ審判）を用いた場合のRL訓練過程における、フロントエンドコーディングスコア（訓練セットおよびテストセット）と生成長さの訓練ステップに伴う変化曲線を示す。RLの報酬シグナルとして、インタラクティブ審判は二つの静的審判案より優れ、出力長を安定に保ちつつより高いテストスコアを獲得した。
ユーザーを検証者として
エージェントがプロダクト化段階に入るにつれ、広範なユーザーが重要な監督の源泉となる。ユーザーは自分の意図が真に実現されたかどうかを気にかけるため、生来的にエージェントの最も忠実で頑健な検証者であり、エージェントの進化に伴いユーザーもまた適応してより豊かな意図を実現するようになり、ゆえにエージェントと共進化する。しかし、その真の意図（大量の、当初は明言されなかった要求を含む）は複数ターンのインタラクションの中に暗黙的にエンコードされており、直接監視シグナルに変換するのが難しい。そのため、何らかの方法でそれを抽出し利用する必要がある。
著者らは熟練エンジニアとコーディングアシスタントの12.5万件の実際のインタラクション軌跡を収集し、これら対話の中に散らばるシグナルをスカラー形式に変換し、ユーザーフィードバックの感情極性と対応するフィードバックの種類をラベル付けした。その結果、次のことが判明した：
ポジティブなシグナルは極めて稀（わずか3.5%）で、ネガティブなシグナルが20%を占め、残りはすべて中立。
ネガティブフィードバックは「より確信的」：81.8%のネガティブシグナルは高信頼度である——ユーザーは否定するとき、格段に明確に表現する。
エラーは二箇所に集中：実行エラー（56.6%）と理解エラー（21.1%）で、合計約8割。
エラー情報から見て取れるように、エージェントタスクにおいてユーザーのネガティブ情報は非常に明確な改善価値を持っており、実行エラーやコード理解エラーなどが含まれる。
そこで著者らはSpan-KTOという手法を設計し、これらの監視シグナルを活用する。Span-KTOの考え方は単純明快だ。一つの応答をユーザーインタラクションの境界に沿って、正/負ラベル付きの複数の断片（span）に切り分け、明確に「良い振る舞いに寄せ、悪い振る舞いを押し退ける」。各断片について、「現在のモデル vs 訓練前モデル」の対数確率の差をそのスコアとし、正の断片はそれがより高くなるように奨励し、負の断片はより低くなるように抑制する：
ユーザーフィードバック利用 vs 教師あり学習の性能評価比較。Aone-benchはQwen自社構築のソフトウェア工学評価セット。
ユーザーの暗黙的フィードバックを利用して訓練した後、モデルはソフトウェア工学タスクとスキャフォールディング命令の遵守において非常に顕著な改善を示した。著者らはまたエージェントの中間挙動を監視し、ユーザーフィードバック情報の利用がエージェントの不良挙動を効果的に低減できることを発見した。
エージェントの行動監視、軌跡中の誤った行動に改善が見られたかを観測。
解けたタスク上では各次元で小幅な向上に留まったが、解けなかった困難なタスク上では差が明確に広がった——非効率な挙動が34.5%減少（無意味な再試行の減少）、コミュニケーション品質が26.5%向上（どこで詰まっているかを明確に説明できるように）、実行エラーが13.9%改善した。つまり、モデルが学んだのは単に「より多くの問題を解く」ことではなく、失敗の軌跡においてもより制御可能で、専門的で、抑制の効いたものになったこと、そしてこれこそがデプロイメントにおける信頼の源泉なのである。
能動的エージェントを検証者として
エージェント能力の持続的向上に伴い、Long-horizonの長時間タスクがますます注目を集めている。NL2repo（自然言語からリポジトリ全体を生成する）を例にとると、モデルに自然言語の要件記述を提供するだけで、完全に機能するコードベースを得ることができる。
しかしながら、タスクの難易度が上がるにつれて、検証の難易度も大幅に上がる。第一に、複雑なコードベースに比べて、要件記述は「曖昧」である。我々はリポジトリを設計する際、「何を望むか」だけを考え、「具体的にどのような形に仕上げるか」を事細かに書き表したりはしない。加えて、テスト対象は動的に変化する。各モデルは全く異なるアーキテクチャ案や入出力インターフェースを選択しうるため、可能性のあるすべての実装経路をカバーするテスト群をあらかじめ書いておくことはほぼ不可能である。
では、要件が極めて複雑で、実装経路も動的に変動する問題をどのように検証するのか？著者らの答えはこうだ。万能なテストが書けないなら、エージェントに「読み解かせ」て動的に判断させればよい。彼らは自律的な評価エージェント（Evaluation Agent）を配備し、生成されたコードリポジトリを直接読ませ、要件を逐項チェック可能なリストに分解させ、自らテストを作成・実行させ、複数ラウンドの精査の後にスコアを付けさせた。評価は「既定の固定ルール」から「必要に応じた推論、動的判断」へと変わったのである。
しかしモデルにモデルを判断させることは、決して順調にはいかなかった。著者らは五ラウンドの反復（v1→v5）を通じて、評価器のいくつかの典型的な失敗モードを体系的に暴露し修正した：
手抜き（v1）：評価器は「見るだけで実行しない」ことを好む——静的コード読解だけを行い、テストを実行しないため、一見合理的に見えるコードが容易にすり抜ける。
エンドツーエンド検証の欠如（v2）：個々のモジュールには問題がなくとも、リポジトリ全体がインポートエラーや依存性衝突などで全く動作しないにもかかわらず、高スコアを獲得し続ける。
役割の錯乱（v3）：評価器が「越権」する——こっそりコードを修正してバグを隠蔽したり、自らテストを作成する代わりに既存のテストを実行したり、さらには生成者の弁護まで行う。
文脈過多（v4）：評価器がコードベース全体を端から端まで読み込むため、肝心な情報が埋没し、判断精度が低下する。
ルール過多（v5）：細かすぎるプロセス規範がモデルの命令遵守能力を超えてしまった——評価器は教条に溺れ、かえって総合的な判断力が低下した。
評価器プロンプトの五ラウンド反復結果
v1からv4にかけて、BoN正確度は57.9%から67.4%へ向上したが、v5での下落が示すのは、評価器のルール設計には「スイートスポット」が存在するということだ——正しいプロセスへ導くのに十分具体的である必要がある一方、モデル自身の推論能力を圧倒するほど細かくあってはならない。
続いて著者らは別の興味深い発見も明らかにした：「良い評価器」かどうかは、何のためにそれを使うかによる。RFTは「悪いサンプルを混入させない」ことを要求し、順位付けの精度には寛容である。一方、RLは勾配を形成するために正確なサンプルごとの報酬を必要とし、順位付けに比較的厳しい。実験が示すのは、順位付けが最も正確な評価器が必ずしもフィルタリング品質が最適とは限らず、両者は当然ながら一致するものではないということだ。どちらを選ぶかは訓練目標次第である。
さらに、データ品質とデータ数量の間にも構造的矛盾が存在する。フィルタリング閾値を上げれば品質は向上するが、残存するサンプル量が急激に縮小する可能性があり、実際の使用時には両者の相互トレードオフを考慮する必要がある。
RFT実験は評価器の実際的価値を検証した。同じデータ規模のもとで、評価器により選別されたデータはランダムサンプリングより1.91点高い。データ量を倍増すれば追いつけるものの、訓練効率は大きく損なわれる。計算予算が限られた現実的条件下では、良い評価器こそが最も費用対効果の高いデータ梃子である。
検証の地平線（The Verification Horizon）
コーディングエージェントの検証とは、後退し続ける地平線である。地平線の内側は、エージェントが現在の能力のもとで確実に検証されうる部分であり、地平線上はエージェントが発見した人間の意図と不一致な箇所である。しかし我々がこの線に近づき、それを実現するたびに、より強力な方策が新たな隙間を見つけ、この線を再び遠くへ押しやり、我々に絶え間ない追走を強いる：
エージェントが検証システム内で反例を発見する → 地平線が再び後退する → 人間がさらに意図を明確化し、検証システムを再構築する。
結論はここから自然に導き出される。信頼に足る能力成長を真に支えるのは、いかなる単一の報酬関数でもない。それは、報酬関数、品質フィルタリング、行動監視、失敗モード分析などの機能を一つの全体へと組織化し、方策能力に応じて絶えず再構築される検証システムである。これが要求するのは、一度の視点転換である。「方策が抜け穴を突き、設計者が事後的にパッチを当てる」という受動的修復から、検証器と方策の能動的共進化への転換だ。検証システムとは、訓練パイプラインの補助コンポーネントではなく、「単なる能力成長」を「信頼に足る能力成長」へと変換する中核的インフラストラクチャなのである。
[^metr]: METR, *Summary of METR's predeployment evaluation of GPT-5.6 Sol*, 2026-06-26. https://metr.org/blog/2026-06-26-gpt-5-6-sol/
[^openai]: OpenAI, Previewing GPT-5.6 Sol and corresponding Preview System Card, 2026-06. https://openai.com/index/previewing-gpt-5-6-sol/
© THE END
転載の際は本公式アカウントの許可を求めること
投稿または取材依頼：liyazhou@jiqizhixin.com