Gemini Decision 対 Gemini Decision 1：一方は名前、もう一方はモデルID

「Gemini Decision」を検索すると、ローンチ記事、リーダーボードの項目、料金表の行、APIリファレンスが見つかります。いずれも同じものを少しずつ違う言葉で表しています。次に「Gemini Decision 1」を検索すると、実際に動作するモデルIDが見つかります。この2つの文字列は1文字だけ異なるのに、コードではまったく異なる動作をします。一方は人々が製品を呼ぶときの名前で、もう一方はPOST /v1beta/decisionsが受け付ける唯一の値です。明らかに存在するモデルが見つからないのはなぜかと、404エラーで午後を丸ごと費やしたことがあるなら、これを読んでいれば救われたはずの記事です。

この混乱は、特に誰かのミスというわけではない。Googleは2026年11月11日の同じリリースで、モデル、エンドポイント、ファミリー名を提供し、この3つすべてについて書くときの自然な方法は、それらを短縮することだ。その短縮は文章では機能するが、リクエストボディでは失敗する。そして、この2つの事実の間のギャップが、今後1か月でこのカテゴリのサポートチケットの大半が発生する場所になる。

2つの名前が何に解決されるか

マッピングから始めましょう。ほかのすべてはそこから導かれるからです。

• Gemini Decision — 製品名です。これは意思決定モデル系列を指し、Google 自身のドキュメントでは、文章中のファミリーラベルとして、モデルカードの見出しで、そして「Gemini Decision でのみ利用可能」のような文で登場します。これはモデル ID ではなく、背後にエイリアスもなく、model として渡すと、ファミリーの最新メンバーにフォールバックするのではなく unknown-model エラーが返ります。

• Gemini Decision 1 — モデル、および ID gemini-decision-1。これが機能する値です。Decisions API が提供する唯一のモデルであり、ドキュメントにも明記されています。エンドポイントは G​emini Decision 1 でのみ利用可能です。

2つの名前、1つのモデル、そして両者の間にエイリアスはない。最後の点が珍しいところだ。ほとんどの G​oogle モデルファミリーは、変動するエイリアスと固定された ID を提供する — プロトタイプ向けの -latest 形式と、本番向けの日付付きまたは番号付き形式だ。これは固定形式しか提供しないため、ファミリーには流動的な先頭があるという前提で組まれたコードパスは、新しいバージョンを黙って追跡するのではなく、ここで失敗する。

2番目の名前が繰り返し出てくる場所

この曖昧さがなかなか払拭されないのは、3つの別々のシステムがこのモデルを記述しているものの、どれ一つとして同じ命名規則を共有していないからだ。

料金ページでは、それはモデル自身の名前で掲載されており、料金と、出力は該当なしという注記が併記されています。API リファレンスはエンドポイントを説明し、モデル名はモデル表ではなく可用性に関する文の中で示しています。それをベンチマークする独立系リーダーボードは、その行とグラフで読みやすい名前を使用しています。これらはいずれも誤りではなく、いずれもモデル ID ではありません。そのため、どれからコピーしてリクエストボディに入れても、同じ失敗が発生します。

時間が経つにつれて重要性を増す第四の変動要因がある。それは他人が書いた文章だ。ローンチ時の報道、チュートリアル、フォーラムの回答はいずれも名前を短縮しており、中にはそれをIDのように見える形——小文字、ハイフン区切り、いかにもありそう——に短縮するものもある。対処法は、それらのどれも信用しないことだ。エンドポイントに問い合わせよう。

特定のキーが実際に何を呼び出せるかを確認する方法

リクエストを書く前に、そのキーに利用権のあるモデルを一覧表示してください。Generative Language API の標準の list-models 呼び出しは、プロジェクトで利用可能なモデルをその ID とともに返します。一度実行すれば、そのキーについてこの問いは恒久的に解決します。

gemini-decision-1 が表示されるなら、アクセス権があり、その正確な文字列をリクエストに入れることになります。表示されない場合、問題は綴りではなく権利付与か地域であり、名前をどう変えても解決しません。そのリストに見つからないのは gemini-decision という項目です。なぜなら、そのようなモデルは存在しないからです。

2つ目の確認はレスポンスに関するものです。成功した判定レスポンスは、それを処理したモデルを識別するため、モデルフィールドを自身のリクエストIDと併せて記録するパイプラインなら、数か月後に設定を読み直さなくても「この回答を生成したのはどのモデルか」に答えられます。それは単なる事務処理のように聞こえますが、誰かが「なぜ判定が変わったのか」と初めて尋ね、正直な答えが「エイリアスが移動したから」だったときまで、そう思われるだけです。

