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

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

VLM で書類から値を抽出するとき、VLM 自身に「この値は正しいか」を聞いても、誤読した値に高い確信度を返してしまうことがあります。
Cloudflare の Clef に書類画像(英語)を見せて、OCR 結果の誤りを見つけさせてみた | DevelopersIO では、Cloudflare の Clef に書類画像と抽出結果を渡して「この値は画像どおりか」を判定させ、仕込んだ誤り36件をすべて検出できました。

OpenAI の Decisions API（モデルは gpt-6-luna）でも、画像を入力として受け取って yes の確率を返す質問ができます。
そこで今回は、Clef の検証で使ったものと同じ英語の書類3枚・同じ質問を Decisions API に渡し、誤りの検出数や誤検知の傾向を Clef と比較してみました。

1. 検証の条件

データは Clef の検証と同じものを使いました。
英語の見積書・請求書・領収書（3枚・計91項目）を Claude Haiku 4.5 で抽出した結果に対して、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）

判定方法も Clef の検証と揃えています。
書類画像1枚と抽出結果を渡し、項目ごとに predicate（yes の確率を返す質問）で「この値は画像に印字されたとおりか」を問い合わせます。
確率 0.5 未満を「誤り」と判定し、比較対象は clef・clef-flash（2026年10月4日の実測値）としました。

Decisions API へのリクエストは次の形です（質問は1問だけ抜粋しています）。
コメントは説明用なので、実際に送る JSON には含めていません。

{
  "model": "gpt-6-luna",
  "input": [{
    "role": "user",
    "content": [
      // 判断の前提（OCR システムが請求書画像を読み取り、キーと値を抽出した。画像と照合せよ）と抽出結果
      {"type": "input_text", "text": "{\"task\": \"An OCR system read the attached invoice image and produced these key-value pairs. Verify them against the image.\", \"extracted\": {\"invoice_no\": \"INV-2026-0042\", ...}}"},
      {"type": "input_image", "image_url": "data:image/png;base64,..."}
    ]
  }],
  "questions": [{
    "type": "predicate", // yes/no の質問。yes の確率を返す
    "name": "field__invoice_no",
    // 抽出された invoice_no の値は、書類画像に印字された文字列と一字一句一致しているか
    "instructions": "Is the extracted value of \"invoice_no\" (\"INV-2026-0042\") exactly what is printed in the document image, character for character?"
  }]
}

Clef の noul は、Decisions API では predicate に相当します

検証に使った請求書

2. 結果

2.1 誤りを見つけられたか

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

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

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

Decisions API でも、注入した誤りを36件すべて検出できました。
一方で、正しい値を誤りと判定してしまった誤検知は5件あり、clef（0件）や clef-flash（3件）よりも多くなっています。

請求書の bill_to_attn は、画像上では「Attn: Accounts Payable」と印字されています。
抽出値には「Attn:」を含めていなかったため、Decisions API は「一字一句一致しているか」という指示を厳密に解釈し、不一致と判定したようです。

注入した36件の一致確率は次のとおりです。
値が低いほど、モデルが「画像と一致していない」と強く判断していることを示します。

2.2 確率の分かれ方

誤りの項目（36件）と正しい項目（237件）に出力された確率のばらつきは次のとおりです。
下位5%と上位5%は、確率を昇順に並べたときの下から5%と95%にあたる値です。

1項目を1点として、モデルごとに並べると次のようになります。
なお、次の3つのグラフは、検証結果のデータをもとに Claude に作成してもらったものです。

Decisions API：誤りは 0.0 付近、正しい値は 1.0 付近に固まる

clef：誤りは 0.0〜0.2 台、正しい値は 0.6〜0.9 台に散らばる

clef-flash：clef に近い分かれ方だが、正しい値の一部が 0.5 を下回る

Decisions API の出力した確率はかなり両極端に寄っていました。
誤りの36件中31件はちょうど 0.0、正しい値の237件中123件はちょうど 1.0 になっており、Clef のように 0.9 台や 0.0 台へ緩やかに散らばる形にはなりませんでした。
ただその一方で、正しい値の下位5%は 0.718 と、Clef と同程度に低い値も一部出ています。

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

Decisions API は誤りの確率がすべて 0.08 以下に収まっていたため、しきい値を 0.1 まで下げても36件すべてを検出できました。

2.3 時間と費用

リクエストは書類1枚につき1回行い、画像1枚とその書類に含まれる全項目の質問（21〜38問）をまとめて送信しています。
所要時間は日本国内から REST API を呼び出した際の実測値で、費用は1ドル150円換算です。

Decisions API は検証した3モデルの中で最もレスポンスが速く、clef の約3分の1の時間で処理が終わりました。
入力トークン数は Clef と同内容でも約1.9倍に増えたものの、トークン単価が clef（$0.24）より安いため、総費用としては clef の約4分の3に収まっています。

3. まとめ

Decisions API は英語の書類画像をそのまま読み込ませて、OCR の抽出結果が正しいかどうかをチェックすることはできそうです。

ただ、出力される確率が 0.0 付近と 1.0 付近に極端に張り付く傾向がある点は、運用上少し気になるところです。