Shopify FlowでEC運用を自動化する設計ガイド｜タグ・通知・保留・在庫アラート

Shopifyで受注が増えると、運用担当者の負荷は少しずつ見えにくい形で増えます。

• 高額注文や不正疑い注文を目視で探している
• 注文ごとに「要確認」「ギフト」「法人」「予約商品」などのタグを手で付けている
• 在庫切れや低在庫に気づくのが遅れ、広告やSNS投稿を止められない
• 住所不備、支払い未確定、出荷保留をSlackやメールで共有し忘れる
• Flowを作ったが、Run historyを誰も見ておらず、失敗に気づかない
• HTTP requestや外部アプリ連携を入れた結果、二重通知や二重処理が起きる

こうなると「Shopify Flowを入れれば自動化できるのでは」と考えるのは自然です。

方向性は正しいです。ただし、Flowをテンプレート集として使うだけでは、運用は安定しません。

Shopify公式ヘルプでは、Shopify Flowはストアやアプリ上のイベントを監視し、トリガー、条件、アクションを使ってタスクやプロセスを自動化する仕組みとして説明されています。また、Shopify Flow referenceでは、トリガー、条件、アクション、コネクタの役割が整理されています。

実務で大事なのは、「Flowで何ができるか」ではなく、「どの業務をFlowに任せ、どこに人のレビューを残すか」です。

既存記事のShopify API連携の設計方法では、受注、在庫、会計、外部システムの正本と同期イベントを整理しました。この記事では、その前段または軽量版として、Shopify Flowを使って日々のEC運用をどう設計するかを扱います。

Shopify Flowの価値は、手作業を全部消すことではなく、確認すべき注文・在庫・例外を、正しい担当者へ自動で渡すことです。

先に結論：Flowは「通知」と「判断前の整理」に強い

Shopify Flowは、受注や商品、顧客、在庫などのイベントを起点にして、タグ付け、通知、データ取得、保留、外部サービス連携を行うのに向いています。

一方で、複雑な状態管理、厳密な再実行、外部DBとの双方向同期、重い業務ロジックは、Flowだけで抱え込まない方がよいです。

業務	Flow適性	代表的な設計	人の確認点
受注タグ付け	高い	注文作成時に金額、配送先、商品、顧客タグで分類する	タグの意味が古くなっていないか月次で見る
Slack・メール通知	高い	高額注文、住所不備、在庫切れ、不正リスクを担当チャンネルへ通知する	通知疲れが起きていないか確認する
注文保留	中〜高	支払い未確定、高額、不正疑い、在庫確認対象を保留する	保留解除の担当者と期限を決める
不正・高額注文レビュー	高い	リスク条件や金額条件でタグと通知を付ける	最終出荷判断は人が行う
在庫切れ・低在庫アラート	高い	SKU、在庫数、ロケーション条件でSlackやメールへ送る	補充、広告停止、販売停止の判断を人が行う
外部システム通知	中	Send HTTP requestやアプリコネクタで軽くつなぐ	失敗時の再送・重複防止は別途設計する
会計・WMS同期	低〜中	Flowは起点や補助通知に使う	正本、再実行、監査ログはAPI連携で設計する
複雑な承認フロー	低〜中	タグと通知で一次振り分けする	承認台帳やタスク管理は別システムを使う

Flowは「運用担当者が見落としやすいものを拾う」用途に強いです。逆に、会社の基幹データを正確に同期する中心として使うには、ログ、重複排除、再処理、権限、監査が不足しやすくなります。

Flowの基本はトリガー・条件・アクションで分解する

Flowを作る前に、業務をトリガー、条件、アクションに分解します。

公式リファレンスでも、トリガーはワークフローを開始するイベント、条件は基準に応じてアクションを実行するか決めるもの、アクションはストアや外部サービスに対して変更・通知・連携を行うものとして説明されています。

