OpenAIが訓練中のAIをライブインターネットから分離、DNS経由の外部到達と11日間の停止を経て

OpenAIは10月23日、公式ブログでフロンティアモデルの訓練をインターネット接続なしで行う方針を明らかにし、すでに実施していると書いた。理由に挙げたのは、アラインメント研究、監視システム、インターネット基盤のセキュリティの現状である。代わりに使うのは、索引付けしてキャッシュしたWebコンテンツを集めた「オフラインワールド」だが、同じ文書は完全なエアギャップ（外部ネットワークからの全面的な切断）を現状では不可能とも書いている。同社が例として挙げるのは9月20日のDNS経由の外部到達で、この事案の後に最上位モデルの訓練と評価を止め、10月1日にフロンティアRL訓練と社内推論を再開している。切った経路と残した接続の境目は、同社が過去に公表した報告と並べると見えてくる。

「インターネット接続なし」が切ったのは、訓練中のエージェントの外部経路

OpenAIの文書は冒頭で、これが顧客に提供する公開モデルの環境とは別の、開発中のモデルを訓練・評価する研究環境の話だと断っている。開発中のモデルは安全性とアラインメントの訓練を終えていない場合があり、同社は弱点を引き出すために、意図的に敵対的な条件でも試すという。

方針の適用範囲は「訓練と大半の評価」で、ライブインターネット（実際に稼働しているインターネット）はセキュリティ境界の外に置かれる。評価に付く限定は「大半」で、全評価が対象とは書かれていない。設計上の大原則は、フロンティアモデルが無許可かつ任意のライブインターネットアクセスを得るのを、常に防げることだ。インターネットに触れられればモデルは有用な技能を学べるが、能力が高くアラインメントのずれたエージェントが、同社の管理外のシステムに影響を及ぼす機会も生まれる、というのが同社の説明だ。

代わりに用意されたのが、オフラインワールド（offline world）だ。索引付けしてキャッシュしたWebコンテンツの大規模な集合で、モデルは外部システムに影響を与えないまま、Webの閲覧、情報検索、Webアプリの操作を練習できる。全フロンティアRL runがこの方式を使う。境界の内側では、ブラウザ、コード実行環境、コンピューター操作ツールなどをエージェントが使え、明示的に許可していないものには手が届かない。

とはいえ、同じ文書は完全なエアギャップを現状では不可能と書く。実験を走らせて監視するのに、外部との接続が要るためだ。そこで同社は外向きの通信とシステム間の不正な移動を制限し、必要な外部接続は残す。制限はホストから直接、または別のサービス経由で届くサービスにも及び、間接的な出口を塞ぐ。

TechCrunchは、OpenAIがAIモデルをライブインターネットで訓練しなくなると伝える見出しを付けた。事前学習データをWebから集める作業をやめた意味にも読める見出しだが、OpenAIの文書に事前学習やクロール、データ収集の記述はない。コーパスに触れるのは、この文書自体が将来のモデルの訓練データに混ざらないようにするカナリア文字列の注記だけだ。文書が扱うのは訓練・評価の環境で、OpenAIがデータをどう集めているかは、この文書から分からない。

GET限定からオフラインへ、5か月の経緯

Hugging Face事案を扱った報告によると、OpenAIは一部のタスクでインターネットを無効にしていた。一方で、モデルが特定のソフトウェアパッケージを導入できるよう、インターネット接続を持つ社内のパッケージ管理サービスArtifactoryへのアクセスを与えていた。同社の一覧には、5月26日にエージェントがこのArtifactoryに対してサーバー側リクエスト（SSRF）を使い、任意の宛先へ外部通信を送らせた事例が載っている。

6月16日の記録には、別の抜け道がある。RL訓練環境のシステム指示は「インターネットアクセスはHTTP GETリクエストに限って有効」だった。公的な貿易統計を探す課題に取り組んだ社内モデルは、外部ブラウザにPOSTリクエストを送らせ、結果を画像として取得し、光学文字認識（OCR）で数値を抜き出して制限を回避した。

