LLM・VLMのOCRは従来のAI-OCRと何が違うか。帳票定義なしで読み、承認つきで業務へ流す設計

LLMやVLM（画像も読める言語モデル）でOCRをすると、従来のAI-OCRで必要だった帳票定義がいらなくなります。その代わりに、確信度スコアと決定性を失い、読めない文字をもっともらしく捏造する幻覚が入ります。 だから「どのモデルが一番読めるか」より、読み取り・検証・承認・実行を分けて業務に流す設計の方が、導入の成否を決めます。

この記事は、2026年9月28日時点の各社の公開資料に基づく整理と設計案です。当社が特定製品の読み取り精度を同一条件で実測した結果ではありません。精度の数値は対象帳票と画像品質で大きく変わるため、導入判断は自社の帳票で確かめてください。機密書類を外に出せない場合の選択肢は、ローカルLLMでOCRの記事で扱っています。

この記事の要点

従来OCRは「文字を読む」、AI-OCRは「決めた位置から読む」、LLM・VLMのOCRは「意味を読んで構造化する」技術です。違いは精度の高低ではなく、帳票定義の要否と、失敗の現れ方にあります

LLM・VLMは帳票定義なしで非定型帳票を読めますが、フィールドごとの確信度がなく、同じ入力でも出力が揺れ、読めない箇所を捏造します。クラウドの文書AIサービスは型付きフィールドと確信度を返す点が違います

汎用LLMにPDFを直接渡す方式は、OpenAIが1ファイル50MB、Claudeが1リクエスト32MB・600ページ、Geminiが1,000ページ・1ページ258トークン相当という上限です

業務に流すなら、読み取り（JSON化）、検証（決定的なルールと二重読み取り）、承認（例外だけ人が見る）、実行（システムが登録し、AIは登録しない）を分けます。人が全件を目視する設計に戻さないことが要点です

3世代のOCRを1つの表で比べる

「AI-OCR」という言葉は、機械学習で手書きや活字の認識率を上げた製品と、LLMを搭載した製品の両方に使われています。混同を避けるため、この記事では次の3つに分けます。

	従来OCR	AI-OCR（帳票定義型）	LLM・VLMのOCR
何をするか	文字を文字コードにする	決めた位置・項目を読む	内容を理解して、指定した項目を構造化する
手書き	苦手	対応	対応
非定型帳票（取引先ごとに様式が違う）	不可	苦手。様式ごとに定義が要る	対応。定義なしで項目を探せる
表記揺れ（「請求金額」「ご請求額」「合計」）	不可	定義で吸収	文脈で吸収
確信度スコア	文字単位である	項目単位である製品が多い	ないか、自前で作る
失敗の型	文字化け、認識不能	位置ずれ、定義漏れ	捏造、桁の入れ替え、繰り返し
同じ入力で同じ出力か	はい	はい	保証されない
向く帳票	定型の活字	自社様式、行政様式	取引先ごとに様式が違う請求書・注文書、FAX

3列目の「失敗の型」が、この記事で最も見てほしい行です。従来型は失敗すると「読めなかった」と分かる形で止まります。LLM・VLMは失敗すると、整ったJSONの中に間違った金額が静かに入ります。設計はこの違いを前提に組みます。

「帳票定義が不要」の意味と、代わりに失うもの

帳票定義型のAI-OCRは、「請求金額は右上、請求日は左下」のように読み取り位置を様式ごとに登録します。取引先が100社あれば、様式も100通り近くになり、定義の作成と保守が導入コストの本体でした。

LLM・VLMのOCRは、位置ではなく「項目の意味」を指定します。指定の仕方は3つあります。

自然言語で項目を説明する。 Azure Content Understandingのカスタムアナライザーは、抽出したい項目を平易な言葉で書くだけで始められ、ラベル付きデータを必要としません。Microsoftの選定ガイドは、取引先ごとに様式が違う請求書や納品書のような「バリエーションの多い半構造化文書」に、この方式を推奨しています。
スキーマを渡して構造化出力させる。 OpenAIのStructured Outputsは、JSON Schemaに従った出力を保証し、拒否応答も別フィールドで検出できます。Geminiも文書から表や図を含めて構造化出力へ抽出できます。
事前学習済みの文書AIを使う。 Azure Document Intelligenceの請求書・領収書・本人確認書類モデルや、Google Document AIのプロセッサは、定義なしで共通項目を返します。

一方で、Microsoftの選定ガイド自身が、汎用LLMで自前構築する場合の弱点を明記しています。信頼度と根拠づけは「いいえ（カスタム実装が必要）」、推論と検証は「手動での連携とロジックが必要」です。つまり帳票定義が不要になった分、確信度と検証を自分で設計することになります。これがLLM・VLMのOCRの本当の費用です。

