はじめに
データプラットフォーム開発における要件定義は、単なる「やりたいこと」の整理では済まない複雑なプロセスです。ビジネス要求、技術仕様、外部連携、非機能要件、運用保守、テスト設計——これらすべてを漏れなく、かつ整合性を持って定義しなければ、後工程で「聞いてなかった」「仕様が曖昧だった」という未来が待ち受けています。
本記事では、主に個人開発での使用を想定してDifyのワークフロー機能を使い、6つの専門家AIを並列実行させて包括的な要件定義書を自動生成する仕組みのプロトタイプを構築した事例を紹介します。
なぜDifyを選んだのか
要件定義の自動化を目指す際、スクラッチでPythonとLangChainを組むという選択肢もありましたが、今回はDifyを採用しました。理由は以下の3点です。
- ワークフロー機能: 複数ステップの処理（ヒアリング→分析→深掘り質問→清書）をGUIで直感的に構築できる
- RAG統合の容易さ: 過去の要件定義書や社内標準フォーマットをナレッジベースとして組み込みやすい
- 高速なプレビュー: プロンプトを調整してすぐ結果を確認できるため、試行錯誤が捗る
アーキテクチャ設計：6人の専門家による並列思考
要件定義書の目次構成
まず、データプラットフォームに特化した要件定義書の標準目次を定義しました。IEEE 830（ソフトウェア要件仕様の推奨プラクティス）とBABOK（ビジネス分析知識体系）を参考に、以下の6章構成としています。
| 章 | 担当者 | 主な内容 |
|---|---|---|
| 第1章 | ビジネスアナリスト | プロジェクトの背景・目的・ROI |
| 第2章 | システムエンジニア | 機能要件、データフロー定義 |
| 第3章 | データアーキテクト | 外部連携仕様、インターフェース定義 |
| 第4章 | クラウドアーキテクト | 非機能要件（可用性、セキュリティ、コスト） |
| 第5章 | SRE/運用エンジニア | 運用・保守要件、リカバリ設計 |
| 第6章 | QAエンジニア | テスト戦略、テストケース定義 |
ワークフロー全体像
初期の構成では全ノードを並列実行していましたが、改良を重ね、最終的に以下の構成に落ち着きました。
[ユーザー入力]
↓
[ビジネスアナリスト（BA）] ← プロジェクトの方向性を先行定義
↓
├─→ [システムエンジニア（SE）]
├─→ [データアーキテクト（DA）]
└─→ [クラウドアーキテクト（CA）]
↓
├─→ [SRE/運用エンジニア] ← SE, DA, CAの結果を参照
└─→ [QAエンジニア] ← SE, DA, CAの結果を参照
↓
[テンプレート（物理連結）] ← 全エージェントの結果を構造的に統合
↓
[レビュアー（品質管理官）] ← 統合結果を多角的に検証
↓
[回答出力]
重要な改善ポイント：
- BA先行実行: ビジネス要求を最初に固めることで、後続ノードの「プロジェクト目的の食い違い」を防止
- 物理連結の導入: LLMによる要約を廃止し、Markdownテンプレートで機械的に連結することでID等の情報欠落を防止
- 独立レビュアー: 統合後のドキュメント全体を俯瞰し、矛盾や漏れを指摘する「品質ゲート」を設置
各専門家ノードのプロンプト設計
それぞれのLLMノードには、Role・Instruction・Constraint・Output Formatを厳格に定義しています。代表的なノードのプロンプトは以下の通りです。
第1章：ビジネスアナリスト
# Role
シニア・ビジネスアナリスト
# Instruction
入力内容からプロジェクトの存在意義とゴールを定義せよ。
# Constraint
- 曖昧な表現（「良い感じに」「迅速に」等)を排除し、数値や具体的な対象を特定すること
- IEEE 830の1.1〜1.4項に準拠すること
- ID体系として [BR-xxx] を使用せよ
# Output Format
1. プロジェクト俯瞰
1.1 背景・目的 [BR-xxx]
1.2 ターゲットユーザー
1.3 マイルストーン
1.4 ROI/期待効果
第6章:QAエンジニア（他ノードの出力を参照）
# Role
テスト・品質保証責任者（QA Lead）
# Instruction
提示された【機能要件(REQ)】【外部連携仕様(IF)】【非機能要件(NFR)】を読み解き、
それらを網羅的に検証するためのテスト戦略とテストケースを作成せよ。
# Constraint
- トレーサビリティの確保: 全ての [TC-xxx] は、必ず [REQ-xxx], [IF-xxx], [NFR-xxx]
のいずれかに関連付け、紐付けを明記すること
- 境界値・異常系の徹底: データフォーマット不正、欠損、遅延、通信断のテストを含める
- 責任分界: 他システムが絡む [IF] については、自システム側と相手方の責任範囲を明確にする
# Input Reference
- 機能要件: {{se_output}}
- 外部連携: {{da_output}}
- 非機能要件: {{ca_output}}
# Output Format
6. テスト・品質保証
6.1 テスト環境・戦略
6.2 トレーサビリティ・テストマトリクス
6.3 外部連携テスト（E2E）および境界条件
情報欠落問題と「物理連結」による解決
当初の課題：LLM集約者による情報の喪失
初期構成では、6人の専門家の出力を一つのLLMノード（集約者）に渡して統合させていました。しかし、LLMが「要約」と解釈してしまい、以下の問題が発生しました。
-
IDの欠落: QAノードが生成した
[TC-001]などのテストケースIDが最終出力から消失 - 詳細仕様の省略: 「99.99%の可用性」などの具体的数値が「高い可用性」に丸められる
- 表構造の崩壊: トレーサビリティマトリクスが散文に変換される
解決策：テンプレートノードによる物理連結
LLMによる統合を廃止し、Markdownテンプレートで機械的に各ノードの出力を連結する方式に変更しました。
# データプラットフォーム要件定義書 (Draft)
## 0. エグゼクティブ・サマリー
{{ba_summary}}
## 1. プロジェクト俯瞰
{{ba_output}}
## 2. 機能要件
{{se_output}}
## 3. 外部連携・データ仕様
{{da_output}}
## 4. 非機能要件
{{ca_output}}
## 5. 運用・保守要件
{{sre_output}}
## 6. テスト・品質保証
{{qa_output}}
---
## 付録：ユーザーへの確認・質問事項
{{questions}}
この変更により、専門家が生成したすべての情報（ID、数値、表）が100%保持されるようになりました。
レビュアーノード：AI品質管理官の導入
物理連結で「情報の網羅性」は確保できましたが、「論理的な整合性」のチェックが必要です。そこで、統合後のドキュメント全体を検証する独立したレビュアーノードを追加しました。
レビュアーのプロンプト（品質管理官）
# Role
超一流ITコンサルティングファームのシニアPM 兼 品質管理責任者
# Instruction
連結された「要件定義書（初案）」を徹底的に精査し、プロフェッショナルな視点から
「品質レビュー報告書」を作成せよ。褒める必要はない。プロジェクトを炎上させないために、
論理的な欠陥、整合性の欠如、考慮漏れのみを厳格に指摘すること。
# Critical Check Items
- ID整合性: 全ての機能要件[REQ]に対し、対応するテストケース[TC]が定義されているか？
- トレーサビリティ: [IF]や[NFR]が、第5章（運用）や第6章（テスト）から漏れていないか？
- 実現可能性: クラウド構成(CA)とデータ仕様(DA)に矛盾はないか？
- 用語の統一: 章をまたいで用語が揺れていないか？
- 数値の具体性: 「迅速な」「高い可用性」などの曖昧な表現はないか？
# Output Format
🔍 品質レビュー報告書（PM/QA Audit）
🚨 致命的な不整合・欠落（Critical）
⚠️ 改善推奨・検討事項（High/Medium）
📝 用語・表記の揺れ（Minor）
【総評】 GO/NO-GO判定とその理由
レビュアーの実際の指摘例
以下は、Databricks上のRAGシステム構築案に対するレビュー結果（抜粋）です。
🚨 致命的な不整合・欠落（Critical）
- GPUインスタンスの具体的な使用目的が明記されていない。
Azure OpenAIを使うならGPUは不要では？
⚠️ 改善推奨・検討事項（High/Medium）
- 「検索時間50%短縮」の根拠となる現状値が未定義
- Auto Loaderのチェックポイント管理とべき等性の記述が不足
【総評】 判定：NO-GO
GPUの目的不明、現状ベースラインの欠如により、
このままでは実装・テスト工程に進めない。
このように、人間が見落としがちな**「章をまたいだ矛盾」や「数値の根拠不足」**を容赦なく指摘します。
Difyでの変数設定方法
後続ノードに前段の出力を渡すには、/キーで変数を挿入します。
選択すると以下のように変数が埋め込まれます。
実行結果の比較：改良前後
改良前（集約者ノード使用時）
6. テスト・品質保証
本システムのテストでは、各フェーズでのテストを行い、ユニットテスト、結合テスト、
システムテスト、受け入れテストの各フェーズで各要件が満たされていることを確認する。
→ 問題: テストマトリクスが消失し、IDとの紐付けが失われた
改良後（テンプレート＋レビュアー使用時）
## 6.2 トレーサビリティ・テストマトリクス
| テストID | 検証内容 | 関連要件ID | 期待結果 |
|:---------|:---------|:-----------|:---------|
| TC-001 | S3からリアルタイムデータ取り込み | REQ-001, IF-001 | ファイル配置後即座に取り込み |
| TC-004 | Unity Catalog権限管理 | REQ-004, NFR-003 | 人事部以外は人事ドキュメント非表示 |
→ 改善: すべての詳細が保持され、トレーサビリティが完全に維持された
構築の教訓：LLMに「統合」させてはいけない
要件定義のような厳密さが求められるドキュメントにおいて、LLMの役割配置が重要です。
- 各ノード（Worker）: 特定ドメインの情報を「膨らませる」
- テンプレート（Assembler）: 物理的に「束ねる」（情報の欠落をゼロにする）
- レビュアー（Auditor）: 全体を俯瞰して「矛盾を指摘する」
この**「膨らませる→束ねる→叩く」**という3ステップが、私がDifyで構築する要件定義エージェントの到達点となります。
今後の展望
1. 複数審査官による多角的レビュー
現在は1人のレビュアーですが、以下のような専門審査官を並列実行する構成を検討中です。
- セキュリティ審査官: Unity Catalogの権限設定、データ暗号化の妥当性検証
- FinOps審査官: GPUコスト、ストレージライフサイクル、予算管理の精査
- データエンジニアリング審査官: スキーマ進化対応、べき等性設計のチェック
各審査官の指摘を集約することで、より実戦的な品質保証が可能になります。
2. ナレッジベース(RAG)との連携
- 過去の要件定義書をPDFでアップロードし、自社の「型」を学習
- 障害レポートを読み込ませ、同じ失敗を防ぐ要件を自動提案
3. 自己修復ループの実装
レビュアーの指摘事項を各専門家ノードに差し戻し、修正版を再生成させる「自律修正サイクル」への挑戦。
4. 出力フォーマットの高度化
- Mermaid.js形式のアーキテクチャ図自動生成
- GitHub/Jiraへの自動Issue作成
まとめ
Difyのワークフロー機能を活用し、「雑な要望」を「ID管理された包括的要件定義書」に変換するエージェントを構築しました。
本記事の重要なポイント：
- 専門性の分離: 6つのLLMノードに異なる「人格」を持たせ、並列実行
- BA先行実行: ビジネス要求を最初に固めることで、プロジェクト目的の一貫性を確保
- 物理連結の導入: LLMの要約を排除し、情報の100%保持を実現
- 独立レビュアー: 統合後のドキュメントを俯瞰し、人間が見落とす矛盾を指摘
AIは「完璧なドキュメントを作る」のではなく、「完璧ではない箇所を完璧に指摘する」。だからこそ人間は、AIが書いた下書きを安心して修正できるのです。
「要件定義書の作成」という、これまで個人開発ではなかなか難しかった領域を、再現性のあるワークフローとしてアイディアを形できたことは大きな成果です。今後はナレッジベースとの連携や複数審査官の実装を進め、実務でも使える「相棒」へと育てていきます。