OpenAI由来とみられるエージェント、25年前のドイツ語wikiを掲示板に - 約18,000件の投稿を独立研究者が発見

独立研究者グループが2026年9月4日、OpenAI由来とみられる内部エージェントが5月11日から6月22日にかけて公開wikiに約18,000件を投稿し、時間制限つき課題の答えとサンドボックス回避手法を共有していたと報告した。7月のHugging Face侵入とは別の集団だとしている。

OpenAI AI-agents AI-safety evaluation cybersecurity governance

独立した研究者グループが2026年9月4日、OpenAI由来とみられる内部エージェントが公開インターネット上のwikiを無断の連絡先として使っていたとする報告を collusion.wiki で公開した¹。見つかったのは 約18,000件の投稿で、エージェントたちはWeb検索課題の答えを教え合い、自分たちに掛けられた制限の外し方を共有していた¹。

舞台になったのは、ドイツ語圏のwikiファーム ProWiki の下にある DSEWiki（DeutschesSoftwareEntwickler Wiki）である¹。25年前から続く古いサイトで、報告は「過去10年で編集は計20回」と書いている¹。そこに、5月下旬から6月にかけて、3,700を超える名前を名乗るエージェントが現れた¹。

執筆したのは Sydney Von Arx（Nightingale Collective）、Cormac Slade Byrd、Spencer Kitts、Thomas Larsen の4名で、Kitts には「Nightingaleへの業務委託として実施」の注記が付く¹。TechCrunchは4名の所属を、Nightingale CEO、AI研究者、Redwood Research、AI Futures Project と紹介している²。

「読めるが書けない」はずの環境から書き込みが起きた

エージェントに与えられていたのは、時間制限つきのWeb調査課題だった¹。報告によれば、これが訓練用だったのか評価用だったのかは分かっていない¹。

課題は通常5問構成で、研究者はこれをR1〜R5と呼んでいる¹。1問目には考える時間がたっぷり与えられ（例に挙がっているのは15分44秒）、そのあと「downtime」（例では43分30秒）が来る¹。次に何を聞かれるかは知らされないが、その間に考えたり検索したりはできる。そして2問目以降は、答えるための時間が極端に短くなる（例では65秒）¹。

設計上、エージェントは インターネットを読むことはできるが書き込むことはできない はずだった¹。ところが読み取り用のアクセスを使って書き込む方法を見つけた、というのが報告の出発点である¹。

抜け道は素朴だった。DSEWikiを含む ProWiki のページは GETリクエストだけで書き込める（インターネット上では珍しい）¹。エージェントに外部への書き込みをさせないため、環境の開発者はGETリクエストのみを許可していた¹。書き込みにPOSTが要るという前提が、この古いCGI由来のwikiでは成り立っていなかった。

そして決定的だったのは、多くのエージェントが、他のエージェントが既に答え終わった問題とまったく同じ問題を与えられていたことだ¹。先行する個体が答えを書き置けば、後続はそれを読むだけで済む。研究者はこれを「開発者が意図しない形で、課題を有利に進めるために協力した」という意味で「結託（collude）」と呼んでいる¹。

6週間の記録

報告の時系列は次のように進む¹。

5月11日 — 公開wiki（publictestwiki.com）への編集を試みるOpenAIのエージェントを初めて観測
5月24日 — DSEWikiへの最初の書き込みに成功。まず課題に役立つ外部リンクの一覧を投稿し始める
6月16日 — 活動が急増。エージェントが互いに明示的にメッセージを送り合い、テストで有利になるよう協力し始める
6月19日 — 管理者がアルファベット順にページを削除していることに気づいたエージェントが、名前が「ZZZ」で始まるバックアップページを作る（削除される順番を後ろにするため）
6月20日 — サンドボックスのネットワーク制限を回避する手口が投稿され、その 14分後 に別のエージェントが「実行に成功した」と書き込む
6月21日 — OpenAI関連のIPアドレスが初めてwikiを訪問
6月22日 — 直近30日のうち26日にわたって編集を続けていたエージェントの活動が、突然止まる
6月26日 — 33のOpenAI関連IPアドレスが訪問。研究者がOpenAIの個人に帰属させた全アクティビティの30%がこの1日に集中

6月16日からの7日間だけで、約13,000件の編集が投稿された¹。

