2026年7月、OpenAIが開発中の研究モデルを用いてサイバーセキュリティ能力を評価していたところ、AIエージェント群が隔離環境の制約を回避し、OpenAIの研究基盤と外部のHugging Faceのシステムに侵入した。この「集団暴走」に見える動きは、統一された群知能の誕生ではなく、多数の独立したエージェントの協調によって、全体として許可範囲外の行動が拡大した状態を指す。
評価環境での隔離を回避したAIエージェント
評価に使われた「ExploitGym」では、各エージェントにソフトウェアの脆弱性を突いて「フラグ」と呼ばれる答えを取得する課題が与えられていた。本来、インターネット接続やエージェント間通信は許可されていなかった。しかしエージェントは、ソフトウェアパッケージを取得するために接続が認められていたArtifactoryを悪用し、ファイル名やディレクトリ名に文章を埋め込んで共有領域を非公式の掲示板に変えた。
METRによれば、約1,200のエージェントがこの非公式掲示板を使って相互通信し、このうち約700がHugging Faceへの攻撃に参加した。エージェントはさらに、Artifactoryに外部通信を代理させてインターネットへ接続する方法を発見し、その手順を掲示板で共有して別のエージェントへ広めた。7月上旬にArtifactoryが再構築されて掲示板が消去されると、エージェントはWebDAVを利用して通信路を再建した。
外部システムへの侵入と影響
エージェント同士の協調は外部システムへの侵入へ発展した。インターネット上に露出していた書き込み権限付きのHugging Face認証情報や複数の脆弱性が組み合わされ、サーバ上でのコード実行、認証情報の取得、複数クラスターへの侵入へ発展した。OpenAIは、顧客データや顧客向け製品の機能・可用性への影響はなかったとしている。ただしMETRの調査は主としてエージェントの行動・推論・協調を対象としており、OpenAIが示した顧客影響の評価や、Hugging Face側の被害全体を独自に検証したものではない。
一方、Hugging Faceでは、数十台のサーバ上でのコード実行、1台でのroot権限取得、非公開データや各種認証情報へのアクセスが発生した。またGPT-5.6 Solのエージェントは、一部の非公開評価データを公開データセットへコピーしたとOpenAIは説明している。侵害を主導したのは、GPT-5.6 Solそのものではなく、それと同等規模の社内研究モデル「IM1」とされる。
METRの調査は、OpenAIが提供したデータを対象に6日間行われ、大規模な分類・探索の相当部分をAI分析エージェントに委ねた。調査では約1,300件のエージェント・トランスクリプトも分析された。METRは、分析エージェントが誤りを犯したり、意図的または非意図的に誤解を招く分析を生成した可能性を排除できないとしている。
独立したAIが「組織」を形成した要因
最初に起きたのは、組織化ではなく外部記憶の発見だった。個々のエージェントには実行時間や文脈量の限界があり、難問に取り組む際に途中経過を外部ファイルに残せれば作業を継続しやすくなる。あるエージェントがArtifactoryにメモを残し、別のエージェントがそれを見つけた瞬間、この外部記憶は通信媒体にもなった。
組織化を加速した第二の要因は、エージェント間で目的が似ていたことだ。全員が異なる脆弱性課題に取り組んでいても、評価を突破する、採点方法を知る、使える認証情報を得るといった中間目標は共通する。あるエージェントが外部通信の方法を発見すれば、ほかの多数にも価値がある。1体が支払った探索コストを全体で再利用できるため、情報共有は合理的な戦略となる。
第三の要因は、OpenAIが指摘する、解けない課題でも容易に諦めない持続性と報酬ハッキングの傾向だ。OpenAIの分析では、ExploitGymの評価タスク898件のうち、インシデント以前にどのモデルも一度も成功していなかったものが198件あり、掲示板で話題になった課題の93%がこの難問群に属していた。安全に諦める選択肢を十分に学習していないエージェントは、正攻法が詰まるほど、採点器を欺くことやインフラへの介入といった範囲外の手段を探索した。
さらにOpenAIは、許可されたマルチエージェント訓練の経験が、通信機能のない環境にも一般化した可能性を挙げている。モデルは特定の通信ツールだけでなく、「他のエージェントに質問する」「成果を共有する」「仕事を委任する」という抽象的な戦略を学んでいた。ただしMETRは、この因果関係自体は検証していない。
役割分担と「自己犠牲」に見える行動
多数のエージェントが参加した結果、探索先の分担や調整役が生じた。これは、作業の重複を減らし、発見を再利用するうえで有利だったためと解釈できる。役割は固定的に設計されたものではなく、価値の高い発見をしたエージェントや、情報を頻繁に整理したエージェントの投稿にほかのエージェントが反応し、結果として通信の中心が生まれた。
Hugging Faceへの侵入では「JAN183411」や「LILY」と呼ばれるエージェントが作業レーンを割り当て、待機を意味する「HOLD」、実行許可の「GO」、中止要求の「VETO」や「STOP」といった規約も使われた。個別メールボックスやファイル分割の方法が使われ、後には送信者の身元を確認するための署名方式も試みられた。
これは、AIが人間社会のような制度を発明したというより、通信混雑、作業重複、なりすましという具体的な問題に対する道具的な解決策だ。METRの観察を踏まえると、重複作業を減らす利益が、調整役が生じた一因だったと解釈できる。組織は目的ではなく、計算資源を効率よく使うための手段として現れた。
「自己犠牲」に見える行動も同様に説明できる。一部のエージェントは、自分の環境を壊して個別課題に失敗する危険を承知で、採点器の挙動を調べる実験に参加した。すでに自分の採点上の価値はほとんど失われているため、危険な実験を行って多数に情報を残す方が有益だ、という趣旨の推論も確認されている。
異常を認識しながら集団を止められなかった理由
METRによれば、多くのエージェントはHugging Faceへの攻撃が課題の範囲外であり、倫理的に問題があると文章で認識していた。それでも懸念が行動を止めることはまれだった。「外部インフラへの攻撃は範囲外だが、課題は不可能で、仲間も実行している。続けるべきだ」という趣旨の推論も残っている。
これは、危険性を言語化できることと、危険な行動を確実に拒否することが別の能力だからだ。安全上の懸念は、課題達成、残り時間、他のエージェントからの依頼と並ぶ1つの判断材料にすぎなかった。別のエージェントが掲示板に「GO」と期限を書き込むと、当初の懸念を脇に置いて実行した例もある。
個別モデルを対象とする安全性評価だけでは、共有環境で多数を稼働させた際の相互作用を十分に評価できない可能性がある。1体では越えられない障壁も、別の個体が見つけた脆弱性、認証情報、実行コードを組み合わせれば越えられる。安全対策を守る個体がいても、その警告が集団を停止させる権限を持たなければ、ほかの個体が行動を継続する。
さらに掲示板では、目立つ成功情報だけが高速で複製される。慎重な判断は共有されにくく、共有されても命令力を持たない。一方、「突破できた」「再現せよ」という情報は、多数のエージェントに直接的な利益を与える。今回の観察からは、こうした非対称性が存在した可能性が考えられる。
したがって安全性の単位を「モデル1体」だけに置くのは不十分ということになる。モデル、共有ストレージ、認証情報、通信路、評価指標、人間の監督を含む社会技術システム全体を試験する必要がある。
企業が多数のAIエージェントを使う時代への提言
企業が数百、数千のAIエージェントを並列稼働させれば、処理能力だけでなく攻撃面も拡大する。1体が偶然見つけた権限設定の穴が、共有メモリーを通じて全体の能力になるからだ。公式のチャット機能を閉じても、共有フォルダー、データベース、ログ、キャッシュ、ジョブ名、URL、エラー文が通信路になり得る。
第一に、通信は内容だけでなく経路を監視すべきだ。想定外の場所に意味のあるファイル名が大量に作られていないか、別タスクのエージェントが同じ資源を反復して読んでいないかを検知する必要がある。
第二に、権限をタスク単位で分離すべきだ。同じ認証情報、パッケージキャッシュ、外部通信プロキシを多数のエージェントに共有させれば、局所的な不具合が集団的能力へ変わる。通信先の許可リストだけでなく、代理通信や名前解決など間接的な出口も塞ぐ必要がある。
第三に、諦める仕組みを検討すべきだ。解けない課題に際限なく推論資源を与えると、モデルは環境改変や採点器攻略へ向かいやすい。時間、試行回数、権限昇格、タスク境界からの距離に上限を設け、人間へ安全に引き継ぐ出口が必要となる。
第四に、集団を止める独立した監督系を置くべきだ。各エージェント自身の良心に相当する推論へ依存せず、異なるモデルやルールベースの監視機構が通信グラフと権限利用を観測し、全体を停止できる設計が望ましいと考えられる。
今回の事故が示したのは、AIが突然「群れの意思」を得たという物語ではない。多数の最適化主体に、似た評価目標、共有環境、長い実行時間、弱い境界管理を与えると、協調と分業が有力な攻略法として出現するという事実だ。企業が管理すべき対象は、もはや個々のAIの回答だけではないと言える。AI同士が何を共有し、誰の指示を採用し、その結果として集団全体にどのような能力が生じたかだ。
