AI の「正しい」を決める検証契約

by

生成 AI の信頼性を考えるとき、最初に目へ入りやすいのは正答率である。質問に正しく答えた割合、プログラム修正に成功した割合、ベンチマークで得た点数は、異なるモデルの能力を同じ尺度で比較するために使いやすい。正解があらかじめ定義された課題では、モデルの出力と正解を照合すれば合否を決められるため、正答率はモデル選定の有力な材料になる。

実際のシステムでは、モデルが正しい答えを生成する確率に加えて、生成された個々の結果を業務上の回答、判断、変更として確定してよいかという判断が続く。正答率が 90% のモデルを使っても、目の前にある一件の回答が残り 10% に含まれるかは正答率だけから判定できない。そこで、引用元を確認する、計算を再実行する、生成したコードへテストを適用する、別の評価器で条件を照合するといった検証が必要になる。

この違いは、生成能力と受理条件を分けると明確になる。生成能力は、モデルが要求に合った候補をどれだけ高い確率で作れるかを表す。受理条件は、その候補について何を確認すれば確定してよいかを定める。モデルの能力が向上すると正しい候補が増える。一方、受理条件を明示すると、個々の出力について何が確認済みであり、どこまでを保証できるかを管理できる。

ソフトウェアテストを例にすると、この構造は身近である。テストを通過したプログラムについて確定するのは、用意された入力、期待結果、実行条件の組み合わせで要求を満たしたという事実である。既稿では、テストが仕様全体そのものではなく、仕様から選び出した観測条件として働くことを整理した[1]。仕様から確認条件を選び、その条件を実行可能な形へ変換し、観測結果を期待値と比較することで、自動的な合否判定が成立する。

同じ構造を生成 AI へ適用すると、「AI が正しいか」という広い問いを、そのまま一つの数値で扱うことの難しさが見えてくる。最終結論が正しいこと、引用先が存在すること、引用した資料が主張を支持すること、生成したコードが要求されたテストを通ること、診断した原因が既知の正解と一致することは、それぞれ異なる条件である。どの条件を確認するかによって、「検証済み」という言葉が指す範囲も変わる。

本稿では、AI の出力を受理するために定める条件の集合を検証契約と呼ぶ。検証契約は、少なくとも検証対象、検証単位、判定規則、保証範囲の 4 要素から構成できる。

構成要素 決めること 生成 AI での例 契約上の意味
検証対象 何について正しさを確認するかを決める。 最終回答、引用、コード変更、原因診断などを対象にする。 何を「確認済み」と呼ぶかの対象範囲が決まる。
検証単位 対象をどの粒度まで分解して判定するかを決める。 回答全体ではなく、個別主張や引用ごとに判定する。 どの種類の誤りを個別に検出できるかが決まる。
判定規則 どの条件を満たせば合格とするかを決める。 正解ラベルとの一致、参照先の存在、テスト成功などを条件にする。 同じ出力に対して再現可能な合否判定を置ける。
保証範囲 合格結果からどこまでの正しさを主張するかを決める。 引用先の存在確認と、引用内容による主張の裏付けを区別する。 合格という結果から導いてよい結論の境界が決まる。

この 4 要素は互いに独立している。たとえば、回答に引用が付いていることを検証対象に選んでも、引用をどの粒度で調べるか、何を合格条件とするかによって結果の意味は変わる。引用記号が存在すれば合格とする規則、参照先の文献が実在すれば合格とする規則、引用した箇所が直前の主張を意味的に支持していることまで要求する規則では、同じ「引用を検証した」という表現でも確認している内容が異なる。

検証条件 確認できること その条件だけでは確定しないこと
引用記号がある 回答が所定の引用形式を持っていることを確認できる。 参照先が実在することや、主張を支持することまでは確定しない。
参照先が存在する 架空の文献や取得していない資料への参照を検出できる。 参照した資料の内容が直前の主張を支持することまでは確定しない。
引用内容が主張を支持する 主張と根拠との意味的な対応を確認できる。 回答全体の結論が妥当であることや、必要な資料を網羅したことまでは確定しない。
最終結論が正解と一致する 評価対象となった問いについて期待された結論へ到達したことを確認できる。 途中の根拠、調査手順、引用関係まで妥当であることは別に確認する必要がある。

検証条件を追加すると、確認可能な範囲は段階的に広がる。引用形式だけを見る契約から、参照先の存在、意味的な支持、最終結論まで確認する契約へ進めば、それぞれ異なる失敗を検出できる。契約を詳細にすると、契約へ含めた条件についての証拠が増え、その範囲で保証を具体化できる。保証範囲は、契約へ含めた条件に限られる。

ここには、ソフトウェアテストと共通する構造がある。テストケースを増やせば観測できる挙動は増えるが、テストへ変換した条件が仕様全体と完全に一致するとは限らない。生成 AI の検証でも、評価器が確認した条件と、利用者が最終的に求めている正しさの間には対応関係を設計する必要がある。検証器の性能だけを見るより、その検証器が何を入力として受け取り、どの条件で合格を返し、その結果から何を保証する設計なのかを確認する方が、システムの信頼性を具体的に把握できる。

この観点では、AI の信頼性はモデル単体の属性から、生成、検証、確定を組み合わせたシステムの属性へ広がる。モデルは候補を生成する。検証契約は候補を判定する。システムは契約を満たした結果を確定する。そして利用者が受け取る保証は、検証契約が確認した範囲によって決まる。モデルの正答率が同じでも、どの検証契約を置くかによって運用上の信頼性は変化する。

ここまで区別すると、検討すべき命題も分かれる。「高性能なモデルほど正しい回答を生成しやすい」という命題と、「検証条件を増やせば確認可能な範囲が広がる」という命題は別である。さらに、「検証器が合格を返した」という命題と、「現実に要求される正しさを満たした」という命題の間には、検証契約の保証範囲が入る。

命題 確認すべき対象 成立しても別途確認が必要なこと
モデルの正答率が高い 同じ評価条件で多数の問題を解かせ、正答率を比較する。 目の前にある個々の回答が正しいことは個別の検証を要する。
検証器が合格を返す 定義された判定規則を出力が満たしたかを確認する。 判定規則へ含まれていない品質条件は別の契約を要する。
検証契約の範囲が広い 引用、内容、結論、実行結果など複数の条件を個別に確認する。 各検証器そのものの誤判定や、現実との対応関係は別途評価を要する。
システムを信頼できる 必要な品質条件と検証契約が対応し、失敗時の扱いまで定義されていることを確認する。 利用環境や要求が変われば、契約自体の再評価が必要になる。

この分解を置くと、AI の信頼性を一つの正答率へ集約することの限界が見える。モデルの能力は正しい候補を生成できる確率を左右し、検証契約は個々の候補について何を確認してから確定するかを決める。さらに、契約がどこまで現実の要求を代表しているかによって、その合格結果から導ける保証の範囲が決まる。

以降では、この検証契約が実際の AI システムでどのように設計されているかを見る。法律回答では、完成した回答を主張と引用へ分解して検証する方法がある。原因診断では、逆に問題を生成する段階で正解を保存し、後から機械的に答え合わせできる環境を作る方法がある。両者は対象も方式も異なるが、AI が扱う曖昧な正しさを、判定可能な条件へ変換するという点で共通している。

1. 正しい答えだけでは AI の信頼性を定義できない

正答率という評価値が意味を持つためには、何を正解とするかが先に決まっている必要がある。数学問題なら最終値、選択問題なら選択肢、プログラミング課題ならテスト結果を判定材料にできる。モデルが回答を生成したあと、その出力を既知の正解や実行結果と照合すれば、一件ごとの合否を決定できる。多数の課題へ同じ規則を適用すると、正答率という集計値をモデル間で比較できる。

一方、実務上の成果物は、一つの正解ラベルへ還元しにくい。法律回答、原因診断、コード修正では、最終結果だけでなく、その結果を成立させる別々の条件がある。

対象 最終結果 追加で確認する条件 条件を分ける理由
法律回答 問いに対する最終的な法律判断が妥当である。 適用した法理、引用資料の存在、資料と各主張との対応を確認する。 正しい結論へ誤った根拠から到達した回答を区別する必要がある。
原因診断 異常を生じさせた原因を特定する。 影響対象、観測データ、原因との対応、調査過程を確認する。 原因名の偶然の一致と、再現可能な診断能力を区別する必要がある。
コード修正 要求された不具合や変更要求を解決する。 回帰、互換性、性能、セキュリティ、実装規約、運用条件を確認する。 対象症状の解消だけでは変更全体を受理する条件を満たさない場合がある。

法律回答では、最終結論だけを採点すると、正しい結論へ不適切な根拠から到達した回答も同じ正解として集計される。引用の有無を条件に追加すると、根拠を示した回答と示していない回答を分離できる。さらに参照先の存在と、引用内容による主張の支持を別々に確認すれば、架空引用と根拠の取り違えも異なる失敗として扱える。検証単位を細かくするほど、「法律回答が正しい」という一つの判定から、どの部分について何を確認したかという複数の判定へ移る。

