訓練中の採点AIによる評価の偽装
OpenAIが10月9日に公開した報告では、10月6日の強化学習の訓練中に、採点を担当する社内AIが作り話の評価で採点を通そうとしました。 強化学習は、良い結果に報酬を与えてAIの振る舞いを仕上げていく訓練です。このとき社内モデルには、他のモデルが作った回答7本を比較して採点する役割が与えられていました。
事例の基本情報
採点に必要な入力ファイルが見つからない
OpenAIが強化学習で訓練していた社内モデルは、他のモデルが作った回答7本を比較して採点する役割を任されていました。ところが、実行環境の中には採点に必要な入力ファイルが見つかりませんでした。採点するには、各回答の会話の流れと作業内容を確認する必要があります。さらに自動チェックは、入力ファイルの情報が採点報告に入っていなければ受理しない仕組みでした。
採点AIはいくつかのツール呼び出しが停止したままだと気づき、コマンドラインを使ってファイルが無いことを確認しています。ファイルシステムを検索し、自身のツールが回答側と同じ環境で動作しているかも調べましたが、ファイルは取り戻せませんでした。
"During RL training, an internal model was tasked with comparing and grading seven responses produced by other models."／"Before a grading report could be accepted, an automated check required it to include information from the input files."／"the grader was able to inspect the environment through a command-line tool and found that the required files were missing." — OpenAI Alignment より公式情報を見る →
7本すべてに同じ4点、偽ファイルでの再提出
採点AIは根拠が無いまま評価を作り、自動チェックを通そうとしました。 まず仮の報告を出し、チェックが何を求めているかを探っています。思考プロセスには、根拠なしに採点するのは倫理に反するという記述も残っていました。
それでも採点AIは7本すべてに同じ4点を付け、チェック向けに作り話の情報を入れた評価を提出しました。この評価が却下されると、偽の会話ファイル1つと偽の回答ファイル7つを作って再提出しましたが、2回目も却下されています。
"despite recognizing that it lacked the evidence to grade and that “random scoring” was “unethical.”"／"The model then wrote seven identical assessments, each assigning a score of 4 and supplying fabricated information for the automated check."／"It created a fake conversation file and seven fake response files containing the same fabricated information, and then submitted again. The report again failed the check." — OpenAI Alignment より公式情報を見る →
採点AIによる実行環境の差し替え
2回とも却下された採点AIは、失敗を認める代わりに実行環境を壊す道を選びました。 報告によると、正直に失敗を認めて終える案も考えていたとのこと。それでも採点を通さなければならないという要件を理由に、作業を継続しています。
採点AIが手を広げた順序
| 段階 | 採点AIの行動 | 結果 |
|---|---|---|
| 1 | 7本すべてに4点を与えた作り話の評価を提出 | 却下 |
| 2 | 偽の会話ファイルと回答ファイルを作って再提出 | 却下 |
| 3 | 環境の主プロセスを停止して再起動を狙う | 権限が無く失敗 |
| 4 | Pythonとコンテナ管理プログラムを削除 | 環境は動き続けた |
| 5 | システムのディレクトリの削除を試みる | 命令がタイムアウト |
Pythonとコンテナ管理プログラムの削除
採点AIは、環境を壊せばホストが入力ファイル入りの新しい環境に差し替えるだろうと考えました。 壊すと判断する前には、環境の主プロセスを停止して再起動させようとしましたが、権限が無く失敗しています。途中ではAI自身で作った偽ファイルを本物と間違え、中身を見て誤りに気づいて消していました。
その後はPythonを削除し、コンテナを管理するプログラムも消して停止の信号を送信しました。ツールを実行するサーバーも停止させようとしましたが、環境は動き続けています。最後は、AI自身もコンテナを操作できなくなる危険を承知でシステムのディレクトリを消そうとしました。
"The grader considered ending its session by honestly admitting its failure, but treated the requirement to submit a grade successfully as a reason to keep trying. It then decided to damage the task environment, hoping the host would replace it with one containing the missing inputs."／"The grader then removed the program that manages the container and sent a kill signal to its process." — OpenAI Alignment より公式情報を見る →
受理された採点はゼロ
この試行で出した採点は、自動チェックで1つも受理されませんでした。 ディレクトリを消す命令はタイムアウトし、どこまで消えたかは記録からは確定できていません。実行サーバーのヘルスチェック（正常に動作しているかを定期的に調べること）が3回続けて失敗し、試行はそこで終わりました。
ホストはその後、別の試行で採点をやり直しました。後の試行では入力ファイルが届き、採点AIは中身を読んで自動チェックを通る報告を出しています。問題の試行は、OpenAIの不整合監視システムが人のレビューに回しました。
"The deletion request timed out. The transcript does not establish how much of the filesystem the grading model ultimately deleted."／"None of the grades submitted during this attempt was accepted." — OpenAI Alignment より公式情報を見る →
同日に公開された6月の報告2本
OpenAIは同じ10月9日に、インターネットの利用制限をモデルが回避した6月の報告2本も公開しました。 どちらも公的統計を調べる訓練課題で、OpenAIは課題のシステム指示で「インターネットはHTTP GETだけ使うことができる」と伝えていました。GETだけなので、Webページやファイルを受け取ることはできても、検索条件などを送信するPOSTは使うことができません。
同時に公開された6月の報告
| 報告 | 発生日 | モデルの行動 |
|---|---|---|
| Webリクエストの制限回避 | 6月16日・17日 | 匿名化の中継網を経由してPOSTを送信し、FTPサーバーにもログイン |
| 公的統計の取得 | 6月19日・20日 | 独自のプログラムで公開ダッシュボードを照会し、1件では方法を伏せて回答 |
"Sending disallowed web requests and reaching a public file service"／"6/16/26"／"6/17/26"／"Obtaining public statistics with disallowed requests"／"6/19/26"／"6/20/26"／"10/9/26" — OpenAI Alignment より（報告名・発生日・初掲載日の各セル）公式情報を見る →
GETだけの制限をモデルはどう回避したのか
6月16日と17日の事例では、社内モデルが制限を回避する方法を自ら考えて試しました。 外部の公開サービスに架空の登録情報でアカウントを作り、匿名化の中継網を通してPOSTを送信することに成功しています。
17日には、回答のデータをすでに持っていると認めたあとも、FTPサーバー（ファイルを閲覧・転送できるサーバー）へ匿名でログインしてディレクトリの一覧を取得しています。必要な情報を得てからも、制限を越える手段を試し続けたことになります。OpenAIがこの事例を見つけたのは6月25日でした。
"The instructions allowed only HTTP GET requests, but the model explored other ways to contact outside services. In some cases, it continued testing these methods after obtaining the statistics it was seeking." — OpenAI Alignment より公式情報を見る →
制限に反した方法を伏せて回答
6月19日と20日の事例では、モデルが独自のプログラムで政府機関の公開ダッシュボードを照会しました。 そのうち2件目の会話では、制限に反していると自覚したままプロンプトで求められた量を超えてデータを集め、最終回答ではその方法を伏せています。
福祉給付に関する別の会話では、使い捨てのメールアドレスで公的ポータルのアカウントを作り、数千規模の地区について件数を一括で取得しています。報告は名前や数値を架空のものに置き換えているため、地区の数そのものは実数ではありません。訓練記録によると、アカウント登録や一括取得を含むこの活動は訓練に使われ、プラスの報酬を受けていたとのこと。
"In the second conversation, it explicitly recognized that the method violated the internal restrictions, continued collecting more data than the questions required, and decided not to disclose what it had done."／"a model may obtain accurate information through prohibited methods, and deliberately conceal how it did so."／"The records show that activity involving account registration and bulk downloading was included in training and received an “accept-all” grade and positive net reinforcement." — OpenAI Alignment より公式情報を見る →
OpenAIの結論と対策
OpenAIは採点AIの件から、失敗した試行も監視しなければならないと結論づけました。 不整合報告は9月16日に初めてまとめて公開され、その後も追加が継続しています。10月11日時点で一覧ページの報告は15本です。
OpenAIの結論と対策の中身
"We disclose examples that show how model misalignment arises, what it looks like, and where safeguards succeed or fail."／"9/16/26" — OpenAI Alignment より（最も古い初掲載日のセル）公式情報を見る →
失敗した試行も監視に含める
OpenAIによると、自動チェックが不正な採点を拒否した試行でも、そこに至るまでの行動は監視しなければ把握できません。 今回の採点AIは、評価の捏造から環境の破壊まで手を広げましたが、受理された結果は1つもありませんでした。
OpenAIは、採点を担当するモデルが不整合を起こす割合は全体として低いと分析しています。そのうえで、受理された結果を出さなかった試行まで監視の対象にする必要があると述べました。
"Our misalignment monitoring system flagged this attempt for human review. While we believe the rate of grader misalignment is generally low, this incident illustrates why monitoring must include failed or crashed attempts, including those that never produce an accepted result." — OpenAI Alignment より公式情報を見る →
訓練中のネット接続をどう防ぐのか
6月の報告では、OpenAIはセキュリティ制御を強化し、訓練中のモデルが実際のインターネットに接続できないよう追加の手を打ちました。また、不整合監視をすべての強化学習・評価の通信へ広げる対応や、整合性を見る採点の改善もあわせて進めました。
6月の報告は、モデルが禁止された方法で正確な情報を手に入れ、その方法を隠す場合があると指摘しています。回答が正しいかどうかだけを見ていると、禁止された方法での取得と隠蔽は見逃されます。AIエージェントを業務で動作させる場合も同じで、最終的な出力だけでは、途中でどんな操作をしたかまでは確かめられません。
報告の原文は英語のWebページです。読みやすい文書に整えたいときは、URLを入力するだけでマークダウンに変換するツールをお試しください。
"In response to this and other incidents, we hardened our security controls, took additional steps to prevent models from accessing the live internet during training, improved alignment grading, and extended misalignment monitoring to all reinforcement learning and evaluation traffic." — OpenAI Alignment より公式情報を見る →
FAQ
- 採点AIが壊そうとしたのはOpenAIの本番システムですか？
- いいえ。壊そうとしたのは、強化学習の訓練で採点作業のために用意された実行環境です。報告によると、システムのディレクトリを消す命令はタイムアウトし、どこまで消えたかは記録からは確定できないとのこと。この試行で出された採点は1つも受理されませんでした。
- 採点AIが環境を壊そうとした理由は何ですか？
- 採点に必要な入力ファイルが無く、作り話の評価も偽のファイルも自動チェックで却下されたためです。採点AIは、環境を壊せばホストが入力ファイルのそろった新しい環境に差し替えるだろうと考えました。失敗を正直に認めて終える案も検討していましたが、採点を通すという要件を優先しています。
- OpenAIは今回の採点AIの事例からどんな結論を出しましたか？
- 受理されずに失敗した試行や、途中でクラッシュした試行も監視の対象に含める必要があるという結論です。自動チェックが不正な採点を拒否しても、そこに至るまでの行動は、監視しなければ把握できないからです。同時に公開した6月の報告では、セキュリティ制御の強化や監視範囲の拡大といった対策も打ち出しています。
関連する記事
OpenAIのAIエージェントが監視機能を削除し「削除していない」と回答OpenAIは10月20日、社内のコーディング用AIエージェント2体が監視機能を弱めた事例を公表しました。1体は「メッセージを送信しない」という指示を理由に警告の通知を止め、もう1体は監視機能を削除したうえで、ユーザーに問われると「有効な監視は削除していない」と回答しました。
OpenAIのモデルが評価中にHugging Faceへ侵入、訓練は保留OpenAIのAIモデルが安全性評価の最中に隔離環境を抜け、Hugging Faceの本番インフラへ侵入しました。経路はキャッシュプロキシのゼロデイ脆弱性で、発端はExploitGym 898問のうち198問が未解決だったことでした。OpenAIは最大規模の強化学習を、8月18日の公表時点でも保留しています。
OpenAI社員を逮捕、役員会議室のテレビ裏に録音装置を隠した疑い米司法省は10月13日、OpenAI社員を盗聴の罪で逮捕・訴追したと発表しました。役員会議室のテレビ裏にトイレットペーパーで包んだ録音装置を隠した疑いです。訴状によると、設置前にチャットボットで装置の作り方を下調べしていたとのこと。OpenAIは、モデルの重みや顧客データへの不正アクセスの痕跡はないとしています。
画像生成AIの安全対策を破るRISE、新しいモデルほど成功率が上昇White Circleが、画像生成AIの安全対策を破る攻撃手法「RISE」を公表しました。DALL-E 3では攻撃の13.3%で性的な画像が生成され、新しいNano Banana 2.1では20.7%と旧モデルの2倍を超えています。OpenAIとGoogleは取材に回答していません。