Skip to Content
ユーザーガイド機能サブエージェント

サブエージェント

サブエージェントは、Qwen Code 内で特定のタイプのタスクを処理するための専門的な AI アシスタントです。これにより、タスク固有のプロンプト、ツール、および動作で構成された AI エージェントに、集中的な作業を委任できます。

サブエージェントとは?

サブエージェントは、以下のような特徴を持つ独立した AI アシスタントです:

  • 特定のタスクに特化 – 各サブエージェントは、特定の種類の作業向けに焦点を当てたシステムプロンプトで構成されています
  • 独立したコンテキストを持ちます – メインチャットとは別に、独自の会話履歴を維持します
  • 制御されたツールを使用 – 各サブエージェントがアクセスできるツールを設定できます
  • 自律的に動作 – タスクが与えられると、完了または失敗するまで独立して動作します
  • 詳細なフィードバックを提供 – 進行状況、ツール使用状況、実行統計情報をリアルタイムで確認できます

主な利点

  • タスクの専門化: 特定のワークフロー(テスト、ドキュメント作成、リファクタリングなど)に最適化されたエージェントを作成
  • コンテキストの分離: 専門的な作業をメインの会話から分離して管理
  • 再利用性: プロジェクトやセッション間でエージェント設定を保存・再利用
  • アクセス制御: 各エージェントが使用できるツールを制限し、セキュリティと集中力を維持
  • 進捗の可視化: リアルタイムの進捗更新でエージェントの実行状況を監視

サブエージェントの仕組み

  1. 設定: 振る舞いやツール、システムプロンプトを定義したサブエージェント設定を作成
  2. 委譲: メインAIが適切なサブエージェントにタスクを自動的に委譲
  3. 実行: サブエージェントが独立して動作し、設定されたツールを使ってタスクを完了
  4. 結果: 結果と実行サマリーをメインの会話に戻す

はじめに

クイックスタート

  1. 最初のサブエージェントを作成する:

    /agents create

    ガイド付きウィザードに従って、専門的なエージェントを作成します。

  2. 既存のエージェントを管理する:

    /agents manage

    設定済みのサブエージェントを表示および管理します。

  3. サブエージェントを自動的に使用する: メインAIに、サブエージェントの専門分野に一致するタスクを実行するように単純に依頼してください。AIが適切な作業を自動的に委任します。

使用例

