ShopifyとバックエンドのOMS（受注管理システム）をつないでいるEC事業者から、「注文の連携が最初の一度しか走らず、あとから注文をキャンセルしたり数量を変えたりしても基幹側に反映されない」という相談を受けることがあります。多くの場合、最初の注文取り込みだけは連携ツールが担ってくれていて、その後の変更が抜け落ちているのが実態です。この記事は、Shopify側で起きた注文変更（キャンセル・数量変更・住所変更・返品）を基幹側へ自動で反映させたい事業者と、その実装を検討する技術者に向けて、当社が設計時に必ず押さえている勘所をまとめます。結論を先に言えば、この種の同期は「Shopifyの標準機能だけ」では成立せず、両者の間に小さな橋渡し処理を一本置くことで解決します。そして本当に難しいのは処理を書くことではなく、更新の整合性をどう守るかと、どこで自動化を諦めるかの線引きです。
標準機能だけでは双方向にならない理由
Shopify側には「注文が変わったことを外部に通知する」仕組み（Webhook や Flow）はありますが、外部システムの受注伝票を書き換える機能はありません。逆に基幹側にも「Shopifyの変更を自分から取りに行く」機能がないことが多い。つまり両者の間には何もいないので、誰かが変更を受け取って相手を更新する橋渡しが要ります。
一方で、多くのOMSのAPIには受注伝票を更新する手段は揃っています。受注のキャンセル区分、送り先住所、明細の数量、明細のキャンセルフラグといった項目は、更新APIで書き換えられる。やりたいこと自体はAPI仕様上できるのに、間をつなぐ処理だけが存在しない、という状態です。だから解決策は「外部ツールを大がかりに載せ替える」ことではなく、「変更を検知して相手を更新するグルーコードを一本足す」ことになります。カスタマイズが膨らんで費用が跳ね上がっている連携ツールと相見積もりを取ると、この差は金額に明確に表れます。
最小構成のかたち
当社が第一候補にするのは、Shopifyの注文更新系Webhook（orders/updated、orders/cancelled、orders/edited、refunds/create）を受け口にして、API Gateway と受信用の関数でいったん受け、キューに積み、同期ワーカーが基幹APIを叩く、というサーバーレス構成です。ワーカーは「基幹側で対象の受注伝票を検索して特定する → Shopifyの変更内容と突き合わせて差分を判定する → 受注伝票を更新する」という流れで動きます。Shopifyの注文番号を検索キーにして基幹側の伝票を引き当てるのが基本です。
インフラそのものの費用は月数千円規模に収まることが多く、主なコストは開発と、後述するAPIの従量課金です。ポーリング型のiPaaSでテンプレートに乗せてしまう選択肢もあり、開発ゼロで動かせる反面リアルタイム性と複雑な差分判定に弱いので、自社開発案と並べて事業者に選んでもらうと意思決定が早くなります。
見落とすと事故る三つの整合性
橋渡しを書くだけなら難しくありません。事故はいつも整合性の側で起きます。
一つ目は冪等性です。Shopifyの Webhook は同じイベントを重複配信します。受信のたびに素直に更新すると二重反映になるので、Webhook固有のIDを記録して重複を弾く処理を必ず入れます。
二つ目は同時実行です。同じ注文に対する変更が立て続けに走ると、更新が交錯して後述の楽観ロックで確実に事故ります。キューを注文ID単位で直列化し、一つの注文に対する処理が同時に二つ走らないようにしておくのが安全です。
三つ目が楽観ロックそのものです。多くのOMSの更新APIは「伝票の最終更新日時」を必須で要求し、こちらが検索してから更新するまでの間に基幹側で伝票が触られていると、更新はエラーになります。だから「検索してから更新する」を一つのまとまりとして扱い、競合エラーが出たら再検索してやり直す作りが前提になります。ここを省くと、人が基幹画面を触った瞬間に自動更新が失敗し、しかも失敗に気づけない、という最悪の状態になります。
金額まわりにも固有の落とし穴があります。数量を変えたときに商品計や税額は再計算フラグで直せても、明細の小計は再計算対象外で、こちら側で計算してセットしないとずれることがあります。インボイス対応店舗では税率別の請求項目も絡むため、この検証工数は多めに見積もっておくべきです。明細そのものを削除できず、キャンセルフラグで無効化する仕様のOMSもあり、その場合はShopifyの注文編集で商品を丸ごと外したケースとの突き合わせロジックが要ります。
「完全自動化」は出荷確定でカットオフされる
事業者からの要望はたいてい「完全自動化」です。しかし出荷確定後の変更は、物理的に自動化できません。倉庫でピッキングが始まった注文の住所を後からシステムで書き換えても、荷物は元の住所に飛びます。出荷確定済みの伝票は原則更新できず、専用フラグを立てたときだけ更新できるOMSもありますが、出荷後にキャンセルや住所変更を機械的に反映すると倉庫の実態と伝票がずれるだけなので、ここはフラグを立てず、通知して人にエスカレーションする作りに倒すのが正解です。
だから当社は、システムを作る前に「変更受付のカットオフ時刻」を運用ルールとして合意することを強くおすすめしています。たとえば「出荷確定処理の実行前までに入った変更は全自動反映、それ以降は運用担当が個別対応」と線を引けば、自動化率は実務上ほぼ100%に近づき、システムの複雑度とリスクは大きく下がります。この線引きを先に決めないまま作ると、「自動化したのに事故が起きる」という一番まずいパターンに落ちます。
返品も筋が悪い領域です。返品伝票を操作するエンドポイントがそもそも用意されていないOMSがあり、その場合は「基幹側に返品発生のタグを自動で付けて通知し、処理自体は人が行う」半自動が上限になります。返品は件数が少ないことが多いので運用インパクトは小さいですが、「全部自動」と約束してしまわないことが肝心です。
運用費が跳ねないかを先に試算する
安く作れても運用費で逆転することがあります。基幹側APIの利用が従量課金の場合、変更一件につき「検索一回＋更新一回」で最低二コール発生するので、月間の注文数と変更発生率から事前にコール数を試算しておくべきです。想定を超えると「安く作ったのに運用費が高い」という結果になりかねません。契約プランによってはリクエスト数や通信量に上限があり、審査や追加契約が必要になることもあるため、ボリューム試算は設計と同じタイミングで済ませておきます。
まとめ
Shopifyと基幹システムの注文同期は、橋渡しのグルーコードを一本足せば解ける問題です。ただし本質的な難所はコードではなく、冪等性・同時実行・楽観ロックという三つの整合性を守ること、そして出荷確定というカットオフで自動化の限界を運用ルールとして先に合意することにあります。当社では、この線引きと従量課金の試算を実装より前に固めることを、事故を防ぐ最初の一手として位置づけています。