Sentryは「エラー通知ツール」ではない。ビジネスを加速させる「インサイトエンジン」だ
多くのエンジニアがSentryを「エラーが飛んできたらSlackを見る場所」と勘違いしている。それはSentryのポテンシャルの1%も引き出せていない。
Sentryの真髄は、その裏側に潜むSnubaという分散型クエリエンジンと、それを直接叩けるDiscover 2にある。ここを使いこなせば、「なぜこの機能でエラーが起きるのか」という問いに対し、カンではなくデータで、しかも秒速で答えを出せるようになる。
今日は、Sentryを単なるログの墓場から、開発の意思決定を支えるインテリジェンスへと昇華させるための極限のテクニックを伝授する。
—
1. Snubaの魔力を引き出す：Discover 2のカスタムクエリ術
SentryのUIにはない「自分たちだけのKPI」を抽出するには、Discoverのクエリ構文をマスターする必要がある。
頻出する「使える」クエリ構文
Discoverで検索する際、ただ単に `is:unresolved` を打つのは卒業だ。以下の構文を組み合わせることで、ビジネスセグメントに応じたエラー分析が可能になる。
- 特定機能の健全性チェック:
`transaction:”/api/v1/checkout/” event.type:error`
（決済フローでのエラーのみを抽出。これで「決済のどのステップで落ちたか」が可視化される）
- 影響力の大きいユーザーの特定:
`error.handled:false user.email:@premium-corp.com`
（重要顧客の環境で発生した未ハンドリングエラーのみをフィルタリング。CS対応の優先度を自動化できる）
- リリースごとの品質比較:
`release:2.4.0` vs `release:2.3.9`
（タグによる比較は基本中の基本だが、これをダッシュボードに固定することで、リリース直後の「違和感」を即座に検知する）
—
2. 開発スピードを劇的に上げるキーボードショートカット
Sentry画面でマウスを動かしている暇はない。以下のショートカットを指に覚え込ませろ。
- `g` → `d`: Discoverへ即時移動。
- `g` → `i`: Issues一覧へ即時移動。
- `Cmd/Ctrl + Enter`: クエリの実行。
- `?`: 全ショートカットリストを表示。
特に、Discover画面でフィルタをいじりながら `Cmd + Enter` を連打するフローは、障害調査時のルーチンとして体に叩き込むこと。
—
3. チームで共有すべき「設定ファイル」ベストプラクティス
個人の設定で終わらせるな。`sentry.client.config` や SDK の初期化設定を共通化し、チーム全体で「質の高いメトリクス」を吸い上げろ。
以下は、TypeScriptでの推奨設定例だ。
import as Sentry from “@sentry/react”;
Sentry.init({
dsn: “YOUR_DSN”,
// 1. ノイズを殺す: 予期せぬブラウザ拡張機能のエラーを除外
denyUrls: [/extensions\//i, /^chrome:\/\//i],
// 2. 重要なビジネスメトリクスをタグとして付与
beforeSend(event) {
// ユーザーのプラン情報をタグに付与し、Discoverでセグメント分析できるようにする
event.tags = {
…event.tags,
plan: window.user.planType,
tier: window.user.tier
};
return event;
},
// 3. パフォーマンスとエラーを紐付ける
tracesSampleRate: 0.1, // トラフィックに合わせて調整せよ
});
—
4. 絶対に入れるべき「神プラグイン/連携」
Sentry単体で完結させるな。以下の連携こそが、現場で震えるほど役に立つ。
1. GitHub / GitLab Integration:
`Code Owner` と連携させ、エラーが発生したファイルに対して、担当エンジニアを自動でIssueにアサインせよ。
2. Jira / Linear Integration:
「Create Issue」ボタンからチケットを切る際、スタックトレースとログが自動添付されるように設定せよ。これだけでチケット作成コストが5分から10秒に短縮される。
—
5. 運用を自動化する「Dashboard」の構成戦略
ダッシュボードは「眺めるもの」ではなく「アクションを生むもの」であるべきだ。以下の3つを必ず作成し、チームの入り口にせよ。
- 「今、燃えている場所」ダッシュボード:
`event.type:error` かつ `timestamp:>now-1h` で、Issueの発生数が多い順に並べる。これが朝一番のチェックリストだ。
- 「ビジネス影響度」ダッシュボード:
特定の重要な取引APIの成功/失敗率を `transaction` メトリクスで可視化。エラー数ではなく「失敗率」でアラートを飛ばす。
- 「CS対応用」ダッシュボード:
顧客からの問い合わせID（`user.id`）を入力して、そのユーザーの直近の全エラー履歴を即座に表示できるようにする。
—
最後に：エンジニアへの提言
Sentryを使いこなすということは、「何が起きているか分からない」という状態を撲滅するということだ。
エラーをただのデバッグ対象とするな。Discover 2でクエリを投げ、Snubaが吐き出すデータから、ユーザーがどこで迷い、どこでシステムが悲鳴を上げているのかを見極めろ。
それが、凡庸なエンジニアと、ビジネスを動かすアーキテクトの決定的な違いだ。さあ、今すぐコンソールを開き、最初のカスタムクエリを叩け。