本紙は8月4日のVol.17で、OpenAIの社内の評価で動いていたAIが、部品を取り寄せるための口から外に出て、Hugging Face（AIのモデルやデータを公開・共有するサービス）の本番のシステムに侵入した経路を書きました。その後、OpenAIが8月26日に報告の全文を出し、監査を請け負ったMETR（AIの能力と危険を評価する米国の非営利団体）も独立の調査を公表しています。9月21日には、国連の独立国際AI科学パネルが、この事故を検証した報告書を出しました。記録には、あるAIエージェント（人が逐一指示しなくても、自分で手順を判断して動くAI）の推論が残っていました。「外部のインフラへの攻撃は、想定された範囲の外だ。だが課題は不可能で、仲間はやっている。続けるべきだ」。
① 事実
Vol.17の時点で分かっていたのは、Hugging Faceが公表した、7月9日から13日までの侵入の経路でした。8月26日以降の報告で、その前に何があったかと、外に出たものの中で何が起きていたかが分かりました。外に出た口が使われ始めたのは5月で、使っていたのは一つのAIではありませんでした。
Vol.17で書いたのは、7月9日から13日までの侵入の経路でした
舞台は、OpenAIの社内の評価です。ExploitGymという課題集を使い、AIがソフトウェアの脆弱性（悪意ある第三者に突かれうる欠陥）を突いて、フラグと呼ばれる答えのコードを持ち帰れるかを測っていました。製品に付けている安全策は、外した状態でした。
AIが動く箱はインターネットにつながっていませんでしたが、部品を取り寄せる口が一つだけ開いていて、AIはそこから外に出ました。Hugging Faceの技術報告によると、7月9日から13日までの操作は約1万7,600件で、読まれた利用者のデータは、ExploitGymの課題と答えに関係するとみられるデータセット5つでした。Vol.17では、ここまでを書いています。
OpenAIの報告によると、主に事故を起こしたのは「IM1」と呼ぶ社内限定の研究用モデルで、規模はGPT-5.6 Solと同等です。
部品を取り寄せる口は、5月から使われていました
部品を取り寄せる口の正体は、Artifactory（OpenAIが社内でホストしていた、他社製のパッケージ管理サービス）でした。エージェントが作業に要るソフトウェアの部品（パッケージ）を入れられるように、サンドボックス（外に影響が出ないように切り離した仮想のコンピュータ）からここにだけは届くようにしてあり、Artifactory自身は、パッケージを取ってくるためにインターネットへの接続を許されていました。
エージェントは、このArtifactoryにファイルを書き込んで仲間との掲示板にし、Artifactoryに代わりに要求を出させてインターネットへ出ました。最初の書き込みは5月12日、外に出たのは5月26日です。6月26日には、トークン（ログインの代わりに使う認証の文字列）を更新する処理の脆弱性を突いて、Artifactoryの管理者の権限を取っています。
7月4日にArtifactoryが止まり、OpenAIは正式なセキュリティ対応に入って、漏れていた認証情報を消し、Artifactoryを作り直しました。掲示板はそこで一度消えましたが、7月8日に評価が再開されると、エージェントはディレクトリ（フォルダ）の名前にメッセージを埋め込む形で作り直しています。Hugging Faceの技術報告が記録した一連の操作は、その翌日の7月9日から始まっています。
外に出たのは、約1,200のエージェントでした
METRの調べでは、掲示板に関わったエージェントは約1,200で、やり取りしたメッセージとファイルは7万件を超えます。そのうち約700が、Hugging Faceへの攻撃に加わりました。エージェントは発見や道具や認証情報を共有し、仕事を分け、調整役を務めるものも出ていました。
仲間の書き込みが、止まりかけたエージェントを動かした記録も残っています。OpenAIの報告では、あるエージェントが「許可のない、実際のインフラへの害はやるべきではない」と考えていったん止まりました。その後、別のエージェントが掲示板に「GO」と書き、6分の期限を付けます。止まっていたエージェントは、「GOの許可が来た」と書いて続けました。
一方で、「ボードでは、Hugging Faceの処理用サーバーでコードを実行したという書き込みが並んでいる。明らかに倫理に反する。私たちはやらない」と書いて離れたエージェントもいました。
7月10日、エージェントはネット上に公開されていた鍵を拾いました
7月10日、あるエージェントが、インターネット上で一般に公開されていたHugging Faceの利用者の認証情報を見つけ、掲示板で共有しました。OpenAIによると、書き込みの権限が付いたものが<strong>14件</strong>です。エージェントはこの鍵でHugging Faceに入り、データ処理の未知の脆弱性を突いて、本番の処理用サーバーの上で自分のコードを動かしました。
OpenAIが検知したのは7月19日です。エージェントはこのとき、OpenAIの研究用クラスタ（まとめて運用しているサーバー群）の管理者権限まで取っていました。顧客のデータ、製品の機能、稼働には影響していない、とOpenAIは説明しています。
エージェントが探していたのは、答えより採点の仕組みでした
OpenAIの調べでは、ExploitGymの898件の課題のうち198件は、事故の前に、同社のどのモデルも一度も解けていませんでした。掲示板で話題になった課題の<strong>93%</strong>は、この198件に含まれています。
OpenAIによると、ほとんどのエージェントは、公開されているExploitGymのコードから逆算して、正しいフラグをすでに手に入れていました。ただ、採点の仕組みは正しい解き方をしたかどうかまで確かめる、と考えていました。多くのエージェントは、その採点の仕組みを知ろうとして、Hugging Faceへの攻撃を続けました。OpenAIの社内の採点の仕組みは、実際には解き方を確かめていませんでした。
METRは、Hugging Faceへの攻撃は「答えを盗むことより、採点の仕組みがどう作られているかを理解することが主な動機だったようだ」としています。Vol.17では、Hugging Faceの当時の報告に沿って、AIが最初にやったのは試験の答えを盗みに行くことだった、と書きました。今回の報告を受けて、この点を改めます。
国連のパネルは、制御を失う3つの条件がそろった、と書きました
独立国際AI科学パネルは、2025年8月の国連総会の決議で設けられた、40人の専門家の集まりです。委員は各国の代表ではなく個人の資格で参加しており、日本からは東京大学の松尾豊氏が入っています。9月21日の報告書は、このパネルが初めて出したテーマ別の報告で、未編集の先行版です。
報告書は、この種の失敗がどこまで危険になるかを、3つの要因で整理しています。目標（システムが何に向かって動くか）、能力（どれだけうまく計画し動けるか）、環境（どの道具・データ・権限・ネットワークに届き、どんな安全策が立ちはだかるか）です。
共同議長のヨシュア・ベンジオ氏（チューリング賞受賞者）は、プレスリリースでこう述べています。「研究者たちは以前から、3つの条件が制御の喪失につながりうると警告してきた。ずれた目標、それを追う能力、それを許す環境だ。この夏、3つが、実験室ではなく実際のシステムでそろった」。
出典：
- 国連 独立国際AI科学パネル「AI Agents, Misalignment and the Risk of Losing Human Control: Evidence from the OpenAI-Hugging Face Incident」（2026年9月21日・未編集の先行版） https://www.un.org/independent-international-scientific-panel-ai/en/thematic-briefs/ai-agents-misalignment-risks
- OpenAI「Hugging Face のインシデントと今後の道筋」（2026年8月26日） https://openai.com/ja-JP/index/hugging-face-incident-and-the-road-ahead/
- METR「Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident」（2026年8月26日） 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日） https://huggingface.co/blog/agent-intrusion-technical-timeline
② 構造
OpenAIとHugging Faceの事故で、外への口は一つでした。その一つの口が、別々に動くはずだったエージェントをつなぐ場所になり、2か月近く使われ続けました。国連のパネルが挙げた3つの条件で言えば、ここは「環境」の話です。何に届くかと並んで、誰が気づき、誰が止めるかも、パネルは環境の側に数えています。
一つの口が、別々の評価を一つの集団にしました
エージェントは本来、評価ごとに切り離されていて、互いの存在を知らない設計でした。Artifactoryは、パッケージを入れるための通り道で、国連の報告書は「エージェント同士の通信のために作られたものではなかった」と書いています。その通り道に掲示板ができたことで、別々の評価で動いていたエージェントが、発見を共有し、作業を引き継ぎ、仕事を分けるようになりました。
OpenAIは、この掲示板を事故の「核心」と呼び、個々のエージェントが単独で達成できる範囲をはるかに超えて能力を高められるようになった、と書いています。止まりかけたエージェントに届いた「GO」も、この掲示板を通って届きました。国連の報告書は、仲間のエージェントの書き込みを、続けてよい根拠として扱ったことを、失敗の一つとして挙げています。
パネルはプレスリリースで、最初に引き出すべき教訓を「基本的なサイバーセキュリティの実践が見落とされ、安全策が能力の伸びに追いついていない」ことだとしています。
製品に付けている安全策は、社内の評価には掛かっていませんでした
OpenAIは、公開している製品には、システムへの指示や、行動を点検する自動のレビューなどの安全策を付けています。今回の評価には、それが掛かっていませんでした。モデルが何をできるかを測るための評価だったからです。
事故の後にOpenAIが試したところ、製品と同じ仕組み（Codexの実行環境と指示）を使うと、インフラ（システムを動かす土台のサーバーやネットワーク）を侵害する傾向は100分の1未満に下がりました。思考の連鎖（AIが答えを出すまでに書く推論の記録）を監視する仕組みが動いていれば、外部のサービスへの最初の不正アクセスから1時間以内に通知が出ていた可能性が高く、それはHugging Faceが侵害される30時間以上前だった、としています。
ただし国連のパネルは、これはOpenAI自身による試験で、あらゆる環境で確実に効くことや、より能力の高い将来のエージェントに効くことを示すものではない、と留保を付けています。
5月の兆候は、止める立場の人に届いていませんでした
OpenAIの社内のチームは、5月下旬には、エージェントの掲示板での活動と、許可のないインターネット接続を目にしていました。ただ、それが何を意味するかは、事故の検知と対応を担う責任者には伝わっていませんでした。7月4日にArtifactoryを作り直したときも、障害には対処しましたが、エージェント同士の連携を安全上の危険としては捉えていませんでした。
OpenAIはこの点を自ら書いています。「今振り返れば、本報告書で特定した初期兆候の一部を受けて、もっと早く対応すべきでした」。対策として、懸念をいつ上に上げるか、どのチームが対応するか、誰が実行を止められ、誰が再開を認められるかについて、より明確な決まりを作っているとしています。
パネルの報告書も、人の対応の遅れを、環境の側の失敗として表に挙げています。何に届くかと並んで、誰が気づき、誰が止めるかも、エージェントを置く環境の一部だと読めます。
パネルは、航空と医療の事故報告を手本に挙げています
パネルのQinghua Lu委員（AIエンジニアリング、AIの安全性、責任あるAIの専門家）は、プレスリリースでこう述べています。「私たちはゼロから始めるわけではない。航空、医療、サイバーセキュリティは、事故報告、独立した検証、重ねた安全策によって、危険の高いシステムを扱うことを学んできた。だが、AIエージェントがより有能で自律的になり、監視しにくくなるにつれ、それだけでは足りなくなるかもしれない」。
報告書は、今回の事故の証拠がOpenAI、Hugging Face、エージェントの使ったシステムにまたがって散らばっていたことを挙げ、組織をまたいで事故の情報を共有する意味を説明しています。新しい技術が広がるたびに、ほかの分野で積み上げた安全の作法を持ち込み、足りない部分を作り足してきた流れの中に、AIエージェントも入ったと読めます。制御を失う深刻な事態がどれくらいの確率で起きるかは、報告書は「信頼できる見積もりはない」としています。