Shopify Flow

Shopify Flowとは？

Shopify Flow（https://apps.shopify.com/flow?locale=ja)はShopifyが提供するEコマースの自動化プラットフォームです。

顧客の注文に応じてCRMメールを送る
顧客の注文に応じてタグを付与する
最初の注文から30日後にクーポンを送る
商品の在庫が一定数を下回った場合にアラート通知をする

など、様々なオペレーションを自動化できます。

定期購買アプリとの連携でできること

顧客管理タグや注文管理タグによる制御だけでは、「解約しようとしたお客様を引き止める」「n回継続したお客様にお礼のクーポンを送る」といった、お客様の行動に応じたきめ細かい CRM 施策は実現が困難でした。

定期購買アプリの Flow トリガーを使うと、スキップ・解約・周期変更・決済エラーといった定期購買ならではのイベントを起点に、解約防止や LTV 向上の施策を組み立てられます。

参考：Shopifyアプリ「定期購買」、Shopify Flowとの連携機能追加（PR TIMES）

ご利用前にご確認ください

Shopify のプランによって、一部のトリガーが表示されない場合があります

定期購買アプリは Flow トリガーを 22個（2026年8月時点）提供していますが、Shopify のプランが有料化されていないストアでは、Flow のトリガー一覧に一部のトリガーが表示されないことがあります。

これは Shopify 側の仕様によるもので、Shopify からは「完全な Flow をテストするには有料プランにする必要がある」と案内されています。Flow を使った自動化を継続的に運用・検証される場合は、有料プランへの変更をご検討ください。

表示されているトリガーは、通常どおりご利用いただけます。 （2026年8月時点で確認）。
表示上の制限であり、トリガーの動作そのものに違いはありません。
※ただし Shopify 側の仕様によるものであるため、今後の変更により挙動が変わる可能性があります。
すでに設定済みの Flow は、そのトリガーが一覧に表示されなくなった場合でも動作を継続します（2026年8月時点で確認）。
ただし Shopify 側の仕様によるものであるため、今後の変更により挙動が変わる可能性があります。

目的のトリガーが表示されない場合

新しく Flow を作成・編集する際に目的のトリガーが見つからない場合は、以下をお試しください。

