Posts

Dataverse MCPプラグインの導入は1コマンドで完了する。Claude Codeで /plugin install dataverse@claude-plugins-official を実行すれば、Python3・PAC CLI・.NET SDK・Azure CLI・Node.js・Dataverse CLI・Gitの一式が自動で揃う。 難しいのはその先だ。接続を成立させるには、テナント全体の管理者同意（G1）と環境ごとの許可リスト登録（G2）という2段のゲートが待つ。どちらも迂回できない。そしてG2にはManaged Environmentが必須条件であり、Developer Plan環境ではデフォルトで設定画面が現れない可能性がある。 この記事では「どのテナントでMCPが通るか」の判断軸を整理する。対象読者は、Claude CodeやCursorからDataverseを操作しようとしている個人開発者・受託開発者。前提：Power Platformの環境概念（Dataverseテナント・環境・Managed Environment）について基礎知識があること。 2段ゲートの全体像：先に地図を見ておくMCP接続が成立するまでの構造はこうなっている。 [Claude Code] ↓ プラグイン導入 (/plugin install 1コマンド) [G1: テナント全体の管理者同意] ↓ グローバル管理者 or 特権ロール管理者が承認 [G2: 環境ごとの許可リスト登録] ↓ Managed Environment が有効な環境のみ設定可能 [Dataverse MCP Server] ↓ [Dataverseデータ操作（読み取り・書き込み・削除系）] G1→G2の順に通過が必要で、G1を通過していてもG2が設定されていなければMCPは機能しない。2段とも「自分が管理者でないと動かせない」仕組みになっている。 G1：テナント全体の管理者同意承認者：Azure ADのグローバル管理者、または特権ロール管理者。 プラグインはテナントIDとクライアントID入りの同意URLを自動生成して案内する。承認操作そのものはプラグインでは代行できない。一次ソース：Dataverse Plugin Is Now on the Claude Marketplace（Microsoft Power Platform Blog） 顧客テナントでは、G1の時点で顧客側のグローバル管理者の承認が必要になる。管理者を説得できなければMCP接続は始まらない。 G2：環境ごとの許可リスト登録G1通過後、使いたい環境ごとに許可リストへの追加が必要だ。 操作パス：Power Platform管理センター → 管理 → 環境 → （対象環境名）→ 設定 → 製品 → 機能 →「Dataverse MCP Server」セクション →「Allow MCP clients to interact with Dataverse MCP server」をオン。 ...

「個人 PC での開発は不可」で会話が終わるとき、足りないのは熱意ではなく答えだ。 相手が確認したいのは 3 点しかない。その端末は誰の管理下にあるか / 顧客テナントのどこまで入るのか / AI は何に触るのか。 この 3 つに具体的な答えを持てば、依頼の中身が「PC を貸してください（規程の例外承認）」から「設定を 1 つ入れてください（設定変更）」に変わる。 顧客の規程には、外部の個人が AI ツールを使って開発することを記述する欄そのものが無いことが多い。欄が無ければ、正しさとは無関係に通り道が存在しない。この状況がなぜ続くのかは本番データは外に出さない方が安全だ——それでも声が上がらない理由で扱った。ここでは「では何を持てば審査に答えられるか」だけを書く。 前提を 1 つ置いておく。基本線は顧客テナントに触らずに作り切ることで、この記事の装備はその代わりではない。 入館を求められたときと、「触っていない」ことを証明する必要が出たときに要るものだ。 先に、顧客側に発生するコストを書くこの経路は無料の抜け道ではない。顧客側に作業と費用が生まれる。提案の後で判明すると信用を失うので、最初に開示する。 顧客側に発生するもの 中身 誰が実施するか クロステナントアクセス設定の変更 受信側の信頼設定で「準拠しているデバイスを信頼する」を有効化 Entra の Security Administrator 以上 ゲストユーザーのライセンス Dataverse にアクセスさせるならゲスト側もライセンス要件を満たす必要がある 顧客のライセンス管理者 Dataverse セキュリティロール ゲストにロールを割り当てる。既定では何も付かない 環境管理者 / システム管理者 環境ごとの設定変更 ゲストアクセスの開閉は環境単位。まとめて一括では入らない Power Platform 管理者 監査の見直し 外部ユーザーが増えるぶんの証跡確認 情報セキュリティ担当 この表を先に出せる状態が、審査を通る前提になる。交渉の相手を、規程の例外承認から設定変更 1 件に移す。 問い①：その端末は誰の管理下にあるか既存の答えは貸与 PC だ。ID とデバイスと開発環境を一度に片付けるので有効だが、届くまでの待ち時間に報酬は出ない。 別解は 3 段構えになる。 受託側が自分の Microsoft Entra テナントを持つ（M365 や Power Platform の職場アカウントを自分の名義で確保する） 個人 PC を自分のテナントの Intune に登録し、デバイス準拠ポリシーを満たす（Intune ＝ 端末の設定と準拠状態を管理する Microsoft のサービス） 顧客側で、受信側の信頼設定を有効にしてもらう 3 が要になる。Microsoft Entra のクロステナントアクセス設定には、外部ユーザーのホームテナントが出す「この端末は準拠している」というクレームを信頼するかどうかの選択肢がある。公式ドキュメントの記述はこうだ。 ...

