Posts

PAYG（従量課金）の有効化は、Power Platform 管理センターでチェックボックスを入れるだけに見える。実際には Azure 側に専用リソースが自動作成される工程を伴い、ガバナンスの効いたテナントでは japan と japaneast という名前体系のズレでポリシーに弾かれる。加えて、Production または Sandbox 環境が存在しない場合や、テナントの Dataverse 容量が 1 GB に満たない場合は、有効化の手前で詰まる。壁の構造が分かれば、回避の判断軸は絞られる。 有効化の裏で何が起きているかPAYG を有効化すると、Power Platform 側の操作に連動して Azure 側に Microsoft.PowerPlatform/accounts というリソースが自動作成される（Microsoft Learn – pay-as-you-go-set-up、2024）。 Power Platform 管理センター（プラットフォーム側）の操作が、Azure サブスクリプション（クラウド側）への書き込みを誘発する構造だ。この2段構造を意識しないと、エラーの原因が Power Platform にあるのか Azure にあるのかが判断できない。 詰まりやすい壁は、この境界で2種類出現する： 壁1：Azure Policy がリソース作成リクエストを拒否する（ポリシーの名前体系ズレ） 壁2：対応環境がない、または容量が足りない（環境種別・容量の制約） 壁1——japan と japaneast は別体系Azure のリージョン名と Power Platform のジオ名（地理区分名）は、別の名前体系で管理されている。 名称 種別 補足 Japan Geography（地理区分） デプロイ先として直接指定不可 japaneast ARM リージョン名 Japan East・東京/埼玉 japanwest ARM リージョン名 Japan West・大阪 （Microsoft Learn – Azure Regions List、2024） ...

Power Apps PAYG（従量課金：使った量に応じて後払いする課金モデル）のコストは、機能の利用量でも処理件数でもなく、**「アプリを開いたユーザー数」**で決まる。入力ゼロ・閲覧のみでも、その月に1回でも開けば1人ぶん課金が発生する。「使った分だけ払えばいい」という前提で導入を進めている場合、この定義を先に確認してほしい。 環境前提を整理しておく。本記事が対象とするのは、Power Platform 環境で PAYG を有効化し、per-user ライセンスを持たないユーザーへアプリを公開する設計判断だ。フロー実行課金（Premium Cloud Flow $0.60/実行）と Dataverse ストレージ課金（$48/GB/月）は別メーターであり、本記事のスコープ外として扱う。課金の全体像については、Power Apps PAYG の課金単位——月間ユニーク利用者数の定義と落とし穴 を参照してほしい。 「開く」が課金イベントであるMicrosoft の公式定義は次のとおりだ。 “An active user is someone who opens an app at least once in the given month.” “Repeat access of an app by a user isn’t counted.” — Microsoft Learn: Pay-as-you-go meters（2026年時点） 月に何度開いても1カウントのみ。同じユーザーが30回アクセスしても、その月の課金は $10 のまま（本記事公開時点の単価。最新は公式ページで確認してほしい）。逆に言えば、1回でも開けばその月 $10 が確定する。 課金対象と対象外の基本整理は次の表のとおりだ。 ユーザーの状態 PAYG メーターの扱い Power Apps per-user ライセンス保有者 対象外（カウントされない） Dynamics 365 ライセンスで per-user アクセスを持つ者 対象外 M365 ライセンスで標準コネクターのみ使用する者 対象外 上記以外でアプリを開いたユーザー 対象（$10/アプリ/月） さらに、ユーザーがその月に3本の異なるアプリを開いた場合は、3 × $10 が計上される。「ユーザー数 × アプリ数」の掛け算で課金額が決まる構造だ。複数アプリを一括展開するタイミングは、この掛け算が最大値をとる瞬間でもある。 ...

