AI時代のキャッシュ設計: 人間トラフィックとBotトラフィックを両立させる運用モデル

これまでのキャッシュ戦略は、主にブラウザ利用者を前提に最適化されてきました。しかし現在は、LLM向けの収集Bot・要約Bot・検索Botが継続的にコンテンツへアクセスし、同じOriginリソースを消費します。結果として、従来の「ヒット率を上げれば良い」だけでは運用が破綻しやすくなっています。

Cloudflareが提起している「AI時代にキャッシュを再考する」という論点は、まさにここです。キャッシュは性能向上機能ではなく、需要調停のための制御面として扱うべきです。

問題の再定義

現在のWeb運用では、少なくとも以下の2系統を同時に捌く必要があります。

• 人間ユーザーの対話型トラフィック（低遅延重視）
• Bot主体の収集トラフィック（高頻度・広範囲）

同じポリシーで処理すると、Bot需要の増加が人間向け体験を直接圧迫します。

推奨アーキテクチャ: 2レーン運用

Interactiveレーン

• 低レイテンシSLO優先
• キャッシュキー厳格化
• stale-while-revalidateで体感維持

Retrievalレーン

• Bot識別に基づく分離
• 明示TTLでEdgeキャッシュを最大化
• フェアネス制御（レート整形）

ポイントはBot排除ではなく、アクセス特性の違いを運用面で分離することです。

TTLとキー設計の実務

1) キャッシュキーの正規化

不要なクエリやヘッダがキーを爆発させると、ヒット率より先に運用コストが悪化します。まずはキー設計を標準化します。

2) コンテンツ分類ごとのTTL

• 仕様書・ドキュメント: 長TTL
• 料金・在庫・プラン情報: 中TTL + 条件付き再検証
• 障害・ステータス情報: 短TTL

3) フレッシュネス予算の明文化

「どの情報を何分まで古く許容するか」を事前定義し、事故時の場当たり変更を防ぎます。

Bot時代のガバナンス

• 検証済みBotと不明Botを区別
• 一律制限ではなく分類別に整形
• Botヒット率・Originバイパス率を常時計測
• 緊急時の抑制スイッチを事前定義

ここがないと、負荷が上がるたびに運用担当が手作業で火消しすることになります。

FinOpsに接続する

キャッシュ運用を費用管理に直結させます。

• レーン別リクエスト単価
• キャッシュ階層ごとのEgress削減量
• 再検証リクエスト比率
• 未キャッシュ上位パスの支出影響

数字に結び付けることで、性能議論が投資判断に変わります。

30日導入プラン

• Week1: 現状計測（Bot分類・レーン別遅延）
• Week2: TTLマトリクスとキー標準化
• Week3: レーン別制御の適用
• Week4: コスト/遅延差分をレビューして再調整

まとめ

AI時代のキャッシュは、機能ON/OFFではなく運用設計の問題です。人間体験とBot需要を同時に守るには、ポリシー・可観測性・責任分担まで含めた運用モデルが不可欠です。