顧客に提供して見えた AIエージェント設計 リアル 技術本部 CTO室 AI Solution Development プロダクト室 AI Enablement Group 瀬戸 博則 

瀬戸 博則 Sansan株式会社 技術本部 CTO室 AI Solution Development プロダクト室 AI Enablement Group 写真が入ります SIer企業にBI・データエンジニアとして新卒入社以降、大手IT会社・ 広告代理店でデータエンジニアリングやデータマネジメント案件を経 験。 2025年11月にSansanへ入社し、Sansan AIエージェント レクションや顧客向け 導入やオンボーディングに従事 開発ディ 

今日話すこと Sansan AIエージェントをどう設計して、顧客向けに本番提供するにあたり何に 苦労しているかについて話します。 - 1. Sansan AIエージェントと - 2. 設計方針 - 3. 苦労していること 

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

そ “できる営業 ” 動き、 誰でも再現できてますか？ 

Sansan AIエージェントと 営業活動で "成果を誰でも再現できる仕組み "を提供するプロダクトです。 データを探す に 時間がかかる データがどこにあるか 分からない 分析できる 一部 人だけ 次 最適なアクションが 分からない 情報を探す に時間がかかる、情報 活用方法が分からない 

Scene ：突然 商社 東洋オフィス株式会社 営業担当 西山 修一 引き継ぎアポイントメント 前任者が 急に退職した 引き継ぎ資料が 残っていない 引き継ぎ作業が 追いつかない 3日後に初訪問 予定がある 

No content

No content

No content

Sansan AIエージェントと Sansanと顧客 データ、個社 コンテキストをもとに営業行動を支援。 01 SFA 基幹 システム クラウド ストレージ 名刺情報 MA 請求書 契約書 社内に存在する あらゆる ビジネスデータを 統合 データ統合基盤 02 チャットUIで 簡単に利活用できる 

既にある仕組み 作り直さない。 自分たちにしか出せない価値に集中する。 

設計方針 - コンテキストと統合データをどう蓄積 /管理/活用するか 1 インタラクション層 FDE 業務アプリケーション 顧客 FA Google alesforce / Hub pot 等 orkspace / クライアント 365 / lack / ansan I claude / chatgpt / copilot /gemini eb/ obile eams コネクタ（アドオン開発） コネクタ（アドオン開発） 1〜 4を横断的に支援す bservability る機能 C / A I （外部 → Agent 呼び出し） 呼び出し / 応答 2 エージェント層 オーケストレータ ub-Agent群 ワークフロー・差配管理 ・個社プリセット定義/ タスク指向 ub-Agent群 準備 提案 議事録 //フォロー タスク指向 ub-Agent群 準備//準備 提案///提案 議事録 フォロー タスク指向 ub-Agent群 / フォロー ユーザ指示 から が コンテキスト読み書き ・行動 型定義 3 コンテキスト層 ※ユースケース検証中 出力まで 過程や分岐 運用 語彙と関係 オントロジー・集合知 ナレッジ鮮度・品質管理 / ゴールデンクエリ /個社D A（行動 型・ I・運用ルール） を評価 eflector・Curator 形式知化 暗黙知を自動抽出・整理／履歴管理 Generator 会話セッション 会話生データ・業務ファイル・用語蓄積 定義・いつ時点 出来事か（状態） ・ノード：顧客/部門/人物/案件/商談/提案/意思決定/競合/論点 ・データ接続設計 ・関係：担当/影響者/反対者/引継/競合/承認/論点紐付/対象 / C 接続支援等 ・状態： ステージ/確信度/鮮度/有効期限 C / A I （Agent → 外部 呼び出し） 必要な分だけ動的に参照する 4 データベース層 統合データベース 業務ファイル Googleドライブ / Box / otion等 基幹システム 顧客データ / マスタデータ ・集合知 品質維持 ansanデータ 名刺 / 企業 / コンタクト 

設計方針 - L1 顧客が普段使う SFA・Slack等からエージェントを呼べるようにする (API化) 今後 LLMクライアント 進化を鑑み、専用 UI 最低限にしている 

設計方針 - L2 個社別 業務ユースケースに合わせたタスク志向型 り実業務に近い支援が可能に。 Agentを提供することでよ 

設計方針 - L3 暗黙知を「個社 DNA」として資産化し、属人化を防ぎながら組織全体 意思決定スピード と精度を高める仕組み 個社戦略 ハイパフォーマー 行動 型 ログ・プロセス - 営業戦略 : 注力領域 / 新規 or 既存顧客 優先順位 / 企業規模 / 業態 / 組織構 KGI・KPI : 売上単価 , 受注率 , 訪問数 , アポ率 etc… 商品特性 : 標準 or オプション / 効能 / 価格 etc… - - 商談 : 初回商談で必ず確認する項目 / 提案前に確認すべき社内事情 / 値引き基準 提案 : 提案資料 構成 / 成功事例 etc.. 顧客対応 : 約束してよいこと、持ち帰るべきこと / エスカレーション条件 etc… - エージェントと 会話履歴 : 担当企業・商品 / ミッション・役割 etc… 業務プロセス・パターン : リード ~ 契約 / 問い合わせ対応 / 商品開発 etc… 

設計方針 - L3 - 現状 yamlやmarkdownで階層管理 - エージェント層で sub agent 内 ワークフローに組み込むなど - ユースケース増加や複雑化に伴いコンテキストサイズが増加 ... - 時間経過と共にコンテキストと現実 変化と 整合性が取れない - ハルシネーション確率増や入力トークン量増大によるコスト増など - どこまでどう必要か検証中 - 抽象化・関係構 化してみる？ → オントロジー？ - ベクトル化してみる？ → RAG？ - 鮮度管理する？ → 最新情報だけ？キーワードヒット率 ランキング？ 