設計要素	EC運用での例	悪い設計	よい設計
トリガー	注文作成、商品在庫変更、顧客作成、スケジュール実行	「何かあったら全部見る」	注文作成時、在庫数変更時など発火点を明確にする
条件	合計金額、支払い状態、配送先、商品タグ、顧客タグ、在庫数	条件が曖昧で通知が多すぎる	レビュー対象になる具体条件を数値・タグで定義する
アクション	注文タグ追加、Slack通知、メール送信、注文保留、HTTP request	何でも自動で進める	タグ付け、通知、保留、台帳記録に分ける
例外処理	条件に合わない注文、失敗した通知、外部連携失敗	何もしない	Run historyを見て、再試行や手動対応に回す
レビュー	月次で不要ワークフローを止める	作りっぱなし	台帳で目的、担当、通知先、失敗時対応を見直す

たとえば「高額注文を確認する」という業務は、次のように分解できます。

項目	設計例
トリガー	Order created
条件	注文合計が100,000円以上、または不正リスクが高い、または初回購入かつ配送先が海外
アクション1	注文タグ review:high-value を追加
アクション2	Slackの #ec-review へ注文番号、金額、顧客名、管理画面URLを通知
アクション3	必要ならフルフィルメント注文を保留
人の確認	EC責任者が当日中に支払い状態、住所、リスク、在庫を確認
解除条件	レビュー済みタグを付け、保留解除またはキャンセルへ進める

この粒度まで落とすと、Flowを作る前に「何を自動にするか」と「何を人が見るか」が分かります。

受注タグ付けは、運用の索引として設計する

Flowで最初に効果が出やすいのは、受注タグ付けです。

ただし、タグは増やせば便利になるものではありません。タグは注文一覧、検索、通知、レビュー、外部連携の索引になります。命名がばらばらだと、半年後には誰も意味を説明できません。

タグ例	付与条件	使い道	注意点
review:high-value	注文金額が一定額以上	高額注文レビュー、出荷前確認	金額基準を客単価に合わせて見直す
review:fraud-risk	不正リスク、配送先、決済条件に該当	不正・チャージバック予防	自動キャンセルではなく人の確認へ回す
hold:payment-check	手動決済、未払い、支払い未確定	入金確認前出荷の防止	入金確認後の解除手順を決める
ops:address-check	住所不備、郵便番号不一致、海外配送	CS確認、配送前補正	顧客連絡テンプレートとセットにする
stock:partial-risk	明細に低在庫SKUを含む	出荷優先度、在庫確認	在庫正本がShopifyかWMSか確認する
order:b2b	法人顧客タグ、会社名、請求書払い	B2B対応、請求確認	個人購入と同じ出荷ルールにしない
campaign:gift	ギフト商品、ラッピング、メッセージカード	梱包指示、CS確認	倉庫側がタグを見られるか確認する

タグ設計では、接頭辞をそろえると運用しやすくなります。レビュー対象は review:、保留は hold:、在庫系は stock:、運用分類は ops: のように分けると、検索や月次棚卸しがしやすくなります。

受注タグは、外部連携のキーにもなります。たとえばWMSへ渡す前に hold: 系タグがある注文を除外する、会計連携前に review: 系タグが残っている注文を一覧化する、といった使い方です。ここまで行う場合は、Shopify API連携の設計方法で扱うWebhookやAdmin APIの設計と合わせて考えます。

Slack・メール通知は「誰が何をするか」まで書く

Flowでは、Slackコネクタやメール送信、外部サービスへの通知を使って、運用担当者に情報を届けられます。

ただし、通知は作りすぎると読まれません。通知文には、注文番号や商品名だけでなく、担当者が次に取る行動を入れます。

通知対象	通知先	通知に入れる情報	通知後の行動
高額注文	#ec-review	注文番号、金額、顧客、支払い状態、注文URL	当日中に出荷可否を確認する
不正疑い注文	#ec-risk	リスク要因、配送先、決済方法、過去購入有無	支払い確定・出荷を止めるか判断する
住所不備	CSメール、#ec-cs	注文番号、配送先、エラー内容	顧客へ確認し、修正後にタグを外す
低在庫	#ec-inventory	SKU、商品名、ロケーション、残数	補充、販売停止、広告停止を判断する
在庫切れ	#ec-inventory と広告担当	SKU、商品URL、販売チャネル	商品露出や広告を止める
Flowエラー	管理者、開発担当	ワークフロー名、実行時刻、Run history確認依頼	Run historyで原因を確認し再試行する

