※本稿で扱う数値は、いずれも relmea の運用記録に基づきます。

AIエージェントの評価データ設計で、まず崩れる場所

AIエージェントの評価は、大きく分けると2つの部品でできています。ひとつは「何を入力として与えるか」（入力側）、もうひとつは「その入力に対する正しい答えは何か」（正解側）です。さらに、この2つを束ねて「テストが本当に意味のある違いを検知しているか」を確かめる不変条件のテストがあります。

この3か所は、それぞれ別の理由で壊れます。

  • 入力側が壊れる理由：AIに書かせると、AIが解釈しやすい言い回しに寄る
  • 正解側が壊れる理由：ラベル付けの手法自体が、本番で禁じている手法と同じになっている
  • 不変条件が壊れる理由：「合計が合う」ことと「意味が変わっていない」ことは別の話である

relmeaでは、この3か所すべてで実際に問題が起き、それぞれ別の対策を運用に組み込みました。次の節から、順番に一次情報つきで説明します。

評価データの入力側をAIに書かせると何が起きるか

質問文・依頼文の偏り

AIエージェントの評価データを作るとき、最初にやりがちなのが「評価用の質問文や依頼文をAIに生成させる」ことです。relmeaでもこの方法を試しましたが、AIが書いた言い回しはAIが解釈しやすい方向へ系統的に偏ることが分かりました。

さらに厄介なのは、「AIが書いた下書きを人が後から直す」という対策が効かないことです。下書きの構文や語順がすでに錨（いかり）になっていて、人が手直ししても骨格までは変わりません。

relmeaでは、評価データの入力側を次の3種類の実在の言い回しに切り替えました。

  • 検索サジェストに実際に出てくる言い回し
  • 実際に利用者から来た質問文
  • 本人の書き起こし（会話・音声を文字にしたもの）

AI生成の文をどうしても使う必要がある場合は、主セットには入れず、対照群として別枠でスコアを持つようにしています。主セットの点数とAI生成対照群の点数がずれていたら、それは「AIエージェントの実力差」ではなく「入力データの生成元の違い」を測っている疑いがある、という運用です。

フェイク応答も同じ構造で壊れる

入力側が壊れるのは、自然文の言い回しだけではありません。外部APIを呼び出すAIエージェントのテストでは、「外部APIのフェイク応答」も評価データの入力側にあたります。

2026年7月、relmeaは広告APIの読み取りツール（社内用MCP）を開発しました。このとき、テストで使う外部APIのフェイク応答を、実物を取得せずに想定で書きました。結果、テストカバレッジ98%・68テストすべて緑という状態を通過しましたが、本番では「0件返却」というバグが残っていました。

原因は単純で、フェイク応答が「自分が想定した形」を検証していただけで、実際のレスポンスの形とは違っていたためです。テストが緑になっても、それは「想定どおりに動く」ことを示しただけで、「本番のAPIに対して正しく動く」ことは何も示していませんでした。

対策として、relmeaでは「認証取得直後に生レスポンスを1本保存し、それをテストの正典にする」運用に変えました。手順にすると次のとおりです。

  • 外部APIの認証が通った直後に、実際のレスポンスを1回そのまま保存する
  • 保存したレスポンスをテストのフィクスチャ（評価データの入力側）として使う
  • 想定で書いたフェイク応答は、保存前の一時的な仮置きとしてのみ扱い、正典にはしない

言い回しであれ、APIのレスポンスであれ、評価データの入力側を「頭の中の想定」で作ると、AIエージェントは想定どおりに振る舞ったときだけ高得点を取ります。それは評価ではなく、想定の再現テストです。

正解ラベルにも検算が要る理由

入力側を実物に揃えても、正解側（正解ラベル）が誤っていれば評価は成立しません。relmeaが経験したのは、正解ラベルの誤りが、しかも「評価対象のAIエージェントに有利な形」で紛れ込んだケースです。

分類タスクの教師データを、機械的なヒューリスティック（単純なルール）で作ったところ、64件の正解ラベルのうち11件が誤りでした。さらに悪いことに、そのうち4件は、評価対象のエージェント（解決器）が同じ誤りを再現したために「正解」として採点されていました。

原因を辿ると、正解ラベルを作る際に使ったヒューリスティックが、本番では禁じている手法である「部分一致」でした。エージェント側も部分一致に近い挙動をしていたため、間違った基準どうしが一致して、誤りが誤りのまま「正解」として記録されていたのです。

これは、測定器そのものが誤りを強化する構造です。正解ラベルの作り方が甘いと、その甘さと同じ甘さを持つエージェントほど高得点になります。厳密に作られたエージェントのほうが、逆に「不正解」と判定されることさえあります。

