MENU
知識がなくても始められる、AIと共にある豊かな毎日。
noteを見に行く
AIコーディング

Trace-Driven Development (TrDD)：非決定論的エージェントのテスト手法

ゲンキ

AIエージェントの普及に伴い、テストの在り方が根本から変わりつつあります。AIエージェント市場は2025年に約76億ドル規模に達し、2030年には約503億ドル（年平均成長率45.8%）まで成長が見込まれています。しかし、従来の決定論的テスト手法ではLLMベースのエージェントを正しく検証できません。Googleの調査では全テストの41%がFlaky（不安定）であり、Microsoftでも26%に達しています。本記事では、この問題を解決するTrace-Driven Development（TrDD）の概念と実践方法を徹底解説します。

目次
  1. 従来テストが通用しない理由：非決定論の壁
  2. TrDDの基本概念：出力ではなくプロセスを検証する
  3. LLM-as-a-Judgeの実践：良いJudgeを育てる
  4. TrDD対応ツール比較：2026年版
  5. Anthropicのエージェント評価ベストプラクティス
  6. TrDD実践例：住所変更エージェントのテスト
  7. TrDD導入ステップガイド
  8. CI/CDパイプラインへのTrDD組み込み
  9. よくある質問（FAQ）
  10. まとめ
  11. あわせて読みたい

従来テストが通用しない理由：非決定論の壁

従来のソフトウェアテストは「入力Aに対する出力は必ずBである」という決定論に基づいていました。しかし、LLMベースのエージェントは確率的（Stochastic）です。「このデータを要約して」という指示に対し、毎回異なる単語、異なる順序で出力が返ってきます。時にはツールを使う順序さえ変わります。

これをassert output == expectedでテストしようとすれば、CIパイプラインはFlakyなテストで埋め尽くされ、誰もテスト結果を信用しなくなるでしょう。2026年、従来のTDD（Test-Driven Development）に加えて、エージェント固有のテスト手法が求められています。本記事ではこのアプローチを便宜的にTrDD（Trace-Driven Development）と呼びます。

※「TrDD」は本記事における造語です。DarkLangにも同名の概念がありますが、そちらはHTTPトレースベースの開発手法であり、本記事の概念とは異なります。

TrDDの基本概念：出力ではなくプロセスを検証する

TrDDでは、最終的な出力（Output）だけを見るのではなく、エージェントの思考プロセスと行動履歴（Trace）全体を評価対象にします。このアプローチは3つのステップで構成されます。

ステップ1：実行トレースのキャプチャ

エージェントの実行をOpenTelemetry互換のトレーサーで記録します。OpenTelemetry GenAI Semantic Conventions v1.37以降では、プロンプト、モデルレスポンス、トークン使用量、ツール呼び出しなどを標準化された形式で記録できます。キャプチャする情報は以下のとおりです。

  • 入力プロンプトとシステムインストラクション
  • 思考プロセス（Chain of Thought）の内容
  • ツール呼び出しの引数と結果
  • 最終回答とトークン消費量

ステップ2：LLM-as-a-Judgeによる意味的検証

記録したトレースを別のLLM（Judge Model）に渡し、振る舞いの正当性を評価します。Judgeモデルは、完全一致ではなく「意味的に正しいか」「ポリシーに違反していないか」「適切な手順を踏んでいるか」を判定します。研究によれば、LLM-as-a-Judgeは最大85%の人間評価一致率を達成できます。さらに、Few-shotで2〜3個の評価例を与えると、ゼロショットと比較して精度が大幅に向上することが複数の研究で示されています。

ステップ3：リグレッション検知と統計的保証

トレースデータを蓄積し、新バージョンのエージェントが過去のバージョンと比較して品質を維持しているかを統計的に検証します。ここで重要なのは、100%の正確性ではなく「95%の確率で安全な振る舞いをする」ことを統計的に保証するという考え方です。信頼区間と仮説検定を組み合わせ、エージェントの品質変化を定量的に評価します。

LLM-as-a-Judgeの実践：良いJudgeを育てる

TrDDの成功は、Judge Modelの品質にかかっています。LLM-as-a-Judgeには既知のバイアスが存在し、対策が不可欠です。

  • 位置バイアス：GPT-4では回答の提示順序によって最大40%の評価不一貫性が発生する。対策として、回答の順序を入れ替えてスコアを平均化するキャリブレーションを行う
  • 冗長性バイアス：長い回答を高く評価する傾向があり、約15%のスコアインフレーションが発生する。評価プロンプトで「簡潔さも評価基準に含める」と明示する
  • 同意バイアス：Judgeが入力に同調しやすい傾向。人間アノテーションサンプルを使った回帰ベースのキャリブレーションで補正する
  • 確率的変動：同じ入力でもJudgeの出力が変わる。温度パラメータを低く設定し、複数回実行の多数決を取る