案件が決まってから、最初に手を動かせるまで何をしていただろう。 アカウントの発行を待つ。貸与パソコンの到着を待つ。VPN の設定手順書を待つ。情報システム部門の承認を待つ。契約は成立しているのに、環境が揃うまで着手できない。その待ち時間に、報酬を払ってくれる人はいない。 この待ち時間を、多くの人が「仕方のないもの」として受け入れている。環境を用意してもらわないと開発は始まらない、という前提があるからだ。 その前提を、一度外してみる。 「触らない」は制約ではなく設計になった顧客のテナントに一切接続せず、自分の開発環境だけでアプリを組み上げ、ファイル1つで納品する。この形は以前から理屈のうえでは可能だったが、2026年に入って土台のほうが追いついてきた。 Microsoft の権限設計が、この形を推奨する側に回った。 開発者が AI エージェントに Dataverse を触らせようとすると、テナント全体の管理者同意と環境ごとの許可リスト登録という2段の関門を通る必要がある。この関門は迂回できない。顧客のグローバル管理者にとっては、テナント全体に効く同意を外部の委託先のために出す判断になる。承認のハードルは高い。 顧客のテナントに AI を入れる道は、技術のほうが先に閉じている。 開けようとすること自体が、無理筋になった。 もうひとつ、ゲストアカウントで呼んでもらう抜け道も細くなった。新しく作られた環境では、既定でゲストの Dataverse アクセスが遮断される 設定になっている。「ゲストで招待するから作業して」は、Power Platform では成立しない。 残る道は2つになる。顧客が正規のアカウントを発行してくれるのを待つか、そもそも触らずに作るか。 触らないと決めると、何が起きるか自分の側にすべてが返ってくる。 顧客の環境には、業務で使われている本物のテーブルがある。実際のデータが入っていて、動いているフローがあり、誰がどこまで見られるかの設定が積み上がっている。そこに入れてもらえるなら、現物を見て真似ればいい。 入らないと決めた瞬間、それが全部なくなる。渡された仕様書と、自分の頭のなかにある構造の知識だけで、同じものを組み立て直すことになる。 ここが分かれ目になる。この働き方が成立するかどうかは、契約でも交渉でもなく、構造をどれだけ正確に再現できるかで決まる。 再現しようとすると、必ず詰まる場所がある。しかもその場所は、驚くほど毎回同じところだ。 詰まる場所は4つに分かれる自分の環境で作り直すとき、つまずきは4つの層のどれかで起きる。 第1層：データの形。 テーブルとテーブルをどう繋ぐか。Lookup 列は SQL の JOIN とは違う挙動をするし、Excel から取り込んだ参照は静かに空のまま入る。名前の列を突合キーに使うと、あとから壊れる。 第2層：誰に何が見えるか。 一覧画面から隠すことと、権限で守ることは別物だ。ビューのフィルターはアクセス制御ではない。フォームから列を外しても、その列の中身は守られていない。ビジネスユニットを無効化しても、権限は切れていない。この層の誤解は、納品してから発覚すると信頼の問題になる。 第3層：認証と鍵。 鍵を渡さずに繋ぐ方法。認証は通っているのに拒否されることがあり、401 と 403 を切り分けられるかで原因が変わる。承認する人に本番権限が要らない仕組み。個人PCで作る働き方は、この層を説明できることが前提条件になっている。 第4層：コストと性能。 従量課金は誰に開かせるかで決まる。並列を増やすと遅くなることがある。検証できれいな数値が出たら、まず計器を疑う。 この4層が、「顧客の環境に入らなくても作れる」を実際に支えている中身だ。 環境をもらえば現物を見て済むものを、もらわないと決めたぶん、原理で知っておく必要がある。 それぞれの層で、何を先に読むか以下は、詰まったときに開く場所として並べてある。上から順に読む必要はない。 第1層 データの形 DataverseのLookup列はSQLのJOINではない——Excelインポートで参照が空のままになる理由 DataverseのName列をUpsertの突合キーに使ってはいけない理由と、代替キー設定の3ステップ Dataverse 代替キーで Lookup を張る——取込時正規化と親→子ロードオーダーの作法 フロント入力データをSoRに昇格させるか——判断は「他システムが書き足すか」の一点 Power Platform のローコードは行を作れる。多対多の繋ぎは作れない 第2層 誰に何が見えるか Dataverse のビューフィルターはアクセス制御ではない——ロール深度×BU 構造で守り、API で壊して確かめる Dataverse の列セキュリティ——フォームから外すだけでは列の機密は守れない Dataverse で owner と owningBU をどう使い分けるか——2語に分けると設計判断が言語化できる Dataverse ビジネスユニットの「無効化」は権限を切らない——廃止設計に失効工程を組み込む判断軸 役職名でアクセスを設計すると例外で壊れる――判定軸を「管理範囲」に移す3つの設計パターン 第3層 認証と鍵 Microsoft Entra ID で AI 外部委託を止めずに進める——鍵もデータも渡さない設計の判断軸 Azure SQL への接続情報を外部ベンダーと共有しない——Entra ID の認証梯子で「鍵を渡さない設計」を組む Microsoft Entra クロステナント：同意しても 401 が返る理由と 403 との切り分け方 Power Platform 委任デプロイ：なぜ承認者に本番権限が要らないのか Power Platform 認可設計：そのアプリが消えても残る環境×グループ 3 層の分け方 第4層 コストと性能 Power Platform 従量課金（PAYG）有効化で踏む2つの壁 Power Apps PAYG のコストは「誰に開かせるか」で決まる 並列を増やすと遅くなる理由と、直列ボトルネックを解消する3つの対策 検証で「きれいな数値」が出たら計器を疑え――4種の測定ミスと確かめる手順 作る場所を3つに分ける知識が揃っても、置き場所を間違えると台無しになる。AI に手伝わせるなら、なおさら線を引いておく必要がある。 ...

