Gemini 3 の思考レベル：設定と比較の方法

Gemini の思考レベルは推論に使う余地を調整する設定です。一定の手順数、応答時間、正答率を保証するものではありません。モデルのバージョン、対象タスク、結果の確認方法とセットで選びましょう。

この記事は Gemini 3 系列を扱います。常に最新の系列を紹介する記事ではなく、Google API の設定がそのまま第三者のチャット画面にあるとも限りません。

モデルごとに対応する値を確認する

2026 年 9 月 18 日に確認した Google の思考機能ドキュメントでは、Gemini 3 Pro preview は low と high、Gemini 3.1 Pro preview はそれに加えて medium に対応しています。Gemini 3 Flash preview には minimal、low、medium、high があります。これらのモデルの既定値は high であり、medium が共通の既定値ではありません。

導入時には実際のモデル ID に対応する資料を再確認してください。ID、API の種類、SDK のバージョン、実行日を記録します。「Pro」という表示だけでは同じ条件を再現できません。

タスクに合わせて候補を比較する

Low は、指定された分類への振り分けや明確な値の抽出など、範囲の限られた作業の候補です。情報不足や該当カテゴリがない入力を含め、勝手に分類を追加しないか確認します。低い設定が推論の完全な停止を意味するわけではありません。

Medium が使える場合は、複数の条件を同時に守る作業で比較できます。例えば、日付や例外を保持しながら文書を決められた項目に整理するタスクです。同じ原文で既定値と比較し、短さや自信のある表現を正確さと取り違えないようにします。

High は、矛盾する資料の照合や修正パッチの検査など、複数の確認が必要な作業で試せます。待ち時間、利用量、確認の手間に見合うだけ失敗が減るかを判断してください。資料にない事実を設定だけで補うことはできません。

MidassAI ChatでGemini 3を試す

API と SDK の例を混ぜない

Interactions と generateContent では会話状態の扱いが異なります。SDK の引数名と REST のフィールド名も同一とは限りません。利用するインターフェースの公式例から始め、サーバーが設定を受け付けることを確認します。

独自に推測したエンドポイントを使わず、認証情報はローカル環境に置き、プロンプトや評価記録に含めないでください。タスク ID、モデル、API、候補レベル、合格条件をまとめた評価メモは、実行用のリクエストとは別に管理します。

一度に変える設定は一つにする

Gemini 3 開発ガイドは temperature を 1.0 のままにすることを推奨し、下げると望ましくない挙動につながる場合があると説明しています。推論を強めて temperature を 0.2 に下げれば常に安定する、という使い方は避けましょう。

プロンプト、ツール、入力資料、出力上限を固定し、思考レベルだけを変えます。同じリクエストで thinking_level と thinking_budget を併用せず、クライアントが予算を自動追加していないかも確認してください。

失敗を検出できる評価セットを用意する

抽出タスクなら、値が明確なケース、値がないケース、値が矛盾するケース、作業と無関係な指示を含む資料を用意します。出力を見る前に期待結果を書き、安定性が重要なケースは繰り返します。

設定、完了状況、最初の応答までの時間、全体の時間、取得できる利用量、修正時間を記録します。JSON として有効でも顧客 ID が誤っていれば失敗です。値が正しくても単位が変わっていれば別の誤りとして記録し、形式と内容を分けて評価します。

全体の待ち時間と費用を見る

通信、ツール、再試行、出力長、サービスの負荷も時間に影響します。API が返す利用量と適用料金、または第三者サービスの実際の利用記録で判断し、設定名だけから料金を推測しないでください。

一回の遅い回答が修正不要なら、速い回答を何度も直すより早く終わることもあります。タイムアウトも理由付きで記録し、再試行を制限します。文章生成の再送と外部操作の再実行は分けて扱う必要があります。

チャットで使う場合

説明のある推論設定が実際に提供されていれば、表示名を記録して同じ入力を比較します。設定がなければプロンプトの品質は評価できますが、API の思考レベルを測定したとはいえません。MidassAI に Deep Think スイッチや利用量計、スケジューラーがあると仮定しないでください。

合格条件を満たす最も負担の少ない構成を選び、モデルや連携方法が変わったら再評価しましょう。