📑

生成AIを使った要件定義書作成の改善方法

2024/12/21に公開

この記事では、生成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つの原則が重要です。

  1. 具体性
    • 「誰が」「何を」「どのように」「なぜ」の視点でプロンプトを作成
  2. 出力フォーマットの明示
    • 「見出し」「箇条書き」「項目名」など、構成をあらかじめ指定
  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 チェックリストで抜け漏れを防ぐ

  1. 目的を明確にする
    • どんなドキュメントを作りたいか(ユースケース、機能一覧、非機能要件、画面要件など)
  2. 前提条件を網羅する
    • 業務フロー、ユーザー特性、既存システムや連携先
  3. 出力形式を指示する
    • 見出し、箇条書き、表など、期待する構成を具体的に指定
  4. 追加・除外したい内容を記載する
    • 例: 「セキュリティ要件は必須」「UI案は不要」「不明箇所は明示して」など
  5. 優先度やトレードオフを明示する
    • 例: セキュリティ > コスト > スピード など
  6. 仮説検証と修正を前提にする
    • 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 次のステップ

  1. プロンプトの再構築: まずは自プロジェクトで必要な背景情報を洗い出し、細かい指示やフォーマットをしっかり書いたプロンプトを作ってみましょう。
  2. AI出力の検証: 出力された要件定義書をチームでレビューし、誤りや不足を洗い出したうえで再プロンプト(フィードバック)を実施。
  3. プロジェクト作成機能の活用: GPTやClaudeなどの事前コンテキスト登録を活用し、使い回せる情報はプロジェクト設定にまとめましょう。
  4. 継続的なプロンプト改善: プロジェクトごとにベストプラクティスを蓄積し、「どのように依頼すれば高品質な要件定義書が得られるか」をチームで共有。

以上が、より実践的なアンチパターンの解説と、事前コンテキスト登録による精度向上「ユースケースを作るためのプロンプト雛形」をAIに作らせる例を盛り込んだ最終版記事です。ぜひ、明日からの要件定義やドキュメント作成でお役立てください。きっとプロジェクトを加速させる一助となるはずです。

Discussion