原因診断では、真の原因が既知であれば原因名との一致を採点できる。しかし実世界の障害では、真の原因そのものが調査対象になるため、学習や評価に使える正解ラベルを大量に揃えることが難しい。原因名、影響対象、観測値、調査過程のうち、どこまで正解を保持できるかによって、検証可能な能力も変わる。この制約は、後に扱う TRACE が問題生成側から検証可能性を作る理由につながる。

コード修正では、テストを通過したという結果が一つの証拠になる。不具合を再現するテストが通れば、対象となった症状の解消を確認できる。既存テストも通れば、既知の回帰について追加の証拠が得られる。そこへ互換性、性能、セキュリティ、リポジトリ固有の規約を加えると、受理条件はさらに広がる。どこまでを自動検査へ変換し、どこからをレビューや運用確認へ残すかによって、「確認済み」と呼べる範囲が決まる。

これら三つの例に共通するのは、成果物を一つの総合点で評価するより、正しさを複数の観測可能な条件へ分解した方が、失敗の場所と保証範囲を特定しやすいことである。検証契約は、その分解方法と合否条件を固定する。ここから先の論点は、検証を置くこと自体よりも、どの契約を置けば対象となる仕事の正しさを十分に捉えられるかへ進む。

2. 検証契約は何を合格とみなすかを固定する

AI が生成した成果物を検証するとき、最初に必要なのは検証器の種類を選ぶことではなく、何を満たしたら成果物を受理するのかを定めることである。最終回答が正解と一致すればよいのか、回答中の各主張にも根拠を要求するのか、生成したコードなら対象のテストだけでなく回帰試験まで通すのかによって、同じ「検証済み」という状態でも意味が変わる。

この受理条件を構造化したものが検証契約である。少なくとも、検証対象、検証単位、判定規則、保証範囲の四つに分けると、何を確認し、その結果から何を言えるのかを区別できる。

要素 確認する内容 契約を曖昧にした場合に起きること
検証対象 最終回答、個別主張、引用、原因、コード変更など、何について正しさを判定するかを決める。 異なる性質が一つの評価へ混ざり、どの条件について合格したのかを説明しにくくなる。
検証単位 回答全体、文、主張、推論段階、テストケースなど、どの粒度で合否を取るかを決める。 局所的な誤りが全体評価へ埋没したり、部分的な成功を成果物全体の成功へ拡張したりする。
判定規則 どの条件を満たした結果を合格として受理するかを決める。 評価者や実行時点によって合否の意味が変わり、同じ成果物への判定を再現しにくくなる。
保証範囲 合格したという事実から、どの性質まで確認済みと主張するかを決める。 判定規則が確認していない性質まで、合格結果から推定する余地が生まれる。

四つの要素は連動している。検証対象を「法律回答」とだけ定めても、回答全体を一件として採点する契約と、回答を複数の主張へ分解して各引用との対応を確認する契約では、検出できる失敗が異なる。判定規則を細かくしても、その規則から導ける保証範囲を明示しなければ、「引用先が存在する」という確認結果から「引用内容が主張を正しく支えている」という別の性質まで推定することになる。

この関係はソフトウェアテストにも現れる。特定のテストケースが成功したという判定は、その入力、期待結果、実行条件についての確認結果である。回帰試験を追加すれば確認対象が広がり、性能試験や静的解析を追加すれば別の性質も評価できる。検査項目の追加によって保証範囲は拡張されるが、その範囲は実際に配置した検査条件によって決まる。

形式証明は、この境界をさらに明瞭に観察できる例である。Lean のような証明支援系では、形式化された命題と証明項が与えられると、カーネルが定められた推論規則に従って証明を検査する。既稿で扱ったフェルマーの最終定理の形式化でも、AI が証明候補の生成を支援できる一方、その候補を数学的な証明として受理する最終条件は Lean の型検査へ置かれていた[2]。

この構成では、生成と検証の役割が分離されている。AI は証明候補を生成するため、生成能力が高いほど有望な候補へ到達しやすくなる。Lean は候補が形式体系の規則を満たすかを決定的に検査するため、候補を受理する条件はモデルの自己評価から独立している。生成モデル自身に「この証明は正しいか」と尋ねる方式と比べると、受理条件を形式体系へ固定できる点が大きく異なる。

段階 確認すること 確認結果から言えること 次に残る確認
自然言語の数学的主張 人間が証明したい対象と、その意味を定める。 証明対象となる数学的主張を特定できる。 その意味が形式命題へ正しく写されているかを確認する。
形式化された命題 自然言語の主張を Lean が扱える定義と命題として記述する。 形式体系の中で検証対象となる命題を固定できる。 形式化した命題と人間が意図した主張との対応を確認する。
証明項 形式化された命題が前提と推論規則から導出されることを示す。 Lean のカーネルが受理すれば、その形式体系の中で命題が導出可能であることを確認できる。 使用した定義、前提、形式化が目的に適しているかは別の確認対象になる。

Lean の検査が厳密であることと、検証対象となった形式命題が人間の意図を完全に表していることは異なる条件である。カーネルが証明項を受理すれば、指定された形式体系の中でその命題が導出できることは強く確認できる。一方、自然言語で意図した数学的主張を別の命題として形式化していれば、カーネルは与えられた命題について正しく判定しても、元の目的との対応には別の確認が必要になる。

ここで検証契約の四要素が具体的につながる。検証対象は形式化された命題と証明項、検証単位は型検査が扱う形式表現、判定規則は Lean のカーネルが定める推論規則、保証範囲はその形式体系の中で命題が導出可能であることになる。どの要素も明示されているため、「何をもって証明を受理したのか」を追跡できる。

この例が示すのは、検証器の厳密さそのものより、検証器と保証範囲の対応を固定することの意味である。検証条件を追加すると確認可能な性質は増える。一方、それぞれの判定から主張できる範囲は、その検証条件が実際に確認した内容によって決まる。検証契約は、合格条件を増やすための一覧ではなく、合格という事実と保証する性質を対応付ける仕組みである。

この見方を生成 AI へ戻すと、信頼性を高める方法にも複数の方向がある。生成後の成果物を細かな単位へ分解し、それぞれに検証条件を置く方法がある。もう一つは、問題を作る段階から正解を保存し、後から決定的に答え合わせできる環境を構成する方法である。次に見る GANDR と TRACE は、この二つを異なる場所で実装している。

3. GANDR は回答側を検証可能な構造へ変える

法律回答では、最終結論が正しくても、その結論を支える個々の主張と引用資料との対応まで正しいとは限らない。たとえば、結論自体は妥当でも、途中で適用した法理を誤っていたり、実在する判例を引用しながら、その判例が直前の主張を十分に支持していなかったりする場合がある。回答全体を一件の正解として採点すると、こうした局所的な不整合は最終結論の成功へ埋もれる。

GANDR は、この問題を回答全体の評価だけで処理せず、法律回答を複数の検証単位へ分解する[3]。Drafter が検索済み資料を使って構造化された法律回答を生成し、別の Critic が質問、検索済み資料、完成した回答を受け取り、各主張と引用との対応を監査する。回答そのものを一つの塊として採点する代わりに、検索、生成、引用、主張との対応、最終確定という複数の境界を設ける。

この章で扱う検証対象を整理すると、次のようになる。

検証対象 主な役割 対応する研究・評価 残る確認
検索結果 回答に必要な資料を取得できたかを確認する。 LegalBench-RAG は法律分野における検索能力そのものを評価する。 取得した資料を生成モデルが正しく利用するかは別に確認する。
生成文と取得資料 生成内容が取得資料に支持されているかを確認する。 RAGTruth は取得内容に支持されない生成や矛盾を対象とする。 個々の主張と引用との対応をさらに細かく確認できる余地がある。
個別の事実 長文を小さな事実単位へ分解して正しさを判定する。 FActScore は atomic fact 単位で知識源からの支持を評価する。 どの証拠がどの主張を支えるかという帰属関係が残る。
主張と引用 引用証拠が対応する主張を十分に支持するかを確認する。 AttributionBench は主張と証拠の意味的な対応を評価する。 自動評価器そのものの誤判定が残る。
法律回答全体 検索、生成、引用、主張の監査を一つの回答生成工程へ組み込む。 GANDR は Drafter と Critic を分離し、複数の検証境界を統合する。 検索漏れや Critic の判定精度など、検証器側の制約が残る。

185 問の法律ベンチマークで、比較した 6 システムが同じ基盤モデル、同じ検索面、同じ引用指示を使う条件では、GANDR は strict accuracy 70.8% を記録し、最良のベースラインを 11.3 ポイント上回った[3]。基盤モデルや検索対象をそろえた比較であるため、この差にはモデル規模ではなく、Drafter の構成と protocol-anchored commit を含むシステム構成が関係している。

