SQL からエクスポートした Excel ファイルを Dataflows（Power Query ベースのデータフロー）経由で Dataverse（Power Platform のクラウドデータベース）に投入するとき、必ずといっていいほど4つの同じ壁にぶつかる。電話番号の0落ち・Lookup列のマッピングエラー・Choice型の内部値不一致・Upsert用の代替キー設定だ。

この4つはどれも「構造を知っていれば避けられる」種類のつまずきだ。本記事は、各難所の「なぜそうなるか」と「どう設定するか」を1本に収めた逆引きバイブルとして書いた。次の投入作業の前にブックマークしておくと、そのたびに調べ直す時間が不要になる。

なぜ「SQL → Excel → Dataflows」が有効なルートなのか

Dataverse にデータを投入する方法はいくつかある。SQL から直接連携するパイプライン、Power Automate による行単位の書き込み、そして Dataflows 経由のルート。

Dataflows が実務でよく選ばれる理由は3つだ。

  1. 可視性：Power Query エディターで変換内容を列ごとに確認しながら作業できる。何が起きているかが目に見える。
  2. ノーコード操作：M言語の知識がなくても、GUIで型変換・列の追加・フィルタリングが完結する。
  3. クラウド完結型：OneDrive for Business または SharePoint Online にファイルを置けば、オンプレミスデータゲートウェイが不要になる。

行数の上限については、公式ドキュメント（Microsoft Learn「Power Query Online Usage Limits」）で「制限なし」と明記されている。大規模な移行案件でもルートを変える必要はない。ただし1回の実行時間上限は4時間（Power Apps / Power Platform ライセンス）のため、数十万行を超えるような場合はバッチ分割を検討する。

Excel前処理——0落ちと型崩れを事前に防ぐ

Dataflows に読み込む前の Excel ファイルで起きる型崩れを防ぐ。ここを飛ばすと、投入後に意図しないデータが静かに混入する。

電話番号・コードの「0落ち」対策

Excel はデフォルトで数値として認識できる列を自動変換する。0901234567 は 901234567 になり、0001 は 1 になる。

対策は、列のセルを文字列フォーマットに設定してからデータを入力または貼り付けることだ。

手順：

  1. 対象列を選択 → ホームタブ → 「数値」グループのドロップダウン → 「文字列」に変更
  2. この状態でデータを貼り付ける（既に数値化されている場合は再入力が必要）

Dataflows 側で Power Query の「データ型」を「テキスト」に変更しても、Excel ファイル側で既に0が落ちていれば後の祭りだ。前処理の段階で封じる。

日付のシリアル値化対策

Excel は日付列を内部的に数値（シリアル値）として持つ。2026/05/28 が 46199 のような整数列として Dataflows に渡されることがある。

対策：日付列を文字列フォーマット（yyyy/mm/dd 等）で統一するか、Dataflows の Power Query 側で「日付」型に明示的に変換するステップを追加する。どちらでも構わないが、前者の方がトラブル発生時の原因特定が速い。

テーブル化（Ctrl + T）を必ずやる理由

Dataflows から Excel ファイルを読み込む際、テーブル化されていない範囲はシート全体として認識され、列ヘッダーが正しく取得できないことがある。

Ctrl + T でテーブル化すると、Excel が「ここからここまでがデータ」と認識するため、Dataflows 側でテーブル名を指定して正確に読み込める。

ファイル配置——OneDrive for Business か SharePoint Online に置く

ローカル PC に保存した Excel ファイルを Dataflows のデータソースとして指定することは技術的には可能だが、オンプレミスデータゲートウェイのインストールと設定が必要になる。運用コストが無視できない。

推奨構成：OneDrive for Business または SharePoint Online にファイルを配置する。

この2つは Dataflows のコネクターで直接接続でき、ゲートウェイ不要でクラウド完結する。ファイルを更新するたびに、次の Dataflows 実行時に最新データが取り込まれる。

SharePoint Online はチームで共有するファイルに向いており、OneDrive for Business は個人作業や検証用途に向いている。本番運用では SharePoint Online を選ぶケースが多い。

難所① Lookup列のマッピング（プライマリ名前列 vs GUID）

Lookup列（参照型列）とは、別のテーブルの行を「参照」するための列だ。例えば「取引先」テーブルの特定の行を「商談」テーブルの1行に紐付けるような関係を持つ列がこれにあたる。

Dataflows で Lookup列にデータを投入するとき、問題は「どの値で参照先の行を特定するか」だ。

キー選択の判断軸

キーの種類使うタイミング注意点
プライマリ名前列（表示名）参照先のレコード名が一意に決まっている場合表示名が重複していると誤マッピングが発生する
GUID（一意識別子）確実な一意性が必要な場合ソースデータに GUID が含まれている必要がある
代替キー（Alternate Key）業務コード等、独自の一意キーがある場合別途 Dataverse 側で代替キーの設定が必要

