オブザーバビリティ（可観測性）とは？監視・APM・テレメトリとの違いと使い分け

オブザーバビリティ（observability、可観測性）とは、システムが外に出すメトリクス・ログ・トレースから、内部で「なぜその状態になったのか」を後から問い直せる性質のことです。決めておいた指標を閾値で見張る監視（モニタリング）と違い、事前に想定していなかった障害の原因まで追えるかどうかが分かれ目になります。なお、広義のモニタリングにはログやトレースを使った原因調査も含まれ両者は重なるため、この記事では比較のために「監視」を指標と閾値による検知に絞って扱います。

この記事では、混同されやすい監視・モニタリング・APM・テレメトリの4語との違いを先に切り分けます。そのうえで3本柱とOpenTelemetryの2026年時点の状況、トレースが途中で切れる原因、監視だけで足りる構成とオブザーバビリティに投資すべき構成の判断基準までを順に扱います。名前の似た「データオブザーバビリティ」は対象が違う別分野なので、中盤で短く切り分けます。

まとめ：オブザーバビリティと監視・APM・テレメトリの違いの要点

• オブザーバビリティは道具ではなくシステムの性質です。出力から内部状態を説明できる度合いを指し、ツールを入れただけでは手に入りません。
• 監視は「何が起きたか」を知らせ、オブザーバビリティは「なぜ起きたか」に答えます。両者は置き換えではなく、検知と原因探索の役割分担です。
• APMはアプリケーション性能の監視・分析を担う領域で、分散トレースや基盤との相関分析も含みます。オブザーバビリティは、それらのデータから内部状態を説明できる性質です。
• テレメトリは材料となるデータそのもので、監視やオブザーバビリティと横並びで選ぶものではありません。
• 計装の標準はOpenTelemetryで、2026年5月21日にCNCFが卒業を発表しました。ただしログのSDKは言語によってまだDevelopmentです。
• 構成が静的で障害の型が分かっているなら監視の作り込みで足ります。障害の切り分けに毎回数時間かかる分散構成なら、トレースから計装する価値があります。

オブザーバビリティ（可観測性）の定義：制御工学の語とIT運用での意味

可観測性はもともと制御工学の用語で、1960年にルドルフ・カルマンが線形の動的システムについて導入した概念です。外部から観測できる出力だけを使って、システムの内部状態を一意に推定できるかどうかを表します。observabilityの訳語が可観測性で、両者は同じ意味です。oとyの間に11文字あることから「o11y」とも略されます。

IT運用に持ち込まれたとき、意味は「事前にダッシュボードを作り込んでいなかった問いにも、手元のテレメトリから答えられる状態」に広がりました。たとえば「昨夜21時台に、特定の決済手段を選んだユーザーだけ注文確定が遅かったのはなぜか」という問いに、新しいコードを足さず既存のデータだけで答えられるなら、そのシステムは観測可能だといえます。

つまりオブザーバビリティはツールの名前ではありません。高価な製品を入れても、アプリがリクエストIDやユーザー属性を出力していなければ、上の問いには答えられません。必要なのは計装（instrumentation）でシステムの出力を設計することです。

オブザーバビリティが必要になった背景：分散構成における障害パターンの複雑化

1台のサーバーで動くモノリシックなアプリなら、CPU・メモリ・ディスク・プロセスの死活を見張れば、多くの異常は監視項目のどれかに引っかかりました。状況を変えたのは、マイクロサービスとは？モノリス（モノリシック）との違いを原典の定義と比較表で解説で扱った分散構成とコンテナです。構成によっては、1つのリクエストが多数のサービスを経由し、コンテナの追加・削除も頻繁に発生します。その結果、「特定サービスの特定バージョンが、特定のリージョンで、特定の顧客の大きな注文のときだけ遅い」といった組み合わせの障害が起きます。こうした組み合わせは事前に監視項目として書き出せないため、生のデータを属性付きで残し、後から任意の切り口で絞り込める設計が求められるようになりました。

