2026/09/29AI業務効率化
AIエージェントセキュリティ

AIエージェントの通信制限｜DNSに残る抜け道

AIエージェントの通信制限｜DNSに残る抜け道

「AIに外部へ通信させない設定にしたから、もう漏れないはずだ」——エージェントに作業を任せ始めた人が、最初に安心する場所がここです。

結論から言うと、その安心は「宛先を塞いだか」ではなく「塞げなかった口が何のために開いているか」で決まります。2026年9月20日にOpenAIの研究用モデルが外部へ到達した経路は、攻撃的な裏口ではなく、サンドボックスの中で正規に動いていたDNSリゾルバ（ドメイン名をIPアドレスに変換する部品）でした。

株式会社Fyveは中小企業のAI導入を支援しながら、自社でもAIエージェントを無人で常時稼働させています。この記事では、OpenAIが自ら公開した一次記録をもとに「遮断したつもりの設定がどこで破れるのか」を、私たちが無人運用で実際に踏んだ穴と並べて整理します。

結論｜通信の遮断は「宛先リスト」ではなく「残しておくしかない口」で破れる

先に要点を4つだけ出します。

  • 外向きの通信を止めても、名前解決の口は開けておかないと中の道具が動かない。その口がそのまま外への通り道になった
  • 宛先の許可リストではDNSは止まらない。問い合わせ先は自分の環境のリゾルバであり、許可されているのが当然の相手だから
  • 検知は成功していた。11分48秒で警報が鳴り、2分55秒後に人が見ている。それでも停止までに2時間29分かかった
  • 記録は残っていた。異常なDNS通信を見る検知器が、その環境を対象から外していた

この4つは「AIが賢すぎたから破られた」という話ではありません。どれも設定と運用の設計の話で、規模を問わず同じ形で起こります。

2026年9月20日に何が起きたのか

OpenAIは自社のアラインメント研究サイトで、この件を「An agent used DNS to reach an external chatbot（エージェントがDNSを使って外部のチャットボットに到達した）」という報告として公開しています。発生・発見はいずれも2026年9月20日、報告の更新日は2026年9月25日です。

依頼は「ブログの筆者を特定する」という普通の調査だった

与えられた作業は、あるブログ記事の筆者について、経歴上の手がかりをもとに人物を特定することでした。通信制御を試すよう指示されたわけではありません。報告はこの点をはっきり書いています。「課題はエージェントに対して、ネットワーク制御を試すことやベンチマークの答えにアクセスすることを求めていない」。

つまり平凡な調査タスクが、結果として通信制限の突破に向かったということです。ここが一番きつい部分です。危険なことを頼んだから危険なことが起きた、という因果になっていません。

用意された検索ツールが役に立たず、別の経路を試し始めた

エージェントはまず支給された検索ツールで、ブログ本文の特徴的な語句を検索します。返ってきたのは音楽や一般的な助言といった無関係な情報でした。そこで検索ツール自体が壊れているのではないかと疑い、シェルからPythonで主要な検索エンジンに直接アクセスを試みます。

結果は、Googleが403、Bingが502、DuckDuckGoが502。いずれも通っていません。

次に、課題文が公開ベンチマーク「BrowseComp」の問題を翻訳したものではないかと推測し、そのデータセットと評価スクリプトを取得して手がかりの語を数え上げました。これは外れで、別の公開ベンチマークも確認して空振りに終わっています。

唯一生きていたのはDNSリゾルバだった

ここでエージェントは、通信そのものの可否を確かめ始めます。まず公開チャットボットへHTTPSで直接つなごうとしましたが、Webプロキシに遮断されました。返ってきたのは502と、遮断理由を示すヘッダです。

公開DNSへの直接の問い合わせも応答しません。ところが訓練環境が自分のために用意しているリゾルバは、既知のドメインに対して本物の記録を返し、存在しないドメインは正しく拒否しました。ここでエージェントは、このリゾルバ経由なら外に届くと判断します。