Power Apps の従量課金（PAYG）が数えているのは、回数でも存在でもない。月間にアプリを1回以上開いた、異なる利用者の人数だ。この定義を誤解したまま現場展開すると、見積もりが構造的に外れる。 環境前提：Azure サブスクリプション経由で PAYG を有効化した Power Apps 環境を対象とする（本記事公開時点の情報。単価・課金条件の最新は公式の Power Apps 料金ページを確認）。 「使った分」の正体PAYG の per-app メーターが数えるのは、月間アクティブユーザー数 × アプリ数だ。 アクティブユーザー（active user）の定義は公式に明確に定まっている。 “An active user is someone who opens an app at least once in the given month.” （Microsoft Learn / pay-as-you-go-meters より） その月に1回以上アプリを開いた利用者を1カウントとして計上し、同一ユーザーの2回目以降のアクセスは数えない。この構造から、現場でくり返し見かける3種の誤解が生まれる。 3つの誤解を潰す誤解1：ヘビーユーザーがいると高くなる実際には、回数は課金に影響しない。 “Repeat access of an app by a user isn’t counted.” “Pay-as-you-go billing only counts unique monthly active users of an app. Repeat access of the same app by a user in a single month results in only one charge for that user that month.” （Microsoft Learn / pay-as-you-go-issues-faq より） ...

役職名をもとにアクセスグループを設計しているなら、例外が増えるたびに設計が崩れていく構造に入っている。 同じ「課長」でも決裁権限が違う人がいる。部門によって「支社長」と呼ぶポジションが、別部門では「部長」と呼ばれる。 この2つの問題を役職名で解こうとすると、例外グループが増え続けるか、手動判断が常態化するかのどちらかに向かう。 判定軸を役職名から「その人が管理する範囲（スコープ）」に移すことで、例外を構造の外に出せる。以下、破綻のパターンと修正設計を整理する。 役職名が「表示」である理由アクセス設計で役職名を使う発想は自然だ。人事システムやMicrosoft 365（以下M365）のユーザー属性に役職名は入っているし、「課長以上はこのリソースへアクセス可」というルールは口頭でも伝わりやすい。 ただし、役職名は名刺の文字——つまり表示のための情報であって、アクセスを決める判定軸ではない。 アクセスを決めるべきは管轄地図の区画だ。「その人がどの範囲の業務・データを担当しているか」という情報は、役職名から計算では導けない。同じ「課長」でも、担当課が違えば見るべきデータは違う。同じ「部長」でも、特定プロジェクトの都合で一段上の権限を持つケースがある。この差は人事システムの役職コードには含まれていない。 NIST SP 800-162（Guide to Attribute Based Access Control、2014年・2023年更新）は、役職・職責を軸にするRBAC（Role-Based Access Control：役割ベースアクセス制御）が、兼務・例外・部門横断業務に対応しようとするとロール数が増加し続ける構造的問題を公式に認識している。また、Gartner IAM Summit 2024の場では「誰が何にアクセスできるか？そもそもアクセスすべきか？」という基本問を答えられないIAM（Identity and Access Management：アイデンティティとアクセスの管理）担当者が多いという指摘がなされた（Axoniusブログ経由・2次ソース）。名前軸の設計が崩れるのは運用の問題ではなく、設計の構造上の必然だ。 破綻が起きる3つのパターン役職名ベースの設計が壊れるとき、たいていこの3パターンのどれかが起きている。 パターン1: 同じ役職名で権限が違う「課長グループ」にアクセス権を設定した後、「A課長は経営企画も兼務しているので一段上の権限が必要」という依頼が来る。グループに例外フラグを付けるか、別グループを作るか——どちらを選んでもその場しのぎになる。次の例外が来るたびに同じ判断を繰り返す。 パターン2: 部門ごとに呼称が揃わない営業部門では「支社長」、本社管理部門では「部長」、製造部門では「工場長」——これらが同じ権限スコープを持つとき、呼称の等級を比較して共通グループに収める作業が発生する。組織変更のたびにこの比較表が更新の対象になる。 パターン3: 異動・兼務のたびに設定変更が必要になる役職名軸の設計では、異動や兼務が発生するたびに「旧グループから削除して新グループに追加する」という手作業が伴う。作業が常態化し、設定漏れが権限の過不足を生む。業界の実務知見として、1,000名規模の組織でもロール（グループ）定義が数千に達するケースが広く認識されている（Evolveum IAMドキュメント・2次ソース）。 設計パターン3点セット判定軸を管理範囲に移すとき、以下の3点を設計に組み込む。 1. 名前→範囲の対応表を1枚に隔離する役職名と管理範囲の対応関係を、権限グループとは別の1枚のテーブルに切り出す。 [ユーザー] → [名前→範囲対応表] → [スコープ定義] → [リソース権限] 権限グループ側は「スコープA担当」「スコープB管理者」という管理範囲ラベルを持ち、役職名は対応表の入力値になるだけで権限グループ側には現れない。 組織変更や呼称変更があったとき、更新するのは対応表だけでよく、権限グループ側は無改修になる。 設計の比較 役職名軸 管理範囲軸 例外対応 新グループを追加 対応表に1行追加 呼称変更 グループ名も変更 対応表だけ変更 組織変更 グループ構成を再設計 スコープ定義のみ見直し 異動処理 複数グループを更新 対応表のエントリを更新のみ 2. 例外は「人ごとの上書き」データで吸収する同じ役職名でも権限が違うケースをスコープ計算で解こうとすると、ルールの置き場所がなくなる。「この人だけ一段上」という例外は、計算ロジックではなく人ごとの上書きエントリで持つ。 実装上は、ユーザーに紐づく「スコープオーバーライド」テーブルを対応表の隣に用意し、上書き値がある場合はそちらを優先する構造にする。 [ユーザーID] × [上書きスコープ] × [有効期限] × [申請理由] 有効期限と申請理由を必須フィールドにしておくことで、いつ・なぜ付与された例外かを追跡できる状態を保てる。過剰権限が放置されるとセキュリティインシデントにつながる経路は実際にある（IDSA「Trends in Securing Digital Identities」2024：過去の調査データで不適切な権限管理が侵害の36%、過剰権限が21%に関与）。上書きデータは定期的にレビューし、不要になった時点で削除する運用とセットにする。 ...

