Power BI のオンプレミス データ ゲートウェイでレポート更新が失敗する、Gateway connections に対象ゲートウェイが出てこない、誰にデータソース利用権限を付けるべきか分からない――こうした問題の多くは、「Add or remove a gateway data source – Power BI」で説明されているデータソース登録・削除・権限管理の基本を押さえることで防げます。
結論から言うと、管理者が最優先で確認すべきポイントは、Power BI Desktop 側とゲートウェイ側のサーバー名・データベース名を完全に一致させること、データソース単位でユーザー権限を管理すること、SSO を使う場合は Microsoft Entra SSO のテナント設定と対象データソースを確認することです。データソースを削除すると、それに依存するダッシュボードやレポートは動作しなくなるため、削除前の棚卸しも欠かせません。Microsoft Learn の対象ページでは、Power BI のオンプレミス データ ゲートウェイにデータソースを追加・削除し、スケジュール更新や DirectQuery、ユーザーアクセス管理に使う流れが整理されています。(Microsoft Learn)
Microsoft の新機能・変更点：「Add or remove a gateway data source – Power BI」で確認すべきポイント
「Add or remove a gateway data source – Power BI」は、新しい可視化機能の紹介というより、Power BI Service とオンプレミス データ ゲートウェイを安全に接続するための運用手順を示す公式ドキュメントです。対象ページ本体の Microsoft Learn 上の最終更新日は 2025年10月2日と表示されています。一方で、関連する SSO 公式情報は 2026年7月1日に更新されており、特に Microsoft Entra SSO を利用する組織では併せて確認する必要があります。(Microsoft Learn)
実務上のポイントは、次の4つです。
| 確認ポイント | 管理者が見るべき内容 | 放置した場合の影響 |
|---|---|---|
| データソース登録 | ゲートウェイクラスター、接続名、データソース種類、サーバー名、データベース名 | スケジュール更新や DirectQuery でゲートウェイが候補に出ない |
| 認証方式 | Basic、Windows、OAuth2、SSO の使い分け | 認証失敗、更新失敗、権限過多 |
| ユーザー権限 | ゲートウェイ全体ではなくデータソース単位で共有 | 不要なユーザーが社内データへ接続できる |
| 削除前確認 | 依存する semantic model、レポート、ダッシュボード | 削除後に業務レポートが停止する |
特にグローバル企業では、日本本社、海外拠点、地域別データセンターでサーバー名の表記が揺れやすくなります。たとえば Power BI Desktop では SERVER\INSTANCE、ゲートウェイ側では IP アドレスで登録している場合、同じ SQL Server を指していても Power BI Service は別物として扱う可能性があります。対象ページでも、Power BI Desktop とゲートウェイ側のサーバー名・データベース名が一致している必要があると説明されています。(Microsoft Learn)
影響範囲：レポート利用者よりも管理者・所有者への影響が大きい
この更新ポイントの影響は、一般の閲覧者よりも、Power BI 管理者、ゲートウェイ管理者、semantic model 所有者、データベース管理者に強く出ます。
| 対象者 | 影響範囲 | 具体的に確認すべきこと |
|---|---|---|
| Power BI 管理者 / Fabric 管理者 | テナント設定、SSO、ゲートウェイ導入制御 | Microsoft Entra SSO for Gateway を有効化するか、誰にゲートウェイ導入を許可するか |
| ゲートウェイ管理者 | データソース登録、認証情報、ユーザー管理 | 登録済みデータソースの棚卸し、不要接続の削除、権限の最小化 |
| semantic model 所有者 | スケジュール更新、DirectQuery 接続 | Gateway connections が Running になるか、更新履歴で失敗していないか |
| データベース管理者 | 接続アカウント、SSO、権限設計 | サービスアカウントの権限、Kerberos / Microsoft Entra ID 認証の要件 |
| セキュリティ担当者 | 認証情報、トークン、共有範囲 | SSO トークンの扱い、過剰な共有、退職者や異動者の権限残存 |
Power BI のオンプレミス データ ゲートウェイは、オンプレミス環境にあるデータと Power BI などのクラウドサービスをつなぐ橋渡しの役割を持ちます。Power Platform 管理センターではゲートウェイクラスター、状態、バージョン、メンバー、管理者などを確認できます。(Microsoft Learn)
データソース追加の基本手順
Power BI Service でオンプレミス データ ゲートウェイにデータソースを追加する流れは、次のように整理できます。
| 手順 | 操作 | 実務上の注意点 |
|---|---|---|
| 1 | Power BI Service の設定から「Manage connections and gateways」を開く | 管理者権限または対象ゲートウェイへの適切な権限が必要 |
| 2 | 「New」を選択して新しい接続を作成する | 似た名前の接続を乱立させないよう命名規則を決める |
| 3 | On-premises、Gateway cluster name、Connection name、Data Source Type を指定する | 本番・検証・地域名を接続名に含めると運用しやすい |
| 4 | SQL Server などのサーバー名・データベース名を入力する | Power BI Desktop 側の表記と完全一致させる |
| 5 | Basic、Windows、OAuth2 などの認証方式を選ぶ | 個人アカウントではなく、可能な限り管理されたサービスアカウントを使う |
| 6 | 必要に応じて SSO と Privacy level を設定する | DirectQuery、Import、Kerberos、Microsoft Entra SSO の違いを確認する |
| 7 | Create を実行し、作成成功を確認する | その後、対象 semantic model の Gateway connections で Running を確認する |
対象ページでは SQL Server を例にしていますが、他のデータソースでも考え方は同じです。重要なのは、Power BI Desktop で使った接続情報と、ゲートウェイに登録した接続情報が一致していることです。複数のデータソースを使う semantic model では、すべてのデータソースをゲートウェイに追加しないと、スケジュール更新用のゲートウェイとして表示されない場合があります。(Microsoft Learn)
データソース削除で最も注意すべきこと
データソースの削除は、使っていない接続を整理するうえで必要です。ただし、削除するとそのデータソースに依存するダッシュボードやレポートは動作しなくなります。Microsoft Learn でも、使わなくなったデータソースを削除できる一方で、依存するダッシュボードやレポートが停止することが明記されています。(Microsoft Learn)
削除前には、最低限次の確認を行います。
| 確認項目 | 確認方法の例 | 判断基準 |
|---|---|---|
| 利用中の semantic model | ワークスペースの設定、更新履歴、所有者確認 | 直近で更新・閲覧されているものは削除しない |
| レポート・ダッシュボード依存 | 対象 semantic model を利用するレポートを確認 | 業務利用中なら代替接続を先に作る |
| 所有者 | semantic model owner、ゲートウェイ管理者、業務部門 | 所有者不明なら削除せず棚卸し対象にする |
| 更新スケジュール | Schedule refresh、Refresh history | 定期更新が設定されている場合は要注意 |
| 代替接続 | 新接続で Running になるか | 切り替え確認後に旧接続を削除する |
よくある失敗は、「接続名が古いから不要」と判断して削除してしまうケースです。接続名が古くても、サーバー移行前の semantic model や月次レポートで使われていることがあります。削除は、利用実績と所有者確認を済ませてから行うべきです。
スケジュール更新と DirectQuery で起きやすい問題
データソースを追加した後、その接続はスケジュール更新または DirectQuery で利用できます。スケジュール更新の設定画面では、Gateway connection、Data source credentials、Schedule refresh などの項目を確認します。オンプレミス データ ゲートウェイを使う場合、認証情報はゲートウェイ管理者がデータソース側で定義するため、semantic model 側で個別に入力しない構成になります。(Microsoft Learn)
トラブルが起きた場合は、次の順番で確認すると原因を切り分けやすくなります。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| Gateway connections に対象ゲートウェイが出ない | サーバー名・データベース名の不一致、ユーザー権限不足、未登録データソース | Desktop とゲートウェイの接続情報を照合し、Users タブに対象ユーザーまたはグループを追加 |
| 更新が失敗する | ゲートウェイがオフライン、認証情報の期限切れ、接続先DBの権限不足 | Gateway status、Data source credentials、Refresh history を確認 |
| DirectQuery がユーザーごとに期待どおり制御されない | SSO の未設定、データソース側権限の不足 | SSO 方式とデータソース側のユーザー権限を確認 |
| 複数データソースのモデルで更新できない | 一部のデータソースがゲートウェイに登録されていない | semantic model が参照する全データソースを登録 |
| 更新スケジュールが無効化される | 連続失敗または非アクティブ状態 | エラーを解消し、スケジュールを再有効化 |
スケジュール更新は、一定期間利用がない場合に一時停止されることがあります。また、更新失敗が続く場合や認証情報の不備など回復不能なエラーが検出された場合、更新スケジュールが無効化されることがあります。管理者は Refresh history と Gateway status を定期的に確認する運用を作るべきです。(Microsoft Learn)
Microsoft Entra SSO を使う場合の確認ポイント
2026年7月1日に更新された関連公式情報で特に重要なのが、Microsoft Entra SSO の扱いです。Power BI のオンプレミス データ ゲートウェイでは、Active Directory ベースの SSO と Microsoft Entra SSO を選択できるケースがあります。SSO は Power BI の semantic model でサポートされますが、Power BI dataflows ではサポートされないと説明されています。(Microsoft Learn)
Microsoft Entra SSO は、Microsoft Entra ID ベースの認証を利用するクラウドデータソースへ、ゲートウェイ経由でユーザー本人の ID を使ってアクセスする仕組みです。DirectQuery レポートで利用すると、Power BI を操作しているユーザーの Microsoft Entra ID に基づいてクエリが実行されます。(Microsoft Learn)
ただし、Microsoft Entra SSO は既定で無効です。Fabric 管理者が Fabric 管理ポータルで「Microsoft Entra single sign-on (SSO) for Gateway」のテナント設定を有効にしなければ、オンプレミス データ ゲートウェイや VNet gateway で Microsoft Entra SSO を使うことはできません。加えて、ゲートウェイ所有者がトークンを扱える立場になり得るため、ゲートウェイの展開権限や VNet 管理権限を最小化することが推奨されています。(Microsoft Learn)
SSO 設定で判断すべきこと
| 判断項目 | Kerberos / AD SSO が向くケース | Microsoft Entra SSO が向くケース |
|---|---|---|
| 主な対象 | 社内ネットワーク内のオンプレミスデータソース | Microsoft Entra ID 認証を使うクラウドデータソース |
| 代表的な用途 | SQL Server、SAP HANA、Oracle などの社内DB | Azure SQL、Azure Synapse、Azure Data Explorer、Snowflake など |
| 認証の考え方 | ドメイン、Kerberos 制約付き委任、SAML など | ユーザーの Microsoft Entra トークン |
| 管理の焦点 | SPN、委任、ドメイン参加、サービスアカウント | Fabric テナント設定、ゲートウェイ導入制御、VNet 管理 |
| 注意点 | Kerberos 設定ミスでユーザー単位の制御が効かない | 既定では無効。トークン取り扱いリスクを考慮する |
データソース追加画面の SSO オプションでは、Kerberos を使った DirectQuery、Kerberos を使った DirectQuery と Import、Microsoft Entra ID を使った DirectQuery などの選択肢が示されています。対象ページでは、Microsoft Entra ID による DirectQuery の SSO オプションについて、テナント管理者が許可していることと、対象データソースが SQL Server、Azure Data Explorer、Snowflake、Denodo Preview であることが条件として示されています。(Microsoft Learn)
一方で、SSO の概要ページでは、Microsoft Entra ID や Kerberos に対応する複数のデータソースが整理されています。実際の導入では、Power BI の接続画面だけで判断せず、対象コネクタごとの公式ドキュメントとテナント設定を確認するのが安全です。(Microsoft Learn)
移行期限はあるのか
確認できる公式情報の範囲では、「Add or remove a gateway data source – Power BI」の手順そのものに対して、全テナント一律の移行期限や強制切り替え日は示されていません。したがって、今回のポイントは「期限までに移行しないと使えなくなる」というより、既存のゲートウェイ接続を棚卸しし、認証・SSO・権限管理を現在の推奨運用に合わせて見直すことにあります。(Microsoft Learn)
ただし、移行期限が明示されていないからといって、後回しにしてよいわけではありません。特に次の環境では、早めに確認すべきです。
| 環境 | 早めに確認すべき理由 |
|---|---|
| 個人アカウントでゲートウェイ接続を作っている | 退職・異動・パスワード変更で更新が止まる可能性が高い |
| DirectQuery と SSO を使っている | ユーザーごとのデータアクセス制御に直結する |
| 海外拠点ごとにゲートウェイを設置している | 地域、サーバー名、権限グループのばらつきが起きやすい |
| 複数ワークスペースで同じDBを参照している | 接続の重複や不要権限が残りやすい |
| Private Link や VNet 経由の接続を検討している | オンプレミス データ ゲートウェイではなく VNet data gateway が適する場合がある |
VNet data gateway は、Azure やその他データサービスを Microsoft Fabric や Power Platform に接続するための仕組みで、Private Endpoint や Private Link のシナリオで利用できます。一方で、対応ワークロードや SKU、リージョン変更不可などの制約もあるため、オンプレミス データ ゲートウェイの単純な置き換えとしてではなく、ネットワーク要件と合わせて検討する必要があります。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
Power BI ゲートウェイのデータソース管理では、「接続できること」だけでなく、「誰が、どの権限で、どのデータに接続しているか」を継続的に管理することが重要です。
| チェック項目 | 確認内容 | 推奨アクション |
|---|---|---|
| ゲートウェイクラスター | 本番・検証・地域別に整理されているか | 命名規則を統一し、不要なクラスターを棚卸し |
| ゲートウェイバージョン | クラスター内のメンバーが同じバージョンか | バージョン差による予期しない失敗を避ける |
| データソース名 | 接続名だけで用途が分かるか | prd-jp-sql-sales のように環境・地域・用途を含める |
| サーバー名・DB名 | Power BI Desktop とゲートウェイで一致しているか | IP、FQDN、インスタンス名の表記を統一 |
| 認証情報 | 個人アカウントに依存していないか | 最小権限のサービスアカウントを検討 |
| ユーザー権限 | データソース単位で必要なユーザーだけに付与されているか | Microsoft Entra セキュリティグループで管理 |
| SSO | Kerberos か Microsoft Entra SSO か | 対象データソース、DirectQuery / Import、テナント設定を確認 |
| 削除予定接続 | 依存する semantic model が残っていないか | 所有者確認後、段階的に削除 |
| 更新履歴 | 失敗が継続していないか | Refresh history と Gateway status を定期確認 |
| API 管理 | 手作業だけに依存していないか | REST API で棚卸し・権限確認を自動化 |
Power BI REST API には、ゲートウェイの取得、データソース作成、削除、状態確認、データソースユーザーの追加・削除、認証情報更新などの操作が用意されています。大規模環境では、管理画面で個別に確認するだけでなく、API を使って定期的に接続情報や権限を棚卸しする運用が有効です。(Microsoft Learn)
グローバル運用で失敗しやすいポイント
グローバル向けに Power BI を運用している企業では、単一拠点よりもデータソース管理が複雑になります。特に注意したいのは、地域ごとの表記揺れと権限管理の分散です。
たとえば、日本では SQL-JP01\PROD、米国では 10.20.30.40、欧州では DNS エイリアスを使っているような構成では、Power BI Desktop の作成者ごとに接続文字列が変わり、ゲートウェイ接続が一致しない原因になります。データベース管理者は「同じDB」と考えていても、Power BI Service 側では別の接続として扱われることがあります。
また、海外拠点の担当者をゲートウェイ管理者にしている場合、データソースの作成・削除・ユーザー追加がローカル判断で進み、不要な接続や過剰権限が残りやすくなります。Power Platform 管理センターでは、Global administrator、Power BI service administrator、Gateway administrator などのロールによってゲートウェイ管理にアクセスできます。テナント管理者は、全社のゲートウェイを見渡せる管理ビューを使い、導入者と管理者を分けて統制することが重要です。(Microsoft Learn)
実務でおすすめの運用ルール
Power BI ゲートウェイのデータソース管理は、最初にルールを決めておくと後から破綻しにくくなります。最低限、次のルールを整備しましょう。
| ルール | 具体例 |
|---|---|
| 接続名の命名規則を決める | 環境-地域-システム-データソース種類 の形式にする |
| サーバー名の表記を統一する | IP アドレス、FQDN、インスタンス名のどれを使うか決める |
| 個人アカウントを避ける | 更新用アカウントはサービスアカウント化し、権限を最小化する |
| ユーザーはグループで付与する | 個人追加ではなく Microsoft Entra セキュリティグループで管理する |
| 削除は申請制にする | 依存レポート、所有者、代替接続を確認してから削除する |
| SSO は用途別に標準化する | DirectQuery の個人別権限制御が必要な場合だけ SSO を使う |
| 定期棚卸しを行う | 四半期ごとに接続、所有者、権限、更新失敗を確認する |
特に「User with resharing」や「Owner」を安易に付与すると、データソース利用範囲が広がりすぎる可能性があります。対象ページでは、データソースの Users タブで User、User with resharing、Owner を選べると説明されています。共有前には、ユーザーまたはグループが信頼でき、必要最小限の権限だけを持っているか確認することが重要です。(Microsoft Learn)
まとめ：まずは接続情報・権限・SSO の3点を棚卸しする
「Add or remove a gateway data source – Power BI」で管理者が押さえるべき本質は、データソースを追加するボタン操作ではありません。Power BI Desktop、Power BI Service、オンプレミス データ ゲートウェイ、データベース、Microsoft Entra ID の間で、接続情報と権限を一貫させることです。
まず実施すべきことは、次の3つです。
- 登録済みゲートウェイデータソースの一覧を作り、サーバー名・データベース名・所有者・利用中の semantic model を確認する
- データソース単位の Users を見直し、不要な個人権限や退職者・異動者の権限を削除する
- DirectQuery や SSO を使う接続について、Kerberos、Microsoft Entra SSO、Fabric テナント設定、対象データソースを確認する
移行期限が明示された変更ではないものの、ゲートウェイ接続の不備は更新失敗や情報漏えいリスクに直結します。Power BI を業務基盤として使っている組織ほど、今回の公式情報をきっかけに、接続管理を「作った人任せ」から「管理者が継続的に棚卸しする運用」へ切り替えるべきです。
コメント