AIオブザーバビリティ：本番環境でのLLM監視に関する完全ガイド【2026年版】

AIオブザーバビリティとは、LLMアプリケーションとサイレントな障害との間にある唯一の防壁です。500エラーを投げてクラッシュするサーバーとは異なり、言語モデルは自信満々に間違った答えを返すだけで、スタックトレースもエラーコードも、何も出てきません。だからこそ、従来の監視ツールではここでは通用しないのです。

AIオブザーバビリティの全体像

詳しく入る前に、スクリーンショットを撮ってチームに共有できる要約をここにお示しします。

では、AIオブザーバビリティを皆さんがすでに知っている監視と根本的に異なるものにしている点から、各要素を一つずつ分解していきましょう。

AIオブザーバビリティとは何か（そしてなぜ監視と違うのか）？

AIオブザーバビリティとは、LLMシステムの内部で何が起きているかを理解する能力のことです。単に動いているか止まっているかだけでなく、なぜ特定の入力に対して特定の出力が生成されたのかを理解することです。これは、分散トレーシング、リアルタイムメトリクス、自動化された品質評価、アラートを一つのフィードバックループに統合したものです。

では、それは単なる監視とどう違うのでしょうか？ このように考えてみてください。監視は、レスポンスレイテンシが8秒に急上昇したことを教えてくれます。オブザーバビリティは、なぜそうなったのかを教えてくれます。誰かが埋め込みの閾値を変更したせいで、検索ステップが5個ではなく47個のチャンクを返し、それがコンテキストウィンドウを溢れさせ、モデルにより長く遅い応答を生成させていた、という具合に。

Datadog、New Relic、Grafanaのような従来のAPMツールは、決定論的な世界を前提に作られています。HTTPステータスコード、CPU使用率、メモリリーク。これらは把握可能で再現可能な状態です。LLMはその前提を完全に覆します。同じプロンプトを2回送れば、2つの異なる応答が返ってきます。比較するための「期待される出力」もなく、検証するスキーマもなく、取りうる戻り値の列挙型もありません。

この非決定性こそが、AIシステムに独自のオブザーバビリティ層が必要である核心的な理由です。皆さんが追跡しているのはインフラの健全性だけではありません。4つの柱にまたがる出力の品質を追跡しているのです。

• データ品質 — RAGのドキュメントは最新か？ 埋め込みはドリフトしていないか？
• モデルの振る舞い — モデルは先週よりハルシネーションを起こしていないか？ プロバイダーのアップデートで出力パターンが変わっていないか？
• インフラのパフォーマンス — レイテンシ、スループット、エラー率、キャッシュヒット率
• パイプラインの完全性 — チェーン内のすべてのステップが正しい順序で正しい入力をもって実行されているか？

監視は何かが壊れたことを教えてくれます。オブザーバビリティはその理由を教えてくれます。そして、システムの障害が成功とまったく同じように見えるとき、この違いははるかに重要になります。

なぜAIシステムには専門的なオブザーバビリティが必要なのか

「LLM呼び出しをロギングで包んでおけば十分だろう」と考えているかもしれません。なぜそれが長続きしないのか、理由をお話しします。

サイレントな障害がデフォルトです。 従来のAPIが失敗すると、エラーが返ってきます。LLMが失敗すると、もっともらしく聞こえるが完全に間違っている段落が返ってきます。ユーザーは気づきすらしないかもしれません。ハルシネーションされたデータに基づいて意思決定をしてしまうだけです。ライブトラフィックに対して品質評価を走らせていなければ、目隠しをして飛んでいるのと同じです。

コストは警告なしに爆発します。 最適化されていないエージェントループ一つで、一晩に数百ドル分のトークンを燃やし尽くすことがあります。私の知るチームは、リトライループが毎回フルの会話コンテキストでGPT-4を叩き続けたせいで、3,200ドルの請求書を見て朝を迎えました。トークンレベルのコスト配分はオプションではなく、生存の問題です。

モデルドリフトは目に見えません。 OpenAI、Anthropic、Googleは定期的にモデルを更新しています。変更がユースケースを改善することもあれば、壊すこともあります。ベースラインの品質メトリクスと自動化された評価がなければ、ユーザーが不満を言うか去っていくまで、品質の劣化に気づくことはありません。

