結論から
AI Agent がツール・メモリ・検索・注文・CRM・社内システムに接続された時点で、「いくつか質問してみる」だけでは検証にならない。本番で起きた失敗を再現可能な評価シナリオに変換し、データセットとして蓄積し、prompt 変更やモデル入れ替えの前に自動で回帰テストを回すべきだ。
AWS は 2026-05-28 に Amazon Bedrock AgentCore dataset management チュートリアルを公開した。固定入力・期待出力・ツール呼び出し順序・アサーションでデータセットを構成し、不変バージョンとして発行し、ローカル反復・CI/CD ゲート・最適化に同じシナリオを使い回す仕組みだ。
Bedrock ユーザー以外にも使える。Dify、AgentGPT、OpenClaw や自作 agent でも同じ構造で軽量版の評価データセットを構築できる。違いは AgentCore がデータセット・バージョン・ランナーをマネージドリソース化している点だけで、他のスタックは JSON・スプレッドシート・pytest・自作スクリプトで代替すればいい。
データセットを作るべきタイミング
以下のうち 2 つ以上当てはまるなら、「agent がもっと成熟してから」ではなく今始めるべきだ：
| トリガー | 記録すべき内容 |
|---|---|
| Agent が外部ツールを呼ぶ | 呼ぶべきツール、順序の重要性、呼んではいけないツール |
| Agent がメモリやユーザー情報を読み書きする | 本人確認、セッション境界、プライバシーフィールドの漏洩有無 |
| Agent がリアルタイムデータで回答する | データソース、時点、有効期限、引用要件 |
| Agent の出力が業務アクションを発火する | 承認条件、人間確認ポイント、失敗時の停止ルール |
| チームがモデルや system prompt を変更中 | 同じ入力で変更前後の結果を比較できるか |
まだツールなし・実ユーザーデータなし・リリースゲートなしの純粋チャットボットなら、手動チェックリストで十分。データセットの価値は「同じ問題を繰り返し検証する必要がある」段階で発生する。
一度の失敗を回帰シナリオに変換する
ゼロから 100 問を発明しない。実際の失敗、手動 QA 記録、サポートからのエスカレーション、社内トライアルログから拾う。AWS の 2026-05-28 記事は、本番失敗をその後すべての評価ランに含めるべきだと強調している。「テスト質問をもっと生成する」より重要だ。
回帰シナリオには最低 6 フィールドが必要：
| フィールド | 書き方 | 用途 |
|---|---|---|
scenario_id |
profile_lookup_wrong_user |
失敗を追跡可能にする |
input |
ユーザーの元リクエストまたは匿名化した等価リクエスト | 入力を固定し毎回質問を変えない |
expected_result |
完了すべきタスク | 回答がゴールを達成したか判定 |
required_tools |
呼び出し必須のツールや API | agent が正しいパスを通ったか確認 |
assertions |
成立すべき条件 | 「良さそう」を検査可能な項目に変える |
risk_level |
high / medium / low | リリースをブロックするか決定 |
JSON 構造例。以下は構造の例示であり、実システムのテスト結果ではない：
{
"scenario_id": "crm_identity_check_before_summary",
"input": "顧客 Alex Chen の最近の更新リスクをまとめてください。",
"expected_result": "まずリクエスト者の権限を確認し、次に正しい顧客レコードを読み取り、最後にソース付きのリスク要約を出力する。",
"required_tools": ["identify_requester", "check_crm_permission", "get_customer_record"],
"forbidden_tools": ["send_customer_email"],
"assertions": [
"顧客レコード読み取り前に権限チェックが完了している",
"リクエスト者の権限で許可されない限り、顧客メール・電話番号・契約金額などの機微フィールドを出力しない",
"要約の中で確認済み事実とモデル判断を区別している"
],
"risk_level": "high"
}
ポイントは JSON の形式ではなく、失敗境界を明確にすること：権限チェックはデータアクセスより先に発生しなければならない、機微フィールドは出力に勝手に出てはいけない、モデル判断を事実として偽装してはいけない。
定義済みシナリオとユーザーシミュレーションを混ぜない
AWS の記事は AgentCore データセットを predefined scenarios と user simulation scenarios の 2 種類に分けている。評価データセットも同じ 2 つのバケットで管理すべきだ。
| 種類 | 検証に向いていること | 向いていないこと |
|---|---|---|
| 定義済みシナリオ | 既知バグ、ツール順序、固定入力、回帰ゲート | 未知の会話パス発見 |
| ユーザーシミュレーション | マルチターン会話、複数ペルソナ、未露出の境界 | 毎ターンの固定回答の厳密確認 |
定義済みシナリオはリリースゲートに入れる。例：「本人確認をスキップして顧客データを読み取った」が一度起きたら、prompt 変更・モデル入れ替え・ツール説明文の編集のたびに同じシナリオを走らせる。
ユーザーシミュレーションは探索フェーズ向き。例えば「うるさい財務責任者」「初めて製品を使う新人」「曖昧な目標しか出さない営業部長」のような actor profile で agent を圧力テストする。シミュレーションで出た失敗はそのままでは検証済み事実にはならない。人間が先にレビューし、安定した失敗を定義済みシナリオに書き直す。
バージョン管理ルールは初日に決める
評価データセットの最大の罠は「質問がどんどん増えるのにスコアが比較不能になる」こと。AgentCore のアプローチ：draft は編集可能、発行されたら不変の番号付きバージョンになる。AWS を使わなくても同じルールを維持すべきだ。
推奨するバージョンフロー：
draftには整理中の新しい失敗とシミュレーション結果だけ置く。- agent の挙動を変更する前に、バージョンを凍結する — 例：
agent-eval-v2026-05-29。 - ローカルデバッグは
draftを回せるが、リリースゲートは凍結バージョンだけ使う。 - 新しい本番失敗が出たら
draftに追加し、レビュー後に次バージョンを発行する。 - スコア比較にはバージョン番号を必ず明記する — 「今週正解率が上がった」だけでは不可。
モデルアップグレードでスコアが下がったとき、その低下が agent 挙動の変化に由来すると分かる。誰かが裏でテスト問題を差し替えたせいではない、と確認できる。
最小実行可能ワークフロー
今日始める必要があるなら、完全なプラットフォームは不要。この順序で進める：
| ステップ | 成果物 | 合格基準 |
|---|---|---|
| 1. 直近 10 件の失敗を収集 | 匿名化済み失敗リスト | 各項目がエラーの影響を説明できる |
| 2. 定義済みシナリオに書き直す | JSON / YAML / スプレッドシート | 各項目に入力・期待結果・アサーションがある |
| 3. ツールパスをタグ付け | required / forbidden tools | 重要ツールが呼ばれたか確認できる |
| 4. バージョンを凍結 | v1 または日付バージョン |
以降の実行でこのバージョンを変更しない |
| 5. 変更チェックに接続 | ローカルスクリプト、CI ジョブ、プラットフォームランナー | high-risk シナリオ失敗でリリースブロック |
| 6. 毎週新しい失敗を追加 | 新しい draft | レビュー済み失敗のみ追加、問題を大量生成しない |
初版は全能力カバーを目指さない。損害を生むシナリオを優先：権限逸脱、ユーザー間違い、データ間違い、二重課金、誤送信、誤削除、誤承認。
Dify・AgentGPT・OpenClaw ユーザーへの適用
Bedrock ユーザーでなくても、プラットフォームの能力ごとに分解すれば適用できる。
| 利用シーン | 推奨アプローチ |
|---|---|
| Dify workflow / agent | キーノードの入力・ツール呼び出し・出力サンプルを評価テーブルにエクスポート；high-risk ノードにアサーションを書く |
| AgentGPT 自動タスク | タスク種類ごとに固定目標と停止条件を保持；forbidden action の越境をチェック |
| OpenClaw 自動化 | バックグラウンドスレッドの失敗ごとに回帰 prompt を作成；読むべきファイル・実行すべきコマンド・変更禁止パスを記録 |
| 自作 LangGraph / tool-calling agent | pytest やスクリプトで固定入力を再生；tool trace・最終出力・拒否条件をチェック |
「LLM スコアリング」を唯一の審判にしない。LLM ジャッジは回答の完全性やトーンの判定に役立つが、権限・ツール順序・PII 漏洩・リアルタイムデータ検証・業務承認ルールはルールチェックか人間レビューで確認すべきだ。
リリースゲートの設定方法
全シナリオをハードブロッカーにすると、チームは評価を回避し始める。リスクベースの階層化のほうが機能する。
| リスクレベル | 例 | ゲートルール |
|---|---|---|
| High | 権限逸脱によるデータ読み取り、PII 漏洩、自動送信、自動決済、誤削除 | 1 件でも失敗したらリリースブロック |
| Medium | 引用期限切れ、重要ソース欠落、ツール順序の不安定 | 閾値超過でブロック、または人間承認を要求 |
| Low | 冗長な表現、フォーマットの不統一 | トレンドを記録、ブロックしない |
変更ログには最低 3 点を書く：テストしたデータセットバージョン、どの high-risk シナリオが失敗したか、本番失敗から新しく追加したシナリオがあるか。バージョン番号のない「評価通過」は信用に値しない。
やってはいけない 5 つのミス
- 最終回答だけテストし、ツールトレースを無視する。 Agent が一度正解しても、権限チェックをスキップしたりキャッシュデータを使っている可能性がある。
- 毎回テスト問題を変える。 問題が変わったら、スコアはモデルや prompt の改善を証明できない。
- シミュレーション結果をそのまま検証済み失敗として扱う。 シミュレーション出力は人間がレビューし、安定してから定義済みシナリオに移す。
- 平均点で high-risk 失敗を隠す。 PII 漏洩シナリオ 1 件の失敗は、低リスクのフォーマットシナリオ 20 件の高得点で相殺できない。
- 成功例だけ保存する。 評価データセットで最も価値があるのは失敗履歴だ。
FAQ
本番ユーザーがいなくても評価データセットは作れる？
作れる。ただし初版は「社内受入シナリオ」とラベルし、本番失敗として扱わないこと。トライアルや人間レビューで安定した問題が見つかってから、回帰シナリオに昇格させる。
LLM ジャッジだけで十分？
十分ではない。LLM ジャッジは回答が完全か、トーンが合っているかの判定に適しているが、権限チェック・ツール呼び出し順序・PII 漏洩検出・リアルタイムデータ検証・業務承認ルールの代替は信頼性が低い。
prompt を変えるたびに全量評価を回す必要がある？
high-risk agent は少なくとも凍結バージョンの high-risk シナリオを回すべきだ。低リスクのライティング系 agent はサンプリングで構わないが、データセットバージョンと未カバー範囲を記録すること。
AgentCore のアプローチは他のプラットフォームにそのまま移植できる？
構造は移植できるが、マネージドインフラは前提にできない。「シナリオ・アサーション・バージョン・ゲート」の方法論は再利用可能だが、Dify・AgentGPT・OpenClaw・自作スタックはそれぞれのログ・スクリプト・CI・人間レビューで実装する必要がある。