2026.10.14 AI

Microsoft-Decision-1とは？判断専用モデルの料金・Foundry実装と採用条件【2026年10月】

Microsoft-Decision-1は、Microsoftが2026年10月9日にMicrosoft Foundryで公開した、文章を書かずに「判断」だけを返すモデルです。テキストやJSONと型の決まった質問を渡すと、選んだ選択肢と各選択肢の確率が数値で返ってきます。この記事では、noul・choice・scoreの3種類の質問、Foundryへのデプロイとsystemoneエンドポイントの呼び出しコード、入力100万トークン0.042ドルの試算を示します。日本リージョンで動かない点、同じ形式のTypeSafe Jevとの違い、採用と見送りの条件も整理しました。仕様と価格は2026年10月14日時点の公式情報に基づきます。

まとめ：Microsoft-Decision-1は分類と振り分けを確率で返すAzureの判断モデル

Microsoft-Decision-1は、Qwen3.5-9Bを判断用に追加学習したモデルです。問い合わせの振り分け、エージェントの次の一手の選択、LLM出力の採点のように、答えの候補が先に決まっている処理を大量に回す用途に向きます。料金は入力100万トークンあたり0.042ドルで、出力には課金されません。

導入前に確かめる条件は2つです。1つ目は、デプロイできるのが米国9リージョンと欧州7リージョンだけで、東日本・西日本は対象外なこと。2つ目は、パブリックプレビューの段階でSLAの対象外になることです。

Azureの契約の中で、国外での処理が許される分類やルーティングの検証から始めるなら試す価値があります。人事や与信のように人に関わる判断を単独で任せる使い方は、公式も推奨していません。

Microsoft-Decision-1の正体と文章を生成しない判断モデルの仕組み

LLMと同じカタログに並んでいますが、入出力の形はまったく違います。まず中身を確認します。

Qwen3.5-9Bを判断用に追加学習した9B級モデルという成り立ち

Microsoftの発表記事によると、Microsoft-Decision-1はAlibabaのQwen3.5-9Bを、1回の推論で判断を出す用途に向けて追加学習したものです。ベースモデルはApache 2.0ライセンスで公開されています。Microsoftは今後、自社のMAIモデルやOpenAIのモデルを土台にした版も出す方針です。Qwen3.5系の大型モデルの性能やライセンスはQwen3.5-397B-A17Bの解説で整理しています。

提供状況は、Tech Communityの公式ブログに「パブリックプレビュー」と書かれています。OpenRouterのモデルページにも同日に掲載され、文脈長は32,768トークンです。

noul・choice・scoreの3種類の質問で返る値と使い分けの基準

入力は、判断材料の state と、名前を付けた質問の集まり questions の2つです。Microsoft Learnの使い方ガイドは、質問の型を次の3つに分けています。

型	問いの形	返る値	向く処理
`noul`	これは真か	0〜1の確率	返金の約束を含むか等の関門
`choice`	どれに当たるか	選んだ1つと各選択肢の確率	担当チームやモデルの振り分け
`score`	どの程度か	段階の位置と各段階の確率	障害の深刻度、回答の採点

迷いやすいのは score です。返る値は段階の番号を確率で重み付けした平均で、4段階なら0〜3の間の小数になります。ガイドは、絶対的な評価値としてではなく、並べ替えや閾値に使うよう勧めています。

36ベンチマークと判断反転率1.3%という社内公表値の正しい読み方

発表記事では、学習に含めていない約15万問・36種類のベンチマークで最も高い精度を出したとしています。速度は2番手のH2O-Lightning-4B v1.1の2.5倍、GPT-6 Solの35倍です。同じ入力を8通りに言い換えたとき判断が変わる割合は、平均1.3%と公表されました。

社内事例も載っています。Xboxのフィードバック1万件超の分類では、GPT-6 Solと同等の品質で14倍以上速く、費用は200分の1だったという内容です。

