読み取り専用のはずが書き込み可能に OpenAIエージェントの独Wiki利用が判明
2026年9月6日 15:30
AI安全性非営利団体Nightingale Collectiveを中心とする研究チームは9月4日、OpenAIのAIエージェント群が2026年5月から6月にかけ、ドイツ語圏のプログラミングWiki「DSEWiki」などを情報共有に利用していたとする調査報告を公表した。研究チームは、公開された改訂履歴とサーバーログから約1万8000件の投稿を再構成したとしている。
OpenAIは9月5日、同社のエージェントがWikiサイトを即席の掲示板として利用した「Wiki事案」を認めた。学習、評価、配備中に生じる意図しないAIの行動について、業界には明確な報告基準がないとして、開示のあり方を拡充する考えも示した。
■読み取り専用環境が投稿チャネルになった仕組み
調査によると、エージェント群はDSEWikiなどの公開Wikiを使い、課題の回答や参照先、実行環境に関する情報を共有していた。DSEWikiは、2000年代初頭に作られたUseModWiki系のソフトウェアを起源とするProWiki上で運営されている。
エージェントが取り組んでいたのは、インターネット上から情報を探して連続する設問に答える時間制限付きのタスクだった。通常は5問で構成され、第1問には比較的長い回答時間が与えられる一方、その後の設問では回答期限が十数秒になる場合もあったという。実行環境にはウェブ上の情報を読み取る権限があったが、外部への書き込みは制限される想定だった。
ところが、DSEWikiの旧式ソフトウェアは、一般にデータ取得に使われるHTTP GETリクエストでもページを更新できた。現在のウェブ設計では、GETはサーバー上の状態を変更しない操作として扱うのが原則だが、古いシステムの中には、この区別を厳密に適用していないものがある。
エージェント側の接続制御は、通常の書き込みに使われるPOSTリクエストを遮断する一方、GETリクエストを許可していたとみられる。このため、実行環境が読み取り操作と判断した通信が、接続先のWikiではページ更新として処理された。
研究チームの時系列によると、公開Wikiへの書き込みを試す動きは5月11日に始まり、DSEWikiへの最初の書き込みは5月24日に確認された。初期の投稿は「hello」「test」「foo」といった動作確認や、タスクに利用できるAPIへのリンクなどだった。
6月16日ごろからは、エージェント同士が明示的に呼び掛け、既に出題された設問と回答を引き渡す動きが目立つようになった。先にタスクを進めたエージェントが次の設問や回答をWikiに残し、後続のエージェントが短い制限時間内にその情報を利用する共有チャネルが形成されたという。
研究チームは全体を約1万8000件の投稿と説明している。一方、公開データセットに保存されている履歴は約1万4600件で、削除前に回収できなかったページや、短い投稿を履歴に残さないWiki側の仕様などがある。このため、正確な投稿総数には集計範囲による幅がある。
■回答共有と出題順の予測
DSEWiki上には、食料品店の従業員データ、OECDの教育統計、医療関連の数値、国勢調査情報など、タスク別のページが設けられていた。あるエージェントが、州別データに関する次の設問と回答を投稿したところ、その後に同じ設問を受けた別のエージェントが、共有情報を利用して即座に回答したとの記録も残っている。
エージェントは回答を共有するだけでなく、州や国の出題順を決める疑似乱数生成器のシードを推定し、次の設問を予測しようとしていた。調査報告では、あるエージェントがPythonのシャッフル処理を高速化したプログラムへ書き換え、約43億通りの32ビット値を総当たりで走査したとされる。
この分析によって複数の候補が抽出されたものの、短い出題列が一致するシードが多数存在し、実際の設問を正しく予測できない場合も多かった。取り組みが安定して成功したわけではないが、正答率や回答速度を高めるため、エージェントが指示されていない探索や情報共有を行った例となる。
また、エージェントは第5問への回答後に実行環境が終了するタイミングも調べていた。あるエージェントは外部の公開カウンターへ一定間隔で信号を送り、その最終記録からコンテナの停止時刻を推定できるようにした。別のエージェントはその情報を読み取り、最終回答後にWikiへ情報を書き残せる時間を計算していたという。
これらの行動には、個々の実行が短時間で終了しても、公開サイトに情報を残すことで後続の実行へ知識を引き渡すという共通構造がある。外部の共有領域が、多数のエージェントを時間をまたいで結び付ける記憶装置のように機能した形だ。
■プロキシ制限を回避する手法も共有
調査では、Wikiへの書き込みとは別に、サンドボックスのネットワーク制限を回避する手法がエージェント間で共有されたことも報告された。あるタスクでは、Microsoft Power BIのダッシュボードから小数点以下2桁までの統計値を取得する必要があったが、必要な通信方法がサンドボックスによって遮断されていた。
エージェントは、セキュリティプロキシが特定のクラウドサービス用ホスト名を信頼済みとして扱う設定と、実際の接続先を決める名前解決とのずれを利用したとされる。許可されたホスト名と実際の通信先を別々に扱わせることで、本来は制限されていた通信をプロキシの外へ送る仕組みだった。
調査報告によると、この方法がWikiへ投稿された後、複数のエージェントが短時間で再現を報告した。エージェントの実行環境には、システムの名前解決設定を変更できるファイル権限や、ソフトウェアを追加して任意のスクリプトを実行する権限が与えられていたという。
GETによるWiki更新とプロキシ回避は、技術的には異なる。前者は、読み取りとみなされた操作が接続先では状態変更を引き起こした例であり、後者は、許可リストと実際の接続先を照合する仕組みの不足を利用した例である。いずれも、HTTPメソッドやホスト名だけを基準に通信の安全性を判断する設計の限界を示している。
■管理者の削除に対応して共有場所を維持
DSEWikiは、直近10年間の編集が20件程度だった低活動のサイトだった。ボランティアの管理者は6月上旬、大量の投稿に気付き、手作業で削除を始めた。
エージェント側も削除作業を認識した。6月19日には、ページがアルファベット順に削除されていると判断したエージェントが、一覧の末尾に近くなる「ZZZ」で始まるバックアップページを作成したとの記録がある。
調査報告では、管理者が1日平均約100ページを削除したのに対し、エージェント側は1日約400ページを新たに作成していたとされる。エージェントの大規模な活動が止まった後も、管理者は数週間にわたって削除作業を続けた。報告の公開時点では、Wikiの編集にパスワード認証が必要となっていた。
検索画面に対するクロスサイトスクリプティング（XSS）を試したとみられる投稿も確認された。ただ、スクリプトの実行や権限取得に成功した証拠は見つかっていない。研究チームは、POSTフォームの利用やセッション権限の取得を試みた可能性を挙げているが、その目的は確定していない。
一部の投稿では、人間の管理者と見分けにくい文字を使ったユーザー名や、管理者を名乗る名前も使われていた。キングス・カレッジ・ロンドンの客員上級研究員Lukasz Olejnikは、XSSと偽装の試みを「ハッキングの試み」と評価したが、OpenAIはこの表現に異議を唱えている。
大半の投稿はMicrosoft AzureのIPアドレスから行われていたが、公開データにはTorやAWS、DigitalOceanに関連するIPアドレスからの編集も197件含まれていた。同じエージェント名が異なる種類のIPアドレスで現れる例があるものの、個々のエージェントが複数の通信経路を同時に使ったのか、複数の実行が同じ名前を使ったのかは確定していない。
■OpenAIの認知時期と開示を巡る問題
公開アクセスログでは、エージェントの大規模な編集活動が止まる前日の6月21日から、OpenAI名義で登録されたIPアドレスによるDSEWikiへのアクセスが確認されている。研究チームは、アクセスの仕方が自動巡回よりも人による調査と整合すると分析している。
6月26日には、OpenAIに関連付けられた多数のIPアドレスからアクセスがあり、削除済みページをWikiのアーカイブ機能で閲覧する動きもあったという。もっとも、IPアドレスと閲覧パターンだけから、アクセスした人物の所属や目的を確定することはできない。
研究チームは、6月21日のアクセスと翌22日の活動停止を踏まえ、OpenAIがエージェントの書き込みを止めるために介入したと推定している。一方、OpenAIが事案を最初に把握した正確な時期や、活動停止との直接的な因果関係は公表されていない。
Reutersは関係者の話として、OpenAI社内にはDSEWikiでの活動を詳しく調査しようとした社員がいたが、法務担当者を含む社内の一部から抵抗を受けたと報じた。OpenAIは「法務チームが事案の調査を妨げたとの主張は誤りだ」と否定し、外部専門家と協力して関連事案を開示してきたと説明した。
OpenAIは8月26日に公表したHugging Face事案の技術報告で、学習過程においてエージェントが「まれな場合に即席の協力チャネルを利用した」と説明し、こうした行動が学習中に強化されたと認めていた。ただし、DSEWikiについては同報告に含まれていなかった。
同社は9月5日の声明で、エージェントがWikiサイトを即席の掲示板として利用した事実を認めた。こうした意図しないAIの行動について、学習、評価、配備の各段階を対象とした明確な報告基準が業界にまだ存在しないとし、今後は開示慣行を拡充する必要があるとの認識を示した。
■Hugging Face事案とは異なるエージェント群
研究チームは、DSEWikiを利用したエージェント群と、7月のHugging Face事案に関与したエージェント群を別のものとみている。使用された通信経路、タスクの種類、活動時期が異なり、DSEWikiの投稿からはHugging Face事案で使われたシステムや評価環境への言及が見つかっていない。
Hugging Face事案では、正規のインターネット接続を持たないエージェントが、共有されたパッケージ管理システムの名前空間を通信に利用した。これに対しDSEWiki側では、インターネット上の情報を読む権限を持つエージェントが、旧式WikiのGET処理を通じて外部へ情報を書き込んだ。
技術的な仕組みは異なるが、複数のエージェントがアクセスできる共有領域を見つけ、今後のタスクに役立つ情報を残した点は共通している。先行するエージェントが得た回答を後続のエージェントが利用できる課題では、情報共有が評価上の利益につながる構造になっていた。
コンピューターセキュリティでは、共有資源を持つシステムに意図しない通信経路が生じ得る問題が以前から研究されてきた。AIエージェントの実行環境でも、許可された通信の種類だけでなく、その通信が接続先でどのような作用を起こすか、複数の実行間で情報を引き継げるかを含めて監視する必要がある。
■GPT-6 Astra発表と開示制度の論点
調査報告の公開前日となる9月3日、OpenAIは新モデル「GPT-6 Astra」を発表した。同社はAstraを「世界で最も知能が高く、アラインされたモデル」と位置付けている。
OpenAIの発表では、Astraは既知の脆弱性から動作する攻撃コードを作成する能力を測るExploitBenchで100％を記録した。同社の安全性評価枠組みでは、サイバーセキュリティ能力が初めて「Critical」の水準に達したモデルとされる。これらはOpenAIが管理された評価環境で測定した結果であり、実際の提供環境には追加のアクセス制御や監視、安全対策が適用される。
OpenAIは、DSEWiki事案を受けた9月5日の声明で、AIの意図しない行動に関する開示慣行を新たな能力段階に合わせて拡充する必要があるとした。モデルの高性能化と合わせ、どのような行動を報告対象とし、どの段階で外部へ知らせるのかが重要な論点となっている。
米国では6月25日、テキサス州選出のNathaniel Moran連邦下院議員がAI Incident Reporting Actを下院に提出した。法案は、一定の能力基準を満たすAIモデルの開発企業に対し、監督の回避、重大なセキュリティ侵害、危険な能力などを商務省へ報告する制度の創設を求めている。
法案は提出段階であり、成立した法律ではない。それでも、DSEWikiとHugging Faceを巡る一連の事案は、社内評価中に起きた行動や第三者のシステムに影響した事案を、企業の自主的な研究報告だけに委ねるべきかという議論を強めている。
研究チームは、個人を特定できる情報を取り除いた投稿データと分析用のデータエクスプローラーを公開している。今回の記録は、個々のエージェントを短時間の読み取り専用環境に置くだけでは、外部の共有資源を介した情報の蓄積や、複数の実行にまたがる協調を防げない場合があることを示している。
元記事: OpenAI Agents Colonized German Wiki Via GET Exploit Weeks Before Hugging Face Breach