この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、既存ストアの販促設計を見直したい運営担当者
「セールをやると売れるけれど、やめると止まる」。Shopifyストアの運営がある程度続いた頃に、多くの事業者がこの壁にぶつかります。
原因は施策の量ではなく、割引の設計にあります。Shopifyの割引機能は「コードを入れて使うもの」と「条件を満たすと勝手に効くもの」の2系統に分かれていて、この2つは目的も、置く場所も、成果の測り方もまったく違います。ここを分けずに運用すると、割引が常設化して定価が意味を失い、粗利だけが削れていきます。
この記事では、制作会社としてShopifyストアを組み、かつ自社でもストアを運営している立場から、Shopifyの割引・クーポン・自動割引の設定をどう設計するかを扱います。「クーポンコードの作り方」の手順書ではありません。どの割引をどこに置くか、併用を許すか、いつ止めるかという判断の話です。
Shopifyの割引は2系統ある（クーポンと自動割引）
コード入力型と自動適用型
Shopify管理画面の「ディスカウント」から作れる割引は、大きく次の2つに分かれます。
| コード入力型（クーポン） | 自動適用型（自動割引） | |
|---|---|---|
| 効き方 | 顧客がカートでコードを入力して初めて効く | 条件を満たした時点で自動的に効く |
| 顧客の認知 | コードを知っている人だけ使える | 全員が対象になる |
| 主な用途 | メルマガ・LINE・広告・インフルエンサー・お詫び | まとめ買い促進、送料無料、期間セール |
| 成果の追跡 | コード単位で使用回数・売上が見られる | どの条件が効いたか個別には追いにくい |
| 顧客体験 | コード忘れ・入力ミスで離脱が起きる | 何もしなくても効くので離脱しない |
| 定価への影響 | コードを知らない人は定価で買う | 全員が割引価格を「通常価格」と認識する |
一番大事な違いは最後の行です。コード入力型は定価を守れる。自動適用型は定価を溶かす。 この非対称性が、割引設計のほぼすべてを決めます。
割引の種類（何を安くするか）
系統とは別の軸として、「何をいくら安くするか」の種類があります。
- 金額割引 — 商品または注文から一定額を引く（500円引き、1,000円引き）
- 率割引 — 商品または注文から一定割合を引く（10%OFF、20%OFF）
- 送料無料 — 配送料を無料にする。国・地域や送料上限で絞れる
- X個買うとY個無料（Buy X Get Y） — まとめ買い・セット販売の促進
この4種類が「コード入力型」「自動適用型」のどちらでも作れる、という2×4のマトリクスで考えると整理しやすくなります。ただし後述するとおり、組み合わせによっては併用できないので、そこが設計の勘所になります。
コード入力型に向くもの
- 特定の顧客層だけに配る率割引
- 初回購入・再購入の金額割引
- インフルエンサー・アフィリエイト経由
- クレーム対応・お詫びの個別発行
自動適用型に向くもの
- ○円以上で送料無料
- 2点以上でまとめ買い割引
- 期間限定セール（全員対象）
- セット商品のBuy X Get Y
自動適用型に向くのは「全員に同じ条件を提示してよいもの」だけです。逆に言えば、特定の誰かに向けた割引を自動適用にすると、その特定性が消えて価値がなくなります。
使い分けの判断軸は「誰に届けたいか」
クーポン（コード入力型）を選ぶべきケース
コードが要るというハードルは、デメリットではなくフィルターです。このフィルターが欲しいときにコード入力型を選びます。
1. 割引の到達先を絞りたいとき
メルマガ登録者だけ、LINE友だちだけ、初回購入者だけ。「登録してくれた人にだけ渡す」という構造があるからこそ、リスト獲得のインセンティブが成立します。誰でも使える割引は、リストを増やす力を持ちません。
2. 流入元ごとに成果を測りたいとき
インフルエンサーごと、媒体ごとにコードを分ければ、どの経路が売上を作ったかがコード単位で見えます。クリック計測が効かない口頭紹介やオフライン配布でも追跡できるのが、コード方式の強みです。
3. 個別対応が必要なとき
配送遅延のお詫び、破損交換のフォロー。1回だけ使える1人限定のコードを発行できるので、対応の記録としても機能します。
4. 定価を崩したくないとき
これが一番見落とされます。コードを知らない顧客は定価で買います。逆に自動適用の20%OFFを常設すると、定価は「存在するけれど誰も払わない数字」になります。
自動割引（自動適用型）を選ぶべきケース
自動適用型は「顧客に何かを覚えさせない」ことに価値があります。
1. 客単価を上げたいとき
「3,000円以上で送料無料」「2点購入で10%OFF」のような条件は、カートの中身を見て顧客が自分で行動を変えます。コード入力を挟むと、この場面での判断が止まります。
2. コード入力の離脱を避けたいとき
コード入力欄はカートの中で最も危険な場所のひとつです。「クーポンがあったはず」と顧客がタブを離れ、メールを探し、戻ってこない。この離脱はGA4のイベントでは原因が見えにくく、機会損失として静かに積み上がります。
3. 全員対象のセールをやるとき
期間限定セールで全員に同じ割引を適用するなら、コードを配る意味はありません。自動適用のほうが伝達コストがゼロで、離脱も起きません。
判断を1本の線にする
順番が大事です。ステップ4を最後ではなく設計時に決めておくことで、割引の常設化を構造的に防げます。
このステップ1で迷うなら、割引の設計に入る前に一段戻ったほうが早いです。「客単価も新規も在庫も全部」という状態は、目的が決まっていないのと同じで、どの型を選んでも中途半端になります。目的が1つに絞れていれば、対象も型も終了条件も自動的に決まっていきます。
併用の可否が設計を縛る
併用ルールの基本
Shopifyの割引には「他の割引と組み合わせられるか」の設定があります。ここを理解していないと、キャンペーン中に「クーポンが使えない」という問い合わせが噴出します。
Shopifyの併用（combinations）は、割引をおおむね次の3クラスに分けて管理します。
| クラス | 対象 | 例 |
|---|---|---|
| 商品割引 | 特定の商品・コレクション | セール対象商品10%OFF |
| 注文割引 | 注文全体 | 5,000円以上で500円引き |
| 送料割引 | 配送料 | 3,000円以上で送料無料 |
併用は「異なるクラス同士」で許可できます。 商品割引と送料割引を同時に効かせることはできますが、注文割引を2つ重ねることは基本的にできません。そして重要なのは、併用は割引を作るとき両方に許可を入れておく必要があることです。片方が「併用しない」設定だと、もう片方が無視されます。
現場で起きるつまずき
制作・運用の場面で頻出するパターンを挙げます。
「送料無料が効かない」
多いのが、注文割引で単価が下がった結果、送料無料の下限を割ってしまうケースです。「3,000円以上で送料無料」と「500円引きクーポン」を併用可にしていると、3,200円のカートに500円引きが乗って2,700円になり、送料が復活します。顧客からすると「割引を使ったら送料を取られた」という体験になります。
回避策は2つあります。送料無料の判定を割引前の金額基準で設計できるかを確認するか、あるいは送料無料と注文割引を併用不可にして、どちらか一方だけが効くと明示することです。後者のほうが説明が簡単で、問い合わせも減ります。
「セール品にクーポンが使えると思われた」
セール中に「セール品はクーポン対象外」とするなら、コード側とセール側の両方で併用設定を切り、さらにフロント側に文言を出す必要があります。カートでエラーが出て初めて分かる設計は、確実に問い合わせを生みます。
「複数のコードを入れたい」
Shopifyのカートは、コードを複数入力できる場合とできない場合があります。プランやチェックアウトの仕様に依存するため、複数コード運用を前提にしたキャンペーンは組まないのが安全です。「コードは1回の注文で1つ」を前提に設計しておけば、仕様が変わっても崩れません。
「クーポンが期待した商品に効かない」
率割引を「対象コレクション」で作ったあと、新商品をそのコレクションに入れ忘れるパターンです。商品を個別指定した割引でも同じことが起きます。割引を作った日と、商品が増える日はずれるので、対象指定は必ずコレクション単位にして、コレクション側を自動ルールで運用するのが安全です。この構造は後述の「制作段階で決めておくこと」に直結します。
併用の設計はキャンペーン開始前に表にする
割引が3つ以上並走する時期は、必ず併用可否のマトリクスを作ってから管理画面に入ります。
| 期間セール10%（商品） | 500円引き（注文） | 送料無料（送料） | |
|---|---|---|---|
| 期間セール10%（商品） | — | 可 | 可 |
| 500円引き（注文） | 可 | — | 不可にする |
| 送料無料（送料） | 可 | 不可にする | — |
この表を先に作ると、「送料無料の下限割れ」のような事故が設定前に潰せます。表を作らずに管理画面で1つずつ設定していくと、組み合わせの検証が漏れます。
さらに、表を作ったあとにテスト注文で実際に確かめる工程を入れます。確認するのは3点です。①併用可にした組み合わせが本当に両方効くか、②併用不可にした組み合わせでどちらが優先されるか、③割引後の金額で送料判定がどう動くか。管理画面の設定値は「意図」であって、チェックアウトの挙動そのものではありません。金額が絡む設定は、必ず1回通してから公開します。
まとめ買い・送料無料条件の組み立て方
送料無料の下限は「送料が消える金額」ではない
送料無料ラインは、送料をタダにするための設定ではなく、客単価をどこに引き上げたいかの意思表示です。決め方には順序があります。
- 現在の平均注文金額（AOV）を出す
- 実際にかかっている配送原価を1件あたりで出す
- 「AOVより少し上」で、かつ上乗せ分の粗利が配送原価を超える金額を下限にする
AOVより下に設定すると、放っておいても達成される注文まで送料を負担することになり、粗利が削れるだけで行動は変わりません。逆に大きく上に設定すると誰も届かず、単に「送料が高い店」になります。
3番目の条件は言葉より計算で見たほうが早いです。AOVが3,000円、粗利率が40%、1件あたりの配送原価が600円のストアで、下限を3,500円に置いたとします。顧客が下限に届くために追加する500円が生む粗利は200円で、負担する配送原価600円に届きません。この場合、下限を上げる（4,500円なら追加1,500円×40%＝600円で釣り合う）か、粗利率の高い商品を「あと少し」の位置に置くか、送料無料そのものを諦めて別の訴求にするかの三択になります。送料無料ラインは感覚で決めると、ほぼ必ず低すぎます。
商品単価が低いストアでは、送料無料ラインに1点では届かないことが多く、この場合「まとめ買いを前提とした見せ方」がセットで必要になります。カート内に「あと○円で送料無料」を出すのは、Shopifyの標準機能では持っていない表現なので、テーマ改修またはアプリの領域です。
まとめ買い割引の型
まとめ買いには2つの型があり、向く商材が違います。
数量しきい値型（2点で10%OFF）
- 同一商品のリピート消費財に向く
- 顧客が理解しやすい
- Shopify標準の自動割引で組める
セット型（Buy X Get Y）
- 関連商品の抱き合わせに向く
- 在庫を動かす力が強い
- 組み合わせ条件が複雑になりやすい
数量しきい値型は説明が1行で済むぶん、運用の負担が軽いのが利点です。セット型は在庫消化に効きますが、対象商品が増えるたびに設定を見直す必要があるため、管理画面を触る人の作業量が確実に増えます。ここは機能の優劣ではなく、運用体制で選ぶところです。
Buy X Get Yを組むときに注意したいのが、Yの原価がそのまま割引原資になる点です。率割引なら「10%OFF＝原資は売価の10%」と見積もれますが、Buy X Get Yは「Xの売上に対してYの原価分を渡す」構造なので、XとYの単価差でコストが大きく振れます。単価の高い商品をYに置くと、実質割引率が想定を超えることがあります。組む前に「この条件の実質割引率は何%か」を1回計算しておくと、後から驚かずに済みます。
どこまでアプリで足りて、どこからテーマ改修か
標準機能の範囲
Shopifyの標準ディスカウント機能でできることは、実は広いです。金額・率・送料無料・Buy X Get Y、対象商品やコレクションの絞り込み、使用回数の上限、期間の指定、顧客セグメントの指定。販促の骨格は、これでかなり組めます。
足りなくなるのは、次のような要件が出てきたときです。
| 要件 | どこで解決するか |
|---|---|
| 商品ページに「2点で10%OFF」を表示したい | テーマ改修（またはアプリのウィジェット） |
| カートに「あと○円で送料無料」を出したい | テーマ改修 |
| 会員ランクごとに常時価格を変えたい | アプリ（B2B/卸機能または会員価格系） |
| 数量に応じた段階価格表を商品ページに出したい | アプリ、または段階価格ロジックの実装 |
| クーポンをURLパラメータで自動適用したい | 標準（ディスカウントURL）で足りることが多い |
| 割引の使用状況を独自の切り口で集計したい | 管理画面のレポート＋外部集計 |
見ていくと、「割引を効かせる」部分は標準で足り、「割引を伝える」部分でテーマ改修が必要になるという線引きが見えてきます。ここが判断の中心です。
割引が効いていても、顧客が気づかなければ行動は変わりません。だから多くのストアで実際に必要になるのは、割引ロジックを増やすアプリではなく、割引条件を商品ページとカートに出す表示の実装です。
アプリを入れる前に見る4点
割引・販促系のアプリはShopifyアプリストアに多数あります。無料枠のあるものから月額課金のものまで幅がありますが、料金は改定されるので最新の金額は各アプリのページで確認してください。ここでは金額以外に見るべき箇所を挙げます。
1. 最終更新日
長期間更新が止まっているアプリは避けます。Shopifyはチェックアウトやテーマの仕様を継続的に変えていくので、追従が止まったアプリは静かに壊れます。特にチェックアウトに関わるものは、Checkout Extensibilityのような仕様移行に取り残されるリスクが直接あります。
2. 日本語・多通貨への対応
管理画面が英語だけなら、日々触る運用担当の負担になります。顧客に見える文言が英語のまま出るアプリもあり、この場合は文言の差し替え可否を導入前に確認します。
3. テーマへの入り方
アプリブロックとして入るのか、テーマのコードを直接書き換えるのか。後者は解約時に残骸が残ります。 テーマファイルにアプリのスニペットが埋め込まれていると、解約後も呼び出しコードが残り、コンソールエラーや表示崩れの原因になります。ここはDawnベースの改修方針と同じ考え方です。
4. 表示速度への影響
割引表示系のアプリは、商品ページとカートに追加のスクリプトを読み込みます。1つならほぼ気にならなくても、いくつも積み上がると体感で遅くなり、Core Web Vitalsに出ます。導入前後でPageSpeed Insightsを測っておくと、後から犯人を特定できます。
自前実装を選ぶ判断
制作会社として、また自社でもDawnベースのストアを運営している立場から言うと、表示だけの要件なら自前実装のほうが後々楽になるケースが少なくありません。
- 商品ページの数量割引表示（「2点以上で10%OFF」のような静的な訴求）
- カートの「あと○円で送料無料」バー
- セール価格の見せ方（定価の取り消し線、割引率バッジ）
これらは割引ロジックそのものをアプリに持たせる必要がなく、Shopify標準の自動割引を裏で効かせつつ、表示だけテーマ側で書くという構成が取れます。月額が積み上がらず、テーマ内で完結するので解約時の残骸もありません。
ただし自前実装には、割引条件を変えたときに表示側も直す必要があるという宿題が残ります。「2点で10%OFF」を「3点で15%OFF」に変えるとき、管理画面の割引設定とテーマの文言の2か所を直すことになる。ここを忘れると、表示と実際の割引が食い違う最悪の状態になります。回避するには、しきい値と割引率をテーマの設定項目（セクション設定やメタフィールド）として外に出し、コードを触らずに管理画面から変えられる形にしておくことです。実装時の一手間で、運用中の事故がなくなります。
一方で、次のような要件は自前実装に向きません。
- 会員ランクごとの動的な価格制御（会員管理そのものが要る）
- 在庫や購買履歴に応じたリアルタイムな割引判定
- チェックアウト画面そのものの改変（プランと仕様の制約が強い）
判断の線は「状態を持つかどうか」です。顧客ごと・履歴ごとに変わるものはアプリまたは外部の仕組み、静的な表示はテーマ。この線で切ると迷いません。
アプリなしで機能を実装する具体例としては、ウィッシュリストの実装方針の記事も同じ考え方で書いています。
割引を乱発すると起きること
「定価で買われなくなる」の中身
ここが、この記事で一番伝えたい部分です。割引の失敗は、粗利率の悪化として現れる前に、顧客の待ち行動として現れます。
起きる順序はだいたい決まっています。
ステップ2で「セールをやめると売上が落ちる」という現象が出ますが、これはセールに効果がある証拠ではなく、需要が後ろに繰り延べられている証拠です。セール期間に集まった売上の一部は、本来なら定価で買われていた分の前借りです。この区別をしないまま「セールは効く」と結論を出すと、ステップ4まで一直線に進みます。
厄介なのは、ステップ3が管理画面の数字に「落ち込み」として出ないことです。セール期間の売上が伸びているので、月次で見れば横ばいか微増に見える。減っているのは定価期間のCVRという、意識して切り出さないと目に入らない数字だけです。気づいたときには、20%OFFが「普通の価格」になっている。 ここから戻すには、一度売上を落とす覚悟で定価期間を作るしかなく、コストは常設化した期間の長さに比例して増えていきます。
乱発を防ぐ3つの仕組み
1. 割引の総枠を先に決める
「年間の売上に対して割引原資は何%まで」を決めます。この枠を超える施策は、既存施策を止めてから打つ。枠がないと、施策は足し算だけで増えていきます。
2. 終了条件を設定時に書く
期間、在庫数、使用回数の上限。Shopifyの割引には使用回数の上限を設定できるので、「使用回数100回まで」を入れておけば、止め忘れが物理的に起きません。日付だけの管理は、担当者が変わると必ず残ります。
3. 定価期間を意図的に作る
年間カレンダーに「割引を出さない期間」を先に置きます。この期間の売上とCVRが、そのストアの素の実力です。素の実力を測れないストアは、割引をやめる判断ができません。
効果を測るときに見る指標
| 指標 | 何が分かるか | 注意点 |
|---|---|---|
| 割引適用注文の比率 | 定価で買われている割合 | 高止まりしていたら常設化を疑う |
| 平均割引率 | 原資の実消費 | 併用が効いていると想定より高くなる |
| 定価期間のCVR | 素の実力 | 定価期間を作らないと測れない |
| 割引注文のリピート率 | 顧客の質 | 割引でしか買わない層が育っていないか |
一番下の行が重要です。割引で獲得した顧客が定価でリピートしているなら投資は成功、割引時にしか戻ってこないなら獲得しているのは顧客ではなく取引です。この判別には、割引の有無で顧客をセグメント分けした分析が必要になります。
計測の土台がないと、この判断はできません。GA4と補助ツールの組み合わせ方は別の記事で扱っています。
制作段階で決めておくこと
割引設計はサイト構築の要件である
割引を「公開後に管理画面で設定するもの」と考えていると、構築時に必要な仕込みが漏れます。制作段階で決めておくべきものを挙げます。
- 割引条件を表示する場所 — 商品ページ、カート、ヘッダーの告知バー。どこに出すかで実装範囲が変わる
- セール価格の見せ方 — 定価の取り消し線、割引率バッジ、対象商品の一覧ページ
- 併用ルールの初期方針 — 特に送料無料と注文割引の関係
- 管理画面を触る人のスキル — 誰が設定するか。専任がいないなら設定項目を減らす設計にする
- コレクション設計 — セール対象を「コレクション単位」で切れる構造にしておく
最後の項目が地味に効きます。割引の対象指定はコレクション単位でできるので、「セール対象」という運用用コレクションを作ってタグやルールで自動振り分けできる状態にしておくと、キャンペーンごとの設定が数クリックで終わります。ここが商品個別指定しかできない構造だと、キャンペーンのたびに対象商品を手で選ぶ作業が発生し、商品数が増えるほど選び漏れの確率が上がります。
具体的には、商品タグに「sale-2609」のようなキャンペーン識別子を付ける運用にして、自動条件コレクション（タグが一致する商品を自動で集める）を作ります。次のキャンペーンではタグを付け替えるだけで対象が入れ替わり、割引設定そのものは触りません。運用の手数が「商品数×クリック」から「タグの付け替え」に変わるのが効きどころです。この設計は構築時に決めておかないと、後から入れるには既存商品全部にタグを振り直す作業が発生します。
もうひとつ、公開前に決めておきたいのが割引の告知をどこに置くかです。ヘッダーの告知バー、商品ページのバッジ、カート内のメッセージ。この3か所は実装の担当範囲も更新のしやすさも違うので、「誰がいつ更新するか」まで含めて構築時に整理しておくと、キャンペーンのたびに実装者を呼ぶ状態を避けられます。
Shopifyを事業の器として見る
割引設計をここまで詰められるのは、Shopifyがカートだけの道具ではなく、販促と情報発信をまとめて載せられる器だからです。コーポレートサイトと兼用する構成にすれば、キャンペーンの告知ページ、ブランドストーリー、会社情報までを同じ管理画面で運用できます。この考え方はShopifyをコーポレートサイトと兼用する構成の記事で詳しく扱っています。
構築の初期段階で「どちらのプラットフォームで組むか」を迷っている場合は、次の記事も判断材料になります。
なお、割引表示のためのテーマ改修や販促系アプリの設定は、公開後の運用コストとして積み上がります。月額のアプリが増えれば、それは維持費です。費用は改修の範囲・アプリの本数・更新の頻度で変わるので、全体の見積もりを組むときは、ホームページの維持費の考え方と同じく、初期費用とは別に年間で積み上げて見ておくのが安全です。
よくある質問
クーポンコードと自動割引はどちらが売上に効きますか
目的が違うので比較できません。客単価を上げたいなら自動割引、新規顧客の獲得やリスト構築なら定価を守れるコード入力型が向きます。両方を並走させ、コード入力型で顧客を掴み、自動割引で客単価を上げるのが基本形です。
送料無料の下限はいくらに設定すべきですか
一律の正解はなく、自社の平均注文金額と1件あたりの配送原価から決めます。平均注文金額より少し上に置き、上乗せ分の粗利が配送原価を上回る水準にするのが原則です。平均を下回る設定は、放っておいても達成される注文まで送料を負担することになります。
複数のクーポンを同時に使わせることはできますか
同じクラスの割引（注文割引同士など）は基本的に重ねられません。異なるクラス（商品割引＋送料割引など）は併用設定を両方に入れれば可能ですが、複数コード入力の可否は仕様に依存するため、キャンペーンは「1注文につきコード1つ」を前提に設計するのが安全です。
割引の表示にはアプリが必要ですか
割引を効かせること自体はShopify標準機能で足ります。必要になるのは「商品ページやカートで割引条件を伝える表示」で、静的な訴求ならテーマ改修で完結します。顧客ごとに変わる動的な価格制御が必要な場合は、アプリまたは外部の仕組みを検討します。
セールをやめると売上が落ちるのですが
セールの効果ではなく、需要の繰り延べが起きている可能性が高いです。まず「割引を出さない期間」を意図的に作り、その期間のCVRと売上を素の実力として測ってください。この基準値がないと、割引を止める判断ができません。
割引コードが適用されないと問い合わせが来ます。どこを見ればいいですか
確認する順序は4つです。①有効期間と使用回数の上限を超えていないか、②対象商品・対象コレクションに該当商品が入っているか、③最低購入金額の条件を満たしているか、④他の割引と併用不可になっていないか。特に②は、割引を作ったあとに追加した商品がコレクションから漏れているケースが多く、自動条件コレクションにしておくと構造的に防げます。
まとめ
Shopifyの割引設定は、機能の選択ではなく判断の順序の問題です。
- 系統を分ける — コード入力型（クーポン）は届ける相手を絞って定価を守る。自動適用型（自動割引）は全員に効かせて客単価を上げる
- 併用を先に表にする — 特に送料無料と注文割引の関係。設定前にマトリクスを作り、テスト注文で1回通す
- 効かせる部分と伝える部分を分ける — 割引ロジックは標準機能、表示はテーマ改修。この線でアプリ導入の必要性が判断できる
- 終了条件を設定時に書く — 使用回数の上限を入れておけば止め忘れが起きない
- 定価期間を作る — 素の実力を測れないストアは、割引をやめる判断ができない
割引は売上を作る道具ですが、設計を持たずに使うと定価を壊す道具にもなります。構築の段階で表示場所とコレクション構造を仕込んでおけば、公開後の運用は数クリックで回ります。逆にここを飛ばすと、キャンペーンごとに手作業が積み上がり、割引の判断そのものに時間を割けなくなります。
