LLMの確率出力を決定木のように制御する：Decision Model導入による堅牢なAIシステム設計

はじめに：LLMエージェントの「確率」と「決定」の境界線

LLMは本質的に生成モデルであり、与えられた入力に対して確率的なトーク列を出力する。この特性は文章生成や推論支援には強みになるが、ビジネスロジックや制御フローに組み込む際には根本的な問題を生む。制御フローが要求するのは「分岐の確定」であり、確率的な出力をそのまま分岐条件に使うことは、システム全体の挙動を予測不能にする。

従来のアプローチでは、プロンプトにJSONスキーマを指定したり、システムプロンプトで出力形式を制約したりすることで、LLMの出力を構造化しようとしてきた。しかし、この手法はモデルの内部状態を「外から押さえつける」ものであり、フォーマット違反や意図しない値の出力を完全に排除することはできない。特にエージェントアーキテクチャが複雑化するにつれ、こうした「確率の漏れ」がパイプライン全体に波及するリスクが高まっている。

近年、Microsoftは構造化された意思決定タスク向けの新モデルを発表している。これはテキスト生成ではなく、ルーティング・分類・優先順位付けといった「決定」に特化したモデルであり、LLMの確率出力を決定木のように制御するという設計思想を具体化している。公式発表を確認すると、このモデルは特定の決定タスクに最適化されていることが示唆されている。

本記事では、LLMエージェントの制御フローにおける「確率」と「決定」の境界線を明確にし、決定モデル（Decision Model）という設計パターンを用いて堅牢なAIシステムを構築するための技術的指針を解説する。

なぜ今、Decision Modelなのか：LLMの出力制御における課題

現代のエージェントアーキテクチャにおいて、LLMが担う役割は「推論」だけに限らない。入力タスクをどのサブエージェントにルーティングするか、リクエストの種類をどう分類するか、複数の候補から優先順位をどう付けるか——こうした「決定」の判断も、多くの場合LLMが担っている。Microsoft-Decision-1の設計目的である「ルーティング、分類、優先順位付け、検証、ワークフロー制御」は、まさにこの層の課題を指している。

汎用LLMをこれらの決定用途に使うと、以下のような問題が起きる。第一に、出力フォーマット違反である。JSONスキーマを指定しても、モデルがスキーマにないキーを出力したり、Enumの範囲外の値を返したりする。第二に、意図しない出力によるパイプラインの分岐ミスである。例えば「分類不能」という出力が想定されておらず、例外処理が追いつかない。第三に、遅延である。汎用LLMは複雑な推論プロセス（Chain-of-Thoughtなど）を内部で実行するため、単なる分類判断にも数百ミリ秒〜数秒の応答時間が発生する。リアルタイム性が求められる制御フローでは、この遅延がボトルネックになる。

これらの課題の根本原因は、汎用LLMが「推論能力」を最適化の対象としていることにある。決定タスクにとって推論能力は不要であり、むしろオーバーヘッドに過ぎない。決定タスクに特化したモデル——すなわちDecision Model——を用いることで、確率を排除し、構造化出力のみを返す堅牢な設計が可能になる。公式発表でも、決定モデルは「テキスト生成や複雑な推論ではなく、ソフトウェアが即座に活用できる構造化出力を目的としている」と明記されている。

Decision Modelの技術的特徴：推論ではなく決定に特化する

Decision Modelの技術的特徴を一言で言えば、「出力の制約がモデルの設計に組み込まれている」ことである。汎用LLMが「何でもいいから生成しろ」という設計であるのに対し、Decision Modelは「このスキーマの範囲内で、このEnumの値のうち一つを返せ」という設計になっている。出力が構造化されることはプロンプトによる外部制約ではなく、モデルの学習目標そのものとして定着しているため、フォーマット違反の発生率が構造的に低くなる。

「System One」モデルとしての位置づけ

認知科学における「System 1（直感的・高速な判断）」と「System 2（分析的・低速な推論）」の比喩が、この分野でも使われている。Strands Deciderは、LLMよりも高速に calibrated confidence を持つ決定を下す「system one」モデルの一種として設計されている。calibrated confidence とは、モデルが「この判断は信頼度80%」と出力したとき、実際に80%の確率で正解しているという自己評価の精度を指す。この値が後続のフォールバック戦略（信頼度が閾値を下回ったら人間確認にエスカレートする、など）の判断材料として使える点が、単なるBoolean出力との決定的な違いである。