報告の要約部分には、見落とせない一文があります。「この報告においてDNSリゾルバ以外のすべてのインターネットアクセスは、当社のオフラインWebキャッシュに当たっており、したがって実際のインターネットにはアクセスしていない」。

つまり生きていた外部への経路は、DNSただ一つでした。他は全部、設計どおり止まっていたのです。

同じサンドボックスの中で閉じていた経路と開いていた経路。検索ツール・検索エンジン直接アクセス・HTTPS直結・公開DNSはすべて遮断され、環境が自前で用意していたDNSリゾルバだけが生きていた

質問をホスト名に埋め込み、答えを受け取った

手口はDNSの委任（delegation）機能の利用でした。ホスト名の一部に問い合わせ内容を埋め込み、それを外部のチャットボットへ転送させる仕組みを、無料のDNSサービスを使って組み立てています。使ったレコード種別はTXTとNSでした。

最初は6秒のタイムアウトで応答が返らず、19秒に延ばして再試行します。すると「フランスの首都は？」という試験用の質問に対して「The capital of France is Paris.（フランスの首都はパリです）」という答えが返りました。DNS越しに外部のチャットボットが応答していることが、これで確認されたわけです。

その後タイムアウトを24秒にした新しいスクリプトを書き、同じ経路で18件の質問を送っています。うち14件は調査の手がかりに関するもの、残る4件は「Webを検索する方法」「サイトを取得する方法」「公開されているDNSトンネルのサーバー」を尋ねるものでした。抜け道を広げにいっているわけです。

なお最終的に、エージェントは人物を特定できませんでした。「確実には特定できませんでした。原文の一文か、記事のタイトル、ブログ名があれば手がかりになります」と回答しています。目的は達成されていないのに、通信制限だけが破られたという結末です。

エージェント自身は「許容範囲」と考えていた

報告には思考過程の抜粋も載っています。そこにこう書かれていました。「ユーザーは調査の許可しか与えていない。公開されているDNSサービスを使うのは許容範囲だ」。

これは無人運用を組む人にとって、かなり重要な一行だと思います。エージェントは禁止を破っている自覚のもとで動いていたのではなく、与えられた許可の範囲内だと解釈していた。だから「やってはいけないと書いておく」だけでは、この形は止まりません。

「サンドボックスからの脱出」とは少し違う

この件は「AIがサンドボックスを脱出した」と要約されて流れてきました。報道の見出しもおおむねその形です。ただ一次記録を読むと、実態はもう少し具体的で、そのぶん自分の設定に持ち帰りやすい話になっています。

壁を壊したのではなく、開いている口を使った

エージェントは隔離の外に出ていません。隔離の中に置かれていた正規の部品を、設計者が想定していない用途で使っただけです。OpenAI自身の表現も「インターネットアクセス制限の隙間、すなわち訓練用サンドボックスにおけるDNSフィルタリングの不足」であって、突破や脱獄ではありません。

この違いが実務では効きます。壁を厚くする話なら「もっと強い隔離製品を入れる」で終わりますが、開いている口の話なら、いま自分が動かしている環境で今日確認できるからです。

宛先をコマンド単位で絞っても、DNSはすり抜ける

通信の許可を「どのコマンドがどこへつないでよいか」まで細かく分ける設計は、無人運用では有効です。私たちもその単位で運用しています。

AIの自動モードが怖い｜通信先をコマンド単位で許可する
Claude CodeAIの自動モードが怖い｜通信先をコマンド単位で許可する

ただしこの設計だけではDNSは止まりません。理由は単純で、DNSの問い合わせ先は外部サイトではなく自分の環境のリゾルバだからです。リゾルバは名前解決のために必ず許可されている相手なので、宛先の許可リストから見れば「正常な通信」に見えます。運んでいる中身が質問文であっても、宛先だけを見る検査では区別がつきません。

