問い合わせを担当部署へ振り分ける、セキュリティ警告の優先度を付ける、提出された情報が条件を満たすか確認する。企業のシステムがAIに求める答えは、いつも丁寧な説明文とは限りません。「該当するか」「どれを選ぶか」「何点に相当するか」が分かれば、次の処理へ進める場面もあります。こうした用途では、生成した文章から必要な結論を取り出す工程が、開発や運用の負担になり得ます。

Googleは2026年11月11日、限られた形式の質問に答えるAIサービス「Gemini Decisions API」を発表しました。中核となるモデルは「Gemini Decision 1」です。APIは、アプリケーションから機能を呼び出すための窓口を指します。利用者との会話画面を作る用途に限らず、既存の業務システムの中に判定機能を組み込む使い方が想定できます。



この発表で注目したいのは、AIの担当範囲を絞ることで、処理速度や費用、システムへの組み込みやすさを追求している点です。幅広い依頼に文章で応じる大規模言語モデルに対し、Gemini Decision 1が扱う質問形式は三つに限定されています。その制約は、あらかじめ選択肢や評価基準を決められる業務では、導入設計を具体化する手掛かりになるでしょう。

企業にとっての検討課題も変わります。どれだけ自然な回答を書くかに加えて、どの判断を任せ、その結果をどの処理へ渡すかを設計する必要があります。Gemini Decisions APIは、生成AIを業務の途中に置く際の選択肢として読むと、その狙いを理解しやすくなります。

Gemini Decision 1が受け付けるのは、はい・いいえで答える質問、複数の候補から選ぶ質問、利用者が指定した尺度で評価する質問です。自由な文章作成よりも、答えの取り得る範囲が決まった処理に焦点を当てています。例えば、セキュリティ担当者がウイルス対策ソフトの警告を渡し、深刻度を1から10で評価させる使い方が紹介されています。

入力には、質問と、その質問に関係するデータを含めます。データはテキストだけでなく、音声、画像、動画、またはそれらの組み合わせに対応し、最大25万6,000トークンを扱えます。トークンはモデルが情報を処理する際の単位です。文字数とは一致せず、画像や音声も対象になるため、容量を日本語の文字数だけで捉えるのは適切ではありません。



業務へ当てはめる際は、質問形式を選ぶ前に、何を判定したいかを明確にする必要があります。「この問い合わせは重要ですか」だけでは、売上への影響、緊急性、対応期限のどれを指すのか定まりません。これはモデルの能力だけで解消できる問題ではなく、企業側の基準を入力に落とし込む設計の問題です。

尺度評価でも同様です。1から10という範囲を決めるだけでなく、低い点と高い点が業務上何を意味するかを共有すると、結果を扱いやすくなるでしょう。以下は活用を考える際の一般的な設計例ですが、担当部署を選ぶ処理なら選択式、必要情報がそろっているかの確認なら二択、対応順を付ける補助なら尺度評価という対応が考えられます。形式を絞れることと、判断基準が整っていることは、分けて確認したい条件です。

一般的な大規模言語モデルは、質問に対して説明を含む文章を返します。アプリケーションがその出力を利用する際には、必要な値を取り出したり、余分な説明を除いたりする処理が必要になることがあります。Gemini Decision 1は「はい」「いいえ」などの簡潔な回答を返し、応答の正確さに対する確信の度合いを示すスコアも提示します。

このように、単純な質問に短い答えを返すことへ最適化されたニューラルネットワークは、判断モデルと呼ばれます。利点は回答の短さだけではありません。出力の形を限定できれば、受け取った値が想定した形式かどうかを確認しやすくなります。ただし、形式が正しくても内容が正しいとは限らず、構造化された回答をそのまま正解と扱うことはできません。



信頼度スコアは、出力を使うかどうかをアプリケーションが判断する材料になります。例えば、一定の条件を満たす結果は自動処理へ回し、それ以外は人の確認へ送る設計が考えられます。これは導入時の設計例であり、どの業務にも共通する適切なしきい値が示されているわけではありません。実際のデータで、スコアと正誤の関係を確かめる必要があります。

特に、見逃しと過剰な検知では影響が異なります。警告を見逃す損失が大きい業務と、担当者へ不要な確認を回す負担が大きい業務では、同じ運用基準にはならないでしょう。信頼度を使う価値は、判断を無条件に委ねることよりも、どこまで機械で進め、どこで確認を挟むかを具体的に決められる点にあります。

