こんにちは！開発チームの守り神、そして夜間呼出しに怯えないためのオブザーバビリティ設計を愛する先輩エンジニアです。
新しいプロダクトを立ち上げたり、既存のシステムに「Sentry」を導入しようとしたとき、誰もが一度はこう不安に思うはずです。
「Sentryって、エラーが爆発的に発生したら料金が高額になるって本当？」
「無料プランですぐに上限に達して、肝心な時にエラーが追えなくなったらどうしよう……」
結論から言いましょう。Sentryは「何も考えずに導入すると、どうでもいいノイズエラーでチケット（イベント枠）を秒速で溶かす魔物」ですが、正しい知識を持って手懐ければ、開発チームにとっての最強の相棒になります。
今回は、Sentryの料金体系のリアルな裏側から、Freeプランの限界を華麗に突破する「サンプリングの魔法」、そして有料プランへ移行すべき運命の分かれ目まで、現場の知見をたっぷり詰め込んで優しく解説します。これをマスターすれば、無駄なコストに怯える夜とはおさらばできますよ！
—
1. Sentryの料金体系（Developer, Team, Business）の概要
まずは、Sentryの土俵を知ることから始めましょう。Sentryのプランは大きく分けて以下の3つです。
1. Free（Developer）プラン
- 向いている人: 個人開発、小規模なプロトタイプ、まだ収益化していない趣味のプロジェクト。
- 特徴: ずっと無料。ただし機能制限と月ごとのイベント数（エラーの発生回数）にシビアな上限があります。
2. Teamプラン
- 向いている人: 成長中のスタートアップ、本格的なSaaSプロダクト。
- 特徴: 月額26ドル〜（従量課金あり）。チームメンバーの無制限追加、エラーの優先度付け、アラートの高度化など、実務で必要な機能が揃います。
3. Businessプラン
- 向いている人: 中規模〜大規模企業、複数のプロダクトを抱える組織。
- 特徴: 月額80ドル〜。高度なワークフロー、ロールベースのアクセス制御（RBAC）、より長いデータ保持期間など、エンタープライズ向けの堅牢性を提供します。
ここで知っておくべき最大のポイントは、Sentryの課金は「月間のイベント消費数（Errors と Transactions）」をベースにしているという点です。「何人開発者がいるか」ではなく、「システムがどれだけエラーを吐き、どれだけリクエストをトレースしたか」で財布の中身が決まります。
—
2. Free（Developer）プランで許容されるイベント数の上限と注意点
「とりあえず無料で試そう！」とSentryを導入したエンジニアが、数日で直面する最初の壁がこれです。
- Freeプランの枠： 月間 5,000 エラー (Errors) および 10,000 トランザクション (Transactions)
「5,000件もあれば十分じゃん？」と思いましたか？
ここに大きな罠があります。例えば、フロントエンド（ReactやVueなど）でよくある「ネットワークが一時的に切断された時の未処理のPromise拒否」や、サードパーティ製スクリプト（Googleアナリティクス等）が引き起こす`Script error.`がループしたとしましょう。
1人のユーザーがリロードを繰り返すだけで、数分で数百件のエラーがSentryに飛び込みます。 気づいた時には、月の半ばどころか、導入して2日目で「今月の枠を使い切りました」という冷酷な通知メールが届くことになります。これが「Freeプランの限界」の正体です。
—
3. 意図しないイベント消費を防ぐための「Sampling（サンプリング）」設定
では、どうすればこのイベント消費の暴走を防げるのでしょうか？
答えは「サンプリング（間引き）」です。全てのゴミエラーを律儀に収集する必要はありません。必要なのは「シグナル（本当に重要なバグ）」だけであり、「ノイズ（通信不良やブラウザ依存の軽微な例外）」は適度に捨てるべきなのです。
ここでは、最も効果が高いパフォーマンス監視（Transactions）のサンプリングレート設定と、不要なエラーを送信前に握りつぶす（BeforeSend）テクニックの基礎をセットアップしましょう。
実装例：JavaScript / TypeScript (Node.js or ブラウザ) の場合
以下のコードは、Sentryを初期化する際の最も安全で実用的な設定テンプレートです。
import as Sentry from “@sentry/node”;
Sentry.init({
dsn: “あなたのSentryのDSNをここに記述”,
// 1. パフォーマンス監視のサンプリングレート（0.0 から 1.0）
// 0.1 なら、全トランザクションの 10% だけをサンプリングして送信します。
// 本番環境のトラフィックが多い場合は 0.05 (5%) や 0.01 (1%) に絞るのが定石です。
tracesSampleRate: 0.1,
// 2. イベントがSentryサーバーに飛ぶ直前にフックする（超重要！）
// ここで不要なエラーをフィルタリングして、イベント消費枠を守ります。
beforeSend(event, hint) {
const error = hint.originalError;
// 例：特定の既知の外部起因エラーや、無視したい特定の文字列が含まれる場合は null を返して破棄
if (error && error.message && error.message.includes(“Network Error”)) {
// ネットワーク一時切断など、サーバー側でコントロールできないものは捨てる
return null;
}
// 古いブラウザからの意味不明なエラーもここで弾くことが可能
if (event.culprit && event.culprit.includes(“some-outdated-plugin.js”)) {
return null;
}
return event; // 通過したものはSentryへ送信される
},
});
この `beforeSend` と `tracesSampleRate` を適切に設定するだけで、Freeプランの5,000件という上限は、個人の小規模アプリであれば余裕でお釣りが来るほど長持ちするようになります。
—
4. 有料プランへ移行すべきタイミングの判断基準
では、サンプリングで工夫してもなお、Freeプランでは耐えられなくなる「正しい移行のタイミング」とはいつでしょうか？
以下の3つのシグナルが出たら、それはあなたのプロダクトがビジネスとして成長している証拠です。迷わずTeamプランへの移行（財布の紐を緩めること）を検討してください。
① ユーザーベースが拡大し、エラーの「全体像」を正確に把握する必要が出たとき
サンプリングレートを下げている（例えば 1% にしている）ということは、「100件に1件のエラーしか見えていない」ことを意味します。
ユーザー数が数千人を超え、特定の環境でのみ発生するクリティカルなバグ（決済エラーやログイン不可など）を「見逃すリスク」が、有料プランの月額料金（約26ドル＝約4,000円〜）のコストを上回った時が移行の合図です。
② アラートの宛先やチームメンバーが増えたとき
Freeプランではメンバーの権限管理や通知連携（SlackやPagerDutyなど）に制限があります。「誰がどのエラーの担当者（Assignee）か」がチーム内で曖昧になり、誰もエラーを見なくなる「監視の死角」が生まれるチーム規模になったら、Teamプランの組織機能に投資する価値が十分にあります。
③ 「エラーの調査時間」にエンジニアの人件費が溶けているとき
これが最大の判断基準です。「あれ、このエラーっていつから起きてるんだっけ？」とログの海を数時間さまよっているエンジニアの時間給を計算してみてください。
Sentryの有料プラン（Error Searchの高度化や、Session Replayによるユーザー操作の再現機能など）を使うことで、その調査時間が「3秒」に短縮されるとしたら、月額のコストは一瞬で回収できます。
—
まとめ
Sentryは、正しく設定すればあなたの開発ライフを劇的に楽にしてくれる「最高の相棒」です。
- Freeプランは「サンプリング」と「フィルタリング（beforeSend）」で限界まで延命できる。
- ただし、ビジネスの成長やチーム拡大に伴う「投資」としての有料プラン移行を恐れない。
「とりあえず動くHelloWorld」から一歩進んで、プロダクトの規模に合わせた適切なオブザーバビリティの設計を今日から始めてみましょう。毎日のエラーチェックが、少し楽しみになりますよ！