WAI SYSTEMSのブログ連載、シリーズB（IT・システム開発・プロジェクト管理向け）の第2回です。
前回（第1回）では、要件定義・実装・PMOといった開発現場の各フェーズで、生成AIがどのように使われ始めているのか、その「現在地」を整理しました。今回からは、いよいよ具体的な開発フェーズに踏み込んでいきます。
システム開発において、手戻り（手直し）のコストが最も高くつくのはどのフェーズでしょうか？ 言うまでもなく、「要件定義」および「基本設計」のフェーズです。
実装（コーディング）段階やテスト段階で仕様の抜け漏れや矛盾が発覚すると、手戻り工数は数倍〜数十倍に膨れ上がります。リリース後に発覚すれば、その影響は顧客の業務や信頼にまで及びます。
今回は、生成AI（LLM）を活用して「要件定義・設計フェーズにおける仕様漏れを防ぎ、ドキュメント作成とレビューを高速化・高品質化する手法」について、そのまま使えるプロンプト例を交えて解説します。
1. 上流工程におけるAIの役割は「壁打ち相手」と「抜け漏れ検知器」
要件定義や設計において、AIに「仕様書を全部書いて」と丸投げするのは間違いです。顧客の泥臭い業務プロセスや、言葉になっていない本当のニーズは、AIには分からないからです。
上流工程におけるAIの真の価値は、以下の2点にあります。
- 思考の壁打ち相手（ブレストパートナー）： 提示した要求に対して「他に考慮すべきケースはないか？」と問いを立てさせる
- 抜け漏れ検知器（ネガティブチェック）： 人間が作成した仕様書に対して、エッジケースや例外処理の欠落を指摘させる
エンジニアやPMが頭の中で考えている設計案をAIにぶつけ、AIに「悪魔の弁護人（あえて反対意見や欠点を指摘する役割）」になってもらうことで、設計の品質を大きく高めることができます。
💡 使えるプロンプト例：悪魔の弁護人
あなたは経験豊富なシステムアーキテクトであり、今回は「悪魔の弁護人」役です。
以下の【設計方針】に対して、あえて批判的な立場から問題点を指摘してください。
【指摘してほしい観点】
1. 想定していない利用パターン・例外ケース
2. 将来の機能追加や利用者増加で破綻しそうな点
3. 運用・保守担当者が困りそうな点
【出力形式】
指摘ごとに「懸念点」「起こりうる事象」「確認すべき質問」を記載すること
【設計方針】
（検討中の設計方針を箇条書きで貼り付け）
ポイントは「確認すべき質問」まで出力させることです。AIの指摘をそのまま採用するのではなく、顧客や有識者に確認すべき論点のリストとして活用することで、打ち合わせの質が上がります。
2. 実践①：ヒアリングメモからの「要件定義・機能一覧」構造化
顧客との打ち合わせで取った雑多なヒアリングメモから、要件定義の初期ドラフトを作成する手法です。
💡 使えるプロンプト例：要件の構造化
あなたはITコンサルタントおよび上流工程を担当するシステムエンジニアです。
以下の【ヒアリングメモ】をもとに、システムに必要な機能要件を構造化してリストアップしてください。
【制約条件】
1. 大項目（カテゴリ）、中項目（機能名）、詳細説明、想定されるユーザー権限の表形式で出力すること
2. メモに明記されていないが、一般的なECシステムとして必要不可欠と思われる機能（例：パスワードリセット、ログアウト等）があれば「推測・提案」として別欄に記載すること
3. メモの内容が曖昧で判断できない点は「未決事項」として最後に一覧化すること
【ヒアリングメモ】
（打ち合わせのテキストメモや文字起こしデータを貼り付け）
これにより、手作業で1時間以上かかる機能一覧表の骨組みが数秒〜数十秒で完成し、さらに「提案すべき隠れた要件」まで浮き彫りになります。
出力後に必ずやるべき「ひと手間」
- 「推測・提案」欄は顧客確認用に分ける： AIの推測が混ざったまま要件として確定させないよう、確認待ちの項目として明確に区別します。
- 「未決事項」は次回打ち合わせのアジェンダにする： 曖昧な点がリスト化されるため、次のヒアリングで何を聞くべきかが明確になります。
- 業務用語の定義を揃える： 「顧客」「会員」「ユーザー」など、同じ意味の言葉がばらついていないかを確認し、用語集として整理しておくと後工程の誤解を防げます。
3. 実践②：非機能要件・セキュリティ要件の抜け漏れチェック
要件定義で最も見落とされがちなのが、パフォーマンス、セキュリティ、障害運用などの「非機能要件」です。顧客からは「普通に動けばいい」「セキュリティはしっかり」といった抽象的な要望しか出てこないことが多く、具体化は開発側の役割になります。
そこで、IPA（情報処理推進機構）が公開している非機能要求グレードや、Webアプリケーションの代表的なセキュリティリスクをまとめたOWASP Top 10といった、公的・業界標準の枠組みを観点としてAIに与えるのが効果的です。
💡 使えるプロンプト例：非機能要件のレビュー
以下の【機能概要】を持つWebシステムを構築予定です。
IPAの非機能要求グレードおよび一般的なセキュリティ基準（OWASP Top 10）に基づき、考慮すべき非機能要件と潜在的なリスクをリストアップしてください。
【機能概要】
・会員数：約10万人、月間PV：50万PVの会員制情報配信サイト
・決済機能（クレジットカード・PayPay連携）あり
・管理画面から大量の画像・PDFを一括アップロードする機能あり
【チェックしてほしい観点】
1. セキュリティ（認証、認可、データ暗号化）
2. パフォーマンス・拡張性（スパイクアクセス、ファイル容量）
3. 運用・障害対策（バックアップ、ログ保持期間）
【出力形式】
観点ごとに「要件項目」「推奨される目標値・対策」「顧客に確認すべき事項」を表形式で出力すること
このプロンプトを実行するだけで、インフラ設計やセキュリティ設計で考慮すべきチェックリストの叩き台がすぐに手に入ります。
ただし、AIが提示する「推奨される目標値」（稼働率99.9%、RPO 24時間など）はあくまで一般論です。目標値を上げるほどインフラ費用や運用コストは増えるため、最終的な数値は顧客の予算や業務への影響を踏まえて合意する必要があります。
4. 実践③：設計書・仕様書のAIレビュー（矛盾・曖昧表現の検出）
作成した要件定義書や基本設計書のレビューも、AIが得意とする領域です。人間のレビューは「書かれていること」の確認に偏りがちですが、AIには「書かれていないこと」「記述同士で食い違っていること」を機械的に洗い出させることができます。
💡 使えるプロンプト例：仕様書のセルフレビュー
あなたは品質保証（QA）担当のシニアエンジニアです。
以下の【仕様書】をレビューし、問題点を指摘してください。
【レビュー観点】
1. 矛盾：記述同士で食い違っている箇所
2. 曖昧表現：「適宜」「なるべく」「等」「速やかに」など、解釈が分かれる表現
3. 例外処理の欠落：入力エラー、タイムアウト、二重送信、権限不足時の挙動が未定義の箇所
4. テスト不能な記述：合否判定ができない（数値や条件がない）記述
【出力形式】
「該当箇所（章・項番）」「指摘内容」「修正案」の表形式で出力すること
【仕様書】
（レビュー対象の仕様書テキストを貼り付け）
特に「曖昧表現」と「テスト不能な記述」の検出は効果が大きく、後工程のテスト設計を楽にしてくれます。たとえば「検索結果は速やかに表示する」という記述は、「検索結果は3秒以内に表示する（データ件数10万件時）」のように、検証可能な形に書き換えるきっかけになります。
なお、AIレビューは人間のレビューを置き換えるものではなく、人間がレビューする前の「一次チェック」として位置付けるのがおすすめです。形式的な指摘をAIが先に潰しておくことで、レビュー会議では業務ロジックや設計判断といった本質的な議論に時間を使えるようになります。
5. 実践④：Mermaid / PlantUMLを活用した「図解（UML）」の自動生成
設計書に必要な「シーケンス図」や「ER図（エンティティ・リレーションシップ図）」、「状態遷移図」も、AIを使えばテキストからすぐにコード化できます。テキストで図を記述できるMermaidやPlantUMLといった記法を使います。
例えば、ChatGPTやClaudeに以下のように指示します。
プロンプト： 「ユーザーがログインし、2段階認証を経てマイページを表示するまでの処理フローを、Mermaid.jsのシーケンス図コードで出力してください。」
すると、次のようなコードが出力されます（一例）。
sequenceDiagram
actor User as ユーザー
participant Web as Webアプリ
participant Auth as 認証サーバー
User->>Web: ID・パスワードを入力
Web->>Auth: 認証リクエスト
Auth-->>Web: 認証OK（2段階認証が必要）
Web-->>User: ワンタイムコード入力画面
User->>Web: ワンタイムコードを入力
Web->>Auth: コード検証
Auth-->>Web: 検証OK
Web-->>User: マイページを表示
生成されたコードをNotionやGitHub、Mermaid対応のMarkdownエディタに貼り付けるだけで、シーケンス図が描画されます。図形ツールで矢印を1本ずつ引く作業から解放されるうえ、図がテキストで管理されるため、Gitでの差分管理や修正も容易になります。
さらに一歩進めて、「このシーケンス図に、認証失敗が3回続いた場合とワンタイムコードの有効期限切れの場合の分岐を追加して」と依頼すれば、異常系フローの考慮漏れチェックにも使えます。
6. 上流工程でAIを使う際のガバナンスと注意点
要件定義・設計フェーズでAIを活用する際は、以下のリスク管理が必須です。
- 顧客の機密情報・個人情報のマスキング： ヒアリングメモをAIに入力する際は、顧客の社名、担当者名、具体的な売上データやパスワード情報などを「A社」「〇〇様」といったダミー文字に置き換えてから投入してください。
- 入力データが学習に使われない環境を使う： 法人向けプランやAPI経由の利用など、入力内容がAIの学習に利用されない設定・契約になっているツールを選びましょう。個人情報の取り扱いについては、個人情報保護委員会の「生成AIサービスの利用に関する注意喚起等について」も参考になります。
- 「AIの提案」をそのまま顧客要件にしない： AIが提示した「あった方が良い機能」を安易に要件に盛り込むと、スコープクリープ（要件の際限ない肥大化）につながります。必ず「今回のフェーズの予算・納期に収まるか」を人間が判断してください。
- AIの出力を鵜呑みにしない： AIはもっともらしい誤り（ハルシネーション）を出力することがあります。法令や外部サービスの仕様に関わる記述は、必ず一次情報で裏付けを取ってください。
AIに入力してよい情報の線引きについては、第1回のガバナンスの章もあわせてご覧ください。また、なぜ人はAIの回答を信じてしまうのか、という根本的な話は【第0回】40年前の「コンピュータ占い」から何も変わっていない説で取り上げています。
7. まとめ：上流工程の品質向上こそが、最大のコスト削減
システム開発における最大のコスト削減は、コーディングを速くすることではなく、「設計の不備による手戻りを限りなくゼロに近づけること」です。
今回ご紹介した活用法を振り返ると、次のとおりです。
- 悪魔の弁護人として、設計方針の弱点と確認すべき質問を洗い出す
- ヒアリングメモから機能一覧と未決事項を構造化する
- 非機能要求グレードやOWASPを観点に、非機能要件の抜け漏れをチェックする
- 仕様書の矛盾・曖昧表現・テスト不能な記述を一次チェックする
- シーケンス図などのUMLをテキストから生成し、異常系の検討にも活用する
要件定義や設計の段階でAIを「思考のパートナー」として活用し、あらゆる角度から抜け漏れや矛盾をチェックしておくこと。これこそが、納期の遵守と高品質なシステム構築を実現する最短ルートです。
次回（第3回）は、エンジニアの関心が最も高い「実装・テスト編」です。「GitHub CopilotなどのAIを活用したコーディング補助と、品質を高めるテスト自動化」について詳しく解説します！
WAI SYSTEMSでは、要件定義からのシステム開発や、AI活用を含めたITコンサルティングのご相談を承っています。「要件がまとまっていないけれど、まずは相談したい」という段階でもお気軽にお問い合わせください。
