LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

LLMオブザーバビリティとは——生成AI運用で何を可視化するのか

LLMオブザーバビリティとは、本番稼働するLLM(大規模言語モデル)アプリケーションやAIエージェントの応答・コスト・障害を継続的に可視化し、運用担当が状況を把握できるようにする仕組みを指します。Amazon Bedrock AgentCoreの公式ドキュメントは、エージェントの実行を段階ごとに可視化し、実行経路の確認・中間出力の監査・性能低下や失敗のデバッグを可能にするものと説明しています^*5。Microsoft Foundryも同様に、AIシステムのライフサイクル全体を通じて監視・理解・トラブルシューティングを行う能力をオブザーバビリティと定義しています^*6。

本稿が扱うLLMオブザーバビリティは、稼働中のLLM/AIエージェントの応答品質・コスト・障害を捉える運用監視に焦点を当てます。入力の安全対策(いわゆるガードレール)や、機械学習モデルの学習データ分布の変化を捉えるドリフト監視とは対象が異なる、別の関心領域です。従来のAPM(アプリケーションパフォーマンス監視)がHTTPリクエストのレイテンシやエラー率を主に見てきたのに対し、LLM/AIエージェントの監視ではプロンプトの内容やトークンの消費量、ツール呼び出しの成否、生成された応答の質まで対象が広がります。

観測すべき指標——レイテンシ・トークン消費・エラー率・ツール呼び出し・回答品質

OpenTelemetryのGenAIセマンティック規約は、クライアント側のメトリクスとしてgen_ai.client.token.usage(ヒストグラム、単位は{token})とgen_ai.client.operation.duration(ヒストグラム、単位は秒)を定義しています^*2。ストリーミング応答向けには、最初のチャンクまでの時間を示すgen_ai.client.operation.time_to_first_chunkと、チャンク間の処理時間を示すgen_ai.client.operation.time_per_output_chunkも用意されています^*2。トークン消費はコストに直結するため、Langfuseのようなツールもトラフィックごとのコストとトークン使用量を追跡する機能を備えています^*3。

エラー率や障害の把握も欠かせません。Amazon Bedrock AgentCore Observabilityは、CloudWatchのダッシュボードでセッション数・レイテンシ・処理時間・トークン使用量・エラー率を主要な指標として提供しています^*5。ツール呼び出しの成否や応答の質は、従来のAPMでは扱われてこなかった観点です。Microsoft Foundryは、ツール呼び出しの正確性やタスク完了度といったエージェント固有の指標に加え、groundedness(事実整合性)やrelevance(関連性)、coherence(一貫性)、fluency(流暢さ)といった品質評価指標を組み込み評価器として提供しています^*6。groundednessの低下はハルシネーション(事実に基づかない応答の生成)の兆候として扱われる指標のひとつです。

これらの指標を整理すると次の通りです。

トレーシングの仕組み——プロンプトからツール呼び出し・応答までのスパン可視化

トレーシングとは、1回のリクエストが辿る処理の流れを、親子関係を持つスパンの集合として記録する手法です。OpenTelemetryのGenAIセマンティック規約は、推論や埋め込みのスパン名を「{gen_ai.operation.name} {gen_ai.request.model}」の形式で構成することを推奨し、検索(retrieval)のスパンでは「{gen_ai.operation.name} {gen_ai.data_source.id}」という形式を用いるとしています^*1。

スパンに付与する属性のうち、gen_ai.operation.name(chat・embeddings・retrievalなど実行中の作業を識別する値)とgen_ai.provider.name(openaiやgcp.vertex_aiなどのプロバイダー識別子)は必須属性とされています^*1。加えてgen_ai.request.model(リクエスト対象のモデル名)、gen_ai.usage.input_tokensとgen_ai.usage.output_tokens(入力・出力のトークン数)、gen_ai.response.finish_reasons(生成が止まった理由)なども推奨される記録対象です^*1。これらの共通語彙があることで、プロンプトの受信からツール呼び出し、応答生成までの一連の流れを、単一のツールに縛られずに追跡できるようになります。

Arize Phoenixは、この考え方を踏まえてOpenTelemetryに対応したトレーシング機能を提供し、モデル呼び出し・検索・ツール利用といった各ステップを段階的に可視化するとしています^*4。Amazon Bedrock AgentCoreも、エージェントやゲートウェイ、メモリといったリソースごとにOpenTelemetry互換のテレメトリを標準出力し、CloudWatchのトレース画面で実行経路を確認できるようにしています^*5。

評価との連携——オンライン評価とLLM-as-a-judge

トレーシングで得られる実行ログは、それ単体では品質の良し悪しを判定してくれません。そこで組み合わせるのが評価の仕組みです。LLM-as-a-judge(大規模言語モデル自身を評価者として用いる手法)は、Langfuseで組み込みの評価手法として提供されているほか^*3、Arize Phoenixでも事前構築済みの評価器やカスタム評価器としてLLMベースの評価を実行できます^*4。

