カンム「Synapse」— Text-to-SQL への業務コンテキスト注入と、その育て方（記事の言う「セマンティックレイヤー」）¶
作成日: 2026-07-23 出典 / きっかけ: カンム テックブログ（2026-06-18、佐野氏 @hiroakis_）「社内 AI エージェント Synapse とセマンティックレイヤーの育て方」登壇（Findy 主催、タイミー・メルカリと同席）＋補足記事 関連: カンム_synapse_adkコンパクションでコスト削減_整理（同シリーズ最新回・運用コストの軸）意味層_enforced_cube_dbt_looker_整理（enforced 側の対極。カンムは advisory）タイミー_dre_looker_adk_社内aiエージェント_整理 メルカリ_socrates_データ基盤とマルチエージェント_整理（同 Findy 登壇の他2社。実は別の位置にいる）sansan_corporate_databridge_情シス内製データ連携基盤_整理 palantir_foundry_ontology_ビジネスのai化基盤_整理 dspy_現場プロンプト改善ループ_metricと所有権境界_整理
⚠️ 用語の注意（このノートの一番大事な訂正）¶
記事は「セマンティックレイヤー」と呼ぶが、カンムがやっているのは enforced（強制される）意味層ではなく、Text-to-SQL への advisory（無視できる）な業務コンテキスト注入。両者は別物:
| 本物のセマンティックレイヤー（Cube / dbt SL / LookML / Palantir 意味層） | カンムの「セマンティックレイヤー」 | |
|---|---|---|
| 強制力 | クエリが必ずそこを通る。モデルは無視できない | 定義を参照してくれることを期待する。モデルは無視できる |
| メトリクスの定義 | コンパイルされ一意（売上 = この JOIN）に固定 | 文書で説明するだけ（守るかは LLM 次第） |
| LLM の出力 | 定義済み measure/dimension を選ぶ | 生 SQL を BigQuery に投げる（Text-to-SQL） |
決定的な証拠: カンム自身が「LLM が定義を十分に参照・遵守しない場合がある」と書いている（§3-2）＝無視できる時点で契約ではない。かつ評価が Text-to-SQL の Execution Accuracy＝ LLM が生 SQL を書いている＝ DWH が直接露出していて、意味層は間に挟まっていない。実体は「Text-to-SQL に業務ドメイン知識を良く食わせている」だけ。以下このノートでは記事の語をそのまま「セマンティックレイヤー」と書くが、中身は業務コンテキスト注入と読むこと。
0. 要点（3行）¶
- Synapse はカンム（バンドルカード）の社内 AI エージェント。3名チームでデータ分析＋業務支援を提供し、精度の土台として「用語・データ構造・業務ルールの知識層」（記事の言うセマンティックレイヤー＝実体は業務コンテキスト）を育てている。置き場所はシステムプロンプト→MCP サーバへ進化
- 構成は意図的にミニマム: BigQuery ＋ Gemini、ベクトル DB なし（導入予定もなし）。「最低限のコンポーネントで動くものを作り、簡単な内容から始める」を明言。マルチ LLM（軽い質問は Flash）は精度低下で失敗し 3.1 Pro に一本化した失敗談まで公開
- 評価は Text-to-SQL に Execution Accuracy（期待の結果が返るか）を採用（Exact Match 非採用）。コンテキストは書いて終わりでなく「実際の質問と失敗例を通じて更新し続ける」— この育て方（運用ループ）こそが本ノートの持ち帰り。看板の「セマンティックレイヤー」は名前負けしている
1. Synapse の位置づけ（シリーズ3部作の到達点）¶
| 回 | 記事 | 内容 |
|---|---|---|
| 1 | 2025-12-24 | データ分析を加速する AI エージェント Synapse の開発と運用 |
| 2 | 2026-03-30 | Synapse を MCP サーバ化して Entra ID で認証 |
| 3 | 2026-06-18（本記事） | セマンティックレイヤーの育て方（Findy イベント登壇＋補足） |
- チームは3名、全員バンドルカードのサーバサイド・インフラ開発経験者 — 業務知識を持つ人が作ったことが初期の立ち上がり速度の源泉と自己分析。新規プロダクト展開時は「アプリ開発知見＋業務知識を持つメンバーの巻き込みが必須」とも
- 同席登壇: タイミー・メルカリ（セマンティックレイヤー×AI エージェントは各社同時多発のテーマ）
2. セマンティックレイヤーの実装 — 最小構成の哲学¶
- 定義: 「用語・データ構造・業務ルールの知識層」。AI エージェントが社内の業務文脈で正確に応答するための基盤
- 置き場所の進化: 初期はシステムプロンプトに直書き → 現在は MCP サーバに移設（エージェントから参照される「定義の置き場」として独立）
- スタック: BigQuery ＋ Gemini（2.5 Flash / 3.1 Pro）。ベクトル DB は不採用 — 理由は複雑性とインフラ運用負荷の増加。RAG 前提を疑い、定義の質と参照性で勝負する構え
- 「最低限のコンポーネントのみで動くものを作り、簡単な内容を与えるところからスタートするとよい」（本文より）
3. 学び — 失敗談と評価設計が具体的¶
3-1. マルチ LLM の失敗 → 一本化¶
- 「簡単な質問は応答の速い Flash に振れば UX が良いはず」という目論見で 2.5 Flash を併用 → 精度低下で断念、Gemini 3.1 Pro に一本化
- 教訓: ルーティングの複雑さはタダではない。モデル×ビジネス文脈の組合せで検証結果が変わるため、「軽い質問」の判定自体が難しい
3-2. セマンティックレイヤーの不確実性¶
- 定義を書いても LLM がそれを十分に参照・遵守しない場合がある。「書けば効く」ではなく、効いているかを評価で確かめる対象
3-3. Text-to-SQL の評価手法（比較表が有用）¶
| 手法 | 中身 | 採否 |
|---|---|---|
| Execution Accuracy | 期待された結果が返るか | 採用 |
| Exact Match | 生成 SQL が期待 SQL と文字列一致するか | 非採用（書き方の多様性を殺す） |
| Component Match Accuracy | SELECT/WHERE/JOIN 等の構成要素一致度 | — |
| Valid Efficiency Score | 実行効率も含めた評価 | — |
| Query Variance Testing | 異なる訊き方への頑健性 | — |
- 結果ベース評価の採用は、自分の testing ルール「実装詳細でなく振る舞い/契約を固定する」の Text-to-SQL 版
4. 考察（ここは自分の解釈）¶
- 一言でいうと「業務ドメイン知識を良く食わせた Text-to-SQL」。Palantir Ontology や Cube のような enforced な意味層とは別軸で、「LLM にどれだけ上手く文脈を渡すか」の実践。意味の強制は無いので、意味層の代替ではなく、意味層が無い環境で精度を上げる現実的な工夫と読むのが正確
- 「定義の置き場」がプロンプト→MCP へ動いたのは示唆的。判断基準・語彙をプロンプトに埋めず外部リソース化する流れは、ai-engineering-digest の harness.yaml（基準の外化）と同じ設計思想。ただしこれは「ハーネス（文脈の管理）」の改善であって、意味層（クエリの強制）にはならない
- 育て方＝運用ループが本体（ここが唯一の持ち帰り）: 実質問と失敗例からの継続更新は、DSPy 的な「メトリクス（Execution Accuracy）を持ってコンテキストを改善し続ける」ループ。定義を書く行為より、失敗を定義更新に還流する経路の設計が価値。Text-to-SQL の実務知見としては良質
- 段階論としては横並びにできない（当初この点を盛って書いていた・訂正）: Sansan（人・組織データの読み取り契約）と Palantir（操作まで契約）は両方 enforced contract で、スコープ違いの同一軸。一方カンムは enforced ではなく advisory context なので、「契約ラダーの中段」ではなく別軸。本物の「意味の契約」の段はカンムでなく Cube / dbt Semantic Layer / LookML / Palantir 意味層（メトリクス定義がコンパイルされ強制される）が入る。※このノートを最初に書いたとき、この3社を綺麗な段階論に並べたのは誤り
- 留保: 精度・利用数などの定量値は記事に無し（登壇補足記事のため）。スライド・シリーズ過去2本に当たると実装詳細が補える
5. まとめ — 転用できる型¶
| 状況 | 型 |
|---|---|
| 社内データ分析エージェントを始める | 最小構成（DWH＋LLM のみ・ベクトル DB なし）＋簡単な質問から |
| 用語・業務ルールをどこに置くか | プロンプト直書き→独立した定義置き場（MCP サーバ等）へ段階移行 |
| Text-to-SQL の品質をどう測るか | Execution Accuracy（結果一致）を主指標に。SQL 文字列一致は使わない |
| 精度が伸びない | 定義の追記でなく「実質問の失敗例→定義更新」のループを仕組み化 |
| マルチ LLM でコスト最適化したい | 精度検証なしのルーティングはしない（カンムは失敗して一本化） |
参考リンク¶
- 出典記事: https://tech.kanmu.co.jp/entry/2026/06/18/152618
- 登壇スライド: https://speakerdeck.com/hiroakis/she-nei-ai-eziento-synapse-to-semanteitukureiyanoyu-tefang
- シリーズ第1回（2025-12-24）・第2回 MCP サーバ化＋Entra ID 認証（2026-03-30）: カンム テックブログ内
- イベント: Findy「セマンティックレイヤーをどう育て、信頼できるAI Agentを開発するか」（タイミー・メルカリ登壇）
作成: 2026-07-23 ／ 最終更新: 2026-08-08