目次
1.はじめに
環境情報
2.Model steeringを使ってみた
事前準備
CLI Help Agent での「制約への割り込み指定」
Codebase Investigatorでの「絞り込み指定」
Plan Modeでの「詳細設計の後出しによる軌道修正」
3.おわりに
1.はじめに
Model steering とはエージェントがユーザープロンプトなどで指示を受け、その処理の思考中に割り込み指示を与えられる機能です。
例えばユーザープロンプトを入力・実行後、指示内容が曖昧だったので具体的なコンテキストを追加したり、逆に不要な手順のスキップ指示をすることができます。
つまりエージェントが実行しようとしていることに対して軌道修正を行える機能となります。
本記事執筆時点では experimental 版(開発途中の先行公開機能)でありますが、実際に使ってみたので紹介します。
環境情報
- macOS:Tahoe 26.3.1
- Node.js のバージョン(
node --version):24.11.1 - Gemini CLI のバージョン(
gemini --version):0.42.0
2.Model steeringを使ってみた
事前準備
本記事執筆時点では experimental 版(開発途中の先行公開機能)であり、利用するためには有効化が必要となります。

設定ファイルに以下を追加し Model steering 機能を利用できる状態とします。
"experimental": {
"modelSteering": true
}
CLI Help Agent での「制約への割り込み指定」
CLI Help Agent とは Gemini CLI の設定やコマンドについて質問すると、それについて答えてくれる組み込み Subagent です。
この組み込み Subagent を使う形で「Gemini CLI の experimental 機能を3つ選んで教えてください」とユーザープロンプトに入力・実行直後に「Model steering は必ず含め最も具体的に教えてください」と入力してみます。
Gemini CLI を起動し、まずは「Gemini CLI の experimental 機能を3つ選んで教えてください」と入力、そのすぐ後に「Model steering は必ず含め最も具体的に教えてください」と入力したものが以下となります。

「Gemini CLI の experimental 機能を3つ選んで教えてください」を入力した後、まずは Thinking 状態(思考状態)となります。(これはModel steering 関係なくユーザーからの指示を受け、それを実現するためにエージェントが思考している時間です)
このタイミングで「Model steering は必ず含め最も具体的に教えてください」と入力しエンターを押下すると、入力した文章の接頭に Steering Hint: が付与されました。
これで最初の指示に対して軌道修正、つまり3つの experimental 機能紹介に必ず Model steering を含んだ応答をするはずです。
結果は期待通り Model steering を3つの中に含めており、最も具体的にという文脈から1番目かつ最重要という文言付きで出力してくれました。

ちなみに応答結果の全容は以下です。
✦ Gemini CLI の experimental 機能の中から、ご要望の Model Steering を中心に 3 つ選んで詳しく解説します。
特に Model Steering については、エージェントが動作している「その瞬間」に介入できる強力な機能です。
1. Model Steering(モデル・ステアリング)※最重要
エージェントがタスクを実行している最中に、ユーザーがリアルタイムで「ヒント」を与えて、その後の行動を微調整(ステアリング)できる機能です。
* 具体的な仕組み:
通常のエージェントは一度指示を出すと、そのタスクが完了するかエラーになるまで入力を受け付けません。しかし、この機能を有効にすると、エージェントが考えていたりツールを実行したりしている最中(スピナーが回っている間)に、ターミナルから直接メッセージを入力して Enter を押すことができます。
* 具体的にできること(具体例):
* 情報の補足: エージェントがファイルを探し始めた瞬間に「設定ファイルは ./config/internal/の中にあるよ」と教えて、無駄な探索を省かせる。
* 方針の即時修正:
実装方針が自分の意図と違うことに気づいた時、停止させるのではなく「やっぱりそのライブラリは使わず、標準モジュールだけで書いて」と軌道修正させる。
* 優先順位の変更:
「テストコードは後でまとめてやるから、今は実装を優先して」と伝え、現在の計画を動的に書き換えさせる。
* メリット:
エージェントが「間違った方向」に進むのを未然に防げるため、トークンの節約と作業時間の短縮に直結します。
2. Auto Memory(オート・メモリー)
過去の対話履歴(トランスクリプト)をバックグラウンドで分析し、繰り返し行っている作業パターンを「スキル(Agent Skills)」として自動で抽出・提案する機能です。
* 具体的な動作:
例えば、あなたが毎回「特定のディレクトリ構成でコンポーネントを作る」指示を繰り返していると、エージェントがそれを検知し、「この手順をスキルとして保存しませんか?」と SKILL.md の下書きを作成します。
* 活用方法:
提案されたスキルを承認(Promote)すると、次回からは詳細な指示を書かなくても、エージェントがそのプロジェクト固有のルールを理解した状態で動作するようになります。
3. Git Worktrees(Git ワークツリー)
各 Gemini セッションに対して、独立した Gitワークツリー(物理的に異なるディレクトリとブランチ)を自動的に作成・割り当てる機能です。
* 具体的な動作:
gemini --worktreeとして起動すると、現在の作業ディレクトリを汚さずに、一時的なディレクトリで新しいブランチを切って作業を開始します。
* メリット:
「機能 A の実装」と「バグ Bの修正」を、同じリポジトリで同時に別々のエージェントに並行して進めさせることが可能になります。一方の作業が他方のファイル変更と競合する心配がありません。
---
設定方法:
これらの機能を利用するには、/settings コマンドで各項目を true にするか、設定ファイル(~/.gemini/settings.jsonなど)に以下のように記述します。
1 {
2 "experimental": {
3 "modelSteering": true,
4 "autoMemory": true,
5 "gitWorktrees": true
6 }
7 }
Codebase Investigatorでの「絞り込み指定」
Codebase Investigator とはプロジェクト内のコードを分析し、どのようなプロジェクトかを教えてくれる組み込み Subagent です。
この組み込み Subagent を使う形で「ADK Python samples の各エージェントのプロジェクトを解説してください」とユーザープロンプトに入力・実行直後に「全てでなく、gemma-food-tour-guide だけ解説してください」と入力してみます。
ちなみに ADK Python samples とは Python ADK のサンプルエージェントリポジトリで、本記事執筆時点では、およそ70個のサンプルプロジェクトが用意されています。
Gemini CLI を起動し、まずは「ADK Python samples の各エージェントのプロジェクトを解説してください」と入力、そのすぐ後に「全てでなく、gemma-food-tour-guide だけ解説してください」と入力したものが以下となります。

