SalesforceとERPや外部SaaSをAPI連携する方法と設計パターン

データが分断されたまま運用を続けるコスト——なぜ今、API連携が求められるのか

SalesforceをCRMとして活用しているBtoB企業の多くが、ある共通の課題に直面しています。商談情報や顧客データはSalesforce上に蓄積されている一方で、受注処理や在庫管理、請求業務はERPや会計SaaSで動いている——というデータの分断状態です。

この構造が現場にもたらす影響は小さくありません。営業担当者がSalesforceに入力した受注情報を、別の担当者がERPに手動で再入力する。請求書の発行タイミングで会計SaaSと突き合わせ作業が発生する。こうした二重入力・手動転記の工数は、日常業務に深く組み込まれているため見えにくくなっていますが、積み重なると月間で相当な時間を消費します。

問題は工数だけではありません。手作業を介するプロセスには、必然的に入力ミスや転記漏れのリスクが伴います。また、Salesforce上の商談ステータスとERPの受注データにタイムラグが生じることで、経営層や営業マネージャーがリアルタイムの受注状況を把握できないという情報の鮮度問題も発生します。意思決定の根拠となるデータが「どのシステムが正」なのかあいまいになることも、現場の混乱を招く要因のひとつです。

こうした状況は、いわゆるデータサイロ——システムをまたいで情報が分断され、連携されないまま孤立している状態——と呼ばれます。SaaSの普及によって業務システムの選択肢が広がった反面、ツールが増えるほどサイロが生まれやすくなっているのが現状です。

この課題を根本から解消する手段として、SalesforceとERPや外部SaaSをAPI連携するアプローチが注目されています。適切に設計されたAPI連携を実装することで、データの自動同期・リアルタイム連携が実現し、二重入力の解消と情報の一元管理が可能になります。

本記事では、以下の内容を順に整理します。

• Salesforceの外部連携で使われる主な方式（REST API・Apex・ミドルウェア）の違い
• ERP・会計SaaS・MAツールといった連携先ごとの設計パターン
• Apexを使った連携開発の実態と注意すべき制約
• 発注前に確認すべきポイントと、内製・ローコード・フルスクラッチの選び方

Salesforceと外部システムの連携を検討している情報システム担当者や事業開発担当者が、方針決定・発注判断に活用できる情報を提供することを目的としています。

Salesforceの外部連携で使われる3つの方式——REST API・Apex・ミドルウェアの違い

Salesforceを外部システムと連携する方法は、大きく3つのパターンに整理できます。それぞれ仕組みが異なるため、自社の技術体制・運用方針・予算に合った方式を選ぶことが、後工程のトラブルを防ぐうえで重要です。

REST APIで直接つなぐ——シンプルだが設計の甘さがトラブルの元になりやすい

Salesforce REST APIとは、HTTP通信を使ってSalesforceのデータを外部から読み書きできる仕組みです。ERPや会計SaaSなど、相手側のシステムがAPI呼び出しに対応していれば、2つのシステムを直接つなぐことができます。

構造がシンプルで初期実装コストを抑えやすい反面、エラーハンドリングやAPI制限（Salesforceには1日あたりのAPI呼び出し上限があります）への対処を開発者が個別に設計する必要があります。設計が甘いと、大量データ送信時のタイムアウトや重複登録といった問題が本番環境で発生しやすくなります。

Apexで制御する——Salesforce内にロジックを持たせる選択肢

ApexとはSalesforceが独自に提供するサーバーサイドのプログラミング言語です。Javaに近い文法を持ち、Salesforceプラットフォーム上で動作します。外部APIを呼び出す処理をApex内に記述することで、「受注が確定したら自動で在庫システムへ通知する」といったイベント駆動の連携を実装できます。

Salesforceの内部処理と連携ロジックを一体で管理できるため、ビジネスルールが複雑な場合に向いています。ただしApexの開発・保守にはSalesforce認定の開発者が必要になるケースが多く、社内にリソースがない場合はベンダー依存になりやすい点に注意が必要です。

iPaaS・ミドルウェアを挟む——ノーコード寄りで保守しやすい反面、費用と制約がある

iPaaS（Integration Platform as a Service）とは、複数のSaaSやシステムを仲介するクラウド型の連携基盤です。MuleSoft・Zapier・Make（旧Integromat）・Boomiなどが代表例として挙げられます。GUI上でデータの流れを設定できるため、開発工数を抑えられる場面があります。

一方で、月額ライセンス費用が継続的に発生すること、処理件数や接続先の数によって料金が変動すること、細かいビジネスロジックの実装に制約が生じることもあります。

3つの方式の特徴を以下に整理します。

