LangChainとLangGiraphによるRAG・AIエージェント実践入門「10章 要件定義書生成Alエージェントの開発」輪読会スライド

Transcript

1. 1/45
2. LangChainとLangGraphによるRAG・AIエージェント 実践入門 輪読会 10章「要件ドキュメント生成AIエージェント」 2025/4/10 2/45
3. 本日のAgenda 導入LT: ユースケースを明確にして要件定義をしよう(6分) • 「要件ドキュメント生成AIエージェント」動かしてみる(6分) • Elicitronフレームワーク 論文概要(12分) • 質問＆中休憩(3分) • 「要件ドキュメント生成AIエージェント」(15分) コードを読んで理解を深める • 運営からの事務連絡等 (3分) • 3/45
4. 導入LT: ユースケースを明確にして要件定義をしよう (6分) 4/45
5. システム開発の落とし穴 ユーザが思ってたのと違うシステムが出来る 顧客が本当に必要だったもの 5/45
6. 顧客が本当に必要だったもの そもそも、まず要件定義をした？ 出典:セキュリティ・バイ・デザイン「システム開発のセキュリティ向上0.0」 6/45
7. 顧客が本当に必要だったもの 要件はレビューしてもらった？ 聞いてないんだが！ 7/45
8. 顧客が本当に必要だったもの その要件定義、誰が要件を出した？（要件出した人は実際に使う人？） AWSみたいなシステム作って！ OpenAIみたいなシステム作って！ 非機能要件：外販できること！ 8/45
9. 顧客が本当に必要だったもの 実際に使うユーザのユースケースに落として、 何が出来るかイメージ出来るとこまで落として確認した？ 機能要件：ブランコ機能 （誰が使う？） （どういうユースケースで使う？） （作るものがイメージ出来る？） 9/45
10. ユーザにユースケースを確認しよう ユースケースを明確にして要件定義をしよう 顧客が本当に必要だったもの 10/45
11. 本日の問い 「ユーザにユースケースを確認しよう」 それ、AIでいい感じに出来ない？ 適切なユーザがすぐつかまらない • ユーザインタビュー コストと時間めっちゃかからない？ • 多用なニーズ、潜在要求の把握 • 11/45
12. 10章「要件ドキュメント生成AIエージェント」 動かしてみる (6分) 12/45
13. 最初に自己紹介 稲田 高明 ACES ソフトウェアエンジニア ～ インフラからアプリまで手広く 13/45
14. 個人開発サービスの宣伝 “ずんだもん AI放送局“ で検索 案件ください！！ langgraph • langsmith • 全自動配信 • 14/45
15. まずは動かしてみる 「要件ドキュメント生成AIエージェント」を動かしてみる https://github.com/GenerativeAgents/agent-book chapter10 poetry run python -m documentation_agent.main --task "スマートフォン向けの健康管理アプリを開発したい" 実行すると、 途中経過のログは出ない(動いているのかちょっと心配になる) • 1分程で結果が返ってくる • 15/45
16. 実行結果の確認 (実行結果を確認し、コードをチラ見する) 16/45
17. どういう仕組み？ この「要件ドキュメント生成AIエージェント」は、Elicitronという論文を 元に実装されている 引用元: LangChainとLangGraphによるRAG・AIエージェント実践入門 p278 17/45
18. Elicitronフレームワーク 論文概要 Elicitron: An LLM Agent-Based Simulation Framework for Design Requirements Elicitation (2024) (12分) 18/45
19. 論文概要の構成 この論文概要の説明はそれなりに重いパート。頑張ってついてきて！ 背景と主要問題 • 論文の提供する解決策 • 論文の技術的優位性 • 論文の先行研究 (Empathic Lead User (ELU)インタビューの説明) • Elicitoronフレームワークの各構成ブロックの解説 • Elicitoronフレームワークのおさらい • 論文の制約と今後の課題 • 19/45
20. 背景と主要問題 従来の要求獲得手法は、多様なユーザー視点の不足や潜在的要求の抽出困 難、実施にかかる時間やコストの問題を抱える ユーザーリサーチの主要課題 ユーザーリサーチ 多様なユーザー視点 の不足 ・偏ったサンプリング ・少数派の意見が反映されない ・文化的背景の考慮不足 潜在的要求の 抽出困難 ・ユーザー自身が気づいていない ・言語化できないニーズ ・観察と解釈の難しさ 実施にかかる 時間・コスト問題 ・専門人材の確保 ・スケジュール調整の複雑さ ・分析作業の負担 20/45
21. [Elicitron] 論文の提供する解決策 LLMを用いたエージェントインタビューと分析により潜在ニーズを抽出 CoT(Chain of Thought)でユーザの多様性と潜在ニーズの抽出精度を向上 LLMエージェントによるユーザーリサーチの改善 Before After 従来の ユーザーリサーチ 多様なユーザー視点 の不足 潜在的要求の 抽出困難 実施にかかる 時間・コスト問題 LLMエージェント 活用型 ユーザーリサーチ 改善点 • 多様なペルソナのシミュレーション • エージェントインタビューによる 潜在ニーズの抽出精度向上 • 時間・コスト効率の大幅改善 多様なペルソナ設計 行動 シミュレーション エージェント インタビュー AI支援による 分析・抽出 21/45
22. [Elicitron] 論文の技術的優位性 潜在ニーズ抽出数を1.8倍(baseline比[1]) 出典:Elicitron: An LLM Agent-Based Simulation Framework for Design Requirements Elicitation. Fig.4 [1]:Lin, Joseph and Seepersad, Carolyn Conner. “Empathic Lead Users: The Effects of Extraordinary User Experiences on Customer Needs Analysis and Product Redesign.” 実施にかかる時間を 80時間(4時間/人x20人) → 2.3時間に短縮 時間 80h 2.3h 80h 2.3h 0 20 40 60 22/45
23. [Elicitron] 論文の先行研究 DETC2007/35302: “Empathic Lead Users: The Effects of Extraordinary User Experiences on Customer Needs Analysis and Product Redesign.” Empathic Lead User (ELU)インタビュー 通常のユーザに対して特別な状況をシミュレートし、インタビューを実施 することで潜在ニーズを抽出する 典型的な顧客の経験からの逸脱を考慮し、通常では見過ごされがちな潜在 ニーズを明らかにする 23/45
24. [Elicitron] 論文の先行研究(ELUインタビューの例) 「週末にキャンプをする、15〜30歳、健康で体力があり、年に数回キャン プをする人」に対して二人用テントの製品インタビューを実施 潜在ニーズ抽出数の比較 口頭インタビュー 0.2 プロトタイプ（テント）に触れず口頭でインタビューを受ける 明確化された使用 0.9 通常状態でテントを使用しながらインタビューを受ける 共感的リードユーザー 5.6 暗い部屋でオーブンミット着用してテント組立 (特殊環境での不便さをシミュレート) 厚手の手袋使用や関節炎の不器用さを模倣し、潜在ニーズを効果的に抽出 潜在ニーズを元にNemo Equipment社のSakoテント(空気注入式の支柱を持つテント)が製品化 24/45
25. Elicitron フレームワーク概要 ブロック構成： ・ユーザエージェント生成 ・製品体験生成 ・ユーザインタビュー ・ユーザニーズ抽出 25/45
26. Elicitron解説(ユーザエージェント生成) 多様性が最大となるようにユーザのペルソナを作成する 作成方法： 一つ前に作成したユーザとは異なる 典型的なユーザを順番に作成 さらに、非典型的なユーザをprompt 操縦(steer)で作成 26/45
27. Elicitron解説(ユーザエージェント生成) 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歳、健康で体力があり、年に数回キャン プをする人」 非典型なユーザ：「アドベンチャーを求めるティーン」「引退した自然愛好家」「身体障害 を持つ人」「遠征リーダー」「高地登山家」など 27/45
28. Elicitron解説(製品体験生成) ユーザインタビューで潜在的なニーズを特定するためのコンテキストとし て製品体験を生成する 多様なインタラクションのシミュレーション 具体的な利用シナリオの特定のための構造化 セットアップ • 特定機能の使用 • トラブルシューティングなど • 「行動 (Action)」 • 「観察 (Observation)」 • 「課題 (Challenge)」 • 28/45
29. Elicitron解説(製品体験生成) 例：「関節炎を患う高齢者」ユーザにテント利用に関する製品体験を生成 ステップ1： アクション：指の器用さが限られている状態で、テントの入り口のジッパーをつかもうと試みた。　　　　　　　　　　　　 観察：ジッパーが小さすぎて把持しにくく、操作が困難だった。 課題：テントの開閉に苦労し、イライラした。 ステップ2： アクション：テントのポールを組み立て、構造の上に生地を張ろうとした。 観察：テントポールを接続し、生地を引っ張るのに必要な力が、関節炎の痛みを悪化させた。 課題：指の力が弱く、痛みがあるため、組み立てが困難で時間がかかった。 ステップ3： アクション：テントを地面に固定しようとした。 観察：通常サイズの杭とハンマーを使う方法では、自分の状態では扱えないと感じた。 課題：テントを効果的に地面に固定できず、風の強い状況下での安全性が懸念された。 ステップ4： アクション：使用後、テントを片付けようとした。 観察：テントを畳んでバッグに収まるほどきつく巻くのに苦労した。 課題：この作業は肉体的にきつく、自分には必要な器用さと力が足りず、他人の助けを借りる必要があった。 29/45
30. Elicitron解説(ユーザインタビュー) 「質問プールの作成」「ユーザインタビュー」のタスクで構成される 質問設計プロセス 質問の種類と目的 インタビュー質問の作成 （人間またはLLM） ・自由形式の質問 ・カテゴリ別の質問 コンテキストを活用した質問 過去のQA履歴の活用 シミュレーション体験の反映 実践的で具体的な回答を 引き出す設計 適応的なカテゴリ選択 製品の種類に応じた 質問カテゴリの選択 エージェントの役割に応じた 情報収集の最適化 質問設計プロセスフロー 1 質問作成 2 コンテキスト活用 3 カテゴリ選択 4 質問の最適化 5 インタビュー 30/45
31. Elicitron解説(ユーザインタビュー) 生成されたユーザへの質問（例） 自由形式： 「理想的なテントを購入するとしたら、どのような主な特徴を求めますか？」 カテゴリ別： 「テントの[カテゴリ]の側面、具体的には、あなたのニーズと、 　それらのニーズに対応するための革新的な洞察を教えてください」 *カテゴリ:サイズ、形状、重量、素材、安全性、耐久性、美観、エルゴノミクス、コスト、セットアップ、輸送 質問: テントの設営という側面に特に焦点を当てて、あなたのニーズと、 それらのニーズに対応するための革新的なアイデアがあれば教えてください。 回答: 「…バッグから取り出すと自動的に展開し、自分で設営できる自己設営型のテント構造です。 手動でテントポールを接続したり、生地を伸ばしたりする必要がありません。 これは、スプリング式または形状記憶素材の技術を活用できるでしょう。 構造要素は、解放されると自動的に正しい形状と張力を得るように設計されています。」 31/45
32. Elicitron解説(ユーザニーズ抽出) ユーザ回答を元に"think step-by-step to detect the latent needs"で潜在ニー ズの条件に合致するかLLMに考えさせる 潜在ニーズの判定条件： 製品設計への重要な変更を表しており、サ イズ、形状、重量、素材、安全性、耐久 性、美観、エルゴノミクス、コスト、セッ トアップ、または輸送のカテゴリのいずれ にも該当しない場合 • 製品および/またはその使用方法に関し て、非常に革新的で明確に表現された洞察 を反映している場合 • 32/45
33. Elicitron解説(ユーザニーズ抽出) 潜在ニーズ: 「写真撮影のために広い視野を確保するために、指 定された開口部を通してテントの内部構造を再設計 する」 → 既存のカテゴリに当てはまらない製品設計への 重要な変更 潜在ニーズではない: 「鋭利なものや一般的な摩耗による裂けに強いテン トの床にする」 → 耐久性という既存のカテゴリに該当 33/45
34. Elicitronフレームワークのおさらい ステップ1 ELUエージェントの作成 典型的なユーザからの 逸脱に基づいて 複数のエージェントを作成 (実験では20人作成) ステップ2 特別な条件の シミュレーション 年齢、健康状態、 使用環境などの 特殊条件を想定 ステップ3 インタビューの実施 シミュレートされた 状況下でユーザに インタビューを実施 ステップ4 潜在ニーズの特定 インタビュー回答を 分析し、基準に基づいて 潜在ニーズをラベル付け 潜在ニーズの抽出方法プロセス 34/45
35. [Elicitron] 論文の提案する方法の限界または制約 入力 処理 出力 シミュレーションで生成されるニーズの質は、 設計者が提示する初期条件や文脈の設定に 大きく左右される マルチモーダルな情報（画像や音声など） との連携は今後の課題 LLMの出力品質や与える文脈に依存 最終的な要求選定や優先順位付けには 依然として専門家の介在が必要 35/45
36. 質問＆中休憩 (3分) 36/45
37. 10章「要件ドキュメント生成AIエージェント」 動かして理解を深める＆コードをひたすら読む (21分) 37/45
38. 輪読会の進め方 発言自由・質問歓迎： 気軽に意見や疑問を出し合い、学びを深める場にする。 • スライド不要・準備は最小限： 手間をかけず、気軽に参加できるようにする。 • 完璧を求めない： ざっくり理解でOK。わからない部分はみんなで考える。 • 38/45
39. コードスタディ: 処理の流れ(全体) 引用元: LangChainとLangGraphによるRAG・AIエージェント実践入門 p278 主要エージェント: PersonaGenerator • InterviewConductor • InformationEvaluator • RequirementsDocumentGenerator • 39/45
40. コードスタディ: 処理の流れ(レポートの生成) 以下の通り出力する構成をpromptで指定して要件定義書を作成 プロジェクト概要 • 主要機能 • 非機能要件 • 制約条件 • ターゲットユーザー • 優先順位 • リスクと軽減策 • 40/45
41. コードスタディ: 実装のポイント LLMまとめ 初期ペルソナ5セット作成 • 情報の不足に応じて動的にペルソナ追加 • AIエージェントによる包括的な要件収集 • 自動要件ドキュメント生成 • LangGraphワークフロー • Pydanticによる構造化データモデリング • 41/45
42. 個人的な気付き、ふと思ったこと 入力 処理 出力 要求の品質への依存 マルチモーダル入力への対応は今後の課題 作るものに応じたペルソナ作成 (新規SaaS、コンシューマ向け、DXではアプローチが違う) LLM品質への依存 DeepResearchのように処理をどう計画立案するかも AIがいずれ十分に頭が良くなって自分で考えるはず 先行研究の実験結果からユーザインタビューは 製品体験中に行うようシミュレートすると良さそう 42/45
43. 個人的な気付き、ふと思ったこと 作るものに応じたペルソナ作成も大事そう • 新規のSaaSプロダクト: ターゲットマーケット、自社の競争優 位性から導いたターゲットユーザのペルソナ設定 • コンシューマー向け: Elicitron同様潜在ニーズを探るアプローチ での多様なペルソナ設定（購買履歴、カスタマーの声の活用） • DX: 現場ユーザのペルソナ設定（実在の人物を設定しつつ、課 題ヒアリングをコンテキストとしてペルソナを作成する等） • cursorやclineがモックを自動で作ってインタビューを行うとcool • 結局、要件定義の元になる要求の質が大事 • 43/45
44. 振り返り この章では、Elicitronフレームワークをlanggraphで実装し以下を実現した ユーザインタビュー起点の要件定義プロセスの実装 • AI技術を活用した要件定義プロセスの効率化 • 多様な仮想ペルソナからの潜在ニーズの掘り起こし • 44/45
45. ご参加ありがとうございました 45/45