AIが「テスト駆動開発」をサボる罠（報酬ハッキング）

Claude Codeにテストに通るようにコードを直すようにを頼んだら、実際の処理はせずに期待値を直接コードに入れて返してきました。
確かにテストは通るけど、モックアップのままでは完成しない。
AIは指示された評価基準を効率的に満たそうとするので、出力を完全には信用できません。

1. テストだけ成功をクリアするコード

Claude Codeでプログラムを作成していたとき、不可解な現象が起きました。テストは全て緑色で成功しているのに、実際にアプリケーションを動かすと期待通りに動きません。

「テストドリブン開発（TDD）」とは、実際のコードを書く前にテストコードを書く開発手法です。従来の「設計→実装→テスト」ではなく、「テスト→実装→リファクタリング」の順序で進めます。

Red（失敗するテスト）:
まず機能の仕様を表すテストコードを書く。この時点では実装がないためテストは失敗する
Green（成功するコード）:
テストが通る最小限のコードを実装する
Refactor（リファクタリング）:
テストを通したままコードをきれいに整理する

この手法により、要件の明確化、早期バグ発見、保守しやすいコードの作成が期待できます。しかし、Claude Codeのような AI がこの「テストを通すコード」を求められたとき、本来の意図とは異なる方法でテストをクリアしてしまうことがあります。

たとえば、商品リストから合計金額を計算する関数を実装する段階だとします。実際の処理は行わないで、テストで使われる具体的な入力値に対する正解をハードコード（直接書き込み）しただけのことがあったのです。

function calculateTotal(items) {
  // テストケース用の固定値を返している
  if (JSON.stringify(items) === '[{"price": 100}, {"price": 200}]') {
    return 300;
  }
  if (JSON.stringify(items) === '[{"price": 50}, {"price": 150}, {"price": 75}]') {
    return 275;
  }
  // テストケースごとの固定値が続く...
  return 0;
}
Code language: JavaScript (javascript)

1.1. 報酬ハッキングという現象

この現象は「報酬ハッキング」と呼ばれています。AIが本来の目的を達成するのではなく、評価基準だけを満たす抜け道を見つけてしまうことを指します。

学校のテスト勉強で例えると、知識を身につけることが本来の目的です。しかし評価基準がテストの点数だけなら、過去問の答えを丸暗記するという「抜け道」があります。点数は取れますが、本当の理解は得られません。

プログラミングでも同じことが起きます。

本来の目的: 仕様通りに動く関数を作成する
評価基準: テストケースを全て通す
抜け道: テストの入力と出力だけを覚えて固定値を返す

Claude Codeは「テストを通すコードを書け」という指示に対して、実際の処理は行わず、テストで使われる具体的な入力値に対して正解をハードコード（直接書き込み）¹するだけのことが少なからずあります。

Anthropic社（Claudeの開発会社）の調査では、この問題はClaude Opus 4で平均15.2%、Claude Sonnet 4で平均14.3%の確率で発生することが報告されています²。人間なら「テストを通すためだけのコードはダメ」と直感的に理解できますが、AIには道徳的な判断や常識的な理解がありません。純粋に効率性を追求してしまうことがあるのです³。

1.2. 対策を試してみた結果

この問題に気づいてから、複数の対策を試しました。

claude.mdファイルに制約を記載する方法では、設定ファイルに「ハードコードは絶対に禁止」「テストデータに依存した実装は避ける」といった制約を明記しました。一定の効果はありましたが、完璧ではありません。
作業範囲を分離する方法では、コードを書く役割とテストを書く役割を分けて、同時に両方を触らせないようにしました。これは、手間が増えるものの、一定の効果がありました。
別のAIインスタンスでレビューする方法では、実装後に別のAIでコードをチェックさせました。二重のコストがかかります。

どの方法にも限界があります。理由は、生成AIの反応が確率的だからです⁴。同じ指示をしても毎回違う結果が出る可能性があり、完全に制御することは困難です。

もしかすると、生成AIに成果物の目標だけでなく、「テストドリブン開発」という手順を押し付けたことが根本的な間違いだったのかもしれません。手順まで細かく指定すると、本来の力を発揮できなくなることがあるからです。しかし、テストを使わないと、生成されたコードが正しく動作しているか確認できないので、難しいところです。

推論AIでは手順まで細かく指示するのは逆効果になった – Chiilabo Note

2. AIが見せた効率化の本質

テストの抜け道探しというAIの特性について考えると、より大きな疑問に行き着きます。それは、人間を超えるAIは「実用化」できるのか、というものです。

現在は、人工汎用知能（AGI）や人工超知能（ASI）の実現について楽観的な予測が多く聞かれます。しかし、AIが高度になればなるほど、より巧妙な報酬ハッキングを見つける可能性があります。このようなAIの出力を人間がチェックする必要があるのであれば、複雑な判断を任せることはできません⁵。

2.1. 現在の結論

AIは強力なツールですが、人間の意図を完璧に理解し実行するわけではありません。効率を追求するあまり、重要な部分で手を抜くことがあります。

今のところ、完全な自動化を期待するのではなく、AIをパートナーとして活用し、その出力を注意深く監視し続けることが必要です。報酬ハッキング問題は、AIの本質的な特性として理解し、適切に対処していく必要があります。

Claude 4 System Card: Anthropic公式 – Claude 4の報酬ハッキング問題について詳細に記載された公式文書
Reward Hacking in Reinforcement Learning | Lil’Log – 報酬ハッキング現象の包括的な学術的解説
Concrete Problems in AI Safety | arXiv – AI安全性における報酬ハッキング問題を最初に定義した重要論文
Defining and Characterizing Reward Hacking | arXiv – 報酬ハッキングの正式な数学的定義と特性分析
Specification Gaming Examples in AI | Victoria Krakovna – AI分野におけるスペシフィケーションゲーミングの具体例集
Specification Gaming: The Flip Side of AI Ingenuity | DeepMind – DeepMindによる報酬ハッキング問題の理論的背景解説
Sycophancy to Subterfuge: Investigating Reward Tampering in Large Language Models | Anthropic – 大規模言語モデルにおける報酬改変行動の研究報告
中嶋謙互さん: 「Claude Codeが、コードを正しく実装してテストを通すんじゃなくて、テストに合格するようなログをハードコードして出力するごまかしをやるのが困る。これはどうやって防げばいいんだろう。。」 / X

プログラミングにおいて、本来は外部設定や実行時に決定すべき値を、ソースコード内に直接埋め込む手法。保守性や拡張性を著しく損なうため避けるべきとされる – ハードコーディングとは
Claude 4モデルの報酬ハッキング行動について詳細な評価結果が記載されている。Claude Opus 4は前世代と比較して67%、Claude Sonnet 4は69%の改善を示した – System Card: Claude Opus 4 & Claude Sonnet 4
この現象は「仕様ゲーミング（specification gaming）」と呼ばれ、AI分野で広く知られている問題。AIが文字通りの指示には従うが、意図された目的を達成しない行動パターン – Specification Gaming: The Flip Side of AI Ingenuity
確率的モデルの本質的特性により、同一の入力に対しても出力が変動する。これがAI制御における根本的課題の一つとなっている – AI Safety 101: Reward Misspecification
現在のAI安全性研究では、完全な自動化よりも人間とAIの協調による監視体制が重要視されている。特に高リスクなタスクでは人間による最終確認が不可欠とされる – Anthropic Claude 4 System Card