AI アプリケーションが本番環境に移行するにつれ、トレーシングはエージェントの実際の動作を理解するための重要な手段となります。プロンプト、ツール呼び出し、応答、レイテンシ、実行パスを捕捉することで、デバッグや評価、ガバナンスを大幅に改善できます。しかし、従来の可観測性ツールでは、AI エージェントが生成する大量のトレースデータをコスト効率よく長期保存し、分析やガバナンスを統合することが困難でした。
Databricks は、OpenTelemetry（OTel）トレースを Unity Catalog テーブルに直接書き込む新しい機能を発表しました。このソリューションは、完全マネージドなサーバーレスインジェストエンジン「Zerobus Ingest」を基盤としており、OTel データをネイティブ形式で Delta テーブルに保存します。これにより、トレースデータは他のデータセットと同様に、Lakehouse のスケーラビリティ、ガバナンス、ツールエコシステムの恩恵を受けられます。
なぜ AI トレーシングが従来の可観測性を変えるのか
AI トレースデータは、単なるデバッグを超えて、分析、評価、モニタリングに広く利用されます。チームはトレースを長期保存し、SQL で分析し、ビジネスデータやモデルデータと結合し、評価やモニタリングに再利用したいと考えます。しかし、トレースが可観測性システム内にのみ存在する場合、柔軟性が制限され、ガバナンスが断片化し、分析ワークフローへのデータ移動に余分なパイプラインと複製が必要になります。特に機密性の高いプロンプトデータが含まれる場合、この問題は深刻です。
アーキテクチャ：サーバーレス OpenTelemetry インジェスト
Databricks は、マルチホップのテレメトリパイプラインを排除し、Zerobus Ingest によるシングルホップインジェストを実現しました。OTel 対応のクライアント（人気の AI エージェントフレームワークを含む）は、gRPC または REST API を介してトレース、ログ、メトリクスを Unity Catalog テーブルに直接送信できます。この「シングルシンク」アーキテクチャは、Kafka などのメッセージバスの中間層を不要にし、運用の複雑さを軽減します。
チュートリアル：トレースを Lakehouse に配線する
この記事では、LangGraph で構築した「サポートマネージャーアシスタント」エージェントを使用して、エンドツーエンドのトレーシングをデモンストレーションします。このエージェントは、Databricks がホストする Claude Sonnet モデルで推論を行い、MCP ツール API を介して Genie スペースを呼び出し、サポートデータセットをクエリします。MLflow で OpenTelemetry テーブルを構成すると、エージェントの各呼び出し（モデル呼び出しとツール呼び出しを含む）が自動的にトレースされます。
MLflow 実験では、エージェントの完全な実行パスを観察できます。例えば、「どのサポートエンジニアを昇進させるべきか」という質問に対して、エージェントが Genie スペースを 3 回呼び出してデータを収集した過程が表示されます。トレースデータは Delta テーブルとして保存され、SQL でクエリ可能です。
デバッグを超えて：トレースデータの分析
トレースデータが Unity Catalog に保存されると、バッチ分析とストリーミング分析の両方に即座に利用可能になります。Unity Catalog のきめ細かいアクセス制御により、機密性の高いプロンプトデータの安全性を確保しつつ、チームは SQL を使用してダッシュボード、ETL パイプライン、カスタム分析を構築できます。
MLflow 実験 UI には、トレース量、エラー、レイテンシ、トークン使用量、コストを表示するネイティブの可観測性ダッシュボードが含まれています。さらに、トレーステーブルは単なる Delta テーブルであるため、AI/BI ダッシュボードを使用してカスタムビューを構築できます。例えば、契約価格を反映した実際のコスト分析や、個々のツールの P50/P99 レイテンシやエラー率を表示するコンポーネントレベルのパフォーマンス監視が可能です。
本番トレースデータと分析ワークフローを統合することで、チームは継続的改善のループを確立できます。本番の動作が評価と分析を促進し、それがイテレーションを加速してエージェントのパフォーマンスを向上させます。