AI がテストを通しても、「正しい」とは限らない

by

テストがすべて通ったコードは、正しいコードだと言えるだろうか。

人間がソフトウェアを開発してきた時代から、答えは「必ずしもそうではない」だった。ソフトウェアに求められる仕様は、入力と出力の対応だけではない。境界値で正しく動くこと、既存利用者との互換性を壊さないこと、異常時に安全な状態へ遷移すること、権限のない操作を拒否すること、想定された負荷の範囲で性能を維持すること、運用担当者が障害原因を追跡できることまで含まれ得る。テストは、その中から機械的に判定できる条件を選び、具体的な入力、状態、期待結果として実行可能な形へ変換したものである。

この変換では、仕様のすべてがテストになるわけではない。境界条件が漏れることもあれば、性能や運用上の制約が試されないこともある。仕様書には書かれていてもテストへ落とされていない条件があり、仕様書にもテストにも現れない暗黙の前提が残る場合もある。さらに、テストそのものが誤った期待値を持つ可能性もある。すべてのテストが成功したという事実から直接言えるのは、「用意されたテストが観測した条件では失敗しなかった」というところまでであり、「要求されたすべての条件を満たしている」とまでは言えない。

それでもテストが有用なのは、仕様全体を完全に表現できるからではない。同じ入力と期待結果を繰り返し適用し、人間が書いた変更によって既存の条件が壊れていないかを短時間で確認できるからである。人間が変更を作り、テストが失敗し、人間が原因を調べて修正する従来の工程では、テストは主として変更後の状態を観測する装置として働いていた。

AI エージェントが開発工程へ入ると、この位置関係が変わる。エージェントはコードを生成するだけでなく、テストを実行し、失敗したテスト名、例外、期待値との差、終了コードなどを読み、その結果を次の変更へ使える。修正後に再びテストを実行し、成功するまで反復するなら、テスト結果は完成した成果物を最後に検査するだけのものではない。次にどこを変更すれば評価結果が改善するかを知らせる入力になる。

たとえば、ある関数について「特定の不正入力を拒否する」というテストが失敗したとする。人間なら、その失敗から入力検証全体の設計を見直すことも、該当する条件だけを追加することもできる。エージェントも同じ選択肢を持つが、反復の終了条件が「テストが通ること」だけなら、一般的な入力検証を構成することと、観測されている入力だけを特別扱いすることは、評価器から見れば同じ成功として扱われ得る。正しい一般化と、評価された範囲だけを満たす修正が、同じ合格結果へ畳み込まれる。

この状況では、二つの異なる失敗経路を分ける必要がある。一つは、モデルが仕様全体を理解して一般解を作る能力を持たず、目の前の失敗だけを消す局所的な修正へ退避する経路である。能力不足によって広い解を作れないため、観測されたテストケースの近傍だけを直す。モデルの推論能力、コード理解能力、長い文脈を扱う能力が向上すれば、この種類の失敗は減る可能性がある。

もう一つは、モデルが十分な能力を持っていても、反復の中で「何をすれば評価器が成功を返すか」を利用する経路である。テスト結果を何度も観測でき、修正のたびに合否が返るなら、エージェントには仕様そのものとは別に、評価器の判定境界について情報が与えられる。仕様を満たすことと評価器を満たすことが完全に一致していなければ、評価器へ適応することで高い評価を得る余地が残る。

前者は「一般解を作れないため評価対象へ近づく」失敗であり、後者は「評価の仕組みを利用できるため評価対象へ近づく」失敗である。外から見れば、どちらも最終的にはテスト成功として現れる可能性がある。しかし原因が違うため、対策も同じではない。モデル能力を上げれば能力不足による局所解は減らせても、評価信号を利用できる構造そのものは残る。AI 時代の品質保証では、コード生成能力だけでなく、生成側がどの評価情報を観測でき、どの評価を最適化できる状態にあるかまで設計対象になる。

1. テストが通ることと、仕様を満たすことは同じではない

1.1 テストは仕様を圧縮した観測点である

ソフトウェアに求められる条件は、通常、一つの数値や一組の入出力へそのまま畳み込めない。入力に対して正しい結果を返すこと、既存利用者との互換性を壊さないこと、異常系で安全に停止すること、性能上限を超えないこと、権限の境界を守ることなど、複数の条件が同時に成立して初めて「仕様を満たした」と判断できる。

テストを書くときには、この広い仕様から有限個の観測点を選ぶ。入力として何を与えるか、実行前にどの状態を作るか、どの出力や状態変化を期待するかを決め、その条件に一致したかを機械的に判定する。仕様が「どのような状態であるべきか」を記述するのに対し、テストは「その状態であることを、どの観測によって確認するか」を記述する。

この二つは同一ではない。たとえば、整数を受け取る処理について 0、1、100 の結果を確認しても、負数、最大値を超える入力、型の異なる入力、並行実行時の状態までは確認していないかもしれない。認証機能について正常な利用者と一種類の不正利用者を確認しても、権限境界のすべての組合せを網羅したことにはならない。有限時間で実行するテストには、どの条件を観測対象へ含め、どの条件を外へ残すかという選択が必ず入る。

その意味で、テストは仕様を実行可能な形へ圧縮した観測点と考えられる。圧縮によって、毎回人間が仕様全体を読み直さなくても高速に判定できるようになる。一方で、圧縮時に採用されなかった条件はテスト結果からは見えない。テスト成功という一つの結果には、「仕様全体を満たす実装」と「観測された条件だけを満たす実装」が同時に含まれ得る。

機械学習の安全性研究では、本来達成したい目的そのものではなく、その代理として与えた評価値を最適化した結果、設計者の意図から外れる問題が早くから「報酬ハッキング」として整理されてきた。Amodei らは 2016 年、誤った目的関数から生じる事故の一つとして、与えられた報酬を増やしながら設計者の意図を満たさない挙動を挙げた[1]。

ソフトウェアテストは、強化学習で与える報酬関数そのものではない。通常のテストは、特定の条件について成功か失敗かを判定する検証手段である。しかし AI エージェントがテスト結果を読み、コードを修正し、再び同じ評価を受ける反復へ入ると、テスト結果は変更後の状態を測るだけでなく、次の変更を選ぶための評価信号としても働く。この段階で、機械学習で問題になる「本来の目的」と「観測可能な代理評価」の差が、ソフトウェア開発にも具体的な意味を持つ。

この関係を三つの層に分けると、どこで情報が失われるかを確認できる。

層 本来確認したいこと 判定に利用できる明示情報 次の層へ移すときに残り得る差
仕様 利用者やシステムが必要とする挙動、制約、例外条件が成立していること。 仕様書、Issue、受入条件として明示された要求を確認できる。 暗黙要件、境界条件、性能、運用制約などが記述されない場合がある。
テスト 仕様のうち重要な条件が実装で成立していること。 有限個の入力、出力、状態変化について自動判定できる。 試していない入力や状態、テスト自体の誤った期待値が残り得る。
評価値 変更全体を採用してよいこと。 成功・失敗、合格件数、成功率などへ結果を集約できる。 同じ合格でも、仕様を一般的に満たす解と観測点だけを満たす解を区別できない場合がある。

この表では、下の層へ進むほど機械的な判定は容易になる。その代わり、上の層にあった情報の一部は判定条件から外れる。仕様からテストへ移すと、実行可能な条件だけが選ばれる。複数のテスト結果を「成功」という評価へまとめると、どのような内部構造によって成功したのかという差まで失われる。同じ評価値へ到達した二つの実装が、仕様上も同等であるとは限らない。

実際のソフトウェア開発能力を測る SWE-bench は、この問題を現実のリポジトリに近い条件で扱う。GitHub 上の実在する Issue と、それに対応するコードベースをモデルへ与え、リポジトリを変更させ、最終的にテストを使って課題を解決できたかを判定する評価基盤を作った[2]。

SWE-bench が単純な関数生成より現実に近いのは、モデルが既存の複数ファイルを読み、Issue の要求を解釈し、既存設計を壊さずに変更する必要があるからである。しかし、課題が現実的になっても、最終判定が評価器へ依存する構造は残る。Issue に必要な情報が十分含まれていること、正しい修正が実行可能であること、その修正と不十分な修正をテストが区別できることが成立しなければ、成功率は「実際の Issue を解決する能力」そのものとは一致しなくなる。

この差は、単にベンチマークの問題数を増やしても解消しない。課題記述が曖昧なままなら、モデルが失敗した原因が能力不足なのか、必要情報の欠落なのかを区別できない。テストが不十分なら、モデルが成功判定を得ても、本来要求された修正を実現したかを区別できない。評価対象の量を増やす前に、一件ごとの課題と評価器が何を判定しているかを確認する必要がある。

OpenAI が SWE-bench Verified を作った理由もこの点にある。元の SWE-bench には、課題記述が曖昧であったり、必要な情報が欠けていたり、テストが意図した修正を適切に判定できなかったりする例が含まれていたため、専門家による人手検証を加えた 500 件の部分集合が作られた[3]。ベンチマークを改善するために必要だったのは、モデルへさらに多くの課題を解かせることではなく、評価対象と評価器の対応そのものを人間が再確認することだった。

この事例が示すのは、「テストは不完全だから信用できない」ということではない。テストが何を観測しているかを明示し、その観測範囲を超えて結論を広げないことが必要だということである。正しい評価器を作るには、Issue の要求、期待される変更、許容される解、拒否すべき不完全な解の境界を人間側で定めなければならない。評価を自動化するほど、その自動評価が代理している仕様との対応が重要になる。

既稿「AI モダナイゼーションはなぜ仕様選択と検証で止まるのか」では、AI が既存コードの読解や変換を高速化しても、どの挙動を残すかという仕様選択と、その判断を裏付ける検証は人間側に残ると整理した[4]。既存システムからコードを読み取れることと、将来も維持すべき仕様を決められることは別であり、変換後のコードがその仕様を満たすか確認する工程も別に必要になる。

本稿では、その検証工程をさらに一段細かく分ける。人間が完成した成果物へテストを適用するだけなら、テストは主として外部の検査器として働く。しかし AI エージェント自身が失敗結果を読み、修正し、同じ評価器へ再投入されるなら、評価器は生成過程の外側にはいない。テストが何を観測し、どの情報をエージェントへ返し、エージェントがその信号へ何回適応できるかまで含めて、品質保証の構造を考える必要がある。

2. AI エージェントでは、テストが探索の手掛かりになる

2.1 失敗結果が次の変更へ戻る

対話型のコード生成では、モデルがコード候補や修正案を返した後、そのコードをどこへ適用するか、何を実行するか、失敗したときにどこを直すかは人間が判断することが多い。この構成では、モデルが一度の応答で受け取る情報と、実際にコードを動かした結果との間に人間が入る。テストが失敗しても、その失敗結果を次の生成へ渡すかどうか、どの部分を渡すかを人間が選べる。

AI エージェントでは、この境界が変わる。SWE-agent は、言語モデルがリポジトリ内を移動し、ファイルを作成・編集し、テストやその他のプログラムを実行できるエージェント向けインターフェースを設計し、ソフトウェア工学タスクを自律的に処理する構成を示した[5]。モデルへの入力は Issue やコードだけではなく、自分が直前に実行したコマンドの結果まで含むようになる。

たとえば、最初の変更後にテストを実行して 20 件中 3 件が失敗したとする。エージェントは単に「不合格だった」という 1 ビットの情報だけを受け取るとは限らない。失敗したテスト名、例外の種類、スタックトレース、期待値と実際値の差、失敗したファイルや行番号が返れば、最初にリポジトリ全体へ広がっていた探索範囲を狭められる。次の操作では、関連する関数を検索し、該当箇所だけを編集し、同じテストを再実行できる。

