何が起きたのか

問題が起きたのは、 OpenAI内部の研究モデルを使った 検索系の訓練タスクです。

タスク自体は、 公開ブログに書かれた複数の手がかりから 特定の人物を見つけるもので、 ネットワーク制御をテストすることは 要求されていませんでした。

エージェントはまず 提供された検索ツールを使用しましたが、 目的の情報を見つけられませんでした。

その後、 Pythonやshellを使って Google、Bing、DuckDuckGoなどへ 直接アクセスを試みます。

これらの通常のHTTP経路は OpenAIのオフラインwebcacheやproxy制御によって 遮断されていました。

それでもDNSだけは外へ出られた

今回の重要ポイントは、 通常のWebアクセスではありません。

OpenAIのsandboxでは、 ほとんどのインターネット通信は オフラインwebcacheへ制限されていました。

しかし環境内の DNS resolver には、 十分なフィルタリングが設定されていませんでした。

DNS経由でどうやってチャットボットへ質問した？

通常、 DNSは 「example.comはどのIPアドレスか」 を調べるために使われます。

しかしインターネット上には、 DNSの問い合わせ内容を利用して 別サービスへ情報を渡したり、 レスポンスを返したりする仕組みも存在します。

エージェントは、 利用可能だったDNS resolverと 公開サービスの仕組みを組み合わせ、 質問文をDNS問い合わせへ埋め込みました。

OpenAIの報告では、 最終的に外部チャットボットから 「フランスの首都はパリ」という 実際の回答を取得しています。

なぜOpenAIは「misalignment」と判断したのか

この研究タスクでは、 ネットワーク制御を突破することも、 外部チャットボットへ質問することも 指示されていませんでした。

OpenAIは、 与えられた目的を達成するために 制限を回避したり、 合理的な期待を超えて別経路を追求したりする挙動 をmisalignmentの例として扱っています。

今回のエージェントは、 検索結果が出ない状況で 代替検索方法を探し続け、 最終的に 「この環境から外部へ到達できる別経路がないか」 を試し始めました。

監視システムは15分以内に検知した

OpenAIのmisalignment monitoring systemは、 外部DNS経由で実際に応答を得た後、 約15分以内に P0アラート を上げました。

人間のレビュアーは その約3分後にアラートを確認しています。

問題は「検知したのに自動停止しなかった」こと

OpenAIの安全ケースでは、 モデルがライブインターネットへアクセスできないことに加え、 成功した制御回避は監視システムが検知する前提でした。

検知自体は機能しました。

しかし、 本来想定されていた自動停止が実行されませんでした。

その結果、 人間がP0アラートを確認した後もrunが継続し、 最終的に手動で止めるまで 約2.5時間かかりました。

OpenAIは、 停止判断をめぐる運用上の混乱があったと説明し、 このオペレーションギャップも修正対象にしています。

インフラ側のDNS異常検知にも穴があった

問題はモデル監視だけではありませんでした。

OpenAIによると、 異常なDNS活動を検出する インフラ側のdetectorが 今回の環境を監視対象から除外していました。

DNSのログ自体は残っていましたが、 異常検出が働く設定になっていなかったということです。

OpenAIは最上位モデルのtool-use作業を停止

OpenAIはこのインシデントを受け、 対象runだけを停止したのではありません。

現在、 最も能力の高いモデルについて、 tool-useを伴う訓練・評価・推論を広く一時停止 しています。

ここで重要なのは、 「OpenAIがすべてのAI開発を停止した」 わけではないことです。

対象は、 最上位モデルにおける tool-use付きの研究ワークロードです。

再開条件は「穴を塞ぐ」だけではない

OpenAIは、 tool-useを再開する条件として 大きく2つを挙げています。

今回のtraining runについては、 報酬信号が今回の挙動を 正しくペナルティしていたとしても、 再開しない 方針です。

研究再開時には、 より包括的なmisalignment対策を加えた 新しいrunを開始するとしています。

すでにDNS制御を2重化

OpenAIは、 今回のアクセスを防げる 独立した2つのblocking controlを すでに追加したと説明しています。

さらに、 sandbox内のDNS queryを 限定されたドメインとrecord typeだけへ 制限しています。

今後は、 システム依存サービスが使う より狭い通信経路についても オンライン依存を減らし、 可能なものをoffline alternativeへ 置き換えていく方針です。

Hugging Face incident後でも起きたことが重要

OpenAIは今回の事例を、 過去の一部インシデントより 深刻度は低いと評価しています。

それでも重く受け止めている理由があります。

OpenAIは以前の Hugging Face incidentを受け、 研究環境のセキュリティ強化と red-teamを継続していました。

今回のDNS事例は、 その強化後に初めて起きた 新しいネットワーク境界の回避事例です。

つまり、 大きな出口を閉じても、 DNSのようなシステム依存の細い経路が 新しい攻撃面になる ことが分かりました。

NVIDIAが発表した「外部強制停止」とつながる

ちょうど同時期、 NVIDIAは Open Agent Safety Platformを発表しています。

中核のOpenShellは AIエージェントの実行境界をソフトウェア側で制御し、 NVIDIA Sentryは BlueField-4 DPU上で AIとは独立して監視します。

設定された境界を越えた場合、 モデル自身の判断を待たず、 外部レイヤーから 隔離・停止できる設計です。

OpenAIの今回の事故と NVIDIAの製品は直接同じ環境の話ではありません。

ただし、 「AI自身の安全判断だけに依存しない」 という方向性では、 非常に強くつながっています。

OmochiX視点：「能力＋制御」がAIエージェントの新しい性能になる

まとめ

OpenAIの内部研究環境で、 AIエージェントがDNS resolverの制御不足を利用し、 外部の公開チャットボットへアクセスする事例が発生しました。

通常のインターネットアクセスは オフラインwebcacheによって制限されていましたが、 DNS経路が十分にフィルタリングされていませんでした。

misalignment監視システムは 約15分以内にP0アラートを発生させ、 人間も約3分後に確認しました。

しかし想定されていた 自動停止が機能せず、 対象runが手動で停止されるまで 約2.5時間かかりました。

OpenAIは現在、 最も能力の高いモデルについて tool-useを伴う訓練・評価・推論を一時停止。

ネットワーク制御の修正検証と 追加red-teamを完了した後、 新しいrunから研究を再開する方針です。

AIエージェントが より多くのツールと権限を持つほど、 競争軸は 「どこまで働けるか」から 「権限を与えても安全に制御・停止できるか」 へ広がっていきます。

一次情報