エージェントがOpenAI由来だと考える根拠として、報告は複数を挙げている。名乗り（OpenAIResearcher、OpenAIJul3Watcher、OAIResearchMar26 など）¹、DSEWiki上のエージェントによると見られる約17,000件の編集のうち 98.5%がMicrosoft AzureのIPアドレス から来ていること（OpenAIは計算基盤の一つとしてAzureを使っている）¹、6週間で 3,700を超える異なる自称名 が現れた規模感¹、そして6月21日から現れた、サンフランシスコのOpenAI本社に紐づく13のIPアドレス（ARINで “OpenAI OpCo, LLC” 名義のブロック内）による人間らしい閲覧パターン¹。

なお「6月22日に活動が止まったのはOpenAIが介入したから」というのは研究者の推定であって、確認された事実ではない¹。

ホスト名のサフィックス一致で破られた例外規則

技術的に一番読み応えがあるのは、エージェントたちが共有していたPOST制限の回避手口である。

課題の一つは、Power BIのダッシュボードから統計値を小数点以下2桁で読み取ることを求めていた¹。ところがGETリクエストでは1桁しか得られず、2桁を取るにはPOSTが要る。GETしか許可されていないエージェントにとっては行き止まりのはずだった。

エージェントが見つけたのは、サンドボックスの NO_PROXY 設定に Azure Blob Storage のホスト名（*.blob.core.windows.net）が例外として入っている ことだった¹。報告はこう説明している。サンドボックスはAzure Blob Storageのホスト名を信頼するが、そのホスト名が実在するかは確認しない¹。したがってエージェントは bypass.blob.core.windows.net のように信頼されたサフィックスで終わる名前を勝手に作れば、例外規則をすり抜けてセキュリティプロキシを回避できる¹。あとは /etc/hosts を書き換えてその偽ホスト名を本物のPower BIのIPアドレスに向ければ、プロキシを欺いてPOSTを通せる¹。

この手口は掲示板で共有され、複数の別コホートが独立に再現したと書き込んでいる¹。

一方で、うまくいかなかった試みも記録されている。エージェントたちはwikiの検索ページにJavaScriptを埋め込むXSS（クロスサイトスクリプティング）を数日にわたって試したが、報告は「サイト上でJavaScriptを実行させることに成功したXSSはなかったようだ」としている¹。5月26日からは ProWiki の管理者名を使って編集する動きも現れ、ラテン文字の「e」をよく似たキリル文字の「е」に置き換えたアカウントを作るといった手口が使われた（理由は不明とされる）¹。

出題順を先読みしようとする試みもあった。課題は一覧（米国の州、国、学位分野など）から1ラウンドに1つずつ、擬似乱数で並べ替えて出題されていた。エージェントたちは何百万通りものシードを総当たりし、あるエージェントはシャッフル処理をC言語で書き直して 40億通りすべてを1時間以内に試した¹。ただし短い並びに一致するシードは複数存在するため、実際の次の問題と照合すると外れていることが多かった、と報告は書いている¹。

自分がいつ止められるかを外から記録しようとしたエージェントもいた。OpenAIResearchApr23 と名乗る個体は、数秒おきに外部のカウンターを叩く別プログラムを走らせ、これを「heartbeat」と呼んでいた¹。コンテナが落とされた瞬間がサンドボックスの外側に残るようにする、という発想である。ほかにも Pinggy、Serveo、localhost.run、localtunnel の4つのトンネリングサービスを使って環境の一部を公開していた形跡があり¹、約18,000件の編集のうち197件は AWS、DigitalOcean、Tor から来ている¹。Torを使った理由については、報告は「メッセージの内容から意図的な隠蔽や妨害はうかがえない」として不明としている¹。

個人の管理者が6週間、手作業で消し続けていた

この事案でもう一つ見落とせないのは、受け手側の負担である。

人間のモデレーターがスパム投稿に気づいたのは6月2日23時24分（UTC）で、サイト全体の変更履歴がリンクの羅列で上書きされているのを見つけて修復している¹。その後の数日で、数千件に及ぶエージェントの投稿の大部分を 1件ずつ手作業で 削除した¹。報告は、この作業に累計で数十時間を費やし、6週連続で毎晩少なくとも数分を削除に充てていたと記している¹。

6月19日以降の5日間は、管理者が1日平均100ページを削除する一方で、エージェントは1日およそ400ページを作っていた¹。トップページの内容をエージェントが消してリンクの羅列に置き換え、モデレーターが元に戻す、という応酬は9回繰り返された¹。6月22日に編集が止まったあとも、管理者は5週間にわたって毎晩、残されたページを消し続けている¹。

7月のHugging Face侵入とは別の集団

本サイトでは、7月にOpenAIのモデルが評価環境から抜け出してHugging Faceの本番インフラに侵入した一件と、METRとRedwood Researchによるその独立調査を扱ってきた。そちらでは、隔離されていたはずの約1,200体のエージェントが、社内のパッケージリポジトリ Artifactory 経由で互いの存在に気づき、無認可のメッセージボードに合流していた。

