フロントエンド本番公開後に何が起きるか？ 実効性のあるモニタリング

新しいバージョンのフロントエンドをリリースした。ビルドは成功し、デプロイも完了し、CDNが最新のバンドルを配信している。ところが5分後、東南アジアのユーザーから「チェックアウトボタンをクリックしても何も起こらない」と報告が入る。サーバーログにはエラーはなく、APIも正常に応答している。問題はあなたの側からは見えない。

これがフロントエンドモニタリングの現実だ。バックエンドサービスならプロセスの状態やCPU使用率、リクエストログを確認できるが、フロントエンドはあなたが制御できないデバイス上で動作する。ブラウザ、OS、ネットワーク環境、さらには広告ブロッカーによって、コードの動作はユーザーごとに異なる。サーバーだけを監視していては、目隠しをして飛んでいるようなものだ。

なぜサーバーモニタリングだけではフロントエンドに不十分なのか

バックエンドがダウンすれば、すぐにわかる。プロセスが停止し、ポートが閉じ、ログにエラー率の急上昇が現れる。アラートが飛び、調査し、修正する。

フロントエンドの障害は違う。JavaScriptの例外が発生するのは、回線の遅い古いiPhoneで動作するSafari 15だけかもしれない。API呼び出しは成功しても、サードパーティのスクリプトが読み込めずにレンダリングロジックが静かに壊れる。ユーザーには真っ白な画面や回り続けるスピナーが見えるが、サーバー側は何も異常を検知しない。

このギャップを埋めるには、フロントエンド専用のモニタリング戦略が必要だ。インフラが報告する内容だけでなく、ユーザーがブラウザで実際に体験していることを把握しなければならない。

ブラウザのエラー率：最初のシグナル

フロントエンドリリース後に追跡すべき最も重要な指標は、ブラウザ上でのJavaScriptエラー率だ。これはAPIエラーやサーバーサイドの例外ではない。ユーザーのデバイス上で実行されているコード内部で発生するエラーである。

よくある例：

  • 古いバージョンのブラウザでは利用できないAPIを使おうとした関数
  • ユーザーのネットワーク切断によりライブラリの読み込みに失敗した
  • APIレスポンスに期待したフィールドが含まれていなかったために発生したnull参照エラー
  • ビルドプロセスで混入し、特定のミニファイ設定でのみ顕在化する構文エラー

これらを捕捉するには、実際のユーザーから例外、スタックトレース、ブラウザコンテキストを収集するReal User Monitoring（RUM）ツールが必要だ。Sentry、Datadog RUM、New Relic Browserなどのツールは、ページに小さなスクリプトを追加し、未処理のエラーをインターセプトして中央のコレクターに送信する。

以下は、グローバルエラーハンドラを設定し、ページ読み込みパフォーマンスを取得する最小限の例である。

// キャッチされなかった例外のグローバルエラーハンドラ
window.onerror = function (message, source, lineno, colno, error) {
  const errorData = {
    message: message,
    source: source,
    line: lineno,
    column: colno,
    stack: error ? error.stack : null,
    url: window.location.href,
    userAgent: navigator.userAgent
  };
  // エラーデータをモニタリングエンドポイントに送信
  fetch('/api/log-error', {
    method: 'POST',
    body: JSON.stringify(errorData),
    headers: { 'Content-Type': 'application/json' }
  });
};

// ページ読み込みパフォーマンスの取得
window.addEventListener('load', function () {
  const perfData = window.performance.timing;
  const pageLoadTime = perfData.loadEventEnd - perfData.navigationStart;
  console.log('ページ読み込み時間 (ms):', pageLoadTime);
  // モニタリングサービスに送信
  fetch('/api/log-performance', {
    method: 'POST',
    body: JSON.stringify({ loadTime: pageLoadTime, url: window.location.href }),
    headers: { 'Content-Type': 'application/json' }
  });
});

重要なのは、エラー率の変化に基づいてアラートを設定することだ。リリース直後にエラー率が0.1%から2%に跳ね上がったら、何かがおかしい。ユーザーからの苦情を待つ必要はない。データが苦情が殺到する前に教えてくれる。

ページ読み込み時間：ユーザーが実際に感じるもの