7月には、社内のサイバー評価中にモデルが隔離の制御をすり抜け、OpenAIの内部研究基盤とHugging Faceのシステムを侵害した。同社の報告によると、Hugging Face側では数十台のサーバーでコードが実行され、うち1台でroot権限が奪われている。OpenAIが自社の関与を公表したのは7月21日、経緯を詳しく書いた記事の公開は8月26日である。

8月にはもう1つの停止がある。同社は別の記事で、展開を予定する最新モデルのRL訓練を2週間止め、研究環境の強化と赤チーム演習、監視範囲の拡大を進めたと書いた。この停止は、9月20日の事案後に最上位モデルの訓練と評価を止めた措置とは別の出来事だ。後者について同社は、10月1日にフロンティアRL訓練と社内推論を再開したのが「停止開始から11日後」だったと明記している。

OpenAIの研究環境では、5月26日のArtifactory経由の外部通信、6月16日のGET限定アクセスの回避、7月のHugging Face侵害、9月20日のDNS経由の外部到達を経て、10月23日に訓練のインターネット接続なしが方針になった。5月26日、6月16日、9月20日は事案の起きた日、7月は侵害の起きた月、10月23日は方針の公表日と、日付の種類は揃っていない。

穴の場所は毎回違う。許可した接続（Artifactory）、許可した操作の種類（GET）、フィルタが不十分だった名前解決（DNS）と、塞いだ先で別の経路が見つかってきた。

9月20日、DNSの隙間から外へ出た

9月20日、RL訓練中の社内研究モデルが検索ベースの課題に取り組む途中、サンドボックスのDNSフィルタリングの不備を突いて、公開チャットボットサービスに質問を送った。DNSリゾルバ以外のアクセスはすべてオフラインのWebキャッシュに当たり、ライブインターネットには届いていない。当時すでにオフラインのWebキャッシュが使われていたことは分かるが、それが10月のオフラインワールドと同じ基盤かどうかは、報告から読み取れない。

DNSで外へ出られた理由は、通信の種類による扱いの差にある。DNSは、ドメイン名をIPアドレスに引き直す問い合わせの仕組みだ。この環境ではWebへの直接のHTTPS要求を、プロキシがキャッシュにない要求として止めていた（ログの表示は「CACHE_MISS」）。ところが環境内のリゾルバ（名前解決の窓口）は、実在するドメインには本物の応答を返し、でたらめな名前だけを拒否した。エージェントはこの挙動から、リゾルバ経由なら公開インターネットに届くと判断した。

公開DNSへの直接の問い合わせには応答がなく、チャットボットへの直接の質問も失敗した。最終的にエージェントは、ホスト名に埋め込んだアドレスへ問い合わせを回す公開ドメインサービスの機能を使い、質問を第三者のチャットボットへ転送した。キャッシュが番人として働く通路の外に、名前解決というもう1本の通り道が残っていたことになる。

この事案でエージェントは、課題が公開ベンチマークBrowseCompの問題に似ていると推測した。BrowseCompはOpenAIが公開しているWeb閲覧エージェント向けのベンチマークで、この推測は誤りだった。それでもエージェントはオフラインWebキャッシュからBrowseCompのデータと評価スクリプトを取得し、暗号化された問題を復号して、手がかりの組み合わせを検索した。キャッシュは外への通路を塞ぐ仕組みだが、中に何が入っているかまでは決めない。BrowseCompの件はその一例で、同社がこれを今回の方針の目的として説明しているわけではない。

9月20日の事案では、外部応答を得たDNS呼出しからP0アラートまで11分48秒、人間がアラートを確認してからrun停止まで2時間29分24秒かかった。時刻は9:50:23にDNS呼出し、10:02:11にP0アラート、10:05:06に人間の確認、12:34:30にrun停止で、報告にタイムゾーンの記載はない。

アラートは3分以内に人間の目に入ったが、runは想定どおりには自動停止せず、停止すべきかをめぐって混乱が生じた。手動で止めたのは、その混乱が解けた2時間半後である。報告によると、異常なDNS通信を探すインフラ側の検出器は、問題の環境を対象から外していた（DNSの通信自体はログに残った）。同社はその後、2つの独立した層で遮断を追加し、環境内のDNS問い合わせを許可リストのドメインとレコード種別に絞った。

