こんにちは、menu クルーチームでリードエンジニアをしている坂井田です。

プロダクトのリリース日、皆さんはどのようなスケジュールを立てていますでしょうか。

「デプロイボタンを押して完了！」といけば最高ですが、、、そう甘くないのも現実です😔

リリース直後は、予期せぬ不具合や環境依存のエラーが潜んでいないか、最も神経を尖らせる時間帯です。

そんな時、私たちフロントエンジニアの生命線となるのが Sentry！
（サービスで発生したエラーを収集・監視するトラッキングツール）

ただ、Sentryを導入していても通知チャンネルに流れてくるログを「なんとなく眺める」だけになっていませんか？

今回は、リリース直後の緊迫した状況下で、ノイズを除去し、本当に直すべきクリティカルな問題を秒速で特定するための調査テクニックをまとめました。

今後のエラー調査時の参考になりますと幸いです。

🪏 検索クエリで「今、見るべきもの」だけを抽出する

リリース直後はログの量がスパイクしがちです。

調査の第一歩は、膨大なログの中から「今回のリリースに関連するもの」だけを炙り出すフィルタリングです。

[ 基本 ] 環境での絞り込み

まず最初に行うのが、本番環境への絞り込みです。

開発環境や検証環境のエラーが混ざると、判断のノイズになるためです。

検索バーに以下を入力することで、商用以外のエラーが検索結果から除外されます。

environment:production

Tip: 除外検索を活用する
逆に「商用のエラーだけ除外したい」というケースの場合は、先頭に ! を付けるとそれ以外のものに絞ることができます。

!environment:production

Sentryの検索バーにこのテキストをコピペすると、画像のようになりフィルターとして認識されます。

または、ここにあるフィルターを選択して、絞り込みたい環境にチェックを入れても同じことが可能です。

これで、監視中のノイズを消しつつ、検証環境と本番環境の傾向を別々に見るといった柔軟な動きが可能になります。

[ 応用 ] アプリバージョン / OTA での絞り込み

モバイルアプリで Expo などのOTAアップデートを行った場合、バイナリのバージョンは変わらず、JSバンドルのIDだけが変わります。

もしアプリを ReactNative で開発していて @sentry/react-native パッケージを導入している場合は、該当のOTAアップデートに絞って検索することができます。

release: アプリのバージョン（例: 1.0.0）
ota_updates: OTAアップデートのID

特定のアプリバージョンに絞って検索する場合は、これを条件に追加します。

これを活用することで、「ユーザーがまだ古いアプリをそのまま使っているだけ」というパターンを即座に見抜くことができます。

release.version:1.0.0

「OTAでリリースしたはずの修正が効いていない？」と思った時は、これを条件に追加します。

ota_updates.update_id:{your-update-id}

OTAのIDは、Expo の場合 Update group の画面から Android と iOS のIDをそれぞれコピーすることができます。

これにより、特定のOTAアップデート配信後に発生したエラーのみを抽出することができ、より精密な調査が可能になります。

🔎 エラー内容を「狙い撃ち」で検索する

「カスタマーサポートチームから『〇〇画面でエラーが出る』という報告が上がってきた」
このようなあたりがついている状況では、テキストでの検索よりもフィールドを指定した検索の方がより特定しやすくなります。

テキスト検索の精度を上げる

単にテキストを入れるだけだと、メッセージ本文やスタックトレース内の細かい文字列までヒットしてしまったり、記号などが入っていると正しく認識されないことがあります。

そのため title や message を使いましょう。

検索結果の項目において太字で表示されている部分が title、その下にあるテキストが message に該当します。

title:"NullPointerException"

message:"type"

ワイルドカード * も使えます。

「Arguments」関連のエラーをすべて確認したい場合は以下のようになります。

title:"*Arguments*"

これで PaymentController.process も PaymentController.validate も全て引っ掛けることができます。

特定のユーザーや条件を探す

「特定のユーザーでだけ起きているらしい」

この場合は、user.id タグで検索することができます。

user.id:12345

※ Sentry.setUser を設定している場合のみ有効です

これにより、そのユーザーが遭遇したエラーの時系列を追うことができ、再現手順の特定に繋がります。

🧐 「これはヤバいエラーか？」を瞬時に見分ける視点

SentryのIssue一覧に大量のエラーが並ぶことがありますが、全てに対応することはなかなか難しいです。

優先度判断のための「見るべきポイント」をご紹介します。

スパークラインの形状を見る

Issueリストの各行には、直近の発生推移を示す小さな棒グラフが表示されているため、ここを見ると緊急度が分かります。

右肩上がりのグラフ / 突然現れたグラフ
- 危険度：高 🔥
- 今回のリリースで混入した新規バグ、または影響範囲が拡大しているエラーです
- 最優先で確認します
ずっと平坦なグラフ
- 危険度：中〜低
- 以前から継続的に発生しているエラーです
- リリース起因ではない可能性が高いですが、修正が必要なものかどうかは改めて相談する必要があるかもしれません
- もしこのリリースで改善する予定だったエラーがこの状態であれば、うまく修正が効いていない可能性があるため方針を検討する必要がありそうです
断続的なグラフ
- 危険度：低
- 特定の操作や、特定の機種でのみ発生している可能性があります
- サービスへの影響度はそこまでないものと思われますが、内容によっては今後の発生数に変化がないかどうかを見守った方がいいかもしれません