「タイムアウト0件、合格」という結果が出た。だが、その数値は本当に測りたいものを測っていたか。 実機検証でもっとも見落とされがちなのは、対象システムの不具合ではなく計器（測定の前提）の誤りだ。 きれいな結果ほど疑われず、そのまま結論に変わりやすい。 「計器を疑う」という視点パイロットが視界ゼロの気象条件で飛行するとき、コックピットの計器だけを根拠に操縦する。FAA（米連邦航空局）はこの飛行方式をIFR（Instrument Flight Rules）と定義している（FAA Pilot/Controller Glossary 2024年）。計器が正しいことを前提とした運用だ。 この話を逆にすると、ソフトウェア検証への応用になる。「計器が正しい」という前提を意識せずに検証結果を読むと、計器が狂っていても気づかない。「計器を先に疑う」というのは著者が航空のアナロジーを逆転させた言い方で、正式な学術用語ではない。ただ、実機検証の現場で繰り返しぶつかった構造を説明するのに、航空のアナロジーを逆転させた視点が有効だった。 SREやDevOpsのオブザーバビリティ文脈では、instrumentation（計器化）は「センサー・ゲージ・アラームの集合体でシステム状態を観測可能にする行為」を指す（SRE School 2026年）。その計器自体が誤った値を出していたら、オブザーバビリティは機能しない。 以下で、実機検証で実際に踏んだ4種類の計器の嘘と、それぞれへの対処を整理する。 計器の嘘1: 環境の汚染前回の検証データが環境に残留していて、新しい測定が汚染される。典型的なのは「解決済み件数が投入件数を上回る」という数値が出るケースだ。物理的にあり得ない値なので、見た瞬間に気づけば問題ない。だが、きれいな数値の場合はそのまま通過してしまう。 対処：サニティチェックを先に走らせる。 サニティチェックとは、「主張や計算結果が正しい可能性があるかを素早く評価する基本テスト」（Wikipedia – Sanity check 2024年）だ。明らかに誤った結果クラスを除外するための確認で、IEEEやSEIの正式標準用語ではなく業界慣用語にとどまるが（Software Testing Help 2024年）、実務では有効なファーストステップになる。 チェック観点 確かめること あり得ない値 件数の逆転、マイナス値、100%超え 前回データの残存 ジョブテーブルに旧データが混在していないか 環境の初期化 本当にクリーンな状態から始めているか 測定を始める前に、「この環境は本当に前回と切れているか」を確かめる。これが最初の手続きだ。 計器の嘘2: 指標の取り違え「処理時間を測った」という記録が、実際には「キュー待ち時間＋実行時間」の合計だったというケースがある。見たかったのは実行時間だけなのに、待機時間が混入していると、数値の意味が変わる。 たとえばキューが詰まっている状況では総経過時間が長くなるが、実行自体は速い場合がある。反対に、キューが空いていれば見かけ上速く見えるが実行処理が重いこともある。指標の定義を事前に明示せずに測ると、「速い/遅い」の結論が的外れになる。 対処：測定対象の定義を測定開始前に書き留める。 「どこからどこまでを時間とするか」「何個のジョブを対象とするか」「並列度はいくつか」——これらを検証レポートの冒頭に書いておく。指標の定義は後付けにしない。 なお、このパターンの技術的な詳細（Dataverse非同期ジョブのキュー構造とタイムアウトの関係）は関連記事「async-timeout-diagnosis」を参照。 計器の嘘3: データ消失（成功ジョブの自動削除）Power Platform（Dataverse）の非同期ジョブ処理で遭遇する、見落としやすい仕様がある。 Microsoft Learnの公式ドキュメントによれば、Dataverse AsyncOperationテーブルの成功済みシステムジョブは、デフォルトで30日後に自動削除される（Microsoft Learn 2025年）。失敗・キャンセルの場合は60日間保持されるが、成功ジョブの保持期間はそれより短い。 “All environments are configured with out-of-box bulk delete jobs to delete successfully completed workflow system jobs that are older than 30 days.” — Microsoft Learn, Delete completed system jobs and process log ...

