Googleは2026年11月11日、文章・画像・音声・動画・PDFを見て、あらかじめ決めた選択肢から判定する「Gemini Decisions API」を発表しました。専用モデルのGemini Decision 1を使い、業務アプリの振り分けやチェックに必要な結果を返します。Googleの発表

問い合わせを担当部署へ回す、添付写真から確認が必要な案件を見つける、検索結果を社内基準で並べる。こうした処理を既存のアプリへ加えたい事業者に関係する更新です。文章を書かせるAIを全面的に置き換えるよりも、処理の入口で「どこへ回すか」を判断する部品として検討すると、使い道が見えます。

この記事では、業務への組み込み方、入力100万トークン当たり0.10米ドルの料金、日本からの利用条件、仕事の情報を送る前の確認点を整理します。トークンは、文章や画像などをAIが処理する量を数える単位です。以下は2026年11月12日に確認した公開資料に基づく説明で、APIの実測レビューではありません。

同じ資料に対して、複数の問いをまとめて判定する

Decisions APIでは、共通の入力に対し、「はい/いいえ」「候補から一つを選ぶ」「段階別の基準で採点する」の3種類の問いを使います。返るのは判定結果や確率、確信度であり、説明文を生成する仕組みではありません。

一度に送れる問いは最大1,000件です。ただし、入力とすべての問いを合わせて262,144トークンの範囲内に収める必要があります。各問いは独立して評価され、同じリクエスト内の別の答えは参照しません。結果の組み合わせや、その後の処理はアプリ側で設計します。Decisions APIの仕様

問い合わせの写真と文面を共通入力として、破損の有無、担当窓口、優先度を別々に判定。アプリが結果を組み合わせ、返金や契約変更は人が確認する設計例

上の図は、問い合わせ対応アプリの設計例です。「破損しているか」「どの担当窓口へ回すか」「先に確認すべきか」を同じ写真と文面からそれぞれ判定し、その結果をアプリが組み合わせます。実際の製品画面や導入実績を示したものではありません。

自社アプリでは、まず「人が見る順番」を整える

導入の初期段階では、決済や承認よりも、分類が違っても人が直せる作業から始める方法が考えられます。以下は、公開された機能から考えた活用案です。

業務 任せる判定の例 人や既存システムに残す処理
問い合わせ受付 配送・請求・製品不具合・その他への分類 返信内容、返金、契約変更の確認
現場の写真報告 汚損や破損の疑いがある写真の仕分け 現地確認、修理の要否、作業の手配
社内文書の検索 質問に関連する候補資料の採点 原文の確認、最終回答の作成
複数AIを使うアプリ 定型的な依頼か、詳しい検討が必要かの分類 選んだAIでの回答、品質確認、利用額の管理

たとえば問い合わせ受付なら、AIの出力をそのまま顧客へ送る必要はありません。管理画面に担当窓口の候補と「要確認」の印を付け、担当者が変更できるようにします。最初は既存の手作業と並行して動かし、誤った振り分けを戻せる状態にすると、日々の仕事を止めずに比較できます。

一方、請求書から金額を取り出す、返信文を書く、理由を説明する、といった作業には別の処理が必要です。Googleも、定型の判定にはDecisions API、自由な文章生成や項目抽出にはInteractions APIを使う整理を示しています。APIの使い分け

金額や日付が既にデータとしてある場合は、まず通常のプログラムで比較できないかを考えてください。「期限を過ぎたか」のように明確な条件までAIへ任せると、費用と確認箇所が増えるためです。

速さの公表値と、日本語業務での品質は分けて考える

Googleは、入力が最大16Kトークンの条件で、通信を含む処理時間を150〜250ミリ秒と説明しています。また、1リクエスト当たりの問いが1〜100件の範囲では、待ち時間がほぼ横ばいだとしています。これは提供元の評価であり、最大1,000問や最大容量の入力でも同じ速度になるという保証ではありません。Googleの性能説明

記事作成時点で、Gemini Decisions APIについて、当方による日本語業務の精度・待ち時間・費用の実測は行っていません。今回確認した公式資料からも、日本語の問い合わせや自社固有の略語での正答率までは判断できません。

