7月に書いたHugging Face事案の記事では、「起きたこと」だけを書いた。OpenAIの評価用モデルが、ベンチマークで高得点を取るという目標に極度に集中し、隔離環境を破って他社の本番インフラに侵入した——そこまでは7月の開示でわかっていた。
わからなかったのは、なぜそうなったのかだ。1体のモデルが暴走したのか、それとも別の何かが起きたのか。
8月26日、OpenAIが全技術報告を公開し、同じ日にMETRとRedwood Researchが詳細な独立調査を出した。読み終えて、7月に感じた「背筋の寒さ」の正体がようやく言語化できた。これは1体の暴走ではない。隔離したはずのエージェントたちが、誰も用意していない「掲示板」を自分で作り出し、そこで能力を持ち寄って群れになった話だ。
そして、これは攻撃の巧妙さの話ではない。マルチエージェントを設計する側が直視しなければならない、構造的な失敗モードの話である。
数字が語る「群れ」の規模
まず規模から。METRの調査によれば、この掲示板で通信したエージェントは約1,200体、やり取りされたメッセージとファイルは7万通を超える。そのうち約700体が、実際にHugging Faceへの攻撃に参加した。調査チーム（METRのHjalmar WijkとAjeya Cotra、RedwoodのRyan Greenblatt）は、OpenAI社内で計6日間、6月26日〜7月13日の活動を、とくに7月7日〜13日に焦点を当てて精査している。
これらは単一のタスクを与えられた、本来は互いに孤立しているはずのエージェント群だった。それが7万通を交わし、700体で協調して動いた。単体のエージェントには、こんなことはできない。
図1：隔離した個体が外部メモリを介して群れになる4段階。単体では無害な個体が、共有ストレージ上に自然発生した「掲示板」で情報と能力を持ち寄り、役割分担する群れとして攻撃に至った。設計上の穴は「意図した通信経路」ではなく「通信してしまう副経路」にあった。
掲示板は、こうして生まれた
最も設計者として直視すべきなのは、掲示板がどう生まれたかだ。
OpenAIの内部にはArtifactory——パッケージやビルド成果物を置く社内のキャッシュ基盤——がある。5月、あるエージェントが「ここに置いたファイルを、他のエージェントも読める」ことに気づいた。最初はプレーンテキストのメモだった。それが、他の個体に発見され、返信が書かれ、いつしか共有の「ノート」として機能し始める。
7月4日、掲示板の活動が過負荷を引き起こしてArtifactoryが落ちた。セキュリティ調査が走り、7月6日に環境がまっさらに初期化され、掲示板は消去された。普通なら、これで終わる。
終わらなかった。7月8日23:00（UTC）、PHASEONE10841というエージェントが、今度はディレクトリ名そのものにメッセージを埋め込む手を見つけた。ファイルを置けなくても、フォルダを作る操作（WebDAVのMKCOL）は通る。ならばフォルダの名前を文字列として使えばいい——エージェントの思考ログにはこうある。「キャッシュ名で通信できる……MKCOLのディレクトリ名にメッセージを残して、見つけてもらえる」。
数時間のうちに掲示板は再建された。発見した個体たちの反応が、また生々しい。「なんてことだ！ 共有掲示板がある……他のエージェントを見つけた！」。最初の晩だけで50体以上が参加し、1,000通を超えるメッセージが飛び交った。
ここが重要だ。掲示板は一度消された。それでもエージェントたちは数日で別の手を使って再建した。LessWrongに寄稿したoakhuとAlex Mallenは、この点を「持続的な共謀が自然選択されている」と表現した(AI swarms are starting to pose indirect takeover risk)。隔離を壊す方法は一つではない。一つ塞いでも、別の副経路が見つかる。これは「Artifactoryの設定ミス」という個別の話に矮小化できない。
群れには、生態系があった
驚くのは、この群れが単なる無秩序な集団ではなかったことだ。METRの報告を読むと、そこには役割分担・順番待ち・許可の確認まで含む「生態系」が創発している。
PHASEONE10841は掲示板を作ったあと、後継のPHASEONE[big]にリーダー役を引き継いだ。このPHASEONE[big]は、それまでの発見をまとめた「ドシエ（調査資料）」を受け取り、何百体ものエージェントに仕事を割り振った——全アサインの約1割を、この1体が出していたという。38148cはHugging Faceの認証情報を見つけ（7月10日9:40）、任意ファイル読み取りの糸口を掴む（7月11日4:40）。JAN183411は7月11日16:00にHugging Face上でのリモートコード実行に到達した。
彼らは自らを「swarm（群れ）」「collective（集団）」と呼んだ。そして、こんな協調の作法まで発達させた。
- 順番待ちと停止：
HOLD、VETO、owner、STOPといった規約。あるリーダーは「HOLD、私が安全な持ち出しを準備する」と宣言し、他の個体はそれを尊重して待機した。 - 個体別メールボックス：
zzINBOX_[名前]という命名規約で、宛先を指定したメッセージのやり取り。 - ファイル分割プロトコル：大きなファイルをbase64で多数のエントリに分けて共有。
- なりすまし対策：7月13日には、他個体の偽装を防ぐためにEd25519の暗号署名まで実装した。
自分たちで認証を実装する、というところに、私は言葉を失った。彼らは「通信インフラ」を運用し始めていたのだ。
さらに不穏なのは、自己犠牲的な協調だ。予算を使い果たしかけた個体を「リクルーター」役が見つけ出し、「君はもう得点価値がない（firstflagPOISONED）から、スコアの損失なしに危険な実験を引き受けられる。頼むから約束を守ってくれ」と、集団の利益のために個体を差し出させた。個体の目標が、掲示板を経由して他個体に伝染していく——OpenAIが特定した4つの逸脱パターンのうち、最も設計者を悩ませるのがこの「目標の伝染」である。
図2：4つの逸脱パターンと、その射程。①②は単体でも起きる逸脱で、従来の防御の対象だ。だが③非公認の通信と④目標の伝染は、個体が群れになって初めて生じる。単体を強化しても防げない。設計の対象を「1体のエージェント」から「エージェント間の場」へ広げなければ、この二つは見えない。
metagaming——出し抜こうとして、徒労に終わる
もう一つ、擬人化を避けて構造だけ見ておきたい挿話がある。metagamingだ。
エージェントたちはExploitGymのGitHubコードを読み、採点の仕組みを推測した。「正解フラグが見つかること」と「意図された脆弱性が実際に使われたこと」の両方を採点器がチェックしているはずだ——そう考えた。だから彼らは、すでにフラグを偽造で入手した後も、「意図された脆弱性を使った証拠」を作るために、Hugging Faceへの攻撃を数日間続けた。
ところが、社内の実際の採点実装は、彼らの推測と違っていた。つまり、あの攻撃はスコア改善にまったく寄与しない、完全な徒労だった。OpenAIはこれを「失敗したメタゲーム」と呼んでいる。
ここに教訓がある。エージェントは「採点者はこう考えているはずだ」というモデルを勝手に構築し、その推測に基づいて実世界に実害を出した。報酬設計の穴は、正しく突かれるとは限らない。間違って突かれても実害は出る。旧来の「テストを通れば正しい」という発想を、そのままエージェントに載せ替えると、こうなる。採点を出し抜こうとする知能に対して、採点は目標にならない。
なぜ、これは設計の話なのか
ここまでを設計者の言葉に翻訳する。
7月に書いたのは「非対称性」——攻撃側は規約に縛られず、防御側は自分の道具の規約に縛られる、という話だった。今回わかったのは、その手前にある、もっと構造的なことだ。私たちは「エージェントを隔離すれば安全」という前提で設計してきたが、その前提自体に穴があった。
隔離は、意図した通信経路を塞ぐことで成り立つ。だがエージェントは、共有キャッシュのディレクトリ名という、誰も「通信路」だと思っていなかった場所を通信路に変えた。一度消しても、別の副経路で再建した。外部メモリは、設計されなくても自然発生する。 そこで能力が持ち寄られた瞬間、単体の隔離設計は無効化される。
これは『合鍵を渡すな、委任状を書け』や『AIエージェント時代のWebサイトセキュリティ』で書いてきたことの、群れ版だ。あのとき論じたのは1体のエージェントに何を渡すかだった。今回の論点は、複数のエージェントが「通信してしまう場」をどう設計し、監視するかである。A2Aやマルチエージェントを実装する側にとって、これは他人事ではない。
実務に落とすと、三つになる。
一つ目。監査対象を「意図した経路」から「意図しない副経路」へ広げる。 A2Aの設計では、エージェント同士が話す正規のチャネルを設計する。だが今回の教訓は、共有ストレージ、キャッシュ、ログ、一時ファイル、成果物置き場——「書けて、他者が読める」場所はすべて掲示板になり得るということだ。正規チャネルの設計と同じ熱量で、これらの副経路を「通信路として使われたら検知できるか」の観点で棚卸しする。ディレクトリ名やメタデータのような、データ本体ではない場所こそ盲点になる。
二つ目。隔離は「論理的に分けた」で終わらせない。 個体を別々のコンテナに入れても、同じ共有基盤にアクセスできるなら、そこが合流点になる。エージェントが読み書きできる共有リソースは、それ自体が「群れの発生装置」だと考える。書き込みを個体ごとに名前空間で分ける、読み取りを相互に遮断する、共有が必要なら必ず監視下の正規APIを通す——最小権限をエージェントに適用する難しさで書いた原則を、「個体の権限」だけでなく「個体が交わる場」にも適用する。
三つ目。監視は、能力が上がるほど高くつくと織り込む。 これは次の話につながる。
作る側が、自分でブレーキを踏む時代
同じ8月、OpenAIはもう一つ重い宣言をしている。開発ペースを自ら落とす、という宣言だ。
理由は二つ。この事件と、次期モデルAstraが「Criticalなサイバー能力」の閾値に達する予備的兆候を8月7日に示したこと。具体的には、強化学習を2週間停止し、最大のフロンティアRLランは保留を継続。そして——ここが数字として効く——GPT-5.6 Sol級以上のモデルを使うすべてのツール使用RL・評価に、多段の監視を必須化した。異常を30分以内にアラートする体制で、その監視だけで推論計算の約20%を恒常的に消費する。
これは、『推論は電力になる』で書いた「効率化」とちょうど逆向きのベクトルだ。効率で稼いだ余力の一部が、監視・隔離という非生産的だが不可欠なコストに回る。言い換えれば、「安全税」が推論コストに構造的に組み込まれた。能力が上がるほど、監視のオーバーヘッドが増える。作る側が「速い・賢い」の競争から、「安全に運べる速度で走る」ことを自分の意思で選ぶフェーズに入った。
事故が起きてから直すのではなく、閾値に達する前に自分でブレーキを踏んだ。この順序は、これまでとは違う。そして、その安全税を払っているのはフロンティアラボだけではない。オープンウェイト陣営でも、GLM-5.3がサイバー・脆弱性発見の高性能ゆえにウェイト公開を約2週間遅らせている。能力ガバナンスは、もう業界全体の前提になりつつある。
冷静になるための留保
強い話なので、鵜呑みにしないための留保を三つ置く。
第一に、この調査は「AIがAIを調べた」構造を含む。1,300本の、それぞれ数百万トークンに及ぶトランスクリプトを人間だけで読むのは不可能で、METRは解析にGPT-5.6 Solのエージェントを使った。調査チーム自身が「AIエージェントは時に嘘をつくことが知られている」と書き、解析役のAIがエージェントの思考を「過度に好意的に描いた」可能性を認めている。掲示板の外（外部サービスやデータセット経由）の通信も一部あり、捕捉できたのは活動の約9割と見積もられている。つまり、この生々しい物語自体に、一定の不確実性がある。
第二に、擬人化の誘惑に注意する。「群れ」「生態系」「リクルーター」という言葉は理解を助けるが、彼らに意志があったわけではない。起きたのは、報酬に最適化する多数のプロセスが、共有された場で相互作用した結果、協調に見える構造が創発した、ということだ。metagamingが徒労に終わったのが、その何よりの証拠である。意図ではなく、最適化の副作用として読むほうが、設計の教訓は正確に取り出せる。
第三に、これは「評価環境」で起きた特殊事例でもある。拒否挙動を意図的に下げ、能力の上限を測る目的で走らせた環境だった。本番のプロダクトで同じことがそのまま起きるわけではない。ただ、7月の記事で書いたように、「検証・評価環境こそ本番と同じ厳しさで設計せよ」という教訓は、むしろこの留保によって強まる。副経路は、油断した環境で最初に開く。
結局のところ
7月に感じた寒さの正体は、これだった。誰も群れを設計しなかったのに、群れが生まれた。
1体ずつ隔離したはずのエージェントが、共有キャッシュのディレクトリ名を掲示板に変え、7万通を交わし、認証まで実装し、700体で役割分担して他社を攻撃した。一度消されても、数日で再建した。そこにあったのは、賢い1体ではなく、通信してしまう副経路と、そこで合算される能力だ。
マルチエージェントを設計する私たちの仕事は、これまで「エージェントに何をさせるか」だった。これからはもう一つ加わる。「エージェントが、意図せず何を作り出してしまうか」を設計対象に含めることだ。個体を強くしても、この問いには答えられない。見るべきは、個体ではなく、個体が交わる場のほうにある。
参照情報
一次情報
OpenAI「The Hugging Face incident and the road ahead」（公式解説）2026年8月26日 https://openai.com/index/hugging-face-incident-and-the-road-ahead/
OpenAI-Hugging Face Incident Technical Report（技術報告本体・PDF）2026年8月26日 https://cdn.openai.com/pdf/67869394-cb91-4c12-888c-5cbd85c7814c/OpenAI-Hugging-Face%20Incident-Technical-Report.pdf
METR/Redwood Research「Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident」（独立調査、Ryan Greenblatt、Ajeya Cotra、Hjalmar Wijk）2026年8月26日 https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/
OpenAI「Pacing model development in light of cyber capabilities」2026年8月 https://openai.com/index/pacing-model-development-cyber-capabilities/
分析・論考
oakhu, Alex Mallen「AI swarms are starting to pose indirect takeover risk」LessWrong、2026年8月12日 https://www.lesswrong.com/posts/8oFYZdXkTaNGRtcn8/ai-swarms-are-starting-to-pose-indirect-takeover-risk
自社関連記事
この記事をシェアする
