Salesforceのシステム連携とは？API方式の選定とコール上限の設計を実装目線で解説

Salesforceと基幹システムをつなぐとき、最初に決めるのはツールではなくデータの向きと件数です。1日あたり万単位のレコードを動かすならBulk API 2.0、数分以内の反映が要るならPub/Sub APIとプラットフォームイベント、というように方式は要件から機械的に絞り込めます。この記事では、Summer ’26（APIバージョン67.0）時点の公式ドキュメントに記載されたコール上限・イベント配信枠・廃止スケジュールを基準に、API系統の使い分け、自前実装とETL・iPaaS・MuleSoftの選び方、統合ユーザーの権限設計までを扱います。特定SaaSごとの手順ではなく、方式選定と容量設計に絞った内容です。

まとめ：連携方式の選定順序とAPIコール上限から逆算する設計の要点

方式選定は三つの問いを順に埋めると手戻りが出ません。データはどちら向きに流れ、マスタはどちらが持つのか。反映までに何分許されるのか。1日あたり何件動くのか。この三つが決まれば、同期のREST API、非同期のBulk API 2.0、イベント駆動のPub/Sub APIのどれを使うかはほぼ自動的に決まります。

実装主体は件数ではなく本数で選びます。連携先が1〜2システムなら自前実装、夜間バッチで数十万件ならETLツール、SaaS間を10本以上つなぐならiPaaS、社内APIが二桁で統制まで要るならMuleSoft。単発の連携にMuleSoftを充てる判断は取りません。

容量の検算は着手前に済ませます。Enterprise Editionの24時間枠は「100,000＋ライセンス数×1,000」で、200ライセンスなら300,000コール。10万件を1件ずつRESTで更新すると枠を使い切りますが、sObject Collectionsで200件ずつ束ねれば500コールに収まります。イベント側はEnterpriseで24時間あたり25,000件の配信枠が先に詰まる制約です。運用面では統合専用ユーザーの権限を対象オブジェクトだけに絞り、APIバージョンの棚卸しを年次の定例に入れます。製品そのものの機能と料金はSalesforceとは？CRMの機能・料金・認定資格から導入判断までで扱っています。

Salesforce連携で使う主要API五系統と適用領域の切り分け

SalesforceのAPIは公式ドキュメント上で十数種類に分かれますが、連携設計で実際に選ぶのは五系統です。選定を誤ると、機能ではなくコール上限で先に詰まります。

REST APIとsObject Collectionsでコール数を抑える基本設計

REST APIは1リクエストが1コールとして数えられます。10万件のレコードを1件ずつ更新すれば、それだけで10万コールを消費する計算になります。

これを避ける仕組みがsObject Collectionsとcompositeです。sObject Collectionsは1リクエストで最大200件を扱え、リクエスト全体がAPI上限に対して1コールとして数えられます。10万件なら500コール。compositeも同様に、一連のサブリクエストをまとめてカウントは1コールになります。親子レコードを続けて作る処理では、この差が枠の消費を二桁変えます。設計時は1業務トランザクションあたりのコール数を先に見積もり、日次の実行回数を掛けて総消費を出してください。

Bulk API 2.0が前提になるレコード件数とファイルサイズの境界

件数が万単位を超えたら非同期のBulk API 2.0へ切り替えます。判断材料になる上限値は公式ドキュメントに明記されています。

実務で先に当たるのはジョブあたり150MBの方です。1レコードが1KBなら15万件で分割が要り、CSVの列を絞るだけで通ることもあります。取り込みは200件ごとに別トランザクションとして処理されるため、途中で失敗しても全件が巻き戻るわけではありません。部分成功を前提に、失敗レコードだけを再投入する導線を用意してください。

Pub/Sub APIとプラットフォームイベントで扱う準リアルタイム連携

数分以内の反映が要件になると、ポーリングでは枠が持ちません。5分間隔なら1日288回、対象オブジェクトが10本で2,880コール。

代替がプラットフォームイベントとPub/Sub APIです。Salesforce側の変更をイベントとして発行し、外部システムが購読します。イベントメッセージの最大サイズは1MB。発行枠は1時間あたりEnterprise EditionとUnlimited Editionで250,000件、Developer Editionで50,000件。配信枠は24時間あたりEnterpriseが25,000件、Unlimited・Performanceが50,000件、Developerが10,000件です。なお標準ボリュームプラットフォームイベントはSummer ’27での廃止が告知されており、これから設計するなら高ボリューム側を前提に置きます。

Metadata APIとTooling APIが担う設定同期とリリース自動化の範囲

