ツール連携の設計｜MA→SFA→CRM→DWH→BIの連携ポイントとAPI設計

連携ツールを導入したのに、MAで獲得したリードがSFAに正しく渡らない。SFAで見ている数字と、BIのダッシュボードに出る数字が食い違う。そもそもどのツールの数字が正しいのか、担当者ごとに言うことが違う。ツールをつないだはずなのに、こうした「情報のずれ」が消えないのは、接続はしたが設計が甘いからです。

この記事では、MA→SFA→CRM→DWH→BIという営業・マーケのデータの流れに沿って、各接点で何を決めるべきか（連携ポイント）と、API設計で押さえる要点を、具体的な判断材料つきで整理します。連携自動化の用語やツール比較を含む体系的な全体像はツール連携の自動化の全体像で扱っているので、本記事は「流れに沿った接点ごとの設計」に絞ります。

ツール連携の設計とは｜データの流れを一本の線でつなぐこと

ツール連携の設計とは、個々のツールを2つずつつなぐことではなく、MA→SFA→CRM→DWH→BIという営業・マーケのデータの流れ全体を、どこで・何を・どちらへ・どの鮮度で渡すかを一本の線として決めることです。接続の本数だけを増やしていくと、同じ顧客情報を複数のツールが別々に持ち、どれが正しいのか追えなくなります。

連携設計の良し悪しは営業の生産性に直接効きます。マツリカでは営業生産性を「（商談数×受注率×単価）÷工数」というフレームで整理していますが（出所：株式会社マツリカ 製品ファミリー資料）、リードの転記漏れは商談数を、二重入力や数字の突き合わせ作業は工数を、それぞれ悪化させる要因になります。まずデータの流れ全体を俯瞰し、どこが設計対象かを押さえます。

MA→SFA→CRM→DWH→BIというデータの流れ

このパイプラインに登場するツールは、それぞれ営業・マーケの中で役割が異なります。初出の用語なので、一つずつ意味を添えて整理します。

• MA（マーケティングオートメーション：見込み客の獲得・育成を自動化するツール）：Webフォームやメール配信でリードを集め、育てる。
• SFA（営業支援システム：営業プロセスを前に進めるための仕組み）：案件・商談を管理し、受注まで運ぶ。
• CRM（顧客関係管理システム：顧客との良好な関係を長期に築くための仕組みであり、業務の考え方でもある）：顧客情報と接点履歴を蓄積し、関係を維持・拡大する。
• DWH（データウェアハウス：分析用にデータを集約する基盤）：各ツールのデータを1か所に集める。
• BI（ビジネスインテリジェンス：データを可視化・分析する仕組み）：集約したデータをダッシュボードやレポートで見せる。

データはおおむね左から右へ流れます。MAで獲得したリードがSFAへ渡って案件になり、その顧客情報や履歴がCRMに蓄積され、SFA・CRMのデータがDWHに集約されて、最終的にBIで可視化される。この矢印の一本一本が設計対象です。どこで何を渡すかを決めていないと、右へ行くほど数字がずれていきます。

連携設計が甘いと起きること

流れのどこで問題が起きるかを具体的に押さえておきます。まずMA→SFAでは、リードが二重登録されたり、逆に条件設定のミスで転記漏れが起きたりします。SFA↔CRMでは、同じ企業の情報を両方が更新して、どちらが最新か分からなくなります。SFA・CRM→DWH→BIでは、フェーズの定義や金額の単位がツール間で揃っていないと、BIに出る売上や受注率がSFAの数字と食い違います。

共通するのは、二重入力・データの不整合・情報のサイロ化（部門やツールごとに情報が孤立する状態）という症状です。これらは「どこかのツールが悪い」のではなく、接点で何を渡すかを決めていないことが原因です。だからこそ、次に述べる「データの正」を先に決める必要があります。

データの正を1つに決める｜連携設計の起点