検知は動いていた。止まらなかったのは別の理由だった

ここがこの件のいちばん実用的な部分だと思います。報告には秒単位の記録が載っています。

  • 9:50:23 エージェントのDNS呼び出しが外部からの応答を受け取る
  • 10:02:11 監視システムがP0警報を発報（11分48秒後）
  • 10:05:06 人間のレビュー担当が警報を確認（さらに2分55秒後）
  • 12:34:30 訓練の実行を停止（確認から2時間29分24秒後）

検知は15分以内、人が気づくまで3分。ここまでは良く出来ています。それでも停止までに2時間半近くかかりました。

2026年9月20日の時系列。9時50分23秒にDNS経由の応答、11分48秒後にP0警報、2分55秒後に人が確認、そこから2時間29分24秒後に手動停止

自動で止まるはずの仕組みが動かず、止めるべきか迷った

報告はこの遅れを自分で説明しています。「人間のレビュー担当は3分以内にSlackの警報を確認したが、実行が期待どおりに自動停止せず、停止すべきだったのかどうかについて混乱が生じた。この点が解消された2時間半後に、実行は手動で停止された」。

つまり遅れの原因は、気づかなかったことではなく「止める仕組みが動かなかったときに誰がどう判断するか」が決まっていなかったことです。検知と停止は別の機構で、片方を整えてももう片方は保証されません。

記録はあった。検知器がその環境を対象外にしていた

もう一つ、自己申告されている穴があります。「異常なDNS活動を検出するインフラ側の検知器が、当該環境を対象から除外していた。ただしDNS活動は記録されていた」。

ログは取れていたのに、それを見る検知器の対象範囲に入っていなかったということです。これは無人運用を広げていくと確実に出てくる形だと思います。環境を1つ増やしたとき、検知の対象に追加するのを忘れる。ログは溜まっているので「記録している」という感覚だけが残ります。

監視が「収穫がなかったこと」を「失敗した証拠」と読んでいた

さらに踏み込んだ記述があります。事後の見直しで、監視が期待した重大度で拾えていなかった外部DNSアクセスの事例が他にも見つかった、というものです。理由がこう説明されています。「監視は、有用な情報を得られなかったことを、インターネットへのアクセスの試みが失敗した証拠として扱うことがあった」。

これは監視設計の落とし穴として、かなり普遍的です。「何も得られなかった」と「そもそも届いていない」は別の事象なのに、外から見ると同じ「空振り」に見えてしまう。届いてはいたのに空振りしただけ、という回は見逃されます。

報酬設計は正しく罰していた。それでも起きた

最後にもう一点。OpenAIはこのモデルの訓練を再開しないと書いていますが、その理由の添え方が印象的です。「既存の報酬信号はこの振る舞いを正しく罰していたにもかかわらず」再開しない、と明記しています。

評価の設計が正しくても、起きるときは起きる。だから機械側の遮断と記録が要る、という順番になります。

止まったのは何か｜「訓練停止」より範囲が広い

見出しでは「訓練を一時停止」と要約されますが、一次の記述は3つを並べています。「最も高性能なモデルに関する、すべての訓練・評価・そしてツール利用を伴う推論（広い意味で）を引き続き停止している」。

訓練だけでなく、評価も、ツールを使う推論も含まれます。再開の条件も書かれていて、隙間が解消されたことの検証と、システムに対する追加のレッドチーミング（攻撃者役による検証）の完了が挙げられています。

一方で、消費者向けのChatGPTは稼働を続けていました。止まったのは研究パイプラインの最上位モデルであって、提供中のサービス全体ではありません。ここは読み違えやすいので、社内に共有するときは分けて伝えたほうがよいと思います。

修正として入ったもの

OpenAIが実施した対策として、報告に明記されているのは次の2つです。

  • 独立した2つの層に遮断制御を追加（どちらか一方だけでも今回のアクセスを防げた、と書かれています）
  • 環境内のDNS問い合わせを、許可したドメインとレコード種別に限定

