AI-OCRを業務につなぐIDPとは？仕組みとツール選び、精度の評価方法

AI-OCRなどを用いるインテリジェント文書処理（IDP）は、転記の手間を減らし、誤ったデータが業務システムに入り込むのを防げてこそ価値があります。設計の軸になるのは4つの仕事です。文書を分類し、項目を抽出し、値を検証したうえで、例外を人に回します。保存や登録は、その確認を経てから行います。

業務部門や経理部門の責任者にとって、まず役立つ成果物は、原本を添付した確認済みの下書きデータです。支払いの自動実行、契約の解釈、取引先の承認は、それぞれ別に判断する必要があります。最初に取り組むのは、日々の時間を奪っている作業で十分です。添付ファイルを読み、項目を転記し、保存先のフォルダーを探すところから始めましょう。

機能と制約は、2026年10月26日時点の各社の公式ドキュメントで確認しています。以下の試験導入は評価方法の提案であり、製品のベンチマーク結果ではありません。

AI-OCRを業務につなぐIDPの仕組み

IDPは、文書を業務で使えるデータに変え、判断がつかないものを確認に回すワークフローです。 チェックリストを使う書類担当者を思い浮かべるとわかりやすいでしょう。届いたものを見分け、必要な情報を書き写し、ルールと照合して、解決できない書類を判断できる人に渡します。

入力には、記入欄が固定された定型フォーム、取引先ごとにレイアウトが異なる準定型の請求書、非定型のメールなどがあります。処理後の送り先は、会計システム、契約台帳、案件管理の処理待ち一覧などです。AWSによるIDPの解説でも、分類、抽出、検証、システム連携を、こうした一連の処理の構成要素として説明しています。

請求書であれば、次のような流れが実用的です。

1. 分類する。 添付ファイルが請求書、クレジットノート、取引明細書、それ以外のどれかを判定します。複数の文書をまとめたファイルは、項目を抽出する前に個々の文書へ分割します。
2. 抽出する。 取引先、請求書番号、日付、通貨、合計、明細行を読み取ります。原本とともに、それぞれの値の根拠となるページや領域を保持します。
3. 検証する。 必須項目、計算の整合性、重複、取引先マスターを確認します。合計金額を正しく読み取れていても、別の請求書の金額である可能性は残ります。
4. 振り分ける。 受け入れ可能と判断したデータを、許可された保存先へ登録します。発注書がない、合計が合わない、分類に確信が持てないといったものは、担当を明確にした確認者へ回します。

これらは自分たちで設計すべき役割です。どの抽出APIにも備わっている機能だと考えてはいけません。APIはソフトウェアがサービスを呼び出すための接続口であり、自社の承認方針を知らなくても、抽出した項目を返すことはできます。

処理の最初から最後まで、データにはファイルの識別子を付けたままにします。抽出が正確でも、根拠となった文書を見つけられなければ、業務としては失敗になり得るからです。

LLMと画像認識モデルでOCRはどう変わったのか

変わったのは、項目の位置だけでなく、意味やページ内の文脈を使って抽出できるようになったことです。 光学文字認識（OCR）は、画像から文字を読み取ります。テンプレート型の抽出処理は、その後で所定の位置を探したり、レイアウトのルールに従ったりします。大規模言語モデル（LLM）は言語を解釈し、視覚言語モデルは画像も入力として扱います。

たとえば、取引先が「お支払金額」の欄を右下から上部の集計欄へ移したとします。固定位置を前提にしたルールなら修正が必要です。一方、「支払うべき合計金額を見つける」と指示されたモデルは、項目名や周囲の文脈を利用できます。ただし、それでも別の金額を選ぶ可能性はあります。

Google Document AIのCustom Extractorは、取得したい項目名を定義したスキーマに基づき、基盤モデルで情報を抽出できます。ゼロショットとフューショットにも対応しており、タスクの例を与えずに使う方法と、少数の例を与える方法を選べます。つまり、マネージド型の抽出サービスも、すでに従来のテンプレートだけに依存する方式から進んでいます。利用できる方法は、GoogleのCustom Extractorドキュメントに説明されています。