エージェントは問題を倍増させます。 シンプルなチャット補完は1回のLLM呼び出しです。エージェントは5〜20回の呼び出しを連鎖させ、ツールを使い、意思決定を行い、行き詰まれば引き返すこともあります。セッションレベルのトレーシングなしにエージェントの悪い出力をデバッグするのは、print文だけで分散システムをデバッグするようなものです。不可能ではありませんが、苦痛です。

コンプライアンスはオプションではありません。 LLMがPII、有害なコンテンツ、偏った出力を生成する場合、監査証跡が必要です。「モデルがやったことです」は規制当局にとって許容できる答えではありません。オブザーバビリティは、こうした問題を調査し防止するためのトレースレベルの証拠を提供します。

AIオブザーバビリティの背後にあるトレーシングアーキテクチャ

トレーシングはAIオブザーバビリティの背骨です。マイクロサービス向けの分散トレーシングを使ったことがあれば、概念はおなじみでしょう。ただし、LLMのトレーシングにはいくつか重要なニュアンスが加わります。

トレースは1つのエンドツーエンドの操作を表します。LLMの文脈では、通常は1件のユーザーリクエストです。各トレースにはスパンが含まれます。「クエリを埋め込む」「ドキュメントを検索する」「応答を生成する」「ガードレールチェックを実行する」といった個々のステップです。スパンはネストできます。RAGパイプラインのトレースには、検索スパンと生成スパンを含む親スパンがあり、それぞれが独自のタイミング、トークン数、メタデータを持つ、といった形です。

ここでの大きな改善は、Generative AI向けOpenTelemetryセマンティック規約です。これらの規約は、LLMテレメトリの命名と構造を標準化するもので、gen_ai.system、gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.usage.output_tokensといった属性が含まれます。この標準化により、トレースはバックエンド間でポータブルになります。OTELで一度計装すれば、今日はLangfuseに送り、明日はDatadogに切り替えることができます。

LLM呼び出しに対する基本的なOpenTelemetry計装は次のようになります。

from opentelemetry import trace
from opentelemetry.semconv.ai import SpanAttributes

tracer = trace.get_tracer("my-llm-app")

def call_llm(prompt: str, model: str = "gpt-4o") -> str:
    with tracer.start_as_current_span("llm.chat") as span:
        span.set_attribute("gen_ai.system", "openai")
        span.set_attribute("gen_ai.request.model", model)
        span.set_attribute("gen_ai.usage.input_tokens", len(prompt.split()) * 1.3)

        response = openai_client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": prompt}]
        )

        span.set_attribute("gen_ai.usage.output_tokens", response.usage.completion_tokens)
        span.set_attribute("gen_ai.response.model", response.model)
        return response.choices[0].message.content

RAGパイプラインでは、トレースはより豊かになります。親スパンがリクエスト全体を包み、子スパンとして埋め込み、ベクトル検索、リランキング、生成が続きます。各スパンは独自のレイテンシ、トークン数、カスタム属性（取得したチャンク数や類似度スコアの閾値など）を持ちます。このネスト構造こそが、遅い応答や低品質な応答のどこで問題が起きたのかを正確に特定できるようにするものです。

主要なオブザーバビリティプラットフォーム（Langfuse、Braintrust、Arize）は、OTELトレースをネイティブに受け入れるか、同等のトレース構造を生成する軽量なSDKを提供しています。トレンドは明らかにOTELを共通標準とする方向に向かっているので、今OTEL計装に投資しておくことで、将来の柔軟性が最大化されます。

LLMにとって実際に重要なメトリクスは何か？

すべてのメトリクスが同じ価値を持つわけではありません。追跡すべきものを、お金の節約やインシデント防止にどれだけ早くつながるかという観点で、おおよその順位をつけて紹介します。

レイテンシは最初のシグナルです。P50、P95、P99を個別に追跡してください。P50は典型的な体験を、P99は最も不運なユーザーにとってどれほど悪くなりうるかを教えてくれます。体感速度がすべてであるストリーミングアプリケーションでは、最初のトークンまでの時間（TTFT）が重要です。

