Googleは、Gemini 3.7 Flashの3週間後の2026年9月2日に、Gemini 3.8 Flashを、同じ導入価格でほぼ同じ速度でリリースしました。モデルIDはgemini-3.8-flashで、プレビューサフィックスはなく、モデルカードには「Gemini 3.7 Flashをベースにしている」と記載されています。そのため、ほとんどのチームは1行の置き換えを期待しています。単純なチャットプロンプトであれば、その通りです。思考パラメーターの設定、サンプリングの調整、ツールループの実行を行うものに関しては、確認すべき9つの項目があり、そのうち2つは3.7 Flashでは発生しなかったエラーを返します。
このガイドは、GoogleのGemini 3.8 Flashの新機能ページとGemini 3開発者ガイドから作成されたそのチェックリストです。各項目には、API形状（Googleが現在主要パスとして扱っているInteractions APIと、ほとんどの3.7 Flashコードで依然として使用されているレガシーなgenerateContentエンドポイント）の両方について、変更前後のフラグメントが記載されています。すべてのフラグメントはApidogに貼り付けて、本番環境に適用する前にライブエンドポイントに対して送信できます。まずモデルの概要を知りたい場合は、Gemini 3.8 Flashとは何かから始めてください。
リストの前に一つ補足説明があります。Googleによると、3.8 Flashは設計上「より一層機能する」とのことです。複雑なタスクでは、より小さな推論ステップを踏み、自身の作業を検証し、ツールを繰り返し呼び出します。これがほとんどの性能向上の源であり、移行の際に設定の差分だけでなく、トークン予算の見直しが必要となる理由でもあります。
何が変わるのか、何が変わらないのか
| 項目 | 3.7 Flash | 3.8 Flash |
|---|---|---|
| モデルID | gemini-3.7-flash |
gemini-3.8-flash |
| コンテキスト / 出力 | 1,048,576 / 65,536 | 同じ |
| 価格（2026年12月31日までの導入価格） | 100万トークンあたり $0.75 / $3.75 | 同じ。その後、2027年1月1日からは両方とも$1.50 / $7.50 |
| 思考レベル | low, medium, high | 同じ。minimalは検証エラーを返す。デフォルトはmedium |
| タスクあたりのトークン数 | ベースライン | 平均で出力トークンが30%増加（Artificial Analysis調べ） |
| 関数結果 | call_id + name |
両方必須、強制 |
| サポート状況 | 「完全にサポートを継続」、廃止予定日なし | 現在 |
価格行のソース：GoogleのGemini API料金ページ。ここでは、3.6、3.7、3.8 Flashの行は同じです。
ステップ0：そもそも移行するかどうかを決定する
移行を強制するものではありません。Googleのローンチ投稿では、「Gemini 3.7 Flashは引き続き完全にサポートされる」と述べられており、廃止予定日は公表されていません。トークンあたりの価格は変わらないため、唯一のコスト差は利用量です。Artificial Analysisは、彼らの指標において、3.8 Flashが「高レベルの思考（high thinking）」でタスクあたり約48,000の出力トークンを使用すると測定しました。これは3.7 Flashよりも30%多く、同一の料金率でタスクあたりのコストを$0.40から$0.58に上昇させました。彼らの指標スコアは56から59に上昇し、τ³-Bankingでのツール利用精度は12ポイント上昇して45%になりました。
したがって、トレードオフは、タスクあたりのトークン数が増える代わりに、タスクあたりの機能が向上するということです。ワークロードが短く、レイテンシに敏感な場合、または3.7 Flashで既に評価をパスしている場合は、そのまま据え置くことができます。3.8 Flashと3.7 Flashの比較の完全版には、ワークロード別の決定マトリックスが掲載されています。移行する場合は、読み続けてください。
ステップ1：両方のAPI形状でモデルIDを交換する
Interactions API（GoogleのGemini 3.x向け主要API）：
{"model": "gemini-3.7-flash", "input": "..."}
{"model": "gemini-3.8-flash", "input": "..."}
レガシーなgenerateContent（引き続きサポートされており、廃止予定なし）：
POST /v1beta/models/gemini-3.7-flash:generateContent
POST /v1beta/models/gemini-3.8-flash:generateContent
Python SDK、両方のパス：
client.interactions.create(model="gemini-3.8-flash", input=..., generation_config={"thinking_level": "medium"})
client.models.generate_content(model="gemini-3.8-flash", contents=..., config=types.GenerateContentConfig(thinking_config=types.ThinkingConfig(thinking_level="low")))
Interactions APIを使ったことがない場合は、3.8 Flash APIガイドが両方の形状を網羅しています。古い3.7 Flash APIウォークスルーはgenerateContentのみを扱っていたため、このガイドでは両方を示しています。
9項目の移行チェックリスト
これらを順番に進めてください。1から4の項目は、すぐに現れる設定変更です。5と6の項目は、ツールループとマルチターン状態に影響します。7から9の項目は、テストでしか気づかない計画とメディアの変更点です。
1. thinking_level: "minimal"を"low"にマッピングする
これが最初に問題となる点です。3.8 Flashはlow、medium、highを受け入れます。minimalを送信すると、検証エラーが返されます。何も送信しない場合のデフォルトはmediumです。Gemini 3 Proはデフォルトでhighであるため、Proの設定をそのままコピーして一致すると仮定しないでください。
変更前（3.7 Flash、Interactions）：
{"generation_config": {"thinking_level": "minimal"}}
変更後（3.8 Flash）：
{"generation_config": {"thinking_level": "low"}}
レガシー形状、変更後：
{"generationConfig": {"thinkingConfig": {"thinkingLevel": "low"}}}
Googleの思考に関するドキュメントでは、lowはレイテンシ設定、mediumは複雑なコードやエージェント的な作業のデフォルトと説明されています。ルートごとにどのレベルを使用するかは別の記事ですが、移行の目的では、lowがminimalの直接的な代替となります。
2. temperature、top_p、top_kを削除する
GoogleのすべてのGemini 3モデルに対するガイダンスは、temperatureをデフォルトの1.0に保つことです。それを下げると「ループやパフォーマンスの低下を引き起こす可能性があります」。多くの3.7 Flashの設定には、以前の世代から残っているtemperature: 0.2が含まれています。サンプリングキーを設定するのではなく、削除してください。
変更前：
{"generationConfig": {"temperature": 0.2, "topP": 0.9, "topK": 40}}
変更後：
{"generationConfig": {"thinkingConfig": {"thinkingLevel": "medium"}}}
再現性のあるJSONを得るために低いtemperatureを使用していた場合は、代わりに構造化出力を使用してください。これらは3.8 Flashでサポートされており、サンプリングに手を加えることなくスキーマに沿った応答を提供します。
3. thinking_budgetをthinking_levelに置き換える
thinking_budgetは整数のトークン上限でした。thinking_levelは文字列の列挙型です。それらの間に算術的なマッピングはないため、意図に基づいてレベルを選択してください。レイテンシが重要なルートにはlow、デフォルトのルートにはmedium、最も難しい多段階ルートにはhighを設定します。
変更前：
{"generationConfig": {"thinkingConfig": {"thinkingBudget": 4096}}}
変更後：
{"generationConfig": {"thinkingConfig": {"thinkingLevel": "low"}}}
思考トークンは引き続き出力トークンとして課金され、usageMetadata.thoughtsTokenCountで報告されるため、コスト管理はハードキャップからレベル選択とテストでのアサーション（下記の回帰テストのセクションを参照）へと移行します。
4. candidate_countを削除する
Gemini 3以降は、複数の候補をサポートしていません。そのキーを削除し、candidates[1]以降をインデックスしていたコードもすべて削除してください。
変更前：
{"generationConfig": {"candidateCount": 2}}
変更後：
{"generationConfig": {}}
複数の候補をサンプリングして最適なものを選んでいた場合、3.8 Flashではより高い思考レベルを設定することで、1つの応答内で検証が行われます。
5. すべての関数結果にcall_idとnameを付与する
これが2つ目の大きな変更点です。3.8 Flashでは、返送するすべての関数結果に呼び出しのidと関数nameの両方が含まれている必要があります。GoogleのGemini 3ガイドには「すべてのFunctionResponseオブジェクトにcall_idとnameを含めるようにする」と記載されています。名前だけをエコーしていたコードは、ツール結果のターンで失敗します。
Interactions API、変更後：
{
"previous_interaction_id": "<id from the function_call step>",
"input": [{
"type": "function_result",
"name": "get_weather",
"call_id": "<id from the function_call step>",
"result": [{"type": "text", "text": "{\"temp_c\": 24}"}]
}]
}
モデルのfunction_callステップはid、name、argumentsを提供します。最初の2つはそのまま返します。レガシーな形状では、functionResponse部分が、モデルのfunctionCall部分のidと一致するidという名前のフィールドに、nameとresponseとともに同じ値を持ちます。Googleの関数呼び出しリファレンスには正規の例があり、3.8 Flash関数呼び出しガイドでは、3.8 Flashが3.7 Flashよりもタスクあたりのツール呼び出し回数が多い理由を含め、完全な2ターンループを詳しく説明しています。
6. 思考シグネチャを、受け取ったそのままの形で返す
Gemini 3モデルは、応答部分に思考シグネチャを付与します。次のターンを自分で構築する際は、テキストだけでなく、すべてのパートタイプについて、シグネチャを含め、すべてのパートをそのまま返してください。それらを削除したり、再シリアル化したりすると、次のステップでのモデルの連続性が低下します。
Interactions APIでは、サーバーに状態を保持させることでこの作業が不要になります。previous_interaction_idを渡すと、Googleが履歴を保持します。ステートレスな呼び出しでstore: falseを設定した場合、再び履歴を自分で管理する必要があり、思考ブロックとシグネチャを自分で返送する必要があります。レガシーなgenerateContentでは、常に履歴を自分で管理するため、最後の応答からトリミングされたコピーからcontentsを再構築するすべてのコードを監査してください。
7. ルートあたりのトークン予算を増やす
この項目はエラーを発生させないため、見過ごされがちです。Artificial Analysisの出力トークン30%増加という数値は、彼らの指標における「高レベルの思考（high thinking）」での平均です。Google自身の表現では、このモデルは「設計上、より長い時間実行される複雑なタスクでより多くのトークンを使用できる」とし、その使用量は「特に高い労力を要するレベルで増加する」と述べています。
- グローバルではなく、ルートごとに計画する：
- レイテンシに敏感なエンドポイント：
low。AAは、lowではタスクあたり0.8分、highでは2.5分、タスクあたり$0.24対$0.58と測定しました。 - デフォルトルート：
medium、同じ指標でタスクあたり約$0.41。 - エージェントループ：タスクあたりのツール呼び出しターンが増えることを想定し、トークン数だけでなくターン数でループを制限してください。
また、65,536の出力トークン上限も見直してください。思考を含めて4万トークンを返していた3.7 Flashのプロンプトは、上限に近づく可能性があります。料金を試算する場合は、3.8 Flashの料金内訳で3つのレベルすべてにおけるタスクあたりの数値が計算されています。
8. PDFとビデオでmedia_resolution_highをテストする
3.8 Flashは、テキスト、画像、ビデオ、オーディオ、PDF入力を受け入れます。メディア解像度設定は、各メディア入力が消費するトークン数を変更し、コストはメディアタイプによって異なるため、PDFページでは安価な設定が、長いビデオでは高価になる可能性があります。測定せずに、3.7 Flashからグローバルな高解像度設定をそのまま引き継がないでください。各解像度で代表的なPDFと代表的なビデオを1つずつ送信し、usageMetadata.promptTokenCountを比較してください。
9. 画像セグメンテーションの呼び出しをすべて削除する
Gemini 3モデルでは画像セグメンテーションはサポートされていません。3.7 Flash時代のパイプラインが古いGeminiモデル経由でセグメンテーションをルーティングしていた場合、そのパスはこの移行とは別です。プロンプトが3.8 Flashにセグメンテーションマスクを要求した場合、使用可能な出力を返すのではなく、失敗すると予想してください。画像生成、音声生成、およびLive APIも、モデルページによると3.8 Flashではサポートされていません。
Apidogで回帰計画を構築する
2つの破壊的変更とトークン使用量の変化を伴う移行には、一度きりのcurlではなく、再現性のある比較が必要です。以下は、Apidogで使用する設定です。ApidogはAPIクライアントでありテストランナーであるため、リクエストを送信し、応答をチェックし、実行をスケジュールします。モデル自体は実行しません。
- 環境と変数。
GEMINI_API_KEYを秘密変数として保存し、MODEL変数を持つGemini環境を作成します。generateContentリクエストのURLとInteractionsリクエストのmodelフィールドで{{MODEL}}を使用すると、同じ保存されたリクエストがどちらのモデルに対しても実行されます。 - ゴールデンプロンプト。 実際のルートを表す10〜20個のプロンプト（短いチャットターン、構造化出力抽出、モックツールを使用した2ターン関数呼び出し、1つのPDF入力、1つのビデオ入力）を保存します。それぞれがテストシナリオ内の1つのリクエストとなります。
- アサーション。 リクエストごとに3つ追加します。
- ステータスが200であり、応答ボディがJSONスキーマに一致すること。構造化出力ルートの場合、ダウンストリームで解析するフィールドについてアサートします。
usageMetadata.thoughtsTokenCountが、ルートごとに設定した上限（例：lowルートで8,000）を下回っていること。これは、mediumにサイレントにフォールバックした設定を捕捉するガードです。usageMetadata.totalTokenCountが、項目7で設定したルートの予算を下回っていること。
- 並行実行。 シナリオを複製し、一方の
MODELをgemini-3.7-flashに、もう一方をgemini-3.8-flashに設定して両方を実行します。Apidogのテストレポートは、アサーションごとの合否と応答ボディを示すため、プロンプトごとのトークン差分はログから再構築するのではなく、1つのビューで確認できます。関数呼び出しシナリオの場合、返送したcall_idが前のステップのfunction_callのidと等しいことをアサートに追加します。 - スケジュール化。 3.8 Flashシナリオをスケジュール実行に設定し、ロールアウト期間中にトークン上限が毎日チェックされるようにします。スケジュールAPIテストガイドで設定方法を説明しています。アプリで手順を追いたい場合は、Apidogをダウンロードして、上記のcurlフラグメントをインポートしてください。
ロールバック：3.7 Flashを設定フラグの背後に保持する
3.7 Flashは引き続き完全にサポートされ、3.8 Flashと同じ価格であるため、ロールバックは安価です。モデルIDをコードではなく設定に保持します。
{"gemini_model": "gemini-3.8-flash", "gemini_fallback_model": "gemini-3.7-flash"}
次の3つのルールにより、フラグは安全になります：
- 移行したリクエスト形状を両方のモデルで維持します。項目1〜6（
minimalなし、サンプリングキーなし、thinking_budgetではなくthinking_level、candidate_countなし、call_id+name、シグネチャの保持）はすべて3.7 Flashでも有効であるため、フラグを切り替えても2つ目のコードパスは必要ありません。 - ルートごとに展開します。トークン差分が最小である
lowレベルのレイテンシールートを最初に切り替え、並行シナリオが数日間パスした後、エージェントループを最後に切り替えます。 - エラーだけでなく、トークンにも注意してください。3.8 Flashでのロールバックトリガーは、4xxエラーよりもコストやレイテンシの回帰である可能性が高いため、トークン上限のアサーションをアラートに組み込んでください。
よくある質問
Gemini 3.8 Flashは3.7 Flashよりも高価ですか？ トークンあたりではそうではありません。どちらも2026年12月31日までは入力$0.75 / 出力$3.75（100万トークンあたり）で、2027年1月1日からは両方とも$1.50 / $7.50に上昇します。タスクあたりでは、3.8 Flashは設計上より多くのトークンを使用します。Artificial Analysisは、彼らの指標における「高レベルの思考（high thinking）」で約30%多くの出力トークンを測定しました。
thinking_level: "minimal"をそのままにしておくとどうなりますか？ 3.8 Flashでは、リクエストが検証エラーで失敗します。lowに置き換えてください。思考レベルガイドで、残りの各レベルの機能と違いの測定方法を説明しています。
3.8 Flashを使用するためにInteractions APIに移行する必要がありますか？ いいえ。generateContentはレガシーと説明されていますが、廃止予定日はなく、引き続き完全にサポートされており、3.8 Flashでも動作します。Interactions APIはprevious_interaction_idを介してサーバーサイドの会話状態を追加し、これにより項目6の思考シグネチャの管理作業が不要になります。
3.7 Flashは廃止されますか？ Googleは「完全にサポートを継続する」と述べており、廃止予定日は公表していません。それが設定フラグによるロールバックを可能にしている理由です。
3.7 Flash用に調整した同じtemperatureを維持できますか？ GoogleのすべてのGemini 3モデルに対するアドバイスは、temperatureを1.0にすることです。3.7 Flashで既にそれをオーバーライドしていた場合、この移行はそれを削除して評価をチェックするタイミングです。構造化出力は、決定論的な形状を得るためのサポートされている方法です。
段階的に展開する
移行自体は小さなものです。IDの変更が1つ、設定の削除または名前変更が4つ、ツールループフィールドが2つ、そしてシグネチャの監査です。時間がかかるのは、ルートごとのトークン予算が維持されることを証明する部分であり、これはテストの問題です。ゴールデンプロンプトを保存し、スキーマとトークン上限をアサートし、数値が安定するまで3.7 Flashと3.8 Flashを並行して実行し、その後、ルートごとにフラグを切り替えます。ルートが回帰した場合、フラグはコード変更なしで3.7 Flashに戻し、改善されたルートは維持できます。