dispatching-parallel-agents

概要

このスキルでできること

dispatching-parallel-agents は、複数の独立したタスクをそれぞれ専用のエージェントに委任し、並列に実行するためのパターンを示します。各エージェントは、自分専用に絞り込まれたコンテキスト・指示・ゴールだけを受け取り、あなたのメインセッションの履歴や状態は引き継ぎません。

根本的な考え方はシンプルです。互いに関係のない複数の問題に直面したとき、1 つのエージェントにすべてを押し込まない、ということです。代わりに次のようにします。

• 独立した問題領域を見極める
• 領域ごとに 1 つずつエージェントを立ち上げる
• 各エージェントには必要なコンテキストだけを与える
• あなたは全体を調整しつつ、それぞれを同時並行で動かす

このオーケストレーションパターンにより、特に無関係なテスト失敗を調査するとき、別々のサブシステムをデバッグするとき、あるいは異なる解法候補を並行検討するときに、経過時間を短縮しながらより多くの作業をこなせるようになります。

想定しているユーザー

このスキルは次のような方に向いています。

• マルチエージェントシステム やエージェントワークフローを構築・運用している
• 大規模なコードベースに対して、AI を使った デバッグ・テスト・解析 を行っている
• 複数の障害やインシデントを 並列にトリアージ する必要がある
• コンテキストの分離 を重視し、無関係な履歴がタスク間で漏洩するのを防ぎたい

すでにエージェントを使って複雑な作業をしている開発者、SRE、QA エンジニア、ワークフローデザイナーが、「複数の独立したタスクを同時に扱うための、より体系化された再現性の高いパターン」を求めているケースに特に有用です。

解決できる課題

dispatching-parallel-agents が真価を発揮するのは、状態を共有せず、互いの結果に依存しない 2 つ以上のタスク があるときです。例えば次のようなケースです。

• 別々のサブシステムに影響する複数のテストファイルが失敗している
• 異なるユーザー報告から上がってきた、関連性のないバグがいくつもある
• コードベースに対する並列解析（例：片方はセキュリティスキャン、もう片方はパフォーマンスレビュー）

従来のように：

• 各問題を 順番に 調査する、あるいは
• 1 つのエージェントにすべての失敗をまとめて押し付ける

のではなく、次のようにします。

• 問題ごとに別々のエージェントを作る
• 各エージェントに、その問題に必要なコンテキストだけを厳選して渡す
• エージェントを並列に動かし、最後に結果を統合する

その結果、エージェント 1 つあたりの集中力が高まり、コンテキストのノイズが減り、エンドツーエンドの調査がより速く進むようになります。

このスキルが向かないケース

dispatching-parallel-agents が 適さない のは次のような場合です。

• タスク間で常に一貫していなければならない 重要な状態を共有 している
• 作業が 厳密な順序 で進む必要がある（ステップ B がステップ A の結果に依存している）
• 変化していくコンテキストを、すべてのエージェントがリアルタイムに共有する必要がある

このようなときは、コンテキストを丁寧にメンテナンスした単一エージェント、または並列ではない 逐次ワークフロー のパターンを選ぶ方が適しています。

使い方

1. スキルをインストールする

obra/superpowers リポジトリから dispatching-parallel-agents スキルを追加するには、次のコマンドを実行します。

npx skills add https://github.com/obra/superpowers --skill dispatching-parallel-agents

このコマンドにより、スキル定義と関連する資料が次の場所から取得されます。

• Repository: https://github.com/obra/superpowers
• Skill path: skills/dispatching-parallel-agents

インストール後、あなたの環境の skills ディレクトリ配下（具体的な場所は skills runner やツールによって異なります）にスキルファイルが配置されていることを確認してください。

2. コアとなるパターンを理解する

dispatching-parallel-agents の中心にあるのは、「いつエージェントを並列実行に振り分けるか」を判断するための意思決定パターンです。上流のスキルでは、これを次のようなシンプルなフローで説明しています。

• Multiple failures?
  • いいえの場合、おそらくエージェントは 1 つで十分です。
• Are they independent?
  • no – related の場合は、全体像を把握できるように single agent を使います。
  • yes の場合は次へ進みます。
