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

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

Cloudflare の Clef に書類画像(日本語)を見せて、OCR 結果の誤りを見つけさせてみた | DevelopersIO で、Cloudflare の Clef に日本語の書類画像と OCR の抽出結果を渡し、「画像に印字されたとおりの値か」を判定させました。
clef は注入した誤り36件のうち32件を見つけられたものの、OCR（Claude Haiku 4.5）が実際に起こした読み間違いは19件中7件しか拾えませんでした。

OpenAI の Decisions API（モデルは gpt-6-luna）も、画像を受け取って yes の確率を返す質問ができます。
そこで本記事では、Clef の検証と同じ日本語の書類3枚・同じ質問を Decisions API に渡し、Haiku の読み間違いまで拾えるかを Clef と比べてみました。

1. 検証の条件

データは Clef の検証と同じです。
日本語の請求書・見積書・領収書（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枚と抽出結果を渡し、項目ごとに predicate（yes の確率を返す質問）で「この値は画像に印字されたとおりか」を聞きます。
確率 0.5 未満を「誤り」と判定し、比較対象は clef・clef-flash（2026年10月4日の実測）です。
画像は元の PNG（1700×2200、約200〜300KB）をそのまま渡しました。
Clef では推定トークン数の上限を超えたため32色に減色した画像を使っており、画像の条件だけは Clef と異なります。

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

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

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

2. 結果

2.1 誤りを見つけられたか

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

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

• Haiku の誤りの検出：Haiku の出力に含まれる読み間違い19件のうち、「誤り」と判定できた件数

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

Decisions API は、注入した誤りと Haiku の読み間違いのどちらも、3つのモデルの中で最も多く検出できました。
一方で、誤検知は16件と clef（7件）の2倍以上になりました。

Decisions API は桁・似た文字・置き換えの誤りをすべて検出しましたが、全角と半角の入れ替えは Clef と同じく3件中1件しか拾えませんでした。
Decisions API が判定を誤った27件（Haiku の読み間違いの見逃し9件、注入した誤りの見逃し2件、誤検知16件）は次のとおりです。

Decisions API の誤検知16件のうち9件は、正解データの版で起きていました。
特に、Haiku が全角と半角を読み違えた領収書の数量では、正しい ３日 に 0.04、Haiku が読み間違えた 3日 に 0.98 を付けており、Clef と同じく全角と半角を逆に判断しています。

2.2 確率の分かれ方

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

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

Decisions API：注入した誤りは 0.0 付近に固まるが、Haiku の読み間違いは 0.0 と 1.0 の両端に分かれる

clef：注入した誤りは 0.0〜0.3 台に散らばり、Haiku の読み間違いの多くは 0.5 を上回る

clef-flash：clef に近い分かれ方だが、正しい値の一部と注入した誤りの一部が 0.5 をまたいで重なる

Decisions API は、注入した誤りの中央値が 0.0、正しい値の中央値が 0.99 と、英語のときと同じく確率が端に寄っていました。
Haiku の読み間違いも中央値は 0.34 と Clef（0.691）より低く出ていますが、見逃した項目には 0.9 以上を付けたものもあります。

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

Decisions API はしきい値 0.1 でも注入した誤りを33件拾え、誤検知は1件でした。

2.3 時間と費用

リクエストは書類1枚につき1回で、画像1枚とその書類の全項目に関する質問（30〜63問）をまとめて送っています。
3書類 × 4通りの抽出結果で、モデルごとに12回呼び出しました。
時間は日本国内から REST API を呼び出した際の実測値で、費用は1ドル150円で換算しています。

処理時間は Decisions API が clef の約半分で、費用も clef の約4分の3で済みました。
入力トークンは Clef の約1.8倍ですが、画像の条件（Decisions API は減色していない画像）が違うため、単純には比較できません。

3. まとめ

日本語の書類でも、Decisions API は注入した誤りを36件中34件、Haiku の読み間違いを19件中10件検出し、どちらも Clef の2モデルを上回りました。
OCR 結果のチェックでは誤りを見逃さないことが何より大事なので、日本語の書類にも比較的強いと感じました。
また、Clef のように画像を減色する必要がなく、元の画質のまま渡せる点も、細かい文字を読み取るうえでは有利だと考えられます。

一方で、誤検知は16件と clef（7件）の2倍以上あり、誤検知の少なさでは clef に及びませんでした。
全角と半角の違いも Clef と同じく見逃しやすく、Haiku が実際に起こした読み間違いの約半分は 0.5 以上の確率が付いて素通りしています。
全角と半角の区別は英語圏にはない概念なので、米国企業が開発したモデルは、Decisions API や Clef に限らずこの違いを苦手としやすいのかもしれません。