LabHub

ブログ

エラートラッキング & モニタリング 2026 — Sentry / Bugsnag / Honeybadger / GlitchTip / Highlight / LogRocket / Hyperdx 徹底比較

2026-05-16 · 25 分で読めます · #error-tracking#monitoring#sentry#bugsnag#honeybadger#rollbar#glitchtip#highlight-io#appsignal#raygun#betterstack#logrocket#fullstory#hyperdx#openreplay#opentelemetry#observability#deep-dive#japanese

한국어English日本語

1. 2026年のエラートラッキング地図 — 商用 / OSS / セッションリプレイ 3 陣営

2026年のエラートラッキングは「Sentry を入れれば終わり」という時代を抜けました。Sentry が事実上のリーダーであることは変わりませんが、その周りに3つの明確なカテゴリが育っています — クラシックな商用ツール、セルフホスト可能なオープンソース、そして「エラーだけでなくその直前60秒のユーザー行動」を見せるセッションリプレイ陣営です。

全体像を整理するとこうなります。

2026年のキーになる変化は3つ。第一に、Sentry が2024年に Codecov を買収したことで「エラー → 影響を受けたコード → 影響を受けた PR → 誰の変更か」のフローが一社内で完結するようになりました。第二に、OpenTelemetry の Logs シグナルが GA から2年目に入り、ベンダーロックインなくエラーを送る道が実用的になりました。第三に、AI グルーピング / AI トリアージが Sentry、Datadog、Bugsnag すべてで標準機能になりました。

この記事は上記のツールを2026年5月時点で機能 / 価格 / セルフホスト可否 / データレジデンシーの観点から駆け足で見ていくガイドです。

2. Sentry — リーダー、Codecov 買収 (2024)、AI 機能

Sentry は2008年に David Cramer が作ったオープンソースエラートラッカーから出発し、いまやエラートラッキングの事実上の標準です。2024年最大の出来事は Codecov の買収でした — コードカバレッジツールの Codecov を取り込むことで、「エラーが起きた行のテストカバレッジ」と「エラーを引き起こした変更の PR 番号」を一画面で見せる構図が完成しました。

2026年5月時点で Sentry がカバーする領域はこうです。

JavaScript クライアントの基本セットアップはこんな感じです。

import * as Sentry from '@sentry/nextjs'

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  release: process.env.SENTRY_RELEASE,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.0,
  replaysOnErrorSampleRate: 1.0,
  integrations: [
    Sentry.replayIntegration({
      maskAllText: true,
      blockAllMedia: true,
    }),
  ],
})

コアになるパターンをいくつか。

価格は2026年5月時点で Team プラン月 $26 から、Business 月 $80 から。セルフホストも可能ですが、2024年から Sentry 本体は Business Source License (BSL) に移行しました — ホスティングサービスとして再販はできませんが、社内利用は無料です。

3. Bugsnag (SmartBear) — エンタープライズ

Bugsnag は2013年に作られたエラートラッカーで、2021年に SmartBear が買収しました。SmartBear は BitBar / Cucumber / SoapUI / TestComplete といった QA ツールチェーンを持つ会社で、買収後の Bugsnag はエンタープライズ / コンプライアンス / SDLC 統合の方向にさらに振れました。

Bugsnag の差別化ポイント。

Bugsnag の日本 / 韓国市場シェアは Sentry より小さいですが、グローバルエンタープライズ (特にモバイルゲーム / フィンテック) ではいまも第一候補です。

価格は非公開 — セールス問い合わせベース。一般にシート単価と従量課金のミックスです。

JavaScript クライアントのセットアップは Sentry とほぼ同型。

import Bugsnag from '@bugsnag/js'
import BugsnagPluginReact from '@bugsnag/plugin-react'

Bugsnag.start({
  apiKey: process.env.NEXT_PUBLIC_BUGSNAG_KEY,
  appVersion: process.env.APP_VERSION,
  releaseStage: process.env.NODE_ENV,
  enabledReleaseStages: ['production', 'staging'],
  plugins: [new BugsnagPluginReact()],
})

4. Honeybadger — インディー向き

Honeybadger は2012年に Ben Curtis / Joshua Wood / Starr Horne の3人で始めたブートストラップ会社です。VC 資本なしで運営され、「インディーハッカー / Rails コミュニティの友達」のポジションを保ち続けています。

特徴を整理するとこうなります。

Honeybadger の魅力は「チームが小さくても、決済が単純でも、コンプライアンスが軽くても気軽に使える」点です。Sentry の機能幅が重い、Bugsnag のセールスサイクルが重い、と感じる1人 / 小規模チームの選択肢です。

Ruby のセットアップは1行に近いです。

# Gemfile
gem "honeybadger"

# config/honeybadger.yml
api_key: 'xxx'
env: <%= Rails.env %>

5. Rollbar — ロングテール

