オブザーバビリティとは？ 開発チームのための実践ガイド

深夜2時、チェックアウトのAPIが20回に1回ほどの割合で500エラーを返しているのに、ダッシュボードはすべて正常を示しています。「システムは問題ないと言っている」と「ユーザーは壊れていると言っている」のあいだにあるこのギャップを埋めるためにあるのが、オブザーバビリティです。オブザーバビリティとは？ システムが出力するデータ（ログ、メトリクス、トレース）を見て、システムの内部で何が起きているかを理解する能力のことです。事前に計画していなかった質問にも答えられる状態を指します。

この最後の一節がこの記事の要点です。ほかの部分はすべて詳細です。

オブザーバビリティと監視の違い：設定していないアラートへの答え

監視は、すでに知っている問いに答えます。CPUが90%を超えていないか。エラー率が2%を超えていないか。キューの深さが増えていないか。監視する指標を選び、しきい値を設定すると、それを超えたときにページャーが鳴ります。

オブザーバビリティは、まだ知らなかった問いに答えます。特定のテナントで、特定のアプリのバージョンで、ある特定のデプロイの後だけリクエストが4秒遅くなるのはなぜか。誰もそれを予測していなかったので、そのためのアラートは存在しません。

つまり両者は対立するものではありません。監視はアラートの層であり、オブザーバビリティはアラートが鳴った後、あるいは顧客から問い合わせがあってもアラートが1つも鳴らなかったときに調べるための仕組みです。事前に作られたダッシュボードの壁しかないなら、それは監視です。どの次元でも本番データを切り出せて、新しいコードを出さずに複数のサービスをまたいで1つのリクエストを追えるなら、それがオブザーバビリティです。

3つのシグナル：メトリクス、ログ、トレース

定義はたいてい「3本の柱」から始まります。このラベルは少し堅苦しいものの、3種類のデータは実在し、それぞれ得意な仕事が違います。

• メトリクス は時系列の数値です。リクエストレート、p95レイテンシ、メモリ使用量など。保存コストが低く、クエリが速く、「何かおかしいか」を知るのに向いています。「どのリクエストで、なぜか」は苦手です。

• ログ は個別イベントのタイムスタンプ付きの記録です。決済の失敗、リトライの発生、フィーチャーフラグの切り替えなど。詳細を持ちますが、負荷の高いサービスでは構造化されていないログは干し草の山になります。

• トレース は1つのリクエストが複数のサービスをまたぐ経路を追います。各ホップは開始時刻、所要時間、属性を持つスパンです。分散システムにおける、スタックトレースに最も近いものです。

Grafanaの2025年の調査は、実務者がどこにいるかを示しています。1,255人の回答者を対象としたGrafanaのオブザーバビリティ調査によると、メトリクスを使う人は95%、ログは87%ですが、トレースは57%にとどまります。分散したバグの解決に最も役立つシグナルが、最も多くのチームで導入されていないのです。

「メトリクスは何が起きたかを、ログは理由を、トレースはどこかを教える」という簡単な言い回しは避けましょう。きれいに聞こえますが、実際には失敗します。適切に構造化されたログは、計装の甘いトレースよりも「どこで」について多くを教えてくれることがよくあります。

実際に観測可能なシステムとは

データを出力することは必要条件ですが、十分条件ではありません。システムは、データが次の3つの性質を持つときに観測可能になります。

高いカーディナリティ。 ユーザーID、テナント、ビルドのSHA、リージョン、フィーチャーフラグで絞り込めること。ツールがサービス名やステータスコードで事前集計することを強いるなら、悪い状態にある1つのテナントを見つけることはできません。

シグナル同士をつなぐコンテキスト。 すべてのログ行にトレースIDがあれば、遅いスパンから、そのスパンが出力した正確なログへ移動できます。このリンクがなければ、2つの別々の話を読んで、そのつながりを推測することになります。

