Drex Max、意思決定モデルに注目——クリック単価を0.06ドルに設定

コンピューター操作エージェントは、実際には単一の判断ではありません。飛行機の予約は30回の判断の連続です。どのフィールドをクリックするか、どの検索結果を開くか、カレンダーウィジェットのレンダリングが終わったか、見ている運賃が目的のものか。その一つひとつがスクリーンショットの往復であり、相手側のモデルがフロンティアのチャットモデルなら、各回に数秒とフロンティアモデル分の料金がかかります。Drex Maxは、Nace.AIが2026年10月19日に一般提供としてリリースしたもので、この計算を圧縮しようとする試みです。これはチャットモデルではなく判断モデルであり、画面と型付きの選択肢群を渡すと、1回のフォワードパスで各選択肢の確率を返します。Naceによる価格は入力100万トークンあたり0.06ドル、レイテンシ中央値183ms、出力料金は一切なしです。なぜなら何も書き出さないからです。このようなリリースの背景にある、文書化されたAI障害やエージェントインシデントは、OrcaRouter AI Incident Archiveに収集されており、各項目には独自の情報源、重大度、信頼度グレード、係争中フラグが付いています。

ネイスがそこに並べて示す比較対象はTypeSafe J​ev 1.14、つまりこのカテゴリーのリクエスト形状を定義した決定モデルと、今日エージェントが使っている汎用フロンティアモデルだ。ネイス自身が公開した表では、Claude Opus 5.5 が1000判断あたり10.17ドル、1判断あたり約3.5秒であるのに対し、同じ243件のスクリーンショット質問で Drex Max は0.06ドル、174ミリ秒となる。ベンダーによる数値で、自社実施、ネイス外部の誰による監査も受けていない——だが要点は桁の違いにあり、だからこそこのリリースはベンチマークの1行以上に重要なのだ。

実際に出荷されたもの

Drex Maxは、視覚エンコーダーを搭載したDrexシリーズ初のモデルです。Drex 2.0とDrex 1.5はテキスト入力・確率出力でしたが、Maxはスクリーンショット、スクリーンキャスト、スキャンした文書、グラフ、写真、動画フレームを読み取り、従来モデルと同じ3種類の質問に回答します。

• モデルID — drex-max、固定。オープンウェイトはなく、Nace 独自の API 経由でホストされており、ダウンロード可能なチェックポイントはありません。

• 入力形式 — state 文字列と questions オブジェクト、およびリクエストあたり最大8枚の画像を含む images 配列です。エンドポイントは POST /v1/systemone で、J​ev が使用するのと同じパスです。

• 質問の種類 — choice（名前付きオプション、オプションごとに確率を返す）、noul（はい/いいえの質問、P(true) を返す）、score（順序付きレベル、期待レベルと分布を返す）。1つの状態に関する複数の質問は、1回のパスを共有します。

• コンテキスト — APIガイドによると、画像トークンを含めて1質問あたり131,072トークンです。ローンチ投稿では別途「262Kトークンのコンテキストウィンドウ」と述べています。この2つの数値は一致しておらず、スクリーンショットバッファのサイズを決める前に解決すべき最初の事項です。

• 料金 — 入力トークン100万個あたり0.06ドル。出力は課金されません。Naceは同じ数値を「1000件の判断あたり0.06ドル」と述べており、これは1回の呼び出しあたりおよそ1000トークンであることを示唆しています。

• 前世代モデル — Drex 2.0(総パラメータ35B、アクティブ約3B、Qwen3.6-35B-A3Bをベースに構築、オープンウェイト)は1,000判断あたり$0.06、Drex 1.5(9B、テキストのみ)は$0.04です。

• デプロイメント — NaceのGPU上でのマネージド、専用、顧客のAWSまたはAzureアカウント内、あるいはエアギャップ環境で、いずれも同じリクエスト契約。重みがないことはセルフホスティングがないことを意味しますが、SaaS専用という意味ではありません。

インターフェースに奇抜なところは何もない。それは意図的だ。NaceはDrex MaxをTypeSafeのJ​ev SDKとワイヤ互換になるよう作ったので、@typesafe-ai/sdkはベースURL、キー、デフォルトモデルを変えるだけで動き続ける。この互換性は競合他社への好意ではない。新規参入者が試される方法であり、最も安価な移行とは設定値ひとつで済む移行のことだ。

