フロントエンドの「闇」を可視化せよ：Sentry × Next.js で実現する、妥協なきエラー監視の極意
「ユーザーの画面で何が起きているのか分からない」。この恐怖に震える日々は今日で終わりにしよう。
コンソールログを眺め、ユーザーからの「なんか動かないんですけど」という曖昧な報告を待つのは、もはやプロの仕事ではない。フロントエンド監視の目的は、単なるバグ報告ではない。「ユーザーが体験している崩壊を、開発者が先回りして検知し、修正する」という、信頼性を担保するためのエンジニアリングだ。
今回は、Next.js開発においてデファクトスタンダードであるSentryを、単に「入れる」レベルから「使いこなす」レベルへと引き上げるための実践知を伝授する。
—
1. なぜフロントエンドで「本気」のエラー監視が必要なのか？
サーバーサイドのエラーはログに残るが、フロントエンドは「ユーザーのブラウザというブラックボックス」で実行される。
- 環境の断片化: Chrome, Safari, Firefox、そして無数のブラウザ拡張機能がJSを汚染する。
- 非同期の迷宮: Reactのレンダリングループや非同期処理で発生するエラーは、スタックトレースが断片化しやすく、原因特定が困難。
- 信頼の崩壊: ユーザーはエラーが出た瞬間に離脱する。無言の離脱を減らす唯一の手段が「エラーの即時検知」だ。
—
2. `@sentry/nextjs` の真の実装戦略
単なる `sentry-wizard` の実行で満足してはいけない。本番環境で真価を発揮させるための構成を解説する。
インストールと初期設定のベストプラクティス
まず、`sentry.config.js` を分割し、環境変数による機密保護を徹底する。
// sentry.client.config.js
import as Sentry from “@sentry/nextjs”;
Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
// 重要な知見: 100%サンプリングはコストが膨大になる。
// 本番環境では 0.1 ～ 1.0 程度に抑え、必要なエラーを確実に拾う。
tracesSampleRate: 0.1,
// クライアントサイドでのパフォーマンス監視を最適化
replaysSessionSampleRate: 0.1,
replaysOnErrorSampleRate: 1.0, // エラー発生時は必ず録画して再現性を高める
});
【神テクニック】
Sentryの管理画面で、「Issue Alert」をSlackの特定チャンネルに流す際、必ず「Alert Rule」を環境ごとに分離せよ。 開発環境のエラーでSlackが埋まるのは生産性の低下だ。
—
3. ソースマップ：エンジニアの「命綱」
Sentryにソースマップをアップロードしていないなら、それは「目隠しをしてデバッグしている」のと同じだ。`next.config.js` での自動アップロード設定が必須となる。
// next.config.js
const { withSentryConfig } = require(“@sentry/nextjs”);
const moduleExports = {
// 本番ビルド時にソースマップを生成する設定
productionBrowserSourceMaps: true,
};
const sentryWebpackPluginOptions = {
silent: true, // ビルドログを汚さない
org: “your-org”,
project: “your-project”,
// 致命的な注意点: ソースマップを公開サーバーに置くな。
// Sentryにのみアップロードし、ビルド後は削除するフローをCIに組み込むこと。
};
module.exports = withSentryConfig(moduleExports, sentryWebpackPluginOptions);
—
4. 現場で震えるほど役立つ「生産性向上テクニック」
① 開発スピードを上げるキーボードショートカット
SentryのIssueページを開いているとき、`j` / `k` で前後のIssueへ移動し、`o` でIssueを開く。マウスに手を伸ばす時間を削れ。これが「Sentryを日常的に使っている」エンジニアの作法だ。
② 絶対入れるべき神プラグイン：`Sentry Breadcrumbs`
Sentryは単なるエラー捕捉ツールではない。エラー発生直前の「ユーザーの操作（クリック、ネットワークリクエスト、URL遷移）」をBreadcrumb（パンくずリスト）として残す。これがないと、どんなに優れたスタックトレースもただのテキストだ。
③ チーム共有の設定ルール：`sentry.ignoreErrors`
すべてのエラーが修正対象ではない。`ResizeObserver loop limit exceeded` のようなブラウザ固有の無害なエラーは、`ignoreErrors` 設定でノイズから除外せよ。ノイズを排除し、「直すべきエラー」だけを可視化するのがテックリードの仕事だ。
// チーム全員で共有すべき ignoreErrors 設定例
ignoreErrors: [
“ResizeObserver loop limit exceeded”,
“Script error”, // CDNの制限などで詳細が取れないエラーは除外
“TypeError: Cannot read properties of null (reading ‘addEventListener’)”
],
—
最後に：オブザーバビリティは「文化」である
Sentryは魔法の杖ではない。導入しただけでバグが消えるわけではない。しかし、「何が起きているかを知っている」という事実は、チームの心理的安全性を極限まで高める。
障害が起きたとき、ログを漁るのではなく、SentryのReplayを見て「ユーザーがここで詰まったのか」と即座に理解できるチームを目指してほしい。
次は、あなたがこの知見をコードに落とし込み、チームを次のステージへ導く番だ。健闘を祈る。