役立つだけの詳細さ。ただし支払えない量にはしないこと。 ここでほとんどのチームが苦労します。同じGrafanaの調査では、回答者はあわせて100を超えるツール、サービス、プロジェクトを挙げ、平均的なチームは8つを運用していました。ツールを選ぶ際にはコストが主要な基準でした。すべてを収集するのは簡単です。それに支払うことが、後から分かる部分です。

ここで、OpenTelemetryを使った出発点の例を示します。OpenTelemetryはベンダーに依存しない計装の標準です。以下は、スパンを作成し、深夜2時に必要になる属性を付与する最小限のPythonの例です。

from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result

3つの属性があるかどうかで、「チェックアウトが遅い」と「バージョン3.8.1上のテナント4412でチェックアウトが遅い」の差が生まれます。OpenTelemetryのオブザーバビリティ入門では、この背後にある概念をより深く説明しています。ベンダーが配線を代行している場合でも、一度読んでおく価値があります。

オブザーバビリティツールの違い（そして違わない点）

マーケティングの下では、ほとんどのプラットフォームが同じ3つのシグナルを取り込んでいます。違いは料金モデル、クエリ能力、そしてどこまで計装を代行してくれるかにあります。

• オールインワン型のプラットフォーム はメトリクス、ログ、トレース、アラートなどを1つにまとめています。便利ですが、トラフィックに応じて増える従量課金の請求が伴います。

• オープンソースのスタック（Prometheus、Loki、Tempo、Grafanaなど）は、ホストごとのライセンス料がかからず、制御の自由度があります。その代わり、自分で運用とチューニングを行う必要があります。

• OpenTelemetryネイティブのバックエンド は標準フォーマットを直接受け取るため、ベンダーを変えてもすべてのサービスを計装し直す必要がありません。

Datadogはオールインワン型カテゴリーの基準点です。幅広いカバレッジ、洗練されたUI、そして毎月見直す価値のある請求額があります。ベンダーを1社にまとめたく、予算があるなら検討に値します。コストの予測可能性が最大の制約なら、避けた方がよいでしょう。

Grafanaは実用的なオープンソースの選択肢です。すでに持っているデータの上にダッシュボードを載せて始め、必要になったらログやトレースを追加できます。ある程度のエンジニアリング時間への投資は必要です。

SigNozは最初からOpenTelemetryを中心に作られ、メトリクス、ログ、トレースを1つのオープンソースのインターフェースにまとめています。高額なオールインワンの価格を払わずに、シングルペインの体験を求めるチームにとって妥当な選択です。

New Relicは両者の中間に位置します。ホスト型のプラットフォームと、本格的な評価を行えるだけの無料枠があります。デモではなく、自分のチームが本番環境の実際の問いに、そのツールで答えられるかどうかで判断してください。

どのツールも、それ単独であなたのシステムを観測可能にはしません。ツールはクエリのためのインターフェースにすぎません。計装こそが本体です。

多くのガイドが飛ばす部分：オブザーバビリティはコードの境界で止まる

これらのツールを本格的に使うと、必ず気づくギャップがあります。トレースは、charge_card に3.9秒かかったこと、そして遅い部分が payment_client への呼び出しだったことを教えてくれます。しかし payment_client が実際に何をしているのか、誰が書いたのか、なぜバックオフなしで3回リトライするのかは教えてくれません。

そのためには、オブザーバビリティツールを離れてコードを読みに行く必要があります。小さなサービスなら10分で済みます。4つのチームが所有する10万行のリポジトリでは、読む作業がインシデント対応の中で最も長い部分になることがよくあります。どのスパンが遅いかは正確に分かっていても、そのスパンの背後のコードがどう配線されているかを理解するのに1時間かかるのです。

これは実行時データとソースコードのあいだの引き渡しの問題です。だからこそ私たちは、オブザーバビリティとコード理解を1つのワークフローの2つの半分と考えています。

