生成AIストリーム
ネットアクセスの過半数は、もう人間じゃない……機械が読む「Web4時代」のアクセス数の読み方
2026年8月14日 17:28
こんにちは、しらいはかせです。筆者は普段、AICUという会社で『つくる人をつくる』をビジョンに、生成AIやメディア技術の研究・実践を行っています。今回は、Webメディアを運営する立場から見えてきた、静かで大きな地殻変動の話です。テーマはずばり―― ネットアクセスの過半数は、もう人間じゃない 、という話です。
2026年7月13日、CDN大手のCloudflareは『自動化されたボットが初めて人間による活動を上回り、全Webリクエストの約57%を生成するようになった』と発表しました。
これは筆者の体感ですが、実は2025年の時点で、WebはWeb4.0時代へと静かに転換点へ向かっていると考えています。Web1.0=人間が読む。Web2.0=人間が書く。Web3=人間が所有する。そして Web4=機械が読み、機械が動く。この変化を、筆者は「Web4」と呼んでいます。「Web 4.0」は欧州委員会が2023年の戦略で『現実世界とデジタル世界の統合』という意味で使っており、まだ確立した定義ではありません。ブロックチェーンやメタバースやAIといったバズワードだけではなく、Webの世代を実際のアクセスログを使って『誰がアクセスしているか』で並べるとわかりやすくなります。
- 🔗Cloudflare Radar 2025 Year in Review
- https://blog.cloudflare.com/ja-jp/radar-2025-year-in-review/
2025年の「Bot vs. Human」の分析では、HTMLページへのリクエストの内訳は、12月2日時点で人間が47%、非AIボットが44%でした。その後、2026年7月にCloudflareは、自動化されたボットが全Webリクエストの約57%に達し、人間による活動を初めて上回ったと発表しました。今回はこの発表が本当に正しいのか、実際のサイトに訪問してくるWebアクセスデータを使って検証してみたいと思います。
- 🔗Cloudflare Introduces Precursor(2026年・公式プレスリリース)
- https://www.cloudflare.com/press/press-releases/2026/cloudflare-introduces-precursor-one-click-behavioral-defense-against-modern-bots/
もともとネットアクセスの3割は人間ではなかった
ボットによるアクセス自体は、生成AIとともに突然現れたわけではありません。Cloudflare側もそのあたりは真剣に取り組んでおり、「Cloudflare Radar」というサービスでわかりやすく可視化しています。これを見ると「Bot vs. Human」は 35:65といったところです。
Webアクセスには人間による訪問者以外にも、検索エンジンのインデックス作成、Webサイトの死活監視、API連携、SlackやDiscordのリンクプレビュー、脆弱性探索、価格収集など、Webには以前から大量の自動通信が存在しました。サーバーやCDN側から見れば『3件に1件は人間ではない』状態がすでに日常だったのです。
つまり『何万アクセス』といった数字がHTTPSのアクセスの数字であれば『3割5分引いて見る』必要があるのかもしれません。サーバー管理者的な実務、テクニカルな視点ではWeb Beaconなどを用いて実ブラウザーによるアクセス数の計測を行います。これによりボットはほぼ除外され、サーバー側のアクセス解析ではなく『人間の閲覧』をカウントします。Cloudflareでは「Web Analytics」を使って RUM(Real User Monitoring:実ユーザー計測)を行います。RUMはJavaScript を実行する実ブラウザーだけを対象とするため、ボットはほぼ除外され、『人間が何回ページ見たか』に近い指標を得ることができます。
ただし、RUMや動くJavaScriptであれば人間だ、と言い切れるわけでもありません。筆者のGoogle Analytics (GA4)ダッシュボードで最近の市区町村別の利用者を見ると、上位に「Ashburn」「Council Bluffs」が並びます。前者はAWSの、後者はGoogle Cloudの大規模データセンターがある土地です。サーバー側のクライアント分類を見ても、ブラウザー名が並ぶ中に「GoogleBot」が191件混じっています。人間の閲覧を測るはずの計測にも、ブラウザーを見分けるはずの分類にも、機械が入り込んでいます。 『JavaScriptが動く=人間』という前提も、すでに完全ではない のです。RUMは生のリクエスト数より人間に近い、という程度に理解しておくのが安全です。
Webを巡回しているのは誰か
前述した2025年のレポートによると、検証済みボットの通信では「Googlebot」が28%以上を占め、最も活動量の多いボットでした。次いでOpenAIの「GPTBot」が約7.5%、Microsoftの「Bingbot」が6%となっています。検索エンジンクローラー全体は検証済みボット通信の40%、AIクローラーは20%を占めました。
「Googlebot」や「Bingbot」は、検索結果を作るためのクローラーであると同時に、Cloudflareでは検索とAIの双方に関係する多目的クローラーとして扱われています。一方、「GPTBot」や「ClaudeBot」「Meta-ExternalAgent」は、主としてモデルの開発や学習に関係します。「ChatGPT-User」や「Claude-User」のように、利用者が質問した瞬間にページを取得するボットもあります。
つまり、ボットの中には、将来のモデルを作るためにサイト全体を巡回するものもあれば、検索結果に載せるもの、AI回答で引用するもの、人間の依頼を受けてその場で1ページだけ読むものもいる。 『ボット』という一語でまとめるには、目的が違いすぎる のです。
『curl』の正体は「Claude Code」なのか
Cloudflareの2025年版レポートでも、利用者の質問に反応してWebサイトへアクセスする『user action』型のAIクロールが急増し、2025年1月から12月初旬までに21倍以上へ増えたと説明されています。特に「ChatGPT-User」の通信量とよく似た推移を示したといいます。
この流れと並行して、Webサーバーのログでは『curl/8.x』のようなUser-Agentが目立つようになりました。「Claude Code」などのコーディングエージェントは、コードを読むだけでなく、ターミナル上でコマンドを実行できます。公式ドキュメントにも、ファイル編集、コマンド実行、CIからの非対話的な利用が機能として明記されています。エージェントが公式ドキュメントやAPI仕様を調べる過程で、「curl」や同様のHTTPクライアントを呼び出すことは十分にあり得ます。
- 🔗Claude Code overview(公式ドキュメント)
- https://docs.claude.com/en/docs/agents-and-tools/claude-code/overview
ただし、アクセスログに『curl』と書かれているからといって、「Claude Code」からの通信だと断定することはできません。「curl」は人間の開発者も使いますし、監視サービス、CI/CD、Webhook、サーバー間API、スクレイパー、セキュリティ診断にも使われます。User-Agentは書き換えることもできるため、身分証明書ではなく『自己申告の名札』に近いのです。
判断材料になるのは、『curl』という文字列そのものよりも行動です。技術文書やAPI仕様を短時間に連続して取得しているのか、認証やCookieを伴うのか、同じIPアドレスから規則的に巡回しているのか、エラー発生直後に関連ドキュメントへアクセスしているのか。こうした情報を組み合わせれば、『Claude Code』とまでは言えなくても、『コーディングエージェントらしい通信』を推定できます。
- 🔗Cloudflare Radar「AIのインサイト」
- https://radar.cloudflare.com/ja-jp/ai-insights
筆者が管理する、実際のサイト「AICU.jp」「AICU.ai」でもログを分析してみました。
- 🔗ネットアクセスの過半数は、もう人間じゃない — AICU 実測レポート
- https://aicu.jp/aidx/bots
- 🔗ボット採取手帳
- https://aicu.jp/aidx/bots/blog/2026-08-12-week
観測期間: 2026-08-12 までの7日間でAICU のサイトに robots.txt を読みに来た相手の記録です。1週間で 947回・75種のボットが採取できています。検索エンジン、AI学習、AI参照、人間のブラウザーらしきもの他に、無視できない「curl」からのアクセスがあることがわかります。
自動化なのか、人間の指令なのか
ここで、従来の『人間対ボット』という分類が崩れ始めます。人間が「Google Chrome」で記事を開いた場合も、HTML、画像、CSS、JavaScript、広告、アクセス解析へのリクエストはブラウザーが自動的に発行します。人間が1つずつHTTP通信を送っているわけではありませんが、閲覧を始めた主体が人間なので、通常は人間のアクセスとして数えられます。
それでは、人間が「Claude Code」に『このエラーについて公式ドキュメントを調べて』と指示し、AIが「curl」で5ページを取得した場合はどうでしょう。通信自体は自動化されています。しかし、その直前には人間の目的がある。Web全体を無差別に収集する学習クローラーとは、同じボット判定でも意味が違います。
さらに、AIエージェントは1回の依頼から多数の通信を生成します。人間なら検索結果を見て数ページを開くところを、エージェントは候補となるページ、API、関連ファイル、エラーコード、GitHub上の実装例を短時間で横断します。その結果、1人分の関心が数十件、数百件のHTTPリクエストへ膨張する。アクセス数が増えても、人間の読者が同じ割合で増えたとは限らないのです。
逆に、ユーザー起点のAIアクセスをすべて『無価値なボット』として除外すると、人間の新しい情報行動を見失います。利用者が記事をブラウザーで直接読む代わりに、AIへ要約させたり、コードへ反映させたりするようになったからです。ページを取得したのは機械でも、その結果を必要としているのは人間かもしれない。
「Cloudflare」も『過去のボット対人間』で、重要なのは単純な人間かボットかではなく、通信が何をしようとしているのか、サイト側がその行動を許容できるかだと論じています。これから必要なのは『誰が来たか』だけでなく、 『誰の指示で、何の目的で、何を取りに来たか』という分類 です。
- 🔗過去のボット対人間 | Cloudflare ブログ
- https://blog.cloudflare.com/ja-jp/past-bots-and-humans/
この変化は、計測ツールの側にも現れ始めています。筆者のGA4で流入チャネルの内訳を見ると、Direct、Referral、Organic Search、Emailに混じって、 [AI Assistant]という分類が 記録されていました。まだ数は小さいものの、Googleも『AI経由の流入』を検索やSNSと並ぶ独立したチャネルとして数え始めたということです。AIを介した訪問は、もはや『ボットかどうか』ではなく『どこから来た人間か』として扱われ始めています。
サイト側も「読ませない」を選び始めた
AIクローラーは大量のページを取得しますが、従来の検索エンジンほど人間を送り返しません。「Cloudflare」はこの差を『crawl-to-refer』、つまりクロール数と参照流入数の比率として公開しています。
2025年8月に発表された記事『The crawl-to-click gap』によると、2025年7月時点でAnthropicは、人間を1人サイトへ送るまでに約3万8,000ページをクロールしていました。年初に記録された1人当り約28万7,000ページからは改善したものの、検索エンジンとは桁が違います。OpenAIでもこのギャップは約1,091対1、Perplexityでは約195対1でした。大量に読まれるのに、元サイトにはほとんど読者が戻らない。これが 『crawl-to-click gap』 です。
- 🔗The crawl-to-click gap: Cloudflare data on AI bots, training, and referrals
- https://blog.cloudflare.com/crawlers-click-ai-bots-training/
サイト運営者の応答も変化しています。「Cloudflare Radar」の四半期データを同じ条件で比較すると、AIクローラーへ200や204など2xxの正常応答を返した割合は、2025年第2四半期の83.4%から2026年第2四半期には75.5%へ低下しました。一方、403や404などの4xx応答は8%から13.6%へ増えています。クロールの増加に対して、パブリッシャー側が『そのまま読ませる』以外の選択を取り始めた形です。
これは単なる防御ではありません。AIに読ませることで知名度や引用が増えるコンテンツもある一方、全文を取得されることで購読や広告の価値が失われるコンテンツもあります。記事、商品情報、APIドキュメント、会員限定資料では、それぞれ判断が異なるのです。
robots.txtは交渉の場になった
2025年7月1日、「Cloudflare」は新規ドメインに対し、AIクローラーを無条件で受け入れるのではなく、最初に許可するか拒否するかをサイト所有者へ尋ねる方式へ変更しました。従来の『クロールされたくなければ自分で拒否する』というオプトアウトから、サイト側が明示的に判断する許可ベースのモデルへの転換です。
- 🔗Cloudflare Just Changed How AI Crawlers Scrape the Internet-at-Large(公式プレスリリース)
- https://www.cloudflare.com/press/press-releases/2025/cloudflare-just-changed-how-ai-crawlers-scrape-the-internet-at-large/
同時に、「Cloudflare」は既知のAI学習クローラーを拒否するルールを自動生成する「Managed robots.txt」を提供し、AIクローラーへ1リクエスト単位で課金する「Pay Per Crawl」のプライベートベータも始めました。「Pay Per Crawl」では、サイト所有者がクローラーごとに『無料で許可する』『課金する』『ブロックする』を選択できます。支払いが必要な場合にはHTTP 402 Payment Requiredを返し、条件が合えばコンテンツを提供する仕組みです。
- 🔗Managed robots.txt(Cloudflare Docs)
- https://developers.cloudflare.com/bots/additional-configurations/managed-robots-txt/
- 🔗Introducing Pay Per Crawl(The Cloudflare Blog)
- https://blog.cloudflare.com/introducing-pay-per-crawl/
robots.txtは、もはや検索エンジンに巡回範囲を伝えるだけのファイルではありません。検索掲載を許すのか、AI回答での引用を許すのか、モデル学習を許すのか、ユーザー代理の取得を許すのか。 サイトのコンテンツ利用方針を機械へ伝える交渉窓口 になっているのです。
ただし、robots.txtは法的な契約書でも、技術的な防壁でもありません。従うクローラーへの意思表示にすぎず、拒否設定を無視する通信を止めるにはWAFや「AI Crawl Control」による強制が必要になります。「Cloudflare」の公式ドキュメントも、robots.txtによる表明と「AI Crawl Control」による実際のブロックを併用できると説明しています。
Web管理者が今後やるべきこと
最初に見るべきなのは、サーバーの総アクセス数ではなく、数字の出どころです。従来はサーバーログやGoogle Analytics(GA4)のみを使っていましたが、実際にブラウザーで表示された閲覧は「Cloudflare Web Analytics」と「Cloudflare Radar」で測ります。人間を完全に証明するものではありませんが、生のHTTPリクエスト数より人間の閲覧に近い数字です。
- 🔗Cloudflare Web Analytics(公式ドキュメント)
- https://developers.cloudflare.com/web-analytics/about/
自分のサイトへ来ているAIクローラーは、「AI Crawl Control」で確認します。どのAIサービスが、どのパスへ、何件アクセスし、どのステータスを受け取ったかを調べ、クローラー単位で許可や拒否を設定できます。robots.txtに書いた方針へ従っているかも確認できます。
- 🔗AI Crawl Control(Cloudflare Docs)
- https://developers.cloudflare.com/ai-crawl-control/
「curl」、Unknown、独自クライアント、探索的な404などは、「Cloudflare HTTP Traffic Analytics」やログで追います。User-Agent、アクセス先、国、ASN、HTTPメソッド、ステータスコード、Cookie、Referer、アクセス間隔を組み合わせて、検索、AIエージェント、監視、攻撃、API利用を分離する。「Cloudflare」のHTTP Trafficには正規ユーザーだけでなく、クローラーや脅威も含まれ、通常のページビュー1回から複数のHTTPリクエストが発生することも公式ドキュメントに明記されています。
- 🔗Zone Analytics(Cloudflare Docs)
- https://developers.cloudflare.com/analytics/account-and-zone-analytics/zone-analytics/
AICUでは、世界の基準であるRadarと、自社の全リクエスト、RUM、AIクローラー、robots.txtの方針を同じ画面で比較できるようにしました。次の作業は、コンテンツごとに『読ませる』『課金する』『守る』を決めることです。一般公開の記事はAI検索やユーザー起点の参照を許可し、会員限定コンテンツや権利処理が必要な素材は保護する。モデル学習への提供は、利用条件や対価を別に判断する。「curl」系の通信も一括して排除せず、API利用、開発エージェント、監視、攻撃へ分解していく必要があります。そのような『きめ細かで動的なrobots.txt』を設定できるよう、まずは調査の基盤を作った、ということになります。
まとめ:人間が消滅したわけではない、Web4が始まっている
さて、冒頭の『57%』は検証できたでしょうか。結論から言えば、 単一のサイトから『人間対ボット』を一つの比率で出すことはできませんでした 。Cloudflareのプレスリリースが示す57%と、Radarが今この瞬間に返す35.2%ですら、母集団も分類方法も集計期間も異なります。同じ「ボット比率」という言葉でも、測っているものが違うのです。数字を1つ引用して終わりにするのではなく、その数字が何をどう数えたのかを確かめる。それが最初の作法になります。
代わりに見えたのは、もっと具体的な事実でした。32万件のリクエストのうち、実ブラウザーで観測できた閲覧は1,020ページビュー。GA4が数えた実際の訪問者は397人。 1ページビューという人間の体験の裏側で、317件のリクエストがサーバーに届いていた 。しかもその大半は、転送や拒否、そしてAIコーディングによって雑に放置された実験の残骸かもしれません。比率を1つの数字に丸めるより、この桁の違いと内訳を直視するほうが、はるかに実用的でした。現在の引越し作業が終わると、ブログ等のアクセス誘引となっているコンテンツもCloudflare内で完結するため、今後のサーバーコストはほとんどかからなくなります。引っ越しが終われば、この6%は上がるしかない数字です。
しかも今回は自分で分析ダッシュボードを書いてみたおかげで、もっとすごい発見がありました。この計測をしているのはCloudflareのエッジそのものだ、という点です。放置されていたホストにも、壊れていたホストにも、Workerのコードは1行も載っていません。ただDNSレコードがCloudflareをプロキシ経由(オレンジ雲)しているだけです。それでも全リクエストがエッジで記録されており、httpRequestsAdaptiveGroupsのclientRequestHTTPHost次元で引き出せました。 計測のために、そのホストへ何かを仕込む必要がない 。GA4のようなタグもエージェントも不要です。
だからこそ、忘れられたホスト、誰も見ていないホスト、壊れているホストへのアクセスも、この方法でしか見つかりませんでした。実際、GA4では絶対にわからない障害、つまりJavaScriptが動かないので計測対象にすらならない障害も発見できました。ドメインを横断するゾーン単位の引っ越しはなかなか体験できないので、これはまた別途レポートしたいと思います。
静的ページを人間が読んだWeb1.0、SNSやブログで人間が書くようになったWeb2.0、分散台帳で人間が所有を主張しはじめたWeb3。そして Web4は、機械が読み、機械が動く時代 です。ただし機械が勝手に動いているわけではありません。その多くは、人間の問いを受けたAIエージェントの代理行動です。ネットアクセスの過半数が人間でなくなったとしても、人間の関心が消滅したわけではない。 人間の意図が、ブラウザーを経由せずWebへ届くようになった ——これがWeb4の実像です。これからもAI時代のWebのストリームを失踪…ではなく疾走していきたいと思います!




















![1冊ですべて身につくHTML & CSSとWebデザイン入門講座[第2版] 製品画像:3位](https://m.media-amazon.com/images/I/51skMJ-OVcL._SL160_.jpg)






