Dataverse で担当者別表示を作るとき、フィルターより先に整理すべき3つのID

「担当者ごとに見え方を変えたい」という要件が来たとき、最初にフィルター条件を書き始めると詰まる。
Dataverse は毎クエリ、ログイン時のトークン情報から「あなた」に対応する内部ユーザーを自動で特定し、レコードの持ち主と突き合わせて表示範囲を決める。
作り手がやるべき準備は、ログインする人とレコードの持ち主を正しく結びつけることだけだ。

3つのIDを整理する

Dataverse の担当者管理を理解するには、3種類のIDを別物として扱う必要がある。

1. ログインID（Azure AD Object ID）

Entra ID（旧称 Azure Active Directory）がログイントークンに乗せる識別子。azureactivedirectoryobjectid という列名で Dataverse の内部に保持される。ユーザーがアプリを開いた瞬間、このIDがトークンの中に含まれている。

2. 内部ユーザーID（systemuserid）

Dataverse 環境内部で割り当てられるGUID（グローバル一意識別子）。レコードの ownerid（所有者）欄に実際に入るのはこのIDだ。外部システムには存在しない、Dataverse 固有の識別子になる。

3. 職場アカウント（UPN / domainname）

[email protected] 形式の文字列。Dataverse では domainname 列として保持される。人間が読める識別子だが、文字列なのでそのままでは Lookup（関連テーブルへの参照）として機能しない。

この3つを混同して設計すると、データ取込時に ownerid がnullになったり、フィルターを書いても動かない状態が発生する。

利用者登録が3つのIDを橋渡しする

3つのIDをつなぐ場所は1か所だけ、systemuser（SystemUser テーブル）だ。

Microsoft Learn のシステムユーザーテーブル定義（2024年–2026年）によると、このテーブルの1レコードには次の3列が同居している。

M365 管理センターや Entra ID との同期で利用者を登録すると、この1レコードに3つのIDが書き込まれる。橋は1か所だけで完結する。逆に言えば、この連携が成立していないと——たとえばユーザーが未登録だったり、UPNが変更されて不一致になっていたりすると——後続のすべての処理が機能しない。

毎クエリ自動で突き合わせる（フィルターを書かない）

Power Apps のモデル駆動型アプリや Dataverse Web API にリクエストが来るたびに、Dataverse サーバーは次の処理を自動で実行する。

トークンの azureactivedirectoryobjectid
  → systemuser テーブルの azureactivedirectoryobjectid 列で照合
  → systemuserid（内部 GUID）を解決
  → レコードの ownerid と突き合わせ
  → 行レベルセキュリティを評価

セキュリティロールの深度が「User（Basic）」に設定されている場合、ownerid がログインユーザーの systemuserid と一致するレコードだけが返却される。この評価は画面・API・Power Automate のすべてに共通して適用される（Microsoft Learn「Security concepts in Microsoft Dataverse」）。

つまり、「担当者別に表示を変える」ために独自のフィルター条件を書く必要はない。ownerid を正しく設定し、ロール深度を User（Basic）にしておけば、Dataverse が毎回自動で絞り込みを実行する。

なお、ロール深度には User / Business Unit / Parent:Child / Organization の4段階がある。この深度設計の詳細は、関連記事「Dataverse のビューフィルターはアクセス制御ではない——ロール深度×BU 構造で守り、API で壊して確かめる」で扱っている。

取込時はUPN（文字列）のみ運ぶ——後工程でID解決する

外部システム（基幹システムや Excel）から Dataverse にデータを取り込む際、systemuserid（GUID）は外部には存在しない。外部システムにあるのは担当者のメールアドレス（UPN 形式の文字列）だけだ。

正しい手順は2段階になる。

ステップ1：取込時はUPN文字列を別列に格納する

取込ジョブでは担当者の UPN を一時列に格納する。この時点では ownerid は設定しない（または空のまま）。

ステップ2：後工程でdomainname照合 → systemuserid解決 → owneridに設定する

systemuser テーブルの domainname 列を照合キーとして使い、対応する systemuserid を取得する。取得した GUID を ownerid に設定して完了だ。

GitHub MicrosoftDocs の systemuser.md（2024年–2026年）では、domainname 列が「データインポート時の ownerid 解決の照合キー」として公式に記述されている。この2段階手順は設計上の正規ルートだ。

解決が失敗しうるケース

後工程のID解決は静かに失敗することがある。設計の一部として確認手順を組み込む必要がある。

ケース1：未登録ユーザー

取込時点で Dataverse に登録されていないユーザーの担当レコードは、ownerid が null のまま取り込まれる。取込ジョブ自体は成功扱いで完了するため、この状態は後から気づきにくい。

ケース2：UPNの名称変更

Entra ID でUPN（メールアドレス）が変更された後、Dataverse の domainname 列が更新されるタイミングは同期スケジュールに依存する。変更直後は systemuser.domainname と外部システムのメールアドレスが不一致になり、照合が失敗する可能性がある（Microsoft Learn「Create users」）。

どちらのケースも、取込ジョブが「成功」として終わるため発見が遅れやすい。この挙動は複数のコミュニティ事例で報告されている。対処として、後工程で ownerid が null のレコードを検出するクエリを確認ステップとして組み込んでおく。

4場面の比較表

設計時に確認すべきチェックリスト

M365 Developer Program（Microsoft 365 Developer Program）で取得できる個人用の無料検証テナントがあれば、これらの確認を顧客環境とは切り離して実施できる。

まとめ

Dataverse の担当者別表示は、フィルターを書く問題ではなく、3つのID（azureactivedirectoryobjectid・systemuserid・domainname）の橋渡し構造を正しく準備する問題だ。ログインユーザーの解決からレコードの所有者突き合わせまで、Dataverse が毎クエリ自動で処理する。作り手の仕事は ownerid を正しく設定する準備だけ。

次の一歩

1. Power Platform 管理センターで、対象テーブルの所有権タイプを確認する（User or Team owned かどうか）
2. Dataverse の systemuser テーブルを開き、担当者全員のレコードと domainname 列を確認する
3. 取込後に ownerid is null のレコードを検出するクエリを作成し、確認ステップとして組み込む

関連記事

• Dataverse ビューフィルターの裏側——ログインユーザーのデータだけ表示される3段クエリ処理の全体像（担当者フィルターの内部動作と FetchXML 3段クエリの詳細）
• Dataverse のビューフィルターはアクセス制御ではない——ロール深度×BU 構造で守り、API で壊して確かめる（ロール深度 User/BU/Parent:Child/Org の設計）
• Dataverse 代替キーで Lookup を張る——取込時正規化と親→子ロードオーダーの作法（取込時の Lookup 変換の詳細手順）

参考

• User (SystemUser) table/entity reference — Microsoft Learn
• Security concepts in Microsoft Dataverse — Microsoft Learn
• Create users — Microsoft Learn