• REST API直接連携：初期費用を抑えやすいが、エラー処理や流量制御の設計負荷が高い。シンプルな1対1連携に向いています。
• Apex開発：Salesforce内で完結するため整合性を保ちやすい。複雑なビジネスルールを持つ企業に向いていますが、専門知識を持つ開発者が必要です。
• iPaaS・ミドルウェア：ノーコード・ローコードで設定できるため運用担当者が関与しやすい。多対多の連携や将来的な拡張が見込まれる場合に選ばれやすいですが、ランニングコストと機能制約の確認が欠かせません。

どの方式が適切かは、連携するシステムの数・データ量・更新頻度・社内の開発体制によって変わります。方式の選定を誤ると、後から作り直しが発生するケースも少なくないため、設計段階での判断が重要です。

連携パターン別の設計アプローチ——ERP・会計SaaS・MAツールそれぞれの典型構成

外部システムとの連携設計は、接続先ごとにデータの流れ・同期タイミング・エラーへの対処方法が大きく異なります。「とりあえずAPI でつなぐ」という発想で進めると、運用開始後に重複登録やデータ不整合が頻発するケースが少なくありません。ここでは代表的な3つの連携パターンについて、設計上の要点と起こりがちな失敗を整理します。

SalesforceとERP連携——受注データの双方向同期で二重入力をなくす設計

ERPとの連携では、SalesforceとERP双方がデータを更新するため、双方向同期の設計が必要になります。典型的なフローは「Salesforceで商談が受注になる → ERPに受注伝票を自動生成 → ERPで出荷・納品が確定する → Salesforceの案件ステータスに反映される」という流れです。

この設計で最も起こりがちなのが重複登録です。Salesforceのトリガー処理とERPのバッチ処理が競合し、同一の受注データが2件作成されてしまうケースがあります。対策としては、ERP側に「Salesforce連携フラグ」を持たせ、連携済みレコードには上書き処理を走らせない制御を入れることが有効です。また、同期タイミングはリアルタイム連携ではなく、5〜15分間隔の準リアルタイムバッチとすることで、API呼び出し回数を抑えながら安定した運用が可能になります。

SalesforceとERPや会計SaaS連携——請求・入金データのプッシュ設計

請求書の発行や入金確認といった会計データは、Salesforceから会計SaaSへの片方向プッシュで設計するのが一般的です。受注情報をもとにSalesforceが請求データを生成し、会計SaaS側に送信するフローになります。

この構成で注意すべきはAPI制限超過です。月次の請求処理が集中するタイミングでAPI呼び出しが急増し、会計SaaSの1日あたりのAPI上限に達してしまうケースがあります。送信処理をキュー（待ち行列）に積んで順次実行する仕組みを設けること、またエラー発生時に自動リトライと管理者通知が走る設計にしておくことが実務上の最低条件です。データの不整合を防ぐためには、会計SaaS側からの処理完了レスポンスを受け取るまでSalesforce上のステータスを「送信済・未確定」として保持する設計が有効です。

SalesforceとMAツール連携——リードデータの同期とスコアリング活用

MA（マーケティングオートメーション）ツールとの連携では、リードの属性データとスコアリング結果をSalesforceに取り込み、営業担当者がタイムリーにアプローチできる状態をつくることが目的です。MAツールでスコアが閾値を超えたリードをSalesforceのリードオブジェクトに自動連携し、担当者への通知やタスク生成につなげる構成が典型的です。

設計ミスとして多いのがデータ不整合、特にメールアドレスの表記ゆれによる重複リード生成です。MAツールとSalesforceで同一人物が別レコードとして存在し、スコアが正確に引き継がれないまま営業に渡るケースがあります。連携時には名寄せロジックを明示的に定義し、重複判定のキーとなるフィールド（メールアドレス・会社名など）の正規化ルールを連携設計の段階で決めておくことが重要です。

Apexを使った連携開発の実態——できること・できないこと・注意すべき制約

Apexとは何か——SalesforceのサーバーサイドプログラミングをBtoB担当者向けに整理する

Apex（エイペックス）は、Salesforceが独自に提供するサーバーサイドのプログラミング言語です。Javaに近い文法を持ち、Salesforceのプラットフォーム上で直接動作します。外部ツールのサーバーを用意する必要がなく、Salesforce環境の内側で処理を完結できる点が特徴です。

Salesforce開発言語としてのApexは、主に次のような用途で使われます。

• レコード保存時に自動で処理を走らせる（トリガー処理）
• 外部システムのAPIを呼び出してデータを取得・送信する（Callout）
• バッチ処理や非同期処理によって大量データを定期的に同期する

意思決定者の視点で整理すると、Apexは「Salesforce内部のロジックを柔軟にコントロールするための開発手段」と理解するのが適切です。ミドルウェアのような中間基盤を使わずに外部連携を実現できる反面、Salesforceプラットフォーム特有の制約に縛られる点を先に把握しておく必要があります。

