◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- BtoB ECとSFA(営業支援システム)の連携は、方式の選定より先に「商談と受注をどの粒度で対応づけるか」を業務として決める必要があります。
- SFAの商談は確定前の案件、ECの受注は確定後の注文という違いがあり、この境界の置き方が連携設計の出発点になります。
- データ連携が進んでも売上に直結しにくいという公的調査の結果を踏まえ、効率化と売上向上を分けて設計する考え方を紹介します。
目次
取引先・商談・見積・受注・活動履歴——連携がつなぐ5つのデータ
BtoB ECとSFAの連携とは、取引先を共通キーに商談情報と受注情報を対応づけ、確定前の案件と確定後の注文を一つの取引の流れとして扱えるようにすることです。経済産業省の調査では、2024年のBtoB-EC市場規模が514.4兆円まで拡大しており*1、連携設計の巧拙が業務効率を左右する場面が増えています。
定義:取引先を共通キーに商談と受注を結ぶ仕組み
SFAは営業支援システム(Sales Force Automation)の略で、商談の進行状況や顧客対応履歴を一元管理する仕組みです。BtoB ECとSFAの連携とは、営業支援システム上の商談情報とECサイト上の受注情報を、取引先を共通のキーとして対応づける仕組みを指します。この対応づけによって、確定前の案件と確定後の注文を一つの取引の流れとして扱えるようになります。
この定義で重要なのは、連携する対象が「システムとシステム」ではなく「案件の状態」だという点です。商談と受注は別のライフサイクルを持つデータであり、まず何を対応づけるかを決めてから、方式の話に進む必要があります。
つなぐ対象は5種類——取引先・商談・見積・受注・活動履歴
連携の検討対象になるデータは、実務上おおむね5種類に整理できます。取引先、商談、見積、受注、そして商談に紐づく活動履歴です。すべてを双方向でつなぐ必要はなく、データの性質に応じて連携方向を変えるのが実務的な設計です。
このうち取引先は、SFAとECの双方に存在する共通データであるため、連携の前提として名寄せ・突合が必要になります。商談・見積はSFA側の管理対象、受注はEC側の管理対象という役割分担が出発点になります。
BtoB-EC市場は514.4兆円・EC化率43.1%へ拡大している*1
経済産業省「令和6年度電子商取引に関する市場調査」によると、2024年のBtoB-EC市場規模は514.4兆円(前年465.2兆円・前年比10.6%増)でした。BtoB-EC化率も43.1%(前年比3.1ポイント増)に達しています*1。市場が拡大する一方、企業間のデータ連携そのものはまだ限定的な段階にあります*2。
この市場拡大は、営業部門にとって「ECで完結する取引」が増えることを意味します。次章で見るとおり、商談と受注は同じものではなく、この違いを踏まえないまま連携方式を決めると、運用段階でつまずきやすくなります。
確定前の商談と確定後の受注——ステージ対応表で見る境界
SFAの商談は確定前、ECの受注は確定後という時間軸の違い
SFA上の商談は「これから受注に至るかもしれない案件」であり、受注確定前の状態を管理する対象です。一方、EC上の受注は「確定した注文」であり、状態としてはすでに商談を終えた後の記録にあたります。
この時間軸の違いを埋めずに連携すると、同一の取引が商談としても受注としても重複して登録され、二重入力や件数の齟齬が生じます。境界をどこに置くかを先に決めることが、連携設計の実務上の出発点です。
受注確定でSFAの商談をクローズしECの受注を正本に切り替える
SFAの商談ステージとECの受注ステータスは、そのままでは対応しません。実務で採用例の多い整理を次の表にまとめました。詳細な承認フロー設計は見積承認の記事に譲り、ここでは対応関係のみを示します。
| SFAの商談ステージ | ECの受注ステータス | 実務上の対応関係 |
|---|---|---|
| 見込み・提案中 | 未発生 | ECの受注はまだ存在しません。SFA側だけで案件を管理します。 |
| 見積提示・交渉中 | 未発生〜下書き | 見積情報をECの下書き注文へ引き継ぐ運用が多く見られます。 |
| 受注確定 | 注文確定 | この時点でSFAの商談をクローズし、ECの受注データを正本に切り替えます。 |
| (商談を経ない) | 注文確定(リピート発注) | 商談が存在しないため、SFA側に案件を作らない運用も選択肢になります。 |
ECで完結する注文には商談が存在しないケース
リピート発注や定期発注がECで完結する場合、そもそもSFA上に商談が立ちません。これは連携の不備ではなく、取引の性質上当然に起こる現象です。この前提を置いたうえで、どのデータをどちら向きに流すかを次章で決めていきます。
正本をどちらに置くか——5データの連携方向と更新タイミング
正本の置き場所——取引先は基幹、商談はSFA、受注はEC
連携設計の核心は、5種類のデータそれぞれについて「どちらを正本にするか」を決めることです。取引先は基幹システム(販売管理・会計等)を正本にするのが一般的で、商談はSFA、受注はECを正本にする分担が実務上機能しやすい形です。
取引先の正本を基幹に置く場合、SFAとECそれぞれの取引先が同一の相手を指しているかどうかを、事前に突合しておく必要があります。取引先の名寄せが済んでいないと、そもそも連携の前提が成立しません。この突合には、国税庁が公表する法人番号(13桁の番号で、利用範囲の制約がなく誰でも自由に利用できる)*3を共通キーの一つとして使う方法があります。
双方向にすべきもの・片方向で足りるもの
5種類のデータは、すべてを双方向で同期する必要はありません。取引先のように両システムに実体があるデータは双方向の突合が前提になりますが、商談・見積・受注は片方向の連携で足りる場合が多くあります。
| データ | 正本 | 連携方向 | 更新タイミング |
|---|---|---|---|
| 取引先 | 基幹システム | 双方向(突合が前提) | 都度 |
| 商談 | SFA | 片方向(SFA→EC) | イベント駆動(受注確定時) |
| 見積 | SFA | 片方向(SFA→EC) | イベント駆動 |
| 受注 | EC | 片方向(EC→SFA) | イベント駆動または日次反映 |
| 活動履歴 | SFA | 連携なし(ECに持たせない) | - |
連携の粒度とタイミング——都度・日次・イベント駆動
連携のタイミングは、都度(発生ごと)・日次バッチ・イベント駆動(状態変化時)の三択で検討します。受注確定という重要な境界を挟むデータは、イベント駆動で即時反映させる価値が高く、活動履歴のように参照頻度が低いデータは連携自体を見送る判断も有効です。
取引に関する電子データをやり取りする場合、そのデータの保存義務や保存方法についても法律で定められています*4。連携によって取引情報を電子的にやり取りする範囲が広がる場合は、保存要件への対応も併せて確認しておく必要があります。
API・CSV・中間DB・手動——連携方式は業務設計を決めてから選ぶ
API・CSV・中間DB・手動運用、それぞれの適用条件
連携方式には、API連携(システム同士がリアルタイムにデータをやり取りする方法)、CSVでのファイル連携、中間DBを介した連携、手動での再入力運用があります。方式の優劣は業務要件に依存するため、先に境界と正本を決めたうえで選ぶ順序が実務的です。
更新頻度が高く即時性が求められるデータはAPI連携が向き、更新頻度が低いデータや小規模な運用ではCSV連携や手動運用でも成立します。実装レイヤの認証設計・エラー処理・再送制御といった詳細は別に検討が必要な領域です。
特定企業間の直接的なデータ連携は実施35.6%にとどまる*2
IPA「DX動向2026」によると、企業外部の主体とのデータ連携は、いずれの形態でも「実施・検討していない」が過半数を占め、まだ限定的な段階にあります。形態別では「特定企業間での直接的なデータ連携」の実施率が35.6%で最も高くなっています。次いで「サプライチェーン内でのデータ連携プラットフォームの利用」が22.5%、「地域・異業種間でのデータ連携基盤の利用」は4.6%です*2。
なお中小企業庁の委託報告書(2022年3月公表)には、当時の政府目標が記されています。「2023年を目途に電子受発注システムの導入率約5割の達成を目指す」という記載です*5。目標年次は既に経過しており、現況の普及水準を示す数値としては使えませんが、普及が段階的に進められてきた経緯の参考になります。
実装の詳細は要件定義フェーズで詰める
方式そのものの比較や、EDI(電子データ交換。取引文書を通信回線でやり取りする仕組み)との使い分けは、本記事の範囲を超える実装レイヤの論点です。連携方式は要件定義の工程で技術的な制約と合わせて確定させるのが現実的です。
リピート発注がECへ移ると商談件数が減る——営業評価への副作用
リピート発注のEC移行で商談件数が減る
連携設計を進めると、これまでSFAに商談として登録されていたリピート発注が、商談を経ずにECで直接処理されるようになります。結果として、SFA上の商談件数そのものが減少します。
この現象を営業活動の停滞と誤読してはいけません。誤読すれば、評価制度と実態がずれてしまいます。ECに移った注文は「商談が減った」のではなく、「商談を必要としない取引が増えた」ことを意味します。
営業評価の指標を連携設計より先に見直す
連携方式を決める前に、営業評価の指標がリピート発注の減少にどう影響するかの確認が欠かせません。商談件数や受注件数だけを評価軸にすると、ECへの移行が進むほど営業の評価が不当に下がりかねません。
評価指標を、新規開拓・大口案件・仕様調整といったSFAに残る案件の質で測る方向に見直すことが、連携設計と並行して必要な作業になります。
ECに移す注文と営業が持つ案件の線引き
すべての注文をECに移すわけではありません。新規顧客・大口案件・仕様調整を要する取引は、引き続き営業がSFA上で商談として扱うべき対象です。ECに移すのは、条件が定型化されたリピート発注に限定するのが妥当な線引きです。
この線引きが曖昧なままだと、営業が握っておくべき大口案件までECで完結してしまい、商談としての管理が抜け落ちかねません。境界の運用ルールは、連携方式と同時に業務側で確定させておく必要があります。
効率化85.2%・売上向上17.9%——「つないだのに効かない」を避ける設計
データ連携の目的は効率化85.2%に偏り、新規事業創出は24.5%*2
IPA「DX動向2026」では、データ連携の目的として「業務の効率化や自動化」が85.2%で最も高くなっています。次いで「既存事業の改善やサービス高度化」が50.8%、「新規事業やサービスの創出」は24.5%です*2。いずれもデータ連携の形態の設問で、いずれかの項目を「実施している」「実施を検討している」と回答した企業を母集団とした数値です。連携の目的が内向きの効率化に偏っている実態は、原典の数値が示すとおりです。
この傾向は、BtoB ECとSFAの連携についても当てはまりやすいと考えられます。二重入力を減らす効率化の効果は明確ですが、それだけで売上増加まで期待すると、目的と手段がずれてしまいます。
DXの売上高増加は17.9%、成果指標の設定率は23.9%*2
同調査では、DXによる経営面の成果として「売上高増加」を挙げた企業は17.9%、「利益増加」は19.6%でした(成果が出ていると回答した企業が対象)*2。また、DXの成果指標を「設定している」企業は2025年度で23.9%にとどまっています(全社的または部門単位でDXに取り組む企業が対象)*2。
連携すれば効率化はできても、売上に直結するとは限らないというのが、公的調査から読み取れる現実です。この前提を先に認めたうえで、効率化の効果と売上への効果を分けて設計する考え方が必要になります。
効率化と売上を分けて設計するための確認順3点/順位根拠:着手順序の依存関係
- まず境界(受注確定の瞬間)と正本の置き場所を業務として確定させます。ここが曖昧だと後続の効果測定も意味を持ちません。
- 次に、効率化の効果(二重入力の削減・処理時間の短縮)を測る指標を、連携方式の確定と同時に決めます。
- 最後に、売上・利益につながる指標(新規案件の創出・大口案件の受注率など)を別枠で設定し、効率化指標と混在させません。
可視化した課題を自社の数字で確かめるには、無料相談で要件を整理するのが近道です。
人材不足45.7%が課題の最多——設計者がいない前提の段階導入
課題の最多は人材不足45.7%、次いでセキュリティ38.7%*2
IPA「DX動向2026」によると、データ連携推進の課題は「社内にデータ連携を企画・推進・実装できる人材が不足している」が45.7%で最も多くなっています。次いで「セキュリティ対策やプライバシー保護の負荷が高い」が38.7%、「データ連携による具体的な費用対効果が見込めない・不明確である」が38.4%です。「ビジネスモデルや収益化の仕組みが描けない」も31.8%を占めています*2。
この結果は、社内に連携を設計できる人材がいない状態が珍しくないことを示しています。連携方式の選定より前に、誰がこの設計を担うのかを決めておく必要があります。
取引先マスタの突合作業には、SFAとECそれぞれのデータ構造を理解した上で名寄せルールを設計する専門知識が必要です。規模によっては複数人・複数週にわたる工数を要するため、社内に担当者がいない場合は外部の専門知識を借りる選択肢も検討に値します。
段階導入:取引先の突合→受注の片方向連携→商談との双方向
人材が限られる前提では、一度にすべてを連携するのではなく、段階的に進めるのが現実的です。まず取引先の突合を済ませ、次に受注データを片方向で連携し、最後に商談との双方向連携を検討する順序が、依存関係として無理がありません。
前工程として取引先マスタを整える
取引先マスタが両システムで一致していない状態のまま連携を始めると、どの工程でも突合エラーが発生します。取引先の名寄せは、連携設計そのものより先に済ませておくべき前工程です。
取引先マスタを整えたあと、どこまでを本記事の範囲として扱うかも先に切り分けておきます。受注確定後の在庫引当や物流側の連携(WMSとの連携等)は本記事の範囲外です。商談時点の在庫確認についても、在庫連携の要否と設計は別の論点として扱います。
境界・正本・指標——3つを分けて決めるのが連携設計の要点
本稿では、BtoB ECとSFAの連携を「方式の選定」ではなく「業務設計」として整理しました。要点を3つに集約すると次のとおりです。第一に、連携対象は取引先・商談・見積・受注・活動履歴の5種類であり、境界は受注確定の瞬間に置くという原則があります。第二に、正本の置き場所と連携方向をデータごとに決めることが、方式選定より先に必要な作業です。第三に、データ連携の効果は効率化に偏りやすく、売上への効果を狙うなら指標を分けて設計する必要があります*2。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
よくある質問
SFAとBtoB ECは常に連携しなければなりませんか。
常に連携しなければならないわけではありません。取引の規模が小さく、商談件数が少ない場合は、手動での再入力運用でも成立します。連携の必要性は、二重入力の量や受注確定までのリードタイムに応じて判断します。
商談を経ずにECで入った注文は、SFAに登録すべきですか。
必須ではありません。リピート発注のように商談を経ない注文は、SFA側に案件として登録しない運用も選択肢になります。営業評価の指標が商談件数に依存している場合は、指標自体の見直しが欠かせません。
取引先マスタはSFAとECのどちらを正本にすべきですか。
実務上は基幹システム(販売管理・会計等)を正本にする形が機能しやすいとされます。SFAとECの取引先が同一の相手を指しているかを、法人番号などの共通キーで事前に突合しておくことが前提になります*3。
連携はAPIでなければなりませんか。
APIに限定されません。更新頻度が高く即時性が求められるデータはAPI連携が向きますが、更新頻度が低いデータはCSV連携や中間DBを介した連携でも足ります。方式は業務要件を確定させた後に選びます。
連携の効果はどう測ればよいですか。
効率化の効果(処理時間・二重入力の削減)と、売上・利益に結びつく効果は分けて測る必要があります。IPAの調査でもDXの成果指標を設定している企業は23.9%にとどまり*2、指標設計自体が不足しがちな領域です。
- *1 出典:経済産業省「令和6年度電子商取引に関する市場調査の結果を取りまとめました」(2025年8月26日公表)
- *2 出典:独立行政法人情報処理推進機構(IPA)「DX動向2026」図表3-31・3-32・3-33・2-6・2-14・3-14(2026年7月30日公表、調査期間2026年4月中旬〜6月中旬、日本標準産業分類19業種の経営層またはICT関連事業部門を対象に有効回答1,799社)
- *3 出典:国税庁「法人番号とは」(法人番号公表サイト)
- *4 出典:国税庁「電子帳簿等保存制度特設サイト」(電子帳簿等保存制度特設サイト)
- *5 出典:中小企業庁委託『受発注のデジタル化に関する推進方策 報告書』(EYストラテジー・アンド・コンサルティング株式会社、2022年3月31日公表)
画像の出典元
- BtoB企業間の商談でSFA連携のデータを確認するビジネスプロフェッショナル/Photo by Vitaly Gariev on Unsplash
- 取引先のイメージ/Photo by Ambre Estève on Unsplash
- 見積のイメージ/Photo by maks_d on Unsplash
- 受注のイメージ/Photo by Lucas on Unsplash
- 発注のイメージ/Photo by Vitaly Gariev on Unsplash