generate_images は2027年まで残ります。それでも8月17日に画像生成は止まります

8月17日の停止まで、あと2日になりました。

ブログ記事のアイキャッチ画像を作っているスクリプトを、念のため手元で走らせてみました。何事もなく終わります。警告のひとつも出ません。

停止が2日後に迫っているのに、この静けさはどういうことなのか。気になって google-genai の中身を開いてみました。

SDK は確かに、何かを言っていました。ただしそれが指していた期限は、8月17日ではありませんでした。

SDK が告げていた期限は、2027年より前ではありませんでした

まず、最新版に generate_images が残っているかどうかを確かめました。

pip index versions google-genai
# google-genai (2.18.1)
# Available versions: 2.18.1, 2.18.0, 2.17.0, ...
#   INSTALLED: 2.18.1
#   LATEST:    2.18.1

from google.genai import models
 
print(hasattr(models.Models, "generate_images"))
# True

2026年8月15日時点の最新版である 2.18.1 に、generate_images はそのまま存在しています。「SDK を最新にしたから移行は済んだ」という考え方は、ここで崩れます。

では SDK は何も言っていないのかというと、そうではありません。メソッドにはデコレータで警告文が付いていました。

import inspect
from google.genai import models
 
src = inspect.getsource(models.Models.generate_images)
print(src[:400])

出てきた警告文の全文は、こうです。

The generate_images method is deprecated and will be removed in the next
major release (not before Jan. 1 2027). Please use the generate_content
method with image models instead.

「次のメジャーリリースで削除される。ただし2027年1月1日より前ではない」。

つまり SDK が管理している期限は、早くても2027年です。8月17日については一言も触れていません。ここを読んで安心してしまうと、そのまま2日後を迎えることになります。

止まるのはメソッドではなく、モデルのほうです

整理すると、期限は1本ではなく複数あり、しかも決めている主体が違います。

何が終わるか	期限	決めているもの	手元で確認できるか
`generate_images` メソッドの削除	次のメジャーリリース（2027年1月1日以降）	SDK のバージョン	できる
imagen-4.0 系3モデルの停止	8月17日	サーバー側	できない
Gemini 3 Image 系の停止	8月17日	サーバー側	できない

個人開発で全部を一人で回していると、スクリプトが今日も動いたという事実が、そのまま点検の代わりになってしまいます。私が油断していたのは、まさにこの表の3列目と4列目でした。手元のスクリプトが今日も動くことは、モデルが明日も生きていることを一切保証しません。動作確認で得られる安心は、SDK の層までしか届いていないのです。

止まるのはメソッドではありません。そのメソッドに渡している モデル ID のほうです。呼び出し箇所の洗い出しについては 8月17日の Gemini 画像生成モデル停止に備えるに手順をまとめてありますので、まだ棚卸しをしていない方はそちらを先にご覧ください。

警告は1プロセスに1回だけで、設定では取り戻せません

もうひとつ、実際に動かしてみて分かったことがあります。

この非推奨警告は、同じプロセスの中で1回しか出ません。しかも warnings の設定を強めても、2回目は出ませんでした。

import warnings
from google import genai
 
client = genai.Client(api_key="YOUR_API_KEY")
 
for n in (1, 2):
    with warnings.catch_warnings(record=True) as caught:
        warnings.simplefilter("always")
        try:
            client.models.generate_images(
                model="imagen-4.0-generate-001",
                prompt="a quiet morning street",
            )
        except Exception as e:
            err = type(e).__name__
        print(f"call#{n}: warnings={len(caught)} err={err}")

手元での実行結果です。

call#1: warnings=1 err=ClientError
call#2: warnings=0 err=ClientError

simplefilter("always") を指定しているのに、2回目はゼロ件でした。SDK 側が独自のフラグで「一度出したら以降は出さない」と決めているため、利用者側のフィルタ設定では取り戻せません。

警告の種類も確認しておきます。