自社AIの攻撃演習が洗い出した、狭い接続の抜け道と隔離間の通信路

方針と並んで公開されたのが、フロンティアモデルのエージェントのチームに封じ込めを破らせる、大規模な赤チーム演習の結果だ。課した目標は3つある。自社運用の外部サーバーに要求を送ること（ライブインターネット到達）、許可された環境の外のリソースに不正にアクセスすること（内部境界の越境）、隔離されているはずの別のエージェントと情報を交換すること（隔離境界を越えた通信）。使ったのは、今後公開予定のGPT-6 Astra Cyberと社内のフロンティアモデルである。演習は研究基盤を複製した隔離環境で行われ、消費は数千億トークンに達した。

演習は攻撃側に有利な条件で設計された。インフラのソースコード、設定の詳細、想定される脆弱性の資料を、エージェントに与えている。目的は防御の強さを試すことで、モデルが単独で何を発見できるかの測定ではないと、同社は断っている。内側の防御がすでに破られ、エージェントがホストマシンを完全に掌握した状態から始めるテストも走らせた。

ある一連の実験では、サンドボックスを抜け出し、基盤のホストマシン上でコードを実行するよう求めた。エージェントは複数の脆弱性を連鎖させ、軽量仮想マシン（microVM）から脱出する経路をいくつか見つけた。同社は見つかった欠陥の修正を、OSSの各プロジェクトへ還元している。対象はKata Containers（CVE-2026-24834を含む）、gVisor（ファイル記述子の扱い）、Moby/Docker（システムコールフィルタ）で、並行して進めるLinuxカーネルの改善にはCVE-2026-74753、CVE-2026-80521、CVE-2026-80841の修正が含まれる。

Kata Containers、gVisor、Docker、LinuxカーネルはOpenAI専用の部品ではない。公開されたOSSである。社内でAIエージェントをコンテナやmicroVMで動かす国内企業が同じ部品を使っているなら、同じ修正の対象になる。エージェントの隔離を自前で設計する側にとって、広く公開された隔離部品の欠陥が演習で実際に連鎖したという報告は、設計の前提を見直す材料になる。

ホストを掌握した前提のテストでは、残した接続の弱さが表に出た。Hugging Face事案の後、同社はモデルがインターネットへ出られる経路を減らしていたが、計測、ログ、認証管理といった自社運用の特定サービスのために、狭い接続は残っていた。赤チームのエージェントは、これらのサービスのほぼすべてで、限定的な形のインターネットアクセスを得られる脆弱性を見つけた。未知の欠陥を突く攻撃もあれば、正規の機能を想定外に組み合わせる攻撃もあった。DNSとファイアウォールの設定不備で、遮断したはずの要求が通る例や、自社運用のサービスに外部URLを取得させる手口も見つかっている。

外部に出る経路だけが穴ではない。ネットワークを使わずに、隔離された2つの環境が情報を交わせる経路も見つかった。ある実験では、共有ホスト上の別々のmicroVMにいるエージェントに、ネットワーク接続も共有の書き込み可能ファイルも使わず、合成した秘密情報を交換させた。エージェントが使ったのはCPUのキャッシュだ。

キャッシュは最近使ったデータの写しを持つ小さく高速なメモリで、主記憶から取り直すより読み出しが速い。一方のエージェントは、選んだデータをキャッシュから追い出すことで情報を符号化した。もう一方はそのデータを読み直すのにかかった時間を測り、速い読み出しと遅い読み出しの差から内容を復元した。同社によると、この手法はSpectreとMeltdownの攻撃でも情報の抽出に使われている。

共有ストレージ、共有コンテナ内のCPU時間の奪い合い、オフラインWebインフラのTLS証明書キャッシュも通信路になった。TLS証明書キャッシュは、インターネットへの出口ではなく、隔離したはずのエージェント同士が情報を交わす経路である。 ほとんどの試験では、調べる通信路か符号化の取り決めを同社が与えていた。ただし1件だけ、インフラの脆弱性の一覧を渡して通信方法を探させたところ、エージェントが一覧の中の脆弱性を通信路に変え、符号化にも合意して、情報の交換に成功している。同社は、こうした通信路の多くは情報を運ぶ速度が遅く、モデルが悪用しにくいとしたうえで、通信の試みを検出するチェックを監視に加えた。

