🔭
オブザーバビリティ分散システムログトレースメトリクスAIエージェント 2026年4月2日

オブザーバビリティ(Observability)

📁 概念 👁 -- 閲覧

オブザーバビリティ(Observability)

定義

システムの外部出力(ログ・トレース・メトリクス)だけを見て、内部状態を推測・診断できる度合い。

「モニタリング(既知の失敗を検知)」と異なり、オブザーバビリティは未知の問題を探索・診断できる能力を指す。

なぜ重要か

分散システムにおける障害の性質

モノリシックなシステムでは「どこで壊れたか」がスタックトレース1つで分かる。 分散システムでは、リクエストが複数のサービスをまたいで処理されるため:

  • ユーザーから見た失敗(エラー応答・タイムアウト)の根因が、別サービスの奥深くに隠れている
  • あるサービスが正常でも、依存先の遅延がカスケード障害を引き起こす
  • ログを単独サービスで見ても全体像がつかめない

→ サービス間のリクエストの流れを一本の糸として追跡できなければ、診断が不可能になる。

AIエージェントシステムにおけるトレースの必要性

AIエージェントは以下の特性により、可観測性の難易度が通常のAPIより高い:

  • 非決定的な実行フロー:LLMの判断によって呼び出すツール・ステップ数が変わる
  • 多段階の連鎖:プランニング → ツール実行 → 評価 → 再試行が動的に組み合わさる
  • 長い実行時間:非同期・バックグラウンド処理が多く、途中の状態が不可視になりやすい

→ どのステップで・なぜ・どんな判断をして・どこで失敗したかを追跡するトレースが必須。

3本柱の棲み分け

シグナル問いに答える問い用途
構造化ログ何が起きたか(個別イベント)特定リクエストの詳細診断、監査
トレースどこを通ったか(リクエストの経路)サービス間レイテンシ、根因特定
メトリクスどのくらいの頻度・量で起きているか(集計)アラート、容量計画、SLO監視

Google SREの定義では、監視すべき4つのゴールデンシグナルとして以下を挙げる:

  • レイテンシ(成功・失敗それぞれ)
  • トラフィック(リクエスト数)
  • エラー率
  • 飽和度(リソースの使用率)

langfuse と OpenTelemetry の棲み分け

ツール対象強み
OpenTelemetryあらゆる分散システム汎用計装標準。ログ・トレース・メトリクスすべてをカバー
LangfuseLLM / AIエージェント特化プロンプト・補完・トークンコスト・評価スコアを可視化

AIエージェントシステムでは両者を層ごとに使い分けるのが現実的:

  • インフラ・サービス間通信 → OpenTelemetry
  • LLM呼び出し・エージェントの判断フロー → Langfuse

OpenTelemetryはLangfuseへのエクスポートにも対応しているため、計装は統一しつつ用途別に転送することも可能。

適用場面

  • 分散システムの障害診断・ポストモーテム
  • AIエージェントの応答品質・コスト・レイテンシの継続的改善
  • SLO/SLAの達成状況の可視化

関連概念

出典