Fabric の on-premises data gateway 手動即時アップデートを一言で言うと、管理者が「今この時間に更新したい」を選べるようになった機能です。March 2026 の Microsoft Fabric updates では、この考え方が一般提供として整理され、メンテナンスウィンドウや変更管理に合わせて gateway 更新を進めやすくなりました。従来の「各サーバーで新しいインストーラーを手動実行する」更新がすぐ不要になるわけではありませんが、更新の主導権が明らかに管理者側へ寄ったのが大きな変化です。 (Microsoft Learn)
この記事では、Fabric の on-premises data gateway 手動即時アップデートで何が変わったのか、自動更新と何が違うのか、保守窓口でどんな価値があるのか、そして PowerShell にどう組み込むと運用しやすいのかを、実務目線で整理します。先に結論を言うと、この機能の価値は「便利になった」よりも、計画更新・段階更新・証跡管理がしやすくなったことにあります。 (Microsoft Learn)
Fabric の on-premises data gateway 手動即時アップデートで何が変わったのか
時系列で見ると、2025 年 12 月に manual update が preview として登場し、2026 年 2 月も preview、2026 年 3 月の Fabric の What’s new では “On-premises data gateway auto-update (admin triggered)” が Generally Available として掲載されています。一方で、更新手順ページの見出しは 2026-03-28 時点でも UI / Programmatic Update に (preview) 表記が残っています。現場では、機能の考え方は GA として整理されたが、個別手順ページの文言は追従中と理解しておくと混乱しません。 (Microsoft Learn)
なお、2026 年 2 月の What’s new では portal / API / PowerShell で管理者が更新をトリガーできると案内されていましたが、2026 年 3 月末時点の公開手順ページで明示されているのは ポータルと PowerShell です。自動化を急ぐなら、まずは PowerShell ベースで運用設計するのが無難です。 (Microsoft Learn)
自動更新との違いを先に整理
従来の更新は、最新の standard mode gateway をダウンロードし、インストーラーを実行して、更新後に再サインインする流れが基本でした。新しい方式では、Fabric または Power BI ポータルの Manage Gateways から更新を発火でき、PowerShell でも Update-DataGatewayClusterMember で更新を開始できます。さらに、更新処理専用の On-premises Data Gateway Updater Service は、UI または PowerShell でトリガーされたときだけ動作します。 (Microsoft Learn)
| 観点 | 従来の更新 | 管理者主導アップデート |
|---|---|---|
| 更新の起点 | サーバーで新しいインストーラーを取得して実行 | Fabric / Power BI ポータル、または PowerShell から発火 |
| 作業の中心 | サーバー上の手作業 | 管理ポータルや運用スクリプト |
| 適用のタイミング | サーバー作業者の都合に寄りやすい | メンテナンスウィンドウに合わせやすい |
| 更新処理 | インストーラー実行が前提 | トリガー後は Updater Service が処理 |
| 向いている場面 | 単発更新、旧来手順の継続 | 定例保守、計画更新、複数 gateway の標準化 |
この表でいちばん大事なのは、「勝手に毎月上がる」わけではない点です。Power Platform の管理ドキュメントでは、on-premises data gateway は「更新が自動インストールされない」と明記されています。Fabric 側の新機能も、Microsoft 側が一方的に適用するものではなく、管理者が好きなタイミングで更新ジョブを起動し、その後の適用を任せる方式と理解するとズレが少ないです。 (Microsoft Learn)
管理者主導アップデートが現場でうれしい理由
メンテナンスウィンドウに合わせやすい
March 2026 の What’s new では、この機能の価値として maintenance windows に合わせて更新できることと、PowerShell による programmatic update が挙げられています。月次メンテが土曜深夜、四半期ごとに変更審査が必要、といった現場では、ここが一番効きます。更新可否の判断と実行タイミングを IT 側で握れるため、データ連携担当とインフラ担当の会話が噛み合いやすくなります。 (Microsoft Learn)
保守窓口で標準手順を作りやすい
新しい流れは、更新候補の確認 → 実行 → 状態確認 → 必要ならログ採取に分けやすいのが利点です。公式には Get-DataGatewayClusterStatus や Update-DataGatewayClusterMember -CheckStatus で状態確認でき、障害時は gateway アプリの Diagnostics > Export logs や Event Viewer からログを集められます。保守窓口にとっては「誰が見ても同じ順番で確認できる」こと自体が価値です。 (Microsoft Learn)
高可用クラスタを安全に更新しやすい
Microsoft は、gateway cluster に複数メンバーがある場合、1 台ずつ無効化して処理を流し切り、更新してから再有効化する順次更新を推奨しています。さらに、メンバー間のバージョン差があると、古いノードにルーティングされたクエリだけ失敗するなどの不安定さが起こり得るため、同一バージョン維持が重要です。管理者主導アップデートは、この「順番に確実に上げる」運用と相性がいいです。 (Microsoft Learn)
更新前に確認したいチェックポイント
手動即時アップデートを使う前に、次の 5 点は先に確認した方が安全です。要件を外したまま当日作業に入ると、ボタンが出ない、途中で止まる、クラスタが不安定になる、という失敗につながりやすいです。 (Microsoft Learn)
| チェック項目 | 確認内容 | 実務での判断基準 |
|---|---|---|
| ベースライン | 2025 年 11 月 baseline 以降か | それ未満なら、まず従来手順で baseline 以上へ上げる |
| 空き容量 | 10 GB 以上あるか | Windows Update や一時ファイルで減りやすいので事前確認必須 |
| 権限 | Gateway admin 権限があるか | 作業者が運用担当でも、gateway admin でないと更新できない |
| クラスタ構成 | 2 台以上か単体か | 複数台なら 1 台ずつ更新する前提で計画する |
| 目標バージョン | 最新へ上げるか、指定版へ上げるか | Get-DataGatewayAvailableUpdates で候補確認後に決める |
あわせて、Microsoft は on-premises data gateway を毎月更新し、直近 6 リリースのみをアクティブサポートしています。Fabric を gateway 経由で使う場合は、最新版へ上げることで Fabric 機能更新や既知問題修正が反映されやすくなります。サポート一覧では March 2026 update は 3000.310 とされています。 (Microsoft Learn)
Fabric / Power BI ポータルから手動即時アップデートする手順
ポータルから更新する流れはシンプルです。UI で急ぎの 1 台を上げたいときや、定例保守をまず手動で安定化したいときに向いています。 (Microsoft Learn)
- Fabric または Power BI ポータルで Manage Gateways を開く
- On-premises data gateways タブを選ぶ
- 更新したい gateway を選ぶ
- 新しいバージョンがある場合、更新インジケーターを確認する
- Update を選ぶ
- インストール完了後に gateway status を更新して確認する (Microsoft Learn)
更新インジケーターが出ないときは、単純に新しいバージョンがまだ出ていないケースに加え、先に 2025 年 11 月 baseline まで上げる必要がある可能性も見ます。特に古い gateway を長く維持していた環境では、いきなり「ポータルから即時更新」に切り替えるのではなく、まず baseline 到達を優先した方が安全です。 (Microsoft Learn)
PowerShell 運用と相性がいい理由
March 2026 の What’s new では PowerShell model for gateways も Generally Available とされており、gateway のライフサイクル管理、更新、復旧、構成変更を PowerShell で扱いやすくする流れが強まっています。定例保守を runbook 化したい、複数 cluster を横断したい、夜間変更でヒューマンエラーを減らしたいなら、PowerShell を軸にした方が長期的には楽です。 (Microsoft Learn)
PowerShell 側の前提も整理されています。公式の overview では PowerShell 7.0.6 以降 が前提で、Install-Module -Name DataGateway でモジュールを導入し、他の cmdlet 実行前に Connect-DataGatewayServiceAccount で Data Gateway サービスへ接続します。認証はユーザーだけでなく、サービス プリンシパルや証明書にも対応しています。 (Microsoft Learn)
# 前提: PowerShell 7.0.6 以降
Install-Module -Name DataGateway
# 対話ログイン
Connect-DataGatewayServiceAccount更新の基本フローは次の形です。まず対象 cluster を把握し、次に利用可能な更新候補を確認し、その後に更新を発火して状態を追います。公式 cmdlet として Get-DataGatewayCluster、Get-DataGatewayAvailableUpdates、Update-DataGatewayClusterMember、-CheckStatus が用意されています。 (Microsoft Learn)
$gatewayClusterId = "<GatewayClusterId>"
# 更新候補を確認
Get-DataGatewayAvailableUpdates -GatewayClusterId $gatewayClusterId
# 最新版への更新を開始
Update-DataGatewayClusterMember -GatewayClusterId $gatewayClusterId
# 更新状態を確認
Update-DataGatewayClusterMember -GatewayClusterId $gatewayClusterId -CheckStatus特定メンバーだけを段階的に上げたい場合や、検証済みの版へ狙って上げたい場合は、-MemberGatewayId と -TargetVersion が使えます。Update-DataGatewayClusterMember は Nov 2025 以降の gateway が前提で、Get-DataGatewayAvailableUpdates でサポート対象の更新版を確認できます。 (Microsoft Learn)
$gatewayClusterId = "<GatewayClusterId>"
$memberGatewayId = "<MemberGatewayId>"
$targetVersion = "<TargetVersion>"
Update-DataGatewayClusterMember `
-GatewayClusterId $gatewayClusterId `
-MemberGatewayId $memberGatewayId `
-TargetVersion $targetVersion複数 cluster をまとめて扱う運用では、Get-DataGatewayCluster -Scope Organization も選択肢です。ただし Organization スコープは O365 テナント管理者、Power Platform 管理者、Power BI 管理者向けです。なお、この PowerShell cmdlet 群は on-premises data gateway 向けであり、overview では VNet gateway には対応しない点も明記されています。 (Microsoft Learn)
保守窓口で使いやすい運用フロー
保守窓口で実務に落とすなら、次の 4 ステップにしておくとブレにくいです。
- 作業前に対象 cluster / member、現在版、目標版、メンテナンス時間を記録する
- ポータルまたは PowerShell で更新を発火する
-CheckStatusや portal status で完了確認を行う- 失敗や停滞があれば、Diagnostics > Export logs と Event Viewer の gateway service ログを採取する (Microsoft Learn)
この形にしておくと、「更新したのに直らない」「どこまで進んだか分からない」「次の担当者へ引き継げない」といった保守あるあるをかなり減らせます。特に gateway 更新はデータソースやネットワーク要因も絡むので、実行結果とログの両方を残すことが重要です。 (Microsoft Learn)
運用でハマりやすいポイント
| ハマりどころ | なぜ起きるか | 実務での対策 |
|---|---|---|
| クラスタをまとめて更新する | 逃がし先がなくなり、処理中ジョブや refresh に影響しやすい | 1 台ずつ無効化して流し切ってから更新する |
| メンバーの版差を放置する | 古いノードに当たったクエリだけ失敗することがある | クラスタ全体を同一版にそろえる |
| 10 GB 空き容量を見落とす | 更新条件を満たせず途中でつまずく | 作業前チェックに組み込む |
| 「Update を押した」で完了扱いにする | 実際の完了や停滞を見落とす | status 確認を必須化する |
| 障害時にログを取らない | 切り分けが属人化しやすい | Diagnostics と Event Viewer の採取を標準化する |
上の対策は、Microsoft が示している順次更新手順、クラスタ内バージョン整合性の重要性、空き容量要件、状態確認 cmdlet、ログ採取手順を、運用現場向けに並べ直したものです。特に複数メンバー構成では、「全部一気に」より「少しずつ確実に」の方が結果的に早く終わるケースが多いです。 (Microsoft Learn)
迷ったらこの順で進めれば失敗しにくい
Fabric の on-premises data gateway 手動即時アップデートは、単なる新ボタンではありません。更新のタイミングを管理者が握れること、PowerShell に載せやすいこと、クラスタを順番に安全に上げやすいことが本質です。March 2026 時点では、この考え方が GA として整理されており、運用チームが本気で使い始めるタイミングに入ったと見てよいでしょう。 (Microsoft Learn)
まずやるべきことはシンプルです。
- 今の gateway が Nov 2025 baseline 以降か確認する
- 単体 gateway ならまずポータル更新で流れを固める
- 複数 cluster や夜間変更があるなら、PowerShell で 候補確認 → 更新発火 → 状態確認の runbook を作る
- 高可用クラスタでは必ず 1 台ずつ更新する (Microsoft Learn)
この順で進めれば、Fabric gateway の更新は「毎月の面倒な作業」から、「計画的に回せる標準運用」へ変えやすくなります。
コメント