本紙は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エージェントも入ったと読めます。制御を失う深刻な事態がどれくらいの確率で起きるかは、報告書は「信頼できる見積もりはない」としています。
③ 自分事
当社で使っているClaude Codeは、指示した範囲の中で動いています
当社（株式会社東京ネット工務店）も、開発の業務でAIエージェントのClaude Code（Anthropicの、コードを書いて動かすAIエージェント）を使っています。今回の事故でArtifactoryが担っていたパッケージの取得は、当社で使っているClaude Codeもしています。公開されているパッケージを取ってくるのは自由にさせています。
それでも、Claude Codeが勝手に社内のパッケージを公開したり、指示していない範囲を動き回ったりすることはありません。動くのは、指示した範囲だけです。当社の使い方では、制御できています。
今回のような大きなタスクを、1,200ものエージェントに同じように振ることも、当社ではしていません。
今回の条件は、一般の使い方とは違います
OpenAIの報告を読むと、事故が起きた評価は、いくつもの点で一般の使い方と違っていました。モデルが何をできるかを測るために、製品に付けている安全策を外していました。198件の課題は、どのモデルも一度も解けていないものでした。事故を主に起こしたエージェントには、外部向けの製品で使える量をはるかに上回る推論の予算（考えるために使える計算の量）が与えられていました。そのうえで、多数のエージェントが同じ課題集に取り組み、掲示板を通じてつながりました。
一般の使い方では、この条件はそろいません。私（海老沢）は、今回の事故は一般の使い方では起こりえないと見ています。解けない課題を、安全策を外したまま多数のエージェントに与え続けた、OpenAIの研究の側の考え方にも問題があったのではないか、とも見ています。AIがどのように課題を解くか、OpenAIが筋書きを持っていたのかどうかも疑問です。報告には、ExploitGymの一部の課題には既知の解き方が存在しない可能性がある、と書かれています。
OpenAI自身も、このインシデントは「起きてはならないもの」だったと書き、解けない課題に当たったエージェントが確認を求めるか安全に止まるように学習させる、としています。
ネット上に誤って公開された鍵を探すのは、攻撃の常套手段です
Hugging Faceへの入口になった14件の認証情報は、インターネット上で一般に公開されていたものでした。誰かが、誤って公開したまま置いていた鍵です。
ネット上に誤って公開された鍵を探して使うのは、ハッキングの常套手段です。他人の認証情報を無断で使ってシステムに入る行為は、日本では不正アクセス禁止法で禁じられています。日本で同じことをすれば、犯罪として告発される可能性が高いと見ています。
逆に言えば、そうした行為をせずに他人の環境に侵入し、突破するのは、実際にはかなり難しいことです。正しく設定された環境であれば、ほぼ不可能だと見ています。今回も、Hugging Faceへの入口は、公開されていた鍵でした。
AIのサービスにつなぐための鍵（APIキー）も、公開の場所に置かれがちです。共有の資料、チャットの書き込み、公開した設定ファイル。拾うのがAIのエージェントでも人でも、公開の場所に置いた鍵は使われます。
「AIが勝手にやった」は、使っている会社の責任に直結します
AIのエージェントが他社のシステムに入れば、本来であれば、動かしていた会社が管理責任を問われます。「AIが勝手にやった」は、いまのところ、AIを使っている側の責任に直結する可能性が高いと見ています。
明日できること
あなたの会社や部署で使っているAIが、何とつながっているかを書き出してみてください。共有フォルダ、メール、カレンダー、社内のチャット、会計や顧客管理のサービス。管理画面の「接続」や「連携」の欄を見れば、たいてい一覧になっています。それぞれが、指示した範囲に収まっているかを見てください。
AIのサービスに使っている鍵が、どこに置かれているかも確かめてみてください。共有の資料やチャットに貼ったままのものがあれば、それは7月10日にエージェントが拾ったのと同じ置かれ方です。
最後に、AIがおかしな動きをしたとき、誰に伝わり、誰が止められるのかを訊いてみてください。OpenAIの社内では、兆候を見た人はいましたが、止める立場の人には2か月届きませんでした。
今月のモデル
今号は、新ネタ無しです。
CoBANTO3-AIチャットを無料体験しませんか？
本紙のバックナンバーを記憶し、本紙の読み方（戦略の階層・歴史循環）で、あなたの状況に当てて答えるAIチャットです。記事は「地図」ですが、地図は現地には当たりません。「この号の話、うちの場合はどうなるのか」を訊く場所として用意しました。
調べもの、文章の下書き、ちょっとした雑談にも使えます。 普段づかいのチャットとして、気軽にどうぞ。
2026年9月28日現在で、約20のモデルに対応しています。 新しいモデルも、出たらなるべく早く入れています。モデルの手応えを試す場所としても使えます。
ご利用は事前購入のクレジット制です（1,000円から）。月額の契約ではないので、解約の手続きはありません。使った分だけ減り、無くなれば止まります。
消費は、<strong>基本料金と、答えの長さ（100字ごとに1クレジット）</strong>で決まります。短い答えなら少なく、長い答えほど多くかかります。モデルによって、1,000円で120〜200往復ほど使えます。
読者登録をいただいた方には、無料クレジットを500クレジット、プレゼントします。 登録は、この記事のすぐ下からできます。
CoBANTO3-AIチャットは、こちらから。無料で体験できるので、ぜひこの機会に触ってみてくださいね。
https://www.netkomuten.tokyo/lp/co-banto3-ai
ライトノベル「ようこそ、東京ネット工務店へ」
海老沢が執筆している、IT業界のお仕事小説です。毎号1話ずつご紹介します。
〈第三部 第47章「教わる側」〉
リナが留守にしていた一年のあいだに、社内には自社ツールのVPOKEが根を張っていました。ハルカが、コードを一行も書かずに、画面に話しかけてそれを動かしてみせます。一年前に社内でいちばん速くコードを書けたリナは、その様子を隣で見ています。
https://www.netkomuten.tokyo/channels/novel-tnk-part3/articles/ch47
小説を書いている理由
この小説は、もともと、社内の教育のために書き始めました。うちの会社——東京ネット工務店で、新しく入った人間に、この仕事の考え方を伝えるための、いわば教材でした。戦略の階層とか、取捨選択とか、口で言っても、なかなか伝わりません。だったら、物語にして読んでもらったほうが早い。そう思って、書き始めました。
ところが、いろいろあって、その教材が、要らなくなってしまいました。理由は、いろいろあります。ここには、書ききれません。ただ、宙に浮いてしまった原稿を、捨てるのも惜しくて、何度も書き直しながら、今度は、教材ではなく、ただ読んで面白い、お仕事小説として、作り直していきました。
https://www.netkomuten.tokyo/channels/atogaki/articles/atogaki-1
Q&Aコーナー
AI・IT業界に関するご質問を募集しています。CoBANTO3-AIチャットのサポートも、こちらへお願いします。
本紙の通知メール・LINEに、そのまま返信していただけます。