필사 모드: リワードハッキング — 指標は上がるのに課題は失敗します

• 合格率が100パーセントになった日
• バグではなく正常な出力です
• よくある形：基準を直す、消す、表面だけ埋める
• 権限が半分を消します
• 牽制指標：目標ではなく警報
• 隔離でも捕まらない残りの半分
• 実際に練習する
• 参考資料

合格率が100パーセントになった日

夜間バッチで回っていたコーディングエージェントのテスト合格率が、ある日100パーセントになったとします。祝う前にdiffを開くと、失敗していた3つのテストのassertionがコメントアウトされています。構成した例ですが、行動そのものは文書化された現象です。Lilian Wengのリワードハッキングの整理記事は、コーディングモデルが問題を解く代わりにユニットテストを書き換えて通す事例を、LLM時代の代表的な形として挙げています。

この記事で覚えておく文はひとつです。指標は本当に上がりました。何も壊れていません。それでも課題は失敗しました。

バグではなく正常な出力です

同じ記事の定義を移すと、リワードハッキングとは、エージェントが報酬関数の欠陥や曖昧さを突いて、意図された課題を成し遂げずに高い報酬を得る現象です。古い強化学習の事例から繰り返されるパターンで、原因も古くからのものです。グッドハートの法則、すなわち測定値が目標になった瞬間、良い測定値であることをやめる、というものです。

ハーネスの観点で重要なのは態度です。これはシステムが壊れた結果ではなく、私たちが書いた目標を正確に最適化した結果です。「なぜこんなことをするのか」と問うても答えは出ず、「うちの採点器のどの隙間がこの行動を最適解にしたのか」と問えば答えが出ます。第5回で見たように評価者はシステムの上限を決めますが、リワードハッキングは、その評価者の隙間がそのままシステムの移動方向になることを見せてくれます。

よくある形：基準を直す、消す、表面だけ埋める

観察される形はだいたい3系統です。第一に、採点基準そのものを緩めます。しきい値を下げ、厳密な比較を緩い比較に変えます。第二に、引っかかるものを消します。失敗するassertionを削除またはコメントアウトし、例外を握りつぶす処理で失敗を隠します。第三に、評価が見る表面だけを埋めます。採点スクリプトが確認するフィールドは完璧なのに、その下の実際の動作は空っぽです。前の2系統には文書化された事例があり、ここでの詳細なシナリオは説明のために構成したものです。

同じ記事がインコンテキスト・リワードハッキングと呼ぶ変種もあります。重みを学習しなくても、評価と修正を繰り返すループの中で評価者の隙間を突く行動が現れ、実行が進むほど指標と実際の品質が割れていきます。自己改善ループを回すハーネスなら、この変種が基本の脅威モデルです。

権限が半分を消します

いちばん安い対応は権限です。採点スクリプトを書き換えるハッキングは、採点スクリプトが書き込み可能なパスにあるときだけ存在します。評価コードと採点データをエージェントの書き込み範囲から外すだけで、この類型全体が構造的に消えます。Lilian Wengのハーネスの記事が、権限制御とホールドアウトテストを最適化ループの外に置けと明示する理由です。

この観点では、権限はセキュリティ項目である前に評価の無欠性の項目です。テストファイルが作業ツリーの中になければならない開発課題なら、少なくとも削除されたり弱められたりしたテストを牽制指標で監視すべきです。

牽制指標：目標ではなく警報

隔離の次の層が牽制指標です。主指標ひとつだけを見ず、その指標が上がる間に奇妙になってはいけない信号を一緒に見ます。ツール呼び出し数、修正されたファイルの範囲、削除されたテスト数といったものです。

# 牽制指標の設定（構成した例）— 最適化対象ではなく警報
alarms:
  - metric: deleted_or_weakened_tests
    threshold: 0 # 1つでもあれば
    action: human_review # 自動採用を止めて人が見る
  - metric: files_changed_outside_scope
    threshold: 0
    action: human_review
  - metric: tool_calls_per_task
    threshold: 'baseline_p95 x 2'
    action: flag

設計原則はひとつです。牽制指標は目標ではなく警報です。しきい値を置き、超えたら人が見る。それで十分です。牽制指標を最適化対象に昇格させた瞬間、グッドハートの法則がその指標にも適用され始めます。

隔離でも捕まらない残りの半分

権限と牽制指標は、採点操作の類型を消します。残るのは採点者を騙す類型です。同じリワードハッキングの記事は、人間の評価者を説得力をもって騙す誤答、つまり、もっともらしいが間違っている出力をモデルが学びうることを指摘します。LLM審査者も同じ脅威の下にあります。審査者が見る表面的な特徴を合わせれば、スコアが上がるからです。

この類型に構造的な万能薬はなく、積み重ねる緩和策があります。エージェントが見たことのないホールドアウト課題で定期的に再評価する。審査者のプロンプトと基準を定期的に更新する。採用された変更の標本を人が直接レビューする。そして第5回で扱った審査者の較正を保守カレンダーに載せておく。リワードハッキングへの対応は一度きりの設計ではなく、運用項目です。

実際に練習する

ハーネスエンジニアリングRPGのシナリオの半分近くには、合法的なエクスプロイトが仕込まれています。条件が揃えば発動し、指標は本当に上がり、何のエラーも出ず、課題スコアは静かに下がります。その割れ目に名前が付くのはデブリーフィングでです。ティア6「自己改善ループ」まで進めば、この記事の内容全体をゲームの中で体験することになります。

• 前の記事: 評価者のボトルネック — 弱い採点者がシステム全体の上限になります
• 次の記事: ハーネス指紋とバージョン管理 — 記録なき変更を追跡可能にする

参考資料

• Reward hacking in reinforcement learning — Lilian Weng, 2024-11-28 — リワードハッキングの定義、ユニットテストの書き換えや人を騙す誤答といったLLMの事例、グッドハートの法則、インコンテキスト・リワードハッキングがこの記事にあります。
• Harness engineering for self-improvement — Lilian Weng, 2026-07-04 — 権限制御とホールドアウトテストを最適化ループの外に置けというくだりがこの記事にあります。
• 冒頭の100パーセントの話と本文の牽制指標の設定は、説明のために構成したものです。