Rollbarとは？エラー監視の仕組み・Node.js導入手順・通知設計と料金、Sentry/Bugsnagとの選び分け【2026年10月】

Rollbar（ロールバー）は、アプリで起きた例外やログメッセージを集め、同じ原因のものを1件にまとめて通知する米Rollbar社のエラー監視サービスです。この記事では、送られた例外がどの規則で束ねられるか、Node.jsとExpressへの組み込みコード、ソースマップとデプロイ情報の送り方を順に示します。後半では、通知が多すぎて誰も見なくなる事態を避けるトリガーの選び方と、2026年10月時点の料金、SentryやBugsnagとどちらを選ぶかの判断基準を扱います。

まとめ：Rollbarを選ぶべき通知設計重視のチームと見送る条件

Rollbarの強みは、無料プランでもユーザー数が無制限で、月1万件9ドルからの細かい段階で課金できる点と、通知トリガーを「新しいエラー」「直したはずのエラーの再発」のように状態の変化で組める点にあります。開発者が数人から十数人のチームで、Slackに流す通知を絞り込んで運用したい場合に向いています。

見送るのは、リリースごとのクラッシュ率を指標にして出荷を判断したいモバイル中心のチームと、すでにAPMやログ基盤を1つの製品にまとめている環境です。前者はBugsnagの安定性スコア、後者は既存製品のエラー追跡機能のほうが手戻りが少なく済みます。

Rollbarの仕組み：オカレンスをアイテムへ束ねるフィンガープリントの規則

Rollbarは、アプリに組み込んだSDKが例外を検知してAPIへ送り、サーバー側でまとめて画面に並べる構成です。SDKはJavaScript（ブラウザとNode.js）・Python・Ruby・PHP・Java・.NET・iOS・Android・Flutter・React Nativeなどに公式で用意されています。

オカレンスとアイテムの違い：同一フィンガープリントで1件にまとめる単位

Rollbar Terminologyによると、SDKが送る1回1回の例外やメッセージを「オカレンス（Occurrence）」、同じ原因とみなしたオカレンスの束を「アイテム（Item）」と呼びます。課金はオカレンス数で決まり、画面にはアイテムが並ぶという関係です。

アイテムにはActive・Resolved・Muted・Mergedの4つの状態があります。運用で押さえるべきは、Resolvedにしたアイテムに新しいオカレンスが届くと自動でActiveに戻る「Reactivated」です。人が手で戻す「Reopened」とは別の遷移として記録されるため、修正したはずの不具合の再発だけを通知に拾えます。この区別が後述の通知設計の土台になります。

既定のグルーピング：行番号でなくソース行とSHA1で指紋を作る理由

Default Grouping Algorithmによると、Rollbarはオカレンスごとに「フィンガープリント」という文字列を計算し、同じ値のものを1つのアイテムにまとめます。よく出る例外の型は機械学習で見つけたパターンで判定し、それ以外は次の手順で計算する方式です。

1. 再帰呼び出しやNode.jsのrunMicrotasksなど、ノイズと分かっているスタックフレームを除く
2. 残った全フレームについて、ファイル名・関数名・その行のソースコードをつなげる
3. 末尾に例外クラス名を足し、SHA1でハッシュを取る

行番号を使わないので、ファイルの先頭に1行足しただけではアイテムが分かれません。反対に、エラーが出た行そのものを書き換えると別のアイテムになります。最上位のフレームだけでなく全フレームを使うため、同じライブラリ関数で落ちた無関係な不具合が1件に混ざりにくい代わりに、1つの原因が複数のアイテムに散ることがあります。

カスタムフィンガープリントのJSONルールで分かれすぎたアイテムを束ねる手順

DB停止のように、あちこちの呼び出し元で同じ例外が出る障害は、既定の規則だと呼び出し元ごとに別アイテムになります。Custom Fingerprinting Rulesを使うと、Project Settingsの「Custom Fingerprinting」にJSONで条件を書き、まとめ方を上書きできます。

