AI-OCR 比較で本当に知りたいのは、デモ画面で最もきれいに文字を読んだ製品名ではありません。タイ・ASEANの製造業で使う請求書、注文書、検査票、納品書を対象に、どの方式が必要項目を正しく業務システムへ渡し、例外を安全に人へ戻し、運用費を含めて継続できるかです。本稿では、同じ帳票・同じ採点器で4方式を比べるRFP、PoC、FAT・SATの作り方を解説します。
結論：AI-OCR比較は文字認識率ではなく業務出力で採点する
AI-OCRの比較表を、対応ファイル形式、表示された認識率、API単価だけで埋めると、発注後に重要な差が見えます。請求書番号を1文字誤れば照合できず、税額や通貨を誤ったまま自動登録すれば会計処理へ影響します。一方、社名の空白や全角・半角の差は、合意した正規化で吸収できる場合があります。文字単位の平均点だけでは、この業務上の重みを表せません。
比較の主語を「OCRエンジン」から「入力受付からERP登録候補、レビュー、証跡までを含む処理」に変えます。候補は少なくとも次の4方式に分けると、製品名に引きずられず要件を整理できます。
- OCR／読取専用の文字抽出
- 既成の帳票・フォーム・表抽出
- 顧客帳票向けのカスタムかつ決定論的な抽出
- 生成AI・マルチモーダル文書理解を使い、根拠と人のレビューを組み込む方式
採点するのは、重要フィールドの正しさ、誤った自動承認の有無、ストレートスルー処理率、レビュー率、未解決率、重複・出力エラー、処理時間、言語・レイアウト適合、証跡、変更耐性、総運用費です。勝つ方式は常に同じではありません。顧客が凍結した代表テストセットに対し、合意した合否条件を満たす方式が、その工程に適した選択肢です。
AI-OCR比較で分けるべき4つの方式
「AI-OCR」という一語には、文字を座標付きで返すサービスから、請求書の項目を構造化する既成モデル、学習済みのカスタム抽出、自由形式の文書を解釈する生成AIまでが含まれます。同じ土俵に見えても、出力、作り込み、変更時の挙動、説明可能性が違います。
| 比較方式 | 得意な課題 | 主な確認点 | 適しやすい使い方 |
|---|---|---|---|
| OCR／読取専用 | 文字と位置の取得 | 言語、画像品質、段組み、後段ルールの工数 | 全文検索、後段システムで項目を決める処理 |
| 既成フォーム・表抽出 | 一般的な請求書、領収書、表 | 必要項目、国・言語、モデル版、例外帳票 | 標準的な帳票を短期間で始める処理 |
| カスタム決定論抽出 | 安定した独自レイアウト、厳格な項目定義 | 学習・設定量、版変更、帳票追加、再学習 | 固定取引先や定型検査票の大量処理 |
| 生成AI・マルチモーダル理解 | 形式が多い文書、文脈を使う分類・補完候補 | 根拠、再現性、誤推論、費用、レビュー境界 | 多様な文書を人と協働して整理する処理 |
方式1：OCR／読取専用は後段設計まで含めて比べる
読取専用OCRは、ページ内の文字、行、単語、座標などを返します。単価が低く見えても、そこから「これは請求書番号」「この表の3行目は品目」と判断する分類、抽出、正規化、照合を自社またはSIerが作る必要があります。帳票が安定し、既存ルールを持つ企業には柔軟ですが、API費だけで完成価格を判断できません。
Google Cloudの公開価格ページでは、2026年9月2日時点でEnterprise Document OCRの0〜1,000ページが無料、その後の1,000〜5,000,000ページの階層が1,000ページ当たり1.50米ドルと表示されています。AWS Textractの米国西部（オレゴン）の公式例でもDetect Document Textは1ページ当たり0.0015米ドルです。いずれもアクセス日時点の公開情報であり、地域、機能、階層、契約、税、為替により変わります。分類、項目化、レビュー、保存、連携を含まない数字を完成システムの比較価格にしてはいけません。
方式2：既成モデルは「ある項目」より「必要項目」で確認する
請求書やフォーム向けの既成モデルは、ベンダーが定義したフィールドや表を構造化して返すため、初期構築を短縮しやすい方式です。ただし、タイの税務帳票で使う項目、社内のサプライヤーコード、PO照合、明細単位、押印や混在言語がそのまま満たされるとは限りません。
Azureの現行資料は、Document Intelligenceを構造化・半構造化文書の高ボリュームで決定論的な抽出に向くもの、Content Understandingをより多様またはマルチモーダルな入力や推論・生成フィールド向けとして案内しています。これはAzure自身の製品選定ガイドであり、独立した性能比較ではありません。RFPでは、候補製品の名称より、引用するモデル、APIバージョン、リージョン、言語、出力スキーマを固定します。
方式3：カスタム抽出は変更費と再検証を測る
自社独自の検査票、現品票、取引先別注文書では、ラベル付きデータやテンプレート、ルールを使うカスタム抽出が高い再現性を得やすい場合があります。その代わり、レイアウト版変更、新規取引先、撮影条件の変化、モデル更新ごとに保守が発生します。
PoCで一度だけ高得点でも、学習に使った帳票とテスト帳票が混ざっていれば評価になりません。学習用、調整用、最終受入用を分け、最終受入用はベンダーへ事前に見せないか、少なくとも調整に使わないheld-outデータにします。帳票追加に必要なラベル件数、作業時間、再学習、回帰試験、旧版へのロールバックも見積対象です。
方式4：生成AI文書理解は根拠とレビューを契約する
生成AIやマルチモーダルモデルは、項目名が一定でない文書の分類、複数箇所の文脈を使う候補抽出、注意事項の要約などに有効な場合があります。しかし、もっともらしい値を生成する危険、同じ入力での揺らぎ、モデル更新、入力長、処理時間、説明可能性を扱う必要があります。
「空欄なら推測する」のか「見つからなければnullにする」のかを明記し、出力値にはページ、領域、原文などの根拠を結び付けます。重要ID、税額、通貨、合計はマスタ照合や数式検算を通し、矛盾や根拠不足は人へ回します。生成AIの文章能力を、会計システムへ自動登録する権限と同一視してはいけません。
帳票OCRの代表テストセットを凍結する
比較の公平性は、製品カタログよりテストセットで決まります。ベンダーごとに得意なサンプルを選ばせたり、きれいなPDFだけでデモしたりすれば、順位は容易に変わります。自社の実際のばらつきを反映し、版番号とハッシュ値を付けて凍結したデータセットを用意します。
層化する軸
- 帳票種類：請求書、注文書、納品書、検査票、受領票、現品票
- 発行元：主要取引先、少量取引先、新規取引先、社内拠点
- 言語：タイ語、英語、日本語、ベトナム語、同一ページ内の混在
- 入力形態：ネイティブPDF、スキャン、スマートフォン写真、メール添付
- ページ：1ページ、複数ページ、別紙、ページ欠落、順不同
- レイアウト：現行版、旧版、位置ずれ、明細が次ページへ続く版
- 表記：手書き、印、訂正線、注記、縦書き、特殊記号
- 画像欠陥：ぼけ、ノイズ、暗さ、薄い文字、切れ、反射、傾き
Google Enterprise Document OCRには、0から1の画像品質スコアと、ぼけ、ノイズ、暗さ、薄い文字、小さい文字、切れ、反射などの品質欠陥を示す任意機能があります。公式資料も誤検知や局所的な反射の限界を記しています。品質値は業務精度ではありませんが、「撮影に失敗した」のか「抽出モデルが失敗した」のかを分ける入力ゲートとして利用できます。
テストセットには、よく出る帳票だけでなく、件数は少なくても影響が大きいケースを含めます。例えば、通貨がTHBではない請求書、マイナス明細、複数PO、手書き訂正、税込・税別が混在する帳票です。割合は実績分布を示す運用セットと、危険な境界を厚くしたリスクセットに分けても構いません。平均点だけでリスクケースが埋もれないよう、両方を報告します。
正解データを二重確認する
比較対象より正解ラベルが間違っていれば、採点器が誤りを正解にします。入力担当者が抽出し、別担当者が原本を見て確認し、不一致は業務責任者が裁定します。項目名、型、必須・任意、複数値の扱い、欠落値、明細行の境界をデータ辞書に記録します。
識別子は、先頭ゼロを保持するか、空白やハイフンを除くか、大文字小文字を区別するかを決めます。金額は小数桁、丸め、桁区切り、負数表記、税を定義します。日付は日月順、仏暦・西暦、タイムゾーン、未確定日の扱いを定義します。採点後に都合よく正規化規則を変えると、比較の再現性が失われます。
AI-OCR精度をフィールド別・業務別に測る
「認識率99%」という表示だけでは、何を分母にしたのか、どの帳票で測ったのか、重要項目の誤りが何件か分かりません。比較表では、文字精度を補助指標にし、業務フィールドと文書処理の指標を中心にします。詳しい精度評価の考え方は、関連記事「AI-OCR精度の測り方」も参照してください。
項目ごとに採点規則を変える
| フィールド | 推奨する採点方法 | 重要な誤り |
|---|---|---|
| サプライヤー／顧客ID | 合意した正規化後の完全一致 | 別会社への誤紐付け |
| PO番号・請求書番号 | 完全一致、先頭ゼロ保持 | 照合不能、重複処理 |
| 日付 | 許容形式へ正規化後に一致 | 月日逆転、年度誤り |
| 通貨 | ISOコード等へ正規化して完全一致 | THBとUSDなどの混同 |
| 税額・合計 | 明示した丸め・許容差で比較 | 自動計上額の誤り |
| 品目コード | 完全一致、マスタ照合 | 別品目への登録 |
| 数量・単位・単価 | 個別一致と組合せ整合 | 桁、単位、行ずれ |
| 明細行 | 行対応を決めてprecision/recall | 行の欠落、重複、列ずれ |
精度指標は最低でも、フィールドごとの完全一致率またはprecision・recall、文書単位のストレートスルー処理率、誤自動承認率、手動レビュー率、未解決率、重複・出力エラー率、エンドツーエンド処理時間を出します。処理失敗を母数から除外せず、「回答が返った帳票だけ」の高精度表示を防ぎます。
Azureの公式ガイドはconfidenceを推定確率として説明し、低confidenceの項目を人へ送る構成を示しています。また視覚・レイアウトの違いを学習と評価に含める必要を述べています。ただし、ベンダーAの0.90とベンダーBの0.90が同じ危険度とは限りません。同じラベル付きテストセットでconfidence帯ごとの実際の正答率を測り、校正してからレビュー閾値を決めます。
高confidenceの誤りは、レビューを通過しやすいため特に危険です。confidenceだけでなく、「小計＋税＝合計」「POの取引先・通貨と請求書が一致」「明細合計とヘッダー合計が一致」などの決定論的な業務ルールを使います。モデルが確信していてもルールと矛盾すれば、自動登録せず例外へ送ります。
多言語対応はOCR言語一覧だけで判断しない
GoogleのDocument AI processor一覧は、Enterprise Document OCRがGAで200以上の言語に対応し、印刷された日本語、タイ語、ベトナム語を含むと案内しています。一方、一般OCRで文字が読めることは、自社請求書の項目抽出、混在言語の明細、手書き、印影まで正確に処理できることを意味しません。必要な言語と帳票を顧客テストで確認します。
AWS Textractの公式制限資料は、対応する文字検出言語として英語、フランス語、ドイツ語、イタリア語、ポルトガル語、スペイン語を挙げ、手書き認識は英語のみとしています。タイ語、日本語、ベトナム語の帳票が範囲に入るなら、RFP初期の重大な適合確認になります。また同期処理のPDF/TIFFは1ページかつメモリ内10MB、非同期処理は最大500MB・3,000ページとされます。実際のページ数、ファイル容量、応答時間、非同期連携をテストします。
AzureのWhat’s Newページは、invoice modelにタイ語・ベトナム語ロケールとタイ語・ベトナム語の通貨コード対応を掲載しています。これも、見積対象のモデル、API版、リージョンで利用できるかを確認し、該当帳票で実証する必要があります。「ベンダー全体が多言語対応」という回答ではなく、機能単位で証拠を求めます。
AI-OCR価格は月次TCOへ直して比較する
公開API価格は重要ですが、月次費用の一部です。AI-OCR価格の比較では、次の式を共通フォーマットにします。
月次TCO ＝ API／プロセッサ料金 ＋ 取込・分類 ＋ 保存・ネットワーク ＋ 連携・監視 ＋ モデル／テンプレート保守 ＋ 人手レビュー ＋ 誤り訂正・再処理 ＋ セキュリティ／コンプライアンス運用
Google Cloudの2026年9月2日時点の公開ページでは、最初の100万ページまでForm ParserとCustom Extractorが1,000ページ当たり30米ドル、Layout Parserが1,000ページ当たり10米ドルと表示されています。AWSのオレゴン地域の公式例では、最初の100万ページに対してFormsが1ページ0.05米ドル、Tablesが1ページ0.015米ドルです。FormsとTablesを同時に使う例なら両機能分を考えます。これらは同じ出力範囲を保証する横並び価格ではなく、地域や機能も異なります。為替前提なしにTHBへ換算せず、見積日、リージョン、機能、無料枠・段階価格、税を明記します。
仮想的な社内試算例
以下は市場平均でもベンダー見積でもなく、比較方法を示すための設計例です。
- 月50,000ページ
- 手作業の基準：1ページ3分、労務費180 THB／時
- 手作業費：50,000 × 3 ÷ 60 × 180 ＝ 450,000 THB／月
- 案A：ストレートスルー60%、残る40%を1ページ1.5分レビュー
- 案Aのレビュー労務費：50,000 × 40% × 1.5 ÷ 60 × 180 ＝ 90,000 THB／月
- 案B：ストレートスルー80%、残る20%を1ページ1.5分レビュー
- 案Bのレビュー労務費：50,000 × 20% × 1.5 ÷ 60 × 180 ＝ 45,000 THB／月
- レビュー労務費の差：90,000 − 45,000 ＝ 45,000 THB／月
誤り訂正やリスクが同等なら、案Bのプラットフォーム費が案Aより月45,000 THB未満高くても経済合理性がある可能性があります。しかし、案Bの誤自動承認が多い、モデル保守が高い、ピーク時に遅いなら、差額だけでは決められません。全項目を入れ替えて再計算します。ここから普遍的な回収期間を主張することはできません。
レビュー時間は実測します。画面を開く時間、原本との見比べ、修正、ERPエラー対応を含めます。「レビュー対象件数」だけ減っても、難しい例外だけが残れば1件当たり時間は増えます。初年度は構築・移行・教育・並行稼働と、定常月を分けて提示すると意思決定しやすくなります。
比較スコアカードをRFPに添付する
重み付き点数は意思決定を整理しますが、重大な失敗を平均点で隠してはいけません。まず必須ゲートを設定し、通過した候補だけを重み付きで比較します。以下は顧客ごとに合意するための設計例で、外部ベンチマークではありません。
先に置く必須ゲートの例
- 凍結した受入セットで、重要フィールドの誤った自動登録が0件
- low-confidenceまたは業務ルール矛盾をすべてレビューへ送る
- 出力レコードから原本ページ・該当領域へ到達できる
- 同じ入力の再送で重複登録せず、idempotencyを確認できる
- 人の訂正、モデル・設定版、再試験結果を追跡できる
- 必須言語・ファイル・ページ数・リージョン条件を満たす
「0件」は普遍的に安全を保証する統計値ではありません。この例では、顧客が用意した有限の凍結受入セットに対するリリース条件です。本番監視と段階展開は別に必要です。
重み付きスコアカード例
| 評価領域 | 設計例の重み | 観測する証拠 |
|---|---|---|
| 業務フィールド精度 | 25% | フィールド別結果、重大度別誤り |
| 例外・人手レビュー | 15% | レビュー率、未解決率、訂正時間 |
| 多言語・帳票変動 | 15% | 層別結果、未対応条件、版変更試験 |
| 連携・運用 | 15% | API、再試行、重複防止、監視、SLA |
| 証跡・セキュリティ | 15% | 原本リンク、アクセス、ログ、保持 |
| 3年TCO・退出性 | 15% | 前提付き費用、データ出力、移行条件 |
各点数には、営業回答ではなくテストケースID、ログ、画面、API出力、見積項目を結びます。重みを後から変えても元データから再計算できるようにし、ベンダー固有のconfidenceや項目名は共通スキーマへ変換します。スコアを小数点以下まで精密に見せるより、未確認事項と失格条件を明示する方が誠実です。
AI-OCR導入RFPに書くべき項目
RFPは「当社の請求書を読めますか」という質問票ではなく、比較可能なテストと運用条件の仕様書です。次を記載します。
- 帳票台帳：種類、版、発行元、言語、月間量、ピーク、ページ数
- 入力経路：メール、共有フォルダ、スキャナー、スマートフォン、API
- 出力スキーマ：フィールド、型、必須、正規化、許容差、明細構造
- 後続システム：ERP、会計、購買、品質、DMSと責任分界
- 例外フロー：誰が何を確認し、修正後にどこへ戻すか
- データ条件：保存場所、暗号化、アクセス、保持、削除、学習利用
- 証跡：原本、座標、抽出値、confidence、ルール、訂正、出力ID
- 非機能：量、ピーク、応答、可用性、監視、バックアップ、サポート
- 変更管理：モデル・API版、通知期間、回帰試験、ロールバック
- 価格：従量単位、最低額、追加機能、保守、レビュー、環境別費用
- PoC条件：固定データ、採点器、blind／held-out、期間、成果物、合否
- 退出条件：データ・設定・ラベル・ログの返却、削除証明、移行支援
営業デモ用にベンダーがきれいな文書だけを選ぶことを禁止し、顧客が指定したblindまたはheld-out帳票を含めます。全候補の出力を同じJSONやCSVスキーマへ正規化し、同じ採点プログラムを再実行します。製品ごとに別の評価者が目視採点するより、比較の再現性が高まります。
AI-OCR導入の体制、段階展開、運用設計については「AI-OCR導入ガイド」で整理しています。本稿のスコアカードを、その導入計画の選定・受入工程へ組み込むとよいでしょう。
PoCで正常系以外を実演させる
PoCは「10枚読めた」で終わらせず、失敗したときに安全に止まり、証拠を残し、復旧できることを確認します。最低限、次を実演対象にします。
- ぼけ、切れ、反射などの取込不良を検出し、再取込へ戻す
- 未対応言語や未知レイアウトを、無理に既知項目へ当てはめない
- 明細が次ページへ続く、ページが欠ける、順序が入れ替わる
- 同じファイルを再送しても二重登録しない
- API timeout、部分成功、rate limit後に安全に再試行する
- サプライヤー、PO、通貨、合計の矛盾を人へ送る
- 人が訂正した値、理由、担当者、時刻を残す
- モデルまたはAPI版変更後に同じセットを再採点する
- 新版で悪化した場合に旧版・手動経路へ戻す
結果は、入力ID、データセット版、モデル・設定版、開始・終了時刻、出力、ルール判定、レビュー、最終登録IDで追跡します。画面のスクリーンショットだけでは再現できないため、機械可読な出力と採点結果も受け取ります。
FATとSATを分ける
FAT（Factory Acceptance Test）は、制御された環境で抽出、ルール、API、証跡、障害ケースを確認します。SAT（Site Acceptance Test）は顧客環境で、実際のidentity、network、メール・スキャナー、共有フォルダ、ERP/API、レビュー担当者、監視、バックアップを確認します。
FATで同じPDFを読めても、SATでは複合機の解像度、ファイル名、ネットワーク遅延、サービスアカウント権限、ERPマスタ、担当者の勤務時間が結果を変えます。本番可否は、ベンダー環境の抽出点数だけで決めません。SATではピーク量、部分障害、夜間処理、手動フォールバックも実地で確認します。
受入後も固定セットを捨てない
本番開始後、モデル、テンプレート、ルール、スキャナー、ERPスキーマが変わるたびに、関連する固定セットで回帰試験します。新規帳票は、即座に自動承認範囲へ入れず、レビュー期間を設けて結果を蓄積します。どの版のどの結果で自動化範囲を広げたかを変更記録へ残します。
紙の受領から保管・廃棄までを含む全体設計は「紙帳票のデジタル化ライフサイクル」で解説しています。AI-OCRだけを入れ替えても、スキャン品質、原本管理、訂正権限、保存ルールが未定なら業務は完結しません。
比較結果を稟議と契約へ変換する実務手順
評価レポートが技術チームの点数表だけで終わると、経営側は投資判断ができず、購買側は契約条件へ変換できません。最終成果物は、方式選定の理由、業務効果、残るリスク、運用体制、費用前提、リリース条件を一続きにします。次の順序でまとめると、採点結果から稟議、発注、受入へ同じ証拠を引き継げます。
手順1：対象工程と自動化境界を一文で固定する
「AI-OCRを導入する」では範囲が広すぎます。例えば「タイ工場がメールで受領する主要取引先の請求書について、ヘッダーと明細を抽出し、PO・取引先・通貨・金額を照合し、矛盾がない候補だけをERP登録待ちへ送る。確定登録は経理担当者が行う」と書きます。入力、対象、確認、出力、人の責任が一文に入れば、ベンダーの提案範囲がずれにくくなります。
自動化率を目標にする場合も、分母を定義します。受領した全ファイルなのか、対象帳票と判定された文書なのか、必須項目がそろった文書なのかで数字は変わります。対象外言語や破損ファイルを密かに除外しないよう、除外件数と理由を別に報告します。
手順2：重大度と責任者を先に合意する
誤りを、軽微、要修正、重大、リリース停止などに分類し、例を付けます。表示上の空白は軽微でも、別取引先への紐付け、通貨誤り、重複登録、原本と結び付かない値は重大になり得ます。業務責任者、経理、品質、IT、情報セキュリティが、自分の領域の停止条件を承認します。
評価担当者が重大度を後から都合よく変えないよう、判定表をテスト前に版管理します。判断が割れた場合の裁定者と期限も決めます。製品の精度を議論する前に、企業として何を危険とみなすかを固定する作業です。
手順3：証拠台帳で主張と実測を分ける
各要件について、「提案書に記載」「設定画面で確認」「PoCで実測」「契約に記載」「未確認」を区別します。営業資料に多言語対応と書かれているだけなら、実帳票でのフィールド精度とは別の証拠です。データ削除機能を画面で確認しても、バックアップやログを含む契約上の削除期限とは別です。
| 要件 | 主張 | 実測 | 契約 | 残課題 |
|---|---|---|---|---|
| タイ語請求書 | 対応言語に記載 | テスト集合の層別結果 | 対象モデル・地域を明記 | 手書き欄は追加確認 |
| 重複防止 | API仕様に記載 | 同一入力の再送試験 | 障害時責任を明記 | 長時間timeoutをSATで確認 |
| 証跡 | 画面デモあり | 原本座標と出力IDを取得 | 保持期間を明記 | 契約終了時の出力形式 |
| 価格 | 単価表あり | 実ページ量で試算 | 値上げ通知を明記 | ピーク時の追加費用 |
未確認を低得点と同じ色にせず、別の状態として管理します。能力がないのか、まだ試していないのかで次の行動が違うためです。契約までに確認する事項と、SATまでに確認する事項を分け、責任者と期限を付けます。
手順4：点数に感度分析を加える
重みは組織の優先順位を数値化したものにすぎません。業務フィールド精度を25%から35%へ変えたとき、または3年TCOを15%から25%へ変えたときに順位が逆転するなら、結論は重みに敏感です。その場合「総合1位」と断定せず、精度優先なら案A、変化対応と費用優先なら案B、と条件付きで示します。
また、推定値には範囲を持たせます。月間ページが40,000〜60,000、レビュー時間が1.2〜2.0分なら、単一のTCOだけでなく低位・基準・高位を計算します。為替、取引先追加、繁忙期、再処理率も変数にします。小さな単価差より、レビュー率や保守工数の仮定が結果へ大きく効く場合があります。
手順5：採用案だけでなく不採用理由を保存する
不採用案の記録は、将来の再選定に役立ちます。「精度が低かった」だけでなく、どのデータセット版で、どのフィールドが、どのgateに抵触し、改善条件は何かを書きます。製品が更新されたり、対象帳票が変わったりしたとき、同じ論争を最初から繰り返さずに済みます。
採用案にも留保条件を付けます。例えば「タイ語印刷請求書は自動登録候補、手書き欄は常時レビュー、ベトナム語旧版は対象外、新規supplierは最低観察期間を経てから自動化」と記載します。採用は製品全体への無条件承認ではなく、試験済みの範囲に対する許可です。
手順6：契約成果物と支払条件を受入証拠へ結ぶ
契約成果物には、設定値だけでなく、データ辞書、変換スキーマ、ラベル方針、テストセット版、採点器、全結果、例外一覧、運用手順、監視項目、障害手順、回帰試験方法を含めます。顧客が再試験できない成果物では、運用中のモデル変更を検証できません。
支払マイルストーンを「PoC完了」のような曖昧な出来事ではなく、合意した成果物とgateへ結びます。ただし、テストセットへの過適合を促す契約にしないことも重要です。受入セットだけを通す個別調整ではなく、新しいheld-out帳票でも同じ処理規則が働くかを確認します。最終的な契約条件は、各社の購買、法務、情報管理部門が適用法令と社内規程に沿って確認してください。
この手順により、比較表は単なる製品ランキングではなく、「どの範囲を、どの証拠で、誰が許可し、何を残課題として運用するか」を示す意思決定記録になります。次回の帳票追加や契約更新でも、同じ枠組みで差分だけを評価できます。
ベンダーへ確認する20の質問
- 見積対象は読取、既成抽出、カスタム抽出、生成AI理解のどれか。
- モデル名、API版、リージョン、言語、非同期・同期条件は何か。
- 各出力値から原本ページと領域へ戻れるか。
- 値が無いときはnullにするか、推論候補を出すか。
- confidenceは何を表し、当社セットでどう校正するか。
- 高confidenceの誤りを業務ルールで止められるか。
- タイ語、日本語、英語、ベトナム語混在をどう試験するか。
- 手書き、印、訂正、表の結合セル、複数ページにどこまで対応するか。
- 取込不良とモデル不良をどう分類するか。
- blind／held-outデータを使うPoCを受け入れるか。
- 学習データ、ラベル、設定、プロンプトの所有権は誰にあるか。
- 新規取引先や帳票版変更に必要な作業、期間、費用は何か。
- retry時のidempotencyと部分成功の回復方法は何か。
- 人手レビュー画面で原本、値、根拠、ルール矛盾を同時に見られるか。
- 訂正履歴を保持し、回帰試験へ再利用できるか。
- データ保存、処理地域、保持、削除、学習利用、subprocessorの条件は何か。
- 月次TCOに含まれない分類、保存、監視、サポート費は何か。
- モデルやサービス仕様の変更をいつ、どう通知するか。
- 障害時の手動経路、復旧目標、旧版ロールバックは何か。
- 契約終了時にデータ、ログ、設定、ラベルをどの形式で返却するか。
「対応しています」という回答には、対象モデル、条件、テスト結果、制限、追加費用を付けてもらいます。機能が製品に存在しても、契約プランや地域で使えない場合があります。未回答を0点にするのか、PoCまで保留にするのかも事前に決めます。
FAQ：AI-OCR比較・価格・精度のよくある疑問
AI-OCR比較では最初に何をそろえるべきですか？
製品一覧より先に、帳票台帳、必要フィールド、凍結テストセット、正解ラベル、正規化規則、重大度、例外フローをそろえます。これが無ければ、各社が異なるサンプルと指標で「高精度」を示し、比較できません。
AI-OCR精度は何%以上なら導入できますか？
普遍的な合格率はありません。フィールドの危険度と処理方法で変わります。請求書番号、取引先、通貨、税額などは個別に測り、誤った自動登録を別指標にします。低いconfidenceを人へ回しても、高confidenceの誤りが残るため、業務ルールとの併用が必要です。
AI-OCR価格はAPI単価だけで比較できますか？
できません。取込、分類、保存、連携、監視、テンプレート保守、人手レビュー、誤り訂正、セキュリティ運用を月次TCOに含めます。通貨換算は為替レートと基準日を明示し、公開単価が同じ機能範囲かも確認します。
生成AI型は従来型OCRより優れていますか？
常に優れるとは言えません。多様な文書や文脈判断では有力ですが、厳格な定型抽出では既成・カスタムモデルやルールの方が再現性と費用を管理しやすいことがあります。同じ顧客セットで、根拠、誤推論、レビュー、処理時間、TCOまで比べます。
帳票OCRのPoCは何枚あれば十分ですか？
一律の枚数はありません。総数より、主要取引先、言語、レイアウト、入力品質、危険な例外を十分に含み、項目別の不確実性を判断できる構成が重要です。少量の層は追加収集し、PoC結果の信頼区間や未確認条件を明記します。
confidenceが高ければ自動登録してよいですか？
同じラベル付きセットで校正し、重要項目の誤りを確認するまでは不十分です。confidenceは品質スコアや業務正確性と同義ではなく、ベンダー間で直接比較できません。マスタ照合、金額検算、重複検知と組み合わせます。
タイ語対応と書いてあればタイの請求書に使えますか？
言語一覧への掲載は出発点です。印刷文字、手書き、既成invoice model、表抽出、混在言語では範囲が異なり得ます。対象モデル、版、リージョンを固定し、実際のタイ語帳票でフィールド別に実証してください。
FATとSATの違いは何ですか？
FATは制御環境で抽出、ルール、API、証跡を確認します。SATは顧客環境のidentity、network、実スキャナー・入力経路、ERP連携、レビュー運用、監視を確認します。両方を通じて、デモ精度と本番運用の間を埋めます。
まとめ：同じ帳票・同じ採点器・同じ合否条件で選ぶ
AI-OCR比較の中心は、カタログ上の認識率や最小API単価ではありません。自社の帳票を層化して凍結し、重要フィールド、誤自動承認、レビュー率、未解決、証跡、連携、変更、月次TCOを同じ条件で測ることです。OCR専用、既成抽出、カスタム抽出、生成AI文書理解の4方式を、製品名ではなく業務成果で比較してください。
RFPにはテストセット、共通出力スキーマ、blind／held-out条件、必須ゲート、価格前提、失敗実演、FAT・SAT、退出条件まで書きます。内部の推奨閾値は顧客工程ごとの設計値として合意し、外部ベンチマークのように扱いません。これにより、PoCの印象ではなく再現可能な証拠で発注判断できます。
TOMAS TECHでは、タイの製造業が保有する帳票をもとに、方式を決める前の帳票台帳、比較スコアカード、RFP、PoC採点設計からご相談いただけます。候補製品が未確定の検討段階でも、必要フィールドと例外フローを整理したい場合は、お問い合わせください。
参考資料
- Google Cloud Document AI pricing（2026年9月2日参照）
- AWS Textract pricing（2026年9月2日参照）
- Azure Document Intelligence: Choose a model or feature
- Azure Document Intelligence: Accuracy and confidence
- Google Document AI processor and detail list
- Google Enterprise Document OCR
- Amazon Textract quotas and limits
- Azure Document Intelligence: What’s new
