AI-OCRは「それっぽく間違う」— 便利なOCRの条件を考えて、Mistralと読み比べてみた話

AI-OCRは「それっぽく間違う」— 便利なOCRの条件を考えて、Mistralと読み比べてみた話

こんにちは。書類の写真から欲しい項目を取り出すAPI(いわゆるAI-OCR)を個人開発しているエンジニアです。

今日は、AIで領収書や請求書を読み取るときにハマりがちな落とし穴と、それをどう設計で解決したか、そして海外の有名AI(Mistral)と同じ写真で読み比べた実測結果をご紹介します。開発者の方はもちろん、「紙の書類の入力作業をなんとかしたい」という方にも読んでいただける内容にしたつもりです。

■ デモは魔法、本番は……

AIモデルに領収書の写真を渡すと、店名・日付・明細・合計がきれいなデータになって返ってきます。初めて見たときは魔法のようです。「もう解決済みの分野なんだな」と思いますよね。

ところが本番で使い始めると、ある日「数量 1」が「7」になって返ってきます。単価がいつのまにか隣の行にずれていることもあります。

怖いのは、エラーが出ないことです。JSONの形は完璧で、数字だけが静かに間違っている。応答のどこを見ても「間違えました」というヒントがありません。

請求書や納品書のように会計ソフトに入っていくデータだと、「それっぽく間違った数字」は「読めませんでした」よりずっと危険です。その数字のせいで、誰かが間違った金額を支払ってしまうからです。

■ 「便利なOCR」の3つの条件

このAPIを作るとき、ずっと頭にあった言葉は「便利」でした。宣伝文句としてではなく、すべての設計判断を照らし合わせるテストとして、です。

本気で考えてみると、「便利」は3つの約束の積み重ねだと気づきました。

1. つなぐのが早いこと。数分でつながる。スプリント1本ではなく。

2. 返ってきたデータがそのまま使えること。整形コードなしでデータベースに入る。

3. エンジンが間違えたとき、気づけるチャンスがあること。

呼び出しが簡単なだけのAPIは、2番目で静かに止まります。返ってくるのが生テキストと単語の位置だけだと、そこから「請求書の項目がデータベースに入っている状態」までの距離が、実は本当のプロジェクトなんです。正規表現、ラベルと値の対応付け、表の再構築……。「呼ぶのが簡単」はスプリントを消したのではなく、自分のコードベースの中に移動させただけでした。

3番目は「便利さ」というより「信頼性」の話に見えるかもしれません。でも、信頼できないAPIを使うとき、私たちが実際にやることを思い出してください。抜き取りチェック、確認用のスプレッドシート、合計を全部読み直す担当者——結局その周りに第2の業務プロセスを自分で作ることになります。不便さは消えず、下流に移動して、データを掃除する誰かの上に着地するだけ。信頼できない答えは、便利ではなく「後回しにされた作業」です。

■ 仕組み:AIに座標を作らせない

設計で一番大事にした決め事は、「AIモデルには座標を作らせない」ことです。

マルチモーダルAIは書類を読むのは驚くほど得意ですが、「どこに書いてあったか」を答えるのは苦手です。位置を聞くと、それっぽい枠を自信満々に返してきます。間違った値に、自信ありげな枠が付いてくる——まさに一番捕まえたかった失敗が、一番捕まえにくくなるパターンです。

そこで、得意分野の違う2つのエンジンに仕事を分けました。

・従来型のOCRエンジンが、ページ上の全文字を正確な位置つきで読む(位置は正確だが、意味は分からない)

・AIモデルが、意味を理解して欲しい項目を抜き出す(意味は分かるが、位置は信用できない)

・最後に照合ステップが、抜き出した値がページのどこに印字されているかを1文字ずつ探す

抜き出した値と、その場所に実際に印字されている文字が一致したら——成り立ちがまったく違う2つのシステムが独立に同じ答えを出したことになるので、その項目は「検証済み(verified)」になります。合わなければ、あるいはページのどこにも見つからなければ、「この項目は要確認」と理由つきのフラグが立ちます。

