LLM Observability / LLMOps
LLM アプリケーション・エージェントの挙動（プロンプト、トークン、tool 呼び出し、レイテンシ、コスト）を計測・追跡する分野。MLOps の LLM 版という位置づけ。
トレーシングの選択肢
- OpenTelemetry (OTel) 統一路線: opentelemetry-observability の Span 属性 / Event に GenAI 用の semantic conventions を設定し、Cloud Trace 等に生成 AI 情報を表示する。ただし semantic conventions は策定途上で、span 属性として送るか Event として送るか議論の最中。ADK・OSS 実装でもこれらの定義はまだほとんど使われていない。
- 独自トレース: OpenAI Agents SDK は OTel ではない独自のトレース機能を持つ。
主要ツール
- langfuse: LLM observability プラットフォーム。OTel 経由のトレース取り込みと、OpenAI Agents SDK 連携の両方をサポート（2026/2 に対応）。Dataset 機能で入力と期待出力の集合を持ち性能評価に使う。
- traceloop/openllmetry (
MCPInstrumentor): OTel instrumentation ライブラリ。patch_mcp_server()/patch_mcp_client()で model-context-protocol の通信を計測する PR が進行。
MCP への OTel 導入
MCP エコシステムでは OTel trace support 導入が複数の issue/discussion で並行議論されている（modelcontextprotocol #269、python-sdk #421、open-telemetry/semantic-conventions #2043、openllmetry #2662）。エージェントが server/client をまたいで tool を連鎖実行するため、分散トレースの意義が大きい。
評価との関係
実行トレースの観測だけでなく、promptfoo のようなプロンプト/モデルの評価ツールと組み合わせて品質を回す。
関連
MCP の OpenTelemetry トレース計装
model-context-protocol (MCP) サーバ/クライアント間のやり取りを opentelemetry-observability の Trace として可視化する取り組み。LLM アプリケーションは「クライアント → MCP サーバ → 外部 API → LLM」と多段に処理が流れるため、どこで時間がかかったか・どんな引数で Tool が呼ばれたかを分散トレースで追いたい、という動機がある。
プロトコル側の議論
標準化に向けた提案・Issue が複数走っている。
- modelcontextprotocol#269 — MCP への OpenTelemetry Trace サポート追加提案。
- python-sdk#421 — MCP SDK への OpenTelemetry 導入。
- traceloop/openllmetry#2662 — OpenLLMetry の MCP 対応リクエスト。
- open-telemetry/semantic-conventions#2043 — MCP 向けの semantic conventions（span 名・属性の標準化）。
MCP は仕様面で LSP に似ている（リクエスト/レスポンスの構造）という指摘があり、計装の設計でもこの類似が参照される。
未対応・課題
- Sampling（サーバ → クライアント方向のリクエスト、LLM 補完を逆方向に要求する機能）のトレースは未対応。
- 独自に OTel 計装した事例はあるが、semantic conventions が固まっていないため属性の付け方が実装依存になる。
A2A への接続
リモート MCP や A2A (Agent2Agent) プロトコルが普及すると、エージェント間通信もトレース対象になる。MCP がツール接続（垂直方向）を、A2A がエージェント協調（水平方向）を担うという整理がなされている。
関連: model-context-protocol・opentelemetry-observability・llm-observability・rust-opentelemetry-tracing