from google.genai import _common
 
print([c.__name__ for c in _common.ExperimentalWarning.__mro__])
# ['ExperimentalWarning', 'Warning', 'Exception', 'BaseException', 'object']

DeprecationWarning ではなく、Warning の直下に置かれた独自クラスでした。非推奨の検出を DeprecationWarning で見張っている仕組みを持っている場合、この警告はその網に掛かりません。

常駐しているワーカーや、朝に起動して夜まで回り続けるバッチでは、起動直後の1回を見逃すとその日はもう二度と出ません。私のスクリプトが静かだったのも、単に警告を出し終えた後だっただけかもしれない、と思い当たりました。

見逃したくない場合は、起動時に一度だけ拾ってログへ流しておくのが確実です。

import logging
import warnings
 
logging.captureWarnings(True)
warnings.simplefilter("always")

logging.captureWarnings(True) を入れておくと、警告が py.warnings ロガー経由で流れます。標準エラー出力を誰も見ていない運用でも、ログ基盤には残ります。

API に届く前と後で、エラーの層が分かれます

移行作業中に出るエラーは、見た目が似ていても発生している層が違います。手元で実際に踏んだものを並べておきます。

1. API キーを渡していない場合

ValueError: No API key was provided. Please pass a valid API key.

クライアントを作る時点で止まります。通信は発生していません。

2. 引数の置き場所を間違えた場合

from google.genai import types
 
types.GenerateContentConfig(aspect_ratio="9:16")

pydantic_core._pydantic_core.ValidationError: 1 validation error for
GenerateContentConfig
aspect_ratio
  Extra inputs are not permitted [type=extra_forbidden, ...]

これも通信前です。aspect_ratio は GenerateContentConfig の直下ではなく、ImageConfig の側に置きます。現行の ImageConfig が受け取るのは aspect_ratio image_size output_mime_type output_compression_quality person_generation prominent_people image_output_options の7つでした。引数の移し先の全体像は generate_images から generate_content へ書き換えるとき、引数は素直に移りませんに対応表があります。

3. キーが無効だった場合

ClientError: 400 INVALID_ARGUMENT.
{'error': {'code': 400, 'message': 'API key not valid. ...',
 'status': 'INVALID_ARGUMENT'}}

ここで初めてサーバーからの応答になります。ClientError が返ってきたということは、リクエスト自体は届いているという意味です。

4. モデルが停止した後

これは8月17日を過ぎてからでないと再現できません。手元で先に作って見せることはできませんので、その旨だけ正直に書いておきます。ただし層としては3番と同じ、サーバーからの応答側で起きます。

見分け方はこう覚えておくと迷いません。ValueError と ValidationError は自分のコードの書き方の問題で、ClientError から先は向こう側の状態の問題です。画像生成まわりのエラーをもう少し広く見ておきたい方は Gemini 画像生成でつまずく5つのエラーも参考になるかと思います。

17日までに決める3つのこと

残り2日でできることは限られています。優先順に3つだけ挙げます。

モデル ID を渡している箇所を数える。 generate_images を検索するのではなく、imagen-4.0 という文字列を検索してください。メソッド名は残りますが、止まるのはモデル ID のほうです。
17日以降に何が壊れるかを、壊れる前に決めておく。 画像生成が失敗したとき、処理全体を止めるのか、生成をとばして先へ進めるのか。この判断を当日その場でするのは、いちばん高くつきます。
警告を捨てない設定にしておく。 logging.captureWarnings(True) の2行を入れるだけです。今回の件に限らず、次の非推奨に気づくのが数週間早くなります。

私自身、SDK が静かだったことを「まだ大丈夫」の材料にしかけていました。手元で確認できるのは自分のコードの側だけで、期限を握っているのは向こう側だという当たり前のことを、あらためて手を動かして確かめた形です。

同じところで足を止めかけている方の役に立てば嬉しく思います。お読みいただきありがとうございました。