チェックの失敗からユーザーへの影響まで：Grafana CloudでSynthetic MonitoringとFrontend Observabilityを併用する

注記：本記事は2026年8月に公開され、Grafana Cloud Synthetic MonitoringとFrontend Observabilityの最新の機能とワークフローを反映して、2026年10月に更新されました。

アプリのあるページが表示されない、というサポートへのエスカレーションを受けたとします。ところが、シンセティックチェックを確認すると、すべて緑色です。稼働率は100%で、プローブも成功しています。何かがおかしいものの、どちらを信じればよいのでしょうか。

Grafana Cloud Synthetic Monitoringを使ったことがあれば、この両方の立場を経験しているはずです。ユーザーが実際にそのパスで行き詰まっているのに、チェックはきれいに成功している場合があります。逆に、チェックが失敗して慌て、30分かけて再現を試みた末に、単一のリージョンで起きた一時的な不具合で、実ユーザーへの影響はほとんどなかったとわかる場合もあります。緑のダッシュボードも赤いアラートも、嘘をついていたわけではありません。ただ、知りたい問いに答えていなかっただけです。

ここに根本的な問題があります。Synthetic Monitoringは、何かが壊れたかどうかを伝えることにかけては、非常に優れています。しかし、それが誰に起きたのか、どれほど深刻なのか、なぜ重要なのかまでは教えてくれません。これはSynthetic Monitoringの欠陥ではなく、管理されたスケジュール実行のテストが知りうる範囲の限界です。

Grafana Cloud Frontend Observabilityは、このギャップを埋めるのに役立ちます。Synthetic Monitoringが外側から先回りして得るシグナルを提供するのに対し、Frontend Observabilityは、実際のユーザーが何を体験しているかを示すものです。この2つの視点を組み合わせることで、Grafana Cloudは、チームがDigital Experience Monitoring（DEM）のループを完成させる助けになります。シンセティックのアラートには実ユーザーの情報が加わり、実ユーザーのデータは、より的確なシンセティックチェックにつながります。

この記事では、シンセティックだけの戦略が盲点を生みうる理由、Frontend Observabilityが何を加えるのか、そしてGrafana Cloudで両者をいっしょに運用する実践的なワークフローを、順に見ていきます。

その過程で、効果が具体的であることもわかるでしょう。トリアージが速くなり、アラートには影響範囲の情報が付き、チェックのセットは、時間とともに古くなるのではなく、実際のトラフィックに合わせて進化していきます。

緑のチェックは、ユーザーが満足している証拠ではない

Synthetic Monitoringは、能動的なシグナルです。ジャーニーをスクリプトで記述するか、ターゲットを宣言し、既知のプローブロケーションから一定のスケジュールで実行すると、一貫性のあるクリーンな結果が返ってきます。変数を厳密に制御できることが、この方法の価値です。チェックが失敗したり、チェックのメトリクスが基準から外れたりしたとき、原因となっている場所、手順、アサーションを、正確に特定できます。ユーザーより先に問題を検知するための手段です。

ただし、シンセティックだけの戦略には、根本的な穴があります。

• シンセティックテストがカバーするのは、テストしようと思いついた範囲だけです。スクリプトで書いたパスは、予想したジャーニーしか反映しません。実際のユーザーは、想定外のパスをたどったり、ロングテールのブラウザとデバイスの組み合わせでアクセスしたり、プローブでは再現しにくい地域特有のケースに遭遇したりします。エスカレーションに上がってくるエラーは、誰も考えていなかったパスで起きているのかもしれません。
• 影響範囲が見えません。チェックの失敗は、ユーザーも同じように失敗するはずだということを示します。しかし、すでに何人の実ユーザーが失敗したかまでは教えてくれません。この失敗は、1つのリージョンの3人に影響しているのでしょうか。それとも、静かに数千人の体験を悪化させているのでしょうか。シンセティックチェックには、それがわかりません。
• シグナルの補強がないと、アラート疲れにつながります。すべてのシンセティックアラートが、同じように（欠けた）ユーザー影響の情報しか持たなければ、どのアラートも同じ緊急度に感じられます。適切なラベル付けの戦略やアラートの感度調整で対処するユーザーも多いのですが、アラートが多すぎて緊急に感じられなくなり、気づかないうちに監視そのものが形骸化してしまうこともあります。

私は、Synthetic Monitoringをカナリアのようなものだと考えています。ユーザーの多くが影響を受ける前に、早く、確実に警告しようとするものです。ただ、カナリアが伝えられるのは空気が悪くなったことまでで、それによって何人が影響を受けるかまでは教えてくれません。

ユーザーのブラウザで実際に起きていること

Frontend Observabilityは、オープンソースのGrafana Faro SDKを基盤とした、リアルユーザーモニタリング（RUM）です。軽量なJavaScriptのスニペットでアプリを計装すれば、ユーザーのブラウザで実際に起きていることを取得できます。Frontend Observabilityでは、次のようなデータを確認できます。

