バックエンドのエラーはログに残りますが、フロントエンドのエラーはユーザーのブラウザの中で起きて、そのまま消えていきます。「特定の環境でだけ画面が真っ白になる」という報告を受けても、手元で再現できず調査が難航する──これがフロントエンド監視の出発点となる課題です。
本記事では、ErrorBoundaryとunhandledrejectionによるエラーの捕捉、エラー収集ツール導入時の設計、そして運用で必ず直面するノイズ対策を整理します。
ErrorBoundaryで「画面全滅」を防ぐ
Reactでは、レンダリング中に例外が発生するとコンポーネントツリー全体がアンマウントされ、画面が真っ白になります。これを局所化するのがErrorBoundaryです。
- アプリ全体を包む最上位のErrorBoundaryで「全画面エラー表示＋再読み込み導線」を用意する
- ウィジェット単位（サイドバー、グラフ、コメント欄など）にも配置し、一部の障害が画面全体を巻き込まないようにする
- 捕捉したエラーは必ず収集ツールへ送信する（握りつぶすと障害が見えなくなります）
注意点として、ErrorBoundaryが捕捉するのはレンダリング中・ライフサイクル中の例外のみです。イベントハンドラ内や非同期処理の例外は捕捉されないため、別の仕組みが必要です。
unhandledrejectionとグローバルハンドラ
ErrorBoundaryの網から漏れるエラーは、windowのグローバルハンドラで受け止めます。
// 同期エラー（イベントハンドラ内含む）
window.addEventListener("error", (event) => {
reportError(event.error);
});
// awaitし忘れたPromise、catchのないPromiseの失敗
window.addEventListener("unhandledrejection", (event) => {
reportError(event.reason);
});特に unhandledrejection は重要です。fetchの失敗やawait漏れなど、非同期処理の例外は現代のフロントエンドで最も多いエラー経路ですが、catchされなければコンソールに出るだけで誰にも気づかれません。SentryなどのSDKはこれらのハンドラを自動で登録しますが、「何が自動で捕捉され、何が漏れるのか」を理解しておくと障害調査で迷いません。
エラー収集ツール導入時の設計ポイント
SentryやDatadog RUMなどの収集ツールは「入れて終わり」ではなく、導入時の設計が運用品質を決めます。最低限、次の点を決めておきます。
- リリースバージョンの付与: どのデプロイで発生したエラーかを紐付ける。「このリリースから増えた」が判断できることが最重要です
- ソースマップのアップロード: minifyされたスタックトレースは読めません。CIでソースマップを収集ツールに送る一方、公開サーバーには置かない構成にします
- 環境の分離: production / staging / development をタグで区別し、アラートはproductionのみに絞る
- コンテキストの付与: ユーザーID（個人情報は避ける）、画面名、直前の操作（breadcrumbs）を添付する
- 個人情報のマスキング: URLやフォーム値に含まれるメールアドレス等を送信前に除去する
ノイズ対策｜アラートを「見るもの」に保つ
フロントエンドのエラー収集は、放っておくとノイズの山になります。ブラウザ拡張機能が注入したスクリプトのエラー、古いブラウザの互換性エラー、クローラーのアクセス、ネットワーク切断による通信失敗──これらが大量に流れ込み、本当に対処すべきエラーが埋もれます。「アラートが多すぎて誰も見なくなる」のが監視の一番の失敗パターンです。
- 拡張機能由来のスタック（chrome-extension:// など）やサードパーティスクリプト起点のエラーをフィルタリングする
- オフライン起因の通信エラーは、エラーではなく「再試行＋ユーザー通知」というUXの問題として扱う
- 既知で対処不能なエラー（特定ブラウザのバグ等）はignoreリストで明示的に抑制し、理由をコメントで残す
- アラート条件は「新規エラーの発生」と「発生件数の急増」に絞り、既知エラーの継続発生では鳴らさない
また、トラフィックの多いサイトではサンプリングレートを設定し、コストと情報量のバランスを取ります。エラーは全件、パフォーマンス計測は数%といった配分が一般的です。
まとめ
フロントエンドのエラーハンドリングは、ErrorBoundaryで画面の全滅を防ぎ、グローバルハンドラ（特にunhandledrejection）で非同期エラーを漏らさず捕捉し、収集ツールにリリース・環境・コンテキストを紐付けて送る、という3層で構成します。そして運用フェーズでは、ノイズを削ってアラートの信頼性を保つことが監視を機能させ続ける鍵です。「エラーが見える」状態を作って初めて、フロントエンドの品質改善は始まります。
