「発注は未承認」が「発注する」に変わる。AI要約の品質はどう評価する？

たとえば、試作の議事録要約を数件読むと、文章は自然で、十分使えそうに見えます。ところが「発注はまだ承認されていない」が「発注する」に変わっていたら、読みやすさだけでは採用を決められません。

まず議事録要約だけを試すなら、一つの議事録と、そこから作った要約を並べます。決定事項、担当、期限、未承認の条件を原文と照合し、違っていた箇所を記録してください。担当者が読んで直す下書きの試用から始められます。外部への送信や記録の更新まで任せる段階では、権限と実際の処理結果も調べます。

以下は評価基準の記入例です（想定例）。合格条件は対象業務に合わせて調整します。

二つの要約は、読みやすくても同じ評価にならない

S02の原文は「10月1日開始は案」「9月25日に実施可否を決める予定」「金額の上限30万円、発注未承認」「担当未定」です。許容例は「10月1日開始を提案しており、9月25日に実施可否を決める予定。金額の上限は30万円だが発注は未承認で、担当者も未定」。文言が違っても、この情報が保たれれば正解にできます。

これを「試験導入は10月1日に開始する。金額は30万円で、担当者は営業部に決まった」とまとめたらどうでしょうか。短くても、開始案を確定にし、上限を金額に変え、担当まで作っています。採点するなら、文章の流暢さより先に、この三つの変化を拾います。

会議の引継ぎ要約を採点する四つの観点（説明用の基準）

観点	2点	1点	0点
原文への忠実性	事実・否定・条件に矛盾や付け足しがない	意味は変わらないが、一部の表記が曖昧	原文と矛盾する／事実を作る
重要事項の充足	ケースで指定した必須事項がそろう	補助的な事項だけが欠ける	担当・期限・承認など必須事項が欠ける
不確実性の保持	未定・提案・条件付きの状態を保つ	未確定の示し方が弱いが、確定とは書かない	未定や提案を確定事項に変える
形式・読みやすさ	3文以内で関係が明確	形式違反はあるが意味を読み取れる	意味や関係を読み取れない

説明用の合格条件は、合計7点以上／8点満点、忠実性・重要事項・不確実性が各2点、重大失敗なし、とします。重要事項はケースごとに事前指定します。単なる短縮率や文章の似ている度合いで、承認条件の欠落を相殺しないためです。

許容例は4観点とも2点です。断定した例は、忠実性・重要事項・不確実性が0点。読みやすさが2点でも不合格です。

機能ごとに「正しい」の意味を決める

最初に「誰が、何のために、出力をどこまで使うか」を一文にします。担当者が読んで直す要約の下書きと、外部システムを書き換える実行機能では、同じ誤りでも影響が違います。機能を組み合わせる場合は、各工程の結果に加え、最後の引き継ぎや保存状態までを評価対象にします。

OpenAIの「Evaluation best practices」は、目的・データ・指標を定めて比較し、継続して評価する手順を示しています。以下の4機能への分け方は、その原則を業務の判断に置き換えた本記事の提案です（出典：OpenAI「Evaluation best practices」）。

表1　4機能の正解と重要な失敗（説明例）

用途	正解・許容回答	重要な失敗
会議の引継ぎ要約	原文の事実・否定・条件を保ち、決定事項・担当・期限を落とさない。言い換えは許容する	未決定を決定済みにする。担当・期限・承認条件を落とす、または作る
分類	定義したラベルを一つ返す。障害と変更が混在するときは障害を優先。不明なら確認必要	業務停止を伴う障害を変更依頼へ回す。情報不足を無理に確定する
回答	適用日・版を合わせ、答えと根拠箇所が対応する。資料にない事項は保留して問い合わせ先を示す	資料にない金額や条件を断言する。古い規程を現行として使う
実行	許可された対象だけが指定状態になる。余計な送信や更新がなく、再送でも論理更新は一度だけ	権限外の更新、承認回避、二重更新、未完了なのに完了と報告する

要約の必須項目は使い道で変わります。商品レビューなら、主な評価理由と賛否の偏りを原文と比べます。論文の概要なら、目的・方法・結果・限界が残っているかを確かめます。会議用の担当・期限を、すべての要約に要求する必要はありません。

例えば、回答の根拠が正しくても、その後の登録先が違えば実行は不合格です。答えがない質問に対しては、回答を保留することが正解になる場合もあります。入力に応じた正解を先に決めておきます。

