Lookup列でテーブルを繋いだのに、チーム共有の要件が出てきた瞬間に設計が崩れる——この問題は、Dataverseで業務アプリを内製化するときに必ず一度ぶつかる。
判断軸は単純だ。「誰と共有するか」が個人（1対1）ならLookup列でいい。組織やチーム（1対多）になるなら、テキストコード突合に切り替える。
この切り替えを設計段階で決めていれば、人員増加も組織変更も無修正で吸収できる。逆に、Lookup列のまま複数人共有を試みると、テーブル構造の手戻りが発生する。
連載の前提知識：代替キー（Alternate Key）の設定と安全なUpsertの手順は、連載第1回「Dataverseの代替キーで安全にUpsertする」で解説しています。本記事はその続きとして、設計判断の軸を扱います。
Lookup列が崩れるメカニズム
Lookup列（検索列）は、Dataverseの公式仕様で次のように規定されている。
All custom lookups can only allow for a reference to a single row for a single target row type.
訳すと「すべてのカスタム検索列は、単一のターゲット行の種類に対して、単一の行への参照しか持てない」。つまり、1つのLookup列に入るのは常に1行だけだ（Microsoft Learn「Column data types in Microsoft Dataverse」2024年）。
Lookup列を使うと、DataverseはN:1（多対一）リレーションシップを自動生成する。「案件テーブルの担当者列 → 社員テーブルの1行」という構造は、担当者が1人固定のうちは問題なく機能する。
問題は、「この案件を3人で担当する」「営業グループ全員が見られるようにしたい」という要件が出たとき。Lookup列は構造上それを受け取れない。1つのセルに複数の行を詰め込む設計は、Dataverseのスキーマが許していない。
なお、メールのToフィールドのような「PartyList型」は複数値を持てるが、これはシステム列の例外扱いであり、カスタム列には適用できない（公式確認済み）。
テキストコード突合の原理
解決策は「直接繋がない設計」に切り替えることだ。
具体的には、双方のテーブルに共通のテキストコード（例：GA001、GA002 といった組織コード）を持たせ、Lookup列による直接結合を使わない設計にする。ビューフィルターでこのコードを照合することで、1対多の共有が実現できる。
たとえば「案件テーブル」と「担当グループテーブル」の両方に group_code 列（テキスト型）を作り、同じ GA001 を持つ行同士を参照させる。担当者が増えても、グループが変わっても、テーブル設計には手を加えずに対応できる。
このテキストコード突合は、Dataverseの代替キー（Alternate Key）仕様を技術的な土台にしている。代替キーは、主キー（GUID）とは別に「業務上の一意識別子」として列を定義する機能で、Microsoftが公式に仕様化している（Microsoft Learn「Work with alternate keys」2024年）。ただし、「組織共有のためにテキストコード突合を使う」という設計パターンそのものの公式ガイドは存在しない。この設計パターンの公式ガイドは存在しない。代替キー仕様を土台にした設計判断として提示する。
役割分解の判断軸
設計の出発点として、次の分解を使うと判断が早い。
| 共有の単位 | 向いている設計 | 典型的なケース |
|---|---|---|
| 個人（1対1） | Lookup列 | 担当営業、承認者、作成者 |
| 組織・チーム（1対多） | テキストコード突合 | 担当グループ、部門、担当エリア |
| 未定・変動する | テキストコード突合 | 組織再編が見込まれる、兼任が多い |
Lookup列が最も力を発揮するのは、「この行を担当するのは常に1人」という前提が成立する場面だ。担当者が交代しても「前任者→後任者」と1対1で置き換わるなら、Lookup列で問題ない。
組織単位の共有が必要な場合は、設計段階でテキストコード突合に切り替える。後から変えようとすると、既存のビューやフォームへの影響範囲が広くなる。
代替キー設定の制約——設計前に知っておく数値
テキストコード突合を代替キーとして設定する場合、次の制約が2026年時点の仕様として存在する（Microsoft Learn「Work with alternate keys」2024年）。
| 項目 | 制限値 |
|---|---|
| テーブルあたりの最大定義数 | 10個 |
| キー合計サイズ上限 | 900バイト |
| キーに含められる最大列数 | 16列 |
| 列レベルセキュリティが有効な列 | 使用不可 |
| NULL値の一意性強制 | なし（NULL重複が発生しうる） |
業務コードの文字種にも注意が必要だ。代替キーを使ったUpsert（PATCH操作）では、テキストコードに < > * % & : / # のいずれかが含まれると動作しない。コード設計の段階でこれらの文字を除外する必要がある。
また、代替キーを新規作成した直後はステータスが Pending（データベースのインデックス作成中）になる。Active に変わったことを確認してからUpsertを実行すること。Pending のまま実行すると失敗する。ステータスが変わるまでの時間は既存レコード数や環境負荷によって変わるため、数値の目安は公式に記載がない——確認してから進む習慣をつけておく。
チェックリスト：設計切り替えの判断ポイント
Lookup列をやめてテキストコード突合に切り替えるかどうかは、次の問いで判断する。
□ 1つのレコードに対して、担当者・参照先が複数になる可能性があるか
□ 組織変更・人員増加が今後1〜2年以内に見込まれるか
□ ビューフィルターで「特定のグループが担当する行だけ見る」という要件があるか
□ 外部システムや既存マスタに業務コード（代理店コード・部門コード等）が存在するか
□ テキストコードに < > * % & : / # が含まれないか（Upsert利用前提の場合）
□ 代替キーのステータスをActive確認してからUpsertを実行する運用が取れるか
1つでも当てはまるなら、Lookup列のままで進めるリスクを設計書に明記した上で判断する。3つ以上当てはまるなら、テキストコード突合への切り替えをデフォルトとして考える。
個人開発環境での検証
ここまでの設計判断を実際に手を動かして確認するには、本番環境ではなく検証用テナントで試す必要がある。
Microsoft 365 Developer Programの無料テナントを使えば、Power Apps / Dataverseを個人PCから使える検証環境が手に入る。代替キーの設定→Lookup廃止→テキストコード突合のフローを1度作っておけば、次の案件でそのテンプレートを転用できる。
まとめ
Lookup列を使うかテキストコード突合に切り替えるかは、「誰と共有するか」の単位が個人か組織かで決まる。この判断を設計段階で確定しておくことで、人員増加・組織変更に無修正で対応できる構造になる。
次の一歩
- 現在使っているLookup列の設計を確認し、「担当が複数になる可能性」があるものをリストアップする
- テキストコード突合に切り替える対象を絞り、業務コードの文字種を確認する（
< > * % & : / #を除外） - M365 Developer Programの無料テナントで代替キーの設定→Upsert動作を1度試す
次回予告：Dataverseビューフィルターを使った「全自動バケツリレー」——担当グループが変わっても自動で表示対象を切り替える仕組みの設計パターンを解説予定。
関連記事
- Dataverseの代替キーで安全にUpsertする——Pending→Active確認とコード設計の注意点（連載第1回）
- ExcelからDataverseへのインポートでLookup列をマッピングする
参考：Microsoft Learn「Column data types in Microsoft Dataverse」（2024年） / 「Work with alternate keys (Microsoft Dataverse)」（2024年）