公開 2026.10.09

生成AIの正確性課題とは？企業文書の誤情報を防ぐ評価・承認・改善フロー

AI評価クラウド

そのAI、精度やリスクを正しく計測できていますか？

ハルシネーション検知や満足度計測など、AI品質の可視化をご支援します。

生成AIを使った提案書、社内報告、FAQ、議事録、調査メモでは、文章が自然であることと、内容が業務で使えるほど正確であることは別です。もっともらしい誤情報、存在しない出典、原典とずれた要約、必須項目の抜けは、公開・意思決定・顧客対応の直前まで見逃されることがあります。

結論からいうと、企業での対策は「AIに正しく答えさせる」ことだけでは不十分です。何を確認対象にするか、どの原典を正とするか、誰がどの条件で承認するか、失敗をどう記録して次の評価へ戻すかを業務フローとして決める必要があります。

NISTは、生成AIが誤った内容を自信ありげに出す現象を「confabulation」と整理し、一般にハルシネーションとも呼ばれると説明しています。誤った出力を利用者が信じて行動・拡散することがリスクになるため、重要な意思決定に組み込む場合は特に監視が必要です。NIST AI 600-1

本記事の評価表、判定基準、役割分担、テンプレートは、特記がない限りMojiによる実務上の提案です。業界規制、契約、個人情報、法務判断が関わる業務では、担当部門や専門家による確認を追加してください。

最初に決めること：正確性を一つの数字にしない

「正確性95%」だけでは、どの失敗を許容し、どの失敗で利用停止するのかを判断できません。企業文書では少なくとも次の4軸に分けます。

評価軸	確認する問い	主な確認方法	失敗例
事実性	記述は原典と矛盾していないか	数値・固有名詞・日付を原典と照合	古い料金、誤った制度名、架空の実績
根拠一致	引用・リンク先は、その主張を本当に支えているか	主張と原典の該当箇所を対にして確認	出典は実在するが、別の主張を述べている
完全性	必要な条件・例外・前提が抜けていないか	要件チェックリストとの照合	対象外条件、例外規定、必要な添付の漏れ
形式遵守	指定の構成・表記・トーン・権限を守っているか	テンプレート・ルールとの照合	未承認の対外表現、必須の注意書き漏れ

この4軸の重みは一律ではありません。たとえば社内のアイデアメモなら形式や完全性を中心に見られる場合がありますが、顧客向け提案書、契約関連の説明、規制対象の文書では、事実性と根拠一致により厳しい基準が必要です。モデル、入力資料の品質、評価指標、許容誤差、文書の影響範囲によって結論は変わります。

ハルシネーションそのものの仕組みや抑制方法は、ハルシネーションとは？防止方法や費用についても参照してください。本記事では、生成された企業文書を公開・利用するまでの検証と承認の設計に絞ります。

なぜ「AIに出典を付けさせる」だけでは足りないのか

出典リンクがあることは、正しさの証明ではありません。リンク先が古い、主張とリンク先の内容が一致しない、検索結果の断片だけを基にしている、そもそも引用表示が生成されたものだった、といった失敗があり得ます。

OWASPは、LLMがもっともらしく見える虚偽または誤解を招く情報を出すことを、アプリケーションにとっての主要なリスクの一つとして挙げています。対策として、人の監督とファクトチェック、重要な出力の自動検証、利用者への限界の周知などを示しています。OWASP Gen AI Security Project: LLM09:2025 Misinformation

したがって、確認すべき単位は「文章全体」ではなく、検証可能な主張です。特に次の記述は、文章レビューとは分けて原典照合する運用をおすすめします。

数値、日付、料金、契約条件、仕様、制度・規制の要件
顧客名、導入実績、受賞歴、比較優位、性能値
因果関係や断定表現（「必ず」「唯一」「最も」など）
外部サイト、論文、規程、社内文書に基づくと示す主張
意思決定、対外公開、金銭・契約・権限変更につながる提案

