MLflowとOpenTelemetryの違いとは？AI Agent Observabilityでの役割分担を整理

📚 参考書籍

※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。

本書は、AI Agentを「作って動かす」だけでなく、その品質をどう観測し、どう評価し、どう守り、どう説明可能にするかを体系的に学ぶための入門書です。

AI Gatewayでつなぎ、Agent Skillsで企業の仕事を標準化し、Pipeline Factoryで量産し、MLflowで評価・改善する。
その一連のライフサイクルを、データパイプライン開発という具体的な題材を通して理解することが本書のゴールです。

MLflowとOpenTelemetryの違いとは？AI Agent Observabilityでの役割分担を整理

MLflowとOpenTelemetryの役割分担

ここでは、その中でも特に混同されやすいMLflowとOpenTelemetryの役割の違いを整理します。

両者は競合するものというより、観測する対象や得意とする領域が異なるため、実務では補完関係として捉えると理解しやすくなります。

OpenTelemetryはシステム全体のTelemetryを扱う

OpenTelemetryは、分散システムにおけるTrace、Metric、LogなどのTelemetryを収集・連携するための標準的な仕組みです。

AI Agentも、実際には単独で動作しているわけではありません。

たとえば、次のような構成を考えてみます。

Web Application
↓

Backend API
↓

AI Agent
↓

Retriever / Database
↓

External Tool / API

このときOpenTelemetryを利用すると、ユーザーからのリクエストがBackend APIを通り、AI Agentを呼び出し、さらにDatabaseや外部APIへ到達するまでの処理を、一連の分散Traceとして追跡できます。

そのため、OpenTelemetryは、

• API間の呼び出し

• Service間の依存関係

• Database Access

• 外部API Call

• Latency

• Error

• Infrastructure Metric

など、アプリケーションやインフラを含むシステム全体の実行可観測性を実現するうえで重要な役割を持ちます。

MLflowはAI Agent固有の実行と品質を扱う

一方、MLflow 3では、AI AgentやGenAIアプリケーションに特有の情報を中心に扱います。

たとえば、

• Prompt

• LLM Call

• Retriever

• Retrieved Documents

• Tool Call

• Tool Argument

• Final Answer

といったAgent内部の実行情報をTraceとして記録できます。

さらにMLflowの特徴は、Tracingだけで終わらないことです。

記録したTraceやOutputに対して、

• Correctness（正確性）

• Relevance（関連性）

• Groundedness（根拠に基づいているか）

• Safety

• Tool Correctness（正確性）

• Task Completion

などをScorerで評価し、その結果をAssessmentやFeedbackとして蓄積できます。

さらに、Evaluation Datasetを利用した変更前後の比較や、本番TraceへのScoringまでつなげることができます。

つまりMLflowは、AI Agentが何をしたかだけでなく、その実行が良かったのかを評価するQuality Observabilityまで扱う点に特徴があります。

両者は観測するレイヤーが異なる

MLflowとOpenTelemetryの違いを単純化すると、次のように整理できます。

観点 MLflow 3 OpenTelemetry
主な対象 AI Agent / GenAIアプリ 分散システム全体
Trace LLM、Retriever、Toolなど Service、API、DBなど
Metric / Log AI品質・実行情報を中心に利用 汎用Telemetryとして広く扱う
品質評価 Scorer、LLM Judgeなど 原則として別途仕組みが必要
Evaluation Dataset 扱える 主目的ではない
本番品質評価 Production Scoringへ展開可能 Monitoring基盤との連携が中心
主な役割 AI Agent固有の実行・品質可観測性 システム全体の実行・性能可観測性

したがって、「MLflowとOpenTelemetryのどちらを使うべきか」という二者択一で考える必要はありません。

実務では両者を組み合わせる

たとえば、本番でAI Agentの応答が極端に遅くなったとします。

MLflow Traceを見ると、

Agent
├─ Retriever: 0.5秒
├─ LLM: 2.0秒
└─ Tool: 8.0秒

となっており、Tool Callで時間がかかっていることが分かりました。

しかし、そのToolの先で、

Tool
↓

Backend API
↓

Database

のどこが遅いのかまでは、Agent Traceだけでは十分に分からない場合があります。

そこでOpenTelemetry側のTraceを確認し、

Backend API: 0.2秒
Database Query: 7.5秒

と分かれば、問題がDatabaseにあると切り分けられます。

逆に、処理性能には問題がないものの、Agentが誤った回答を返している場合には、MLflow側でRetriever Result、LLM Output、Scorer結果を確認した方が原因を分析しやすくなります。

このように、

システム全体で何が起きたか
↓

OpenTelemetry

AI Agent内部で何が起き、
その結果は妥当だったか
↓

MLflow

という役割分担で考えると整理しやすくなります。

本書ではMLflow 3を中心に扱う

本書の主題は、汎用的な分散システムObservabilityそのものではありません。

中心となる問いは、

AI Agentの回答・検索・Tool利用・Task実行をどのように観測し、その品質をどのように評価・改善するか

です。

そのため、本書ではTracingだけでなく、Scorer、LLM Judge、Evaluation Dataset、Assessment / Feedback、Production Monitoringまでを一連の品質管理ライフサイクルとして扱えるMLflow 3を中心に解説します。

一方で、実務システムではOpenTelemetry、クラウドMonitoring、SIEM、Security Audit Logなども重要です。

したがって、本書の立場は「MLflowだけですべてのObservabilityを実現する」というものではありません。

AI Agent固有のExecution・Quality ObservabilityはMLflowを中心に扱い、システム全体のTelemetryやInfrastructure MonitoringはOpenTelemetryなどの既存基盤と連携する。

この責任分担を前提とすることで、MLflowの役割を過大評価することなく、AI Agent Observability全体の中で適切に位置付けることができます。