Power BI Serviceからオンプレミス・プライベートエンドポイントへ安全に接続する3つの最適解【オンプレゲートウェイ/VNetゲートウェイ/Fabricミラーリング】

Power BI Service からオンプレミスの SQL Server や Azure のプライベートエンドポイントへ、安全かつ高性能に接続する方法は 2025 年時点でいくつかあります。本記事では「オンプレミスデータゲートウェイ」「仮想ネットワーク（VNet）データゲートウェイ」「Microsoft Fabric ミラーリング」を軸に、それぞれの特徴・違い・使い分けを実務視点で整理します。

Power BI Service からオンプレミス／プライベートエンドポイントへ“最適に”つなぐには？

ゴールの整理：何を“最適化”したいのか

「Power BI Service から社内の SQL Server や、プライベートエンドポイント配下の Azure SQL / Storage につなぎたい」という相談には、だいたい次のような条件が付いてきます。

インターネット側からのインバウンド通信は開けたくない
SQL Server などの本番 DB への負荷は最小限にしたい
ユーザーごとの権限を守るためにSSO（シングルサインオン）を効かせたい
なるべく運用（パッチ／バージョンアップ）の負担を減らしたい
将来的には Microsoft Fabric / OneLake などの新しいサービスも活用したい

この要件に対し、2025 年現在の Microsoft 公式ドキュメントと Fabric の最新仕様を踏まえると、選択肢は大きく次の 3 つに整理できます。

結論：3 つの代表的な選択肢

オンプレミスデータゲートウェイ（標準）
Premium 容量がなくても利用できる王道パターン。オンプレミスネットワーク内の Windows マシンにエージェントを入れ、そこから Azure Service Bus へのアウトバウンド通信のみでクラウドに接続します。
仮想ネットワーク（VNet）データゲートウェイ
Power BI Premium / Fabric 容量が前提。Azure VNet 内にマネージドなゲートウェイを用意し、プライベートエンドポイントや ExpressRoute / VPN 経由のオンプレ資産に、Microsoft バックボーン経由で閉域接続します。
Microsoft Fabric ミラーリング（SQL Server → OneLake）
SQL Server データベースを OneLake に常時レプリケーションし、Power BI からは Import / Direct Lake で参照するパターン。初回の取り込み経路としてはデータゲートウェイ（オンプレ or VNet）が必要ですが、その後の閲覧時にはゲートウェイ不要となり、本番 DB への負荷とゲートウェイ依存を大きく減らせます。

さらに Fabric / Private Link の制約を踏まえると、テナントレベルで Private Link を有効化した場合はオンプレミスデータゲートウェイがサポート外となり、代わりに VNet データゲートウェイを使うことが公式に推奨されています。

3 方式のざっくり比較

方式	主な用途	前提ライセンス	到達できる代表的なデータソース	特徴
オンプレミスデータゲートウェイ（標準）	Premium なし環境でのオンプレ接続全般	Power BI Pro / Fabric Free などで可	社内 SQL Server、ファイル共有、Oracle、SAP 等	オンプレに Windows サーバーを用意し、 Azure Service Bus へのアウトバウンド通信のみで動作
VNet データゲートウェイ	Azure VNet 内／ExpressRoute / VPN 越しの閉域接続	Power BI Premium (A4+ / P / F) または Fabric 容量	プライベートエンドポイント付き Azure PaaS、 VNet から到達可能なオンプレ SQL Server など	Microsoft 管理のマネージドゲートウェイ。 SSO（Microsoft Entra ID）対応、サーバーレス運用
Fabric ミラーリング（SQL Server → OneLake）	本番 SQL Server の負荷軽減とゲートウェイ依存の削減	Fabric 容量（F / P など）	SQL Server 2016–2022、2025（条件付き）	SQL Server を OneLake に常時同期。 Power BI は Import / Direct Lake で高速参照

オンプレミスデータゲートウェイ（標準）の詳細

アーキテクチャとネットワーク要件