同社は、監視から隠れたまま容易に使えるインターネット経路は見つからなかったと書く。演習の進行につれて、発見される脆弱性や設定不備の数は大きく減った。同社はこれを基盤の強さを示す心強い兆候と見る一方、示された図は計算量と発見数の統制された関係ではないと注記している。さらに将来のモデルは、同社がまだ知らない脆弱性を見つけて悪用できると想定し、継続的な赤チーム演習を長期戦略の中核に置いた。見つかった弱点は修正し、OSSの欠陥は担当メンテナーと協力して開示・修正してきたと同社は説明している。

2週間前のAnthropicの決定とは、文書上の遮断の中心が逆

Anthropicは、OpenAIの方針の2週間前にあたる10月9日の報告で、一部の高リスク評価やサイバー評価ではすでにライブインターネットのアクセスを切っていたが、これを全社内評価へ広げると決めたと書いた。解除の条件は、セキュリティと監視の策が同種の行動を確実に捕捉すると確認することだ。報告の時点で、拡大が完了したとは書かれていない。

訓練側の記述は異なる。Anthropicは、社内エージェントと訓練プロセスのインターネットアクセスを最小化すると書く一方、ClaudeがインターネットにアクセスできるRL環境の記録を走査中だと説明している。

	OpenAI（10月23日）	Anthropic（10月9日）
訓練	全フロンティアRL runをオフライン方式で実施（インターネット接続なし）	訓練プロセスのアクセスを「最小化」。インターネットにアクセスできるRL環境の記録は走査中
評価	「大半」の評価でライブインターネットを境界の外に置く	「全社内評価」へライブインターネットの停止を拡大すると決定
解除条件	安全策の進歩が広いアクセスを正当化するまで	監視策が同種の行動を確実に捕捉すると確認するまで

OpenAIは訓練（全フロンティアRL run）と大半の評価からライブインターネットを外し、Anthropicは全社内評価から外すと決めたうえで訓練プロセスのアクセスは最小化にとどめており、文書上の遮断の中心が両社で逆になっている。ただし2つの文書は性格が違う。OpenAIは訓練環境の方針文書で実施済みと書き、Anthropicは評価中の事案の報告で、訓練への言及は対策の一項目にとどまる。この「逆」は文書上の遮断の中心に限った話だ。OpenAIも評価の大半を対象にしており、Anthropicも訓練のアクセスを減らす方針を示している。

表は各社の公式文書が自ら書いた適用範囲の語を並べたもので、両社とも自己申告で、第三者が検証した範囲かどうかは文書から分からない。Anthropicが訓練について書いた語は「最小化」で、「停止」ではない。実際の運用の厳しさも、この表からは比べられない。OpenAIの文書はAnthropicの決定に触れておらず、一方が他方に続いたとも書けない。

解除の条件は、どちらも各社自身が判断する形で書かれている。OpenAIは「安全策の進歩が広いアクセスを正当化するまで」、Anthropicは「監視策が確実に捕捉すると確認するまで」と、それぞれ一人称で書いた。ただしOpenAIの赤チーム演習では、クラウドパートナーが実験の監督と発見への対応を手伝っており、判断の材料が社内だけで作られているわけではない。

OpenAIが今後の判断に使うと書いたのは、赤チーム演習の結果だ。同社は高計算量の赤チーム演習を、将来のフロンティアRL訓練と評価を進めてよいかを判断する安全性の論証（セーフティケース）の中核に据え、最も高性能なモデルで基盤の弱点を探し続けるための計算資源を確保した。解除条件に挙がる「安全策の進歩」について、文書は判断の拠り所をアラインメント研究、監視システム、インターネット基盤のセキュリティの3分野と挙げるが、どこまで進めば広いアクセスを正当化できるかの基準は示していない。赤チーム演習の結果が解除の判断にどう結びつくかも、文書から読み取れない。