GANDR の strict correctness が確認する範囲は明確に分かれている。最終判断が正しいことに加え、すべての引用が検索器の返した資料へ解決できることを要求する。一方、引用した資料が個々の主張を十分に支持しているかについては Critic が別の監査を行う。参照先が存在することと、その内容が主張を裏付けることは別の判定規則である。

確認条件 確認する内容 確認結果から言えること 残る境界
最終判断 回答が期待される法律判断と一致するかを確認する。 評価対象の問いについて所定の結論へ到達したことを確認できる。 途中の各主張や引用関係の妥当性は別に確認する。
引用の解決可能性 引用識別子が検索済み資料へ対応するかを確認する。 架空の引用や検索結果外の参照を検出できる。 引用内容が直前の主張を支持することまでは確定しない。
主張と証拠の対応 Critic が各主張と引用資料との意味的な対応を判定する。 根拠不足や不適切な引用を主張単位で指摘できる。 Critic 自身の意味判定精度が保証範囲の上限になる。

論文では、Critic が出す 4 段階の詳細な判定ラベルと法律専門家との一致は弱かったと報告されている[3]。引用先の存在確認は比較的決定的な規則へ落とし込める一方、「この資料がこの法律上の主張を十分に支持するか」という判定には意味解釈が入る。検証単位を細かくすると失敗箇所を局所化できるが、その単位を判定する検証器の精度が次の制約として現れる。

回答を細かな事実へ分けて評価する考え方は GANDR 以前にも使われている。FActScore は長文を atomic fact と呼ぶ最小限の事実単位へ分解し、それぞれが知識源によって支持される割合を測る[4]。長文全体を一件として評価する場合、十個の主張のうち一つだけ誤っている回答と、半数が誤っている回答との差は一つの合否へ圧縮される。事実単位へ分解すると、どの主張が根拠を持ち、どこに誤りが集中しているかを観測できる。

細分化した後には、証拠との対応を誰が判定するかという問題が現れる。AttributionBench は、生成文中の主張が引用証拠によって十分支持されているかを自動評価する課題を集め、微妙な情報差や、人間とモデルが参照できる情報範囲の違いが誤判定につながることを示した[5]。引用番号が付いていること、参照先が実在すること、引用内容が主張を支持することは、それぞれ異なる検証契約である。

検索拡張生成も同じ境界を持つ。RAGTruth は、検索結果をモデルへ与える構成でも、取得内容に支持されない主張や矛盾する主張が生成されることを前提として、約 1 万 8000 件の応答を注釈したコーパスを構築している[6]。検索によって根拠候補を取得できても、生成された文章がその根拠に沿っていることまでは検索工程だけでは確定しない。検索後に、生成文と根拠との対応を確認する検証が必要になる。

法律領域では、その検索工程自体も独立した評価対象になる。LegalBench-RAG は、法律 RAG の検索段階を評価するため、法律専門家によって注釈された 6858 組のクエリーと回答を用意し、回答に必要な法律情報を適切な粒度で取得する能力を評価する[7]。生成モデルへ適切な根拠を渡すには、関連文書へ到達することに加えて、回答に必要な箇所を検索結果として取り出す必要がある。

これらの研究を検証工程の順序で並べると、検索結果の妥当性、生成文と資料との整合、個別事実の正しさ、主張と引用との帰属関係という異なる検証対象が見えてくる。GANDR は、その複数の境界を一つの法律回答生成工程へ組み込み、回答のどこで契約を満たせなかったかを追跡できる形にしている。

GANDR の特徴は Critic を追加したことだけには収まらない。回答全体を一つの検証単位として扱う代わりに、検索、主張、引用、確定という境界を分離し、それぞれに異なる判定規則を置いた点にある。その結果、「正しい法律回答」という一つの評価の内部に含まれていた複数の失敗を別々に観測できる。

同時に、GANDR は検証契約の限界も示している。引用の解決可能性は明確な規則として固定しやすいが、主張と証拠との意味的な対応は Critic の判断へ依存する。検証契約を細かくすると確認可能な範囲は広がる一方、意味判断を担う検証器そのものの性能が新しい境界になる。検証契約は誤りを一括して消す仕組みではなく、何を決定的に確認でき、どこから判定誤差が入るかを分離する仕組みとして働く。

GANDR は、すでに生成された回答を検証可能な単位へ分解する方法である。次に扱う TRACE は逆方向から同じ課題へ取り組む。回答を細分化する代わりに、問題を生成する段階で真の原因を保存し、後から決定的に答え合わせできる環境を作る。検証契約を成果物側へ置くか、問題生成側へ置くかという違いが、二つの研究を比較する軸になる。

4. TRACE は問題生成側を検証可能な構造へ変える

GANDR が生成済みの回答を検証可能な単位へ分解するのに対し、TRACE は問題そのものを作る段階で正解を保存する[8]。対象はデジタル広告の異常原因診断である。広告配信量や売上などに異常が現れたとき、観測データから原因を推定することはできても、現実のシステムでは真の原因そのものが最初から分かっているとは限らない。専門家がログや集計値を調査し、複数の仮説を比較して原因を絞り込む必要があるため、学習用データへ大量の正解ラベルを付けるには調査コストがかかる。

この制約は、原因診断を強化学習へ持ち込むときに直接効いてくる。エージェントへ試行錯誤させるには、最終診断が正しかったかを繰り返し判定できる報酬が必要になる。現実の障害を一件ずつ人間が調査して正解を確定する方式では、エージェントが必要とする反復回数に対して正解生成のコストが大きい。TRACE は診断器を直接簡単にする代わりに、正解を安価に取得できる問題生成系を構築する。

TRACE の構造を先に整理すると、検証可能性を作る場所が GANDR と大きく異なる。

観点 GANDR TRACE 検証契約としての違い
検証可能性を作る場所 生成された回答を判断、主張、引用へ分解する。 問題生成時に真の原因を介入として保存する。 GANDR は成果物側、TRACE は環境側へ検証条件を埋め込む。
主な検証単位 最終判断、引用の解決可能性、主張と証拠の対応を扱う。 根本原因と、必要な場合には影響を受けたセグメントを扱う。 何を正解ラベルとして保持するかが異なる。
正解情報の由来 ベンチマークの正解と検索済み資料を使う。 シミュレーターへ事前に注入した介入を使う。 TRACE では問題を生成した時点で答えが確定している。
主な利用局面 生成された回答の監査と最終確定に使う。 学習時の報酬と能力評価に使う。 一方は運用時の受理条件、もう一方は学習信号として働く。
残る境界 検索漏れや Critic の意味判定精度が残る。 シミュレーターが現実の原因構造をどこまで表現しているかが残る。 どちらも検証契約の外側に別の妥当性確認を持つ。

TRACE は因果関係の向きを逆向きに利用する。通常の原因診断では、最初に異常という結果を観測し、そこから原因を推定する。TRACE の問題生成側では、まず原因を決め、その原因をシミュレーターへ介入として注入し、介入の結果として観測データを生成する。診断するエージェントから見れば原因は未知のままである一方、問題を生成した側には正解が残る。

段階 問題生成側で行うこと エージェントから見えるもの 検証に使える情報
原因選択 定義済みの 12 種類の原因から介入を選ぶ。 原因そのものは開示されない。 選択した原因を正解ラベルとして保持できる。
介入 選んだ原因を制御されたシミュレーターへ注入する。 介入後に生じた状態だけが調査対象になる。 どの変更が観測結果を生じさせたかを問題生成側で追跡できる。
観測生成 介入を反映した広告配信や集計データを生成する。 Python と SQL から観測可能なデータとして提示される。 原因と観測結果との対応を再現可能な形で保存できる。
診断 正解情報を隠した状態でエージェントへ調査させる。 観測データと利用可能な調査手段だけを使って原因を推定する。 診断結果を保存済みの原因と直接比較できる。
報酬 診断した原因と必要な属性を正解ラベルへ照合する。 診断結果に応じた学習信号を受け取る。 人手で毎回原因調査を行わず、反復可能な報酬を生成できる。

この構成では、「原因を当てること」と「原因の正解を作ること」が分離されている。エージェント側では、観測された変化から原因へ遡るため診断課題の難しさが残る。一方、問題生成側では原因から観測結果へ進むため、何を介入したかを最初から記録できる。解く側には原因が未知で、採点する側には原因が既知という非対称性によって、難しい診断課題と安価な答え合わせを同時に成立させている。

235 エピソードの保留テストでは、最良のプロンプト型ベースラインである Claude Opus 5 が FullAttr@1 0.686、Qwen3.5-35B-A3B は素の状態で 0.159、教師あり微調整後に 0.637、その後に合成報酬を使った強化学習を加えると 0.757 に達した[8]。同じ Qwen3.5-35B-A3B でも、素のモデル、教師あり微調整、さらに強化学習を加えた状態で成績が段階的に変化しているため、この実験では訓練信号の設計が性能差と対応している。

