二つの観測地点が数えるものを分ける
Cloudflareのグラフはエッジで受けた通信を、WordPress側のカウンターはPHPまで到達してAI処理を試みた通信を見ています。したがって、PVが横ばいなのにWordPressのAI試行だけ増えたことは矛盾ではなく、以前はエッジで終わっていた処理がオリジンへ抜けた可能性を示します。
最初に変更時刻をUTCで固定し、その前後15分ずつについてキャッシュヒット率、オリジン到達数、AI試行数、HTTP状態、プロバイダーのトークン数を同じ行へ並べます。日単位の集計では一時的なバイパスが平均化されるため、障害が起きた短い時間窓を使います。
比較条件を固定した一件目を作る
対象URL、クエリ、Cookie、認証状態、User-Agentをそろえたうえで、1件はキャッシュヒット、もう1件はキャッシュミスまたはバイパスになる条件で送ります。単なるリロードでは条件が混ざるので、時刻、完全なURL、応答のCF-Cache-Status、Age、Cache-Control、WordPress側の要求IDを一組として保存します。
二件目を相関IDで証拠マップへ結ぶ
有料処理が動くURLに個人情報を含む実データを使う必要はありません。再現用の固定入力を用意し、ブラウザーの開発者ツール、Cloudflareのログ、WordPressの記録、プロバイダーの要求IDを一つの相関IDへ結び付けます。
次の表は原因を決めつけるためではなく、どの境界で挙動が分かれたかを示すためのものです。キャッシュ有りの通信でWordPress要求IDが存在せず、キャッシュ無しでだけAI試行とプロバイダー要求IDが生まれるなら、費用増の入口はエッジとオリジンの間にあります。
| 証拠点 | キャッシュ有り | キャッシュ無し | 読み取り方 |
|---|---|---|---|
| CF-Cache-Status | HIT | MISS / BYPASS | エッジで分岐したか |
| WordPress要求ID | なし | あり | PHPへ到達したか |
| AI試行数 | 0 | 1 | 課金候補処理が始まったか |
| プロバイダー要求ID | なし | あり | 外部処理まで進んだか |
| 応答トークン | 0 | 記録値 | 実際の生成量 |
| 適用ルール | 通常キャッシュ | バイパス条件名 | 修正対象の所有者 |
分岐点を読み、変更対象を一つに絞る
両方ともオリジンへ届くなら、キャッシュキーだけでなくSet-Cookie、Authorization、Cache-Control: private、クエリ文字列、WorkersやTransform Rulesの変更も確認します。CF-Cache-StatusがDYNAMICやBYPASSである理由を、推測ではなく応答ヘッダーと変更履歴で説明できる状態が合格です。
原因候補が見えても、キャッシュTTL、Cookie除外、WordPressプラグイン、AI上限を同時に変えてはいけません。証拠マップで分岐を生んだルールを一つだけ変更し、同じ2通信を再実行して、キャッシュ状態とAI試行の両方が期待どおり戻るか確認します。
製品の観測範囲を経路全体と混同しない
AI Cost Circuit BreakerはWordPress標準のAI Clientを通る処理を観測します。Cloudflareで止まった通信や、WordPressを経由せずプロバイダーへ直接送られた通信まで同じ数字になるとは限らないため、製品の対象範囲とネットワーク全体の通信量を混同しません。
再試験と引継ぎで復旧を確定する
復旧判定は、代表URLで期待するHITが再現し、オリジン到達数が基準範囲へ戻り、WordPressのAI試行とプロバイダー要求IDが1対1で対応することです。さらに15分観測を続け、ログイン利用者や購入画面など、意図的にキャッシュしない導線を壊していないか確認します。
最後に証拠マップへ変更前後の時刻、ルールID、承認者、戻し方を追記します。これで次回同じ費用増が起きたとき、キャッシュ全体を疑うのではなく、同じ二点比較から短時間で調査を再開できます。導入時の観測項目はガイドで確認できます。
「Cloudflareのキャッシュヒットが消えたとき、AI通信の移動先を15分で突き止める」の「エッジ・オリジン証拠マップ」を、最初の実環境導入に使ってください。AI Cost Circuit Breakerを無料でダウンロードし、Monitoringから始め、期待するシグナルと戻し方を確認してから制御を有効にしましょう。