9月1日、Datadogが「From traces to experiments: A loop for improving AI agents」と題した記事を公開した。この記事では、本番環境で稼働するAIエージェントのトレースデータを起点に、オフライン評価と本番実験を組み合わせた反復的な改善サイクルの構築方法について詳しく紹介されている。以下に、その内容を紹介する。
「テレメトリはあるのに改善できない」問題
AIエージェントを本番に出した後、「なんとなく精度が悪い」と感じても、何をどう直せばいいかわからない——そういったケースは多い。プロンプトを調整してみたり、モデルをアップグレードしてみたりして「改善した気がする」で終わる。
問題はデータが不足しているのではない。エージェントシステムを運用するチームは通常、消化しきれないほど大量のトレースデータを収集している。問題は、エージェントがどこで失敗しているかを特定し、変更が意図した成果を改善したかどうかを測る再現可能な手順がないことだ。
この記事が提示するのは、そのための5段階ループ「観測→仮説→オフライン評価→本番実験→継続監視」である。
トレースを「どこに投資するか」の地図として使う
トレースは通常、不具合のデバッグに使われる。だがトレースデータを集計して分析すると、再現パターンが見えてくる。評価スコアやアウトカムと紐付けることで、「エージェントがなんか微妙」という曖昧な感覚を「15メッセージ超のスレッドで要約プロンプトが低精度になり、そのチケットの再オープン率が通常の2倍になっている」という検証可能な仮説に落とし込める。
特に有用なシグナルは以下の3種類だ。
- レイテンシパターン: 特定のプロンプトやツール呼び出しにレイテンシが集中していれば、そこがボトルネックの候補。請求APIへのツール呼び出しで毎回遅延が発生するなら、モデルがそのレスポンスを待ってから処理を進めている可能性がある。
- コスト異常: 高コストのトレースが長いスレッドに集中しているなら、毎ターン全履歴をコンテキストに読み込んでいる可能性がある。
- 品質シグナル: レイテンシとコストが正常でも、回答が間違っていることはある。評価スコア、ユーザーの「低評価」フィードバック、エスカレーション精度、チケット再オープン率などが品質の劣化を示す。エージェントシステムでは特に「正しいツールを選んだか（ツール選択精度）」「正しい引数を渡したか（ツール引数の正確性）」が重要だ。
「オフライン評価」と「本番実験」は別物で、両方必要
仮説が立ったら、次はテストだ。ここで記事が強調するのは評価（Evaluation）と実験（Experimentation）を混同しないことである。
| オフライン評価 | 本番実験 | |
|---|---|---|
| 目的 | 品質基準をクリアするか | 実際のユーザー・ビジネス指標で勝るか |
| 対象 | キュレーションされたデータセット | 本番トラフィック |
| タイミング | リリース前 | リリース後（段階的ロールアウト） |
評価を飛ばすと、データセットで判明できたことを顧客に対して実験する羽目になる。実験を飛ばすと、テストセットが本番トラフィックで通用するかどうかわからないまま信用することになる。
変更の規模によってウェイトは異なる。プロンプトの小さな文言変更なら、評価＋軽い本番チェックで十分。全リクエストに影響するモデル入れ替えなら、徹底的なオフラインベンチマークと段階的ロールアウトの両方が必要だ。
5段階の最適化ループ
1. 観測
集計トレースビューから最も成果が悪いセグメントを1つ選ぶ。最も多く聞こえる不満ではなく、指標が最悪のセグメントに絞る。例として記事が挙げるのは「15メッセージ超のスレッドで要約完成度の平均が68%（短いスレッドは89%）、再オープン率が12%（全体基準は6%）」というケースだ。
2. 仮説の立て方——「間違いになりうる」レベルの具体性を
記事が特に力を入れているのがこのステップだ。「長いチケットで要約が微妙」では弱い。強い仮説には4要素が必要だ：提案する変更内容、対象セグメント、主指標、後退させてはいけないガードレール指標。
記事の例：「15メッセージ超のスレッドで、map-reduceプロンプトに切り替えることで要約完成度を現在の68%から83%以上に引き上げる。トーンスコアを90%以上に維持し、p95レイテンシの増加を10%以内に抑える。」
変更は一度に1変数だけ。原因を特定するためだ。
3. オフライン評価
2種類のデータセットを使い分ける。
- 回帰セット: 本番トラフィックを反映したサンプル。全体的な性能が動いたかを確認する。
- カバレッジセット: エッジケースをオーバーサンプリング。気になるコーナーケースが実際に改善されたかを確認する。
LLM-as-a-judgeを使う場合は、本番で使う前に人間のレビューでキャリブレーションすること。非決定論的な出力は複数回実行してスコアの分布を比較する。コスト管理のため、評価には「その用途に対して十分に信頼できる最安モデル」を使うことが推奨されている。
4. 本番実験
オフライン評価をクリアしたものだけを昇格させる。フィーチャーフラグでトラフィックを分割し、事前に決めた停止ルールに達するまで実験を続ける。主指標が良く見えてきたからといって早期終了しない。レイテンシ・コスト・エラー率などのガードレールも並行して監視し、主指標の勝利が他の指標の後退を隠していないか確認する。
5. リリース後も監視を続ける
バリアントが主指標で勝利し、ガードレール内に収まっていればロールアウト。本番トラフィックのサンプルに対して同じ評価器を走らせ続け、より広い本番分布でも勝利が維持されることを確認する。新しい失敗パターンが現れたら、次の評価サイクルのためにデータセットに追加する。
Datadogでループを一か所に閉じる
記事の後半では、このループを複数のツールに分散させることの非効率さが指摘されている。トレースが別システム、オフライン評価ベンチが別ツール、A/BテストがさらにCSVエクスポート……という状況では、イテレーションのたびに手動ステップが増え、ミスの温床になる。
Datadogの場合、Agent Observabilityで問題を検出したトレースをAgent Observability Experimentsのデータセットに直接追加し、オフライン評価をクリアしたらFeature Flagsでバリアントを配信、Experimentsでオンラインテストの結果を分析するという一連のフローが一つのプラットフォームで完結する設計になっている。
なお、本番データには個人情報（PII）が含まれる場合がある。評価用に再利用する前にSensitive Data Scannerでスキャン・マスクすることが推奨されている。
詳細はFrom traces to experiments: A loop for improving AI agentsを参照していただきたい。