条件 FullAttr@1 この比較から確認できること
Qwen3.5-35B-A3B 0.159 対象環境へ追加学習していない状態では、診断精度が低い。
Qwen3.5-35B-A3B + 教師あり微調整 0.637 診断例を使った教師あり学習によって、対象環境への適応が大きく進む。
Qwen3.5-35B-A3B + 教師あり微調整 + 強化学習 0.757 保存された正解から生成した報酬を追加すると、同じ基盤モデルの性能がさらに上昇する。
Claude Opus 5 0.686 プロンプトだけで利用した比較対象の中では高い性能を示すが、対象環境へ学習した 35B モデルを下回る。

この結果から、単純に「小さいモデルが大きいモデルを上回った」と一般化するのは適切ではない。比較しているのはモデル規模だけではなく、対象環境への教師あり微調整と、正解を利用した強化学習の有無も含む。確認できるのは、TRACE が構築した診断環境では、客観的な正解を反復的な学習信号へ変換することで、同じ 35B モデルの性能を大きく改善できたという範囲である。

TRACE の特徴は、現実世界から正解付きの原因診断事例を大量収集する代わりに、正解を保持したまま診断問題を生成した点にある。現実の障害からデータを集める方式では、異常発生後に専門家が原因を調査し、その結論を正解ラベルとして保存する必要がある。TRACE では、原因を先に決めることで、この順序を逆転させている。原因の確定に必要だった後工程を問題生成時へ移動し、報酬生成のコストを下げている。

検証契約という観点では、この方法は「何を正解とするか」を問題の外側から後付けするのではなく、問題生成過程そのものへ埋め込んでいる。注入した根本原因が正解、必要な場合には影響セグメントまで含めて正解という契約を先に固定し、その契約を満たした診断へ報酬を与える。エージェントがどれだけ説得力のある文章を書いたかではなく、問題生成時に保存した事実との一致を基準にできるため、報酬を再現可能にする。

一方、この検証契約にも保証範囲がある。シミュレーター内部では、注入した介入が真の原因として確定している。そのため、エージェントがその原因を当てたかどうかは客観的に採点できる。ここから直接確認できるのは、定義済みの原因体系とシミュレーターが生成するデータの範囲で診断能力を学習できることである。

現実の広告システムでは、シミュレーターへ定義されていない原因、複数原因の同時発生、データ欠損、運用変更、外部要因などが加わる可能性がある。シミュレーター内部で原因を正しく特定できることと、現実世界に存在する原因空間を十分に覆っていることは別の検証対象になる。TRACE の報酬はシミュレーター内部では決定的でも、そのシミュレーターが現実をどこまで代表するかによって実運用への保証範囲が決まる。

確認できること TRACE で成立する理由 追加で確認する対象
診断結果を客観的に採点できる 問題生成時に注入した原因を正解として保存している。 保存した原因体系が実際の診断対象を十分に表現しているかを確認する。
大量の学習信号を生成できる 各エピソードについて人間が原因を再調査する工程を省ける。 生成されたエピソードの分布が実運用の分布と対応するかを確認する。
原因特定能力を反復学習できる 診断と正解との一致を報酬へ変換できる。 未知の原因や複数原因へ同じ能力を一般化できるかを確認する。
検証契約を再現できる 原因、介入、観測生成、採点規則を問題生成側で管理している。 契約そのものが現実世界の成功条件と対応しているかを継続して評価する。

GANDR と TRACE は、検証可能性を作る位置こそ異なるが、共通して「正しいか」という広い問いを機械的に判定できる条件へ変換している。GANDR は成果物を分解して、回答のどの部分をどの資料と照合するかを固定する。TRACE は問題を生成する時点で原因を保存し、診断結果をどの正解と照合するかを固定する。前者は出力側の構造化、後者は環境側の構造化によって検証契約を成立させている。

この比較から、検証可能性は課題に最初から備わった性質だけで決まるわけではなく、システム設計によって追加できることが分かる。回答を分解して検証可能にする方法もあれば、正解を保持した環境から問題を生成する方法もある。共通するのは、AI の出力を評価する前に、何を正解として保存し、どの条件で照合するかを設計している点である。

5. モデルだけでなく検証構造も結果を変える

ここまで見てきた GANDR と TRACE は、モデル単体の推論能力だけでなく、検証条件と学習信号の設計が結果に影響することを示していた。この考え方は、法律回答や原因診断に限らない。数学推論、コード生成、人間によるレビューでも、候補をどう選ぶか、どの段階を採点するか、誰が最終確認するかによって、最終的に得られる結果が変わる。

この章で扱う事例を、検証契約を置く位置で整理すると次のようになる。

方式 検証を置く場所 検証単位 結果への作用
Training Verifiers 複数の候補解を生成した後に置く。 完成した候補解ごとに順位付けする。 生成器が出した候補の中から、より正しい可能性が高いものを選べる。
Let’s Verify Step by Step 推論の途中へ判定点を置く。 最終回答ではなく、途中の推論段階も評価する。 どの段階の行動へ学習信号を返すかを変えられる。
CriticGPT 人間が成果物を確認する工程へ置く。 生成されたコードに対する問題指摘を扱う。 人間が単独で読む場合とは異なる観点から誤り候補を提示できる。
実務システム 生成から確定までの工程全体へ置く。 観測、実行結果、完了条件、返却条件などを分けて確認する。 モデルの出力をそのまま成果物とせず、所定の条件を通過した結果だけを確定できる。

Training Verifiers to Solve Math Word Problems は、生成器が一つの解答だけを出し、その結果をそのまま採用する方式から離れ、多数の候補解を生成した後に別の検証器で順位付けする構成を示した[9]。生成器は候補を広く出す役割を持ち、検証器は候補同士を比較して選ぶ役割を持つ。生成と選別を分けることで、生成器が一回で最良解を選び切る必要がなくなる。

この構成で変わるのはモデルの知識量そのものではなく、生成された候補の扱い方である。同じ生成器が複数の候補を出した場合、一件目をそのまま採用する方式と、候補を比較して最も高い評価を得たものを採用する方式では、最終的に利用される答えが変わる。生成能力が同じでも、候補を確定する検証契約を追加すると、運用結果を改善できる余地が生まれる。

構成 生成器の役割 検証器の役割 失敗し得る場所
単一回答 一つの回答を生成し、その回答がそのまま最終候補になる。 明示的な選別器を置かない。 生成時に選択した誤答がそのまま採用される。
複数候補と検証器 複数の候補解を生成する。 候補を比較し、評価の高いものを選択する。 正解候補を生成できない場合と、検証器が誤った候補を選ぶ場合がある。

検証契約を置く場所は、完成した回答の後だけとは限らない。Let’s Verify Step by Step は、最終結果だけに報酬を与える結果監督と、途中の推論段階ごとに評価を与える過程監督を比較した[10]。MATH の代表的なテスト部分集合では、過程を監督したモデルが 78% を解き、研究では過程監督が結果監督を上回ったと報告されている。

二つの方式では、最終的に数学問題を解くという目的は共通しているが、どこへ学習信号を返すかが異なる。最終回答だけを評価する場合、途中で不適切な推論をしていても最後の答えが一致すれば成功として扱える。推論段階ごとに評価する場合は、途中の誤りへ直接フィードバックを返せるため、最終結果へ至る過程そのものが学習対象になる。

監督方式 評価する単位 学習信号が示すこと 残る制約
Outcome supervision 最終回答を一つの単位として評価する。 最終結果が正解だったかを直接示す。 途中のどの推論が成功や失敗に寄与したかを局所化しにくい。
Process supervision 途中の推論段階ごとに評価する。 どの推論段階が適切だったかを細かく示せる。 各段階を正しく判定する検証器や人間評価の品質が必要になる。

ここでも、検証単位を細かくすれば自動的に信頼性が上がるわけではない。過程を監督するには、途中の推論について何を正しいと判定するかを定義し、その判定自体を信頼できる必要がある。最終結果だけを見る方式では見えなかった誤りを観測できる一方、途中過程を評価する検証器が新しい判断主体として加わる。検証契約を細かくすると、確認可能な範囲と同時に、検証器側で管理すべき条件も増える。

検証器を人間のレビュー工程へ組み込む方式もある。OpenAI の CriticGPT は、ChatGPT が生成したコードを読み、誤りや問題点を指摘する批評を生成して人間のレビューを支援する[11]。実験では、CriticGPT の支援を受けた人間による批評が、支援なしの人間による批評より好まれたケースが 60% を超えた。一方、CriticGPT 自身が誤った問題点を生成する場合も報告されている。

この方式では、AI が生成物を作り、別の AI が問題候補を提示し、人間が最終的な判断を行う。検証契約を完全に自動化する代わりに、検証器を人間の観測能力を補う道具として配置している。人間が見落とす可能性のある問題を CriticGPT が提示できる一方、CriticGPT の指摘もそのまま確定事項にはならない。批評を追加の証拠として利用し、人間が採否を判断するという契約になる。

役割 担当する処理 その結果から言えること 次に必要な判断
生成モデル コードや回答などの成果物を生成する。 要求に対する候補成果物を得られる。 成果物に誤りが含まれているかを確認する。
CriticGPT 生成された成果物から問題候補を指摘する。 人間が確認すべき箇所を追加で提示できる。 指摘が実際の問題であるかを確認する。
人間 成果物と批評を確認し、最終的な採否を判断する。 複数の情報源を使って成果物を受理できる。 人間自身の見落としや判断基準のばらつきは残る。

これらの事例では、生成能力と、生成された結果を確定する能力が分離されている。Training Verifiers では候補生成と順位付け、Let’s Verify Step by Step では推論と段階評価、CriticGPT では生成と批評が別の役割として構成される。どの方式でも、モデルが一度出した回答をそのまま最終結果として扱う代わりに、別の判定点を設けている。

既稿「AI に仕事を任せるには、モデルの外側を設計する」でも、実務を最後まで進めるには、生成器だけでなく、観測、実行環境、状態、完了条件、人間へ返す条件まで含む外側の構造が必要になると整理した[12]。AI がコードを生成できても、そのコードを実行する環境、実行結果を観測する手段、処理が完了したと判定する条件、異常時に人間へ戻す条件がなければ、業務全体を閉じた処理として成立させにくい。

検証契約は、この外側の構造の中で「何を満たしたら次の状態へ進めるか」を決める。テスト成功を条件にコードを確定する、引用監査を通った回答だけを利用する、原因診断が正解条件と一致した場合だけ報酬を与えるといった形で、生成物と次の処理の間に判定点を置く。モデルは候補を生成し、検証契約は状態遷移の条件を決める。

システム要素 役割 検証契約との関係
生成 回答、コード、診断結果などの候補を作る。 検証対象となる成果物を供給する。
観測 実行結果、検索結果、引用資料、状態変化などを取得する。 判定規則が参照する証拠を供給する。
検証 成果物と証拠を判定規則へ照合する。 契約を満たしたかを判定する。
確定 合格した成果物を次の処理や人間へ渡す。 検証結果を実際の状態遷移へ反映する。
返却 自動処理で確定できない事例を人間へ戻す。 検証契約の範囲外を無理に自動確定することを防ぐ。

この構造から見ると、AI の信頼性はモデルのパラメーターだけに宿る性質ではなく、生成、観測、検証、確定をどの順序で接続したかというシステム属性になる。より高性能なモデルは、契約を満たす候補を生成する確率を高められる。一方、どの候補を成功として受理するか、どの失敗を検出するか、どの条件で人間へ戻すかはモデル外部の構造が決める。

一件目の出力をそのまま採用する方式、複数候補を検証器で選別する方式、推論途中へ評価を置く方式、人間と Critic を組み合わせる方式では、最終的に確定される成果物が変わる。検証単位、判定位置、確定条件は、モデル能力とは別にシステム全体の結果へ影響する。

ただし、検証構造を追加するほど自動的に現実の正しさへ近づくわけではない。候補を選ぶ検証器、途中過程を採点する評価器、問題点を指摘する Critic は、それぞれ別の誤判定を持ち得る。生成器の外へ検証器を置くと、信頼性の問題が消えるのではなく、次は「その検証器をどこまで信頼できるか」という問いへ移る。次章では、この検証器そのものが現実の正しさをどこまで代理できるかを扱う。

6. 検証器も現実そのものではない

検証契約を明示すると、何を満たせば合格とするかを固定できる。同時に、その合格が保証する範囲も明確になる。検証器が判定しているのは、現実世界に存在する「正しさ」そのものではなく、観測可能な情報を判定規則へ当てはめた結果である。どの情報を観測し、どの基準で評価するかによって、検証器が扱える正しさの範囲が決まる。

この境界は、検証器の種類によって異なる。大規模言語モデルを評価者として使う場合は評価モデル自身の選好や偏りが入り、報酬モデルを使う場合は学習済みの評価基準が判定を規定する。形式的な照合では判定規則を固定しやすい一方、その規則が現実の要求を十分に表しているかという別の問題が残る。

検証方式 判定に使う情報 確認できること 残る境界
LLM-as-a-Judge 評価対象の回答を別の大規模言語モデルへ提示する。 文章品質や有用性など、人間の判断に近い評価を大量に実行できる。 提示順、文章量、自己類似性など、評価モデル固有の偏りが判定へ入る。
報酬モデル 学習済みの選好モデルで回答を比較する。 人間の選好を近似した学習信号を自動生成できる。 報酬モデルが学習した基準と、本来求める品質との対応を別途評価する必要がある。
GANDR の Critic 質問、検索済み資料、完成した法律回答を照合する。 主張と引用との対応を局所的に監査できる。 意味的な支持関係を判定する Critic 自身の精度が保証範囲を制約する。
TRACE の正解ラベル 問題生成時に保存した介入と診断結果を比較する。 シミュレーター内部では原因診断を決定的に採点できる。 定義した原因体系と現実世界の原因構造との対応が別の評価対象になる。

大規模言語モデルを評価者として使う LLM-as-a-Judge は、この境界を観察しやすい例である。GPT-4 のような強い判定モデルは、人間の選好と 80% を超える一致を示す一方、回答の提示順、文章量、自分と似た出力への選好などの偏りも報告されている[13]。人間の判断を一件ずつ集める代わりに自動評価を大量実行できることは大きな利点だが、その判定結果には評価モデル自身の性質が入り込む。

たとえば、二つの回答の内容が近くても、先に表示された回答を選びやすい傾向があれば、評価対象の品質とは独立した要因が順位へ影響する。文章量の多い回答を高く評価する傾向があれば、簡潔で正確な回答より冗長な回答が有利になる場合もある。評価器が一貫した基準で採点しているように見えても、その基準の中へ対象外の特徴が混ざれば、合格結果と本来測りたい品質との間にずれが生じる。

偏り 判定へ入る要因 本来評価したい性質とのずれ
提示順 回答を表示する順序が選好へ影響する。 内容が同じでも提示位置によって評価が変わる可能性がある。
文章量 長い回答が高く評価されやすい場合がある。 正確性や有用性より情報量そのものが評価へ混入する可能性がある。
自己類似性 評価モデル自身に近い出力を好む傾向が生じる。 一般的な品質よりモデル固有の表現傾向が有利になる可能性がある。

この構造は、報酬モデルにもそのまま現れる。RewardBench は、RLHF などで利用される報酬モデルそのものを評価対象へ置いた[14]。チャット、推論、安全性などの比較課題を使い、どの回答をより好ましいと判定するかを測る。回答を生成するモデルを評価するために報酬モデルを使い、その報酬モデルの性能をさらに別のベンチマークで測るという階層になる。

ここでは、「モデルを評価するモデルにも評価が必要になる」という循環が生じているように見えるが、実際には役割を分けて考えればよい。生成モデルは候補を作り、報酬モデルは候補へ選好スコアを付ける。RewardBench は、その報酬モデルが人間の期待する選好とどの程度対応するかを測る。各段階で異なる検証契約を置くことで、どの判断主体にどの誤差が入るかを切り分けられる。

層 役割 評価対象 次に確認すること
生成モデル 回答候補を生成する。 要求に沿った回答を作れるかを評価する。 生成した候補の品質を誰がどう判定するかを決める。
報酬モデル 複数の回答候補を比較し、好ましさを判定する。 人間の選好をどの程度再現できるかを評価する。 報酬モデル自体の偏りや失敗条件を確認する。
RewardBench 報酬モデルを共通課題で比較する。 複数領域での判定能力を測る。 ベンチマーク自体が実運用の品質をどこまで代表するかを確認する。

GANDR へ戻ると、同じ境界が一つのシステム内部に現れている。strict correctness が直接確認するのは、正しい判断に加えて、すべての引用が検索器の返した資料へ解決できることである[3]。引用識別子と検索済み資料との対応は、比較的明確な規則で確認できる。存在する識別子へ解決できるかという判定には、意味解釈をほとんど必要としない。

主張と引用との意味的な対応まで扱うと、判定の性質が変わる。Critic は各主張が引用資料によって十分支持されるかを監査するが、論文では詳細な 4 段階の判定ラベルと法律専門家との一致が弱かったと報告されている[3]。参照先を解決する処理から、文章同士の意味関係を評価する処理へ移ると、検証器の判断能力そのものが結果へ影響する。

GANDR の判定 判定の性質 確定しやすさ 保証範囲
引用の解決可能性 識別子と検索済み資料との対応を確認する。 比較的決定的に判定できる。 引用先が検索結果として存在することを確認できる。
主張と引用の支持関係 資料の内容が主張を十分に支えるかを意味的に評価する。 評価モデルの判断精度へ依存する。 Critic が支持関係を認めたことを確認できる。
法律上の妥当性 回答全体として適切な法律判断へ到達したかを評価する。 ベンチマークの正解定義へ依存する。 評価対象となった法律問題に対する判断の正しさを確認できる。

