AI-OCR精度の測り方｜タイ4言語帳票のPoC・受入試験

AI-OCR精度を比較するとき、ベンダー資料にある単一の「認識率」だけを並べても、タイで実際に扱う帳票の成否は判断できません。日本語・英語・タイ語・ベトナム語が混在し、日付、通貨、税番号、明細行、手書き追記、低品質スキャンが含まれる業務では、文字を読めた割合と、業務データとして正しく使える割合が一致しないからです。本稿では、自社帳票を使ったPoCと受入試験で、field-level precision（適合率）・recall（再現率）・F1、重要項目の完全一致、STP率、人手確認のすり抜け、処理失敗率、再現性、モデル版変更時の差分をどう測るかを、計算例と判定表まで含めて解説します。

先に結論を言えば、AI-OCRの選定は「最高の認識率を持つ製品探し」ではなく、「自社の誤りコストに合わせて、どこまで自動化し、どこから人が確認するかを測定可能な契約にする作業」です。

AI-OCR精度比較で単一の認識率を使ってはいけない理由

「OCR認識率99%」という数字は分かりやすい一方で、分母、正解条件、対象データ、前処理、除外条件が分からなければ比較指標になりません。文字単位なのか単語単位なのか、抽出項目単位なのか。空欄を正解に含むのか。明細行の位置ずれは何件の誤りに数えるのか。読み取り不能な画像を分母から除いたのか。こうした定義が違えば、同じシステムでも数値は大きく変わります。

さらに、業務影響は項目によって異なります。請求書の備考欄で記号が一つ欠ける場合と、支払先口座、税番号、通貨、総額、小数点が誤る場合を、同じ「1文字の誤り」として平均化するのは危険です。AI-OCR導入の目的は文字列を生成することではなく、ERP登録、照合、承認、支払、監査などの後続処理を安全に短縮することです。したがって、精度評価は後続業務のリスクから逆算します。

Google Document AIの公式評価資料はprecision、recall、F1とconfidence thresholdを説明し、optional fieldや繰り返しline itemを含む抽出では、単純なaccuracyよりprecision/recallに基づく評価が有用であることを示しています。MicrosoftもDocument Intelligenceについて、実際の用途に合わせたPoC、人手確認、confidenceを用いた運用設計を重視しています。AWS Textractのconfidenceは0〜100、Microsoftなどでは0〜1として扱われる場面がありますが、これは表示尺度の違いだけではありません。モデルごとに校正が違うため、ベンダー間で「0.95と95は同じ」「0.92より0.94の方が安全」と生のconfidenceを横比較してはいけません。

OCR認識率ではなく、業務判断に使う8つの指標

受入試験では、少なくとも次の8指標を同じテストセットから計算します。どれか一つだけをKPIにすると、別の重要な失敗を隠してしまいます。

precisionは TP ÷ (TP + FP)、recallは TP ÷ (TP + FN) です。TPは正しく抽出できた項目、FPは存在しない値を出した、または誤った値を正しい候補として出した項目、FNは正解があるのに抽出できなかった項目です。F1は 2 × precision × recall ÷ (precision + recall) で計算します。

ここで重要なのは、FPとFNの数え方をテスト前に固定することです。たとえば、正解にない任意項目を幻覚的に出した場合はFPです。一方、任意項目が正解データ上も存在せず、システムも出さなければTNですが、抽出評価ではTNが膨大になりやすく、単純accuracyを不自然に高く見せます。明細行でも、存在しない行を追加する誤りと、存在する行を落とす誤りを分けるからこそ、precisionとrecallが役立ちます。

帳票OCR精度を測るテストセットの作り方

PoC用データは「手元から集めやすい帳票」ではなく、「本番で起こる条件を再現する帳票」で構成します。平均的なきれいなPDFだけで評価すると、導入後にスキャナ、複合機、スマートフォン、FAX経由の画像が入った瞬間に性能が崩れます。

1. 言語・帳票型・画質を層化する

最初に、母集団を言語、帳票型、仕入先、テンプレート、取得経路、画質、手書き有無、ページ数で層化します。日本語の請求書が多いからといって、日本語だけで平均精度を作ると、少数だが高リスクなタイ語税務帳票やベトナム語仕入先帳票の失敗が見えません。件数比に応じた本番再現セットとは別に、希少・高リスク条件を多めに入れたチャレンジセットを持つと、平均性能と限界性能を分けて判断できます。

