SalesforceはCRM/SFAとして営業・顧客データの中心になりますが、kintoneや会計システム、DWH・BIとの連携ニーズは尽きません。本記事では連携手段の4分類を整理したうえで、主要な連携ツールを中立に比較し、SOQLや外部IDupsert、API消費量、ガバナ制限まで踏まえた選定チェックポイントをまとめます。

01　Salesforce連携でよくある要件

SalesforceはCRM/SFAとして営業・顧客データの中心的な情報源になっている一方、実務では他システムとの連携ニーズが絶えず発生します。代表的な要件を挙げると、kintoneとの案件・請求データの突き合わせ、会計システムとの請求情報の連携、DWH・BIへの商談データ集約、広告媒体からのリード自動投入、そして双方向での同期（upsert）やSOQLによる柔軟な抽出などがあります。

Salesforce連携が一般的なデータ連携より難しく感じられるのは、標準オブジェクトだけでなくカスタムオブジェクト・カスタム項目まで含めて扱う必要がある点、大量データを取得・更新する際のAPI消費量とガバナ制限という独自の制約がある点、そして双方向で書き戻す際に外部IDでの突き合わせが必要になる点が理由です。汎用的な連携方法では、この特有の制約に対応しきれないことがあります。

例えば、営業部門がSalesforceで商談を進めながら、経理部門はkintoneで請求書を発行し、マーケティング部門は広告媒体からのリードを日々確認する、という体制はよく見られます。連携の要件を整理する際は、どの部門がどのタイミングで何のデータを必要としているかを棚卸しし、リアルタイム性が必要な連携と、日次バッチで十分な連携を切り分けておくと、後の手段選定がスムーズになります。

02　連携手段の選択肢｜4つの方法を比較

Salesforceとデータをやり取りする方法は、大きく4つに分類できます。それぞれ得意な場面が異なるため、まずはタイプで絞り込むと選びやすくなります。

定型的な一往復の連携ならAppExchangeアプリ、単発の移行や一括更新ならData Loader、複数システムとの継続的な連携なら汎用データ連携ツール、既存の手段で対応できない特殊要件だけAPI開発、という住み分けで考えると迷いにくくなります。

それぞれの向き不向きをもう少し補足すると、次のようになります。

• AppExchangeアプリは導入が速く運用負荷も低い一方、対応範囲があらかじめ決まっているため、自社独自のカスタムオブジェクトや特殊なマッピングには対応しきれないことがあります。
• Data Loader / 標準機能は追加コストなしで扱える手軽さが魅力ですが、スケジュール実行や差分検知の仕組みは自前で用意する必要があり、継続的な運用には向きません。
• 汎用データ連携ツールは複数システムをまたぐ継続的な連携に強みがありますが、製品によって対応オブジェクトやSOQLの柔軟性に差があるため、事前の検証が欠かせません。
• API開発（フルスクラッチ）は要件に完全に合わせた実装ができる反面、開発・保守にエンジニアの継続的な工数がかかり、属人化のリスクも抱えることになります。

03　主要なSalesforce対応連携ツール比較

ここでは汎用データ連携ツールの代表例として、6製品を分類と特徴で整理します。特定の製品の優劣を評価するものではなく、位置づけの違いを把握することが比較の出発点になります。

候補を絞り込む際に、それぞれのツールで確認しておきたいポイントを整理すると次のとおりです。

• Passwork：SOQLの直接実行や外部IDによるupsertなど、双方向の書き戻しにどこまで対応しているかを確認しておくとよいでしょう。
• trocco：DWHへの集約が中心のため、Salesforce側への書き戻しが将来的に必要になるかどうかを見極めておくとよいでしょう。
• ASTERIA Warp：国産ならではのサポート体制や、オンプレの既存システムとの接続実績があるかを確認します。
• DataSpider：大規模・基幹系の統合を想定している場合、既存の業務ルールをどこまでフロー上で表現できるかを確認します。
• CData：BIツールや自社アプリからの参照が主目的であれば、JDBC/ODBC接続のパフォーマンスを確認します。
• Fivetran：Salesforceへの書き戻しが必要な場合は、他の手段と組み合わせる前提で検討するとよいでしょう。

04　選定時のチェックポイント