実務では「プライマリ名前列を使おうとしたが、同名のレコードが複数あってエラー」というパターンが多い。ソースデータの一意性を確認してから選ぶ。

代替キーとは、GUID以外の列をレコードの一意識別子として定義する機能だ。例えば「社員コード」や「製品番号」のような業務上の一意コードを代替キーとして登録しておくと、Dataflows のマッピング画面でそのキーを使って参照先行を特定できる（参考：Microsoft Learn「Define alternate keys using Power Apps」https://learn.microsoft.com/en-us/power-apps/maker/data-platform/define-alternate-keys-portal）。

代替キーの設定と制約

設定手順（Power Apps ポータル）：

  1. Power Apps ポータル → 対象テーブルの編集画面 → 「Keys」タブを選択
  2. 「New key」をクリック → 表示名・スキーマ名を入力 → 使用する列を選択
  3. 「Save」をクリック → バックグラウンドでデータベースのインデックス作成ジョブが起動

保存後、ステータスが「Pending」になる。バックグラウンドのインデックス作成が完了すると「Active」に変わる。この移行にかかる時間はデータ量に依存する（公式ドキュメントに具体的な数値記載はなく、数秒で終わる場合もあれば数分以上かかることもある）。Active になる前に Dataflows 側でそのキーを使おうとするとエラーになるため、ステータスを確認してから次のステップへ進む。

制約（2026年時点の公式値）：

制約項目公式値出典
1テーブルあたりの代替キー数上限最大10個Power Platform Release Plan 2021 Wave 1
1キーあたりの列数上限最大16列Microsoft Learn「Work with alternate keys」
1キーあたりのサイズ上限900バイト以内Microsoft Learn「Work with alternate keys」
NULL値の扱いNULL値は一意性を保証しないMicrosoft Learn「Define alternate keys to reference rows」
使用できない列列セキュリティ（Column security）が有効な列—
特殊文字の注意/ < > * % & : \ ? + を含む値の列はGET/PATCH/UPSERT操作が動作しない—

（出典：Microsoft Learn「Define alternate keys to reference rows」https://learn.microsoft.com/en-us/power-apps/maker/data-platform/define-alternate-keys-reference-records、Microsoft Learn「Work with alternate keys」https://learn.microsoft.com/en-us/power-apps/developer/data-platform/define-alternate-keys-entity）

難所② Choice型の内部値マッピング

Choice型（選択肢型）とは、「進行中」「完了」「保留」のような固定選択肢を持つ列だ。一見シンプルだが、Dataverse の内部では整数（Integer）として格納されている（参考：Microsoft Learn「Choices columns」https://learn.microsoft.com/en-us/power-apps/developer/data-platform/multi-select-picklist）。

「進行中」というテキストラベルは表示用のものであり、実際の格納値は 100000001 のような整数だ（整数値はソリューションパブリッシャーのプレフィックスによって変わる）。

Power BI から Dataverse に接続すると Choice列が2列に分かれて見える——整数値の列とテキストラベルの列——というのは、この内部構造が露出している状態だ（参考：Microsoft Learn「Access Dataverse choices with Power BI」https://learn.microsoft.com/en-us/power-apps/maker/data-platform/azure-synapse-link-choices-powerbi）。

マッピングのアプローチ

ソースデータが既に整数値の場合（方法A）：

Dataflows の「Field Mapping」画面でソース列を Choice列に直接マップできる。変換ステップ不要。

ソースデータがテキストラベルの場合（方法B）：

Power Query で「条件列の追加（Add Conditional Column）」を使い、テキストから整数への変換ステップを追加する。

以下は実務での確認手順（公式サンプルは未公開）：

変換ロジックのイメージ：

if [ステータス] = "進行中" then 100000001
else if [ステータス] = "完了" then 100000002
else if [ステータス] = "保留" then 100000003
else null

Power Query GUI での操作手順：

  1. Dataflows の Power Query エディターを開く
  2. 「列の追加」タブ → 「条件列」を選択
  3. 条件：[ステータス] が "進行中" に等しい → 出力 100000001（数値型）を追加
  4. 同様の条件を選択肢の数だけ追加する
  5. 追加した列の型を「整数（Whole Number）」に変更する（「テキスト」のままだと Field Mapping 画面で型不一致エラーになる）
  6. Field Mapping 画面でこの変換後の列を Choice列にマップする

各選択肢の整数値は、Power Apps ポータルの対象テーブル → 対象列の編集画面 → 「Choices」タブで確認できる。

この変換アプローチ（条件列を使ってテキスト→整数に変換する）は、公式ドキュメント（Microsoft Learn「Field mapping considerations for standard dataflows」https://learn.microsoft.com/en-us/power-query/dataflows/get-best-of-standard-dataflows）で方向性として言及されているが、Power Query M言語での正式な構文サンプルは公式ドキュメントに現時点では明示されていない。上記の手順は実務での確認手順であり、コミュニティベストプラクティスに基づく部分がある。