通知文は、次のように定型化します。

[要レビュー] 高額注文が入りました
注文: #12345
金額: 128,000円
条件: 100,000円以上 / 初回購入
対応: EC責任者が本日中に支払い状態・配送先・在庫を確認
URL: Shopify管理画面の注文URL

大事なのは、「通知したから終わり」にしないことです。通知後に誰がタグを外すのか、保留を解除するのか、キャンセルするのかまで決めます。

注文保留は、不正・高額・支払い確認とセットで使う

Shopify Flowのアクションには、注文タグの追加やメール・Slack通知だけでなく、フルフィルメント注文を保留するような運用に関わるアクションもあります。注文保留は強い手段なので、乱用すると出荷遅延やCS負荷につながります。

保留条件	Flowの処理	人のレビュー	解除条件
高額注文	review:high-value タグ、Slack通知、必要に応じて保留	支払い状態、不正リスク、在庫、配送先を確認	EC責任者が承認し reviewed タグを付ける
不正疑い注文	review:fraud-risk タグ、出荷保留、リスク通知	顧客情報、IP、配送先、過去購入を確認	出荷承認またはキャンセル
銀行振込・請求書払い	hold:payment-check タグ、CS/経理へ通知	入金確認、振込名義照合	入金確認後に保留解除
住所不備	ops:address-check タグ、CSへ通知	顧客へ住所確認	修正後に保留解除
在庫確認が必要	stock:partial-risk タグ、在庫担当へ通知	WMSや倉庫へ在庫確認	引当可能なら出荷、不可なら分割・キャンセル

決済や不正対策は、Flowだけでは完結しません。支払い確定、返金、チャージバック、会計照合まで含めた判断は、Shopifyの決済設定は何を決めてから有効化すべきかでも整理しています。

Flowの役割は、危ない注文を自動で見つけ、担当者へ渡すことです。最終判断まで無理に自動化すると、誤キャンセル、出荷遅延、顧客対応漏れが起きやすくなります。

在庫切れ・低在庫アラートは、販売停止までの行動に接続する

在庫アラートもFlowで扱いやすい業務です。

ただし、「在庫が少ないです」と通知するだけでは不十分です。低在庫を見た担当者が、何を止めるのか、何を補充するのか、どこへ連絡するのかを決めます。

在庫イベント	条件例	Flowアクション	運用側の判断
低在庫	販売可能数が5以下	Slack通知、商品タグ stock:low 追加	発注、広告停止、メルマガ対象外にする
在庫切れ	販売可能数が0	Slack通知、商品タグ stock:out 追加	商品露出、SNS投稿、広告を止める
高速消化	24時間で一定数以上減少	在庫担当と広告担当へ通知	追加発注、在庫配分、販売制限を判断
予約・入荷待ち	商品タグやメタフィールドで判定	CSへ通知、注文タグ追加	顧客への納期案内を行う
複数ロケーション差異	ロケーションごとの残数が条件に合う	在庫担当へ通知	ShopifyとWMSの正本差異を確認する

在庫の正本がShopifyではなくWMSや基幹システムにある場合、Flowだけで在庫運用を完結させない方がよいです。Flowはアラートやタグ付けに使い、在庫数の正式更新や差異復旧はAPI連携やWMS側の仕組みで管理します。

HTTP requestとアプリコネクタは、軽い連携に向く

Shopify Flowには、SlackやGoogle Sheetsなど外部サービスとつなぐコネクタがあります。さらに、Grow、Advanced、Plusプランでは、Send HTTP requestアクションを使って外部URLへHTTPリクエストを送れます。

HTTP requestは便利ですが、使い方を誤ると、外部連携の失敗や二重処理に気づきにくくなります。