オンプレミスデータゲートウェイ（標準）は、オンプレミスネットワーク内の Windows マシンにインストールするエージェントです。Power BI や Power Apps など複数のクラウドサービスからのリクエストを受け、社内ネットワーク内のデータソースに接続して結果を返す“中継役”として機能します。

Azure Service Bus / Azure Relay へのアウトバウンド接続のみを使用
必要なポートは TCP 443 / 5671 / 5672 / 9350–9354 の送信方向のみ（インバウンドは不要）
Power BI 以外にも Power Apps / Power Automate / Azure Analysis Services / Fabric Data Factory などから共通利用できる

この「インバウンド不要・アウトバウンドのみ」という性質のおかげで、多くの企業のファイアウォールポリシーに乗せやすく、オンプレ接続の第一候補となることが多いです。

セキュリティ：AD SSO（Kerberos）と Entra SSO

オンプレミスゲートウェイは、次の 2 系統の SSO をサポートする設計になっています。

Active Directory ベース SSO
- Kerberos 制約付き委任（KCD）
- SAML ベース SSO
Microsoft Entra ID（旧 Azure AD）ベース SSO

典型的なパターンは、オンプレミス SQL Server を DirectQuery で参照しつつ、ゲートウェイ側で Kerberos 制約付き委任を構成し、Power BI の閲覧ユーザーごとの権限をそのまま DB に委譲する方式です。これにより、「レポート上で RLS（行レベルセキュリティ）を頑張る」のではなく、既存の DB 権限設計をそのまま活かせます。

性能設計のポイント

オンプレミスゲートウェイのスループットは、ざっくり次の 3 要素で決まります。

ゲートウェイマシンのスペック（CPU / メモリ / NIC）
ゲートウェイ ⇔ データソース間のレイテンシ
Power BI 側のモデル設計（Import / DirectQuery / 増分更新など）

Microsoft の公式ガイドや各種ベストプラクティスを踏まえると、次のような設計が現実的です。

重要なワークロードは専用サーバー（もしくは専用 VM）にゲートウェイを配置
CPU / メモリの目安として、少なくとも 8 コア / 8GB 以上からスタートし、負荷に応じてスケール
ゲートウェイと DB サーバーは同一データセンター／同一サブネット近傍に置き、レイテンシを最小化
アンチウイルスソフトで、ゲートウェイの内部ワークフォルダーを除外し、I/O ボトルネックを避ける
負荷が増えてきたら、ゲートウェイクラスタ（複数台構成）でスケールアウト

運用：毎月のアップデートとサポートポリシー

オンプレミスデータゲートウェイは毎月新しいバージョンがリリースされており、Microsoft がサポートするのは最新 6 バージョンのみです。

毎月 1 回程度のアップデートが提供される
新しいバージョンには最新の Mashup エンジンやバグ修正が含まれる
Fabric 機能をゲートウェイ経由で使う場合は常に最新バージョンの利用が推奨されている

そのため、現実的には：

検証用ゲートウェイクラスタでアップデートを適用・テスト
問題なければ、本番クラスタへ計画的に反映

という 2 段階運用が安全です。

向いているケース

Premium / Fabric 容量はまだなく、まず Power BI からオンプレ DB につなぎたい
オンプレ Windows サーバーを既に保有しており、そこにエージェントを入れられる
Private Link（Fabric 側）がまだ有効化されていない、もしくは予定がない
Power BI 以外にも、Power Apps / Power Automate / Logic Apps などからも共通でオンプレ接続したい

仮想ネットワーク（VNet）データゲートウェイの詳細

VNet データゲートウェイとは

VNet データゲートウェイは、Azure 仮想ネットワーク（VNet）内のリソースや、VNet から ExpressRoute / VPN 経由で到達可能なリソースに対して、Microsoft が管理するマネージドゲートウェイを提供する仕組みです。

特徴をまとめると：