[
  {
    "condition": {"path": "body.trace.exception.class", "eq": "SequelizeConnectionError"},
    "fingerprint": "db-connection-error",
    "title": "DB接続エラー（呼び出し元を問わず1件）"
  },
  {
    "condition": {"path": "body.trace.exception.message", "icontains": "ETIMEDOUT"},
    "fingerprint": "upstream-timeout"
  }
]

ルールは上から順に評価され、最初に条件が合ったもののfingerprintが使われます。演算子はeq・icontains・regex_matchなど14種類で、any・all・noneで条件を組み合わせることが可能です。SDK側でfingerprintを送っている場合は、多くのプロジェクトでSDKの値が優先される点に注意が要ります。

RollbarをNode.jsとExpressへ組み込む導入手順とコード例

ここからは、Rollbarのアカウントとプロジェクトを作成済みという前提で、Node.jsのWebアプリに組み込む手順を示します。サーバー側では、プロジェクト設定の「Project Access Tokens」にあるpost_server_itemスコープのトークンを使います。

rollbar 4.1系のインストールとNode 18を外した4.0系の変更点

Node.jsとブラウザの両方を扱う公式SDKは、npmのrollbarパッケージです。npmレジストリ上の最新版は2026年10月18日公開の4.1.0で、型定義も同梱されています。GitHubのリリースノートによると、10月6日の4.0.0でNode 18のサポートが外れました。Node 18のまま動かしている環境では、3.1系に留めるか、ランタイムを先に上げる必要があります。

npm install --save rollbar

Node.jsのドキュメントのExpress構成に、版の記録と個人情報の扱いを足した初期化例です。

const express = require('express')
const Rollbar = require('rollbar')

const rollbar = new Rollbar({
  accessToken: process.env.ROLLBAR_SERVER_TOKEN,   // post_server_item スコープのトークン
  environment: process.env.NODE_ENV,               // production や staging
  captureUncaught: true,                           // 未処理の例外を送る
  captureUnhandledRejections: true,                // Promiseの未処理リジェクトを送る
  reportLevel: 'warning',                          // 既定は debug。warning 未満は送らない
  scrubFields: ['cardNumber', 'myNumber'],         // 既定の伏せ字リストに追記される
  captureIp: 'anonymize',                          // 既定は true（IPをそのまま保存）
  payload: { code_version: process.env.GIT_SHA }   // デプロイ情報と突き合わせる版
})

const app = express()
/* ここにルートと他のミドルウェアを書く */
app.use(rollbar.errorHandler())   // ルート定義の後ろに置く
app.listen(3000)

scrubFieldsは既定のリスト（password・secret・access_token・request.cookieなど）に追記される仕様で、置き換えたいときだけoverwriteScrubFields: trueを足します。reportLevelを既定のdebugのままにすると、rollbar.infoで書いたログまで課金対象のオカレンスになります。

try-catchで握った例外をrollbar.errorと利用者IDで送るコード

未処理の例外は初期化だけで送られます。手で送るのは、catchで処理を続ける代わりに記録だけは残したい例外です。レベルごとにdebugからcriticalまでのメソッドがあり、2番目の引数にリクエストを渡すとURLやヘッダーも記録されます。

app.post('/orders', async (req, res) => {
  try {
    await chargeCustomer(req.body)
  } catch (e) {
    // 処理は続けるが、注文IDを付けて記録を残す
    rollbar.warning(e, req, { orderId: req.body.orderId })
    return res.status(502).json({ message: '決済処理に失敗しました' })
  }
  res.status(201).end()
})

どの利用者がエラーに当たったかを残すには、リクエストにuserかrollbar_person（idは必須・40文字まで）を付けます。Passportで認証していれば、利用者情報は自動で拾われる仕組みです。既定で送られるのはIDだけで、メールアドレスとユーザー名はcaptureEmail・captureUsernameを有効にしたときに限られます。