推論環境の最適化

決定モデルは汎用LLMと比べてパラメータ数が小さく、推論時の計算負荷が低い。そのため、量子化などの最適化が精度への影響を大きく出さずに適用できる。deck31bは、Gemma 4 31BベースのFP8量子化された決定モデルで、TorchAOを用いて推論を行う。FP8量子化は16bit浮動小数点の半分である8bitの精度で重みを表現する手法であり、メモリ帯域幅と計算量を削減できる。決定タスクは汎用推論と比べて出力空間が狭く（Enumの値が数個〜数十個程度）、量子化による精度劣化の影響が相対的に小さいという特性がある。これは、エッジデバイスや低コストな推論環境でもDecision Modelをデプロイできることを意味する。

ただし、量子化の適用は「精度が落ちない」ことを保証するものではない。特定のドメインでの精度劣化リスクは常に存在し、導入前に自社のデータセットでの検証が不可欠である。この点は後述の「落とし穴」セクションで詳しく扱う。

ベンチマーク結果から読み解く：精度と速度のトレードオフ

Microsoft-Decision-1のベンチマーク結果は、36のタスク（約15万件の質問）において最高精度を達成している。ここで重要なのは、この「最高精度」が汎用推論タスクではなく、ルーティング・分類・優先順位付け・検証・ワークフロー制御といった構造化された決定タスクに限定されている点である。汎用LLMが得意とする長文生成や多段推論の精度とは、測定対象が根本的に異なる。

速度面では、GPT-6 Solより35倍、Quyet-1.0-Largeより4.5倍高速という数値が示されている。この差は、モデルが出力するトークン数を最小限に抑え、Chain-of-Thoughtのような中間推論ステップを省略する設計思想から生じる。汎用LLMが「考える」時間をかけている間に、Decision Modelはすでに構造化された答えを返している。

トレードオフの本質：何を得て何を捨てるか

この速度と精度の両立には明確な代償がある。汎用推論能力の削ぎ落としである。Decision Modelは「この入力に該当するカテゴリは何か」「どのパスを通すべきか」という問いには強いが、「この文脈では何が適切か」を推論する能力は持たない。つまり、タスクが「既知の分類に収まる」場合にのみ、その性能が意味を持つ。

エージェント設計における実務的な意味は以下の通りだ。ユーザーリクエストを受け付けてから応答を返すまでのレイテンシが、リアルタイム性の要件（例：チャットボットの応答時間、APIゲートウェイのタイムアウト閾値）に収まるかどうかは、決定ノードの処理時間に大きく依存する。汎用LLMをルーティングに使うと、推論時間のばらつきが応答時間の下限を押し上げる。Decision Modelに置き換えることで、この下限を大幅に下げる可能性がある。

観点	Decision Model	汎用LLM
出力形式	構造化（JSON, Enum, Boolean）	自然言語＋任意の構造化
推論ステップ	なし（即答）	CoT等の多段推論あり
速度	高速（ms〜数十ms級）	低速（秒級）
得意タスク	分類・ルーティング・検証	生成・推論・文脈理解
失敗モード	分類ミス（誤ルーティング）	フォーマット違反・意図しない出力

ベンチマークの数値は理想条件下での結果であり、実際の入力分布がトレーニングデータと一致しない場合、精度は低下する。特に、分類カテゴリの境界が曖昧な入力や、トレーニング時にカバーされなかった新しいパターンに対しては、汎用LLMの方が頑健に振る舞う場合がある。ベンチマークの「最高精度」は、そのモデルが設計されたタスク空間内での話であり、そのまま実環境の精度を保証するものではない。

アーキテクチャ設計：Decision Modelをエージェントフローに組み込む

Decision Modelをエージェントシステムに組み込む際の核心は、「どこで呼び出すか」という配置の設計である。すべてのリクエストにDecision Modelを通す必要はなく、分岐が生まれるノード（決定点）にのみ配置する。これにより、決定ロジックと実行ロジックが分離され、それぞれのモデルの特性を活かした設計が可能になる。

