Observability

Observabilityとは、システムが外部へ出すtelemetryを手掛かりに、内部で何が起きているかを理解・診断できる性質や、そのための計測基盤を指します。

Observabilityとは何か

Observability（オブザーバビリティ、可観測性）は、システムが外へ出している情報から、その内部で何が起きているかを理解できる性質を指します。ソフトウェア運用では、logs、metrics、tracesなどのtelemetryを集め、障害、遅延、異常、依存関係、利用状況を調べられる状態を作ることまで含めて使われます。

OpenTelemetryはObservabilityを、「システムの出力を調べることで内部状態を理解する能力」と説明しています。単にCPU使用率を表示するダッシュボードがある、エラー数を数えている、というだけでは十分ではありません。予想していなかった問題が起きたときに、「どのrequestで、どのserviceを通り、何が遅れ、どのversionで失敗したのか」を後からたどれることが重要です。

Logs・Metrics・Traces

Observabilityでよく出る三つのsignalがlogs、metrics、tracesです。

Metricsは、一定時間の数値を集約したものです。CPU使用率、request数、error rate、latencyのp95、GPU使用率、token消費量などが該当します。全体傾向を素早く把握するのに向きます。

Logsは、ある時刻に起きたeventやmessageを記録します。例外stack、認証失敗、model load失敗、tool callの結果など、個別の出来事を詳しく残せます。

Tracesは、一つのrequestや処理が複数componentをどう通ったかを関連付けます。分散システムでは、front end→API→retrieval→model server→databaseのような流れを一つのtraceとして追えます。

この三つは競合するものではありません。Metricで「latencyが上がった」と気付き、traceで遅いrequestを特定し、logでそのserviceの具体的errorを確認する、といった組み合わせで使われます。

Monitoringとの違い

MonitoringとObservabilityは重なりますが、実務では少し役割が違います。Monitoringは「CPUが90%を超えたらalert」「error rateを毎分測る」のように、事前に決めた指標や閾値を追跡する意味で使われることが多いです。

Observabilityは、それより広く「なぜそうなったのか」を探索できる状態を目指します。OpenTelemetryのprimerでは、既知の問題だけでなくunknown unknownsを扱う点が強調されています。

ただし、両者を厳密に別概念として使わない製品もあります。「Observability platform」がMonitoring機能を含むのは普通です。用語のラベルより、実際に何を計測し、どこまで原因を追えるかを見る方が重要です。

AIシステムでは何を観測するのか

AIシステムでは、通常のsoftware telemetryに加え、モデル固有の情報が必要です。たとえばmodel version、prompt/template version、input length、output length、token数、latency、cache hit、retrieval結果、tool call、model error、safety filter、costなどです。

機械学習モデルなら、data drift、prediction drift、model performance、data qualityも重要です。Azure Machine LearningのModel Monitoringは、production inference dataとreference dataを比較し、data driftやprediction drift、data qualityなどを継続的に計測できます。

LLMやAI agentでは、一つのuser requestの中で複数回model callが起き、retrievalやtool useを挟み、retryすることがあります。総latencyだけ見ても原因は分かりません。traceで各stepを分解し、どこで時間やcostを使ったかを見られると、改善しやすくなります。

「全部記録すればよい」わけではない

Observabilityを高めるためにtelemetryを増やすと、storage cost、network cost、query costも増えます。高trafficサービスで全requestの詳細traceを永久保存するのは現実的でないことがあります。そのためsamplingやretention policyを設計します。

さらにAIではprivacyが大きな問題です。promptやretrieval document、tool outputをそのままlogへ保存すると、個人情報、機密文書、認証情報がtelemetry基盤へ流れる可能性があります。Observabilityのためのデータ収集が、新しい情報漏えい経路になり得ます。

したがって、redaction、access control、encryption、retention、samplingを含めて設計する必要があります。「詳細traceを取れる」ことと「何でも保存してよい」ことは別です。

Instrumentationが必要

OpenTelemetryは、systemをobservableにするにはinstrumentationが必要だと説明しています。Application codeやlibraryがtelemetryを出さなければ、backend側だけ用意しても内部状態は見えません。

自動instrumentationで取得できる情報もありますが、AI固有の文脈はapplication側で追加することがあります。たとえばmodel_version=2026-09-12、retrieval_top_k=10、tool=web_searchのようなattributeをspanに付けると、問題の切り分けが容易になります。

ただしattributeのcardinalityが高すぎると、backendのcostやquery性能へ影響する場合があります。観測項目は「取れるから取る」のではなく、運用上の問いに答えられるよう設計します。

AI製品の「Observability対応」をどう読むか

ベンダーが「AI Observability」をうたっていても、対象範囲は製品ごとに違います。Infrastructure metrics中心のものもあれば、LLM trace、prompt、evaluation、drift、costまで扱うものもあります。

確認したいのは、第一にsignalsです。logs、metrics、tracesのどれが取れるのか。第二にcorrelationです。同じrequest、session、user、model versionを跨いで関連付けられるか。第三にAI固有signalです。token、retrieval、tool call、model qualityを見られるか。第四にprivacyです。promptやoutputを保存するか、maskできるか。

そして最も重要なのは、「alertが出た後に原因へたどり着けるか」です。異常を知らせるだけならMonitoringとして有用でも、Observabilityとしての診断能力は限定的かもしれません。

元の文脈へ戻るためのポイント

Observabilityという言葉を見たら、「何を観測しているか」「どの粒度で相関できるか」「未知の問題を後から分析できるか」を確認してください。

AIシステムでは、単にserverが生きているかを見るだけでは不十分です。Infrastructureが正常でも、model qualityが落ちている、retrievalが外れている、tool callがloopしている、costだけ急増していることがあります。

Observabilityは、AIモデルの正しさを自動的に保証する仕組みではありません。内部で起きていることを外部signalから理解し、問題を発見・説明・切り分けるための能力です。この境界を押さえると、「監視」と「可観測性」の宣伝文句をより具体的に評価できます。

関連AI用語

• G256 — Tracing
• G257 — Model Monitoring
• G231 — LLMOps

注・出典

主要参照資料：^[1][2][3]

1. OpenTelemetry What is OTel — Observabilityは出力からシステム内部状態を理解する能力で、softwareではtraces、metrics、logs等のtelemetryを分析して実現する。 ↩
2. OpenTelemetry Primer — Observabilityは外部から内部を理解し、unknown unknownsを含む問題へ問いを立てられること、適切なinstrumentationが必要であることを説明。 ↩
3. Azure Model Monitoring — ML運用ではproduction inference dataとreference dataから複数signalを継続計測し、drift、data quality、performanceなどを監視する。 ↩

AI協働制作について