Agent Orchestrator について
Agent Orchestrator は、複雑なタスクで専門エージェント、スキル、ツールを連携させるスキルです。作業の分割、並列・逐次実行や障害への対応、結果の統合と検証を行います。
主な機能
- 01タスクの分割と委任
- 02並列・逐次のエージェントワークフロー
- 03状況に応じた専門エージェント選択
- 04障害復旧と代替手段
- 05結果の統合と検証
活用シーン
- 01複雑なプロジェクトを専門家に分担
- 02独立したサブタスクの並列実行
- 03エージェントパイプラインで結果を受け渡し
- 04エージェントのタイムアウトやエラーへの対応
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ eddiebe147/ claude-settings --skill agent-orchestratorインストール後、Claude Code で/agent-orchestratorを入力して読み込まれたか確認します。
詳細
エージェントオーケストレーター
エージェントオーケストレーターのスキルは、分散した専門知識を活用することで効果が高まる複雑なタスクを達成するために、複数の専門 AI エージェント、スキル、ツールを連携させます。指揮者のように適切なエージェントへサブタスクを委任し、依存関係を管理し、結果を統合して、一貫性のある最終出力を確実に作成します。
このスキルは、利用可能なエージェント(汎用、operations-manager、専門スキル)の能力を把握し、最適なタスク分解を判断し、エージェント間の通信を管理し、失敗に対処して、多様な出力を統一された結果にまとめます。マルチエージェントの連携を効果的にするメタレイヤーです。
多様な専門知識が必要な複雑なプロジェクト、並列実行が効果的なタスク、または専門エージェントが汎用的なアプローチを上回るワークフローに、このスキルを使用してください。
コアワークフロー
ワークフロー 1:タスクを分解して委任する
- 複雑なタスクを分析します:
- 最終的な目標は何ですか?
- どのような要素で構成されていますか?
- どのような専門知識が必要ですか?
- 利用可能なエージェント/スキルに対応付けします:
- 関連する能力を持つエージェントはどれですか?
- 各エージェントの専門分野は何ですか?
- どのツール/MCP にアクセスできますか?
- タスクをサブタスクに分解します:
- 専門分野の境界に沿って分割します
- 依存関係を特定します
- 実行順序を決定します
- 適切なエージェントに委任します:
- 明確な指示を添えてサブタスクを割り当てます
- 必要なコンテキストを提供します
- 成功基準を設定します
- 出力形式を指定します
- 実行を監視します:
- 進捗を追跡します
- 阻害要因を特定します
- 失敗に対処します
- 結果を統合します:
- エージェントの出力を収集します
- 矛盾を解消します
- 一貫性のある全体にまとめます
- 最終結果を検証します
ワークフロー 2:エージェントを並列実行する
- 並列化できるサブタスクを特定します:
- どのタスクが独立していますか?
- 依存関係を共有しないタスクはどれですか?
- どのタスクを同時に実行できますか?
- 並列実行を準備します:
- サブタスクをエージェントに割り当てます
- 分離されたコンテキストを提供します
- タイムアウトの制限を設定します
- エージェントを並列に起動します:
- すべてを一斉に開始します
- 個別のコンテキストを維持します
- すべての実行を監視します
- 完了を調整します:
- すべての完了を待ちます
- 遅れているエージェントに対処します
- タイムアウトによる失敗を管理します
- 結果を集約します:
- すべての出力を収集します
- 関連する調査結果を統合します
- 不整合を解消します
- 最終出力をまとめます
ワークフロー 3:エージェントの逐次パイプライン
- パイプラインの流れを設計します:
- 依存関係に沿ってエージェントの順序を決めます
- 引き継ぎポイントを定義します
- データ変換を指定します
- パイプラインを順次実行します:
- エージェント 1:初期入力を処理 → 出力 A
- 出力 A を検証
- エージェント 2:出力 A を処理 → 出力 B
- 出力 B を検証
- エージェント N:出力 (N-1) を処理 → 最終出力
- エージェント間の状態を管理します:
- 関連データを次へ渡します
- 必要に応じてコンテキストを維持します
- 一時的な成果物を破棄します
- パイプラインの失敗に対処します:
- 失敗した段階を特定します
- 再試行するか、フォールバックを使用します
- 不正なデータを後続へ伝播させないでください
- エンドツーエンドの結果を検証します
ワークフロー 4:状況に応じてエージェントを選択する
- タスクの要件を動的に評価します:
- どのような能力が必要ですか?
- 複雑さのレベルはどの程度ですか?
- どのような制約がありますか?
- 最適なエージェントを選択します:
- 能力を要件に照らし合わせます
- エージェントの利用可能状況を考慮します
- 過去のパフォーマンスを考慮します
- 適切な場合は、汎用エージェントより専門エージェントを選びます
- コンテキストを添えて委任します:
- タスクに特化した指示を提供します
- 関連する背景情報を含めます
- 明確な期待値を設定します
- エージェントのパフォーマンスを評価します:
- 基準を満たしましたか?
- 品質は十分でしたか?
- 所要時間は許容範囲でしたか?
- 今後の選択に向けて学習します:
- どのエージェントが何に優れているかを記録します
- 失敗のパターンを記録します
- 選択ロジックを改善します
ワークフロー 5:エラーの復旧とフォールバック
- 検出:エージェントの失敗を検出します。
- タスクが完了していない
- 出力品質が不十分
- タイムアウトを超過した
- エラーが発生した
- 診断:失敗の原因を診断します。
- タスクが不明確でしたか?
- エージェントの選択が間違っていましたか?
- 入力の形式が不正でしたか?
- 依存関係を利用できませんでしたか?
- 試行:復旧を試みます。
- 再試行:同じエージェントで再試行します(一時的なエラーの場合)。
- 再試行:別のエージェントで再試行します(能力が適合しない場合)。
- 簡略化:タスクを簡略化して再試行します(複雑すぎる場合)。
- エスカレーション:人間に引き継ぎます(復旧できない場合)。
- 記録:失敗と復旧を記録します。
- 復旧できた場合はワークフローを続行します。
クイックリファレンス
| アクション | コマンド/トリガー |
|---|---|
| 複雑なタスクを委任する | 「[task] のためにエージェントをオーケストレーションする」 |
| エージェントを並列実行する | 「次のタスクを並列実行する:[tasks]」 |
| エージェントのパイプラインを作成する | 「パイプラインを作成する:[agent1] → [agent2] → [agent3]」 |
| 最適なエージェントを選ぶ | 「[task] を担当するのに最適なエージェントは?」 |
| ワークフローを調整する | 「エージェント間で [workflow] を調整する」 |
| エージェントの失敗に対処する | 「エージェント [X] が [task] で失敗したため、復旧する」 |
| エージェントの出力を統合する | 「[agents] の出力を統合する」 |
ベストプラクティス
-
タスクに専門知識を適合させる:専門的な作業には専門のエージェントを使用します。
- プロジェクトの調整には Operations Manager
- コンポーネントの設計には UI Builder
- スキーマ作業には Database Designer
- すべてに汎用エージェントを使わないでください。
-
明確なコンテキストを提供する:各エージェントが自分の役割を理解できるようにします。
- より大きな目標は何ですか?
- このエージェントの具体的な責任は何ですか?
- 期待される出力は何ですか?
- ワークフローの中でどのような役割を果たしますか?
-
依存関係を管理する:実行順序を明示します。
- エージェント B はエージェント A の出力を必要とします。
- エージェント C は A と B と並行して実行できます。
- エージェント D は B と C を待ちます。
-
引き継ぎを検証する:不適切なデータをエージェント間で渡さないようにします。
- 出力形式を確認する
- 完全性を検証する
- スキーマに照らして検証する
- 問題があればすぐに失敗として処理する
-
失敗に適切に対処する:エージェントは失敗することがあります。
- フォールバック用のエージェントを用意する
- 再試行ロジックを実装する
- 失敗を連鎖させない
- 事後分析のために記録する
-
コミュニケーションを最適化する:エージェント間のやり取りを最小限にします。
- 必要なデータだけを渡す
- 構造化形式を使用する
- 重複する情報を避ける
- 適切な場合は圧縮する
-
進捗を監視する:何が起きているか把握します。
- 稼働中のエージェントを追跡する
- ボトルネックを特定する
- 失敗を早期に検出する
- 状況を更新する
-
慎重に統合する:多様な出力を一貫性のある形で統合します。
- 矛盾を解消する
- 一貫性を保つ
- 重要な詳細を維持する
- 統一された説明を作成する
エージェントの能力マップ
利用可能なエージェント/スキル
| エージェント/スキル | 専門分野 | 最適な用途 | 避けるべき用途 |
|---|---|---|---|
| General-Purpose | 幅広いタスク | 簡単なタスク、一般的なコーディング | 複雑なオーケストレーション |
| Operations Manager | プロジェクトの調整 | ワークフロー、スケジュール、リソース | コードの作成 |
| UI Builder | フロントエンド設計 | コンポーネント、レイアウト、スタイル設定 | バックエンドロジック |
| Database Designer | スキーマ設計 | テーブル、リレーションシップ、RLS | フロントエンド作業 |
| API Designer | エンドポイント設計 | RESTful API、検証 | UI/UX |
| Testing QA | テスト作成 | E2E テスト、テスト計画 | 機能開発 |
| Performance Optimizer | パフォーマンス最適化 | メトリクス、キャッシュ、遅延読み込み | 初期開発 |
| Deployment Automation | CI/CD | Vercel、環境、パイプライン | 機能のコーディング |
| Prompt Engineer | AI 最適化 | プロンプトの改善、AI ワークフロー | AI 以外のタスク |
| Skill Creator | スキル開発 | 新しいスキルの構築 | 日常的なタスク |
| Workflow Designer | プロセス設計 | 複雑なワークフロー | 簡単なタスク |
| Chain Builder | プロンプトシーケンス | 複数ステップの AI タスク | 単一のプロンプト |
MCP/ツールへのアクセス
| エージェント | 利用可能な MCP/ツール |
|---|---|
| 汎用 | すべて(Playwright、Supabase、GitHub、Firecrawl、Memory) |
| 運用マネージャー | GitHub(PR、イシュー)、Memory(追跡) |
| UI ビルダー | Playwright(テスト)、Memory(設計上の決定) |
| データベース設計者 | Supabase(マイグレーション、クエリ)、Memory(スキーマ) |
| テスト QA | Playwright(E2E)、GitHub(テスト実行) |
オーケストレーションパターン
パターン 1:エキスパートパネル
Task → [Expert A, Expert B, Expert C] → Synthesize → Decision
使用する場面:同じ問題について多様な視点が必要な場合 例:アーキテクチャの決定 → [パフォーマンスの専門家、セキュリティの専門家、保守性の専門家] → 推奨案
パターン 2:組立ライン
Task → Agent A → Agent B → Agent C → Output
使用する場面:順次変換が必要な場合 例:設計 → 実装 → テスト → デプロイ
パターン 3:分割統治
Task → Split → [Agent 1: Part A, Agent 2: Part B, Agent N: Part N] → Merge → Output
使用する場面:大きなタスクを独立した部分に分割できる場合 例:複数ページのアプリ → [ページごとのエージェント] → 統合
パターン 4:スーパーバイザーとワーカー
Supervisor analyzes → Delegates to Workers → Workers execute → Supervisor integrates
使用する場面:中央での調整が必要な場合 例:プロジェクトマネージャー → [機能開発者] → 統合
パターン 5:協調的な改善
Agent A: Draft → Agent B: Critique → Agent A: Revise → Validate → Output
使用する場面:反復によって品質が向上する場合 例:ライター → レビュアー → ライター → 最終版
パターン 6:専門家への振り分け
Analyze task → Route to appropriate specialist → Specialist executes → Return
使用する場面:タスクの種類に応じて異なるエージェントが必要な場合 例:イシューのトリアージ → [バグは QA へ|機能は開発者へ|運用は DevOps へ]
委任テンプレート
標準的な委任
**Agent**: [Agent name]
**Task**: [Clear, specific task description]
**Context**: [Relevant background information]
**Inputs**: [Provided data/resources]
**Expected Output**: [Format and content requirements]
**Success Criteria**: [How to know it's done well]
**Constraints**: [Limitations or requirements]
**Deadline**: [If time-sensitive]
並列委任
**Parallel Execution**: [N agents]
**Agent 1**: [Agent name]
- Task: [Task 1]
- Output: [Output 1]
**Agent 2**: [Agent name]
- Task: [Task 2]
- Output: [Output 2]
**Integration**: [How to combine outputs]
パイプライン委任
**Pipeline**: [Agent A] → [Agent B] → [Agent C]
**Stage 1**: [Agent A]
- Input: [Initial data]
- Task: [Transform 1]
- Output: [Intermediate 1]
**Stage 2**: [Agent B]
- Input: [Intermediate 1]
- Task: [Transform 2]
- Output: [Intermediate 2]
**Stage 3**: [Agent C]
- Input: [Intermediate 2]
- Task: [Transform 3]
- Output: [Final output]
調整戦略
リアルタイム調整
- タイミング:実行中にエージェント同士がやり取りする必要がある場合
- 方法:共有コンテキスト、メッセージの受け渡し、状態の更新
- トレードオフ:複雑になりますが、柔軟性が高まります
バッチ調整
- タイミング:エージェントが独立して作業し、最後に統合する場合
- 方法:すべての出力を収集してから統合
- トレードオフ:シンプルですが、適応性は低くなります
階層的な調整
- タイミング:明確な権限構造がある場合
- 方法:スーパーバイザーが委任し、ワーカーが報告
- トレードオフ:明確ですが、ボトルネックになる可能性があります
ピアツーピア調整
- タイミング:エージェントが対等な立場で協力する場合
- 方法:共有ワークスペース、相互認識
- トレードオフ:柔軟ですが、明確なプロトコルが必要です
コンフリクトの解決
エージェントの出力が食い違う場合:
-
特定:コンフリクトを特定します。
- 何が一致していませんか?
- どのエージェント同士で意見が異なっていますか?
- 意見の相違はどのような性質ですか?
-
評価:情報源を評価します。
- この内容について、どのエージェントの権威がより高いですか?
- 確信度はどの程度ですか?
- その根拠は何ですか?
-
解決:戦略を用いて解決します。
- 権威:専門家を信頼する
- 投票:多数決で決める(複数のエージェントがいる場合)
- 統合:双方の最良の部分を組み合わせる
- エスカレーション:人間に判断を求める
-
記録:解決内容を記録します。
- どのようなコンフリクトがありましたか?
- どのように解決しましたか?
- なぜこの選択にしましたか?
パフォーマンスの最適化
オーバーヘッドの削減
- 単一のエージェントで十分な場合は、オーケストレーションを行わない
- 引き継ぎやデータの受け渡しを最小限にする
- 独立したタスクには並列実行を使用する
- 繰り返し行う計算をキャッシュする
負荷分散
- エージェント間で作業を均等に分配する
- 単一のエージェントにボトルネックが生じないようにする
- エージェントの処理能力と速度を考慮する
- バースト性のあるワークロードにはキューを使用する
障害の分離
- 1 つのエージェントの障害でワークフロー全体が停止しないようにする
- 信頼性の低いエージェントにはサーキットブレーカーを使用する
- フォールバックの選択肢を用意する
- タイムアウトの上限を設定する
モニタリングと可観測性
以下のメトリクスを追跡します。
- エージェントの稼働率:各エージェントはどれくらい稼働していますか?
- タスクの完了時間:エージェントごとにどれくらい時間がかかりますか?
- 成功率:どのエージェントが成功し、どのエージェントが失敗しますか?
- 引き継ぎの効率:移行はどれくらいスムーズですか?
- 統合品質:出力はどれくらいうまく組み合わされていますか?
- エラー率:どこで障害が発生していますか?
- コスト:エージェントごとのトークン使用量
オーケストレーションの例
機能開発ワークフロー
**Orchestrator**: Coordinate feature development
1. **Requirements Analysis** (Operations Manager)
- Clarify requirements
- Define scope
- Identify constraints
2. **Parallel Design Phase**
- **UI Builder**: Design components
- **Database Designer**: Design schema
- **API Designer**: Design endpoints
3. **Integration Review** (Orchestrator)
- Ensure designs are compatible
- Resolve conflicts
- Approve for implementation
4. **Implementation** (General-Purpose)
- Build based on approved designs
5. **Quality Assurance** (Testing QA)
- Generate E2E tests
- Run test suite
- Report issues
6. **Fix Issues** (General-Purpose)
- Address failing tests
7. **Deployment** (Deployment Automation)
- Deploy to staging
- Verify deployment
- Deploy to production
コンテンツ作成パイプライン
**Orchestrator**: Create technical blog post
1. **Research** (General-Purpose + Firecrawl)
- Gather sources
- Extract key information
2. **Parallel Analysis**
- **Prompt Engineer**: Analyze for clarity
- **Workflow Designer**: Identify structure
- **Output Formatter**: Determine format
3. **Draft** (General-Purpose)
- Write based on research and analysis
4. **Review & Edit** (Prompt Engineer)
- Review for quality
- Suggest improvements
5. **Revise** (General-Purpose)
- Apply feedback
6. **Format** (Output Formatter)
- Format for target platform
7. **Generate Metadata** (General-Purpose)
- SEO metadata
- Social snippets