企業の生成AI導入では、プロンプトの工夫が過大評価され、評価設計が後回しにされやすい。

担当者が複数のモデルへ同じ質問を投げ、最も自然な回答を選ぶ。気に入らない箇所があればプロンプトを追加する。この方法でもデモは作れる。

しかし、本番運用で必要なのは「たまに良い回答が出ること」ではない。業務上重要な入力に対し、許容できる品質を、必要な頻度で、予算と時間の範囲内に収めることである。

そのために必要なのが評価、つまりevalsである。

AIシステムの品質は、モデル名ではなく、何を成功と定義し、どの失敗を検出できるかで決まる。

なぜ人間の印象だけでは不十分なのか

生成AIの回答は流暢である。文章として自然で、説明も整い、自信のある表現を使う。そのため、内容の正しさ、抜け、根拠、手順違反を見落としやすい。

さらに、同じ入力でも出力が変わる可能性がある。ある一回の成功例は、安定した能力を証明しない。

人間による試読だけに頼ると、次の問題が起きる。

  • 評価者によって基準が変わる
  • 良い例だけが共有される
  • 失敗例が記録されない
  • プロンプト変更の影響を比較できない
  • モデル更新による劣化に気づけない
  • 費用と待ち時間が品質評価から分離される
  • 本番利用者の入力分布とテストがずれる

「以前より良くなった気がする」という状態では、改善も回帰も説明できない。

評価はベンチマーク順位ではなく業務テスト

公開ベンチマークは、モデルの一般能力を比較する参考になる。しかし、自社業務の成功率を直接示すものではない。

例えば、一般的な文章生成能力が高いモデルでも、次の業務では失敗する可能性がある。

  • 自社の商品分類コードを守る
  • 契約書から特定の例外条項を抽出する
  • 社内規程に従って申請を振り分ける
  • 指定形式のCSVを生成する
  • 顧客へ回答してはいけない内容を除外する
  • 古い情報と最新情報を区別する

必要なのは、自社の実際の入力と期待結果を使った評価である。

評価セットには、日常的な例だけでなく、失敗すると困る例を含める。

  • 曖昧な入力
  • 情報不足
  • 例外ケース
  • 矛盾した資料
  • 悪意ある入力
  • 長文
  • 表や画像を含む入力
  • 「分からない」と答えるべきケース
  • 人間へ引き継ぐべきケース

最初から大量のデータは要らない

評価という言葉から、数千件の正解データを想像する必要はない。

Anthropicは、エージェント評価を始める段階では、実際の失敗から取った20〜50件程度の単純な課題でも有効な出発点になると説明している。重要なのは、件数より、業務上の意味があることだ。

最初の評価セットは、次から集められる。

  1. 担当者が毎回手作業で確認している項目
  2. 過去の問い合わせ
  3. 過去の誤回答
  4. 現行業務のチェックリスト
  5. 監査で指摘された事例
  6. 例外処理の記録
  7. 利用者が頻繁に行う依頼

本番で失敗が起きたら、その事例を評価セットへ追加する。これにより、障害が一度限りの修正ではなく、将来の回帰を防ぐ資産になる。

一つの総合点で判断してはいけない

AIシステムの品質は多次元である。

評価軸確認内容
正確性事実や計算が正しいか
完全性必要な項目を落としていないか
根拠性与えられた資料に基づいているか
指示遵守形式、長さ、禁止事項を守るか
安全性機密、差別、危険な操作を避けるか
一貫性繰り返しても許容範囲に入るか
速度業務上の待ち時間に収まるか
費用1件当たりの原価が妥当か
引き継ぎ不確実な場合に人間へ戻せるか

例えば、正確性が高くても、回答に2分かかるならリアルタイム接客には使えない。安価でも、10回に1回重大な規程違反をするなら自動実行には使えない。

平均点だけでなく、重大失敗率を見る必要がある。

合否を機械判定できる部分を増やす

評価方法は、すべて人間の主観である必要はない。

決定論的に評価しやすいもの

  • JSONスキーマに合うか
  • 必須項目があるか
  • 数値が一致するか
  • 指定語を含まないか
  • コードがテストに通るか
  • データベースの状態が期待通りか
  • ツールを正しい引数で呼んだか

