--- title: "ShopifyとSalesforceの連携方法｜5つの手段の比較とAPI制限の設計【2026年版】" url: "https://www.issoh.co.jp/column/details/2955/" published: 2024-07-05 updated: 2026-09-27 categories: ["EC"] publisher: "株式会社一創" --- # ShopifyとSalesforceの連携方法｜5つの手段の比較とAPI制限の設計【2026年版】 ShopifyとSalesforceをつなぐ話には、性質の違う2つの相談が混ざっています。ひとつは「ShopifyのECデータをSalesforceのCRMへ流したい」という連携の相談。もうひとつは「ECの基盤としてShopifyとSalesforce Commerce Cloudのどちらを選ぶか」という比較の相談です。前者を進めるつもりで後者の情報を読むと、話がまったく噛み合いません。この記事では前者、つまりShopifyを残したままSalesforceへデータを寄せる連携を扱い、手段の選び方と、双方のAPI上限から逆算する同期設計までを整理します。 ## まとめ 連携手段は、連携アプリ・Salesforce Connect・iPaaS・Data 360のShopifyコネクタ・GraphQL Admin APIによる自前開発の5通りです。選定は機能一覧ではなく、必要な同期の遅延許容度と、社内に開発体制があるかどうかの2軸で決まります。 設計判断で最も影響が大きいのは、ShopifyのREST Admin APIが2024年10月1日付でレガシーAPIとなり、2025年4月1日以降の新規公開アプリはGraphQL Admin APIのみで作る必要がある、という前提の変化です。2024年より前の手順書やベンダー製コネクタはこの変化に追随していないことがあり、REST前提で組んだ実装は将来の作り直しを抱えます。同期の粒度は、Shopify側の単一クエリ1,000ポイントという壁と、Salesforce側の24時間あたりAPIコール上限の両方から逆算してください。以降で、切り分け・データ設計・手段比較・API仕様・上限設計・失敗パターンの順に見ていきます。 ## ShopifyとSalesforceの関係整理：Commerce Cloudとの切り分け Salesforceは2016年7月11日にDemandwareの買収を完了し、これを「Salesforce Commerce Cloud」として自社のEC基盤に据えました。つまりSalesforceは、CRMのベンダーであると同時にShopifyの競合でもあります。ここを押さえずに情報を集めると、Commerce Cloudの導入・移行の話とCRM連携の話が混ざったまま設計に入ることになります。 SalesforceがShopify向けに公式提供しているのは、後述するData 360のShopifyコネクタと、MuleSoftのAnypoint Connector for Shopifyです。いずれもShopifyのデータをCRM側へ取り込むためのもので、Commerce Cloudとは無関係です。実務で「ShopifyとSalesforceの連携」と呼ばれているものも、ほぼ例外なくShopify（EC）とSales Cloud・Marketing Cloud・Data 360（CRM側）のデータ連携を指します。Salesforce側の製品構成そのものが曖昧なままなら、先に[SalesforceというCRMの機能構成と料金体系](/column/details/15087/)を確認してから連携の設計に入ったほうが早く進みます。 ## 連携対象になるデータとマスタ設計 連携の設計は「何を同期するか」ではなく「どちらを正とするか」から決めます。マスタを決めないまま双方向同期を組むと、更新が往復して値が振動します。 ### 顧客・注文のマスタをSalesforceへ置く判断基準 顧客と注文は、Salesforceを参照先にする価値が最も高いデータです。Shopifyの注文をSalesforceの取引先責任者に紐づけると、営業やサポートがCRMの画面だけで購買履歴を確認でき、EC管理画面へ切り替える手間がなくなります。方向は基本的にShopifyからSalesforceへの一方向で足ります。Salesforce側で注文を作り直す運用は、返品・キャンセルの整合を自前で持つことになるため、よほどの理由がなければ避けてください。 実装上の起点になるのは、Shopifyのwebhookトピック `orders/create` と `customers/create` です。注文確定のたびにイベントを受け、Salesforce側では外部ID項目に対するupsertで書き込みます。upsertにしておけば、再送やリトライが起きても同じ注文が二重に登録されません。 ### 商品・在庫をShopify側に固定する理由 商品と在庫は逆で、Shopifyを正としたほうが破綻しません。在庫はカート投入から決済までの間に動く値で、Shopify側が販売の最前線にいる以上、CRMを経由した反映では常に遅れます。SalesforceにはShopifyの在庫を参照用として持たせ、更新はShopify側でのみ行う構成が安全です。 商品情報の変更を拾う場合は、webhookトピック `products/create`・`products/update`・`products/delete` を購読します。基幹システムが別にあり、そちらが在庫の正である場合は、基幹からShopify、ShopifyからSalesforceの順に流し、Salesforceから在庫を書き戻す経路は作らないでください。書き戻し経路を1本作った時点で、どちらが正なのかが運用の中で曖昧になります。 ## 連携手段5通りの比較と選定基準 選定軸は、許容できる反映の遅れと、開発・保守を誰が担うかの2つです。機能の多さで選ぶと、月額数千円のコネクタで足りる要件に自前開発を始めることになります。 | 手段 | 同期の粒度 | 必要な開発体制 | 費用感 | 向く要件 | | ------------------ | ------------ | ------------ | ------------ | -------------- | | 連携アプリ | 注文・顧客の定型同期 | 不要 | 月額19〜39ドル＋従量 | 項目が定型で件数が読める | | Salesforce Connect | 参照のみ（保存しない） | OData中継の設定者 | 中継製品のライセンス費 | CRMから参照できれば足りる | | iPaaS・MuleSoft | 任意（変換込み） | 連携基盤の担当者 | ライセンス費 | 他システムも同時に束ねる | | Data 360コネクタ | バッチ／ゼロコピー | Data 360の設定者 | Data 360の消費枠 | 分析・セグメント用途 | | 自前開発 | webhookで即時も可 | 常設の開発チーム | 開発費＋保守費 | 独自項目・独自ロジック | ### 連携アプリ：定型項目での最短ルート Shopify App Storeの「Salesforce Sync」（CRM Perks）は、Shopifyの顧客と注文をSalesforceの取引先・取引先責任者・リード・受注へ同期し、項目マッピングと過去データの送信に対応します。2026年8月時点の料金は月額19〜39ドルの3プランで、プランごとに月100〜1,000件の同期枠があり、超過分は1注文あたり0.02〜0.07ドルの従量課金です。7日間の無料トライアルが付きます。 注意点は上限の設計です。月1,000件を超えるストアでは従量課金が積み上がるため、月間注文数が数千件規模なら、この時点でiPaaSや自前開発と比較しておく価値があります。日本語のUIやサポートが必要なら、Shopify App Storeだけでなく、AppExchange側で公開されている国内ベンダーの連携アプリも候補に入れてください。 ### Salesforce Connect：外部オブジェクトによる参照専用の連携 Salesforce Connectは、外部システムのデータをSalesforceに保存せず、外部オブジェクトとして参照する機能です。データをコピーしないため、ストレージを消費せず、同期ずれも原理的に起きません。CRMの画面からShopifyの注文を見られれば十分で、Salesforce側でレポートや自動化の対象にしないのであれば、この構成が最も軽く済みます。 ただしShopifyはODataを直接提供していないため、Shopify APIをOData化する中継製品を挟む必要があります。日本語検索でも、CDataのコネクタを使ってShopifyを外部オブジェクト化する手順が上位に出てきます。逆に、Salesforce側で注文を集計したい、Flowで処理を起動したいといった要件が出た時点で、外部オブジェクトでは扱いにくくなります。将来そこまで踏み込む見込みがあるなら、最初から取り込み型を選んでください。 ### iPaaS：複数システムを束ねる場合の選択 SalesforceグループのMuleSoftには、Anypoint Connector for Shopifyが用意されています。ただしこのコネクタは、公式ドキュメントに「exposes operations provided by the Shopify REST Admin API」と明記されているとおり、REST Admin APIを叩く実装です。認証はBasic AuthまたはOAuth2に対応します。ZapierやMakeのような軽量なiPaaSでも同種の連携は組めますが、こちらは処理件数と項目数が増えたときの費用が読みにくくなります。 ERPやWMSなど複数システムをまとめて連携するならiPaaSの投資は回収できますが、ShopifyとSalesforceの2点間だけを結ぶために導入すると割高です。判断の目安は、連携先が3系統を超えるかどうかです。 ### Data 360のShopifyコネクタ：分析用途への限定 Salesforce Data 360（旧Data Cloud）には公式のShopifyコネクタがあり、バッチ取り込みとゼロコピー（Query Federation）の両方に対応します。ただし公式ドキュメントは「beta for batch ingestion and beta for Zero Copy (Query Federation) Data Federation」と記載しており、2026年8月時点でいずれもベータ扱いです。対応スキーマはGRAPHQL-2024-07とREST-2024-07です。業務トランザクションの同期基盤としてではなく、セグメント作成や分析のためのデータ取り込みとして位置づけるのが妥当な段階といえます。 ### 自前開発：独自項目と即時性が要る場合 受注に独自項目が多い、あるいは注文確定から数秒でSalesforce側の処理を走らせたい場合は自前開発になります。Shopifyのwebhookで注文イベントを受け、GraphQL Admin APIで必要な項目を取得し、SalesforceのREST APIまたはBulk API 2.0へ書き込む構成が基本形です。同じ判断の型は他のSaaS連携でも共通で、[Shopifyとkintoneを連携するときの手段選定とAPI制限の考え方](/column/details/2341/)は本記事とほぼ同じ骨格で整理しています。 ## Shopify Admin APIの現在地：RESTのレガシー化とGraphQL前提への移行 2024年より前に書かれた連携手順の多くは、Shopify管理画面でAPIキーを発行してREST APIを叩く、という前提に立っています。この前提はすでに崩れています。 ### 2024年10月1日のレガシー化と、2025年4月1日の公開アプリ要件 Shopifyの公式リファレンスは、REST Admin APIについて「The REST Admin API is a legacy API as of October 1, 2024\. Starting April 1, 2025, all new public apps must be built exclusively with the GraphQL Admin API.」と明記しています。同ドキュメントにREST Admin APIの提供終了時期は記載されておらず、いつ停止するかは公表されていません。一方で「Some newer platform features may only be available in GraphQL.」ともあり、新しいプラットフォーム機能はGraphQL側にしか提供されない場合があります。 実務上の判断はこうです。これから作る連携は、内製・外注を問わずGraphQL Admin APIを前提にしてください。ベンダー製コネクタを採用する場合も、その製品がRESTとGraphQLのどちらを叩いているかを契約前に確認する価値があります。前述のMuleSoftコネクタのように、Salesforceグループの製品であってもREST Admin API実装のものが現存します。 GraphQL Admin APIのリクエストは、POSTでバージョン付きエンドポイントへ送り、アクセストークンをヘッダーで渡します。以下は公式ドキュメントに記載されている最小の例です。 ``` curl -X POST \ https://{shop}.myshopify.com/admin/api/2026-07/graphql.json \ -H 'Content-Type: application/json' \ -H 'X-Shopify-Access-Token: {SHOPIFY_ACCESS_TOKEN}' \ -d '{ "query": "query { shop { name } }" }' ``` ### 四半期バージョンとサポート期限 Shopifyは四半期ごと、各四半期の初日にAPIバージョンをリリースします。バージョン名は日付形式（例：2026-04）で、各安定版は最低12カ月サポートされ、連続するバージョン間には9カ月以上の重複期間が設けられます。到達不能なバージョンを指定したリクエストは、アクセス可能な最古の安定版へ「fall forward」して応答されます。つまり指定を放置しても即エラーにはならず、意図しないバージョンで動き続ける形になります。 | 安定版 | リリース日 | アクセス可能期限 | | ------- | ---------- | --------------------- | | 2025-10 | 2025年10月1日 | 2026年10月16日 15:00 UTC | | 2026-01 | 2026年1月1日 | 2027年1月16日 15:00 UTC | | 2026-04 | 2026年4月1日 | 2027年4月16日 15:00 UTC | | 2026-07 | 2026年7月1日 | 2027年7月16日 15:00 UTC | 表に無い旧版はすでに失効しています。たとえば2025-07は2026年7月16日に期限を迎えており、これを指定したままの実装はfall forwardで別バージョンの応答を受け取っています。連携の保守計画には、四半期ごとのバージョン確認を組み込んでください。 ## API上限から逆算する同期設計 同期の頻度と粒度は、要件からではなく上限から決めます。1日1回の全件同期を選んだ結果、Salesforce側の日次コール枠を昼前に使い切る、という事故はここを飛ばしたときに起きます。 ### Shopify側：クエリコストと単一クエリ1,000ポイントの壁 GraphQL Admin APIはリクエスト数ではなく、クエリの計算コストで制限されます。リーキーバケット方式で、1秒あたりの復元ポイント数がプランごとに決まっています。 | プラン | GraphQL Admin API 上限 | | ------------------- | -------------------- | | Standard | 100ポイント/秒 | | Advanced | 200ポイント/秒 | | Shopify Plus | 1,000ポイント/秒 | | Commerce Components | 2,000ポイント/秒 | コストはフィールド単位で加算され、スカラーと列挙型が0、オブジェクトが1、ミューテーションが10です。インターフェースと共用体は選択されうるフィールドの最大値、コネクションはfirstとlastの指定値で決まります。公式ドキュメントの指針は「Optimize your code to only get the data that your app requires.」で、不要なフィールドを含めないことが唯一の効く対策です。 設計上の実質的な天井は、プラン別の復元レートではなく単一クエリのコスト上限です。公式ドキュメントは「A single query may not exceed a cost of 1,000 points, regardless of plan limits.」と定め、この判定はクエリ実行前に要求コストで行われると明記しています。プランを上げても1回で取れる量は変わりません。加えて入力配列は最大250件、ページネーションは25,000件が上限で、件数取得は25,000件を超えると25,001として返ります。25,000件を超える範囲を舐める設計は、そもそもGraphQL Admin API向きではないと考えてください。 ### Salesforce側：エディション別のコール枠 Salesforceは24時間あたりの合計APIリクエスト数で制限されます。エディションとライセンス数で決まる点が特徴で、ユーザー数の少ない組織ほど枠が薄くなります。 | エディション | 24時間あたりのAPIリクエスト上限 | | ------------------------------- | -------------------------- | | Developer Edition | 15,000 | | Enterprise / Professional（API付） | 100,000＋ライセンス数×1,000＋追加購入分 | | Unlimited / Performance | 100,000＋ライセンス数×5,000＋追加購入分 | 表のライセンス単価は、SalesforceライセンスとSalesforce Platformライセンスの場合の値です。External Identityなど他のライセンス種別は別の係数が適用されるため、実際の枠は自組織のライセンス構成で計算してください。20秒以上かかる同時実行リクエストにも別枠があり、Developer Editionとトライアル組織で5、本番組織とSandboxで25です。大量の初期移行や日次バッチをREST APIのループで流すとこの枠を圧迫するため、まとまった件数はBulk API 2.0へ寄せます。Bulk API 2.0はローリング24時間で1億5,000万レコードの取り込み、1ジョブあたり150MBが上限で、日次数万件規模の同期であれば制約になることはまずありません。Salesforce側の方式選定と実効残量の算出手順は[SalesforceのAPI方式選定とコール上限の設計](/tech/details/16155/)で個別に扱っています。 受け皿にするクラウドは、その後の使い道で決まります。営業とサポートが顧客の購買履歴を見るならSales Cloud、購買行動を起点にシナリオ配信を組むならMarketing Cloud、複数チャネルのデータを突合して分析するならData 360です。アパレルや製造業のように、既存の基幹システムやコールセンターが絡む構成では、EC以外の経路も同じCRMへ集約する前提で設計しないと、後から連携先が増えるたびに作り直しになります。電話とCRMをつなぐ場合の考え方は[SalesforceとTwilioを組み合わせた顧客接点の設計](/column/details/1945/)でも触れています。 ## 失敗しやすい構成と、避けるべき場面 ここまでの上限を踏まえると、選ぶべきでない構成がはっきりします。 ### 全件双方向リアルタイム同期を避ける理由 最初の要件定義で「両システムを常に一致させたい」と言われることがありますが、これは実装してはいけない構成です。双方向にすると更新のループが起き、リアルタイムにすると上限に張り付き、全件にすると差分検知の余地がなくなります。Shopify側は単一クエリ1,000ポイント、Salesforce側は長時間リクエストの同時実行25件という天井があり、全件を一度に流す設計はどちらの側でも通りません。取るべき構成は、マスタを片側に固定し、webhookで発生した差分だけを流し、失敗分を夜間バッチで補う形です。反映の遅れを数分許容できるだけで、必要なAPIコール数は桁で変わります。 ### メールアドレス単独の名寄せが抱えるリスク Shopifyはゲスト購入を許可でき、同一人物が別のメールアドレスで複数回購入することがあります。ゲスト購入と法人購買が混在するストアでメールアドレスだけを突合キーにすると、Salesforce側に同じ顧客の取引先責任者が積み上がります。突合はメールアドレスに加えて電話番号や配送先を組み合わせ、判定できなかったものは自動作成せず、重複候補として保留する運用にしてください。外部ID項目にはShopifyの顧客IDを据えます。Shopify側で一意な値を鍵にしておけば、メールアドレスが変更されても同じ取引先責任者に紐づきます。重複してから統合するより、作らないほうが安く済みます。 ### コネクタ採用前に見るべき対応APIバージョン ベンダー製コネクタは、対応するShopify APIバージョンが実際の最新版より大きく遅れることがあります。MuleSoftのShopifyコネクタは、リリースノート上、2026年1月31日リリースの1.1.10まで対応バージョンがv.2021-10のままでした。2026年2月26日の1.1.11でv.2026-01へ引き上げられ、最新は2026年8月14日リリースの1.1.13（Mule 4.3.0以降）です。導入検討時には、製品名や機能一覧ではなく、リリースノートの対応APIバージョンと更新頻度を見てください。ここが数年止まっている製品は、Shopify側のバージョン失効時に真っ先に影響を受けます。 もっとも、こうした判断を都度社内だけで担うのが難しい場合もあります。Salesforce側の設計と運用に継続的な支援が必要なら、[Salesforce導入支援サービスで何をどこまで任せられるか](/column/details/7448/)を先に確認しておくと、内製と外注の線引きが決めやすくなります。 ## よくある質問 ### API連携とは何ですか？ API連携とは、システムが外部向けに公開している操作の入口（API）を通じて、別のシステムからデータを読み書きする仕組みです。画面を人が操作する代わりにプログラムが呼び出すため、注文が入った時点で自動的にCRMへ登録する、といった処理を人手を介さずに実行できます。ShopifyとSalesforceの場合、ShopifyのAdmin APIとSalesforceのREST API／Bulk API 2.0がその入口にあたります。 ### SalesforceはShopifyを買収したのですか？ いいえ。SalesforceはShopifyを買収していません。混同されやすいのは、Salesforceが2016年7月11日にDemandwareの買収を完了し、これをSalesforce Commerce Cloudとして自社のEC基盤に位置づけた経緯があるためです。Commerce CloudはShopifyと同じEC基盤の領域にある製品で、両社は連携相手であると同時に競合関係にあります。 ### ShopifyのREST Admin APIは今も使えますか？ 既存の実装は動作しますが、2024年10月1日付でレガシーAPIに位置づけられています。2025年4月1日以降、Shopify App Storeへ新規に公開するアプリはGraphQL Admin APIだけで構築する必要があり、新機能もGraphQL側からのみ提供される場合があります。提供終了の時期は公表されていませんが、これから設計する連携でRESTを選ぶ理由はほとんどありません。 ### Shopify APIにはどんな種類がありますか？ 連携で使うのは主にAdmin API（GraphQL）です。バージョン管理されるAPIはほかに、Storefront API、Customer Account API、Function APIs、Payments Apps API、Partner API、そしてwebhookがあります。一方、Ajax APIやLiquid、OAuthエンドポイント、Customer Privacy APIはバージョン管理の対象外で、予告なく変更される可能性があります。ShopifyとSalesforceの連携では、Admin APIで注文や顧客を取得し、webhookで発生イベントを受け取る組み合わせが基本形になります。 ### 連携アプリと自前開発は、どちらを選ぶべきですか？ 同期する項目が標準の顧客・注文で収まり、月間注文数が連携アプリのプラン枠に収まるなら、連携アプリのほうが総コストで有利です。独自項目が多い、複数システムを経由する、注文確定から数秒でSalesforce側の処理を走らせたい、のいずれかに当てはまる場合は自前開発を検討してください。判断がつかない場合は、まず連携アプリで動かして必要な項目を洗い出し、枠が足りなくなった時点で移行する順序が無駄になりません。 ## 関連記事 - [Salesforceのシステム連携とは？API方式の選定とコール上限の設計を実装目線で解説](/tech/details/16155/) - [ShopifyとkintoneのAPI連携｜手段の選び方・実現できることとAPI制限の設計【2026年版】](/column/details/2341/) - [Salesforceとは？CRMの機能・料金・認定資格から導入判断まで解説](/column/details/15087/) - [Salesforce導入支援サービスの概要とビジネスにもたらす価値](/column/details/7448/) - [Salesforce×Twilioで実現する顧客体験の変革](/column/details/1945/) --- 出典: [ShopifyとSalesforceの連携方法｜5つの手段の比較とAPI制限の設計【2026年版】]()（株式会社一創）