構造化出力が解決するのは、これとは別の課題です。返答を、指定したデータ構造に収めます。日付欄に文字列が入り、合計が数値で返れば、ソフトウェアは扱いやすくなります。しかし、形式が整っていても、その値を正しい箇所から読み取った証拠にはなりません。構造を確かめるスキーマ検証と、業務上受け入れられる値かを確かめる業務ルールの検証は、分けて考えます。

インテリジェント文書処理はどんな業務に使えるのか

最初の対象は、何を正解とするかを明確に定義できる業務から選びます。 「書類仕事をすべて処理してほしい」という指示よりも、範囲を絞った抽出タスクのほうが評価しやすくなります。

買掛金・支払管理では、請求書から支払データの下書きを作り、取引先と照合して、重複を検出します。印字された口座番号を完全に読み取れていても、振込先口座の変更は自動受け入れの対象から外します。

契約書では、当事者、記載された日付、更新について述べた箇所を抽出します。通知期間をそのまま抜き出すことと、変更契約を踏まえてその期間をどう適用するか判断することは別です。業務責任者は前者を契約台帳の準備に使えますが、後者には責任を持って判断する確認者が必要です。

フォーム・申込書では、入力された文字や選択マークを取り込み、記入漏れを確認します。受け入れ手続きのフォームに必須の署名がなければ、答えを推測して補うのではなく、未完了のまま扱います。

メールでは、依頼内容を特定し、添付ファイルと結び付けます。「修正版の請求書を使ってください」と書かれているなら、その関係を維持できるワークフローが必要です。両方の添付ファイルを抽出して、重複したデータを作るだけでは足りません。

同じ考え方は、保険金請求の受付、出荷書類、従業員の記録にも使えます。判断の基準は具体的なままです。どの値が必要で、根拠はどこにあり、食い違いは誰が解決するのかを決めます。

文書処理ソフトは買うべきか、自社で組み立てるべきか

標準的な業務なら完成済みのアプリケーションを選び、自社特有のルールや登録先があるなら抽出サービスを軸に構築します。 違いは、取り込み、検証、確認、連携のどこまでを自社で担うかです。

マネージドサービスは構成部品であり、導入するだけで経理のワークフローが完成するとは限りません。一方、「自社向けに構築する」ことは、モデルをゼロから学習させることでもありません。ホスト型の抽出サービスを使い、取り込みと確認の工程を自社で設計することもできます。

購入を判断するうえで見たいのは、確認担当者が原本を横に表示しながら、例外への対応を完了できるデモです。アップロード完了のアニメーションだけでは、その後に残る仕事はほとんどわかりません。

IDPの主要サービスとLLMを使った構築方法

実際の文書の種類、必要な根拠、確認作業の負担を軸に比較します。 以下は、各社が公式に説明している機能をまとめたものです。適性についての判断は選び方の提案であり、精度のランキングではありません。

Google Document AI：プロセッサーを選び、生成AIによる抽出も使う

Google Document AIは、Google Cloudの文書処理サービスです。プロセッサーのカタログには、OCR、Invoice Parser、Custom Extractor、Custom Classifier、Custom Splitterがあります。Invoice Parserはヘッダーと明細行の項目を抽出し、分類と分割は文書の種類や区切りを扱います。それぞれの役割は、Googleのプロセッサーカタログで確認できます。

まずは用途に合う事前構築済みのプロセッサーを試し、必要な項目や文書の種類が合わなければCustom Extractorを評価します。生成AIを使う方法では、スキーマに沿った抽出に加え、例の提示やファインチューニングを任意で利用できます。Googleの評価機能には完全一致とあいまい一致もあるため、結果を比較する前に、どの表記の正規化を許容するか決めておきます。詳しくはCustom Extractorのドキュメントを参照してください。

残る課題は、ワークフローを誰が担うかです。請求金額が返ってきても、それだけで取引先との照合、社内方針の適用、例外の解決まで終わるわけではありません。試験導入の前に、選んだプロセッサーのバージョンが対応する言語、リージョン、文書を確認します。

