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

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

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

🧑‍💻 はじめに

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

私たちは、プロダクトが提供する価値をデータで可視化するため、データ基盤の導入やモニタリングを進めてきました。 さらに、様々な部署でのデータ活用を促進する活動の一環として、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が集計に失敗するオブジェクト（仮に「注文書」とします）が存在しました。

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

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

この構造は、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つのことが明らかになりました。

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

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

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

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

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

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

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