この記事で分かること
- Evals＝テストケース集＋採点基準＋合否ライン＋再実行の仕組みという定義と、ソフトウェアのテストとの決定的な違い（期待値が一意でない・出力が毎回揺れる）
- ケースの3区分（定型・境界・過去に失敗した事例）と、公開情報ケースと合成ケース（誤りを意図的に埋め込んだケース）を分けて集計する理由
- ①数値正確性 ②出典追跡 ③数式・論理 ④指示遵守・出力形式 ⑤再現性の5軸ルーブリック（各0〜3点）と、ゲート軸を使った合否判定の設計
- 架空の20ケースを採点して合計232点・合格率70.0%まで通した計算例と、閾値を動かしたときの合格率の変化（80.0%→5.0%）
- モデルやプロンプトが変わったときの再評価トリガー7種と、記録に残すべき項目
結論：1回の出力を検証するのがdt-015、継続的に測る仕組みが本記事
社内で生成AIを使い始めると、必ず「で、このAIは使えるんですか」と聞かれます。その場でプロンプトを1本打ち込んで「ちゃんと出ますよ」と見せるのは、答えになっていません。次の1回が同じ品質である保証がなく、来月モデルが更新されて品質が変わっても誰も気づかないからです。
必要なのは、固定した問題集と採点基準を先に作り、同じ物差しで繰り返し測る仕組みです。これがEvals（評価セット）です。1回の出力が正しいかを確かめる手順——出典が実在するか、数値が転記できているか、計算が再現できるか、論理が整合しているか——は生成AI出力の検証手順で扱っています。個別出力の検証がdt-015、その検証を固定ケースに対して継続的に回す仕組みが本記事、という役割分担です。AIが作った財務モデルと人手モデルの差分分解はAI財務モデルのベンチマーク検証、AIのリスク分類は金融リスク管理でのAI活用、審査判断の説明可能性は説明可能AI（XAI）と金融審査に譲ります。
本記事の結論は3つです。第一に、採点は5軸で行い、軸ごとに0〜3点をつける。合否を二値で判断すると、どこが悪いのかが記録に残らず改善に使えません。第二に、同じ入力を原則3回実行し、単発の結果を評価にしない。出力は同じ入力でも揺れるため、1回の結果は測定値ではなくサンプル1件です。第三に、合格ラインと再評価トリガーを、測る前に決めて文書化する。結果を見てから基準を決めれば、その評価は「導入を正当化するための作業」に変わります。
Evalsとは何か｜金融実務の言葉で定義する
Evalsはソフトウェア開発の文脈で使われる言葉ですが、金融実務の言葉に置き換えると次の4点セットです（本記事における定義であり、業界標準の定義があるわけではありません）。
- テストケース集：入力（渡す資料とプロンプト）と期待される答えをセットにした、20〜50件の固定集合。
- 採点基準（ルーブリック）：出力のどこを、どの尺度で何点にするかの定義。採点者が違っても同じ点数になることを目指します。
- 合否ライン：何点以上なら業務に使ってよいか。加えて、点数に関わらず即不合格にする条件（ゲート条件）。
- 再実行の仕組み：何が起きたら測り直すか（トリガー）、結果をどこに残すか（記録）、誰が判断するか（責任者）。
ソフトウェアのテストとどこが違うか
「単体テストと同じでしょう」と言われますが、同じ発想で作ると失敗します。違いは4つです。
| 論点 | ソフトウェアの単体テスト | 生成AIのEvals |
|---|---|---|
| 期待値 | 一意に決まる（この入力ならこの戻り値） | 数値は一意だが、要約・所見文は一意に決まらない |
| 判定 | 合格／不合格の二値 | 段階評価が必要。二値にすると改善点が残らない |
| 再現性 | 同じ入力なら同じ結果（決定的） | 同じ入力でも出力が揺れる。複数回実行が前提 |
| 変更の起点 | 自社がコードを変えたとき | 自社が何も変えなくても、提供側の更新で変わりうる |
4番目が実務上いちばん厄介です。自社のコードを変えていないのに品質が変わりうるため、変更管理ではなく定期モニタリングでしか捕捉できません。金融庁の「モデル・リスク管理に関する原則」（2021年11月12日公表）でも、原則5として使用開始後のモデルへの継続モニタリングの実施が示されています。適用対象は本邦G-SIBs・本邦D-SIBs等とされ事業会社に直接適用されるものではありませんが、「作って終わりにしない」という考え方の枠組みとしては参照する価値があります（本記事の見方です）。概念そのものはモデルリスクも参照してください。
評価セットの設計｜何を、どれだけ、どう集めるか
ケースの3区分
闇雲に集めると「うまくいく問題ばかりの問題集」ができます。次の3区分で意識的に配分してください（配分は本記事の提案です）。
| 区分 | 中身 | 20件のときの目安 | 狙い |
|---|---|---|---|
| 定型 | 日常的に頻度が高い、標準的な依頼 | 10件 | 通常業務が回るかを確認する |
| 境界 | 資料が欠けている、単位が混在、注記に例外がある、決算期変更がある等 | 5件 | 「分かりません」と言えるかを見る |
| 過去に失敗した事例 | 実際に誤りが出て、人が差し戻した現物 | 5件 | 同じ失敗が再発しないかを見る |
このうち「過去に失敗した事例」は必ず入れてください。実際に起きた失敗は再発確率が最も高く、失敗事例のない評価セットでは、モデルを変えたときのデグレード（以前できていたことができなくなる）を検出できません。逆に言えば、差し戻し時にその入力と出力を捨てずに残す運用が先に必要で、これはAI導入ロードマップでいうPoC段階から始めるべき作業です。
公開情報ケースと合成ケースは分けて集計する
ケースには出自の違う2種類があり、混ぜて1つの合格率にすると、その数字は解釈できなくなります。
| 公開情報ケース | 合成ケース | |
|---|---|---|
| 作り方 | 実在の開示資料（有価証券報告書・決算短信等）をそのまま使う | 資料を加工し、単位の取り違え・期ズレ・合計不一致などの誤りを意図的に埋め込む |
| 測っているもの | 通常業務の遂行能力 | 誤りの検出能力（埋めた誤りに気づくか） |
| 正解 | 人が一次資料に当たって作る（時間がかかる） | 設計時点で既知（埋めた誤りが正解） |
| 弱点 | 著名企業の資料は学習済みの可能性があり、資料を読まずに答えても当たることがある | 人工的すぎると実務と乖離する。誤りの事前確率が100%で現実と異なる |
分ける最大の理由は、誤りの事前確率が違うことです。合成ケースは定義上100%誤りを含みますが、実務でそのような資料に当たる頻度ははるかに低い。両者を混ぜた合格率は、「実務の遂行能力」でも「誤りの検出能力」でもない、構成比次第で動く数字になります。後述の設例では、混合ベースで70.0%、公開情報だけで85.7%、合成だけで33.3%と、まったく違う結論が出ます。報告書には必ず3つとも書いてください。
なお公開情報ケースの弱点「学習済みの可能性」は、資料を渡さず社名と期だけで質問すると顕在化します。資料を渡さなくても答えてしまうケースは公開情報ケースから外すのが有効です（本記事の提案）。これはハルシネーションとは別の問題で、「たまたま当たっている」ため検証をすり抜けます。
正解データの作り方
正解は「答えの数値」だけでは足りません。①値（数値・単位・期間。例：営業利益 4,820百万円、2025年3月期・連結）、②所在（有価証券報告書 第○期・連結損益計算書・○ページ）、③導出（計算式）の3点をセットにします。所在を書かなければ軸②（出典追跡）を採点できません。作成コストは20件で概ね10〜20時間（1件30〜60分）というのが本記事の見積もりです（実データではなく作業内容からの概算）。この初期投資を認めない限り、評価セットは作れません。
正解が一意でないタスクをどう扱うか
要約、所見文、リスク指摘など、正解文が一意に決まらないタスクは少なくありません。模範解答文を1つ書いて「どれだけ似ているか」で採点すると、表現の好みを採点することになり、採点者が変わると点が変わります。代わりに必須要素リスト方式——正解を文章ではなく「含んでいなければならない要素」と「含んでいてはならない要素」のチェックリストで定義する方法——を使います。
| 種別 | 例（「売上総利益率の低下について所見を3行で」の場合） |
|---|---|
| 必須要素 | 低下幅を数値で示している／主因として原材料費と製品構成の両方に言及している／前年同期と比較している |
| 禁止要素 | 資料に記載のない要因（為替・値上げ効果など）を根拠なく断定している／将来予測を資料の裏付けなく述べている |
| 採点 | 必須要素の充足数で点数化（3個中3個＝3点、2個＝2点、1個＝1点、0個＝0点）。禁止要素が1つでもあれば、その軸は最大1点に制限する |
表現が違っても要素が揃えば同じ点になり、採点者間のばらつきが小さくなります。必須要素は3〜5個に絞ってください。10個並べると採点に時間がかかり、運用が続きません。
ケース数の目安と、増やすタイミング
本記事の提案は「最小20件から始め、業務が安定してから50〜100件へ」です。20件に統計的な根拠はなく、1回転（実行・採点・振り返り）を半日で終えられる上限という運用上の目安です。回せない評価セットは作った時点で死にます。増やすタイミングは3つ。(1) 合格率が高止まりして差がつかなくなったとき、(2) 本番で評価セットにない類型の失敗が出たとき、(3) 対象業務が広がったとき。合格率が0%や100%に張り付いた評価セットは、測定力を失っています。
採点ルーブリック｜5軸×0〜3点
採点軸は次の5つです。この5軸は本記事が設計したもので、標準規格ではありません。自社の業務に合わせて言葉を差し替えてかまいませんが、「数値」「出典」「論理」「形式」「安定性」の5つの観点は外さないことをおすすめします。
「数値正確性を2倍にすべきでは」という議論が必ず出ますが、本記事の提案は等重みのまま、ゲート条件で処理するです。重み付けは、①根拠を説明できない、②変えると過去の点数と比較できなくなる、という2つの問題を抱えます。重要な軸は「点数を重くする」のではなく「その軸が低ければ即不合格」というゲートで表現するほうが簡単です。それでも重み付けをするなら、決めた日・理由・決裁者を記録し、変えたら過去分を再集計することを条件にしてください。
再現性の測り方｜単発の結果を評価にしない
Evals設計で最も見落とされるのが再現性です。生成AIは、同じ入力に対して毎回同じ文章を返すとは限りません。1回実行した結果は「測定値」ではなく「1件のサンプル」です。本記事の提案は「原則3回実行」。3という数に統計的な根拠はなく、揺れの有無を検出できる最小の回数という実務的な選択です（2回では、違ったときにどちらが典型か分かりません）。採点ルールは次の2つです。
- 軸①〜④は、3回のうち最も点数が低い回を採用します（最悪値採点）。実務でその出力に当たった担当者が損をするのは悪い回だからです。平均を採ると、3回に1回の重大な誤りが埋もれます。
- 軸⑤（再現性）は、3回の一致度で採点します（図2の基準）。「一致」の定義は先に決めます。数値タスクは指定桁で丸めたうえでの完全一致、文章タスクは必須要素リストの充足パターンが3回とも同一であること（表現や語順の差は一致とみなす）。この定義を書かないまま「だいたい同じ」で採点すると、採点者ごとに点が変わります。
3回実行のコストが許容できない場合
20ケースなら実行60回、採点も60出力分（1件5分なら300分＝5時間）です。これが重い場合の代替は「重要ケースのみ複数回」。設例の配分（定型10・境界5・過去失敗5）なら、境界5件と過去失敗5件の計10件を3回、定型10件を1回とします。実行回数は 10×3＋10×1＝40回で、全件3回の60回に対し20回減（3分の1の削減）。揺れが出やすいのは判断が必要な境界ケースともともと失敗したケースなので、測定力の低下は限定的だと考えられます（本記事の推論であり、実測に基づくものではありません）。
注意点が1つあります。1回しか実行しないケースは軸⑤を採点できません。満点が15点ではなく12点になるため、合格ラインを12点満点用に引き直す必要があります（本記事の提案は9点以上）。15点満点の11点をそのまま持ち込むと、実質的に基準を厳しくしたことになり、期をまたいだ比較が壊れます。
整数設例｜20ケースを5軸で採点し、合格率まで出す
仮設企業「大井川インダストリー」経理財務部の設例です。数値はすべて計算手順を示すための架空の前提であり、実在企業・実在製品の実績値ではありません。
- 対象業務：取引先の開示資料から指定14項目を抽出し、6つの財務比率を計算し、与信判断の材料となる所見を3行で書く
- 評価セット：20ケース（定型10・境界5・過去失敗5／公開情報14・合成6）
- 実行：同一入力を3回、モデル・設定は固定
- 合格基準：合計11点以上（15点満点）、かつ軸①・軸②がそれぞれ2点以上
| ID | 区分 | 出自 | ①数値 | ②出典 | ③論理 | ④形式 | ⑤再現 | 合計 | 判定 |
|---|---|---|---|---|---|---|---|---|---|
| R01 | 定型 | 公開 | 3 | 3 | 3 | 3 | 3 | 15 | 合格 |
| R02 | 定型 | 公開 | 3 | 3 | 3 | 3 | 2 | 14 | 合格 |
| R03 | 定型 | 公開 | 3 | 2 | 3 | 3 | 3 | 14 | 合格 |
| R04 | 定型 | 公開 | 3 | 3 | 2 | 3 | 2 | 13 | 合格 |
| R05 | 定型 | 公開 | 2 | 3 | 3 | 2 | 3 | 13 | 合格 |
| R06 | 定型 | 公開 | 3 | 3 | 3 | 2 | 2 | 13 | 合格 |
| R07 | 定型 | 公開 | 3 | 2 | 3 | 2 | 2 | 12 | 合格 |
| R08 | 定型 | 公開 | 2 | 2 | 3 | 3 | 2 | 12 | 合格 |
| R09 | 定型 | 公開 | 3 | 3 | 2 | 2 | 1 | 11 | 合格 |
| R10 | 定型 | 公開 | 2 | 1 | 3 | 3 | 2 | 11 | 不合格（②ゲート） |
| B01 | 境界 | 公開 | 3 | 2 | 2 | 3 | 2 | 12 | 合格 |
| B02 | 境界 | 公開 | 2 | 2 | 2 | 2 | 2 | 10 | 不合格（点数） |
| B03 | 境界 | 合成 | 2 | 2 | 3 | 2 | 1 | 10 | 不合格（点数） |
| B04 | 境界 | 合成 | 1 | 2 | 2 | 3 | 2 | 10 | 不合格（①ゲート） |
| B05 | 境界 | 合成 | 3 | 3 | 2 | 2 | 2 | 12 | 合格 |
| F01 | 過去失敗 | 公開 | 3 | 3 | 3 | 2 | 2 | 13 | 合格 |
| F02 | 過去失敗 | 公開 | 2 | 2 | 2 | 3 | 2 | 11 | 合格 |
| F03 | 過去失敗 | 合成 | 0 | 2 | 1 | 3 | 1 | 7 | 不合格（①ゲート） |
| F04 | 過去失敗 | 合成 | 2 | 1 | 2 | 2 | 1 | 8 | 不合格（②ゲート） |
| F05 | 過去失敗 | 合成 | 3 | 2 | 2 | 2 | 2 | 11 | 合格 |
| 軸別合計（各60点満点） | 48 | 46 | 49 | 50 | 39 | 232 | 合格14件 | ||
検算
- 区分別：定型（R01〜R10）＝15＋14＋14＋13＋13＋13＋12＋12＋11＋11＝128。境界＝12＋10＋10＋10＋12＝54。過去失敗＝13＋11＋7＋8＋11＝50。合計 128＋54＋50＝232。
- 軸別：48＋46＋49＋50＋39＝232。区分別合計と一致します。
- 満点：20×15＝300点。得点率＝232÷300＝77.3%、平均＝232÷20＝11.6点。
- 合格率（全体）：14÷20＝70.0%。
- 出自別：公開情報14件中12件＝85.7%、合成6件中2件（B05・F05）＝33.3%。12＋2＝14で全体と一致します。
- ゲート条件の寄与：合計11点以上は15件（75.0%）ですが、うちR10はゲート違反で不合格。ゲートにより 75.0%→70.0%、5.0ポイント下がります。
この数字から何を読むか
合格率70.0%だけを報告しても、次の行動が決まりません。読むべきは軸別と出自別の内訳です。第一に、最も低い軸は⑤再現性（39÷60＝65.0%）。1回しか実行していなければ、この軸は存在すらせず、最大の弱点が見えないまま「合格率は高い」と報告されていたことになります。次に低い②出典追跡（46÷60＝76.7%）は、プロンプト側で出典表示のフォーマットを指定することで改善余地があります（金融実務のプロンプトエンジニアリング参照）。
第二に、公開情報85.7%に対して合成33.3%。「通常業務は概ねこなすが、資料側に埋め込まれた誤りにはほとんど気づかない」ことを意味します。運用判断は「不採用」ではなく「資料の正確性を人が担保したうえで使う」という条件付き採用になります。合成ケースの合格率が低いまま、AIに資料の妥当性チェックまで任せてはいけません。
第三に、全体合格率は構成比に依存します。同じ品質でも合成ケースを6件から12件に増やせば、公開情報12件合格＋合成4件合格（33.3%を維持）で 16÷26＝61.5%。構成比を変えた期と前期を単純比較してはいけません。
閾値を変えるとどうなるか
合格ラインの11点に絶対的な根拠はありません。閾値を動かしたときの合格率の動きを見て、自社が許容できる水準を意思決定として選ぶのが正しい手順です。ゲート条件を固定したまま合計点の閾値だけを動かすと、次のようになります。
読み方は2つ。第一に、10点と11点の差はわずか（80.0%→70.0%）ですが、12点にすると55.0%へ大きく落ちます。この「崖」の位置が現状の実力を示しています。第二に、閾値を後から動かして合格率を作らないこと。閾値は測る前に決め、変更するなら変更日と理由を記録し、過去分を新閾値で再集計して両方を並べてください。
Excelでの実装
専用ツールは不要です。1行1ケースの表を作り、B列に出自、C〜G列に5軸の点数を置いて、次の数式を並べれば運用できます。
| 場所 | 数式 | 意味 |
|---|---|---|
| H2（合計） | =SUM(C2:G2) | 5軸の合計点 |
| I2（判定） | =IF(AND(H2>=$L$1,C2>=$L$2,D2>=$L$2),"合格","不合格") | L1に閾値（11）、L2にゲート点（2）。この2セルを動かすだけで感応度が見られます |
| L4（合格率） | =COUNTIF(I2:I21,"合格")/COUNTA(A2:A21) | 全体合格率 |
| L5（出自別） | =COUNTIFS($B$2:$B$21,"公開",$I$2:$I$21,"合格")/COUNTIF($B$2:$B$21,"公開") | 「合成」に変えれば合成ケースの合格率 |
閾値セル（L1）を10から15まで変えれば、図3がそのまま再現できます。見せ方は感応度分析と同じで、財務モデルの作法をそのまま持ち込めます。
運用｜誰が採点し、何を記録し、いつ測り直すか
AIに任せる範囲と人が判断する範囲
| 工程 | AI・自動処理に任せてよい | 人が判断する |
|---|---|---|
| ケース収集 | 失敗ログの分類・重複候補の抽出 | どのケースを採用するか／区分の割当 |
| 正解作成 | 資料から候補値を拾う下書き | 一次資料に当たっての確定（AIの下書きを正解にしない） |
| 実行 | 3回実行・出力の保存・メタデータ記録 | 実行条件（モデル・設定）を変えるかどうか |
| 採点（軸①②③） | 数値の完全一致照合・計算の再現・出典の実在確認（機械照合が可能） | 丸め差か実質差かの線引き／出典箇所が本当にその主張を支えているか |
| 採点（軸④⑤） | 形式チェック・3回の差分抽出（自動化しやすい） | 差が結論を変えるかどうかの判断 |
| 合否判定 | 閾値・ゲートの機械適用 | 業務で使ってよいかの最終決定／条件付き採用の条件設計 |
この表の要点は、5軸のうち自然言語の判断が本当に必要なのは、所見文の質と「差が結論を変えるか」の2点だけだということです。残りは機械照合で処理できます。「AI採点は不安だから全部人手で」と決める前に、人の判断が要る部分がどれだけあるかを切り分けてください。多くの場合、人の作業量は想像より小さくなります。
AIに採点させる場合の注意
所見文の質のように自然言語の判断が必要な部分をAIに採点させることは可能ですが、次の3点を条件にしてください（いずれも本記事の提案です）。
- 採点対象と同じモデルを採点者にしない。同じ傾向の誤りを見逃す可能性があると考えられるためです（本記事の推論であり、実測に基づくものではありません）。同一モデルを使う場合は、その旨を報告書に明記してください。
- 人による抽出再採点を必ず入れる。本記事の提案は全出力の20%です。設例の60出力なら12件、5軸×12件＝60判定を人が採点し直します。AI採点と1点以上ずれた判定が6か所なら不一致率10.0%。10%を超えたら採点基準の文言が曖昧である可能性が高いため、基準の書き直しを優先します。
- 採点プロンプトを固定し、版管理する。採点基準が変われば過去の点数と比較できません。評価対象と同じ厳密さで管理します。
採点プロンプトの例
AI採点を使う場合の完成形です。そのまま使わず、自社の軸定義に合わせて書き換えてください。
【役割・目的】 あなたは金融機関のモデル検証担当者です。下記「評価対象出力」を5軸で採点し、各軸0〜3点と根拠を返します。 出力を擁護したり改善案を書いたりせず、採点だけを行うこと。 【入力】 1. 設問文（AIに与えた指示の全文）／2. 参照資料（これ以外の知識を使わない） 3. 正解データ（値・単位・期間・所在ページ・導出式／文章設問は必須要素リストと禁止要素リスト） 4. 評価対象出力（3回分。回ごとに R1 / R2 / R3 のラベルを付与） 【単位】 金額は百万円、比率は%（小数第1位）、期間は「2025年3月期・連結」の形式。 単位が異なる場合は正解データの単位に換算したうえで比較すること。 【採点方法】 - 軸①数値正確性／②出典追跡／③数式・論理／④指示遵守・出力形式： それぞれ正解データ・参照資料・設問文の形式指定と突き合わせ、3回のうち最も低い回の点数を採用する。 - 軸⑤再現性：R1/R2/R3を比較。数値は指定桁で丸めた後の完全一致、文章は必須要素の充足パターンの一致で判定。 - 0〜3点の定義は【採点基準】に厳密に従い、独自の基準を追加しない。 【禁止事項】 - 参照資料と正解データにない知識で正誤を判断しない。 - 「概ね正しい」等の曖昧な理由で加点しない。迷った場合は低いほうの点をつける。 - 文章表現の巧拙を採点に含めない（軸④の形式要件を除く）。 【不明情報の処理】 正解データに該当項目がない、または参照資料から判定できない場合は、点数ではなく「判定不能」と記載し、 どの情報が不足しているかを1行で書く。推測で点をつけない。 【出典表示】 各軸の根拠には、参照資料の該当箇所（ページ・行）または正解データの項目名を必ず引用する。 【検算】 5軸の点数を合計し、再度足し直して一致することを確認してから出力する。 合計が15を超える、または0未満になる場合は採点をやり直す。 【出力形式】 以下のCSV1行のみ。前後に説明文を付けない。 ケースID,軸1,軸2,軸3,軸4,軸5,合計,判定不能の有無,軸1根拠,軸2根拠,軸3根拠,軸4根拠,軸5根拠 【人のレビュー項目】（人が確認する観点。出力には含めない） - 軸①の「丸め差」判断が本当に丸め差か／軸②の出典がその主張を支える箇所か - 軸⑤の「結論を変えない差」という判断が妥当か
記録に残す項目
Evalsの価値は過去と比較できることにあります。1回の実行につき、実行条件（モデル名と版、設定、実行日時、実行者）、プロンプト（システム指示を含む全文または版番号）、入出力（入力資料の識別子、3回分の出力全文）、採点（軸ごとの点数・根拠・採点者の人／AIの別）、判定（合否、閾値とゲート条件の値、判定者）、前回からの差分を残してください。差分欄に「変更なし」と明記する意味は大きく、自社が何も変えていないのに合格率が動いたという事実こそが、提供側の更新を検出する唯一の手がかりになります。
再評価トリガー
| トリガー | 再評価の範囲 | 期限の目安 |
|---|---|---|
| 1. モデルの版が変わった（提供側の更新告知を含む） | 全ケース・3回実行 | 切替前。切替後にしか気づけない場合は検知から2週間以内 |
| 2. プロンプト・システム指示を変えた | 全ケース・3回実行 | 本番反映前（合格するまで反映しない） |
| 3. 参照データ・検索対象の更新 | 該当領域の全ケース＋その他から抽出 | 更新後1か月以内 |
| 4. 業務要件・出力形式・会計基準等の変更 | 該当ケースの改訂＋正解データの更新 | 適用日前 |
| 5. 本番で失敗報告が出た | 当該事例をケース化して追加。次回定期実行に含める | 報告から2週間以内にケース化 |
| 6. 定期（四半期） | 全ケース・3回実行 | 四半期ごと |
| 7. 合格率が2期連続で5ポイント超低下 | 原因調査を先行。軸別・出自別・ケース別に低下箇所を特定してから再実行 | 検知から1か月以内 |
トリガー1と6が、Evalsを持つ最大の理由です。自社が何も変えていなくても品質は変わりうる——この前提に立てているかが、AI活用の成熟度を分けます。効果の測り方はAI導入効果の測定を参照してください。Evalsは「使ってよいか」を測り、ROI測定は「使う価値があったか」を測る、別々の道具です。
やってはいけないこと
- 評価セットをプロンプトに混ぜて最適化する。問題文や正解をシステム指示や例示に入れると、そのケースだけ点数が上がり、本番では上がりません。過学習のテスト版です。理想はプロンプト改善の担当者が中身を見られない状態（ホールドアウト）に保つこと。難しい場合は2〜3割を非公開ケースとして取り置き、公開部分との合格率を比較してください。差が大きければ、公開部分に最適化されている疑いがあります。
- 合格したケースだけを残す。「設問が悪かった」として不合格ケースを削れば、合格率は自動的に上がります。修正自体は正当な作業ですが、修正理由と修正前の結果を記録し、修正した期を前期と単純比較しないことが条件です。
- 失敗ログを捨てる。差し戻したとき入力と出力を残さず修正だけして進むと、評価セットの中核である「過去に失敗した事例」が永久に作れません。差し戻し時に入力・出力・理由を保存する運用を、AI利用開始と同時に始めてください。
- 単発デモで導入を決める。デモは「できる場合があること」の証明であって、「できること」の証明ではありません。
- 合格ラインを結果を見てから決める（または下げる）。変更自体は禁止ではありませんが、変更日・理由・決裁者の記録と、過去分の再集計をセットにしてください。
- 評価セットを社外に広く共有する。公開されるほど「対策される」性質があります。ベンダー選定で外部に渡す場合は渡す用のケースと自社だけが持つケースを分けることをおすすめします（金融実務向けAIツールの選び方）。
評価セットそのものの検証方法
個別出力の検証手順は生成AI出力の検証手順に譲り、ここでは「評価セットと採点の仕組み自体が正しく機能しているか」を確かめるEvals固有の項目を挙げます。
- 正解データの二重確認：作成者とは別の人が、無作為に3〜5件について一次資料に当たり直す。正解が間違っていれば、以降の測定はすべて無意味になります。
- ネガティブコントロール：意図的に壊した出力（数値を1桁ずらす、実在しない出典を書く等）を採点フローに流し、ルーブリックが確実に0点／不合格を出せるかを確認する。不合格にできないルーブリックは、良い出力も悪い出力も同じ点にします。
- 採点者間の一致：同じ10件を2名が独立に採点し、軸ごとに点差を確認する。2点以上の差が全判定の5%を超えたら、基準文言が曖昧だと判断して書き直します（数値は本記事の提案）。
- 点数の分布とゲートの機能：全ケースが同じ点数帯に固まっていないか。100%や0%に張り付いた評価セットは改善を検出できません。ゲートで落ちたケースが1件もない期が続く場合は、ゲート条件が緩すぎる可能性があります。
- ケースの重複と偏り：同じ論点を測るケースが重複していないか、特定の業種・資料形式に偏っていないか（データバリデーションと同じ発想です）。
1と2は評価セットを作った直後に必ず実施してください。この2つを飛ばした評価セットは、動いているように見えて何も測っていないことがあります。
機密情報・個人情報の注意
評価セットは、性質上、実務で扱った実データを含みやすいものです。取引先名・与信判断・個人情報を含むケースをそのまま社外サービスに投入してよいかは、社内規程と契約条件（入力データの学習利用の有無を含む）で必ず確認してください。難しい場合は、公開情報ケースは開示資料のみで構成し、社内固有の論点は数値と固有名詞を置き換えた合成ケースで代替するのが現実的です。あわせて評価セット自体を機密として扱う必要があります。何をどう測っているかが広く知られると、その測定に合わせた最適化が起きうるためです。判断基準の詳細は生成AIに入れてよい情報・いけない情報を参照してください。
よくある失敗
- 合格率という1つの数字だけを報告する。設例では全体70.0%でしたが、公開情報85.7%・合成33.3%、軸別では再現性が65.0%と最も低い、という内訳がなければ次の打ち手が決まりません。報告は「全体・出自別・軸別」の3点セットにしてください。
- 1回実行の結果を評価にする。設例で最も弱い軸だった再現性は、1回実行では存在すらしません。
- 正解データをAIに作らせる。「AIに正解を作らせてAIを採点する」構造になり、同じ誤りが正解として固定されます。正解は必ず人が一次資料で確定します。
- 評価セットを一度作って放置する。業務が変われば評価セットも変わります。ケースを追加せず半年放置した評価セットは、現在の業務を測っていません。
- ゲート条件を置かない。合計点だけで判定すると、数値が間違っていても形式が整っていれば合格します。設例のR10（合計11点だが出典追跡1点）が典型です。
実務チェックリスト
- 評価セットの対象業務と、測らない範囲を1文で定義した
- ケースを定型・境界・過去に失敗した事例の3区分で配分した
- 過去に実際に差し戻した事例を、現物の入力・出力つきで入れた
- 公開情報ケースと合成ケースを分け、集計も分けている
- 正解データに「値・単位・期間」に加えて「所在（資料名・ページ）」を書いた
- 正解が一意でない設問は、必須要素リストと禁止要素リストで定義した
- 5軸それぞれの0〜3点の判定基準を文章で書き出し、ゲート軸とその最低点を決めた
- 合格ラインを、測定を始める前に決めて文書化した
- 同一入力を原則3回実行する運用にし、「一致」の定義（丸め桁・要素充足パターン）を書き出した
- モデル名・版・設定・実行日時を記録する場所と、再評価トリガーを文書化した
- 正解データの二重確認と、ネガティブコントロールを実施した
- 失敗ログを保存する運用（差し戻し時に入力・出力・理由を残す）を開始した
日本企業・日本市場での留意点
日本の開示資料を対象にするなら、日本固有の境界ケースを入れておく価値があります。本記事の提案として、単位の混在（百万円と千円、有報と決算短信での違い）、和暦と西暦（決算期変更年度の期間認識を含む）、会計基準の併存（日本基準・IFRS・米国基準で営業利益の定義や表示科目が異なる）、単体と連結（どちらを答えるかを設問で明示し、混同したら軸①で落ちる設計）が候補です。
制度面では、金融庁が2026年3月3日に公表した「AIディスカッションペーパー（第1.1版）」が、金融機関等におけるAIの活用実態と健全な利活用に向けた初期的な論点を整理しています。総務省・経済産業省の「AI事業者ガイドライン」も、開発・提供・利用の各主体に向けた実践的指針として公表されています。いずれも本記事の5軸ルーブリックのような具体的な採点基準を定めたものではありません。海外では米国NISTのAI Risk Management Framework（AI RMF、2023年1月26日公表）がGovern・Map・Measure・Manageの4機能で構成され、測定（Measure）を独立した機能に位置づけていますが、これは米国の任意の枠組みであり、日本の金融機関に直接適用されるものではありません。
よくある質問（FAQ）
Q. ベンダーが示す公開ベンチマークのスコアは、選定の判断材料になりますか。
A. 一次的な足切りには使えますが、採用判断の根拠にはなりません。公開ベンチマークは汎用的な課題で測られており、自社の資料形式・出力要件・許容誤差を反映していないためです。本記事はいかなる製品のスコアも掲載しません（実測していない数値は記載しない方針であり、製品スコアは版が変われば変わるためです）。判断は必ず自社ケースでの測定に基づいて行ってください。
Q. 温度（temperature）を0に設定すれば、再現性の問題はなくなりますか。
A. 出力のばらつきが小さくなることは期待できますが、完全に同一の出力が保証されるかは製品・提供形態によって異なります。各社の公式ドキュメントで確認してください。実務上より重要なのは、設定値を固定して記録に残し、その設定のもとで実際に揺れが起きていないかを測ることです。設定を信頼して測定を省略するのは、順序が逆です。
Q. 評価セットを作る工数を、どう社内で正当化すればよいですか。
A. 「品質保証のため」だけでは通りにくいのが実情です。Evalsがないと発生するコスト——(1) モデル更新時に品質低下を検出できず誤った出力が業務に流れるリスク、(2) 「使えるかどうか」の議論が毎回感想ベースで蒸し返される時間、(3) 内部監査やモデル検証部門から根拠を求められたときに出せる資料がないこと——を並べるほうが説得力があります。
次に手を動かす
本記事の20ケース採点表（ID・区分・出自・5軸・合計・判定＋閾値セル）をExcelで再現し、自社業務の「過去に差し戻した事例」を5件だけ入れて、最初の評価セットを組んでみてください。5軸の採点は、財務モデルのQC観点をそのまま流用できます。
まとめ
「このAIは使えるのか」に答えるには、感想ではなく同じ物差しで繰り返し測った記録が要ります。必要なのは、テストケース集・採点基準・合否ライン・再実行の仕組みの4点セット。ケースには境界と過去に実際に失敗した事例を必ず含め、公開情報ケースと合成ケースは分けて集計する。採点は数値・出典・数式論理・形式・再現性の5軸で0〜3点をつけ、数値と出典はゲート軸として即不合格の条件にする。
そして同じ入力を原則3回実行してください。設例で最も低かったのは再現性（65.0%）でした。1回だけ実行していれば、この最大の弱点は測定対象にすらならず、「合格率は高い」という報告だけが残ったはずです。
Evalsの本当の価値は最初の1回の測定ではなく、モデルが変わったとき、何も変えていないのに数字が動いたときに、それを検出できることにあります。閾値と再評価トリガーを測る前に決め、記録を残し、四半期ごとに回す。この地味な仕組みが、AI活用を「試してみた」から「業務に組み込んだ」へ移す一歩になります。
出典・参考（2026-08-16確認）
- 金融庁「モデル・リスク管理に関する原則」（令和3年11月12日） https://www.fsa.go.jp/common/law/ginkou/pdf_02.pdf （原則5として、使用開始後のモデルへの継続モニタリングの実施が示されています。適用対象は本邦G-SIBs・本邦D-SIBs等の金融システム上重要な金融機関とされています）
- 金融庁「AIディスカッションペーパー（第1.1版）｜金融機関等におけるAIの活用実態と健全な利活用の促進に向けた初期的な論点整理」（2026年3月3日公表） https://www.fsa.go.jp/news/r7/sonota/20260303/aidp.html
- 総務省・経済産業省「AI事業者ガイドライン」 https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html （AIの開発者・提供者・利用者それぞれに向けた実践的指針）
- NIST「AI Risk Management Framework（AI RMF 1.0）」（2023年1月26日公表） https://www.nist.gov/itl/ai-risk-management-framework （Govern・Map・Measure・Manageの4機能。米国の任意の枠組みであり、日本の金融機関に直接適用されるものではありません）
- 本記事の5軸ルーブリック、ゲート条件、合格ライン、ケース区分と配分、再評価トリガー、ケース数・工数の目安は、いずれも本記事が実務上の考え方として提案するものであり、公的機関や業界団体が定めた基準ではありません。設例（仮設「大井川インダストリー」経理財務部・20ケース）の数値も計算手順を示すための架空の前提です。本記事ではいかなるAI製品についても実測を行っておらず、製品別のスコアも掲載していません。
※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。