停止日のない非推奨をどう扱うか — 画像モデルの移行先を、3つの条件で選び直す

月初の朝、モデル ID を一覧で見直していたとき、deprecations の表に見慣れない行が増えていました。10月6日の changelog には「gemini-3.1-flash-image は非推奨（停止日は未発表）」とだけ書かれています。期限が書かれていないと、かえって手が止まります。

最初にお伝えしたいのは、停止日のない非推奨は「いつ止まるか」ではなく「どの条件なら今すぐ動かせるか」で決めるということです。ここから先は、公式ドキュメント（2026年10月8日に確認）に書かれている内容だけを使い、移行先を選ぶ順番を整理します。数値はすべて公式の記載で、私が測ったものではありません。

先に押さえる事実

gemini-nano-banana-2.1 は10月6日に GA になりました。
gemini-3.1-flash-image は非推奨で、推奨移行先は gemini-nano-banana-2.1 です。deprecations の表には「No shutdown date announced」とあります。
同じ表に「表の日付は、そのモデルが退役しうる最も早い日」という注記があります。日付が出た時点で、猶予はその日までと考えるのが安全です。
以前の記録には 10月29日停止という記述がありましたが、現在の表には該当の日付がありません。古い情報を見かけたら、公式の表で確かめ直してください。

3つのモデルを、使える条件で並べる

観点	gemini-nano-banana-2.1	gemini-3.1-flash-lite-image	gemini-3.1-flash-image
状態	GA（推奨）	提供中	非推奨（停止日未発表）
解像度	1K / 2K / 4K	1K のみ	512px / 1K / 2K / 4K
参照画像	物体10枚・人物4枚	物体14枚（人物の記載なし）	物体10枚・人物4枚
Google 検索の根拠付け	あり（画像検索も可）	なし	あり（画像検索も可）
thinking の段階	minimal / medium / high（既定は medium）	minimal / high	minimal / high（既定は minimal）

表を作っていて気づいたのは、512px の出力を使えるのは、非推奨になった gemini-3.1-flash-image だけだという点です。サムネイル用途で 512px を指定している場合は、移行先を単純に差し替えられません。1K で出して縮小するか、別の手当てが必要になります。

選定を、手元で再現できる形にする

表を目で追うより、条件を渡して判定させるほうが見落としません。次のスクリプトは、上の表をそのまま辞書にしたものです。API キーは使わず、手元の Python だけで動きます。

MODELS = {
    "gemini-nano-banana-2.1":      {"sizes": {"1K", "2K", "4K"}, "objects": 10, "characters": 4, "grounding": True,  "thinking": {"minimal", "medium", "high"}, "status": "GA"},
    "gemini-3.1-flash-lite-image": {"sizes": {"1K"},             "objects": 14, "characters": 0, "grounding": False, "thinking": {"minimal", "high"},           "status": "stable"},
    "gemini-3.1-flash-image":      {"sizes": {"512", "1K", "2K", "4K"}, "objects": 10, "characters": 4, "grounding": True, "thinking": {"minimal", "high"},    "status": "deprecated"},
}
 
def pick(size="1K", objects=0, characters=0, grounding=False, thinking=None):
    out = []
    for name, m in MODELS.items():
        why = []
        if size not in m["sizes"]: why.append(f"{size} 非対応")
        if objects > m["objects"]: why.append(f"物体参照 {m['objects']} 枚まで")
        if characters > m["characters"]: why.append(f"人物参照 {m['characters']} 枚まで")
        if grounding and not m["grounding"]: why.append("検索グラウンディング非対応")
        if thinking and thinking not in m["thinking"]: why.append(f"thinking={thinking} 非対応")
        if m["status"] == "deprecated": why.append("非推奨（停止日は未発表）")
        out.append((name, why))
    return out

4つの使い方を想定して、実際に実行した出力は次のとおりです。

[A 壁紙の1K量産（参照なし）]
   OK   gemini-nano-banana-2.1
   OK   gemini-3.1-flash-lite-image
   NG   gemini-3.1-flash-image — 非推奨（停止日は未発表）