通常例だけでない評価セットを作る

1ケースには、入力、前提条件、正解・許容回答、重要な失敗、採点方法を記録します。資料を使うなら版と適用日、操作するなら利用者の権限と実行前の状態も必要です。答えだけを保存すると、後から何を正解としたのか分からなくなります。

用意するのは通常例、境界・例外、不明・答えなし、権限外です。12ケースの出発点を表2に示します。全文の入力と期待結果は、判断表と記入例（PDF）と評価設計テンプレート（Excel）の「合成12ケース」に収録しています。

評価設計テンプレート（Excel）に自社の条件を記入できます。判断表と記入例（PDF）は、入力と期待結果を照合するときに使ってください。

表2　評価を始めるための12ケース

用途	通常の1ケース	条件を変える2ケース
要約	S01：担当・期限の引き継ぎ	S02：未承認と開始案／S03：日付・責任者が不明
分類	C01：単一の障害報告	C02：障害と変更依頼の混在／C03：文脈不足
回答	Q01：事前承認の条件	Q02：資料に答えなし／Q03：規程の版・適用日
実行	A01：自分の下書きを更新	A02：他人のタスクへの権限外操作／A03：応答消失後の再送

調整用と判定用を分ける

指示を直すために見るケースと、直した結果を判断するケースは分けます。この素材では各機能の通常例を調整用、残りを判定用の設計例としました。ただし、公開された12件は見本です。これらに合わせて調整した後で同じ12件を解いても、未知の入力で試したことにはなりません。

自社で使うときは、同じ会議や依頼の言い換えを両方へ分けず、原文・案件の単位で分離します。判定用の結果を見て修正したケースは回帰テストに残し、別の未使用データで最後に判定します。実データを使えない段階では架空例で基準を整えます。人が直す下書きとして試す場合は、その用途の代表例と間違えると困る例から始めます。利用者を広げたり外部送信・自動更新を任せたりする前には、担当部門と利用範囲を決め、必要な例外や権限のテストを追加します。

「何件で十分か」は、この12件からは決められない

NISTの生成AIプロファイルは、狭い・非体系的な評価から性能を一般化しないよう求めています。この12件は、見つけたい失敗を具体化するための見本です。本番の誤り率を求める場合は、実際の入力の種類と比率を踏まえて評価します（出典：NIST「AI 600-1」（PDF）、MS-2.5-001）。

追加件数は、対象業務の種類、入力のばらつき、失敗の影響、どの程度の見逃しを許すかで決めます。通常の比率を確かめる集まりと、まれな重大失敗を狙う集まりは別に集計します。難しい例を増やした評価セットの合格率を、そのまま本番の成功率とは呼びません。

採点方法を、見つけたい失敗に合わせる

採点方法は、確かめたい内容に応じて組み合わせます。ラベルや日付は一致判定、数値は単位・丸め方・許容差を決めた計算、自由文は原文との照合、操作は状態差分で判定します。AIによる採点は、自由文を整理する補助として使います。

分類・回答・実行の採点と、AI採点を使う場合の注意

分類・回答・実行は別の証拠を見る

分類は正解ラベルとの一致を見て、ラベル別にどこへ誤って振り分けたかを残します。例えば「障害」の再現率は、実際に障害のケースのうち障害と判定できた割合、適合率は、障害と判定したケースのうち正解も障害だった割合です。分母が0なら算出不能とします。全体の一致率だけでは、少数の重要ラベルの見逃しが埋もれます。

回答は、主張が資料のどの部分で裏付けられるかを調べます。引用が存在するだけでは合格にしません。NISTも出力の出典・引用の検証を挙げています（出典：NIST「AI 600-1」（PDF）、MS-2.5-003）。

実行は、成功らしい返答ではなく、許可された変更だけが保存された証拠で判断します。A03では通信が再送されても、同じ操作IDの論理更新は一度だけが期待結果です。権限はAIに注意書きを渡すだけでなく、実行側で拒否できることを直接テストします。画面上の成功表示と保存状態が違う場合も失敗です。

AI採点は、人とのズレを確かめてから使う

OpenAIは、自動採点を人の評価で調整することや、AI採点に回答順・長さの偏りがあることを説明しています（出典：OpenAI「Evaluation best practices」）。

