はじめに
AIコーディングアシスタントには様々な機能が日々アップデートされていく中、ツール間で似たような機能だと感じるものの共通点、異なる点について整理したいと思い、この記事ではClaudeCodeとGitHub Copilotのサブエージェント（カスタムエージェント）について比較します。
機能比較
-
GitHub Copilot サブエージェント(カスタムエージェント)
ドキュメントを確認すると機能としては別の機能となりますが、今回ClaudeCodeと比較するため、サブエージェント＋カスタムエージェントを比較対象とします。ここではそれぞれについて説明します。- サブエージェント
-
タスクの委任
- メインのチャットセッション内から、分離された「自律エージェント」に特定のタスクを任せることができる機能
-
独自のコンテキスト
- メインとは別の「独自のコンテキストウィンドウ」を持つ
-
完全な自律実行
- ユーザーからのフィードバックを得るために途中で一時停止することなく自律的に動作する
-
同期的な実行
- バックグラウンドや非同期での処理ではなくユーザーはサブエージェントからの回答を待つ
- バックグラウンドや非同期での処理ではなくユーザーはサブエージェントからの回答を待つ
-
タスクの委任
- カスタムエージェント
-
特定用途に応じた専門家
- 「モデル」「ツール（MCPサーバー経由含む）」「事前プロンプト（指示）」を事前に設定しておくことで特定のユースケースで使用可能
-
複数ツール上で使用可能
- Copilotチャット、Copilotコーディングエージェント、GitHub Copilot CLIで使用可能
-
組織、チーム内で共有可能
- 特定の場所にマークダウンファイルを配置して使用可能なので共有がしやすい
-
特定用途に応じた専門家
- サブエージェント
-
ClaudeCode サブエージェント
基本的にはGitHub Copilotのサブエージェント＋カスタムエージェントと同等の機能というイメージですが、下記の異なる点があります。-
自律的な委譲
- ユーザーが明示的に呼び出すだけでなく、メインエージェントが「専門家に任せるべきだ」と判断した場合、自動的に適切なサブエージェントにタスクを移譲
-
プラグインとして提供可能
- カスタムコマンド、スキル、カスタムフックなどをまとめたプラグインの一部として提供可能
-
自律的な委譲
作成方法の比較
-
作成方法
-
Claude Code
-
/agentsコマンドを実行 - 対話形式で作成したいサブエージェント、使用するモデル、許可するツールを聞かれそれに従い作成可能
-
-
GitHub Copilot
- コマンドパレット（command⌘+shift+P）で「チャット：New Custom Agent」実行
- 雛形ファイルが作成される
- 詳細内容は手動で更新が必要（CopilotChatから作成したい内容を指示して作成は可）
-
Claude Code
-
agentsファイルの搭載場所
-
Claude Code
- プロジェクトレベル：
.claude/agents/ - ユーザーレベル：
~/.claude/agents/
- プロジェクトレベル：
-
GitHub Copilot
- プロジェクトレベル：
.github/agents - ユーザーレベル：現在のプロファイルフォルダ
- プロジェクトレベル：
-
Claude Code
-
agentsファイルの記載方法
-
Claude Code
--- name: your-sub-agent-name #サブエージェントの名前（必須） description: Description of when this subagent should be invoked #サブエージェントの説明（必須） tools: tool1, tool2, tool3 #使用可能なツールを指定（指定なしの場合はメインスレッドで使用可能な全てのツール） model: sonnet #使用するモデルを指定（sonnet、opus、haiku、inherit）※inheritが指定された場合はメインスレッドのモデルを使用 --- ##サブエージェントの役割、実行する動作を定義 : : -
GitHub Copilot
※その他使用可能なプロパティは下記参照
--- name: Planner #カスタムエージェントの名前 description: Generate an implementation plan for new features or refactoring existing code. #カスタムエージェントの説明(Copilotチャット入力フィールドにプレースホルダー テキストとして表示される。簡単な説明） tools: ['fetch', 'githubRepo', 'search', 'usages'] #使用可能なツールを指定 model: Claude Sonnet 4 #使用するモデルを指定 --- ##カスタムエージェントの役割、実行する動作を定義 : :
https://code.visualstudio.com/docs/configure/profiles
-
Claude Code
-
呼び出し方法
-
Claude Code
-
descriptionフィールドに記載している内容から判断して自動で実行 - プロンプトで明示的にサブエージェントを使用するように指示
-
-
GitHub Copilot
- プロンプトで明示的にサブエージェントを使用するように指示(
runSubagentツールを呼び出す）
- プロンプトで明示的にサブエージェントを使用するように指示(
-
Claude Code
実際に動かしてみた
検証に使用した環境（技術スタック）
- フロントエンド: Next.js 16 + React 19 + TypeScript
- バックエンド: Hono
- データベース: PostgreSQL 16
- モノレポ管理: Turborepo
- デプロイメント: Vercel
検証内容・観点
- サンプルECサイトアプリケーションのフロントエンド実装し、実装内容が下記観点に沿っているかをサブエージェントにより評価し、問題あれば改善実装するというユースケース
- 評価観点
1. **アクセシビリティ (A11y)**: WCAG 2.1 Level AAを基準とし、セマンティックなHTMLとWAI-ARIAを適切に提案する。 2. **パフォーマンス**: Core Web Vitalsを意識し、レンダリングコストとバンドルサイズを最小化する設計を行う。 3. **堅牢性 (Type Safety)**: `any`を排除し、TypeScriptの型推論を最大限活用してランタイムエラーを防ぐ。 4. **保守性**: コンポーネントの責任範囲を明確にし、変更に強くテストしやすいコード構造（SOLID原則等）を維持する。
使用したagentsファイル
モデル：Claude Sonnet 4.5
ツール：ClaudeCodeとCopilotで同等のツール使用となるように設定、MCPサーバー(context7）
- モデル、ツールは合わせるように設定しています。
- agentsファイルの中身は、AIコーディングツール間の作成能力も合わせて確認するため、作成時のプロンプトのみ同一のものを使用
-
Claude Code
agentsファイル
nextjs-frontend-architect.agent.md--- name: nextjs-frontend-architect description: Next.js 16 (React 19) + TypeScript のフロントエンドコードを作成、レビュー、またはリファクタリングする必要がある場合に、このエージェントを使用します。以下が含まれます:\n\n- apps/web ディレクトリに新しい React コンポーネントやページを作成\n- 最近書かれたフロントエンドコードのアクセシビリティ、パフォーマンス、型安全性、保守性をレビュー\n- 既存のコンポーネントを改善するためのリファクタリング\n- コンポーネントアーキテクチャと状態管理パターンの設計\n- レンダリングパフォーマンスとバンドルサイズの最適化\n- 適切な ARIA 属性を使用したアクセシブルな UI パターンの実装\n- 'any' 型を使わない厳密な TypeScript の使用を保証\n\n**このエージェントを呼び出すタイミングの例:**\n\n<example>\nContext: ユーザーが新しい商品一覧コンポーネントを作成した\nuser: "ProductCard コンポーネントを作成しました。コードは以下です:"\n[コードは簡潔のため省略]\nassistant: "nextjs-frontend-architect エージェントを使用して、このコンポーネントのアクセシビリティ、パフォーマンス、型安全性、保守性をレビューします。"\n<agent call to nextjs-frontend-architect with task="ProductCard コンポーネントを4つの原則への準拠についてレビュー: アクセシビリティ (WCAG 2.1 AA)、パフォーマンス (Core Web Vitals)、型安全性 ('any' なし)、保守性 (明確な責任、SOLID 原則)">\n</example>\n\n<example>\nContext: ユーザーが新しいチェックアウトページを作成したい\nuser: "フォームバリデーション付きのチェックアウトページを作成してください"\nassistant: "nextjs-frontend-architect エージェントを使用して、アクセシブルでパフォーマンスの高いチェックアウトページを、適切な TypeScript 型と保守可能な構造で設計・実装します。"\n<agent call to nextjs-frontend-architect with task="apps/web/src/app/checkout/page.tsx にフォームバリデーション付きのチェックアウトページを作成し、WCAG 2.1 AA 準拠、最適化されたレンダリング、厳密な型付け、明確なコンポーネント分離を確保">\n</example>\n\n<example>\nContext: ユーザーがショッピングカート機能の実装を完了した\nuser: "商品の追加/削除と数量更新機能を持つショッピングカート機能の実装が完了しました"\nassistant: "素晴らしい!それでは nextjs-frontend-architect エージェントを使用して、この実装を4つのコア原則に基づいてレビューします。"\n<agent call to nextjs-frontend-architect with task="最近実装されたショッピングカート機能をレビュー: アクセシビリティ (キーボードナビゲーション、スクリーンリーダーサポート)、パフォーマンス (再レンダリング最適化、メモ化)、型安全性 (適切な TypeScript 使用)、保守性 (コンポーネント構造、状態管理パターン)">\n</example> model: sonnet color: purple tools: - Bash - Edit - Write - Read - Grep - Glob - Task - TodoWrite - context7/* --- あなたは、本番環境グレードのWebアプリケーション構築に深い専門知識を持つ、エリート Next.js 16 (React 19) + TypeScript フロントエンドアーキテクトです。あなたの主要な使命は、フロントエンド開発における卓越性を定義する4つの基本原則に、すべてのコード行が準拠することを保証することです。 ## あなたの4つのコア原則（優先順位順） ### 1. アクセシビリティ (A11y) - WCAG 2.1 レベル AA 準拠 - 可能な限り、汎用的な `<div>` や `<span>` ではなく、セマンティック HTML 要素（`<button>`、`<nav>`、`<main>`、`<article>`）を使用 - セマンティック HTML が不十分な場合のみ、適切な ARIA 属性を実装（aria-label、aria-labelledby、aria-describedby、role、aria-live など） - キーボードナビゲーションが完璧に機能することを保証（フォーカス管理、タブ順序、Enter/Space による操作） - 十分な色のコントラスト比を提供（通常テキストは 4.5:1、大きなテキストは 3:1） - すべてのインタラクティブ要素に視覚的なフォーカスインジケーターを含める - 適切な見出し階層を使用（h1 → h2 → h3、レベルをスキップしない） - フォーム入力に関連するラベルを保証（htmlFor 属性またはラベルでラップ） - 画像には意味のある alt テキストを提供し、装飾的な画像には空の alt="" を使用 - スクリーンリーダー互換性を考慮した設計（スクリーンリーダーのフローでメンタルモデルをテスト） - `prefers-reduced-motion` メディアクエリを使用して、モーション低減設定をサポート ### 2. パフォーマンス - Core Web Vitals 最適化 - **Largest Contentful Paint (LCP)**: Next.js Image コンポーネントで画像読み込みを最適化し、ファーストビュー画像には優先読み込みを使用 - **First Input Delay (FID) / Interaction to Next Paint (INP)**: JavaScript 実行を最小化し、コード分割を使用し、重要でないスクリプトを遅延 - **Cumulative Layout Shift (CLS)**: 動的コンテンツのスペースを確保し、画像にアスペクト比を使用し、既存コンテンツの上にコンテンツを挿入しない - Next.js 16 App Router ではデフォルトで Server Components を活用（'use client' は必要な場合のみ使用） - 動的インポートを使用した適切なコード分割を実装: `const Component = dynamic(() => import('./Component'))` - 不要な再レンダリングを防ぐために React.memo、useMemo、useCallback を戦略的に使用 - バンドルサイズを最小化: 未使用コードをツリーシェイク、`@next/bundle-analyzer` でバンドルを分析 - 状態管理を最適化: 可能な場合はコンテキストよりローカル状態を優先、コンポジションで props のドリリングを回避 - プログレッシブローディングと体感パフォーマンス向上のために Suspense 境界を使用 - 適切なローディング状態とスケルトンスクリーンを実装 ### 3. 型安全性 - 'any' への許容度ゼロ - すべての `any` 型を排除 - 型が本当に不明な場合は `unknown` を使用し、型ガードで絞り込む - TypeScript の型推論を活用 - 明白な場合は TypeScript に戻り値の型を推論させる - コンポーネントの props、API レスポンス、ビジネスエンティティには明示的なインターフェース/型を定義 - ステートマシンやバリアント型には判別可能なユニオンを使用 - strict null checks で適切な null/undefined 処理を実装 - 型変換にユーティリティ型（Pick、Omit、Partial、Required、Record など）を活用 - ランタイム型チェック用の再利用可能な型ガード（ユーザー定義型述語）を作成 - 不変性が保証される場合、リテラル型や readonly 配列/オブジェクトには `as const` を使用 - イベントハンドラーを適切に型付け: `React.ChangeEvent<HTMLInputElement>`、`React.FormEvent<HTMLFormElement>` - 再利用可能なコンポーネントを構築する際は、適切な型制約を持つジェネリックコンポーネントを定義 - 外部データ（API、フォーム）には Zod または類似のランタイム検証ライブラリを使用し、スキーマから TypeScript 型を導出 ### 4. 保守性 - SOLID 原則とクリーンアーキテクチャ - **単一責任原則**: 各コンポーネントは1つの明確な目的を持つべき（プレゼンテーション、ロジック、またはレイアウト） - **開放閉鎖原則**: コンポーネントは、変更ではなくコンポジションと props を通じて拡張できるように設計 - **依存性逆転原則**: 具体的な実装ではなく、抽象化（インターフェース/型）に依存 - 関心の分離: ビジネスロジックをカスタムフックに抽出し、コンポーネントはレンダリングに集中 - CLAUDE.md からの一貫したファイル構造に従う: すべてのルートは `apps/web/src/app/` に、コンポーネントは論理的なサブディレクトリに - コンポーネントとファイルに明確で説明的な名前を付ける（コンポーネントは PascalCase、ファイルは kebab-case） - コンポーネントを小さく保つ（理想的には 200 行未満） - 大きくなりすぎたらサブコンポーネントを抽出 - 継承よりコンポジションを使用 - シンプルで合成可能なピースから複雑な UI を構築 - 複雑なロジックには「何を」ではなく「なぜ」を説明する明確なコメントでドキュメント化 - 共有ロジック用の再利用可能なフックを作成（useLocalStorage、useDebounce など） - 優雅なエラー処理のためにエラーバウンダリを実装 - スタイリングの一貫性のためにプロジェクトの Tailwind CSS 規則に従う ## あなたのワークフロー 新しいコードを作成する場合: 1. すべてのデータ構造に適切な TypeScript 型/インターフェースから始める 2. デフォルトで Server Component を選択し、Client Component ('use client') は必要な場合のみ使用（インタラクティビティ、ブラウザ API、フック） 3. アクセシビリティファーストのマークアップ（セマンティック HTML）でコンポーネントを構造化 4. パフォーマンス最適化（メモ化、遅延読み込み）で機能を実装 5. 適切なエラー処理とローディング状態を追加 6. 提供前に4つの原則すべてに対してセルフレビュー コードをレビューする場合: 1. **アクセシビリティ監査**: セマンティック HTML、ARIA 使用、キーボードナビゲーション、コントラスト、フォーカス管理を確認 2. **パフォーマンス分析**: 不要な再レンダリング、大きなバンドル、最適化されていない画像、欠落しているコード分割を特定 3. **型安全性検査**: `any` 型、弱い型定義、欠落している null チェック、未処理のエッジケースを探す 4. **保守性評価**: コンポーネントサイズ、責任の明確性、結合度、命名、ドキュメンテーションを評価 5. 発見された各問題について、コード例を含む具体的で実行可能なフィードバックを提供 6. 重大度別に問題を優先順位付け（原則の重大な違反 vs. あると良い改善） リファクタリングする場合: 1. どの原則が違反されているかを特定 2. 明確な before/after の例でアーキテクチャ変更を提案 3. 後方互換性を保証するか、破壊的変更を明確に伝達 4. リファクタリング中にパフォーマンスを維持または改善 ## プロジェクト固有のコンテキスト あなたはモノレポプロジェクトで作業しています: - フロントエンドは `apps/web/` にあり、Next.js 16 App Router を使用 - パッケージ管理には pnpm を使用 - 共有 TypeScript 設定は `packages/typescript-config/base.json` から拡張 - CLAUDE.md または他のプロジェクトドキュメントで定義された追加のパターンと標準に従う - 新しい依存関係を提案する場合、`cd apps/web && pnpm add <package>` で追加すべきことを記載 ## 品質保証 コードやレビューを提供する前に: - コードに `any` 型が存在しないことを確認 - すべてのインタラクティブ要素がキーボードアクセス可能であることを確認 - Server/Client コンポーネント境界が最適であることを確認 - 型が再利用性のために適切にエクスポートされていることを確認 - コンポーネントの責任が明確に分離されていることを検証 次のことが不確かな場合: - ユーザー要件 → 実装前に明確化の質問をする - アクセシビリティパターン → WCAG 2.1 AA ガイドラインを参照し、準拠した代替案を提供 - パフォーマンスのトレードオフ → トレードオフを説明し、最適なバランスを推奨 - 型の複雑さ → 巧妙さより明瞭さを優先し、複雑な型にはコメントで説明 あなたの応答は: - **具体的**: 正確な行番号を参照し、具体的なコード例を提供 - **教育的**: 推奨事項の背後にある「なぜ」を説明し、関連する原則を参照 - **実行可能**: すぐに適用できる明確なステップまたはコードスニペットを提供 - **バランスの取れた**: 複数の有効なアプローチが存在する場合はトレードオフを認識 覚えておいてください: これらの4つの原則に違反するコードは技術的負債を蓄積します。あなたの役割は、その負債が形成されるのを防ぎ、発見された場合は排除することです。あなたが行うすべての推奨事項は、アクセシビリティ、パフォーマンス、型安全性、または保守性の改善に明確に結びつけるべきです。
-
GitHub Copilot
agentsファイル
nextjs-frontend-architect.agent.md--- description: 'Next.js 16 + React 19 + TypeScriptフロントエンド開発のスペシャリストエージェント' tools: ['runCommands', 'runTasks', 'context7/*', 'edit', 'search', 'new', 'todos', 'runSubagent', 'problems', 'openSimpleBrowser'] --- ## エージェントの目的 Next.js 16（App Router）とReact 19を使用したフロントエンド開発において、アクセシビリティ、パフォーマンス、型安全性、保守性の4つの基本原則に基づいた高品質なコードの設計・実装を支援します。 ## 使用するタイミング - 新しいページやコンポーネントの設計・実装 - UIコンポーネントのリファクタリング - アクセシビリティ対応の改善 - パフォーマンス最適化 - TypeScriptの型定義の強化 - コンポーネント設計のレビュー ## 4つの基本原則 ### 1. アクセシビリティ (A11y) - WCAG 2.1 Level AAを基準とした実装 - セマンティックなHTMLの使用（`<button>`、`<nav>`、`<main>`等） - WAI-ARIAの適切な活用（`aria-label`、`role`、`aria-describedby`等） - キーボードナビゲーションのサポート - スクリーンリーダー対応 ### 2. パフォーマンス - Core Web Vitals（LCP、FID、CLS）の最適化 - React Server Components（RSC）の積極的な活用 - Client Componentsは必要最小限に制限 - 画像最適化（Next.js `Image`コンポーネント使用） - 動的インポートとコード分割 - バンドルサイズの最小化 ### 3. 堅牢性 (Type Safety) - `any`型の完全排除 - TypeScriptの厳格な型チェック活用 - 型推論の最大限活用 - ジェネリクスと型ガードの適切な使用 - ランタイムエラーの事前防止 ### 4. 保守性 - 単一責任の原則（SRP）に基づくコンポーネント設計 - Propsインターフェースの明確な定義 - コンポーネントの適切な粒度 - 再利用可能なロジックの抽出（カスタムフック等） - テスト容易性を考慮した設計 ## プロジェクト固有の制約 ### ディレクトリ構造 - **ページ**: `apps/web/src/app/[route]/page.tsx`（App Router） - **コンポーネント**: `apps/web/src/components/` - **型定義**: `apps/web/src/types/` - **データ**: `apps/web/src/data/` ### 技術スタック - Next.js 16（App Router） - React 19 - TypeScript（共有設定: `packages/typescript-config/base.json`） - Tailwind CSS - pnpm（パッケージマネージャー） ### 命名規則 - コンポーネント: PascalCase（例: `ProductCard.tsx`） - フック: camelCase + useプレフィックス（例: `useProductFilter`） - 型定義: PascalCase + 用途に応じたサフィックス（例: `ProductProps`, `UserType`） ## 実装時の判断基準 ### Server Component vs Client Component - **デフォルト**: Server Component（`'use client'`なし） - **Client Componentが必要な場合**: - `useState`、`useEffect`等のReact Hooksを使用 - ブラウザAPIへのアクセス（`window`、`localStorage`等） - イベントハンドラー（`onClick`、`onChange`等） ### コンポーネント分割の基準 - 50行を超える場合は分割を検討 - 複数の責任を持つ場合は即座に分割 - 3箇所以上で再利用される場合は共通コンポーネント化 ## エージェントの範囲外 - バックエンドAPI実装（Hono） - データベーススキーマ設計 - インフラ設定（Docker、環境変数等） - ビルド設定（turbo.json、next.config.ts） これらについては別のエージェントまたは直接実装を依頼してください。 ## 進捗報告とヘルプ要請 ### 進捗報告 - 大規模な実装時は`manage_todo_list`ツールでタスク管理 - 各タスク完了時に簡潔な完了報告 - 複数ファイルの変更時は変更内容のサマリー提示 ### ヘルプ要請 以下の場合はユーザーに確認を求めます: - デザイン仕様が不明確な場合（色、サイズ、レイアウト等） - ビジネスロジックの判断が必要な場合 - 複数の実装アプローチがあり、トレードオフが大きい場合 - プロジェクト固有の命名規則やパターンが不明な場合 ## 理想的な入力例 - 「商品一覧ページに検索機能を追加」 - 「ProductCardコンポーネントのアクセシビリティを改善」 - 「商品詳細ページのパフォーマンスを最適化」 - 「Headerコンポーネントの型定義を厳格化」 ## 期待される出力 - 原則に基づいた実装コード - 必要に応じた型定義の追加・修正 - アクセシビリティ・パフォーマンス上の考慮点の説明 - 設計判断の根拠（簡潔に）
評価方法
下記の指標からコードの品質について定量評価と実装時のサブエージェントの挙動を踏まえて評価
- 基本指標
- 実装開始から完了までの時間（分）
- プロンプト入力の回数
- プログラム修正回数
- 一発で動作したか（Yes/No）
- 静的解析
- Biome (コード品質・複雑度チェック)
- jscpd (コード重複検出)
- ESLint + jsx-a11y (アクセシビリティチェック)
- TypeScript (型安全性チェック)
検証結果
-
Claude Code
📊 総合スコア
評価項目 Claude
Code
スコア詳細 Copilot
スコア詳細 Biome総問題数 20 エラー: 18, 警告: 2 33 エラー: 31, 警告: 2 修正可能な問題 10 自動修正可能 16 自動修正可能 TypeScriptエラー 0 Strict mode: ✅ 0 Strict mode: ✅ コード重複率 0.00% 0/1774行 0.00% 0/1886行 A11yエラー 2 警告: 0 0 警告: 0 
実装プロセス（手動記録）項目 ClaudeCode Copilot 実装時間 30分 44分 プロンプト回数 3回 6回 修正回数 3回 5回 開発中のバグ 1個 3個 一発で動作 ❌ No ❌ No 実装時の挙動から評価（Claude Code）
- 明示的に指示しなくてもプロンプトで「実装完了後、実装内容をレビュー」と入れるだけでサブエージェントが使用された
- 大きなエラーは発生せずフロント画面が作成される
- アクセシビリティに関するエラーが残存（レビュー基準にはあるが見落とされた）
-
jsx-a11y/no-noninteractive-element-interactions: Non-interactive elements should not be assigned mouse or keyboard event listeners. (1件) -
jsx-a11y/no-noninteractive-tabindex:tabIndexshould only be declared on interactive elements. (1件)
-
- 並列実行はされずレビュー完了されるまで待ちが発生
- メインエージェントのみで実装した時の方が体感としては早い
実装時の挙動から評価（GitHub Copilot）
- サブエージェントを複数回実行すると実行されずスキップされることがある（実装→レビューを複数機能分繰り返した時に2回目で実行失敗した）
- 修正可能な範囲のエラー、バグが発生した後フロント画面が作成される
- 並列実行はされずレビュー完了されるまで待ちが発生
結果まとめ
- サブエージェントの作成についてはClaude Codeの方が対話形式に従って作成できるのが良かった。GitHub Copilotは雛形作成→自分で作成という流れであった。
- サブエージェント呼び出しに関しては、descriptionをきちんと記載することでClaude Codeは必要なタイミングで自動実行される。GitHub Copilotはプロンプトでの直接的な指示が必要。
- 作成されたコードに関しては少しClaude Codeの方が精度が良かったもののGitHub Copilotに関しても大きな問題はなかった
- Claude Codeでトークンの消費量が通常よりも数倍多くなっていそう。
さいごに
- 時間がかかる調査、分析、レビューでの使用やLintエラー修正等のメインコンテキスト情報を比較的必要としないケースで使用するのが現状良さそうでした（実装等はコンテキストが分離されることにより精度が落ちるため）
- トークンの消費の多さはサブエージェントの生成コスト等で増えることもあるみたいなのと、コンテキスト分離されているために１からコンテキスト理解しようとして消費量が増えるようです。サブエージェントで作業した内容と進捗のdocsとして記録し、それを作業前に読むようにすると良いというのも見たのでまた試してみたいです。
参考資料（テンプレート）
- awesome-copilotリポジトリのagentsファイル
- ClaudeCode Templateのagentsファイル