生成AIを活用した要件定義書作成：失敗を防ぐ実践＆プロジェクトコンテキスト活用ガイド

0. はじめに

0.1 背景・目的

要件定義書はシステム開発の全体像を示す重要ドキュメントですが、情報不足や曖昧な指示によって手戻りが増え、プロジェクトコストが膨れ上がるリスクを抱えています。

ChatGPTやClaudeなどの生成AIを活用すれば、短時間で要件のたたき台を作成・更新できるメリットがありますが、プロンプト（AIへの指示）の設計が甘いと抽象的な出力や実務にそぐわない内容が増え、結局は修正工数が大きくなりかねません。

本記事では、**AIに要件定義書を作らせる際の失敗例（アンチパターン）と、その回避策としての「詳細プロンプト」「フェーズ分割」「レビュー＆再プロンプト」**の方法を解説します。
さらに、ビフォーアフター例として、曖昧依頼（ビフォー）vs.詳細依頼（アフター）の違いを複数視点（ユースケース・機能一覧・非機能要件）で示し、「こう書くとこんな問題が起きる」「こう直せば解決」という流れを具体的に見せます。
加えて、**プロジェクト機能（事前コンテキスト）**の活用で、繰り返し長い背景を書かなくてもAIが一貫した情報を保持できる利点にも触れます。

---

1. よくある失敗例（アンチパターン）

1.1 前提情報（コンテキスト）の不足

• 例: 「受発注システムが欲しいからAIに依頼。要件定義書を作ってもらったら、抽象的な文書しか出てこない…」
• なぜ問題か？
  • 業務フローや部署別ルールが不明 → AIは一般的な受発注システムの話しかしない
  • 例えば「夜間23:00～翌3:00は在庫DBがロックされて更新不可」という重要ルールがないと、手戻りが大量発生
• 回避策:
  • 事前に業務フロー図や在庫DBのSKU数(例:3万)・夜間バッチ時間をまとめて伝える
  • プロジェクト機能で部署名や運用時間をコンテキストに登録 → 毎回詳しく書かなくてもAIが把握する

1.2 出力形式の曖昧さ

• 例: 「AIに要件定義書を作ってとだけ言ったら、章立てもなく、長文だらだら…」
• なぜ問題か？
  • ユースケースと非機能要件が混在するなど、レビュー・再利用が難しい
  • 後から人間が「これを機能一覧っぽくまとめ直すか…」と膨大な整理作業
• 回避策:
  • 「1. 機能一覧、2. ユースケース、3. 非機能要件、4. 制約事項」など形式を具体的に提示
  • ExcelやMarkdown表の使用を指示 → 読みやすい結果が得やすい

1.3 矛盾する制約や要望の混在

• 例: 「オンプレ必須、でもAWSをフル活用、セキュリティ最優先だけどコストは削減…」
• なぜ問題か？
  • AIは“すべてを盛り込む理想案”を書きがち→ 実際の現場では実現不能または予算オーバー
• 回避策:
  • 優先順位をはっきり提示（セキュリティ＞可用性＞コストなど）
  • 複数案をAIに出させ、どれを採用するかはチームで合意

1.4 要件定義の範囲が広すぎる

• 例: 「UIデザインやマーケ戦略、将来拡張も全部まとめて」
• なぜ問題か？
  • コア機能要件とアイデア段階の構想がごっちゃに → どこが今すぐ必要か不明
  • フェーズを分けないと、手戻りや混乱が多発
• 回避策:
  • 「今回は機能＆非機能要件のみ」とスコープを割り切る
  • ビジョンや拡張は別ドキュメントにし、後で再依頼

---

2. 効果的なプロンプト設計の原則

2.1 具体性

• 数値（1日100件、ピーク時30件/時、ログ保持3年）・部署名（Sales部10名、Inspection部5名）・API認証方式（APIキー、OAuth2など）を明示
• AIが抽象論を避け、実際の運用に近いドキュメントを作りやすくなる

2.2 出力フォーマットの明示

• 例:

  1. ユースケース一覧
  2. 機能一覧(表)
  3. 非機能要件(箇条書き)
  4. 制約事項
  

• 指示がないと散文にされてしまう → レビュー工数が増大

2.3 背景情報の提供

• 既存システム運用（夜間バッチ、オンプレ/クラウド制限など）
• 数字があるほど、「レスポンスタイムは1秒以内を希望」「車両DBは3万SKU」などリアリティが増す

---

3. フェーズ別導入（段階的アプローチ）

3.1 フェーズ1：機能一覧

