Dataverse のレコードに所有者を設定するとき、「Owner」「Owning User」「Owning Team」「Owning Business Unit」の4欄が並んでいる。
どれを書けばいいか迷ったなら、答えは単純だ。書くのは Owner だけ。残り3つはプラットフォームが自動で埋める。
4欄すべてを手で触ろうとすると、途中でエラーか混乱のどちらかに当たる。
4欄あるが、手を出すのは1欄だけ
4欄の役割を整理すると、こうなる。
| 欄名 | 役割 | 書き込み可否 |
|---|---|---|
| Owner（OwnerId） | 所有者の本体。ユーザーまたはチームの ID を指定する | 書き込み可 |
| Owning User（owninguser） | Owner がユーザーの場合に自動設定される投影 | 読み取り専用 |
| Owning Team（owningteam） | Owner がチームの場合に自動設定される投影 | 読み取り専用 |
| Owning Business Unit（owningbusinessunit） | Owner が属する部署が自動設定される投影 | 読み取り専用 |
残り3欄が「読み取り専用」というのは、UI の見た目の話ではない。Microsoft のエンティティ定義レベルで IsValidForCreate: false かつ IsValidForUpdate: false が設定されており、作成・更新操作でこれらの列に値を渡してもプラットフォームが受け付けない（Account table/entity reference — Microsoft Learn）。
自動派生の連動は次のとおり動く（Security concepts in Microsoft Dataverse — Microsoft Learn）：
- Owner にユーザーを設定 → owninguser が自動更新、owningteam は null にリセット、owningbusinessunit はそのユーザーの部署に自動設定
- Owner にチームを設定 → owningteam が自動更新、owninguser は null にリセット、owningbusinessunit はそのチームの部署に自動設定
Owner 1欄を正しく書けば、残り3欄は連動して正しくなる。逆に、残り3欄を直接操作しようとしても何も起きない。
「Owner テーブルが見つからない」は正常——型であって物理テーブルではない
Power Apps メーカーポータルのテーブル一覧を検索しても、「Owner」というテーブルは見当たらない。これは不具合でも設定ミスでもない。
Owner は、SystemUser（ユーザー）テーブルと Team（チーム）テーブルへの参照を束ねた抽象的な型定義として機能しており、独立した物理テーブルとして存在しない（Owner table/entity reference — Microsoft Learn）。
これを 多態参照（polymorphic lookup） と呼ぶ。1つの列が複数の異なるテーブルを参照できる仕組みで、Owner 列の場合は「ユーザーかチームのどちらか」を指すことができる（Use multi-table lookup columns — Microsoft Learn）。
具体的には、OwnerId 列に参照先の GUID を、OwnerIdType 列に参照先の種別（systemuser または team）を格納する2列セットで成立している。
「Every table in Dataverse includes an Owner column that can’t be removed, you can’t add another, and it always requires a value.」（Microsoft Learn）
テーブル一覧に出ないから「Owner 型の Lookup 列を手で追加する必要がある」と誤解するのは逆で、すべてのテーブルに最初から Owner 列は組み込まれている。
矢印アイコン＝値あり——空に見えるのは描画上の問題
Owner にユーザーを設定したのに、Owning User 欄を見ると名前テキストが表示されず、矢印アイコンだけが見える——という状況に出くわすことがある。
これは「設定できていない」のではなく、値が入っているからこそ矢印（リンク）が表示されている。クリックすれば参照先のレコードに遷移できる。名前テキストが出ない理由は、polymorphic lookup 型の列の描画仕様によるものだ。
ただし、この挙動を明示した Microsoft 公式ドキュメントは2026-06-21時点で確認できていない。ここでの説明は実機観察と Model-driven App の一般的な lookup 描画仕様に基づくもので、公式一次ソースが確認でき次第アップデートする。なお、Power Platform コミュニティフォーラムにも同様の現象を報告するスレッドが存在することは確認している（内容詳細は取得できていない）。
「空だから再入力しよう」と Owner 列を上書きすると、意図しない所有者変更が起きることがある。矢印が見えたら、まずクリックして参照先を確認する。
回り道 vs 正解——4場面の比較表
実装現場で観察されるよくある回り道と、正解操作を対比する。
| # | よくある回り道 | 正解 | 根拠 |
|---|---|---|---|
| 1 | Owning User 欄に直接ユーザーを書こうとして保存がエラーになる | Owner 欄だけ書く。Owning User は自動で埋まる | IsValidForCreate/Update=false |
| 2 | 「Owner」テーブルを Lookup 先として探してテーブル一覧に見当たらず困る | 物理テーブルではないと認識し、OwnerId 列を直接操作する | 多態参照（polymorphic lookup）の型定義 |
| 3 | Owning User 欄に名前テキストが出ず「未設定」と判断して再入力ループに入る | 矢印アイコンはリンク（値あり）。クリックで参照先を確認する | lookup 列の参照描画仕様（実機観察ベース） |
| 4 | データ移行で owninguser 列を直接 PATCH しようとしてエラーになる | OwnerId 列を更新する（ownerid を直接更新するのが現在の公式推奨方法） | IsValidForUpdate=false / AssignRequest は deprecated |
場面4のデータ移行については補足しておく。かつて Dataverse SDK には AssignRequest というクラスが存在したが、現在は deprecated になっている。現在の公式推奨は Web API 経由で ownerid フィールドを直接更新する方法だ（Sharing and assigning — Microsoft Learn）。
所有は一点集中——1つを正しく書けば全部正しい
Owner 1欄だけが書き込み可能という設計は、所有者の情報を「単一の真実の源」に集約する意図がある。owninguser / owningteam / owningbusinessunit はすべて OwnerId から導かれる投影であり、これら3つの整合性は常にプラットフォームが保証する。
ただし、自動派生はあくまで「書いた Owner を正しく展開する」だけであり、誰を Owner にするかの判断を自動化してくれるわけではない。
データ移行や一括インポートでは、ログイン ID（UPN）や表示名から実際の systemuser ID を解決する工程が必要になる。この解決工程の設計が甘いと、意図しないユーザーが Owner になり、行レベルのアクセス制御がずれる。Owner を正しく書くための前段工程として、systemuser の解決方法は別途設計に組み込む。
M365 Developer Tenant（Microsoft 365 Developer Program で取得できる無料の開発用テナント）があれば、こうした所有者の設定挙動を本番環境リスクなしで実機確認できる。
→ 関連記事：Dataverse の Owner とログイン ID はなぜ一致しないのか——systemuser 解決の上流工程（公開予定）
まとめ：Dataverse の所有設定は、Owner 1欄に集中する。残り3欄は手を出さない。これだけで、所有まわりのエラーの大半は消える。
次の一歩：Power Apps メーカーポータルで任意のテーブルのレコードを開き、Owner 欄に自分のユーザーを設定して保存する。Owning User / Owning Business Unit が自動で埋まることを実機で確認する。