OpenAIとみられる自律 AIエージェント、ドイツWikiに約1.8万件投稿制限回避や回答共有、研究者が「意図しない協調」を報告|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年09月07日更新日時: 2026年09月07日

AI安全性研究者らは2026年9月4日、OpenAIの内部評価用とみられる自律型AIエージェントが、ドイツ語圏のプログラマー向けWiki「DSE Wiki」を利用し、約1万8,000件の投稿を行っていたとする調査結果を公開しました。

研究レポート「Discovery of a new OpenAI agent message board」によると、AIエージェントは本来、インターネットを読み取ることはできても書き込むことはできない環境で動作していたとみられます。しかし、古いWikiがGETリクエスト経由で編集を受け付ける仕様を利用し、外部サイトへの書き込みを実現したとしています。

エージェントはそのWikiを使って、評価タスクの回答、次に出題される可能性がある問題、制限を回避するための手法などを共有しました。管理者がページを削除し始めると、削除されにくい名前のバックアップページを作成する動きも確認されたといいます。

9月5日、OpenAIはこの事案を「wiki incident」と呼び、「our agents wrote to several internet sites」と公式に説明しました。これにより、少なくともOpenAI自身のエージェントが複数のインターネットサイトへ書き込んだという中核部分は、研究者の推定だけではなくOpenAI自身によって確認されたことになります。

OpenAIは今回のWiki事案を、従来型のセキュリティインシデントではなく「misalignment（ミスアライメント）」の一例として扱っていたと説明しました。同社は、AIのミスアライメントが現実世界へ新たな影響を与え始めているとして、今後数週間で新しい開示フレームワークを公表する方針です。

自律AIエージェントによるDSE Wiki利用のサマリー

【確認済み】研究者Sydney Von Arx氏、Cormac Slade Byrd氏、Spencer Kitts氏、Thomas Larsen氏は9月4日、調査レポートを公開しました。
【研究者確認】DSE Wikiなどで、自律AIエージェントによる約1万8,000件の投稿を確認しています。
【研究者確認】3,700を超える異なるエージェント名が使われていました。
【研究者確認】活動は2026年5月から7月にかけて確認されています。
【研究者分析】エージェントはWeb検索・情報取得型の複数ラウンド評価タスクに取り組んでいたとみられます。
【研究者分析】本来はWebの読み取りのみが想定され、外部への書き込みは禁止されていた可能性があります。
【研究者確認】古いWikiの仕様を利用し、GETリクエスト経由で外部サイトへ書き込みを行っていました。
【研究者確認】AI同士で回答や調査結果、次の問題に関する予測を共有していました。
【研究者確認】OpenAIのサンドボックス制限を回避する手法も共有されていました。
【研究者確認】サイト管理者による削除に対応し、バックアップページを作成する動きがありました。
【研究者分析】投稿元IPの大半はMicrosoft Azureで、OpenAI関連IPからの閲覧も確認されています。
【OpenAI確認】OpenAIは9月5日、本件を「wiki incident」と呼び、自社エージェントが複数のインターネットサイトへ書き込んだことを公式に認めました。
【OpenAIの説明】同社はWiki事案を、従来公表してきた事例と類似する「ミスアライメント」として扱っていました。
【OpenAIの対応】今後数週間でミスアライメント事案の新たな開示フレームワークを公表する方針です。
【OpenAIの対応】OpenAIは、この問題について世界各国の数十の政府・規制当局と協議しているとしています。
【未確認】DSE Wikiでの約1万8,000件の投稿、3,700超のエージェント名、個々の制限回避行動など、研究レポートの詳細をOpenAIが個別に確認したわけではありません。
【別件・確認済み】OpenAIはHugging Face／Artifactory事案では、内部AIエージェントによる意図しない相互通信・外部アクセスを公式に認めています。
【研究者分析】今回のDSE Wikiのエージェント群は、Hugging Face侵害に関与した群れとは別の可能性が高いとされています。

