Gemini 3.6 Flash APIアップグレード：3.5 Flashから安全に移行する手順

Gemini 3.5 FlashでコードアシスタントやAIエージェントを運用している開発者は、モデル名を変更するだけでは安全に移行できません。Gemini 3.6 Flash APIアップグレードでは、モデルID、思考設定、関数呼び出し、多モーダル入力、会話状態を順番に確認する必要があります。この記事では、比較表、実装手順、回帰テスト、灰度切り替え、API回退の方法をまとめます。

Gemini 3.6 Flashへすぐ移行すべきプロジェクト

Gemini 3.6 Flashは2026年7月21日に公開された安定版で、コード生成、エージェント処理、多モーダル推論を重視したモデルです。公式仕様では、入力はテキスト、画像、動画、音声、PDFに対応し、入力トークン上限は1,048,576、出力上限は65,536です。(ai.google.dev)

次の条件に当てはまる場合は、まず検証環境での移行優先度が高いです。

・コード修正を伴うAIエージェントを運用している
・関数呼び出しを複数回実行するワークフローがある
・画像、動画、音声、PDFを同じ会話で扱っている
・短い応答より、少ないターンでタスクを完了させたい
・Computer Useを使った画面操作を検討している

一方、単純な分類や短文生成だけで、現在の品質と速度に不満がない場合は、急いで本番を切り替える必要はありません。まず同じ入力セットで、処理時間、出力トークン、失敗率、手動修正量を比べるべきです。

ポイント： 移行理由は「新しいモデルだから」ではなく、現在の処理で発生している反復回数やツール呼び出しの多さで判断します。

Gemini 3.5 Flashから3.6への移行で見落としやすい点

移行前に、次の項目をリポジトリとデプロイ設定から洗い出します。

1. 環境変数や設定ファイルに古いモデルIDが残っていないか
2. SDK、API形式、ストリーミング処理を別々に管理できているか
3. temperature、top_p、top_kを送信していないか
4. thinking_budgetを使っていないか
5. 直前のターンをモデルメッセージとして事前入力していないか
6. 関数応答に呼び出しIDと関数名が含まれているか
7. 自動操作に確認画面や権限制限があるか

Gemini 3.6 Flashでは、サンプリング関連の設定が非推奨となり、将来のモデルではエラーになる可能性があります。また、thinking_budgetはthinking_levelへの置き換えが必要です。公式の移行案内では、candidate_countの削除や、複数ターンでのprevious_interaction_id利用も案内されています。(ai.google.dev)

API方式を先に固定する

新規のエージェント構築ではInteractions APIを使う設計が案内されていますが、既存のgenerateContent APIも引き続き利用できます。既存システムを一度に全面変更すると、モデル変更とAPI変更の原因を切り分けにくくなるため、最初は同じAPI方式のままモデルだけを切り替える方法が安全です。(ai.google.dev)

※注意： Gemini 3.6 Flash API互換性を確認するときは、「モデル変更」と「API方式変更」を同じリリースに入れないでください。

Gemini 3.6 Flash APIアップグレードの設定手順

1. 旧モデルの使用箇所を一覧化する

まず、アプリケーション、バッチ、CI/CD、ローカル用スクリプト、監視ジョブを検索します。モデルIDを直接書いている箇所だけでなく、環境変数、設定ファイル、テスト用モックも対象にしてください。

grep -R "gemini-3.5-flash" .
grep -R "thinking_budget\|temperature\|top_p\|top_k" .

2. Gemini 3.6 FlashのモデルIDを固定する

Gemini 3.6 FlashのモデルIDはgemini-3.6-flashです。本番では曖昧な最新エイリアスより、安定版の具体的なIDを環境変数で管理する方が、予期しないモデル変更を避けやすくなります。モデルの現在の入力形式と機能は、公式モデル仕様で確認してください。(ai.google.dev)

export GEMINI_MODEL="gemini-3.6-flash"

3. 最小リクエストを実行する

いきなり本番の会話履歴やツール定義を渡さず、短いテキストだけで接続を確認します。

from google import genai
import os

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model=os.environ["GEMINI_MODEL"],
    contents="次の文章を1文で要約してください。"
)

print(response.text)

この段階では、HTTPステータス、応答時間、空の候補、認証エラー、利用できない地域やプロジェクト設定を記録します。

4. 思考レベルを明示して比較する

Gemini 3.6 Flashの既定の思考レベルはmediumです。従来の設定をそのまま移植するのではなく、minimal、medium、high相当の実運用設定を決め、同じタスクで比較してください。複雑なコード修正やツール連携では、思考量を下げたことで早く終わるとは限らず、再試行や手動修正が増えることがあります。(ai.google.dev)

確認する項目は次の通りです。

・回答の長さ
・計画を立てる順番
・不要なファイル変更の有無
・ツール呼び出し回数
・最終回答までの総時間

5. 本番相当の履歴とツールで回帰する

最後に、実際の関数定義、構造化出力のスキーマ、多モーダル素材、複数ターン履歴を追加します。関数呼び出しでは、関数名、引数の型、必須項目、並列呼び出し、エラー時の再試行を確認してください。

Gemini 3シリーズでは、関数呼び出しと構造化出力を組み合わせる設計が可能です。関数応答に画像などを含める場合の形式も従来と異なるため、テキストだけで成功した後に、画像やPDFを含む応答を別ケースとして検証します。(ai.google.dev)