連携手段とツールの候補を絞り込んだら、実際の運用で効いてくる観点を確認します。Salesforce特有の制約を踏まえたチェックが特に重要です。

• ①カスタムオブジェクト・カスタム項目への対応：標準オブジェクトだけでなく、自社が拡張したカスタムオブジェクト/項目までAPI越しに取得・更新できるかを確認します。
• ②外部IDによるupsert対応：双方向で書き戻す際、Salesforce側のレコードと連携元システムのキーを外部IDで正しく突き合わせられるかを確認します。
• ③API消費量への配慮：SalesforceのAPIコール数には日次の上限があり、大量データや高頻度の実行ではBulk APIの利用や差分取得など、消費量を意識した設計が必要です。
• ④ガバナ制限（Governor Limits）への配慮：SOQLクエリの取得行数やCPU時間などSalesforce側の実行制限を踏まえたクエリ設計になっているかを確認します。
• ⑤権限・シェアリングルールの扱い：連携用ユーザーの権限セットやシェアリングルールが、取得・更新したいデータ範囲と一致しているかを確認します。
• ⑥サンドボックス/本番環境の切り替えやすさ：開発・検証を安全に行うため、接続先環境を容易に切り替えられるかを確認します。

ガバナ制限（Governor Limits）の考え方

Salesforceはマルチテナント環境で安定した動作を保つため、SOQLの取得件数やCPU時間、DML操作数などに実行時の制限（ガバナ制限）を設けています。大量のレコードを扱うバッチ処理では、この制限に抵触しないようクエリや処理を分割する設計が求められ、連携ツール側がバルク処理やページネーションに対応しているかが重要な確認事項になります。

API消費量を抑える設計

SalesforceのAPIコール数には組織ごとに日次の上限があり、高頻度・大量データの連携ではこの消費量が無視できないコストになります。全件を毎回取得するのではなく、更新日時などをキーにした差分取得や、Bulk APIによるまとめての取得・更新を組み合わせることで、消費量を抑えながら安定した連携を続けられます。

外部ID設計のポイント

双方向でデータを同期する場合、Salesforce側のレコードと連携元システムのレコードをどのキーで突き合わせるかという外部ID設計が土台になります。連携元システムの一意なIDをSalesforceのカスタム項目（外部ID属性）として保持しておくことで、重複作成を避けつつ、更新か新規作成かをupsertで自動的に判定できるようになります。

カスタムオブジェクト・カスタム項目の扱い

自社の業務に合わせて追加したカスタムオブジェクトやカスタム項目は、標準オブジェクトとは異なるAPI名（末尾に__cが付く形式など）で管理されています。連携ツールがこれらのカスタムオブジェクト・項目を一覧から選択でき、項目レベルのマッピングを柔軟に組めるかどうかは、実運用での対応範囲を左右する重要なポイントです。

サンドボックス環境での検証フロー

連携の設定や項目マッピングを本番組織でいきなり検証すると、既存データを誤って上書きするリスクがあります。Salesforceのサンドボックス環境に接続を切り替え、テストデータで動作確認を行ったうえで本番へ切り替えられる連携ツールであれば、安全に検証サイクルを回せます。接続先の切り替えが設定項目として用意されているかどうかも、選定時に確認しておきたいポイントです。

05　PassworkでのSalesforce連携

Passworkは、分類上はVPN・VPC接続やオンプレを含むハブ型の統合、双方向連携に対応するEAI型に位置づけられますが、設定はドラッグ&ドロップのノーコードで完結する設計です。Salesforce連携では、標準/カスタムオブジェクトの取得、SOQLの直接実行、作成・更新・外部IDによるupsert・条件付き削除までの書き戻しを、コードを書かずに組み立てられます。

実運用の例として、商談データを日次でBigQueryへ集約しTableau等のBIで可視化する連携や、広告（Meta広告・Google広告等）経由で獲得したリードをSalesforceへ自動投入する連携が動いています。分析への集約と、業務システムへの書き戻しの両方をひとつの基盤でカバーできる点が、EAI型でありながらノーコードという位置づけの強みです。

提供元のPraztoは、2022年にSalesforceのルーキーパートナーとして最優秀賞「Emerging Partner of the Year – Consulting –」を受賞。350社以上の連携・導入支援実績があります。初期構築には1ヶ月の伴走支援がつくため、SOQLやガバナ制限といった専門知識がなくても連携を立ち上げられます。

