Claude Codeのfeature-devプラグインで7フェーズ開発を回す手順
feature-devは、要件確認から設計、実装、レビューまでを7フェーズに分けて進めるClaude Codeの公式プラグインです。導入手順、3つのサブエージェントの役割、人が判断する地点、向かない場面をまとめます。
feature-devは、新機能の開発を7つのフェーズに区切って進めるClaude Codeのプラグインです。/feature-dev と打つと、コードを書き始める前にコードベースの調査、要件の質問、設計案の比較を挟み、実装後にはレビューまで走ります。Anthropicの公式プラグイン集に入っています。
要するに、Claudeに「いきなり実装させない」ための型です。人が答える場面が途中に4回あり、そこで止まる設計になっています。この記事では導入から各フェーズの動き、サブエージェントの正体、向かない場面までを順に見ます。
feature-devプラグインとは何か
feature-devは /feature-dev というスラッシュコマンド1つと、code-explorer・code-architect・code-reviewer という3つのサブエージェントで構成されます。プラグインの説明文は「コードベースの調査、設計、品質レビューのための専門エージェントを備えた機能開発ワークフロー」です。
このプラグインが前提にしているのは、機能開発が「書く」だけでは終わらないという考え方です。READMEは、コードベースを理解し、曖昧な要件を質問で潰し、実装前に設計し、作ったあとにレビューする、という4つの習慣をコマンドに埋め込んだと説明しています。
Planモードとは守備範囲が違います。Planモードは変更を加えずに計画を出すための動作モードです。feature-devは計画の前後、つまり調査・質問・設計案の比較・実装・レビューまでを1本のコマンドに束ねたものです。
導入と起動
公式マーケットプレイスは、対話セッションを初めて開いたときに自動で登録されます。そのため、インストールは次の1行で始められます。
/plugin install feature-dev@claude-plugins-officialセッション内でこのコマンドを打つと、すぐには入らずプラグインの詳細パネルが開きます。内容を確認し、インストール範囲(user・projectなど)を選んで確定します。シェルから入れる場合は claude plugin install feature-dev@claude-plugins-official です。プラグインの仕組み全般はClaude Codeプラグイン完全ガイドにあります。
入れた直後に反映されないときは、/reload-pluginsで再起動なしにプラグインを反映する方法が使えます。
起動は次の2通りです。
/feature-dev APIエンドポイントにレート制限を追加する
/feature-dev引数に機能の説明を渡すと、それが最初の依頼として使われます。引数なしでも起動でき、その場合は対話で聞かれます。プラグインのコンポーネントは名前空間付きで管理されるため、補完候補が feature-dev:feature-dev のように表示されることがあります。入力時は / に続けて補完で確かめると確実です。
7フェーズの流れ
READMEとコマンド定義に書かれたフェーズを順に並べます。「止まる」と書いた地点が、人の返答を待つ場所です。
feature-devの7フェーズ
- 1
1. Discovery(要件の把握)
作りたいものが曖昧なら、解きたい問題と制約を聞き、理解した内容を要約して確認を取ります。
- 2
2. Codebase Exploration(コードベース調査)
code-explorerを2〜3本並列で動かし、似た機能や構造を追わせます。各エージェントは読むべき主要ファイルを5〜10個挙げ、Claudeがそれを実際に読んで要約を出します。 - 3
3. Clarifying Questions(確認質問)
調査結果を踏まえ、抜けているエッジケース、エラー処理、連携点、後方互換性、性能要件を質問リストにまとめて出します。答えが返るまで先に進みません。止まります。
- 4
4. Architecture Design(設計案の比較)
code-architectを2〜3本並列で動かし、変更最小、クリーンな設計、バランス型の3方向で案を作らせます。比較とおすすめを添えて、どれにするかを聞きます。止まります。 - 5
5. Implementation(実装)
明示的な承認を待ってから、選んだ設計で実装します。コマンド定義には「ユーザーの承認なしに始めない」と大文字で書かれています。止まります。
- 6
6. Quality Review(品質レビュー)
code-reviewerを3本並列で動かします。観点は、簡潔さ・重複排除、バグ・正しさ、規約・抽象化の3つです。指摘を集約し、今直す・後で直す・そのまま進める、のどれにするかを聞きます。止まります。 - 7
7. Summary(まとめ)
作ったもの、主な判断、変更したファイル、次の候補を要約し、進捗管理用のToDoを完了にします。
READMEの例では、/feature-dev Add caching と頼むとフェーズ1で「何をキャッシュするか」「性能要件は」「使いたいキャッシュ基盤は」と聞かれます。フェーズ3の例は、OAuth対応を頼んだ場合に「どのプロバイダーか」「トークンを保存するか」「既存の認証を置き換えるか並存させるか」と聞く形です。これらはREADMEに載っている例示で、実際の質問はコードベースの調査結果によって変わります。
3つのサブエージェントの役割
フェーズ2・4・6でそれぞれ別のサブエージェントが動きます。定義ファイルを見ると、3つとも同じ作りです。
| エージェント | 動くフェーズ | 並列数 | 役割 |
|---|---|---|---|
| code-explorer | 動くフェーズ2 | 並列数2〜3 | 役割実行経路をたどり、構造と依存を調べ、読むべきファイルを返す |
| code-architect | 動くフェーズ4 | 並列数2〜3 | 役割既存の規約を踏まえ、実装の設計図と作る順序を出す |
| code-reviewer | 動くフェーズ6 | 並列数3 | 役割バグ、規約違反、品質の問題を、確信度の高いものだけ報告する |
3つとも使えるツールは検索と読み取り系(Glob、Grep、Readなど)に限られ、Write・Edit・Bash は含まれません。モデルは sonnet に固定されています。つまり、調査・設計・レビューの各エージェントはファイルを書き換えられず、書くのはメインのClaudeだけです。
README上は、この3つはフェーズの外からも呼べます。例えば次のように頼めます。
code-explorerで認証の仕組みを端から端まで追って
code-architectでキャッシュ層の設計案を出して
code-reviewerで直近の変更を確認して全フェーズを通す必要がない場面でも、調査だけ、レビューだけを切り出して使えます。サブエージェントのモデルを役割ごとに変えたい場合の考え方はサブエージェントのモデル配分設計で扱っています。
人が止まる4地点で何を用意するか
feature-devの特徴は、速さではなく「止まる場所」にあります。本格的に判断を求められるのは、次の4地点です。
- フェーズ3の質問への回答
- フェーズ4の設計案の選択
- フェーズ5の実装開始の承認
- フェーズ6の指摘への対応方針
フェーズ1の確認は、依頼が明確なら軽く済みます。負担が大きいのはフェーズ3と4です。
フェーズ3の質問が多いと感じるときは、最初の依頼に制約を書くと減ります。READMEも「具体的に依頼するほど質問が減る」「制約を先に伝える」「本当にこだわりがなければ、お任せと答えてよい」と案内しています。たとえば依頼文を次のように組みます。
/feature-dev 注文一覧APIにページネーションを追加する。
既存のcursor方式に合わせる。レスポンス形式は変えない。
テストは既存のpytestに追加する。この例は、決めてある点(方式・互換性・テストの置き場)を先に書いて、フェーズ3で聞かれる範囲を狭める書き方です。
フェーズ4の設計案が多くて迷うときも、READMEは「推奨案は、コードベースの分析に基づいている」と書き、迷ったらバランス型を選ぶよう勧めています。
CLAUDE.mdでレビューの精度が変わる
code-reviewer の定義は、プロジェクトのルール(CLAUDE.mdなど)への準拠を最初のレビュー観点に挙げています。code-architect も、技術スタックやモジュール境界と並んでCLAUDE.mdの指針を拾うよう書かれています。規約をCLAUDE.mdに書いておけば、設計とレビューの両方で基準として働きます。
書き方の例を示します。ポイントは、レビューで機械的に確かめられる粒度にすることです。
## コーディング規約
- APIハンドラは `src/api/handlers/` に置き、ビジネスロジックを書かない
- 外部呼び出しは `src/clients/` 経由にし、ハンドラから直接呼ばない
- エラーは `AppError` を投げる。生の `Error` は使わない
- 新しいエンドポイントには `tests/api/` に対応するテストを置く「きれいに書く」のような抽象的な指示は、レビューで判定しようがありません。置き場所、禁止事項、命名のように、差分を見て違反かどうか言えるものを並べると、フェーズ6の指摘が具体的になります。
READMEとエージェント定義で食い違う点
code-reviewer の報告基準は、READMEと定義ファイルで書き方が揃っていません。
READMEの概要は「確信度80以上のものだけ報告する」としながら、出力の節では「重大(確信度75〜100)」と「重要(確信度50〜74)」の2段を挙げています。一方、エージェント定義は「確信度80以上のものだけを報告する」と明記し、0・25・50・75・100の5段階の目安を載せています。
実際の動作を決めるのは定義ファイルの側です。この基準に従えば、確信度が80に届かない軽い指摘は報告に出ません。READMEの「重要(50〜74)」の項目が出力に並ぶとは期待せず、細かな指摘が欲しいときは、code-reviewer を単体で呼んで観点を明示します。
もう1点あります。code-reviewer は既定で git diff の未ステージ変更を対象にします。フェーズ5の途中でコミットしてしまった場合は、対象範囲が空になりかねません。コミット済みの変更を見せたいときは、範囲(ブランチ差分や特定のファイル)を指定します。READMEが要件にGitリポジトリを挙げているのも、このレビューのためです。
向く場面と向かない場面
READMEは、向く場面として次の4つを挙げています。
- 複数ファイルにまたがる新機能
- 設計上の判断が要る機能
- 既存コードとの複雑な連携
- 要件がまだ固まりきっていない機能
向かない場面は、1行のバグ修正、ごく小さな変更、内容が明確で単純な作業、緊急のホットフィックスです。7フェーズを通すと、調査エージェントの並列起動や質問のやり取りで時間がかかります。READMEも、大きなコードベースで調査が遅いのは通常の挙動だと書いています。
要件に挙がっているのは、Claude Codeが入っていること、レビュー用のGitリポジトリ、そして学習元となる既存のコードがあることです。ゼロから新規プロジェクトを作る場面では、調査フェーズで拾える情報がないため、効果は薄くなります。
近い機能との使い分け
「計画を立ててから実装したい」という目的は、他の機能でも満たせます。違いは、止まる地点の数と、並列で動く調査・レビューの有無です。
| やりたいこと | 向く手段 |
|---|---|
| 小さな変更の方針だけ先に見たい | 向く手段Planモード |
| 実装後に差分を点検したい | 向く手段/code-review や /simplify |
| 調査・質問・設計比較・レビューを通しで回したい | 向く手段feature-dev |
レビュー部分だけが目的なら、Claude Codeコードレビューの4つの実行経路や/simplifyコマンドのほうが軽く済みます。feature-devのフェーズ6は、その1回分を設計・実装と同じ流れの中に組み込んだものと位置づけられます。
よくあるつまずき
- エージェントが遅い: 大きなコードベースでは調査に時間がかかります。READMEによれば、エージェントは可能な範囲で並列に動きます。
- 質問が多すぎる: 依頼文に制約と対象範囲を書き、決めていない点には「お任せ」と答えます。
- 設計案が3つ出て決められない: 推奨案に従うか、迷ったらバランス型を選びます。判断の根拠を聞き返すこともできます。
- コマンドが補完に出ない: インストール範囲と、プラグインが有効になっているかを
/pluginで確かめます。
まとめ
feature-devは、実装そのものを速くするものではありません。調査・質問・設計比較・レビューという、飛ばしがちな工程を強制的に挟むための型です。判断が要る地点で止まるので、任せっぱなしにはなりませんが、そのぶん「何を決めるか」を人が持ち続けられます。
試すなら、複数ファイルにまたがる中規模の機能を1つ選び、依頼文に制約を書いて走らせるのが入り口です。CLAUDE.mdに規約を数行足しておくと、フェーズ4とフェーズ6の出力が変わります。