この曖昧さが実際に引き起こす3つの間違い

• 未知のモデルによる 404。 最も明らかな原因です。リクエスト本文の gemini-decision は、権限の問題のように読めるエラーを返しますが、実際には権限の問題ではありません。エラーがプロジェクトではなくモデルに言及している場合は、請求アカウントを確認する前にその文字列を確認してください。

• 静かなるエイリアス前提という落とし穴。 こちらは見つけるのがより困難です。`-latest` の慣習を身につけたチームは、ファミリー名と解決ステップを含む設定を書き、その解決ステップはエイリアスが存在しない場合にファミリー名のリテラルをそっと返します。すると障害はデプロイ時ではなく最初の実際のリクエスト時に現れることになり、これ以上ないほど最悪のタイミングで発覚します。

• 誤ったエンドポイントの想定。 さらに微妙なのは、モデルが存在し名前も正しいためです。gemini-decision-1 を通常の generate-content エンドポイントに送っても、やはり失敗します。そのモデルはそもそもその方法では呼び出せません。これは decisions エンドポイント上の確率のみのターゲットであり、散文を要求するリクエストは、それが生成しないものを求めていることになります。チャット補完をデフォルトとするクライアントライブラリには、明示的なパスが必要になります。

これがモデルについて何を物語っているのか、単にその名前だけでなく

命名は、実際の設計上の判断が表れたものにすぎない。つまりこれは、出力形式が異なるチャットモデルではないということだ。チャットモデルはテキストを返すため、同じスキーマを扱うプロバイダー、プロキシ、ゲートウェイの間でそのIDを自由に入れ替えられる。自分の型付き質問に対して較正済みの確率を返すモデルには、そのような共通スキーマはなく、IDは1つのリクエスト形状を持つ1つのエンドポイントに結び付いている。

家族にフローティングエイリアスも2番目のメンバーもまだ存在しないのは、そのためです。互換性を取る相手がまだ何もないからです。これは、このモデルを単純に汎用ルーターへ追加できない理由も説明しています。OrcaRouter が gemini-decision-1 を扱っていないのは、確率のみを返すエンドポイントは chat-completions の対象ではなく、そのスキーマを話すキーの背後に置くことは、ルーティング層が守れない約束になるからです。決定空間で実際に扱っているのは TypeSafe の typesafe/jev-1.14 です。これは、カタログ上のほかのすべてと同じインターフェースを通じて呼び出せる決定モデルです。

ルーターが実際に担う意思決定パイプラインの部分は、下書き側、すなわち候補回答や、その後スコアラーが評価するルーブリックを生成する生成呼び出しです。その呼び出しは、1つのエンドポイント上で200以上のモデルにまたがって実行され、プロバイダーの定価が0%のマークアップでそのまま反映されます。そして、それはベンダーの切り替えが書き直しではなく設定変更で済む。一方、スコアリング呼び出しは設計上1つのエンドポイントに縛られており、誠実なアーキテクチャでは、それをルーティングで回避するものではなく固定された依存関係として扱います。

フォーム上で2つの文字列のどちらかを選ぶ場合は

この質問には、識別子にまったく関係しないバージョンもあり、その言い回しがそれを誘うため、直接答える価値があります。誰かが「G​emini Decision」と「G​emini Decision 1」を比較するとき、古いものと新しいものという2つの製品を見ていると信じ、どちらを採用すべきか知りたいと思うかもしれません。しかし存在するのは1つだけです。G​emini Decision 1 より前に G​emini Decision という名称のものが出荷されたことはなく、短い名前は、現在メンバーが1つだけのファミリーのファミリーラベルです。

実際的な帰結として、両方を別々の項目として挙げている比較表、レビュー、ベンチマークは、同じモデルを二重に説明していることになります。2行で1モデル、価格も1つ。2行の数値が食い違っている場合、それは別のものを測定しているのではなく、どちらかが古くなっているだけです。

結論

すべてのリクエストボディ、エンドポイントパス、設定値では gemini-decision-1 を使用し、「G​emini Decision」は人間が読む箇所でのみ使用してください。フォールバックできるエイリアスはなく、短い名前の背後に隠れた第2のモデルも、長い名前へ通じる chat-completions パスもありません。これを間違える代償は小さく、404 が1回と、混乱した午後が1回ある程度ですが、エイリアスが存在すると仮定する代償はより大きくなります。その誤りはレビューをすり抜け、本番環境で失敗するからです。id を固定し、レスポンスに示されたモデルをログに記録し、ファミリー名は文章として扱ってください。