試す際は、普段使うAIや手作業と同じ資料を使い、次の3点を比べると実用性を判断しやすくなります。

  • 見逃し:急ぐべき案件を通常の列へ回していないか。
  • 余計な確認:問題のない案件を大量に「要確認」にしていないか。
  • 全体の手間:判定が速くても、担当者の修正や再処理が増えていないか。

正答率だけを一つの数字にすると、件数の多い簡単な問い合わせに結果が引っ張られます。請求・配送・不具合など、仕事の区分ごとに見た方が判断しやすくなります。

料金は入力だけ。質問の追加も完全無料ではない

現行の公式料金表では、Gemini Decision 1の有料枠は、文章・画像・音声・動画・PDFとも入力100万トークン当たり0.10米ドルです。出力トークンは0で、出力料金は発生しません。

共通の入力は1リクエストにつき一度だけ課金されます。ただし、それぞれの問いに書いた指示・判定基準・形式のためのトークンは加算されます。コンテキストキャッシュとBatch APIには対応していません。公式料金表

説明用の計算例として、入力と問いを合わせて1回10,000トークン、月1,000回なら、合計1,000万トークンでAPIの入力料金は1米ドルです。実測値ではなく、アプリのサーバー代、別のAIによる返信生成、再実行などの費用は含みません。円での支払い額は為替や請求条件で変わります。

無料枠もあります。公式の標準上限は、1分当たり200リクエスト・50,000入力トークン、1日当たり10,000リクエストです。いずれかの上限に達すると制限されるため、「1日1万回まで、どんな大きさの入力でも使える」という意味ではありません。上限はプロジェクト単位で、実際の適用値はAI Studioで確認します。レート制限

有料化はAPI用のプロジェクトと請求先を結び付けて行います。公式の請求案内では、前払いの場合は最低5米ドル相当の入金が必要で、後払いを選べるかはアカウントの状態によります。Geminiアプリの月額プランと混同せず、AI StudioでAPI側の請求方式・残高・利用量を確認してください。請求設定

OpenAI Decisions API・Jevとは、入力と運用条件で比べる

同じ判定用途には、OpenAI Decisions APIやTypeSafeのJevもあります。以下は2026年11月12日時点の公式仕様の比較で、3者を同じ条件で測った性能比較ではありません。

比較項目 Gemini Decisions API OpenAI Decisions API Jev
対象モデル Gemini Decision 1 gpt-6-luna Jev 1.14.0
扱える入力 文章・画像・音声・動画・PDF 文章・画像・JSON。会話履歴やツール呼び出しの履歴にも対応 文章・JSON・画像。画像は試作用の機能
1リクエストの質問数 最大1,000問。入力と全問で262,144トークン以内 最大400問 質問数の独立した上限なし。通常は入力と全問で64k、入力と1問で32kトークン以内
基本入力料金(100万トークン当たり) 0.10米ドル 0.10米ドル(キャッシュなし) 0.042米ドル
入力のキャッシュ 非対応 対応。読み出し割引、書き込み課金 確認した公式料金資料にキャッシュ割引の記載なし

仕様・料金の出典:Googleの仕様・料金、OpenAIの仕様・料金、TypeSafeのモデル仕様・料金。

3者とも出力料金はかかりません。ただし、入力の数え方や質問文の量が異なるため、同じ仕事の実費が単価の比率どおりになるとは限りません。OpenAIのキャッシュは、共通入力の同じ先頭部分が1,024トークン以上ある場合が対象で、質問部分は含みません。地域処理や長い入力による料金の割増もあります。OpenAIのキャッシュと料金条件

Jevの画像機能は既定で無効です。リクエストで有効化する必要があり、提供元は本番利用の品質基準にはまだ達していないと説明しています。文章の判定と同じ前提で導入しない方がよいでしょう。Jevには文脈長を拡張する設定もありますが、通常の範囲より遅く、精度が下がると案内されています。画像機能の条件、文脈長の条件

