Microsoft-Decision-1：文ではなく数字で答えるMicrosoftのモデル

Microsoft-Decision-1 のモデルカードには、これまで他のどの Microsoft モデルも掲げたことのない一文がある: テキスト生成向けには設計されていない。、このモデルは Microsoft Foundry で一般提供が開始された2026年10月8日。これは、言語モデルの用途を意図的に絞り込んだものだ。ある状況と、回答があらかじめ決まった選択肢からなる質問——はい/いいえ、多肢選択、評価スケール、ルーブリック——を渡すと、各選択肢について較正された確率を返す。文章はない。説明もない。根拠を書く欄もない。出力は JSON の数値だけで、それ以外は何もない。これはオープンウェイトのQwen3.5-9Bを基に作られ、Microsoft によるポストトレーニングを経ている。そして Microsoft は、後に MAI や他のパートナーモデルを挙げつつ、このモデルを他のバックボーンに載せ替えると述べている。

それは、最初に聞こえる印象よりも風変わりな製品だ。2026年におけるMicrosoftの競争上の立場は、フロンティアのチャットモデルとCopilotに依拠しており、Microsoft-Decision-1はその両方の対極にある。中規模の単一用途スコアラーで、その仕事のすべては、アプリケーションに対して、あなた自身が用意した選択肢のうちどれが最も正しい可能性が高いか、そしてその確信度がどれほどかを伝えることだ。興味深い問いは、それが文章を書くのが得意かどうかではない——それは明示的に苦手で、そうしようともしていない——。そうではなく、選択肢に対する確率分布が、企業が実際に動かすワークロードにとって、JSONモードを備えた別の汎用モデルよりも有用なプリミティブなのかどうかである。

具体的な機能

契約は、入力が1回の呼び出し、出力が1つの分布だ。Microsoft は、サポートされている質問形式として、はい/いいえ、多肢選択、評価、分類、ルーブリックベースを挙げている。すべての選択肢にスコアが付く。モデルは、最大 32K トークンの入力に対して単一の呼び出しで実行される — 32,768 が公称コンテキストウィンドウだ — そして実用的な上限は、入力と選択肢セットの合計であり、生成予算ではない。なぜなら生成が存在しないからだ。

公開されているユースケースは、プラットフォームチームならすぐに認識するものです：

• AI出力の評価 — 生成された応答を、提供されたルーブリックに照らして採点する、またはその応答が与えられた根拠に基づいているかどうかを判断します。

• 分類とルーティング — リクエストを分類し、関連性を判断し、キューをトリアージし、ワークフローの分岐を選択する。

• エージェントのガードレール — 統合アプリケーションが実行を許可する前に、提案されたツール呼び出しやエージェントのアクションをスコアリングします。

• コンテンツ安全性スクリーニング — 固定的なベンダーポリシーではなく、アプリケーションが定義するしきい値に基づいてコンテンツにフラグを立てます。

• 検索と文書の関連性 — 検索された文書が与えられた質問に答えているかどうかを判断する。

• 信頼度ベースの自動化 — 信頼度の高い結果は自動承認し、それ以外は人にエスカレーションします。

棄権オプションは、注目に値する細部です。Microsoft は、提供された証拠が不十分な場合に「判断できない」などのオプションを明示的にサポートしています。これは、キャリブレーションされたスコアラーと、単に自信があるだけのスコアラーとの違いです。また、スコアは数値として返されるため、エスカレーションのしきい値はあなた自身が決めることです。0.7 なら人に回し、0.95 なら回さない、という基準を設定するのはあなたです。

実行しないこと

マイクロソフトは除外事項について異例なほど明確であり、実際のパイプライン向けにこれを検討する人にとっては、機能リストよりもそれらの方が重要です。Microsoft-Decision-1 は ではありませんテキスト生成、自由回答形式の質問応答、会話、翻訳、要約向けに設計されたもの。閉じた質問と定義された回答選択肢のないタスク、または入力にない知識を必要とするタスクには意図されていません。テキスト専用です。画像、音声、動画の入力はなく、出力もありません。説明や根拠は提供されません。

それらを一緒に読むと、うっかり越えやすい境界が浮かび上がる。これは、ついでに分類もしてくれるチャットボットではないし、スコアを後付けできる要約ツールでもない。トークン予算を伴うスコアリング関数だ。チーム自身の枠組み——人に関する重大な決定において唯一の自動意思決定者になるべきではなく、信用、雇用、住居、保険、教育、医療、法的権利「あるいは同様に重大な領域」に関わる決定の唯一の根拠になるべきでもない——も同じ方向を指している。これは決定の隣に位置するように設計されており、決定そのものになるようには設計されていない。

ベンチマークの状況は誰も記事にしたがらない話だ

数字はありません。Microsoft-Decision-1 の Microsoft Foundry カタログページには Benchmarks タブがありますが、数値は一切載っていません。代わりに記載されているのは、方法論の段落と定性的な主張です。モデルは「公開およびコミュニティの意思決定ベンチマークと、トレーニングに使用されていない保持された社内テストセットで評価された」とされ、Microsoft は「主要な意思決定モデルと同等で、同じ方法論で評価された他のオープンな意思決定モデルより優れている」と報告しています。また、使用された指標は精度、キャリブレーション誤差、安全性リコール、偽陽性率、公平性の一貫性で、選択肢の順序を変化させ、対応のある統計検定を適用しました。

