2026年10月8日に、NISTのAI 600-1生成AIプロファイルを再読しました。本文はconfabulationをもっともらしく提示される誤った内容として説明し、リスクを発生可能性と結果の重大さの組み合わせで捉え、既知の正解との照合を含む実際の文脈で複数の評価手段を使い、狭い逸話から能力を一般化せず、監視・訂正・停止を組み合わせるよう案内しています。この記事の100件・無検証20%・検証済み80件中5件という数値はNISTの測定値ではなく、工程の違いを説明する架空教材です。
AIの誤った回答が、社内の下書きで止まるのか、顧客への約束や取り消しにくい判断まで進むのか。同じ誤答でも、使い道によって対処の優先度は変わります。ただし、確認担当者を置いただけで安全になるわけではありません。
この記事は、AI導入を判断する責任者と業務担当者に向けて、誤りの起こりやすさ・起きた場合の影響・検証が働く条件を分ける手順を示します。回答の表現や編集工程はAIコンテンツ品質管理も参照してください。
30秒で要点
- モデルの正答率だけでも、業務フローだけでも、事業リスクは決まりません。利用条件と損害の大きさを併せて判断します。
- 無検証通過率は「確認工程を通らなかった割合」です。誤答率や損害発生確率とは別の指標です。
- まず一つの業務で、根拠を確認する人・止める条件・誤りを見つけた後の訂正先を決めます。
用語をそろえる
表が収まらない場合は、横にスクロールできます
| 用語 | この記事での意味 |
|---|---|
| ハルシネーション | 生成AIが、もっともらしく提示する誤った内容。引用先の捏造や入力との矛盾も確認対象 |
| 伝播 | 誤りが別の資料、判断、外部への通知へ引き継がれること |
| 検証 | 出典や原データと照合し、正否や適用条件を確かめること。文章を一読するだけとは区別 |
| 無検証通過率 | 定義した利用件数のうち、必要な検証を経ず利用した件数の割合 |
NISTの生成AIプロファイルは、誤った内容を確信的に出力する現象と、人がAIを過信する問題を扱っています。同資料のリスクの捉え方は、事象の起こりやすさと結果の重大さを組み合わせるものです。特定モデルの誤答率や、自社の損害額を与える資料ではありません。NIST AI 600-1
正答率を見る前に、どの誤りを困ると定義するか
正答率は必要な情報ですが、評価問題と実業務が違えば、その数値をそのまま持ち込めません。文章の自然さ、回答の正しさ、顧客への影響も別です。次の表を使い、実際に使う条件で確認します。
表が収まらない場合は、横にスクロールできます
| 確認する軸 | 問い | 記録例 |
|---|---|---|
| 発生条件 | 最新情報、数値、固有名詞、例外規定を扱うか | 更新日の古い料金表から回答した |
| 影響 | 間違ったまま使うと誰が困るか、取り消せるか | 社内メモか、顧客に確約する見積もりか |
| 接続先 | AIの回答を次の工程が事実として使うか | 要約を別のAIが企画判断の前提にした |
| 検証可能性 | 正しい原資料と照合できる人・時間があるか | 担当者は読むが、原資料を開けない |
| 復旧 | 利用後に誤りが分かったらどこを訂正するか | 顧客通知、関連資料、判断記録の更新先 |
「専門家が確認するから低リスク」と即断せず、専門家が確認に使える情報と、実際に見落とした事例も確かめます。外部へ直接送る工程は優先的に点検する候補ですが、社内用途でも採用・投資・安全に関わる判断なら影響は大きくなり得ます。
架空例：無検証20%は誤答20%ではない
次は計算のための架空例で、導入成果や実測データではありません。ある期間の「AI出力を業務に採用した判断」を1件と数え、重複を除いた100件を調べたとします。
表が収まらない場合は、横にスクロールできます
| 利用前の工程 | 件数 | 100件に対する割合 | まだ分からないこと |
|---|---|---|---|
| 定義した検証を実施 | 80件 | 80% | 検証で見逃した誤りの件数 |
| 検証を実施せず利用 | 20件 | 20% | そのうち誤っていた件数 |
| 合計 | 100件 | 100% | 全体の誤答率・損害発生確率 |
無検証通過率は 20 ÷ 100 × 100 = 20% です。検証済み80件のうち、5件の誤りを利用前に発見したと仮定すると、検証済み案件における発見割合は 5 ÷ 80 × 100 = 6.25% です。全100件を分母にした5%とは異なります。発見できなかった誤りが不明なため、どちらも「検知率」や真の誤答率とは呼べません。
無検証通過率を下げる施策と、検証の質を上げる施策を分けてください。全件に確認欄があっても、出典を開かずチェックを付けるだけなら、誤りを見つける工程として機能しているかは不明です。
「確認した」の条件を業務ごとに決める
実務上の点検案として、次の3種類を分けて残します。NISTも既知の正解との比較や複数の評価手段を示していますが、この表はそのままの規格ではなく、業務へ落とすための例です。評価の考え方
表が収まらない場合は、横にスクロールできます
| 対象 | 確認作業の例 | 確認できなければ |
|---|---|---|
| 出典付きの説明 | リンク先の実在、該当箇所、更新日、条件を読む | 根拠不明と表示し、断定して外部へ出さない |
| 数値・計算 | 原データ、分母、単位、計算を照合する | 数値を意思決定に使わず再確認する |
| 判断・提案 | 前提、代替案、不利な証拠、責任者を確認する | 人の判断に戻す、用途を限定する、保留する |
AIに別の言い方で聞いて回答が一致しても、それだけでは独立した裏付けになりません。元の出典が存在しても、AIの説明と出典の中身が一致するかは別に調べます。
まず一つの業務で試す4手順
- 対象を固定する。 業務、利用者、期間、利用1件の数え方、重大な誤りの定義を記録します。
- 通過経路を描く。 誰が生成し、誰が照合し、何に使うかを追い、無検証で進む箇所を探します。
- 実例で確かめる。 原資料に照らして正誤が判断できる案件を使い、誤答と見逃しを別に記録します。都合のよい例だけで評価しません。
- 停止と訂正を決める。 重大な誤りや根拠不明を誰へ上げるか、利用を止めるか、既に伝えた情報をどう訂正するかを定めます。
確認時間が足りない場合も「確認済み」にせず、利用範囲を狭める、根拠のある部分だけ採用する、人へ戻す、といった選択肢を記録します。AIを止めるラインと責任を合わせて決めると、担当者個人の注意だけに頼らず運用を組めます。
分かることと、残る不確実性
表が収まらない場合は、横にスクロールできます
| 現時点で確認できること | それだけでは言えないこと |
|---|---|
| 定義した案件での誤答と検証結果 | 別の業務・別モデルでも同じ性能になる |
| 無検証で利用した件数 | その全件が誤り、または検証済みなら安全 |
| 発見した誤りの件数と影響 | 未発見の誤りがない、将来の損害がゼロ |
最初に選ぶのは「最も高性能なモデル」だけではありません。自分たちが確認できる範囲と、誤りを利用しない境界を具体化し、その条件の下でモデルや工程を比較してください。業務の数字を整理する補助には無料ツールも使えますが、ツールの計算結果も入力条件と合わせて判断します。