Gemini Decision 1 で書類の値を突合し、Jev・Decisions API と比べてみた

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

値の一致チェックは、これまで正規表現やスクリプトで頑張っては、表記揺れや例外対応でエンジニアを悩ませてきました。
かといって一般的なLLMに任せると、柔軟に判定できる一方で処理に時間がかかり、API呼び出しコストもかさみます。
そうした課題に対して、文章を生成せず判定と確率値だけを返す decision model は、スピードとコストの両面を解決できる選択肢として注目されています。

ただ、これまで検証してきた decision model の中には、出力される確率が 0 や 1 に極端に張り付いてしまい、中間がほとんど出ないものもありました。「この確率って本当に適切なの？」と疑問に思うことも少なくありません。以前試した中では、TypeSafe の Jev は確率が 0 と 1 の間にも程よく散らばり、判断に迷ったケースを確率の低さから見分けられていました（OpenAI の Decisions API で書類の値の突合を試し、Jev・Clef と比べてみた | DevelopersIO）。

そこで本記事では、2026年11月11日に Google から新たに登場した「Gemini Decision 1」を使い、同様の突合タスクでどのような挙動を示すのか調査してみました（検証日は 2026年11月13日です）。
正答数だけでなく、Jev や Decisions API と比較して出力される確率が 0 や 1 に極端に張り付いてしまわないかどうかも中心に整理しています。

1. 検証の方法

1.1 データ

書類の項目の値を2つ並べたペアを107件用意しました。
次のような、判断に迷いやすいケースを意図的に混ぜています。

• 日付の書き方の違い（Sep 12, 2026 と 12/09/2026）

• 数値の区切りの違い（1.250,00 と 1,250.00）

• 会社名・住所の日英の表記の違い

• OCR の誤読（1,25O.00 の O）

• 値が無いことの表現の違い（空欄・N/A・該当なし）

• 合計と明細の照合（合計 500 KG と 明細: 500 KG / 500 KG）

各ペアに対して、次の2つの質問を日本語で投げかけました。

• 完全一致：値Aと値Bは、文字列として完全に同一か

• 意味の一致：値Aと値Bは、表記が違っていても同じ値を指しているか

1.2 リクエスト

3つのモデルに、同じ値・同じ質問文を送信しました。
Gemini Decision 1 は、noul の質問に criteria（yes と no の条件）を付けると受け付けないため、条件を質問文の後ろに書き足しています（Decisions API も同じ扱いです）。

{
  "model": "gemini-decision-1",
  "input": "{\"値A\": \"1,250.00\", \"値B\": \"1250\"}",
  "questions": {
    "exact": {
      "type": "noul",
      "instructions": "値Aと値Bは、文字列として完全に同一か。空白・記号・大文字小文字・全角半角の違いも「同一ではない」と扱う。\n「はい」となる条件：1文字も違わず完全に同じ\n「いいえ」となる条件：1文字でも違う"
    },
    "semantic": {
      "type": "noul",
      "instructions": "値Aと値Bは、表記が違っていても同じ値を指しているか。これは2つの書類の同じ項目を突合している場面での判断である。片方が明細の羅列で、もう片方が合計値の場合は、明細をすべて足し合わせてから合計値と比べること。\n「はい」となる条件：書式・言語・単位・略記の違いだけで、指している値は同じ。または明細の合計が合計値と一致する\n「いいえ」となる条件：指している値そのものが違う、または片方にしか値がない。または明細の合計が合計値と一致しない"
    }
  }
}

Jev は同じ内容を state と criteria で、Decisions API は predicate 型で送信しました。
検証では、ケースごとに3つのモデルを順番に呼び出しています。

1.3 指標

• 正答数：yes の確率が 0.8 以上なら「同じ」と判定し、正解と照らし合わせた数

• すり抜け：本当は違う値なのに「同じ」と判定した数。横突合では一番避けたい誤り

• 確率がちょうど 0 か 1 の件数：多いほど、迷ったケースを確率で見分けにくい

• 料金：1ドル150円で換算

2. 結果

2.1 正答数と速度・料金

意味の一致については、Jev がもっとも高い正答数となり、すり抜けもわずか1件でした。
Gemini Decision 1 は入力トークン数こそ最も少なかったものの、単価が Jev の約2.4倍のため、料金は Jev より少し高くなりました。

2.2 確率の散らばり

意味の一致の確率を、正解が「同じ」の69件と「違う」の37件に分けてプロットしました。私が一番気にしているのはここです。Decisions APIは過去に実施した時、0や1に張り付きました。
点1つが値のペア1件を表しており、破線はしきい値の 0.8 です。

意味の一致の確率（日本語の質問文、106件）

おーーーー、decision model では Jev 以来となる、それっぽい確率が出ています！
0 や 1 には張り付いていませんね。
中間層もそれなりにあります。

2.3 しきい値を変えたとき

しきい値を変えてみたところ、意味の一致の正答数とすり抜け件数は次のように変化しました（正答／すり抜け）。

Gemini Decision 1 は、しきい値を 0.9 に引き上げるとすり抜けが1件に減り、正答数も95件へと向上しました。

2.4 Gemini Decision 1 が外したケース

意味の一致で Gemini Decision 1 が外した12件のうち、すり抜けとなってしまった3件は次のとおりです。

3. 全件の結果

太字は、しきい値 0.8 で外したものです。

4. まとめ

Gemini Decision 1・Jev・Decisions API に、同じ107件の横突合を同日で解かせてみました。

意味の一致の正答数は、しきい値 0.8 では Jev が100件と最も多く、Gemini Decision 1 は94件、Decisions API は96件という結果でした。
速度や料金面でも Jev が最も有利で、Gemini Decision 1 は応答時間の中央値が約0.54秒と3つの中で一番遅く、料金も Jev の約1.4倍かかりました。速度はほとんど誤差だと思っています。

一方で、出力される確率の傾向は Gemini Decision 1 と Jev でよく似ていました。
Decisions API は83件で確率がちょうど 0 か 1 に張り付いてしまったのに対し、Gemini Decision 1 は0件で、判断に迷ったケースを確率の低さから拾い上げられる形になっていました。これは本当に嬉しいですね！

Gemini Decision 1 は、料金が Jev より多少高いものの、画像や PDF を同じ API で扱えるメリットも含めて、採用を検討する候補になりそうだと感じました。

ただ、今のところ Gemini Decision 1 を使えるのは Gemini Developer API（Google AI Studio の API キーで呼ぶ API）だけです。

Available on the Gemini Developer API (v1beta) with Gemini Decision 1 only.

引用元: Decisions API | Google AI Studio

あとは、Google Cloud の Gemini Enterprise Agent Platform（旧 Vertex AI。Vertex AI name changes | Google Cloud）でも使えるようになれば最高です！