5 月の中旬、Gemini 2.0 Flash の廃止スケジュールが 6 月に近づいているのを意識し始めて、自分が使っている個人開発のジョブを 1 件ずつ点検することにしました。年単位で動いている運用ジョブと、最近書いたばかりの実験ジョブが混在しており、廃止が来てから慌てて差し替えると確実にどこかが壊れます。同じように年単位で Gemini を使っている個人開発の方の参考になればと、5 月時点の私の点検プロセスを残しておきます。
廣川政樹と申します。アーティスト・個人開発者として 2014 年から壁紙アプリ群（累計 5,000 万ダウンロード超）の運営をしながら、最近は Gemini API を画像メタデータ生成や App Store の口コミ要約に使っています。これから書く話は、その個人開発バッチの 5 月時点の見直し記録です。
廃止アナウンスを「6 月に来るイベント」として扱わない
私が最初に変えたのは、廃止アナウンスを「6 月のイベント」として扱う発想を捨てたことです。アナウンスは確かに 6 月のどこかに区切りがありますが、本当に向き合うべきは「廃止前後でレスポンスのクセが変わってジョブの精度がぶれる」ほうです。
私の経験では、Gemini はモデル世代が変わると次のような部分でクセが移ります。
- 日本語の敬体/常体のゆらぎ
- JSON 出力時の
nullの扱い（フィールド省略か明示nullか） - 長文要約での句読点配分
- ツール呼び出しの引数フォーマットの微差
これらは API のレスポンスコードでは検出できないので、廃止日だけ見ていると本番リリース後に静かに壊れます。私は廃止日の前から「同じ入力を新旧モデルに送って差分を取るバッチ」を回しはじめました。
私の点検チェックリスト 4 つ
5 月時点で私が回しているチェックリストは 4 つに整理してあります。
1. プロバイダ抽象の有無
Gemini API を直叩きしている呼び出しと、自前の薄い抽象越しに呼んでいる呼び出しが混在していると、廃止対応の作業量が指数的に増えます。私は次のような最小抽象を 30 行ほど書いて、すべての呼び出しをこれに通すよう統一しました。
from dataclasses import dataclass
from typing import Optional
from google import genai
@dataclass
class GeminiRequest:
prompt: str
model: Optional[str] = None # None なら provider の default
json_schema: Optional[dict] = None
class GeminiProvider:
DEFAULT_MODEL = "gemini-2.5-flash" # 5 月から default を移行
FALLBACK_MODEL = "gemini-2.0-flash" # 廃止までは残す
def __init__(self, api_key: str):
self._client = genai.Client(api_key=api_key)
def call(self, req: GeminiRequest) -> str:
model = req.model or self.DEFAULT_MODEL
cfg = {"response_mime_type": "application/json"} if req.json_schema else {}
try:
res = self._client.models.generate_content(
model=model, contents=req.prompt, config=cfg
)
return res.text
except Exception:
if model != self.FALLBACK_MODEL:
return self.call(GeminiRequest(req.prompt, self.FALLBACK_MODEL, req.json_schema))
raiseここで意図的にやっているのは「default を 2.5 Flash に倒し、フォールバックとして 2.0 Flash をしばらく残す」運用です。廃止日が来る前に default 側で 100% 運用される実績を作っておきたいので、フォールバックを呼び出した回数が日次でカウントできるよう、別途メトリクスも入れてあります。
2. JSON スキーマ運用の差分
Gemini 2.0 Flash と 2.5 Flash で JSON 出力の挙動が体感で違うのは、空配列を返すときの形と、null を許容するフィールドの扱いです。2.0 では "items": [] を出していた場面で、2.5 ではフィールド自体を省略してくる頻度が増えました。私は壁紙アプリのレビュー要約スキーマで "keywords": [] が前提だったので、廃止前にスキーマと parse 側を両対応に直しました。
3. ログのモデル名タグ付け
すべての呼び出しログにモデル名を入れておきます。これは廃止後のトラブルシュート時にどのジョブが何モデルで動いていたかを後から辿るためです。私は構造化ログにしていなかったジョブが 2 つあって、5 月の点検で全てに model_id フィールドを追加しました。
4. コスト試算と推論時間の実測
私の実測値で言うと、Gemini 2.5 Flash は 2.0 Flash と比べて、入力 1,000 トークンあたりの推論時間が 5 〜 15% ほど増える傾向がありました。月の処理量が多いジョブだとここがそのまま AdMob 由来の収益に対する原価率に乗ってくるので、レイテンシ要件のあるジョブ（例えば壁紙アプリ内のチャットボット）だけは 2.5 Pro よりも 2.5 Flash の方が個人開発の経済性として現実的だと判断しました。