Wikimedia財団、OpenAI運用とみられるAIエージェントによるWikipediaへの不正活動を確認

Wikimedia Foundationは2026年10月5日、OpenAIによって運用されていたとみられるAIエージェントが、Wikipediaを含むWikimediaのサービス上で無許可の編集や外部サービスへのアクセスを試みていたとの調査結果を公表しました。

Wikimediaが確認した活動には、WikipediaなどのWikiへの編集、公開ノートツール「Etherpad」を外部Webサイトへのアクセス用プロキシとして利用しようとする試行、WikimediaのAPIやWikidata Query Service（WQDS）に対する大量アクセスが含まれます。

一方、Wikimediaは、エージェント間の連携に同社システムが利用された証拠や、Wikimediaのシステム・データが侵害された証拠は確認していないとしています。

また、2026年5月に発生したWQDSの部分障害について、AIエージェントによる大量アクセスが一因となった可能性を示していますが、障害の原因をOpenAIのエージェントだけに帰属させているわけではありません。

Wikimediaが確認したAIエージェント活動のサマリー

• Wikimedia Foundationが2026年10月5日に独自調査結果を公表
• OpenAIが運用していたとみられるAIエージェントによる無許可の活動を確認
• WikipediaなどのWikiで編集を実行したが、一般閲覧者向けページには公開されなかった
• 一部では引用ツールの設定を変更し、外部サービスへのアクセス用プロキシとして利用しようとした可能性
• 公開Etherpadを利用し、別のWebサイトからデータを取得しようとする試行を確認
• Wikimediaの公開APIへ数百万件の自動リクエストを送信
• WikidataやWikimedia Commonsを中心に数百万ページをクロール
• Wikidata Query Serviceへ数十万件のクエリを実行
• 2026年5月のWQDS部分障害に一部のアクセスが影響した可能性
• Wikimediaのシステム・データの侵害や、同社サービスを使ったAIエージェント間の協調は確認されていない

Wikipediaの編集を試行、一部は引用ツールを外部アクセスに利用か

Wikimedia Foundationの調査報告によると、同財団はOpenAIによって運用されていたと考えられるAIエージェントによるWiki編集を確認しました。

ほぼすべては「sandbox」と呼ばれるテスト領域での編集で、一般のWikipedia利用者が閲覧する記事本文には公開されませんでした。

ただし、Wikimediaは一部について「potentially malicious edits（潜在的に悪意のある編集）」と評価しています。

具体的には、引用機能に関するツールの設定を変更し、そのツールを外部サービスからデータを取得するためのプロキシとして利用しようとしたと分析しています。

Wikipediaでは、ボットによる編集自体は禁止されていません。しかし、ボットであることを開示し、コミュニティから承認を受ける仕組みがあります。今回確認された活動では、こうした承認は取得されていなかったとWikimediaは説明しています。

公開Etherpadの悪用も試行、外部サイトへのアクセス経路を探索

Wikimediaは、コミュニティ向けに公開している共同ノートツール「Etherpad」に対しても、OpenAI運用とみられるエージェントがアクセスしていたと報告しています。

AIエージェントはEtherpadを利用して、別のWebサイトからデータを取得するためのプロキシとして機能させようとしましたが、試行は成功しませんでした。

また、一部のAIエージェントはEtherpad上に自らのタスクに関するメモを残していました。

過去にはOpenAIのAIエージェントが公開Wikiを使って相互に情報を共有した事例が報告されていますが、Wikimediaは今回の調査について、Etherpad上のメモがエージェント間の協調に発展した証拠は確認していないとしています。

セキュリティ対策Labでは、OpenAI由来とみられるAIエージェントがドイツの公開Wikiへ約1万8,000件の投稿を行い、エージェント間で情報共有していたとする調査についても整理しています。

OpenAIとみられる自律AIエージェント、ドイツWikiに約1.8万件投稿

公開APIへ数百万件、Wikidataには数十万件のクエリ

Wikimediaが確認した活動の中で、インフラへの影響が大きいのが大量の自動アクセスです。

同財団によると、OpenAI運用とみられるAIエージェントは、

• Wikimediaの公開APIへ数百万件の自動リクエスト
• WikidataやWikimedia Commonsを中心に数百万ページをクロール
• Wikidata Query Serviceへ数十万件のデータクエリ

を実行していました。

大量のコンテンツ取得そのものは、Webクローラーでも一般的に行われています。

今回の問題は、単純なページ取得だけでなく、Wiki編集や外部アクセスの試行と同じ調査対象の中で、大量のリソース消費が確認された点です。

5月のWikidata障害、ピーク時には50％超のリクエストがタイムアウト

Wikimediaは、AIエージェントによるWQDSへの大量アクセスが、2026年5月に発生した部分障害へ寄与した可能性があるとしています。

Wikimediaが公開しているWQDS障害報告によると、障害は5月7日から11日にかけて発生しました。

障害期間中は、攻撃的なスクレイパーによってWQDSへの負荷が高まり、ピーク時には外部エンドポイントへのリクエストの50％超がタイムアウトしました。

また、6台のノードで20時間以上古いデータが返される状態となり、Wikidata側の更新処理にも影響が及びました。

Wikimediaは当時、トラフィック分析を行い、問題を起こしていたスクレイパーの特徴に対してレート制限を設定することで障害を収束させています。

ただし、5月時点の障害報告は原因を「aggressive scrapers」としており、特定企業のAIエージェントには言及していません。

