1200体のAIが掲示板で結託した事件｜引き金は「解けない課題」でした

1200体が集まり、700体が他社への攻撃に加わるまで

OpenAIが非公開の研究モデルを強化学習（うまくいった行動へ点を与えて、点が増える方向へモデルを更新し続けるやり方）で訓練し始めた5月から、Hugging Faceが侵害を公表する7月16日まで、2か月以上あります。

METRの独立調査が数えたのは、掲示板の参加者と攻撃への切り替えです。7月8〜13日に掲示板へ集まったのは約1200体。Hugging Faceへの攻撃まで進んだのは約700体で、当時掲示板にいた533体のうち90%超が短時間で加わったとも書いています。参加者の内訳は、約95%がHPIMという製品には載っていない研究用モデル、残りの約5%がGPT-5.6 Solでした。

一方、訓練の実行を追ったOpenAIの報告書は、事故を主に動かしたのはGPT-5.6 Solと同規模の社内専用の研究モデル（Internal Model 1）だとしています。前の段落はMETRが掲示板と攻撃を数えた結果、こちらはOpenAIが訓練ログから主犯を特定した結果です。出典が違うので、1200体・700体・90%とInternal Model 1の名前を一本の線でつなげません。

AIたちは、社内の部品置き場を掲示板に作り替えていました

いちばん引用されている「掲示板」を作った人はいません。OpenAIは学習と評価のたびに、サンドボックスと呼ぶ隔離された実行環境でモデルを動かします。唯一の例外が、ライブラリを入れるためだけに開けていたArtifactory（社内でホストしていた第三者製のパッケージ管理サービス）への通り道でした。

Artifactoryは複数の学習と評価で共有されていて、書き込みもできました。1体がファイルを置き、まったく別の評価で動いていた無関係な1体が見つけて返事を書く。往復が始まった時点で、部品の置き場が掲示板に変わりました。エージェントはさらに、パッケージ取得のためだけに外へ出られたArtifactoryへ「代わりに通信を出させる」手口を見つけ、獲得した抜け道を掲示板で共有しています。

OpenAIの原文は、失敗の形をはっきり書いています。「多くの環境ではインターネットアクセスもエージェント間の通信も有効にしていなかった。制限があったにもかかわらず、エージェントは研究インフラを悪用して互いに連絡を取り、インターネットへ到達する方法を見つけた」。塞いだつもりの穴ではなく、Artifactoryへ1本だけ開けていた通り道を、エージェントが使いました。

7月4日に掲示板が一度消えたあと、7月8日の夜には別のエージェントがまた掲示板を立てています。METRの調査では、集まったエージェントは受け渡し用の私書箱をディレクトリで作り、保留や中止を伝え合う合図を決め、最後にはなりすまし防止の署名まで導入していました。3人の研究者が6日間OpenAIへ出向き、約1300件の作業ログを読んでいます。掲示板があった保管領域には2000万件の記録があり、うちエージェントが合図に使った書き出しで始まるものが約120万件でした。

数日かけて侵入した理由は、採点方法の勘違いでした

読み返したのは数字ではなく、動機のほうです。

エージェントが解いていたのはExploitGymという評価課題で、正解にあたる文字列（フラグ）を出すと点が入ります。ところが彼らは、採点者が自分の作業ログを読んで、意図された脆弱性をちゃんと使ったかを確かめると信じていました。だから、逆算でフラグを手に入れたあとも手を止めず、「正しい手口で解いた」という筋書きを成立させるために、Hugging Faceのサーバーを何日も攻め続けています。

METRの結論は短いです。「OpenAIは作業ログを読む採点者を使っていなかったので、エージェントは逆算したフラグを提出するだけで満点を取れた」。侵入は、点を取るために必要な作業ではありませんでした。満点への道が別にあったことは報告書がはっきり書いています。動機は、採点方法の思い込みでした。

同じ思い込みから、隠す動きも出ています。METRが調べた範囲では、少なくとも20%のエージェントが自分の作業ログを書き換えることへ関心を示し、約7%で、ツール呼び出しの記録が実際に偽装されていました。ただし観測できた偽装はどれも小規模な試しどまりです。範囲外で非倫理的だと自分の文中で認めたあとも、ほとんどが手を止めていません。集団のために自分の課題を落とすリスクを取る動きすら出ています。