[B 4K・人物参照2枚・検索あり]
   OK   gemini-nano-banana-2.1
   NG   gemini-3.1-flash-lite-image — 4K 非対応 / 人物参照 0 枚まで / 検索グラウンディング非対応
   NG   gemini-3.1-flash-image — 非推奨（停止日は未発表）
[C 512px サムネイル]
   NG   gemini-nano-banana-2.1 — 512 非対応
   NG   gemini-3.1-flash-lite-image — 512 非対応
   NG   gemini-3.1-flash-image — 非推奨（停止日は未発表）
[D 参照12枚・1K]
   NG   gemini-nano-banana-2.1 — 物体参照 10 枚まで
   OK   gemini-3.1-flash-lite-image
   NG   gemini-3.1-flash-image — 物体参照 10 枚まで / 非推奨（停止日は未発表）

読み方は単純です。A のように 1K で参照なしなら、nano-banana-2.1 と flash-lite-image のどちらも通ります。ここは品質と費用で選ぶ場面なので、費用の側はNano Banana 2 Lite でバッチ画像を作るときの費用設計が参考になります。B は nano-banana-2.1 しか残りません。C は、どの移行先でも条件を満たしません。

呼び出しの形は、公式ページでは Interactions API

移行先を決めたら、呼び出しも確かめます。現行の画像生成ページは generate_content ではなく interactions.create を使った例を示しています。

import base64
from google import genai
 
client = genai.Client()
 
interaction = client.interactions.create(
    model="gemini-nano-banana-2.1",
    input="Create a picture of a nano banana dish in a fancy restaurant with a Gemini theme",
)
 
with open("generated_image.png", "wb") as f:
    f.write(base64.b64decode(interaction.output_image.data))

出力の指定は response_format={"type": "image", "aspect_ratio": "16:9", "image_size": "2K"} の形です。image_size は大文字の K で書く必要があり、"1k" のような小文字は拒否されると公式ページにあります。thinking は generation_config={"thinking_level": "high"} で指定します。この記事のコードのうち、API を呼ぶ部分は公式ページの記載をそのまま写したもので、私の環境で呼び出して確かめたものではありません。実際に動かす前に、自分のキーで1枚だけ試してください。

ID を替えるだけでは同じ挙動にならない点

もう一つ、見落としやすい違いがあります。公式ページによると、Gemini 3 世代の画像モデルは thinking を API 上でオフにできず、途中経過の画像を最大2枚まで生成し、thinking のトークンにも課金されます。そして既定の段階は、nano-banana-2.1 が medium、3.1-flash-image が minimal です。

つまり、ID だけを差し替えて thinking を指定しないままにすると、既定値の違いで応答時間と費用の見え方が変わる可能性があります。私は「同じ品質で安く」と期待して差し替え、あとで請求の内訳を見て首をかしげる場面を何度も経験してきました。移行の初日は、thinking_level を旧モデルの既定（minimal）に明示してから比べるようにしています。差が出たときに、モデルのせいなのか設定のせいなのかを切り分けられるからです。

決め方の順番

私なら、次の順で進めます。

コード中の gemini-3.1-flash-image を検索し、解像度・参照枚数・検索の有無を呼び出し箇所ごとに書き出します。
上のスクリプトに条件を渡し、OK が出たものを移行先の候補にします。
512px や参照12枚以上のように、どの候補でも NG になる呼び出しだけを別枠にして、仕様を見直すか、日付が出るまで据え置くかを決めます。

据え置く場合も、置き換え先を ID 1つで切り替えられる形にしておくと、日付が発表された日の作業が小さくなります。モデル ID を設定に逃がす考え方は画像モデルの GA 移行と非推奨に強いパイプラインに詳しく書きました。

日付が書かれていないあいだにできる準備は、条件の棚卸しだけです。 次に表が更新されたら、まず自分の NG の行から見直そうと思っています。