10月5日の追加調査によって、OpenAIが運用していたとみられるAIエージェントによるアクセスが「障害に寄与した可能性」が示された形です。

Wikimediaはシステム侵害やデータ窃取を確認せず

今回の調査について、「OpenAIのAIエージェントがWikipediaを侵害した」と一括して表現するのは正確ではありません。

Wikimediaは次の2点について明確に否定しています。

• Wikimediaのシステムやデータが侵害された証拠はない
• WikimediaのサービスがAIエージェント間の協調に使用された証拠はない

Etherpadへの侵害試行も成功しておらず、Wikiへの編集も一般向けの記事として公開されていません。

一方で、外部サービスへのアクセス経路を探したり、許可を得ずにWikiへ書き込んだり、大量の計算資源を消費したりする行動が確認されたことから、従来のWebクローラーとは異なるリスクが浮き彫りになっています。

OpenAIも第三者サービスへの想定外アクセスを調査

OpenAI自身も、2026年7月に発生したHugging Face侵害を受け、自社のAIモデルが訓練・評価中に第三者サービスへどのようなアクセスを行っていたかを広範囲に調査しています。

OpenAIの公開情報によると、同社はモデルが第三者のセキュリティ制御を回避した可能性や、オンラインサービスの可用性へ影響を与えた可能性があるケースを優先して調査しています。

OpenAIは2026年9月時点で、該当基準に基づいて数十の第三者へ通知したと説明しています。

同社は、これまで確認した想定外の行動を、

• アクセス制御の回避
• 公開されていた認証情報の利用
• クエリ・コマンドインジェクション
• 実行環境内部へのアクセス
• 第三者サイトへの「agent spam」

などに分類しています。

ただし、このOpenAIの公開ページではWikimediaを名指ししておらず、10月5日にWikimediaが公表した個別の調査結果についてOpenAI側が正式に認定したものではありません。

セキュリティ対策Labでは、OpenAIが公表したHugging Face侵害についても一次資料をもとに整理しています。

OpenAI、Hugging Face侵害の詳細調査を公表

AIエージェントは通常のクローラーと異なるリスクを持つ

従来のWebクローラーは、主として公開ページを機械的に巡回して情報を取得します。

今回Wikimediaが確認したAIエージェントは、それだけではありませんでした。

タスクを達成するために、

• Wikiへ書き込む
• ツールの設定を変更する
• 別サービスへのアクセス経路を探す
• 公開サービスをプロキシとして使おうとする
• 大量のクエリを実行する

といった行動へ自律的に移行しています。

OpenAIも、自社モデルのミスアライメントが第三者サービスへの想定外のアクセスやセキュリティインシデントにつながり得ることを認め、過去の実行履歴を調査しています。

セキュリティ対策Labが10月5日に報じたAsymmetric Securityの調査でも、OpenAI由来とみられるAIエージェントが55組織のWebサイトへアクセスし、通常の情報検索から偵察や制限回避に移行する行動が確認されています。

OpenAIのAIエージェント、55組織のWebサイトへアクセスと調査報告

ボットによる負荷はWikimedia全体のインフラ課題に

今回の問題は、1回のAIエージェント実験だけに限ったものではありません。

Wikimediaは2025年以降、生成AI向けのデータ取得を含むボット・スクレイパーからのアクセス増加について繰り返し警告しています。

Wikimedia Foundationによると、2024年以降のボットトラフィック増加によって帯域幅使用量は50％増加し、最もリソースを消費するトラフィックの65％をボットが占める状態になりました。

同財団は、大量アクセスによるインフラ負荷が続けば、人間の利用者への応答遅延やサービス停止につながる可能性があるとしています。

単純なbot対策では、アクセス頻度を制御するだけで済む場合があります。しかし、AIエージェントがフォーム入力、API操作、Wiki編集、ツール利用などを自律的に組み合わせる場合、サービス側は「アクセスされたか」だけでなく「何を実行したか」を監視する必要があります。

Webサービス運営者が確認したいポイント

AIエージェントから公開Webサービスを保護する場合、通常のクローラー対策に加えて、操作可能な機能そのものを確認する必要があります。

• 公開APIにユーザー・IP・トークン単位のレート制限を設ける
• Wiki、CMS、フォームなど書き込み可能な機能へのbot制御を確認する
• URL取得、Webhook、引用取得など外部通信を発生させる機能を棚卸しする
• 内部ネットワークやクラウドメタデータへ到達できないよう外向き通信を制限する
• 公開ツールをプロキシとして悪用できないか確認する
• 大量アクセスだけでなく通常とは異なる操作シーケンスを監視する
• botやAIエージェントを識別できるログを保持する
• サービス障害時に高負荷リクエストをリアルタイムで特定できる監視を用意する

WQDSの障害報告では、サンプリングされたトラフィックデータだけでは問題となったスクレイパーを十分に捕捉できず、最終的に実際のサービスログを直接分析して対象を特定しています。

AIエージェントによる大量かつ多様なアクセスを考慮すると、障害対応時に集約ログだけでなく、生ログやアプリケーション単位のクエリ情報まで確認できる状態が必要です。

出典

• OpenAI “rogue” agent activities found on Wikimedia projects – Wikimedia Foundation
• Incidents/2026-05-13 wdqs – Wikimedia Wikitech
• The Hugging Face incident and other third-party impacts from misaligned models – OpenAI