Gemini 3.8移行で請求が膨らむ前に、thinkingを3段階で試す
Gemini 3.8 Flashへ安全に移行するには、現行モデルとの比較に加え、同じ評価セットをlow、medium、highの3段階で実行する。モデルIDを置き換えるだけでは、既定値であるmediumが品質、遅延、トークン消費に与える影響を切り分けられない。
各実行では、タスク成功率、P95遅延、入力・出力トークン、ツール呼び出し回数、リクエスト失敗率を記録する。2026年中の導入価格と2027年1月以降の標準価格で費用を別々に計算すれば、試験時には予算内でも価格改定後に請求が膨らむ構成を本番投入前に見つけられる。
同じ評価セットで比較条件を固定する
Gemini 3.8 Flashの公式解説 によると、モデルIDはgemini-3.8-flashで、thinking levelはlow、medium、highに対応し、mediumが既定値である。長時間の複雑なタスクでは、小さな推論ステップ、反復的なツール利用、結果の検証によってトークン使用量が増える場合もあるため、応答本文の長さだけで費用差を判断してはいけない。
評価セットには、本番処理を代表する短い分類や抽出だけでなく、長いコンテキスト、複数回の関数呼び出し、失敗時の再試行を伴うタスクも含める。生成結果に唯一の正解がない場合は、必須項目、禁止事項、ツール実行後の状態など、採点可能な成功条件を先に定義する。
実験群は現行モデルとGemini 3.8 Flashのlow、medium、highとし、入力、システム指示、ツール定義、会話履歴、タイムアウト、再試行方針をそろえる。外部APIや時刻によって結果が変わる処理では、その応答と実行時刻も保存し、モデル設定の差と外部要因を分離する。
品質試験の前にAPI互換性を確認する
移行用ブランチではモデルIDをgemini-3.8-flashへ変更し、thinking_levelを明示する。既定値に任せず構成として保存しておけば、試験結果、本番設定、ロールバック対象を対応付けられる。
Google Cloudの移行ガイド では、3.7 Flashまたは3.6 Flashから移行する際、整数のthinking_budgetを文字列のthinking_levelへ置き換えるよう案内している。有効値はLOW、MEDIUM、HIGHで、MINIMALはエラーになる。temperature、top_p、top_kはバックエンドで無視され、candidate_count、frequency_penalty、presence_penaltyはエラーになるため、旧コードから取り除く必要がある。
会話履歴も回帰試験の対象にする。履歴をmodelロールで終える形式と、モデル応答をあらかじめ埋める形式は非対応で、空のターンは削除されるか検証エラーになる。さらにFunctionResponseは直前のFunctionCallとID、名前、実行数を一致させなければならないため、品質比較へ進む前にリクエスト検証テストで互換性エラーを除く。
low、medium、highを同じ採点表で走らせる
実行順はlow、medium、highとし、各段階の役割を分ける。lowで必要最低限の品質と遅延を測り、mediumで既定設定による増分を確認し、highでは難しいタスクに限って改善幅と追加使用量を見る。
- low：分類、定型抽出、短い要約など、遅延と処理量を重視するタスクを評価する。許容する成功率を下回ったタスクをmediumの検討対象にする。
- medium：評価セット全体を実行し、既定設定での品質、遅延、使用量を基準値にする。lowから品質が改善しないタスクは、推論量を増やす対象から外す。
- high：mediumで失敗した多段推論やツール連携を中心に試す。成功率が上がっても、P95遅延、トークン、ツール呼び出し回数が上限を超えるなら採用しない。
記録表には、run_id、task_id、model_id、thinking_level、成功・失敗、失敗理由、開始・終了時刻、総遅延、入力・出力トークン、ツール別呼び出し回数、HTTPステータス、再試行回数を持たせる。P95遅延は全タスクを混ぜた値だけでなく、短い同期処理、長文処理、エージェント処理など、待ち時間要件の異なる群ごとに集計する。
ツール呼び出し回数が増えると、モデルのトークンだけでなく、外部サービスの料金、待ち時間、失敗機会も増え得る。成功率が同じなら呼び出しの少ない設定を優先し、回数と成功率がともに増えた場合は、追加費用に見合う業務上の改善かを判定する。
2026年と2027年の単価で二重に試算する
Gemini Developer APIの料金表 では、Gemini 3.8 FlashのStandard有料枠は2026年12月31日まで入力100万トークン当たり0.75ドル、thinking tokenを含む出力が3.75ドルである。2027年1月1日からは入力1.50ドル、出力7.50ドルとなり、どちらも2倍になる。
Standardでの各実験群の費用は、2026年中なら「入力トークン÷100万×0.75ドル＋出力トークン÷100万×3.75ドル」、2027年以降なら「入力トークン÷100万×1.50ドル＋出力トークン÷100万×7.50ドル」で求める。Batch、Flex、Priority、コンテキストキャッシュには別の単価があるため、実際に使う提供方式を固定してから計算する。
月次試算には評価セットの単純平均ではなく、本番におけるタスク種別の構成比を使う。low向け定型処理、medium向け一般処理、highが必要な難問について、月間件数と平均入出力トークンを別々に掛け合わせる。通常月に加え、長期タスクやツール連携が増える繁忙時も計算すれば、平均値に隠れた予算超過を検出しやすい。
合否、段階展開、ロールバックを一つの条件表にする
設定を一つに統一する必要はない。タスクごとに必要条件を満たす最小のthinking levelを選び、定型処理をlow、一般処理をmedium、追加推論が成功率を改善する難問だけをhighへ送れば、効果のないリクエストまで高い遅延と使用量を負担せずに済む。
実行前に、現行モデルを基準とする成功率の下限、P95遅延の上限、成功タスク1件当たりの費用上限、ツール呼び出し回数の上限を決める。具体値は既存のSLOと予算から設定し、結果を見て動かさない。2026年の単価では合格しても2027年の単価で費用上限を超える構成は、本番候補ではなく再設計候補とする。
オフライン評価を通過した構成は、社内トラフィック、限定した本番トラフィック、対象全体の順に広げる。各段階で同じ指標を監視し、成功率、P95遅延、トークン、ツールループのいずれかが定めた範囲を外れたら展開を止める。旧モデルIDと旧ルーティングを一定期間保持し、デプロイなしで戻せるようにしておく。
移行記録には、タスク別のthinking level、除外した処理、2026年と2027年の月次試算、合否基準、ロールバック手順、再評価時期を残す。移行完了の条件はモデルIDが動くことではなく、品質、遅延、利用量、将来単価が承認済みの範囲に収まることである。
関連記事:
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。