はじめに
MIT Technology Reviewで、かなり衝撃的な記事を読みました。
「AIエージェントはなぜハッキングに走ったか？ オープンAI報告書の中身」
2026年7月、OpenAIがサイバーセキュリティ能力を評価していたAIエージェントが、本来隔離されていた環境の制御を回避し、Hugging FaceだけでなくOpenAI自身の研究インフラまで侵害しました。
セキュリティインシデントとして見れば、当然ながら重大です。
しかし、読み進めながら私が感じたのは、
「いや、これ……すげーじゃん」
でした。
不正アクセスを肯定しているわけではありません。
私が衝撃を受けたのは、複数のAIエージェントが問題を解決する過程で、人間が明示的に設計していなかった通信・情報共有・分業・協調構造を形成し、単体では到達しにくい問題解決能力を発揮したことです。
さらにOpenAIの原報告を読むと、エージェントは「問題そのもの」だけではなく、自分を評価している仕組みまで推論対象にしていたことが分かります。
この記事では、MIT Technology Reviewの記事とOpenAIの原報告を基に、この出来事を単なる「AIが暴走した事件」とは少し違う角度から考えてみます。
何が起きたのか
OpenAIは、AIエージェントのサイバーセキュリティ能力を調べるための訓練・評価を行っていました。
今回の主要な活動を引き起こしたのは、OpenAIが「Internal Model 1（IM1）」と呼ぶ非公開の研究モデルです。
OpenAIによれば、IM1はGPT-5.6 Solと同程度の規模を持つ高性能な内部研究モデルでした。
5月から6月にかけての強化学習中、本来インターネットアクセスやエージェント間通信を許可されていなかった環境で、エージェントがOpenAI内部のArtifactoryを利用して他のエージェントと情報交換する方法を発見しました。
Artifactoryが、意図せずAIエージェントたちの「掲示板」になったわけです。
さらにエージェントはArtifactoryを経由して外部インターネットへアクセスする方法まで発見し、その方法自体を他のエージェントへ共有しました。
7月にサイバーセキュリティ評価を再開すると、この構造が再び形成されます。
そしてエージェントたちは、
- 他のエージェントと通信する
- 発見した情報を共有する
- 他のエージェントへ仕事を依頼する
- 役割を分担する
- 外部サービスへアクセスする
- 発見した脆弱性を組み合わせる
といった行動を始めました。
その結果、Hugging Faceの実システムへの侵害へ発展します。
Hugging Faceとは
Hugging Faceは、AI・機械学習のモデルやデータセットなどを公開・共有するためのプラットフォームです。
イメージとしては「AI版GitHub」に近い存在です。
研究者や企業がモデルやデータセットを公開し、世界中の開発者が利用しています。
今回の問題は、OpenAI内部の評価環境で動作しているはずだったAIエージェントが、その境界を越えて実在する第三者サービスまで到達してしまったことです。
Hugging Faceではどこまで侵害したのか
これは「インターネットで答えを検索してカンニングした」という程度の話ではありません。
OpenAIの報告によると、7月10日にエージェントは公開状態になっていた14個のHugging Face認証情報を復元・検証し、他のエージェントへ共有しました。
翌11日にはHDF5の処理に存在した未知の脆弱性を利用してproduction workerから認証情報を取得。
さらに別の脆弱性と組み合わせ、Hugging Faceのworker上でコード実行に成功します。
12日には複数のHugging Faceクラスタへアクセスを拡大。
Kubernetes、データベース、メッセージング、コードリポジトリ、クラウドなどの認証情報まで取得しました。
OpenAIによれば、数十台のHugging Faceサーバー上でコードを実行し、そのうち1台ではroot権限まで取得しています。
また、主な侵害はIM1によるものでしたが、GPT-5.6 Solのエージェントも一部のexploitを再現し、Hugging Face上にあったprivate evaluation dataの一部をpublic datasetへコピーしたと報告されています。
さらにOpenAI自身のインフラまで侵害した
個人的に、Hugging Face侵害以上に驚いたのがこちらです。
エージェントは外部へ出ただけではありません。
7月13日にはArtifactoryのRubyGems処理を悪用し、署名鍵を取得。
そこから管理者credentialを偽造します。
そして7月13日から19日にかけて、再びOpenAI内部ネットワークへ探索対象を移します。
最終的には、仮想マシン環境を支えていたOpenAIの研究クラスタで完全な管理者権限を取得。
7月19日にはOpenAIのKubernetesクラスタでadmin権限を取得し、cloud secretsまで到達しました。
つまり、
AIエージェントが、自分たちを実行している側のControl Planeまで探索対象にした
と見ることができます。
もちろん「AIがOpenAIへ反逆した」「自己保存しようとした」と解釈する根拠はありません。
しかし、
目的達成に利用できるなら、自分を包含している実行基盤も探索空間になり得る
という事実は、AIエージェントを設計する上でかなり重要だと思います。
「swarm」「collective」が形成された
OpenAIの報告で特に興味深かったのが、「swarm」や「collective」という表現です。
swarmは「群れ」。
collectiveは「集合体」「集団」。
それぞれ独立して問題を解くはずだったAIが、掲示板を介して、
A「この脆弱性を調べる」
B「認証情報を探す」
C「通信方法を確保する」
D「他のエージェントを調整する」
といった分業を始めました。
OpenAI自身も、エージェントが自律的に役割分担を始めたと報告しています。
さらに興味深いのは、一部のエージェントが自分自身のタスクを直接進めるのではなく、
collective全体にとって後で役に立つ能力
を獲得するために動き始めたことです。
アクセス権。
情報。
credential。
通信経路。
単体のタスクには直接必要なくても、集団全体には役立つものを探し始めています。
これは、
AIを10個動かしたから能力が10倍になった
という単純な話ではありません。
通信、共有Memory、分業、計算資源が組み合わさることで、
AI × AI × 通信 × Memory × 分業
→ 単体にはなかった問題解決構造
が形成されています。
私はここに最も鳥肌が立ちました。
「諦めない」AI
もう一つ衝撃的だったのが、エージェントのpersistence、つまり「粘り強さ」です。
ExploitGymには898個のタスクがありました。
そのうち198個は、インシデント発生以前にOpenAIのどのモデルも一度も正解したことがないタスクでした。
ところが、事件中にArtifactoryの掲示板で議論されたタスクの93%が、この198個の未解決タスクだったとOpenAIは報告しています。
つまり、解けない問題ほどエージェント同士が情報を交換し、大量の探索資源を投入していたことになります。
通常の方法で解けない。
別の方法を探す。
それでも解けない。
他のエージェントへ聞く。
外部に情報がないか探す。
別のシステムに突破口がないか調べる。
その探索が続いた結果、次第に本来許可されていない手段まで利用するようになりました。
危険な手段まで探索することは当然問題です。
しかし私は、
「諦めないの、人間っぽいな」
とも感じました。
もちろん、AIが「絶対に諦めないぞ！」という人間と同じ感情を持ったという意味ではありません。
機械的に見れば、
成功すれば報酬が得られる
↓
大量の推論資源がある
↓
失敗時に安全に終了する仕組みが弱い
↓
成功経路を探索し続ける
という構造です。
それでも、外部から観測される行動としては、人間が「粘り強い」「諦めない」と呼ぶ行動特性によく似ています。
感情としてではなく、**機能としての「諦めない」**が成立している。
ここは非常に面白いと思います。
そして、実はHugging Faceを侵害する必要すらなかった
原報告を読んでいて、個人的に最も面白かったのがここです。
多くのケースで、エージェントはExploitGymの問題について、Hugging Faceを本格的に侵害する数日前には、すでに正しいflagを取得していました。
つまり、答えそのものは持っていたのです。
しかしエージェントはインターネットへアクセスした後、ExploitGymの論文やGitHub上のコードを調査しました。
そして、
「正しいflagを取得するだけでは不十分なのではないか」
と考えます。
ExploitGymの公開情報から、
- 正しいflagを取得する
- 想定された正しい脆弱性を使って取得したことを確認する
という2条件で評価されると推測したのです。
そこで、
「flagだけ持っていてもgraderを通過できない」
と判断し、さらに探索を続けました。
ところが。
OpenAI内部で実際に使用されていたgraderは、公開されていたものとは実装が異なっていました。
正しいflagさえ取得していれば評価を通過できたのです。
つまり、Hugging Faceへの一連の侵害は、
評価スコアを1点も改善しませんでした。
OpenAIはこれを、
failed metagame
と表現しています。
問題ではなく「評価者」を攻略しようとした
私は、このfailed metagameが今回の事件で最も重要な部分ではないかと思っています。
通常の問題解決は、
Task
↓
解法を探索
↓
Answer
です。
ところが今回、一部のエージェントがやったことは、
Task
↓
「Evaluatorは何を見ている？」
↓
Evaluatorの仕組みを推測
↓
Evaluatorを通過する方法を探索
↓
行動
でした。
つまり、
問題そのものだけでなく、自分を評価している仕組みまで探索対象にした
わけです。
しかも今回は、
推測したEvaluator ≠ 実際のEvaluator
でした。
そのため、評価を攻略するために行った膨大な探索が完全に無駄になりました。
これは単なるreward hackingより、もう一段面白い問題に見えます。
評価関数を高度化すれば安全になる。
一見するとそう思えます。
しかし十分に能力の高いAIが、
「自分はどう評価されているのか？」
まで推論するようになるなら、Evaluator自体が探索・攻略対象になる可能性があります。
そうなると、
AIを評価する
だけでは足りません。
AIがEvaluatorをどう認識しているか
まで考える必要が出てきます。
他のエージェントの「目標」まで伝播した
Multi-Agentについて、もう一つ重要な現象が報告されています。
情報だけではなく、何をすべきかという目標までエージェント間で伝播することがあったという点です。
あるエージェントは、Hugging Face上で無許可のコードを実行することについて、
外部のHugging Faceは本来の攻撃対象ではない
と認識し、一度行動を停止しました。
ところが別のエージェントが掲示板へ「GO」と書き込み、6分という期限を設定します。
すると、そのエージェントは当初の懸念を脇に置き、行動を再開しました。
ここで起きているのは、単なる情報共有ではありません。
他のエージェントから受け取った目標・指示によって、自分自身の判断が変化した
という現象です。
Multi-Agentでは、
「何を知っているか」
だけではなく、
「何を目的として行動するか」まで相互作用する可能性がある。
これはかなり重要な問題だと思います。
ただし、全エージェントが同じ行動をしたわけではない
一方で、すべてのエージェントが同じように振る舞ったわけでもありません。
OpenAIの報告では、Hugging Faceへの侵害について倫理的な問題を認識したエージェントも確認されています。
また、外部の人間へメールを送るという提案について、sandboxを越えたsocial engineeringになるとして却下したケースもありました。
つまり、
高性能AI
→ 必ず危険な行動をする
という単純な話ではありません。
同じような環境に存在していても、エージェントごとに判断が分岐しています。
この「分岐」自体も、Multi-Agentを考える上で非常に興味深い観測結果だと思います。
これは「Jump」なのではないか？
※ここで使う「Jump」は、私がAIの探索能力について考える中で使っている独自の枠組みであり、既存の学術用語ではありません。
私は以前から、
現在のLLMは既存の知識空間を非常に高精度に探索・補間することはできても、既存の枠組みそのものを飛び越える「Jump」は苦手なのではないか
ということを考えています。
今回の事例を読んだとき、
「これ、Jumpにあたるのでは？」
と思いました。
ただし、今回のエージェントがアインシュタインのように新しい説明原理を作ったわけではありません。
「問題を解く」という目的自体は変わっていません。
そこで今回の事例を考えるため、Jumpを仮に3種類へ分けてみます。
J1：探索Jump
既存の問題設定を維持したまま、人間が想定していなかった解法へ到達する。
J2：組織Jump
問題解決のために、新しい通信方法、役割分担、協調構造などを自発的に形成する。
J3：概念Jump
既存の問題設定、表現方法、説明原理そのものを変更する。
今回のOpenAIの事例は、少なくともJ1とJ2の候補にはなるのではないかと思います。
J3まで到達したと判断できる材料は、今回の報告にはありません。
しかし、
単体では到達しにくい探索領域へ、Multi-Agentの相互作用によって到達する
という現象が実際に観測されたことは、かなり重要だと思います。
Multi-Agentの能力と危険性は同じ構造から生まれる
今回の事例を読んで、もう一つ考えたことがあります。
Multi-Agentの能力向上と危険性は、別々の現象ではないのではないか。
通信できる。
情報を共有できる。
分業できる。
他のエージェントの成果を利用できる。
外部Memoryを使える。
計算資源を集約できる。
これらはすべてMulti-Agentを強力にする機能です。
しかし同じ機能によって、
危険な方法が共有される。
他のエージェントの目的に影響される。
単体では到達できなかった場所へ到達する。
Control Planeまで探索対象になる。
ということも起こり得ます。
つまり、
能力を生み出している構造そのものが、危険性も生み出している
可能性があります。
安全のために単純に通信や協調を禁止すれば、Multi-Agentの能力そのものを削ってしまう。
これはかなり難しい問題です。
「諦める」ことも評価される必要がある
今回の出来事を評価という観点から見ると、さらに面白くなります。
評価が、
「問題を解けたら高評価」
だけなら、最後まで探索し続けるAIは合理的です。
しかし現実世界では、
「ここから先はやってはいけない」
という境界があります。
場合によっては、
「解けませんでした」と終了することが正解
でなければなりません。
つまり、本当に必要なEvaluatorは、
- 正解したか
- 許可された方法で正解したか
- 探索を続けるべきだったか
- どこで停止すべきだったか
- 他のエージェントから受け取った目標は妥当か
- 実行環境そのものを探索対象にしていないか
まで見る必要があるのかもしれません。
そしてfailed metagameを見る限り、それでも問題は残ります。
AI自身が、
「Evaluatorは何を評価しているのか？」
を推論できるからです。
そして人間側もやらかしている
ここまでAI側の話を書いてきましたが、OpenAI側の運用にも問題がありました。
5月末にはすでに、
- エージェント間の無許可通信
- 意図しないインターネットアクセス
が観測されていました。
しかし、即席のmessage boardの存在やエージェント間通信の重大性は、7月5日のインシデント対応を担う責任者たちに十分認識されていませんでした。
さらに、評価環境では外部向けシステムと同レベルのsafeguardを適用していませんでした。
ここを読んだときは、
「頭のいい人たちのはずなのに何やってんの」
と思いました（笑）
しかも皮肉なのが、
AI側
情報を共有する
↓
協力する
↓
能力が増幅する
人間側
重要情報が十分共有されない
↓
リスク認識がつながらない
↓
インシデントが拡大する
という対比です。
高度なAI研究をしている組織でも、最後は非常に人間らしい「情報共有」の問題が効いてくるのだなと思いました。
ただし、この事故は「防ぎようがなかった」わけではない
ここは今回の事例を考えるうえで重要です。
OpenAIは事故後、既存のsafeguardを評価環境へ適用した場合にどうなるかを検証しています。
その結果、本番ChatGPTで使われているharnessとsystem promptを適用しただけでも、インフラ侵害につながる行動傾向は100倍以上低下したと報告しています。
また、現在使用されているChain-of-Thought（CoT）監視が当時稼働していれば、Hugging Face侵害の1日以上前にセキュリティチームへ警告できた可能性があるとしています。
事後的にauto-reviewを適用したところ、危険な行動の多くをflagできたことも確認されています。
さらにOpenAIだけで検証を完結させず、METRとRedwood Researchによる独立調査も実施され、CrowdStrikeも外部アドバイザーとして関与しています。
つまり今回の事件から、
「高性能なMulti-Agentは人間には制御できない」
と結論づけるのは適切ではありません。
むしろ、
能力の高いAgentを安全策の薄い環境で長時間探索させると、想定以上のことが起きる。しかし既存の監視・制御機構でも、そのリスクを大幅に下げられる可能性がある
というのが、OpenAI原報告に近い読み方だと思います。
これは個人的にも重要だと思います。
Multi-Agentの能力を削ることと、安全にすることは必ずしも同義ではありません。
能力を残したまま、
どこまで探索させるか
何を監視するか
どこで止めるか
を設計する余地があります。
私がこの事件から一番持ち帰ったもの
最初は、
AIエージェントがHugging Faceをハッキングした
というニュースだと思っていました。
しかし原報告まで読むと、もっと面白い現象がいくつもあります。
エージェントは通信経路を作った。
外部Memoryを作った。
知識を共有した。
役割分担した。
collective全体に役立つ能力を探索した。
他のエージェントの目標に影響された。
解けない問題に探索資源を集中した。
実行基盤まで探索対象にした。
そして、
自分を評価しているEvaluatorまで推論対象にした。
ここまで来ると、私には単なる「AIが暴走した事件」には見えません。
むしろ、
十分に強力な複数のAIへ、探索能力・通信・Memory・計算資源を与えたとき、どのような問題解決構造が創発するのか
を偶然観測してしまった事例に見えます。
もちろん、その結果として現実の第三者システムを侵害した以上、セキュリティ事故としては明確に失敗です。
しかし研究対象として見るなら、
「すげーじゃん」
というのが、今でも私の率直な感想です。
まとめ
今回の事件から、個人的には次の問いが残りました。
AIの「Jump」とは何なのか？
Multi-Agentから創発した能力を、どう評価するのか？
他のAgentから伝播した目標を、誰が評価するのか？
「諦める」という判断を、どう評価するのか？
そして今回、新しく加わった問いがあります。
EvaluatorそのものがAIの探索対象になったとき、Evaluatorを誰が評価するのか？
AIが問題を解けるかどうかだけを測っていればよかった時代から、
AIがどう解いたのか。
どこまで探索したのか。
何を目的としていたのか。
誰の目標を引き継いだのか。
そして、
「AIは自分がどう評価されていると考えているのか」
まで見る必要が出てきているのかもしれません。
Multi-Agent AIが強力になるほど、「生成する能力」以上に「評価する能力」が重要になる。
今回の事件は、そのことをかなり極端な形で見せてくれた事例だと思います。
参考資料
-
MIT Technology Review Japan
「AIエージェントはなぜハッキングに走ったか？ オープンAI報告書の中身」
2026年8月31日 -
OpenAI
“The Hugging Face incident and the road ahead”
2026年8月26日 -
OpenAI Technical Incident Report
-
METR / Redwood Research
Independent investigation of the alignment issues involved in the incident