思考モード、関数呼び出し、構造化出力の検証方法

Gemini 3.6 Flash Agentテストでは、単発の質問ではなく、失敗しやすい一連の作業を使います。

・リポジトリを調査し、変更対象を限定する
・関数でデータを取得し、JSONスキーマで結果を返す
・取得した画像やPDFを追加して判断を更新する
・失敗したツールを1回だけ再試行する
・危険な操作の前に人間の確認を求める

受け入れ基準は「回答が自然か」だけでは不十分です。次の表のように、実行結果を数値化します。

Computer Useは、モデルが画面を見て操作案を返し、アプリケーション側が実行する仕組みです。ブラウザーやファイル操作を自動化する場合は、実行権限、許可ドメイン、削除や送信の確認を必ずアプリ側で制御してください。(ai.google.dev)

画像、動画、音声、PDFを再テストする項目

多モーダル入力は、ファイルを渡して応答が返れば完了ではありません。次の観点で、成功だけでなく失敗時の挙動も確認します。

・MIMEタイプと拡張子が一致しているか
・大きなPDFでページ欠落が起きないか
・動画の時間範囲や音声の転記結果を正しく扱えるか
・複数の画像を渡したとき、対象の取り違えがないか
・タイムアウト時に同じ課金処理を重複させないか
・入力素材をログに残す場合、個人情報をマスキングできるか

公式仕様上、Gemini 3.6 Flashはテキスト、画像、動画、音声、PDF入力に対応します。ただし、アプリ側のアップロード処理、サイズ制限、再試行、保存期間は別に検証する必要があります。(ai.google.dev)

移行効果と費用をどう判断するか

公式料金表では、Gemini 3.6 Flashの標準料金は入力100万トークンあたり$1.50、出力100万トークンあたり$7.50と案内されています。単価だけでなく、ツール呼び出し回数や出力長が変わるため、旧モデルとの比較では1タスク単位の総費用を算出してください。(ai.google.dev)

最低限、次の4つを同じテストセットで記録します。

・1タスクあたりの入力・出力トークン
・最終回答までの経過時間
・APIエラーとツール失敗の割合
・開発者による手動修正時間

例えば、単価が下がっても出力が長くなったり、失敗した関数を再実行したりすれば、実費は増える可能性があります。反対に、少ないターンでコード修正が完了し、手動確認が減るなら、API単価が同じでも移行効果は出ます。

ポイント： 判断単位は「1回の応答」ではなく、「完了した業務タスク」です。

灰度切り替えとAPI回退の実装

本番切り替えは、次の手順で段階的に進めます。

1. 旧モデルと新モデルを同じインターフェースで呼び出せるようにする
2. 固定した評価データで両方の出力を保存する
3. 内部利用者だけを新モデルへ振り分ける
4. 全体の一部トラフィックへ広げる
5. エラー率、遅延、費用、手動修正を監視する
6. 閾値を超えたら環境変数だけで旧モデルへ戻す

API回退では、モデルIDだけでなく、思考設定、ツール仕様、レスポンス変換も管理対象にします。新モデルの応答形式を前提にしたコードを先に本番へ入れると、旧モデルへ戻したときに別の障害が起きるためです。

SpinMacのMac環境で行う回帰検証

Gemini 3.6 Flash API互換性を、SDKだけでなく開発ツールや画面操作まで含めて確認する場合は、専用のMac環境を分けると切り分けやすくなります。ローカル環境と本番環境で権限、Pythonパッケージ、ブラウザー設定、環境変数が混在している場合は、まず同じ構成を再現できる状態を作ります。

SpinMacの環境では、次の流れで検証します。

・利用するSDKとランタイムのバージョンを記録する
・旧モデル用と新モデル用の環境変数を分離する
・コードアシスタント、関数呼び出し、多モーダル入力を個別に実行する
・Computer Useでは画面操作の許可範囲を限定する
・ログ、スクリーンショット、API応答をテスト単位で保存する
・同じ作業を旧モデルでも実行し、差分を確認する

検証期間中に開発環境を占有したくない場合は、SpinMacのMac環境や料金プランを確認し、必要な開発フレームワーク、ツールチェーン、テスト期間を相談してください。

Gemini 3.6 Flash APIアップグレードで起きやすい失敗

・モデルIDだけを置換し、非推奨パラメータを残す
・旧APIとInteractions APIの形式を同じ処理で混ぜる
・関数応答のIDや名前を省略する
・構造化出力を検証せず、そのまま画面に表示する
・PDFや動画だけを本番相当で確認していない
・Computer Useに削除、送信、購入などの操作権限を与えすぎる
・新モデルの結果を保存せず、品質低下の原因を追えない
・回退先の旧モデルを用意していない

特に危険なのは、単純な要約テストが成功したため、エージェント全体も互換性があると判断することです。ツール呼び出し、多ターン状態、異常系、権限確認まで通過して初めて、移行候補として扱えます。

現在の開発用Macだけで検証すると、既存パッケージとの衝突、個人設定の混入、作業中の環境変更、複数人利用による占有が起きやすくなります。共有クラウド環境も手軽ですが、画面操作を伴うAgentではセッション保持や権限分離の確認が増えます。旧モデルを残したまま並行検証し、多モーダルAgentを継続的に動かすなら、SpinMacのレンタルMacで検証環境を分離する方が、原因の切り分けと回退を進めやすい選択肢です。