Rollbar は2012年に作られ、Sentry とほぼ同時期にスタートしたエラートラッカーです。かつては Sentry と二強でしたが、2020年代に入って機能幅 / コミュニティ / 価格競争で押されてシェアが縮みました。2026年も生きていますが「ロングテール」のポジションです。

Rollbar のいまも残る強み。

既存の Rollbar ユーザーは続けて問題ありませんが、新規導入で Rollbar を最初に検討するケースは減りました。

6. GlitchTip — オープンソース Sentry 互換

GlitchTip は2020年に Burke Software が始めたオープンソースエラートラッカーです。最大の特徴は Sentry の SDK / ワイヤープロトコルと互換であること — つまりクライアントコードで DSN だけ差し替えれば、そのまま GlitchTip に送れます。

GlitchTip が狙う位置は明確です。

Docker Compose 一発でセルフホストできます。

git clone https://gitlab.com/glitchtip/glitchtip-backend.git
cd glitchtip-backend
docker compose up -d

既存の Sentry クライアントの DSN だけ差し替えればそのまま動きます。

import * as Sentry from '@sentry/browser'

Sentry.init({
  // Sentry 本体ではなく GlitchTip ホストへ
  dsn: 'https://yourkey@glitchtip.example.com/1',
})

GlitchTip は Sentry のすべての機能を追いません (特に Performance / Replay / Profiling はなし)。ただ「エラーさえちゃんと拾えればよい、そして自社データセンターで回したい」というニーズには最も軽い答えです。

7. Highlight.io — オープンソース + セッションリプレイ

Highlight.io は2022年に始まったオープンソースの可観測性プラットフォームです。エラートラッキング + セッションリプレイ + ログ + 分散トレースを一画面に束ねるのが特徴。Apache 2.0 ライセンスで、GitHub とセルフホストとの互換性を優先します。

特徴を整理するとこうです。

Highlight が面白い位置は「オープンソースなのに LogRocket 級のセッションリプレイが付く」点です。LogRocket のライセンス / 価格が重いインディー / 小規模チーム / 非営利によい候補です。

import { H } from 'highlight.run'

H.init('YOUR_PROJECT_ID', {
  environment: 'production',
  version: 'commit:abcdefg12345',
  tracingOrigins: true,
  networkRecording: {
    enabled: true,
    recordHeadersAndBody: true,
    urlBlocklist: ['/api/auth/login'],
  },
})

8. AppSignal — Elixir/Ruby 特化

AppSignal はオランダの会社で、2012年に Ruby on Rails の APM としてスタートし、現在は Elixir / Node.js / Python / Ruby を第一級で支援するフルスタック可観測性ツールです。特に Elixir コミュニティでは事実上の標準です。

特徴。

AppSignal は「Elixir / Rails 系のダイナミック言語を使い、単一ツールで APM + エラーを片付けたい」ユーザーに最適です。JS / Java / Go がメインのチームには合いません。

Elixir のセットアップ。

# mix.exs
defp deps do
  [
    {:appsignal_phoenix, "~> 2.4"}
  ]
end

9. BetterStack — ログ + エラー + ステータスページ

BetterStack はスロバキアの会社で、Better Uptime (2021) と Logtail (2022) を統合した可観測性プラットフォームです。2026年現在は Uptime / Logs / Telemetry (メトリクス+トレース) / Incidents / Status Pages を1つの SaaS に束ねています。

特徴。

BetterStack の差別化は「1社で Uptime + Logs + Status Page まで束ねる」点。小規模 SaaS / インディー / スタートアップが PagerDuty + Datadog + statuspage.io といった3つを糊で貼らずに1か所で始めるよい候補です。

エラートラッキングの「専用ツール」ではないですが、ログベースでエラーを検知 / アラートするワークフローは十分に組めます。Sentry の領域と部分的に重なります。

10. LogRocket / FullStory / OpenReplay — セッションリプレイ

セッションリプレイは「エラーが出たときその直前 N 分のユーザー画面 / クリック / ネットワーク / コンソール」を動画のように再生してくれる機能です。クラシックな「バグが再現しない」問題を解きます。2026年の3強は LogRocket、FullStory、OpenReplay です。

LogRocket — 2016年スタート、最も有名なセッションリプレイツール

FullStory — UX 分析の代表

OpenReplay — オープンソースのセッションリプレイ (Elastic License)

セッションリプレイは PII / GDPR 問題が常に伴います。入力値 / クレジットカード番号 / トークンをクライアントでマスクしてから送るのが標準です。

// LogRocket 例
import LogRocket from 'logrocket'

LogRocket.init('your/app-id', {
  network: {
    requestSanitizer: (request) => {
      if (request.url.includes('/api/auth')) return null
      delete request.headers['Authorization']
      return request
    },
  },
  dom: {
    inputSanitizer: true,
    textSanitizer: false,
  },
})

11. Hyperdx — OpenTelemetry ネイティブのオープンソース