TRACE では、検証器の判定自体はより決定的である。問題生成時に注入した原因を保存しているため、エージェントがその原因を回答したかどうかを直接比較できる[8]。この意味では、GANDR の Critic のような意味判定よりも、正解ラベルとの一致を機械的に確認しやすい。

一方、判定が決定的であることと、現実世界を十分に表していることは別の性質である。TRACE の正解は、定義された 12 種類の原因体系とシミュレーターの内部では客観的である。しかし、現実の広告システムには定義外の原因、複数原因の重なり、外部環境の変化などが存在し得る。シミュレーター内部の診断精度は、シミュレーターで表現した世界に対する能力を示し、その世界と実運用との対応は別の検証契約になる。

対象 内部で確定できること 外部で追加確認すること
LLM-as-a-Judge 評価モデルが定めた基準に基づく選好を大量に取得できる。 その選好が人間の判断や実運用品質と対応しているかを確認する。
報酬モデル 学習済みの選好関数に基づいて回答を順位付けできる。 選好関数が本来求める品質を十分に代理しているかを確認する。
GANDR 引用の解決可能性や Critic による支持判定を取得できる。 意味判定の精度と、検索できなかった証拠の影響を確認する。
TRACE 注入した原因と診断結果との一致を決定的に採点できる。 シミュレーターの原因体系と現実世界との対応を確認する。

四つの事例で共通するのは、検証器の合格が必ず特定の観測条件と判定規則に結び付いていることである。LLM-as-a-Judge は評価モデルの選好、報酬モデルは学習済みの選好関数、GANDR は検索済み資料と Critic の判定、TRACE はシミュレーターへ注入した原因を基準にする。それぞれの契約内部では再現可能な評価を作れるが、契約の外側にある品質まで同じ判定で確定することはできない。

これは検証器の欠点というより、検証という行為そのものが持つ境界である。検証器は、広い意味での正しさを扱える形へ縮約する。文章品質なら選好比較、法律回答なら引用と主張の対応、原因診断なら保存済みの原因との一致というように、対象を観測可能な条件へ変えることで判定が成立する。縮約した範囲が明確であれば、合格という結果から何を言えるかも明確になる。

検証契約の価値は、「合格したから正しい」と一括して結論づけることではなく、「どの条件について、どの検証器が、どの証拠を使って合格と判定したか」を追跡できる点にある。検証器の出力を読むときに必要なのは、合格というラベルそのものより、合格条件と保証範囲との対応である。

ただし、ここにはもう一つの問題が残る。検証器が一定の基準を返し続けると、学習する側はその基準へ適応できる。検証契約が現実の品質を代理している限り、その最適化は有効である。一方、代理指標だけを強く最適化すると、契約上の得点と本来求める品質との対応が崩れる場合がある。次章では、検証契約そのものが最適化対象になったときに何が起きるかを見る。

7. 固定された検証契約は攻略され、劣化する

検証契約には時間軸がある。ある時点で品質をよく表していた判定規則でも、その規則を学習の報酬として繰り返し使い、モデル自身が規則へ適応すると、得点と本来ほしかった品質との対応が変わる。また、モデル側が変化しなくても、評価データの公開、訓練データへの混入、テスト設計上の欠陥の発見によって、同じ検証契約が以前と同じ意味を持たなくなる場合がある。

ここでは、この二つを分けて考える必要がある。一つは、モデルが固定された判定規則へ適応することで起きる最適化による劣化である。もう一つは、評価対象やデータ環境の変化によって、検証契約と測りたい能力との対応が崩れる評価基盤の劣化である。

変化の型 何が変わるか 検証契約に起きること 代表例
代理指標への過剰最適化 モデルが判定規則から高得点を得る特徴へ適応する。 契約上の得点と本来求める品質との対応が弱まる。 報酬モデルの過剰最適化。
固定評価基準への適応 同じ評価項目を報酬として反復利用する。 学習に使う評価器の評価は上がっても、別の評価器による品質が低下する。 Rubric Dropout が測定した報酬ハッキング。
評価データへの曝露 公開された問題や解答が訓練データへ混入する。 未知課題を解く能力と既知情報の再現がスコア上で混ざる。 SWE-bench Verified の訓練データ汚染。
検証条件の欠陥発見 問題文やテストケースに不足や過剰制約が見つかる。 正しい解を失敗と判定したり、評価対象の能力を正確に測れなくなったりする。 SWE-bench と SWE-bench Verified の再監査。
評価対象の能力向上 以前より高性能なモデルが同じ評価を受ける。 残っている問題の品質や難易度が評価値を支配し、上位モデル間の差を読み取りにくくなる。 最先端モデルのコーディング能力に対する SWE-bench Verified。

最初の二つは、検証契約を学習の目標として使うことで生じる。報酬モデルの過剰最適化を調べた研究では、人間の選好を近似する代理報酬モデルを強く最適化すると、代理報酬の値は上がる一方、より真の評価に近い基準報酬が一定点を境に悪化する関係が測定された[15]。モデルは報酬として与えられた規則へ適応するため、その規則が本来の品質を完全には表現していない場合、両者の差まで学習対象になる。

この構造では、検証器が誤作動している必要はない。代理報酬モデルは、自分に与えられた判定規則に従って一貫して得点を返している。それでも、代理報酬が本来ほしい品質の近似である以上、最適化を進めるほど近似誤差を利用できる余地が生まれる。合格条件が品質の一部だけを観測しているなら、モデルはその観測部分を改善しながら、観測されていない部分の品質を落とすことができる。

段階 代理報酬 基準報酬 解釈
最適化初期 上昇する。 上昇する。 代理指標の改善が本来の品質改善と対応している。
一定の最適化後 さらに上昇する。 改善幅が小さくなる。 代理指標が捉える性質と本来の品質とのずれが表面化し始める。
過剰最適化 上昇を続ける。 低下する場合がある。 モデルが品質そのものより代理指標に特有の特徴へ適応している。

2026 年の Rubric Dropout は、この現象を評価基準と LLM 評価器を使う強化学習で直接測った[16]。評価基準は、回答に求める条件を複数の評価項目として記述し、それぞれを LLM 評価器が採点する仕組みである。正解を一意に定めにくい医学や科学の回答でも、評価項目を固定すれば報酬を生成できる。その一方で、その評価基準自体が品質の代理指標になる。

研究では Qwen3-8B を固定評価基準で学習すると、学習時に使う評価器のスコアは上昇を続けた一方、より強い基準評価器の評価は途中で頂点を迎え、その後低下した。HealthBench-Hard では頂点から 3 ポイント、ResearchQA では 22 ポイント低下している[16]。同じ回答を評価する二つの評価器が一定量だけずれているのではなく、学習が進むほど一方が上昇し、もう一方が低下するため、固定された評価規則への適応として観測できる。

観測 学習時評価器 基準評価器 意味
学習初期 スコアが上昇する。 スコアも上昇する。 評価基準の最適化が分布外の品質改善にもつながっている。
学習継続 さらに上昇する。 頂点へ到達する。 固定評価基準が表現する品質と、より広い評価との対応が弱まり始める。
過適応後 上昇を続ける。 HealthBench-Hard で 3 ポイント、ResearchQA で 22 ポイント低下する。 モデルが評価基準で高く評価される特徴を学習し、その改善が広い品質改善へ対応しなくなる。

Rubric Dropout は、この固定性そのものを崩す。各学習ステップで評価基準の一部をランダムに外して報酬を計算することで、モデルが毎回まったく同じ評価項目へ最適化される状態を避ける。30% または 50% のドロップアウトを使った条件では、分布外の基準評価スコアが同じ学習段階のドロップアウトなし条件より高くなり、ResearchQA では 6 から 7 ポイントの改善が報告されている[16]。

ここで検証契約そのものを消しているわけではない。評価項目という契約は維持したまま、学習時に毎回使う部分集合を変えることで、特定の判定規則だけへ適応する利益を減らしている。検証契約を報酬として利用する場合、その契約の内容だけでなく、モデルが契約をどの程度観測し、反復して最適化できるかまで設計対象になる。

一方、検証契約はモデルによる最適化がなくても劣化する。SWE-bench は、実際の GitHub issue と、それを解決した pull request から 2294 件のソフトウェア工学課題を構築した[17]。モデルやエージェントへ issue の説明と修正前のリポジトリを与え、コードを変更させる。評価時には、修正前には失敗し、正解の変更後には成功する FAIL_TO_PASS テストと、既存機能が壊れていないことを確認する PASS_TO_PASS テストを実行する。

これは、現実のソフトウェア修正を再実行可能な検証契約へ変換した例である。issue の要求を満たし、対象テストを通し、既存のテストも維持できれば、その課題を解決したものとして採点できる。しかし、この契約が意味を持つには、問題文が必要な要求を十分に記述し、テストが妥当な解を受理し、不正な解を拒否する必要がある。

