# 作業を複数エージェントに分けて本当に得なのはいつか

Canonical URL: https://bestskillsforclaude.com/ja/skills/subagent-driven-development
Language: ja
Skill: subagent-driven-development
Publisher: Jesse Vincent (obra) (https://github.com/obra)
Source: https://github.com/obra/superpowers
License as stated by the publisher: MIT
Runtime: Claude Code and other supported coding agents
Category: 計画と協働
Last reviewed: 2026-08-05

分割された部分が本当に独立しているときで、それ以外ではほぼ得になりません。

## Short answer
subagent-driven-development スキルは、複数のエージェントが衝突せず同時に動けるように作業を構造化します。別々のモジュールや並行調査のように部分が本当に独立していれば効果があり、そうでなければマージの苦痛と矛盾した判断を生みます。

Best for: 幅があり独立した作業。並行調査、モジュール単位の変更、大規模で機械的な一括処理。
Skip it if: 部分が状態やインターフェース、まだ決まっていない設計判断を共有している場合。

## What to remember
- 独立性は最適化の細部ではなく前提条件です。
- 計画前に分割すると、同じ誤解が並列に複製されます。
- 本当のコストはマージで、支払うのはエージェントではなくあなたです。
- 調査やレビューのような読み取り専用の並列化が、最も安全で確実な使い方です。

## 実務で何が変わるか
並列エージェントは分かりやすい理由で魅力的で、分かりにくい理由で危険です。各自が小さな設計判断を積み重ね、それを後から調整するものは、あなた以外に存在しません。
確実なのは、読み取りと収集で広げ、判断は 1 人の書き手に集約する形です。調査、監査、レビューはきれいに並列化します。インターフェース設計はしません。

## 期待に届かない点
共有ファイルは並列性を衝突解決に変えます。複数が書き込む時点で worktree のような隔離が要る理由です。
調整コストは速度向上より速く増えます。同時に走る部分がいくつかを超えると、マージそのものがプロジェクトになります。

## Install and first run
1. obra/superpowers から MIT ライセンスで superpowers を導入します。
2. 先に計画を書き、それから分割します。計画のない分割は混乱を掛け算にします。
3. 各エージェントにファイル境界と完了条件を与え、同じリポジトリに書くなら隔離を使います。

## Questions
### 並列化すべきでないのは
部分が状態や未決の設計判断を共有しているときです。自信のある互換性のない答えが複数返ってきます。

### 最も安全な使い方は
調査、監査、レビューのような読み取り専用の作業です。マージするものがありません。

### 隔離された作業環境は必要ですか
複数がリポジトリに書き込むなら必要です。そうでなければ手作業で衝突を処理することになります。

## Sources
- GitHub の obra/superpowers: https://github.com/obra/superpowers
- エージェントスキルのディレクトリ: https://skills.sh

## Other languages
- English: https://bestskillsforclaude.com/en/skills/subagent-driven-development
- Spanish: https://bestskillsforclaude.com/es/skills/subagent-driven-development
- Brazilian Portuguese: https://bestskillsforclaude.com/pt-br/skills/subagent-driven-development