ScaleDown Classify 対 Microsoft-Decision-1：一方は数値を公表し、他方は手法を公表する

ScaleDown ClassifyとMicrosoft-Decision-1は、この比較における2つのクローズドなホスト型選択肢です。どちらも重みを配布せず、どちらもダウンロードするものではなく、両方とも同じ前提に基づいて構築されています。つまり、ある決定——どのカテゴリか、どの選択肢か、これらのうちどれか——は、生成ループによってテキストとして書き出されるのではなく、モデルの確率から読み取られるべきだという前提です。Microsoft-Decision-1は、マイクロソフトが事後学習した90億パラメータの密なデコーダとして、2026年10月8日からMicrosoft Foundryで一般提供されており、25言語に対応し、32,768トークンのコンテキストを持ちます。ScaleDown Classifyは、100万入力トークンあたり0.05ドル、100万出力トークンあたり0ドルで提供されるホスト型ルーブリックエンジンで、100万トークンの入力上限と20ラベルの上限があります。両者を分けるものは能力ではありません。それぞれの企業が自社モデルについて何を公表しようとしているかであり、両社は正反対の半分を選んでいます。

開示の反転

Microsoft-Decision-1のFoundryドキュメントは、その評価について異例なほど詳細に説明している。公開およびコミュニティの意思決定ベンチマークに加え、ホールドアウトされた社内セット。精度やキャリブレーション誤差を含む指標。選択肢の順序を変化させる。対応のある統計検定。比較対象となるすべてのモデルに同一のハーネス。そして、そのモデルは「最先端の意思決定モデルと同等の性能を発揮し、同じ方法論で評価された他のオープンな意思決定モデルを上回る」と報告しながら、数値を一切示していない。精度の数値も、キャリブレーション誤差も、ベンチマーク別の表もない。

Microsoftが実際に公開しているのは制限事項リストであり、それは優れたものだ。スコアは言い回しや選択肢の順序によって変動する。不適切に作られた質問でも、依然としてスコアは返される。キャリブレーションは、よく知られたタスク種別で最も強い。説明は一切生成されない。このモデルで挙げられている強みは、推論、ルールの適用、プロンプトの書式に対する堅牢性であり、挙げられている弱みは、専門領域の知識と非英語での性能である。

ScaleDown Classify はそのポリシーの裏返しを実行する。そのドキュメントは、リクエストの書き方について運用上の詳細に踏み込んでいる——ルーブリックは分類リクエストの最も重要な部分だと説明され、直接的なはい/いいえの質問として表現され、否定を避け、確率質量が予測不能に分割されないよう重複しないように保たれる——そしてベンダーのマーケティングは精度とコストに関する主張を伴っており、約5億パラメータのモデルが単純な分類タスクで91.7%に達し、720億パラメータのモデルでは88.6%だったことなどが含まれる。これらのいずれも、記述された方法論に紐づけられてはいない。また ScaleDown Classify は、いかなる公開ハーネス上でも公表された期待キャリブレーション誤差を持っていない。

つまり、選択肢は、どのように測定したかは教えても、何がわかったかは教えないベンダーか、何がわかったかは教えても、どのように測定したかは教えないベンダーのどちらかです。どちらも完全な情報開示ではなく、どちらもそう扱うべきではありません。

言語: 一方は件数を公開し、もう一方は何も公開しない

Microsoft-Decision-1 は 25 のサポート言語を列挙し、カバレッジ、品質、キャリブレーションは「言語によって異なる場合がある」と率直に述べ、非英語、特に低リソース言語を性能不足の領域として名指ししている。これは使える開示だ。モデルが多言語対応であること、おおよそどの程度多言語対応なのか、そしてどこを信用すべきでないかを教えてくれる。

ScaleDownのClassifyのドキュメントは言語リストを公開していません。APIリファレンスには、ルーブリックスコアリングがどの言語を扱うのか、非英語でのルーブリックの言い回しが同じように動作するのかについて何も記載されていません。さらに、ルーブリックのガイダンス——直接的なはい/いいえの質問として表現し、否定を避ける——は、英語話者の呼び出し元が英語でルーブリックを書くことを暗黙のうちに前提とした書き方になっています。実際には国際的なサポートチケットを対象にすることになる分類器にとって、それは導入を決める前に埋めるべきギャップであり、あなた自身の評価でしか埋められないギャップです。

ドキュメント化された言語フットプリントが必要なら、この比較はここで終わり、Microsoft が既定で勝利します。英語のみを対象とするなら、その数は考慮要素にならず、残りの判断は入力長としきい値次第です。

コンテキスト: 100万に対して32,768トークン

Microsoft は、最大 32,768 トークンにまたがる単一の呼び出しについて記載しています。ScaleDown は 100 万トークンの入力上限を記載しており、チャンクが単独で送信される場合でも 50 チャンクのバッチの一部として送信される場合でも、チャンクごとのキャリブレーションは同一であり、共有プロファイルはリクエストごとに 1 回だけ課金されると述べています。生の数値で見ると、それは 30 倍の差であり、両製品間の最大の単一の隔たりです。

それがもたらすのはスループットではない — チャンキング層が必要かどうかだ。サポートスレッド、履歴付きのチケット、短い検索済みパッセージ：それらはすべて、質問スキーマの余地を残して32kに収まり、そのサイズでは2つのモデルはほぼ同等だ。完全な契約書、複数ページのポリシー文書、長い検索コンテキスト、スキャンしたフォーム：それらはどれも32kに収まらず、Classifyのドキュメントパス — base64のJPEG、PNG、TIFF、PDF、単一または複数ページ、抽出テキストはocr_textフィールドで返される — を使えば、文書を前処理済みテキストとしてではなくバイト列として投入できる。

