Power BI Serviceでsemantic modelのscheduled refreshが資格情報エラーになり、Power BI Desktopでは更新できる。こうしたとき、すぐパスワードを入れ直す前に、Refresh historyで失敗したsourceとエラー全文を確認し、クラウド接続・オンプレミスgateway・OAuth・保存済みcredentialのどこで失敗したかを分けます。Desktopの成功は、Serviceに保存されたcredentialやgateway接続まで正常だと証明しません。
この記事は切り分けの順序を示すガイドです。特定のworkspace、semantic model、data sourceへのアクセスや更新テストはしていません。画面名称はPower BI Serviceの変更で変わる可能性があるため、管理画面の現行項目名とエラー内容を合わせて確認してください。
目次
先に記録する：失敗したsourceと実行経路
Workspaceで対象semantic modelを開き、Refresh historyから失敗した実行の時刻、種類、継続時間、エラー全文を記録します。エラー全文にcredentialが現れていても、保存情報の期限切れだけとは限りません。どのデータsource、どの認証方式、どの接続経路についてのメッセージかを確認します。Refresh historyはscheduledとon-demandの結果・時刻・duration・error messageを調べる入口です。
次に、対象モデルが使うsourceを一覧にします。例えばSharePoint Online、SQL Server、ファイル、複数sourceを組み合わせるPower Queryなどです。source名だけでなく、server/database、URL、環境（本番・検証）、認証方式（OAuth、Windows、Basic、匿名など）を可能な範囲で記録します。パスワード、access token、refresh token、Cookie、client secretは監査票や共有コメントへ書き写さないでください。
切り分けメモの項目：
・対象workspaceとsemantic model
・失敗日時とRefresh historyのエラー全文
・失敗したsourceまたはquery
・Power BI Desktopの更新結果と使用したアカウント
・Service側のData source credentialsの状態
・Gateway and cloud connectionsで選ばれたgateway/connection
・認証方式、資格情報変更日、gateway再インストール有無
・直近のモデル再発行、query変更、schedule停止の有無
Desktopで成功したかどうかは比較材料です。Desktopは利用者のローカル環境や認証状態でデータへ接続しますが、Serviceはモデル設定に保存されたcredentialやgatewayのconnectionを使う場合があります。したがって「Desktopで成功＝Serviceのcredentialも正しい」とは言えません。逆にDesktop側で同じsourceに接続できないなら、Serviceだけの問題と決めつける前にsource自体へのアクセスや認証を確認します。
Serviceの保存credentialを確認する
Power BI Serviceのsemantic model settingsからData source credentialsを確認します。パスワードが変更・失効した、OAuth接続からサインアウトした、gatewayを再インストールした、credentialが保存されていない、といった場合は、権限のあるモデル所有者やデータsource担当者が該当connectionの認証を更新する必要があります。Microsoftのgateway troubleshooting資料では、personal gatewayをアンインストールして再インストールすると、Serviceに保存されたデータsource credentialsが削除されるケースも説明されています。
設定に「credentialがない」「invalid credentials」「sign inが必要」などの明示的な状態がある場合、対象sourceを特定してからその認証方式で再サインインします。複数sourceがあるモデルは、1つのcredential更新で全sourceが直るとは限りません。更新する前後の値は監査記録に残しても、secretそのものは残しません。
ServiceのRefresh historyにinvalid/expired credentialsに関するエラーが出ている場合でも、まずどのsourceのcredentialか確認します。対象connectionの設定が正しく、認証方法も現在のsourceと一致することを確かめてから更新します。ログイン成功を確認したら、Refresh nowを一回実行し、同じsourceで再現するかを確かめます。闇雲に複数sourceのcredentialを一括変更すると、正常だった接続まで切れる可能性があります。
Gatewayが関係する場合の確認順
On-premises data gatewayが必要なsourceなら、semantic model settingsのGateway and cloud connectionsで割り当てられたgatewayがonlineか確認します。gatewayがofflineなら、credentialを何度も入れ直すより、gatewayの状態、サービス実行アカウント、ネットワーク到達性、対応version、登録済みdata sourceを確認します。Microsoftはscheduled refreshの診断で、Refresh history、gateway status、credential更新を確認する順を案内しています。
gatewayのdata sourceとDesktopのsource情報が一致することも重要です。Microsoftの管理資料では、server名とdatabase名はDesktop側とgateway connection側で一致する必要があると説明されています。DesktopでIP addressを使ったのにgatewayではホスト名を指定した、instance名やdatabaseが違う、といった差がないか確認します。gateway data sourceのUsersにモデル所有者または実行に必要な利用者が含まれるか、必要なsourceがすべて登録済みかも管理者が確認します。
Personal mode gatewayを使うケースでは、標準gatewayとの機能差を区別します。Personal modeは個人のImport modelとscheduled/on-demand refresh向けで、集中管理、DirectQuery、クラスタリングや高可用性などには適しません。チーム運用や常時稼働が必要な場合に、単にpersonal gatewayを再インストールして解決しようとせず、組織のgateway設計を担当者へ確認してください。
Cloud sourceとオンプレミスsourceを同じPower Query内で結合・appendしている場合、単独sourceのときとは接続条件が異なる可能性があります。Microsoftの資料は、同一query内でcloudとon-premises dataを結合するシナリオではgatewayを介した構成が必要になり、gateway cluster側でcloud data sourcesのrefreshを許可する設定、on-premises側のconnection、Service側のcloud credentialを確認する流れを示しています。cloud queryとon-premises queryが単に別々に存在するケースと同一query内でmerge/appendするケースは混同しないでください。Power Queryのどの段階で統合しているかを確認してから設定を判断します。
gatewayがonlineでも、Serviceのconnection mappingや権限、server/database文字列が誤っていればrefreshは失敗します。逆に、gatewayがofflineという表示だけでcredential errorの唯一の原因だと断定することもできません。Refresh historyのエラー、Gateway and cloud connectionsの状態、connectionのserver/database一致、利用者権限を同時に確認します。
OAuthの期限・同一tenant条件を疑うケース
Microsoft Entra ID OAuthを利用する一部のdata sourceでは、Power BI Serviceで長時間refresh中にtoken期限が問題になることがあります。Microsoftのrefresh troubleshooting資料は、こうしたOAuth tokenがおよそ1時間で期限切れとなり、データロードが長い場合に資格情報エラーになることがあると説明しています。これはすべてのOAuth connection、すべての失敗に当てはまる診断ではありません。まず対象sourceがその案内に該当するか、refresh時間が長いか、同じ失敗が長い実行で再現するかを確認してください。
同資料は、Power BI ServiceからOAuth2で接続するsourceを使う場合、sourceがPower BI Serviceと同じtenantにある必要があり、現状のmultitenant connection scenarioはサポートされないと記載しています。これは特定のOAuth2接続シナリオについてのMicrosoftの案内です。すべてのPower BI OAuth接続に一般化せず、sourceの製品、tenant、認証方式を確認したうえで適用します。SharePoint Onlineなど該当sourceでは、Serviceにサインインするアカウントとsourceへ接続するアカウントの条件も公式手順に照らして確認します。
OAuthの不具合に見えるときは、保存credentialの再認証だけでなく、tokenの再発行条件、tenant境界、データロード時間、対象source固有の既知制約を見ます。ただしtoken期限の可能性は、エラーを見ただけで確定できるものではありません。Refresh historyのdurationとsource、対象製品の公式資料、必要ならMicrosoftサポートの診断情報を合わせてから原因を記録します。
変更後の単発検証とschedule復旧
変更前に、誰が、どのconnectionまたはcredentialを、どの承認に基づいて変更するか記録します。資格情報を扱える権限者が、必要なsourceに限って更新します。その後、Refresh historyに直近の時刻と変更内容が分かるよう記録し、まず手動Refreshを一回実行します。完了状態、duration、更新日時、該当source、エラー有無を確認し、成功した場合でも後続scheduleが有効になっているかを確認します。
Microsoftのscheduled refresh資料によると、Serviceは4回連続失敗、またはcredential無効など構成変更を必要とする回復不能エラーを検出したとき、scheduleを無効化することがあります。credentialを更新しても、自動的にscheduleが再度有効になるとは限りません。基礎原因を解消した後、Schedule refreshの状態を確認し、承認された担当者が必要なら再度OnにしてApplyします。
更新後の単発refreshが失敗した場合、同じ操作を何度も繰り返しません。新しいRefresh historyのエラーと前回との差を比べ、失敗source、credential、gateway、OAuth、query混在のどの仮説が残ったかを更新します。エラーが「credential」から「gateway unreachable」へ変化したなら、前段の認証問題は変わった可能性がありますが、解決を意味しません。gateway statusとログ、接続一致を別途調べます。
更新が成功しても、結果データが更新されたことを確認します。refreshの成功ステータスと更新timestamp、期待する対象期間・行数、レポート上の値の変化を確認し、古いcacheや対象期間の問題を資格情報の問題と混同しないようにします。大規模データモデルや容量制限でrefreshがtimeoutする場合は、credential変更を繰り返さず、query・容量・refresh時間など別の原因を調査します。
判断マトリクス
・Refresh historyにcredential missing / invalidがあり、gatewayはonline：対象sourceのData source credentials、認証方式、credential変更・失効を確認し、該当connectionだけ再認証。
・Personal gateway再インストール後にcredential missing：Service側のsource credentialsを再設定し、gatewayがonlineか確認。
・Gateway offline / GatewayNotReachable：credential変更を続けず、gateway status、version、サービス、ネットワーク、管理者ログを確認。
・Desktop成功、Service失敗：Serviceの保存credential、gateway mapping、server/database名、ServiceでのOAuthアカウント・tenant条件を照合。
・同じqueryでcloudとon-premisesをmerge/append：gatewayのcloud refresh許可、gateway上のon-premises connection、Service cloud credentialsを個別に確認。
・OAuth sourceで長時間実行中にだけ失敗：sourceが公式資料の対象か、refresh durationとtoken期限の関係を確認。一般のOAuthすべてへ拡張しない。
・credential更新後にscheduleが停止：underlying errorを解消し、schedule状態を確認して権限者が再有効化。
・原因が特定できない、複数tenant/connectionが絡む：secretを除いたerror、time、Trace/diagnostic informationを添えてデータsource管理者またはMicrosoftへ引き継ぐ。
この表は決めつけの対応表ではなく、確認順を選ぶための分岐です。Power BI画面に出る正確なエラー、利用source、認証方式、license/capacity、gateway構成により確認項目は変わります。エラー本文や画面名が変わった場合は、現行Microsoft Learnの該当するTroubleshooting資料を確認します。
再試行前チェックリスト
□ Refresh historyで対象の失敗日時・エラー全文・durationを記録した
□ modelが参照するsourceと失敗したsourceを特定した
□ DesktopとServiceで異なるconnection / credentialsの有無を確認した
□ Data source credentialsの認証方式・期限・再認証状態を確認した
□ gatewayが必要か、割り当てられたgatewayがonlineか確認した
□ gateway connectionのserver/database名・data source登録・利用者権限を確認した
□ Cloud/on-premisesを同一queryでmerge/appendしているか確認した
□ OAuth token・tenant条件がそのsourceに適用される根拠を確認した
□ secretやtokenを記録・共有していない
□ 変更した担当・対象・承認・再試行結果を記録した
□ scheduleが停止していれば、原因修正後に有効状態を再確認した
これらを確認できれば、単に「パスワードを再入力する」から、どの接続のどの設定をどの担当者が直すべきかに進めます。自分がモデル所有者でもgateway管理者でもない場合、権限を越えて資格情報やgatewayを変更せず、記録した差分を担当者へ渡してください。
公式資料
Microsoft Learn｜Configure scheduled refresh
https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-scheduled-refresh（新しいタブで開く）
確認日：2026-10-15
Microsoft Learn｜Troubleshoot Power BI gateway (personal mode)
確認日：2026-10-15
Microsoft Learn｜Troubleshoot refresh scenarios
確認日：2026-10-15
Microsoft Learn｜Merge or append on-premises and cloud data sources
確認日：2026-10-15
Microsoft Learn｜Manage your data source - import and scheduled refresh
確認日：2026-10-15