エンジニアがClaudeで要件定義や基本設計をさくさく進める活用術まとめ

Claude

Posted at 2026-03-16

「要件定義って、何から手をつければいいんだろう」「基本設計書を書くたびに、これで合っているのか不安になる……」

そんな悩みを抱えたことはありませんか？コードを書くのは得意でも、要件定義や設計フェーズになると急に手が止まってしまう——そういったエンジニアは、実はとても多いと思います。私自身も、初めて設計を任されたとき、「何をどの粒度で書けばいいのか」がわからず、かなり時間を無駄にした記憶があります。

この記事では、ClaudeをつかってエンジニアがAIに要件定義・基本設計をさくさく進める具体的な活用術を紹介します。プロンプトの例も豊富に掲載しているので、読み終えたあとにはすぐ実践できるはずです。

なぜ要件定義・基本設計でClaudeが役立つのか

そもそも、なぜ設計フェーズこそClaudeが力を発揮するのでしょうか。

コーディングは「正解かどうか」が動作確認でわかりやすいですが、要件定義や基本設計は**「何が抜けているか」「どこが曖昧か」を自分一人では気づきにくい**という特徴があります。経験豊富なレビュアーがいれば指摘してもらえますが、そうでない場合は抜け漏れに気づかないまま進んでしまうことも。

Claudeはそのレビュアー役を担えます。整理の壁打ち、抜け漏れチェック、代替案の提示——こうした作業を、気兼ねなく何度でも依頼できるのが大きなメリットです。

設計フェーズの課題	Claudeで解決できること
何から書けばいいかわからない	構成のひな型・チェックリストを生成してもらえる
抜け漏れが怖い	「この要件で見落としている観点は？」と確認できる
用語・粒度が統一されているか不安	レビューして矛盾・曖昧さを指摘してもらえる
ステークホルダーへの説明資料が必要	わかりやすい言葉への言い換えを手伝ってもらえる
設計の妥当性が自信をもって言えない	トレードオフの整理や代替案の比較ができる

活用術①：要件定義の叩き台をゼロから作る

「白紙から要件定義書を書く」のは、かなり消耗する作業です。でも、Claudeに叩き台を作ってもらうことで、「ゼロから書く」から「修正・肉付けする」作業に変えられます。これだけで心理的なハードルが大きく下がります。

プロンプト例：要件定義のひな型を作る

以下の開発案件について、要件定義書のひな型を作ってください。

【案件概要】
社内向けのタスク管理ツールをWebアプリで開発します。
ユーザーは社員50名、主にプロジェクトの進捗管理に使います。

以下の項目を含む構成にしてください。
・システム概要
・ユーザーとロール
・機能要件（一覧形式）
・非機能要件
・スコープ外の定義

ポイントは、「スコープ外の定義」を明示的に含めること。要件定義での最大の落とし穴のひとつは「やらないことを決めていない」ことで、あとから認識のズレが生まれやすくなります。Claudeに最初からスコープ外の項目を考えさせることで、その抜け漏れを防げます。

プロンプト例：抜け漏れチェック

叩き台ができたら、次は穴を探してもらいましょう。

以下は私が作成した要件定義の草案です。
抜け漏れや曖昧な点、矛盾している箇所を指摘してください。
また、追加で検討すべき非機能要件があれば提案してください。

【要件定義の草案】
（ここに草案を貼り付ける）

「指摘してください」だけでなく、「追加で検討すべき観点も提案して」と添えるのが私のおすすめです。指摘だけでなく、次のアクションまでセットで返してくれます。

エンジニアなら読むべき本を紹介しています。
→記事を読む

活用術②：ユーザーストーリーとユースケースを整理する

要件定義で「機能一覧を書いた」だけで終わっていませんか？機能一覧は「何を作るか」のリストに過ぎず、「誰が・何のために・どう使うか」が抜けると、作ってみたら使いにくいシステムになることがあります。

ユーザーストーリーやユースケースの整理にも、Claudeは力を発揮します。

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

以下のシステム概要をもとに、主要なユーザーストーリーを
「〇〇として、△△したい。なぜなら□□だから。」の形式で10件作成してください。

【システム概要】
プロジェクトマネージャーと一般メンバーが使う社内タスク管理ツール。
タスクの作成・担当者設定・進捗更新・期日管理が主な機能。