Microsoft Foundryは、評価を開発ライフサイクル全体に組み込む設計を取っています。本番投入前の評価に加え、投入後は本番トラフィックをサンプリングして継続的に評価する仕組みや、システムドリフトを検知するためのスケジュール評価を用意しています^*6。品質基準を下回った場合や有害な出力が生じた場合には、Azure Monitorのアラート機能で通知する運用も可能です^*6。トレーシングで異常を検知し、評価指標でその原因を切り分けるという組み合わせが、運用監視の基本形になります。

なお、RAG(検索拡張生成)における検索精度の評価は、groundednessやrelevanceといった指標を通じて本稿の評価指標とも関連しますが、検索側の精度そのものを深掘りするテーマは別稿の関連トピックとして扱います。

代表的な手法とOSS・サービス——OpenTelemetryとLangfuse、Phoenix、クラウド各社

共通の土台となっているのがOpenTelemetryのGenAIセマンティック規約です。スパン・メトリクス・イベントの語彙を標準化することで、計装したアプリケーションのコードを変えずに、接続先の観測基盤を切り替えられるようにする狙いがあります^*1*2。

OSSの代表例としては、LangfuseとArize Phoenixが挙げられます。Langfuseはトレース・セッション・オブザベーションという階層構造でリクエストを記録し、プロンプト管理やコスト追跡、LLM-as-a-judge評価までを一体で提供するOSSで、セルフホストにも対応しています^*3。Arize Phoenixは、Arize AIとオープンソースコミュニティによって開発されており、LangChainやLlamaIndexなど主要フレームワークの自動計測に対応したトレーシングと、LLMベース・コードベース・人手ラベルを組み合わせた評価機能を持っています^*4。

クラウド各社もマネージドな運用監視を提供しています。Amazon Bedrock AgentCore Observabilityは、CloudWatchのダッシュボードでエージェントの実行を可視化し、標準のOpenTelemetry互換形式でテレメトリを出力します^*5。Microsoft Foundryは、評価・モニタリング・トレーシングの3機能を組み合わせ、Azure Monitor Application Insightsと統合したオブザーバビリティを提供しており、LangChainやLangGraph、OpenAI Agents SDKなど複数のフレームワークのトレーシングに対応しています^*6。自社の技術スタックやクラウド利用状況に応じて、OSSとマネージドサービスのどちらを軸にするかを検討することになります。

導入の進め方——計装からアラート設計、外注時の勘所まで

導入は、まずどこにトレースを仕込むかという計装設計から始まります。OpenTelemetryのGenAIセマンティック規約に沿ってgen_ai.operation.nameやgen_ai.provider.nameなどの必須属性を付与しておくと、後から観測基盤を切り替える際の手戻りを抑えられます^*1。次に、レイテンシ・トークン消費・エラー率といった基礎的な指標をダッシュボードで可視化し、日次や週次で傾向を追える体制を整えます。

その上で、評価の設計に着手します。すべての応答を人手で確認するのは現実的ではないため、LLM-as-a-judgeによるオンライン評価をどの範囲・頻度で回すか、どの指標(groundednessやtool call accuracyなど)を重視するかを事前に決めておく必要があります^*4*6。最後に、しきい値を下回った場合の通知やエスカレーションのルールを整え、運用担当が異常に気づける状態にします。

外注を検討する場合は、計装対象の範囲(どのスパン・属性まで仕込むか)、既存のAPM基盤との統合可否、評価指標の設計と継続的な見直しの体制まで、一括して依頼できるかどうかが選定の分かれ目になります。社内に生成AI特有の計装知識を持つ担当者が少ない場合、立ち上げ段階だけでも外部パートナーの支援を受けることで、指標設計の手戻りを減らせる場合があります。

まとめ：LLMオブザーバビリティ導入で押さえる3つの判断軸

本稿ではLLMオブザーバビリティ・AIエージェント監視の考え方を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、観測対象はレイテンシやエラー率だけでなく、トークン消費・ツール呼び出しの成否・応答の質にまで及びます^*2*6。第二に、OpenTelemetryのGenAIセマンティック規約が、スパンとメトリクスの共通語彙を提供しており、多くのOSSやクラウドサービスがこの規約を土台にしています^*1*2。第三に、トレーシングだけでは品質判定はできず、LLM-as-a-judgeによるオンライン評価と組み合わせる設計が運用監視の基本形になります^*3*6。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OpenTelemetry「Semantic conventions for generative client AI spans」（semantic-conventions-genai リポジトリ）（https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md）
2. *2　出典：OpenTelemetry「Semantic conventions for generative AI metrics」（semantic-conventions-genai リポジトリ）（https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-metrics.md）
3. *3　出典：Langfuse「LLM Observability & Application Tracing (Open Source)」（https://langfuse.com/docs/observability/overview）
4. *4　出典：Arize AI「Phoenix」ドキュメント（https://arize.com/docs/phoenix）
5. *5　出典：AWS「Observe your agent applications on Amazon Bedrock AgentCore Observability」（Amazon Bedrock AgentCore Developer Guide）（https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html）
6. *6　出典：Microsoft「Observability in Generative AI – Microsoft Foundry」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/foundry/concepts/observability）

Tweet