【geek-terminalニュース】Microsoft-Decision-1で決定モデル競争がカテゴリ化、生成器ではなく採点器をエージェント部品にする時代へ

以前お伝えしたJev/OpenJev系のDecision Model実装フェーズの続報です。前回は、出力トークンなしの小型Decision Modelをエージェントの停止判断、集中モード、ツールルーティングへ組み込む流れを扱いました。今回はそこから一段進み、Microsoft-Decision-1、Drex 1.5、OpenAI Decisions APIが同時期に話題化したことで、単発の実験ではなく“決定モデル”という市場カテゴリそのものが立ち上がり始めた、という話です。

【事象の全貌と背景】
Microsoftは2026年10月9日、Microsoft-Decision-1を発表しました。公式説明では、これはMicrosoft FoundryとOpenRouterで利用できる高速な決定スコアリングモデルで、用途はルーティング、分類、優先順位付け、検証、ワークフロー制御です。重要なのは、普通のLLMのように長い文章を生成するためのモデルではなく、事前に与えられた選択肢に対して確率やスコアを返す“採点器”として設計されている点です。

これまで多くのエージェント実装では、LLMに「次に使うツールをJSONで返して」「このタスクは完了したかyes/noで答えて」と聞き、その自由文やJSONをパースして分岐していました。しかし本番ではここが弱い。フォーマット崩れ、曖昧なconfidence、プロンプトの微妙な揺れによるルート変化、低確信なのに無理やりどこかの分岐へ流す事故が起きます。今回のトレンドは、その“LLMの返答を読んで判断する”層を、最初から判断専用のAPIまたはモデルに置き換える動きです。

【技術的ディープダイブ】
公式情報として確認できるMicrosoft-Decision-1の中核仕様は、Qwen3.5-9Bを基盤に事後学習した9B級モデルであること、固定された回答候補が与えられた場合に、それぞれの選択肢へ較正済み確率スコアを返すことです。対象形式としては、yes/no、多肢選択、評価尺度、AI応答やエージェント行動に対するルーブリック採点が挙げられています。つまり「この問い合わせはGPT-5へ送るべきか、軽量モデルで十分か」「このエージェント行動は承認ゲートを通してよいか」「この顧客チケットは緊急か通常か」を、文章生成ではなくスコアリング問題として処理するわけです。

Microsoftは構造化決定タスクでレイテンシと品質の両面で優位だと主張しています。ただし、ここはMicrosoft側の主張として扱うべきで、独立した第三者ベンチマークで全面検証済みという段階ではありません。ExplainXは価格として100万トークンあたり0.042ドルという情報を整理しつつ、速度・性能主張には独立検証がまだ必要だと見ています。DeepThinkはこの動きを、巨大LLMが読解、計画、ツール選択、分類、最終応答まですべて抱える設計から、専用の決定レイヤーへ分解する流れとして位置づけています。

競合側については、Nace.AIのDrex 1.5が9B決定モデルとしてオープンソース化されたと報じられています。状態と型付き質問を読み取り、各選択肢に確率を返すモデルで、Decision Index 0.3.1で58.08を記録し、10B未満カテゴリで上位とされています。ただしこれは公式・大手メディア側で同等に裏取りされた事実というより、現時点では報道ベースの情報として扱うのが安全です。OpenAI Decisions APIについても、テキストと画像入力から型付き回答、確率、選択、スコアを返し、Responses APIより約10倍速いとOpenAIチームが述べたと報じられていますが、Microsoft Foundryでの提供タイムラインについてはMicrosoft Learn上で確認済みの予定はないと説明されています。

【コミュニティの生々しい熱量と議論】
コミュニティの反応は、かなり実装者の匂いが濃いです。Reddit r/LLMDevsでは、あるユーザーが「このカテゴリの本質はsub-200ms decisionsだと思っていたが、Decisions APIはそのために作られた感じがしない」と失望を語っています。別のユーザーは、Jev系ゲートを日常的に回している経験から「200ms目標は正しい」「本番で必要なのはunresolved verdict、つまり分からないならスキップするゲートだ」と述べています。これはめちゃくちゃ重要です。決定モデルの価値は、常に正解を選ぶことではなく、低確信時に“選ばない”という実行制御を返せることにあります。

r/n8n側ではさらに現場感があります。「低信頼の選択には独自出力を持たせ、常にルートを選ばせない方がいい」「providerが受け付けた後にタイムアウトしたケースもテストすべき」「入力itemのidを保持しないとリトライで別ブランチへ静かに流れる」といった声が出ています。また、プロンプトドリフトでAIルーティングが壊れる問題に対し、型付き質問と生の質問別回答が返る設計はデバッグ性を大きく上げる、という評価もあります。これはノーコード/ワークフロー自動化界隈にとってかなり刺さる論点です。

一方、Hacker Newsにはいつもの冷水も飛んでいます。「regular LLM calls can’t provide a meaningful confidence score」という賛成寄りの短い指摘がある一方で、「Benchmarks or it didn’t happen.」「AI slop demo」といった懐疑もあります。つまり、カテゴリとしての方向性は理解されつつも、実運用で使うにはレイテンシ、キャリブレーション、失敗時挙動、ベンチマーク再現性を見せろ、という圧が強い。Lobsters側でも、派手なデモより評価設計や先行OSSとの新規性比較へ関心が寄っており、18ゲーム程度の実験ではノイズが大きい、多数試行と分布が必要だというギークらしい突っ込みが出ています。

【今後の展望とエコシステムへの影響】
この流れでオワコン化しそうなのは、「LLMに自由文で自己confidenceを語らせ、それをそのままif文に入れる」実装です。今後は、生成モデル、推論モデル、埋め込みモデル、決定モデルを分けて使う設計が普通になっていく可能性があります。生成器は文章や計画を作る。決定モデルは候補を採点する。ポリシーエンジンは閾値で止める。人間承認ゲートは低確信や高リスクだけ拾う。この分業が成立すると、エージェントは“賢いチャットボット”から、観測、採点、分岐、停止、監査を持つ実行システムへ近づきます。

特に編集長ポイントである「生成器ではなく採点器を実行部品にする」発想は、エージェント開発を一気に実装臭い話へ落とします。どのツールを呼ぶか。いつ止めるか。どの出力を人間レビューへ回すか。どのモデルへルーティングするか。これらは華やかなデモでは地味ですが、運用では最重要の分岐です。Microsoft-Decision-1の公式発表、Drex 1.5のオープンソース報道、OpenAI Decisions APIのベータ報道が重なったことで、決定モデルは“Jev周辺の変わった実験”から、“エージェントスタックの標準部品候補”へ昇格したように見えます。

ただし、勝負はこれからです。必要なのは、低遅延時の実測、確率の較正、未解決判定の設計、EU residencyやセルフホスト要件、OpenAI互換API間の構造化出力差分、そして「低確信なら第三出力へ流す」ような運用パターンです。決定モデル競争の本丸は、ベンチマークで1位を取ることだけではありません。実行ログに残り、監査でき、失敗時に静かに誤ルートしない“判断の配管”を誰が握るかです。AIエージェントの次の主戦場は、長文をうまく書く能力ではなく、毎秒何度も発生する小さな分岐を、安く、速く、説明可能にさばく能力へ移り始めています。