この記事では、生成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に作らせる例を盛り込んだ最終版記事です。ぜひ、明日からの要件定義やドキュメント作成でお役立てください。きっとプロジェクトを加速させる一助となるはずです。