文章を書かずに、決められた選択肢のどれに当たるかを確率つきで返すだけのAIモデルが、2026年の秋に相次いで出ています。
Cloudflare と Strands Agents は10月1日に、Microsoft は10月9日に同じ種類のモデルを公開し、OpenAI も10月6日に Decisions API を公開ベータにしました。
各社はこれを「decision model」と呼んでいて、日本語なら判断モデルと訳せます。
LLM と何が違い、どこで役に立つのかが分かると、エージェントの中で毎回大きなモデルに聞いていた小さな判断を見直すきっかけになります。
判断モデルとは
判断モデルは、入力された文章や画像について、あらかじめ用意した選択肢ごとの確率を返すモデルです。
答えの形は大きく3つあります。
| 問いの形 | 例 | 返ってくるもの |
|---|---|---|
| はい／いいえ | 商品の写真に傷があるか | 「はい」である確率（0〜1） |
| 選択 | どの部署が担当すべきか | 選んだ選択肢と、選択肢ごとの確率 |
| 評点 | 不具合の深刻さはどの段階か | 段階ごとの確率と、その加重平均 |
OpenAI のドキュメントでは、この3つをそれぞれ predicate・choice・score と呼んでいます。
評点は段階ごとの確率の加重平均なので、確率が0.1・0.7・0.2なら1.1のように、段階と段階の間の値にもなります。
文章を生成しないので、答えは必ず用意した選択肢のどれかに収まります。
判断モデルは、文章を書く力を手放す代わりに、速さと確率つきの答えを手に入れたモデルです。
仕組みと使い方は Decisions | OpenAI API にまとまっています。
文章を1トークンずつ作らないから速い
LLM は答えを1トークンずつ順番に作ります。
前のトークンが決まらないと次を作れないので、答えが長いほど時間がかかります。
判断モデルの計算は、入力を一度読み込んで、選択肢ごとの点数を並列に出すところまでです。
Cloudflare は Clef について、もとになる Qwen のモデルで入力を一度だけ処理し、正しい形の選択肢をまとめて採点すると説明しています。
Introducing Clef: our open-source decision models では、Clef が Jev と API の互換を持つことも書かれていました。
Strands Agents（エージェントを作るためのオープンソースの SDK）の Strands Decider 2B は、もっと作りが分かりやすいモデルです。
Qwen3.5-2B から文章を作る出力層を外し、選択肢の位置と答えの位置の内部表現を突き合わせる小さな層に付け替えています。
付け替えた層は約100万パラメータで、もとのモデル側の調整は LoRA によるものでした。
速さは、手元の RTX 3090 で中央値およそ115ミリ秒、M3 の MacBook で小さな問いならおよそ153ミリ秒と公表されています。
詳しい作りは Introducing Strands Decider 2B で読めます。
選択肢の外の答えや、形の崩れた JSON は返らない作りです。
OpenAI の Decisions API には、答えること自体を断る refusal という返り方も用意されています。
最初の判断モデルとして注目された Jev について、TypeSafe AI は「型の誤りは数学的に起こりえない」と書いています。
確率が付くことの意味
判断モデルの答えには、選択肢ごとの確率が付きます。
OpenAI のドキュメントには、「注文で二重に請求された」という苦情をどの部署に回すかを聞く例があります。
次のコードは、その例の問いと答えを抜粋したものです（私は手元で API を実行していません）。
// 問い（抜粋）
"choices": [
{"value": "billing", "description": "Payments, invoices, and refunds."},
{"value": "technical", "description": "Problems using the product."},
// shipping・other は省略
]
// 答え（抜粋）
"probabilities": [
{ "value": "billing", "probability": 0.95 },
{ "value": "technical", "probability": 0.02 },
// 省略
],
"confidence": 0.93この確率が役に立つのは、数字と実際の当たり方が合っているときだけです。
Microsoft は、90%と予測したものは代表的な事例で10回中9回ほど当たるべきだと書いています。
確率と正解率が合っている状態を、キャリブレーション（較正）と呼びます。
Strands と Cloudflare は、確率のずれを測る Brier スコアを評価や学習に使っていると説明していました。
LLM に「自信は何%ですか」と聞くこともできます。
ただ TypeSafe AI は、LLM はそう聞かれても自信を高めに言いがちで、答えも一貫しないと指摘しています。
判断モデルでは、その確率そのものが API の答えの一部です。
確率が分かると、「0.9以上なら自動で進め、それ未満は人に回す」のような分岐をコードで書けるようになります。
閾値については、自分のアプリの正解付きの例で決め、誤検知と見逃しのどちらが高くつくかで選ぶよう OpenAI のドキュメントが勧めています。
どこで使うのか
判断モデルの出番は、エージェントや業務の流れの中にある、答えの形が決まった小さな判断です。
各社が挙げている使いどころを並べると、次のようになります。
- 問い合わせの振り分け（どのチームが担当するか、急ぎか）
- モデルルーティング（どの LLM に任せるか）
- ツール選択（次にどのツールを呼ぶか）
- 評価（AI の出力が基準を満たしているか）
- ガードレール（危ない入力や操作を止めるか）
- データのラベル付け（感想や投稿をテーマに分ける）
Cloudflare は、社内の脅威情報チームでウェブサイトのドメインを分類するのに Clef を試しています。
ページの取得から分類までが2.2秒で、同じ流れを汎用の gpt-oss-120b で動かすと4.7秒かかり、返ってきた分類も2つだけでした。
Microsoft は、Xbox の調査部門が1万件を超える感想を決まったテーマに分けた例を挙げています。
品質は GPT-6 Sol と同程度で、14倍以上速く、費用は200分の1だったそうです。
Microsoft-Decision-1: Our model for fast decision-making には、ほかにも社内での試用例が並んでいます。
Strands のブログには、エージェントがツールを呼ぶ直前に判断モデルをはさむ例がありました。
「天気は？」と場所を言わずに聞かれたエージェントが、勝手に都市を決めて天気のツールを呼ぼうとする場面です。
呼ぶ前に判断モデルへ「引数はユーザーが言ったことに基づいているか」「ツールを呼ぶのはまだ早くないか」を聞き、その答えでエージェントは都市を聞き返す流れに戻ります。
LLM を毎回呼ぶには遅すぎる、高すぎる場所にも置けるのが、判断モデルの強みです。
AI が AI を採点する仕組みは、別の記事で整理しています。
質問ごとにモデルを選ぶ仕組みは、こちらの記事にあります。
構造化出力との違い
答えの形を固定するだけなら、構造化出力でもできます。
構造化出力は、LLM に JSON スキーマどおりの文章を生成させる仕組みです。
抽出した項目や説明文など、中身を自由に書かせたいときはこちらが向いています。
OpenAI のドキュメントも、決まった選択肢・確率・評点が欲しいときは Decisions、独自のスキーマで中身を作らせたいときは構造化出力と使い分けを示しています。
ツールを呼ばせたいときはファンクションコーリングを使う、という整理です。
主な判断モデル
2026年10月11日時点で、公式の発表やドキュメントで確かめられた主な判断モデルは次のとおりです。
| モデル | 提供元 | 提供の形 | 入力100万トークンあたりの料金 |
|---|---|---|---|
| Jev | TypeSafe AI | 早期アクセス | 0.042ドル |
| gpt-6-luna（Decisions API） | OpenAI | 公開ベータ | 0.10ドル |
| Clef／Clef-flash | Cloudflare | Workers AI・重みは Apache 2.0 で公開 | 0.24ドル／0.038ドル |
| Clef-omni | Cloudflare | Workers AI・重みは Apache 2.0 で公開 | 0.15ドル |
| Strands Decider 2B | Strands Agents | 重み・学習データ・スクリプトを Apache 2.0 で公開 | 手元で動かす |
| Microsoft-Decision-1 | Microsoft | Microsoft Foundry・OpenRouter | 0.042ドル |
TypeSafe AI・OpenAI・Microsoft の3社は、出力には料金がかからないと明記しています。
Cloudflare・Strands Agents・Microsoft のモデルは、どれも Qwen のモデルを判断用に追加学習したものです。
Clef-omni は文章と画像に加えて、音声と動画もそのまま受け取れます。
Clef-omni と値下げの詳細は Introducing Clef-omni with full multimodality に書かれています。
落とし穴
判断モデルを使うときに気をつけたい点は、次の4つです。
文章を書く仕事はできない
Strands のブログは、判断モデルは複雑な問題を解くのが推論モデルよりかなり苦手で、コーディング・チャット・要約にも向かないと書いています。
LLM の代わりにはならず、LLM の手前や横に置く部品と考えたほうが合います。
Strands も、難しい判断は LLM に、決まりきった判断は判断モデルに任せる組み合わせの試みを紹介していました。
選択肢の外側を用意しておく
判断モデルは、答えるときは必ず選択肢のどれかを返します。
どの選択肢にも当てはまらない入力も、どこかに振り分けられてしまいます。
OpenAI のドキュメントは、other のような受け皿の選択肢を入れ、そこに入ったものは人の確認に回すよう勧めています。
前の答えで次の問いが変わる判断（傷があるなら修理の種類を選ぶ、など）は、リクエストを分けるようにとも書かれていました。
ベンチマークの数字は各社の自己申告
Microsoft は自社で比べた36のベンチマークで最も正確だったと書き、Cloudflare も Clef が Jev Decision Index で首位だとしています。
どちらも自社で測った比較で、条件はそろっていません。
TypeSafe AI も、評価の基準にした答えが OpenAI と Anthropic のモデル寄りに偏っている可能性を自ら認めています。
選ぶときは、自分の業務の正解付きデータで、正解率と確率の当たり方を測るのが確実です。
Jev を発表した Introducing System One Models & Jev には、こうした数字の但し書きもまとめて載っています。
選択肢の数と入力の長さに上限がある
Jev が一度に扱える選択肢は255個までです。
Cloudflare は Clef-flash の値下げと引き換えに、ホスト版で受け付ける入力の長さを64Kトークンから24Kトークンに縮めました。
長い入力や選択肢の多い問いを渡す前に、モデルごとの上限を確かめておく必要があります。
最後に
判断モデルは、答えの形が決まった判断を、LLM より速く安く、確率つきで返すためのモデルです。
文章を書く力はないので、要約や対話はこれまでどおり LLM の仕事になります。
エージェントの中で「急ぎか」「どのツールか」「合格か」を毎回大きなモデルに聞いているなら、そこを判断モデルに置き換えられるか測ってみる価値があります。
以上です。
コメントを残す