Gemini 3.5 FlashでFAX OCRを試した結果
— 住所・TEL抽出は強いが全面切替はまだ慎重

SP-FAXでは、FAX OCRの読み取り精度を上げるために、匿名化した社内検証用帳票で複数モデルを継続検証しています。今回は、社内検証環境でGemini 3.5 Flashを使い、既存のGemini 3.1系との違いを見ました。

結論から言うと、Gemini 3.5 Flashは住所・電話番号など、帳票の周辺情報を拾う力がかなり強いです。一方で、明細を余計に拾いすぎる、商品名に不要な文字が混ざる、店コードや店名が落ちるケースもありました。

そのため現時点では、SP-FAX全体を3.5へ丸ごと切り替えるより、現行の3.1系を軸にしつつ、住所/TEL補完や追加確認ロジックへ3.5の良いところを取り込むのが現実的です。

※ 本記事はSP-FAXの社内検証メモです。顧客名、帳票ファイル名、住所、電話番号、商品名などの固有情報は公開用に伏せています。モデル名・提供形態・性能は利用環境や時期により変わる可能性があります。

検証した帳票

検証対象は、複数ページの注文書と単票の帳票です。実務上よくある、宛先・納品先・店舗名・商品明細・手書きや印字の混在を含むFAX帳票で見ています。

良かった点: 納品先の住所・TELを拾えた

一番はっきり差が出たのは、納品先や倉庫情報の抽出です。複数ページ帳票Aでは、Gemini 3.5 Flashが納品先の情報として、会社名に加えて郵便番号・住所・電話番号まで抽出できていました。

納品先名: 抽出成功
郵便番号: 抽出成功
住所: 抽出成功
TEL: 抽出成功

3.1系でも納品先ラベル自体は拾えていましたが、住所や電話番号まで明細ごとの配送先として埋める力は3.5の方が強く見えました。受信FAXを後続の配送・出荷・確認フローにつなげる場合、この差はかなり大きいです。

気になった点: 余計に拾いすぎる

一方で、3.5は情報をよく拾う分、明細の扱いが過剰になる場面がありました。複数ページ帳票Aでは3.1系の明細数が10件前後だったのに対して、3.5では20件台まで増えています。

FAX OCRでは「拾える」だけでは足りません。業務システムへ連携するには、明細が増えすぎないこと、店コードや店名が安定すること、商品名に余計な文字を混ぜないことが重要です。

今回の判断

今回の検証結果だけを見ると、Gemini 3.5 Flashは「補助モデル」としてかなり有望です。ただし、全帳票を一律で3.5へ切り替える判断にはまだ早いです。

コスト面でも標準化は慎重に見る

高精度なモデルは、読み取り品質だけでなく処理コストも上がります。SP-FAX OCRは「1枚10円から試せる」ことを重視しているため、全帳票を高コストなモデルで処理すると、サービス全体の価格設計と合わなくなります。

そのため、3.5は標準処理に全面採用するより、難しい帳票だけに使う方が現実的です。たとえば、3.1系で住所・TELが不足した場合、店コードが不安定な場合、Guardで危険判定された場合、またはユーザーが高精度再OCRを選んだ場合に限定して使う設計です。

安い標準モデルで大半を安定処理し、必要な箇所だけ高精度モデルに回す。この組み合わせの方が、精度と価格のバランスを保てます。

SP-FAXとして追加したい補正

モデル単体で勝負するより、帳票の業務ルールを後段で当てる方が安定します。今回の結果から、SP-FAXでは次のような補正が有効だと見ています。

1. 納品先・店舗マスタ補完: 「倉庫」「店舗」などのラベルが出たら、住所・TELをマスタから補う
2. 商品名クリーニング: 商品名末尾の「受」など、帳票上のステータス文字を分離する
3. 店コード検証: 店コードが落ちた場合、店名・住所・過去履歴から候補を出す
4. 明細数の異常検知: 期待件数より大きく増えた場合、ページ別・行番号別にレビュー対象へ回す

AIモデルの更新は強力ですが、FAX業務では「モデルを新しくする」だけで完結しません。モデルの得意不得意を見て、辞書・マスタ・レビュー画面・補正ロジックを組み合わせる方が、実務の精度は上がります。