画質は少なくともgood、medium、poorの3層に分けます。解像度だけでなく、傾き、ぼけ、影、折れ、透け、圧縮ノイズ、背景模様、薄い印字、スタンプ重なり、切れ、ページ回転をタグ化します。AWSのベストプラクティスも、入力画像の品質が結果へ影響することを前提に、画像品質やconfidenceを用途に応じて扱う考え方を示しています。

2. 学習・調整用と最終受入用を分離する

ベンダーや実装チームが見ながらプロンプト、テンプレート、抽出スキーマ、前処理を調整するdevelopment setと、最終判定まで封印するacceptance holdoutを分けます。同じ帳票を調整と受入の両方に使うと、特定テンプレートへの過学習を「精度向上」と誤認します。重複画像、同じ原本の再スキャン、ほぼ同じ連番帳票は同じ側にまとめ、情報漏えいを防ぎます。

3. 正解データを二重確認する

AI-OCRの評価では、ground truth自体が間違っていることがあります。特にタイ語の声調記号、ベトナム語のダイアクリティカルマーク、日本語の全角・半角、税番号の区切り、0とO、1とIなどは、アノテーター間で揺れます。重要項目は二人の独立入力と不一致解消、一般項目はサンプリング監査を行い、正解作成者、確認者、修正履歴を保存します。

4. 失敗画像を分母から外さない

タイムアウト、ファイル破損扱い、ページ上限、暗号化PDF、APIエラー、空レスポンスは、精度計算から消してはいけません。「抽出できた帳票だけで96%」でも、5%が処理不能なら業務の完了率は別物です。処理失敗率を独立KPIにし、再試行で回復した件数、恒久失敗、手作業へ送った件数を分けます。

4言語混在で先に決める正規化ルール

AI-OCR精度は、文字列をそのまま比較するか、業務上同じ値へ正規化して比較するかで変わります。正規化は精度をごまかす処理ではなく、意味的に同じ表記を同じと扱うための評価契約です。ただし、何でも変換すればよいわけではありません。

Unicode UAX #15はcanonical equivalenceとnormalization formを定義しています。実務ではNFCを基準にする選択肢がありますが、NFKCは互換文字の区別を変える可能性があるため、項目別の承認なしに一律適用すべきではありません。原文、OCR生出力、正規化後値の3つを保存し、監査時に変換過程を追えるようにします。

日本語・英語・タイ語・ベトナム語が同一ページにある場合は、「帳票の主言語」だけで集計せず、field languageも保持します。たとえば、英語フォーム上のタイ語住所だけが誤るケースを、英語帳票の平均へ埋没させないためです。Microsoftの公開情報ではThaiとVietnameseを含むOCR言語対応が示されていますが、モデル、機能、リージョン、API版、preview/GAの状態は変わり得ます。2026年8月26日時点の参照情報だけで契約せず、採用候補の現在の公式仕様と自社入力で再確認してください。

重要項目はexact matchと業務制約を併用する

金額や税番号は、文字編集距離が近いだけでは合格にできません。1,000.00 と 10,000.00 は文字列として似ていますが、支払業務では重大な差です。critical fieldは正規化後exact matchを基本にし、加えて以下の業務制約を検査します。

• 明細合計＋税額＝総額という算術整合性
• 通貨記号と通貨コードの整合性
• 税番号・登録番号の桁数やチェック規則
• 請求日と支払期日の前後関係
• 発注番号がERPの候補集合に存在するか
• 仕入先名と登録口座の組み合わせがマスタと一致するか

制約検査はOCRそのものの正解率とは別に集計します。マスタ照合で誤りを止められたからといってOCR精度を上乗せせず、「OCRで正解」「ルールで検知」「人が修正」を分けると、改善箇所と統制効果を正しく判断できます。

confidence閾値は重要度別に実測する

confidenceは正解確率の保証ではありません。特定モデルが出すスコアと実際の正解率の関係を、採用する帳票セットでcalibration curveとして確認します。スコア帯ごとに件数と実正解率を出し、言語、帳票型、画質、重要度で分解します。低品質タイ語画像では0.95以上でも誤りが残り、きれいな定型英語帳票では0.90未満でも正しい、といった条件差があり得ます。