Hyperdx は2023年に始まったオープンソースの可観測性プラットフォームです。最大の特徴は OpenTelemetry ネイティブ — つまり OTLP が第一級の入力で、ClickHouse がバックエンドです。2024年に ClickHouse が Hyperdx を買収したことで、現在は ClickHouse Observability の1コンポーネントとして位置付けられています。

特徴。

Hyperdx の位置は明確です。「ベンダーロックインなしで OpenTelemetry 標準の上にセルフホストしたい、なおかつ Sentry のような UX もほしい」チームです。ClickHouse 買収後、「ClickHouse + Hyperdx + OTel」スタックは Datadog / New Relic の強力な代替になっています。

// OpenTelemetry SDK の設定だけで Hyperdx に自動送信
import { NodeSDK } from '@opentelemetry/sdk-node'
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http'

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'https://in-otel.hyperdx.io/v1/traces',
    headers: {
      authorization: process.env.HYPERDX_API_KEY,
    },
  }),
})

sdk.start()

12. Datadog / New Relic — APM との統合

Datadog Error Tracking と New Relic Errors Inbox は「APM に組み込まれたエラートラッキング」です。別ツールではなく APM の1タブとしての位置付け。

Datadog Error Tracking の特徴。

New Relic Errors Inbox の特徴。

「すでに Datadog / New Relic を APM として使っている」チームは、Sentry を別途導入する前にこの機能を有効化するのが合理的です。追加ツールなしで APM + エラーを一画面で解けます。

13. OpenTelemetry Logs/Errors シグナルの成熟

OpenTelemetry は2019年に OpenTracing と OpenCensus が統合してできた可観測性標準です。最初は Traces のみ GA でしたが — Metrics が2023年、Logs が2024年に順次 GA になりました。2026年時点では「OpenTelemetry でログ + トレース + メトリクス + エラーを1つの SDK で送り、バックエンドだけ差し替える」シナリオが実用的です。

OpenTelemetry でエラーを送る標準形はこうです。

import { trace, SpanStatusCode } from '@opentelemetry/api'

const tracer = trace.getTracer('my-app')

async function fetchUser(id: string) {
  return tracer.startActiveSpan('fetchUser', async (span) => {
    try {
      const user = await db.user.findUnique({ where: { id } })
      span.end()
      return user
    } catch (err) {
      span.recordException(err)
      span.setStatus({ code: SpanStatusCode.ERROR, message: err.message })
      span.end()
      throw err
    }
  })
}

こうして作られたエラーは OTLP でどこにでも送れます — Sentry (OTLP 入力ベータ)、Datadog、New Relic、Hyperdx、Grafana、または自社バックエンド。これが2026年の「エラーは標準、ベンダーは交換可能」シナリオの基盤です。

ただ実際にはすべてのベンダーが OTLP を第一級で受けるわけではありません。Sentry / Datadog / New Relic はいずれも自社 SDK のほうが機能が多く (自動コンテキスト / 自動グルーピング / 自動 PII マスキング)、OTLP 経路はそれよりミニマムです。「ベンダーロックイン」と「最大機能」のトレードオフがあります。

14. 韓国 / 日本 — トス、カカオ、メルカリ、LINE、freee

韓国 / 日本の大規模企業が実際にどんなエラートラッカーを使っているかを見ると、グローバルトレンドと近いながらも地域色があります。

韓国の事例

日本の事例

共通パターンが見えます。ユーザーデータ量が一定規模を超える (月数億イベント以上) と、自社ツール / セルフホストを再検討します。コストもさることながら、韓国の個人情報保護法、日本の個人情報保護法のデータレジデンシー要件が大きいのです。だから小規模企業は Sentry SaaS、大規模企業は Sentry セルフホスト or 自社ツールに割れる形がよく見られます。

15. 誰が何を選ぶべきか — 1人 / スタートアップ / エンタープライズ / セルフホスト

最後にシナリオ別の推奨を整理します。

1人 / インディー / サイドプロジェクト

小規模スタートアップ (10名以下)

成長期スタートアップ (10〜100名)

エンタープライズ (100名以上、コンプライアンス重要)

セルフホスト / データ主権

言語 / ランタイム別第一候補

2026年のベストセットアップは「Sentry」か「OpenTelemetry + バックエンド」のどちらかです。Sentry は即時の価値、OpenTelemetry は長期の自由を与えます。小さなチームは Sentry、大きなチームは OTel の上に Sentry / Datadog / Hyperdx を載せる両面戦略が一般的になっています。

16. 参考 / References

Sentry

Bugsnag

Honeybadger

Rollbar

GlitchTip

Highlight.io

AppSignal

Raygun

BetterStack

LogRocket / FullStory / OpenReplay

Hyperdx

Datadog / New Relic

OpenTelemetry

韓国 / 日本のエンジニアリングブログ

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-error-tracking-monitoring-2026-sentry-bugsnag-honeybadger-glitchtip-highlight-logrocket-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます