何が起きたか

Googleが2026年4月2日、Gemini APIに新しいサービスティア「Flex Inference」と「Priority Inference」を追加した。これまで「バッチ処理か通常APIか」という二択だった開発者の選択肢に、より細かい粒度のコスト・信頼性コントロールが加わることになる。

シンプルに言えば「安さ優先のFlex」と「信頼性最優先のPriority」の2レーンを用意して、同じエンドポイント（service_tierパラメータ1つ）で切り替えられるようにした、というアップデートだ。

技術的な中身を整理する

Flex Inference ── 標準APIの半額、ただし遅延あり

Flex Inferenceはレイテンシ許容型ワークロード向けの低コストティアだ。価格は標準APIの50%オフ。

ポイントは「バッチAPIと違い、同期エンドポイントをそのまま使える」こと。従来のバッチAPIは入出力ファイルを管理してポーリングで結果を取りに行く非同期設計だったが、Flexは通常のAPIコールと同じ使い方でコストだけ下げられる。代償はリクエストの優先度が下がることによる遅延増加とやや低い信頼性だ。

適するユースケース：

  • CRMのバックグラウンドデータ更新
  • 大規模リサーチのシミュレーション
  • エージェントの「思考」や「ブラウジング」ステップ（即時応答不要なもの）

設定はリクエストパラメータに "service_tier": "flex" を追加するだけ。すべての有料ティアで利用可能。

Priority Inference ── ピーク時も落とさない最高信頼性

Priority Inferenceは逆に最高優先度保証のプレミアムティアだ。ピーク負荷時も他のリクエストに割り込まれない。

「Graceful downgrade」と呼ばれる設計が面白い。Priorityの割当上限を超えたトラフィックは失敗せず自動的にStandardティアへフォールバックする。アプリが落ちるより、少し遅くなっても継続する方が多くのケースでユーザー体験として正しい。レスポンスにはどのティアで処理されたか明示されるので、課金や性能の把握も容易だ。

適するユースケース：

  • リアルタイムカスタマーサポートBot
  • ライブコンテンツモデレーションパイプライン
  • 時間的制約のある処理全般

こちらはTier 2/3の有料プロジェクト向け。

実務への影響 ── 日本のエンジニア・IT管理者にとっての意味

このアップデートで実務的に変わるのは主にAIアーキテクチャのシンプル化とコスト最適化の粒度だ。

これまでGemini APIで大量処理と対話処理を両立しようとすると、バッチAPIと通常APIで別々の実装・ジョブ管理が必要だった。今後は service_tier パラメータ1つで経路を分けられる。コードベースの複雑度が下がるのは素直に良い設計だ。

コスト面では、非同期でよいバックグラウンド処理をFlex Inferenceに移行するだけで料金を半額にできる。AIエージェント系のワークロードは「考える」ステップが多く、そのほとんどは即時応答不要なのでFlexとの相性がいい。すでにGemini APIを使っているプロジェクトは、移行コスト試算から着手する価値がある。

実務でのアクションポイント：

  1. 既存のAPIコールを「即時応答が必要か否か」で分類する
  2. バックグラウンド系は service_tier: flex に切り替えてコスト比較
  3. 対話系・SLA重要系は service_tier: priority（Tier 2/3のみ）の検討
  4. レスポンスのティア情報をログに残してコスト可視化

筆者の見解

技術的には悪くない。同一エンドポイントで粒度の細かいコスト・信頼性制御ができるようになるのは、API設計として正しい方向だ。「バッチか通常か」の二択しかなかった頃よりずっとマシになった。

ただ、率直に言う。Googleのgenerative AI領域での実務信頼性は、筆者の中ではまだかなり低い位置にある。

画像生成はぴか一だと思っているし、インフラの規模感はさすがだ。だが実際のコーディング支援・エージェント系タスクにおいて、現時点でGeminiをメインに使おうとは全く思えていない。このFlexとPriorityのアップデートも、「Googleがまた面白い機能を出した」というよりは、「他社APIに比べてユーザーが少ない中で、価格で差別化しようとしている」という印象が正直なところだ。

とはいえ、こういう動きはAPI市場全体に良い影響を与える。価格競争は開発者にとってはありがたい。GeminiのFlexが普及すれば、他社もコスト最適化ティアの導入を迫られる。その恩恵を間接的に受けるのは我々ユーザーだ。

Geminiを本番で使うかどうかはプロジェクトの要件次第だが、コスト優先のバックグラウンド処理でGemini Flexを「安い選択肢」として組み合わせる戦略は十分あり得る。ひとつのプロバイダーに全賭けせず、ワークロードごとに最適な選択をする時代になっている。Flexはその「安い引き出し」として使える可能性がある。

がんばれGoogle。実務での実績がさらに積み上がれば、有力な選択肢になるポテンシャルは十分にある。

出典: この記事は New ways to balance cost and reliability in the Gemini API の内容をもとに、筆者の見解を加えて独自に執筆したものです。