CodeAgentとMCPで実現するデータ分析エージェント

Transcript

1. CodeAgentとMCPで実現 するデータ分析エージェン ト 村脇 光洋 CA DATA NIGHT #6
2. 自己紹介 村脇 光洋 職種：サーバーサイド 所属 : AI事業本部 アプリ運用カンパニー ➡ AI POS カンパニー (2025/1~) 業務内容: ◦ 小売業/メーカー向けデータ分析SaaS開発 2
3. Table of Contents 1. プロダクト紹介「AI POS」 2. 事例紹介 : 分析コンテンツの開発速度を向上させるLLM利用 3. LLM領域の技術選定 3
4. プロダクト紹介「AI POS」 4
5. AI POS とは？ 5
6. AI POS とは？ 6 メールレポート チャット 小売業・製造業の方に 情報を提供
7. AI POS の システム構成 7 メール レポート チャット 多くの分析メニュー
8. ユーザの質問に応じた分析を、 LLMによる生成は行っていない （データの正確性が求められるため） AI POS におけるLLMの活用ポイント 8 メール レポート チャット 多くの分析メニュー
9. AI POS におけるLLMの活用ポイント 9 多くの分析メニュー 分析メニュー開発をLLMエージェントで高速化
10. 分析コンテンツの開発速度を向上させる LLM利用 10
11. LLMを利用した分析メニュー開発のフロー 11 ① 分析エージェントを利用して分析メニューの プロトタイプを作成する ② Cursorで事前定義済み(mdc)の設計パターン に則ってプロトタイプをプロダクションコード化 ③ 人間がチェック・修正。品質を担保
12. LLMを利用した分析メニュー開発のフロー 12 ② mdcファイルに事前定義済みの設計パターン に則ってプロトタイプをプロダクションコード化 ③ 人間がチェック。品質を担保 ① 分析エージェントを利用して分析メニューの プロトタイプを作成する 今回はこの分析エージェントの話をします
13. 分析エージェント（実際のUI） 13 プロファイル（利用ツールなどエージェント設定）選択 プロファイル（利用ツールなどエージェント設定）選択 ツール群（MCPなどで連携）選択 分析定義 入力
14. 分析エージェント（実際のUI） 14 カテゴリ情報 step1: カテゴリ情報取得 ※一部情報をマスクしています
15. 分析エージェント（実際のUI） 15 ※一部情報をマスクしています step2: Queryを記述して データを取得
16. 分析エージェント（実際のUI） 16 ※一部情報をマスクしています step3,4: 取得したデータを 加工して可視化
17. 分析エージェントの効果 17 • 分析メニューの開発工数を1/3以下に圧縮 • 最終アウトプットを事前にメンバーが見ながら議論ができる • PMなど、開発メンバー以外でも分析メニューの作成ができる
18. 分析エージェントの構成 18
19. 分析エージェントの構成 19 エージェントの実装について
20. エージェントの実装 20 • フレームワークにHugging Face社の「smolagents」を採用 • 特徴 ◦ 動作原理にCodeActを採用 ◦ 最小限の機能。ワークフローが組めない ◦ MCP対応 ◦ OpenTelemetry準拠 ◦ LLMモデルの切り替えが容易(litellm)
21. smolagentsの特徴 : CodeAct 21 関連 ReAct: https://arxiv.org/abs/2210.03629, CodeAct: https://arxiv.org/abs/2402.01030 （画像はCodeActの論文より引用） 従来のエージェントは、ツールとツールの繋ぎ込みに課題があった • 既存アプローチではjsonがtoolの インターフェース • toolの結果が、別のtoolへと渡さ れる時に欠損する • 扱う値の変換も容易ではない • CodeActはツール呼び出しを Python上で行うことで、それら の課題を解決
22. smolagentsの特徴 : CodeAct 22 具体例 : 先の分析の例 step2 sqlを実行し、結果を result変数に格納
23. smolagentsの特徴 : CodeAct 23 step4 step2で取得したresultを DataFrameとして利用 Pandasの機能を使って可視化するた めに、データをPython上で加工 Pythonの表現力を使って振る舞うこ とができる 具体例 : 先の分析の例
24. LLM領域の技術選定 24
25. 分析エージェントの構成 （再掲） 25
26. 分析エージェントの構成 （再掲） 26 なぜツール定義にMCPを採用？ なぜワークフローが組めないフレームワークを採用？
27. 分析エージェントの構成 （再掲） 27 なぜツール定義にMCPを採用？ なぜワークフローが組めないフレームワークを採用？ LLM関連領域の技術発展が日進月歩なため
28. LLMとその周辺の技術状況 28 • 最高性能のモデルはすぐに更新される • エージェント/ワークフローツールは 乱立している • LLMにデータ、ツール、文脈を与える 手法も日夜開発されている 出典: https://www.insightpartners.com/ideas/ai-agents-disrupting-automation/
29. ベストプラクティスの覆りやすさ 29 エージェント部 : 高 基盤モデルの性能向上や、新手法、新プロダクトによって覆される （マルチエージェントの自社開発そのものがほぼ不要になるかも）
30. ベストプラクティスの覆りやすさ 30 ツール部分: 中 現在は多くのエージェントがMCPに対応しているので、すぐに使 えなくなることはない しかしE2B(仮想環境ベースの文脈付与)など別の手法が主流になる可 能性はある
31. ベストプラクティスの覆りやすさ 31 ツールが参照する自社情報の整備 : 低 （例: データベースのスキーマ、APIの仕様） MCPで繋いだとしても、メタ情報や活用すべきドメイン知識が、 アクセス可能な形で言語化されていないと、エージェントの性能 が高くても最大限の性能を出せない
32. 技術の発展を考慮したチームリソースの投下 32 自社が投資しなくても進歩していく 自社が投資しないと進歩しない エージェント最適化 選択肢が移り変わりやすい 選択肢が変化しづらい MCP対応 LLMリーダブルに情報を整備 すぐ乗り換えられる ように、軽量に実装 新しいMCPクライア ントをすぐに試すこ とができるので、 できるだけ対応 一定コストを払って整備 例: APIドキュメントを充実化 データベースを一般的な規格にし て、固有表現をなるべく排除。メ タデータを可能な限り付与
33. まとめ 33 • smolagentsで分析用のエージェントを開発 ◦ CodeActは複数ツール連携や、データ加工にPythonの表現 力を使えることが利点 • LLM領域の移り変わりが激しいことを考慮して技術選定を実施 ◦ 『エージェント ＜ MCPのツール ＜ 元となるリソース 』の 優先順位で力を入れて整備すると報われやすいのでは？