Azure AI Document Intelligence：事前構築済みモデルとカスタムモデル

Azure AI Document Intelligenceは、Microsoftの文書抽出サービスです。公式に案内されている選択肢には、ReadとLayout、請求書や領収書向けの事前構築済みモデル、カスタムのテンプレート抽出とニューラル抽出、カスタム分類があります。Microsoftは、レイアウトが固定された文書にはカスタムテンプレートを、より多様な文書にはニューラルモデルを使うと説明しています。Microsoftのモデル概要で確認できます。

Azure上の業務システムであれば、文書に合う事前構築済みモデルから始めます。受け取る一式のファイルに異なる種類の文書が混在するならカスタム分類を加え、必要な項目が既存モデルと異なるならカスタム抽出を評価します。

注意したいのは、レイアウトを認識すれば業務データが完成する、と思い込むことです。Layoutは文字、表、選択マークを認識できますが、出力を登録先の要件と整合させるのはアプリケーション側の仕事です。MicrosoftのLayoutガイドでも、ページをまたぐ表を後処理でひとつに結合する方法に明示的に触れています。

AWSのインテリジェント文書処理：Amazon Textract

Amazon Textractは、Amazon Web Servicesが提供する、文書内の文字やデータを抽出するサービスです。AWSは、文字検出、フォームや表の抽出、請求書と領収書に特化した処理を案内しています。経費分析では、取引先別のテンプレートを用意せずに、請求日、請求書番号、合計などの項目を取得できます。Textractの請求書・領収書向けドキュメントで説明されています。

周辺のアプリケーションがすでにAWS上で動いており、文書の項目が提供される処理機能に合うなら、Textractは最初に試す候補になります。どの文書も単なるテキストとして扱うのではなく、用途に対応する処理を選びます。

注意したいのは、信頼度スコアだけで業務上の判断が決まる、と思い込むことです。AWSは、用途に求められる慎重さに応じてしきい値を設定し、不確かな結果を詳しく確認するよう勧めています。また、結合セルや不規則な表では、抽出結果が安定しない場合があると注意を促しています。Textractのベストプラクティスを参照してください。

LLMを使う構成：モデル、スキーマ、確認待ちキュー

LLMを中心に構築する方法の一例がOpenAI APIです。ソフトウェアからモデルへ文書を送り、定義した構造で項目を返すよう求めます。PDFの場合、画像を扱えるモデルへの入力経路では、抽出テキストと各ページの画像の両方が渡されます。ファイル入力のドキュメントに説明があります。

項目を定義し、根拠の参照先を必須にし、値がない場合の扱いを決めるのは、アプリケーション側です。「記載なし」「判読不能」などの理由を付けて欠損値として扱い、モデルにすべての空欄を埋めさせないようにします。生成されたページ番号が正しいと決めつけず、根拠の参照先を原本と照合します。

OpenAIは、対応する構造化出力がスキーマに従うことを説明する一方、値には誤りが残り得ること、回答の拒否や未完了の返答への対応が必要なことも明記しています。Structured Outputsのドキュメントを確認してください。当サイトの構造化出力ガイドでは、モデルとアプリケーションの間で取り決める出力の仕様を解説しています。

この方法が向くのは、文脈を踏まえた抽出が不足していて、ワークフローを維持できる担当者がいる場合です。課題は運用にあります。プロンプトを書いてJSONの返答を得ても、評価、再試行、人による確認、保存、登録先への安全な書き込みは自分たちで担います。

Dext：経理書類の取り込みに用途を絞って選ぶ

Dextは、経理書類を取り込むアプリケーションです。領収書や請求書の処理が滞っている場合に、候補となります。公式ドキュメントでは、取引先または顧客、日付、合計、税額、請求書番号を抽出し、詳細画面で確認・編集して、連携先の会計ソフトへ出力する流れを説明しています。Dextの抽出ガイドを参照してください。