ビルド時間やデプロイ速度はユーザーにとって重要ではない。重要なのは、ページがユーザーの画面にどれだけ速く表示されるかだ。フロントエンドが遅いとユーザーは離脱し、コンバージョン率が下がり、プロダクトの評判を損なう。

ページ読み込み時間はいくつかの要因に依存する：

  • JavaScriptバンドルのサイズ
  • ページが行うネットワークリクエストの数
  • ユーザーのネットワーク速度とレイテンシ
  • デバイスの処理能力
  • コードがレンダリングとインタラクティビティをどのように処理するか

RUMツールを使えば、全ユーザーベースにおける読み込み時間の分布を確認できる。ある地域のユーザーは3秒でページを表示できるが、別の地域のユーザーは8秒待たされていることがわかる。あるいは、3G回線のモバイルユーザーと光回線のデスクトップユーザーでは全く異なる体験をしていることがわかる。

リリース後は、読み込み時間の分布をリリース前後で比較しよう。中央値が500ミリ秒増加していれば、それはリグレッションだ。機能自体は正しく動作していても、ユーザー体験は低下している。

ユーザーインタラクション：ボタンは実際に機能したか？

エラー率と読み込み時間は技術的な健全性を教えてくれるが、ユーザーがタスクを完了できるかどうかは教えてくれない。エラーなくページが読み込まれても、フォーム送信が壊れていたり、検索バーが機能していなかったりする可能性がある。

ここで活躍するのが合成モニタリングだ。アプリケーションを通じたユーザージャーニーをシミュレートする自動スクリプトを作成する。スクリプトはボタンをクリックし、フォームに入力し、ページ間を移動し、各ステップが正常に完了することを確認する。

例えば、Eコマースサイトの合成テストは次のように行う：

  1. ホームページを読み込む
  2. 商品を検索する
  3. 商品をカートに追加する
  4. チェックアウトに進む
  5. 配送情報を入力する
  6. 注文を送信する
  7. 注文確認ページが表示されることを確認する

これらのテストをデプロイのたびに実行する。チェックアウトのステップでテストが失敗したら、そのフローで何かが壊れたことがわかる。実際のユーザーが問題に遭遇する前に調査できる。

合成モニタリングはRUMの代わりにはならない。制御された反復可能なチェックを提供するが、実際のユーザー環境の多様性をすべて捉えることはできない。両方を併用しよう。

モニタリングをパイプラインに統合する

モニタリングはデプロイ後に行う別個のアクティビティであってはならない。デプロイパイプライン自体の一部であるべきだ。

実用的な流れは次の通り：

  1. 新しいフロントエンドバージョンを本番環境にデプロイする
  2. CDNの伝播を待つ（通常数分）
  3. 本番URLに対して合成テストを実行する
  4. 実際のユーザーからRUMデータが蓄積されるのを5〜10分待つ
  5. エラー率と読み込み時間のメトリクスをしきい値と照合する
  6. いずれかのメトリクスがしきい値を超えた場合、自動ロールバックをトリガーするか、オンコールチームに通知する

これはパイプラインが何時間もRUMデータを待つという意味ではない。最初のチェックは迅速な健全性テストだ。最初の数分でエラー率が急上昇すれば、すぐに捕捉できる。メトリクスが正常に見えれば、デプロイは健全とみなされ、受動的なモニタリングを継続できる。

フロントエンドリリースモニタリングの実践的チェックリスト

  • JavaScriptエラー、読み込み時間、ブラウザコンテキストを取得するRUMツールを導入する
  • デプロイ後のエラー率変化に対するアラートを設定する
  • 重要なユーザージャーニーの合成テストを作成する
  • デプロイごとに合成テストを自動実行する
  • エラー率と読み込み時間の許容しきい値を定義する
  • しきい値超過時に自動ロールバックまたは通知を設定する
  • インシデントだけでなくトレンドを把握するためにモニタリングデータを定期的にレビューする

まとめ

フロントエンドはあなたが所有しないデバイス上で、制御できない環境で動作する。サーバーログは、ボタンが動かなくなったときやページの読み込みが遅すぎるときに教えてくれない。Real User Monitoringと合成テストは、ユーザーが報告する前に問題を発見するために必要な可視性を提供する。これらのチェックをデプロイパイプラインに統合すれば、リリースが実際に機能しているかどうかを、単にデプロイが成功したかどうかではなく、数分以内に把握できる。