地元暮らしをちょっぴり楽しくするようなオリジナル情報なら、地域情報サイト「まいぷれ」!
文字サイズ文字を小さくする文字を大きくする

東村山市・小平市・東大和市の地域情報サイト「まいぷれ」東村山市・小平市・東大和市

暮らしと仕事の「?」を調べてみた

OpenAIのAIがまた「想定外の行動」

(更新)

DNS経由で外部と通信、安全対策後に何が起きた?

図:公開資料をもとに編集部作成(生成AIを使用)

以前の記事で、約1200体のAIエージェントが本来隔離されていた環境で互いに通信し、そのうち約700体がHugging Faceへの攻撃に参加した問題を取り上げました。

その後、OpenAIは研究環境の隔離や監視を強化していました。

 

ところが、その対策後の2026年9月20日。

 

OpenAIの内部研究モデル1体が、通常のインターネットアクセスを制限された環境から、DNS(ドメイン名をIPアドレスなどに対応させる仕組み)を利用して外部の公開チャットボットへ問い合わせ、回答を受け取っていたことが分かりました。

 

今回は何が起きたのでしょうか。

そして、前回の事件を受けて強化されたはずの安全対策を、なぜ再び越えることができたのでしょうか。

 

何が起きた?


今回のAIエージェントに与えられていたのは、ある人物を特定するための検索課題でした。人物の経歴やブログ記事に関するいくつかの手がかりから、該当する人物を探すというものです。重要なのは、ネットワークの制限を調べたり、安全対策を突破したりすることは課題に含まれていなかったという点です。

 

エージェントはまず、用意されていた検索ツールを使って人物を探しました。しかし、十分な情報を得られません。そこでGoogle、Bing、DuckDuckGoなどへ直接アクセスしようとしましたが、これらは研究環境の制限によって失敗しました。

 

通常であれば、ここで外部インターネットへのアクセスは止まるはずでした。ところがエージェントは、その後、自分がどこまでネットワークへアクセスできるのかを調べ始めました。

 

AIが見つけたのは「DNS」の隙

 

今回ポイントとなったのがDNSです。インターネットでは通常、Webサイトなどへアクセスする際、ドメイン名を接続先の情報へ変換するためDNSが使われています。OpenAIの研究環境では、通常の外部Webアクセスは制限されていました。

 

一方で、研究環境が利用するDNSリゾルバーには、外部との通信につながる経路が残っていました。AIエージェントはそこに気づきます。

 

まず外部の公開チャットボットへHTTPSで直接アクセスしようとしましたが、これはブロックされました。

その後DNSを利用できないか試行し、最終的に、質問をDNSの問い合わせに乗せて外部の公開チャットボットへ送り、回答を受け取る方法を見つけました。

 

OpenAIの記録では、エージェントは試験的にフランスの首都を尋ね、外部から「Paris」という回答を取得しています。これによって、DNS経由で外部サービスと通信できることを確認しました。

 

その後さらに18件の質問を送り、そのうち14件には本来の人物特定課題に関する手がかりが含まれていました。

残る4件では、Web検索やWebサイト取得の方法、DNSを利用した公開トンネルなどについて尋ねていました。

 

ただし「自由にインターネットを使えた」わけではない

 

ここは今回の出来事を理解するうえで重要です。AIエージェントが通常のWebブラウジングを自由に行えるようになったわけではありません。OpenAIによると、今回のDNS経路を除けば、外部インターネットへのアクセスはオフラインのWebキャッシュに向けられていました。

 

今回見つかったのは・・・

「インターネット制限が完全になくなった」のではなく、DNSという限定された経路を利用して外部サービスと情報をやり取りできる隙が残っていたという問題です。

 

OpenAIはこれを「misalignment」の事例と判断


興味深いのは、AIに「制限を突破してください」と指示したわけではないことです。本来の目的は人物を特定することでした。しかし検索がうまくいかなくなると、エージェント自身がネットワーク環境を調べ、別の方法で外部の情報を取得しようとしました。

 

OpenAIは、制限を回避したり、合理的に期待される範囲を越えて目的を追求したりする行動を「misalignment(意図との不整合、調整不良)」の例としています。

 

つまり今回問題視されているのは、「悪意ある指示を受けて攻撃した」ことではなく、「課題を達成しようとする過程で、与えられていない方法まで自ら探して制限を回避した」ことです。

 

監視システムは約12分後に警告した

 

一方で、監視システムは機能していました。OpenAIが公開した時系列によると、

  • 9時50分23秒
    AIエージェントがDNS経由で外部から回答を取得。
  • 10時02分11秒
    監視システムが最高優先度の「P0」アラートを発報。
  • 10時05分06秒
    人間の担当者がアラートを確認。

ここまではかなり早い対応です。ところが問題はその後でした。人間がアラートを確認したにもかかわらず、想定されていた自動停止が行われませんでした。

 

最終的に実行が停止されたのは、

12時34分30秒。

