GoogleがGemini 2.5主要モデルを10月終了、GAからPreviewへ移る場合の本番リスク

GoogleはGemini APIで提供しているGemini 2.5系の主要モデルを2026年10月に停止する。

最初の期限は10月2日のgemini-2.5-flash-imageである。続いて10月16日にgemini-2.5-pro、gemini-2.5-flash、gemini-2.5-flash-liteが停止する。

移行先はGemini 3系だが、公式表では一部の代替がPreviewモデルになっている。GAモデルからPreviewへ移る場合、モデル品質だけでなく、変更頻度、停止予告、契約上の扱い、本番SLAを再評価する必要がある。

停止対象と推奨移行先

2026年7月12日時点の公式廃止予定は次の通りである。

Googleは廃止表の日付を「最も早く停止される可能性がある日」と説明し、正確な停止日は利用者へ事前通知するとしている。実務では表の日付を最終期限として扱い、延長を前提にしない。

一つの移行プロジェクトにまとめない

4モデルは用途が異なる。

• Proは高難度推論、長文、複雑なエージェント
• Flashは速度と性能の均衡
• Flash-Liteは大量・低コスト処理
• Flash Imageは画像生成・編集

同じ「Gemini 2.5終了」でも、評価方法、担当部門、障害影響が違う。移行をモデル単位ではなく、ワークロード単位へ分解する。

customer-support-chat -> gemini-2.5-flash
invoice-classification -> gemini-2.5-flash-lite
contract-analysis -> gemini-2.5-pro
creative-image-edit -> gemini-2.5-flash-image

一つのモデルIDを全システムで置き換えると、低コスト処理まで高価なモデルへ移る、または高難度処理が軽量モデルへ落ちる可能性がある。

GAからPreviewへ移る問題

Previewは性能評価だけでは不十分

Previewモデルは一般に、GAモデルより変更や終了の可能性が高い。公式の廃止表でも、PreviewにはGAとは異なる寿命が設定されている。

本番採用時に確認する。

• SLAの対象か
• データ処理条件は同じか
• リージョン制約があるか
• レート制限が安定しているか
• モデルIDが固定できるか
• 自動更新されるか
• 終了通知の期間
• Provisioned Throughput相当の契約が可能か
• 障害時の代替モデル

品質が高くても、契約上の安定性が要件を満たさない場合、本番の主経路にできない。

Previewを隔離する

Preview採用時は、アプリケーションから直接モデルIDを呼ばず、ルーティング層を置く。

production-policy: contract-analysis-primary
  -> current: gemini-3.1-pro-preview
  -> fallback: approved-secondary-model

モデルID、Prompt、ツール、評価セットを同じリリース単位で管理する。Previewが更新された場合、モデルだけが黙って変わらないようにする。

Pro移行で評価すること

gemini-2.5-proからgemini-3.1-pro-previewへ移る場合、長文処理と推論タスクを中心に確認する。

• 長いコンテキストで重要情報を保持できるか
• 指示の優先順位
• 引用の正確性
• 数値・契約条件の抽出
• 複数文書の矛盾検出
• Tool Callの選択
• Tool引数の構造
• JSON Schemaへの適合
• 思考時間とレイテンシー
• 入出力トークン量
• 安全拒否率

平均正解率だけでなく、重大な誤りを個別ゲートにする。

契約金額の誤抽出: 0件
存在しない条項の引用: 0件
無許可ツール実行: 0件
個人情報の不要出力: 0件

Flash移行で評価すること

gemini-2.5-flashからgemini-3.5-flashへの移行では、速度とコストの分布を見る。

• P50、P95、P99レイテンシー
• 最初のトークンまでの時間
• 出力長
• キャッシュ利用
• 1リクエスト当たりの総トークン
• 429率
• タイムアウト率
• 再試行後の成功率
• Tool Call回数
• 同じ品質を得るための再質問回数

単価が低くても、出力が長くなる、再試行が増える、人間確認が増える場合、総費用は上がる。

Flash-Lite移行で評価すること

大量処理では小さな差が月間費用へ大きく影響する。

代表的な評価対象は次である。

• 分類
• 情報抽出
• 要約
• ルーティング
• モデレーション補助
• メタデータ生成
• バッチ処理

正解率だけでなく、誤分類の費用を重み付けする。

cost = API費用
     + 再処理費用
     + 誤分類による業務損失
     + 人手確認

軽量モデルの移行では、1%の精度差が数百万件へ拡大する。

Flash Image移行で評価すること