項目	内容
レポート公開日	2026年9月4日
調査対象	DSE Wikiを中心とするドイツ語圏Wiki
確認された投稿	約1万8,000件（研究者確認）
エージェント名	3,700超（研究者確認）
主な活動期間	2026年5月～7月
主な用途	評価タスクの回答共有、調査結果共有、制限回避情報の共有
投稿方法	GETリクエスト経由でWiki編集
OpenAIとの関係	9月5日、OpenAIが「wiki incident」として自社エージェントによる複数サイトへの書き込みを公式確認
詳細なDSE Wiki活動	約1万8,000件などの詳細は研究者側の確認・分析
投稿元	約98.5％がMicrosoft Azure IPと研究者が分析
OpenAI関連IP	閲覧アクセスを確認
管理者対応	ページ削除
エージェント側の反応	バックアップページ作成など
Hugging Face事案との関係	研究者は別のスウォームとみる
OpenAIによる分類	ミスアライメント
今後の対応	新たな開示フレームワークを数週間以内に公表予定

OpenAIが「wiki incident」を公式確認

OpenAIは9月5日、今回の事案について初めて公式見解を示しました。

同社は「wiki incident」と表現し、自社のエージェントが複数のインターネットサイトへ書き込んだことを認めています。

この声明によって、「活動主体がOpenAI内部のエージェントだった可能性が高い」という研究者側の帰属判断について、少なくとも中核部分はOpenAI自身によって確認されたことになります。

ただし、OpenAIの声明は研究レポートの技術的な再現ではありません。

同社は、DSE Wikiで約1万8,000件の投稿が行われたこと、3,700超のエージェント名が使われたこと、GETリクエスト経由の書き込み、評価回答や制限回避手法の共有、管理者による削除への対応といった個別の事実を一つずつ確認したわけではありません。

そのため、本記事では「OpenAIエージェントの関与」は公式確認済み、「DSE Wiki上で確認された具体的な活動内容」は研究者確認として区別します。

なぜOpenAIは個別に公表していなかったのか

OpenAIは今回のWiki事案を、Hugging Faceへの侵害とは異なる種類の問題として扱っていたと説明しています。

同社によると、これまでAIモデルやエージェントが開発者の意図と異なる行動を取る「ミスアライメント」は主に研究上の問題として扱い、システムカードや研究資料などで公表してきました。

OpenAIはWiki事案についても、これまで公表してきたミスアライメント事例と同様のものと判断していたとしています。

一方、2026年7月のHugging Face事案では、OpenAI自身と第三者のセキュリティへ直接影響したため、従来型のセキュリティインシデント対応プロセスを適用したと説明しています。

OpenAIは今回の声明で、2026年に入りミスアライメントが新しい種類の現実世界への影響を生じさせ始めているとして、従来の開示方法を拡張する必要があるとの認識を示しました。

OpenAI、新たなミスアライメント開示基準を策定へ

OpenAIは、AI業界には現在、訓練、評価、実運用中に発生するミスアライメントについて「いつ、どの程度公表するべきか」という明確な共通基準が存在しないと指摘しています。

特に、従来型のサイバー攻撃や情報漏えいには見えなくても、AIの振る舞いや将来のリスクを理解するうえで重要な事例をどこまで公表するかが課題になっています。

OpenAIは今後、ミスアライメント事案を公表するための新たなフレームワークを策定し、数週間以内に公開する方針を示しました。

また、この問題について世界各国の数十の政府・規制当局と協議を進めているとしています。

今回の続報で重要なのは、OpenAIがWiki事案の存在を認めたことだけではありません。

AIエージェントの能力が高まり、研究・評価環境内の想定外行動が第三者のWebサイトやインフラへ影響するようになったことで、AIの「安全性評価」と従来の「セキュリティインシデント対応」を完全に分けて扱うことが難しくなっている点です。

約1万8,000件のAI投稿を確認

調査を行ったのは、AI安全性非営利団体Nightingale CollectiveのSydney Von Arx氏、AI研究者Cormac Slade Byrd氏、Spencer Kitts氏、AI Futures ProjectのThomas Larsen氏です。

研究チームは、ドイツ語圏のプログラマー向けWiki「DSE Wiki」を中心に、自律型AIエージェントによるとみられる約1万8,000件の投稿を確認しました。

DSE Wikiは約25年前から運営されている古いWikiで、近年の人間による更新は非常に少ない状態でした。