ハードウェアや OS パッチはすべて Microsoft 管理（ゲートウェイ VM を自分で立てる必要なし）
サポート対象ワークロード：
- Fabric Dataflow Gen2 / Data パイプライン / Copy Job
- Fabric ミラーリング
- Power BI セマンティックモデル / Paginated Reports
といった Fabric / Power BI の主要ワークロードをカバー
Power BI 側では「仮想ネットワークデータゲートウェイ」として、通常のゲートウェイと同じ画面から管理可能

接続パターン：Azure 内だけでなくオンプレにも届く

公式ドキュメントでは、VNet データゲートウェイの接続パターンとして次の 3 シナリオが明示されています。

Azure 内のプライベートリソース（プライベートエンドポイント / サービスエンドポイント経由）
Azure 外（オンプレミスなど）のプライベートリソース（ExpressRoute / サイト間 VPN 経由）
パブリックエンドポイントを持つリソース

1 と 2 のパターンでは、通信は Microsoft のバックスボーンネットワーク上を流れ、インターネットに晒されないと明記されています。

つまり、Azure VNet からオンプレミスネットワークへ ExpressRoute / VPN で閉域接続していれば、その先にある社内 SQL Server などにも VNet ゲートウェイ経由で到達できる、ということになります。

ライセンスと制約

VNet データゲートウェイは、Premium / Fabric 容量が前提である点に注意が必要です。

Power BI Premium 容量：A4 以上、P 系列、F 系列（Fabric 容量）
Fabric 側では、すべての Fabric 容量 SKU で利用可能
一部の政府系クラウドなどでは利用不可（GCC L2 など）

また、作成した VNet データゲートウェイは、後からリージョンやサブスクリプション、リソースグループを変更できない制約もあります。ネットワーク設計を見直す場合は、新しい VNet ゲートウェイを作成して移行する必要があります。

セキュリティと Microsoft Entra ID SSO（DirectQuery）

VNet データゲートウェイの「売り」のひとつが、Microsoft Entra ID SSO（DirectQuery）への対応です。

対象コネクタで「Use SSO via Microsoft Entra ID for DirectQuery queries」をオンにすると、
Power BI Service 上でユーザーが操作するたびに、そのユーザーの Entra ID トークンでバックエンドにクエリが飛ぶ
Azure SQL や Azure Synapse など Entra 認証対応 PaaS と相性が良い

これにより、オンプレの Kerberos 設定に頼らなくても、「PaaS 上の DB の権限 = Power BI の閲覧権限」というシンプルなモデルを構築しやすくなります。

運用：パッチなし・クラウド側で一元管理

VNet データゲートウェイは、ハードウェアや OS、ゲートウェイバイナリの更新を含めて完全に Microsoft 管理です。

オンプレミスと異なり、毎月のゲートウェイ手動更新は不要
Power Platform 管理センター、または Power BI の「接続とゲートウェイ」から一元管理
監査ログやネットワークトレースなども Azure 側の機能で取得しやすい

その代わり、ネットワーク設計（VNet / サブネット / プライベート DNS / ExpressRoute / VPN など）を適切に設計できることが前提となります。

向いているケース

既に Power BI Premium / Fabric 容量を保有している
Azure の PaaS（Azure SQL、Azure Synapse、Storage など）を プライベートエンドポイントで閉域化している、またはそうしたい
オンプレミスと Azure 間に ExpressRoute / VPN で閉域を構築済み
Private Link for Fabric / Power BI を有効にしつつ、オンプレや PaaS にも安全に接続したい

Fabric ミラーリングで「ゲートウェイ依存」から段階的に脱却

Fabric ミラーリングとは

Fabric ミラーリング（Mirroring in Fabric）は、SQL Server や Azure SQL などの運用 DB を Fabric OneLake に継続レプリケーションするための機能です。

