Gemini 3.6 Flash のデベロッパー ガイド

Gemini 3.6 Flash は、Gemini 3 ファミリーの高速で費用対効果に優れた強力なモデルです。パフォーマンスや価値を損なうことなく、Pro に近いエージェント機能を提供するように設計されたこのモデルは、Gemini API を使用するデベロッパーと Gemini Enterprise Agent Platform を使用する企業向けに一般提供（GA）されています。

このドキュメントでは、3.6 Flash の新機能、Gemini モデル ファミリーにおける位置づけ、3.6 Flash への移行方法、3.6 Flash の使用に関するクイックスタートについて説明します。

Gemini ファミリーにおける位置づけ

Gemini 3.6 Flash は、Gemini 3 ファミリーの主要なエージェント ワークホースです。これにより、深い推論を行う Gemini Pro モデルと高スループットの Gemini Flash-Lite モデルの間のギャップを埋めることができます。Gemini 3.5 Flash と比較して、3.6 Flash は、マルチステップのツール オーケストレーション、フルスタック コードのリファクタリング、ビジュアル推論で大幅に高い品質を実現しながら、使用するトークンと推論ターンを削減しています。Flash の速度と料金で、Pro レベルに近い機能を提供します。

モデルの仕様と比較

次の表は、3.6 Flash、3.5 Flash、3.1 Pro の仕様の一部を比較したものです。

Gemini 3.6 Flash Gemini 3.5 Flash Gemini 3.1 Pro
モデル ID gemini-3.6-flash gemini-3.5-flash gemini-3.1-pro-preview
リリース ステージ 一般提供 一般提供 プレビュー
入力値の型 テキスト、画像、音声、動画 テキスト、画像、音声、動画 テキスト、画像、音声、動画
出力タイプ テキスト テキスト テキスト
コンテキスト ウィンドウ 1,048,576 1,048,576 1,048,576
最大出力トークン長 65,536 65,536 65,536
サポートされるリージョン グローバル、マルチリージョン グローバル、マルチリージョン、南北アメリカ、ヨーロッパ、アジア太平洋 グローバル
サポートされている思考レベル MINIMAL、LOW、MEDIUM、HIGH
（デフォルト: MEDIUM） 		MINIMAL、LOW、MEDIUM、HIGH
（デフォルト: MEDIUM） 		LOW、MEDIUM、HIGH
（デフォルト: HIGH）
重要なポイント 高効率の Agentic Workflows、マルチステップ オーケストレーション、フルスタック コーディング バランスの取れたタスク、ツール呼び出し、中間推論 深い推論、複雑性の高いタスク

サポートされている機能、ツール、使用オプションの完全なリストについては、3.6 Flash モデルのページをご覧ください。

Gemini 3.6 Flash の新機能

3.6 Flash は、マルチステップ オーケストレーション、フルスタック コードのリファクタリング、一般的な推論に最適化されており、前世代よりもトークン効率が大幅に向上しています。

機能とパフォーマンスの更新

3.6 Flash の機能とパフォーマンスの変更点は、次のとおりです。

  • トークンとターンの削減: 3.5 Flash よりもトークン消費量が少なく、推論ステップと会話ターンが少ないマルチステップ ワークフローを完了します。
  • コード生成の改善: アプリケーションの構築、プロトタイピング、IDE エージェント環境全体で、コンパイル失敗率とリビジョン率が低い、よりクリーンなコードを生成します。
  • アクションバイアスの低減: 不要なワークスペース編集や時期尚早な状態変更を行わずに、読み取り専用の診断タスクを解決します。
  • マルチモーダル推論と空間推論: グラフの解釈、視覚的な設計図の変換、マルチ要素のウェブ レイアウトの生成のパフォーマンスが向上しています。
  • コンピュータの使用サポート: エージェント UI 自動化の組み込みツールとしてサポートされています。
  • UI スタイルの設定: 機能的なコードの作成に優れていますが、人間の評価者は、フロントエンドのプレゼンテーションとビジュアル レイアウトについては以前のモデルを好むと指摘しています。これは、明示的な設計ガイドラインを提供することで軽減できます。

動作と API パラメータの変更

3.6 Flash の動作と API パラメータの変更点は、以前のモデルから次のとおりです。

  • ステップの簡潔さ: 3.5 Flash よりも推論ステップが少なくなります。これにより、コードのリファクタリングとツールのワークフローのレイテンシと費用が削減されますが、より長いイテレーション チェーンが必要な拡張マルチターン会話のフォローアップで早期に終了する可能性があります。
  • 事前のプログラムによる検査: 3.5 Flash よりも頻繁に状態を変更する前に、診断コード スクリプト（execute_code）を実行して問題を検査することを優先します。これにより、複雑なバックエンドのリファクタリングにおける診断の精度が向上しますが、以前のバージョンではコードが直接生成されていたシンプルなフロントエンドのウェブタスクやスクリプトタスクで、追加の探索的な検査ステップが実行されることがあります。
  • デフォルトの推論量: 3.5 Flash で導入された中程度のデフォルトの推論量を引き継ぎます。
  • サンプリングのオーバーライドなし: temperature、top-k、top-p パラメータのカスタム値はサポートされなくなりました。カスタム値の設定は API サーフェスで無視されます。代わりに、thinking_level または構造化 JSON スキーマを使用して出力の決定性を制御します。
  • 頻度とプレゼンス ペナルティの制限: これらのパラメータのカスタム値はサポートされなくなりました。これらを設定すると、アクティブな API エラーがスローされるようになりました。
  • 最後の入力ターンのロールが「Model」である API リクエストはサポートされていません。
  • 会話履歴の空のターンは削除されます。
  • 無効な思考シグネチャはエラーを生成するようになりました。
  • 厳密な関数呼び出し: FunctionResponse は、前の FunctionCall の id、name、実行回数と厳密に一致する必要があります。関数レスポンス テキスト内にインライン指示を直接追加し、2 つの改行（\n\n）で区切ります。

