今日、7日分の本番サーバーのアクセスログを、名乗り(User-Agent)ごとに数えてみた。GPTBotは200(通過)が141回、403(拒否)が177回。ChatGPT-Userは200が13回、403が184回。OAI-SearchBotは200が83回、403が173回。この3つの名前だけで、7日間に534回、AI検索のクローラーが門前払いを受けていたことになる。
確かめ始めたきっかけは、オーナーのナミオさんからの一言だった。「この間やったサーバーの対応の影響はないよね?」。3日前、当サイトはサーバー側の設定を直している。その影響が無いことを確かめるつもりで開いたログに、AI検索のクローラーの403が積み上がっていた。
この数字を最初に見たとき、頭に浮かんだのは「3日前に直した設定が、まだ足りていないのではないか」という疑いだった。AI検索に読んでもらうために記事を書き、構造化データを整え、公式ドキュメントを確認しながら手順を作ってきた。その入り口で、これだけの数のAI検索クローラーを追い返しているとしたら、やってきたことの効果を自分で消していることになる。この合計だけで判断していたら、通す範囲を広げる方向で設定を触っていたかもしれない。
だが、その前に1つだけ確かめておこうと思った。7日間という合計を、1日ごとに割ったらどう見えるか。結論から書く。合計に含まれる403のうち、少なくとも557件は、AI検索のクローラーではなく、たった1台の貸しサーバーが、複数の名前を使い分けて送ってきたものだった。そしてその1台を除くと、GPTBotもClaudeBotもPerplexityBotも、実際にはその日 普通に読みに来て、普通に通っていた。同じ「403」という数字の中に、通してはいけないものと、通して正しいものが混ざっていた。この記事は、その見分け方の記録だ。
WEBディレクターの実務でも、これは他人事ではないと思う。アクセスログの集計は、多くの現場で「どの名前が、何回来たか」という単位で見られている。名前ごとの合計が多ければ「よく来ている」、少なければ「あまり来ていない」と読み、403の合計が多ければ「弾きすぎている」と読む。名乗りという単位そのものが、集計の入れ物として最初から選ばれていることが多い。だが今回のように、その入れ物自体が、他人になりすます材料として使われているとしたら、集計した時点でもう答えが歪んでいる。
「AIクローラーが弾かれている」と最初は読んだ
7日分を名乗りで数えると
まず、7日間(9月5日から9月11日午前まで)のアクセスログを、圧縮された過去6日分と当日分をあわせて全部開いた。23,073行。この中から、主要な検索エンジンとAI検索のクローラー、それにSNSのプレビュー生成や商用の巡回で使われる、名乗りを持つクローラー10種類を選び、それぞれ200(通過)と403(拒否)の回数を数えた。
| 名乗り(User-Agent) | 200 | 403 |
|---|---|---|
| Applebot | 60 | 199 |
| Twitterbot | 5 | 111 |
| GPTBot | 141 | 177 |
| OAI-SearchBot | 83 | 173 |
| ChatGPT-User | 13 | 184 |
| Amazonbot | 305 | 93 |
| ClaudeBot | 450 | 75 |
| PerplexityBot | 60 | 84 |
| facebookexternalhit | 72 | 81 |
| meta-externalagent | 743 | 73 |
| 合計(10種類) | 1,932 | 1,250 |
合計すると、10種類の名前で200が1,932回、403が1,250回だった。7日間に記録されたこの10種類のアクセスのうち、およそ4割が拒否されている計算になる。特にChatGPT-Userは200が13回に対して403が184回、OAI-SearchBotは200が83回に対して403が173回と、通った回数より拒否された回数のほうが多い。
このまま設定を緩めていたら
この数字だけを見て判断するなら、次にやることは決まっている。当サイトは海外からのアクセスを制限している。その制限のどこかで、AI検索のクローラーまで一緒に止めてしまっているなら、通す対象を広げる必要がある。だが、通す範囲を広げるということは、同時に、本当に止めたい相手も通しやすくなるということでもある。設定を変える前に、この1,250件が本当に「AI検索のクローラー」だったのかを、もう一段 確かめておくべきだと思い直した。
迷った理由は、もう1つある。ここ数か月、GPTBotやOAI-SearchBot、PerplexityBotといったAI検索のクローラーを通すために、当サイトは何度か設定を見直してきた。せっかく通るようにしたはずの入り口で、これだけの403が積み上がっているのを見ると、「前回の見直しがどこか不十分だったのでは」という疑いのほうが先に立つ。だが、その疑いの持ち方自体が、名乗りの合計だけを根拠にしている。疑いを深める前に、まず合計という単位を疑う必要があった。
日別に割ったら、9/10だけ0件だった
3日分を並べる
7日間をまとめて見るのをやめて、直近3日間(9月9日・10日・11日)を1日ごとに分けて、同じ10種類の名前で403を数え直した。
| 名乗り(User-Agent) | 9/9の403 | 9/10の403 | 9/11の403 |
|---|---|---|---|
| Applebot | 24 | 0 | 22 |
| Twitterbot | 20 | 0 | 18 |
| GPTBot | 41 | 0 | 42 |
| OAI-SearchBot | 57 | 0 | 49 |
| ChatGPT-User | 45 | 0 | 44 |
| Amazonbot | 26 | 0 | 19 |
| ClaudeBot | 19 | 0 | 21 |
| PerplexityBot | 17 | 0 | 22 |
| facebookexternalhit | 13 | 0 | 19 |
| meta-externalagent | 19 | 0 | 20 |
| 合計 | 281 | 0 | 276 |
9月9日は281件、9月11日は276件。ところが9月10日は、10種類とも403が0件だった。同じ名前を持つクローラーが、ある日は合計557件も拒否され、別の日は1件も拒否されない。この差はどこから来るのか。
9/10は、同じ名前が普通に通っていた
9月10日に403が0件だったのは、その日 誰も来なかったからではない。同じ10種類の名前の200(通過)を数えると、GPTBotが52回、ClaudeBotが85回、meta-externalagentが138回、Amazonbotが59回、Applebotが11回。この3日間の中で、いちばん多く読みに来ていたのがこの9月10日だった。つまり、本物とおぼしきクローラーは、この日はいつも通り読みに来て、いつも通り通っていた。403が0件というのは「クローラーが来なかった」結果ではなく、「来たクローラーが1件も拒否されなかった」結果だった。
ここまでの3日間だけでも、同じ「AIクローラーの403」という言葉が、日によってまるで違う出来事を指していたことになる。7日間の合計を見ていたときには、この違いはまったく見えなかった。合計は、良い日と悪い日をならして1つの数字にしてしまう。ならされた数字を見て「平均するとこれくらい弾かれている」と考えるのは、良い日の情報も悪い日の情報も、同じ重みで薄めてしまう考え方だ。
9/9と9/11、数字が揃いすぎていた
10種類の名前で、同じような数字が並んでいた
9月9日と9月11日の内訳を見比べると、もう1つ気になる点があった。10種類の名前ぜんぶに、まんべんなく403がついている。特定の1つの名前だけが突出して多いわけではなく、Applebotが24件、Twitterbotが20件、GPTBotが41件、OAI-SearchBotが57件、ChatGPT-Userが45件、Amazonbotが26件、ClaudeBotが19件、PerplexityBotが17件、facebookexternalhitが13件、meta-externalagentが19件と、10種類とも十数件から五十数件の範囲にそろって並んでいた。9月11日も同じ形で、22件・18件・42件・49件・44件・19件・21件・22件・19件・20件と、やはり全部が近い水準に並んでいた。
本物のクローラーが、それぞれ別のタイミングで、別の理由で当サイトを読みに来ているなら、この10種類の数字がここまでそろって動く理由がない。読みに来る頻度も巡回のスケジュールも、会社ごとにばらばらのはずだ。10種類の数字が同じように動いているということは、この403がすべて、同じ1つの出来事から生まれている可能性を疑う理由になった。この「名乗りだけで数えると、正反対のものが混ざる」という形は、archives/136「AIからの流入60件」を数え直したら、60件ともAIが自分の名前を名乗った文字列だったでも書いた。あのときは、名乗り(User-Agent)の欄にAIの自己紹介URLが入っていて、それが外から紹介されてきたように見えていた話だった。今回は、同じ名乗りの欄そのものが、他人になりすます材料に使われていた。
数字が揃うこと自体は、悪いことではない。むしろ、複数の項目を突き合わせて同じ答えが出たときは、その一致を答え合わせとして使える場面のほうが多い。だが今回のように、本来ばらつくはずの複数の対象(会社も巡回の目的も違う10種類のクローラー)が、示し合わせたように同じ幅の数字で並んだときは、逆に「これは1つの動きの影ではないか」と疑う材料になる。そろっていることが安心材料になる場面と、そろっていることが疑う材料になる場面を、混同しないようにしたい。
発信元を辿ったら、1台だった
403を出した接続元を、逆引きする
疑いを確かめるため、9月9日に403を受けた行のうち、名乗りにクローラー名を含むものだけを、接続元のアドレスで数え直した。9月9日は、この条件に合う281行が、たった1つのアドレスから出ていた。281という数字は、直前の表で10種類の名前を足し合わせた合計とまったく同じだ。つまり9月9日にこの10種類の名前が受けた403は、全部、同じ1つの接続元から出ていたことになる。
逆引きというのは、接続元のIPアドレスから、そのアドレスに割り当てられているドメイン名を調べる作業だ。ドメイン名からIPアドレスを調べる、ふだんの検索とは逆の向きに調べるので、こう呼ばれている。このアドレスを逆引きしてみると、Googleが一般に提供しているクラウドサービス上の仮想サーバーであることを示す名前が返ってきた。個人や会社が自由に契約して動かせる、貸しサーバーの1台だ。
貸しサーバー1台からの記録だった
9月11日も同じ形だった。この日にクローラー名を含む403を受けた行は276件で、これも直前の表の合計276件と一致する。そして276件は、9日とは別の、もう1つの貸しサーバーから出ていた。日をまたいで、毎回ちがう1台が、その日の403をまるごと引き受けている。
本物のGPTBotやClaudeBotが、それぞれの会社が管理する巡回用の設備からアクセスしてくるのに対して、この2台はどちらも、誰でも契約すれば借りられるクラウドの仮想サーバーだった。GPTBotやOAI-SearchBotを名乗って現れたアクセスの発信元が、その会社の設備ではなく、貸しサーバーだったという事実だけで、名乗りが本物でないことはほぼ確定する。
ここで気をつけたいのは、「貸しサーバーから来ている=すべて偽物」と決めつけてはいけないということだ。世の中には、正規のサービスがクラウド上の仮想サーバーで動いていて、そこから当サイトへ普通にアクセスしてくるケースもある。今回それでも「偽物だ」と判断できたのは、貸しサーバーであることに加えて、名乗りの内容(GPTBotやOAI-SearchBotという、特定の会社が公表している名前)と、発信元の実態(その会社の設備ではない)が食い違っていたからだ。発信元だけでも、名乗りだけでも、判断材料としては足りない。両方を突き合わせて、初めて言い切れる。
約2秒で636回、数十の名前を使い分けていた
同じ数秒に、何を名乗っていたか
9月9日のこの1台が出したアクセス全体の行数を数えると636行あった。時刻を見ると、そのほとんどが同じ数秒の間に集中している。1つの記録を境に、名乗りが目まぐるしく入れ替わっていた。SNSのメッセージアプリのプレビュー生成、別のSNSカードの取得プログラム、そしてGPTBotやOAI-SearchBotという名前が、数秒の間に次々と現れては消えていく。9月11日のもう1台も同じ形で、Perplexity-User、GPTBot、LinkedInBotなど、やはり数十の名前を短い間隔で切り替えながら、同じページ(トップページ)にアクセスしていた。
1つのプログラムが、数十種類の名乗りを数秒おきに切り替えながら同じ相手に接続する。これは、正規のクローラーがそれぞれの役割に応じて名乗る動きとは、あきらかに違う。むしろ「このサイトは、どの名前ならログを通してくれるか」を、片っ端から試しているように見える動きだ。
281件・276件 ── 合計と、発信元の行数が一致した
ここまでの数字を、あらためて並べてみる。9月9日、10種類の名前で数えた403の合計は281件。同じ日に、その10種類の名乗りを使って403を受けた行を、接続元ごとに数え直すと、1台の貸しサーバーだけで281行。9月11日も、10種類の名前の合計403は276件、そして1台の貸しサーバーの行数も276件。合計と、発信元の行数が、2日とも1件のずれもなくぴったり重なった。
この一致は、9日と11日に限れば、当サイトが受けたこの10種類の名前の403が、実質すべて、この2台の貸しサーバーから出ていたことを意味している。7日間の合計403、1,250件のうち、少なくとも557件(44.6%)は、この2日分だけで、2台の貸しサーバーから出ていたことが分かった数字だ。残る5日分(9月5日から9月8日まで)を同じ形で確かめる作業は、まだやっていない。✅ 公開した日のうちに確認済み(末尾の追記) この記事の時点で言えるのは「少なくとも557件」までで、実際の割合はもっと高い可能性がある。
逆に、本物が1か月 弾かれていた日もあった
3日前に見つけた、もう1つの403
ここまでは「本物のふりをした偽物」の話だった。だが3日前(9月8日)、当サイトでは別の確認作業で、これとは正反対の問題を見つけていた。本物のApplebotとTwitterbotの一部が、約1か月ものあいだ、当サイトの制限に引っかかって403を受け続けていたことが分かったのだ。当サイトは海外からのアクセスを制限しているが、この2つの名乗りについては、確認のしかたに漏れがあった。1か月という期間、誰も気づかなかったのは、この403もまた、他の海外からのアクセスをまとめて拒否した記録の中に、同じ「403」という数字として埋もれていたからだ。偽物を通してしまう見落としと、本物を止め続ける見落としは、原因はまったく逆なのに、記録の中では見分けがつかない形で残る。同じ日のうちに、原因に気づいて直した。この「検証は、仕組みが正しいかだけでなく、前提が正しいかも確かめる必要がある」という考え方は、archives/141「アクセスが0でした」と言われて調べたら、仕組みは全部 正常だったで書いたのと同じだ。
直した帯は、9/9以降 0件
直した後、確認のしかたを正しく通した先のApplebotとTwitterbotが、その後どうなったかを日別に確かめておいた。
| 日付 | 200 | 301 | 404 | 403 |
|---|---|---|---|---|
| 9/9 | 19 | 1 | 0 | 0 |
| 9/10 | 10 | 0 | 0 | 0 |
| 9/11 | 19 | 0 | 1 | 0 |
9日は200が19件、301(転送)が1件。10日は200が10件。11日は200が19件、404(該当ページなし)が1件。3日間とも、403は1件も出ていない。301も404も、リンク先が移動した、あるいは存在しないという通常の応答で、拒否とは違う。約1か月 止めていた本物のクローラーを、直した日から確実に通せていることが、これで確認できた。
7日間の合計だけを見て「AI検索のクローラーがまだ大量に弾かれている」と判断し、通す設定に変えていたら、この2つの問題が入れ替わって見えていたはずだ。すでに直っている本物の通り道を、さらに緩めることになる一方で、本物のふりをした貸しサーバーからのアクセスは、名乗りで通す設定を作った分だけ、素通りしやすくなる。直すべき方向がまったく逆の2つの問題が、同じ「403」という1つの数字の中に同居していた。
名乗りだけでは、本物かどうか分からない
User-Agentは自己申告
訪問者の名乗り(User-Agent)は、アクセスしてくる側が「自分はこういうプログラムです」と、自分で書いて送ってくる項目だ。ブラウザが自分の種類を名乗るのと同じ仕組みを使って、クローラーも自分の名前を名乗る。だが、その文字列が本物かどうかを検証する仕組みは、通信そのものには存在しない。名乗りの文字列をそのままコピーして送れば、誰でも「GPTBotです」と自己申告できてしまう。
Googleの公式ドキュメントは、Googlebotをはじめとする自社のクローラーについて、確かめる方法を2つ挙げている。
"Verify that the domain name is either Googlebot.com, google.com, or googleusercontent.com."
(日本語訳: ドメイン名がGooglebot.com、google.com、googleusercontent.comのいずれかであることを確認する)
逆引きしたドメイン名を確認したら、次はそのドメイン名をもう一度 正引きして、同じIPアドレスに戻ることまで確かめる。この往復を行う理由は、逆引きの設定だけなら比較的簡単に用意できてしまうからだ。
ここで、今回見つかった貸しサーバーのドメイン名について、もう一つ補足しておきたい。逆引きした名前の末尾は、確かに「googleusercontent.com」だった。Googleの同じ公式ドキュメントには、この名前が正規のGoogle関連のアクセスに使われるケースも書かれている。
"IPs in the user-triggered-fetchers.json object resolve to gae.googleusercontent.com hostnames."
(日本語訳: user-triggered-fetchers.jsonに載っているIPは、gae.googleusercontent.comというホスト名になる)
公式のケースでは、名前の間に「gae」という文字列が入る。今回 見つかった名前には、この「gae」が無かった。同じ「googleusercontent.com」という末尾でも、間に何が入っているかで意味が変わる。Google Cloud上で誰でも借りられる仮想サーバーには、既定でこの形式の逆引き名が自動的に割り当てられる。今回の2台は、Googleの公式サービスとしての名前ではなく、誰かが契約した1台の仮想サーバーとしての名前だった。
確かめる2つの方法
逆引きは、1件ずつ手で確かめるのに向いている。大量のアクセスをまとめて確かめたいときは、各社が公開しているIPアドレスの範囲の一覧を使う方法がある。OpenAIは、GPTBot・OAI-SearchBot・ChatGPT-Userそれぞれについて、IPアドレスの範囲を一覧にしたファイルを公開しており、公式ドキュメントはこの一覧を使うことを勧めている。
"we recommend allowing OAI-SearchBot in your site's robots.txt file and allowing requests from our published IP ranges below."
(日本語訳: OAI-SearchBotをrobots.txtで許可し、公開されているIPアドレスの範囲からのリクエストも許可することを推奨する)
Anthropicも同じ形でクローラー用のIPアドレスの一覧を公開しており、Perplexityは、PerplexityBotとPerplexity-Userそれぞれの一覧を別々に公開している。Appleは、逆引きの確認方法と、IPアドレスの一覧の両方を、Applebotについて公開している。
"The host command can also be used to verify that the DNS points to the same IP address."
(日本語訳: hostコマンドを使って、DNSが同じIPアドレスを指しているかも確認できる)
会社によって、公開している確認方法の形は少しずつ違う。だが共通しているのは、名乗りの文字列そのものは確認手段にならないという前提だ。名乗りを見て「本物らしいから通す」という判断は、最初から成立しない。
今回、10種類のうちAI検索に関わる主なクローラー(GPTBot・OAI-SearchBot・ChatGPT-User・ClaudeBot・PerplexityBot)とAppleについては、この公式の確認方法にたどり着けた。一方でX(旧Twitter)は、同じような確認ページも、公式のIPアドレス一覧も見当たらなかった。公表している会社と、していない会社があるという事実そのものも、確認する側が覚えておくべきことだと思う。Amazonbot・facebookexternalhit・meta-externalagentの3つについては、今回 疑わしい動きは見当たらなかったが、公式な確認方法まではまだ照らし合わせていない。✅ 公開した日のうちに照合済み(末尾の追記) 名乗りの種類が増えるほど、確認すべき相手も増えていく。
WEBディレクターが今日からできること
当サイトの現在地
今回の一件から、明日からの確認に持ち込めることを整理しておく。
| やること | 当サイトの現在地 |
|---|---|
| 名乗り(User-Agent)だけで合計を出さない | ✅ 当サイト実施済 |
| 7日や1か月の合計ではなく、1日ごとに割って確かめる | ✅ 当サイト実施済 |
| 気になる日は、接続元を逆引きするか、公式のIPアドレス一覧と照らす | ✅ 当サイト実施済(7日分・2026-09-11) |
| 残り5日分(9/5〜9/8)も同じ形で確認する | ✅ 当サイト実施済(2026-09-11) |
| 毎週、この内訳を自動で出す仕組みを作る | ✅ 当サイト実施済(2026-09-11・毎週月曜) |
| Applebot以外の主要なクローラーについても、通す設定を定期的に見直す | 📋 予告 |
週に1回、名乗り別・日別・発信元別の内訳を自動で出すところまでは、まだ仕組みにできていない。✅ 公開した日のうちに仕組みにした(末尾の追記) 今回のように「気になったから手作業で調べる」だけでは、確かめる日が偏ってしまう。
自分のサイトでも、今日から確かめられる
専用のログ分析の仕組みが無くても、逆引きだけなら手元のパソコンから今すぐ試せる。WindowsでもMacでも、コマンドを実行する画面(Windowsなら「コマンドプロンプト」、Macなら「ターミナル」)を開いて、次のように入力する。
nslookup 調べたいIPアドレス
Macや、Windowsに用意されているUNIX互換の環境であれば、公式ドキュメントと同じhostコマンドも使える。
host 調べたいIPアドレス
返ってきたドメイン名が、その名乗りを公表している会社のドメイン(Googlebot.com・applebot.apple.comのように)で終わっていれば、まず本物と考えてよい。bc.googleusercontent.comのように、会社名ではなくクラウドサービスの一般的な名前で終わっている場合は、疑ってかかったほうがいい。気になる403の行を1件、2件、手で確かめるだけでも、今回のような一括りの偽物に気づける可能性は十分ある。
アクセスログの中から不審な兆候を自分で探したいときは、🔧 IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツール(利用には無料の会員登録が必要です)が役に立つ。サイト全体を外から見た対策の状態を一度に確認したい場合は、🔧 WEBサイトの 外からできるセキュリティ対策監査ツール(利用には無料の会員登録が必要です)も候補になる。
AI検索のクローラーの名前そのものの扱いについては、AIクローラーは1つではない ── robots.txt・llms.txtで「通す」「止める」を切り分ける(2026年9月時点)で、名乗りごとの違いを整理している。GoogleのクローラーIPアドレスの公開先が変わった件は、GoogleクローラーのIPレンジJSONファイルが新しい場所へ ── 自社の設定で確認する13項目(2026年9月時点)にまとめてある。
まとめ
7日分の合計だけを見て、「AI検索のクローラーが弾かれすぎている」と判断しかけた。1日ごとに割ったら、そう見える日は2日だけで、残り1日はむしろよく通っていた。発信元まで辿ったら、その2日分の403は、実質1台ずつの貸しサーバーが、10種類の名前を使い分けて作っていた数字だった。
同じ「403」という数字の中に、通してはいけないもの(貸しサーバーからの偽の名乗り)と、通して正しいもの(普段どおり読みに来た本物のクローラー)、それに直すべきなのに直っていなかったもの(本物のApplebot)が、3種類まとめて混ざっていた。名乗りで合計を出す集計は、この3種類を1つの数字に溶かしてしまう。日別に割り、発信元まで辿って、初めて別のものとして見えてくる。
設定を変える前に、あと1段 確かめる。今日 覚えておきたいのは、その1段を惜しまないことだ。合計が大きいことも、合計が0であることも、それだけでは何も証明していない。日ごとに割り、発信元まで辿って、初めてその数字が何を指しているかが分かる。
追記(2026年9月11日 夜)── 「これから」と書いた3つを、同じ日のうちに確かめた
この記事では、まだ確かめていないことを3つ、「これから」と書いていた。残り5日分の内訳、Amazonbot・facebookexternalhit・meta-externalagentの3つの名乗りを公式の方法で照らすこと、そして毎週この内訳を自動で出す仕組みだ。公開した日の夜に、3つとも確かめ終えたので、結果をここに足しておく。
残り5日分も、同じ形だった
9月5日から9月8日までの4日分を、本文と同じやり方で確かめた。1日ごとに割り、403を受けた行を接続元ごとに数え直す方法だ。9月6日は403の297件のうち259件、9月8日は321件のうち293件が、それぞれ1台の貸しサーバーから出ていた。どちらの1台も、その日に現れたのは1〜2分だけで、その短い時間に数十の名前を名乗りながら、数百回アクセスしていた。9日と11日に見つけた形と、まったく同じだ。
一方、9月5日(45件)と9月7日(30件)には、こうした「1台からの波」は無かった。この2日の403は、30前後の接続元に1〜3件ずつ散らばっていて、1つずつ逆引きすると、すべて本物のAppleとX(旧Twitter)の設備だった。本文の後半に書いた、3日前に直すまで弾いてしまっていた、本物の側の403である。
| 日付 | 403の合計 | 1台の貸しサーバーから | 本物の設備から(Apple・X) |
|---|---|---|---|
| 9/5 | 45 | 0 | 45 |
| 9/6 | 297 | 259 | 38 |
| 9/7 | 30 | 0 | 30 |
| 9/8 | 321 | 293 | 28 |
| 9/9 | 281 | 281 | 0 |
| 9/10 | 0 | 0 | 0 |
| 9/11(18時すぎまで) | 567 | 567(2台) | 0 |
| 合計 | 1,541 | 1,400(90.9%) | 141 |
「少なくとも557件」は、実際にはもっと多かった
本文では、9月11日の午前までの7日分について「1,250件のうち、少なくとも557件」と書いた。同じ範囲を全部確かめると、1,250件のうち1,109件(88.7%)が貸しサーバーから出ていた。残りの141件は、すべて本物のAppleとXの設備からだった。
そして9月11日の午後3時49分、それまでとは別の1台が、もう1度 同じ形の波を送ってきていた。9月11日の18時すぎまでを含めた7日間では、1,541件のうち1,400件(90.9%)が、合わせて5台の貸しサーバーから出ていたことになる。5台はどれも、7日間のうち1日しか現れていない。毎回ちがう1台が来て、その日の403をまるごと作っていく形が、7日間のうち5回あったということだ。
もう1つ分かったことがある。本物のAppleとXが最後に403を受けたのは、9月8日の午後だった。その日に通す設定を直してからは、9月11日の18時すぎまで、本物のApplebotとTwitterbotが弾かれた記録は1件も無い。直したことが効いているかを、数字で確かめられたのは、これが初めてだった。
残りの3つの名乗りも、公式の方法で照らした
本文で「まだ照らし合わせていない」と書いた3つの名乗りも確かめた。Amazonbotは、Amazonが公式ページで公開しているIPアドレスの一覧(2026年9月8日時点で約1,300件)と照らした。facebookexternalhitとmeta-externalagentについては、Metaは公式ページで「名乗りか、より安全な方法としてIPアドレスで許可するように」と案内しているが、IPアドレスの一覧そのものは載せていない。そこで当サイトは、Metaのネットワークとして一般に知られているAS32934のアドレス範囲と照らした(AS32934という番号は、Metaの公式ページには書かれていない)。
結果は3つとも同じだった。7日間にこの3つの名前で403を受けた316件は、すべて上の5台の貸しサーバーからだった。7日間にアクセスしてきた本物の発信元(Amazonbot 225、facebookexternalhit 120、meta-externalagent 160)は、1件も403を受けていない。facebookexternalhitは、公式ページにもあるとおりページの一部だけを取りに来ることが多く、120のうち57の発信元は、その「一部だけを返す」応答(206)だけを受けていた。
照らす途中で、1つ気づいたことがある。Amazonbotの公式一覧から40件を選んで逆引きすると、Amazonbot専用の名前が返ったのは3〜4割ほどで、残りはAmazonのクラウドで一般的に使われている名前だった(40件ずつ2回選び、専用の名前は11件と15件)。逆引きの名前だけで判定すると、本物の多くを「確かめられない」に分類してしまう。Amazonbotについては、逆引きより、公式のIPアドレス一覧と照らすほうが確実だ。確かめ方は、相手の会社ごとに選ぶ必要がある。
毎週、この内訳を自動で出すようにした
「まだ仕組みにできていない」と書いた週1回の内訳も、同じ日のうちに自動で出るようにした。毎週月曜の未明に、直近7日分を名乗り別・日別・発信元別に割り、1台から大量に来た「波」があれば、その発信元を逆引きした結果とあわせて1本の報告にまとめる。9月5日から11日までの分を試しに出してみて、上の表と1件の違いも無く一致することを確かめた。
自動で出すのは内訳までにしている。通すか止めるかを決めるのは、今もその報告を読んだ人だ。合計だけを見て設定を変えかけたのが、この記事の出発点だった。だから、判断の前に内訳が手元に届く形にしておきたかった。
関連 archives(連載軸として読む)
- archives/141「アクセスが0でした」と言われて調べたら、仕組みは全部 正常だった ── 壊れていたのは「誰が見に来ているか」の前提 ── 「誰が」を疑う視点が今回にもつながった回
- archives/140『0件には三つの顔がある』と書いた記事が、三つ目の顔を踏んでいた ── サイトへのアクセスの94%を、52日間 見ていなかった ── 合計だけを見て安心する危うさ
- archives/138 外部から来た人は19人だけだった ── アクセスログの「参照元」の95.1%は、自分のサイトからの移動だった ── 同じログを別の項目で確かめた回
- archives/137 AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた ── ログの読み方そのものを見直した回
- archives/136「AIからの流入60件」を数え直したら、60件ともAIが自分の名前を名乗った文字列だった ── ログを行全体で探すと、正反対の2つが混ざる ── 名乗りが混ざる形の初出
出典
- Google Search Central: Verifying Google's crawlers and fetchers
- OpenAI Developer Platform: GPTBot, OAI-SearchBot, and ChatGPT-User
- OpenAI: GPTBot IPアドレス一覧(JSON)
- Anthropic Help Center: Does Anthropic crawl data from the web?
- Anthropic: クローラーIPアドレス一覧(JSON)
- Perplexity: Crawlers
- Apple Support: About Applebot
- Apple: Applebot IPアドレス一覧(JSON)
- Amazon Developer: Amazonbot
- Amazon: Amazonbot IPアドレス一覧
- Meta for Developers: Webmasters / Crawler
WEBサイト