DATA INTEGRATION

名刺管理で終わらせない
Sansanの顧客データをCRM・MAへつなぐ設計

公開日 2026.08.14 / 検証日 2026.08.14 / 執筆・編集:テクヒカ編集部

SansanからCRMやMAへ名刺を渡すだけでは、重複、古い所属、同姓同名の誤統合といった問題が残ります。

Sansanは名刺を99.9%の精度でデータ化すると案内しています。これはSansanが公表している名刺データ化精度であり、CRMへ連携した後の顧客データが自動的に99.9%正しくなる、という意味ではありません。外部システム側には既存レコード、独自項目、古い会社名、担当者の手入力がすでに存在します。連携後の品質を決めるのは、名寄せと更新ルールです。

本記事では公式情報を基に、CRM・SFA・MAで使い続けるための設計を整理します。

Sansanへ名刺を入れただけでは、案件化までの空白が残る

名刺管理と営業管理の間には、意外に大きな空白があります。名刺から分かるのは、誰と接点があり、その時点でどの会社・部署・役職にいたかです。しかし営業が次に知りたいのは、「この会社には今いくつ案件があるか」「誰が担当しているか」「過去に失注していないか」「マーケティングメールを送る対象か」といった情報です。

つまり、Sansanで顧客接点を集めても、それだけで案件、売上見込み、MQL、商談ステージが生まれるわけではありません。逆にCRMへ全名刺をそのまま流し込むと、接点があるだけの人物と今追うべき見込み客が混ざります。ここで必要なのが「名刺管理→顧客マスタ→営業・マーケティング活用」という三段階の設計です。

仕組み主な役割正本にしたい情報ここで持たせすぎない情報
Sansan名刺・接点・人物情報の蓄積、名寄せ、最新情報の把握氏名、会社、部署、役職、接点、人脈商談金額や営業ステージの詳細
CRM顧客マスタと関係履歴会社・人物ID、担当、契約・問い合わせ履歴名刺画像そのものの管理
SFA案件・商談・営業行動の管理商談、金額、ステージ、次回アクション全社の名刺を無条件で案件化
MA見込み客の育成、セグメント、通知配信対象、行動、スコア、MQL状態営業が追わない全顧客を一律にホットリード化

CRMへ渡す項目は「名刺にあるもの全部」ではなく、更新責任で絞る

SansanからCRMへ渡す基本候補は、氏名、会社名、部署、役職、メールアドレス、電話番号、住所、名刺交換日、名刺所有者などです。Sansan Data Hubでは、名寄せ後の顧客データへ法人番号や登記情報など100種類を超える属性情報を付与できると案内されています。ただし、連携できる属性情報の数は連携先サービスによって異なります。

ここで100種類を超える属性を見て、できるだけ多くCRMへコピーしたくなりますが、運用上は逆です。CRMで検索、セグメント、営業判断に使う項目だけを連携し、それ以外は必要時にSansanで参照するほうが管理しやすくなります。項目が増えると、上書き可否、権限、API容量、変更時の影響範囲まで増えるからです。

項目連携方針の例更新責任
会社名・法人識別情報名寄せ後の会社IDとセットでCRMへSansan/Data Hubを優先候補
部署・役職最新名刺・異動情報から更新。ただし履歴は消さないSansanを更新元にしやすい
営業担当名刺所有者をそのまま担当者にせず、CRMの担当ルールで決定CRM/SFA
商談ステージ・金額Sansanから上書きしないSFA
メール配信可否名刺保有=配信可能とは扱わず、社内ルールと同意状態で管理MA/配信基盤
最終接点日名刺交換だけでなくメール・面談など何を接点とするか定義利用システムの活動設計に合わせる

Salesforce連携は「作成できる」より、既存レコードとどう合わせるかが本題

Sansan公式では、Salesforce連携によりSansanの名刺データを基に「取引先」「取引先責任者」「リード」を自動で作成・更新できると案内しています。また、外部システム上の顧客データを企業名、住所、電話番号など9つの情報を組み合わせて識別し、企業を特定する名寄せ機能も説明されています。