確認済みの経理データを作れば課題が解決する経理責任者なら、汎用的な文書システムの開発を依頼するより、こうした製品から検討するほうが目的に合います。ただし、この推奨は契約の解釈や、多種多様なフォーム・メールの一連の処理にまで広げられるものではありません。経理アプリケーション自体を選びたい場合は、AI会計ソフトの比較を参照してください。

自動化を任せる前に、試験導入で項目ごとの精度を測る

抽出結果に基づいて処理を実行させる前に、業務に必要な値を採点します。 正しく転記できているように見える文書にも、通貨、取引先、支払金額といった肝心な項目の誤りが潜んでいることがあります。

1. 1

   対象の文書をひとつに絞り、必須項目を定義する

   取引先の請求書から支払データの下書きを作るなど、範囲を限定した仕事から始めます。必須項目をすべて挙げ、それぞれの出典と、その値を根拠に許可できる処理を明確にします。抽出した値と、計算などで導いた値は区別します。文書に記載された支払期日と、支払条件から計算した期日は、別の結果です。

2. 2

   人が確認した正解データを作り、評価用の文書を取り分ける

   実際の文書の傾向を反映する過去の資料を集めます。初めて扱う取引先、画質の悪いスキャン、クレジットノート、難しい表も含めます。正解データとは、人が確定した正しい答えです。判断が曖昧な箇所や重要な項目は、別の担当者にも確認してもらいます。評価用の文書は、プロンプトの調整や抽出器の学習に使う例と分けて管理します。同じ取引から生じた、ほぼ同一の文書についても、両方にまたがらないようにします。

3. 3

   結果を見る前に、一致とみなすルールを決める

   前後の空白や、既知の日付形式といった、意味を変えない表記の違いは正規化します。金額、口座の識別情報、請求書番号には、緩い文字列の類似判定を使いません。通貨と小数の意味を保ちます。明細は、値が正しいかに加え、正しい行に割り当てられているかも採点します。金額が合っていても、別の品目に結び付いていれば誤りです。

4. 4

   各候補を、同じ未加工の文書で試す

   手動で直す前の返答をそのまま保存し、モデルまたはプロセッサーのバージョン、プロンプトとスキーマのバージョン、処理の失敗、原本の参照先を記録します。読み込めないファイル、タイムアウト、何も抽出できなかった結果も、運用上の成績に含めます。黙って分母から外してはいけません。

5. 5

   例外を振り分け、既存業務と並行して試す

   既存の処理を続けながら、導入候補のワークフローで下書きを作ります。修正内容と確認時間を測ります。自動受け入れを有効にするのは、取り分けた評価用文書での結果が、業務責任者の事前に定めたしきい値を満たした文書群に限ります。影響の大きい処理には、別途承認を残します。

項目、データ全体、見逃した誤りを分けて測る

平均値ひとつでは、どこで誤りが起き、どんな影響を及ぼすかが見えなくなります。項目ごと、難しい文書のグループごとに、結果を分けて記録する評価表を使います。

任意項目に値がなかったケースは、別に集計します。何百もの欄が空欄のままで正しかったというだけで、性能が高く見えてしまうのを防ぐためです。再現率も示すなら、「正しく取得できた必須の値の数」を「すべての必須の値の数」で割ったものと定義します。文書の分類と、ひとまとめのファイルを分割する精度も、別に評価します。別の文書から完璧に抽出しても、そのレコードは失敗です。

以下は計算の例であり、製品の実測値ではありません。 請求書が200件あり、それぞれに8項目が必要なら、正解すべき値は1,600個です。1,590個が正しくても、残る10個が別々の請求書の支払合計だった場合、すべて正しい請求書は190件にとどまります。項目単位の総合成績がよくても、それを根拠にすべての請求書を承認することはできません。

見逃した誤りを測るには、確認待ちキューを見るだけでなく、ワークフローが受け入れると判断したデータも監査します。試験導入では、まずすべての出力を確認します。その後サンプリングに切り替えても、受け入れている文書全体の傾向を反映する必要があります。自動受け入れがまったくなければ、誤りの見逃し率は「未定義」です。完璧な結果ではありません。値が入った項目がない場合の適合率にも、同じ考え方を適用します。

