アプリごとに権限を作り込む設計は、アプリが廃止・移行された瞬間に価値を失う。組織改編のたびにアクセス権を全件触り直すのは、うっかりではなく構造の問題だ。
結論を先に置く。セキュリティ境界は環境（Environment）であってアプリではない。グループを「組織の写し」と「使ってよい人の束」の 2 家系に分離すれば、アプリが増減しても土台は揺らがない。
前提の明記：本記事が扱う「環境」は Power Platform の Environment を指す。Dataverse を持つ環境が前提であり、SharePoint リスト単体や Teams タブアプリのみの構成では環境設計の条件が異なる。
境界はアプリではなく環境
Microsoft の公式ドキュメント「Security in Microsoft Dataverse」（2026 年）には次の一文がある。
“Environments act as security boundaries allowing different security needs to be implemented in each environment.”
環境がセキュリティ境界として機能するという明示的な表明だ。さらに「Power Platform environments overview」（2026 年）はアプリとデータの関係を次のように規定する。
“When you create an app in an environment, that app is only permitted to connect to the data sources that are also deployed in that same environment.”
アプリが参照できるデータは同じ環境内に限られる。ただし、アプリの UI を通らなくても API（コネクタ・Dataverse Web API 等）経由でアクセスできる。アプリを壁として扱うと、API という窓から入られる。
認可設計の本質は、混ぜてはいけない層を分けることだ。
環境の区切り方：部門単位では再利用できない
環境を「営業部環境」「経理部環境」のように部門単位で区切ると、組織改編のたびに環境レベルから揺れる。環境は一度作ると変えにくい。
Microsoft の設計パターンが示す判断軸は「データ領域・機密単位」だ。同じデータを使うアプリは同一環境に同居させ、アプリが増減しても環境レベルのデータ境界を安定させる。
| 区切り軸 | 安定性 | 再利用性 |
|---|---|---|
| 部門単位 | 低（組織改編で揺れる） | 低 |
| データ領域・機密単位 | 高 | 高 |
Dataverse 内では Business Unit（BU：データレベルの境界を形成する組織区画の概念）が環境の下に位置する。「Security in Microsoft Dataverse」（2026 年）は環境・BU・ロールの多段構造を明示している。環境 → BU → ロールの順に設計を積み上げるのが前提だ。
グループは 2 家系で管理する
セキュリティグループの設計で最初に決める分離が 2 家系だ。これは筆者が整理した分類で Microsoft の術語ではない。Dataverse グループチームの実装動作を根拠に導いた設計判断として読んでほしい。
構造グループ（組織の写し・恒久資産）
組織ツリーを写したグループ。「東日本営業チーム」「物流管理部門」のように組織構造に対応する。アプリの都合を持ち込まない。組織改編時に変えるのはここだけ。
エンタイトルメントグループ（使ってよい人の束）
「受発注アプリ利用者」「在庫閲覧許可ユーザー」のようにアプリ・機能の利用資格をまとめたグループ。構造グループをメンバーとして内包する。アプリが廃止されれば、エンタイトルメントグループだけを削除すればよい。構造グループは残る。
この分離により、アプリの都合が組織構造のグループを汚染しなくなる。
グループチームのロール割り当て：メンバー権限継承の落とし穴
Dataverse でグループチームにロールを付与する場合、メンバー権限継承（Members’ privilege inheritance） の設定を見落とすと意図しない動作になる。Microsoft Learn「Manage group teams」（2025 年）より：
| 設定 | レコード所有者 | 補足 |
|---|---|---|
| あり | ユーザー個人 | チームメンバーが自分を所有者としてレコードを作成できる。追加ロール割当不要。 |
| なし | チーム | 個人所有レコードが必要な業務では、別途直接ロール割当が必要になる。 |
「なぜレコードの所有者がチームになっているのか」という疑問の多くは、この設定の見落としから来る。
グループ粒度：細かく切って上に合成する
グループ粒度の原則は「粗く始めない」だ。「営業部グループ」のような粗い粒度は後から細かく切れない。小さく作り、上位グループに合成して大きな単位を表現する。
避けるべきパターン：役職名でグループを作る
「課長以上」「部長権限」は昇格・異動・役職廃止のたびに壊れる。役職名はアクセス権の正体ではなく、組織の便宜上の呼び名にすぎない。
推奨パターン：BU 階層 × ロール粒度の写像
「東日本営業チーム × レコード参照のみ」のように BU 階層とロール粒度の積で定義する。役職が変わってもグループは変わらず、メンバーを付け替えるだけで済む。
役職名によるアクセス設計の具体的な崩れ方については、関連記事「役職名でアクセスを設計すると例外で壊れる」を参照してほしい。
3 つのゲートを層として分離する
Power Platform / Dataverse のセキュリティは「入場」「行」「列」の 3 ゲートで構成される。「Security in Microsoft Dataverse」（2026 年）は環境レベル・レコードレベル・フィールドレベルの多段設定を明示している。
| ゲート | 制御対象 | 絞るべき内容 |
|---|---|---|
| 入場（環境） | 環境に入れるか | 環境ロール（Environment Maker / Basic User 等） |
| 行（レコード） | 対象データを扱えるか | チーム・所有権・BU 階層 |
| 列（フィールド） | 機密フィールドを見られるか | フィールドセキュリティプロファイル |
各ゲートを本来の役割に絞ることが設計の規律だ。入場ゲートでやるべき制御を行ゲートで代替しようとすると、設計が複雑になり監査の説明で詰まる。
行の強制とビューフィルターの混同については、関連記事「ビューフィルターはアクセス制御ではない——Dataverse の行権限設計」で詳しく扱っている。
設計前に確認する 3 つの留保
動的グループのライセンス条件
Entra ID の動的メンバーシップグループ（属性でメンバーを自動追加するグループ）を使う場合、ライセンス要件がある。Microsoft Learn「Manage rules for dynamic membership groups in Microsoft Entra ID」（2025 年）より：
“The feature of dynamic membership groups requires a Microsoft Entra ID P1 license or an Intune for Education license for each unique user who’s a member of one or more dynamic membership groups. You don’t have to assign licenses to users for them to be members of dynamic membership groups, but you must have the minimum number of licenses in the Microsoft Entra organization to cover all such users.”
個人への割り当ては不要で、組織全体の P1 ライセンス保有数がユニークメンバー総数以上であればよい。動的グループのメンバーが 1,000 人なら、組織に P1 ライセンスが 1,000 本以上必要になる。なお、デバイスグループはライセンス不要（ユーザーグループとは別扱い）。
連携アカウント（機械 ID）の過剰権限
フロー連携用のサービスアカウント（ユーザー ID 形式）は Microsoft が非推奨としている。Microsoft Learn「Support for service principal owned flows」（2025 年）：
“Service accounts (user identities) are not recommended as a best practice. Where service accounts are used to remove dependency on the original flow owner, the guidance is to use a service principal instead to mitigate security risks.”
サービスアカウントは通常のユーザーと同じ権限セットを持つため、最小権限の原則が崩れやすい。自分の検証では、配送処理用に設定した連携アカウントが想定以上の権限を保持していたケースを確認している。サービスプリンシパル（非ヒューマン ID）への移行が、最小権限原則の観点で正しい方向だ。
最小権限ロールの作成コスト
最小権限のカスタムロールをゼロから作ると相応の設計コストがかかる。標準ロールを複製して削ぎ落とす方式は「削ぎ落とし漏れ」が出やすい——権限の組み合わせが多く、構造的に全体を把握しきれなくなるためだ。公式の定量データがある話ではなく、設計上の構造的な難しさとして認識しておく。現実的なアプローチは、標準ロール（Basic User 等）から始め、業務要件が固まった段階でカスタムロールを段階的に追加することだ。
個人テナントで設計パターンを試す
ここまでの判断軸をグループチームの設定や環境ロールの挙動として実際に動かして確認するには、本番環境とは別の検証場所が必要になる。M365 Developer Tenant に検証環境を持っているなら、この 3 層の設計パターンを安全に試せる。テンプレとして蓄積しておけば、次の案件で同じ設計判断を 30 分で再現できる。
→ 関連記事：[Power Platform 個人開発環境の作り方——M365 Developer Program の使い方]（リンク予定）
まとめ
認可設計の耐久性は「アプリ層に権限を作り込まない」という一点から始まる。環境をセキュリティ境界として扱い、グループを 2 家系に分け、3 ゲートをそれぞれ本来の役割に絞る——この分離を守れば、アプリが増減しても土台は揺らがない。
次の一歩
- 自社・顧客の Power Platform 環境一覧を確認し、「データ領域単位」で区切られているか見直す
- 既存セキュリティグループを「構造グループ」と「エンタイトルメントグループ」に分類する棚卸しを 1 時間実施する
- Dataverse グループチームの「メンバー権限継承」設定を現行環境で確認する（Microsoft Learn「Manage group teams」）
関連記事
- [役職名でアクセスを設計すると例外で壊れる]（リンク予定）
- [ビューフィルターはアクセス制御ではない——Dataverse の行権限設計]（リンク予定）
- [Dataverse の owner と owning BU——2 軸で理解するレコードレベル制御]（リンク予定）