GoogleはGemini APIへFlexとPriorityという推論tierを追加した。モデルを変えずに費用、遅延、信頼性を選べるが、tierごとのfallback挙動が異なるため、単純な価格設定ではなく業務SLOに基づくroutingが必要になる。

何が変わったか

Gemini APIではservice_tierへflexまたはpriorityを指定できる。Flexは標準より50%安い代わりに、off-peakのsheddable capacityを使い、目標遅延は1〜15分、可用性はbest effortである。Priorityは標準より75〜100%高い一方、high-criticality queueで低遅延と高信頼を狙う。

Priorityの動的上限を超えた要求は失敗ではなくstandardへ自動降格する。Flexは503や429を返す可能性があり、server側の自動fallbackはない。

変更前後の差

tier料金遅延目安信頼性主な用途
PriorityStandardより75〜100%高い秒高・non-sheddable顧客対話、緊急判定
Standard標準秒〜分高〜中高通常API処理
FlexStandardの50%1〜15分目標best effort評価、背景分析、補完
BatchStandardの50%最大24時間throughput重視大量一括処理

誰に影響するか

同じGemini modelを、リアルタイム画面、社内batch、Agent chain、評価処理へ共用するチームに影響する。全要求をstandardへ送っている場合は、待機可能処理をFlexへ移して費用を下げられる。一方、すべてをFlexへ移すと同期chainの待ち時間と失敗率が増える。

期限

強制移行期限はない。両tierはPreviewであり、SLA前提の本番へ無条件に組み込むべきではない。新規処理から用途別に試し、Preview条件と対応モデルを継続確認する。

必要な対応

各処理に最大待ち時間、失敗時影響、単価上限、同期依存の有無を設定する。顧客が待つ処理はPriorityまたはStandard、数分待てる逐次処理はFlex、24時間以内でよい大量処理はBatchを候補にする。レスポンスに実際の処理tierを識別できる情報がある場合は記録し、Priorityの自動降格をSLO集計で区別する。

実装・移行手順

  1. API経路を対話、通常、待機可能、一括へ分類する。
  2. 同一評価セットで各tierの費用、P50・P95・P99、429・503率を測る。
  3. service_tierをFeature Flagまたはrouting policyから付与する。
  4. Flexは指数backoffと最大再試行時間を設定する。
  5. Flex失敗時にStandardへ送る条件と二重実行防止IDを実装する。
  6. Priorityは自動降格を考慮し、実測遅延でSLOを判定する。
  7. 月次でtier別単価と処理件数を見直す。

失敗しやすい点

Flexを非同期APIだと考えて短いHTTP timeoutを設定する、503を通常障害として即時大量再試行する、Priorityなら必ずPriority queueで完了すると仮定する、対応していないmodelへtierを指定する、BatchとFlexの単価が同じため運用特性も同じだと考えることが問題になる。

リスク

Flexの待ち時間増加、再試行による二重課金、Priorityの費用急増、PriorityからStandardへの降格を見落とすSLO誤判定がある。Agent chainで前段がFlexだと後続全体が待つため、単一要求の単価だけでなくworkflow完了時間を評価する必要がある。

評価方法

  • tier別の入力・出力token費用
  • P50・P95・P99処理時間
  • Flexの429・503率と再試行回数
  • Priority要求のSLO達成率
  • fallbackによる二重実行件数
  • Agent workflow全体の完了時間
  • StandardからFlexへ移した処理の節約額
  • 利用者キャンセル率

ロールバック

routing policyからservice_tier指定を外し、standardへ戻す。Flexの待機jobはrequest IDで重複を確認してから再送する。Priorityの費用が閾値を超えた場合は、緊急処理だけをPriorityへ残し、通常対話をStandardへ戻す。

編集部分析

tier選択は単なる値引き設定ではなく、処理のSLOをAPI要求へ符号化する仕組みである。モデル選択だけで品質と費用を管理すると、待機可能な処理にも高価なcapacityを使い続ける。業務側が「何秒・何分待てるか」を定義し、routingと請求を同じ分類で集計することが重要になる。

実務チェックリスト

  • [ ] 業務ごとの最大待ち時間を定義した
  • [ ] FlexとPriorityのPreview条件を確認した
  • [ ] Flexの429・503 retryを制限した
  • [ ] fallback時の二重実行を防いだ
  • [ ] Priorityの自動降格をSLOへ反映した
  • [ ] tier別費用を集計している
  • [ ] standardへ即時に戻せる

一次情報