Apexで外部APIを呼び出す仕組みと、押さえておくべきガバナ制限

ApexからSalesforce REST API開発の文脈でよく用いられるのが、外部REST APIへのHTTPリクエスト（Callout）です。たとえば、Salesforceの商談が成立したタイミングでERPに受注データを自動送信する、といった連携がApexで実装できます。

ただし、Apexには「ガバナ制限」と呼ばれるプラットフォーム固有の制約が存在します。これはSalesforceが共有リソースを保護するために設けた上限値であり、開発の自由度を左右する重要な制約です。発注・内製を判断する前に、以下の点を把握しておくことをお勧めします。

• 1トランザクションあたりのCallout上限：1回の処理で呼び出せる外部APIは最大100回までです。大量レコードを一括処理する設計では、この上限に抵触しやすくなります。
• 同期処理でのタイムアウト制限：外部APIへのリクエストは、応答待ち時間に制限があります。応答の遅い外部サービスとの連携では、非同期処理（FutureメソッドやQueueable Apex）への切り替えが必要になるケースが少なくありません。
• 非同期処理のキュー管理：Queueableなどの非同期処理は同時実行数に上限があります。連携頻度が高いシステムでは、処理が詰まってデータ反映が遅延するリスクがあります。

これらの制約は、設計段階で考慮しておかないと後工程での手戻りに直結します。特に「1日何件のデータを、どの頻度で連携するか」という処理量の見積もりが甘いと、ガバナ制限に起因するエラーが本番稼働後に発生するケースがあります。Apexを使った連携開発では、機能要件だけでなく処理量・頻度・エラー時の挙動まで含めた設計の議論が不可欠です。

連携開発を発注する前に確認すべきポイント——認識のズレが後工程の手戻りを生む

外部システムとのAPI連携開発を外部ベンダーに依頼する場合、発注側が事前に用意すべき情報が揃っていないと、開発途中で仕様の確認待ちが発生し、手戻りコストが膨らみます。以下では、発注前に確認・整理しておくべきポイントを3つの領域に分けて整理します。

外部システム側の確認事項——API仕様書・認証方式・レート制限を先に押さえる

連携先となる外部システム（ERPや会計SaaSなど）のAPI仕様が公開されているかどうかを、発注前に必ず確認してください。API仕様書が存在しない、または取得にベンダー申請が必要なケースでは、開発着手後に仕様確認待ちで工程が止まることがあります。

• API仕様書の公開有無：ドキュメントURLの有無、取得条件（契約プランによる制限など）を確認する
• 認証方式：OAuth 2.0方式かAPIキー方式かによって、Salesforce側の接続アプリ設定が変わります。どちらの方式を採用しているかを事前に把握しておく必要があります
• レート制限（Rate Limit）：1日あたり・1秒あたりのAPIコール上限を確認します。同期頻度や対象レコード件数が上限を超えると、データの欠損や連携遅延が発生します

Salesforce側の確認事項——接続アプリ設定・セキュリティポリシー・責任共有モデルの理解

Salesforceへの外部システムからの接続には、「接続アプリ（Connected App）」の設定が必要です。OAuth認証の許可スコープ、IPアドレス制限、セッションポリシーなどをSalesforce管理者が事前に整理しておく必要があります。

あわせて理解しておきたいのが、Salesforceの責任共有モデルです。Salesforceはプラットフォームのセキュリティ（インフラ・基盤レイヤー）を担いますが、接続アプリの設定・アクセス権限の管理・API経由で送受信するデータの取り扱いは、利用企業側の責任範囲となります。外部システムとのAPI連携を設計する際は、「どの操作・データがどちらの責任か」を明確にした上で、セキュリティポリシーを策定することが求められます。

業務設計側の確認事項——データマッピングとエラー時の運用フローを先に決める

技術仕様と同等に重要なのが、業務設計側の準備です。発注側が以下の2点を整理せずに開発を依頼すると、仕様確定が開発と並走する状態になり、工程全体が不安定になります。

• データマッピング（項目対応表）：Salesforceの項目と外部システムの項目を1対1で対応させた一覧表を用意します。項目名・データ型・必須／任意・変換ルールを明記することで、開発側の手戻りを大幅に減らせます
• エラー時の業務フロー設計：API連携は通信エラーやタイムアウトが発生することがあります。その際に「誰が・何を確認し・どう対処するか」を業務フローとして先に定義しておく必要があります。エラー検知の通知先・リトライ判断・手動補正の手順まで設計しておくことが、安定運用の前提になります

これらのドキュメントを発注時に揃えておくことで、開発側との認識のズレが減り、見積精度と開発スピードの両方が向上します。

内製・ローコード・フルスクラッチ開発——自社に合った進め方の選び方