連携設計で最初に決めるべきは、どのデータについて・どのツールを情報の正（マスター：その項目の正しい値を持つ大元）とするかです。ここが曖昧なまま双方向連携を組むと、両方のツールが同じ項目を更新して衝突し、どちらが正しいか追えなくなります。

判断の出発点は、顧客・企業情報の正はCRM、案件・商談の正はSFA、集計・分析の正はDWH/BIという典型的な切り分けです。この切り分けを項目ごとに決め切ることが、後の接点設計をすべて楽にします。

項目ごとにマスターを決める

正は「ツール単位」ではなく「項目単位」で決めます。同じ顧客に関する情報でも、項目によって正が置かれる場所は変わります。

• 顧客・企業情報（会社名・住所・業種など）：CRMを正にすることが多い。
• 担当者・接点情報（人物・メールアドレス・対応履歴）：CRMを正にする。MAが持つ行動履歴はMA側を参照元にする。
• 案件・フェーズ・受注確度：SFAを正にする。営業プロセスを動かす大元だから。
• 売上・集計数値：SFA/CRMの生データをDWHに集約し、分析用の値はDWH/BIを正にする。

この表を先に埋めておくと、各接点で「どちらからどちらへ流すか」が自動的に決まります。逆にここを決めずに接続を始めると、後述の双方向同期で必ず衝突します。

双方向同期の衝突をどう防ぐか

双方向同期は「どちらのツールで更新しても両方に反映される」ため便利に見えますが、同じ項目を両側でほぼ同時に更新すると、どちらの値を残すかで衝突が起きます。基本の回避策は、項目ごとに片方を正と決め、正から従へ流す一方向連携にすることです。たとえば顧客情報はCRMを正にし、SFAへは一方向で反映する。

SFA側で顧客情報を直接書き換えられないようにしておけば、そもそも衝突が起きません。どうしても双方向にする場合は、更新タイミングを分ける（項目Aは朝、項目Bは夜）、あるいは更新時刻の新しい方を優先するといったルールを決めます。ルールを決めずに双方向をつなぐのが、最も壊れやすい設計です。

MA→SFAの連携ポイント｜リードを取りこぼさず渡す

MA→SFAの接点で決めるのは、どの条件で・どの粒度のリードを・いつSFAへ渡すかです。せっかくMAで獲得・育成したリードでも、渡す条件が曖昧だと営業が追いきれない量が流れ込み、名寄せミスや転記漏れで正しく載らないと追客が遅れて商談数が落ちます。

ここで押さえる設計項目は、引き渡す条件とタイミング、そして名寄せ・重複の扱いです。どちらも「取りこぼさない」と「二重に登録しない」を両立させる設計が要点です。

引き渡す条件とタイミングの設計

すべてのリードをSFAへ流すと、営業が確度の低いリードに埋もれます。MAのスコア（行動や属性を点数化した指標）や特定の行動（資料請求・料金ページ閲覧など）を条件にして、SFAへ渡す基準を決めます。渡すタイミングは、確度の高い行動が起きたら即時（リアルタイム）で渡すのが原則です。

問い合わせや見積依頼のような、営業の初動が遅れると失注につながる行動は、待たせずSFAへ通知します。一方で、育成途中のリードをまとめて渡す運用なら、日次のバッチ（一定間隔でまとめて処理する方式）でも間に合います。行動の緊急度で即時とバッチを分けるのが設計の勘所です。

名寄せ・重複の設計

同じ人物・企業が別々のリードとして登録されると、SFAに二重に案件が立ちます。名寄せ（重複データを1つに突き合わせる処理）のキーを何にするかを決めます。個人ならメールアドレス、企業なら会社名＋ドメインといった具合に、一意になりやすい項目をキーにします。

重複が見つかったときの統合ルール（新しい情報で上書きするか、既存を残すか）も先に決めておきます。ここを設計しておかないと、取りこぼしを恐れて全件流した結果、SFAが重複だらけになるという事態になります。取りこぼしと二重登録は、名寄せキーと統合ルールの2点でまとめて防ぎます。

