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 を新規作成完了

ロールが残存している限り、権限評価はフルに機能する。無効化フラグが権限評価エンジンに影響を与えていないことが、こうした動作を可能にしている構造だ。

実効ある剥奪操作は 2 つのみ

権限を確実に切る操作は以下の 2 つだ。

操作手順反映
ロール除去Power Platform 管理センター → セキュリティロール → メンバー → 削除（Assign security roles）即時
メンバーシップ除去グループからユーザーを削除（Control user access）即時

Microsoft Learn「Control user access」より：

“When users are removed from the group, they’re disabled in the environment.”

グループからの除去と同時にアクセスが失効する。これが唯一の確実な操作だ。「無効化すれば権限も切れる」という前提は、Dataverse の累積加算式アクセスモデルと合わない。

M365 Developer Tenant に Dataverse 環境を持っているなら、ロール除去とメンバーシップ除去をそれぞれ実行して即時反映を確認できる。廃止手順のテンプレをここで作っておくと、次の案件での設計判断が速くなる。

→ 関連記事：Power Platform 認可設計：そのアプリが消えても残る環境×グループ 3 層の分け方

廃止の連鎖順序と明示工程設計

廃止時の操作順序は、システムの拒否理由が規定する。

1. 引き取り：レコード・所有物を別の BU に移動
   （BU 内にレコードや子 BU が残っていると削除できない——システムが強制する手順）
2. 剥奪：ロール除去 + メンバーシップ除去
   ★ここだけシステムが自動で実行しない
3. 確認：メンバー・ロール紐付けが残っていないことを確認
4. 無効化：一時的な非表示（省略可）
5. 削除：BU の物理削除

「引き取り」はシステムが削除を拒否することで強制される。「削除」も残余リソースがある限りシステムが通さない。しかし「剥奪」だけはシステムが守ってくれない。廃止設計書に「失効工程」として明示しない限り、この手順は抜け落ちる。

走査コストと可視性の残存コスト

剥奪対象のロールとメンバーシップを全件洗い出すコストは、設計者が事前に織り込む必要がある。「この BU のメンバー全員が持つロールの一覧」を一度に出力する公式ツールは 2026 年時点では確認できていない。環境が大きくなるほど、走査・確認の工数が廃止作業全体の中で無視できない比率を占める。

設計を見直す機会があるなら、Modernized Business Units（2023 wave 2 で GA 済み・新規環境ではデフォルト有効）はレコードの所有権が BU 階層を横断できる設計モデルだ。廃止時の構造的な複雑さを減らす選択肢として検討できる（参照：Release Plan 2023wave2）。

まとめ

廃止設計において無効化と権限剥奪は独立した工程であり、失効工程を設計書に明示しなければ過剰権限は残り続ける。

次の一歩

  1. 廃止対象 BU のメンバー一覧とロール割り当てを Power Platform 管理センターで確認する
  2. 廃止設計書の手順に「ロール除去」「メンバーシップ除去」を独立ステップとして追記する
  3. Modernized Business Units の有効化状態を確認し、設計見直しの要否を判断する

関連記事