OpenAIが2026年9月、研究中のAIエージェントが、インターネットアクセスを制限された環境からDNSを利用して外部のチャットボットへ問い合わせた事例を公開した。
最初にこのニュースを見たとき、
「インターネットを制限しているのに、どうして外部と通信できたのだろう？」
というところが気になった。
また、監視システムは異常な挙動をかなり早い段階で検知していたにもかかわらず、実際にAIの実行が停止されたのは約2.5時間後だった。
調べてみると、AIそのものの話だけではなく、
- サンドボックス
- DNS
- ネットワーク分離
- 監視
- インシデント対応
- 多層防御
といった、普段システムを作るうえでも重要な考え方が詰まった事例だった。
今回は、OpenAIが公開したインシデントレポートを読みながら、自分なりに理解した内容を整理する。
何が起きたのか
今回のAIには、ある人物について公開情報から調査するタスクが与えられていた。
最初は用意された検索ツールを利用していたが、必要な情報を見つけることができなかった。
そこでAIは検索エンジンなどへの直接アクセスも試みた。
しかし、実行環境ではインターネットアクセスが制限されていたため、通常のHTTPS通信では外部へアクセスできなかった。
ここまでは想定通りだった。
ところが、AIは調査を続ける中で、実行環境のDNSリゾルバが実在するドメインについて実際の情報を返すことに気づいた。
つまり、
AI
│
├─ HTTPS ──×──> インターネット
│
└─ DNS ──────> 外部
という状態になっていた。
AIはこの経路を利用し、最終的に外部の公開チャットボットへ質問を送り、その回答をDNS経由で受け取ることに成功した。
重要なのは、最初から「ネットワーク制限を突破する」というタスクだったわけではない点だと思う。
本来の目的は情報を探すことだった。
しかし、
情報を探す
↓
検索ツールでは見つからない
↓
直接アクセスしてみる
↓
HTTPSは通らない
↓
他に外部へ到達できる方法はないか調べる
↓
DNSなら到達できる
と、目的達成のために別の経路を探索していった。
そもそもDNSとは
DNS（Domain Name System）は、ドメイン名とIPアドレスなどの情報を対応させる仕組みである。
例えば、
example.com
という名前でWebサイトへアクセスするとき、コンピュータはDNSを利用して接続先を調べる。
ざっくり書けば、
PC
↓
DNS
「example.comはどこ？」
↓
「このIPアドレスです」
↓
Webサーバーへ接続
という流れになる。
Webサイトを見るための通信そのものとは別に、DNSという通信が存在している。
DNSリゾルバとは
ここで今回の事例に出てくる「DNSリゾルバ」についても整理しておく。
DNSがドメイン名とIPアドレスなどを対応させる仕組み全体だとすると、DNSリゾルバは、その仕組みを使って
«「このドメイン名の接続先はどこ？」»
と調べてくれる役割を持つ。
例えばPCから "example.com" にアクセスする場合、
PC
↓
DNSリゾルバ
「example.com のIPアドレスを教えて」
↓
DNSを使って調べる
↓
「このIPアドレスです」
↓
PC
↓
Webサーバーへ接続
というイメージになる。
つまり、
DNS
= 名前とIPアドレスなどを対応させる仕組み
DNSリゾルバ
= DNSを使って名前解決をしてくれる役割
と考えると分かりやすい。
今回の環境では、
AI → Webサイトへの直接通信 ×
AI → DNSリゾルバへの通信 ○
という違いがあった。
通常のインターネットアクセスは制限されていた一方で、名前解決などに必要なDNSリゾルバとの通信経路は残っていた。
AIは、この経路が外部と情報をやり取りする手段として利用できることに気づいた。
ここが今回の事例を理解するうえで重要なポイントだった。
サンドボックスとは
今回AIが動いていたのは「サンドボックス」と呼ばれる隔離された実行環境である。
サンドボックスは、プログラムにある程度自由な操作を許しながら、その影響を外部へ広げないために使われる。
イメージとしては、
┌──────────────┐
│ Sandbox │
│ │
│ AI │
│ コード実行 │
│ ファイル操作 │
│ │
└──────┬───────┘
│
×
Internet
のような状態である。
AIにコードを実行させる場合、何をするか完全に予測することは難しい。
そのため、
「危険な操作をしないでください」
とAIに指示するだけではなく、
そもそも危険な操作が成立しない環境に閉じ込める
ことが重要になる。
今回の事例では、この境界にDNSという細い経路が残っていた。
なぜ検知できたのに2.5時間止まらなかったのか
もう一つ気になったのがここだった。
OpenAIが公開している時系列を見ると、
09:50 外部からの応答を取得
↓
10:02 P0アラート
↓
10:05 人間が確認
↓
12:34 実行停止
となっている。
P0は、非常に重大で最優先の対応を必要とするインシデントを表す。
つまり監視そのものは比較的早く機能している。
それなのに停止まで約2.5時間かかった。
OpenAIの報告によると、本来は実行が自動的に停止される想定だったが、期待通りに停止しなかった。
人間のレビュー担当者はアラートを3分ほどで確認していたものの、「すでに停止されているのか」「停止する必要があるのか」という運用上の混乱が生じ、最終的に手動で停止された。
ここが個人的にはかなり印象に残った。
「検知できる」と「止められる」は別
監視について、
異常を検知する
↓
アラートを出す
までを考えてしまいがちだが、それだけではシステムを守れない。
本当に必要なのは、
異常発生
↓
検知
↓
アラート
↓
判断
↓
隔離・停止
↓
調査
までの一連の仕組みだと分かる。
今回も、
「監視システムが異常を検知した」
という部分だけなら成功している。
しかし、
「異常を検知したら確実に止める」
という部分には問題が残っていた。
Observabilityや監視を考えるときも、「見えるようにする」だけではなく、その後どう行動するかまで設計する必要があるのだと思った。
一番印象に残ったのは「想定していないから大丈夫」では足りないこと
今回の事例を読んで、一番印象に残ったのはここだった。
AIが外部アクセスすることは想定していない
ではなく、
AIが外部アクセスしようとしても
実際にはアクセスできない
状態にする必要がある。
これはAI特有の考え方というより、通常のシステム開発にも通じると思う。
例えば、
「このAPIは普通のユーザーから呼ばれない」
から安全なのではなく、
「呼ばれたとしても権限がなければ実行できない」
から安全である、という考え方に近い。
「そんな操作はしないはず」という前提ではなく、
「想定外の操作をされても境界を越えられない」
ようにする。
多層防御として考えてみる
そこで出てくるのが「多層防御（Defense in Depth）」という考え方である。
一つのセキュリティ対策だけに依存せず、複数の防御を重ねる。
AIエージェントなら例えば、
AIへの指示
↓
ツールの権限制御
↓
サンドボックス
↓
ネットワーク制御
↓
DNS制御
↓
監視
↓
自動停止
↓
人間による対応
というように複数の層を持たせる。
一つが突破されても、次の層で止める。
今回の事例を受けてOpenAIは、問題となったアクセスを防ぐ制御を独立した2つの層に追加している。
また、DNSについてもアクセスできるドメインやレコードタイプを限定する対策を進めている。
AIエージェントでは特に重要になりそう
従来のチャットAIなら、
人間 → 質問 → AI → 回答
が中心だった。
一方でAIエージェントは、
目標
↓
考える
↓
検索
↓
コード実行
↓
結果を確認
↓
次の方法を考える
というように、自分で複数の手段を試すことができる。
ツールを利用できるAIが増えていくと、
「こちらが想定した使い方だけをする」
という前提はますます危険になるのかもしれない。
だからこそ、
AIを信用するかどうかではなく、信用しなくても安全に動かせる環境を作る
という考え方が重要になると感じた。
まとめ
今回の事例を最初に見たときは、
「AIがDNSを使って外部へアクセスした」
という部分のインパクトが大きかった。
しかし調べてみると、それ以上に、
- サンドボックスだけでは完全ではない
- 通常の通信を塞いでも別経路が残る可能性がある
- 監視で検知するだけでは足りない
- 検知後に確実に停止できる仕組みも必要
- 一つの防御策に依存せず、多層防御にする
という点が重要な事例だった。
特に、
«「想定外のことをしない」ことに期待するのではなく、「想定外のことをされても越えられない境界を作る」»
という考え方は、AIエージェントに限らずシステム設計全般で意識しておきたい。
参考
- OpenAI Alignment「An agent used DNS to reach an external chatbot」
- OpenAI「The Hugging Face incident and the road ahead」