合計 14,192 件の中に、止めてはいけない 234 件が埋もれていた

今回の登場人物

ロン（Ron）

AI パートナー / WEB サイトサポート・プロデューサー

Web サイトの運用と記事づくりを担当している。1 ヶ月「正常」と読んでいた合計を割り直し、止めてはいけない相手を止めていたのを自分で見つけて直した。通すときも、名乗りを信じずに 1 つずつ逆引きした。

2026 年 9 月 8 日の午後。仲間のロンは、オーナーに言われて、サーバーのエラーログを開きました。

そこには、直近 7 日分で 14,192 件のアクセス拒否（AH01797）が記録されていました。
ロンはこの数字を、8 月 7 日から 1 ヶ月、こう読んでいました ── 国ごとのアクセス制限が、正しく弾いた記録だと。

合計だけを見れば、その読みは自然です。制限を入れれば、拒否は増える。増えているのは、制限が効いている証拠に見えます。

合計を、相手ごとに割った

ロンは合計を、アクセスしてきた相手（クローラー）ごとに割りました。比べるために、止めていないはずの相手も並べています。

Googlebot と bingbot は、1 件も拒否されていません。比べ方が壊れていないことは、この 2 行で確かめられます。
そのうえで、Applebot は 234 回来て、1 回も通されていませんでした。

原因は、許可するネットワークの一覧でした。Apple のクローラーが使うネットワークは 33 あるのに、一覧には 3 つしか入っていなかったのです。

装置は、毎週正しく言っていた

ここがこの話の芯です。

ロンの家には、クローラーのネットワーク一覧を毎週取り直す仕組みがありました。その仕組みは毎週、正しく 33 件を取っていました。
そして毎回、設定そのものは一切変更していない、反映するかどうかは人間の判断だ、と出力していました。

取ってくる側は正しく動き、正直に自分の限界を言っていた。それでも 1 ヶ月、3 つのままでした。ロンはこう書いています。

その【人間の判断】が、誰の日課にも入っていませんでした。

ロンは Applebot を止めていたことを見つけて、直しました。

同じ日に、残りの 2 つも直しています。

ChatGPT-User は、公式に公開されているネットワーク範囲 4 つを許可に足しました。

Twitterbot は、オーナーから許可リストに入れるよう言われたとき、すぐには足しませんでした。Twitterbot を名乗ってきた 12 の IP を、1 つずつ逆引きしたのです。
本物は 8 つ（X 社のネットワーク）。残りの 4 つは、クラウドの貸しサーバーからの偽物でした。ロンは本物の 8 つだけを通しています。

2 日後の 9 月 10 日には、ChatGPT-User も Twitterbot も、拒否は 0 件になっていました。

ただし、直したあとも Twitterbot の拒否が記録される日があります。9 月 9 日と 11 日には、数十のクローラーの名前を順番に名乗る貸しサーバーが、日ごとに別の 1 台ずつ来て、正しく拒否されていました。名前だけで数えると、直したはずのものが、まだ弾かれているように見えます。

この 2 日間に何が起きていたかは、ロンが自分のブログに書いています。7 日分の合計では AI クローラーが軒並み弾かれて見えたものを、日ごとに割って確かめた記録です ── 「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだった

2 件目 ── 毎朝の「エラー: 3」

同じ午後、ロンは 2 件目を見つけています。

その少し前に私（ブライアン）は、自分のサイトで解析が 404 のページを 490 日 測り続けていた話を書いて、ロンに測り方を渡していました。

1. 解析が「収録しているページ」の一覧を出す
2. その URL を、実際に 1 件ずつ叩く（一覧を眺めるだけでは分からない）
3. 在ると分かっているページを 1 本、一緒に混ぜておく

ロンがこれを自分の家で踏むと、毎朝 6 時 4 分に届くレポートが、ずっと 「エラー: 3」と出し続けていたことに行き当たりました。誰も開いていませんでした。

開いてみると、サイトマップのページから辿った記事ページが 404 を返していました。
追いかけると、本番のサイトマップに載っていた 60 本は、テスト環境のデータベースの記事でした。本番で公開している 71 本は、1 本も載っていませんでした。

原因は、読み込む場所の候補を順番に試す作りにありました。1 番目の候補が解決せず、2 番目に落ちていたのです。落ちたことは、どこにも表示されていませんでした。

ロンは直しました。サイトマップは 60 本から 71 本になり、404 は消え、71 本すべてが 200 を返すことを確かめています。

合計が正しいと、内訳を見に行かない

私が 490 日の話で書いた一文は、これでした。

合計が合っていると、内訳を見に行く動機そのものが消える。

ロンは、自分の家での形をこう書いてくれました。

俺の家では「合計が 14,192 件 出ていたから、誰も 234 を見なかった」でした。

2 件とも、数字は出ていました。拒否の件数も、レポートのエラー数も。
出ていたから、中身を確かめる理由が見つからなかった。ロンが開いたのは、オーナーに、たまにはサーバーのエラーログも見て、直すべきは直しておくように、と言われたからです。そしてロンは、その確認を毎日の手順に入れました。

【技術コラム】明日そのまま使える 4 つ

1. 拒否の記録は、合計ではなく「誰を拒否したか」で割る。
   アクセス拒否が多いこと自体は、制限が効いている証拠にも、止めてはいけない相手を止めている証拠にもなります。相手ごとに割り、止めていないはずの相手を比較として並べる。今回は Googlebot と bingbot が「拒否 0」だったので、割り方が正しいことをその場で確かめられました。
   そして、名前（User-Agent）は誰でも名乗れます。許可に足す前に、IP を逆引きして本物か確かめる。今回は 12 のうち 4 つが偽物でした。
2. 反映を人間に任せる仕組みがあるなら、その判断を誰の日課に置くかを決める。
   正しいデータを取ってくる仕組みと、それを設定に反映する手順は別物です。前者が毎週動いていても、後者が誰の予定にも無ければ、設定は古いまま残ります。
3. 毎朝のレポートの「小さなエラー」を、一度は開く。
   「エラー: 3」のように変わらない数字は、見慣れた風景になります。中身を開くと、まったく別の問題が入っていることがあります。
4. 候補を順番に試して、黙って次に落ちる作りにしない。
   1 番目が見つからないときに 2 番目へ落ちるなら、落ちたことを必ずログやレポートに出す。できれば、落ちずにエラーで止まる作りにする。黙って落ちると、動いているように見えたまま、別のものを読み続けます。