Decision 3.0とは？オープン意思決定モデルの仕組み・API・Jevとの違い

結論：生成AIの前後で使う「判断専用モデル」がオープン化した

Decision 3.0は、自由文を長く生成するLLMではありません。入力を読み、あらかじめ定義した候補から選ぶ、条件を満たす確率を返す、段階評価を付ける、といった構造化された判断を行います。返り値に各候補の確率とconfidenceが含まれるため、分類、ルーティング、承認ゲート、優先度付けをアプリケーションから扱いやすい点が特徴です。

対象はd3-edge 0.6Bからd3-turbo 27Bまでの6サイズです。すべてテキスト・画像・動画を入力でき、モデルの重みはApache 2.0で公開されています。小型モデルを端末や自社GPUで動かし、難しい判断だけ大きいモデルへ送る構成も検討できます。

注目点は、単なるJev互換モデルが増えたことではありません。vLLMがdecision modelをネイティブに提供し、Semantic Routerが判断結果をモデル選択や安全制御へ使えるようになったことで、分類モデル、LLM Gateway、推論ルーターの境界が近づいています。ただし、日本語性能、確率の校正、本番SLAは自社データでの確認が必要です。

この節の一次情報：vLLM-SR公式｜Decision 3.0 ／ Hugging Face｜vllm-sr/d3

開発元：vLLM Semantic Routerが作るdecision model

開発主体は、オープンソースの推論ルーティング基盤vLLM Semantic Routerです。同projectは、promptからdomain、language、PII、複雑さなどのsignalを抽出し、policyに従ってmodelや処理経路を選ぶdecision layerを開発しています。GitHubは2026年10月27日の確認時点で約6,300 stars、licenseはApache 2.0です。

Decision 3.0のtrainingはAMD vLLM-SR teamがPyTorchとAMD Instinct GPUで行ったと公表されています。モデル配布はHugging Face、local servingはvLLM Semantic RouterのEngine mode、hosted試用はDecision APIという構成です。

従来のrouterは、keyword rule、embedding similarity、専用classifier、別のLLMによる判定を組み合わせることが一般的でした。Decision 3.0は、複数種類の判断を共通interfaceで処理できるfoundation modelをrouter内部へ置く考え方です。routing用途に限定されず、ticket triage、画像検査、agent actionの許可判定にも使えます。

この節の一次情報：GitHub｜vllm-project/semantic-router ／ vLLM-SR公式｜System overview

仕組み：文章をdecodeせず、選択肢の確率を直接読む

Decision 3.0はQwen3.5系のbackboneに、answer codeをscoreする小さなreadoutを組み合わせています。入力stateと質問、選択肢を与えると、各質問について最後のtoken位置から候補のscoreを読み、確率として返します。通常の生成LLMのように、回答文を1 tokenずつdecodeしてJSONへ変換する方式ではありません。

choiceは複数候補から1つを選び、noulはYes／Noに相当する連続値、scoreは段階評価の期待値と各levelの確率を返します。d3-turboはstateを一度読み、同じ入力に対する複数質問を分岐させて処理します。入力の重い画像・動画を質問ごとに再計算しにくい設計です。

この構造は、出力tokenが0で、選択肢を追加しても長い説明文を生成しない点がコスト面の利点です。一方、候補にない答えを自由に説明する用途には向きません。判断理由が必要なら、根拠となるsignalを別途保存するか、選択後に生成LLMへ説明を依頼する二段構成にします。

この節の一次情報：vLLM公式｜Structured Decisions Models ／ vLLM-SR公式｜Model runtime reference

6モデルの仕様：0.6Bから27B、全サイズがmultimodal

2026年10月27日時点の公開familyは、d3-edge、d3-lite、d3-nano、d3-mini、d3-flash、d3-turboです。大きいほど公開benchmarkのscoreは高い傾向ですが、hardware、latency、memoryも増えます。d3-turboのtext・vision scoreは公式leaderboard確定値ではなく、model cardによる推定値として区別します。

d3-turboはChoice・noul・scoreに加え、画像内の位置を返すboxと、動画内の対象を追うtrackにも対応します。d3-flashのhosted APIはgrid scoringでboxを近似するため、1問当たり約18,000 input tokens、median約1秒という公式説明があり、通常のdecisionと同じ速度ではありません。

