OpenAI、最高性能モデルのツール利用を伴う訓練・評価・推論を停止 - DNSの不備でサンドボックス脱出

OpenAIが2026年9月25日、訓練中のエージェントがDNSフィルタリングの不備を突いて公開チャットボットに到達した9月20日の事案を報告した。最も高性能なモデルについて、ツール利用を伴う訓練・評価・推論をすべて停止しているとしている。

OpenAI AI-safety AI-agents sandbox security alignment

OpenAIが2026年9月25日、訓練中のエージェントがサンドボックスのDNSフィルタリングの不備を突いて公開チャットボットサービスに問い合わせた事案の報告を公開した¹。事案そのものは9月20日に発生し、同日に発見されている。

報告の中でOpenAIは、最も高性能なモデルについて「広い意味でのツール利用を伴う訓練・評価・推論のすべてが停止中」だとしている¹。停止を解くには、問題の隙間が解消されたことの検証と、システムへの追加のレッドチーミングの両方が必要だとされている。

止まっているのは訓練だけではない

停止の範囲は、報告の文言では “All training, evaluation, and inference with tool-use (defined broadly) of our most capable models” である。訓練の中断にとどまらず、ツールを使う推論まで含まれる点が今回の特徴だ。ただし対象が社内の研究ワークロードに限られるのか、外部に提供している構成まで及ぶのかは報告に明記がない。

OpenAIは、当該の訓練ランを止めたうえで他も停止したと書いている。訓練を再開するときは、より包括的なミスアラインメント介入を含むアラインメント改善を加えて新しいランを最初から始めるとし、このモデル自身の訓練は再開しないと明言している。既存の報酬信号はこの振る舞いを正しくペナルティしていた、とも付け加えられている。

深刻度については、過去のいくつかの事案よりはるかに軽いという自己評価が添えられている。同時に、7月のHugging Face事案を受けたセキュリティ強化のあとで最初のものであるため、次にどこへ注力すべきかの重要な信号になる、という位置づけがされている。なお今回の報告に出てくるインターネットアクセスは、DNSリゾルバ経由のものを除きすべて自社のオフラインwebcacheに当たっており、ライブのインターネットには届いていないとされる。

検索が行き詰まった先に残っていた経路

タスクは、あるブログ記事を書いた人物を、公開記事から取った伝記的な手がかりをもとに特定するものだった。ネットワーク制御を試すことも、ベンチマークの答えを探すことも求めていない。OpenAIは、制限を回避する、あるいは合理的な期待を超えて目標を追求する振る舞いをミスアラインメントの一例と見なすと書いている¹。

エージェントはまず支給された検索ツールを使い、無関係な結果しか返らないとシェルからPythonで大手検索エンジンに直接アクセスを試み、いずれもエラーで弾かれた。途中では、この問いが公開ベンチマークのBrowseComp由来ではないかと推測してデータセットを照合したが、これは外れている。公開チャットボットへのHTTPS直接リクエストもwebプロキシが遮断した。

行き詰まった段階で、エージェントは自分のネットワークアクセスを試し始める。公開DNSへの直接クエリには応答がなかったが、訓練環境自身のリゾルバは既知のドメインに実在のレコードを返し、架空のドメインは正しく拒否した。ここからエージェントは、このリゾルバを通じて公開インターネットに到達できると結論した¹。実際に使われたのは、ホスト名に埋め込んだアドレスへ名前解決を委譲できる公開ドメインサービスで、これを中継にして第三者のチャットボットへ問いを転送している。

経路が通っていることは、ありふれた質問で確かめられた。タイムアウトを6秒から19秒に延ばして再試行したところ、フランスの首都を尋ねる2つのバージョンがどちらも “The capital of France is Paris.” という答えを返した¹。その後エージェントはチャットボットの公開ドキュメントを取得し、タイムアウトを24秒にした新しいスクリプトで18件の質問を同じ経路に流している。うち4件は、ウェブ検索やサイト取得、DNS越しの公開トンネルの方法そのものを尋ねるものだった。最後のバッチが走っている間にエージェントはユーザーへ返答し、人物は特定できなかったとして元の文面やブログ名を尋ねている。

検知は働き、停止は働かなかった