ブラウザのソースマップをcurlで送り圧縮後のスタックトレースを戻す手順

本番のJavaScriptは圧縮されているため、そのままではスタックトレースが読めません。Source Mapsのドキュメントでは、ソースマップを公開URLから自動で取りに行かせる方法もありますが、本番では事前アップロードを推奨しています。デプロイ直後の数件にソースマップが当たらない取りこぼしを避けるためです。

curl https://api.rollbar.com/api/1/sourcemap \
  -F access_token=$ROLLBAR_SERVER_TOKEN \
  -F version=$GIT_SHA \
  -F minified_url=//example.com/assets/app.min.js \
  -F source_map=@dist/app.min.js.map

minified_urlはスキーム（https:）を除いた形で書き、versionはブラウザ側SDKのcode_versionと同じ値にします。ブラウザ側の設定ではsource_map_enabledの既定がfalseなので、trueにするのを忘れないでください。ソースマップは遡って適用されないので、アップロード前に届いた例外は圧縮後の表示のまま残ります。サーバー側のTypeScriptなら、nodeSourceMaps: trueで送信前に変換させる方法も選べます。

通知設計：New ItemとReactivatedを軸にSlackへ流すアラートの組み方

エラー監視を入れても、通知が多すぎてチャンネルがミュートされれば意味がありません。Rollbarの通知はプロジェクト単位で、Slack・メール・PagerDuty・Webhookなどの連携先ごとにルールを組みます。

通知トリガーの選び方：本番で有効にする4種とEvery Occurrenceの扱い

Notificationsのドキュメントには、New Item・Every Occurrence・10^th Occurrence・High Occurrence Rate・Item Reactivated・Deployなどのトリガーが並びます。本番で最初に有効にするのは次の4つで十分です。

• New Item：初めて見るエラー。リリース直後の新しい不具合を拾う
• Item Reactivated：Resolvedにしたエラーの再発。修正漏れと先祖返りを拾う
• High Occurrence Rate：y分間にx件。障害の発生をつかむ
• 10^th Occurrence：10件・100件・1,000件目。じわじわ増えるエラーに気づく

Every Occurrenceは発生のたびに通知するため、公式も「use wisely」と注意しています。使うのはレート制限の到達のような件数の少ない事象だけにします。各ルールにはEnvironment・Level・Filenameなどのフィルターを掛けられるので、production環境かつerror以上に絞るのが基本形です。

Suspect Deployを効かせるデプロイ通知：CIからAPIへ送るcurl例

Deploy Trackingによると、デプロイはRollbar側で自動検知されず、CIからAPIで知らせる必要があります。知らせておくと、各アイテムに「最初の発生の直前のデプロイ」がSuspect Deployとして表示され、どのリリースで入り込んだかを追えます。

curl https://api.rollbar.com/api/1/deploy \
  -H "X-Rollbar-Access-Token: $ROLLBAR_SERVER_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"environment\":\"production\",\"revision\":\"$(git rev-parse HEAD)\",\"local_username\":\"ci\"}"

Report a deployのAPIリファレンスではenvironmentとrevisionが必須で、statusの既定はsucceededです。startedで送った場合は60分以内に完了状態へ更新しないとtimed_outになります。コミットメッセージに書いたアイテムをデプロイ時に自動でResolvedにする機能もあり、Reactivatedの通知と組み合わせると修正の確認まで一続きになります。

Adaptive Alertsとレート制限の通知：429で取りこぼす量の把握

Adaptive Alertsは、過去2週間の例外数を1時間刻みで学習し、普段と違う増え方をしたときに最大10分の遅れで知らせる通知です。グルーピングに左右されず例外の型と環境単位で数えるため、アイテムが散らばる障害でも1通で気づけます。使えるのはAdvancedとEnterpriseのプランに限られます。

