無人で回している画像生成処理が、ある朝とつぜん 404 NOT_FOUND を返し始める。その原因が自分のコードではなく、外部のモデル廃止スケジュールにあった——という経験をされた方は少なくないのではないでしょうか。
2026年6月25日、gemini-3.1-flash-image-preview と gemini-3-pro-image-preview の2つの画像プレビューモデルが停止されました。入れ替わりに、ネイティブ画像モデルの正式版として gemini-3.1-flash-image(Flash Image)と gemini-3-pro-image(Pro Image)が GA に昇格しています。
私自身、壁紙や癒し系のアプリで図版やサムネイルを自動生成する処理をいくつか回しております。プレビュー版のモデルIDをコードに直書きしていた頃は、こうした廃止のたびに該当箇所を探して書き換える、という後手の対応を繰り返していました。今回はその反省を踏まえ、GA への移行手順と同時に「廃止日に振り回されないパイプライン設計」を共有いたします。
プレビューと GA で、実際に何が変わるのか
まず押さえておきたいのは、今回の変更が単なる名前替えではないという点です。モデルIDから -preview サフィックスが落ちたことには、運用上の意味があります。
項目 プレビュー版 GA 版
モデルID gemini-3.1-flash-image-preview gemini-3.1-flash-image
SLA・安定性保証 なし(予告で停止しうる) あり(廃止には移行期間)
料金体系 暫定・変動しうる 確定
本番利用の推奨 非推奨(検証向け) 推奨
動画→画像生成 一部のみ Flash Image で対応
プレビュー版は「いつ消えてもおかしくない」前提のモデルでした。検証や試作には便利ですが、無人で回す本番処理に直書きするのは、今思えば筋の悪い設計だったと感じています。GA 版は廃止時に移行期間が設けられるため、同じ事故は起きにくくなります。
ただし、GA 版に差し替えれば終わり、ではありません。次にまた別のモデルが廃止される日は必ず来ます。大切なのは「次の廃止」に備えた構造を、この移行のタイミングで仕込んでおくことだと考えています。
移行の最小手順:まずは止まった処理を動かす
緊急で動かす必要がある場合の最小手順から示します。多くのコードでは、モデルIDの差し替えだけで復旧します。
from google import genai
client = genai.Client( api_key = "YOUR_API_KEY" )
# Before(停止済み):
# model = "gemini-3.1-flash-image-preview"
# After(GA):
model = "gemini-3.1-flash-image"
response = client.models.generate_content(
model = model,
contents = "A calm minimalist wallpaper, soft gradient, muted teal" ,
)
# 生成画像はパートとして返る
for part in response.candidates[ 0 ].content.parts:
if part.inline_data is not None :
with open ( "wallpaper.png" , "wb" ) as f:
f.write(part.inline_data.data)
この段階での注意点は、プレビューと GA でレスポンス形状が同じでも、生成結果のトーンが微妙に変わる ことがある点です。プロンプトをそのまま流用すると、色味や構図がわずかにずれる場合があります。本番に流す前に、代表的なプロンプト数本で出力を目視確認することを推奨します。
廃止に強い設計:モデルIDを一元管理する
ここからが本題です。緊急対応で直書きを書き換えただけでは、次の廃止でまた同じ作業を繰り返します。モデルIDをコード全体に散らさず、一箇所の設定レイヤーに集約します。
# model_registry.py
from dataclasses import dataclass
from datetime import date
@dataclass ( frozen = True )
class ModelSpec :
id : str
role: str # 用途のラベル
deprecate_on: date | None # 既知の廃止日(公式アナウンスがあれば設定)
fallback: str | None # 廃止時の代替モデルID
# 用途ごとに「論理名 → 実モデルID」を対応させる
REGISTRY : dict[ str , ModelSpec] = {
"image_fast" : ModelSpec(
id = "gemini-3.1-flash-image" ,
role = "サムネイル・量産図版" ,
deprecate_on = None ,
fallback = "gemini-3-pro-image" ,
),
"image_quality" : ModelSpec(
id = "gemini-3-pro-image" ,
role = "高品質ヒーロー画像" ,
deprecate_on = None ,
fallback = "gemini-3.1-flash-image" ,
),
}
def resolve (logical_name: str ) -> str :
spec = REGISTRY [logical_name]
return spec.id
アプリケーション側のコードは、実モデルIDではなく resolve("image_fast") という論理名でモデルを参照します。こうしておけば、次にモデルが廃止されても、修正箇所は model_registry.py の1ファイルだけで済みます。直書きを全コードベースから grep して回る、あの不毛な作業から解放されます。
私はこの「論理名で参照する」パターンを導入してから、モデルの世代交代にかかる手間が体感で大きく減りました。手を動かす箇所が1ファイルに収束していると、移行そのものへの心理的な抵抗も小さくなります。
廃止日を見落とさない:事前アラートの仕組み
GA 版にも、いつかは廃止の日が来ます。問題は、その告知を人間が見落とすことです。無人で回す処理ほど、廃止の事実に気づくのが遅れます。deprecate_on フィールドを使い、廃止日が近いモデルを毎日チェックする小さな番人を用意します。
# deprecation_guard.py
from datetime import date, timedelta
from model_registry import REGISTRY
ALERT_WINDOW_DAYS = 30
def check_deprecations (today: date | None = None ) -> list[ str ]:
today = today or date.today()
warnings: list[ str ] = []
for name, spec in REGISTRY .items():
if spec.deprecate_on is None :
continue
days_left = (spec.deprecate_on - today).days
if days_left < 0 :
warnings.append(
f "🔴 { name } ( { spec.id } ) は廃止済み。fallback= { spec.fallback } へ即時移行が必要です"
)
elif days_left <= ALERT_WINDOW_DAYS :
warnings.append(
f "⚠️ { name } ( { spec.id } ) は残り { days_left } 日で廃止。移行先 { spec.fallback } の検証を始めてください"
)
return warnings
if __name__ == "__main__" :
for w in check_deprecations():
print (w)
これを日次の cron や Cloud Scheduler に組み込み、出力を Slack やメールに流すだけで、廃止の30日前に必ず手元へ通知が届きます。公式の changelog で廃止日が告知されたら、REGISTRY の deprecate_on に日付を1行書き加える。運用としてはこれだけです。
数値で言えば、今回のように「廃止当日に告知に気づく」のと「30日前に気づく」のとでは、検証と切り替えにかけられる時間が文字どおり桁違いになります。無人処理の信頼性は、こうした地味な番人の有無で大きく変わると感じています。
動画から画像を生成する:サムネイル自動化への接続
今回の GA 昇格と同時に、gemini-3.1-flash-image 限定で動画ファイルを文脈として渡し、そこから画像を生成する 機能が使えるようになりました。動画のサムネイルや、内容を要約した図版を自動で作る用途に直接効きます。
from google import genai
client = genai.Client( api_key = "YOUR_API_KEY" )
# 動画をアップロードして文脈として渡す
video_file = client.files.upload( file = "clip.mp4" )
response = client.models.generate_content(
model = "gemini-3.1-flash-image" ,
contents = [
video_file,
"Create a clean thumbnail capturing the calmest moment of this clip. "
"16:9, soft lighting, no text overlay." ,
],
)
for part in response.candidates[ 0 ].content.parts:
if part.inline_data is not None :
with open ( "thumbnail.png" , "wb" ) as f:
f.write(part.inline_data.data)
従来は「動画から代表フレームを抽出 → そのフレームを別途加工」という2段構えが必要でした。動画そのものを文脈として渡せると、内容を踏まえた1枚を一発で生成できます。個人開発で図版やサムネイルを日々さばく立場には、工程が1つ畳めるのは素直にありがたい変化です。
コスト試算:日次運用での目安
サムネイル自動化を組む際は、件数からおおよその月額を見積もっておくと安心です。Flash Image は量産前提の速い・安いモデルで、品質重視の Pro Image は単価が上がります。用途で使い分けるのが現実的です。
運用シナリオ モデル 1日あたり 月間生成数
記事サムネイル量産 image_fast(Flash Image) 30枚 約900枚
ヒーロー画像・告知用 image_quality(Pro Image) 3枚 約90枚
具体的な単価は公式の料金ページが正本ですので、運用前に必ず確認してください(Gemini API 料金 )。設計の勘所は「量産は Flash、勝負どころは Pro」という役割分担を model_registry.py の論理名に落とし込んでおくことです。image_fast と image_quality を分けておけば、コストとクオリティのバランスを設定1箇所で調整できます。
移行を終えたら確認したいこと
最後に、GA 移行と廃止対策を入れたあとの確認項目を、実務の順番で挙げておきます。
本番運用に乗せる前に、次の3点を順に確認することを推奨します。
出力の目視確認:プレビューと GA で色味や構図が変わっていないか、代表プロンプト数本で見比べます。トーンのずれに気づいたら、プロンプト側を微調整して対処します。
直書きの洗い出し:model_registry.py 以外の場所にモデルIDが残っていないか、grep -rn "gemini-3" . で確認します。
アラートの実地テスト:deprecation_guard.py を日次スケジュールに乗せ、テスト送信で通知が実際に届くかを確かめます。
廃止というイベントそのものは避けられません。けれども、それを「当日の事故」から「30日前の予定された作業」に変えることはできます。今回の停止を、その仕組みを仕込む良い機会にしていただければ幸いです。お読みいただきありがとうございました。