実務ハック

「個人 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 のクロステナントアクセス設定には、外部ユーザーのホームテナントが出す「この端末は準拠している」というクレームを信頼するかどうかの選択肢がある。公式ドキュメントの記述はこうだ。 ...

個人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に同じアカウントでサインインしていれば一致するが、複数テナントを持っていると一致している保証はどこにもない。 ...

「ローコードでどこまでやれるか」——その境界は難しいかどうかではなく、操作の種類で決まる。行の作成・更新・読み取りはローコードの射程内。多対多の関連付け（所属・権限割り当て）だけは、通常のローコード操作では届かない。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 は遅い」という印象は比較対象次第だ。 ...

「基幹に持たせよう」という一言は善意で出る。ただし、判断基準が利用者数でも設計の美しさでもないとすれば、何なのか。 答えは一点だけだ。「他システムがそのデータを取り込んで書き足す共有物に育ったかどうか」——これがSoR（System of Record：組織のデータ管理における権威的ソース）への昇格の唯一の引き金だ。この一軸で判断できれば、会議での問いに根拠を持って返せる。 受益者の有無が唯一の判断軸SoRという概念の産業界定義は、Geoffrey MooreとAIIMが2011年に策定した白書が原典だ。「組織の重要マスターデータを管理するトランザクション処理の権威的ソース」——核心条件は、他システムがそのデータを取り込んで書き足す「共有物になっているかどうか」だ。 利用者数・設計の美しさ・担当者の熱意は、この定義に入らない。「月1,000人が参照する」と「他システムから書き込まれる」は別の概念だ。前者はアクセス頻度、後者はデータ所有権の問題だ。 Microsoftの公式参照アーキテクチャ「Synchronize data across Dataverse environments」（2024年）も「一方をプライマリ（権威的ソース）と定め、他はセカンダリ（コピー）として設計する」と明示している。SoRを定めることは自然に決まるものではなく、明示的な意思決定だ。 データ設計の判断とは、受益者を先に確認する作業だ。 2つの取り違えを潰す会議でよく起きる取り違えは2つある。 利用者が多い ＝ 共有物 「多くの部門が参照している」は昇格の引き金でない。読み取り専用の利用がいくら増えても、他システムからの書き込みが発生しなければSoRの条件を満たさない。 コピーを基幹に流す ＝ 正本が基幹に移った 「基幹DBにデータをコピーして同期している」と「基幹が正本（SoR）になった」は別の意思決定だ。どちらが権威的ソースかを明示的に決めなければ、障害時・更新競合時に「どちらが正しいか」の判断がつかなくなる。 Microsoft公式ドキュメント「Data ownership models for synchronization」（2024年、DataverseとBusiness Centralの統合設計）はこう規定している——「どちらかをSoR（正本）と定め、他はコピーとして扱う」。写しがいくら出回っても、正本は動いていない。 昇格に付く4つの恒久コスト昇格を選んだ瞬間から、以下4つのコストが恒久的に積み上がる。 コスト 内容 同期コスト 2システム間のデータを常に一致させるための配管メンテナンス 維持コスト スキーマ変更・バージョンアップのたびに統合コードを更新する工数 責任分界 障害時・更新競合時に「どちらが正しいか」の所管整理（担当部門間の調整） 部門間調整 マスタ変更・スキーマ変更の影響範囲を関係部門と合意し続けるコスト IPAが示す業界慣行では、システム保守費用は初期開発費の15〜20%が目安だ。Fivetranの調査（参考値・商業調査機関）によれば、エンジニア時間の53%がデータパイプライン・統合のメンテナンスに費やされるという。Ampersandの調査（参考値・商業調査機関）では、統合1件あたりの年間保守コストは構築コストの2倍以上に達するとされている。 昇格した日から始まる構造的なコストだ。 受益者がいなければ、コストだけが積み上がる他システムが書き足す受益者がいない状態で昇格すると、便益はゼロのままこれらのコストが恒久的に積み上がる。 経産省のDXレポート（2018年）は「既存システムの集約が必ずしもサイロ化を解消するわけではなく、新たな統合コストを生む」と指摘している。「あった方がいい」という根拠だけで昇格する場合、この指摘は直接当てはまる。 受益者の有無という一軸で判断できれば、「昇格しておけば将来使えるかもしれない」という根拠のない期待を機械的に排除できる。 データ種別で答えが変わるSoR定義（Geoffrey Moore/AIIM 2011）から整理すると、判断が異なるデータ種別が2つある。この判断フレームが主な対象とするのはフロント入力データ（ユーザー入力・業務記録・申請フォームへの回答等）だ。 参照データ（コード表・マスタ等）は、通常すでにSoRが存在している。問いは「どこのSoRから取るか」になる。フロント入力データは「そもそも昇格すべきか」から判断が必要だ。 Microsoftも「バーチャルテーブル（参照のみ）とデータ同期（コピーを持つ）の選択肢」を公式に並べており、どちらが適切かは状況に依存すると示している。この種別の区別を持っておくと、「なぜ基幹に集約しないのか」という問いに対して、まずデータ種別から答えを絞り込める。 → M365 Developer Tenant でのローカル検証環境構築：顧客テナントに時間を吸わせる構造へ、資産を渡すな まとめフロント入力データをSoRに昇格させるかどうかは、他システムが書き足す受益者がいるかどうかだけで決まる。受益者がいなければ、昇格は4つの恒久コストを無償で積む選択だ。 次の一歩：会議で「基幹に持たせよう」と言われたら、まず「そのデータを書き足す他システムが今あるか、3ヶ月以内に現れるか」を確認する。Yesなら昇格を検討する。Noならコピー運用の設計を選ぶ。ただしコピー運用には写しのライフサイクル管理と参照タイムラグの許容範囲の合意が別途必要になる。 関連記事 認可の恒久資産——アプリが消えても残す設計の選択（「アプリが消えても残すか」という引き金の考え方が共通） 取込時の正規化と代替キーLookup——昇格しないと決めたあとの設計 Power Automateで写しを安全に運ぶ疎結合設計