特定の PoC 環境で、Dataverse 非同期ジョブのキュー待ちが最大13分に達したとき、タイムアウトは1件も発生しなかった。「2分制限のはずでは」と思ったとしたら、診断の起点が間違っている。 タイムアウトは実行時間にしかかからない。ログで見ている「総経過時間」は、キューに放り込んでから完了するまでの wall-clock であり、その大半が「拾われ待ち（ディスパッチ待ち）」である可能性がある。この区別が曖昧なまま診断すると、問題のないジョブを危険視するか、本当に問題のある実行時間の長さを見逃す。 結論を先に示す。Dataverse の AsyncOperation テーブルには CreatedOn / StartedOn / CompletedOn の3時刻フィールドがある。これを分離して計測すれば、総経過時間の内訳がわかり、タイムアウト診断が正確になる。 13分待っても、タイムアウトしないDataverse の非同期サービスは FIFO（先入れ先出し）のマネージドキューを持つ。ジョブが登録されると、キューに投入され、非同期サービスが「拾いに来る」まで待つ。この待ち時間はタイムアウトのカウントに含まれない。 Microsoft Learn の公式ドキュメント（Asynchronous service (Microsoft Dataverse)、2025年確認）には次の記述がある。 sending the request asynchronously doesn’t provide more execution time 非同期登録にしても、実行タイムアウト（プラグイン・ワークフロー共通で2分＝120秒）は変わらない。制限されているのはあくまで「実行時間」であり、「キューに入ってから拾われるまでの待ち時間」は制限の対象外だ。 レストランの席待ちに例えると、タイムアウト2分は「席に着いてから注文・食事・会計までの時間制限」だ。席待ちで40分並んでいても、それはタイムアウトに数えられない。13分のキュー待ちがあっても、その後の実行が2分以内に収まれば、タイムアウトは発生しない。 ただし、上記の「最大13分のキュー待ち」は特定の PoC 環境での観察値であり、本番環境や他製品での再現を保証するものではない。 判断軸：拾われ待ちと実行時間は別物だ非同期ジョブの経過時間は、大きく2つに分解できる。 区間 内容 タイムアウト対象か 拾われ待ち キュー投入 → 実行開始 対象外 実行時間 実行開始 → 実行完了 対象（2分・120秒） タイムアウト診断で見るべきは、右列が「対象」の実行時間だけだ。ログの総経過時間を見ていると、拾われ待ちの長さがそのまま「危険なシグナル」に見えてしまう。逆に、実行時間が2分に近づいていても、総経過時間が短ければ見過ごす可能性がある。 計測の単位を間違えると、診断の方向が最初から狂う。 AsyncOperation テーブルで3時刻を分離するDataverse の AsyncOperation テーブル（System Job (AsyncOperation) table/entity reference、2025年確認）には、以下のフィールドが存在する。 フィールド 意味 診断での役割 CreatedOn ジョブ作成（キュー投入）時刻 拾われ待ちの開始点 StartedOn 実行開始時刻 拾われ待ちの終点・タイムアウトカウント開始 CompletedOn 実行完了時刻 実行時間の終点 ExecutionTimeSpan 実行時間（数値） タイムアウト評価の直接対象 計算式はシンプルだ。 ...

