AIものさし

Power BIのスケジュール更新が無効になったとき、原因を直して再開する

Power BIのscheduled refreshがDisabledになったら、Refresh historyとcredential・gateway・capacityのエラーを確認し、修正後に安全に再開します。

AIものさし編集部

Power BI Serviceのsemantic modelで予定更新がDisabledになったら、スケジュールをOnへ戻す前にRefresh historyのエラーを確認します。Power BIはscheduled refreshが4回連続で失敗した場合、または無効・期限切れcredentialなど、設定修正が必要な回復不能エラーを検出した場合にスケジュールを無効化します。Embedded capacityが停止中の場合は、最初の更新失敗で直ちに無効化される場合もあります。したがって「4回失敗したはず」と決めつけず、対象semantic modelの状態と具体的なエラーを読みます。

Power BI Desktopで手動更新できても、Service側のcredential、gateway、ネットワーク、capacityまで正常とは限りません。再開するのは原因を修正した後です。停止期間中にデータソースが変わっている場合、次回更新が最新状態を取得するか、更新履歴とソース側の最終更新時刻を照合します。

目次

まずRefresh historyを開く

Power BI Serviceで対象workspaceを開き、semantic modelのRefreshまたはSchedule refreshからRefresh historyを表示します。モデル名だけでなくworkspace、semantic model、所有者、更新時刻を確認してください。Refresh historyにはstatus、開始時刻、実行時間、エラーメッセージが表示されます。停止前の最後の成功と、最初の失敗、その後の連続失敗を並べます。

次の4項目を記録します。

  • 最後に成功した更新の時刻

  • 最初に失敗した更新と、その後の失敗回数

  • エラー全文と発生した時刻

  • Gateway and cloud connections、Data source credentialsの表示状態

credentialやprivate dataを含む診断ログを共有する場合は、アカウント名・token等を伏せます。エラーが途中で切れている場合、画面の詳細表示や必要な管理者ログで全文を確認してください。

エラーから原因層を分ける

Refresh historyのメッセージを起点に、次の順で切り分けます。

表は横にスクロールできます

エラーの手掛かり確認先次の確認
401、403、credential、sign-inData source credentials対象sourceの再認証、アカウント、権限、条件付きアクセス
GatewayNotReachable、timeout、接続失敗Gateway and cloud connectionsgateway online、data source mapping、server/database名、ネットワーク
Unsupported data sourcePower BIのsource対応条件対象sourceと接続方式がService refresh対応か
Query / Processing errorRefresh historyの詳細、Power Query失敗したquery・step・入力schema・source側変更
Capacity / throttling / timeoutcapacityと更新スケジュール同時実行、処理量、更新間隔、capacity状態
4回連続失敗またはschedule Disabled上記原因を特定後にSchedule refresh根本原因を直したあとスケジュールを再有効化

この表は原因を決める早見表であり、エラーコードだけで解決方法を確定するものではありません。例えば接続timeoutならgatewayとは限らず、source serviceの一時障害やnetwork policyも候補です。エラー本文、開始時刻、同じ時間帯の他モデルの結果を照合します。

Desktopで成功し、Serviceで失敗する理由

Desktopの更新は、実行中のPCに保存されたcredentialやローカルファイル、インストール済みdriver、到達可能な社内networkを利用することがあります。Power BI Serviceはsemantic modelの設定にあるcredential、cloud connection、gatewayを通じてsourceへ接続します。そのためDesktopで更新できても、Serviceから同じsourceへ接続できるとは限りません。

確認する項目は次の通りです。

  1. DesktopとServiceで同じsource、server、database、file pathを指定しているか。

  2. ServiceのData source credentialsが有効で、必要なアカウントに権限があるか。

  3. on-premises sourceなら、正しいgateway clusterとdata source mappingが選ばれているか。

  4. Gatewayがonlineで、Power BI Serviceが表示するversion要件を満たしているか。

  5. Entra ID OAuthを使うsourceなら、Serviceへのサインインアカウントがsourceへのアクセス条件に合うか。

  6. source側のpassword、server名、network、schemaが最後の成功以降に変わっていないか。

Data source credentialsを更新する権限がない場合、semantic model ownerやPower BI administratorへ、Refresh historyのエラーと確認済みのsource条件を渡します。credentialを共有したり、ブラウザへパスワードを貼り付けたりしないでください。

Gatewayとsourceを確認する

on-premises data sourceを更新する場合は、Power BI Serviceのsemantic model settingsでGateway and cloud connectionsを確認します。対象gatewayがonlineで、モデルのsourceと一致するdata sourceが割り当てられているかを見ます。Gatewayの一覧に表示されているだけでは、そのモデルとsourceが正しくmappingされているとは限りません。