CLI Help Agent での「制約への割り込み指定」の時と同じく、後から入力した文章の接頭に Steering Hint: が付与されています。
ADK Python samples には多くのサンプルエージェントのプロジェクトがありますが、指定プロジェクトの解説のみの応答をするはずです。
結果は期待通り gemma-food-tour-guide の解説のみ出力する形となりました。

応答結果の全容は以下となります。
✦ gemma-food-tour-guide プロジェクトについて解説します。
このプロジェクトは、Google の ADK (Agent Development Kit)を使用して、ユーザーにパーソナライズされたフードツアー(食べ歩きルート)を提案するAIエージェントのサンプルです。
1. プロジェクトの概要
* プロジェクト名: gemma-food-tour-guide
* 目的:
ユーザーが提供した「料理の写真」や「料理の説明」、「場所」、「予算」に基づいて、最適な食べ歩きルートとおすすめメニューを提案すること。
2. 主な機能
このエージェントは以下の4つのステップを自動で実行します:
1. 料理の特定:
ユーザーが送ったテキストや画像から、どのような料理やジャンル(例:ラーメン、BBQ、シカゴピザなど)を求めているかを判別します。
2. スポット検索: Google Maps MCP ツールを使用して、指定された場所周辺で評価の高いレストランや屋台を探します。
3. ルート構築: Google Maps MCP の経路計算機能を使用し、選ばれたスポット間を効率よく移動できる徒歩ルートを作成します。
4. 注文のアドバイス: 各スポットで「何を注文すべきか、何は避けるべきか」といったインサイダーなヒントを提供します。
3. 技術スタック
* フレームワーク: google-adk (Google Agent Development Kit)
* エージェントの定義、ツールの統合、Webインターフェースの提供に使用されています。
* モデル: gemma-4-31b-it (Google AI Studio 経由)
* Gemini ファミリーのモデル(ここでは実験的な名称として gemma-4が指定されています)を使用し、高度な推論と画像理解を行います。
* ツール (MCP): Google Maps MCP
* Model Context Protocol (MCP) を介して Google Mapsのリアルタイムデータ(地点検索、経路計算)をエージェントが直接利用できるようにしています。
4. 特徴
* マルチモーダル対応: テキストだけでなく、料理の画像(URL)を入力として受け取ることができます。
* グラウンディング (根拠付け): モデルの想像で住所や場所を捏造する(ハルシネーション)のを防ぐため、必ず Google Mapsツールから返された正確な place_id や座標を使用してルートを構成するように設計されています。
このサンプルは、ADK と MCP を組み合わせることで、LLMがいかに実世界の便利なツール(Google Maps等)を使いこなし、具体的で実用的なサービスを提供できるかを示す良い例となっています。
Plan Modeでの「詳細設計の後出しによる軌道修正」
Plan Mode とは Gemini CLI が実装を始める前に調査・計画のプロセスを踏み、ユーザーとの合意を経て実装を行うモードです。
この Plan Mode を使う形で Terraform の AWS インフラコードに対する追加実装内容の策定を行うが、その計画プロセスの途中で詳細設計情報を後出しし、軌道修正ができるかを試してみます。
シナリオとしては Terraform の AWS ネットワークリソースのコードに対し、NACL の設定を追加するものとします。
Gemini CLI を起動し Plan Mode とした上で「ネットワークリソースにNACLを追加してください」と入力します。
その後の計画策定ヒアリングにて「サブネット種別は分けず、共通のNACLで管理する構成にしてください」と入力、実行直後に「詳細設計書を追加しました。nacl_design.md を参照し、この要件に即した計画に修正してください」と入力します。
後出しする nacl_design.md には以下の通り、計画策定ヒアリング時に入力した「サブネット種別は分けず、共通のNACLで管理する構成にしてください」と異なり、サブネット種別ごとに NACL を作成するという内容を記載しています。
つまり当初の要望と真逆の内容となっています。
## 前提 - NACLはサブネット種別(public / protected / private)ごとに個別に作成してください。
真逆の指示を Model steering で後出しし、その内容を反映した応答となるかを確認してみます。
※ 本記事の趣旨は Model steering の挙動紹介となるので、Terraform コードや nacl_design.md の全内容の提示は割愛します。
Gemini CLI を起動、Plan Mode とし、まずは「ネットワークリソースにNACLを追加してください」と入力、計画策定ヒアリングに進みます。

