決定LLM：モデルが判断すべきとき、すべきでないとき

エージェントのシステムで何が壊れるのかと実践者に聞けば、答えはほとんど時に能力ではありません。より静かな失敗です：モデルが判断し、誰も妥当なものと流暢なものの区別がつかない、ということです。

モデルの出力はサンプルです。判断には、サンプルにはない性質があります — 固定された入力に対する決定性、満たすべき不変条件、そしてなぜこの選択肢で他の選択肢ではなかったのかを示す監査記録です。それらの性質が欠如している場合、「判断」とは、判断の服をまとった高確信度の推測にすぎません。

この記事では、そのギャップに機械的な処理を与えます：5つの判断役割の分類、各判断を最も小さい有能なモデルにルーティングするルール、そして「エージェントがXを判断した」を、後から妥当であることが証明できるものに変換する検証機構です。この記事の最後では、ご自身のシステムのあらゆるアクションに対して実行できるルーブリックを提示します。

「ローカルエージェントにおいて、私が繰り返し直面するギャップは能力ではなく、検証です。エージェントはファイルを読んだ、ツールを呼び出した、判断した、と言いますが…」 — r/LocalLLaMA, “Best Local Agents — Jun 2026”（2026年6月の最良のローカルエージェント）

「LLMエージェントが失敗すると、それはブラックボックスになり、なぜ失敗したのか誰も知りません。普及の本当のボトルネックは、モデルの精度を92%から96%に上げることではなく、[なぜXを判断したのかを知ることです]」。 — r/AI_Agents, “The gap between decision and execution”（判断と実行の間のギャップ）

コミュニティでは、3つの直感的な認識に収斂しています：最終判断をモデルに任せない、判断を最も小さい有能なモデルにルーティングする、判断を説明可能にする。しかし、これら3つを同時に実行可能な形にするフレームワークが欠けていました。

「答えはするが、判断はするのか？」

モデルの出力は、1つのシーケンスに収束したトークン分布であり、同じプロンプトを2回実行しても、まさに重要なトークンで分岐する2つのシーケンスが生成されることがあります。一方、判断は固定された入力に対して決定論的であり、明示的な不変条件を満たし、どの分岐が選択され、なぜそうだったかを記録する監査記録を残します。

モデルが周囲に機械的な機構を持たずに「判断」した場合、それらの性質はどれ一つとして存在しません。出力が遵守義務を負う不変条件はなく、選択された分岐のログはなく、判断を再生してそれが保持されていたかを確認する手段もありません。このギャップは知能の問題ではありません — 確率的な出力が、決定論的な出力のために設計されたスロットに配置されたことの問題です。

実践者の直感は、モデルを判断から完全に排除することです：

「このシステムでは、LLMは最終判断を下すことはない。その役割は純粋に：ロジックの精錬、ストレステスティング、シナリオ生成、説明である。」 — r/AI_Agents, “Using an LLM as a ‘reasoning agent’ for validating price…"（価格検証のための「推論エージェント」としてのLLM使用…）

これは、原理として述べられた正しい姿勢です。それを適用するには、与えられたアクションにおいてモデルがどの役割を負うべきかを分類する手段が必要です — 以下の分類がそれを提供します。

5つの判断役割

システムが行うあらゆる判断は、5つの役割のいずれかに割り当てられます。役割は、モデルの出力をどれほど信頼できるか、どのように監査されるか、どのように失敗するか、そして人間がループにいるべきかを決めします。

この表は、メニューではなく、制約として読み取ってください。多くの壊れたシステムに共通する1つの欠陥があります：単一のモデルが同時に5つの役割すべてを担っているため、決定性を要求する役割（Decider）が、流暢さのために最適化されたコンポーネント（Generator）によってサービスされているのです。モデルがGeneratorとして機能する場合、判断の機構は必要とされず、内容レビューが必要です。避けるべき失敗は、これらを混同することです：「エージェントは環境を削除することを決定した」というのは、通常は判断の質の問題ではなく、承認ゲートの欠如です。

判断を最も小さい有能なモデルにルーティングする

役割が決まったら、ルーティングの質問は、どのモデル階層がそれをサービスするかです。実践者は、その収益を直接的に報告しています：

「モデルルーティング：分類/ルーティング判断にはHaiku、実行にはSonnet、設計/計画にはOpusのみ。Opusをすべてに使うのをやめたことで、コストは約60%低下した。」 — r/AI_Agents, “What is your full AI Agent stack in 2026”（あなたの2026年の完全なAIエージェントスタックは？）

その数値は、モデル選択をシステム単位の判断ではなく、役割単位の判断として扱うことから生まれます。ルーティング呼び出し — 「これはメールのトリアージか、返金承認か？」 — は分類であり、分類にはフロンティアモデルは必要ありません；必要なのは、小さい、速い、低温度のモデルです、なぜならそれは何千回も実行されるからです。階層の機構 — 能力ベース、コスト認識、レイテンシ認識の選択、そしてフォールバックチェーン — はモデルルーティング：すべてのために1つのモデルを使うのをやめるでカバーされており、複数モデルの周りのオーケストレーションパターンはマルチモデルシステム設計にあります。

