AIものさし

Power BIの増分更新で過去データの修正が反映されないとき、対象期間と再処理方法を確認する

Power BI増分更新で過去の修正が反映されないとき、更新対象期間と履歴partitionを確認し、必要な期間を再処理する方法を整理します。

AIものさし編集部

Power BIの増分更新を実行しても過去レコードの修正や削除がレポートへ反映されない場合は、refreshの成功・失敗だけで判断せず、対象行の日付が現在のrefresh期間に含まれるかを確認します。増分更新はポリシーに沿って最近の期間を処理し、そこから外れたデータは履歴partitionになるため、通常のrefreshだけでは再処理されないことがあります。

この記事はPower BI Serviceに公開したsemantic modelのImport型増分更新を主に扱います。リアルタイムDirectQuery、別のBI製品、Direct Lakeなどは同じpartitionやrefresh動作とは限りません。まず対象model・table・データ更新方式を特定してから読み進めてください。

目次

最初に確認する三つの日時

調査で混同しやすいのは、業務データの日付、sourceで値が変更された日時、Power BIのpartition期間です。対象行が「いつ発生したデータか」と「いつ修正されたか」は別の情報です。例えば取引日が半年前の行を昨日訂正した場合、incremental policyのrefresh期間が直近30日なら、取引日をpartition filterに使う構成では昨日の通常refresh範囲に入らない可能性があります。30日は説明用の例で、既定値や推奨値ではありません。

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

記録する項目例用途
business date注文日、計上日どのpartitionに行が属するか
source modified time元データを訂正した日時変更をどのrefreshで拾える想定か
model refresh timeServiceのrefresh開始・終了どの時点の結果を見ているか
policy refresh periodmodelに設定された期間通常更新で再取得される範囲
store/archive periodmodelに保持する期間古いデータが保持対象か確認

実際の値は利用者のmodel設定から取得します。sourceの更新日を基準にしたchange detectionが設定されているか、partition境界に使う日付列が業務上の更新日と一致しているかも確認してください。

成功したrefreshでも過去の変更が反映されない理由

Microsoftのincremental refreshは、RangeStartとRangeEndで期間を分け、各refreshでrefresh period内のデータを更新します。期間を外れたpartitionはhistorical periodに移り、その後の通常更新では再処理されません。したがって、Serviceがrefresh成功を返していても、それはその回に対象となった範囲が処理できたという意味で、モデル内の全履歴がsourceと一致する証明ではありません。

まずPower BI Serviceのrefresh historyと、source側の対象行を並べて確認します。

  1. sourceで対象レコードを一意に特定するキーを決める。

  2. 現行値、訂正値、削除状態、business date、source modified timeを記録する。

  3. semantic modelのtableとpartition filterに使う日付列を確認する。

  4. incremental refresh policyのrefresh periodと保持期間をmodel ownerに確認する。

  5. 最後のrefreshが対象行の日付を含むpartitionを処理したか確認する。

  6. sourceでの修正後にrefreshしたか、model側の結果をいつ確認したか記録する。

Refresh historyは実行の証拠ですが、どの行が含まれたかの証拠ではありません。sourceとmodelの件数・金額など対象業務に合った値を照合します。対象partitionが分からないまま「refreshをもう一度実行すれば直る」と決めつけないでください。

増分更新policyの期間を読む

Desktopで設定したincremental policyをServiceへpublishすると、初回refreshでpolicyに基づくpartitionが作られます。以降のrefreshでは、refresh period内の日時範囲が処理されます。policyのrefresh periodとstore/archive periodは異なる役割です。前者は通常更新の対象範囲、後者はmodelに残す履歴の範囲です。保持期間に入っていても通常refresh対象とは限りません。

概念上は、対象行の日付がrefresh period内なら通常の増分refreshで再取得される候補です。refresh period外で保持期間内ならhistorical partitionになっており、通常refreshだけでは更新されない可能性があります。保持期間外ならpolicyに従ってmodelから削除済みの可能性もあります。実際の境界はpolicy、RangeStart/RangeEndの実装、partitionの粒度、source connectorやquery foldingなどで変わります。日付境界のタイムゾーンやinclusive/exclusive条件も確認し、境界当日のレコードを手計算だけで判定しないでください。

Detect data changesを使っている場合

一部の増分更新設定には、変更検出用の列を使う方式があります。対象期間の中でその列の最大値を調べ、変化があるpartitionを再更新する設計です。これは全履歴を毎回比較する仕組みではありません。変更検出用の値が更新されない、対象の更新期間から外れている、deleteが検出方法の対象外などの条件があれば、期待どおりに反映されない場合があります。

確認する項目は、Detect data changesが有効か、どの日時列を使うか、sourceの訂正時にその列も更新されるか、refresh期間外のhistorical partitionを対象とする設計か、行削除が検出できる構成か、です。物理削除かsoft-deleteかも区別します。modelの構成を見ずに「変更検出があるから古い修正も必ず反映する」とは言えません。

Historical partitionを選択的に再処理する

