最近、AI駆動開発にSDD（Spec Driven Development、仕様駆動開発）を取り入れるアプローチがある。Kiro式やその方式をClaude Codeなどでも使えるようにしたcc-sdd、spec-kitなど色々なツールが出ている。
自分もcc-sddを個人開発で試してみたのだが、生成される仕様の文章量が膨大で、実装を始めるまで時間がかかる割に仕様のレビューもしきれなかった。diff 1000行のPullRequestが来たらレビューできず「よく分からないけどOK」となるのと同じで、仕様も膨大だとレビューできないという気持ちになった。
一方で、SDDの考え方の中でも、実装を始める前にちゃんと要件や仕様を固めたいなど、自分の中で取り入れたいものはあった。そこで、自分の得意不得意に合わせてスラッシュコマンドを自作して運用している。個人的にこのやり方がハマっているので紹介する。
自分の得意不得意に合わせてプロセスにメリハリをつける
SDD系のツールではrequirements（要件定義）、design（設計）、tasks（タスク分解）のようなプロセスを全て詳細に生成する。しかし自分の場合は全てに同じ力を入れる必要はないと考えた。自分は長年エンジニアをやってきたため、設計やコード実装は得意だ。一方、ユーザー目線で要件や仕様を固めるのはエンジニアリングと比較すれば弱い。
自分の能力を考えると、SDDの中でもrequirementsはしっかり作りたい。一方でdesignやtasksは自分でもある程度考えられるので、AIと壁打ちしながらシンプルにまとめてもらえれば十分だと考えた。
このように自分の特性に合わせてSDDを運用するなら、自作のスラッシュコマンドを作って運用するのが最適だと考えた。そこでAIと協力しながら /create-requirements や /create-implement-plan というスラッシュコマンドを作って運用している。
/create-requirements: 要件定義をしっかり作る
自分は要件定義をしっかり作るために、/create-requirementsというClaude Codeのスラッシュコマンドを作った。ヒアリングを通じて要件定義書を作ってもらうためのものだ。
Goalやスコープに入れるもの、User storiesなど、含めたい内容を決めて、それに向かってヒアリングを繰り返してくれるようになっている。さらに技術的な設計・実装詳細を一切含めないように制約をかけているのもポイントだ。要件定義の段階で実装の話が混ざると判断がブレるので、「何を作るか」だけに集中できるようにしている。
プロンプト全文
--- argument-hint: 作りたい機能 --- ## あなたの役割 わたしにヒアリングしながら作りたい機能の要件定義を確定してください。事実確認と利用者価値に集中して要件定義していきます。 ## 制約（最重要） - この段階では技術的設計・実装詳細・アーキテクチャ・データ構造・API仕様・ライブラリ選定を**一切**検討しない。要件を整理するためにこちらから実装について聞いた時だけチャットで教えるだけで、最終的な要件定義書には含めない - 実現方法の示唆（例: 「〜で実装できる」「〜を使う」）は禁止 - 出力は**要件のみ**。検討すべき事項は「Open Questions」に入れる ## 要件定義したい内容 $1 に基づいて要件定義を行ってください。 ## 手順 1) 作りたい機能の概要を理解し、その文脈を把握するために現在のコードベースを調査する 2) 不足情報を最大3問だけ質問する（Yes/No or 選択式を優先） 3) こちらが「十分」と言うか、あなたが十分だと判断するまで、質問を繰り返す 4) 要件定義書を返答、もしくはプランファイルとしてMarkdown形式で作る。以下を必ず含める - Context / Goal - In scope / Out of scope - User stories（3〜7個） - Acceptance Criteria（Gherkinで主要3本＋例外2本） - NFR（性能/コスト/セキュリティ/監査/運用） - Open Questions（未確定事項）
/create-implement-plan: 壁打ちしながら実装計画を作る
実装計画を作るために/create-implement-planというスラッシュコマンドを作った。壁打ちしながらフェーズ分解・commit分解まで行うものだ。
こっちは先に既存調査をしてもらって設計と大まかな実装方針を提示してもらい、それを壁打ちしていくスタイルにしている。またAIに実装をしてもらうために自分の好みのフェーズ分解をしてもらった方がやりやすいため、どのように分解するかは詳しく指示している。
プロンプト全文
--- argument-hint: 要件定義書のパス --- ## あなたの役割 わたしと壁打ちしながら、要件定義書から実装計画（フェーズ分解・commit分解）を作成してください。 ## 要件定義書 $1 を読み込んで、実装計画を作成してください。 ## 手順 1) 要件定義書を読み込み、実装する機能の全体像を把握する 2) 関連するコードベースを調査し、既存のアーキテクチャ・パターンを理解する 3) PoCや参考PRがあれば確認する 4) 実装する要件と、既存のコードベースやアーキテクチャを考慮し、設計と大まかな実装方針を検討する 5) この段階でわたしと相談し、フィードバックを受けながら設計と実装方針を確定する。わたしが「十分」と言うまで、次に進んではならない 6) 実装方針が決まり次第、フェーズ分解案を提示し、壁打ちする 7) 各フェーズのcommit分解案を提示し、壁打ちする 8) 確定したら実装計画をMarkdown形式で返答する ## フェーズ分解の観点 - 「一つの統合ができる単位」で分解する - フェーズごとに別PRにすることも検討する ## commit分解の観点 - レイヤーごとに分ける（下位レイヤー → 上位レイヤー） - 「概念的な責務」が1つ = 1 commit - テストと実装は同じcommitにする（確認しながら進められる） ## 出力フォーマット 要件定義書の末尾に以下の形式で追記： ### 実装計画 （参考PRなどあれば記載） ### フェーズN: フェーズの概要 ### Commit N: commit message - やること1 - やること2 - やること3 - ... - やることN ### フェーズN+1: フェーズの概要 ...
実際に使ってみた感触
事例としてはslack-explorer-mcpにCanvas対応を入れた時の資料がある（20260124-canvas-html-strip-requirements-ja.md）。要件や仕様面はきっちり作った上で、実装計画部分はシンプルな形になっている。
元々cc-sddを使った時は、小さい機能でも仕様の生成とレビューに1時間以上かかり、それでもレビューしきれない状態だった。自作のスラッシュコマンドに切り替えてからは、要件定義は10分程度、実装計画も5分程度で完了するようになった。自分が注力したい要件定義にはちゃんと時間をかけつつ、全体のコストはかなり下がったと感じる。
まとめ
SDDのツールが合わなくても、「実装前に要件を固める」というSDDの考え方自体は有用だ。既存ツールのやり方にこだわる必要はなく、自分の得意不得意に合わせて必要な部分だけ取り入れればいい。自作のスラッシュコマンドなら情報量を自分でコントロールできるし、いつも漏らしがちな観点があればプロンプトに組み込んでおける。SDDが重いなと感じたら、自分に合ったスラッシュコマンドを作ってみるのもおすすめ。