見落としやすいのがレート制限です。トークンごとの上限に達すると、APIは429 Too Many Requestsを返し、その間の例外は処理も課金もされません。到達時には「Your rate limit has been reached」で始まるSystem Messageのアイテムが無料で作られるため、このタイトルに絞ったEvery Occurrenceのルールを1本足しておくべきです。

Rollbarの料金：オカレンス段階課金のプラン比較と超過時の3つの挙動

Rollbarは全プランでユーザー数による課金が無く、月間のオカレンス数で金額が決まります。以下は料金の機械可読ページ（2026年7月8日生成と明記）の値で、2026年10月20日に確認しました。年払いは2か月分が無料になる換算の月額です。

月1万件9ドルから：Free・Essentials・Advancedの実額と保持期間

段階は月1万件から5,000万件まであり、Enterpriseは月8,000万件超が対象です。AdvancedではAdaptive Alerts・RQLによる分析・SCIMが加わり、件数が増えるほどEssentialsとの差が開きます。月10万件では月払いで80ドルの差です。セッションリプレイ（Freeは月1,000件まで）とAI機能向けのクレジットは別料金で足していく形になります。料金ページからAdvanced相当を14日間試せます。

上限到達時の停止・オンデマンド・予算上限の3方式と本番で選ぶ設定

プランの件数を使い切ったときの挙動は、アカウント単位で3つから選びます。

• 停止（既定）：翌月の更新まで新しいオカレンスを処理しない。請求額は増えないが、障害の真っ最中に記録が途切れる
• オンデマンド：Essentials以上。同じ単価で上限なく処理を続ける
• 超過予算：Essentials以上。先に決めたドル額まで超過を許し、達したら停止する

本番では超過予算を選び、月額の2〜3割程度を上限にする設定が無難です。既定の停止は、エラーが急増した日、つまり記録が一番欲しい日に監視が止まる設計だからです。オンデマンドは上限が無いため、無限ループで例外を投げ続けるような不具合1つで請求が跳ねます。

RollbarとSentry・Bugsnagの選び分け：通知設計と保持期間で決める基準

Rollbarの比較相手として挙がるのはSentryとBugsnagです。各製品の導入方法はSentryの料金プランと導入手順とBugsnagの仕組みと安定性スコアにまとめています。

無料枠・入口価格・保持期間の比較表：Rollbarの5,000件と無制限ユーザー

RollbarはEssentials、BugsnagはBugsnagの料金ページのSelectプラン、SentryはSentryの料金ページのTeamプランの値です（2026年10月時点）。月5万件の単価は3製品で大差がありません。差が出るのは、無料のまま複数人で使えるかと、RollbarのAdvancedを選んだときの180日という保持期間です。

Rollbarを採用すべき条件：小規模チームでユーザー数を気にせず使う体制

採用するのは、Webアプリやバックエンドを数人から十数人で開発し、エラーの件数がまだ月数万件に収まるチームです。無料プランのまま全員をメンバーにでき、件数が増えても1万件刻みで費用を合わせられます。New ItemとReactivatedをSlackに流し、デプロイ通知でSuspect Deployを出す構成なら、Essentialsの範囲で運用が回ります。

Datadogを使っている組織でも、料金ページの比較表にあるとおりRollbarのデータはDatadogへ転送できます。エラー追跡だけを開発者向けの軽い画面に分けたい場合の選択肢です（Datadog本体の機能はDatadogの仕組みと料金を参照）。エラー監視の導入に加え、通知ルールや障害時の連絡体制まで整えたい場合は、保守運用・内製化支援としてツール選定から運用ルールづくりまで相談を受けています。

Rollbarを見送る場面：リリース単位の安定性指標やAPM統合が必要な構成

見送るのは、iOSとAndroidのアプリを段階リリースし、「エラーの無かったセッションの割合」で配信を広げるか止めるかを決めているチームです。Rollbarにもバージョン単位の集計とSuspect Deployはありますが、セッションを分母にした指標を前提に運用するならBugsnagが合います。

