生成AIの導入後に起きやすい停滞は、「出力が良いか悪いか」を感覚で議論してしまうことです。文章が自然でも、確認工数が増えたり、重要な条件を落としたり、後工程で使われなければ、業務効率化にはつながりません。
結論から言うと、生成AIの評価はモデル単体の性能比較ではなく、任せたい業務が品質・安全性・工数の面で成立するかを確かめる作業です。出力品質だけでなく、入力情報、プロンプト、検索データ、ツール連携、人の承認まで含めて評価対象にすると、改善すべき場所と自動化してよい範囲が明確になります。
この記事では、マーケティングや営業支援などの業務で生成AIを使う前提で、「任せられる」を測る評価設計を7ステップで整理します。
生成AIの評価で見るべきものは「回答の良さ」だけではない
一般的なLLMベンチマークは、モデルの能力を比較する材料にはなります。しかし、自社業務で必要なのは、そのモデルが高得点かどうかではありません。自社の入力、ルール、担当者、顧客接点のなかで、期待した仕事を安定して完了できるかです。
たとえば「商談前の企業リサーチを要約するAI」を評価する場合、対象は生成文だけではありません。CRMにある情報が不足していないか、参照した情報は最新か、重要な変化を落としていないか、営業が短時間で使える形かまでを見ます。
評価は、次の3層に分けると設計しやすくなります。
- 業務品質：正確性、根拠との整合、網羅性、形式、読み手にとっての使いやすさ。
- 業務安全性：誤った断定、機密情報・個人情報の不適切な扱い、禁止表現、承認漏れなどの重大な失敗。
- 業務効果：レビュー時間、修正・再作業、処理件数、利用率、次工程の成果への寄与。
この順番が重要です。安全性に関わる失敗を平均点で相殺してはいけません。まず「出してはいけない出力」を排除する合格条件を置き、そのうえで品質と工数を比べます。NISTの生成AI向けリスク管理プロファイルも、利用文脈に応じてリスクを測定・追跡し、利用者からのフィードバックを評価に組み込む考え方を示しています。NIST AI RMF: Generative AI Profile (nist.gov)
生成AIの評価設計を進める7ステップ
1. 「AIに任せる業務単位」を1つに絞る
最初に「提案書作成をAI化する」のような大きすぎるテーマを避けます。評価できる大きさまで、仕事を分解してください。
- 失注理由の商談メモを、定めた分類で整理する
- 公開済みの導入事例から、指定業界向けの訴求仮説を抽出する
- 営業面談前に、企業ニュースとCRM情報を1ページに要約する
- 問い合わせ内容を分類し、回答案と担当部署を提示する
業務単位ごとに、入力、出力、出力を使う人、その人が次に下す判断、最終責任者を定義します。ここが曖昧だと、評価基準が「なんとなく便利」に寄り、改善の優先順位を決められません。
2. 失敗を「即不合格」と「品質差」に分ける
評価項目を増やす前に、失敗の重さを分けます。特に顧客や営業が見る出力では、致命的な失敗を品質スコアの一部にしないことが重要です。
| 評価層 | 主な確認項目 | 判定の考え方 |
|---|---|---|
| 即不合格の条件 | 根拠のない事実断定、禁止情報の出力、顧客名・数値の取り違え、必須承認の欠落 | 1件でも発生すれば公開・送信・自動実行を止める |
| 品質の条件 | 要点の網羅性、論理構成、文体、次の行動の明確さ、参照情報との整合 | ルーブリックで段階評価し、改善対象を特定する |
| 業務効果の条件 | レビュー時間、修正回数、差し戻し率、利用率、後工程での採用率 | 従来業務と比べ、導入する意味があるかを見る |
たとえば記事構成案の作成なら、「見出しがやや冗長」は品質差です。一方で、存在しない導入実績を提案している、根拠がない数値を入れている、といった問題は即不合格の条件になります。
3. 実際の仕事から評価セットを作る
評価セットとは、AIに同じ条件で繰り返し与え、比較に使う入力ケースの集合です。一般的な質問を集めるのではなく、実務で起きるばらつきを残したまま作成します。
過去の業務データを使える場合は、利用許諾、個人情報、機密情報の扱いを確認したうえで、必要最小限に加工します。その際、成功事例だけでなく、次のようなケースを意図的に含めてください。
- 情報が十分にそろった標準ケース
- 入力が短い、矛盾する、古いなど判断が難しいケース
- 人に確認を返すべきケース
- 出力してはいけない情報や表現が混ざるケース
- 業種、商材、担当者、情報源が異なるケース
重要なのは件数を先に決めることではなく、どの条件で失敗したかを切り分けられる構成にすることです。運用中に見つかった失敗は、原因とともに評価セットへ追加します。ただし、以前のケースを消してしまうと、修正したはずの問題が再発しても気づけません。
4. 正解集ではなく「判断基準」を書く
分類や抽出のように答えが明確なタスクでは、正解ラベルとの一致を測れます。一方、メール文案、提案骨子、要約のように複数の妥当な答えがある業務では、正解例だけで評価すると有効な別案まで落としてしまいます。
そこで、評価者が確認できるルーブリックを作ります。たとえば商談前リサーチの要約なら、次のように書けます。
- 入力にない事実を追加していないか
- 案件化の判断に必要な変化・課題・確認事項を分けているか
- 推測と確認済みの情報が区別されているか
- 営業担当者が追加調査なしで次の質問を決められるか
ルーブリックは「よい文章」「十分に具体的」といった曖昧な表現で終えません。誰が読んでも判断できる観察可能な条件に変換します。また、複数の評価者が同じケースを採点し、判断が割れた項目は、AIではなく基準側の曖昧さを疑うべきです。
5. 人・ルール・LLM評価者を使い分ける
評価をすべて人手で行うと遅くなり、すべてAIに任せると見落としが残ります。評価方法は、項目の性質で分けるのが実務的です。
- ルールベース：JSON形式、必須項目、禁止語、文字数、参照IDの有無など、機械的に判定できる条件。
- 人による評価：高リスクな主張、顧客への影響、事業文脈の妥当性、ブランド上の判断。
- LLMによる評価：多数の出力を同じルーブリックで一次判定し、比較・傾向分析を速くする用途。
LLMを評価者にする場合は、採点結果を真実と扱わないことが前提です。人が採点済みのケースで判定のずれを確認し、モデルや評価プロンプトを変えた際にも再確認します。候補を比較させる場合は表示順の影響も確認し、重要なケースは人のレビューを残します。LLM評価は人の判断との整合を高められる可能性がある一方、AI生成文を好むなどの偏りも研究で指摘されています。Liu et al. (2023), G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment (aclanthology.org)
6. 「何分減ったか」ではなく、再作業を含む純削減時間で比べる
AIの生成時間だけを測ると、効果を過大評価しやすくなります。下書きが速くても、確認が難しくなったり、差し戻しが増えたりすれば、総工数は減りません。
評価では、次の式で従来業務と比べます。
1件あたりの純削減時間 ＝ 従来の処理時間 −（AI操作時間 ＋ 人のレビュー時間 ＋ 修正・再作業の期待時間）
さらに、マーケティング業務では時間だけで終えず、後工程の利用状況を見ます。たとえば営業用リサーチなら営業が面談前に使った割合、コンテンツ案なら編集会議で採用された割合、問い合わせ分類なら適切な担当へ渡せた割合です。売上のように結果が遅れて出る指標だけに頼らず、まずは業務の完了品質に近い中間指標を置くと、改善サイクルが回りやすくなります。
7. 変更管理と再評価を運用に組み込む
生成AIの出力は、モデル変更だけで変わるわけではありません。プロンプト、参照するナレッジ、検索設定、連携するツール、承認ルールの変更でも挙動は変化します。したがって、評価対象は「現在のモデル」ではなく、現在の業務システムの版として管理します。
- 評価時点のモデル、プロンプト、ナレッジの版、ツール設定を記録する
- 変更前後で同じ評価セットを実行し、合格条件違反を最優先で比較する
- 平均点だけでなく、どの業種・入力条件・タスクで悪化したかを見る
- 重大な失敗が起きた場合の停止、有人確認への切り戻し、再開条件を決める
日本のAI事業者ガイドラインでも、AI利用者を含む事業者に対し、安全性、透明性、アカウンタビリティなどを踏まえた継続的な対応が求められています。評価を導入時だけの審査にせず、運用改善の仕組みにすることが重要です。経済産業省・総務省「AI事業者ガイドライン（第1.2版）」 (meti.go.jp)
評価結果から「どこを直すか」を判断する5つの原因コード
評価で不合格が出るたびにプロンプトを書き換えると、改善が属人的になります。失敗を発生箇所で記録すると、対策を誤りにくくなります。
- I：Input 入力情報が足りない、古い、矛盾している。
- R：Retrieval 必要な情報を取得できない、または不要な情報を拾う。
- G：Generation 指示を守れない、根拠から飛躍する、形式を崩す。
- H：Handoff 人への確認依頼が遅い、判断材料が不足している、責任者が曖昧。
- P：Process ツール実行、承認順、保存先、通知先など業務フローの設計に問題がある。
たとえば「商談メモの要約で重要な論点が抜ける」問題は、モデルの能力不足とは限りません。入力メモに情報がないならI、CRMや録画からの取得が弱いならR、重要論点の定義が指示されていないならG、営業が確認すべき項目が不明ならHです。
この分類を残すと、改善の対象がモデル選定、プロンプト、ナレッジ整備、フォーム設計、承認フローのどこにあるかを判断できます。AI活用を単発の文章生成で終えず、入力から人の判断、公開後の計測までつなぐ考え方は、AIワークフロー設計の解説もあわせて確認してください。
生成AIの評価でよくある失敗
平均スコアだけでリリースを決める
平均点が高くても、少数の重大な誤りが含まれることがあります。特に対外発信、顧客対応、営業判断に使う出力では、重大リスクの違反率と発生条件を別に確認します。
正解例を増やしすぎて、目的を見失う
想定回答を細かく作り込むほど、評価セットの維持は重くなります。正誤が明確な作業だけを完全一致に寄せ、複数の正解がある作業はルーブリック中心にするほうが、実務の変化に耐えやすくなります。
LLM評価者を導入して、人の確認をゼロにする
LLMによる採点は、評価件数を増やし、失敗傾向を見つける用途には有効です。しかし、高リスクな出力の最終承認を完全に置き換えるものではありません。誤情報への対策は、出力後の漠然とした目視確認ではなく、主張単位で根拠と承認を設計する必要があります。詳しくは生成AIハルシネーション対策の解説を参照してください。
評価セットを成功例だけで作る
標準的な入力だけでは、本番で困るケースを拾えません。情報不足、例外処理、禁止条件、古い資料など、「AIが自信を持って答えてはいけないケース」を含めることが、評価の価値を高めます。
まとめ：評価とは、AIの点数を付けることではなく業務の境界を決めること
生成AIの評価設計で最も重要なのは、良い回答を選ぶことだけではありません。どの入力条件ならAIに任せ、どの条件では人が確認し、何が起きたら止めるかを、業務ルールとして決めることです。
- モデル単体ではなく、入力・生成・人の承認を含む業務全体を評価する
- 重大な失敗は平均点に混ぜず、即不合格の条件として管理する
- 品質、レビュー工数、後工程の利用状況を同時に測る
- 失敗を原因コードで分類し、プロンプト以外の改善箇所を見つける
- 変更のたびに再評価し、評価セットを運用資産として育てる
まずは、影響範囲が限定され、従来の作業時間と成果物を比較できる業務を1つ選んでください。その業務の「即不合格条件」と「純削減時間」を定義するところから始めると、AI・業務効率化を導入施策ではなく、再現可能な改善活動に変えられます。
参考情報
- AI事業者ガイドライン（第1.2版）｜経済産業省・総務省
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile｜National Institute of Standards and Technology
- G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment｜Association for Computational Linguistics
