【入門編】Sentryの「Release Health」でCrash-Free Users/Sessions率を追跡しアプリの品質をプロダクト指標化する方法 – 運用監視・オブザーバビリティ活用バイブル

こんにちは！アプリケーションのリリース後、「ユーザーは本当に快適に使えているだろうか」「見えないところでエラーが頻発していないか」と、夜も眠れなくなるような不安に襲われたことはありませんか？

ログを見に行っても、エラーが洪水のように流れてきて「どれが本当のクリティカルな問題か分からない……」なんて状態になっていれば黄色信号です。

今回は、そんなエンジニアの不安を綺麗さっぱり解消し、さらにプロダクトの品質をビジネスチームとも共通言語で語れるようにする魔法の機能――Sentryの「Release Health（リリースヘルス）」について、徹底的に解説していきます。

これをマスターすれば、単なる「エラーのログ収集ツール」だったSentryが、「ビジネスの信頼性を守る最強の品質ダッシュボード」に生まれ変わりますよ。さあ、一緒に扉を開けていきましょう！

—

1. そもそも「Release Health」とは何か？

多くの開発チームは、「エラーログが出たかどうか」でシステムの健康状態を測りがちです。しかし、ユーザー視点に立ってみてください。

  • 「エラーログが出ていなくても、画面が真っ白になってアプリが強制終了（クラッシュ）している」
  • 「APIのレスポンスが遅すぎて、ユーザーがセッションを諦めて離脱した」

これらは、単純なエラーログ監視だけでは見抜けない「サイレントな大惨事」です。

そこで登場するのが Release Health です。Release Healthは、デプロイされた「リリース（バージョン単位）」ごとに、以下の2つの指標を自動で追跡・可視化してくれます。

1. Crash-Free Users（クラッシュフリーユーザー率）: そのバージョンを使っていて、一度もクラッシュに遭遇しなかったユーザーの割合（目標は通常 99% 以上！）。
2. Crash-Free Sessions（クラッシュフリーセッション数/率）: アプリの起動やセッションの中で、クラッシュしなかった割合。

これによって、「新しいバージョンをリリースした途端に、ユーザーのクラッシュ率が95%まで落ち込んだぞ。すぐにロールバックしよう！」といった、データに基づいた冷静な判断が瞬時にできるようになります。

—

2. 導入のステップ：最短でRelease Healthを有効化する

「難しそうな設定が必要なんでしょ？」と思うかもしれませんが、ご安心を。SentryのSDKを正しく導入していれば、数行のコードを追加するだけで、この高度な計測が動き始めます。

ここでは、モダンなWebアプリケーション（例：React / Vue / Node.jsなど）で一般的に使われるSentry SDKをベースに、最も確実な基礎セットアップを解説します。

ステップ①：SDKのインストールと初期化

まずはプロジェクトにSentryのSDKをインストールします（ここではJavaScript/TypeScriptを例にします）。

npm install –save @sentry/node # バックエンドの場合
または
npm install –save @sentry/react # フロントエンドの場合

そして、アプリケーションのエントリーポイント（起動時）で初期化を行います。ここでのポイントは、`release`（リリースバージョン）を明示的に指定することです。これが抜けていると、Release Healthは機能しません。

import as Sentry from “@sentry/node”;

Sentry.init({
dsn: “https://your-public-dsn@o00000.ingest.sentry.io/0000000”,

// 【超重要】CI/CDパイプラインから渡す環境変数や、Gitのコミットハッシュなどを指定します
release: “my-cool-app@1.2.0”,

// リリースヘルスの心臓部：セッションの追跡を有効化します
// 自動的にセッションの開始・終了・クラッシュをカウントしてくれます
autoSessionTracking: true,

// パフォーマンスモニタリングのサンプルレート（必要に応じて調整）
tracesSampleRate: 1.0,
});