連携開発の進め方は、大きく3つの段階に整理できます。要件の複雑度・社内の保守体制・コスト感の3軸で自社に合った選択肢を選ぶことが、後工程の手戻りを減らす上で重要です。

標準機能・Flowで解決できる範囲——まず確認すべき前提

まず確認すべきは、Salesforceの標準機能やFlow（ノーコードの自動化ツール）で要件を満たせるかどうかです。たとえば、商談のステータスが変わったタイミングで関連レコードを自動更新する、定型のメール通知を送るといった処理であれば、Flowだけで実装できるケースが少なくありません。

「Salesforceへの入力が面倒」「二重入力が発生している」という運用課題も、まずFlowによるレコード自動生成や項目の自動転記で解消できないかを検討することが先決です。開発コストをかける前に、標準機能で対応できる範囲を整理しておくことが前提になります。

iPaaSを使うケースとフルスクラッチ開発が必要になるケースの分岐点

標準機能では対応できない外部システムとのデータ連携が必要になったとき、次の選択肢がiPaaS（Integration Platform as a Service）を使ったローコード連携です。MuleSoft・Zapier・Make（旧Integromat）などのツールを使えば、SalesforceとERPや会計SaaSをGUIベースで接続できます。定型的なデータの受け渡し、スケジュール同期、Webhookによるイベント連携といった用途に向いており、開発リソースが限られている組織でも運用しやすい点が特徴です。

一方、以下のような条件が重なる場合はApexによるフルスクラッチ開発が現実的な選択肢になります。

• ERPのデータ構造が複雑で、変換ロジックをコードで記述する必要がある
• リアルタイム性が求められ、バッチ同期では業務要件を満たせない
• 既存のiPaaSコネクタでは対応できない独自APIを持つシステムと連携する
• エラーハンドリングや再送制御を細かく制御しなければならない

フルスクラッチ開発はSalesforce API連携の方法として柔軟性が最も高い反面、開発・保守の両面で継続的な技術対応が必要になります。社内にSalesforce開発者がいない場合、外部パートナーとの伴走体制を前提に進めることが現実的です。CLANEはApex・LWC（Lightning Web Components）を活用したカスタム連携開発を担っており、設計段階から保守フェーズまで継続的に関与する体制を取っています。

選定の基準をまとめると、要件がシンプルで社内運用できるならFlow、外部接続が必要でも定型処理が中心ならiPaaS、複雑な変換ロジックやリアルタイム連携が必要ならフルスクラッチ、という順序で検討を進めるのが妥当です。

まとめ——API連携の設計で押さえるべき論点を整理する

SalesforceとERPや外部SaaSをAPI連携する際に押さえるべき論点は、大きく3つの軸に整理できます。

連携方式の選択——REST API・Apex・ミドルウェアの使い分け

連携方式は、相手システムの仕様・データ量・更新頻度によって判断します。シンプルな単方向データ転送であればREST APIの直接呼び出しで対応できるケースが多く、Salesforce側にビジネスロジックを持たせたい場合はApexが選択肢になります。一方、複数システムをまたぐ連携やエラーハンドリングの設計が複雑になる場合は、MuleSoftやBoomiといったミドルウェアを挟むことで保守性を確保しやすくなります。方式の選択を誤ると、後工程での手戻りコストが大きくなるため、要件定義の段階で明確にしておくことが重要です。

設計パターン——連携相手ごとの典型構成を把握する

ERP連携では受注・在庫・請求データの双方向同期が主な要件になり、冪等性（同じ操作を繰り返しても結果が変わらない性質）の担保とエラー時のリカバリ設計が焦点になります。会計SaaSとの連携では、Salesforceの売上データを会計側に一方向で渡す構成が多く、仕訳ルールの定義を先に固めることが設計の起点になります。MAツールとの連携では、リードスコアや商談ステータスをリアルタイムで同期する構成が一般的で、データ重複の防止ロジックが設計の核になります。

発注前の確認——認識のズレを最小化する3つのポイント

連携開発を外部ベンダーに発注する前に、以下の3点を自社内で整理しておくことが、手戻りの防止につながります。

• データの流れと更新タイミング：どのシステムがマスターデータを持ち、どの方向に・どの頻度でデータを流すかを図示する
• エラー時の業務影響範囲：連携が止まった場合にどの業務が止まるかを洗い出し、優先度を定義する
• 内製・ローコード・フルスクラッチの判断基準：保守担当者のスキルセットと将来的な拡張予定を踏まえて進め方を決める

Salesforceの外部システム連携は、二重入力の解消や業務効率化に直結する取り組みです。しかし、設計の粒度が粗いまま開発に入ると、運用開始後に想定外の不整合や改修コストが発生するケースが少なくありません。連携方式の選択・設計パターンの把握・発注前の要件整理という3軸を起点に、自社の状況に合った進め方を検討してください。