監視・モニタリング・APM・テレメトリとの違い

4語は同じ層に並ぶ選択肢ではありません。層の違いを先に押さえると、「どれを選ぶか」という誤った問いを避けられます。

監視（モニタリング）との違い：既知の異常の検知と未知の原因の探索

この文脈での「監視」と「モニタリング」はほぼ同じ意味で使われるため、「オブザーバビリティとモニタリングの違い」は「オブザーバビリティと監視の違い」と読み替えて構いません。監視は、事前に決めた指標と閾値で既知の異常（known-unknowns）を検知する仕組みです。オブザーバビリティは、その裏にある生データを使って、想定していなかった異常（unknown-unknowns）の原因を後から探す能力を指します。監視の種類や死活監視・性能監視の違いはシステム監視とは？監視項目の種類と死活監視・性能監視の違いを発注者視点で解説にまとめています。

監視が古い手法で、オブザーバビリティがその置き換えだという理解は誤りです。閾値アラートで一次検知するのが監視、鳴った後に原因を掘るのがオブザーバビリティで、片方だけでは運用が回りません。

APMとの違い：性能監視・分析の領域とシステムの性質

APM（Application Performance Monitoring、アプリケーション性能監視）は、トランザクションの応答時間・スループット・エラー率などアプリ層の性能に焦点を当てた領域です。現在のAPM製品は分散トレースや基盤データとの相関分析も扱うため、機能の範囲だけでは線を引けません。違いは出発点にあり、APMがアプリの性能指標を起点に遅い処理を探すのに対し、オブザーバビリティはインフラのメトリクス、ミドルウェアのログ、デプロイなどのイベントまで、どこを起点にしても内部状態を説明できる性質を指します。

「アプリの処理時間は平常なのに体感だけ遅い」事象は、ロードバランサーの待ち時間やマネージドDBのスロットリングを同じ時間軸に並べないと説明が付きません。逆に、単一構成のWebアプリでボトルネックがほぼコード内に限られるなら、APMだけで足りる場面も珍しくありません。APMの計装方式やサンプリング設計はAPM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説で実装目線から解説しています。

テレメトリとの違い：観測データと内部状態を説明できる性質

「オブザーバビリティ vs モニタリング vs テレメトリ」と3語を並べて比べる問いがありますが、テレメトリ（telemetry）はシステムが外へ送り出すデータそのものを指します。OpenTelemetryは、メトリクス・ログ・トレースなどをテレメトリのシグナルとして整理しています。監視はそれらを収集・分析する活動で、オブザーバビリティはデータから内部状態を説明できる性質です。

実務での順番は、テレメトリを出す（計装）、閾値で検知する（監視）、同じデータで探索できるようにする（オブザーバビリティ）の3段です。監視ツールを先に買い、アプリが必要な属性を出していないと後で気付くのは、1段目を飛ばした場合です。

オブザーバビリティの3本柱：メトリクス・ログ・トレースの役割

3種類のテレメトリは粒度とコストが違い、どれか1つでは完結しません。

メトリクス：数値の時系列による異常検知と傾向把握

CPU使用率・レイテンシ・エラー率などを一定間隔で数値にした時系列データです。集約した数値を扱うため、アラートの起点と長期の傾向把握に向きます。ただし、ラベルの組み合わせが増えると時系列数も増え、保存・処理コストが膨らみます。何を測るか迷ったら、GoogleのSRE本が挙げる4つのゴールデンシグナル（レイテンシ・トラフィック・エラー・サチュレーション）から始めると絞り込めます。同書は「ユーザーに面したシステムで4つしか測れないなら、この4つに集中せよ」と書いています（Google SRE Book「Monitoring Distributed Systems」）。メトリクスの型や閾値の決め方はメトリクス監視とは｜4種のメトリック型・収集方式・アラート閾値の設計と導入判断を実装目線で解説で扱っています。

ログ：イベント単位の記録による原因調査

