こんにちは！日々のパフォーマンスチューニングやエラー調査、本当にお疲れ様です。
「画面の読み込みがなんだか遅い……でも、どこがボトルネックになっているのか全然わからない」
「ローカルでは再現しないのに、本番環境の特定ユーザーの環境だけでAPIが重くなっている」
そんなエンジニアの終わらない悪夢を、一撃で解決してくれる魔法のツールをご存知でしょうか？
それが今回解説する、Sentryの「Performance Monitoring（パフォーマンス監視）」です。
「Sentryって、エラーログを集めるだけのツールじゃないの？」と思ったそこのあなた。もったいない！実はSentryの真骨頂は、エラーとその裏側で起きていた「パフォーマンスの遅延」を一本のタイムラインで結びつけて完全可視化する能力にあります。
これをマスターすれば、もう「なんとなくここが怪しいからインデックスを貼ってみよう」という勘に頼った開発とはお別れできます。さあ、一緒にモダンなオブザーバビリティの世界へ踏み出し、毎日の作業を劇的に楽にしましょう！
—
1. エラー監視だけじゃない！Sentryのパフォーマンス監視機能とは
多くの開発現場では、Sentryを「例外（Exception）キャッチャー」として導入しています。アプリがクラッシュしたとき、スタックトレースをSlackに飛ばしてくれる便利な奴、という認識ですね。
しかし、実際のプロダクト運用で本当に厄介なのは、「クラッシュはしないけれど、レスポンスに5秒かかる地獄のような重さ」です。ユーザーはローディング画面を見せ続けられ、静かに離脱していきます。エラーログには何も出ないため、開発者には検知できません。
ここでSentryのPerformance Monitoringが登場します。
Sentryは、アプリケーション内部の処理を「トランザクション」として切り出し、「どのAPIが」「どのデータベースクエリで」「何ミリ秒ブロックされたのか」をすべてミリ秒単位で計測・記録します。
エラーが起きたとき、「その直前にどの処理がどれだけ時間を食っていたか」がひと目でわかる。これが、Sentryのパフォーマンス監視を導入する最大のメリットです。
—
2. トレース（Traces）とトランザクションの概念解説
パフォーマンス監視の海原へ漕ぎ出す前に、Sentryが使っている独自の言葉（概念）を整理しておきましょう。ここを理解しておくだけで、ダッシュボードの見え方が180度変わります。
- トランザクション (Transaction):
ユーザーのアクション（例：ボタンクリック、ページ遷移、APIリクエストの受信）単位の「ひとまとまりの処理」を指します。例えば、「`GET /api/products` リクエストの処理全体」が1つのトランザクションです。
- スパン (Span):
トランザクションの中身をさらに細かく分割した「個別の作業工程」です。トランザクションという大きな箱の中に、データベースへのクエリ発行、外部APIの呼び出し、JSONのシリアライズといった「スパン」がタケノコのように並びます。
- トレース (Trace):
フロントエンドからバックエンド、さらにマイクロサービスへとリクエストが伝播していく一連の流れ全体（ツリー構造）を指します。分散トレーシングとも呼ばれる概念です。
イメージとしては、「トランザクションがオーケストラの演奏会で、スパンはその中で演奏される個々の楽器の音色」です。どこで音程が外れた（遅延した）のかが、タイムライン（ウォーターフォール表示）を見ると一目瞭然になります。
—
3. データベースクエリの遅延やAPIレスポンスの計測設定
百聞は一見に如かず。実際にNode.js（Express）とフロントエンドを想定した環境で、最も重要で精度高いセットアップを行ってみましょう。
今回は、Sentryのパフォーマンス監視のキモである「サンプリングレートの設定」と「トランザクションの計測（初期化）」をコードで実装します。
バックエンド（Node.js / Express）のセットアップ
まずはパッケージをインストールします。
npm install –save @sentry/node
次に、アプリケーションのエントリーポイント（一番最初）でSentryを初期化します。
// app.js
const Sentry = require(“@sentry/node”);
const express = require(“express”);
const app = express();
// 1. Sentryの初期化（必ずすべてのルーティングの前に記述）
Sentry.init({
dsn: “YOUR_SENTRY_DSN_HERE”,
// 非常に重要：パフォーマンス監視を有効化するためのサンプリングレート
// 本番環境では負荷を考慮して 0.1 (10%) や 0.2 (20%) に設定しますが、
// 動作確認や初期段階では 1.0 (100%) にしてもOKです。
tracesSampleRate: 1.0,
integrations: [
// Expressのルーティングやミドルウェアのパフォーマンスを自動計測する統合機能
new Sentry.Integrations.Http({ tracing: true }),
new ExpressIntegration(),
],
});
// 2. リクエストハンドラーを最初に配置
app.use(Sentry.Handlers.requestHandler());
// トレーシング用のトレーサーハンドラー
app.use(Sentry.Handlers.tracingHandler());
// テスト用のエンドポイント（わざとDBクエリっぽい遅延を入れる）
app.use(“/api/heavy-task”, async (req, res) => {
// トランザクションの中に手動で「カスタムスパン」を生やすことも可能
const transaction = Sentry.getCurrentHub().getScope().getTransaction();
const span = transaction ? transaction.startChild({ op: “db.query”, description: “SELECT FROM heavy_table” }) : undefined;
// 擬似的なDB遅延（800ミリ秒かかる重いクエリをシミュレート）
await new Promise((resolve) => setTimeout(resolve, 800));
if (span) {
span.finish(); // スパンの計測終了
}
res.json({ status: “success”, message: “Heavy task completed” });
});
// 3. エラーハンドラーは必ずルーティングの「後」に配置
app.use(Sentry.Handlers.errorHandler());
app.listen(3000, () => {
console.log(“Server is running on port 3000”);
});
動作確認（HelloWorld的テスト）
1. アプリを起動し、ブラウザや `curl` で `http://localhost:3000/api/heavy-task` にアクセスします。
2. Sentryのダッシュボードにログインし、「Performance」タブを開きます。
3. トランザクション一覧に `GET /api/heavy-task` が出現していることを確認してください。
4. その詳細をクリックすると、先ほどコード内で仕込んだ `db.query` スパンが「800msもの時間を食っている犯人」として、美しいウォーターフォール（滝グラフ）のタイムラインで視覚化されているはずです！
この瞬間、「あ、このクエリがアプリを重くしているんだな」と直感的に確信が持てるようになります。これがSentryのパフォーマンス監視の真髄です。
—
4. ダッシュボードを活用したWebVitalsの改善アプローチ
バックエンドの遅延だけでなく、Sentryはフロントエンド（ブラウザ）のパフォーマンス監視も強力にサポートしてくれます。特に現代のWeb開発で避けて通れないのが「Web Vitals（ウェブバイタル）」です。
- LCP (Largest Contentful Paint): 画面の主要なコンテンツが表示されるまでの時間（目安：2.5秒以内）
- FID / INP (First Input Delay / Interaction to Next Paint): ユーザーが操作してから反応するまでの遅延（目安：200ms以内）
- CLS (Cumulative Layout Shift): 意図しないレイアウトのガタつき（目安：0.1未満）
SentryのフロントエンドSDK（React, Vue, ブラウザ用JSなど）を導入し、`tracesSampleRate`を設定するだけで、これらの指標が自動的にSentryのダッシュボードに集約されます。
ダッシュボードを活用した改善の黄金ルーティン
1. 「Performance」>「Web Vitals」画面を開く
自社サイトのユーザーが、実際にどのLCPやINPを体験しているかの分布（Good / Needs Improvement / Poor）が一目でわかります。
2. 「Poor（要改善）」なトランザクションに絞り込む
例えば、特定のチェックアウトページ（`/checkout`）だけLCPが4秒を超えている、といった異常値を見つけます。
3. ユーザーセッションのトレースを覗き見る
該当するトランザクションをクリックすると、そのユーザーのブラウザ環境（iOSなのか、古いAndroidなのか、回線速度は遅いか）とセットで、どの画像やJavaScriptの読み込みがボトルネックになっていたかが分かります。
「感覚」で語られていたフロントエンドの重さが、「数値」と「タイムライン」という動かぬ証拠として突きつけられるため、チームでの優先順位づけ（チケット起票）が劇的にスムーズになります。
—
おわりに
いかがでしたでしょうか？
SentryのPerformance Monitoringは、単なる「高級なログ置き場」から、「アプリケーションの健康状態を全方位でレントゲン写真のように映し出すオブザーバビリティ・プラットフォーム」へとあなたを引き上げてくれる最強の相棒です。
エラーが出てから慌てて対応する「リアクティブな開発」から、ボトルネックを事前に見つけて先手を打つ「プロアクティブな開発」へ。
今日からあなたのプロジェクトにも `tracesSampleRate: 0.1`（あるいは最初は思い切って `1.0`）を設定し、アプリの内部で何が起きているのかを覗き見してみてください。その瞬間から、毎日のコードレビューやパフォーマンスチューニングが、驚くほど楽しく、クリアなものに変わるはずですよ！