うれしい誤算だったのは、この1つの仕組みが2つの機能を同時に生むことでした。文字照合は検証の判定を生むと同時に、正確な座標も生みます。「値がページに印字されているか」を調べることと「どこに印字されているか」を調べることは、同じ探索だからです。だから枠はAIの当てずっぽうではなく、実際に印字された文字の実測範囲。値をクリックすると原本のその場所がハイライトされる、といった確認画面がそのまま作れます。

もちろん万能ではありません。両方のエンジンが同じように読み間違えたら、すり抜けます。それでも初期状態が変わります。何もなければ、すべての間違いはきれいなJSONの中に隠れる。この仕組みがあれば、大半の間違いには場所つきのフラグが立ち、人に回すことができる——実務ではこれが大きな違いになります。

■ Mistralと同じ写真で読み比べてみました

設計の話だけでは説得力がないので、2026年8月に Mistral の Document AI と条件をそろえて比較しました。同じ画像、同じ項目定義、同じ採点方法(空白を除いた完全一致)、各3回ずつ実行です。

・自作API(この記事のパイプライン)

・mistral-ocr-latest(OCR 4.1)

・mistral-medium(ビジョン+JSONスキーマ)

対象は日本語・韓国語の実物ビジネス書類——納品書、手数料明細、価格表、レシートです。

結果(項目正解率):

・自作API:91.1%

・mistral-ocr-latest:70.0%

・mistral-medium:73.5%

※7枚の書類・8ケース・463フィールド・各3回実行(2026年8月)

数字そのものより、印象に残ったことが3つあります。

1. 差がついたのは「読む力」ではなく「構造」でした。きれいに印字された表では、ほぼ互角(139対141)。現代のOCRは、きれいな印字なら全部読めるんです。差が開いたのは、商品名が上の行・数量と単価が下の行に印字される「2行組のレシート」でした。13明細のうち、自作APIは12件、Mistral は平均2.3件。どの文字の断片がどのレコードのものか——項目抽出の勝負は、ここで決まります。

2. 同じ画像を3回入れたときのブレも意外でした。自作APIは合計スコアが16フィールド動き、Mistral OCR は100フィールド動きました。そのうち1回は、43行の表の列の対応が丸ごと崩れました。実行するたびに違う答えが返ってくる抽出ステップの上に、業務プロセスを組むのは難しいです。

3. そして、一番大事な差はスコアに出ません。Mistral の応答には項目ごとの座標がなく(22行の価格表が、1つのテキストブロックとして返ってきました)、要確認フラグのようなものも一切ありません。正しい数字も間違った数字も、同じ顔で返ってくる。まさに、この検証設計が避けたかった状況そのものです。

フェアに書いておきます。この比較は7枚の書類の範囲の話で、それ以上の一般化はしません。正解データは自作パイプラインの表記ルールで固定したので、絶対値より相対差を見てください。測ったのは項目抽出だけで、Mistral のMarkdown変換や速度・価格については何も言っていません。

■ まとめ

製品にOCRを組み込むなら、「どのモデルが一番読めるか」は、だんだん正しい質問ではなくなってきています。きれいな印字なら、どれもよく読めるからです。

いい質問は、返ってきたデータで何ができるかのほうにあります。値の出どころをユーザーに見せられるか。どの値を再確認すべきか、何かが教えてくれるか。

私の場合、この2つは同じ場所から生まれました。AIの答えと、視覚エンジンが実際にページで見たものとの、1文字ずつの照合です。そして一番こだわったのは、この機構が外に漏れないこと。外から見れば、欲しい項目名を並べてPOSTするだけの、退屈な1回のAPI呼び出しです。多段の検証パイプラインを「普通のAPI」に見せることに一番時間を使いましたし、そこにこのAPIの意味の大半があると思っています。

書類の読み取りをシステムに組み込もうとしている方の、何かの参考になればうれしいです。

最後までお読みいただき、ありがとうございました。

※ベンチマーク数値:7枚の書類・8ケース・463フィールド・各3回実行(2026年8月)