CRM・SFAが定着しない

CRM連携が止まる原因は、機能ではなく照合キーの設計でした

公開 2026年8月20日

既存の顧客台帳とCRMをつなぐ案件で、要件が固まらない理由の大半は連携ツールの機能ではありません。

2つのレコードを同一の相手と判定する項目が決まっていないことと、項目ごとにどちらのシステムを正とするかが決まっていないことです。

連携先を選ぶ前に、この2つを決めてください。順序を逆にすると、ツールを選び終えてから要件定義が止まります。

「同じ相手」をどう判定するかで、会話が止まった

kintoneで数万件規模の顧客台帳を運用してきた企業が、新規事業でHubSpotを使い、フォーム経由の獲得と配信を回す。既存顧客は台帳側に、新規はCRM側に増えていく。二重入力を避けるため、両者を自動同期する。

要望としては単純です。実際に会話が止まったのは、次の一文でした。「同じ相手だと、どうやって判定しますか」

日本の法人顧客の台帳には、個人のメールアドレスが入っていないレコードが珍しくありません。代表電話と部署宛の住所、担当者名は姓のみ。この状態で「氏名と会社名が一致したら同一人物」という運用ルールを作ると、同姓の別人が統合されます。

ツールを選ぶ前に、照合項目と正のシステムを決めた

決めたのは3点です。

1. 照合する項目を1つに決める。 HubSpotのデータ同期で照合項目を自分で指定する場合、一意の識別子に選べるのはテキスト型の項目で、一致判定に使われるのは選んだ1項目だけです（HubSpotナレッジベース「Match records in data sync」）。「氏名と会社名とメールアドレスの3つが揃ったら同一」という設計は、この機構では組めません。1項目に絞れないなら、それは連携の設計ではなく名寄せの設計です。先に片付けます。

2. 一意のIDを、どちらが発番してどちらが保持するか決める。 CRM側が自動採番するレコードIDを識別子にする場合、それは相手側にも同期済みで両者が共有している状態が前提です。つまり初回は別の項目で当て、その時に生まれたIDのペアで以降を回す、という二段構えになります。台帳側にはIDの保持用項目を追加し、一般ユーザーは編集できないようにします。

3. 項目ごとに正を決める。 住所は台帳が正、行動履歴はCRMが正、会社名はどちらか。ここを決めずに双方向同期を入れると、両側で更新された項目が上書きし合います。決められない項目は、双方向ではなく一方向にします。

採らなかった案は、中間システムを作って独自の名寄せロジックを持つことでした。判定基準が言語化できていない段階でロジックを書くと、誤統合の責任がシステムに移り、誰も直せなくなります。

連携すると運用は減らず、確認と整理の担当が増える

連携を入れると運用は減りません。増えます。

同期の失敗レコードと除外レコードを日次で確認する担当、CRM側で重複を統合したときに台帳側を後追いで整理する担当、相手側起点で作られたレコードの空欄を埋める担当が要ります。台帳側の必須項目が多いほど、CRM起点のレコードは保存に失敗し続けます。連携の前に、受け側の必須項目を見直す作業が入ります。

もう1点、誤解しやすい仕様があります。同期対象を絞るフィルタは、初回にどのレコードを同期するかを制御する機能で、一度同期したレコードの継続同期を止める手段ではありません。フィルタを入れたから安全、とは言えません。

数字の面から見ても、この作業は例外ではなく標準です。IPAが2025年2月10日から3月28日に実施した「DX動向2025」（日本の回答企業n=1,400）では、データ整備・管理・流通の課題として「データ管理システムが整備されていない」を挙げた企業が43.4%、「既存システムがデータの利活用に対応できない」が22.6%、「全社的なデータ利活用の方針や文化がない」が**37.2%でした。HubSpot Japanがマクロミルに委託して2023年11月24日から27日に実施した年次調査（売り手n=1,545、従業員51〜5,000名）でも、営業組織でデータを活用するうえで79%**が何らかの困りごとを挙げ、「営業部署内のデータが適切に管理されていない」28.1%、「他部署とのデータ連携が進んでいない」24.4%が上位に入っています。後者はCRMを販売するHubSpotの自社調査であり、結論が同社の営業メッセージと一致する点は割り引いて読む必要があります。

連携で最初に決めるのは、どのツールを使うかではなく、2つのレコードを同一と判定する項目と、項目ごとにどちらのシステムを正とするかです。

今週、連携を検討している案件を1つ開いて、この2つが文書に書いてあるかを確認してください。書いていないなら、比較しているのは連携ツールの機能ではなく、まだ決めていない自社の設計です。

システムをまたいだ顧客データを収益の構造としてどう置くかは、レベニューアーキテクチャとはにまとめています。