生成AIによるOCR実施例の紹介
従来のOCRから生成AIを活用した最新のOCR技術への変遷を解説。Gemini 2.5 ProとGemini 2.0 Flash Liteを用い、架空の請求書PDFから構造化データ(JSON)を抽出する実例を通して、モデルによる精度差や業務適用のポイントを紹介します。

1. 導入
OCR(Optical Character Recognition、光学文字認識)は、紙やPDFに含まれる文字をデータに変換する技術です。
請求書処理などの業務では、単に文字を読むだけでなく「請求日」「請求先」「明細」「合計金額」といった記載内容を構造化データに変換することが重要になります。
従来のOCRは「文字を読む」ことに特化していましたが、近年は深層学習や生成AIの発展により、文書全体を理解して必要な情報を抽出・整理することが可能になっています。
本稿では、OCRの歴史と代表的な手法を整理したうえで、最新の生成AIを活用した請求書処理の実例を紹介します。
2. OCRの歴史の紹介
OCRは「光学OCR」と呼ばれ、もともとは専用フォントを読み取る仕組みから始まりました。現在では深層学習や生成AIと融合し、非定型帳票や契約書処理にも対応できるようになっています。
| 時期 | 技術の特徴 | 代表例 | ポイント |
|---|---|---|---|
| 1960年代〜 | 光学OCR(専用フォントOCR-A/B、機械読み取り装置) | OCR-Aフォント(1966年発表。その後ANSI/ISOで規格化)、郵便番号読み取り機(1968年) | 郵便番号や銀行小切手など限定用途で利用開始 |
| 1980〜1990年代 | PC向けOCRソフト、パターンマッチングや初期ニューラルネット | Kurzweil Reading Machine、ABBYY FineReader | 活字の多様化に対応、オフィス利用が広がる |
| 2000年代 | オープンソースOCRの普及 | Tesseract(1980年代HP開発 → 2005年OSS化 → 2006年Google継続開発) | 無料で高精度OCRが普及 |
| 2010年代前半 | スマホOCR、深層学習の導入 | CNN/RNN応用、CamScannerなどアプリ普及 | 手書き認識の精度向上、クラウドOCR登場 |
| 2010年代後半 | クラウドOCRサービスの普及 | Google Vision API, AWS Textract, Azure Form Recognizer | OCR+レイアウト解析、表やフォーム抽出に対応 |
| 2020年代前半 | AI-OCR(深層学習の商用化、IDPの登場) | Google Document AI, Azure Document Intelligence | 非定型帳票の精度向上、構造化も支援 |
| 2023年〜現在 | 生成AIとOCRの融合(文脈理解・自然言語指示で抽出) | Gemini, GPT-4, Claude | OCR結果をLLMで理解・構造化、非定型帳票処理が急速に普及 |
3. 主要な手法の紹介
| 技術分類 | 概要 | 代表例 | 時代背景 |
|---|---|---|---|
| ルールベース | 座標やキーワード指定による抽出。フォーマットが変わると対応できない。 | 古い帳票OCRシステム | 1960〜2000年代に主流 |
| 機械学習 | 特徴量を人が設計し分類器で学習。SVMなどは1990年代後半以降に登場。 | 旧OCRソフト、Tesseract初期版 | 1990年代後半〜2000年代に利用 |
| 深層学習 | ニューラルネットが特徴量も自動学習し、高精度な文字認識を実現。 | PaddleOCR, Google Vision API, AWS Textract | 2010年代半ば〜現在の主流 |
| 生成AI併用 | OCR結果をLLMが文脈理解し、必要項目を抽出・構造化。 | Gemini, GPT-4, Claude | 2023年以降に急速に普及 |
4. 代表的なツール/サービス一覧
| 分類 | ツール/サービス | 提供元 | 特徴 |
|---|---|---|---|
| OSS / 無料系 | |||
| Tesseract | Google継続開発(元HP開発) | 無料で広く利用されるOCRエンジン。多言語対応だがレイアウト解析は弱め。 | |
| PaddleOCR | Baidu | CNN/Attentionベース。80+言語対応、表や縦書き・複雑レイアウトに強い。 | |
| クラウドOCR / IDP | |||
| Google Document AI | 請求書・契約書向けプロセッサーを備える。IDP(インテリジェント文書処理)の代表例。 | ||
| AWS Textract | Amazon | 表やフォーム抽出に強み。 | |
| Azure Document Intelligence | Microsoft | 契約書解析やMicrosoft 365連携に適したサービス。 | |
| 生成AIモデル | |||
| Gemini | マルチモーダル対応。OCR結果を文脈理解して指定項目抽出。 | ||
| GPT | OpenAI | 同上。 | |
| Claude | Anthropic | 同上。 |
5. 例:Geminiによる請求書のJSON化
ここでは実際に、架空の不動産会社の請求書PDFを対象に、生成AIを用いて必要な項目を抽出してみます。
重要な点として、生成AIの出力は常に正確とは限らず、誤認識や取り違えが発生する可能性があるということです。
その特性を理解するため、ここでは Gemini 2.0 Flash Lite と Gemini 2.5 Pro を用い、同じプロンプトを与えた際の結果を比較します。
使用したプロンプト
以下のプロンプトと請求書PDFを生成AIに投入し、請求書PDFから指定項目を抽出しました。
#命令 あなたは請求書画像を読み取り、以下の項目を必ずJSON形式で抽出してください。 JSON以外のテキストは出力しないでください。
#抽出する項目
請求番号(invoice_no)
請求日(invoice_date)
発行元会社名(issuer)
請求先会社名(client)
明細(items)・項目名(name)・数量(quantity)・単価(unit_price)・金額(amount)
小計(subtotal)
消費税額(tax)
合計金額(税込)(total)
備考(note)
#出力形式
JSON形式のみを返す
日付は YYYY-MM-DD 形式
金額は整数(カンマを除去)
数量や単価が欠けている場合は null を入れる
OCRで読み取った会社名や項目名をそのまま出力する(例:「ジェネレート不動産株式会社」)
#出力例
{
"invoice_no": "INV-2508-101",
"invoice_date": "2025-08-31",
"issuer": "ジェネレート不動産株式会社",
"client": "ディフュージョン開発合同会社",
"items": [
{"name": "賃料", "quantity": 1, "unit_price": 250000, "amount": 250000},
{"name": "共益費", "quantity": 1, "unit_price": 30000, "amount": 30000}
],
"subtotal": 280000, "tax": 28000,
"total": 308000,
"note": null
}
入力ファイル(サンプル請求書)

