Microsoft Decision-1、QwenをAIエージェント向け高速制御レイヤーへ
Microsoftは10月9日、AlibabaのQwen3.5-9Bを迅速かつ構造化された意思決定に特化したモデルへと変えるMicrosoft Decision-1を発表した。回答文を生成するのではなく、あらかじめ定義された選択肢から選び、ソフトウェアが即座に実行できる確率を割り当てる。
この限定された使命こそが、本質的な緊張を生んでいる。Microsoftが提示しているのは、また一つのチャットボットや推論アシスタントではない。リクエストを振り分け、AIの応答を評価し、インシデントの優先順位を付け、データを検証し、エージェントを継続させるかどうかを判断する制御レイヤーである。
Qwenを基盤にした点は、製品カテゴリーと同じくらい重要だ。Microsoftの初版はAlibabaが開発したオープンモデルに依存している。一方でMicrosoftは独自のMAIモデルにも投資し、OpenAIとの大規模な提携も維持している。Microsoftによれば、後続バージョンではMAIやOpenAIのモデルを含む別の基盤モデルを使用する予定だという。
このモデルはMicrosoft FoundryおよびOpenRouterでパブリックプレビューとして提供されている。Microsoftは広範な社内評価で首位の結果を報告しているが、重要な判断を委ねる前に、開発者は依然としてワークロード固有のテストを行う必要がある。
Microsoft Decision-1は書くためではなく、選ぶために作られた
Microsoft Decision-1は、高速な業務上の選択を、自由形式のテキストを生成・推論する高コストな処理から切り分ける。
従来の大規模言語モデルはプロンプトを受け取り、トークン列を生成する。その柔軟性により、メールの下書き、概念の説明、コードの記述、曖昧な資料の分析が可能になる。一方で、アプリケーションに必要なのが限定された回答だけである場合、レイテンシーとばらつきも生じる。
Microsoft Decision-1は、この限定的なケースを対象とする。開発者は一定のコンテキストと、承認、却下、エスカレーションといった固定の選択肢を提供する。モデルはそれらの選択肢を採点し、信頼度情報を含む構造化された結果を返す。
Microsoftの発表詳細では、ルーティング、分類、優先順位付け、検証、ワークフロー制御を主なワークロードとして挙げている。対応する質問形式には、Yes／No判断、評価、多肢選択、ルーブリックに基づく評価が含まれる。
この構造はアプリケーションコードを簡素化できる。サポートシステムは段落を解析せずとも、メッセージを請求、技術、アカウント関連に分類できる。エージェントは、継続、再試行、別ツールの呼び出し、人間によるレビューの要求のいずれを行うかを選択できる。
同じアプローチはモデルルーティングにも当てはまる。アプリケーションは基本的な分類タスクを小規模モデルに送り、複雑なリクエストには推論モデルを割り当てられる。意思決定レイヤーは、ユーザー、モデル、ツール、業務プロセスの間を取り持つ交通整理役となる。
Microsoftはこれをシングルパスの意思決定スコアリングと呼ぶ。モデルは最初に長い推論トレースを生成することなく、選択を出力する。この設計により、連続するトークン数が減り、応答時間の予測可能性が高まる。
確率はインターフェースの中心的な要素だ。モデルは一つの選択肢を最も可能性が高いものとして示しつつ、その確信度が弱いことも示せる。アプリケーション開発者はその上で、自動実行、レビュー、エスカレーションのためのしきい値を設定できる。
この区別は重要である。分類ラベルだけでは不確実性が隠れてしまう。ある選択肢をかろうじて上回る結果は、圧倒的な確信を伴う結果と同じ自動化を引き起こすべきではない。Microsoftは、確率出力をワークフローのロジックの一部にしたい考えだ。
このモデルは生成AIの万能な代替ではない。意思決定を迅速に返すからといって、曖昧な依頼を思慮深いレポートへ変換できるわけではない。開発者は選択肢を定義し、関連するコンテキストを提供し、スコアが返された後に何が起こるかを決めなければならない。
また、このモデルは通常のソフトウェアルールを不要にするものでもない。信頼できるデータから正しい結果が直接導かれる場合は、決定論的な条件の方が適している。言語、ノイズの多い証拠、変化するコンテキストによって固定ルールの維持が難しくなる場合に、意思決定モデルが有用になる。
これにより、Microsoft Decision-1は従来の分類器と汎用言語モデルの間に位置付けられる。現代的な基盤モデルの言語理解を備えつつ、出力は業務利用に向けて制約されている。
この変化は小さく聞こえるかもしれないが、AIシステム内で開発者が作業を分担する方法を変える。生成が一つのコンポーネントとなり、構造化された判断が別のコンポーネントとなる。
MicrosoftがQwen3.5上に意思決定モデルを構築した理由
MicrosoftによるQwen3.5-9Bの選択は、基盤モデルが専門特化したAI製品の中で置き換え可能な部品になりつつあることを示している。
Microsoftによれば、Microsoft Decision-1の初回リリースを作るためにQwen3.5-9Bをポストトレーニングしたという。ポストトレーニングとは、広範な初期学習の完了後に、既存の基盤モデルを特定の振る舞いへ適応させることを指す。
その結果生まれた製品は、単に名称を変えたQwenエンドポイントではない。Microsoftは、元の汎用モデルのあらゆる能力を維持するのではなく、あらかじめ定義された選択肢の選定と採点に向けてモデルを最適化している。
Qwen3.5-9Bは、言語能力と推論能力がすでに組み込まれた、比較的コンパクトな出発点を提供する。Microsoftは追加学習を、確率のキャリブレーション、応答の一貫性、安全性の振る舞い、構造化された意思決定タスクに集中させられる。
Alibabaは、より広範なQwen3.5シリーズを、推論、コーディング、エージェントタスク、効率的な推論向けに設計されたネイティブなマルチモーダルモデル群として発表した。9Bモデルは、より大きなワークフロー内で頻繁な判断を行うのに十分小さな基盤をMicrosoftに提供する。
この選択は、オープンモデル開発が競争の境界をどう変えてきたかも反映している。一つのクラウド・コマース企業が作ったモデルが、別の企業によって配布される製品の基盤になり得る。価値は事前学習から、ポストトレーニング、評価、ホスティング、統合、アプリケーション設計へ移り得る。
MicrosoftはQwenを恒久的な依存先とは説明していない。同社は意思決定モデルをMAIおよびOpenAIの基盤に再構築する計画だとしている。この表現は、アーキテクチャが意図的に可搬的に設計されていることをうかがわせる。
可搬性のある意思決定レイヤーはMicrosoftに柔軟性をもたらす。異なる基盤モデルをテストしながらも、開発者向けのタスク、すなわちコンテキストを送信し、選択肢を定義し、スコアを受け取り、ポリシーを適用するという流れは安定して保てる。
このアプローチは、Microsoftのモデルカタログにおける切り替えコストも下げられる可能性がある。サービスが一貫したスキーマ、キャリブレーション、レイテンシー、評価ツールを維持するなら、開発者はどの基盤モデルがスコアを生成したかをあまり気にしなくなるかもしれない。
ただし、基盤モデルを変えることは中立的な実装の詳細ではない。各基盤は指示を異なる形で解釈し、異なる確率分布を割り当て、未知の入力に対して異なる反応を示し得る。将来の再構築には慎重な回帰テストが必要になる。
この戦略は基盤モデル提供者に圧力をかける。専門的なポストトレーニングにより、交換可能なオープンモデルを、独自のAPI、ベンチマーク、流通チャネルを持つブランド製品へと変えられるからだ。
同時にMicrosoftにも圧力がかかる。同社は、追加した学習とデプロイメント層が、Qwenをプロンプトで包んだだけのもの以上の価値を持つことを示さなければならない。キャリブレーション、書式変更への耐性、未知のワークロードでの性能が、その差別化を維持できるかを決める。
したがってQwenとのつながりは脚注ではない。企業がモデル、タスク固有の学習、評価システム、クラウド配信を組み合わせて製品を構築する、よりモジュール化された市場の証拠である。
Microsoftの初回リリースはこのモジュール性に依存している。その長期計画は、基盤が変わっても意思決定の振る舞いを維持できるかを試すものだ。
仕組みは速度だが、対象は連続的な作業である
主な利点は一つの回答が速く届くことではなく、繰り返される判断がエージェントのワークフロー全体に加える遅延を抑えられることにある。
AIエージェントが行う選択は一つだけではない。ツールを選び、その引数を検証し、結果を評価し、次の手順が必要かを判断し、アクションに承認が必要かを確認する。
こうした手順の間でレイテンシーは蓄積する。Microsoftは簡単な例を示す。20回の連続した判断のそれぞれに100ミリ秒が加われば、ワークフロー全体には2秒が追加される。
Microsoftは、Microsoft Decision-1が36件のベンチマーク比較で最高精度を達成したと報告している。この評価には、Microsoftが学習から遮断されていたとする公開・非公開ベンチマークの約15万問が含まれていた。
同社はまた、このモデルが比較対象の次点であるH2O-Lightning-4B v1.1より2.5倍高速だったとしている。GPT-6 Solと比べた中央値レイテンシーは約35倍高速だったとも報告している。
これらはMicrosoftによる測定であり、あらゆるデプロイ環境にわたる独立した評価結果ではない。ネットワークの場所、プロバイダーのインフラ、バッチサイズ、入力長、ワークロード設計は、いずれも観測されるレイテンシーを変え得る。
それでも、その仕組みには妥当性がある。限定されたスコアを出力するモデルは、生成応答に必要な長い出力列を避けられる。この差は、ソフトウェアが数十回の小さな判断を必要とする場合に大きくなる。
Microsoftはいくつかの社内テストを説明している。Xbox Researchは、このモデルを使い、1万件を超えるフィードバックを研究者が定義したテーマに分類したと報じられている。元となる資料にはアンケート、Steamレビュー、ソーシャル投稿が含まれていた。
Microsoftによれば、このテストはGPT-6 Solと競合する品質を実現しながら、14倍以上高速に動作したという。同社はまた、CopilotチームがGPT-5.6 Lunaに匹敵する品質を、はるかに低いレイテンシーで確認したと報告している。
インシデント対応のテストでは、このモデルがログ、チケット、通話、メッセージ、その他の運用資料から関連知識を選ぶのに役立ったとMicrosoftは述べている。人間が調査する前に、システムが情報を順位付けまたは振り分ける必要があることが多いため、これは自然な意思決定ワークロードである。
Microsoft Discoveryは、このモデルを適応型の科学ワークフロー内でテストした。エージェントは実験を評価し、結果をルーブリックに照らして採点し、計画を修正した。Microsoftは、LLMベースの代替手段よりも一貫した採点と高速な再計画を報告している。
これらの例には共通するパターンがある。モデルは最終成果物を生成しているのではない。システムの別の部分を選択、分類、確認、または導いている。
この分担により、チームはすべての段階を弱めずに推論予算を管理できる。より大きな推論モデルが難しい部分を担い、意思決定モデルは頻繁かつ制約された選択を処理できる。
また、可観測性の改善にもつながる。名前付きの選択肢と確率スコアを備えた構造化された判断は、非構造化の段落よりもログに記録しやすい。チームはスコアを最終的な結果と比較し、時間の経過に伴う性能変化を検出できる。
知識集約型のワークフローでは、この制御レイヤーは検索すべきリポジトリ、優先すべき結果、検索で得た証拠が不十分なタイミングを判断できる。検索やソース検証を置き換えるのではなく、適切に維持されたAIナレッジベースを補完する。
アプリケーションが不適切に構成された質問を投げかける場合、速度の利点は弱まる。開発者が重複する選択肢や不完全なコンテキストを与えれば、速い回答は欠陥のあるワークフローを加速するだけである。
Microsoft Decision-1は、そのため一部のエンジニアリング作業を上流へ移す。チームは意味のある選択肢を定義し、エスカレーションの閾値を設け、モデルの確信が妥当だったかを明らかにする結果を収集しなければならない。
ベンチマークで自動化ポリシーは決められない
Microsoftがベンチマークで先行していることはモデルを試す理由にはなるが、制御なしに高影響の意思決定を委ねてよいという許可にはならない。
Microsoftによれば、その評価はルーティング、ランキング、長文コンテキスト入力、多言語タスク、推論、安全性、分布外の事例を対象としている。この幅広さは、単一の分類スコアよりも有用だ。
同社は、リクエストに8種類の変更を加えることで堅牢性も検証した。Microsoftによると、こうした変更によって判断が変わった割合は平均1.3%だった。
選択肢の説明を言い換えた場合や、選択肢を逆順またはランダム順にした場合には、判断の反転は記録されなかったという。この結果は、表現上の無害な変化によって回答が変わるという、言語モデルによる分類でよく見られる弱点に対応している。
確率キャリブレーションも重要な試験だ。キャリブレーションされたモデルでは、代表的なケース全体での確信度が、実際に観測された精度と一致するべきである。およそ90%の確信度が与えられた予測は、10回中9回程度正しくあるべきだ。
この特性により、アプリケーションは確信度の閾値を使える。高確信度の判断はそのまま進め、不確実なケースはより大きなモデルへ回し、機微なケースでは常に人間の承認を求めることができる。
ただし、キャリブレーションがベンチマークから企業固有のデータへ自動的に移行するわけではない。一般的な分類タスクで試験されたモデルは、専門用語、特殊な顧客行動、変化する不正パターンに遭遇すると、過剰な確信を示す可能性がある。
公開されているJevBench testsは、この問題の別の側面を示している。質問が言い換えられたり、否定形になったり、再編成・翻訳されたり、選択肢の組み合わせが変更されたりしても、確率的な判断が一貫しているかを検証するものだ。
これらのテストが測るのは一貫性であり、すべての判断が正しいかどうかではない。モデルは一貫して誤ることもある。また、ラベル付きの事例では高スコアを出しながら、アプリケーションの選択肢構造が少し変わっただけで不安定な確率を出力することもある。
Microsoftの主要な比較は、公開・非公開のベンチマークを組み合わせている。非公開テストは直接的な学習データ汚染を抑えられる一方、外部の人々は評価のすべてを完全に検証・再現することはできない。
開発者は、ベンチマークの主張を受け入れる前にいくつかの質問をすべきだ。競合モデルは最適に構成されていたか。等価なプロンプトを受け取っていたか。レイテンシー測定は比較可能なインフラで収集されたか。結果はどの程度繰り返し検証されたか。
ワークロード設計も同様に重要だ。コンテンツルーティングのベンチマークでは、医療上の優先順位付け、金融承認、アクセス制御、人事判断における信頼性を確立できない。
Microsoftは、有害コンテンツ、ジェイルブレイクの試み、プロンプトインジェクションを対象とする11のベンチマークで、5,250件のリクエストを使って安全性を試験したとしている。同社によると、モデルは有害な行為を拒否しつつ、有用性を保った。
これは有用な証拠だが、安全な導入を定義するものではない。エージェントを制御するモデルは、1件の分類ミスを後続の行動全体に増幅させる可能性がある。出力がデータを誤ったツールに振り分けたり、安全でない行動を承認したり、正当なタスクを妨げたりするかもしれない。
確信度スコアは、開発者を誤った精密さへと誘うこともある。確率が有用なのは、チームが自らのデータ上でその挙動を理解している場合に限られる。0.92という結果に普遍的な保証はない。
本番テストには、過去の事例、難しいエッジケース、敵対的な指示、選択肢の順序変更、未知の入力を含めるべきだ。チームは、より大きなLLMだけでなく、単純なルールや従来型の分類器ともモデルを比較すべきである。
また、各エラー種別のコストも測定すべきだ。誤ったエスカレーションは担当者の時間を浪費する一方、誤った承認はセキュリティまたはコンプライアンスのインシデントを生みかねない。総合精度では、この非対称性が隠れてしまう。
Microsoft Decision-1は範囲が限定された選択を行うが、その結果は限定されない可能性がある。自動化が許容される場面を決めるべきなのは、モデルではなく導入ポリシーだ。
真の競争は特化モデルと汎用LLMの間にある
Microsoftは、1つの高価なモデルがすべてのステップを担わなくなれば、AIシステムはよりうまく機能するという賭けに出ている。
初期のAIアプリケーションの多くは、ほぼすべてのタスクを同じ汎用モデルに送っていた。モデルはリクエストを分類し、情報を検索し、ツールを選択し、回答を下書きし、出力を確認し、継続すべきかを判断する。
このアーキテクチャはプロトタイピング段階では便利だ。しかし、アプリケーションが拡大し、何千件もの単純な判断を繰り返すようになると、非効率になる。
Microsoft Decision-1は、モジュール型の代替案を打ち出している。生成モデルがコンテンツ作成を担い、推論モデルが複雑な計画を処理し、検索システムが証拠を提供し、意思決定モデルが範囲を限定した遷移を制御する。
したがって、Microsoftの主要な競争相手はAlibabaやQwenではない。あらゆる処理に汎用LLMを使うという慣行そのものだ。
特化型のルートには明確な利点がある。レイテンシーを減らし、予測可能なデータ型を返し、確信度スコアを提示し、アプリケーションの挙動を監視しやすくできる。
一方で、調整コストも生じる。開発者は各タスクをどのモデルに任せるかを選び、複数の障害モードを管理し、情報がコンポーネント間を移動する際にコンテキストを保持しなければならない。
汎用モデルは、固定された選択肢セットが見逃す曖昧さを解決できる場合がある。誤った前提を問い直し、追加の詳細を求め、開発者が想定していなかった選択肢を提案できる。
範囲が限定された意思決定モデルは、存在しない選択肢を選べない。そのため、アプリケーションには「不明」「証拠不十分」「人間によるレビュー」といった退避経路が必要になる。
より単純な技術との競争もある。チームが安定したラベルと十分な学習データを持つ場合、従来型の機械学習分類器のほうが安価で監査しやすいことがある。判断が明示的なポリシーに従う場合は、通常のルールのほうが依然として望ましい。
この新モデルが価値を発揮するのは、言語表現の揺れによってルールが脆くなる一方で、出力空間は制御可能な場合だ。例としては、サポートリクエストの振り分け、生成された応答の採点、インシデント報告の優先順位付け、エージェントの行動が評価基準を満たすかの確認が挙げられる。
Microsoftの流通網は、このモデルに別の利点を与える。Foundry previewでは、企業開発者がすでに利用している他のモデルやサービスと並んで提供される。
OpenRouterは第2のアクセス経路を提供し、プロバイダー間の比較を容易にする。開発者はアプリケーション全体を再構築することなく、同じ意思決定ワークロードを複数のモデルで試せる。
この可用性により、モデルルーティング自体が独立した製品カテゴリーになる。意思決定モデルは、タスクの種類、レイテンシー要件、リスク、期待品質に基づいて生成モデルを選択できる。
ここには、珍しい再帰的な構造が生まれる。AIモデルが出力を生成し、別のAIモデルが、どのモデルに作業させるか、結果が許容可能か、次に何をするかを決める。
このアーキテクチャは機能し得るが、明確な権限境界が必要だ。低リスクの分類器は自動で行動できる。法務、金融、セキュリティ、安全性に関わる結果を評価するモデルには、より厳しい閾値と人間による監督が求められる。
Microsoftの意思決定モデルは、特化型か汎用型かという議論に決着をつけるものではない。開発者に、自らのシステム内でそのトレードオフを測る具体的な方法を与えるものだ。
特化モデルが品質を保ちながら累積遅延を減らせるなら、モジュール型エージェントアーキテクチャの信頼性は高まる。統合とエラー処理によってその利点が失われるなら、チームはより少数で高性能なモデルへ戻るだろう。
Microsoft Decision-1のローンチ後に注目すべきこと
Microsoftが持続可能なモデルカテゴリーを生み出したのか、それとも説得力のあるベンチマーク結果にとどまるのかを示すシグナルは3つある。
第1のシグナルは、顧客のワークロードにおける性能だ。チームは実際の本番環境に近いデータを用いて、判断精度、キャリブレーション、レイテンシー、エスカレーション率を測定すべきである。
導入だけでは信頼性を確立できない。高いリクエスト量は、実験、プロモーション上の配置、低リスクな分類タスクを反映している可能性がある。継続的な導入から得られる証拠のほうが重要になる。
有用なケーススタディは、既存のルール、分類器、汎用LLMと比較してモデルがどう機能するかを報告すべきだ。また、平均精度だけでなく、エラーのコストも開示すべきである。
強い結果とは、Microsoft Decision-1がデータの変化に伴ってもキャリブレーションを維持し、エンドツーエンドのワークフロー時間を短縮することを示すものだ。頻繁な上書きや、気づかれない誤ルーティングはMicrosoftの主張を弱める。
第2のシグナルは、Qwen3.5-9Bを超えるというMicrosoftの約束だ。同社は、MAIとOpenAIの基盤モデルに基づいてモデルを再構築する計画だとしている。
この移行は、製品を特徴づける挙動がMicrosoftのポストトレーニング手法によるものなのか、それともQwenのベースモデルによるものなのかを試すことになる。開発者は、レイテンシー、キャリブレーション、対応入力、安全性の挙動、ベンチマーク結果の変化を注視すべきだ。
Microsoftはまた、バージョン変更が既存のアプリケーションに与える影響を説明しなければならない。勝者となる選択肢が同じままでも、小さな確率変動によってケースが自動化の閾値をまたぐことがある。
安定したバージョニングと回帰テストツールは不可欠になる。チームには、代替モデルが本番の判断を変える前にテストする手段が必要だ。
第3のシグナルは、独立した評価である。Microsoftの36ベンチマーク比較は幅広いが、外部研究者や顧客が最も重要な主張を再現しなければならない。
独立テストには、局所的なエラーが蓄積する長時間稼働のエージェントタスクを含めるべきだ。モデルは個々の選択を迅速に行えても、小さなミスが多くのステップで複合すれば、最終的なタスク完了率を下げる可能性がある。
評価者は、未知のドメイン、敵対的な選択肢説明、欠落した選択肢、矛盾するコンテキストも試験すべきだ。こうした条件は、整然とした多肢選択問題より本番環境に近い。
開発者はMicrosoftのdeployment guideから始められるが、実装はシャドーテストから始めるべきだ。チームがモデルの判断を人間またはシステムの結果と比較する間、モデルは結果を制御せずに実際のケースを採点できる。
Qwenを基盤にしていることは、このローンチを戦略的に注目すべきものにしているが、より大きな論点はアーキテクチャにある。Microsoftは、あらゆるAIタスクで生成をデフォルトの解決策として扱うのをやめるよう開発者に求めている。
この主張は真剣に検証する価値がある。高速で構造化された採点は、エージェントの応答性を高め、観測しやすくする可能性がある。一方で、その確信が実際以上に信頼できるように見える自動化された制御点を生み出す可能性もある。
次のステップは実務的だ。既存のワークフローで頻繁に発生する、範囲が限定された意思決定を1つ特定し、現在の手法と比較してテストする。最終結果、確信度のキャリブレーション、レイテンシー、上書き、エラーの重大性を測定する。
Microsoftの意思決定モデルがこうした条件下で勝つなら、ベンチマークチャートを超えた役割を持つ。そうでなければ、ルール、分類器、または汎用LLMが依然としてより良い選択肢となる。