• 目的: 大枠の機能、優先度、依存関係を把握
• プロンプト例:

  まずは機能一覧を表形式でまとめて。列は「機能名,概要,利用部署,優先度,依存関係」。
  Sales部(10名)、Inspection部(5名)が平日9～18時利用。...
  

• チェックポイント: 抜け漏れ（API連携機能は書かれているか？）と重複（似た機能が2つないか？）

3.2 フェーズ2：ユースケース・詳細フロー

• 目的: 「誰がどの順序で何をし、どんなデータ項目を扱うか」具体化
• プロンプト例:

  機能一覧に基づき、ユースケースを作って。
  1. ユースケース名
  2. アクター
  3. 前提条件
  ...
  

• チェックポイント: 例外フローや承認フロー、VINなど必須データ項目をカバー

3.3 フェーズ3：非機能要件・制約事項

• 目的: 可用性、性能、セキュリティ、運用など数値指標
• プロンプト例:

  非機能要件を整理して。可用性99.9％, レスポンスタイム1秒以内, ログ保持3年, 初年度予算3000万円
  

• チェックポイント: 実現性（オンプレで冗長化するにはサーバーが何台必要か、予算は足りるか）

---

4. ビフォーアフター形式の具体例

4.1 ビフォー部分に“なぜ問題か”の補足

ここでは、ビフォーを短く書きすぎるとAIはどう答えるかと、それがなぜ問題を引き起こすのかを補足説明します。

4.1.1 ユースケース定義（ビフォー）

「中古車マッチングプラットフォームのユースケースを作ってください。
出品者が車を出品して、購入希望ユーザーが申し込むシナリオをお願いします。」

• 想定AI出力（例）:
  • 「1) 出品者が車両登録 2) 購入希望ユーザーが申し込み 3) システム承認 4)完了」程度の大まかなフロー
• なぜ問題か？
  1. 部署名が不明: Sales部？ Inspection部？ 何人がどのように承認？ → 後から大幅な書き直し
  2. API連携が欠落: CarFaxなどの車両履歴照会が必要なのに書かれない → 運用で使えない
  3. 例外・データ項目が不足: VIN管理やキャンセル時の処理が書かれず、後工程で想定外の修正

4.1.2 ユースケース定義（アフター）

あなたは要件定義のスペシャリストです。

【システム名】
- 中古車マッチングサイト「CarTrade Plus」

【ユースケース名】
- Sales部が購入申し込みを承認→Inspection部へ検査依頼

【前提情報】
- アクター: Sales部(10名), Inspection部(5名), 出品者, 購入希望ユーザー
- 1日平均100件、ピーク時30件/時
- CarFax MockAPIでVIN照会(修理歴・走行距離)
- 同時接続上限50ユーザー

【依頼内容】
1. ユースケース名
2. アクター
3. 前提条件
4. 主成功シナリオ
5. 代替/例外フロー
6. 利用データ項目
7. 事後条件

• メリット:
  • データ項目（VINなど）や数値（100件/日、30件/時）→ 実務寄り
  • 車両検査APIを忘れにくい
  • 後で人間が修正しやすく、手戻りが少ない

---

4.2 機能一覧（ビフォー）

「中古車売買システムの機能一覧を作ってください」

• 想定AI出力:
  • 「車両登録, 検索, 申し込み, チャット, 支払い」など漠然とした羅列
• なぜ問題か？
  1. 優先度が分からない: どれがHigh？ どれが後回し？ → プロジェクト計画が立てにくい
  2. 誰が使う機能か不明: Sales部？ 外部ユーザー？ → 開発範囲が混乱
  3. 依存関係の明示なし: 「在庫DBがなければ検索できない」「検査APIがなければ検査依頼できない」といった情報を見落とし

4.3 機能一覧（アフター）

あなたはシステムアーキテクトです。
以下の項目で機能一覧を表形式にまとめてください：
(1) 機能名
(2) 概要
(3) 利用部署
(4) 優先度(High/Med/Low)
(5) 依存関係

Sales部(10名), Inspection部(5名)が平日9～18時利用。1日平均100件、ピーク時30件/時の申し込み。

• メリット:
  • 表の例:

    機能名	概要	利用部署	優先度	依存関係
    車両検索	購入ユーザーが車両を検索	購入希望ユーザー	High	在庫DB
    申し込み	購入希望ユーザーが申し込む	購入希望ユーザー,S部	High	ユーザーDB
    検査依頼	Sales部→Inspection部依頼	Sales部, Inspection部	Med	検査API

  • 改訂時、「検査依頼機能の優先度をHighに変更」など短い依頼で要件を更新可能

---

4.4 非機能要件（ビフォー）

