設計せずに書き始める Claude を止める方法——公式プラグイン feature-dev

いきなり書き始める Claude

Claude Code に「この機能追加して」と頼むと、いきなり書き始めることがある。

既存コードをほとんど読まず、1 つの実装方針しか提示せず、曖昧な仕様のまま実装に入る。出来上がったものを見ると「いや、そっちじゃないんだよ」となる。書き直しになる。

何度かやられるうちに、私は依頼の前に長いプロンプトを書くようになった。「まず関連ファイルを読んで」「不明点があったら質問して」「複数の案を出して」——毎回これを書くのは面倒だし、書き忘れるとまた暴走する。

ある日 Anthropic 公式マーケットプレイスを眺めていて、feature-dev というプラグインが目に入った。説明を読むと、私が毎回書いていたあの長いプロンプトの 構造化版 だった。

feature-dev は何をするか

feature-dev は /feature-dev <機能の説明> で起動する 7 phase のワークフロー。順番にこう進む。

1. Discovery — 何を作るか・なぜ作るかをヒアリング
2. Codebase Exploration — 既存コードを並列で調査
3. Clarifying Questions — 曖昧点をまとめて質問してユーザー回答を待つ
4. Architecture Design — 複数の設計案を並列で起こして採択を仰ぐ
5. Implementation — 承認後に実装
6. Quality Review — 多観点で並列レビュー
7. Summary — 変更まとめ

順序は固定。Phase 5（実装）の前には 必ずユーザー承認 が入る。「いきなり書き始める」が構造的に不可能な作りになっている。

3 種類のサブエージェント

このワークフローは 3 つのサブエージェントを並列起動する。サブエージェント機能そのものの基礎はサブエージェント検証シリーズで扱ったので、ここでは feature-dev が組み合わせている 3 種類だけ見る。

• code-explorer：既存コードをトレースして、入口・データフロー・読むべきファイル一覧を返す
• code-architect：複数の実装方針（最小変更案、クリーン案、実用バランス案など）を返す
• code-reviewer：書いたコードを観点別にレビューする

特徴的なのは、サブエージェントが「答え」ではなく「次に読むべきファイルのリスト」を返す ところ。

これは賢い分担だと思う。エージェントに調査結果を全部書き出させると、本体（メイン Claude）の context が一気に膨れる。代わりに「ここを読め」とだけ指し示してもらえば、本体は必要な箇所だけ精読すればよい。

個人的に一番効くのは Phase 3

7 phase のうち、私が一番効くと感じているのは Phase 3（Clarifying Questions） だ。

ここでは、エッジケース・エラー処理・統合点・後方互換性・パフォーマンス要件などの曖昧点を まとめて一覧で質問してくる。回答する前に Phase 4 には進まない。

これが効くのは、AI を暴走させる最大の要因が「曖昧仕様」 だからだ。仕様が曖昧なままだと、エージェントは「たぶんこういうことだろう」で勝手に解釈して走り出す。後で見ると全然違う方向に進んでいる。

「先に全部聞いてくれ」を構造化したのが Phase 3 で、これだけで実装後の手戻りが目に見えて減る。

Phase 4 の「複数案を出す」も地味に効く

Phase 4 では code-architect が 2-3 並列で起動して、軸の違う設計案を返してくる。

• 最小変更案：既存コードに最小限の変更で済ませる、低リスク
• クリーン案：抽象化を整え、保守性を取る、変更量大
• 実用バランス案：ほどほどに整えてほどほどに早い、中間

軸が直交しているので比較しやすい。「最小か、クリーンか、バランスか」と聞かれると、自分の今の状況（時間がない / 長く保守する / プロト）と照らして選べる。

1 案だけ出されると「まあこれでいいか」と判断を放棄してしまうけど、3 案あるとちゃんと考える。これは設計の意思決定そのものを ユーザーに引き戻す仕掛け だと感じる。

レビューも並列・多観点

Phase 6 では code-reviewer が 3 並列で動く。観点を変えて投げる。

• 「シンプル / DRY / エレガンス」
• 「バグ / 機能的正しさ」
• 「プロジェクト規約 / 抽象化」

1 人のレビュアーに全部見せると観点が薄まるが、観点を分担すると深くなる。さらに confidence（信頼度）が 80 以上の指摘だけが報告される。「気になる点」レベルの低信頼ノイズは出ない。

どんなときに使うか

公式の README には「使うべき場面」「使わない方がいい場面」が書いてある。

使うべき：

• 複数ファイルに触る新機能
• アーキテクチャ判断が必要な機能
• 既存コードとの統合が複雑なもの
• 仕様がややぼんやりしている依頼

使わない方がいい：

• 1 行のバグ修正
• 自明で小さい変更
• 仕様が完全に決まっている定型作業
• ホットフィックス

私の使い方は前者寄り。新機能を頼むときに /feature-dev を経由するクセをつけてから、書き直しの頻度が体感で半分以下になった。

まとめ

feature-dev は「Claude にいきなり書かせない」を構造的に強制するプラグインだ。やっていることは、私が依頼のたびに長いプロンプトで書いていたものの 公式版。

7 phase + 3 サブエージェントという形式の中で一番本質的なのは、おそらく Phase 3 で曖昧さを潰す ことと サブエージェントに答えではなくファイルリストを返させる ことの 2 つだと思う。前者は AI 暴走対策、後者は context 管理の作法として、コーディング以外にも応用が効く考え方だ。

「機能追加を頼むたびに似たような前置きを書いている」と感じている人には、一度試してみてほしい。Claude Code で /plugin install feature-dev@claude-plugins-official を叩くだけで使えるようになる。