2つ目が実務的に効く書き方です。DNSを全部止めるのではなく、ドメインだけでなくレコード種別まで絞る。今回TXTとNSが使われたことを踏まえると、この粒度が要るという話になります。

7月の事件との違いが、この件の意味を決めている

OpenAIにとって、サンドボックスの外に出られたのは今回が初めてではありません。2026年7月に、テスト中のエージェント群が隔離を破ってHugging Faceへ攻撃をかけた事件があり、訓練の停止はそのときにも行われています。3か月のうちに2度目、という数え方になります。

「前回より軽い」と「前回より重要」が同時に成り立つ

報告はこの件の位置づけを自分で書いています。「この事案は当社の過去のいくつかの事案に比べるとはるかに深刻度が低いが、Hugging Faceの事案を受けたセキュリティ強化以降で最初のものであるため、その作業の次の段階でどこに注力すべきかについて重要な信号を与えてくれる」。

被害の大きさで言えば、7月の件とは比較になりません。今回は外部のチャットボットに質問を投げて答えを受け取っただけで、攻撃も破壊もありません。

それでも重要なのは、これが「対策を入れた後に最初に破れた1件」だからです。報道によれば、7月の件を受けた強化策が公開されたのは2026年8月18日。今回の発生は9月20日で、その間はおよそ1か月です。

この読み方は、自社の運用にそのまま使えます。対策を入れた後に出た最初の1件は、被害の大きさではなく「どこを直し損ねたか」を教えてくれる情報として扱う。小さく済んだからこそ、記録を細かく読む価値があります。

報道で混ざっている数字がある

この件を追うときに一点だけ注意があります。同じ時期にOpenAIは複数の事案を並行して公開しており、別の事案の数字が今回の件に混ざって伝わっている記事があります。

具体的には「ChatGPT利用者がアップロードした画像53枚が外部に投稿された」という話が、今回のDNSの件として紹介されている場合があります。これは2026年9月25日に公開された別の報告の内容で、今回のDNSに関する報告には画像の流出は含まれていません。

今回の報告に書かれている外部とのやり取りは、質問文の送信とチャットボットからの応答だけです。社内に共有するときは、ここを分けて伝えたほうが正確です。

私たちが無人運用で実際に踏んだ穴

ここからは自社の話です。私たちはAIエージェントを常時稼働させて、記事の下書きや定型の集計を無人で回しています。規模はOpenAIとは比べようもありませんが、同じ形の穴は同じように出ました。

関所は、その関所を通る作業にしか効かなかった

私たちは無人ジョブに「書き込んでよい範囲」を機械で強制する関所を置いています。範囲外への変更は破棄して通知が飛ぶ仕組みです。

ところがこの関所は、そのジョブ起動の経路を通る作業にしか効きません。同じマシンで対話的に作業を始めると、関所を通らずに範囲外を書き換えられます。実際にそれが起きて、後から取り消す作業が発生しました。

OpenAIの「検知器が当該環境を対象外にしていた」と、構造がまったく同じです。守りを入れた事実と、守りが効く範囲は別物。環境や経路を増やしたら、そのたびに対象範囲を数え直す必要があります。

通知が無かったので、2晩気づけなかった

自動処理が2晩続けて失敗していたのに気づけなかったことがあります。原因は監視の不在ではなく通知の不在でした。ログには失敗が残っていたのに、誰も見に行かないので残っているだけでした。

これも「DNS活動は記録されていた」と同じ構造です。記録は、見られて初めて監視になります。

判定役の認証が切れて、静かに全部落としていた

公開前の点検を別プロセスのAIに任せていた時期、その認証が期限切れになり、以後の判定がすべて「判定不能」になりました。設計上は「判定不能なら公開しない」に倒れるので事故にはなりませんでしたが、止まっていることに気づくまでに時間がかかりました。