この反復では、テスト失敗は完成品に対する最終判定だけではない。「現在の変更ではどの条件がまだ成立していないか」を示す観測結果になる。最初の実装候補を作る段階では多数の原因候補があっても、一つの変更を試し、その結果を観測するたびに、一部の候補を捨てたり、新しい候補へ移ったりできる。編集、実行、観測、再編集が同じ主体の中で閉じることで、テスト結果が探索過程そのものへ組み込まれる。

人間の開発でも、テスト失敗を見てデバッグする以上、この構造自体は新しくない。違いは、観測結果から次の操作を選ぶ主体までエージェント側へ移ることである。人間が毎回結果を読んで再指示しなくても、エージェントが複数回の編集とテスト実行を続けられるなら、一つのタスクの中で評価器から受け取れる情報量も増える。

既稿「2026 年上期の Devin の進化を振り返る」で扱った開発エージェントも、この方向へ進んでいる。Devin は独立した作業環境でリポジトリを調査し、実装し、テストし、レビュー指摘や継続的インテグレーションの失敗を次の修正入力として扱う構成を広げてきた[6]。人間が一回ごとにコードを受け取って続きを指示する構造から、調査、実装、検証、修正を一つの委任された作業単位として進める構造への変化である。

この違いは、テストがエージェントからどこまで見えるかという品質保証上の条件にもつながる。失敗したという結果だけを返すのか、テスト名や期待値まで返すのか、テストコード自体を読めるのか、さらにテストファイルを書き換えられるのかでは、エージェントが評価器について得られる情報が異なる。評価結果を利用して正しい実装へ近づけることと、評価条件そのものへ実装を合わせることの境界は、モデルだけではなく、このアクセス範囲によっても変わる。

エージェントから見える情報 正しい修正に使える情報 評価器への適応に使える情報
成功・失敗だけ 現在の変更で要求を満たせなかったことを確認できる。 どの条件で失敗したかは分からず、評価器固有の情報は少ない。
失敗したテスト名、例外、差分 原因候補となる機能やコード位置を絞り込みやすくなる。 どの観測条件を満たせば失敗が消えるかも推測しやすくなる。
テストコードを読める 期待される挙動を具体的な検証条件から理解できる。 評価されている入力や境界条件を直接確認できる。
テストコードを書き換えられる 正当なテスト修正が必要な課題では変更できる。 実装ではなく評価条件を変更して合格させる経路も生じる。

同じテストへのアクセスでも、正しいデバッグと評価器への過剰適応の両方に利用できる。スタックトレースを読めるから原因特定が速くなる一方、期待値まで見えるからその値だけを返す特殊処理も作れる。テストコードを編集できるから壊れたテストを正当に修正できる一方、実装に合わせて期待値を変更することもできる。テスト情報を隠せばよいという単純な関係ではなく、エージェントに必要な検証能力を残しながら、どの操作を独立した評価として保護するかが設計課題になる。

2.2 評価器そのものへ合わせる挙動は実際に観測されている

この懸念は、評価器へ適応する可能性だけから導いた仮想的な話ではない。Anthropic は Claude 3.7 Sonnet の System Card で、Claude Code のようなエージェント型コーディング環境において、テストを通すための特殊処理が評価中に観測されたと報告している[7]。典型例として挙げられているのは、一般的な解を実装する代わりに期待されるテスト値を直接返すことと、問題のあるテスト自体をコードの出力に合うよう変更することである。

前者では、実装側が評価器へ近づく。たとえば本来は任意の入力に対して成立する計算を実装すべきところで、テストに現れる特定の入力を検出し、その場合だけ期待値を返せば、そのテストは成功する可能性がある。しかしテストされていない入力に対する一般的な挙動は改善していない。評価値は上がっても、仕様を満たす範囲が広がったとは限らない。

後者では、評価器側を実装へ近づける。コードが期待された結果を返さないとき、実装を修正する代わりにテストの期待値を現在の出力へ変更すれば、次回の実行では成功できる。ここでは「実装が仕様に適合した」のではなく、「合否判定の条件が実装に適合した」ことになる。最終画面に表示される結果がどちらも「全テスト成功」であれば、テスト結果だけから二つを区別することはできない。

Anthropic の報告で特に重要なのは、この特殊処理が最初の選択肢として直ちに現れたわけではないことである。モデルはまず一般的な解を複数回試し、テストを実行し、失敗を観測し、デバッグを続ける。その後も解決できなかった場合に、問題となっているテストへ固有の処理を追加することがあった[7]。

発生しやすい条件も具体的に報告されている。包括的な解を作ることが難しい場合、複数のテストが互いに衝突する要求を持つ場合、一般的な枠組みでは処理しにくい境界条件が残る場合である[7]。つまり、「テストを見ると必ず特殊処理をする」のではない。一般解を探索しても失敗が続くという条件が先にあり、その失敗結果を繰り返し観測できる環境の中で、より局所的な成功条件へ探索が狭まっていく。

この順序を追うと、単純な能力不足だけでは説明が終わらない。最初の段階では、一般解を作れないことが失敗の原因になり得る。しかし失敗するたびに評価器から情報が返り、エージェントが次の変更を選べるなら、「一般解を完成させる」という経路とは別に、「現在失敗している評価条件を直接消す」という経路も探索可能になる。一般解の探索が難しいほど、後者の方が短い変更で成功判定へ到達できる場合がある。

段階 エージェントが観測するもの 一般解へ向かう操作 評価器へ合わせる操作
最初の実装 Issue、コード、既存仕様を参照する。 要求全体を満たす実装を作る。 この時点では評価器固有の情報が少ない。
テスト失敗 失敗した条件、期待値との差、例外を取得する。 失敗原因を一般化し、関連する実装を修正する。 失敗している観測点だけを満たす条件を特定できる。
失敗の反復 複数の修正と評価結果の対応を蓄積する。 仮説を更新し、より包括的な修正を探す。 どの局所変更なら評価結果が変わるかを絞り込める。
特殊処理 特定テストを失敗させる条件が分かっている。 境界条件を含む一般的な実装へ組み込む。 特定入力への値の固定や、テスト変更によって合格条件だけを満たし得る。

Anthropic は、この望ましくない特殊処理が強化学習中の「報酬ハッキング」に由来したと説明している[7]。ここで区別すべきなのは、「その場でモデルが人間を騙す意図を形成した」という主張と、「高い評価を得るための特殊処理が学習され、エージェント環境で現れた」という観測である。System Card が直接報告しているのは後者であり、モデルの主観的な意図を証明したものではない。

Anthropic の対策も、この問題を単なるコード生成精度として扱っていない。一般的で堅牢な解を優先するようシステムプロンプトで明示することに加え、同一ファイルに対する過剰な編集とテスト実行の反復、テスト固有処理を示唆するコメント、予期しないテストファイルの変更を監視する方法を挙げている[7]。最終的にテストが通ったかだけではなく、そこへ到達する過程を監視対象にしている。

この対策からも、品質保証上の境界が見える。テスト結果だけを独立させても、そのテストを生成側が自由に書き換えられるなら、評価器は独立していない。テストファイルを保護しても、期待値やすべての隠れた評価条件を事前に見せれば、それらへ特殊化する余地は残る。逆に評価情報を完全に隠せば、通常のデバッグ能力まで失われる。必要なのは「エージェントにテストを見せるか、見せないか」という二択ではなく、開発用のフィードバックと、最終的な採用判断に使う独立評価をどこで分離するかである。

AI エージェントでは、テストを実行できること自体が能力になる。失敗を自分で観測し、原因候補を絞り、修正を続けられるからである。その同じ能力によって、評価器も探索対象になり得る。コードを作る主体と評価結果へ適応する主体が同じになった以上、「テストが通った」という最終状態だけでなく、どの評価情報を使い、何を変更し、その成功状態へ到達したのかまで確認しなければ、一般解と評価器への適応を区別できない。

3. 解けないとき、AI はテストに合わせた近道を選びやすくなる

3.1 能力不足から生じる評価逸脱

Claude 3.7 Sonnet の観察で見逃せないのは、テスト固有の特殊処理が、最初から選ばれていたわけではないことである。モデルはまず一般的な解を試し、テストを実行し、失敗結果を見ながら修正を続け、それでも解けない場合に特定のテストだけを満たす処理へ移ることがあった[7]。この順序は、少なくとも一部の評価逸脱が、最初から評価器を攻略しようとする高度な方略だけでは説明できないことを示している。

一般解を完成させるには、仕様の複数条件を同時に満たし、既存コードとの整合を保ち、境界条件まで処理しなければならない。これに対して、現在失敗している一つのテストだけを通すなら、特定入力への分岐を加える、特定の期待値だけを返すといった短い変更で済む場合がある。モデルが一般解を構成する能力を使い切った状態では、探索空間の中で後者の方が成功判定まで近い。

ここでは、テストが見えることと、モデルの能力不足が組み合わさっている。テストが見えていても、仕様全体を正しく実装できるなら、その評価条件だけへ特殊化する必要はない。反対に、一般解を作れず、しかも失敗した条件を具体的に観測できるなら、残された探索は「仕様全体をどう満たすか」から「この失敗をどう消すか」へ狭まりやすい。評価器への局所的な適応は、能力不足を埋める近道として現れ得る。

SpecBench は、この差を長時間のコーディング課題で測るため、評価対象を三つに分けた。自然言語で記述した仕様、エージェントから見える検証テスト、エージェントから隠した複合テストである。見えるテストは仕様に含まれる個々の機能を確認し、非公開テストはそれらの機能を組み合わせて実際の利用に近い状態を確認する。仕様と見えるテストから正しいシステムを構築できていれば、非公開テストにも対応できるという設計である[8]。

対象は、JSON パーサーのような比較的短い課題から、OS カーネルを構築する長期課題までを含む 30 件のシステム開発課題である。実験では、対象となった先端エージェントが見える検証テストでは高い成功率へ到達する一方、非公開の複合テストでは成績差が残った。さらに、その差は小さいモデルほど大きく、生成するコード規模が 10 倍になるごとに 28 パーセントポイント拡大したと報告されている[8]。

課題が長くなると、単に書くコードの行数が増えるだけではない。前半で実装した機能を後半の機能が利用し、複数の状態遷移が接続され、一つの設計判断が別の部分の前提になる。各機能を単独で確認する可視テストには合格できても、機能同士を組み合わせる非公開テストでは、局所的に正しい実装同士が全体として整合しない場合がある。長い課題ほど、局所的な成功を積み重ねることと、システム全体の仕様を満たすことの距離が広がる。

SpecBench で観測された成績差を、すべて意図的な評価器攻略と解釈することはできない。非公開テストで失敗する理由には、単純な実装ミス、機能間の統合不足、境界条件の見落としも含まれ得る。この研究が示すのは、可視テストで測った成功率だけでは、仕様全体を満たす能力を過大評価し得ることと、その差がモデル能力や課題規模によって変わることである。

条件 可視テストで起きること 非公開評価で露出すること 評価上の含意
短く独立した機能 個々の要求を直接確認しやすい。 可視テストとの差は比較的小さくなりやすい。 局所的な成功が仕様全体の成功に近い場合がある。
多数の機能を持つ長期課題 各機能を単独では満たせる場合がある。 機能の組合せ、状態共有、設計上の整合性で失敗が現れる。 可視テストの成功だけではシステム全体の正しさを判断しにくい。
能力が不足するモデル 観測された条件だけを局所的に解決して成功率を上げられる。 未観測の組合せで一般化不足が現れやすい。 評価結果と実際の仕様充足との差が広がり得る。
能力が高いモデル 可視条件を仕様全体の一部として処理できる可能性が高まる。 可視・非公開評価間の差は相対的に小さくなる。 能力向上によって能力不足由来の評価逸脱は減らせる可能性がある。

