第6章：AIの出力を評価・改善する
この章で作れる成果物
この章を読み終えると、次の成果物を作れる状態を目指します。
- CARE+評価シート: CAREに、Evidence（根拠）、Risk（リスク）、Approval（承認条件）を加え、AI出力の採否を判断するシート。
- 評価rubric / acceptance criteria: 成果物ごとの必須条件、品質条件、差し戻し条件をまとめた評価基準。
- 改善指示ログ: 初回出力、評価結果、修正指示、再評価結果、採否判断を残すログ。
- regression checklist / evaluation log: 改善後に、以前満たしていた条件を壊していないか確認するチェックリストと評価履歴。
第5章では、AIに依頼する前に、目的、文脈、出力形式、受け入れ基準を設計しました。本章では、返ってきた出力を「使えるか」「何を直せば使えるか」「誰が承認すべきか」まで判断します。AI出力は完成物ではなく、評価、検証、編集、承認を経て業務成果物になります。
本章とAI活用の標準業務フロー
本章は、AI活用の標準業務フロー（1枚） のうち、主に次の工程に対応します。
- 4. 出力仕様: 何を満たせば採用できるかを、評価しやすい形で定義する。
- 6. 生成: 初稿、比較案、反論、要確認事項を受け取る。
- 7. 評価: CARE+で、正確性、適切性、関連性、効果性、根拠、リスク、承認条件を点検する。
- 8. ファクトチェック: 一次情報、社内正本資料、複数ソース、時点、数値、固有名詞を確認する。
- 9. 編集・承認: 人間が最終版に編集し、承認者、確認日、残リスクを残す。
- 10. ログ化・再利用: task brief、指示、出力、評価結果、改善理由、廃止条件を資産化する。
評価は、生成後の後始末ではありません。評価基準を先に置き、評価結果を改善指示へ変換し、再評価してから承認する一連の品質管理です。
6.1 この章で扱う業務課題
AI出力は読みやすく整っていることがあります。しかし、読みやすさと業務利用の可否は別です。次のような問題が残ると、提案書、稟議メモ、顧客向け文面、意思決定ログとしては使えません。
- 根拠が示されていないのに、断定的に書かれている。
- 事実、解釈、仮説、推奨が混ざっている。
- 読み手、意思決定点、社内ルールに合っていない。
- 重要なリスクや反対意見が抜けている。
- 機密情報、個人情報、著作権、知財、社内ポリシーへの配慮が不足している。
- 改善指示が「もっと具体的に」のように曖昧で、再出力を評価できない。
- 一度よくなった箇所が、次の修正で壊れても気づけない。
- 誰が確認し、誰が承認したかが残っていない。
本章の目的は、AIを疑うことだけではありません。AI出力を安全に活用するために、評価、差し戻し、再評価、承認、ログ化の型を持つことです。
6.2 CAREからCARE+へ
6.2.1 CAREの役割
CAREは、AI出力を評価するときの本書独自の基本観点です。
| 観点 | 確認すること | 典型的な問い |
|---|---|---|
| Correctness | 事実、数値、固有名詞、時系列が正しいか | 根拠は確認済みか |
| Appropriateness | 読み手、目的、トーン、社内ルールに合っているか | この相手に出してよい表現か |
| Relevance | 意思決定点に関係する情報へ絞れているか | 依頼に答えているか |
| Effectiveness | 次の行動、判断、承認に使えるか | これで業務が前に進むか |
CAREは、初稿の品質を大きく外さないための有効な入口です。一方で、実務では「正しそう」「目的に合っていそう」だけでは足りません。根拠の確認、リスクの許容、承認責任まで含めて判断する必要があります。
6.2.2 CARE+で追加する3観点
本書では、実務利用の評価として、CAREに次の3観点を加えたCARE+を使います。
| 追加観点 | 確認すること | 出力に残す情報 |
|---|---|---|
| Evidence | 根拠、参照元、確認日、適用範囲が明示されているか | 出典候補、確認済み / 未確認、確認日 |
| Risk | 誤情報、情報漏えい、著作権、知財、誤承認、誤解のリスクを確認したか | リスク、影響、緩和策、保留条件 |
| Approval | 人間の編集者、承認者、承認条件、ログ化範囲が明確か | 承認者、承認日、採否判断、残課題 |
CARE+は、AI出力を採用するためのチェックリストではなく、採用してよい条件を明確にする判断表です。条件を満たさない場合は、差し戻し、不採用、保留を選びます。
6.2.3 採否判断の種類
評価結果は、単に「良い / 悪い」で終わらせません。次のように、次アクションへ接続します。
| 判断 | 使う状況 | 次アクション |
|---|---|---|
| 採用 | 受け入れ基準を満たし、残リスクが許容範囲 | 人間が最終編集し、承認ログを残す |
| 条件付き採用 | 一部の確認や表現修正を前提に使える | 条件、確認者、期限を明記する |
| 差し戻し | 構成、根拠、表現、リスク確認が不足 | 改善指示を出し、再評価する |
| 不採用 | 根拠不明、方向違い、リスク過大 | 使わない理由を記録し、別案に切り替える |
| 保留 | 正本資料や承認者確認が未了 | 追加確認の担当者と期限を決める |
重要なのは、判断理由を残すことです。同じ出力でも、社内メモなら条件付き採用、顧客向け文書なら差し戻し、法務判断なら保留になることがあります。
6.3 CARE+評価シートを作る
6.3.1 評価シートの基本項目
評価シートには、本文評価だけでなく、前提と承認情報を含めます。
【CARE+評価シート】
対象成果物:
用途 / 読み手:
意思決定点:
情報分類:
AIに渡した資料:
評価対象バージョン:
評価者:
評価日:
承認者:
最終判断: 採用 / 条件付き採用 / 差し戻し / 不採用 / 保留
前提情報がない評価は、後から再現できません。特に、どの資料をAIに渡したか、どの版の出力を評価したか、誰が評価したかを残します。
6.3.2 評価表のテンプレート
次の表を使うと、評価結果を改善指示へ変換しやすくなります。
| 観点 | 受け入れ基準 | 評価結果 | 根拠 / 確認方法 | 問題点 | 次アクション |
|---|---|---|---|---|---|
| Correctness | 数値、固有名詞、時系列が確認済み | OK / 要修正 | 一次情報、社内正本、複数ソース | 未確認の断定 | 出典確認、注記追加 |
| Appropriateness | 読み手、トーン、社内ルールに合う | OK / 要修正 | 読み手、用途、社内規程 | 顧客向けには強すぎる表現 | 表現を調整 |
| Relevance | 意思決定点に直結している | OK / 要修正 | task brief、論点 | 背景説明が多く結論が弱い | 結論先出しにする |
| Effectiveness | 次アクションが明確 | OK / 要修正 | 承認者、期限、担当 | 実行条件が不明 | 担当と期限を追記 |
| Evidence | 根拠、確認日、適用範囲が残る | OK / 要修正 | evidence matrix | 出典候補のみ | 確認済み / 未確認を分ける |
| Risk | 誤情報、漏えい、権利、誤解を確認済み | OK / 要修正 | risk review | 機密区分の記載なし | 情報分類を追記 |
| Approval | 承認者、条件、ログ化範囲が明確 | OK / 要修正 | 承認フロー | 誰が承認するか不明 | 承認者を明記 |
評価表は、すべてを詳細に書く必要はありません。社内メモなら簡易版で十分な場合があります。ただし、顧客向け文書、経営判断、法務・人事・財務に関わる成果物では、根拠、リスク、承認条件を省略しないでください。
6.3.3 例：顧客向け回答テンプレートを評価する
次のAI出力を、顧客向け回答テンプレートの初稿として評価します。
AI出力:
当社サービスでは、どのような問い合わせにも即日対応できます。
導入後はサポート負荷が大きく下がり、顧客満足度も向上します。
詳細はFAQをご確認ください。
CARE+で見ると、次の問題があります。
| 観点 | 評価 | 理由 |
|---|---|---|
| Correctness | 要修正 | 「どのような問い合わせにも即日対応」は保証条件が不明 |
| Appropriateness | 要修正 | 顧客向けには約束が強すぎる |
| Relevance | 要修正 | どのFAQ、どの問い合わせ範囲か不明 |
| Effectiveness | 要修正 | 顧客が次に何をすればよいか不足 |
| Evidence | 要修正 | FAQの版、確認日、根拠資料がない |
| Risk | 要修正 | SLA誤認、過大表示、サポート負荷低下の断定リスクがある |
| Approval | 要修正 | サポート責任者や法務確認の要否が不明 |
評価結果から、次の改善指示に変換します。
改善指示:
顧客向け回答テンプレートを修正してください。
修正条件:
- 「どのような問い合わせにも即日対応」のような保証表現は避ける。
- 対応範囲、受付時間、一次回答と解決の違いを分ける。
- FAQの版、確認日、参照箇所を根拠欄に残す。
- 顧客が次に確認すべきURL、問い合わせ先、必要情報を明記する。
- 未確認の効果は「期待されます」と書かず、要確認欄に移す。
- 公開前にサポート責任者と法務確認が必要であることを承認条件に入れる。
「もっと安全にして」ではなく、どの観点で何を直すかを指定します。
6.4 評価rubricと受け入れ基準
6.4.1 受け入れ基準を成果物ごとに置く
AI出力の評価は、成果物の種類で変わります。1枚サマリー、稟議メモ、議事録、顧客向け回答では、満たすべき条件が違います。
| 成果物 | 必須の受け入れ基準 |
|---|---|
| 経営向け1枚サマリー | 結論、判断点、根拠、選択肢、リスク、推奨アクションが1枚に収まる |
| 稟議メモ | 目的、費用、効果、代替案、リスク、承認条件、未確認事項が分かる |
| 議事録 / 意思決定ログ | 決定事項、未決事項、担当、期限、承認者、共有範囲が明確 |
| 営業ヒアリングメモ | 顧客課題、制約、予算、意思決定者、反論、次アクションが整理されている |
| リスクレビュー | リスク、影響、発生条件、緩和策、残リスク、承認判断が残っている |
第5章で出力仕様を作る段階から、これらの受け入れ基準を入れておくと、評価が主観に流れにくくなります。
6.4.2 rubricは「採点」ではなく「差し戻し条件」に使う
評価rubricは、点数を付けるためだけの表ではありません。実務では、差し戻し条件と承認条件を明確にするために使います。
| 水準 | 意味 | 判断 |
|---|---|---|
| 2 | 業務利用に必要な条件を満たす | 採用または条件付き採用 |
| 1 | 方向性は合うが、根拠、表現、構成の修正が必要 | 差し戻し |
| 0 | 目的違い、根拠不明、リスク過大 | 不採用または作り直し |
これは点数の絶対評価ではなく、チーム内のサンプル基準です。重要な成果物では、点数合計だけで採用せず、必須条件を1つずつ確認します。
6.4.3 経営向け1枚サマリーのrubric例
| 評価観点 | 2: 採用可能 | 1: 要修正 | 0: 不採用 |
|---|---|---|---|
| 結論 | 冒頭で判断案が明確 | 結論はあるが弱い | 結論がない |
| 根拠 | 主張ごとに根拠候補と確認状態がある | 一部の根拠が不足 | 根拠がほぼない |
| リスク | 主要リスクと緩和策がある | リスク列挙のみ | リスクがない |
| 読み手適合 | 経営判断に必要な粒度 | 詳細すぎる、または粗い | 読み手と合わない |
| 次アクション | 承認事項、担当、期限がある | 一部が不足 | 行動につながらない |
このrubricで「根拠が1、リスクが0」なら、文体が整っていても採用しません。評価rubricは、成果物の見た目よりも、意思決定に必要な条件を優先します。
6.5 根拠確認とリスク確認
6.5.1 事実と推奨を分けて確認する
AI出力を評価するときは、文章全体をまとめて見るのではなく、主張ごとに分類します。
| 分類 | 例 | 評価方法 |
|---|---|---|
| 事実 | 価格、日付、制度、社名、数値 | 一次情報や社内正本で確認する |
| 解釈 | 売上減少の背景、顧客反応の読み取り | 根拠と別解を確認する |
| 仮説 | 施策Aなら解約率が下がる可能性 | 検証方法と反証条件を置く |
| 推定 | おおむねこの範囲と見込む | 前提、計算方法、誤差を残す |
| 推奨 | 施策Bを優先すべき | 評価軸、代替案、リスクを確認する |
第3章で扱った分類は、CARE+評価の前処理です。分類しないまま評価すると、未確認の推定を事実として採用する危険があります。
6.5.2 ファクトチェックの優先順位を決める
すべての文を同じ深さで確認すると、実務では回りません。影響が大きい主張から確認します。
| 優先度 | 対象 | 確認方法 |
|---|---|---|
| 高 | 顧客、契約、費用、法務、人事、公開情報に影響する主張 | 一次情報、社内正本、承認者確認 |
| 中 | 社内判断の前提になる数値、比較、固有名詞 | 複数ソース、確認日、定義確認 |
| 低 | 一般的な説明、文章表現、構成案 | 常識確認、読み手確認 |
未確認の情報は、本文から削除するか、「要確認」として分けます。AIが出した出典候補も、実在性と該当箇所を人間が確認します。
6.5.3 リスクを採否判断に組み込む
リスクは、章末の注意書きではなく、採否判断の条件です。少なくとも次の観点を確認します。
| リスク | 確認すること | 典型的な対処 |
|---|---|---|
| 情報漏えい | 機密、個人情報、契約情報が含まれないか | 匿名化、削除、社内環境利用 |
| 誤情報 | 未確認の数値、固有名詞、制度を断定していないか | 根拠確認、注記、差し戻し |
| 著作権 / 知財 | 他者コンテンツや社内資料の扱いは適切か | 引用範囲確認、出典明記、法務確認 |
| prompt injection | 外部資料やWeb内容に不正な指示が混ざっていないか | 入力分離、権限制限、手動確認 |
| 誤承認 | AIの文章を承認済みと誤解しないか | 承認者、承認日、残課題を明記 |
| 読み手誤解 | 条件付きの主張が断定に見えないか | 条件、範囲、要確認を明記 |
詳細なポリシー設計は組織ごとに異なります。この章では、出力を採用する前に、リスクが許容範囲か、誰の承認が必要かを確認することに焦点を当てます。
6.6 改善指示と再評価
6.6.1 改善指示は評価結果から作る
改善指示は、評価表の問題点から逆算します。
改善指示の型:
1. 対象成果物と利用目的
2. 評価で見つかった問題点
3. 修正してほしい範囲
4. 参照すべき根拠、使ってはいけない情報
5. 維持してほしい良い点
6. 受け入れ基準と差し戻し条件
7. 出力形式
特に「維持してほしい良い点」を入れることが重要です。AIに修正を依頼すると、改善された箇所とは別の箇所が変わることがあります。
6.6.2 よい改善指示と悪い改善指示
| 悪い指示 | 問題 | よい指示 |
|---|---|---|
| もっと具体的に | どこを直すか不明 | 施策ごとに担当、期限、必要情報、承認者を表にしてください |
| リスクも入れて | リスクの種類が不明 | 情報漏えい、誤情報、著作権、顧客誤解の4観点で確認してください |
| 経営向けにして | 読み手の判断点が不明 | 取締役会で投資可否を判断するため、費用、効果、代替案、残リスクを1枚にしてください |
| 根拠を追加して | 根拠の基準が不明 | 公開資料、社内正本、確認日を分け、未確認情報は要確認欄へ移してください |
改善指示は、AIに「よくする」作業を任せるものではありません。人間が評価した問題を、再出力できる作業単位に変換するものです。
6.6.3 再評価の進め方
改善後は、初回と同じ基準で再評価します。
- 修正指示で指定した箇所が直ったか確認する。
- 受け入れ基準を満たしたか確認する。
- 根拠、リスク、承認条件が追加されたか確認する。
- 以前満たしていた条件が壊れていないか確認する。
- 採用、条件付き採用、差し戻し、不採用、保留を判断する。
改善は、AIとの往復回数を増やすことではありません。判断に必要な条件を満たすまで、評価と修正を管理することです。
6.7 regression checklistとevaluation log
6.7.1 regressionを確認する理由
AI出力の改善では、ある問題を直す過程で別の品質が下がることがあります。
- 文章を短くした結果、根拠や条件が消える。
- リスクを追加した結果、結論が曖昧になる。
- 顧客向けに柔らかくした結果、重要な注意事項が弱くなる。
- 表を整えた結果、未確認情報のラベルが消える。
- 最新情報を足した結果、古い前提と矛盾する。
そのため、修正後には regression checklist で、前の版で満たしていた条件が維持されているか確認します。
6.7.2 regression checklistの例
【regression checklist】
□ task brief の目的と読み手からずれていない
□ output schema の見出し、表、根拠欄、要確認欄が残っている
□ 受け入れ基準で必須にした項目が消えていない
□ 確認済み / 未確認 / 推定 / 推奨のラベルが維持されている
□ 機密情報、個人情報、契約情報が追加されていない
□ 参照元、確認日、適用範囲が残っている
□ リスク、承認条件、残課題が弱まっていない
□ 前回の採用条件や差し戻し条件と矛盾していない
□ 読み手に対して過大な約束や断定が追加されていない
チェックリストは、毎回すべてを詳細に確認するためではなく、壊してはいけない条件を明示するために使います。
6.7.3 evaluation logのテンプレート
評価ログは、AI活用を監査可能にし、再利用可能にします。
| 項目 | 記録内容 |
|---|---|
| task brief ID | 対象タスクや案件の識別子 |
| 入力情報の分類 | 公開情報、社内限定、機密、個人情報の区分 |
| 指示バージョン | どの指示を使ったか |
| 出力バージョン | 初稿、修正版、最終版の区別 |
| 評価結果 | CARE+各観点のOK / 要修正 |
| 改善指示 | 何を、なぜ、どう直したか |
| regression確認 | 維持すべき条件が壊れていないか |
| 採否判断 | 採用、条件付き採用、差し戻し、不採用、保留 |
| 承認情報 | 承認者、承認日、残課題 |
| 再利用条件 | 適用範囲、更新条件、廃止条件 |
ログを残す目的は、責任追及ではありません。何を根拠に使ったのか、次回どこから改善すべきかを分かるようにすることです。
6.8 よくある失敗
6.8.1 文体だけを評価する
読みやすい文章でも、根拠や承認条件がなければ業務利用できません。文体の調整は最後に行い、先に事実、論理、根拠、リスクを確認します。
6.8.2 AIに自己承認させる
AIに「この出力は採用してよいですか」と聞くことは、レビュー材料としては使えます。しかし、採用可否、承認、公開判断は人間が行います。
6.8.3 未確認情報を自然な表現で残す
「一般的に」「多くの場合」「効果が期待されます」のような表現は、根拠がなくても自然に見えます。未確認情報は、本文に溶け込ませず、要確認欄へ移します。
6.8.4 rubricの点数だけで判断する
点数が高くても、必須条件が欠けていれば採用しません。機密情報の混入、未確認の法務判断、顧客への過大な約束は、総合点ではなく個別ゲートで止めます。
6.8.5 ログを残さず再利用する
よい出力やよい指示ができても、適用範囲、前提、廃止条件を残さなければ、別の案件で誤用されます。再利用する場合は、評価ログとセットで資産化します。
6.9 人間が最終判断すべき点
AIに評価案や改善案を出させても、最終判断は人間が行います。特に次の点は、人間が確認します。
- 受け入れ基準は、実際の意思決定点に合っているか。
- 事実、解釈、仮説、推定、推奨が分かれているか。
- 根拠の出所、確認日、適用範囲は十分か。
- 未確認情報を本文に残してよいか、要確認欄へ移すべきか。
- 情報漏えい、著作権、知財、誤承認、読み手誤解のリスクは許容できるか。
- 顧客、経営、人事、法務、財務など、専門部門の承認が必要か。
- 改善後に、以前満たしていた条件が壊れていないか。
- 出力、評価、改善指示、採否判断をどこまでログ化するか。
- 指示やrubricを再利用してよい条件、更新条件、廃止条件は何か。
章末演習
演習6-1：CARE+でAI出力を評価する
次のAI出力を、CARE+で評価してください。採用、条件付き採用、差し戻し、不採用、保留のどれにするかを判断し、理由を書いてください。
日本企業のテレワーク導入率は非常に高く、ほとんどの企業が恒常的に利用しています。
そのため、当社でも全社フルリモートへ即時移行すべきです。
コスト削減と従業員満足度向上が期待できます。
演習6-2：経営向け1枚サマリーのrubricを作る
「新規SaaS導入の投資判断」をテーマに、経営向け1枚サマリーの評価rubricを作ってください。必須条件、差し戻し条件、承認条件を含めてください。
演習6-3：改善指示ログを作る
AIが作成した提案骨子に、根拠不足、リスク不足、担当者不明の問題がありました。改善指示ログとして、問題点、修正指示、再評価基準を記録してください。
演習6-4：regression checklistを作る
顧客向け回答テンプレートを短く修正したところ、根拠欄と注意書きが消えました。次回の修正で同じ問題を防ぐ regression checklist を作ってください。
演習6-5：採否判断メモを書く
AI出力を条件付き採用する前提で、承認者、確認日、残課題、再利用条件を含む採否判断メモを書いてください。
理解度チェック
□ CAREを、Evidence、Risk、Approvalを含むCARE+として説明できる □ 成果物ごとに受け入れ基準と差し戻し条件を設計できる □ AI出力の事実、解釈、仮説、推定、推奨を分けて評価できる □ 評価結果から、具体的な改善指示を作れる □ 改善後に regression checklist で品質低下を確認できる □ evaluation log に、評価、改善、採否、承認、再利用条件を残せる □ AIにレビュー材料を作らせても、採否と承認は人間が行うと説明できる
章末の要点
- AI出力は、評価、検証、編集、承認を経て業務成果物になります。
- CAREは有効な入口ですが、実務ではEvidence、Risk、Approvalを加えたCARE+で判断します。
- 評価rubricは、点数を付けるためだけでなく、差し戻し条件と承認条件を明確にするために使います。
- 未確認情報は自然な文章に混ぜず、要確認欄へ分けます。
- 改善指示は、評価で見つかった問題を、再出力できる作業単位へ変換します。
- regression checklist と evaluation log を残すと、品質低下の防止、承認、再利用がしやすくなります。
- 人間は、採否判断、承認、残リスク、再利用条件を最終判断します。
次章への橋渡し
第6章では、AI出力をCARE+で評価し、改善指示、regression確認、評価ログへつなげる方法を扱いました。次の第7章では、評価で要確認となった情報を、批判的思考とメディアリテラシーの観点で検証する方法へ進みます。
- 前章: 第5章：AIへの指示（プロンプト）設計
- 次章: 第7章：批判的思考とメディアリテラシー
- リライト方針: 2026年版リライト契約と分割計画