• Core Web Vitalsとページのパフォーマンス：読み込み、インタラクション、視覚的な安定性を、実際のデバイス、ネットワーク、地域でユーザーが体験するとおりに、実際のセッションから取得します。
• JavaScriptエラー：スタックトレースと、その周辺のユーザーの状況を含みます。チェックのスクリプトでは想定していなかったエラーも対象です。
• Session Replay：実際のユーザーのジャーニーを最初から最後まで追い、何かが壊れる前に、そのユーザーが何をしていたかを正確に確認できます。

どちらもWeb Vitalsを生成できますが、このデータはシンセティックのデータと重複するものではありません。両者を組み合わせて運用する理由は、まさにそこにあります。

シンセティックチェックは、管理された実験です。同じスクリプト、同じターゲット、同じプローブロケーション、同じ実行環境で、何度も繰り返します。変わる入力は、実行された時刻だけです。そのため、チェックの結果がベースラインから外れ始めたときは、その変化に意味があります。変わったのはテストではなく、システムのほうだからです。この決定論的な性質のおかげで、シンセティックのデータは、アラートの根拠にできるほど信頼でき、AIエージェントが推論に使えるほど確かなものになります。

実ユーザーのデータは、その正反対です。すべてのセッションは、基本的に1つとして同じものがありません。ユーザーごとに、デバイス、ブラウザ、OS、ネットワーク、地域などが違います。1つのセッションだけでは、問題の原因が自分たちのコードなのか、不安定な接続なのか、動作に干渉するブラウザ拡張機能なのかはわかりません。しかし、十分な数のセッションを集めると、共通点が見えてきます。影響を受けたユーザーはすべてChromeを使っている、特定の1つのリージョンにいる、あるいは同じJavaScriptエラーに遭遇している、といった具合です。シグナルは、個々のサンプルの中ではなく、サンプル全体に広がるパターンの中にあります。

だからこそ、どちらも、もう一方の代わりにはなりません。シンセティックチェックは、1つ1つを信頼できる少数のサンプルを提供します。RUMは、全体として信頼できる数千のサンプルを提供します。一方は何かが変わったことを検知し、もう一方は、それが誰に影響しているのか、影響を受けた人たちに何が共通しているのかを教えてくれます。

信頼性のループを実践する

ここからは、実践的な内容です。このループは、両方向に回ります。1つは、シンセティックのアラートが発火し、実ユーザーのデータで範囲を絞り込む、リアクティブな方向です。もう1つは、実ユーザーのデータでカバーされていない部分が見つかり、それをチェックとして定義する、プロアクティブな方向です。

リアクティブ：シンセティックのアラート後に、影響範囲を把握する

オンコール担当のエンジニアなら誰でも、チェックが失敗した後の慌ただしさを知っています。本当に起きていることなのか。実際に重要な問題なのか。自分で、あるいは誰かに代わりに試してもらって、再現できるのか。実ユーザーのデータがあれば、この悩みは単なる調べものになります。

シナリオは次のとおりです。/checkout のブラウザチェックが、フランクフルトのプローブから失敗しました。Frontend Observabilityがなかった頃は、次の手順は推測に頼るしかありませんでした。しかし、Grafana Cloudで両方のシグナルを使えば、ワークフローは次のようになります。

1. チェックが失敗する。Synthetic Monitoringが、/checkout のブラウザチェックが09:13にフランクフルトから失敗したことを通知します。
2. 実際のセッションに移動する。Synthetic Monitoringにあるリンクをたどり、Frontend Observabilityで取得されたセッションに直接移動します。この連携は、タイムスタンプの突き合わせやURLの探し回りを省くために作りました。ここでは、問題が起きている可能性のあるページと、そのブラウザチェックのセッションリプレイを確認できます。Page ボタンをクリックすれば、同じページを訪れた実際のユーザーのセッションも表示されます。
3. 影響を定量化し、パターンを探す。同じ時間帯に、実ユーザーが何人エラーに遭遇したかがわかります。それと同じくらい重要なのは、影響を受けたセッションに共通点があるかどうかです。特定のブラウザか、特定のリージョンか、同じJavaScriptエラーか、という点です。こうした共通点によって、トレースを1つも開く前に、根本原因の候補が絞り込まれます。これは、個々のセッションにも、シンセティックチェック単体にも、わからないことです。
4. 根本原因を確認する。ユーザーが遭遇したエラーを、チェックで失敗したアサーションと比較します。原因がフロントエンドの背後にある場合は、Grafana CloudのKnowledge Graphが、チェックとフロントエンドアプリを、つながっているサービスにすでに対応付けています。そのため、担当者を尋ねて回らなくても、失敗したジャーニーからバックエンドのサービスまでの経路を確認できます。
5. 勘ではなく、データに基づいて対応する。これで、次の3点がわかります。

• 範囲：何人のユーザーが影響を受けたか
• 期間：チェックの実行間隔で検知された時刻ではなく、実際に問題が始まった時刻はいつか
• 深刻度：ユーザーが体験したのは、完全な失敗か、緩やかな劣化か

