Tech Learning Daily

「精度 94%」の中身 ― 精度と confidence score は別の指標

OCR ベンダーが提示する精度（accuracy）は、テスト用のデータセット全体に対してモデルがどれだけ正しく認識できたかを表す平均的な評価指標だ。一方、実際にプロダクトが 1 枚の書類を処理するときに欲しいのは「この 1 件のこの項目は、どれくらい信頼できるか」という個別の判断材料であり、これはconfidence score（抽出結果 1 つ 1 つに対してモデルが持つ、その場での自信の度合いを 0〜1 や 0〜100% で表した値）という別の指標が担う。

Azure Document Intelligence のドキュメントでは、confidence 0.95 は「20 回中 19 回は正しいと期待できる」水準として説明されている。つまり同じ「精度 94%」のモデルでも、書類ごと・項目ごとに confidence は 99% のこともあれば 60% のこともあり、平均値の 94% という数字だけでは、目の前の 1 件がどちらに近いかは分からない。

文書画像 → OCR → 項目ごとに confidence
 日付   conf .98 → 自動採用
 金額   conf .61 → 人がレビュー
 取引先 conf .99 → 自動採用

レビュー画面は「全部見る」のではなく「怪しい所だけ見る」ように作る

confidence score が項目単位で手に入るということは、レビュー担当者が書類を最初から最後まで読み直す必要はなく、confidence が低い項目だけに注意を向ければよいということでもある。AI の出力を自動で確定させず、一定の条件下で人の確認・修正を挟む設計をヒューマンインザループ（human-in-the-loop）と呼ぶ。Amazon Textract と Amazon A2I（Amazon Augmented AI）の組み合わせでは、活性化条件（activation condition）としてキーバリューの confidence がしきい値を下回ったときにだけ人のレビューを発生させる設定ができる（なお A2I は 2026-07-30 以降 AWS が新規顧客の受け付けを終了する予定のサービスだが、既存顧客は継続利用でき、この activation condition という考え方自体は他の文書処理サービスにも共通する）。

{
    "Conditions": [
        {
            "ConditionType": "ImportantFormKeyConfidenceCheck",
            "ConditionParameters": {
                "ImportantFormKey": "*",
                "KeyValueBlockConfidenceLessThan": 60,
                "WordBlockConfidenceLessThan": 90
            }
        }
    ]
}

この設定を入れると、キーバリューブロックの confidence が 60 未満、または配下の単語ブロックの confidence が 90 未満の項目を含む書類だけが、人による確認が必要な書類・項目だけを集めた待ち行列であるレビューキューに送られ、confidence の高い大半の書類はそのまま自動で流れる。逆にこの活性化条件を設定しないと、モデルの出力はすべてそのまま自動採用される設計になり、低 confidence の項目が誰にも見られないまま下流の処理に流れ込む。

しきい値をどこに置くか ― 業務の重さで変えるべき数字

しきい値を高く（例えば confidence 99 未満で全部レビュー）設定すると、大半の書類が人のレビューに回ってしまい、自動化によるコスト削減効果がほとんど残らない。逆に低く設定しすぎると、実際には誤読している項目が人の目を通らずに下流の会計処理や請求処理に紛れ込む。Azure のドキュメントは、カスタムモデルの精度目標として一般的には 80% 以上を、財務や医療記録のように誤りの許容度が低い書類では 100% に近い水準を目安に挙げ、そうした重要度の高いワークフローには人のレビュー段階を追加することを勧めている。しきい値は業務の重さに応じて個別に決める設計判断であり、一律の正解値があるわけではない。

加えて confidence は 1 段階の数字ではない。Azure のテーブル抽出では、テーブル全体・行・セルという階層それぞれに confidence が付き、あるセルの confidence が高くても、それが属する行全体としては低いということが起こる。個々のセルだけを見て「全部高いから大丈夫」と判断すると、行やテーブル単位の構造的な誤り（列のズレなど）を見落とす。

マルチモーダル LLM への移行で前提はどう変わるか

従来の OCR パイプラインは、画像から文字を認識する処理と、認識結果からどの値がどの項目かを組み立てる処理が別々のステップになっていることが多い。これに対してマルチモーダル LLM（画像とテキストを同時に扱える大規模言語モデル）は、書類の画像とレイアウトの文脈をまとめて 1 つのモデルで処理する。文字がかすれていても、周囲の文脈から「ここは金額の欄だから数字のはずだ」と推論できる点は、文字単体の認識に頼る従来型 OCR にはない強みだ。

ただしこの強みは万能ではない。マルチモーダル LLM を画像解像度別に評価した研究では、300 ppi 相当の高解像度では従来の OCR とほぼ同等の精度が出る一方、150 ppi を下回る低解像度では認識精度が従来の OCR 手法を下回ると報告されている。スマホで急いで撮った書類の写真は、この低解像度側に転びやすい。実運用では従来の OCR を完全に置き換えるのではなく、OCR の出力をマルチモーダル LLM に後処理として通し、誤読の訂正やテーブル構造の再構築に使うハイブリッドな構成が現実的な選択肢になっている。