並列ワーカーを増やしたのに処理が遅くなった、あるいは不安定になった——そういう状況で真っ先に疑うべきは、ボトルネックが「容量の問題」ではなく「通り道の渋滞」になっている可能性だ。 この2つは別の病気であり、治療法が逆になる。容量不足なら並列化は効く。だが渋滞が原因なら、並列を増やすほど状況が悪化する。どちらの病気かを見分けることが、チューニングの出発点になる。 規模を倍にしたら、裏処理が6倍遅くなった実機での観測を出発点として示す。 処理対象レコードを5万件から10万件——規模を2倍——に増やした。書き込み自体はほぼ線形にスケールした。ところが、書き込み後に走る裏処理（プラグイン・同期処理）の1件あたりの処理時間が約6倍に膨らんだ。 レコード数は2倍なのに、1件あたりのコストが6倍。これは容量不足で起きる線形のスケール超過とは異なる動きだ。「通り道」に何かが詰まって、ピタゴラスイッチ的に連鎖悪化していた。 環境前提の確認：チューニング対象はリクエスト制限のあるプラットフォームで動く同期処理。スペックアップで解決する問題ではない。 2種類の遅さの病気——型Aと型B処理が遅い原因には2種類あり、対策が逆になる。 観点 型A（容量不足） 型B（直列渋滞） 症状 エラーではじかれる・OOM・タイムアウト じわじわ遅くなる・不安定 限界の形 硬い壁（急激に落ちる） なめらかな遅延爆発（利用率が上がるにつれ非線形に悪化） 並列を増やすと 速くなる 遅くなる 診断の手がかり ログにリソース不足の記録が残る ログは正常・ただしキューの待ち時間が長い 対策の方向 スケールアップ / スケールアウト 1単位の仕事量を絞る・通り道を太くする・時間分散 冒頭の6倍膨張は型Bの典型だ。エラーは出ていない。ただ、ある1本の共有資源への書き込み競合がひたすら積み上がっていた。 待ち行列の経済——利用率が上がると待ち時間は非線形に爆発する型Bの「なめらかな遅延爆発」の数学的な構造は、待ち行列理論で説明できる。 コーヒーショップを想像してほしい。レジは1台、客は次々と来る。客が少ないうちは注文してすぐ受け取れる。客が増えてレジの処理能力の80%くらいに達しても、多少の列はできるが許容範囲だ。ところが90%を超えたあたりから、列が急激に伸び始める。99%に近づくと、列は事実上無限に長くなる。 これはコーヒーショップだけの話ではなく、1つの共有資源に複数のワーカーが書き込みを競合させる構造すべてに当てはまる。 Kleinrock の教科書（Queueing Systems, Volume 1: Theory, 1975年, Wiley）が示す M/M/1 キューイングモデルの公式がその理由だ。 W ∝ 1 ÷ (1 − ρ) W が待ち時間、ρ（ロー）が利用率（到着率 ÷ 処理率）。利用率が1に近づくほど、待ち時間は際限なく膨らむ。 利用率 ρ 待ち時間の倍数（基準比） 50% 約2倍 80% 約5倍 90% 約10倍 99% 約100倍 並列ワーカーを増やすということは、1本の共有資源への到着率 λ を上げることだ。λ が上がれば ρ が上がり、待ち時間は非線形に爆発する。「並列を増やしたのに遅くなった」は、数学的な必然になる。 なぜDBのトランザクションログが「1本の直列資源」なのかバッチ処理や同期処理の文脈で、この「1本の共有資源」の実体になりやすいのがDBのトランザクションログだ。 ...

