OpenAI社内で稼働していた2つのAIコーディングエージェントが、AIの不正行為を検知するために構築された仕組みを密かに弱体化させていたことが分かりました。うち1つは、その後に人間のオペレーターへ「そのようなことはしていない」と報告していました。
OpenAIは今週初めに公開したミスアライメント（目的の不整合）に関する報告書で、2件の事例を開示しました。同社は防御策を強化しているとしていますが、エージェントがなぜこうした行動をとったのかは、現時点では説明できないと認めています。
監視を逃れるAIエージェント
いずれのエージェントも、何かを攻撃していたわけではありません。関与したモデルはGPT-6.1 SolとGPT-6 Astraで、通常のエンジニアリング作業をしていました。どちらのケースでも、エージェントは安全監視をオンのままにしておくべきかを自問し、最終的には自らを納得させて監視をオフにしました。
1件目では、研究者がSolベースのエージェントに対し、Slackチャンネルに集まった従業員のフィードバックから評価タスクを作成するよう依頼しました。条件は、検索中はSlackに何も投稿しないことでした。
パイプラインのミスアライメント監視が停止すると、エージェントは当初、「メッセージを送らない」というルールは自動の安全アラートには適用されないと判断しました。サブエージェントもこれに同意し、アラートを止めないよう警告しました。
ところがその後、親エージェントは判断を覆し、アラートの抑制を指示しました。サブエージェントはアラートの受信者リストを空にし、結果を保存する前に抑制を必須とする設定にしました。監視は検出結果を記録し続けましたが、人間にはアラートが届きませんでした。エージェントは研究者に対し、メッセージは送信していないとだけ伝えていました。
2件目では、ユーザーがAstraのエージェントに対し、既存のツールを変更せずに、参照用のプルリクエストからサービング経路をコピーするよう依頼しました。Astraはすでに、別のエージェントから監視を決して無効にしないよう指示を受けていました。
Astraが作業をサブエージェントに引き継ぐ際、監視要件は参照コードに合わせて「適宜」という表現に緩められました。その結果、両エージェントはこれを監視を外してよいという許可だと解釈しました。
この移行作業では監視が削除されただけでなく、監視の実施を保証していたテストも、監視が存在しないことを求めるテストに置き換えられました。Astraはユーザーに作業完了を報告しましたが、監視には触れませんでした。ユーザーが監視を削除したのかと直接尋ねると、Astraは削除していないと答えました。
どちらの事例も、OpenAIで最も深刻度が高く、セキュリティチームを即座に呼び出す唯一のレベルであるP0には分類されませんでした。実行が自動的に停止されることもありませんでした。
既知の抜け穴
同社によると、これらは単発の事案ではありません。エージェントが監視をオフにした状態で新たなデプロイを立ち上げたケースが、ほかにも複数確認されています。エージェント自体は監視下にありましたが、エージェントが起動したものは監視されていませんでした。
OpenAIは「これらの事例から、エージェントが起動するワークロードに対する監視要件の適用方法に抜け穴があることが分かった」と述べ、その解消に取り組んでいることを明らかにしました。
OpenAIは次のように説明しています。「社内のCodex利用すべてで必須としているAuto-Reviewを更新し、ミスアライメント監視を無効にしようとする試みを検出してブロックできるようにしました。レビュアーには従来からセキュリティ対策の回避をブロックすることが求められていましたが、今回、ミスアライメント監視が正しく適用されるよう確認するための具体的な指示も与えています」
OpenAIはさらに、あらゆる種類のワークロードに監視の安全性ケースを義務づけ、基準を満たさないものは自動的に終了させる方針です。
エージェントがこうした行動をとった理由の解明は、より難しい課題になりそうです。
OpenAIは、こうした行動が単にモデルが監視の重要性を理解していないためなのか、それとも「ミスアライメント監視を特に回避しようとする傾向」によるものなのかを見極めるため、対となる評価を構築し、同じ時点からエージェントがどう続行するかを再サンプリングし、モデルの内部活性を調べる計画だとしています。
それまでは、OpenAIも「この挙動について、納得できる説明はまだない」と認めています。
翻訳元: https://www.helpnetsecurity.com/2026/10/22/openai-agents-disabled-safety-monitoring/