最初は汎用モデルで始め、組織固有のポリシー（コンプライアンス等）を学習させたカスタムJudgeモデルを育てることが2026年のベストプラクティスです。バイナリ評価（合格/不合格）はスカラー評価（1〜5段階）よりも信頼性が高いことが研究で確認されています。

TrDD対応ツール比較：2026年版

エージェントのテスト・評価に使えるツールは急速に充実しています。主要なプラットフォームを比較します。

  • LangSmith：LangChain統合で最も広く使われている。月5,000トレースまで無料。マルチエージェント対応でプロンプト管理機能も充実。Python中心の開発に最適
  • Braintrust：100万スパンまで無料。TypeScript/JavaScript優先で、評価・監視・可観測性を統合した統一プラットフォーム。有料プランは月額249ドルから
  • Arize Phoenix：完全無料のオープンソース。自己ホスト可能でデータレイク統合（Iceberg/Parquet）に対応。エンタープライズ向けにはArize AXも提供
  • DeepEval：完全無料のオープンソース。30以上の内蔵評価メトリックを備え、Pytestライクな記法でLLMのユニットテストが書ける
  • Langfuse：MITライセンスのオープンソース。トレース記録、プロンプト管理、評価機能を備え、完全なデータ制御が可能。自己ホストなら無制限
  • Ragas：RAG評価に特化した無料ツール。月間500万件以上の評価を処理し、AWS、Microsoft、Databricksで採用されている

Anthropicのエージェント評価ベストプラクティス

Anthropicはエンジニアリングブログで、エージェント評価の実践的なフレームワークを公開しています。その核心は「タスク」「グレーダー」「評価」の3層構造です。

  • タスク設計：20〜50個の簡潔なタスクを、実際の障害事例から抽出する。テストケースは仮説ベースではなく、本番で起きた失敗パターンに基づくべき
  • グレーダー設計：結果そのものではなく「振る舞い」をグレードする。決定論的テストとLLMベースのルーブリックを組み合わせる
  • 早期構築：評価を後から作ると逆エンジニアリングコストが膨大になる。エージェント開発の初期段階から評価を構築すべき

さらに、AnthropicはBloomフレームワーク（MITライセンス）を公開しています。これはターゲット化された行動評価を自動生成するツールで、手動ラベルとの強い相関が確認されています。

TrDD実践例：住所変更エージェントのテスト

具体的なTrDDの実装例として、住所変更を処理するカスタマーサポートエージェントのテストを考えます。このエージェントは、ユーザーの本人確認を行い、データベースから既存情報を検索し、新しい住所に更新するという手順を踏みます。

従来のテストでは「出力が期待値と一致するか」を検証しますが、TrDDでは「検索せずに書き込む」という危険な振る舞いを検出します。具体的には、トレースからツール呼び出し履歴を取得し、search_userツールがupdate_addressツールの前に呼ばれているかを検証します。この評価関数をデータセット全体に適用し、合格率が95%以上であることを要求します。

このテストは、エージェントが「どのような手順で」住所変更を行っても、「検索せずに書き込む」というポリシー違反をした時だけ落ちます。これがTrDDの本質です。出力の文言ではなく、プロセスの安全性を検証するのです。

TrDD導入ステップガイド

TrDDを自分のプロジェクトに導入するための具体的なステップを紹介します。

ステップ1：トレース基盤の構築

まず、エージェントの実行をトレース可能な状態にします。OpenLLMetryなどの自動計測ライブラリを導入すれば、OpenAI、Anthropic、各種ベクトルDBへの呼び出しを自動的にOpenTelemetry形式で記録できます。既存のAPMツール（Datadog、Grafana、New Relicなど）との互換性も確保されています。

ステップ2：評価データセットの作成

Anthropicの推奨に従い、20〜50個のテストケースを実際の障害事例から作成します。仮説ベースではなく、本番環境で発生した失敗パターンをベースにすることで、実用的な評価が可能になります。各テストケースには、入力プロンプト、期待される振る舞い（ツール呼び出し順序など）、成功基準を定義します。

ステップ3：Judge Modelの設定とキャリブレーション

Judge Modelを選定し、評価プロンプトを設計します。最初は汎用モデルで始め、Few-shotで2〜3個の評価例を含めることで精度を大幅に向上させます。バイナリ判定（合格/不合格）から始め、十分なデータが蓄積されてからスカラー評価に拡張するのが安全です。

