その仕組みが機能していると、どうやって判断しますか
AIシステムの品質劣化をどう検知するのか。この問いに答えられない導入は少なくありません。評価基盤は最初に省かれ、そして導入の妥当性を最後に左右する層です。
モデル選定には予算も関心も集まりますが、評価に回るのは残りであり、多くの案件ではそれがゼロになります。結果として、誰も採点できない導入が残ります。前より良くなった気がする、デモは好評だった、しかし来月モデルが差し替えられたときに回答品質がどう動くかは誰にも言えない。日本企業ではこの点が特に重く効きます。社内のリスク委員会が求めるのは体験談ではなく証跡であり、測定の設計を持たないベンダーは、その後の二回の会議を測定設計に費やすことになります。
評価手法の階層
SC-LY-05 · REV A · 2026.07
モデルによる採点
評価基準 · 較正済み
意味的類似度
言い換え · 埋め込み
完全一致
形が一つに定まる事実
形式とスキーマ
JSON · 必須項目 · 範囲 · CI
下の段で良否が判別できなくなったときにだけ、上の段へ進む
従来の評価手法がそのままでは使えない理由
従来の機械学習には、正解ラベル付きのテストセットと、関係者が合意した指標がありました。基盤モデルはその前提を四か所で崩します。出力が自由記述であるため、比較すべき唯一の正解文字列が存在しないことがほとんどです。モデルの内部は不可視で、挙動が変わった理由を調べられません。公開ベンチマークは短期間で飽和し、学習データに混入します。高いスコアは、能力の証拠であると同時に汚染の証拠でもあります。残るのは狭く具体的なもの、すなわち自社の業務、自社のデータ、自社にとっての良い回答の定義です。
厳密に判定できるものと、できないものを分ける
実務的な評価には二種類の検査が含まれ、これを混同すると数か月を失います。厳密な検査は形式を問います。JSONとして妥当か。必須項目が揃っているか。数値が許容範囲内か。引用先の文書が実在するか。安価で決定的であり、CIに組み込めます。もう一方の主観的な検査は内容の妥当性を問い、文書化された評価基準と採点者を必要とします。先に作るべきは厳密な層です。労力に対して捕捉できる本番障害の割合が高く、判定が揺れません。
完全一致から、モデルによる採点まで
内容の品質を測る手法には順序があります。答えの形が一つに定まる事実なら完全一致で足ります。言い換えを許容するなら意味的類似度ですが、その分だけ信頼すべき採点モデルが増えます。それ以外の大半は、評価基準を文書化したうえでモデルに採点させる方式に行き着きます。上の段に進むのは、下の段が良い回答と悪い回答を区別できなくなったときだけにしてください。一段上がるごとに費用が増え、知らないうちに劣化しうる要素が一つ増えます。
採点するモデルには既知の偏りがある
モデルによる採点は、固有の誤差を持つ測定器です。自分と同系統のモデルの出力を高く評価します。候補が提示される順序に影響されます。長さが品質に寄与しなくなった後も、長い回答を高く評価し続けます。これらは手法を使えなくする欠陥ではありませんが、検証していない採点器の数値を鵜呑みにすれば判断を誤ります。提示順を無作為化し、一定量を定期的に人手で採点し、人の評価との一致度を確認してください。較正していない採点器の数値は、引用に値しません。
指標を、経営が既に見ている数字に接続する
評価基盤を正当化する最も強い論拠は、技術的な厳密さではありません。指標が金額に対応することです。事実整合性が八割なら問い合わせの三割を無人で完結でき、九割なら五割を完結できる。そう言えた時点で、モデル改善に価値と予算と停止条件が生まれます。この対応関係を持ち込めば、議論は「AIは信用できるのか」から「どの水準なら投資判断が立つのか」に移ります。後者のほうが、はるかに前に進む会議です。
評価データは本番から採る
最初の評価セットは開発側の想像で書かれたもので、急速に陳腐化します。実際の問い合わせは、想定した形をしていません。本番のクエリを記録し、失敗した事例を抽出し、評価セットに昇格させてください。そうすれば評価は実トラフィックに近づいていきます。利用者からの否定的な反応も、会話履歴と紐づいていれば教師データです。この経路は稼働前に設計してください。後から追加しようとすると、取得済みデータの二次利用について個人情報保護の責任者と協議することになり、事業部門の判断では済まなくなります。
// 要点
押さえておきたいポイント
- 基盤モデルは従来の評価前提を崩します。出力は自由記述、内部は不可視、公開ベンチマークは飽和し学習データに混入します。
- 形式の検査と内容の検査を分け、安価で決定的な形式検査から先に整備します。
- 完全一致・意味的類似度・モデルによる採点の順に進み、下の段で良否が判別できなくなるまで上には進みません。
- 採点モデルは自系統・提示順・回答の長さに偏ります。順序を無作為化し、人手評価との一致度を検証してから数値を使ってください。
- 評価指標が無人処理率などの業務数値に対応して初めて、改善に予算と停止条件がつきます。
- 本番のクエリと利用者の反応を評価セットに還流させ、そのための同意設計は稼働前に済ませてください。
// よくあるご質問
よくあるご質問
生成AIアプリケーションの評価は、どのように行いますか。
厳密に判定できる検査から始めます。JSONとして妥当か、必須項目が揃っているか、数値が許容範囲内か、引用先の文書が実在するか。これらは安価で決定的であり、CIに組み込めます。内容の妥当性は文書化された評価基準と採点者を要して費用も時間もかかりますので、厳密な層を先に整えることをお勧めいたします。
従来の機械学習のベンチマークは、なぜそのまま使えないのですか。
基盤モデルが三つの前提を崩したためでございます。出力が自由記述であるため、比較すべき唯一の正解文字列が存在しません。内部が不可視であるため、挙動が変わった理由を調べられません。公開ベンチマークは飽和し学習データに混入するため、高いスコアは能力の証拠であると同時に汚染の証拠でもございます。
モデルによる採点は信頼できますか。
既知の誤差を持つ測定器として扱えば、有効な手法でございます。採点モデルは自分と同系統の出力を高く評価し、候補の提示順に影響され、長さが品質に寄与しなくなった後も長い回答を高く評価します。提示順を無作為化し、人手評価との一致度を確認してから数値をご利用ください。
評価基盤への投資は、どう正当化しますか。
指標を業務数値に対応させることでございます。事実整合性が八割なら問い合わせの三割を無人で完結でき、九割なら五割を完結できる。そう言えた時点で、モデル改善に価値と予算と停止条件が生まれ、財務部門が判断できる数字になります。
評価用のデータは、どこから集めますか。
本番からでございます。最初の評価セットは開発側の想像で書かれたもので、実際の問い合わせは想定した形をしていないため急速に陳腐化します。本番のクエリを記録し、失敗事例を抽出し、評価セットへ昇格させます。日本では、そのための同意設計を稼働前に済ませておく必要がございます。
最終更新:
