目次
マルチエージェントの作り方で「増やす前にすべてのハンドオフを計測せよ」と書いた。その「計測」を本番で支える技術がAIオブザーバビリティ（可観測性）だ。LLMやエージェントが本番で実際に何をしているか——どのツールを呼び、何を検索し、どこで失敗し、いくらかかったか——を見えるようにする。
普通のアプリ監視と違い、AIには厄介な特徴がある。「200 OK・50msで返ってきても、堂々と嘘（ハルシネーション）をついている」ことがある。つまり速くて落ちていなくても、品質が壊れている。本記事は、オブザーバビリティの3本柱、評価（Evals）との違い、見るべきメトリクス、主要ツールまでを初心者向けに整理する。
1リクエストの「実行の木」を可視化する
— トレース＝入力・ツール呼び出し・検索・出力をスパンで記録
※本記事のツールの特徴・概念は各種公表資料・公式情報の引用（2026年6月時点）。ツールの評価は用途・バージョンで変わるため、傾向の参考に。
1. AIオブザーバビリティとは？
AIオブザーバビリティとは、LLMやAIエージェントが本番環境で何をしているかを、外から観測・把握できる状態にすること。リクエストごとに「どのモデルを・どんなプロンプトで呼び、どのツールや検索を使い、何を返し、何秒・いくらかかったか」を記録し、問題が起きたときに原因まで遡れるようにする。
普通のアプリ監視との決定的な違い：従来の監視は「落ちていないか・速いか」を見る。だがAIは正常に・高速に応答しながら、内容が間違っていることがある。AIの障害の多くはインフラ障害ではなく「品質障害」——ハルシネーション、検索の失敗、安全でない回答、タスク未完了、ツールの誤用、プロンプト変更後の劣化だ。
だからAIには専用の観測が要る。とくにマルチエージェントでは、失敗が「個々の呼び出し」ではなく多段の因果連鎖の中に現れる。「どのステップで・なぜズレたか」は、セッション全体のトレースを取って初めて見える。
2. 3本柱：トレース・メトリクス・ログ
オブザーバビリティは伝統的に3本柱で語られる。AIでも同じで、業界標準のOpenTelemetry（GenAI規約）がこの3つをベンダー非依存の共通スキーマで扱えるようにしている。
トレース（Traces）
1リクエストの実行経路をスパンの木で記録。LLM呼び出し・ツール・検索・推論連鎖がどう流れたかが見える。AI観測の主役。
メトリクス（Metrics）
レイテンシ・コスト・トークン数・エラー率・スループットを数値で集計。モデル/エージェント別に傾向を追える。
ログ（Logs）
個別イベントの詳細記録。プロンプト全文・エラー内容など、深掘り調査の根拠になる。
OpenTelemetryのGenAI規約は、プロンプト・モデルの応答・トークン使用量・ツール/エージェント呼び出し・プロバイダ情報を標準フォーマットで記録する。これにより、特定ベンダーに縛られず、Datadog・Grafanaなど既存の監視基盤にもAIのトレースを流し込める。
3. 評価（Evals）との違い
初心者が最も混同しやすいのが「オブザーバビリティ」と「評価（Evals）」の違いだ。両者は別物で、セットで初めて意味を持つ。
🔭 オブザーバビリティ
「何が起きたか」を見る。トレース・コスト・レイテンシ・エラー。計測は簡単だが、これだけでは「答えが正しいか」は分からない。
✅ 評価（Evals）
「答えの質が良いか」を測る。正確さ・根拠の有無・安全性。明示的なEvalsが必要で、ここが品質の番人になる。
キモは「コストとレイテンシは簡単に測れるが、答えの質は明示的な評価がないと分からない」こと。だから2026年の主要ツールは、トレースを見せるだけでなく、出力をスコアリングし、品質の劣化をアラートし、開発に戻すループまで一体で提供する。観測と評価は、車の両輪だ。
4. 何を見るか：主要メトリクス
実際にダッシュボードで追うべき指標は、大きく「運用系」と「品質系」に分かれる。
⚙️ 運用系（測りやすい）
- コスト：1リクエストあたりのトークン課金
- レイテンシ：応答時間（入力で大きく変動）
- トークン使用量：肥大したプロンプトの早期検知
- エラー率・スループット：モデル/エージェント別
🎯 品質系（評価が必要）
- ハルシネーション：事実と異なる断定
- 根拠性（groundedness）：RAGで最重要・検索結果に基づくか
- 安全性：PII漏えい・有害な出力
- タスク完了度・ツール使用の正しさ
品質系の中でも、RAG（検索拡張生成）では「根拠性（faithfulness）」が最重要指標。回答が検索した文書に実際に支えられているか、それともモデルが勝手に創作したかを見る。ハルシネーション検知にはLLM-as-a-judge（AIに採点させる）・意味的類似度・根拠性スコアがよく使われる。
5. 主要ツール比較
2026年の代表的なAIオブザーバビリティ・ツールを整理する。多くはトレースと評価を一体で提供する方向に進んでいる。
| ツール | 特徴 | 向いている用途 |
|---|---|---|
| LangSmith | LangChain/LangGraphと相性◎。詳細トレース＋評価＋監視。オーバーヘッドが小さい。 | LangChain系の本番 |
| Langfuse | オープンソース。セルフホスト可能でデータを外部SaaSに出さずに済む。 | 自社運用・データ要件が厳しい場合 |
| Arize Phoenix | RAGのデバッグに強い。検索品質の可視化が得意。 | RAGの調査・改善 |
| MLflow | GenAIのライフサイクル全体を一元管理。 | 開発〜運用を通したい場合 |
| AgentOps | 自律エージェントの監視に特化。多段セッションの追跡。 | エージェント運用 |
| OpenTelemetry | 標準規格。ベンダー非依存でDatadog/Grafana等に接続。 | 既存監視基盤への統合 |
出典：各種ツール比較・公式情報の引用（2026年6月）。特徴は傾向で、用途やバージョンにより評価は変わる。
迷ったら、まずOpenTelemetry準拠でトレースを取り始めるのが安全。ベンダーロックインを避けつつ、後からツールを選び直せる。LangChainを使っているならLangSmith、データを自社に置きたいならLangfuseが入口になりやすい。
6. 始め方とエージェントでの重要性
難しく考えず、小さく始めればよい。重要なのは「本番に出す前から」観測を入れておくことだ。
とくにマルチエージェントでは、観測は「あれば便利」ではなく必須。失敗が多段の連鎖に隠れるため、セッション全体のトレースがないと「どこで・なぜ壊れたか」が永遠に分からない。エージェントを増やす前に、まず観測を入れる——これが鉄則だ。セキュリティ事故の早期発見にも効く。
まとめ
AIオブザーバビリティは、本番のAIを「見えるようにする」運用の基盤だ。要点を振り返ろう。
この記事の要点
- 🔭 本番のAIの中身を可視化する仕組み。トレース・メトリクス・ログの3本柱。
- ⚠️ 200 OKでも嘘はつく。AIの障害の多くはインフラでなく「品質障害」。
- 🔁 観測＋評価の両輪。トレースで「何が」、Evalsで「質が良いか」を見る。
- 🛠️ ツール：LangSmith/Langfuse/Phoenix/MLflow/AgentOps。標準はOpenTelemetry。
- 🤖 エージェントでは必須。多段の失敗はセッション全体のトレースでしか見えない。
「速くて落ちていない」だけでは、AIは安心して任せられない。中身が見えて、質を測れて初めて本番品質だ。まずはOpenTelemetry準拠でトレースを取り、評価を接続するところから始めよう。エージェントの作り方はこちら、安全設計はガードレールへ。
FAQ
Q. オブザーバビリティと評価（Evals）は何が違う？
A. オブザーバビリティは「何が起きたか」（トレース・コスト・レイテンシ）を見るもの、評価は「答えの質が良いか」を測るものです。速くて落ちていなくても内容が誤っていることがあるため、両方をセットで使うのが基本です。
Q. 普通のアプリ監視ツールではダメ？
A. 落ちていないか・速いかは測れますが、ハルシネーションや根拠性といったAI特有の品質は捉えられません。AI向けにはプロンプト・トークン・ツール呼び出しを記録する専用の観測（またはOpenTelemetry GenAI規約）が必要です。
Q. 何から始めればいい？
A. まずOpenTelemetry準拠でトレースを取り始めるのが安全です。ベンダーロックインを避けられ、後からLangSmithやLangfuseなどのツールを選び直せます。次にコスト・レイテンシを可視化し、最後に評価を接続します。
Q. エージェントだとなぜ特に重要？
A. エージェントの失敗は1回の呼び出しではなく、複数ステップの因果連鎖の中に現れます。セッション全体のトレースがないと「どのステップで・なぜズレたか」を特定できず、デバッグが不可能になるためです。