個人PCで複数の案件を回していると、いつの間にかこうなる。 pac auth list に複数のプロファイルが並ぶ。az account list にも複数のアカウントが載る。どれも自分がサインインしたものだが、どれが今アクティブなのかは、コマンドを打った瞬間には見えていない。 この状態で、スクリプトが1本走る。 --environment を書き忘れると、どこへ行くのかPower Platform CLI の多くのコマンドは --environment で宛先を指定できる。書かなくても動く。 書かなかったとき、コマンドは今アクティブな認証プロファイルの既定環境へ向かう。 ここが分かれ目になる。複数テナントのアカウントを持っている人にとって、「今アクティブなプロファイル」は自分が最後に使ったものであって、今から触りたい環境とは限らない。 具体的にどうまずいか。既定でアクティブなのが別テナント（たとえば他社の業務で使っているアカウント）で、その既定環境が相手の実業務環境だったとする。そこへ --force-overwrite を含む import が飛ぶ。 宛先を書くことが、唯一の防御になる。 --environment を書けば安全か書いても足りない。 --environment が守るのは宛先だけで、使われる資格情報はアクティブな認証プロファイルのままだからだ。宛先だけ正しくても、身元が別テナントのアカウントなら拒否される。 守るべき軸は2本ある。 軸 何を決めるか 守り方 宛先 どの環境へ行くか --environment を必ず書く 身元 誰として繋がるか その環境に対して正しいプロファイルを選ぶ 片方だけでは足りない。 宛先を書き忘れれば別の環境へ行き、身元を選び忘れれば拒否される。後者はまだ幸運で、拒否されれば気づく。 Azure CLI は、さらに別の身元を持っているDataverse（Power Platform のデータ基盤）の Web API を直接叩くとき、アクセストークンを Azure CLI から取ることがある。 $tok = (az account get-access-token --resource $OrgUrl --query accessToken -o tsv) このトークンは Azure CLI 側でアクティブなアカウントのものだ。pac の認証プロファイルとは何の関係もない。 同じスクリプトの中に pac solution export と az account get-access-token が混在していると、前半と後半で別の身元が使われることになる。両方のCLIに同じアカウントでサインインしていれば一致するが、複数テナントを持っていると一致している保証はどこにもない。 ...