この節の一次情報：Decision API公式｜Models and limits ／ Hugging Face｜Decision 3.0 collection

API料金・仕様：hosted版は無料、self-hostはGPU原価

公開Decision APIは2026年10月27日時点で無料です。Base URLはdecision.vllm-sr.ai、endpointはPOST /v1/systemoneまたはPOST /v1/decisionsです。API keyを発行し、stateとquestionsをJSONで送ります。responseにはanswer、各候補のprobability、confidence、input_tokensが含まれ、decision modelは文章を生成しないためoutput_tokensは0です。

無料APIにはmodel別のrequest／tokenの毎分制限と日次quotaがあり、値は/api/infoで動的に公開されます。1 requestの制限時間は30秒で、混雑時は429、起動中は503、timeoutは504を返します。無料という表示を本番の容量保証やSLAと解釈してはいけません。

self-hostではtoken従量課金はありませんが、GPU・電力・運用・monitoringが原価です。小型modelのMac検証例はあるものの、公式のfull familyはAMD Instinct環境を中心に案内されています。月間原価は、1件当たりcompute時間、同時実行数、稼働率、必要VRAM、fallback APIを含めて算定します。

この節の一次情報：Decision API公式｜API reference ／ Decision API公式｜Terms

速度と評価：開発元測定と外部検証を分けて読む

Jev Decision Indexへの提出情報では、AMD Instinct MI325X上のmedian latencyとしてd3 27Bがtext 54.8ms・image 273.1ms、d3-flash 9Bがtext 19.1ms・image 149.4msと報告されています。これは開発teamによる提出値で、batch size、queue、network latencyを含む本番APIのp95ではありません。

外部contributorのFluid InferenceはM5 Pro搭載MacBook ProでCore ML版を検証しました。JevBenchのmedian requestはd3-lite 53ms、d3-nano 69ms、d3-mini 169msで、同じMac上のPyTorch版204ms、173ms、438msより2.5〜4倍高速でした。1 requestずつ、local HTTPを含む測定であり、server workloadのthroughputではありません。

benchmark scoreにも注意が必要です。Decision 3.0はJev Decision Indexで上位ですが、評価interfaceに近いmodel familyであり、日本語の社内ticket、規制文書、曖昧なlabel境界で同じ順位になるとは限りません。確率を閾値に使う場合は、accuracyだけでなくcalibration error、false positive、abstain率を測ります。

この節の一次情報：Jev Decision Index discussion｜Decision 3.0 submission ／ Fluid Inference｜Decision 3.0 on Apple Silicon

Jev・生成LLM・Semantic Routerとの違い

Jevはdecision modelというカテゴリを開発者へ広め、choice・predicate・scoreをAPIで扱う流れを作りました。Decision 3.0は同じ用途を、Apache 2.0のmodel familyとself-host可能なruntimeへ広げた存在です。Jevとの互換性やscoreの近さだけでなく、model size、multimodal入力、運用責任、data経路で選びます。

vLLM Semantic Routerはmodelではなくdecision layerです。Decision 3.0は、そのrouterがdomain判定、cost・quality優先度、safety gate、model selectionを決めるために利用できるmodelです。一般的なLLM GatewayがAPI key、retry、logging、provider接続を管理するのに対し、Semantic Routerはrequestの意味とpolicyから経路を選びます。

生成LLMは、候補を事前定義できない調査、説明、創作、code生成に必要です。Decision 3.0はLLMを置き換えるのではなく、LLMを呼ぶ前の分類、呼んだ後の検査、agent actionの許可判断を軽量化する役割です。

この節の一次情報：vLLM-SR公式｜Decision model selection

海外で注目されている根拠と、日本で広がる可能性

独立したadoption signalは複数あります。Semantic Router本体はGitHubで約6,300 stars、Decision 3.0のd3-miniはHugging Faceで約35,000 downloadsを確認しました。project側の記録では、公開postがr/LocalLLaMAのhot feedで1位となり、公開5時間で224 upvotes・272 sharesに達しています。

さらにvLLM本体がStructured Decisions Modelsとしてnative servingをdocument化し、Jev Decision Indexのcommunity boardへ6 modelが提出されました。単発の企業発表ではなく、model weights、runtime、benchmark、community discussionが同時に立ち上がっている点が強いsignalです。

