Shopify API連携の設計方法｜受注・在庫・会計がズレない外部連携

Shopifyで受注が増えてくると、最初に負荷が出るのは画面の見た目ではありません。

• 注文CSVをダウンロードしてWMSへ取り込む
• 出荷済みの追跡番号をShopifyへ手入力する
• 在庫数を倉庫、Shopify、モールで見比べる
• 返金済みの注文を会計ソフトへ反映し忘れる
• CRMやメール配信ツールの顧客情報が古い
• 連携エラーが起きても、誰も気づかない

こうなると「Shopify API連携を作ろう」という話になります。

方向性は正しいです。ただし、API名から考え始めると失敗しやすくなります。

Shopify公式ブログでも、ShopifyはAdmin API、Functions、Storefront、B2B APIなどを通じて、注文、在庫、顧客データやバックオフィス連携を扱えると説明されています。

Shopify公式ブログ: ECサイトのAPI連携とは？仕組みや活用方法を解説

また、Shopify公式ヘルプでは、ERP、CRM、PIM、会計など外部システムとの連携方法として、直接連携、iPaaS、カスタムAPIを挙げています。

Shopifyヘルプセンター: 外部システムとShopify B2Bを連携させる

ここで重要なのは、「APIで何ができるか」ではなく「どの業務データをどちらへ動かすべきか」です。

Shopify API連携で先に決めるべきなのは、Admin APIかWebhookかではなく、商品、注文、在庫、顧客、出荷、会計の正本と同期イベントです。

先に結論：APIをつなぐ前に正本と同期イベントを決める

Shopify API連携は、1本の連携で全部を同期する話ではありません。

最低でも次の5つを先に決めます。

決めること	具体的に見る点
データの正本	商品、SKU、在庫、顧客、売上、返金、出荷状態をどのシステムで正式管理するか
同期イベント	注文作成、支払確定、出荷完了、返金、返品、顧客更新のどこで動かすか
同期方向	Shopifyから外部へ送るのか、外部からShopifyへ戻すのか、双方向にするのか
失敗時の処理	リトライ、自動停止、Slack通知、手動補正、二重処理防止をどうするか
人の確認点	返金、返品、住所不備、在庫差異、会計計上など、人が判断する点をどこに残すか

API連携の目的は、手作業をゼロにすることではありません。

正しいデータを、正しいタイミングで、正しい相手へ渡し、例外が起きたときに戻せる状態を作ることです。

Shopify API連携で扱う主なデータ

Shopify連携で扱うデータは、大きく分けると次のようになります。

領域	主なデータ	正本の候補	API連携で決めること
商品マスタ	商品名、説明、画像、SKU、JAN、原価、メタフィールド	Shopify、PIM、基幹システム	販売情報と社内管理情報をどこで更新するか
注文	注文番号、明細、支払状態、配送先、割引、税	Shopify	どの状態になったらWMS、CRM、会計へ渡すか
在庫	SKU、ロケーション、販売可能数、引当、入出庫	Shopify、WMS、基幹在庫	在庫数をどちらからどちらへ反映するか
出荷	出荷指示、配送会社、追跡番号、出荷完了、返品	WMS、配送管理、Shopify	出荷完了と追跡番号をShopifyへどう戻すか
顧客	氏名、メール、電話、住所、タグ、購入履歴、同意情報	Shopify、CRM、MA	顧客更新と配信可否をどこで正式管理するか
会計	売上、送料、手数料、返金、税、入金、仕訳	freee、マネーフォワード、会計ソフト	注文単位、入金単位、日次集計のどれで渡すか
通知	連携失敗、低在庫、住所不備、高額注文、返金待ち	Slack、メール、タスク管理	誰が何を見て対応するか

この表を作らずにAPI実装へ入ると、あとから「顧客名はCRMが正しいのか、Shopifyが正しいのか」「返金はShopifyで処理しただけで会計に渡っているのか」という混乱が起きます。

Admin API、Storefront API、Webhook、Flow、iPaaSの使い分け

Shopify API連携では、方式を用途ごとに分けます。

方法	向いている用途	注意点
Admin API	商品、注文、顧客、在庫、フルフィルメントなど管理側データの読み書き	権限、APIバージョン、レート制限、エラー処理を設計する
Storefront API	ヘッドレスEC、外部サイト、アプリなどで商品、検索、カートを扱う	バックオフィス連携や会計連携の中心にはしない
Webhook	注文作成、商品更新など、イベント発生を外部へ通知する	受信API、署名検証、重複排除、再実行ログが必要
Shopify Flow	タグ付け、メール、Slack通知、HTTPリクエストなど軽い自動化	複雑な状態管理や厳密な再実行には向かない
iPaaS	Shopifyと会計、CRM、スプレッドシートなどの同期を短く始める	例外処理、項目変換、再実行範囲をブラックボックスにしない
カスタムアプリ/API	独自DB、WMS、会計、通知、承認を含む運用基盤	初期設計と保守担当を明確にする

