この記事で分かること
- OCR(画像やPDFの文字を読み取る技術)と文書AI(表や項目の構造まで解釈して取り出す仕組み)の違い
- 請求書や決算書などの金融文書で精度が下がりやすい典型的な原因(罫線なし表、符号、単位など)
- 整数設例で見る、機械的な合計突合で発見できる誤りと発見できない誤りの違い
- 電子帳簿保存法のスキャナ保存制度について、一次情報で確認できる範囲
30秒で分かる定義
OCRとは画像やPDFに写った文字をテキストデータとして読み取る技術をいい、文書AIとは読み取った内容を表・項目・見出しといった構造として解釈し、金額や日付などの項目単位で取り出す仕組みをいいます。英語では OCR(Optical Character Recognition)、Document AI(読み方:おーしーあーる・ぶんしょえーあい)と呼ばれ、光学文字認識、AI-OCR、インテリジェントドキュメント処理(IDP)などとも言い換えられます。OCRが「文字が読めること」を担うのに対し、文書AIは「その文字がどの項目の値か」までを解釈する点が異なり、両者はセットで使われるのが一般的です。
なぜファイナンス実務で重要なのか
経理・財務の実務では、請求書、領収書、契約書、決算書、銀行取引明細、有価証券報告書の表など、紙またはPDFでやり取りされる文書が今なお大量に存在します。転記作業をOCR・文書AIに置き換えれば入力工数を減らせる可能性がある一方、AIに読ませる財務データの作り方にあるように、読み取り対象の作られ方次第で後工程の精度は左右されます。生成AIで有価証券報告書・決算資料を読む場面でも資料の渡し方や検証手順が同様に問われます。OCR・文書AIは読み取り結果を無条件に正しいものとして扱ってよい道具ではありません。
仕組み:OCRと文書AIの役割分担
処理は大きく2段階に分かれます。まずOCRが画像・PDFの文字を認識してテキスト化し、次に文書AIがそのテキストの位置関係やレイアウトから「どの数字が請求金額で、どの数字が消費税額か」といった項目の対応関係を解釈します。機械学習を基盤とし、大量の文書パターンを学習したモデルが初見の帳票でも項目の位置を推定する仕組みです。
| 段階 | 役割 | 失敗すると起きること |
|---|---|---|
| OCR(文字認識) | 画像・PDFの文字をテキスト化する | 数字の読み違い、文字化け、欠落 |
| 文書AI(構造解釈) | テキストを項目・表構造に対応づける | 列のずれ、符号の取り違え、単位の見落とし |
なおXBRLのように項目ごとにタグ付けされた構造化データや、EDINETで提供される開示データは、この読み取り工程自体が不要か大幅に簡略化されます。OCR・文書AIが必要になるのは、紙やスキャン画像、非構造のPDFのように機械が項目を認識できない文書に限られます。
整数設例で確認する
架空の設例。ある会社が、取引先から届いた請求書200件をOCR・文書AI経由で処理しました。処理後に人が全件を見直したところ、正しく処理できていたのは185件、何らかの誤りがあったのは15件でした(185+15=200件、検算一致)。
15件の誤りの内訳は、金額の符号(△表記などのマイナス)を取り違えたもの3件、金額の単位(千円・円)を取り違えたもの2件、金額欄と摘要欄などの列がずれたもの4件、文字自体が読み取れず空欄・記号になったもの6件でした(3+2+4+6=15件、検算一致)。項目単位での正答率は 185 ÷ 200 = 92.5%です。
ここで「各請求書の小計+消費税=請求金額」という機械的な合計突合を行うと、符号3件・単位2件・文字認識エラー6件の計11件は合計が合わなくなるため検算で検出できます。一方、列がずれた4件は金額自体は正しく転記され合計が一致してしまい、検算だけでは検出できません(11+4=15件、検算一致)。検算で発見できる誤りと、目視でしか発見できない誤りがあることがわかります。
単位の取り違えが金額に与える影響も見ておきます。ある請求書の金額欄が「1,250千円」(=1,250,000円)のところ、単位の「千円」を見落として「1,250円」と記録すると、実際の1,000分の1、998,750円の過少計上になります。件数は200件中2件、全体の1%にすぎませんが、金額のずれは最大で1,000倍に達し、件数の少なさと影響の大きさは釣り合いません。単位の取り違えは、金額の妥当性(前期比・平均値との乖離)で検証する必要があります。
精度を下げる典型的な要因
「文字が読めること」と「表として正しく取れること」は別の問題です。金融文書のOCR・文書AI処理では、次のような要因で誤りが生じやすくなります。
| 要因 | 起きやすい誤り |
|---|---|
| 罫線のない表・結合セル・複数段組 | どの数字がどの項目に属するか列がずれる |
| △やカッコによるマイナス表記 | 符号を取り違え、プラスとマイナスが逆になる |
| 単位(千円・百万円)が表外の注記にある | 単位を見落とし、桁数を大きく誤る |
| 桁区切りのカンマ、全角・半角の混在 | 数字の一部を読み飛ばす、別の数字と誤認する |
| 手書き・押印・スキャンの傾き | 文字そのものの認識精度が下がる |
符号と単位の誤りは、件数が少なくても金額を大きく間違える方向に働きます。誤読自体を減らす工夫だけでなく、誤読が起きても金額の異常として検出できる仕組みを併せて用意することが実務上のポイントです。
実務での使い方
- 請求書・領収書の経費精算や支払処理で金額・日付・取引先を自動抽出し、入力工数を削減する。月次決算の早期化にAIを使う場面でも、証憑処理の自動化として位置づけられます
- 抽出結果をそのまま会計処理に使わず、小計・合計が一致するか、前期比が異常でないか、貸借が一致するかを機械的に検算する工程を必ず挟む
- 検算で不一致となった件だけを人が目視確認する。全件目視は現実的でないため検算で落ちたものだけ人が見る設計にする
- 検証工程の考え方は生成AI出力の検証手順のハルシネーションの見抜き方・数値照合の型と共通します
実務家が確認するポイントとよくある誤解
誤解1:「文字がきれいに読めていれば、表としても正しく取れている」→ 誤りです。文字自体は正しく読めても、列のずれや符号の取り違えのように構造の解釈段階で誤りが生じることがあります。
誤解2:「空欄や不明な項目は、AIが文脈から埋めてくれるので安心」→ むしろ注意が必要です。文書に実際には書かれていない値をAIが推測で埋めると、ハルシネーションと同じ構造の問題になります。空欄は空欄のまま検出し、人が原本を確認する運用が基本です。
確認ポイント:精度を「読み取れた文字数の割合」だけで評価せず、金額として正しく取れたかという観点で評価しているかを確認します。
日本実務での扱い
国税庁は、電子帳簿保存法に基づき、紙で受領した請求書・領収書などの国税関係書類をスキャナ等で画像データ化して保存する「スキャナ保存制度」を公表しています。国税庁の制度パンフレット(令和5年7月版)では、保存画像の解像度について25.4mmあたり200ドット以上、階調について256階調(24ビットカラー)以上という基準が示されています。また令和4年(2022年)1月1日の改正で、スキャナ保存の事前承認制度は廃止されています。
これら以外の要件(タイムスタンプの付与方法・期限、検索要件の詳細、書類区分ごとの取扱いなど)は、確認できた一次情報の範囲を超えるため本記事では立ち入りません。具体的な適用要件・期限は、国税庁「電子帳簿保存法一問一答【スキャナ保存関係】」など最新の公表資料で確認してください。自社への適用可否の判断は専門家への確認が必要です。
面接・実務で問われるポイント
Q:OCRと文書AIの違いを説明してください。
「OCRは画像やPDFの文字をテキストとして読み取る技術です。文書AIは、読み取った文字が請求金額や日付などどの項目に対応するかまで、表や見出しの構造から解釈して取り出す仕組みです。」
深掘りでは「精度をどう担保するか」が問われます。開示書類を生成AIで読む場合と同様に、抽出結果を無条件に使わず、合計突合など機械的な検算工程を通す設計かまで説明できるかが分かれ目です。
よくある質問(FAQ)
Q. OCRの精度が高ければ、文書AIの結果も信頼できますか。
A. そうとは限りません。文字自体は正しく読めても、表の列がずれたり符号や単位を取り違えたりすると、項目単位の値としては誤りになります。両者は別に確認する必要があります。
Q. すべての読み取り結果を人が目視確認する必要がありますか。
A. 全件目視は現実的でないことが多く、小計・合計の一致や前期比の異常値といった機械的な検算を先に行い、不一致となった件だけを人が確認する運用が一般的です。
出典・参考(2026-08-16確認)
- 国税庁「電子帳簿等保存制度特設サイト|スキャナ保存関係」 https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/tokusetsu/03.htm
- 国税庁「はじめませんか、書類のスキャナ保存」(令和5年7月)(PDF) https://www.nta.go.jp/publication/pamph/sonota/0018004-061_02.pdf
- 国税庁「電子帳簿保存法一問一答【スキャナ保存関係】」 https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/07scan/index.htm