設計方針 - L4 “独自名寄せ技術 ”で統合したデータベースによって高品質な出力を下支え 接点データ 名寄せエンジンによって 一意 コードを振ることで、 企業単位に集約 • 会社名 • 営業社員 ID • 営業社員名 • 日付 • アポイントメモ チャット UI 市場データ • 会社名 • IR情報 BigQuery 売上データ • 会社 ID • 会社名 • 年月 • 売上 部署データ • 営業社員名 • 部署名 名寄せエンジン (DataHub) 

設計方針 - FDE これまで話してきたすべて 層に対して、個社 課題解決やアウトカムを生み出 すために必要なあらゆることを実施する。泥臭い地道なことも実施する。 課題設定 現状把握 設計・実装 運用・定着化 ・目標/ゴール設定 ・プロセス可視化 ・DWH/マート ・利用促進 ・アウトカム ・要求整理 ・ヒアリング ・コンテキスト ・運用装着 ・利用状況 ・スコープ定義 ・要件定義 ・エージェント ・運用保守 ・継続判断 ・実行計画 ・ユースケース ・TOBE業務設計 ・合意形成/調整 課題やユースケース毎・成果が出るまでできるだけ高 に繰り返す 評価 

設計方針 - 環境構成 Google Cloud egion : asia-northeast1（ okyo） anagement lane IA / ecurity bservability / CI-CD Identity latform orkload Identity Federation Edge / ecurity Cloud un ervices Cloud un ervices ecret anager Cloud Data ayer 1コンテナ = 1テナント Cloud un : Front + BFF Cloud un : Front + BFF Artifact egistry bservability Cloud un : Agent Apps Cloud un : Agent Apps Cloud un : C ervers Cloud un : C ervers ansanデータ Ingress Access Cloud Armor AG- I（ Front + BFF Front + BFF ser（営業） E） Agent Apps（AD ） Agent Apps（AD ） C C ervers ervers Cloud oad Balancing ain ession / Inspect prompt/response ervices ertex AI emory Bank ession ervice ertex AI（Gemini） odel Armor ain Inspect I/ Internal ervices angfuse GitHub Big uery 顧客提供データ 

顧客提供で 苦労点 

苦労① 個社ごと 非機能要件対応 対外提供にあたって 契約条件へ 影響を踏まえ、顧客ごと 非機能要件へ 対応が必要。 例 : データ保持リージョン 例 : Web Search grounding結果に個人情報が混入する可能性 解決策 - 実行基盤・データ asia-northeast1 に保持する 顧客 データレジデンシー要件に合 わせて配置・保持を制御する。 例 : プロンプト攻撃・不正アクセスへ 多層防御 (prompt injectionなど) 解決策 - “Grounding with Google Search Enterprise” を使用することで、検索 データ 保存期間を 3日以内 検索チップを表示しない。 解決策 - 外部テキストから 命令注入に備 え、入力 サニタイズ・権限分離（読 取専用／SELECT専用） ツール実行 ガードレールで多層 に防御する。 Model Armorによる悪意 ある URL やジェイルブレイク検知 加えて許可I ・アクセス権限・監査ログを顧客要件ごとにチューニング。以上における書面化と合意工数がかかる。 

苦労② 共通と個別 開発境界 共通に寄せすぎると個社に刺さらない。個別に寄せすぎると事業がスケールし ない。 顧客 声 フィードバック FDE 顧客(Client) PdM/エンジニア 個別機能に反映 共通機能に反映 営業戦略・ KPI・業務プロセス 業界/商習慣etc… 個別機能① 拡販機会 提案 個別機能② 休眠顧客 検知 課題・要件① 単価を上げたい 深耕 課題・要件② 注力商品や案件状況を把握したい 課題・要件③ 部署・ユーザー間で参照情報を分 けたい 共通機能① 入力ワードによるワークフロー分岐 抽象化 個別機能③ 週報作成 共通機能② 定量指標 定点観測 / 可視化 個別機能④ 売上や取引実績 分析 共通機能③ コンタクト 要約 個別機能⑤ アクセス権限制御 

苦労③ 出力 再現性 特に定量指標 (売上や取引実績 ) 再現性 、日々 営業活動において間違え られない。 ※共通機能化を前提にどこまでど 組み合わせが必要か検証中 定型分析（Deterministic） セマンティックレイヤ 指標定義を一元化 C or ool化 問い 「私 「 4 取引実績 ？」 現在 売上実績と目標 GA ？」 集計軸： 顧客 / 期間 / 商品 取引実績 推移（毎回同じ） 型（スキル） 期間： 四半期 / D / 前年同期 「◯◯会社と 商品における過 去1年 取引実績 ？」 誰が聞いても・何度でも ロジックを ool側に保持 + セマンティックレイヤ 定義を参照 で分岐 アドホック分析（Flexible） 単位： 百万円 / 件 / 社 がクエリを動的生成 同じ定義 → 同じ数字 検証済み 正解クエリ(ゴールデンクエリ) + セマンティックレイヤ 定義を参照 柔軟に対応 （要検証） 

今後 共通化と品質担保を仕組み化して個社対応 手作業を減らす。 ゆくゆく 支援ツールにとどまらず、アクションそ も 込みたい。 代替まで踏み 

SansanAIエージェント ま だまだ道半 。 一緒に進める仲間を探して います。 

No content