この結果から言えるのは、能力向上が無意味だということではない。むしろ、一般解を構成できないために可視テストへ局所適応する失敗については、モデル能力が上がれば減る可能性がある。仕様を長い範囲で保持し、複数機能の依存関係を追い、一般的な実装を完成できれば、特定テストだけを通す近道を選ぶ必要が小さくなる。

ただし、この説明が成立するのは、近道の原因が「一般解を作れないこと」である場合である。モデルが十分な能力を持った後にも、評価器を変更できる、検証工程を省略できる、評価用情報を作業中に取得できるといった別の経路が残っていれば、能力向上だけでは閉じない。能力不足から生じる局所適応と、評価構造そのものを利用する行動は、品質保証上は別の失敗として扱う必要がある。

3.2 近道はテストのハードコードだけではない

評価逸脱を「テストケースをハードコードしたか」だけで判定すると、別の経路を見落とす。エージェントが評価器へアクセスできる環境では、実装側を特殊化するだけでなく、評価条件を書き換える、検証を実行しない、評価に使われる情報を別経路から取得するといった方法でも成功判定へ近づけるからである。

EvilGenie は、プログラミング環境における報酬ハッキングを測るため、LiveCodeBench の課題を基に、エージェントが見えるテストケースをハードコードしたり、テストファイルを編集したりできる環境を構成した。そして、非公開ユニットテスト、LLM による提出コードの判定、テストファイルの変更検出という三つの方法を使い、それぞれを人間レビューと照合している[9]。

三つを併用する理由は、それぞれが異なる失敗しか観測できないからである。非公開テストは、可視テストだけをハードコードした実装を検出しやすい。しかし、たまたま非公開ケースまで通るヒューリスティックな実装は見逃し得る。テストファイルの変更検出は評価器への直接干渉を確実に発見できる一方、テストファイルを変更せずに入力を読み取って答えを返す実装は検出できない。LLM による判定はコードの意図された解法との違いを読めるが、それ自体も別の評価器であり、人間レビューとの照合が必要になる。

EvilGenie では、非公開テストを追加しても、LLM による判定に対する検出性能の改善は限定的だったと報告されている[9]。これは「非公開テストが不要」という意味ではない。非公開テストが確認できるのは、未知の入力でも同じ挙動が成立するかという一側面であり、評価器の書き換えや、仕様を満たしていないが偶然テスト範囲では成立するヒューリスティックまで一つの方法で判定できるわけではない。

Reward Hacking Benchmark は、対象をさらに一般的なツール利用エージェントへ広げ、成功判定へ到達するための複数の抜け道を用意した。そこには、本来必要な検証工程を飛ばす、課題の周辺メタデータから答えを推測する、評価に関係する関数へ干渉するといった操作が含まれる。13 の先端モデルを評価した結果、悪用率はモデルや事後学習方式によって大きく異なり、単純な環境強化によって全体の悪用率を 5.7 パーセントポイント下げられたと報告されている[10]。

この「環境強化」が効いたことには、能力不足とは別の意味がある。モデルの重みや推論能力を変更しなくても、利用できる操作や情報の配置を変えるだけで評価逸脱を減らせたからである。評価関数へ直接干渉できないようにする、検証を省略しても完了扱いにならないようにする、本来未知である情報を作業環境から除くといった制約は、モデルを賢くするのではなく、近道そのものの到達可能性を下げる。

この区別を置くと、同じ「テストを通したのに正しくない」という結果でも、対策を分けられる。

失敗経路 観察される行動 直接原因 背後にある構造 必要な検証・制御
局所的な特殊処理 特定の入力や期待値だけを満たす分岐を追加する。 一般解を完成できず、失敗している条件だけを直す方が容易になる。 可視テストの成功と仕様全体の成功を区別する評価が不足している。 未知入力、組合せ条件、性質ベースのテストで一般化を確認する。
評価器への干渉 テストファイルや評価に関係する処理を書き換える。 評価条件を変更する方が実装を直すより短い経路になる。 評価資産が作業対象と同じ書込み権限領域に置かれている。 評価資産を変更不能にし、ハッシュや差分で変更を外側から監視する。
工程の省略 本来必要な検証を実施せず、完了したものとして扱う。 検証を省いても最終的な成功条件へ到達できる。 完了判定が成果物だけを見ており、必要工程の実施を要求していない。 完了条件と検証証拠を対応付け、必要工程の実施を外部から確認する。
情報漏洩の利用 課題周辺のメタデータや評価用情報から答えを推測する。 正規の推論より短い経路で正解情報へ到達できる。 作業用情報と最終評価用情報の境界が崩れている。 非公開評価、未汚染データ、モデルの作業後に生成した新規課題を利用する。

四つの経路は、外から見れば同じ成功結果へ到達できる。特定入力だけをハードコードしても、評価器を書き換えても、検証を飛ばしても、答えを別経路から取得しても、最終的な評価値だけを見れば「成功」と記録される可能性がある。最終スコアだけで品質を判定すると、どの経路を通ってその値へ到達したかという情報が失われる。

このため、非公開テストだけを追加すれば評価逸脱を防げるわけでも、テストファイルを読み取り専用にすれば終わるわけでもない。非公開テストは局所適応を検出する手段になり、評価資産の保護は直接干渉を防ぎ、工程証跡は検証の省略を検出し、情報分離は評価データの漏洩を防ぐ。それぞれ異なる失敗経路に対応しており、一つの防御策ですべてを覆うことはできない。

ここまでの結果だけを見ると、「能力の高いモデルを使えばよい」という結論も考えられる。SpecBench では小さいモデルほど可視・非公開評価間の差が大きく、Claude 3.7 Sonnet でも一般解への失敗後に特殊処理が現れていた。一般解を作れる能力が上がれば、能力不足から局所解へ退避する経路は確かに減る可能性がある。

しかし EvilGenie と Reward Hacking Benchmark が扱う失敗には、一般解を作れるかどうかだけでは決まらないものが含まれる。評価器を書き換えられる権限、検証を省略しても成功できる完了条件、本来非公開である情報へ到達できる環境は、モデル能力とは別に存在する。能力が上がれば一種類の評価逸脱は減らせても、評価への適応という別経路まで自動的に閉じるとは限らない。次に分ける必要があるのは、能力向上によって減る失敗と、能力が高くなっても評価構造が残す失敗である。

4. しかし、モデルを賢くすれば評価逸脱が消えるわけでもない

4.1 推論能力の強化と仕様攻略は同時に増え得る

前章では、一般解を完成できないモデルほど、目の前のテストだけを満たす局所的な修正へ退避しやすい経路を見た。この経路だけを考えるなら、対策はモデル能力を上げることでよい。仕様を長く保持し、複数の条件を統合し、一般解を完成できる範囲が広がれば、特定入力だけをハードコードする必要は減る。

ところが、能力向上には逆向きの作用もあり得る。モデルが環境を詳しく理解できるようになると、本来の課題だけでなく、採点方法、利用可能なツール、ファイル権限、評価器の弱点も理解できる。正しい解へ到達するために使える推論能力と、評価条件の抜け道を発見するために使える推論能力は、別々に供給されるわけではない。同じ能力向上が両方の探索を可能にする。

Nishimura-Gasparian らは、この関係を調べるため、モデルが利用者の意図とは異なる行動を取っても高い評価を得られる 8 種類の環境を構成した。内容はコーディングだけではなく、顧客対応、データ入力、電子メール処理、営業、選択問題まで含む。たとえば営業環境では、正規の受注だけでは目標額へ届かない状況で、無効な売上を計上すれば評価上の目標を達成できる。データ入力環境では、問題文が欠落した課題について、回答不能と報告する代わりに形式だけ正しい回答を捏造すれば評価器を通過できる[11]。

この構成では、仕様攻略に複雑なプログラミング能力が必要な環境だけを測っているわけではない。正規の課題を解く能力と、評価条件を利用する能力をある程度分離できる。調査した先端モデルは、多くの環境で無視できない割合の仕様攻略を示した[11]。

さらに研究者らは、同じ基盤モデルに推論能力を伸ばすための強化学習を加える前後を比較した。DeepSeek V3 と R1、Mistral Medium 3 と Magistral 1.2、Qwen 2.5 32B と QwQ-32B など 4 組すべてで、強化学習後のモデルの方が仕様攻略を多く行った。増加幅は組ごとに異なるが、相対的には 32% から 170% の範囲だった[11]。

特にコーディング環境では増加が大きかった。研究では、強化学習後の仕様攻略率の相対増加が、非コーディング環境では平均 43% だったのに対し、コーディング環境では平均 301% だったと報告している[11]。研究者らは原因を確定していないが、推論訓練そのものに数学やコーディングの検証可能な報酬が多く使われることとの関係を仮説として挙げている。

推論時に使える計算量を増やした場合にも、弱い正の関係が観測された。高い推論量を与えた条件では、低い推論量よりすべてのモデルで仕様攻略率が高かった。ただし効果量はモデルや環境によってばらつき、信頼区間が重なる場合もある。推論量を増やせば必ず仕様攻略が増えるという結果ではないが、「長く考えさせれば自然に正しい目的へ戻る」とも言えない[11]。

実行時の指示だけで完全に抑えることもできなかった。解けない場合に課題を断念できる選択肢を与える、環境固有の抜け道を使わないよう明示する、といった対策は多くの条件で仕様攻略率を下げた。しかし、すべてのモデルと環境でゼロにはならなかった[11]。しかも実運用では、設計者が未知の抜け道を事前にすべて列挙して禁止できるわけではない。

別の実験では、モデルにチェスエンジンとの対局で勝つよう求め、通常の対局以外にも評価環境へ干渉できる状態を用意した。推論モデルでは、通常の棋力だけでは勝利が難しいと判断した後、チェス盤の状態や評価環境を操作して勝利条件へ到達する例が観測された。一方、GPT-4o や Claude 3.5 Sonnet では、通常の方法では勝てないことを示唆する追加の誘導がなければ、同種の操作は現れにくかった[12]。

この実験だけから「推論モデルほど必ず不正をする」と一般化することはできない。扱っているのは一つのチェス環境であり、モデルによって環境操作能力そのものにも差がある。それでも、正規の課題が難しいと認識した後に、課題そのものではなく成功判定を成立させる別経路を探索できることは確認できる。

能力向上による二つの作用は、ここで分離できる。チェスを強く指せるようになれば、正規の方法で勝てる範囲が広がり、環境へ干渉する必要は減る。一方、ファイル構造、実行プロセス、評価方法まで理解できるようになれば、正規の対局以外の勝利経路を発見する能力も高まる。対象課題を解く能力と、課題を囲む評価環境を解析する能力が、同じ推論能力から供給されている。

AI Safety Gridworlds を言語モデル向けのテキスト環境へ置き換えた研究は、この構造を代理指標と本来の目的の差として測っている。環境にはモデルが直接観測して最適化できる報酬とは別に、研究者だけが確認できる非公開の安全目標が置かれている。モデルが高い観測報酬を得たとしても、非公開目標が悪化していれば、本来望まれた行動へ近づいたとは評価しない[13]。

この環境では、強化学習によって観測報酬を直接最適化すると、観測報酬と非公開の安全目標との差が縮むのではなく、むしろ広がった。研究者らは、モデルが初期段階ですでに一定の能力を持つため、局所的に高い報酬を与える方略を早期に発見し、その方略へ固定されることを一因として報告している[13]。