役割分担の原則

Decision Modelが担うのは、ルーティング（どのサブエージェントに転送するか）、分類（入力タスクの種類を識別する）、優先順位付け（リソース配分の判断）、検証（出力の妥当性チェック）、ワークフロー制御（次のステップの決定）である。一方、LLMはコード生成、文章作成、複雑な推論といった「実行・生成」に集中する。この分離により、決定ロジックの更新（例：新しいカテゴリの追加）がLLMのプロンプト変更を伴わずに行えるようになる。

具体的には、エージェントの入口にDecision Modelを配置し、入力の内容に応じて異なるLLMエージェントやツールチェーンにルーティングする。ルーティングの判断はEnum値として返されるため、後続の処理はswitch文やマップ参照で対応でき、LLMの出力をパースする必要がない。これが「決定木のように制御する」という意味の核心である。

flowchart TD
    A["ユーザー入力"] --> B["Decision Model（ルーティング）"]
    B --> C{"タスク分類"}
    C -->|"コード生成"| D["LLM: コードエージェント"]
    C -->|"データ分析"| E["LLM: 分析エージェント"]
    C -->|"簡易応答"| F["ルールベース応答"]
    D --> G["統合出力"]
    E --> G
    F --> G

この設計の利点は、モジュール性である。コードエージェントのLLMをモデルBからモデルCに差し替えたとすると、影響範囲はコードエージェントの内部だけにとどまり、ルーティングロジックや分析エージェントには何の変更も不要である。逆に、ルーティングのカテゴリを追加する場合も、Decision Modelの分類空間を更新するだけで済み、各LLMエージェントの挙動は変わらない。

ただし、Decision Modelの出力が誤った場合、後続の全フローが誤ったパスに進むリスクがある。このため、Decision Modelの出力には必ず検証層（後述）を挟み、異常検知時にデフォルトパスへフォールバックする設計が必須である。

実装パターン：構造化出力と検証の仕組み作り

Decision Modelからの出力は、構造化されていることを前提としていても、スキーマベースの検証を省略してはならない。モデルのバージョン更新や入力分布の変化により、期待外の形式で返却される可能性は常に存在する。検証層は、システム全体の信頼性を支える最後の防衛線である。

スキーマ検証の実装

出力の検証には、JSON SchemaやPydanticのようなスキーマ定義ツールを用いる。Decision Modelが返すJSONが、定義済みのスキーマに適合するかを呼び出し直後にチェックし、不適合の場合は例外を送出してフォールバック処理に移行する。ここで重要なのは、検証エラーを「ログに記録して無視する」のではなく、明示的に例外として扱うことである。無視された検証エラーは、後続の処理でより深刻な不整合として表面化する。

from pydantic import BaseModel, ValidationError
import json

class RoutingDecision(BaseModel):
    target_agent: str  # "code" | "analysis" | "simple"
    confidence: float  # 0.0 ~ 1.0
    reason: str        # 監査ログ用（任意）

def parse_decision(raw_output: str) -> RoutingDecision:
    """Decision Modelの生出力をパースし、スキーマ検証を行う。"""
    data = json.loads(raw_output)
    return RoutingDecision(**data)

# 呼び出し例
try:
    decision = parse_decision(raw_output_from_model)
    if decision.confidence < 0.7:
        # 低confidenceの場合のフォールバック
        decision = RoutingDecision(
            target_agent="default",
            confidence=0.0,
            reason="low_confidence_fallback"
        )
except ValidationError as e:
    # スキーマ違反：デフォルトパスへ
    decision = RoutingDecision(
        target_agent="default",
        confidence=0.0,
        reason=f"schema_violation: {e}"
    )

フォールバック戦略の設計

Decision Modelが信頼できない決定を下した場合の対処は、以下の3段階に整理できる。第一に、confidenceが閾値を下回った場合はデフォルトパス（最も安全な処理）に振り向ける。第二に、スキーマ違反が発生した場合は、汎用LLMに切り替えて再判定させる。第三に、連続してフォールバックが発生した場合は、アラートを発出して人間の介入を促す。この3段階の閾値とトリガー条件は、実環境での誤判定率をモニタリングしながら調整する。