データではなく設定を運ぶのがMetadata APIとTooling APIです。カスタムオブジェクトの定義、項目、権限セット、Apexクラスといった構成情報を組織間で移送します。用途はデータ連携と別で、Sandboxから本番への反映をCIに組み込む文脈で使います。Apexでカスタムのエンドポイントを外部に開く判断をするなら、ガバナ制限の考え方を押さえてから設計してください。Apex固有の制約はApexとは？Salesforce専用のオブジェクト指向言語をガバナ制限と実装目線で解説にまとめています。

API直結・ETL・iPaaS・MuleSoftで変わる開発工数と保守の負担配分

API系統が決まっても、それを誰がどこで動かすかは別の判断です。ここを外すと、動くけれど誰も直せない連携が残ります。

自前実装によるAPI直結が成立するデータ量と更新頻度と要員の条件

自前実装が向くのは、連携先が1〜2システムに限られ、変換ロジックが業務固有で、Salesforce開発の要員が継続的に確保できる場合です。三つのうち一つでも欠けると保守が止まります。

自前実装で抱え込む仕事はコードだけではありません。認証情報の更新、APIバージョンの追随、失敗時の再実行、コール消費の監視。ツールなら標準機能で付いてくる部分を全部作ることになります。連携が1本なら安く付きますが、5本を超えたあたりから逆転します。

ETLとEAIツールで吸収できる差分抽出とエラー再実行の設計範囲

夜間バッチで数十万件を動かす連携は、ETLやEAIツールの土俵です。差分抽出、型変換、エラーレコードの隔離と再実行が製品機能として揃い、Bulk API 2.0のジョブ分割も内部で処理されます。

設計者が決めるのはキーの持ち方です。SalesforceのレコードIDを外部システムに保持させるか、外部システムのキーをSalesforceの外部ID項目に持たせるか。後者なら登録と更新を1本の処理に統合でき、初回同期と差分同期を同じジョブで回せます。

iPaaSがSaaS間連携で優位に立つコネクタ数と保守コストの目安

Slack、Outlook、Gmail、kintone、HubSpot、Sansan。SaaS同士をつなぐ要件が並んだときは、iPaaSが最も安く済みます。各SaaSの認証とAPI仕様をコネクタ側が吸収するため、連携1本あたりの実装が画面設定で終わるからです。

注意すべきは課金体系で、多くの製品が実行回数やタスク数で課金します。1日数万回動く連携をiPaaSに載せると、自前実装の保守費を上回ることがあります。件数が少なく種類が多い連携に向き、件数が多く種類が少ない連携には向きません。個別SaaSとの連携イメージはShopifyとSalesforceのAPI連携でできることが参考になります。

MuleSoftの採用が成立する社内API本数とガバナンス要件の水準

MuleSoftはSalesforce傘下の統合基盤で、APIの設計・公開・監視・アクセス制御を一元管理します。採用が正当化されるのは、社内で再利用するAPIが二桁に達し、部門横断で重複開発が起きていて、誰がどのAPIを呼んだかを監査要件として追跡する必要がある場合です。連携が数本の段階では投資が回収できません。

四つを併用する構成も珍しくありません。基幹との大量同期はETL、SaaS間はiPaaS、業務固有の変換だけ自前実装。この切り分けにすると、障害時にどこが壊れたかの判別も早くなります。

APIコール上限とイベント配信枠から逆算する連携容量の設計手順

方式が決まったら、枠に収まるかを数字で確認します。上限に当たってから設計を戻すのが、この領域でいちばん高くつく手戻りです。

エディション別のAPIコール割り当てと一日の実効残量の算出方法

24時間あたりのコール枠は、基本の100,000件にライセンス数と種別ごとの単価を掛けた値を足して求めます。

Enterprise Editionで200ライセンスなら、100,000＋200×1,000で300,000コール。ここから既存連携の消費と、モバイルアプリや外部フォームからの流入を差し引いた残りが、新しい連携に回せる実効枠です。

同時実行25件とタイムアウト10分から決まるバッチ処理の分割単位

総量とは別に、瞬間的な並列度にも上限があります。20秒を超える長時間リクエストは、本番組織とSandboxで同時25件、Developer EditionとTrialで5件まで。REST・SOAPのタイムアウトは10分で、リクエストのURIとヘッダを合わせたサイズは16,384バイトが上限です。

1. 1リクエストの処理時間を実測し、10分の半分以下に収まる件数へ分割する
2. 並列度を25未満に抑え、他の連携と重ならない実行窓を決める
3. 20秒を超える処理はバッチ側に寄せ、同期APIには短時間で返る処理だけを残す

検索条件をURIに載せる設計だと、対象IDが増えたときに16,384バイトの制限へ当たります。IDのリストを渡す処理はボディ側へ移しておくと、後から件数が増えても壊れません。

プラットフォームイベントの配信枠を超えない発行設計と再送の扱い

