parallel-execution

並列実行

概要

複数の独立したサブシステムで別々の障害が発生している場合、ひとつずつ対処すると時間がかかります。それぞれの調査は独立しており、同時に進められます。

基本原則： 独立した問題領域ごとにエージェントを割り当てます。並行して作業を進めてもらいます。

最優先事項

独立性を確認せずに並行して作業を割り当てないでください

例外はありません。回避策もありません。近道もありません。

使用するタイミング

digraph dispatch_decision {
    "Multiple problems?" [shape=diamond];
    "Are they isolated?" [shape=diamond];
    "Single agent handles all" [shape=box];
    "One agent per domain" [shape=box];
    "Can they run concurrently?" [shape=diamond];
    "Sequential agents" [shape=box];
    "Parallel dispatch" [shape=box];

    "Multiple problems?" -> "Are they isolated?" [label="yes"];
    "Are they isolated?" -> "Single agent handles all" [label="no - coupled"];
    "Are they isolated?" -> "Can they run concurrently?" [label="yes"];
    "Can they run concurrently?" -> "Parallel dispatch" [label="yes"];
    "Can they run concurrently?" -> "Sequential agents" [label="no - shared state"];
}

適しているケース：

• 異なる理由で3つ以上のテストファイルが失敗している
• 複数のサブシステムがそれぞれ独立して壊れている
• 他の問題についての知識がなくても、各問題を理解できる
• 作業項目間で共有された可変状態がない

適していないケース：

• 障害が関連している（一方を解決すると他方も解決する可能性がある）
• システム全体を包括的に把握する必要がある
• エージェント同士の作業が干渉する可能性がある

進め方

1. 独立した領域を整理する

障害を根本原因の領域ごとに分類します。

• Module X のテスト：権限検証フロー
• Module Y のテスト：キューの排出動作
• Module Z のテスト：キャンセル処理

各領域は独立しています。権限の修正はキャンセルのテストには影響しません。

2. エージェント向けの簡潔な指示を作成する

各エージェントに次の内容を伝えます。

• 範囲の明確化： 1つのテストファイルまたはサブシステム
• 具体的な目標： 対象のテストをすべて成功させる
• 制約： 担当範囲外のコードを変更しない
• 成果物： 根本原因と実施した変更の概要

3. 並行して開始する

// Dispatch parallel agents using the Agent tool in Claude Code
Agent("Fix permission-validation.test.ts failures")
Agent("Fix queue-drain-behavior.test.ts failures")
Agent("Fix cancellation-handling.test.ts failures")
// All three execute at the same time

4. 結果を整理して検証する

エージェントの作業が完了したら、次のことを行います。

• 各エージェントの概要を確認する
• 変更が重複していないことを確認する
• テストスイート全体を実行する
• すべての結果を統合する

エージェントへの指示の構成

効果的な指示には、次の特長があります。

1. 範囲が狭い — 問題領域が明確に1つに絞られている
2. 自己完結している — 問題を理解するために必要な情報がすべて含まれている
3. 出力が指定されている — 何を報告すればよいかが明確である

Resolve the 3 failing tests in src/workers/queue-drain.test.ts:

1. "should drain remaining items on shutdown" - expects empty queue, finds 2 items
2. "should handle mixed priorities during drain" - high-priority item processed last
3. "should report drain metrics accurately" - expects 3 metrics but receives 0

These stem from async drain ordering. Your assignment:

1. Read the test file and understand the intended behavior
2. Determine root cause - ordering bug or stale test assumptions?
3. Fix by:
   - Implementing deterministic drain ordering
   - Correcting production bugs if found
   - Updating test expectations if behavior legitimately changed

Do NOT just add delays or increase timeouts - identify the underlying issue.

Return: Root cause analysis and description of changes made.

よくある落とし穴

範囲が広すぎる： 「すべてのテストを修正してください」 — エージェントの焦点が定まりません
焦点を絞る： 「queue-drain.test.ts を修正してください」 — 範囲が限定されています

コンテキストがない： 「順序の不具合を修正してください」 — エージェントはどこから始めればよいかわかりません
コンテキストを示す： エラーメッセージと失敗したテスト名を貼り付けます

制約がない： エージェントが無関係なコードを再構成する可能性があります
制約を設ける： 「src/workers/ の外にある本番コードは変更しないでください」