出力構造の設計では、後続のアクション実行に必要な最小限のフィールドのみを含めることを原則とする。過剰なメタデータ（例：推論の中間ステップ、代替候補の列挙）を含めると、パースの複雑さが増し、検証の負荷も上がる。Decision Modelの出力は「決定」であり、「説明」ではない。説明が必要な場合は、reasonフィールドに短い文字列を付与する程度に留め、本体の決定値とは分離する。

実装の構成としては、Decision Modelを独立した関数（またはマイクロサービス）としてラップし、呼び出し側からモデルの詳細（エンドポイント、認証、リトライ設定）を隠蔽する。これにより、モデルの差し替えやリトライポリシーの変更が、呼び出し側のコードに影響を与えないようにする。インターフェースは「入力テキスト → RoutingDecision」のシンプルな関数シグネチャに収める。

アクセスと展開：Microsoft FoundryとOpenRouterの活用

Microsoft-Decision-1は、Microsoft FoundryおよびOpenRouterを通じてAPI利用が可能である。この二つの経路は、それぞれ異なる設計上の利点を持ち、導入フェーズに応じて使い分けるのが合理的である。

Microsoft Foundry：企業内での管理・カスタマイズ

Foundry経由で利用する場合の主な利点は、モデルのライフサイクルを組織内で管理できる点にある。具体的には、自社ドメインのデータでファインチューニングを行うことで、ルーティングの判断基準を業務に合わせて調整できる。また、ネットワーク分離やデータ residency（データが置かれる地域の制約）といったセキュリティポリシーを適用しながら、モデル推論を社内環境に閉じた形で運用できる。

ただし、FoundryはMicrosoftエコシステムに紐づくため、他社のモデルとの横断的な比較がしにくい。特に、将来的にDecision Modelの選択肢が複数存在する前提で設計する場合、Foundry単独への依存はアーキテクチャの柔軟性を損なう要因になり得る。

OpenRouter：多様なモデルの比較・切り替え

OpenRouterは、複数のモデルプロバイダを単一のAPIインターフェース経由で呼び出せるサービスである。Decision Modelの文脈では、Microsoft-Decision-1とStrands Deciderやdeck31bなど、異なるアプローチの決定モデルを同一の呼び出しインターフェースで比較できる。これにより、特定のプロバイダへのロックインを回避しつつ、コストと精度のバランスを継続的に評価できる。

導入初期の推奨パターンは以下の通りである。まずOpenRouter経由で公開されているDecision Modelをプロダクション環境に接続し、実トラフィックでのレイテンシ・決定精度・コストを計測する。この段階で「自社のタスク分布に対して十分な性能か」を判定し、必要に応じてFoundry経由でファインチューニング版に切り替える。この二段階の導入により、初期投資を抑えつつ、性能要件に応じた最適な配置を選べる。

設計判断のトレードオフ：いつDecision Modelを採用すべきか

Decision Modelは、構造化された意思決定タスクに特化して設計されているが、それ以外のタスクには不向きである。採用判断の核心は、「その判断に文脈理解や創造的な推論が不可欠か」である。明確なルールやパターンで分類・ルーティングできるタスクではDecision Modelが有効だが、入力の意味を解釈し、新しい対応策を導き出す必要があるタスクでは、汎用LLMの推論能力が不可欠になる。

ハイブリッド設計における役割分担を整理すると、Decision Modelは「高速なフィルター」、汎用LLMは「深い処理」を担う。具体的には、ユーザー入力を受け入れた瞬間にDecision Modelが「このタスクはどのサブエージェントにルーティングすべきか」を即座に判定し、該当するサブエージェント内のLLMが実際の推論・生成を行う。この分離により、LLMの呼び出し回数を減らし、レイテンシとコストの両方を圧縮できる。

判断基準を整理すると、以下の表の通りである。