SFA↔CRMの連携ポイント｜案件と顧客関係を分けて扱う

SFAとCRMは、同じ顧客データを扱っていても目的が異なります。SFAは目の前の案件を前に進めるための仕組み、CRMは顧客との良好な関係を長期に築くための仕組みです。この2つの視点を分けて連携することが接点設計の要点です。

SFAとCRMを1つのツールで扱う形は近年の流行ではなく、実務では歴史的に主流の統合型です（統合型は SFA/CRM と表記されることがあります）。統合型を使うか、別ツールを連携するかで、決めるべきことが変わります。

統合型を使うべきケースと別ツールを連携するケース

統合型は、案件も顧客情報も同じデータ基盤に乗るため、そもそも接点をまたぐ連携が少なく、データの正が一元化されます。個別の案件を効率的に進める視点と、どの顧客を優先して関係を築くかという全体最適の視点の両立が、統合されている意義です。一方、SFAとCRMを別ツールで運用して連携する場合は、顧客マスターの正をどちらに置くかを最初に決めます。前述のとおり顧客・企業情報はCRMを正にすることが多いので、CRM→SFAへ一方向で顧客情報を流し、SFAは案件情報の正を担う、という分担が自然です。

顧客関係データ（履歴・接点）の扱い

案件（SFA）と、顧客との対応履歴・接点（CRM）を、どちらへどう反映するかを決めます。商談メモや提案の進捗はSFAの案件に紐づけ、問い合わせ対応やサポート履歴といった案件をまたぐ関係情報はCRMに集約する、という切り分けが基本です。属人化を解消するには、この履歴をデータとして一元化するだけでなく、誰がやっても一定の質で記録・活用できるようプロセスを標準化する両輪が必要です。データを集める設計だけに寄ると、入力の仕方が人によってばらつき、集めても使えない履歴になります。

SFA・CRM→DWH→BIの連携ポイント｜分析に使える形で集約する

分析側への連携で決めるのは、どの粒度・どの鮮度で集約するかと、集約前にデータを整形するかどうかです。営業の生データをそのままBIへ流すと、フェーズの定義や金額の単位がツール間で揃わず、可視化した数字が信頼されなくなります。

ここでの設計項目は、集約のタイミング（多くはバッチ）と、DWHでのデータ整形・指標定義の統一です。BIに出る数字が現場のSFAの数字と一致してはじめて、ダッシュボードは意思決定に使われます。

リアルタイムかバッチか

分析側への集約は、多くの場合バッチで十分です。日次の売上集計や、大量のレコードをまとめて取り込む処理は、一定間隔でまとめて流すバッチが向きます。リアルタイム連携は処理負荷が高く、分析用途では過剰になりがちです。

一方で、当日の商談件数や進行中の案件数のように、鮮度が意思決定に直結する一部の指標だけはリアルタイムに近い頻度で更新する、という切り分けをします。すべてをリアルタイムにするのではなく、指標の性質で頻度を分けるのが現実的です。

データ整形と指標定義の統一

DWHに集約する前後で、データを分析に使える形に整えます。フェーズ名（例：SFAでは「提案」、別ツールでは「見積」）、金額の単位、通貨表記（円か¥か）といった表記を統一し、集計に使う指標の定義を1つに揃えます。「受注率」の分母を何にするか、「単価」を税抜きで見るか税込みで見るか、といった定義がツールごとに違うと、同じ名前の指標なのに違う数字が並びます。

ここが崩れると、BIの数字は「どれを信じればいいか分からない」ものになります。指標定義の統一は、DWHへ集約する設計の中で最も後回しにされやすく、最も効く工程です。

API設計で押さえる要点｜つないだ後に壊れない連携にする

ツール間をAPI（システム同士がデータをやりとりする窓口）でつなぐ設計は、「連携要件の定義→連携方式の選択→エラーハンドリング→テストと本番展開」の順で決めます。とくに認証方式とデータの整合性、そして順序（追い抜き）制御を最初に固めておくほど、後で壊れにくくなります。

