壊れやすいAIを安定させる:評価基盤で自動テストをCI/CDに組み込む
開発中のAIエージェント、プロンプトを少し変更したら意図しない挙動をするようになった」「毎回手動で出力をチェックするのが限界…」そんな悩みを抱えていませんか?LLMを使ったアプリケーションの品質保証は、従来のソフトウェアテストとは異なる難しさがあります。本記事では、AIエージェントの振る舞いを継続的かつ自動的に評価するための「評価基盤」構築ガイドを解説します。ゴールデンデータセットの作成からCI/CDへの組み込みまで、明日から開発フローに導入できる具体的な手法を紹介し、手戻りの少ない安定したエージェント開発を実現します。
AIエージェント開発における評価の重要性:なぜ自動評価基盤が必須なのか
AIエージェント開発において、手動での動作確認は初期段階では有効ですが、すぐに限界を迎えます。プロンプトの微調整、利用するモデルの変更、あるいは新しいツールの追加といった日常的な開発作業が、予期せぬ性能劣化(リグレッション)を引き起こす可能性があるからです。特に、複数のツールを自律的に呼び出すエージェントの場合、変更の影響範囲を人間がすべて予測するのは困難です。
この課題を解決するのが 自動評価基盤 です。従来のソフトウェア開発でユニットテストやE2Eテストが果たす役割と同様に、AIエージェントの振る舞いをコード化されたテストケースで継続的に検証する仕組みが不可欠です。自動評価基盤を導入することで、以下のメリットが得られます。
- 客観性と再現性: 誰がいつ実行しても同じ基準で性能を測定でき、属人性を排除します。
- 迅速なフィードバック: コードやプロンプトの変更後、すぐに性能への影響を把握でき、問題の早期発見に繋がります。
- 開発サイクルの加速: 手動確認の工数を削減し、開発者がより創造的な改善作業に集中できるようになります。
品質保証(QA)の観点を開発プロセスに組み込み、自動テスト を文化として根付かせることが、信頼性の高いAIエージェントを継続的に提供するための鍵となります。
評価基盤の全体像:ゴールデンデータセット、評価指標、自動評価ループの設計
効果的な評価基盤は、いくつかのコンポーネントが連携して動作するシステムです。その中核をなすのが「評価ループ」であり、主に以下の4つの要素で構成されます。
- ゴールデンデータセット: エージェントに解かせるべきタスク(入力)と、そのタスクに対する理想的な結果(期待出力)をペアにしたデータセットです。これが評価の「正解」となります。
- 評価ランナー: ゴールデンデータセットからタスクを一つずつ取り出し、評価対象のエージェントに実行を指示するプログラムです。
- 評価指標(メトリクス): エージェントの実際の出力と、データセット内の期待出力を比較し、性能を数値化(スコアリング)するロジックです。
- 結果ストア: 実行日時、モデルバージョン、プロンプトのバージョン、そして算出されたスコアといった評価結果を記録・保存するデータベースやファイルストレージです。
このループは、「データセットを基にエージェントを実行し、出力を指標で評価し、結果を保存する」という一連の流れを自動化します。この仕組みを構築することで、エージェントの性能を定量的かつ継続的に追跡することが可能になります。
実践的なゴールデンデータセットの作成と管理手法
評価基盤の品質は、ゴールデンデータセットの品質に大きく依存します。質の低いデータセットでは、いくら高度な評価ループを構築しても意味のある結果は得られません。実践的なデータセットの作成には、以下のようなアプローチが考えられます。
- ユーザーログからの抽出: 実際にユーザーが利用したログの中から、エージェントがうまく機能した成功事例を抽出してデータセットに追加します。これは、現実世界のユースケースを反映できる強力な手法です。
- 専門家による手動作成: サービスのドメイン知識を持つ専門家が、典型的または重要なタスクと、その理想的な実行結果を手動で作成します。特に、エージェントが間違いやすい境界ケースや複雑な指示を含むデータは価値が高いです。
- 既存ベンチマークの活用:
AgentBenchやHELMといった公開ベンチマークを参考に、自社のタスクに合わせてカスタマイズする方法もあります。
データ形式は、1行に1つのJSONオブジェクトを格納するJSONL形式が一般的です。各オブジェクトには、task_id, input_prompt, expected_output, category といったフィールドを含めると管理しやすくなります。
{"task_id": "user-query-001", "category": "info-retrieval", "input_prompt": "先週の営業ミーティングの議事録を要約して。", "expected_output": "先週の営業ミーティングは...(要約文)"}
{"task_id": "code-gen-002", "category": "code-generation", "input_prompt": "Pythonで現在時刻をISO 8601形式で出力する関数を書いて。", "expected_output": "import datetime\ndef get_iso_time():\n return datetime.datetime.now().isoformat()"}
作成したデータセットは、コードと同様にバージョン管理することが重要です。Git LFS (Large File Storage) を利用すれば、大規模なデータセットもGitリポジトリ内で効率的に管理でき、どのバージョンのコードがどのバージョンのデータセットで評価されたかを明確に追跡できます。
効果的な評価指標の選び方と実装:LLMベース評価と既存メトリクスの活用
エージェントの出力をどう評価するかは、タスクの性質によって大きく異なります。ここでは代表的な2つのアプローチを紹介します。
LLMベース評価
GPT-4oのような高性能なLLM自体を「評価者」として利用する手法です。評価対象エージェントの出力とゴールデンデータセットの期待出力を評価者LLMに渡し、特定の評価基準に基づいてスコアリングさせます。
例えば、以下のようなプロンプトで評価を依頼できます。
# 指示
あなたは優秀な品質評価者です。以下の「正解」と「エージェントの回答」を比較し、「正確性」と「網羅性」の観点からそれぞれ5段階で評価し、その理由を簡潔に述べてください。出力はJSON形式でお願いします。
# 正解
...(ゴールデンデータセットの期待出力)...
# エージェントの回答
...(評価対象エージェントの出力)...
この手法の利点は、人間の感覚に近い定性的な評価や、表現の揺れに柔軟に対応できる点です。一方、評価コストがかかることや、評価者LLMのバイアスによって評価結果が安定しない可能性がある点には注意が必要です。
既存メトリクスの活用
より客観的でコストの低い評価方法として、従来から使われている評価指標も有効です。
- 完全一致 (Exact Match): 出力が期待結果と完全に一致するかを判定します。シンプルですが、少しの表現の違いも許容しません。
- 意味的類似度 (Semantic Similarity):
text-embedding-3-largeのようなモデルで出力と期待結果をベクトル化し、そのコサイン類似度を計算します。これにより、表現が異なっても意味的に近ければ高いスコアが得られます。 - タスク成功率 (Task Success Rate): エージェントの最終的な成果物で評価します。例えば、Web操作エージェントであれば「予約確認ページの特定のHTML要素が存在するか」、コード生成エージェントであれば「生成されたコードがユニットテストをパスするか (
Pass@k)」で成否を判定します。
これらの評価ロジックは自前で実装することも可能ですが、langchain-evaluation や promptfoo といったOSSライブラリを活用すると、多様な評価指標を効率的に試すことができます。特に promptfoo はYAML設定ファイルでテストケースと評価指標を定義できるため、手軽に導入しやすいツールの一つです。
CI/CDパイプラインへの組み込み:継続的な品質保証を実現する自動評価ワークフロー
評価基盤を構築したら、それをCI/CDパイプラインに組み込むことで、継続的な品質保証 が実現します。GitHub ActionsやGitLab CI/CDといったツールを利用して、特定のブランチへのプッシュやマージをトリガーに評価ジョブを自動実行するワークフローを構築します。
以下は、main ブランチにコードがプッシュされた際に評価スクリプトを実行するGitHub Actionsの簡単な設定例です。
name: AI Agent Evaluation
on:
push:
branches: [ main ]
workflow_dispatch:
jobs:
evaluate:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
lfs: true # Git LFSで管理しているデータセットをチェックアウト
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run evaluation script
run: python scripts/evaluate.py --dataset ./data/golden.jsonl --output ./results/
- name: Upload evaluation results
uses: actions/upload-artifact@v4
with:
name: evaluation-results
path: results/
このワークフローにより、開発者はプロンプトやビジネスロジックの変更がエージェント全体の性能に与える影響を、プルリクエストのレビュー段階で客観的なスコアとして確認できます。これにより、「改善したつもりが、別の箇所で性能が悪化していた」といったリグレッションを未然に防ぎ、チーム全体で品質を維持しながら開発スピードを向上させることが可能になります。
評価結果の分析とフィードバック:エージェントの改善サイクルを加速させる可視化戦略
自動評価によって得られたスコアは、ただ眺めるだけでは意味がありません。その結果を分析し、次の改善アクションに繋げるプロセスが最も重要です。
まず、評価結果、特にスコアが低かった失敗ケースを詳細に分析します。失敗の原因は、「プロンプトの指示が曖昧だった」「利用可能なツールを正しく選択できなかった」「LLMが事実に基づかない情報を生成した(幻覚)」など様々です。これらのエラーを分類・集計することで、エージェントが持つ根本的な弱点を特定できます。
次に、これらの分析結果を開発チーム全体で共有するために、評価結果を可視化するダッシュボードを構築することをお勧めします。GrafanaやLooker StudioのようなBIツールを使い、以下のような情報を表示します。
- 主要メトリクスの時系列推移: 全体スコアの推移をブランチやモデルバージョンごとに比較し、どの変更が性能向上に寄与したかを一目でわかるようにします。
- カテゴリ別スコア: 「情報検索」「データ分析」「メール作成」といったタスクカテゴリごとのスコアを表示し、エージェントの得意・不得意な領域を明らかにします。
- 失敗ケース一覧: スコアの低いテストケースとその実行結果(エージェントの思考プロセスを含む)を一覧表示し、開発者がすぐにデバッグに着手できるようにします。
このような可視化されたフィードバックループを構築することで、チームはデータに基づいた意思決定を下せるようになります。プロンプトの改善、Few-shotサンプルの追加、あるいはエージェントの思考ロジックの修正といった具体的な改善策の優先順位付けが容易になり、開発サイクル全体が加速します。


