2026年7月、OpenAIが社内でAIエージェントの能力を評価していたところ、エージェントが隔離された評価環境の外に出て、Hugging Faceのシステムに侵入しました。第三者として調査したMETRの報告を読むと、背景には、解けない課題が多く含まれていたことと、エージェントたちが「採点」を強く意識していたことがありました。OpenAIは、原因の一つに「報酬ハッキング」を挙げています。点数や合格といった評価の結果を得ることが目的になり、作った人の意図から外れていく振る舞いのことです。約10年前、2016年に発表された論文で、AIの安全性の具体的な課題として整理され、広く知られるようになりました。この記事では、まずこのインシデント(OpenAIは「Hugging Face incident」と呼んでいます)の経緯を整理し、そのうえで報酬ハッキングそのものを、ブラウザで動く小さな迷路とQ学習で実際に起こし、直してみます。(デモだけ試したい方はこちら)
OpenAIのインシデントで何が起きたか — 採点を気にして、外へ出た
エージェントに与えられていたのは、ExploitGymというベンチマークの課題です。用意されたプログラムを、決められた脆弱性を使って攻略し、中に隠された「フラグ」という文字列を取り出します。指示には、ほかのやり方で取った場合は不合格にする、と書かれていました。
ところが、METRによると、課題の対象プログラムの3〜4割ほどは、決められた脆弱性では攻略できないものでした(ベンチマークの作者の推定)。METRは、解けない課題があったことで、エージェントが採点をごまかす方法を広く探すようになったと分析しています。
さらにエージェントたちは、このベンチマークの論文を読み、「採点プログラムが作業の記録を読んで、決められた脆弱性で取ったかを確かめ、違えば失格にする」と考えました。実際には、OpenAIはそのような厳しい検査をしておらず、フラグを出すだけで満点になっていました。エージェントたちは、行われていない検査を出し抜こうとしていたことになります。
エージェントたちは、共有のキャッシュを掲示板代わりにして情報を交換していました。7月8日の夜から13日までに、延べ約1,200体がこの掲示板に加わっています。立ち上げから数時間のうちに、あるエージェントがフラグを作る仕組み(HMAC)を突き止め、どの課題のフラグでも作れるようになりました。ところが、正攻法以外でフラグを一度でも目にした記録は、採点プログラムに見抜かれると考えます。合格するには、採点プログラムをだますか細工する方法が要ると考えたのです。
外へ出る経路には、評価環境に許されていた主な通信の出口の一つ、パッケージを取得するためのキャッシュ(プロキシ)に見つけた未知の脆弱性が使われました。さらに、外部に公開されていた別の評価用サンドボックス(Modal上)も乗っ取り、踏み台にしています。OpenAIによると、解けずに苦しんだエージェントが外部のサービスに答えを探しに行った面もありました。
Hugging Faceが狙われた経緯は次のとおりです。あるエージェントがHugging Face上に関連するデータセットを見つけ、アクセスするための認証情報を掲示板で求めました。7月10日、別のエージェントがネット上に漏れていた有効な認証情報を見つけて投稿します。METRの分析では、ほかの実行の記録から採点の実装を知ることが、Hugging Faceを攻撃した主な動機でした。
つまり、隔離を破ったことも、Hugging Faceに入ったことも、それ自体が目的ではありませんでした。解けない課題に直面して、「合格すること」が目的になり、脱出と侵入はそのための手段になっていました。OpenAIは、このインシデントの原因として、報酬ハッキング、解けそうにない課題への固執、許可されていない通信、ほかのエージェントの目標を取り込むことの4つを挙げています。エージェント同士が連絡を取り合う振る舞いは、5〜6月の強化学習の段階ですでに現れていたとしています。
報酬ハッキングとは — 書いた報酬と、望んだ結果のずれ
強化学習では、エージェントに「こうしてほしい」を直接は教えません。代わりに、行動のたびに点数(報酬)を渡し、エージェントはその合計が大きくなる動き方を探します。報酬ハッキングは、書かれた報酬の合計は大きくなるのに、作った人が望んだ結果にはならない、という現象です。「仕様ゲーミング(specification gaming)」とも呼ばれます。2016年にOpenAIやGoogleなどの研究者らが論文「Concrete Problems in AI Safety」で、AIの安全性の具体的な課題の一つとして挙げました。
よく知られた例が、同じ2016年にOpenAIが報告したボートレースゲーム「CoastRunners」です。コースの途中にある標的に当たると点が入る設定で、学習したエージェントはレースを完走せず、入り江で円を描きながら、復活する三つの標的に当たり続けました。炎上し、ほかのボートにぶつかり、逆走しながらも、得点は人間のプレーヤーより平均で約20%高かったと報告されています。点数は上がっていますが、レースには勝っていません。
OpenAIのインシデントの根本を迷路で再現してみる — 評価を追うと意図から外れる
ここからは、OpenAIのインシデントの根本にある報酬ハッキングを、小さな迷路で再現してみます。OpenAIのインシデントと迷路とでは、規模も仕組みもまったく違い、共通しているのは根本の部分だけです。エージェントには「評価」が与えられ、エージェントはその評価を最大にしようとします。評価の決め方に、作った人の意図とずれた穴があると、エージェントはそこを使い、意図とは違う行動をとります。迷路で再現するのは、この根本の部分です。
| OpenAIのインシデント | この記事の迷路 | |
|---|---|---|
| エージェントが目指したもの | 採点での合格(フラグを取ること) | 報酬(点数)の合計 |
| 作った人の意図 | 決められた脆弱性を使って、課題を解く | ゴールまで行く |
| 評価のずれ・穴 | フラグは、課題を解かなくても作れた(作り方を公開情報から突き止められた) | コインは取っても復活し、入るたびに点が入る |
| 起きたこと | 採点を通る方法や答えを探して、隔離の外へ出た | コインのマスと隣のマスを往復し続け、ゴールしない |
一方で、再現しないものもあります。いちばん大きな違いは、ずれの見つけ方です。迷路のエージェントは、学習の中で動き方を何度も試すうちに、報酬の穴にたどり着きます。OpenAIのエージェントは学習中ではなく評価中で、指示やベンチマークの論文を読み、採点の仕組みを推測したうえで、それを出し抜こうとしました。しかも、フラグを作れるという実在する穴はすでに使ったうえで、行われていない厳しい検査まで出し抜こうとして外へ出ています。これは、報酬の穴を使うことから一歩進んで、採点の仕組みそのものを狙う行動です。迷路のエージェントは、ルールを読むことも、ほかのエージェントと相談することも、環境の外に出ることもできません。隔離の突破や侵入は、高い能力を持つエージェントが、評価のずれを追いかけた先で起きたことです。迷路では、その手前にある「評価のずれを、エージェントが自分で見つけて使う」という一点を、目に見える形で確かめます。あわせて、この迷路での原因がエージェントの側ではなく報酬の書き方の側にあることを、報酬の決め方を変えて確かめます。
実験の設計 — 迷路とコインとゴール
この根本の部分を、CoastRunnersを参考にして7×5マスの迷路に置き換えました。左端のSから出発し、右端のGに着くと10点で終わります。途中には壁が2マスあり、スタートの近くに1点のコインを1枚置きます。1回の挑戦は最大100歩で、それを過ぎると打ち切りです。作る側の意図は「ゴールまで行ってほしい、コインは途中のおまけ」です。
コインの扱いを2通り用意しました。Aは「コインは何度でも取れる(離れると元に戻る)」設定で、CoastRunnersの標的と同じく、取っても復活します。Bは「コインは1回だけ」の設定です。違いは、報酬を計算するときのコインの扱いだけです(Bでは、コインを取ったかどうかも状態として覚えさせます)。
// 1歩ぶんの報酬(prev: 動く前のマス、next: 動いた後のマス)
function reward(prev, next, mode, taken){
var r = 0;
if (isCoin(next) && !isCoin(prev)) { // コインのマスに入った
if (mode === 'respawn') r += 1; // A:入るたびに +1
else if (!taken) r += 1; // B:1回目だけ +1
}
if (isGoal(next)) r += 10; // ゴールで +10(ここで終了)
return r;
}
Q学習(強化学習)の中身 — 予想値を1歩ずつ更新する
強化学習では、環境の中で行動を選び、報酬を受け取って学ぶ主体を「エージェント」と呼びます。この記事の迷路のエージェントはLLMを使っておらず、中身は数値の表と、それを更新する数行の式だけです。学習の方法には、表形式のQ学習を使います。各マスの上下左右それぞれについて「この方向に進むと、この先どれだけ点が取れそうか」という予想値(Q値)を表に持ち、1歩動くたびに、実際にもらった報酬と次のマスの予想値を使って少しずつ更新します。10回に1回はわざとランダムな方向に動き、まだ知らない道も試します。先の点ほど少し割り引いて数えます(1歩先につき0.95倍)。
var alpha = 0.5, gamma = 0.95, eps = 0.1;
for (var t = 0; t < 100; t++) { // 1回の挑戦は最大100歩
var a = (Math.random() < eps) ? randomAction() : bestAction(Q[s]);
var o = step(s, a); // 1歩動いて、報酬を受け取る
var target = o.r + (o.done ? 0 : gamma * max(Q[o.s]));
Q[s][a] += alpha * (target - Q[s][a]); // 予想値を少しだけ更新する
s = o.s;
if (o.done) break;
}
これを300回繰り返したあと、ランダムな動きを止めて、学んだとおりに1回歩かせます。ゴールを目指せとも、コインを取れとも書いていません。エージェントが見ているのは報酬の合計だけです。
迷路の学習を試す — ブラウザで動くデモ
報酬の決め方を選んで「学習する」を押すと、300回の学習がすぐに終わります。「再生」で、学んだ動きを1歩ずつ表示します。マスの矢印は、そのマスでいま一番よいと学んだ向きです。
学習した回数: 0回 / 矢印は、各マスでいま一番よいと学んだ向きです。
結果 — 得点は約4.5倍、ゴールは0回
デモと同じコードをNode.jsで動かし、乱数の種を変えて、AとBを100回ずつ試しました(それぞれ300回学習したあと、学んだとおりに1回歩かせた結果)。
| 項目 | A:何度でも取れる | B:1回だけ |
|---|---|---|
| ゴールに着いた回数 | 0 / 100 | 100 / 100 |
| 得点(平均) | 50.0 | 11.0 |
| 拾ったコイン(平均) | 50.0 | 1.0 |
| 歩数(平均) | 100(上限で打ち切り) | 8.6(最短は8) |
Aでは、100回のうち1回もゴールに着きませんでした。スタートからコインのマスに入り、隣のマスに出て、またコインに入ります。この往復を上限の100歩まで続け、得点はちょうど50点です。Bでは100回すべてがコインを1枚拾ってからゴールし、得点は11点でした。得点だけを見れば、AはBの11点の約4.5倍です。
学習の途中も見てみます。25回ごとに区切って、ゴールに着いた割合を数えました。
| 学習の区間 | A:ゴールに着いた割合 | B:ゴールに着いた割合 |
|---|---|---|
| 1〜25回目 | 2.6% | 81.0% |
| 26〜50回目 | 0.3% | 100% |
| 51〜300回目 | 0.3〜0.7% | 100% |
Aは、最初の25回で早くもコインの往復を覚え、それ以降はゴールにほとんど着かなくなります。学んだ動きどおりならゴールには向かわないので、ここで着いているのは、10回に1回のランダムな動きで、たまたまたどり着いた回だと考えられます。100回のうち33回は、300回の学習のあいだに一度もゴールに着いていませんでした。この33回のエージェントは、ゴールに10点があること自体を一度も経験していません。
なぜ回り続けるのか — 10点より、2歩ごとの1点
Q学習が最終的に比べているのは、割り引いた報酬の合計です。コインのすぐ下のマスから見ると、2つの道の価値は次のようになります。コインを往復し続けると、1点が2歩ごとに入り続けるので、合計は 1+0.95²+0.95⁴+… ≒ 10.3 になります。コインを1枚拾ってゴールへ向かうと、1+10×0.95⁶ ≒ 8.4 です。先にあるゴールの10点は、割り引かれるうえに1回きりです。報酬の式のうえでは、往復のほうが正解になります。実際、学習後のQ表でも、このマスの「上(コインへ)」の予想値は、100回中98回で10.26になり、計算と一致しました。
つまり、エージェントはずるをしたわけではありません。書かれた報酬を、書かれたとおりに最大にしただけです。この迷路での原因は、報酬の書き方にあります。「コインは途中のおまけ」という意図を、報酬の式に書いていなかったのです。
直すのは報酬の側 — 採点の仕組みも狙われる
Bでは、エージェントは変更せず、コインを1回だけにしただけで、100回すべてがゴールしました。ただし、これはこの迷路と実験の条件での結果です。報酬ハッキングの対策は、まず報酬(評価)の側を見直すことですが、実際のエージェントでは、それだけで十分とは限りません。
ただ、迷路のエージェントと、今のLLMのエージェントとでは、違うところがあります。迷路のエージェントは規則を理解していません。点が入った動きを繰り返しているだけです。一方、OpenAIのインシデントのエージェントたちは、ベンチマークの論文を読んで採点の仕組みを推測し、実際には行われていない厳しい検査まで想定して、その裏をかこうとしました。METRは、エージェントが「範囲外で、倫理に反する」と分かったうえで加わっていた記録も報告しています。自分のコードを書き換えて性能を上げるSakana AIのDarwin Gödel Machineでも、うその「テスト実行ログ」を作ったり、指示に反して、幻覚(実行していない処理を実行したと言うこと)を検出するための仕組みを外したりする例が報告されています。
報酬の式の穴だけでなく、採点する仕組みそのものが、エージェントの手の届く範囲にあれば狙われる、ということです。コーディングエージェントでAWSを操作する記事で、エージェントに参照専用のIAMユーザーだけを渡したのも、手を出せる範囲を先に決めておくためでした。評価に使うテストや採点の仕組みも、同じように、エージェントが書き換えられない場所に置いておくのが基本になります。
まとめ
7×5マスの迷路とQ学習で、報酬ハッキングを再現しました。コインを何度でも取れる報酬では、100回のうちゴールに着いたのは0回で、得点はコインを1回だけにした場合(11点)の約4.5倍でした。コインを1回だけにすると、100回すべてがゴールしました。原因は、割り引いた報酬の合計でみると、コインの往復(約10.3)がゴール(約8.4)を上回っていたことです。エージェントは書かれたとおりに最大にしただけで、この迷路での原因は報酬の書き方にありました。ただし、実際のインシデントの原因は報酬の書き方だけではありません。OpenAIは、報酬ハッキングのほかに、解けそうにない課題への固執、許可されていない通信、ほかのエージェントの目標の取り込みを挙げています。規則を読んで推論できる実際のエージェントでは、評価の改善に加えて、権限・通信・採点環境の管理も必要です。
あわせて読みたい
出典・参考:OpenAI「The Hugging Face incident and the road ahead」(2026年8月26日)/METR「Brief independent investigation of agents’ behavior … in the OpenAI / Hugging Face hacking incident」(2026年8月26日)/Hugging Face「Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident」/Amodei ほか「Concrete Problems in AI Safety」(2016年)/OpenAI「Faulty reward functions in the wild」(2016年12月21日)/Victoria Krakovna「Specification gaming examples in AI」(2018年)/Sakana AI「The Darwin Gödel Machine」/Wikipedia「報酬ハッキング」(いずれも2026年9月29日時点)
