Claude Codeで要件定義・設計書を作成/効率化する方法【プロンプト例あり】

Claude Codeを使い始め、要件定義や設計書の作成も効率化できたらと考えている人は多いですよね。

要件定義は開発全体の土台となる工程です。ここでAIをうまく使いこなせるかどうかで、仕様整理や設計工程のスピード・品質が大きく変わります。

そこでこの記事では実際のプロンプト例も交え、Claude Codeで要件定義・設計を効率化する方法を解説します。実務で失敗しやすいポイントや注意点も紹介しているので、ぜひ参考にしてください。

Claude Codeの特徴をおさらいしておきたい人は、次の記事を参考にしてください。

Claude Codeで要件定義・設計を行う全体の流れ

Claude Codeで要件定義を進めるには「初期設定→要件整理→仕様書化」という3段階の流れで進めることが重要です。

順番を意識せずにプロンプトを入力すると、出力内容にばらつきが生じ、後から整合性を取り直す手間が発生しやすくなります。

ここからは下記の3つのステップを、順を追って解説します。

プロジェクト初期化とCLAUDE.mdの設定

Claude Codeで要件定義を始める際は、まずCLAUDE.mdと呼ばれるプロジェクト設定ファイルを作成してください。

CLAUDE.mdとは、Claude Codeがプロジェクトの前提条件やルールを読み込むためのMarkdownファイルです。セッション開始時に自動で読み込まれます。ここにプロジェクトの目的・使用技術・制約条件を整理しておくことで、毎回同じ前提を繰り返す手間を減らせます。

たとえば、社内の在庫管理システムを開発する場合は、次のような内容をCLAUDE.mdに記載します。

```
# プロジェクト概要
プロジェクト名：社内在庫管理システム
目的：倉庫スタッフが在庫の入出庫をリアルタイムで管理できるシステムを構築する

# 使用技術
フロントエンド：React 18
バックエンド：Node.js + Express
データベース：PostgreSQL

# コーディング規約
変数名はキャメルケースで統一
コメントは日本語で記載

# 禁止事項
外部APIへの無断通信
本番環境への直接デプロイ
```

CLAUDE.mdを用意してからセッションを開始すると、Claude Codeがプロジェクト前提を理解しやすくなります。設定なしで進める場合、会話ごとに背景説明が必要になり、出力内容にもばらつきが出やすくなります。

最初にCLAUDE.mdを整理しておくことで、その後の指示や修正の手間を減らしやすくなります。

機能・非機能要件の整理ステップ

CLAUDE.mdを作成したら、次は機能要件と非機能要件を分けて整理します。

機能要件とは「システムが何をするか」を定義するものです。一方、非機能要件とは「システムがどのように動作するか」を定義するものです。この2つを混在させると、後の仕様整理や設計書作成が曖昧になりやすくなります。

整理の手順は次の通りです。

1. Claudeに「このシステムで実現したいことを箇条書きで洗い出してほしい」と依頼する
2. 出力された一覧を機能要件と非機能要件に分類するよう追加指示を出す
3. 各要件に優先度（高・中・低）を付けるよう指示します
4. 矛盾や曖昧な表現がないか確認するよう依頼する

在庫管理システムの例で言えば「在庫を登録できる」は機能要件です。一方で「1,000件の同時アクセスに耐えられる」は非機能要件に該当します。

Claudeに分類を任せることで整理速度は向上しますが、業務背景や優先順位を完全に理解できるわけではありません。出力内容に漏れや誤分類が含まれることもあるため、最終判断は必ず人間が行ってください。

仕様書・設計書への展開手順

要件整理が完了したら、次は仕様書・設計書へ展開します。

要件定義の内容をそのまま設計書に流用するのではなく、「詳細化」のプロセスを挟むことが重要です。ここを丁寧に行うことで、後工程での手戻りを減らしやすくなります。

展開の手順は次の通りです。

1. 機能要件をもとに画面一覧・機能一覧を生成する
2. 各機能の入力・処理・出力を定義したユースケース記述を作成する
3. データモデル（テーブル構成やER図の元になる情報）を生成する
4. APIエンドポイント一覧を作成する

Claudeに対しては、次のように出力フォーマットまで指定すると効果的です。

先ほど整理した要件をもとに、画面一覧をMarkdown表形式で出力してください

出力形式を指定しない場合、セッションごとに粒度が変わり、後から統合しにくくなることがあります。

