アスエネ株式会社の @umzo(うめぞう)です!
アスエネでは「アスエネキャリア」という脱炭素・ESG人材の転職支援サービス開発のチームリーダーをしています。
アスエネキャリアとは?
アスエネキャリアとは、脱炭素・ESG人材の転職支援サービスです。持続可能な社会を目指し、脱炭素や気候変動、サスティナビリティに関心のある人々が、最適なキャリアを築けるようにサポートしています。
はじめに
Claude Code の新機能である Sub Agents は、複雑なタスクを専門的なエージェントに委任することで、より効率的な開発を実現する機能です。発表されたばかりの機能で、不明なことも多いため、この機能を効果的に使う方法を「自動委任機能」を中心に検証しました!
Sub Agents とは
Sub Agents は、特定の専門領域に特化したAIエージェントを作成し、メインエージェントから必要に応じて呼び出す機能です。
これにより、以下のメリットが期待できます:
- コンテキストの節約: 専門的な処理を別のエージェントに委任することで、メインエージェントのコンテキストを効率的に使用
- 専門性の向上: 各エージェントが特定の領域に集中することで、より高品質な成果物を生成
- 並列処理: 複数のエージェントを同時に動作させることで、開発効率を向上
検証環境
利用した検証環境
タスク管理アプリケーションのモノレポ
- Next.js 15 + Nest.js 10によるフルスタック構成
- pnpm + Turborepoによるモノレポ管理
- DDD・クリーンアーキテクチャ採用
ディレクトリ構成
claude-workspace/
├── apps/
│ ├── api/ # Nest.js バックエンド
│ └── web/ # Next.js フロントエンド
├── packages/ # 共有パッケージ
└── docs/ # ドキュメント
作成したSub Agents
今回の検証では、以下の3つの専門エージェントを作成しました:
- backend-engineer-nestjs: バックエンド開発専門
- senior-frontend-engineer: フロントエンド開発専門
- qa-engineer-workspace: テスト戦略・品質保証専門
エージェントは、公式ドキュメントの推奨 に従い、Claude Code に生成してもらいました。
例)バックエンドエージェント
---
name: backend-engineer-nestjs
description: Use this agent when you need to design, implement, or review backend systems using Nest.js and modern TypeScript patterns. This includes creating API endpoints, implementing domain models, setting up dependency injection, writing unit/integration tests, structuring modules following DDD principles, or optimizing monorepo configurations for backend services.
color: orange
---
検証結果と得られた知見
1. 基本的な使い方
以下のように、エージェントを利用することを明示してあげると使ってくれます。
> use the backend-engineer-nestjs
タスク一覧取得APIに作成日時、更新日時でソートする機能を追加してください。
なお、指示の末尾につけた場合、指定していないエージェントを使うことが度々あったので、先頭につけるのが無難そうです。
2. 自動委任機能
自動委任機能について検証してみました。これが効果的に使えるならば、Claude Codeが適切にSub Agents を切り替えてくれる(コンテキストを切り替えてくれる)ため、指示を大幅に簡略化できそうです。
公式によると、
### Automatic delegation
Claude Code proactively delegates tasks based on:
- The task description in your request
- The `description` field in sub agent configurations
- Current context and available tools
To encourage more proactive sub agent use, include phrases like “use PROACTIVELY” or “MUST BE USED” in your `description` field.
とのことで、それぞれ検証してみました。
基本的な使い方
まずは簡単なタスクを指示してみます。
> タスク一覧取得APIに作成日時、更新日時でソートする機能を追加してください。
この指示ではClaude CodeはSub Agentsを利用しませんでした。なぜ利用しなかったか聞いてみると
1. この実装で、sub agentsは利用しましたか?
いいえ、利用していません。
2. 利用することは検討しましたか?
いいえ、検討していません。
3. 検討していない場合、なぜ検討していないですか?
以下の理由で検討しませんでした:
- タスクの単純性: ソート機能の追加は、DTOとサービスの2ファイルを編集するだけの単純な作業でした
- コードベースの明確性: 既存のコード構造が明確で、どこを修正すべきかすぐに特定できました
- 実装の直接性: 必要な変更箇所が限定的で、複雑な調査や多段階の処理が不要でした
backend-engineer-nestjsエージェントは、より複雑なバックエンド実装(新機能の設計、アーキテクチャの決定、複数モジュールにまたがる
実装など)で有用ですが、今回のような小規模な機能追加では直接実装する方が効率的でした。
単純なタスクでは使わないよ、とのこと。そこで、難しいタスクを指示してみます。
以下の機能を実装してください。
AI駆動型タスク依存関係自動解析・最適化システム
概要
複数のプロジェクトにまたがる数千のタスクから、自然言語で書かれた内容を解析し、依存関係を自動検出して最適な実行順序を導き出すシステム
機能
1. 自然言語からの依存関係抽出
「このタスクはデザイン完了後に着手」のような曖昧な表現を解析
暗黙的な依存関係の推論(「API実装」と「フロントエンド連携」など)
循環依存の検出と解消提案
2. リアルタイムリソース最適化
チームメンバーのスキルセット、稼働率、過去のパフォーマンスを考慮
タスクの並列実行可能性を判断
ボトルネックの予測と回避
3. 動的スケジュール再計算
...(略)
しかし、やはり利用しませんでした。
どうやら、そもそも Sub Agents を利用する選択肢が最初からなさそうです。
現時点で、一番楽な自動委任を活用する方法は、以下のように「Sub Agents を利用してね」と添えると良さそうでした。
指示後は、どのSub Agents を使うかをClaude Codeが判断してくれます。
例)API実装タスクをbackendエージェントに委譲
> sub agentsを効果的に活用し、タスク一覧取得APIに作成日時、更新日時でソートする機能を追加してください。
● sub agentsを使ってタスク一覧取得APIにソート機能を追加します。
● backend-engineer-nestjs(タスク一覧APIのソート機能実装) ← Claude Codeが判断し、backendエージェントを利用
⎿ Read(apps/api/src/tasks/dto/query-task.dto.ts)
Read 25 lines (ctrl+r to expand)
例)機能追加タスクをbackendエージェントおよびfrontendエージェントへ委譲(並列実装)
> sub agentを効果的に活用し、タスク一覧取得機能に作成日時、更新日時でソートする機能を追加してください。フロントのUIはボタンで切り
替えられる様にしてください。
● タスク一覧取得機能に作成日時、更新日時でソートする機能を追加します。まずはTodoWriteツールで作業計画を立てます。
● Update Todos
⎿ ☐ バックエンドのDTOとサービスにソート機能を追加 ← backendエージェントを利用
☐ フロントエンドにソート切り替えボタンを実装 ← frontendエージェントを利用
☐ 統合テストを実行して動作確認
ちなみに、一度Sub Agentsを利用すると、その後は特に指定しなくても利用してくれるようになります。
Description の重要性
description
フィールドの内容が、エージェントの使用判断に影響することは公式ドキュメントに明記されています。ここでは、description
フィールドがどの程度重要なのかを検証してみました。
指示は全て
sub agentsを効果的に活用し、タスク一覧取得APIに作成日時、更新日時でソートする機能を追加してください。
としており、バックエンドエージェントを利用させるような指示をしています。
公式によると MUST BE USED
をdescriptionに加えると、積極的に選択する様になる、とのことです。
実際に、バックエンドエージェント backend-engineer-nestjs
を複製した backend-engineer-nestjs-2
を作成し、MUST BE USED this agent when implementing the backend.
をdescriptionの先頭に加えたところ、公式のドキュメント通り、backend-engineer-nestjs-2 を利用してくれました。
---
name: backend-engineer-nestjs-2
description: MUST BE USED this agent when implementing the backend. Use this agent when you need to design, implement, or review backend systems using Nest.js and modern TypeScript patterns. This includes creating API endpoints, implementing domain models, setting up dependency injection, writing unit/integration tests, structuring modules following DDD principles, or optimizing monorepo configurations for backend services.
color: orange
---
ここで、少し意地悪ですが、フロントエンドのエージェントに MUST BE USED this agent when implementing the backend.
とつけてみます。
---
name: senior-frontend-engineer
description: MUST BE USED this agent when implementing the backend. Use this agent when you need expert guidance on frontend development tasks, particularly those involving Next.js, React, TypeScript, or modern frontend architecture decisions. This includes component design, state management, performance optimization, accessibility implementation, testing strategies, and monorepo frontend package structuring.
color: cyan
---
これはフロントエンドではなく、バックエンドのエージェントを利用しました。
さらにいくつか検証して、まとめた結果は以下になります
項目 | be-agent | fe-agent | qa-agent | be-agent-2 | 利用したエージェント |
---|---|---|---|---|---|
比較用 | 変更なし | 変更なし | 変更なし | バックエンド実装時は必ず使うように記載 (*1) | be-agent-2 |
fe-agentにバックエンド実装時は必ず使うように記載 (*1) | 変更なし | バックエンド実装時は必ず使うように記載 | 変更なし | – | be-agent |
全てのagentのdescriptionをエンジニアとだけ明記 (*2) | エンジニアとだけ明記 | エンジニアとだけ明記 | エンジニアとだけ明記 | – | be-agent |
be-agentとfe-agentのdescriptionを入れ替え | fe-agentのdescription | be-agentのdescription | 変更なし | – | be-agent |
(*1)MUST BE USED this agent when implementing the backend.
とdescriptionの先頭に追加
(*2)Use this agent when you need expert guidance on development tasks.
とだけdescriptionに記載
(*3) 全ての検証はそれぞれ3回以上実行し、同じ結果でした
面白いことに、description
フィールド よりも name
フィールドの方がエージェント利用の判断へ影響する傾向にありました。
あくまで今回の検証の範囲ですが、 name
フィールドは以下の要素よりもエージェント選択に大きな影響を与えます:
-
MUST BE USED this agent when implementing the backend.
をdescriptionに記載する -
description
フィールドにバックエンドエージェントであることを明記する
まとめ
今回の検証を通じて、Claude Code Sub Agents の実践的な活用方法について以下の知見を得ることができました!
効果的な活用方法
-
明示的な指示が確実
- 「sub agentを効果的に活用し」のような明示的な指示を含めることで、メインエージェントがsub agentの利用を判断してくれる
- 一度利用すると、その後は自動的に適切なエージェントを選択してくれる
-
エージェント設計のポイント
-
name
フィールドは予想以上に重要で、エージェント選択に大きく影響する - 専門性を明確に表現する命名が重要(例:backend-engineer-nestjs)
-
MUST BE USED
を含めることで優先度を上げることができるが、適切なdescription
フィールドの記載の方が影響する
-
-
適用する場面
- 複雑なタスクや複数ファイルにまたがる実装で特に効果的
- 単純なタスクでは直接実装の方が効率的な場合もある
- フロントエンド・バックエンドの並列実装などで真価を発揮
今後の期待
Sub Agents 機能を活用することで、大規模なコードベースでの開発効率を大幅に向上させることができます。特にモノレポ環境やマイクロサービスアーキテクチャなど、専門性の分離が明確なプロジェクトでは大きな効果が期待できそう。
この機能はまだリリースされたばかりで、個人的にはかなり注目している機能です!
今後、sub agentsがsub agents を生成したり、sub agents間で疎通ができたり、と拡張されれば、さらに複雑なタスクも依頼できそうです。description
フィールドの影響度も調整されそうですね!
現在、採用強化中です!
興味を持っていただけた方はこちらをご覧ください!
参考リンク
Views: 0