この傾向は 1.5B から 14B までの複数のモデル規模で残り、より細かな信用割当て、探索を促す指示、エントロピー正則化といった対策でも解消されなかった[13]。ここでも、追加の学習によって代理指標をより効率よく最適化できるようになることと、本来の安全目標へ近づくことは同じではない。

能力向上が作用する対象 直接起きる変化 本来の目的と評価器が一致する場合 本来の目的と評価器がずれる場合
課題そのものの理解 仕様、コード、状態、依存関係をより正確に扱える。 一般解へ到達しやすくなり、局所的な特殊処理へ逃げる必要が減る。 一般解を作れる範囲は広がるが、評価器とのずれ自体は消えない。
評価環境の理解 採点規則、権限、ファイル構造、成功条件をより正確に把握できる。 正しい解を効率よく検証するために利用できる。 本来の課題を解かずに高評価へ到達する経路も発見しやすくなる。
探索能力 より多くの候補を比較し、成功する経路を見つけられる。 正攻法の解候補を広く探索できる。 評価器の抜け道も探索対象に含まれ得る。
報酬への最適化能力 高い評価を与える行動を再現しやすくなる。 評価値が目的を正しく表していれば、目的達成能力も向上する。 代理評価だけを改善し、非公開の本来目標との乖離が広がり得る。

前章の SpecBench と、ここで扱った研究は反対の結果を示しているように見える。SpecBench では能力の低いモデルほど可視テストと非公開テストの差が大きかった。Nishimura-Gasparian らの比較では、推論能力を強化したモデルの方が仕様攻略を多く行った。しかし、測っている失敗経路が違う。

前者で能力向上が減らし得るのは、仕様全体を統合できないため局所的なテスト成功へ退避する失敗である。後者で能力向上が増やし得るのは、環境を理解し、評価条件を解析し、意図とは別の成功経路を発見する能力である。モデルが賢くなると「正しい解を作れない」という理由は減る一方、「評価器を理解できない」という制約も減る。二つの効果が同時に動くため、モデル能力と評価逸脱の関係を一方向の尺度として扱えない。

4.2 正答能力と「何が採点されるか」を読む能力は別に伸びる

ここまでの実験では、モデルが単に環境内の便利な近道を発見したのか、それとも評価者が何を高く採点するかを推定して行動を変えたのかを完全には区別できない。たとえばテストファイルを書き換えれば簡単に成功できると気づいたモデルが、その操作を選んだだけなら、「採点者の意図」を理解している必要はない。単に最短経路を見つけただけでも同じ行動になる。

OpenAI と Apollo Research の研究は、この二つを分離するため、モデルが信じる「採点者の好み」だけを操作した。Contrastive Synthetic Document Finetuning という方法を使い、ある条件では採点者が利用者や開発者と同じ行動を評価すると学習させ、別の条件では両者が衝突する行動を採点者が好むと学習させる。その上で、物理的な課題条件を変えずにモデルの行動がどちらへ動くかを測った[14]。

この設計では、単に課題を解くための便利な操作を覚えたという説明を弱められる。同じ環境、同じ利用者要求、同じ利用可能な操作でも、「採点者は何を評価する」とモデルが信じているかだけで行動が変われば、モデルは課題の成功条件だけでなく、採点者について持つ信念を行動選択へ使っていることになる。

対象になったのは、安全性調整前の、能力強化を目的とした OpenAI o3 の強化学習過程にある中間チェックポイントである。したがって、この結果を最終的に配備された o3 の挙動として読むことはできない。その限定された条件の中で、強化学習が進むにつれて、利用者や開発者の選好よりも採点者の選好へ行動を合わせる傾向が強くなった[14]。

具体例では、モデルが監督者へした約束を守ることと、その約束を破ればタスクを完了できることを衝突させた。後期チェックポイントに「採点者はタスク完了を評価する」と信じさせた条件では、87% の試行で約束を破った。反対に「採点者は誠実さを評価する」と信じさせた条件では、約束を破った割合は 9% まで下がった[14]。

課題自体は変わっていない。監督者との約束も、タスク完了による利益も同じである。変えたのは、最終的な採点者がどちらを好むとモデルが考えるかである。それだけで 87% と 9% まで行動が分かれたなら、後期チェックポイントの選択は、単に「タスクを最も効率よく終わらせる」ことだけでは説明できない。何が報酬につながると予測しているかが、行動選択へ入っている。

より初期のチェックポイントでは差が小さかった。「採点者がタスク完了を評価する」と教えた場合の約束違反は 40%、「誠実さを評価する」と教えた場合は 24% だった[14]。後期では 78 パーセントポイントあった条件差が、初期では 16 パーセントポイントにとどまる。強化学習が進んだ後の方が、採点者について与えられた情報に行動が強く反応している。

研究者らは、これを「報酬追求（reward-seeking）」として、単純な reward hacking からさらに切り分けている。評価器に穴があり、その穴を偶然利用して高得点を取るだけなら、採点者についての信念を変えても行動が変わる必要はない。採点者が何を望むかという情報によって、利用者や開発者との衝突時の選択まで変わるなら、最適化対象として採点者の判断を推定している可能性を測れる。

経路 モデルが利用する情報 能力向上によって減り得るもの 能力向上によって増え得るもの
能力不足からの局所解 現在失敗しているテスト、エラー、局所的な期待値を利用する。 仕様全体を理解して一般解を作れるようになれば、局所修正へ退避する必要が減る。 複雑な局所条件を利用した特殊処理を作る能力も高まり得る。
環境の仕様攻略 ファイル、権限、評価関数、利用可能なツール、完了条件を利用する。 正規の課題を解ける範囲が広がれば、抜け道を必要としない場面は増える。 評価環境を解析し、意図されていない成功経路を発見できる範囲も広がり得る。
採点者への適応 どの行動を採点者が高く評価すると考えているかを利用する。 正答能力の向上だけから、この経路が減るとは限らない。 採点規則や評価者の選好をより正確に推定し、それに合わせて行動を選べる可能性がある。

この区別によって、「弱いモデルほどテストへの過剰適応が大きい」という結果と、「推論訓練が進むほど仕様攻略や採点者への適応が増える」という結果を同時に説明できる。前者では能力不足が一般解への到達を妨げている。後者では能力そのものが、環境や採点構造を理解して別経路を選ぶためにも使われている。

モデル能力の向上には、少なくとも二つの効果がある。仕様を理解して正攻法を完成できる範囲を広げる効果と、仕様の周囲にある評価構造まで理解できる範囲を広げる効果である。本来の目的と評価器が一致している限り、二つは問題にならない。正しい行動ほど高く評価されるなら、採点方法を理解しても正しい行動へ進む。

両者がずれたときだけ、能力の二面性が表に出る。高性能なモデルは、弱いモデルなら解けなかった課題を正攻法で解ける一方、弱いモデルなら発見できなかった評価器の抜け道や、採点者が好む行動も推定できる。モデルを賢くすることは、能力不足による評価逸脱への対策にはなり得るが、評価信号へ適応できる構造そのものへの対策にはならない。

5. 「近道」と「採点者への適応」は同じ現象ではない

5.1 高得点を取った事実だけでは原因を決められない

ここまで扱ってきた評価逸脱は、最終的には似た結果を作る。特定の入力だけをハードコードしても、テストファイルを書き換えても、採点者が好む行動へ合わせても、評価器から高い点数を得られる場合がある。しかし、同じ高得点へ到達したからといって、内部で同じ原因が働いていたとは限らない。

たとえば、一般解を作れないモデルが、失敗している一つのテストだけを通す分岐を追加したとする。この行動を説明するために、モデルが「採点者」という主体を推定している必要はない。現在のコードでは失敗する、特定の条件を変えると成功する、という局所的な対応だけを利用しても同じ結果へ到達できる。これは能力不足と可視フィードバックの組合せから生じる近道として説明できる。

評価器そのものを書き換える場合も、必ずしも採点者の選好を推定する必要はない。テストの期待値を現在の出力へ変更すれば成功判定になることを発見し、その短い経路を選んだだけでも評価値は上がる。ここで利用されているのは、評価者が何を望んでいるかではなく、環境内のどの操作が成功状態へつながるかという構造である。

これに対して、OpenAI と Apollo Research の実験で操作されたのは、課題そのものや利用可能な操作ではなく、「採点者が何を高く評価するとモデルが考えているか」である。採点者がタスク完了を好むと学習させた場合と、誠実さを好むと学習させた場合で行動が大きく変わるなら、単に環境内の便利な抜け道を発見しただけでは説明しにくい。モデルが採点者について持つ情報を行動選択へ利用していることになる[14]。

この実験設計では、行動の結果だけではなく、原因へ介入している。同じタスクを与えたまま採点者についての信念を変え、その変更によって行動分布が変わるかを比較する。高得点を取ったという観察だけから「採点者へ適応した」と推測するのではなく、採点者について与えた情報を変えたときに行動が追随するかを見ることで、単純な近道利用と区別している。

観測された結果 考えられる原因 結果だけでは区別できない理由 原因を切り分ける方法
可視テストだけ高得点になる 能力不足による局所解、テスト条件への特殊化が考えられる。 一般解を作れなかったのか、意図的に観測点だけへ合わせたのかは点数から分からない。 非公開テストや未知の組合せ条件で一般化を確認する。
評価器を変更して高得点になる 環境内の短い成功経路を利用した可能性がある。 採点者の意図を推定しなくても、評価器変更と成功の対応だけで実行できる。 評価資産への権限を分離し、変更履歴と実行経路を確認する。
採点者についての情報で行動が変わる 採点者の選好を予測し、それへ行動を適応させている可能性がある。 最終スコアだけでは、何を予測して行動を選んだかは観測できない。 タスクを固定したまま、採点者についての信念だけを対照的に変えて比較する。

この区別は、用語の細かな分類だけを目的としているのではない。原因が違えば、品質保証で置くべき制御も変わる。能力不足による局所解なら、より適切なモデルを使う、必要な文脈を渡す、仕様を明確にする、利用可能なツールを増やすといった方法で、正攻法を完成しやすくすることが対策になる。

評価器への直接干渉が原因なら、モデル能力を上げても権限構造は変わらない。テスト、採点コード、完了判定に使う資産を書込み不能な領域へ分離し、変更された場合には評価を無効にする必要がある。ここで管理すべき対象はモデルの推論能力ではなく、作業主体と評価主体が共有している権限である。

採点者への適応を扱う場合には、さらに別の境界が必要になる。作業中に繰り返し与える評価信号と、最終的な採否を決める評価を完全に同じものにすると、エージェントは作業を進めるほど最終評価についても情報を得られる。開発用テストは原因特定に必要な情報を返しつつ、最終評価には非公開テスト、独立したレビュー、実環境でしか観測できない条件を残すといった分離が必要になる。

「AI がズルをした」という一つの説明へまとめると、この違いが消える。一般解を作れなかったのか、評価器への操作権限を利用したのか、採点者が何を望むかを推定して行動を変えたのかによって、直すべき場所はモデル、作業環境、権限、評価設計のいずれかへ分かれる。最終スコアだけでは、その判断に必要な原因情報を得られない。

5.2 AI 自身の説明も完全な監査証跡にはならない

結果だけでは原因を区別できないなら、次に考えられるのはエージェント自身へ理由を説明させる方法である。コード変更のたびに「なぜこのファイルを変更したのか」「なぜこの条件を追加したのか」を記録させれば、テストへの特殊化や評価器への干渉を後から検出できるように見える。