あらかじめフォーマットを固定しておくことで、設計書全体の粒度を揃えやすくなり、レビューや修正の負担も減らしやすくなります。

Claude Codeの要件定義で使えるプロンプト例

Claude Codeで要件定義を進める際に、プロンプトの書き方によって出力品質が大きく変わります。

指示が曖昧な場合、出力内容も抽象的になりやすくなります。要件定義では、目的・対象・出力形式まで明示したうえで依頼することが重要です。

ここからは下記の3つのシーン別に、すぐ使えるプロンプト例を解説します。

機能要件を洗い出すプロンプト

機能要件を整理する際は、システムの目的・対象ユーザー・主要な業務フローをセットで伝えるプロンプトが効果的です。

情報が不足すると、一般的な機能一覧になりやすくなります。具体的な情報を与えるほど、実際の業務に近い要件を整理しやすくなります。

次のプロンプトをベースに、プロジェクトに合わせて書き換えてみてください。

情報が不足している場合、一般的な機能一覧になりやすくなります。具体的な情報を与えるほど、実際の業務に近い要件を整理しやすくなります。

次のプロンプトをベースに、プロジェクト内容に合わせて調整してください。

```
あなたはシステム要件定義の専門家です。
以下の情報をもとに、機能要件を洗い出してください。

【システムの目的】
中小企業の倉庫スタッフが、在庫の入出庫をリアルタイムで記録・管理できるシステムを構築する。

【対象ユーザー】
倉庫スタッフ（PC・スマートフォンを日常的に使うが、ITリテラシーは高くない）
管理者（在庫レポートの確認・ユーザー管理を行う）

【主な業務フロー】
1.商品が入荷したらバーコードをスキャンして入庫登録する
2.出荷指示が来たら出庫処理を行う
3.月末に在庫棚卸しを実施する

【出力形式】
機能名・説明・対象ユーザーの3列でMarkdown表形式にしてください
機能は「在庫管理」「ユーザー管理」「レポート」のカテゴリに分類してください
```

このプロンプトのポイントは「出力形式」を最後に明示している点です。表形式を指定することで、仕様書や設計書へ転記しやすくなり、レビューもしやすくなります。

非機能要件を整理するプロンプト

非機能要件には、パフォーマンス・セキュリティ・可用性など、後から変更コストが高くなりやすい項目が多く含まれます。

とくに上流工程で整理できていない場合、後続工程で大きな改修が発生することもあります。そのため、システムの特性や利用条件（社内利用か外部公開か、ユーザー数の規模など）を明示したうえで依頼することが重要です。

```
あなたはシステムアーキテクトです。
以下の条件をもとに、非機能要件を洗い出してください。

【システム概要】
中小企業（従業員50名）向けの社内在庫管理システム

【利用条件】
同時利用ユーザー数：最大20名
利用時間：平日9:00〜18:00
外部公開：なし（社内ネットワークのみ）

【重視する観点】
パフォーマンス（レスポンスタイム）
セキュリティ（認証・アクセス制御）
可用性（障害時の対応）
保守性（将来の機能追加のしやすさ）

【出力形式】
観点・要件内容・測定基準の3列でMarkdown表形式にしてください
測定基準は数値で表現してください（例：ページ表示は3秒以内）
```

「測定基準は数値で表現してください」という一文が重要です。この指示がない場合「十分なパフォーマンスを確保すること」のような抽象的な表現になりやすくなります。

ユーザーストーリーの生成プロンプト

ユーザーストーリーとは「誰が・何をしたいか・なぜ必要なのか」を短い文章で表現する要件記述の形式です。

「〜として、〜したい。なぜなら〜だから。」という形式で整理することで、要件の背景や目的が明確になります。

次のプロンプトを使うことで、機能要件からユーザーストーリーを生成できます。

```
以下の機能要件一覧をもとに、ユーザーストーリーを生成してください。

【機能要件一覧】
バーコードスキャンによる入庫登録機能
出庫処理機能
在庫残数のリアルタイム表示機能
月次棚卸しレポート出力機能

【ユーザーストーリーのフォーマット】
「[ユーザーの役割]として、[実現したいこと]をしたい。なぜなら[理由・目的]だから。」

【受け入れ条件】
各ユーザーストーリーに、完了を判断するための受け入れ条件を3つ以上追加してください。

【出力形式】
ユーザーストーリーと受け入れ条件をセットにして、Markdown形式で出力してください。
```