どれもMicrosoft自身の測定で、日本語の課題での数値はありません。LLMに採点させる手法の偏りと人手との一致率の測り方はLLM-as-a-Judgeの解説にまとめています。自社の正解ラベル付きデータで、正答率と確率の当たり具合を測ってから判断してください。

Foundryへのデプロイとsystemoneエンドポイントの呼び出し手順

呼び出しはFoundryリソース上の専用エンドポイント1本です。チャット補完のAPIとは別物なので、既存のOpenAI互換クライアントはそのままでは使えません。

日本から使う場合の米国・欧州リージョンとデプロイ種別の選び方

最初の関門はリージョンです。Foundry Modelsのリージョン表でMicrosoft-Decision-1に印が付くのは、eastus2やwestus3など米国の9リージョンと、swedencentralやwesteuropeなど欧州の7リージョンです。japaneast・japanwestを含むアジア太平洋の列はすべて空欄でした（2026年10月14日時点）。

デプロイ種別は2つから選びます。デプロイ種別の説明によると、GlobalStandard は任意のAzureリージョンで推論が処理されうる方式です。DataZoneStandard は米国または欧州のデータゾーン内に処理を留めます。日本の利用者が処理場所を説明できる状態にしたいなら、eastus2などにリソースを作り DataZoneStandard を選ぶほうが説明しやすくなります。Foundryのリソースと料金の全体像はMicrosoft Foundryの解説を参照してください。

az CLIでのデプロイとEntra IDトークン付きcurlでの最初の呼び出し

デプロイの作成には、リソースに対するCognitive Services Contributorロールが要ります。米国データゾーンにデプロイし、Microsoft Entra IDのトークンで呼ぶ例です。ACCOUNT_NAME などは自分の値に置き換えます。

az cognitiveservices account deployment create \
  --name ACCOUNT_NAME \
  --resource-group RESOURCE_GROUP \
  --deployment-name decision-1 \
  --model-name "Microsoft-Decision-1" \
  --model-format Microsoft \
  --model-version "1" \
  --sku-name DataZoneStandard \
  --sku-capacity 1

export AZURE_ENDPOINT="https://ACCOUNT_NAME.services.ai.azure.com"
export AZURE_ENTRA_TOKEN=$(az account get-access-token \
  --resource https://cognitiveservices.azure.com \
  --query accessToken --output tsv)

curl "$AZURE_ENDPOINT/providers/microsoft/v1/systemone" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AZURE_ENTRA_TOKEN" \
  -d '{
    "model": "decision-1",
    "state": "The API returns 500 on every call.",
    "questions": {
      "team": {
        "type": "choice",
        "instructions": "Which team should handle this ticket?",
        "criteria": {
          "billing": "Charges, invoices, and refunds",
          "engineering": "Bugs, errors, and outages",
          "support": "How-to and account questions"
        }
      }
    }
  }'

AZURE_ENDPOINT には、デプロイ詳細画面に表示されるリソースのエンドポイントを入れます。リクエストの model にはモデル名ではなくデプロイ名を書く点に注意してください。応答側の model には実体のモデル名が入るため、両者が一致しなくても異常ではありません。APIキーで呼ぶ場合は、Authorization ヘッダーを api-key ヘッダーに差し替えます。

1リクエストで振り分け・深刻度・再問い合わせを同時に判定するPython例

同じ state に対する質問は1回のリクエストにまとめられます。ガイドの例を、日本語の問い合わせと「判断できない」の選択肢を足した形に組み替えたコードです。pip install azure-identity で依存を入れ、Python 3.10以上で実行します。

import json
import os
import urllib.request

from azure.identity import DefaultAzureCredential

ENDPOINT = os.environ["AZURE_ENDPOINT"].rstrip("/")
DEPLOYMENT = os.environ["DEPLOYMENT_NAME"]
SCOPE = "https://cognitiveservices.azure.com/.default"
CREDENTIAL = DefaultAzureCredential()