MicrosoftはPremium機能のXMLA endpointを用いる高度なpartition・refreshシナリオを案内しています。対応するcapacity・設定・権限がある環境では、特定partitionを処理する方法を検討できます。ただし、全てのPro modelや全ユーザーが実行できるわけではありません。modelのcapacity、XMLA endpointの設定、workspace権限、使用ツール、partition名と範囲を確認してから、model ownerまたはPower BI管理者へ依頼してください。

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

確認決める内容
対象partitionどの日付・どのtableを処理するか。全履歴を対象にしない
sourceの状態訂正・削除が正しい値として確定しているか
capacityと権限XMLA等の高度な処理が利用可能か
backup / rollback失敗時の復旧、再処理前の状態記録
負荷・時間対象範囲がcapacityとrefresh windowに与える影響
検証key、row count、合計値、重複、欠落をどう照合するか

partitionの手動変更や再処理は本番modelに影響し得ます。必要な権限を持たない利用者が画面操作やスクリプトで迂回しないでください。capacity条件が合わない場合は、policyのrefresh rangeを変更した時の再処理・保持期間・model sizeへの影響をownerに評価してもらいます。全履歴再構築は処理量と保持データに影響するため、短い局所修正と同じ扱いにしません。

設定変更を検討する条件

同じ種類の過去訂正が繰り返される場合は、refresh periodを広げる、変更検出用列を整える、別の訂正テーブルをmodelへ取り込むなどを検討できます。ただし範囲を広げるとrefresh時間・source負荷・capacity消費が増え、履歴の保持期間やpartition構成にも影響します。modelの利用頻度と訂正頻度、sourceで変更を追跡できる期間を確認してから判断してください。

次の条件があれば、refresh periodの拡張だけを先に試すのではなくmodel ownerへ相談します。

  • 過去行を頻繁に修正・削除する。

  • 変更日と業務日が大きく離れる。

  • sourceに信頼できる更新日時がない。

  • 複数tableで異なる日付列を使っている。

  • 変更対象期間がstore/archive periodを超えている。

  • 大きなmodelでfull refreshや履歴再処理の負荷が読めない。

  • policy変更が行数や金額の再集計に与える影響を把握できない。

訂正前後を照合する手順

  1. 対象レコードのbusiness keyを使い、source側の訂正後データを保存する。

  2. 更新した日時列がpartition filterやDetect data changesに使われているか確認する。

  3. 対象日付がrefresh period、store periodのどこに属するかをmodel ownerと確定する。

  4. 通常refreshが適切なら、実行前のrow count・合計値・対象key一覧を記録する。

  5. historical partitionなら、XMLA等の利用条件・権限・安全な戻し方を確認し、対象partitionだけの処理を依頼する。

  6. 実行結果に成功表示が出ても完了にせず、対象key、件数、金額・数量などをsourceとmodelで比較する。

  7. 削除対象は、表示filterで隠れたのかmodelから除かれたのか確認する。

  8. 検証結果、実行者、時刻、対象範囲を記録する。

比較では丸め・更新遅延・sourceの重複・model側の集計粒度を考慮します。対象行が一件でも集計値だけでは他の欠落と相殺される場合があります。可能なら個別keyの存在確認と総計の両方を確認してください。

症状別の切り分け

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

状況可能性次に見るもの
対象日がrefresh period内、成功後も古いquery filter、source読取結果、DateTime境界、query foldingRefresh history、RangeStart/RangeEnd、source query
対象日がrefresh period外だが保持期間内historical partitionが通常対象外partition範囲、XMLA等の適用条件と権限
sourceは更新済みだが検出されないchange detectionの列・範囲・値が不適合設定列、source modified column、refresh period
削除が反映されないsoft-delete/physical deleteとpolicyの違いsource削除方式、partition、変更検出仕様
対象partitionが分からないmodel metadataやfilter構成が不明model owner、管理者、管理ツールでの確認
保持期間を外れているpolicyでpartitionが除去された可能性Store/archive期間、sourceからの再構築方法

可能性は診断確定ではありません。環境構成を確認してから判断してください。

管理者へ渡す情報

自分でmodel設定やpartitionを変更できない場合は、workspace、semantic model、table、対象レコードのbusiness key、business dateとsource modified time、変更・削除した内容と時刻、incremental policyの期間とdate column、Refresh historyのmessage、期待する値と現在のmodel値、XMLA endpointの利用可否を分かる範囲でまとめて依頼します。機密情報を含むkeyは社内の安全な手順で共有してください。

依頼内容は「対象partitionと範囲の確認」「再処理の実行可否」「実行前後の件数・値の検証」と具体化します。調査担当は権限を超えて操作せず、変更の承認者と実行者を記録します。

結論

過去データの訂正が反映されないときは、refreshを繰り返す前に、対象行のbusiness dateとsource modified timeを分け、増分更新policyのrefresh period・store periodと照合します。対象が通常のrefresh範囲外なら、success表示だけで過去partitionまで更新されたとは判断できません。環境が対応する場合はmodel ownerが対象partitionの再処理を判断し、権限・capacity・戻し方を確認してから実行します。最後に対象keyと件数・数値をsourceとmodelで突合してください。

公式情報（2026-10-15確認）