「みんなでまとめ買いして送料を安くしたい」「同僚と割り勘で買いたい」。共同購入や割り勘は、EC事業者から見れば魅力的な機能です。まとめ買いは客単価を上げ、招待の連鎖はネットワーク効果を生みます。しかしShopifyでこれを作ろうとすると、「1注文＝1決済」というプラットフォームの構造と、メンバー間の金銭授受をシステムが仲介することへの法規制という2つの壁に同時にぶつかります。本記事では、この2つの制約から導かれる設計の解と、要件次第で開発規模が数倍変わる分岐点を整理します。共同購入を検討しているEC事業者と、その見積もりを作る立場の技術者に向けた内容です。

前提となる2つの制約

まず、動かせないものを確認します。

Shopifyは1つの注文を複数人で分担して決済することができません。これは設定やアプリで回避する話ではなく、注文と決済が1対1で紐づく構造そのものです。チェックアウトの深いカスタマイズは上位プラン限定の領域であり、そこに手を入れられたとしても、1注文を複数の支払い者に割ることはできません。

メンバー間の金銭授受をシステムが仲介すると、資金移動業の登録という論点が出ます。誰かが立て替えて、後からシステムが他のメンバーから回収して立替者に渡す。この「預かって送る」構造が、日本の法制度では為替取引にあたり得ます。技術的に作れるかどうか以前の問題です。

この2つを並べると、答えは自ずと1つに収束します。各自が自分の分を直接Shopifyで決済する設計にすること自体が、技術面と法務面の両方の解になるのです。制約が2方向から同じ設計を指している以上、ここは迷う場所ではありません。

現実的な3つの方式

その前提で、実現方式は3つに整理できます。

個別注文を束ねる方式。各メンバーが自分のアカウントで普通に注文して決済し、システム側がグループIDで注文どうしを紐づけます。配送先は代表者の住所に揃え、倉庫で同梱して発送する。割り勘は「各自が自分の分を払う」ことで自然に成立し、システムがお金を預かる場面がありません。開発規模は中程度で、多くのケースでこれが第一候補になります。

共有カートを分割する方式。全員で１つのカートに商品を入れていき、締切時にメンバーごとの下書き注文へ分割して、それぞれに決済リンクを送る。利用者体験としては理想形に近いのですが、開発は一段重くなります。将来の拡張形として位置づけるのが現実的です。

代表者がまとめて決済する方式。幹事が全員分をまとめて買う、いわば最安構成です。ただし本来の意味での割り勘は満たせません。

「代表者決済」は結局なにを作るのか

この方式は説明が難しく、実際「それって何を開発するの？」と聞かれることが多い部分です。極端に言えば、開発ゼロでも運用できてしまいます。幹事がチャットで「何が欲しい？」と聞いて、自分のカートに入れて、自分の住所に届けて配る。これだけなら標準機能のままです。

では何を作るのかというと、「口頭やチャットで集める」部分をサイト上の体験に置き換えるUIです。具体的には3点に集約されます。

欲しいものを集める仕組み。幹事がグループを作って招待リンクを共有し、メンバーが自分でサイトを見ながら「これが欲しい」をグループのリストに登録する画面です。ストアのドメイン配下で動くカスタムページとして作ります。これがないと、メンバーは商品URLをチャットに貼り、幹事が手動でカートに入れる、という原始的な運用に戻ります。

リストを幹事のカートへ一括反映する機能。数点なら手動でも回りますが、10人分・30点となると現実的ではありません。

誰の分がいくらかの内訳表示。注文にメンバーごとの内訳を紐づけて保持し、注文後に幹事もメンバーも確認できるようにします。精算そのものはサービスの外（現金や個人間送金）で行われますが、精算の根拠になる明細がないと幹事が電卓を叩くことになり、実用に耐えません。ここがこの方式の価値の核だと考えています。

逆に、束ねる方式との決定的な違いは、決済とその後の処理に一切手を入れない点です。チェックアウトは幹事1人の通常注文なので、配送先の固定、グループ単位の送料計算、注文の束ね、同梱の出荷指示、一部キャンセル時の整合といった重い開発が全部不要になります。だから見積もりの桁が変わります。

提案の組み立てとしては、「代表者決済は開発なし（純粋な運用）でも始められます。ただし幹事の負担が大きいので、この3点のUIを付けるのがこの金額です」という2段構えで見せると、予算を絞りたいクライアントにとっての逃げ道が残ります。

見積もりのブレ幅を決めるのは「割り勘」の解釈

当社の経験上、この機能で見積もりを最も大きく揺らすのは技術ではなく言葉の解釈です。

「割り勘」が「各自が自分の分を払う」を意味するなら、束ねる方式で済みます。しかし「1つの商品の代金を複数人で分割する（プレゼントを何人かで割る）」まで含むなら、共有カート方式で金額の分割が必要になり、難易度が跳ね上がります。同じ「割り勘」という単語が、開発規模を数倍変える分岐点になっているわけです。

ここは提案前に必ず確認します。後者だった場合は、フェーズを分けて切り出す提案が有効です。

見落とされがちな成立条件

もうひとつ、技術検討の場では出てきにくいのに、成立を左右する条件があります。倉庫で同梱のオペレーションが回るかです。

束ねる方式も共有カート方式も、「複数の注文を1つの荷物にまとめて送る」ことで送料メリットを出しています。ここが物流側でNoなら、機能の価値そのものが崩れます。システムを作り込む前に、物流の担当者へ確認すべき事項です。

同様に、一部のメンバーだけがキャンセルしたときにグループ全体の送料や同梱指示をどう整合させるかも、束ねる方式を選んだ瞬間に発生する論点です。ここを詰めずに見積もると、後工程で必ず膨らみます。

上位プランでなくても成立する

最後に、よくある誤解に触れておきます。「共同購入はチェックアウトをいじるから上位プランが必要では」という質問をよく受けますが、ここで挙げた方式はいずれもチェックアウトに手を入れません。

そもそも各自が自分の分を通常のチェックアウトで払う設計にしている以上、チェックアウト拡張の出番がないのです。送料のディスカウントも、ディスカウントコードの自動適用に寄せれば全プランで動きます。制約から出発した設計が、結果的にプランへの依存も外してくれる、という構図です。

まとめ

Shopifyでの共同購入は、「1注文＝1決済」の構造と資金移動業の論点という2つの制約が、どちらも「各自が自分の分を直接決済する」という同じ設計を指し示します。そこから、個別注文を束ねる方式・共有カートを分割する方式・代表者がまとめて決済する方式の3つが導かれ、多くのケースでは束ねる方式が第一候補になります。見積もりを左右するのは技術ではなく「割り勘」という言葉の解釈と、倉庫で同梱が回るかという物流側の条件です。プラットフォームの制約を回避しようとするのではなく、制約が示す方向に設計を寄せる。それがこの種の機能をもっとも確実に動かす方法だと考えています。