TEAMS = {
    "billing": "請求・返金・支払い方法に関する問い合わせ",
    "engineering": "エラー・不具合・障害の報告",
    "support": "使い方・アカウント設定の質問",
    "cannot_tell": "情報が足りず担当を決められない",
}


def decide(ticket: dict) -> dict:
    body = {
        "model": DEPLOYMENT,
        "state": ticket,  # テキストでもJSONでも渡せる
        "questions": {
            "team": {
                "type": "choice",
                "instructions": "この問い合わせを担当するチームを、主な問題から1つ選ぶ。",
                "criteria": TEAMS,
            },
            "severity": {
                "type": "score",
                "instructions": "業務への影響はどの程度か。",
                "criteria": ["軽微", "小", "大", "致命的"],  # 低い順に並べる
            },
            "repeat_contact": {
                "type": "noul",
                "instructions": "顧客は同じ件で以前にも問い合わせているか。",
            },
        },
    }
    req = urllib.request.Request(
        f"{ENDPOINT}/providers/microsoft/v1/systemone",
        data=json.dumps(body, ensure_ascii=False).encode("utf-8"),
        headers={
            "Authorization": f"Bearer {CREDENTIAL.get_token(SCOPE).token}",
            "Content-Type": "application/json",
        },
        method="POST",
    )
    with urllib.request.urlopen(req, timeout=60) as res:
        return json.loads(res.read())["answers"]


if __name__ == "__main__":
    answers = decide({
        "message": "決済画面が今日もエラーになります。問い合わせは3回目です。",
        "customer_contact_count": 3,
    })
    print(json.dumps(answers, ensure_ascii=False, indent=2))

応答の answers は、リクエストで付けた質問名（ここでは team・severity・repeat_contact）をキーに返ります。choice 型の答えの choice に選ばれた選択肢名が入ることは、ガイドのサンプルコードで確認できます。ガイドの例はすべて英語です。日本語の指示文と英語の指示文で正答率が変わるかは、自社データで比べてから決めてください。

Decision-1の確率を閾値にして自動処理と人の確認を分ける運用設計

判断モデルを入れる意味は、答えと一緒に確率が返ることにあります。確率を使わずに最上位の選択肢だけを採用すると、普通の分類器と変わりません。

最上位の確率が閾値未満の判断を人へ回すエスカレーション処理の組み方

ガイドは、最上位の確率が低い判断を人か別のモデルへ回す合図として使うよう勧めています。前のコードの answers を受け取り、振り分け先を決める関数の例です。

THRESHOLD = 0.7  # 誤振り分けの費用と人手の費用から決め直す


def top_probability(answer: dict, options: dict) -> float:
    # 選択肢名をキーに持つ確率の辞書を探す
    for value in answer.values():
        if isinstance(value, dict) and set(value) == set(options):
            return max(value.values())
    raise ValueError("選択肢ごとの確率が応答に見つかりません")


def route(answers: dict) -> str:
    team = answers["team"]
    if team["choice"] == "cannot_tell":
        return "human_review"
    if top_probability(team, TEAMS) < THRESHOLD:
        return "human_review"
    return team["choice"]

確率の辞書を名前で引かずに探しているのは、2026年10月14日時点のLearnに応答のフィールド名が明記されていないためです。最初の応答を出力して名前を確かめたら、直接参照に書き換えて構いません。閾値は、誤って自動処理したときの損失と、人が確認する工数の比で決めます。返金や本番環境への操作のように誤りが高くつく判断ほど、閾値を上げます。

判断できないという選択肢と選択肢の並び替えで偏りを確かめる手順

ガイドの「既知の制限」には、質問や選択肢の言い回しと順序でスコアが変わること、質問の立て方が悪くてもスコアは返ってくることが挙がっています。対策として公式が示すのは次の4点です。

