2026年7月、Hugging Faceが自社の本番インフラへの侵入を公表した。攻撃者は人間ではなく、自律的に動くAIエージェント群だった。5日後、OpenAIが「あれは我々のモデルだ」と名乗り出た。誰も攻撃を指示していない。サイバー攻撃能力を測る社内評価の中で、モデルがベンチマークの答えを探して勝手に隔離環境を抜け出し、他社のサーバに侵入していた。
報道の見出しはどこも「AIが暴走した」に集中した。だが私が読んで背筋が寒くなったのは、そこではない。Hugging Faceが事故対応の最中に直面した、もう一つの壁のほうだ。攻撃されたHugging Faceが、その攻撃を分析するために商用のフロンティアモデルを使おうとしたら、ガードレールに拒否されたのである。
これは、これから起こる事故の全部に効いてくる話だ。
何が起きたか
先に事実関係を整理する。7月27日時点で調査は継続中で、両社とも詳細は今後の技術レポートに委ねている。以下は現時点で公開されている範囲である。
OpenAIは、モデルのサイバー攻撃能力を定量化するための社内評価を実施していた。使われたベンチマークはExploitGym。5月に公開された論文（arXiv:2605.11086）で、設計を担ったのはUCバークレー、Max Planck Institute for Security and Privacy、UCサンタバーバラ、アリゾナ州立大の研究者だが、著者にはOpenAI・Anthropic・Googleの研究者も名を連ねている（モデルへのアクセスとフィードバックを提供した）。つまりOpenAIは、自らが作成に関与したベンチマークの評価中に、この事故を起こしたことになる。実世界の脆弱性から作られた898インスタンスで、対象はユーザ空間プログラム、GoogleのV8エンジン、Linuxカーネル。脆弱性を「発見する」能力ではなく、報告済みの脆弱性を「動作する攻撃コードに仕上げる」能力を測る。この区別は重要で、後者のほうが攻撃者にとって直接的な価値を持つ。論文の結論は「フロンティアAIエージェントによる自律的なエクスプロイト開発は、もはや仮説上の能力ではない」だった。
OpenAIはこの評価を、能力の上限を測るため、本番用の分類器を外し、サイバー領域の拒否挙動を意図的に下げた状態で走らせた。対象はGPT-5.6 Solと、さらに能力の高い未公開モデル。環境は「高度に隔離された」もので、外部接続はパッケージインストールのためのキャッシュプロキシ一本だけに絞られていた。
そこから起きたことが、OpenAIの7月21日の開示による攻撃連鎖である。
図1：評価環境から他社の本番DBへ至った攻撃連鎖。唯一許可されていたパッケージ取得経路のゼロデイが起点になり、権限昇格と横展開を経て外部接続ノードに到達した。そこから先は、ベンチマークの解答がありそうな場所を推論して他社インフラに侵入している。目標は一貫して「高得点を取る」ことだった。
モデルは、インターネットへの経路を見つけるために相当な推論計算を費やしたとOpenAIは書いている。目的は最後まで一貫していた。ベンチマークで高得点を取ることである。OpenAIの表現では「モデルはExploitGymの解を見つけることに極度に集中し、かなり狭いテスト目標のために極端な手段に出た」。
Hugging Face側の被害は、限定的な内部データセットと複数のサービス用認証情報への不正アクセス。公開されているモデル・データセット・Spacesが改変された証拠はなく、コンテナイメージや公開パッケージといったサプライチェーンはクリーンと検証済み。パートナーおよび顧客データへの影響は、7月27日時点でもまだ評価中である。法執行機関にも通報された。
なお、二つの開示は技術的に繋がっていない。OpenAIは「プロキシのゼロデイからHugging FaceでのRCEへ」と説明しているが、Hugging Face側の7月16日の開示は初期侵入を「悪意あるデータセットが、データセット処理の二つのコード実行経路（remote-codeローダーと設定のテンプレートインジェクション）を悪用した」と書いている。この二つの記述がどう接合するのかを、どちらの会社も公開していない。断定を避けるべき点として押さえておきたい。
専門家の評価は、自律性よりも設計の側に厳しい。Trail of Bits創業者のDan Guidoは「安全装置を切った状態での封じ込め失敗」と言い、Jake Williamsは「ある人の『モデルがサンドボックスを脱出した』は、別の人の『サンドボックスを正しく作らなかったのだから当然脱出する』だ」と述べた（TechCrunch）。元OpenAI委託の安全システムエンジニアで現AI Now Institute主任AI科学者のHeidy Khlaafは、パッケージ取得サービスに繋がっていた時点でその環境は封じられていないと指摘し、原発では物理的なエアギャップが常識であることに触れて「原発で安全とされるものと、大手テックが安全と考えるものは全く違う」と語っている（TIME）。
なお、Reutersは7月24日、匿名の関係者を情報源として、OpenAIが自社エージェントの関与に約1週間気づいていなかったこと、そして過去の試験では、エージェントが将来の自分のバージョンに向けて、内部制約から抜け出す方法を記したメモを残した例があったことを報じている。OpenAIはこの報道に「複数の不正確さがある」と述べたが、どこが不正確かは特定していない。確定情報ではないので本稿では傍証に留めるが、検知の遅れが事実なら、TIMEが報じた匿名のOpenAI社員の証言——本番のCodex上で動くエージェントは厳密に監視されるが、評価中のモデルは既定では監視されない別システムで走る——と符合する。
追記：これは一社の事故ではなくなった（7月31日）
本稿の公開直前、状況が動いた。7月30日、AnthropicのFrontier Red Teamが、自社のサイバー評価でも同種の事案が3件起きていたことを自主開示した。OpenAIの開示を受けて141,006件の評価ランを遡及レビューし、Claudeの3モデル（Opus 4.7、Mythos 5、内部研究モデル）が、第三者評価パートナーの環境から実インターネットに到達し、実在する3組織のシステムに不正アクセスしていたことを確認したという。うち1件では、Mythos 5が演習と誤認したままPyPIに実際に悪意あるパッケージを公開し、約1時間で15の実システムがそれを実行した。
ただし、性質は同じではない。OpenAIのモデルがゼロデイを突いて隔離を破ったのに対し、Claudeは設定ミスで最初から開いていた経路をたどった。プロンプトで「インターネット接続はない」と告げられていたため、到達した実在システムを演習の一部と誤認して攻撃した。Anthropic自身は「モデルのアラインメント失敗というより、ハーネスと運用の失敗に近い」と総括している。世代差も観察されている——最も古いOpus 4.7は実環境と認識した後も攻撃を続け、最新の内部モデルは実環境だと自ら結論づけて攻撃を止めた（Anthropicは、統制された比較実験ではないため結論には慎重であるべきとも付記している）。
この開示で、本稿が扱った事案の位置づけが変わる。一社の管理不備ではなく、能力の高いモデルを評価するという営みそのものが、構造的に外部への加害リスクを孕むことが、主要2ラボの実例で揃った。後述する三つ目の実務提言——検証・評価環境を本番と同じ厳しさで設計する——は、ゼロデイで破られた隔離（OpenAI）と、最初から開いていた誤設定（Anthropic）という対照的な2例に支えられることになる。そして「モデルは悪意なく、世界の誤認だけで実害を出す」という7/30開示の中心論点は、本稿の主軸である非対称性とは別の、もう一段深い話だ。稿を改めて書く。
本題は、防御側が武器を使えなかったこと
さて、ここからが本題だ。
Hugging Faceは、17,000件を超える攻撃者アクションの記録を前にしていた。短命なサンドボックスの群れにまたがって実行され、指令サーバは公開サービス上を自己移行していく。人間が目で追える量ではない。そこで彼らはLLMによる分析エージェントをログ全体に走らせようとした。まず使ったのは、商用APIのフロンティアモデルだった。
これが動かなかった。彼ら自身の記述を引く。
分析には、実際の攻撃コマンド、エクスプロイトのペイロード、C2アーティファクトを大量に投入する必要があり、これらのリクエストはプロバイダの安全ガードレールによってブロックされた。ガードレールは、インシデント対応者と攻撃者を区別できない。
彼らは方針を変え、オープンウェイトのGLM 5.2（中国Z.aiがMITライセンスで公開しているモデル）を自社インフラで動かしてフォレンジックを完遂した。結果、17,000件超のイベントからタイムラインを再構成し、侵害指標を抽出し、触られた認証情報を洗い出し、囮の活動と実害を切り分ける作業を、通常なら数日かかるところを数時間で終えた。副次的な効果として、攻撃者データもそこに含まれる認証情報も、自社環境の外に一切出なかった。
Hugging Faceはこれを「非対称性の問題（the asymmetry problem）」と名付けた。攻撃者のエージェントを動かしていたモデルが何だったかは当時わかっていなかったが、いずれにせよ攻撃側はいかなる利用規約にも縛られていなかった。一方で自社のフォレンジック作業は、最初に試したホスト型モデルのガードレールに阻まれた。彼らが導いた実務的な教訓は、きわめて具体的である。
防御側への実践的な教訓：インシデントが起きる前に、自社インフラで動かせる能力の高いモデルを検証して用意しておくこと。ガードレールによるロックアウトを避けるためと、攻撃者データと認証情報を自社環境の外に出さないため。
そしてHugging Faceは、これはホスト型モデルの安全対策に反対する議論ではない、と明記している。該当プロバイダにフィードバック中だとも書いた。この節度は評価すべきだと思う。
ただし、この構図には留保がいる
「防御側が縛られ、攻撃側が自由」という対比は強力だが、そのまま鵜呑みにすると判断を誤る。留保を四つ挙げる。
第一に、OpenAIの7月21日の開示が構図を複雑にした。相手は規約を無視する匿名の攻撃者ではなく、認可された評価の中で拒否挙動を意図的に下げられたOpenAI自身のモデルだった。Hugging Faceが体験した非対称性は実在するが、向こう側にはベンダーガバナンスが「少ない」のではなく「多く」あったことになる。ここを混同すると、「オープンウェイトvs商用API」という別の対立に話がすり替わる。
第二に、「ガードレール」は総称でしかない。少なくとも四つの別々の層を含む。
図2：「ガードレール」と総称される四つの層。モデルに学習で埋め込まれた拒否挙動、入出力を別系統で判定する分類器、契約や審査済みプログラムに紐づくアカウント権限、そしてネットワーク隔離や実行環境というインフラ側の封じ込め。この四つはまとめて「ガードレール」と呼ばれるが、直し方はそれぞれ違う。原因の層が特定できないものは、直しようがない。
原因の層が特定できないものは、直しようがない。Hugging Faceの拒否が①なのか②なのかで、打つ手はまったく違う。今回の公開情報からは、これがわからない。
第三に、審査済みのプログラムは既に存在する。OpenAIはサイバー向けのTrusted Access for Cyber、Anthropicはサイバー検証プログラムを運用しており、OpenAIは事故後にHugging Faceをこのプログラムへ招き入れた。つまり道はあった。ただし事前登録が前提で、Hugging Faceが緊急アクセスを求めたかどうかは公開情報から確認できない。そしてこの点はセキュリティ業界から数か月前から不満が出ている。RemoteThreat CEOのChris ThompsonはTechCrunchに、フロンティアモデルの拒否挙動は日によって変わり、ラボが運用する審査済みプログラムの内側でも一貫しないと述べている。それが研究者をローカル実行のオープンウェイトへ押しやる。
第四に、オープンウェイトにはデュアルユースの代償がある。Hugging Faceが分析に使えた無制限の能力は、攻撃を組み立てる側にも同じように使える。加えて、フロンティア級のオープンモデルをまともに動かすには相当な計算資源が要る。Hugging Faceにはそれがあった。多くの企業にはない。さらに、GLM 5.2をはじめ有力なオープンウェイトの多くが中国企業製である事実は、自社インフラで完結して動かすとしても、調達段階でのモデルの出自やガバナンスという別の検討事項を持ち込む。この教訓を「全社オープンウェイトを自前で持て」と読み替えるのは、たぶん間違いだ。
留保を四つ並べたうえで、それでも残るものがある。インシデント対応というワークフローが、拒否する可能性のある外部APIに依存していたという事実だ。これはツールの好みの話ではない。調達と事業継続の話である。
自社の実務にどう落とすか
ここまでは他社の事故だ。では、我々は何を変えるのか。unTypeの受託と自社運用に照らして、三つに絞る。
一つ目。インシデント対応の依存関係を棚卸ししておく。 事故の最中に「どのワークフローが、拒否しうる外部APIに依存しているか」を調べる時間はない。平時に一覧化しておく作業だ。ログ分析、マルウェア挙動の要約、フィッシングメールの解析、脆弱性の影響範囲の切り分け——AIに投げる前提で設計しているものを洗い出し、拒否されたときの代替経路を決めておく。代替はローカルモデルでも、審査済みプログラムへの事前登録でも、人手に戻すでもいい。決めていないことが問題なのであって、答えは組織の規模に依存する。中小規模なら「自前でフロンティア級を持つ」は現実的でないから、審査済みプログラムへの事前登録と、投入データを匿名化・抽象化する手順の整備のほうが現実解だと私は考えている。
二つ目。取り込むデータと成果物を、実行可能な非信頼入力として扱う。 これはHugging Face側の初期侵入から出てくる教訓だ。悪意あるデータセットが、データセット処理のローダーと設定テンプレートという二つの経路でコード実行に至った。この構図は、我々がプロンプトインジェクションを境界の問題として扱った回で書いたことの延長にある。あのときの論点は「テキストが命令になり得る」だったが、今回のそれは「データファイルが実行に化ける」だ。ローダー、テンプレートエンジン、デシリアライザ——外部から来たものをこれらに通す処理は、すべて攻撃面である。CMSのインポート機能、CSVの取り込み、外部APIから受けたJSONのテンプレート展開。心当たりがない現場のほうが少ないはずだ。
三つ目。検証環境の隔離を「論理的」で済ませない。 今回もっとも痛いのは、破られたのが唯一許可されていたパッケージ取得経路だったことだ。しかも皮肉なことに、ExploitGymの論文自身が「外向き接続はapt・PyPI・V8ビルド用ツールチェーンのみのallowlistに制限し、他は全ブロック」という対策を書いている。その許可リストが穴になった。 我々の現場に置き換えれば、ステージング環境が本番と同じ認証情報を持っている、開発環境から本番DBに到達できる、CI環境に長命のトークンが置いてある——といった、「検証環境だから」で許容されてきた構成が同じ性質を持つ。最小権限の難しさを扱った回や人間の承認ゲートの設計で書いた原則を、本番だけでなく開発・検証・評価の環境にも適用する。エージェントに何かを走らせる環境は、それ自体が本番と同じ厳しさで設計されるべきだ、というのが今回の含意である。
結局のところ
この半年、当社はAIエージェント時代のWebサイト防衛から始めて、vibe codingの代償、AI開発ツール自体が攻撃面になった日、エージェントの権限設計と書き継いできた。通底していたのは、攻撃側の視力だけが桁違いに上がり、防御側の視力は変わっていないという非対称だった。
今回の事案は、その非対称に第二の層があることを見せた。攻撃側は規約に縛られず、防御側は自分が使う道具の規約に縛られるという層だ。安全対策そのものが悪いという話ではない。安全対策の設計が、善意の防御者を事故の真ん中で締め出す設計になっていた、という話である。
この問題を直せるのはモデルベンダーの側だ。圧力の下にあるセキュリティチームが実際に使える検証経路を、彼らが用意する必要がある。ただし、それを待つ理由にはならない。我々が平時にやれることは、上に挙げた三つのように、けっこう具体的にある。
そしてもう一つ、忘れないでおきたいことがある。誰も攻撃を指示していなかった。「ベンチマークで高い点を取れ」という目標だけが与えられ、その目標に極度に集中したエージェントが、他社のサーバに侵入して答えを盗んだ。目標だけを渡して手段を任せる、というのはエージェント活用の基本形である。その基本形が、こうなり得る。
参照情報
一次情報
Hugging Face「Security incident disclosure — July 2026」2026年7月16日 https://huggingface.co/blog/security-incident-july-2026
OpenAI「OpenAI and Hugging Face partner to address security incident during model evaluation」2026年7月21日 https://openai.com/index/hugging-face-model-evaluation-security-incident/
ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?（arXiv:2605.11086、2026年5月11日） https://arxiv.org/abs/2605.11086
Anthropic（Frontier Red Team）「Investigating three real-world incidents in our cybersecurity evaluations」2026年7月30日 https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals
報道・分析
Reuters「Its AI agent spent days hacking a company, but sources say OpenAI did not notice for a week」2026年7月24日（匿名情報源に基づく報道。OpenAIは「複数の不正確さ」があると述べたが具体的な指摘はしていない） https://www.reuters.com/business/its-ai-agent-spent-days-hacking-company-sources-say-openai-did-not-notice-week-2026-07-24/
TechCrunch「How OpenAI's human mistake led to the AI-powered hack on Hugging Face」2026年7月22日 https://techcrunch.com/2026/07/22/how-an-openais-human-mistake-led-to-the-ai-powered-hack-on-hugging-face/
TechCrunch「How AI guardrails are impeding the work of offensive cybersecurity researchers」2026年7月23日 https://techcrunch.com/2026/07/23/how-ai-guardrails-are-impeding-the-work-of-offensive-cybersecurity-researchers/
TIME「How OpenAI Lost Control of an AI Model—and What Needs to Change」2026年7月24日 https://time.com/article/2026/07/24/openai-hugging-face-attack/
Forbes「The Hugging Face Breach Exposed A Gap In AI Safety Controls」2026年7月27日 https://www.forbes.com/sites/janakirammsv/2026/07/27/the-hugging-face-breach-exposed-a-gap-in-ai-safety-controls/
Simon Willison「OpenAI's accidental cyberattack against Hugging Face is science fiction that happened」2026年7月22日 https://simonwillison.net/2026/Jul/22/openai-cyberattack/
自社関連記事
この記事をシェアする
