「MA・SFA・CRMの違いは分かった。問題は、どうつなぐのか」。ツール選定の入口を抜けた担当者から、次にいただくのがこの相談です。3つの違いを並べた解説記事は世にあふれていますが、実装の現場でつまずくのは違いそのものではなく、「データがどこから来て、どこへ行くのか」が一枚の図として描けていないことです。本稿では3つのツールを別物として並べるのではなく、ひと続きのデータパイプラインとして図解します。顧客が最初に名前を出した瞬間から、商談を経て受注し、利用が始まり、解約や深耕に至るまで。そのデータの流れに沿って、連携の実装パターン、想定される落とし穴、そして少人数の組織でも踏み出せる3つの実装ステップまでを整理します。違いの解説はCRM・SFA・MAの違いに譲り、ここでは「連携の実装」に軸足を置きます。
目次
MA・SFA・CRMは時間軸の異なるレイヤーに乗っており、一枚の図で重ねて見ると関係が掴めます。顧客ライフサイクルを横軸（認知→検討→商談→受注→継続/深耕）、データの所在を縦軸に置いたとき、3つのツールはそれぞれ別の帯を担当します。
MAは認知から検討までの帯を担当します。Webサイトの閲覧、資料ダウンロード、メールの開封・クリックといった、まだ商談になる前の行動データが主役です。SFAはGartnerの定義によれば「営業活動、プロセス、管理業務の自動化と捕捉」を担う仕組みで、検討の終盤から商談、受注に至る帯を扱います（参照：Gartner「Sales Force Automation (SFA)」）。CRMは認知から継続まで全帯を貫く土台のレイヤーに置かれ、顧客という一つの単位にすべての履歴を集約します。
図にすると、MAとSFAが横方向に並ぶ「業務レイヤー」で、CRMはその下に敷かれた「データレイヤー」だと捉えると分かりやすいでしょう。MAとSFAは、それぞれの業務を効率化する道具です。一方CRMは、両者が動くたびに生まれるデータを受け止め、顧客単位で再構成する器の役割を持ちます。実装の議論で迷子になる主因は、この縦横の関係を平面で並べてしまい、「3つとも対等なツール」と見てしまうことにあります。
定義そのものは前述の違いの記事に圧縮して譲りますが、本稿で押さえてほしいのはこの「業務2本＋データ1本」という三層の構造です。連携の話は、この三層の間でデータをどう受け渡すかという話に置き換わります。
連携を成果につなげる鍵は、データが一方通行ではなく双方向に流れる設計にあります。MA→SFA→CRMの順方向だけを描いた図は世に多いのですが、それだけでは半分しか機能しません。受注後のCRMからMAへ戻る逆方向の流れこそが、リード品質の学習と既存深耕を支えます。
順方向のフローはこうです。
匿名のWeb閲覧者がフォームを送信した瞬間に、MA側でリードレコードが立ちます。資料ダウンロードやセミナー参加で行動が積み上がり、スコアが一定の閾値を超えたところで、SFAに商談として引き渡されます。営業はその商談を進め、受注に至れば、取引情報と顧客情報がCRMに記録されます。ここまでは多くの記事が描いている流れです。
問題は、ここで終わらせてしまうと連携の半分しか動かないことです。逆方向のフローを描き加えると、次のようになります。
受注した顧客のセグメント情報、契約プラン、利用状況、解約の兆しが、CRMからMAへ戻ります。MAはその情報をもとに、オンボーディングのメールを自動配信し、利用が増えてきたタイミングでアップセルの案内を送り、利用が減ってきた顧客にはリテンションの施策を打ちます。さらに、受注した顧客の属性や接点履歴がMAに戻ることで、「どんなリードが受注に至りやすいか」をスコアリングモデルに反映できるようになります。
HubSpotのブログでも、CRMとMAを統合した運用が手動の引き継ぎを排除し、データの分断を解消するうえで重要だと整理されています（参照：HubSpot「Why CRM and Marketing Automation Need Each Other」。ベンダー出典である点は割り引いて読む必要があります）。ベンダー目線を差し引いても、「順方向だけでは学習が起きない」「逆方向の設計があって初めて既存深耕が動く」という骨子は、現場の実感とも一致します。
連携設計の最初に確認したいのは、この逆方向のラインが図に描かれているかです。多くの現場で、順方向の矢印は引かれているが、逆方向は手書きのExcel出力で代用されたままになっています。これが既存顧客向けのコミュニケーションが手薄になる典型的な構造です。
実装の選択肢は大きく二つに分かれます。別ベンダーの3製品をAPIで連携するパターンAと、1ベンダーの統合プラットフォーム上で完結させるパターンBです。どちらが正しいということはなく、自社の規模と既存資産しだいで判断します。
両者の違いを、同期するフィールド・同期頻度・データオーナーシップの観点で並べると次のようになります。
| 項目 | パターンA：別ベンダー3製品をAPI連携 | パターンB：統合プラットフォーム |
|---|---|---|
| 構成例 | MA・SFA・CRMを別ベンダーで選定し、API/iPaaSでつなぐ | 1つの基盤上にMA/SFA/CRMの機能が同居 |
| 同期するフィールド | 双方向同期する項目を事前に定義（連絡先、企業、商談、活動履歴、スコア等） | 同一データベースのため定義不要（同じレコードを参照） |
| 同期頻度 | リアルタイム/バッチ（数分〜1時間単位）を項目ごとに設計 | 即時反映（同じレコード） |
| データオーナーシップ | 「どのツールが正本か」を項目ごとに決める必要あり | 単一の正本（プラットフォーム自体） |
| 製品選択の自由度 | 各領域でベストを選べる | プラットフォームの制約を受ける |
| 連携の保守 | API仕様変更・項目追加のたびに保守が発生 | ベンダーが内部で吸収 |
| 初期コスト | 個別ライセンス＋連携実装の工数 | プラットフォーム単体のライセンス |
| 向く規模 | 既存資産が多い・専門人員がいる中堅以上 | 少人数・新規導入・素早い立ち上げ重視 |
パターンAでつまずきやすいのは、同期するフィールドの定義よりも、データオーナーシップの曖昧さです。「メールアドレスはMAとSFAのどちらが正本か」「企業名の表記揺れはどこで吸収するか」が決まっていないと、双方向同期がすぐに矛盾を生みます。MA側で営業活動の結果が上書きされたり、SFA側でマーケが整えたセグメントが消えたりといった事故は、技術ではなく取り決めの問題として起こります。
パターンBは、同じレコードを参照するので同期そのものが不要になります。代わりに、プラットフォームの設計思想に業務を寄せる必要が出てきます。たとえばリードと顧客（Contact／Company）の扱い、商談（Deal）のステージ定義、メール配信権限の設計など、ベンダーの設計に乗ることで決め直しが要らない反面、すでに別ツールで運用している取り決めとの段差は調整しなければなりません。
少人数で運用する中堅BtoB企業の現場で観察するのは、パターンAを最初に選んで連携保守に疲弊し、数年後にパターンBへ寄せ直す動きです。一方、最初からパターンBで素早く立ち上げて、データが溜まってから個別最適のツールを足す動きも見られます。どちらの場合も共通するのは、「同期フィールドとデータオーナーシップを文書化しないまま動かさない」という原則です。
連携不備が小さな手間にとどまらず、成長の天井を作るという話を、定量データで確認しておきます。
MuleSoftの「2024 Connectivity Benchmark Report」では、回答企業の81%がデータサイロ（部署やツールごとにデータが分断され孤立している状態）に直面していること、組織で使われているアプリケーションは平均991個に達すること、そして約9割（90%）の組織がデジタル変革を後押しするためのアプリケーション/データ統合の課題を抱えていることが報告されています（参照：Salesforce/MuleSoft「2024 Connectivity Benchmark Report」(2024)）。991アプリは大企業を含む世界平均なので、日本の中堅BtoB企業にそのまま当てはまる数字ではありませんが、「ツールが繋がっていないことに大半の組織が悩んでいる」という大きな傾向は、ほぼ普遍的に観察されるものです。
なぜ繋がっていないことが成長の天井になるのか。Forresterの調査では、マーケティング・営業・カスタマーサクセスといった顧客接点機能の整合度が高い企業は、そうでない企業に比べて収益成長で2.4倍、利益成長で2倍の差がついていると報告されています（参照：Forrester「Customer-Obsessed Growth Engine Alignment」(2023)）。これは個別機能の優秀さではなく、機能間がデータでつながり同じ顧客像を見ていることの効果です。MA・SFA・CRMの連携は、この「整合した顧客接点機能」の物理的な土台に当たります。
ここからは現場の視点を加えます。日本の中堅BtoB企業、とくに少人数のマーケ・営業体制では、「ツール3つ・人2人」という構造で詰まるケースが目立ちます。MAの担当が1人、SFA/CRMの管理が営業マネージャー兼任、専任の連携保守はいない。各人の担当範囲では合理的に動いているのに、3者の間に挟まれた連携作業だけが誰の業務でもなくなり、Excelの手作業で埋められ続けます。これは人手不足の問題に見えますが、根は「データオーナーシップが文書化されていないこと」にあり、人を増やしても文書がなければ同じ穴に落ちます。組織側の整合をどう設計するかはマーケと営業の連携をデータで設計するで、技術側に蓄積する負債の話はツールをつなぐほど重くなる連携負債で扱っています。
ここからは、明日から手をつけられる順番で実装ステップを示します。完璧な連携を一度に作ろうとせず、小さく1本のフローを通すところから始めるのが現実的です。
Step 1：共通IDの設計
最初に決めるのは、3つのツールをまたいで「同じ人物・同じ企業」を識別するためのキー、つまり共通IDです。多くのBtoB現場では、人物のキーをメールアドレス、企業のキーを会社ドメイン（メールアドレスの@以降）に置くのが実装しやすい選択肢です。フリーメールでの登録を許容するかどうか、グループ会社・子会社の取り扱い、メールアドレス変更時の同一人物判定など、運用上の例外を最初に決めておきます。共通IDが決まらないまま連携を組み始めると、双方向同期のたびに重複レコードが量産されます。
Step 2：データオーナーシップ表
次に、「誰が、どのフィールドを、いつ更新するか」を一枚の表にします。最低限、次の列があれば十分です。
| フィールド | 正本となるツール | 更新する人/仕組み | 更新タイミング | 他ツールへの反映方向 |
|---|---|---|---|---|
| メールアドレス | MA（フォーム入力） | 本人 | フォーム送信時 | MA→SFA→CRM |
| 商談ステージ | SFA | 営業担当 | 商談進捗時 | SFA→CRM→MA |
| 契約プラン | CRM | カスタマーサクセス | 契約・変更時 | CRM→MA |
| マーケスコア | MA | MA自動計算 | 行動発生時 | MA→SFA |
| 解約サイン | CRM | 利用状況の自動判定 | 日次バッチ | CRM→MA |
この表は10〜20行で十分に機能します。重要なのは網羅性よりも、「誰が正本を持つか」が項目ごとに決まっていることです。営業がMAのスコアを書き換えるとか、マーケがSFAの商談ステージを動かすといった事故は、この表があれば回避できます。
Step 3：小さく1本のフローを通す
共通IDとデータオーナーシップが決まったら、いきなり全フィールドを連携せず、1本のフローだけ先に通します。最も投資対効果が高いのは、たとえば次のような1本です。
``` 〔最初の1本〕 フォーム送信 → MAスコア加点 → 閾値超え → SFAに商談として作成 ↓ 営業に通知 ```
このフローが通ると、リード獲得から商談化までの「ボトルネック」が一本の自動連携に置き換わります。営業がMA画面を見に行く必要がなくなり、マーケは商談化に至ったリードの傾向を後から振り返れます。ここで動作確認と運用の癖を掴んでから、逆方向のフロー（受注情報のMAへの戻し）、既存顧客向けのオンボーディング配信と、1本ずつ足していきます。最初から全方向の連携を組もうとすると、設計が机上で複雑化し、立ち上がる前に止まります。
MA・SFA・CRMは別物のツールではなく、ひと続きのデータパイプラインです。本稿の整理を、最後にもう一度まとめます。
ツール選定の前に、まずいま動いているデータの流れを一枚の図にしてみる。それだけで、どこに最初の連携を引くべきかは見えてきます。自社の現状を起点に共通IDとデータオーナーシップから設計したい場合は、CRM・SFAの導入と再設計の支援の入り口として、棚卸しと連携の優先順位づけをご一緒できます。どこから手をつけるか迷うときは、無料相談からお気軽にご相談ください。