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

この記事では、生成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 ユースケース重視のプロンプト例（詳細版）

```markdown
あなたはシステムアーキテクトです。次の情報をもとに、ユーザーがシステムを利用する際の「ユースケース詳細」を作成してください。

【システム概要】
- オンライン学習サービス
- ユーザー（受講者）が講座を検索・受講し、学習履歴を管理できる
- 講師が講座を登録し、受講者への連絡を行う機能も含む

【ユースケースに関する追加情報】
- 作成したいユースケース: 「受講者が講座を検索して受講を申し込む」
- 業務フロー例:
  1. 受講者がログインし、講座検索画面を開く
  2. カテゴリやキーワードで講座を検索
  3. 検索結果一覧から受講したい講座を選択
  4. 講座詳細画面で「受講申し込み」ボタンを押下
  5. システムが申し込み可否を判定（定員状況など）
  6. 申し込み完了後、通知メールを受講者に送付
- 前提条件:
  - 受講者は事前に会員登録済み
  - 講座が「公開」ステータスの場合のみ受講可能
- 主な例外・代替フロー:
  - (例外1) 定員に達している場合: 申し込み不可メッセージ表示
  - (例外2) 未ログインの場合: ログイン画面にリダイレクト
- 事後条件:
  - 受講者の学習履歴に講座受講申し込みが登録される
- データ項目例:
  - 講座ID、受講者ID、申し込み日時、申し込みステータス

【出力フォーマット】
1. ユースケース名
2. アクター（主アクター、サポートアクター）
3. トリガー、前提条件
4. 主成功シナリオ（通常フロー）
5. 代替フロー / 例外処理
6. 事後条件
7. 関連する機能要件・非機能要件（あれば）

【注意点】
- 上記の業務フローやデータ項目例を必ず反映してください
- 講座管理や通知メール送信など、バックエンド処理に関する補足があれば記載してください
```

---

### 4.2 機能一覧重視のプロンプト例

```markdown
あなたはシステムアーキテクトです。以下の情報に基づいて、機能一覧を明確に定義してください。

【システム概要】
- 中古車の売買を行うマッチングプラットフォーム
- 主なアクター: 購入希望ユーザー、車両出品者、運営管理者

【事前情報】
- 購入希望ユーザー: 事前に住所や支払い方法を登録する必要がある
- 車両出品者: 出品時に車両写真や走行距離、年式などを入力
- 運営管理者: ユーザーアカウント管理、トラブル対応、出品審査を行う

【要望・目的】
- システム全体の機能を洗い出し、優先度や関連度を可視化
- 機能の粒度を具体的に（ユーザー登録、車両登録、チャット機能、入金確認など）

【出力フォーマット】
1. 機能一覧
   - 機能名
   - 機能概要
   - 利用アクター
   - 関連するユースケース（あれば）
   - 依存関係や前提条件
2. 機能ごとの優先度 (High / Medium / Low)
3. 機能間の関連性を示す補足説明

【注意点】
- 運営管理者向け機能（出品審査、トラブル対応など）を必ず含む
- 車両登録→出品審査→公開、購入申込→チャット機能→入金確認など、機能同士の連携順序がわかるようにしてください
```

---

### 4.3 非機能要件重視のプロンプト例

```markdown
あなたは信頼性と拡張性を重視するシステムアーキテクトです。以下の情報をもとに、非機能要件を整理してください。

【システム概要】
- 大規模な物流管理システム（倉庫内在庫、配送情報、入出荷記録などを統合管理）
- 同時接続ユーザー数: 平均1000人、ピーク時3000人
- 24時間365日の運用必須

【詳細情報】
- APIレスポンスタイム: 通常0.5秒、ピーク時でも1秒以内
- ダウンタイム: 月あたり1時間以内に抑えたい
- セキュリティ要件: 監査ログ3年間保存、SSL/TLS通信必須、RBAC導入
- 保守性: マイクロサービス化を検討中、将来的に海外拠点増設も予定

【出力フォーマット】
1. 非機能要件一覧（項目別に箇条書き）
2. 各要件の具体的な指標・数値目標
3. アーキテクチャ上の考慮点（フェイルオーバー、クラウド設計など）

【注意点】
- ピーク時負荷への対応策を具体的に提示（例: オートスケーリング、負荷分散）
- 将来拡張（新拠点、海外など）を念頭においたアーキテクチャ戦略を提案
```

---

### 4.4 画像（ワイヤーフレーム等）をマルチモーダル入力として活用する例

```markdown
【タスク】
以下のワイヤーフレーム画像を解析し、画面要件を抽出してください。
- 画像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に提案してもらう例です。

```markdown
あなたは要件定義書作成のスペシャリストです。
私は新しい顧客管理（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に作らせる例**を盛り込んだ最終版記事です。ぜひ、明日からの要件定義やドキュメント作成でお役立てください。きっとプロジェクトを加速させる一助となるはずです。