こんにちは！フロントエンドの開発、日々楽しくも泥臭く進めていることと思います。

ReactやNext.jsでモダンなWebアプリケーションを作っていると、ローカル環境では完璧に動いていたのに、いざ本番（プロダクション）にデプロイした瞬間に、ユーザーの環境でだけ謎の白い画面（エラー画面）が出現する……という、冷や汗が背筋を伝うような経験はありませんか？

「ブラウザのコンソールを開いてくれませんか？」とユーザーにお願いするわけにもいかない。そんな現代のフロントエンド開発における「視界不良」を鮮やかに解決してくれるのが、今回解説するSentry（セントリー）です。

今回は、Next.js開発者に向けて、Sentryを用いたエラー監視の極意を基礎から優しく、かつ現場で本当に役立つノウハウを交えて解説していきます。これをマスターすれば、ユーザーからの「なんか動かないんですけど」という問い合わせに怯える日々から解放されますよ。

—

1. なぜフロントエンドに「エラー監視」が必要なのか？

まず、大前提のお話です。
「エラーなんて、開発中のテストやVercelなどのログを見れば十分でしょ？」と思っていませんか？ ここに、モダンWeb開発の大きな罠があります。

Next.jsは、サーバーサイド（SSR/RSC）とクライアントサイド（ブラウザ）の両方でコードが実行されるハイブリッドなフレームワークです。つまり、エラーが起きる場所が2箇所あるということ。

1. サーバーサイドのエラー: VercelやAWSのログを見れば追えます。
2. クライアントサイドのエラー: ユーザーのブラウザ（iPhoneのSafari、古めのChromeなど）で起きています。

特に厄介なのは2つ目のクライアントサイドです。ユーザーのデバイス環境、拡張機能の干渉、ネットワークの瞬断など、開発者の手元では100%再現しないエラーが日常茶飯事に起きています。

Sentryは、この「ユーザーのブラウザで起きたエラー」を、発生した瞬間にキャッチし、「どのユーザーが、どの画面で、どんな操作をした結果、どのコード（何行目）で壊れたのか」をタイムライン形式で手にとるように教えてくれる、いわばフロントエンド専用のフライトレコーダーです。

—

2. `@sentry/nextjs` のインストールと初期設定

百聞は一見に如かず。実際にNext.jsプロジェクトにSentryを導入していきましょう。
Sentry公式は、Next.js専用の超優秀なCLIウィザードを用意してくれています。これを使わない手はありません。

ステップ1: ウィザードの実行

あなたのNext.jsプロジェクトのルートディレクトリで、以下のコマンドを叩いてください。

npx @sentry/wizard@latest -i nextjs

コマンドを実行すると、ターミナル上で対話形式のセットアップが始まります。
1. Sentryへのログイン（ブラウザが立ち上がります）
2. 連携するプロジェクトの選択
3. 設定ファイルの自動生成

これらがすべて自動で行われます。魔法のようですね。

ステップ2: 生成されたファイルたちを確認する

ウィザードが無事に終わると、プロジェクトのルートにいくつかのファイルが生成（または更新）されます。

• `sentry.client.config.ts`: ブラウザ側（クライアントサイド）のSentry設定
• `sentry.server.config.ts`: Node.js側（サーバーサイド）のSentry設定
• `sentry.edge.config.ts`: Edgeランタイム側のSentry設定
• `next.config.js`: ソースマップ等を出力するためのSentryプラグイン設定

ここで、クライアント側の設定ファイル `sentry.client.config.ts` を覗いてみましょう。

// sentry.client.config.ts
import as Sentry from “@sentry/nextjs”;

Sentry.init({
// Sentryダッシュボードから発行された固有のDSN（宛先住所のようなもの）
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,

// パフォーマンスモニタリング用のサンプリングレート（本番では 0.1 = 10% などを推奨）
tracesSampleRate: 1.0,

// ユーザーのセッションリプレイを記録するか（エラー発生時の画面録画機能！神機能です）
replaysSessionSampleRate: 0.1,
replaysOnErrorSampleRate: 1.0, // エラーが起きた時は100%の確率で録画する

integrations: [
new Sentry.Replay({
// プライバシー保護のため、パスワードや入力値をマスクする設定
maskAllText: true,
blockAllMedia: true,
}),
],
});

> 💡 先輩からのワンポイントアドバイス
> `replaysOnErrorSampleRate: 1.0` は絶対に設定しておいてください。エラーが起きた瞬間の「ユーザーの操作画面の録画」がSentry上に残るため、デバッグ効率が文字通り10倍になります。

—

3. クライアントサイドとサーバーサイドのエラー捕捉テスト

セットアップが終わったら、正しくエラーがSentryに飛ぶか（HelloWorld的な動作確認）をテストしましょう。