イベント駆動の連携で先に詰まるのは配信側です。Enterprise Editionの発行枠が1時間あたり250,000件あるのに対し、配信枠は24時間あたり25,000件。桁が二つ違います。

対処は二つ。レコード更新のすべてをイベント化せず、外部システムが本当に必要とする状態変化だけを発行対象に絞ること。もう一つは、1イベントに複数レコードの識別子をまとめ、購読側が詳細をAPIで取りに行く形にすることです。イベントメッセージは最大1MBまで載るため、識別子の配列ならかなりの件数が入ります。配信枠はアドオンライセンスで1日あたり100,000件を追加できますが、枠を買う前に発行対象の絞り込みで収まらないかを確認する方が費用対効果は高くなります。

統合ユーザーの権限設計とAPIバージョン更新で決まる連携の保守性

連携が止まる原因は、コードの不具合より権限と版の管理に寄っています。作った直後は動くのに半年後に止まる。その多くはここで防げます。

統合ユーザーのプロファイルと項目レベルセキュリティの最小化基準

連携を人のユーザーアカウントで動かしてはいけません。異動や退職でアカウントが無効化された瞬間、連携ごと止まるためです。専用の統合ユーザーを立て、次の範囲まで権限を絞ります。

• 対象オブジェクトの参照・作成・更新のみとし、削除権限は原則与えない
• 項目レベルセキュリティで、書き込む項目だけを編集可能にする
• ログインIPの制限を連携元サーバーのアドレスに限定する
• 権限セットで付与し、プロファイル本体は最小構成のまま維持する

削除権限を外しておけば、連携の不具合が起きても最悪で不要レコードが増えるだけで済みます。復旧の手間が桁で違うため、削除が業務要件に本当に必要かは設計段階で詰めてください。

OAuth 2.0の認証方式選定とSOAP login()廃止への移行判断

サーバー間の連携では、利用者の操作を挟まないJWTベアラーフローが扱いやすくなります。証明書で署名したトークンを渡してアクセストークンを得る方式で、パスワードを連携基盤側に持たせずに済みます。

ここで注意したいのが、SOAP APIのlogin()コールの廃止です。バージョン31.0から64.0のlogin()はSummer ’27での廃止が告知されており、廃止後は該当のエンドポイントが停止します。ユーザー名とパスワードでセッションIDを取る古い実装が残っているなら、外部クライアントアプリを使う認証への移行を計画に載せてください。

版数21.0〜30.0の廃止に学ぶバージョン固定の危険と更新の周期

SalesforceのAPIは各バージョンを初回リリースから最低3年サポートし、廃止の1年前までに通知する方針が公開されています。実際にバージョン7.0から20.0はSummer ’22以降、21.0から30.0はSummer ’25以降に廃止されました。廃止済みバージョンへのリクエストは410 GONEを返します。

2026年8月時点の最新はSummer ’26のバージョン67.0で、31.0以降は現役です。とはいえ構築時の版をエンドポイントに埋め込んだまま10年動かせば、いずれ同じ経路をたどります。年に一度、連携が指しているバージョンを棚卸しし、二世代以上古ければ上げる。この定例を運用設計に含めるかどうかで、数年後の停止リスクが変わります。ERP・CRM全体の製品選定はERP/CRM導入とは？Salesforce・SAP・Dynamicsの選定軸と進め方で整理しています。

Salesforce連携で見送るべき方式と二重登録を招く実装パターン

ここからは判断を言い切ります。要件の並びによっては、やらない方が良い連携があります。

双方向同期を選ばない条件と一方向配信で足りる業務の具体的な見分け方

マスタの所在が片側に決まっている業務で、双方向同期は選びません。受注や請求のように基幹システムが正を持つデータは、基幹からSalesforceへの一方向にして、Salesforce側は参照専用に固定します。

双方向にした瞬間、両側で同じレコードが同時に更新されたときの競合解決を設計する必要が出ます。タイムスタンプで後勝ちにするのか、項目ごとに優先側を決めるのか。どちらを選んでも時刻のずれや遅延で意図しない上書きが起きる余地が残り、障害調査は両側のログを突き合わせる作業になります。双方向が要るのは、両側で独立に更新される顧客の連絡先のような限られたデータだけです。

標準コネクタを捨てて自前実装に倒す判断が正当化される三つの境界

ETLやiPaaSの標準コネクタで動く要件を、わざわざ自前実装へ置き換えるべき場面は限られます。次の三つのどれかに当たったときだけです。

• コネクタが対応していないオブジェクトや項目型を扱う必要がある
• 1レコードあたりの変換分岐が10本を超え、設定画面では表現しきれない
• 実行回数課金の見積もりが、自前実装の年間保守費を上回る

