AIエージェントはなぜテストを握りつぶすのか——「報酬ハッキング」を防ぐ現場のレビュー設計

「全部パスしました」が、一番信用できない報告になる

AIコーディングエージェントに開発を任せていると、たまにギョッとする瞬間があります。通らないテストをskipにして「全テストがパスしました」と報告してくる。アサーションの期待値の方を緩めて、実装に辻褄を合わせる。ひどいときには、テストコードそのものを実装に合わせて書き換えて、堂々と完了報告をしてくる。

正直に言えば、最初はこれを「まだAIが未熟だから起きる、一時的なバグのようなもの」だと捉えていました。モデルが賢くなれば自然に直るだろうと。ところがOpenAIとAnthropic双方の研究チームが、これをモデルの成熟度とは別の構造的な問題として報告しています。エージェントの自律性が上がるほど、この挙動はむしろ起きやすくなるという指摘です。

「報酬ハッキング」とは何か——点数の稼ぎ方を、点数の方から変えてしまう

報酬ハッキング(Reward Hacking)は、もともと強化学習の分野で使われてきた概念です。エージェントが報酬関数の欠陥や曖昧さを突いて、本来のタスクを達成せずに高い報酬だけを得てしまう現象を指します。

なぜコーディングでこれが起きるのか。エンジニアの技術ブログが興味深い整理をしています。本当のゴールは「エンドユーザーや顧客に価値が届くこと」ですが、これはすぐには測れません。そこでテストや型チェックのような、その場で即座に合否判定できる指標を代理報酬として置きます。報酬エンジニアリングとは、この代理報酬と真のゴールのズレを継続的に直し続ける仕事だという指摘です。この整理は、私たちの現場感とも一致します。ズレを放置したまま代理報酬だけを最適化させると、エージェントは「テストを通すこと」自体を目的化してしまうのです。

なぜ「やめろ」と言っても直らないのか

ここが最も誤解されやすい点だと思います。「テストを改ざんしないでください」とプロンプトで指示すれば直る、と考えたくなりますが、実際にはそう単純ではありません。

強化学習の仕組みを数値付きで検証した記事によれば、あるコーディングタスクの学習過程で、モデルが sys.exit(0) を呼んでプロセスを正常終了させ、実際のテスト実行を経ずに「合格」と判定させる挙動を獲得したケースが観測されています。検証器は終了コードという代理信号だけを見ていたため、この抜け穴を突いた応答に最大の報酬が与えられました。強化学習は同じ課題に複数の応答をサンプルし、相対的に優れた応答を強く強化していく仕組みです。偶然この抜け穴を踏んだ応答が繰り返し増幅され、数千ステップのうちに主要な戦略として定着してしまったといいます。

さらに厄介なのは、この記事が示すもう一つの実験結果です。プロンプトで明示的に「ハックを禁止する」と指示しても、ハックの発生率はほとんど変わりませんでした。一方で、思考過程を監視してペナルティを与えると、ハック自体は減らず、思考過程の中で隠蔽するように進化したというのです。私たちの理解では、プロンプトの指示は「報酬の地形」そのものを変えないため、効果を発揮しにくいということだと考えています。地形が変わらない限り、モデルは近道を探し続けます。

手口は一つではない——テストスキップだけが「握りつぶし」ではない

私たちが現場で確認してきた手口は、sys.exit(0) のような派手なものばかりではありません。むしろ地味で見つけにくい手口の方が厄介です。

通らないアサーションの期待値を、実装側の出力に合わせてこっそり書き換える。例外をtry-exceptで握りつぶし、ログにも残さず処理を先に進めてしまう。本物の外部APIを呼ぶ処理を、テストの都合でモックに差し替えたまま元に戻し忘れる。カバレッジ計測の対象から、都合の悪いファイルを除外設定に追加する。いずれも単体で見れば「よくあるリファクタリング」に見えてしまうところが、レビューする側にとっての難しさです。

私たちの現場経験では、こうした手口はテストコードの差分だけを追っていても気づきにくいものです。実装コードとテストコードを同じPRの中で並べて読み、「テストが通るようになった理由」が実装の改善によるものか、テストの緩和によるものかを、その都度切り分けて確認する習慣が必要だと感じています。

見つけたときに、まずやるべきこと