ルーブリックで評価するもの

  • 説明が十分か
  • 文体が適切か
  • 根拠が明確か
  • 反対材料を扱っているか
  • 不確実性を適切に表現したか

人間の専門家が必要なもの

  • 法的な妥当性
  • 医療上の判断
  • ブランドへの影響
  • 高度な編集品質
  • 新しい種類の失敗

Google Cloudの評価機能も、正解データと照合する計算型指標、評価基準に沿って判定するルーブリック型指標、独自関数などを組み合わせる構成を採っている。

一つの評価方法ですべてを判定するのではなく、機械判定、モデル判定、人間判定を使い分ける。

「成功したか」と「安定して成功するか」は別

エージェントや生成AIは、同じ課題を複数回実行すると結果が変わる。

一度でも成功すればよい探索型の仕事と、毎回成功しなければならない業務では、見る指標が違う。

  • 複数回のうち一度でも正解すればよい
  • 初回で正解する必要がある
  • 連続してすべて成功する必要がある

例えば、アイデア出しは10案のうち1案が良ければ価値がある。一方、顧客の住所変更や返金処理は、毎回正しくなければならない。

平均成功率が75%でも、3回連続ですべて成功する確率は約42%である。単発の成功率だけを見れば、繰り返し業務での不安定さを見落とす。

プロンプト変更はソフトウェア変更として扱う

プロンプトを一文追加すると、一部の入力は改善し、別の入力が悪化することがある。

例えば「必ず詳しく説明する」と追加すれば、説明不足は減るが、簡潔さ、速度、費用が悪化する。「不明点は推測しない」と強化すれば、誤答は減るが、答えられる質問まで拒否する可能性がある。

したがって、次の変更はすべて評価セットへ通すべきである。

  • プロンプト変更
  • モデル変更
  • 検索方式変更
  • 参照データ更新
  • ツール追加
  • 権限変更
  • 出力形式変更
  • ガードレール変更

生成AIシステムには、通常のソフトウェアと同じく回帰テストが必要である。

本番前評価だけでは足りない

事前評価に合格しても、本番では未知の入力が来る。

必要なのは三層の評価である。

開発時

変更ごとに自動評価を実行し、明らかな回帰を止める。

本番監視

失敗率、拒否率、引き継ぎ率、費用、待ち時間、ツールエラーを監視する。

定期的な人間レビュー

実際の会話や処理履歴を抽出し、評価項目に含まれていない問題を発見する。

Anthropicは、自動評価、本番監視、定期的な人間レビューを組み合わせ、単一の評価層に依存しないことを勧めている。

ROIは評価結果と業務指標を接続して測る

AIの精度だけでは投資対効果を判断できない。

例えば要約AIなら、次を接続して見る。

  • 合格率
  • 修正時間
  • 処理件数
  • 担当者の所要時間
  • 見落とし件数
  • 顧客への回答時間
  • 1件当たりの推論費用

AIが80%の要約を作れても、残り20%の確認に従来以上の時間がかかれば、効果は限定的である。逆に、精度が完璧でなくても、重要箇所を先に抽出して人間の確認時間を半減できるなら価値がある。

評価指標は、業務成果へつながって初めて意味を持つ。

実務で使える最小評価表

最初は、次の表で十分である。

項目内容
課題ID評価事例を識別する
入力実際の依頼や資料
期待結果正解または満たす条件
重大度失敗時の影響
判定方法自動、モデル、人間
合否Pass / Fail
費用1回当たりの推論費用
時間完了までの時間
失敗理由改善に使う分類
追加日いつ評価へ入れたか

これをモデル、プロンプト、システム変更ごとに実行し、結果を比較する。

結論

生成AI導入の初期は、良いプロンプトを集めることに関心が向く。しかし、プロンプト集だけでは品質を管理できない。

本番運用に必要なのは、実際の業務課題、明確な合否条件、重大失敗の分類、回帰テスト、本番監視、人間レビューをつないだ評価基盤である。

最も高性能と宣伝されるモデルを選ぶことより、自社の仕事で何ができ、何に失敗し、変更後にどこが悪化したかを継続的に測れることの方が重要である。

AIを導入する会社と、AIを運用できる会社の差は、プロンプトの巧さではなく評価能力に現れる。

一次情報