AI機能もGA済みで、AIチャットでの対話からフローを組み立てたり、Slackでの会話操作から連携を実行したりすることもできます。詳しくはSlackからのAgentic ETL操作をご覧ください。

06　業務シーン別の活用例

ここまで整理してきた連携手段と比較軸は、実際にはどの業務シーンで使うかによって、優先すべきポイントが変わってきます。代表的な3つのシーンを例に見てみます。

Salesforce×kintone｜案件・請求データの双方向同期

営業がSalesforceで管理する案件情報と、事務・経理がkintoneで管理する請求情報を突き合わせ、双方向で同期したいケースです。片方で更新した内容がもう片方にも反映される必要があるため、外部IDによるupsertに対応した連携が向いています。標準オブジェクトだけでなくカスタム項目まで正確にマッピングできるかが、実運用での使いやすさを左右します。

商談データをBigQueryへ集約｜BIでのパイプライン分析

Salesforceの商談（Opportunity）データを含む複数オブジェクトを日次でBigQuery等のDWHへ集約し、TableauなどのBIでパイプラインを可視化したいケースです。大量データを定期的に抽出する処理が中心になるため、API消費量への配慮と、差分取得を含む安定した実行が重要になります。

広告リードのSalesforce自動投入｜獲得から商談化までの一気通貫

Meta広告やGoogle広告経由で獲得したリード情報を、手作業を挟まずSalesforceのリードオブジェクトへ自動投入したいケースです。重複登録を避けるための外部ID管理と、リードの獲得から商談化までを一気通貫で追えるようにする設計が鍵になります。

07　よくある質問

Data Loaderと連携ツールの違いは何ですか？

Data LoaderはCSVファイルを介した手動またはコマンドラインでの一括処理が基本で、単発の移行や低頻度の更新に向いています。一方、汎用データ連携ツールはスケジュール実行や差分検知、複数システムとのマッピングをノーコードで継続的に自動化できる点が異なります。日常的に繰り返す連携であれば連携ツール、一度きりのデータ移行であればData Loaderという住み分けで考えるとよいでしょう。

API使用量が心配なのですが、どう対策すればよいですか？

まず想定するデータ量と実行頻度を洗い出し、全件取得ではなく更新日時などをキーにした差分取得に切り替えることが有効です。あわせて、Bulk APIに対応した連携ツールを選ぶことで、消費量を抑えながら安定した連携を続けられます。

カスタムオブジェクトや項目も連携できますか？

多くの連携ツールは標準オブジェクトに加えてカスタムオブジェクト・カスタム項目にも対応していますが、対応範囲はツールによって差があります。項目レベルでのマッピングが可能か、独自に追加したオブジェクトも一覧から選択できるかを、導入前に必ず確認しておくことをおすすめします。

リアルタイムに近い連携は可能ですか？

連携ツールやAPI開発であれば、Webhookやイベント連携の仕組みを利用することで、数分単位に近い頻度での同期を組める場合があります。ただしAPI消費量とのトレードオフになるため、どこまでのリアルタイム性が業務上本当に必要かを見極めたうえで、実行頻度を設計することが重要です。

AppExchangeアプリとの使い分けはどう考えればよいですか？

対応する連携先システムがAppExchange上に用意されており、標準的な連携内容で足りるのであれば、設定だけで完結するAppExchangeアプリが最短ルートになります。複数システムをまたぐ連携やカスタムオブジェクトを含む柔軟なマッピングが必要な場合は、汎用データ連携ツールを検討するのがおすすめです。

08　まとめ：手段で絞り、要件で決める

Salesforce連携ツールの選び方は、いきなり製品を比較するのではなく、まずAppExchangeアプリ・Data Loader・汎用データ連携ツール・API開発という4つの手段で自社の用途に合う候補を絞り込み、次にカスタムオブジェクト対応や外部IDupsert、API消費量、ガバナ制限といった実務観点で判断するという2段階で考えると失敗しにくくなります。特に双方向での書き戻しやオンプレを含む統合が必要であれば、EAI型でありながらノーコードという位置づけの連携ツールが有力な選択肢になります。まずは自社にとって欠かせない要件を1つ書き出すところから始めてみてください。