紙の書類をデータにする

紙で来る請求書・申込書を、AI-OCR で読み取り、確信度で人が見る範囲を絞り、業務システムに入れるまでの流れを決める

この手順の要は「読み取り」ではない

AI-OCR の話は、たいてい読み取り精度の話になります。「99.6%」のような数字が並びます。

しかし業務として成立するかどうかを決めるのは、読み取りの次の工程です。 精度 99% は「100 項目に 1 つ間違える」という意味で、どれが間違いなのかは教えてくれません。 それを人が探すなら、全件目視と手間は変わりません。

分かれ目は、間違えていそうな項目だけを特定できるかです。これができる製品とできない製品があり、そこが手順の設計を決めます。

確信度（confidence）の読み方

Azure AI Document Intelligence の公式ドキュメントが、いちばん具体的に書いています。

a confidence value of 0.95 (95%) indicates that the prediction is likely correct 19 out of 20 times

確信度 0.95 は「20 回に 19 回は正しい」という意味です。そして、

For scenarios where accuracy is critical, confidence can be used to determine whether to automatically accept the prediction or flag it for human review.

自動で通すか、人に回すかを、この値で決めるという使い方が公式に示されています。これが工程 4 の根拠です。

目安として書かれている数字

カスタムモデルの精度スコアについて、公式はこう書いています。

It's best to target a score of 80% or higher. For more sensitive cases, like financial or medical records, we recommend a score of close to 100%.

会計・医療のような分野では 100% 近くを目標にせよ、と明記されています。請求書処理はここに入ります。

落とし穴1: 全部の項目に確信度が返るわけではない

Currently, not all document fields return a confidence score.

確信度で仕分ける設計をした後で、肝心の項目に確信度が付かないと分かる——これが起きます。設計前に、自分が必要とする項目に確信度が返るかを実データで確かめてください。

落とし穴2: 確信度は 1 種類ではない

Azure は読み取り（readResults）の確信度と項目抽出（pageResults）の確信度を別に返します。そして明確に書いています。

The confidence of the read results doesn't affect the confidence of the key/value extraction results, so you should check both.

文字は正しく読めているが項目の対応付けを間違えている、という壊れ方があります。片方だけ見ていると見逃します。

AWS も同じ構造で、A2I では 2 種類を区別しています。

Identification confidence — フォーム内で検出されたキーと値の組に対する確信度
Qualification confidence — キーと値に含まれるテキストに対する確信度

落とし穴3: 表の結合セルと空欄

日本の帳票は結合セルだらけです。Azure の記述がそのまま当てはまります。

Regardless of the type of table, the expectation for merged cells is that they should have lower confidence values. Furthermore, the cell that is missing (because it was merged with an adjacent cell) should have NULL value with lower confidence as well.

そして空欄にも確信度が付きます。

When a value is missing from a row, the cell has a NULL value and confidence assigned. A high confidence score here should mean that the model prediction (of there not being a value) is more likely to be correct.

「空欄である」という予測にも自信度がある、という考え方です。確信度の低い空欄は、読み落としの可能性がある空欄になります。

各工程の中身

1. 仕分け — ここは人が決める

定型か非定型かで製品の選び方が変わります。

定型帳票（自社の申込書など、レイアウトが 1 種類）— どの製品でも扱える
非定型（発行元ごとに違う請求書）— レイアウト学習が要らない製品を選ぶ必要がある

DX Suite は自社サイトで「定型書類はもちろん、請求書や領収書、発注書など発行元ごとにフォーマットが異なる非定型書類」に対応すると書いています。Amazon Textract は請求書・領収書専用の AnalyzeExpense API を別に持っています。

手書きが混ざるかも先に決めます。 Textract は「Detect typed and handwritten text」と明記、DX Suite は 6 言語（日本語・英語・中国語繁簡・タイ語・インドネシア語・ベトナム語）の手書きに対応と記載しています。

この仕分けを AI にやらせようとする人がいますが、自分の会社にどんな紙が来ているかは、AI ではなく現場が知っていることです。 ここは業務要件定義の工程で、船井総研の型——現場に張り付いて観察する——がそのまま効きます。

2. 取り込み — ここの手抜きが後で効く

公式が短く書いています。

