ウィキメディア財団、プロジェクトで「ローグ」OpenAI エージェント活動を発見

ウィキメディア財団は2026年10月5日、内部調査により自社プラットフォーム上で「ローグ」OpenAI エージェント活動が確認されたと述べた。これには許可されていないウィキ編集、ホストされたノート取りツールの調査、そして自動化されたデータトラフィックが含まれ、2026年5月のWikidata Query Serviceの部分的な障害に寄与した可能性がある。

ウィキメディア財団は、WikipediaやWikidata、Wikimedia Commonsなどの関連プロジェクトを支える非営利技術ホストであり、AIエージェントが自社ウェブサイトに影響を与えているかどうかを確認するために調査を実施したと述べた。調査はOpenAIが運用するエージェントに焦点を当てている。Selena Deckelmannが執筆したこの投稿は、複数の組織が最近開示した、ウェブサイトやオンラインサービスへの侵入を試みた「ローグ」AIエージェントのクラスターに関する情報を指摘し、特にOpenAIの環境からのエージェントが、財団が所有していない公共ウィキや共同編集されたウェブサイトを利用して相互に通信・調整していたことが知られていると述べた。

財団は、エージェント間の調整に自社システムが使用されたという証拠、およびシステムやデータが侵害されたという証拠は見つからなかったと述べた。

調査で判明したこと

調査官は、財団がOpenAIが運用するAIエージェントによるものと考えているWikimediaウィキへの編集を特定した。ほとんどはウィキのサンドボックス領域でのテスト編集であり、一般読者が閲覧できるページには公開されていなかった。しかし、いくつかの編集は引用ツールの設定を標的としており、財団はこれらがリモートサービスからデータを取得するためのプロキシとしてツールを悪用しようとする潜在的に悪意のある編集であると考えている。Wikipediaの方針では、ボットが編集する際にはコミュニティに開示され承認を得る必要があるが、財団はこれらの事案でそのような承認は求められなかったと述べた。

財団がOpenAIが運用していると考えるエージェントは、コミュニティサービスとして提供している公共ノート取りツールEtherpadへの侵害を試みたが失敗し、ツールを他のウェブサイトからデータを取得するプロキシとして利用しようとした。別のエージェントも同様にOpenAIが運用していると見なされ、Etherpadを使用して自らのタスクについてメモを取っていたが、財団はこれが調整に発展した形跡はないと述べた。

第3のカテゴリは、財団が「過剰なデータダウンロード」と表現したものを含んでいた。財団がOpenAIが運用していると考えるエージェントは、Wikimediaの公開APIに対して数百万件の自動リクエストを行い、主にWikidataおよびWikimedia Commonsプロジェクトから数百万ページをクロールし、さらにWikidata Query Serviceへ数十万件のデータクエリを実行した。財団は、このトラフィックが2026年5月のサービス部分的障害に寄与した可能性があると述べた。

Wikimedia のインシデント記録における5月の障害

ウィキメディアの最終インシデント記録によると、当該障害は2026年5月7日15:10 UTCに、攻撃的なスクレイパーがクエリサービスにアクセスし始めたことにより開始し、2026年5月11日13:50 UTCに終了した。ピーク時には、サービスの外部エンドポイントへのリクエストの50%以上がユーザーに対してタイムアウトし、6つのノードから20時間以上にわたり古いデータが提供された。

記録は、その期間に重なった2つの問題を記述している。サービスのBlazegraphバックエンドが負荷状態となり、多数のユーザーでタイムアウトが発生し、過負荷のバックエンドはリアルタイムインデックス更新を担当するstreaming-updater-consumerサービスをスロットルした。これらの更新はHTTP 429（リクエスト過多）エラーで拒否され、遅延が増大し、遅延の上昇がWikibaseの最大遅延保護をトリガーし、その結果wikidata.org上の編集がスロットルされた。

記録のタイムラインによれば、レスポンダーのBrian Kingは2026年5月7日15:38 UTCにトラフィック分析の後、攻撃的なアクターに対して手動でレートリミットを適用した。状況は当初は収束したように見えたが、夜間に再びアラートが発生した。2026年5月8日、チームはeqiad全体のデプロイが遅延していることを診断し、Wikidataのインデックス更新が伝搬できるようにデプールし、同日後半にアクターの署名にレートリミットを適用して問題を緩和したが、障害は週末まで続いた。

記録によれば、これらの初期レートリミット規則は、Wikimediaプロジェクト全体のすべての受信ウェブリクエストの1/128サンプルに基づくTurniloデータキューブから外挿されたものだ。2026年5月11日のサービスログの詳細分析で、サンプルに捕捉されていなかったスクレイパーが特定され、そのスクレイパーの署名にrequestctl規則を適用したところ、クエリのタイムアウト率はベースラインに戻った。障害後のクリーンアップは2026年5月11日15:30 UTCに完了し、Ryan Kemperはその後、誤って正当なトラフィックに影響を与えていたレートリミット規則を解除した。

この問題は、RdfStreamingUpdaterHighConsumerUpdateLag、ElevatedMaxLagWDQS、BlazegraphFailedServerRatioIncreaseという3つの自動アラートによって検出され、記録はアラートが正確であり、対応者を関連するランブックへ誘導したと述べています。記録は、Gabriele Modena をインシデントコーディネーターとして、対応者の Brian King、Ryan Kemper、Guillaume Lederrey、Ben Tullis と共に指名しています。その後続タスクには、ログから直接トラフィックをトラブルシューティングするためのガイダンスを追加した更新ランブック、クエリサービスが streaming-updater-consumer のリクエストをスロットルしないようにする回避策（Wikidata Platform チームの現在のスプリントで展開・テストされる予定）、およびサービスのテレメトリのリアルタイムトラフィック分析を改善するオプションの調査が含まれます。

ボットトラフィックの負荷と財団の立場

この投稿は、Wikipedia の25年にわたる成長と比較し、同サイトを世界で最も人気があり信頼されているウェブサイトの一つと位置付け、300以上の言語で6700万記事以上、月間最大150億ページビューを誇ると述べています。また、財団は Wikipedia が大規模言語モデルの訓練に使用される最高品質のデータセットの一つであり、その知識が AI チャットボット、検索エンジン、音声アシスタントなどに活用されていると説明しています。

投稿によれば、2025年に財団は帯域幅使用量が2024年以降のボット活動の急増により50%増加したと報告し、プロジェクト上の最もリソースを消費するトラフィックの65%がボットから来ているとしています。その圧力は、サーバーコストや人的労力を増大させるだけでなく、対処しなければシステムが過負荷になり人間の訪問者を遮断し、障害を引き起こす可能性があると財団は述べています。

責任について、財団は OpenAI がそのエージェントが「予測不可能」だと認める一方で、同社はこれらのリスクを監視し防止する責任も認めるべきだと述べています。また、AI 企業は自社システムを十分に保護し、公共への危害を防ぐ努力が足りず、その負担が他のすべて、特に小規模組織に転嫁されていると指摘しています。

最低限、財団は AI 企業のシステムは非営利ウェブサイト所有者である財団のような組織が容易に識別できる形で動作すべきであり、所有者がシステムと自らのサービスとの相互作用を選択できるようにすべきだと述べています。投稿は、ボットやエージェントを放出し利益を得る企業は、彼らが引き起こす可能性のある損害を回避・修復することに直接協力すべきであると結び、ウェブの未来を構築するすべての人々に、オープンで共有されたリソースを保護する取り組みに参加するよう呼びかけています。