ShopifyのGraphQL Admin APIは、Shopify管理画面を拡張するアプリや連携を作るためのAPIとして説明されています。

Shopify Dev Docs: GraphQL Admin API reference

一方、Storefront APIは商品、検索、カートなど外部の購入体験側で使うAPIです。Shopify公式ドキュメントでも、Storefront APIはGraphQLで提供され、商品、コレクション、検索、カートなどを扱う文脈で説明されています。

Shopify Dev Docs: Storefront API reference

受注、在庫、出荷、会計をつなぐなら、中心になるのは多くの場合Admin APIとWebhookです。

ただし、軽い通知やタグ付けならShopify Flowで十分なこともあります。Shopify Flowのアクションには、注文タグの追加、顧客タグの削除、フルフィルメント注文の保留、メール送信、Slackメッセージ送信、外部サービスへのHTTPリクエスト送信などがあります。

Shopifyヘルプセンター: Shopify Flow のアクション

連携方式は、機能名ではなく「更新するデータ」「起点になるイベント」「失敗時の戻し方」で選びます。

商品マスタとメタフィールドをどう連携するか

商品マスタは、Shopify API連携の中でも特に崩れやすい領域です。

見た目の商品情報と、社内管理に使う商品情報が混ざりやすいからです。

項目	Shopifyで持ちやすいもの	外部正本にしやすいもの
商品名、説明文、画像	EC担当が販売ページとして編集する情報	ブランド全体でPIM管理している情報
SKU、JAN、型番	小規模ECでShopify中心に管理する場合	基幹、WMS、PIM、会計で共通キーにする場合
原価、仕入先、発注単位	メタフィールドで参照する程度	原価管理、発注管理、会計で正式に使う情報
サイズ、色、素材	商品バリエーションやメタフィールド	商品規格マスタが別にある場合
発送温度帯、同梱不可、危険物区分	出荷指示に必要ならメタフィールド	WMS側の出荷ルールが正本の場合

商品連携で避けたいのは、Shopifyの商品画面と外部マスタの両方で同じ項目を自由に編集できる状態です。

たとえばSKUをShopify側で手修正できるままにすると、WMSや会計ソフトの明細と紐づかなくなります。

逆に、商品説明や画像までPIMや基幹から上書きする設計にすると、EC担当が販売ページを改善しにくくなります。

商品マスタは、次のように分けると整理しやすくなります。

データ	正本	更新方向
販売ページの見せ方	Shopify	Shopify内で編集する
SKU、JAN、倉庫連携キー	外部商品マスタまたはWMS	外部からShopifyへ反映する
検索・絞り込み用属性	ShopifyまたはPIM	どちらで商品運用するかに合わせる
出荷・梱包ルール	WMSまたは出荷管理	Shopifyへ必要最小限だけ持たせる
原価・仕入先	会計、販売管理、基幹	Shopifyには表示・判断に必要な範囲だけ持たせる

ShopifyのAdmin APIには、Products and collections、Inventory、Metafieldsなどの領域があります。

Shopify Dev Docs: GraphQL Admin API reference

APIで商品を更新できることと、商品マスタの責任をShopifyに寄せることは別です。

受注、出荷、追跡番号、在庫更新の連携フロー

受注から出荷までの基本フローは、次のように分けて考えます。

顧客
  ↓ 注文
Shopify
  ↓ orders/create Webhook
連携基盤・中間DB
  ↓ 出荷指示
WMS・配送管理
  ↓ 出荷完了・追跡番号
Shopify
  ↓ 顧客通知・注文ステータス更新
顧客

WMS・在庫正本
  ↓ 在庫更新
Shopify
  ↓ 低在庫・差異・同期失敗
Slack・メール・タスク管理

ShopifyのWebhookドキュメントでは、orders/create のようなトピックを購読し、イベント発生時に指定したエンドポイントへペイロードが送られる流れが説明されています。

Shopify Dev Docs: About webhooks

このフローで決めることは、APIの呼び出し方だけではありません。

イベント	連携するデータ	設計で決めること
注文作成	注文、明細、配送先、支払状態	未払い注文や不正疑い注文をWMSへ送るか
支払確定	支払状態、金額、決済方法	出荷可能にする条件をどこで判定するか
出荷指示	SKU、数量、配送先、温度帯、同梱条件	Shopify明細をWMSが扱える単位に変換する
出荷完了	配送会社、追跡番号、出荷日時	WMSからShopifyへどの単位で戻すか
在庫更新	SKU、ロケーション、販売可能数	WMSとShopifyのどちらを正本にするか
返品・返金	返品状態、返金額、検品結果	在庫復帰と会計反映を自動にするか確認後にするか