特にserverとdatabaseの名前がDesktopの設定とGateway側のdata sourceで一致するかを確認します。DNS名とIP、短いhost名とFQDNなど表記が異なると、同じサーバーを指しているつもりでもmappingされないことがあります。gatewayがofflineなら、実行マシン・service・通信を管理者に確認してもらいます。gatewayの再起動や再登録は、影響範囲を確認できる管理者が行います。

Unsupported data sourceの表示がある場合は、資格情報を何度も入れ直さず、対象sourceと接続方式がServiceのscheduled refreshに対応しているかを公式資料で確認します。Desktopで接続できることは、Serviceでのrefresh対応を意味しません。

Query、capacity、その他の失敗

Refresh historyでqueryやprocessing errorが示された場合は、失敗したqueryやstepを特定します。sourceの列名・型が変わった、期待したファイルがない、Power Queryの式が空値や新しいschemaに対応していないなどを確認します。全queryを一度に作り直さず、失敗箇所とsourceの変更を対応づけます。

Capacity関連のmessageなら、同じworkspace/capacityの更新が同時刻に集中していないか、実行時間が増えていないか、上限やthrottlingが発生していないかを管理者と確認します。更新時間をずらす、データ量を減らす等の変更は、対象capacityの状態と利用要件を確認してから決めます。共有capacityとPremium/Embedded等では適用条件が異なります。すべての環境に同じrefresh回数・timeoutを当てはめないでください。

Embedded capacityが停止している場合、スケジュールが直ちに無効化される条件があります。capacityが再開したことだけで問題解決とみなさず、semantic modelのRefresh historyと容量管理者の状態を確認します。原因が不明なら、詳細エラー、request IDが表示される場合はそのID、発生時刻、workspace、gateway/capacityの状況を揃えてMicrosoft Supportまたは管理者に渡します。

原因を直した後にスケジュールを再有効化する

Microsoft Learnの手順は、Refresh historyで失敗内容を調べ、根本問題を解消した後にSchedule refreshをOnへ戻してApplyする流れです。再有効化は原因修正の代わりになりません。invalid/expired credentialsなど回復不能エラーが残る状態でOnにしても、次の失敗を招きます。

再開前に次を確認します。

  • 失敗原因に対応する変更が保存された。

  • credentialを更新した場合、Serviceがそのsourceへ接続できる状態になった。

  • Gatewayを使う場合、onlineでsource mappingが一致している。

  • Power Queryやsourceに必要なschema・ファイルがある。

  • schedule設定とtimezone、次回予定時刻が意図どおり。

  • ownerまたは運用担当が次回Refresh historyを確認できる。

  • 停止中に元データが更新された場合、次回refreshが何を取り込むか分かる。

条件を満たしたらSchedule refreshをOnに戻し、Applyします。その後、Refresh historyの次の実行でstatus、duration、error messageを確認します。成功表示だけで終わらず、レポートが参照する期間・行数・更新時刻がsourceと合うかを確認してください。必要に応じてRefresh nowを使う場合も、対象モデルの容量や実行負荷を考慮します。

再開してはいけない状態

次の場合は原因が確定するまでSchedule refreshをOnにしないでください。

  • エラーの詳細を読めず、同じ原因の失敗が続いている。

  • credential、gateway、source mappingを変更する権限がない。

  • Gatewayがoffline、またはmodelのsourceとmappingの一致を確認できない。

  • Sourceのschema・server・ファイルが変わり、queryの修正範囲が分からない。

  • Capacity停止やthrottlingが継続している。

  • 次回更新で重複・誤集計が起きる可能性があるのに、影響確認ができない。

Power BI Service上で再開操作をする前に、owner/adminへ渡す記録をまとめます。Workspace、semantic model、Refresh historyの時刻、エラー全文、gateway/capacity状態、最後に変更したsourceやcredentialの時期、確認したが未解決の条件を含めます。パスワードやaccess tokenは含めません。

次にすること

  1. Refresh historyで最後の成功と最初の失敗を確認する。

  2. エラーをcredential、gateway/connectivity、unsupported source、query、capacityへ分類する。

  3. DesktopとServiceの接続条件を比較する。

  4. 原因を一つずつ修正し、権限がなければowner/adminへ渡す。

  5. Schedule refreshを再有効化し、次のRefresh historyとsource側の結果を照合する。

4回連続失敗で無効化されたケースでも、修正するべきものは4回の数字ではなく根本原因です。回復不能エラーやEmbedded capacity停止では4回を待たず無効化される場合があるため、表示されている状態と最新の公式説明を優先します。

公式Sources

Checked: 2026-10-15

Editorial Note: Microsoft Learnの現行資料に基づく一般的な診断記事。特定workspace、semantic model、gateway、capacityの状態は確認していない。