個々の出来事を記録したデータで、原因特定の最後の裏付けになります。JSONなどの構造化ログにしておくと、ユーザーIDや注文IDといったフィールドで後から絞り込めます。反面、出力頻度や1件あたりのサイズによってデータ量が膨らむため、保持期間と出力レベルを先に決めておかないと費用が読めなくなります。OpenTelemetryでログを送る方式の選び方はOpenTelemetryのログ実装｜直接送信とfilelog receiverの選び分けにまとめています。

トレース：リクエストの処理経路と所要時間の記録

1つのリクエストが複数のサービスをまたいで処理される経路を、スパン（処理区間）の連なりとして記録します。OpenTelemetryのスパンには開始・終了時刻と親子関係が入るため、サービスごとの処理時間を比較し、遅延が生じた区間を調べられます。一方、単一プロセスのアプリでは得られる情報がAPMとほぼ重なるため、優先度は下がります。

イベントとプロファイリング：3本柱の外側に置かれるシグナル

ベンダーによっては、デプロイや設定変更などの出来事を「イベント」として4つ目に数え、MELT（Metrics・Events・Logs・Traces）と呼びます。障害の直前にデプロイがあったかを重ねて見られるため、原因の当たりを付ける速さが変わります。

もう1つが、関数単位でCPUやメモリの消費を記録し続ける継続的プロファイリングです。OpenTelemetryも4つ目のシグナルとしてProfilesを策定中ですが、仕様はAlphaの段階で、言語別のステータス表でProfiles欄に状態が載っているのは2026年10月時点でJavaの「Development」だけで、ほかの言語の欄は「-」と表示されています（OpenTelemetry「Status」）。評価環境で試す価値はありますが、本番の障害対応をこのシグナル前提で設計する段階には来ていません。

OpenTelemetryが計装の標準になった経緯と2026年の状況

3本柱を集める計装の標準は、ベンダー中立のOpenTelemetry（OTel）です。分散トレーシングのOpenTracingとOpenCensusが2019年に統合して生まれ、2026年5月11日にCNCF（Cloud Native Computing Foundation）の卒業段階へ移り、同月21日に発表されました（CNCFの発表）。共通の転送プロトコルであるOTLPを使えば、一度OTelで計装すれば、送り先をDatadogからGrafana系のOSSへ変えてもアプリのコードはほぼ書き換えずに済みます。

ただし「3シグナルとも全言語で安定版」ではありません。仕様と転送プロトコルOTLPはトレース・メトリクス・ログとも安定版ですが、言語別SDKの実装状況では、トレースとメトリクスが主要言語の大半でStableなのに対し、ログはPythonとJavaScriptがDevelopment、GoがRelease candidateです（OpenTelemetry「Status」）。PythonやNode.jsのサービスでログまでOTelのSDKに寄せる場合は、既存のロギングライブラリの出力をCollectorのfilelog receiverで拾う構成のほうが、SDKの仕様変更に振り回されません。Collectorを実際に動かす手順はOpenTelemetryとは｜LinuxでCollectorを動かしテレメトリを集める手順とPrometheusとの違いで解説しています。

生成AIを組み込んだアプリでは、LLMの呼び出しもスパンとして記録します。OTelの属性名（gen_ai.*）は開発段階で、名前が変わる可能性があります。スパン木の設計はエージェントトレーシングとは？スパン木の設計・gen_ai属性・記録範囲を実装目線で解説【2026年版】で扱っています。

トレースが途中で切れる原因：W3C Trace Contextの伝播漏れ

分散トレースを入れたのに、画面上でリクエストの経路が途中で途切れることがあります。確認するのは、コンテキストの伝播漏れ、サービス間のサンプリング方針の不一致、スパンの収集漏れの3点です。サービス間のHTTP通信では、W3C勧告のTrace Contextが定める traceparent ヘッダでIDを渡します。

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             │  │                                │                └ trace-flags（2桁・01はサンプリング対象）
             │  │                                └ parent-id（16桁・呼び出し元スパンのID）
             │  └ trace-id（32桁・リクエスト全体で共通）
             └ version（2桁）