無理に選ばせたくない判断には cannot tell のような棄権の選択肢を入れる
選択肢の順序を入れ替えて、結果が変わらないかを試す
指示文と選択肢の説明は、中立で曖昧さのない言葉で書く
自社の業務を代表するラベル付きデータで、導入前に精度を測る

2番目は手間が小さく効果が大きい確認です。同じ100件を、選択肢の順序だけ変えた2通りで投げ、判断が割れた件数を数えます。割れた件の説明文を書き直すと、精度より先に安定性が上がります。プロンプトインジェクションや有害な入力を止める関門として使う場合は、見逃しも誤検知もありうると明記されているため、AIガードレールの設計のように複数の検査層を重ねてください。

400・422・429エラーの主な原因と再試行してよい状態コードの見分け方

ガイドのトラブルシューティング表のうち、実装時に当たりやすいものを抜き出しました。

状態コード	主な原因	対処
400	質問の型や形が不正	`type` と `criteria` の形を見直す
401	トークンやキーの期限切れ・誤り	トークンを取り直す
404	エンドポイントかパスの誤り	詳細画面のエンドポイントと照合する
422	デプロイ名か質問の定義が非対応	`model` にデプロイ名を入れる
429	デプロイのレート上限超過	指数バックオフで再試行、クォータ申請

再試行してよいのは429だけです。400と422は何度送っても同じ結果になるため、ログに残して設定を直します。choice の criteria は辞書、score の criteria は低い順の配列、という形の違いで400を出す例が多くなりがちです。

料金・文脈長とJev・Clef・GPT-6 Lunaとの違いの比較

判断専用モデルは2026年9月から10月にかけて4製品がそろいました。費用の計算と、乗り換えたときに変わる箇所を確認します。

入力100万トークン0.042ドル・出力無料で試算する月額費用

1件あたりの入力を500トークンと置くと、月100万件で5億トークン、費用は21ドルです。出力は課金されないため、質問を3つにまとめても増えるのは質問文の入力トークンだけです。

この単価の出典は発表記事とOpenRouterのページです。Foundry経由の請求単価は契約前にAzureの請求画面でも突き合わせてください。プレビュー期間はAzureプレビューの補足利用規約が適用され、価格や仕様が変わりうる前提です。

Jev互換の質問形式で乗り換え時に変わる接続先と認証方式の差分

Microsoft-Decision-1の質問形式は、TypeSafe AIのJevとほぼ同じです。JevのAPIリファレンスと比べると、state と questions の構造、noul・choice・score の型名、エンドポイント名の systemone まで共通しています。入力0.042ドル・出力無料という単価も同じです。

乗り換えで書き換えるのは3か所です。接続先をFoundryリソースの /providers/microsoft/v1/systemone に変える。認証をTypeSafeのAPIキーからEntra IDトークンかAzureのキーに変える。model をJevのモデルIDからFoundryのデプロイ名に変える。Jev固有の confidence の扱いは、Learnに同じ記載がないため、応答を見て確かめてから移してください。

主要な判断モデル4製品の料金・文脈長・提供段階・処理場所の比較表

各社の公式ページの値を並べました（2026年10月14日時点）。Cloudflare Clefの値はWorkers AIの料金ページ、GPT-6 Lunaの値はOpenAIのDecisionsガイドによります。

製品	入力単価（100万トークン）	文脈長	提供段階	処理場所の選択
Microsoft-Decision-1	0.042ドル	32,768	パブリックプレビュー	米国・欧州のデータゾーン
TypeSafe Jev 1.13	0.042ドル	全体64k	早期アクセス	記載なし
Cloudflare Clef-flash	0.038ドル	24,576	Workers AIで公開	記載なし
OpenAI gpt-6-luna	0.10ドル	記載なし	パブリックベータ	米国・欧州

単価の差は小さく、選定を分けるのは契約と処理場所です。すでにAzureで閉域接続や請求をまとめている企業なら、Microsoft-Decision-1が最も導入の手続きが少なくて済みます。画像を判断材料に含めたいなら、入力に画像を受け付けるGPT-6 Lunaが候補になります。

