🎥 YouTubeでも公開しています
Unknownを合格扱いしない検証設計｜AIの信頼性を「見かけの一致率」でごまかさない
Books: Knowledge Flow実践ガイド: 企業知識をAIが利用できる知識基盤へ変換する
AIを業務へ導入するとき、よく使われる指標がある。
- 回答の正答率
- 判定の一致率
- 自動処理の成功率
- 検索ヒット率
- ルール違反の検出率
これらは重要である。しかし、数値だけを見ていると、危険な見落としが起こる。
確認できなかったことを、「問題なし」または「一致」として数えていないか。
取得権限がない資料、切り詰められたログ、連携エラーで届かなかったデータ、更新が止まった情報源。AIや検証システムがそれらを見られなかったにもかかわらず、「該当なし」「一致」「合格」と扱えば、信頼性は見かけ上だけ高くなる。
この問題に対して必要なのが、Unknownを合格扱いしない検証設計である。
「見つからない」と「存在しない」は違う
例えば、AIが次の質問を受けたとする。
この申請は、過去に承認された例外条件に該当していますか。
検索の結果、関連する記録が見つからなかったとする。このとき、考えられる状態は少なくとも三つある。
- 過去にそのような例外は存在しない
- 例外は存在するが、検索条件やデータ構造の問題で見つからなかった
- 例外記録はあるが、権限や障害のために参照できなかった
1だけが「該当なし」である。
2や3まで「該当なし」と扱えば、システムは確認できなかった事実を、存在しないという結論にすり替えてしまう。
これはAIだけの問題ではない。監視、セキュリティ、品質保証、法務確認、データ連携、ETL、RAG検索など、あらゆる検証処理に共通する問題である。
検証結果は、少なくとも三値で扱う
多くの業務システムは、結果を二値で表現する。
- Pass / Fail
- Yes / No
- 一致 / 不一致
- 検出あり / 検出なし
しかし、不確実な情報環境では二値だけでは足りない。
| 状態 | 意味 | 代表例 |
|---|---|---|
| Pass / Match | 必要な証拠を確認でき、条件を満たしている | 署名済みの承認記録と現行ルールが確認できた |
| Fail / Mismatch | 必要な証拠を確認でき、条件を満たしていない | 承認限度額を超えている |
| Unknown | 判定に必要な証拠を確認できない | ログ欠落、権限不足、取得失敗、情報が古い |
Unknownはエラー表示のためだけの状態ではない。判断を保留し、人の確認や追加取得へつなげるための正式な結果である。
重要なのは、UnknownをFailと必ずしも同一視することではない。低リスクの処理では再試行や後続確認でよい場合もある。
ただし、高リスクの処理においてUnknownをPassとして扱わないことは、必須の原則である。
見かけの一致率が高くなる仕組み
Unknownを除外したり、Passへ丸め込んだりすると、ダッシュボード上の数字は美しく見える。
例えば100件の検証があり、実際の内訳が次の通りだったとする。
| 結果 | 件数 |
|---|---|
| 一致 | 80 |
| 不一致 | 5 |
| Unknown | 15 |
Unknownを無視して「確認できた85件のうち80件が一致」と表現すれば、一致率は94.1%になる。
しかし、業務全体で見ると、100件中15件は確認できていない。特にUnknownが高リスク案件や特定のデータソースに集中していれば、94.1%という数字はほとんど意味を持たない。
したがって、信頼性を示すときは、一致率だけでなく、少なくとも次を並べて表示すべきである。
- 一致率
- 不一致率
- Unknown率
- Unknownの理由別内訳
- 情報源別の取得成功率
- 高リスク対象におけるUnknown件数
- 再確認・人手確認の滞留件数
信頼できるシステムは、都合の悪い不確実性を隠さない。
Unknownが発生する主な理由
Unknownには、単に「データがない」以上の意味がある。原因を記録しなければ、改善につながらない。
| Unknownの理由 | 例 | 必要な対応 |
|---|---|---|
| 取得失敗 | API障害、タイムアウト、連携ジョブ失敗 | 再試行、障害通知、復旧確認 |
| 権限不足 | 許可されていない契約書・顧客データ | 権限申請、人の確認、アクセス制御維持 |
| ログ欠落 | 保存期間切れ、記録漏れ、途中からの運用開始 | 証跡不足として扱い、補完手続きを行う |
| ログ切り詰め | サイズ上限、会話履歴の省略、長文の途中欠落 | 原本取得、対象範囲の縮小、再処理 |
| 鮮度不足 | 最終更新日が古く、現在の有効性が不明 | 現行版を確認、更新責任者へ照会 |
| 根拠の矛盾 | 設計書と実装、議事録と規程が食い違う | 自動合格を止め、責任者の裁定へ送る |
| 検索不能 | OCR品質不良、インデックス未更新、形式非対応 | データ整備、再インデックス、対象外表示 |
Unknownを理由別に扱えば、問題を「AIの精度不足」と曖昧にせず、情報基盤、権限、運用、連携品質のどこに原因があるかを改善できる。
AIの回答にもUnknownを組み込む
生成AIは、知らないことでも自然な文章を作れる。そのため、Unknownの扱いはRAGやAIエージェントで特に重要になる。
AIは次のように答えられるべきである。
現在取得できた資料の範囲では、承認済みの例外条件は確認できませんでした。
ただし、2026年6月以前の議事録は保持期限切れのため参照できず、例外が存在しないとは断定できません。追加確認が必要です。
この表現は、回答能力が低いことを示しているのではない。むしろ、証拠の範囲と限界を正しく管理できていることを示している。
AIに求めるべきなのは、常に答えることではない。
何を確認でき、何を確認できなかったかを、正確に区別すること
である。
Unknownを次の行動につなげる
Unknownを表示するだけでは、現場では使いにくい。Unknownには、次に取るべき行動を結びつける必要がある。
- 一時的な取得失敗なら、自動再試行する
- 重要な情報源にアクセスできないなら、管理者へ通知する
- 権限不足なら、必要に応じて承認フローへ送る
- ログが切り詰められているなら、原本または対象期間を指定して再取得する
- 資料が古いなら、文書オーナーへ更新確認を依頼する
- 根拠が矛盾しているなら、AIによる自動実行を停止し、人の判断に委ねる
ここで重要なのは、Unknownを安易に自動解消しようとしないことだ。
権限がない資料を「念のためAIに読ませる」、取得できないログを別経路から無断で集める、といった設計は、信頼性を上げるどころか、セキュリティと統制を壊してしまう。
Unknownは、システムの限界であると同時に、越えてはいけない境界を示す信号でもある。
リスクに応じて、Unknownの扱いを変える
すべてのUnknownを同じように止める必要はない。しかし、リスクに応じた明確なポリシーは必要である。
| 対象 | Unknown時の扱い |
|---|---|
| 社内向け要約・下書き | Unknownを明示し、必要なら利用者に注意表示 |
| ナレッジ検索回答 | 根拠不足として回答を限定し、原本確認を促す |
| 顧客への送信文 | 自動送信せず、人の確認へ送る |
| ポイント・特典の付与 | 保留し、必要な証拠がそろうまで実行しない |
| 権限変更・契約・返金 | 原則停止し、明示的な承認を必須にする |
| 監査・法令対応 | Unknown自体を重要な監査所見として記録する |
このように、Unknownを処理の一部として設計することで、AI活用の速度と安全性を両立できる。
結び：信頼性とは、分からないことを隠さない能力である
AIシステムの信頼性は、高い一致率を表示することではない。
本当の信頼性は、
確認できたこと、確認できなかったこと、そして確認できなかった理由を、区別して示せること
にある。
観測できなかったデータ、切り詰められたログ、アクセス権のない資料を「一致」として数えない。Unknownを正式な結果として記録し、必要な再確認や人の判断へつなげる。
この設計は、AIを慎重にしすぎるためのものではない。
むしろ、AIが扱える範囲を正しく定め、その範囲では安心して自動化を進めるための基盤である。
Unknownを合格扱いしない。
その原則が、見かけの精度ではなく、実務で信頼されるAIをつくる。
Chinoba
Intelligence as Relationship
Research Platform
founded by
Masao Watanabe
AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance
Related Research
この記事は Chinoba Knowledge Base の一部です。
コメント