社内 AI エージェント Synapse と セマンティックレイヤーの育て方

Transcript

1. 1 株式会社カンム 佐野裕章 2026/06/16 社内 AI エージェント Synapse と セマンティックレイヤーの育て⽅ Data Career Talk #5 セマンティックレイヤーをどう育て、信頼できるAI Agentを開発するか 〜カンム＆タイミー＆メルカリの実践事例〜
2. 2 2 Engineer at Kanmu, Inc. 佐野 裕章 GitHub @hiroakis ⾃⼰紹介
3. 3 • Synapse と名付けられた社内 AI エージェントの紹介 • 主にセマンティックレイヤーに着⽬してそれをどのように導⼊しどのように運⽤しているか • ※ この発表でいうセマンティックレイヤーはAI エージェントが社内の業務⽂脈で正しく答えるた めの⽤語‧データ構造‧業務ルールの知識層を指す。セマンティックレイヤー⾃体は AI 時代の新 概念ではなく古くから存在している概念のため本発表内での意味を明らかにします。 本⽇の内容
4. 4 目次 INDEX 0 1 2 3 Kanmu Synapse Semantic Layer まとめ
5. 5 0. Kanmu カンム
6. 6 プロダクト 誰でもすぐに作って買い物できる Visaプリカアプリ 手元の資産形成に活用できる クレジットカード 生活者向け
7. 7 プロダクト 中小事業者向け 分割あと払いサービス AI審査でオンライン完結できる 新しい資金調達サービス 企業向け
8. 8 誰でもすぐ作れる 1分でVisaカードが発行可能 バンドルカード 1 すぐ確認できる 使ってすぐにPush通知で金額確認 2 後でも払える その場でチャージして翌月末にお支払い 3 🎊 2026年1月：累計1,400万DLを突破 ローンの機能も使える ローンもアプリ内で完結 4 New
9. 9 1. Synapse シナプス
10. 10 Synapse (シナプス) • 2025年頃、データ分析を⽀援する AI エージェント として⽣まれた ◦ もともと社員は SQL を⾃⼒で書いて洞察を得ていた ◦ それを AI 時代に合わせて進化させた結果⽣まれた ◦ ユーザ属性や決済データが格納されているBigQuery をデー タソースとした Text-to-SQL が主な機能 ◦ ⾃然⾔語で問い合わせて洞察を得る • 現在は業務全般の役に⽴つように⼿⾜を広げた ◦ BigQuery に加えて... ▪ Notion 連携 ▪ Google Spreadsheet 連携 ▪ ソースコード (GitHub)参照 ▪ Redash (既存の分析SQL資産) 連携 ▪ …etc • 主に3⼈の⼈間が開発運⽤を⾏っている • 社員の1/3くらいが⽇常利⽤している
11. 11 現在の Synapse 構成図 • ユーザは社内で承認されているクライアントから利⽤可能 ◦ ブラウザ, Claude Code, Claude Desktop, Codex… ◦ 社内インフラ (Microsoft Entra ID) と連携して認証認可が⾏われる • Synapse Chat ◦ ブラウザにチャット様の UI を提供するウェブアプリケーション ◦ Google ADK が LLM を呼び出し Gemini シリーズが使⽤される ◦ RDS に会話内容を保存 • Tools GW ◦ Synapse Chat (ブラウザ利⽤)および各種 AI ツール (Claude Code類) に Tools を提供する MCP サーバ ◦ Tools が BigQuery へのクエリや GitHub のソース参照などを⾏う ◦ ブラウザ以外のクライアントは Synapse Chat を経由せず Tools-GW に MCP クライアントとして接続 ▪ その場合の LLM は各種クライアント任せ (Claude Code なら Claude シリーズ) • Knowledge ◦ データ構造‧⽤語‧業務に関するドキュメントを返す MCP サーバ ◦ これ⾃体も MCP サーバとなっていてブラウザ側‧AIツール側から透過 的に参照できる ◦ これが現在のセマンティックレイヤーの配置場所
12. 12 デモ: 決済データからユーザを調査する (データは加⼯済) - Synapse Chat からの例 ↓処理過程を展開すると実⾏されたSQLや利⽤されたツール (セマンティックレイヤー含む)を参照できる
13. 13 デモ: 業務について質問 - Claude Desktop からの例
14. 14 デモ: セマンティックレイヤーを参照させずに同様の質問 - Codex からの例 ⼀般的な説明になる ユーザ (社員) が知りたいのはこれではない
15. 15 • 「残⾼」をカンムのバンドルカードの業務という⽂脈で理解している ◦ 「利⽤可能残⾼ (Available Balance)」と「帳簿残⾼ (Ledger Balance)」の存在を理解 ◦ データ構造を把握して SQL を構築して残⾼を調査してユーザの特定を⾏っている • 「オーソリ」をカンムのバンドルカードの業務という⽂脈で理解している ◦ ⼀般的なオーソリ    : 与信‧⽀払い能⼒を照会 ◦ バンドルカードのオーソリ: 決済そのもの‧Available Balance を引く • AI エージェントに⽤語‧データ構造‧業務に関するコンテキストが注⼊され、それを期待通 りの⽣成が⾏われている ◦ → セマンティックレイヤー • このセマンティックレイヤーをどう育てて運⽤してきたか Synapse はカンム⽂脈で回答できる
16. 16 2. Semantic Layer セマンティック‧レイヤー
17. 17 当初の構成とセマンティックレイヤーの位置 • Google ADKのシステムプロンプトに書くところから開始 • 当時の選択肢 ◦ ユーザ/システムプロンプト ◦ ファインチューニング ◦ RAG ◦ MCP • エージェントスキルのような概念はまだなかった • なぜシステムプロンプトを選んだか？
18. 18 • ここでいう不確実性とは ◦ LLM は社内の知識を解釈してくれるのか？ ◦ LLM は本当に社内の知識を⽂章にすることができるのか？ • 例えば先ほどのオーソリに関する質問の例 ◦ ⼀般的なオーソリの意味と、カンムのプロダクトのオーソリには違いがある ◦ こちらが注⼊した知識を優先してくれるのか？ ◦ ⼀般的な説明とカンムの説明が混ざってしまうことはないのか？ ◦ 途中でおかしな⽂章が⽣成されることはないのか？ 導⼊期: 不確実性の検証
19. 19 • 開発者側が管理する前提でかつ⾃然⾔語で記述可能 ◦ -> システムプロンプトとして検証するのが取り回しやすかった • ファインチューニングや RAG だとうまくいかなかったときに、やりかたが悪いの か？ミドルウェアの設定が悪いのか？ちゃんと検索できているのか？といった考慮す べき事項が増えてしまう 導⼊期: 不確実性の検証
20. 20 導⼊期: システムプロンプトに注⼊して検証 • Markdown と YAML に⽇本語をひたすら⼿書き ◦ Markdown と YAML である必要はない ◦ 視認性が得られて構造化しやすければ何でもよかった • それを読み込んでGoogle ADKのシステムプロンプトに与える • テストで精度をチェック ◦ Question-Answering ▪ 例えば「オーソリってなんですか？」の期待する回答をあらかじめ⽤意 ▪ Synapse に質問を投げて得られた回答と期待する回答をLLMで⽐較 ◦ SQL Generation ▪ Text-to-SQL の評価の⼿法はいくつかあるが、 EX (Execution Accuracy、 実⾏結果を⽐較) を採⽤ ▪ 例えば「ユーザAの残⾼は？」に対する正解のレコードを⽤意 ▪ 正解のレコードが出⼒されるかを⽐較 • 加えて、ユーザの利⽤をモニタリングしてセマンティックレイヤーを改善していった
21. 21 カンムの場合のセマンティックレイヤーの書き方 name: ドメインモデル名 description: ドメインモデルの説明 bigquery_dataset: BigQuery のデータセットID root_table: 調査の起点となるテーブル名 facts: - description: fact の説明 calculation: fact の調査の手法 - description: fact の説明 calculation: fact の調査の手法 dimensions: - description: dimension の説明 calculation: dimension の調査方法 - description: dimension の説明 calculation: dimension の調査方法 • ドメインモデルごとに定義 ◦ ふわっとしているが、カンムだと「決済」「ユーザ」「カード」程度の粒度としている • ディメンジョナル‧モデリングの概念を借⽤したフォーマットで書いている ◦ 例えば「決済」ドメインにおいては「決済が発⽣した」というのは fact で、「決済ID」「決済したユーザ」な どは dimension となる • root_table は完全にオリジナルの要素で、これはカンムでは分析⽤のビューを作っていないため、調査の起点となる テーブルを指⽰してそっから JOIN で辿らせるようにしている name: BASE I 決済 description: BASE I 決済に関するデータを表す bigquery_dataset: {{ dataset_id }} root_table: {{ table_name }} facts: - description: BASE Iメッセージを受信した calculation: | tbl_a テーブルの1行が1 BASE Iメッセージである col_a カラムでメッセージ種別を判別: - 100: オーソリ - 400: リバーサル - … - description: カードが漏洩カードとして登録された... calculation: | tbl_b テーブルの1行が、漏洩カードの登録1件に対応する... dimensions: - description: トランザクションID calculation: tbl_a テーブルのidカラム... - description: カードID calculation: | tbl_c テーブルの card_id カラム …
22. 22 サービス辞書 title: "用語辞書: 決済、VISA" category: 用語辞書 tags: - 辞書 - 決済 - BASE I - … description: 決済およびVISAに関する用語辞書 last_updated: "2026-03-10" content: | ## オーソリ オーソリは...(略)...バンドルカードではオーソリ受信時に実際に残高 (Available Balance) の減算を実行している。 同義語: Authorization ## Available Balance Available Balanceとは... 同義語: AB ## Ledger Balance Ledger Balanceとは... 同義語: LB • セマンティックレイヤーの⼀部として辞書を管理している • ⽤語の説明や業務の説明を YAML + Markdown の独⾃フォーマットで記述
23. 23 • 少なくとも主要ユースケースでは、必要な知識を与えることで期待に近い 解釈‧回答が得られることが確認できた • 蛇⾜だが、システムプロンプトに⼊れたから良かった、という意味ではな い。システムプロンプトに⼊れたのは検証の取り回しがしやすかったか ら、というのは先に述べた通り。セマンティックレイヤーをコンテキスト に注⼊できれば指⽰通りの解釈と挙動をしてくれることがわかった、とい うことである。 検証の結果...
24. 24 拡張期: MCP サーバへの分離 • 任意の AI ツールからも使えるようMCP 経由で知識 を注⼊するようにした ◦ 各種ツールが同じ知識を参照できるように ◦ 知識の更新を引き続きサーバ側に集約できるように ◦ ログを⾒て参照された知識を追跡しやすいように ▪ ただしシステムプロンプトはまだ活⽤。Google ADK の システムプロンプトにて「semlayer を必ず参照せよ」 と指⽰ ▪ AI ツール側はスキルに同様の指⽰を記述 • スキルは GitHub にホストして共有 • -> この形でも同じようにワークすることがわかった
25. 25 運⽤改善期: セマンティックレイヤー⽣成の⾃動化 • プロダクトは育つ ◦ 機能も増えたり減ったりする ◦ DB 構造は変わる • ⼿書きで追従するのは厳しすぎる • -> GitHub Actions でリポジトリを巡回するエー ジェントを泳がせて、セマンティックレイヤーに PR を出すようにした • レビューとマージは⼈間達がやっている
26. 26 • 導⼊期: まずは不確実性の検証のために取り回しやすいやりかたを選択 ◦ システムプロンプトに⼿書き ◦ コンテキストに注⼊できれば期待通りに挙動することがわかった • 拡張期: 任意のAIツールに対応 ◦ セマンティックレイヤーをMCP サーバ化して MCP クライアントを搭載した AI ツールであればどこからでもその効果が得られるようにした • 運⽤改善期: ⾃動化 ◦ ⼿書きの限界に直⾯ ◦ GitHub Actions でセマンティックレイヤー更新を⾃動化 セマンティックレイヤーをどう育ててきたか
27. 27 3. まとめ
28. 28 • まずは期待通りの動きをするか⼩さな検証から始める ◦ 使っている LLM や注⼊する内容によってはワークしない可能性ある • ワークしたらどうにかしてコンテキストに注⼊するための仕組みを作る ◦ 今だとスキルに記述するのが選択肢の1つになると思うが、その場合は利⽤者に スキルを配り、更新時にも再配布する仕組みを作る必要がある ◦ カンムはMCPサーバに寄せて、スキルとシステムプロンプトでそれを必ず⾒る ように指⽰する⽅式になっている • セマンティックレイヤー⾃動更新の仕組みは遅かれ早かれ必ず必要になる ◦ ⼿で追従するのは限界がある まとめ＋これからセマンティックレイヤーを作る⼈に向けての考慮事項の提案
29. 29 • 評価の仕組みを強化 ◦ セマンティックレイヤーの更新や肥⼤化、Synapse のシステム変更に よって回答の精度が落ちたり、何もしていなくてもある⽇突然おかしな 回答が出始める可能性はある ◦ テストで精度を...と話をしたが例えば70/100の正解だったら OK なの か？60/100の正解だったら NG なのか？といった合格点の設計が難し い 今後の課題
30. 30 Thank you! ありがとうございました