Dataverse で owner と owningBU をどう使い分けるか——2語に分けると設計判断が言語化できる

「持ち主を設定したのに課長から見えない」「チームを作るべきか、作らなくていいのか」——この判断がぶれるのは、owner（誰の責任か）と owningBU（どこに属すか）を1本の概念として扱うからだ。
2語に分けるだけで、Dataverse のアクセス制御設計は自分の言葉で説明できるようになる。
そして、純粋な階層要件であれば、チームは必要ない。

owner は名札、owningBU は番地——2語の役割を分けて定義する

Dataverse の行レベルアクセスは、2つの独立したフィールドで動いている。

**owner（名札）**は「このレコードは誰の責任か」を指す。設定できるのは1人のユーザーか1つのチームだけだ。

**owningBU（番地）**は「このレコードはどこに属すか」を指す。owning business unit（所有ビジネスユニット）の略で、常に1つのBU（ビジネスユニット：組織の管理単位。課・部・事業部などに対応させる）に紐づく。

Microsoft Learn「Security concepts in Microsoft Dataverse」（2026年時点）は次のように明示している。

“Data access to records is granted based on the owning business unit.”
— Microsoft Learn: Security concepts in Microsoft Dataverse

アクセスの開口部を決めるのは owningBU であり、owner ではない。ここが混同の出発点だ。

名札（owner）は「誰のものか」という属人的な指し示しであり、番地（owningBU）は「どのBU配下に置かれているか」という場所の指定だ。この2語は別のフィールドとして独立して存在し、別の経路でアクセス評価に効く。

2軸の効き先が違う——名札は本人経路で、番地は階層経路で効く

名札（owner）が効くのは「本人経路」だ。ユーザーが自分自身のsystemuserid（Dataverse内部のユーザーID）と、レコードのownerIdフィールドを突き合わせることでアクセスが成立する。User深度のセキュリティロールがあれば、自分が名札に入っているレコードは見える。

番地（owningBU）が効くのは「階層経路」だ。レコードのowningBUと、アクセスしようとするユーザーのBU位置関係を評価する。セキュリティロールの深度設定がBU以上であれば、owningBUの属するBU内のレコードが見えるようになる。

この2つの評価経路は独立して動く。だから「持ち主が1人（name=担当者）なのに、課長からも見える」という状態が成立する。名札経路は本人しか通らないが、番地経路はBU階層を通して開口部を開けるからだ。

Microsoft Learn「How access to a record is determined」は、チーム所有経路について次のように記述している。

“In both cases, any access level will suffice to have access regardless of the business unit the record belongs to.”
— Microsoft Learn: How access to a record is determined

これはチーム所有の場合の記述だが、名札経路と番地経路が独立して評価されることを示す構造的な根拠になっている。

持ち主が1人なのに課全体が見える——番地の階層経路が効いているから

具体的に整理する。

担当者AさんがレコードXを所有している。owner = Aさんの systemuserid、owningBU = 営業1課のBU。

「なぜ課長から見えるのか」の答えは、Aさんがownerだからではなく、レコードのowningBUが営業1課のBUに設定されており、課長がBU深度の読み取り権限を持っているからだ。

この設計をセキュリティロール深度（User / BU / Parent:Child / Org）で実装する仕様の根拠は、Microsoft Learn「Security roles and privileges for Dataverse」（参照）にある。

名札（owner）と番地（owningBU）を別物として把握していれば、「誰が見えるか」の説明は迷わず言語化できる。

チームは「名札を集合にする」手段——番地の性質は変わらない

チーム（owner team：レコードを所有できる所有チーム）を使うと、名札を1人ではなくチームという集合に変えることができる。レコードのownerIdがチームIDに設定される。

このとき、owningBU（番地）はチームが属するBUに設定される。番地の「常に1つ」という性質はチーム所有でも変わらない。

Microsoft Learn「Teams in Dataverse」は次のように定義している。

“Although a team belongs to one business unit, it can include users from other business units.”
— Microsoft Learn: Teams in Dataverse

チーム自体は1つのBUに属するが、メンバーは複数のBUから参加できる。レコードをチームが所有した場合、そのレコードの番地（owningBU）はチームのBUに設定される。チームメンバーは「チーム所有経路」でアクセスできるため、レコードのowningBUがどのBUでも、アクセスレベルを問わずに届く。

