紙の請求書や申込書をシステムに取り込みたい、という相談は中小企業の現場で最も多いテーマのひとつです。ここで必ず出てくるのが「OCRでやるのか、生成AIに読ませるのか」という問いです。結論から言うと、どちらが優れているかという比較には答えがありません。書類が定型か非定型か、そして読み取り結果を誰がどこまで確認するかで、選ぶべき道具は変わります。この記事では、その切り分け方と、実装で詰まりやすい箇所を整理します。
OCRと生成AIは「読む」の中身が違う
まず用語を揃えます。
- OCR（光学文字認識）：画像の中の文字を文字コードに変換する技術。「この位置にある黒い点の並びは『5』である」と判定するところまでを担います。
- AI-OCR：OCRに機械学習を組み合わせ、帳票のレイアウト認識や手書き文字の読み取り精度を高めた製品群の総称。多くは「どの欄が請求金額か」をテンプレートや学習で覚えます。
- 生成AI（LLM／大規模言語モデル）：文章の意味を扱うモデル。近年は画像も直接入力できるマルチモーダルモデルが一般的になり、帳票画像をそのまま渡して「請求元と税抜金額をJSONで出して」と指示できます。
違いを一言でいえば、OCRは文字を写す技術で、生成AIは意味を解釈する技術です。写すだけなら安定して速く安く済みますが、「この書類のどこが納期なのか」を状況から判断するのは苦手です。逆に生成AIは解釈が得意な反面、読めない部分を文脈から埋めてしまう（ハルシネーション）リスクを抱えます。
定型と非定型を分ける基準
「定型」という言葉は曖昧に使われがちです。実務では次の3点で判定すると迷いません。
| 観点 | 定型書類 | 非定型書類 |
|---|---|---|
| レイアウト | 発行元が自社または少数で、欄の位置が固定 | 取引先ごとに様式が異なり、毎月新しい様式が増える |
| 項目の名前 | 「御請求金額」など表記が揃っている | 「合計」「ご請求額」「Total」など表記がばらつく |
| 抽出したい情報 | 欄の中の値をそのまま取る | 複数箇所を突き合わせて意味を判断する必要がある |
自社の申込書、定期的に届く同一フォーマットの検針票、社内の作業日報などは定型側です。一方、取引先が数百社ある請求書、受領書、契約書、手書きのメモが混じる現場報告書は非定型側に入ります。
ここで重要なのは、一括りに「請求書」と呼ばず、発行元の数で数えることです。請求書でも発行元が5社なら定型として扱えますし、社内書類でも部署ごとに様式が違えば非定型です。
どちらを選ぶか — 判断の目安
| 条件 | 向いている方式 | 理由 |
|---|---|---|
| 様式が固定、月数千枚以上 | OCR（テンプレート型） | 1枚あたりの処理単価が低く、結果が安定して再現する |
| 様式が固定、手書きが多い | AI-OCR | 手書きの文字認識に特化した学習が効く |
| 様式が多様、枚数は中程度 | 生成AI（マルチモーダル） | テンプレートを作らずに項目の意味で拾える |
| 文章から要約・分類したい | 生成AI | 「この報告書はクレームか問い合わせか」の判断はOCRでは不可能 |
| 金額・数量の正確性が最優先 | OCR＋ルール検証 | 生成AIの出力は桁の取り違えを文脈で補ってしまうことがある |
実務では「どちらか一方」ではなく、OCRで文字を起こし、その結果のテキストを生成AIに渡して項目に振り分けるという二段構成が有効な場面が多くあります。画像を直接モデルに渡すよりトークン（モデルが扱う文字の単位）消費が少なく、コストも読みやすくなります。費用の考え方は呼び出し回数と文脈量から設計するコスト削減の整理が参考になります。
実装で詰まる5箇所
- スキャン品質のばらつき：傾き、折り目、裏写り、影。読み取り精度の問題だと思っていたら、入り口の画像品質が原因だったというケースは少なくありません。解像度と傾き補正の前処理を先に入れるだけで改善することがあります。
- 「空欄」と「読めなかった」の区別：生成AIは空欄を見ると、それらしい値を書いてしまうことがあります。出力形式に「不明」を必ず用意し、推測を禁じる指示を明示する必要があります。
- 信頼度の扱い：OCRは文字ごとの信頼度スコアを返せる製品が多い一方、生成AIの出力には標準的な確信度がありません。人の目視確認に回す基準をどう作るかは、設計の早い段階で決めるべき論点です。
- 複数ページ・複数伝票の分割：1つのPDFに複数社の請求書が混在している、明細が次ページに続く、といった構造の判定は想像以上に手間がかかります。
- 個人情報を含む書類の取り扱い：履歴書、健康診断票、申込書などは、どのモデルにどこまで渡してよいかの線引きが必要です。処理を社外のAPIに出すか社内に置くかは、クラウドAIか社内設置かの判断軸の論点とそのまま重なります。
精度は「何%」ではなく運用で決める
読み取り精度を「95%」と一言で語ると、現場で必ず揉めます。文字単位の正解率なのか、項目単位なのか、1枚まるごと正しい割合なのかで数字は大きく変わるからです。
発注側が先に決めておくとよいのは次の3点です。
- 間違えたときのコスト：金額の誤りが支払事故につながるのか、後工程で必ず人が見るのか
- 目視確認に回す条件：合計金額が明細の和と一致しない、日付が未来、必須項目が空、といったルールで機械的に弾く
- 合否の基準：必ず満たすべき条件と、達成を目指す目標値を分けて書く
この合否の書き方は、検収を必達条件と目標値の二段構えで決めるという考え方が適用できます。また、どの様式でどの項目が落ちやすいかを把握するには、代表的な書類を集めた検証用のデータを事前に用意しておくことが欠かせません。
なお、スキャンした書類を紙の代わりに保存する場合は、電子帳簿保存法のスキャナ保存の要件を確認する必要があります。解像度や検索要件、タイムスタンプの扱いなどが定められており、要件は改正で変わることがあるため、国税庁の公表資料や顧問税理士への確認をおすすめします。読み取り精度の話と保存要件の話は別問題なので、分けて検討してください。
まとめ
紙の読み取りをどう作るかは、次の順番で考えると整理できます。
- 書類を発行元の数と様式の数で数え、定型と非定型に仕分ける
- 定型かつ大量ならOCR、手書きが多ければAI-OCR、様式が多様なら生成AIを軸にする
- 多くの現場ではOCRで文字起こし、生成AIで項目振り分けの二段構成が現実的
- 間違えたときのコストから、目視確認に回す条件を先に決める
- 保存要件は読み取り精度とは別論点として確認する
「最新のモデルなら全部読める」という前提で始めると、様式が増えた3か月後に崩れます。先に書類を数え、落ちたときの手当てを設計しておくことが、結果として最短距離になります。