「中古車システムの非機能要件をお願いします。」

• 想定AI出力:
  • 「可用性を確保する。セキュリティに気をつける。レスポンスをなるべく速く…」など抽象的
• なぜ問題か？
  1. 数値目標がない: 99.9％稼働なのか？ 90％なのか？ レスポンスタイム1秒以内なのか？
  2. 運用時間や障害時対応が書かれない → 実際に運用してみると大きな手戻り

4.5 非機能要件（アフター）

あなたはシステムアーキテクトです。

【システム背景】
- CarTrade Plus: 1日100件,ピーク時30件/時, Sales部(10名)平日9～18時集中
- ログ保持3年、可用性99.9％以上、障害2h以内復旧
- 初年度予算3000万円

【依頼内容】
非機能要件を以下でまとめて：
1. 可用性(稼働率◯％以上, 障害対応ルール)
2. 性能(レスポンスタイム◯秒以内, 最大同時接続数など)
3. セキュリティ(ログ保持期間,認証方式,監査要件)
4. 運用保守(運用時間帯,バックアップ体制,復旧時間)
5. コスト(予算上限,運用費など)

• メリット:
  • AIは「可用性99.9％, レスポンスタイム平均0.5秒, 夜間バッチがある場合の対応」など運用に則した具体案を出しやすい
  • レビューで「1秒以内は予算的に難しいのでは？」など議論しやすい

---

5. レビュー＆再プロンプトの流れ

5.1 全体プロセス

1. 初回AI出力
   • フェーズ1→2→3で依頼し、要件定義書の下書きを得る
2. チームレビュー
   • セキュリティ(🔒)・DB(🗄️)・API連携(🔗)などアイコン区分で担当を割り振り、抜け漏れ確認
3. 修正点をまとめて再プロンプト
   • 例: 「キャンセル時のステータス変化追加」「検査APIのレスポンスタイム500ms以内と明記」「SKU3万件対応」
4. 改訂版→合意
   • OKなら次フェーズ or 要件定義完了

5.2 プロジェクト機能でコンテキスト保持

詳細解説：

1. 事前コンテキスト登録

   • 例：「CarTrade Plus」プロジェクトを作成し、部署構成(Sales部10名, Inspection部5名)、API情報(検査API,認証キー)、夜間バッチ時間(23～3時)などをAIに一括登録
   • メリット：毎回「Sales部が... Inspection部が... APIは...」と書かなくても、AIが覚えてくれている

2. 簡略プロンプト

   • 「既存機能一覧を使い、チャット機能をHigh優先度に変更して。初年度予算3000万円とSKU3万件を踏まえ、レスポンスタイムの要件も修正」
   • AIはプロジェクトの設定を参照し、新しい要件定義書を一貫した形で再生成

3. 運用のポイント

   • コンテキスト上限に注意し、重要項目（部署数・SKU数・バッチ時間など）を厳選
   • 法規制やログ保持などの機密情報を登録する際は、セキュリティポリシーを確認

---

6. まとめと今後のステップ

6.1 主要ポイント

1. アンチパターン
   • 前提情報不足, 出力形式あいまい, 矛盾要望の放置, スコープ過大
2. 詳細プロンプト設計
   • 数値や部署など具体性, 章立て指示, 背景情報を整える
3. フェーズ分割
   • 機能一覧→ユースケース→非機能要件で手戻りを削減
4. ビフォーアフター例
   • 曖昧依頼だと抽象的, 詳細依頼だと運用向き → 差は非常に大きい
5. プロジェクト機能
   • 事前コンテキスト登録で、毎回長い依頼をしなくてもAIが覚えてくれる → 短いプロンプトでドキュメント更新OK

6.2 今後のアクションプラン

1. プロンプト再点検
   • 曖昧依頼をしていないか？ 部署数や在庫SKU数、レスポンスタイム指標など盛り込んでいるか？
2. フェーズ計画立案
   • いつ機能一覧を確定し、いつユースケースを詳細化、いつ非機能要件で最終合意するか
3. レビュー体制整備
   • 🔒セキュリティ、🗄️DB、🔗API担当を明確化。アイコンで役割区分
4. プロジェクト機能の活用
   • 事前に背景情報を登録 → 短いプロンプトでも一貫性のある要件定義書を出力してもらう

🍀ヒント：

• 数値例（SKU3万、1日100件、ピーク時30件/hなど）は各プロジェクトで変わる → 現場の実態をしっかり洗い出す
• AIが出した要件は人間の最終合意が必要。法規制(医療・金融)や予算・セキュリティを満たすかどうかチームで確認を

---