障害管理における情報設計の重要性

Last updated at 2025-09-16Posted at 2025-09-16

自分の今の仕事の一つがお客さん先の障害管理なんですが、例外をそもそもどう管理するかといったことについてまとめてみようかと思います。

システムをリリースした後の運用段階では、定期的にバグ報告が上がってくることは避けられません。
本来はリリース前に完璧な検収テストを行うべきですが、現実的には時間的余裕がないことも多いため、効果的なエラーハンドリング→監視や検知が重要になります。

運用時のエラー処理ですが以下のような点が重要だと思われます。：

予算に余裕がなかったり、プロジェクト自体が実験的だったりすると、お客さんからの報告を受けて直すということが多くなりがちですが(昔ようやってました)、そうならずに能動的に対処できるのが理想です。

情報のアウトプット

エラー出力の基本方針ですが、「誰に」「どんな情報を」伝えるかを明確にする必要があります。
要は普通の文章と同じで情報をうけとる相手の想定がまず大事になってきます。

たとえばそのシステムを使っている一般ユーザーとシステム管理者ではシステムに対する権限もリテラシーも全く違います。

対象者別の情報設計:

対象者	提供する情報	例
システム使用者	操作上の端的でわかりやすい情報	「在庫が不足しています」
システム運用者	障害の詳細な情報	スタックトレース、PG上の重要な情報

ざっくりわけると一般ユーザーには内部情報は伝えず、あくまでシステム操作をする上でわかる情報のみ伝えます。
逆に、システム運用者にはシステムの詳細な情報がわからなければいけないので、障害の詳細な情報が必要になります。

ただユーザーに伝える際にはエラーが発生しました、など操作上のミスを特定できないもの、あるいは操作がおかしくないものもあります。
ユーザーにStackTraceを見せるためにはいかないのですが、問い合わせの際の不具合報告を円滑にするためにもエラーコードなどを埋め込んでおくのはいいかもしれません。

観点としては

エラーをログに吐き出す選択肢も

多くの方がなんらかのクラウド系のログサービスでログを追っていると思いますが、ERRORレベルに限っても都度サービスをみるのは現実的ではないです。
一般的にはエラー時に発報して告知するようなサービスを同時に使っている方が多いと思います。

私が以前いた現場ではSentryというサービスを使っており、Exceptionをキャッチした際に告知してくれて、基本的には不具合をここで管理していました。

Sentry（ https://sentry.io ）は、エラーが発生した際に自動的にエラーを記録・通知してくれるサービスです。

Sentryの主な利点:

推奨する組み合わせ:
Sentryをメインとしつつ、CloudWatchのようなログサービスを併用する構成が効果的です。「エラーは出ていないが動作がおかしい」ような状況では、生ログの確認が必要になるケースが多いためです。

また不具合の検知などであるあるなのが、発報されるエラーの量が多すぎて、確認できず、結局見なくなる・・のようなことです。

どうしても見なくてはいけない、クリティカルなものは発報する必要がありますが、例えばバリデーションエラーのようなユーザーが自覚できて、すぐに対応できそうなものは例えExceptionにするにしても、告知不要でしょう。

またエラーのレベルでも２、３段階に分けて、超緊急的なものと時間を分けて対応しても良いものに分けてもよいでしょう。

運用にあわせて発報レベルを抑えておきましょう。