Gemini Decision 1 に書類画像を見せて OCR の誤りを探させ、Jev・Decisions API と比べてみた

こんにちは、けーまです。

書類からの OCR 処理では、 AWS であれば Amazon SageMaker で OCR モデルをホストして文字を抜き出し、文字認識の確信度スコアを使いつつ後段の LLM でキーと値を構造化するようなアプローチがあります。
しかし、SageMaker でモデルを常時ホストし続けると料金がかさみやすく、複数のサービスを組み合わせるため構成も重くなりがちです。

最近は VLM 自体の文字認識精度が向上してきたため、VLM 単体で抽出まで完結させる構成も実用的になってきました。
ただ、LLM が出力する確信度は自己申告になりやすく、誤読した値に対しても高いスコアを出してしまうことがあるなど、判定の根拠として信頼しきれない弱点があります。
そこで、書類の画像と読み取り結果を decision model に渡し、「この値は画像と合っているか」を項目ごとに確率で判定させれば、怪しい項目だけを人手による確認に回せます。

以前、Cloudflare の Clef で同じことを試しました。
詳しくは Cloudflare の Clef に書類画像(日本語)を見せて、OCR 結果の誤りを見つけさせてみた | DevelopersIO をご覧ください。

本記事では、2026年11月11日に Google が公開した Gemini Decision 1 に書類画像と OCR の値を渡して誤りを探させ、同じく画像入力に対応している TypeSafe の Jev、および OpenAI の Decisions API と同条件で比較してみました（検証日は 2026年11月13日です）。OCR に強いと言われている Google のモデルがどれくらいなのか気になりますね

1. 検証の方法

1.1 書類

記事への掲載が可能な実物の書類を5件使用しました。
内訳は日本語2件、英語3件です。

左からイオン マックスバリュ松山店、キャメルマート秋田八幡平店、マレーシアの書店のレシート

左から論文掲載料の請求書、Form 1040 のテスト用記入例の2ページ目

各画像の出典とライセンスは上の表のとおりです。いずれも当ブログにて縮小し、横に並べて1枚にまとめています。

1.2 OCR の値と、わざと入れた誤り

各書類から5〜6項目を選び、正しい値を書き起こしました（例：イオンのレシートであれば店名・日付・外税8%・合計・お釣りなど）。
書類全体ではなく一部の項目に絞ったのは、正解データを人手で確実に確認できる分量にするためです。

検証用のデータとして、次の3パターンを用意しました。

• 誤りなし：書き起こした正しい値のまま

• 誤りA・誤りB：2項目ずつ、値をわざと変えたもの

誤りの入れ方は次の3種類で、書類5件で合計20件の誤りを作成しました。

• 数字の入れ替え・抜け（¥246 → ¥264、36,852 → 36,582）

• 形の似た文字への置き換え（マックスバリュ → マックスバリユ、UCSFD00005 → UCSFDO0005）

• 別の値への差し替え（お釣りの欄に預り金の ¥500）

1.3 質問

画像と値の一覧をあわせてモデルに渡し、項目ごとに次のような yes/no の質問を行いました。

{
  "field__total": {
    "type": "noul",
    "instructions": "抽出した「total」の値 \"¥264\" は、画像に印字されている内容と1文字も違わず同じか。空白の数の違いだけは同じとみなす。"
  }
}

書類5件 × 3パターンの計15回のリクエストを、3つのモデルに対して同じ画像・同じ質問で送信しました。
Jev は画像入力が preview 版のため、ヘッダーに TypeSafe-Danger-Zone-Images: true を付与し、画像を assets に含めて送信しています。

1.4 指標

• 見つけた誤り：あらかじめ仕込んだ20件の誤りのうち、「画像と同じ」である確率が 0.8 未満と判定された件数

• 誤検知：正しい値61件のうち、「画像と同じ」である確率が 0.8 未満になってしまった件数（この数が多いほど、人手で見直す項目が増えてしまいます）

• 正しい値を正しいと判定：正しい値61件のうち、「画像と同じ」である確率が 0.8 以上と判定された件数（誤検知と合わせて 61件になります。何でも「誤り」と答えれば見つけた誤りは増えるので、正しい値をきちんと通せたかもあわせて見ます）

判定には、表示用に小数第2位で丸める前の確率を使っています（そのため、表で 0.90 と表示されている値でも、閾値 0.9 では「0.9 未満」になる場合があります）。

2. 結果

2.1 見つけた誤り・誤検知・正しい値を正しいと判定

Gemini Decision 1 は誤りの見落としが最も少なかった一方で、正しい値についても24件を誤りと判定してしまい、正しいと判定できたのは61件中37件にとどまりました。
正しい値を正しいと判定できた件数は、Decisions API が54件、Jev が50件でした。
誤検知となったケースの多くは、正しい値に対して 0.5〜0.8 程度の確率を出力したものでした。
たとえば、SROIE のレシートの店名（BOOK TA .K (TAMAN DAYA) SDN BHD）については、正しい値であるにもかかわらず 0.26〜0.38 という確率を出力しています（印字がかすれていて読みにくい箇所であり、Jev と Decisions API も同様に 0.8 未満でした）。

2.2 閾値を変えたとき

Gemini Decision 1 の確率は正しい値であっても低めに出る傾向が見られたため、判定の閾値を変えて比較してみました。

表内の数値は、見つけた誤り／誤検知／正しい値を正しいと判定を表しています。

Gemini Decision 1 は、閾値を 0.8 や 0.9 に上げると、正しい値を正しいと判定できる件数が極端に減ります（61件中、0.8 で37件、0.9 で6件）。
一方で、誤りのすり抜けはどの閾値でも少なく、0.6〜0.8 では20件中19件を検出できています。
このグラフを見る限り、Gemini Decision 1 は閾値を 0.7 くらいにしておくと、ちょうどよいバランスになりそうだと感じました。

2.3 見落とした誤り

3モデルのうち、どれか1つでも見落とした誤りを載せます。
数値は「画像と同じ」の確率で、太字が閾値 0.8 以上、つまり誤りを見落としたものです。

申告書の名前の n が1文字多い誤りについては、Gemini Decision 1 と Jev の両方が見落とす結果となりました。
一方の Decisions API は、数字の並び替えや 0 と O の違いといった誤りに対して、確率 1.00 で「同じ」と判定してしまっています。

3. 全件の結果

結果はこちらになります。太字は、閾値 0.8 の条件で判定を外してしまった項目です

4. まとめ

Gemini Decision 1・Jev・Decisions API に、書類5件の画像と OCR の値を渡し、わざと入れた誤りを探させてみました。

Gemini Decision 1 でも、OCR の値の誤りは見つけられるようになっています。
また、同じ画像を渡しても入力トークンが他の2モデルより少なく済みました。
以前 Gemini のモデルを検証したときも同じ結果だったので、Gemini 系のモデルの特徴なのかもしれません。
日本語の書類にも実用レベルで使えそうな感じがあります。

ただし、閾値の感覚は Jev とは違います。
実際に組み込むときは、用途に近いテストデータを用意して、どの閾値にするかを判断する必要があると感じました。

参考

• Images | TypeSafe Docs