ミラーリング対象の DB から変更データを取り込み、OneLake 上の Delta テーブルに反映
Fabric ワークスペースには
- 「ミラーされたデータベース」アイテム
- SQL Analytics Endpoint
が作成され、T-SQL や Power BI から分析用途で利用可能
ミラーリングに使われるレプリケーション用コンピュートは追加課金なし（クエリ時の Fabric 容量は従来どおり課金）

Power BI 観点で言えば、本番 SQL Server を直接 DirectQuery するのではなく、OneLake 上のコピーに対して Import / Direct Lake で参照する構成へ移行できる点が大きなメリットです。

サポートされる SQL Server とファイアウォール内 DB

SQL Server 側のサポート状況（2025 年 11 月時点）は次のとおりです。

SQL Server 2016–2022
- Windows 上の Standard / Enterprise / Developer 版
- Linux 版も一部バージョンで対応
- オンプレ / Azure VM / 他クラウド上の SQL Server をサポート
SQL Server 2025
- オンプレミス環境のみサポート（現時点で Azure VM 上の 2025 は対象外）
- Azure Arc + SQL Server 拡張機能が必須

SQL Server がオンプレや閉域内にある場合、そのままでは Fabric から到達できないため、公式ドキュメントではオンプレミスデータゲートウェイまたは VNet データゲートウェイを経由することが推奨されています。

一度ミラーリングを構成してしまえば、Power BI からは OneLake / SQL Analytics Endpoint への接続となるため、レポートの閲覧や更新時にはゲートウェイに依存しなくてよくなります。

メリットと注意点

メリット

本番 SQL Server への DirectQuery をやめ、OneLake 上のコピーに対して Import / Direct Lake で高速に参照できる
Power BI だけでなく、Notebook / Data Warehouse / Data Science など Fabric 全体で同じデータを共有できる
取り込み経路としてのゲートウェイは最小限で済み、「閲覧時のゲートウェイ障害」から解放される

注意点

Fabric 容量が前提（料金・キャパシティ設計が必要）
同期はほぼリアルタイムに近いものの、「完全なトランザクション同期」ではないため、用途によってはラグを意識する必要がある
初回スナップショット時にはソース DB で CPU / IOPS 負荷が増えるため、十分な時間帯を選ぶ必要がある

セキュリティ・性能・運用性で比較する

観点	オンプレミスゲートウェイ	VNet データゲートウェイ	Fabric ミラーリング
ネットワークセキュリティ	アウトバウンドのみで Azure Service Bus に接続。インバウンドポートは不要。	プライベートエンドポイント + ExpressRoute / VPN で Azure バックボーン上のみを通過。	本番 DB への直接アクセスを極小化し、 OneLake 上のコピーを参照。
SSO	AD SSO（Kerberos / SAML）と Entra SSO に対応。	Entra ID SSO（DirectQuery）に対応。	OneLake 側への認証は Entra ID 基盤に統一。
性能	ゲートウェイと DB の近接配置が重要。クラスタ構成でスケールアウト。	VNet 内で経路最適化。 ExpressRoute / VPN のレイテンシ次第。	Import / Direct Lake に最適化され、高速。ただし同期レイテンシは考慮が必要。
運用	毎月の手動アップデートが必要。サポート対象は最新 6 バージョンのみ。	マネージドサービスのため、サーバーパッチやバージョン管理は不要。	ミラーリング設定後は、レポート側からゲートウェイ運用がほぼ消える。
Private Link との相性	Fabric に Private Link を有効化したテナントではサポートされず、エラーとなる。	Private Link シナリオを公式にサポート。	Fabric 側が Private Link でも OneLake 参照は可能。

シナリオ別のおすすめ構成

Premium なし：まずはオンプレゲートウェイで「最短でつなぐ」

Power BI Pro / Fabric Free が中心で、Premium 容量がない場合は、オンプレミスゲートウェイ（標準）一択と言ってよい状況です。

