なぜ従来の「監視」では不十分なのか？NewRelicで見るオブザーバビリティ

Posted at 2026-09-18

👀概要

本記事はオブザーバビリティについての概要説明資料です。

わかりづらいオブザーバビリティについて、監視との差を明確にしながらできること・できないこと・全体像を解説します。
後半はNewRelicの画面を例に、オブザーバビリティが達成できた状態を共有します。

以下は本記事の対象外です。

SLI/SLOについての詳細。
費用面。

👨‍👩‍👧‍👦対象者(Who)

📌関連リンク

📝 内容

オブザーバビリティとは?

結論 : オブザーバビリティとは、システム内のあらゆる状態が把握でき、システム障害時のあらゆる疑問を解消できる状態。
そしてその指標を高めるために、障害の発生を事前に予測するのではなくシステム全体から豊富なデータ（メトリクス、イベント、ログ、トレースなど）を常時収集する。

オブザーバビリティ（可観測性）とは、システムから出力されるデータを用いて、その内部状態をどれだけ正確に推測できるかを示す指標です。

参考 : NewRelic オブザーバビリティとは？

背景

現代のシステムは、マイクロサービス、Kubernetes、そして複数のクラウドが混在する環境へと、ますます複雑化しています。
同時に、DevOpsやアジャイル開発の浸透により、ソフトウェアのリリース速度はかつてないほど加速しました。
この「システムの複雑化」と「開発の高速化」という2つの潮流は、問題発生時にその根本原因を迅速に特定することを、極めて困難な課題に変えています。

このような課題を解決する鍵がオブザーバビリティです。
オブザーバビリティは、チームの効率化、システムのプロアクティブな最適化、迅速な問題解決を実現し、これらはすべて組織の収益に直接的な影響を与えます。

監視でいいのでは?と思うかもしれませんが、監視とオブザーバビリティには以下の大きな違いがあります。

監視：既知の問題を把握する。「問題が起きていないか?」に答えられる。
オブザーバビリティ：未知の問題を探求する。「なぜ問題が起きたか?」に答えられる。

これまでは、あらかじめ問題となりそうな箇所（CPU使用率の上昇、ネットワーク帯域幅の逼迫、危ないコードなど）を予測し、そのためのダッシュボードやアラートを設定しておきました。しかし、システムが複雑化すると問題となりそうな箇所の予測も困難になります。

障害の発生を事前に予測するのではなく、システム全体から豊富なデータ（メトリクス、イベント、ログ、トレースなど）を常時収集し、問題が発生した際にどんな問いかけ（質問）もできる状態がオブザーバビリティが達成できた状態です。

※ 以下イメージ図。言語等は一例。

フロントエンドのレイヤー
バックエンドのレイヤー
インフラレイヤー

できること

CPU 使用率、メモリ、リクエスト数、レイテンシなどを把握
サービスレベルの概念を導入し、本質的な問題の検知が可能。
- SLO / SLA / Error Budget のモニタリング
根本原因の深掘りが可能。
- 分散トレーシングでどのサービスが遅いか特定
- どのAPIのどの関数が遅いか？まで追跡可能

Note:サービスレベルとは

ユーザー視点での、サービスのパフォーマンスの指標。サービスを利用するユーザーが期待していることを指標とする

例 : ECサイトのレスポンス時間は一定の閾値内か? を常に確認し、閾値を超えた割合が 99.999...% 以内か?が一目でわかる状態。

できないこと

詳細なビジネスインテリジェンス分析 : アプリケーションのパフォーマンスやインフラの監視は得意ですが、マーケティングデータや売上分析など、BIツールほどの複雑な分析はできません。
詳細なセキュリティ監査・侵入検知 : パフォーマンス監視に特化しているため、専用のセキュリティ監査ツールやIDS（侵入検知システム）のような高度なセキュリティ分析はできません。
深いコードレベルの自動修正や自動最適化 : 問題を検知するのは得意ですが、自動でコードを修正したり最適化したりする機能はありません。

注意点

NewRelicへのデータ転送はインターネット経由であるため、バックエンドサーバーがプライベート環境にある場合はプロキシサーバーの経由/プライベートエンドポイントの経由などの対応が必要です。

NewRelicとは