判断軸	Decision Modelが適する	汎用LLMが適する
出力の形式	Enum・Boolean・固定スキーマのJSON	自由形式のテキスト・多様な構造
判断の基準	明確なルール・パターンで判定可能	文脈依存・曖昧な境界がある
レイテンシ要件	数百ms以内が求められる	数秒〜十数秒許容可能
変更頻度	判断基準が頻繁に変わる	判断基準が安定している
失敗時の影響	誤判定がシステム停止に直結する	誤答が人間に確認される

特に注意すべきは「変更頻度」の軸である。ルーティングの判断基準がビジネス要件の変化に伴って頻繁に変わる場合、汎用LLMのプロンプト変更で対応できるのに対し、Decision Modelは再学習やファインチューニングが必要になる可能性がある。このコストを考慮して、判断基準が安定したタスクにDecision Modelを割り当てるのが安全である。

落とし穴：決定モデル特有の注意点と回避策

量子化による精度劣化

推論コストを削減するためにFP8量子化などの最適化を施すと、特定のドメインでの決定精度が低下するリスクがある。deck31bのようにGemma 4 31BベースをFP8量子化してTorchAOで推論するアプローチは、リソース効率では優れているが、量子化による情報損失が判断の境界付近で誤判定を増やす可能性がある。ベンチマークで示される精度は、テストセットの分布がトレーニング分布と一致している理想条件での値である。実環境では入力分布が異なるため、量子化版とフル精度版を並行して評価し、誤判定率の差が許容範囲内かを自社のデータで確認する必要がある。

解釈可能性の欠如と監査ログ

Decision Modelは内部の決定プロセスを外部に開示しない。汎用LLMがChain-of-Thoughtで推論の過程をテキストとして出力できるのに対し、Decision Modelは構造化された決定値のみを返す。これは設計上の意図であるが、運用上は「なぜその決定を下したか」を事後に追跡できないという制約になる。

対策として、決定時に付随するメタデータ（入力テキストのハッシュ、決定値、confidence値、タイムスタンプ）を必ず監査ログに記録する。confidenceが閾値を下回ったケースは自動的にアラートに昇格させ、人間によるレビュー対象とする。これにより、モデルの判断が「正しいか」を定量的に評価できるだけでなく、誤判定のパターンを蓄積して改善の材料にできる。

分布シフトと継続的モニタリング

Decision Modelの精度は、入力データの分布がトレーニング時の分布から乖離すると急落する。例えば、ルーティングモデルが「技術サポート」「請求」「問い合わせ」の3分類で学習されていた場合、新しい製品ラインの登場により入力パターンが変化すると、既存の分類境界が機能しなくなる。

対策としては、決定の正解率（Ground Truthとの一致率）を継続的にモニタリングし、閾値を下回った時点で再学習またはプロンプト更新のトリガーを発生させる仕組みを構築する。また、入力分布の変化を検知するための統計的検定（例：特徴量分布のKLダイバージェンス）を定期実行し、精度の劣化が顕在化する前に異常を検知する。このモニタリング体制なしにDecision Modelをプロダクションに置くことは、システム全体の信頼性を賭けた設計判断になる。

厳格な構造化と柔軟性のバランス

出力スキーマを厳格に定義しすぎると、モデルが予期せぬエッジケースに対応する余地を失う。例えば、ルーティングのEnumに「unknown」を含めずに設計した場合、既存の分類に該当しない入力に対して、モデルが最も近いカテゴリを無理やり選択する可能性が高い。この「無理やりな分類」は、明示的な「判定不能」よりもはるかに危険である。

スキーマ設計では、必ずフォールバック用の値（unknown、escalate_to_humanなど）を含め、モデルが「判断できない」と明示的に示せる経路を確保する。この「判断不能の宣言」を許可する設計は、一見するとシステムを不安定に見せるが、実際には誤判定による静かな失敗を防ぐ最も効果的な手段である。

運用と発展：モデルの監視と継続的改善

監視メトリクスの設計

Decision Modelをプロダクションで運用する際、汎用LLMとは異なる監視指標が必要になる。まず基本となるのは、呼び出し頻度、P99レイテンシ、そして決定の正解率（Ground Truthとの一致率）の3つである。汎用LLMでは「出力の質」を主観的に評価するケースが多いが、Decision Modelの出力はEnumやBooleanなど離散的な値であるため、正解率を数値として定量化できる。これが可能になることで、SLO（Service Level Objective）の定義とアラート設定が明確になる。

