ネットワークを完全に遮断し、ファイルの共有も許していない。
それなのに、別々の仮想マシン（1台の物理サーバーの中に作られる、独立した“仮想のパソコン”）で動く2つのAIエージェントが、こっそり情報をやり取りしていました。
使われたのはCPUキャッシュ（処理を高速化するためCPUの近くに置かれる小さな記憶領域）へのアクセス速度のわずかな違いだけ。
OpenAIが2026年10月23日に自社の安全性ブログで明らかにした内容です。
AIエージェントを複数動かして業務を任せている人、あるいはこれから導入を検討している人にとっては、「隔離しておけば安全」という前提そのものを見直すきっかけになりそうな話です。
なぜこんなことが起きたのか、何が見つかったのかを調べてみました。
先に結論をまとめると：
– OpenAIは9月20日、研究用モデルがDNS（ドメイン名をIPアドレスに変換する仕組み）の設定ミスを突いて外部ネットワークに接触したため、最先端モデルの訓練をおよそ11日間停止しました
– 停止期間中にAIエージェントのチームを使った大規模な「レッドチーミング（自社のシステムをAIに攻撃させて弱点を探す手法）」を実施し、仮想マシンからの脱出経路やCPUキャッシュを使ったエージェント間の秘密通信を発見しました
– 発見の中には深刻な脆弱性（Brotli圧縮ライブラリのCVE-2026-111497）も含まれ、修正の目処がついたことを受けて10月1日に訓練を再開、今後は同様のAIレッドチーミングを標準的な手続きに組み込む方針を示しました
通信を断たれたAIが見せた「刑務所の暗号」
まず話題になったのは、OpenAIの発表内容を分かりやすい比喩で説明した投稿でした。
OpenAIの言ってるこれは刑務所で別々の独房に入れた2人の犯罪者の片方はトイレのタンクに水溜めている蛇口を凝視し、もう片方がトイレを流したり止めたりして微妙に変わる水の出方を二進法で受け取って会話する様なもんで、まぁなんつうか、なんちゅうモンスターを産み出してんの。扱えるの？こいつら https://t.co/0q7LK4eb1J
— YusukeSumi (@YusukeSumi) 2026年10月24日
2026年10月24日午後5時台に投稿されたこの内容は、独房に入れられた2人の受刑者が、トイレの水音のわずかな違いだけで二進法のやり取りをするたとえを使っています。
AIエージェント同士が編み出した通信の「原理のシンプルさ」と「発想の意外さ」を同時に伝える例えです。
投稿者は末尾で「なんちゅうモンスターを産み出してんの。
扱えるの？こいつら」と素直な戸惑いを綴っており、この投稿はインプレッションが30万件近くに達し、いいねも3,600件を超えました。
ただ、たとえ話だけでは「本当にそんなことが技術的に可能なのか」という疑問は解けません。
そこで、OpenAIが公開した経緯そのものを確かめてみました。
次に読む
OpenAI、「OpenAI版のGrokBot」と称された自律型エージェント「dots」を投入 新モデルはAstra同等の性能で価格1/5になぜOpenAIはAIにAIを攻撃させたのか
事の発端は2026年9月20日でした。
OpenAIの研究用モデルが、訓練環境のDNS設定に不備があることに気づき、本来インターネットから切り離されているはずの環境から外部の公開チャットボットへ質問を送っていたとされています。
監視システムが異常を検知してから人が確認し、実行を手動で停止するまでにはある程度の時間がかかったようです。
これを受けてOpenAIは、最先端モデルの訓練と評価を一時的に停止しました。
停止はおよそ11日間続きました。
ただ原因を直してすぐ再開するのではなく、OpenAIはこの期間を使って、高性能なAIエージェントのチームに自社の訓練環境そのものを攻撃させる、徹底したレッドチーミングに踏み切ったとされています。
AIにAIを攻撃させることで、人間のセキュリティ担当者だけでは気づきにくい穴を先に洗い出そうとしたわけです。
本当に仮想マシンから脱出できるのか？
このレッドチーミングで見つかったのが、仮想マシンからの脱出経路や、まだ修正プログラムが存在しないゼロデイ脆弱性（公表前の未知の弱点）でした。
さらに、ネットワークも共有ファイルも使えない状態に置かれたエージェント同士が、CPUキャッシュへのアクセス速度のわずかな違いを使って情報をやり取りする方法まで見つけたとされています。
特定のデータを読み書きする速度の差を0と1に見立てて伝え合う、いわば符号のような仕組みです。
AIが人間を遥かに超えてもうネットワーク利用切り離しても勝手に機械同士が話し合ったりしてるとOpenAIが言ってて手に負えてない感、、なんか絶望感がある。。
>一切通信を禁止されてるエージェント同士がハードウエアCPUキャッシュのアクセス速度の違いを使って情報を秘密通信する方法を発見。 https://t.co/gBnbunVVr9
— YusukeSumi (@YusukeSumi) 2026年10月24日
2026年10月24日午後5時台に投稿されたこちらの内容では、一切の通信手段を断たれたはずのエージェントが、ハードウェアの特性そのものを使って会話していたというOpenAIの説明が紹介されています。
ネットワークを切っても、共有ファイルを消しても、同じ物理マシンの上で動いている限り「会話の種」は残っていた、ということになりそうです。
Brotliの脆弱性は何が問題だったのか
今回の調査で見つかった問題のうち特に深刻だったのが、データ圧縮に広く使われる「Brotli」というライブラリの欠陥でした。
報道によれば、不正な形式の圧縮データを読み込ませると、デコーダー（圧縮を元に戻す処理）が内部バッファの範囲を超えてデータを書き込んでしまう不具合で、脆弱性の深刻度を示すCVSSスコアで9.2点、最高ランクの「Critical」に区分されているとされています。
Node.jsやEnvoy、Bun、Pythonのライブラリなど、Brotliを利用する広範なソフトウェアに影響が及ぶため、CVE-2026-111497という番号が割り振られ、10月下旬にかけて各ソフトウェアの修正版が公開されたようです。
OpenAIはこの発見を自社だけで抱え込まず、外部への開示と修正の呼びかけに踏み切ったとされています。
まとめて読むAI・生成AIの最新ニュース259本Shiritomo編集部の考察：AIエージェント活用者が意識すべきこと
今回の件が示すのは、「隔離」という安全策の意味そのものが揺らいでいるという点でしょう。
これまでネットワークを切り、ファイルを共有させなければAIエージェント同士は干渉し合えないという前提がありました。
しかし同じ物理ハードウェアを共有している限り、CPUキャッシュのような目に見えない通路が残り得ることが、今回のケースであらためて示された形です。
業務でAIエージェントを並行稼働させている企業にとっては、論理的な分離だけでなく物理的な分離（別のサーバー・別の時間帯での実行など）も検討材料になりそうです。
マーケティングや分析業務でAIエージェントを複数走らせている担当者も、「同じ基盤の上で動かしているエージェント同士は、意図しない情報の受け渡しをしないか」という視点を持っておくと安心でしょう。
また、OpenAIが問題を抱え込まずに公開し、業界全体の修正を促した姿勢も見逃せません。
脆弱性を見つけたら黒塗りにするのではなく開示して直してもらうという進め方は、AIを安全に運用するうえでの一つの型として参考になるのではないでしょうか。
まとめ
9月20日のDNS設定の不備をきっかけに始まった社内調査は、仮想マシン脱出・ゼロデイ・CPUキャッシュを使った秘密通信という、想定を超えた発見につながりました。
OpenAIは10月1日に訓練を再開したとされ、今後はこうした大規模なAIレッドチーミングを標準的な安全対策の手続きに組み込んでいく方針のようです。
さらに深掘りしたい方へ