OpenAI の Decisions API で書類の値の突合を試し、Jev・Clef と比べてみた

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

請求書と発注書を照合するような書類の突合では、2026/09/12 と 2026年9月12日、株式会社サンプル商事 と サンプル商事株式会社 のように、人が見れば同じ値でも文字列としては一致しない表記ゆれがよく起きます。
Cloudflare の Clef で書類の値の突合をさせて、Jev と比べてみた | DevelopersIO で、この「同じ値を指しているか」の判定を TypeSafe の Jev と Cloudflare の Clef で試してみたところ、Jev は107ケース中96件を正しく判定できた一方、clef は質問文を日本語にすると76件まで正答数が落ちました。

そこで本記事では、同じ107ケース・同じ質問文を OpenAI の Decisions API（モデルは gpt-6-luna）に渡し、Jev や Clef と比べてみました。

1. 検証の条件

• データ：上記の記事と同じ107ケース（日付・金額・取引先名・住所・OCR 誤読・欠損など10カテゴリ）。すべて架空の値で、日本語と英語の表記が混ざる

• 判定の軸：exact（文字列として完全に同じか）と semantic（表記が違っても同じ値を指しているか）の2問を predicate（yes の確率を返す質問）で聞く

• 質問文の言語：モデルに渡す指示を英語にした場合と日本語にした場合の2パターン。突合する値A・値Bは共通

• 閾値：0.8。確率が 0.8 以上なら「一致」と判定する

• 比較対象：Jev（2026年9月20日、jev-1.13.0）と Clef（2026年10月4日、clef・clef-flash）の結果

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

{
  "model": "gpt-6-luna",
  // 突合する2つの値（請求書の値と発注書の値）
  "input": "{\"value_a\": \"2026/09/12\", \"value_b\": \"2026年9月12日\"}",
  "questions": [{
    "type": "predicate", // yes/no の質問。yes の確率を返す
    "name": "semantic",
    // 表記が違っても value_a と value_b は同じ値を指しているか（2つの業務書類の同じ項目の照合。一方が明細、他方が合計なら明細を足して比べる）
    // True の条件：書式・言語・単位・略記だけが違い値は同じ、または明細の合計が一致
    // False の条件：値そのものが違う、一方に値がない、または明細の合計が一致しない
    "instructions": "Do value_a and value_b refer to the same underlying value, even when they are written differently? ... \nTrue when: Only the format, language, unit, or abbreviation differs ...\nFalse when: The underlying value itself differs, one side has no value, ..."
  }]
}

Jev や Clef では true と false の条件を criteria に分けて渡していましたが、Decisions API の predicate には対応するフィールドがないため、instructions の末尾に追加しています（Decisions API | OpenAI API）。

2. 結果

2.1 全体

各モデルが出力した確率が 0.8 以上の場合を「一致」と判定して集計した結果は次のとおりです。
semantic の正答数は、正解が決まっている106ケースで集計しています。

Decisions API は exact で Jev と同じ106件を正しく判定し、semantic は英語90件・日本語91件と、clef（英語）とほぼ同等の結果でした。
clef とは異なり、Decisions API は質問文を日本語にしても正答数が落ちませんでした。

Decisions API が閾値 0.8 で外したケースには、次の2つの傾向がありました。

• 欠損：片方または両方の値が空のケースは、Jev・Clef と同じく Decisions API も判定を誤りました

• OCR で崩れた文字列同士：DOC-O0O12345 同士（1-7）や INVO1CE 同士（7-7）のように、完全に同じ文字列でも確率が 0.66〜0.77 にとどまりました。整った文字列同士（1-1 など）には 0.91 以上を付けています

2.2 費用

Decisions API の費用は clef の約6割で、Jev の約2.3倍でした。

2.3 全ケースの確率

3. まとめ

Decisions API は、exact で Jev と並び、semantic でも日本語の質問文で正答91件と安定した結果を出しました。
Clef と違って質問文を日本語にしても精度が落ちなかったので、日本語にも十分強いと感じました。

実行時間は Decisions API が最も短くなりましたが、その時点のサーバーの混み具合でも変わるため、今回の 0.3〜0.7秒程度の差は誤差の範囲だと考えています。
AI システムに組み込む場面で1秒を切る応答を求められることはあまりないので、速度はそれほど気にしなくてよさそうです。

一方で、料金は Jev が Decisions API の半分以下で済みます。
処理する件数が多い業務では、この2倍以上の差は効いてきます。

また、適切な閾値はモデルごとに異なります。
システムに組み込むときは、実際のデータで確率の分かれ方を確かめてから閾値を決めるようにしてください。