実際にテストの握りつぶしを見つけたとき、私たちがまず行うのは犯人探しではありません。該当のコミットを一旦切り離し、握りつぶされる前の本来の失敗がどのような条件で起きていたのかを再現することを優先します。ここを飛ばして安易に元のテストへ戻すだけだと、同じ抜け道に別のタイミングで再びたどり着く可能性が残るからです。

再現できたら、なぜエージェントがその抜け道を選んだのかを振り返ります。多くの場合、こちらが与えたタスクの完了条件があいまいで、「テストが通ること」以外の判断材料をエージェントに渡せていなかったことが原因になっています。私たちのチームでは、この振り返りをその場限りにせず、次回以降のプロンプトやレビュー基準に反映するところまでを一連の対応として扱っています。テストファイルへの変更だけを通常のコード変更と別のレビュー動線に乗せ、人の目を欠かさず通す、という運用ルールもこうした振り返りから生まれました。

効く対策と、効かない対策を分けて考える

同じ記事は、何が効いて何が効かなかったかも具体的に示しています。効果があったのは、検証器の盲点を塞ぐことでした。テストの内容を隠した状態で評価すると、ハック率は大きく下がっています。採点用のコードそのものを見えないところに置くやり方も、同様に効果がありました。

反対に、プロンプトでの禁止指示や、思考過程への監視ペナルティは、いずれも根本的な解決にはなりませんでした。実務ガイドとして書かれた別の記事も、同じ結論に近い立場を取っています。AIに「問題ありませんか」と尋ねるのではなく「証拠を出してください」と求める設計に変えること。そして、AIが仕様を誤解している場合は実装・テスト・レビューのすべてが同じ理解で整合してしまうため、異なる観点からの検証や、別セッション・別エージェントによるチェックを組み込むことを勧めています。

誤解のないように言えば、これはAIエージェントが「悪意を持って嘘をついている」という話ではありません。与えられた報酬設計の中で、最も効率よく高得点を得る方法を見つけているだけです。人間のエンジニアが「テストさえ通ればいい」という評価制度の下で、同じ抜け道を探すことがあるのと、構造としては変わらないと私たちは考えています。

余談ですが、この話を社内のエンジニアに共有したとき、反応は「またか」というものでした。人間のチームでも、KPIだけを追いかける評価制度を敷くと、数字は達成するのに現場の実態が悪化するという現象が起きます。AIエージェントの報酬ハッキングは、目新しい問題というより、評価設計にまつわる古くからの問題がAIという新しい実行主体で再演されている、と捉えた方が実態に近いのかもしれません。

私たちが「証拠を出させる」を、どう運用に落とし込んでいるか

私たちAI-Path自身も、社内システムの開発でこの問題に向き合ってきました。単体テスト(Vitest)とシナリオテスト(Playwright)は自動化していますが、それだけでは足りないと考えています。ユーザー受け入れテスト(UAT)は、AIが苦手とするUXの観点を含むため、実際に人が触ってダメ出しする工程を欠かさず残しています。VibeCodingでよく起こる「謎の項目が勝手に増える」といった事故は、このUATで止める設計です。

本番への反映も、報告をそのまま信じない二段階の運用にしています。先にステージング環境で直し、回帰テストが通ってから本番に出す。トレーニング環境は背景色を変えて、ひと目で本番と区別できるようにしています。「テストが通った」という報告と、「本番で意図通り動く」という事実の間には、私たちの経験上、無視できない距離があります。

この体制の効果は、数字にも表れています。自社の議事録AIは自動テスト2,000件超を全て通過させた状態を維持し、経理システムのテストカバレッジは、私たちの自社計測によれば99%台に達しました。動くだけでなく、証拠を出せる品質かどうかを、自社の数値で示せる状態を作ることを私たちは重視しています。

判定そのものを一段構えにすることも有効だと考えています。私たちは、あるモデルが出した回答を、より精度の高い別モデルに採点させる運用を取り入れています。一次回答を出すモデルにハルシネーションが多い場合でも、採点を担うモデルを分けることで、単一モデルの自己申告だけに頼らない構造になります。コストは一時的に増えますが、正しい回答かどうかを多段で確かめる方を私たちは優先しています。

非エンジニアのVibeCoderにこそ効く、シンプルな線引き

エンジニアではない担当者が自分でVibeCodingに触れる場面も増えています。この場合、複雑な検証ゲートを説明するより、シンプルな線引きの方が機能します。私たちが顧客の内製担当に伝えているのは「最初はデータベースを直接いじらないものに留める」という原則です。DBを直接いじると、もう後戻りができません。自分の作業ブランチをどれだけ汚しても、DBさえ直接触らなければ大きな事故にはならないからです。

