Decision Model と LLM-as-a-Judge: Jev、OpenAI の Decisions API、そして確率を較正するのは誰か

Decision Model とは、文章を書くことを禁じられた言語モデルです。ドキュメントと型付きの質問を渡すと、型付きの答えが返ってきます。ある記述が正しい確率、列挙した選択肢に対する分布、あるいは自分で定義したスケール上の位置です。パースすべき自由文はありませんが、答えが間違っている可能性はもちろん残ります。10 月 6 日、OpenAI はこれを専用エンドポイントの Decisions API として公開しました。動くモデルは gpt-6-luna の 1 つだけです。9 月に公開された TypeSafe AI の Jev、そしてオープンウェイトの 2 モデル、Convai Innovations の Laya と AWS Strands Labs の Strands Decider 2B に並ぶ形になります。

ベンダーが売っているのは速度と価格で、どちらも本物です。ただ、ここで検討したいのはすべての答えに付いてくる数字のほうです。確率はソフトウェアがそのまま使えるもののように見えます。0.8 を超えたらルーティング、0.95 を超えたらブロック、という具合です。コードを 0.8 で分岐させる前に、0.8 が本当に 10 回中 8 回を意味すると誰が確かめたのかを知りたいところです。4 社のドキュメントを最後まで読むと、どこも同じ答えにたどり着きます。較正そのものを製品にしている 1 社も含めて、答えは「あなた自身」です。

Decision Model とは何か。Jev、Laya、Strands Decider、OpenAI の Decisions API はどう違うのか

Decision Model は、非構造の入力と 1 つ以上の型付き質問を受け取り、数値スコア付きの型付き判断を返します。ここで比べる 4 つは、3 つのプリミティブを共有しています。Yes/No の述語 (predicate)、1 つを選ぶ選択 (choice)、順序付きのスコア (score) です。違いはウェイト、入力の種類、価格にあります。

OpenAI のガイドは、この API が型付きの答えを「about 10x faster than the Responses API」で返すと述べていますが、測定方法は公開されていないベンダー側の数字です。使うべきでない場面も書かれています。独自の JSON スキーマを生成するなら Structured Outputs、ツール呼び出しなら Function Calling です。TypeSafe の発表記事はトレードオフをはっきり書いています。Jev は「gives up string generation」。Strands Decider は Qwen3.5-2B からテキスト生成用のヘッドを取り除き、渡された選択肢を採点する約 100 万パラメータのポインタヘッドに置き換えたものです。

Decision Model はどこで使えるか。ベンダーが挙げる 7 つのパターンを Red Hat のベンチマークで確かめる

以下はベンダー自身が挙げる用途です。Red Hat の比較ベンチマークが関係するのはそのうち 3 つで、残りは報告ベースのパターンです。ベンダーの主張である箇所はそう明記します。

Decision Model はワークフローの if 文を置き換えられるか

はい。TypeSafe が真っ先に挙げるのがこの用途で、「smart if-statements」や、大きなデータセット全体に 1 つの質問を map-reduce する使い方です。入力 100 万トークンあたり 0.042 ドル、出力無料なら、サポートチケット 100 万トークン分に Yes/No の質問を 1 つ投げても約 4 セントで済み、答えはコードがそのまま分岐できる数値で返ってきます。この売り文句を地に足の着いたものにしているのが、Jev 自身の弱点ページです。算術、数え上げ、日付の比較、16 進数や RGB 値は信頼できないと書かれ、それらはコードでやるよう勧めています。判断は Decision Model が答え、計算は相変わらずコードが担います。

Decision Model はエージェントでリクエストのルーティングやツール選択ができるか

ベンダーはできると言っています。Strands は、うまく動くのを確認した用途として「model routing, tool selection, evaluations, guardrails, memory, context management, and policy classification」を挙げています。これは8 月にワーカーモデルについて書いた論点の延長です。モデルは役割の席に合わせるもので、選ぶだけの席に文章を書けるモデルは要りません。注意点は Strands のモデルカードにあります。「With the state and options fixed, a changed question often gets the same answer.」質問を無視するルーターでも、1 つの質問から作ったテストセットでは良い結果に見えます。入力だけでなく、質問を変えてテストしてください。

Decision Model は平易な英語で書いたポリシーでのコンテンツモデレーションに使えるか

Red Hat の数字がいちばん好意的なのがここです。クラスバランスを取った英語データセットで 9 モデルを比べた比較では、コンテンツ安全性で Jev が 86.2% と最高で、Judge としての Qwen3.6-35B (85.5%)、IBM の 125M パラメータの Granite Guardian HAP 分類器 (80.3%) を上回りました。Granite のレイテンシは中央値 33 ms、Jev は 360 ms で、Jev の数字にはローカルモデルにはないネットワーク往復が含まれます (著者は最低でも約 56 ms と見積もっています)。TechCrunch は、モデレーション特化の新顔として Musubi のオープンウェイトモデル PolicyLM-1.7B を報じています。売りは、平易な英語で書いたポリシーを再学習なしで変更できることです。この売り文句は、後のポリシーの節と照らし合わせて読んでください。

