AI時代のキャッシュを再考する理由

2026-04-02 — Avani Wildani、Suleman Ahmad — 読了約8分

Cloudflareのデータは、ネットワーク全体のトラフィックの32%が自動化トラフィックから発生していることを示しています。これには検索エンジンクローラ、稼働監視（uptime check）、広告ネットワーク、そして最近ではRAG（retrieval-augmented generation）を用いて応答生成時にWebの関連データを知識ベースへ取り込むAIアシスタントなどが含まれます。人間の典型的な挙動とは異なり、AIエージェント、クローラ、スクレイパーの自動化された挙動は、サーバ側から見ると攻撃的に見えることがあります。例えば、AIボットは高頻度な並列リクエストを多用することがあり、人気ページに集中するのではなく、サイト内のあまり訪問されない、または関連性の低いコンテンツを順次、網羅的にアクセスすることがあります。あるAIアシスタントが応答を生成する際に、数十に及ぶ無関係なソースから画像、ドキュメント、ナレッジ記事をフェッチすることもあります。

Cloudflareは既に自動化アクセスの制御や制限を簡単に行える仕組みを提供していますが、多くのサイトはAIトラフィックを積極的に提供したい場合があります。たとえば、アプリ開発者は開発者向けドキュメントが主要なAIモデルに反映されることを保証したいかもしれませんし、eコマースサイトは製品説明がLLMの検索結果に含まれることを望むかもしれません。出版社は「pay per crawl」のような仕組みでコンテンツに対価を得たい場合もあるでしょう。したがって、ウェブサイト運営者はジレンマに直面します：AIクローラ向けにチューニングするか、人間のトラフィック向けにチューニングするか。両者はトラフィック特性が大きく異なるため、現在のキャッシュアーキテクチャはリソース節約のためにいずれか一方を選ばざるを得ないことが多いのです。

本稿では、AIトラフィックがストレージキャッシュに与える影響を検討し、この影響を緩和する際の課題を述べ、CDNキャッシュをAI時代に適応させるためにコミュニティが検討すべき方向性を提案します。本研究はETH Zurichの研究チームとの共同取り組みです。完全版は2025年のSymposium on Cloud ComputingでZhangらにより “Rethinking Web Cache Design for the AI Era” として発表されています。

キャッシングの復習

簡単にキャッシュの仕組みを復習します。ユーザがデバイスでコンテンツのリクエストを開始すると、通常は最も近いCloudflareのデータセンターに送信されます。リクエスト到着時に有効なキャッシュがあれば、即座にコンテンツを返せるため応答が高速になり、ユーザ満足度が高まります。キャッシュに読み取り可能なコンテンツがない場合（「キャッシュミス」）、データセンターはオリジンサーバに新しいコピーを取りに行き、それが有効期限切れや他のデータに押し出されるまでキャッシュに留まります。

キャッシュに何を残すかは、キャッシュミスを減らし、優れたユーザ体験を提供するために重要です──しかし、人間のトラフィックにとって「正しい」要素は、AIクローラにとっては全く異なる場合があります。

CloudflareにおけるAIトラフィック

ここではAIクローラトラフィックに焦点を当てます。最近の解析では、自己識別されたAIボットトラフィックのうち約80%がAIクローラに該当し、最も活動的なAIボット種別として浮上しています。AIクローラは、質問応答やページ要約などのリアルタイムAIサービスを支えるコンテンツ取得のほか、LLMのようなモデルの訓練用に大規模なデータセットを収集するためにもコンテンツを取得します。

Cloudflare Radarのデータから、単目的のAIボットトラフィックの大部分は訓練用途であり、検索用途ははるかに少ないことが分かります（詳細は当社の別記事参照）。検索と訓練のクローラはいずれも多数の順次的でロングテールなアクセスを通じてキャッシュに影響を与えますが、訓練トラフィックは高いユニークURL比、コンテンツ多様性、クロール非効率性といった性質を持ち、キャッシュにより大きな影響を与えます。

CDNにおけるAIトラフィックの差異