受け入れ条件（アクセプタンスクライテリア）まで出力させることで、テスト仕様書や受け入れテスト設計のベースとしても活用しやすくなります。

Claude Codeで使えるプロンプトをより詳しく知りたい人は、次の記事を参考にしてください。

Claude Codeの要件定義を効率化・高精度化する方法

要件定義を効率よく、かつ高精度に進めるには、Claudeにゼロから考えさせるのではなく、既存の情報や対話設計を活用するアプローチが有効です。

現実の業務フローや既存コードを入力として与えたり、セッション設計や出力フォーマットを工夫したりすることで、要件定義の精度を高めやすくなります。

ここからは下記の5つのテクニックを、まとめて解説します。

業務フローのヒアリングを代替する

要件定義では、現場担当者へのヒアリングに多くの時間がかかることがあります。

Claude Codeにヒアリングシートや業務フロー図の内容を入力することで、要件定義のたたき台を短時間で生成できます。

たとえば、現場担当者が書いたメモや手書きのフロー図をテキスト化して貼り付け、次のように指示します。

```
以下の業務フローのメモをもとに、システム化すべき機能を洗い出してください。
現状の手作業で行っている部分を特定し、システム化した場合の機能要件として整理してください。

【業務フローのメモ】
（現場担当者のメモをそのまま貼り付け）

【出力内容】
1.現状の手作業一覧
2.システム化が有効な業務（優先度付き）
3.各業務をシステム化した際の機能要件
```

もちろん、完全なヒアリングの代替ができるわけではありません。ただし、事前に要件のたたき台を作成しておくことで、ヒアリング時間を短縮できます。

現場担当者に「この内容で合っていますか？」と確認する形にすると、ゼロから聞き出すよりも会話が進みやすくなります。

既存コードから要件を逆引きする

リプレース案件や保守・改修プロジェクトでは、既存コードから要件を逆引きする手法が効果的です。

ドキュメントが不足している既存システムでも、コードを分析させることで、現状の仕様や業務ルールを整理できます。

次のプロンプトを使うと、既存コードから要件定義書の素材を生成できます。

```
以下のコードを分析し、このシステムが実現している機能を要件定義書の形式で整理してください。

【分析対象のコード】
（既存コードをここに貼り付け）

【出力内容】
1.このコードが実現している機能の一覧
2.入力・処理・出力の整理
3.想定しているユーザーとユースケース
4.コードから読み取れる制約・ルール
```

長大なコードをまとめて貼り付けるのではなく、機能単位で分割して入力するのがおすすめです。一度に扱う情報量を絞ることで、出力精度を高めやすくなります。

なお、社外に公開できない社内コードを入力する際は、後述するセキュリティ上の注意点を必ず確認してください。

曖昧な表現を排除する指示の出し方

要件定義書では「できるだけ速く」「使いやすい」「十分なセキュリティ」のような曖昧な表現を避けることが重要です。

数値や条件で測定できない要件は、解釈のずれにつながりやすくなります。プロンプト側で明確な記述ルールを指定することで、Claudeの出力品質を安定させやすくなります。

曖昧な表現を排除するための指示例は次の通りです。

```
以下のルールに従って要件を記述してください。

【絶対に使ってはいけない表現】
「できるだけ〜」「なるべく〜」「十分に〜」
「高速に」「使いやすく」「安全に」（数値なし）
「〜等」「〜など」（具体的に列挙すること）

【代わりに使う表現例】
「ページ読み込みは3秒以内」
「パスワードは英数字8文字以上」
「対応ブラウザはChrome・Firefox・Safariの最新版」
```

既存の要件書をClaudeに渡して「曖昧な表現をすべて洗い出し、数値化できる項目は具体化してください」と依頼することも有効です。

対話的に要件を深掘りするセッション設計

一度のプロンプトで完璧な要件を生成しようとするのは、現実的ではありません。

「まず洗い出し→次に優先度付け→最後に詳細化」という段階的な対話設計が、完成度の高い要件定義につながります。

具体的なセッションの流れは次の通りです。

一度のプロンプトで完璧な要件を生成しようとするのは現実的ではありません。

「洗い出し→優先順位付け→詳細化」のように段階的に対話を進めることで、より実務に近い要件定義を整理しやすくなります。

具体的なセッションの流れは次の通りです。