If the confidence score for the readResults object is low, improve the quality of your input documents.

**読み取りの確信度が低いときの対処は「入力の品質を上げる」**です。斜め、影、低解像度、折り目——ここで作った損失は、後段のどの工夫でも取り戻せません。

複合機のスキャン設定を一度決めて共有するだけで効きます。AI-OCR の検討より先にやるべき工程です。

3. 読み取り

工程表の 4 製品を参照してください。選ぶときに見るのは、精度の数字ではなく次の 3 点です。

必要な項目に確信度が返るか（落とし穴1）
API があるか。 画面で 1 件ずつ操作する製品は、月に数十枚なら十分ですが、自動化には繋がりません
手書き・非定型が要るか

Google Document AI は Digitize（Enterprise Document OCR）／ Extract（Custom extractor、Form Parser、layout parser、pretrained parsers）／ Classify（custom classifier、custom splitter） の 3 系統に分かれています。分類（Classify）が独立しているのは、届いた紙が何の書類かを先に判定する用途があるためです。工程 1 を機械側に寄せたい場合の入口になります。

4. 確信度で仕分けて人が見る — この手順の中心

全件目視でも全件自動でもない設計をここで作ります。

AWS の A2I は、人のレビューを起動する条件を 4 つ挙げています。

特定のフォームキーの確信度で起動する
特定のフォームキーが欠落しているときに起動する
指定した確信度の範囲に入る全キーで起動する
無作為抽出で一定割合を人に回す

2 番目と 4 番目が実務的です。 「金額が読めなかった」は確信度ではなく欠落として出ます。そして無作為抽出は、確信度が高いのに間違っている件を見つける唯一の方法です。確信度による仕分けだけだと、その系統の誤りは永久に見つかりません。

重要: A2I は「no longer open to new customers」と明記されています。既存顧客は継続利用できますが、これから作る仕組みの部品にはできません。 考え方（起動条件の 4 分類）は他の実装にそのまま使えるので、ここでは仕組みではなく設計として扱っています。

5. データを整える

ここから先はこの図書館の 3 ツールの領域です。大量ファイルを一括処理するがそのまま使えます。特に、

出力の形を JSON Schema で固定する
confidence に相当する欄を必ず持たせる
終了コードが 0 でも中身がエラーのことがある

6. 業務システムに載せる

データにしただけでは業務は変わりません。使う画面と申請フローが要ります。

ここは業務改善ツールの内製の巻と完全に重なります。 LIXIL の 3 つの仕掛け——機能制限・本番運用は申請制・年 1 回の棚卸し——は、この工程の運用設計そのものです。

どこから始めるか

製品選定から始めないでください。 順序はこうです。

1 週間分の紙を集めて数える。 種類・枚数・手書きの有無
スキャン設定を決める（工程 2）。ここだけで読み取り結果が変わる
10 枚を各製品の無料枠で試し、確信度が返る項目を確かめる（落とし穴1）
人が見る条件を決める（工程 4）。「確信度 0.9 未満」「金額欄が欠落」「無作為 5%」のような形
そこまで決まってから製品を選ぶ

4 を決められないなら、その業務はまだ自動化できません。 誰がどの条件で確認するかが決まっていない状態で導入すると、全件目視に戻るか、誰も確認しないかのどちらかになります。

鵜呑みにしてはいけないもの

「読み取り精度 99.6%」のようなベンダー数値。 どの帳票を、どの条件で、何を正解として測ったかが書かれていません。手書きと活字を分けて出している例もほとんど見かけません
「AI-OCR 市場シェア No.1」。 調査主体と対象範囲の記載を確認してください
「導入 3,000 社」。 導入した数であって、成功した数ではありません

この分野で分かっていないこと

日本の帳票に対する第三者の精度比較が見つからない。 各社が自社条件で測った数字しかない
国産 AI-OCR の確信度の扱いが公開されていない。 DX Suite が項目ごとの確信度を返すか、どの粒度かは公式サイトからは読み取れなかった。クラウド 3 社は公開している
A2I の後継が分からない。 新規受付が終わっているが、代替として何を使うかの公式案内を確認できていない
工程 4 の運用実績が無い。 「確信度 0.9 で仕切ったら目視が何割減った」という実データを、実名の事例として見つけられていない