ソート順を使いこなす

内容によりますが、「1人が100回エラーを出している」のと「100人が1回ずつエラーを出している」のでは、ビジネスインパクトが変わってきます。

デフォルトの「新しい順」以外にも、状況に応じてソート順を切り替えましょう。

イベント
- 発生件数の多い順
- 「1人が100回エラーを出している」パターンを見つけるのに有効
- レンダリング周りにバグがあったり、特定の条件で発生するエラーはここに潜んでいるかもしれません
ユーザー
- 影響ユーザー数の多い順
- 「100人が1回ずつエラーを出している」パターンを見つけるのに有効
- リリースの影響判断には、このソートがおすすめです

🔗 URL共有時の「落とし穴」と、正しいお作法

調査が進み、「原因はこれです！」とSlackやGitHubのコメントにURLを貼るシーン。

ここで私含め、やってしまいがちなことがあります。。😨

Sentry Issue を開いた直後のURLをそのままコピペする

なぜダメなのか？

Sentryは似たようなエラーを自動的にグルーピングして、ひとつの Issue にまとめます。

しかし、このグルーピングは完璧ではない場合があります。

全く別の原因のエラーが、たまたま似ていたために同じIssueにまとめられる
逆に、同じエラーなのに別Issueとして扱われる

Issue ID のみのURLを共有すると、相手が見たタイミングでは最新のイベントが表示されます。

そのため、例えば以下の画像のように、「上で表示されている内容と Stack Trace 欄で表示されている内容が違っている」といった現象が発生する場合があります！

Stack Trace 欄にはURLを開いたときの最新のものが表示されるため、開くタイミングによっては違うものが表示されてしまいます

もしそこに別のエラーが混入して最新になっていた場合、相手は「え？これ全然関係ないエラーじゃない？」と混乱することになってしまいます。

正しい共有方法「Event IDを含める」

「私が今見ているこのスタックトレースを見てほしい」という場合は、必ず個別の Event ID を含めたURLを共有してください。

Issue詳細ページを開く
「Share Issue」ボタンを押す
ダイアログで「Include Event ID in link」にチェックが入っていることを確認し、「Copy Link」ボタンを押す

これで以下のような形式のURLがコピーされるので、これを共有することで時間が経過しても同じエラーを見ることができます。

https://******.sentry.io/issues/******/events/<Event ID>/

また、他のタイミングのエラーを確認・共有したい場合は、イベント欄の右側にある「View More イベント」ボタンを押して、共有したいイベントの「Open link」のURLを共有することでも可能です。

こうすることで、ログが不適切にマージされたとしても、ピンポイントで「その事象」を指し示すことができます。

認識齟齬を減らすためにも、マナー的に抑えておきたいです💡

📊 ダッシュボード機能を活用し、「点」ではなく「面」で監視する

毎回クエリを手打ちするのは効率が悪いです。

Sentry の Dashboards 機能を使い、リリースの健全性を一目でわかるようにしておきましょう。

現在弊社で使用しているウィジェット構成を紹介します。

リリース監視当番の報告対象Issue

弊社ではリリースを行う日は、エラーを監視するメンバーを当番制で決めています。

割と多めに記録されているエラーを一覧で表示するようにしています。

危ない！Unhandled

ハンドリングされていないエラーはアプリの強制終了に繋がってしまうため、特に注視するようにしています。

そのためこちらは件数のしきい値を低くして、エラーを取りこぼさないように確認できるようにしています。

デグレしたIssue

以前改善したものが再発するパターンはリリース前の検証ですべてを網羅することが難しいため、こちらで確認できるようにしています。

弊社ではこれらを参考に、フロントエンドチームで話し合って優先順位を確認した後に、対応するものはタスクとして事業チーム側に提案するフローをとっています。

ダッシュボードに表示する項目やフィルターに設定しているしきい値は、随時チームで相談してアップデートしていく予定です。

🏁 まとめ

Sentry をうまく活用して、予期せぬ事象に気づきやすくなる体制を作っていきましょう！

要点

環境の絞り込みや検索フィルター で事象を特定する
スパークラインとソート でインパクトを測る
URL共有時は Event ID で誤解を防ぐ
Dashboard で定点観測する

▼ 新卒エンジニア研修のご紹介

レアゾン・ホールディングスでは、2025年新卒エンジニア研修にて「個のスキル」と「チーム開発力」の両立を重視した育成に取り組んでいます。

実際の研修の様子や、若手エンジニアの成長ストーリーは以下の記事で詳しくご紹介していますので、ぜひご覧ください！

▼ 採用情報

レアゾン・ホールディングスは、「世界一の企業へ」というビジョンを掲げ、「新しい"当たり前"を作り続ける」というミッションを推進しています。

現在、エンジニア採用を積極的に行っておりますので、ご興味をお持ちいただけましたら、ぜひ下記リンクからご応募ください。