社内ネットワーク内の Windows サーバー（または常時稼働 PC）を 1 台決める
最新バージョンのオンプレミスデータゲートウェイをインストールし、Power BI テナントと紐づける
Power BI Service の「接続とゲートウェイ」から SQL Server などのデータソースを登録し、資格情報とゲートウェイをマッピング
重要なレポートは、同一クラスタに複数台のゲートウェイを登録して HA/負荷分散
必要に応じて Kerberos SSO を構成し、DirectQuery でユーザーごとの権限を DB に委譲

将来的に Premium / Fabric 容量を導入したら、「一部ワークロードを VNet ゲートウェイ + ミラーリングに寄せていく」という段階的移行が現実的です。

Premium / Fabric あり：VNet ゲートウェイでプライベート接続を標準化

既に Premium 容量（A4+ / P / F）や Fabric 容量を持っているなら、Azure VNet + VNet データゲートウェイを標準構成として検討する価値があります。

Azure 上で、データソース用の VNet / Subnet を設計
- Azure SQL / Synapse / Storage などはプライベートエンドポイントを作成し、Private DNS ゾーンを構成
Power Platform 管理センター、または Power BI の「接続とゲートウェイ」から、VNet データゲートウェイを作成
- サブスクリプション / リソースグループ / VNet / Subnet を指定
- Subnet は Microsoft.PowerPlatform/vnetaccesslinks に委任する必要あり
VNet ゲートウェイ上にデータソースを作り、認証情報と SSO 設定（Entra ID SSO）を構成
オンプレ接続も必要なら、VNet とオンプレ間に ExpressRoute / VPN を敷き、VNet から SQL Server へ到達可能にする
Power BI セマンティックモデルの「ゲートウェイ接続」で、該当の VNet データゲートウェイを紐付ける

この構成を取ると、Power BI / Fabric 側に Private Link を有効化しても、VNet データゲートウェイ経由ならサポートされるため、長期的なセキュリティ要件にも対応しやすくなります。

中長期的には：Fabric ミラーリング + Direct Lake で「参照時ゲートウェイ不要」へ

オンプレ／PaaS の DB をそのまま DirectQuery し続けると、「ゲートウェイが落ちると全部止まる」「本番 DB に分析クエリが集中する」といった課題が必ず出てきます。

そこで、枯れたシステムほどFabric ミラーリング + Direct Lakeに寄せていくのがおすすめです。

SQL Server 2016–2025 について、Fabric Portal から「Mirrored SQL Server database」を作成
オンプレであればオンプレ / VNet データゲートウェイ経由で接続し、ミラーリングを有効化
初回スナップショット完了後、Power BI からは OneLake 上のミラーデータベースに対して Import / Direct Lake でモデルを作成
段階的に、旧来の「オンプレ DirectQuery レポート」をミラーリングベースに置き換え

これにより、レポート閲覧時にはゲートウェイやオンプレ DB を経由しなくなるため、ゲートウェイ障害が「分析全停止」になるリスクを大きく減らせるのがポイントです。

その他の選択肢：Fabric Data Factory / Managed Private Endpoints

Dataflow Gen2 / Pipeline + オンプレゲートウェイ

「レポート閲覧時にはゲートウェイを使いたくないが、取り込みのためなら許容できる」というケースでは、Fabric Data Factory（Dataflow Gen2 / パイプライン / Copy Job）を使うパターンも有力です。

オンプレ接続はオンプレミスデータゲートウェイを使用
Dataflow Gen2 でオンプレから OneLake / Lakehouse へ定期取り込み
Power BI は Lakehouse / Warehouse を Import / Direct Lake で参照

この場合も、ゲートウェイは「バッチ取り込みのための専用経路」と割り切れるため、レポート閲覧側の可用性・性能を確保しやすくなります。

Managed Private Endpoints（MPE）+ Private Link

Fabric の最新機能として、Managed Private Endpoints（MPE） を使って、Fabric ワークロードから Private Link Service 経由でオンプレ / カスタムホストのデータソースに接続する仕組みも登場しています。

