Dataverse への取込ツールは、好みや習熟度で選ぶと後で詰まる。
判断軸は 2 つだけ——代替キーで Lookup を解決できるか、secretless Managed Identity（MI）で繋げるか。
この 2 軸を両方満たすツールは、2026 年 6 月時点で Azure Functions（SDK for .NET）と Azure Data Factory（ADF）に限られる。

2 軸で絞る——なぜ「Lookup 解決力 × MI secretless」なのか

Dataverse の行レベルセキュリティ（Row-level Security）は、レコードの「所有者（owner）」フィールドを起点に動く。
この所有者は、取込レコードに Lookup 列（参照列）が正しくセットされているとき、初めて自動設定が発火する。

つまり、取込ツールが Lookup 列を解決できなければ、所有者は設定されず、行セキュリティはそもそも機能しない。
認証が Managed Identity（secretless）でない場合は、シークレット管理の運用負荷と漏洩リスクが別途発生する。

2 軸を分けて評価しても意味が薄い。取込ツールの選定は、この 2 軸の同時達成で決まる。

ツール能力マトリクス

環境前提：Dataverse への書き込み、代替キー（Alternate Key）によるインライン Lookup 解決、secretless MI 認証の 3 要件で評価する（2026 年 6 月時点）。

ツール代替キー Lookup 解決MI secretless 接続両軸評価
Power Automate（Dataverse コネクター）△ 行操作は可、複雑な Lookup 解決は制限あり△ SP + Secret は対応済み。secretless MI は標準コネクターでは未対応。HTTP / Custom Connector 経由で実現可能だが設計コスト増△
Power Apps Dataflows（Power Query ベース）△ 代替キー設定済みテーブルなら解決可△ 公式ドキュメントに MI 接続手順の記載なし（2026 年 6 月時点）。SP + Secret が一部利用可△
Azure Functions（SDK for .NET）✓ EntityReference + 代替キーで GUID 不要✓ ManagedIdentityCredential で secretless 対応✓
Azure Data Factory（ADF）✓ Lookup Activity 等で対応✓ MI 対応コネクター✓

注意：Azure Data Factory の Mapping Dataflows は MI 接続に対応しているが、Power Platform の Power Apps Dataflows とは別製品。Power Apps Dataflows（Power Query ベース）と ADF Dataflows を同一視しないこと。

Power Automate を「使えない」と断定する必要はない。標準コネクターの範囲内での制約が問題になるだけで、HTTP コネクターや Custom Connector を組み合わせれば secretless MI は実現できる。ただしその設計コストは、Azure Functions を選んだ場合と比較する価値がある。

Azure Functions での実装例

Azure Functions（SDK for .NET）を使う場合、MI 認証と代替キー Lookup 解決を次の構成で組み合わせる。

Web API 経由——PATCH で代替キーを使った Lookup 列設定

PATCH /api/data/v9.2/contacts(emailaddress1='[email protected]')
Content-Type: application/json

{
  "[email protected]": "/accounts(account_code='ACC001')"
}

account_code が代替キーとして定義されていれば、GUID を事前に取得せずに Lookup 列（parentaccountid）をセットできる（出典：Microsoft Learn「Use an alternate key to reference a record」）。

Dataverse SDK for .NET（C#）——EntityReference で代替キー指定

// 代替キーで EntityReference を作成（GUID 不要）
var accountRef = new EntityReference("account",
    new KeyAttributeCollection() { { "account_code", "ACC001" } });

// Entity の Lookup 列に設定
entity["parentaccountid"] = accountRef;

MI 認証との組み合わせは、ManagedIdentityCredential で ServiceClient（Dataverse SDK for .NET）を初期化することで成立する。代替キーを使った UpsertRequest と組み合わせれば、GUID 依存なしに冪等な取込処理が実装できる（出典：Microsoft Learn「Integrate Microsoft Dataverse Azure solutions」）。

この構成を個人 PC の M365 Developer Tenant 環境で検証する場合の手順は、関連記事「[normalize-at-ingestion-altkey-lookup]」を参照。

「緑（成功）」≠ 行セキュリティの着地

ここが、取込パイプライン設計で最も見落とされる箇所だ。

Power Automate や Dataflows でレコードを書き込んだとき、実行ステータスは「成功（緑）」を返す。だが、成功が返ったことと、行レベルセキュリティが意図どおりに機能していることは別の話だ。

実務でよく観察される連鎖は次の構造をたどる：

Lookup 列の解決ができていない
    ↓
所有者（owner）フィールドの自動設定が発火しない
    ↓
行レベルセキュリティが「レコードあり」と判定しない
    ↓
特定ユーザーにデータが見えない（またはすべてのユーザーに見える）

この連鎖を直接示す公式ドキュメントは 2026 年 6 月時点で確認できていない。ただ、所有者フィールドと行セキュリティの関係は Dataverse の基本設計であり、Lookup 欠落が所有者設定の前提条件を崩す構造として実機挙動の観察から導かれる。詳細な所有者設定の仕組みは関連記事「[dataverse-owner-set-once-auto-fill]」を参照。

問題は「緑」が確認の終了を告げるサインとして扱われることにある。実行ステータスの確認と、セキュリティ着地の確認は、別の検証フローを必要とする。

苦手なツールで Lookup 欠落を回避する

Power Automate やローコードツールを既に使っている構成で、代替キー Lookup 解決が難しい場合は、内部 ID（GUID）を先に取得してから書き込む方法で回避できる。

手順は次の通り：

  1. ソースレコードの自然キー（メールアドレス・コードなど）で参照先レコードを検索し、GUID を取得する
  2. 取得した GUID を @odata.bind 形式で Lookup 列にセットして書き込む
PATCH /api/data/v9.2/contacts(emailaddress1='[email protected]')
Content-Type: application/json

{
  "[email protected]": "/accounts(00000000-0000-0000-0000-000000000001)"
}

GUID 直指定でも Lookup 列は正しくセットされる。設計上のコストは増えるが、取込ツールを変更できない制約がある場合の実用解だ。

ただし、この方式には「GUID 取得ステップ分の追加 API 呼び出し」と「GUID 取得と書き込みの間でレコードが削除された場合の整合性」という 2 つの留保がある。Azure Functions であれば代替キーで 1 ステップに集約できる。

まとめ

取込ツールの選定は、Lookup 解決力と MI secretless 接続の 2 軸で決める。どちらかが欠ければ、成功ステータスが返っても行レベルセキュリティは着地しない。

次の一歩：手元の取込処理で Lookup 列が正しくセットされているかを、Dataverse の「列の診断ビュー」または Web API で直接確認する。owner フィールドが埋まっていることと、セキュリティロールへの反映を別々に検証する。

関連記事：

  • [取込時の正規化と代替キー Lookup 構築手順——normalize-at-ingestion-altkey-lookup]（リンク予定）
  • [所有者フィールドの自動設定と一度セットしたら変えない設計——dataverse-owner-set-once-auto-fill]（リンク予定）
  • [秘密ゼロで Azure リソースを繋ぐ梯子構造——db-identity-auth-no-shared-password]（リンク予定）