WebサイトやAPIの利用者を考えるとき、これまでは「人間のユーザー」を中心に設計してきました。
朝の通勤時間にアクセスが増える。昼休みにスマートフォンから閲覧される。夜にECサイトの比較や購入が行われる。キャンペーンを打てば一時的にアクセスが跳ねる。
こうした人間中心のアクセスパターンを前提に、キャッシュ、CDN、オートスケール、WAF、ログ分析、SEO、コンテンツ運用が組み立てられてきました。
しかし、その前提が変わり始めています。
Fastlyが2026年6月9日に公開した分析記事「AI Traffic Grew 6.5x Faster Than Human Traffic This Year」によると、同社のグローバルネットワーク上で観測されたAIリクエストは、2026年1月から5月までに約30%増加しました。これは同期間の人間由来トラフィックの約6.5倍の成長速度です。
この数字が示しているのは、単に「ボットが増えた」という話ではありません。
Webの利用主体が、人間だけでなく、AIクローラー、AIフェッチャー、AIアシスタント、エージェント、API駆動の自律システムへ広がっているということです。
IT技術者にとって重要なのは、これを一過性のアクセス増として見るのではなく、Webインフラ、アプリケーション設計、セキュリティ、データ公開ポリシーを見直すきっかけとして捉えることです。
Fastlyの数字で見るAIトラフィックの変化
Fastlyの分析は、2026年1月1日から5月31日までの期間を対象に、同社のグローバルインフラ上のトラフィックを調べたものです。顧客の新規オンボーディングや特殊な機械間トラフィック増加による歪みを避けるため、固定された顧客群を対象にしたと説明されています。
主なポイントは次の通りです。
| 観点 | Fastlyの観測 |
|---|---|
| AIリクエストの増加 | 2026年1月から5月までに約30%増加 |
| 人間由来トラフィックとの比較 | AIトラフィックの成長速度は約6.5倍 |
| 機械間トラフィック | クローラー、ボット、エージェント、API駆動システムなどの自律的な機械間トラフィックが、インターネット上のリクエストの半分に近づいている |
| AIボットの内訳 | 2026年5月時点で、AIクローラーが85%、AIフェッチャーが15% |
| Claude関連トラフィック | 2026年1月を基準に555%超の増加 |
| オリジン到達率 | 人間のリクエストは9%未満、AIリクエストは51%超がオリジン到達を必要とした |
特に重要なのは、AIリクエストのオリジン到達率です。
人間のリクエストでは、CDNやエッジキャッシュで処理できるものが多くあります。一方、AIリクエストでは、半数を超えるリクエストがオリジンインフラに到達していました。
つまりAIトラフィックは、量が増えているだけではありません。キャッシュで吸収しにくく、アプリケーションサーバ、API、データベース、検索基盤、認証基盤に直接負荷をかけやすいトラフィックとして扱う必要があります。
AIクローラーとAIフェッチャーを分けて考える
AIからのアクセスをすべて「ボット」とまとめると、設計判断を誤ります。
FastlyはAIトラフィックを大きく2種類に分けています。
1つ目はAIクローラーです。
AIクローラーは、Web上の情報を広く収集する仕組みです。大規模言語モデルの学習データ、更新データ、検索拡張、要約、回答生成の根拠情報などに使われる可能性があります。従来の検索エンジンのクローラーに近い動きもありますが、目的は検索インデックスだけではありません。
2つ目はAIフェッチャーです。
AIフェッチャーは、AIアシスタントやAIエージェントが、ユーザーの依頼に応じて必要な情報を取りに来るアクセスです。
たとえば、ユーザーがAIに次のように頼んだ場面を考えるとわかりやすくなります。
今日買える在庫を調べて。
最新の料金を比較して。
この製品仕様を確認して。
この会社の最新ニュースを要約して。
予約できる時間を探して。
このときAI側がWebページやAPIを取得する動きが、AIフェッチャーに近いアクセスです。
AIクローラーは、広範囲、継続的、機械的にアクセスします。AIフェッチャーは、ユーザーの依頼に近く、よりリアルタイム性の高い情報を求めます。
2026年5月時点のFastlyの観測では、AIボットリクエストの85%はAIクローラー、15%はAIフェッチャーでした。しかし、AIエージェントやAIアシスタントの利用が広がれば、フェッチャー型のアクセスは今後さらに重要になります。
IT技術者は、少なくとも次の分類でログと制御を考えるべきです。
| 分類 | 目的 | 設計上の注意点 |
|---|---|---|
| AIクローラー | 学習、収集、インデックス、検索拡張 | robots.txt、レート制限、キャッシュ、公開範囲 |
| AIフェッチャー | ユーザー依頼に応じた情報取得 | 鮮度、認可、API負荷、レスポンス形式 |
| AIエージェント | 予約、購入、問い合わせ、操作代行 | 認証、権限、確認フロー、監査ログ |
| 悪性スクレイパー | 無断収集、不正利用、偽装 | Bot対策、WAF、IP/ASN分析、法務連携 |
| 正規パートナー連携 | 契約済みAPI利用、業務連携 | APIキー、契約上限、SLA、利用量監視 |
この分類なしに「全部ブロックする」「全部許可する」と判断すると、ビジネス機会、セキュリティ、運用コストのどこかに歪みが出ます。
問題はアクセス数ではなくオリジン到達率
AIトラフィックで最初に見るべき数字は、単純なリクエスト数ではありません。
重要なのは、どれだけオリジンに到達しているかです。
Fastlyの分析では、2026年5月時点で、人間のリクエストのうちオリジンインフラへの到達が必要だったものは9%未満でした。一方、AIリクエストでは51%超がオリジンアクセスを必要としていました。
これは、AIが求める情報の性質を考えると理解できます。
人間の閲覧では、トップページ、記事ページ、画像、CSS、JavaScript、商品説明など、キャッシュしやすいコンテンツが多く含まれます。CDNが正しく効いていれば、多くのリクエストはエッジで処理できます。
一方、AIフェッチャーやAIエージェントは「今どうなっているか」を取りに来ます。
- 在庫は今あるのか
- 価格は最新か
- 規約は更新されたか
- イベントの空席はあるか
- ニュースは変わったか
- API仕様に差分はあるか
- 製品情報は更新されたか
こうした情報は、キャッシュのTTLを長くしにくく、オリジンやAPIに到達しやすくなります。
AIトラフィックの増加は、CDNの転送量だけの問題ではありません。アプリケーションサーバ、データベース、検索基盤、認証基盤、APIゲートウェイ、外部連携、レート制御、監視基盤に影響します。
これからは「人間のピークアクセスに耐える設計」だけでは不十分です。
人間とは違うリズムで、常時、機械的に、鮮度の高い情報を取りに来るアクセスに耐える設計が必要になります。
夜間に負荷が下がる前提も崩れる
人間のアクセスには生活リズムがあります。
朝、昼、夜。平日と休日。通勤時間。学校や仕事の時間。セールやイベントの時間。
サービスによって差はありますが、人間のアクセスにはある程度の周期性があります。
一方、FastlyはAIクローラーについて、人間のような時間帯の偏りが小さく、24時間を通じて比較的一貫した活動を示すと説明しています。
AIクローラーは眠りません。昼休みもありません。休日も関係ありません。
この違いは、インフラ運用に直接影響します。
- 夜間は負荷が下がる前提でバッチ処理を入れている
- 深夜帯にバックアップや集計処理を集中させている
- 人間のアクセスが少ない時間に検索インデックスを更新している
- 夜間の監視体制を薄くしている
- 深夜メンテナンスなら影響が小さいと判断している
こうした運用は、AIトラフィックの増加によって見直しが必要になります。
特に注意すべきなのは、AIクローラーのアクセスと、社内バッチ、バックアップ、検索インデックス更新、ログ集計、データ同期が重なるケースです。
人間のアクセスが少ない時間帯でも、機械同士の処理が集中し、オリジン負荷やDB負荷を生む可能性があります。
robots.txtは方針表明であり、アクセス制御そのものではない
AIクローラー対策として、robots.txtに注目が集まっています。
robots.txtは必要です。しかし、IT技術者はこれを「アクセス制御そのもの」と誤解してはいけません。
GoogleのGoogle crawlers and fetchersの公式ドキュメントでは、Googleの一般的なクローラーは自動クロール時にrobots.txtを尊重する一方、フェッチャーは通常、ユーザー操作に基づく単発リクエストとして説明されています。また、Googleのcommon crawlers一覧では、HTTPのUser-Agentは偽装される可能性があるため、Googleクローラーであることの検証が必要だと説明されています。
Google-Extendedについても注意が必要です。
Googleのドキュメントでは、Google-Extendedは通常のHTTPリクエストのUser-Agentではなく、robots.txt上で制御するためのプロダクトトークンだと説明されています。Geminiのモデル改善やgroundingへの利用可否を管理するためのものであり、Google検索への掲載やランキングには影響しないとされています。
つまり、robots.txtは「この情報をどの用途に使ってよいか」を示す重要な方針表明です。
しかし、すべてのアクセスを技術的に遮断する仕組みではありません。善意のクローラーは従いますが、悪意あるスクレイパーやUser-Agentを偽装するアクセスには効きません。
現実的には、次の多層防御が必要です。
| 層 | 実施内容 |
|---|---|
| 方針表明 | robots.txt、利用規約、データ利用ポリシーを整備する |
| 識別 | User-Agent、IP、ASN、逆引き、リクエスト挙動を確認する |
| 防御 | WAF、Bot Management、レート制限、地理制限を使う |
| 認証 | 重要API、会員情報、操作系エンドポイントには認証と認可を必須にする |
| 負荷制御 | キャッシュ、サーキットブレーカー、キュー、リトライ制御を設ける |
| 監査 | AIクローラー、AIフェッチャー、人間、悪性ボットをログ上で分類する |
robots.txtだけでAIトラフィック対策を完結させるのは危険です。
robots.txtは、CDN、WAF、API Gateway、認証、レート制御、ログ分析と組み合わせて初めて実効性を持ちます。
「悪いボットを止める」だけでは足りない
従来のボット対策は、悪意あるアクセスを止めることが中心でした。
- DDoS対策
- 不正ログイン対策
- スクレイピング対策
- 在庫買い占めボット対策
- 脆弱性スキャン対策
- スパム投稿対策
もちろん、これらは今後も重要です。
ただしAIトラフィックの時代には、「悪いボットを止める」だけでは不十分です。すべてのAIアクセスが悪意あるものではないからです。
AIアシスタントが自社の商品情報を正しく取得し、ユーザーに紹介してくれる可能性があります。AI検索が自社の技術文書を参照し、開発者に案内してくれる可能性があります。AIエージェントが予約、問い合わせ、購入、比較検討の入口になる可能性もあります。
一方で、無制限に許可すれば、コンテンツの無断利用、オリジン負荷、APIコスト増、競合への情報流出、誤った情報の再利用が起きます。
Fastlyも別の記事「Bot defense is table stakes. Machine traffic requires business strategy」で、悪いボットを止めるだけでは足りず、どのAIインタラクションが価値を生み、どれがリスクを生むのかを判断する必要があると述べています。
IT技術者が考えるべきことは、単純な遮断ではありません。
- どのAIアクセスを許可するのか
- どのAIアクセスを制限するのか
- どの情報は取得されてもよいのか
- どの情報はログイン後に限定すべきか
- どのAPIは人間向けUIとは別に提供すべきか
- どの範囲までキャッシュさせるか
- どのボットにはレート制限をかけるか
- どのボットは契約や許諾が必要か
AI時代のWeb運用では、機械向けアクセス制御ポリシーが必要になります。
まずログでAIアクセスを分類する
AIトラフィックに対応する第一歩は、自社サービスにどれだけAIアクセスが来ているかを把握することです。
まず確認すべきなのは、アクセスログです。
| ログ項目 | 見る理由 |
|---|---|
| User-Agent | AIクローラーや既知ボットの候補を把握する |
| IPアドレス、ASN | 特定ネットワークやクラウド事業者からの偏りを見る |
| リクエストパス | どのページやAPIに集中しているかを見る |
| HTTPメソッド | GET中心か、POSTや操作系に来ているかを見る |
| ステータスコード | 403、404、429、5xxの増加を確認する |
| レスポンスタイム | AIアクセスが遅延を生んでいるかを見る |
| キャッシュヒット率 | エッジで吸収できているかを見る |
| オリジン到達率 | バックエンド負荷への影響を見る |
| API別リクエスト数 | 高コストAPIに集中していないかを見る |
| 時間帯別分布 | 夜間や休日の機械的アクセスを把握する |
特に重要なのは、AIアクセスが「どのページ」や「どのAPI」に集中しているかです。
トップページだけなら影響は限定的かもしれません。静的記事ページならキャッシュで吸収できるかもしれません。
しかし、検索API、在庫API、価格API、会員情報API、問い合わせフォーム、予約API、管理系エンドポイントに集中しているなら、設計上のリスクが高くなります。
また、AIアクセスが増えているのに、通常のWebアクセス分析ツールでは「ユーザー数」として見えていない場合もあります。PVやセッションだけを見ていると、インフラ負荷の増加に気づけません。
今後は、マーケティング用のアクセス解析だけでなく、インフラ運用視点のトラフィック分類が必要です。
キャッシュ設計をAI向けに拡張する
Fastlyの調査で示されたように、AIリクエストは人間のリクエストよりもオリジンに到達しやすい傾向があります。
そのため、キャッシュ設計の見直しは優先度が高い作業です。
これまでのキャッシュ設計では、人間の閲覧体験を中心に考えることが多かったはずです。
- ページ表示を速くする
- 画像、CSS、JavaScriptをCDN配信する
- 記事ページをキャッシュする
- 商品一覧を一定時間キャッシュする
しかしAIフェッチャーは、差分、鮮度、構造化情報を求めます。HTMLをそのまま読ませるだけでなく、AIが取得しやすく、かつオリジン負荷を抑えられる形で情報提供を考える必要があります。
たとえば、次のような設計が考えられます。
| 設計 | 内容 |
|---|---|
| AI向け静的情報 | 商品仕様、価格表、FAQ、ドキュメントをキャッシュしやすい形式で提供する |
| 差分取得 | ETag、Last-Modified、更新日時APIで不要な再取得を減らす |
| 構造化データ | JSON、RSS、sitemap、schema.org、OpenAPIなどで機械が読みやすくする |
| AI向けMarkdown | 重要ドキュメントをMarkdownで提供し、HTML解析の負荷を減らす |
| TTL設計 | リアルタイム性が不要な情報は短すぎるTTLにしない |
| Vary管理 | AcceptやUser-Agentで配信内容を変える場合、キャッシュキーの爆発に注意する |
| クエリ制御 | 無数の検索条件やフィルタでキャッシュが効かなくなる問題を抑える |
FastlyはAIエージェント向けにMarkdownを提供する記事でも、AIクローラーがHTMLよりMarkdownを好む傾向や、Vary: Accept, User-Agent、キャッシュ、レート制限の設計に触れています。
AIに読ませる情報をすべて人間向けHTMLから取得させる必要はありません。
むしろ、AIに読ませてよい情報は、読みやすく、キャッシュしやすく、制御しやすい形で入口を分けるべきです。
API設計はエージェント操作を前提にする
AIフェッチャーやAIエージェントが増えると、WebページだけでなくAPI設計も変わります。
人間向けUIは、画面上の確認、ボタン、警告文、入力補助で誤操作を防げます。一方、AIエージェントはAPIを直接呼び出す可能性があります。
このとき、API側に安全装置がないと危険です。
最低限、次の観点を確認する必要があります。
| 観点 | 確認すること |
|---|---|
| 認証 | APIキー、OAuth、サービスアカウント、ユーザー委任の区別があるか |
| 認可 | ユーザーができない操作をAI経由で実行できないか |
| 操作確認 | 購入、予約、送信、削除、課金などに確認ステップがあるか |
| 冪等性 | 同じ操作が再試行されても二重実行にならないか |
| レート制限 | ユーザー単位、アプリ単位、IP単位、トークン単位で制御できるか |
| 監査ログ | 誰の代理で、どのAIまたはアプリが、何を実行したか残るか |
| スコープ | 読み取り専用、下書き作成、実行権限を分けられるか |
| エラー設計 | AIが再試行すべきエラーと停止すべきエラーを区別できるか |
AIエージェントに操作を許すなら、APIは単なるデータ取得口ではありません。
人間の代理操作を受ける業務境界になります。
そのため、API設計には、権限、監査、確認、取り消し、レート制限、異常検知が必要です。
セキュリティは「偽装」と「間接的な悪用」まで見る
AIトラフィックのセキュリティで難しいのは、見た目だけでは意図を判断しにくいことです。
User-Agentは偽装できます。Googleの公式ドキュメントも、HTTPのUser-Agentはなりすまし可能であり、Googleクローラーの検証が必要だと説明しています。
また、AIフェッチャーはユーザーの依頼に応じてアクセスするため、悪意あるアクセスと正当な情報取得の境目が曖昧になります。
注意すべきリスクは次の通りです。
- User-Agentを偽装したスクレイピング
- AIクローラーを装った脆弱性探索
- 検索APIや在庫APIへの高頻度アクセス
- 高コストな生成、検索、集計APIの濫用
- 会員向け情報の間接的な取得
- AIエージェント経由の誤操作
- プロンプトインジェクションによる外部情報取得の誘導
- 公開情報を組み合わせた機密推測
特に、AIエージェントが外部サイトを読み、社内システムに入力し、APIを実行するようになると、Webサイト側だけで完結しないリスクが出てきます。
自社サイトに埋め込まれたテキストが、他社やユーザーのAIエージェントの動作に影響する可能性もあります。
その意味で、Webコンテンツは「人間が読む文章」であると同時に、「AIが解釈し、別のシステム操作に使う入力」でもあります。
IT部門が今週確認できるチェックリスト
AIトラフィック対策は、大規模な基盤刷新から始める必要はありません。
まずは、現状把握と方針整理から始めるべきです。
1. 直近3カ月のアクセスログからAI系User-Agentの傾向を見る
2. AIアクセスの上位URL、上位API、上位IP/ASNを確認する
3. AIアクセスのキャッシュヒット率とオリジン到達率を分けて見る
4. 403、404、429、5xxがAIアクセスで増えていないか確認する
5. robots.txtに現在どの方針が書かれているか確認する
6. Google-ExtendedなどAI利用制御の扱いを社内方針として決める
7. 公開してよい情報、取得を制限したい情報、ログイン必須の情報を分類する
8. 検索API、在庫API、価格API、予約APIなど高負荷APIのレート制限を確認する
9. AIフェッチャー向けにキャッシュしやすい静的情報やMarkdownを用意できるか検討する
10. AIエージェントが操作する可能性のあるAPIに、認可、確認、監査ログがあるか確認する
この確認だけでも、見えていなかった負荷やリスクが浮かび上がります。
重要なのは、AIトラフィックを「迷惑なアクセス」とだけ見ないことです。
価値を生むアクセスと、制限すべきアクセスを分ける必要があります。
AIを止めるのではなく入口を設計する
AIトラフィックの増加は、Webの利用者が人間だけではなくなったことを示しています。
これは、Web設計の前提変更です。
SEOだけを考えればよかった時代から、AIクローラー、AIフェッチャー、AIエージェント、正規API連携、悪性スクレイパーを分けて扱う時代に移っています。
IT技術者が見るべき問いは、次のように変わります。
人間にどう見せるか
だけではなく、
AIに何を読ませるか
AIに何を読ませないか
AIにどの形式で渡すか
AIにどこまで操作を許すか
AIアクセスをどこで止め、どこで受け入れるか
です。
AIトラフィックをすべて拒否すれば、将来の流入経路やユーザー体験を失う可能性があります。無制限に許可すれば、コスト、負荷、権利、セキュリティの問題を抱えます。
必要なのは、AIを止めるか受け入れるかの二択ではありません。
AI向けの入口を設計することです。
キャッシュしやすい情報、機械が読みやすい形式、明確な利用ポリシー、実効性のあるレート制限、認証と認可、監査ログ、異常検知。
これらをそろえたWebサイトやAPIだけが、人間とAIの両方に使われる時代の基盤になります。
作成日: 2026-07-02