Gemini 3.5 Flash-LiteのFAX OCR精度を180回比較 — 3.1を継続した理由

新しいAIモデルが公開されると、OCRでも「モデル名を差し替えるだけで精度が上がるのでは」と期待したくなります。SP-FAXでも、Gemini 3.5 Flash-Liteの公開を受け、実際の受注業務で使われたFAX帳票を使って検証しました。

結論から言うと、3.5 Flash-Liteは速いものの、今回の帳票群では3.1 Flash-Liteを安定して上回りませんでした。プロンプト調整やthinking levelも試しましたが、全面移行は見送り、標準モデルは3.1 Flash-Liteを継続しています。

この記事では、都合のよい成功例だけでなく、20帳票を3条件・各3回、合計180回実行した結果をそのまま紹介します。

※ 顧客名、FAX番号、住所、商品名、帳票画像などの固有情報は掲載していません。モデルの提供条件・料金・挙動は検証時点のものです。

なぜ3.5 Flash-Liteに期待したのか

以前の検証では、上位クラスだったGemini 2.5 Flashの処理を、より軽量なGemini 3.1 Flash-Liteでかなり代替できました。その経験から、3.1 Flash-Liteから3.5 Flash-Liteへの更新でも、速度を維持しながら帳票理解が改善する可能性があると考えました。

Googleも3.5 Flash-Liteについて、文書解析、構造化データ抽出、JSON出力、高スループット用途の改善を案内しています。FAX OCRで期待したのは、単なる一文字ずつの認識だけではなく、次のような部分です。

• 商品行と数量欄を正しく対応付ける
• 総量行と店舗別明細を重複させない
• 発注元、宛名、納品先を混同しない
• 指定したJSON構造を崩さず返す

参考: Google AI for Developers — Using the latest Gemini models

検証方法: 同じ20帳票を3条件で各3回

対象は、社内の受注業務ですでに確認・修正されたFAX帳票から、送信元が重複しない20帳票を選びました。20明細に対して86項目の修正履歴があり、品番の元読取値は20明細、商品名の元読取値は19明細で残っていました。

一度だけの成功・失敗をモデル性能と誤認しないよう、同じPDFを各条件で3回ずつ処理しています。

3.5のON/OFFでは、モデル、PDF、基本プロンプト、解像度、thinking levelを共通にし、商品候補一覧から選択行だけを出すための追加指示だけを変えました。OCR結果や辞書利用回数、後続システムのデータは更新しない読み取り専用試験です。

180回比較の結果

3.5 Flash-Liteは処理時間で明確に優位でした。一方、受注処理で重要な明細行数、数量、商品名、3回の再現性では3.1 Flash-Liteが上回りました。品番や過去の修正対象への一致はほぼ互角で、モデル更新だけで業務上の修正が大幅に減る結果ではありませんでした。

プロンプトを調整すれば逆転するのか

当初は、3.5向けに追加した「選択された商品行だけを出力する」という指示が、通常注文書の数量補完と競合している可能性を疑いました。そこで、その追加指示だけを外した条件も比較しました。

OFFで少し改善した項目はありますが、3.1との差を逆転するほどではありません。品番と商品名はOFFの方がわずかに下がりました。今回の範囲では、特定の一文が3.5の性能を大きく損ねていたとは言えません。

過去に未選択商品を大量抽出したチェック式帳票でも各3回確認しましたが、ONは2/3回、OFFは3/3回が正しい1明細でした。1帳票だけなので一般化はできませんが、「指示を増やせば必ず安定する」とも限らないことが分かります。

thinking levelを上げればよいわけでもなかった

3.5 Flash-Liteはthinking levelを変更できます。複雑な帳票なら推論量を増やすことで改善する可能性があるため、別試験でminimalとhighも比較しました。

通常帳票10枚では一部の品番・帳票種別が改善しましたが、平均処理時間は3.56秒から8.17秒へ増加。複雑な7ページ帳票では、明細数と行構造は同じまま、処理時間が41.99秒から87.93秒へ増えました。

この結果から、難しい帳票へ一律にhighを適用する案も見送りました。thinkingは「高いほど高精度」という単純な設定ではなく、帳票ごとの実測が必要です。

今回の判断: 3.1を標準のまま維持

3.5 Flash-Liteが悪いモデルという意味ではありません。高速な構造化抽出が必要な用途では有力です。ただ、今回のような低画質FAX、手書き、商品候補表、業務上の品番変換が混ざる受注OCRでは、速度だけで標準モデルを決められませんでした。

モデル移行テストで重要だった5つのこと

1. 同じPDF・同じプロンプトで比較する: モデルと同時に解像度や追加指示を変えると、原因を切り分けられません。
2. 業務上の正規値と紙面の読取値を分ける: 品番変換や辞書補正までモデルの誤りとして数えると、OCR性能を誤評価します。
3. 一度ではなく反復する: 今回は3回の完全一致が3.1で12/20、3.5で7/20でした。単発の成功例だけでは見えない差です。
4. 行構造と文字転写を別に採点する: 一文字違いと、別の商品行へ数量を付ける誤りは、業務上の危険度が異なります。
5. 入力・出力・thinkingトークンを残す: 解像度や推論量を変えたとき、見かけの出力トークンだけでは費用を判断できません。

まとめ

Gemini 3.5 Flash-Liteは、今回のFAX OCRでは約4割高速でした。しかし、実務上重要な行数、数量、商品名、再現性は3.1 Flash-Liteが優位で、全面移行には至りませんでした。

新しいモデルは、ベンチマーク上の進化がそのまま自社帳票の改善になるとは限りません。だからこそ、実際の帳票、承認済みの正解データ、複数回の反復で確かめ、よくならなければ切り替えない判断も必要です。

SP-FAXでは今後も、モデル名だけでなく、辞書、商品マスタ、帳票構造Guard、レビュー画面まで含めてOCR精度を改善していきます。