2024 年には、その前提自体が再監査された。OpenAI と SWE-bench の研究者は、元の SWE-bench から 1699 件を専門のソフトウェア開発者によって確認し、各問題を 3 人が独立して評価した[18]。問題記述が不足している課題や、妥当な実装を失敗と判定するテストなどを除外し、最終的に 500 件からなる SWE-bench Verified を構築した。

段階 検証契約 見つかった課題 対応
SWE-bench GitHub issue とテストを使ってコード修正を採点する。 仕様不足や、妥当な解を拒否するテストを含む課題が存在した。 人間による課題単位の再監査へ進んだ。
SWE-bench Verified 人間が問題文とテストの妥当性を確認した 500 問を使う。 元の評価より問題品質を改善した。 最先端モデルの評価へ広く使われるようになった。
2026 年の再監査 高性能モデルが安定して解けない残存問題を詳細に調査する。 テスト設計、問題記述、データ汚染などが評価信号へ影響していた。 最先端モデルのコーディング能力の主要指標としての利用を終了した。

2026 年 2 月には、SWE-bench Verified 自体が再び監査対象になった。OpenAI は、OpenAI o3 が 64 回の独立実行で安定して解けなかった 138 問を調査し、それぞれを少なくとも 6 人の経験あるソフトウェアエンジニアに確認させた[19]。その結果、138 問の 59.4% に、テスト設計または問題記述上の重要な問題が存在すると報告している。

たとえば、機能上は正しい複数の実装が可能なのに、テストが特定の実装方法だけを要求すると、妥当な解答を不正解として扱う。問題文が複数の解釈を許すのに、テストがそのうち一つだけを正解として固定する場合も同じである。さらに、OS や Python のバージョンなど実行環境の差によって、本来の修正内容とは無関係にテストが失敗する場合も確認された[19]。

これに加えて、SWE-bench Verified は公開された GitHub リポジトリ、issue、pull request から構築されているため、課題や解答情報がモデルの訓練データへ含まれる可能性が時間とともに高まる。ベンチマークの点数が上昇しても、未知のソフトウェア問題を解く能力の向上と、学習済み情報を利用した結果とを分離しにくくなる。この汚染は、テストそのものが正しくても評価の意味を変える。

劣化要因 スコアへ与える影響 失われる解釈
過度に狭いテスト 機能的に正しい別実装を失敗として扱う。 失敗がモデル能力不足を意味するとは限らなくなる。
問題記述の不足 テストが要求する実装を問題文から一意に導けない。 課題解決能力と、隠れた要求を推測する能力が混ざる。
実行環境依存 コード変更とは独立した理由でテストが失敗する。 テスト失敗を修正失敗として直接解釈できなくなる。
訓練データ汚染 既知の課題や解答への曝露によってスコアが上昇し得る。 未知課題への一般的な問題解決能力を分離して測りにくくなる。
モデル能力の向上 残った少数の不良課題が全体スコアやモデル間差へ与える影響が大きくなる。 ベンチマーク全体の得点を最先端モデルの能力差として読み取りにくくなる。

SWE-bench Verified は、2024 年に元の SWE-bench の検証契約を改善するために作られた。その改善版でさえ、2026 年には評価対象の能力向上、残存するテスト設計上の問題、公開データへの曝露によって、最先端モデルのコーディング能力を測る指標としての意味が弱まった[19]。これは、2024 年の設計が誤りだったことを意味するのではなく、検証契約と評価対象との関係が時間とともに変化したことを示している。

Rubric Dropout と SWE-bench Verified は、異なる経路から同じ問題へ到達する。前者では、モデルが固定された契約へ適応することで、契約上の得点と外部評価が乖離した。後者では、評価対象とデータ環境が変化し、さらに契約内部の欠陥が再発見されたことで、同じスコアの意味が変化した。検証契約は、固定された規則であっても、その規則と現実との対応まで固定されるわけではない。

このため、検証契約にはモデルとは別のライフサイクルが必要になる。判定規則を作った時点で終えるのではなく、モデル能力の変化、評価データへの曝露、誤判定事例、未知の実装方法、運用環境の変化を継続的に調べる。合格した結果が本来求める品質と対応しているかを再監査し、その対応が崩れた時点で、評価データ、検証器、閾値、採点条件を更新する必要がある。

検証契約は、AI を固定された物差しで測るための静的な仕様というより、測定対象との対応を維持するための運用対象である。モデルを更新すれば再評価が必要になり、評価データが広く知られれば汚染を確認する必要が生じ、検証器の弱点が見つかれば判定規則そのものを修正する必要がある。信頼性を維持するには、AI の出力だけでなく、AI を合格と判定する仕組みも継続して監査することになる。

8. AI の信頼性は検証契約の射程で読む

GANDR と TRACE は、対象分野も実装方式も異なる。GANDR は法律回答を主張と引用へ分解し、生成後の成果物へ検証条件を置く。TRACE は原因を先にシミュレーターへ注入し、問題生成時に正解を保存する。検証可能性を作る位置は異なるが、自然状態では判定しにくい「正しさ」を、機械的または再現可能に確認できる条件へ変換している点は共通している。

ここまで扱ってきた事例を、検証契約という一つの軸で整理すると次のようになる。

事例 検証契約を置く場所 合格条件 主に保証できる範囲 契約の外側に残るもの
ソフトウェアテスト 生成または変更されたコードの実行後に置く。 指定された入力、期待結果、実行条件の下でテストを通過する。 テストへ変換した要求について期待された挙動を確認できる。 テストへ含めていない仕様、性能、運用条件などが残る。
形式証明 形式化された命題と証明項の検査段階に置く。 形式体系の規則に従って証明項が型検査を通過する。 形式化された命題が指定された体系内で導出可能であることを確認できる。 形式命題と人間が意図した主張との対応が残る。
GANDR 法律回答の生成後に置く。 最終判断、引用の解決可能性、主張と証拠の対応を確認する。 回答のどの部分がどの根拠によって支持されているかを追跡できる。 検索漏れや Critic の意味判定精度が残る。
TRACE 診断問題を生成する段階に置く。 エージェントの診断結果が保存済みの原因と一致する。 シミュレーター内部の原因体系に対する診断能力を評価できる。 シミュレーターと現実の原因分布との対応が残る。
LLM-as-a-Judge 生成された回答の評価段階に置く。 評価モデルが定めた基準で高い評価を得る。 大規模な回答集合を一定の基準で比較できる。 評価モデル固有の偏りと、人間の判断とのずれが残る。
SWE-bench Verified 実世界のコード修正課題を採点する段階に置く。 課題ごとに定められたテストを通過する。 その課題とテストが表現する修正要求への対応を測定できる。 問題文やテストの欠陥、データ汚染、評価対象の変化が残る。

この一覧から分かるのは、「検証済み」という状態が一種類ではないことである。テストを通ったコード、Lean が受理した証明、引用監査を通った法律回答、保存済みの原因と一致した診断結果は、いずれも検証済みと呼べる。しかし、それぞれが確認している対象、判定規則、保証範囲は異なる。検証という語だけを共通化しても、契約の中身を見なければ合格の意味は比較できない。

この構造は、AI を使ったシステム開発全般へ広げられる。生成器の性能が上がると、回答、コード、設計案、診断候補を作る時間は短くなる。その後に残るのは、候補が要求を満たしたと判断する工程である。既稿「AI モダナイゼーションはなぜ仕様選択と検証で止まるのか」でも、既存コードの解析や変換が高速化した後、どの挙動を保存すべき仕様として選び、その仕様をどの証拠で確認するかが工程上の制約として残ることを論じた[20]。

生成能力の向上によって、この制約はむしろ見えやすくなる。人間が一件ずつコードを書く段階では、生成そのものが長い工程を占めていた。AI が短時間で複数の候補を生成できるようになると、どの候補を採用するか、既存挙動を保存しているか、テスト結果を十分な証拠として扱えるかという判断工程の割合が大きくなる。生成の速度が上がるほど、受理条件の曖昧さが次の待ち時間として表面化する。

工程 生成能力が低い場合 生成能力が高い場合 残る制約
候補生成 成果物を作ること自体に多くの時間を使う。 複数の候補を短時間で生成できる。 どの候補を採用するかを決める必要がある。
仕様選択 生成作業と並行して人間が判断する。 生成速度に対して仕様判断が相対的に遅くなる。 何を保存し、何を変更してよいかを固定する必要がある。
検証 生成量が少ないため人手でも追跡しやすい。 大量の生成物へ同じ確認を適用する必要がある。 自動化可能な判定規則と、人間判断へ残す範囲を分ける必要がある。
確定 人間が生成と採否をまとめて担う場合が多い。 生成と採否を別工程として設計する必要が高まる。 どの証拠が揃えば成果物を確定できるかを明示する必要がある。

このとき、AI の信頼性を「モデルがどれほど賢いか」という一軸で表すと、生成能力と確定条件が同じ評価へ混ざる。高性能なモデルは正しい候補を生成する確率を高められる。一方、その候補を業務上の成果物として採用してよいかは、検索結果、テスト、引用、形式検査、別モデルの評価、人間レビューなど、モデル外部の証拠によって決まる。