難所③ 代替キーを使ったUpsert設定

Dataflows のデフォルト動作は Insert（新規追加のみ）だ。代替キーを指定しない場合、同じデータを2回実行すると重複行が作成される。エラーは出ない。静かに重複する。

既存行を上書き更新しながら新規行を追加する Upsert（Update + Insert）を実現するには、代替キーの指定が必要だ。

難所①で設定した代替キーが Active になっていることを確認したうえで、Dataflows 側の設定を行う。

Dataflows 側の設定手順

  1. Dataflows 編集画面 → 「Map tables」（テーブルマッピング）画面を開く
  2. 対象テーブルの「Alternate Key」フィールドで、Active になった代替キーを選択する
  3. 選択後、保存してリフレッシュを実行する

この設定をすることで：

  • ソースに存在するキー値が Dataverse にも存在する → 既存行を上書き更新
  • ソースに存在するキー値が Dataverse に存在しない → 新規行として追加

という動作になる（参考：Microsoft Learn「Field mapping considerations for standard dataflows」https://learn.microsoft.com/en-us/power-query/dataflows/get-best-of-standard-dataflows）。

キーを指定せずに実行し続けると、毎回の実行でレコードが増殖していく。本番環境で気づいたとき、重複行の削除コストは無視できない。

Dataflows の制限値（2026年時点）

設計段階で把握しておく制約値をまとめる（Power Apps / Power Platform ライセンス基準）。

項目値補足
1テーブルあたりの行数上限制限なし（公式記載）大量データはタイムアウトリスクあり
クエリ実行時間上限4時間超えると途中で終了
リフレッシュ頻度上限48回 / 24時間（30分ごと）スケジュール設定の下限は30分間隔
1Dataflow あたりのテーブル上限50テーブル超える場合は Dataflow を分割
Mashupスクリプトサイズ上限512KB複雑な変換ロジックで到達することがある

出典：Microsoft Learn「Power Query Online Usage Limits」https://learn.microsoft.com/en-us/power-query/power-query-online-limits、Microsoft Learn「What licenses do you need to use dataflows」https://learn.microsoft.com/en-us/power-query/dataflows/what-licenses-do-you-need-in-order-to-use-dataflows

Power BI Pro のリフレッシュ上限は8回/日と大きく異なる。ライセンス種別を確認してからスケジュールを設計する。

トラブルシューティング

「型が一致しません」エラーが出たとき

このエラーが出る主なパターンと確認順序：

  1. Choice列に文字列を直接マップしていないか → Choice列には整数値を渡す必要がある。難所②の変換ステップが入っているか確認する。
  2. 日付列が文字列型のままになっていないか → Dataflows の Power Query エディターで列の型を「日付」または「日時」に変換する。
  3. 数値列に空白やカンマが混入していないか → Excel の該当列を確認する。「1,000」のようなカンマ付き数値は数値型として認識されない。
  4. Lookup列のキー列の型が不一致になっていないか → 代替キーとして設定した列の型（テキスト / 整数）とソース列の型が一致しているか確認する。

Dataflows の実行ログを確認する手順

  1. Power Apps ポータル（make.powerapps.com）→ 左メニューの「データフロー」を選択
  2. 対象の Dataflow の「…」（その他のオプション）→ 「分析情報の表示」または「履歴」を選択
  3. 直近の実行ログが表示される。失敗した場合は行単位のエラーメッセージを確認できる

エラーメッセージが英語で返ってくることが多い。「Invalid data type」「Unique constraint violation」等のキーワードで上記の確認ポイントと照合する。

まとめ

SQL → Excel → Dataflows の4つの難所はすべて「型の不一致」と「キーの識別方法の誤解」に集約される。Excel 前処理で型を守り、Lookup列・Choice型・代替キーの内部構造を把握すれば、繰り返し発生していたエラーは構造的に消える。

次の案件でも同じ壁は来る。このページをブックマークして、難所の手前で一度開くだけでよい。

次の一歩：

  • 代替キーの設定は、投入対象テーブルで先に済ませておく。Pending → Active の移行を待たずに Dataflows 実行に進むと確実にエラーになる。
  • Choice列の整数値は、Power Apps ポータルの「列の編集」→「Choices」で事前に一覧を確認してスプレッドシートに記録しておく。毎回ポータルで調べる手間を省ける。
  • Dataflows の初回実行は、本番データではなく10〜20行程度のサンプルデータで動作確認する。全件流してから型エラーに気づくと、重複行のクリーンアップが加わる。

→ 関連記事：Power Platform で社内申請業務をデジタル化する——Dataverse テーブル設計の考え方 → 関連記事：Power Automate のフロー設計を疎結合にする判断軸