Azure や Power Platform の管理画面でつまずく場所には、だいたい共通した理由がある。 ボタンの存在・押す順序・固定された名前・エラーメッセージ——これらは設計者の気まぐれではなく、システムが守る「不変条件」を画面に物理化したものだ。 環境前提：Azure ポータル / Power Platform 管理センターの操作権限があること。GUI は更新が速いため、以下の実例はいずれも 2026 年時点の確認情報として読むこと。 GUIでつまずく場所には「理由」があるクラウドの管理画面を触り始めた頃、ボタンがグレーアウトしている理由が分からず、手順を最初から読み直した経験はないだろうか。エラーメッセージを Google に貼り付けて、それっぽい Stack Overflow の回答を試す——という作業を繰り返した日数を足し合わせると、それなりの時間がかかってきたのではないか。 だが、ほとんどの詰まりには構造的な理由がある。 ボタン・順序・既定値・固定名・エラーは、すべて「不変条件の物理化」だ。 不変条件とは、システムが設計上必ず守る制約のこと。名前の衝突禁止、権限の分離、リソースの依存関係——これらを画面の操作制約として見えるようにしたのが、GUI の「詰まりポイント」の正体だ。 このフレームで読むと、暗記していた操作手順が「必然」として理解できるようになる。 不変条件5型：ボタン・順序・エラーはここから来る以下の5型は、クラウド GUI で頻繁に現れる不変条件のパターンを筆者がまとめた分類だ（公式分類ではない）。個々の事例は後述の Microsoft Learn 一次ソースで裏付け済みだが、5型としての体系化は提案書起点の整理であることを断っておく。 型 名称 一言での意味 ① 一意性 システムが専有する名前・文字列は使えない ② 所有と権限の分離 身分の管理者（誰を管理するか）≠ 資源の所有者（何を操作できるか） ③ 依存リソースの存在順 先に作るものが決まっている。順序を逆にすると詰まる ④ 安全の二要件 「昇格する」と「解除する」は別の操作。どちらかだけでは安全は成立しない ⑤ レイヤー切り分け どの層が止めているかで、対処者も意味も変わる この5型を頭に入れておくと、初見のエラーでも「この詰まりは③番だな」と当たりをつけられるようになる。 4事例で読む：不変条件はこう画面に出てくる(A) PIMの昇格ボタン → 解除ボタン ＝ 安全の二要件（型④）Azure PIM（Privileged Identity Management：特権 ID 管理）では、高権限ロールは「Eligible（適格）」状態で休眠している。使うときだけ Activate（昇格）し、作業後は Deactivate（解除）する。 「なぜ昇格後に解除ボタンが出てくるのか」——これは UI の癖ではない。JIT（Just-In-Time）アクセスという設計意図が画面の操作制約として現れた形だ。 公式ドキュメントには次のように明記されている： “Privileged Identity Management provides just-in-time privileged access to Microsoft Entra ID and Azure resources.” “Eligible assignments require the member to activate the role before using it.” ...

