産地直送、複数工房、複数倉庫。ひとつの注文の中に「発送元が異なる商品」が混ざるECは珍しくありません。Shopifyでこれを実現しようとすると、多くの案件でまず検討されるのがロケーション機能の活用です。当社でも第一候補として提案しますが、この方式には明確な適用限界があり、それを踏まえずに設計すると後戻りが発生します。本記事は、マルチベンダー的な構成をShopifyで検討しているEC事業者と開発者に向けて、方式選択の判断基準を整理します。
配送は二つのレイヤーに分けて考える
最初にやるべきは、問題を分解することです。配送の話は、顧客に見せる送料の計算と、実際の出荷処理（フルフィルメント）という、性質のまったく異なる二つのレイヤーが混ざりがちです。この二つを一緒に議論すると、必ず話がこんがらがります。
送料計算はチェックアウト時に顧客へいくら請求するかという商売の話であり、出荷処理は注文をどう発送元ごとに分けて処理するかというシステム構造の話です。それぞれ独立に方式を決められます。
出荷処理 ― ロケーション分割方式が強力な理由
出荷側の推奨は「発送元イコールShopifyのロケーション」とする方式です。発送元ごとにロケーションを作り、各商品の在庫を担当ロケーションに割り当てておくと、混合注文が入った際にShopifyがロケーション単位でフルフィルメントオーダーを自動分割してくれます。
この方式の本質的な価値は、「どの商品がどの発送元か」という判定をShopifyのデータモデルが答えてくれる点にあります。タグや独自DBで発送元を管理し、自前で振り分けロジックを書く必要がなくなります。さらに、部分発送、追跡番号の登録、発送通知メールの送信がすべてShopifyの標準機能に乗ります。「混合注文では発送元ごとに複数回の発送通知メールが飛ぶ」といった仕様が、追加開発なしで標準挙動として実現されるのは大きな利点です。
その方式が破綻する二つの条件
一方で、この方式には無視できない制約があります。
ひとつはロケーション数の上限です。Shopifyのプランによってロケーション数には上限があり、下位プランでは十数拠点程度に収まります。発送元が数社のうちは問題になりませんが、「今後は数十社まで増やしたい」という事業計画があるなら、この方式は最初から採用できません。当社では要件定義の段階で、発送元の将来的な件数を必ず確認するようにしています。ここを聞かずに設計に入ると、実装後半で土台からやり直すことになります。
もうひとつは、一つのバリアントを複数の発送元が扱うケースです。ロケーション分割方式は「1バリアント＝1発送元」を暗黙の前提としています。同じ商品を複数の生産者が出荷するような運用が将来あり得るなら、この前提は崩れます。
この二つの条件のいずれかに該当するなら、発送元の管理は独自のデータ構造で持ち、フルフィルメントも自前で制御する設計に切り替える必要があります。
送料計算 ― 標準機能で「割り切る」判断
送料側は、Shopifyの標準機能でどこまで妥協できるかの勝負になります。よくある要件は「基本送料＋クール便加算＋離島加算＋サイズ別」といったものですが、Shopifyの標準配送設定は都道府県ゾーンや重量・金額条件による分岐はできても、「商品に特定の属性があれば一定額を加算する」という条件加算は素直にはできません。
実務的な回避策が、配送プロファイルの分割です。たとえば常温商品とクール便商品を別のプロファイルに分け、それぞれに料金表を持たせます。両方が混在するカートでは、Shopifyが両プロファイルの送料を合算するため、結果として「基本送料＋クール加算」に近い挙動になります。カスタム開発なしで条件加算を近似できる点で、費用対効果は高い方式です。
これで足りない場合、たとえば郵便番号単位の離島判定や任意の加算ロジックが必要なら、Carrier Service APIによる独自送料計算に進むことになります。ただしこれは上位プランが前提になる上、送料計算エンドポイントの実装が必要で、工数もランニングコストも跳ね上がります。当社では多くの場合、「離島は都道府県単位で丸める」といった割り切りをクライアントと合意する方向を先に提案します。要件の精緻さと、それを実現するためのプラン変更・開発費が釣り合っているかを、事業者と一緒に判断するべき論点だからです。
混合注文の送料は「実費」ではなく「価格」
設計の初期に必ず合意しておきたいのが、混合注文の送料をどう扱うかです。発送元が複数あれば物理的には箱が複数出るので、実費としては送料も複数発生します。しかし顧客体験としては、送料が発送元の数だけ加算されるカートは受け入れられにくい。
ここは「送料は実費の転嫁ではなく販売価格の一部である」と整理し、差額は事業者が吸収する、という考え方を取るのが一般的です。クール便加算についても「注文にクール品が一つでもあれば一回」なのか「クール発送元ごと」なのかを明示的に決めます。技術的な選択ではなく事業判断なので、開発側が勝手に決めず、必ず事業者の合意を取ります。
まとめ
複数発送元のECをShopifyで組む場合、当社ではまず配送を送料計算と出荷処理に分解し、出荷側はロケーション分割方式を第一候補としつつ、発送元の将来件数と「1商品を複数発送元が扱うか」を要件定義で必ず確認します。この二点で引っかかれば独自実装に切り替えます。送料側は配送プロファイルの合算で割り切り、精緻化はフェーズを分ける。プラットフォームの標準機能に最大限乗せた上で、どこを割り切るかを事業者と合意する。それが、コストと保守性の両方で最も収まりの良い構成になります。