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

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

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

最近は VLM 自体の文字認識精度が向上してきたため、VLM 単体で抽出まで完結させる構成も実用的になってきました。
ただ、LLM が出力する確信度は自己申告になりやすく、誤読した値に対しても高いスコアを出してしまうことがあるなど、判定の根拠として信頼しきれない弱点があります。
かといって、検証のためだけにもう1つ別の LLM を呼び出すと、さらにコストがかかってしまいます。

2026年10月1日に Cloudflare Workers AI で公開された Clef は、画像入力に対応した decision model で、質問に対して直接確率を返してくれます。
軽量かつ低コストで動かせるため、抽出結果を独立してチェックする役目に適しているのではないかと考えました。

そこで本記事では、書類画像と抽出結果を Clef に渡し、「この値は画像どおりか」を判定させて OCR 結果の誤りを見つけられるかを検証してみました。

1. 検証の条件

まずは Claude Haiku 4.5 に英語の見積書・請求書・領収書（3枚・計91項目）を抽出させ、自然に発生した誤りを検出しようと試みました。
しかし、Haiku が思った以上に優秀ですべての項目を正しく抽出してしまったため、今回は検証用に3パターンの誤り（各12件・計36件）を意図的に注入しました。

注入した誤りの内訳は次のとおりです。

• 桁の変更（12件）：金額や日付の数字を1桁だけ変える（$1,150.00 → $1,160.00、09/18/2026 → 09/19/2026 など）

• 似た文字への変更（12件）：OCR で混同しやすい文字に差し替える（0 → O、1 → l、m → rn など）

• 別の値への置き換え（12件）：文脈として不自然ではない別の単語に置き換える（SAMPLE MART → FRESH MARKET、Service → Hardware など）

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

• 判定方法：書類画像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 invoice image ...",
    "extracted": { "invoice_no": "INV-2026-0042" }
  },
  "questions": {
    "field.invoice_no": {
      "type": "noul", // yes/no の質問。yes の確率を返す
      // instructions: 判定の指示（抽出された invoice_no の値は、書類画像に印字された文字列と一文字一句違わず完全に一致しているか？）
      "instructions": "Is the extracted value of \"invoice_no\" (\"INV-2026-0042\") exactly what is printed in the document image, character for character?"
    }
  }
}

検証に使った請求書

2. 結果

2.1 誤りを見つけられたか

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

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

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

clef は、注入した誤りを全件検出し、誤検知も 0 件でした。
一方、clef-flash は本来正しい値であるはずの項目を「誤り（確率 0.5 未満）」と誤判定してしまう誤検知が 3 件ありました。該当したのは次の項目で、いずれも合計金額など金額に関する項目でした。

※ 見積書の Total は2回の試行でそれぞれ誤検知されたため件数としては計3件ですが、対象の項目自体は上記の2種類です。

注入した36件すべての一致の確率は次のとおりです。
この値は「抽出した値が画像どおり正しい確率」を表しているため、数値が低ければ低いほどモデルが「画像と一致していない（誤りである）」と強く疑っていることを意味します。

2.2 確率の分かれ方

しきい値をどこに設定すればよいかを見るため、誤りの項目（36件）と正しい項目（237件）に付いた「値が画像どおりである確率」のばらつきをまとめました。
下位5%と上位5%は、確率を低い順に並べたときに、下から5%と95%の位置にある値です。

正しい項目については、どちらのモデルも中央値が0.9台（clef: 0.914、clef-flash: 0.940）と高い確率を出しています。
下位5%を見ると clef は 0.769、clef-flash は 0.645 とやや低めに出る項目もありました。

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

どのしきい値でも、注入した誤りは両モデルとも36件すべて拾えました。
違いが出たのは誤検知の数で、しきい値を上げるほど、正しい値まで人の確認に回ってしまう件数が増えます。
clef は 0.5〜0.6 なら誤検知が 0 件でしたが、0.8 にすると正しい値の約1割（23件）が人の確認に回ります。
clef-flash は 0.5 でも誤検知が3件あり、0.8 では約2割（50件）にのぼるため、確認の手間を抑えたいなら clef が向いています。
ただし、誤りのデータは36件と少ないため、実際の運用では扱う書類で同様に集計を取り、しきい値を決めることをおすすめします。

2.3 時間と費用

Clef へのリクエストは、書類1枚につき1回です。
1回のリクエストで、画像1枚と、その書類の全項目に関する質問（21〜38問）をまとめて送っています。

時間は日本国内から REST API を呼び出した際の実測値で、費用は1ドル150円で換算しています。
Haiku による抽出には1枚あたり10〜13秒ほどかかるため、このチェック処理を追加しても全体の処理時間はほぼ変わりません。

3. まとめ

英語の書類3枚で試した限りでは、画像を渡した clef は注入した誤りをすべて検出し、誤検知もありませんでした。
ただし、今回の誤りは人工的に注入したもので、Haiku 自身が起こす読み間違いに対する性能までは確かめていません。

書類の抽出チェックに組み込むなら、VLM で抽出した結果の正しさをその VLM 自身に自己申告させるのではなく、Clef のような軽量な decision model に画像付きで渡してダブルチェックさせる構成が有効です。

参考

• Models: clef | Cloudflare Workers AI docs

• Changelog: Introducing Clef: Cloudflare's first open-source decision models, now on Workers AI | Cloudflare Docs