---
title: "オブザーバビリティ（可観測性）とは？監視・モニタリング・APMとの違いと使い分けを解説"
url: "https://www.issoh.co.jp/column/details/3077/"
published: 2024-07-16
updated: 2026-09-20
categories: ["ガイドライン"]
publisher: "株式会社一創"
---

# オブザーバビリティ（可観測性）とは？監視・モニタリング・APMとの違いと使い分けを解説

オブザーバビリティ（可観測性、observability。o11yとも書く）とは、システムが外部に出力するメトリクス・ログ・トレースから、その内部で「なぜその状態になったのか」を後から問い直せる状態を指します。あらかじめ決めた指標をチェックする従来の監視（モニタリング）と対比され、想定していなかった障害の原因まで追える点が違いです。

検索では「オブザーバビリティ 監視 違い」「オブザーバビリティ モニタリング 違い」「オブザーバビリティ apm 違い」といった比較の問いが寄せられる傾向です。そこでこの記事では、監視・モニタリング・APM・テレメトリという紛らわしい4語をまず一覧で切り分け、3本柱と主要ツールを押さえたうえで、どちらをいつ優先するかという使い分けの判断まで通しで扱います。なお、名前が似た「データオブザーバビリティ」はデータパイプラインの品質を監視する別分野なので、中盤で分けて解説します。

## まとめ：オブザーバビリティと監視の違いと使い分けの要点

- オブザーバビリティ＝出力データから内部状態を推測し、未知の障害（unknown-unknowns）まで事後に深掘りできる能力。
- 監視（モニタリング）は既知の異常を閾値で検知する仕組み。オブザーバビリティはその上位概念で、APMはアプリ性能に絞った一部。両者は対立ではなく包含。
- テレメトリは能力でも手法でもなく、両者が材料にするデータそのもの（メトリクス・ログ・トレース）を指す言葉。
- 3本柱はメトリクス・ログ・トレース。計装の標準はOpenTelemetryで、2026年5月11日にCNCFを卒業した。
- 第4のシグナルと呼ばれる継続的プロファイリングは、2026年9月時点で仕様ステータスがAlphaのため本番前提には置かない。
- 「データオブザーバビリティ」はデータの鮮度・量・スキーマ等を監視する別分野（Monte Carloが2019年に提唱した5つの柱）。
- ツールはOSS（Prometheus・Grafana・Jaeger・OpenTelemetry）とSaaS（Datadog・New Relic・Splunk）に大別できる。
- 使い分けは「構成が静的か動的か」「障害の切り分けを誰が何分でやるか」で決まる。監視だけで足りる構成にオブザーバビリティを足しても、運用コストが増えるだけで回収できない。

## オブザーバビリティ（可観測性）の定義と制御工学に由来する考え方

オブザーバビリティはもともと制御工学の用語で、システムの外部出力だけから内部状態を推定できる度合いを意味します。IT運用では、メトリクス・ログ・トレースというテレメトリーを手がかりに、事前にダッシュボードを作り込んでいなかった問いにも答えられる状態を指します。

核心は、未知の障害に答えられるかどうかです。マイクロサービスやコンテナで構成が動的に変わる環境では、障害の出方を事前に列挙しきれません。特定の指標を見張る監視だけでは「想定外」を取りこぼすため、生データを高い解像度で残し、後から任意の切り口で掘り下げられる設計が必要になります。

ここで押さえておきたいのは、オブザーバビリティがツールの名前ではなく**システム側の性質**だという点です。同じDatadogを入れても、アプリがリクエストIDを吐いていなければ「このユーザーのこの注文がなぜ遅いか」には答えられません。ツールを買う話ではなく、計装（instrumentation）でシステムの出力を設計する話だと捉えると、後述の導入ステップが順序どおりに読めます。

## 監視・モニタリング・APMとの違いを問いの種類から切り分ける

「オブザーバビリティ 監視 違い」は、この記事に対して最も多く検索される問いです。監視（モニタリング）は事前に定義した指標と閾値で「既知の異常」を検知する仕組みで、オブザーバビリティはその生データを使って「なぜ起きたか」を後から探索する上位概念、という関係になります。両者は対立ではなく包含です。

