要件定義 Claude Code｜質問・仕様・プロンプト例で手戻り回避
Claude Codeに「アプリを作って」と頼んだのに、想定と違う機能や画面ができてしまう。原因は、コードを書く前に目的・利用者・範囲・合格条件が共有されていないことです。本記事では、要件定義を会話で進める順番、使えるプロンプト、要件定義書とCLAUDE.mdの役割、実装前の確認方法を、初めて使う人にもわかる形で整理します。
Claude Codeの要件定義は、いきなり実装させず、目的・利用者・機能・制約・受け入れ条件を質問で確定し、合意した内容を文書に残してからPlan Modeで計画を確認する流れです。曖昧さと手戻りを減らして実装へ進めるとわかる。
目次 (8)
Claude Codeで要件定義をするメリット
要件定義は、「誰が、何のために、何を使い、どこまでできれば成功か」を開発前にそろえる作業です。Claude Codeは不足部分を推測して先へ進めるため、前提が曖昧だと実装後の修正や作り直しにつながります。
まず、要望・要件・仕様・実装を分けて考えます。
| 段階 | 決めること | 例 |
|---|---|---|
| 要望 | 作りたいものの方向 | 店舗の予約をオンラインで受けたい |
| 要件 | 必要な振る舞いと条件 | 利用者は空き枠を確認して予約できる |
| 仕様 | 画面や処理の具体的なルール | 予約確定後にメールを送る |
| 実装 | 技術的な作り方 | DB、API、画面をどの構成にするか |
検索上位の記事でも、いきなり作らせず、Claude Codeに質問させて考えを整理する方法が紹介されています。実践例はClaude Codeラボ（https://claudecodelab.jp/blogs/claude-code-requirements/）、仕様書作成例（https://portal.okihiro-school.com/articles/claude-code-requirements-definition）、要件定義から実装へ進めた記録（https://techuplabo.com/requirement-definition-to-app-claude-code-260102/）で確認できます。
最初に整理する5つの論点
Claude Codeへプロンプトを送る前に、次の論点を洗い出します。未決定の部分は「未定」と明示し、勝手に確定させないことが大切です。
- 目的と成果：何を改善し、完成後にどんな状態なら成功かを決めます。「電話受付を減らし、二重登録を防ぐ」のように書くと判断軸になります。
- 利用者と場面：誰が、いつ、どの端末から使うかを整理します。管理者と一般利用者は役割ごとに分けます。
- 機能・非機能要件：機能に加え、速度、セキュリティ、対応ブラウザなど品質条件も書きます。
- 制約と対象外：予算、納期、既存サービス、個人情報の扱いと、今回作らないものを決めます。
- 受け入れ条件：完成と判定する操作と結果を書きます。例は「予約確定後に番号を表示し、管理画面にも同じ予約を出す」です。
この5項目は、Functional、Non-functional、Constraint、Acceptance Criteria、Out of Scopeという分類にも対応します。用語を英語で書く必要はありませんが、分類すると機能だけを書いて運用条件を忘れる失敗を防げます。
要件定義の実践手順：質問から合意まで
要件定義は一度の長い指示で終わらせず、質問、整理、確認、文書化の順に進めます。
- 最初は質問だけを依頼する：目的を短く伝え、「コードは書かず、決めるべき論点を質問してください」と指定します。
- 決定事項と仮定を分ける：回答のたびに「決定」「未決定」「Claude Codeの仮定」を分けて表示させます。
- 操作をシナリオにする：正常系に加え、空入力、重複、権限不足、通信失敗、キャンセルなどを確認します。
- 要件定義書を保存する：背景、目的、要件、制約、対象外、受け入れ条件、未決事項を
requirements.mdなどに残します。 - 人間が承認する：不足・矛盾・過剰な要件を指摘させ、依頼者が優先順位と範囲を確定します。
- 計画を確認して実装する：変更ファイル、実装順、テスト、リスクを計画に出させ、要件との差分を確認してから編集を許可します。
この流れなら、質問の途中で決定が変わっても文書と計画を更新できます。会話の記憶だけに頼らず、決定事項をファイルに残すことが、時間を空けて再開する場合にも役立ちます。
そのまま使える要件定義プロンプト例
最初の依頼は、「質問の進め方」と「出力形式」を明示します。サービス名や利用者だけを置き換えて使えます。
予約管理アプリを作りたい。実装前に要件定義を進めたい。
次のルールでヒアリングしてください。
1. コードを書かず、決めるべきことを質問する
2. 論点を絞り、私の回答を待つ
3. 目的、利用者、要件、制約、対象外、受け入れ条件を確認する
4. 決定、未決定、仮定、リスクを分ける
5. 権限、入力エラー、重複、通信失敗も質問する
6. 最後に requirements.md の草案を作り、実装は始めない
私が回答し終えたら、矛盾や不足を指摘してから、要件定義書を提示してください。
ポイントは、Claude Codeに答えを急がせず、質問を通じて前提を引き出すことです。「良い感じに作って」「一般的な仕様で進めて」は便利な反面、判断をAIに預ける範囲が広くなります。未決事項には選択肢、推奨案、採用時の影響を並べて提示させると決めやすくなります。
要件定義書とCLAUDE.mdを使い分ける
要件定義書と CLAUDE.md は、どちらもMarkdownで管理できますが、役割が違います。
| 文書 | 書く内容 | 更新の単位 |
|---|---|---|
requirements.md |
今回の機能の目的、範囲、振る舞い、受け入れ条件 | 機能や案件ごと |
CLAUDE.md |
プロジェクト共通の規約、構成、テストコマンド、禁止事項 | プロジェクト全体 |
CLAUDE.mdには、すべての作業で守るルールだけを置きます。「変更後はテストを実行する」「秘密情報をコミットしない」といった内容です。特定機能の期限や画面仕様まで詰め込むと、重要な指示が埋もれます。
Claude Code公式の説明（https://code.claude.com/docs/en/memory）でも、CLAUDE.mdはセッション開始時に読み込まれる指示書として扱われ、簡潔な構成が推奨されています。要件定義書を別に保管し、CLAUDE.mdには「機能開発では docs/requirements.md を確認する」と書くと役割が明確です。
Plan Modeで実装前に確認する
要件が固まったら、Plan Modeでコードベースと要件の関係を調べます。公式ドキュメントでは、Plan Modeはファイルを読みながら計画を提案し、承認までソースを編集しないモードと説明されています。起動例は次のとおりです。
claude --permission-mode plan
セッション中は /plan や Shift+Tab で切り替える方法もあります。表示は環境で異なるため、利用中の公式ドキュメントも確認してください。
Plan Modeでは、次の内容を依頼すると要件と計画を照合しやすくなります。
requirements.mdを読み、目的と受け入れ条件を要約する- 関係する既存ファイルとデータの流れを調査する
- 変更・追加・変更しないファイルを分ける
- 実装順、テスト、リスクを提示する
- 要件にない変更や判断が必要な点を質問する
公式のベストプラクティス（https://code.claude.com/docs/en/best-practices）も、複雑な作業では「探索、計画、実装」の順に進め、検証手段を先に用意する考え方を示しています。計画を読んで変更範囲やテスト漏れを確認すれば、大きな手戻りを避けられます。使い方は公式チュートリアル（https://code.claude.com/docs/en/tutorials）にも掲載されています。
要件定義で起きやすい失敗と対策
文章の見栄えより、決定の根拠と確認可能性を重視します。
| 失敗 | 起きること | 対策 |
|---|---|---|
| 「作って」だけで依頼する | Claude Codeが不足部分を推測する | 先に質問だけを依頼する |
| 機能一覧だけを書く | 使う人や成功条件が不明になる | 利用シナリオと受け入れ条件を加える |
| 対象外を決めない | 便利機能が増え、納期と範囲が膨らむ | 今回作らないものを明記する |
| 仮定を確定事項として扱う | 後から仕様変更として発覚する | 決定・未決・仮定を分ける |
| 文書を長くしすぎる | 重要なルールが読みにくくなる | 要件定義書と共通ルールを分離する |
| 計画を確認せず編集する | 変更範囲やテスト漏れに気づけない | Plan Modeで差分を確認する |
特に非機能要件と対象外は後回しにされがちです。速度、ログ、権限、バックアップ、エラー時の案内は、画面完成後に変えると影響が広がります。未決事項には期限と判断者を記録し、実装開始の条件を決めておきましょう。
まとめ
Claude Codeでは、最初に質問だけを依頼し、目的、利用者、要件、制約、対象外、受け入れ条件を整理します。決定事項は requirements.md に残し、共通ルールは CLAUDE.md に分けます。最後にPlan Modeで変更範囲とテストを確認してから実装へ進めば、手戻りを抑えられます。
