Google、Gemini APIにFlexとPriorityを追加——生成AIの推論を「安く流す」か「確実に通す」かをAPIで選べるようになった

Googleが4月2日、Gemini APIにFlexとPriorityの2つのservice tierを追加した。ぱっと見では料金メニューの拡張に見えるが、実際にはもう少し大きい話だと思う。

AIアプリの設計は、この1年でかなり複雑になった。ユーザーと会話するフロントの推論もあれば、裏側で長く考えさせるジョブもある。検索や要約やデータ整理のように、多少遅くても安く回したい処理もあるし、サポートチャットや審査のように、多少高くても落ちてほしくない処理もある。

これまでは、その差を吸収するためにBatch APIを混ぜたり、アーキテクチャを分けたりする必要があった。Googleは今回、その分岐を同じ同期APIの中で service_tier という1つのパラメータで切り替えられるようにしてきた。これは地味に大きい。

何が起きたか

今回追加されたのは、既存のStandardに加えて使えるFlexとPriorityの2つだ。

Flexは、レイテンシと信頼性を少し譲る代わりに、標準より最大50%安く使えるコスト最適化ティアとして位置づけられている。Googleは、CRM更新、大規模なリサーチシミュレーション、バックグラウンドで考え続けるエージェント処理などを主な用途として挙げている。

一方のPriorityは、重要なトラフィックを落としにくくする高信頼ティアだ。ピーク時でも優先的に処理し、もし契約上のPriority枠を超えても、リクエストを失敗させずStandardへ自動で落として処理する。レスポンスには実際にどのティアで処理されたかが返るので、計測や課金の把握もしやすい。

Googleがこの2つを押し出す理由ははっきりしている。AIアプリがチャット一発の世界から、エージェントが裏で複数段階の処理を走らせる世界へ移ったからだ。全部を同じ価格・同じ信頼性で流すと、どこかで非効率が出る。

Flexは何を変えるのか

Flexの本質は、単に「安いプラン」ではない。同期APIのまま、バックグラウンド向けの経済性を手に入れられることが大きい。

これまで、ユーザーを待たせなくていい処理を安く回したいなら、非同期のBatch APIへ寄せるのが自然だった。ただ、Batchには入出力ファイル管理や完了待ち、ポーリングなどの運用コストがある。処理量が多いほど効率はいいが、アプリ実装は確実に重くなる。

Flexはそこをかなり崩している。Googleは「同期のシンプルさ」と「Batchに近い経済性」の間を埋めるものとして説明している。要するに、大量だが急がない仕事を、アプリ本体の設計をあまり変えずに安くできる。

たとえば、記事の自動タグ付け、問い合わせ履歴の後処理、非同期の調査エージェント、夜間バッチに近い補助推論、ログの要約、営業データの補完といった用途はFlexと相性がいいはずだ。人が画面の前で待っていないなら、少し遅くても安いほうが合理的な場面は多い。

Priorityは何を変えるのか

Priorityの価値は、性能向上というより事業上の予測可能性にある。

本番のチャットボット、リアルタイムの顧客対応、モデレーション、時間制約のあるワークフローでは、「たまに遅い」や「混んだ時間に落ちる」がそのまま体験劣化になる。そこでは1リクエストの単価より、必要なときに通ることのほうが重要になる。

GoogleはPriorityを、最も高いcriticalityを持つティアとして説明している。しかも上限超過時にStandardへグレースフルダウングレードする。これはかなり実務的だ。完全失敗に比べれば、品質や待ち時間が少し悪化してもサービス継続できるほうが圧倒的にマシだからだ。

アプリ運用側から見ると、Priorityは単なるプレミアム課金ではなく、SLO設計のための部品として使える。ユーザー向けの重要経路だけPriorityへ寄せ、それ以外はStandardやFlexへ逃がす、という構成が作りやすくなる。

なぜこのアップデートが重要なのか

ここからは僕の見方だけど、今回の本質はGoogleがAI推論を3階層に分けて売り始めたことにある。

• ふつうに使うならStandard
• 遅れてもよい仕事はFlex
• 落としたくない仕事はPriority

この整理は、SaaSの料金プランというより、AIシステムの内部キュー設計に近い。つまりGoogleは「モデル性能」だけでなく、「その推論をどう流すか」までAPI商品として切り出し始めた。

エージェント化が進むと、1つのユーザー操作の裏で複数の推論が走る。中には重要なものとそうでないものが混ざる。全部を同じ扱いにすると、コストも信頼性も最適化しにくい。今回のservice tierは、その問題にかなり素直に効く。

実務でどう設計するとよさそうか

実装イメージとしては、処理を次の3種類に分けると分かりやすい。

1つ目は、ユーザーが待っているリアルタイム処理だ。ここはPriority候補になる。チャット応答、本人確認、通報判定、一次対応などが入る。

2つ目は、ユーザーが待つが、そこまで厳密でなくてよい処理だ。ここはStandardで十分な場面が多い。一般的な補助チャットや社内ツールの会話などが当てはまる。

3つ目は、裏側で回る大量処理だ。ここはFlex候補になる。要約の再生成、社内ナレッジ整理、データ更新、調査エージェントの下処理などが典型だ。

この整理をアプリ側のルーティングルールとして持つだけで、コスト構造がかなり見えやすくなるはずだ。しかも今回はすべて同期APIの延長で扱えるので、アプリの責務を必要以上に増やさずに済む。

注意点

もちろん、Flexが万能というわけではない。Google自身が明示している通り、Flexは低いcriticalityを前提にしたティアで、遅延や信頼性の面でStandardより劣る。ユーザーの目の前に出る処理へ無差別に入れると、体験が崩れる可能性が高い。

Priorityにもコストがあるし、現時点ではTier 2 / 3の有料プロジェクト向けに提供される。つまり、全アプリが今日から自由に使えるわけではない。あくまで本番運用の重みを持つチームに向いた機能だ。

まとめ

Gemini APIのFlexとPriorityは、単なる料金オプション追加ではなく、AI推論を仕事の重要度ごとに流し分けるためのAPI設計だと見ると分かりやすい。

エージェント時代のアプリは、「どのモデルを使うか」だけでなく、「その推論をどのティアで処理するか」を考える必要が出てくる。今回のGoogleの更新は、その運用現実をかなり正面から取り込んだものだ。コスト最適化と信頼性設計を分けて考えたい開発チームにとっては、かなり実務的なアップデートだと思う。

出典

• New ways to balance cost and reliability in the Gemini API — Google, 2026-04-02
• Gemini API pricing — Google AI for Developers
• Interactions API documentation — Google AI for Developers