トークン使用量はコストと品質を同時に左右します。リクエストごとの入力トークン、出力トークン、合計を追跡してください。入力トークンの急激な増加は、RAGの検索がチャンクを返しすぎていることを意味するかもしれません。出力トークンの急増は、モデルが過剰に説明しているか、冗長なループに陥っていることを意味するかもしれません。

コスト配分はトークン数を金額に変換します。リクエストごと、ユーザーごと、機能ごと、モデルごとに分解してください。ここで、ユーザーの5%がコストの60%を生み出していることや、要約機能が検索機能より10倍高価であることを発見するでしょう。

モデル間のコスト差は驚くほどです。シンプルなクエリを小さいモデルに振り分け、GPT-4oやClaude Sonnetを複雑なものに取っておくことで、品質の目に見える低下なしに請求額を60〜80%削減できます。ただし、どのクエリが「シンプル」かを知るには、メトリクスが必要です。

品質スコアは追跡が難しいものの、最終的には最も重要です。これにはカスタム評価スコア（次節で詳しく述べます）、RAGシステムのハルシネーション率、モデルの出力が取得したコンテキストに基づいているかを測る忠実性（faithfulness）メトリクスが含まれます。

運用メトリクスが全体像を完成させます。APIエラー率、ガードレール発動率、タイムアウト率、キャッシュヒット率、フォールバック発動回数です。タイムアウト率の上昇は、プロバイダーにキャパシティの問題が起きていることを意味するかもしれません。キャッシュヒット率の低下は、ユーザーがより多様な質問をしていることを意味するかもしれません。

評価ループはどうやって品質のギャップを埋めるのか？

十分な数のチームが内面化していない見解を一つ。評価はテストの関心事ではなく、オブザーバビリティの関心事です。 評価は、デプロイ前のCI/CDパイプラインだけでなく、本番トラフィックに対して継続的に実行されるべきです。

理由はシンプルです。ユーザーが送ってくるすべての入力を予測することはできません。デプロイ前のテストスイートは既知のパターンをカバーしますが、本番トラフィックは奇妙で、敵対的で、絶えず変化します。ライブリクエストのサンプルに対して品質チェックを実行するオンライン評価は、テストスイートが想像もしなかった障害を捕まえます。

LLM-as-a-judgeは、自動化されたオンライン評価で最も実用的なパターンです。別のモデル（多くの場合より安価なもの）を使って、関連性、忠実性、有用性、安全性といった次元で別のモデルの出力をスコアリングします。完璧ではありません。判定モデルにも独自のバイアスがあります。しかし、無限にスケールし、品質問題の大部分を捕まえます。

Hamel Husainが主張するように、評価はAI開発ライフサイクルにおいて、ほぼすべてのことに先んじるべきです。測れないものは改善できません。最小限のLLM-as-a-judge関数は次のとおりです。

async def evaluate_faithfulness(question: str, context: str, answer: str) -> float:
    """Score whether the answer is grounded in the provided context (0.0-1.0)."""
    judge_prompt = f"""Rate whether this answer is faithful to the context.
    Question: {question}
    Context: {context}
    Answer: {answer}
    Return only a score between 0.0 (hallucinated) and 1.0 (fully grounded)."""

    response = await openai_client.chat.completions.create(
        model="gpt-4o-mini",  # cheap judge model
        messages=[{"role": "user", "content": judge_prompt}],
        temperature=0
    )
    return float(response.choices[0].message.content.strip())

関連性、毒性、一貫性といった評価メトリクスのより深い考察については、Confident AIの評価メトリクスガイドが、実践的なスコアリング基準とともにそれぞれを分解して解説しています。

Human-in-the-loop評価は、自動化されたアプローチを補完します。ドメインエキスパートが本番トレースのサンプルにアノテーションを付け、悪い出力にフラグを立て、スコアを修正し、エッジケースにラベルを付けます。これらのアノテーションは評価データセットにフィードバックされ、自動化された評価を時間とともに賢くしていきます。