それは、公表された結果が皆無のまま付けられた、真剣な方法論の説明だ。これは、今日の Microsoft-Decision-1 に関するあらゆる性能主張がベンダー申告によるもので、再現されていないことを意味しており、それを評価する誰にとっても正直な立場は、確率をそもそも有用にする唯一の特性であるキャリブレーションが、Microsoft の外部では検証されていないということだ。同社は、モデルが最も強いと考える領域と最も弱い領域を実際に名指ししており、これは見出しのスコアより有用だ。推論、ルール適用、プロンプトの書式に対する頑健性で最も強く、分類、検索、公平性、ツール利用、および大半の多言語タスクで競争力があり、専門領域の知識を要するタスクではより弱い。

自己申告された制限事項は、機能リストの前に読む価値がある。スコアは言い回しや選択肢の順序によって変動し得るし、不適切に組み立てられた質問でもスコアは返される。キャリブレーションは、慣れ親しんだタスクタイプで最も強く働く。古い知識に依存する可能性があり、説明は一切提供されない。多言語対応について：日本語、韓国語、アラビア語、ベトナム語、タイ語、トルコ語、ヒンディー語、ベンガル語、スワヒリ語、ヘブライ語、ペルシア語、ウクライナ語を含む25言語がサポート対象として挙げられているが、Microsoftはカバレッジ、品質、キャリブレーションが「言語によって異なる場合がある」と述べており、非英語、特に低リソース言語を性能不足の領域として挙げている。基盤となるQwen3.5-9Bは200以上の言語をサポートしているが、ポストトレーニングされたモデルはその4分の1しかサポートしていない。

どうやって手に入れるのか、そしてその費用はいくらなのか

Microsoft-Decision-1 は、Microsoft Foundry において「Direct from Azure」ポートフォリオの下でホスト型 API として提供されています。モデルの重みは配布されていません。これはオープンウェイトのリリースではなく、ダウンロード可能な Hugging Face リポジトリも存在しません。HTTPS リクエストを発行できるアプリケーションであれば、Foundry のエンドポイントと標準的な Azure 認証を使用して統合できます。デプロイの一覧には、従量課金制または予約済みプロビジョニング スループットでのサーバーレスおよび統合エンドポイントのオプションが、標準 SKU、バッチ推論は無効の状態で表示されており、トレーニングの開示情報によると、トレーニング データセットが初めて使用されたのは 2026 年 9 月で、現在も収集が継続中です。

価格はモデルページに公開されていません。カタログの価格フィールドは、入力料金と出力料金を記載する代わりに Microsoft のモデル価格ページへリンクしているため、Decision-1 呼び出しのトークンあたりのコストは Azure の価格表示画面で調べるか、請求書から読み取る必要があります。大量処理で決定あたりのコストをモデル化しようとする人にとって、これは実際のギャップであり、推計で済ませるのではなく率直に言っておく価値があります。実際に価格を調べる際に知っておく価値のあることが 2 つあります。コストに占める出力トークンの割合は 0% です。なぜなら、出力トークンが存在しないからです。また、バッチ推論はオフになっているため、生成モデルのようにバッチチャネルを通じて一括スコアリング実行を償却することはできません。

OrcaRouterがこの話のどこに関わるかというと、呼び出しの反対側です。当社はMicrosoft-Decision-1をホストしておらず、カタログにも載せていません。テキストではなく確率を返すモデルは、チャット補完をルーティングする先のモデルではないからです。当社が扱っているのは、生成を行う側の半分です。つまり、ルーブリックを書き、候補となる応答を起草し、あるいはDecision-1がその後に採点するツール呼び出しを生成するモデルです。これらは200以上のモデルを載せた単一のOpenAI互換キーの背後にあり、プロバイダーの定価を0%のマークアップでそのまま提供しているため、ジャッジモデルのベンダー値下げは当社側でもその当日に反映されます。あるモデルが書き、別のモデルが採点する評価ループを構築している場合、採点の呼び出しはMicrosoftへ送り、生成の呼び出しはどこへでも送れます。単一のジャッジではなくパネルが欲しいときに複数のモデルを単一の呼び出しへと組み上げるルーティングDSL経由も含めてです。

なぜスコアラーは、優れたチャットボットとは別の賭けなのか

マイクロソフトがここで売り込んでいるパターンは、すでにオープンな形で存在している。InternLMのIntern-Decision-4B、Liquid AIのd1-3B、Convai InnovationsのLaya、そしてJared PalmerによるKevファミリーはいずれも、テキストを生成せずに、与えられた選択肢に対する較正済みの分布を返す。その多くはApache-2.0の重みで、自分のハードウェア上で無償で実行できる。マイクロソフトの参入製品は、ベンチマークに依存しない3つの点で異なる。Azureの認証、課金、ガバナンスが付随するマネージドAPIであるため、Hugging Faceからのダウンロードでは適合しない企業調達の道筋に適合する。そのベースは9Bモデルで、この分野の大半より大きい。また、責任あるAIの評価と文書化された評価方法論が付属しており、これは規制対象の展開において実際のゲート要件であることが多い。

それが備えていないのは、数字だ。ブライアスコアと期待キャリブレーション誤差——0.8が0.8を意味するかどうかを教えてくれる2つの指標——を公表しているオープンな競合他社に対して、マイクロソフトは方法論を公表したが、結果は公表していない。独立したキャリブレーション検証が存在するまでは、Microsoft-Decision-1を防御可能な形で使う方法は、同製品自身のドキュメントが推奨する方法だ。すなわち、自分のユースケースを代表するデータで検証し、誤りのコストから閾値を設定し、常に棄権オプションを含め、順序が回答にバイアスを与えうる場合は選択肢の順序をランダム化し、重要なことには人間をループに入れておくことだ。それはどんなスコアラーにも良い助言だ。特に、社外の誰もそのキャリブレーションを測定していないスコアラーにとっては、なおさら良い助言だ。