固定の「業界標準閾値」を探すのではなく、誤りコストと人手容量から決めます。たとえば支払先口座や総額は高い閾値＋業務ルール＋人手確認、備考欄は低い閾値または後工程で未使用なら抽出対象外、という設計が可能です。Googleの評価資料が説明するconfidence thresholdも、precisionとrecallのトレードオフを見るために使います。閾値を上げると一般に自動通過は減りprecisionが上がりやすい一方、recallやSTPが下がるため、両方を同時に見ます。

閾値設計の実務手順

1. 重要度をcritical、controlled、informationalに分類する。
2. 0.01または適切な刻みで候補閾値を動かす。
3. 各閾値でprecision、recall、F1、STP、leakage、レビュー件数を再計算する。
4. 言語・帳票型・画質別に最悪層を確認する。
5. 人手確認チームの1日処理能力とSLAを重ねる。
6. 採用閾値、理由、承認者、適用モデル版を記録する。

レビューキューに送った帳票だけを再学習データにすると、低confidence例へ偏ります。一方、自動通過した高confidence群にも抜き取り監査を残さなければ、critical-error leakageを測れません。高スコア群のランダム監査と、高リスク層の重点監査を組み合わせます。

説明用の仮定で計算するAI-OCR PoC

以下は計算方法を示すための説明用の仮定です。特定ベンダーの性能、TOMAS TECHの保証値、導入効果の予測ではありません。

テストセットを、日本語・英語・タイ語・ベトナム語の4言語群、good・medium・poorの3画質層、各100帳票として、4 × 3 × 100 = 1,200帳票用意したと仮定します。正解として存在する抽出対象は合計9,600項目です。結果がTP 9,024、FP 216、FN 576なら、次のように計算します。

• Precision = 9,024 ÷ (9,024 + 216) = 97.66%
• Recall = 9,024 ÷ (9,024 + 576) = 94.00%
• F1 = 2 × 97.66% × 94.00% ÷ (97.66% + 94.00%) = 95.80%（丸め）

重要項目3,600件のうち3,480件が正規化後に完全一致したなら、critical-field exact matchは 3,480 ÷ 3,600 = 96.67% です。一方、必須項目が帳票内ですべて一致した帳票が684件なら、document exact matchは 684 ÷ 1,200 = 57.00% です。項目精度が高く見えても、帳票単位で完全無修正となる比率は低くなり得ることが分かります。

人手を介さず通過した帳票が870件ならSTPは 870 ÷ 1,200 = 72.50%。その自動通過群870帳票のうち、重要誤りを1件以上含む帳票が9件なら、critical-error leakageは 9 ÷ 870 = 1.03% です。処理不能が18件ならfailure rateは 18 ÷ 1,200 = 1.50%。同一入力・同一設定で複数回実行し、1,188件の出力が一致したならrepeatabilityは 1,188 ÷ 1,200 = 99.00% です。

モデル版更新前後で9,600項目中44項目の結果が変わったなら、version deltaは 44 ÷ 9,600 = 0.46%。内訳が改善31、悪化13なら、差分総数44と整合します。ただし、改善件数が悪化件数より多いだけで自動承認はできません。悪化13件が総額や税番号に集中していれば、平均値が改善していてもリリースを止めるべきです。

受入基準は「平均点」ではなくゲートで定義する

同じく説明用の仮定として、受入基準をF1 95.00%以上、重要項目完全一致99.50%以上、STP 70.00%以上、leakage 0.20%以下、failure 1.00%以下、repeatability 99.00%以上とします。

この結果の総合判断は「平均的には良いので採用」ではなく、条件付き保留、是正後に再試験です。重要項目の誤り、人手確認のすり抜け、処理不能が受入ゲートを超えているためです。修正対象を、低品質スキャンの前処理、重要項目の閾値、マスタ照合、レビュー振り分け、失敗時の再試行に分解し、変更後は同じholdoutと追加challenge setで再試験します。

再現性と版変更差分を受入試験に入れる

AIサービスは、同じ製品名でもモデル、API、prebuilt processor、学習データ、既定設定が更新される可能性があります。Googleのprocessor listやMicrosoftのWhat’s newのような公式情報で提供範囲を確認しつつ、本番側でもモデルID、API版、リージョン、設定、前処理コード、評価スクリプトを固定・記録します。対応言語やpreview/GAの状態を提案時点の記憶で断定せず、判断直前に再確認する運用が必要です。

