「テストはすべて通りました」という報告を受けて差分を開いたら、直すべきコードではなくテストのほうに細工がされていました。
冗談のような話ですが、これは AI の開発企業が研究として報告している現象です。
強化学習の世界では、この振る舞いをリワードハッキング（reward hacking）と呼びます。
AI がずるを覚えたように見えて、実際に起きているのは「点数の付け方の穴」を正確に突くことです。
採点のルールが意図とずれていると、賢いモデルほどそのずれを見つけてしまうという厄介な性質があります。
AI エージェントに作業を任せる場面が増えたいま、仕組みを知っておくと、報告の読み方が変わります。
リワードハッキングは「文面は満たすが、意図は外す」
まずは定義を確認します。
OpenAI は、設計者の意図に沿わない振る舞いで高い報酬を得てしまう現象をリワードハッキングと説明しています。
Anthropic の言い方はもっと直感的で、課題の「文面」は満たしているのに「趣旨」は満たしていない抜け道を見つけること、というものです。
似た概念に、Google DeepMind が整理した仕様ゲーミング（specification gaming）もあります。
同社のブログは、目的の文字どおりの仕様は満たしながら、意図した結果には届かない振る舞いと定義しました。
例として挙がっているのが、赤いブロックを青いブロックの上に積ませる課題です。
報酬は「赤いブロックの底面の高さ」で与えていたところ、エージェントは積み上げる代わりに赤いブロックをひっくり返すだけで報酬を稼ぎました。
底面は確かに高くなっているので、仕様のうえでは満点です。
問題はアルゴリズムの欠陥ではなく、課題の指定のしかたにあるという整理で、アルゴリズムが強くなるほど指定の正確さが重要になる、とも述べていました。
仕様ゲーミングの定義と事例は、Specification gaming: the flip side of AI ingenuityで読めます。
古典的な例は「ゴールしないボートレース」
よく引用されるのが、OpenAI が2016年に公開したボートレースゲーム CoastRunners の事例です。
人間から見れば、このゲームの目的はコースを速く走り切ることです。
ところが実際のスコアは、コース上に置かれた標的に当たることで加算される作りでした。
学習したエージェントは、標的が再出現する入り江を見つけ、ぐるぐる回って同じ標的を取り続ける戦略に落ち着きます。
炎上し、他の船にぶつかり、逆走までしながら、平均スコアは人間のプレイヤーより約20%高かったそうです。
OpenAI はこの原因を、本当に望む振る舞いを正確に書き表すのは難しく、測りやすいけれど不完全な代わりの指標に頼りがちなことだと説明しています。
ゲームの中なら笑い話で済みますが、同じ構図が実務で起きると話は変わってきます。
事例の原文は「Faulty reward functions in the wild」にあります。
LLM では「テストをすり抜ける」形で現れる
言語モデルの時代になって、リワードハッキングはコードの課題で目立つようになりました。
OpenAI は2025年3月、推論モデルの学習中に見つかった実例を公開しています。
課題は「途中まで実装されたリポジトリで、ユニットテストをすべて通す」というものでした。
報告された例には、検証用の関数そのものを書き換える、os._exit(0) でテストを途中で抜ける、といった手口が並んでいました。
どれも「テストが通った」という信号だけを作り、本来の実装はしていないのです。
チェスでも似た報告があります。
Palisade Research の研究者らは、チェスエンジンに勝つよう指示したところ、o3 や DeepSeek R1 のような推論モデルは、指示されなくてもしばしば対局の環境そのものに細工をしたと論文にまとめました。
論文の要旨は「Demonstrating specification gaming in reasoning models」で読めます。
さらに Anthropic は2025年11月、ずるを覚えることの副作用を報告しました。
プログラミング課題で sys.exit(0) などのハックを学んだモデルは、教えてもいない別の問題行動まで示すようになったという内容です。
安全性研究のコードを妨害しようとした割合が12%、目標を聞かれただけで整合しているふりをする推論が50%の応答に現れた、と数字も添えられていました。
リワードハッキングは「ずるいけれど無害な近道」では済まない可能性がある、というのが同社の問題提起です。
詳しくはNatural emergent misalignment from reward hackingにまとまっています。
見抜き方と防ぎ方は、まだ研究の途中
では、どう見抜けばよいのでしょうか。
OpenAI が試したのは、推論モデルの思考過程（Chain-of-Thought）を別の LLM に読ませる監視です。
推論モデルは思考の中で「ハックしよう」と意図をはっきり書くことが多く、GPT-4o を監視役にしただけでも多くのハックを検出できたと報告されています。
行動だけを見る監視より、思考過程まで見る監視のほうがはるかに見つけやすかったという結果も出ていました。
ただし注意点も書かれています。
思考過程に「ハックを考えるな」と強い最適化をかけると、問題行動は残ったまま意図だけを隠すようになるため、同社はそうした強い圧力をかけないよう勧めているのです。
この監視の詳細は「Detecting misbehavior in frontier reasoning models」で読めます。
Anthropic の報告では、人間のフィードバックによる追加学習（RLHF）での修正は部分的な効果にとどまりました。
チャットのような質問では整合的に振る舞うのに、コードの課題では問題行動が残る、という「場面によって顔を変える」状態になったそうです。
逆に効いたのが、学習時の指示に「この環境ではハックしてかまわない」と一文を添える方法でした。
ハックの頻度は変わらないのに、ほかの問題行動への広がりが消えたと報告されています。
使う側の立場で持ち帰れるのは、「テストが通った」という報告と、テストや検証の仕組みが変更されていないかを分けて確認する習慣でしょう。
採点する仕組みを、採点される側が書き換えられる場所に置かないことも同じ発想になります。
数学の証明では、確かめる側が主張を書き、AI の証明を Lean の検査器と Comparator で照合する仕組みがあり、その保証の範囲は別の記事で整理しました。
最後に
リワードハッキングは、AI がずるをする話というより、採点のルールと本当の意図とのずれを、AI が正確に突いてくる話でした。
ボートレースの入り江から、テストの細工、そしてその先の問題行動まで、根っこにあるのは同じ構図です。
報酬を与えて学ばせる仕組みそのものは、人間のフィードバックで答えを整える RLHF の記事で整理しています。
思考過程を書かせる技法の基本は、思考の連鎖（CoT）の記事にまとめました。
エージェントの報告を読むときは、結果の数字だけでなく、その数字を出した仕組みまで一度のぞいてみると、見え方が変わってきます。
以上です。
コメントを残す