Sentry と Bugsnag｜フロント・API のエラー監視ツール比較

モダンな Web アプリケーション開発において、ユーザーのブラウザ上で発生する JavaScript エラーや、マイクロサービス化した API のサイレントな失敗を「ユーザーからの問い合わせ」で知る時代は終わりました。エラー監視ツール（Error Tracking / Error Monitoring）の導入は、今や非機能要件の最優先事項です。

本記事では、この分野の二大巨頭である Sentry と Bugsnag について、IT 実務者の視点から徹底的に比較します。単なる機能紹介にとどまらず、実際の運用で直面するコストの問題、セキュリティ設定、ソースマップ連携の手順まで詳しく解説します。

Sentry と Bugsnag の基本特性

両ツールとも「発生したエラーをキャッチし、スタックトレースや発生時のコンテキストを集約して開発者に通知する」という基本機能は共通していますが、プロダクトとしての思想が大きく異なります。

Sentry とは：オブザーバビリティの統合プラットフォーム

Sentry（公式ウェブサイト）は、エラー監視の枠を超え、アプリケーション全体のパフォーマンス（Application Performance Monitoring: APM）や、ユーザーがエラーに至るまでの操作を動画のように再生できる「Session Replay」など、広範な可観測性（Observability）を提供するツールです。

オープンソース版も公開されており、オンプレミスでの構築（セルフホスト）が可能な点も大きな特徴です。対応言語が非常に広く、フロントエンドからバックエンド、モバイル、さらにはデスクトップアプリまで一貫して管理できます。

Bugsnag とは：安定性スコアに特化した専門ツール

Bugsnag（公式ウェブサイト）は、SmartBear 社が提供する「アプリケーションの安定性（Stability）」を可視化することに特化したツールです。最大の特徴は、エラー数ではなく「セッションに対するエラー発生率」から算出される「Stability Score」を重視している点です。

UI は非常に洗練されており、特にモバイルアプリ（iOS/Android）のエンジニアからの支持が厚い傾向にあります。「どのリリースバージョンから不安定になったか」を一目で把握できるため、リリースの Go/No-Go 判断に直結させやすいのが強みです。

【徹底比較】Sentry vs Bugsnag 5つの主要ポイント

実務で導入を検討する際に重要となる 5 つの観点で比較します。

1. エラー集約とデバッグ機能の深さ

Sentry は、エラーが発生した際の「パンくずリスト（Breadcrumbs）」が非常に詳細です。コンソールログ、HTTP リクエスト、DOM イベントなどが時系列で並び、エラー直前にユーザーが何をしたかが手に取るようにわかります。

Bugsnag も同様の機能を持ちますが、Bugsnag は「エラーのグループ化」の精度に定評があります。同じ原因のエラーが別々に報告される「ノイズ」が少なく、対応すべき課題を絞り込みやすい設計になっています。

2. パフォーマンスモニタリング（APM）の有無

ここで両者の差が顕著に出ます。Sentry はフル機能の APM を備えており、スロークエリの特定や LCP（Largest Contentful Paint）などの Web Core Vitals の計測が可能です。一方、Bugsnag はあくまで「エラーと安定性」にフォーカスしており、詳細なトランザクショントレース機能は Sentry に軍配が上がります。

例えば、広告計測データとシステムエラーを紐づけて分析するような高度なデータアーキテクチャを構築する場合、Sentry のような統合的なデータ保持能力が有利に働きます。
広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ
のような事例でも、フロントエンドの微細なエラー検知は機械学習モデルへの入力データの質に直結します。

3. 対応プラットフォームと SDK の柔軟性

両ツールとも JavaScript, React, Vue, Node.js, Python, Ruby, Go, Java, PHP, iOS, Android, Flutter など主要な環境をほぼ網羅しています。

• Sentry: SDK の設定オプションが非常に豊富で、柔軟なカスタマイズが可能。
• Bugsnag: SDK が軽量で設定がシンプル。導入の速さを優先するなら Bugsnag がスムーズ。

4. 導入コストとプランの構造

※料金は 2024 年現在の公式情報を基準としていますが、最新情報は必ず各社公式サイトを確認してください。

Sentry は「エラー（Event）数」に応じた従量課金に近い体系です。無料枠（Developer プラン）は月間 5,000 イベント程度で、それを超えると Business プランなどへ移行し、イベント量に応じてコストが増加します。

Bugsnag は「月間アクティブユーザー（MAU）」や「エラー発生数」に基づきますが、プランによっては「イベント数無制限」のエンタープライズ枠があり、大規模トラフィックがあるサービスでは Bugsnag のほうがコストを予測しやすい場合があります。

5. セッションリプレイと再現性の担保