計画策定ヒアリングにて自由記述の形で「サブネット種別は分けず、共通のNACLで管理する構成にしてください」と入力します。

「サブネット種別は分けず、共通のNACLで管理する構成にしてください」と入力、実行直後に「詳細設計書を追加しました。nacl_design.md を参照し、この要件に即した計画に修正してください」と入力します。
これで Model steering が稼働します。

提示された実装プランですが、期待通りサブネット種別は分けず共通のNACLで管理する構成から軌道修正し、サブネット種別ごとに NACL を作成する内容となりました。

応答結果(実装プラン)の全容は以下となります。
✦ nacl_design.md の詳細設計を確認しました。当初検討していた共通構成ではなく、設計書に従いサブネット種別(Public / Protected / Private)ごとに個別のNACLを作成する方針に修正しました。
特にエフェメラルポートの範囲(Linux用: 32768-61000, ALB/NAT用: 1024-65535)や、サブネット間の通信許可(ProtectedからPrivateへの3306等)を設計通りに反映したプランを作成しました。
作成した修正プランの詳細は以下の通りです。この内容で実装を進めてよろしいでしょうか?
---
実装プラン:サブネット別詳細設計に基づくNACL追加
目的
nacl_design.mdの詳細設計に基づき、パブリック、プロテクト、プライベートの各サブネット種別に対して、それぞれ最適化されたネットワークACL(NACL)を適用します。
キーファイルとコンテキスト
- modules/vpc/main.tf: 3つのNACLリソース(Public, Protected,Private)と、それぞれのルール、およびサブネットへの関連付けを定義します。
- nacl_design.md: ルールの根拠となる詳細設計書。
実装ステップ
1. パブリックサブネット用NACLの定義 (modules/vpc/main.tf)
- Ingress:
- 100: TCP 443 (0.0.0.0/0) 許可
- 110: TCP 1024-65535 (0.0.0.0/0) 許可 (ALB/NATGW戻りトラフィック用)
- Egress:
- 100: TCP 80 (Protected Subnet CIDRs) 許可
- 110: TCP 443 (0.0.0.0/0) 許可
- 120: TCP 1024-65535 (0.0.0.0/0) 許可
- 関連付け: aws_subnet.public[*].id
2. プロテクトサブネット用NACLの定義 (modules/vpc/main.tf)
- Ingress:
- 100: TCP 80 (Public Subnet CIDRs) 許可
- 110: TCP 32768-61000 (0.0.0.0/0) 許可 (Linuxエフェメラルポート)
- Egress:
- 100: TCP 443 (0.0.0.0/0) 許可
- 110: TCP 3306 (Private Subnet CIDRs) 許可
- 120: TCP 1024-65535 (Public Subnet CIDRs) 許可
- 関連付け: aws_subnet.protected[*].id
3. プライベートサブネット用NACLの定義 (modules/vpc/main.tf)
- Ingress:
- 100: TCP 3306 (Protected Subnet CIDRs) 許可
- Egress:
- 100: TCP 32768-61000 (Protected Subnet CIDRs) 許可
- 関連付け: aws_subnet.private[*].id
検証・テスト
1. terraform plan を実行し、3つのNACLリソースと計11個のルール(Ingress/Egress)が正しく追加されることを確認します。
2. サブネットの関連付けが重複なく、各サブネット種別に対して正しく行われていることを確認します。
3.おわりに
Model steering を組み込み Subagent への割り込み指定・絞り込み指定、そして Plan Mode での詳細設計の後出しによる軌道修正という3つのシナリオで使ってみました。
AI からの応答を待たずに追加指示を投入できたり、最初の指示をキャンセルして一から指示を出し直すというような手間も省ける点で便利な機能だと感じました。
本ブログ執筆時点では experimental 版(開発途中の先行公開機能)でありますが、興味の湧いた方はぜひ試してみてください。