SharePoint の「プロンプト集」フォルダを開く。 最終更新日は 8 ヶ月前。投稿者の名前は、すでに別の部署に異動している。 「使えるかもしれない」とクリックしたプロンプトの説明文には、退役済みのモデル名が書いてあった。 Teams のチャットを立ち上げて、「誰かこの業務で使えるプロンプト持ってませんか」と打つ。 こういう経験が、1 度や 2 度ではない人は多いはずだ。 1. 3 年分の蓄積が、なぜ一晩で使えなくなるのか具体的な場面を想像してほしい。 あなたのチームが、3 年かけてプロンプトを積み上げたとする。毎月の定例でメンバーが持ち寄り、担当者が週 2 時間を費やして整理した。200 件に達したとき、「ナレッジ資産」として経営報告に記載された。 2026 年 2 月、OpenAI が GPT-4o の退役を発表した。リリースからわずか 21 ヶ月だった（OpenAI 公式）。 GPT-4o 特有の挙動——長めのシステムプロンプトで安定する、特定の言い回しで精度が上がる——に最適化されたプロンプトは、次世代モデルで同じように動かない。GPT-4.1 は GPT-4o より「指示に文字通り忠実に従う」設計に変わったため、同じプロンプトでも挙動が変わることが OpenAI のプロンプトガイドに明記されている。200 件のうち何件が影響を受けるか。1 件の再テストに 30 分かかるとすれば、100 件で 50 時間だ。これが 1 回のモデル交代で発生する。 もし最初から「動作確認日」と「対象モデル」の 2 列をテンプレートに設けていたなら、どうなっていたか。 モデル更新のたびに「この日付より前・このモデル向けのプロンプト」として絞り込める。全件再テストの代わりに、影響範囲の特定から始められる。「GPT-4o の退役が出た。確認が必要な候補は 18 件」——そう絞り込める設計になっていれば、50 時間が 9 時間になっていた。差の 41 時間で、チームは次の業務自動化に着手できていた可能性がある。 「ポータルがある組織」と「ポータルが機能している組織」の差は、設計前の一手で生まれる。 2. ナレッジが腐る構造は、AI に限った話ではないAI ポータルの形骸化は AI 固有の問題に見えるが、ナレッジ管理全般の失敗パターンと重なる部分が大きい。 ナレッジ管理施策の 55% は変革管理の不足や経営層のサポート不足で失敗する（Helpjuice「Knowledge Management Trends and Statistics in 2025」2024-25 年）。能動的な管理がなければ、ナレッジベースの 20〜40% は無関連・陳腐化コンテンツを含むようになる（同調査）。デジタルワーカーの **47% が「業務上必要な情報を見つけるのが困難」**と感じる（Gartner 2023 年調査、二次引用）という実態は、「溜まってはいるが使えない」状態が広く常態化していることを示す。 ...

「ローコードでどこまでやれるか」——その境界は難しいかどうかではなく、操作の種類で決まる。行の作成・更新・読み取りはローコードの射程内。多対多の関連付け（所属・権限割り当て）だけは、通常のローコード操作では届かない。Patch 関数での直接書き込みは構造的に不可で、専用の Relate アクションを使うにはプレミアムライセンスと制限の確認が前提になる（2026 年 7 月時点）。 難易度ではなく、操作の種類で境界を引くPower Platform で業務ロジックを組むとき、ほとんどの処理はローコードで通る。Patch 関数でレコードを作成・更新し、Filter 関数で読み取り、条件分岐で制御する——これは難易度の問題ではなく、標準の道具が揃っているということだ。 壁になるのは多対多の「繋ぎ」だ。 比喩にすると：付箋に文字を書く・書き直す・読むことは自在にできる。このカードとあのカードを糸で結ぶ——多対多の関連付け——だけは、道具箱に入っていない。 Dataverse（マイクロソフトのクラウドデータプラットフォーム）の多対多関係には交差テーブル（junction table：テーブル間の関連を管理する中間テーブル）が存在するが、Canvas Apps の Patch / Collect 関数からは内部管理テーブルとして直接露出していない。Microsoft Learnのドキュメントには “the intersecting table is not available to use directly”（交差テーブルは直接使用できない）と明記されている。 操作 種類 Patch / 標準アクション直書き 専用の Relate 手段 レコードを作る / 直す 行の作成・更新 ○ — 階層の追従・廃止判定 行の更新・読み取り ○ — 所属させる 多対多の繋ぎ ✕ △（ライセンス・制限あり） 権限を割り当てる 多対多の繋ぎ ✕ △（ライセンス・制限あり） 覚え方：作れる・直せる・読める。ただ、繋げない（通常操作では）。 「できない」と「制限付きで可能」は別の話Patch 以外の手段として、Relate / Unrelate という専用の関数・アクションが用意されている。ただし、使える範囲は限られている。 手段 ステータス ライセンス要件 主な制限 Power Automate：Relate rows / Unrelate rows GA（正式版） Power Automate Premium フロー経由のみ Canvas Apps：Relate / Unrelate 関数 Preview（2024 年 3 月時点） Power Apps Premium オフライン非対応・フラグ有効化必要 Patch 関数で交差テーブルに直接書き込む 不可 — 構造的制約 設計判断として押さえておきたいのは 2 点。 ...