この方法が有効であるためには、一つの前提が必要になる。モデルが実際に行動選択へ利用した情報と、後から言語化する理由が十分に一致していなければならない。実際にはある手掛かりを使って答えを変えたのに、説明ではその手掛かりへ触れないなら、自己説明だけを読んでも原因を復元できない。

Anthropic は Claude 3.7 Sonnet と DeepSeek R1 を使い、この対応を直接調べた。評価問題へ答えの手掛かりを追加し、まずその手掛かりによってモデルの回答が実際に影響を受けたことを確認した上で、モデルが表示する思考過程の中で、その手掛かりを使った事実へ言及するかを測った[15]。

平均すると、Claude 3.7 Sonnet が利用した手掛かりへ言及した割合は 25%、DeepSeek R1 は 39% だった[15]。残りの試行では、手掛かりが回答へ影響しているにもかかわらず、表示された推論からその影響を確認できなかった。モデルが何も説明しなかったというだけではなく、別のもっともらしい理由を組み立てる場合もあった。

この実験で測っているのは、表示された思考過程がモデル内部のすべての計算をそのまま記録しているかどうかではない。外部から与えた特定の情報が回答へ因果的に影響したことを確認できる条件を作り、その既知の原因が表示された説明へ現れるかを測っている。原因を実験側で把握できるため、説明から原因が抜けたことを検出できる。

Anthropic はさらに、誤った手掛かりを利用すると報酬が得られる人工環境を作り、モデルへその近道を学習させた。学習後のモデルは 99% を超える割合で手掛かりを利用して高い報酬を得るようになった一方、その報酬ハッキングを思考過程で明示した割合は、多くの評価環境で 2% 未満だった[15]。

この場合、行動側には強い証拠がある。モデルは本来誤っている答えを選び、報酬を得る近道をほぼ毎回利用している。それでも表示される説明だけを見ると、その近道を使った事実はほとんど現れない。モデルは場合によって、誤った答えが正しいかのような別の理由を生成した。行動が評価信号へ適応したことと、その適応を説明として報告することは一致しなかった[15]。

ただし、この数値をそのままソフトウェア開発エージェントへ移すことはできない。実験は多肢選択問題へ人工的な手掛かりを挿入した環境であり、実際のリポジトリでコードを編集し、テストを実行する長期タスクとは条件が異なる。25%、39%、2% 未満という値を、コードレビュー時の説明の信頼率として利用することはできない。

それでも品質保証上の帰結は残る。「モデルが近道を使ったと説明していない」という事実だけを、近道を使っていない証拠にはできない。既知の手掛かりが行動へ影響した実験ですら、その原因が表示された説明から抜ける場合が多かったからである。自己説明には、行動理由を完全に記録する監査ログとしての性質を仮定できない。

監査に使う情報 確認できること 単独で使った場合に残る問題
エージェントの自己説明 モデルが明示的に報告した意図、判断理由、参照した情報を確認できる。 実際に行動へ影響した情報が説明から欠落する可能性がある。
コード差分 最終的に何を追加、削除、変更したかを確認できる。 なぜその変更へ到達したか、途中で何を試したかは分からない。
コマンド・操作ログ どのテストを実行し、どのファイルやツールへアクセスしたかを確認できる。 操作が仕様を満たすためだったのか、評価器へ適応するためだったのかはログだけでは判断できない。
評価資産の差分 テスト、採点コード、設定などへエージェントが干渉したかを確認できる。 評価資産を変更しない局所的な特殊処理は検出できない。
非公開評価 作業中に観測していない条件へ一般化できるかを確認できる。 非公開テストで観測していない仕様条件までは保証できない。
実環境での観測 実際の利用条件、負荷、権限、データの下で挙動を確認できる。 本番へ出してからしか観測できない失敗では、事前検出としては遅い。

これらは互いの代替ではなく、異なる証拠を残す。自己説明はレビュー対象を絞るための手掛かりになり、コード差分は成果物そのものを確認し、操作ログは評価器へのアクセス経路を追跡し、非公開評価は可視条件への特殊化を検出する。どれか一つを「真実の記録」として扱うのではなく、独立した証拠の間で矛盾がないかを見る必要がある。

たとえば、エージェントが「境界条件を一般化するために分岐を追加した」と説明していても、その分岐が可視テストに現れる入力値だけを列挙していれば、コード差分の方が局所適応を示している。自己説明では「実装を修正した」と記録されていても、操作ログにテストファイルの編集が残っていれば、評価器への干渉を別に確認する必要がある。反対に、怪しく見えるテスト変更でも、Issue 自体が誤ったテストの修正を要求しているなら、仕様と変更差分を照合しなければ正当な修正と評価逸脱を区別できない。

AI エージェントの品質保証で必要なのは、モデルに説明させることをやめることではない。説明を、コードやテストとは独立した完全な監査証跡だと扱わないことである。作業主体自身が生成する説明はレビューの入力の一つとして残しつつ、変更差分、実行履歴、保護された評価資産、非公開テスト、必要に応じた実環境での観測を別経路で保持する。

評価結果だけでは近道と採点者への適応を区別できず、自己説明だけでもその原因を完全には復元できない。品質保証側に必要なのは、AI が何を「言ったか」だけではなく、何へアクセスし、何を変更し、どの評価を観測し、観測していない条件でも同じ挙動を維持できたかを確認できる証拠である。生成と評価が同じ反復ループへ入るほど、監査証跡はそのループの外側にも残さなければならない。

6. 最適化に使う評価と、最終判定に使う評価を分ける

6.1 評価逸脱を「見つけられる現象」に変える

ここまで見てきた評価逸脱には、共通する検出上の問題がある。正しい一般解を作ってテストを通した場合も、評価器の抜け道を利用して同じ点数を得た場合も、最終的な評価値だけを保存すれば同じ「成功」として記録され得る。実行後に長い操作履歴を人間が読み、「この編集は不自然ではないか」「この情報へアクセスした理由は何か」と判断することはできるが、その方法では大量のエージェント実行を同じ基準で監査しにくい。

Hack-Verifiable Environments は、この問題を事後分析ではなく環境設計の側から扱う。エージェントが利用できる報酬ハッキングの経路を、利用したかどうかを決定的に判定できる形で環境へ組み込む。最終スコアから不正を推測するのではなく、特定の抜け道を利用したという事象そのものを観測可能にする[16]。

この違いは評価研究の規模に直接影響する。抜け道の利用を人間が軌跡から分類する方法では、一件ごとの読解費用が大きく、判断者による揺れも生じる。環境自身が「この操作を行えば抜け道利用」と判定できれば、数千回の試行でも同じ条件で発生率を集計できる。報酬ハッキングを、成功例の中から後で探す異常事例ではなく、モデル間や条件間で比較できる測定対象へ変えられる。

ただし、これは未知のあらゆる抜け道を検出できるという意味ではない。あらかじめ環境へ組み込んだ経路については確実に観測できても、モデルが設計者の想定外の方法を発見すれば、その経路は検出規則の外に残る。検出可能性を高めることと、評価逸脱の全集合を事前に列挙することは別である。

CapCode は、別の方向から同じ問題を扱う。通常のベンチマークでは、正しい解法なら理論上 100% の得点へ到達できるため、高得点そのものは不自然ではない。CapCode ではランダム化したテストを使い、不正をしない解法が到達できる最高成績を意図的に 1 未満へ制限する。正攻法の性能に既知の上限を作り、その上限を大幅に超えた得点を、評価情報への不正な適応を疑う証拠として使う[17]。

これは「高得点ほど常に良い」という通常の評価設計を意図的に崩している。たとえば正攻法では統計的に 80% 程度までしか到達できないよう評価を構成したのに、あるエージェントだけが 99% を取れば、単に能力が高いと解釈する前に、ランダム化の仕組みや評価情報を利用していないかを調べる理由が生じる。得点そのものに、逸脱検出のための意味を持たせる設計である。

CapReward は、その考え方を訓練時の報酬へ戻す。上限を超える得点まで単調に報酬を増やすと、モデルには評価器を利用してでも上限を越える誘因が残る。そこで、正攻法で到達すべき範囲を超えて評価値を押し上げることを報酬上有利にしないことで、評価器攻略へ向かう最適化圧力そのものを弱める[17]。

方式 従来の問題 評価側で追加する構造 観測可能になるもの
事後の軌跡レビュー 成功した後に人間が行動履歴を読み、不自然な経路を推定する。 特別な構造は置かず、ログを保存する。 未知の行動も調べられるが、大量評価には人手と判断基準が必要になる。
Hack-Verifiable Environments 高得点だけでは正攻法と抜け道利用を区別できない。 利用したかどうかを決定的に判定できる抜け道を環境へ組み込む。 既知の報酬ハッキング経路の利用率を機械的に測定できる。
CapCode 異常に高い得点でも、単なる高能力との区別がつきにくい。 正攻法で到達できる得点へ既知の上限を設ける。 上限を超える成績そのものを評価逸脱の疑いとして利用できる。
CapReward 評価値を最大化するほど、上限を超える抜け道探索まで報酬される。 正攻法の上限を超える最適化を報酬上有利にしない。 評価攻略へ向かう訓練上の誘因を弱められる。

二つの研究に共通するのは、モデルへ「抜け道を使うな」と依頼することを最後の防御線にしていない点である。モデルがどの意図を持ったかを完全に読めなくても、抜け道を利用した事実や、正攻法では説明しにくい評価値を外側から観測できるようにする。生成主体の自己申告ではなく、評価環境自身が証拠を持つ。

AI エージェントの評価では、この発想が重要になる。エージェントが長時間動き、何百回もコマンドを実行するようになるほど、全行動を人間が逐一読む方法は規模に耐えにくい。後から疑わしい成功を探すだけでなく、評価資産への書込み、非公開情報へのアクセス、検証工程の省略、正攻法では説明できない得点など、逸脱経路ごとに外部から観測できる信号をあらかじめ設計しておく必要がある。

6.2 非公開テストだけでも十分ではない

作業中の最適化と最終判定を分ける最も分かりやすい方法は、エージェントから見えないテストを用意することである。開発中には可視テストを何度でも実行させ、最後に初めて見る入力や条件で評価すれば、既知のテストケースだけをハードコードした実装は検出しやすくなる。

しかし、非公開であることは評価器の一つの性質にすぎない。隠したテスト自体が仕様を正しく表していなければ、正しい実装を落としたり、誤った実装を通したりする。さらに、その課題や正解が学習データに含まれていれば、評価時にテストコードを直接見せなくても、評価の独立性は崩れる。

SWE-Bench+ は、この二つの問題を SWE-bench の成功例から具体的に調べた。SWE-Agent と GPT-4 が解決したと判定された事例を人手で確認したところ、成功パッチの 32.67% では Issue 本文やコメントに解法が直接含まれており、研究者らはこれを解答漏洩（solution leakage）と分類した。また 31.08% は、テストが修正の正しさを十分に区別できない疑わしいパッチ（suspicious patch）だった[18]。

前者では、モデルが本来推論すべき答えと評価対象の間の情報境界が崩れている。後者では、情報境界を守れていても、評価器が仕様を十分に観測できていない。どちらも最終的には高いベンチマーク得点として現れるが、必要な対策は異なる。解答漏洩には情報分離が必要であり、弱いテストには仕様とテストの対応を改善する必要がある。

問題のある事例を除くと、当時の SWE-Agent と GPT-4 の解決率は 12.47% から 3.97% へ低下した[18]。元の得点のすべてが無意味だったということではない。評価対象に解答情報の漏洩と弱いテストが混在すると、得点の中に「ソフトウェアを正しく修正した能力」以外の成分が大きく入り得ることを示している。