Salesforceをすでに運用している会社では、新規作成より既存データとの統合が難所です。「株式会社テック比較」と「テック比較(株)」が別取引先なら三つ目を作らず、旧担当者を履歴として残すか、異動先へ新しい関係を作るかまで決めます。

おすすめは、人物を「現在の所属」と「過去の接点」に分けて考えることです。異動したから旧会社での商談履歴まで移動させるのではなく、旧会社時代の活動は過去履歴として残し、新しい所属先に現在の人物情報を関連づけます。営業担当者から見ると、誰がどこへ移ったかと、以前どの案件に関わったかの両方が必要だからです。

2025年のアップデートでは、Salesforce側でSansan Data Hubへ取り込む識別項目を「名寄せ設定」画面から設定できるようになったとSansanが案内しています。こうした設定を利用する場合も、変更権限を営業全員へ広げず、CRM管理者が名寄せ条件を管理するほうが安全です。

HubSpot・Marketoへ渡すなら、「会社・人物」と「配信対象」を分ける

Sansanは2025年2月、Sansan Data HubからHubSpotの「会社」「コンタクト」へ自動連携する機能を公開しました。同年7月にはHubSpot側からData Hubへ取り込む間隔も従来の1時間から10分へ短縮しています。

スポンサーリンク

ただし、HubSpotのコンタクトが作られた瞬間にマーケティング対象へする必要はありません。名刺交換しただけの人、既存顧客、採用候補者、仕入先、パートナーまで同じ配信対象にすると、セグメントが崩れます。Sansanから人物を作成・更新した後、「対象企業か」「マーケティング対象か」「営業担当がすでに接触中か」をHubSpot側のプロパティとワークフローで分ける設計が必要です。

Marketoについては、Sansan公式が開発不要のプラグインを案内しています。ただし公開情報だけではフィールドマッピングや更新優先順位の細部までは分からないため、「Personを何で一意にするか」「CRM同期と同じ項目を更新しないか」を導入時に確認してください。

SalesforceとMarketoをすでに同期しているなら、Sansan→Salesforce→Marketoと直接連携を併用せず、一本の正規ルートを決めるほうが安全です。

4つのケースで分かる、名寄せ後に人間が決めること

連携前に例外処理を洗い出せるよう、重複、部署異動、転職、同姓同名の4ケースで判断を分けます。

ケースCRM側で起こる問題推奨する処理自動化しすぎない点
重複名刺
同じ人の名刺を営業A・Bが登録
人物が2件作られ、活動やメール反応が分裂人物ID・メール・会社などで同一候補を照合し、接点所有者は複数保持名刺所有者の違いを人物重複と混同しない
部署異動
営業部長→事業企画部長
旧部署のままセグメントされ、担当営業も気付かない現在部署・役職を更新し、旧情報は履歴へ。関係営業へ通知過去商談を新部署へ付け替えない
社名変更
社名だけ変わり法人は同じ
旧社名と新社名で会社レコードが分裂法人・企業識別情報で同一企業を確認し、表示名を更新名称一致だけで新会社扱いしない
同姓同名
別会社に同じ氏名
誤統合すると別人へ活動・配信履歴が混ざる会社、メール、電話、部署など複数情報で照合。不確実なら別レコード氏名だけで自動マージしない

Sansan Data Hubは企業の名寄せについて、企業名や住所、電話番号など9つの情報を組み合わせて識別し、社名変更や吸収合併のような表記だけでは判断しづらいケースにも対応するとしています。公式ページでは、条件を満たす顧客データについて99%の精度で企業を識別するとの注記もあります。これもベンダー公表値です。人物の同姓同名まで「99%で自動統合できる」と読み替えてはいけません。

同姓同名はむしろ慎重に扱います。別人を一つにまとめる誤統合は、重複を残すより修復コストが高いからです。迷うケースは自動マージせず、候補として管理者へ回すほうが安全です。

