実務ハック

役職名をもとにアクセスグループを設計しているなら、例外が増えるたびに設計が崩れていく構造に入っている。 同じ「課長」でも決裁権限が違う人がいる。部門によって「支社長」と呼ぶポジションが、別部門では「部長」と呼ばれる。 この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 の所有者」であるサーバーが担うのが責任分界として自然になる。 ...

Power Automate も Power Apps も Azure Logic Apps も、Dataverse に対しては同じ Web API を叩いている。 「このツールではできない」と止まるとき、問題は API に届いていないことではなく、そのコネクタが必要な機能を露出しているかどうかに 9 割ある。 壁の正体を理解すれば、問い直すべき場所が変わる。 全ツールが同じ API に届いているDataverse の入口は、すべてのツールで共通だ。Power Automate のコネクタも、Power Apps のフォームも、Azure Logic Apps のアクションも、最終的には Dataverse Web API（OData v4 実装） を経由してサーバーと通信する。 この構造は公式ドキュメントで裏付けられている。Dataverse Web API は「Organization service のすべてのメッセージを functions/actions として露出している」（Microsoft Learn: Web API types and operations, 2025 年時点）。コードで直接 Web API を呼べば、サーバーが持つ全操作にアクセスできる。 コネクタの内部も同様だ。「Connectors create a proxy or wrapper around an API that allows the underlying App Service Environment to talk to Microsoft Power Automate, Power Apps, Azure Logic Apps and Power BI」（dev.to/wyattdave: The 4 APIs of the Power Platform）。コネクタは直接の接続ではなく、Azure APIM（API Management）を経由した OpenAPI ラッパーとして機能する。すべてのコネクタホストは、この APIM 経由で同一の Dataverse バックエンドに到達している。 ...

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 を同一視しないこと。 ...

Dataverse のレコードに所有者を設定するとき、「Owner」「Owning User」「Owning Team」「Owning Business Unit」の4欄が並んでいる。 どれを書けばいいか迷ったなら、答えは単純だ。書くのは Owner だけ。残り3つはプラットフォームが自動で埋める。 4欄すべてを手で触ろうとすると、途中でエラーか混乱のどちらかに当たる。 4欄あるが、手を出すのは1欄だけ4欄の役割を整理すると、こうなる。 欄名 役割 書き込み可否 Owner（OwnerId） 所有者の本体。ユーザーまたはチームの ID を指定する 書き込み可 Owning User（owninguser） Owner がユーザーの場合に自動設定される投影 読み取り専用 Owning Team（owningteam） Owner がチームの場合に自動設定される投影 読み取り専用 Owning Business Unit（owningbusinessunit） Owner が属する部署が自動設定される投影 読み取り専用 残り3欄が「読み取り専用」というのは、UI の見た目の話ではない。Microsoft のエンティティ定義レベルで IsValidForCreate: false かつ IsValidForUpdate: false が設定されており、作成・更新操作でこれらの列に値を渡してもプラットフォームが受け付けない（Account table/entity reference — Microsoft Learn）。 自動派生の連動は次のとおり動く（Security concepts in Microsoft Dataverse — Microsoft Learn）： Owner にユーザーを設定 → owninguser が自動更新、owningteam は null にリセット、owningbusinessunit はそのユーザーの部署に自動設定 Owner にチームを設定 → owningteam が自動更新、owninguser は null にリセット、owningbusinessunit はそのチームの部署に自動設定 Owner 1欄を正しく書けば、残り3欄は連動して正しくなる。逆に、残り3欄を直接操作しようとしても何も起きない。 ...