User: "認証モジュールの包括的なテストを書いてください" AI: これをテスト専門のサブエージェントに委任します。 [「testing-expert」サブエージェントに委任] [テスト作成のリアルタイム進捗を表示] [完了したテストファイルと実行概要を返却]`

管理

CLI コマンド

サブエージェントは、/agents スラッシュコマンドとそのサブコマンドを通じて管理されます:

使用方法: /agents create。ガイド付きステップウィザードを使用して新しいサブエージェントを作成します。

使用方法: /agents manage。既存のサブエージェントを表示および管理するためのインタラクティブな管理ダイアログを開きます。

保存場所

サブエージェントは、以下の2つの場所に Markdown ファイルとして保存されます:

  • プロジェクトレベル: .qwen/agents/(優先)
  • ユーザーレベル: ~/.qwen/agents/(フォールバック)

これにより、プロジェクト固有のエージェントと、すべてのプロジェクトで動作する個人用エージェントの両方を持つことができます。

ファイル形式

サブエージェントは、YAML フロントマター付きの Markdown ファイルを使用して設定されます。この形式は人間が読みやすく、任意のテキストエディタで簡単に編集できます。

基本構造

--- name: エージェント名 description: このエージェントを使用するタイミングと方法の簡単な説明 tools: - ツール1 - ツール2 - ツール3 # 任意 --- システムプロンプトの内容をここに記述します。 複数の段落に対応しています。 動的コンテンツには ${variable} テンプレートを使用できます。

使用例

--- name: project-documenter description: プロジェクトドキュメントとREADMEファイルを作成します --- あなたは ${project_name} プロジェクトのドキュメントスペシャリストです。 タスク: ${task_description} 作業ディレクトリ: ${current_directory} 生成日時: ${timestamp} 新しい貢献者とエンドユーザーの両方がプロジェクトを理解できるよう、 明確で包括的なドキュメントを作成することに重点を置いてください。

サブエージェントの効果的な使用方法

自動委任

Qwen Code は以下の基準に基づいて、積極的にタスクをサブエージェントに委任します:

  • リクエスト内のタスクの説明
  • サブエージェント設定の description フィールド
  • 現在のコンテキストと利用可能なツール

より積極的なサブエージェントの使用を促進するには、description フィールドに「PROACTIVELY を使用」や「必ず使用する必要がある」などのフレーズを含めてください。

明示的呼び出し

コマンド内で特定のサブエージェントを呼び出すことでリクエストできます:

testing-expert サブエージェントに支払いモジュールのユニットテストを作成させる documentation-writer サブエージェントに API リファレンスを更新させる react-specialist サブエージェントにこのコンポーネントのパフォーマンスを最適化させる

開発ワークフロー エージェント

テストスペシャリスト

包括的なテスト作成とテスト駆動開発に最適です。

--- name: testing-expert description: 包括的なユニットテスト、結合テストを作成し、ベストプラクティスに基づいたテスト自動化を担当します tools: - read_file - write_file - read_many_files - run_shell_command --- あなたは高品質で保守性の高いテストを作成することに特化したテストスペシャリストです。 あなたの専門知識には以下が含まれます: - 適切なモックと分離によるユニットテスト - コンポーネント間の相互作用を検証する結合テスト - テスト駆動開発(TDD)の実践 - エッジケースの特定と包括的なテストカバレッジ - 必要に応じたパフォーマンステストおよび負荷テスト 各テストタスクに対して以下の手順を踏んでください: 1. コード構造と依存関係を分析する 2. 主要機能、エッジケース、エラー条件を特定する 3. 説明的な名前を持つ包括的なテストスイートを作成する 4. 適切なセットアップ/ティアダウン処理と意味のあるアサーションを含める 5. 複雑なテストシナリオについてコメントを追加する 6. テストが保守可能であり、DRY原則に従っていることを確認する 常に検出された言語とフレームワークにおけるテストのベストプラクティスに従ってください。 正常系だけでなく異常系のテストケースにも焦点を当ててください。

使用例:

  • 「認証サービスのユニットテストを書いてください」
  • 「支払い処理ワークフローの結合テストを作成してください」
  • 「データ検証モジュールのエッジケースに対するテストカバレッジを追加してください」

ドキュメントライター

明確で包括的なドキュメント作成を専門に行います。

--- 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 Specialist

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、hooks、コンポーネントの適切な型付け - **モダンパターン**: 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 エキスパートです。 あなたの専門知識には以下が含まれます: - **Core Python**: Pythonic パターン、データ構造、アルゴリズム - **Frameworks**: Django, Flask, FastAPI, SQLAlchemy - **Testing**: pytest, unittest, モック、テスト駆動開発 - **Data Science**: pandas, numpy, matplotlib, Jupyter Notebook - **Async Programming**: asyncio, async/await パターン - **Package Management**: pip, poetry, 仮想環境 - **Code Quality**: PEP 8, 型ヒント、pylint/flake8 によるリンティング Python のタスクにおいて: 1. PEP 8 スタイルガイドラインに従ってください 2. コードのドキュメント化のために型ヒントを使用してください 3. 特定の例外を使った適切なエラーハンドリングを実装してください 4. 包括的な docstring を記述してください 5. パフォーマンスとメモリ使用量を考慮してください 6. 適切なロギングを含めてください 7. テスト可能でモジュール化されたコードを書いてください コミュニティ標準に準拠した、クリーンで保守可能な Python コードの作成に重点を置いてください。

ユースケース:

  • 「JWT トークンを使用したユーザー認証のための FastAPI サービスを作成する」
  • 「pandas とエラーハンドリングを使用してデータ処理パイプラインを実装する」
  • 「包括的なヘルプドキュメント付きの argparse を使用して CLI ツールを作成する」

ベストプラクティス

設計原則

単一責任原則

各サブエージェントは、明確で集中した目的を持つべきです。

✅ 良い例:

--- name: testing-expert description: 総合的なユニットテストとインテグレーションテストを記述します ---

❌ 避けるべき例:

--- name: general-helper description: テスト、ドキュメント作成、コードレビュー、デプロイを支援します ---

理由: 目的が明確なエージェントほど、より良い結果を生み出し、保守も容易になります。

明確な専門性

広範な能力よりも、特定の専門領域を定義しましょう。

✅ 良い例:

--- name: react-performance-optimizer description: プロファイリングとベストプラクティスを使用してReactアプリケーションのパフォーマンスを最適化します ---

❌ 避けるべき例:

--- name: frontend-developer description: フロントエンド開発タスクに取り組みます ---

理由: 特定の専門知識があることで、より的確で効果的な支援が可能になります。

実行可能な説明文

エージェントをいつ使用すべきかを明確に示す説明文を記述してください。

✅ 良い例:

description: セキュリティ脆弱性、パフォーマンス問題、保守性の懸念についてコードをレビューします

❌ 避けるべき例:

description: 役に立つコードレビューエージェント

理由: 明確な説明文は、メインのAIが各タスクに適したエージェントを選択するのに役立ちます。

設定のベストプラクティス

システムプロンプトガイドライン

専門性について具体的に記述する:

あなたは以下の専門知識を持つPythonテストスペシャリストです: - pytestフレームワークとフィクスチャ - モックオブジェクトと依存性注入 - テスト駆動開発のプラクティス - pytest-benchmarkによるパフォーマンステスト

ステップバイステップのアプローチを含める:

各テストタスクに対して: 1. コード構造と依存関係を分析する 2. キーとなる機能とエッジケースを特定する 3. 明確な命名規則を持った包括的なテストスイートを作成する 4. セットアップ/テアダウンと適切なアサーションを含める 5. 複雑なテストシナリオを説明するコメントを追加する

出力標準を指定する:

常に以下の標準に従ってください: - シナリオを説明する記述的なテスト名を使用する - 正常系と異常系の両方のテストケースを含める - 複雑なテスト関数にはdocstringを追加する - テストが独立しており、任意の順序で実行できることを確認する

セキュリティに関する考慮事項

  • ツールの制限: サブエージェントは設定されたツールのみにアクセス可能
  • サンドボックス化: すべてのツール実行は、直接的なツール使用と同じセキュリティモデルに従う
  • 監査ログ: すべてのサブエージェントのアクションはリアルタイムで記録・可視化される
  • アクセス制御: プロジェクトレベルおよびユーザーレベルの分離により、適切な境界を提供
  • 機密情報: エージェント設定にシークレットや認証情報を含めないようにする
  • 本番環境: 本番環境と開発環境では別々のエージェントを使用することを検討
Last updated on