目次
まず「同じ行が二重に入った場所」を特定する
Power BIの増分更新後に重複が見つかったら、最初に更新を何度もやり直すのではなく、同じ業務キーの行がどこで増えたかを調べます。確認するのは、①元データに同じキーがある、②Power QueryのRangeStart / RangeEnd条件が隣接期間で重なる、③更新列の変更で既存行が別期間へ移った、④モデルやレポートの結合・表示で重なって見える、の4つです。RangeStartとRangeEndだけが原因とは限りません。
対象テーブル、日付列、重複とみなす業務キー、重複が初めて見えた更新日時を決め、同じフィルター条件を使ってsourceとsemantic modelの件数を比べます。たとえば注文明細なら、注文番号だけでは複数明細を区別できないため、注文番号＋明細番号など実際に一意性を持つキーを使います。顧客名や日付だけで重複を判断すると、正当な複数行を誤って削除する恐れがあります。
RangeStartとRangeEndの境界が重なっていないか
増分更新は、日付または日時列をRangeStart / RangeEndで区切り、対象期間ごとのpartitionに分けて処理します。Microsoft Learnは、2つのパラメーターをDate/Time型にし、大小の範囲を表すフィルターを設定するよう説明しています。隣接partitionが同じ境界時刻の行を両方含まないよう、片方だけをinclusive（以上・以下）、もう片方をexclusive（より大きい・より小さい）にします。両方の条件で等号を使うと境界値が二つの範囲に入って重複する可能性がある、と公式手順にも明記されています。
よくある安全な形は「RangeStart以上、RangeEnd未満」です。Power Query Mなら、日付列をOrderDateとしたときの考え方は次のとおりです。
Table.SelectRows(
Source,
each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd
)
これは一般的な例であり、読者の実テーブルにその列名や型があるとは限りません。既存クエリをそのまま置き換えるのではなく、対象列の型・タイムゾーン・ソース側の日時精度を確認してから条件を当てはめます。日付だけの列と時刻を含むDateTime列を混ぜると、日付境界の想定がずれることがあります。
まず小さな検証期間を選び、境界時刻そのもの、境界直前、境界直後の3ケースを用意します。たとえばRangeStartを2026-03-01 00:00、RangeEndを2026-04-01 00:00とする検証なら、3月1日0時ちょうどの行は期間に含まれ、4月1日0時ちょうどの行は次の期間に入ることを確認します。隣接期間の集計を足したとき、同じ業務キーが二つの期間に現れないかを照合します。日付値を勝手に月末23:59:59へ丸めるとミリ秒精度などを落とす可能性があるため、境界を半開区間として扱う方が検証しやすくなります。
1. データ型・名前・日付列を確認する
Power BIの増分更新では、パラメーター名RangeStartとRangeEndは大文字・小文字も含めた予約名です。どちらもDate/Time型で、実際のフィルターに参照されているか確認してください。Desktopで表示されている初期値は、Service上の各partitionの境界そのものではありません。公開後のServiceでは、Incremental Refresh policyが設定した保存期間・更新期間に応じてパラメーター値がpartitionごとに適用されます。
次に、フィルター対象列とパラメーターの型・タイムゾーン・精度を比べます。日付列が文字列になっていたり、ローカル時刻とUTCを変換する処理が境界フィルターより前後で異なったりすると、期待した期間の行が欠けたり重なって見えます。整数形式のyyyymmddを使う場合も、RangeStart / RangeEnd自体はDate/Timeであり、対応する変換方法が必要です。公式資料の例では、Date/Timeパラメーターを整数キーへ変換してフィルターします。
Power Query Editorで対象クエリを開き、Applied Stepsを上からたどって、日付列がいつ作られ、型変換がいつ行われ、RangeStart / RangeEndのフィルターがどこでかかるかを記録します。同じ列に別名のフィルターや後段の期間条件がないかも確認します。後続stepで別の条件を加えること自体は可能ですが、どの期間の行を落とすのか、モデル側のpartition設計と一緒に説明できる状態にしてから変更します。
2. Query foldingを検証する
Query foldingは、Power Queryの処理を可能な範囲でデータソース側のクエリへ押し戻す仕組みです。増分更新では、RangeStart / RangeEndによる期間フィルターが各partition向けにデータソースへ渡ることが重要です。折りたたまれなければ必ず重複するわけではありませんが、全期間を取得してからローカルで絞るなど、遅延・リソース不足・想定外の更新を招くことがあります。
Power Queryでフィルターstepを選び、可能なら「ネイティブクエリの表示」やクエリ診断で日付条件がsource queryへ含まれているかを確認します。表示できない場合、それだけでfolding失敗と断定しません。データソース側のトレース、Power Query Diagnostics、短い期間での行数比較など、使える検証方法を選びます。Microsoft Learnも、sourceがフィルターを実行できることを確認し、判断できない場合はDiagnosticsやsource側のtraceを使うよう案内しています。
小さなテスト期間でPower Queryの結果件数と、同じ条件をデータベース等へ直接適用した件数を比較します。両者が一致しない場合は、型変換、UTC変換、フィルターの順序、foldingの有無を一つずつ確認します。全履歴を再取得する前に、テストがどの処理を実際に走らせたかを確認してください。
3. 更新された過去行とpartitionの設定を分ける
RangeStart / RangeEndの境界が正しくても、古い期間の行が更新されたときに見え方が変わることがあります。現在の増分更新ポリシーでどの期間を再処理するのか、Detect data changes用の列を使っているか、更新されたレコードが過去partitionに残る設計なのかを確認します。Microsoft Learnは、増分更新で変更検出を使う場合、削除行を検出する仕様ではなく、sourceに残ったまま削除印が付くsoft deleteのみを検出すると説明しています。実データの更新・削除仕様とポリシーを照合してください。
確認対象は、保存する履歴期間、増分更新する直近期間、変更検出列、source側の遅延到着データ、partition境界です。たとえば過去日付の注文行が後日訂正されても、その日付partitionを再処理しない設定なら、訂正が反映されないことがあります。逆に、更新日時をpartition列として使うか業務発生日を使うかで、行の移動や重複の見え方が変わります。どちらが適切かは業務要件で決まり、更新日時を一律に推奨できません。
Service側のpartition状態を確認できる権限や容量がない場合は、そこを未確認として切り分けます。Power BI Desktopのpreviewだけで、Service内のpartitionがどのように作成・更新されたかを確定したとは扱いません。Serviceで発生した重複なら、refresh history、対象期間、Rows processed、partition情報など、利用可能な管理情報を集めてから原因を絞ります。
4. 元データ・モデル・表示の重複を検査する
同じ業務キーがsourceに既に二行あるなら、partition境界を直しても重複は解消しません。まずsourceの該当期間で、期待する一意キーごとの件数が1を超えるか集計します。次にPower Queryの読み込み結果、semantic modelのテーブル、ビジュアルや関連テーブルのjoin後を順に比べます。
Power Queryのmergeで一対多または多対多になっている場合、結合キーの重複によって行数が増えることがあります。モデルで複数のテーブルを結合して表示しているなら、テーブル単体の行数とビジュアルの集計を分けて見ます。単純な「重複削除」は、どちらの行を残すべきか決めないまま値を失うので、原因確認の先に実行しません。
調査表には、対象キー、期間、source件数、Power Query件数、semantic model件数、最後に確認したrefresh、使用したフィルターを記録します。例：同一キーがsource=1、Power Query=1、モデル=2なら、sourceからモデルに取り込まれるまでに増えた箇所をpartitionやモデル処理に絞れます。source=2なら、先にsourceの品質・業務上の一意性を確認します。
5. 原因を絞るための実行手順
-
重複が出たテーブル、業務キー、日付列、初回発生refreshを固定する。
-
sourceで対象キーを検索し、同じ期間の元行を確認する。
-
Power QueryでRangeStart / RangeEndの名前・型・参照列・フィルター式を記録する。
-
境界値、直前値、直後値のテスト行を用意し、隣接期間の重なりを調べる。
-
filter stepの位置とquery foldingをDiagnosticsまたはsource traceで確認する。
-
増分更新policyの保存期間・更新期間・変更検出列・遅延到着データの扱いを確認する。
-
source→Power Query→model→visualの件数を同じ業務キーと期間で比較する。
-
原因が境界式なら、片側のみ等号を使う式へ修正し、小さな期間で回帰確認する。
-
原因がsourceやmergeなら、source/relationship側の一意性と意図された多重度を確認してから直す。
-
修正後に境界日、遅延到着行、訂正行、通常期間の代表ケースを再確認する。
この手順はPower BIの実モデルに対して実行した検証結果ではなく、Microsoft公式資料から組み立てた診断方法です。対象dataset、source、relationship、refresh historyは確認していません。
6. 検査用の境界ケースを作る
単体で境界を確認するなら、検証テーブルまたは一時queryに次の三件を用意します。
表は横にスクロールできます
| Key | Timestamp | 期待 |
|---|---|---|
| A | RangeStartよりわずかに前 | 現在のpartitionに入らない |
| B | RangeStartと一致 | 現在のpartitionに一度だけ入る |
| C | RangeEndと一致 | 次partitionに一度だけ入る |
このテストで見るのは各partitionの件数だけでなく、partitionをまとめたときのKeyの出現回数です。各境界の一致時刻にどちらのpartitionが含むかを明示し、片方のpartitionに1回、隣接側に0回、全体で1回という期待を作ります。
元データに同一Keyの複数明細が正当に存在する場合、Key単体では重複テストになりません。実際の一意キーを定義し、正常な複数行と誤った二重取込を区別します。また、datetime精度やUTC変換がある場合には「わずかに前」をsourceが表せる最小精度に合わせます。
7. 修正前後の安全確認
増分更新policyやPower Query式を変更する前に、現行式、policy、sourceの件数を保存します。変更は一つずつ行い、テスト用期間で結果を比較します。境界式の直しによってpartition間の穴ができていないことを確認します。ソースがfoldingできるときは、source側へ日付条件が伝わったことも確認します。
既に重複が本番モデルにある場合、フィルター式を修正しただけで過去partitionが自動的に正しく作り直されるとは限りません。再処理や履歴再読み込みが必要かはポリシー・容量・モデル構成次第です。Service側の更新方法に不確実性があるなら、変更を一時停止し、モデル所有者と影響範囲を確認します。行の削除や全期間refreshを安易に実行しないでください。
検証記録には変更前後の式、対象期間、Rows processed、sourceとmodelの件数差、境界テスト結果、refreshの結果を残します。テストが通らない場合は変更を元に戻す前に、他の変更が混ざっていないかと実行した期間を確認します。削除を伴う回復は、別のバックアップ・復元手順と責任者承認を用意してから行います。
8. 結果から次の一手を選ぶ
表は横にスクロールできます
| 観察結果 | 優先確認 |
|---|---|
| 同じ行がsourceにも複数ある | 業務キーの定義、sourceの重複生成、重複が許容される仕様 |
| 境界時刻の行が隣接partition双方にある | 2条件の等号、タイムゾーン、日時精度 |
| sourceとPower Queryの件数が異なる | フィルターstep、型変換、query folding、source query |
| Power Queryは正しいがmodelが増える | partition processing、refresh policy、Serviceのrefresh履歴 |
| テーブルは正しいがvisualだけ多く見える | relationship、merge、複数テーブルの粒度・集計 |
| 過去行の訂正が反映されない | 更新期間、Detect data changes、過去partition再処理の要否 |
この表で原因候補を分類した後、該当する担当レイヤーへ証拠と変更前状態を渡します。原因が確定する前に「incremental refreshが悪い」と断定せず、誰が何を調べれば次の判断ができるかを明確にします。
公式情報と確認範囲
Microsoft Learnを2026-10-15に確認しました。Configure incremental refreshはRangeStart/RangeEndのDate/Time型、予約名、filter boundaryの等号を両側で使うと隣接partition間で重複し得ること、PolicyがServiceで適用されることを説明します。Overviewはquery folding要件とDate/Time parameterをsource filterへ接続する条件を示します。Troubleshootページは型不一致、folding診断、source traceの確認方法を説明します。ここで紹介した手順は一般診断ガイドで、特定のPower BI modelまたはsourceでの実測結果ではありません。
・Incremental refresh configuration：https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-configure（新しいタブで開く）
・Incremental refresh overview：https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview（新しいタブで開く）
・Incremental refresh troubleshooting：https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-troubleshoot（新しいタブで開く）