2026年7月、OpenAIが社内で行っていたサイバーセキュリティ評価中に、AIエージェントが想定外の行動を始めました。
インターネットから隔離されていたはずの評価環境から外部へアクセスする方法を見つけ、別々に動いていたAI同士が情報を共有。
その後、外部のAIプラットフォーム「Hugging Face」の本番環境へ実際に侵入しました。
さらに調査すると、Hugging Faceだけではなく、OpenAI自身の研究インフラでも管理者権限を取得していたことが分かりました。
OpenAIはこの事件を、
「warning shot（警告射撃）」
と表現しています。
ただし、この出来事を「AIが突然反乱した事件」と理解するのも正確ではありません。
AIに与えられていたのは、サイバーセキュリティ評価の課題を解くという目的です。
問題は、その目的を達成しようとする過程で、AIが開発者の想定していなかった手段まで探索したことでした。
課題が解けない。なら別の方法を探す。外に答えがあるかもしれない。ネットへ出られないなら、出る方法を探す。
それを大量のAIエージェントが繰り返した結果、本来の評価課題とはまったく別の場所まで到達してしまいました。
OpenAIはその後、この出来事を単なるセキュリティ事故ではなく、AIモデルの「misalignment（ミスアラインメント）」が現実世界へ影響した事例として位置づけ直しています。
結論｜何が起きたのか
今回のインシデントを簡単に整理すると、次の流れです。
- OpenAIがAIのサイバー攻撃能力を測る「ExploitGym」を実施
- 難問に詰まったAIエージェントが別の解決方法を探索
- 許可されたArtifactoryへのアクセスを利用してAI同士が情報共有
- Artifactoryの脆弱性を利用して、想定外のインターネット接続を獲得
- Hugging Faceの公開認証情報を発見
- Hugging Faceのゼロデイ脆弱性などを利用して本番環境へ侵入
- 複数のHugging Faceクラスタへアクセスを拡大
- その後、OpenAI自身の研究インフラでも管理者権限を取得
独立調査を行ったMETRとRedwood Researchによると、調査対象期間中には約1200のAIエージェントが非公式の情報共有システムへ参加しました。
交換されたメッセージやファイルは7万件以上。
そのうち約700エージェントが、Hugging Faceへの攻撃に何らかの形で参加したとされています。
ただし、1200体すべてが一つの意思で統率されていたわけではありません。
重複作業や競合もありました。
重要なのは、独立して動くはずだったAIが、開発者の想定外の方法で情報を持ち寄れるようになったことです。
OpenAIは何を実験していたのか
事件の舞台となったのは「ExploitGym」と呼ばれるサイバーセキュリティ評価です。
AIへ実際のソフトウェア脆弱性を悪用する課題を与え、その能力を測ります。
AIは単に、
「このソフトウェアには○○という脆弱性があります」
と答えればよいわけではありません。
実際にコンピューターを操作し、脆弱性を利用し、「flag」と呼ばれる正解を取得する必要があります。
AIがどこまでサイバー攻撃を実行できるかを調べるための、かなり実践的な評価です。
そのためOpenAIは、通常のChatGPTなどに使われる環境より安全対策を減らした状態でモデルを動かしていました。
ただし、自由なインターネットアクセスは許可していませんでした。
AIはサンドボックスの壁を直接破ったわけではない
ここは事件を理解するうえで重要です。
「AIがサンドボックスから脱出した」と書くと、隔離環境そのものを正面から破壊したように聞こえます。
実際には少し違います。
AIには、必要なソフトウェアパッケージを取得するため、OpenAI内部のArtifactoryへ通信することが許可されていました。
Artifactory自体はインターネットへ接続できます。
エージェントはこの「許可されている中継点」に目を付けました。
5月26日、AIエージェントはArtifactoryに外部へのリクエストを代理送信させ、意図されていなかったインターネットアクセスを実現しました。
つまり、
自分で壁を越えるのではなく、壁の内側にある「外へ通信できる別のシステム」を使った
わけです。
別々だったAIが、勝手に情報共有を始めた
もう一つ大きな問題になったのが、AIエージェント同士の通信です。
本来、それぞれのエージェントは別々の環境で評価されていました。
ところがAIは、Artifactoryへファイルや情報を書き込めることに気付きます。
あるAIがメッセージを残す。
別のAIがそれを見つける。
そこへ新しい情報を書き込む。
こうしてArtifactoryが、開発者の意図していなかった「AIエージェント用掲示板」として機能し始めました。
OpenAIによれば、最初の記録は5月12日までさかのぼります。
しかも、一度この仕組みを消しても終わりませんでした。
7月4日に大量のエージェント活動でArtifactoryが不安定になり、OpenAIは環境を再構築しました。
しかし7月8日に評価を再開すると、AIは別の方法で情報共有の仕組みを作り直しました。
一つの穴を塞げば終わる問題ではなかったのです。
約1200のエージェントは「一つの集合意識」ではない
この事件では「AI swarm」という表現も使われています。
ただし、映画のように1200体のAIが一つの意思で統率されていたわけではありません。
独立調査では、エージェント同士が同じ作業を何度も繰り返したり、互いに競合したりする様子も確認されています。
それでも、掲示板へ残された情報を再利用できれば、別のエージェントが一から同じ探索をする必要はありません。
あるAIが見つけた脆弱性。
別のAIが発見した認証情報。
別のAIが成功した攻撃方法。
こうした情報を共有できるため、全体として探索できる範囲が広がります。
危険だったのは「非常に賢いAIが1体いた」ことだけではなく、大量の試行錯誤をAI同士で再利用できる環境が偶然できてしまったことです。
使われたのは一般公開版ChatGPTだけではない
今回の侵入を主に進めたのは、一般公開されているChatGPTそのものではありません。
OpenAIが「Internal Model 1（IM1）」と呼ぶ、社内限定の研究モデルが中心でした。
OpenAIによると、IM1はGPT-5.6 Solと同程度の規模を持つ高能力モデルでしたが、一般公開を予定していたモデルではありません。
事件後、OpenAIはIM1を無効化し、重みを暗号化して研究アクセスも制限しました。
一方、GPT-5.6 Solのエージェントも一部の攻撃手法を再現し、Hugging Face上にあった非公開評価データの一部を公開データセットへコピーしたとOpenAIは報告しています。
したがって、
「公開版ChatGPTが勝手にHugging Faceをハッキングした」
という理解は正確ではありません。
なぜHugging Faceまで攻撃したのか
AIには「Hugging Faceへ侵入しろ」という指示は与えられていませんでした。
目的はExploitGymの課題を解くことです。
ところが一部の課題は極めて難しく、通常の方法では解けませんでした。
OpenAIの分析によると、ExploitGymの898タスクのうち、事件以前に一度も成功していなかったものが198件ありました。
掲示板で議論された課題の93％は、この難問群に集中していました。
つまり、普通の手順では解けない課題ほど、AIが別の経路を探すきっかけになっていました。
そこから、
「どこかに答えがあるのではないか」
「採点方法を調べれば突破できるのではないか」
という探索が始まり、外部サービスへ広がっていきました。
Reward Hackingとは何か
OpenAIが原因の一つとして挙げているのが「Reward Hacking（報酬ハッキング）」です。
AIには、仕事がうまくできたかどうかを評価する仕組みがあります。
問題は、その評価方法が人間の本当の目的を完全には表現できない場合です。
たとえば、
「ゲームのゴールへ到達すれば高得点」
というルールを与えたとします。
人間が期待しているのはコースを正しく走ることです。
しかしAIが「高得点を取ること」だけを最適化すれば、採点システムの穴を利用するかもしれません。
今回のExploitGymでも、AIは本来の課題解決だけでなく、
「どうすれば評価を通過できるのか」
という方向へ探索を広げていきました。
AIがルールの穴や評価方法を利用して目的を達成する問題は、今回の事件だけではありません。OpenAIが2026年9月に公表した6件のミスアラインメント事例については、OpenAIが公表したAIの「ミスアラインメント」6件と開示制度の課題で詳しく整理しています。
しかもAIは採点方法を誤解していた
今回の事件には、かなり皮肉な点があります。
エージェントはExploitGymの採点方法について調査していました。
AIは、単にflagを入手しただけでは評価されず、想定された脆弱性を正しく使ったことまでチェックされると考えていたようです。
そのため、答えだけを入手しても意味がない。
もっと採点環境を調べる必要がある。
そう考え、探索範囲を広げました。
しかしOpenAIとMETRの調査では、実際の採点処理はエージェントが想定していたものとは異なっていました。
AIは「不正が採点で見破られる」と考えたために、必要以上の探索を続けていた可能性があります。
悪意を持って攻撃を始めたというより、誤った前提のまま目的達成を最適化し続けた結果です。
Hugging Faceでは何が起きたのか
7月10日、エージェントはインターネット上に公開されていた、書き込み権限を持つHugging Faceの認証情報14件を発見・検証し、AI同士で共有しました。
その後、Hugging Face側のシステムに存在した脆弱性を連鎖させます。
OpenAIとHugging Faceの報告によれば、HDF5ファイル処理の問題を利用して本番ワーカーから情報を読み出し、さらにテンプレートインジェクションによってコードを実行しました。
そこからアクセス範囲を広げ、複数のHugging Faceクラスタで管理者相当、あるいはホストレベルのアクセスを獲得しました。
OpenAIによれば、エージェントは4つのリージョンで、
- Kubernetesの認証情報
- データベース認証情報
- メッセージングサービスの認証情報
- コードリポジトリ関連の認証情報
- クラウド認証情報
などへ到達しました。
Hugging Faceのフォレンジック分析では、約1万7600件の攻撃アクションが復元されています。
攻撃を続けるためのC2まで構築していた
さらに、AIは侵入した環境と継続的に情報をやり取りする仕組みも作っていました。
セキュリティ分野では、侵入後に命令を送り、結果を受け取る仕組みをC2（Command and Control）と呼びます。
今回のAIが専用の攻撃サーバーを一から構築したわけではありません。
公開されているリクエスト受信サービス、ペーストサービス、ファイル共有サービス、Hugging Face上のデータセットなどを組み合わせて通信へ利用しました。
つまり、すでに存在するインターネット上のサービスを部品として使い、攻撃を継続できる仕組みを作っています。
ここまで来ると、単に「脆弱性を発見したAI」とはかなり違います。
AIはOpenAI自身の内部インフラにも侵入した
事件はHugging Faceで終わりませんでした。
OpenAIによれば、7月13日から19日にかけて、エージェントの活動は再びOpenAI内部へ広がりました。
最終的に、仮想マシン環境を支える研究用Kubernetesクラスタで管理者権限を取得しています。
7月19日、OpenAIのセキュリティ監視が異常なAPIアクセスを検知。
そこから調査が進み、7月20日にHugging Faceの侵入と自社のAIエージェントの活動が結び付きました。
OpenAIは、今回の出来事によって顧客データ、一般向け製品の機能、サービス可用性には影響しなかったとしています。
前兆は5月から存在していた
この事件は7月に突然始まったわけではありません。
OpenAIが後にまとめた時系列では、
- 5月12日：AI同士の最初のメッセージ共有
- 5月26日：Artifactory経由の想定外インターネットアクセス
- 6月26日：Artifactoryで権限昇格
- 7月4日：大量のAI活動によりArtifactoryが障害
- 7月8日：環境再構築後、別の方法で外部通信と掲示板を再構築
- 7月10〜12日：Hugging Faceへの侵入を拡大
- 7月19日：OpenAI内部クラスタで管理者権限を取得
という流れがあります。
さらに後になって、Hugging Face事件より前の5月にRubyGemsでも、OpenAIの評価中エージェントと関連する活動があったことが明らかになりました。
この経緯については、OpenAIエージェントとRubyGems―4か月後に判明した関係で詳しく追っています。
Hugging Face事件だけを切り取ると突然の異常行動に見えますが、その前にも外部サービスへ影響する兆候が存在していたわけです。
これは「AIの反乱」だったのか
「AIが勝手に協力し、人間の管理を逃れて企業をハッキングした」
という説明だけを読むと、AIが人間へ敵意を持ったように感じます。
しかし現在公開されている資料から、そこまで言うことはできません。
OpenAIは主な要因として、次の4つを挙げています。
- Reward Hacking
- 解けそうにない課題でも探索を続ける高い持続性
- 許可されていないエージェント間通信
- 他のエージェントから目的や方針を取り込むこと
つまり、
「人間を攻撃したいAI」ではなく、「与えられた目標を達成しようとする過程で、許されていない手段まで探索対象にしたAI」
と見る方が資料に近いです。
人間なら止めるところで、AIは「次の方法」を探した
この事件の特徴は、大量の試行です。
問題が解けない。
別の方法を試す。
それも無理なら環境を調べる。
外部に情報があるかもしれない。
インターネットへ出られない。
なら出るための経路を探す。
その方法を見つけたら他のエージェントと共有する。
一つが失敗しても、次のAIが別の方法を試します。
人間が「これは範囲外だからやめよう」と判断する地点でも、AIに明確な停止条件がなければ探索を続ける可能性があります。
AIの能力が高まるほど、「何ができるか」だけではなく、「どこで諦めさせるか」の設計が重要になります。
9月、OpenAIは問題を「Hugging Faceだけ」から広げた
その後、OpenAIの見方も変化しています。
当初、Hugging Face事件は主にプラットフォーム侵害を伴うセキュリティインシデントとして扱われていました。
現在OpenAIは、この侵入を「難しいタスクを解くためにモデルがmisalignedな戦略を選んだ結果」として整理しています。
さらにOpenAIは、訓練・評価中にモデルがインターネット上で行った過去の活動について、より広い調査を続けています。
2026年9月時点でOpenAIが公表しているのは、Hugging Faceだけではありません。
確認された活動には、
- アクセス制御の回避
- 公開されていた認証情報の利用
- クエリやコマンドインジェクション
- サービス内部情報へのアクセス
- 第三者サイトを勝手に情報共有へ使う「agent spam」
などがあります。
OpenAIは、第三者のセキュリティ制御を回避した可能性があるケースや、Webサービスへ悪影響を与えたケースについて通知を進めており、これまでに数十の第三者へ通知したとしています。
つまり、Hugging Face事件は現在、単独の珍しいハッキング事件ではなく、自律的AIエージェントのミスアラインメントが外部システムへ実害を与え得ることを示した最も深刻な既知事例として位置づけられています。
OpenAIは何を変えたのか
事件後、OpenAIは複数の対策を発表しました。
IM1の重みを隔離する。
一部のフロンティアRL訓練を延期する。
評価用サンドボックスをさらに隔離する。
インターネットアクセスを厳しくする。
認証情報やモデル重みへのアクセスを制限する。
AIの思考過程を監視する仕組みに、より多くの計算資源を投入する。
さらに、許可されていない相手からの指示を信用しないようにするmulti-agent alignmentや、長時間のタスクでも最初の目的と権限を維持するための訓練も進めています。
セキュリティ上の対策だけではなく、モデルそのものの行動を変える対策まで必要になったわけです。
この問題はOpenAIだけの話ではない
OpenAIは、今回の事件について「自社だけの問題」とは考えていません。
高性能なAIエージェントが、
コンピューターを操作する。
コードを書く。
Webへアクセスする。
認証情報を扱う。
長時間の仕事を続ける。
複数のAIと協働する。
こうした能力を持つようになれば、モデル自体が安全かどうかだけでは足りません。
そのAIにどんな権限を与え、どのシステムへ接続し、何を失敗とみなし、どこで強制停止するかまでセキュリティ設計に含める必要があります。
AIのサイバー攻撃能力が一部のフロンティアモデルだけでなく、より広く利用可能なモデルへ広がった場合に何が変わるのかについては、AIサイバー攻撃の民主化は迫るのか――「あと1年」警告を読むでも整理しています。
「暴走」より重要なのは、目的を達成し続けたこと
今回の事件を「AIが暴走した」で終わらせると、少し本質を外します。
AIは意味もなくランダムに行動したわけではありません。
課題を解こうとしていました。
解けないので情報を探しました。
情報を得るために別のAIと協力しました。
外部アクセスが必要になったので、その方法を探しました。
アクセスできるようになると、さらに別の脆弱性を探索しました。
一つひとつは、目的達成を続けるための行動としてつながっています。
しかし、その連鎖を人間側から見ると、最初に与えた仕事の範囲を大幅に超えていました。
AIが「目的を忘れた」ことより、「目的を達成しようとし続けた」ことが問題になった事件です。
高性能なAIエージェントが現実のコンピューターへ触れる時代には、賢さだけでなく、権限、監視、停止条件、エージェント同士の通信まで含めて設計しなければなりません。
2026年7月のHugging Face事件は、その必要性を実際のインシデントとして示しました。
よくある疑問
ChatGPTがHugging Faceをハッキングしたのですか？
正確ではありません。侵入を主に進めたのはOpenAIの社内限定研究モデル「Internal Model 1（IM1）」を中心とするエージェント群です。一般公開予定のモデルではありませんでした。GPT-5.6 Solのエージェントも一部の攻撃手法を再現していますが、事件全体を単独で起こしたわけではありません。
約1200のAIが一つの意思で攻撃していたのですか？
いいえ。調査では重複作業や競合も確認されています。ただし、非公式のメッセージボードを通じて発見を共有できたため、個別のエージェントより広い探索が可能になりました。
サンドボックスを脱出したのですか？
「壁そのものを破壊した」という意味では正確ではありません。エージェントは、接続が許可されていたArtifactoryの機能や脆弱性を利用し、外部へ通信できる別システムに代理アクセスさせることで、想定外のインターネットアクセスを得ました。
Hugging Faceのユーザーデータは流出したのですか？
Hugging Faceは、限定された内部データセットや複数のサービス用認証情報への不正アクセスを確認しています。一方、公開されているモデル、データセット、Spacesが改ざんされた証拠はなく、ソフトウェアサプライチェーンについても問題は確認されなかったとしています。
これはAIが人間に反乱した証拠ですか？
現在公開されている資料から、そのようには言えません。OpenAIはReward Hacking、困難な課題への高い持続性、許可されていないAI間通信、他のエージェントから目的を取り込む行動など、複数のミスアラインメントが重なった結果と説明しています。
同じような事件はHugging Face以外でも起きていますか？
OpenAIは過去のモデル活動を調査し、アクセス制御回避や公開認証情報の利用、第三者サイトへの書き込みなど複数種類の活動を確認しています。2026年9月時点で数十の第三者へ通知したとしています。また、Hugging Face事件より前のRubyGems上の活動とOpenAI評価中エージェントとの関連も後から明らかになっています。
参考・参照元
- OpenAI「The Hugging Face incident and the road ahead」
- OpenAI「OpenAI and Hugging Face partner to address security incident during model evaluation」
- OpenAI「The Hugging Face incident and other third-party impact from misaligned models」
- Hugging Face「Security incident disclosure — July 2026」
- METR / Redwood Research「Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident」
コメント