第8章 Power BI Semantic Model連携

8-1. なぜPower BIとCoWorkの数字がずれるのか

Snowflake上の同じデータを使っていても、Power BIとCoWorkが別々に集計ロジックを持つと結果がずれることがあります。

原因	例
Metric定義	Power BIは返品除外、CoWorkは返品込み
Filter Context	Power BIでは有効顧客だけを対象
日付定義	暦年と会計年度が違う
RLS	利用者ごとに見えるデータが違う
DAX独自ロジック	単純SUMでは再現できないMeasureがある

8-2. Power BI Semantic Modelとは

Power BI Semantic Modelは、Table・Relationship・Measure・Calculationなどを持つ分析モデルです。Power BI Reportは、このSemantic Modelを通じて一貫した指標を表示できます。

flowchart LR S[Snowflake] --> P[Power BI Semantic Model] P --> M[DAX Measures] M --> R[Power BI Reports]

8-3. パターンA：Power BI Semantic Modelを直接AIから使う

MicrosoftはPower BI MCP Serverを提供しており、AI AgentからSemantic ModelのSchema取得やDAX Query実行が可能です。Remote MCP Serverには「Execute Query」「Get Semantic Model Schema」などのツールがあります。

flowchart TD U[利用者] --> C[Snowflake CoWork] C --> A[Cortex Agent] A --> MCP[MCP Connector] MCP --> PBIMCP[Power BI Remote MCP Server] PBIMCP --> PBI[Power BI Semantic Model] PBI --> DAX[DAX Measureを実行] DAX --> A --> U

最大の利点：Power BIで表示しているMeasureそのものをDAXで実行できれば、Power BIとAIで同じ計算ロジックを利用しやすくなります。

重要：Snowflake Cortex AgentsはRemote MCP Connectorを、MicrosoftはRemote Power BI MCP Serverを提供していますが、Snowflake→Power BIの組み合わせを手順化した公式共同ガイドまでは確認できません。実導入では認証方式・MCP互換性・ネットワーク・権限をPoCで検証してください。

8-4. Power BI MCPでできる代表操作

操作	用途
Get Semantic Model Schema	Table・Column・Measure・Relationship等のメタデータを取得
Execute Query	DAX QueryをSemantic Modelに実行

Execute QueryはSemantic Model IDとDAX Queryを指定します。ユーザー認証ではRLSが適用される設計が可能ですが、Service Principal認証ではRLSの扱いに注意が必要です。

8-5. パターンB：Power BI定義をSnowflake Semantic Viewへ移植する

flowchart TD PBI[Power BI Semantic Model] --> DEF[Measure・Relationship・業務定義を棚卸し] DEF --> SV[Snowflake Semantic View] SV --> CA[Cortex Analyst] CA --> CW[CoWork]

Power BIとの直接接続を使わず、重要MeasureをSnowflake側のMetricとして再定義する方式です。Snowflakeネイティブで完結しやすい反面、DAXとSnowflake SQLの二重管理が発生します。

8-6. どちらを選ぶべきか

観点	Power BI直接参照	Snowflakeへ移植
Power BIとの数値一致	最も狙いやすい	定義同期が必要
Snowflake内完結	外部MCP利用	しやすい
DAX Measure再利用	できる	SQL/Metricへ再実装
運用	MCP認証・Power BI権限も管理	定義の二重管理に注意
複数Semantic Model	Model IDの選択・ルーティング設計が必要	Snowflake側で統合・分割設計

8-7. 推奨：重要指標は「System of Record」を決める

数値一致を最優先するなら「この指標の正解はどこにあるか」を決めます。

例
売上金額        → Power BI Measureを正とする
粗利率          → Power BI Measureを正とする
在庫金額        → Snowflake Semantic Viewを正とする
社内文書検索    → Cortex Searchを正とする

Agent Instructionsに「売上・粗利はPower BIツールを優先する」などのルーティングルールを与えると、回答の一貫性を高められます。

8-8. 複数のPower BI Semantic Modelがある場合

複数モデルそのものが直ちに問題になるわけではありませんが、Agentがどのモデルを使うか迷わない設計が必要です。

対策	内容
モデルカタログ	Friendly NameとSemantic Model IDを管理
ドメイン分割	営業・在庫・財務など用途を明確化
Instructions	質問領域ごとに優先モデルを指定
重複Measure整理	同名・異定義のMeasureを減らす

8-9. サンプル：Power BIと一致させる

Power BI側のMeasureが以下だとします。

売上金額 =
CALCULATE(
    SUM(Sales[Amount]),
    Sales[ReturnFlag] = FALSE()
)

CoWorkがSnowflakeのSUM(Amount)を直接計算すると、返品分だけ差が出ます。Power BI MCP経由でこのMeasureを実行するか、Snowflake Semantic View側に同じ「返品除外」定義を実装する必要があります。

この章で理解したこと

Power BIとCoWorkの数値ずれはMetric・Filter・RLS・DAXが主因
Power BI MCP ServerでSemantic Model Schema取得やDAX Query実行が可能
Cortex Agent側はMCP Connectorを使える
直接参照方式とSnowflakeへの定義移植方式の2つがある
重要指標ごとに「正解の定義元」を決めることが重要