AI-OCRとは？タイ製造業の導入・価格・精度を実務で判断する方法
AI-OCRとは、画像やPDFに含まれる文字を読む従来型OCRに、機械学習などを組み合わせ、帳票の種類やレイアウトが変わっても必要項目を取り出しやすくした技術です。ただし、AI-OCRを選べば手入力が即座になくなるわけではありません。タイの製造拠点で成果を出すには、対象帳票、受入精度、確認作業、PDPA、基幹連携、運用費までを一つの業務として設計する必要があります。本記事では、OCR・AI-OCR・IDPの違いからPoC、価格、RFPまで、導入判断に必要な論点を実務順に解説します。
AI-OCRとは：OCR・AI-OCR・IDPの違い
「帳票を読みたい」という要望は同じでも、必要な仕組みは書類の揺れ方と、その後の業務によって変わります。まず用語を分けて考えましょう。
| 区分 | 主な役割 | 得意な場面 | 注意点 |
|---|---|---|---|
| OCR | 画像内の文字を機械可読な文字列へ変換 | 定型フォーム、鮮明な印刷文字、検索可能なPDF化 | どの文字が注文番号か、といった業務上の意味付けは別途必要 |
| AI-OCR | 文字認識に学習モデルや文書理解を組み合わせ、項目を抽出 | 複数レイアウト、請求書・注文書、日英タイ語が混在する帳票 | 「AI」という名称だけでは対応範囲や精度を判断できない |
| IDP | 帳票分類、抽出、検証、業務ルール、連携までを統合 | 多種類の帳票を継続処理し、ERPやワークフローまで自動化 | 製品導入だけでなく業務設計・例外処理・監視が必要 |
OCRは「読む」技術、AI-OCRは「どの項目かを理解して取り出す」範囲まで広げた技術、IDP（Intelligent Document Processing）は「受領から基幹登録までを運用する」仕組み、と整理すると分かりやすくなります。市場では名称の使い方が統一されていないため、製品名ではなく、分類・読取・抽出・検証・連携のどこまで提供されるかを確認してください。
たとえば、固定レイアウトの検査表を同じスキャナーで読み、全文検索できればよいならOCRで足りる場合があります。一方、仕入先ごとに様式の異なる請求書から請求番号、日付、合計、税額、PO番号を取得したいならAI-OCRが候補です。さらに、注文書か請求書かを自動判定し、金額照合、承認、ERP登録、監査ログまでつなぐなら、検討対象はIDPに近づきます。
タイ製造業でAI-OCR導入が難しくなる理由
タイの工場や地域統括拠点では、単に「紙が多い」だけでなく、言語、書式、商流、IT環境が複雑に重なります。代表的な対象は、購買注文書、納品書、請求書、税務書類、輸出入関連書類、検査成績書、製造指図書、日報、設備点検票、手書き追記のあるチェックシートです。
同じ種類の書類でも、顧客や仕入先ごとに位置、表の列、単位、日付形式が異なります。英語、タイ語、日本語が一枚に混在し、コピーやFAX、スマートフォン撮影、傾き、影、折れ、印影、罫線の重なりが認識を難しくします。さらに、抽出後の値を登録するERP側では、取引先コード、品目コード、税区分、通貨、単位、工場コードなど、OCRには見えていないマスター情報との照合が必要です。
Google Cloud Document AIの現行公式説明では、Enterprise Document OCRは200を超える言語を対象とし、日本語、タイ語、ベトナム語も対応言語として案内されています（公式情報取得日：2026-08-28）。ただし、対応言語に含まれることは、個別帳票で必要な精度が保証されることを意味しません。画質、フォント、文字サイズ、表構造、手書き、言語混在、対象項目の定義によって結果は変わるため、自社サンプルでの検証が不可欠です。
帳票OCRの処理を5段階で設計する
AI-OCR導入は「ファイルをAPIへ送って結果を受け取る」だけでは完成しません。安定運用には、次の5段階を明確に分けることが重要です。
1. 帳票分類：何の書類かを判定する
最初に、受領ファイルが請求書、注文書、納品書、検査表のどれかを判定します。メール添付のPDFに複数書類が連結される場合は、ページ分割も必要です。分類を誤ると、その後の抽出モデルや必須項目ルールを誤って適用します。
分類ルールは、文書全体の特徴、特定語、ロゴ、ページ構成などを使えますが、ロゴだけに依存すると様式変更に弱くなります。「不明」クラスを用意し、低信頼の書類を無理に既知の分類へ寄せないことが安全です。新規仕入先や未知様式が発生した件数も監視対象にします。
2. 文字・レイアウト認識：文字列と位置関係を読む
次に、文字、行、段落、表、チェックボックスなどを認識します。ここでは全文が読めるだけでなく、座標やページ、セル構造を保持することが重要です。「合計」というラベルの右側にある数字と、明細行の小計を区別するには、レイアウト情報が必要だからです。
入力画像の品質も工程の一部です。解像度、傾き、余白、上下方向、暗さ、圧縮、二重撮影を入口で検査し、読取困難なファイルを早期に戻す仕組みを用意します。高性能モデルでも、切れた文字や強い反射で失われた情報は復元できません。
3. 項目抽出：業務で使う値に変える
OCR結果から、PO番号、請求日、通貨、合計金額、税額、品目、数量、単価などを抽出します。ここで必要なのは文字列ではなく、「項目名」「値」「ページ」「位置」「信頼度」を持つ構造化データです。
同じ項目でも表記は揺れます。Invoice No.、Inv No、Tax Invoice Numberなどのラベル差、仏暦と西暦、DD/MM/YYYYとMM/DD/YYYY、THBとBaht、カンマと小数点の扱いを正規化します。ただし、元の読取値を消さず、正規化前後を保存すると監査や原因調査がしやすくなります。
4. 検証：確信度と業務ルールで間違いを止める
AI-OCRの出力をそのままERPへ登録するのではなく、信頼度と業務ルールを組み合わせて検証します。たとえば、合計金額が明細合計と一致するか、PO番号がERPに存在するか、仕入先と通貨の組み合わせが通常どおりか、請求書番号が重複していないかを確認します。
モデルの信頼度は有用ですが、「0.9なら必ず正しい」とは限りません。信頼度の意味や校正方法はサービスごとに異なります。重要項目では、実データ上の誤り率と照合し、どの閾値なら自動処理できるかを決めます。金額や銀行口座などリスクの高い項目は、文字認識が高信頼でも業務ルールで止める設計が必要です。
5. 基幹連携：ERP登録と結果追跡まで閉じる
最後に、検証済みデータをERP、会計、MES、文書管理、承認ワークフローへ連携します。APIがない既存システムではCSV取込やRPAも候補ですが、途中失敗、二重登録、再実行、文字コード、排他制御を設計しなければなりません。
連携結果には、元文書ID、処理日時、モデルやプロセッサーの版、抽出値、修正値、操作者、ERP伝票番号をひも付けます。後から「なぜこの値が登録されたか」を追えることが、月次締め、監査、顧客問い合わせ、モデル改善の土台になります。
AI-OCRの精度をどう測るか
AI-OCR 精度を一つの数字だけで比較するのは危険です。文字単位の認識率が高くても、業務上重要なPO番号や合計金額が誤っていれば利用できません。反対に、備考欄の全文認識に多少の誤りがあっても、必要項目が正しく抽出されれば業務目標を達成できる場合があります。
詳細な精度設計はタイ製造業向けAI-OCR精度の評価方法でも解説しています。PoCでは少なくとも次の層を分けて評価します。
| 評価層 | 指標例 | 判断したいこと |
|---|---|---|
| 文字認識 | 文字誤り、単語誤り | 原文がどの程度読めるか |
| 項目抽出 | 項目別の正解・誤抽出・未抽出 | 必須項目を正しく取得できるか |
| 文書分類 | 文書種類別の正解・誤分類 | 適切な処理へ振り分けられるか |
| 表構造 | 行・列・セル対応の一致 | 明細を崩さず取り込めるか |
| 業務結果 | 自動処理率、要確認率、修正件数、処理時間 | 人の仕事とリードタイムが改善するか |
PoCのサンプルを都合よく選ばない
PoCには、鮮明な標準帳票だけでなく、実運用の難しさを反映したサンプルを含めます。仕入先別、帳票タイプ別、言語別、入力経路別、画質別、複数ページ、表の長さ、印影や手書き追記の有無で層別化します。正解データは、業務担当と一緒に「何を正解とするか」を定義して作成します。
同じ帳票を学習や設定調整と最終評価の両方に使うと、未知帳票への性能を過大評価します。調整用と受入評価用を分け、評価セットは受入判定まで固定してください。また、サービス側のモデル更新や設定変更があるため、PoC時のプロセッサー、版、設定、日付を記録します。
PoCの受入指標は業務リスクから決める
受入基準は、ベンダーの平均値をそのまま採用せず、自社の業務リスクから決めます。たとえば、必須項目の項目別精度、重要項目の見逃し上限、自動処理へ進める条件、担当者確認へ回す条件、処理時間、ピーク時のスループット、エラー時の復旧時間を定義します。
おすすめは「必ず無人化」という目標ではなく、三つの経路を設けることです。
- 高信頼かつ業務ルール合格：自動登録へ進む
- 一部が不確実：人の確認画面へ回す
- 読取不能または重大矛盾：差し戻し・再取得へ回す
これにより、AIの不確実性を無視せず、正しいデータだけを下流へ流せます。
Human-in-the-loopを「失敗」ではなく制御として設計する
Human-in-the-loopは、AIが判断できない箇所を人が確認・修正する運用です。これは自動化の敗北ではなく、リスクに応じて人の判断を配置する制御です。重要なのは、すべてを目視する状態から、必要な箇所だけを短時間で確認する状態へ移すことです。
確認画面では、元画像と抽出値を並べ、対象箇所をハイライトし、キーボードで素早く修正できるようにします。担当者は「全文を読み直す」のではなく、「不確実な項目とルール違反だけを見る」べきです。修正理由や変更前後の値を記録し、再学習やルール改善へつなげます。
確認負荷を測るときは、要確認書類の割合だけでなく、一件あたりの確認時間、項目数、担当者間の判断差、ピーク時の滞留、再処理率も見ます。自動処理率が高くても、少数の難しい帳票に長時間かかれば、現場負荷は下がりません。
AI-OCR導入の進め方：業務起点の7ステップ
Step 1：対象業務と目的を限定する
「全社の紙をなくす」ではなく、「仕入先請求書の入力」「受注書の転記」「検査成績書の検索」など、一つの業務に絞ります。現状の件数、繁閑、入力時間、二重確認、差し戻し、誤入力の影響を把握し、改善したい指標を決めます。
Step 2：帳票インベントリを作る
帳票種類、発行元、言語、ページ数、入力経路、レイアウト数、手書き、表、必須項目、保存要件を一覧化します。「請求書100種類」のような集計だけでなく、件数の多い上位様式と、リスクの高い例外様式を分けると優先順位が見えます。
Step 3：To-Be業務と責任分界を決める
誰がファイルを投入し、誰が例外を確認し、誰がマスター不一致を解消し、誰がシステム障害へ対応するかを決めます。クラウド事業者、導入ベンダー、自社IT、業務部門の責任範囲も明文化します。
Step 4：候補サービスを技術・運用・契約で比較する
Google Cloud Document AI、Azure AI Document Intelligence、Amazon Textractなどは、OCR、レイアウト、表、クエリ、事前構築モデル等の提供範囲や課金単位が異なります。自社帳票で必要な機能、対象リージョン、セキュリティ、運用支援を照らして比較します。機能差の整理にはAI-OCRサービス比較の実務ガイドも参考にしてください。
Step 5：PoCで受入基準を検証する
評価セットと正解データを用意し、候補ごとに同じ条件で検証します。ベンダーのデモ帳票ではなく、自社の難しい帳票を必ず含めます。精度だけでなく、設定作業、確認画面、API、監視、再処理、運用者の学習負荷も評価します。
Step 6：小規模本番で運用を安定させる
対象仕入先や一部拠点から始め、並行稼働で誤りを検出します。閾値やルールを調整し、問い合わせ窓口、障害時の手動代替、データ保持、アクセス権、ログ確認を定着させてから対象を広げます。
Step 7：継続改善と変更管理を行う
新様式、取引先変更、法令・社内規程、モデル更新、ERPマスター変更に追随します。月次で項目別精度、要確認理由、自動処理率、例外件数、コストを確認し、変更前後を比較できるようにします。
AI-OCRの価格とTCOをどう見積もるか
AI-OCR 価格は、単純な「1ページ単価」だけで比較できません。クラウドAPIでは、機能、プロセッサー、ページ数、リクエスト方式、リージョン、追加学習、保存、ネットワークなどで課金条件が変わります。SaaSでは、月額、読取枚数、ユーザー、ワークフロー、保守が組み合わさる場合があります。価格は改定されるため、必ず公式ページと見積書で最新条件を確認してください。
Google Cloud Document AIの公式価格ページでは、Enterprise Document OCRについて、月1,000〜5,000,000ページの帯で1,000ページあたり1.50米ドルと記載されています（公式情報取得日：2026-08-28）。この数値は特定の機能・数量帯の掲載価格であり、他のプロセッサー、上位数量帯、周辺サービス、税、為替、契約条件を含む総額ではありません。Amazon Textractの価格も機能とリージョンに依存し、公式ページ上の例は利用リージョンと対象APIを確認する必要があります。Azureを含む各社の価格は地域や契約で変動し得ます。
最新条件を整理する際はAI-OCR価格と費用の考え方も併せて確認してください。
TCOに含める項目
| 費用区分 | 主な項目 | 見落としやすい点 |
|---|---|---|
| 初期費用 | 要件定義、帳票分析、PoC、設定、連携開発、テスト、教育 | 正解データ作成と例外画面の設計 |
| 利用費 | OCR・抽出API、SaaSライセンス、ストレージ、通信 | 再処理ページ、複数機能の重複課金、最低利用料 |
| 運用費 | 目視確認、監視、問い合わせ、マスター保守、モデル・ルール改善 | 新様式追加と繁忙期の確認要員 |
| 統制費 | セキュリティ審査、契約、監査、ログ保管、PDPA対応 | データ主体対応、削除、越境移転の確認 |
| 変更費 | ERP改修、API変更、モデル更新、拠点展開 | 回帰テストと停止時の代替運用 |
TCO比較では「現状コスト」も同じ粒度で測ります。手入力時間だけでなく、二重確認、差し戻し、月末残業、入力待ちによる支払・出荷遅延、原本検索、誤入力対応、管理者の調整時間を含めます。一方、削減効果を100%自動化前提で置くのは避け、確認作業が残るケース、帳票量が増えるケースも試算します。
概算式を共通化する
候補比較では、次の形で月次費用を揃えると判断しやすくなります。
月次TCO = 基本利用料 + 処理量課金 + 周辺クラウド費 + 人の確認費 + 運用保守費 + 変更費の月割り
処理量は「受領ファイル数」ではなく課金単位に合わせます。一つのPDFが複数ページならページ課金が増え、同じページをOCRと抽出の複数機能へ通す構成では各機能の条件を確認します。リトライやテスト環境の処理も見込んでください。
PDPA・データ所在地・セキュリティの確認
タイで個人データを含む帳票を処理する場合、PDPA対応は製品のセキュリティ機能だけで完了しません。自社が扱うデータ、目的、法的根拠、関係者、保存期間、委託、越境移転、データ主体からの請求、漏えい対応を整理し、社内の法務・DPO・情報セキュリティ担当と確認してください。本記事は法的助言ではありません。
データフローを図にする
入力元、アップロード端末、ネットワーク、OCR処理リージョン、一時保存、ログ、確認画面、ERP、バックアップ、サポートアクセスを図にします。「データ所在地」は保存先だけでなく、処理、バックアップ、障害解析、テレメトリー、サブプロセッサーの範囲も契約資料で確認します。
帳票に従業員名、住所、電話番号、ID、銀行口座、署名、健康情報などが含まれる場合、必要最小限の項目だけを処理・保持する設計が有効です。テスト環境へ本番帳票を無制限にコピーせず、マスキングやアクセス制限、保存期限、自動削除を検討します。
契約と運用で確認する項目
- 入力文書や出力データがサービス改善・学習に使われるか
- 選択可能な処理リージョンと保存先
- 暗号化、鍵管理、アクセス制御、管理者操作ログ
- 保存期間、削除方法、バックアップからの削除方針
- サブプロセッサー、越境移転、データ処理契約
- インシデント通知、サポート時のデータアクセス
- 契約終了時の返却・削除と移行手段
タイ政府のGPPC/PDPCが提供するGovernment Platform for PDPA Complianceは、PDPA対応の公式情報へアクセスする入口として参照できます。ただし、自社の処理に適した通知内容、法的根拠や越境移転対応は、個別に専門家へ確認してください。
RFPで確認すべきAI-OCR要件
RFP（提案依頼書）では、「AI-OCR対応」「高精度」といった抽象語を避け、受入条件と証拠を求めます。
| RFP領域 | 質問例 | 提出を求める証拠 |
|---|---|---|
| 対象帳票 | 対応する帳票、言語、手書き、表、複数ページは何か | 自社サンプルでのPoC結果 |
| 精度 | 項目別に何を測り、どの条件で受け入れるか | 正解データとの比較表、誤り事例 |
| 例外処理 | 低信頼・未知様式・連携失敗をどう扱うか | 画面デモ、再処理手順、運用フロー |
| 連携 | API、バッチ、Webhook、ERP接続、二重登録防止はあるか | API仕様、エラーコード、構成図 |
| セキュリティ | 所在地、暗号化、権限、監査、保持・削除はどうなるか | 契約条項、認証報告、データフロー |
| 運用 | 監視、SLA、障害対応、モデル更新、変更管理はどうするか | SLA、サポート体制、回帰試験計画 |
| 価格 | 初期、従量、最低料金、再処理、追加環境はいくらか | 単価表、前提条件、3年TCO |
| 撤退 | データと設定を移行できるか | エクスポート形式、削除証明の手順 |
ベンダー比較を公平にする条件
全候補に同じ評価セット、同じ正解定義、同じ時間制約を適用します。事前設定の許容範囲、手動補正の扱い、未知様式の割合も揃えます。平均精度だけでなく、必須項目別、帳票群別、画質別の結果を出してもらうと、どこにリスクが残るか分かります。
デモでは成功例だけでなく、低信頼、誤分類、表崩れ、API停止、ERP拒否が発生したときの画面と運用も確認します。「読めたか」だけでなく、「読めないときに安全に止まり、復旧できるか」が本番品質を左右します。
導入方式の選び方：API・SaaS・個別構築
クラウドAPI中心
OCRや文書理解APIを組み込み、自社またはパートナーが分類、検証、画面、ERP連携を開発する方式です。既存システムへ柔軟に統合できますが、運用機能を自分たちで設計する必要があります。APIの出力が高品質でも、業務アプリ全体の完成度は別問題です。
業務SaaS中心
投入、確認画面、承認、出力までを備えたSaaSを使う方式です。早く開始しやすい一方、タイ語帳票、現地税務様式、既存ERP、個別承認ルールへの適合を確認します。利用者、ページ、帳票テンプレート、連携オプションなど課金範囲も見ます。
個別モデル・個別アプリ
特殊な帳票、独自記号、複雑な表、現場固有フローに合わせて構築する方式です。適合度を高められますが、学習データ、MLOps、保守人材、回帰試験が必要です。まず既製プロセッサーとルールでどこまで対応できるかを確認し、個別化の価値がある部分だけを選ぶのが現実的です。
よくある失敗と回避策
「精度99%」だけで採用する
測定対象、帳票、正解定義が違えば比較できません。自社の必須項目と業務結果で再評価します。
最初から全帳票を対象にする
要件と例外が膨らみ、PoCが終わりません。量が多く、形式が比較的安定し、効果を測りやすい業務から始めます。
AI-OCRだけを導入し、前後工程を残す
読み取り後にExcelへコピーし、さらにERPへ手入力するなら効果は限定的です。受領、確認、承認、連携を含む全体時間を見ます。
低信頼結果を無条件で登録する
誤登録の影響が大きい項目に閾値、照合、承認を設けます。信頼度だけでなく、取引先マスターや金額整合を使います。
本番後に精度を測らない
帳票様式や入力品質は変わります。項目別精度、要確認理由、未知様式、処理時間、コストを継続監視します。
FAQ：AI-OCR導入・価格・精度の疑問
AI-OCRとは、通常のOCRと何が違いますか？
通常のOCRは画像から文字列を得ることが中心です。AI-OCRは、機械学習や文書理解を使い、レイアウトが異なる帳票から項目や表を抽出しやすくします。ただし名称は製品ごとに異なるため、分類、抽出、検証、連携の機能範囲を確認してください。
AI-OCRはタイ語・日本語・ベトナム語に対応しますか？
対応するサービスがあります。Google Cloud Document AIのEnterprise Document OCRは、現行公式説明で200を超える言語を対象とし、日本語、タイ語、ベトナム語も案内しています（取得日：2026-08-28）。ただし、対応言語であることは個別帳票の精度保証ではありません。自社帳票で項目別にPoCを行ってください。
AI-OCRの価格はいくらですか？
機能、ページ数、リージョン、契約、確認画面、連携によって変わります。Google Cloudの公式価格では、Enterprise Document OCRの月1,000〜5,000,000ページ帯について1,000ページあたり1.50米ドルの記載があります（取得日：2026-08-28）。これは総TCOではなく、適用条件と最新価格を公式ページで確認する必要があります。
帳票OCRの精度は何%以上なら本番運用できますか？
一律の基準はありません。項目のリスク、確認工程、照合ルール、誤りの影響で判断します。平均値ではなく、PO番号、金額、日付など必須項目別に受入基準を定め、自動処理・人確認・差し戻しの経路を分けます。
手書き帳票もAI-OCRで読めますか？
サービスや文字、画質によっては認識できますが、印刷文字より変動が大きくなりやすいため、実サンプルで検証が必要です。自由記述と数字記入欄を分け、重要項目は入力制約や照合ルールを併用します。
オンプレミスで運用すべきですか？
機密性、ネットワーク、データ所在地、運用能力、更新頻度、TCOで判断します。クラウドかオンプレミスかだけで安全性は決まりません。データフロー、権限、暗号化、ログ、パッチ、バックアップ、サポートアクセスまで比較してください。
AI-OCRのPoCには何を準備すべきですか？
対象業務、帳票インベントリ、難易度を反映した評価セット、正解データ、必須項目、受入指標、連携先、セキュリティ条件、運用担当を準備します。PoCで調整したデータと最終評価データを分けることも重要です。
まとめ：AI-OCRは「読取製品」ではなく業務として選ぶ
AI-OCRとは、文字認識だけでなく、帳票の違いを扱い、必要項目を構造化するための有力な技術です。しかし成果はモデル単体では決まりません。帳票分類、文字・レイアウト認識、項目抽出、検証、基幹連携を一つの流れとして設計し、Human-in-the-loopで不確実性を制御する必要があります。タイ製造業では、多言語、様式差、PDPA、データ所在地、ERPマスターをPoCとRFPに含めてください。価格は公式条件を確認し、API単価だけでなく人の確認や変更管理まで含むTCOで比較することが、持続可能な導入につながります。
自社の帳票をどこまで自動化できるか、PoCの受入指標やRFPをどう作るかという検討段階でもご相談いただけます。タイの製造現場と既存システムを踏まえた進め方を整理したい場合は、TOMAS TECHへのお問い合わせをご利用ください。
参考情報（公式情報取得日：2026-08-28）
- Google Cloud, Document AI processor and language list: https://docs.cloud.google.com/document-ai/docs/processors-list
- Google Cloud, Document AI overview: https://docs.cloud.google.com/document-ai/docs/overview
- Google Cloud, Extraction overview: https://docs.cloud.google.com/document-ai/docs/extracting-overview
- Microsoft Learn, Azure AI Document Intelligence Read model: https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/read?view=doc-intel-4.0.0
- AWS Documentation, Amazon Textract tables: https://docs.aws.amazon.com/textract/latest/dg/how-it-works-tables.html
- Google Cloud, Document AI pricing: https://cloud.google.com/products/document-ai/pricing
- AWS, Amazon Textract pricing: https://aws.amazon.com/textract/pricing/
- Thailand GPPC/PDPC, Government Platform for PDPA Compliance: https://gppc.pdpc.or.th/
※本記事の価格・機能・対応言語は取得日時点の公式情報に基づきます。実際の契約、リージョン、利用量で条件は変動するため、導入時に各社の最新公式情報と個別見積をご確認ください。
