【入門編】Sentryで「Uncaught Exception」を捕捉できないときの原因と解決策チェックリスト – 運用監視・オブザーバビリティ活用バイブル

こんにちは!オブザーバビリティの世界へようこそ。
新しいプロジェクトを立ち上げ、Sentryを導入して「これで夜中に怯えなくて済むぞ!」と意気込んだものの、いざテストエラーを起こしてみたら……あれ、Sentryのダッシュボードが真っ白なまま。

……この絶望的な瞬間、エンジニアなら誰もが一度は通る道です。

今回は、Sentryで「Uncaught Exception(捕捉されない例外)」がなぜか届かないときの原因と解決策を、現場の知見をたっぷり詰め込んでチェックリスト形式でお届けします。これをマスターすれば、エラー迷子になることはもうありません。一緒にひとつずつ原因を潰していきましょう!

—

1. 導入したのにエラーがSentryに届かない代表的な原因

Sentryは魔法の道具ではありません。アプリケーションのライフサイクルやネットワークの機微を正しく理解していないと、エラーは簡単に闇に葬られます。

まず大前提として、Sentryがエラーを捕捉するメカニズムをイメージしてください。アプリケーションがクラッシュする瞬間、SentryのSDKがそれを横取りしてサーバーへ送信しています。
したがって、「Sentryが初期化される前に起きたエラー」や「Sentryの送信がブロックされた場合」は、永遠にSentryに届きません。

ここから、現場でよくある4つの「届かない原因」を、具体的な対策とともに見ていきましょう。

—

2. CORS制限やネットワークブロック(AdBlock等)への対策

ブラウザ側の環境で最も多いのがこれです。
「ローカルでは動くのに、本番環境(特にユーザーのブラウザ)でエラーが取れない」という場合、大半の犯人は AdBlock(広告ブロッカー)やプライバシー保護機能 です。

ブラウザの拡張機能は、`sentry.io` というドメインや、いかにもエラー収集しそうなスクリプトの名前を容赦なくブロックします。

解決策:プロキシ(トンネリング)を設定する

ユーザーのAdBlockに邪魔されない最強の防衛策は、自社ドメインを経由してSentryにデータを送る(リバースプロキシ)ことです。

例えば、Next.jsやNginxを使って、自社の `/monitoring/…` 宛ての通信をSentryのサーバーに転送するようにルーティングします。これにより、ブロッカーからは「自社サーバーへの普通の通信」に見えるため、ブロックされなくなります。

—

3. 初期化コード(`Sentry.init`)の実行順序の確認

初心者が最もやりがちなミスが、初期化の「タイミング」と「順番」のミスです。

Sentryは、読み込まれた瞬間から監視を始めます。つまり、アプリケーションのどのコードよりも先(エントリーポイントの最上部)で `Sentry.init()` を呼び出さなければなりません。

正しい初期化の作法(TypeScript / JavaScriptの例)

// ⚠️ 厳守:他のどのモジュールをインポートするよりも、一番上に書くこと!
import as Sentry from “@sentry/react”;

Sentry.init({
dsn: “https://examplePublicKey@o0.ingest.sentry.io/0”,
// パフォーマンスモニタリングのサンプルレート(本番では0.1〜0.2推奨)
tracesSampleRate: 1.0,

// デバッグモードを一時的に有効化して挙動を監視する
debug: true,
});

// ここから下に、通常のアプリケーションのコードやルーティングを記述する
import React from ‘react’;
import ReactDOM from ‘react-dom/client’;
import App from ‘./App’;

ReactDOM.createRoot(document.getElementById(‘root’)!).render();

もし `import App from ‘./App’` の中でエラーが起き、そのファイル内でSentryより先に別の重い処理やインポートエラーが発生した場合、Sentryはまだ目を覚ましていません。初期化は常に「一番乗り」が鉄則です。

—

4. デバッグモードを有効にしてコンソールログを解析する方法

「何が起きているのか分からない」ときは、Sentryに語らせましょう。
Sentryの初期化設定に `debug: true` を仕込むと、ブラウザのコンソール(またはNode.jsの標準出力)に、Sentryの内部ログがこれでもかと出力されるようになります。

Sentry.init({
dsn: “YOUR_DSN”,
debug: true, // ← ここを true にする
});

これを有効にしてページをリロードし、開発者ツールの「Console」タブを見てみてください。次のようなログが流れるはずです:

  • `Sentry Logger [log]: Intializing SDK…` (初期化成功)
  • `Sentry Logger [log]: Sending event [Event ID] to Sentry…` (送信中)
  • もしここで赤字で `CORS error` や `Failed to fetch` が出ていたら、ネットワークやブロックが原因です。

動作確認(HelloWorld)用のテストボタンを作ろう

正しく設定できているかを確かめるために、あえて例外を発生させるボタンを一時的に置いてみましょう。

function TestSentryButton() {
return (

);
}

このボタンを押した瞬間、コンソールにSentryの送信ログが走り、数秒後にSentryのダッシュボードにエラーがドカンと着弾すれば成功です。

—

まとめ:これをマスターすれば、毎日の作業が劇的に楽になりますよ

Sentryでエラーが取れないときのチェックリスト、いかがでしたか?

1. 初期化は誰よりも早く行われているか? (`Sentry.init` の位置)
2. AdBlockやCORSに通信を握りつぶされていないか?
3. `debug: true` を使ってコンソールの叫び声を聞いたか?

この3つを上から順に確認するだけで、世の中の大半のエラー未検知問題は解決します。
オブザーバビリティの基本は「見えないものを可視化する」こと。まずは自分の手でエラーを意図通りにSentryへ送り届け、ダッシュボードに通知がピコンと光る快感を味わってみてください。

あなたの開発ライフが、より安心で快適なものになりますように!

タイトルとURLをコピーしました