オブザーバビリティプラットフォームの一種です。
SaaS型のプラットフォームは他にはDatadog（データドッグ）、Dynatrace（ダイナトレース）がありますが、NewRelicは特に、APM(アプリケーションパフォーマンスモニタリング)が非常に強い印象です。

以下NewRelicの画面イメージ

【取得できる項目】サマリ画面

Web合計実行時間
Apdex score(ユーザーの満足度？調査中...)
スループット(処理している作業量。単位はRPM: requests per minute)
エラー発生率（時間単位は調整可能）

【取得できる項目】トランザクション

トランザクション一覧
- どのメソッドが多く呼ばれているか確認可能。

ブレイクダウン
- 一つのトランザクションでどのメソッドが呼ばれているかを確認できる。
- 以下の画像からはPostgreSQLへのアクセスを行っていることがわかる。
- どのトランザクションで時間がかかっているかがわかる。

【取得できる項目】ログ

ログレベル。デフォルトは information〜errorを取得するが、No Status含めPython Agent側の設定の変更で取得可能

【取得できる項目】データベース

発行されているクエリを確認することが可能。
実行速度が遅いクエリに対してクエリの中身を確認することが可能

体験談

ある社内プロダクトで、期間指定（例: 9月1日〜9月30日）の不具合有無を確認してほしいという依頼がありました。ユーザーからの報告は「画面でエラーが出た」という粒度、詳細な再現手順やログの共有はなく、従来の監視では原因の特定が難しい状況でした。
そこで、導入済みのオブザーバビリティ基盤（NewRelic）を活用しました。まず Error Inbox を用いて該当期間のエラーを集約・分類し、影響の大きいトレースを抽出。エラーログの種類が「NetworkError」であることを確認し、さらにセッションリプレイで当時の画面挙動を追ってみると、エラー発生時に適切なポップアップが表示されていることが分かりました。これにより、フロントエンドからバックエンドへの接続に起因するネットワーク系の問題だと合理的に推定できました。

この一連の確認によって、

実際に NetworkError が発生していたこと
UI 上でエラー通知が正しく表示されていたこと

を事実ベースで説明でき、問い合わせ対応の精度と速度が向上しました。特に、ユーザー報告が限定的で情報が不足しがちなケースでも、ログ・トレース・セッションリプレイを横断して「何が起きていたか」を再構成できた点が、オブザーバビリティの価値を強く実感したところです。

なお、この事例はユーザー規模やデータ量が比較的少ないプロダクトでの検証でしたが、Error Inbox や分散トレーシング、セッションリプレイといった機能が、フロントエンド起因の問い合わせにも十分に有効であることを確認できました。オブザーバビリティの「未知の問題に対して、後からでも問いを立てて解像度を上げられる」強みが、現場での意思決定と原因特定を確かなものにしてくれます。

まとめ

オブザーバビリティとは、システムから得られる多種多様なデータ（メトリクス・イベント・ログ・トレース）を常時収集し、未知の問題に対して「なぜ起きたか？」に答えられる状態を目指す考え方。監視が「問題が起きていないか？」に答えるのに対し、オブザーバビリティは根本原因の特定を可能にする。
背景として、マイクロサービス・Kubernetes・マルチクラウド化と、DevOps/アジャイルによる高速リリースにより、問題の予測やダッシュボード前提の運用が困難化。結果として、全スタックからの広範なデータ収集と、発生時に自由に問いを立てられる仕組みが重要。
できることは、リソース可視化（CPU/メモリ/レイテンシ）、サービスレベル監視（SLO/SLA/Error Budget）、分散トレーシングによる根本原因特定（どのサービス/どの関数が遅いか）。一方で、BIの深掘り、セキュリティ監査/侵入検知、コードの自動修正は範囲外。
NewRelicはSaaS型オブザーバビリティプラットフォームの一種で、特にAPMに強み。トランザクション一覧、ブレイクダウン、ログ、DBクエリなどを包括的に可視化し、ボトルネックやエラー原因の特定を支援する。インターネット経由のデータ送信であるため、プライベート環境ではプロキシ/プライベートエンドポイントの設計が必要。
実運用では、Error Inboxやセッションリプレイを活用して、ユーザー報告が乏しいケースでもネットワークエラーの特定やUI上の挙動確認が可能となり、フロントエンド起因の問い合わせに有効だった。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up