Next.js の Server Component でエラー詳細が出ない時の原因と対処（Rails バックエンド連携）

現象

本番環境の Next.js（App Router + Server Components）では、レンダー時のエラー詳細が省略されます。例えば、次のようなメッセージだけが表示されます：

これは設計上の挙動で、機密情報の漏えいを防ぐためです。そのため原因特定には工夫が必要です。

前提

以下は、Next.js フロントエンド + Rails バックエンド構成で役立った対処法とよくある原因です。

1. どうやって原因を特定する？

• Sentry などのエラートラッキングを導入する（Next.js のサーバー側・クライアント側、Rails 側の両方）
• Sentry の Issue で「URL（クエリを含む）」を記録するようにする
• 記録された URL からルーティングとデータ取得箇所（fetch/API 呼び出し）を辿り、ソース位置を絞り込む
• デプロイ先（例：Vercel）のログと Sentry のスタックトレースを併用する

2. よくある原因

• バックエンド API が Not Found (404) を返し、フロント側が区別せずにそのままエラーを投げてしまう
• Server Component が「データ欠如」まで例外として扱っている（null/undefined の想定不足）

3. 何をすべきか（フロント側）

• 404 や空データは例外にせず、「Not Found UI」を明示的に表示する分岐を作る
• fetch のレスポンスコードを必ず確認し、非 2xx の時は安全にフォールバックする
• SSR 必須データには防御的コーディング（null チェック）を入れて、UI を優雅に劣化させる
• エラーバウンダリは「本当の例外」にだけ使い、業務的な「未検出」「空」状態は通常分岐にする

4. 何をすべきか（Rails 側）

• 404、422、500 など意味のあるステータスを返す（何でも 500 にしない）
• エラーレスポンスは簡潔かつ機械可読（コード・メッセージ）にして、フロントエンド側で判定しやすくする
• Sentry にコンテキスト（リクエストパス、重要なパラメータなど）を付与する

5. まとめ

• 本番の Server Components がエラー詳細を隠すのは正常挙動
• 追跡には Sentry と URL ログが有効。スタックトレースとデプロイログで突き合わせる
• 「Not Found（404）」など業務的状態は UI 分岐で処理し、例外と混同しない

この方針にしてから、原因特定が速くなり、ユーザーに安全な表示を維持できました。