出力比較
Gemini 2.5 Pro の結果
{
"invoice_no": "INV-2508-102",
"invoice_date": "2025-09-02",
"issuer": "株式会社 日本サンプル",
"client": "株式会社サンプル不動産 渋谷支社",
"items": [
{ "name": "修繕工事費(部材)", "quantity": 2, "unit_price": 62880, "amount": 125760 },
{ "name": "修繕工事費(工賃)", "quantity": 1, "unit_price": 66800, "amount": 66800 },
{ "name": "水道料金", "quantity": 1, "unit_price": 8100, "amount": 8100 },
{ "name": "ガス料金", "quantity": 1, "unit_price": 4200, "amount": 4200 },
{ "name": "通信回線費", "quantity": 1, "unit_price": 39770, "amount": 39770 },
{ "name": "共益費", "quantity": 1, "unit_price": 46350, "amount": 46350 },
{ "name": "賃料", "quantity": 1, "unit_price": 77170, "amount": 77170 },
{ "name": "管理委託料", "quantity": 1, "unit_price": 51450, "amount": 51450 },
{ "name": "駐車場代", "quantity": 1, "unit_price": 74060, "amount": 74060 },
{ "name": "巡回点検費", "quantity": 1, "unit_price": 25640, "amount": 25640 },
{ "name": "エレベーター保守料", "quantity": 1, "unit_price": 74620, "amount": 74620 },
{ "name": "廃棄物処理費", "quantity": 1, "unit_price": 53020, "amount": 53020 },
{ "name": "消防設備点検費", "quantity": 1, "unit_price": 28670, "amount": 28670 },
{ "name": "清掃費(共用部)", "quantity": 1, "unit_price": 87680, "amount": 87680 },
{ "name": "消耗品費", "quantity": 1, "unit_price": 15720, "amount": 15720 },
{ "name": "鍵交換費", "quantity": 1, "unit_price": 2830, "amount": 2830 }
],
"subtotal": 781840,
"tax": 78184,
"total": 860024,
"note": null
}
Gemini 2.0 Flash Lite の結果
{
"invoice_no": "INV-2508-102",
"invoice_date": "2025-09-02",
"issuer": "株式会社サンプル不動産 渋谷支社",
"client": "三菱UFJ銀行",
"items": [
{ "name": "修繕工事費(部材)", "quantity": 2, "unit_price": 62880, "amount": 125760 },
{ "name": "修繕工事費(工賃)", "quantity": 1, "unit_price": 66800, "amount": 66800 },
{ "name": "水道料金", "quantity": 1, "unit_price": 8100, "amount": 8100 },
{ "name": "ガス料金", "quantity": 1, "unit_price": 4200, "amount": 4200 },
{ "name": "通信回線費", "quantity": 1, "unit_price": 39770, "amount": 39770 },
{ "name": "共益費", "quantity": 1, "unit_price": 46350, "amount": 46350 },
{ "name": "賃料", "quantity": 1, "unit_price": 77170, "amount": 77170 },
{ "name": "管理委託料", "quantity": 1, "unit_price": 51450, "amount": 51450 },
{ "name": "駐車場代", "quantity": 1, "unit_price": 74060, "amount": 74060 },
{ "name": "巡回点検費", "quantity": 1, "unit_price": 25640, "amount": 25640 },
{ "name": "エレベーター保守料", "quantity": 1, "unit_price": 74620, "amount": 74620 },
{ "name": "廃棄物処理費", "quantity": 1, "unit_price": 53020, "amount": 53020 },
{ "name": "消防設備点検費", "quantity": 1, "unit_price": 28670, "amount": 28670 },
{ "name": "清掃費(共用部)", "quantity": 1, "unit_price": 87680, "amount": 87680 },
{ "name": "消耗品費", "quantity": 1, "unit_price": 15720, "amount": 15720 },
{ "name": "鍵交換費", "quantity": 1, "unit_price": 2830, "amount": 2830 }
],
"subtotal": 781840,
"tax": 78184,
"total": 860024,
"note": null
}
抽出結果の比較(サマリー)
結果としては(たった1サンプルの結果であり業務適用に際してはよりしっかりとした精度検証は必要だが)、最新モデルの2.5 Proは誤りなく指定した項目を抽出できているが、2.0 Flash Liteは日本語の項目で間違いが起きやすい。
数値は両モデルで一致。
差が出るのは 固有名詞(発行元/請求先)。2.5 Pro は安定、2.0 Flash Liteは混同が起きやすい。
| 観点 | Gemini 2.5 Pro | Gemini 2.0 Flash Lite |
|---|---|---|
| 発行元 / 請求先の抽出 | 正しく区別:・issuer=「株式会社 日本サンプル」・client=「株式会社サンプル不動産 渋谷支社」) | 混同あり:・振込先ブロックの 「三菱UFJ銀行」 を client として誤認・issuer と client の入れ替え |
| 明細の整合性(amount = quantity × unit_price) | 全行一致 | 全行一致 |
| 小計 / 税 / 合計 | 一致(781,840 / 78,184 / 860,024) | 一致(781,840 / 78,184 / 860,024) |
| 出力フォーマット | 指定JSONスキーマに準拠 | 指定JSONスキーマに準拠 |
6. 業務適用に向けたコメント
OCR精度は生成AIのモデル性能に大きく依存します。高精度なモデルほど利用料金が高いため、品質とコストのバランスを考える必要があります。
生成AIベースのOCRでは、プロンプト設計(プロンプトエンジニアリング)が精度に直結するため、業務要件に合わせた工夫が求められます。
精度をさらに高める方法として、AI-OCR(深層学習)と生成AIを組み合わせるハイブリッド方式も有効になります。
また、業務適用で非常に重要な点として日本語手書きに適用できるかという観点がありますが、荒れた手書きで検証してみたところ実用に耐えない結果になったので、それなりのチューニングが必要になりそうです。


