Microsoft FabricでPower BIからSnowflakeに接続する際の重要ポイントは、単にコネクタを選ぶことではありません。管理者がPower BI管理ポータルでSnowflake SSOを有効化し、セマンティックモデル作成者がOAuth2（Microsoft Entra ID）とDirectQuery向けSSO設定を正しく構成することが中心です。公式情報では、Snowflake接続はMicrosoft Entra IDによるSSOに対応する点が他の多くのコネクタと異なり、Snowflake、Power BI、Azure側で異なる管理者ロールが関わると説明されています。(Microsoft Learn)
特に2026年5月6日更新の関連公式情報では、Power BIサービスの「セマンティック モデル設定ウィンドウ」がプレビューとして整理され、現在のページから移動せずにデータソース資格情報やゲートウェイ／クラウド接続などを確認・変更できることが示されています。Snowflake連携を展開する管理者や開発者は、SSOの有効化だけでなく、設定場所、ゲートウェイの扱い、既存接続の移行、DirectQueryでの権限評価まで確認しておく必要があります。(Microsoft Learn)
Microsoft FabricでPower BIからSnowflakeに接続する際の結論
Microsoft Fabric環境でPower BIとSnowflakeを連携する場合、最初に判断すべきことは次の3つです。
| 判断項目 | 推奨される考え方 | 確認する人 |
|---|---|---|
| 認証方式 | 可能であればMicrosoft Entra ID／OAuth2を優先する | Fabric管理者、Snowflake管理者 |
| 接続方式 | ユーザーごとのSnowflake権限を反映したい場合はDirectQueryを前提にする | Power BI開発者 |
| ゲートウェイ | プライベート接続やオンプレミスデータゲートウェイが必要かを先に決める | インフラ管理者、Power BI管理者 |
今回のポイントは、「Snowflakeに接続できるか」よりも「誰のIDでSnowflakeにクエリが実行されるか」です。
SSOを有効にしない場合、Power BIの多くのレポートと同じように、保存された資格情報を使ってデータにアクセスします。一方、Microsoft Entra IDによるSSOをDirectQueryで使うと、レポートを操作するユーザーのIDをもとにSnowflakeへアクセスできます。Power BI側の共有設定だけでなく、Snowflake側のユーザー、ロール、ネットワークポリシーも実質的なアクセス制御に関わります。(Microsoft Learn)
何が変わるのか：設定の主役は「テナント設定」と「セマンティックモデル設定」
公式ドキュメントの内容を実務目線で見ると、変更・確認すべきポイントは次のように整理できます。
| 確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| Snowflake SSOのテナント設定 | Fabric管理者がPower BI管理ポータルで有効化する | 組織レベルでMicrosoft EntraトークンをSnowflakeへ送信する許可になる |
| セマンティックモデル側のSSO設定 | 公開後のセマンティックモデルでOAuth2資格情報とDirectQuery向けSSOを設定する | テナント設定だけではレポート単位のSSOは完成しない |
| 設定ウィンドウの利用 | 右側に開くプレビューの設定ウィンドウから設定確認・変更が可能 | 従来の設定ページと併用しつつ、UI変更に注意する |
| ゲートウェイの利用有無 | ゲートウェイ不要な構成では、不要なゲートウェイ紐付けを外す | 意図しない経路や資格情報で接続されるのを防ぐ |
| Snowflakeコネクタ実装2.0 | 新規接続では既定で実装2.0が使われ、古い接続は更新が推奨される | 移行テスト、メモリ使用量、集計結果の検証が必要 |
Power BI管理ポータルでは、Fabric管理者が「Snowflake SSO」を有効化します。この設定は、Power BIサービスからSnowflakeサーバーへMicrosoft Entra認証トークンを送信することへの同意に相当し、反映まで最大1時間かかる場合があります。(Microsoft Learn)
ただし、テナント設定を有効化しただけでは不十分です。Snowflakeコネクタを使ったレポートをPower BIサービスに発行した後、セマンティックモデル作成者が対象ワークスペースのセマンティックモデル設定で、データソース資格情報をOAuth2（Microsoft Entra ID）にし、DirectQueryアクセス時にエンドユーザー自身のOAuth2資格情報を使う設定を選択する必要があります。(Microsoft Learn)
対象者別に見る影響範囲
Fabric管理者・Power BI管理者が確認すべきこと
Fabric管理者は、まずPower BI管理ポータルのテナント設定でSnowflake SSOを有効にするかを判断します。これは組織レベルの設定であり、特定のレポートだけの小さな変更ではありません。
確認すべき項目は次の通りです。
| 確認項目 | 見るべきポイント |
|---|---|
| Snowflake SSO | 管理ポータルの統合設定で有効化されているか |
| 反映時間 | 設定後すぐに検証せず、最大1時間程度の反映時間を考慮しているか |
| ゲートウェイ用Microsoft Entra SSO | オンプレミスデータゲートウェイ経由で使う場合に必要な設定が有効か |
| ゲートウェイ管理者 | ゲートウェイをインストール・管理できるユーザーが適切に制限されているか |
| 監査・展開手順 | 本番テナントで一括展開する前に検証ワークスペースで確認しているか |
オンプレミスデータゲートウェイでMicrosoft Entra SSOを使う場合、この機能は既定で無効です。Fabric管理者が管理ポータルで「Microsoft Entra Single Sign-On (SSO) for Gateway」を有効にする必要があります。(Microsoft Learn)
Power BI開発者・セマンティックモデル作成者が確認すべきこと
開発者が最も注意すべき点は、SSOが「認証方法」だけでなく「接続モード」と強く結び付いていることです。
Power QueryのSnowflakeコネクタ公式情報では、Microsoft Entra IDによるSSOはDirectQueryのみをサポートすると説明されています。つまり、Importモードの更新で「閲覧者ごとのSnowflake権限」をそのまま反映できると考えるのは危険です。(Microsoft Learn)
開発者は、公開前に次を確認してください。
| 確認項目 | 具体的な確認方法 |
|---|---|
| 接続モード | ImportかDirectQueryかを明確にする |
| 認証方式 | Basic、KeyPair、OAuth2のどれでSnowflakeにサインインしているか確認する |
| SSO設定 | DirectQueryで「エンドユーザーが独自のOAuth2資格情報を使用する」設定を有効にする |
| Snowflakeロール | レポート利用者がSnowflake側で必要なロールを持つか確認する |
| パフォーマンス | DirectQueryのビジュアル数、スライサー、行レベルセキュリティ、同時接続を考慮する |
DirectQueryでは、レポートのページ表示やスライサー操作、クロスフィルターなどでSnowflake側にクエリが実行されます。Power BIサービスのDirectQueryにはクエリタイムアウトなどの制約もあるため、Snowflakeウェアハウスのサイズ、クエリ設計、集計テーブルの有無を含めて検証する必要があります。(Microsoft Learn)
Snowflake管理者が確認すべきこと
Snowflake側では、Microsoft Entra IDとSnowflakeユーザーを正しく結び付けることが重要です。
Snowflake公式ドキュメントでは、Power BI SSO利用時に、Microsoft Entra IDのupn属性がSnowflake内のlogin_name、name、またはemail属性にマップされる必要があると説明されています。また、Snowflakeのネットワークポリシーを使っている場合は、Power BIが利用するAzureリージョンのIP範囲を許可する必要があります。(Snowflake Docs)
Snowflake管理者は次の項目を確認しましょう。
| 確認項目 | 失敗しやすいポイント |
|---|---|
| ユーザーマッピング | Entra IDのUPNとSnowflakeユーザー属性が一致していない |
| 既定ロール | レポート閲覧に必要なロールが既定で使えない |
| 高権限ロール | ACCOUNTADMINなどの高権限ロールを安易に許可する |
| ネットワークポリシー | Power BIサービスからの接続元IPを許可していない |
| プライベート接続 | ゲートウェイなしでプライベート接続できると誤解する |
Snowflake公式情報では、ゲートウェイなしの場合、Snowflakeサービスへのプライベート接続はサポートされていません。プライベート接続が必要な場合は、オンプレミスゲートウェイを使う構成を検討する必要があります。(Snowflake Docs)
実際の設定手順
事前に決めること
設定作業に入る前に、次の設計を決めておくと手戻りを減らせます。
| 設計項目 | 選択肢 | 判断基準 |
|---|---|---|
| データ取得方式 | Import / DirectQuery | ユーザーごとのSnowflake権限を反映したいならDirectQuery |
| 認証方式 | Microsoft Entra ID / KeyPair / Basic | 長期運用ではEntra IDまたはKeyPairを優先 |
| 接続経路 | クラウド接続 / オンプレミスデータゲートウェイ / VNet関連構成 | ネットワーク制約やプライベート接続の有無で判断 |
| Snowflakeロール | 利用者ロール / 分析用ロール / 管理者ロール | 最小権限で設計し、高権限ロールは避ける |
| 展開単位 | 検証ワークスペース / 部門別 / 全社 | SSOは影響が大きいため段階展開が安全 |
Power BI管理ポータルでSnowflake SSOを有効化する
Fabric管理者はPower BIサービスに管理者権限でサインインし、管理ポータルのテナント設定から統合設定を開きます。そこで「Snowflake SSO」を有効化し、適用します。(Microsoft Learn)
実務では、設定を有効化した直後に「動かない」と判断しないことが重要です。公式情報では、設定の反映に最大1時間かかる場合があるとされています。検証手順書には、設定時刻、検証開始時刻、対象ワークスペース、対象セマンティックモデルを記録しておくと、トラブルシューティングがしやすくなります。(Microsoft Learn)
Snowflake側でPower BI SSOに必要な構成を行う
Snowflake側では、Power BIからのMicrosoft Entra IDトークンを検証し、Snowflakeユーザーへマッピングできる状態にします。
特に重要なのは次の3点です。
| 設定 | 確認内容 |
|---|---|
| セキュリティ統合 | Power BI SSO用の外部OAuth構成が正しいか |
| ユーザーマッピング | Entra IDのUPNとSnowflakeユーザー属性が対応しているか |
| ネットワーク許可 | Power BIサービスからSnowflakeへ到達できるか |
Snowflakeの高権限ロールをPower BI経由で使う場合は慎重に扱う必要があります。Snowflake公式情報では、ACCOUNTADMIN、ORGADMIN、GLOBALORGADMIN、SECURITYADMINなどのシステムロールは既定でブロックされると説明されています。運用では、Power BI閲覧・分析用のロールを別途作り、必要なデータベース、スキーマ、ビューに絞って権限を付与する方が安全です。(Snowflake Docs)
Power BI DesktopまたはPower QueryでSnowflakeに接続する
Power BI Desktopでは、データ取得からSnowflakeを選択し、Snowflakeサーバー名とウェアハウス名を入力します。必要に応じて、ロール名、接続タイムアウト、コマンドタイムアウト、データベース、ネイティブSQLなどの詳細オプションを指定できます。(Microsoft Learn)
この時点で注意したいのは、詳細オプションを「とりあえず入力する」ことです。特にロール名は、ユーザーが実際に使用できるロールでなければ期待通りに適用されません。開発環境では動くのに本番ユーザーで失敗する場合、ロール名や既定ロールの不一致が原因になりやすいです。
Power BIサービスでセマンティックモデルのSSOを有効化する
レポートをPower BIサービスへ発行したら、対象ワークスペースでセマンティックモデルの設定を開きます。
設定の流れは次の通りです。
| 手順 | 作業内容 |
|---|---|
| 1 | 対象ワークスペースを開く |
| 2 | Snowflakeを使うセマンティックモデルの設定を開く |
| 3 | データソース資格情報でOAuth2（Microsoft Entra ID）を使ってサインインする |
| 4 | DirectQueryアクセス時にエンドユーザー自身のOAuth2資格情報を使う設定を選択する |
| 5 | 対象ユーザーでレポートを開き、Snowflake側の権限通りに表示されるか確認する |
公式情報では、セマンティックモデルはBasic、KeyPair、OAuth2（Microsoft Entra ID）資格情報でSnowflakeにサインインでき、Microsoft Entra IDを使うことで次の手順でSSOを有効化できると説明されています。(Microsoft Learn)
ゲートウェイの設定を確認する
ゲートウェイを使わない構成であれば、基本的にはゲートウェイ設定は不要です。ただし、既にSnowflake資格情報がオンプレミスデータゲートウェイに構成されており、そのデータソースをモデルでのみ使っている場合は、該当データモデルのゲートウェイでセマンティックモデル設定をオフに切り替える必要があると公式情報に記載されています。(Microsoft Learn)
ゲートウェイを使う場合は、データソース名の一致も重要です。Power BIのゲートウェイデータソースでは、セマンティックモデルとゲートウェイデータソースのリンクにサーバー名とデータベース名が使われるため、Power BI Desktop側とゲートウェイ側で名前の形式を一致させる必要があります。(Microsoft Learn)
Snowflakeコネクタ実装2.0への移行で注意すべき点
Power QueryのSnowflakeコネクタでは、すべての新しい接続で既定でSnowflakeコネクタ実装2.0が使われます。また、2025年3月より前に作成された接続は新しい実装へ更新することが推奨されています。(Microsoft Learn)
実装2.0はADBCドライバーを使っており、パフォーマンスやセキュリティ面の改善が説明されています。一方で、移行時には既知の問題も確認が必要です。公式情報では、count distinctロジックを使うSnowflakeクエリで正しくない結果が返る可能性や、メモリ使用量が増える可能性があるとされています。(Microsoft Learn)
移行時の実務チェックは次の通りです。
| チェック項目 | 確認方法 |
|---|---|
| 既存接続の作成時期 | 2025年3月より前の接続か確認する |
| 実装方式 | M式にImplementation="2.0"があるか、Mashupログで確認する |
| 集計結果 | count distinctを使うメジャーやPower Query処理を重点的に比較する |
| メモリ使用量 | 更新時のエラー、容量メトリック、ゲートウェイ負荷を確認する |
| ゲートウェイバージョン | オンプレミスデータゲートウェイは少なくとも2025年1月以降、可能なら最新にする |
| 32bit環境 | 64bit版Power BI Desktopで検証する |
問題が出た場合、公式情報では、Implementation="2.0"を削除してODBCコネクタを使い続けることで一時的に業務中断を避けられる可能性があると説明されています。ただし、KeyPair認証では設定に関係なくADBCドライバーが使われる点に注意が必要です。(Microsoft Learn)
Microsoft FabricのDataflow Gen2やData Factoryとの違い
Microsoft Fabricでは、Power BIセマンティックモデルだけでなく、Dataflow Gen2やコピーアクティビティでもSnowflake接続を扱います。ただし、対応する認証方式や設定画面は完全に同じではありません。
FabricのSnowflakeデータベース接続に関する公式情報では、コピーとDataflow Gen2でSnowflake、Microsoftアカウント、KeyPairなどの認証がサポートされ、サービスプリンシパルはコピー側でサポートされると整理されています。また、Microsoft Entra IDは推奨される認証方式として説明され、FabricではワークスペースIDを使ってSnowflakeへ認証できるシナリオも示されています。(Microsoft Learn)
Power BIレポートのSSOを設定しているのか、Dataflow Gen2でデータを取り込んでいるのか、コピーアクティビティでデータ移動をしているのかを混同しないようにしましょう。設定画面の名称が似ていても、実行主体、資格情報の保存場所、Snowflakeに見えるユーザーが異なる場合があります。
よくある失敗と対策
| 失敗例 | 原因 | 対策 |
|---|---|---|
| Snowflake SSOを有効にしたのにSSOにならない | テナント設定だけで、セマンティックモデル側のOAuth2設定が未完了 | セマンティックモデルのデータソース資格情報とDirectQuery向けSSO設定を確認する |
| Importモードでユーザー別権限が反映されると思っていた | Microsoft Entra ID SSOはDirectQueryのみサポート | ユーザー別のSnowflake権限を使うレポートはDirectQueryで設計する |
| 本番ユーザーだけエラーになる | Snowflake側のユーザーマッピングやロールが不足 | Entra IDのUPN、Snowflakeユーザー属性、既定ロールを確認する |
| ゲートウェイ経由になってしまう | 既存のゲートウェイデータソースがモデルに紐付いている | 不要なゲートウェイ設定をオフにする |
| プライベート接続で接続できない | ゲートウェイなし構成ではSnowflakeプライベート接続がサポートされない | オンプレミスデータゲートウェイを使う構成を検討する |
| 集計結果が移行前と違う | Snowflakeコネクタ実装2.0の既知問題に該当 | count distinctを使う処理を重点的に検証する |
| 更新時にメモリエラーが出る | 実装2.0でメモリ使用量が増えるケースがある | データ量削減、容量見直し、実装方式の一時切り戻しを検討する |
| UI手順書がすぐ古くなる | セマンティックモデル設定ウィンドウがプレビュー段階 | 画面名だけでなく、設定項目名と目的を手順書に記載する |
展開前チェックリスト
本番展開前に、次のチェックリストを使って確認してください。
| 区分 | チェック内容 |
|---|---|
| テナント設定 | Snowflake SSOがPower BI管理ポータルで有効化されている |
| 反映確認 | 設定反映までの時間を考慮して検証している |
| Snowflake側 | Power BI SSO用のセキュリティ統合が構成されている |
| ユーザー属性 | Entra IDのUPNとSnowflakeユーザー属性が対応している |
| ロール | 高権限ロールではなく、分析用の最小権限ロールを使っている |
| ネットワーク | SnowflakeネットワークポリシーでPower BIからの接続が許可されている |
| 接続モード | SSOを使うレポートがDirectQueryで設計されている |
| 資格情報 | セマンティックモデルでOAuth2（Microsoft Entra ID）を使っている |
| ゲートウェイ | 必要な場合のみゲートウェイを使い、不要な紐付けは外している |
| コネクタ実装 | Snowflakeコネクタ実装2.0への移行影響を検証している |
| 性能 | DirectQueryのビジュアル数、同時利用、Snowflakeウェアハウス負荷を確認している |
| 運用 | 接続エラー時の担当範囲をPower BI、Fabric、Snowflake、ネットワークで分けている |
まず取るべき次の行動
Microsoft FabricでPower BIからSnowflakeへ接続する場合、最初にやるべきことは、既存レポートをすぐ変更することではありません。まず、対象レポートを「Importでよいもの」と「DirectQuery＋SSOが必要なもの」に分けてください。
そのうえで、DirectQuery＋SSOが必要なレポートについて、Fabric管理者、Power BI開発者、Snowflake管理者で次の順に確認します。
| 順番 | 作業 |
|---|---|
| 1 | Power BI管理ポータルでSnowflake SSOを有効化する |
| 2 | Snowflake側でPower BI SSO用の統合、ユーザー、ロール、ネットワークを確認する |
| 3 | Power BI DesktopでDirectQueryレポートを作成・発行する |
| 4 | セマンティックモデルでOAuth2資格情報とエンドユーザーOAuth2利用を設定する |
| 5 | 一般ユーザー権限で表示、操作、Snowflake側のクエリ実行を検証する |
| 6 | 既存接続についてSnowflakeコネクタ実装2.0への移行影響を確認する |
Snowflake接続の成否は、Power BIの画面だけでは判断できません。Entra ID、Power BIセマンティックモデル、ゲートウェイ、Snowflakeロール、ネットワークポリシーが一体で動きます。小さな検証ワークスペースでSSO、DirectQuery、ゲートウェイ有無、コネクタ実装2.0を確認してから、本番レポートへ段階的に展開するのが安全です。
コメント