株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
コンサルティングファームの要件定義書作成をAIで効率化する方法｜ヒアリング記録→LLMで構造化→レビュー支援まで一気通貫
ITコンサルティングにおいて、要件定義書の作成はプロジェクトの成否を決定づける最重要工程です。クライアントの業務課題をヒアリングし、システムで実現すべき機能・非機能要件を構造化し、関係者全員が合意できる文書に仕上げる——この高度なドキュメンテーション業務をLLMで効率化するアプローチが、2025年以降のコンサルティング業界で急速に実用化されています。CoBrainのようなAI要件定義支援ツールの登場や、Fincons GroupのIT企業での実証研究（arxiv 2507.19113）が示すように、LLMは要件仕様書のドラフト生成において人間のアナリストと同等の品質を達成しつつあります。
業務の詳細フロー（現状の手作業）
ステップ1：クライアントヒアリング
クライアントの業務部門・IT部門のキーパーソンに対して、現行業務の課題、システムへの期待、運用上の制約等をヒアリングします。複数回のセッションを通じて、表面的な要望の背後にある「本当の課題」を掘り下げます。
ステップ2：ヒアリング記録の整理
ヒアリングの議事録を整理し、発言内容から要件の種（機能要求、非機能要求、業務ルール、制約条件）を抽出・分類します。発言者の立場による優先度の違いや、矛盾する要求も記録します。
ステップ3：要件の構造化
抽出した要件をカテゴリ別（業務要件、機能要件、非機能要件、データ要件、移行要件等）に構造化します。ユースケース図、データフロー図、画面遷移図等の図表も作成し、要件間の整合性を確認します。
ステップ4：要件定義書の執筆
構造化した要件を正式な要件定義書として執筆します。目的・スコープ→業務要件→機能要件→非機能要件→データ要件→移行要件→運用要件→制約事項の構成で、数十〜数百ページのドキュメントを作成します。
ステップ5：レビュー・合意形成
クライアントの業務部門・IT部門、開発チームとのレビューを複数回実施し、要件の漏れ・矛盾・曖昧さを解消します。最終的にクライアントの承認を得てベースライン化します。
課題・ペインポイント
- ヒアリングから要件への変換の属人化：クライアントの発言から「システム要件」を抽出する能力がコンサルタント個人のスキルに依存し、経験の浅いメンバーでは重要な要件を見落とすリスクがある
- 執筆時間の長さ：1つの要件定義書に数週間〜数ヶ月を要し、プロジェクト全体のタイムラインを圧迫する
- 要件の抜け漏れ：非機能要件（性能、セキュリティ、可用性等）やエッジケースの考慮が不十分になりやすい
- レビューの反復：「この要件は曖昧」「この機能の前提条件が不明」等の指摘が繰り返され、修正サイクルが長期化
- 過去プロジェクトの知見が活用されない：類似の業界・業務で過去に作成した要件定義書の構成や考慮事項が組織的に活用されていない
AI化のアプローチ（LLMによる実装イメージ）
入力データの設計
- ヒアリング記録：クライアントとの打ち合わせ議事録、ヒアリングシートの回答
- 現行システム資料：既存システムの仕様書、画面キャプチャ、業務フロー図
- RFP/提案書：プロジェクトのスコープ・目的を定めた上位文書
- 過去の要件定義書：同業界・同規模プロジェクトの要件定義書（RAGで参照）
- 要件定義テンプレート：自社の要件定義書フォーマット、品質基準チェックリスト
処理パイプライン
- ヒアリング記録の自動分析：LLMが議事録テキストを分析し、発言内容から「機能要求」「非機能要求」「業務ルール」「制約条件」「未確定事項」を自動分類・抽出（出典：CoBrain "要件定義書の作成と添削をAIで"）
- 要件の構造化・整理：抽出した要件をカテゴリ別に構造化し、要件間の依存関係や矛盾を自動検出。過去プロジェクトの要件定義書をRAGで参照し、考慮漏れしやすい観点を補完
- 要件定義書ドラフトの自動生成：LLMが自社のテンプレートに沿った要件定義書のドラフトを自動生成。各要件に対して「受入基準」「優先度」「関連要件」も自動付与
- 品質チェックの自動化：LLMがドラフトに対して「曖昧な表現はないか」「非機能要件は網羅されているか」「矛盾する要件はないか」を自動レビュー（出典：Fincons Group "LLMs for Requirements Specification in IT Consulting"）
- レビュー指摘の自動反映：レビューコメントをLLMに入力し、要件定義書の該当箇所を自動修正。修正履歴と変更理由も自動記録
LLMへの指示（プロンプト設計の考え方）
- 役割設定：「あなたはITコンサルティングファームのシニアコンサルタントです。以下のヒアリング議事録に基づき、要件定義書のドラフトを作成してください」
- 構成指定：「①プロジェクト概要（目的・スコープ・前提条件）、②業務要件（現行業務フロー・改善後フロー・業務ルール）、③機能要件（機能一覧・画面要件・帳票要件・外部連携要件）、④非機能要件（性能・可用性・セキュリティ・運用保守）、⑤データ要件（データモデル・データ移行）、⑥制約事項・リスク・未確定事項の構成で作成してください」
- 品質基準：「各要件は『〜できること』の形式で記述し、テスト可能な受入基準を付与してください。曖昧な表現（適切に、必要に応じて等）は使用しないでください」
人間が判断すべきポイント
- ヒアリングの設計と実施：「誰に何を聞くか」の設計と、対面でのニュアンスの把握はコンサルタントが担う
- 要件の優先度判断：「この機能はMVPに含めるか」「この非機能要件の目標値は妥当か」の判断はクライアントとの合意に基づく人間の意思決定
- ステークホルダー間の利害調整：業務部門とIT部門で要求が矛盾する場合の調整・交渉は対人スキルの領域
- スコープの最終決定：「何をシステム化し、何を業務運用で対応するか」の線引きは経営判断を含む
他業種の類似事例
- 建設業の技術提案書：要求仕様に基づきLLMが提案書ドラフトを構成（本シリーズ参照）
- 製造業の設備仕様書：製造ラインの要件を構造化しLLMが仕様書を自動生成
- コンサルティングファームの提案書（ピッチ資料）：クライアント情報＋過去事例RAGからLLMが提案書ドラフトを生成（本シリーズ参照）
導入ステップと注意点
ステップ1：過去の要件定義書のデータベース構築（2〜4週間）
過去のプロジェクトで作成した要件定義書をベクトルデータベースに格納し、業界別・規模別・システム種別でタグ付けします。特に品質の高い要件定義書を「お手本」として優先登録します。
ステップ2：プロンプト設計・テスト（2〜4週間）
要件定義書の各セクション（業務要件、機能要件、非機能要件等）ごとにプロンプトを設計し、テスト生成を行います。シニアコンサルタントが「このドラフトをベースにクライアントと議論できるか」を評価します（出典：NTTデータ "生成AIを活用したソフトウェア開発の現在地"）。
ステップ3：パイロット運用（4〜8週間）
実際のプロジェクトでAIドラフトと従来プロセスの品質・所要時間を比較します。レビュー回数の削減効果、要件の漏れ率の変化も測定します。
注意点
- クライアント情報の機密性：ヒアリング内容にはクライアントのビジネス戦略や未公開情報が含まれるため、LLMへの入力時のセキュリティ管理が必須
- ハルシネーションのリスク：LLMがヒアリングで言及されていない要件を「もっともらしく」生成するリスクに対し、原本（議事録）との照合チェックを必ず実施
- テンプレート依存の回避：AI生成の要件定義書がプロジェクト固有のコンテキストを反映せず、汎用的な記述に留まるリスク。クライアントの業界特有の規制・慣行を人間が追記
renue視点：専用ツールではなく汎用LLMで実現する理由
要件定義書作成の本質は「クライアントの発言を聞き→業務課題を理解し→システム要件として構造化し→関係者に伝わる文書にまとめる」という言語処理の連鎖です。CoBrainのような専用ツールも登場していますが、汎用LLMに自社の高品質な要件定義書テンプレート＋過去プロジェクトの優良事例をRAGで参照させれば、同等以上のアプローチが実現可能です。課題共有は背景・現状・目的・根拠・実現プランまで整理することが有効とされますが、この構造化の思考プロセスこそLLMの最も得意とする領域です。「自社のトップコンサルタントがどのようにヒアリングから要件を抽出し、どのような構造で文書化しているか」を言語化してプロンプトに落とし込むことが、AI活用の最も重要なステップです。
まとめ
コンサルティングファームの要件定義書作成は、ヒアリング記録の自動分析→要件の構造化・分類→ドラフト自動生成→品質チェック自動化→レビュー反映のパイプラインでLLMによる大幅な効率化が可能です。学術研究でも、LLMによる要件仕様書生成が人間のアナリストと同等品質を達成しうることが実証されています。ただし、ヒアリングの設計・実施、要件の優先度判断、ステークホルダー間の利害調整、スコープの最終決定は完全にコンサルタントの思考力と対人力の領域です。
設計観点の整理：要件定義AI導入で陥りやすい3大落とし穴
要件定義AIは請負/準委任契約の性質・クライアント機密保護・EU AI Act高リスク分類の3軸で設計を誤ると、契約責任の所在不明・機密情報流出・規制違反の致命的リスクが生じる領域です。
落とし穴1：契約法（請負/準委任）×個情法×不正競争防止法×取適法×要件定義AIの5層コンプライアンス
国内の要件定義AI化は民法（632条請負 vs 656条準委任、AI開発の不確実性から準委任契約が適合、成果物完成義務か善管注意義務か）、経産省「AI・データの利用に関する契約ガイドライン-AI編」（平成30年）、「AIの利用・開発に関する契約チェックリスト」（2025-02）、不正競争防止法（ヒアリング記録の営業秘密保護）、取適法（2026-01-01施行、下請事業者への不当な取引条件に留意が必要とされます）、2022年改正個人情報保護法（ユーザーインプットが個人データ含む場合の第三者提供ルール）の5層で重なります。AIによるヒアリング記録の構造化・要件仕様ドラフト生成は有効ですが、「クライアント業務機密・インタビュー内容の外部LLM送信禁止（営業秘密、閉域LLM必須）」「AI生成要件の契約属性明確化（準委任でもクライアント承認必須、AI単独成果物の納品は禁止）」「AI出力のハルシネーション検証（実現不能機能の要件化防止）」を設計段階で組み込む必要があります。
落とし穴2：グローバル要件定義AI×EU AI Act高リスク×GDPR Art.25/32×privacy-first開発×2026-08-02透明性要件
海外の要件定義AIは2026年、EU AI Act（2026-08-02透明性規定発効、高リスクAIは36ヶ月猶予で全面準拠）が雇用・信用・法執行等高インパクト領域のAIを優先執行対象化。要件定義段階から「システム名・バージョン・意図する用途・利用者タイプ・影響を受ける人」の技術文書化が求められ、LLMアプリケーションではプロンプトインジェクションリスク・ハルシネーション率・バイアスパターン・緩和戦略の文書化が必須。GDPR Art.25（Privacy by Design）・Art.32（処理のセキュリティ）は技術的・組織的措置を要求、Art.35のDPIA（データ保護影響評価）は置換不可。企業は「データ残留ゼロ（Zero Data Retention）」を法律業界等で採用、プライベートインフラデプロイ・HIPAA/SOC2/GDPR準拠の知識ベース型LLM（BYOM: Bring Your Own Model）が標準化傾向。コンプライアンス文書は開発プロセス組込型が後付けより容易。日本のAI設計も「Privacy-by-Design×Zero Retention×継続的文書化」が国際標準化しつつあります。
落とし穴3：中国要件定義AI×AI編程大模型×準委任的アプローチ×PIPL/大模型備案×70%戦略採用30%落地成功
中国の要件定義AI化は2026年、国産AI編程大模型（要求分析→コード生成→最適化→デバッグ→テスト→デプロイのフルサイクル）の性能が海外の主要モデルに近づき、企業向けの商用展開が本格化しつつあるとされます。多くの中国企業が大規模言語モデルの活用を掲げる一方、実運用への定着は限定的との指摘もあります。要求分析の段階では生成AIのテキスト要約能力で概念抽出・概念関係モデリング・業務フロー生成を自動化。PIPL・改正網絡安全法（2026-01-01施行）・生成AIサービス管理暫行弁法（大模型備案）・反不正当競争法への対応が必須。中国市場向け要件定義AIでは国産大模型＋中国内DC処理＋クライアントごとの情報隔離設計を組み合わせる構成が検討されることがあり、日中跨境ITコンサルでは日本の契約ガイドライン×中国反不正当競争法×EU AI Act高リスク分類の三方整合設計が重要論点です。
