モデル選択・ルーティング・生成設定

概要

/model コマンドと --model フラグによるモデル選択、失敗時の fallback（model routing）、実行中の誘導（model steering、experimental）、modelConfigs によるハイパーパラメータ制御を扱う。

仕様

`/model` コマンド

選択肢	内容	モデル
Auto (Gemini 3)	タスクに最適な Gemini 3 モデルを自動選択する	`gemini-3-pro-preview`、`gemini-3-flash-preview`
Auto (Gemini 2.5)	タスクに最適な Gemini 2.5 モデルを自動選択する	`gemini-2.5-pro`、`gemini-2.5-flash`
Manual	特定のモデルを選ぶ	利用可能な任意のモデル

/model コマンド（および --model フラグ）は sub-agent が使うモデルを上書きしない。 そのため --model を使っていてもモデル使用量レポートに他のモデルが現れうる
設定の変更は以後のすべてのやり取りに適用される

使い分けの指針:

既定は Auto。速度と性能のバランスを取り、タスクの複雑さに応じて自動選択する
望む結果が得られないときは Pro を手動選択する（最も高い推論力と創造性）
速い応答が要るときは Flash または Flash-Lite

モデル選択の優先順位

--model コマンドラインフラグ（常に使われる）
GEMINI_MODEL 環境変数
settings.json の model.name
ローカルモデル（experimental）: Gemma のローカルルーターが有効なら、Gemini モデルではなくローカルの Gemma モデルを使ってリクエストを適切なモデルへルーティングする
既定のモデル: 上記のいずれも無ければ既定が使われる。既定は auto

model routing（fallback）

既定で有効。プライマリモデルが利用できないときの耐性を提供する
ModelAvailabilityService がモデルの健全性を監視し、定義されたポリシーに従って利用可能なモデルへリクエストを回す

モデル失敗: 現在のモデルが失敗（クォータやサーバーエラーなど）すると fallback を開始する
ユーザー同意: 失敗の種類とモデルのポリシーによって、fallback への切り替えを尋ねる（既定では常に尋ねる）
- prompt completion や classification などの内部ユーティリティ呼び出しは、gemini-2.5-flash-lite に対する silent fallback チェーンを使い、確認せず設定モデルも変えずに gemini-2.5-flash と gemini-2.5-pro にフォールバックする
切り替え: 承認された場合、またはポリシーが silent fallback を許す場合、現在のターンまたはセッションの残りで fallback モデルを使う

Local Model Routing（experimental）

ルーティング判断にローカルで動く Gemma モデルを使える。ホストモデルへルーティング判断を送らずに済み、コストを抑えつつ同等のレイテンシと品質を狙う
最も簡単な設定方法は gemini gemma setup コマンド

model steering（experimental）

活発に開発中の実験的機能で、既定で無効。/settings から有効にする必要があることがある
有効化: /settings で Model Steering を検索して true にするか、settings.json の experimental.modelSteering を true にする
有効なとき、エージェントが作業中に入力したテキストは steering hint として扱われる
送信すると Gemini CLI は
1. 小さく速いモデルで 1 文の受領確認を生成する
2. アクティブな計画の再評価、更新の分類、影響を受けるタスクへの最小差分の適用を指示する内部命令を hint の前に付ける
3. 次のターンの冒頭でエージェントに届ける
用途の例: パスの訂正、手順のスキップ、コンテキストの追加、作業の方向転換、曖昧さの解消

Advanced Model Configuration（`modelConfigs`）

power-user 向け機能。設定値は最小限の検証でモデルプロバイダへ直接渡されるため、非互換なパラメータの組み合わせは API のランタイムエラーになりうる。

2 つのプリミティブがある。

Aliases（`customAliases`）

名前付きで再利用可能な設定プリセット
extends で他のエイリアス（chat-base などのシステム既定を含む）を継承できる。子は継承した設定を上書き・追加できる
具体的な model を持たない抽象エイリアスも作れる（他のエイリアスのベースとしてのみ使う場合）

Overrides（`overrides`）

実行時のコンテキストに応じて設定を注入する条件付きルール。モデルリクエストごとに動的に評価される
match の条件
- model: 要求されたモデル名またはエイリアス
- overrideScope: リクエストのスコープ（通常は agent 名）

解決の手順

Step 1: エイリアス解決

要求されたモデル文字列を、システムの aliases とユーザーの customAliases をマージしたマップから探す
見つかれば extends チェーンを再帰的に解決する
親から子の順にマージする（子が勝つ）
見つからなければ、その文字列を生のモデル名として扱う

Step 2: override の適用

一致するすべての override を特定する
specificity（match オブジェクト内の一致キー数）で優先度付けする。 具体的な一致（model + overrideScope）が広い一致（model のみ）を上書きする
specificity が同じ場合は overrides 配列の定義順が保たれ、後のものが勝つ
ソート済みの override の設定を、ベース設定へ順にマージする

`ModelConfig` オブジェクト

プロパティ	型	内容
`model`	string	呼び出すモデルの識別子
`generateContentConfig`	object	`@google/genai` SDK に渡す設定オブジェクト

generateContentConfig の主なパラメータ: temperature（低いほど決定的、0.7 超で創造的）、topP、maxOutputTokens、thinkingConfig（thinkingBudget、includeThoughts など。推論能力を持つモデル向け）

設定

{
  "modelConfigs": {
    "customAliases": {
      "precise-mode": {
        "extends": "chat-base",
        "modelConfig": {
          "generateContentConfig": { "temperature": 0.0, "topP": 1.0 }
        }
      }
    },
    "overrides": [
      {
        "match": { "overrideScope": "codebaseInvestigator" },
        "modelConfig": {
          "generateContentConfig": { "thinkingConfig": { "thinkingBudget": 4096 } }
        }
      }
    ]
  }
}

{
  "experimental": { "modelSteering": true }
}