【ITニュース解説】Most of my robots were me
2026年11月02日に「Dev.to」が公開したITニュース「Most of my robots were me」について初心者にもわかりやすく解説しています。
ITニュース概要
Webサイトのアクセスを解析すると、ロボットの訪問者数に大きな誤解があった。大半はSNSのリンクプレビューや、自身のサーバーが正常かを確認する通信だったのだ。正しい分析には、数字の内訳を詳細に確認し、不要なアクセスを正確に除外する作業が欠かせない。主要なロボットは意外にもHTTPヘッダーで自身の情報を提示していた。
ITニュース解説
ある開発者が自身のウェブサイトに、訪問してくる「ボット(自動化されたプログラム)」の数を数えるためのツールを導入した。目的は、どれくらいのボットがサイトを訪れているのか、そしてそのボットが誰によって運営されているのかを知ることだった。しかし、この調査を通じて、彼はウェブサイトのアクセスデータがどのように構成されているかについて、大きな誤解を抱いていたことに気づくことになる。
まず、開発者が新しい記事をSNSに投稿し、数分後にアクセス状況を確認すると、「5回の閲覧、62体のボット」という結果が表示された。彼はたくさんのボットが自分のサイトに興味を持って訪れてくれたと喜びを感じた。しかし、これは最初の大きな誤解だった。実際には、FacebookやLinkedInといったSNSが、記事のプレビューカード(リンクを貼ると表示される、記事のタイトルや画像を含む小さな情報)を作るために、何度もウェブサイトのページを取得していたのだ。彼がSNSにリンクを共有する行為が、まるで多くのボットがサイトをクロールしているかのように見えていた。本来のAIクローラー(例えばGooglebotやGPTBotのような、検索エンジンやAIが情報を収集するためのプログラム)は、それぞれ1回しかアクセスしていなかったのである。開発者はプレビューカードの作成には1回のリクエストしかかからないと思っていたが、Facebookだけでも130回ものリクエストを送っていたことが判明し、このデータは「読者」ではなく「リンクプレビュー」として区別する必要があることがわかった。
次に、このツールを導入した翌朝、訪問者数が21,791回に達しているのを見て、開発者は再び喜びを覚えた。しかし、このデータも深く掘り下げて分析すると、さらに大きな誤解が含まれていることが明らかになった。彼はデータを種類別に分類したところ、そのうち20,709回ものアクセスが「curl」というクライアントからのものだった。これは一体何だったのか。開発者が運用しているアプリケーション(プログラム)の各コンテナ(システムを動かすための箱のようなもの)には、「ヘルスチェック」という機能が備わっていた。これは、そのコンテナが正しく動作しているかを確認するために、15秒ごとに自身のウェブサイトのトップページに「curl」コマンドを使ってアクセスし、生きているかどうかを判断する仕組みだ。彼が設定したボットを識別するフィルターが、「curl」という単語に一致するように作られていたため、この自身のシステムが行っていた「健康診断」のためのアクセスが、すべて自動化された訪問者(ボット)としてカウントされてしまっていたのである。つまり、ボットトラフィックの95%は、彼のサーバー自身が自身の状態をチェックしていたものだったのだ。
この問題の解決は、コードをたった1行修正するだけで済んだ。しかし、どのデータが信頼できる情報で、どれがノイズなのかを見極めるまでには、多くの試行錯誤があった。アクセス元のソフトウェア名を示す「ユーザーエージェント」を頼りにする方法も考えられたが、これは簡単に偽装されてしまうため、信頼できない。また、アクセスされたページのパス(URL)で判断しようとしても、実際の正規のクローラーもトップページを頻繁に要求するため、これでは正しい判別ができない。最終的に彼が見つけた信頼できる判別方法は、「クライアントアドレスがない」という特徴を利用することだった。自身のヘルスチェックは、ウェブサーバーを介さず直接アプリケーションにアクセスするため、通常は付与されるべきクライアント(アクセス元)のアドレスが記録されない。これにより、「家の中から来た」内部のアクセスだと特定できるようになったのだ。この方法は、将来的にウェブサーバーがクライアントアドレスを正しくアプリケーションに伝えなくなった場合に、実際のボットの数を少なく数えてしまうリスクはあるが、架空のボットを数え続けるよりはましだと判断された。
コードの修正だけでは不十分で、既に記録されてしまっていた2万件以上の「自身の健康チェック」による誤った記録を削除する必要があった。これは単なるデータの整理ではなく、重要な意味を持っていた。なぜなら、ウェブサイトのアクセス数は日ごとの集計や長期的な傾向を比較するための永続的なデータとして保存されるからだ。もし誤った記録をそのまま残しておけば、たとえ今日のシステムが正しくなったとしても、過去のデータはずっと「毎日2万体のボットが訪れた」という嘘の情報を伝え続けることになり、これは将来的に大きな問題となりかねない。彼は最初、クライアントアドレスがないものをすべて削除しようとしたが、その前にクエリ(データベースに指示を出す命令)を慎重に確認したところ、Googlebotのような正規のボットの記録まで消してしまうことに気づき、より厳密な条件で削除を行った。こうして、初日の正確な訪問者数は「26種類のボットファミリーからの914回の訪問」という、当初の印象とは大きく異なる、しかし信頼できる数字に修正された。
最後に、開発者が知りたかった「ボットの運営者が誰か」という疑問にも、予想外の答えが見つかった。HTTP(ウェブ通信のルール)の仕様には、自動化されたクライアントの責任者のメールアドレスを記述するための「From:」ヘッダーという項目があるが、彼はこれがほとんど使われていない古い仕組みだと思い込んでいた。しかし、自身のヘルスチェックによるノイズを除去した後のデータを見ると、66回の訪問でこのヘッダーがきちんと入力されていたのだ。Googlebotは「googlebot@googlebot.com」、Bingbotは「bingbot@microsoft.com」、GPTBotは「gptbot@openai.com」といったように、大手IT企業のクローラーが自らその身元を明かしていた。さらに、一部の小規模なクローラーは、より具体的な問い合わせ先のアドレスまで提供していた。この発見から、彼は「ボットの運営者を知りたいなら、尋ねる必要はない。行儀の良いボットたちは、ずっと自分たちの正体を教えてくれていたのに、自分がそれに気づいていなかっただけだ」という結論に至った。
この経験は、ウェブサイトのアクセスデータを扱う上で重要な教訓を与えてくれる。開発者は、リンクプレビューを読者と誤認し、自身のシステムのヘルスチェックを外部からの訪問者と誤認し、そしてボットが自己紹介をしていることに気づかないという、三つの異なる誤りを犯していた。これらの大きな問題を解決したのは、たった一つの条件の見直しだった。ユーザーエージェントやパスによるフィルタリング、あるいはサーバー自身のネットワーク範囲を除外するといった他の方法では、いずれも不完全であったり、将来的に破綻する可能性があったりした。最終的な教訓は、「どんな数字であっても、それを信頼する前に、その数字が一体何で構成されているのか、きちんと確認するべきだ」というものだ。彼のウェブサイトの訪問者数の95%は、サーバー自身の鼓動だった。この出来事は、システムエンジニアを目指す上で、データ分析がいかに重要で、かつ誤解を生みやすいかを示している。表面的な数字に惑わされず、その裏にある真実を見抜く力が求められるのである。