オンプレ側で Private Link Service（PLS）を構成（必要に応じて ExpressRoute / VPN で Azure と接続）
Fabric ワークスペース管理者が、対象 PLS に対する Managed Private Endpoint を作成
承認後、Spark / Data パイプラインなどの Fabric ワークロードから、Private Link 経由で安全にデータ取得

現時点では主にデータエンジニアリングワークロード向けですが、「MPE で OneLake に集約 → Power BI で参照」という構成を取れば、オンプレゲートウェイでなく Private Link ベースの経路でオンプレ DB を取り込むことも視野に入ってきます。

よくある質問・ハマりどころ

VNet データゲートウェイは「Azure 専用」なのか？

いいえ。公式ドキュメントには、Azure 外のプライベートリソースに対しても ExpressRoute / VPN 経由で接続できると明記されています。

つまり、VNet からオンプレミスネットワークに閉域接続できていれば、その先の SQL Server / Oracle / ファイル共有などにも VNet ゲートウェイ経由で到達できます。

Private Link を有効化すると、オンプレゲートウェイは使えない？

テナントレベルで Private Link を有効化した場合、オンプレミスデータゲートウェイはサポートされません。公式ドキュメントには「Private Link 有効化時にオンプレミスデータゲートウェイはサポートされず、VNet データゲートウェイを使うことが推奨される」と明記されています。

今後 Private Link を導入予定であれば：

中長期的には VNet データゲートウェイ + ミラーリング / MPE を前提としたアーキテクチャ
オンプレゲートウェイは「移行期間の暫定措置」として位置付け

として設計しておくと、後の大規模な組み替えを避けやすくなります。

Power BI Desktop から VNet ゲートウェイ経由で開発できない？

よくある混乱ポイントですが、Power BI Desktop 自体は VNet データゲートウェイを利用しません。

Desktop からデータソースに接続する際は、クライアント PC から直接そのデータソースへネットワーク到達できる必要がある（VPN など）
レポートを Power BI Service へ発行した後、サービス側のデータセットが VNet データゲートウェイを利用する

そのため、「Desktop の開発マシン用 VPN」と「サービス側の VNet ゲートウェイ」は別物として設計する必要があります。

まとめ

Premium なしなら：
- オンプレミスデータゲートウェイ（標準）が最短・王道。
- CPU / メモリ / ネットワークを十分確保し、クラスタ構成で HA とスループットを確保。
- 毎月のアップデート運用は必須。
Premium / Fabric 容量あり & プライベート接続を徹底したいなら：
- Azure VNet + VNet データゲートウェイを標準構成に。
- プライベートエンドポイント + ExpressRoute / VPN で Azure / オンプレを閉域接続。
- Microsoft Entra ID SSO（DirectQuery）でクラウド側の権限管理をシンプルに。
将来を見据えるなら：
- SQL Server は Fabric ミラーリングで OneLake に常時同期。
- Power BI は Import / Direct Lake で OneLake を参照し、閲覧時のゲートウェイ依存を解消。
- オンプレゲートウェイ / VNet ゲートウェイは「取り込み経路」として最小限に。

最終的には、「今すぐつなぐための現実解（オンプレゲートウェイ）」と「数年後も保守しやすい構成（VNet ゲートウェイ + ミラーリング）」のバランスをどう取るかが設計のポイントになります。現在のライセンス状況・ネットワーク構成・将来の Private Link / Fabric 活用方針を整理し、段階的に「ゲートウェイ依存を減らしていくロードマップ」を描いておくと、後悔の少ないアーキテクチャを選びやすくなります。

参考リンク（公式ドキュメント）

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Power BI Serviceからオンプレミス・プライベートエンドポイントへ安全に接続する3つの最適解【オンプレゲートウェイ/VNetゲートウェイ/Fabricミラーリング】

Power BI Service からオンプレミス／プライベートエンドポイントへ“最適に”つなぐには？

ゴールの整理：何を“最適化”したいのか

結論：3 つの代表的な選択肢

3 方式のざっくり比較