Gemini Decision 1の料金は、入力100万トークン当たり0.10ドルで、出力トークンには課金されません。Googleは、同社のエントリーモデルであるGemini 3.5 Flash-Liteと比べ、比較対象のベンチマーク群では費用がほぼ5分の1になると説明しています。開発者向けサービス「Google AI Studio」には、動作を試すための利用制限付き無料枠も用意されています。

処理速度について、Google DeepMindは、回答をトークンごとに生成せず、候補を採点する仕組みを説明しています。同社が示した中央値は、モデルの計算部分で50〜100ミリ秒、処理全体で150〜250ミリ秒です。ただし、説明されている条件は最大1万6,000トークンの入力で、1リクエスト当たりの質問数が1〜100の場合です。Googleの発表で確認できます。



最大入力容量の25万6,000トークンと、上記の遅延が示された入力条件は同じではありません。大きなデータを渡せるという仕様から、最大容量でも同じ時間で応答すると読み替えないことが大切です。自社の資料量や画像・音声の組み合わせで、必要な応答時間を満たすか確認する必要があります。

費用の評価でも、単価だけでは判断しきれません。どの程度のデータを毎回渡すか、判定を何回呼び出すか、結果の確認にどれだけ人手が残るかによって、業務全体の負担は変わります。低価格という特徴は、大量の判定処理を検討する入り口になるでしょう。ただし、再判定や人の確認まで含めた費用で比べると、導入後の効果を捉えやすくなります。

判断モデルの市場には、すでに複数の企業が参入しています。SiliconANGLEの報道によると、スタートアップのTypeSafe AIは9月中旬に「Jev」を公開し、数日で100万人の利用者を獲得しました。同社は公開から3週間後に8億7,000万ドルを調達し、評価額は75億ドルに達したとされています。OpenAIも10月に競合サービス「Decisions API」を投入しています。

Googleは、Gemini Decision 1をJevおよびOpenAIのサービスと比較し、九つのベンチマークのうち七つで上回ったと説明しています。ただし、費用効率ではJevがわずかに優位だったと報じられています。これらはGoogleによる比較結果として受け止める必要があり、あらゆる業務で同じ順位になることを保証するものではありません。



企業の選定では、総合的な評価順位より、自社の判断対象に合うかどうかが実務上の焦点になります。例えば、問い合わせの振り分けと画像を含む警告の評価では、入力も誤り方も異なるでしょう。共通のテストデータを用意し、同じ質問と基準で比較すれば、自社が必要とする精度と処理速度を満たすか検討できます。

市場への影響としては、汎用モデルですべてを処理する構成から、役割に応じてモデルを使い分ける構成が検討されやすくなると考えられます。説明文の作成には汎用モデル、担当先の選択には判断モデル、といった分担です。ただし、呼び出すサービスが増えれば、監視や障害時の対応も設計対象になります。単体の性能だけでなく、システム全体で扱いやすいかまで確認したいところです。

日本企業が導入を検討する際は、担当者の間で正解の基準を共有できる業務から試すと、効果を見極めやすくなります。例えば、問い合わせを既存の担当区分へ振り分ける補助や、申請に必要な情報が含まれているかの確認が候補になります。これらは活用を考えるための例であり、Googleが日本企業での導入成果を示したものではありません。

検証用のデータには、分かりやすい事例だけでなく、担当者が迷う事例も含めたいところです。日本語の略語や社内独自の呼び方、前後の文脈が必要な依頼では、短い質問だけで必要な判断材料が伝わらない可能性があります。モデルへ渡す情報を増やすか、判定対象を狭めるかを検討すると、精度の課題と業務設計の課題を切り分けやすくなります。



評価では正解率に加え、誤りの種類を記録することが有効でしょう。誤った部署へ送るケースと、判断できず確認待ちになるケースでは、現場の負担が違います。信頼度をどのように使うかも含め、担当者が修正する時間まで測れば、APIの応答が速いことと、業務が速く進むことを区別できます。機密情報や個人情報を扱う場合には、自社の利用条件に合うかという確認も欠かせません。

最初の一歩は、自社で繰り返している判定を一つ選び、その答えを二択、選択式、尺度評価のどれで表せるかを書き出すことです。続けて、正解の基準と人へ戻す条件を整理し、過去のデータで確かめます。Gemini Decisions APIの低価格や短い応答時間を生かせるかは、その小さな検証から判断するのが現実的です。