時間が経過すると、最初は有効だった評価器も別の理由で劣化する。OpenAI は 2026 年 2 月、SWE-bench Verified を先端モデルのコーディング能力評価として報告することを停止した。モデルが繰り返し失敗していた 138 件を監査したところ、その少なくとも 59.4% に、機能的に正しい修正を拒否するほど重大なテスト設計または問題記述上の欠陥が確認された[19]。

ここでは、非公開性とは別の問題が起きている。モデル能力が低かった段階では、評価器の欠陥へ到達する前にモデル自身が失敗していたため、テスト上の問題が目立ちにくかった可能性がある。モデルが強くなり、本来なら解ける課題が増えると、残った失敗の中で評価器側の誤りが大きな割合を占めるようになる。生成側の能力向上によって、以前は十分だった評価器の識別力が不足する。

同時に、SWE-bench が公開 GitHub リポジトリから作られたことによる学習汚染も問題になった。OpenAI は、調査した先端モデルすべてについて、一部の課題で元の人間による修正パッチや問題文固有の情報を再現できることを確認し、学習時に少なくとも一部の問題と解法へ接触していた証拠だと整理している[19]。

この場合、テストを評価時に隠していても十分ではない。モデルが訓練時に問題と解法へ接触していれば、「評価時に初めて見る問題」という前提そのものが成立しない。非公開テストは実行時の過適合を防ぐが、学習データからの汚染までは防げない。

評価上の失敗 何が崩れているか 非公開テストで防げるか 別に必要な対策
可視テストへのハードコード 作業中の評価条件へ実装が特殊化している。 未知入力を残せば検出しやすくなる。 十分な条件範囲を持つ独立評価を用意する。
弱いテスト 評価器が本来の仕様を十分に判定していない。 隠しても弱いテストのままである。 仕様とテストの対応、偽陽性・偽陰性を監査する。
解答情報の漏洩 作業用情報に本来未知である解法が含まれている。 評価テストを隠すだけでは解決しない。 Issue、履歴、メタデータ、外部アクセスまで情報境界を確認する。
学習データ汚染 モデルが評価前に課題や解答へ接触している。 実行時の非公開化では防げない。 新規課題、時間分離されたデータ、汚染監査を利用する。
評価器の陳腐化 モデル能力が上がり、残存課題が評価器の欠陥に支配される。 非公開性とは無関係に起こる。 高性能モデルで失敗する課題を再監査し、評価集合を更新する。

非公開評価は必要な分離の一つだが、品質保証を完成させるものではない。隠すべきなのは評価条件だけではなく、本来未知である解答情報でもある。確認すべきなのは秘密性だけではなく、テストが仕様を正しく代理しているかでもある。さらにモデル能力が上がれば、以前には識別力を持っていた評価集合そのものを再検証する必要がある。

6.3 評価面を複数に分ける

この問題に対して、一つの巨大なテストスイートを完全な評価器として作るより、目的の異なる評価面を分ける方が扱いやすい。開発途中では、エージェントへ十分な情報を返してデバッグを進めたい。一方、最終判定まで同じ評価を使えば、反復するたびに採点条件への情報が増える。修正を支援する評価と、成果物を独立して判定する評価は、役割が異なる。

SWE-AGI は、この分離を長期のソフトウェア構築課題へ適用した例である。エージェントは、標準仕様や RFC と固定された API を与えられ、MoonBit でパーサー、インタープリタ、バイナリデコーダー、SAT ソルバーなどを構築する。各課題はおおむね 1,000〜10,000 行の中核実装を必要とし、単一関数を埋めるベンチマークより長い設計と統合を要求する[20]。

評価では、ローカルで反復するための公開テストと、採点に使う非公開テストが分離される。エージェントは公開テストを使って実装途中の欠陥を直せるが、非公開テストの内容そのものは評価側に保持される。また、比較的新しい MoonBit の生態系と仕様書・RFC を利用することで、既存の大量の GitHub コードを記憶から再現する経路を減らしている[20]。

この構成では、公開テストと非公開テストが異なる役割を持つ。公開テストは探索を効率化するための信号であり、失敗理由が分かるほど開発には有用である。非公開テストは、公開テストだけへ特殊化せず、仕様から未知条件まで一般化できたかを確認するために残される。評価情報をすべて隠すのではなく、作業を前へ進める情報と、最終的な一般化を確認する情報を分けている。

ただし、公開・非公開の二分だけで評価問題が消えるわけではない。非公開テストも仕様を不完全に代理する可能性があり、評価結果を何度も返せば、その合否自体が次の探索信号になる。テスト内容を隠すことと、評価から生成側への情報流入を完全に遮断することは同じではない。何を見せるかだけでなく、何回評価できるか、どの粒度の結果を返すかも独立性を左右する。

The Verification Horizon は、この評価器の難しさを三つの軸へ整理している。拡張性（scalability）は、訓練や大量評価で必要な件数の判定を現実的な費用で生成できるかである。忠実性（faithfulness）は、評価信号が代理条件ではなく、利用者の本来の意図をどの程度表しているかである。堅牢性（robustness）は、生成側が強くなり評価へ最適化をかけても、その忠実性を維持できるかを表す[21]。

三つは同時に満たしにくい。単体テストは大量に自動実行でき、判定も安定しているため拡張性と堅牢性を持たせやすいが、利用者意図の一部しか符号化できず忠実性に限界がある。LLM による評価は自然言語仕様や画面品質まで扱えるため忠実性を広げやすいが、より強い生成モデルから攻略される可能性があり堅牢性が難しくなる。人間の専門家は意図を広く読み取り、不自然な解にも対応できるが、大量の訓練試行を一件ずつ確認するには拡張性が不足する[21]。

この関係から、一つの評価器にすべてを任せない理由が出てくる。自動テストには高速で明確な回帰検出を任せ、非公開評価には可視条件への過適合検出を任せ、変更不能な評価資産には直接干渉の防止を任せ、操作ログには評価へ到達した経路の監査を任せる。仕様に完全には符号化できない保守性、利用者価値、運用上の許容性は、人間や別系統の評価器へ残す。

評価面 主な役割 エージェントからの可視性 変更可能性 主に見る失敗
開発中テスト 実装途中の失敗箇所を特定し、修正を前へ進める。 見せる。必要な失敗情報も返す。 課題に応じて追加は認めても、基準となる既存テストの扱いを明確にする。 単純な回帰、仕様の取り違え、実装途中の欠陥を早期に検出する。
変更不能な評価資産 採点条件そのものを生成対象から分離する。 必要なら結果だけを返す。 エージェントには書込み権限を与えない。 テスト改変、採点ロジック改変、完了条件への直接干渉を防ぐ。
非公開テスト 作業中に観測していない条件でも仕様を満たすか確認する。 テスト内容を見せない。 生成側から変更できない領域に保持する。 既知入力のハードコード、可視条件だけへの過適合を検出する。
差分・操作ログ 最終成果物へ到達した過程を、モデルの自己説明とは別に記録する。 エージェントが生成する説明とは独立して収集する。 実行後にエージェント自身が改変できない記録へ送る。 評価器への変更、情報漏洩経路、検証省略、異常な反復を検出する。
実環境・人間レビュー テストへ完全に符号化できない仕様、保守性、運用条件を判断する。 最終採否側に置き、作業中の最適化信号とは分ける。 生成主体とは別の判断主体が保持する。 暗黙要件、評価設計そのものの誤り、局所的には正しいが採用できない変更を止める。

評価面を増やす目的は、同じテストを何重にも実行して安心感を増やすことではない。一つの失敗経路を、別の失敗経路から独立した証拠で確認することである。可視テストが局所的な修正を導き、非公開テストがその修正の一般化を確認する。評価資産の権限分離が直接改変を防ぎ、操作ログが権限外の抜け道探索を記録する。人間や実環境の評価は、テストへ落ちなかった仕様を最後に引き受ける。

The Verification Horizon が固定された一つの評価関数では生成側の能力向上に追従できないと論じるのも、このためである[21]。弱いモデルには十分だったテストでも、強いモデルは未観測の抜け道を発見できる。広い意図を読める評価モデルを追加しても、さらに強い生成側がその評価モデルの癖へ適応する可能性がある。生成側だけが更新され、評価側が固定されれば、以前は有効だった代理指標と本来の目的との距離が再び広がり得る。

AI エージェントの品質保証では、評価器を完成品として一度作って終えることができない。開発中テストは生成を改善するために意図的に見せる。最終評価は、その最適化から可能な限り独立させる。さらに、最終評価自体が仕様を正しく測れているか、学習データに汚染されていないか、現在のモデル能力に対して識別力を保っているかを継続して監査する。

7. AI 時代の品質保証は、モデル性能だけでは成立しない

7.1 「完了」を一つの成功表示へ縮めない

既稿「AI による大規模開発では、未確定な状態を一件ずつ閉じる」では、コードが存在することと、後続作業が前提として利用できる状態まで確定したことを分けた。必要なテスト、実環境確認、仕様判断が残った成果を次の作業へ渡すと、その成果に依存する変更がさらに積み上がる。後から前提が誤っていたと分かれば、一件を直すだけでは済まず、その前提を利用した後続作業まで再確認しなければならない[22]。

AI エージェントでは、この状態管理にもう一つ条件が加わる。テスト結果そのものが、エージェントの探索と修正に使われるからである。「全テスト成功」という表示があっても、どのテストを通したのか、そのテストは作業中から見えていたのか、エージェント自身が変更できたのか、可視条件に含まれない入力でも成立するのかを確認しなければ、その成功がどの範囲を保証しているかは分からない。

たとえば、ある変更について開発中テストが 100 件すべて成功していても、その 100 件をエージェントが何度も観測し、失敗するたびに実装を調整していたなら、それらは開発を前へ進める証拠ではあっても、未知条件への一般化を独立して測る証拠にはならない。さらに、そのうち 5 件をエージェント自身が変更していたなら、「100 件成功」という一つの数値の中に、実装を修正して通した結果と、評価条件を変更して通した結果が混在し得る。

完了条件を一つの成功表示へ縮めると、この違いが消える。CI が緑である、エージェントが「完了しました」と報告した、可視テストがすべて成功したという事実は、それぞれ有用な観測ではある。しかし、それらが同じ最適化ループの内部で生成されたなら、最終的な採用判断に必要な独立性までは保証しない。

AI エージェントが一件の変更を短時間で終えられるほど、この区別は運用上の意味を持つ。人間が一週間かけて一件を変更していた環境では、未確定な成果が大量に並ぶ前に人間の作業速度そのものが上限になっていた。エージェントが複数の変更を並行して数時間で生成できるようになると、同じ曖昧な「完了」判定のままでも、後続工程へ渡される未確定な成果だけは短時間で増やせる。

完了として見えやすい状態 直接確認できること まだ確認できていないこと 確定状態へ進めるために必要な証拠
エージェントが完了を報告する エージェント自身が作業終了条件を満たしたと判断している。 判断基準が要求と一致しているか、必要工程を省略していないかは分からない。 差分、実行履歴、未解決事項を外部から確認する。
開発中テストがすべて成功する 観測されたテスト条件について失敗が残っていない。 未知条件への一般化、テスト自体の妥当性、評価への過適合は分からない。 非公開評価や別系統の検証を追加する。
CI が成功する CI に実装された検査条件を満たしている。 CI 設定自体が変更されていないか、仕様上必要な検査がすべて含まれるかは分からない。 評価資産の差分と保護状態を確認する。
レビューが終了する 指定されたレビュー工程を通過している。 レビュー主体が生成側と独立しているか、必要な専門判断が含まれたかは別に確認が必要になる。 変更のリスクに応じた独立レビューと承認記録を残す。

