AIコーディングツールの競争軸が変わりつつある。「いかに速くコードを書くか」から「いかに早く正しい設計にたどり着くか」へ。Claude Codeの公式プラグイン「feature-dev」は、この転換を体現する設計駆動の開発支援ツールだ。本記事では、feature-devの導入から7フェーズのワークフロー、3つの専門サブエージェントの役割、そして京谷商会での実践まで、具体的に解説する。
feature-devとは何か — Anthropic公式の設計駆動プラグイン
プラグインの概要と位置づけ
feature-devは、Anthropic社のSid Bidasariaが開発したClaude Code公式プラグインだ。バージョン1.0.0で公開され、すでに131,475回以上インストールされている。Claude Codeのプラグインシステム（パブリックベータ）を通じて提供されており、CLI、Desktop、VS Codeのいずれの環境でも動作する。
Claude Codeのプラグインは、スラッシュコマンド・サブエージェント・MCPサーバー・フックを組み合わせた軽量な拡張パッケージとして設計されている。feature-devはこの仕組みを最大限に活用し、単一の/feature-devコマンドから7つのフェーズと3つの専門エージェントを起動する構成になっている。
なぜ「コード生成」ではなく「設計支援」なのか
多くのAIコーディングツールは「プロンプトを入れればコードが出てくる」という体験を売りにしている。しかし、実際の開発現場で時間を消費するのはコードを書く行為そのものではない。既存コードの理解、設計方針の決定、エッジケースの洗い出し、レビューでの手戻り——こうした「コードを書く前後」の工程が全体の大半を占める。
feature-devは「設計を正しく定義すれば実装時間は劇的に短縮できる」という思想に基づいている。コードを自動生成する前に、要件の曖昧さを解消し、既存コードベースとの整合性を検証し、複数のアーキテクチャ設計案を比較検討する。この設計駆動のアプローチが、feature-devの核心だ。
feature-devのインストールと起動方法
/pluginコマンドからのインストール手順
feature-devのインストールはClaude Code内で完結する。/pluginコマンドを実行するとインタラクティブなUIが開き、「Discover」タブから検索できる。
/plugin
Discoverタブで「feature-dev」を検索し、インストールを実行する。インストール後は以下のコマンドでプラグインを読み込む。
/reload-plugins
これだけでfeature-devが利用可能になる。特別な設定ファイルの編集やAPIキーの追加は不要だ。
/feature-devの2つの起動パターン
feature-devには2つの起動方法がある。1つ目は、機能の説明を引数として直接渡すパターンだ。
/feature-dev Add user authentication with OAuth
このように起動すると、feature-devはただちにDiscoveryフェーズに入り、渡された要件をもとに深掘りを始める。実装したい機能が明確に言語化できている場合に適している。
2つ目は、引数なしで起動するガイド付きパターンだ。
/feature-dev
この場合、feature-devが対話的に要件を聞き出してくれる。「何を作りたいのか漠然としているが、とりあえず相談したい」という段階でも使える。
また、個別のエージェントを手動で呼び出すことも可能だ。
code-explorerを起動して認証フローをトレースして
特定のフェーズだけを実行したい場面では、この方法が効率的に機能する。
7フェーズワークフローの全体像
Discovery（要件把握）からSummary（最終報告）までの流れ
feature-devのワークフローは7つのフェーズで構成されている。単純な直線ではなく、人間のレビューと承認を挟みながら進む設計になっている点が特徴的だ。
Phase 1: Discovery（要件把握） では、feature-devが機能要求の明確化を行う。制約条件、既存機能との関係、期待される振る舞いについて質問を重ね、あいまいな要件を具体的な仕様に落とし込む。
Phase 2: Codebase Exploration（コードベース探索） では、2〜3体のcode-explorerエージェントが並列に起動する。それぞれが異なる観点から既存コードを読み解き、実行パスのトレース、アーキテクチャ層のマッピング、関連ファイルの特定を行う。この並列探索により、大規模なコードベースでも短時間で全体像を把握できる。
Phase 3: Clarifying Questions（確認質問） は、feature-devが人間に判断を求めるフェーズだ。エッジケースの処理方針、エラーハンドリングの戦略、既存機能との統合ポイント、後方互換性の要件などについて質問が提示される。このフェーズではfeature-devが明示的にユーザーの回答を待つ。自動で先に進むことはない。
Phase 4: Architecture Design（アーキテクチャ設計） では、2〜3体のcode-architectエージェントがそれぞれ異なるアプローチで設計案を作成する。最小限の変更で済むアプローチ、クリーンアーキテクチャを追求するアプローチ、実用主義的なバランスを取るアプローチが並列に検討され、トレードオフ分析と推奨案が提示される。
Phase 5: Implementation（実装） に進むには、ユーザーの明示的な承認が必要だ。Phase 4で選択されたアーキテクチャに基づいて実装が進む。
Phase 6: Quality Review（品質レビュー） では、3体のcode-reviewerエージェントが並列に起動する。シンプルさとDRY原則、バグと正確性、コーディング規約という3つの観点からレビューを行い、信頼度スコア80%以上の指摘のみが報告される。
Phase 7: Summary（最終報告） では、実装内容、主要な設計判断、変更されたファイル、次のステップがドキュメント化される。
各フェーズで人間が判断するポイント
7フェーズの中で、人間の介入が必須となるのはPhase 3（確認質問への回答）、Phase 4からPhase 5への移行（アーキテクチャの承認）、そしてPhase 6の結果を受けた修正判断の3箇所だ。これらのゲートが存在することで、AIが誤った方向に暴走するリスクを構造的に抑えている。
逆に言えば、それ以外のフェーズではfeature-devが自律的に動く。コードベースの探索、設計案の比較、品質レビューといった「時間はかかるが判断の余地が少ない」工程をAIに任せ、「方向性を決める」工程に人間が集中する。この分業設計がfeature-devの生産性向上の源泉になっている。
3つの専門エージェントの役割と仕組み
code-explorer — 既存コードのパターン解析
code-explorerは読み取り専用のエージェントだ。コードベースに一切変更を加えず、既存の実装パターンを解析することに特化している。具体的には、関数の呼び出し関係をたどって実行パスをトレースし、アーキテクチャの各層（データ層、ビジネスロジック層、プレゼンテーション層など）を識別し、新機能の実装に不可欠なファイルを特定する。
結果はファイル名:行番号の形式で返されるため、指摘箇所をすぐに確認できる。Phase 2では2〜3体のcode-explorerが並列で動き、それぞれが異なるエントリーポイントから探索を開始するため、単一エージェントでは見落としがちな依存関係も捕捉できる。
code-architect — アーキテクチャ設計の比較提案
code-architectはPhase 4で起動する設計専門のエージェントだ。code-explorerの調査結果を踏まえて、2〜3の実装アプローチを提案する。
各エージェントには異なるフォーカスが与えられる。1体目は既存コードへの変更を最小限に抑えるアプローチ、2体目はクリーンアーキテクチャの原則に忠実なアプローチ、3体目は実用性と設計品質のバランスを取るアプローチを検討する。単に「こう実装すべき」と1案を出すのではなく、複数案のトレードオフを可視化したうえで推奨を示す。この比較提案の仕組みにより、開発者は設計判断の根拠を理解したうえで方針を選択できる。
code-reviewer — 信頼度スコア付き品質レビュー
code-reviewerはPhase 6で3体が並列に起動するレビュー専門エージェントだ。それぞれが「シンプルさとDRY原則」「バグと正確性」「コーディング規約への準拠」という異なる観点でレビューを行う。
特筆すべきは信頼度スコアの仕組みだ。各指摘に対して0〜100%の信頼度が付与され、80%未満の指摘はフィルタリングされて報告されない。AIレビューにありがちな「可能性として指摘しているだけの曖昧なコメント」が排除され、対応すべき指摘だけが残る。この仕組みにより、レビュー結果のノイズが大幅に削減される。
feature-devが効く場面・効かない場面
複雑な機能開発やアーキテクチャ判断に最適な理由
feature-devが真価を発揮するのは、複数ファイルにまたがる機能追加、既存アーキテクチャとの整合性が問われる設計判断、要件が複雑でエッジケースの洗い出しが必要な開発だ。たとえば、認証システムの追加、決済機能の統合、APIバージョニング戦略の策定といったタスクでは、7フェーズのワークフローが投資に見合う価値を生む。
Anthropicのサブエージェントドキュメントが示すように、サブエージェントの並列起動は複雑な問題の分解に効果的であり、feature-devはまさにこのパターンを体系化したものだ。
1行修正や単純タスクには不向き
一方で、feature-devは万能ではない。1行の修正、typoの修正、単純で定義が明確なタスク、緊急のホットフィックスには向かない。7フェーズのワークフローはオーバーヘッドを伴うため、「5分で終わる作業に30分の設計プロセスを回す」のは非効率だ。Claude Codeに直接指示を出すほうが適切な場面は多い。
使い分けの判断基準はシンプルで、「実装前に設計判断が必要か」という問いに尽きる。答えがYesならfeature-dev、Noなら直接実装が合理的だ。
実装での運用パターン — 設計フェーズの構造化とAIスタッフの分業
新規機能開発の立ち上げにfeature-devを組み込む実装方法
feature-devが実務で機能するには、プロジェクト立ち上げ時の運用設計が重要だ。新しい機能開発や既存システムの大規模改修が発生した際、まずfeature-devでDiscoveryからArchitecture Designまでを回し、設計方針を確定させてから実装フェーズに入るという流れが有効である。
この運用が定着するポイントは、複数の実装担当者が並行作業する環境では、設計の一貫性がとりわけ重要になるという点にある。feature-devの7フェーズを通じて設計を明文化することで、後続の実装担当者が迷わず作業を進められるようになる。
また、AIベースの開発体制を導入している場合、各AI実装エージェントが個別に作業を進める際の指針として、feature-devの設計出力が共有仕様書となる。これにより、AIスタッフ間の実装品質にばらつきが出るのを防ぎ、統一された設計理念のもとでコードが生成される。
設計の正確さで実装時間を短縮させる仕組み
「正しい設計を最初から定義できれば、実装は従来の半分以下の時間で終わる」——これはfeature-devの運用を通じて多くのチームが経験する実感だ。
従来のワークフローでは、実装を依頼した後で設計上の問題が発覚し、手戻りが発生するケースが多い。feature-devの導入後は、Phase 3の確認質問とPhase 4のアーキテクチャ比較を経ることで、実装開始前に潜在的な問題の大半が洗い出される。結果として、実装フェーズでの手戻りが激減し、トータルの開発時間が短縮される。
特にPhase 2のcode-explorerによるコードベース探索は、既存の複雑なシステムに新機能を追加する際に威力を発揮する。単一の実装者がコードを読むよりも、構造化された並列探索のほうが漏れなく依存関係を把握できるからだ。この前置きがあれば、後続の実装フェーズは予測可能性が高まり、見積もりの精度向上にもつながる。