再現性試験では、同一ファイルを複数回処理し、生出力、正規化値、confidence、座標、行対応が変わるかを確認します。非決定的な差がある場合は、業務結果へ影響しない差と、重要値が変わる差を分けます。版変更試験では、新旧を同一セットに並行実行し、aggregateだけでなくchanged casesを全件レビューします。

変更管理の最低記録は次の通りです。

• モデル名、processor種別、モデル版、API版、リージョン
• 入力ファイルのハッシュ、テストセット版、ground-truth版
• 前処理、正規化、schema、threshold、business ruleの版
• 実行日時、再試行、エラー応答、処理時間
• 指標集計、層別集計、変更項目一覧、承認者

NIST AI RMFは、AIの測定、監視、人とAIの役割、リスク対応を継続的な管理として捉える枠組みを提供しています。AI-OCRでも、PoC一回の点数を永久保証とせず、導入後のサンプリング監査、drift監視、障害レビュー、版更新ゲートまで運用設計に含めることが重要です。

AI-OCR導入PoCを6段階で進める

Phase 1: 業務と誤りコストを定義する

対象帳票、月間件数、繁忙ピーク、言語、入力経路、後続システム、保存要件を棚卸しします。項目ごとに誤りの影響、検出可能性、修正時間を評価し、criticalityを決めます。「OCR精度を上げる」ではなく、「誤支払を防ぎながら、支払登録のリードタイムを短縮する」のように業務目的を定義します。

Phase 2: 評価契約を作る

正解条件、正規化、TP/FP/FN、明細対応、失敗処理、層別集計、閾値探索、受入ゲートを文書化します。ベンダーには、総合認識率ではなく、同じ評価スクリプトへ投入できるfield output、confidence、座標、モデル情報、エラー情報の提供可否を確認します。

Phase 3: 小さく統合する

最初から全帳票をERPへ自動登録せず、抽出、正規化、ルール検査、レビューUI、監査ログまでの細いend-to-endを作ります。人手確認者が原画像、抽出値、confidence、差分、候補マスタを同じ画面で確認できるかは、STP以外の処理時間に直結します。

Phase 4: holdoutで測る

調整を止めた時点で設定を凍結し、未使用holdoutを一度だけ評価します。全体、言語、帳票型、画質、仕入先、重要度ごとの結果を出し、最悪層を確認します。平均値が合格でも、特定層が業務上許容できなければ条件付き運用または対象外にします。

Phase 5: shadow operationを行う

本番入力を使いつつ、既存業務の結果を正本とするshadow期間を置きます。日次の件数、STP候補、レビュー量、leakage、failure、処理時間、API費用を観測します。個人情報、機密情報、保存場所、アクセス権、ログ保管、削除条件も同時に確認します。

Phase 6: 受入・展開・監視へつなぐ

合格ゲート、例外、残存リスク、手作業へのfallback、SLA、障害連絡、モデル更新通知を承認します。受入後も、自動通過群の抜き取り、重要誤りのroot cause、月次層別指標、版変更前の回帰試験を続けます。

RFP・ベンダー比較で確認する質問

OCR精度比較を価格表だけで終わらせず、次を同じフォーマットで回答してもらうと、PoC後の運用差が見えます。

1. 指定する日本語・英語・タイ語・ベトナム語帳票を、同一条件で評価できるか。
2. field value、raw text、confidence、bounding region、page、model/versionを出力できるか。
3. optional fieldとline itemの評価・対応付け方法は何か。
4. confidenceの意味と校正方法、推奨ではなく実測閾値の設定方法は何か。
5. 低品質画像、回転、複数ページ、混在言語、手書き、スタンプの制約は何か。
6. API失敗、部分抽出、timeout、再試行、重複処理をどう扱うか。
7. データ保存、学習利用、暗号化、リージョン、アクセスログ、削除の条件は何か。
8. モデル更新の通知、版固定、rollback、回帰試験の仕組みはあるか。
9. 人手確認UIと監査ログを含めたend-to-endの処理時間・費用はどう測るか。
10. PoCの成果物として、テストセット定義、評価コード、誤り一覧、運用設計を引き渡せるか。

費用設計の前提を整理したい場合は、タイでのAI-OCR料金・費用の考え方も参照してください。手書き欄や非定型フォームが多い場合は、手書きOCRと帳票デジタル化の実務ガイドを先に読み、活字帳票と別層で評価することをおすすめします。

よくある失敗と回避策

きれいな10枚だけでデモを比べる

