はじめに
OCR（光学文字認識）は、紙の書類や画像からテキストを抽出する技術としてとても便利ですが、
実務で使おうとすると 「フォーマットが違うと読めない」「精度が安定しない」 といった課題がつきまといます。
「フォーマット自由」をうたうサービスもありますが、どうしても高額になりがちですし、
提供されているAPIの仕様が複雑で、システムに組み込むのが大変という問題もあります。
それでも、これまでは各社が提供する専用OCRサービスの中から選ぶしかありませんでした。
しかし最近、生成AIの進化によって状況が大きく変わりつつあります。
画像の読み取り精度が急速に向上し「OCRというカテゴリそのものが、生成AIに吸収されていくのでは？」と感じるほどの勢いがあります。
（まるでスマホがカメラや音楽プレーヤーなど全てを飲み込んでいったように。）
そこで今回は、生成AIを使って OCRをどこまで自動化できるのか を検証しました。
特に、実務で重要になる 「フォーマット自由」「システムへの組み込み」「コスト」という観点で、どこまで理想に近づけるのかを探ります。
実験概要
以下の条件で複数の生成AIを比較しました。
- 使用モデル：Gemini、ChatGPT、Claude
- 入力形式：領収書、レシートなどの実務書類（※フォーマット不定）
- プロンプト設計：指示を最小限にし、フォーマットに依存しない読取を目指す
- システムへの組み込み：kintoneを例に、どのように連携できるかも検証
OCRの前処理など何もせず、生成AIに全部丸投げです。
プロンプト
添付ファイルの 注文書 / 請求書 / 領収書 をOCRで読み取ってください。
回転補正
文字の向きが横向き・逆向きの場合は、全体を回転補正してから読み取ること。
ファイル種類の判定
注文書 / 請求書 / 領収書 のいずれかを判定すること。
判定できない場合は読み取らない。
種類ごとの読取項目
判定した種類に応じて、以下の項目を読み取ること。
【注文書の場合】
・ファイルの種類（"注文書"固定）
・納品先TEL（半角数字と半角ハイフンで出力）
・納品先FAX（半角数字と半角ハイフンで出力）
・納品先会社名（商品の送り先会社名、なければ備考や発注元から推測、文字列で出力）
・納品先住所（商品の送り先住所、なければ備考や発注元から推測、文字列で出力）
・納品希望納期（年月日西暦'YYYY-MM-DD'形式で出力）
・納品希望時間帯（文字列で出力）
・備考（文字列で出力）
・注文書番号（半角英数で出力）
・発行元会社名（本注文書の送付元会社名、文字列で出力）
・発行元TEL（本注文書の送付元TEL、半角数字と半角ハイフンで出力）
・注文商品（以下、複数）
・商品品番（文字列で出力）
・商品名（文字列で出力）
・商品数（半角整数で出力）
【請求書の場合】
・ファイルの種類（"請求書"固定）
・請求書番号（半角英数で出力）
・請求日（年月日西暦'YYYY-MM-DD'形式で出力）
・支払期限（年月日西暦'YYYY-MM-DD'形式で出力）
・発行元会社名（文字列で出力）
・発行元住所（文字列で出力）
・発行元TEL（半角数字と半角ハイフンで出力）
・請求先会社名（文字列で出力）
・請求先住所（文字列で出力）
・税込合計（半角整数で出力）
・消費税（半角整数で出力）
・明細（以下、複数）
・明細名（文字列で出力）
・明細数量（半角整数で出力）
・明細金額（半角整数で出力）
【領収書の場合】
・ファイルの種類（"領収書"固定）
・領収書番号（半角英数で出力）
・発行日（年月日西暦'YYYY-MM-DD'形式で出力）
・発行元（文字列で出力）
・領収金額（半角整数で出力）
・支払方法（文字列で出力）
・備考（文字列で出力）
追加のプロンプト（精度向上）
【3回読み取り → 統合ルール】
同じファイルを3回読み取り、項目ごとに以下のルールで最終値を決定する。
・値が取得できた方を優先
・2回以上同じ値なら、それを採用
・3回とも異なる場合は、最も類似した値を推測して採用
追加のプロンプト（システム組み込み用）
【出力形式】
すべての値を文字列とし、JSON形式で出力する。
種類が判定できなかった場合は { "ファイルの種類": "不明" } のみ返す。
読み取りファイル例
上記を含め、手書きやフリーハンドを混ぜて7種類用意しました。
結果と考察
Geminiはかなり正確に読めています。
先ほどの3例のファイルは、100%読めてました。全部で7通り試しましたが、間違いは1か所だけでした。
ChatGPT / Claude は、ほとんどのファイルで1～3か所ほど間違えていて、現段階ではGeminiがやはり一歩抜きんでていそうです。画像の読み取りはGeminiが評価高いですし、評判通りですね。
間違い箇所としては、漢字の読み取り精度が低い、送り元/送り先を混同するor見つけられない、といったものが多かったです。
確かに、先ほどの例の3つ目（請求書）など、明示的に書いていないものが多いですからね、逆に読めているGeminiが不思議なくらいです。
Geminiが読取れなかったのは、文字の上に印鑑が重なっているもので、こういうのは仕方ないような気もします。
間違えたものを【3回読み取り → 統合ルール】を追加して再度読み直してみましたが、それほど精度は上がりませんでした。生成AIは実行するたびに結果が変わるので、たまたま読めなかった場合の救済としては多少機能するのではと思っていますが、今回は効果が実感できませんでした。
今からOCR用途で利用するなら、Geminiをベースにして、補助的に他の生成AIを使用するものアリかなと思いました。
システムに組み込むには？
プロンプトについて
今回、プロンプトの最後に【出力形式】でJSON形式での出力指示を追加していましたが、これがシステムに組み込む際にはほぼ必須かなと思います。形式はJSONでなくてもいいのですが、プログラムで解析するには、決まった形式での出力を指示する必要があります。
例えば、先ほどの読み取りファイル例の1つ目の場合、下記のような文字列が返ってきますので、これをプログラムで処理します。
{
"ファイルの種類": "注文書",
"納品先TEL": "042-563-****",
"納品先FAX": "042-567-****",
"納品先会社名": "尾崎 ＊＊",
"納品先住所": "東京都東大和市中央4-***",
"納品希望納期": "",
"納品希望時間帯": "",
"備考": "決済方法 銀行振込（10月×日頃振込予定） 代金引換",
"注文書番号": "",
"発行元会社名": "尾崎 ＊＊",
"発行元TEL": "042-563-****",
"注文商品": [
{
"商品品番": "",
"商品名": "オーパスワン",
"商品数": "10000"
}
]
}
kintoneに組み込む場合の例
例えばkintoneに組み込む場合、下記のような流れが考えられます。
例１：
kintoneでレコード保存時にWebhook、またはボタンクリックでWebAPIにリクエスト送信
→Webサーバーで受け取る
→kintoneからAPIで添付ファイルを取得
→生成AIのAPIを使用してOCR処理
→kintoneのレコードに結果を保存
例２：
バッチ処理の定期処理で実行
→kintoneアプリからAPIで未処理のレコードを検索
→kintoneからAPIで添付ファイルを取得
→生成AIのAPIを使用してOCR処理
→kintoneのレコードに結果を保存
生成AIのサービスについて
生成AIをプログラムから使用するためには、APIキーを取得する必要があります。
Geminiの場合
Geminiの場合は、Google Cloud APIs でAPIキーを作成するのが最も手軽かなと思います。
https://console.cloud.google.com/apis/
有効にするAPIは下記いずれか。
- Generative Language API（小規模or検証用）
- Vertex AI API（法人での本番運用の場合はこちら）
OpenAI（ChatGPT系）の場合
また後日記載します。
Claudeの場合
また後日記載します。
サーバー処理について
サーバー処理は、今なら GAS（Google Apps Script）/ Azure / AWS / GCP などのクラウドサービスを利用するのが便利ですね。
おわりに
最後は駆け足になってしまいましたが、参考になりましたでしょうか。
生成AIによるOCRは、実験レベルではかなりの精度を出せるようになってきたように思います。しかし、業務に組み込むには「安定性」「再現性」「UIとの連携」「エラー処理」など必要ですので、ちょっと手間はかかりますね。
最後に、私が作成したkintone向けOCRサービスも紹介しておきますので、ご参考までに。
こちらは、Bubble、Azure、Geminiを使用しています。
https://yellow885444.studio.site/
kintone向けのOCRサービスについて知りたい方は、こちらの記事が参考になるかもしれません。
https://ict4small.com/kintone-ocr/
今回の検証とプロンプトが、みなさんの業務改善やアプリ開発のヒントになれば幸いです。