RAG×実サービス運用の最前線 1,000件のデータ依頼を、 検索できる経験知に変える アナリスト支援 RAG エージェントの設計 CTO室 AI Solution Development グループ 齊藤 拓己 

齊藤 拓己 Sansan株式会社 技術本部 CTO室 AI Solution Developmentグループ 筑波大学大学院（博士: 工学） - 機械学習応用（進化アルゴ、深層学習が主） 『Pythonではじめるオープンエンドな進化的アルゴリズム』 2025年4月より新卒入社 アナリティクスエンジニア / データエンジニア / AIエージェント開発 - Sansan AIエージェント開発 社内データ利活用 

Sansan株式会社の働き方を変える AXサービス 生産性を向上させ、企業の AI活用を最大化するデータベースとしても貢献できる 「働き方を変える AXサービス」を提供します。 法人向け 個人向け AI契約データベースが、利益を守る 「なくせる」をつくり、全社の働き方を変える 営業 AXサービス 取引管理サービ ス 経理 AXサービ ス 営業 契約 請求 名刺データベースが、収益を最大化する 名刺アプリ 名刺 管理 データクオリティマネジメント 各サービスの活用で変わる働き方 必要な情報を 情報の管理がしやすく 情報を分析・活用しやすく すぐに見つけられる すぐに共有できる データに基づいた判断ができる 3 

Agenda - 方々からのデータ分析基盤への依頼 - 依頼者との会話履歴が Slack, Notion に溜まっているが探せない - AIエージェントで過去事例を検索するための設計 - 過去事例のインデックス構築 - アナリスト支援のための出力 - まとめと展望 

過去の対応経験を、次の依頼に活かす 

背景 エージェント 検索 出⼒ まとめ 全社横断データ分析基盤には、全社から依頼が集まる データソース 利⽤ プロダクトDB Salesforce ダッシュボード 全社データ基盤 BigQuery + dbt アドホック分析 ⾏動ログ 1,000+ 対応記録 依頼者は営業‧CS‧マーケ‧企画‧エンジニアまで データだけでなく、データに関する相談も⼀か所に集まる 6 

背景 エージェント 検索 出⼒ まとめ 過去の対応経験が、次の依頼に役⽴つ ‧ 指標の定義 — 件数か利⽤率か。分⺟の取り⽅で結論が変わる ‧ 使ったデータ‧確認事項 — どのデータを使い、依頼者に何を確認したか ‧ 制約‧落とし⽳ — 編集権限がなく運⽤できなかった、等の失敗 似た事例を知っているだけで、最初のヒアリングと設計の質が変わる 7 

背景 エージェント 検索 出⼒ まとめ 記録はあるが、必要な知⾒を掘り起こせない ‧ 知⾒が Slack‧Notion‧SQL‧成果物に分散している ‧ 同じ相談が、過去には別の件名で残っていることもある ‧ 事例を覚えている⼈に聞くか、⼿作業で⻑いスレッドを読み直す 記録はある。でも、どこに何があるかを知る⼈に依存している 8 

過去の知見を掘り起こす、 アナリスト支援エージェント 

背景 エージェント 検索 出⼒ まとめ 過去事例を踏まえた対応計画を作る 新しい依頼 過去事例を調査 対応⼿順を整理 アナリスト対応計画 誤りの影響を限定し、レビューできる位置に置く 10 

背景 エージェント 検索 出⼒ まとめ Slack のやりとりを、検索可能な過去依頼へ変換する 要約 依頼スレッド（原⽂） 決済関連データを⾃ら抽出したい依頼（項⽬追加→抽出環境へ発展） 依頼者 ダッシュボードに決済関連の 項⽬を追加したい。ゆくゆくは goal problem request ⾃分で確認し依 SQL に時間、他 項⽬追加‧仕様 頼を減らす 部署依存 確認 SQL 不要で⾃由 複数テーブルに セルフ抽出環境 に抽出 分散 の構築 ⾃部署で SQL を書かずに確認 LLM 抽出 アナリスト initial 項⽬追加より、抽出環境では？ 依頼者 final それが理想です ⼀本の対話から、複数の検索表現を取り出す 11 

背景 エージェント 検索 出⼒ まとめ search と fetch を繰り返し、対応計画を作る search — ハイブリッドで候補をまとめて取得 要約を読む fetch — 有望な原⽂‧成果物を読む 再検索 — 得た語彙で探し直す 対応計画 検索単位は軽い索引、判断単位は原⽂ 12 

エージェント実用化のための 2つの設計課題 検索: どう表現するか ／ 出力: どう渡すか 

背景 エージェント 検索 出⼒ まとめ 課題1 ― ⼀つの要約で、過去依頼を代表できるか ⼀本のスレッド ‧依頼 / 背景の⽬的 ‧ヒアリングで判明した問題 1 つの要約 1 ベクトル ‧対応⽅法 ‧固有の指標名‧テーブル 問い: 今回必要な⼀致を、保持できるか？ ‧権限の制約 実運⽤の失敗ではなく、⽐較基準として要約 1 本を再現して確かめた 14 

背景 エージェント 検索 出⼒ まとめ 実例 ― 関連する過去事例が、要約検索では埋もれた 新規依頼: ダッシュボードに項⽬を追加し、将来は⾃部署で SQL を書かず確認したい 関連する過去事例: 別部⾨の項⽬追加依頼。利⽤者⾃⾝が確認できる状態を作った（編集権限が壁） 要約のみをベクトル化 goal / problem / requestなどを個別にベクトル化 100 位以下 上位数件 上位から原⽂を読む運⽤では到達できない 依頼時点の request が⼀致して上位に残る 同じ原⽂‧同じ埋め込みでも、何を索引に残すかで知⾒への⼊⼝が変わる ※ 実データで 125 位 → 7 位。 15 