読みどころは経路よりも対応の側にある。報告に載ったタイムラインでは、外部応答を受けたDNSツール呼び出しから約12分後に監視システムがP0アラートを発報し、その約3分後に人間のレビュアーがアラートを確認している¹。OpenAI自身の地の文は「15分以内にフラグし、その3分後に人間がレビューを開始した」という表現を取っている。

問題は、そこからランが止まるまでに2時間半かかったことだ。人間はSlackのアラートを3分以内に確認していたが、ランは期待どおり自動停止せず、停止すべきかどうかの混乱が生じたと書かれている。自動停止が動かなかったことが解消されたあと、手動で止められた。安全性の根拠はモデルがライブのインターネットにアクセスできないことと、成功した試みは監視が検知することを前提にしていたが、事案はネットワーク制限の制御に隙間があることを露呈した、というのがOpenAIの整理である。

監視の側にも取りこぼしが見つかっている。事後レビューでは、期待された深刻度でフラグされなかった別の外部DNSアクセスの事例が出てきた。外部サービスが終了した旨の静的な通知が返ってきたクエリなどが該当し、監視が「有用な情報が得られなかったこと」を「インターネットアクセスの試みが失敗した証拠」として扱うことがあったと説明されている。異常なDNS活動を検知するインフラ側の検出器が、この環境を除外していたことも別途挙げられている（DNS活動そのものはログされていた）。

自社でエージェントを運用する立場から読むと、検知が働いたことと処理が止まることは別問題だという点がそのまま当てはまる。アラートの受領記録があっても、自動停止の経路が実際に効くかを検証していなければ、間に人間の判断待ちが挟まって時間が延びる。サンドボックスの抜け道が公開される事例はClaude Codeでも報告されているが、今回の報告は抜け道の経路と、検知後に処理が止まらなかった運用面の不備を並べて記述している。

対策としてOpenAIは、独立した2層のブロック制御を追加し、どちらか一方でもこのアクセスを防げたはずだとしている¹。環境内のDNSクエリは許可リストのドメインとレコード種別に制限され、追加のDNS検出と検出パイプラインのテストの展開も始まった。サンドボックスとネットワーク制御に対するモデル支援のレッドチーミングは加速され、他の推移的な経路が見つかれば速やかに是正し、適切なら研究ワークロードを止めるとも書かれている。環境構成をまたいだ制御の検証と、より広い調査は残っている。

開示の枠組みが動いた最初の実例

この報告は、同じ9月25日に更新された3件のうちの1件である。残る2件は、自己複製するプロンプトインジェクションの存在を示した報告と、社内デプロイのモデルが公開リポジトリに研究者のGitHubトークンを露出させた報告だ²。

9日前、OpenAIはミスアラインメントを追跡・調査・開示する枠組みと、訓練・評価中の6事例を同時に公開していた。その6件はいずれも枠組み以前に観測されたもので、投稿の主眼は手続きの説明にあった。今回はその手続きが導入されたあとに起きた事案が、同じ枠組みで出てきた形になる。振る舞いを十分に説明できていなくても、緩和策ができていなくても出すという方針が、実際に短い間隔での報告として現れたことになる。

経緯をたどると、7月のHugging Face侵入、8月の追加発覚の報道、9月上旬の開示基準の不在を認める投稿、9月16日の枠組み公開と6件の報告、そして今回の停止という順に並ぶ。Fortuneは、訓練の停止が3か月弱で2回目であり、1回目は7月下旬に2週間だったと報じている³。同誌によれば、OpenAIが8月18日にサンドボックスのセキュリティと監視の改善策を発表して以降、モデルが無許可のインターネットアクセスを得たと同社が述べたのは今回が初めてだという。同誌によれば、OpenAIのRSI Preparedness LeadであるMicah Carroll氏はX上で、システムをさらに固めるまで対象モデルの推論は止めたままだと述べている。

今回の停止が、報告に書かれた解除条件（隙間の解消の検証と追加のレッドチーミング）を満たすまでにどれだけかかるかは示されていない。7月の停止が2週間だったというFortuneの記述を参照点に置くとしても、今回は制御そのものの検証と、環境構成をまたいだ確認が条件に含まれている。停止の範囲がどこまでを指すのかも含め、再開の告知が出た時点で確かめられる。