ここまで設計してきた営業データの流れを、実際に動かす技術的な土台がAPI設計です。前段のデータの正・接点別の連携方針が決まっていれば、API設計は「その方針をどう実装に落とすか」に絞れます。

連携方式と認証の選択

連携方式は、大きく2つの使い分けがあります。REST API（決めた形式でデータを都度取得・送信する方式）は、必要なときにこちらから相手のデータを取りに行く用途に向きます。Webhook（相手側で変化が起きたときにこちらへ通知が届く仕組み）は、リードが登録された・案件フェーズが変わったといった「変化した瞬間」を受け取りたい用途に向きます。

MA→SFAの即時引き渡しはWebhook、DWHへの日次集約はREST APIでまとめて取得、という組み合わせが典型です。認証方式（APIキーやトークンなど、接続元を確認する仕組み）は、後から変えると全連携に影響するため、最初に決めます。

エラーハンドリングとデータ整合性の設計

連携は必ず失敗する前提で設計します。通信エラーや相手側のメンテナンスで処理が失敗したとき、一定回数まで自動で再試行（リトライ）し、それでも駄目なら人へ通知する流れを決めておきます。あわせて、同じデータが二重に処理されないよう一意キーで重複を弾く仕組みと、処理の順序が入れ替わっても矛盾が起きないよう更新時刻や版数で整合を取る仕組みを設計します。

たとえば「フェーズ更新」の通知が「案件作成」より先に届くと、存在しない案件を更新しようとして失敗します。こうした追い抜きを想定した順序制御を入れておくと、連携が止まりにくくなります。

連携を止めないための運用設計

連携は「組んで終わり」ではありません。接続先ツールの仕様変更や一時的なエラーで、いつか必ず止まります。だからこそ、止まる前提で監視・改善する運用まで含めて設計します。

最初から全業務を一気につなぐと、どこかで止まったときに原因の切り分けができません。価値が出やすい1接点から始め、正しく流れることを確かめてから広げるスモールスタートが、結局いちばん早く安定します。

スモールスタートで1接点ずつ検証する

まずはMA→SFAのように、効果が分かりやすく検証もしやすい1接点から始めます。リードが条件どおりにSFAへ渡り、名寄せが意図どおり動くかをデータで確認してから、次の接点へ進みます。この1接点ごとの積み上げなら、問題が起きても切り分けが容易です。連携ルールやワークフローを具体的にどう実装するかは、ツール連携の実装手順で詳しく扱っています。設計の方針が固まったら、実装の段で1接点ずつ形にしていきます。

監視とアラートで異常に気づく

止まったことに人が気づけない連携は、気づいたときには数日分のデータが欠けています。連携の停止・遅延・処理件数の異常（普段より極端に少ない、または多い）を検知して、担当者へ通知する監視を設計に含めます。とくに、エラーは出ていないのに件数だけ落ちている「静かな失敗」は見逃しやすいため、件数の閾値でアラートを出すと有効です。監視・アラートの具体的な設計は、エラー監視と止めない運用の設計で掘り下げています。

連携設計を支えるツールの一例

ここまでの設計、つまりデータの正を決める・接点ごとに連携方針を組む・APIでつなぐ・止めないよう監視する、を実現する手段として、ノーコードのデータ連携基盤やSFA/CRMがあります。ツールの選び方は、連携できるSaaSの数、双方向・一方向を柔軟に設定できるか、エラー時の再試行・通知の仕組みが備わっているか、で見るのが基本です。よく比較される選択肢のひとつとして、専用の連携基盤があります。

たとえば Mazrica DataHub のようなデータ連係基盤は、700以上のSaaS・AIとノーコードで連携でき、AI・API・RPA（画面操作の自動化）・OCR（文字のデータ化）を組み合わせて、データの連携・整形・自動化を担います。メールで受け取った請求書をOCRで読み取り、AIが勘定科目を判別し、必要なときだけ人が確認したうえでシステムへ登録する、といった処理を自動化できます（OCRの読み取りやAIの判別は、AIが処理・生成するため結果を人が確認する前提で使います）。

