/orchestrate

description: 複雑な依頼を自動分析し、適切なエージェントチームで実行・検証・再試行を行う高度な自動化コマンド
allowed-tools: Read, Glob, Grep, Task, TeamCreate, TeamDelete, TaskCreate, TaskUpdate, TaskList, TaskGet, SendMessage, AskUserQuestion
argument-hint: "実施したい依頼内容(例: ログイン機能のテストを追加してバグを修正)"

このコマンドは、ユーザからの複雑な依頼を自動的に分析し、必要な作業をステップに分割し、適切なエージェントチームを編成して実行します。各ステップの成功条件を自動判定し、失敗時は原因を分析して最大5回まで自動再試行を行います。

context

user_request: {{args}} (ユーザからの依頼内容)
team_name: orchestrate-{{timestamp}} (チーム名)
max_retry_per_step: 5 (1ステップあたりの最大再試行回数)
steps: [] (実行ステップのリスト)
current_step_index: 0 (現在実行中のステップ番号)

steps

step1: 依頼内容の分析とプランニング

ユーザの依頼内容を詳細に分析し、以下を決定する:

1. **作業の洗い出し**: 依頼を達成するために必要な具体的な作業をリストアップ 2. **ステップ分割の判定**:

• シンプルな依頼(1つの明確な作業): 1ステップで実行
• 中規模の依頼(2-3の関連作業): 2-3ステップに分割
• 大規模な依頼(4つ以上の作業): 論理的なまとまりでステップに分割

3. **各ステップの定義**:

• ステップ名: 何をするステップか
• 作業内容: 具体的に何を実行するか
• 成功条件: どうなれば成功か(自動判定可能な条件)
• 推奨エージェント: どのエージェントタイプが適切か

**ステップ分割ルール**に従って分析を行い、結果を構造化してメモする。

step2: チームとタスクリストの準備

1. **チーム作成**:

• `TeamCreate` でオーケストレーションチームを作成
• チーム名: `orchestrate-{現在時刻のタイムスタンプ}`

2. **タスク作成**:

• step1で定義した各ステップに対して `TaskCreate` でタスクを作成
• subject: ステップ名
• description: 作業内容 + 成功条件
• activeForm: 実行中の表示メッセージ

3. **依存関係の設定**:

• 前のステップに依存する場合は `TaskUpdate` で blockedBy を設定

step3: ステップの順次実行

各ステップを順番に実行する(並列実行は行わない):

1. **タスクの取得**: `TaskGet` で次の実行対象タスクを取得 2. **タスクを進行中に更新**: `TaskUpdate` で status を `in_progress` に 3. **エージェント選定**: **エージェント選定ルール**に従って最適なエージェントタイプを選択 4. **エージェント起動**: `Task` ツールで選定したエージェントを起動し、作業を依頼

• prompt: 作業内容を明確に指示 + 成功条件を伝える
• team_name: 作成したチーム名
• name: わかりやすいエージェント名(例: `step1-explorer`, `step2-implementer`)

5. **実行待機**: エージェントからの完了報告を待つ

step4: 結果の検証と判定

エージェントの実行結果を検証する:

1. **成功条件の確認**: **成功条件判定ルール**に従って判定

• エージェントの報告内容を確認
• 必要に応じてファイルの状態、テスト結果等を確認

2. **判定結果の処理**:

• **成功の場合**:
• `TaskUpdate` で status を `completed` に更新
• step3に戻り次のステップを実行(全ステップ完了ならstep5へ)
• **失敗の場合**:
• 再試行カウンタをチェック
• 最大再試行回数未満なら step5(再試行)へ
• 最大再試行回数到達なら step6(エスカレーション)へ

step5: 失敗時の原因分析と再試行

**再試行ルール**に従って再試行を実施:

1. **原因分析**:

• エージェントの実行結果とエラーログを分析
• 何が原因で成功条件を満たせなかったかを特定
• 改善方法を検討(例: 指示の明確化、別のエージェントタイプの選択、前提条件の修正)

2. **改善策の適用**:

• エージェントへの指示を改善
• 必要に応じてエージェントタイプを変更
• 前提条件が不足していれば追加の準備作業を実施

3. **再実行**:

• 改善した内容で `Task` ツールを再実行
• 再試行カウンタをインクリメント

4. **step4に戻って再検証**

step6: 最大再試行到達時のエスカレーション

5回の再試行でも成功しなかった場合:

1. **状況の整理**:

• 失敗したステップの内容
• 試行した方法と結果
• エラーの詳細

2. **ユーザへの報告**:

• 現在の状況を簡潔に報告
• `AskUserQuestion` で次のアクションを確認:
• 「このステップをスキップして次へ進む」
• 「手動で介入して修正する(一時中断)」
• 「全体を中止する」

3. **ユーザの選択に従って処理**:

• スキップ: タスクを `completed` にして次のステップへ(step3)
• 手動介入: orchestrate を一時停止し、ユーザの作業完了後に再開
• 中止: step7(クリーンアップ)へ

step7: 完了報告とクリーンアップ

全ステップが完了したら:

1. **完了報告**:

• 実行した全ステップの概要
• 各ステップの結果(成功/スキップ/失敗)
• 再試行が発生したステップとその回数
• 最終的な成果物や変更内容

2. **チームのシャットダウン**:

• 各エージェントに `SendMessage` で shutdown_request を送信
• エージェントからの shutdown_response を待つ

3. **クリーンアップ**:

• `TeamDelete` でチームを削除
• タスクリストも自動削除される

rule

エージェント選定ルール

