2026年10月01日読了約5分 Meydo Editorial Teamによる記事

実際の失敗を捉えるAI評価セットの作り方

本番環境で起きた失敗を、タスク固有の指標、回帰テスト、人による較正を備えたバージョン管理可能なAI評価へ変える実践的方法。

Labeled test cases arranged around a small AI system diagram

有用なAI評価は、ランキング表の縮小版ではありません。システムが担う仕事、ユーザーが気づく失敗、チームが受け入れるトレードオフを凝縮したモデルです。

指標ではなく、意思決定から始める

誰がシステムを使い、何を完了したいのか、回答が誤っていたら何が起きるのかを書き出します。返信文を作るサポート支援には、ポリシー遵守、手順の欠落、不適切な自信を調べるテストが必要です。文書抽出には、フィールド精度、スキーマの妥当性、値がない場合の明示的な処理が必要です。同じ汎用的な「品質」スコアで両方を診断することはできません。

OpenAIの評価ガイドは、タスク固有のテスト、早期かつ反復的な評価、可能な場合の自動採点、採点者を較正するための人のフィードバックを推奨しています。こうした原則が示すのは、製品のテストスイートのように、範囲と版が管理され、チームが実施できる変更に結び付いた評価セットです。

3つの場所からケースを集める

まず、通常の利用を代表する標準的な例を集めます。次に、長い入力、曖昧な依頼、文脈不足、矛盾する文書、未対応言語などの境界例を加えます。最後に、ログやユーザー報告で判明した失敗を加えます。3番目は、もっともらしい設計が実際に誤った内容を記録しているため、価値の高い回帰テストになることが少なくありません。

機密情報を除き、挙動の再現に必要な文脈だけを残します。各ケースには理想的な文章だけでなく、テスト対象の能力と期待する証拠を付けます。正解が一つのケースもあれば、「実行前に確認を求める」「提供文書だけを引用する」といったルーブリックが必要なケースもあります。

コンポーネントテストとエンドツーエンドテストを分ける

検索が情報源を見落とした、プロンプト内で指示が埋もれた、ツールが不正なデータを返した、モデルが判断を誤った、といった理由でエージェントは失敗します。最終回答だけを見ると、誤ったコンポーネントを調整しかねません。検索、ツール引数、ポリシーの振り分け、出力形式に絞ったテストを、タスク完了のエンドツーエンドテストと併用します。

個々のコンポーネントが正常でも相互作用で問題が起きるため、エンドツーエンドのケースも重要です。検索した箇所、ツール呼び出し、中間状態をトレースに残して診断できるようにします。一方、非公開の推論過程は必須とも信頼できる監査記録とも見なしません。

複数の採点方法を使う

スキーマの妥当性、必須フィールド、禁止された操作、引用、厳密な計算には決定論的なチェックを優先します。安定した正解があるタスクでは参照回答を使います。関連性、完全性、文体には、人またはモデルによるルーブリック採点を使えますが、自動採点者を人の判断に合わせて較正し、不一致を調べます。

すべてを一つの数値に潰さず、スコアカードで報告します。文体が改善しても根拠性が下がったリリースを、無条件の改善とは呼べません。重要な項目ごとに明確なしきい値を設け、言語、ワークフロー、リスク水準別に成績を確認します。

評価を継続的に行う

プロンプト、モデル、ツール、検索設定を変える前にベースラインを固定します。同じテスト群を候補版で実行し、構成とコストを記録して、重大な回帰をすべて調査します。新たに見つかった失敗を追加し、難しいケースを黙って削除してはいけません。テストを廃止する場合も理由を記録します。

評価セットは保守対象の製品資産です。責任者、変更履歴、アクセス制御を設けます。年2回だけ実行する壮大なベンチマークより、重要な変更のたびに動く小さなテスト群の方が役立ちます。

実践に移す方法

まず、実際の失敗を捉えるAI評価セットの構築に関わる範囲の限られたワークフローを一つ選びます。システムを変える前に、現在の完了時間、品質チェック、主な失敗分類、エスカレーション経路、結果の責任者を1ページにまとめます。最も整った例だけでなく代表的なサンプルを選び、通常例、難しい境界例、停止または追加情報の確認が正解となる例を少なくとも一つ含めます。

既存プロセスを置き換える前に、候補システムを並行稼働させます。誤り率が下がっても新たな重大事故を隠すことがあるため、成功と失敗の両方を確認します。各テストの正確な構成を記録し、別のレビュー担当者が再現できる成果物を残します。試行の終了時には、最良のデモを見た後の印象ではなく、事前に合意したしきい値に基づいて、拡大、修正、中止を決めます。

ベンダーや社内チームへの確認事項

中心的な主張を支える証拠、その証拠を生成したシステム版とデータ版、除外条件を確認します。導入先で扱う言語、入力形式、リスク分類ごとの結果を求めます。変更の告知方法、回帰の検出方法、インシデント調査に必要なログを顧客が書き出せるかも確認します。

確信度が低い場合、依存先が失敗した場合、依頼が対応範囲外の場合に、システムがどう動くかも確認します。信頼できる製品には、単に洗練された回答ではなく、定義済みの失敗状態が必要です。責任体制も重要です。ワークフローを停止できる人、例外を承認する人、重大な誤りが本番へ流出したとき影響を受けたユーザーへ知らせる人を特定します。