業務AIシステムのシナリオ評価セットを構築する方法

シナリオ評価セットは、難しそうな質問を集めるのではなく、一つの限定された業務フローを再現できる形で記録し、通常業務と重大な例外の双方を検証できるように作ります。例えば購買申請支援AIに、自然な申請書、食い違う取引先番号、取得不能な社内規程、添付見積書に埋め込まれたAI向け指示が同時に届く場面では、整った例題だけの高得点は判断材料になりません。評価対象の版、利用者、入力、参照可能な情報とツール、支援できる範囲、リリース判断を先に固定することが出発点です。

シナリオ評価セットでは何を網羅すべきか

網羅すべきなのは、想定業務の構成を映す代表的な仕事と、頻度だけでは拾えない重要な境界、既知の失敗、禁止行為です。まず、権限を確認した業務記録、問い合わせ、利用者調査、インシデント、業務担当者の説明からタスク群と変化軸を洗い出します。運用実績が乏しければ、精密な比率を装わず仮説と不確実性を明記します。購買申請支援AIなら、完全な申請、書類不足、金額や取引先情報の不一致、判断材料の欠落、人の承認を飛ばす依頼、添付物内の命令、規程検索の失敗、確認済み不具合の最小化した再現を含めます。これは組織固有の権限と規程に合わせる例であり、共通規則ではありません。

各評価シナリオをどう記録すれば再現できるか

各シナリオは、別の担当者が同じ開始状態を作り、許容結果と禁止結果を区別して採点できる事例票にします。入力文だけでは、参照できた規程、利用権限、ツールの返却値、直前の会話、システム指示が欠け、同じテストを再現できません。また、正解を一つの言い回しに固定すると、内容が正しい別表現や別経路を誤って落とします。必要な事実や状態変更、許容できる代替経路、確認質問・保留・拒否・人への引き継ぎが必要な条件を分けて記録し、禁止される開示、操作、ツール呼び出し、状態変更は品質期待とは別欄に置きます。

• 識別情報：安定した事例ID、所有者、版履歴、タスク群、カバレッジ区分、スライス、影響、開発用か保護テストか。
• 由来と統制：出所の種類、再利用の承認、必要な匿名化・最小化、アクセス可能な原資料への管理された参照。
• 開始条件：利用者の役割と目的、初期状態、依頼と添付資料、履歴、利用可能な知識・ツール・権限・環境。
• 期待値：必須の事実や結果、許容する代替、確認・保留・拒否・引き継ぎの条件、禁止される出力と操作。
• 運用情報：採点器、ルーブリックとゲート、参照解、必要な試行数と集約規則、審査資格、裁定経路、構成要素の各版。

有用な評価事例は難問を置くだけでなく、限定された仕事を再現し、成功、許容される違い、禁止行為を検査可能にする。

ModelFold編集部

誤った振る舞いを褒めずにどう採点するか

採点には、そのシナリオの成功と失敗を妥当に分けられる最も限定的な方法を使います。形式、計算、必須フィールド、ツール引数、レコード状態、禁止操作を客観的に確認できるなら決定的チェックが向きます。必要な事実や終了状態は限定される一方、表現や経路に幅があるなら参照事実または参照解を使います。 usefulnessや説明品質のように開かれた評価だけを、観測可能なアンカーを持つ次元別ルーブリックに委ねます。モデル採点器は開発事例での一致だけで十分とせず、該当業務を理解する人の判断に照らして校正します。

• 既知の作業可能な解で事例が解けることと、チェックが意図した結果を検出することを確認します。
• 意味のある作業要素には部分点を認めても、どの要素が失敗したかを集計値の内側に隠しません。
• 機密情報の開示や無権限の実行など、責任者が明示した禁止行為は一般品質と分離した非補償型ゲートにします。
• ルーブリック版、ゲート、スライス、試行の集約方法、判断規則は候補出力を比較する前に固定し、変更時は新しい評価版として残します。

審査担当者はどうすれば基準を一貫して適用できるか

一貫した審査には、出力を見る前に共有する短い審査ガイドと、実案件前の校正が必要です。ガイドには業務目的、利用者の役割、利用可能だった証拠、許容される振る舞い、製品境界、ルーブリック版を示します。各評点には観測可能なアンカーと肯定例、否定例、境界例を置き、事例や証拠が壊れている場合の「採点不能」も用意します。比較評価では実行可能な範囲でシステム名と出力順を伏せ、審査担当者は話し合う前に個別の点数と理由を保存します。

• 本番審査の前に校正事例を採点し、タスク構成、ポリシー、ルーブリック、担当者群が変わったときは校正をやり直します。
• 不一致は直ちに多数決で消さず、事例の欠陥、曖昧な境界、背景不足、正当な複数解、未決定の製品判断のどれかを調べます。
• 裁定責任者を定め、元の評価、理由、使用したルーブリック版、裁定結果を保存します。
• 専門的・規制対象の判断が必要な場合は、適切な資格と権限を持つ担当者に残します。

開発とリリースを通じて評価証拠をどう保つか

評価証拠を保つには、繰り返し使う開発用セットと、使用を限定する保護されたリリーステストを登録時から分けます。開発用事例はプロンプト、検索、ツール、ポリシー、業務フローの改善に何度でも使えますが、チームが内容を見て最適化した後の点数は開発証拠です。保護テストは通常実行や出力確認の前に所属を決め、最終比較やリリース判断に限定して使います。事例、参照解、ルーブリック、結果のいずれかが変更を実質的に導いた時点で独立性は失われるため、その事例を開発・回帰側へ移し、重複しない版管理済みの代替を追加します。

• セット間で完全一致、近似重複、同じ原記録、言い換え、同じテンプレートから作った兄弟事例を検査します。
• 事例内容、参照解、ルーブリック、結果に誰がアクセスしたかを追跡し、露出状態を登録簿へ反映します。
• 確認済みの失敗は機密情報を最小化して回帰事例へ加え、保護側では同じ失敗類型を独立作成した非重複事例で試します。
• 所有者、出所、利用承認、所属、露出、各構成要素の版、審査履歴、変更理由、廃止理由を一つの登録簿で管理します。
• 業務、利用者、規程、知識、モデル、プロンプト、ツール、権限、運用環境が大きく変わったら、カバレッジと採点方法を見直します。

結果はタスク群、カバレッジ区分、スライス、影響、ゲート別に示し、平均点だけでリリースを決めないことが重要です。オフライン評価の合格は、業務価値、安全性、公平性、法令適合性、本番準備の証明ではありません。製品・リスク責任者が結果を見る前にゲートと用途を定め、業務担当者が現実性を確認し、個人情報、セキュリティ、法務、財務、人事、安全などの判断が関係する場合は権限を持つ専門担当を参加させます。さらに監視、利用者調査、インシデント確認など、利用状況に合う証拠と組み合わせます。