
Synthetic Monitoring(合成監視)
因果関係を明確にする実験データを取得する
Synthetic Monitoring(合成監視)とは
Synthetic Monitoring(合成監視)は、実際のユーザー行動を模倣して、計測用のクライアントから能動的にWebサイトへアクセスし、性能や可用性を監視・計測する手法です。
能動的にアクセスする性質からActive Monitoringとも呼ばれ、Webパフォーマンス計測の基本として世界的に広く活用されています。
用語の由来はSynthetic Data(合成データ)にあり、実験的に取得したデータを分析に活かすことに重きを置きます。
参照:「Synthetic Dataとは」
品質管理のための計測・監視
Synthetic Monitoringは統計的品質管理の考え方に基づき、管理できる範囲を明確化したうえで、因果関係の判定に必要なデータを計画的に取得します。
管理できない箇所のデータを集めても意思決定に結びつきにくいため、「どこまで管理できるか」を合意し、その範囲に人的・時間的・資金的リソースを集中させます。
コントロール可能な範囲/不可能な範囲
ユーザー環境の全てをコントロールすることはできません。サイト運用者が直接管理できる主な要素は、HTML・CSS・JavaScriptなどフロントエンドと、配信インフラ(CDN、トランジット)など一部ネットワークに限られます。
一方で、ユーザーの端末性能やブラウザのプラグイン、ラストマイルの回線品質は管理不能です。
被写体の良し悪しはフィルム品質とは別、という古いCMの比喩になぞらえれば、配信を高速化できても受信側の端末やプラグイン由来の遅延は別問題です。
Synthetic MonitoringとRUM(Real User Monitoring)の違い
観点 | Synthetic Monitoring | Real User Monitoring |
---|---|---|
目的 | 因果の切り分け・回帰テスト・SLA監視 | RUMは実ユーザー体験の把握とセグメント別の実態把握 |
データ特性 | 因果関係を明確にする実験データ | 実際の状況を明確にする観測データ |
得意領域 | 変更の効果検証とアラート | RUMは地域・端末・回線などの実環境での体感差の把握 |
Synthetic Monitoringにおけるフィッシャー三原則の適用
因果関係を明らかにするには実験介入と実験計画法が必須です。特に以下の三原則を運用に落とし込みます。
参照:「実験計画法とは」
1. 局所管理化(ブロッキング / Blocking)
影響を調べたい要因以外を統一します(制御変数)。
Synthetic Monitoringでは次を固定します。
- マシンスペック
- CPU、メモリ、NICなど計測用マシンの構成を統一
- OS
- OS種別とバージョンを固定
- ブラウザ
- ブラウザ種別・バージョン・拡張有無を統一
これにより、残る主要な変数は以下に絞られます。
- 自社バックエンド処理
- サードパーティ(タグマネ、解析、A/B、計測、レコメンド、広告 等)のバックエンド処理
- ネットワーク(レイテンシ、スループット、パケットロス、経路)
- フロントエンド処理(自社およびサードパーティスクリプト)
層別化(Stratification)による原因特定
キャリア別・都市別に層別して計測比較すると、特定グループ固有の問題を発見できます(例:特定キャリア×都市でのDNS応答遅延)。