適当なボタンを配置したReactコンポーネント（例: `app/page.tsx`）を作り、意図的にエラーを発生させてみます。

// app/page.tsx
‘use client’;

import as Sentry from “@sentry/nextjs”;

export default function Home() {
const handleClientError = () => {
// 意図的に未定義のメソッドを呼んでエラーを起こす
throw new Error(“フロントエンドでテストエラーが発生しました！”);
};

const handleCapturedError = () => {
try {
// 例外をキャッチしつつ、Sentryに手動で送信するパターン
throw new Error(“手動でキャッチしたエラーです”);
} catch (error) {
Sentry.captureException(error);
}
};

return (

これをブラウザで動かし、ボタンをポチッと押してみてください。
数秒後、Sentryのダッシュボード（Issuesタブ）を確認すると……見事にエラーがキャッチされているはずです！

サーバーサイド（APIルートやServer Components）でも同様に、`throw new Error()` を書くだけでシームレスにSentryへ集約されます。クライアントとサーバーのエラーが1つのダッシュボードにまとまる快感を、ぜひ味わってください。

—

4. ソースマップ（Source Map）のアップロード設定と注意点

さて、ここからが実務で絶対に避けて通れない最も重要な知見です。

Next.jsの本番環境（Production）では、コードは難読化（Minify）され、変数名やファイル名が `t.e(…)` のような暗号に変換されてビルドされます。
この状態でSentryにエラーが届くと、ダッシュボード上のスタックトレース（エラーの発生箇所）も以下のように表示されてしまいます。

❌ 意味不明な表示例:
`at t.e (main.min.js:formatted:123:45)`

これでは「どこを直せばいいのか」分かりませんよね。ここで登場するのがソースマップ（Source Map）です。ソースマップとは、難読化された本番コードと、あなたが書いた元のソースコードを繋ぐ「翻訳の対応表」です。

自動アップロードの仕組み

SentryのNext.jsプラグインを導入していれば、ビルド時（`next build`）に自動的にソースマップが生成され、Sentryのクラウドへ安全にアップロードされます。

しかし、ここで絶対に注意すべき落とし穴があります。

> ⚠️ 致命的な注意点: ソースマップをパブリックに公開してはいけない
> ビルド成果物の中にソースマップ（`.map`ファイル）が含まれたままVercel等にデプロイされてしまうと、誰でもブラウザの検証ツールから「あなたの元のソースコード（コメントや機密ロジックを含む）」を丸見えの状態でダウンロードできてしまいます。セキュリティ事故の元です。

堅牢なソースマップ運用のベストプラクティス

Next.jsでのビルド設定（`next.config.js`）およびSentryの設定を確認し、以下の状態を作ることがプロの鉄則です。

1. ビルド時にソースマップを生成する（Sentryプラグインが裏側で行います）。
2. 生成されたソースマップをSentryのサーバーへアップロードする。
3. アップロードが成功したら、本番環境のビルドフォルダからソースマップファイルを削除する（または一般ユーザーからアクセスできないようにする）。

SentryのNext.js用ウィザードが生成した `next.config.js` は、デフォルトでこの安全な処理をうまくやってくれます。

// next.config.js のイメージ
const { withSentryConfig } = require(“@sentry/nextjs”);

const nextConfig = {
// あなたの通常のNext.js設定
};

module.exports = withSentryConfig(
nextConfig,
{
// Sentryの組織名やプロジェクト名などの設定
silent: true, // ビルド時のログを静かにする
org: “your-org”,
project: “your-project”,
},
{
// ソースマップを隠し、Sentryへ安全にアップロードするためのオプション
widenClientFileUpload: true,
hideSourceMaps: true, // ★これが超重要！本番のブラウザからソースマップを隠す
tunnelRoute: “/monitoring”, // AdBlocker等によるSentryブロックを防ぐ裏技ルート
}
);

特に `hideSourceMaps: true` は、エンドユーザーのブラウザに対してソースマップを非公開にしつつ、Sentry上では元の美しいソースコードでエラーを表示させるための魔法のオプションです。必ず有効になっていることを確認してください。

—

おわりに：監視とは「安心」を買うこと

お疲れ様でした！これでNext.js/ReactアプリケーションにおけるSentryの導入と、実務で絶対に押さえておくべきソースマップの設定まで完了です。

エラー監視ツールを入れると、「エラーが起きないか」とビクビクしながらデプロイする必要がなくなります。万が一バグが混入しても、ユーザーが気づくより早くSentryが通知してくれ、ソースマップのおかげで秒速で修正箇所を特定できるからです。

これをマスターすれば、毎日の開発・運用作業が劇的に楽になりますよ。
あなたのプロダクトの「オブザーバビリティ（可観測性）」の第一歩として、ぜひ今日からプロジェクトに組み込んでみてください。快適なフロントエンドライフを！