# オブザーバビリティとは？監視との違いと導入の進め方を解説 URL: https://upstreamapi.com/ja/journal/observability-towa Type: blog Locale: ja Published: 2026-11-14 Updated: 2026-11-14 --- > 監視で異常に気づいた後に、原因を突き止めるための考え方を整理しました。3つのシグナル、カーディナリティ、コスト、ツールの選び方と始め方をまとめています。 オブザーバビリティとは、システムがすでに出力しているテレメトリだけを使って、想定外の振る舞いの理由を説明できる能力のことです。事前に予想できなかった障害にも対応できる点が、監視との大きな違いです。 監視は「チェックアウトの遅延が800msを超えた」と教えてくれます。オブザーバビリティは、「どの顧客で、どの依存先で、どのデプロイが原因か」を、夜中の3時に新しいコードを出して確かめなくても答えてくれます。 具体的な場面で考えてみます。アラートが鳴り、決済APIのp99が180msから1.4sに上昇しています。ダッシュボードのCPU、メモリ、エラー率はすべて正常です。事前に用意されたパネルはどれも「問題ない」と示していますが、顧客からは「問題がある」と連絡が来ています。この後の10分間にやることが、この記事の主題です。 ## なぜ、ツールより先に定義が重要なのか この言葉は制御理論に由来します。システムの外部への出力から内部の状態を推定できるなら、そのシステムは観測可能だとされます。ソフトウェアの世界では、ベンダーがこの言葉を広げて「ダッシュボード製品」の意味にまでしてしまいました。その広がりは無視してください。 エンジニアリングチームにとって実用的な定義は、もっと狭く、もっと役に立ちます。本番環境で新しい計測を追加せずに、システムの振る舞いについて新しい問いに答えられるなら、そのシステムは観測可能です。鍵になるのは「新しい」という言葉です。しきい値アラートが答えるのは、先四半期に誰かが書いた問いだけです。観測可能なシステムは、今まさに投げている問いに答えます。 これは純粋さを競うテストではありません。完璧に観測可能なシステムを持つチームは存在せず、目指すべきはスコアではありません。目指すのは「何かがおかしい」から「この変更が原因だ」までの道のりを短くすることです。検知までの平均時間と、理解までの平均時間は別の数字ですが、多くのチームは前者しか追っていません。 ![Whiteboard sketch of services connected by arrows](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/3a5d62-i1.webp) ## オブザーバビリティとモニタリングは何が違うのか モニタリングは、既に知っている障害パターンに対する確認の仕組みです。CPUが5分間90%を超えた、エラー率が1%を超えた、キューの深さが10,000を超えた、といった形で表現されます。安価で信頼性が高く、今後も必要です。オブザーバビリティがそれを置き換えるわけではありません。 違いが出るのは、未知の障害に遭遇したときです。モニタリングは過去のインシデントから作られます。オブザーバビリティは、定義上まだ見たことのない次のインシデントに備えて作られます。 簡単なテストがあります。直近の3件のインシデントで、根本原因がどう見つかったかを振り返ってください。 - 既存のダッシュボードを見て答えが映っていたなら、それはモニタリングが役目を果たした例です。 - 複数のホストでログを検索し、仮説を立て、ログ行を追加して再デプロイし、確かめたのなら、それはオブザーバビリティの欠落です。 - 本当の答えが顧客のスクリーンショットから来ていたなら、両方の問題があります。 両者が対立するものかどうかを議論する必要はありません。両者は層です。モニタリングは煙感知器で、オブザーバビリティは火事のあとで建物を歩き回り、どの回路から火が出たのかを突き止める能力です。 ## 3つのシグナルはそれぞれ、どこで破綻するのか ログ、メトリクス、トレースが標準的な3点セットです。それぞれ異なる問いに答えますが、ベンダーのガイドがよく省く失敗モードがあります。 **メトリクス**は、時間で集計された数値です。リクエスト数、エラー率、レイテンシのパーセンタイル、飽和度などが該当します。保存コストが低くクエリも速いので、アラートはメトリクスの上に作られます。失敗モードは集計です。p99が1.4sだと、何かが遅いことはわかりますが、遅いリクエストがすべて1つの顧客の1つのシャードに属することまではわかりません。 **ログ**は、個別のイベントをタイムスタンプ付きで記録したものです。最も詳細ですが、意図的に構造を与えない限り構造は最小限です。失敗モードは量とコストです。構造化されていないログは、どの文字列を探せばよいかを既に知っている人にしか検索できず、デバッグ用の道具を装った監視ツールになってしまいます。 **トレース**は、1つのリクエストを複数のサービス境界をまたいで追跡し、各ホップのスパンと所要時間を記録します。リクエストの形を見せてくれる唯一のシグナルです。「この呼び出しは下流の依存先で900ms待ち、3回リトライされた」といったことがわかります。失敗モードはカバレッジです。1つのサービスがトレースのコンテキストを落とすと鎖が切れます。穴の空いたトレースは、正しそうに見えるぶん、役に立たないどころか有害です。 3つを揃えているだけでは、オブザーバブルであることにはなりません。重要なのは相関です。メトリクスのスパイクから、それに寄与したトレースへ移動でき、そのトレースの特定のリクエストのログへも移動できる必要があります。3つが共通の識別子なしに別々のツールにあるなら、それは3つの監視システムと、その間をつなぐ人間にすぎません。 ## カーディナリティが、デバッグできるかどうかを決めるのはなぜか カーディナリティとは、フィールドが取りうる異なる値の数のことです。status_codeはおよそ20種類程度ですが、customer_idは数十万種類になり得ます。request_idはリクエストごとに1つです。 インシデントの最中に最も必要になるのは、多くの場合こうした高カーディナリティのフィールドです。「どの顧客が影響を受けているか」は customer_id の問いです。「遅いリクエストがどのビルドで動いているか」は deploy_version の問いです。ストレージが高カーディナリティのフィールドを、ユニークな系列ごとの課金で罰したり、黙って捨てたりするなら、インシデントを解く問いに答えられなくなります。 ここが、メトリクスだけの構成と観測可能な構成の本当のアーキテクチャ上の境界です。事前集計されたメトリクスは、後で必要になる次元を捨ててしまいます。幅広い構造化イベントは次元を残すので、後からスライスできます。 サービスの境界で、リクエストごとに構造化レコードを1つ出す例を示します。後から関心を持つはずのあらゆる軸でスライスできるだけの文脈を含めています。 `logger.info("request.completed", { trace_id: span.traceId, route: "/v1/payments", customer_id: ctx.customerId, deploy_version: process.env.BUILD_SHA, flag_variant: flags.get("new-ledger-path"), db_ms: timings.db, upstream_ms: timings.upstream, status: res.statusCode, duration_ms: elapsed, });`機能フラグの評価値がイベントに入っている点に注目してください。公開されているポストモーテムで見られるインシデントの半数は、何らかの変更から始まっています。フラグの評価も変更の一種です。バリアントがイベントに入っていなければ、遅いリクエストが新しい経路に乗っているのかどうかを問えません。 ![Desk with a laptop showing a latency dashboard](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/c95a59-i2.webp) ## インシデントは、あるときとないときでどう違うのか 決済の例を、もう一度同じ場面で考えます。同じアラート、同じ1.4sのp99です。 オブザーバビリティがない場合、作業の流れは次のようになります。サービスのダッシュボードを開くが何もない。データベースのダッシュボードを開くが何もない。インシデントのチャンネルで、何かデプロイされたかを尋ねる。誰かが設定変更を思い出し、別の誰かがそれは違うと言う。40分ほど経ってから直近のデプロイを巻き戻して効果を確かめるが、効果はありません。原因は、一部のテナントに対する機能フラグの段階的ロールアウトだったからです。 オブザーバビリティがある場合、作業の流れは次のようになります。遅いリクエストを flag_variant でグループ化すると、100%が new-ledger-path に乗っていることがわかります。customer_id でグループ化すると、大口の3テナントが大半の量を占めています。1つのトレースを開くと、台帳の呼び出しが40本の逐次クエリに展開されているのが見えます。かかる時間は数分です。止めるべきはデプロイではなく、フラグです。 2つ目の流れで不要だったものに注目してください。事前に用意されたダッシュボードも、「フラグのバリアント」を誰かが重要な次元として事前に予測することも必要ありませんでした。必要だったのは、データが幅広く、クエリ可能な形で残っていることだけです。 これがHoneycombの主張を1段落にまとめたものであり、その主張は成り立ちます。ただし、タダでできるとは言っていません。 ## コストはどれくらいか、そして高価な構成を避けるべきなのは誰か テレメトリは、ツールの問題である前にデータ量の問題です。[Grafana Labsの2025年オブザーバビリティ調査（回答者1,255人）](https://grafana.com/blog/2025/03/25/observability-survey-takeaways)によると、組織は平均して8種類のオブザーバビリティツールを使っており、新しいツールを選ぶ際に最も多く挙げられる基準はコストです。この2つの事実はつながっています。各ツールは部分的な問題を解くために増えていき、その結果、重複する取り込みに料金を払うことになるのです。 多くのチーム規模で当てはまる実践的なルールは次のとおりです。 - **独自のエージェントではなくOpenTelemetryで計装する。** コレクターなら、サンプリング、フィルタリング、ルーティングを1か所で担えます。バックエンドを変えるのは、再計装のプロジェクトではなく設定の変更で済みます。 - **トレースは意図的にサンプリングする。** エラーと遅いリクエストは全件残し、正常で速いものだけをサンプリングします。一律1%のヘッドベースのサンプリングは、まさに必要なトレースを捨ててしまいます。 - **ログは書き込み時に構造を与える。** クエリ時に自由形式のテキストをパースするのは、フィールドを得る高コストな方法です。 - **シグナルごとに保持期間を決める。** メトリクスは1年、広いイベントは2週間、デバッグログは3日。先四半期のデバッグログが必要になった人はいません。 サービスの数が少なく、オンコールのローテーションが1つだけなら、フルプラットフォームは不要なことが多いです。小さなチームは、構造化ログ、RED指標、主要な経路2〜3本のトレースだけで、多くの恩恵を得られます。全部入りの高額な契約が元を取るのは、誰もトポロジー全体を頭に入れておけないほどサービスが増えたときです。私たちの経験では、おおむね30〜40サービスを超えたあたりです。 ## 検討する価値のあるツールは？ ツールの選択は、自前でどこまで運用したいか、カーディナリティの形、請求額に耐えられるかどうかで決まります。率直な比較を示します。 Datadogは最も幅広い商用の選択肢です。メトリクス、ログ、トレース、プロファイリングを1つにまとめ、それぞれの相関も強力です。その統合の代償は、ホスト数、カスタムメトリクス、取り込むログ量に比例して増える請求額です。1社にまとめたく、予算も見合うなら価値があります。契約前にカスタムメトリクスの項目を確認してください。 Grafanaは、オープンなコンポーネントを自前でホストするか、マネージドスタックとして購入したい場合の定番です。Prometheus系のメトリクスやOpenTelemetryのパイプラインとよく合います。代償は運用面です。組み立ての多くを自分で担うことになり、上で触れたツールの乱立は、あなたの環境にも当てはまります。 SigNozは、OpenTelemetryネイティブのオープンソース製品で、ログ、メトリクス、トレースを1つのデータストアにまとめます。前半で述べた相関の点で重要です。共有ストアがあれば、メトリクスからトレース、そしてログへの移動はタブの切り替えではなく、1回のクエリになるからです。4つのプロジェクトを組み合わせずにセルフホストしたいチームには妥当な選択です。 Better Stackは、稼働監視、インシデントのアラート、ログ管理を、小規模チーム向けの価格で組み合わせています。「顧客に指摘されて気づく」状態から体系的な運用へ移る最初の一歩として妥当です。大規模なサービスメッシュで、トレースの要件が重いケースにはあまり向きません。 ![Data center aisle with status lights](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/63d34b-i3.webp) ## 巨大なプロジェクトにせず、どう始めるか ツールの評価から始めてはいけません。直近の3件のインシデントを振り返り、率直な問いから始めてください。「あのとき、何を問えたらよかったのか」。 50〜200人規模のチームで機能する手順は次のとおりです。 - **重要なリクエストの経路を1つ選び、OpenTelemetryでエンドツーエンドに計装する。** チェックアウトでも、ログインでも、夜中の3時に自分を起こすものなら何でも構いません。 - **サービスの境界で、リクエストごとに広い構造化イベントを1つ出す。** 顧客、バージョン、フラグのバリアント、下流の所要時間を含めます。 - **その経路にSLOを1つ定義し、生のしきい値ではなくバーンレートでアラートする。** バーンレートのアラートはユーザーへの影響でページングし、手順2のテレメトリがその理由を教えてくれます。 - **ゲームデーを実施する。** まだアラートを設定していない障害を注入し、コードを書いていない人がそれを見つけるまでにどれだけかかるかを測ります。その数字があなたのベースラインです。 - **最初の経路が実際のインシデントで価値を証明してから、1本ずつ外へ広げる。** オブザーバビリティは、プラットフォームとして購入され、習慣として定着します。その習慣とは、インシデントの最中ではなく、コードレビューの段階で「これを説明するには何を知っておく必要があるか」と問うことです。 直近のインシデントレビューを見てください。「その後、確認のためにログを追加した」と書かれた文を探してみてください。その一つひとつが、本番環境でシステムが答えられなかった問いです。そのうち何件を記録として残していますか。そして、今日でも答えられないものはどれでしょうか。 ## FAQ ### オブザーバビリティとモニタリングは両立しますか？ はい。モニタリングは既知の障害パターンを検知する仕組みで、オブザーバビリティは未知の障害の原因を調べるための能力です。一般的には層として重ねて使います。 ### オブザーバビリティは何から始めればよいですか？ 直近3件のインシデントを振り返り、重要なリクエストの経路を1つ選んで、OpenTelemetryで計装するところから始めます。最初から全体のツール選定をする必要はありません。 ### 3つのシグナルとは何ですか？ メトリクス、ログ、トレースです。メトリクスは集計された数値、ログは個別イベントの記録、トレースは1つのリクエストが複数のサービスをどう通ったかを示します。 ### カーディナリティとは何ですか？ フィールドが取りうる異なる値の数のことです。status_codeは約20種類ですが、customer_idは数十万種類になることがあります。インシデント調査では、高カーディナリティのフィールドが特に重要です。 ### 小規模なチームにもフルプラットフォームは必要ですか？ 必要ないことが多いです。サービスが数個で、オンコールのローテーションが1つだけなら、構造化ログ、RED指標、主要な経路のトレースで十分な効果が得られます。 ### 主なツールはどう違いますか？ Datadogは統合型の商用製品、Grafanaはオープンなコンポーネントを自前で運用するか管理サービスとして使う構成、SigNozはOpenTelemetryネイティブでオープンソースの統合ストア、Better Stackは小規模チーム向けの監視とログ管理です。