営業データを起点にする場合、その正を担うのはSFA/CRMです。たとえば Mazrica Sales のようなSFA/CRMを流れの中心に置き、そこから前段のMA・後段のDWH/BIへつなぐ、という組み立て方ができます。どのツールを使うにせよ、先に設計（データの正と接点方針）が決まっていることが前提で、ツールはその設計を動かす手段です。

まとめ

ツール連携の設計で最初に効くのは、ツールを増やすことではなく、データの流れを一本の線として捉え、どの項目の正をどのツールに置くかを決めることです。取り組む順番は、課題によって変えます。MAで獲得したリードの取りこぼしが課題なら、まずMA→SFAの1接点を、引き渡し条件と名寄せから設計する。

数字が食い違ってどれが正か分からないなら、項目別マスターの決定を先にやる。そのうえで分析側のDWH/BIへの集約と指標定義の統一に進むと、BIの数字が信頼できるものになります。

いきなり全体を設計しようとすると手が止まります。最初の一歩は小さくします。いま二重入力している項目を1つだけ書き出し、その正をどのツールに置くかを決めてみてください。それが決まれば、その項目の連携は一方向に整理でき、衝突がひとつ消えます。連携自動化の用語やツール比較まで含めた体系的な全体像はツール連携の自動化の全体像にまとめています。営業生産性の観点で連携設計の価値を確かめたい場合は、営業効率化の方法もあわせて参照してください。

よくある質問

Q ツール連携の設計は情シスがいないと組めませんか？

A

すべてに専任の情シスが必要というわけではありません。ノーコードの連携基盤を使えば、営業・マーケの担当者が画面上で連携元・連携先とデータの流れを設定できる範囲は広がっています。ただし、データの正をどの項目でどのツールに置くかという設計判断は、ツールの操作とは別に業務側で決める必要があります。認証や独自の変換ロジックが絡む複雑な連携では、情シスや外部の支援を入れる方が安全です。

Q 連携の設計書には何を書いておくべきですか？

A

最低限、次を書き残します。連携する接点の一覧（どのツールからどのツールへ）、項目ごとのマスター（正）の置き場所、連携方向（一方向か双方向か）、連携のタイミング（即時かバッチか、バッチなら頻度）、名寄せのキーと重複時の統合ルール、エラー時の再試行と通知の手順です。とくにマスターの置き場所と連携方向は、後から変えると全体に影響するため、必ず明文化します。

Q 既存のExcel（表計算）はツール連携に組み込めますか？

A

組み込めます。表計算ソフトはファイルの取り込みやAPI経由の連携に対応しているものが多く、連携基盤側から読み書きできます。ただし、Excelを情報の正のまま連携の中心に据えると、同時編集での上書きや版の管理が難しく、データの整合性を保ちにくくなります。連携に組み込む場合は、Excelを一時的な入出力の窓口と位置づけ、正はSFA/CRMやDWHなどのツール側に置くのが安全です。

Q 連携ツールとSFA/CRMは別々に契約が必要ですか？

A

ケースによります。SFA/CRMが標準で外部連携やAPIを備えていれば、追加のツールなしで一部の連携は組めます。一方、700以上のSaaSと横断的につなぎたい、複雑な整形や自動化を挟みたいといった場合は、専用の連携基盤を組み合わせるのが一般的です。まず手持ちのSFA/CRMがどこまで連携できるかを確認し、足りない部分を連携基盤で補う、という順で検討します。

Q 連携を後から作り直すことになるのはどんな時ですか？

A

多いのは、データの正を決めずに双方向で組んでしまい、衝突が頻発してどちらが正しいか追えなくなったときです。ほかにも、指標の定義を統一しないままBIまで連携し、数字が信頼されずやり直すケース、最初から全接点を一気につないで止まったときに原因を切り分けられないケースがあります。いずれも、項目別マスターの決定とスモールスタートを先にやっておけば避けられます。