Google DeepMind が放つ AI エージェント向け新モデル3種

一行に凝縮するなら、こうです。 安価な一次ルーティングには Gemini 3.5 Flash-Lite、メインのエージェント作業には Gemini 3.6 Flash、自社システム上で動かす必要があるときは Gemma 4 を使う。

短くまとめます。この記事は 3 つのモデルを、AI エージェントにとって最も重要なポイント、すなわちレイテンシ、コスト、ツール利用、マルチモーダル入力、プランニング、デプロイ制御で比較します。1 つは大量トリアージ向け、1 つは日常の実行向け、そして 1 つはセルフホストおよびプライベートなワークロード向けに作られています。

私が最も注目した点はこちらです。

• Gemini 3.5 Flash-Lite は分類・抽出・ルーティングのための低コストなトラフィック分配器で、200 ms 未満のレイテンシ
• Gemini 3.6 Flash は中間に位置し、ツール呼び出し、ドキュメント作業、ワークフローステップの主力として約 500 ms のレイテンシ
• Gemma 4 はトレードオフをオープンウェイト、Apache 2.0 ライセンス、ローカルデプロイ、プライベートなデータ処理の方向へシフト
• Gemma 4 は 2.3B から 31B パラメータまで揃い、最大 256K コンテキストに対応
• 26B A4B MoE バージョンは推論時に 25.2B のうち 3.8B パラメータを活性化
• 階層型の構成なら、単純なタスクを小型モデルに任せ、難しいケースを大型モデルに送ることで支出を抑えられる

素早く選ぶなら：
ルーティングには Flash-Lite、実行には Flash、セルフホスト制御には Gemma 4 を選びましょう。

Google の 3.6 Flash が証明する、AI エージェント低価格化の到来

クイック比較

言い換えれば、これは「最強」の 1 モデルを選ぶ話ではありません。統一 LLM API を使って各モデルを仕事にマッチさせ、エージェントスタックを高速かつコスト意識の高い状態に保ち、必要な部分では自分の管理下に置く、という話です。

1. Gemini 3.6 Flash

エージェントワークロードへの適合性

3 モデルの中で、Gemini 3.6 Flash はスループット最優先の選択肢です。低レイテンシ、安定したコスト、素早いターンアラウンドを必要とする大量処理エージェントに使いましょう。

レイテンシとスループット

そのため、チケットのトリアージ、ドキュメント検索、大規模なタスクルーティングといったリクエストの多いフローによく合います。こうした場面では、モデルが安定して頼れる動きをすることが求められるからこそ、速度が最も重要になります。

ツール利用とカスタマイズ

function calling、検索、ポリシーチェック、人間による承認ステップと組み合わせて、自動化を制御下に置けます。たとえば、リクエストを読み、ソースドキュメントを引き出し、ツールを呼び出し、エッジケースを人間に送るエージェントに向いています。

次の Gemini 3.5 Flash-Lite は、トレードオフをより軽量で低コストのエージェントタスク側へシフトさせます。

2. Gemini 3.5 Flash-Lite

エージェントワークロードへの適合性

Gemini 3.5 Flash-Lite は、大量の分類・抽出・ルーティングのためのデフォルト低コストモデルです。エージェントスタックにおける軽量な制御レイヤーと考えてください。トラフィックの大部分を処理し、難しい判断には大型モデルが介入します。

レイテンシとスループット

200 ms 未満のレイテンシにより、ファンアウト型ワークフロー、バッチ処理、高速ルーティングに強く適合します。エージェントシステムが 1 つの大きなジョブを多数の小さなタスクに分割するとき、Flash-Lite はそれらのサブタスクを素早く片付け、結果を統合のために送り返せます。

コストとデプロイモデル

その低コストゆえに、単純なタスクの大きなキューに対する既定の一次モデルとなります。デプロイ制御とオープンウェイトの方がこの構成より重要なら、Gemma 4 がそのトレードオフをシフトさせます。

ツール利用とカスタマイズ

