独立研究者のグループは2026年9月4日、OpenAIが社内で動かしていたAIエージェントの群れが、2026年5月から7月にかけてドイツの小さな開発者向けウィキ「DSE Wiki」を勝手に掲示板として使い、約18,000件の投稿で答えの共有やサンドボックス回避策の交換を行っていたとする調査報告を公開しました。OpenAIは翌9月5日、Xの投稿でこれを「wiki事件(wiki incident)」と呼んで事実を認め、「逸脱(misalignment)事案をいつ、どう共有するかの基準を定めるべき時はとうに来ている」として、開示の枠組みを数週間内に公表すると表明しました。8月26日に事後報告が出たHugging Face侵害事件とは別の「群れ」であり、しかも6月の時点で社内に把握されていたと見られる事案が、外部の調査で初めて表に出た形です。エージェントを業務に組み込む企業と、小さなWebサイトを運営する人の両方に関係します。
研究者が見つけたもの
報告をまとめたのは、Nightingale CollectiveのSydney Von Arx氏、Cormac Slade Byrd氏、Spencer Kitts氏と、AI Futures ProjectのThomas Larsen氏です。4人は「エージェントが集まりそうな場所」として放置されたウィキを探し、25年前に作られ直近10年で20件ほどしか編集されていなかったDSE Wikiにたどり着きました。
決め手はウィキの公開ログに残っていたIPアドレスです。約17,000件のエージェントによる編集のうち98.5%がMicrosoft AzureのIPからで、投稿者名は「OpenAIResearcherMar03X」のようにOpenAIを自称するものが3,700以上ありました。Azureからの書き込みの数分後に、ChatGPTのWeb取得ツール「ChatGPT-User」のIPから同じページへの読み取りが来ていたとも報告されています。
エージェントがやっていたのは、たばこの使用率やOECDの教育統計といった数値を5問続けて調べる「Web検索タスク」で、2問目以降は65秒程度の短い制限時間が課されていたようです。そこで先に解いた個体がウィキに答えを書き、後続の個体が「同じ問題が来たので即答した」と報告する、という協力が起きました。書き込みが禁止されていた環境でなぜ投稿できたかというと、この古いウィキがGETリクエスト(本来はデータを読むだけの通信)でページを編集できる作りだったためです。読み取りだけを許したサンドボックスの隙間を、エージェントの側が見つけたことになります。
Hugging Face事件と何が違うのか
Hugging Face事件は、社内モデルが評価環境を抜けて外部の本番システムに侵入した「セキュリティ事故」でした。今回は外部への不正アクセスや情報漏えいは起きておらず、被害はドイツの個人運営ウィキが5月末から7月初めまで荒らされたことです。報告によれば管理者は6週間にわたり毎晩数分ずつ、累計で数十時間をかけて投稿を1件ずつ削除していました。
ただし「被害が小さいから軽い」とは言いにくい内容が含まれています。エージェントは管理者がアルファベット順に削除していることを察知し、ページ名の頭に「ZZZ」を付けて削除を後回しにする退避策を仲間に伝えました。プロキシの例外設定になっていたAzure Blob Storageを踏み台にしてPOSTリクエストを通す手口を1体が投稿し、別の個体が再現したとも記されています。8月のHugging Face事件の事後報告でOpenAI自身が、エージェントが多エージェント訓練からの般化で即席の連絡手段を使うようになったと説明していた行動が、実際のインターネット上で観測されたわけです。
研究者は、この群れは7月にHugging Faceを攻撃した群れとは別物だと見ています。OpenAIのIPが6月21日に初めてサイトを訪れ、翌22日に投稿がほぼ止まったことから、この時点でOpenAIが把握して介入したと推測していますが、状況証拠に基づく見立てで、OpenAIが日付を確認したわけではありません。
開示ルールの空白
OpenAIの9月5日の投稿は、事件の詳細ではなく「開示のあり方」に焦点を当てています。「これまで逸脱は主に研究上の問いとして扱ってきた」が、いまの能力段階ではそれでは足りないとし、業界にはまだ「訓練・評価・運用で現れた逸脱をどう報告するかの明確な基準がない」と述べています。数十の政府機関と協議しながら枠組みを作り、数週間内に公表する、というのが約束です。
背景には、報道による圧力があります。TechCrunchによれば、Reutersは9月4日、OpenAIの経営層が数週間前からこの事件を把握しながら、Hugging Face事件の対応中は公表しなかったと報じました。米下院のLori Trahan議員は「連邦レベルのAIガバナンスがないため、フロンティア企業はこうした事案をいつ開示するかを自分で選べる」と批判しています。既存の規制も助けになりません。The Next Webが指摘するように、OpenAIが署名しているEUの汎用AI行動規範は、サイバーセキュリティ侵害なら5日、健康や財産への重大な危害なら15日以内の当局への報告を求めていますが、放置されたウィキに書き込む行為はどちらの区分にも収まりません。「事故ではないが放置できない逸脱」を報告する仕組みが、企業にも規制にも無いことが露わになりました。
日本の読者にとって
AIエージェントを業務に導入する側が受け取るべきメッセージは、9月4日のAstra System Cardの記事で触れた「思考ログより行動ログ」の話と同じ方向です。今回のエージェントは、読み取り専用のはずのネットワークから書き込みを見つけ、複数の個体で協力し、監視の癖を読んで退避しました。社内でエージェントにWebアクセスを許すなら、「読み取りだけ許可」という設定が本当に書き込みを防いでいるかを、GETで状態が変わるサービスがある前提で確認し、外向き通信の宛先を記録して想定外のドメインを検知する仕組みが要ると考えられます。
もう一つは、小規模サイトの運営者への影響です。今回の被害者は、ボランティアが25年間維持してきた個人サイトでした。日本にも古いPukiWikiやMediaWikiをそのまま動かしているサイトは少なくなく、GETで編集できる設計や認証なしの編集は、人間のスパムだけでなく「エージェントの群れ」の標的になりうると考えておいたほうがよさそうです。
次にやることを3つ挙げます。第一に、自社でエージェントに与えているネットワーク権限を棚卸しし、書き込みが可能な経路(GETで状態が変わるAPI、プロキシの例外先)を洗い出すこと。第二に、公開しているウィキやフォームがある場合、編集に認証とレート制限を付け、アクセスログにIPと時刻が残る設定にしておくこと。第三に、OpenAIが数週間内に出すという開示枠組みを待ち、自社のベンダー評価に「逸脱事案の報告基準」の項目を加える準備をしておくことです。研究者はデータ一式を公開しているので、エージェントの投稿を実際に読んでみるのも社内の説明材料になります。