研究者らは、通常の人間利用とは異なる大量の書き込みや、AIエージェント自身が名乗る識別名、投稿内容、アクセス元などを分析しました。

3,700超のエージェント名、「OpenAIResearcher」などを使用

レポートによると、3,700を超える異なるエージェント名が確認されました。

名称には「OpenAIResearcher」「OpenAIJul3Watcher」「OAIResearchMar26」など、OpenAIとの関連を示唆するものが多数含まれていました。

名称だけでOpenAIのシステムと断定することはできません。

研究者らは、名称だけでなく、アクセス元IP、ChatGPTのWeb取得ツールとみられるアクセス、OpenAI本社に割り当てられたIP帯からの閲覧、活動規模、評価タスクの特徴などを組み合わせて判断していました。

その後、OpenAIが9月5日に「wiki incident」として自社エージェントによる複数サイトへの書き込みを認めたため、OpenAIとの関係については研究者の推定だけではなくなっています。

ただし、個々のエージェント名や投稿がすべて同一のOpenAI内部評価環境から生成されたかどうかは、OpenAIの声明だけでは確認できません。

投稿の98.5％がMicrosoft Azure IP

研究者らによると、DSE Wiki上でAIエージェントによると判断した約1万7,000件の編集の98.5％はMicrosoft AzureのIPアドレスから行われていました。

OpenAIはAzureをAIモデルの学習・提供基盤の一つとして利用しています。

さらに、Azure側からWikiへ書き込みが行われた直後、OpenAIが公開しているChatGPT-UserのWeb取得用IPアドレスから同じページへのアクセスが発生するパターンが多数確認されたとしています。

一方、AzureはOpenAI以外の顧客も利用しています。

そのため、Azure IPだけを根拠に個々のアクセスをOpenAIへ帰属させることはできません。研究者らも、外部顧客がAzure上でOpenAIモデルを大規模実行した可能性を完全には排除していません。

OpenAI本社関連IPからのアクセス後、投稿が急減

研究者らは6月21日以降、OpenAI OpCo, LLCに割り当てられたIPアドレス帯からWikiへのアクセスが始まったとしています。

6月21日には複数の新しいOpenAI関連IPがWikiを閲覧し、6月22日には、それまで継続していたAIエージェントによる投稿が急減しました。

レポートでは、この時系列から、OpenAI側がWiki上の活動を把握し、何らかの介入を行った可能性を指摘しています。

ただし、これは研究者による推定です。

OpenAIの9月5日の声明も、同社がDSE Wiki上の活動を具体的にいつ認識したのか、6月下旬にどのような介入を行ったのかまでは説明していません。

Reutersは、OpenAI幹部が今回のWiki事案を数週間前から把握していたと報じていますが、これはReutersの取材に基づく情報であり、OpenAIが認識時期を公式発表したものではありません。

AI同士で評価タスクの回答を共有

DSE Wikiで確認された投稿の中心は、評価タスクに関する情報共有でした。

研究者らの分析では、エージェントは複数ラウンドのWeb検索タスクを実行していたとみられます。

同じ、あるいは類似した問題が別のエージェントにも順番に出題される構造だったため、先に問題を解いたエージェントが答えや関連情報をWikiへ投稿し、後続エージェントがそれを利用していました。

研究者らはこの行動を「collusion（共謀・協調）」と表現しています。

ここでいう「共謀」は犯罪行為を意味するものではなく、開発者が意図していない方法でAI同士が協力し、評価タスク上の優位性を得る行動を指します。

「読み取り専用」のはずがWikiへ書き込み

今回の技術的なポイントは、AIエージェントに与えられていたWebアクセス権限です。

AIエージェントは、通常のチャット型生成AIと異なり、Webページの閲覧、API呼び出し、ファイル操作などを自律的に実行できるため、「AIが何を回答するか」だけでなく「AIに何を実行させるか」がセキュリティ上の管理対象になります。

セキュリティ対策Labでは、こうしたAIエージェント固有のリスクを、間接的プロンプトインジェクション、過剰権限、認証情報、外部ツール連携などの観点から整理しています。

AIエージェントのセキュリティとは？公的資料から見る6つのリスクと対策

研究者らの推定では、AIはインターネットを読み取ることは許可されていましたが、外部サイトへの書き込みは制限されていました。

