Gemini Decision 1 vs Drex Max v1.1：どちらも262Kトークンを読み取れるが、文書をカウントできるのは片方だけ

横に並べてみると、Gemini Decision 1とDrex Max v1.1の仕様書はほぼ重なります。どちらも意思決定モデルで、どちらも262,144トークンのウィンドウを持ち、どちらもテキストと並べて画像を読み取り、どちらも文章ではなく確率を返します。差が開くのは1か所です。Artificial Analysis Decision Index v2.1の文書意思決定コンポーネントでは——1つの密度の高い文書から5つの意思決定と10の事実を抽出し、その15項目すべてを正しく答えることを求める、30%の重みを持つテスト——Drex Max v1.1は文書の63%に合格し、Gemini Decision 1は33%に合格します。この単一コンポーネントが、一方が73点、他方が66点となる主な理由です。

残りの違いは、実際に行動に移せる算数の話です。{{1}}Drex Max v1.1{{/1}} は入力トークン100万個あたり $0.03、{{2}}Gemini Decision 1{{/2}} は $0.10 で、100万タスクにわたると $103 対 $345 になります。さらに {{2}}Gemini Decision 1{{/2}} は共有入力に対して1リクエストあたり最大1,000問を扱えますが、{{1}}Drex Max v1.1{{/1}} は1つの状態に少数の質問を付けることを想定しています。これらの数値のどれが選択を決めるかは、意思決定が一度に1つの文書ずつ来るのか、一度に40個のルールで来るのかによって完全に決まります。

同じアイデアの2つの異なる形

両モデルともテキスト生成を拒否し、どちらもコストモデリングで重要な一つの特性を共有している。入力は一度だけ読み込まれ、すべての質問はそれに対してスコアリングされる。両者が異なるのは、その入力に何を入れられるかという点だ。

• 回答タイプ — Drex Max v1.1 は choice、noul、score を提供します。これは TypeSafe の Jev が定義し、Nace が採用したリクエスト形状です。Gemini Decision 1 も同じ3つを提供し、choice では2～255個の選択肢、ルーブリックレベルは2～255段階（推奨は2～10）です。

• 1回の呼び出しあたりの質問数 — Gemini Decision 1 では最大1,000件、それぞれが1回のパスで独立に評価され、キーはご自身で指定します。Drex Max v1.1 では州ごとに数件で、作業単位は1つの項目とその質問です。

• モダリティ — Gemini Decision 1はテキスト、画像、動画、音声、PDFを受け付けます。Drex Max v1.1はテキストとリクエストごとに最大8枚の画像を受け付けます。どちらも質問の指示内にメディアを含めることはできません。Gemini Decision 1ではこれは文書化された制限であり、そこではメディアは共有入力に含めるべきものです。

• ウィンドウ — Gemini Decision 1では、共有入力と全質問を合わせて262,144トークン。Drex Max v1.1は、質問ごとに131,072トークン（画像トークンもこれに含まれる）と記載しており、パックされたリクエストの上限は262,144です。

• 請求 — Gemini Decision 1は入力トークン100万個あたり0.10ドルを請求し、繰り返し共有された入力を明示的に全額再請求します。キャッシュやBatch APIはありません。Drex Max v1.1は入力トークン100万個あたり0.03ドルを請求し、これはvv1.1がv1をそのまま置き換えた際にNaceが半減させた料率です。

• アクセス — Gemini Developer API の v1beta で Gemini Decision 1 を利用可能。無料枠があり、Tier 2 からは1日のリクエスト数が無制限。Drex Max v1.1 は Nace.AI が POST /v1/systemone でホストしており、ダウンロード可能なチェックポイントはありません。

そのリストを一文として読んでください。Drex Max v1.1 は、画面またはページと、それに関するいくつかの判断のために作られており、Gemini Decision 1 は、大きなコンテキストと大規模なルールブックのために作られています。1,000問の上限は、仕様書を飾る見栄ではありません。それは、リクエストごとに40回呼び出すモデルと、1回だけ呼び出すモデルの違いです。

6.6ポイントの差は実際どこから生じているのか

Decision Indexは6つの評価に重み付けを行っており、両モデルはその6つすべてで実行されています。各構成要素を並べて比較するほうが、合成値よりも情報量が多くなります：

• AA-Paperclip, 30% — Drex Max v1.1 72.8、Gemini Decision 1 56.8。文書あたり15問、全問正解か0点か。この16ポイント差が順位を決めます。

• EvalSafe-O*NET-AA, 15% — 88.3 対 87.1。実質的には引き分けです。

• When2Call、10% — 95.3 対 80.5。ここでは Drex Max v1.1 が2位、Gemini Decision 1 は18人中14位です。

• AA-Omniscience-Decision v1.1、15% — 66.3に対し60.3。この項目はGemini Decision 1が制しており、その44.8%という素の正解率は、ボード上のどの意思決定モデルよりも高い。

