生成AIで構築する自律型企業調査アシスタント

Classmethod Odyssey DevelopersIO 2024 Online セッションで登壇した内容です。

・セッション概要
企業名からLLMがクローリングを行い、企業情報をリサーチするSlackBotを開発しました。
生成AIを組み込んだアプリ開発の実践的ノウハウを、技術選定、インフラ構成、開発・デバッグ方法などの観点からご紹介します。

Transcript

1. ⽣成AIで構築する ⾃律型企業調査アシスタント 2024/7/11 リテールアプリ共創部 ⾦城秀哉
2. Xへの投稿の際は、 ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い
3. ⾃⼰紹介 3 ⾦城 秀哉(Shuya Kinjo) • リテールアプリ共創部 マッハチーム • サーバーサイドエンジニア • 興味‧関⼼ ◦ IaC、CI/CD、業務効率化、⾃動化
4. ⽣成AIを⽇々の業務で どのように使⽤していますか？ 4
5. 業務における⽣成AIの活⽤度合い 5 • AIをシステムに統合 • ビジネス固有ニーズへ対応 • タスクに特化したAIツールを選択 • 複数のAIを組み合わせる • 基本的な対話型AI活⽤ • 幅広い⽤途に対応 • タスクに応じてAIをカスタマイズ • GPTs、OpenAI Assistants APIを利⽤して 独⾃のアプリ開発 タスクに応じた AIのカスタマイズ タスク毎にツール/ モデルを使い分け ChatGPTの利⽤
6. 業務における⽣成AIの活⽤度合い 6 • タスクに特化したAIツールを選択 • 複数のAIを組み合わせる • 基本的な対話型AI活⽤ • 幅広い⽤途に対応 • タスクに応じてAIをカスタマイズ • GPTs、OpenAI Assistants APIを利⽤して 独⾃のアプリ開発 タスクに応じた AIのカスタマイズ タスク毎にツール/ モデルを使い分け ChatGPTの利⽤ • AIをシステムに統合 • ビジネス固有ニーズへ対応
7. • フレームワークは使うべき？ • インフラは普通のアプリと同じで良い？ • AIにどこまで任せるべき？ • AIが中々⾔うことを聞いてくれない • etc… AI搭載アプリ開発の検討事項 7
8. 考えることが沢⼭🤯 8
9. この30分で話すこと 1. 構築したアプリ(企業調査ツール)の説明 2. 技術選定のポイント 3. ⽣成AIアプリ実装時のTips 9
10. さらに⽣成AIを使いこなしたい⽅ • ⼀歩進んだ活⽤⽅法のヒントを得る • AI搭載アプリの開発に興味を持ってもらう 既に⽣成AIをアプリに組み込んでいる⽅ • 実装パターンの選択肢を増やす • SlackBot、クローラー実装のノウハウを知る このセッションのゴール 10
11. 企業調査ツールについて 11
12. リテールアプリ共創部について 12
13. お客様のビジネスを 深く理解したい 13
14. 企業調査ツールとは • 顧客理解のため補助ツールとして開発 ◦ ⼿作業で⾏っていた調査業務を半⾃動化 • クローリング、スクレイピング、要約、  考察で⽣成AIを使⽤ • SlackBotのインタフェースで提供 14
15. 動作イメージ 調査対象の企業名を⼊⼒ 15
16. 動作イメージ 企業名を元にURLを収集 16
17. 動作イメージ Markdown形式で 調査結果を出⼒ 17
18. 2つの⼊⼒パターンで調査 18 企業名からの調査 情報源を与えて調査
19. 情報源を与えて調査 19 ⼊⼒されたMarkdownをパース HTML 内部データ モデル ‧調査項⽬ ‧URL ‧AIへの指⽰
20. 情報源を与えて調査 20 情報収集‧要約 URL 調査結果 AIへの指⽰ HTML 要約‧整形 抽出‧考察
21. 経営理念 情報源を与えて調査 21 企業課題の考察‧レポート出⼒ 財務状況 沿⾰ 会社概要 etc.. 調査 レポート AIへの指⽰ 企業課題の 考察 調査結果
22. 企業名からの調査 22 企業名から情報源をWeb検索 🔍クラスメソッド 会社概要 🔍クラスメソッド 財務状況 🔍クラスメソッド 沿⾰ 🔍クラスメソッド 経営理念、etc.. 企業名からの調査
23. 企業名からの調査 23 Web検索結果 🔍クラスメソッド 会社概要 🔍クラスメソッド 沿⾰ 内部データ モデル ‧調査項⽬ ‧URL ‧AIへの指⽰ 結果を精査
24. 既存のAIツールとの違い • より詳細な調査結果 ◦ 調査項⽬毎に、複数ターンの要約と考察処理を1つの レポートにまとめる • 既存の運⽤へ取り込みやすい ◦ UI/UX設計のため毎回調査業務を⾏うデザイナーに も協⼒依頼 ◦ ⾃動調査後⼿作業で⾁付けしやすいフォーマット 24
25. 技術選定のポイント 25
26. • ⾔語：Python • フレームワーク ◦ LangChain、SlackBolt • インフラ(AWS) ◦ Lambda、CloudFront、AWS WAF ◦ Amazon Bedrock ◦ AWS CDK • ⾔語モデル ◦ Claude 3 Haiku, Sonnet 採⽤した技術スタック 26
27. • ⾔語‧フレームワーク • インフラ構成 • ⾔語モデルの選定 技術選定のポイント 27
28. LangChainについて • ⽣成AIを活⽤したアプリ開発のための オープンソースフレームワーク • LLMの機能を拡張し、外部データソース と統合することが可能 • Python/JavaScriptで利⽤可能 ◦ Python版の⽅が機能‧ドキュメント  共に充実している 28
29. 1. 統⼀されたインタフェースの提供 2. LLMと外部リソースの統合 3. 出⼒フォーマットの整形 LangChainの良かった点 29
30. 統⼀されたインタフェースの提供 • 外部リソース(Vector DB)の切り替えのPR ◦ 変更点はほぼこれだけ 30
31. 統⼀されたインタフェースの提供 31 • ⾔語モデルの切り替えでも同様 ◦ Bedrockで未提供のモデルへ変更するPR
32. 統⼀されたインタフェースの提供 • 抽象化により変更に強い設計‧実装が可能 • トライアル&エラーで進める上で変更容易性 は重要 32
33. LLMと外部リソースの統合 • クローリングに特化したツール ◦ Sitemap ▪ サイトマップ配下の全てのページをクロール ◦ Recursive URL ▪ 指定したURL配下のURLを再帰的に読み込む 33
34. LLMと外部リソースの統合 • Web検索を統合 ◦ Google Search API ▪ Google検索のAPI版 ◦ Tavily Search API ▪ LLMとRAGに最適化された検索エンジン ◦ SerpAPI ▪ Google、Bingなど数⼗種類の検索エンジンから データ取得 34
35. • 外部のデータストア、API、サービスとの連 携が数多く提供されている • アプリケーションロジックの実装に集中で きた LLMと外部リソースの統合 35
36. • LLMの出⼒はJSON形式にしたい ◦ LangChainがなければプロンプトで頑張る 出⼒フォーマットの調整 36
37. • LLMの出⼒はJSON形式にしたい ◦ LangChainがなければプロンプトで頑張る 出⼒フォーマットの調整 37 わかりました。以下が処理結果です。 { "result": "success" }
38. • LLMの出⼒はJSON形式にしたい ◦ LangChainがなければプロンプトで頑張る 出⼒フォーマットの調整 38 わかりました。以下が処理結果です。 { "result": "success" } JSON Decode Error
39. • Structured Output ◦ 出⼒形式の構造体をPydanticで定義 ◦ 構造体を渡すだけで出⼒形式を指定可能 出⼒フォーマットの調整 39
40. 出⼒フォーマットの調整 • 出⼒フォーマットをPythonの構造体で指定可能 • プロンプトでの直接指定より安定した出⼒を提供 • モデルがJSONモードを提供している場合は併⽤ も可能 40
41. • ⾔語‧フレームワーク • インフラ構成 • ⾔語モデルの選定 技術選定のポイント 41
42. サーバレスで始める • 最初は検証から始めたい • 検証段階ではあまりコストをかけたくない →まずはサーバレス構成で検討する LLMの課⾦以外は、ほぼ無料で運⽤中 42
43. よくあるサーバレス構成 43
44. よくあるサーバレス構成の問題 44 API Gatewayが29秒で 強制的にタイムアウトし てしまう 使⽤するモデルによって は処理時間を要す
45. Lambda 関数 URLの利⽤ 45
46. Lambda 関数 URLの利⽤ 46 ‧HTTPエンドポイントを直接公開 ‧最⼤15分まで処理可能に
47. よりセキュアに公開する場合 47 CloudFrontを置くこと で、WAFの配置やカスタ ムドメインが設定可能に
48. Lambda 関数URLのOAC対応 48 参考: https://aws.amazon.com/jp/about-aws/whats-new/2024/04/amazon-cloudfront-oac-lambd a-function-url-origins/
49. よりセキュアに公開する場合 49 2024/4にOACがLambda Function URLsに対応 アクセスコントロールが 簡単に！
50. よりセキュアに公開する場合 50 OACはPOST/PUTに未対応 従来通りLambda@Edgeで SigV4の署名が必要
51. 参考: https://dev.classmethod.jp/articles/cloudfront-lambda-url-sigv4-signer/ Lambda＠Edgeで署名 51
52. 別案：SQSで⾮同期化 52
53. 53 キューを⼊れた時点で 正常応答を返す ワーカーが⾮同期で リクエストを処理する 別案：SQSで⾮同期化
54. • ⾔語‧フレームワーク • インフラ構成 • ⾔語モデルの選定 技術選定のポイント 54
55. Amazon Bedrock • ⽣成AIアプリ構築のためのフルマネージド サービス • 複数のAI企業が提供するLLMを単⼀APIで利 ⽤可能 • LLMの請求をAWS利⽤費にまとめられる • 複数のモデルを同時に⽐較‧検証 • エージェントやRAG構築も統合 55
56. Claude 3 • 多くのベンチマーク、コスト⾯でOpenAIのGPT-4を上回 る性能 • 3つのモデルを展開 ◦ Opus（最⾼性能）、Sonnet（バランス型）、Haiku （⾼速‧低コスト） ◦ 現在はClaude 3.5 Sonnetが最新でOpusを上回る • タスクに応じて使い分け ◦ 要約：Haiku、考察：Sonnet 56
57. ⽣成AIアプリ実装時のTips 57
58. ⽣成AIアプリ実装時のTips 1. Agent vs Chain 2. ⽣成AIで処理 or ⾃前実装の判断 3. ⼩さく始める 4. プロンプトの調整 5. 完璧を⽬指さない 6. クローラー実装時の注意点 58
59. Agent と Chainの⽐較 • Agent ◦ LLMにツールを与え、LLM⾃⾝に動的に⾏動を決定させる ▪ 例)思考→⾏動(ツール)決定→実⾏→結果を元に再考→...出⼒ ◦ 汎⽤的なタスクを実⾏可能 ▪ 処理フローがLLMの出⼒結果に左右される ▪ LLMの呼び出し回数が増える(コスト‧レイテンシー増) • Chain ◦ 事前定義した⼀連のアクションを実⾏する ▪ 例)プロンプト⽣成→データ収集→推論 ◦ 特定のタスクに特化 ▪ 従来のプログラミングに⼀部AIを組み込む形 ▪ 動作が安定し、コスト‧レイテンシーも実装次第で下げられる 59
60. Agent と Chainの⽐較 • Agent ◦ LLMにツールを与え、LLM⾃⾝に動的に⾏動を決定させる ▪ 例)思考→⾏動(ツール)決定→実⾏→結果を元に再考→...出⼒ ◦ 汎⽤的なタスクを実⾏可能 ▪ 処理フローがLLMの出⼒結果に左右される ▪ LLMの呼び出し回数が増える(コスト‧レイテンシー増) • Chain ◦ 事前定義した⼀連のアクションを実⾏する ▪ 例)プロンプト⽣成→データ収集→推論 ◦ 特定のタスクに特化 ▪ 従来のプログラミングに⼀部AIを組み込む形 ▪ 動作が安定し、コスト‧レイテンシーも実装次第で下げられる 60 今回はChainで実装
61. ⽣成AIを適⽤した箇所 61 プログラミングでは 解決しにくい課題に 対してのみ適⽤
62. ⽣成AIを適⽤した箇所 62 Web検索結果と 調査対象企業の関連度を 判断しURL収集 企業情報の要約‧抽出‧ 整形‧考察 様々な企業HPのDOM構 造を解釈するスクレイピ ング処理
63. 全てを⽣成AIで実装も可能 63 ⼊⼒⽂字列からWeb検 索キーワード⽣成 企業情報の要約‧抽出‧ 整形‧考察 検索結果の スクレイピング Markdownから 内部データモデルへ変換 出⼒結果の整形 検索結果の 関連度判定 パターン判定
64. • ScrapeGraphAI ◦ 当初はこちらで実装を検討 ◦ LLMにかかるコスト⾯の懸念 ◦ ここまでの汎⽤性は要らず不採⽤ 実際にやっているOSSもあります 64
65. ⽣成AIアプリ実装時のTips 1. Agent vs Chain 2. ⽣成AIで処理 or ⾃前実装の判断 3. ⼩さく始める 4. 完璧を⽬指さない 5. クローラー実装時の注意点 65
66. ⼩さく始めて価値を検証する 66 クローラーの実装は 後回し
67. ⼩さく始めて価値を検証する 67 クローラーの実装は 後回し 情報源を与えるパターンで ⼩さく作って検証
68. ⼩さく始めて価値を検証する 68 • Web検索を統合し た他のAIツールよ り、特定タスクに 特化した企業調査 ツールを作ること の価値を確認 情報源を与えるパターンで ⼩さく作って検証
69. ⽣成AIアプリ実装時のTips 1. Agent vs Chain 2. ⽣成AIで処理 or ⾃前実装の判断 3. ⼩さく始める 4. 完璧を⽬指さない 5. クローラー実装時の注意点 69
70. 完璧を⽬指さない • ハルシネーションは0にはできない • 全てAIで完結させるのではなく、⼈が⼊る前提で 運⽤を組み、補助ツールの⽴て付けとする ◦ ⼈がチェックしやすいように情報取得元のURL を添付 ◦ AIの調査結果を元に、⾃分の⼿で⾁付けした⽅ が企業理解が進むと⾔う事情もあり 70
71. ⽣成AIアプリ実装時のTips 1. Agent vs Chain 2. ⽣成AIで処理 or ⾃前実装の判断 3. ⼩さく始める 4. 完璧を⽬指さない 5. クローラー実装時の注意点 71
72. クローラー実装時の注意点 • 対象サイトのrobots.txtを遵守する ◦ クローリング可能な範囲、リクエスト間隔を守る • サーバーへ負荷を与えない ◦ 10秒以上のクールダウンが推奨 ◦ Lambdaの同時実⾏数やSQSで多重度を制御可能 • エラーハンドリングを適切に実装する ◦ 無限ループ、意図せぬリクエスト増を防ぐ 72
73. まとめ 73
74. このセッションで話したこと 1. 構築したアプリ(企業調査ツール)の説明 2. 技術選定のポイント 3. ⽣成AIアプリ実装時のTips 74
75. まとめ • LangChainで開発⼯数を⼤幅に削減できる • インフラはサーバレスを推奨 ◦ Lambda Function URLsだとシンプルな構成に • AWSで作るならAmazon Bedrockの採⽤を推奨 • ⽣成AIの組み込みは本当に必要な箇所のみ • 最初は⼩さく検証を始める • 全てをAIで完璧にこなそうとしない • クローラーは節度を持って実装する 75
76. さらに⽣成AIを使いこなしたい⽅ • ⼀歩進んだ活⽤⽅法のヒントを得る • AI搭載アプリの開発に興味を持ってもらう 既に⽣成AIをアプリに組み込んでいる⽅ • 実装パターンの選択肢を増やす • SlackBot、クローラー実装のノウハウを知る このセッションのゴール 76
77. • ⼀緒に開発を進めていただいた ◦ たにもんさん、あんでぃさん、さけさん • 仕様‧運⽤の相談に乗っていただいた ◦ スギヤマさん • 検証‧フィードバックしていただいた ◦ マッハチームのみなさん Special Thanks! 77