APIキーや署名鍵をローカルに置くほど、守るべき対象は増え、管理は難しくなる。 専用の保管サービス（以下「金庫」）に移すと、守るものが「秘密の値そのもの」から「誰が触れるか（権限）」へ変わる。 懸念は消えない。より守りやすい場所へ移動する。それが金庫導入で起きる設計上の変化だ。 手元保管の4弱点APIキーや認証トークンをローカル（.envファイル・ソースコード・PCのテキストファイル等）に置くことは、直感的には「手元にあるから安全」に見える。構造上は逆だ。 弱点 内容 複製が散る コード・設定ファイル・ドキュメントに貼るたびに同じ値が複数箇所に存在する 回収不能 一度コミット・共有した秘密は完全には回収できない 追跡不能 「誰がいつ使ったか」を後から確認する手段がない 失効不能 漏洩を疑っても、鍵の更新（ローテーション）の影響範囲が掴めない NIST SP 800-204（Security Strategies for Microservices-based Application Systems、2019年）は「トークンのシークレットキーはライブラリコードに含めてはならない。キー値はデータボルトソリューションに保管すべきである」と明記している（出典PDF）。 NSA/CISA「Defending CI/CD Environments」（2023年6月）も「パイプライン内のいかなる箇所でもシークレットをプレーンテキストで渡してはならない」と規定し、IaCテンプレートへのアクセスキーのハードコードをリスク事例として明示している（出典PDF）。 CISA/FBI「Product Security Bad Practices」v2（2025年1月）は「ソースコード内にハードコードされた認証情報は国家安全保障・経済安全保障・公衆衛生に対するリスクを著しく高める」と踏み込んでいる（出典PDF）。 複数の独立した公的ガイドラインが同じ結論に至っている。「ローカルに持つほど弱くなる」は直感と逆だが、構造的に正しい。 金庫が変えること：守る問いの場所が移動する専用保管サービスを導入すると、秘密の値を日常的に扱う必要がなくなる。代わりに「誰がこの金庫を開けられるか」という権限の管理が日常の守り方になる。 NIST SP 800-57 Part 1 Rev.5（Recommendation for Key Management、2020年5月）は「鍵を暗号境界の外部にプレーンテキスト形式で保管してはならない」原則を規定しており、同文書は鍵のライフサイクル全体（生成・配布・保管・更新・廃棄）を通じた保護要件を定めている（出典PDF）。「廃棄」が含まれている点が重要で、権限（アクセスポリシー）には取り消し・有効期限設定が存在する。ローカルの平文ファイルにそれはない。 守る対象が変わると、何が実現できるか。 ローカル保管：秘密の値を守る → 値が散らばり追跡・失効が困難 専用金庫：金庫を開ける権限を守る → 権限は集中管理でき、取り消し・更新がしやすい Azure Key Vault はすべての認証済みREST API呼び出しを AuditEvent カテゴリとして記録する（ログ仕様）。AWS Secrets Manager は CloudTrail 経由で GetSecretValue・CreateSecret・DeleteSecret 等の操作を記録する（CloudTrail統合）。「誰がいつ金庫を開けたか」を後から確認できる状態は、ローカル保管では再現できない。 秘密管理とは、守る問いをどこに置くかの選択だ。 ただし、金庫が保護するのは「保管中」と「取り出す瞬間まで（API輸送中）」に限定される。取り出した後のAPIキーの平文（生の値）は金庫の管轄外だ。AWS CloudTrail の仕様も「ログ内にシークレット値は含まれない」と明示している——取り出した後の使われ方は追跡対象ではない。この限界があるからこそ、「人が直接鍵を取り出さない（後述のManaged Identity）」方式が推奨される設計になる。 設計で詰めるチェック3点金庫を導入した後、以下3点を確認しないと設計が片手落ちになる。 1. 監査ログを有効化したかAzure Key Vault の AuditEvent ログはデフォルト無効だ。診断設定から手動で有効化しないと「誰がいつ開けたか」が記録されない（設定手順）。 ...

