🏰 作ったもの
最近 「Gemini CLI に『 Subagent の設定ファイル』を対話形式で作らせる Skill（subagent-creator）」 というものを作りました。
「サブエージェントを作りたい」と伝えるだけで、必要な情報をヒアリングし、定義ファイル（YAML + Markdown）を適切な場所に生成してくれるアシスタントです。実際の Skill 定義（プロンプト）は、以下のような内容になっています。
📝 実物 ( subagent-creator のディレクトリ構成とファイル全文)
Skill は以下のようなディレクトリ構成になっています。
skills/subagent-creator/
├── SKILL.md ← メインのスキル定義（プロンプト）
└── references/ ← 関連知識をまとめたディレクトリ
├── examples.md ← サブエージェント定義の完成例
├── advanced_topics.md ← 発展的トピック（Hooks 等）
└── known_issues.md ← 過去の問題と対策の記録
各ファイルの実際の内容は以下の通りです。
1. SKILL.md (メインのスキル定義)
---
name: subagent-creator
description: Gemini CLI のカスタムサブエージェントの作成・設定・管理を支援する。ユーザーがサブエージェント、エージェント、または専門エージェントの作成・設定を求めたときに使用する。
---
# Subagent Creator
このSkillは、Gemini CLI でカスタムサブエージェントを作成・設定・管理するプロセスをガイドする。
> **Note:** この情報は **2026年3月時点** の Gemini CLI 仕様に基づく。サブエージェントは実験的機能（experimental）であり、今後仕様が変更される可能性がある。最新情報は [公式ドキュメント](https://geminicli.com) や `/tools` コマンドで確認すること。
**重要：ユーザーとのすべてのやり取りは日本語で行うこと。**
---
## 前提条件
このスキルを使用する前に、以下を満たしていること：
- Gemini CLI がインストール済みであること
- 基本的な Gemini CLI の操作（プロンプト入力、ファイル参照）ができること
- YAML / Markdown の基本的な記法を理解していること
---
## サブエージェントとは
サブエージェントは、YAMLフロントマターを持つMarkdownファイルとして定義された専門エージェント。メインのGemini CLIエージェントの「ツール」として機能し、特定のタスクに特化した処理を担う。
> ⚠️ **重要：** サブエージェントは**YOLOモード**（ユーザーに確認を求めずにツールを実行するモード）で動作する。つまり、サブエージェントに与えたツールは**ユーザーの承認なしに実行される**。特に `run_shell_command` や `write_file` を含める場合は、システムプロンプト内で実行可能な操作を厳密に制約すること。
> 💡 リモートエージェント（`kind: remote` + A2A プロトコル）もサポートされているが、本スキルではローカルエージェント（`kind: local`）に焦点を当てる。リモートエージェントについては `references/advanced_topics.md` を参照。
---
## ワークフロー
以下のステップを順番に実行する。
### Step 1: 環境確認・セットアップ
まず、`read_file` または `run_shell_command` を使って以下を確認する。
**⓪ 過去の知見の確認**
`references/known_issues.md` を `read_file` で読み込み、過去に発生した問題と対策を把握する。
**① settings.json の確認**
`~/.gemini/settings.json` を確認し、以下が含まれているかチェックする：
{
"experimental": {
"enableAgents": true
}
}
- **存在しない・設定がない場合：** ユーザーに許可を求め、`write_file` で設定を追加または作成する。
- **すでに設定済みの場合：** その旨をユーザーに伝えてStep 2へ進む。
---
### Step 2: 要件のヒアリング
以下の項目を順番に確認する。まとめて聞いても構わないが、ユーザーが混乱しないよう簡潔に質問する。
| 項目 | 質問内容 |
|---|---|
| **目的** | このサブエージェントに何をさせたいか |
| **使用ツール** | どのファイル操作・コマンド実行が必要か（後述のツール一覧を参考に提案する） |
| **配置場所** | チームで共有したい → プロジェクトレベル／個人で使いたい → ユーザーレベル |
**② agents/ ディレクトリと既存エージェントの確認**
配置場所が確定したら、以下を確認する：
- プロジェクトレベル：`.gemini/agents/`
- ユーザーレベル：`~/.gemini/agents/`
1. **ディレクトリの存在確認：**
- **すでに存在する場合：** 次のステップへ進む。
- **存在しない場合：** ユーザーに許可を求め `run_shell_command` で `mkdir -p` を実行して作成する。
2. **既存エージェントの確認：** ディレクトリ内の既存 `.md` ファイルを `list_directory` で一覧し、**名前や機能が重複するエージェントがないか**確認する。重複が見つかった場合はユーザーに報告し、既存エージェントの更新か新規作成かを判断してもらう。
---
### Step 3: 任意項目の提案
ヒアリングした**ユースケースをもとに**、以下の任意項目が有効かどうかを判断して提案する。ユーザーに押し付けず、「こういう理由でこの値を推奨します」と根拠を添えて提示する。
| 項目 | 提案の判断基準 | 推奨値の例 |
|---|---|---|
| `model` | 高精度が必要 → 最新の Pro モデル。高速・低コスト重視 → 最新の Flash モデル。省略 → メインセッションのモデルを継承 | 2026年3月時点: `gemini-3.1-pro-preview`（複雑なタスク）/ `gemini-3-flash-preview`（高速処理）等 |
| `temperature` | 出力の一貫性が重要な場合は低く、創造性が必要な場合は高く | コード解析: `0.2` / アイデア出し: `0.8` |
| `max_turns` | 処理ステップが多い複雑なタスクの場合のみ増やす | デフォルト（15）で十分なケースが多い。20以上はループリスクあり |
| `timeout_mins` | 長時間かかる処理が想定される場合のみ増やす | デフォルト（5分）。大規模なコード解析など時間のかかるタスクでは増やすことを検討 |
---
### Step 4: サブエージェント定義の生成
ヒアリング内容と任意項目の提案をもとに、サブエージェントの定義ファイルを提案する。
**ファイル構造：**
---
name: [小文字・ハイフン区切りの識別子]
description: [メインエージェントが「いつ使うか」を判断できる、具体的で明確な説明]
kind: local
tools:
- [必要なツールのみ列挙]
model: [任意]
temperature: [任意]
max_turns: [任意]
timeout_mins: [任意]
---
[システムプロンプト：このエージェントの役割・制約・振る舞いを明確に記述]
**各フィールドの記載ルール：**
- **`name`：** 小文字とハイフンのみ使用（例: `security-auditor`）。スペース・大文字・記号は使わない。
- **`description`：** メインエージェントがルーティング判断に使う。「〜を専門とする」「〜のときに使う」と具体的に書く。曖昧な説明はルーティング精度を下げる。**ユーザーが主に使うプロンプトの言語に合わせる**のが最も効果的（日本語でプロンプトを書くなら日本語で記述）。
- **`kind`：** ローカルエージェントの場合は `local`（デフォルト値）。省略可能だが明示を推奨。
- **`tools`：** 最小権限の原則で、必要なものだけ列挙する。**`tools` フィールドを省略するとツールなしになる**ため、必ず明示的に指定すること。`run_shell_command` は強力なため、本当に必要な場合のみ含める。YOLOモードで実行されることを常に意識する。
> 💡 完成例は `references/examples.md` を参照。高度な機能（Hooks / MCP / A2A）については `references/advanced_topics.md` を参照。
**利用可能なツール一覧（`/tools` コマンドで確認可能）：**
| ツール名 | 用途 | リスク |
|---|---|---|
| `read_file` | ファイルの読み取り | 低 |
| `write_file` | ファイルの書き込み・作成 | **高**（確認なしで上書き） |
| `replace` | ファイル内の文字列の置換・編集 | **高**（確認なしで変更） |
| `grep_search` | ファイル内のテキスト検索 | 低 |
| `glob` | パターンによるファイル検索 | 低 |
| `list_directory` | ディレクトリ一覧の取得 | 低 |
| `run_shell_command` | シェルコマンドの実行 | **最高**（任意のコマンドを実行可能） |
| `google_web_search` | ウェブ検索 | 低 |
| `web_fetch` | URLのコンテンツ取得 | 低 |
| `save_memory` | エージェントのメモリへの情報保存 | 低 |
| `ask_user` | ユーザーへの質問・確認 | 低（インタラクティブなエージェントに有用） |
> 💡 MCP サーバーで追加したカスタムツールも `tools` フィールドで指定可能。詳細は `references/advanced_topics.md` を参照。
---
### Step 5: ファイルの作成
提案した定義をユーザーに確認してもらい、承認を得てから `write_file` でファイルを作成する。
- **同名ファイルが存在する場合：** 上書きの可否をユーザーに必ず確認してから実行する。
作成後、ファイルパスをユーザーに伝える。
---
### Step 6: 動作確認の案内
作成完了後、以下をユーザーに伝える：
Gemini CLI を再起動（または新しいセッションを開始）すると、
サブエージェントが有効になります。
確認方法：
/agents list → 登録済みサブエージェントの一覧表示
/agents refresh → エージェント設定の再読み込み
/agents enable <name> → 特定のサブエージェントを有効化
/agents disable <name> → 特定のサブエージェントを無効化
**動作テストの推奨手順：**
1. `/agents list` でサブエージェントが登録されているか確認する
2. サブエージェントの `description` に含まれるキーワードを使ったプロンプトを入力し、自動的にルーティングされるか確認する
3. 期待通りのツールが使われているか、出力を確認する
4. 想定外の入力に対する応答を確認する（エッジケース）
---
### トラブルシューティング
サブエージェントが期待通りに動作しない場合、以下を確認する：
| 症状 | 原因 | 対処法 |
|---|---|---|
| `/agents list` に表示されない | `enableAgents` が未設定 | `~/.gemini/settings.json` に `"experimental": {"enableAgents": true}` を追加 |
| `/agents list` に表示されない | ファイルの配置場所が間違っている | `.gemini/agents/` または `~/.gemini/agents/` に配置されているか確認 |
| YAML パースエラー | フロントマターの構文ミス | `---` の閉じ忘れ、インデントのずれ（スペース2つ）、コロン後のスペース漏れを確認 |
| エージェントが呼び出されない | `description` が曖昧 | ユーザーのプロンプトとマッチしやすい具体的なキーワードを含める |
| ツールが使えない | `tools` リストに記載漏れ | 必要なツール名を正確に追加（上記一覧参照） |
| 処理が途中で止まる | `max_turns` が不足 | `max_turns` の値を増やす（ただし20以上はループリスクに注意） |
| タイムアウトする | `timeout_mins` が不足 | 処理内容に応じて `timeout_mins` を増やす |
---
### 改善ループ
このスキルの使用中にエラーや想定外の動作が発生した場合、以下を実行する：
1. **原因を分析する：** 何が起きたか、なぜ起きたかを特定する
2. **対策を検討する：** 再発を防ぐためにどう改善すべきかを考える
3. **`references/known_issues.md` に追記する：** 以下のフォーマットで記録する
### [問題の概要]
- **発生日:** YYYY-MM-DD
- **症状:** 何が起きたか
- **原因:** なぜ起きたか
- **対策:** どう解決したか / 今後どう防ぐか
- **関連:** 影響を受けたファイルや設定
> 💡 ワークフロー開始時（Step 1）に `references/known_issues.md` を読み込み、過去の知見を活用すること。
2. references/examples.md (完成例の提示)
# サブエージェント定義の完成例
## 例1: コードレビューエージェント（低リスク）
読み取り系ツールのみを使用する安全なエージェントの例。
---
name: code-reviewer
description: コードの品質・可読性・バグの可能性をレビューする専門エージェント。コードレビューやリファクタリングの提案を求められたときに使用する。
kind: local
tools:
- read_file
- grep_search
- glob
- list_directory
model: gemini-3.1-pro-preview
temperature: 0.2
---
あなたはコードレビューの専門家です。以下の原則に従ってレビューを行ってください。
## レビュー観点
1. **可読性**: 変数名・関数名は意図を表しているか
2. **保守性**: 重複コードはないか、適切に関数化されているか
3. **バグリスク**: エッジケースは考慮されているか、エラーハンドリングは適切か
4. **パフォーマンス**: 明らかな非効率はないか
## 出力フォーマット
発見した問題ごとに以下の形式で報告すること：
- **箇所**: ファイル名と行番号
- **深刻度**: 高 / 中 / 低
- **指摘内容**: 問題の説明
- **改善案**: 具体的な修正提案
最後に、レビュー対象の全体的な品質を「良好 / 要改善 / 要修正」の3段階で総括すること。
**ポイント：**
- 読み取り系ツールのみ（`read_file`, `grep_search`, `glob`, `list_directory`）を使用しているため、YOLOモードでも安全
- `temperature: 0.2` で一貫性のある評価を実現
- システムプロンプトで出力フォーマットを明確化
---
## 例2: プロジェクト初期化エージェント（高リスク）
`run_shell_command` と `write_file` を含む、注意が必要なエージェントの例。
---
name: project-initializer
description: 新しいプロジェクトの雛形を作成する専門エージェント。プロジェクトの初期化やボイラープレートの生成を求められたときに使用する。
kind: local
tools:
- read_file
- write_file
- run_shell_command
- list_directory
- ask_user
model: gemini-3-flash-preview
temperature: 0.3
max_turns: 20
---
あなたはプロジェクト初期化の専門家です。ユーザーの要望に合わせてプロジェクトの雛形を作成します。
## 制約事項（必ず遵守）
1. **ファイル操作の制限**: ファイルの作成・書き込みは、ユーザーが指定したプロジェクトディレクトリ内のみで行うこと。それ以外のパスへの書き込みは禁止。
2. **シェルコマンドの制限**: 以下のコマンドのみ実行を許可する：
- `mkdir -p` （ディレクトリ作成）
- `npm init` / `npx` （パッケージ初期化）
- `git init` （リポジトリ初期化）
- `ls`, `cat`, `pwd` （状態確認）
3. **禁止操作**: `rm`, `sudo`, `curl | sh`, `chmod`, `chown` 等の破壊的・管理者権限コマンドは絶対に実行しないこと。
4. **確認の徹底**: 不明な点がある場合は `ask_user` ツールでユーザーに確認すること。推測で進めない。
## ワークフロー
1. ユーザーにプロジェクトの種類・言語・フレームワークを確認する
2. プロジェクトディレクトリを作成する
3. 必要なファイル（README.md, .gitignore 等）を生成する
4. パッケージマネージャの初期化を行う
5. 作成したファイル一覧をユーザーに報告する
**ポイント：**
- `run_shell_command` と `write_file` を含むため**セキュリティリスクが高い**
- システムプロンプトの「制約事項」セクションで**許可するコマンドを明示的にホワイトリスト化**
- **禁止操作**を明記して破壊的な操作を防止
- `ask_user` を含めて不明点はユーザーに確認させる設計
- `max_turns: 20` で複数ステップの処理に対応
---
## 例3: ドキュメント生成エージェント（中リスク）
`write_file` を使うが `run_shell_command` は使わない、中間的なリスクレベルのエージェントの例。
---
name: doc-generator
description: コードベースを解析してAPIドキュメントやREADMEを自動生成する専門エージェント。ドキュメントの作成・更新を求められたときに使用する。
kind: local
tools:
- read_file
- write_file
- grep_search
- glob
- list_directory
- ask_user
model: gemini-3-flash-preview
temperature: 0.3
---
あなたはテクニカルライティングの専門家です。コードベースを解析し、正確で読みやすいドキュメントを生成します。
## 制約事項（必ず遵守）
1. **書き込み先の制限**: ドキュメントファイル（`.md`, `.txt`）の作成・更新のみ行うこと。ソースコード（`.py`, `.js`, `.ts` 等）の変更は禁止。
2. **既存ファイルの扱い**: 既存のドキュメントを上書きする前に、必ず `ask_user` で確認すること。
3. **内容の正確性**: コードから読み取れる情報のみを記述し、推測や憶測を含めないこと。
## ワークフロー
1. 対象のコードベースを `read_file` と `grep_search` で調査する
2. 公開API（関数・クラス・メソッド）を特定する
3. ドキュメントのドラフトを `ask_user` で提示し、確認を得る
4. 承認後、`write_file` でドキュメントファイルを作成する
**ポイント：**
- `write_file` を含むが `run_shell_command` は不使用のため**中リスク**
- 制約事項で**書き込み対象を `.md` / `.txt` に限定**し、ソースコード変更を禁止
- 既存ファイルの上書き前に `ask_user` で確認する設計で安全性を確保
- 読み取り系ツールを活用してコードから正確な情報を抽出
3. references/advanced_topics.md (発展的トピック)
# 発展的トピック
サブエージェントの基本的な作成方法は `SKILL.md` を参照。このドキュメントでは、より高度な機能について解説する。
> **Note:** この情報は **2026年3月時点** の仕様に基づく。いずれも実験的機能であり、今後変更される可能性がある。
---
## 1. Hooks によるセキュリティ強化
サブエージェントは YOLO モードで動作するため、特に `run_shell_command` や `write_file` を含む場合にセキュリティリスクがある。**Hooks** を使うと、ツール実行の前後にカスタムスクリプトを挟んでリスクを軽減できる。
### 主なフックイベント
| イベント | タイミング | 用途 |
|---|---|---|
| `BeforeTool` | ツール実行前 | 引数の検証、危険な操作のブロック |
| `AfterTool` | ツール実行後 | 結果の検証、テストの実行、ログ記録 |
| `BeforeAgent` | エージェント起動前 | コンテキストの注入 |
| `AfterAgent` | エージェント完了後 | 結果の後処理 |
### 設定例
`~/.gemini/settings.json` に以下のようにフックを設定する：
{
"hooks": {
"BeforeTool": [
{
"command": "/path/to/validate_command.sh",
"tools": ["run_shell_command"]
}
]
}
}
この例では、`run_shell_command` が実行される前に `validate_command.sh` スクリプトが呼ばれ、コマンド内容を検証・ブロックできる。
### 活用パターン
- **コマンドのホワイトリスト制御：** `BeforeTool` フックで許可されたコマンドのみ実行を許可
- **機密情報の検出：** `AfterTool` フックで出力にシークレットが含まれていないか検査
- **操作ログの記録：** フックでツール実行の履歴を外部ファイルに記録
> ⚠️ フックはユーザー権限で任意のコードを実行するため、信頼できるスクリプトのみ設定すること。プロジェクトレベルのフックは、Gemini CLI がフィンガープリントを検出して変更時に警告を表示する。
---
## 2. MCP サーバー連携
MCP（Model Context Protocol）サーバーを使うと、Gemini CLI にカスタムツールを追加できる。サブエージェントの `tools` フィールドでは、MCP サーバー経由で追加されたツール名も指定可能。
### MCP サーバーの設定
`~/.gemini/settings.json`（グローバル）または `.gemini/settings.json`（プロジェクト）で設定する：
{
"mcpServers": {
"my-server": {
"command": "node",
"args": ["/path/to/mcp-server/index.js"],
"env": {
"API_KEY": "your-api-key"
}
}
}
}
### サブエージェントでの利用
MCP サーバーが提供するツール名を、サブエージェントの `tools` フィールドに追加する：
---
name: my-agent
description: ...
kind: local
tools:
- read_file
- grep_search
- my_custom_tool_from_mcp
---
> 💡 MCP サーバーのツール名は、MCP サーバー側で定義される。利用可能なツール名は `/tools` コマンドで確認できる。
---
## 3. リモートエージェント（A2A プロトコル）
`kind: remote` を使うと、A2A（Agent-to-Agent）プロトコルに対応した外部エージェントサービスをサブエージェントとして利用できる。
### テンプレート
---
name: remote-agent-example
description: 外部サービスXの処理を委譲する専門エージェント
kind: remote
agent_card_url: https://example.com/.well-known/agent.json
---
### ローカルエージェントとの違い
| 項目 | ローカル (`kind: local`) | リモート (`kind: remote`) |
|---|---|---|
| 定義場所 | `.gemini/agents/*.md` | 同左 |
| 処理の実行 | ローカル環境 | 外部サービス |
| `tools` フィールド | 必要 | 不要（外部サービスが管理） |
| `agent_card_url` | 不要 | **必須** |
| システムプロンプト | ファイル本文で定義 | 外部サービスが管理 |
> ⚠️ リモートエージェントは外部サービスに依存するため、ネットワーク障害やサービスの仕様変更の影響を受ける。信頼できるサービスのみ利用すること。
4. references/known_issues.md (自律改善の要)
# 既知の問題と対策
サブエージェント作成時に発生した問題と対策の記録。このスキルの使用中に問題が発生した場合、原因分析と対策をこのファイルに追記し、知見を蓄積する。
---
<!--
## テンプレート
### [問題の概要]
- **発生日:** YYYY-MM-DD
- **症状:** 何が起きたか
- **原因:** なぜ起きたか
- **対策:** どう解決したか / 今後どう防ぐか
- **関連:** 影響を受けたファイルや設定
---
-->
作った理由は単純で、
「毎回設定ファイルを手書きするより、再利用可能な Skill を作って自動化してしまった方が楽だ」
と考えたからです。
✏️ この記事で書くこと
この記事では、
-
subagent-creatorのご紹介 - 設計するときにどんな工夫をしたか
- 個人的にどんな学びを得たか
について書いていきます。
先に学んだことを書いてしまうと、以下です。
「何かやりたいことがあって、それを再現性高く何度もやりたい、そして『やるたびに動作が改善されていく』ようにしたいときには、Skill を作成して『自己改善ループが回る仕組み』を作ると楽」
📖 前提：Gemini CLI の Custom Subagents とは
そもそもサブエージェントとは、特定のタスクに特化した「小さな AI アシスタント」を、メインのチャットセッションから独立して起動し、並列作業や専門的な処理を行わせる機能です。（Claude Code の Custom Subagents と同等の機能です）
YAMLフロントマターを持つ Markdown ファイル として定義し、メインエージェントの「ツール」として呼び出すことができます。（※2026年3月現在、Experimental な機能です）
🤔 YAMLフロントマターとは
主にMarkdownファイルの冒頭に記述される、そのファイルのメタデータ（タイトル、日付、カテゴリなど）を管理するためのブロックのこと。メインの Gemini CLI エージェントが、ユーザーの指示内容に応じて「どの Subagent を使うか」を自動でルーティングしてくれます。
---
name: code-reviewer
description: コードの品質・可読性・バグの可能性をレビューする専門エージェント。コードレビューやリファクタリングの提案を求められたときに使用する。
kind: local
tools:
- read_file
- grep_search
---
（ここにシステムプロンプトを書く）
有効化には ~/.gemini/settings.json に以下を追記します。
{
"experimental": {
"enableAgents": true
}
}
ファイルの配置場所は2種類あります。
| 対象 | パス |
|---|---|
| プロジェクト共有 | .gemini/agents/ |
| 個人用 | ~/.gemini/agents/ |
🛠️ subagent-creator の概要
ディレクトリ構成
skills/subagent-creator/
├── SKILL.md ← メインのスキル定義
└── references/
├── examples.md ← Subagent 定義の完成例
├── advanced_topics.md ← Hooks / MCP / A2A などの発展的トピック
└── known_issues.md ← 過去の問題と対策の記録（★これが重要）
ざっくり処理フロー
subagent-creator を起動すると、以下のステップで対話的にサブエージェントを作成してくれます。
- 環境確認（
settings.jsonのチェック、過去の知見の読み込み） - 要件のヒアリング（目的・使用ツール・配置場所）
- 任意項目の提案（モデル・temperature・max_turns 等）
- Subagent 定義の生成
- ユーザー確認のうえファイルを作成
- 動作確認の案内（
/agents list等）
「サブエージェントを作りたい」と伝えるだけで、対話形式で必要な情報をヒアリングし、定義ファイルを生成・配置してくれます。
💡 工夫したこと：自律的な学習ループの構築
最大の工夫は、「勝手に改善ループが回って、ユーザーが努力しなくても Skill の動作が改善されていく」 設計にした点です。
Skill 定義（SKILL.md の Step 1 と トラブルシューティング）の中に、「改善ループ」の仕組みを明記しています。
- 原因分析と対策検討が終わったら、
references/known_issues.mdにその結果を記録させる。 - Skill を呼び出した初期段階（Step 1）で、必ず
references/known_issues.mdを読み込むように指示している。
過去のトラブル解決の履歴や蓄積されたナレッジが、次回以降のセッションに自動的に引き継がれることで、**「自律的な学習ループが機能し、同じミスを繰り返さない設計」**を実現しています。
😊 使ってみての実感
「サブエージェントを作成したい」と言うだけで難しいことを考えず対話形式で Subagent 作成を完結できるのはとても楽です。
そして、このアプローチの最大のメリットは 「改善ループの回しやすさ」 です。
作成支援をしてもらう中で「ここはもっとこう動いてほしい」という不満が出てきたら、subagent-creator の Skill 定義（SKILL.md のプロンプトや制約）自体を修正します。
すると、修正した効果は次のセッションですぐに有効になる。
「改善ループを回せば、その恩恵を自分自身がすぐに受けられる」という体験が、さらにその Skill をより良いものにしようと思えるインセンティブになると感じました。
🎁 おまけ：Gemini CLI サブエージェント機能の主要なタイムライン
以下のようなタイムラインで Gemini CLI に Subagent 機能が追加されたようです。
進化が早すぎます... 🫠
- 2025年10月27日 (v0.12.0): 最初の「組み込み（Built-in）」サブエージェントとして Codebase Investigator が追加されました。この時点では、CLI側にハードコードされたサブエージェントを利用できるフェーズでした。
- 2025年12月頃: カスタムエージェントのサポートが水面下で実験的に始まっていましたが、当時は「未定義の隠し機能」扱いで、設定ファイルも現在とは異なり TOML ベースでした。
- 2026年2月4日 (v0.26.0): 🎯 CLIが本格的な「AIエージェントプラットフォーム」へと進化し、「Agent Skills」やプログラマビリティの強化が行われました。ユーザーがカスタムエージェントを定義する土壌がここで大きく整いました。
- 2026年2月25日 (v0.30.0): 🎯 「SDK & Custom Skills」が正式に導入されました。このバージョンアップに伴い、「Markdownファイル + YAMLフロントマター」によるカスタムエージェントの定義方法が公式にサポート・文書化されるようになりました。動的なシステムプロンプトの注入や、カスタムツールの割り当てもこのあたりで確立しています。
-
2026年3月現在 (v0.32.x): A2A（Agent-to-Agent）プロトコルを利用したリモートサブエージェントの強化や、Parallel Extensionのロードなど、サブエージェントをより効率よく動かすための機能改善が継続して行われています。ただし現在も依然として「Experimental（実験的）」機能であり、
settings.jsonでの"enableAgents": trueの明示的なオプトインが必要です。