名刺の名寄せとは、同じ人・同じ会社を表す名刺やCRMのレコードを突き合わせ、1つにまとめることです。名刺管理ツールとZoho CRMの自動同期とは、名刺管理ツールに登録された名刺を、人の手を介さずにZoho CRMの見込み客・連絡先・取引先へ反映し続ける仕組みです。ただ「つなぐ」だけなら連携拡張機能で済みますが、実際の運用で困るのは、同じ人が何件も登録される、営業が直した情報が上書きされる、担当者が取引先に紐づかない、といった名寄せの問題です。
この記事では、当社が複数の案件で組んできた同期の設計を、技術担当の目線でまとめます。題材は、複数の業種（製造業、非営利団体、BtoB企業）での構築と検討です。ツール選びの比較は「ZOHO CRMと名刺管理アプリの連携の比較３選」、名刺登録後のお礼メールの自動化は「名刺交換時のお礼メール送信を自動化をZOHO CRMで実装してみた」で扱っているので、ここでは「つないだ後に、データをどう正しく保つか」に絞ります。
名刺管理ツールの標準の連携拡張機能だけでは足りないのか
名刺管理サービスの多くは、Zoho Marketplaceに連携拡張機能を出しています。設定画面で項目の対応づけをするだけで使えるので、まずはこれを試すのが自然です。
ただ、すでに拡張機能を使っている開発者への聞き取りでは、次の制約があるとのことでした（2025年秋時点の聞き取りで、公式ドキュメントでは確かめられていません）。
- 連携先は見込み客か連絡先のどちらか一方だけを選ぶ
- 拡張機能そのものには重複チェックがない。同じ人の名刺が重複していても、すべて新しいレコードとして入る
- Zoho CRM側でメールアドレスの重複を禁止する設定にすると、連携がエラーになる
- 同期はリアルタイムではなく定期のまとめ処理。実行時刻は拡張機能をオンにした時刻に左右される
- 初めて同期したときに、蓄積済みの名刺が一度に流れ込むかどうかは、事前に提供元へ確認が必要だった
この状態で運用を続けると、現場では次のような困りごとが起きます。ある企業での打ち合わせでは、連絡先には名刺連携から入ったデータが多いとのことで、この3つが営業の入力負担になっていました。
- 上書き：名刺をスキャンし直すたびに、営業が手で直した最新情報が名刺の古い値に戻る
- 重複：社名変更の前後の名刺が、同じ人の別レコードとして並ぶ
- 紐づけ漏れ：担当者は登録されても、どの取引先の人なのかがつながらない
どれも「同じ人・同じ会社かどうかを、誰が、どの順で判断するか」を決めていないことが原因です。そこで、名寄せを自前の処理として組みます。
全体設計：取得→移行→同期の3段に分ける
ある企業で組んだ構成では、処理を3つの関数に分けました。
| 段 | 何をするか | 出力先 |
|---|---|---|
| ① 取得 | 名刺管理ツールのAPIから、前回以降に更新された名刺を取る | 表計算シートの「取得済み」 |
| ② 移行 | 取得済みのうち、取得に成功した行だけを「処理待ち」に並べる | 表計算シートの「処理待ち」（状態＝未処理） |
| ③ 同期 | 処理待ちを読み、Zoho CRMへ名寄せして登録・更新する | 見込み客・連絡先・取引先と、シートの処理状態 |
3段の関数はZoho CRMの関数（Deluge）で書き、外側の表計算側のスクリプトが15分おきに①→②→③の順で呼び出します。各関数は「続きあり」を返す限り、上限回数まで繰り返し呼ばれます。
1つの関数にまとめず分けた理由は3つです。
- 時間切れに強い：関数1回あたりの実行時間には上限があります。段ごとに小分けにすれば、件数が多くても途中で切れません
- 続きから再開できる：取得のページ位置、移行と同期の最終処理行を、Zoho CRMの組織変数（組織全体で共有する設定値。公式ヘルプ）に保存しています。途中で止まっても、次の起動で続きから動きます
- 失敗の場所が分かる：名刺の取得で失敗したのか、CRMへの書き込みで失敗したのかが、シートの状態を見ればすぐ分かります
処理量のボトルネックは③の同期です。1件ごとにCRMを検索するためで、当社の構成では同期を100件ずつに区切りました。数千件の初回取り込みは、15分ごとの起動を何回かまたいで進む前提で計画します。
本番切り替えのため、サンドボックス（検証環境）か本番かを組織変数で切り替えられるようにしておくと、移行時の書き換えが1か所で済みます。
名刺の名寄せはどの順番で判定するか
③の同期では、名刺1件ごとに次の順で判定します。
- メールアドレスがなければ止める。自動では作成も更新もせず、要確認にする
- メールアドレスで連絡先を探す。見つかれば、その連絡先を更新する。名刺の会社名が今の取引先と違うときは取引先を探し直し、紐づけを変える
- 連絡先になければ、見込み客を探す。このとき「リードソース＝名刺連携」の見込み客だけを対象にする。フォームなど別経路で入った見込み客を勝手に書き換えないためです
- どちらにもなければ、見込み客を新しく作る（リードソース＝名刺連携）
- 結果をシートに書き戻す（状態、CRMのレコードID、エラー内容）
既存レコードをどこまで上書きするかも、ここで決めます。当社が別の案件で組んだ例では、次のルールにしました。
- 名刺連携で作ったレコード：新しい名刺の値で更新する（名刺側が空欄なら更新しない）
- 手動で管理しているレコード：空欄の項目だけを補完する
- 既存レコード側の「名刺の最終更新日時」のほうが新しい場合：古い名刺で基本情報を上書きしない
この3つで、「スキャンし直したら手入力の情報が消えた」という上書きの問題を防ぎます。
会社名の表記ゆれはどう正規化するか
取引先を探すときは、会社名をそのまま比べず、表記ゆれを減らした「正規化会社名」で比べます。当社の構築例のルールは次のとおりです。
- 英字は小文字にする
- 半角スペースと全角スペースを削除する
- 法人格を削除する。対象は株式会社、有限会社、合同会社、一般社団法人、公益社団法人、一般財団法人、公益財団法人、国立研究開発法人、独立行政法人、国立大学法人の10種
- 255文字を超えるときだけ切り詰める
- 記号は削除しない
合資会社、合名会社、特定非営利活動法人、学校法人、医療法人、社会福祉法人などは、この例では削除対象に入れていません。対象にするかどうかは、自社の取引先にどの法人格が多いかで決めてください。
Delugeで書くと次の形です。
companyName = ifnull(card.get("Company_Name"),"");
normalizedCompany = companyName.toLowerCase();
// 半角と全角のスペースを1つずつ消す（\sは使わない）
normalizedCompany = normalizedCompany.replaceAll(" ","");
normalizedCompany = normalizedCompany.replaceAll(" ","");
normalizedCompany = normalizedCompany.replaceAll("国立研究開発法人|独立行政法人|国立大学法人|株式会社|有限会社|合同会社|一般社団法人|公益社団法人|一般財団法人|公益財団法人","");
if(normalizedCompany.length() > 255)
{
normalizedCompany = normalizedCompany.left(255);
}会社名だけで取引先を確定しない
正規化しても、会社名の一致だけで取引先を決めるのは危険です。同名の別会社や、グループ会社の取り違えが起きるからです。当社の例では、正規化会社名が一致し、かつ名刺のメールドメインが、取引先のWebサイトまたは代表メールのドメインと一致したときだけ自動で確定します。メールドメインがない名刺で会社名だけが一致した場合は、要確認で止めます。
比較のときは、取引先のWebサイトからドメインだけを取り出します。
website = ifnull(account.get("Website"),"").toString().toLowerCase().trim();
website = website.replaceAll("^https?://","");
website = website.toList("/").get(0);
website = website.replaceAll("^www[.]","");
domainMatches = (website != "" && website == emailDomain);失敗談：正規表現の書き方で「s」が消えた
ある案件では、正規化した会社名から英字の「s」だけが消える不具合が出ました。空白をまとめて消そうとして \\s のような書き方をしたところ、Delugeでは意図どおりの「空白」として扱われず、文字の s まで削除対象になっていたのが原因でした（同じ正規表現を手元で実行し、本番に保存されていた値と同じ結果になることで確かめました）。半角・全角スペースを1つずつ消す書き方に直して解消しました。
同じ原因で、メールアドレスとURLの形式チェック（\\. を使った判定）が正しいアドレスまで不一致と判定し、その時刻以降に同期した名刺だけメールとURLが空欄で保存されていました。対策は2つです。
- ドットは
\\.ではなく文字クラス[.]で書く - 形式チェックに通らない値は「空欄で上書きする」のではなく「送らない」。既存の値を壊さないためです
正規表現を使う処理は、本番に入れる前に、正しい値と誤った値の両方を数件流して結果を確かめてください。
「要確認で止める」運用
名寄せで一番大事なのは、自動で決めきれないときに無理に統合しないことです。間違った統合は、重複よりも直すのが大変です。重複を自動でまとめない考え方は「CRMの重複チェックは「自動マージしない」設計にする｜キー別の判定と重複フラグの運用」でも詳しく扱っています。当社の例では、次の場合に名寄せを止め、名刺レコードの処理状態を「要確認」にします。
- メールアドレスがない
- 会社名は一致したが、メールドメインで確かめられない
- 取引先の候補が複数ある
- 同じ人物IDやメール・携帯電話に一致する候補が複数ある
- 同じ取引先の配下に、担当者の候補が複数ある
- 見込み客の候補が複数ある
- 名刺が、連絡先と見込み客の両方に関連付いている
- 見込み客を法人向けと個人向けのレイアウトで分けていて、名刺が個人向けの見込み客に関連付いている
最後の項目は、法人と個人の両方を扱う組織で起きます。名寄せの検索対象を法人向けレイアウトの見込み客に限り、新規作成も法人向けレイアウトに固定しました。レイアウトを途中で変えるときは、名寄せ処理が書き込む項目が移行先のレイアウトに全部そろっているかを先に確かめます。レイアウトにない項目は保存時に無視されるため、重複判定に使う項目が抜けると重複防止が効かなくなるからです。
人が直しやすいエラー詳細を残す
要確認の名刺には、止まった理由に加えて、候補レコードの種類・名前・ID・CRMで直接開けるURLを、エラー詳細の項目へ1件ずつ改行して残します。候補が多いときは10件まで表示し、残りは件数だけを書きます。担当者はURLを開いて正しいレコードを選ぶだけで済みます。
直したら、保存し直すだけで再処理する
人が関連付けを直した後、もう一度名寄せを走らせる方法も決めておきます。当社の例では、名刺レコードを手動で保存すると名寄せのワークフローが再実行される条件にしました（名刺の元データを表す値が入っている場合に限る）。名寄せ関数が自分で保存したときには再実行されないようにして、処理が無限に繰り返されるのを防いでいます。
API失敗は専用モジュールに退避する
名寄せの判断とは別に、APIの呼び出し制限や一時的な通信エラーで失敗することもあります。最初に挙げた3関数の構成では、失敗した名刺を「同期エラーキュー」というカスタムモジュールに退避し、あとで再処理する設計にしました。主な項目は次のとおりです。
- 名刺ID（必須）、人物ID、会社ID、メール、氏名、会社名
- エラー種別（呼び出し制限超過／APIエラー／データエラー）とエラーメッセージ
- 失敗日時、リトライ回数、ステータス（待機中／処理中／完了／失敗）
「待機中」「失敗」のビューを作っておくと、毎朝どこを見ればよいかがはっきりします。
運用で見る画面を決めておく
同期は止まっていても気づきにくい仕組みです。当社の例では、運用担当が見る画面を4つに絞りました。
- 同期の状態・最終成功日時・処理件数（組織変数）
- 定期実行が有効か、次回はいつか（スケジュール設定）
- 名刺管理ツールとの接続状態（外部連携の設定）
- 要確認とエラーの一覧（名刺モジュールの専用ビュー）
導入前のチェックリスト
- 取り込み先は見込み客か、連絡先か、両方か。既存顧客の名刺をどう扱うか決めたか
- 名寄せのキー（メール）と、メールがない名刺の扱いを決めたか
- 会社名の正規化ルールと、削除する法人格の一覧を決めたか
- 会社名だけの一致で取引先を確定しないルールになっているか
- 名刺連携で作ったレコードと、手動管理のレコードで、上書きのルールを分けたか
- 要確認の条件、エラー詳細の書き方、直した後の再処理の方法を決めたか
- 初回同期で蓄積済みの名刺がどう流れるか、提供元に確認したか。サンドボックスで少量から試したか
- 正規表現を使う処理を、正しい値と誤った値の両方で試したか
名刺以外の経路（表計算や他システム）から入った顧客データも同じルールで名寄せしたい場合は、「散らばった顧客データをZoho CRMに統合する｜メール→ドメイン→取引先の名寄せルールと一括取込」も参考にしてください。
名刺の同期は、作った直後よりも、半年後に「重複が増えた」「情報が古い」と言われないことのほうが大事です。止めるべきところで止め、人が直しやすい形で残す。これが、名刺をCRMの資産として使い続けるための設計です。
名刺管理ツールとZoho CRMの連携設計は、Zoho導入支援・コンサルティングでご相談いただけます。
よくある質問
Zoho Marketplaceの名刺連携拡張機能だけでは足りませんか？
名刺の件数が少なく、取り込み先が見込み客だけでよいなら十分なこともあります。ただ当社が確認した時点では、連携先は見込み客か連絡先の一方だけで、拡張機能自体に重複チェックはありませんでした。既存の連絡先と同じ人の名刺が見込み客として増えていくため、既存顧客が多い会社ほど、別途名寄せの処理が必要になります。
名寄せのキーにメールアドレスを使う理由は何ですか？
氏名は同姓同名や表記ゆれがあり、会社名は社名変更や略称で変わるため、1人を特定する軸としては弱いからです。メールアドレスは表記がほぼ一意です。ただし名刺にメールがないこともあるので、その場合は自動で作成・更新せず「要確認」で止めます。
会社名の正規化で記号も削除したほうがよいですか？
当社の構築例では記号は削除していません。記号を消すと別会社が同じ文字列になる可能性が増えるためです。正規化は「表記ゆれを減らす」ためのもので、それだけで取引先を確定させない前提で設計します。
要確認で止まった名刺はどう処理しますか？
エラー詳細に出ている候補レコードを開き、正しい取引先・連絡先を人が決めて関連付けを直します。その後、名刺レコードを手動で保存し直すと名寄せが再実行される仕組みにしておくと、担当者がCRMの画面だけで完結できます。
名刺のスキャン内容で、営業が手入力した最新情報が上書きされませんか？
上書きのルールを決めておかないと起きます。当社の構築例では、手動で管理しているレコードは空欄だけを補完し、名刺連携で作ったレコードは新しい名刺の値で更新します。さらに既存レコード側の名刺更新日時のほうが新しい場合は、古い名刺で上書きしないようにしています。