Decision Model はプロンプトインジェクション対策のフィルタとして優秀か

フィルタとしては十分戦えますが、最良ではありません。Red Hat のプロンプトインジェクションのデータセットでは、Judge としての Qwen3.6-35B が 89.3% で首位、プロンプトインジェクション向けに学習した Protect AI の 200M パラメータの DeBERTa-v3 分類器が 89.0% (サマリー表では中央値 54 ms、付録の表では 80 ms)、Jev が 86.4% で中央値 348 ms でした。より根本的な限界は TypeSafe 自身が書いています。

State is data, and jev-1.13 does not treat it as hostile by default.
Content written to adversarially steer the model, whether that is an
injected instruction, a deliberately misleading framing, or text that
argues for its own classification, can move the answer.

ベンダーとして誠実な記述で、Your approval gate is a guess now で書いた議論のベンダー版でもあります。類似性で判断するモデルは、順位付けやフィルタはできても、境界にはなれません。Decision Model は、API がきれいになっただけの同じ推測です。段落より浮動小数点数のほうがしきい値は決めやすいものの、意味についての判断であることに変わりはなく、意味はどんな検出器もすき間を埋められない側にあります。人の目に届くものを仕分けるのに使い、アクションの制御はハーネスが許可する範囲で行ってください。

Decision Model は評価や採点で LLM-as-a-Judge の代わりになるか

部分的には。score プリミティブはルーブリック採点向けに作られていて、Strands も用途に評価を挙げています。ただし失敗のパターンは見慣れたもので、目立たなくなっただけです。Jev のドキュメントによると、選択では「leans toward the option that comes first」傾向があり、選択肢の順番を入れ替えて答えが変わらないか確かめるよう勧めています。Laya のカードによると、Yes/No プリミティブは「can follow its option labels instead of the state」ことがあり、順序スコアがいちばん弱いプリミティブです。段落を書く Judge なら、少なくとも確認できる根拠が残ります。その根拠が本当に判断の理由だという保証はないにしてもです。Decision Model には確認できるものが何もありません。Simon Willison は Jev について「the only thing you’re going to get back is a floating point number」と書いています。監査する評価にとって、これは機能ではなくコストです。

Decision Model で画像のトリアージはできるか

この 4 つの中では OpenAI のものだけができます。gpt-6-luna は画像をインラインの base64 で受け付け (ホストされた URL やファイル ID は非対応)、ガイドの例には損傷検出も含まれています。Simon Willison のプラグイン記事には、ペリカンの写真に哺乳類が写っているかを尋ねたときの答えの形が載っています。

{"type": "predicate", "name": "evaluation", "probability": 0.0}

簡単な質問にきれいなゼロが返るのはデモです。難しい写真で 0.3 が出たとき、それが 30% の確率を意味するのかどうか。この記事の残りはその問いについてです。

API を呼ぶ代わりにオープンな Decision Model をファインチューニングすべきか

ラベルがあるなら、オープンモデルはまさにそのために作られています。Laya のモデルカードは珍しいほど率直です。「Laya is a fast base to specialise, not a zero-shot decision engine.」ベースのチェックポイントは自前の型付き判断ベンチマークで 0.362 と、多数派クラスのベースライン 0.461 を下回り、そのベンチマークの学習用分割でファインチューニングした版は 0.766 です。Red Hat は Laya をファインチューニングせずポリシープロンプトで動かし、コンテンツ安全性で 57.9% の最下位でした。タスクも設定も違うので、判定としてではなく並べて読んでください。Strands は学習スクリプトを公開しており、モデルカードによると再学習の手順一式は H100 8 枚で約 70 分です。

Decision Model の確率にしきい値を設定できるか

ベンダーの言葉だけを根拠にするのは無理です。このカテゴリのどのベンダーも、数字に基づいて動く前に自分のデータで検証するよう求めていて、2 社はさらに確率そのものを自分で再フィットするよう求めています。約束の大きいほうから小さいほうへ、順に読んでみます。

TypeSafe は較正を製品の核として売っていて、Reinforcement Learning for Calibrated Decisions と呼ぶ手法で学習しています。

Always communicates confidence and uncertainty with every output.
Calibrated: higher confidence means higher accuracy.

発表記事にも弱点ページにも、それを裏付ける較正誤差の数値は載っていません。弱点ページの助言は、デプロイ前に自分の統合を徹底的にテストせよ、というものです。Strands は、ある種類のデータで較正をフィットしたことを明記しています。

Calibration is one temperature per primitive, fitted on held-out short
classification. The confidence bands are established there only:
measure on your own traffic before you trust a threshold.

Laya は数字を公開していて、だからこそ 4 つの中でいちばん役に立つカードです。