Flash-Lite は、ルーティングと抽出のための構造化出力と軽いタスクチューニングをサポートします。よくあるパターンはシンプルです。Flash-Lite を一次の分類器または抽出器として使い、エッジケースだけをより強力なモデルに送ります。そうすることで、大規模なエージェントは重いモデルをプランニング、マルチモーダル推論、困難な例外処理のために温存できます。

3. Gemma 4

エージェントワークロードへの適合性

Gemma 4 は、ローカルで動かし、機微なデータを扱い、チューニングしやすい状態を保つ必要があるエージェントスタック向けの制御最優先の選択肢です。Apache 2.0 ライセンスにより、チームはファインチューニングしてローカルシステムにデプロイでき、厳格なデータガバナンスルールを持つ規制対象またはオフラインの環境に適合します。また、データがローカルシステムを離れる前に入口で PII をマスキングできるため、医療や金融のチームには便利です ^[1]。

これが重要なのは、ローカル制御がプライバシーだけの話ではないからです。モデルをどこまでチューニングできるか、どこで動かすか、どんなワークロードを扱えるかを決めることでもあります。Gemma 4 では、それはモデルサイズ、コンテキストウィンドウ、ランタイムコストに帰着します。

レイテンシとスループット

Gemma 4 は 2.3B のモバイルモデルから 31B のサーバーモデルまで揃っています。これにより、1 つのモデルにすべてを強いるのではなく、モデルを仕事に合わせる余地がチームに生まれます。小型モデルはエッジタスクを、大型モデルはプランニングや長コンテキストの推論を担えます。

ここで目立つのは 26B A4B MoE バリアントです。推論時には 25.2B のうち 3.8B パラメータを活性化し、ランタイムの効率維持に貢献します。コンテキスト長については、小型モデルが 128K トークン、12B・26B A4B・31B モデルが 256K トークンをサポートします。長いドキュメントや長いエージェントトレースにぴったりです ^[1]。

コストとデプロイモデル

Gemma 4 を自前のハードウェアで動かせばトークン単位の API 料金は消えますが、請求がゼロになるわけではありません。コストはサーバー、スケーリング、稼働維持に移ります。つまりプロバイダーに支払う代わりに、モデルの背後にあるスタックに支払うことになります。

Gemma 4 は、メモリ使用量を削るいくつかの方法もチームに提供します。Quantization-Aware Training（QAT）チェックポイントが GGUF、モバイル最適化の wNa8o8、Compressed Tensors w4a16 の各フォーマットで利用可能です。これらは出力品質を bfloat16 に近く保ちながらメモリ要件を下げられます ^[1]。

この構成により、エージェントにローカル制御と構造化された実行が必要で、それに伴うインフラをチームが管理する準備ができているとき、このモデルは強力な選択肢になります。

ツール利用とカスタマイズ

Gemma 4 はネイティブな function calling とネイティブなシステムロールをサポートし、エージェント開発者に会話フローとタスク実行へのより直接的な制御を与えます ^[1]。また transformers、vLLM、llama.cpp で動作するため ^[1]、多くのチームがすでに使っているスタックに組み込めます。

Unified 12B バリアントは、画像と音声の入力を直接受け取れます。テキスト・画像・音声の入力にまたがる単一のファインチューニング経路を必要とするマルチモーダルエージェントに有用です ^[1]。

Gemma 4 には組み込みの「Thinking」モードもあります。難しいタスクでは役立ちますが、レイテンシが増えます。平たく言えば、プランニングや複雑な推論に使い、高速ルーティングには使わないこと ^[1]。つまり Gemma 4 は制御に大きく寄っている一方、その制御にはインフラの要求と速度のトレードオフが伴います。

トレードオフ・統合オプション・メリットとデメリット

これらのモデルをスタックとして見ると、かなりきれいに 3 つの仕事に分かれます。トリアージ、実行、ローカル制御です。

つまり主な判断は「どのモデルが最強か」だけではありません。1 つのモデルにすべてを任せるか、それとも各モデルが最も得意な部分を担う階層型の構成にするか、です。

