Gemini Decisions API：速い判断にも実行の境界が必要だ

2026年11月11日、Googleは限定された選択肢を判断するGemini Decisions APIを発表した。注目すべき変化だが、重要なのはモデルがどれだけ速く答えを選べるかだけではない。組織が、自動実行につなげてよい判断と、追加確認のために止めるべき判断を定義できているかである。

Googleの発表がニュースの背景となる。本稿は技術と事業上の意味を検討するもので、独立した性能試験ではない。

判断と実行を分ける

ソフトウェア企業のサポート窓口に「今月また請求されました。解約してください」という連絡が来たとする。これは本稿の仮想例であり、Googleの顧客事例ではない。二重請求なのか通常の更新なのか。将来の更新を止めたいのか、支払い済みの代金を返してほしいのか。注文はそのアカウントのものか。すでに返金されていないか。複数の問いが残っている。

言語モデルは意図の理解を助けられる。しかし、文章だけで決済台帳上の事実を確定すべきではない。確信の強い分類でも、二重請求の証明にはならない。記録の照合、操作権限の確認、返金規則の適用が必要だ。すべてを「返金すべきか」という一問にまとめれば、呼び出し回数は減ったように見えるが、不足している証拠を隠す可能性がある。

専用の判断部品には、役割分担を明確にする価値がある。一つの部品が依頼を理解し、別の部品が信頼できる業務記録を読み、明示的な規則が操作範囲を制限する。モデルがすべてを担当する必要はなく、従来のプログラムも固定キーワードだけであらゆる表現を理解できると装う必要はない。その境界自体が製品設計の対象となる。

選択肢が認識できる範囲を決める

GoogleのAPI文書は、適切な選択肢がなくても確率が配分されることを注意点として挙げ、業務のラベル付き事例で閾値を決めるよう勧めている。形式が正しい応答だからといって、問いの定義も正しいとは限らない。

サポート分類が「返金」と「更新」だけなら、請求書のダウンロード依頼まで誤った分類に押し込まれかねない。「その他」を追加するのは出発点にすぎない。その依頼をどこへ送り、誰が確認し、繰り返し現れる何を独立した分類にするかを決める必要がある。担当者のいない例外キューは、自動化の失敗を見えにくくするだけだ。

分類も事業とともに変わる。無料体験の終了、キャンペーンの変更、法人契約の例外によって、同じ文章への正しい対応が変わる場合がある。維持すべきなのはモデルの版だけでなく、選択肢の説明、規則の版、受け入れ試験の事例である。そうしなければ、業務上の意味が変わった後も、整った構造の結果だけが安定して出続ける。

確信度を永久的な許可証として扱うべきでもない。低リスクのラベル付けに十分な確からしさが、送金に十分とは限らない。顧客を一分余計に待たせる振り分けミスと、取り消せない取引では必要な保護策が異なる。閾値の選択は、もっともらしい小数を探すことではなく、まず誤りの損失を考えることだ。

推論価格だけでは業務費用は分からない

Vercelも11月11日にGemini Decision 1の提供を確認し、判断の呼び出しをログと予算管理に含めている。接続経路が増えれば試しやすくなるが、実務での評価を省略できるわけではない。

購入側が比較すべきなのは、正しく完了した一つの仕事にかかる総費用だ。安い判断でも再試行、大型モデルへの切り替え、人による確認が多ければ、節約は想定より小さくなる。反対に単価が高くても、不要なエスカレーションや重複処理が減れば、全体の経済性は改善し得る。業務事例なしに計算できる共通の答えはない。

Vercelの判断機能の文書は、確信度が低い場合に別モデルで再実行する任意機能と、二段階の課金を説明している。代替モデルは信頼性を高める仕組みであると同時に費用項目でもある。いつ呼び出され、誤りを修正したかを記録すべきであり、最終的に成功したからといって最初の判断を評価から消してはいけない。

速度もサービス全体で測る必要がある。待ち時間の大部分が注文照会や承認なら、分類の高速化が改善するのは一部分だけだ。小さな判断が多数、対話の主要な処理経路に存在するなら、専用インターフェースが体験を大きく改善する可能性がある。有益な比較では、仕事、データ、成功基準をそろえる。各社の宣伝上の遅延数値をそのまま並べるべきではない。

新しい製品分類に必要な検証

OpenAIは2026年10月22日にDecisions APIの一般提供を発表した。Googleの参入も、文章生成だけでなく、範囲の決まった選択を頻繁に必要とするアプリケーションへの対応と理解できる。

競争は導入や提供元の変更を容易にするかもしれない。しかし似たインターフェースでも結果は交換可能とは限らない。典型的な依頼、境界事例、情報不足、誤解を誘う表現を含む、提供元に依存しない試験材料を維持したい。モデルを変更した際は、応答の項目名が同じかよりも、業務上の振る舞いが許容できるかが重要だ。

妥当な導入順序は、まず実業務を観察させ、提案だけ記録して実行はさせないことだ。次に低リスクの場面で限定的に実行を許し、結果を確認して範囲を広げる。これは本稿の技術的提案であり、特定製品の安全性の保証ではない。試験には情報不足も含めるべきだ。優れたシステムは早く答えるだけでなく、追加の証拠が必要な場面を扱わなければならない。

Gemini Decisions APIの意義は、判断を個別に購入、測定、交換できる部品にした点にある。企業に代わって規則を定義したり、不足する証拠を補ったりはしない。実際の利益は、判断、事実、権限、実行を区別し、その境界を継続して点検できるかに左右される。