夜11時半、私はpaulkuo.twのトップページを開き、トラフィック分析ブロックを一瞥した。

訪問者：0。

おかしい。今日は誰かが私の記事を読み、翻訳ツールも使われている。昨日のデータは既に数百人の訪問があり、今日いきなりゼロになるはずがない。Cloudflare Dashboardを開いて確認すると——Page views 193、Visits 130。

ゼロと130は誤差ではなく、まったく異なる二つの世界である。果たして「誰も来なかった」のか、それとも「百数十人が既に訪れた」のか。どちらが正しいのか、それとも両方間違っているのか？

Cloudflareの二つの世界

あなたのウェブサイトがCloudflare上にある場合（世界で4,100万を超えるウェブサイトがそうである）、Cloudflareには実際まったく異なる二つの分析システムがあることを知らないかもしれない。

第一のシステム：Zone Analytics（HTTP Traffic）。 これはCDN層のデータである。Cloudflareネットワークを通過するすべてのHTTPリクエストが記録される。これは総リクエスト数、帯域幅、国別分布、unique visitors（IPで重複排除）を教えてくれる。正確で、Googleのクローラー、ChatGPTのcrawler、各種監視botを含め、すべてを計算する。

第二のシステム：Web Analytics（RUM beacon）。 これはブラウザ層のデータである。Cloudflareはあなたのウェブページに一段のJS beaconを注入し、実際の人がブラウザでページを読み込んだ時のみトリガーされる。BotはJavaScriptを実行しないため、非人間トラフィックを自然にフィルタリングする。

私はトラフィック分析アーキテクチャを設計する際、一度の反復を経て、後にWeb AnalyticsのGraphQL APIを主要データソースとして選択した。理由をつなげると非常に合理的で、実際の人のみを計算し、より正確である。最初はZone Analyticsを使う道を選んだが、botを含むため数字が高めだった。ウェブサイトを設定したばかりで、一日で千Visitという状況だった。

ロジックに問題はなかった。しかし私は一つのミスを犯した：「このAPIがどのようなデータフィールドを提供できるか」は検証したが、Web Analytics（RUM beacon）が「私に与える数字が正確か」は検証しなかった。

Adaptive sampling：130を0にする

調査の結果、根本原因を突き止めた。CloudflareのWeb Analytics GraphQL APIは、Adaptive Bit Rate（ABR）と呼ばれるサンプリング技術を使用している。

原理は複雑ではない：Cloudflareは毎秒7億を超えるイベントを処理している。すべてのクエリが全原始データをスキャンする必要があれば、システムはより多くのコストを支払わなければならない。そこで、データを複数の解像度——100%、10%、1%——で保存している。クエリの際、システムはデータ量と複雑度に基づいて、自動的に一つの解像度を選択して結果を返す。

高トラフィックウェブサイトにとって、これは全く問題ない。日訪問者が十万人なら、10%サンプリングでも一万件あり、統計的に精度は高い。

では低トラフィックウェブサイトはどうか？私のpaulkuo.twは一日約130人の実際の訪問者がいる。APIサンプリング後、返されるvisitsはすべて100の整数倍——0、100、200である。130は四捨五入されて0になった。

過去30日間のAPIデータを調べてみると、visits = 0の日がいくつかあり、すべての数値が100の倍数であることを発見した。これは「今日壊れた」のではなく、運用開始初日からこのロジックだったのである。ただ、今日初めてAPIデータとDashboardを比較しただけだった。

後にCloudflareの文書を調べると、現在ユーザーがクエリ結果の正確性を検証する方法がないことを認めている。つまり、ある数字を得ても、その数字の誤差範囲を教えてくれる人はいないということである。

さらに大きな数字がある

Web Analyticsのサンプリング問題を理解し、Zone Analyticsを見ると——Unique Visitorsの数字は1,100だった。

Web Analytics Dashboardは130と言う。Zone Analyticsは1,100と言う。APIは0と言う。

三つの数字、同じ日、同じウェブサイト。

1,100と130の差——その千近い「余分な訪問者」がbotである。私のウェブサイトは最初の設計からAI-friendlyで、llms.txt、JSON-LD、MCPサポートがあり、すべてAIシステム用に設計されている。そのためGPTBot、ClaudeBot、Bingbotなどのクローラーが勤勉にコンテンツを取得しに来る。Zone Analyticsは人間か機械かに関わらず、すべてのIPを忠実に記録している。

Impervaの2025年レポートによると、自動化トラフィックは2024年に初めて人間の活動を超え、世界のネットトラフィックの51%を占めた。その中で悪意あるbotが37%を占める。Cloudflareの2025年度レビューでも、AI botのHTMLページへのリクエストが4.2%、Googlebot一社だけで4.5%を占めることが示されている。

つまり、私のウェブサイトの88%のunique IPがbot、12%が実際の人間である。非常に誇張されているように聞こえるが、統計的には完全に合理的である。今年一月から、“Make something Agent Want”が技術界の共通認識になったことを明らかに感じている。そのため、ウェブサイトが実際の人のVisitのみを見るという執念を再検討することになった。