結果として、インシデントの優先度や顧客への連絡は、データに基づいたものになります。「チェックが失敗したので調査中」というSlackの最初のメッセージと、「09:07以降、EUのユーザーの約8%でチェックアウトのフローが劣化している」というメッセージとでは、まったく違います。

プロアクティブ：実ユーザーのデータを、より賢いシンセティックテストに変える

ループの戻りの経路は、多くのチームが見落としているものです。この経路がなければ、実際の利用状況が変わっても、シンセティックチェックのセットは更新されません。

シナリオは次のとおりです。Frontend Observabilityを見ると、かなりの割合のChromeユーザーが、/onboarding/step-3 でJavaScriptエラーに遭遇しています。このパスは、ユーザーが苦労するとは誰も予想していなかったため、どのシンセティックチェックにもカバーされていません。

1. カバレッジの穴を見つける。Frontend Observabilityの、エラーの多い順とページの遅い順のビューで、実際のユーザーが最も苦労している場所を確認し、その一覧を、シンセティックチェックの一覧と照らし合わせます。一致しない部分が、盲点です。
2. チェックとして定義する。そのパスを対象にした新しいブラウザチェックを作成します。または、gcxやオーサリングスキルを使って、エージェントに作成させることもできます。
3. 現実に基づいてしきい値を設定する。根拠のない値ではなく、Frontend Observabilityから得られる実ユーザーのp75／p95のベースラインをもとに、レイテンシのしきい値を設定します。これで、スプリント計画会議で誰かが決めた推測値ではなく、実ユーザーが普段体験している性能を基準に、劣化したときにチェックがアラートを出すようになります。さらに、チェックからSLOを作成すれば、そのジャーニーは、成功・失敗のアラートだけでなく、エラーバジェットも持てるようになります。
4. シグナルの弱いチェックを廃止する。実際のトラフィックのデータからは、監視しているページのうち、ほとんど誰も訪れないページもわかります。それらの実行回数を、トラフィックが多く、ユーザーが苦労しているパスに振り向ければ、費用を増やさずにカバレッジを向上できます。

結果として、シンセティックチェックのセットは、昨年の想定ではなく、実際のトラフィックのパターンを反映したものになります。実行するチェックの1つ1つが、存在する理由を持つようになります。

Grafana Cloudで相関を設定する

このループを回すのに、高度な連携は必要ありません。2つの製品のデータは、どちらも同じGrafana Cloudスタックに保存されます。実践的な構成要素を、いくつか紹介します。

• チェックがすでに監視しているアプリを計装する。最も早く効果が出るのは、最も重要なブラウザチェックと同じURLを、まずFaro SDKで計装する方法です。これで、すでに最重要と判断しているフローについて、両方のシグナルがそろいます。
• 両方のデータソースを並べてクエリする。シンセティックの結果は、PrometheusメトリクスとLokiログとして保存されます。Faroのデータも、同じGrafana Cloudのインスタンスでクエリできます。Exploreでは、時間範囲とURLをもとに、チェックの失敗と実ユーザーのエラーを並べて確認できます。
• 重要なフロー向けに、1画面にまとめる。シンプルなダッシュボードのレイアウトが、よく機能します。片側にシンセティックチェックのステータスと稼働率、反対側に同じURLのFaroのエラー率とセッション数を置きます。チェックが失敗したときも、最初のSlackメッセージを送る前に、影響範囲が一目でわかります。

まとめ

信頼性を担うチームを率いているなら、このループを完成させて得られるものは次のとおりです。

• トリアージが速くなる。本物なのか一時的な不具合なのかという議論はなくなります。両方のシグナルが1か所にあるためです。
• オンコールが楽になる。最初から影響範囲の情報がわかるので、深刻度の判断は、20分かけて調べた後ではなく、数分で下せます。
• テストのカバレッジが賢くなる。シンセティックチェックのセットは、古くなるのではなく、実際のトラフィックのパターンとともに進化します。
• 開発と運用の連携が深まる。開発者は、アラートの背後にある実際のセッションを見られます。運用担当は、しきい値の背後にあるシンセティックのベースラインを信頼できます。

Synthetic Monitoringは、顧客より先に問題を教えてくれます。Frontend Observabilityは、顧客が実際に体験したことを教えてくれます。この2つがそろうことで、Digital Experience Monitoringのループが完成し、起こりうる問題と実ユーザーへの影響の両方を、よりはっきりと見ながら、フロントエンドの信頼性を管理できます。

Digital Experience Monitoringを始めるなら、Grafana Cloudの無料プランではじめるのが手軽です。すでにGrafana Cloud Synthetic Monitoringを使っているなら、数分でFrontend Observabilityを始めることができます。最も重要なチェックがすでに監視しているウェブサイトやアプリを、まず計装してください。

さらに詳しく知りたい場合は、ObservabilityCON 2026のDigital Experience Monitoringに関するセッションを確認してください。