オブザーバビリティ（）とは、ソフトウェア工学や分散コンピューティングにおいて、システムが外部に出力するデータからその内部状態をどれだけよく推測できるかを表す性質である。可観測性（かかんそくせい）とも訳され、日本語メディアでは長音符を付けた「オブザーバビリティー」の表記も用いられる。用語は制御理論における同名の概念（可観測性）に由来する。
オブザーバビリティの実践では、システムが出力するログ、メトリクス、トレースなどのデータ（テレメトリー）を収集・分析し、マイクロサービスやクラウド環境のような複雑な分散システムで起きる予期しない障害の原因を調べられるようにする。DevOpsやサイトリライアビリティエンジニアリング（SRE）の実践を支える基盤とされる。2020年代にはガートナーが市場調査レポートの分野名に採用するなど独立した製品分野として扱われるようになり、生成AIの普及に伴って大規模言語モデル（LLM）を組み込んだシステムを対象とする「LLMオブザーバビリティ」と呼ばれる領域も生まれている。
定義 Cloud Native Computing Foundation（CNCF）のオブザーバビリティ・ホワイトペーパー（2023年10月）は、オブザーバビリティを「システムの内部状態を、その外部出力の知識からどれだけよく推測できるかの尺度」と定義している。これは制御理論の可観測性の定義をソフトウェアシステムに適用したものであり、同ホワイトペーパーは概念の起源としてルドルフ・カルマンが1960年の第1回国際自動制御連盟（IFAC）大会で発表した論文を挙げている。制御理論における可観測性は「出力信号の測定データから、システムの現時点の内部状態を一意的に決めることができる」性質を指し、可制御性と数学的に双対の関係にある。同ホワイトペーパーはSREやDevOpsの技術者を主な読者と位置づけ、オブザーバビリティの用途として、サービス水準の指標（SLI）と目標（SLO）の測定、テレメトリーに基づく警報、障害の根本原因分析などを挙げている。
ソフトウェア分野では、これを実務に引きつけた定義も広く使われる。オブザーバビリティ製品企業Honeycombの共同創業者チャリティ・メイジャーズ（Charity Majors）は、オブザーバビリティを「新しいコードを書いてデプロイすることなく、システムへの問い合わせだけで、事前に想定していなかった新しい質問に答えられる能力」として説明している。
モニタリングとの違い オブザーバビリティは従来の監視（モニタリング）を置き換えるものではなく、補完するものと整理される。分散システム技術者のシンディ・スリダラン（Cindy Sridharan）は2017年に、モニタリングがシステム全体の健全性を報告し既知の障害パターンを検出することに向くのに対し、オブザーバビリティはデバッグのための高い粒度の洞察を与える上位概念であり、「未知の未知（unknown-unknowns）」を最小化する設計目標だと論じた。メイジャーズも同様に、モニタリングはしきい値を設定して検査を走らせ、あらかじめ定義できる障害すなわち「既知の未知（known-unknowns）」を見張る手法であり、オブザーバビリティは事前に予測できなかった問題を事後に調査できる能力だと対比している。
この区別が重視される背景には、システム構成の変化がある。単一のサーバ上で動く一体型のシステムでは、障害パターンをあらかじめ列挙してダッシュボードと警報を用意する方法が機能した。しかしマイクロサービスやクラウド、Kubernetesなどにより構成要素が動的に増減する環境では、事前に想定できない障害が支配的になり、任意の切り口でシステムの内部状態を問い合わせられる能力が必要になったと説明される。
歴史 可観測性の概念は、1960年前後にカルマンが線形力学系の理論として導入した。ソフトウェアシステムの文脈へ転用された時期を特定することは難しい。ブロードコムの技術解説記事は、早い例として1999年にサン・マイクロシステムズが性能管理の文脈でこの語を使った文書を挙げたうえで、2018年頃には技術カンファレンスで頻出する主流の用語になったとしている。この間の2013年には、Twitterのエンジニアリングチームが自社の分散システム監視基盤を紹介する「Observability at Twitter」と題した記事を公開している。
要素技術はそれ以前から発展していた。2010年にGoogleは社内の大規模分散トレーシング基盤に関する論文「Dapper」を公表し、後の分散トレーシングツールの設計に影響を与えた。2011年にはEtsyがメトリクス集計デーモンのStatsDを公開した。2012年にはTwitterが、Dapper論文の基本部分を実装した分散トレーシングシステムZipkinを公開した。同じ2012年にはSoundCloudで時系列メトリクス監視システムPrometheusの開発が始まり、2016年にKubernetesに次ぐ2番目のプロジェクトとしてCNCFに参加した。
2017年頃には、ピーター・ボーゴン（Peter Bourgon）によるメトリクス・ロギング・トレーシングの3領域の整理や前述のスリダランの論考など、オブザーバビリティの構成要素を体系化する議論が活発になった。2019年には、テレメトリー収集の重複した枠組みであったOpenTracingとOpenCensusが統合されてOpenTelemetryが発足した。2023年10月にはCNCFがオブザーバビリティ・ホワイトペーパー1.0版を公開した。市場区分の名称としては、ガートナーが従来「APMとオブザーバビリティ」と呼んでいたマジック・クアドラント（市場調査レポート）を、2024年版から「オブザーバビリティ・プラットフォーム」に改称している。
テレメトリーの種類 オブザーバビリティを実現するためにシステムから収集されるテレメトリーデータは、伝統的にログ・メトリクス・トレースの3種類に整理され、「オブザーバビリティの三本柱」と呼ばれてきた。ボーゴンは2017年、メトリクスの本質を「集計可能であること」、ロギングの本質を「離散的なイベントを扱うこと」、トレーシングの本質を「リクエスト単位の範囲を持つこと」として、3領域をベン図で整理した。一方でCNCFのホワイトペーパーは、3つすべてが常に必要とは限らないことなどを理由に「柱」ではなく「主要シグナル」という呼称を採り、プロファイルとダンプ（プログラム異常終了時のメモリ内容の記録）を加えた5種類のシグナルとそれらの相関付けを論じている。またNew Relicは、イベントを加えた4分類を「MELT」（Metrics、Events、Logs、Traces）と呼ぶ。メイジャーズのように、集約済みデータであるメトリクスではなく、リクエスト単位の幅広い構造化イベントを基礎単位とすべきだとして「三本柱」の枠組み自体を批判する論者もいる。
ログ ログは、システム内で発生した個々の事象を記述するテキストエントリであり、オペレーティングシステムやアプリケーションが動作の記録として出力する。誤りの深刻度を表すレベル（ERROR、WARNING、INFO、DEBUGなど）を伴うことが多い。障害の根本原因分析やデバッグに有用である一方、自由形式のテキストであるため、大量のログから意味を抽出することが課題となる。
メトリクス メトリクスは、システムの状態を数値で表現した時系列データであり、名前・ラベル・時刻・数値から構成される。値が上下するゲージ、単調に増加するカウンター、分布を表すヒストグラムなどの型がある。収集・保存の効率が高くコストを予測しやすい反面、集約の過程で詳細な文脈は失われるため、システムの全体像の把握や異常の検知の出発点として使われる。
トレース トレースは、1つのリクエストが複数のサービスやコンポーネントを横断して処理される過程を追跡するデータである。処理の単位はスパンと呼ばれ、スパンの親子関係からなる木構造として1つのトレースが構成される。マイクロサービスのように多数のサービスが連携する環境で「分散トランザクションのどこで何が起きたか」を理解するために用いられ、分散トレーシングと呼ばれる。サービス間でトレースの文脈を伝播させるためのHTTPヘッダー形式は、World Wide Web Consortium（W3C）が「Trace Context」として標準化しており、2020年2月に勧告となった。
プロファイルなどの追加シグナル プロファイルは、プログラムのどの箇所がCPUやメモリなどの資源をどれだけ消費しているかを記録したデータである。サンプリング型プロファイラーの発展により、本番環境で資源消費をコードの行レベルまで継続的に計測する継続的プロファイリングが現実的になった。OpenTelemetryは2024年3月、ログ・メトリクス・トレースに続く第4のシグナルとしてプロファイリング対応の計画を発表し、データモデルの策定を進めている。このほか、LinuxカーネルのeBPF技術を用いて、アプリケーションのコードを変更せずにカーネルレベルでテレメトリーを収集する手法も広がっている。
標準化 アプリケーションにテレメトリー出力用の計測コードを組み込む作業は計装（インスツルメンテーション）と呼ばれ、その標準化の代表的な取り組みがOpenTelemetryである。OpenTelemetryは2019年にOpenTracingとOpenCensusの2プロジェクトを統合してCNCFの下で発足したベンダー中立のオープンソースフレームワークで、テレメトリーの収集・処理・送信のための単一のAPI・SDK・コレクターと、計装の語彙を定めるセマンティック規約を提供する。2026年5月にCNCFの卒業（Graduated）プロジェクトとなった。CNCFはこの時点で貢献者が12,000人、参加企業が2,800社を超え、プロジェクトの活動量がCNCFの240超のプロジェクト中Kubernetesに次ぐ2位であるとして、オブザーバビリティの「事実上の標準」と位置づけている。日本語の技術メディアでも、オブザーバビリティ実現の標準的な計装手段として紹介されている。
メトリクスの公開形式については、Prometheusの形式を汎用の標準へ発展させる目的でOpenMetricsプロジェクトが2018年にCNCFに受け入れられたが、後にPrometheusプロジェクトへ統合され、CNCFのアーカイブ済みプロジェクトとなった。2024年11月公開のPrometheus 3.0はOpenTelemetryのプロトコル（OTLP）によるメトリクス受信をネイティブに備えるなど、両エコシステムの相互運用が進んでいる。
テレメトリーデータの急増に伴い、収集元と分析基盤の間でデータの経路制御・変換・削減を行う「テレメトリーパイプライン」という製品区分も生まれている。ガートナーは2025年9月にこの分野のマーケットガイドを発行し、テレメトリーパイプライン製品を経由して処理されるログの割合が、2024年の20%未満から2027年までに40%に達すると予測した。
主要な製品とサービス 調査会社のガートナーは、2025年版の「オブザーバビリティ・プラットフォームのマジック・クアドラント」でDatadog、Dynatrace、Splunk、New Relic、Elastic（Elasticsearch開発元）、Grafana Labs（Grafana開発元）、IBM、Chronosphereの8社をリーダーに位置づけ、オブザーバビリティ製品市場が2028年までに推定142億ドルに達すると予測している。
商用プラットフォーム Datadogは、インフラ監視・APM・ログ管理などを統合したSaaS型（インターネット経由で提供されるサービス型）のプラットフォームを提供する米国企業で、2018年に日本国内拠点を開設し、2019年に日本法人を設立した。オブザーバビリティSaaSを提供するNew Relicは、2023年に投資ファンドのフランシスコ・パートナーズとTPGによる約65億ドルの買収に合意し、同年11月に非公開企業となった。ログ分析製品から発展したSplunkは、2024年3月にシスコシステムズが約280億ドルで買収を完了した。このほか、『オブザーバビリティ・エンジニアリング』の著者の一人であるメイジャーズが共同創業したHoneycombのような専業企業もある。
大手クラウド事業者も自社クラウドに統合されたオブザーバビリティサービスを提供しており、Amazon Web ServicesのAmazon CloudWatch、Microsoft AzureのAzure Monitor、Google CloudのGoogle Cloud Observability（旧Stackdriver）などがある。
オープンソースソフトウェア オープンソースでは、メトリクス監視のPrometheus、可視化のGrafana、分散トレーシングのJaeger（Uber発、2019年にCNCF卒業）やZipkinなどが広く使われている。
コストの課題 テレメトリーデータの増大に伴い、オブザーバビリティ基盤の費用の増大が運用上の課題として議論されている。2023年には、Datadogのある顧客の年間利用料が約6,500万ドルに達していたことが決算説明会での質疑から明らかになり、業界メディアで大きく取り上げられた。前述のテレメトリーパイプライン製品の伸長も、このようなコスト管理の需要を背景とする。
生成AIとオブザーバビリティ 2020年代半ばの生成AIの普及とともに、生成AIを組み込んだシステムをどう観測するか、また生成AIが作ったソフトウェアや、オブザーバビリティ自体への生成AIの応用をどう扱うかが論じられるようになった。ガートナーは2026年3月、「2028年までに生成AIを導入した企業の50%がLLMオブザーバビリティに投資する」との予測を発表している。日本語メディアでも、生成AI時代の運用の文脈でオブザーバビリティを扱う解説や調査報道が増えている。
LLM・AIエージェントの可観測性 大規模言語モデルを組み込んだアプリケーションは、同じ入力に対して出力が変わり得る非決定的な性質を持つため、従来のソフトウェアやそれまでの機械学習モデルとは異なる監視上の課題を抱える。プロンプトと応答の内容の記録や、アプリケーション内の処理連鎖の追跡に加えて、トークン使用量とコスト、応答遅延、ハルシネーションの発生、出力の品質評価、プロンプトインジェクションや個人情報漏えいの検知などが監視対象となる。これらを扱う領域はLLMオブザーバビリティと呼ばれる。学術研究の対象にもなっており、2025年のACM CHI会議では、開発者への調査に基づいてLLMオブザーバビリティの4つの設計原則を提示する論文が発表された。
製品としては、2023年4月にArize AIが公開したオープンソースのLLM評価・オブザーバビリティライブラリPhoenix、LangChain社のLangSmith（2024年2月正式提供）、オープンソースのLangfuseなどがある。既存のオブザーバビリティ企業も参入しており、Dynatraceは2024年1月に大規模言語モデルと生成AIを対象とするAI Observabilityを、New Relicは2024年3月にAI Monitoringを、Datadogは2024年6月にLLM Observabilityを、それぞれ正式提供した。
自律的にツールを使い分けてタスクを遂行するAIエージェントの普及に伴い、その行動を追跡するエージェント・オブザーバビリティも論じられている。OpenTelemetryプロジェクトは2025年3月、AIエージェントは非決定的であるため、そのテレメトリーは従来の監視に加えて評価と継続的改善のためのフィードバックループという二重の目的を持つと論じ、生成AI向けのセマンティック規約の策定を進めていることを紹介した。日本でも、クラウド会計ソフトのfreeeがLLMの品質管理のためにLangfuseを用いたLLMオブザーバビリティを実践している事例などが報じられている。
AIが生成したコードと可観測性 生成AIによるコーディング支援や、自然言語の指示だけでソフトウェアを組み上げる「バイブコーディング」の広がりは、人間の開発者が細部まで把握していないコードが本番環境で稼働する状況を生んでいる。2025年に発表されたベンチマーク研究は、AIエージェントが生成したコードに脆弱性が残りやすいことを実証的に示した。こうした状況を受けて、オブザーバビリティを安全網と位置づける議論がある。監視ツール開発企業のOneUptimeは2026年2月の論説で、AIが生成した大きな変更を受け入れるほど開発者のエッジケースや障害パターンへの理解は薄くなるとして、「オブザーバビリティは以前から重要だったが、AI支援コーディングはそれを不可欠なものにする」と論じ、分散トレーシング・文脈を持つ構造化ログ・異常検知の整備を求めた。Dynatraceも2026年7月、本番環境のテレメトリーをAIコーディングのフィードバックループに組み込むことで、AIによるコード生成を規律ある工学的実践に発展させられると論じている。
オブザーバビリティへのAI活用 一方、AIをオブザーバビリティを実現する手段として用いる取り組みもある。テレメトリーデータに機械学習を適用してイベントの相関付けや異常検知、原因究明を自動化する手法はAIOpsと呼ばれ、この用語は2016年にガートナーが導入した。生成AIの登場後は、蓄積したテレメトリーに対して自然言語で問い合わせて障害対応を支援する対話型アシスタントも登場しており、Datadogは2023年8月に生成AIベースのアシスタント「Bits」を発表した。誤検知の多発や「アラート疲れ」に悩む運用現場を、AIとオブザーバビリティの組み合わせがどう変えるかという議論も行われている。
日本における動向 日本語圏では2022年前後から技術メディアや専門誌でオブザーバビリティの解説が増え、2023年1月には『オブザーバビリティ・エンジニアリング』の日本語版が刊行された。技術評論社の月刊誌『Software Design』は2025年5月号で「オブザーバビリティの最前線」と題する特集を組んでいる。
企業での導入例も報じられており、NTTドコモは運用作業の自動化と併せてオブザーバビリティ製品を活用し、みずほ銀行は顧客体験と安定稼働の両立を目的にオブザーバビリティを導入したことを公表している。日立製作所は2023年、SREの考え方に基づきオブザーバビリティ導入などを支援するクラウド運用支援サービスを発表した。
関連項目 可観測性 - 制御理論における原義 アプリケーション性能管理 分散トレーシング OpenTelemetry AIOps サイトリライアビリティエンジニアリング
脚注
参考文献