その結果生まれるのが、私が評価のフライホイールと呼ぶものです。本番の出力を観察し、品質を評価し（自動化＋人間）、プロンプトと検索を改善し、変更をデプロイし、再び観察する。各サイクルがシステムを測定可能な形で良くしていきます。このフライホイールを毎週回しているチームは、四半期ごとの評価スプリントしかやらないチームでは到底及ばない品質改善を達成します。

AIエージェントの観測：2026年の課題

単一のLLM呼び出しの観測が難しいとすれば、エージェントは一桁難しいです。エージェントはテキストを生成するだけでなく、推論し、計画し、ツールを使い、意思決定し、時には引き返します。1件のユーザーリクエストが5回、10回、あるいは50回のLLM呼び出しを引き起こし、それぞれが前の呼び出しの上に積み重なることもあります。

本番環境にエージェントをデプロイしようとしているなら、まずビジネス向けAIエージェントを理解してから、オブザーバビリティ層のためにここに戻ってくることをおすすめします。

根本的なシフトは、リクエストレベルのトレーシングからセッションレベルのトレーシングへの移行です。単一のエージェントセッションは数分から数時間にまたがり、複数のツール呼び出し、メモリ検索、サブエージェントへの委譲を含むことがあります。トレースは、個々のLLM呼び出しだけでなく、意思決定の木全体を捉える必要があります。

エージェントのトレーシングが、標準的なLLMトレーシングにはない捉えるべきものは次のとおりです。

• ツール呼び出しとその結果 — エージェントはどのツールを呼び出したか？ 何を返したか？ エージェントはその結果を正しく解釈したか？
• 推論の連鎖 — 各ステップでエージェントの計画は何だったか？ セッション途中でアプローチを変えたか？
• マルチエージェントシステムでのハンドオフ — あるエージェントが別のエージェントに委譲するとき、トレースはそのハンドオフをクリーンに追跡する必要がある
• 状態遷移 — エージェントの意思決定をステップごとにリプレイし、各意思決定時点での完全なコンテキストを確認できる能力
• トークンバジェット — エージェントは直接のLLM呼び出しの10〜100倍のトークンを消費することがある。セッションごとの累積トークン消費の追跡は、コスト管理に不可欠

OpenTelemetryコミュニティは、エージェント固有のトレーシング標準に積極的に取り組んでおり、GenAIセマンティック規約を、ツール呼び出し、計画ステップ、エージェントのハンドオフ用のスパンタイプで拡張しています。まだ進化の途上ですが、方向性は明確です。エージェントには、後付けのワークアラウンドではなく、オブザーバビリティスタック内でのファーストクラスのサポートが必要です。

実際問題として、現時点でエージェントのトレーシングに最も適しているツールはLangfuseとBraintrustです。どちらもセッションレベルのグルーピング、ネストされたマルチステップのトレース、ツール呼び出しの帰属をサポートしています。LangChainやLangGraphで構築しているなら、LangSmithは思考の連鎖の可視化を含む深いネイティブ統合を提供します。

AIオブザーバビリティツールの比較：どれを選ぶべきか？

ツールの状況は2024年以降、爆発的に拡大しました。2026年に評価する価値のある8つのプラットフォームと、それに続く比較マトリクスを紹介します。

**Langfuse**はオープンソースのリーダーです。MITライセンスで、セルフホスト可能、v3以降は完全にOpenTelemetryネイティブです。トレーシング、評価、プロンプト管理、コスト追跡をカバーします。データの完全なコントロールとベンダーロックインのゼロを求めるなら、Langfuseがデフォルトの選択肢です。

**Braintrust**は評価ファーストのアプローチを取ります。そのスコアリングフレームワークは、このカテゴリーでおそらく最高です。カスタムスコアラーを定義し、本番トラフィックで実行し、品質のトレンドを時間とともに追跡します。出力品質が最優先のチームに最適です。

**Arize Phoenix**は従来のMLオブザーバビリティの世界から来ています。オープンソース（BSDライセンス）で、ドリフト検出と埋め込みクラスタリングに強く、LLMにおなじみの概念を適用したいMLエンジニアリングのバックグラウンドを持つチームに特に適しています。

