フラットな Excel や CSV を Dataverse の関連テーブルに載せるとき、Azure Data Factory（ADF）のような重い基盤は必要か。答えは条件付きで「否」だ。単一の Dataflows（Power Platform の ETL ツール。Power Query で変換ロジックを定義し、Dataverse へデータを投入する）で設計上の安全性を担保できる——ただし「自己正規化」という設計原則と、Dataflows の fail-open 挙動（エラーが出ても処理を続け、失敗行だけを落とす動作）を正しく理解している場合に限る。
環境前提として確認しておく：Dataflows 単独では削除の自動検知はできない。デルタ同期・変更検知の設計は別途必要だ。
なぜ自己正規化は孤児を消せるのか
参照整合性エラー——いわゆる「孤児」——が生まれる原因は単純だ。子テーブルのレコードが指す親が、まだ存在していない。これだけだ。
自己正規化の設計は、この問題を構造で封じる。手順は 3 ステップだ。
- 移行対象のフラット表から、親テーブル相当の列を重複排除して抽出する
- 抽出した親マスタを Dataflows で先に投入する
- 同じフラット表から子レコードを投入する
この順序を守る限り、子が指す親は必ず存在する。なぜなら、親マスタは同じフラット表の重複排除から作っているからだ。フラット表に存在しない親を子が参照する、という事態は原理的に起きない。これは論理の帰結であり、ツール依存の話ではない。
欠損が生じる場合は「順序のズレ」だけが原因になる。親の投入が終わる前に子を流してしまった場合だ。対処は親→子の順で再実行するだけで収束する。「本物の孤児」——設計上解決できない孤児——は、この構成では原理的に生まれない。
判断が分かれる境界線
とはいえ、Dataflows 1 本で完結できる条件には限界がある。以下で対照する。
| 観点 | Dataflows で十分 | ADF 等が必要になる |
|---|---|---|
| 規模感 | 数万〜10万件（後述の速度実測を参照） | 数百万件の継続的デルタ同期 |
| データ鮮度要件 | 初回移行・週次バッチ | リアルタイム / 1 分以内 |
| 変換の複雑さ | Power Query M で表現できる範囲 | 複数システム横断の複雑なジョイン・集計 |
| 監査・ガバナンス | 手動モニタリングで許容できる | SLA・自動アラート・再実行の完全自動化が必須 |
| 保守体制 | 業務担当者または情シス 1 名が触れる | 専任インフラチームが SLA を持って管理 |
上記の左列すべてに当てはまる初回移行であれば、ADF を持ち出す必要はない。
速度の正体——固定費を畳む
速度に関して、よく聞く「Dataflows は遅い」という印象は比較対象次第だ。
単一 HTTP 呼び出し（Create API を 1 件ずつ直列で叩く）の場合、往復レイテンシが毎回固定費としてかかる。Service Protection API Limits（6,000 リクエスト/5 分の上限）と HTTP 往復コストを踏まえると、単一スレッド直列呼び出しでは約 2〜3 行/秒が物理的な天井に近い（コミュニティ実測・複数ソースで観測されている値）。
Dataflows の Merge 操作（Upsert：追加と更新を一括で行う操作）はバッチ化することで固定費を畳み込む。コミュニティ実測（Dynamics Chronicles「Power Platform Dataflow Tutorial Deep Dive」）では、10 万件の Dataflows → Dataverse 投入が約 52〜58 分、換算で20〜32 行/秒程度に収まっている。改善倍率は環境によって幅があるが、約 9〜14 倍が複数ソースで収束している数値だ。
「88行/秒・40倍」という数値が一部で言及されるが、複数の独立した実測値（Dynamics Chronicles・Microsoft Q&A コミュニティ）では確認できていない。速度を計画に組み込む際は、20〜32 行/秒・約 9〜14 倍を参考値として使い、本番投入前に数千件のパイロット計測を行うことを前提にする。
Dataflows は fail-open——落ちた行の監視が必須
見落としやすい設計上の特性がここにある。
Dataflows はエラーが出た行を黙って落として処理を続ける（fail-open 動作）。 成功した行だけが Dataverse に入り、失敗した行は記録されるが処理は止まらない。これは一見便利だが、監視なしでは欠損に気づかないまま移行が完了したように見える。
公式ドキュメントに「fail-open」と明示した記述はないが、2 点の公式資料から設計上の示唆が得られる。
- msdyn_entityrefreshhistory スキーマ（Microsoft Dataverse entity reference）：単一のリフレッシュレコードに
InsertCount（成功投入件数）とErrorCount（エラー件数）が並存するフィールド設計。1 回のリフレッシュ内で成功行とエラー行が共存できる構造になっている。 - Monitor your dataflow refreshes（Microsoft Learn）：モニタリングダッシュボードが inserted / upserted / failed を同一リフレッシュの独立指標として公式提示している（“the count of rows that were inserted, upserted, or failed”）。
なお、Power BI 分析系 Dataflows（Azure Data Lake へ書き込むもの）は fail-closed であり、エンティティ障害で全体がロールバックする（公式）。同じ「Dataflows」という名前でも、Power Platform 標準 Dataflows（Dataverse 向け）と Power BI 分析系 Dataflows では挙動が異なる点に注意が必要だ。
設計時に詰める確認項目
投入前に以下を確認しておく。抜けがあると後の保守で引っかかる。
| チェック | 確認内容 |
|---|---|
| 自己正規化の順序 | 親テーブル → 子テーブルの Dataflows 実行順が明示的に設計されているか |
| 代替キー（Alternate Key） | Merge の基準キーは代替キーで設定しているか（内部 GUID での Upsert は衝突が起きやすい） |
| fail-open 監視 | msdyn_entityrefreshhistory の ErrorCount を定期確認する手順があるか |
| 削除・変更検知 | ソース側のレコード削除をどう扱うか明確か（Dataflows Merge はデフォルトで削除を同期しない） |
| パイロット計測 | 本番投入前に数千〜数万件で実測したか（速度は環境依存が大きい） |
個人テナントで動作を確認しておく
上記の設計パターンを手を動かして確認したいなら、Microsoft 365 Developer Program（無料）で個人 PC 側に検証環境を用意するのが最短だ。Dataflows の Merge 動作・fail-open 挙動・ErrorCount の確認方法を、本番データや顧客環境を使わずに事前に体験できる。
→ 関連記事：Dataverse × Dataflows 投入 4 難所——0落ち・型崩れ・Upsert 代替キーの回避
まとめ
自己正規化の設計を取る限り、フラット表から関連テーブルへの初回移行は Dataflows 1 本で構造的に安全に完結する——ただし fail-open 監視設計を省略せず、速度は 20〜32 行/秒を前提にパイロット計測を入れた場合に限る。
次の一歩：まず数千件のパイロット移行を 1 本の Dataflows で設計し、リフレッシュ後に msdyn_entityrefreshhistory の ErrorCount を確認する。この 2 ステップが本番移行前の最低限の検証になる。ErrorCount がゼロであれば、同じ設計を本番規模に展開できる。
関連記事