AIクローラトラフィックは主に以下の三つの特徴で他のトラフィックと差別化されます：高いユニークURL比、コンテンツ多様性、クロールの非効率性。Common Crawlのような月次の大規模ウェブクロールの公開統計では、90%以上のページがコンテンツとしてユニークであることが示されています。異なるAIクローラは別個のコンテンツタイプをターゲットにすることが多く、例えば技術ドキュメント、ソースコード、メディア、ブログ投稿などに特化するものがあります。

さらに、AIクローラは必ずしも最適なクロール経路を辿るわけではありません。人気のあるAIクローラからのフェッチのかなりの割合が404エラーやリダイレクトで終わることがあり、これはしばしば不適切なURL処理が原因です。これらの非効率的なリクエストの割合は、クローラがどれだけライブかつ意味のあるコンテンツを的確にターゲットできているかによって変動します。

AIクローラは、ブラウザ側キャッシュやセッション管理を人間のユーザと同じ方法で利用するとは限りません。AIクローラは複数の独立したインスタンスを立ち上げることがあり、セッションを共有しないため、同じコンテンツを要求しても各インスタンスがCDNにとって新しい訪問者として現れる場合があります。単一のAIクローラであっても、典型的な人間ユーザよりもサイトを深く掘り下げ、より幅広いコンテンツを探索する傾向があります。

Wikipediaの利用データは、かつて「ロングテール」やあまりアクセスされなかったページが頻繁に要求されるようになり、CDNキャッシュ内のコンテンツ人気度分布が変化していることを示しています。実際、AIエージェントは検索結果を改善するために反復的にループして同じコンテンツを何度もスクレイピングすることがあります。我々のモデル化により、この反復ループが低いコンテンツ再利用率と広いカバレッジにつながることを示しています。

我々のAIエージェント行動のモデル化では、エージェントが検索結果を洗練するために反復ループを行う（RAGで一般的なパターン）と、その都度ユニークアクセス比率が一貫して高く（一般に70%～100%）、各ループは精度（図中の青線）を向上させる一方で、以前に見たページを再訪するのではなく新規のユニークコンテンツを常にフェッチしていることが示されます。ロングテール資産へのこの反復アクセスは、人間トラフィックが依存するキャッシュを掻き回します。その結果、プリフェッチや従来のキャッシュ無効化戦略は、クローラトラフィックが増加するにつれて効果が薄くなる可能性があります。

AIトラフィックはキャッシュにどう影響するか

CDNにとってキャッシュミスは、要求されたコンテンツをオリジンからフェッチしなければならないことを意味します。キャッシュミスを、地元の図書館に本が在庫されておらず他館から取り寄せる必要がある状況に例えると、いつかは本は手に入るが、待ち時間が生じるということになります。また、その経験は図書館に対してその本を地元在庫に置くことが望ましいというフィードバックにもなります。

AIクローラはロングテールを幅広く予測不能にアクセスするため、キャッシュミス率を大幅に押し上げます。キャッシュヒット率を改善するための一般的手法（キャッシュスペキュレーションやプリフェッチなど）も、AIクローラの挙動下では著しく効果が低下します。下の（元記事中の）最初のグラフは、Cloudflareの単一ノードにおけるキャッシュヒット率が、特定のAIクローラを含めた場合と含めない場合でどれほど差が出るかを示しています。まだ影響は限定的であるものの、AIクローラの追加によるヒット率低下は明瞭です。

我々はキャッシュを「LRU（Least Recently Used）」というアルゴリズムで管理しています。これは、ストレージが満杯になった際に最も最近参照されていないコンテンツから順に追い出す方式です。ヒット率の低下は、LRUがAIクローラの繰り返しスキャン挙動の下で苦戦していることを意味します。下の図はその期間中のAIキャッシュミスを示しています。それらの各キャッシュミスはオリジンへのリクエストを表し、応答時間の遅延、エグレスコストの増加、オリジン負荷の上昇を引き起こします。

このAIボットトラフィックの急増は実際の影響を及ぼしてきました。論文に示された以下の表は、いくつかの大規模サイトでの影響を示します（各例は出典レポートへのリンクあり）。

