Googleが、Gemini APIに Flex と Priority という2つの新しい inference tier（推論の優先度・サービス階層）を追加しました。
ざっくり言うと、「安く回したい処理」と「安定して速く返ってほしい処理」を、APIの中で使い分けやすくする仕組みです。
これ、かなり実用的だと思います。AIアプリって、全部を同じ品質・同じ速さで動かしたいわけじゃないんですよね。裏で黙々と処理する仕事もあれば、ユーザーの目の前でサクッと返さないと困る仕事もある。そこを一つのAPIで整理しよう、というのが今回の話です。
AIアプリを作ると、処理は大きく2種類に分かれます。
これは、裏でまとめてやっておけばいい仕事です。
たとえば:
こういう処理は、多少遅くても困りません。むしろ、安く大量に回せることのほうが大事です。
こちらは、ユーザーが直接触る処理です。
たとえば:
こっちは逆で、多少高くてもいいからちゃんと速く、安定して返ってきてほしい。
1回でも遅いと、「あれ、壊れた？」となりがちです。人間は待たされるとすぐ不安になるので、ここはかなり重要です。
Googleによると、これまではこうした2種類の処理を両立させるために、
を使い分ける必要がありました。
でも正直、これは開発者にとってやや面倒です。
同期処理と非同期処理をまたぐと、設計も運用も複雑になります。ジョブ管理、結果のポーリング（完了確認のために何度も見に行くこと）、入出力ファイルの扱いなど、地味に気をつかうことが増えるんですよね。
今回の Flex / Priority は、その“分断”をまたぐための仕組みです。
Flex Inference は、コスト最適化寄りの tier です。
Googleの説明では、Latency-tolerant workloads、つまり「多少遅くてもいい処理」に向いています。
特徴はこんな感じです。
ここが面白いところで、Flexは「単に安い」だけではなく、**“安さの代わりに何を受け入れるか”がはっきりしている**んです。
AIの料金体系って、つい「安いか高いか」だけ見がちですが、実際は 速さ・安定性・運用コスト のバランスなんですよね。Flexはそのバランスを、かなり開発者フレンドリーに見せていると思います。
Googleは、次のような用途を挙げています。
要するに、人が画面を見て待っている必要がない処理です。
「すぐ返事がほしいわけじゃない、でも大量に回したい」というケースにはかなり刺さりそうです。
本文の冒頭では Priority も新設されたと説明されています。
こちらは名前の通り、優先度を高めて、信頼性や応答の安定性を重視する tier だと読めます。
詳細は今回の抽出本文では途中で省略されていますが、記事全体の文脈から見ると、Priority は ユーザー向けの重要なリクエストを安定して通したい場面で使うものです。
たとえば、
みたいな「ここで失敗すると体験が悪くなる」場面ですね。
個人的には、こういう “大事な処理には Priority、裏方は Flex” という整理はかなりわかりやすいです。
AIアプリって、ついつい全部を同じラインで流しがちですが、本当はそんな雑な作り方では持ちません。今回の発表は、その現実にかなり素直だと思います。
これまでは、用途によって同期APIとBatch APIを行き来する必要がありました。
でも Flex と Priority があれば、同じ synchronous endpoints の中で使い分けられるので、設計がかなりすっきりします。
「この処理は安くていい」「この処理は高くても止められない」という線引きができると、予算の調整がしやすいです。
AIサービスの運用で一番こわいのは、便利だからと全部高品質設定にして、請求額を見て青ざめるパターンなので……ここは現実的でありがたいです。
最近は、単発のチャットではなく、AIが裏で複数のステップをこなす agentic workflows が注目されています。
こういう処理は、全部を一律に扱うより、「考える部分はFlex」「最後の返答はPriority」のように分けたほうが設計しやすいはずです。
今回の発表は、派手な新機能というより、地味だけどかなり効く改善だと思います。
こういう機能は見た目のインパクトは小さくても、実際にプロダクトを作る人にはかなり効きます。
特に印象的なのは、Googleが「AIを使うなら、全部同じ扱いでは無理がある」とちゃんと認めている点です。
AIは魔法じゃなくて、結局はワークロードの集合体ですからね。裏方の大量処理と、ユーザーに見える即応処理を分けるのは、すごく筋がいい設計だと思います。
一方で、こうした tier が増えるほど、開発者は「どの処理をどこに載せるか」をちゃんと考える必要があります。
便利にはなるけど、雑に使えば逆に最適化の悩みが増える可能性もある。ここは、運用する側の腕が問われるところではないでしょうか。
参考: New ways to balance cost and reliability in the Gemini API