採点には入力・根拠・観点別の採点基準を渡し、点数だけでなく、根拠箇所と短い理由を出させます。まず同じ出力を業務担当者も独立に採点し、合否が分かれたもの、とくに人が不合格としたのにAIが通したものを見直します。人同士で割れる場合は基準を直します。生成したAIの自己採点や、別モデルに替えただけの採点を品質保証にはしません。

合格・保留・使わない条件を先に書く

各ケースの判定と、機能を公開する判断は分けます。まだ試していないケースや、正解が決まっていないケースは「保留」にします。また、正しく「回答を保留した」Q02はケースとして合格になり得ます。この二つの保留を、同じ欄で扱わないようにします。

本記事の判定例では、重大失敗が1件でも見つかれば対象範囲の公開を止め、原因を直して評価し直します。重大失敗が観測されなかった場合も、未評価の条件まで安全とは言えません。通常例の基準、重大失敗の検証、未評価範囲、人へ戻す手順をそろえ、業務責任者が利用範囲を決めます。

採点の前提が変われば結論も変わります。分類を複数のラベルで答える方法へ変えるなら、C02にも「障害」に加えて該当するラベルを設定します。要約を速報メモから正式な承認引き継ぎへ使い回すなら、必須事項と人が見る条件を定め直します。改善後の点数が高く見えても、採点規則を変えた場合は以前の点数と単純比較しません。

対応しない例として、この12件だけで採用・融資など人の権利や機会を左右する判断を自動化することはできません。対象者への影響、属性・利用言語などの集団別の誤り、説明・見直しの方法を別途設計し、業務責任者・専門担当者から要件を得ます。

NISTは、集団や言語による性能差と、人がAIを過信するリスクを整理しています。人が画面を見るだけで対策済みとはせず、訂正・差し戻し・手作業への切替ができるかを試します（出典：NIST「AI 600-1」（PDF）、2.6・2.7）。

評価担当者向け：変更後に評価し直す範囲を選ぶ

OpenAIの評価手順には、変更に応じた継続評価が含まれます。ここでは一律に全件を回すのではなく、変更との対応を記録して、評価し直す範囲を決める方法を提案します（出典：OpenAI「Evaluation best practices」）。

表3　変更内容から評価し直す対象を選ぶ例

変更	評価し直す対象
共有モデル・共通指示	利用する全機能の代表例と重要な失敗。局所変更と決めつけない
要約の指示・文数制約	S01〜S03。必須事項と未確定情報が残るか
分類規則・ラベル	C01〜C03と、その分類結果を受ける後続処理
回答資料・適用日	Q01〜Q03。正解の版、答えなし、引用の対応
ツール・認可・再試行	A01〜A03。状態差分、権限外、二重反映、完了報告
採点AI・観点別の採点基準	人が採点した固定出力で、合否のズレを見直す

変更の影響を追えない場合は範囲を広げます。権限外操作や二重反映などの重大失敗は、関連するリリースで必ず評価対象に残します。モデル・指示・資料・ツール・採点基準・評価セットの版と実行日を記録し、同条件の出力を比較します。出力の揺れを見るための反復実行は別のケース数に数えず、実行回数も残します。

付属票を使う場合は、冒頭で選んだ一つの機能について「正解・許容回答」「重要な失敗」「使わない条件」を書き込んでください。許容範囲を決めてから評価すれば、利用できる範囲と、人へ戻す条件を具体的に決められます。

人や企画を評価する用途では、全体の正解率に加え、特定の条件へ誤りが偏っていないかを調べます（AIの評価を採用する前に｜偏りと人の見直し）。

関連記事・具体的な導入の検討

検索から回答を作るRAGを使う場合は、検索・回答・引用・権限を切り分ける評価へ進みます。RAGの評価方法｜資料どおりでも足りない答えを探すでは、その工程別の評価を説明しています。本記事の回答例は資料を直接与えるため、検索性能は別に評価します。

評価票に任せる仕事と人が見る範囲を書けたら、生成AIの導入・組み込み支援で必要な画面や手順を相談できます。

参考出典

• OpenAI「Evaluation best practices」：評価手順、採点方法、人とのズレの確認。2026年9月15日確認
• NIST「生成AIリスク管理プロファイル」AI 600-1、2024年7月：2.2、2.6、2.7、MEASURE 2.5（本文31ページ、PDF35ページ目）