1. オブザーバビリティは実行時のどこで（どのサービス、どのスパン、どのテナントか）を教えます。

2. コード理解はソースの中のなぜ（どの関数、どのリトライポリシー、どの設定か）を教えます。

この流れを閉じているチーム（スパン名がファイルに対応し、ファイルが担当者と説明に対応している）は、「アラートが鳴った」から「修正の理解が終わった」までの時間を短くできます。これは主にルールの問題です。スパンを関数にちなんで命名し、リポジトリのパスをスパンの属性に入れ、サービスごとに短いアーキテクチャメモを持つことです。そのうえで「支払い呼び出しのリトライポリシーはどこで設定されているか」といった質問に答えられるAIアシスタントがあれば、判断の拠り所になる具体的なものが手に入ります。

オブザーバビリティは機能しないと思わせる3つの間違い

ダッシュボードを目的にすること。 ダッシュボードは古い問いへの保存された答えです。40個も作って、アドホックなクエリを一度も練習しないチームは、きれいなラッパーに包まれた監視を手にしているだけです。インシデントのたびに問いかけましょう。「これはダッシュボードで答えられたのか、それとも生データを探索して答えたのか」。

サンプリングが早すぎる、あるいは一切しないこと。 負荷の高いサービスで100%のトレースを保持すると、すぐに高くつきます。一方で、ランダムに1%だけ残すと、あなたが気にかけている、まれに失敗するリクエストを捨ててしまいます。よく使われる妥協案は、テールベースサンプリングです。遅い、失敗したトレースを残し、正常なものの大半を捨てます。最初の請求書が届く前に決めましょう。

属性名がずれていくこと。 あるサービスは user_id、別のサービスは userId、3つ目は uid と書きます。すると、3つすべてにまたがるべきクエリが全体像の3分の1しか返さなくなります。テナント、ユーザー、バージョン、フラグの属性について小さな命名規則を決め、人が見つけられるようリポジトリに書いておきましょう。

これらはどれもツールの問題ではありません。習慣の問題であり、習慣はベンダーを変えるよりも安く直せます。

一度に全部を計装しない現実的な始め方

今何もないなら、初週にすべてを計装したくなる衝動に抗ってください。5人から50人のエンジニアのチームで機能している手順は次のとおりです。

1. 重要なユーザーフローを1つ選ぶ。 チェックアウト、サインアップ、主要なAPI呼び出しなど。システム全体ではなく。

2. リクエストIDつきの構造化ログを追加する。 JSON形式で、1行に1イベント、すべての行にトレースIDまたはリクエストIDを入れます。

3. そのフローをOpenTelemetryのトレースで計装する。 上の例にあったテナント、バージョン、フラグの属性を含めます。

4. 2つか3つのSLO（サービスレベル目標）を定義する。 例えば、チェックアウトリクエストの99.5%が800ミリ秒未満で成功する、といった具合です。アラートはCPUではなく、これに紐づけます。

5. 1件の実際のインシデントをデータと照らして振り返る。 新しいコードなしで原因を見つけられたか。見つけられなかったなら、そのギャップが次の計装タスクになります。

手順5は飛ばされがちですが、あなたが観測可能かどうかを示す唯一の手順です。ほかのすべては配管工事にすぎません。

私たちならどうするか

チームが20人未満なら、OpenTelemetryの計装と、料金を予測できるバックエンドから始めましょう。計装は持ち運び可能なので、バックエンドの選択は取り消せます。競合が使っているからという理由で、最大のプラットフォームを買うのはやめましょう。

すでにオールインワンのツールに支払っているなら、それを引き剥がす必要はありません。何を取り込んでいるかを監査し、誰もクエリしていないログを削り、節約した分を重要なフローの計装に充ててください。

どちらの道を選ぶにせよ、スパンがどうコードに対応するかを書き留めておいてください。ダッシュボードは火の手を見せてくれます。しかし、なぜ火が出たのかを知るには、誰かがソースを読まなければなりません。