はじめに
2026年10月9日、Microsoft Foundry に Microsoft-Decision-1 というモデルが追加されました。
このモデルは最近少し話題になったJevと同種のモデルで文章を生成しません。入力（テキストか JSON）と「選択肢つきの質問」を渡すと、判定結果（確率やスコア）だけを返します。
LLM に「このページは何のカテゴリ？ JSON で答えて」と頼むような処理を、もっと速く・安く・決まった形で返すことができるモデルです。今回このモデルについて情報分析に使う例を交えて紹介したいと思います。
- Decision-1 の基本（質問の型、上限、デプロイの種類、リージョン）
- Foundry ポータルと Azure CLI でのデプロイ手順
- 実際に、個人の Obsidian に貯めている Web クリップ（Web ページの要約メモ）210 件を「カテゴリ振り分け」「保存価値の採点」「中身の薄いページ判定」にかけた結果
- ハマったところ（デプロイの容量 = 1 分あたりのリクエスト数）と、向き・不向き
本記事の内容は 2026年10月12日時点のものです。公開直後のモデルでかつプレビュー提供なので、リージョンや価格は今後変わる可能性があります。
Microsoft-Decision-1 とは
公式ドキュメントでは、分類・振り分け・順位づけ・採点・Yes/No 判定のためのモデルとして紹介されています。
| 生成 LLM（GPT 系など） | Microsoft-Decision-1 | |
|---|---|---|
| 出力 | 文章 | 判定結果（選んだ答えと、その確からしさを表す数値） |
| 出力の形式 | プロンプト次第で変わる | 質問の型ごとに固定 |
| 理由の説明 | 書ける | 返さない |
| 向いている作業 | 要約・書き直し・説明 | 分類・ゲート・採点・ルーティング |
「自然言語で条件を書ける if 文」と考えると分かりやすいです。文章を作る作業は生成 LLM に任せ、その手前の振り分けに Decision-1 を挟む、という組み合わせ方が公式でも推奨されています。
なお、同じ種類のモデルとしてTypeSafe AIのJev（2026年9月に早期公開）があり、質問の型やAPIの形はかなり似ています。Decision-1の中身は、AlibabaのオープンウェイトモデルQwen3.5-9BをMicrosoftが追加学習したものです（Foundry のモデルカードと Microsoft のブログに記載）。今後はMAIやOpenAI系のモデルにも載せ替える予定とされています。
基本スペック
| 項目 | 内容 |
|---|---|
| モデル名 / バージョン | Microsoft-Decision-1 /1 |
| 入力 | テキストのみ（画像・音声・動画は不可） |
| 入力上限 | 32K トークン（1 回の呼び出しで採点） |
| デプロイの種類 | GlobalStandard、一部リージョンで DataZoneStandard |
| API | Decision API（/providers/microsoft/v1/systemone） |
| 認証 | Microsoft Entra ID（推奨）または API キー |
質問の型は 3 種類
| 型 | 用途 | 返り値 |
|---|---|---|
noul |
はい／いいえ（ゲート・フィルタ） | 0〜1 の確率 |
choice |
決まった選択肢から 1 つ（分類・振り分け・ツール選択） | 選ばれた選択肢＋全選択肢の確率 |
score |
順序つきの段階（優先度・採点） | 段階番号の確率加重平均（4 段階なら 0〜3 の小数） |
同じ入力（state）に対する質問は 1 リクエストにまとめられます。 今回は 1 リクエストで 3 問（choice / score / noul）を同時に聞いています。
リクエストとレスポンスの具体的な形は、後半の「API の呼び出し方」で紹介します。
デプロイの種類とリージョン
GlobalStandardとDataZoneStandardで展開されています。すべてのリージョンで利用可能ではないので注意が必要です。
| 種類 | 推論が行われる場所 | 特徴 |
|---|---|---|
| GlobalStandard | Azure のどのリージョンでも | 容量を確保しやすい。遅延はばらつくことがある |
| DataZoneStandard | 選んだデータゾーン（EU/USなど）の中 | データの処理場所をゾーン内に限定できる。対応リージョンは一部のみ |
今使えるリージョン（2026-10-14 時点）
Foundry のモデルカタログ（Microsoft-Decision-1 のページ）に載っているリージョン一覧をまとめると、次のとおりです。
| デプロイの種類 | 使えるリージョン |
|---|---|
GlobalStandard と DataZoneStandard の両方 |
米国: East US、East US 2、Central US、North Central US、South Central US、West Central US、West US、West US 3 欧州: France Central、Germany West Central、Italy North、Poland Central、Spain Central、Sweden Central、West Europe |
GlobalStandard のみ |
日本: Japan East、Japan West その他: Australia East、Brazil South、Canada Central、Canada East、Korea Central、Norway East、South Africa North、South India、Switzerland North、Switzerland West、UAE North、UK South |
| 使えない | Central India、East Asia、North Europe、Qatar Central、Southeast Asia、UK West、West US 2、East US 2 EUAP |
- 日本の 2 リージョン（Japan East / Japan West）は
GlobalStandardのみです。今回の検証は Japan East で行いました -
DataZoneStandardは米国と欧州のデータゾーンだけです。推論を日本国内に限定することはできません - North Europe や Southeast Asia、West US 2 のように、よく使われるリージョンでも使えない場合があります
- OpenRouter での提供は「近日」とされています
一覧は執筆時点のカタログの表示です。公開直後のモデルなので、デプロイ前にご自分の環境で確認してください。
自分のリソースのリージョンで使えるかは、次のコマンドでも確認できます。
az cognitiveservices model list \
--location japaneast \
--query "[?model.name=='Microsoft-Decision-1'].{name:model.name, version:model.version, skus:model.skus[].name}" \
--output json
価格
報道ベースでは 入力 100 万トークンあたり $0.042、出力は無料（Jev と同額）とされています。執筆時点では公式の価格表で確認できていません。今回の 210 件（約 14 万トークン）で 約 $0.006（1 円ほど） でした。
今回試した環境
| 項目 | バージョン・内容 |
|---|---|
| OS | Windows 11 |
| Python | 3.12（標準ライブラリのみ。requests 等は不要） |
| Azure CLI | 2.x（az login 済み） |
| Foundry リソース | japaneast、GlobalStandard
|
| 必要なロール | デプロイ: Cognitive Services Contributor / 呼び出し: Cognitive Services User 相当 |
デプロイ手順
ポータルと CLI のどちらでもデプロイできます。簡単に挙動を試したい人はポータルでの確認利用がおすすめです。
方法 1: Foundry ポータル
-
Foundry ポータル を開き、対象のプロジェクトに移動
対象のプロジェクトは先ほど紹介したDecision-1が使えるリージョンにデプロイされたものを使用してください。 - モデルカタログ を開く
-
Microsoft-Decision-1を検索して選択 - デプロイ を選び、デプロイ名・デプロイの種類（GlobalStandard など）・容量を設定して デプロイ
- デプロイの詳細画面で、エンドポイント・デプロイ名・API キーを控える
方法 2: Azure CLI
az cognitiveservices account deployment create \
--name <ACCOUNT_NAME> \
--resource-group <RESOURCE_GROUP> \
--deployment-name decision-1-trial \
--model-name "Microsoft-Decision-1" \
--model-format Microsoft \
--model-version "1" \
--sku-name GlobalStandard \
--sku-capacity 50
公式の CLI 例は --sku-capacity 1 ですが、そのままだと1分に1リクエストしか通りません。
Decision-1 の容量（capacity）はトークン数ではなく1分あたりのリクエスト数のようです。今回のサンプルのようにまとまったリクエストを投げたいときはCapacityは上げておくといいと思います。
- 従量課金なので、容量を上げても固定費は増えません
- サブスクリプションの上限（クォータ）は私の環境では 60 でした
<ACCOUNT_NAME> はFoundryリソース名です。デプロイ一覧は次で確認できます。
az cognitiveservices account deployment list \
--resource-group <RESOURCE_GROUP> \
--name <ACCOUNT_NAME> \
--output table
まずはプレイグラウンドで試す
コードを書く前に挙動を見るだけなら、Foundry ポータルのプレイグラウンドが手軽です。デプロイの詳細画面の「プレイグラウンド」タブを開くと、次の 2 つを入力して「実行」するだけで結果が見られます。
- 状態: 判定したい文章（API の state）
- 決定 JSON: 質問の定義（API の questions の中身。state や model は含めない）
上の例では、「今日、アカウントの支払いが 2 回失敗しました。今日中にサポートが必要です。」という文章に 3 つの質問をまとめて投げています。
| 質問 | 型 | 結果 |
|---|---|---|
| urgency : 顧客は緊急の支援を必要としているか | noul | true が 99.72% |
| team: どのチームが処理すべきか | choice | billing（信頼度 100%） |
| priority : 優先度はどれくらいか | score（3 段階） | 加重スコア 1.4687（信頼度 29.67%） |
priority は「1: ある程度の時間的制約あり」が 53.12%、「2: 即時の対応が必要」が 46.88% と割れていて、そのぶん信頼度が低く出ています。score の値だけを見ると「1 と 2 の間」に見えますが、段階ごとの確率を見ると判断が割れていることがわかります。こうした迷いが数値で見えるのが、このモデルの使いどころです。
画面右上の「JSON」を切り替えると生のレスポンスも確認できます。質問の文言や選択肢を変えて結果がどう動くかを見てからAPIに移ると、質問を設計しやすくなります。
API の呼び出し方
エンドポイントとリクエスト
<Foundry リソースのエンドポイント>/providers/microsoft/v1/systemone
model にはデプロイ名を入れます（モデル名ではありません）。
先ほどプレイグラウンドで試した例を、そのまま API で呼び出してみます。プレイグラウンドの「状態」が state、「決定 JSON」が questions に入ります。model にはデプロイ名（ここでは decision-1-trial）を書きます。
export AZURE_ENDPOINT="https://<ACCOUNT_NAME>.cognitiveservices.azure.com"
export AZURE_ENTRA_TOKEN=$(az account get-access-token \
--resource https://cognitiveservices.azure.com \
--query accessToken --output tsv)
# リクエスト本文を UTF-8 のファイルに書き出す
cat > body.json <<'EOF'
{
"model": "decision-1-trial",
"state": "今日、アカウントの支払いが2回失敗しました。今日中にサポートが必要です。",
"questions": {
"urgency": {
"type": "noul",
"instructions": "顧客は緊急の支援を必要としていますか?"
},
"team": {
"type": "choice",
"instructions": "どのチームが要求を処理する必要がありますか?",
"criteria": {
"billing": "支払いと請求書に関する問題",
"technical": "ソフトウェアと統合の問題"
}
},
"priority": {
"type": "score",
"instructions": "この要求の優先度はどれくらいですか?",
"criteria": [
"普通で、時間的制約なし",
"重要で、ある程度の時間的制約あり",
"緊急で、即時の対応が必要"
]
}
}
}
EOF
curl -s "$AZURE_ENDPOINT/providers/microsoft/v1/systemone" \
-H "Content-Type: application/json; charset=utf-8" \
-H "Authorization: Bearer $AZURE_ENTRA_TOKEN" \
--data-binary @body.json
Windows（Git Bash や PowerShell）で日本語を含む JSON を -d '{...}' のようにコマンドラインへ直接書くと、文字コードが変わって Request body could not be parsed as JSON. というエラーになることがあります。今回も実際にこのエラーが出ました。上のように本文を UTF-8 のファイルにして --data-binary @ファイル名 で送ると確実です。
API キーを使う場合は Authorization ヘッダーの代わりに -H "api-key: <API キー>" を付けます。
レスポンス
実際に返ってきたレスポンスです（読みやすいように整形し、数値は小数第 4 位で丸めています）。
{
"model": "microsoft-decision-1",
"answers": {
"priority": {
"confidence": 0.2967,
"legend": {
"0": "普通で、時間的制約なし",
"1": "重要で、ある程度の時間的制約あり",
"2": "緊急で、即時の対応が必要"
},
"probabilities": { "0": 0.0001, "1": 0.5312, "2": 0.4687 },
"score": 1.4687,
"type": "score"
},
"team": {
"choice": "billing",
"confidence": 1.0,
"probabilities": { "billing": 1.0, "technical": 0.0 },
"type": "choice"
},
"urgency": {
"noul": 0.9968,
"type": "noul"
}
},
"usage": { "input_tokens": 129, "output_tokens": 3 }
}
プレイグラウンドの画面とほぼ同じ値が返ってきています（team の confidence は実際には 0.99995 で、画面では 100% と表示されていました）。urgency は画面の 99.72% に対して API では 99.68% と少しだけ違いますが、判定の結果は変わりません。
-
answersのキーは、リクエストで付けた質問名（urgency/team/priority）がそのまま使われます -
output_tokensは 3。文章を生成しないので、出力側はほぼゼロです - レスポンスの
modelはデプロイ名ではなくmicrosoft-decision-1になります
検証: 気になるニュース 210 件を振り分ける
Decision-1を使うにあたってまとまった情報で試してみたく、Obisidianに蓄積している情報で検証してみました。
普段から、興味のある Webサイトや技術情報の要約メモを Obsidianに記録しています。件数がかなり多くなってきたことと、カテゴリや内容も色々な粒度になっているため、カテゴリの付け直しと捨ててよいページの洗い出しをするとどうなるか検証してみました。
既存のメモはすでに7つのカテゴリのフォルダに分かれているので、各カテゴリから30件ずつ、計210件を抜き出し、フォルダ名を「正解」としてDecision-1の判定と比べました。
質問の設計
1 件のメモ（本文 4,000 字まで）に対して、3 つの質問を 1 リクエストで投げます。
| 質問名 | 型 | 内容 |
|---|---|---|
category |
choice（7 択） |
主題に最も合うカテゴリ |
keep_value |
score（4 段階） |
個人のナレッジベースに長期保存する価値 |
thin_page |
noul |
ログイン画面・トップページ・一覧などの中身の薄いページか |
メモには Category: という行でフォルダと同じカテゴリ名が書かれているので、正解が漏れないように送信前に削除しています。
実際の処理は1件ごとに次のような情報をやり取りしています。リクエストのquestionsは後述のコードのQUESTIONSで、stateにはメモの本文が入ります。返ってきたレスポンスの例です（数値は見やすいように丸めています）。
{
"model": "microsoft-decision-1",
"answers": {
"category": {
"type": "choice",
"choice": "AI",
"confidence": 0.898,
"probabilities": {
"AI": 0.913,
"開発技術": 0.085,
"XR": 0.0003,
"イベント": 0.0002,
"クラウド・インフラ": 0.0005,
"ハードウェア": 0.0006,
"空間コンピューティング": 0.0005
}
},
"keep_value": {
"type": "score",
"score": 2.994,
"confidence": 0.994,
"probabilities": { "0": 0.0001, "1": 0.0013, "2": 0.0032, "3": 0.9954 },
"legend": {
"0": "価値なし（中身がない、ログイン画面、広告、エラーページ）",
"1": "一時的（セール・告知・速報など時間が経つと不要）",
"2": "参考程度（一般的な内容で、後で探す可能性は低い）",
"3": "有用（具体的な技術情報・手順・知見を含む）"
}
},
"thin_page": {
"type": "noul",
"noul": 0.0003
}
},
"usage": { "input_tokens": 793, "output_tokens": 3 }
}
category は「AI」を 91% で選び、keep_value はほぼ 3（有用）、thin_page はほぼ 0（中身のあるページ）という判定です。これを 210 件分集めて、既存のフォルダと比べました。
コード（判定の実行）
標準ライブラリだけで書いています。認証は az account get-access-token で取ったトークンを使っています。
"""Microsoft-Decision-1 で Web クリップのメモを試し分類する。
usage: python decision_trial.py probe | run <n_per_cat>
"""
import json, os, random, re, subprocess, sys, time, urllib.request, urllib.error
from concurrent.futures import ThreadPoolExecutor
from pathlib import Path
ENDPOINT = "https://<ACCOUNT_NAME>.cognitiveservices.azure.com"
URL = f"{ENDPOINT}/providers/microsoft/v1/systemone"
DEPLOYMENT = "decision-1-trial"
RAW = Path(r"<Web クリップのフォルダ>")
OUT = Path(__file__).parent / "decision_results.jsonl"
CATS = {
"開発技術": "プログラミング言語、開発ツール、ライブラリ、Git、CI/CD、Web 開発などソフトウェア開発全般",
"AI": "生成 AI、LLM、機械学習、AI エージェント、AI サービス",
"XR": "VR / AR / MR、XR デバイス、Unity・XR 開発、メタバース",
"ハードウェア": "PC、スマホ、電子工作、ガジェット、半導体などの機器",
"空間コンピューティング": "Apple Vision Pro / visionOS、空間 UI、空間コンピューティング全般",
"クラウド・インフラ": "Azure、AWS、サーバー、ネットワーク、インフラ運用",
"イベント": "勉強会・カンファレンス・展示会の告知や参加レポート",
}
QUESTIONS = {
"category": {
"type": "choice",
"instructions": "この Web ページ要約の主題に最も合うカテゴリはどれか",
"criteria": CATS,
},
"keep_value": {
"type": "score",
"instructions": "個人の技術ナレッジベースに長期保存して後で検索する価値はどれくらいか",
"criteria": [
"価値なし（中身がない、ログイン画面、広告、エラーページ）",
"一時的（セール・告知・速報など時間が経つと不要）",
"参考程度（一般的な内容で、後で探す可能性は低い）",
"有用（具体的な技術情報・手順・知見を含む）",
],
},
"thin_page": {
"type": "noul",
"instructions": "この要約は中身の薄いページ（ログイン・トップページ・一覧・404・広告など）か",
"criteria": {
"true": "具体的な情報がほとんどない",
"false": "記事・ドキュメントとして具体的な情報がある",
},
},
}
_token = None
def token():
global _token
if _token is None:
_token = subprocess.check_output(
["az", "account", "get-access-token", "--resource", "https://cognitiveservices.azure.com",
"--query", "accessToken", "-o", "tsv"], shell=True, text=True).strip()
return _token
def call(state):
body = json.dumps({"model": DEPLOYMENT, "state": state, "questions": QUESTIONS}).encode()
req = urllib.request.Request(URL, data=body, method="POST", headers={
"Content-Type": "application/json", "Authorization": f"Bearer {token()}"})
for attempt in range(5):
t0 = time.perf_counter()
try:
with urllib.request.urlopen(req, timeout=60) as r:
return json.loads(r.read()), time.perf_counter() - t0
except urllib.error.HTTPError as e:
if e.code == 429 and attempt < 4:
time.sleep(5 * 2 ** attempt)
continue
raise RuntimeError(f"{e.code}: {e.read().decode(errors='replace')[:500]}")
def load(path):
text = path.read_text(encoding="utf-8", errors="replace")
# 正解ラベルが漏れないよう Category/SubCategory 行は落とす
text = re.sub(r"^(Category|SubCategory):.*\n", "", text, flags=re.M)
return text[:4000]
def sample(n_per_cat):
random.seed(42)
picked = []
for cat in CATS:
files = [p for p in RAW.glob(f"*/Lists/*/{cat}/*.md")]
picked += [(cat, p) for p in random.sample(files, min(n_per_cat, len(files)))]
return picked
def main():
if sys.argv[1] == "probe":
cat, p = sample(1)[0]
res, dt = call(load(p))
print(p, f"{dt*1000:.0f}ms")
print(json.dumps(res, ensure_ascii=False, indent=2))
return
items = sample(int(sys.argv[2]))
# デプロイの上限は 50 リクエスト/分。開始間隔を 1.3 秒空けて超えないようにする
import threading
lock, last = threading.Lock(), [0.0]
def work(item):
cat, p = item
with lock:
wait = last[0] + 1.3 - time.monotonic()
if wait > 0:
time.sleep(wait)
last[0] = time.monotonic()
try:
res, dt = call(load(p))
return {"truth": cat, "path": str(p.relative_to(RAW)), "ms": round(dt * 1000), "res": res}
except Exception as e:
return {"truth": cat, "path": str(p.relative_to(RAW)), "error": str(e)}
with ThreadPoolExecutor(4) as ex, OUT.open("w", encoding="utf-8") as f:
for row in ex.map(work, items):
f.write(json.dumps(row, ensure_ascii=False) + "\n")
print("done", len(items), "->", OUT)
if __name__ == "__main__":
main()
ポイントは 3 つです。
- modelにデプロイ名（decision-1-trial）を指定
- 1.3秒間隔で送信して、デプロイの上限（50リクエスト/分）を超えないように調整
- subprocess のshell=TrueはWindowsでaz（実体はaz.cmd）を呼ぶため。Linux / macOS では外して構いません
実行は次のとおりです（az login 済みが前提）。
# 1 件だけ試す
python -I -X utf8 decision_trial.py probe
# 各カテゴリ 30 件ずつ（計 210 件）
python -I -X utf8 decision_trial.py run 30
コード（集計）
import json, statistics
from collections import Counter, defaultdict
from pathlib import Path
rows = [json.loads(l) for l in (Path(__file__).parent / "decision_results.jsonl").read_text(encoding="utf-8").splitlines()]
ok = [r for r in rows if "res" in r]
print(f"total {len(rows)} ok {len(ok)} error {len(rows) - len(ok)}")
ms = [r["ms"] for r in ok]
toks = [r["res"]["usage"]["input_tokens"] for r in ok]
print(f"latency p50 {statistics.median(ms)}ms p90 {sorted(ms)[int(len(ms)*.9)]}ms / input tokens avg {statistics.mean(toks):.0f} sum {sum(toks)}")
per = defaultdict(Counter)
conf_ok, conf_ng = [], []
for r in ok:
a = r["res"]["answers"]["category"]
per[r["truth"]][a["choice"]] += 1
(conf_ok if a["choice"] == r["truth"] else conf_ng).append(a["confidence"])
hit = sum(per[c][c] for c in per)
print(f"\n== カテゴリ一致 {hit}/{len(ok)} = {hit/len(ok):.0%} (確信度 平均: 一致 {statistics.mean(conf_ok):.2f} / 不一致 {statistics.mean(conf_ng):.2f})")
for c, cnt in per.items():
print(f"{c}: {cnt[c]}/{sum(cnt.values())} 外れ先 {dict((k, v) for k, v in cnt.most_common() if k != c)}")
hi = [r for r in ok if r["res"]["answers"]["category"]["confidence"] >= 0.8]
hh = sum(r["res"]["answers"]["category"]["choice"] == r["truth"] for r in hi)
print(f"確信度0.8以上: {len(hi)}件 一致率 {hh/len(hi):.0%}")
print("\n== 不一致の例")
for r in [r for r in ok if r["res"]["answers"]["category"]["choice"] != r["truth"]][:14]:
a = r["res"]["answers"]["category"]
print(f" [{r['truth']}→{a['choice']} {a['confidence']:.2f}] {r['path'].split(chr(92))[-1][:60]}")
print("\n== 保存価値スコア分布 (0価値なし〜3有用)")
b = Counter(round(r["res"]["answers"]["keep_value"]["score"]) for r in ok)
print(dict(sorted(b.items())))
print("低スコア(<1.5)の例:")
for r in sorted(ok, key=lambda r: r["res"]["answers"]["keep_value"]["score"])[:10]:
print(f" {r['res']['answers']['keep_value']['score']:.2f} {r['path'].split(chr(92))[-1][:60]}")
thin = [r for r in ok if r["res"]["answers"]["thin_page"]["noul"] >= 0.5]
print(f"\n== 薄いページ判定(>=0.5): {len(thin)}件")
for r in thin[:10]:
print(f" {r['res']['answers']['thin_page']['noul']:.2f} {r['path'].split(chr(92))[-1][:60]}")
結果
速度とコスト
| 項目 | 結果 |
|---|---|
| 成功 / 失敗 | 210 / 0 |
| 応答時間 | 中央値 381 ms、90% 点 796 ms（japaneast からの実測） |
| 入力トークン | 平均 671、合計 約 14 万 |
| 費用 | 約 $0.006（約 1 円） ※報道ベースの単価で計算 |
カテゴリ振り分け（choice）
既存フォルダとの一致率は 151/210 = 72% でした。おおむね自分で整理していた内容とカテゴリ分類は一致していることがわかりました。
| 正解（既存フォルダ） | 一致 | 主な外れ先 |
|---|---|---|
| イベント | 30/30 | なし |
| AI | 26/30 | 開発技術 3 |
| クラウド・インフラ | 26/30 | 開発技術 2 |
| XR | 23/30 | イベント 4 |
| 開発技術 | 22/30 | AI・XR・クラウド 各 2 |
| ハードウェア | 21/30 | 開発技術 4、XR 4 |
| 空間コンピューティング | 3/30 | XR 14 |
ただ、空間コンピューティングのカテゴリが大きく外しているのですが、これはそもそも分類の仕方が悪かったとしか言えないです。XRと空間コンピューティングの概念はかなり近いものなので、LLMが困ってしまうような状況を生んでいたといえるかもしれません。
保存価値（score）と薄いページ判定（noul）
保存価値スコアの分布（四捨五入）は次のとおりです。
| スコア | 意味 | 件数 |
|---|---|---|
| 3 | 有用 | 139 |
| 2 | 参考程度 | 28 |
| 1 | 一時的 | 39 |
| 0 | 価値なし | 4 |
スコアが低かったのは、次のようなページでした。
- メーカー直販ストアのトップページ・製品の紹介ページ
- セール情報のまとめ記事
どれも「捨ててよい」と私が判断するものとほぼ同じでした。
薄いページ判定（noul ≥ 0.5）は 9 件で、製品紹介ページ・イベント一覧ページなど。誤検出と言えるのは、内容の短いリリースノート（変更点が数行だけのページ）程度でした。
向いていること・向いていないこと
公式ブログなどでも解説はありますが、改めて整理すると以下のようになると思います。
向いている
- 大量の分類・振り分け（チケット、ドキュメント、アラート）
- ゲート・フィルタ（「この返信は返金を約束しているか」など）
- 優先度づけ・採点（LLM の出力の採点にも使える）
- どのモデル・ツール・エージェントに回すかの選択
- 今回のような「捨てる候補を拾う」用途
向いていない
- 要約・書き直し・説明など文章を作る作業 → 生成 LLM と組み合わせる
- 理由が必要な判断 → 理由は返らないので、外から確かめる仕組みが必要
使うときの注意（公式）
- 質問や選択肢の言い回し・並び順で結果が変わる。言い回しが悪くても何かしらのスコアは返ってくる
- 確率がよく当たるのは、モデルが慣れている種類のタスク
- 無理に選ばせたくないときは「判断できない（
cannot tell）」の選択肢を用意する - しきい値は自分のラベル付きデータで決める
- 人に関わる重要な判断（与信・採用など）では、唯一の判断材料にしない
まとめ
- Microsoft-Decision-1 は文章を生成せず、選択肢ごとの確率だけを返す判定専用モデル
- デプロイは Foundry ポータルのモデルカタログか Azure CLI。日本リージョン は
GlobalStandardのみ（執筆時点） - capacity は 1 分あたりのリクエスト数
- 選択肢の説明文がそのまま判断基準になる。
- 「捨てる候補を拾う」「振り分けて生成 LLM の前に挟む」用途にはすぐ使える
「自然言語で条件を書ける if 文」という表現がしっくりくるモデルです。低コストで判定だけ行えるためマルチエージェント運用や、様々なロジックの中でLLMによる条件分岐を手軽に導入するのに役だちそうです。