Best-Practices-for-Cortex-Analyst-and-AI-Agent

Transcript

1. © Finatext Holdings Ltd. 実例から学ぶ Cortex Analyst RFP 業務の自動化と AI Agent 連携のベストプラクティス 2026/01/21 株式会社ナウキャスト 池田遼太郎
2. © Finatext Holdings Ltd. 自己紹介 池田遼太郎 / Ryotaro Ikeda LLM エンジニア @株式会社ナウキャスト • Data AI Solution Domain 所属 • RAG や AI Agent の構築を主に担当 • 最近は AWS や Azure などのインフラ領域も担当 最近勉強していること • Claude Code：Subagent / Skills • MCP Server • 認証認可：OAuth + OIDC • 暗号技術 https://zenn.dev/shilla
3. © Finatext Holdings Ltd. 3 データAIソリューション事業 Data Service事業 ビッグデータを用いたプロダクトを提供する事業。 Data AI Solution事業 データとAIで顧客のDXを支援する事業。 Data Service Platform Unit 事業横断でデータ基盤の高度化、R&Dなどを行うチーム。 Financial Research Unit 内閣府や日本銀行、シンクタンクにマクロ経済分析 のデータ提供。また、機関投資家の投資意思決定を サポートするサービスを提供。 Real Estate Unit 商圏分析や売上予測モデルに よる店舗物件の診断サービス を不動産会社に提供する。 Data Holder Unit 提供元からデータを受領し、データパイプラインの構築を行うチーム。 Engineering Team データエンジニアリングと生成AI活用に精通した エンジニアリングチーム。 Consultant Team データとAIを用いたDXに特化したコンサルティ ングチーム。
4. © Finatext Holdings Ltd. 4 データAIソリューション事業 データエンジニアリング、生成AI、業務システムに関するソリューションを一気通貫で提供できることが強み 1 2 データエンジニアリングの専門性 2015年の創業以来POS、クレカ、位置情報、求人データ、ポイントカードなど様々なデータの 基盤を構築し、プロダクトを運用する中で、データ分析やデータエンジニアリングの知見を蓄 積。ナウキャストのエンジニアの大半はデータエンジニア。 生成AI、データ分析の専門性 機関投資家、官公庁などを対象としたデータ分析のSaaSを運用する中で、データ分析に関す る知見を蓄積。2023/4に「LLMラボ」を立ち上げ、社内外のプロジェクトを通じて生成AI関 連にも積極投資。 3 堅実なシステム開発能力 Finatext HDは証券サービスの基幹システム、デジタル保険の基幹システム、大手銀行のID 基盤など、様々なミッションクリティカルなシステムを運用。業務に関連するシステム開発では グループ間で連携を行い高品質な開発を実現。
5. © Finatext Holdings Ltd. 5 データAIソリューション事業 • ナウキャストはデータ基盤構築、データ分析、生成AIのPoC、業務システムの開発を一気通貫で提供することが可能です。 • 業務要件から逆算してデータ分析基盤を整備し、データ分析を行うことで、最短ルートでデータとAIを用いた業務効率化を実現し ます。 データ活用から生成AI活用までをフルサポート Step 1 要件定義 Step 2 データ基盤構築/運用 Step 3 データ分析支援 ・金融とデータ活用に知見のあるメ ンバーが、ビッグデータの利活用に 関する計画策定をご支援。 ・財務、顧客情報、市場データ、取引 情報、リスク管理、オルタナティブ データなど様々なデータを対象に データ基盤を構築。 ・構築後のインフラ管理やバッチ処 理のメンテナンスまでご支援。 ・データの目検チェックなどオペ レーション業務も外注可能。 ・リサーチ業務、リスク管理、営業な ど、様々な業務におけるデータ分 析のユースケースをご提案。 ・生成AIを活用した業務効率化/高 度化に向けたPoCの実施。 Step 4 業務への展開 ・分析を実際の業務へ展開するた めに必要な業務アプリケーション開 発を実施 ・データ活用から逆算した業務アプ リ設計、実装を実現。
6. © Finatext Holdings Ltd. Cortex Analyst で RFP 業務を効率化する
7. © Finatext Holdings Ltd. Cortex Analyst と Semantic View • Cortex Analyst とは、構造化データに対して Text2SQL ができる機能 • Semantic View という論理テーブルをもとに、SQL を生成して snowflake の DB からデータを取得 Fact: Select で取得する値 Dimension: 分析軸となるカラム Filter: where 句の条件 Metric: 集計済みの値 Logical Table Relationship: table 同士の関係性 Verified Query: 検証済みの質問とSQLのペア Custom Instruction: カスタム指示 出典：https://www.snowflake.com/en/blog/cortex-analyst-ai-self-service-analytics/ Semantic View / Model
8. © Finatext Holdings Ltd. RFP 業務とは • RFP 業務とは、資産運用会社のクライアント（機関投資家、公的/私的年金、銀行・証券会社<投資信託の販売会社>、年金コン サルタント等）から来る、運用商品に関する質問書に回答する形で資料作成を行うというもの。 • 運用商品の真髄から、昨今のトレンドに至るまで、幅広い情報を網羅。例えば、各運用商品に関して、どのような投資哲学や投 資戦略でアプローチしているのか、運用チーム構成、主要人物の経歴、過去数年のトラック・レコードや要因分析といったRFP の「基本の基」から、ESGの取り組みといった近年のトレンドまで包括的に全体像を捉える。 • ※一般的なシステム導入や業務委託などのプロジェクトを発注する際に作成する提案依頼書とは異なる。アセマネ業界特有の業 務。 RFP の質問例 RFP 業務における関係性図
9. © Finatext Holdings Ltd. RFP 業務フローの改善 Before After
10. © Finatext Holdings Ltd. アーキテクチャ図
11. © Finatext Holdings Ltd. RFP 回答業務支援システムの App を作成
12. © Finatext Holdings Ltd. 検証結果 • テストケース43件中 42件正解（97%） • しかし当初は 21件（47%）の精度しか出なかった、、、 • そこからどのように改善をしたのか
13. © Finatext Holdings Ltd. 検証を通して得た知見
14. © Finatext Holdings Ltd. やってみてわかった失敗のパターン • 高確率で Where 句条件に失敗する ◦ 日付指定のミス ◦ 存在しないカテゴリで条件設定する • Custom Instruction に記載の指示が反映されないことが多い • 同時に関連性の少ない2つ以上のテーブルの参照することが苦手
15. © Finatext Holdings Ltd. 高確率で Where 句条件に失敗する • 日付指定の失敗 → 具体性と情報粒度の整備 ◦ 問い合わせ文の修正： ▪ 「直近1ヶ月の売上合計」→ 「 2025年12月の売上合計」 ◦ Semantic View の修正： ▪ Dimension の粒度を統一もしくは複数用意する • 存在しないカテゴリを指定してしまう → Enum で縛る ◦ sample value + is enum ◦ 固定化されたカテゴリに対して有効 ◦ ※ Fact では is enum 設定不可
16. © Finatext Holdings Ltd. Custom Instruction に記載の指示が反映されないことが多い • Module Custom Instruction には「question_categorization」と「sql_generation」の2つの instruction がサポート • ただし、特定の条件下で考慮する Where 句条件や SQL の工夫を記載しても反映されないことが多かった • → AI Agent 側の system prompt を工夫し、Cortex Analyst の問い合わせ内容を改善することで解決 この指示はほとんどの場 合で無視される
17. © Finatext Holdings Ltd. • 単純な join による結合は OK • ただし別々の集計軸がある場合は分けないと、集計方法が混ざり正しい SQL が生成されない • 例：サンプル会社の 2025 年度の人員と資格保有者数の合計を教えて 同時に関連性の少ない2つ以上のテーブルの参照することが苦手 人員データ 資格データ 企業データ 年度 と 部署 で集計 年度 で集計 join join 人員データ 資格データ 企業データ 年度 と 部署 で集計 年度 で集計 join join 企業データ 一度に取得する 別々に取得する
18. © Finatext Holdings Ltd. Cortex Analyst の仕様からベストプラクティスを探る
19. © Finatext Holdings Ltd. Agentic workflow for answering a question 引用：https://www.snowflake.com/en/engineering-blog/snowflake-cortex-analyst-behind-the-scenes/
20. © Finatext Holdings Ltd. 想定されるベストプラクティス 質問の曖昧性を限りなく排除する（1クエリ = 1目的、1主要指標） ◦ 例：「昨年最も良かった製品は何ですか？」→「過去90日間の純売上高に基づく上位10商品を、地域別にグ ループ化して一覧表示して」 “why/施策/戦略” を混ぜない（まずSQLで算出可能な形へ分割） ◦ 例：「なぜ売上が減ったのか？」→「直近3ヶ月の売上の傾向を教えて」 指標を “業務定義済みの metric 名”として指定（“売上”が複数なら「総売上」「純売上」などに固定） Classification：質問のカテゴリ分類 “分類エージェントは、受信した質問を 「曖昧」、「データに関する質問」 、「SQL以外のデータに関する質問」 などのクラスに分類します。曖昧性がなく、 SQLを使用して回答できる質問にのみ回答します。その他のクラスの質問は拒否され、ユーザーには自信を持って回答できる類似の質問のリストが 表示されます。これにより、ユーザーが行き詰まるのを防ぎ、データに関する質問に対して信頼できる回答を継続的に得ることができます。 ” 要点：質問を “曖昧/非データ/非SQLデータ/… ”に分類し、SQLで答えられる明確な質問だけ通す。
21. © Finatext Holdings Ltd. 想定されるベストプラクティス • 時系列の粒度（daily/weekly/monthly）と期間（start/end）を明示 • ランキングする場合 top k を明示する • 期間比較をする際は “前年比/前月比/前年差” のどれかを明示し、比較対象期間を固定 Feature Extraction：特徴抽出 “分類後、特徴抽出エージェントが質問を分析して、その具体的な特徴を理解します。例えば、時系列に関する質問ですか？前期比の計算が必要で すか？順位計算が含まれますか？ Snowflakeのデータ分析ワークロード実行における豊富な経験を活かし、 Cortex Analystは幅広い機能からお選 びいただけます。” 要点： “時系列か、 PoP（期間比較）か、ランキングか ” のようなクエリの型を抜く
22. © Finatext Holdings Ltd. 想定されるベストプラクティス • よく使う質問はVQRに登録し、ユーザー入力は VQR の言い回しに寄せる（完全一致ではなく“類似度”狙 い） ◦ VQRがある場合、ユーザー入力に類似したVQR質問が最大5件提示され得る（= 類似度が効く） • 値リテラルは、semantic model の sample_values 等が精度に効く（＝値同定の支援） “コンテキストエンリッチメントエージェントが、質問への回答に関連する追加のコンテキストを用いてセマンティックモデルを処理します。このようなエン リッチメントは、ビジネスユーザーの質問に回答する際に不可欠です。ビジネスユーザーの質問には、必要なコンテキストが不足している場合がありま す。取得されるコンテキストには、主に「 VQR」と「関連リテラル」の 2種類があります。” Context Enrichment：Context の充実化 要点：VQR（Verified Query Repository）の類似検索や、値リテラルの検索で精度を上げる
23. © Finatext Holdings Ltd. 検証を効率よく進める
24. © Finatext Holdings Ltd. • Suggestion の種類 ◦ クエリ履歴からの Fact の提案 ◦ VQR の提案 ◦ Filter、Metrics の提案 ◦ 使用状況データからの VQR 提案 ◦ ※ Dimension の提案はない • よくある提案 ◦ Fact ▪ 加工 Fact の生成 ▪ カテゴリ値の Flag 作成 ◦ Filter ▪ 期間指定 ▪ 除外指定 Suggestions の活用
25. © Finatext Holdings Ltd. • Monitoring 機能で Cortex Analyst を実行した全てのログを閲覧可能 • 得られる情報 ◦ 質問したユーザー ◦ 質問内容 ◦ 生成された SQL ◦ エラーおよび/または警告 ◦ リクエスト本文と応答本文 ◦ その他のメタデータ ▪ Latency ▪ Action path ▪ Is semantic sql ▪ Model ▪ Question category Monitoring 機能からログを分析する SELECT * FROM TABLE( SNOWFLAKE.LOCAL.CORTEX_ANALYST_REQUESTS ( '<semantic_model_or_view_type>' , '<semantic_model_or_view_name>' ) );
26. © Finatext Holdings Ltd. Discussion
27. © Finatext Holdings Ltd. ドメイン知識をどこに入れるべきか？ AI Agent Cortex Analyst Snowflake DB Semantic View / model Description Custom Instruction Fact, Dimension, Filter, Metric の description Description Table Column Comment Agent System prompt Tools Description Process What How / What How • 理想は Semantic View だが、性能的にまだ Agent の System prompt が良さそう 情報の役割 情報の置き場所
28. © Finatext Holdings Ltd. まとめ • Cortex Analyst の仕組みをしっかりと理解した上で使いこなす ◦ Cortex Analyst の精度 = 問い合わせ内容の工夫 × Semantic View の整備 ◦ 問い合わせ内容は曖昧性を排除し、範囲の指定をより詳細にする ◦ Semantic View は VQR と Enum 設定で最適化 • AI Agent と Cortex Analyst を組み合わせる際は、役割分担を明確に ◦ ドメイン知識は Agent 側に寄せる ◦ Cortex Analyst はデータと Agent の架け橋