Shopify Scripts終了後に購買ルールが戻っていないか確認する｜割引・配送・決済の復旧監査台帳とテスト注文
ON THIS PAGE▼
Shopify Scriptsは2026年6月30日に削除され、公開済みのScriptsも機能しなくなりました。Scriptsで制御していた内容があれば、管理画面上で設定が残って見えるかどうかではなく、現在の購入画面で意図した結果になるかを確認する必要があります。
とくに確認対象になるのは、次のような「条件付きの購買ルール」です。
- 特定の商品群を一定数購入したときだけ段階割引を適用する
- 会員ランク、顧客タグ、法人顧客などで割引内容を変える
- 温度帯、商品区分、注文金額、配送先によって配送方法を出し分ける
- 特定条件では代金引換、後払い、特定の決済方法を表示しない
- 商品同士を同時購入した場合に、セット価格や無償同梱を成立させる
通常の受注確認では、条件に該当しない注文だけを見て「問題ない」と判断してしまうことがあります。そこで、旧Scriptsのコードを先に読み解くのではなく、まず「誰が、何を、どの条件で買うと、画面と注文がどうなるべきか」を台帳に戻します。
この記事の確認基準日は2026年9月28日です。Shopifyの機能・利用可能なアプリ・ストアごとの契約内容は変わり得るため、実装や設定変更の前には管理画面と公式ドキュメントを再確認してください。
まず把握する：Scripts終了後に確認すべき範囲
Shopifyは、既存のpayment・shipping・line item Scriptsについて、互換性のあるShopify Functionsなどへ移行する必要があると案内しています。つまり、確認対象を「割引があるか」だけに限定せず、旧Scriptsが担っていた役割で分けることが重要です。
| 旧Scriptsの役割 | 購入者に見える結果 | 監査時の確認点 |
|---|---|---|
| line item Script | 商品価格、割引、セット・数量条件 | 対象商品、数量、顧客条件で価格・割引が正しいか |
| shipping Script | 配送方法、送料、配送選択肢 | 配送先・カート内容・金額ごとに選択肢と料金が正しいか |
| payment Script | 決済手段の表示・非表示・並び順 | 顧客・配送先・カート条件ごとに利用可能な決済が正しいか |
Scripts customizations reportは、既存のpayment・shipping・discountカスタマイズを確認し、Shopify Functionsまたは関連アプリの代替候補を把握する入口になります。ただし、レポートに代替候補が示されても、それだけで移行完了とは判断できません。
理由は三つあります。
- 旧ルールに含まれたすべての条件が、新しい設定に反映されているとは限らない
- 移行先の仕組みとScriptsでは、対応できる条件や購入画面での挙動が同一とは限らない
- 設定済みでも、他の割引、配送プロファイル、決済設定、アプリとの組み合わせで期待結果が変わり得る
そのため、レポートは「調査対象を集める一覧」、テスト注文は「現在の購入体験を確認する証跡」と役割を分けます。
Scripts customizations reportで何も見つからない場合でも、過去のキャンペーン資料、CS向け案内、配送表、決済制限の社内ルールは確認してください。Scripts以外の標準設定やアプリで実現していたルールが混在している場合があるためです。
復旧監査台帳を作る：コードではなく購買ルールで記録する
監査の単位は「Script 1本」ではなく「購入者に約束している結果」です。1本のScriptに複数の条件が書かれていた場合、そのまま1行で管理すると、部分的な移行漏れを見落とします。
スプレッドシートやチケット管理ツールに、次の列を作成してください。
| 項目 | 記入内容 |
|---|---|
| ルールID | 例：DISC-01、SHIP-03、PAY-02 |
| 区分 | 割引／配送／決済 |
| 旧ルールの目的 | 何を実現するための条件だったか |
| 対象者・対象商品 | 顧客タグ、商品、コレクション、地域など |
| 発動条件 | 数量、カート金額、組み合わせ、配送先など |
| 期待結果 | 割引額・率、送料、表示すべき／しない配送・決済方法 |
| 旧Scriptsの根拠 | Script名、コードの該当箇所、過去の仕様書など |
| 現在の実現手段 | Shopify Functions、標準機能、アプリ、未対応、運用回避 |
| 代替可否 | そのまま可能／条件変更で可能／要追加開発／不可 |
| テスト条件 | 実施する顧客、商品、数量、住所、決済の組み合わせ |
| テスト結果 | 期待どおり／差異あり／未実施 |
| 証跡 | テスト日時、担当者、画面キャプチャ、注文番号など |
| 暫定対応 | 告知、広告調整、CS案内、手動対応の要否 |
| 恒久対応の担当・期限 | 判断者と次回確認日 |
ここで大切なのは、曖昧な表現を残さないことです。たとえば「VIPは送料無料」ではテスト条件を作れません。次のように購入画面で判定可能な条件に分解します。
- 顧客タグが
vipのログイン済み顧客 - 対象配送先は国内の指定地域
- 常温商品のみをカートに入れる
- 商品小計が指定金額以上
- 配送方法選択時に「通常配送」が送料無料で表示される
この書き方であれば、実装担当者だけでなく、運用・CS担当者も期待値を確認できます。
優先順位を付ける：売上影響と誤案内の大きさで並べる
すべてのルールを同じ緊急度でテストすると、重要な問題の確認が遅れます。まずは次の四つの観点で優先度を付けてください。
1. 購入不能・離脱につながるか
決済方法や配送方法が表示されない、反対に本来使えない方法が表示される、といったルールは優先度を上げます。購入完了前に影響が出るためです。
例として、特定地域への配送手段を制限していた場合は、対象外の配送を選べてしまうケースと、配送可能なのに選択肢が消えるケースを分けて確認します。前者は履行や追加送料の問題、後者は機会損失につながり得ます。
2. 価格・粗利への影響が大きいか
セット割、数量割引、会員別価格、無償同梱などは、誤った値引きと値引き漏れの両方を確認します。販売促進施策と連動している場合は、広告やメール配信の対象条件も台帳に記載します。
3. 発動条件が複雑か
顧客属性、複数商品、数量、地域、通貨などの条件が重なるルールは、単純な商品単位の確認では不十分です。ShopifyはScriptsに多通貨などで制約や挙動差があり得ることを案内していました。旧仕様と現在の表示・計算結果を同一視せず、実際のテストで確認してください。
4. 外部への約束になっているか
利用規約、配送ポリシー、会員特典ページ、法人向け案内、キャンペーンLP、メールなどに記載した内容は優先的に照合します。実装が正しくても、案内が古いままなら問い合わせや誤認の原因になります。
優先度は、たとえば「高・中・低」の3段階で十分です。ただし「高」にした理由を台帳へ残してください。「売上が大きそう」ではなく、「特定決済を利用する購入者が注文完了できない可能性」「誤送料無料で送料負担が発生する可能性」のように、判断の根拠を記録します。
代替手段を決める：Functions、標準機能、アプリ、運用を比較する
代替手段は、Shopify Functionsを使うこと自体を目的に選ぶものではありません。台帳に書いた期待結果を満たせるか、変更後も運用できるかで判断します。
Shopify Functionsを候補にする場面
ShopifyはScriptsからの移行先としてShopify Functionsを案内しています。割引、配送、決済で担う役割が異なるため、旧Scriptを一括で置き換えるというより、ルールの種類ごとに対応可否を確認します。
Functionsを利用する場合は、次を確認対象に含めます。
- 現在のルールの発動条件を表現できるか
- 必要なFunctionの種類と、利用するアプリまたはカスタム実装が一致するか
- 管理画面で誰が条件を変更できるか
- 他の割引やアプリの設定と併用したときの結果はどうなるか
- テーマ、カート、チェックアウト上の案内を更新する必要があるか
独自実装は細かな条件に合わせやすい一方、保守担当・検証環境・仕様変更時の対応を用意する必要があります。反対に、アプリは導入や運用を進めやすい場合がありますが、表現できる条件、料金、設定権限、解約時の影響を事前に確認します。料金や対応範囲は変動するため、契約判断時点の提供元情報を記録してください。
標準機能で足りる場面
旧Scriptsの目的が、現在はShopifyの標準機能で実現できることもあります。この場合も、「似た設定がある」だけで置換を決めず、発動条件と購入画面の期待結果を台帳の1行ごとに照合します。
たとえば単純な割引へ見直すことで運用が軽くなることがあります。一方、会員属性と商品組み合わせを掛け合わせていたルールでは、標準設定へ寄せることで対象範囲が広がる、または狭まる可能性があります。条件を簡略化するなら、事業判断として変更を承認し、購入者向け案内も更新します。
運用回避を選ぶ場合の条件
すぐに技術的な代替が決められない場合、期限を区切って手動対応や告知で影響を抑える選択肢はあります。ただし、恒久対応が未定のまま運用へ渡すと、判断漏れや対応差が起きやすくなります。
暫定対応には少なくとも以下を定義します。
- どの条件の注文を、誰が、どの画面で確認するか
- 購入者へ何を案内するか
- 価格訂正、返金、配送変更が必要な場合の承認者
- 暫定対応の終了条件と見直し日
テスト注文は「正常系1件」で終わらせない
テストでは、ルールが発動する注文だけでなく、発動してはいけない境界条件も確認します。各ルールについて、最低限「発動する条件」「発動しない近接条件」「他ルールと重なる条件」を設計します。
割引のテスト観点
| 観点 | 例 |
|---|---|
| 対象商品 | 対象商品だけ／対象外商品だけ／両方を同時購入 |
| 数量・金額 | しきい値未満／ちょうど／超過 |
| 顧客条件 | 対象顧客でログイン／対象外顧客／未ログイン |
| 割引の重なり | 他の自動割引・コードを併用する条件 |
| 表示と注文 | カート、チェックアウト、注文詳細で金額が一致するか |
配送方法のテスト観点
配送は住所、商品構成、金額で結果が変わるため、実際に配送先住所を変えて確認します。
- 対象地域と対象外地域
- 送料無料のしきい値未満・到達・超過
- 配送制限のある商品と通常商品の単独・混載
- 表示すべき配送方法が出ること
- 表示してはいけない配送方法が出ないこと
- 送料表示と社内の配送ポリシーが一致すること
決済方法のテスト観点
決済は、表示された時点だけでなく、注文完了まで確認します。利用可能な決済手段はストア設定や購入者側の状況にも左右されるため、テスト不能な条件は「未検証」として残し、検証方法を別途決めます。
- 対象・対象外の配送先
- 対象・対象外の商品構成
- 顧客タグなどの顧客条件
- カート金額の境界値
- 決済方法の表示・非表示と、注文完了可否
テスト結果には、画面キャプチャだけでなく、実施日時、テスト条件、注文番号またはカート内容、確認者を残します。キャンセルや返金が必要なテスト注文の処理担当も事前に決めておくと、注文データが曖昧に残りません。
テストアカウントを使う場合も、顧客タグ、ログイン状態、配送先、カート内容が本番想定と一致しているかを確認します。「テストした」という記録より、「どの購入条件を再現したか」の記録が重要です。
差異を見つけたときの初動：設定修正より先に影響を止める
差異があった場合、すぐに実装作業へ進めるとは限りません。まず、影響する購入者が増えないように、販促・案内・CSの対応を切り分けます。
1. 影響範囲を言語化する
台帳の該当行に、次を追記します。
- 本来の結果と実際の結果
- 発生する条件
- 影響する商品、地域、顧客区分
- 購入不能、値引き漏れ、過剰値引き、送料誤りなどの影響種別
- 確認済みの注文と、未確認の期間
2. 販促と案内を一時調整する
意図しない価格や配送条件が表示される場合は、該当する広告、メール、LP、バナーの継続可否を判断します。停止が常に正解ではありませんが、購入後に訂正が必要になる状態で露出を増やすことは避けるべきです。
また、CSには「対象条件」「現在の案内」「個別対応の可否」「エスカレーション先」を渡します。原因が未確定の段階で、復旧時刻や恒久対応を約束しないことも重要です。
3. 暫定策と恒久策を分ける
たとえば、配送方法の表示が誤っている場合、配送設定の一時変更で販売継続できることがあります。一方で、その変更が別地域や別商品へ与える影響もテストしなければなりません。
恒久対応としてFunctions、標準機能、アプリ、またはルール自体の見直しを選ぶ際は、変更後に同じテストケースを再実施します。差異を直した注文だけではなく、以前は正常だった境界条件まで再確認してください。
監査を一度で終わらせないための運用
Scripts終了後の復旧監査は、初回の移行確認で完了ではありません。割引施策、新商品、配送地域、決済設定、導入アプリが変われば、以前は正しかったルールにも影響が及ぶ可能性があります。
更新の契機を決めておくと、台帳が過去資料ではなく運用台帳になります。
- 新しい割引・会員施策を開始する前
- 配送プロファイルや送料を変更した後
- 決済方法を追加・停止した後
- Functionsや関連アプリの設定を変更した後
- 大型キャンペーン前
- CSで価格、送料、決済の問い合わせが発生したとき
最後に、台帳の「未対応」「未検証」を定例で確認します。未対応が直ちに障害とは限りませんが、何が未確認なのかを可視化しておくことで、担当変更やキャンペーン開始時の判断がしやすくなります。
Shopify Scripts終了後に必要なのは、移行方式の名称をそろえることではなく、購入者に提供してきた条件が現在も成立していると確認できる状態を作ることです。割引、配送、決済を別々にテストしつつ、同じ復旧監査台帳で優先度、証跡、暫定対応、恒久対応を管理してください。
参考情報
この課題、もっと詳しく相談したい方へ
記事では答えきれない個別の状況にもお応えします。