階層型アーキテクチャは、複雑なエンタープライズ規模のエージェントに最も適合しやすい構成です。Flash-Lite は最も低いレイテンシとコストで大量のトリアージとルーティングを担えます。Gemini 3.6 Flash はコアなワークフロー実行、ツール利用、長コンテキスト作業を処理できます。Gemma 4 は、セルフホストまたはプライベートクラウドのデプロイを必要とする規制対象・プライベートなワークロードに適合します。

このように使えば、チームはすべてのリクエストを 1 つの高性能モデルに送る場合と比べて、意味のある形でコストを削減できます。その時点でトレードオフはこう変わります。デプロイ制御 vs 運用のシンプルさです。

テキスト推論の外にある画像や動画の生成については、APIMart が単一のマルチモーダル API を通じてタスクをルーティングできます。

以下の表は主な統合パスをまとめたものです。

実務では、これらのトレードオフはかなりシンプルな選択を形作ります。1 つのモデルをエンドツーエンドで使うか、ルーティング・実行・プライベートワークロードを別々のレイヤーに分けるか、です。

結論

適切なモデルは 3 つの要素で決まります。タスクの複雑さ、予算、デプロイ制御です。

このレンズで見ると、軽量なルーティングの第一候補は Gemini 3.5 Flash-Lite です。大量のルーティングと抽出の仕事によく適合します。分類、抽出、一次ルーティングに使いましょう。仕事により多くの連携が必要なら、Gemini 3.6 Flash にステップアップします。

Gemini 3.6 Flash は、本番エージェントのデフォルトの実行レイヤーとして機能します。Flash-Lite の低コストと Gemma 4 の制御最優先デプロイの間に位置し、スケール時に強い出力を求めるチームの堅実なデフォルトになります。デプロイ制御が最重要なら、Gemma 4 がより良い適任になります。

Gemma 4 は、制御、プライバシー、オフラインアクセスを必要とするチームのために作られています。オンデバイスまたはセルフホストの処理とローカルでの PII マスキングをサポートするため、規制環境に適合します。オープンウェイトはドメイン特化のファインチューニングも簡単にします。

ルーティングには Flash-Lite、実行には Gemini 3.6 Flash、セルフホスト制御には Gemma 4 を使いましょう。

FAQs

階層型モデル構成はいつ使うべきですか？

アプリの成長に伴い、パフォーマンス、コスト、信頼性のバランスを取る必要があるときに階層型モデル構成を使ってください。

基本の考え方はこうです。単純で大量のタスクは低コストモデルに送り、フロンティアモデルは複雑で重要度の高い仕事のために取っておく。

この振り分けは API コストを 60%〜80% 削減できます。特に、軽量モデルが信頼度の閾値を満たせなかった後にのみリクエストをエスカレーションする場合に有効です。

かなりシンプルなトレードオフです。最先端のモデルにあらゆる定型タスクを処理させる必要はありません。まず軽量モデルに一次対応させ、仕事が求めるときだけ重量級モデルを投入しましょう。

Gemini 3.6 Flash と Gemma 4 はどう選べばいいですか？

最も重視するものに基づいて選んでください。速度か、スケールか、制御か。

Gemini 3.6 Flash は、低レイテンシ・大量処理タスクのために作られた高性能マルチモーダルモデルです。リアルタイムアプリやコスト重視のワークフローに強く適合します。

Gemma 4 は、ローカルデプロイや自社インフラでのモデル実行など、より多くの制御と柔軟性を求めるなら理にかなっています。高速でスケーラブルな本番運用には Gemini 3.6 Flash を。プライベートなオンデバイス利用やカスタムファインチューニングには Gemma 4 を選びましょう。

Flash-Lite に最も適したエージェントタスクは？

Flash-Lite は、深い推論よりも効率が重要な、大量かつコスト重視の仕事によく合います。特に基本的なデータ抽出と分類が得意です。

モデルカスケードの第一層としても優秀です。多くの構成で、難しいクエリをプレミアムモデルに送る前に、リクエストの 70%〜85% を処理できます。標準的なエージェントワークフローを安定させたまま、コストを 60%〜75% 削減できる可能性があります。