GoogleのDecisions API、1,000件の質問に回答するも出力なしで課金

の最も安い部分はGemini Decision 1、存在しない部分です。Googleは2026年11月11日に、このモデルを新しいGemini Decisions APIの背後に置きました。料金ページでは出力がゼロと記載されています。安いのでも、割引なのでもなく、存在しないのです。なぜなら POST /v1beta/decisions には生成すべき文章がないからです。共有入力のブロックを1つと、最大1,000件の型付き質問を送ると、質問ごとに較正された回答が1つ返ってくるだけで、それ以外は何も返ってきません。ローンチ当日に注目を集めたのはリーダーボードの数字でした。あなたの作るものを変えるのは請求明細の行であり、誰かのアーキテクチャ図をコピーする前に計算しておく価値があります。

過去2年間にあなたが下した他のあらゆるモデル決定は、相反する2つのコストによって形作られてきた。一度だけ送りたい入力と、短く保ちたい出力だ。このエンドポイントは2つ目の緊張関係を完全に取り除き、代わりに単一リクエスト内部の別の緊張関係に置き換える。新しい緊張関係がどこにあるのか分かれば、API設計の残りの部分——質問数の上限、共有コンテキスト、キャッシュの不在——が恣意的に見えなくなる。

出力トークンがゼロだと算術に何が起きるか

現実的なドキュメントスコアリングの仕事を考えてみましょう。40,000トークンのポリシーや契約書があり、それについて回答を得たい1,000個の質問があるとします。Decisions API への1回のリクエストでは、40,000入力トークンが一度だけ課金されます。100万トークンあたり$0.10、つまり1セントの10分の4——1,000件の回答すべてで$0.004です。

では、1週間前に尋ねただろうと同じ方法で、同じ1,000個の質問を、1,000件の個別のgenerate-content呼び出しとして尋ねてください。各呼び出しはドキュメントを運ぶ必要があります。チャットエンドポイントには呼び出し間でそれを保持する方法がないからです。これは4,000万入力トークン、同じトークン単価なら4.00ドルであり、それらの各呼び出しが生成したはずの出力トークンを加えると差はさらに広がります。エンベロープは便利機能ではありません。同じ作業に対して1,000倍のコスト差が生じるのであり、それは単一の設計上の選択、つまり質問は往復ごとに1つではなく、1回のパスで1つの共有コンテキストに対して評価されるという選択に由来します。

その計算は、このモデルが求めるワークロードの形も教えてくれます。1つの大きなオブジェクトに関する多くの質問を、まとめて回答する形です。質問が1,000個の異なるオブジェクトに関するものであれば、1,000件のリクエストになり、節約はまったく得られません。

エンベロープ：262,144トークン、共有、かつ1,000問までに制限

コンテキストウィンドウは、共有入力とリクエスト内のすべての質問を合わせて、262,144トークンでカバーします。その予算内で、1～1,000個の質問を投げかけることができます。重要なのは上限です。1回の呼び出しで1,000個の質問を処理するのは分類器の領域ではなく、ルールエンジン相当の判断を1回のパスに圧縮するようなものです。サポートチケットは40条のポリシー条項と照合でき、融資ファイルはすべての引受ルールと一括で照合できます。

リクエスト形状には、見落としやすく、後から気づくと高くつく性質が2つある。質問は独立に評価される — ある質問の回答が次の質問の条件になることはないので、以前の回答に依存する追加質問を投げて推論をつなげることはできない。また、モデルは質問キーを一切見ず、あなたが書いた指示テキストだけを見る。つまりキーは自分用の記録にすぎず、指示はそれ単独で成立していなければならない。

3つの質問の型、そしてそれぞれに潜む罠

• はい/いいえ — noul型は0.01から0.99の間の確率と信頼度スコアを返します。境界は両端でクランプされるため、ルーティング閾値を0.995に設定しても、モデルがどれほど確実でも発火することはありません。APIが実際に返せる範囲内で閾値を選んでください。

• Choice — 2～255個の名前付きオプションを指定でき、勝者のオプション、合計が1になる各オプションの確率、信頼度を返します。スコアリングの前に、API はオプションのキーを UTF-8 バイト順でアルファベット順にソートします。つまり JSON のキー順は関係なく、完全な同点は最初にソートされるキーに解決されます。Google のガイダンスもそこから導かれています。catch-all オプションには other という名前を付けてください。none_of_the_above のような名前はほとんどの実際のカテゴリより前にソートされるため、負けるべき同点で勝ってしまうからです。

• Score — 2～255 の順序付きルーブリックレベル（2～10 を推奨）。戻り値は確率で重み付けされた期待レベルです。期待値はラベルではなく配列インデックスを平均するため、1/10/100/1000 のように記述されたスケールでは、あなたのスケール上にない数値が生成されます。ルーブリックをインデックス基準で均等に保つか、期待インデックスを自分でラベルに変換し直してください。