CI/CDパイプラインへのTrDD組み込み

TrDDを開発フローに定着させるには、CI/CDパイプラインへの統合が不可欠です。プルリクエストごとに自動でエージェント評価を実行する仕組みを構築しましょう。

  • ステージング環境でのトレース収集：PRがマージされる前に、ステージング環境でエージェントを実行し、トレースを自動収集する
  • 評価ゲート：合格率が閾値（95%推奨）を下回った場合、PRのマージをブロックする。これにより品質劣化を防止できる
  • ダッシュボード連携：評価結果をGrafanaやDatadogのダッシュボードに自動送信し、品質トレンドをチーム全体で可視化する
  • アラート設定：本番環境のサンプリング評価で合格率が急落した場合、Slackやメールで即座に通知する

Q8. OpenTelemetryの導入は難しいですか？

OpenLLMetryを使えば、数行のコードで自動計測が開始できます。既存のOpenAIやAnthropic SDK呼び出しを自動的にトレースし、Datadog、Grafana、New Relicなどの既存APMツールにそのまま送信できます。専用のインフラ構築は不要で、既存の可観測性スタックに乗せるだけです。

よくある質問（FAQ）

TrDD（Trace-Driven Development）について、よく寄せられる質問をまとめました。

Q1. TrDDは従来のTDDと併用できますか？

はい、併用を推奨します。決定論的なロジック（入力バリデーション、データ変換など）は従来のTDDでテストし、LLMの振る舞いに関わる部分をTrDDで補完します。両者は排他的ではなく、テストピラミッドの異なる層を担当します。

Q2. Judge Modelのコストはどのくらいですか？

使用するモデルとテスト頻度によります。たとえばClaude 3.5 Sonnetの場合、入力100万トークンあたり3ドル、出力100万トークンあたり15ドルです。50タスクの評価を毎日実行する場合、月額コストは数十ドル程度に収まるケースが多いです。バッチAPIを使えばさらに50%割引になります。

Q3. 評価の合格率はどの程度を目標にすべきですか？

Anthropicの推奨は95%以上です。100%を目標にすると、テストが脆弱になり逆効果です。95%の統計的保証を達成するには、各テストケースを複数回実行し、信頼区間を計算します。実際のプロダクション環境では、エージェントの用途のリスクレベルに応じて閾値を調整してください。

Q4. 小規模チームでもTrDDは導入できますか？

はい。DeepEvalやLangfuseなど無料のオープンソースツールを使えば、初期コストゼロで始められます。最小構成として、トレース記録（Langfuse）＋バイナリ評価（DeepEval）＋10個のテストケースがあれば、TrDDの恩恵を受けられます。

Q5. TrDDはRAGシステムにも適用できますか？

はい、RAGシステムにはRagasフレームワークが特に有効です。コンテキスト関連性、コンテキスト想起率、忠実性、回答関連性の4つのメトリックで評価できます。Ragasは月間500万件以上の評価を処理しており、AWS、Microsoft、Databricksでも採用されています。

Q6. エージェントの振る舞いが変わった場合、テストケースも更新が必要ですか？

はい、エージェントの機能追加やポリシー変更に合わせて、テストケースの更新が必要です。ただし、TrDDではプロセスの正当性を検証するため、出力の文言変更によるテスト修正は不要です。新しいツールやポリシーが追加された場合にのみ、評価基準を更新してください。

Q7. 本番環境でもTrDDを使えますか？

はい、本番環境でのトレース収集と評価は推奨されます。ただし、本番ではサンプリングレートを調整し、全リクエストではなく一定割合のトレースのみを評価することで、コストとレイテンシのバランスを取ります。異常検知と組み合わせて、品質低下を早期に発見する運用が理想的です。

まとめ

LLMベースのエージェントは確率的であり、従来の決定論的テストだけでは品質を保証できません。TrDD（Trace-Driven Development）は、エージェントの出力ではなくプロセス全体をトレースし、LLM-as-a-Judgeで意味的に検証する新しいテスト手法です。OpenTelemetryによるトレース基盤、LangSmithやDeepEvalなどの評価ツール、Anthropicのベストプラクティスを組み合わせることで、「95%の統計的保証」という現実的な品質目標を達成できます。あなたのCIパイプラインが完全一致を探しているなら、今こそTrDDへの移行を検討してください。

あわせて読みたい

さらに詳しい情報はAll3DPでご覧いただけます。

ABOUT ME
swiftwand
swiftwand
AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.
Recommend
こちらの記事もどうぞ
記事URLをコピーしました