Sentry の目玉機能である「Session Replay」は、エラー発生前後 30 秒程度のユーザーの画面操作を動画のように再現します。これにより、「特定のブラウザで、特定のボタンを 2 回連打したときだけ発生する」といった再現困難なバグの特定が劇的に速まります。Bugsnag もサードパーティ連携（LogRocket など）で対応可能ですが、Sentry はネイティブ機能として統合されている点が強力です。

【比較表】Sentry と Bugsnag の機能・料金一覧

実務者が教える選定基準：どちらを選ぶべきか？

Sentry を選ぶべきケース

• フルスタックでの可観測性を追求したい: フロントエンドから DB クエリ、パフォーマンスまで 1 つのツールで完結させたい場合。
• 再現の難しい UI バグが多い: Session Replay を活用して、カスタマーサポートへの負担を減らしたい場合。
• コストを細かく制御したい: サンプリングレート（エラーを何％間引いて送信するか）を細かく設定し、予算内に収める運用ができるチーム。

Bugsnag を選ぶべきケース

• モバイルアプリ開発がメイン: クラッシュ率を KPI にしており、リリース判断にツールを組み込みたい場合。
• 運用負荷を下げたい: Sentry は多機能すぎて設定に迷うことがありますが、Bugsnag はシンプルで学習コストが低いです。
• 「安定性スコア」を経営指標にしたい: エンジニア以外（PM や経営層）にシステムの現状を伝える際、スコア化されている Bugsnag は非常に説明しやすいです。

社内の DX 推進において、ツールの整理やライセンスコストの最適化は避けられない課題です。
SaaSコストを削減。フロントオフィス＆コミュニケーションツールの「標的」と現実的剥がし方
で解説している通り、エラー監視も「なんとなく両方入れる」のではなく、機能の重複を整理することが重要です。

導入・運用のステップバイステップガイド

ここでは Sentry を例に、実務で必須となる設定手順を解説します。

ステップ1：SDK の導入と初期設定

Node.js プロジェクトの場合、npm または yarn で SDK をインストールします。

npm install --save @sentry/react

初期化コードでは、dsn（Data Source Name）を指定します。ここで tracesSampleRate を 1.0 に設定するとすべてのパフォーマンスデータを送信しますが、本番環境では 0.1（10%）などに絞り、コストと負荷を抑えるのが通例です。

ステップ2：ソースマップのアップロード

ビルド・難読化された JavaScript のエラーは、そのままでは「a.js:1:500」のように表示され、原因が特定できません。CI/CD パイプライン（GitHub Actions 等）で、ビルド時に .map ファイルを Sentry にアップロードする設定を行います。これにより、Sentry 上で元の TypeScript コードの行数が表示されるようになります。

ステップ3：PII（個人情報）のフィルタリング設定

これはセキュリティ上、最も重要な工程です。デフォルトのままでは、URL パラメータに含まれるメールアドレスや、フォーム入力値が Sentry のサーバーに送信されるリスクがあります。
SDK の beforeSend フックを利用して、特定の文字列をマスクする処理を必ず実装してください。

ステップ4：通知ノイズの削減（アラートルール）

導入初期にやりがちな失敗が、すべてのエラーを Slack に通知し、誰も通知を見なくなる「アラート疲れ」です。
「新規発生のエラー（New Issue）のみ」「影響ユーザーが 10 人を超えた場合のみ」といったフィルタリングを Sentry/Bugsnag 側の設定で行います。

バックオフィス業務の自動化と同様、エラー監視も「仕組み化」が肝要です。
Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド
で紹介しているような業務改善の思考は、開発現場のエラーハンドリング運用の設計にも通ずるものがあります。

よくあるエラーとトラブルシューティング

• エラーが送信されない: 広告ブロック（AdBlock）などのブラウザ拡張機能によって、監視ツールのドメインがブロックされている場合があります。この場合、Sentry のトンネル機能（Tunnelling）を使用して自社ドメイン経由で通信させる対策が必要です。
• クォータ（上限）を即座に消費した: while ループ内でのエラーや、リトライ処理が無限に走るバグが本番に出ると、数万件のエラーが数分で飛びます。SDK 側の sampleRate 設定や、管理画面でのレートリミット設定を確認してください。
• ソースマップが反映されない: release 名が SDK 側とアップロード側で完全に一致しているか確認してください。1 文字でも違うと紐付けに失敗します。

まとめ：エラー監視がDXとプロダクト品質に与える影響

Sentry と Bugsnag はどちらも優れたツールですが、「多機能で統合的な Sentry」か、「シンプルで安定性重視の Bugsnag」かという選択になります。

エラー監視を導入することで、開発チームは「何かが起きているかもしれない」という不安から解放され、具体的なデータに基づいた改善に集中できるようになります。これは単なるデバッグの効率化ではなく、ユーザー体験（CX）の向上と、ビジネスの信頼性を支える重要なインフラ投資と言えるでしょう。

まずはスモールスタートとして、主要なフロントエンドのプロジェクトに無料枠で導入し、ソースマップの連携から始めてみることを強くお勧めします。