異動・退職・社名変更は「上書き」ではなく、現在値と履歴を分ける

Sansanの名刺管理機能では、自動名寄せによって顧客の役職や所属部署の変更を検知した場合、その名刺を持つ社員へ通知する仕組みが案内されています。これはCRM連携で非常に価値があります。ただし、通知を受け取った後に何をするかを決めていないと、「へえ、異動したんだ」で終わります。

営業運用では、異動を三つに分けると扱いやすくなります。同一企業内の部署異動なら現在部署・役職を更新し担当営業へ通知。別企業への転職なら旧企業との接点履歴を残したまま、新企業側で人物を関連づけ直す。退職で新しい所属が不明なら、営業対象から外しつつ過去履歴は保持する、という分け方です。

社名変更も同じです。表示名は新社名へ更新してよい一方、過去の商談や契約書で旧社名が使われていることがあります。企業コードや法人番号など安定した識別子を軸にして、名称だけを会社IDとして扱わない設計が重要です。

スポンサーリンク

API・自動連携・CSVは「最初の楽さ」ではなく、更新が何回続くかで選ぶ

方式向く場面弱点運用で必要なもの
専用連携/Data HubSalesforce・HubSpotなどで継続更新したい契約・オプション・対応項目の確認が必要正本、名寄せ条件、上書き項目、エラー監視
Open API/プラグイン既存の業務フローへ組み込みたい、対応サービスを利用する設計次第で更新経路が複雑になる一意キー、同期方向、再実行、ログ
CSV初回移行、月次更新、件数が少ない差分更新・重複・取り込み漏れが人に依存ファイル命名、担当、更新日、重複処理ルール

CSVは初回移行には十分でも、2回目以降に差が出ます。全件上書きか差分か、退職・異動をどう反映するかを決めないと、担当者しか分からない手順になりやすいです。

連携頻度も最短が正解ではありません。展示会後は短く、休眠顧客の属性更新なら月次でもよい。情報が変わってから営業判断へ使うまでの許容時間で決めます。

連携しても案件化しない会社は、営業への通知条件が抜けている

顧客データがきれいになっても、それだけでは売上につながりません。最後に必要なのは「何が変わったら誰が動くか」です。たとえば、既存顧客のキーパーソンが別会社へ転職した、休眠企業に新しい部長との接点ができた、ターゲット企業で複数名との名刺交換が短期間に増えた、といった変化は営業アクションの候補になります。

一方、すべての名刺登録を営業へ通知すると通知疲れが起きます。通知条件は「役員・部長クラスへの異動」「ターゲット企業の新規接点」「担当企業から別企業への転職」のように絞り、通知先も会社担当者、名刺所有者、インサイドセールスのどこへ渡すか決めます。MAを使う場合も、データ更新とホットリード判定は別イベントとして扱うほうが整理しやすいです。

前の記事で整理したように、MAは見込み客の母数と営業への引き渡し条件がなければ定着しません。SansanからMAへ顧客を増やす前に、MAツールを導入する条件と営業への引き渡し設計も合わせて確認してください。

導入前に決めておく10項目――これが空欄なら連携を急がない

  1. 顧客の正本:会社・人物・商談・配信可否をそれぞれどのシステムが持つか。
  2. 一意キー:会社名や氏名だけに頼らず、どの識別子を使うか。
  3. 新規作成条件:CRMに存在しない名刺を全件作るのか、対象企業だけにするか。
  4. 更新項目:Sansan側から上書きしてよい項目と禁止する項目。
  5. 重複時の処理:自動統合、候補表示、管理者確認の境界。
  6. 異動・転職:旧所属の履歴と新所属の現在値をどう保持するか。
  7. 退職:配信停止、営業対象外、履歴保持をどの状態で管理するか。
  8. 連携頻度:リアルタイム、10分単位、日次、月次のどこまで必要か。
  9. エラー責任者:同期エラーや未名寄せレコードを誰が週次で見るか。
  10. 営業通知:データが変わった時、誰にどの条件でアクションを促すか。

