11月14日、Pradeep Singhが「Stop Using LLMs for Yes/No Routing: Meet Google's New Gemini Decisions API」と題した記事を公開した。Yes/No判定などの制御フロー処理に汎用LLMを使うことの非効率を指摘し、Googleの新しい専用モデル「Gemini Decision 1」とその Decision API を使った代替アプローチを詳しく解説している。最大のポイントは出力トークンが常にゼロであること、そして汎用LLMと比べてキャリブレーション誤差（ECE）が最大8倍以上改善されることだ。

「if/else代わりのLLM」問題

現代のAIアプリケーションを眺めると、LLMが本来不得意な仕事をさせられているケースが多い。

• 「このサポートチケットを billing、shipping、replacements に分類せよ」
• 「この営業通話を 0〜3 のルーブリックで採点せよ」
• 「このエージェント応答が25件のコンプライアンスルールに違反しているか確認せよ」

これらはすべて、テキスト生成モデルにif/else文を書かせているようなものだ。システムプロンプトに「必ずJSONのみで返答せよ。markdownのコードブロックは使うな」と書いてきた経験があるエンジニアは多いはずだ。

これが小規模なら問題ない。しかしスケールすると、隠れたコストが積み上がっていく。

生成LLMを制御フローに使う「5つの税金」

Pradeep Singhは、生成LLMをルーティング・分類処理に使い続けることの問題点を5つ挙げている。

① レイテンシ：出力が {"queue": "replacements"} の一語であっても、自己回帰デコーディング（トークンを1つずつ生成する処理）は毎回実行される。エージェントが1ターンごとにツールルーティングとガードレールチェックを行う場合、600ms＋800msの積み重ねが体験を劣化させる。

② 信頼度の未校正：LLMに「0〜100で確信度を答えよ」と聞いても、その数値は幻覚に近い。RLHFによるフォーマット最適化の影響で、生トークンのlogprobも歪む。自動化のしきい値として使えるキャリブレーション済み確率が得られない。

③ 自己回帰による汚染：40件のコンプライアンスチェックを1つのJSONで返させると、ポリシー1の判定結果がポリシー2の予測コンテキストに入り込む。後半の判定精度が下がる「アンカリングバイアス」が発生する。

④ OCR・音声認識パイプラインの別途構築：テキスト専用の分類器では、画像・PDF・音声を扱うために別途前処理パイプラインが必要になる。

⑤ 出力トークン課金：50件のポリシーチェックを個別に呼び出せば共有ドキュメントに50回課金される。1つのStructured Outputにまとめれば、出力トークン単価（通常は入力の4〜5倍）が重くのしかかる。

Gemini Decision 1：「System 1」型の新しいモデルクラス

2026年11月11日、GoogleはGemini Decisions APIと、それを支える専用モデル gemini-decision-1 を発表した。

Pradeep SinghはKahneman（ノーベル賞経済学者）の「ファスト＆スロー」の概念を借りて説明している。

• System 2（生成LLM）：多段階の推論、文章生成、コード合成。トークンを逐次生成する。
• System 1（Decision Model）：交差点の信号を見て即座に「赤だ」と判断するような処理。生成は不要。

gemini-decision-1の動作原理はシンプルだ。

[マルチモーダル入力 + 型付き質問群]
         ↓
   シングルフォワードパス（1回の推論）
         ↓
  校正済み確率・信頼スコア（出力トークン = 0）

入力に対して最大1,000件の質問を1回の推論で並列評価し、テキストトークンを1つも生成しない。各質問は独立して採点されるため、質問の追加・削除・並び替えが他の質問の結果に影響しない。元記事によれば、このシングルフォワードパス設計により150ms以下のレイテンシを実現しているとされる。自己回帰デコーディングを行わないことが、このレイテンシ特性の直接的な要因だ。

主要スペック

3種類の質問プリミティブ

質問は以下の3タイプで定義する。

• noul（Yes/No判定）：バイナリの条件に対してYesの確率（0.01〜0.99）と信頼スコアを返す。
• choice（排他的選択、2〜255択）：候補キーすべての確率分布を返す。内部でキーをUTF-8バイト順にソートして採点するため、ペイロード上の並び順が結果に影響しない。
• score（ルーブリック採点、2〜255段階）：0〜N-1の各レベルに対する確率加重期待値（例：0〜2スケールで 1.12）を返す。

キャリブレーション精度の比較

校正誤差（ECE）の比較（値が低いほど正直な確率推定）：

（※）TypeSafe Jev 1.14およびGPT-6 Luna（OpenAI）は、元記事掲載のベンチマーク対象モデル。読者は元記事の比較表も合わせて参照されたい。

if answer.confidence >= 0.85 のようなしきい値判定を本番環境で信頼できるかどうかは、このECEの差に直結する。

コスト面でも、Googleの7ベンチマーク合計で gemini-decision-1 は $0.88、Gemini 3.5 Flash-Lite は $4.14 と、約4.7倍の差がある。

コードサンプル：最小構成のYes/No判定

from google import genai

client = genai.Client(http_options={"api_version": "v1beta"})

result = client.decisions.create(
    model="gemini-decision-1",
    input="The blue mug I ordered on Monday arrived cracked on Wednesday.",
    questions={
        "is_damaged": {
            "type": "noul",
            "instructions": "Did the item arrive damaged?",
        },
    },
)

answer = result.answers["is_damaged"]
print(f"P(yes)={answer.noul:.2f} | confidence={answer.confidence:.2f}")
print(f"Output tokens billed: {result.usage.total_output_tokens}")

SDKは google-genai パッケージの3.2以降が必要だ。対応バージョンはPyPIのgoogle-genaiリリースページで確認できる。APIキーはGoogle AI Studioで取得できる。

まとめ

「分類・ルーティング・ポリシーチェック」をLLMで処理し続けているコードベースは、今まさに見直しの対象になる。gemini-decision-1 は出力トークンゼロ・150ms以下のレイテンシ・校正済みの確率という3点をセットで提供することで、汎用LLMがこれまで引き受けてきた制御フロー処理を専用モデルに切り出すための具体的な選択肢になった。

詳細はStop Using LLMs for Yes/No Routing: Meet Google's New Gemini Decisions APIを参照していただきたい。