| 観点       | 監視（モニタリング）            | オブザーバビリティ               |
| -------- | --------------------- | ----------------------- |
| 扱う問い     | 既知の異常（known-unknowns） | 未知の異常（unknown-unknowns） |
| データ      | 事前定義した指標・閾値           | メトリクス/ログ/トレースを横断保持      |
| 使い方      | ダッシュボードとアラート          | 事後に任意の条件で深掘り            |
| 答えるもの    | 「何が」起きたか              | 「なぜ」起きたか                |
| 事前に必要なもの | 監視項目と閾値の定義            | 高解像度な出力と計装の設計           |
| 向く構成     | 構成が静的で障害型が既知          | 構成が動的で障害型が未知            |

### モニタリングとオブザーバビリティは対立ではなく包含の関係にある

日本語の「監視」と英語由来の「モニタリング」は、この文脈ではほぼ同義に使われます。したがって「オブザーバビリティとモニタリングの違い」は、そのまま「オブザーバビリティと監視の違い」と読み替えて差し支えありません。

誤解が生まれやすいのは、モニタリングが古い手法で、オブザーバビリティが新しい置き換えだと受け取る読み方です。実際には、閾値アラートで一次検知するのがモニタリング、鳴った後に原因を掘るのがオブザーバビリティで、片方だけでは運用が回りません。SLO違反を知らせる通知路が無ければ誰も掘り始めませんし、掘るための生データが無ければ通知は「落ちた」以上の情報を持たないままです。

### APMとの違いはアプリ層に絞るか基盤まで含めて横断するかで決まる