受け取ったサービスが同じtrace-idを引き継ぎ、自分のスパンIDを新しいparent-idにして次へ渡す。この連鎖がどこか1か所で切れると、そこから先は別のトレースとして記録されます。切れやすい箇所は次の3つです。

• ヘッダを落とす中継：独自のAPIゲートウェイやプロキシが、許可リストに無いヘッダを転送しない。
• メッセージキューをまたぐ非同期処理：メッセージ属性などを通じたコンテキスト伝播が必要になる。対応する計装ライブラリが自動処理する場合もあり、未対応の通信では注入・抽出処理を実装する。
• 伝播形式の混在：一部のサービスが旧来のB3形式（Zipkin由来）だけを読み書きしていて、W3C形式のヘッダを無視する。

導入時はまず1本のリクエストを入口から末端まで流し、全サービスのスパンが同じtrace-idでつながるかを確かめます。ここが通るまでダッシュボード作りには進みません。

データオブザーバビリティとの違い：対象はシステムではなくデータの品質

「データオブザーバビリティ」は名前が似ていますが、対象が違う別の分野です。この記事のオブザーバビリティがアプリやインフラの挙動を扱うのに対し、データオブザーバビリティはデータパイプラインやデータウェアハウスを流れるデータそのものの品質を監視します。データ基盤ベンダーMonte Carloの共同創業者Barr Mosesが2019年に提唱した言葉で、データの鮮度・量・スキーマ・リネージ（上流から下流への依存関係）などを柱に監視します。

見張るものが「リクエストの遅延やエラー」ではなく「昨夜のバッチで売上テーブルが更新されたか、件数が急減していないか」なので、使うツールも別系統です。5つの柱の測り方と導入の判断はデータオブザーバビリティとは？五つの柱とデータ品質監視の導入判断【2026年8月時点】で詳しく解説しています。

主要なオブザーバビリティツール：OSSとSaaSの役割分担

ツールは、役割ごとに部品を組むOSSと、3シグナルを1つにまとめるSaaSに大別できます。どちらを選んでも、計装はOpenTelemetryで行い、送り先のバックエンドを選ぶ組み合わせが基本です。

Jaegerは2024年11月に出たv2系からOpenTelemetry Collectorを土台に作り直されており、v1系は2025年12月31日でサポートを終えました（Jaeger「Download」、Jaeger v1の終了告知）。v1のエージェントやクライアントライブラリを前提にした古い手順書は、そのまま新規構築に使わないほうが安全です。ログ側をOSSで組む場合はGrafana Lokiとは？仕組み・Alloyでの導入手順とLogQLの書き方【v3.7】の構成が参考になります。

比較の軸は機能表より費用の増え方です。OSSはライセンス費が増えない代わりに基盤の運用を自分たちで背負い、SaaSはホスト数や取り込み量の課金なので、ログを絞らずに送ると見積りを大きく超えます。製品ごとの課金単位と体制別の選び方はオブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方【2026年8月時点】で整理しています。

監視とオブザーバビリティの使い分け：構成・体制別の判断基準

構成が静的で障害の出方が既知なら監視の作り込みで足り、構成が動的で切り分けに時間がかかっているならオブザーバビリティに投資します。条件ごとの優先順位は次のとおりです。

採用を見送ってよい場面もはっきりしています。原因不明の障害が少ない、構成の変更が少ない、既存の監視で復旧目標を満たしている。この3つが揃う場合は、全面導入より既存監視の不足項目の補完を優先候補にします。投資の可否は、障害による損失と調査工数の削減見込みを、導入・運用費用と比較して判断します。

逆に投資すべき兆候は、障害のたびに「誰がどのサーバーのログを見るか」の相談から始まる状態です。この段階で必要なのはツールの追加ではなく、計装の設計と障害対応の当番の型づくりです。一創の保守運用・内製化支援では、システム監視と障害対応、運用手順・ワークフローの整備、内製化に向けた引き継ぎを支援しています。