企業文書向け：正確性を守る6段階フロー

以下は、生成AIに資料の下書き・要約・レビューを任せる際の、Mojiによる運用提案です。最初から全社共通の厳格な仕組みにせず、まず一つの文書種別で試行し、失敗記録を基に調整します。

1. 文書を影響度で分類する

まず、文書ごとに「誤りが外部へ与える影響」と「修正のしやすさ」を見ます。分類の目的は、AIの利用可否を単純に禁止・許可することではなく、必要な確認の深さを変えることです。

区分	例	AIの役割	公開・利用前の扱い
低影響	社内ブレスト、構成案、表現案	下書き・言い換え	作成者が内容確認
中影響	会議要約、社内FAQ、業務手順の初稿	要約・抽出・草案作成	業務担当者が重要主張と必須項目を確認
高影響	顧客向け提案、対外発信、経営判断資料	下書き・根拠候補の整理まで	原典照合と承認者レビューを必須化
要個別判断	法務・医療・人事評価・金融判断など	補助に限定、または利用しない	部門ルールと専門家確認に従う

業務で何を入力し、何を出力に使い、誰が承認するかというルール設計は、生成AIの社内ルール設計｜禁止事項だけにしない許可範囲・権限・承認・人間確認の決め方で詳しく扱っています。

2. 正とする原典と更新責任者を決める

AIに渡す資料が古い、矛盾している、版が混在している場合、出力だけをレビューしても原因を取り除けません。文書種別ごとに、正とする情報源を決めます。

一次原典：契約書、承認済み規程、製品仕様、公式の料金表、正式な議事録
補助資料：社内解説、過去の提案書、FAQ、研修資料
参照不可または要注意：更新者不明の資料、期限切れ資料、ドラフト、個人のメモ、出典不明のWeb情報

原典には、文書名、版・更新日、管理部門、利用可能な用途、次回見直し日を付けます。RAGを使う場合も、検索で見つかった資料をそのまま正解とみなさず、原典性・更新日・閲覧権限を管理してください。RAGのデータ整備と回答設計の基本は、RAG（検索拡張生成）とは？向く業務・他方式との違い・導入から評価までの実践ガイドを参照できます。

3. AIの出力を「主張」と「根拠」に分けて保存する

レビューを速くするには、完成文だけを渡さないことが重要です。AIへの依頼時に、本文とは別に次の情報を出力させます。

主張ID
主張の本文
根拠文書名・版・該当箇所
原典から直接確認できるか、推論を含むか
不明点と追加確認が必要な事項

ただし、この一覧自体もAI出力です。承認者は、重要主張について原典を開き、主張ID単位で「一致・条件付き一致・不一致・確認不能」を記録します。AIが示した根拠ではなく、人が確認した原典を承認の根拠にします。

4. 失敗を検出できる評価セットを作る

評価は、良い出力例を眺めるだけでは足りません。実際に起きた間違い、または起こしてはいけない失敗を含めたテストケースを用意します。OpenAIは、生成AIの出力にはばらつきがあるため、評価を構造化されたテストとして扱い、精度・性能・信頼性を測る必要があると説明しています。OpenAI Developers: Evaluation best practices

最小構成は、文書種別ごとに「入力」「期待する要件」「正とする根拠」「失敗ラベル」「合否」を持つケースです。RAGを使う場合は、最終回答だけでなく、正しい根拠が検索候補に入ったか、LLMに渡る文脈に残ったか、回答で正しく使われたかを分けて確認します。評価データセットの作り方は、RAG評価データセットの作り方｜設計・作成・品質確認・更新を実務手順で解説も参考にしてください。

5. 承認を「最終レビュー」ではなく、影響の直前に置く

人の確認は、必ずしも全段落を二重入力することではありません。影響の大きい判断点に、確認者と確認内容を固定します。

