X で「Claude Code で一番使っているのは /feature-dev」という投稿を見かけた。コードベースの現状を読ませ、足りない要件を質問させてから実装に入るので、雑に頼んだ機能追加でも途中で論点が締まっていく、という話だ。
https://twitter.com/i/status/2034177733375430667
気になって確認してみると、/feature-dev は Claude Code の組み込みスラッシュコマンドではなかった。Anthropic の公式ニュース記事で案内されている feature-dev プラグインのコマンドで、/plugin marketplace add anthropics/claude-code のあとに /plugin install feature-dev で導入する形になっている。
ここを勘違いすると、「Claude Code を最新にしたのに /feature-dev がない」とハマる。まず前提として、これは公式が用意している拡張ワークフローであって、標準で最初から有効なコマンドそのものではない。
何が良いのか
feature-dev の中身は、単に「新機能を作るコマンド」ではない。Anthropic 公式リポジトリの README を読むと、7段階の機能開発ワークフローとして設計されている。
流れはざっくりこうだ。
- まず何を作るのかを確認する
- コードベース内の関連箇所を探索する
- 足りない要件や曖昧な点を質問する
- 複数の実装アプローチを比較する
- 承認後に実装する
- 専門エージェントでレビューする
- 変更内容を要約する
要するに、いきなりコードを書かせない。この一点が大きい。
AI コーディングでズレやすいのはここだ。雑な依頼でも、モデルはそれっぽいコードをすぐ出せてしまう。でも本当に欲しいのは「とりあえず動く何か」ではなく、既存設計と整合し、抜けている要件が洗い出され、あとで自分が困らない変更だ。
feature-dev は、その面倒な前工程をコマンド化している。効いている理由はそこにある。
深掘り質問が先に来る
README で特に重要なのは、第3段階を深掘り質問として独立させているところだ。OAuth の例では、どのプロバイダを使うのか、既存認証と共存させるのか、エラー処理をどうするのか、といった曖昧さを整理してから先へ進む。
これ、当たり前のようで実際には飛ばしがちだ。人間同士でも「まあたぶんこうだろう」で走ってしまうし、AI に投げるとその雑さがそのまま実装に乗る。
/feature-dev が便利なのは、モデルが賢いからというより、質問しないまま進めない構造になっているからだ。X の元投稿で「根掘り葉掘り聞かれることで脳が起きる」と書かれていたが、あれはかなり本質を突いている。
公式プラグインは分業まで入っている
さらに重要なのは、第2段階と第4段階と第6段階で、探索役や設計役やレビュー役のエージェントを並列で動かす前提になっていることだ。
- コード探索では
code-explorer - 設計比較では
code-architect - 品質確認では
code-reviewer
つまり feature-dev は、ただの「長いプロンプト」ではない。コードベース理解、設計比較、品質確認を役割分担させるプラグインとして作られている。
Claude Code を雑に使うと、強いモデル1体に全部やらせたくなる。でも Anthropic の公式サンプルは逆で、「誰に何をさせるか」を先に決めている。参考になるのはこの設計思想だ。
すぐ真似できる使い方
もし普段の AI コーディングが「とりあえず作って」で始まりがちなら、feature-dev をそのまま入れなくても、考え方だけ真似すると効く。
- まず現状コードを調べる
- そのあと不足要件を質問させる
- 実装案を2つ以上出させる
- 承認してから書かせる
- 最後に別視点でレビューさせる
この順番を守るだけで、AI の出力はかなり扱いやすくなる。モデルの性能差より、ワークフロー差の方が支配的な場面は多い。
Claude Code の /feature-dev は、そのワークフローを「思い出して頑張る」ではなく、「コマンドにして毎回踏ませる」ところまで持っていった。そこが良い。