Gemini CLIに「サブエージェント」が着地。長い仕事をコンテキストごと分離できる
Gemini CLI にサブエージェントが入りました（2026-04-23、Google Developers Blog）。長い仕事、重い仕事、コンテキストがぐちゃぐちゃになりがちな仕事を、独立したコンテキスト窓で走る専門エージェントに分割できる、という話です。
これ、なかなかすごいんですよ。Claude Code の Task agent、Cursor の subagent、OpenAI Codex の Plugins and skills──ここ半年で、各 CLI が「親エージェントのコンテキストを汚さずに、別担当を呼ぶ」仕組みを次々に揃えてきました。Gemini CLI もこの列に並んだ、と見るのが素直です。
何が変わるか
要はこういうことですね。今までの Gemini CLI は、ひとつの会話に全情報を詰めて走っていた。長い作業を頼むと、途中で「過去ログを抱えたまま重くなる」「別の話題が混ざって判断がぶれる」が起きやすかった。サブエージェントは、このコンテキストを物理的に切る仕組みです。
Google が挙げているユースケースは、ざっくり以下のようなもの。
- 専門領域を割り当てる（例: テスト生成だけ、ドキュメント化だけ、リファクタだけ、の担当を作る）
- 大量タスクを並列に流す（ファイル単位やモジュール単位で同時に作業）
- サブエージェントごとにツールや system instructions を分ける
で、何が変わるかというと、「巨大な指示書を 1 つ書く」から「小さな役職を何人か雇う」に発想が寄るということです。社内の SOP をサブエージェント単位で記述しておくと、親エージェントはオーケストレータとして働く、という構図になる。
Claude Code との似て非なる関係
ちょっと立ち止まって考えると、Claude Code の subagent と設計思想は近い。どちらも「親が子を呼び、子は子のコンテキストで完結する」という親子モデルです。Gemini CLI 側で分かりやすいのは、サブエージェントを Markdown + YAML frontmatter で定義し、~/.gemini/agents や .gemini/agents に置けること。公式 docs では built-in の generalist、cli_help、codebase_investigator も案内されています。
一方、Claude Code は Anthropic の Computer Use や MCP の成熟度で一歩先を行っている。道具は適材適所で、プロジェクトの色に合わせて使い分けるのが現実的です。
導入の順序
現場で入れる場合、いきなり「全部サブエージェント化」は危ないです。順序を間違えないこと。
- 手元でひとつだけサブエージェントを立てる（例: テスト生成専門）
- 親エージェントとの責任分界を決める（誰が PR を出すか、コミットするか）
- 監査ログ（どのサブエージェントがどの API を呼んだか）を必ず残す設定にする
- そこから複数のサブエージェントに広げる
エージェントのトークン効率の観点で言うと、サブエージェント化は結果的に総トークンを節約する方向に効きます。親のコンテキストを短く保てるので、長い会話で発生しがちな「不要な履歴の再読み込み」が減ります。
個人的には
個人的には、「サブエージェントを雇う」という言い方が、だんだん実感を伴ってきたな、と感じます。数年前はエージェントひとりに全部任せる発想でしたが、今は小さな役割を何体も並べて、親がとりまとめるのが主流になってきた。5 年前に知りたかった説明、という感覚です。
ドキュメント側はまだ薄いので、続報待ちですね。手元で試すなら、まず無害な作業（ドキュメント補完・テスト生成）から切り出すのが安全です。
Google Developers Blog — Subagents have arrived in Gemini CLI
