独立サイトのパフォーマンス監視：合成監視、リアルユーザー監視、アラートしきい値と対応

独立サイトのパフォーマンス監視：合成監視、リアルユーザー監視、アラートしきい値と対応

一、「自分はすぐ開ける」が通用しない理由

サイト運営者が最もよくやる誤りは、自分のパソコンでトップページが2秒で開くからサイト性能は問題ないと判断することだ。越境ECの独立サイトでは、これはほぼ確実に誤判定になる。自分は国内にいて自宅のブロードバンドを使い、CDN の近接キャッシュも効いているかもしれない。一方バイヤーは欧州・中東・ラテンアメリカにいて、現地のネットワークから大洋を越えてオリジンにアクセスする。同じページでも、自分が測れば1秒、相手側では6秒かもしれない。

ここでの直感に反する判断はこうです。パフォーマンス監視が測るべきは買い手のネットワークと地域であり、自分の環境ではない。国内で自分のパソコンから測るのは「自分と自分のサーバー間」の経路であり、この経路は海外のバイヤーにとって何の参考にもならない。

正しい方法は、監視プローブをバイヤーが実際にいる地域に設置し、その地域のネットワークからアクセスして得た数値を判断材料にすることだ。指標そのものの合格ラインは次を参照。Core Web Vitals。

二、合成監視：固定プローブで「早期発見」を担う

合成監視（Synthetic Monitoring）とは、固定スクリプトで、あらかじめ決めた地点から決まった頻度で指定したいくつかの重要ページにアクセスし、応答時間と可用性を記録するものだ。定期巡回のような役割を果たし、1分ごとにトップページ、商品一覧ページ、問い合わせページにアクセスし、ページが開けない、または遅すぎる場合にアラートを出す。

その価値は「早さ」と「安定性」にあります。プローブ環境が固定されているため、今日と明日の数値を比較でき、ユーザーが変わっても結果が変わりません。サーバーダウン、証明書の期限切れ、APIの停止などを、合成監視なら1分以内に検知できます。

ただし合成監視が測るのは固定された経路なので、「特定の地域でスマホから特定の深いページにアクセスすると極端に遅い」といったロングテールの問題は見つけられません。それはリアルユーザーモニタリングの役割です。重要ページの選び方と可用性監視の組み立て方は、こちらをご覧ください。サイト監視とアラート。

シナリオ例：プローブはフランクフルト、シンガポール、シリコンバレーの3拠点に設置し、それぞれが1分ごとにトップページへアクセスします。ある日、フランクフルト拠点で3回連続タイムアウトし、スマホにアラートが届きました。ログを調べると、ヨーロッパからオリジンサーバーへの経路が不安定で、アジアとアメリカは正常でした。こうした地域固有の問題は、国内からでは絶対に発見できません。

三、リアルユーザーモニタリング：実データを収集し「正確さ」を担う

リアルユーザーモニタリング（RUM, Real User Monitoring）は、ページにスクリプトを埋め込み、実際の訪問者ごとに読み込み時間、デバイス、地域、ネットワークを収集します。測るのは「シミュレーションユーザー」ではなく、実際の購入者の体験です。データは平均値ではなく分位点で見る必要があります。

なぜ平均値ではだめなのでしょうか。平均値はごく少数の極端に速い、または遅いサンプルに引っ張られ、大多数の実際の体験を覆い隠してしまうからです。正しい方法はP75を見ることです。すべてのユーザーの読み込み時間を小さい順に並べ、75%の位置にある値のことです。

P75が4秒を超えるということは、4分の1のユーザーがそれより遅いことを意味します。越境ECサイトでは地域別にスライスして見る必要もあります。全体のP75は合格でも、中東地域だけを見ると6秒で、問題が地域の中に隠れていることがあります。CDNが各地域の高速化をどう支援するかは、こちらをご覧ください。CDNグローバル高速化。

四、アラートしきい値と段階的な対応

監視してもアラートにつながなければ、監視していないのと同じです。データがダッシュボードに横たわっていて、誰も見なければ存在しないのと同じです。ただしアラートが多すぎても、3日後にはオオカミ少年のように無視されます。やり方は、深刻度に応じて段階分けし、レベルごとに対応速度を変えることです。

しきい値は具体的な数字で決めます。可用性（ページが開くか）は3回連続で失敗したら即アラート、5分以内に対応。性能劣化（LCP P75が2秒から4秒以上に悪化）は当日中に対応。長期的な傾向の問題（毎週じわじわ遅くなる）は週次会議で確認。一度だけの失敗でアラートを出してはいけません。それはノイズです。連続で失敗したときだけアラートを出すのがポイントです。

シナリオ例：アラートルールを3つ設定します。ルール1：主要ページのいずれかでプローブが3回連続失敗したら電話アラート。これはダウン級です。ルール2：LCP P75が2日連続で4秒を超えたらメールアラート。これは性能劣化級です。ルール3：5xxエラー率が10分間で1%を超えたら即時アラート。これはバックエンド障害級です。3つのルールは3つの対応速度に対応し、見逃しも過剰通知も防ぎます。

5. 落とし穴：性能監視で最も多い4つの誤判定

1つ目の落とし穴は、合成監視だけを見て実ユーザーを見ないことです。プローブはすべて正常でも、ある地域のスマホユーザーが極端に遅いことがあります。プローブはデスクトップ版の固定パスを測っているからです。2つ目の落とし穴は、平均値だけを見ることです。平均値が合格でも大多数が速いとは限りません。必ずP75を見て、地域とデバイスで切り分けましょう。

3つ目の落とし穴は、アラートが多すぎて本当のアラートが埋もれることです。1日に20回鳴れば人は麻痺し、本当にダウンした回が見逃されます。4つ目の落とし穴は、トップページしか測らないことです。トップページはCDNでよくキャッシュされますが、実際のコンバージョンは製品詳細ページと問い合わせページで起きます。この2ページが遅いと受注を逃します。クリティカルパスは全体をカバーしましょう。日々のメンテナンスのリズムは次を参考に。公式サイト保守期間。

FAQ よくある質問

最後に

性能モニタリングの核心は「正しい相手を測り、正しい数字を見て、正しいアラートを出す」ことです。個人で海外向けECサイトを運営するなら、購入者地域に合成モニタリングを置いて予兆を検知し、RUMを仕込んで実体験を把握し、P75とCore Web Vitalsの合格ラインでレベル分けして通知する。この組み合わせは大きなコストはかかりませんが、「ユーザーが遅いと感じている」という曖昧な不満を、「どの地域の、どのページが、どれだけ遅いか」という具体的な数字に変えてくれます。

導入は3ステップ。第一に、フランクフルト・シンガポール・シリコンバレーにプローブを置き、トップページ・製品ページ・問い合わせページを毎分計測します。第二に、ページにRUMを埋め込み、LCP・INP・CLSをP75で見て、地域別に切り分けます。第三に、ダウン時は電話アラート、性能劣化はメールアラート、傾向の課題は週次レポートで受け取ります。この3ステップを終えれば、サイトの速さの判断は「なんとなく大丈夫そう」から「買い手は実際に何秒待っているか」に変わります。

覚えておきたい一言。性能監視とは自分のサイトを測ることではなく、買い手側の体験を測ることです。プローブを国内に置くのは、目をつぶって海外顧客に答案を出すようなものです。