IDPの導入効果は、減らせた作業時間で測る

業務上の効果は、正しいデータを得るまでにかかる時間が短くなることです。手作業と比較する際は、取り込み、モデルの処理、修正、確認、出力、やり直しを含め、導入後の工程全体を対象にします。完了までの所要時間と、未解決の例外のうち最も古いものがどれだけ滞留しているかも追います。抽出が速くても、確認待ちが増えているなら、滞留の場所を移しただけです。

確認担当者には、原本のページ、可能であれば強調表示した根拠、抽出値、違反したルール、登録先を示します。修正内容と理由も記録します。ヒューマン・イン・ザ・ループAIのガイドでは、確認待ちキューの責任分担とエスカレーションを扱っています。例外を解決する担当者を決めることも、ワークフローを立ち上げる仕事の一部です。

IDPがつまずきやすい手書き、表、スキャン画像

試験導入には、扱いにくい入力を意図的に含めます。 きれいなデジタル請求書だけで評価しても、スマートフォンで撮った写真、書き込みのあるフォーム、次のページに続く表を処理できるかは、ほとんどわかりません。

手書きは、専用の評価グループを設けます。 製品が手書きに対応していても、取り消し線のある金額、続け字のメモ、重なった印影は曖昧さを生みます。対応状況は言語によっても異なります。Amazon Textractが公式に案内している手書き文字認識は、英語のみです。Textractの制限事項を確認してください。判定が不確かな手書きの訂正は、確認へ回します。印字された金額を、気付かないうちに置き換えさせてはいけません。

複数ページの表では、つながりを確認します。 改ページで行が分かれたり、見出しが繰り返されたり、明細行に見える小計が挿入されたりすることがあります。文書全体を通して、行数、続きの説明、合計を確かめます。MicrosoftのLayoutガイドでも、複数ページを後処理でひとつの表にまとめる方法に明示的に触れています。これは、選んだモデルと表の結合ロジックを試すべき理由です。どのモデルも複数ページの表で必ず失敗する、という意味ではありません。

画質の悪いスキャンには、取り直しの手順が必要です。 ぼけ、端の切れ、圧縮によって失われた情報は、モデルでも確実には復元できません。AWSは高画質の画像を推奨し、理想的には少なくとも150 DPIとしています。また、すでに対応形式のファイルについては、解像度を落とさないよう勧めています。Textractのベストプラクティスを参照してください。原本を保存し、根拠が読めない場合は、より鮮明なものを依頼します。

ページの欠落や、複数文書をまとめたファイルも試します。各項目の形式チェックをすべて通過していても、データ全体が不完全なことはあります。「処理失敗」という大まかな理由だけでなく、「根拠が欠けている」という例外理由も残します。

IDPに期待しすぎてはいけないこと

「文書を読める」ことと、「取引を安全に完了できる」ことは同じではありません。 避けられるはずの誤りを生む、よくある思い込みが三つあります。

第一に、構造化された出力は、検証済みの出力ではありません。返答をスキーマに合わせても、抽出した銀行口座が承認済みの取引先のものだとは証明できません。

第二に、信頼度は、どの業務にも通用する受け入れ方針ではありません。サービスが返すスコア、モデルが自分で示す確信度、自社の文書で測定した正解率は、それぞれ別物です。取り分けた評価用文書の結果と、誤りが与える影響に基づいて、受け入れルールを調整します。モデルが生成した信頼度の数値を、実測した確率として扱ってはいけません。

第三に、修正を保存しても、モデルが再学習するとは限りません。修正履歴は、失敗の原因を調べ、ルール、プロンプト、学習データを改善するために使います。その変更を本番へ出す前に、再評価します。過去に確認した文書を固定した回帰テスト用のセットとして残し、ある取引先での改善の陰で、別の取引先の処理が悪化していないか確かめます。

今すぐ始めるべき企業、待つべき企業、現状を維持すべき企業

