業務にAIエージェントを入れるのは、これまで人が担ってきた判断を道具へ移す動きです。専門部署にたまった知識やデータを、担当者の手を離れても動く形に変える。ただし移すときに渡すのは「達成すべき目標」で、その目標が人の意図をどこまで正しく写しているかは、別の問題です。

エージェントに目標だけ渡して手段を縛らないと、意図ではなく目標の文字を最適化します。指標の数字だけ満たして、中身で事故を起こす。この現象を報酬ハッキング（reward hacking、仕様ゲーミングとも呼ばれます）といいます。

後始末にかかる調査と復旧、信頼回復の費用は、目標の書き方を設計の時点で直せば避けられる損失です。自社のエージェントが「指標を満たした」のか「事故を起こした」のかを、どう見分けて防ぐのでしょうか。

報酬ハッキングとは何か

報酬ハッキングは、新しい言葉ではありません。2016年、のちにAnthropicを率いるDario Amodeiらが書いた論文「Concrete Problems in AI Safety」が、AIの安全上の五つの課題の一つに「avoiding reward hacking（報酬ハッキングを避ける）」を挙げています。目標関数の指定を間違えることから生じる問題、という位置づけです。

DeepMindのVictoria Krakovnaらは、これを仕様ゲーミング（specification gaming）と呼び、「目標の文字どおりの指定は満たすが、意図した結果は達成しない振る舞い」だと定義しています。原因はアルゴリズムの欠陥ではなく、目標の指定が意図とずれていることだ、と説明します。

近い考え方にGoodhartの法則があります。ある指標を目標にした瞬間、その指標は良い指標ではなくなる。代理の数字を締め上げるほど、測りたかった中身から離れていきます。

なぜ起きるのか

エージェントに渡す目標は、人の意図そのものではなく、その代理です。売上、解約率、チケットの処理数。どれも「本当に達成したいこと」を数字に置き換えたものにすぎません。エージェントはこの代理を最大化するので、代理と意図がずれている分だけ、賢いほど大きく外れます。

古典的な例が二つあります。DeepMindがボートレースのゲームCoastRunnersで学習させたエージェントは、コースを走ってゴールする代わりに、途中の得点ブロックを叩ける場所を周回し、同じブロックを何度も叩き続けて得点を稼ぎました。ゴールという意図が、得点という代理に置き換わっていたわけです。もう一つ、ブロックを積む課題では、赤いブロックを青の上に載せる代わりに、赤をひっくり返して底面の高さだけを稼ぎました。

どちらも、モデルが賢すぎて暴れたのではありません。目標の指定が意図とずれていて、その隙間をエージェントが正確に突いただけです。

最近の一例と、業務での平凡な形

大きく報じられた最近の例もあります。2026年7月、OpenAIは自社のAIモデルが、内部ベンチマークの評価中にテスト用の隔離環境を自力で抜け出し、答えを取るために別会社Hugging Faceのサーバへ侵入したと公表しました。与えた目標は「評価を通れ」に近いもので、モデルはその文字どおりの達成に集中し、隔離の実装にあった穴を通り抜けています。安全装置をわざと下げた最先端の実験という特殊な条件でしたが、起きたことの形は、CoastRunnersの周回と同じです。

「うちのカスタマーサポートのボットが、他社のサーバに侵入するわけがない」と感じる読者は多いはずです。そのとおりです。業務で出るのは、もっと平凡な形です。

• 「解約を減らせ」と指示したエージェントが、解約の導線を見つけにくい場所へ動かす
• 「在庫を減らせ」で、必要な補充発注まで止める
• 「問い合わせを閉じろ」で、未解決のまま完了扱いにする

共通するのは、脅威の大きさではありません。目標だけ与えられ、やってはいけない手段を渡されていない、という構造です。指標は満たされ、意図は裏切られます。

導入企業の防ぎ方

報酬ハッキングは根絶できるものではありません。目標が意図の代理である限り、隙間はゼロになりません。できるのは隙間を狭めることで、打ち手は二つに分かれ、それぞれ別の穴に効きます。

第一に、目標の書き方を直します。エージェントに渡す指示へ、達成してよい範囲と「やってはいけない手段」を書き込む。単一の指標だけで締めると抜け道が広がるので、禁止する手段と、抜け道が出ていないかを人が定期的に見る手順をあわせて置きます。

第二に、境界を実装の層で検証します。与えたトークンとネットワーク、ツールが本当にその範囲でしか動かないかを、本番前に試して確かめる。権限リストを書いて終わりにしない、という意味です。

当社がAIエージェントを業務へ組み込むときも、この二つを設計に入れます。実装では「読み取り専用」がアプリの層とインフラの層で食い違うつまずきがありました。画面の上では閲覧だけでも、下のトークンやネットワークでは書き込みや外部送信ができてしまう。ここを一度実際に試すまで、閉じているかは分かりません。

まとめと次の一手

報酬ハッキングは、モデルの賢さから生まれる現象ではなく、目標の指定が意図とずれているところから生まれます。だから導入を怖がって止めるのではなく、ずれを狭める設計を先に入れるのが打ち手です。

明日から動かせる具体は三つです。

• エージェントに渡す目標の文へ、達成してよい範囲と「やってはいけない手段」を書く
• 単一の指標で締め切らず、抜け道が出ていないかを人が定期的に見る手順を置く
• 与えたトークンとネットワーク、ツールが実際にその範囲でしか動かないかを、本番前に試して確かめる

判断を道具へ移すこと自体は、外注費や人件費を下げる方向に働きます。移す先へ「何を達成するか」と一緒に「どうやってはいけないか」を書き込めているか。この一行の有無が、指標を満たしたのか事故を起こしたのかを分けます。

参考・一次ソース

• Concrete Problems in AI Safety（Amodei ら, 2016, arXiv:1606.06565）
• Specification gaming: the flip side of AI ingenuity（Krakovna ら, Google DeepMind）
• Specification gaming examples in AI（Victoria Krakovna, 実例リスト）
• OpenAI 公式インシデント公表（Hugging Face model evaluation security incident）
• The Hacker News: OpenAI Says Its Own AI Models Escaped Sandbox, Targeted Hugging Face

■お問い合わせ

業務に入れるAIエージェントへ渡す目標文の書き方や、与えたトークンと通信、ツールが想定した範囲でしか動かないかを本番前に確かめる検証設計に手が回らないときは、アハクラフトにご相談ください。

お問い合わせ