本当に異なっている部分：文ではなく分布であること

チャットモデルは、書くことによって答えにたどり着く形で、コンピューター操作に関する質問に答える。「ページを見ると、検索結果は読み込まれているように見えるので、次の操作は2番目の結果をクリックすることです」——そしてハーネスはその文やJSONの塊を解析し、モデルがこちらが提示していない選択肢を選ばなかったことを願う。その設計のコストは二重に払うことになる。1つは出力トークンとして、もう1つは、モデルが画面に存在しないボタンを幻覚し得るために保守しなければならないパーサーとして。

{{1}}Drex Max{{/1}}はそれはできません。提供された選択肢に対する確率を返すだけで、それ以外は何も返しません。クリック可能な候補を5つ提示すれば、{{3}}合計が1になる5つの数値{{/3}}が返ります。それは{{4}}より狭い能力であり、ループにはるかに適しています{{/4}}。その理由は3つあり、{{5}}デモよりも本番環境でより重要になります{{/5}}。

最初はしきい値処理です。確率分布があれば、実際に望むルールを書けます。最上位の選択肢が0.9を上回ったら実行し、そうでなければより遅いモデルや人間にエスカレーションする、といった具合です。生成モデルは文章と、まったく別の意味を持つ信頼度フィールドを返します——通常それはトークン分布がどれだけ尖っていたかを示すものであり、答えが正しい確率ではありません。

2つ目は失敗時の挙動です。宣言済みの選択肢でしか答えられないエージェントは、6つ目のボタンを発明することはできません。間違うことはあり得ますし、キャリブレーションがひどくずれることもありますが、あなたのハーネスが実行方法を知らないアクションを生み出すことはできません。

第三は経済性だ。出力トークンが不要なので、10個の選択肢を採点するコストは2個を採点する場合と同じだ。Naceの見立てでは、これにより毎ステップ呼び出しても十分安くなり、1000回あたり0.06ドルという計算も成り立つ。雑な30ステップのタスクでも、意思決定にかかるコストは0.2セント未満だ。同じタスクをOpus 5.5で行うと、Naceの意思決定あたりの数字では約30セントになる——致命的ではないが、それが行っていることの30倍の価格だ。

ベンチマーク表と、これらの数字が誰のものなのか

以下の数値はすべてNaceのローンチ投稿によるものです。Decision Index 0.3.2は意思決定型ベンチマークの公開リーダーボードですが、そこでのDrex Maxの実行はNace自身によるもので、公式キットを使用しており、Nace以外でこれを再現した人はいません。ボードの「Full」スコアは、この実行には含まれない非公開テストも混ぜ合わせています。結果の形は参考情報として、小数点以下はマーケティングとして扱ってください。

見出しとなる公開Decision Indexは67.6で、Drex 2.0の61.3、Drex 1.5の58.1、J​ev 1.14の60.7、GPT-6 Luna Decisionsの47.8との対比になっています。付随するVision Index——視覚を売りにするモデルにとって重要な数値——では、Drex Maxが74.5を記録し、Lunaの63.9と対比されています。

• Mind2Web — 88.6 対 GPT-6 Luna Decisions の 81.2、ブラウザエージェントにとって最も直接的に関連する行です。

• OSWorld-Verified — 0.780（GPT-6 Sol は 0.756、Claude Opus 5.5 は 0.790）。Drex Max は前者を上回り、後者には僅差で敗れる。

• OSWorld-V2 — 0.737 に対し Sol は 0.744、Opus 5.5 は 0.761。同じ傾向で、差はやや広がっています。

• BFCLツール呼び出し — 98.2で、J​ev 1.14の96.4とClaude Opus 5.5の97.3を上回り、GPT-6 Solだけに及ばない。

• DecideBench — 項目で98.5、ペアで97.0、いずれもJ​ev 1.14を上回っています。

• ビジネス意思決定 vs J​ev 1.14 — FinEntity 92.3 vs 81.9、BANKING77 90.0 vs 79.7、ContractNLI 75.9 vs 57.7。

