Contents
目的と主要KPI（計測の狙いと期待効果）
このセクションでは計測の目的と測定すべき主要指標を明確にします。測定の目的を共通認識化してからデータ収集を開始してください。
期待効果
導入で狙う主な効果を列挙します。定量・定性的効果を関係者で合意してください。
- パフォーマンス改善（ページ表示高速化、応答遅延短縮）
- オリジン負荷低減（オリジンリクエスト数・CPU負荷の削減）
- 帯域コスト削減（オリジン転送量の減少）
- 可用性・セキュリティ向上（CDN経由の緩和効果、WAF活用）
主要KPI
計測前にKPI定義を確定します。指標名と集計方法をドキュメント化してください。
- キャッシュヒット率（edge cache hit ratio。Logpush／cf-cache-statusベース）
- TTFB（エッジ側とオリジン側を分離して計測）
- Core Web Vitals（LCP / CLS / INP）※FCPは別指標として扱う
- p95 / p99 レイテンシ（リクエストやページロードのパーセンタイル）
- オリジンリクエスト数、オリジン帯域（GB）
- エラー率（4xx / 5xx）
- 月次コスト換算（帯域・オリジン処理を金額換算）
計測前の前提
比較実施時の前提条件を揃えます。条件差が結果を歪めないように注意してください。
- 同一URL／同一クエリ／同一Cookie／同一ヘッダ条件で比較すること
- 認証やユーザ固有レスポンスは別集計にすること
- ベースラインは代表的なページ群で取得すること（代表的な5〜10ページを選定）
- ベースライン期間は概ね30日を推奨するが、季節性や週次差を考慮すること
計測手法の選択と使い分け（RUM / Synthetic / ログ）
手法ごとに得られる情報と制約が異なります。用途に応じて最適な組合せを決めてください。
RUM（実ユーザ計測）
実ユーザから得られる指標の利点と注意点を記します。実ユーザ環境の多様性を反映できます。
- 長所：実際のユーザ環境でのCore Web Vitalsが計測できる。地域・デバイス分布を反映する。
- 制約：サンプリングや同意（Cookie／CMP）の影響を受ける。問題切り分けは難しい場合がある。
- 運用メモ：同意管理の実装とPIIのマスキングを必須にしてください。
Synthetic（合成計測）
再現性の高いテストでプロトコルや構成差の評価に向きます。検証用に使います。
- 長所：ブラウザ・ネットワーク・環境を固定して比較可能。HTTP/2・HTTP/3・TLSの差を検証しやすい。
- 制約：実ユーザ分布を反映しない。合成結果はRUMと必ず照合すること。
- 運用メモ：複数ロケーション、複数デバイス設定で定期実行すること。
ログ解析（Edge / Originログ）
リクエスト単位の詳細な集計が可能です。コストやオリジン負荷の根拠を得られます。
- 長所：オリジンリクエスト数や帯域を正確に算出できる。トラフィック傾向の定量化に必須。
- 制約：ログ量が大きく保管・処理コストがかかる。スキーマ整備が必要。
- 運用メモ：Logpush設定時は保存先の権限とスキーマを事前に確認すること。
Cloudflareネイティブツールの活用
Cloudflareの標準機能を目的別に使い分けます。各ツールの役割を明確にしてください。
- Analytics / Cache Analytics：トラフィック概況とキャッシュ傾向の把握に有用です。
- Browser Insights：実ユーザのCore Web Vitals取得に適しています。
- Logpush：EdgeログをS3/GCS/BigQueryへ送信します。集計基盤に直接取り込めます。
- Cloudflare Radar：大域トレンド把握や異常検知に役立ちます。
実務ワークフローと役割分担（時系列手順・チェックポイント）
測定から改善までの実行手順と担当を明確にします。段階ごとにチェックポイントを設けて安全に進めてください。
実行ワークフロー（ステップ）
標準的な実務ワークフローを時系列で示します。各ステップで成果物と合格条件を定義してください。
- スコープ決定：代表ページ、期間、KPI、許容差を合意する。
- ステージング検証：設定変更やLogpushの宛先動作をステージングで検証する。
- RUM／Logpush有効化：Browser Insights と Logpush を設定し、データ流入を確認する。
- ベースライン取得：30日程度で日次トレンドを確定する（目安）。
- Synthetic実行：WebPageTest等でオン／オフ比較を複数ロケーションで実施する。
- 分析・可視化：BigQuery等で集計しダッシュボードを作成する。
- 改善実施と検証：小さな変更を段階的に適用し、効果を計測する。
- 定常運用：アラートの設定と定期レポート化を行う。
役割分担（権限・担当）
各工程の責任者と必要な権限を明示してください。権限は最小権限で付与します。
- プロダクトオーナー：KPI承認、優先順位決定
- SRE / CDNエンジニア：Cloudflare設定、Workers変更、DNS操作
- データエンジニア：Logpush設定、BigQueryスキーマ、権限管理
- 分析担当（BI）：SQL・ダッシュボード作成、アラート設定
- セキュリティ／コンプライアンス：PIIポリシー、同意フロー確認
チェックポイントと合格基準
各段階における合格条件の例を示します。失敗時の対応を事前に決めてください。
- ステージングでの差分が許容内であること（例：ページ応答差 <10%）
- Logpushが期待フォーマットで受信できること
- RUMデータのサンプリング率が想定値に達していること
- 本番操作前にロールバック手順を文書化していること
計測設計と実行の前提（コマンド／スクリプト／web-vitals）
計測を行う前に必要な前提と実行コマンド、スクリプトの注意点をまとめます。環境や権限の前提を必ず確認してください。
対象URL選定と測定条件
代表ページは高トラフィックかつビジネス影響が大きいものを優先します。5〜10ページでベースラインを取る方針が実務では有効です。
- ページ種別：トップ、主要テンプレ、ログイン後、画像配信、API等
- デバイス／ネットワーク：主要地域、モバイル・デスクトップ、回線種別
- 時間帯：ピーク・通常時間で分ける
即使えるコマンド例（注意事項を含む）
以下のコマンドは結果を確認するための例です。実行前に想定環境と影響範囲を確認してください。
- cf-cache-status と時間指標を同時に確認する（本番に影響しない簡易確認）
curl -s -D - -o /dev/null 'https://EXAMPLE_URL' -w 'namelookup:%{time_namelookup}s connect:%{time_connect}s starttransfer:%{time_starttransfer}s total:%{time_total}s\n'
- cf-cache-status ヘッダのみ取得
curl -s -I 'https://EXAMPLE_URL' | grep -i 'cf-cache-status'
- オリジンへ直接接続（テスト端末のみ。DNS全体を書き換えない）
curl -s -D - -o /dev/null --resolve 'example.com:443:ORIGIN_IP' 'https://example.com'
注意点：--resolve はSNIに example.com を保持しますが、オリジン証明書やファイアウォール設定に依存します。必ずテスト端末で実行し、プロダクションDNSは変更しないでください。
RUM 実装（web-vitals の入手先・CSP・認証前提）
web-vitalsは公式のライブラリを利用してください。配布方法はビルドに取り込むか、バージョンを固定したCDN参照にすることを推奨します。
- 入手方法：npmパッケージ 'web-vitals' をビルドに含めるか、信頼できるCDN（jsDelivr/unpkg）でバージョンを固定して利用する
- CSP影響：外部CDNを使う場合は script-src に追加が必要です。非同期送信先は connect-src に含めること
- 認証／環境変数：RUMを受ける収集エンドポイントは認証トークンやレート制限を実装してください。S3/GCS/BigQueryへ書き込む場合は適切なサービスアカウント権限を設定します
例（クライアント側最小実装。発火は同意後に行うこと）：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<script src="https://unpkg.com/web-vitals@VERSION/dist/web-vitals.iife.js"></script> <script> webVitals.getLCP(metric => sendMetric(metric)); webVitals.getCLS(metric => sendMetric(metric)); webVitals.getINP(metric => sendMetric(metric)); function sendMetric(metric){ if(typeof navigator.sendBeacon === 'function'){ navigator.sendBeacon('/rum-collector', JSON.stringify(metric)); } else { fetch('/rum-collector', {method:'POST', body:JSON.stringify(metric), keepalive:true}); } } </script> |
注：上記は例です。CSPや同意フロー、IPの取扱いは別途実装します。
ログ設計・BigQueryスキーマとプライバシー対応
Logpush→BigQuery を前提にしたスキーマ例とプライバシー設計を示します。スキーマは環境により変わるため、代表例を参考にしてください。
代表的なサンプルスキーマ（BigQuery テーブル例）
以下は代表的なフィールドを想定した BigQuery DDL の例です。実際のフィールド名は Logpush 設定に合わせて調整してください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
CREATE TABLE `project.dataset.cloudflare_logs` ( timestamp TIMESTAMP, zone_id STRING, zone_name STRING, client_ip STRING, client_asn INT64, client_country STRING, request_method STRING, request_uri STRING, request_host STRING, request_query STRING, status INT64, cf_cache_status STRING, response_bytes INT64, edge_response_time_ms FLOAT64, origin_response_time_ms FLOAT64, user_agent STRING, referer STRING ); |
フィールド名対応（Cloudflare → BigQuery のマッピング例）
下表は代表的な Cloudflare ログフィールド名と BigQuery カラム名の対応例です。実運用では Logpush の出力項目名を確認して合わせてください。
| Cloudflare のフィールド名（例） | BigQuery カラム（例） | 説明 |
|---|---|---|
| ClientIP / client_ip | client_ip | クライアントIP（匿名化前） |
| ClientASN | client_asn | クライアントASN |
| ClientCountry | client_country | 国コード |
| ClientRequestMethod | request_method | HTTPメソッド |
| ClientRequestURI | request_uri | パス＋クエリ |
| EdgeResponseStatus | status | エッジのHTTPステータス |
| cf_cache_status | cf_cache_status | キャッシュステータス |
| ResponseBytes | response_bytes | レスポンスバイト数 |
| EdgeResponseTime | edge_response_time_ms | エッジ応答時間（ms） |
サンプル集計クエリ（キャッシュ率・帯域・p95/p99）
以下はサンプル集計クエリの例です。フィールド名は環境に合わせて置換してください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
SELECT DATE(timestamp) AS date, COUNT(*) AS requests, COUNTIF(cf_cache_status IN ('MISS','BYPASS','EXPIRED')) AS origin_requests, SAFE_DIVIDE(COUNTIF(cf_cache_status = 'HIT'), COUNT(*)) AS cache_hit_ratio, SUM(response_bytes)/1024/1024/1024 AS bandwidth_gb, APPROX_QUANTILES(edge_response_time_ms, 100)[OFFSET(95)] AS p95_ms, APPROX_QUANTILES(edge_response_time_ms, 100)[OFFSET(99)] AS p99_ms FROM `project.dataset.cloudflare_logs` WHERE timestamp BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY) AND CURRENT_TIMESTAMP() GROUP BY date ORDER BY date; |
プライバシー（PII）の具体的対策
ログやRUMで個人情報を扱う場合の実装例を示します。法令に従い、組織のDPOに確認してください。
- IPの匿名化／ハッシュ化：受信側でハッシュ化またはトークナイズする。例（Node.js）：
const crypto = require('crypto');
function anonymizeIp(ip){
return crypto.createHmac('sha256', process.env.IP_HASH_SALT).update(ip).digest('hex').slice(0,32);
}
サーバ側で hashed_ip を保存し、元のIPは破棄します。ソルトは安全に保管してください。
- 保持期間：生ログは業務上必要な最短期間（例：30日）、集計結果は長期保存（匿名化済）で保持。法令や社内ルールに合わせる。
- 同意実装：CMPにより計測系スクリプトのロード可否を制御する。ユーザが拒否した場合はRUMスクリプトを読み込まないか、サーバで受信を破棄する。
- アクセス制御：BigQueryデータセットやS3バケットは最小権限でアクセス可能なサービスアカウントのみ許可する。
- 法令参照：GDPR、ePrivacy、CCPA、国内は個人情報保護法（APPI）などを踏まえ、必要であれば法務に相談する。
Logpush の前提（権限と設定）
- BigQuery 宛先の場合：Logpush に必要な書き込み権限が付与されたサービスアカウントを用意する（例：BigQuery Data Editor 相当をデータセットに付与）。
- S3/GCS 宛先の場合：バケットの書き込み権限をLogpush用に限定する。
- スキーマの確認：Logpush設定時に出力項目を指定し、BigQueryのスキーマとマッピングを合わせる。
分析結果の解釈・KPI閾値と可視化（ダッシュボード例）
集計結果の読み方、閾値目安、可視化例を示します。実務ではサイト特性に応じて閾値を調整してください。
KPI閾値の目安（サイト規模別の参考値）
以下はあくまで目安です。ビジネス要件で調整してください。
- LCP：良好 < 2.5s、改善 2.5–4.0s、要対策 > 4.0s
- CLS：良好 < 0.1、改善 0.1–0.25、要対策 > 0.25
- INP：良好 < 200ms、改善 200–500ms、要対策 > 500ms
- Edge TTFB（p95）：小規模サイト < 250ms、一般サイト < 500ms、大規模バックエンドありは目標を緩和
- キャッシュヒット率：静的重視サイト > 90〜95%、混在サイト 60〜85% を目安
- エラー率：5xx < 0.1% を目標、4xx は利用形態で評価
サイト規模（例）
- 小規模（〜100万PV/月）：p95 TTFB < 300ms、cache_hit > 85%
- 中規模（100万〜1000万PV/月）：p95 TTFB < 500ms、cache_hit > 75%
- 大規模（1000万PV+/月）：SLAに応じて目標を設計する
可視化とレポート例
ダッシュボードで有用なメトリクスとチャート例を示します。Looker Studio、Grafana、Looker 等に接続してください。
- 時系列：日次のキャッシュヒット率、オリジンリクエスト、帯域（GB）
- スタックエリア：cf-cache-status 別のリクエスト比率（HIT/MISS/BYPASS 等）
- パーセンタイルライン：p50/p95/p99 の応答時間推移
- ヒストグラム：LCP 分布（ページ別）
- テーブル：ページ別のオリジンリクエスト削減と推定コスト削減
- アラート：日次オリジンリクエストが前日比20%増、5xx が閾値超過など
サンプルクエリは前節の集計例を元にダッシュボードのデータソースとしてください。
cf-cache-status の読み方（代表例）
代表的な cf-cache-status 値の例と意味を簡潔に示します。完全な一覧は公式ドキュメントを参照してください。
- HIT：エッジキャッシュから応答
- MISS：キャッシュに存在せずオリジン取得
- BYPASS：キャッシュをバイパスしてオリジン取得
- EXPIRED：期限切れによりオリジンに問い合わせ
- REVALIDATED：オリジンと再検証して応答
- DYNAMIC / UPDATING：キャッシュ対象外や更新中の応答
まとめ
RUM・Synthetic・ログを組合せることでCloudflare経由の効果を定量化できます。代表ページ群（5〜10ページ）で30日程度のベースラインを取り、Logpush→BigQueryで集計基盤を作成してください。安全対策（hosts/--resolve、Pause Cloudflare 等）は事前確認とロールバック手順を必ず用意し、PIIは受信側でハッシュ化・保持期間を短くする運用を徹底してください。