Salesforce活動履歴の二重登録を防ぐ設計
商談は進んでいるのに、活動履歴だけが信用できない。営業会議で困るのは、その瞬間です。メールを1通送っただけなのに活動が2件見える。複数の担当者に送ったメールが案件側で重複して見える。外部連携を入れたあとに、Last Activity Dateの見え方まで揺れる。こうなると、入力工数の問題では済みません。営業判断の土台が崩れます。
> Salesforceにおける活動履歴の二重登録防止とは、同じ営業事実を複数のTask・Event・EmailMessageとして増やさないだけでなく、複数の関係先への関連付けや表示差を含めて、「1活動を何件として扱うか」を更新判定で統一する設計です。
Key Takeaways
- Salesforceの活動重複は、EAC、手動Log Email、API連携、Shared Activities未設定、Task/Event自動化の干渉が重なって起きます。単純な機能ON/OFFでは解決しません。
- まず分けるべきは、見た目の重複と実レコードの重複です。Timeline、Activity History、レポートで見え方が異なるためです。
- 重複防止の中心は、どの取り込み経路を正とするか、新規作成・更新・関連付け追加・スキップをどう判定するかを表に落とすことです。
- 複数Contacts宛てのメールを1活動で扱いたいなら、Shared Activitiesの影響確認が重要です。ただし有効化はロールバック制約があるため、Sandbox検証が前提です。
- パートナー営業や問い合わせ連携では、社外で起きた出来事を何でも活動化しないことが重要です。AIや自動連携を使うほど、冪等キーと人間レビューの設計が効いてきます。
まず切り分けたいのは「重複して見える」のか「重複登録されている」のか
営業から「同じメールが2回入っている」と言われても、すぐにTaskの重複とは限りません。Salesforceでは活動は概念上はActivityですが、実体は主にTaskとEventです。メール同期ではEmailMessageが関わるため、同じ出来事でも見える場所と持ち方が揺れます。Salesforceのデータモデルでも、TaskとEventが活動の中心であり、関係先の表現は別レイヤーを持ちます。 外部参照: Salesforce Developers: Tasks and Events Data Model
この違いを無視すると、対策が逆効果になります。Activity TimelineとActivity Historyでは表示の仕方が異なります。つまり、UI上で2回見えることと、実レコードが2件あることは同義ではありません。 外部参照: Salesforce Help: Activity Timeline vs. Past Activity
最初の確認対象は、少なくとも次の3つです。
- Taskが実際に複数作成されているか
- 1件の活動に複数のRelationが付いているだけか
- TimelineとHistoryで表示差が出ているだけか
この切り分けをせずにFlowや連携を止めると、現場の活動記録まで欠けやすくなります。
重複が起きる代表パターンは5つある
1. 取り込み経路を併用している
もっとも起きやすいのは、自動同期と手動ログの二重運用です。Salesforce公式は、Einstein Activity CaptureのSync Email as Salesforce Activityと、Outlook/Gmail側パネルのLog Emailを併用すると、同じメールが二重記録されうると案内しています。 外部参照: Salesforce Help: Considerations for Sync Email as Salesforce Activity
また、Sync Email as Salesforce Activityでは、メールがTaskとEmailMessageとしてSalesforce上で扱われ、レポート、API、自動化の対象になります。活動が見えるようになるほど、既存の手動ログや旧来の連携経路を残したままでは、重複が「見える問題」に変わります。 外部参照: Salesforce Help: Guidelines for Using Sync Email as Salesforce Activity 外部参照: Salesforce Help: Migrate to Sync Email as Salesforce Activity
2. Shared Activitiesが前提になっていない
複数の担当者に送った1通のメールを、営業事実としては1件と数えたい。ここで分岐になるのがShared Activitiesです。SalesforceではShared Activitiesを有効にすると、1つのTask/Eventを最大50 Contactsに関連付けできます。 外部参照: Salesforce Help: Enable Shared Activities
逆に、Shared Activitiesが無効で、primary accountへのroll-upが有効な状態だと、複数ContactへログしたメールがAccountやOpportunity上で重複して見えやすくなります。Salesforce公式も、この条件での重複表示・重複作成リスクを説明しています。 外部参照: Salesforce Help: Email Logged Using Salesforce Outlook Integration or Gmail Integration Appears Multiple Times
ただし、Shared Activitiesは軽く試せる設定ではありません。無効化やロールバックには制約とデータ損失リスクがあります。 外部参照: Salesforce Help: Considerations for Enabling Shared Activities 外部参照: Salesforce Help: How to Enable or Disable Shared Activities
3. TaskやEventへの自動化が標準ロジックに干渉している
「重複が出たのでFlowで吸収しよう」と考えがちですが、ここにも落とし穴があります。Salesforce公式は、標準ロジックが重複Taskを作成後に片方を削除するような場面で、TriggerやFlowが削除を阻害すると重複が残ると案内しています。 外部参照: Salesforce Help: Email Logged Using Salesforce Outlook Integration or Gmail Integration Appears Multiple Times
実装上は、同期対象のTaskやEventに独自自動化をかけるなら、除外条件が必要です。特にメール由来のTaskは、通常の架電TaskやToDoと同じルールで処理しないほうが安全です。
4. Contact/Leadの名寄せが甘い
EACの自動マッチングは、1メールアドレスにつき1つのContactまたはLeadだけを選びます。Contactsが優先され、同一アドレスが複数レコードにある場合はタイブレークで決まります。自動で複数にきれいに関連付けてくれるわけではありません。 外部参照: Salesforce Help: How Email Activity Matches with Other Records
つまり、同一メールアドレスを持つContactやLeadが残っていると、誤紐付けだけでなく、重複を温存したまま運用が進みます。営業現場では「履歴はあるのに担当者が違う」「古い商談に付いた」という形で見えます。
5. API連携に冪等性がない
問い合わせ、見積、カレンダー、外部営業ツールからTask/Eventを入れる場合、insert中心の設計は危険です。SalesforceではExternal IDとUniqueの設計が弱いまま並列upsertを行うと、重複挿入や`DUPLICATE_EXTERNAL_ID`が起こりえます。 外部参照: Salesforce Help: Differences between the 'External ID' field and the 'Unique ID' field setting
さらに、Task/Eventの`WhatId`と`WhoId`はpolymorphic fieldのため、Data Loaderではexternal IDマッピングができません。関連先を外部キーでそのまま安全に解決できる、とは言えません。 外部参照: Salesforce Help: Import Related Records with an External ID in Salesforce Data Loader
ここはCRM管理者だけの問題ではありません。RevOpsや営業企画が外部連携を広げるとき、活動そのものに冪等キーを持たせる設計が必要です。
最初に確認すべき設定と構成
「どこが悪いか」を探す前に、いま何本の経路で活動が入っているかを棚卸しした方が早いです。Salesforce公式も、Outlook Integration、EAC、Lightning Sync、Email to Salesforceなどは役割が異なると整理しています。移行期は、旧経路を止め切れないまま新経路を足しやすくなります。 外部参照: Salesforce Help: Outlook Integration, EAC, Lightning Sync, and Email to Salesforce
確認項目は、少なくとも次の8つです。
- 活動の取り込み経路は何本あるか
- EAC新モード - 旧EAC - Outlook Integration / Gmail Integration - Email to Salesforce - Lightning Sync - 独自API連携
- Shared Activitiesは有効か
- primary accountへのroll-upは有効か
- Task / Event / EmailMessage作成時にFlowやTriggerが動くか
- 同一メールアドレスのContact/Lead重複がないか
- Event同期は片方向か双方向か
- 監視対象はTimelineか、Activity History/Reportsか
- 旧EAC由来のTimeline表示だけのデータが混じっていないか
旧EACでは、メールがSalesforce DBに標準レコードとして保存されず、Timeline上だけ見える場合があります。新旧を混ぜると、重複の定義そのものがぶれます。 外部参照: Salesforce Help: Emails Captured via EAC Not Seen in the Activity Timeline
更新判定表がないと、現場ルールは必ず崩れる
活動重複は、入力ルールではなく更新判定の問題です。誰が何をしたら新規作成するのか、既存活動に追記するのか、関連付けだけ足すのか、何もしないのか。この4分類を決めていない組織では、ツール追加のたびに重複が再発します。
営業企画にとっては、活動件数の定義がぶれる問題です。CRM管理者にとっては、同期経路ごとの責任分界が曖昧な問題です。代理店営業責任者にとっては、社外起点の問い合わせや見積依頼を何でも活動化してしまう問題です。同じ「二重登録」でも、見ている業務が違います。
代表的な更新判定例
> ここからの表は、Salesforce公式仕様を踏まえた提案例です。自社の運用、オブジェクト設計、承認フローに合わせて調整してください。
| 入力ソース | 判定条件 | 推奨アクション | 理由 |
|---|---|---|---|
| EAC自動同期メール | 同一メールをEACで取り込み済み | スキップ | 自動同期と手動ログを二重で持たないため |
| Outlook/Gmail手動Log Email | 対象ユーザーがEAC自動同期対象 | 原則スキップ | 公式に二重ログの可能性あり |
| 複数Contact宛てメール | Shared Activities有効 | 既存活動へ関連付け追加 | 1営業事実を1レコードで持ちやすい |
| 複数Contact宛てメール | Shared Activities無効 | 新規作成を許容するか要判断 | Account/Opportunityで重複見えしやすい |
| APIでTask/Event投入 | 外部イベントIDあり | upsertで更新 | insert中心を避け、冪等性を持たせる |
| APIでTask/Event投入 | 外部イベントIDなし | 新規作成を原則避ける | 重複検出が難しく、再送に弱い |
| Event双方向同期 | Salesforce側も外部側も更新 | 一方を正にする | conflictと競合が起きやすい |
| Contact/Lead重複あり | 同一メールアドレスが複数 | 名寄せ後に再設計 | 誤紐付けと重複温存を招く |
この表で重要なのは、新規作成を最後の選択肢に落とすことです。活動は案件より件数が多く、後からのクリーニングコストが大きくなります。
営業現場に伝えるべき運用ルール
設計だけ整っても、現場の行動が逆なら重複は止まりません。営業企画や代理店営業責任者が伝えるべきルールは、意外と少数です。
- EAC自動同期の対象ユーザーは、原則として手動Log Emailをしない
- Email to SalesforceのBCC運用を残すなら、EACと対象を分ける
- 同一メールアドレスのContact/Lead重複を放置しない
- 同期対象Task/Eventへの後追いFlow・Triggerは除外条件を入れる
- 重複を見つけたときは、Timelineではなく実レコード確認の手順を持つ
営業マネージャーにとっての意味は明確です。活動件数を評価や温度感に使うなら、「件数の増え方が正しいか」を先に担保しないと、KPIそのものが現場の努力を誤読します。
関連する設計は、CRM入力を自動化する方法でも扱っています。入力を減らす施策ほど、更新判定の設計が先に必要です。
API・Flow・Triggerで外せない設計要件
事実
- EACのマッチングは、Flow/Apexで拡張できます。custom email fieldやcustom objectへの関連付けも可能です。
外部参照: Salesforce Help: How Email Activity Matches with Other Records
- ただし、Activities Matchのcore actionsはsystem-run flowやautomated process userを支援せず、context user権限前提で動きます。
外部参照: Salesforce Help: How Email Activity Matches with Other Records
- Eventの双方向同期では、Salesforce側と外部カレンダー側の双方を同期前に更新するとconflictが起きやすくなります。
外部参照: Salesforce Help: How Events Sync with Einstein Activity Capture
実装上の示唆
- 活動自身に冪等キーを持たせる
`WhatId`や`WhoId`の外部IDマッピングに期待しすぎず、外部メールID、会議ID、問い合わせIDなどを活動側で保持した方が安全です。
- 再送がありうる連携は、insert前提にしない
Uniqueな外部IDを前提に、重複を検知できる更新経路を設計した方が、並列実行や再送に強くなります。
- TaskSubtypeや同期由来フラグで除外する
すべてのTaskに同一ロジックをかけると、メール同期系の標準挙動を壊しやすくなります。
- 人間レビューの例外条件を持つ
名寄せ不能、複数商談候補、同一メールアドレス重複などは、自動処理だけで閉じない方が安全です。
AIネイティブCRMやAgentic CRMの話も、ここで初めて実務とつながります。AIが次の行動提案や要約を行うほど、元の活動データの重複や誤紐付けが直接性能に響きます。自動化の前提は、活動件数を増やすことではなく、営業文脈を壊さずに還流することです。詳しくはAIネイティブCRMとは？も参考になります。
パートナー営業・代理店営業では「何を活動化するか」の線引きが先
社内営業だけなら、メールや会議の同期を整えれば一定の効果があります。難しくなるのは、代理店、販売パートナー、問い合わせ窓口、見積依頼など、社外で発生したやり取りをCRMへ戻す場面です。
ここで起きがちなのは、同じ案件相談が別々の活動として増えることです。たとえば、パートナーからの問い合わせ、担当営業の返信、見積依頼の受付、案件化時のTask、外部ポータルからの連携履歴が、それぞれ独立した活動として積み上がるケースです。
これを全部「活動」として新規作成すると、案件が活発に見えるだけで、実態より膨らみます。パートナー営業では、証跡として残すものと参照のみに留めるものを分ける設計が重要です。
提案例としては、次のように分けると運用しやすくなります。
- 商談前の単純な問い合わせ: 活動ではなく参照ログ
- 見積依頼の受付: 根拠ID付きで活動化
- 共同提案の進行連絡: 既存案件活動へ関連付け追加
- 同一案件に紐づく再送や催促: 既存活動更新またはスキップ
見積・問い合わせとのつながりは、Salesforceと見積を連携する方法でも整理しています。活動設計と案件設計を別々に考えると、あとで必ずズレます。
導入時の注意点
Shared Activitiesは本番でいきなり有効化しない
Shared Activitiesは便利ですが、既存のTask/Event運用、レポート、連携、権限、画面表示に影響します。Sandboxで、複数Contacts関連付け、既存自動化、監査・出力への影響を見てから判断すべきです。 外部参照: Salesforce Help: Considerations for Enabling Shared Activities
「古い重複」と「これから増える重複」を分けて対処する
既存データのクレンジングだけ先にやっても、新規流入の経路がそのままなら再発します。順番としては、取り込み経路の一本化、更新判定表の合意、自動化の除外条件、その後に既存重複の整理、の方がやり直しが少なくなります。
Event同期は片側を正に寄せる
イベント同期は、双方更新を許すほど競合しやすくなります。会議変更が多い組織ほど、どちらを正とするかを決めておかないと、重複より厄介な不整合が残ります。 外部参照: Salesforce Help: How Events Sync with Einstein Activity Capture
Hiwayへの接続を考えるときの判断軸
活動履歴の重複は、Salesforceの設定だけでなく、社外起点データをどの粒度でCRMへ返すかまで含めて決まります。特に、問い合わせ、見積、パートナー経由の相談をCRMへ戻す運用では、何を活動として残し、何を参照情報に留めるかの設計が欠かせません。
Hiwayの公開ページでは、既存CRM/SFAとの双方向同期を前提に、営業データの入力・更新・分析を扱うCRMを案内しています。社外で発生した情報をCRMへ還流する設計を考えるときは、活動を増やす前に、更新判定と関連付けルールを先に決める方が安全です。 外部参照: Hiway CRM
相談の前に整理しておくとよい情報は、次の4点です。
- 現在の取り込み経路一覧
- 重複が起きている画面と対象オブジェクト
- Task / Event / EmailMessageに対する既存Flow・Trigger
- 社外チャネルから戻している問い合わせ・見積・案件データの有無
このあたりが見えていると、自社でまず止めるべき重複経路と、活動化の基準を判断しやすくなります。
FAQ
Shared Activitiesを有効にすれば重複は解消しますか？
いいえ。Shared Activities未設定は主要因の1つですが、自動同期と手動Log Emailの併用、Task自動化の干渉、APIの冪等性不足が残っていれば重複は続きます。 外部参照: Salesforce Help: Email Logged Using Salesforce Outlook Integration or Gmail Integration Appears Multiple Times
Activity Timelineで重複して見えたら、Taskが2件あると考えてよいですか？
必ずしもそうではありません。TimelineとActivity Historyでは見え方が異なります。実レコードの重複か、表示差か、Relationの違いかを切り分ける必要があります。 外部参照: Salesforce Help: Activity Timeline vs. Past Activity
EACのメールはすべてSalesforce標準レコードとして保存されますか？
新しい同期モードではTaskとEmailMessageとして扱えるケースがありますが、旧EACでは標準レコード化されずTimeline表示のみのケースがあります。新旧の見分けが必要です。 外部参照: Salesforce Help: Guidelines for Using Sync Email as Salesforce Activity 外部参照: Salesforce Help: Emails Captured via EAC Not Seen in the Activity Timeline
APIでupsertしていれば重複は防げますか？
upsertだけでは不十分です。External IDとUniqueの設計、活動自身の冪等キーが重要です。関連先の`WhatId`や`WhoId`を外部IDで直接安全に処理できるとは限りません。 外部参照: Salesforce Help: Differences between the 'External ID' field and the 'Unique ID' field setting 外部参照: Salesforce Help: Import Related Records with an External ID in Salesforce Data Loader
代理店や問い合わせ経由のやり取りも、すべて活動化した方がよいですか？
そうとは限りません。活動として残すものと、参照ログとして保持するものを分けた方が、案件の実態を歪めにくくなります。社外起点データが多い組織ほど、更新判定表の定義が重要です。
デモ・導入相談
活動履歴の重複は、設定ミス1点よりも、取り込み経路と更新判定のズレで起きることが多いです。社外問い合わせ、見積、代理店経由の活動まで含めて整理したい場合は、現行のSalesforce運用に照らして確認できます。
参考文献・一次情報
Salesforce活動重複・Shared Activities
- Salesforce Help: Email Logged Using Salesforce Outlook Integration or Gmail Integration Appears Multiple Times on Salesforce Records
- Salesforce Help: Enable Shared Activities
- Salesforce Help: Considerations for Enabling Shared Activities
- Salesforce Help: How to Enable or Disable Shared Activities
EAC・メール同期・マッチング
- Salesforce Help: Guidelines for Using Sync Email as Salesforce Activity
- Salesforce Help: Considerations for Sync Email as Salesforce Activity
- Salesforce Help: How Email Activity Matches with Other Records
- Salesforce Help: Migrate to Sync Email as Salesforce Activity
- Salesforce Help: Emails Captured via EAC Not Seen in the Activity Timeline
表示差・同期経路・イベント同期
- Salesforce Help: Activity Timeline vs. Past Activity
- Salesforce Help: Outlook Integration, EAC, Lightning Sync, and Email to Salesforce
- Salesforce Help: How Events Sync with Einstein Activity Capture
API・データモデル
- Salesforce Help: Import Related Records with an External ID in Salesforce Data Loader
- Salesforce Help: Differences between the 'External ID' field and the 'Unique ID' field setting
- Salesforce Developers: Tasks and Events Data Model
- Salesforce Developers: Change Data Capture for Shared Activities