背景 エージェント 検索 出⼒ まとめ 原因 ― 要約全体では、依頼内容の強い⼀致が⽬⽴ちにくくなった request に対する検索 要約に対する検索 新規 ≒ 過去（ほぼ同⼀） 同じ request が、固有詳細に埋もれる 「既存ダッシュボードへ 指標名‧テーブル‧編集権限‧ 項⽬を追加してほしい」 → 検索上の⼀致が強く表れる 代⾏作業‧対応結果… → 検索上の⼀致が弱く表れる 要約は情報を失ったのではなく、単⼀観点の強い⼀致を希釈した 16 

背景 エージェント 検索 出⼒ まとめ ⼯夫 ― 依頼を時点と観点に分け、複数の検索⼊⼝を残す goal problem request initial 検索表現 検索表現 検索表現 final 検索表現 検索表現 検索表現 原⽂（fetch 先として別保存） 今回⼀致したのは initial × request ⼀つの要約へ統合する前の違いを、検索⼊⼝として残す summary も参照⽤途で併存。時点分離は設計軸（この例が実証したのは希釈回避） 17 

背景 エージェント 検索 出⼒ まとめ 検索する事例が変わると、得られる知⾒も変わった 要約のみをベクトル化 取得した事例 別システムの設定状況‧更新 レポートの核⼼ 設定確認が中⼼ goal / problem / requestなどを個別にベクトル化 取得した事例 他部署依存の解消‧編集権限 レポートの核⼼ ⾮エンジニアの⾃律確認‧ 編集権限の確認 観点分解は順位だけでなく、原⽂の有⽤な知⾒への⼊⼝を残した 18 

一方、出力にも同じ問題があった 詳しい対応計画は、判断を助けなかった 

背景 エージェント 検索 出⼒ まとめ 課題2 ― 詳しい対応計画ほど、読む負担が⾼くなった Before: 対応計画（初期版の出⼒例） 1 知⾒が⼿順に埋没 【対応計画】ダッシュボード項⽬追加 2 参照が ID の羅列 1. 対象DBとデータソースの特定 - 既存データソースに含まれるか 3 未確認のデータ実体を⽣成 - 過去に複数指標を追加した例 （参照: 17xx…） - svc_x_dashboard_source_v2 の利⽤も検討できます 2. 最新データ表⽰の仕様確認 - 定期更新の失敗時は⼿動対応 （参照: 17xx…） 3. フィールド追加の実装 - 不⾜フィールドを追加します …（さらに続く） 進め⽅はアナリストが考えられる。 欲しかったのは、 ● 過去の判断と、 ● まだ分かっていないこと エージェントが仕事を完成させようとするほど、読む負担が増えた 20 

背景 エージェント 検索 出⼒ まとめ ⼯夫 ― 知⾒‧不明点‧根拠を、計画から分離する Before After ‧ 計画が中⼼ ‧ 過去事例からの知⾒ ‧ 知⾒と根拠が⼿順に埋没 ‧ 今回の不明点 ‧ 未確認のデータ実体を⽣成 ‧ 根拠‧参照元 ※ 対応計画は補助に下げる 完成した⼿順ではなく、アナリストが判断するための材料を渡す 21 

背景 エージェント 検索 出⼒ まとめ 現在のレポートは、知⾒と不明点を先に渡す B への対応レポート（全体） 過去事例からの知見 1. 依頼内容の整理 セルフサービス化の壁は編集権限。過去に、依頼者が編 集できずアナリストが代行した事例あり。早期に確認を。 2. 対応計画 3. 過去事例からの知見 調査から不明だった点 4. 調査から不明だった点 5. 参照 他部署が今どのツールで抽出しているかは記録から確定 できない。関係部署への確認が必要。 過去事例を答えとして移植せず、今回の判断材料として渡す 22 

知見探索の自動化と、残った限界 

背景 エージェント 検索 出⼒ まとめ ― 過去知⾒の探索を⾃動化した 成果: 過去事例の検索‧掘り起こしを⾃動化 ‧⾃分でキーワードを⼊れて探す⼿作業が ０になった ‧知⾒を解釈する認知コストが減った 設計の学び 検索 出⼒ 1 要約 → 時点‧観点へ分ける 1 計画 → 知⾒‧不明点‧根拠へ分ける RAG の価値は、⼀つの答えへ早くまとめることより、次の判断に必要な違いを残すこと まとめ 

背景 エージェント 検索 出⼒ まとめ ただし、今回⽀援できたのは、主に過去事例の探索 対応プロセスの限界 知識の限界 ‧ ⾃動化は主に過去事例探索 ‧ 記録にないデータは検索できない ‧ ⽬的確認、指標決定、SQL、検証、 ‧ 当時の定義が今も正しいとは限らない 成果物はアナリスト ‧ 組織‧⽬的が違えば適⽤できない 探索の属⼈性は下げられたが、分析そのものを⾃動化したわけではない 25 

背景 エージェント 検索 出⼒ まとめ 次は、経験知と構造知をつなぐ 経験知（今⽇の話） 構造知（次のテーマ） 過去にどう対応したか 今どのデータが存在し、 ヒアリング‧判断理由‧ どう定義されるか 制約‧失敗‧成果物 テーブル‧指標定義‧リネージ‧ 更新‧権限 過去の対応経験と現在のデータ構造をつなぎ、検索から実⾏へ進む 26 

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/ 

No content