画像モデルは最初の期限が10月2日であり、テキスト系より早い。

比較する項目は次である。

• 画像生成と編集のAPI形式
• 入力画像の扱い
• 画像サイズ
• アスペクト比
• 日本語文字
• 商品・人物の一貫性
• 安全判定
• 拒否理由
• 生成時間
• 料金
• 再生成率
• 承認率
• メタデータと透かし

画像の品質は主観評価になりやすい。代表Promptを固定し、採用率、修正率、再生成回数を記録する。

Prompt互換性を過信しない

同じPromptを新モデルへ送れば同じ結果になるとは限らない。

モデル世代が変わると次が変化する可能性がある。

• 指示への忠実度
• 冗長性
• JSONの厳密さ
• Tool Callの積極性
• 安全判定
• 長文中の注意配分
• 画像理解
• 多言語表現
• トークン化

Promptをそのまま維持することではなく、業務要件を維持することが目的である。

ツールとエージェントの移行

Geminiをエージェントへ組み込んでいる場合、単発回答より影響が大きい。

確認する。

• Function Callingのスキーマ解釈
• 並列Tool Call
• Tool Callの最大回数
• 無限ループ
• 途中状態の保存
• 長時間処理
• 再試行
• 人間承認
• 検索結果の引用
• Computer Useまたは外部操作

モデルが賢くなるほどツールを積極的に使い、権限範囲を超える可能性もある。新モデルへの移行時は、ツール権限を一時的に読み取り専用へ下げて評価する。

段階移行

1. 利用台帳を作る

モデルID、プロジェクト、APIキー、リージョン、月間量、所有者、業務重要度を一覧化する。

2. 用途別に移行先を決める

公式推奨を出発点にしつつ、SLA、Preview可否、費用、地域条件を確認する。

3. 評価セットを固定する

通常例だけでなく、境界例、過去障害、セキュリティ例、長文、異常入力を含める。

4. シャドー実行する

本番入力を匿名化または許可された範囲で新モデルへ送り、旧結果と比較する。副作用のあるTool Callはモック化する。

5. 一部トラフィックを切り替える

1%、5%、20%、50%、100%のように段階的に増やす。モデル別だけでなく、顧客層、言語、業務種類で偏りを確認する。

6. 切り戻し条件を定義する

• 重大誤答が1件でも発生
• P95遅延が基準超過
• 429率が一定以上
• Tool Call失敗率が増加
• 単位業務当たり費用が上限超過

問題発生後に判断するのではなく、事前に数値化する。

移行スケジュール

公式停止日当日の切り替えを避ける。Prompt調整、権限審査、顧客告知の時間を確保する。

編集部分析

今回の終了で注目すべきなのは、Gemini 2.5という一世代のモデルがまとめて置き換わることと、移行先の成熟度が用途ごとに異なることである。

企業は「新しい世代だから一律に優れている」という前提を置くべきではない。Pro、Flash、Lite、Imageは、性能、費用、安定性の異なる製品である。移行判断はモデルファミリーではなく、業務単位で行う必要がある。

また、GAからPreviewへの移行が必要なワークロードでは、技術評価と契約評価を分離してはいけない。ベンチマークで高得点でも、短い通知期間や強制更新が許容できなければ、本番基盤として不適切である。

モデル終了への耐性を高めるには、モデル名をコードへ埋め込まず、用途名を内部ポリシーへ定義する。

high-accuracy-contract-analysis
low-cost-batch-classification
real-time-customer-chat
commercial-image-editing

この用途名から承認済みモデルへルーティングすれば、次回の世代交代でも業務コードを変更せずに移行できる。

実務チェックリスト

• [ ] Gemini 2.5系の利用箇所を全プロジェクトで検索した
• [ ] 10月2日と10月16日の期限を分けて管理した
• [ ] 用途ごとに移行先を決めた
• [ ] Previewモデルを本番利用できる契約条件か確認した
• [ ] Prompt、構造化出力、Tool Callを回帰試験した
• [ ] トークン量、遅延、429、再試行を比較した
• [ ] 画像の採用率と再生成率を評価した
• [ ] エージェントの権限を下げて移行試験した
• [ ] シャドー実行と段階的トラフィック移行を行った
• [ ] 数値化した切り戻し条件を設定した
• [ ] モデルIDを内部用途ポリシーから分離した
• [ ] 公式停止日前に旧モデル通信をゼロにした

一次情報

• Gemini API deprecations
• Gemini API release notes
• Gemini API models