しばらく時間をおいてから、Flow のトリガー一覧を再度ご確認ください(まれにこの方法で改善するケースがあります）
Shopify のプランを有料プランへ変更いただくと、すべてのトリガーが表示されます

トリガー一覧と発火条件

同じ「解約」でも、お客様がマイページから操作した場合とストア様が管理画面から操作した場合で、トリガーが発火するかどうかが異なります。下記の表でご確認ください。

表の見方

記号	意味
○	その操作でトリガーが発火します
×	その操作ではトリガーが発火しません
★	一般設定にて、発火条件の拡張を有効に切り替えると発火します

マイページ：お客様ご自身によるマイページからの操作
管理画面：ストア様によるアプリ管理画面からの操作
システム：人が介在しない、アプリ側の自動処理（決済失敗後の一時停止など）

契約内容の変更

トリガー名	マイページ	管理画面	システム	補足
一時停止時	○	★	★	システムは「決済失敗による自動一時停止」で発火します
解約時	○	★	★	システムは下記4つの経路で発火します① 一般設定「定期購買の自動解約」による、顧客の退会時の自動解約② 一括支払いプランの最高サイクル回数への到達③ 一括支払いプランの契約商品が削除済み④ 通常契約の最大購入回数への到達
プラン（周期）の変更時	○	★	×
スキップ時	○	★	×
スキップの取り消し時	○	★	×
お届け日の変更時	○	★	×
お届け先の変更時	○	★	×
商品の追加時	○	★	×
商品の変更時	○	★	×
商品の削除時	○	★	×
数量の変更時	○	★	×
ポイントディスカウント	△	△	△	こちらのAPIを利用して実装していることが前提です。管理画面は付与済みのポイントディスカウントを「削除」する場合のみ発火します。システムは付与済みのポイントディスカウントを「クーポンの一括削除」した場合に発火します

注意点

一括操作について

管理画面の一括操作では、原則としてトリガーは発火しません。「ポイントディスカウント」の一括削除のみが例外です。

マイページからの契約内容変更について

管理画面では商品の追加・変更・削除・数量変更がそれぞれ個別の機能として実行され、それぞれのトリガーが発火します。

マイページカスタマイズにて商品一括変更APIを利用している場合、変更内容に応じて該当するトリガーが発火します。

注文・決済

トリガー名	マイページ	管理画面	システム	補足
初回の購入時	×	×	○	契約作成時に発火します
2回目以降の購入時	×	×	○	定期決済に限らず、マイページの「追加購入」、管理画面の「今すぐ注文」「再決済」の成功時にも発火します
商品の追加購入時	○	★	×	管理画面は「今すぐ注文」で発火します
管理画面からの再決済時	×	○	×	支払い履歴からの再決済で、成功・失敗いずれの場合も発火します
決済エラー時	×	×	○	6分ごとのインターバルの再決済では3回目の決済まで全て失敗した場合に発火します。以後、指定日数後の再決済や定期決済等、決済失敗のたびに発火します
決済成功・一時停止からアクティブに契約ステータスが更新された時	×	×	○	決済設定にて「再決済成功時に契約ステータスをアクティブへ変更する」を有効にしている場合に発火します
未確定の支払い情報の検知時	×	×	○	3Dセキュア認証が必要な情報をShopifyから受け取った際に発火します(そのため3Dセキュア認証が必要になってから発火するまでにタイムラグが発生します）
支払い方法の変更時	×	×	○	クレジットカード変更のご案内メールからお客様がShopify上で変更された後に発火します（支払い方法変更ボタンが押されたタイミングではありません）
Shopifyペイメント以外の支払い方法の変更時	×	×	○	後払い決済と通常決済を切り替えた際に発火します。契約IDが変わるため、出力に「変更前の定期契約ID」を含みます

管理画面から再決済した場合の発火

　成功時：「管理画面からの再決済時」＋「2回目以降の購入時

　失敗時：「管理画面からの再決済時」＋「決済エラー時」

　「2回目以降の購入時」「決済エラー時」は決済結果次第でどちらが発火するか変わります。

決済エラー時

「決済失敗時、指定日数後に再決済する、再決済する日数の設定：2、再決済を最大2回まで繰り返す、の場合の発火タイミングはこちらになります9月1日　12:00 決済失敗

　　　　12:06 決済失敗

　　　　12:12 決済失敗　←発火

9月3日　12:00 決済失敗　←発火

9月5日　12:00 決済失敗　←発火

（アクティブを継続する場合、失敗回数設定に応じて以後同様）

その他

トリガー名	マイページ	管理画面	システム	補足
注文時n日前通知メール	×	×	○	アプリの定期処理で発火します

トリガーが発火しない操作

以下の操作では、いずれの経路からもトリガーは発火しません。

会員ランクの変更（現在の累計額の変更）
一時停止からの再開
解約からの再開
次の注文予定日の変更
注文回数の変更
備考の変更
次回適用クーポンの設定
金額の変更
オプションの変更
送料の変更
BOXの変更

操作元による分岐（Operator変数）

各トリガーは Operator 変数を出力します。同じトリガーでも「誰の操作で発火したか」によってFlowの処理を分けたい場合にご利用ください。

値	対応する操作
CUSTOMER	お客様ご自身によるマイページからの操作、および公開API経由の操作
MERCHANT	ストア様によるアプリ管理画面からの操作
SYSTEM	人が介在しない、アプリ側の自動処理

※公開APIにて、旧版の「お届け日の変更時」APIを利用されている場合は例外的に MERCHANT となります。

分岐の利用方法

トリガー選択後、「条件」を選択
「変数を追加する」をクリック
operatorを選択
OperatorにはCUSTOMER/MERCHANT/SYSTEM任意のものを入力してください
お好みのアクションや条件を追加してご利用ください

活用例

「CRM PLUS on LINE」などと連携したLINE CRM

ソーシャルPLUS社提供のShopifyアプリ「CRM PLUS on LINE」などと組み合わせることにより、 LINEでのステップ配信やお知らせも実現可能になります。

CRM PLUS on LINE：https://apps.shopify.com/socialplus?locale=ja

初回購入や発送からのLINEステップ配信
決済日n日前にLINEで商品変更・スキップ等案内
LINEで発送完了のお知らせ
n回継続で限定クーポンをLINE配信

Operator変数の分岐を利用した柔軟な対応

決済失敗が原因で自動的に一時停止となった顧客に対してのみ、対応を行いたいというケースがあります。

一時停止トリガーを利用し、Operator変数でSYSTEMのみに絞り込むことで、「決済失敗によって一時停止となった顧客」のみを洗い出すことが可能です。

システム起因の一時停止（決済失敗後の一時停止）が発生したらスプレッドシートへ連携.flow

2.2KB

公開APIを組み合わせた柔軟な運用（応用編）

定期購買アプリのFlowトリガー × ShopifyのHTTPリクエストアクション × 定期購買アプリの公開API を組み合わせることで、標準機能だけでは難しい運用も実現できます。

はじめにご確認いただきたいこと

安心してご活用いただくために、設計の前に以下を押さえておいていただけるとスムーズです。

ご利用条件： 公開API連携はアプリのENTERPRISEプランでご利用いただけます。FlowのHTTPリクエストアクションはShopifyのプランが Grow 以上で利用可能です。一部のアクションはShopifyプランによって利用可否が変わりますので、あわせてご確認ください。
APIコール数について： トリガーが発火するたびに公開APIを呼び出す構成の場合、発火頻度の高いトリガー（たとえば「2回目以降の注文作成」は毎回の定期注文で発火します）を起点にすると、呼び出し量が想定以上に増えることがあります。Flowの条件設定で対象を絞り込んでいただくのがおすすめです。
重複適用にご注意： Flowの処理は非同期で行われ、実行の順序は前後する場合があります。とくにクーポンの付与を自動化する際は、次回適用クーポン機能は使用回数の制限が反映されない仕様のため、条件を付けずに付与すると同じ契約へ複数回適用されることがあります。付与済みかどうかを判定する仕組みをあわせて用意しておくと安心です。
本番の前にひと確認： はじめにテスト環境で挙動とコスト感を確かめていただくと、安心して本番に移していただけます。

実装イメージ（一例）

上記を踏まえたうえで、たとえば次のような運用が考えられます（構成の一例です）。

例1： 2回目以降の注文作成をトリガーに、条件に合致する契約へディスカウントクーポンを付与する（トリガー → 条件設定で絞り込み → HTTPリクエストアクションで公開APIを呼び出し）。
例2： 初回注文をトリガーに、配送日時指定アプリ経由で付与されたお届け予定日をもとに次回お届け予定日を算出し（Run Codeアクション）、指定の日時へ更新する（HTTPリクエストアクションで公開APIを呼び出し）。