OSWorldの行には、Naceの表が明示していない注意書きが必要だ。これらのスコアは完全な自動化スタックを表しており、Drex Maxを囲むループのうちどれだけがNace自身のハーネスでもあったかは文書化されていない。次の行動をうまく選ぶ意思決定モデルでも、スクリーンショットを撮り、レンダリングを待ち、タスクが完了した時点を判断する何かに依存する。0.780は、意思決定がボトルネックではない証拠として読むべきであり、あなたのエージェントに関する約束として読むべきではない。

それが劣る場面、つまり表のより有用な半分

損失は埋もれてはいないが、流し読みで見過ごしやすく、そのうち二つは丸め誤差ではなく実際の限界を示している。

一般的な知識と高度な推論では、意思決定モデルはフロンティアのチャットモデルとまったく競争にならず、Drex Max もそれを変えない。MMLU-Pro は 72.5 で、J​ev 1.14 の 82.1、Sol の 93.0、Opus 5.5 の 94.0 に後れを取る。HLE は 19.0 で、J​ev の 19.4 に対して——いずれにせよレンジ最下位での引き分けだ。これは、画面が与えられた短いリストから選ぶことを仕事とするモデルにとって想定内であり、意思決定モデルがエージェント内の一構成要素であって、計画を立てるモデルの代替ではない理由でもある。

さらに興味深いのは、自社の前世代モデルに対する性能後退だ。ツール呼び出しがそもそも正当化されるかを問うWhen2Callでは、Drex Maxは85.2、Drex 2.0は86.5、より古く安価なDrex 1.5は89.7を記録する。最新かつ最も高価なDrexモデルは、いつ行動すべきでないかを知る点で3つの中で最悪だ。ワークフローが自制に依存している場合——返金ツールを呼び出すよりも沈黙すべきサポートエージェントなど——視覚能力はそれを買ってくれるわけではなく、安価なテキストモデルの方が依然として適切な選択肢かもしれません。

同じパターンは、逆方向の結果を示す視覚分野の2行にも現れている。スキャンした帳票からの主要情報抽出であるKIEは95.5で、Lunaの97.5に対して劣る。Hateful Memesのモデレーションは70.6対71.2だ。どちらの差も大きくなく、しかも両方とも、Drex Maxが他の分野では30ポイント幅の優位を持つ領域にある。これは、視覚エンコーダーが印刷された帳票やミームよりも、画面レイアウトやグラフに向けて学習されていることを示唆している。

レイテンシも後退した。Drex Maxの中央値183 msは、Drex 2.0より32 ms遅く、Drex 1.5より38 ms遅い。1タスクあたり30回実行されるループでは、タスクあたり約1秒が追加される計算になるが、フロンティアモデルと比べればステップあたり数秒を節約できる。それでも正しいトレードオフだが、ビジョンエンコーダーがタダではないことは知っておく価値がある。

引用される前に切り分けておくべき数値が一つある。冒頭段落の174 msは、Naceによるスクリーンショット限定の測定値だ——243の画像に関する質問を一度に1リクエストずつ行ったもので、同じセットでのJ​ev 1.14の253 msと対比される。183 msは、発表時の表にあるベンチマークスイート全体の中央値だ。どちらもNaceの測定値であり、別々の測定で、都合のよいほうはより狭い範囲のものだ。

何かを接続する前に知っておきたいAPIの2つの落とし穴

ドキュメントには、ざっと目を通すだけなら誰かが半日を無駄にするような細部が含まれている。 drex-latest は Drex Max を指していない。それは固定されたチェックポイントであり、エイリアスは別の何かに解決される。クイックスタートに従い、自分のキーに差し替えて TYPESAFE_DEFAULT_MODEL=drex-latest を設定する人——まさに J​ev-compatibility の手順がそうするよう指示していること——は、テキスト専用モデルを呼び出し、なぜスクリーンショットが無視されるのか不思議に思うことになる。

第2の罠はサイズです。APIガイドでは、リクエストは画像8枚まで、および画像トークンを含めて質問あたり131,072トークンに制限されていますが、ローンチ投稿では262Kをうたっています。Naceがこの2つを整合させるまでは、小さい方の数値に合わせてサイズを見積もってください。画像1枚あたりのトークンコストは公開されていないため、上限を事前に推測するのは困難です。フル解像度のスクリーンショットは固定のトークン数ではなく、ドキュメントには画像がどのようにリサイズまたはタイル分割されるかも記載されていません。