連携方式	向いていること	向かないこと	設計ポイント
Flow単体	タグ付け、保留、メール、簡単な通知	複雑な外部同期、監査ログが必要な処理	Shopify内の運用整理に使う
Flow + アプリコネクタ	Slack通知、Google Sheets追記、既存アプリの軽い処理	失敗時の厳密な再実行が必要な処理	連携アカウントと権限を台帳に残す
Flow + HTTP request	社内Webhook、通知基盤、軽い受付APIへの送信	長時間処理、在庫・会計の正本更新	受信側で認証、ログ、重複防止を持つ
Webhook + Admin API	注文・商品・在庫イベントの本格連携	管理画面だけで完結する簡単な通知	署名検証、キュー、再実行、DB保存を設計する
カスタムアプリ	独自UI、承認、外部DB、双方向同期	一度きりの簡単な通知	権限、保守、リリース、監査まで持つ

Shopify Dev Docsでは、カスタムアプリがFlow actionを受け取る場合のFlow action endpointsについて、HTTPS、JSON、署名付きリクエスト、POST、action_run_id、レスポンスコード、重複リクエスト防止などが説明されています。

この領域に入ると、Flowの画面設定だけではなく、アプリ側の実装設計になります。action_run_idを冪等性キーとして扱い、同じリクエストが複数回来ても二重処理しないようにする。長時間処理は即時完了にせず、受け付けてからバックグラウンドで処理する。こうした設計が必要です。

FlowからHTTP requestを送るなら、受信側は「一度だけ必ず処理される」と仮定せず、失敗・再試行・重複を前提に設計します。

Run history、エラー確認、再試行を運用に組み込む

Flowは作って終わりではありません。Run historyを見て、どのワークフローがいつ動き、どのステップで何が起きたかを確認する必要があります。

Shopify公式ヘルプのFinding and monitoring workflow runsでは、FlowのRecent runsから実行履歴を確認し、エラー、実行ステータス、トリガー種別、Retry status、Run IDなどで検索できることが説明されています。ワークフロー実行履歴は完了後14日で削除されるため、長期的な監査が必要な場合は別途台帳や外部ログが必要です。

また、Retrying workflow runsでは、問題を修正したあとに過去のrunを手動で再試行できる条件が説明されています。再試行では、元のトリガーデータを使う一方で、Get dataアクションなどは最新データを取得する点に注意が必要です。

症状	Run historyで見ること	切り分け	対応
通知が来ない	ワークフローが発火しているか、条件で落ちていないか	トリガー条件、通知先、接続アカウント	条件修正、接続再認証、テスト実行
タグが付かない	対象注文・顧客・商品データが存在するか	リソース不足、条件式、For each漏れ	条件前に存在確認、必要ならGet data追加
HTTP requestが失敗する	ステータスコード、レスポンス、再試行有無	受信側障害、認証、タイムアウト	受信ログ確認、再試行、キュー化
同じ通知が複数来る	Run ID、Retry status、トリガー重複	再試行、複数ワークフロー、条件重複	台帳で重複ワークフローを統合
注文が保留されたまま	保留アクション後の解除手順	人の対応漏れ、解除Flowなし	保留一覧と解除担当を作る
エラーが繰り返す	同じステップで失敗しているか	transient errorかpermanent errorか	設定修正後に対象runを再試行

Shopify公式のトラブルシューティングでは、Flowの一時的なエラーは再試行される場合があり、永続的なエラーは設定やデータを直す必要があると説明されています。複数のワークフローが同じトリガーで増えすぎると、処理負荷や遅延の原因にもなります。

つまり、Flow運用では「失敗したら誰がRun historyを見るか」まで決める必要があります。

重複実行を前提に、タグと外部処理を設計する

Flowでは、同じトリガーに複数のワークフローがぶら下がったり、HTTP requestやアプリ連携が再試行されたりすることがあります。外部連携では、重複実行を前提にしておく方が安全です。

