Sentry「BeforeSend」完全制覇：ノイズを制し、シグナルを研ぎ澄ますオブザーバビリティの神髄
Sentryを導入している多くの現場で、ダッシュボードが「ゴミ」で埋め尽くされている光景をよく見る。ブラウザ拡張機能が吐き出す意味不明なエラー、ユーザーのネットワーク環境に依存した一時的な切断、そして何より「プライバシー侵害リスクのある機密情報」の混入。
これらを放置することは、「アラート疲れ」という名の慢性的なエンジニアの疲弊を招き、本当に追うべき重大な障害を見逃す原因となる。
今日は、Sentryの心臓部である`beforeSend`フックを使いこなし、ノイズを排除して「本物のシグナル」だけを抽出する、プロの作法を伝授する。
—
1. BeforeSend：イベントを「送信前」にフィルタリングする最強の門番
`beforeSend`は、Sentryがサーバーへペイロードを送信する直前に、イベントオブジェクトを操作または破棄できるコールバック関数だ。ここで「送信するか、しないか」を判断する。
実践的なフィルタリング実装（TypeScript）
以下のコードは、拡張機能由来のゴミを除去し、機密データを確実にマスクする実戦仕様の構成だ。
import as Sentry from “@sentry/browser”;
import { Event } from “@sentry/types”;
Sentry.init({
dsn: “YOUR_DSN”,
beforeSend(event: Event, hint: any) {
// 1. ノイズの除去: ブラウザ拡張機能起因のエラーは無視する
const errorMessage = event.exception?.values?.[0]?.value || “”;
const ignoredErrors = [
“ResizeObserver loop limit exceeded”, // UIライブラリの定番ノイズ
“Extension context invalidated”, // Chrome拡張機能
“Failed to fetch” // 一時的なネットワーク断
];
if (ignoredErrors.some(msg => errorMessage.includes(msg))) {
return null; // nullを返すと送信自体が破棄される
}
// 2. 機密情報のマスキング（PII: 個人特定可能情報の保護）
// リクエストのURLからトークンやメールアドレスを除去するロジック
if (event.request?.url) {
event.request.url = event.request.url.replace(/token=[^&]+/, “token=MASKED”);
}
// 3. ユーザー情報のサニタイズ
if (event.user) {
delete event.user.email; // メールアドレスはSentryに送らない（GDPR対策）
event.user.id = “ANONYMIZED_ID”; // IDもハッシュ化を推奨
}
return event; // 修正されたイベントを送信
},
});
—
2. 開発効率を爆速にする「Sentry × IDE」の神連携
SentryをWebブラウザだけで見ているなら、それはまだ「素人」の域だ。プロはIDEと直結させている。
VS Code神プラグイン: `Sentry for VS Code`
このプラグインは、Sentryに記録されたエラーをIDE上に直接マッピングする。エディタを開いた瞬間に、自分の書いたコードのどの行がSentryでエラーになっているか、エラー数と共にインライン表示される。
- メリット: コンテキストスイッチ（ブラウザとエディタの往復）がゼロになる。
- 設定の肝: `sentry.properties` をプロジェクトルートに置き、組織とプロジェクトを確実に紐付けること。
隠れたキーボードショートカット
- `Cmd + K` (Sentry画面): 検索窓の即時フォーカス。
- `J` / `K`: イベント詳細画面で、前後のエラーへ瞬時に遷移。
- `Space`: Issueの解決済み/未解決のトグル。
—
3. チーム開発で失敗しない「設定共有」のベストプラクティス
属人化を防ぎ、新人が入った瞬間に「守りの堅いSentry」を使わせるための構成案だ。
`sentry-config.ts` での責務分割
SDKの設定をべた書きせず、設定ファイルとして切り出すのがプロの流儀だ。
// sentry-config.json (プロジェクトで共有)
{
“ignoreErrors”: [
“TypeError: Cannot read property ‘xxx’ of undefined”,
“/refused to connect/i”
],
“denyUrls”: [
“graph.facebook.com”,
“extensions:///”
]
}
チーム開発のルール:
1. Ignoreリストは一元管理: 個人のローカル環境で無視設定をせず、設定ファイルをプロジェクトに含める。
2. Breadcrumbsの制限: ログを吐きすぎない。`maxBreadcrumbs: 30` 程度に絞り、重要度の低いログは送信しない。
3. 環境変数の活用: `SENTRY_ENVIRONMENT`を必ず付与し、ローカル開発・ステージング・本番を厳格に分けること。
—
4. プロのテックリードからの提言
オブザーバビリティとは、単に「エラーを記録すること」ではない。「ノイズという名の曇りガラスを取り除き、システムの真実を見通すこと」である。
多くのチームが「Sentryのエラーメールが多すぎて読まなくなった」という末期症状に陥る。その時、あなたがまずやるべきは、コードの修正ではなく、`beforeSend`による「情報の選別」だ。
今すぐ実践せよ。
1. Sentryの「Issue一覧」を開き、上位3つのノイズを特定しろ。
2. `beforeSend`でそれらを破棄しろ。
3. 残ったエラーこそが、あなたが解決すべき、ユーザーの体験を損なう「真のバグ」だ。
それができれば、あなたのチームは「エラーを追うチーム」から「エラーを未然に防ぐチーム」へと進化できるはずだ。健闘を祈る。