在庫更新をどう設計するかは、別記事のShopify在庫連携の設計方法でも詳しく整理しています。

API連携では、注文を送るだけでは足りません。

出荷完了、追跡番号、在庫更新、返金、返品後の在庫復帰まで含めて、どのイベントを正とするかを決めます。

顧客、CRM、メール、LINE連携の境界

顧客データは、便利だからといって全部を双方向同期にすると壊れやすい領域です。

特に次の項目は、正本を分けます。

データ	Shopify側で持つ意味	CRM・MA・LINE側で持つ意味
氏名、メール、電話	注文、配送、顧客アカウントのため	顧客管理、問い合わせ、営業・販促のため
住所	注文配送に使う	顧客台帳や請求先管理に使う
購入履歴	Shopify注文履歴として見る	セグメント、LTV、問い合わせ文脈に使う
タグ	EC運用上の分類	配信対象、興味関心、営業状態に使う
配信同意	ストアのマーケティング同意	メール、LINE、広告連携の配信可否に使う

CRMやメール配信、LINE連携では、「購入したら自動で顧客を作る」だけでは足りません。

次のような例外が起きます。

• 同じ人が別メールアドレスで購入する
• 家族の名前で注文し、本人のLINEと紐づかない
• 法人顧客で会社、担当者、配送先が分かれる
• 配信停止した人へ別ツールから再度送ってしまう
• 返金・返品後も優良顧客セグメントに残る

APIで顧客情報を同期するなら、顧客ID、メール、電話、会員ID、LINE user IDなどのキーをどう扱うかを先に決めます。

顧客連携の目的は、顧客データを増やすことではありません。

問い合わせ、販促、再購入、返品対応の場面で、担当者が正しい履歴を見られる状態にすることです。

freeeや会計ソフトへ渡すデータ粒度

Shopifyとfreee、マネーフォワードなど会計ソフトを連携するとき、売上金額だけを渡す設計は危険です。

会計で見るべきデータは、注文データより細かく、かつタイミングが違うことがあります。

会計に渡す候補	そのまま自動化しにくい理由
注文売上	注文日、支払日、出荷日、計上日が一致しないことがある
送料	売上に含めるか、送料収入として分けるかを決める必要がある
割引	商品値引き、クーポン、ポイント、キャンペーンを分けたいことがある
決済手数料	決済サービスや入金明細と照合する必要がある
返金	返金日、返金理由、在庫復帰、手数料戻しが絡む
消費税	税率、税込・税抜、越境、軽減税率が絡む場合がある
入金	注文単位と入金単位が一致しないことがある

小規模なら、日次の売上集計を会計へ渡し、手数料や入金消込は会計側で確認する方が現実的なことがあります。

一方で、受注件数が多い、返品が多い、モールや実店舗もある、B2B請求が混ざる場合は、注文単位や明細単位で連携した方が後から確認しやすくなります。

会計連携で決めるべきことは、次の3つです。

1. Shopify注文を会計上の売上として扱うタイミング
2. 返金、手数料、送料、税をどの粒度で渡すか
3. 入金消込と仕訳の正本を会計ソフト側に残すか

API連携しても、会計判断そのものをShopifyに寄せる必要はありません。

むしろ会計ソフトを正本にし、Shopifyから必要な明細や集計を渡す設計の方が安全です。

API連携で失敗しやすい認証、権限、レート制限、重複処理

Shopify API連携で実装時に詰まりやすいのは、接続そのものより運用時の例外です。

失敗	起きること	設計で見ること
権限スコープ不足	注文は読めるが在庫を書き込めない	必要な読み取り・書き込み権限を連携ごとに分ける
権限過多	通知だけの連携が顧客情報まで読める	最小権限にする
APIバージョン未管理	ある日連携が動かなくなる	バージョン、廃止予定、変更履歴を管理する
レート制限未考慮	セール時や一括更新で失敗する	キュー、バッチ、差分同期、再試行を作る
Webhook重複	同じ注文を2回処理する	Webhook IDや注文IDで重複排除する
Webhook順序ズレ	更新イベントが前後して状態が戻る	受信時刻ではなく業務状態で処理する
手動補正なし	失敗したデータが放置される	連携ログ、再実行ボタン、補正ルールを用意する

ShopifyのWebhook検証ドキュメントでは、配信に含まれるヘッダーとして X-Shopify-Webhook-Id や X-Shopify-Hmac-SHA256 が説明され、HMAC署名検証や重複配信の扱いが示されています。

Shopify Dev Docs: Verify webhook deliveries

