Shopify構築プロジェクトが炎上する原因は、デザインでもテーマでもありません。ほぼ例外なく「連携」です。在庫が合わない、受注が基幹に流れない、モール併売で売り越しが起きる——これらは公開直前ではなく、要件定義の最初の1週間で決着がついている論点です。本記事では、Shopifyと在庫・受注・基幹システムをつなぐ設計を、方式選定・マスタ設計・失敗パターンの3層で整理します。発注側が事前に何を決めておけば見積もりが安定するかまで、実務目線で解説します。
なぜ連携設計がプロジェクトの成否を分けるのか
実際、Shopify構築の見積もりが会社によって2倍3倍に開く最大の要因は、この連携範囲の解釈差です。同じ「Shopifyでサイトを作りたい」という依頼でも、在庫を手動でCSV更新する前提なら数十万円、モール3店舗と基幹システムをリアルタイムに同期する前提なら数百万円規模になります。発注側がここを言語化していないと、各社がそれぞれ勝手な前提で見積もり、比較不能な数字が並ぶことになります。
「後から連携すればいい」が通用しない理由
よくある失敗が、「まず売れるサイトを作って、連携は次のフェーズで」という進め方です。一見合理的ですが、実務では次の問題が起きます。
商品マスタの構造が固定される
SKUの持ち方、バリエーションの設計、商品コードの体系は、連携先の仕様に強く依存します。後から基幹に合わせようとすると、全商品の登録をやり直すことになります。
受注データの粒度が足りない
基幹側が必要とする項目（取引先コード、税区分、配送区分など）を最初に持たせていないと、受注データを流し込めず、結局は手入力に戻ります。
運用が人力で固まってしまう
最も厄介なのがこれです。連携なしで数か月運用すると、その手作業が業務手順として定着し、後からシステム化しても現場が使わないという状態になります。
連携対象の全体像：何と何をつなぐのか
まず「連携」という言葉を分解します。ひとくちに連携といっても、方向も頻度も難易度もまったく異なる複数の流れの束です。
| 連携の種類 | 方向 | 頻度の目安 | 難易度 |
|---|---|---|---|
| 商品マスタ（商品名・価格・画像・SKU） | 基幹 → Shopify | 日次〜随時 | 中（項目のマッピングが論点） |
| 在庫数 | 基幹/WMS ⇄ Shopify・モール | 数分〜リアルタイム | 高（最大の難所） |
| 受注データ | Shopify → 基幹/WMS | 数分〜日次 | 中〜高 |
| 出荷実績・追跡番号 | WMS → Shopify | 日次 | 中 |
| 顧客マスタ | 双方向 | 随時 | 高（名寄せが論点） |
| 会計仕訳 | Shopify → 会計 | 月次 | 低〜中 |
見積もりを比較するときは、まずこの6行のうちどれが見積もりに含まれ、どれが含まれていないかを各社に明示させてください。安い見積もりは、たいてい在庫と受注しか含んでおらず、顧客マスタや会計は「別途お見積り」になっています。高い見積もりは6行すべてを含んでいるだけで、単価が高いわけではないことも珍しくありません。金額の差は多くの場合、単価差ではなく範囲差です。
このうち、プロジェクトを壊すのはほぼ「在庫」と「受注」の2つです。商品マスタや会計は多少ずれても後から直せますが、在庫のずれは売り越し（在庫がないのに売れる）として顧客に直撃し、受注の詰まりは出荷停止として即座に事業が止まります。
【最重要】在庫連携の3方式と選定基準
在庫をどうつなぐか。実務上の選択肢は大きく3つです。ここを最初に決めないと、見積もりも要件定義も始まりません。
Shopifyアプリによる連携
在庫連携・モール連携を担うアプリを導入する方式。初期費用が最も小さく、立ち上がりが速いのが利点です。一方で、連携できる項目・タイミング・エラー時の挙動はアプリの仕様に縛られます。自社の業務がアプリの想定する型に収まるかが分かれ目で、収まるなら最良の選択、収まらないなら最悪の選択になります。
連携サービス／iPaaSを挟む
Shopifyと基幹・モールの間に、受注・在庫を集約する連携基盤を置く方式。モール併売がある事業者の実質的な標準解です。在庫の在り処が1か所に定まり、モールが増えても構造が壊れません。費用は月額で継続的に発生しますが、スクラッチ開発に比べれば総額は読みやすいのが利点です。
Admin APIによるスクラッチ開発
ShopifyのAdmin APIを使い、自社仕様の連携を作り込む方式。業務にシステムを完全に合わせられるのが唯一にして最大の利点です。反面、初期費用・保守費用ともに最も高く、作った会社に依存する構造が生まれます。既存の基幹が特殊で、方式A・Bで吸収できない場合の最終手段と考えるのが健全です。
⚠️ 方式選定は「機能比較」ではなく「業務の型が決まっているか」で決まる
多くの現場が、アプリや連携サービスの機能一覧を並べて比較しようとします。しかし実際の判断軸は「自社の在庫・受注業務の型が、標準的な形に収まっているか」の一点です。
型が標準的なら方式AかBで十分であり、スクラッチは過剰投資になります。逆に、受注ごとに人が判断する例外処理が多い業務にアプリを当てると、例外のたびに手作業が発生し、連携した意味がなくなります。先に業務を標準化するか、システムを業務に合わせるか——この判断こそが要件定義の中身です。
モール併売の在庫同期：売り越しはなぜ起きるか
楽天市場・Amazon・Yahoo!ショッピングとShopifyを併売している事業者にとって、在庫同期は事故が起きる場所が構造的に決まっています。
売り越しの発生メカニズム
売り越しは「システムが壊れたから」起きるのではありません。同期の間隔と、注文の集中度の掛け算で起きます。同期が5分間隔なら、その5分間に複数チャネルで同じ最終在庫が売れれば、確実に売り越します。セール時間帯やテレビ紹介直後など、注文が秒単位で集中する局面では、同期間隔がどれだけ短くても理論上ゼロにはできません。
対策①：安全在庫を持つ
実在庫よりも少ない数を各チャネルに出す。最も確実で、最も安価な対策です。機会損失と引き換えに事故を防ぎます。回転の速いSKUほど厚めに取ります。
対策②：チャネル別に在庫を配分する
共有在庫をやめ、SKUごとにチャネル別の枠を切る。売り越しは構造的に消えますが、片方で余り片方で欠品する非効率が生じます。
対策③：欠品時の運用を先に決める
技術で防ぎきれない以上、売り越しが起きた後の連絡・返金・代替提案のフローを事前に文書化しておくことが実質的な対策になります。ここを決めていない店舗ほど、事故が炎上に発展します。
⚠️ 「リアルタイム同期」という言葉を鵜呑みにしない
提案書に「リアルタイム在庫連携」と書かれていたら、必ず具体的な数値と条件を確認してください。確認すべきは3点です。①同期の実際の間隔は何秒／何分か。②1日あたり何件まで処理できるか（API側の呼び出し上限に達したときどうなるか）。③同期が失敗したとき、誰にどう通知され、誰が復旧するのか。
この3点に明確に答えられない提案は、「動くときは動く」という水準の設計だと考えて差し支えありません。
受注・出荷（WMS／3PL）連携の設計論点
在庫の次に事故が多いのが受注連携です。「注文は取れているのに出荷できない」という状態は、事業として最悪の形の停止です。設計時に必ず詰めるべき論点を挙げます。
連携する受注データの粒度
| 論点 | 決めておくべきこと |
|---|---|
| いつ連携するか | 決済完了時か、注文確定時か、出荷指示時か。与信・不正チェックの後にするのが原則。取り消し注文がWMSに流れると出荷事故になる。 |
| ギフト・熨斗・同梱物 | Shopify側でどう保持し、WMSにどの項目で渡すか。備考欄に自由記述で入れる設計は、必ず現場で読み落とされる。 |
| 分割出荷 | 複数SKUのうち一部が欠品したときの扱い。分割するのか、揃うまで止めるのか。顧客への通知タイミングも含めて決める。 |
| 配送日時指定 | 指定可能な範囲をどこが判定するか。Shopify側で表示する選択肢と、実際に配送業者が対応できる範囲がずれると苦情になる。 |
| キャンセル・返品 | 出荷前キャンセルと出荷後返品で、在庫の戻し方・返金処理・基幹への通知が異なる。ここを設計しない構築は必ず後で揉める。 |
| 追跡番号の戻し | WMSからShopifyへ書き戻し、顧客に自動通知するか。手動運用にすると、件数増加とともに必ず破綻する。 |
エラーが起きたときの設計
連携設計の質は、正常系ではなく異常系の設計に表れます。発注前に必ず確認してください。
✅ 異常系の確認項目
- リトライ／連携が失敗したとき、自動で再試行されるか。何回、何分間隔か
- 通知／失敗を誰がどこで知るか。メールか、Slackか、管理画面を見に行かないと分からないのか
- 重複防止／リトライで同じ受注が二重に基幹へ流れない仕組みがあるか
- 手動リカバリ／失敗した1件だけを人が再連携できるか。それとも全件やり直しか
- ログ／いつ何が失敗したかを後から追えるか。追える期間はどれくらいか
基幹連携で決めるべきマスタ設計
技術以前に、「どのシステムを正とするか」を先に決めるのがマスタ設計です。ここが曖昧なまま構築に入ると、必ず二重管理が発生します。
商品コードの体系
基幹の品番とShopifyのSKUをどう一致させるか。桁数・記号・全角半角の揺れが、そのまま連携エラーになります。変換ルールを持たせるのか、そもそも統一するのかを決めます。
バリエーションの持ち方
色・サイズを基幹側で別品番にしているか、属性で持っているか。ここがShopifyのバリアント構造と合わないケースは非常に多く、変換設計の要否を左右します。
価格の正はどちらか
基幹の売価をShopifyに配信するのか、Shopify側で自由に変えられるのか。セール価格の扱いを含めて決めないと、値引き施策のたびに整合が崩れます。
在庫の正はどこか
最重要の論点。基幹か、WMSか、連携基盤か。「正はここ、他は写し」という一文が書けない設計は、必ず在庫が合わなくなります。
この4点は、いずれも制作会社が単独で決められません。基幹システムの担当者、在庫を管理している現場、EC運営の責任者の三者が同じ場で合意すべき事項です。裏を返せば、この三者が揃わない打ち合わせでマスタ設計を進めているプロジェクトは、後から必ず手戻りが発生します。キックオフの段階で誰を呼ぶべきかは、この4点から逆算して決めてください。
連携が失敗する典型パターンと対処
| 失敗パターン | 何が起きているか | 対処 |
|---|---|---|
| 在庫の「正」が決まっていない | 基幹とWMSとShopifyがそれぞれ在庫を持ち、どれが正しいか誰も答えられない。 | 要件定義で1システムを正と宣言し、他は参照専用にする。技術ではなく合意の問題。 |
| 商品コードが揺れている | 同じ商品に複数の表記が存在し、連携時にマッチしない。 | 構築前にマスタの棚卸しとクレンジングを行う。これを制作会社任せにすると必ず追加費用になる。 |
| 例外業務が要件から漏れている | 「稀にある特殊対応」を伝えておらず、公開後に手作業として残る。 | 要件定義で年に数回の例外まで洗い出す。頻度が低くても、業務が止まる論点なら書く。 |
| API呼び出し上限を考慮していない | 商品数・注文数が増えると連携が詰まり、遅延が慢性化する。 | 提案時点で想定件数と上限、超過時の挙動を確認する。将来の件数で試算させる。 |
| テストが本番データで行われていない | 綺麗なテストデータでは通るが、実データの揺れで落ちる。 | 本番相当のデータ量・データ品質でテストすることを契約に含める。 |
| 返品・キャンセルが未設計 | 正常系だけ作られ、返品時に在庫が戻らない・二重返金が起きる。 | 要件定義で返品フローを独立した項目として立てる。後付けは高くつく。 |
| 運用担当者が決まっていない | 連携エラーの通知が飛んでも、誰も見ていない。 | 公開前に監視担当と一次対応手順を決める。システムではなく体制の設計。 |
| アプリの多重導入 | 在庫を触るアプリを複数入れ、互いに上書きし合う。 | 在庫に書き込むアプリは原則1つに絞る。導入前に書き込み範囲を確認する。 |
| 連携仕様書が存在しない | 作った人しか分からず、担当交代や制作会社変更で詰む。 | 納品物に連携仕様書（項目対応表・タイミング・異常系）を明記する。 |
発注前に自社でやるべき5ステップ
ここまでの論点を、発注側が実際に手を動かせる順番に並べ直します。この5つを終えてから相見積もりを取ると、各社の金額が同じ土俵に乗り、比較できる状態になります。逆に言えば、ここをやらずに見積もりを取ると、返ってくるのは「前提が違う3つの数字」であり、比較しても意味がありません。
現状のシステムを1枚の図に書き出す
いま社内で使っているシステム——基幹、販売管理、会計、WMS、モールの管理画面、Excelファイルまで含めて——を紙に並べ、その間を流れるデータに矢印を引きます。人がコピー＆ペーストや目視転記をしている箇所を赤で囲んでください。その赤い部分が、連携で解消したい候補のすべてです。ツールは不要で、手書きで十分です。
赤で囲んだ箇所に優先順位をつける
すべてを自動化しようとすると費用は跳ね上がります。判断軸は「頻度 × 1回あたりの所要時間 × ミスが起きたときの損害」です。毎日30分かかっていて、間違えると出荷事故になる作業は最優先。月に1回10分で、間違えても後から直せる作業は手作業のまま残すのが合理的です。「自動化しない」と決めた範囲を明示することが、費用のコントロールそのものになります。
在庫の「正」を1つ宣言する
基幹か、WMSか、連携基盤か。「在庫の正は◯◯である。他は写しであり、直接編集しない」という一文を社内で合意し、文書に書き残します。ここで場合分けが必要なら（例：予約商品だけ別管理など）、その例外も併せて明文化します。この一文が書けないまま構築に入ったプロジェクトは、公開後にほぼ確実に在庫の不整合で揉めます。
例外業務を洗い出す
年に数回しか発生しないが、発生すると業務が止まる処理を書き出します。特注品の受注、法人からの大口注文、同梱物の出し分け、特定顧客だけの価格、返品時の特別対応など。頻度が低いことは、要件から外してよい理由になりません。ここが漏れると、公開後に「システムでは対応できないので手作業で」という運用が積み上がり、連携した意味が薄れていきます。
想定件数を数字で出す
現在の商品SKU数、月間注文件数、ピーク時の日次注文件数、そして3年後の想定値。この5つの数字を提示できると、制作会社は方式選定と処理設計を具体的に検討できます。逆にこれがないと、各社は安全側に振った見積もりを出すか、逆に楽観的な前提で安く出して後から追加請求するかのどちらかになります。数字を渡すことは、値切ることよりも確実に費用を適正化します。
【独自視点】連携は「システムの話」ではなく「在庫の責任者を決める話」である
ここが、多くのプロジェクトが構造的に取り違えている点です。
連携要件の打ち合わせは、たいてい技術的な質問から始まります。「APIは使えますか」「同期間隔はどれくらいですか」「このアプリは対応していますか」。しかし本記事でここまで見てきた通り、失敗の原因はほとんどが技術的な限界ではなく、「誰が何に責任を持つか」が決まっていないことです。
要件定義で本当に決めるべき3つの問い
✅ この3つに即答できれば、連携設計は8割終わっている
- ① 在庫の正はどのシステムか。——「基幹です」と一言で答えられるか。「場合による」なら、その場合分けを書き出せているか
- ② 在庫が合わなかったとき、誰が調べて誰が直すか。——制作会社か、社内の担当者か。連絡経路と対応時間帯まで決まっているか
- ③ システム化しない例外業務は何か。——すべてを自動化しようとすると費用が跳ね上がります。「これは手作業で残す」と決めた範囲が明示されているか
この3つは、いずれも制作会社が決められる話ではありません。発注側が業務の持ち主として決めるべきことです。逆に言えば、ここを決めて提示できる会社は、どの制作会社に頼んでも見積もりが安定し、比較可能な数字が返ってきます。
「ECは戦術ではなく設計で決まる」
ボトルシップが一貫して掲げている考え方です。連携設計は、この思想が最も分かりやすく費用に現れる領域だと考えています。
バナーの見せ方も、商品ページの構成も、後からいくらでも改善できます。しかし「在庫の正をどこに置くか」という判断は、構築の初日に決まり、後から変えるには作り直しに近いコストがかかります。ここを制作会社任せにしたプロジェクトは、公開後に「思っていたのと違う」という形で必ず問題が表面化します。
実務的な第一歩は単純です。いま社内にあるシステムを紙に書き出し、それぞれの間を流れているデータに矢印を引く。手作業で人が転記している部分を赤で囲む。それだけで、自社の連携要件の輪郭はほぼ見えます。特別なツールも技術知識も必要ありません。必要なのは、業務を「作業の集まり」ではなく「データの流れ」として一度書き下ろす手間だけです。
あわせて読みたい
- Shopify制作の要件定義書の作り方｜連携要件を含めた12項目の固め方と、見積もりが変わる分岐点。
- BtoB・卸売のShopify構築完全ガイド｜取引先別価格・掛け払いと基幹連携の設計論点。
- 楽天・BASEからShopifyへ移行する完全ガイド｜移行時のデータ移管とマスタ整備の手順。
- ECモールとD2Cの複合戦略｜モール併売を前提としたチャネル設計の考え方。
よくある誤解
誤解①「Shopifyは在庫管理が弱い」
Shopify単体の在庫機能は必要十分です。問題は複数チャネル・複数倉庫を跨いだときの整合であり、これはどのカートでも同じ構造の課題です。カートの優劣ではなく設計の問題として扱ってください。
誤解②「アプリを入れれば連携できる」
アプリは自社の業務が標準的な型に収まっている場合に限って機能します。例外処理が多い業務にアプリを当てると、例外のたびに手作業が発生します。
誤解③「スクラッチのほうが確実」
自由度は最も高いですが、保守費用と属人化のリスクを引き受けることになります。作った会社しか触れない連携は、担当者の退職や契約終了で一気に負債化します。
誤解④「売り越しはゼロにできる」
複数チャネルで同一在庫を売る限り、理論上ゼロにはできません。安全在庫でリスクを下げ、起きた後の運用を決めるのが現実的な設計です。
誤解⑤「連携は公開後に足せばいい」
商品マスタの構造と受注データの粒度は、連携先の仕様に依存して初期に固定されます。後付けは登録のやり直しを伴うことが多く、割高になります。
誤解⑥「仕様書はなくても動けばいい」
動いている間は問題になりません。問題が起きるのは、担当が代わったときと、制作会社を変えたときです。連携仕様書は納品物として必ず要求してください。
よくある質問（FAQ）
Q1. 在庫連携はどれくらいの間隔があれば実用に足りますか？
業種と回転率によります。判断材料は「最終在庫が複数チャネルで同時に売れる確率」で、1点物や在庫が薄い商材ほど短い間隔が必要になり、常時潤沢に在庫を持つ商材なら間隔が長くても実害は出にくくなります。実務的には、まず自社の欠品直前SKUの比率を確認し、そこから逆算するのが現実的です。なお、どれだけ間隔を短くしても売り越しは理論上ゼロにならないため、安全在庫の設定と、事故時の運用フローを併せて設計してください。
Q2. 基幹システムが古く、APIがありません。連携は諦めるべきですか？
諦める必要はありませんが、選択肢は限られます。APIがない場合、実務ではCSVファイルの受け渡し（指定フォルダへの出力・取り込み）で連携するのが一般的です。リアルタイム性は落ちますが、日次バッチで足りる業務であれば十分に実用的です。判断のポイントは「その業務にリアルタイム性が本当に必要か」で、受注連携は数分〜数十分の遅延が許容できるケースが多い一方、在庫は遅延がそのまま売り越しリスクになります。在庫だけ別方式にするという設計も有効です。
Q3. 連携部分の見積もりが会社によって大きく違うのはなぜですか？
ほぼ確実に、各社が異なる前提を置いているからです。同期間隔、対象データの範囲、異常系の作り込み、テストの深さ、仕様書の有無——これらのどれか一つが違うだけで金額は倍近く動きます。比較可能にする方法は一つで、発注側が前提条件を書いた紙を用意し、全社に同じものを渡すことです。最低限、対象システム名、同期対象のデータ種別、必要な同期間隔、想定件数、異常時の通知要否を明記してください。詳細は要件定義書の記事で解説しています。
Q4. 在庫を触るアプリを複数入れてはいけないのですか？
原則として、在庫数に「書き込む」アプリは1つに絞ることを推奨します。複数のアプリが同じ在庫を更新すると、互いの更新を上書きし合い、原因の特定が極めて困難な不整合が発生します。読み取り専用（在庫を参照してレポートを出す等）のアプリは併用しても問題ありません。導入前に、そのアプリが在庫に書き込むのか読むだけなのかを必ず確認してください。既に複数入っている場合は、棚卸しして書き込み役を一本化するところから着手します。
Q5. 連携の保守費用は、どの程度を見込むべきですか？
金額は構成によって大きく変わるため一概には言えませんが、「連携は作って終わりではなく、継続的に費用が発生するもの」と予算計画に織り込むことが重要です。理由は3つあります。①ShopifyのAPIやアプリの仕様は更新され、対応が必要になる。②モールの仕様変更に追随する必要がある。③商品数や注文数の増加に伴い、処理の見直しが必要になる。見積もり取得時には初期費用だけでなく、月額の保守範囲と、範囲外作業の単価を必ず確認してください。
まとめ
この記事の要点
- Shopify構築の難所は「作ること」ではなく「つなぐこと」。テーマは後から直せるが、在庫の持ち方・受注の流れ方・マスタの持ち主を後から変えるのは作り直しに近い。
- 連携は6種類に分解できる——商品マスタ／在庫／受注／出荷実績／顧客／会計。このうちプロジェクトを壊すのはほぼ「在庫」と「受注」の2つ。
- 在庫連携の方式は3つ——A:アプリ、B:連携サービス／iPaaS、C:Admin APIスクラッチ。選定軸は機能比較ではなく「自社の業務の型が標準的な形に収まっているか」。
- 売り越しは理論上ゼロにできない。同期間隔×注文集中度で発生するため、安全在庫の設定と、起きた後の連絡・返金・代替提案フローを事前に文書化しておく。
- 設計の質は異常系に表れる。リトライ・通知・重複防止・手動リカバリ・ログの5点を、提案時点で必ず確認する。
- 要件定義で本当に決めるべきは3つの問い——①在庫の正はどのシステムか、②合わなかったとき誰が直すか、③システム化しない例外業務は何か。いずれも制作会社ではなく発注側が決める。
- 連携仕様書を納品物に含める。問題が起きるのは担当交代時と制作会社変更時。仕様書がない連携は、その時点で負債になる。
100文字要約：Shopify構築が炎上する原因は連携。在庫連携はアプリ／連携基盤／スクラッチの3方式から業務の型で選ぶ。売り越しは理論上ゼロにできず、安全在庫と事故時運用の設計が要る。