オブザーバビリティの導入ステップと効果の測り方

導入の順序：SLOを起点とした計装設計とツール選定

ツール選定から入ると、データは集まったのに何も判断できないダッシュボードになりがちです。守るべき目標から逆算します。

1. 守るべき指標（SLI）と目標値（SLO）を決める。考え方はSREとは？サイト信頼性エンジニアリングの意味・DevOpsとの違いをわかりやすく解説が土台になります。
2. OpenTelemetryでアプリを計装し、出力の形式と送り先をそろえる。
3. 入口から末端までtrace-idがつながることを確かめる。
4. ログ・トレースではユーザーIDなどの高カーディナリティ属性を検索できるバックエンドを選ぶ。メトリクスではユーザーIDをラベルにせず、時系列数の増加を抑える。
5. クラウドではマネージドの収集機能を使う。AWSでの構成はAWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成【2026年時点】で解説しています。

導入時の失敗要因：SLO未定義・収集量の未設計・ID伝播漏れ

1つ目は、SLOを決めずにダッシュボードから作る順序違いで、グラフが増えるだけで判断は速くなりません。2つ目は、ログの保持期間とトレースのサンプリング率を決めないまま本番データを流し、翌月の請求で問題になるケースです。3つ目は前の章で触れたtrace-idの伝播漏れで、W3C Trace Contextの伝播が途切れると、前後の処理を同じトレースとして追えなくなります。いずれも設計段階で潰せるので、ツールを選ぶ前にSLO・保持期間・ID伝播の3点を文書にしておくと手戻りが減ります。

導入効果の測定：MTTD・MTTRの導入前後比較

効果は「見える化できた」では測れません。測るのは、障害発生から検知までの平均時間（MTTD）と、復旧までの平均時間（MTTR）です。MTTRは定義に幅があるため、本記事では検知から復旧までと定義し、導入前後で同じ起点・終点と集計条件を使います。監視の改善はMTTDに、オブザーバビリティはMTTRのうち原因の特定に効くので、復旧時間を「切り分け」と「修正」に分けて記録すると、どちらの投資が効いたかを区別できます。

よくある質問

オブザーバビリティと監視の違いは何ですか？

監視は事前に決めた指標と閾値で既知の異常を検知する仕組みです。オブザーバビリティはその裏にある生データを使い、想定していなかった障害についても「なぜ起きたか」を後から探せる性質を指します。

オブザーバビリティとAPMの違いは何ですか？

APMはアプリケーションの性能（応答時間・スループット・エラー）を監視・分析する領域で、現在の製品は分散トレースや基盤データとの相関分析も扱います。これに対しオブザーバビリティは特定の製品領域ではなく、テレメトリから内部状態を説明できる性質です。課題がアプリ内の遅延に限られるならAPMだけで足ります。

オブザーバビリティとテレメトリはどう違いますか？

テレメトリはシステムが送り出すデータそのもの（メトリクス・ログ・トレース）で、オブザーバビリティはそのデータから内部の状態を説明できる性質です。層が違うため、どちらかを選ぶ関係にはなりません。

可観測性とオブザーバビリティは同じ意味ですか？

同じ意味です。observabilityの日本語訳が可観測性で、oとyの間の11文字を数字にした「o11y」という略記も使われます。

データオブザーバビリティとは何が違うのですか？

データオブザーバビリティは、データパイプライン内のデータの鮮度・量・スキーマ・リネージなどを監視する別分野です。アプリやインフラの挙動を対象とするオブザーバビリティとは、監視の対象も使うツールも異なります。

関連記事

• OpenTelemetryとは｜LinuxでCollectorを動かしテレメトリを集める手順とPrometheusとの違い
• APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説
• オブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方【2026年8月時点】
• データオブザーバビリティとは？五つの柱とデータ品質監視の導入判断【2026年8月時点】
• システム監視とは？監視項目の種類と死活監視・性能監視の違いを発注者視点で解説