**Helicone**は根本的に異なるアプローチを取ります。プロキシなのです。LLMトラフィックをHelicone経由でルーティングすれば、文字どおりコード変更ゼロでトレーシング、コスト追跡、キャッシュが手に入ります。セットアップの速さが最優先なら、これに勝るものはありません。

LangSmithはLangChainチームによるオブザーバビリティプラットフォームです。すでにLangChainやLangGraphを使っているなら、統合はスムーズで、深いチェーンのトレーシング、プレイグラウンドでのデバッグ、データセット管理が得られます。トレードオフはLangChainエコシステムへのベンダーロックインです。

Weights & Biases Weaveは、W&Bの実験トラッキングを本番環境に拡張します。チームがすでにモデルのトレーニングと評価にW&Bを使っているなら、Weaveは別のベンダーを追加することなく、本番のオブザーバビリティへの橋渡しをします。

**Datadog LLM Observability**はエンタープライズ向けの一手です。LLMのトレースをDatadogのAPM、ダッシュボード、アラートに直接統合します。運用チームがすでにDatadogの中で仕事をしているなら、これが最も抵抗の少ない道です。

Elastic Observabilityは、LLMトレーシングをELKスタックに持ち込みます。オープン（SSPLライセンス）で、セルフホスト可能で、すでにログ分析にElasticsearchとKibanaを動かしているなら自然にフィットします。

ハンズオンテストによる詳細なツールレビューは、Best AI Observability Platforms [近日公開]をご覧ください。

結論：単一の勝者はいません。スタック、チーム、優先順位次第です。 Langfuseはほとんどのチームにとって最も安全なデフォルトです。Braintrustは評価品質でリードしています。Heliconeはセットアップの速さで勝ちます。Datadogはすでにそのエコシステムにいる場合に勝ちます。

正しいAIオブザーバビリティツールの選び方

機能マトリクスに頭を悩ませる代わりに、次の質問を自分に投げかけて、その答えで選択肢を絞り込んでください。

最も重要なアドバイスは？シンプルに始めて進化させることです。 ツールを一つ選び、クリティカルパスを計装し、今週中に基本的なトレーシングを動かしてください。評価の追加、プラットフォームの切り替え、セルフホストは後からいつでもできます。最悪の決断は、決断しないことです。オブザーバビリティなしで本番のLLMを動かすのは、ヘッドライトなしで夜間運転するようなものです。

正しいスタックを選ぶことも、オブザーバビリティのニーズに影響します。異なるアーキテクチャの選択が監視要件をどう形作るかは、SaaS向けベストAIスタックのガイドを参照してください。

実装ロードマップ：ゼロからオブザーバブルへ、5つのステップ

私たちが推奨する実践的な道筋は次のとおりです。各ステップは前のステップの上に積み重なり、ステップ1〜3は1つのスプリントで完了できるはずです。

ステップ1：計装する

すべてのLLM呼び出しにトレーシングを追加します。ゼロから始めるなら、OpenTelemetryを使ってください。ベンダーニュートラルで将来性があります。より早く価値を得たいなら、選んだプラットフォームのSDK（Langfuse、Braintrustなど）を使ってください。重要なのは、モデル名、入力/出力トークン、レイテンシ、プロンプト/補完のペアを捉えることです。

ステップ2：トレースする

計装をバックエンドに接続し、トレースが正しく流れることを確認します。RAGパイプラインとマルチステップのチェーンで、ネストされたスパンが正しくレンダリングされることをチェックしてください。三大要素のダッシュボードを設定します。レイテンシ（P50/P95）、トークン使用量、エラー率です。これが運用上のベースラインになります。

ステップ3：評価する

サンプルした本番トラフィックに対して、自動化された品質スコアリングを設定します。忠実性（RAG向け）または有用性（チャット向け）のシンプルなLLM-as-a-judge評価器から始めてください。最初はトラフィックの5〜10%で実行します。スコアを時間とともに追跡し、品質のベースラインを確立します。

ステップ4：アラートする

最も重要なメトリクスに対してアラートを設定します。推奨する初期の閾値は次のとおりです。

