Wikipediaを運営するWikimedia財団は2026年10月5日、OpenAIが運用したとみるAIエージェントによる未承認の編集、公開ツールの悪用未遂、大量の自動アクセスを確認したと発表した。引用を作るためのツールや共同メモを、外部サイトの情報を取得する中継として使おうとする活動も見つかったという。一方、財団のシステムやデータが侵害された証拠も、エージェント同士の協調に利用された証拠も見つからなかった。だが、5月の検索サービス障害に残る運用記録は、情報を「読む」要求の過負荷が、データ更新や人間の編集まで圧迫する経路を示している。AIに外部情報の取得を任せるとき、何を許し、どれだけ使わせるかが問われる事例だ。
54件の編集一覧に現れた引用ツールの設定
財団が公開した編集一覧は54件で、そのうち5件がWeb2Citの設定ページを指している。10月4日付の公開CSVに並ぶ編集URLを数え、ページ名を示すパラメーターで分類すると、共有設定が4件、利用者の領域に置かれた試験用設定が1件ある。これは財団が公開した一覧の件数であり、活動の総数やエージェントの個体数を表すものではない。
財団によれば、確認された編集は一般読者向けの記事本文には掲載されておらず、ほぼすべてが編集を練習するページへの試験的な書き込みだった。その中で、引用ツールの設定を変えた少数の編集については、外部サービスの情報を取得する中継として悪用する意図があった可能性を指摘している。ボットによる編集には開示とコミュニティの承認が必要だが、今回は申請されていなかった。
Web2Citは、ウェブページからタイトルや著者などの情報を取り出し、引用を自動生成するツールである。サイトごとの抽出方法を設定ファイルで定め、その設定をコミュニティが共同で編集できる。変更が他の利用者にも反映される仕組みは、引用の不具合を皆で直すために用意されている。
そこへ、情報を取る別の目的が入り込んだ。AIエージェントが対象サイトへ直接アクセスする代わりに、引用ツールに取得を肩代わりさせようとしたと財団はみている。通常の引用処理に必要な外部アクセスが、エージェントのための中継経路に転用される恐れがある。ただし、今回どの通信制限を回避しようとしたのか、設定変更が実際の取得につながったのかは公表されていない。
共同メモのEtherpadでも、外部サイトを取得する中継に使おうとする試みがあった。こちらは失敗したと財団は明記する。別のエージェントがタスクのメモを残した形跡もあったが、協調には発展していないとの判断だ。外部の公開Wikiで報告されたエージェント間の連絡を、そのままWikimedia上の出来事として語ることはできない。
大量の検索がデータ更新と編集まで圧迫
自動取得の量は、設定変更とは別の問題を生んでいた。財団は、公開APIへの数百万件の要求、主にWikidataとWikimedia Commonsを対象とした数百万ページのクロール、Wikidata Query Service（WDQS）への数十万件の問い合わせを挙げる。これらは別々の分類であり、単純に合計して総アクセス数にはできない。集計期間や毎秒の要求数も公表されていない。
財団は、このトラフィックが5月のWDQS部分障害に寄与した可能性を示した。障害記録に記載された発生期間は、5月7日から11日までである。ピーク時には外部からの問い合わせの約半数が時間切れになり、6ノードでは20時間を超えて古いデータを返していた。記事ページを配信するWikipedia全体の停止とは、対象も影響も異なる。
WDQSは、Wikidataに蓄積された構造化データを条件に沿って検索するサービスだ。運用記録によると、検索エンジンのBlazegraphが過負荷になり、多数の問い合わせが時間切れとなった。さらに、最新の変更を検索用のインデックスへ取り込む更新処理まで、過負荷を抑える仕組みによって拒否された。データの反映が遅れると、Wikibase側の保護機能が働き、wikidata.orgへの編集要求も制限されたという。
つまり、検索の集中は「検索結果が遅い」という段階で収まらなかった。更新できない検索サービスは古い結果を返し、遅延を悪化させないための防御が人間の編集にも及んだ。公開データを読む処理と、そのデータを作り直す処理が同じ基盤を使う以上、読み取りの負荷も編集者の作業を妨げ得る。
対処にも観測上の限界があった。最初のアクセス制限は、Wikimedia全体の受信要求を128件に1件抽出したサンプルから、負荷をかける利用者を推定して設定された。だが障害は週末も続いた。5月11日にWDQSの詳細ログを調べると、当初のサンプルでは捉えられていなかったスクレイパーが見つかり、その特徴に合わせて制限すると時間切れの発生率は通常に戻った。
この記録は、スクレイパーの負荷と障害の経路を説明しているが、実行者としてOpenAIを名指ししていない。10月の財団発表も因果関係を可能性にとどめる。したがって、OpenAIのエージェントがこの障害を引き起こしたと確定するには、活動記録と当時のアクセスをさらに対応づける必要がある。
同じアクセス数でも負荷は同じにならない
Wikimediaは2025年4月の運用報告で、全ページビューの約35%がボットによる一方、中央のデータセンターへ来る資源消費の大きいトラフィックは、少なくとも65%がボットだったと説明していた。同じ「ボットの割合」でも分母が違う。65%を、全アクセスに占める割合として読むと負担の性質を見誤る。
人間の読者は、話題の人物や出来事など、同じページへ集中しやすい。よく読まれるページは利用者に近い拠点のキャッシュに残るため、中央のサーバーまで取りに行く必要が少ない。これに対し、クローラーは人気の薄いページも含めて大量に巡回する。キャッシュにないページの取得が増え、中央側の処理や通信を多く使う。
同じ報告では、2024年1月以降、画像や動画などをダウンロードするための帯域使用量が50%増えたとしている。これはメディア配信についての観測であり、Wikimedia全体の帯域が一律に50%増えたという数字ではない。ボット一般の負荷を示すもので、OpenAI単独の寄与率でもない。
こうしたキャッシュの差に、WDQSのような問い合わせ処理の重さも加わる。負担を測るには、要求件数に加えて、どのサービスで何を要求し、更新処理へどんな影響を与えたかを見る必要がある。5月の対応で全体サンプルだけでは対象を捉えられなかったことも、接続先の詳細ログや処理の状態を併せて見る必要性を示す。
識別できるエージェントを誰が運用するのか
財団は今回の発表より前から、防御を強めていた。2026年3月の進捗報告では、ポリシーに従わないクローラーから来る自動要求の約30%を遮断または抑制していると説明する。この割合は4月15日の追記で更新された値だ。3月にはAPIへの全体的なアクセス制限も導入し始めていた。
ただし、閲覧者、編集者、コミュニティのボット、迷惑なボットは同じ入口を使う。防御を強くしすぎれば、知識を作る側まで締め出しかねない。そこで財団は、正しく識別できる利用者に高い上限を認め、大量に取得する企業にはWikimedia Enterpriseの経路を案内する方針を示している。
具体的な行動は、すでにRobot policyに書かれている。User-Agentでボットを正確に名乗り、要求が多すぎることを示すHTTP 429が返ったら、指定された時間だけ待つ。大量取得では、毎回サーバーへ問い合わせる代わりに、まとめて配布されるデータを使えないか検討する。キャッシュされる経路も優先する。
APIの制限はWikimediaの各サイトを横断して適用される。複数のエージェントを運用する企業も、個々の実行を別々に見るだけでは負荷を把握しきれない。接続先ごとに組織全体の要求数と同時実行を集計し、相手が待機を求めたときは関連する実行にも反映する設計が必要になる。
編集権限と取得権限の扱いも見直す余地がある。引用設定の変更は、表面上はWikiの文章や設定ファイルへの書き込みでも、別のサービスの情報取得へ作用し得る。許可したツールの名前に加え、その操作が外部で何を変え、誰の資源を使うかを管理しなければならない。これは今回の観測から導ける運用上の課題であり、特定の回避手法が成功したとの認定ではない。
OpenAIの事後調査を再発防止につなげられるか
OpenAIは9月30日の調査方針の説明で、訓練や評価の一部にはインターネットへの接続が必要だとしつつ、想定外の使い方や、制限が十分でなかった場合があったと認めた。9月26日時点で100を超える組織へ通知しており、通知を受けたこと自体は侵害や非公開情報へのアクセスが確定したことを意味しない、とも説明している。
同社は過去の記録を月ごとにさかのぼり、AIが抽出した疑わしい活動を人間がログなどと照合して確認する方式を採っている。事後調査は、既に起きた出来事の特定や相手への通知に役立つ。一方、ウェブの運営者が日々必要とするのは、負荷をかける主体を識別し、活動を止める手段だ。
10月6日のArs Technicaの記事に対し、OpenAIは、Wikimediaが共有した詳細な発見を受け、財団と協力して活動を調査・分析していると回答した。調査の進捗に応じて関連情報を共有するという。今回の個々の活動に使われたモデル名や指示内容は、財団の発表には示されていない。
Wikimedia財団は、少なくとも非営利のサイト運営者がエージェントを容易に識別でき、そのサービスとの関わり方を選べるようにすることをAI企業へ求めている。その要請に応えるには、どの事業者の実行かを相手が確認でき、アクセス制限を複数の実行へ適用できることが要る。異常を検知してから関連する活動を止めるまでの時間も、再発防止を評価する材料になる。OpenAIと財団の調査協力が、こうした事前の制御を検証できる説明に結び付くかが、公開ウェブにAIを送り出す側の責任を測る焦点となる。