Dataverseで階層アクセス制御（BU単位でのデータスコープ設定）を設計すると、セキュリティロールの行数が数万〜十万に膨らむことがある。 管理できないと感じた場合、数え方が違っている可能性が高い。実際に管理すべきは行数ではなく、定義の数——より正確には RoleTemplate（ロール定義の実体エンティティ）の数だ。 BU（Business Unit：ビジネスユニット、組織単位）がいくつ増えても、RoleTemplate は一セットだけ存在する。行数が膨らんでも、管理対象の定義数は環境規模にかかわらず百数十件の範囲に収まる。 なぜ行数が「BU数×定義数」に膨らむのかDataverse のセキュリティロール（特定のテーブルへの操作権限をまとめた権限グループ）は、BU ごとに個別の行として発行される仕組みになっている。BU が 10 あり、ロール定義が 20 あれば、行数は 200 になる。BU が数十〜数百規模の組織では、行数が数万を超えることも珍しくない。 Microsoft の公式ドキュメント（Security roles and privileges、2024 年更新）には次のように明示されている。 “A security role can exist in the root business unit (BU) and replicated to different BU’s, and therefore the role ID is not unique across environments.” Dataverse は内部で Role エンティティ（行として BU ごとに複製される側）と RoleTemplate エンティティ（ロール定義の実体）を分離して設計している。この二層構造が行数の爆発を生む一方で、管理の複雑さを大幅に抑えてもいる。 複製された行が「空の殻」とはどういう意味か複製された Role 行が格納しているのは次の 3 点だけだ。 格納情報 内容 roleId この行固有の識別子（BU ごとに異なる GUID） BusinessUnitId この行がどの BU に属するかの参照 roleTemplateId どの RoleTemplate を参照するか（全環境・全 BU で固定の GUID） 権限の中身——どのテーブルへの読み書き・削除が可能か、という情報——は Role 行に存在しない。それは参照先の RoleTemplate が保持する。 ...

Dataverse でビジネスユニット（BU：データレベルの境界を形成する組織区画）を「無効化」しても、配下ユーザーの権限は一つも切れない。累積加算式のアクセスモデルでは、ロールを明示的に除去しない限り有効な権限として機能し続ける。廃止設計における「無効化」と「権限剥奪」は、独立した 2 工程だ。 無効化フラグの正体——アクセス評価に参加しない状態変数Microsoft の公式ドキュメント（delete-business-unit.md、2026 年確認）は無効化の効果をこう記述する。 “All users and teams associated with the business unit or child business units won’t be able to sign in.” 遮断されるのは「サインイン」だ。セキュリティロールは削除されない。 Dataverse のアクセスモデルは累積加算式で構築されている（Security concepts in Dataverse）。 “all privilege grants are accumulative with the greatest amount of access prevailing” 複数ロールを持つユーザーはすべての権限の和を持つ。無効化フラグはこの評価ロジックの外にある。BU が無効になっても、配下ユーザーのロールは削除されず、アクセス評価エンジンはそのロールを有効として扱い続ける。 無効化とは表示上の印であり、アクセス制御のスイッチではない。 この構造は公式ドキュメント自身が示している。BU を削除する前の手順として「ユーザーとチームを別の BU に移動し、セキュリティロールを再割り当てせよ」と指示していること自体が、無効化操作だけではロール除去が起きないことを前提にしている。 無効化後に通ってしまう操作以下は Dataverse 開発者テナントを用いた検証環境での確認結果だ。公式ドキュメントに明示された記述は見つかっておらず、実測を根拠とする記述であることを最初に断る。 無効化済みの BU 配下に対して次の操作を確認した。 操作 確認結果 配下 BU への新規メンバー追加 完了（セキュリティロール付きで追加できる） 配下 BU を所有者とするレコード作成（Dataverse Web API 経由） 完了 配下 BU の下に子 BU を新規作成 完了 ロールが残存している限り、権限評価はフルに機能する。無効化フラグが権限評価エンジンに影響を与えていないことが、こうした動作を可能にしている構造だ。 ...

フラットな 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 は遅い」という印象は比較対象次第だ。 ...