Ships over-confident: Refitting one temperature per (question type,
option count) moves mean ECE 0.466 → 0.081 (laya) and 0.314 → 0.106
(laya-multilingual). Do this on your own data before trusting the
probabilities.

同じカードには、Laya の act/escalate 確率は「carries no usable signal yet」とあります。ほぼすべての入力で 1.0 を示し、生のシグナルは正解と逆向きに動きます (ラベル付きの判断 396 件で AUROC 0.30)。自動化したいまさにその判断の名前が付いたフィールドこそ、無視すべきものだということです。

このカードは、著者自身の測定ではなく第三者の報告として、Jev が DAIR Emotion の例の 16% で正解ラベルに確率ゼロを付けたことも紹介しています。較正されたモデルでも間違えることはあります。しかしゼロは、正解の可能性がまったくないと言っているのです。

いちばん語らないのが OpenAI です。ガイドは別フィールドの confidence がどう計算されるかを一度も定義しておらず、しきい値についての助言も短いものです。

Use labeled examples from your application to set thresholds for
routing, filtering, or review.

これらの引用には 3 つの異なる指示が含まれていて、分けて考えると役に立ちます。検証は、自分のトラフィックでモデルがどれだけ正しいかを教えてくれます。較正は、スコアの意味を変えて、0.8 が本当に 10 回中 8 回になるようにします。しきい値は、あるスコアで何をするかを決めるもので、役に立つしきい値に完璧な較正は要りません。それぞれのカットオフのコストが見えるだけのラベル付きの例があれば十分です。3 つとも、必要な材料は同じです。Decision Model もラベル付きデータを必要とします。必要になるのが学習時ではなく、しきい値を決めるときだというだけです。温度の再フィットは分類器の学習よりずっと小さな推定問題なので、必要なラベルは少なくて済みますが、初日から必要で、しかも自分のトラフィックに近いものでなければなりません。その見返りは、何も学習しないうちに使える最初の答えと、テキストを編集するだけで変更できるポリシーです。

ポリシーの文面は Decision Model そのものより重要か

Red Hat の設定では、ポリシーが精度を動かした幅は大半のモデル間の差より大きかったので、ポリシーの変更はモデルの変更として扱ってください。Laya のコンテンツ安全性ポリシーを組み直し、有害カテゴリごとに独立した Yes/No の質問に分け、どれか 1 つでも 0.5 を超えたらブロックするようにしたところ、Laya は 57.87% から 75.20% へと 17.33 ポイント上がり、レイテンシの中央値は 118 ms から 289 ms と 2 倍以上になりました。同じ調整済みポリシーを Jev に渡すと、Jev は 3.67 ポイント下がりました。

つまり、ポリシーは Decision Model 間で使い回せず、1 つのモデルの中でも中立ではありません。これが「再学習不要」という売り文句の落とし穴です。ウェイトは変わりませんが、精度は変わります。しかもどちらに変わるかは測ってみるまでわかりません。評価の数字を見ていない人が平易な英語でポリシーを編集できるなら、コミットのたびにテストスイートを回すのと同じように、編集のたびに評価セットを回す必要があります。同じベンチマークの限界がもう 1 つあります。英語のみで、Decisions API がパブリックベータになる 4 日前に公開されたもので、OpenAI のモデルは試していません。

Decision Model、ファインチューニング済み分類器、LLM Judge: 今週どれを選ぶべきか

間違えたときにそのタスクが自分に何をもたらすかで選び、何かを選ぶ前にラベル付きのセットを作ってください。ここまでの材料から見た読みは次のとおりです。

攻撃を受ける固定タスク、つまりプロンプトインジェクションや既知の悪用パターンには、小さなファインチューニング済み分類器が向いています。Red Hat のテストでは、最良の Judge との差は 0.3 ポイントほどで、レイテンシはごく一部で済み、誰かがプロンプトを編集しても挙動は変わりません。フィルタとして使い、境界には決して使わないでください。

頻繁に変わるポリシーで、間違いのコストが人によるレビューで済む場面こそ、Decision Model が本領を発揮するところです。ポリシーを編集し、評価セットを回し、その日の午後には変更をリリースできます。間に学習の工程は挟まりません。

説明が必要な判断、監査や異議申し立てを受けうる採点には、LLM Judge か、争いのあるケース用に Judge を後ろに置いた Decision Model が向いています。Judge の根拠は判断の理由の証明にはなりませんが、裸の浮動小数点数では、異議を申し立てる人が反論する材料が何もありません。

ラベル付きのセットは、選択よりも長く残る部分です。Decision Model のしきい値を決め、比較のために試すどの分類器や Judge の評価にも使えます。ただし一部をどのフィッティングにも使わずに取っておき、ポリシーが変わったらラベルも見直す必要があります。これらの製品は出てきて数週間で、モデルはいずれ置き換えられます。自分のトラフィックからラベルを付けた例は、最終的にどのモデルが勝っても持っていける唯一の資産です。どのベンダーのドキュメントも最後にそれを求めているのですから、まずそれを作ってください。