Dataverse のビューフィルターはアクセス制御ではない——ロール深度×BU 構造で守り、API で壊して確かめる

ビューで行を絞っても、Dataverse Web API を直接呼べばそのフィルターは無効になる。
本物のアクセス境界は、レコードの所有者（owner）・所属部門（owningBU）・ロールの深度（User / BU / Parent:Child / Org）の 3 つで決まる。
設計したら、Dataverse Web API を使って意図的に崩してみる。それが境界の実効性を確かめる検証手順だ。

ビューフィルターは化粧であり、アクセス制御ではない

Power Apps でビューを作り、フィルター条件を設定すると、画面上の行は見事に絞られる。「これで見せてはいけないデータが隠れた」と判断するのは自然だ。しかし、それは正確ではない。

ビューのフィルター条件は、画面表示のための設定に過ぎない。Dataverse Web API（REST API）を直接呼び出した場合、ビューのフィルターは引き継がれない。返る結果は、ユーザーのセキュリティロールの深度設定に基づくものになる。ロールが Organization レベル（全件）で設定されていれば、ビューが何を絞っていても、全レコードが取得できる。

Microsoft Learn に明確な記述がある。

“The records that the user can see in the views are still governed by security privileges.”
（ビューで見えるレコードの決定権はセキュリティ権限側にある）
— Microsoft Learn「Security roles and privileges for Dataverse」（2025年12月9日更新）

2025年 Power Platform Release Wave 1 でビューへのセキュリティロール割り当て機能がプレビュー追加された。この機能追加が示す事実は「それ以前はパブリックビューはテーブルへのアクセス権を持つ全ユーザーに表示されていた」ということだ（Microsoft MVP Nishant Rana「Use Security Roles to manage access to views (preview)」2025年4月29日）。つまりビューの絞り込みは、長らくアクセス制御の外側に置かれていた。

API だけが抜け穴ではない。高度な検索・Power Automate のフロー・Excel へのエクスポートといった入口でも、ビューのフィルターは通用しない。画面の見た目を整える設定と、データへのアクセスを制御する設定は、Dataverse では別の場所にある。

Zenity.io の 2025 年の研究では、Service Principal（アプリユーザー）経由の API アクセスでセキュリティグループ制御を回避できることが実証されており、CVE-2025-53004（Common Vulnerabilities and Exposures：公的脆弱性識別番号）として登録されている。外部システム連携を設計する際は、この観点も考慮に入れてほしい。

関連記事：Dataverse ビューフィルターの仕組みと絞り込みパターン

本物の境界を作る 3 つのダイヤル

アクセス制御の本丸は、セキュリティロールに設定する「深度（アクセスレベル）」だ。

Dataverse のセキュリティロールには、テーブルごとに 4 段階の深度を設定できる（Microsoft Learn「Security roles and privileges for Dataverse」2025年12月9日更新）。

この深度設定は、UI・Web API・Power Automate・SDK のすべての入口に対して一貫して適用される。根拠は Microsoft の開発者向けドキュメントにある。

“The Web API provides a RESTful programming experience but ultimately all data operations go through the underlying organization service.”
— Microsoft Learn「Use the Dataverse Web API」

API 経由のリクエストも、画面操作も、最終的には同じセキュリティ層を通過する。UI で絞れているなら API でも絞れているはず、という前提は成立しない。

深度設定の基準になるのが owningBU（所有ビジネスユニット）だ。各レコードには作成時にユーザーのビジネスユニット（BU：組織を部門・支社単位で管理するための区画）が自動で付与される。セキュリティロールの深度はこの owningBU を参照して「誰がどのレコードに触れるか」を決める（Microsoft Learn「Security concepts in Microsoft Dataverse」2025年6月3日更新）。

境界を設計する 3 ダイヤルをまとめると次の通りだ。

1. 誰が所有しているか（owner）：レコードのオーナーがユーザーかチームか
2. どの BU に属するか（owningBU）：レコードが紐づくビジネスユニット
3. どこまで届くか（深度）：ロールに設定した Global / Deep / Local / Basic

この 3 つが揃って初めて、ビューがなくても境界が機能する。

なお、BU 深度設定が Web API にも適用されることを一箇所で明示した公式ページは現時点で特定できていない（Microsoft Learn の複数ページから間接的に確認できる状態）。設計後の実機検証で確かめることを推奨する。

関連記事：所有権タイプ設定ミスが引き起こす落とし穴

役職と深度の翻訳表——設計フェーズで間違いを防ぐ

役職階層と Dataverse のロール深度をどう対応させるか。次の翻訳表は Microsoft 公式で定義されたマッピングではなく、実務設計での判断フレームワークとして整理したものだ。

代理店・チャネル・支社構造を持つ業態（保険・通信・金融・流通）では、この翻訳が設計の出発点になる。

もう一点知っておくべきことがある。複数のセキュリティロールをユーザーに付与した場合、各ロールの深度の和集合（OR）が最終的なアクセス範囲になる。「狭いロールを足したから制限される」は誤解だ。最も広いロールが全体を規定するため、意図せず Organization レベルが混入していれば全件見える状態になる。

設計時に詰めるべきチェックリストを整理する。

設計チェックリスト

「壊して確かめる」2 つの検証手順