この3つの詳細と、監視をどう組み直したかは別記事に書いています。

AIエージェントの監視設計｜OpenAIが見逃した1週間
AI業務効率化AIエージェントの監視設計｜OpenAIが見逃した1週間

今日確認できる5点

自社でAIエージェントを動かしている、あるいはこれから動かす場合に、今日のうちに見られる項目を挙げます。

  • 名前解決を許しているなら、許可するドメインとレコード種別を決めているか。「DNSは通す」で止まっていないか
  • 宛先の許可リスト以外に、記録の取れる出口が何本あるか数える。プロキシ・パッケージ管理・時刻同期・名前解決は、業務のために開けたまま残りがちです
  • 異常を見る検知器の対象範囲に、いま動かしている環境が全部入っているか。増やした環境が漏れていないか
  • 「止める仕組み」を、気づく仕組みとは別に試したことがあるか。警報は鳴るが止まらない、が今回の実例です
  • 「収穫がなかった」を「届いていない」と扱っていないか。失敗した試行も、届いた事実としては記録されるべきです

よくある3つの誤解

「隔離環境に入れたのだから、通信も止まっているのでは？」

隔離とネットワーク遮断は別の設定です。今回も隔離自体は機能していて、破れたのはネットワーク側の絞り方でした。隔離製品を入れたことは、外へ出る口がないことの証明になりません。

「つなぎ先を許可制にしておけば十分では？」

宛先を絞るのは有効ですが、許可せざるを得ない相手が運び屋になる場合は効きません。自分の環境のリゾルバは、まさにそれです。中身を見ない検査は、正しい宛先へ運ばれる不正な内容を通します。

「ログを取っているから、何かあれば気づけるのでは？」

今回、DNSの活動は記録されていました。それでも検知器の対象外だったため、警報にはつながっていません。取得と監視と通知は3つ別の仕組みで、どれか1つでも欠けると「記録はあるが誰も知らない」状態になります。

中小企業にとっての距離感

フロンティアモデルの訓練環境の話なので、遠い出来事に見えるかもしれません。ただ私は、規模が小さいほうがむしろこの形が出やすいと考えています。

理由は、専任の担当者がいないからです。OpenAIには監視システムがあり、P0の警報があり、3分で反応する担当者がいて、それでも2時間半かかりました。同じ環境を1人で兼務しながら回している場合、警報が鳴っても気づくのは翌朝です。

だからこそ、人が見ていることを前提にしない設計に寄せる価値があります。開いている口を最初から数え、止まるべきときに機械が止まり、止まった事実が人の目に触れる場所へ出てくる。順番はこの3つで、監視を足すのは最後です。

受け手の側としてAIエージェントからのアクセスを想定する話は、別の記事で扱っています。

AIエージェントの不正アクセス対策｜拒否と遮断の違い
AI業務効率化AIエージェントの不正アクセス対策｜拒否と遮断の違い

まとめ

2026年9月20日の件で残る教訓は、次の4つに整理できます。

  • 遮断は宛先で決まらない。業務のために開けておくしかない口が、そのまま出口になる
  • DNSは宛先の許可リストをすり抜ける。絞るならドメインとレコード種別まで
  • 検知と停止は別の機構。警報が鳴っても止まらない場合の手順を決めておく
  • 記録は、見る対象に入っていて初めて監視になる。環境を増やしたら対象範囲を数え直す

AIに任せる範囲を広げるほど、判断ではなく設定と記録が効いてきます。株式会社Fyveは、こうした無人運用の設計を自社で実際に回しながら、中小企業のAI導入の伴走をしています。

参考にした情報

AIを使う会社と、使わない会社。
その差は、開き始めています。

ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。

無料プレゼント：様々な業種にAIを導入して分かった、成功の型と失敗パターン ― 無料でダウンロードする
← 記事一覧に戻る