ユーザーストーリーの活用ポイント

ユーザーストーリーの役割	具体的な使い方
機能要件の妥当性確認	「このストーリーを満たせるか？」で機能の過不足を点検
受け入れ基準の設定	「どうなったら完了か」をストーリーから逆引きできる
優先度の判断	「どのストーリーが最も重要か」で開発順序を決める
ステークホルダーとの合意	技術用語より伝わりやすく、認識合わせに使いやすい

活用術③：基本設計書の構成と内容を一緒に作る

要件定義が固まったら、次は基本設計です。「基本設計に何を書けばいいか」「どの粒度で書くか」は、経験が少ないうちは特に迷うポイントですよね。

プロンプト例：基本設計書の構成を作る

以下の要件定義をもとに、基本設計書の目次構成を提案してください。
Webアプリ開発（フロントエンド：React、バックエンド：FastAPI）を前提とします。

各章に「何を記載すべきか」の概要も一緒に書いてください。

【要件定義の概要】
（ここに要件定義の概要を貼り付ける）

Claudeが提案する構成をそのまま使う必要はなく、「たたき台として受け取り、自分のプロジェクトに合わせて修正する」という使い方が効果的です。

プロンプト例：データモデルの設計支援

以下の機能要件をもとに、データベースのテーブル設計を考えてください。
各テーブルのカラム、データ型、主キー・外部キーの関係を提案してください。
また、この設計の注意点やトレードオフも教えてください。

【機能要件の抜粋】
・ユーザーはプロジェクトに複数参加できる
・タスクはプロジェクトに紐づく
・タスクには1人の担当者を設定できる
・タスクにはコメントを複数投稿できる

「注意点とトレードオフも教えて」と加えるのがコツです。Claudeは言われた通りに設計するだけでなく、潜在的な問題点まで一緒に考えてくれます。

活用術④：設計書のレビューと品質チェックに使う

設計書が書けたら、提出前に一度Claudeにレビューしてもらうのが習慣になると、品質が安定します。

レビュー依頼のプロンプト例

以下の基本設計書をレビューしてください。
特に以下の観点でチェックをお願いします。

①要件定義との整合性（抜け漏れがないか）
②データモデルの正規化・整合性
③セキュリティ上の懸念点
④スケーラビリティへの配慮
⑤仕様の曖昧さや矛盾

指摘はできるだけ具体的に、修正案もあわせて教えてください。

【基本設計書】
（ここに設計書を貼り付ける）

チェック観点	Claudeが得意なこと
要件との整合性	要件定義と設計書を並べて比較し、抜け漏れを検出
セキュリティ	認証・認可の設計ミス、SQLインジェクションリスクなどを指摘
非機能要件	パフォーマンス・可用性・保守性の観点を補完
言葉の統一	同じ概念に異なる名称が使われていないかを確認

Claudeと進める設計フローの全体像

ここまでの活用術をまとめると、以下のような流れで設計を進められます。

ステップ	Claudeの使い方	アウトプット
①要件の整理	ひな型生成・抜け漏れチェック	要件定義書（草案）
②ユーザー視点の確認	ユーザーストーリーの生成	ストーリー一覧・受け入れ基準
③設計書の構成	目次・記載内容の提案	基本設計書（骨格）
④詳細設計の支援	データモデル・API設計の壁打ち	テーブル定義・API仕様
⑤レビュー	品質チェック・矛盾の指摘	修正済み設計書

各ステップでClaudeを活用することで、「一人で悩む時間」を「Claudeと一緒に考える時間」に変えられます。これが、設計フェーズのスピードと品質を同時に上げる、いちばんシンプルな方法だと思います。

まとめ

要件定義や基本設計は、エンジニアが苦手意識を持ちやすいフェーズです。でも、Claudeをうまく活用すれば、「何から始めるか」「抜け漏れがないか」「この設計で大丈夫か」という不安をかなり減らせます。

大切なのは、Claudeに「正解を出してもらう」のではなく、「一緒に考えてもらう」という姿勢で使うことです。叩き台を作ってもらい、自分で判断・修正する——このサイクルを回すことで、設計のスキル自体も着実に上がっていきます。

まずは次の設計タスクで、今日紹介したプロンプトをひとつ試してみてください。