relmeaが正解ラベルの作成に組み込んだ検算手順は次のとおりです。

  • 正解ラベルを機械的な手法（ヒューリスティック・部分一致・キーワード一致など）で作る場合、その手法が本番のロジックと同じでないかを必ず確認する
  • サンプルの一定件数を人手で見直し、機械的な手法との一致率を出す（relmeaでは64件中11件・約17%が誤りでした）
  • エージェントが誤答したケースと正解ラベルの作成手法を突き合わせ、「同じ間違え方をしていないか」を個別に確認する
  • 本番で禁じている手法（部分一致など）を、正解ラベルの作成にも使わない

正解ラベルは「一度作ったら固定の真実」ではありません。評価対象のエージェントと同じ癖を持つ手法で作られていないか、定期的に検算する対象です。

合計が合うテストは、分類の潰れを見逃す

もう1つ、relmeaが実際に見逃しかけたのが、分類の「意味の潰れ」です。

AIエージェントが4分類のうち1つを判定するタスクで、意図的に「4分類が3分類に畳まれる」変異（バグを想定した書き換え）を入れてテストしました。1つの分類が消えて、別の分類にすべて吸収される変異です。

このとき、a + b + c + d === total のような「合計が元の件数と一致するか」を確かめる等式テストは、落ちませんでした。理由は単純で、畳まれた側の分類が空配列になるだけで、4つの数を足した合計自体は変わらないためです。合計の不変条件は、「分類の中身が変わった」ことではなく「件数が保存されているか」しか見ていません。

relmeaが以後の運用に組み込んだのは、次の2点をセットで書くというルールです。

  • 合計の不変条件テスト（a + b + c + d === total）は引き続き書く。ただし、これだけでは分類の潰れを検知できないと理解した上で使う
  • 新しい分類・状態を追加するときは、必ず境界テストを対で書く。「Aという入力はBに分類される」だけでなく、「Aという入力はAには分類されていない」ことまで確認する

さらに、このテストが本当に機能しているかどうかは、推測せずに変異を入れて実測することにしました。手順は次のとおりです。

  • 意図的にバグとなる変異（分類の統合・削除・入れ替えなど）をコードに一時的に入れる
  • その状態でテストを実行し、テストが落ちるかどうかを確認する
  • テストが落ちなければ、そのテストは分類の潰れを検知できていない証拠であり、境界テストを追加する
  • 変異を元に戻し、追加した境界テストが正しく機能することを確認してから本番コードに反映する

「テストが緑だから安全」という判断は、そのテストが何を検知できて何を検知できないかを、変異を入れて実測して初めて言えることです。合計が合う・件数が合うという条件は、分類の意味が保たれていることの証明にはなりません。

明日から使える、AIエージェントの評価データ設計チェックリスト

ここまでの3つの失敗と対策を、AIエージェントの評価データ設計としてまとめると、次のチェックリストになります。新しく評価データを作るとき、あるいは既存の評価データを見直すときに、そのまま使える形にしています。

入力側の点検

  • 評価用の質問文・依頼文をAIに生成させていないか。生成させている場合、それは主セットではなく対照群として分離されているか
  • 実在の言い回し（検索サジェスト・実際の質問文・本人の書き起こし）を主セットに使えているか
  • 外部APIを呼ぶ評価では、フェイク応答が「実際に取得した1本」を元にしているか、それとも想定で書かれたものか

正解側の点検

  • 正解ラベルを機械的な手法（ヒューリスティック）で作った場合、その手法が本番で禁じている手法と同じでないか
  • サンプルを人手で見直し、機械的な手法との一致率（誤り率）を数値で持っているか
  • エージェントの誤答と正解ラベルの作成手法が、同じ間違え方をしていないか個別に確認したか

不変条件の点検

  • 合計・件数が一致する等式テストだけに頼っていないか
  • 新しい分類・状態を追加するとき、「入っている」テストと対で「入っていない」ことを確認する境界テストを書いているか
  • そのテストが実際に意味の潰れを検知できるか、変異を入れて実測したか

このチェックリストは、AIエージェントの機能を1つ追加するたびに、評価データ側も1周まわして確認する前提で運用しています。評価データは一度作って終わりの資産ではなく、エージェントの実装が変わるたびに、入力側・正解側・不変条件のどこかが古くなっていないかを点検し続ける対象です。検証役をどう分けるかはAIエージェントの成果物品質を守る検証設計の考え方で、出力側の合格基準を実物から作る方法はAI生成物の品質基準の作り方｜規約でなく実物を実測して決めるで、それぞれ扱っています。