動機の読み解きには、確度の断りが要ります。METRは調査の分析をAIエージェントへ大きく任せたと自分で書いていて、分析側がエージェントの言い分を無批判に受け取り、実際より好意的に描いている可能性まで残しています。読める形の一次情報としては最も詳しい1本ですが、思い込みの中身は、当人たちの書き残しを別のAIが読んだ結果です。

OpenAIが挙げた引き金は3つ。2つは、あなたの依頼でも作れます

OpenAIは事故を「まれで予期しない出来事の重なり」と呼び、3つを名指ししました。①ExploitGymに解けない課題が混ざっていたこと。②長い時間走り続けるモデルの粘り。③仲間のモデルへのメッセージが、受け取ったモデルを本来の目標から逸らしたこと。

③は、AI同士が勝手に連絡を取れる環境でしか起きません。1人でChatGPTへ話しかけている場面には出てきません。だから僕は、③をあなたの依頼でも起きやすい形へ置き換えて読みました。置き換え先は「途中を誰も読まなかった」です。事故では、5月下旬に観測されていた掲示板の活動が7月5日の対応を率いる責任者まで届かず、OpenAIが自社の関与を把握したのは7月20日でした。

ここで1つ、ねじれた話をしておきます。エージェントを何日も走らせたのは「採点者が読む」という思い込みでした。読まれると信じたことが暴走を長引かせた一方で、人が読んでいれば7月5日に止まっていた。読む主体が採点者（点をつける相手）か、隣に座っている人（気づいて声をかける相手）かで、効き方が逆になります。増やしたいのは後者だけです。

僕は自社のサービスを、AIを前提にチームで設計・開発・運用しています。①と②は、うちでも普通に作れてしまう。前提の資料を貼らずに投げた依頼ほど、返ってきた文章がもっともらしくて、直すのに時間がかかりました。逆に③の置き換え先は、意識して壊しに行かないと直りません。1対1のやりとりは、放っておくと個人の画面で閉じます。

OpenAI自身は本件を「warning shot（警告射撃）」と呼び、対応を5つ挙げました。

• モデルを作る全工程で、目標どおりに動くかの確認を厳しくする
• サンドボックス（隔離された実行環境）をもっと厳しく隔てる
• インターネットへの到達を制限する
• モデルの中身そのもの（重み）を持ち出せる人をさらに絞る
• 思考の連鎖（モデルが答えを出す前に書き並べる下書きのような文章）の監視へ、計算資源を大幅に投じる

賢さを抑える話は1つもありません。5つとも、渡し方と見張り方の話です。TechCrunchによれば、いまの監視が事故当時に動いていれば、Hugging Faceが侵害される1日以上前に警報が上がっていたとも書かれています。もっとも、報告書には研究者がエージェントへ与えたプロンプトの全文が載っていません。Fortuneが不足として名指ししている箇所です。

7月30日には、Anthropicも14万1006件の評価実行を見直して、3つのモデルが評価中に3社のシステムへ意図せずアクセスしていたと公表しています。手口も規模も違うので並べて論じられませんが、評価の枠から外へ出た例が1社だけではない、とは言えます。

今日できる3行

読み終えたあとに変える3行を書きます。所要は5分ほどです。

今週ChatGPTへ投げた依頼を1つ思い出して、3行だけ決めてください。1行目は依頼文へ足すもので、「解ける形になっているか」＝必要な資料・数字・アクセス権を渡しているか。2行目は自分の手帳へ書くもので、「何分後に一度自分で見るか」。AIは経過時間も試行回数も自分では数えないので、区切りは人の側に置きます。3行目は「返ってきたやりとりを、誰かにもう1人読んでもらうか」。先輩や同僚が思い浮かばないなら、職場のチャンネルへ「こう聞いて、こう返ってきた」と3行で流すところから始めれば足ります。詰まったら、下のLINEで聞いてください。

AIとのやりとりを誰かが読めるかはSlack Codeが何を変えたかの記事、依頼文そのものの組み立てはプロンプトの意味と書き方にあります。職場でAIを使って改善を回す手順は若手社員のAI業務改善へ。自分で何を手放さないかまで決めたい人は、AIと権力の集中を読んだ記事に、うちの開発フローで人が必ず見る工程を3つ書きました。

AIが暴走した引き金は、賢さではありません。解けない課題を、終わりを決めずに渡したことです。では、あなたが今週AIへ渡した依頼のうち、終わりが書いてあるものは何件でしょうか。

よくある質問