サーバーレス DB は「停止中コストゼロ」が前提だが、監視クエリや接続プールが DB を起こし続けると provisioned（常時起動）より高くつく。課金の主役は保存容量ではなく**起きている時間（計算 vCore）**であり、稼働率が上がるにつれてコストが逆転する構造を持つ。Azure SQL Serverless と Amazon Aurora Serverless v2 の課金構造、稼働率 48% のクロスオーバー試算、keep-alive の正体と監査手順を整理する。 課金の主役は「起きている時間」Azure SQL Database Serverless の課金は vCore 秒（per-second billing）単位で動く。DB が起きている間は vCore単価 × 使用vCore数 が積み上がり、停止中は計算コストがゼロになる。ストレージは起動・停止にかかわらず消費分だけ課金が続くが、実際の PoC 請求を分解すると計算 vCore が約 8 割、ストレージが約 1 割だった。節約効果の大半は「起きている時間を削る」ことで生まれる。 Amazon Aurora Serverless v2 も同じ構造で、$0.12/ACU-hour 課金・停止中は計算コストゼロ。2024 年 11 月からは最小 ACU を 0 に設定できるゼロスケール対応になり、完全停止によるコストゼロが可能になった。 Azure Cosmos DB は別モデル。 消費した RU（Request Unit: データ操作の処理量の単位）の実量に対して課金される（$0.25 / 100 万 RU）ため、接続がなければ RU 消費ゼロ = 請求ゼロとなる。自動一時停止の設定自体が不要で、以降で説明する keep-alive（DB を起こし続ける動作）の問題は Cosmos DB には直接当てはまらない。主軸は Azure SQL Serverless と Aurora Serverless v2 の話になる。 ...

フローが「オン」でも、Dataverse 側の webhook 購読が登録できていなければ、イベントは永久に届かない。実行履歴が空でエラーも出ない場合、ロジックより先に「購読レコードが実在するか」を確かめる。とくにサービスプリンシパル（機械 ID）接続では、業務権限と購読登録権限は独立した別レイヤーにあり、権限不足で静かに失敗する。 「オン」は「購読が開通した」を意味しないDataverse の「行が追加されたとき」などのイベントトリガーは、フローを有効化した時点で Dataverse 側に購読（webhook）を登録しにいく。内部的には ServiceEndpoint テーブル（エンドポイント本体・contract = 8 が webhook を示す）と SdkMessageProcessingStep テーブル（どのテーブル・イベント・ステージで発火するかの設定）の 2 テーブルにレコードが立つ。この登録が成功してはじめて、回線が開通した状態になる。 フローの「オン」表示は、購読の登録成否とは独立して維持される。権限不足で登録が失敗してもステータスは ON のまま残り、エラーメッセージはユーザーに提示されない。Microsoft 公式ドキュメントには次の一文がある。 “Missing permissions or an invalid connection can silently cause triggers to not fire.” （権限不足または無効な接続により、トリガーは静かに発火しない） 結果として、フローは ON のまま実行履歴は空のまま残る。健康診断ツールが「◯日間、一度も実行されていません」と表示するだけで、ログもエラーも出ない。 「フローがオン」と「購読が開通した」は、独立した別の事実だ。 サービスプリンシパル接続で静かに失敗する理由Dataverse コネクタはサービスプリンシパル接続を公式にサポートしている。ただし、この構成では権限の二層構造に注意が必要だ。 サービスプリンシパルを Dataverse 接続として使う場合、Entra ID にアプリ登録を作成し、Dataverse 環境に Application User（Dataverse 側の機械 ID）として追加したうえで、セキュリティロールを割り当てる。このロールに 2 つのレイヤーがある。 レイヤー 内容 典型的なロール 業務データ層 対象テーブルへの読み書き（CRUD） カスタムセキュリティロール プラットフォーム層 購読登録（ServiceEndpoint / SdkMessageProcessingStep の作成） System Customizer / System Administrator 業務データ層の権限だけを付与した Application User は、テーブルへのアクセスはできる。しかし購読の登録は失敗する。この 2 レイヤーは独立しているため、業務ロジックが動作する別の接続で確認済みであっても、機械 ID での購読登録成功を意味しない。 ...