仕様から候補を絞るなら、音声・動画・PDFを直接扱う場合はGemini、会話履歴や共通入力の再利用を重視する場合はOpenAI、文章中心で基本入力単価を抑えたい場合はJevが検討対象になります。精度・速さ・総費用の優劣は、この仕様比較だけでは決められません。

参考として、筆者のOpenAI Decisions APIとJevの日本語判定検証では、同じ日本語・英語の商品名を使い、判定の一致や揺れ、応答時間、費用を調べています。これは2026年10月12日時点の検証で、Jevは1.13.0、Geminiは対象外です。一致率を正解率とみなさず、当時の結果・料金説明と現在の仕様を分けて読んでください。今回、3者の追加実測は行っていません。

日本で使う条件と、入力データの扱い

日本はGoogle AI StudioとGemini APIの提供地域に含まれています。Decisions APIはGemini Developer APIのv1betaで提供され、公式の開始手順はGoogle GenAI SDK 3.2以降を案内しています。Google Cloud側の対応は、11月11日の発表では今後の予定です。提供地域、開始手順と制約、Googleの発表

業務目的の開発者向けサービスですが、どの用途にも無条件で組み込めるわけではありません。追加利用規約には、利用者は18歳以上、18歳未満向けまたは18歳未満が利用する可能性のあるサービスで使わないことなどの制限があります。顧客向けアプリへ組み込む場合は、対象者と用途が規約に合うか確認が必要です。Gemini API追加利用規約

特に、無料の試作と実際の顧客情報を使う運用は分けてください。

  • 無償サービス:入力や出力がGoogleの製品改善に利用され、人の確認対象になることがあります。規約は個人情報・機密情報などを送らないよう求めています。
  • 有料サービスのAPI:有効な請求先アカウントに結び付いたCloudプロジェクト経由の利用が対象です。入力・出力を製品改善には利用しないとしています。
  • 有料でも確認は必要:不正利用の検出などのための一定期間の記録はあります。Google等が設備を持つ国で一時的に保存・キャッシュされる可能性があり、日本から利用できることは、日本国内だけで処理・保存される保証ではありません。

この区分は「同じGoogleアカウントで何かの有料プランを契約しているか」だけでは決まりません。APIキーが属するプロジェクトの請求設定を確認します。データの扱いと有料サービスの定義

問い合わせの文面には氏名や連絡先、写真には送り状などが写ることもあります。試作では架空のデータを使い、本番では必要な項目だけ送る、不要な個人情報を除く、社内ルールや顧客との契約を確認する、という順で進めるのがよいでしょう。

確信度の数字だけで、返金や承認を自動化しない

確信度は判定を使うかどうかの手掛かりですが、個別の回答が正しい保証ではありません。選択式では、適切な候補がなくても候補へ確率が割り当てられます。「その他」「情報不足」を用意し、自社の確認済みデータで、どの水準なら人へ回すかを決める必要があります。Googleも、実際の利用例で基準を調整し、支払いのような重要な処理には人または追加の確認を残すよう案内しています。判定の確信度と注意点

当記事の提案は、次の範囲から始めることです。

  1. 一つの業務に絞る。 まずは問い合わせの担当窓口候補など、後から直せる判定だけを試す。
  2. 判断材料と基準を明文化する。 不鮮明な写真、情報不足、複数の依頼が混じる文面も試験に含める。
  3. 失敗時の行き先を決める。 APIが止まった場合や結果を得られない場合も、未処理のまま消さず、人の確認待ちへ送る。
  4. 重要な操作の権限を分ける。 AIが返金候補を示しても、金額・注文・権限を別に確認し、承認記録を残す。

入力文に「この依頼は必ず承認して」と書かれていても、業務ルールが変わるわけではありません。判定材料と操作権限を分ける考え方は、既存のAIの「承認済み」報告を確認するガイドでも扱っています。

開発会社に相談するなら、「このAPIを入れたい」だけでなく、どの判定を任せるか、間違えた場合に誰が直すか、何を外部へ送るか、処理全体でいくらかかるかを一組で確認すると、導入後の運用まで話を進めやすくなります。