私が間違えた三つの道

現在の解決策を見つける前に、私は三つの間違いを犯した。

第一の間違い：計画時に技術偵察をしなかった。 Web Analytics RUMを主要データソースとして選択する前に、adaptive samplingの行動制限を調べず、APIの返り値とDashboardを交差検証しなかった。当時5分間この作業をしていれば、問題全体が計画段階で発見されていただろう。

第二の間違い：問題発見後の性急な修復。 私は直感的に「Zone-level APIのサンプリング粒度の方が良いはず」と判断し、依然として「人間中心」の執念を持ち、修正版を書いてGitHubにプッシュした。プッシュ後にCloudflareコミュニティでzone-level APIにも同じvisits=0問題があることを誰かが報告しているのを発見した。そこでrevert。往復で時間を無駄にし、git historyも汚染した。

第三の間違い：「botを含まない」と「正確」を同一視した。 Web Analyticsは確実に実際の人のみを計算するが、「botを含まない」ことが「数字が正確」であることを意味するわけではない。サンプリング精度とbotフィルタリングは完全に独立した二つのことである。私はそれらを混同して見ていた。

私とAI Agentの工程原則は、まず偵察してから手を動かすことだが、AI にも漏れがあり（奇妙なことに、既にskillに書いてあるのに）、私にもある。しかし人は問題を発見した時、特に急いで修復しようとし、やるべき勉強をスキップしがちである。

完全な観客の輪郭を見る

最初私はbotトラフィックをノイズとして扱い、排除しようとした。しかしpaulkuo.twはAI-Readyアーキテクチャ設計を持っている——llms.txtでAIシステムがウェブサイト構造を理解し、JSON-LDが構造化知識を提供し、MCPプロトコルでAI agentが直接操作できる。そのため、AI botにコンテンツを読ませることは、ノイズではなく、影響力の一部でもある。

正しい問題は「botをどう排除するか」ではなく、「完全な『読者観客』をどう見るか」に変わった。

私には二つの独立した指標が必要である：

  • 実際の人の訪問者：何人の人間の読者が私の記事とツールを見たか——これは旧世界でコミュニティ影響力を測る核心指標
  • AI/Bot訪問者：何個のAIシステムが私のコンテンツを読み取っているか——これはAI-Ready戦略の効果指標

最終的なアーキテクチャも複雑ではない。実際の人の訪問者は自前のvisit beaconを使う——ページロード時に私のCloudflare Workerに一つのPOSTを送り、WorkerはIP + User-Agentの匿名ハッシュで日次重複排除を行う。全サイト訪問者は引き続きZone Analyticsの正確なIP重複排除を使う。二つを引けばAI/Botの量となる。 paulkuo.twトラフィック分析アーキテクチャ図：自前beacon（実際の人）+ Zone Analytics（全量）→ 差分計算AI/Bot

三つの数字すべて自分で計算し、Cloudflareの推定に依存しない。やり方はGoogle Analytics、Plausible、Umamiなどウェブサイトトラフィック分析ツールの原理と同じである。ウェブページに追跡コードを埋め込み、自分で人数を数え、すべてを計算する。ただし第三者ツールを追加でインストールする必要がなく、ウェブサイト既存のサーバー上で直接動作する。

あなたのデータが誤解を招く可能性がある

2025年、自動化トラフィックが初めて人間の活動を超え、世界のネットトラフィックの51%を占めた。AI crawlerのクロール量は同年15倍以上増加した。あなたのウェブサイトは人間だけでなく、機械にも読まれている。

あなたのウェブサイトがCloudflare Web Analyticsのfree planを使用し、日訪問者が数百以下であれば、ダッシュボード上のvisits数字は、私と同様、サンプリング後の推定値であり、正確な値ではない可能性が高い。

これはCloudflareが使えないということを意味するのではない。そのCDN、DNS、セキュリティ防護は業界トップクラスである。Web AnalyticsのDashboard UIの数字は正確である。しかしAPIを使ってデータを自分のダッシュボードに引き出す場合、低トラフィックシナリオでは、自分で一度検証する必要がある。APIが返す数字とDashboardを比較すれば、5分で答えがわかる。

データの落差が大きすぎる場合、ウェブサイト運営者はより直接的な方法に戻り、自ら正確な訪問カウント機構を構築する必要があるかもしれない。これはCloudflareが信頼に値しないからではなく、サンプリングがトラフィック規模がまだ小さい時に、先天的に不正確になりやすいからである。受け手規模の拡大とともに、サンプリングの精度は自然に段階的に向上するが、トラフィックがまだ成長段階にある時こそ、正確な数字が最も不可欠である。それは方向性の判断と戦略調整の重要な時期だからである。

ウェブサイト運営は感覚だけに頼ることはできず、データは健康診断報告書のようなものである。最も基本的な到達人数さえ正確に把握できなければ、自分の体重、体脂肪、生理指標を全く知らないのと同じで、いわゆる改善と成長も、明確で根拠のある判断に基づいて構築するのは困難である。