はじめに
対象読者は、Gemini API の画像生成モデルを本番コードから呼んでいて、廃止告知が出るたびに移行の見積もりと監視を考えることになる開発者です。
Gemini API の Imagen 4 系 3 モデルは 2026-08-17 にシャットダウンされました。画像モデルの廃止はこれで終わりではなく、2026-10-06 には gemini-3.1-flash-image が非推奨になり、gemini-2.5-flash-image には 2027-03-15 のシャットダウン日が付いています。移行を見落としたコードは、ある日を境にエラーを返し始めます。
問題は、そのエラーを見て「モデルが廃止された」と判断できるかどうかです。Imagen 4 のシャットダウン前日に実際の API を叩いた記録では、廃止に関係する 404 が 3 種類あり、廃止と断定できる文面は 1 種類だけでした。さらに、存在確認として真っ先に思いつく GET /models/{id} は、停止済みのモデルに HTTP 200 を返していました。
この記事は、その記録と今回の追加検証をもとに、画像モデルの廃止に備えるための判断材料をまとめたものです。
TL;DR
- 2026-10-15 時点で、Imagen 4 系は 2026-08-17 に停止済み。公式の推奨移行先は
gemini-nano-banana-2.1（2026-10-06 GA）に更新されている - 次に日付が決まっている画像モデルの停止は
gemini-2.5-flash-image（2027-03-15・移行先gemini-3.1-flash-lite-image）。gemini-3.1-flash-imageは非推奨だが停止日は未定 - 廃止に関係する 404 は 3 種類あり、廃止と断定できるのは
is no longer availableを含む 1 種類だけ - API キーが無い・無効なときは、モデルの有無より先に 403 / 400 が返る。認証エラーは廃止の検出を覆い隠す
- 存在確認は
GET /models/{id}ではなくListModelsのカタログ突き合わせで行う
現行の画像モデルと廃止スケジュール
公式の deprecations ページ の画像生成モデル表（2026-10-15 に参照）から、GA モデルを抜き出すと次のとおりです。
| モデル ID | リリース | シャットダウン | 推奨移行先 |
|---|---|---|---|
gemini-nano-banana-2.1 |
2026-10-06 | 未発表 | なし |
gemini-3.1-flash-lite-image |
2026-06-30 | 未発表 | なし |
gemini-3.1-flash-image |
2026-05-28 | 未発表（非推奨） | gemini-nano-banana-2.1 |
gemini-3-pro-image |
2026-05-28 | 未発表 | なし |
gemini-2.5-flash-image |
2025-10-02 | 2027-03-15 | gemini-3.1-flash-lite-image |
imagen-4.0-generate-001 |
2025-06-24 | 2026-08-17（停止済み） | gemini-nano-banana-2.1 |
imagen-4.0-ultra-generate-001 |
2025-06-24 | 2026-08-17（停止済み） | gemini-nano-banana-2.1 |
imagen-4.0-fast-generate-001 |
2025-06-24 | 2026-08-17（停止済み） | gemini-nano-banana-2.1 |
Imagen 4 の推奨移行先は、2026-06-15 の廃止告知の時点では gemini-3.1-flash-image でした。その移行先自体が 2026-10-06 の changelog で非推奨になり、表の推奨先も gemini-nano-banana-2.1 に書き換わっています。告知時点の移行先へ移した直後に、もう一段の移行が発生しうるということです。移行先は告知の記事ではなく、移行作業を始める時点の deprecations ページで確認したほうが安全です。
deprecations ページは、シャットダウンを「モデルが完全に停止し、エンドポイントが利用できなくなること」と定義し、表の日付は「モデルが停止されうる最も早い日付」だと注記しています。日付は下限であり、当日に止まる保証も当日を過ぎて動き続ける保証もありません。
廃止のかたちは 1 種類ではない
同じ deprecations ページを見ると、モデルの終わり方には少なくとも 3 つのかたちがあります。
| かたち | 例（公式表より） | 古い ID で呼んだときの挙動 |
|---|---|---|
| シャットダウン |
imagen-4.0-*（2026-08-17） |
エンドポイントが止まり、エラーになる |
| 非推奨・停止日未定 | gemini-3.1-flash-image |
当面は動く。停止日は後から告知される |
| 自動ルーティング |
gemini-3.5-flash → gemini-3.6-flash（2026-10-08） |
エラーにならず、別モデルが応答する |
画像モデルで実際に起きたのはシャットダウンですが、テキストモデルでは 2026-10-08 に、古い ID へのリクエストを新モデルへ自動で回す方式が使われました。この方式ではエラーが一切出ないため、エラー監視だけでは移行を検知できません。出力の品質や料金が変わったことに気づく手段は、レスポンスに含まれるモデル情報やコストの記録を見るほうになります。
以降の節は、エラーが出るかたち（シャットダウン）を扱います。
停止前日の記録: 404 は 3 種類あった
以下は 2026-08-16 12:10 JST（Imagen 4 停止前日）に、Generative Language API v1beta を API キー付きの curl で叩いたときの記録です。今回（2026-10-15）はこのコンテナに Gemini の API キーが供給されていないため、キーを要する呼び出しは再実行できていません。現在も同じ文面が返るかは未確認です。
当時の結果を整理すると、廃止に関係する 404 は次の 3 種類でした。
| # | メッセージの型 | 発生条件 | 廃止と断定できるか |
|---|---|---|---|
| 1 | models/X is not found for API version v1beta, or is not supported for METHOD |
生成系エンドポイントで、ID が存在しない または メソッドが非対応 | できない |
| 2 | Model is not found: models/X for api version v1beta |
GET /models/{id} で ID が存在しない |
できない（ID 誤記と同じ） |
| 3 | This model models/X is no longer available. Please update your code to use a newer model... |
シャットダウン済みモデルを生成系エンドポイントで呼んだ | できる |
型 1 は「存在しない」と「メソッド違い」を同じ文面で返します。当時は、停止済みの gemini-1.5-flash:generateContent、停止済みの imagen-3.0-generate-001:predict、当時は存在したがメソッドが違う imagen-4.0-generate-001:generateContent と gemini-2.5-flash-image:predict の 4 パターンが、モデル名とメソッド名を除いて同じ文面でした。
この型が実務で効くのは、移行が中途半端なときです。Imagen 4 は :predict、Gemini の画像モデルは :generateContent 系と、呼び出しメソッドが違いました。モデル ID だけ差し替えて :predict のまま呼ぶと、移行先のモデルが確実に存在していても型 1 の 404 が返ります。エラー本文だけでは「移行漏れの ID が残っている」のか「ID は替えたがメソッドが古い」のかを切り分けられないので、ログには URL のメソッド部分まで残しておく必要があります。
なお、現行の公式画像生成ドキュメントの REST 例は、gemini-nano-banana-2.1 を Interactions API（POST /v1beta/interactions）で呼ぶ形になっています。Imagen 4 の推奨移行先へ移すときは、ID・メソッド・リクエストボディの構造がまとめて変わる前提で見積もるのが妥当です。
今回の検証: 認証エラーは 404 より先に返る
廃止の判定にはもう 1 つ落とし穴があります。2026-10-15 14:40 JST ごろ、API キーを付けない場合と無効なキーを付けた場合に何が返るかを、curl で確認しました。
curl -sS -X POST -H 'Content-Type: application/json' -d '{"instances":[{"prompt":"x"}]}' \
"https://generativelanguage.googleapis.com/v1beta/models/imagen-4.0-generate-001:predict"
{
"error": {
"code": 403,
"message": "Method doesn't allow unregistered callers (callers without established identity). Please use API Key or other form of API consumer identity to call this API.",
"status": "PERMISSION_DENIED"
}
}
無効なキー（key=INVALID）を付けると、今度は 400 になりました。
{
"error": {
"code": 400,
"message": "API key not valid. Please pass a valid API key.",
"status": "INVALID_ARGUMENT"
}
}
停止済みの imagen-4.0-generate-001 と、最初から存在しない ID を並べて HTTP ステータスだけ取ると、結果は同じでした。
imagen-4.0-generate-001 nokey=403 badkey=400
no-such-model-xyz nokey=403 badkey=400
認証のチェックはモデルの有無を調べる前に行われるため、キーが無い・無効な状態では、停止済みモデルも架空の ID も同じエラーになります。キーのローテーションやシークレットの供給ミスと廃止が重なると、ログに出るのは認証エラーだけで、廃止の 404 は見えません。廃止の監視を組むなら、まず認証が通っていることを別に確かめてから 404 の文面を見る順序にします。
エラー本文の振り分け
ここまでの 5 つの文面を振り分ける関数を書き、手元の Node.js v22.22.0 で動かしました。判定に使う文面は、404 の 3 種類が 2026-08-16 の記録、403 / 400 が今回取得したものです。
// classify-gemini-error.mjs
export function classify(httpStatus, body) {
const msg = body?.error?.message ?? '';
if (httpStatus === 400 && /API key not valid/.test(msg)) return 'AUTH_INVALID_KEY';
if (httpStatus === 403 && /unregistered callers/.test(msg)) return 'AUTH_NO_KEY';
if (httpStatus === 404 && /is no longer available/.test(msg)) return 'SHUTDOWN';
if (httpStatus === 404 && /or is not supported for (\w+)/.test(msg)) return 'NOT_FOUND_OR_METHOD';
if (httpStatus === 404 && /^Model is not found/.test(msg)) return 'NOT_FOUND_GET';
return 'UNKNOWN';
}
404 SHUTDOWN This model models/gemini-2.0-flash is no longer ...
404 NOT_FOUND_OR_METHOD models/gemini-3.1-flash-image is not found for A...
404 NOT_FOUND_GET Model is not found: models/imagen-3.0-generate-0...
403 AUTH_NO_KEY Method doesn't allow unregistered callers (calle...
400 AUTH_INVALID_KEY API key not valid. Please pass a valid API key....
SHUTDOWN だけが「廃止された」と言い切れる結果です。NOT_FOUND_OR_METHOD は、ログに残した URL のメソッドとカタログの supportedGenerationMethods を突き合わせないと原因が決まりません。文面は公式に固定された仕様ではないため、UNKNOWN に落ちたものを数えておき、件数が増えたら文面の変化を疑う運用が向いています。
存在確認は ListModels で行う
エラーが出る前に移行漏れを見つける方法として、生成リクエストを投げずに GET /models/{id} で存在確認する実装を思いつきます。課金も副作用もなく、安全に見えるからです。
2026-08-16 の記録では、この方法は停止済みモデルを見逃しました。2026-06-01 に停止した gemini-2.0-flash に対して、GET /models/gemini-2.0-flash は HTTP 200 と、対応メソッド付きの正常なメタデータを返しています。同じモデルに生成リクエストを投げると型 3 の 404 で落ち、ListModels の一覧（当時 54 件）にも含まれていませんでした。停止済みの imagen-3.0-generate-001 は GET でも 404 だったので、どちらになるかはモデルごとに違い、事前には分かりません。
当時の判定経路ごとの結果は次のとおりです。
| 判定経路 | 生きているモデル | 停止済み（gemini-2.0-flash） |
判定に使えるか |
|---|---|---|---|
ListModels に含まれるか |
含まれる | 含まれない | 使える |
GET /models/{id} |
200 | 200（誤検出） | 使えない |
| 生成リクエスト | 成功 | 404（型 3） | 使えるが課金・副作用あり |
また、停止前日の時点で Imagen 4 のメタデータには deprecated フラグもシャットダウン日も含まれていませんでした。API の応答から廃止予定を読み取って警告を出す監視は、当時の Generative Language API では組めません。廃止予定の把握は changelog と deprecations ページを追う側に残ります。
カタログ突き合わせのチェックスクリプト
ListModels の結果と、自分のコードが実際に呼んでいるモデル ID とメソッドの組み合わせを突き合わせるスクリプトです。USED は 2026-08-16 に動かしたときの内容のままにしてあります。
#!/usr/bin/env node
// GEMINI_API_KEY=... node gemini-model-precheck.mjs
const API = 'https://generativelanguage.googleapis.com/v1beta';
const KEY = process.env.GEMINI_API_KEY;
// 自プロジェクトが実際に叩いている組み合わせを列挙する
const USED = [
{ model: 'imagen-4.0-generate-001', method: 'predict' },
{ model: 'imagen-4.0-fast-generate-001', method: 'predict' },
{ model: 'gemini-3.1-flash-image', method: 'predict' }, // ID だけ差し替えた想定の誤り
{ model: 'gemini-3.1-flash-image', method: 'generateContent' },
{ model: 'gemini-2.0-flash', method: 'generateContent' }, // 停止済みと分かっている ID（カナリア）
];
async function fetchCatalog() {
const catalog = new Map();
let pageToken = '';
do {
const url = `${API}/models?key=${KEY}&pageSize=200${pageToken ? `&pageToken=${pageToken}` : ''}`;
const res = await fetch(url);
if (!res.ok) throw new Error(`ListModels failed: HTTP ${res.status}`);
const body = await res.json();
for (const m of body.models || []) {
catalog.set(m.name.replace(/^models\//, ''), {
methods: m.supportedGenerationMethods || [],
displayName: m.displayName,
});
}
pageToken = body.nextPageToken || '';
} while (pageToken);
return catalog;
}
const catalog = await fetchCatalog();
let ng = 0;
for (const { model, method } of USED) {
const entry = catalog.get(model);
if (!entry) {
console.log(`NG ${model} :${method} — カタログに存在しない（shutdown 済み or ID 誤り）`);
ng++;
} else if (!entry.methods.includes(method)) {
console.log(`NG ${model} :${method} — 存在するがメソッド非対応（対応: ${entry.methods.join(', ')}）`);
ng++;
} else {
console.log(`OK ${model} :${method} — ${entry.displayName}`);
}
}
console.log(`\n${ng === 0 ? 'PRECHECK: OK' : `PRECHECK: NG ${ng} 件`}`);
process.exit(ng === 0 ? 0 : 1);
2026-08-16 に実行したときの出力です。
OK imagen-4.0-generate-001 :predict — Imagen 4
OK imagen-4.0-fast-generate-001 :predict — Imagen 4 Fast
NG gemini-3.1-flash-image :predict — 存在するがメソッド非対応（対応: generateContent, countTokens, batchGenerateContent）
OK gemini-3.1-flash-image :generateContent — Nano Banana 2
NG gemini-2.0-flash :generateContent — カタログに存在しない（shutdown 済み or ID 誤り）
PRECHECK: NG 2 件
生成リクエストを 1 回も投げずに、メソッドが古いままの移行漏れと停止済み ID の両方を検出できています。exit code を返すので CI に置けます。1・2 行目の Imagen 4 が OK なのは停止前日だったからで、このチェックが答えるのは「いま呼べるか」であって「停止日の後も呼べるか」ではありません。停止日の管理には、上のフローチャートのとおり deprecations ページとの照合が別に必要です。
同じスクリプトを GET /models/{id} で 1 件ずつ確認する実装にすると、当時の記録では最終行が OK gemini-2.0-flash :generateContent — Gemini 2.0 Flash になりました。停止済みの ID を「使える」と報告する偽陰性です。移行前チェックは通ったときに安心するためのものなので、偽陰性がいちばん高くつきます。停止済みと分かっている ID を 1 件カナリアとして固定で混ぜておくと、チェック自体が壊れたときに NG が出なくなることで気づけます。
次の廃止に向けて確認しておくこと
2026-10-15 時点で画像モデルを使っているコードについて、ここまでの材料から確認しておきたいのは次の 4 点です。
-
呼んでいるモデル ID を棚卸しする。
gemini-2.5-flash-imageは 2027-03-15 停止、gemini-3.1-flash-imageは非推奨で停止日未定です -
移行先は作業開始時に deprecations ページで確認する。Imagen 4 の推奨移行先は告知後に
gemini-nano-banana-2.1へ変わりました - 404 のログに URL のメソッドまで残し、認証エラーとは分けて数える。認証が通っていない間は廃止の 404 が見えません
-
存在確認は
ListModelsで行い、停止済み ID のカナリアを混ぜる。GET /models/{id}は停止済みモデルに 200 を返すことがあります
まとめ
冒頭の問いは「廃止後に返るエラーを見て、廃止だと判断できるか」でした。答えは条件付きで、is no longer available を含む 404 が出たときだけ廃止と言い切れます。それ以外の 404 は ID の誤りやメソッドの不一致と同じ文面で、キーが無効なら 404 にすら届きません。
エラーから判断できる範囲が狭い以上、備えの中心はエラーが出る前に置くことになります。ListModels との突き合わせを CI に置き、停止日は deprecations ページで追い、画像モデルの次の停止日である 2027-03-15 までに gemini-2.5-flash-image の呼び出しが残っていないかを確かめておくのが、現時点で取れる手当てです。
関連記事
- Gemini API、モデル廃止スケジュール5件と13本の実装記事を整理した
- Gemini 3.1 Flash Image 入門 — 動画から画像を生成するAPI実装ガイド
- Imagen 4入門 — Ultra・Standard・FastをAPI活用する完全ガイド