Dynamics 365 を導入すると「社内の人を取引先担当者としても登録した方が便利では？」という議論がよく起こります。しかし、Azure AD / Microsoft Entra ID に存在する社内ユーザーを「ユーザー」と「Contact」の二重構成にすると、後から消せないトラブルの原因になります。本記事では、その理由と安全な設計・運用方法を詳しく解説します。
Dynamics 365 における「ユーザー」と「取引先担当者(Contact)」の基本整理
まず、用語と役割を整理します。
ユーザー（System User）とは
- Azure AD / Microsoft Entra ID 上のアカウントと 1 対 1 で対応したレコード
- ライセンス付与や環境へのアクセス権付与により、自動または半自動で作成される
- セキュリティロール・所有者・監査情報など、システム内部の権限管理の基点になる
- レコードの「所有者（Owner）」に設定できる
取引先担当者（Contact）とは
- 顧客・仕入先・パートナー・見込み客など、社外の人を表現するためのレコード
- Dynamics 365 / Dataverse 標準テーブルの 1 つで、ほとんどのアプリで共通利用される
- メールアドレスや電話番号を持ち、活動（メール・電話・予定など）の相手として紐付ける
- レコードの所有者にはなれない（所有者はあくまでユーザー or チーム）
ユーザーとContactの違い早見表
| 項目 | ユーザー（System User） | 取引先担当者（Contact） |
|---|---|---|
| 想定対象 | 社内の人（従業員・派遣社員など） | 社外の人（顧客・パートナー・仕入先など） |
| ソース | Azure AD / Microsoft Entra ID アカウント | CRM 内で手動作成・インポート・連携など |
| サインイン | Dynamics 365 にサインイン可能 | 原則サインイン不可（Power Pages 等の特殊ケースを除く） |
| レコードの所有者になれるか | なれる（Owner フィールドに設定可） | なれない（参照は持てるが所有者ではない） |
| セキュリティロール | ロールを付与してアクセス権を制御 | ロールは付与できない |
| 監査・履歴 | 「作成者」「最終更新者」として記録される | 操作主体にはならない（関連相手として記録される） |
Microsoft の公式ドキュメントでも、一般的なモデル駆動型アプリでは「ユーザーは Microsoft 365 / Entra ID のアカウントを同期して作成し、アクセス権付与の単位として用いる」と明記されています。
社内の人をユーザーとContactで二重に持つべきではない決定的な理由
結論から言うと、社内の人はユーザーだけにして、同一人物の Contact を作らないのがベストプラクティスです。その理由を「よく起こる事故」ベースで説明します。
データ重複・同期不整合が必ず起きる
ユーザー情報は、基本的に Azure AD / Entra ID を「真実のソース」として同期されます。一方、Contact は手入力や CSV インポート、外部システム連携などバラバラな経路で更新されます。
- ユーザーの部署が AD 上で「営業部」→「事業企画部」に変更された
- しかし、Contact 側は古い部署名のまま放置
- レポートによってはユーザー側の部署、別のレポートでは Contact 側の部署が参照される
この結果、同じ人物なのに「営業部」と「事業企画部」の両方にカウントされるなど、集計結果や分析結果が信用できない状態になります。どこまでいっても「本当の情報はどっち？」という確認作業から逃れられません。
メール・予定・活動の紐付けが混乱する
Dynamics 365 では、サーバーサイド同期や Outlook 連携により、メールアドレスをキーにして活動（メール・予定・電話）を自動で紐付けます。そのとき、同じメールアドレスを持つユーザーと Contact が存在すると、次のような問題が起こりがちです。
- メールをトラッキングしたときに、ユーザーではなく Contact に紐付いてしまう
- 予定の参加者としてユーザーと Contact の両方が候補に現れ、誤って Contact を選択してしまう
- 同じメールがユーザーと Contact 両方のタイムラインに登録され、活動が二重記録される
コミュニティでも「社内ユーザーと同じメールアドレスの Contact を持つと、メールトラッキングや自動作成ルールで混乱する」という相談が多数あります。
権限・所有者・ワークフローが破綻する
Dynamics 365 の内部処理は「レコードの所有者＝ユーザー or チーム」を前提に設計されています。たとえば、よくあるシナリオとして次のようなものがあります。
- 見積や案件の所有者に応じて、承認フローを開始する Power Automate フロー
- リードの所有者に基づいて、フォローアップメールを送るワークフロー
- 所有者を使った「担当者別案件数」「担当者別売上」のダッシュボード
ここに「社内の人の Contact」が混ざるとどうなるでしょうか。
- Contact は所有者になれないため、ワークフローの条件に合致しない
- レコードの所有者はユーザーだが、活動の相手として Contact が使われており、担当者別レポートが分断される
- 承認フローがユーザーだけを対象にしているため、「Contact しか紐付いていない社内者」が承認経路から抜け落ちる
結果として、承認が回らない・通知が飛ばない・レポートが意図と違うという「運用事故」に直結します。
ライセンスと監査の観点からも非推奨
社内の人は原則として「ユーザーライセンスの付与を前提に利用する」ことが Microsoft の想定です。Contact で社内利用を代替しようとする設計は、ライセンスモデルと相性が悪く、トラブルの元になります。
また、監査ログやレコードの履歴に記録されるのは「ユーザー」が実行主体です。「誰がいつ、どの情報を更新したのか」を追いたいとき、Contact を多用すると、
- 操作主体はユーザーだが、関連先に Contact しか無く、人の特定に時間がかかる
- セキュリティインシデント時に、ユーザーと Contact のどちらを基準に調査すべきか迷う
コンプライアンスや内部統制を意識するほど、「操作する人」はユーザーに一本化しておくことが重要になります。
レポート品質・分析精度の低下
Dynamics 365 の標準レポートやダッシュボードは、「所有者（ユーザー）別」「作成者別」「担当者別」での集計が多く用意されています。社内の人を Contact でも表現し始めると、次のような問題が頻発します。
- 担当者別売上レポート：所有者ベースの売上と、Contact ベースの活動件数がずれて見える
- 営業パイプライン：ユーザー単位のパイプラインと、マーケ部門が管理する Contact 単位のリストが合わない
- ダッシュボードのフィルタ：ユーザーと Contact の両方から担当者を選べてしまい、誰が何の数字を見ているのか混乱する
すべてのレポートとダッシュボードで「社内の人はユーザー、社外は Contact」という前提を共有することで、分析結果の信頼性が一気に高まります。
問題点のまとめ表
| 問題カテゴリ | ユーザー＋Contact二重登録時の影響 | よくある症状 |
|---|---|---|
| データ品質 | 同一人物の情報が複数箇所に分散し、どれが正か分からなくなる | 部署名・電話番号・役職がレポートごとにバラバラ |
| 活動管理 | メールや予定が誤ったレコードに紐付く、もしくは二重登録される | タイムラインに同じメールが複数表示される |
| プロセス・ワークフロー | 所有者前提の承認フローや通知が正しく動作しない | 承認依頼が届かない、特定ユーザーだけ通知が来ない |
| 監査・セキュリティ | 誰が何をしたのか追いにくくなり、調査コストが増大 | インシデント対応時に調査対象が増え、復旧が遅れる |
| レポート・分析 | 担当者別の数字が割れる・ダッシュボード間で整合性がなくなる | 「同じ数字のはずなのに合わない」が日常化 |
正しい使い分けの原則
ここまでの内容をルール化すると、とてもシンプルです。
- 社内の人（Entra ID に存在し、Dynamics 365 にサインインする人）＝ユーザー（System User）のみ
- 社外の人（顧客・パートナー・仕入先担当など）＝取引先担当者（Contact）のみ
この原則を守るだけで、権限設計・レポート設計・監査・運用教育の全てが一貫し、トラブルを大幅に減らせます。
「社内だけどサインインしない人」はどうするか
一部の組織では、サインインはしないが社内の関係者として記録しておきたい人（アルバイト、工場の現場要員など）が存在します。この場合は以下のような選択肢があります。
- Dynamics 365 を使わない前提なら、Contact として登録してもよい（メールトラッキング対象にしないなど運用ルールを明確にする）
- 将来的に使う可能性があるなら、ライセンスやセキュリティポリシーを整理したうえでユーザーとして管理する
重要なのは、「Dynamics 365 を利用する社内ユーザー」と「単なる社内の情報としての人」を混在させないことです。
すでにユーザーとContactが二重登録されている場合の是正手順
現実には、既に二重登録がある環境の方が多いでしょう。その場合は、次のステップで安全に整理できます。
全体フローのイメージ
| ステップ | 目的 | 主な作業 |
|---|---|---|
| 1. 現状把握 | どれくらい重複しているかを知る | メールアドレスなどをキーにユーザーと Contact を突合 |
| 2. 正レコードの決定 | どちらを主とするかを明確化 | 同一人物は必ずユーザーを「正」とするルールを定義 |
| 3. 関連データの移行 | 活動・関連先を正レコードに寄せる | メール・予定・タスク等の Regarding/To をユーザー側に付け替え |
| 4. Contact の統合／無効化 | 二重レコードを整理し、再発を防ぐ | 重複 Contact のマージまたは非アクティブ化 |
| 5. ルール・設定の見直し | 再び二重登録が生まれないようにする | 自動作成ルール・個人設定・運用ルールを修正 |
ステップ 1: 重複の洗い出し
- ユーザー一覧と Contact 一覧を、それぞれ Excel にエクスポート
- メールアドレス（primary email）をキーに VLOOKUP や XLOOKUP で突合する
- 同じメールアドレスを持つペア一覧を作る
件数が多い場合は、Power Query や Power BI を使って突合・集計して「重複の傾向」を把握するのも有効です。
ステップ 2: 正レコードの決定ルール
基本原則はシンプルです。
- 同じ人物であれば必ず「ユーザー」を正とする
- Contact 側にしかない情報（部署名・役職など）は、可能な限り AD / 元人事システム側で整備した上でユーザーに反映させる
- Contact 固有の情報（顧客としての役割など）は、別テーブルや接続（Connections）で表現する
ステップ 3: 活動・関連データの付け替え
次に、Contact 側にぶら下がっている活動・関連レコードをユーザーに移します。
- メール・電話・予定・タスクなどの Regarding（件名の関連先）を Contact → ユーザーに変更
- カスタムテーブルで Contact 参照を持っている場合、ユーザー参照に切り替える or 中間テーブルで持ち直す
- Power Automate を使って一括で付け替えるフローを作ると安全かつ効率的
運用中の環境では、一度に全て移行するのではなく、部門単位・期間単位で段階的に移行するのがおすすめです。
ステップ 4: Contact のマージ or 非アクティブ化
関連付けの付け替えが完了したら、二重 Contact を整理します。
- 履歴として残しておきたい場合は「非アクティブ化」して新規作成を防ぐ
- 同一人物の Contact が複数ある場合は「マージ」して 1 レコードにまとめる
- 将来誤って選ばれないように、ビューや検索結果から除外する工夫（ビュー条件で「ステータス＝有効」のみ表示など）を行う
ステップ 5: 再発防止のための設定・運用見直し
なぜ Contact が勝手に増えてしまったのか、原因を特定し、設定を見直します。代表的な発生源は以下です。
- ユーザーの個人設定で「追跡されたメールから取引先担当者を自動作成」がオンになっている
- 自動レコード作成ルール（ARC）で「未知の送信者からのメールは Contact を作成」にしている
- マーケティングツール（Customer Insights – Journeys やサードパーティ製）からの同期ロジックが「社内ドメインも Contact として作成」になっている
これらを見直し、「社内ドメインのメールアドレスは Contact として自動作成しない」「内部向けメーリングには別の設計を取る」といったルールを整理します。
そもそもなぜ二重登録したくなるのか？よくあるニーズと代替案
現場からは、次のような要望がよく上がります。
- 「社員にもキャンペーンメールを送りたいから、Contact にもしておきたい」
- 「社員を見積の関係者として選びやすくしたい」
- 「担当営業と顧客を 1 画面で一覧したい」
これらは一見もっともですが、ユーザー＋Contact 二重登録に頼らなくても、別の形で実現できます。
社内向けメールマーケティングをしたい場合
- 社内専用の別環境を用意する
- Azure AD グループや配布リストを使ってメール配信する
- どうしても Contact を使う場合は、社内ドメイン用の別メールアドレス（例：[email protected]）を使うなど、トラッキングと混ざらない設計にする
見積・案件の関係者に社員を紐付けたい場合
- ユーザーを参照するカスタムルックアップ（例：担当エンジニア、プリセールス担当など）を作る
- チームを使って「プロジェクトメンバー」単位で紐付ける
- Connections（接続）機能を使い、「この案件にどのユーザーがどんな役割で関わっているか」を表現する
担当者と顧客を 1 画面で見たい場合
- ビューやフォーム上で「所有者」「担当営業」などユーザー参照フィールドを追加する
- Power BI レポートなどでユーザーと Contact を結合して表示する
いずれも、ユーザーを正として設計すれば実現可能なパターンです。最初から「Contact も作ろう」と考えるのではなく、「ユーザーをどう活用するか」から逆算して設計するのがポイントです。
例外的に Contact が必要になるケースと注意点
原則として「社内＝ユーザー、社外＝Contact」ですが、例外的に Contact が必須となるケースもあります。その代表が Power Pages（旧ポータル） や一部のマーケティングシナリオです。
Power Pages/ポータルでログインさせたい社内ユーザー
Power Pages では、ログインユーザーのアイデンティティとして Contact を使う設計が基本です。そのため、社内ユーザーであっても、ポータルにログインさせたい場合は Contact が必要になります。
この場合のポイントは次のとおりです。
- 「ポータル用 Contact」と「社内利用のユーザー」は用途が違うものとして明確に分ける
- 内部業務（案件・見積・活動管理など）では、ポータル用 Contact を関連先として極力使わない
- メールトラッキング衝突を避けるため、ポータル用 Contact のメールアドレスを内部トラッキングから除外する・別のアドレスを使う
また、可能であれば Azure AD B2B / External ID 等を活用し、ユーザーを中心とした ID 設計に近づけると運用がシンプルになります。
マーケティングで社員を「顧客のように」扱いたい場合
Dynamics 365 Customer Insights – Journeys など一部のマーケティングソリューションでは、配信対象として Contact を前提とすることが多くあります。そのため、社員にも同様の配信をしたい場合、「社員 Contact」を作る選択をせざるを得ないケースもあります。
この場合は、以下のような厳格な分離ルールを設けることをおすすめします。
- 社員 Contact には「社内マーケ用」のフラグを立て、通常の営業・サポート業務では使わない
- ビューやフォームで 社員 Contact を通常の検索結果から除外する
- 社員 Contact を参照するのは「マーケティングリスト」「キャンペーン」などに限定する
- メールトラッキングや活動作成ロジックでは、社員 Contact を候補から外す
「作ってもいいが、利用範囲を徹底的に制限する」というのが安全運用のポイントです。
運用ルールとして定義しておきたいチェックリスト
最後に、運用ルールとしてそのまま社内に展開しやすいチェックリストをまとめます。
社内ユーザー登録時のチェック
- この人は Azure AD / Entra ID 上の社内ユーザーか？
→ はい：ユーザーのみ作成（Contact は作らない） - 同じメールアドレスの Contact が既に存在しないか？
→ 存在する場合は 統合・非アクティブ化してからユーザーを運用
日常運用でのチェック
- レコードの所有者に Contact を使っていないか？
→ 所有者は 必ずユーザー or チーム にする - ワークフローや Power Automate フローが Contact を前提にしていないか？
→ 社内プロセスは ユーザー／チーム参照に統一 - メールトラッキングで、新しい社内アドレスを Contact として自動作成していないか？
設定・設計レビューでのチェック
| チェック項目 | OK 条件 |
|---|---|
| 自動レコード作成ルール | 社内ドメインからのメールで Contact を自動作成しない設定になっている |
| 個人設定（メールトラッキング） | 「追跡されたメールから取引先担当者を自動作成」などの設定が適切に制御されている |
| カスタムエンティティの設計 | 社内担当者への参照は「ユーザー」へのルックアップに統一されている |
| マーケティング／ポータルの設計 | 社員 Contact を使う場合、その用途と運用範囲が明文化されている |
よくある質問（FAQ）
Q. すでに社内の人を大量に Contact で登録しています。全部消すべきでしょうか？
A. 一気に消すのではなく、ユーザーを正として段階的に置き換えるのがおすすめです。前述のステップに沿って、まずは新規の二重登録を止め、その後、活動の多い社員から順に整理していくと現場への影響を最小化できます。
Q. Contact をユーザーに変換するツールはありますか？
A. 標準機能で「Contact → ユーザー」へ自動変換するボタンはありません。Entra ID 側でユーザーを作成し、Dynamics 365 に同期されたユーザーに対して、必要に応じて Contact 側から情報をコピーする、という手順になります。Power Automate やカスタムスクリプトで半自動化するパターンは多くの実装で採用されています。
Q. 将来のライセンスコストが怖いので、社員を Contact だけで管理したいのですが…
A. ライセンスコストの懸念から Contact に寄せたくなる気持ちは理解できますが、権限管理・監査・運用トラブルのリスクの方が高くつくことが多いです。どの業務で誰が Dynamics 365 を使うのかを洗い出し、本当に必要な人だけにライセンスを割り当てる設計を検討してください。
Q. 社内ユーザーでも、どうしても Contact にしたい特別なケースはありますか？
A. 原則は「なし」ですが、例外として Power Pages や一部マーケティング用途のように、アプリ側の設計上 Contact が必須の場面があります。その場合でも、用途を限定し、内部業務で使わないことと、ユーザーと Contact の関係を明示的に管理することが重要です。
まとめ：社内＝ユーザー、社外＝Contact の原則を徹底する
社内ユーザーを「ユーザー」と「取引先担当者(Contact)」の二重構成にしてしまうと、
- データ不整合・重複
- メール／活動の誤紐付け
- 権限・ワークフローの破綻
- 監査やコンプライアンス対応の複雑化
- レポート・分析の信頼性低下
といった問題が長期にわたってつきまといます。
「社内の人はユーザーのみ」「社外の人は Contact」というシンプルな原則をチーム全体で共有し、既存の二重登録は計画的に整理・統合していくことで、Dynamics 365 環境の健全性と将来の拡張性を大きく高めることができます。
これから設計する環境でも、すでに運用中の環境でも、この記事の内容をチェックリストとして活用し、自社の Dynamics 365 が「長く安心して使える基盤」になるよう設計・運用を見直してみてください。
コメント