Microsoftは10月9日、文章による回答を生成する代わりに、あらかじめ用意した選択肢ごとに確率を返すAIモデル「Microsoft-Decision-1」を発表した。Microsoft Foundryで一般提供されており、OpenRouterからも利用できる。AlibabaのQwen3.5-9Bを追加学習したモデルで、問い合わせの分類やAIエージェントの行動評価など、大量の判断を低コストかつ高速に繰り返す用途を想定している。MicrosoftはGPT-6 Solと比べて約35倍の速度をうたうが、判断専用モデル同士の差はそれほど大きくなく、第三者による応答時間の測定結果も公式値とは異なる。選択肢を高速に評価できるからといって、業務上の判断をそのまま任せられるとは限らない。
Qwenを基に、文章生成ではなく判断に特化したモデルを開発
Decision-1への入力は、判断に必要な情報を指定するstateと、その情報について尋ねるquestionsで構成される。Microsoftの開発者向け文書によると、入力データにはテキストとJSONの両方を使用でき、同じ情報に対して複数の質問を一度に送ることも可能だ。質問自体は文章で記述できるが、モデルが返すのは説明文ではなく、数値による判断結果となる。
例えば、顧客からの問い合わせを適切な担当部署へ振り分ける場合、「請求」「技術」「アカウント」「要確認」といった選択肢を用意し、それぞれの担当範囲を指定する。モデルは最も適切と判断した選択肢と、各選択肢に該当する確率を返す。実際の問い合わせの転送や返信は、その結果を受け取ったアプリケーション側が実行する。これは仕組みを説明するための例であり、Microsoftが公表した導入事例ではない。
APIは、条件が成立する確率を返すnoul（真偽判定）、複数の候補から1つを選ぶchoice（選択）、段階的な評価基準に沿って採点するscore（評価）の3種類に対応する。AIが生成した回答やエージェントの行動案を、あらかじめ設定した基準で評価することも可能だ。
これにより、生成AIが回答を作成し、Decision-1がその内容を評価するといった役割分担ができる。
基盤となっているのは、90億パラメータのQwen3.5-9Bだ。Microsoftは公開データと合成データを使って追加学習を行い、1回の推論で各選択肢を評価できるよう調整したと説明している。既存の言語モデルを判断処理向けに最適化したものであり、従来のLLMとは根本的に異なる新しいAI技術を開発したわけではない。
一方、元のQwen3.5-9Bが持つ機能をすべて利用できるわけでもない。Qwen3.5-9Bは画像を扱う機能を備えているが、Decision-1のモデルカードでは、テキスト専用モデルと明記されている。
入力上限は32,768トークンで、自由な会話や翻訳、要約などは想定されていない。また、内部でどのように選択肢を評価しているのか、追加学習にどのような手法を用いたのかといった詳細までは明らかにされていない。
GPT-6 Sol比「35倍高速」は、何を比較した結果なのか
Microsoftの発表で示された性能比較は、正答率、応答時間、確率の校正という3つの指標を分けて見る必要がある。
正答率の評価には、学習時に使用していないという36種類のベンチマーク、計147,137問が使われた。以下はMicrosoftが公開した比較表から、主要なモデルを抜き出したものだ。
| モデル | 平均正答率 | 応答時間の中央値（p50） | 確率校正スコア |
|---|---|---|---|
| Microsoft-Decision-1 | 83.5% | 85ミリ秒 | 92.2 |
| Jev 1.13.0 | 82.3% | 240ミリ秒 | 93.7 |
| Quyet-1.0-Large | 81.9% | 380ミリ秒 | 93.1 |
| GPT-6 Luna Decisions | 79.4% | 300ミリ秒 | 89.9 |
| GPT-6 Sol | 未掲載 | 3,010ミリ秒 | 未掲載 |
正答率と確率校正スコアは、Microsoftによる36種類のベンチマーク評価に基づく。確率校正スコアは、モデルが示す確率と実際の正答率がどの程度一致しているかを表す指標で、完全に一致する場合は100となる。正答率そのものを示す数値ではない。
また、応答時間については、脚注によると、2026年10月7日に確認したJevBench v1.6.1の調整済み中央値を使用している。ただし、Decision-1の85ミリ秒は、Microsoft Foundryで同一リージョン内から測定した値だ。したがって、表に並ぶ3種類の指標が、すべて同一条件の試験で測定されたわけではない。
公表された応答時間から計算すると、Decision-1はGPT-6 Solの約35.4倍、判断専用モデルであるGPT-6 Luna Decisionsの約3.5倍の速さとなる。
計算式は、それぞれ3,010÷85≒35.4、300÷85≒3.5だ。
つまり、Microsoftが強調する「約35倍」は、汎用モデルのGPT-6 Solと比較した数字であり、同じく判断処理に特化したモデルとの差ではない。また、異なる測定条件で得られた公表値を単純に比較したもので、すべてのモデルを同時に同一環境で測定した結果でもない。
アプリケーション全体が35倍高速化するという意味でもない。検索や外部ツールの実行など、判断以外の処理にかかる時間は別に考える必要がある。
正答率ではDecision-1が首位となった一方、確率校正スコアではJevとQuyetに次ぐ3位だった。
正しい選択肢を選ぶ能力と、自分の判断がどれほど正しい可能性があるかを適切な確率で示す能力は異なる。なお、GPT-6 Solの正答率は比較表に掲載されていないため、処理速度が速いことを根拠に、判断精度でも汎用モデルを上回るとは結論できない。
第三者の実測では459ミリ秒、公式値の85ミリ秒とは差
判断専用モデルを独立して評価しているBenchmark HeavenのJevBenchも、10月10日にDecision-1の評価結果を追加した。
この評価では、Azure Foundryに直接送信した非公開問題1,200件と公開問題300件を使用。応答速度の測定に使われた124件のリクエストでは、応答時間の中央値が459ミリ秒となった。Microsoftが公表した85ミリ秒を、そのまま実際の利用環境での応答時間と考えることはできない。
同日時点のAPIランキングでは、Decision-1は27モデル中6位で、総合スコアは69.11だった。
ただし、69.11という数値は正答率69.11%を意味しない。判断能力や確率校正に加え、処理速度と料金も同じ重みで評価するJevBench独自の総合指標だ。使用した問題や集計方法も、Microsoftによる36種類のベンチマーク評価とは異なる。
JevBenchは、入力の長さがコンテキスト上限を超えたことで発生した21件の失敗も、評価対象から除外せずに集計している。
さらに、以前から掲載されている他のモデルについては、当時の測定日や問題の抽出結果をそのまま維持している。今回の問題セットを使って全モデルを再測定したわけではないため、ランキングだけで各モデルの性能を一律に比較することは難しい。
もっとも、85ミリ秒と459ミリ秒という差だけで、Microsoftの発表が誤っている、あるいはモデルの性能が低下したと判断することもできない。測定日、通信経路、問題の内容などが異なるためだ。
85ミリ秒はMicrosoftが同一リージョンで測定した公式値、459ミリ秒は第三者がAPIを通じて測定した値として区別し、実際に導入する際は、自社の入力データと接続環境で応答時間を確認する必要がある。
100万回の判断が42ドル、繰り返し処理に適した料金体系
Decision-1の利用料金は、入力100万トークン当たり0.042米ドルで、出力には課金されない。OpenRouterに掲載されている料金も同額だ。
例えば、1回のリクエストで1,000トークンを入力すると仮定する。100万回のリクエストでは合計10億トークンとなり、入力料金は次のように計算できる。
0.042ドル×1,000＝42ドル
これは入力の長さとリクエスト回数を仮定した単純計算であり、周辺システムの運用費用や人による確認作業などは含まれていない。
Microsoftが紹介したXbox Researchの社内試験では、アンケートやゲームレビューなど、1万件を超える自由記述の回答を研究者が設定したテーマに分類した。
同社によると、Decision-1はGPT-6 Solに匹敵する品質を維持しながら、14倍以上の速度と200分の1のコストを実現したという。第三者によって再現された結果ではないものの、あらかじめ決められた分類を大量に繰り返す処理では、生成AIに毎回文章を作成させる工程を省くことで、速度と費用の両面で改善が期待できる。
ただし、実際にどれだけ効果があるかは、業務全体の中で判断処理が占める時間やコストによって変わる。
例えば、問い合わせの振り分け後に長時間の検索や回答生成を行うシステムでは、振り分け処理だけを高速化しても、残りの工程にかかる時間は変わらない。一方、同じような判断を何度も繰り返すシステムなら、1回当たりのわずかな時間短縮でも、全体では大きな効果につながる可能性がある。
また、Qwenを基盤としているからといって、Decision-1自体のモデルの重みが公開され、ローカル環境で実行できるわけではない。今回Microsoftが提供するのは、FoundryやOpenRouterを経由して利用するAPIだ。
これに対し、Strands Decider 2Bは、モデルの重みに加えて学習データやスクリプトも公開しており、ローカルのCPUやGPUで動かすことを想定している。
同じ判断専用モデルでも、クラウド上で提供されるAPIを利用するのか、自社環境でモデルを実行して調整するのかという違いがある。
Foundryでは、対応地域でDataZoneStandardを選択すると、指定したデータゾーン内で推論処理が行われる。一方、GlobalStandardでは、対応するAzureリージョンの計算資源を利用する。
Microsoftは、近くのデータゾーンを選んだからといって、必ずしも低遅延になるわけではないと説明している。モデルを開発した企業の所在地だけでなく、入力したデータが実際にどこで処理されるのかも、導入前に確認すべきポイントだ。
確率を返せても、どこまで自動化するかは利用側の判断
モデルが「90%」という確率を返した判断を多数集めたとき、実際に約90%が正しければ、予測確率と実際の正答率がよく一致しているといえる。この一致度を高めるのが、確率の校正だ。
たとえ正答率が高くても、誤った判断に対して高い確率を示すモデルでは、その数値を基準に自動処理と人による確認を振り分けることが難しい。
Microsoftは、入力の変化に対して判断がどれほど安定しているかも測定した。指示文や選択肢などを8種類の方法で変更したところ、判断結果が変わった割合は平均1.3%だったと報告している。
ただし、これは実際の利用環境で、どのような言い換えにも安定して対応できることを保証するものではない。開発者向け文書でも、質問の表現や選択肢の順序によってスコアが変化する可能性を指摘し、実際の用途を代表するデータを使って検証するよう求めている。
Decision-1は文章を生成しないものの、誤った選択肢を選ぶ可能性はある。
例えば、本来は返金について確認する必要がある問い合わせを、技術サポート担当へ振り分けてしまえば、出力されたJSONが形式上正しくても、業務上の判断は間違っている。また、そもそも選択肢の中に正解が含まれていなければ、どれほど明確な数値が返ってきても、正しい判断ができたとはいえない。
そのため、「分からない」「要確認」といった判断を保留するための選択肢を用意することが重要になる。
どの程度の確率なら自動処理に進めるかという閾値も、アプリケーション側で設定する必要がある。
誤った判断による損失が大きい業務と、多少の誤分類なら後から修正できる業務では、適切な閾値は異なる。実際に扱う日本語の問い合わせや、分類が難しい事例に正解ラベルを付け、どのような誤判断が発生するかを調べたうえで、人間や別のモデルに確認を任せる条件を決める必要がある。
採点用のscoreにも注意が必要だ。
例えば4段階の評価では、各段階に0〜3の番号を割り当て、モデルが返すスコアは、それぞれの段階の確率を使って計算した加重平均となる。
段階の中間に当たる数値が返ってきたとしても、それがあらゆる用途で通用する客観的な品質スコアを意味するわけではない。Microsoftも、絶対的な評価点として扱うのではなく、順位付けや閾値による判定に使うことを推奨している。
さらに、Decision-1は判断理由を文章で説明する機能を持たない。Microsoftは、医療や雇用など個人に重大な影響を与える判断について、このモデルを唯一の判断手段として使用しないよう求めている。
OpenRouterも、APIの形式を維持しながらモデルの重みを継続的に更新すると説明している。そのため、導入時に設定した閾値が、モデルの更新後も同じように機能するかを定期的に検証する必要がある。
Microsoftは今後、基盤となるモデルを自社のMAIやOpenAIのモデルへ切り替える計画も明らかにしている。
基盤モデルが変わっても、自社のデータに対して安定した判断を返し、確率に応じて自動処理と人による確認を適切に切り替えられることが重要だ。こうした仕組みを確立できれば、開発者は文章生成に適したモデルと、大量の判断を高速に繰り返すモデルを、業務の目的に応じて使い分けられるようになる。