重複が起きる場面	起きる問題	対策
同じ注文作成トリガーのFlowが複数ある	同じSlack通知が複数回出る	同一トリガーのFlowを棚卸しし、統合する
タグ追加を起点に別Flowが動く	タグ追加が別のタグ追加を呼び、ループに近くなる	発火条件と追加タグを台帳で管理する
HTTP requestがタイムアウトする	受信側では処理済みなのに再送される	外部側で注文IDやaction_run_idを冪等性キーにする
手動Retryを行う	過去の通知や外部連携が再実行される	再試行前に対象アクションと副作用を確認する
アプリコネクタの接続が復旧する	溜まった処理が遅れて動く	Run historyと外部サービス側ログを突合する

タグ付けのように二重実行しても大きな問題になりにくい処理と、外部システムへの登録や請求・出荷指示のように二重実行が致命的な処理は分けます。

二重実行が困る処理は、Flow単体ではなく、Webhook/API/カスタムアプリ側で一意キー、処理済み状態、再実行ボタン、失敗ログを持つべきです。実装方式の境界は、Shopify APIの種類と選び方でも詳しく整理しています。

ワークフロー台帳を作り、月次レビューする

Flowが増えてくると、最大の問題は「誰も全体像を把握していない」ことです。

テンプレートを少し変えて作ったFlow、キャンペーン用に一時作成したFlow、担当者が退職したFlow、外部アプリ接続が切れたFlowが残ると、通知漏れ、重複通知、意図しない保留が起きます。

Bitlightでは、Flowを作るときにワークフロー台帳を先に用意することを推奨します。

台帳項目	記入例	見直し観点
ワークフロー名	高額注文レビュー通知	名前だけで目的が分かるか
対象業務	受注レビュー、不正確認	どの業務KPIに関係するか
トリガー	Order created	同じトリガーのFlowが増えすぎていないか
条件	合計100,000円以上、初回購入	閾値が現状の客単価に合っているか
変更するタグ	review:high-value	タグ命名が統一されているか
通知先	#ec-review、EC責任者メール	通知先が現在の担当者か
保留条件	不正リスク高、未払い、高額	保留解除手順があるか
外部連携	Slack、HTTP request、アプリ名	接続アカウントと権限が有効か
失敗時対応	Run history確認、対象run再試行	誰が何営業日以内に対応するか
月次棚卸し担当	EC責任者、開発担当	不要Flowを停止・削除しているか

月次レビューでは、次の順番で見ます。

確認項目	見る理由
実行回数が多すぎるFlow	通知疲れやレート制限の原因になる
エラーが出ているFlow	通知漏れ、タグ漏れ、外部連携失敗につながる
保留注文が残っているFlow	出荷遅延や顧客対応漏れにつながる
同じトリガーのFlow	条件重複、二重通知、処理遅延を防ぐ
接続アカウント	Slack、Google Sheets、外部アプリの権限切れを防ぐ
タグ一覧	古いタグ、使われていないタグ、意味が重複するタグを整理する
HTTP request先	受信側のURL、認証、ログ、担当者が変わっていないか確認する

Flowは「作った数」ではなく、「現場が迷わず使える状態で残っている数」で評価します。不要なFlowを止めることも、運用設計の一部です。

まとめ

Shopify Flowは、EC運用の手作業をかなり減らせます。

受注タグ付け、Slack・メール通知、注文保留、不正・高額注文レビュー、在庫切れ・低在庫アラート、アプリコネクタ、HTTP requestまで、日々の運用を支える機能がそろっています。

ただし、Flowを機能一覧として見ると失敗します。先に決めるべきなのは、どの業務をトリガーにし、どの条件で、どのアクションを動かし、どこで人が確認し、失敗したら誰がRun historyを見て再試行するかです。

Flow単体でよい処理、Flow + HTTP requestで軽くつなぐ処理、Webhook/APIで本格連携すべき処理、カスタムアプリで持つべき処理を分けると、EC運用は崩れにくくなります。

Bitlightでは、Shopify Flowを単なる自動化設定としてではなく、受注、在庫、不正確認、通知、保留、外部連携、月次レビューまで含めた運用設計として整理します。Flowを作る前に、まずワークフロー台帳、タグ命名、通知先、失敗時対応、API連携との境界を決めることが重要です。