• コスト： 日次支出が7日平均の150%を超えたらアラート
• レイテンシ： P95が15分以上にわたってベースラインの2倍を超えたらアラート
• 品質： 平均評価スコアがベースラインから10%以上低下したらアラート
• エラー： 任意の10分ウィンドウでエラー率が5%を超えたらアラート

ステップ5：繰り返し改善する

ここでフライホイールが動き出します。本番のトレースを使って評価データセットを構築します。評価スコアを使って弱いプロンプトを特定します。コストデータを使ってモデルルーティングを最適化します。改善を本番にフィードバックし、その影響を測定します。これを毎週繰り返します。

オブザーバビリティから最大の価値を得ているチームは、最も凝ったダッシュボードを持つチームではありません。このフィードバックループを一貫して回しているチームです。

TechsyのAIオブザーバビリティへの取り組み

Techsyでは、私たちは複数の業界にわたってAIアプリケーションを構築・デプロイしてきました。そしてオブザーバビリティは、初日からすべての本番システムにとって譲れない要素であり続けています。

クライアントプロジェクトに対する私たちの標準的なアプローチは、3つの原則に従います。

1. OTELファーストの計装 — デフォルトでOpenTelemetryを使って計装し、再計装なしにバックエンドを交換できる選択肢を維持します。これは、クライアントのニーズが進化した際に、多大な移行の労力を節約してきました。
2. 評価駆動開発 — 評価ループは、最初の本番デプロイの後ではなく、前に設定します。自動化された品質スコアリングは初日から実行され、改善の基準となるベースラインを与えてくれます。
3. コストを意識したアーキテクチャ — モデルルーティングを早い段階でアーキテクチャに組み込み、オブザーバビリティのデータを使って、品質を損なわずに安価なモデルで処理できるクエリを特定します。ほとんどのプロジェクトで、最適化の最初の1か月以内に40〜60%のコスト削減が見られます。

私たちは通常、オープンソースのコントロールを求めるチームにはLangfuseを、評価品質が最優先のチームにはBraintrustを推奨します。すでにDatadogを運用しているエンタープライズクライアントには、LLMオブザーバビリティを既存のスタックに統合します。

AIアプリケーションを構築中で、オブザーバビリティのセットアップに助けが必要ですか？ 無料相談を受ける。

よくある質問

AIオブザーバビリティとは何ですか？

AIオブザーバビリティとは、本番環境におけるAIシステム、特にLLMの内部的な振る舞いを理解する実践です。稼働監視を超えて、出力品質、コスト追跡、レイテンシのプロファイリング、トレースレベルのデバッグをカバーします。目標は「モデルは動いているか？」だけでなく「なぜモデルはこの出力を生成したのか？」に答えることです。

AI監視とAIオブザーバビリティの違いは何ですか？

監視は事前に定義されたメトリクスを追跡し、閾値を超えたときにアラートを発します。「何かがおかしいか？」に答えます。オブザーバビリティは、予期していなかった障害モードであっても、なぜ何かがおかしいのかを調査するツールを提供します。LLMでは、この違いが重要です。ほとんどの障害は新しいものだからです。モデルはクラッシュせず、事前に定義されたアラートでは捕まえられない、微妙に間違った出力を生成するだけです。

2026年のベストなAIオブザーバビリティツールは何ですか？

オープンソースの主要な選択肢は、Langfuse（MIT、最も人気）、Arize Phoenix（BSD、ML重視）、Helicone（プロキシベース、最もセットアップが容易）です。商用プラットフォームでは、Braintrustが評価でリードし、LangSmithはLangChainユーザーに最適で、Datadog LLM Observabilityはエンタープライズの選択肢です。完全な内訳は上記の比較表を参照してください。

LLMオブザーバビリティはどう実装しますか？

まず、OpenTelemetryまたは選んだプラットフォームのSDKで、LLM呼び出しにトレーシングを追加することから始めます。モデル名、トークン使用量、レイテンシ、入力/出力のペアを捉えてください。バックエンド（Langfuse、Braintrustなど）に接続し、レイテンシとコストのダッシュボードを設定し、サンプルしたトラフィックに自動化された評価を追加し、アラートを設定します。基本的なトレーシングなら1時間以内に動かせます。