1. 第1ターン：「このシステムで実現したいことを、思いつく限り箇条書きで出してください」と依頼し、要件候補を広く洗い出す
2. 第2ターン：「上記の機能を重要度・実装コストの観点でMoSCoW分析してください」と依頼し、優先順位を整理する
3. 第3ターン：「Must Haveの機能について、詳細な機能要件を記述してください」と依頼し、具体化する
4. 第4ターン：「漏れている観点はありますか？競合システムと比べて不足している機能を指摘してください」と依頼し、網羅性を確認する

MoSCoW分析とは、要件を次の4段階で分類する手法です。

各ターンの出力を確認しながら次の指示を出すことで、方向のずれを早い段階で修正しやすくなります。

出力フォーマットを固定し品質を安定させる

複数のセッションや複数人で要件定義を進める場合、出力フォーマットが統一されていないと後から統合しにくくなります。

プロジェクト開始時にフォーマットテンプレートをCLAUDE.mdに定義しておくことで、アウトプットの粒度や構成を統一しやすくなります。

CLAUDE.mdに追加するフォーマット定義の例を示します。

```
# 出力フォーマット規約

## 機能要件の記述形式
- 機能ID
- 機能名
- 説明
- 対象ユーザー
- 優先度

## 非機能要件の記述形式
- 観点
- 要件内容
- 測定基準
- 根拠

## ユーザーストーリーの記述形式
US-[番号]: [機能名]

ユーザーストーリー:
[ユーザーの役割]として、[実現したいこと]をしたい。なぜなら[理由]だから。

受け入れ条件
[ ] 条件1
[ ] 条件2
```

フォーマットを事前に定義しておくことで、複数人でClaude Codeを利用する場合でも、アウトプット品質をそろえやすくなります。とくにチームでの要件定義や設計書作成で効果的です。

Claude Codeで要件定義・設計する際の注意点

Claude Codeを要件定義に活用する際は、便利さだけでなくリスクも理解したうえで使うことが不可欠です。

とくに情報の取り扱いや出力内容の信頼性については、初心者が見落としやすいポイントがあります。

ここからは下記の注意点を、順を追って解説します。

機密情報・社内情報の取り扱い

Claude Codeに社内の業務フローや既存コードを入力する際は、機密情報の取り扱いについて事前に社内ポリシーを確認することが必須です。

AIツールでは、入力データの取り扱いに関するルールや運用方針が定められています。一方で、企業によっては「顧客情報を外部サービスへ入力してはいけない」などの独自ルールを設けているケースがあります。

安全に使うための具体的な対処法は次の通りです。

とくに医療・金融・法務などの機密性の高い情報を扱う業界では、法規制や契約上の制約が関わるケースもあります。該当する場合は、利用前に法務部門やセキュリティ担当者へ相談しておくと安心です。

出力内容はレビューしてから使う

Claudeが生成した要件定義書や設計書を、そのまま最終成果物として利用するのは避けてください。

AIの出力はあくまで「たたき台」です。最終的な採用判断や品質確認は、人間が行う必要があります。

具体的に確認すべき項目は次の通りです。

とくにClaudeは自然で説得力のある文章を生成する一方で、事実と異なる内容や現実的ではない提案を含む場合があります。見た目は整った要件書でも、実際の運用に当てはめると問題が見つかるケースは少なくありません。

そのため、ステークホルダーへの確認や合意形成は、人間が責任を持って進める必要があります。

抜け漏れは完全には防げない

どれだけ詳細なプロンプトを使っても、Claudeの出力に抜け漏れが発生する可能性はあります。

「AIが出力したから問題ない」と考えて設計を進めると、後工程で重大な仕様漏れが発覚するリスクがあります。

抜け漏れを減らすための対処法は次の通りです。

とくに例外処理や境界値などのエッジケースは、AIだけで十分に洗い出せるとは限りません。

チェックリストやレビュー工程を組み合わせながら、人間主体で品質を担保する運用が必要です。

まとめ

Claude Codeを使った要件定義は、CLAUDE.md設定→要件整理→仕様書化の流れが基本です。

プロンプトは「目的・対象ユーザー・出力形式」をセットで指定すると、仕様書への転用やレビュー効率が高まります。出力はそのまま採用せず、機密情報に注意しながら妥当性や抜け漏れを必ず人間がレビューしてください。

「自動化ツール」ではなく「要件整理を支援するパートナー」として活用することで、質とスピードを両立できます。