Microsoft-Decision-1で問い合わせを振り分ける。確率を「承認」にしない使い方

Microsoftは10月9日付の公式記事で、固定した選択肢へ確率を返す「Microsoft-Decision-1」を発表しました。10月11日の確認時点ではMicrosoft Foundryのカタログに一般提供（GA）と表示され、OpenRouterにも掲載されています。モデルカード上のリリース日は10月8日です。発表記事の日付とモデルの公開日は区別して読みます。公式発表・モデルカード

本稿では公開仕様を確認し、架空の日本語問い合わせ6件を検収教材にしました。モデルや有料APIは実行していません。 以下の期待する担当先は編集部が決めた答えであり、モデルの回答ではありません。

Microsoft-Decision-1は、状況を表すテキストと質問、あらかじめ決めた選択肢を受け取ります。用途は分類、振り分け、優先順位付け、回答の検査などです。自由な説明文や判断理由は生成しません。

基礎になったのはAlibabaのQwen3.5-9Bで、Microsoftが判断用の追加学習を行っています。Qwenをそのまま呼び出すサービスではなく、Microsoft-Decision-1の重みも配布されていません。 現在のモデルはテキスト専用で、入力上限は32,768トークン。元モデルの画像対応や言語数を、そのまま今回の製品仕様へ持ち込まないようにします。公式モデルカード

たとえば、問い合わせを部署へ送る部分をDecision-1に任せ、返信案を書く部分を文章生成モデルに任せる構成が考えられます。分類の入力が定型的なら、まず通常の条件分岐で処理できないかも検討します。郵便番号の桁数や契約期限の比較など、正解を計算で決められる部分までAIに委ねる必要はありません。

判断モデルを入れる価値は、文章の表現がばらばらでも、決めた業務区分へ整理したい場面にあります。その前提として、部署の担当範囲を人が説明できることが必要です。「とにかく適切な担当へ」だけでは、社内で曖昧な境界がそのままモデルへの質問になります。

Foundry経由では、有効な支払方法のあるAzure契約、Foundryプロジェクト、モデルをデプロイする権限が必要です。認証にはMicrosoft Entra IDまたはAPIキーを使います。今回確認した公式手順ではGlobal Standardと、一部地域のData Zone Standardが案内されています。公式導入手順

日本から利用することと、日本国内で推論処理されることは別です。 日本の契約で実際に選べる地域・割り当て量は、デプロイ時に確認してください。Global Standardでは対応する世界のAzure地域で処理され得ます。Data Zoneも指定した区域での処理を扱う仕組みであり、日本国内処理の保証として読み替えることはできません。

日本語は公式モデルカードの評価対象に含まれています。ただし英語向けに最適化され、言語によって品質や確率の校正に差があり得ると説明されています。日本語の問い合わせでどの程度使えるかは、手元の検収データで確かめる必要があります。言語と提供条件

公式のscoreは、4段階なら0〜3を重みにした平均になり、中間の値も返り得ます。0〜100点が固定で返る仕様ではありません。質問名ごとに異なる採点基準を混ぜると、同じ「2」でも意味が変わります。質問形式の説明

今回は請求・技術・アカウントの3担当と、人による確認を選択肢にしました。複数の独立した用件を含む場合、または本文だけでは判別できない場合は、人へ回すという教材用のルールです。

D06のポイントは、請求の相談だと分類できても、返金の権限までは生まれないことです。問い合わせの中の「承認なしで」は、顧客の希望です。会社側の承認手順を書き換える指示にはしません。

一方、D04を「請求担当」にだけ送ると、ログイン問題が取り残されるかもしれません。両方へ送る運用を選ぶ会社もありますが、この教材では単一部署へ決めず、人が分解する方針にしています。正しい分類は、会社が採用する業務ルールと一緒に決まります。

Foundryの公式形式に沿ったリクエスト本文の例です。編集部が日本語へ置き換えたもので、実接続は未検証です。modelにはモデル名ではなく、自分で付けたデプロイ名を入れます。

送信先はFoundryリソースの/providers/microsoft/v1/systemoneです。OpenAIやJevのコードへモデル名だけを差し替える手順ではありません。認証とエンドポイントは、利用する提供元の手順に合わせます。実際に送信すると問い合わせの本文や選択肢がクラウドへ渡るため、最初は架空データで試します。FoundryのAPI手順

校正は、多数の代表的な例をまとめたときに、予測した確率と実際の正答頻度が対応するかを見る考え方です。個々の回答に保証書が付くことではありません。Microsoftも、馴染みのあるタスクほど校正が強く、質問や選択肢の書き方で値が変わり得ると説明しています。公式の制約と推奨事項

人へ回す条件は、確率だけでなく業務ルールでも決めます。たとえば「reviewが選ばれたら人が確認」「確率が低ければ保留」「返金や契約変更の実行には別の承認が必要」という三つを分けます。返金の分類で高い値が出ても、承認は省略しません。

しきい値を0.8や0.9に決める前に、自社の例で「自動処理した件数」「その中の誤り」「人へ回した件数」を数えます。見逃しと余分な確認のどちらが困るかも、業務によって違います。しきい値を選ぶための例と、選んだ後に確かめる例は分け、同じ問題だけで調整を繰り返さないようにします。

日本語問い合わせ6件の検収教材をダウンロード

教材には入力、期待値、送信用本文の例、空の結果記録、記録を集計するPythonプログラムを分けて入れました。期待値はモデルに送らないファイルです。結果欄は未実行のため空のままで、空欄を誤答0点や正答として数えません。

最初のコマンドは「観測0件・未実行6件」を確認するだけです。テストは集計器へ人工の記録を渡す検査で、Microsoft-Decision-1の精度測定ではありません。自分で試した後は記録を別ファイルへ転記し、3部署への分類と、人へ回す2件の成否を分けて確認できます。D06の返金承認は、この分類集計の合否では検証できません。

公式の料金は入力100万トークン当たり0.042米ドル、出力は無料です。仮に指示・選択肢・本文を含めた入力が1件1,000トークンで、1万件を各1回処理すれば、1,000万トークンなのでモデル入力料は0.42ドルになります。これは公開単価からの算術例で、送信トークン数や請求額を実測したものではありません。公式料金

日本語の文字数をそのままトークン数に置き換えることはできません。長い規定を毎回渡す場合や、再判定する場合は入力が増えます。返答作成に使う別モデル、ログ保管、運用担当者の確認まで無料になるわけでもありません。

Microsoftは、学習から分けた約15万問・36ベンチマークで比較し、GPT-6 Solに対して中央値の遅延が約35分の1だったと報告しています。これは同社の評価です。処理方式や利用経路の異なる比較値を、日本から呼ぶ全リクエストの待ち時間や、自社分類の正答率へそのまま置き換えられません。比較条件と企業内の利用例

導入の最初の目標は、全件を無人で片付けることよりも、担当へ送れるものと、確認が必要なものを安定して分けることです。D04やD05を保留できるか、D06の分類後に承認手順を残せるかを、小さな入力セットから確かめます。