作業内容に応じて最適なエージェントタイプを選択する:

general-purpose エージェント

• **用途**: 汎用的な実装作業、複雑な多段階タスク
• **適用例**:
• コードの実装・修正
• テストコードの作成
• バグ修正
• 機能追加
• 複数ファイルにまたがる変更

Explore エージェント

• **用途**: コードベースの調査・分析
• **適用例**:
• 既存コードの理解
• バグの原因調査
• パターンの検索
• アーキテクチャの把握
• 依存関係の分析

Plan エージェント

• **用途**: 実装計画の立案
• **適用例**:
• 大規模な実装の設計
• アーキテクチャ決定
• リファクタリング計画
• マイグレーション計画

Bash エージェント

• **用途**: コマンドライン操作、git操作、外部ツール実行
• **適用例**:
• テストの実行
• ビルドの実行
• git操作(ブランチ作成、コミット等)
• パッケージのインストール
• 環境設定

選定の優先順位

1. 調査が必要 → Explore 2. 計画が必要 → Plan 3. コマンド実行のみ → Bash 4. コード実装 → general-purpose 5. 迷ったら → general-purpose

成功条件判定ルール

各ステップの成功条件を自動判定する基準:

ファイル操作系

• ファイルが作成/更新された
• 想定される内容が含まれている
• 構文エラーがない

テスト系

• テストが実行された
• テストがパスした
• カバレッジが適切

調査系

• 必要な情報が得られた
• 原因が特定された
• 次のステップに必要な情報が揃った

実装系

• コードが書かれた
• エラーなくビルド/実行できる
• 要求仕様を満たしている

判定方法

1. エージェントの報告内容を確認 2. 必要に応じて `Read` でファイルを確認 3. 必要に応じて `Bash` でテストやビルドを実行 4. 成功条件に照らして合格/不合格を判断

**注意**: 完璧を求めすぎない。80%の品質で次に進めるなら進む。

再試行ルール

失敗時の再試行は以下の方針で行う:

1回目の失敗

• **原因**: 指示が不明瞭、情報不足の可能性
• **対策**:
• 指示をより具体的に修正
• 必要な前提情報を追加
• 成功条件を明確化

2回目の失敗

• **原因**: エージェントタイプが不適切の可能性
• **対策**:
• 別のエージェントタイプを試す
• 作業を細分化して複数エージェントに分割

3回目の失敗

• **原因**: 前提条件が満たされていない可能性
• **対策**:
• 依存する作業が完了しているか確認
• 必要なファイルや設定が存在するか確認
• 不足があれば準備作業を追加実行

4回目の失敗

• **原因**: アプローチ自体が間違っている可能性
• **対策**:
• 根本的に異なるアプローチを検討
• Explore エージェントで再調査
• Plan エージェントで計画を見直し

5回目の失敗

• **原因**: 自動化が困難なタスクの可能性
• **対策**:
• 最後の試行として、最も確実と思われる方法を実行
• それでも失敗したら step6 でユーザにエスカレーション

再試行の間隔

• 即座に再試行(待機時間なし)
• ただし、同じエラーを繰り返さないように改善策を適用してから実行

ステップ分割ルール

依頼内容に応じて適切にステップを分割する:

シンプルな依頼(1ステップ)

• 単一の明確な作業
• 例: 「特定のバグを修正」「テストを1つ追加」「ファイルを整形」

中規模の依頼(2-3ステップ)

• 関連する複数の作業
• 例: 「機能を追加してテストを書く」
• Step1: 機能実装
• Step2: テスト作成

大規模な依頼(4ステップ以上)

• 複雑で多段階の作業
• 例: 「ログイン機能のテストを追加してバグを修正」
• Step1: 既存コードの調査(Explore)
• Step2: バグの原因特定と修正(general-purpose)
• Step3: テストコード作成(general-purpose)
• Step4: テスト実行と検証(Bash)

分割の基準

• **依存関係**: 前の作業の結果が次の作業に必要な場合は別ステップに
• **作業の性質**: 調査→計画→実装→検証のように性質が異なる場合は別ステップに
• **検証ポイント**: 途中で検証したい場合は別ステップに
• **エージェントタイプ**: 異なるエージェントが適切な場合は別ステップに

分割しすぎない

• 過度な分割は管理コストが増える
• 密接に関連する作業は1ステップにまとめる
• 目安: 1ステップ = 5-30分で完了する作業量

info

エージェントタイプ一覧

<agent_types_reference> 利用可能なエージェントタイプとその特徴:

**general-purpose**

• フルアクセス: Read, Write, Edit, Glob, Grep, Bash, Task など全ツール
• 汎用的な実装・修正作業に最適
• 迷ったらこれを選択

**Explore**

• 読み取り専用: Glob, Grep, Read, WebFetch, WebSearch
• コードベースの調査・分析専用
• ファイル編集不可

**Plan**

• 読み取り専用: Glob, Grep, Read, WebFetch, WebSearch
• 実装計画の立案専用
• ファイル編集不可

**Bash**

• コマンド実行専用: Bash のみ
• git操作、テスト実行、ビルドなど
• ファイル編集は専用ツールでは不可(sedなどは使える)

</agent_types_reference>

成功条件の例

<success_criteria_examples> 各種作業タイプにおける成功条件の具体例:

**コード実装**

• 指定された機能が実装されている
• 構文エラーがない
• 既存のコードスタイルに従っている

**バグ修正**

• 報告されたバグが再現しない
• 関連するテストがパスする
• 副作用が発生していない

**テスト作成**

• テストケースが作