Microsoft-Decision-1を採用する条件と見送るべき場面の判断基準

ここまでの仕様と制約から、採否を条件付きで言い切ります。

Azure契約内で振り分けやエージェント制御を大量に回す場合の採用条件

採用を勧めるのは、次の3条件がそろう場合です。答えの候補が事前に決まっている判断を、月に数万件以上回す。判断材料を米国か欧州のデータゾーンで処理することに契約上の制約がない。Azureの契約と認証基盤をすでに使っている。問い合わせの一次振り分け、エージェントが次の手順を続けるか止めるかの判定、生成AIの回答を出す前の採点が典型です。

LLMに毎回「どれに当たるか」を答えさせている処理を置き換えると、JSONの崩れを直す後処理も不要になります。判断モデルとLLMをどこで分担させるかの設計から組み込みまでは、AIエージェント開発で要件整理から相談を受けています。

国内処理必須・人に関わる単独判断・日本語精度未検証なら見送る

次のいずれかに当たるなら、現時点では見送ります。

判断材料を国内リージョンで処理する契約・規程がある
採用・与信・医療など、人に関わる判断をモデル単独で決めたい
判断の理由を文章で残す必要がある
日本語の業務データでの精度を、まだ自社で測っていない

2番目について、Learnは信用・雇用・住宅・医療・法律に関わる判断では、人による実質的な確認を伴う支援に留めるよう明記しています。3番目は仕様上の制約で、このモデルは理由を返しません。理由が要る業務では、判断モデルで候補を絞ったあとにLLMで説明文を作る二段構成にします。

Microsoft-Decision-1の料金・日本語対応・使い方のよくある質問

Microsoft-Decision-1の導入を検討する際によく出る疑問に答えます。

Microsoft-Decision-1は日本語の文章を判断できますか？

2026年10月14日時点で、Microsoftの発表記事・Tech Community・Learnのいずれにも対応言語の記載はありません。ベースのQwen3.5は多言語のモデルですが、追加学習後の日本語の精度は公表されていません。日本語の問い合わせ100件程度に正解ラベルを付け、指示文を日本語にした場合と英語にした場合の正答率を比べてから判断してください。判断材料が日本語でも、指示文と選択肢の説明は英語のほうが安定する可能性があります。

無料で試す方法はありますか？

無料枠の記載はありません。ただしFoundryのPlaygroundで、Azureのアカウントがあれば画面上から質問を試せます。API経由でも入力100万トークンあたり0.042ドルのため、500トークンの判断を1,000件流しても約0.02ドルです。Azureの契約を作る前に精度だけ見たい場合は、OpenRouterからも呼び出せます。

LLMの構造化出力やJSONモードとは何が違いますか？

構造化出力は、LLMが生成した文字列をJSONの形に揃える仕組みで、確率は返りません。Microsoft-Decision-1は選択肢ごとの確率を返すため、「70%未満なら人へ回す」といった閾値の処理をコードで書けます。生成を伴わないぶん速く、出力の課金もありません。一方で、要約や説明文の作成はできないため、文章が必要な処理はLLMに任せます。

判断の理由を説明させることはできますか？

できません。Learnは、このモデルが文章による根拠を返さず数値の判断だけを返すと明記しています。監査や顧客への説明で理由が要る場合は、判断モデルの結果と入力をLLMに渡して説明文を作らせるか、判断のログ（入力・確率・閾値・最終処理）を保存して後から追える形にしてください。

パブリックプレビューの段階で本番に使ってよいですか？

社内の業務効率化で、失敗しても人が拾える処理なら使えます。顧客向けサービスの中核に置く場合は勧めません。プレビューはSLAの対象外で、Azureプレビューの補足利用規約により仕様や価格が変わりうるためです。本番に入れるなら、障害時にLLMやルールベースの分類へ切り替える経路と、判断結果を後から検証できるログを最初から用意してください。