幻覚の具体的な型は、LlamaIndexが本番運用の障害として整理しています。かすれた数字を別の数字として自信を持って出力する、空白の多いページで同じ文字列を繰り返す、表の行と列の対応がずれたまま整った出力になる、という3つは、どのモデルでも起こりえます。

クラウドで帳票を読む3つの入口

クラウドで帳票を読む場合、入口は「文書AIサービス」「汎用LLMへの直接入力」「ローカルOCRモデル」の3つです。

入口	例	返るもの	上限・課金の考え方	向く場面
文書AIサービス	Azure Document Intelligence、Google Document AI	型付きフィールド（日付、通貨、住所など）、確信度、表構造	ページ単価。事前学習済みモデルは定義不要、カスタムは数枚のラベルで学習	請求書・領収書・本人確認書類のような共通様式。確信度で自動化率を管理したい
汎用LLMへの直接入力	OpenAI、Claude、Gemini	指示した形式の文字列やJSON	トークン課金。OpenAIは1ファイル50MB未満でテキストと各ページ画像の両方を送る。Claudeは1リクエスト32MB・最大600ページ（コンテキストが100万トークン未満のモデルは100ページ）。Geminiは50MB・1,000ページ、1ページ258トークン相当	様式が毎回違う、項目が文脈依存、要約や判断まで一緒に頼みたい
ローカルOCRモデル	DeepSeek-OCR、PaddleOCR-VLなど	Markdown、JSON	機材費のみ。外部送信なし	外に出せない書類。詳細はローカルLLMでOCR

3つは排他ではありません。実務では「文書AIサービスで確信度つきの読み取りを取り、汎用LLMには例外の解釈や項目の正規化だけを頼む」という組み合わせが、費用と精度の両方で落ち着きやすい構成です。Microsoftのガイドも、標準様式は文書AI、非構造化文書はLLM型、と使い分けを示しています。

読み取り結果を業務に流す設計

ここからが本題です。OCRの精度が99%でも、残り1%が静かに会計システムへ入る設計では使えません。設計は、AIにLINE配信を任せる前の権限設計と同じ考え方で、AIがやること、システムが確認すること、人が決めることを分けます。

1. 読む：出力を固定し、「読めない」を許す

出力はJSON Schemaで固定します。項目名、型、必須かどうかを決め、Structured Outputsのようにスキーマ準拠を保証する機能を使います。
読めない項目はnullで返すことをスキーマと指示の両方で明示します。推測で埋めさせないための、最も効く一手です。
各項目に「どのページのどの位置から読んだか」を持たせます。文書AIサービスは座標を返します。汎用LLMに頼む場合は、ページ番号と根拠の文字列を一緒に返させます。
1回の処理に上限をかけます。出力トークンの上限、タイムアウト、同じ文字列の繰り返し検知です。VLMの暴走は、ここで止めます。

2. 検証する：決定的なルールで、AIの外から確かめる

AIの出力をAIに検証させても、同じ幻覚を共有します。検証は決定的な処理で行います。

算術の検算。 明細の合計と請求合計、税抜と税込と税率の整合、数量×単価。
マスタ照合。 取引先名、口座、品目コードを自社マスタと突き合わせ、一致しなければ例外にします。
範囲と形式。 日付が処理期間内か、請求書番号の桁数、金額の上限。
二重読み取り。 文書AIサービスと汎用LLM、または従来OCRとVLMの2系統で読み、金額・日付・取引先が一致した項目だけ自動通過させます。確信度が返らないモデルでも、これで「確信度の代わり」を自前で作れます。

検証を通った件数の割合が、Microsoftのガイドで言う「ストレートスルー処理率」です。この率が導入効果そのものなので、最初から測れるようにしておきます。

3. 承認する：人が見るのは例外だけ

人が確認するのは、検証で引っかかった項目だけにします。全件目視に戻した瞬間に、AIを入れた意味がなくなります。
確認画面には、元画像の該当箇所と読み取り値を並べて出します。項目の根拠を持たせるのは、このためです。
承認は「読み取り値の版」に対して行います。承認後に再読み取りで値が変わったら、承認は無効にして戻します。

4. 実行する：AIは登録しない

会計や基幹システムへの登録は、承認済みの値を受け取ったシステム側の処理が行います。AIに登録用のAPIキーを渡す必要はありません。
二重登録を防ぐため、「取引先＋請求書番号」のような冪等キーで登録済みを検知します。読み取りの再実行や通信の再試行で同じ請求書が2回入る事故は、ここで防ぎます。
元画像、抽出JSON、検証結果、承認者と日時を1組で保存します。あとから「なぜこの金額で登録されたか」を辿れることが、監査と改善の両方に効きます。

