Google は 2 つの Gemini Flash API スラッグを非推奨にし、各古い名前から新しい代替名にトラフィックを自動的にルーティングし、小規模に見えるモデル カタログの変更を作成し、ゲートウェイ、分析、顧客レポートに大きな影響を与えます。
Google の Gemini API リリースノート (2026 年 10 月 8 日付け) によると、gemini-3.7-flash は非推奨となり、gemini-3.8-flash に置き換えられます。非推奨の 3.7 Flash スラグに送信されたリクエストは、自動的に 3.8 Flash にルーティングされます。 Google も gemini-3.5-flash を非推奨にし、gemini-3.6-flash と同じ自動再ルーティング動作に置き換えました。
同社は deep-research-pro-preview-12-2025 も非推奨とし、Deep Research エージェントは 2026 年 10 月 23 日に閉鎖され、新しい Deep Research エージェントへの移行パスが用意されると述べています。これにより、古いプレビュー エンドポイントが消滅する前に、チームが運用環境での使用を特定し、固定 ID を変更し、出力動作を検証するための短い時間枠が得られます。
Gemini API
での変更点当面の運用上の変更は簡単です。リクエストで 1 つのモデルを指定し、Google で別のモデルを提供できます。これは、開発者がアプリケーションを gemini-3.7-flash から gemini-3.8-flash まで意図的に編集することとは異なります。これはプロバイダ側の置換です。
単純なアプリケーションの場合、応答が受け入れられる限り、違いは目に見えない可能性があります。評価、顧客向け分析、規制されたワークフロー、またはコストの帰属を実行するチームにとって、それは重要です。要求されたモデルのみを記録するログ エントリにより、非推奨のモデルが依然としてトラフィックを処理しているように見える可能性があります。提供されたモデルのみを記録するダッシュボードでは、顧客が依然として古いスラッグを呼び出しているという事実が隠蔽される可能性があります。どちらのビューも不完全です。
ここでは、開発者の利便性以上に AI モデルのエイリアス が重要になります。ゲートウェイは少なくとも 3 つのケースを区別する必要があります。プラットフォームによって作成された安定した顧客エイリアス、意図的にフローティングされるプロバイダー エイリアス、古いパブリック モデル ID を新しい ID にサイレントにマッピングするプロバイダー非推奨ルートです。 3 つすべてを同じフィールドとして扱うと、あいまいな分析が作成されます。
自動再ルーティングが便利だがリスクがある理由
自動再ルートにより、即時の破損が軽減されます。顧客が gemini-3.7-flash をハードコーディングしている場合、Google の置換ルートにより、チームが構成を更新している間もリクエストを実行し続けることができます。これは、特にモデル ID がスクリプト、パートナー統合、プロンプト、または顧客設定全体に分散されているアプリケーションにとって、実際的なサービス継続性の選択肢です。
その代償として、明示的な制御が失われます。 API 呼び出しがまだ成功している場合でも、モデルを置換すると、レイテンシー、出力スタイル、安全動作、ツールの使用パターン、またはエッジケースの信頼性が変更される可能性があります。開発者は、評価が変動するか、プロンプトの動作が異なるか、報告された使用状況がドキュメントと一致しない理由を顧客から尋ねられるまで、変更に気付かない可能性があります。
チーム用の マルチモデル API ゲートウェイを通じて Google モデルを公開するプラットフォームではリスクが高くなります。これらの製品はプロバイダーとエンドユーザーの間に位置するため、プロバイダーのルーティング動作をどの程度表面化するかを決定する必要があります。古いスラッグを単に転送し、結果として生じる呼び出しに対して通常どおり請求を行うゲートウェイは互換性を維持する可能性がありますが、サポート チームと財務チームには監査証跡が脆弱になります。
ゲートウェイと再販業者のプラットフォームが記録すべき内容
最もクリーンなパターンは、リクエストされたモデル、解決されたプロバイダ モデル、解決の原因となったエイリアス ルールを保存することです。 Gemini のフラッシュ変更の場合、使用状況記録は、顧客が gemini-3.7-flash をリクエストし、Google が gemini-3.8-flash を提供し、その理由が顧客定義のフォールバック ルールではなく Google の非推奨のリルートであることを示すことができる必要があることを意味します。
この区別は、請求サポート、移行計画、製品の信頼性に影響します。顧客がアプリケーションで非推奨のモデルをまだ使用しているかどうかを尋ねた場合、その答えに手動のログ考古学は必要ありません。リセラーがダウンストリームアカウントに通知する必要がある場合は、要求されたレガシースラッグによってセグメント化できる必要があります。内部の評価スイートが失敗し始めた場合、エンジニアはトラフィックがいつ移動したかを推測することなく、提供モデルの変更前後の結果を比較できる必要があります。
Model Gate スタイルの製品の場合、実際の作業は使用状況分析と顧客レポートです。 使用状況分析ダッシュボード では、リクエストされたモデルと提供されたモデルが 1 つのラベルに折りたたまれないようにする必要があります。また、アカウント所有者がプロバイダーのサポートが終了する前に移行をプッシュできるように、非推奨の ID が表示されるようにする必要があります。
Deep Research エージェントのシャットダウンにより、2 番目の種類の期限が追加されます。 Flash リルートとは異なり、Google によれば、deep-research-pro-preview-12-2025 は 2026 年 10 月 23 日にシャットダウンされる予定です。そのプレビュー エージェントを使用しているチームは、無期限の互換性ルーティングに依存するのではなく、移行する必要があります。 Deep Research ワークフローは、長時間実行される調査パイプラインや自動化パイプラインに組み込まれている可能性があるため、移行チェックには、プロンプト、ツールの前提条件、出力形式、保存されているモデルのホワイトリストを含める必要があります。
まだ不確実なことは何ですか
Google のリリース ノートでは、非推奨のスラッグ、代替品、および再ルーティング動作が特定されていますが、ダウンストリーム プラットフォームの運用上の問題がすべて解決されているわけではありません。このメモでは、引用された変更ログ エントリにある古いフラッシュ モデルと代替フラッシュ モデルの間の広範な動作の比較は提供されていません。また、Deep Research プレビュー エージェントとは異なり、非推奨の Flash スラグのシャットダウン日も明記されていません。
そのため、チームにはおなじみの API 管理の問題が残ります。互換性は当面続く可能性がありますが、安定した状態はまだ移行中です。開発者は、明示的なモデルの選択を更新し、置換 ID に対して重要な評価を再実行し、移行中に何が起こったかを説明するのに十分な詳細がログに保持されていることを確認する必要があります。
より広範な教訓は、モデル ID はもはや単純な製品名ではないということです。それらは、安定リリース、移動エイリアス、互換性シム、または非推奨トラップである可能性があります。顧客に信頼性の高い制御を提供したいゲートウェイには、それらの違いを直接表現できるデータ モデルが必要です。