一方、チームのメンバー権限継承（Member’s privilege inheritance）を「Team privileges only」に設定すると、メンバーはそのセキュリティロールについてチームが所有するレコードにしかアクセスできなくなる。

“If the team has the Member’s privilege inheritance set to Team privileges only, then the user will only be able to make use of that privilege for records owned by the team.”
— Microsoft Learn: How access to a record is determined

チームを使う場合、番地（owningBU）が「チームのBU」になる点と、メンバー権限継承の設定が与える影響を事前に確認しておく必要がある。なお、チームのBUを移動させた後に既存レコードのowningBUが追随して変わるかどうかは、2026年時点で公式ドキュメントからの直接確認ができていない。設計時には実機検証を推奨する。

純粋な階層要件ではチームは不要——個人所有＋BU配置で担当から本部まで成立する

重要な判断軸を先に言う。「担当者のレコードを課長が見る、支社長が見る、本部が見る」という純粋な階層要件は、チームなしで実現できる。

構成はシンプルだ。レコードは個人所有（owner = 担当者のユーザー）、番地（owningBU）は担当者の所属BUに設定、ロールの深度を役職に合わせて設定する。それだけで担当 ≤ 課長 ≤ 支社長 ≤ 本部の階層アクセスが成立する（Microsoft Learn「Security roles and privileges for Dataverse」参照）。

チームを加えると、owningBUがチームのBUに変わり、メンバー権限継承の設定が絡み、設計の複雑度が上がる。階層要件しかない場面でチームを使うと、後から理由を説明できなくなるケースが出てくる。

チームが要るのは例外のみ——複数人担当・受け皿・越境共有の3ケース

チームが必要になるのは次の3ケースだ。

1. 複数人担当
1件のレコードに対して「担当者」を1人に決められない場合。owner teamにすることで名札をチームという集合に変えられる。

2. 受け皿
担当者が決まる前、または担当者が異動した後の一時的な所有先として機能させる場合。レコードを個人に割り当てるまでのバッファとして使う。

3. 越境共有
自分のBU外のユーザーに、BU階層を経由せずにアクセスさせたい場合。チームはBUをまたいでメンバーを集められるため、BU階層ではつながらない相手へのアクセス付与に使える。

これら3ケース以外でチームを使うと、設計の複雑度が上がる割に、個人所有＋BU配置で達成できていたことと変わらなくなる。

なお、Modernized BU（モダナイズドビジネスユニット：ユーザー自身のBUでなくレコードのowningBUがアクセスの主軸になるモード）ではレコード作成時にowningBUを明示選択できるが、このモードでのチーム所有時のowningBU挙動については2026年時点で公式ドキュメントからの直接確認が取れていない。Modernized BUモードを採用する場合は、上記の設計論の適用範囲を事前に実機検証で確認することを勧める。

まとめ

owner（名札）は「誰の責任か」、owningBU（番地）は「どこに属すか」——この2語を分けて考えることが、Dataverse のアクセス制御設計を言語化する出発点だ。名札経路と番地経路は独立して動き、それぞれが別の経路でアクセスを開く。だから「持ち主が1人でも課全体が見える」は矛盾ではなく、設計通りの挙動だ。

純粋な階層要件であれば、個人所有＋BU配置＋ロール深度の設定だけで担当から本部まで成立する。チームが要るのは、複数人担当・受け皿・越境共有の3ケースに限られる。これ以外の場面でチームを追加すると、説明コストだけが増える。

次の一歩：まず手元の環境で、任意のレコードの owner と owningBU がどのフィールドに格納されているかを確認する。Power Apps テーブルビューで ownerid と owningbusinessunitid を列に追加するだけで、2軸が独立して存在していることが見える。セキュリティロールの深度設定は管理センター（Power Platform 管理センター）から確認できる。

関連記事：Dataverse で担当者別表示を作るとき、フィルターより先に整理すべき3つのID（ownerに設定されるのは誰か、3つのIDの橋渡し構造）
関連記事：Dataverse のビューフィルターはアクセス制御ではない（ロール深度×BU構造の設計論と検証手順）