• HLE-MultiChoice v1.1、15% — 46.6 対 48.7。接戦で、どちらも上位に位置し、どちらも生の正解率は1桁台です。

• AA-Symmetry v1.1、15% — 79.8 対 70.5。Drex Max v1.1 は並べ替えと否定に対して 53.3% の確率で回答を維持します。Gemini Decision 1 は 38.3% です。

パターンは一貫している。Drex Max v1.1 は、意思決定が再現可能で構造的に健全かどうかを試す2つの要素で勝っている。Gemini Decision 1 は、物事を知っているか、そして知らないことを知っているかどうかを試す2つの要素で勝っている。どちらも擁護可能な製品であり、意思決定モデルが何のためにあるのかという異なる問いに答えている。

Drexの数値に関する注意点が一つあります。Artificial Analysisが報告している100万タスクあたり103ドルは一時的なローンチ価格を反映したもので、取締役会は標準価格ではコストが2倍になると注記しています。定価では、Drex Max v1.1は100万タスクあたり約206ドルで、Gemini Decision 1の345ドルを大きく下回るものの、もはやその3分の1ではありません。レイテンシは逆の傾向で、Drex Max v1.1は1タスクあたり283ミリ秒、Gemini Decision 1は211ミリ秒となり、どちらも業界中央値の209ミリ秒より遅くなっています。

スコアではなく、リクエストの形で選んでください

結論が保持されるべき単一の成果物に関する判断であれば、Drex Max v1.1を選んでください。スキャンしたフォームに対する保険金請求のトリアージ、再レンダリング後に同じクリック判断を再度求められるスクリーンショットベースのエージェント制御、反転した yes/no が実際のエラーとなる契約レビューなどです。そこでは、文書合格率63%と対称性合格率53.3%という数値がそれ自体でコストを回収し、入力トークン100万あたり$0.03という価格がボリュームの主張を容易にします。

あなたの判断が単一の入力に適用するルールブックである場合、または入力がテキストでも画像でもない場合は、Gemini Decision 1を選んでください。1回の呼び出しでサポートチケットに対して40件のポリシーチェックを行うのは、Gemini Decision 1が想定していたワークロードであり、Drex Max v1.1は想定していませんでした。また、入力が通話録音やPDFの場合、この2つのうち読み取れるのは片方だけです。Googleのドキュメントには、対応している1つの機能と並べて未対応の14の機能が記載されているため、導入を決める前に適合性を簡単に確認できます。キャリブレーション済みの判断を行い、それ以外はすべてオフにします。

どちらも採用しないでください。ただし、判断が大規模化した際のコストに左右されるのであれば別です。Gemini Decision 1 には Batch API もコンテキストキャッシュもないため、100万件の履歴チケットを毎晩スイープすると、ポリシー文書を毎回読み直したうえでフルレートで課金されます。Drex Max v1.1 のローンチ価格は一時的なものです。現時点でどちらの製品も、バックフィルを安価にする割引構造を提供しておらず、これは1年分のチケットで試算する人にとって6インデックスポイントよりも重要になります。

2つ目の契約なしで両方を実行する

OrcaRouterはこの2つのどちらも扱っていません。どちらもchat-completionsの対象ではなく確率のみのエンドポイントであり、そうでないかのように示唆するのではなく、そのように明言しています——カタログの決定モデル一覧に載っているのはTypeSafeのtypesafe/jev-1.14で、これは同じボード上で66.23となり、本稿で扱う2モデルの間に位置します。

ベイクオフで実際にかかるコストは、ベンチマークには決して現れない部分です。すなわち、2つのSDK、2通りのキー管理、検討すべき2組のレート制限です。だからこそ、意思決定パイプラインの生成側は、スコアリング側がそうできない場合でも、ルーターの背後に置くべきなのです。候補回答の下書きを作り、ルーブリックを書き、スコアリング対象の要約を生成する呼び出しこそ、まさに午後のうちにベンダーを切り替えたくなる呼び出しです — 1つのエンドポイント、200以上のモデル、プロバイダーの定価を0%のマークアップでそのまま提供、そしてプロバイダーが劣化したときのフェイルオーバー。スコアリング呼び出しはGoogleまたはNaceに直接向け、生成呼び出しはポータブルに保ちましょう。ルーティングできないモデルは安価な部分であり、ルーティングできるモデルこそ、あなたが変更したくなるモデルです。

両方を自社のラベルで実際にテストするなら——そしてそうすべきです。どちらのベンダーもあなたのデータに対するキャリブレーション曲線を公開していないからです——同じ200文書に同じ質問セットで実行し、指数ではなく合格率を比較してください。取締役会のPaperclipに関する30ポイントの差は強い事前情報です。それはあなたの文書の測定値ではありません。