6月23日の朝、いつものように Gemini API の更新履歴を開いたら、3.5 Flash が GA になったと書かれていました。気になったのは性能の説明の仕方で、上位だった 3.1 Pro をほぼすべてのベンチマークで上回りながら、他のフロンティアモデルの4倍の速さで動く、という位置づけになっていました。
そこで私が最初に開いたのは、リリースノートの続きではなく、自分の手元にある「どのタスクにどのモデルを当てるか」のメモでした。速くて安いモデルが、自分が今まで上位モデルに任せていた仕事まで賢くこなせるなら、担当表を引き直す価値があります。今日はその引き直しの記録です。
私はタスクごとに「担当モデル」を決めています
個人開発でアプリをいくつか運用していると、Gemini を呼ぶ場面はひとつではありません。壁紙アプリに届くユーザーレビューを朝までに分類しておく処理、リリースノートの下書き、コードの差分に対する軽いレビュー、ストア説明文の多言語チェック。それぞれ求めるものが違います。
レビュー分類は件数が多く、1件あたりの判断は軽いので、速さと単価が効きます。一方でコードレビューは件数こそ少ないものの、見落とすと困るので、多少遅くても賢いほうが安心です。だから私はタスクの性質に応じてモデルを割り当て、その対応をひとつのテーブルとして持っています。値段と速さと賢さは、たいてい三すくみだからです。
今回の更新が面白かったのは、その三すくみの一角が崩れたことです。速くて安いはずの Flash が、上位の Pro をベンチで上回ると言われたなら、「速いから格下」という前提そのものを疑う必要が出てきます。
「速いから下」ではなく「速いのに賢い」を試す
とはいえベンチマークの数字をそのまま信じて担当を入れ替えるのは、私の性に合いません。自分のタスクで実際に試して、出力の質が落ちないことを確かめてから動かしたいところです。そこでまず、担当替えの候補を機械的に出すのではなく、タスクを「賢さ重視」と「速さ重視」に仕分けるところから始めました。
担当を切り替えるかどうかの判断を、私は小さなルーティング関数に閉じ込めています。モデル名をコードのあちこちに直書きすると、こういう乗り換えのたびに探し回ることになるからです。
import os
from google import genai
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
# タスクの性質ごとにモデルを一箇所で決める。
# 乗り換えはこの辞書を書き換えるだけで済むようにしておく。
MODEL_FOR_TASK = {
"review_triage": "gemini-3.5-flash", # 件数が多く判断は軽い → 速さ優先
"store_copy_check": "gemini-3.5-flash",
"code_review": "gemini-3.1-pro", # 見落としが痛い → 当面は上位を維持
"release_notes": "gemini-3.5-flash", # 今回 Pro から Flash へ担当替え
}
def run_task(task: str, prompt: str) -> str:
model = MODEL_FOR_TASK.get(task, "gemini-3.5-flash")
response = client.models.generate_content(model=model, contents=prompt)
return response.text
# 例: リリースノートの下書き（担当を Flash に替えたタスク）
draft = run_task("release_notes", "次の変更点を、落ち着いた敬体の箇条書きにしてください: ...")
print(draft)
# 期待する出力: 箇条書きのリリースノート下書き（数百ミリ秒〜数秒で返る）この形にしておくと、担当替えは辞書の一行を書き換えるだけになります。私が release_notes を Pro から Flash に移したのも、実際にはこの一行の修正でした。出力を一週間ぶんつき合わせて、文体も情報の落ちもほぼ変わらないと確認できたので、安心して移せました。
担当替えで、ひとつだけ慎重にしたこと
全部を Flash に寄せたわけではありません。コードレビューの担当だけは、しばらく上位モデルのまま据え置きました。
理由は、私がこのタスクに求めているのが「速さ」ではなく「立ち止まる力」だからです。以前、壁紙アプリで一覧表示が特定の操作のあとだけ落ちる不具合を追っていたとき、差分そのものは小さいのに、落ちる条件は差分の外側にありました。こういう「コードには現れていない前提」を疑うには、速く答えるより、いったん引いて筋を見る賢さのほうが効きます。ベンチで上回ったと聞いても、私自身は自分の手で同じ難しさのレビューを何度か通して、見落としが増えないと確かめるまでは動かさないことにしています。
新しいモデルが出るたびに全面的に乗り換えたくなりますが、私はタスク単位で、しかも「外したら困る順」に慎重に試すようにしています。速いモデルが賢くなったという報せは嬉しい一方で、嬉しさのまま全部を入れ替えると、たまたま難しかった一件で痛い目を見ます。担当替えは一気にではなく、確かめながら一枚ずつめくるのが、結局いちばん早いと感じています。
なお、こうしたモデルの世代交代は速いので、廃止予定とあわせて追うのが安全です。Gemini の更新履歴と非推奨モデルの一覧を、私は隔週で開くようにしています。
まとめ
もし同じように複数のタスクで Gemini を呼んでいるなら、まずはモデル名を一箇所のテーブルに集めるところから始めてみてください。担当替えの良し悪し以前に、乗り換えが「一行の修正」で済む形になっていること自体が、こういう速い世代交代の時期にいちばん効いてくると感じています。
お読みいただきありがとうございました。