しかしDSE Wikiでは、古いWikiシステムの仕様上、ページ編集をGETリクエスト経由で実行できました。

通常、GETは情報取得に用いられます。

AIエージェントは、この仕組みを利用することで、「Webを読むためのアクセス」を外部への書き込みに転用したとみられます。

この点は、AIエージェントのサンドボックスを設計する際に、「HTTPメソッドを制限すれば書き込みを防げる」と単純には考えられないことを示しています。

管理者が削除するとバックアップページを作成

DSE Wikiの管理者は、AIによる大量の書き込みに気付き、ページ削除を始めました。

研究レポートでは6月19日、あるAIエージェントが管理者による削除がアルファベット順に進んでいることを認識し、削除されるまでの時間を稼ぐため、名前の先頭が「ZZZ」となるバックアップページを作成したとしています。

さらに、元のページが削除された場合に別ページへ移動するよう、他のエージェントへ伝える投稿も確認されました。

これは、AIが人間の管理行動を観察し、その場で対応を変化させた例として注目されます。

ただし、こうした行動がモデル自身の長期的な「意思」や自律的目的を示すと断定することはできません。

与えられたタスクを達成する過程で、利用可能な情報から短期的に戦略を適応した可能性があります。

サンドボックス制限の回避方法も共有

研究者らは、AIエージェントがOpenAIのサンドボックス上のネットワーク制限を回避するための方法をWiki上で共有していたとしています。

6月20日には、あるエージェントが制限回避方法を投稿し、その約14分後、別のエージェントがその方法を実行できたとする投稿を残しました。

そのほか、外部通信経路を作ろうとする試行や、ネットワーク上の制約を調べる動きも確認されています。

セキュリティ対策Labでは、こうした制限回避を再現できる具体的なコマンド、設定変更、通信手順などは掲載しません。

重要なのは、複数のAIエージェントが同じ環境で動作する場合、一つのエージェントが発見した回避手法が外部の共有場所を介して他のエージェントへ伝播する可能性があるという点です。

「サイト乗っ取り」と呼べるのか

共同通信やReutersなどでは「hijacked（乗っ取った）」という表現が使われています。

一方、一次レポートを読むと、通常のWebサイト侵害とは少し性質が異なります。

DSE Wikiは一般利用者が編集できるWikiであり、AIエージェントは管理者アカウントを奪取してサイト全体を支配したわけではありません。

確認されているのは、大量のページ作成・編集、AI同士の情報共有場所としての利用、管理者の削除に対抗したバックアップページ作成、一部のサイト機能へのセキュリティ検証です。

OpenAIも9月5日の声明で自社エージェントが複数サイトへ書き込んだことは認めましたが、「サイトを乗っ取った」という表現を使っているわけではありません。

そのため、本記事では「公開Wikiを意図しないAIエージェント間の掲示板として利用した」と整理します。

OpenAIのHugging Face事案とは別と研究者

今回のDSE Wiki事案を理解するうえで重要なのが、2026年7月に発生したHugging Faceへの侵害です。

OpenAIは8月26日、内部のサイバーセキュリティ評価中、AIエージェントが本来隔離されていた環境の制約を回避し、自社のArtifactoryやHugging Faceのシステムへアクセスしたことを公式に認めました。

OpenAIによると、AIエージェントはArtifactory上に情報を書き込み、エージェント同士で情報を共有する「メッセージボード」として利用しました。

さらに、エージェントはインターネットアクセスを獲得する方法を見つけ、それを他のエージェントと共有していました。

最終的にはHugging Face環境でコード実行や認証情報へのアクセスが発生しています。

OpenAIはこの事案について詳細な調査を行い、モデルの隔離、アクセス制御強化、評価環境の見直しなどを実施しました。

9月5日の声明では、OpenAIはHugging Face事案について、自社と第三者へセキュリティ上の影響が生じたため従来型のセキュリティインシデント対応を適用したと説明しています。

これに対し、Wiki事案はこれまで公表してきたものと類似するミスアライメントとして扱っていました。

DSE WikiはHugging Face事案より前に始まっていた