ドキュメントが利用不可として記載しているもの

不足している機能はどれも同じ方向にあります。これは単発のエンドポイントで、周囲に何もラップされていません。コンテキストキャッシュがないため、リクエストをまたいで再利用されるポリシー文書も毎回まるごと再請求されます。Batch APIがないため、昨年のチケットを半額で夜間に一括処理するといったこともできません。FlexティアやPriorityティアもありません。モデルはGemini Developer APIのみ、バージョンv1betaで、Googleが提供したドキュメントにVertex AIの記載はありません。これは、APIキーではなくクラウド契約を通じて調達している人にとって重要な詳細です。

メディアは、異例なほど広範でありながら、同時に異例なほど制約も厳しいです。テキスト、画像、動画、音声、PDF をすべて 1 つのリクエストで送信できます。制限は、インライン base64 が 100 MB、PDF が 50 MB、外部 HTTPS URL 1 件あたり 15 MB です。YouTube リンクは受け付けられず、gs:// URI も同様です。アップロード済みファイルへの参照、署名付き URL、またはバイト列を渡します。

レート制限は無料枠では毎分200リクエストと50,000トークンから始まり、Tier 1では1,500リクエストと100万トークンに引き上げられ、Tier 2では毎分5,000リクエストと400万トークンに達し、1日あたりのリクエスト上限はありません。無料枠は無償ですが、Googleの製品改善に使用されると文書化されているため、機密保持条項の下での用途には適していません。

スコアを手短に

Artificial Analysis Decision Index v2.1 では、このモデルは66（四捨五入前は65.98）で、同ボードが順位付けする18の意思決定モデルのうち9位に位置する。6つの構成要素のうち2つ、AA-Omniscience-Decision v1.1 と HLE-MultiChoice v1.1 では単独首位で、両方とも重みは15%。また、重み30%の AA-Paperclip では中位で、これは総合スコアの大部分を決める構成要素である。測定されたコストは100万タスクあたり345ドル、レイテンシは1タスクあたり211ミリ秒で、参加モデル全体の中央値209ミリ秒に対してである。Googleは今回のリリースに際して独自のベンチマーク表を公表していない。ここに示すすべての性能数値は、独立したボードが独自のハーネスで計測したものである。66という数字の背後にある計算は、別の問題であり、別の記事で扱う。

すでにルーティングしているパイプラインへの組み込み

OrcaRouterはgemini-decision-1を取り扱いません。その理由は商業的ではなく構造的です。確率のみを返すエンドポイントはchat-completionsの対象ではないため、私たちの形態のルーターが1つのキーの背後に置くものは何もありません。私たちが受け持つのは、パイプラインのもう半分です。意思決定サービスはほぼ常に2つの呼び出しから成ります——候補となる回答、ルーブリック、候補リストのいずれかを下書きするものと、それを採点するものです——そして、モデル選択が実際に争点になるのは下書きの呼び出しのほうです。

その呼び出しは1つのエンドポイント上で200を超えるモデルにまたがって実行でき、プロバイダーの定価を0%のマークアップでそのまま反映した価格で利用できます。そのため、ベンダーが価格を下げると、次の請求サイクルではなく当日中に新しい価格が当社側で有効になります。モデル融合はここでこそ真価を発揮します。チャットUIではそうならない形で：2人のドラフターが競合する候補回答を生成し、Decisions APIが同じルーブリックに対して両方を1回のリクエストでスコアリングするため、A/Bテストがレコード単位の判断に変わります。

フェイルオーバーについても正確に理解しておく価値があります。自動フェイルオーバーは生成呼び出しを保護します — 下書きモデルの背後にあるプロバイダーがエラーを返すと、リクエストは再ルーティングされ、パイプラインは動き続けます。スコアリング呼び出しは保護できません。送信先が正確に1か所しかないからです。意思決定エンドポイントがダウンしていれば、パイプラインもダウンし、どれだけルーティングを変えてもそれは変わりません。下書き側は耐障害性があるように設計し、スコアリング側は依存関係であることを受け入れてください。

結論

Decisions API を採用する価値がある理由は1つだけで、それはリーダーボードでの順位ではありません。1000回の往復を1回の課金対象入力に畳み込み、それによって、どの質問を安く投げられるかが変わるからです。契約書、請求ファイル、1時間の動画といった1つの大きなオブジェクトに対する多数の判断が自分の問題に似ているなら、その上に構築してください。そして、プロンプトは1回のリクエスト内に収めることを前提にしてください。安くするためのすべては、1回の呼び出しの最初のトークンと最後のトークンの間で起きるからです。自分の問題が、1000個の小さなオブジェクトに対する1つの質問に似ているなら、そのエンベロープは何の役にも立たず、入力レートは安価な意思決定モデルが課す料金の単純に3倍です。