2. 反復(リプリケーション / Replication)
物理システムは必ず揺らぎます。
同条件で反復計測し、分布とばらつきを把握します。
例えば15分ごとなら1日あたり96の標本(サンプル)です。
計測の目的は「高速を誇示する」ことではなく、品質不適合(遅延・エラー)がないかを検知することです。
分布と閾値を意識して、目標値に対して十分な余裕(例:目標1.5秒なら平均1.0秒を狙う)を持たせます。
検出力はサンプルサイズに依存します。
検出力とは、統計的な仮説検定において、真に差がある場合に、その差を正しく検出できる確率のことです。
1時間ごと(24件)より15分ごと(96件)の方が当日の異常検出は信頼できます。
さらに精度を高めるなら取得頻度(サンプルサイズ)を戦略的に増やします。
3. 無作為化(ランダム化 / Randomization)
ブロッキングや反復でも取り除けない潜在要因の偏りを抑えるため、計測タイミングをランダム化します。
例えば「毎時00/15/30/45分固定」ではなく、「±数分のジッタ」を持たせます(例:18:02、18:14、18:29、18:48)。
代表性(Representativeness)
代表性とは、標本が母集団をどれだけ的確に代表するかの度合いです。
モバイル計測を固定の4Gエミュレーションのみで代替したり、自社ネットワークのみで計測すると、実世界の利用実態(キャリア・端末・地域差)を代表できません。
Catchpointのように各国・各都市・各ネットワークに測定拠点を配置する/国内で拠点を増やす意義は、この代表性の担保にあります。
拠点人口を用いて人口カバー率として定量化し、監視の網羅性を評価できます。
代表性を欠いたデータは、意思決定を誤らせます。
例)東京の自社回線のみの計測で問題なし→地方×特定キャリアで重大遅延を見落とす→改善優先度の誤配分、機会損失。
運用フェーズと計測戦略
- 現状把握フェーズ
- ベースライン構築、主要指標と分布の把握
- 高速化フェーズ
- 変更の効果検証(A/B・カナリア)と回帰検出(Shift Left:出荷前の性能ゲート/Shift Right:カナリア+本番監視)。詳しく
- 維持・監視フェーズ
- SLO/SLA準拠監視、アラート、トレンド劣化の早期検知
いずれのフェーズでも指標は時間とともに変動します。継続的計測と層別分析、閾値の見直しを定期的に行いましょう。
シフトレフト/シフトライトとSynthetic Monitoring
シフトレフト(左=リリース前)とシフトライト(右=本番運用)で、Synthetic Monitoring を使い分けて因果と品質を保証します。
観点 | シフトレフト(Left:早期検知) | シフトライト(Right:本番の安全運用) |
---|---|---|
目的 | 出荷前に性能・可用性の劣化を未然に排除(パフォーマンスバジェットでゲート) | 安全な段階的展開と、体験品質の維持(回帰・劣化の即時検知) |
対象環境 | PR/CI、エフェメラル環境、ステージング | カナリア、段階的ロールアウト、本番全量 |
Syntheticの使い方 | 同条件A/B(ブロッキング・反復・無作為化)で実験的に効果検証 | カナリア対象へピン留め計測+24/7監視で回帰検出 |
代表的な基準 | p95 TTFB ≤ ベースライン+10%、p95 LCP ≤ 2.5s、JS重量 ≤ 1.5MB | p95 LCP > 直近7日中央値+15% が連続/HTTP失敗率 > 0.5% でアラート |
Left:リリース前の「実験装置」として
- CIでSynthetic A/B
- 同一シナリオ・同一環境で現行(A)と変更後(B)を比較し、合格基準を満たさなければブロック。
- ステージングで層別検証
- 都市×キャリアで分位点(p95/p99)とエラー率を評価。
Right:本番の“見張り番”として
- カナリア+ピン留め計測
-
一部トラフィックにのみ変更を適用し、Syntheticをそのプールへ固定実行。
基準クリアで段階拡大、悪化で即ロールバック。 - 回帰検出
- 分位点+エラー率+可用性(SLO)を連続判定で監視し、イベントログ(デプロイ/CDN/DNS)と突合。
[開発] → [PR] → (CI Synthetic: A/B & 予算ゲート) → [ステージング]→ (層別A/B検証) → [カナリア] → (Syntheticピン留め)→ [全面展開] → (Synthetic + RUMで回帰検出・継続監視)
実務上のヒント
- シナリオ設計
- LCP/TTFBなどのページ指標+ユーザーフロー(検索→詳細→購入)を両輪で。
- 場所とネットワークの層別
- 都市(札幌・東京・大阪・福岡など)×キャリア(NTT・KDDI・J:COMなど)でテストマトリクスを作成。
- 閾値
- 平均のみでなく、
p95/p99
とエラー率も監視。SLOはユーザー体感に近い分位点で管理。 - 変更管理
- デプロイ、CDN設定、DNS変更などのイベントログと計測時系列を必ず突き合わせる。
- RUM連携
- RUMで兆候検知→Syntheticで再現・検証→修正→Syntheticで回帰防止、のサイクルを確立。
- シフト運用の定着
- Left:CIにパフォーマンスバジェットを実装/Right:カナリア用プールとピン留め計測を標準化。
まとめ
Synthetic Monitoringは、統計学と統計的品質管理のノウハウを実務へ落とし込んだ再現性の高い実験計測です。
局所管理化・反復・無作為化と、代表性の担保・層別分析を組み合わせ、さらにシフトレフト/シフトライトで「出す前に壊さない/出した後も壊さない」を両立することで、因果関係を正しく捉えながら継続的にユーザー体験を改善できます。