判断のフレームワークが寄与する追加は確信度ベースのエスカレーションであり、「最も小さい有能なモデル」を推定ではなく測定可能にします。最も小さい階層から開始します。モデルがキャリブルされた確信度 — または構造化された自己評価 — を出力し、それが閾値を超えた場合、停止します。そうでない場合、1階層エスカレーションし、エスカレーションを記録します。こうして、有能さはモデルごとに推定される性質ではなく、呼び出しごとに検証される性質になります。

階層に関わらず、1つの制約は絶対のままです：Router役割そのものは、自由な言語モデルの呼び出しであってはなりません。決定論的な脊柱 — タスクの種類、ペイロードサイズ、コスト予算に関するルール — が分岐を選択し、モデルはその内部のリーフの判断のみを埋めます。脊柱は監査可能かつユニットテスト可能であり、モデルは実際に得意なことに制限されます。

判断を検証可能にする

ここが、「エージェントはXを行ったと言っている」ギャップが閉じる場所です。修正は、判断をチャットターンの副作用ではなく、一次の構造化されたアーティファクトにすることです：

1. 構造化された判断ストア。 モデルが下すことが許可されたすべての判断は、ログ行ではなく、テーブルに書き込まれます：入力、役割、モデルと階層、確信度、考慮された代替案、タイムスタンプ。判断は後からSELECTできるものです。会話トランスクリプトにのみ存在する場合、それは推測です。
2. 実行ログとは分離された判断ログ。 実行ログは何が起こったかを示し、判断ログは何が判断され、その根拠は何だったかを示します。この分離が重要なのは、失敗は通常実行ではなく判断にあるためです — エージェントは削除を完璧に実行しました；バグは削除を判断したことでした。構造化された、追記専用のログの機構は、実践におけるLLMガードレールでコンプライアンス監査記録に使用されるものと同じです。
3. 不変条件とアサーション。 DeciderとEvaluatorの役割では、判断はモデルがそれを出力した後に、決定論的なコードによってチェックされる不変条件を満たさなければなりません。価格Recommenderは何でも出力できますが、「推奨価格は[floor, ceiling]内である必要がある」という不変条件はコードによって強制されます。モデルは提案し、不変条件が処分します。
4. 不可逆性の境界での人間承認ゲート。 ゲートは、アクションのブラスト-radius（影響範囲）の性質であり、モデルの確信度のものではない。閾値以下の返金は自動承認可能ですが、それを超えるものはそうではありません。99%の確信度を持つモデルでも、監査記録のない不可逆的なアクションを承認することはできません。

貫いている線：92%→96%の精度向上はボトルネックではありません — 説明可能性こそがそうです。すべての判断がログに記録され、不変条件でチェックされ、境界でゲートされている92%のシステムは安全にリリースできます。なぜなら、誤った判断の8%は、損害を与える前に発見可能だからです。ブラックボックスの判断プロセスを持つ99%のシステムはそうではありません。なぜなら、1%は法医学的な記録のない生きたインシデントだからです。ゲート自体がアシスタント内にどこにあるのか — どのコンポーネントが承認権限を持ち、リクエストがそこへどのように到達するのか — はAIアシスタントアーキテクチャ：LLM、メモリ、ツール、ルーティング、可観測性に示されています。

ワークドエグゼンプル

3つのシステム、それぞれ1つの役割割り当て。

価格検証 — モデルは推奨者であり、決して決定者ではない。 エージェントはサプライヤーの価格変更をレビューし、ランキングされたリストを生成します：受入れる、Xで交渉する、拒否する。最終判断は、決定論的なルールによって満たされるDeciderスロットです：コストフロア以下なら自動受入れ、天井以上なら人間へルーティング、その間なら「交渉価格は最後に受入れられた価格をY%上回る必要がある」という不変条件を適用します。モデルは自分の推奨を承認することはなく、推奨は判断ストアにルーブリックのトレースとともに格納され、誤りがあれば調査可能です。

エージェントタスクルーティング — 脊柱が決定者であり、モデルはリーフにある。 受信リクエスト（メール、チケット、コマンド）は、ペイロードの形状と意図カテゴリーによってパスに割り当てられます — 決定論的であり、ユニットテスト可能。小さいモデルは、その分岐内のリーフの判断のみを埋めます。誤ルーティングはブラスト-radiusイベントであり、まさにそれだからこそ、分岐の選択は決定論的でなければなりません。

LLM-as-judge — モデルは評価者であり、ルーブリックは制約。 1つのモデルが、バージョン管理されたルーブリックに対してもう1つのモデルの出力を採点し、スコアとルーブリックのトレースが保存されます、数値だけではではありません。既知の失敗モードは自己選好バイアス — モデルが自分の生成スタイルを高く採点すること — であり、緩和は構造的なものです：ルーブリックをバージョン管理し、モデルがそれが形成した基準に対して静かに採点することを防ぐためです。