出力の依頼が曖昧： 「修正してください」 — 何が変わったのか把握できません
出力の依頼を具体化する： 「根本原因の概要と、変更したファイルの一覧を返してください」

思考の落とし穴

正当化	真実
「おそらく十分に独立している」	独立性を明示的に確認しないと、エージェント同士が衝突します。
「あとで競合を整理すればよい」	並行して作業するエージェント間のマージ競合は、順番に進める場合より解決が困難です。
「エージェントが多いほど納品が早い」	エージェントが共有ファイルを編集すると、作業が無駄になり、マージも壊れます。
「範囲は自明だ」	曖昧な指示からは曖昧な成果しか得られません。範囲、制約、出力を指定してください。
「1つのエージェントですべて対応できる」	範囲が広すぎると、エージェントは混乱します。領域ごとに分けてください。

使用しないタイミング

関連する障害： ひとつを解決すると他の修正にもつながる可能性があります。まず包括的に調査してください
包括的な理解が必要： 全体像を把握しなければ理解できません
探索的なデバッグ： 問題の範囲がわかっていません
リソースの共有： 同じファイル、データベース、サービスを使うため、エージェント同士が競合します

実例

状況： 大規模なリファクタリング後、3つのファイルで8件のテストが失敗

失敗：

• permission-validation.test.ts：3件の失敗（認証トークンの問題）
• queue-drain-behavior.test.ts：3件の失敗（順序に関するバグ）
• cancellation-handling.test.ts：2件の失敗（クリーンアップが不完全）

判断： ドメインは分離されています。認証の検証、キューの処理、キャンセルのロジックは互いに無関係です。

割り当て：

Agent 1 -> Fix permission-validation.test.ts
Agent 2 -> Fix queue-drain-behavior.test.ts
Agent 3 -> Fix cancellation-handling.test.ts

結果：

• エージェント1：ハードコードされたトークンを動的なフィクスチャに置き換え
• エージェント2：優先度フィールドを考慮するよう、キューの処理順を修正
• エージェント3：キャンセル状態が部分的な場合のクリーンアップフックを追加

調整： すべての修正が別々のファイルに適用され、競合はゼロで、テストスイート全体がすべて成功

価値： 3つの問題を順番にではなく、同時に解決

利点

1. 並行性 — 複数の調査を一度に進められます
2. 集中 — 各エージェントが小さなコンテキストを扱います
3. 相互非干渉 — エージェント同士の作業を妨げません
4. スループット — 1つの問題を解決する時間でN個の問題を解決します

割り当て後の確認

エージェントから結果が返されたら：

1. 各サマリーを確認する — 何が、なぜ変更されたのかを理解します
2. 重複を検出する — エージェントが同じコードに手を加えていないか確認します
3. テストスイート全体を実行する — すべての修正が共存できることを確認します
4. スポットチェックする — エージェントが体系的なエラーを持ち込む可能性があります
5. 仕上げる — 必須サブスキル：godmode:merge-protocol を使って変更を反映します

ガードレール

禁止事項：

• タスクが分離されていることを確認せずに、エージェントを並行して割り当てること
• エージェントが同じファイルを同時に変更することを許可すること
• エージェントのサマリーを確認せずに統合すること
• 調査目的の診断に並列割り当てを使うこと
• スコープ、境界、成果物を定めずに割り当てること

必須事項：

• 割り当て前に分離を確認します
• 各エージェントに、範囲を絞った明確なスコープを指定します
• エージェントへの指示にエラーメッセージとテスト名を含めます
• 統合前にすべてのエージェントのサマリーを確認します
• すべての変更を統合した後、テストスイート全体を実行します
• エージェントの成果物間に競合がないか確認します

関連項目

godmode:team-orchestration：

• 並列実行は、チームベースの作業の基本パターンです
• エージェント間に部分的な依存関係がある場合は、チームオーケストレーションを使います

godmode:delegated-execution：

• 開発計画内の独立したタスクに、エージェントを並行して起動します
• 各エージェントが計画内の1つのタスクを担当します

godmode:agent-messaging：

• 並行して割り当てられたエージェントは、エージェント間の通信を必要としないようにします
• 通信が必要な場合は、並列で割り当てるには十分に分離されていません