具体的には、正解率が一定期間にわたって閾値を下回った場合にアラートが発火し、分布シフトの兆候を早期に検知する仕組みを構築する。ここでいう「正解」の判定は、人手でのラベリングではなく、後続のアクションが正常に完了したかどうかという業務結果をプロキシとして用いるのが実務的である。例えば、ルーティングの決定が「正しい」かどうかは、送信先サブエージェントがタスクを正常に処理できたかどうかで判断できる。

フィードバックループとバージョン管理

誤判定が発生したケースを収集し、トレーニングデータやプロンプトに反映させるフィードバックループを構築する。このプロセスは、汎用LLMのプロンプト改善とは異なる点がある。Decision Modelの出力空間が離散的であるため、誤判定の「パターン」が明確に集約されやすい。例えば、特定の入力形式に対して一貫して誤ったカテゴリを返す場合、その入力形式の訓練データが不足している可能性が高いと推定できる。

モデルのバージョン管理については、A/Bテストの設計が鍵となる。新しいDecision Model（Microsoft-Decision-1の導入など）を切り替える際、トラフィックの一定割合を新旧モデルに振り分け、正解率とレイテンシの両方を並行して計測する。このとき、新旧モデルで「判断が分かれた」ケースに注目すると、どちらのモデルがより正確であるかを効率的に比較できる。判断が一致したケースは差分がゼロであり、判断が分かれたケースのみが評価の焦点になる。

動的ルーティングによるコスト最適化

コスト最適化の観点では、タスクの複雑さに応じて軽量なDecision Modelと重厚なLLMを使い分ける動的ルーティングを検討する。例えば、入力に対してDecision Modelのconfidenceが閾値を超えた場合のみDecision Modelの決定をそのまま採用し、confidenceが閾値を下回った場合のみ汎用LLMにエスカレーションする、という二段階構造である。この設計により、大部分のトラフィック（confidenceが十分に高いケース）を低コスト・低レイテンシのDecision Modelで処理し、困難なケースのみLLMに委ねることで、全体のコストとレイテンシを最適化できる。

この二段階構造の閾値設定は、コストと正解率のトレードオフを直接制御するパラメータとなる。閾値を高くするとLLMへのエスカレーションが増えコストは上がるが正解率は向上し、逆に低くするとコストは下がるが誤判定のリスクが上がる。この閾値は静的に設定するのではなく、前述の監視メトリクス（正解率、コスト）を基に動的に調整する仕組みが望ましい。

まとめ：堅牢なAIシステムのための決定モデルの活用

本記事では、LLMの確率的出力を「決定」という設計パターンで制御し、エージェントアーキテクチャにおける堅牢性と低遅延を両立させる方法を解説した。Decision Modelは、Microsoft-Decision-1に代表されるように、構造化出力と高速推論に特化したモデルであり、ルーティングや分類といった決定タスクにおいて、汎用LLMの代替として機能しうる。

設計上の核心は、LLMとDecision Modelの役割分担を明確にすることである。LLMは文脈理解や創造的な推論、長文生成といった「深い処理」に集中し、Decision Modelは分岐点の制御やリソース配分といった「速い判断」を担う。この分離により、決定ロジックの更新がモデルの再学習やプロンプト変更という局所的な操作に収まり、システム全体の保守性が向上する。

ただし、導入にあたってはベンチマーク結果の数字だけに依拠しない設計判断が求められる。ベンチマークは理想条件で測定されたものであり、実環境での入力分布がトレーニングデータと乖離した場合、正解率は急落する。前述の監視メトリクスとフィードバックループ、そしてconfidenceに基づく動的ルーティングを組み合わせることで、分布シフトへの耐性を備えた運用体制を構築できる。Decision Modelは万能の解決策ではないが、構造化された意思決定タスクにおいて、確率を決定に変換する最も実用的な設計パターンである。

参考

本記事は海外の技術トレンド「Microsoft-Decision-1, our model for fast decision-making」（Hacker News）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。