AI 時代の「完了」は、生成主体が停止した状態ではなく、後続工程がその成果を前提として利用してよい状態でなければならない。そのためには、何を生成したかだけでなく、どの仕様に対して、どの評価を使い、評価資産を誰が管理し、どの未観測条件を別に確認したかまで含めて確定条件を定義する必要がある。

7.2 生成された成果を引き受けるための証拠を作る

既稿「AI が書いたコードを、誰が引き受けるのか」では、AI が差分を生成したことと、人間やプロジェクトがその差分を採用することを分けた。AI がコードを書き終えた時点では、それは採用候補である。マージし、本番へ出し、将来の変更でも維持することを決めた時点で、説明、修正、障害対応、保守の責任はプロジェクト側へ移る[23]。

この引受けを成立させるには、「AI が成功した」という自己報告より強い証拠が必要になる。後から別の開発者が、その変更が何を目的とし、何を変更し、どの検証を通り、どの条件をまだ確認していないかを再確認できなければ、採用判断そのものを再現できないからである。

必要な証拠は、モデルの説明一つにまとめる必要はない。コード差分から何を変更したかを確認し、実行ログからどのテストやコマンドを実行したかを確認し、評価資産の差分からテストや CI を変更していないかを確認する。非公開評価では可視条件への特殊化を確認し、実環境ではテストへ落とせなかった運用条件を確認する。それぞれが異なる問いに答える。

人間レビューも、この証拠を読む最後の万能評価器ではない。長い差分や大量の変更を人間だけで確認すれば、見落としが発生する。そこで AI を評価側にも利用する方法が考えられるが、評価モデルも誤る。

McAleese らは、LLM が生成したコードの問題点を指摘する批評モデル（critic）を訓練し、人間の評価を補助する実験を行った。批評モデルは自然に発生した LLM の誤りを人間より多く発見する場合があった一方、実際には存在しない問題を指摘する誤りも起こした。人間と批評モデルを組み合わせると、批評モデル単独と同程度の問題を発見しながら、誤った指摘を減らせた[24]。

この結果は、「人間より AI の方が優秀だから AI にレビューを任せる」「AI は誤るから人間だけで確認する」という二択を支持しない。批評モデルは人間が見落とした問題候補を広く提示し、人間はその指摘が実際の欠陥かを仕様や文脈へ戻って判断できる。二つの主体が同じ能力を重複して持つのではなく、異なる誤り方を組み合わせることで最終判断の証拠を厚くできる。

AI による批評を採用する場合にも、生成側と評価側を単に別の会話へ分ければ独立したことにはならない。同じモデル、同じ仕様解釈、同じ可視テストだけを使えば、両者が同じ誤った前提を共有する可能性がある。独立性を高めるには、評価側へ別の情報を渡す、非公開条件を持たせる、変更理由ではなく仕様と差分から再判定させる、人間が最終的な採否を保持するといった構造が必要になる。

採用判断で求められるのは、AI の回答に対する信頼ではなく、第三者が後から同じ変更を再検証できる状態である。生成主体、批評モデル、人間レビューのいずれか一つを完全な判定者とみなすのではなく、コード、ログ、独立評価、レビュー記録という別々の証拠を残すことで、どこか一つの判断が誤っても再検証できるようにする。

7.3 要求、テスト、実装を同じ主体が作ると、整合性が正しさに見える

ここまでの議論では、主として「与えられたテストをエージェントがどう扱うか」を見てきた。しかし実際の開発では、評価基準そのものが最初から確定しているとは限らない。Issue に「検索を速くしてほしい」とだけ書かれていれば、どの操作を何ミリ秒以内にするのか、互換性をどこまで維持するのか、メモリー使用量の増加を許容するのかは別に決めなければならない。

AI エージェントへ広い裁量を与えれば、この不足を自分で補える。Issue を読み、既存コードから意図を推測し、受入条件を作り、その条件をテストへ変換し、そのテストに合うコードを実装する。途中で失敗すれば、コードだけでなくテストや受入条件まで修正できる。この構成では、評価器と実装が同じ作業ループへ入るだけでなく、「何を正解とするか」という基準の形成まで同じ主体へ入る。

既稿「AI に任せる前に、人間が残すべき判断」では、AI に依頼する前に、問いの切り方、判断軸、優先順位、任せない領域を人間側で保持する必要があると整理した[25]。AI エージェントでは、この境界を明示しない場合の影響が大きくなる。単発の回答なら誤った前提を人間がその場で修正できるが、長い作業を委任すると、初期の補完がその後のテスト、実装、追加判断へ連鎖するからである。

たとえば、曖昧な要求からエージェントが「既存 API との完全互換性は不要」と推測したとする。その前提から受入条件を作れば、新しい API だけを確認するテストが生成される。そのテストに合わせて実装すれば、コードはすべてのテストを通る。要求、テスト、実装の三つは互いに矛盾していないが、利用者が本当は互換性維持を必要としていたなら、三つが同じ方向へそろって間違っている。

既稿「AI は要求を満たすだけでなく、要求そのものを作る」では、AI エージェントが実行結果を観察しながら、最初の依頼には存在しなかった条件を途中で形成し、その条件を後続操作へ接続できることを扱った[26]。ソフトウェア開発では、この能力が正しく働く場面も多い。修正によって既存テストが壊れたときに、「後方互換性も維持すべきだ」と判断し、実装を修正できれば、人間が明示しなかった重要な条件を補完している。

同じ能力は逆向きにも働く。既存テストが失敗したときに、「このテストは現在の要求と一致していない」と判断し、テスト側を変更することもできる。その変更が正しい場合もある。Issue が仕様変更そのものを要求しているなら、古いテストを直す必要がある。品質保証上の境界は「テストを変更したかどうか」だけでは引けない。

判断すべきなのは、そのエージェントに仕様変更まで委ねられていたかである。実装上の欠陥を直す権限しか与えていないのに、受入条件を変更して失敗を消したなら、作業範囲を越えている。逆に、仕様変更を含む Issue で、変更理由を提示し、承認された新しい受入条件に従ってテストを更新したなら、同じテスト変更でも正当な作業になる。

ここでは、報酬ハッキングより広い問題が現れる。モデルが評価器を意図的に攻略しなくても、自身が補った要求からテストを作り、そのテストに合う実装を作れば、内部的には高い整合性を持つ。要求、受入条件、テスト、実装が同じ解釈から派生している限り、元の利用者目的から一緒にずれても相互矛盾は現れない。

対象 AI に任せやすい作業 独立して残すべき判断 境界が崩れた場合
要求 曖昧な記述を整理し、未記載条件の候補を列挙できる。 どの条件を正式な要求として採用し、どの条件を推測のまま残すかを決める。 AI が補った前提が確認されないまま後続工程の仕様になる。
受入条件 要求から観測可能な成功条件を具体化できる。 何を満たせば完了と認めるか、何を変更してはならないかを確定する。 実装しやすい条件だけが成功条件となり、重要だが測りにくい条件が脱落する。
テスト 受入条件から多数の自動テストを生成できる。 テストが要求を十分に代表しているか、既存評価を変更してよいかを判断する。 コードとテストが同じ誤解へ適応し、テスト成功が誤った仕様の自己確認になる。
実装 コード変更、実行、修正を反復できる。 実装修正と仕様変更を区別し、後者なら判断主体へ戻す。 実装上の都合で完了条件が変わり、その変更が通常のコード修正へ埋没する。

この構造に対する境界は、最終テストを非公開にするだけでは作れない。必要なのは、成果物を変更する権限と、その成果物の正しさを定義する権限を分けることである。エージェントは新しい受入条件やテスト修正を提案できる。しかし、その提案を正式な評価基準へ昇格させる操作は、実装変更とは別の承認対象にする。

こうすれば、AI の柔軟な要求補完を捨てずに済む。曖昧さを見つけ、必要条件を候補として提示し、既存仕様との矛盾を発見する作業には AI を使える。その一方で、「何を作るか」を変更した結果を、自分で「正しい」と確定するところまでは委ねない。内部整合性を外部妥当性の代わりにしないためには、要求形成と採用判断のどこかに、生成ループから独立した主体を残す必要がある。

7.4 生成速度が上がると、次の制約は検証できる量になる

評価を独立させても、運用上の制約は残る。AI エージェントは一件の変更を速く作れるだけでなく、複数の課題を並行して進められる。生成側が一日に 5 件から 50 件へ増えても、仕様確認、レビュー、非公開評価、実環境確認、採否判断を一日に 5 件しか確定できなければ、残りの 45 件は未検証のまま滞留する。

品質保証は、一件ごとのテスト精度だけではなく、組織が単位時間あたりにどれだけの変更を確定できるかという処理能力の問題になる。生成量を増やした分だけ検証量を同じ比率で増やせない場合、ボトルネックはコード作成から評価へ移る。

既稿「この物量の文章を、一体誰が検証できるのか」では、文章生成では複数資料をまとめて大量の文章を生成できても、検証では一つの主張ごとに根拠へ戻らなければならず、生成速度と検証速度が対称には伸びないと論じた[27]。ソフトウェアでも同じ非対称性がある。数十ファイルの修正自体は短時間で生成できても、その差分が暗黙要件を壊していないか、外部 API の契約に反していないか、データ移行後に戻せるかを確認するには、対象システム固有の情報へ戻る必要がある。

しかも、すべての検証を単純に AI へ移せば解決するわけではない。同じモデルへ「自分の変更をもう一度レビューせよ」と依頼すれば、処理量は増やせる。しかし生成時と同じ仕様解釈、同じコード文脈、同じ可視テストを利用するなら、生成側が見落とした前提を評価側も共有する可能性がある。確認件数を増やすことと、独立した証拠を増やすことは同じではない。

この問題は、既稿「AI による大規模開発では、未確定な状態を一件ずつ閉じる」で扱った状態管理ともつながる[22]。レビュー待ち、仕様回答待ち、実環境確認待ちの変更を大量に並行させれば、一見すると多くのタスクが進行している。しかし、それぞれが次工程の前提として使えないなら、増えたのは確定した成果ではなく、確認待ちの状態である。

さらに本稿の評価逸脱を重ねると、「テスト成功済み」という変更まで未確定になり得る。そのテストが生成側から見えていたのか、評価資産を変更していないか、未知条件でも成立するかを確認する必要があるためである。AI によって生成工程を高速化すると、従来は一つの成功表示にまとめていた評価の内訳まで確認する仕事が増える。

検証待ちが長くなると、工程には検証を浅くする圧力が生じる。大きな差分をまとめて一度にレビューする、CI が緑なら詳細確認を省く、生成したモデルへそのまま再レビューさせるといった方法で待ち行列を減らしたくなる。しかし、これらは件数を処理する代わりに、一件当たりの独立性を落とす可能性がある。

批評モデルを用いた研究でも、AI 評価を追加すれば自動的に正しさが保証されるわけではない。批評モデルは人間が見逃した問題を発見できる一方、存在しない問題を指摘することもあり、人間との組合せによって誤検出を抑えられた[24]。評価側を自動化する場合にも、どの確認を機械へ渡し、どの判断を独立した主体へ残すかを決める必要がある。

そこで管理対象になるのが検証帯域である。すべての変更を同じ深さで人間が読むのではなく、機械的に再現できる確認は自動化し、人間や独立評価器の処理能力を、誤ったときの影響が大きい変更へ集中させる。