この10項目を決めずに連携機能のデモを見ると、「自動で入る」「属性が増える」ことに目が行きます。先に運用表を作り、その条件を満たす方法としてData Hub、API、CSVを選ぶ順番にしてください。

Sansan連携が向く会社、まだCRM連携を急がない会社

連携効果が出やすいのは、すでにSalesforceやHubSpotへ顧客が大量に入り、重複や古い部署情報が営業判断を邪魔している会社です。複数部署が名刺を持ち、同じ企業へ別々にアプローチしている会社も、企業・人物を横断して整理する価値があります。展示会や訪問で新しい名刺が継続して増え、CRMへの手入力が追いつかない会社も対象です。

急いで連携しなくてよいのは、名刺が月数十枚程度で、CRMの顧客数も少なく、営業担当者が一人で全顧客を把握できる会社です。また、CRM自体の会社・人物・案件の使い分けが定まっていない状態でSansanだけをつなぐと、汚れたCRMへ高速でデータを足すことになります。先にCRM側の項目整理をしてください。

SFA側の入力や案件ステージがまだ定着していない場合は、連携より先に営業が入力し続けられるSFAの設計を整えたほうが効果的です。

最後に決めるのは連携方法――最初に決めるのはデータの責任

Sansanは99.9%の名刺データ化精度、Data Hubによる名寄せ、100種類を超える属性付与、外部システム連携を案内しています。ただし営業成果へ変えるには、自社側のデータ責任が必要です。

スポンサーリンク

会社・人物・商談・配信可否の正本を決め、重複、異動、社名変更、同姓同名の例外を決めてから、Data Hub、API、CSVを選ぶ。この順番ならデータの意味がぶれません。

公式仕様の確認には、Sansan 名刺管理Sansan Data HubSansan API連携Salesforce連携を参照できます。契約プランやオプションによって利用条件が異なる場合があるため、導入時は最新の契約条件も確認してください。

連携先の位置づけは、SansanSalesforceHubSpotSATORIMarketoMazricaの各ページで確認できます。製品名より先に、人物・会社・商談・配信可否のどれを各システムの正本にするかを決めてください。

よくある質問

SansanとSalesforceを連携すれば、Salesforceの重複データは自動で全部きれいになりますか?

全部が自動で解決するわけではありません。Data Hubは名寄せと取引先・取引先責任者・リードの作成・更新を支援しますが、独自項目や過去の誤登録、同姓同名は運用ルールと確認が必要です。

SansanとHubSpotはCSVを使わないと連携できませんか?

現在はCSVだけではありません。Sansanは2025年2月にData HubからHubSpotの「会社」「コンタクト」へ自動連携する機能を公開しています。利用条件は契約時に確認してください。

SansanからMarketoへ直接連携するべきですか、それともSalesforce経由がいいですか?

SalesforceとMarketo Engageを同期済みなら、Salesforceを正規ルートにできないか先に検討します。直接連携とCRM経由を併用して更新元を増やさず、同期方向と正本を一本化できる構成を優先してください。

部署異動した人は、CRMの旧レコードを削除したほうがいいですか?

単純削除では過去の営業履歴まで失います。現在の所属は更新し、旧会社・旧部署の接点や商談は履歴として残す設計が扱いやすいです。

Sansan Data Hubの100種類を超える属性情報は全部CRMへ連携できますか?

すべてとは限りません。Sansanは連携できる属性情報の数が連携先サービスにより異なると明記しています。必要項目を先に決め、実際の連携先で確認してください。

顧客データ連携は、CRM選定、SFA定着、MA導入の後に「データをどう使い続けるか」を決める段階です。最初から整理する場合はSalesforceとHubSpotの選定軸から順に確認できます。

← JOURNALに戻るSaaS一覧を見る →

スポンサーリンク