# AIエージェントには新しいデータスタックが必要な理由 - 番組: [The Data Exchange with Ben Lorica](https://ai-curator.jp/podcasts/shows/cmv3z5c0q000m5o10xxr4slsk)（Ben Lorica） - 元のタイトル: Why AI Agents Need a New Data Stack - 配信日: 2026年11月12日 - 長さ: 53分 - 要約作成日: 2026年11月12日 - トピック: [#AIエージェント](https://ai-curator.jp/topics/AI%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#データフェデレーション](https://ai-curator.jp/topics/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%82%A7%E3%83%87%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3) [#セマンティックレイヤー](https://ai-curator.jp/topics/%E3%82%BB%E3%83%9E%E3%83%B3%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF%E3%83%AC%E3%82%A4%E3%83%A4%E3%83%BC) [#text-to-SQL](https://ai-curator.jp/topics/text-to-SQL) [#MCP](https://ai-curator.jp/topics/MCP) [#ガバナンス](https://ai-curator.jp/topics/%E3%82%AC%E3%83%90%E3%83%8A%E3%83%B3%E3%82%B9) - URL: https://ai-curator.jp/podcasts/cmwdkmy4m00005b12qgvk5bop ## 要約 Snow LeopardのCEO、Deepti Srivastava氏がBen Loricaと対談し、AIエージェントにはライブの運用データが必要であり、従来のデータ統合では不十分だと論じた。生成AIによるtext-to-SQLとライブ・フェデレーション、セマンティックレイヤーの自動構築、フィードバックAPIによる精度向上、ガバナンスの設計が主な論点である。エージェント中心の世界ではデータ基盤が頻繁に変わるため、ミドルウェア層が重要になるという見方も示された。 ## ポイント - Snow Leopardはエージェントとデータベースの間に入り、質問から保存先を判断してSQLを生成・結合する。対象はSQLデータベースやSalesforceなど構造化された運用データで、非構造化データは扱わない。 - 従来のフェデレーションは最小公約数的なSQLや事前のロジック固定のせいで難しく、ウェアハウスへの集約も遅延が残る。人間なら補えた遅延が自律エージェントでは致命的になると述べた。 - 運用データのクエリは主にポイント検索や小規模な結合であり、並列化・キャッシュ・分割などの既知の最適化で対処できるという主張である。 - セマンティックレイヤーは、DB種別ごとのスキーマ読み取りと、LLMや敵対的LLMによるデータのプロービングで自動構築する。約4か月前のベンチマークで90〜95%超の精度を報告し、フィードバックAPIでさらに改善できる。 - ガバナンスは役割に加え、どのエージェントが誰の代理で何の目的かを見て制御する。MCPだけではガバナンスや精度が解決せず、トークン消費も多いとし、自社はMCP直接利用より約10倍高速でトークンは平均半分と述べた。 - 3年後のデータスタックは、ガバナンス、ライブ・フェデレーション、自動的な業務文脈理解の3本柱を持つミドルウェアが要になるという見通しを示した。 ## 章立て - [00:00] **Snow Leopardの位置づけと対象データ** — エージェントとDBの間で動く仕組みと、運用データ・SQL系を主対象とする方針を説明している。 - [04:04] **フェデレーションが難しかった理由** — 最小公約数SQLや事前設計の限界、ウェアハウスの遅延が、自律エージェントで問題になる点を論じている。 - [09:14] **生成AIで実現するライブ・フェデレーション** — text-to-SQLと結合、最適化手法、MCPの限界について語られている。 - [14:26] **セマンティックレイヤー自動構築と精度** — ベンチマーク結果、DB別ハーネス、データのプロービング、フィードバックAPIを解説している。 - [25:03] **信頼性・運用面とストリーミング** — 精度5%の懸念、単一障害点、BYOC、性能、ストリーミング方式の限界を議論している。 - [34:20] **ガバナンスと読み書き権限** — MCPの危うさ、エージェントの代理権限の制御、現在は読み取り専用である点を述べている。 - [39:40] **データの乱雑さと説明可能性** — マスターデータ管理の課題、IT部門以外のフィードバック、SQL説明や監査機能を紹介している。 - [48:08] **エージェント first 時代のデータスタック** — 3本柱とミドルウェアの重要性、頻繁に変わるインフラへの対応を展望している。 ## 解説記事 The Data Exchange の今回のゲストは、Snow Leopard の創業者兼CEOであるDeepti Srivastava氏だ。聞き手のBen Loricaとともに、AIエージェントが企業の業務を担うために必要なデータ基盤を議論した。以下は、番組での発言に基づく整理である。 #### エージェントにはライブの運用データが要る Srivastava氏の出発点は「エージェントには、適切なデータが適切なタイミングで必要」という考えだ。Snow Leopardはエージェントとデータベースの間に立ち、APIで受けた質問に対して、どのDBに答えがあるかを判断し、クエリを書き、結果を結合して返す。 対象はSQL ServerやPostgres、MySQL、SnowflakeなどのSQLデータベースと、SalesforceやHubSpotのような構造化APIといった、事業を回す運用データである。RAGが話題になった非構造化データは扱わないと明言している。 背景にある例が、ECの注文確認だ。チャットボットが注文情報を持たないと人間に引き継ぐが、マーケティング予算の配分や金融の小口取引の可否を判断する自律エージェントでは、そうした介入ができない。ウェアハウスにはどうしても遅延が残り、人間が補えた隙間が自律エージェントでは問題になるという。 #### なぜ今、フェデレーションが機能するのか フェデレーションとは、複数のデータソースから必要なデータを取りに行って組み合わせることだ。従来は、どこにアクセスすべきか事前に分からないうえ、共通SQLに揃えると各DBの機能を生かせなかった。その結果、データをウェアハウスに集約する流れが主流になった。 Srivastava氏は、生成AIによって状況が変わったと述べる。LLMはtext-to-SQLを基本レベルでこなせ、パターンマッチによる判断も得意なので、条件分岐を網羅的に書かなくてもよい。結合による性能懸念についても、運用データの問い合わせは主にポイント検索や小規模な結合であり、大きな結合には分割、キャッシュ、ビューなど既知の最適化が使えると説明した。 MCPについては、ガバナンスも精度も解決せず、トークンを多く消費するとして、過度な期待の時期を抜けつつあるという見方を示した。自社はMCP直接利用より約10倍速く、トークンは平均で半分だと述べている。これは本人の主張である。 #### セマンティックレイヤーの自動構築とフィードバック 中核となるのが、データの意味を理解するセマンティックレイヤーの自動構築だ。接続時に、DBの種類ごとに作ったハーネスでスキーマの構造差を吸収し、さらにLLMと敵対的なLLMがデータ自体を調べる。たとえば小数の列なら金額や割引、5桁の整数なら郵便番号かもしれない、といった推定だ。 同社は、公開データセットを使い100問を3回走らせたベンチマークで、90〜95%超の精度だったと述べる。それでも暗黙知は人の頭の中にあるため、フィードバックAPIで修正できる。入力は検証・判断の層を通り、まず当該セッションに適用され、その後システムに取り込まれる。部署ごとに定義が違う場合は、ロールに応じて別々に適用する設計だという。 精度5%の誤りが事業に響くのではという問いには、確率的なシステムが最初から100%の決定性を出すことはなく、確率的エンジンと決定的な結果を近づける試みだと答えた。 #### ガバナンスと信頼性 Srivastava氏は、MCPをDBにそのまま被せるのは、全データとスキーマに触れられる点で怖いと語る。Snow Leopardはデータソースの外に位置するため、どのエージェントが誰の代理で何をしようとしているのかに基づいてルーティングや制限ができるという。たとえば代理エージェントが、クレジットカード情報には触れてよいが銀行口座には触れさせない、といった制御だ。既存のDBアクセス制御に加え、公開するデータセットやテーブルを絞ることもできる。 現在は読み取り専用で、書き込みも技術的には権限の問題にすぎないが、AIへの信頼が追いついていないとの認識だ。権限は、サービスアカウントやOAuthで付与されたロールを使う。単一障害点への懸念には、金融サービス企業での利用実績、BYOC（自社クラウド内への展開）、数百ユーザーの同時接続への対応を挙げた。 説明可能性として、生成したSQL、対象のデータソース、理由が自然言語で返る。ER図やグラフでの可視化の要望もあり、検討中だという。 #### エージェント first のデータスタック 3年後の姿として、エージェント、データミドルウェア、データソースという構成を描く。柱は、ガバナンス（何に加え、誰が何のために）、ライブ・フェデレーション、人のフィードバックを含む自動的な業務文脈理解の3つだ。ウェアハウスを否定するのではなく、そこも取得先の一つとして扱う。 コーディングエージェントがスキーマやインフラを頻繁に作り替えるなら、人が手で整備する前提は崩れる。スキーマのドリフト検知やセマンティクスの更新を機械の速度で行うミドルウェアが重要になる、というのが同氏の見立てである。 #### まとめ 本回の主張は、エージェントの実用化の壁はモデルよりデータへのアクセスと文脈理解にあり、集約型ではなくライブのフェデレーションが解になるというものだ。精度や性能の数値は同社側の発表であり、実環境での検証は必要だろう。それでも、ガバナンスを「誰が・なぜ」まで含めて設計する点や、データ基盤が頻繁に変わる前提でミドルウェアを置く発想は、日本の企業でエージェント導入を考える際にも参考になる。 > この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: The Data Exchange with Ben Lorica「Why AI Agents Need a New Data Stack」