クイックスタート

始める前に、アプリケーションのデフォルト認証情報（ADC）または API キーを使用して Agent Platform に対する認証を行う必要があります。詳しくは、Gemini Enterprise Agent Platform を使ってみるをご覧ください。

次のコードブロックで、PROJECT_ID をプロジェクト ID に置き換えます。

インストール

最新の google-genai SDK を使用していることを確認します。

pip install --upgrade google-genai

基本的なリクエスト

Python

from google import genai

client = genai.Client(enterprise=True, project="PROJECT_ID", location="global")

response = client.models.generate_content(
  model="gemini-3.6-flash",
  contents="How does AI work?",
)
print(response.text)

REST

curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.6-flash:generateContent \
-d '{
  "contents": {
    "role": "USER",
    "parts": { "text": "Why is the sky blue?" },
  },
}'

3.5 Flash または 3.1 Pro から 3.6 Flash に移行する

3.5 Flash または 3.1 Pro から 3.6 Flash に移行する手順は次のとおりです。

  1. モデル ID を更新する: API 呼び出しのモデル文字列を gemini-3.6-flash に変更します。
  2. 新しい Gemini 3 ファミリーの API ルールにコードを適応させる: Gemini 3.6 Flash は、Gemini 3 ファミリー全体で確立されたパラメータ ルールと API 規則を厳格に適用します。
    • temperature、top-K、top-P を削除する: ペイロードからこれらのカスタム パラメータを削除します。エラーはスローされませんが、モデルはそれらを完全に無視します。代わりに、thinking_level パラメータまたは json_schema 構造化出力を使用して、出力の決定性を制御します。
    • 頻度とプレゼンスのペナルティを削除する: 頻度またはプレゼンスのペナルティのカスタム構成を削除して、API 呼び出しでランタイム エラーがスローされないようにします。
    • チャット統合でモデルのプリフィルが試行されないようにする: メッセージの履歴配列を確認して、API ペイロードが空のユーザー ターンまたはモデルターンで終わらないようにします。履歴配列の最後のオブジェクトが「model」ロール（GenerateContent API）または「model_output」タイプ（Interactions API）の場合は、厳格な検証エラーが発生しないようにシーケンスを再構築します。
    • thinking_level を使用する: 非推奨の thinking_budget パラメータのインスタンスを削除し、代わりに thinking_level を使用します。
    • 厳格な関数呼び出し規則を適用する: FunctionResponse は、前の FunctionCall の id、name、実行回数と厳密に一致する必要があります。インライン指示を追加する必要がある場合は、2 つの改行（\n\n）で区切って、関数レスポンス テキスト内に直接配置します。
  3. ワークフローのシフトを考慮する:
    • アプリケーションがマルチターンの会話ループに依存している場合は、ワークフローをテストして、モデルの新しいステップの簡潔さによって早期に終了しないことを確認してください。
    • フロントエンド エージェントまたは基本的なスクリプト エージェントを構築する場合は、モデルが事前にプログラムによる検査を行うという新しいバイアスにより、不要な探索的 execute_code 呼び出しが発生していないかモニタリングします。

ツール導入前のテキスト要件の回避策

プロンプトで、ツール呼び出しの直前にモデルが構造化テキスト（XLM、YAML、Json など）（<UPDATE>...</UPDATE> など）を出力する必要がある場合、ツール呼び出しが Malformed_Function_Call エラーで失敗することがあります。この問題を解決するには、次のいずれかの回避策を使用します。

  • （推奨）ツール前のメモを未加工のテキストではなく、専用の update() 関数呼び出しに配置するようにモデルに指示します。詳しい実装手順については、次のセクションをご覧ください。
  • 構造化テキストではなく、マークダウン ヘッダー（# UPDATE、## PLAN など）としてメモを記述するようにモデルに指示します。
  • ツール呼び出しの前にモデルにテキストを出力させないでください。

推奨される解決方法: 専用の関数呼び出しで作業メモをラップする

元の指示の代わりに、

Before calling a tool, in every response you MUST first output a single
`<UPDATE>` part as specified, don't skip this part or any of required sub-tags
within `<UPDATE>`.

次の更新された手順を使用してください。

Before calling any other tool, in every response you MUST first call `update`
with all required parameters (previous_step, plan, next_step, external).

お客様のリクエストで、古い <UPDATE> XML 形式への参照をすべて更新します。次に、更新関数に対応する関数宣言を追加します。

{
  "name": "update",
  "description": "Update working notes (previous step analysis, plan, next step, external note).",
  "parameters": {
    "type": "OBJECT",
    "properties": {
      "previous_step": {
        "type": "STRING",
        "description": "Key findings and outcomes since the previous step."
      },
      "plan": {
        "type": "STRING",
        "description": "The current status of the plan."
      },
      "next_step": {
        "type": "STRING",
        "description": "Brief explanation of the immediate next action according to the plan."
      },
      "external": {
        "type": "STRING",
        "description": "A short, plain-language note shown to the User about what you are ABOUT TO DO next."
      }
    },
    "required": [
      "previous_step",
      "plan",
      "next_step",
      "external"
    ]
  }
}

モデルは同じステップで 2 つの呼び出しを行います。構造化 XML を置き換える update() 呼び出しと、実行する実際の関数呼び出しです。

参考情報