Microsoft Fabric で Power Query コネクタを使っている場合、今回まず確認すべきなのは「利用中のコネクタ」「ドライバ実装」「ゲートウェイ」「認証方式」です。2026年6月19日公開・更新扱いの「Securing the Power Query connector ecosystem in Fabric」は、特定機能の使い方を案内する更新というより、Power Query コネクタの供給網をより安全にし、コネクタのライフサイクルを明確化する Notice と捉えるのが実務的です。Microsoft は Power Query コネクタを Microsoft 管理の内製コネクタへ寄せ、Preview、GA、Transparent Migration、Retirement の流れを示しています。([Microsoft Fabric Community][1])
すぐに全ワークロードが停止するという告知ではありません。ただし、Snowflake、Google BigQuery、Amazon Redshift、Vertica、IBM Netezza などを Fabric Dataflow Gen2 や Power BI で使っている環境では、ADBC への移行、V2 コネクタ、ゲートウェイ、ユーザーインストール型ドライバの確認が必要です。
Securing the Power Query connector ecosystem in Fabric は何が変わった？
今回の変更点は、大きく分けると「コネクタを誰が管理するか」「どの段階で本番利用できるか」「古い実装から新しい実装へどう移るか」の3点です。
Microsoft Fabric Blog では、Microsoft がコネクタを in-house、つまり Microsoft 所有・管理の形へ移していく方針を示しています。目的は、コネクタのサプライチェーンを安全にし、企業利用で求められるセキュリティ、品質、長期サポートを高めることです。([Microsoft Fabric Community][1])
| 確認項目 | 変更の要点 | 利用者側の確認ポイント |
|---|---|---|
| コネクタ供給網 | Microsoft 管理のコネクタを重視 | 業務で使うコネクタが Microsoft 管理か、外部ドライバ依存かを棚卸しする |
| ライフサイクル | Preview、GA、Transparent Migration、Retirement を明確化 | Preview や古い実装を本番で使っていないか確認する |
| V2 コネクタ | Snowflake、Google BigQuery、Amazon Redshift などで新実装が進む | 既存接続が V1/ODBC か V2/ADBC か確認する |
| ゲートウェイ・ドライバ | Vertica、Netezza などでユーザー側ドライバ管理が重要に | On-premises data gateway のバージョン、設定ファイル、ドライバ導入状況を確認する |
| 移行運用 | 既存ワークロードを止めずに新実装へ移す考え方 | いきなり全体反映せず、検証ワークスペースで比較する |
重要なのは、これは単なるセキュリティ方針の発表ではなく、今後のコネクタ選定や更新計画に影響する変更だという点です。Fabric の Data Factory は Power Query と多数のネイティブコネクタを使ってオンプレミスやクラウドのデータソースに接続できるため、コネクタの扱いはデータ取り込み、変換、更新スケジュールの安定性に直結します。(Microsoft Learn)
影響を受けやすい利用者
影響が大きいのは、Microsoft Fabric の Dataflow Gen2、Power BI セマンティックモデル、Power BI Dataflows、ページ分割レポートなどで Power Query コネクタを使っている組織です。Microsoft Learn では、ADBC へ移行する対象コネクタを使っており、接続内で Implementation パラメーターを明示していない場合や、組織全体で ADBC/ODBC の既定動作を管理したい場合に影響を受けると説明されています。(Microsoft Learn)
| 利用状況 | 優先度 | 理由 |
|---|---|---|
| Snowflake、Google BigQuery、Amazon Redshift を利用 | 高 | V2 コネクタや ADBC 移行の確認が必要 |
| Databricks、Azure Databricks、Impala、Spark、Hive などを利用 | 高 | 埋め込み ODBC から ADBC などへの移行対象に含まれる |
| Vertica、IBM Netezza を利用 | 高 | ユーザーインストール型 ODBC ドライバやゲートウェイ設定の確認が必要 |
| Fabric Dataflow Gen2 で複数の外部 SaaS やDBに接続 | 中 | コネクタごとのサポート状態や認証方式を確認したい |
| Excel、CSV、Web など標準的な接続が中心 | 低〜中 | 直近の影響は限定的だが、コネクタ棚卸しは必要 |
特に注意したいのは、「Power BI だけの話」と誤解しないことです。Microsoft Learn の Power Query コネクタ一覧では、コネクタごとに Excel、Power BI、Fabric Dataflow Gen2、Power Apps、Customer Insights などでのサポート状況が示されています。Fabric Dataflow Gen2 を使っている場合も、自社の接続先がサポート対象かを確認しておくべきです。(Microsoft Learn)
すぐ確認したい設定と運用ポイント
最初に行うべき作業は、Power Query コネクタの棚卸しです。管理者は、ワークスペース単位で「どのデータソースに、どのコネクタで、どの認証方式で、どのゲートウェイ経由で接続しているか」を一覧化してください。
| 手順 | 作業 | 合格基準 |
|---|---|---|
| 接続先の棚卸し | Dataflow Gen2、セマンティックモデル、データフローの接続先を洗い出す | 本番ワークスペースの主要接続が一覧化されている |
| コネクタ実装の確認 | M 式や接続設定で Implementation="2.0" などの有無を確認する | V1/ODBC と V2/ADBC の区別が分かる |
| ゲートウェイ確認 | On-premises data gateway の利用有無、バージョン、導入ドライバを確認する | 誰が更新し、障害時に戻せるかが決まっている |
| 認証方式確認 | ユーザー名/パスワード、Microsoft Entra ID、サービスアカウント、サービスプリンシパルなどを整理する | 個人依存の資格情報が残っていない |
| 検証 | 代表データセットで更新、型変換、件数、実行時間を比較する | 移行前後で差分が説明できる |
| 展開判断 | テナント全体ではなく、検証済みワークスペースから反映する | ロールバック手順がある |
ADBC への移行については、テナント設定とワークスペース単位の上書きが重要です。Microsoft Learn では、管理者が「Users can connect to data sources by using Apache Arrow database connectivity (ADBC)」というテナント設定で既定動作を制御でき、ワークスペース管理者が検証用に上書きできると説明されています。ただし、この制御は段階的に有効化されるため、すべてのテナントですぐ見えるとは限りません。(Microsoft Learn)
コネクタ別に見る注意点
Snowflake を使っている場合
Snowflake コネクタは、埋め込み Simba Snowflake ODBC ドライバから Snowflake ADBC ドライバへ移行中です。ドキュメントでは、新規接続は Snowflake connector implementation 2.0 を既定で使うとされ、既存接続も新実装への更新が推奨されています。(Microsoft Learn)
実務では、更新時間だけで判断しないことが重要です。新実装で速くなるケースがあっても、データ型、集計結果、メモリ使用量、DirectQuery の挙動に差が出る可能性があります。Snowflake では既知の注意点として、count distinct を含むクエリ結果やメモリ使用量に関する記載もあるため、重要レポートは件数照合とメジャー確認まで行ってください。(Microsoft Learn)
Google BigQuery を使っている場合
Google BigQuery コネクタでは、V1 が ODBC ベース、V2 が ADBC ベースとして整理されています。Microsoft Learn では、V2 は大規模分析ワークロード向けにパフォーマンス、信頼性、スケーラビリティを改善する新実装であり、サポートされる環境では新規ワークロードに推奨されると説明されています。(Microsoft Learn)
BigQuery では、組織アカウントとサービスアカウントのどちらで接続しているかも確認してください。個人アカウントで本番更新を回している場合、退職、異動、権限変更で更新失敗につながります。サービスアカウントを使う場合は、JSON キーの管理、ローテーション、アクセス権限の最小化も合わせて見直すべきです。
Amazon Redshift を使っている場合
Amazon Redshift コネクタは implementation 2.0 が GA になっています。Power Query Desktop では新しい Redshift コネクタ実装を有効にすると Implementation="2.0" が接続に追加され、既存接続にも同じオプションを追加できます。(Microsoft Learn)
Redshift は接続時にサーバー名、ポート、データベース名、認証方式、暗号化接続、必要に応じたゲートウェイ設定が絡みます。特に DirectQuery と SSO を使っている場合は、単に更新が成功するかだけでなく、ユーザーごとの権限制御が意図通り働くかも確認してください。(Microsoft Learn)
Vertica を使っている場合
Vertica は注意度が高いコネクタです。Microsoft Learn では、2026年2月から Simba Vertica ODBC ドライバの非推奨プロセスを開始し、Vertica ODBC Driver をサポートする方針が示されています。また、2025年6月以降はクラウド接続をサポートせず、Vertica ODBC ドライバをインストールした on-premises data gateway 経由で接続する必要があると説明されています。(Microsoft Learn)
このため、Vertica 利用環境では「ゲートウェイを使っているか」「ゲートウェイマシンに Vertica ODBC ドライバが入っているか」「設定ファイルの変更履歴を管理しているか」を確認してください。クラウド接続前提のまま放置すると、更新失敗の原因になります。
IBM Netezza を使っている場合
IBM Netezza では、Simba Netezza ODBC Driver の非推奨プロセスが2026年3月から始まり、IBM Netezza ODBC Driver を利用する方向が示されています。2025年7月以降の Power BI Desktop と on-premises data gateway では、ユーザーがインストールした Netezza ODBC ドライバを使うプレビューオプションも用意されています。(Microsoft Learn)
Netezza を使う場合は、Power BI Desktop 側だけでなく、ゲートウェイ側の構成ファイルも確認対象です。検証環境では成功しても、本番更新を担うゲートウェイにドライバや設定が入っていなければ失敗します。
管理者がやりがちな失敗
今回のようなコネクタ変更で多い失敗は、「コネクタ名が同じなら挙動も同じ」と考えることです。同じ Snowflake や BigQuery でも、背後のドライバ実装が変われば、型推論、タイムスタンプ、数値精度、メモリ使用量、エラーメッセージが変わる可能性があります。
もう一つの失敗は、テナント設定を先に変えてしまうことです。ADBC のテナント設定は便利ですが、全体に影響する可能性があります。Microsoft Learn の推奨でも、まずパイロットワークスペースで ADBC を有効にし、重要データセットや更新シナリオを検証してからテナント全体の既定値を判断する流れが示されています。(Microsoft Learn)
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| 本番テナントで一括変更する | 多数の更新失敗を同時に起こす | 検証ワークスペースで先に比較する |
| 更新成功だけを見る | 数値や件数の差分を見落とす | 主要KPI、行数、集計値を移行前後で照合する |
| ゲートウェイを見ない | サービス側だけ成功し、オンプレ接続で失敗する | ゲートウェイのバージョン、ドライバ、設定ファイルを確認する |
| 認証方式を放置する | 個人アカウント依存で更新が止まる | Entra ID、サービスアカウント、サービスプリンシパルを整理する |
| Preview を本番利用する | 仕様変更や制限の影響を受けやすい | GA 状態と既知の制限を確認する |
今後のスケジュールで注意したいこと
ADBC 移行に関する Microsoft Learn では、2026年7月にテナント設定の広範なロールアウト開始、2026年8月に段階的な既定有効化開始、2026年第3四半期後半から第4四半期前半にサービスから ODBC ドライバ削除の開始、2027年春に Power BI Desktop とゲートウェイに ODBC ドライバを同梱しなくなる計画が示されています。いずれも planned とされているため、確定日として扱わず、公式ドキュメントの更新を継続確認してください。(Microsoft Learn)
| 時期 | 予定されている内容 | 実務上の対応 |
|---|---|---|
| 2026年7月予定 | ADBC テナント設定の広範なロールアウト開始 | 管理ポータルに設定が出ているか確認する |
| 2026年8月予定 | ADBC 既定有効化の段階的開始 | 重要ワークスペースの検証を先に終える |
| 2026年Q3後半〜Q4前半予定 | サービス側の ODBC ドライバ削除開始 | ODBC 継続が必要な場合はゲートウェイ利用を検討する |
| 2027年春予定 | Desktop とゲートウェイへの対象 ODBC ドライバ同梱終了 | クライアント更新計画と運用手順を見直す |
ここで重要なのは、「まだ先の話」として後回しにしないことです。データ基盤のコネクタ移行は、レポート数が多いほど棚卸しに時間がかかります。更新エラーが出てから対応するのではなく、どのワークロードがどのドライバに依存しているかを今のうちに可視化しておくべきです。
まずやるべき確認リスト
Microsoft Fabric 利用者は、次の順番で確認すると無駄がありません。
- 本番ワークスペースの Dataflow Gen2、セマンティックモデル、データフローを一覧化する
- Snowflake、Google BigQuery、Amazon Redshift、Vertica、IBM Netezza、Databricks などの利用有無を確認する
- M 式や接続設定で
Implementationパラメーターの有無を確認する - On-premises data gateway の利用有無、バージョン、インストール済みドライバを確認する
- 個人資格情報で動いている更新を洗い出す
- パイロットワークスペースで ADBC または V2 コネクタを検証する
- 行数、主要KPI、更新時間、メモリ使用量、エラー内容を移行前後で比較する
- 問題がなければ、ワークスペース単位、部門単位、テナント単位の順で展開する
今回の「Securing the Power Query connector ecosystem in Fabric」は、すぐに新しい画面操作を覚えるための更新ではありません。むしろ、Fabric と Power BI のデータ接続を長期的に安全・安定して使うための運用見直しの合図です。まずはコネクタ棚卸しを行い、V2/ADBC 移行の対象、ゲートウェイ依存、外部ドライバ依存、認証方式のリスクを把握してください。そのうえで、検証ワークスペースから段階的に移行を進めるのが最も安全です。
[1]: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/Securing-the-Power-Query-connector-ecosystem-in-Fabric/ba-p/5195164 “
Securing the Power Query connector ecosystem in Fa… – Microsoft Fabric Community
“
コメント