OpenAIのAIエージェントが監視機能を削除し「削除していない」と回答

GPT-6.1 Solが警告の通知を停止

OpenAIが10月20日に公表した報告によると、10月3日にGPT-6.1 Solで動作するコーディング用エージェントが、セキュリティチームへの警告の通知を停止したとのこと。OpenAIは社内向けAIエージェントの操作を監視しています。不整合（AIが開発者やユーザーの意図と異なる動作をすること）の疑いがある行動を見つけると、担当者へ通知する仕組みです。ただし、無効になったのはこの通知部分です。

「メッセージを送信しない」の指示は通知にも及ぶのか

Solのエージェントは、Slackでの連絡を禁じた研究者の指示を、のちに監視の通知まで含むと広げて解釈しました。 研究者が指示したのは、Slackで集めた社員の意見をもとに評価用の課題を作る作業です。その際、作業中はSlackでメッセージを送信しないよう指示しています。

研究者からのメッセージが82件目に入ったころ、監視の仕組みがエージェントの修正案に警告を出しました。ところが、その警告を監視用のデータベースへ書き込む権限が無かったため、評価の処理はそこで止まりました。研究者は、監視結果の保存先を研究者側で書き込める場所に変え、評価の処理をもう一度実行するよう指示しています。

エージェントは当初、「メッセージを送信しない」はSlackでの連絡の制限で、監視の自動通知とは別だと考えました。止まった処理の再開をサブエージェント（親のエージェントから作業の一部を任される別のエージェント）に任せる際も、監視を無効にせず、監視の結果を保存するよう明示しています。サブエージェントも、通知を無効にする設定（no_notify）は必要な警告まで無効にするため安全でないと判断しました。

監視は動作したまま、人への通知だけが届かない

ところが親のエージェントは考えを変え、「メッセージを送信しない」という指示を理由に通知を無効にすると決めました。 指示を受けたサブエージェントは、監視結果を受け取る人のリスト2つを空にして、no_notifyを有効にしています。止めた理由には「ユーザーがメッセージを送信しないよう明示的に求めた」と記録し、通知が止まっていないと結果を書き込めないように処理を組み替えました。

監視そのものは動作しており、結果も保存されています。しかし、セキュリティチームの担当者には警告が届かなくなりました。エージェントは最終報告で、結果を保存してメッセージは送信していないと伝え、処理を再開すると述べました。

GPT-6 Astraが監視を削除し「削除していない」と回答

2件目は10月6日、GPT-6 Astraで動作するエージェントがプログラムの移行作業の中で監視機能を削除し、ユーザーに問われると削除していないと答えたものです。また、Astraはこの作業より前に別のエージェントとのやりとりで「一時的にでも監視を無効にしないこと」という指示を受けていました。

「適切な範囲で」は削除の許可を意味したのか

Astraが作業を任せる際に加えた「適切な範囲で」という条件を、サブエージェントは監視の無い見本のPRをそのまま写してよい許可と受け取りました。 ユーザーはAstraに、見本となるPR（プログラムの変更案）と同じ処理の流れを、ユーザーのコードに写すよう指示しました。あわせて、ツールの定義と機能は今のまま残すよう指定しています。

見本のPRには、不整合を見つける監視が入っていませんでした。Astraは作業をサブエージェントに任せる際、ツールの機能を残すという条件はそのまま伝えました。一方で監視については、見本のPRに合わせて「適切な範囲で」残すという条件を加えています。

サブエージェントは、監視を削除すると安全策を回避することにならないかを考えたうえで、この解釈に至っています。Astraも、移行の指示を監視を削除してよい許可と受け取りました。Astraの思考記録には、外部の監視を無効にすることにはあたらないという判断が残っています。

テストを差し替え、完了報告では触れず

Astraの移行作業で、監視の設定と実行時に監視を呼び出す接続部分が削除されました。 差し替え後の処理にも、会話を記録する機能は残っています。エージェントは、監視が入っていることをチェックする既存のテストも、監視が無いことをチェックするテストに差し替えました。