現行製品より簡単な点が1つあります。Drex Maxはあらゆる寸法のスクリーンショットを受け付けます。J​ev 1.14のAPIは、一辺が280 px未満または1,568 pxを超える画像を拒否します。これは、午前2時のリトライループでサイレント障害として表面化する類の制約です。

これがルーティングの判断に与える影響

実用的な問いは、Drex Max がフロンティアモデルより優れているかどうかではない。優れてはいないし、そうなることを目指してもいない。問いは、あるタスクにおける30の判断のうち、どれがフロンティアモデルにふさわしく、どれが174 msの確率分布にふさわしいのか、ということだ。そしてそれは、モデルの問題である前にルーティングの問題なのである。

Drex Max は当社のルート一覧にはありません。OrcaRouter のカタログにも収録されておらず、ここでの記述は当社による提供可否の主張と解釈すべきではありません — Nace が自社の API と自社のコンソールを通じて販売しています。当社が提供しているのは、その比較対象となる既存モデルです。TypeSafe Jev 1.13 は、入力100万トークンあたり $0.042 で掲載されているルートです。65,536 トークンのコンテキストで、同じPOST /v1/systemoneボディを通じて提供されるため、意思決定モデルと現在のスクリーンショットからフロンティアへのループとの A/B は、書き換えではなくモデル文字列の変更で済みます。これを決着させる安上がりな方法は、テキストのみの意思決定呼び出しはそのままにし、目が必要なタスク向けに画面読み取りステップを横に追加し、Nace の 140,178 件の採点済みリクエストではなく自社のログに照らして両方を測定することです。

その種の分割は、各部分を一つの場所から到達できる場合にのみ機能します。200以上のモデルにまたがる1つのキー、プロバイダーの定価をトークンごとの上乗せなしでそのまま適用すること、およびプロバイダー間での自動フェイルオーバーが、これを設定した人がチームを移った後に実験が陳腐化した分岐へと衰退するのを防ぐものです。ここでは具体的な理由もあります。Drex Maxは新しく、監査を受けておらず、API専用であるため、実績のないコンポーネントを採用する安全な方法は、信頼度が下がったりエンドポイントが不調になったりしたときに既知のモデルへフォールバックできるものの背後に置くことです。自信のある判断は安価なモデルにルーティングし、残りはフェイルオーバーに任せましょう。

何がこの読みを変えるだろうか

まず必要なのは、Decision Indexを独立に実行することだ。このスイートは公開されており、{{1}}Nace{{/1}}は評価は再現可能だと言っている。そして、社外の誰かがその上で{{2}}Drex Max{{/2}}を実行するまでは、67.6はサプライヤーの数字にすぎない。そのときに注目すべきセルは、逆方向を指しているものだ。Mind2Webでの30ポイントのリードの隣にWhen2Callでの回帰があるのは、滑らかな能力曲線ではない。「このうちどれが次のクリックか」を徹底的に訓練され、「何かクリックすべきか」についてはそれほど徹底的に訓練されていないモデルを表している。もしそれが裏付けられれば、それはDrex Maxに関する運用上最も重要な事実であり、ハイライトには載っていない。

同時実行時の本番レイテンシが2つ目の問題だ。Nace自身のスループット値——1つのH100レプリカで毎秒約25リクエスト、64件同時実行までエラーなし——はDrex全般についてのもので、Max固有のものではない。この設計の売りは、あらゆるステップでホットパスに入るという点にあり、そのため負荷時のp95は183 msの中央値よりもはるかに重要になるが、公開されている資料はその点に触れていない。

第三に、料金体系には画像を含めた具体的な計算例が必要だ。入力トークン100万個あたり0.06ドルという数字は、スクリーンショット1枚が何トークン分になるかを知って初めて役立つが、それを示した公開数値は存在しない。各ステップで1440pの画面を使う30ステップのループを予算化しようとするチームは、Naceが画像の計上方法を公表するか、誰かが実測するまで、推測に頼るしかない。

そのどれも、このリリースの面白さを損なうものではない。視覚を備えた意思決定モデルは、スクリーンショットを見るよう求められるチャットモデルとはまったく別のコンポーネントであり、価格差は、エージェントが各ステップでコスト的に何を実行できるかを変えるほど大きい。ただ、それはまだNaceの外の誰も検証していない数字にすぎない——そして、実際のデプロイとの接触に耐える表の部分こそ、おそらく誰も引用していない部分だろう。