繰り返し発生する取り込み業務に、明確な登録先、正誤を確かめられる項目、例外の責任者がそろっていれば、今すぐ動けます。 業務責任者が次に行うのは、実態を反映したサンプルを集め、必須項目を挙げることです。経理責任者なら、最初の出力は下書きデータにし、支払いの承認を切り離します。

開発する側は、要件を満たす最もシンプルな抽出器から始めます。 ひとりで開発する技術者なら、同じ評価用サンプルで、マネージドモデルとLLMを使う方法を比較できます。中堅企業の技術責任者は、本番のデータに接続する前に、根拠へのリンク、確認の責任分担、保存期間のルール、再現可能な評価を求めるべきです。文書のテキストは、あくまで入力データとして扱います。アプリケーションの指示や権限を書き換えさせてはいけません。

何が正しいデータかを定義できず、確認待ちキューの責任者も決まらないなら、購入は待つべきです。 資金調達を済ませた創業者でも、この点が欠けているなら、独自の自動化を発注する前に業務責任者を置きます。安定した帳票を既存のテンプレート処理で確実に扱えているチームには、画像認識モデルが登場したというだけで置き換える理由はありません。

月曜日に着手するなら、文書の種類をひとつ選び、過去のサンプルを集め、確認担当者と受け入れルールを書き出し、導入候補のワークフローから下書き用の登録先へ出力してみます。対象を広げるのは、項目ごとの成績と、残る作業量がそれを正当化してからです。

IDPについてよくある質問

インテリジェント文書処理（IDP）とは何ですか？

文書の分類、情報の抽出と検証、処理後のデータや例外の振り分けを行うワークフローです。業務に役立つ成果物は、原本までたどれる、確認済みのデータです。

OCRとインテリジェント文書処理は何が違いますか？

OCRは画像から文字を読み取ります。IDPには、その文字を業務で使うために必要な分類、項目の抽出、確認、振り分けまで含まれます。OCRは、その中の構成要素になり得ます。

インテリジェント文書処理ソフトは、どれを選べばよいですか？

業務の内容と、確認担当者に残る仕事を基準に選びます。領収書や請求書なら、Dextなどの経理アプリケーションから検討します。独自の取り込み処理なら、人が確認した同じ文書を使って、マネージド型の抽出サービスやLLMのワークフローを評価します。

IdPはAIに含まれますか？

インテリジェント文書処理では、通常の業務ルールとともに、分類や抽出にAIを使うのが一般的です。ただし、別の文脈でIdPと書く場合は、認証を担うアイデンティティプロバイダーを指すこともあり、これは別の概念です。

IDPの主要なサービスには何がありますか？

この記事では、マネージド型の選択肢としてGoogle Document AI、Azure AI Document Intelligence、Amazon Textractを取り上げています。機能の比較であり、市場シェアや精度のランキングではありません。適性は文書とワークフローによって変わります。

文書処理には、どのAIが最適ですか？

必須項目とレコード全体の受け入れ基準を満たし、確認の手間も管理できる範囲に収まるものが、最も適した候補です。変則的なレイアウトをうまく読めるモデルでも、表や欠損項目には追加の確認が必要な場合があります。

ChatGPTより優れたAIはありますか？

繰り返し行う文書の取り込みでは、チャットの回答だけを評価するのではなく、実装したワークフローと現行の業務を比較します。どのモデルを選んでも、想定どおりの項目、原本の根拠、例外処理、管理された登録先が必要です。

Document AIの料金はいくらですか？

Google Document AIの料金は、プロセッサーと処理量によって変わります。試験導入で使う予定のプロセッサーについて、公式料金ページで確認してください。

Google Docsに書いた内容はAIに使われますか？

Googleは、Google Workspaceの顧客データを、許可なく顧客のドメイン外で生成AIモデルの学習に使わないと説明しています。利用中のアカウントと機能については、WorkspaceのAIプライバシーポリシーを確認してください。Google Docsは、この記事で扱うDocument AIとは別のサービスです。

AIを業務のワークフローに取り入れる実践ガイドは、ニュースレターでお届けしています。