プレビューモデルの停止で本当に怖いのは、よく使う経路ではなく、めったに動かない経路です。gemini-3.1-flash-image-preview と gemini-3-pro-image-preview が 6/25 で止まります。日中の主要な生成で使っていれば嫌でも気づきますが、月初だけ走る集計バッチや、上位モデルが詰まったときだけ落ちるフォールバック分岐に書いてあると、停止の瞬間まで気づけません。
私自身、個人開発でアプリの画像処理を回していて、フォールバック側に古いモデル名が残っていたことに後から気づいた経験があります。普段は上位モデルで通るので、フォールバックが発火する稀な日にだけ静かに失敗していました。今回は、停止前にこうした取りこぼしを残さないための依存監査を、洗い出しから移行後の確認まで順に整理します。
「使っている場所」は一カ所ではない
モデル名は、思っているより多くの場所に散らばります。監査を始める前に、探すべき場所を洗い出しておくと漏れが減ります。
| 場所 | 見落としやすい例 |
|---|---|
| アプリのコード | フォールバック分岐・リトライ時の別モデル指定 |
| 設定ファイル | 環境別の YAML/JSON に直書きされたモデル名 |
| 環境変数 | デプロイ環境にだけ設定された値 |
| 保存済みプロンプト | DB やファイルに記録されたジョブ定義 |
| バッチ・スケジュール | 月次・週次でしか起動しないジョブ |
この五カ所のうち、コードだけを見て安心してしまうのが典型的な失敗です。設定ファイルや環境変数に直書きされていると、コード本体には文字列が出てきません。私は監査のとき、コードと同じ重みで設定と環境変数を見るようにしています。
まずは機械的に全件拾う
最初の一手は、対象のモデル名をリポジトリ全体から拾うことです。停止対象は二つなので、両方を一度に検索します。コメントや古いドキュメントに残っているだけの「死んだ参照」も、いったん全部出してから仕分けします。
# 停止対象モデルへの参照を、コードと設定からまとめて洗い出す
grep -rnE "gemini-3\.1-flash-image-preview|gemini-3-pro-image-preview" \
--include="*.py" --include="*.ts" --include="*.js" \
--include="*.json" --include="*.yaml" --include="*.yml" \
--include="*.env*" . \
| tee /tmp/preview_model_hits.txt
echo "--- ヒット件数 ---"
wc -l < /tmp/preview_model_hits.txtヒットが多くても慌てる必要はありません。重要なのは件数ではなく、それぞれが「いま動く経路か」です。次の仕分けで、対応が要る参照だけに絞り込みます。
ヒットを三つに仕分ける
洗い出した参照を、対応の緊急度で三つに分けます。仕分けの基準を先に決めておくと、判断が速くなります。
- 稼働中: 現在のリクエストで実際に呼ばれている。最優先で差し替える
- フォールバック/稀: 普段は通らないが、特定条件で発火する。ここが最も見落とされる。同じく差し替える
- 死んだ参照: コメント・旧ドキュメント・到達しないコード。差し替え不要だが、混乱を避けるため削除する
稼働中とフォールバックは必ず差し替えます。私の経験では、停止事故のほとんどはフォールバック分岐で起きます。「上位モデルが動いているから大丈夫」という油断が、稀にしか走らない経路の点検を後回しにさせるからです。死んだ参照は機能には影響しませんが、次に誰かが監査するとき再びノイズになるので、この機会に消しておくと後が楽になります。
後継への差し替えと、設定への一本化
差し替え先は、停止対象に対応する後継の画像生成モデルです。ここで一つだけ運用上の工夫をお勧めします。差し替えるついでに、モデル名をコードへ直書きするのをやめて、一箇所の設定に集約することです。
# model_config.py — モデル名を一箇所に集約し、直書きを排除する
# 後継モデルへの差し替えは、今後この一行を変えるだけで済む
IMAGE_MODEL = os.environ.get("GEMINI_IMAGE_MODEL", "gemini-3-pro-image")
def generate_image(prompt: str):
return client.models.generate_content(
model=IMAGE_MODEL, # 各呼び出しでモデル名を直書きしない
contents=prompt,
)集約しておくと、次にモデルが移行するとき、監査でリポジトリ中を探し回る作業そのものが要らなくなります。今回の停止対応を、将来の移行コストを下げる機会として使うと、同じ作業を繰り返さずに済みます。私は Dolice Labs の個人開発でモデルを複数使い分けているので、この一本化は移行のたびに効いてきました。
差し替え後に、稀な経路を意図的に動かす
最後が一番大切です。差し替えたら、フォールバックや月次バッチのような稀な経路を、本番停止を待たずに意図的に発火させて確認します。差し替えたつもりで別の箇所が残っていた、というのを停止前に自分で見つけるためです。
# 差し替え漏れがないか、停止対象が一件も残っていないか最終確認する
if grep -rqE "gemini-3\.1-flash-image-preview|gemini-3-pro-image-preview" \
--include="*.py" --include="*.ts" --include="*.js" \
--include="*.json" --include="*.yaml" --include="*.yml" .; then
echo "⚠️ まだ停止対象モデルへの参照が残っています"
else
echo "✅ 停止対象モデルへの参照はゼロです"
fiフォールバック分岐は、条件を満たさないと普段は動かないので、テストでは上位モデルをわざと失敗させて経路を通します。月次バッチは、本番の起動を待たずに手元で一度実行します。停止日に「動くはず」を確かめるのではなく、停止前に「動く」を確認しておく。この差が、稀な経路での静かな失敗を防ぎます。
期限のあるモデル停止は、慌てると稼働中の経路だけを直して終わりにしがちです。けれども取りこぼしは、いつも目の届きにくい経路に残ります。停止の前に、まずリポジトリ全体で対象モデル名を一度検索してみてください。ヒットを稼働中・稀・死んだ参照に分けるところから始めれば、6/25 を静かに迎えられるはずです。