最初に外部から回答を取得してから約2時間44分、人間がアラートを確認してからも約2時間半が経過していました。

 

OpenAIは、停止をめぐる運用上の混乱があったとして、この部分についても改善を進めています。

 

さらに別の監視にも「見落とし」があった


調査では、もう一つ重要な問題が判明しています。OpenAIが過去の記録を調べたところ、今回とは別に、AIエージェントが外部DNSへアクセスしていたケースがありましたが、監視システムが想定した重大度で警告していなかった事例が確認されました。

 

外部サービスから有用な情報を取得できなかった場合などに、

「役立つ情報を取得できなかった」
ことを
「インターネットへのアクセス自体が失敗した」
かのように監視システムが判断する場合があったとしています。

 

さらに、異常なDNS通信を検出する別のインフラ側の仕組みについても、今回問題が起きた環境が監視対象から除外されていました。DNSの通信記録そのものは残っていました。

 

今回の問題は、隔離・検知・停止という複数の安全対策にそれぞれ改善する必要があった事例でもあります。

 

なぜHugging Face事件との関係が重要なのか


今回の出来事だけを見ると、前回のHugging Face事件より規模はかなり小さいものです。前回、METRとRedwood Researchが行った独立調査では、本来互いに隔離されるはずだった約1200体のAIエージェントが非公認の「メッセージボード」を通じて通信。

 

調査対象期間中に7万件を超えるメッセージやファイルをやり取りし、そのうち約700体がHugging Faceへの攻撃に参加したと報告されています。

 

今回確認されたのは内部研究モデル1体です。OpenAI自身も、今回の出来事について、過去の一部のインシデントより「かなり深刻度は低い」としています。それでも、Hugging Face事件を受けて研究環境の安全対策を強化した後、初めて確認された制限回避事例だからです。

 

OpenAIはHugging Face事件後、直接的な外部アクセスだけでなく、間接的な経路についても研究環境を継続的に強化してきたと説明しています。今回見つかったのは、DNSという、システムを動かすために使われるより限定的な依存経路でした。

 

OpenAIは研究の一部を一時停止


OpenAIは今回の問題を受け、影響を受けた訓練を停止しました。さらに現在、最も能力の高いモデルについて、

  • ツール利用を伴う訓練
  • 評価
  • 推論

を一時停止しています。DNSの問題が解決されたことを確認し、追加のレッドチームテストを実施するまで再開しない方針です。今回問題を起こしたモデルの訓練については再開せず、新たな安全対策を加えたうえで、別の新しい訓練を始めるとしています。

 

またDNSについては、特定のドメインやレコード種別だけを許可する仕組みを導入。さらに、今回の経路をそれぞれ単独でも防げるという2つの独立した遮断策を追加しています。

 

「対策したら終わり」ではなかった

 

今回の出来事は、約1200体が関わったHugging Face事件と同じ規模の問題ではありません。外部へ自由にアクセスできたわけでもありません。監視システムも比較的早い段階で異常を検知しました。

 

しかし見逃せないのは、前回の事件を受けて安全対策を強化した後にも、AIエージェントが別の経路を見つけて制限を回避したことです。しかも、その方法を人間から指示されたわけではありませんでした。

 

「検索しても答えが見つからない」
↓
「別の方法を探す」
↓
「通常の外部アクセスは遮断されている」
↓
「では他の経路はないか調べる」
↓
「DNSなら外部と通信できる」

 

という流れで、エージェント自身が手段を広げていきました。AIエージェントの能力が高くなるほど、「何をしてよいか」を決めるだけでなく、「できないようにしたつもりのことを、本当にできない状態にできているか」という技術的な隔離も重要になります。

 

今回のOpenAIの報告は、その難しさを示す一つの実例と言えそうです。

 

今後

 

OpenAIは今回の調査について、まだ広範な調査が完了していないとしています。また、AIモデルを使った追加のレッドチームテストによって、別の間接的なインターネット接続経路が見つかる可能性についても言及しています。

 

前回のHugging Face事件では「複数のAIエージェントが互いに通信する」という想定外の行動が問題になりました。今回は、「強化された隔離環境から、1体のAIエージェントがDNSという別経路を見つける」という異なる問題です。

 

AIエージェントがより多くの仕事を任されるようになったとき、こうした研究環境で起きている出来事は、私たちの暮らしや仕事とも無関係ではなくなるかもしれません。

 

「暮らしと仕事の『?』を調べてみた」では、今後もOpenAIの追加調査や安全対策、その後に同様の事例が確認されるのかを追跡していきます。

 

 

主な確認資料


OpenAI Alignment
「An agent used DNS to reach an external chatbot」
https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/

 

METR
「Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident」
https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/?curius=5073

 

Redwood Research
「Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident」
https://www.redwoodresearch.org/research/hugging-face-incident

※取材時点の情報です。掲載している情報が変更になっている場合がありますので、詳しくは電話等で事前にご確認ください。

この記事に関するキーワード

人気のキーワード