Googleが、文章、写真、音声、動画、文書に複数の分類質問をまとめて投げかける新APIを公開した。開発者は生成文を再解釈する代わりに、選択肢ごとの確率と信頼度スコアを受け取り、自動処理するか人に引き継ぐかを決められる。
1. 一つの入力に最大1,000個の質問をまとめる
新APIはGemini Decision 1モデルで、同じ入力に対して最大1,000個の独立した質問を評価する。回答を1トークンずつ生成せず、候補を一度の計算で採点し、各質問は互いの結果を参照しない。通話録音とアカウント情報を併せて問い合わせを分類したり、PDF請求書と破損写真をまとめて請求内容を確認したりする。
Googleは、Gemini Notebookに届く質問に適したモデルと推論レベルを選ぶために、このAPIを使うと明らかにした。同社発表によると、日常的な質問の処理遅延を最大40%削減しつつ、複雑な作業には深い推論を行うモデルを割り当てる。
2. 回答の確率と自動処理の基準を併せて受け取る
質問形式は、はい・いいえ、固定選択肢、順序付き評価スコアの3種類だ。はい・いいえ形式は「はい」の確率を、選択形式は候補ごとの確率と最有力候補を返す。評価形式は各段階の番号にその段階の確率を掛けて合計した平均スコアを返すため、段階の間の値も出る。
信頼度スコアは、最も可能性の高い回答が正しいと推定される確率だ。較正とは、モデルが出す確率を実際の正答率に近づける考え方である。開発者は回答で処理先を決め、信頼度スコアで自動実行するかを決められる。
3. 質問をまとめて遅延と出力費用を減らす
同社発表では、モデル計算時間の中央値は50~100ミリ秒、リクエストと応答が往復する全体の遅延は150~250ミリ秒だ。複数メディアの入力と、入力・指示を併せて収める最大16Kトークンのコンテキストで測定した。Googleによると、リクエスト当たりの質問を1個から100個に増やしても遅延はほぼ一定だった。
入力100万トークン当たりの価格は0.10ドルで、出力トークン料金はない。同じ入力は質問数にかかわらずリクエスト当たり一度だけ課金され、質問ごとの指示文と基準のみが入力量に加わる。画像と動画は解像度を調整し、視覚情報量とトークン費用を調節できる。
4. 共通評価では較正誤差が最も小さかった
Googleが公開した7個の共通評価では、同社発表によるとGemini Decision 1の較正誤差が比較モデル中で最も小さかった。較正誤差は予測確率と実際の正答率のずれを示し、小さいほどよい。同じ評価の合計価格も併せて示された。
表:7個の共通評価の較正誤差と合計価格
条件:Google発表グラフの共通評価7個が対象。Gemini Decision 1はDecisions API、GPT-6 LunaはOpenAI Decisions API、Gemini 3.5 Flash-LiteはInteractions API (minimal)を使用。拒否・安全上のブロック・処理不能なリクエストは誤答として数え、全評価を分母とした。
| 項目 | 較正誤差(Top-1 ECE) | 合計価格(ドル) |
|---|---|---|
| Gemini Decision 1 | 0.0250 | 0.88 |
| TypeSafe Jev 1.14 | 0.0494 | 0.68 |
| GPT-6 Luna | 0.0721 | 0.93 |
| Gemini 3.5 Flash-Lite | 0.2104 | 4.14 |
Googleは、この評価で自社のFlash-Liteモデルと従来APIの組み合わせに比べ、費用がほぼ5分の1だと説明した。表ではTypeSafeモデルの合計価格のほうが低く、価格と較正誤差を併せて見て選択できる。
同社発表によると、Gemini Decision 1のJevBench公開評価の正解率は92.2%だった。この正解率は、拒否・安全上のブロック・処理不能なリクエストを誤答に含めた全評価に基づく。
Mind2Webの複数メディアを使う評価では、このモデルは86.2%で、TypeSafeモデルの86.8%を下回った。
When2Callでも両モデルはそれぞれ79.9%と82.0%を記録した。確率較正の強みと個別作業の正解率を併せて見る必要がある。
5. 質問を定義し、実際の入力で基準を決める
開発はGoogle AI StudioでAPIキーを発行し、PythonまたはJavaScript用のSDK 3.2以上をインストールして始められる。文書の例では、信頼度スコアが0.7以上なら自動分類し、それ以外は人に引き継ぐ。
answer = result.answers["department"]
if answer.confidence >= 0.7:
route_to(answer.choice)
else:
route_to("human_review")回答生成と文章解釈を省いて遅延と出力費用を減らす一方、質問・選択肢と自動処理の基準の設計は開発者に残る。文書は、実際の入力に正解を付けた例で基準を決め、誤って通した場合と誤って拒否した場合のコストを検討するよう案内している。
選択形式は正しい候補がなくても確率を配分するため、「その他」の項目や別途の対象範囲確認質問を設けられる。文書は、ユーザー入力が分類を誘導しうるため、攻撃意図を含む入力で試験し、支払いのような重要な処理には人や二度目の確認を置くよう勧めている。
Gemini Decisions APIの変化は、マルチモーダル判定の確率を直接コードにつなげられるようにしたことであり、自動化の品質は開発者が設計した基準にかかっている。
