--- title: "MA・SFA・CRM連携とは？データ所有の決め方と導入順序の判断基準を解説" url: "https://www.issoh.co.jp/column/details/17495/" published: 2026-09-08 updated: 2026-09-08 categories: ["ERP"] publisher: "株式会社一創" --- # MA・SFA・CRM連携とは？データ所有の決め方と導入順序の判断基準を解説 MA・SFA・CRMを3つとも導入したのに、同じ会社が3か所に別々の名前で登録されている。連携の相談で最も多いのがこの状態です。原因は連携方式の選び間違いではなく、どのデータをどのツールのマスタにするかを決めないまま同期を始めたことにあります。この記事で扱うのは、顧客・リード・商談・行動履歴の4種をどこに置くか、同一項目の更新権限をどう一方向に固定するか、メールアドレス基準の名寄せが崩れる条件、MAからSFAへリードを渡す基準、そして3ツールを揃えない判断です。API連携やiPaaSといった方式そのものの比較は別記事に委ねます。 ## まとめ：MA・SFA・CRM連携で先に決めるデータ所有と導入順序の結論 結論から示します。データ所有は「顧客・企業情報はCRM、商談はSFA、Web閲覧やメール開封などの行動履歴はMA」に置き、同一項目を両側から書き換えられる状態を作らないことが設計の中心です。同期の方向を項目単位で一方向に固定すれば、二重管理は連携方式に関係なく解消します。 名寄せキーはメールアドレス単独に頼らないでください。HubSpotはコンタクトをEmail、会社をCompany domain nameで自動判定し、Zoho CRMはupsert時にduplicate\_check\_fieldsで判定順序を指定します。この2つの仕様が示すのは、個人と法人で一意キーが別物だという事実です。個人アドレスの変更と部署異動が起きる法人営業では、CRMのレコードIDや取引先コードを主キーに据え、メールアドレスは補助キーとして扱うほうが崩れません。 導入順序はCRMとSFAを先に固め、MAは後から接続します。逆順にすると、育成したリードの受け皿がないまま、MAの中でリードが滞留する構図です。営業5名・月間商談30件以下の体制であればMAは見送り、CRM/SFAの入力精度を上げるほうが投資効率は上がります。連携をどの方式で実装するかは、[CRM連携の設計と方式選定を扱った記事](https://www.issoh.co.jp/column/details/15591/)で、API・iPaaS・CSV・標準コネクタの4方式として比較しています。 ## MA・SFA・CRMが扱うデータ範囲と3ツールで重複する項目の切り分け 3ツールは役割が違うだけでなく、保持するデータが一部重なります。重なる部分が二重管理の発生源です。役割そのものの違いは[SFAとCRMの違いを比較した記事](https://www.issoh.co.jp/column/details/12808/)で整理しているため、ここでは重複領域だけを扱います。 ### MAが持つ行動データとCRMの顧客マスタで重複する具体的な項目 MAが記録するのは、メール開封、リンククリック、フォーム送信、資料ダウンロード、Webページの閲覧履歴です。これらはCRMに持たせる必要がありません。問題になるのは、その手前にある会社名・部署名・役職・電話番号です。MAはフォーム入力値をそのまま保存するため、来訪者が「株式会社一創」と入れた翌月に「一創」と入れれば、MA側には2つの表記が並びます。 CRM側の顧客マスタは営業事務が名刺や登記情報をもとに整えた正規表記です。ここにMAのフォーム入力値を上書き同期すると、整えた表記が来訪者の入力で壊れます。逆にMA側へCRMの正規表記を配るぶんには害がありません。重複項目のうち属性情報はCRMを起点にした一方向、行動情報はMAだけが持つ、という切り分けが出発点になります。 判断基準は単純です。人が手で整える項目はCRM、機械が自動で積み上がる項目はMAに置きます。 ### SFAの商談情報とCRMの取引履歴が二重管理へ変わる具体的な分岐点 SFAは進行中の商談、CRMは確定した取引と顧客との関係を持ちます。境目は受注です。受注前のフェーズ・確度・次回アクション・見積金額はSFAだけが更新し、受注後の契約金額・稼働開始日・請求先はCRMまたは基幹に移します。 二重管理へ変わる分岐点は「失注案件の扱い」と「同一顧客の複数商談」です。失注をSFAで閉じたあと、CRMの顧客メモに営業が「今期は予算なし」と書き込む運用を始めると、次の提案時期の判断材料が2か所に分かれます。同一顧客に3件の商談が並走している場合も、CRM側で顧客単位の温度感を持たせるとSFAの商談別確度と矛盾します。 解決策は、顧客単位の温度感をCRMに持たせないことです。温度感は商談に紐づく属性としてSFAだけが持ち、CRMには受注実績と契約情報だけを残します。営業が顧客メモに書きたい内容は、SFAの活動履歴へ入力先を寄せてください。 ## 二重管理を避けるデータ所有の決め方とマスタ配置・更新権限の設計 データ所有とは、そのデータについて「正しい値はここにある」と全社で合意した置き場所のことです。連携の設計書を書く前に、この割り当てを1枚の表で確定させます。 ### 顧客マスタ・リード・商談・行動履歴の4種をどこに置くかの判断 4種のデータについて、マスタの置き場所と更新できる部門を先に固定します。下表は法人向けの受託・提案型ビジネスで標準的な配置です。 | データ種別 | マスタの置き場所 | 更新できる系統 | 他ツールでの扱い | | ------------- | -------- | ----------- | --------------- | | 企業・顧客の属性情報 | CRM | 営業事務／CRM管理者 | SFA・MAは参照のみ | | リード（商談化前） | MA | マーケティング部門 | 商談化時にCRMへ昇格 | | 商談・確度・次回アクション | SFA | 営業担当 | CRMは受注結果のみ受領 | | 行動履歴・スコア | MA | MAが自動記録 | CRM・SFAは要約値のみ参照 | | 問い合わせ・サポート履歴 | CRM | サポート部門 | MAはセグメント条件として参照 | 迷いやすいのがリードです。名刺交換した相手をすぐCRMへ入れる運用にすると、顧客マスタが未検証の見込み客で膨らみ、CRMのレコード数課金が増えます。商談化していない連絡先はMAに置き、初回商談が設定された時点でCRMへ昇格させる境界にしてください。この昇格の瞬間だけは人の判断を入れ、自動化しないほうが精度が保てます。 ### 同一項目を双方から更新させないための書き込み権限の一方向ルール データ所有を決めても、同期設定で双方向を選ぶと崩れます。双方向同期は「後から更新したほうが勝つ」挙動になるため、夜間バッチと担当者の手入力が競合したとき、どちらが残ったか追跡できません。 実装時のルールは3つに絞れます。第一に、項目ごとに書き込み側を1つだけ決める。第二に、書き込み側でない側の画面ではその項目を読み取り専用にする。第三に、どうしても双方向が必要な項目（電話番号など連絡先の実務更新が両側で起きるもの）は、更新日時を比較する条件ではなく「CRM側を常に正とする」固定ルールにする。 読み取り専用の設定を省くと、権限設計は必ず破られます。営業がSFAの画面から会社名を直せる状態を残せば、そこから直します。画面側で塞ぐところまでが連携設計の範囲です。 ### メールアドレスを基準にした名寄せが崩れる条件と代替キーの決め方 多くのツールは、メールアドレスを一意キーの既定値に据えた設計です。[HubSpotの公式ドキュメント](https://knowledge.hubspot.com/records/deduplication-of-records)では、新規コンタクトはEmailプロパティ、新規会社はCompany domain nameの主値で自動的に重複排除され、カスタムの一意値プロパティは各オブジェクトで最大10個まで設定できると明記されています。Zoho CRMも[upsert APIの仕様](https://www.zoho.com/crm/developer/docs/api/v8/upsert-records.html)で、duplicate\_check\_fields配列に指定した順序で重複を検証します。 この既定値が崩れるのは次の3条件です。担当者が転職や異動でアドレスを変える場合、代表アドレス（info@）でフォーム送信される場合、そして1人が個人アドレスと会社アドレスを併用する場合です。いずれも法人営業では珍しくありません。 代替キーの決め方はこうです。法人は自社ドメイン、または法人番号のように外部で一意性が担保された値を主キーにする。個人はCRMのレコードIDを主キーにし、メールアドレスは変更履歴を残す補助キーとして扱う。ツール間の連携ではCRMのレコードIDを外部IDとしてMA・SFA双方の項目に保持させ、同期の突き合わせはこの外部IDで行います。メールアドレスで突き合わせる設計は、初期構築は速く、運用2年目に破綻します。 ## MAからSFAへリードを渡す引き渡し基準とデータ同期頻度の決め方 データ所有が決まったら、次に決めるのはリードの受け渡しです。ここが曖昧なままだと、MAは動いているのに営業が誰にも接触しない状態になります。 ### MQLとSQLの定義を数値で固定するスコアと行動条件の置き方 MQL（マーケティング側が渡せると判断したリード）とSQL（営業が商談化可能と認めたリード）の線引きは、スコアの合計点だけで決めないでください。合計点は「メルマガを毎回開くだけの情報収集者」を上位に押し上げます。 実務で機能するのは、スコアと行動の2条件を掛け合わせる方式です。たとえば「スコア50点以上」かつ「料金ページまたは導入事例ページを直近14日以内に閲覧」をMQLの条件に置きます。加えて、従業員数や業種のような属性条件で足切りを入れます。数値は最初から正解を狙わず、月次で営業からの差し戻し件数を見て調整する前提で置いてください。 差し戻しの理由をMAへ書き戻す経路も同時に作ります。SFA側に「商談化不可の理由」を選択式で持たせ、その値をMAのリード項目へ返す。この1項目があるだけで、MQL条件の見直しが感覚論から数字の話に変わります。 ### SFAで失注したリードをMAへ戻す再ナーチャリングの経路設計 失注や商談化不可のリードを放置すると、3ツール連携の投資が回収できません。戻す経路は、失注理由で3つに分けて設計します。 - 予算・時期の問題（半年後に再検討の可能性あり）：MAの長期育成シナリオへ戻し、四半期ごとの事例メールを配信対象にする - 要件不適合（提供できない領域だった）：配信対象から除外し、CRM側で除外理由を保持する - 他社決定（競合が入った）：契約更新時期を推定して12か月後に再接触リストへ入れる この分岐を自動で回すには、SFAの失注理由の選択肢とMAのシナリオ入口を1対1で対応させておく必要があります。選択肢を「その他」で受けている運用は、ここで手が止まります。失注理由の選択肢設計は、連携プロジェクトの初期に見直す対象です。 ### データ種別ごとに同期頻度を分ける準リアルタイムと日次の線引き すべてを即時同期にすると、APIの消費と障害時の影響が跳ね上がります。頻度は種別で分けてください。営業の初動が変わるデータ（MQL到達、フォーム送信、資料請求）は準リアルタイム、属性の整備結果（会社名の正規化、業種の付与）は日次バッチで足ります。行動履歴の明細は同期せず、MA側で参照する運用が軽く済みます。 件数の見積もりも先に立ててください。[HubSpotのCRM APIリファレンス](https://developers.hubspot.com/docs/reference/api/crm/objects/contacts)では、バッチ操作は1リクエストあたり100レコードが上限と定められています。初回移行で3万件を投入するなら300リクエスト、日次で属性更新を回すなら対象件数を100で割った回数が毎日発生する計算です。この計算を省くと、本番初日にAPI上限で同期が止まります。 障害時の扱いも決めておきます。同期に失敗したレコードを再送するのか、担当者へ通知して手動で直すのか。件数が少ない属性同期は通知で足り、MQL通知のような即時性の高い経路は自動再送を用意します。 ## 3ツール連携を採用しない判断：営業人数と商談件数で見る見送り条件 ここは他社の解説記事が触れない領域です。3ツールを揃えることが前提の議論になりがちですが、体制に見合わない構成は運用されずに終わります。条件を明示して言い切ります。 ### 営業5名・月間商談30件以下でMAを導入すると失敗する理由と代替策 営業が5名以下、月間の新規商談が30件以下の組織では、MAは導入しないほうがよいと考えます。理由は3つあります。第一に、シナリオ設計と配信コンテンツの制作に月10〜20時間かかり、兼任のマーケティング担当では回りません。第二に、月30件の商談であれば営業が全リードに直接接触できるため、スコアリングで優先順位を付ける価値が小さい。第三に、リードの母数が数百件規模だとスコアの分布が偏り、条件の妥当性を検証できません。 代替策は、CRM/SFAの入力精度を上げ、メール配信は配信専用ツールで済ませることです。休眠顧客への一斉配信程度であれば、CRMの標準メール機能で足ります。MAの検討に入るのは、リードが月100件以上積み上がり、営業が接触先を選ばなければ回らなくなってからです。ツールごとの機能差と選定基準は[MAツールの比較と選び方をまとめた記事](https://www.issoh.co.jp/column/details/13409/)で扱っています。 ### 3ツール個別導入と1ベンダー統合を月額と運用工数で比べた判断 3ツールを別々に選ぶか、1つのベンダーで揃えるかは、専任者の有無で決まります。 | 比較軸 | 3ツール個別導入 | 1ベンダーで統合 | | ------- | ---------------- | ------------------ | | 費用構造 | 3契約の合計＋連携の構築・保守費 | 1契約の上位プランに集約 | | 連携の作り込み | API開発またはiPaaSが必要 | 標準機能で完結しやすい | | 機能の深さ | 領域ごとに上位ツールを選べる | MA機能が専用ツールに劣る場合がある | | 入れ替え | 1つずつ差し替え可能 | 全体移行になり負荷が大きい | | 向く体制 | マーケ・営業に専任者がいる | 兼任で運用工数を抑えたい | 専任者がいない組織が3ツール個別構成を選ぶと、連携の保守が誰の担当でもなくなります。エラー通知が放置され、半年後に「同期が3か月止まっていた」と判明する事故はここから起きます。兼任体制なら1ベンダー統合を選び、MA機能の物足りなさは受け入れるほうが結果は良好です。 ### 導入順序の結論：CRMとSFAを先に固めMAを後から接続する条件 導入順序はCRMとSFAが先です。MAを先に入れる構成が失敗するのは、育成したリードの渡し先が整っていないためです。渡し先がなければ、MAはメール配信ツールとして使われ、スコアリングは誰も見ません。 先に固めるべき状態を具体化します。SFAに商談が漏れなく登録され、失注理由が選択式で記録されている。CRMの企業名表記が正規化され、重複レコードが全体の数%以内に収まっている。この2つが満たされた時点がMA接続の開始条件です。逆に、SFAの商談登録が営業任せで半分しか入っていない状態でMAをつなぐと、MQLの成果を測る分母が作れません。 順序を守れない事情がある場合、MAは接続せず単独で運用し、リードの引き渡しは手動のリスト出力で回してください。連携の自動化は、受け皿が整ってからでも遅くありません。 ## 連携プロジェクトの進め方と個人データ共有で先に固める合意事項 最後に、実装に着手する前の進め方と、個人データの取り扱いで確認しておく論点を整理します。 ### 要件定義から初回同期までにデータ所有の合意を固める5つの手順 手順は5つです。順番を入れ替えると、後工程で設計をやり直します。 1. 3ツールのデータを棚卸しする。項目名・件数・重複レコードの概数を洗い出す 2. データ所有の割り当て表を作り、マーケティング・営業・サポートの各部門長の合意を取る 3. 名寄せキー（法人はドメインまたは法人番号、個人はCRMのレコードID）とマッチングルールを確定する 4. 項目単位で同期の方向・頻度・失敗時の扱いを定義し、書き込み側でない画面を読み取り専用にする 5. 本番の全件同期の前に、100〜300件の少量で初回同期を試し、重複と欠損を突き合わせて修正する 2番目の合意形成を口頭で済ませると、稼働後に「営業側で会社名を直せないのは不便だ」という差し戻しが必ず来ます。割り当て表を文書として残し、変更したい場合は表を改訂する手続きにしてください。 ### ツール間で個人データを共有するときの同意取得と共同利用の整理 MA・SFA・CRMの連携は、社内システム間のデータ移動である限り第三者提供には該当しません。論点になるのは、グループ会社や販売代理店とデータを共有する構成、そして取得時の利用目的の範囲です。 個人情報保護委員会の[ガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)は2026年6月に一部改正されており、共同利用は法第27条第5項第3号として整理されています。共同して利用する者の範囲や利用目的などをあらかじめ本人に通知するか、本人が容易に知り得る状態に置く必要があります。グループ横断でCRMを共有する構成を採るなら、この通知内容を先に固めてから連携を設計してください。 もう1つの実務論点は、フォームの利用目的の記載です。資料請求フォームで取得した連絡先を、MAのスコアリングと営業のアプローチに使うのであれば、その旨が利用目的に含まれているかを確認します。記載を後から広げる場合は変更手続きが必要になるため、連携の要件定義と同じタイミングでフォームの文言を点検するのが手戻りの少ない進め方です。 ### 自社設計と外部委託を分ける連携対象数と項目マッピング量の目安 連携を自社で作るか委託するかの分かれ目は、対象システム数と同期項目数です。2ツール間で同期項目が20項目以下、標準コネクタが提供されている組み合わせであれば、社内の情報システム担当で設定しきれます。3ツール以上が絡み、同期項目が50を超え、条件分岐（商談ステージによって同期先を変えるなど）が入る場合は、設計と保守の負荷が担当者1人の範囲を超えます。 判断のもう一軸は、標準コネクタで足りるかどうかです。標準機能の項目マッピングでは表現できない変換（複数項目の連結、業種コードの読み替え、条件付きの上書き制御）が必要になった時点で、開発が前提になります。当社では[Salesforce導入支援サービス・Apex開発](https://www.issoh.co.jp/service/erp%5Fcrm/salesforce/)として、データ所有の割り当て設計から標準機能で対応できない部分の開発、既存の業務システムとの接続までを引き受けています。 委託する場合も、データ所有の割り当て表は自社で決めてください。ここは業務の意思決定であり、外部が代わりに決められる部分ではありません。委託先に渡すのは、確定した割り当て表と項目一覧です。 ## よくある質問 MA・SFA・CRMの連携についてよく寄せられる質問に回答します。 ### MA・SFA・CRMは3つとも導入する必要がありますか？ 体制次第です。営業5名以下・月間商談30件以下の規模であれば、CRM/SFAの2つで足ります。MAが効果を出すのは、リードが月100件以上積み上がり、営業が接触先を選別しなければ回らない段階からです。3つ揃えること自体を目標にすると、使われないツールの月額とデータの分断だけが残ります。まずSFAに商談が漏れなく入る状態を作るほうが、投資に対する戻りは大きくなります。 ### どのツールを顧客マスタにするのが良いですか？ 企業・顧客の属性情報はCRMをマスタにします。理由は、営業事務やサポート部門が名刺・登記情報・契約書をもとに手で整える項目であり、正規表記を保つ責任者が置きやすいためです。MAはフォームの入力値をそのまま保存するため、マスタには向きません。ただし基幹システムで取引先コードを管理している場合は、企業の属性は基幹をマスタとし、CRMはその写しを持つ構成のほうが請求業務との齟齬が出ません。 ### MAとSFAの連携は標準機能だけで足りますか？ 同期項目が20項目程度で、同じベンダーの製品同士なら標準コネクタで足ります。足りなくなるのは、複数項目を連結して同期する、業種コードを読み替える、商談ステージによって同期の可否を変えるといった変換が必要な場合です。判断の順序としては、まず必要な項目マッピングを一覧化し、標準機能の設定画面で表現できるかを確認します。表現できない行が数行でも残れば、その部分だけ開発またはiPaaSで補う構成が現実的です。 ### 3ツール連携の費用はどのくらいかかりますか？ ライセンス費と構築費は分けて見積もってください。ライセンスはユーザー数課金とレコード数課金の混在が多く、リードをCRMに入れる運用にするとレコード数が膨らんで年額が跳ねます。構築費で桁が変わるのは、標準コネクタの設定だけで済む場合と、項目マッピングの変換や条件分岐を開発する場合の差です。見積もりを取る前に、同期対象の項目一覧と件数、変換が必要な行を自社で洗い出しておくと、比較可能な金額が出てきます。 ### 連携後にデータが二重登録された場合はどう直しますか？ 先に原因側を止めます。同期を停止せずにマージすると、次の同期で再び分裂します。原因は多くの場合、名寄せキーの設定です。メールアドレス単独で突き合わせている設定を、法人ドメインや外部IDを含む複数キーの判定順序に変更します。HubSpotであればカスタムの一意値プロパティ、Zoho CRMであればupsertのduplicate\_check\_fieldsが該当します。その後、既存の重複レコードを古いほうから新しいほうへマージし、活動履歴が引き継がれているかを数件抽出して確認してください。 ## 関連記事 - [CRM連携とは？MA・SFA・基幹をつなぐAPI連携の設計と選定基準を解説](https://www.issoh.co.jp/column/details/15591/)：本記事で決めたデータ所有を、どの連携方式で実装するかを比較しています - [SFAとCRMの違いとは？目的・機能・使い分けを比較して解説](https://www.issoh.co.jp/column/details/12808/)：2ツールの役割分担から確認したい場合はこちらから - [MAツールとは？主要ツールの比較と選び方・導入で失敗しない判断基準を解説](https://www.issoh.co.jp/column/details/13409/)：MA接続の段階に入ってからのツール選定基準を扱っています - [CRMとは？顧客関係管理の機能・SFA/MAとの違いと導入メリットを実務目線で解説](https://www.issoh.co.jp/column/details/12805/)：顧客マスタをCRMに置く前提となる機能範囲の解説です - [MAツールのBtoBとBtoCの違いは？シナリオ設計・課金体系・選定基準を解説](https://www.issoh.co.jp/column/details/15816/)：MQL条件やシナリオ設計をBtoB前提で詰めるときの参考になります --- 出典: [MA・SFA・CRM連携とは？データ所有の決め方と導入順序の判断基準を解説]()（株式会社一創）