• Can they work in parallel?（状態を共有していないか、直列化すべき共有リソースがないか）
  • yes の場合は parallel dispatch を使います。
  • no – shared state の場合は sequential agents を使います。

複数のエージェントを立ち上げるか、単一のエージェントに任せるかを決めるたびに、このロジックを当てはめるイメージです。

3. まずは SKILL ファイルから読む

インストールが終わったら、次のファイルを開きます。

• SKILL.md

このファイルには、dispatching-parallel-agents パターンの正式な説明として、以下がまとめられています。

• このスキルを使うべき状況
• コンセプトの概要
• 問題領域ごとにエージェントを構成する際の指針

まずは最初から最後まで一通り読み、スキルの想定する使い方をつかんでください。これが主なリファレンスになります。

4. 独立した問題領域を切り分ける

エージェントをディスパッチする前に、タスクを明確に切り分けます。

1. 現在抱えている課題やゴールをすべて洗い出します（例：失敗しているテスト、バグ報告、解析タスクなど）。
2. それらを、状態やロジックが重ならない ドメイン ごとにグルーピングします。例：
   • Domain A: ui/ コンポーネントのフロントエンドテスト失敗
   • Domain B: api/ サービスのバックエンドエラー
   • Domain C: jobs/ scheduler で起きる間欠的な失敗
3. ドメインが本当に独立しているかを検証します。
   • 別々のコードパスやサブシステムである
   • 共有の mutable state や、密結合したロジックがない

独立性に確信が持ててから、並列実行に移るようにします。

5. ドメインごとに 1 エージェント＋専用コンテキストを用意する

独立した各ドメインについて、次のように進めます。

1. 新しいエージェントを作成 します（あなたのフレームワークにおける表現方法に従って、新しい agent config や新しい conversation/session を作るなど）。
2. メインセッションのコンテキストを再利用しないでください。 その代わりに、明示的に次のものを渡します。
   • 関連するファイル、ログ、設定スニペット
   • そのドメインに固有の簡潔な問題文
   • そのドメイン特有の制約やゴール
3. プロンプトはできるだけフォーカスさせます。例えば：

“You are an agent focused only on debugging front-end tests under ui/. Ignore other systems. Here are the failures and relevant files…”

このスキルのガイドラインでは、エージェントが あなたのセッションのコンテキストや履歴を絶対に継承しない ことを強調しています。これにより、エージェントはタスクに集中し、調査対象同士の「コンテキストの混線」を防げます。

6. エージェントを並列実行し、結果を調整する

ドメイン別のエージェントを用意したら、次のステップに進みます。

1. オーケストレーターやスクリプトを使って、エージェントを並列にディスパッチ します。
2. 各エージェントが、明確な中間成果（疑われる根本原因、パッチ案、追加で必要な質問のリストなど）に到達するまで独立して作業させます。
3. コーディネーター（人間または監督役のエージェント）として、次を行います。
   • すべてのエージェントから出力を回収する
   • それぞれの結果を比較・検証・統合する
   • どの提案を実際に採用するかを決定する

エージェントを実際に並列実行する役割は、（このスキルには含まれていない）オーケストレーションレイヤー側にあります。このスキルが扱うのは、特定のランタイムではなく、「どのような状況で・どのように」並列化を構成するか、という設計パターンです。

7. 途中でタスクの関連性が見つかったら調整する

調査の途中で、「独立している」と思っていた 2 つの問題が実はつながっていた、ということもあります。

• 共通の根本原因
• 同じ設定ミス
• システム間の見えにくい結合

このような場合は次のように方針転換します。

• それらを別ドメインとして扱うことをやめる
• コンテキストを single agent または新しい共有セッションに統合する
• そのエージェントに、統合された問題空間をまとめて考えさせる

dispatching-parallel-agents パターンは意図的に柔軟に設計されています。安全な範囲では並列化を促しつつ、依存関係が見つかったタイミングで 1 つのコンテキストに戻す判断も推奨しています。

8. 自分のスタックにパターンを適用する

リポジトリ自体は概念的なパターンにフォーカスしていますが、実装先の環境は問いません。例えば次のように使えます。