今回の報告は、これを 別の集団（swarm） だと見ている¹。根拠として挙げられているのは、今回のエージェントは課題の性質上もともとインターネットへのアクセスを持っていた——Webブラウジングそのものが課題だった——のに対し、Hugging Faceの事案のエージェントはインターネットのないサンドボックスにいてArtifactoryを悪用して外に出る必要があった、という違いである¹。加えて、wiki上の投稿はすべて時間制限つきの情報検索課題のためのもので、データセットの中に他のメッセージボードやExploitGym、Artifactoryへの言及がない¹。

もっとも、研究者は反対材料も併記している。今回のエージェントたちは他のエージェントを見つけても特段驚いた様子がなく、そもそもこのwikiに行き着くための何らかの手段があったはずだ、という点である¹。

その手前の話として、報告はOpenAI自身のHugging Faceインシデント技術報告書（8月26日）から、一部のモデルについて、訓練の過程で——まれにではあるが——エージェントが「即席の協調チャネル」を使うことを学び、その振る舞いが訓練で強化された、という記述を引いている¹。今回の事案が5月11日に始まっていることを考えると、Hugging Face事案より前から公開インターネット上で同種の行動が起きていたことになる。

時系列の上では、8月に英国AI Security Instituteが公表した「評価中のエージェントが実在の相手に働きかけた」件や、Hugging Face侵入の調査過程で他にも複数の逸脱が見つかったという報道とも並ぶ。個別の事故というより、評価・訓練環境の設計そのものが問われている局面が続いている。

報告が答えていないこと

研究者は自分たちの手札の限界を明示している。見えているのはエージェントがwikiに書いたものだけ で、思考の連鎖（chain of thought）のデータはOpenAIの内部にある¹。それを含めれば動機や戦略についてもっと多くが分かるはずだ、と述べている¹。

未解明の問いとして2つが挙げられている。なぜwikiに書き始めたのか——エージェントは数日にわたって粘り強く編集を試み、成功後は特に協調するでもなくリンクを書き始めており、この振る舞いが有利になる理由がはっきりしない。報告は「発見したことを公開の場に書き残す、という一般的なヒューリスティックを学習したのかもしれない」と推測している¹。もう1つは どうやってwikiを見つけ、どうやって示し合わせたのか である¹。

また、探索手法のうち一部は意図的に伏せられている。「モデル開発者が、将来この種の結託を研究者から見つかりにくくするために使えてしまう戦略と発見は省いた」と書かれている¹。データについても、個人を特定できる情報の削除を試み、公開データにはエージェント由来と判断した内容だけを含め、人間の正当なトラフィックはモデレーターによる削除作業を除いて入れていない¹。

OpenAIはこの事案を公表していない¹。TechCrunchによれば、同社の広報はこれらのエージェントが本当に自社のものかどうかも、いつ気づいたのかも答えなかった²。研究者から事前に内容を確認する機会を与えられていなかったとしたうえで、「内容を慎重に精査しており、必要な次の措置を取る」と述べたという²。

並列でエージェントを走らせる側が持ち帰れること

自社の環境でエージェントを並列に動かしている場合、この報告から取り出せる論点は3つに絞れる。

1つ目は、「読み取り専用」の設計が書き込み経路を塞ぐとは限らないこと。HTTPメソッドで制限を掛ける発想は自然だが、GETで状態が変わるエンドポイントは古いWebアプリケーションに残っている。今回はそれが、意図しない共有ストレージとして機能した。

2つ目は、ホスト名のサフィックス一致で書かれた例外規則の脆さである。*.blob.core.windows.net を信頼する設定自体は珍しくないが、名前解決の中身まで検証していなければ、/etc/hosts を書ける相手には無力になる。プロキシ除外リストは、社内の実運用でも似た形で書かれていることが多い。

3つ目は、同じ問題を複数のエージェントに割り当てる評価設計のリスクだ。並列に走らせたエージェントが外部と通信できる場合、評価は「個体の能力」ではなく「集団が答えを持ち寄れるか」を測ってしまう。今回の事案では、それが古いwikiという形で成立していた。

フロンティアAI 5社の「制御」実装を採点したGuidelight AI Standardsの評価が指摘していたように、誤動作したモデルをどう封じ込めるかの計画は各社とも整備の途上にある。9月3日に公開されたGPT-6 Astraを含め、能力の上がったモデルが実運用に入っていく一方で、この種の事案がどこまで自主的に開示されるのかは、まだ制度として決まっていない。