以前、「文楽（BUNRAKU）」という書類スキャナーアプリを開発。
書類を撮影またはアップロードし、AIで書類種別を判定し、テキストや金額、日付、取引先などを抽出して保存するWebアプリです。開発は Cursor を使いながら進め、Claude のブラウザ版もバグチェックや確認に使っていました。
このアプリで期待していたことのひとつが、GPT-4o Vision を使った OCR です。
正直に言うと、最初はもっと簡単に考えていました。
画像を渡せば、一瞬でテキストも数字も手書きも読み取り、領収書や請求書の項目までかなり高精度に抽出してくれるのではないか、と。
でも、Webアプリとして実際に組み込んでみると、期待していたほど単純ではありませんでした。
AI OCRは、デモとして見るとかなりすごいです。
ただし、業務アプリに組み込むと、精度だけでなく、レスポンス時間、確認UX、保存フローまで含めて設計しないと使いづらくなります。
文楽でやろうとしていたこと
文楽は、書類画像を撮影またはアップロードして、AIで解析するアプリです。
目的は、電子帳簿保存法に完全対応することではなく、日々の書類整理や入力作業を効率化することでした。
主な流れは、次のようなものです。
- 書類を撮影、または画像ファイルをアップロードする
- プレビュー画面で画像を確認する
- AIが書類を解析する
- 結果画面で日付、金額、取引先、品目などを確認・微修正する
- データベースやGoogle Drive、Google Sheetsへ保存する
対象にしていた書類も、領収書、請求書、納品書、見積書、名刺、メモ、パンフレットなど、かなり幅広いものでした。
この時点で、単なるOCRではありません。
文字を読むだけでなく、
- これは何の書類か
- 日付はどこか
- 合計金額はいくらか
- 取引先は誰か
- 品目リストはどう構造化するか
- 名刺なら氏名、会社名、電話番号、メールアドレスをどう分けるか
まで判断させようとしていました。
期待していたのは「一瞬で読み取れるOCR」
GPT-4o の画像理解はかなり強力です。OpenAI も、画像を入力として扱い、画像内の情報を理解できるモデルとして説明しています。
そのため、実装前の期待としてはかなり高いものがありました。
たとえば、
- レシートの金額をすぐ読める
- 手書きメモもそれなりに読める
- 名刺の電話番号やメールアドレスを抜ける
- 請求書の合計金額や支払期限を構造化できる
- 画像を送れば数秒で結果が返る
というイメージです。
もちろん、完全に100%正しいとは思っていません。
それでも、ユーザーが少し確認すれば済むくらいの体験になるのでは、と期待していました。
ところが、実際にWebアプリに組み込むと、気になる点がいくつも出てきました。
OCR精度だけでなく、レスポンス時間が気になる
まず大きかったのは、レスポンス時間です。
人間がChatGPTに画像を投げて「読めるかな」と試すだけなら、多少待ってもあまり気になりません。
でも、アプリの画面で「解析する」ボタンを押したあとに待つ時間は、体感がかなり違います。
ユーザーは、アプリに対してはもっと即時性を期待します。
- カメラで撮る
- ボタンを押す
- すぐ結果が出る
- 間違っていれば軽く直す
- 保存して次へ進む
こういうテンポを期待します。
しかし、画像解析は毎回一定の速さで返ってくるとは限りません。画像サイズ、通信状態、書類の複雑さ、API側の状態などによって、待ち時間に揺れがあります。
この「待つ感じ」は、業務アプリではかなり重要です。
待ち時間をどう見せるかもUXになる
文楽では、解析中の画面にも工夫が必要でした。
単にローディングアイコンを回すだけでは、ユーザーは「止まっているのでは」と感じます。
そこで仕様では、プレビュー画像の上に半透明のオーバーレイを重ね、
- AIが書類画像を解析中です
- 画像チェック
- 種別判定
- 項目抽出
- スキャンラインのようなアニメーション
といった表示を入れる想定にしていました。
これは見た目の演出というより、待ち時間を成立させるためのUXです。
AI OCRをアプリに入れるときは、「読めるか」だけでなく、「ユーザーが待てるか」も考えないといけません。
数字や手書きは、想像より気を使う
OCRで特に気になるのは、数字です。
金額、日付、電話番号、インボイス番号、品番、数量、単価。
これらは1文字違うだけで意味が変わります。
たとえば、文章の中の1文字が少し違っても、ユーザーが読めば意味を補えます。
でも、金額の桁が違う、日付が違う、電話番号が違うとなると、そのまま保存するわけにはいきません。
さらに手書きが入ると、期待値はもっと難しくなります。
「AIなら手書きも一瞬で読めるはず」と思いたくなりますが、実際には画像の明るさ、角度、ブレ、文字のクセ、背景、紙のしわなどにかなり左右されます。
つまり、OCR精度はモデルだけの問題ではありません。
撮影環境と、アプリ側の確認フローにも依存します。
構造化抽出は、OCRよりさらに難しい
文楽でやりたかったのは、ただ全文をテキスト化することではありません。
領収書なら、
- 日付
- 支払先
- 品目
- 税込合計金額
- インボイス登録番号
- 備考
請求書なら、
- 発行者
- 品目リスト
- 合計金額税込
- 10%対象商品合計
- 8%対象商品合計
- 支払期限
- 振込先
のように、書類種別ごとに項目を分けたいわけです。
これはOCRより一段難しい作業です。
文字を読むだけでなく、「この数字は合計金額なのか」「この日付は発行日なのか支払期限なのか」「この会社名は発行者なのか宛先なのか」を判断する必要があります。
この判断が少しズレると、テキストとしては読めていても、アプリのデータとしては使いづらくなります。
結局、「確認・微修正」前提のUXが必要だった
文楽では、解析結果画面で「AIが抽出した値を確認・微修正する」という前提を置いていました。
これはかなり大事です。
AI OCRを業務アプリに入れるとき、最初から「AIが全部正しく読んで保存する」と考えると危険です。
むしろ、
- AIが下書きを作る
- 人間が重要項目を確認する
- 必要なところだけ軽く直す
- 保存する
という流れにした方が現実的です。
アプリとしては、入力フォームも「ゼロから入力する画面」ではなく、「AIが埋めた値をチェックする画面」として設計する必要があります。
ここを間違えると、AI OCRの精度が少し足りないだけで、アプリ全体が使いづらくなります。
デモと業務アプリは違う
今回いちばん感じたのは、デモと業務アプリの違いです。
1枚の画像をAIに読ませて「おお、読めた」と思うのと、毎日使うアプリに組み込むのとでは、求められるものが違います。
業務アプリでは、
- 毎回そこそこ安定しているか
- 待ち時間に納得できるか
- 間違いに気づきやすいか
- 修正しやすいか
- 保存先に正しく流せるか
- エラー時に止まらないか
まで含めて考える必要があります。
AI OCRは強力です。
でも、強力なモデルを入れればそのまま業務アプリになるわけではありません。
まとめ
GPT-4o Visionを使ったOCRには、大きな可能性があります。
ただ、文楽を作ってみて分かったのは、AI OCRをWebアプリに入れるには、期待値の調整が必要だということです。
「一瞬で、何でも、正確に読む」ことを前提にすると、実務ではつまずきます。
精度、レスポンス時間、撮影条件、構造化抽出、確認画面、保存フローまで含めて設計して、ようやく業務で使える形に近づきます。
AIが全部やってくれるのではなく、AIが下書きを作り、人間が確認・微修正する。
この前提に立つと、AI OCRはかなり現実的な道具になります。
逆に、この前提を持たずにアプリ化すると、「思ったより遅い」「思ったより間違う」「結局使いにくい」という印象になりやすい。
AI OCRの価値は、読み取り精度だけではなく、確認しやすい業務フローまで含めて設計できるかにあると思います。