これ以外の動機、たとえば細かく制御したいという理由で自前実装に倒すと、作った担当者が離れた時点で誰も触れない資産になります。迷う段階なら標準コネクタで作って動かし、実運用の数字を見てから作り替える方が安全です。連携を含めた実装体制づくりのご相談はSalesforce導入支援サービス・Apex開発で承っています。

リトライ設計の欠落が二重登録を招く典型と外部IDによる回避手順

連携障害の相談で最も多いのがレコードの二重登録です。原因はほぼ一つに絞られます。Salesforce側の処理は成功したのに応答が返る前に通信がタイムアウトし、呼び出し側が失敗と判断して再送する。この経路です。

回避策は登録処理をべき等にすることに尽きます。外部システムのキーをSalesforceの外部ID項目に持たせ、新規作成ではなくupsertで書き込めば、同じキーの再送は更新として吸収されます。新規作成を選ぶ場合でも、呼び出し側で一意のキーを持たせ、成否が不明なときは再送前に照会する導線を必ず用意してください。Bulk API 2.0を使う連携では、ジョブと結果が7日で削除される点も再実行設計に効きます。週明けに前週の失敗を調べようとして結果が消えている事故を避けるため、ジョブ完了時に結果を自社側へ退避する処理を最初から組み込みます。

よくある質問

Salesforceのシステム連携について、設計の初期段階で確認されることの多い質問をまとめました。

SalesforceのAPI連携はどのエディションでも使えますか？

エディションによって24時間あたりのコール枠が変わります。Developer Editionは固定で15,000コール、EnterpriseとProfessionalはSalesforceライセンス1件あたり1,000コール、UnlimitedとPerformanceは1件あたり5,000コールで、いずれも基本枠の100,000コールが加算されます。フルSandboxは5,000,000コールです。契約中のエディションとライセンス数から枠を計算し、想定する連携の消費が収まるかを先に確認してください。

APIコール上限を超えるとどうなりますか？

枠を使い切ると、それ以降のAPIリクエストがエラーで失敗します。24時間のローリング集計のため時間の経過とともに枠は戻りますが、その間は連携が止まったままです。対処は追加枠の購入より先に、リクエストを束ねる設計の見直しから入ります。sObject Collectionsで1リクエスト200件まで束ねる、compositeで一連の処理を1コールにまとめる、件数が万単位ならBulk API 2.0へ寄せる。この三つで多くの超過は解消します。

SOAP APIは今から使っても問題ないですか？

バージョン31.0以降のSOAP APIは現役で、既存の実装をすぐ書き換える必要はありません。ただし認証に使うlogin()コールは、バージョン31.0から64.0を対象にSummer ’27での廃止が告知されています。ユーザー名とパスワードでセッションIDを取得している実装は、外部クライアントアプリを使うOAuth 2.0の認証へ移す計画を立ててください。新規で作るならREST APIを選ぶ方が、ドキュメントとツールの選択肢は広くなります。

SlackやGmailとの連携にも開発は必要ですか？

通知の送信や予定の同期といった定型的な連携であれば、iPaaSの標準コネクタに設定を入れるだけで組めます。開発が必要になるのは、Salesforce側の商談データを外部の集計ロジックにかけて返すような、業務固有の変換が挟まる場合です。目安はコネクタの設定画面で表現できる分岐かどうか。分岐が10本を超えるなら、その部分だけを自前実装へ切り出す構成が保守しやすくなります。

Salesforceとのリアルタイム連携はどこまで可能ですか？

プラットフォームイベントとPub/Sub APIを使えば、レコードの変更を秒単位で外部システムへ届けられます。制約になるのは配信枠で、Enterprise Editionは24時間あたり25,000件、Unlimited・Performanceは50,000件です。全レコードの全更新をイベント化すると枠に収まらないため、外部システムが必要とする状態変化だけに発行対象を絞ります。イベントメッセージは1件あたり1MBまで載せられるので、識別子をまとめて渡す設計にすると件数を抑えられます。

関連記事

• Salesforceとは？CRMの機能・料金・認定資格から導入判断まで解説：連携の前提になる製品全体の機能と料金体系を確認できます。
• Apexとは？Salesforce専用のオブジェクト指向言語をガバナ制限と実装目線で解説：カスタムのエンドポイントを開く際に効くガバナ制限を扱っています。
• ShopifyとSalesforceのAPI連携でできること：ECサイトとの具体的な連携パターンの実例です。
• Salesforce×Twilioで実現する顧客体験の変革：通信サービスと組み合わせた連携の設計例です。
• ERP/CRM導入とは？Salesforce・SAP・Dynamicsの選定軸と進め方を解説：連携以前の製品選定の軸を整理しています。