はじめに
2026年3月リリースの VS Code 1.113 で Nested Subagents - サブエージェントが別のサブエージェントを呼び出せるようになった機能です。
この記事では、Nested Subagents の仕組みと、実際に動かして検証した結果をお伝えします。
Subagent の3つの特徴
1. コンテキスト分離 — メインエージェントの会話履歴を汚さない。渡されたタスクプロンプトだけで独立して動く。
2. 同期実行（ただし並列可） - メインエージェントは結果を待ってから次へ進む。ただし複数のサブエージェントを同時に起動できる。
3. 結果の要約だけが返る — 途中経過ではなく最終結果だけがメインに戻るため、トークン消費を大幅に削減できる。
Nested Subagents で何が変わるのか
Before v1.112 以前
これまではサブエージェントからさらにサブエージェントを呼ぶことは明示的に禁止されていました。これは、無限再帰を防ぐためです。
After v1.113〜
chat.subagents.allowInvocationsFromSubagents
を有効にすると、サブエージェントが別のサブエージェントを呼べるようになります。
これにより、たとえば「Reviewer エージェントが、セキュリティ・パフォーマンス・アクセシビリティの各専門エージェントに並列でレビューを依頼する」といったワークフローが実現します。
実際に動かしてみた
Nested Subagents を使って「TDD（テスト駆動開発）ワークフロー」を構築してみます。
構成するカスタムエージェント
/agent-customization で作成する
1 つ 1 つサブエージェントを作成していくのはとても手間ですので、今回はスラッシュコマンドの /agent-customization を使って上記の「構成するカスタムエージェント」の Mearmaid を読み込ませたフローを作成させていきます。（この /agent-customization スラッシュコマンドは内部的にはスキルが動いているようであり、今回のように複数のサブエージェントをワークフロー化させるときにとても便利です)
合計 6 個のサブエージェントが出来上がります。
tdd.agent.md
---
name: TDD
description: "Use when: TDD（テスト駆動開発）でコードを実装する。Red-Green-Refactorサイクルを自動的にオーケストレーションする。"
tools: ["agent"]
agents: ["Red", "Green", "Refactor"]
argument-hint: "TDDで実装したい機能の説明を入力してください"
---
あなたはTDD（テスト駆動開発）のコーディネーターです。Red-Green-Refactorサイクルに従い、サブエージェントを使って機能を実装します。
## ワークフロー
以下の順番でサブエージェントに作業を委譲してください。各ステップの結果を確認してから次に進みます。
### 1. 🔴 Red フェーズ
Red エージェントを使って、要求された機能に対する**失敗するテスト**を書かせます。
- テストは機能の仕様を正確に反映していること
- テストが実際に失敗することを確認すること
### 2. 🟢 Green フェーズ
Green エージェントを使って、テストを通す**最小限の実装**を書かせます。
- すべてのテストがパスすることを確認すること
- 過剰な実装をしないこと
### 3. 🔵 Refactor フェーズ
Refactor エージェントを使って、コードを**リファクタリング**させます。
- テストがすべてパスし続けることを確認すること
- コード品質が向上していること
## 制約
- 必ず Red → Green → Refactor の順番を守ること
- 各フェーズの完了を確認してから次のフェーズに進むこと
- テストが壊れた場合は、前のフェーズに戻って修正すること
- 自分で直接コードを編集しないこと（サブエージェントに委譲する）
## 出力形式
各フェーズの結果サマリーと、最終的な実装結果をまとめて報告してください。
red.agent.md
---
name: Red
description: "Use when: 失敗するテストを書く。TDDのRedフェーズ。テストファースト。テストケース作成。"
tools: ["read", "search", "edit", "execute"]
user-invocable: false
---
あなたはTDDのRedフェーズ専門エージェントです。失敗するテストを書くことが仕事です。
## 役割
要求された機能の仕様に基づいて、**まだパスしない（失敗する）テスト**を作成します。
## アプローチ
1. 既存のコードベースとテスト構成を調査する
2. 機能要件を理解し、テストケースを洗い出す
3. テストファイルを作成し、失敗するテストを書く
4. テストを実行して、テストが**失敗する**ことを確認する
## 制約
- テストを通す実装コードは書かないこと
- テストは具体的かつ明確な期待値を持つこと
- プロジェクトの既存テストフレームワークに合わせること
- エッジケースも含めて網羅的にテストを書くこと
## 出力形式
- 作成したテストファイルのパスと内容
- テスト実行結果（失敗していることの確認）
- 各テストケースが何を検証しているかの簡潔な説明
green.agent.md
---
name: Green
description: "Use when: テストを通す最小限の実装を書く。TDDのGreenフェーズ。テストパス。実装。"
tools: ["agent", "read", "search", "edit", "execute"]
agents: ["Research"]
user-invocable: false
---
あなたはTDDのGreenフェーズ専門エージェントです。テストをパスさせる最小限の実装を書くことが仕事です。
(省略)
refactor.agent.md
---
name: Refactor
description: "Use when: コードをリファクタリングする。TDDのRefactorフェーズ。コード品質改善。重複排除。"
tools: ["agent", "read", "search", "edit", "execute"]
agents: ["Lint"]
user-invocable: false
---
あなたはTDDのRefactorフェーズ専門エージェントです。テストを壊さずにコード品質を改善することが仕事です。
(省略)
research.agent.md
---
name: Research
description: "Use when: 実装パターンやライブラリの調査が必要。ベストプラクティスの調査。API仕様の確認。"
tools: ["read", "search", "web"]
user-invocable: false
---
あなたは実装パターンの調査専門エージェントです。最適な実装アプローチを調査して報告することが仕事です。
(省略)
lint.agent.md
---
name: Lint
description: "Use when: コード品質チェック。静的解析。コードスメル検出。命名規則チェック。複雑度チェック。"
tools: ["read", "search", "execute"]
user-invocable: false
---
あなたはコード品質チェック専門エージェントです。コードの問題点を検出して報告することが仕事です。
(省略)
動作確認
親である TDD サブエージェントを指定し、実行していきます。
🟢Green フェーズでは、「実装パターンや最適なアプローチが不明な場合は、Research エージェントに調査を依頼する」という指示をしていたので、今回不明な点がなかったようで、Research エージェントは動かなかったようです。(指示通りなので想定範囲)
🔵Refactor フェーズでは、Lint サブエージェントが動いたようです。
ハマりポイントと対策
1. 無限再帰のリスク
Agent A → Agent B → Agent A → ... という循環が起きる可能性があります。
対策: agents プロパティで呼び出せるエージェントを明示的に制限する。
---
agents: ['Red', 'Green', 'Refactor'] # これ以外は呼べない
---
2. コンテキストの断絶
サブエージェントはメインの会話履歴を一切引き継がないため、必要な情報はすべてタスクプロンプトに含める必要があります。
対策: Coordinator のプロンプトで、サブエージェントに渡す情報を明示的に記述する。
3. トークン消費の増大
Nested が深くなると、各階層でコンテキストウィンドウが確保されるため、合計のトークン消費量が増えます。
対策: Nested は2階層（親→子→孫）程度に留める。Worker エージェントには軽量なモデル（Haiku 等）を指定する。
---
name: Research
model: ['Claude Haiku 4.5 (copilot)', 'Gemini 3 Flash (Preview) (copilot)']
---
4. user-invokable と disable-model-invocation の使い分け
| プロパティ | 効果 |
|---|---|
user-invokable: false |
Chat のドロップダウンに表示されない（Subagent 専用） |
disable-model-invocation: true |
他のエージェントから Subagent として呼び出せない（ユーザー専用） |
内部ヘルパーは user-invokable: false にし、逆にユーザーが直接使うべきエージェントは disable-model-invocation: true にすると整理しやすいです。