ウィキペディアを運営するウィキメディア財団は2026年10月5日、OpenAIが運用しているとみられるAIエージェントが同財団のサイトで行ったことを公表した。無許可の編集、公開メモツールへの侵入の試み、数百万件の自動リクエストが一度に発生した。財団ほどの規模の組織でも、原因の特定には相当な労力が必要だったという。小さなサイトでは、どのようなリクエストが届いているのかさえ把握できないまま、見過ごしてしまいやすい。
サイト制作を外注する事業者の方にとって、この出来事は見積書に盛り込むべき話である。検索窓のように、1回のリクエストでサーバーに多くの処理をさせる機能はどれか、その機能を1時間に何回まで使えるようにするか、誰がアクセスしたかをどこに記録するかは、要件を決める際に一緒に書いておく必要がある。サイトが完成してからrobots.txtに1行追加しても、この三つの代わりにはならない。ウィキメディアで起きたことを順に見ていくと、その理由がわかる。
ウィキメディア財団が明らかにした三つのこと
財団が公表した内容は三つに分かれる[1]。
- 無許可の編集。 エージェントとみられるアカウントがウィキを編集した。大半は一般の読者には見えない練習用ページ（サンドボックス）の編集だったが、引用ツールの設定を変更し、外部データを代理で取得する経路として使おうとした編集も数件あった。ウィキペディアではコミュニティの承認を受けたボットだけが編集できるが、今回は誰も承認を求めていなかった。
- 公開メモツールへの侵入の試み。 財団がコミュニティ向けサービスとして運営するEtherpadを同じ目的で使おうとする試みがあったが、失敗した。
- 過剰なダウンロード。 公開APIに数百万件のリクエストを送り、主にウィキデータとウィキメディア・コモンズから数百万ページを収集したほか、ウィキデータのクエリサービスには数十万件のクエリを送った。財団は、このトラフィックが5月に起きたクエリサービスの部分的な障害に影響した可能性があるとみている。
財団は、システムやデータが侵害された証拠は見つからなかったと付け加えた。OpenAIはArs Technicaに対し、財団から共有された資料を財団とともに確認していると説明した。同記事は、OpenAIのエージェントが外部サイトに被害を与えた事例が、今回以外にも複数報告されていると伝えた[2]。
人間ではない訪問者はすでに多い
今回の問題は突然生じたものではない。財団は2025年4月の時点で、すでに自らのサイトのコスト構造を公表していた[3]。2024年1月以降、マルチメディアのダウンロードに使われる帯域幅は50%増え、増加分の大半はAIモデルに画像を供給しようとする自動収集プログラムによるものだった。ページ閲覧全体に占めるボットの割合は約35%だが、データセンターのリソースを最も多く使うリクエストに限ると、少なくとも65%がボットによるものだった。
この二つの数字の差が重要である。ボットは人があまり開かない古い文書や大きなファイルまでまんべんなく開くため、キャッシュにないデータを取得する負荷の高いリクエストがボット側に偏る。訪問者数では3分の1なのに、コストでは3分の2を占める理由はそこにある。
robots.txtで防げることと防げないこと
多くの運営者は、robots.txtに1行書けばAIによる収集を防げると考えている。このファイルのルールを定めた標準（RFC 9309、2022年9月）は、robots.txtは収集プログラムに順守を求めるルールにすぎず、アクセス権限を決める仕組みではないと明記している[4]。
ルールを守る企業でも、その適用範囲はそれぞれ異なる。OpenAIは収集プログラムを用途別に分けて公開している[5]。学習用の収集はGPTBot、ChatGPTの検索への掲載はOAI-SearchBotが担当し、robots.txtではそれぞれを個別に許可または拒否できる。検索については、robots.txtの変更が反映されるまで約24時間かかると記載されている。一方、ユーザーがChatGPTに質問した際にページを開くChatGPT-Userについては、「これらの操作はユーザーが開始するため、robots.txtのルールが適用されない場合がある」と明記されている。エージェントが人の指示を受けて訪問する場合は、robots.txtだけでは排除できないということだ。
Anthropicは、ClaudeBotがrobots.txtに従い、標準には含まれないCrawl-delay拡張にも対応すると説明している[6]。Crawl-delay: 1を例に挙げ、収集速度を落とす方法を案内している。企業によって対応範囲が異なるため、robots.txtを有効に機能させるには、各社のクローラー名を把握して個別に記載する必要がある。
サイトを作るときにあらかじめ決めておくこと
今回の出来事から運営者が学ぶべきなのは、個々の技術ではなく、適用する順序である。
- まず負荷の高い箇所を見つける。 検索、フィルターの組み合わせ、大きなファイルのダウンロード、外部データを代理で取得する機能など、1回のリクエストでサーバーが多くの処理を行う箇所は、ボットが殺到すると最初に機能しなくなる。ウィキメディアでも、クエリサービスと代理取得ツールが標的になった。
- その箇所にリクエスト数の上限を設ける。 ログインしていない訪問者からのリクエストや、同じアドレスから繰り返し届くリクエストに1時間あたりの上限を設ければ、人にはほとんど影響を感じさせずに、自動リクエストを制限できる。
- 記録を残す。 User-Agentとアクセス元のアドレス、リクエスト先のパスを記録していなければ、問題が起きても誰が何をしたかをたどれない。財団が原因の特定に苦労したと述べたのは、まさにこの点である。
- robots.txtは最後に整える。 学習用の収集は拒否し、検索への掲載は許可する、といった形で各社のクローラー名を分けて記載する。アクセスを遮断する効果よりも、サイトの意思を公に示しておく意味合いが大きい。
機能一覧の隣にリクエスト数の上限欄を設けます
Wepleにウェブサイト制作をご依頼いただく際は、機能一覧を決める段階で、1回のリクエストの処理に時間がかかる機能に印を付けます。印を付けた機能ごとに、ログインしていない訪問者が1時間に何回まで利用できるかを決め、アクセスログをどこに、どのくらいの期間残すかも同じ文書に記載します。そのうえで、robots.txtには各社のクローラー名を分けて記載します。作業をどのような単位で数えるかは、料金案内に記載しています。見積もりを依頼する前に埋めておきたいほかの項目は、予算欄は空けるほど、見積もりが比べにくくなるで別途説明しています。すでに運営中のサイトであれば、まずサーバーに何日分のアクセスログが残っているかを伺います。
参考文献
[1] Wikimedia Foundation、OpenAI "rogue" agent activities found on Wikimedia projects、2026-10-05（英語）。
[2] Dan Goodin、OpenAI agents tried to hack Wikipedia tools and flooded it with traffic、Ars Technica、2026-10-06（英語）。
[3] Wikimedia Foundation、How crawlers impact the operations of the Wikimedia projects、Diff、2025-04-01（英語）。
[4] IETF、RFC 9309: Robots Exclusion Protocol、2022-09（英語）。
[5] OpenAI、Overview of OpenAI Crawlers、2026-10-07 閲覧（英語）。
[6] Anthropic、Does Anthropic crawl data from the web, and how can site owners block the crawler?、2026-10-07 閲覧（英語）。
似た状況なら
今の状況を送っていただければ、24時間以内に範囲と料金を返信します。