可観測性
Observability ・ かかんそくせい
外に出すデータから内部の状態を推し量れる性質。前もって想定しない問いにも後から答えられる。
✦ 30秒で試す — 航海障害の原因を、誰も作っていないグラフの中から見つけるこのとき、全体のエラー率はどうなる？予想してみる概要
可観測性（Observability、略して o11y）は、システムが外部に出す情報 — 数値・記録・追跡データ — だけを手がかりに、内部で何が起きているかをどれだけ推測できるかという「性質」を指す言葉です。もともとは制御工学の用語で、「出力から内部状態を推定できるシステムは可観測である」という定義を、ソフトウェア運用の世界が借りてきました。
ポイントは、可観測性がツールの名前ではなくシステム側の設計品質だということです。どれだけ高機能なダッシュボードを買っても、アプリケーションが「いま何をしているか」を外に出していなければ中身は見えません。逆に、リクエストごとの文脈を丁寧に出力しているシステムなら、初めて遭遇する障害でも「どのユーザーの、どのリクエストが、どこで詰まったのか」をデータから掘り当てられます。この「事前に想定していなかった問いに、後からデータで答えられる」ことが、可観測性という言葉が担う中心的な価値です。
マイクロサービスやKubernetesのように部品が多く動きが速いシステムが主流になった現在、可観測性はSREの実践を支える土台として、運用を語るうえで欠かせない語彙になっています。
なぜ生まれたか
従来の監視は「既知の問い」に答える仕組みでした。CPU使用率が80%を超えたら知らせる、死活監視に応答しなければ知らせる — つまり「何が壊れうるか」を事前に予想し、その項目にチェックリストを仕掛けておくアプローチです。モノリスを数台のサーバで動かしていた時代は、壊れ方のパターンが限られていたため、これで十分に機能しました。
しかし、システムが数十〜数百のサービスに分割され、コンテナが数分単位で生まれては消える環境になると、障害は「予想したどの項目にも引っかからない形」で起きるようになります。全サービスのダッシュボードは緑なのに、特定の条件を満たすユーザーだけ決済が失敗する — こうした「未知の未知（unknown unknowns）」に対して、事前定義のチェックリストは無力でした。
そこで2010年代後半、「予想できる故障を監視する」発想から「予想できない故障でも後から調査できるだけの手がかりを、システム自身に語らせておく」発想への転換が起こります。これが可観測性です。問いを事前に固定するのではなく、豊かなデータを出しておいて問いは障害が起きてから立てる — 監視の否定ではなく、監視を包含するより広い設計思想として広まりました。
詳細
3本柱 — メトリクス・ログ・トレース
可観測性を構成するデータ（テレメトリと総称します）は、伝統的に3種類に整理されます。第一の柱メトリクスは、リクエスト数やエラー率といった数値の時系列です。集計済みで軽量なため「システム全体がいま健康か」を俯瞰するのに向きますが、集計の過程で個別の事情は失われます。第二の柱ログは、出来事を一件ずつ記録したものです。個別の事情が最も詳しく残る反面、量が膨大で、大量のログから目当ての一件を探すのは骨が折れます。第三の柱分散トレーシングは、1つのリクエストが複数のサービスをまたいで処理される道筋を、一本の線としてつなぎ直したものです。「どのサービス間の呼び出しで時間を食っているか」という、分散システム特有の問いに答えます。
3本柱は「どれか1つを選ぶ」ものではありません。実際の障害調査では、まずメトリクスのグラフで「何かがおかしい」ことに気づき、トレースで「どのサービスのどの処理か」を絞り込み、最後にログで「なぜそうなったか」を突き止める — という動線で3つを行き来します。この行き来をスムーズにするため、近年は3種類のデータにリクエストIDなどの共通の文脈を埋め込み、ワンクリックで相互に飛べるようにする設計が重視されています。
「3本柱」への批判 — 幅の広いイベント
ただし「3本柱」という整理そのものには批判もあります。Honeycomb の Charity Majors らは、3種類を別々の道具で集めても、それだけでは未知の問いに答えられないと指摘しました。メトリクスは集計した時点で個々のリクエストの事情を捨て、ログとトレースは別々の場所に散らばり、つなぐのは人の勘に頼ることになるからです。彼らが代わりに勧めるのは、リクエスト1件ごとに、ユーザーID・アプリの版・プラン・地域・機能フラグ・所要時間・結果といった属性を数十〜数百個まとめて持つ「幅の広い構造化イベント（wide event）」を1つ残すことです。メトリクスはそこから後で集計でき、トレースは時刻と親子の情報を持ったイベントの連なりとして表せます。
この考え方の核心は、どの属性で切るかを、障害が起きてから決められることです。前もって用意したダッシュボードは、用意した軸（たとえば地域）でしか切れません。事象ごとに属性が残っていれば、「アプリの版 × カードの種類」のような、誰も予想していなかった組み合わせで後から分けられます。下の部品で、全体の数字は平穏なのに一部の決済だけが失敗している状況を、属性で分けて探ってみてください。朱の点を押すと、その1件をメトリクス・トレース・ログの3つの窓が同じ瞬間で指します。
決済の失敗（朱の点）は全体の2.8%で、閾値5%の下です。地域別のダッシュボードもすべて緑。それでも一部のユーザーは決済できずに困っています。上の属性の札をドラッグして「列」「行」に置き、点をグループ分けしてください（札を押しても置けます）。
監視と可観測性の関係
両者は対立概念ではなく、問いの性質が違います。監視は「既知の問い」を常時チェックし続ける活動で、アラートによって異常を人に知らせる出口を持ちます。可観測性は「未知の問い」に事後から答えられる能力で、探索的な調査を支えます。実務では「監視で気づき、可観測性で理解する」と役割分担して捉えると整理しやすいでしょう。監視だけのシステムは「壊れたことは分かるが、なぜかは分からない」状態に、逆に高カーディナリティなデータを溜めるだけで監視の仕組みがないシステムは「調べれば分かるが、壊れたことに気づけない」状態に陥ります。両輪です。
計装と OpenTelemetry
システムにテレメトリを出力させる作業を「計装（instrumentation）」と呼びます。かつては監視ベンダーごとに独自のエージェントやSDKを組み込む必要があり、ベンダーを乗り換えると計装をやり直すロックインが問題でした。この状況を変えたのが、CNCF（Cloud Native Computing Foundation）の標準仕様 OpenTelemetry です。メトリクス・ログ・トレースの生成と送出をベンダー中立な API・SDK・プロトコル（OTLP）に統一し、「計装は一度だけ、送り先は自由に選ぶ」を実現しました。主要言語のフレームワークには自動計装（コードをほぼ書かずにHTTPリクエストやDB呼び出しを追跡する仕組み）も整い、現在では計装のデファクトスタンダードになっています。
実務の論点 — カーディナリティとコスト
可観測性の実務で最初にぶつかる壁がカーディナリティ、つまり「データに付けるラベルの値が何通りあるか」です（メトリクスの記事で、ラベルを付けて本数を数えられます）。未知の問いに答えるには、ユーザーIDやリクエストIDのような高カーディナリティの属性が欲しくなりますが、メトリクスの時系列はラベルの組み合わせごとに増えるため、安易に付けると保存コストと検索速度が破綻します。このため「俯瞰は低カーディナリティのメトリクスで、深掘りは高カーディナリティを許容するログ・トレースで」という住み分けや、全リクエストではなく一部だけを記録するサンプリングが設計の要所になります。テレメトリの転送・保存コストはクラウド請求の中でも膨らみやすい項目であり、「何を、どの解像度で、どれだけの期間残すか」を決めることが、可観測性エンジニアリングの実質的な仕事の大半を占めます。
観測できることは、改善できることの前提です。SLOの計測も、インシデント対応の初動も、カオスエンジニアリングの仮説検証も、すべて「システムの状態がデータとして見えている」ことの上に成り立ちます。可観測性は派手さのない裏方の性質ですが、信頼性に関わる語彙の多くがここを土台にしています。
試問
1時間ぶんの決済リクエスト600件が点で並んでいます（朱の点が失敗）。全体のエラー率も、地域別のダッシュボードも、警報の線（5%）の下で緑です。リクエストごとに地域・アプリの版・プラン・カードの属性が記録してあり、その札を「列」「行」の枠に置く（札を押しても置ける）と点がグループに分かれ、朱の点を押すとその1件の中身が開きます。
決済の失敗（朱の点）は全体の2.8%で、閾値5%の下です。地域別のダッシュボードもすべて緑。それでも一部のユーザーは決済できずに困っています。上の属性の札をドラッグして「列」「行」に置き、点をグループ分けしてください（札を押しても置けます）。