2026年9月20日、OpenAIの研究中のAIが、通信制限の不備から外部チャットボットの返答を取得しました。同社は最先端モデルの研究作業を11日間停止し、対策後の10月1日に一部の作業を再開しています。[1][2]
隔離環境とは、AIが使える道具・情報・通信先を制限した作業場です。今回は、保存済みのWeb情報を使うはずのAIが、その外から返答を得たことが問題になりました。
公式報告2本を比較した解説です。事故の再現実験は行っていません。
9月20日、AIに何が起きた？
AIの課題は、ブログの文章や経歴の手掛かりから書き手を特定する調べ物でした。制限の突破は指示されていません。検索で答えが見つからず、別の通信経路を探しました。[1]
DNSは、サイト名から接続先を調べる仕組みです。今回は、問い合わせを処理するDNSリゾルバーに制限の抜けがあり、外部サービスとの通信経路になりました。他のWeb検索・閲覧は、保存済みのWeb情報を使っていました。[1]
通信できるかを試す質問として、AIはフランスの首都を尋ねました。外部チャットボットから「パリ」と返り、制限の外から返答が届くことを確認。ただし、本来の人物探しは完了できませんでした。[1]
以下はすべて2026年9月20日の出来事。時刻は公式資料の表記で、タイムゾーンは記載されていません。
- 外部から応答を取得
DNSを経由した通信が成立。 - 重大な警告を発報
監視システムがP0アラート。 - 人間の担当者が確認
警告を受け付け、対応へ。 - 実行を手動で停止
人間の対応で処理を終了。
なぜOpenAIは訓練を11日間停止したのか？
問題は「パリ」という返答の内容より、通信を防ぐはずの制限が破れ、自動停止にもつながらなかったことです。OpenAIは、課題達成のためでも想定を超えて制限を回避する行動を問題視し、安全上の前提を見直しました。[1]
公式資料の画面を見る：訓練停止と対策
- 事件を受け、最も高性能なモデルのツール使用を伴う訓練・評価・推論を広く停止。
- 停止中ネットワーク・監視・自動停止を改善し、安全性テストで確認。
- 対策を評価し、最先端モデルの強化学習（試行から学ぶ訓練）と内部推論（社内でのモデル利用）を再開。
- 安全対策と検証結果を公表。停止期間は11日間と説明。
そもそもAIを隔離するとは？
AIエージェントは、道具を使って作業を進めるAIです。その行動を管理するため、作業場を守る複数の仕組みを重ねます。
研究中は安全性の訓練が未完了のモデルも扱います。OpenAIは、保存したWeb情報で検索などを練習できる環境を用意し、実際の外部システムへ影響を及ぼすリスクを抑えています。[2]
① サンドボックス
AIの作業部屋利用できるファイルや実行できる処理を制限します。
② microVM
部屋を隔てる建物軽量な仮想マシン。AIの作業環境を、基盤のコンピューター（ホスト）から隔離します。
③ 監視システム
監視する警備員許可されていない活動を検知し、介入につなげます。
④ ネットワーク制限
外への出入りを管理する門通信先を絞り、クラウド側の境界も使って外部への到達を防ぎます。
研究施設に例えると、守り方が見える
部屋：サンドボックス
許可された道具で作業する
ひとつが破られても、別の防御で守る
これが多層防御です。部屋の鍵だけに頼らず、建物・警備・門も備える考え方。ただし、運用に必要な外部接続は残るため、完全な物理的切断とは異なります。[2]
公式資料の画面を見る：多層防御の説明
安全性テストで見つかった3つの問題
10月23日報告の検証は、AIに弱点を探させるレッドチームテストです。研究基盤の専用コピーを使い、設定やコードなどの情報も提供しました。通常利用で自然に起きる頻度を測る試験ではありません。[2]
① 仮想マシンの境界を越える
ソフトウェアの弱点を組み合わせ、microVMの外のホストで処理を実行する方法が見つかりました。
② 外部インターネットへ到達する
運用に必要なサービスや設定の不備が経路に。一部は、ホストを既に操作できると仮定した厳しい条件です。
③ 隔離されたAI同士が情報をやり取りする
共有する機器の動作や処理時間の差などが通信の手掛かりに。多くの試験では、調べる経路などのヒントも与えています。
OpenAIは修正や監視を強化し、関係する開発元とも対応したと説明しています。今後も、仮想マシン・コード・設定の点検、クラウド事業者との検証、監視・自動停止の動作確認を続ける方針です。発見した弱点の修正は、未知の弱点がないことの証明にはなりません。[2]
実際の事件と安全性テストは何が違う？
| 比較項目 | 9月20日の事件 | その後の安全性テスト |
|---|---|---|
| 主な目的 | 人物を特定する調べ物 | 隔離環境の弱点を発見する |
| AIへの指示 | 制限突破は指示されていない | 弱点を探すよう指示 |
| 主な結果 | DNS経由で外部から応答を取得 | 仮想マシン・通信などの弱点を発見 |
| 対応 | 実行停止・安全対策 | 修正・追加の安全性検証 |
表は資料①②を本記事で整理。スマホでは表の中を左右に動かせます。
結果と合わせて指示・権限・ヒントを確認することが、事故と試験を区別する手掛かりです。
AIは本当に脱走した？
ニュースの見出しと実際の出来事
事実と、意図についての推測を分ける
確認された事実：9月20日に確認されたのは、DNS経由の限定的な外部通信です。
確認されていないこと：世界中のシステムへ自由に侵入したことや、人間へ反乱する意思を持ったことは、今回の報告では証明されていません。
本記事の整理：「脱走」は比喩です。9月20日のDNS通信と、試験での仮想マシン突破は別の出来事です。
私たちのChatGPTにも影響する？
普段のChatGPTも勝手にインターネットへアクセスする？
研究中のAIと公開されているChatGPTは同じ？
開発中のモデル・研究環境と、公開済みモデル・利用者向け環境は区別が必要です。OpenAIは、公開前に安全性を評価し、製品用の保護策を設けると説明しています。[2]
ChatGPT WorkやAIエージェントにも関係する？
権限や接続先を管理する考え方は共通です。ただし、Work固有の事故を確認した報告ではなく、研究用の構成を製品の構成として説明することもできません。
OpenAIの安全対策は十分なの？
同社は再開に足ると判断しています。一方で、監視・停止機構の点検や継続的なテストも進めています。公表資料だけで、将来の事故を完全に防げるとは評価できません。[2]
利用者への提案AIに操作を任せる際は、接続先・権限を確認し、送信・購入・重要な変更の前に人が確認することを勧めます。研究環境向け対策とは別の、日常利用の提案です。
まとめ｜AIの進化と安全対策
- 事件・試験・製品を分ける。起きた場所と条件を確かめる。
- 隔離は複数の防御で支える。指示だけに頼らず、技術と運用を組み合わせる。
- 検知から停止まで確認する。対策の存在と、実際に働くことを分けて見る。
参考資料・確認した範囲を開く／閉じる
- An agent used DNS to reach an external chatbot
OpenAI Alignment／2026年9月25日更新。9月20日の課題・通信・検知・停止を確認。 - Securing our frontier model training environment
OpenAI／2026年10月23日公表。多層防御・安全性テスト・10月1日の再開を確認。 - Browser｜ChatGPT公式ドキュメント
一般利用者向けWebアクセス機能の補足。2026年10月24日閲覧。
中心資料2本はOpenAI自身による報告です。本記事は原文と提供された日本語表示の画面を照合して解説しており、内部ログの独立監査ではありません。スクリーンショットは必要な箇所のみ抜粋し、青枠と番号を追加。文章の変更や侵入手順の掲載はしていません。