正直な境界

LLMが下してはならない決定のクラスがあり、それはスケールの問題ではありません：行動が不可逆的、高リスク、フォールバックなしである場合 — データ削除、資金移動、外部コミットメント。ロールバックできないアクションでは検証は不可能であり、それだからこそ「自律エージェント」はモデルの質に関係なく同じ壁にぶつかり続けるのです。

芝居ではない人間-イン-ザ-ループは、まさにその境界に、そしてそこだけに位置します。人間がすべての低リスクの判断をレビューすることは、摩擦を追加し、安全性は追加しません；人間がすべての高リスクの判断から不在であることは、そのインシデントそのものです。同じ原理は、エージェントメモリにおいてより狭い形で現れます：自己強化メモリループは、永続状態に到達する前に、明示的な人間の承認の背後で候補メモリの書き込みをゲートします — 書き込みが壊せるものに合わせてゲートサイズが決められる。マルチエージェントシステムでは、対応する質問は誰が誰の名前で行動し得るかであり、そのためのアイデンティティ、委任、監査記録の機構はA2AとMCPエージェントセキュリティにあります。

判断ルーブリック

ご自身のシステムのあらゆるアクションに対してこれを実行してください：

1. 役割を分類する。 Decider、Recommender、Evaluator、Generator、Routerのいずれか？名前のない役割はバグです — Generatorの確信度をまとったDeciderスロットにいるモデル。
2. その役割のための階層を選ぶ。 確信度ベースのエスカレーションで、有能さを呼び出しごとに測定しながら、最も小さい有能な階層。
3. 検証を定義する。 どの不変条件が保持されなければならないか？判断ストアには何が入るか？監査トレースは何か？検証パスのない役割は、デフォルトでDeciderです。
4. ブラスト-radiusから、確信度ではなく、人間ゲートを設定する。 不可逆的または高リスク → ゲートあり。それ以外 → 自動、ただし判断は発見可能ようにログに記録される。

同じ規律は、ランタイムアクションではなくエンジニアリング選択に適用されると、判断記録がすることと同じです — AI駆動開発のための判断記録は、選択がなされた理由を記録し、後からレビューできるようにします；上記のルーブリックは、実行中のシステムが行う判断に対して同じことをします。

次に来るもの：決定者としてプロダクト

フレームワークは、それ自体の商品化を予測します：「判断を最も小さい有能なモデルにルーティングする」がパターンになったとき、次のステップは、判断することだけをやるモデルクラスでした。そのステップはすでに実装されました。

2026年10月まで、複数のベンダーが共有レシピで構築されたモデルをリリースしました — 凍結されたQwenバックボーン、ランク256のLoRAアダプタ、そして共同スキーマヘッド — それは1回のフォワードパスで型付けされた判断を出力します：列挙されたセットからの選択、はい/いいえ、またはスコア、キャリブルされた確率付きで、フリーフォームなテキストなし。待たなければならない思考の連鎖はありません、なぜなら生成はないからです。ベンダー報告のレイテンシはクラスの間に約8msから210msの間 — 最小のバリアント（d1-3B、約8 ms）から最大のもの（d3、約209 ms）まで — と、フットプリントは小さなGPUの領域です：d1-3Bは約1.67 GB、d3-flashはQ4_K_Mで約6.6 GB。サポートも速く動きました：llama.cppは、リリースから約2週間以内にこれらのモデルのいくつかのネイティブアーキテクチャサポートをマージしました。

上記のフレームワークに対する2つの結果。第一に、ルーティングルールは以前にはなかったハードウェア表現を得ます：Decider役割は、一般的なモデルのプロンプトモードではなく、専用の小さいモデルによってサービスされ得るため、最も小さい有能な階層の判断が部分的に自動になります — あなたの判断タイプのために階層が存在するかどうか、です。第二に、検証について何も変わりません。8msでの型付けされた判断は、依然として判断ストア、不変条件、そして不可逆性の境界でのゲートが必要です；モデルクラスが除去するのは、生成コストと非決定性であり、監査の負担ではありません。より速い判断は、監査すべき判断記録の数を増幅します — ボトルネックはモデルの速さではなく、モデルの知能でもありません。

監視すべき他の方向は、より静かです。小さいモデルのためのツール呼び出しの信頼性は飽和に近づいています — ツール使用におけるポストトレーニングはスタックの中で最も安価で高影響のステップであり、それは注目を上記の行に移します。信頼できる計画の地平は拡張し続け、それによりDecider役割がより長いタスクに到達可能になり、地平とともに検証の負担が増えます。両方は同じ結論に給水します：エージェントシステムにおける希少資源は、後から妥当であることが証明できる判断であり、それ以外はそれに追いついているのです。