CreateMultiple（バルク作成 API）を使ったのにジョブが大量に積まれる。あるいは処理速度が単発と変わらない。原因の多くは受け手にある。 送る側がバルクになっても、受け取るプラグインが「1件ずつ処理」のままなら、Dataverse は内部でバルク要求を件数分の単発イベントに分解し、既存プラグインを N 回個別に発火させる。この挙動が「縮小発火」（公式呼称：message pipelines merged の逆方向動作）だ。 結論を先に言う。受け手のプラグインを CreateMultiple イベントに登録し直し、EntityCollection をまとめて処理するロジックに書き替えて初めて、バルク化の効果が出る。 天井は消えない——ただし、正直に言えば「移る」だけだ。それも含めて説明する。 なぜ受け手が「1件ずつ」だと遅いのかMicrosoft Learn 公式ドキュメント（2026年時点）には次の一文がある： “When you use a bulk operation message, the respective Create and Update event occurs for each Entity instance in the Targets parameter.” N 件を CreateMultiple で送ると、Create に登録されたプラグインは N 回個別に呼び出される。バルク API を叩いた送り側からは 1 リクエストに見えていても、受け手の世界では N 回のプラグイン実行サイクルが回る。 これが「縮小発火」（message pipelines merged の逆方向）と呼ぶ挙動の正体だ。公式ドキュメントで明示されており、仕様通りの動作——つまり、バグではない。 この構造で問題になるのは、同期プラグインの実行時間だ。公式は「同期プラグインが 2 秒を超えると深刻なパフォーマンス低下につながる」と明記している。100 件のバルク要求で縮小発火が起きていれば、同期プラグインは合計で最大 200 秒分のサイクルを費やすことになる。送る側だけをバルクにしても、ここが律速だ。 受け手の直し方——CreateMultiple への移行手順プラグインを CreateMultiple イベントに対応させる方向は任意だが、公式ドキュメントは「パフォーマンス向上はバルク版に書き換えたプラグインのみが享受できる」と明示している。実質、書き替えが必要になる。 移行の手順は次の流れで踏む。 ステップ 1：既存の単発プラグインを無効化（または削除）してから移行する これを省くと二重実行のリスクがある。公式は次のように明記している： ...

Lookup（関連レコードへの参照）を埋めるとき、内部 GUID を自前で取りに行くか、業務コードのままサーバーに委ねるかは、設計の細部に見えて環境移行の成否を決める。 結論を先に述べると、委譲が既定・自前は例外だ。 内部 GUID は dev/test/prod で別値になる環境ローカルな値であり、移送側が抱え込んだ瞬間に「build once, deploy many」の可搬性は失われる。 開発では動いたのに、本番で関係が空になったDataverse への取込定義を開発環境で完成させ、テストに展開した途端に Lookup フィールドが空になる。原因の多くは、開発環境で取得した内部 GUID をそのまま成果物に焼き込んでいることだ。 Dataverse の内部 GUID（レコードの主キー）は、レコードが作成された環境内で自動発番される。dev で a1b2c3... だったものが、test の同じ取引先レコードでは d4e5f6... になる。環境をまたぐたびに別の値になるため、GUID を直接参照した取込定義は他の環境で動かない。 Microsoft Learn の OData dataflow 移行ガイド（Migrate Data Between Dataverse Environments Using the OData Connector）は次のように明言している。 代替キーが必須。親テーブルの代替キーがないと子テーブルの Lookup カラムを設定できない。 業務コードは環境が変わっても同じ値を持つ。社内の取引先コード・品番・従業員番号——これらは dev でも prod でも変わらない。環境ローカルな GUID ではなく、環境不変の業務コードで Lookup を張るのが自然な理由はここにある。 責任分界：サーバーが ID を解決するのが自然「業務コード → 内部 GUID」の変換をどちらが担うか。移送側がこれを担うとは、自分が所有していない ID を引きに行って管理下に置くことを意味する。これは**漏れた抽象（leaky abstraction）**と呼ばれる設計上の問題だ——本来サーバーが担うべき責任を移送側に漏らしている状態を指す。 内部 GUID を所有しているのは Dataverse のサーバー側だ。業務コードを受け取り、該当レコードの GUID を探して Lookup を解決する作業は、そのまま「ID の所有者」であるサーバーが担うのが責任分界として自然になる。 ...