Shopify Scriptsは2026年6月30日に実行を停止します。Script Editorで構築したすべてのカスタムディスカウント、配送、または支払いルールはその日付で適用を停止します。代わりになるのはShopify Functionsで、チェックアウト内でサーバー側でロジックを実行します。3つの方法があります。開発者を雇ってFunctionsを書く、エージェンシーに依頼する、またはノーコードFunctionsアプリでルールベースのディスカウントロジックを再構築する。急いでいる部分は、失敗がサイレントであることです。実行を停止するScriptまたはカートと一致しない移行されたルールがエラーをスローしません。通知もしません。顧客が苦情を言うまで静かに全額料金を請求します。
このガイドでは、Scriptsが何をしたのか、Shopifyがそれらをなぜ廃止しているのか、Functionsが実際に何なのか、「Scriptを移行する」が実際には最大3つの別々の移行なのか、サイレント失敗の罠と正確にそれをテストする方法、ノーコードアプリが何ができて何ができないか、そして開発者がまだ必要な場合の正直な説明を説明します。
Shopify Scriptsに何が起こっているのか、そしていつですか?
Shopify Scriptsは廃止されています。Shopifyの開発者ドキュメントによると、「Shopify Scriptsは2026年6月30日に廃止されます。すべての既存Shopify Scriptsはこの日付以降に機能停止します。」重要な2つの日付があり、最初の日付はすでに過ぎています。
- 2026年4月15日:新しいShopify Scriptsの編集と公開はもはや可能ではなくなります。Shopify開発者チェンジログによると、この日付以降はScriptを作成または変更できません。
- 2026年6月30日:すべてのShopify Scriptsは完全に実行を停止します。Scriptに存在するすべてのディスカウント、配送、または支払いロジックは実行を停止します。
あなたの店舗が2026年7月1日のScriptに依存していた場合、あなたがこれを読んでいるようにそのロジックはすでにオフラインです。カスタマイズがエラーを出したり、安全なデフォルトにロールバックしたりすることはありませんでした。それらは静かになっただけです。これがこの期限について理解する最も重要な事柄です。ダッシュボードアラートから気づく大きな失敗ではありません。それは不在です。
Shopifyはまた、作業のスコープを支援するツールを出荷します。Shopify Scriptsカスタマイズレポートは、現在のどのカスタマイズがFunctionsまたはパブリックアプリに移行できるかを特定するのに役立ちます。実行していない場合は、ステップ1です。
画像プレースホルダー（画像1）: Scriptsサンセットタイムライン
推奨ビジュアル: 3つのマイルストーンマーカーがあるクリーンな16:9水平タイムラインを白い背景にバイオレットと深いゴールド色で表示。マーカー1は「2026年4月15日 - 編集終了」をゴール色で表示。マーカー2は「2026年6月30日 - Scripts実行停止」をバイオレット色で表示し、小さい赤い「サイレント」タグを付与。最後のマーカーを超えた矢印は「Shopify Functions」と表示。フラット、ミニマル、サンセリフラベル、写真なし。
Shopify Scriptsは何をしたのか、そしてなぜShopifyはそれらを廃止しているのか?
Shopify Scriptsは、Script Editorアプリで実行され、購入フローの3つの部分をカスタマイズする小さなRubyプログラムでした。カート及びラインアイテムディスカウント、配送料金、および支払い方法。Shopify Plusのマーチャントは、ティアード割引を提供するScript、特定のアドレスの配送オプションを非表示にする、またはチェックアウト時に支払い方法を並べ替えることができました。Scriptsは任意のコードであったため正確に強力でした。Rubyで表現できれば、実行できました。
ShopifyはそれらをShopify Functionsで置き換えています。移行ドキュメントによると、「Shopify Functionsを使用すると、これらのカスタマイズは、より良いパフォーマンスと柔軟性を提供する専用のFunction APIを通じて処理されます。」FunctionsはShopifyのチェックアウトパイプライン内で実行され、古いScriptsモデルより高速でスケーラブルで、買い手がカートページ、チェックアウトページ、またはShop Payなどの高速化されたウォレットでチェックアウトするかどうかに関わらず、同じロジックが適用されます。
トレードオフは、FunctionsはRubyを貼り付けるテキストボックスではないということです。それらは開発者アーティファクトです。Shopify CLIでスキャフォールドし、RustまたはJavaScriptでロジックを書き、GraphQL入力クエリを定義し、アプリを通じてデプロイします。その転換は、「マーチャントがScriptを書く」から「開発者がFunctionをシップする」までです。これが全体の理由です。この移行はプロジェクトであり、チェックボックスではありません。
Shopify Functionsとは何か、そしてなぜ通常は開発者を必要とするのか?
Shopify Functionsを使用すると、Shopifyのバックエンドロジックの一部を拡張または置き換えることができます。チェックアウト中に実行されるカスタムコード付き。Scriptsが過去に行ったことを含む専用のFunction APIがあり、Discount Function API、Delivery（配送）Customization API、Payment Customization APIが含まれます。
移行計画に関係するFunctionsの2つのプロパティ。
Functionsはサーバー側で一度実行されます
FunctionはテーマではなくちょうどShopifyのチェックアウト内で実行されます。それは、テーマJavaScriptでカートページの合計を計算してから、チェックアウトで支払う内容と不一致になるディスカウント方法よりも本当にアップグレードです。Functionが唯一の真実のソースであるため、カートプレビューと最終的な請求は同じ計算です。これはまた、カートページをスキップするShop Pay、Apple Pay、Google Payに渡ってFunctionが同じように適用される理由です。
Functionsはデフォルトで構築され、設定されません
ゼロからFunctionを書くことは開発者のタスクです。Shopify CLIが必要です。言語ツールチェーン。Functionの入力クエリと結果の形状に対する精通度。計画の可用性について知る価値のあるニュアンスがあります。Functions可用性ドキュメントによると、「任意のプランの店舗は、Shopify App Storeを通じて配布され、機能を含むパブリックアプリを使用できます。Shopify Function APIを含むカスタムアプリのみがShopify Plusプランの店舗で使用できます。」平文では、App StoreのパブリックアプリはあらゆるプランにFunctionsをもたらすことができますが、ビスポークのカスタムビルトFunctionはPlus専用です。その区別は、ノーコードFunctionsアプリを開発者に依存していた非Plus商人に魅力的にします。
朗報は、Functionがアプリ内に展開されると、マーチャントはコードに触れずに管理からそれを設定することです。Functionsが起動した時点でShopifyが言ったように、「マーチャントエンドユーザーはカスタマイズを変更する場合、コードの1行にも触れる必要はありません。」コードは一度書かれます。設定は管理に住んでいます。
なぜ「Scriptを移行する」は実際に3つの別々の移行なのか?
これは人々を驚かせる詳細で、Shopifyコミュニティフォーラムでマーチャントが作業をどのように説明しているかから直接来ています。単一のScriptファイルは一度にディスカウント、配送、支払いロジックに触れることができました。Functionsは意図的にそれを分割し、独立したFunction型に分割します。
- ディスカウントロジック（ティアード価格設定、BOGO、注文および商品割引、スタッキングルール）はDiscount Function APIにマップします。Shopifyの統合Discount Function APIは、単一の関数からすべての3つのディスカウントクラス（商品、注文、配送）全体に節約を適用できます。
- 配送及び配達ロジック（配達オプションの名前変更、並べ替え、または非表示）はDelivery Customization Function APIにマップ。完全に別の関数。
- 支払いロジック（支払い方法の名前変更、並べ替え、または非表示）はPayment Customization Function APIにマップ。3番目の別の関数。
したがって、「Scriptを移行する必要があります」という文は、最大3つの異なるものを移行することを意味することがよくあります。独立して設定および展開されます。ノーコード割引アプリは最初のバケットを再構築できます。配送と支払いのバケットに到達しません。これはノーコード割引アプリが提供しない正確な理由です。古いScriptを移行する前にインベントリを作成する必要があります。単一のツールがそれをカバーすると想定します。まずサーフェスで作業を分割してから、各サーフェスのパスを選択します。
画像プレースホルダー（画像2）: 1つのScriptが3つのFunctionsになります
推奨ビジュアル: 16:9ダイアグラム。左側に、スレート色の単一のラベル付きボックス「1つのShopify Script（Ruby）」。3つの矢印が右側に3つの別々のボックスにファンアウトします。バイオレット色の「Discount Function」、ゴール色の「Delivery Function」、スレートブルー色の「Payment Function」。各機能は小さい「独立して展開」キャプションが付けられます。クリーンなフラットベクトル、ブランドカラーバイオレットとゴール、写真なし。
サイレント失敗の危険性、そしてそれをテストする方法
これはマーチャントに実際のお金がかかる部分であり、期限自体と再構築するすべてのルールに適用されるため、独自のセクションに値します。
Shopify Functionは、整形式で実行中であるか、設定が悪くてサイレントです。目に見える中間状態はありません。条件が特定のカートと一致しないFunctionは発火しません。エラーも出しません。アラートも出しません。それは設計上です。Functionが正しく動作している場合に得られるのと同じ沈黙（正しくは適格ではないカートのために何もしませんでした）は、Functionが壊れている場合に得られる沈黙（閾値のタイプ、間違ったコレクションにスコープされたルール、トリガーされないティア）と同じです。
この移行を進めているマーチャントはShopifyコミュニティフォーラムで同じ経験を説明しています。ルールは静かにディスカウント適用を停止し、マーチャントは顧客が全額支払いについて苦情を言うため気づきます。エラーなし。アラートなし。注文ログに何もありません。ストアは、誰かが気づく前に数週間壊れたセットアップで実行されていました。
本番環境でルールを信頼する前に、唯一の信頼できる防御は両方向でテストすることです。
- 発火すべきカートを構築してください。ルールのすべての条件を満たす実際のカートを組み立てて、下書きまたはテスト注文を配置してから、チェックアウトサマリーを1行ずつ読みます。期待される正確なディスカウントが存在し、期待される金額であることを確認します。
- 発火しないカートを構築してください。意図的に適格でないカート、たとえば数量閾値より下の1つのアイテムのカートを組み立てて、ディスカウントが正しくオフのままであることを確認してください。
必要のないときに発火するFunctionは、静かに発火しないものと同じくらい高額です。ルールが両方適用され、正しく拒否されるのを見るまで、テストは完了していません。Shop Payを通じて発火すべきカートも実行して、加速化されたパスが標準チェックアウトと一致することを確認してください。
ここにいる間にもう1つの保存ステップ。古いScript ソースを今保持してください。Script Editorが完全に廃止されると、その保存されたコードはShopifyから復旧不可能になります。それを置き換えるものの参照と仕様を持つように、今日でも再構築する準備ができていなくても、Scriptソースをエクスポートまたはコピーしてください。
ノーコードアプリはScriptsを移行できますか? それが何をカバーし、何をしないか
特にディスカウントサーフェスについては、ノーコードFunctionsアプリは、マーチャントがScriptに使用していたものの大きなシェアを吸収できます。Scriptロジックが規則に減少するの場合、つまり「カートがXのように見える場合、ディスカウントYを適用する」。設定駆動型アプリは通常、開発者なしで再構築できます。これはかなりの共通の根拠をカバーしています。
- ティアード及びボリューム割引。たとえば「3つ以上購入、15パーセント節約。」
- X を購入してYを獲得してBOGOロジック。「6つ購入して2つ獲得、9つ購入して3つ獲得」などのティアを繰り返すを含む。
- オファー間での明示的なスタッキングと組み合わせルール。
- キャンペーンのスケジュール開始、終了、および即時一時停止。
ノーコード割引アプリが何をできないかは、移行がサイレントに失敗する方法であるため、平文で同様に言う必要があります。
- 任意のカスタムコード。Scriptが独自の価格設定式を実行するか、ビルダーが公開しないルールに減少しない1回限りの条件の場合、割引アプリはそれを表現できません。そのロジックはまだ、カスタムFunctionを書く開発者が必要です。
- 配送及び支払いカスタマイズ。これらは別のFunction型（配達および支払い）です。割引のみのアプリはそれらに到達しません。開発者は独立してそれらを移行します。
- ルールベースのディスカウント設定の外のすべてのもの。それが根本的に「条件入力、出力割引」ではなかった場合、設定画面はそれ用の形状が間違っています。
正直なテストはシンプルです。古いScriptの各部分が1つの文で何をしたかを書いてください。文がディスカウントに関するルール。ノーコードアプリは強力な候補です。式、配送変更、支払い変更、またはルールとして表現できない場合。各部分の開発者を予算に入れます。
Stackableでこの移行を確実に実行してください
Scriptのディスカウントロジックがルールベースの場合、ティア、BOGO、スタッキング、スケジューリング、Stackableは正確にそのサーフェスをネイティブShopify Functionsで再構築します。コードなしで、そしてその端を正直に言います。
- これはルールベースのディスカウントロジックを再構築し、ボリュームとティアード価格設定、BOGO、明示的なディスカウントスタッキング、およびスケジュール開始、終了、一時停止。Rubyを維持する代わりに管理で編集する設定として。
- 数学はShopify Function内で実行されるため、カート、チェックアウト、Shop Payは1つの同一の合計を計算します。古いディスカウントセットアップの一般的な失敗モードであるテーマ対チェックアウトドリフトはありません。
- カートシミュレータを使用すると、ライブで実行する前に発火すべきカートと発火しないカートの両方を実行できるため、顧客苦情の代わりにプレビューでサイレント設定ミスを捕捉できます。
- スコープについて正直です。Stackableは任意のカスタムコードを実行しません。配送（配達）またはペイメントカスタマイズにも関与しません。本当に独自のロジックとこれら2つの別々のFunction型はまだ開発者が必要です。
Stackableを無料でインストールして、気づかないうちに売上を逃す前に、ルールベースの割引ロジックをShopify Functionsで作り直しましょう。usestackable.com/pricing 🚀
実行例: 今日フォローできる移行チェックリスト
このシーケンスを使用して、「Scriptが壊れた」を制御された移行に変えます。テーブルは一般的なマルチ目的Scriptをその目的地にマップします。
次に、順番にステップを実行してください。
1. 何かを構築する前に古いScriptをインベントリしてください
Script Editorを開いている間に、まだできる限り、各動作について1つの文を書いてください。Shopifyの Scripts カスタマイズレポートを実行して、何も隠れていないことを確認してください。Rubyソースをエクスポートして、エディタが廃止された後に復旧不可能になる前に安全な場所に保存してください。
2. インベントリをサーフェスで分割してください
各動作をディスカウント、配送、または支払いに分類してください。これは、ノーコード割引アプリが取ることができる部分と、開発者が必要な部分を即座に示します。1つのツールがすべて3つをカバーすると想定しないでください。
3. ルールベースのディスカウント部分をコードなしで再構築してください
「条件入力、割引出力」に減少するすべての動作について、ネイティブShopify割引またはFunctionsベースの割引アプリで再作成してください。オファーが積み重なることを意図している場合は、組み合わせルールを明示的に設定してください。
4. ノンルール部分を開発者に渡してください
独自の式、配送カスタマイズ、支払いカスタマイズは、開発者またはエージェンシーが独自のFunctionsとして構築するために行われます。エクスポートされたScript ソースを仕様として提供してください。
5. 再構築されたすべてのルールを両方の方法でテストしてください
各ルールについて、発火すべきカートと発火しないカートを実行してください。チェックアウトサマリーを1行ずつ読んでください。ルールは、両方適用され、正しく拒否されるのを見るまで、移行されません。
6. 加速化されたチェックアウトを確認してください
Shop Payを通じて発火すべきカートを実行してください。Functionsはサーバー側で計算されるため、正しく構築されたルールは同じように適用されます。これは、ウォレットがスキップするテーマコードに何も依存していないことの最後のチェックです。
画像プレースホルダー（画像3）: 信頼する前に両方向でテストしてください
推奨ビジュアル: 16:9分割図。左パネルは「発火すべきカート」と表示。緑色の割引行が正しく存在するチェックアウトサマリーが表示されます。右パネルは「発火しないカート」と表示。チェックアウトサマリーで割引が正しく不在で、緑色のチェックマークが表示されます。中央のキャプションは「サイレントルールはエラーを発生しません - 両方をテストしてください」と読みます。ブランドカラーバイオレットとゴール、フラットベクトル、写真なし。
ボトムライン
- Shopify Scriptsは2026年6月30日に実行を停止し、編集はすでに2026年4月15日に終了しました。まだ使用中のScriptはすでにオフラインです。
- 失敗はサイレントです。停止したScriptまたはカートと一致しない移行されたルールは、エラーなし。アラートなし。全額料金を請求するだけです。
- Functionsは交換です。チェックアウト内のサーバー側で実行されます。しかし、ゼロから書くことは開発者タスクで、カスタムFunctionsはPlus専用です。
- 1つのScriptは通常、3つの移行になります。ディスカウント、配送、支払いFunctions。独立して展開されます。
- ノーコードFunctionsアプリはルールベースのディスカウントロジック（ティア、BOGO、スタッキング、スケジューリング）を再構築できます。任意のコード、配送、支払いカスタマイズは実行できません。
- 古いScript ソースを今保持してください。Script Editorが廃止された後に復旧不可能になります。
- 再構築されたすべてのルールを発火すべきカートと発火しないカートでテストします。チェックアウトサマリーを1行ずつ読んでください。Shop Payも含めて。
関連記事
- Shopify Scriptsからの移行完全なレスキューパス、コードなしで再構築するもの、そしてまだ開発者が必要なもの。
- Shopifyでディスカウントスタッキングがどのように機能するかネイティブが最高の割引のみ適用する理由と、オファーを正しく組み合わせる方法。
- ボリューム割引と数量ブレークコレクション全体ではなく、同じ製品をカウントするティアード価格設定を再構築します。
- ディスカウントスタッキング、正しく実行3つのクラスごとの結合スイッチとライブカートシミュレータ付き。
- ShopifyのBuy X Get Y100製品制限移行後、フルカタログで3つで2つを実行します。
- Stackable価格設定計画、無料層、および各含むもの。
