この記事では、生成AIを活用した要件定義書の作成において、なぜ期待する結果が得られにくいのか、そしてその改善方法について解説します。特に「プロンプト設計」をキーワードに、実践的かつすぐに使えるテクニックをご紹介します。ぜひ明日からの業務に取り入れてみてください。
1. 導入: 生成AIの普及と課題🎯
1.1 生成AIが変える要件定義書作成
ChatGPTなどの生成AIを活用して要件定義書を作成するケースは増えています。
- 利点: 短時間で大枠のドキュメントを作成でき、効率アップ
- 課題: 曖昧または不適切なプロンプトにより、期待はずれの結果になることが多い
1.2 「なぜ多くの人が成果を得られていないのか？」
要件定義書はプロジェクトの最上流工程にあたり、**「正確さ」「網羅性」「具体性」**が必須です。しかし、
- 必要な背景情報を十分に伝えていない
- 何をどこまでアウトプットしてほしいかが曖昧
- 出力を手直しするためのプロセスが組み込まれていない
などの理由で、AIが本領を発揮できていません。
2. よくある失敗例（アンチパターン）⚠️
ここでは、実際によくある“生成AIに依頼した要件定義書が期待外れになってしまう”ケースを整理します。
2.1 前提情報（コンテキスト）の不足
-
例: 「機能一覧は欲しいが、既存の業務フローやどの部門が利用するか、運用ルールなどを曖昧にしか伝えていない」
- 口頭で「大きめの受発注管理システムがあって、外部サービス連携も必要」とだけ説明し、AIに詳細な要件定義書を作らせようとする
-
起こりうる結果:
- システム背景が曖昧なため、AIの回答も抽象的な提案になりがち
- 本来必要なステップ（例: 外部サービス認証の流れや既存在庫DBとの同期要件など）が欠落
❌ アンチパターン
「受発注管理システムを作りたいので要件定義書を作ってください」
(業務フローや利用部署、既存システムの仕様を提示していない)
✅ 回避策
- 「売上や在庫を管理する既存システムがあり、API連携でデータを同期する必要がある」など、周辺システム・業務ルール・利用部署を明示
- 必要に応じて、**運用ルール（例: 発注承認フロー、請求サイクル、返品処理など）**を箇条書きで示す
2.2 出力形式の曖昧さ
- 例: AIに「要件定義書を作ってほしい」と伝えているが、どの程度の粒度や構成が必要か指定していない
-
起こりうる結果:
- 章立てや見出しが不明確で、読みにくい長文がダラダラ出力される
- 要件定義書というより、ただの一般的な説明文になってしまい、再利用しづらい
❌ アンチパターン
「システムの要件を一覧で出してほしい」
(どのような形式か指定していない)
- AIが「要件リスト」を出してくるが、粒度がバラバラだったり、重複や抜け漏れが混在
✅ 回避策
- **「ユースケース一覧 → 機能一覧 → 非機能要件 → 制約事項」**など、出力フォーマットを事前に指定
- 「見出し」「箇条書き」「表形式」などの具体的な構成例を示す
2.3 複数の制約・要望の整合性が取れていない
-
例: セキュリティ要件、予算制約、技術スタックなどの要望を並列で伝えた結果、相互に矛盾してしまう
- 「オンプレ環境で冗長構成にしたいが、予算は極力削減したい」など
-
起こりうる結果:
- AIが「すべてを満たす理想」を追いかけたフワフワした提案をしてしまう
- 実情とかけ離れた要件に仕上がり、結局使えない
❌ アンチパターン
AWSやAzureなどのクラウドを使いたい。
でもオンプレでしか運用できない制約もある。
セキュリティも最高レベルを目指したい。
予算は限りなく少なく…。
- 整合性を取るための優先度やトレードオフを伝えていない
✅ 回避策
- 事前に優先順位（例: セキュリティ > コスト > 操作性）をはっきり指定
- トレードオフ検討をAIに指示し、各要件の妥協点や推奨案を提案させる
2.4 要件定義の「焦点」が定まっていない
-
例: 「新サービスの要件をまとめたいが、UIデザインやビジネススキーム、将来的な機能拡張の構想まで一括でお願い」と、あらゆる領域を一度に依頼してしまう
- 仕様レベルで決定すべき部分と、まだ未確定の事業アイデアが混ざり合った状態
-
起こりうる結果:
- ビジネスアイデアやUIデザイン案などが盛り込まれ、実際の開発フェーズに必要な情報が薄まってしまう
- 要件が広範囲にわたるため、優先度や予算配分などの軸が不明確になり、結局「どこから実装するの？」となる
❌ アンチパターン
「新サービスでやりたいこと全部まとめて！UIの参考案とか将来のマーケ戦略も」
(要件とアイデア、ビジネスプランが混在)
✅ 回避策
- 「今回は機能要件と非機能要件を中心にまとめたい。UIデザインや長期ビジョンは次のフェーズで検討する」など、スコープとゴールを明確化
- 要望が多岐にわたる場合は、フェーズを分割し、優先度と実装タイミングを分けて定義
3. 効果的なプロンプト設計の原則💡
これまでのアンチパターンを回避するためには、以下の3つの原則が重要です。
-
具体性
- 「誰が」「何を」「どのように」「なぜ」の視点でプロンプトを作成
-
出力フォーマットの明示
- 「見出し」「箇条書き」「項目名」など、構成をあらかじめ指定
-
背景情報の提供
- 業務フロー、技術スタック、対象ユーザー、既存システムとの連携など
4. 実践的なプロンプト例🎯
以下では、ユースケース・機能一覧・非機能要件をしっかりカバーするための具体的なプロンプト例を紹介します。加えて、画面イメージ（ワイヤーフレーム）などをマルチモーダル入力として活用する方法も提示します。
4.1 ユースケース重視のプロンプト例（詳細版）
あなたはシステムアーキテクトです。次の情報をもとに、ユーザーがシステムを利用する際の「ユースケース詳細」を作成してください。
【システム概要】
- オンライン学習サービス
- ユーザー（受講者）が講座を検索・受講し、学習履歴を管理できる
- 講師が講座を登録し、受講者への連絡を行う機能も含む
【ユースケースに関する追加情報】
- 作成したいユースケース: 「受講者が講座を検索して受講を申し込む」
- 業務フロー例:
1. 受講者がログインし、講座検索画面を開く
2. カテゴリやキーワードで講座を検索
3. 検索結果一覧から受講したい講座を選択
4. 講座詳細画面で「受講申し込み」ボタンを押下
5. システムが申し込み可否を判定（定員状況など）
6. 申し込み完了後、通知メールを受講者に送付
- 前提条件:
- 受講者は事前に会員登録済み
- 講座が「公開」ステータスの場合のみ受講可能
- 主な例外・代替フロー:
- (例外1) 定員に達している場合: 申し込み不可メッセージ表示
- (例外2) 未ログインの場合: ログイン画面にリダイレクト
- 事後条件:
- 受講者の学習履歴に講座受講申し込みが登録される
- データ項目例:
- 講座ID、受講者ID、申し込み日時、申し込みステータス
【出力フォーマット】
1. ユースケース名
2. アクター（主アクター、サポートアクター）
3. トリガー、前提条件
4. 主成功シナリオ（通常フロー）
5. 代替フロー / 例外処理
6. 事後条件
7. 関連する機能要件・非機能要件（あれば）
【注意点】
- 上記の業務フローやデータ項目例を必ず反映してください
- 講座管理や通知メール送信など、バックエンド処理に関する補足があれば記載してください
4.2 機能一覧重視のプロンプト例
あなたはシステムアーキテクトです。以下の情報に基づいて、機能一覧を明確に定義してください。
【システム概要】
- 中古車の売買を行うマッチングプラットフォーム
- 主なアクター: 購入希望ユーザー、車両出品者、運営管理者
【事前情報】
- 購入希望ユーザー: 事前に住所や支払い方法を登録する必要がある
- 車両出品者: 出品時に車両写真や走行距離、年式などを入力
- 運営管理者: ユーザーアカウント管理、トラブル対応、出品審査を行う
【要望・目的】
- システム全体の機能を洗い出し、優先度や関連度を可視化
- 機能の粒度を具体的に（ユーザー登録、車両登録、チャット機能、入金確認など）
【出力フォーマット】
1. 機能一覧
- 機能名
- 機能概要
- 利用アクター
- 関連するユースケース（あれば）
- 依存関係や前提条件
2. 機能ごとの優先度 (High / Medium / Low)
3. 機能間の関連性を示す補足説明
【注意点】
- 運営管理者向け機能（出品審査、トラブル対応など）を必ず含む
- 車両登録→出品審査→公開、購入申込→チャット機能→入金確認など、機能同士の連携順序がわかるようにしてください
4.3 非機能要件重視のプロンプト例
あなたは信頼性と拡張性を重視するシステムアーキテクトです。以下の情報をもとに、非機能要件を整理してください。
【システム概要】
- 大規模な物流管理システム（倉庫内在庫、配送情報、入出荷記録などを統合管理）
- 同時接続ユーザー数: 平均1000人、ピーク時3000人
- 24時間365日の運用必須
【詳細情報】
- APIレスポンスタイム: 通常0.5秒、ピーク時でも1秒以内
- ダウンタイム: 月あたり1時間以内に抑えたい
- セキュリティ要件: 監査ログ3年間保存、SSL/TLS通信必須、RBAC導入
- 保守性: マイクロサービス化を検討中、将来的に海外拠点増設も予定
【出力フォーマット】
1. 非機能要件一覧（項目別に箇条書き）
2. 各要件の具体的な指標・数値目標
3. アーキテクチャ上の考慮点（フェイルオーバー、クラウド設計など）
【注意点】
- ピーク時負荷への対応策を具体的に提示（例: オートスケーリング、負荷分散）
- 将来拡張（新拠点、海外など）を念頭においたアーキテクチャ戦略を提案
4.4 画像（ワイヤーフレーム等）をマルチモーダル入力として活用する例
【タスク】
以下のワイヤーフレーム画像を解析し、画面要件を抽出してください。
- 画像URL: https://example.com/wireframe.png
【具体的な依頼内容】
1. 画面内に含まれるUIパーツやボタン名、テキスト項目を箇条書きで列挙
2. 各UIパーツの機能概要やデータ項目との関連性を説明
3. 上記情報を元に、画面要件として整理してください
【注意点】
- 可能であれば、画面遷移の想定も含めてください
- 文字が読みづらい部分は推測で構いませんが、不明箇所は「不明」と記載してください
5. プロンプト設計の黄金ルール✨
5.1 チェックリストで抜け漏れを防ぐ
-
目的を明確にする
- どんなドキュメントを作りたいか（ユースケース、機能一覧、非機能要件、画面要件など）
-
前提条件を網羅する
- 業務フロー、ユーザー特性、既存システムや連携先
-
出力形式を指示する
- 見出し、箇条書き、表など、期待する構成を具体的に指定
-
追加・除外したい内容を記載する
- 例: 「セキュリティ要件は必須」「UI案は不要」「不明箇所は明示して」など
-
優先度やトレードオフを明示する
- 例: セキュリティ > コスト > スピード など
-
仮説検証と修正を前提にする
- AIの出力をレビューし、再度プロンプトをブラッシュアップ
5.2 生成AIに「プロンプトを作らせる」のもアリ
5.2.1 具体的なプロンプト例（ユースケース作成用）
以下は、「ユースケース」を作ってもらうためのプロンプト雛形をAIに提案してもらう例です。
あなたは要件定義書作成のスペシャリストです。
私は新しい顧客管理（CRM）システムにおける「お問い合わせ管理」のユースケースを、生成AIに書かせたいと考えています。
【前提情報】
- 顧客からのお問い合わせをメール、チャット、電話で受け付け
- サポート担当者が対応状況を管理できる
- 一定期間で問い合わせ履歴を自動アーカイブ
- セキュリティ上、個人情報は暗号化必須
【依頼内容】
上記を踏まえ、以下の点を網羅できる「プロンプト雛形」を提案してください。
1. ユースケース名、主アクター、サポートアクター、トリガー、前提条件、主成功シナリオ、代替フローなどを構造化
2. 対応ステータス（受付中、対応中、解決済み）の切り替えフローを含める
3. 個人情報保護の観点を含むセキュリティ要件を考慮する
【希望形式】
- 箇条書きまたはMarkdown形式で、どのようにAIに依頼すれば良いかを解説してください
5.2.2 効果的に作ってもらうコツ
- 作りたい成果物（ユースケース、非機能要件リストなど）をあらかじめ限定し、深堀りする
- 必要な要素（アクター、データ項目、セキュリティ要件など）を具体的に列挙する
- 「抜け漏れのないユースケースを作りたい」「セキュリティ要件を確実に含めたい」などの目的・条件を明文化する
6. 事前コンテキストの登録で精度UP
最近のChatGPTやClaudeなどの生成AIプラットフォームには、プロジェクト作成機能や事前コンテキストの登録が可能なケースがあります。たとえば、プロジェクト単位で以下のような設定を保存しておくと、毎回のプロンプトに冗長な情報を繰り返し書かなくても済み、より正確な結果を得られます。
6.1 事前コンテキスト登録の活用例
-
プロジェクト設定
- システム名: 「グローバルECサイト」
- 対象ユーザー: 北米・欧州・アジア向け
- 決済手段: クレジットカード、PayPal、Alipay
- 非機能要件: 平均応答時間1秒以内、99.9%稼働など
-
既存システム連携情報
- 在庫管理API仕様、商品データベースの構成など
- 認証基盤（SSO）についての説明
-
プロジェクトのフェーズ
- 現在は要件定義フェーズで、デザインやテストは次フェーズ
これらを事前登録しておくことで、新しいプロンプトを投げる際も「対象ユーザー」や「想定システム規模」を繰り返し書かなくてもAIが把握し、一貫性のある出力を得ることができます。
7. まとめと次のステップ📌
7.1 まとめポイント
- 生成AIの出力が期待はずれになる原因は、**「詳細コンテキスト不足」「出力形式の曖昧さ」「矛盾要件の整理不足」「焦点のズレ」**などが主
- ユースケース作成時には具体的な業務フローやデータ項目、例外ケースを明示することで、精度が格段に向上
- 画像（ワイヤーフレーム）をマルチモーダル入力として活用したり、**「プロンプトを作るためのプロンプト」**をAIに提案させるメタ手法も有効
- さらに、プロジェクト作成機能や事前コンテキストの登録を活用すると、やり取りがスムーズになり、出力の一貫性が増す
7.2 次のステップ
- プロンプトの再構築: まずは自プロジェクトで必要な背景情報を洗い出し、細かい指示やフォーマットをしっかり書いたプロンプトを作ってみましょう。
- AI出力の検証: 出力された要件定義書をチームでレビューし、誤りや不足を洗い出したうえで再プロンプト（フィードバック）を実施。
- プロジェクト作成機能の活用: GPTやClaudeなどの事前コンテキスト登録を活用し、使い回せる情報はプロジェクト設定にまとめましょう。
- 継続的なプロンプト改善: プロジェクトごとにベストプラクティスを蓄積し、「どのように依頼すれば高品質な要件定義書が得られるか」をチームで共有。
以上が、より実践的なアンチパターンの解説と、事前コンテキスト登録による精度向上、「ユースケースを作るためのプロンプト雛形」をAIに作らせる例を盛り込んだ最終版記事です。ぜひ、明日からの要件定義やドキュメント作成でお役立てください。きっとプロジェクトを加速させる一助となるはずです。