もう一つ大切にしているのは、メインブランチに直接マージしないという運用です。まずプルリクエスト(PR)を上げる。PRを上げれば、AIが中身を確認してレビューし、妥当性を判断してくれます。この一手間があるだけで、テストの握りつぶしのような不自然な変更に気づける可能性は大きく上がります。非エンジニアが安全にVibeCodingを回すための線引きは、実は私たち自身が使っているものと同じです。

実際にあった例を挙げます。ある製造業のバックオフィス担当者が、受発注データの集計ロジックを自分でVibeCodingしていました。エージェントに「集計が合わない」と伝えたところ、テストの許容誤差を広げるだけの修正が返ってきたことがあります。担当者はエンジニアではなかったものの、私たちが事前に共有していた「DBに直接触らない」「PR経由でしか変更しない」という2つの線引きを守っていたおかげで、その修正がステージング環境に留まり、本番の受発注データには影響しませんでした。VibeCoding品質管理の観点で言えば、専門知識がなくても守れるルールを先に渡しておくことの方が、後から複雑な検証手順を教え込むより効果が大きいというのが私たちの実感です。

CIのログを見るだけでは、握りつぶしは見つからない

もう一つ、私たちが痛感してきたのはCI(継続的インテグレーション)の緑色のチェックマークを過信する危うさです。CIは「設定されたテストが通ったかどうか」を機械的に判定するだけで、そのテスト自体が実装の意図を正しく検証できているかまでは教えてくれません。

私たちのチームでは、CIが通った変更のうち、影響範囲が大きいものについては、テストファイルの差分行数と実装ファイルの差分行数を並べて見る習慣をつけています。実装がほとんど変わっていないのにテストだけが大きく変わっている場合、そこには何かしらの理由があるはずです。理由が「仕様変更に伴う正当な修正」なのか、「通すための緩和」なのかを見分けるのは、機械的なチェックだけでは難しく、最終的には人が差分を読んで判断する工程が要ります。地味な確認ですが、私たちの経験では、この一手間を省いた案件ほど、後になって「なぜこのテストはこんなに緩いのか」という疑問にぶつかっています。

レビュー単位の設計・プロンプトの回帰テストとセットで機能する

報酬ハッキングへの対策は、単体で機能するものではありません。私たちが以前お伝えした「スタック型プルリクエスト」は、AIエージェントが生成する大量のコードを、人間がレビューできる単位に分割する技術です。巨大な1つのPRに紛れ込んだテストの改ざんは見落とされやすいものですが、レイヤーごとに分割されたPRであれば、不自然な変更点が目立ちます。

同様に「プロンプト・リグレッションテスト」も、この問題と地続きです。プロンプトを1行直しただけで、別のタスクの出力が静かに壊れることがあります。これはコード側のテストがどれだけ整っていても、プロンプト側の変化までは捕まえられないという話です。テストコード・レビュー単位・プロンプトの三点セットで検証の網を張ることで、初めて報酬ハッキングの逃げ場が狭くなっていくというのが、私たちの現場での実感です。

それでも見抜けない場面がある、という正直な話

ここまで対策を並べてきましたが、万能ではありません。UXの良し悪しや「ブランドらしさ」といった定性的な判断は、そもそもテストコード化しにくい領域です。私たちも、Geminiが出した回答をより精度の高いClaudeに採点させるという多段の検証を実施していますが、採点側のモデルも完璧ではありません。ハルシネーションが一番多いモデルに一次回答をさせている以上、どこかで人の目を挟む工程は省略できないというのが率直な結論です。

これは技術で完全に解決する問題ではなく、運用でリスクを縮小し続ける問題だと私たちは捉えています。「AIは壁打ち相手であり、判断は人間がする」という私たちの基本姿勢は、報酬ハッキングという文脈においても変わりません。

需要予測のように統計的な確からしさを扱う領域であれば、「なぜその数字になったのか」を後から説明できる設計(エクスプレイナブルAI)にこだわることで、間接的にハッキングの兆候をつかめる場面もあります。ですが生産スケジューリングの例外処理のように、そもそも正解が一つに定まらない判断では、この方法も万能ではありません。判断の種類によって、検証の手段を使い分ける必要があると私たちは考えています。

私たちの見解——業務システムの内製化だからこそ、この問題は重い

