直接回答
成果物、調査課題、検証責任で分割できる作業だけを複数エージェントへ委任します。各エージェントの範囲と権限を限定し、書込状態を分離し、証拠を含む構造化引き継ぎを求め、一人の統合責任者が競合を解決して最終チェックを実行します。
重要な結論
- 曖昧な共同責任ではなく、独立成果物を委任します。
- 可能な限り一つのファイルや部品に一人の書込担当を置きます。
- 引き継ぎに出典、仮定、成果物、検証、リスクを含めます。
- 一人の統合責任者が結合 diff と最終チェックを確認します。
重要な事実
このガイドで解決できること
所有権、安全性、再現性を失わずに作業を並列化します。
検証範囲と制約
- 証拠の種類
- 公式ドキュメント仕様
- 検証範囲
- 分解、権限、成果物分離、引き継ぎ、統合、最終検証を対象にします。
- 制約と失効条件
- - 並列化が常に高速とは主張しません。
- - クライアントごとに編成機能が異なります。
- - 共有外部状態には個別の制御が必要です。
独立して受け入れ可能な成果だけを委任する
異なるモジュールのレビュー、別の公式資料の調査、独立アダプター、独立検証は並列化しやすい仕事です。同じファイルを繰り返し編集したり、未レビューの中間仮定へ依存したりする場合は分解できていません。
開始前に各割当の受け入れ条件と依存を記述します。境界を書けない場合は、設計が分かるまで順番に調査します。
所有権を決め、書込状態を分離する
ファイルやサブシステムごとに一人の書込担当を優先します。同時書込には別 worktree または branch を使い、配信資格情報、実行 hook を含む cache、可変の外部環境を意図せず共有しません。
読み取り専用レビューは同じ snapshot を見られますが、所見にパスと revision を付け、変更後も有効か判断できるようにします。
構造化した引き継ぎ契約を使う
目標、範囲、出典、仮定、成果物、実行コマンド、結果、残るリスク、次の行動を返します。「完了」は証拠ではなく、統合担当が会話全体なしで検証を再現できる必要があります。
- 開始 revision と担当パス
- 公式 URL またはリポジトリ証拠
- 変更ファイルと成果物
- 検証コマンドと観測結果
- 競合、制限、未決事項
一つの責任ある統合ゲートを通す
統合担当が割当との一致、重複編集、セキュリティ変更を確認し、結合後の状態でテストします。各エージェントが単独で通過しても、結合結果の正しさは証明できません。
一つの分岐が失敗したら増幅を止める
前提が無効、安全境界を越えた、baseline が変わった場合は依存作業を中止します。fan-out、リトライ、総実行量を制限し、中止分岐の所見は最終 revision で再確認するまで古い情報として扱います。
公式情報と検証範囲
本ガイドは公開されている公式ドキュメントを根拠にしています。コマンドや設定はクライアントのバージョンにより変わるため、実行前に参照元も確認してください。
技術検証方法を見る