すでにDatadogやNew RelicでAPMとログを計装している環境も、エラー追跡のためだけにRollbarを足す理由は薄くなります。その場合はDatadog Error Trackingの実装手順のように既存の計装の上でエラーを束ねるほうが近道です。APMとエラー監視の守備範囲はAPMの仕組みと導入判断、製品の横並びの比較はオブザーバビリティツールの選定軸で整理しています。

Rollbarの導入前によくある質問：無料プラン・対応言語・個人情報

Rollbarの検討でよく出る質問に、2026年10月時点の公式ドキュメントと料金ページをもとに答えます。

Rollbarは無料で使えますか？

Freeプランがあり、月5,000オカレンスと月1,000件のセッションリプレイまで無料です。ユーザー数とプロジェクト数に制限は無く、クレジットカードの登録も要りません。データの保持は30日です。件数を使い切ると既定では翌月まで処理が止まるため、本番の全エラーを受けるより、まず1つのサービスで件数の感覚をつかむ用途に向いています。

Rollbarはどの言語やフレームワークに対応していますか？

公式ドキュメントの「Latest SDK Versions」に並ぶSDKは、JavaScript（ブラウザ・Node.js）、Ruby、Java、.NET、PHP、Python、Apple（iOS・macOS）、React、React Native、Flutter、Rust、Goです。AndroidはJava SDKの一部として提供されています。JavaScriptではAngular・Vue.js・Next.js・Svelteのガイドがあり、PythonはDjango・Flask・FastAPI、PHPはLaravelの手順も用意されています。

RollbarのアイテムとオカレンスはSentryの何に当たりますか？

Rollbarのオカレンスは、Sentryでいう1件のエラーイベントに当たります。アイテムは、同じ原因のイベントを束ねたSentryのIssueに相当する単位です。料金はどちらもイベント（オカレンス）の件数で決まり、画面ではアイテムやIssueの単位で一覧になる点も共通しています。束ね方の規則は製品ごとに異なり、Rollbarは全スタックフレームのソース行を使う方式です。

Rollbarに個人情報を送らないようにするにはどうすればよいですか？

SDKのscrubFieldsに伏せたいキー名を足すと、送信前に値が*に置き換わります。サーバー版はpasswordやaccess_tokenなど25項目、ブラウザ版はクレジットカード関連の項目が既定で伏せ字です。IPアドレスは既定で全桁が保存されるため、captureIpを'anonymize'かfalseにします。利用者のメールアドレスは既定では送られません。

Rollbarのローカル変数の取得は本番で有効にしても大丈夫ですか？

Node.jsでは、スタックトレースにローカル変数を添える機能が既定で無効です。有効にするとNodeのInspector APIを使うため、例外を投げる処理が通常の1ミリ秒未満から数ミリ秒に延びると公式が説明しています。既定のuncaughtOnly: trueのまま未処理の例外だけに絞り、変数名に合わせて伏せ字のキーも見直してから有効にしてください。

関連記事

• Bugsnagとは？エラー監視の仕組み・JavaScript導入手順・安定性スコアと料金、Sentryとの選び分け【2026年10月】：リリース単位の安定性スコアを持つエラー監視サービス。
• Sentryとは？エラー監視ツールの意味・料金プランと無料枠・導入手順【2026年10月】：Rollbarと最も比べられるエラー監視サービスの機能と料金。
• Datadog Error Tracking実装手順：イシュー集約とソースマップ登録、APM/RUM/Logs連携：APMを入れた環境でエラーを束ねる別の選択肢。
• オブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方【2026年8月時点】：監視製品を課金モデルと体制で選ぶ判断軸。
• オブザーバビリティ（可観測性）とは？監視・モニタリング・APMとの違いと使い分けを解説：エラー監視を含む監視領域全体の位置づけ。