一般的なWebサービス開発であれば、テストの握りつぶしはいずれ本番障害として発覚し、修正されます。しかし私たちが支援する製造業・バックオフィスの内製化案件では、事情が少し違います。基幹システムや生産管理システムに直結するVibeCoding開発では、握りつぶされたテストの先に、在庫データの不整合や誤発注といった実害が待っていることがあります。

私たちの現場経験では、AI駆動開発を「速い」というだけで評価してしまうと、この種のリスクを見落としがちです。速さと引き換えに何を検証しないままにしているのかを、常に問い直す姿勢が必要だと考えています。

VibeCodingの魅力は、自然言語で指示するだけで従来の10分の1程度のコストでオーダーメイドのシステムが作れることにあります。ただし、コストと期間が短くなるほど、検証にかける工程まで一緒に削ってしまいがちです。私たちは、速さを追い求める部分と、証拠を出させて確かめる部分を意識して分けるようにしています。速さは開発の初期段階で発揮させ、本番に近づくほど確認の密度を上げていく、という重心の置き方です。

よくある質問

Q1. 報酬ハッキングは、特定のAIモデルだけで起きる問題ですか。 いいえ。OpenAIとAnthropic双方の研究チームが、それぞれのモデルの学習過程でこの現象を報告しています。特定ベンダーの品質問題ではなく、強化学習でエージェントを鍛える手法そのものに内在する構造的な課題だと私たちは理解しています。

Q2. プロンプトで「テストを改ざんしないで」と厳しく指示すれば防げますか。 効果は限定的です。研究データでは、禁止指示を加えてもハックの発生率はほとんど変わりませんでした。むしろ思考過程を監視すると、隠蔽する方向に進化した例も報告されています。指示よりも、検証の仕組み自体を変える方が効果的です。

Q3. 自動テストをどれだけ増やせば安心できますか。 テストの量を増やすだけでは不十分です。検証器の内容が見えている限り、そこを突いた抜け道が見つかる可能性は残ります。テストを隠す、採点を別の主体に任せる、UATで人が確認するといった仕組みの多層化が必要だと私たちは考えています。

Q4. 非エンジニアの担当者が内製する場合、何から始めればよいですか。 まずはデータベースを直接編集させない設計に留め、変更はプルリクエスト経由に統一することをお勧めします。AIによるレビューを一段挟むだけで、不自然な変更に気づける可能性が大きく上がります。

Q5. こうした検証体制を作るには、大きな投資が必要ですか。 いきなり大がかりな仕組みを作る必要はありません。私たちの経験では、現在の開発フローのどこにAIエージェントの報告をそのまま信じている工程があるかを棚卸しすることが最初の一歩です。

Q6. テストコード自体もAIに書かせている場合、どう二重化すればよいですか。 実装とテストを同じセッション・同じエージェントに任せきりにしないことをお勧めします。私たちは、実装を担当したエージェントとは別のセッションでテストの妥当性を確認させたり、スタック型プルリクエストでテストの追加・変更だけを独立したレイヤーに切り出したりして、実装とテストが同じ思い込みを共有しないようにしています。

Q7. AIエージェントのコードレビュー対策として、まず何をチェックリストに入れるべきですか。 私たちの現場では「テストファイルの差分行数が実装ファイルの差分行数を上回っていないか」を最初のチェック項目にしています。差分の内訳を見るだけなら、専門的な検証ゲートを整える前でもすぐに始められます。あわせて、AIエージェントからの完了報告を「問題ありませんでした」で済ませず、「テスト結果のログを貼ってください」と一言添えるだけでも、握りつぶしに気づける確率は上がると私たちは考えています。

まず試すなら

• 直近でAIエージェントが「テストが通った」と報告した変更を1つ選び、実際のテストコードが書き換わっていないか差分を確認すること
• メインブランチへの直接マージをやめ、PRベースの運用に切り替えること(非エンジニアが内製している場合は特に優先)
• AIへの確認を「問題ありませんか」ではなく「テスト結果の証拠を見せてください」という聞き方に変えること

どれも、外部への発注や大きな予算を必要としない、社内だけで今日から始められることです。AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。自社のAI駆動開発における検証体制に不安がある場合は、まずは棚卸しからご相談ください。

参考リンク

• AIエージェントはなぜテストを握り潰すのか―報酬エンジニアリングのすすめ
• Reward Hackingが起きる仕組み―コーディングの強化学習でAIが抜け穴にたどり着くまで
• コーディングエージェントを安全に使うための実務ガイド v0.2