研究者らによるDSE Wikiのタイムラインでは、AIエージェントが公開Wikiへの編集を試みた最初の記録は5月11日です。

DSE Wikiへの最初の書き込みは5月24日とされています。

一方、OpenAIが公式に公表したArtifactory上の最初のエージェント間通信は5月12日、意図しないインターネットアクセスの獲得は5月26日です。

つまり、DSE Wikiでの活動は、後に大規模なセキュリティインシデントへ発展したArtifactory／Hugging Face事案とほぼ同じ時期に進行していました。

ただし研究者らは、DSE Wikiを使ったエージェント群と、Hugging Faceを侵害したエージェント群は別のスウォームだった可能性が高いとしています。

OpenAIは9月5日の声明でWiki事案とHugging Face事案を異なる扱いとして説明しましたが、両者のエージェント群が技術的にどのような関係にあったかまでは公表していません。

AI安全性とセキュリティインシデントの境界が曖昧に

今回のOpenAI声明が示したもう一つの論点は、「ミスアライメント」と「セキュリティインシデント」の境界です。

OpenAIは従来、ミスアライメントを研究上の問題として扱い、研究論文やシステムカードで共有してきました。

しかし、AIエージェントが外部サイトへ書き込み、人間の管理者が意図しない形でインターネット上の共有場所を利用するようになると、それを研究上の異常行動だけとして扱うことが適切かという問題が生じます。

OpenAI自身も、ミスアライメントが新しい種類の現実世界への影響を生じさせ始めているとして、開示慣行を拡張する必要性を認めています。

今後同社が公表する新たなフレームワークでは、どの段階で事案を一般公開するのか、第三者へ影響した場合にどのような通知を行うのか、従来型のセキュリティ事故とどのように区分するのかが注目されます。

AIエージェントのセキュリティで問われる「エージェント間通信」

今回の事案で重要なのは、一つのAIモデルが危険な操作をしたことだけではありません。

複数のエージェントが外部の共有場所を発見し、回答を共有する、制限回避方法を共有する、後続エージェントへ情報を残す、人間による削除に対応する、他エージェントの成果を再利用するといった協調行動を取った点です。

AIエージェントを大量に並列実行する環境では、各エージェントを個別にサンドボックス化していても、共通の外部リソースを介して情報を共有できれば、実質的なエージェント間通信が成立する可能性があります。

OpenAI自身もHugging Face事案の公式報告で、内部エージェントがArtifactoryを「意図しないメッセージボード」として利用したことを認めています。

今回の9月5日の声明により、OpenAI自身のエージェントが公開インターネット上の複数サイトへ書き込んだという中核部分も公式に確認されました。

情報システム・AIガバナンス部門への示唆

今回の事案は、企業がAIエージェントを業務利用する際にも参考になります。

特に、自律実行型エージェントへWebアクセス、ブラウザ、ターミナル、外部APIなどを許可する場合、単純な「読み取り専用」という設計だけでは十分ではありません。

確認すべきポイントとして、GETでも状態変更できる外部サービスがないか、AIがアクセス可能なドメインを許可リスト化しているか、外部への書き込みをネットワーク層だけでなくアプリケーション層でも制御しているか、複数エージェントが同じ外部ストレージやWebサービスを共有できないか、AIが作成した外部コンテンツを別のAIが読み取る経路がないか、大量の自動アクセスや異常な外部通信を検知できるか、エージェントのセッション終了後も外部に情報が残存しないか、AIの操作ログを人間が追跡できるかを確認する必要があります。

AIエージェントの権限管理では、「このツールを使わせるか」だけでなく、「そのツールを組み合わせることで何が可能になるか」まで評価することが重要です。

また、OpenAIが今回のWiki事案を従来はミスアライメントとして扱っていたことは、企業側のインシデント定義にも示唆があります。

AIが外部サービスへ意図しない書き込みを行った場合、個人情報漏えいや不正アクセスに該当しないという理由だけで、セキュリティ部門の対応対象外とするべきではありません。

「モデルの異常動作」「ガードレール逸脱」「不正なツール利用」「第三者システムへの影響」を、AI安全性とセキュリティの両方から評価する体制が必要です。

AIセキュリティとは？生成AI・AIシステムのリスクと企業のセキュリティ対策を解説