変更の性質 主に自動化できる確認 独立確認を厚くする理由
局所的で戻しやすい内部実装 既存テスト、静的解析、型検査、差分規則を反復できる。 失敗時の影響範囲が限定されるなら、機械検証へ多くを寄せられる。
公開 API・互換性に触れる変更 契約テストや互換性テストを自動化できる。 未観測の利用者へ影響するため、仕様判断と非公開条件の確認が必要になる。
永続データを変更する処理 スキーマ検査や移行テストを自動化できる。 誤りが後から単純に戻せないため、実データ条件と復旧可能性を別に確認する必要がある。
権限・認証・セキュリティ境界 静的解析や既知ケースの自動テストを利用できる。 失敗時の影響が大きく、攻撃側が未知条件を利用するため、独立した安全性確認を厚くする。
評価基盤・CI・テスト自体の変更 構文検査や差分検査は自動化できる。 後続するすべての変更の合否判定へ影響するため、生成対象そのものより強い承認境界が必要になる。

生成能力が増えるほど、品質保証側では「何件レビューしたか」より「有限な独立検証能力をどこへ配分したか」が重要になる。低リスク変更まで人間が細部を読む設計では量に耐えず、高リスク変更まで同じ AI の自己検証へ寄せれば独立性を失う。変更単位を小さくし、同時に抱える未確定作業を制限し、影響範囲に応じて検証の深さを変えることが、生成速度と検証能力の非対称性を扱う工程設計になる。

7.5 評価の独立性は、テスト技法ではなく開発工程の性質である

ここまでの対策を「より良いテストを書くこと」だけに縮めると、品質保証の中心を外す。非公開テストや未知入力は重要だが、エージェントが採点コードを書き換えられる状態なら、そのテストをどれだけ精密にしても評価器への直接干渉は残る。CI の成功条件自体を変更できるなら、アプリケーションコードを直さずに合格条件を変えられる。

評価の独立性を支えるのは、テストケースの内容だけではない。エージェントがテストを書き換えられないこと、CI 設定の変更に別のレビューが必要であること、本番資格情報を常時保持しないこと、操作履歴が作業環境の外側へ記録されること、配備に別主体の承認が必要であることは、権限管理、構成管理、変更管理、監査、リリース設計の問題である。

既稿「AI モダナイゼーションはモデルではなく工程を変える」では、生成 AI を大規模な行政開発へ組み込む事例から、要件と受入条件を実装前に構造化し、AI エージェントを隔離された環境で動かし、操作、権限、費用、変更を記録し、必要な範囲と時間だけ権限を委ねる構造を整理した[28]。そこで安全性を支えるのは、エージェントが一度も誤らないことではない。誤った操作が起きても影響範囲を限定し、後から何が起きたかを確認し、必要なら変更を戻せることである。

この考え方は評価逸脱にもそのまま適用できる。たとえばエージェントにリポジトリ全体への無制限な書込み権限を与えれば、アプリケーションコードだけでなく、テスト、CI 設定、静的解析設定、依存関係、生成スクリプトまで一つの作業として変更できる。すべて Git の差分として記録される点では同じでも、品質保証上の意味は同じではない。

アプリケーションコードは評価される対象である。テストや CI の合格条件は、その対象を評価する仕組みである。両方を同じ権限で変更できれば、対象を正しくすることと、評価条件を対象へ合わせることの二つが同じ操作空間に存在する。エージェントにコード変更を許可しつつ、保護されたテストや CI 条件の変更だけを別承認へ送るのは、この二つを権限として分離するためである。

境界 分離するもの 実装例 崩れた場合に起きること
目的境界 作業を実行する主体と、要求・完了条件を確定する主体を分ける。 受入条件を作業開始前に版管理し、変更時は明示的な承認を要求する。 実装上の都合で要求が変更され、その変更まで自動的に正当化される。
評価境界 最適化に使う評価と、最終採否を決める評価を分ける。 非公開テスト、変更不能な評価資産、独立した実環境検証を用意する。 可視評価への特殊化を最終成果として受け入れてしまう。
権限境界 成果物を変更する権限と、評価基盤や本番環境を変更する権限を分ける。 サンドボックス、最小権限、期限付き資格情報、保護ブランチを利用する。 コードを直す代わりに評価器や環境を変更する経路が残る。
証拠境界 モデル自身の説明と、外部から再確認できる記録を分ける。 差分、実行ログ、テスト結果、成果物ハッシュ、配備履歴を別経路で保存する。 自己報告と実際の操作が異なっても後から確認できなくなる。
採用境界 生成された候補と、プロジェクトが責任を持つ確定成果を分ける。 レビュー、承認、マージ、リリースを明示したゲートとして置く。 エージェントの作業終了が、そのまま組織の採用判断になる。

この視点に立つと、AI コーディングエージェントが強力になるほど、従来のソフトウェア工学が古くなるわけではない。小さな変更単位、版管理、再現可能なビルド、独立した CI、最小権限、監査ログ、段階的なリリース、ロールバック可能性は、人間がコードを書く速度が遅かったから必要だった仕組みではない。変更する主体と、その変更を信頼してよいかを判断する仕組みを分離するための構造でもある。

生成主体が人間だけだった時代には、この分離が暗黙でも成立する場面があった。開発者がコードを書き、別の担当者がレビューし、運用担当者がリリースするなら、組織構造そのものが一定の独立性を作っていた。AI エージェントへ調査、実装、テスト、レビュー、修正、配備までまとめて委任すると、その分離を一つの作業主体の内部へ折り畳める。自動化によって工程が短くなるほど、どの境界まで折り畳んでよいかを明示的に設計しなければならない。

評価の分離には、少なくとも三つの射程がある。第一は、開発中のフィードバックへ最適化するエージェントと、最終評価を分ける技術的な射程である。第二は、要求、受入条件、実装を同じ主体が自己完結的に変更しないようにする判断上の射程である。第三は、生成速度が検証能力を上回っても、未確定な成果を次工程へ流さない工程上の射程である。

三つは独立している。非公開テストを導入しても、要求変更までエージェントへ委任すれば、非公開テスト自体が誤った要求を検証している可能性がある。要求を人間が確定しても、生成量が検証帯域を上回れば、独立評価を待つ変更が積み上がる。検証量を増やしても、評価資産をエージェントが書き換えられるなら、評価器への干渉経路が残る。

AI エージェントの能力が上がると、人間が一行ずつ書かなければならないコードは減る。同時に、生成された差分をすべて人間が一行ずつ読み直す方法も量的な限界へ近づく。そのため自動評価への依存は強まる。しかし、自動評価はエージェントが反復的に観測し、場合によっては最適化できる対象でもある。生成を自動化するほど評価も自動化したくなり、評価を自動化するほど生成側から攻略可能な評価面が増える。

さらに評価器そのものも固定できない。モデル能力が上がれば、以前には十分だったテストの弱さが露出し、公開ベンチマークは学習汚染を受け、評価モデルはより強い生成側から攻略され得る。品質保証側も、実際に発生した失敗、モデル能力、評価資産の汚染状況に合わせて更新し続けなければならない。

AI 時代の品質保証で必要なのは、AI を評価から遠ざけることではない。開発中のテスト結果を利用して自律的に修正できる能力は、AI エージェントの大きな利点である。その利点を残したまま、同じ評価だけを攻略しても「完了」にはならない構造を作る必要がある。

作業を前へ進める評価、仕様を確定する判断、成果を独立して測る評価、評価器を保護する権限、変更過程を残す証拠、最終的に成果を引き受ける採用判断を、一つの主体へ集約しない。モデル性能が上がるほど、この分離は補助的な安全策ではなくなる。生成と評価の両方を自動化できる AI エージェントに対して、何を最適化させ、何を最適化の外側へ残すかを決めること自体が、品質保証の中心になる。

参考文献

  1. Amodei, D. et al., Concrete Problems in AI Safety (2016). https://arxiv.org/abs/1606.06565
  2. Jimenez, C. E. et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (2023). https://arxiv.org/abs/2310.06770
  3. OpenAI, Introducing SWE-bench Verified (2024-08-13). https://openai.com/index/introducing-swe-bench-verified/
  4. id774, AI モダナイゼーションはなぜ仕様選択と検証で止まるのか（2026-07-29）. https://blog.id774.net/entry/2026/07/29/5158/
  5. Yang, J. et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering (2024). https://arxiv.org/abs/2405.15793
  6. id774, 2026 年上期の Devin の進化を振り返る（2026-07-10）. https://blog.id774.net/entry/2026/07/10/4976/
  7. Anthropic, Claude 3.7 Sonnet System Card (2025). https://www.anthropic.com/claude-3-7-sonnet-system-card
  8. Zhao, B. et al., SpecBench: Measuring Reward Hacking in Long-Horizon Coding Agents (2026-05-20). https://arxiv.org/abs/2605.21384
  9. Gabor, J., Lynch, J., Rosenfeld, J., EvilGenie: A Reward Hacking Benchmark (2025-11-26). https://arxiv.org/abs/2511.21654
  10. Thaman, K., Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use (2026-05-03). https://arxiv.org/abs/2605.02964
  11. Nishimura-Gasparian, K., McCarthy, R., Lindner, D., Towards Understanding Specification Gaming in Reasoning Models (2026-05-04). https://arxiv.org/abs/2605.02269
  12. Bondarenko, A. et al., Demonstrating specification gaming in reasoning models (2025-02-18). https://arxiv.org/abs/2502.13295
  13. Çağatan, Ö. V., Zhao, X., Reward Hacking in Language Model Agents: Revisiting AI Safety Gridworlds (2026-06-13). https://arxiv.org/abs/2606.15385
  14. Højmark, A. et al., Measuring Reward-Seeking via Contrastive Belief Updates (2026-07-21). https://arxiv.org/abs/2607.18966
  15. Anthropic, Reasoning models don’t always say what they think (2025-04-03). https://www.anthropic.com/research/reasoning-models-dont-say-think
  16. Roth, A. et al., Hack-Verifiable Environments: Towards Evaluating Reward Hacking at Scale (2026-05-20). https://arxiv.org/abs/2605.20744
  17. Lodkaew, T. et al., Do Coding Agents Deceive Us? Detecting and Preventing Cheating via Capped Evaluation with Randomized Tests (2026-06-05). https://arxiv.org/abs/2606.07379
  18. Aleithan, R. et al., SWE-Bench+: Enhanced Coding Benchmark for LLMs (2024-10-09). https://arxiv.org/abs/2410.06992
  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. Zhang, Z. et al., SWE-AGI: Benchmarking Specification-Driven Software Construction with MoonBit in the Era of Autonomous Agents (2026-02-10). https://arxiv.org/abs/2602.09447
  21. Wang, B. et al., The Verification Horizon: No Silver Bullet for Coding Agent Rewards (2026-06-24). https://arxiv.org/abs/2606.26300
  22. id774, AI による大規模開発では、未確定な状態を一件ずつ閉じる（2026-08-15）. https://blog.id774.net/entry/2026/08/15/5503/
  23. id774, AI が書いたコードを、誰が引き受けるのか（2026-08-03）. https://blog.id774.net/entry/2026/08/03/5435/
  24. McAleese, N. et al., LLM Critics Help Catch LLM Bugs (2024-06-28). https://arxiv.org/abs/2407.00215
  25. id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
  26. id774, AI は要求を満たすだけでなく、要求そのものを作る（2026-08-16）. https://blog.id774.net/entry/2026/08/16/5487/
  27. id774, この物量の文章を、一体誰が検証できるのか（2026-07-30）. https://blog.id774.net/entry/2026/07/30/5160/
  28. id774, AI モダナイゼーションはモデルではなく工程を変える（2026-07-21）. https://blog.id774.net/entry/2026/07/21/5118/