日本で伸びる可能性がある検索意図は「意思決定モデル」「LLM分類モデル」「AIルーティング」「vLLM Semantic Router」「ローカルAI判定」です。日本企業は個人情報、社内文書、画像検査を外部APIへ送れない場合があり、0.6B〜4Bをlocalで動かせる選択肢には固有の需要があります。ただし、日本語のlabel nuanceや業界用語を検証した公開dataはまだ少なく、先行導入ほど自社evalが重要です。

この節の一次情報：GitHub｜Semantic Router stars・activity ／ Hugging Face｜vllm-sr models ／ vLLM公式｜Structured Decisions Models

向くケース・向かないケース

向くのは、候補や評価軸を事前に定義でき、同じ判断を大量に繰り返す処理です。問い合わせrouting、document分類、moderation、priority判定、model selection、画像の有無判定、agent actionのrisk gateが代表例です。複数質問を同じstateへまとめられるほど、state-onceの設計を活かせます。

向かないのは、正解候補を事前に列挙できない調査や、説明そのものが成果物となる業務です。また、法務、医療、与信、採用など不利益を伴う高risk判断をmodel単独で確定してはいけません。確率は責任の代替ではなく、人手確認へ送るthresholdとして使います。

• 向く：LLMへ送る前のmodel／reasoning tier選択
• 向く：問い合わせ・障害・請求書・agent traceの分類
• 向く：画像や動画を含む定型的な有無・選択・score判断
• 向く：機密dataを外部APIへ送れないlocal inference
• 向かない：自由な説明、creative writing、未知の選択肢探索
• 向かない：誤判定が重大な結果を生む完全自動の最終判断

制約・未検証事項

hosted Decision APIは無料ですが、requestとresponse、画像、動画がservice運用・改善・trainingのため保存・処理される場合があります。headerで無効化する仕組みはないとtermsに明記されているため、機密情報、個人情報、regulated dataは送れません。必要ならself-hostを選びます。

公開scoreの多くはJev Decision Indexに依存し、d3-turboの70.2／72.9はmodel cardによる推定です。日本語accuracy、domain shift、class imbalance、adversarial input、確率校正、long-running uptime、p95・p99 latencyは十分に独立検証されていません。

導入時は、rule-basedと既存LLM classifierをbaselineにし、precision、recall、false positive cost、abstain率、latency、1,000件当たりGPU秒、人手review率を比較します。最初から全routeを切り替えず、shadow modeで判断結果だけ記録し、誤判定の種類を確認してからtrafficを移します。

この節の一次情報：Decision API公式｜Terms and data use ／ Decision API公式｜Privacy

FAQ

Q. Decision 3.0はLLMですか？　A. transformer backboneを使いますが、自由文を生成するchat modelではなく、定義した質問へ選択・Yes／No・scoreと確率を返すdecision modelです。

Q. API料金はいくらですか？　A. 2026年10月27日時点のpublic Decision APIは無料です。rate limitと日次quotaがあり、将来の価格やSLAは保証されていません。self-hostはGPUと運用が原価です。

Q. 日本語に対応していますか？　A. text入力は可能ですが、日本語domain別の公開評価は限定的です。自社の実dataでlabelごとのprecision・recallを確認してください。

Q. Jevの代わりになりますか？　A. 候補にはなりますが、同じ用途でもAPI、model size、multimodal機能、latency、data処理、運用責任が異なります。互換性だけで置換せず並行評価します。

Q. LLM Gatewayとは何が違いますか？　A. Gatewayは認証、provider接続、retry、loggingなどを担います。Decision 3.0は判断model、Semantic Routerはその判断を経路選択へ使うlayerです。併用できます。

Q. 小型modelはどこで動きますか？　A. official runtimeはGPUを中心に案内されています。communityのCore ML版ではM5 Pro上でd3-lite・nano・miniが検証されていますが、本番support範囲は別途確認が必要です。

Q. 最初に何を試すべきですか？　A. 既存の分類taskを100〜500件用意し、d3-liteまたはmini、rule、現行LLMをblind比較します。誤判定costが高いclassはconfidence thresholdと人手reviewを設定します。