どちらの数値もベンダー自身が示したものである。ScaleDown の100万トークンという主張は独立して裏付けられておらず、またこのモデルに関する第三者によるカタログ掲載では、その数字をそのまま反映するのではなく、コンテキスト長は「該当なし」と表示されている。これは矛盾ではなく、カタログ上の制約である。

説明：一方は拒否し、もう一方は倍額を請求する

Microsoft-Decision-1 は説明を生成せず、モデルページではそれを設計上の選択ではなく制限として挙げています。ScaleDown Classify はトップラベルの1文の説明を返しますが、ドキュメントはその文が何であるかに注意を払っています。それはトップラベルが確定した後に生成されるため、決定を後から疑うのではなく説明するものであり、自由形式で、ラベルとルーブリックを2倍の課金対象入力トークンで再送信します。これは単一のテキストまたはドキュメント入力を持つ単一ラベルリクエストでのみ利用可能であり、マルチラベルおよびバッチリクエストでは決して返されません。

人間によるレビュー待ち行列では、その一文が、レビュアーが分類を承認するか、やり直すかをしばしば分ける。そのため、人間に到達するトラフィックの一部については、2倍の追加料金を正当化するのは容易だ。自動化パイプラインにとっては、それは請求上の無駄な負担であり、オフにすべきだ。

両方とも閉じているので、テストできる内容が変わります。

• 重み — どちらも提供していません;ScaleDownは要望に応じてエンタープライズ向けのセルフホスティングとライセンスを提供していますが、Microsoftのページにはファインチューニングの方法が一切記載されていません

• オプションの上限 — ScaleDownは1リクエストあたり20ラベル、マルチラベルモードでは16ラベルで、それぞれ独立してスコアリングされる。Microsoft-Decision-1のオプションセットの上限はモデルページに記載されていない

• バッチ推論 — ScaleDownは、共有ラベルプロファイルに対してリクエストあたり最大50チャンクを文書化しています。Microsoftのページではバッチ推論が無効として記載されています

• 課金に関する開示 — Classifyの料金は、入力トークン100万あたり$0.05、出力トークン100万あたり$0として明記されていますが、Foundryのトークン単位の料金はモデルページに明記されていません

• 料金体系 — マルチラベルモードでは、Classify はラベル数に応じて倍増し、reasoning を有効にすると2倍になります。Foundry の料金はトークン単位で、公表されているラベル倍率はありません

• 空の回答 — 何も当てはまらない場合でも Classify は勝者を返すため、しきい値を設定するのはあなた自身です。Microsoft が示している動作では、筋の通らない質問でもスコアが返されます

両方がクローズドであることの結果は、どちらの場合でも同じだ。成果物を検査できないため、唯一の検証手段は振る舞いによるものになる。そのため、自分でラベル付けしたデータのホールドアウトセットは必須となり、プロバイダーを切り替えるコストは、コードの変更ではなく、その評価の再実行となる。

OrcaRouter が、どちらかの上に構築されたパイプラインのどこに位置するか

これらのモデルはどちらも当社のカタログにはありません。また、ここに書かれていることは可用性の主張ではありません。どちらも chat-completions の対象ではなく、構造化されたスコアリングエンドポイントであり、どちらにもルーティングレイヤーは必要ありません。当社が提供するのは、それらの上位層です。つまり、1つの OpenAI 互換キーの背後にある、分類器が評価するドラフトを生成する200以上の生成モデルを、プロバイダーの定価のまま、0%のマークアップで提供する層です。複数のモデルを1回の呼び出しにまとめるためのルーティングDSLと、サービングパスが劣化したときの自動フェイルオーバーを備えています。判断モデルが、生成レイヤーが出荷できる内容をゲートするなら、稼働率リスクがあるのは生成レイヤーであり、1つのキーで統合できるのはその半分です。

どちらを選ぶべきですか

文書化された言語フットプリントが必要な場合、すでに Azure の内側にいる場合、あるいは大規模ベンダーのコンプライアンス姿勢が、公表された精度の数値よりも調達において重要である場合は、Microsoft-Decision-1 を選んでください。Microsoft はそれ以外に何も提供しないことを選択しているため、完全に自社のデータだけで評価することになると受け入れてください。

ScaleDown Classify を選ぶのは、入力が 32k トークンを超える場合、抽出ステップを分類呼び出しに折り込みたい場合、または何も再学習せずに書き換えられるラベルごとのルーブリックが欲しい場合です。精度に関する主張はベンダー自身によるもので再現されておらず、キャリブレーション数値は公開されておらず、自分で信頼度しきい値と catch-all ラベルを書くことになる、という点を受け入れてください。

これを決めるはずの測定——両モデルを同一の入力、同じ選択肢の順序、同じ閾値スイープで、利害関係のない人物が実行する——は、どちらのベンダーからも公表されていない。どちらかがそれを実行するまで、率直な解釈は、Microsoft がより安全な既定であり、ScaleDown がより高性能な計器だというものになる。

このような比較は、失敗モードが表面化する場でもあります。このクラスのモデルの背後にある、記録されたAIインシデントやエージェント障害は、OrcaRouter AIインシデントアーカイブ に集められており、各エントリーには独自の情報源、重大度、信頼度グレード、異議ありフラグが付されています。