Cloudflare の Clef に書類画像(日本語)を見せて、OCR 結果の誤りを見つけさせてみた

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

VLM で書類画像を読み取って OCR を行う構成が増えていますが、抽出された値が本当に画像どおり正しいかをどう検証するかは依然として課題です。
判定に特化した decision model として知られる TypeSafe 社の Jev はテキスト入力専用のため、元の書類画像を直接見て「抽出結果が画像どおりか」を確かめるような検証はできませんでした。

一方、Cloudflare Workers AI の Clef は、画像入力に対応した decision model です。
書類画像と VLM による抽出結果を一緒に渡し、「画像に印字されたとおりの値か」を直接判定させて信頼度スコアを得ることができます。

前回の英語書類での検証では、Clef に書類画像と OCR の抽出結果を渡したところ、意図的に注入した36件の誤りをすべて検出し、誤検知も0件でした。
そこで今回は、登録番号や軽減税率、大字の金額、全角と半角の混在を含む日本語の書類でも、同じように誤りを見つけられるかを検証してみました。

1. 検証の条件

まずは Claude Haiku 4.5 に日本語の請求書・見積書・領収書（3枚・計149項目）を抽出させました。
英語のときは Haiku がすべての項目を正しく抽出できましたが、日本語では19件の読み間違いが自然に発生したため、こちらも検出の対象に含めています。
さらに、検証用として4パターンの誤り（計36件）を意図的に注入しました。

• 桁の変更（12件）：金額や番号の数字を1桁だけ変える（51,750 → 51,790、MQ-2026-0918 → MQ-2026-0916 など）

• 似た文字への変更（9件）：形の似た文字に差し替える（カ → 力、口 → ロ、ー → 一 など）

• 全角と半角の入れ替え（3件）：２０食 → 20食、MN-2407 → ＭＮ－２４０７ など

• 別の値への置き換え（12件）：書類にありそうな別の値にする（普通 → 当座、株式会社ひかり物流 → 株式会社ひかり運輸 など）

抽出結果は、書類ごとに次の4通りを用意しました。

• Haiku の出力そのまま：Haiku が抽出した結果（追加の誤り注入なし。Haiku 自身の読み間違い19件が含まれる）

• 誤りあり A・誤りあり B：Haiku の出力に、検証用の誤りを6件ずつ意図的に注入したもの

• 正解データ（誤りなし）：すべて正しい値だけで構成された版（誤りが1件もないときの挙動を見るための対照データ）

判定と検証の条件は次のとおりです。

• 判定方法：書類画像1枚と抽出結果を渡し、項目ごとに noul（yes の確率を返す質問）で「この値は画像に印字されたとおりか」を聞く。確率 0.5 未満を「誤り」と判定

• モデル：clef（27B）と clef-flash（9B）

{
  "model": "clef",
  "images": ["data:image/png;base64,..."],
  // state: 判断の前提（OCR システムが日本語の請求書画像を読み取り、キーと値を抽出した）
  "state": {
    "task": "An OCR system read the attached Japanese invoice (請求書) image ...",
    "extracted": { "issuer_name": "株式会社さくらフーズ" }
  },
  "questions": {
    "field.issuer_name": {
      "type": "noul", // yes/no の質問。yes の確率を返す
      // instructions: 判定の指示（抽出された issuer_name の値は、書類画像に印字された文字列と一字一句違わず一致しているか？）
      "instructions": "Is the extracted value of \"issuer_name\" (\"株式会社さくらフーズ\") exactly what is printed in the document image, character for character?"
    }
  }
}

検証に使った請求書。印影が発行者名と登録番号に重なっている

2. 結果

2.1 誤りを見つけられたか

Clef は項目ごとに「値が画像どおりである確率」を返します。
この確率が 0.5 未満の項目を「誤り」と判定し、次の3つの観点で件数を集計しました。

• 注入した誤りの検出：注入した誤り36件のうち、正しく「誤り」と判定できた件数

• Haiku の誤りの検出：Haiku 自身の読み間違い19件（「Haiku の出力そのまま」の版）のうち、「誤り」と判定できた件数

• 正しい値を誤りと判定：本来は正しい値なのに「誤り」と判定してしまった件数（誤検知）

clef は注入した誤りの大半を検出できたものの、英語のときのような全件検出には届きませんでした。
また、Haiku 自身の読み間違いについては19件中7件しか検出できませんでした。

誤りの種類別に見ると、全角と半角の入れ替えや、Haiku 自身の読み間違いを見逃すケースが目立ちました。

判定を誤った項目は、clef が23件、clef-flash が41件でした。
なお、ここで言う「見逃し」は誤りがあるのに 0.5 以上を付けたもの、「誤検知」は正しい値なのに 0.5 未満を付けたものを指しています。

clef が誤りと判定してしまった正しい値7件は次のとおりです。

このうち5件（正解データの5件）は、Haiku が読み間違えた項目の正しい値でした。
例えば領収書の数量では、正しい ３日 に 0.34、Haiku が読み間違えた 3日 に 0.89 を付けており、全角と半角を逆に判断してしまっています。
全角と半角の区別は Clef に任せず、比較の前に文字列を正規化して吸収しておくほうが確実です。

2.2 確率の分かれ方

しきい値をどこに設定すべきかを確認するため、注入した誤り（36件）、Haiku の読み間違い（19件）、正しい値（503件）に付いた確率のばらつきをまとめました。
下位5%と上位5%は、確率を低い順に並べたときに、下から5%と95%の位置にある値です。

英語のときと違い、誤りと正しい値の確率が大きく重なる結果となりました。
特に Haiku の読み間違いは中央値が 0.691 と高く、正しい値（中央値 0.874）と見分けがつきにくい状態でした。

しきい値を変えたときの結果は次のとおりです。

clef は 0.8 まで上げると注入した誤りを全件拾えますが、正しい値の約17%（85件）も人の確認に回ることになります。
それでも Haiku の読み間違いは19件中13件までしか拾えず、しきい値の調整だけで取りこぼしをなくすのは困難でした。
clef-flash は、どのしきい値でも clef より検出数が少なく誤検知も多いため、日本語の書類には clef のほうがまだ向いていそうです。

2.3 時間と費用

Clef へのリクエストは、書類1枚につき1回です。
1回のリクエストで、画像1枚と、その書類の全項目に関する質問（30〜63問）をまとめて送っています。
3書類 × 4通りの抽出結果で、モデルごとに12回呼び出しました。

時間は日本国内から REST API を呼び出した際の実測値で、費用は1ドル150円で換算しています。

3. まとめ

日本語の書類では、clef は値として別物になる誤り（桁、置き換え、別の単語）をおおむね検出できたものの、全角・半角の違いや1文字の脱落は見逃しやすく、英語ほどの精度は出ませんでした。
特に、OCR（Haiku）が実際に起こした読み間違いは19件中7件しか拾えていません。

画像入力に対応している点や低コストで扱える点は Clef の大きな強みです。
現時点でチェックを任せる場合、決して手放しで信頼できるほどの精度ではなく、しきい値だけで「これは確実に大丈夫」と言い切れる水準にはまだ達していないように思えます。
ただ、全件を最初から人手で確認するのに比べれば、怪しい項目を絞り込んで人の確認コストをある程度減らす用途としては、試してみる価値がありそうです。

参考

• Models: clef | Cloudflare Workers AI docs