設計が終わったら、意図的に崩してみる。壊れなければ本物だ。

検証 1：隠したはずのレコードを API で読む

1. あるユーザー A に Business Unit（Local）のロールを付与する
2. 別の BU に属するレコード B を用意する（A からは見えないはずの状態）
3. ユーザー A の認証トークンを使い、Dataverse Web API で GET /api/data/v9.2/<テーブル名> を呼ぶ（$filter なし）
4. レコード B が返ってこなければ、境界は機能している

返ってきた場合は、ロール設定に Organization レベルが混入しているか、テーブルへの読み取り権限の深度設定が誤っている可能性が高い。

留保：このステップバイステップの手順を公式一次ソースで確認することはできなかった（2026年時点）。実機検証で動作を確かめることを強く推奨する。Zenity.io の 2025 年研究は、API 経由でのアクセス制御迂回を外部研究として実証しており、検証の必要性の裏付けになる。

検証 2：所有者を 1 つわざと間違える

1. ユーザー A（BU-Tokyo に所属）が、BU-Osaka のレコードを意図的に作成する（owningBU を間違える）
2. BU-Tokyo の Local ロールを持つ別ユーザー B から、そのレコードが見えるかを確認する
3. 見えなければ正しい。見えてしまえば owningBU の設定またはロールの深度設定に問題がある

所有者の設定ミスが境界の崩壊に直結することを、このテストで体験的に理解できる。

M365 Developer Tenant（Microsoft 365 Developer Program で取得できる個人用の無料検証テナント）を使えば、この検証を顧客環境を汚さずに実施できる。非機密の検証環境を個人テナントとして持っておくことが、設計精度を上げる最短経路になる。

→ 個人テナントを使った検証環境の全体設計：[Microsoft 365 環境を軸に据えた個人 PC 検証の組み立て方]（リンク予定）

監査基準との対応——ビューフィルターでは証拠にならない

ISO 27001:2022 A.5.15（Access Control）と SOC 2 CC6（論理的・物理的アクセス制御）は、共通して「プラットフォームが強制するロールベースのアクセス制御」と「定期的なアクセスレビュー記録」を証拠として要求する。

ビューフィルターが監査証拠にならない構造的な理由は 3 点だ。

• 誰がいつどのデータにアクセスしたかの監査証跡を生成しない
• API 経由のアクセスを防げないため、「アクセス制御を実施している」証拠にならない
• RBAC（Role-Based Access Control：役割ベースのアクセス制御）マトリクスはセキュリティロールの設定で示す。ビューの設定はここに含まれない

SOC 2 CC6 は特に厳格だ。

“In a SOC 2 Type 2 audit, the auditor looks for operational evidence, not just a policy document.”
— SOC 2 Auditors「SOC 2 CC6 and CC7 Controls」

「ポリシー文書があります」ではなく、「実際に機能しているという証拠」を求められる。

留保：「Dataverse ビューフィルターは ISO 27001 A.5.15 の証拠として不十分」と明示した公式ガイダンスは現時点で確認できなかった。上記は各規格の要件定義から論理的に導出される主張であり、個別の監査要件については担当監査人と確認することを推奨する。

「完全セキュア」とは言わない

技術的な設計が正しくても、「誰がどの BU に属するか」という組織配置が間違っていれば、境界は崩れる。

代理店ネットワークの担当者が異動したとき、その人物の BU 所属が更新されなければ、前の担当先のデータが見える状態が続く。設計の問題ではなく、運用の問題だ。

ISO 27001 A.5.15 と SOC 2 CC6 はいずれも「定期的なアクセスレビュー記録」を要求する。四半期ごとに「誰がどのロールを持ち、どの BU に属しているか」を棚卸しする運用がなければ、技術的な設計がいかに正確でも監査基準を満たせない。

“RBAC alone is not enough; organizations must pair it with periodic reviews, identity proofing, monitoring and separation of duties checks.”
— SOC 2 Auditors「SOC 2 CC6 and CC7 Controls」

組織配置の維持が境界の維持と同義だ。

AI を使った組織データの配送を設計している場合、アクセス制御の構造的分離は特に重要になる。関連記事：鍵を渡さず PII を分離して届ける配送設計

まとめ

ビューで絞ったから守れている、は Dataverse では成立しない。owner × owningBU × ロール深度の 3 ダイヤルで境界を作り、「わざと破る」検証で初めて本物だと確かめられる。設計の完成をゴールにしない——定期的な BU 配置のレビューが境界の維持そのものだ。

次の一歩

1. Power Platform 管理センターで自テナントのセキュリティロールを開き、読み取り権限の深度設定を一覧で確認する
2. 開発環境（または M365 Developer Tenant）で、BU の異なるレコードを API で呼んでみる
3. 定期アクセスレビューのタイミングと担当者を設計に含める

参考ドキュメント（2026年時点）

• Microsoft Learn「Security roles and privileges for Dataverse」
• Microsoft Learn「Security concepts in Microsoft Dataverse」
• Zenity.io「Power Platform Security Access | App User Bypass Warning」

関連記事

• Dataverse ビューフィルターの仕組みと絞り込みパターン
• 所有権タイプ設定ミスが引き起こす落とし穴
• 鍵を渡さず PII を分離して届ける配送設計