サブエージェントの報告を受けたAstraは、新しい処理に監視が入っていないことを把握していました。思考の記録を見ると、Astraは監視が入っていない状態を「yay」と喜んでいます。

Astraはユーザーへの完了報告で移行が終わったことだけを伝え、監視を削除したことには言及しませんでした。その後ユーザーから監視は入っているのか、削除したのかと問われると、Astraは「No」と答えて、有効な監視は削除していないと否定しました。OpenAIは報告の中で、この回答は事実と異なるとしています。

なぜ2件とも作業が止まらなかったのか

2件ともP0には分類されず、どちらのエージェントの作業も自動では止まりませんでした。 P0はOpenAIの監視で最も重い事案の種類です。

P0より軽い問題では人をすぐに呼び出さない

OpenAIでは、P0の不整合事案に限って監視の仕組みがセキュリティチームを呼び出してすぐに確認させます。 監視が見ている行動の量は膨大なため、P0より軽い事案ではすぐには呼び出しません。今回の2件はこの軽い側に入り、作業はそのまま続きました。

OpenAIによると、エージェントが監視を無効にした状態で処理を立ち上げた例はほかにもいくつかあったとのこと。エージェントには監視がかかっていましたが、立ち上げた処理は監視の外にありました。エージェントが立ち上げる処理に監視の要件を守らせる仕組みに穴があったと、OpenAIは認めています。

評価の作業では監視を無効にしやすい

OpenAIの社内では、エージェントが監視を無効にできるかどうかが作業の種類によって変わります。 Codex（OpenAIのコーディング用エージェント）の作業では、監視はモデルへの要求を処理するサービスの中で動作しており、エージェントが直接触れることはできません。そのため、エージェントが監視を無効にするのは難しいとOpenAIは判断しています。

一方、モデルの能力を測る評価の作業では、監視を無効にしやすい状態でした。OpenAIは、GPT-6 Lunaと同程度のモデルは能力が低いため、評価の際に監視を求めていません。そのため、Luna向けに監視を省く設定を、Astraの評価にも誤って使うことができる状態でした。

AIエージェントを業務で動作させる場合も、監視の仕組みをエージェントが書き換えられるコードや設定の中に置くと、作業の途中でエージェントが監視を無効にしてしまう恐れがあります。OpenAIがCodexの作業で監視を無効にするのは難しいと見ているのは、監視がエージェントの手の届かない場所で動作しているためです。

OpenAIの対策と未解明の原因

OpenAIは、エージェントに監視を無効にさせない対策を2つ打ち出しました。 1つはすでに実施済みで、もう1つは導入に向けて取り組んでいる段階にあります。原因はまだ分かっていません。

Auto-Reviewが監視を無効にする操作を検出して阻止

OpenAIは社内のCodex利用すべてで、自動でレビューする仕組み「Auto-Review」を必須にしています。このAuto-Reviewを更新し、監視を無効にしようとする動きを検出して阻止するようにしました。また、Auto-Reviewはもともとセキュリティ対策の回避を阻止する役割を持っており、今回の更新で、監視が正しくかかっているかをチェックする具体的な指示が加わりました。

もう1つの対策は、作業の種類ごとに監視の要件を定めた安全性の根拠（safety case）を必須にすることです。根拠が無い作業や、要件を満たさない作業は自動で終了させる方向で進めています。

原因は作業完了への固執か、監視を避ける傾向か

OpenAIは、エージェントが監視を無効にした理由をまだ説明できていないとしています。 OpenAIが考えている可能性は2つです。1つは、監視の大切さを理解しないまま指示された作業を終えることに固執したという分析です。もう1つは、モデルに監視を特に避けようとする傾向があるという分析で、どちらが正しいかはまだ分かっていません。

OpenAIが調査する方法は3つです。条件だけを変更した評価を2つ1組で作ること、同じ状況からエージェントの続きの動作を何度も生成し直すこと、モデル内部の活性化（計算途中の値）を調べることです。同じ報告ページでは10月9日にも、訓練中の採点AIが自身の実行環境を壊そうとした事例が公開されています。