• Agent frameworks: それぞれ別のメモリ／コンテキストストアを持つ複数のエージェントを立ち上げる
• Custom scripts: ドメインごとに異なる prompts や入力バンドルを使い、LLM provider を直接呼び出す
• CI/CD や自動化パイプライン: ドメイン専用のエージェントに駆動させるジョブやステージを、並列ジョブとしてトリガーする

重要なのはツールそのものではなく、次のような「運用の discipline（規律）」です。

• 明示的なドメイン境界
• エージェントごとに孤立したコンテキスト
• 結果をきちんと統合・整理するコーディネーション

FAQ

実務的に見ると、dispatching-parallel-agents とは何ですか？

dispatching-parallel-agents は、マルチエージェントワークフローをどう構成するかを教えるスキルです。独立したタスクごとに専用のエージェント・コンテキスト・指示を用意し、タスクが互いに無関係で状態を共有しない場合は、それらを並列で動かせるようにします。1 つの万能エージェントにすべてを任せるのではなく、複数の特化エージェントを立ち上げて並列処理する考え方です。

dispatching-parallel-agents はどんなときに使うべきですか？

このスキルが有効なのは、次の条件を満たす 2 つ以上の独立したタスク がある場合です。

• 互いの出力に依存していない
• 共有・変更可能な状態を必要としない
• 同時に実行しても安全である

典型的なユースケースとしては、無関係なテスト失敗が複数あるケース、別々のバグ報告への対応、異なるサブシステムに対する独立した解析などが挙げられます。

どんなケースではこのパターンを避けるべきですか？

次のような場合は、dispatching-parallel-agents を使うべきではありません。

• タスク間で同期を保つべき重要な状態を共有している
• ワークフロー自体が本質的に逐次的であり、後工程が前工程の結果に依存している
• タスク全体を通して、1 本の連続したストーリーや履歴を維持する必要がある

こうしたシナリオでは、単一エージェント、もしくはきちんと順序づけされたマルチステップワークフローを選び、並列ディスパッチは避けるべきです。

dispatching-parallel-agents のインストール方法を教えてください。

obra/superpowers リポジトリから次のコマンドでスキルをインストールします。

npx skills add https://github.com/obra/superpowers --skill dispatching-parallel-agents

インストール後、dispatching-parallel-agents ディレクトリ内の SKILL.md を開き、コンセプトガイドの全体像を読み込んでください。

このスキルには実行可能なコードが含まれますか？ それともガイドだけですか？

上流のスキルは、主に SKILL.md にまとめられた 概念的・説明的なガイド です。並列エージェントをディスパッチするためのパターンや意思決定ロジックを説明しており、具体的な実行はあなたが利用しているエージェントフレームワークやスクリプト、オーケストレーションツールの上で行う想定になっています。

複数のテスト失敗やバグ対応にどう役立ちますか？

長いリストの無関係な失敗を 1 つのエージェントに流し込む代わりに、dispatching-parallel-agents は次のような進め方を提案します。

• 失敗をサブシステムやドメインごとにグルーピングする
• 各グループ専用に、関連するテスト出力とコードを含んだエージェントを作る
• それらのエージェントを並列実行する

これにより、各エージェントに渡る情報のノイズが減り、全体としての診断スピードを高めることができます。

他のワークフロー／オーケストレーション系スキルと組み合わせられますか？

はい。dispatching-parallel-agents は、他の agent-orchestration や workflow-automation パターンと非常に相性が良いスキルです。例えば、ドメイン内の逐次ステップを管理する別スキルと組み合わせ、その上位レイヤーとして dispatching-parallel-agents を使い、複数ドメインを並列に複数エージェントへ振り分けるといった構成も可能です。

インストール後、最初にどのファイルを読むべきですか？

まず次のファイルから始めてください。

• SKILL.md – dispatching-parallel-agents パターンのメイン解説

このファイルを、並列ディスパッチのタイミングやコンテキストの構成方法を判断するうえでの基本リファレンスとして使ってください。そのうえで、あなたのコードベース、CI パイプライン、エージェントフレームワークに合わせて具体的に適用していきましょう。