Power BI Serviceの更新履歴がCompletedでも、期待した新しいデータが取り込まれ、レポートに表示されたとは限りません。更新処理がエラーなく終了したことと、対象の行が実際に処理されたことは別です。まず対象がdataflowかsemantic modelかを区別し、更新履歴の警告・処理量・対象期間と、元データの更新時刻を照合してください。
dataflowでは、Refresh historyからCSVを取得し、Rows processedとBytes processedを確認できます。どちらも0、または通常より大幅に少ない場合は、データが取り込まれていない可能性があります。Microsoftは、incremental refreshの対象期間に新規データがない、フィルターが全件を除外する、上流dataflowに変更がない、sourceに変更がないケースを挙げています。一方、semantic modelでは履歴のwarningsや更新段階を見て、読み込み後のモデル・計算・表示へ原因を切り分けます。種類の違う履歴指標を同じものとして比較しないことが出発点です。
目次
まず更新対象と見えている場所を特定する
Power BIでは「データが古い」という症状が、dataflow、semantic model、report、dashboard tileのどこにあるかで調査先が変わります。workspace、対象アイテム名、更新開始・終了時刻、使っているレポートページ、期待する数値と実際の数値を記録します。dataflowを更新しただけでsemantic modelやreportが更新されたと考えたり、semantic modelの更新履歴だけでdataflowの処理量を判断したりしないようにします。
表は横にスクロールできます
| 状態が古く見える場所 | 最初に見る対象 | ここで分かること |
|---|---|---|
| dataflowのentity | dataflow Refresh historyとCSV | entityごとの処理状況・行数・処理量 |
| semantic model | modelのRefresh history、warnings、更新段階 | モデル更新の完了状態と非致命warning |
| reportのvisual | modelの最終更新とvisualが参照する列・measure | データは更新されたが計算やフィルターで変化しない可能性 |
| dashboard tile | tile側の反映時間とpin元visual | semantic model更新後のtile反映待ちやpin元の違い |
Microsoftのトラブルシューティングでは、dashboard tileへの反映に10〜15分待ってから再確認するケースがあります。これはdashboard tileについての案内です。通常のreportページやsemantic modelのすべてに一律の待ち時間が必要だという意味ではありません。
1. dataflowならRefresh history CSVの処理量を見る
dataflowを対象にする場合、workspaceでdataflowのRefresh historyを開き、問題のrunを選びます。履歴のCSVをダウンロードし、対象entityとrun時刻を確かめたうえで、Rows processedとBytes processedを前回の正常runや通常時の値と比較してください。Microsoftの案内では、これらが0または想定より大きく低い場合、新しいデータが処理されなかった可能性があります。ただし、処理量だけで原因を確定できるわけではありません。行数が少ないのが正常な日もあるため、source更新記録と同じ期間を見ます。
表は横にスクロールできます
| 見る値 | 記録方法 | 読み取り方 |
|---|---|---|
| Run status / duration | 問題のrunと前回正常runを並べる | Completedか、通常より極端に短いか |
| Rows processed | entity/partitionごとに記録 | 0または少なければ、処理対象がない可能性 |
| Bytes processed | 同じentity・run単位で比較 | 通常より極端に低い場合、データ取得量の差を疑う |
| Source watermark | 元システム側の更新時刻・最大ID等 | source自体に新しいデータがあったか |
| Refresh policy | 対象期間と保存期間 | 新しい行がpolicyの更新範囲に入るか |
CSVの列や詳細度はdataflowの種類・容量などで異なる場合があります。画面に存在しない指標を推測で埋めず、利用できる列名と対象単位を記録します。Rows processedが正の値でも、期待した行を意味するとは限りません。対象entity、日付範囲、filter、source watermarkをセットで確認します。
2. incremental refreshの範囲とfilterを確認する
更新範囲を日付で区切っている場合、今回追加したデータの日付が実際にrefresh対象期間へ入っているか確かめます。たとえば保存期間を数年にしても、毎回再取得する期間を直近数日に絞っている設計なら、古い日付の過去データは通常のrefreshで再処理されないことがあります。新しい記録のタイムゾーンや日付列が想定と違えば、対象期間外として扱われる可能性もあります。
次に、dataflowまたはmodelのqueryにある日付フィルターを確認します。境界条件、対象列、型、タイムゾーンを、今回入れたsource recordの値と照合してください。filterが正しく見えても、source側に新しい行がない、または上流dataflowが未更新なら、下流で処理量が増えないことがあります。
表は横にスクロールできます
| 確認対象 | 手元で比較する値 | 不一致があった場合 |
|---|---|---|
| Source | 新規レコードの作成・変更日時、最大キー | 元データの投入処理や更新時刻を確認 |
| Refresh range | 保存期間、incremental refresh対象期間 | 対象行の日付が更新範囲に含まれるか確認 |
| Filter | date column、開始/終了条件、値の型 | 代表レコードを1件、条件へ照合 |
| Upstream dependency | 参照元dataflowやqueryの最終更新 | 上流が新しいデータを処理したか確認 |
| Entity / partition | 処理対象になったentityやpartition | 期待した範囲が選択されたか確認 |
全履歴refreshやincremental refresh policyの変更を最初の診断として行わないでください。処理量・容量・下流への影響が増えることがあります。まず小さな安全テストで対象期間とfilterを検証し、広い再処理が必要なら管理者と実行範囲を決めます。
3. semantic modelならwarningsと更新段階を確認する
semantic modelのRefresh historyでは、Completedという表示だけでなく、警告が付いていないか、更新処理がどの段階まで進んだかを確認します。Power BIでは非致命的な問題があっても更新statusがCompletedとなり、warningsに詳細が出る場合があります。例として、存在しない列を参照するmeasure、型の不一致、古いgatewayに関する警告などが案内されています。更新履歴に警告があるなら、reportの値が期待と異なる理由がそこにないか読みます。
同じデータがsemantic modelへ入っていても、visualの値が変わらないことがあります。reportのfilter、slicer、measure、relationship、対象期間などが該当行を除外していないか確認します。列がsourceでrenameまたは削除されていれば、schema変更によりvisualやDAX式が壊れることもあります。履歴の警告とモデルの最終更新が正常でも、reportの表示が業務上正しいとは限りません。
表は横にスクロールできます
| 観察 | 次の確認 |
|---|---|
| model refreshがCompleted with warnings | warning本文、対象table/column/measure |
| dataflow側は処理量が増えたがmodelが古い | modelが参照するsource、refresh順、依存関係 |
| modelは更新済みだがvisual値が同じ | 対象行、filter、measure、relationship、時点 |
| dashboard tileだけ古い | pin元visualとtile反映時間 |
| refresh履歴に期待するrunがない | 操作者、API/XMLA経由か、run履歴の表示条件 |
更新経路によって履歴への現れ方が異なるケースもあります。たとえばMicrosoftの説明では、public XMLA endpointから開始したrefreshは、すべての段階を完了しsourceから新しいデータを取得した場合にRefresh history画面へ表示されるとされています。API等から実行したrefreshを調査するときは、開始方法と該当の監査・response情報も確認します。
4. 結果から原因を分ける
次の表を埋め、最初に差が見つかった層を次の調査先にします。同じrunについてsource、dataflow、semantic model、reportを一度に変更すると、どの変更で直ったか分からなくなるためです。
表は横にスクロールできます
| Sourceに新規データ | dataflow処理量 | model更新 | report表示 | 主な候補 |
|---|---|---|---|---|
| なし | 0に近い | 完了 | 古い | source未投入、または対象期間外 |
| あり | 0に近い | 完了 | 古い | filter、incremental range、上流依存 |
| あり | あり | warningあり | 古い/一部欠落 | model schema、型、measure、gateway warning |
| あり | あり | 更新済み | 古い | visual filter、measure、relationship、dashboard tile |
| あり | 記録不明 | 履歴なし | 古い | refresh種別、実行主体、履歴表示先の取り違え |
これは診断の順序を決める表で、特定原因を自動断定する判定器ではありません。証拠が足りない行は「不明」と記録し、sourceや管理者側のログを追加で確認します。
5. 安全な再テスト記録
修正前に、対象item、run IDや時刻、source watermark、CSV/警告の必要部分を保存します。資格情報・個人情報・機密データは監査メモへ複製しません。原因候補を一つに絞ってから、テスト環境または影響が限定された範囲で再テストします。フル更新、policy変更、filter削除が必要な場合は、データ量と再処理時間を確認してから実施してください。
表は横にスクロールできます
| Run | 対象 | Sourceの最新値 | Rows / Bytesまたはwarning | 対象期間 | Reportで確認した値 | 結果 |
|---|---|---|---|---|---|---|
| 前回正常 | item / entity | watermark | 通常値 | policy範囲 | 期待値 | baseline |
| 今回問題 | item / entity | watermark | 実測値 | policy範囲 | 古い値 | 原因候補 |
| 再テスト | item / entity | watermark | 実測値 | 変更した範囲のみ | 実測値 | 解消 / 継続 |
dataflowでRows/Bytesが0でも、sourceに新規データがないならrefresh自体は正常な可能性があります。反対に処理量が増えたことだけで、レポートに必要な行が正しく表示されたとは言えません。最終的には、同じkeyと期間でsource、model、reportの値を比べます。
まとめ：Completedの後に処理量と表示層を確かめる
更新のstatusがCompletedでも、データが新しくなったかは別に確認します。最初にdataflowかsemantic modelか、古く見えるのがentity・model・report・dashboard tileのどこかを決めてください。dataflowならrefresh CSVのRows processed / Bytes processedとsource・incremental range、semantic modelならwarnings・refresh段階を見ます。そのうえでmodelとvisualのfilterや計算を確認します。
次は、問題のrun時刻とsourceの更新時刻を揃え、処理量またはwarningの証拠を1つ取ることです。そこに差があれば、refresh policy、上流依存、schema、reportのどの層へ調査を進めるか選べます。履歴に指標がない、API/XMLA実行で追跡方法が違う、容量や履歴権限が不明な場合は、workspace管理者へrun ID・対象item・source watermarkを渡して確認してください。
Sources
-
Microsoft Learn, Troubleshoot refresh scenarios（新しいタブで開く） — checked 2026-10-15.
-
Microsoft Learn, Data refresh in Power BI（新しいタブで開く） — checked 2026-10-15.
-
Microsoft Learn, Understand and optimize dataflows refresh（新しいタブで開く） — checked 2026-10-15.
-
Microsoft Learn, Get Refresh History REST API（新しいタブで開く） — checked 2026-10-15.
Editorial Notes: This article separates dataflow refresh CSV metrics from semantic model history/warnings. No Power BI tenant, workspace, source, capacity, or report was inspected. Rows processed, Bytes processed, history availability, and policy behavior depend on the specific item/type/capacity and must be read from its own run data.