システム	報告されたAIトラフィックの挙動	報告された影響	報告された対策
Wikipedia	モデル訓練のための大量画像スクレイピング 1	マルチメディア帯域使用量が50%増加 1	クローラをブロック 1
SourceHut	LLMクローラがコードリポジトリをスクレイプ 2, 3	サービス不安定・遅延 2, 3	クローラをブロック 2, 3
Read the Docs	AIクローラが大きなファイルを日々何百回もダウンロード 2, 4	帯域幅の大幅増加 2, 4	一時的なクローラブロック、IPベースのレート制限、CDN設定の見直しでキャッシュを改善 2, 4
Fedora	AIスクレイパがパッケージミラーを再帰的にクロール 2, 5, 6	人間ユーザ向け応答の遅延 2, 5, 6	既知ボットソースからのトラフィックをジオブロック、いくつかのサブネットや国をブロック 2, 5, 6
Diaspora	robots.txtを尊重しない攻撃的なスクレイピング 7	人間ユーザ向けの遅延とダウンタイム 7	クローラをブロック、レート制限を追加 7

影響は深刻です：Wikimediaは大量の画像スクレイピングによりマルチメディア帯域使用量が50%増加しました。大きなソフトウェアパッケージをホストするFedoraや、DiasporaのようなSNSは負荷が重くなり人間ユーザのパフォーマンスが悪化しました。多数のサイトが、AIボットが大きなファイルを繰り返しダウンロードすることで帯域幅増加や速度低下を報告しています。クローラをブロックすることで影響はある程度緩和されますが、より賢いキャッシュアーキテクチャがあればサイト運営者はAIクローラにコンテンツを提供しつつ、人間ユーザ向けの応答時間を維持できるでしょう。

AIを意識したキャッシング

AIクローラはRAGやリアルタイム要約のようなインタラクティブなアプリケーションを支えるため、レイテンシが重要です。そのため、これらのリクエストは大容量を保持しつつ中程度の応答時間を両立できるキャッシュにルーティングされるべきです。これらのキャッシュはフレッシュネス（新鮮さ）を保ちつつ、人間向けキャッシュより若干高いアクセスレイテンシを許容できます。

一方で、訓練データ収集や大規模なコンテンツ収集ジョブのようなワークロードは、はるかに高いレイテンシを許容し、即時性を必要としません。こうした要求は、深いキャッシュ層（例：オリジン側のSSDキャッシュ）からサービスするか、キューベースの受け入れやレートリミッタで遅延させることでバックエンド過負荷を防ぐことができます。これにより、インフラが高負荷時でも大量スクレイピングを延期でき、インタラクティブな人間/AIユースケースに影響を与えずに済みます。

既存のプロジェクトとして、CloudflareのAI IndexやMarkdown for Agentsのように、サイト運営者が既知のAIエージェントやボットに対して簡略化・縮小版のサイトを提示できる仕組みがあります。我々はAIトラフィックがCDNキャッシュに与える影響を緩和するためにさらに多くの施策を行う計画です。ETH Zurichの共同研究者とともに、我々は二つの補完的アプローチを実験しています：ひとつはトラフィックフィルタリングとAI対応キャッシュアルゴリズム、もうひとつはAIクローラトラフィックを吸い上げるための別個のキャッシュ層を追加する検討です。

キャッシュ置換（eviction）アルゴリズムには、LRU（Least Recently Used）、LFU（Least Frequently Used）、FIFO（First-In, First-Out）などがあり、ストレージが満杯の際に新しい要素を追加するためにどの要素を追い出すかを決定します。LRUは単純さ、低オーバーヘッド、一般的な有効性のバランスが良いため広く使われています。しかし、人間トラフィックとAIボットが混在する状況では、我々の初期実験は別の置換アルゴリズム、特にSEIVEやS3FIFOを用いることで、人間トラフィックはAIの干渉の有無にかかわらず同等のヒット率を達成できる可能性を示しています。さらに、ワークロードに直接適応する機械学習ベースのキャッシュアルゴリズムを開発し、リアルタイムでキャッシュ応答をカスタマイズして高速かつ低コストなキャッシュを実現する試みも進めています。

長期的には、AIトラフィック専用の別個のキャッシュ層を設けることが最善の道になると我々は予想しています。人間トラフィックとAIトラフィックをネットワークの異なる層・ティアに配備された別個のティアへルーティングするアーキテクチャを想像してください。人間トラフィックは引き続き…

（注：原文はここで中断しています）