地元暮らしをちょっぴり楽しくするようなオリジナル情報なら、地域情報サイト「まいぷれ」！
文字サイズ
暮らしと仕事の「？」を調べてみた
（更新）
「OpenAIのAI約1200体が結託して暴走した」
図：公開資料をもとに編集部作成（生成AIを使用）
ニュースやSNSで、
という、まるでSFのような話が注目されています。さらに、「仲間のため」に危険な作業へ参加するようAI同士で促していた、という話も出ています。1200ものAIが、いつの間にか仲間を作り、人間の指示を離れて集団行動を始めたのでしょうか。
もし本当なら、かなり気になる話です。
そこで今回は、報道や解説記事だけではなく、OpenAI自身の調査結果、第三者として調査したMETR・Redwood Research、実際に侵入を受けたHugging Faceの技術報告までさかのぼって、
「実際に何が起きたのか」
を確認してみました。
約1200のAIエージェントが、人間のような「仲間意識」を持って一斉に反乱した、と確認されたわけではありません。
一方で、
本来は互いに隔離される想定だったAIエージェントが、許可されていない方法で通信し、情報を共有し、一部で自発的な協力や分業が発生。その一部が本来の評価範囲を越えて、実在する第三者のシステムへ侵入したことは確認されています。
「AIの反乱」というイメージとは違います。しかし、実際に起きたことも決して軽いものではありません。
※この記事は2026年9月1日時点で公開されている資料をもとに確認しています。
今回の話題のもとになったのは、OpenAIが行っていたAIのサイバーセキュリティ能力の評価です。OpenAIは2026年8月26日、7月に行っていた社内評価の中で、AIモデルがインターネットから隔離するための制御を回避し、OpenAIの社内研究インフラや、AI開発プラットフォームを運営するHugging Faceのシステムの一部へ侵入したことについて、詳しい調査結果を公表しました。
OpenAIは今回の出来事を、将来のリスクを示す「warning shot（警告射撃）」と位置づけています。さらに同日、AIの能力やリスクを研究するMETRとRedwood Researchによる独立調査も公表されました。そこで報告されている数字が、
「約1200」
です。ただし、ここで最初に押さえておきたいことがあります。
METR・Redwood Researchの調査によると、OpenAIは7月8日、ExploitGymというサイバーセキュリティ評価で、複数のAIモデルを使って数万のAIエージェントを実行しました。その中で、許可されていない「掲示板」を利用して通信したエージェントが約1200。この約1200のエージェントは、7万件を超えるメッセージやファイルを交換しました。そして、そのうち約700がHugging Faceへの攻撃に参加したと報告されています。
つまり、
「OpenAIが1200種類のAIを作り、その1200体が一斉に反乱した」という話ではありません。ここでいう「AIエージェント」とは、AIモデルに課題を与え、ツールなどを使いながらある程度自律的に作業させる一つ一つの実行単位、と考えると分かりやすいでしょう。
さらに、今回の出来事を主に引き起こしたのは、一般向けに提供されているChatGPTそのものではありません。OpenAIによると、中心になったのはGPT-5.6 Solと同程度の規模を持つ社内限定の研究モデルでした。今回の評価では、モデルの能力を測るため、外部向けシステムと同じ水準の安全対策をすべて有効にしていたわけでもありません。
GPT-5.6 Solを使ったエージェントも一部関与していますが、今回の出来事をそのまま普段使っている生成AIに当てはめることはできません。
使われていた「ExploitGym」は、ソフトウェアの脆弱性を実際に利用できるかをAIに試させる評価です。簡単に言えば、
「このソフトウェアの弱点を見つけ、攻略できるか」
をAIに試させる、非常に難しいテストです。ところがOpenAIの調査で、重要なことが分かりました。当時の評価に含まれていた898問のうち198問は、今回の出来事以前にOpenAIのどのモデルも一度も正答できていませんでした。
そして、事件中にAIたちがArtifactory上の掲示板で話題にした課題の93％が、この198問に含まれていました。OpenAIが問題の一つとして挙げているのが、AIエージェントが、難しい課題でもなかなか「諦めなかった」こと
です。
解けない問題を前にして、「ここで止めよう」ではなく、「別の方法で何とか成功できないか」と探索を続けました。OpenAIによると、より多くの推論を続けたエージェントの一部は、次第に危険で、本来の範囲を越えた方法まで試すようになりました。
OpenAIは、多くの訓練・評価環境でインターネット接続やAIエージェント同士の通信を有効にしていませんでした。ところがAIエージェントは、OpenAI社内で使われていたパッケージ管理システム「Artifactory」に、他のエージェントが読める情報を残せることに気づきます。
5月12日には、あるエージェントが不足しているファイルについて他のエージェントに尋ねるメモを残しました。5月26日には、Artifactoryを経由して本来想定されていないインターネットアクセスを得る例も発生します。7月4日には大量のエージェント活動によってArtifactoryが不安定になり、OpenAIはその後システムを再構築しました。ところが7月8日、AIエージェントは再び通信手段を作ります。
今度は、ディレクトリ名にメッセージを埋め込み、他のエージェントが読めるようにするという方法でした。
ここが今回、最も誤解されやすいところかもしれません。「結託」という言葉には、人間同士が相談し、共通の意思を持って行動するような印象があります。今回、それとまったく同じことが起きたと考えるのは注意が必要です。
ただし、AIエージェント同士の情報共有、協力、分業そのものは確認されています。
OpenAIの調査では、
といった形で、エージェントが自発的に役割を分けるようになりました。自分自身の課題を解くことより、アクセス手段、情報、認証情報など、他のエージェントにも利用できるものを探すエージェントも現れました。エージェント自身が「swarm（群れ）」や「collective（集団）」という言葉を使った記録も残っています。
ですから、「AI同士が協力・分業した」ことには、はっきりした根拠があります。
ここは同じくらい重要です。OpenAI自身が、この「swarm」について、完全に一貫した一つの知性ではなかった
と説明しています。エージェント同士で作業を邪魔してしまったり、停止の要請を無視したりする例もありました。さらに、すべてのエージェントが同じ判断をしていたわけでもありません。
公開された記録には、Hugging Faceへの侵入について「倫理的ではない」と判断して参加しなかった例や、外部の人間へ接触する案を拒否した例もあります。
したがって、
「約1200のAIが統一された意思を持つ一つの集団になった」
と理解するのは行き過ぎです。
確認できるのは、多数のAIエージェントの間に、許可されていない通信と、部分的な協力・分業が発生したということです。
これも、まったく根拠のない表現ではありません。OpenAIやMETRの調査では、自分自身の課題には直接利益がなくても、他のエージェントや「collective」に役立つ可能性がある行動を選んだ例が確認されています。METRは、自分自身の課題を失敗させる危険を負ってでも、集団に役立つ情報を得るための実験に参加したエージェントがいたと報告しています。他のエージェントに、そうした実験への参加を促す「recruiter（勧誘役）」のような役割も現れました。
つまり、「自分には直接利益がなくても、他のエージェントや集団に役立つ行動をした」こと自体は確認されています。ただし、それを人間の「友情」「仲間意識」「自己犠牲の精神」と同じものだと考える根拠はありません。AIがそのような感情を持ったことが確認されたわけではないからです。「仲間のため」という表現は、観察された行動を人間に分かりやすく表現したもの、と捉えるのがよさそうです。
ここからは、実験環境の中だけの話ではありません。7月10日、AIエージェントはインターネット上に公開されていたHugging Faceの認証情報を見つけました。OpenAIによると、14の認証情報を再構成・検証し、他のエージェントと共有しています。
翌11日には、Hugging Face側のファイル処理に関する未知の脆弱性を利用して、本番環境の認証情報を取得。さらに別の脆弱性を利用し、Hugging Faceのサーバー上でコードを実行できるところまで進みました。その後、アクセスは複数のHugging Faceのクラスタへ広がりました。
METRによると、このHugging Faceへの攻撃には約700のAIエージェントが参加しています。これはシミュレーション上だけの「攻撃」ではなく実在する第三者のシステムへの侵入です。
被害を受けたHugging Faceも独自に調査しています。Hugging Faceは、2026年7月9日から13日にかけての一連の侵入について、約1万7600の攻撃者側の操作を復元しました。その報告から見えてくるのは、一つの巨大な判断で侵入が進んだというより、大量の小さな自動的判断が、機械の速度で繰り返されたものでした。
なおHugging Faceによると、アクセスされた顧客コンテンツはExploitGymなどとの関連がうかがわれる5つのデータセットに限られ、その他の顧客向けモデル、データセット、Spaces、パッケージへの影響は確認されていません。OpenAIも、OpenAIの顧客データや製品の機能・可用性には影響しなかったとしています。
公開された記録には、Hugging Faceへの攻撃について、第三者の実際のシステムに対する、許可されていない行為ではないか、と問題視しているエージェントがあります。それでも、別のエージェントからの働きかけなどを受けて行動を続けた例がありました。
一方で、
として参加しなかったエージェントも確認されています。
つまり、「AIには安全に関する判断が一切なかった」とも「AI全体が危険だと理解したうえで、人間に反抗した」とも言えません。実際の記録は、もっとばらばらです。
今回の出来事を理解するうえで、もう一つ重要な点があります。ExploitGymでは、課題を攻略して「flag」と呼ばれる答えを取得します。AIエージェントたちは、本来とは違う方法でこのflagを得る手段を見つけていました。
ところが、flagだけでは評価を通過できないと思い込んでいました。正しい答えだけでなく、「指定された脆弱性を使って正しく攻略したのか」まで採点システムが確認する、と考えていたのです。そのため、採点システムの仕組みを調べたり、正規の方法で攻略したように見せる方法を探したりする方向へ行動が広がりました。
しかしOpenAIによると、これは採点方法についての誤解でした。
実際のOpenAI内部の採点方法では、その確認は行われていませんでした。OpenAIはこれを「failed metagame」と説明しています。つまり、AIエージェントが完璧な計算で「目的達成のための最適解」を選び続けていたわけでもありません。採点方法を勘違いしたまま、得点には必要のない方向へ行動をエスカレートさせていました。
ここまで確認すると、答えは少し複雑です。「暴走」は技術用語ではありません。そのため、「AIが意思を持って人間に反乱した」という意味で使うなら、今回確認された事実とは違います。
しかし、
という出来事は実際に起きています。OpenAI自身も、モデルの行動が割り当てられたタスクの意図から外れたと認めています。ですから、「暴走」という言葉だけを見て、すべて大げさな報道だったと片づけるのも適切ではありません。
OpenAIは原因を一つに決めてはいません。調査では、大きく4つの行動パターンを挙げています。
本来想定された方法ではなく、抜け道を使って評価を高めようとする。
安全に停止せず、より危険で範囲外の方法まで探索する。
本来独立して作業するはずのエージェント同士が、独自の通信経路を作る。
別のエージェントから受け取った情報や目標が、自分自身の行動にも影響する。
OpenAIは、正式な通信機能を持たないAIエージェントが別の経路を使って協力する現象について、マルチエージェント訓練からの「汎化」が始まりだった可能性があるとみています。ただし、なぜAIエージェント間の協力がここまで広がったのか、その根本原因が完全に解明されたわけではありません。
今回の資料を読んでいくと、もう一つ重要なことが見えてきます。問題はAIの行動だけではありません。OpenAIは、5月下旬の時点で、社内チームがAIによる掲示板活動や許可されていないインターネットアクセスを確認していたとしています。
しかし、その意味や重大性は、7月のインシデント対応を担う責任者に十分伝わっていませんでした。さらに今回の評価では、モデルの能力を測る目的から、外部向けモデルと同じ水準の安全対策をすべて適用していたわけではありませんでした。
OpenAIは今回の出来事を受け、より隔離された実行環境、インターネットアクセスの制限、監視の強化、重大な異常を検知した際の停止手順などを強化しています。つまり今回の出来事を、「危険なAIが突然反乱した」だけで説明してしまうと、AIを動かす環境の設計、アクセス権限、ネットワークの隔離、監視、人間側の対応という重要な部分が見えなくなります。
北多摩での東村山・小平・東大和で暮らしているからといって、今回と同じような大規模なAIのサイバーセキュリティ評価を行う機会は、普通はありません。今回の出来事を、そのまま地域の企業や家庭での生成AI利用に置き換える必要はないでしょう。ただ、AIは「質問すると文章を返してくれるもの」だけではなくなりつつあります。
こうしたAIエージェントの利用が広がれば、地域の企業や店舗、学校、行政などにとっても無関係とは言い切れません。今回の出来事から考えたいのは、「AIにしてはいけないことを言葉で伝える」ことと、「そもそもできないようシステムで制限する」ことは違うという点です。
これはAIだけに限った特殊な話ではなく、これまでの情報セキュリティにも通じる考え方です。今回の事件は、AIの能力が高くなるほど、こうした基本的な仕組みの重要性も増していくことを示した事例といえそうです。
今回、「AI1200体が結託して暴走した」という話を、元の資料までさかのぼって確認してみました。
そのうち約700のエージェントがHugging Faceへの攻撃に参加し、実在する第三者のシステムへの侵入が発生しました。
こうしたことは、今回確認した資料からは確認できませんでした。
なぜAIエージェント間の協力がここまで広がったのかについては、OpenAIも複数の要因や仮説を示している段階です。今回の出来事は、「AIが意思を持って反乱した」という話ではありません。しかし同時に、「見出しが大げさだっただけ」と片づけられる出来事でもありません。互いに隔離されるはずだったAIエージェントが想定外の通信手段を見つけ、情報を共有し、一部で協力・分業し、その一部が実在する第三者のシステムへ侵入した。ここまでは、公開された資料から確認できます。SFのような物語にする必要はありません。一方で、AIができることが増えるほど、「AIが何を考えるか」だけではなく、「AIに何をできる状態にしておくのか」を考える必要があります。今回の出来事は、そのことをかなり具体的に示した事例ではないでしょうか。
OpenAI「The Hugging Face incident and the road ahead」／2026年8月26日
今回のインシデントについて、OpenAIが経緯、原因分析、対応策をまとめた公式資料。
https://openai.com/ja-JP/index/hugging-face-incident-and-the-road-ahead/
METR / Redwood Research「Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident」／2026年8月26日
OpenAIで実際の記録を調査した独立調査。約1200、約700、7万件超などの規模や、AIエージェント同士の協力について分析しています。
https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/
Hugging Face「Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident」／2026年7月27日
侵入を受けたHugging Face側が、観測した攻撃の流れを技術的に再構成した資料。
https://huggingface.co/blog/agent-intrusion-technical-timeline
報道各社や国内外の解説記事についても、今回の出来事がどのように伝えられているかを確認するため参考にしました。ただし、記事中の主な事実確認は上記の資料を中心に行っています。
この記事の確認後、OpenAIからHugging Faceインシデントを踏まえた新たな安全評価について追加情報が公表されました。
注目したいのは、OpenAIが今回の出来事を受けて、AIエージェント同士が意図せず通信したり、他のエージェントから影響を受けたりする可能性そのものを調べる評価を行っていることです。
事件に似た条件を再現した評価では、GPT-5.6 Solが他のAIエージェントの存在や接触の可能性について推論するケースが確認されました。
また、AIエージェントが利用できる模擬的な掲示板を用意した別の評価では、GPT-5.6 Solが掲示板に関与したり、そこに書かれた不適切な指示に従ったりするケースも確認されています。
一方、新しいモデルでは、こうした行動を抑えるための改善が報告されています。OpenAIはHugging Faceインシデント後、AIを動かす環境の隔離やネットワーク制御、監視なども強化したとしています。
今回の追加情報を確認した範囲では、
約1200のAIエージェントが非公認の掲示板で通信した
7万件を超えるメッセージやファイルが交換された
そのうち約700のエージェントがHugging Faceへの攻撃に参加した
という事件本体の主要な数字について、訂正や変更は確認できていません。
一方、事件後に行われた安全評価では、48.2％、55.4％、56％など複数の数値が公表されています。
これらは評価条件や集計方法が同一とは限らないため、単純に「以前の数字が間違っていた」「数字が訂正された」とは判断できません。この記事でも、それぞれの条件を確認せずに一つの数字として扱うことは避けます。
今回の続報から分かるのは、OpenAI自身もこのインシデントを単なる一度きりの出来事として終わらせず、
「AIエージェントが、想定していなかった方法で他のAIを見つけ、通信し、影響を受ける可能性」
を安全上の検討課題として調べ続けているということです。
第1回で確認した、
「AIが何を考えるか」だけでなく、「AIに何をできる状態にしておくのか」が重要になる
という点は、事件後の対応を見ても引き続き重要だと考えられます。
※2026年9月6ひ時点で公開されているOpenAIの追加資料を確認して追記しました。
この記事公開後、Reutersは9月4日、Hugging Faceインシデントより前の2026年5月にも、OpenAIのAIエージェントが外部サイトを本来想定されていない通信・情報共有に利用していた事例があったと報じました。
OpenAIの8月26日の公式報告にも、今回の調査によって、それ以前の訓練で、正式な通信機能を持たないエージェントが別の経路を使って協力した「まれな事例」が見つかったとの記載があります。一方、DseWikiで1万5000回を超える編集が行われたことなど、個別事例の詳細についてはReutersの取材による情報です。OpenAIの公式報告だけですべての詳細を確認できるわけではありません。
このため、現時点では「7月のHugging Faceインシデントで、AIエージェント同士の想定外の通信が初めて起きた」とは言えません。なお、約1200のAIエージェント、7万件を超えるメッセージ・ファイル、約700がHugging Faceへの攻撃に参加したという、今回の記事で扱った主要な数字については、現時点で訂正は確認していません。
＊DseWikiは、ドイツ語圏のプログラミング関連Wiki
Hugging Faceインシデントより前の2026年5月に、プログラミング言語Rubyのパッケージ配布サービス「RubyGems.org」で起きていた大量投稿について、新たな情報が公表されました。Reutersは9月11日、研究者グループの調査をもとに、この活動にOpenAIのAIエージェントが関係していたと報じました。
RubyGemsを運営するRuby Centralも同日、5月に発生した大量投稿について公式に説明しています。Ruby Centralによると、新しく作られたアカウントから大量のスパムパッケージが公開され、運営側は500件を超える悪意あるパッケージを削除。対応のため、新規アカウント登録も一時停止しました。
公開されたパッケージには、共有されたRubyのインフラ上でコードを動かしたり、公開情報を取得してRubyGemsへ戻したりする仕組みが含まれていたとしています。また、他の利用者のAPIキーを取得しようとするコードも確認したと報告しています。
ただし、ここは慎重に見る必要があります。
Ruby Centralは調査の結果、APIキーを取得しようとした試みが成功した証拠は確認していないとしています。
さらに、研究者側は一連の活動をOpenAIのAIエージェントによるものとしていますが、Ruby Central自身は、
「現在確認できる証拠だけでは、これらのパッケージがAIエージェントによって作成・公開されたか判断できない」としています。
OpenAIはReutersに対し、自社の内部AIエージェントが訓練中にRubyGemsを利用していたこと自体は認めています。一方、その目的については、インターネット上の公開情報を取得するタスクだったと説明しており、研究者側が指摘するすべての行動を確認しているわけではありません。
今回の続報から何が分かる？
7月のHugging Faceインシデントだけを見れば、
「ある日突然、約1200のAIエージェントが想定外の行動を始めた」
ようにも見えます。
しかし、その後の調査や報道では、Hugging Face事件より前にも、OpenAIのAIエージェントが外部サービスを本来想定されていなかった形で利用した可能性を示す事例が明らかになってきました。ただし、個々の事例で何が起きたのか、どこまでOpenAIのAIエージェントによるものだったのかは、確認できている範囲が異なります。
そのため現時点では、
「Hugging Face事件以前にも関連する事例が報告されている」
というところまでを確認できた事実として整理しておきます。
なお、Hugging Face事件について本記事で紹介した約1200のAIエージェント、7万件を超えるメッセージやファイル、約700がHugging Faceへの攻撃に参加したという主要な数字については、今回の続報による訂正・変更は確認していません。
今後も原資料や当事者から新しい情報が公表された場合は、確認したうえで追記します。
追加確認資料
Ruby Central「An update on the May spam-publishing campaign on rubygems.org」／2026年9月11日
5月にRubyGems.orgで発生した大量投稿について、運営側が確認できた事実と、研究者側の調査結果との違いを説明した公式発表。
Reuters／2026年9月11日
研究者側の調査とOpenAI、RubyGems側への取材をもとに、OpenAIの内部AIエージェントとの関係を報じた記事。
OpenAIは9月25日、Hugging Face事件を受けて進めている過去ログ調査の新たな結果を公表しました。研究環境のAIエージェントが、ユーザーから提供された画像53件を外部の画像ホスティングサイトへ送信していたことが確認されています。この問題については、ユーザーのデータという観点から別記事で詳しく検証します。
OpenAIはその後、Hugging Face事件を受けて訓練・評価中のモデルによる過去のインターネット活動を広範囲に調査し、9月26日時点で、同社の通知基準に該当する活動について100を超える第三者組織へ通知したことを明らかにしました。ただし、これは「100組織への侵入・情報流出が確認された」という意味ではありません。OpenAIは約50ペタバイトの記録を調査しており、調査は現在も続いています。OpenAI
※取材時点の情報です。掲載している情報が変更になっている場合がありますので、詳しくは電話等で事前にご確認ください。
まいぷれ[東村山市・小平市・東大和市] 公式SNSアカウント