本番に流す前の受入表

項目	受入条件
読めない項目	推測ではなくnullで返り、例外として人に回る
算術検算	合計・税・数量×単価の不整合が100%検出される
マスタ照合	未登録の取引先が自動通過しない
二重登録	同じ請求書を2回流しても登録は1件
暴走	白紙ページ、極端に長いページで処理が上限で止まる
根拠	承認画面から元画像の該当箇所に1クリックで戻れる
監査	登録済みの1件から、元画像・抽出値・承認者を辿れる
自動化率	ストレートスルー処理率を日次で集計できる

費用は「1枚いくら」より「人が見る枚数」で決まる

クラウドの単価は、文書AIサービスならページ単価、汎用LLMならトークン量で決まります。Geminiは1ページ258トークン相当、OpenAIはテキストと画像の両方を送るため、ページ数に比例して増えます。ただ、実務で最も大きい費用はAPI料金ではなく、人が確認する枚数です。

ストレートスルー処理率が60%と90%では、人の確認工数が4倍違います。モデルの単価差より、検証と二重読み取りで自動通過率を上げる方が、総費用への効きが大きい。API料金を惜しんで二重読み取りをやめると、確認工数で何倍も払うことになります。

ローカルとクラウドの使い分け

外に出せない書類（診療記録、契約書、人事書類）は、ローカルOCRモデルが第一候補です。上限や幻覚の性質はクラウドと同じなので、本記事の設計はそのまま使えます。
様式が毎回違う、量が多いなら、クラウドの文書AIサービスが確信度と表構造を返す分、検証の設計が楽になります。
少量で、判断や要約まで頼みたいなら、汎用LLMへの直接入力が最短です。ただし確信度がないので、二重読み取りかマスタ照合を必ず入れます。

導入前チェックリスト

対象帳票を「定型」「取引先ごとに様式が違う」「手書き・FAX」に分けて枚数を数えた
抽出項目をJSON Schemaで定義し、読めない場合はnullにすると決めた
算術検算とマスタ照合の項目を、AIの外の決定的な処理として書き出した
確信度が返らない方式なら、二重読み取りで代わりを作ると決めた
人が見るのは例外だけで、全件目視には戻さないと関係者で合意した
登録はシステム側が行い、AIに登録権限を渡さないと決めた
冪等キーと監査記録（元画像・抽出値・承認者）の保存先を決めた
ストレートスルー処理率を測る方法を決めた
外に出せない書類があるなら、ローカルOCRを分けて検討した

まとめ

LLM・VLMのOCRは、帳票定義という導入コストを消した代わりに、確信度と決定性と「読めなかった」という失敗の形を失いました。従来のAI-OCRと比べて精度が高いか低いかではなく、失敗の現れ方が変わったのです。だから導入の本体は、読む・検証する・承認する・実行するを分け、検証を決定的なルールで行い、人が見るのを例外だけにする設計になります。この設計ができていれば、モデルは後から入れ替えられます。

よくある質問

LLMのOCRは従来のAI-OCRより精度が高いのですか？

一概には言えません。定型の活字帳票では帳票定義型のAI-OCRが安定し、取引先ごとに様式が違う帳票ではLLM・VLMが定義なしで読めます。違いは精度の高低より失敗の型で、LLM・VLMは読めない箇所を捏造するため、検証工程が必須です。

帳票定義が不要なら、導入は簡単になりますか？

定義の作成と保守はなくなります。その代わり、確信度がないので検証と承認の設計を自分で作ることになります。Microsoftの選定ガイドも、汎用LLMで自前構築する場合は信頼度と検証を手動で実装する必要があると明記しています。

汎用LLMにPDFを直接渡すときの上限は？

2026年9月28日時点の公開資料では、OpenAIは1ファイル50MB未満、Claudeは1リクエスト32MBで最大600ページ（コンテキストが100万トークン未満のモデルは100ページ）、Geminiは50MBまたは1,000ページで1ページが258トークン相当です。大きな帳票はページ分割か、各社のFiles APIで参照する形にします。

読み取り結果を会計システムに自動登録してもよいですか？

AIが直接登録する構成は避けます。検証と承認を通った値をシステム側の処理が登録し、取引先と請求書番号のような冪等キーで二重登録を防ぎます。元画像、抽出値、承認者を1組で残しておくと、あとから辿れます。

この記事に関連するサービス

請求書・申込書・FAX帳票の読み取りから、検証・承認・基幹システムへの登録までを、AIエージェント開発として承っています。「うちの帳票で自動化率がどこまで出るか」という段階のご相談も、同じ窓口からどうぞ。

AIエージェント開発のサービス・相談窓口を見る