また、GraphQL Admin APIのドキュメントには、認証、エンドポイント、レート制限、ステータスとエラーコードの項目があります。

Shopify Dev Docs: GraphQL Admin API reference

この記事では具体的な現在の上限値までは扱いません。

理由は、ShopifyのAPI制限や利用条件はAPI種別、プラン、バージョン、実装方式で変わるためです。実装時は必ず公式ドキュメントと対象ストアの条件を確認します。

エラー通知、再実行、手動補正の運用設計

Shopify API連携は、正常系より失敗時の設計が重要です。

最低限、連携基盤には次のようなログを持たせます。

項目	内容
連携ID	Webhook ID、注文ID、外部システムIDなど
対象データ	注文、在庫、顧客、出荷、返金など
連携方向	Shopifyから外部、外部からShopify、外部から会計など
ステータス	未処理、処理中、成功、失敗、再実行待ち、手動補正済み
エラー内容	APIエラー、権限不足、項目不整合、外部システム停止など
担当者	EC担当、倉庫、経理、開発担当など
次の対応	再実行、手動修正、保留、仕様確認

Slack通知も、単に「エラーです」と送るだけでは足りません。

通知内容	通知先	必要な情報
注文連携失敗	EC担当、開発担当	注文番号、原因、再実行リンク
WMS登録失敗	倉庫、EC担当	SKU、数量、配送先、エラー項目
在庫差異	EC担当、倉庫	SKU、Shopify在庫、WMS在庫、差分
会計連携失敗	経理、開発担当	注文番号、金額、税、返金有無
顧客同期失敗	CRM担当	顧客ID、メール、重複候補

連携失敗は、開発者だけに通知しても業務は止まります。

EC担当、倉庫、経理、CRM担当がそれぞれ判断できる情報に変換して通知します。

API連携の完成度は、成功件数ではなく、失敗した注文や在庫を誰が直せるかで決まります。

アプリで足りるケース、iPaaSが向くケース、カスタムAPIにするケース

Shopify API連携は、必ずカスタム開発すべきという話ではありません。

実務では、アプリ、iPaaS、カスタムAPIを分けて使います。

選択肢	向いているケース	避けた方がよいケース
Shopifyアプリ	会計、配送、レビュー、メール配信など定番機能を早く使いたい	独自業務ルールや複数システムの例外処理が多い
直接連携	対象システムがShopify連携を公式に持っている	項目変換や例外処理を細かく制御したい
iPaaS	スプレッドシート、CRM、会計などを短期間でつなぎたい	大量データ、厳密な再実行、複雑な分岐が必要
Shopify Flow	通知、タグ付け、軽いHTTPリクエストで足りる	独自DB、複数回リトライ、詳細なログ管理が必要
カスタムアプリ/API	WMS、会計、CRM、通知、承認をまたぐ業務基盤を作りたい	保守担当や仕様管理が決まっていない

判断の目安は、「APIで作れるか」ではなく「運用で壊れたとき誰が直せるか」です。

たとえば、次のような場合はカスタムAPIや中間DBを検討します。

• 注文をWMSへ送る前に独自の出荷判定がある
• 予約商品、セット商品、同梱不可、温度帯などの出荷ルールがある
• Shopify、モール、実店舗の在庫をまとめて扱う
• freeeやマネーフォワードへ渡す前に会計用の集計が必要
• Slack通知だけでなく、未対応リストや再実行画面が必要
• 顧客、問い合わせ、購入履歴をCRM側で統合したい

逆に、次のような場合はアプリやiPaaSから始めてもよいです。

• 連携対象が1つだけ
• 項目変換が少ない
• 失敗時は手動確認でも業務が止まらない
• 月次や日次の集計で足りる
• まず運用仮説を試したい

最初から全部をカスタム開発にしない方がよいケースもあります。

ただし、アプリやiPaaSで始める場合でも、正本、同期イベント、再実行、手動補正の考え方は必要です。

まとめ

Shopify API連携を設計するときは、次の順番で考えます。

1. 商品、注文、在庫、顧客、出荷、会計の正本を決める
2. 注文作成、支払確定、出荷完了、返金、顧客更新などの同期イベントを決める
3. Admin API、Webhook、Flow、iPaaS、カスタムAPIを用途ごとに分ける
4. WMS、CRM、会計、通知基盤へ渡すデータ粒度を決める
5. 認証、権限、レート制限、Webhook重複、APIバージョンを管理する
6. エラー通知、再実行、手動補正の運用を作る
7. アプリで足りる範囲と、カスタムAPIで作る範囲を分ける

Shopify API連携は、APIを呼び出す作業ではありません。

EC運用のデータフローを決め、ズレたときに戻せる仕組みを作る作業です。