データとAIで明らかになる、私たちの課題〜Snowflake MCP,Salesforce MCPに触れて〜

Last updated at 2025-11-01Posted at 2025-10-31

2025/10/30に開催された kaonavi Tech Talk #21 にて登壇した際の資料になります

🧑‍💻 はじめに

こんにちは。株式会社カオナビの本江雄人（ほんごうゆうと）です。普段はデータチームの立ち上げやデータ基盤の運用を担当しています。

私たちは、プロダクトが提供する価値をデータで可視化するため、データ基盤の導入やモニタリングを進めてきました。さらに、様々な部署でのデータ活用を促進する活動の一環として、Snowflake MCPやSalesforce MCPの利用を申請し、利用を促進してみました。

MCPの導入により、ディレクターなどがSQLを書かずに自然言語で顧客の利用状況を確認できるようになり、データ活用の裾野を広げる一歩となりました。

しかし、これらのMCPを使ってみて、私たちは データとAIに関する新たな「課題」 に直面しました。本記事では、その2つの課題と、そこから得られた学びについて共有します。

1. 【第1部】 Snowflake MCP: データ分析の「質」の課題

導入成果と新たな課題

Snowflake MCPの導入により、データ基盤の利用者数は増加し、データアクセスの民主化が進みました。非エンジニアにも活用が広がり、データへの関心も向上しました。

一方で、「めっちゃ雑にAIに問い合わせしても、なかなか欲しい結果は得られず」、分析結果の質が悪いという新たな課題が浮上しました。 AIがアクセスしやすくなったことで、データ基盤側の構造的な問題が露呈したのです。

原因1: 未定義のデータ

第一の原因は、データの意味が一意に定まっておらず、AIの解釈が揺らいでしまうことでした。

Database, Table, Column に COMMENT 等の定義（メタデータ）がない。
そのため、AIがそもそも必要な値を見つけられない。
例: 数値を格納するカラムに「単位」の記載がなく、AIが結果出力で大きく単位を間違える。

対策:
この問題に対し、私たちはLLMを使って不足していた COMMENT を埋めてもらいました。

/* LLMによってCOMMENTを補完した例 */
STATUS_CODE NUMBER(38,0) COMMENT 'HTTPステータスコード by LLM',
RESPONSE_TIME FLOAT COMMENT 'HTTP応答時間(秒) by LLM',
HOST VARCHAR(16777216) COMMENT 'ホスト名 by LLM',

これにより、AIの認識ミス（集計ミス）も減少しました。

原因2: 複雑なデータ構造

第二の原因は、データ構造の複雑さです。
モデリング（martの準備や中間集計等）をしていないRAWデータ、例えばRedmineからそのまま同期したような正規化されたテーブル群は、AIが正しく集計を実施するのが困難でした。

対策:
現在、ディメンショナルモデリングの適応を含むデータ基盤の再構築を実施中です。

ディメンショナルモデリングは、データを「事実(ファクト)」と「次元(ディメンション)」に分けて組織化し、分析を容易にすることを目指す手法です。

この構造は、分析者も（ついでにAIも）理解しやすいはずだと考えています。

❄️ Snowflake MCPのまとめ

人間にやさしい（=メタデータが整備され、モデリングされている）データは、AIがミス・失敗しにくくなる

2. 【第2部】 Salesforce MCP: 作業のツラい「データ構造」の課題

背景と課題

次に、Salesforceのデータです。このデータもSnowflakeに同期し、プロダクト企画などに活用しています。データの不具合調査などを補佐してもらう目的で、Salesforce MCPの利用申請も実施しました。

しかし、ここでもAIが集計に失敗するオブジェクト（仮に「注文書」とします）が存在しました。

原因: 「横持ち」のデータ構造

そのオブジェクトは、以下のような「横持ち」のデータ構造になっていました。

品名1	金額1	品名2	金額2	...
商品A	200円	商品B	300円	...
商品C	500円	商品D	300円	...
商品B	270円	商品C	0円	...

この構造は、AIにとって（そして人間にとっても）集計が非常に困難です。

問題点1: 動的なクエリが必要
「全明細のコードと金額を取得」したい場合、SQL（SOQL）では以下のように、存在する全てのカラム（例では12個）をハードコーディングで書く必要があります。

/* 横持ちデータの場合 */
SELECT
  ItemCode1__c, ItemPrice1__c,
  ItemCode2__c, ItemPrice2__c,
  ItemCode3__c, ItemPrice3__c,
  ... (12個全部書く必要がある)

もしこれが「縦持ち」（注文と注文明細が別オブジェクト）であれば、シンプルに書けます。

/* 縦持ちデータの場合 */
SELECT ItemCode, Price FROM OrderLineItems

問題点2: 集計が複雑
「特定の商品コードが含まれる注文を全部探す」場合、WHERE句が地獄のようになります。

/* 横持ちデータの場合 */
WHERE ItemCode1_c = 'ITEM-001'
   OR ItemCode2_c = 'ITEM-001'
   OR ItemCode3__c = 'ITEM-001'
   ... (12回繰り返し)

これは、SpreadSheetやExcelで集計するにもツラい構造です。

考察

Salesforceには「主従関係 (Master-Detail Relationship)」といった仕組みがあり、これを使えば「注文（親）」と「注文明細（子）」のような、集計しやすい「縦持ち」のデータ構造を実現できます。 AIに相談しても、DBの正規化等を勧められるでしょう。

実は、このオブジェクトに関しては、Salesforceで実際に集計作業をする方から**「ツラい」という噂をかねてから聞いていました**。 AIにこの集計作業をさせてみたのは、その背景があったからです。

☁️ Salesforce MCPのまとめ

AIが作業を失敗する場所 ≒ 人間にとって非効率な場所

3. 【まとめ】プロセスの改善点の炙り出しに、AIをどんどん触ってみよう

今回、SnowflakeとSalesforceのMCPに触れてみて、2つのことが明らかになりました。

Snowflakeの事例:
人間にやさしいデータは、AIがミス・失敗しにくくなる。
Salesforceの事例:
AIが作業を失敗する場所は、結局のところ人間にとっても非効率な場所だった。

ここから導き出される結論は、
「AIが作業を失敗する場所は、データ構造の見直しやプロセス改善の絶好の機会である」
ということです。

さらに言えば、そのデータ構造の見直しやプロセス改善ができたとしたら、それは
「AIで作業を代替できるまで整った設計・設定になっている」
ということではないでしょうか。

私たちが明日からすべきサイクル

AIに触れ、AIが失敗するのを見て「AIは使えない」と結論づけるのは簡単です。
しかし、その失敗をAIのせいにせず、私たちのデータやプロセスを疑うことで、改善のサイクルを回すことができます。

AIに触れる
（エンジニアならコード・設計、デザイナーならUX/デザインツール、営業・CSなら担当する顧客情報など、自分の業務の周辺アセット × AIから）
失敗をAIのせいにせず、データ・プロセスを疑う
データ構造の見直し・プロセス改善を行う
再度、AIでの動作と質を確認する

このサイクルを通じて、「人にも、AIにも優しい」「効率的な仕組み」 を一緒に目指していきましょう。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

データとAIで明らかになる、私たちの課題 〜Snowflake MCP,Salesforce MCPに触れて〜