AIオブザーバビリティツールのコストはどれくらいですか？

Langfuse、Arize Phoenix、Heliconeのようなオープンソースツールはセルフホストなら無料で、支払うのはインフラ代だけです。クラウドホストのプランは月額25ドル（Braintrust）から月額50ドル（W&B Weave）で始まります。Datadogのようなエンタープライズプラットフォームはカスタム価格です。ほとんどのチームは無料で始められ、月間5万トレースを超えてから有料プランが必要になります。

LLMオブザーバビリティではどのメトリクスを追跡すべきですか？

必須のメトリクスは、レイテンシ（P50/P95/P99と最初のトークンまでの時間）、トークン使用量（リクエストごとの入力/出力）、コスト（リクエストごと、ユーザーごと、機能ごとの配分）、品質スコア（自動化された評価から）、エラー率（API障害、ガードレール発動、タイムアウト）です。レイテンシとコストから始め、成熟するにつれて品質スコアリングを追加してください。

本番環境でハルシネーションをどう検出しますか？

最も実用的なアプローチは忠実性スコアリングです。LLM-as-a-judgeを使って、モデルの出力が取得したコンテキストに基づいているかを評価します（RAGシステムの場合）。この評価をサンプルした本番トラフィックで実行し、スコアを時間とともに追跡します。忠実性が閾値を下回ったら、該当するトレースを調査します。これに、フラグの立った出力に対するHuman-in-the-loopのレビューを組み合わせれば、精度が高まります。

LLM向けOpenTelemetryとは何ですか？

OpenTelemetry（OTEL）は、分散トレーシングの業界標準となったオープンソースのオブザーバビリティフレームワークです。GenAIセマンティック規約は、LLMテレメトリ向けの標準化された属性名（gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.systemなど）でOTELを拡張します。これにより、一度計装すれば、互換性のある任意のバックエンドにトレースを送れます。

マルチエージェントのAIシステムをどう観測しますか？

エージェントのオブザーバビリティには、複数のLLM呼び出し、ツール呼び出し、サブエージェントのハンドオフにまたがる意思決定の木全体を捉えるセッションレベルのトレーシングが必要です。推論の連鎖、ツール呼び出しの結果、状態遷移、セッションごとの累積トークンバジェットを追跡する必要があります。LangfuseとBraintrustは現在、最高のエージェントトレーシングサポートを提供しており、OpenTelemetryコミュニティはエージェント固有のセマンティック規約を開発中です。

LangfuseはLangSmithより優れていますか？

スタック次第です。Langfuseは、オープンソース、セルフホスト、ベンダーニュートラル、OpenTelemetryネイティブの取り込みを求める場合に優れています。LangSmithは、LangChain/LangGraphエコシステムに深く投資しており、ネイティブな思考の連鎖のデバッグを求める場合に優れています。Langfuseは任意のフレームワークで動作し、LangSmithはLangChainに最適化されています。ゼロから始めるほとんどのチームにとって、Langfuseはより多くの柔軟性を提供します。

LLMオブザーバビリティに既存のAPMツールを使えますか？

部分的には使えます。DatadogやElasticのようなツールはLLM固有の機能を追加しているので、すでに使っているなら、新しいベンダーを追加せずに基本的なトレーシングとコスト追跡が得られます。ただし、一般的に評価機能、プロンプト管理、エージェントトレーシングでは、専用ツール（Langfuse、Braintrust）に遅れを取ります。多くのチームは、インフラメトリクスには既存のAPMを使い、品質と評価には専門のLLMオブザーバビリティツールを追加しています。

出典

• OpenTelemetry Semantic Conventions for Generative AI
• OpenTelemetry Blog: Observability for AI Agents
• Langfuse Documentation
• Langfuse Tracing Guide
• Arize Phoenix Documentation
• Braintrust Documentation
• Helicone Documentation
• Confident AI: LLM Evaluation Metrics
• Hamel Husain: Your AI Product Needs Evals
• Datadog LLM Observability Documentation