工程	AIに任せられる作業例	人が確認する条件
情報整理	議事録の要約、論点抽出、表の草案	重要な数値・決定事項・担当者・期限
資料作成	構成案、初稿、表現調整	対外主張、比較表、根拠リンク、必須記載
提案・公開	公開用原稿の下書き	承認済み原典との整合、公開権限、最終版
外部操作	操作案、入力候補	送信、登録、発注、権限変更などの実行前

AIにどの操作まで委任し、どこで人が承認し、どの条件で停止するかは、文章の正確性だけでなく運用リスク全体に関わります。AIエージェントはどこまで任せるべきか｜委任範囲・人の承認・停止条件を設計する実務ガイドも併せて確認してください。

6. 事故・差し戻しを評価セットへ戻す

公開前に見つかった誤り、顧客からの指摘、検索漏れ、承認漏れは、個人の注意不足として終わらせず、再発確認できるケースへ変換します。NIST AI RMFは、AIリスク管理をGOVERN、MAP、MEASURE、MANAGEの4機能で整理し、ガバナンスを他の機能全体に横断させる考え方を示しています。測定では、導入前と運用中のテスト、結果の文書化、独立レビューを含む評価が重要とされています。NIST AI RMF 1.0

具体的には、週次または月次で誤りを集計し、「入力資料」「検索・参照」「生成」「人の確認」「承認フロー」のどこで最初に防げたかを記録します。モデル変更、プロンプト変更、知識ベース更新、承認ルール変更の前後には、同じ評価セットで比較します。

評価指標：正確性だけでなく、見逃しを測る

次の指標は、企業文書の正確性を評価する一般的な設計上の目安です。採用する値や許容誤差は、文書の用途、モデル、入力品質、評価件数、失敗の影響によって調整してください。

指標	計算・確認の考え方	見るべき場面
重要主張の根拠一致率	原典と一致した重要主張 ÷ 確認した重要主張	対外資料・意思決定資料
必須項目充足率	記載できた必須項目 ÷ 全必須項目	定型レポート・提案書・手順書
誤情報の見逃し率	レビューで通過し、後から誤りと判明した件数 ÷ 確認対象件数	承認工程の有効性確認
根拠確認不能率	原典にたどれない主張数 ÷ 重要主張数	調査資料・RAG回答
差し戻し率	承認前に大幅修正となった文書数 ÷ 提出文書数	入力・プロンプト・テンプレート改善
重大インシデント数	外部影響、訂正、顧客対応などを要した件数	利用範囲の継続可否判断

自動採点やLLM-as-a-Judgeは、形式違反、必須項目漏れ、根拠リンクの有無などを一次判定する補助になり得ます。しかし、評価器も誤る可能性があるため、高影響の主張では原典確認や専門家レビューを置き換えません。OpenAIも、LLMを評価器として使える場面がある一方、領域専門家が評価器の精度を定期監査し、システムログを直接確認する必要があると説明しています。OpenAI: How evals drive the next chapter in AI for businesses

AI評価全般の指標の選び方は、AIの評価とは？評価指標や評価方法、その費用についても参照してください。

そのまま使える正確性レビューシート

以下はMojiによる提案テンプレートです。スプレッドシート、チケット、文書管理ツールのいずれでも運用できます。

項目	記入内容
文書ID・版	対象文書を一意に識別する番号と版
用途・影響度	社内下書き／対外資料／意思決定資料など
AIの担当範囲	要約、草案、検索、表作成、レビュー補助など
重要主張ID	確認が必要な数値・固有名詞・断定・推奨を分けて登録
原典	文書名、版、更新日、該当ページ・節・URL
照合結果	一致／条件付き一致／不一致／確認不能
修正内容	修正、削除、保留、追加確認の内容
確認者・承認者	確認した担当者と公開・利用を承認した担当者
再発防止	評価ケース追加、原典更新、プロンプト修正、ルール変更など