2026年8月10日、日曜の朝7時50分。当サイトを開こうとすると、見慣れないエラーが返ってきた。同じレンタルサーバーで動かしている3つのサイトが、すべて同時につながらない。管理画面にも入れない。前日まで、何の兆候もなかった。
犯人はハッカーではなかった。MetaのAI学習用クローラーが、明け方から毎時8,000回以上アクセスしてきていたのだ。この記事は、AIクローラーに共用サーバーを黙らせられ、約20分で復旧させるまでの実録である。同じ構成のサイトなら、明日あなたの身にも起きうる。
何が起きたのか——PHPだけが死んでいた
症状は奇妙だった。トップページは表示されるのに、記事の一部や管理画面は「507 Insufficient Storage」というエラーで落ちる。507は「サーバーの割り当て容量が足りない」という意味のエラーだ。最初はディスク満杯やウイルス感染を疑った。
だが調べると、ディスクにもファイル数にも異常はない。生きていたのはキャッシュ済みのページと画像などの静的ファイルだけ。PHPというプログラムを動かす処理だけが、受付の段階で拒否されていた。つまり容量ではなく、サーバーの「体力」が尽きていたのである。
ログが示した犯人——1万3,000件のMetaクローラー
アクセスログの直近2万行を集計すると、内訳は一目瞭然だった。最多はmeta-externalagent。MetaがAIの学習データを集めるために巡回させているクローラーで、約1万3,000件を占めていた。次いでOpenAIのGPTBotが約940件。人間の読者は、ごく少数派だった。
| ユーザーエージェント | 直近2万行中の件数 | 目的 |
|---|---|---|
| meta-externalagent | 約13,000件 | MetaのAI学習用データ収集 |
| GPTBot | 約940件 | OpenAIのAI学習用データ収集 |
| 人間+その他 | 残り | 通常の閲覧・検索クローラーなど |
問題は量だけではない。同じアカウントに同居していた趣味サイトには、ページキャッシュ(表示結果の使い回し)が入っていなかった。1ページ作るのに約12秒。そこへクローラーが並列で押し寄せた結果、処理中のプログラムが約20本たまりっぱなしになり、アカウント全体のブレーカーが落ちた。直撃されたのは1サイトなのに、巻き添えで3サイト全部が止まったのが今回の教訓だ。
図: 障害の連鎖。弱い1サイトへの集中アクセスが、同居サイトまで道連れにした(筆者作成)。
20分でやった応急処置——「PHPに触らせない」が正解だった
復旧の要点は、クローラーを追い返すことではなく、サーバーの体力を使わせないことだった。まずrobots.txtという「巡回ロボットへのお願いファイル」に、meta-externalagentとGPTBotの拒否を書いた。幸い、両者ともこのルールを守る行儀のよいクローラーだ。
ただしrobots.txtが読まれるまでには時間差がある。そこで.htaccessというサーバー設定で、該当クローラーには即座に403(お断り)を返すようにした。403は静的な応答なので、重いPHP処理まで到達しない。ブレーカーを消費させずに済むわけだ。処理の渋滞は約20本から4本まで減り、3サイトとも即座に復旧した。
失敗も正直に書いておく。応急処置の勢いで「単一画像に3,000回アクセスしてくる不審なIP」もブロックしたのだが、これは後でサーバー自身のIP——つまり予約投稿などに使う自己アクセスだと判明した。同日中に解除して事なきを得たが、緊急時ほど「怪しく見えるだけの正常」を撃ってしまう。当事者としての、苦い実感である。
AIクローラーは「災害」になったのか
今回の件を、単なる運の悪い事故とは考えていない。Cloudflareの観測では、Webのアクセスの過半数はすでに人間ではなくボットだ。AIクローラーの増加はその主因のひとつで、雨や風と同じ「環境」になりつつある。傘を持たずに出かける時代は終わった、と受け止めるほかない。
radar.cloudflare.com Cloudflare Radar: Bots 世界のボットトラフィックの実測データ。どのAIクローラーがどれだけ巡回しているかを無料で確認できる。自サイトのrobots.txtを書く前の基礎資料になる。一方で、AIクローラーを全部締め出せばよいという話でもない。AI検索経由で読者が来る時代、AIに引用されることはサイトの新しい入り口でもある。学習用の一方的な収集は断り、読者を連れてくる巡回は通す——そんな選り分けが、これからのサイト運営の標準装備になる。AIエージェントに「身元」を持たせるCloudflare Walletsの試みも、この文脈で読むとつながって見える。
自分のサイトを守るための3点セット
最後に、今回の実体験から言える備えを整理する。第一に、ページキャッシュを必ず有効にすること。12秒が0.1秒になれば、同じアクセス数でも渋滞は起きない。今回の根本原因は、クローラーよりもキャッシュ無しの重いサイトだった。
第二に、月に一度でいいからアクセスログの上位ユーザーエージェントを見ること。異変は数字に先に出る。第三に、拒否の手段を2段構えにすること。robots.txtでお願いし、.htaccessで強制する。順番はこの逆でもいい。まずは今夜、自分のサイトのログを開いてみてほしい。そこに見知らぬロボットの行列がいたら、この記事の手順がそのまま使えるはずだ。
出典: Cloudflare Radar(ボットトラフィック実測) / Meta公式(meta-externalagentの説明) / OpenAI公式(GPTBotの説明)