デモは操作理解には役立ちますが、統計的な受入根拠にはなりません。層化した十分な件数とholdoutを用意し、failureも含めて計測します。

vendor confidenceを共通尺度とみなす

0〜1と0〜100を換算しても、モデル間の校正は揃いません。各候補を自社データでスコア帯別に実測し、それぞれ別の閾値を決めます。

人手確認へ送った案件だけを監査する

これでは自動通過群の誤りが見えず、leakageをゼロと誤認します。自動通過群にもランダム監査と高リスク層監査を残します。

正規化後の値だけを保存する

変換ミスやUnicode差分を追えません。原画像、raw output、normalized value、適用ルール版を関連付けて保存します。

平均精度だけで多言語を承認する

件数の多い言語が平均を支配します。4言語、画質、帳票型、重要項目でminimum gateを設定します。

FAQ：AI-OCR精度とOCR認識率の疑問

AI-OCR精度は何%以上なら導入できますか？

一律の合格率はありません。誤りコスト、項目重要度、人手確認能力、後続の検知ルールで変わります。全体F1だけでなく、重要項目の完全一致、leakage、failure、STPをゲート化し、自社帳票で決めてください。

OCR精度比較ではprecisionとrecallのどちらを優先しますか？

存在しない値を後工程へ渡す損失が大きい場合はprecision、必要項目の取りこぼしが大きい場合はrecallを重視します。実務ではF1と業務別の誤りコストを併用し、重要項目はexact matchで別管理します。

帳票OCR精度に空欄はどう数えますか？

任意項目が存在しないケースを大量の正解としてaccuracyへ入れると、数値が高く見えます。抽出ではTP/FP/FNを定義し、存在しない項目を誤抽出した場合をFPとして扱う設計が分かりやすいです。

日本語・英語・タイ語・ベトナム語を同じPoCで評価できますか？

可能ですが、総合平均だけにせず、言語別・field language別・画質別に層化してください。各サービスの対応モデル、機能、リージョン、preview/GA状態は変更されるため、2026年8月26日時点の資料だけでなく、評価時点の公式仕様を再確認します。

confidence thresholdは何点が標準ですか？

固定の業界標準として扱うべき値はありません。ベンダーやモデルでスコアの校正が違います。criticality別に候補閾値を動かし、precision、recall、STP、leakage、レビュー量を自社データで実測して決めます。

AI-OCR導入のPoC期間中に本番連携まで必要ですか？

全機能の本番化は不要ですが、抽出だけの精度テストではSTPやレビュー時間が分かりません。小規模でも、正規化、業務ルール、人手確認、監査ログまでのend-to-endを検証すると、導入判断が現実的になります。

まとめ：AI-OCR精度は自社の受入契約として測る

AI-OCR精度は、広告上の認識率を比べるのではなく、自社帳票と業務リスクを使って定義します。4言語・帳票型・画質を層化したholdoutを用意し、precision、recall、F1、重要項目完全一致、document exact match、STP、critical-error leakage、failure、repeatability、version deltaを一つの判定表へ載せます。日付、通貨、税番号、Unicode、明細対応の正規化規則を先に固定し、confidence閾値はcriticality別に実測します。平均値が良くても重要ゲートが落ちれば保留し、修正後に同じ条件で再試験することが、安全なAI-OCR導入への最短経路です。

日本語・英語・タイ語・ベトナム語帳票のテスト設計、ground truth、PoC評価表、受入ゲートをまだ整理している段階でもご相談いただけます。特定製品を前提にせず、自社帳票で比較可能な評価条件から設計したい場合は、TOMAS TECHへのお問い合わせをご利用ください。

参考情報

• Google Cloud: Evaluate a processor
• Google Cloud: Shared.Types.Metrics
• Google Cloud: Processor list
• Microsoft: Transparency note for Document Intelligence
• Microsoft: OCR language support
• Microsoft: What’s new in Document Intelligence
• AWS: Amazon Textract best practices
• AWS: Responsible AI Service Card—Textract AnalyzeID
• Unicode Consortium: UAX #15 Unicode Normalization Forms
• NIST: Artificial Intelligence Risk Management Framework 1.0

※対応言語、processor、モデル、API、リージョン、preview/GAなどの提供状態は変更される可能性があります。上記は2026年8月26日参照時点の一次資料であり、選定・契約時には各社の最新公式情報を確認してください。