はじめに
この記事は、LangChainとLangGraphによるRAG・AIエージェント［実践］10章「要件ドキュメント生成AIエージェント」入門 輪読会 - connpass の内容をQiita記事向けに再編集したもの。
構成は以下の通り
- 要件定義の課題
- 「要件ドキュメント生成AIエージェント」を動かしてみる
- 「要件ドキュメント生成AIエージェント」の元になっている論文「Elicitronフレームワーク」の説明
- 「要件ドキュメント生成AIエージェント」の簡単な解説
要件定義の課題
システム開発の落とし穴
ユーザが思ってたのと違うシステムが出来る
考えられる原因
- そもそも、まず要件定義をした？
- 要件はレビューしてもらった？
- その要件定義、誰が要件を出した？（要件出した人は実際に使う人？）
- 実際に使うユーザのユースケースに落として、何が出来るかイメージ出来るとこまで落として確認した？
顧客が本当に必要だったもの
ユースケースを明確にして要件定義をしよう
ユーザインタビューの課題
「ユーザにユースケースを確認しよう」と言っても、
- 適切なユーザがすぐつかまらない
- ユーザインタビュー
コストと時間めっちゃかからない？ - 多用なニーズ、潜在要求の把握
という課題が存在
→ 「それ、AIでいい感じに出来ないだろうか？」 がこの記事のテーマ
「要件ドキュメント生成AIエージェント」動かしてみる
まずは「LangChainとLangGraphによるRAG・AIエージェント実践入門」10章の「要件ドキュメント生成AIエージェント」動かしてみる
https://github.com/GenerativeAgents/agent-book
chapter10
poetry run python -m documentation_agent.main --task "スマートフォン向けの健康管理アプリを開発したい"
実行すると、
- 途中経過のログは出ない(動いているのかちょっと心配になる)
- 1分程で結果が返ってくる
結果の例
# 要件文書
## 1. プロジェクト概要
本プロジェクトは、スマートフォン向けの健康管理アプリを開発することを目的としています。ユーザーが日常的に健康を管理し、改善するための機能を提供し、健康意識の向上を図ります。アプリは、食事管理、運動記録、睡眠分析、ストレス管理など、包括的な健康管理をサポートします。
## 2. 主要機能
1. **食事管理**
- カロリー計算機能（バーコードスキャン、簡単な食事記録）
- 栄養素分析（タンパク質、脂質、炭水化物のトラッキング）
2. **運動記録**
- ワークアウトトラッキング（GPS機能を用いた距離・ペース計測）
- フィットネス目標設定と達成度の可視化
3. **睡眠分析**
- 睡眠の質トラッキング（深い睡眠・浅い睡眠の分析）
- 睡眠環境の評価（環境音、室温の記録）
4. **ストレス管理**
- メンタルヘルスのトラッキング（気分やストレスレベルの記録）
5. **統合データ分析**
- 健康状態の総合的な分析機能（運動、食事、睡眠の相互作用の可視化）
6. **簡単なデータ入力**
- 音声入力やバーコードスキャン機能
7. **リマインダー機能**
- 水分補給、食事、運動の通知
8. **シンプルなインターフェース**
- 直感的なデザイン
9. **カスタマイズ可能な目標設定**
- ユーザーのライフスタイルに合わせた目標設定
10. **サポートコミュニティ**
- 他のユーザーとの情報交換や励まし合いができる機能
11. **SNSとの連携**
- 成果のシェア機能
12. **健康データの記録**
- 健康診断の結果管理機能
13. **サポートやヘルプ機能**
- アプリの使い方に関するサポート
## 3. 非機能要件
- **ユーザビリティ**: 直感的で使いやすいインターフェースを提供すること。
- **パフォーマンス**: アプリの起動時間は3秒以内、データ入力は5秒以内で完了すること。
- **セキュリティ**: ユーザーの健康データは暗号化し、プライバシーを保護すること。
- **互換性**: iOSおよびAndroidの両方のプラットフォームで動作すること。
## 4. 制約条件
- 開発予算は500万円以内。
- 開発期間は6ヶ月以内。
- ユーザーからのフィードバックを基にした機能追加は、リリース後のアップデートで対応。
## 5. ターゲットユーザー
- 健康意識が高い30代男性（例: 佐藤健一）
- 忙しい仕事を持つ看護師（例: 山田美咲）
- 健康診断に不安を感じる自営業の経営者（例: 鈴木太郎）
- 健康的な生活を楽しむ大学生（例: 田中花子）
- スマートフォンに不慣れな60代男性（例: 中村健二）
## 6. 優先順位
1. 食事管理
2. 運動記録
3. 睡眠分析
4. ストレス管理
5. 統合データ分析
6. 簡単なデータ入力
7. リマインダー機能
8. シンプルなインターフェース
9. カスタマイズ可能な目標設定
10. サポートコミュニティ
11. SNSとの連携
12. 健康データの記録
13. サポートやヘルプ機能
## 7. リスクと軽減策
- **リスク**: ユーザーのニーズに合わない機能の実装
- **軽減策**: ユーザーインタビューやフィードバックを定期的に実施し、機能改善に活かす。
- **リスク**: アプリの使い方が難しいと感じるユーザーが多い
- **軽減策**: シンプルなインターフェースを設計し、ヘルプ機能を充実させる。
- **リスク**: データのセキュリティ問題
- **軽減策**: 最新のセキュリティ技術を導入し、定期的にセキュリティチェックを行う。
以上が、スマートフォン向け健康管理アプリの要件文書です。ユーザーの多様なニーズに応えるため、機能の充実と使いやすさを重視した設計を行います。
どういう仕組み？
この「要件ドキュメント生成AIエージェント」は、Elicitronという論文を元に実装されている
引用元: LangChainとLangGraphによるRAG・AIエージェント実践入門 p278
Elicitronフレームワーク 論文概要
Elicitron: An LLM Agent-Based Simulation Framework for Design Requirements Elicitation (2024)
背景と主要問題
従来の要求獲得手法は、多様なユーザー視点の不足や潜在的要求の抽出困難、実施にかかる時間やコストの問題を抱える
多様なユーザー視点の不足
- 偏ったサンプリング
- 少数派の意見が反映されない
- 文化的背景の考慮不足
潜在的要求の抽出困難
- ユーザー自身が気づいていない
- 言語化できないニーズ
- 観察と解釈の難しさ
時間やコストの問題
- 専門人材の確保
- スケジュール調整の複雑さ
- 分析作業の負担
[Elicitron] 論文の提供する解決策
LLMを用いたエージェントインタビューと分析により潜在ニーズを抽出
CoT(Chain of Thought)でユーザの多様性と潜在ニーズの抽出精度を向上
提案手法「Elicitron」は、LLMを活用して多数の仮想ユーザー（LLMエージェント）を自動生成し、各エージェントに製品利用シナリオをシミュレーションさせることで、ユーザーが実際に体験する行動、観察、課題を詳細に記録。さらに、これらのシミュレーション結果を基にエージェントインタビューを実施し、表出されたニーズとともに、従来見落とされがちな潜在ニーズも抽出する仕組みを提供。エージェント生成では、連続的（serial）生成を採用することで多様性を高める工夫がなされ、後続の分析にはチェーン・オブ・ソート（chain-of-thought）を用いることで、潜在要求の自動識別精度が向上。
[Elicitron] 論文の技術的優位性
- 潜在ニーズ抽出数を1.8倍(baseline比[1])
出典:Elicitron: An LLM Agent-Based Simulation Framework for Design Requirements Elicitation. Fig.4
[1] Baseline: Human ELU'sの潜在ニーズ抽出数の5.6は、次節で説明する先行研究のEmpathic Lead User (ELU)インタビューの値
- 実施にかかる時間を80時間(4時間/人x20人)→ 2.3時間に短縮
[Elicitron] 先行研究(Empathic Lead User (ELU)インタビュー)
DETC2007/35302: “Empathic Lead Users: The Effects of Extraordinary User Experiences on Customer Needs Analysis and Product Redesign.”
Empathic Lead User (ELU)インタビュー とは
通常のユーザに対して特別な状況をシミュレートし、インタビューを実施することで潜在ニーズを抽出する
典型的な顧客の経験からの逸脱を考慮し、通常では見過ごされがちな潜在ニーズを明らかにする
実験
「週末にキャンプをする、15〜30歳、健康で体力があり、年に数回キャンプをする人」に対して二人用テントの製品インタビューを実施
一般的な消費者製品として二人用テント（具体的には、標準的な設計であるREI Camp Domeテント）が潜在ニーズ調査対象
典型的なユーザとして「週末にキャンプをする、15〜30歳、健康で体力があり、年に数回キャンプをする人」
-
Verbal(口頭インタビュー):
参加者はプロトタイプに一切触れることなく口頭でインタビューを受ける -
Articulated Use(明確化された使用インタビュー):
参加者は通常の状態でプロトタイプ（テント）を使用しながらインタビューを受ける -
Empathic Lead User:
参加者は暗い部屋でオーブンミットを着用し、テントを組み立てるという特別な状況下でインタビューを受ける。これは、寒さの中での厚手の手袋の使用や、関節炎のユーザーの不器用さをシミュレートすることを意図
Elicitron フレームワーク概要
ブロック構成：
- ユーザエージェント生成
- 製品体験生成
- ユーザインタビュー
- ユーザニーズ抽出
Elicitron解説(ユーザエージェント生成)
(この節はこのブロック↑の解説)
多様性が最大となるようにユーザのペルソナを作成する
作成方法：
一つ前に作成したユーザとは異なる典型的なユーザを順番に作成
さらに、非典型的なユーザをprompt操縦(steer)で作成
serial method prompt
Generate three different user personas for a camping tent, including their name, a description of their characteristics, and a rationale for creating each agent
steer prompt
You must create non-typical users based on the following description of a typical user:
“The typical user would be a weekend camper, 15-30 years old, with very good health and physical fitness, who camps a few times a year.
The typical usage environment would be a public park or wilderness area, in a generally wooded or grassy environment with warm, sunny weather.”
実際に生成されたユーザ（例）
典型的なユーザ：「週末にキャンプをする、15〜30歳、健康で体力があり、年に数回キャンプをする人」
非典型なユーザ：「アドベンチャーを求めるティーン」「引退した自然愛好家」「身体障害を持つ人」「遠征リーダー」「高地登山家」など
Elicitron解説(製品体験生成)
(この節はこのブロック↑の解説)
ユーザインタビューで潜在的なニーズを特定するためのコンテキストとして製品体験を生成する
多様なインタラクションのシミュレーション
- セットアップ
- 特定機能の使用
- トラブルシューティングなど
具体的な利用シナリオの特定のための構造化
- 「行動 (Action)」
- 「観察 (Observation)」
- 「課題 (Challenge)」
例：「関節炎を患う高齢者」ユーザにテント利用に関する製品体験を生成
ステップ1：
アクション：指の器用さが限られている状態で、テントの入り口のジッパーをつかもうと試みた。
観察：ジッパーが小さすぎて把持しにくく、操作が困難だった。
課題：テントの開閉に苦労し、イライラした。
ステップ2：
アクション：テントのポールを組み立て、構造の上に生地を張ろうとした。
観察：テントポールを接続し、生地を引っ張るのに必要な力が、関節炎の痛みを悪化させた。
課題：指の力が弱く、痛みがあるため、組み立てが困難で時間がかかった。
ステップ3：
アクション：テントを地面に固定しようとした。
観察：通常サイズの杭とハンマーを使う方法では、自分の状態では扱えないと感じた。
課題：テントを効果的に地面に固定できず、風の強い状況下での安全性が懸念された。
ステップ4：
アクション：使用後、テントを片付けようとした。
観察：テントを畳んでバッグに収まるほどきつく巻くのに苦労した。
課題：この作業は肉体的にきつく、自分には必要な器用さと力が足りず、他人の助けを借りる必要があった。
Elicitron解説(ユーザインタビュー)
(この節はこのブロック↑の解説)
「質問プールの作成」「ユーザインタビュー」のタスクで構成される
-
質問の種類と目的
インタビュー質問は人間またはLLMが作成し、製品の多様な側面を網羅。自由形式の質問で重要点を探り、カテゴリ別の質問で具体的なニーズや改善策を引き出す。 -
コンテキストを活用した質問
各エージェントへの質問は、過去のQ&Aやシミュレーション体験を反映し、より実践的で具体的な回答を得るために設計される。 -
適応的なカテゴリ選択
製品の種類やエージェントの役割に応じて、最適な質問カテゴリを選択し、関連性の高い情報を収集。
生成されたユーザへの質問とユーザ回答（例）
自由形式：
「理想的なテントを購入するとしたら、どのような主な特徴を求めますか？」
カテゴリ別：
「テントの[カテゴリ]の側面、具体的には、あなたのニーズと、
それらのニーズに対応するための革新的な洞察を教えてください」
*カテゴリ:サイズ、形状、重量、素材、安全性、耐久性、美観、エルゴノミクス、コスト、セットアップ、輸送
質問:
テントの設営という側面に特に焦点を当てて、あなたのニーズと、
それらのニーズに対応するための革新的なアイデアがあれば教えてください。
回答:
「…バッグから取り出すと自動的に展開し、自分で設営できる自己設営型のテント構造です。
手動でテントポールを接続したり、生地を伸ばしたりする必要がありません。
これは、スプリング式または形状記憶素材の技術を活用できるでしょう。
構造要素は、解放されると自動的に正しい形状と張力を得るように設計されています。」
Elicitron解説(ユーザニーズ抽出)
(この節はこのブロック↑の解説)
ユーザ回答を元に"think step-by-step to detect the latent needs"でLLMに潜在ニーズかどうかを次の条件に合致するかで判定
潜在ニーズの判定条件：
- 製品設計への重要な変更を表しており、サイズ、形状、重量、素材、安全性、耐久性、美観、エルゴノミクス、コスト、セットアップ、または輸送のカテゴリのいずれにも該当しない場合
- 製品および/またはその使用方法に関して、非常に革新的で明確に表現された洞察を反映している場合
潜在ニーズ:（下図左）
「写真撮影のために広い視野を確保するために、指定された開口部を通してテントの内部構造を再設計する」
→ 既存のカテゴリに当てはまらない製品設計への重要な変更
潜在ニーズではない:（下図右）
「鋭利なものや一般的な摩耗による裂けに強いテントの床にする」
→ 耐久性という既存のカテゴリに該当
Elicitronフレームワークのおさらい
- ELUエージェントの作成: 典型的なユーザ（週末にキャンプをする、15〜30歳、健康で体力があり、年に数回キャンプをする人）のユースケースからの逸脱に基づいて、ELUエージェントを作成(実験ではELUエージェントを20人分作成)
- 特別なリードユーザ条件のシミュレーション: 年齢、健康状態、使用環境などの典型的な条件から逸脱した状況をユーザに想定してもらう
- インタビューの実施: シミュレートされた状況下でユーザにインタビューを実施
- 潜在ニーズの特定: インタビューの回答を分析し、基準に基づいて潜在ニーズをラベル付け
[Elicitron] 論文の提案する方法の限界または制約
- LLMの出力品質や与える文脈に依存
- シミュレーションで生成されるニーズの質は、設計者が提示する初期条件や文脈の設定に大きく左右される
- 最終的な要求選定や優先順位付けには依然として専門家の介在が必要
- マルチモーダルな情報（画像や音声など）との連携は今後の課題
以上がElicitronフレームワークの論文解説
「要件ドキュメント生成AIエージェント」の簡単な解説
コードスタディ: 処理の流れ(全体)
引用元: LangChainとLangGraphによるRAG・AIエージェント実践入門 p278
主要エージェント:
- PersonaGenerator
- InterviewConductor
- InformationEvaluator
- RequirementsDocumentGenerator
レポート生成(RequirementsDocumentGenerator)で以下の通り出力する構成をpromptで指定して要件定義書を作成
- プロジェクト概要
- 主要機能
- 非機能要件
- 制約条件
- ターゲットユーザー
- 優先順位
- リスクと軽減策
Elicitronの最終ブロックのレポート生成は潜在ニーズのレポート生成を行うが、ここで要件定義を生成するように組み換えを行ってみるのが「LangChainとLangGraphによるRAG・AIエージェント実践入門」10章「要件ドキュメント生成AIエージェント」の実装アプローチ。
但し、Elicitronは要求(ニーズ)の抽出の手法であり、論文の制約の通り実際の要求選定や要求の優先順位付けは人間の介在が必要。要件定義プロセスの入力は要求であり、この違いは留意が必要。
さらに、詳しく内容を知りたい方は書籍「LangChainとLangGraphによるRAG・AIエージェント実践入門」をどうぞ
個人的な所感
要求抽出だと多様なユーザエージェント生成は強みだけど、要件定義で考えるとそれだけではなく実際の利用ユーザに近づけるペルソナ作成も有効そう
- 新規のSaaSプロダクトの要件定義は、ターゲットとするマーケット、自社の競争優位性をどこにおくか要求から導いたターゲットユーザのペルソナ設定が必要。
- DXの場合は、現場ユーザのペルソナ設定が必要（実在の人物を設定しつつ、課題ヒアリングをコンテキストとしてペルソナを作成する等）
- 購買履歴、閲覧履歴、医療診療履歴、個人属性情報、カスタマーの声、現場の声、会議の議事録・発言内容、Slackの発言、人事データ、ありとあらゆる使ってよい利用可能なデータを使ってターゲットユーザをより明確にするアプローチも検討してみても面白そう
- コンシューマー向けの多様なユーザの利用を想定するケースでは、Elicitronの潜在ニーズを探るアプローチと同様の多様なユーザペルソナを作成すると良さそう
先行研究の実験結果から、ユーザインタビューは製品体験シミュレート中に行えると良さそう
実際に初期の段階で画面モックを作ってユーザに確認するのは非常に有効な手法であり、フレームワークの中でcursorやclineがモックを自動で作って、作成した仮想ペルソナのユーザエージェントAIに実際にモックを触ってもらいつつインタビューを行うとこまで行くと、とても品質があがりそう（人間はこの様子をただ眺めているだけになるとディストピア感がありますね）
結局、やはり要件定義の元になる要求の質が大事だと思う（AI使ったところで、ごみを入れてもごみしか出てこないのは変わらないので）
要求抽出では、ターゲットユーザ、ユースケースを意識して要求を出すことがやはり大事であり、要件ドキュメント生成AIエージェントを活用することで、多様なユーザー視点や潜在的要求をよりくみ取りつつ、ユーザインタビューの実施にかかる時間やコストを抑えられる可能性がある。
DeepResearchの活用で上流の要求定義も新しいステージに入っており、下流の開発もAIによる自動コーディングが日々進化をとげており、今回焦点にあてた「要件定義」もまだまだ進化していくと思われる。
Stay Tuned for Evolving Requirements Engineering!
おわりに
論文を読むときにNotebookLM、スライド作る時にClaude sonnet 3.7のSVG出力を大変活用させて頂きました。
怖ろしく便利な世の中になったもので。
あと、輪読会の本の著者とは面識なく、アフィリエイトもしてないので本を宣伝しても私には一銭も入ってこないのではありますが、素晴らしい本をありがとうございます。
個人開発サービスの宣伝
langgraph、langsmith、全自動配信でエンジニア向けpodcastをゆるく運営しています。番組へのお便りもらえるとむっちゃ嬉しいです。あと案件ください！！