> 先輩からのアドバイス：
> `release` の文字列は、Gitのコミットハッシュや、`package.json` のバージョンと完全に一致させておいてください。Sentryのリリース管理機能と綺麗に紐づき、後々「どのコミットがバグを生んだのか」が秒速で特定できるようになります。

—

3. 精度高い「HelloWorld的な動作確認」をしてみる

設定が終わったら、本当にセッションがカウントされ、Release Healthにデータが届いているかをテスト（HelloWorld的確認）してみましょう。

ローカル環境で以下のスクリプトを実行し、意図的にクラッシュを発生させてみます。

// test-health.js
const Sentry = require(“@sentry/node”);

Sentry.init({
dsn: “YOUR_DSN”,
release: “my-cool-app@1.2.0”,
autoSessionTracking: true,
});

console.log(“アプリが起動しました（セッション開始）”);

setTimeout(() => {
try {
// 意図的なクラッシュ（未定義の関数を呼び出す）
nonExistentFunction();
} catch (error) {
// エラーをキャプチャしつつ、クラッシュとしてSentryに送信
Sentry.captureException(error);

// セッションを強制終了扱いにする場合などの処理
console.error(“アプリがクラッシュしました！”);
}
}, 2000);

このスクリプトを実行後、Sentryのダッシュボード（Releases ＞ 対象のバージョン）を開いてみてください。

数分以内に、次のようなデータが反映されます。

  • Sessions: 1
  • Crash-Free Sessions: 0%（クラッシュしたため）
  • Users: 1

これが確認できれば、あなたのアプリケーションは完璧にRelease Healthの計測体制に入っています！

—

4. 開発チームからビジネス側へ：品質を「プロダクト指標」に昇華させる術

さて、ここからが本題であり、一番ワクワクするパートです。
多くの現場で、エンジニアは「バグを直したい」、プロダクトマネージャー（PdM）や経営陣は「新機能を早く出してほしい」と、視点の違いで衝突しがちですよね。

ここで Crash-Free Users率 を共通のKPI（重要業績評価指標）として使いましょう。

① 「99.9%」をチームの共通合意にする

「バグゼロ」を目指すのは不可能です。しかし、「ユーザーベースで99.9%以上の人が、クラッシュせずにアプリを利用できている状態を維持する」という目標は、エンジニアにもビジネス側にも非常に分かりやすいゴールです。

  • ビジネス側へのメリット: 「今月は新機能開発にリソースを全振りしたが、Crash-Free Users率が99.5%まで下がってしまった。来スプリントは品質改善（バグ修正・リファクタリング）を優先しよう」と、数字を根拠に優先順位を議論できるようになります。
  • エンジニアへのメリット: 単なる「作業としてのバグ修正」ではなく、「プロダクトの信頼性（KPI）を守るためのエンジニアリング」として誇りを持って取り組めます。

② リリースゲートとしての活用

CI/CDパイプラインにSentryのCLIを組み込み、「前回のリリースと比較して、Crash-Free率が著しく低い場合は自動でアラートを飛ばす、あるいはステージングでのテストを失敗させる」という仕組みを作ることも可能です。

品質を個人の注意力に頼るのではなく、「システムと数字で担保する」状態を作ることができます。

—

まとめ

今回は、Sentryの「Release Health」を使って、アプリの品質をプロダクト指標化する方法を解説しました。

  • Release Health を使えば、エラーログだけでは見えない「ユーザーの本当の快適さ（Crash-Free Users/Sessions）」が可視化される。
  • 設定は `autoSessionTracking: true` と適切な `release` 名を指定するだけで非常にシンプル。
  • この指標を開発チームとビジネスチームの共通言語にすることで、機能開発と品質改善のバランスを美しく保てるようになる。

これをマスターすれば、毎日のリリースに対する恐怖感が薄れ、「よし、今日もユーザーに最高の体験を届けるぞ！」という純粋なワクワク感に満たされるはずです。

あなたのプロダクトが、より多くのユーザーに愛される安定したシステムになることを、心から応援しています！

スポンサーリンク
タイトルとURLをコピーしました