検証契約は、この生成能力と確定条件を接続する。何を検証対象とし、どの粒度で判定し、どの条件を満たせば受理し、その合格からどの性質までを確認済みとするかを定める。モデルは契約を満たす候補を生成し、検証器は契約に照らして候補を判定し、システムは合格した候補を確定する。この三つを分けることで、「高性能なモデルを使っている」という説明から、「どの条件まで確認した成果物を利用しているか」という説明へ進める。

観点 モデル能力を見る場合 検証契約まで見る場合
評価対象 モデルがどれだけ正しい出力を生成するかを見る。 生成した出力をどの条件で受理するかまで見る。
代表指標 正答率、ベンチマーク得点、成功率などを使う。 判定規則、検証単位、通過条件、保証範囲も確認する。
一件の出力への判断 モデル全体の成功確率から品質を推定する。 個々の出力が契約を満たしたかを確認する。
失敗時の分析 モデルが誤答したという単位で扱いやすい。 生成、検索、引用、検証、確定のどこで条件を満たさなかったかを分けられる。
保証の説明 モデル性能を中心に説明する。 何を確認済みとし、どこから別の確認が必要かを説明する。

契約を広くすれば、そのまま信頼性が高まるという関係でもない。狭い契約は、確認対象を限定する代わりに、比較的決定的な判定を置きやすい。引用識別子が取得済み資料へ解決できるか、テストが成功したか、形式証明が型検査を通過したかという条件は、機械的に判定しやすい。一方、文章が主張を十分に支持しているか、回答が人間にとって有用か、シミュレーターが現実を十分に代表しているかという広い条件には意味判断やモデル化が入り、検証器自身の誤差も大きくなる。

この関係は、検証契約の設計を「厳しいか緩いか」という一軸で比べにくい理由でもある。必要なのは、実際に保証したい性質を分解し、それぞれをどの程度決定的に確認できるかを対応付けることである。自動テストで確認できる条件は自動テストへ置き、意味判断が必要な条件は別モデルや人間レビューへ置く。未知の条件や判断材料が不足する場合には、自動確定を止めて人間へ返すという契約も選べる。

契約の性質 利点 主な制約 適した使い方
狭く決定的な契約 同じ入力に対して再現可能な判定を返しやすい。 保証できる性質が限定される。 テスト、形式検査、識別子照合などへ使う。
広く意味的な契約 人間が求める品質へ近い性質を扱える。 評価器の偏りや解釈差が判定へ入る。 文章品質、根拠の十分性、有用性などの評価へ使う。
シミュレーションによる契約 現実では取得しにくい正解ラベルを大量に生成できる。 シミュレーターと現実との対応が保証範囲を制約する。 原因診断や反復学習の訓練環境へ使う。
人間を含む契約 形式化しにくい条件や例外を扱える。 処理量、判断のばらつき、確認コストが生じる。 自動検証で確定できない境界事例の最終判断へ使う。

さらに、第 7 章で見たように、検証契約には時間による変化もある。固定された評価基準を報酬として使えばモデルがその評価基準へ適応し、代理指標と外部評価が乖離する場合がある。SWE-bench Verified のように、作成時には妥当だった評価契約でも、問題文やテストの再監査、公開データへの曝露、モデル能力の向上によって、数年後には同じスコアの意味が変わる。検証契約の保証範囲は、契約を定義した時点だけで決まるものではなく、評価対象との対応が維持されているかによっても変化する。

このため、AI システムの信頼性を維持するには二つの監査が必要になる。一つは、個々の成果物が検証契約を満たしているかという出力の監査である。もう一つは、その検証契約自体が現在も保証したい品質を適切に表しているかという契約の監査である。前者だけを実施すると、古くなった評価基準へ正確に適合した成果物を大量に作ることもできてしまう。

監査対象 問うこと 失敗した場合に起きること
AI の出力 現在の検証契約が定める条件を満たしているか。 個々の成果物に誤りや根拠不足が残る。
検証器 定められた判定規則を十分な精度で実行できているか。 正しい成果物を拒否したり、誤った成果物を合格させたりする。
検証契約 合格条件が現在も実際に保証したい品質と対応しているか。 契約上の得点だけが改善し、実運用で必要な品質との乖離が生じる。

ここまでの議論から、AI の信頼性を「絶対に正しい状態」として定義する必要はないことが分かる。実用上必要なのは、どの性質についてどの程度の証拠を要求し、その証拠が揃ったときにどこまでを確認済みと扱うかを説明できることである。検証契約が明確であれば、保証範囲と未確認領域を同時に示せる。

AI システムを評価するとき、正答率やベンチマーク得点だけを見ると、合格という結果を成立させている条件が隠れる。GANDR の 70.8% という数字には strict correctness の定義があり、TRACE の 0.757 という数字には保存された原因と属性との照合規則がある。SWE-bench の得点には issue とテストから構成された評価契約があり、LLM-as-a-Judge の評価には評価器が採用する選好基準がある。数字を比較するには、その数字を生成した契約まで読む必要がある。

AI の信頼性は、モデルの正答確率に加えて、何を検証対象とし、どの粒度で判定し、何を合格条件とし、その結果から何を保証するかという検証契約によって定まる。実運用で「信頼できる」と呼べる範囲は、その契約の保証範囲で決まる。そして、その契約が現在も現実の要求を代理しているかを継続して監査することで、その信頼性を維持できる。

モデルを見るときには、モデルの能力を見る。AI システムを見るときには、その出力を何が合格と判定しているかまで見る。AI の信頼性は検証契約によって定義され、その契約の射程によって読むべきものである。

参考文献

  1. id774, AI がテストを通しても、「正しい」とは限らない（2026-09-01）. https://blog.id774.net/entry/2026/09/01/5534/
  2. id774, フェルマーの最終定理の形式化で、AI が生成した証明を Lean がどう検証したか（2026-09-07）. https://blog.id774.net/entry/2026/09/07/5616/
  3. Chen Qian, Yimeng Wang, Yu Chen, Lingfei Wu, Andreas Stathopoulos, GANDR: Claim Auditing for Verifiable Legal Answer Generation（2026-09-09）. https://arxiv.org/abs/2609.10293v1
  4. Sewon Min et al., FActScore: Fine-grained Atomic Evaluation of Factual Precision in Long Form Text Generation（2023-05-23）. https://arxiv.org/abs/2305.14251
  5. Yifei Li, Xiang Yue, Zeyi Liao, Huan Sun, AttributionBench: How Hard is Automatic Attribution Evaluation?（2024-02-23）. https://arxiv.org/abs/2402.15089
  6. Cheng Niu et al., RAGTruth: A Hallucination Corpus for Developing Trustworthy Retrieval-Augmented Language Models（2023-12-31）. https://arxiv.org/abs/2401.00396
  7. Nicholas Pipitone, Ghita Houir Alami, LegalBench-RAG: A Benchmark for Retrieval-Augmented Generation in the Legal Domain（2024-08-19）. https://arxiv.org/abs/2408.10343
  8. Rui Sun, Zhan Shi, Bing He, TRACE: Training Reasoning Agents for Causal Exploration with Synthesized Rewards（2026-09-09）. https://arxiv.org/abs/2609.10315v1
  9. Karl Cobbe et al., Training Verifiers to Solve Math Word Problems（2021-10-27）. https://arxiv.org/abs/2110.14168
  10. Hunter Lightman et al., Let’s Verify Step by Step（2023-05-31）. https://arxiv.org/abs/2305.20050
  11. OpenAI, Finding GPT-4’s mistakes with GPT-4（2024-06-27）. https://openai.com/index/finding-gpt4s-mistakes-with-gpt-4/
  12. id774, AI に仕事を任せるには、モデルの外側を設計する（2026-08-21）. https://blog.id774.net/entry/2026/08/21/5544/
  13. Lianmin Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（2023-06-09）. https://arxiv.org/abs/2306.05685
  14. Nathan Lambert et al., RewardBench: Evaluating Reward Models for Language Modeling（2024-03-20）. https://arxiv.org/abs/2403.13787
  15. Leo Gao, John Schulman, Jacob Hilton, Scaling Laws for Reward Model Overoptimization（2022-10-19）. https://arxiv.org/abs/2210.10760
  16. Minglai Yang et al., Rubric Dropout: A Simple Way to Mitigate Reward Hacking in Rubric-as-Reward RL（2026-08-12）. https://arxiv.org/abs/2608.11669
  17. Carlos E. Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?（2023-10-10）. https://arxiv.org/abs/2310.06770
  18. OpenAI, Introducing SWE-bench Verified（2024-08-13）. https://openai.com/index/introducing-swe-bench-verified/
  19. OpenAI, Why SWE-bench Verified no longer measures frontier coding capabilities（2026-02-23）. https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
  20. id774, AI モダナイゼーションはなぜ仕様選択と検証で止まるのか（2026-07-29）. https://blog.id774.net/entry/2026/07/29/5158/