APM（アプリケーション性能監視）は、トランザクションの応答時間やスループットなどアプリ層の性能に焦点を絞った領域で、オブザーバビリティの一部にあたります。APMの計装方法やサンプリング設計、SaaSと内製OSSの選定といった実装・導入判断は[APM（アプリケーション性能監視）とは](https://www.issoh.co.jp/tech/details/15414/)で実装目線で解説しています。

違いは扱う範囲です。APMはアプリのコード実行とトランザクションを見ますが、オブザーバビリティはそこにインフラのメトリクス、ミドルウェアのログ、サービス間の分散トレースまで含めて横断します。「アプリは遅くないのにユーザー体験だけ悪い」という事象は、APM単体では説明が付かず、ノード側のディスクI/Oやマネージドサービスのスロットリングまで並べて初めて原因に届きます。逆に、単一構成のWebアプリでボトルネックがコード内にほぼ限られるなら、APMだけで足りる場面も珍しくありません。

### テレメトリとモニタリングとオブザーバビリティの関係を切り分ける

「オブザーバビリティ vs モニタリング vs テレメトリ」と並べて比較されることがありますが、この3語は同じ層の選択肢ではありません。テレメトリ（telemetry）はシステムが遠隔に送り出すデータそのもの、モニタリングはそのデータを閾値に当てる運用手法、オブザーバビリティはデータから内部状態を説明できるという性質です。層が違うものを横並びで比べると、どれを選ぶかという誤った問いになります。

| 用語        | 層       | 具体物            |
| --------- | ------- | -------------- |
| テレメトリ     | データ     | メトリクス・ログ・トレース  |
| モニタリング    | 運用手法    | 閾値アラート・ダッシュボード |
| オブザーバビリティ | システムの性質 | 事後探索できる状態      |
| APM       | 適用範囲    | アプリ層の性能に限定     |

実務上の順番は、テレメトリを出す（計装）、閾値で検知する（モニタリング）、そのデータで探索できるようにする（オブザーバビリティ）の3段です。ツール選定でつまずくチームは、2段目の道具を買ってから1段目が欠けていることに気付きます。

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

オブザーバビリティは、性質の異なる3種類のテレメトリーを組み合わせて成立します。1つで完結するものはなく、粒度とコストの違いを踏まえて役割を割り振ります。

### メトリクスは数値の時系列で傾向把握とアラート検知の起点になる

CPU使用率・レイテンシ・エラー率などを一定間隔で数値化した時系列データです。集約が軽く、傾向把握やアラートに向く一方、単体では「どのリクエストで何が起きたか」までは分かりません。保存コストが3本柱で最も低いため、長期保持して季節変動や容量計画の根拠に回せます。

### ログはイベント単位の記録で障害の原因特定を裏付ける一次情報になる

イベント単位の記録です。JSONなどの構造化ログにしておくと、後からフィールドで絞り込んだ横断検索がしやすくなります。原因特定の最終的な裏付けになる一次情報です。このログをOpenTelemetryで送出する実装手順は[OpenTelemetryのログ実装｜直接送信とfilelog receiverの選び分け](https://www.issoh.co.jp/tech/details/16555/)で扱っています。反面、量が最も膨らむ柱でもあるので、保持期間とサンプリングを先に決めておかないと費用が読めなくなります。

### トレースはリクエストが通る経路をスパンの連なりとして記録する

1つのリクエストが複数サービスをまたいで処理される経路を、スパン（処理区間）の連なりとして記録します。どのサービスで時間を消費したかが分かるため、[マイクロサービスとは何か](/column/details/2910/)で解説したような分散構成のボトルネック特定に有効です。逆に単一プロセスのアプリでは得られる情報がAPMと重なるため、導入の優先度は下がります。

### 計装の標準はOpenTelemetryで第4のシグナルも進行中

これら3本柱を集める計装（instrumentation）は、ベンダー中立のOpenTelemetry（OTel）が事実上の標準です。OTelは[2026年5月11日にCNCFの卒業プロジェクト](https://opentelemetry.io/blog/2026/otel-graduates/)になり（発表は同年5月21日）、トレース・メトリクス・ログの3シグナルはいずれも主要言語で安定版（GA）に達し、転送プロトコルOTLPで統一されています。計装の詳細は[OpenTelemetry（OTel）とは](/tech/details/3625/)で解説しています。

「第4のシグナル」と呼ばれる[継続的プロファイリング（Continuous Profiling）](https://www.issoh.co.jp/tech/details/15709/)は、2026年3月にパブリックアルファとして公開されました。ただし[公式仕様のステータス](https://opentelemetry.io/docs/concepts/signals/profiles/)は2026年9月時点でAlphaのままで、SDKレベルのAPIやバックエンド側の対応も途上です。評価環境で試す価値はあるものの、本番の障害対応をこのシグナル前提で設計する段階には至っていません。

## データオブザーバビリティとの違いは監視する対象とツールが別系統

検索では「データオブザーバビリティ」でこの記事にたどり着く人が最も多いものの、これは本記事の主題であるシステムのオブザーバビリティとは対象が異なる別分野です。混同しやすいため切り分けておきます。

システムのオブザーバビリティが「アプリやインフラの挙動」を対象にするのに対し、データオブザーバビリティは「データパイプラインやデータウェアハウスを流れるデータそのものの品質・信頼性」を監視します。データ基盤ベンダーのMonte Carloが2019年に提唱した概念で、監視すべき対象を次の5つの柱に整理しています。

| 柱                | 監視する内容          |
| ---------------- | --------------- |
| Freshness（鮮度）    | データが最新に更新されているか |
| Volume（量）        | 件数の急増・急減や欠損     |
| Distribution（分布） | 値の範囲・NULL率などの逸脱 |
| Schema（スキーマ）     | 列や型の予期しない変更     |
| Lineage（リネージ）    | 上流から下流への依存と影響   |

つまり、メトリクス・ログ・トレースの3本柱を扱うのがシステムのオブザーバビリティ、鮮度・量・分布などデータの健全性を扱うのがデータオブザーバビリティです。監視ツールも前者はDatadogやGrafana、後者はMonte CarloやDatabricksといった別系統になります。データ側の五つの柱をどう測り、どの型のツールをいつ入れるかは[データオブザーバビリティとは？五つの柱とデータ品質監視の導入判断【2026年8月時点】](https://www.issoh.co.jp/column/details/16504/)で扱っています。

## 主要なオブザーバビリティツールのOSS・SaaS別の役割と費用比較

ツールはベンダー中立のOSSと、統合型のSaaSに大別できます。まずOpenTelemetryで計装し、収集・保存・可視化のバックエンドを選ぶ、という組み合わせが一般的です。

| ツール            | 種別     | 主な役割          |
| -------------- | ------ | ------------- |
| OpenTelemetry  | OSS/標準 | 計装・収集（ベンダー中立） |
| Prometheus     | OSS    | メトリクス収集・アラート  |
| Grafana / Loki | OSS    | 可視化 / ログ集約    |
| Jaeger         | OSS    | 分散トレース        |
| Datadog        | SaaS   | 3シグナル+APMを統合  |
| New Relic      | SaaS   | APM中心の統合基盤    |
| Splunk         | SaaS   | ログ分析・監視       |

OSSで組む場合は、メトリクスをPrometheus、可視化とログを[Grafana Lokiとは](/tech/details/9570/)で扱った構成、トレースをJaegerで受ける形が定番です。製品ごとの課金モデルの違いや運用体制別の選び方は[オブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方【2026年8月時点】](https://www.issoh.co.jp/column/details/16502/)で整理しています。SaaSではDatadogが3シグナルとAPMを1つにまとめており、Terraformでの設定管理は[TerraformでDatadogを管理する方法](/tech/details/10105/)にまとめています。

比較の軸は機能表よりも費用の増え方に置くほうが実務に合う考え方です。OSSは利用量が増えてもライセンス費が跳ねない代わりに、収集基盤そのものの運用工数を自分たちで負います。SaaSは取り込み量やホスト数で課金されるため、ログを絞らずに入れると初期見積りの数倍になります。どちらを選んでも、ログの保持期間とトレースのサンプリング率を先に決めた見積りでなければ数字は当たりません。

## 監視とオブザーバビリティの使い分けを構成と体制の条件で判断する

「違いは分かったが、自社はどちらに投資すべきか」という問いには、構成と体制の2条件で答えを出すことが可能です。結論から書くと、**構成が静的で障害の出方が既知なら監視の作り込みで足り、構成が動的で切り分けに時間がかかっているならオブザーバビリティに投資する価値があります**。判断材料を条件で並べます。

| 自社の条件          | 優先するもの          |
| -------------- | --------------- |
| 単一構成・オンプレ中心    | 監視の作り込みで足りる     |
| マイクロサービス・コンテナ  | トレースから順に計装する    |
| 障害の切り分けに数時間かかる | オブザーバビリティに投資する  |
| アプリ内の遅延だけが課題   | APMに絞って導入する     |
| 運用が1〜2名の小規模体制  | SaaSで統合し運用工数を削る |
| データ品質の事故が多い    | データオブザーバビリティ側   |

採用を見送ってよい場面もはっきりしています。月に1度も原因不明の障害が起きていない、構成図が1年変わっていない、アラートが鳴ってから復旧まで30分以内で終わっている。この3つが揃うなら、3本柱を揃える投資は回収できません。既存の監視で取りこぼしている項目を足すほうが費用対効果は上です。

逆に投資すべき兆候は、障害のたびに「誰がどのログを見るか」から相談が始まる状態です。この段階で必要なのはツールの追加ではなく、計装の設計と運用当番の型づくりという対応です。一創では[保守運用・内製化支援](https://www.issoh.co.jp/service/system/maintenance/)として、既存システムの監視項目の棚卸しからOpenTelemetryでの計装、障害対応フローの整備までを引き受けています。自社で運用体制を持ちたい場合の内製化支援も同じ窓口で相談できます。

## オブザーバビリティの導入ステップと設計段階でつまずきやすい三つの箇所

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

1. 守るべき指標（SLI）と目標値（SLO）を決める。この考え方は[SRE（サイト信頼性エンジニアリング）とは](/column/details/3080/)が土台になります。
2. OpenTelemetryでアプリを計装し、テレメトリーの出力先を統一する。
3. 高カーディナリティのデータを許容できる収集・保存バックエンドを選ぶ。
4. 分散構成ではトレースを優先し、サービス間の依存とレイテンシを可視化する。
5. クラウド上ではマネージド機能を使う。AWSでの具体的な計装構成は[AWSオブザーバビリティの実装](/tech/details/15297/)で解説しています。

つまずきやすい箇所は3つに集約されます。1つ目は、SLOを決めずにダッシュボードから作る順序違いで、指標が増えるだけで判断が速くなりません。2つ目は、ログの保持期間とトレースのサンプリング率を決めないまま本番に流し、翌月の請求で費用が問題になるケースです。3つ目が、リクエストIDやトレースIDをサービス間で引き継いでいない計装漏れで、これがあるとトレースが途中で切れて経路が追えなくなります。

いずれも設計段階で潰せる論点なので、ツールの選定より前にSLO・保持期間・ID伝播の3つを文書で決めておくと手戻りが減ります。

## よくある質問

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

監視は事前に定義した指標と閾値で既知の異常を検知します。オブザーバビリティはその生データを使い、想定していなかった障害についても「なぜ起きたか」を事後に探索できる上位概念です。監視が「何が起きたか」を知らせ、オブザーバビリティが「なぜ起きたか」に答える、という役割分担で捉えると混同しません。

### オブザーバビリティとモニタリングの違いはありますか？

この文脈での「監視」と「モニタリング」はほぼ同義なので、オブザーバビリティとモニタリングの違いは、オブザーバビリティと監視の違いと同じ内容になります。モニタリングが閾値で一次検知する運用手法、オブザーバビリティが原因まで掘れるシステム側の性質という関係で、どちらかを選ぶものではありません。

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

APMはアプリケーション層の性能（応答時間・スループット・エラー）に範囲を絞った監視領域で、オブザーバビリティに含まれる一部です。オブザーバビリティはそこにインフラのメトリクスやログ、サービス間の分散トレースまで含めて横断します。課題がアプリ内の遅延に限られるならAPMだけで足り、原因がアプリの外にも散らばるならオブザーバビリティの範囲が必要になります。

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

テレメトリはシステムが送り出すデータそのもの（メトリクス・ログ・トレース）を指す言葉で、オブザーバビリティはそのデータから内部状態を説明できるという性質です。層が違うため「オブザーバビリティかテレメトリか」という選択にはなりません。テレメトリを出す計装が先にあり、その上にモニタリングとオブザーバビリティが乗る三層で理解すると整理できます。

### オブザーバビリティの3本柱とは何ですか？

メトリクス（数値の時系列）、ログ（イベント記録）、トレース（リクエストの経路）の3つです。これらを集める標準として2026年時点ではOpenTelemetryが使われます。メトリクスとして何を優先的に測るかは、[Golden Signals（4つのゴールデンシグナル）](https://www.issoh.co.jp/tech/details/15714/)のレイテンシ・トラフィック・エラー・サチュレーションを起点にすると絞り込めます。第4のシグナルと呼ばれる継続的プロファイリングは、2026年9月時点で仕様ステータスがAlphaです。

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

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

### オブザーバビリティに必要なツールは何ですか？

計装はOpenTelemetryが標準です。バックエンドはOSSならPrometheus・Grafana・Jaeger、統合型のSaaSならDatadog・New Relic・Splunkが代表格です。小規模な運用体制ならSaaSで統合し、取り込み量が読めていてエンジニアを割けるならOSSで組む、という切り分けになります。

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

同じです。observabilityの訳語が可観測性で、o11yという略記も使われます。いずれも出力から内部状態を推し量れる度合いを指します。

## 関連記事

- [OpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector・Prometheusとの違いを解説](/tech/details/3625/)
- [APM（アプリケーション性能監視）とは｜計装方式・サンプリング設計・ツール選定を解説](/tech/details/15414/)
- [AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成](/tech/details/15297/)
- [Grafana Lokiとは？Prometheus連携・LogQL・導入方法をわかりやすく解説](/tech/details/9570/)
- [TerraformでDatadogを管理する方法｜Provider設定・モニター・AWSインテグレーション実践ガイド](/tech/details/10105/)
- [オブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方](/column/details/16502/)
- [データオブザーバビリティとは？五つの柱とデータ品質監視の導入判断](/column/details/16504/)
- [多くのオブザーバビリティツールがビジネスコンテキストを欠く理由](/column/details/4361/)

---

出典: [オブザーバビリティ（可観測性）とは？監視・モニタリング・APMとの違いと使い分けを解説](<https://www.issoh.co.jp/column/details/3077/>)（株式会社一創）