株式会社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で参照させれば、同等以上のアプローチが実現可能です。renueの社内ガイドラインでは「課題共有は背景・現状・目的・根拠・実現プランまで整理する」ことが推奨されていますが、この構造化の思考プロセスこそLLMの最も得意とする領域です。「自社のトップコンサルタントがどのようにヒアリングから要件を抽出し、どのような構造で文書化しているか」を言語化してプロンプトに落とし込むことが、AI活用の最も重要なステップです。
まとめ
コンサルティングファームの要件定義書作成は、ヒアリング記録の自動分析→要件の構造化・分類→ドラフト自動生成→品質チェック自動化→レビュー反映のパイプラインでLLMによる大幅な効率化が可能です。学術研究でも、LLMによる要件仕様書生成が人間のアナリストと同等品質を達成しうることが実証されています。ただし、ヒアリングの設計・実施、要件の優先度判断、ステークホルダー間の利害調整、スコープの最終決定は完全にコンサルタントの思考力と対人力の領域です。