ゴールデンデータセットで始めるエージェント回帰テスト設計

プロンプト1行の修正がエージェント全体の挙動を変えることがあります。モデルのバージョンアップ、ツールの仕様変更、システムプロンプトの調整——変更のたびに「以前の動作が壊れていないか」を手作業で確認するのは現実的ではありません。これを自動化する基盤がゴールデンデータセットと回帰テストの組み合わせです。

ゴールデンデータセットとは何か

AIエージェントの回帰テスト基盤となるゴールデンデータセットは、Anthropicが推奨する50〜200件規模で構築します。

ゴールデンデータセット（golden evaluation set）は、AIエージェントの品質を測る基準テストデータ集合です。各エントリは「入力（タスクやプロンプト）」「期待される出力または採点ルーブリック」「失敗モードのラベル」で構成されます。

通常のユニットテストとの違いは非決定論的な出力への対応です。エージェントは同じ入力でも毎回同一の出力を返しません。そのためexact matchではなく、ルーブリックベースの採点（9軸評価等）や統計指標（pass@k）を組み合わせてスコア化します。

Anthropicが公開している「Demystifying evals for AI agents」によると、20〜50件の単純なタスクから開始し、実際のユーザー障害から抽出したケースを加えて拡充するアプローチが推奨されています。全体規模として50〜200件が「高速な反復と回帰検出の両立」に実用的な範囲です。

回帰テストが必要な3つのタイミング

AIエージェントの回帰テストはモデル更新・プロンプト変更・ツール変更の3タイミングで品質劣化を自動検出します。

1. LLMモデルのバージョンアップ
モデル切り替えは性能向上を期待して行いますが、旧バージョンで安定していたツール選択やJSON出力フォーマットが崩れるケースがあります。2026年の調査では、LLMアプリを本番展開した組織の約40%が展開後90日以内に品質劣化を経験しています。

2. プロンプト・システムプロンプトの変更
表現の小さな変更でもエージェントのツール選択ロジックや出力スキーマに影響する場合があります。Anthropicが推奨するeval-driven development（評価駆動開発）——機能実装前に評価基準を定義し、evalが通るまでイテレーションする——は、この変更リスクを早期に検出するための手法です。

3. ツール・外部API仕様の変更
MCPサーバーのツール定義変更や外部APIのスキーマ変更は、過去に正常動作していたツール呼び出しを壊します。エージェントガバナンスの観点では、外部依存の変更をトリガーに回帰テストを自動実行する設計が必要です。

ゴールデンデータセットの構築ステップ

ゴールデンデータセットは収集・検証・採点設計・バージョン管理の4ステップで構築し、CI/CDで自動実行します。

ステップ1: テストケースの収集

本番ログやバグトラッカーから実際の失敗ケースを中心に収集します。境界値（曖昧な入力）や意図的な敵対的入力も加えます。Anthropicの推奨通り、最初は20〜50件に絞り込みます。

ステップ2: 期待出力の検証

「2名の領域専門家が独立して同じ合否判定を下せる」ことが良いテストケースの条件（Anthropic推奨）。主観的すぎるケースは採点ルーブリックに落とし込んでから採用します。

ステップ3: 採点方式の設計

exact matchが使えないケースには3方式を組み合わせます。

ルールベース採点: JSONスキーマ準拠・必須フィールド有無・URL形式など機械的判定
LLM-as-a-judge: 意味的正確さ・有害性チェックなど意味的判断が必要なもの
リファレンス比較: 参照ソリューション（ground truth）との類似度計算

ステップ4: バージョン管理

ゴールデンデータセット自体をGitリポジトリで管理します。テストケースの追加・修正はPRでレビューし、データセットの変更履歴とエージェントコードの変更履歴を紐付けます。

pass@kとpass^kで非決定性を計測する

AIエージェントの評価はpass@k（k回中1回以上成功）とpass^k（全試行成功）の2指標で非決定性を定量化します。

エージェントの出力は確率的で、同じ入力を繰り返せば異なる結果が返ることがあります。Anthropicはこの非決定性を扱う2つの統計指標を示しています。

pass@k（パス・アット・ケー）: k回の試行のうち少なくとも1回成功する確率。複数の解法が許容されるオープンエンドなタスクの評価に使います。

pass^k（パス・ハット・ケー）: k回の試行すべてで成功する確率。メール送信・データ書き込みなど一発成功が求められるタスクに使います。試行成功率75%・k=3の場合はpass^k ≈ (0.75)³ ≈ 42%です。

回帰スイートにはpass^kでほぼ100%を要求します。スコアが下がった場合は「何かが壊れている」シグナルとして扱い、修正後に再度回帰スイートへ組み込みます。

CIパイプラインへの統合設計

回帰テストはCI/CDで自動実行し、BraintrustやLangSmithを評価フレームワークとして使います。

オフライン評価: ゴールデンデータセット全件をCI上で定期実行し、ベースラインとの比較・レイテンシベンチマークを行います。git pushのたびに自動実行します。

オンライン評価: 本番トラフィックから一定割合をサンプリングしてリアルタイムスコアリングします。オフラインで検出できない本番固有の入力分布の劣化を捕捉します。

代表的な評価フレームワークとしてBraintrust、LangSmith、Arize AIがあります。エージェントの可観測性と組み合わせると、どのスパンでスコアが下がったかをトレースレベルで追跡できます。

規模別の留意点（SMB / エンタープライズ）

SMB（中小企業・スタートアップ）: まず20〜50件のゴールデンデータセットからスタートし、GitHub Actionsで回帰スクリプトを実行する構成が最もコスト効率が良いです。Braintrust無料プランやオープンソース版から始められます。エージェント運用管理の全体支援はKuuのAIオペレーション管理サービスにご相談ください。

エンタープライズ: 複数チームが並行してエージェントを開発する環境では、ゴールデンデータセットの所有チームを明確に定義し、評価インフラをプラットフォームチームが集中管理します。データレジデンシー要件がある場合はオープンソースフレームワークをVPC内に展開します。大規模実装はKuuのRDE（Reinvention Deployed Engineering）サービスでサポートしています。

参考

まとめ

AIエージェントの品質は変更のたびに劣化するリスクがあります。ゴールデンデータセットと回帰テストを組み合わせることで、この劣化を自動で検出する体制を構築できます。

実装のポイントをまとめます。

実際の失敗ケースを核にした50〜200件のゴールデンデータセットを構築する
pass^kで「全試行成功」を回帰スイートの合格基準にする
オフライン評価をCI/CDに統合し、git pushのたびに自動実行する
能力評価で合格した機能は回帰スイートに昇格させ、永続的に監視する

エージェント評価基盤の設計・構築支援についてはKuuの運用管理サービスにご相談ください。