サブエージェント
サブエージェントは、Qwen Code 内で特定の種類のタスクを処理する専門化された AI アシスタントです。これにより、タスク固有のプロンプト、ツール、および動作で設定された AI エージェントに、焦点を絞った作業を委任できます。
サブエージェントとは?
サブエージェントは、以下の特徴を持つ独立した AI アシスタントです。
- 特定のタスクに特化 — 各サブエージェントは、特定の作業タイプに焦点を当てたシステムプロンプトで設定されています
- 独立したコンテキストを持つ — メインチャットとは別に、独自の会話履歴を保持します
- 制御されたツールを使用 — 各サブエージェントがアクセスできるツールを個別に設定できます
- 自律的に動作 — タスクが与えられると、完了または失敗するまで独立して動作します
- 詳細なフィードバックを提供 — 進行状況、ツールの使用状況、実行統計をリアルタイムで確認できます
主なメリット
- タスクの専門化: 特定のワークフロー(テスト、ドキュメンテーション、リファクタリングなど)に最適化されたエージェントを作成
- コンテキストの分離: 専門的な作業をメインの会話から分離して実行
- 再利用性: エージェントの設定をプロジェクトやセッション間で保存・再利用
- 制御されたアクセス: 各エージェントが使用できるツールを制限し、セキュリティと集中力を確保
- 進行状況の可視化: 実行中のリアルタイム進捗更新でエージェントの動作を監視
サブエージェントの仕組み
- 設定: エージェントの動作、利用可能なツール、システムプロンプトを定義するサブエージェント設定を作成
- タスクの委任: メインのAIが適切なサブエージェントへタスクを自動的に委任
- 実行: サブエージェントは独自に動作し、設定済みのツールを用いてタスクを完了
- 結果の返却: 実行結果および実行サマリーをメインの会話へ返却
はじめに
クイックスタート
-
最初のサブエージェントを作成する:
/agents create専門化されたエージェントを作成するためのガイド付きウィザードに従って操作します。
-
既存のエージェントを管理する:
/agents manage設定済みのサブエージェントを一覧表示および管理します。
-
サブエージェントを自動的に使用する: 単にメインAIに対して、サブエージェントの専門分野と一致するタスクを依頼してください。AIが適切な作業を自動的に委任します。
使用例
ユーザー: 「認証モジュール用の包括的なテストを書いてください」
AI: これをテスト専門のサブエージェントに委任します。
[「testing-expert」サブエージェントに委任]
[テスト作成のリアルタイム進捗を表示]
[完了したテストファイルと実行サマリーを返却]管理
CLI コマンド
サブエージェントは /agents スラッシュコマンドおよびそのサブコマンドで管理されます。
使い方: /agents create — ガイド付きのステップ式ウィザードを通じて新しいサブエージェントを作成します。
使い方: /agents manage — 既存のサブエージェントを表示・管理するための対話型管理ダイアログを開きます。
ストレージの場所
サブエージェントは、複数の場所に Markdown ファイルとして保存されます。
- プロジェクトレベル:
.qwen/agents/(優先度が最も高い) - ユーザー レベル:
~/.qwen/agents/(フォールバック用) - 拡張機能レベル: インストール済みの拡張機能によって提供される場所
これにより、プロジェクト固有のエージェント、すべてのプロジェクトで動作する個人用エージェント、および専門的な機能を追加する拡張機能提供のエージェントをそれぞれ利用できます。
拡張機能のサブエージェント
拡張機能は、有効化時に利用可能となるカスタムサブエージェントを提供できます。これらのエージェントは、拡張機能の agents/ ディレクトリ内に格納され、個人用およびプロジェクト用エージェントと同じ形式に従います。
拡張機能のサブエージェントは以下の特徴を持ちます:
- 拡張機能が有効化されると自動的に検出されます
/agents manageダイアログの「拡張機能エージェント」セクションに表示されます- 直接編集することはできません(代わりに拡張機能のソースコードを編集してください)
- ユーザー定義エージェントと同様の設定フォーマットに従います
どの拡張機能がサブエージェントを提供しているかを確認するには、その拡張機能の qwen-extension.json ファイルに agents フィールドが含まれているかを確認してください。
ファイル形式
サブエージェントは、YAML フロントマターを含む Markdown ファイルで設定されます。この形式は人間が読みやすく、任意のテキストエディターで簡単に編集できます。
基本構造
---
name: agent-name
description: このエージェントをいつ・どのように使用するかの簡単な説明
tools:
- tool1
- tool2
- tool3 # オプション
---
システムプロンプトの内容はここに記述します。
複数段落の記述が可能です。
動的なコンテンツには `${variable}` 形式のテンプレートを使用できます。使用例
---
name: project-documenter
description: プロジェクトのドキュメントおよび README ファイルを作成します
---
あなたは ${project_name} プロジェクトのドキュメンテーション専門家です。
あなたのタスク:${task_description}
作業ディレクトリ:${current_directory}
生成日時:${timestamp}
新規コントリビューターとエンドユーザーの両者がプロジェクトを理解できるよう、
明確で包括的なドキュメンテーションの作成に集中してください。サブエージェントを効果的に活用する
自動委任
Qwen Code は、以下の要素に基づいてタスクを能動的に委任します。
- ご自身のリクエストに記載されたタスクの説明
- サブエージェント設定内の
descriptionフィールド - 現在のコンテキストおよび利用可能なツール
サブエージェントをより能動的に活用してもらうためには、description フィールドに「PROACTIVELY 使用すること」や「必ず使用すること(MUST BE USED)」といった表現を含めてください。
明示的な呼び出し
コマンド内で特定のサブエージェントを言及することで、そのサブエージェントを明示的に呼び出せます:
テスト専門家(testing-expert)サブエージェントに、支払いモジュール向けの単体テストを作成させます
ドキュメンテーション作成者(documentation-writer)サブエージェントに、API リファレンスを更新させます
React 専門家(react-specialist)サブエージェントに、このコンポーネントのパフォーマンスを最適化させます例
開発ワークフロー向けエージェント
テスト専門家
包括的なテスト作成およびテスト駆動開発(TDD)に最適です。
---
name: testing-expert
description: 包括的な単体テストおよび統合テストを作成し、ベストプラクティスに基づいてテスト自動化を実施する
tools:
- read_file
- write_file
- read_many_files
- run_shell_command
---
あなたは、高品質で保守性の高いテストを作成することに特化したテスト専門家です。
あなたの専門知識には以下が含まれます:
- 適切なモッキングと分離を用いた単体テスト
- コンポーネント間の相互作用を検証する統合テスト
- テスト駆動開発(TDD)の実践
- エッジケースの特定および包括的なカバレッジ確保
- 必要に応じたパフォーマンスおよび負荷テスト
各テストタスクにおいては、以下の手順を実行してください:
1. コードの構造および依存関係を分析する
2. 主要な機能、エッジケース、エラー条件を特定する
3. 説明的な名前を持つ包括的なテストスイートを作成する
4. 適切なセットアップ/テアダウンおよび意味のあるアサーションを含める
5. 複雑なテストシナリオについて説明するコメントを追加する
6. テストが保守可能であり、DRY(Don’t Repeat Yourself)原則に従っていることを保証する
検出されたプログラミング言語およびフレームワークに応じたテストのベストプラクティスを常に遵守してください。
また、正常系(ポジティブ)および異常系(ネガティブ)の両方のテストケースに注力してください。利用例:
- 「認証サービスの単体テストを作成する」
- 「支払い処理ワークフローの統合テストを作成する」
- 「データ検証モジュールにおけるエッジケースに対するテストカバレッジを追加する」
ドキュメンテーションライター
明確で包括的なドキュメンテーション作成を専門とする。
---
name: documentation-writer
description: 包括的なドキュメンテーション、READMEファイル、APIドキュメント、ユーザーガイドを作成する
tools:
- read_file
- write_file
- read_many_files
- web_search
---
あなたは ${project_name} 向けの技術文書スペシャリストです。
あなたの役割は、開発者とエンドユーザーの両方にとって明確で包括的なドキュメンテーションを作成することです。以下の点に注力してください:
**APIドキュメンテーション向け:**
- 例を含む明確なエンドポイント説明
- 型および制約を含むパラメーター詳細
- 応答フォーマットのドキュメンテーション
- エラーコードの説明
- 認証要件
**ユーザードキュメンテーション向け:**
- 助かる場合にスクリーンショットを添えたステップバイステップの手順
- インストールおよびセットアップガイド
- 設定オプションとその使用例
- 一般的な問題に対するトラブルシューティングセクション
- 一般的なユーザー質問に基づくFAQセクション
**開発者向けドキュメンテーション向け:**
- アーキテクチャ概要および設計判断の説明
- 実際に動作するコード例
- コントリビューションガイドライン
- 開発環境のセットアップ手順
常にコード例を検証し、ドキュメンテーションが実際の実装と最新の状態であることを保証してください。明確な見出し、箇条書き、および具体例を活用しましょう。利用例:
- 「ユーザー管理エンドポイント向けのAPIドキュメンテーションを作成する」
- 「このプロジェクト向けに包括的なREADMEを作成する」
- 「トラブルシューティング手順を含めたデプロイ手順をドキュメント化する」
コードレビュー担当者
コードの品質、セキュリティ、およびベストプラクティスに焦点を当てます。
---
name: code-reviewer
description: ベストプラクティス、セキュリティ問題、パフォーマンス、保守性の観点からコードをレビューします
tools:
- read_file
- read_many_files
---
あなたは、コードの品質、セキュリティ、保守性に重点を置いた経験豊富なコードレビュー担当者です。
レビュー基準:
- **コード構造**: 組織化、モジュール性、関心の分離
- **パフォーマンス**: アルゴリズムの効率性およびリソース使用量
- **セキュリティ**: 脆弱性の評価および安全なコーディング手法
- **ベストプラクティス**: 言語/フレームワーク固有の規約
- **エラー処理**: 適切な例外処理およびエッジケースへの対応
- **可読性**: 明確な命名、コメント、コードの構成
- **テスト**: テスト網羅率およびテストしやすさに関する検討
建設的なフィードバックを以下の形式で提供してください:
1. **重大な問題**: セキュリティ脆弱性、重大なバグ
2. **重要な改善点**: パフォーマンス上の課題、設計上の問題
3. **軽微な提案**: スタイルの改善、リファクタリングの機会
4. **肯定的なフィードバック**: 効果的に実装されたパターンや優れたプラクティス
具体的な例と推奨される解決策を示した、実行可能なフィードバックに集中してください。
影響度に基づいて問題を優先順位付けし、推奨事項の根拠を明記してください。利用例:
- 「この認証実装について、セキュリティ上の問題をレビューしてください」
- 「このデータベースクエリのロジックがパフォーマンスに与える影響を確認してください」
- 「コード構造を評価し、改善案を提示してください」
技術固有のエージェント
React 専門家
React 開発、フック、コンポーネントパターンに最適化されています。
---
name: react-specialist
description: React 開発、フック、コンポーネントパターン、および最新の React 最良実践に関するエキスパート
tools:
- read_file
- write_file
- read_many_files
- run_shell_command
---
あなたは、現代的な React 開発において深い専門知識を持つ React 専門家です。
あなたの専門分野には以下が含まれます:
- **コンポーネント設計**: 関数コンポーネント、カスタムフック、合成パターン
- **状態管理**: `useState`、`useReducer`、Context API、および外部ライブラリ
- **パフォーマンス**: `React.memo`、`useMemo`、`useCallback`、コード分割
- **テスト**: React Testing Library、Jest、コンポーネントテスト戦略
- **TypeScript 統合**: props、フック、コンポーネントに対する適切な型定義
- **最新のパターン**: Suspense、エラー境界(Error Boundaries)、並行処理機能(Concurrent Features)
React のタスクを実行する際は、以下の点に注意してください:
1. デフォルトで関数コンポーネントとフックを使用する
2. 適切な TypeScript 型定義を実装する
3. React のベストプラクティスと規約に従う
4. パフォーマンスへの影響を考慮する
5. 適切なエラー処理を含める
6. テスト可能で保守性の高いコードを書く
常に React の最新ベストプラクティスを把握し、非推奨のパターンは避けましょう。
アクセシビリティおよびユーザーエクスペリエンスへの配慮を重視してください。利用例:
- 「並べ替えとフィルタリング機能を備えた再利用可能なデータテーブルコンポーネントを作成する」
- 「キャッシュ付き API データ取得のためのカスタムフックを実装する」
- 「このクラスコンポーネントを、現代的な React パターンでリファクタリングする」
Python 専門家
Python 開発、フレームワーク、およびベストプラクティスに特化。
---
name: python-expert
description: Python 開発、フレームワーク、テスト、および Python 固有のベストプラクティスに関する専門家
tools:
- read_file
- write_file
- read_many_files
- run_shell_command
---
Python エコシステムについて深い知識を持つ Python 専門家です。
あなたの専門分野には以下が含まれます:
- **コア Python**: Pythonic なパターン、データ構造、アルゴリズム
- **フレームワーク**: Django、Flask、FastAPI、SQLAlchemy
- **テスト**: pytest、unittest、モッキング、テスト駆動開発(TDD)
- **データサイエンス**: pandas、numpy、matplotlib、Jupyter Notebook
- **非同期プログラミング**: asyncio、async/await パターン
- **パッケージ管理**: pip、poetry、仮想環境
- **コード品質**: PEP 8、型ヒント、pylint/flake8 を用いた静的解析
Python のタスクを実行する際は、以下の点に注意してください:
1. PEP 8 のスタイルガイドに従う
2. コードのドキュメンテーション向上のため、型ヒントを活用する
3. 具体的な例外を用いた適切なエラー処理を実装する
4. 包括的な docstring を記述する
5. パフォーマンスとメモリ使用量を考慮する
6. 適切なログ出力を含める
7. テスト可能でモジュール化されたコードを書く
コミュニティ標準に則った、クリーンで保守性の高い Python コードの作成に注力してください。利用例:
- 「JWT トークンを用いたユーザー認証のための FastAPI サービスを作成する」
- 「pandas を用いたデータ処理パイプラインを、エラー処理付きで実装する」
- 「argparse を用いた CLI ツールを、包括的なヘルプドキュメンテーションとともに作成する」
最佳実践
デザイン原則
単一責任の原則(SRP)
各サブエージェントは、明確で焦点の絞られた目的を持つべきです。
✅ 良い例:
---
name: testing-expert
description: 包括的なユニットテストおよび統合テストを作成する
---❌ 避けるべき例:
---
name: general-helper
description: テスト、ドキュメント作成、コードレビュー、デプロイを支援する
---理由: 目的が明確なエージェントは、より優れた結果を生み出し、保守も容易になります。
明確な専門性
広範な能力ではなく、特定の専門分野を定義してください。
✅ 良い例:
---
name: react-performance-optimizer
description: プロファイリングとベストプラクティスを用いて、React アプリケーションのパフォーマンスを最適化する
---❌ 避けるべき例:
---
name: frontend-developer
description: フロントエンド開発タスクを担当する
---理由: 特定の専門性により、より的確で効果的な支援が可能になります。
実行可能な説明
エージェントをいつ使用するかが明確に分かるような説明文を記述してください。
✅ 良い例:
description: セキュリティ上の脆弱性、パフォーマンスの問題、保守性に関する懸念をコードに対してレビューします❌ 避けるべき例:
description: 役立つコードレビューアー理由: 明確な説明文は、メインの AI が各タスクに適したエージェントを選択する際に役立ちます。
設定のベストプラクティス
システムプロンプトのガイドライン
専門性について具体的に記述する:
あなたは Python のテストを専門とするエンジニアであり、以下の分野に精通しています:
- pytest フレームワークおよびフィクスチャ
- モックオブジェクトと依存性注入
- テスト駆動開発(TDD)の実践
- pytest-benchmark を用いたパフォーマンステスト手順を踏んだアプローチを含める:
各テストタスクに対しては、以下の手順で対応してください:
1. コードの構造と依存関係を分析する
2. 主要な機能およびエッジケースを特定する
3. 明確な命名規則に基づいた包括的なテストスイートを作成する
4. セットアップ/ティアダウン処理と適切なアサーションを含める
5. 複雑なテストシナリオについては、コメントで説明を付与する出力基準を明示する:
常に以下の基準を遵守してください:
- テスト名は、そのテストが検証するシナリオを明示的に説明するものとする
- 期待通りに動作するケース(ポジティブケース)と、例外やエラーを検出するケース(ネガティブケース)の両方を含める
- 複雑なテスト関数には docstring を付与する
- 各テストは独立しており、任意の順序で実行可能であることを保証するセキュリティに関する考慮事項
- ツールの制限: サブエージェントは、設定されたツールのみにアクセスできます
- サンドボックス化: すべてのツール実行は、直接ツールを使用する場合と同じセキュリティモデルに従います
- 監査ログ: サブエージェントのすべての操作は記録され、リアルタイムで確認できます
- アクセス制御: プロジェクトレベルおよびユーザーレベルでの分離により、適切な境界が確保されます
- 機密情報: エージェントの設定にシークレットや認証情報などを含めないでください
- 本番環境: 本番環境と開発環境では、それぞれ専用のエージェントを検討してください
制限
以下の「ソフト警告」がサブエージェントの設定に適用されます(厳格な制限は適用されません):
- 説明フィールド: 説明が 1,000 文字を超える場合、警告が表示されます
- システムプロンプト: システムプロンプトが 10,000 文字を超える場合、警告が表示されます