目次
Shopify FlowはBasic、Grow、Advanced、Plusでワークフローを自動化します。Sidekickが作成・更新を支援し、スケジュールトリガー、Get data、ループが一部の定期データ作業に対応します。利用できるフィールドとアクションは、引き続きフローとプランによります。
以下の20個のプロンプトは設計案です。実装前に、現在のFlow資料、使えるトリガーとアクション、プラン要件、外部コネクターを確認してください。詳しくは、高度なShopify Flowワークフローの10例（2026年）をご覧ください。
Sidekickでワークフローを作成してテストする方法
Shopify Flowを開き、管理画面で使える場合はSidekickのワークフロー作成を選びます。 下書きのトリガー、条件、アクション、データ項目、権限を確認してから保存・有効化してください。
ShopifyのSidekickワークフローガイドとバージョン履歴の手順を使い、開発用や影響の小さいフローで想定内・想定外のケースを確認します。履歴は編集と有効化を記録し、以前の版を復元すると有効化前に確認できる下書きが開きます。
A. 注文業務のプロンプト
注文業務の例として5つのパターンを紹介します。 作業時間の変化はストアで測定してください。
プロンプト1：複数条件による高額注文の優先振り分け
プロンプト1： 新しい注文が作成され、合計金額が$500以上で、顧客に 「wholesale」タグが付いておらず、配送先の国が[US, CA]のいずれかである場合： 注文に「priority-pick」と「vip-review」のタグを付け、 「Warehouse-East」に割り当てる。注文番号、顧客名、合計金額、 管理画面のリンクを添えてSlackの#ops-priorityに通知する。
実装の確認： 必要な注文フィールドと条件があるか確認します。タグ付けは対応していても、フルフィルメント拠点の割り当てとSlack送信には互換性のあるアプリやコネクターが必要な場合があります。両方を使用前に確認してください。
プロンプト2：不正リスクの高い注文を自動保留し、担当チームに通知
プロンプト2： Order risk analyzedトリガーが発火し、リスクレベルが「high」の場合： 注文に「fraud-review-hold」タグを付け、フルフィルメント注文を保留する。 リスク要因を列挙して注文メモを更新する。Send HTTP requestで 不正対策チームのSlack webhookに、注文番号、合計金額、 リスクスコア、顧客のメールアドレスを送信する。
実装の確認： リスクトリガーとフルフィルメント保留アクションが使えるか確認します。Slack WebhookにはHTTPアクションと対象プランが必要で、HTTPリクエストはGrow、Advanced、Plusに限られます。リスク情報がない場合もテストしてください。
プロンプト3：配送業者の確認を含む特急注文の迅速処理
プロンプト3： 新しい注文が作成され、配送方法の名称に 「Express」「Overnight」「Next Day」「2-Day」のいずれかが含まれる場合： 「rush-order」タグを付け、非公開メモに 「本日午後3時の締め切りまでに発送」と追加する。 注文番号と配送方法を添えてSlackの#ops-rushに通知する。 保存済みのSLAデータを使い、配送先への最速の配送業者を自動選択する。
実装の確認： 必要なフィールドが使える場合にのみ配送方法を条件判定できます。配送業者の選択には通常、対応するフルフィルメントアプリや連携が必要です。Flowの標準機能と想定せず、倉庫担当がメモを受け取り、使うことも確認してください。
プロンプト4：海外向け注文の通関書類を準備
プロンプト4： 新しい注文が作成され、配送先の国コードが「US」以外の場合： 「international」タグと、国別のタグ（例：「ship-CA」）を付ける。 HSコード、商業送り状、申告価格を列挙した非公開メモを追加する。 合計金額が$2,500を超える場合は「compliance-review-required」 タグを付け、コンプライアンス担当チームにメールを送信する。
実装の確認： 配送国、合計、タグ、メモ、メールの操作が使えるか確認します。Flowは通関書類を生成・検証しません。メモには自社の商品・輸出情報が必要です。
プロンプト5：住所確認が必要な注文を保留
プロンプト5： 新しい注文が作成されたら、次のいずれかに該当する場合に 検証を失敗とする：国が[US, CA, GB, AU, DE, FR, IT, ES]に 含まれない、郵便番号がその国の形式と一致しない、または 配送方法が「freight」で住所に「PO Box」が含まれる。 失敗した場合は「address-review-hold」タグを付け、 フルフィルメントの自動開始を一時停止し、注文情報と理由を サポートマネージャーにメールで送信する。
実装の確認： 国別ルールには郵便番号検証サービスや独自アプリが必要な場合があります。住所項目、保留、通知を確認してください。プロンプトだけですべての郵便番号形式は検証できません。
B. B2B・卸売向けプロンプト
Shopify FlowはBasic、Grow、Advanced、Plusで利用できます。 B2Bデータや利用できるアクションはストアやプランによって異なる場合があります。作成前に必要なフィールドとアクションを確認してください。
プロンプト6：企業ランク別にB2B注文を振り分け、営業担当者に割り当てる
プロンプト6： B2B企業に紐づく新しい注文が作成されたら、 Get Company dataでメタフィールドtier.levelを読み取る。 「enterprise」の場合は「b2b-enterprise」と 「priority-fulfillment」のタグを付け、 「Warehouse-East-Priority」に割り当てる。 営業担当者にメールとSlackのDMで通知する。 「mid-market」の場合は「b2b-mid」タグを付け、 通常のフルフィルメントに割り当てる。
実装の確認： FlowにはGet company dataがありますが、自社で使えるデータとメタフィールドを確認します。拠点割り当てや営業担当への連絡には対応するアプリやコネクターが必要な場合があります。
プロンプト7：Net 30の売掛金に関する定期アラート
プロンプト7：
毎日午前9時にスケジュールトリガーとGet order dataを使い、 利用可能な場合は支払い保留中かつ支払い条件がNet 30の注文を取得します。 各注文が作成から25日以上経過しているか確認し、注文番号、合計金額、 会社名を#finance-arに通知します。28日以上の注文は財務責任者に連絡します。
実装の確認： Get dataはストアのレコードを1回に最大100件取得します。注文フィルター、項目、スケジュール、通知アクションを確認してください。大きな集合には分割や別の設計が必要です。
プロンプト8：高額のB2B下書き注文を営業担当者の確認対象にする
プロンプト8： 商品の合計金額が$10,000を超え、顧客がB2B企業に 所属する下書き注文が作成された場合： 下書き注文に「needs-rep-review」タグを付け、 メモを「現在の社内価格ルールに基づき 営業担当者の確認待ち」に更新する。 Get Company dataで担当営業を調べ、 下書き注文のリンクと合計金額を記載した社内メールを送信する。
実装の確認： 下書き注文のトリガーと必要な明細データがあるか確認します。下書きの更新や営業へのメールにはアプリやAPIアクションが必要な場合があります。プロンプトで標準機能になるわけではありません。
プロンプト9：B2B注文を承認金額のしきい値に応じて振り分ける
プロンプト9： 新しいB2B注文が作成されたら、合計金額を企業の メタフィールドpolicies.approval_thresholdと比較する。 しきい値を超えた場合は自動でフルフィルメントを開始せず、 「awaiting-buyer-approval」タグを付ける。 しきい値を記載したメモを追加し、メタフィールド policies.primary_approver_emailに登録された承認権限のある 購入者に、承認を依頼するメールを送信する。
実装の確認： 指定した会社メタフィールドを読み、合計と比較できるか確認します。承認権限のある購入者への連絡やフルフィルメントの停止には、対応するアクションやアプリが必要な場合があります。
プロンプト10：B2B注文の作成時に営業担当者へ通知
プロンプト10： B2B注文の作成をきっかけに、 Get Company dataで担当営業のメールアドレスを調べる。 注文番号、合計金額、顧客名、管理画面の注文リンクを 記載した社内メールを担当者に送信する。 注文に「rep-notified」タグを付ける。
実装の確認： FlowにはGet company dataがあります。利用できる項目を確認します。営業への通知にはメールやコネクターが必要で、この注文作成トリガーだけでは後の変更を監視しません。
C. 在庫・フルフィルメントのプロンプト
複数拠点の在庫とフルフィルメントに関する5つの例です。 Flowで必要な移転トリガー、アクション、データフィールドを確認してください。
プロンプト11：ロケーション間で在庫不足の商品を自動移動
プロンプト11： 毎日午前6:00に「Warehouse-East」の在庫を照会し、 数量が10未満のSKUを抽出する。各SKUについて 「Warehouse-Central」に50点以上ある場合は、 Central → Eastへ30点移動する下書きの在庫移動を作成し、 「auto-replenish」タグを付け、Centralの責任者に Slackで通知する。Centralにも在庫がなければ購買チームにメールする。
実装の確認： 在庫取得と移動作成のアクションがあるか確認します。倉庫の拠点と移動承認の手順は、自社の設定に合わせる必要があります。
プロンプト12：在庫移動が発送可能になったら通知
プロンプト12： 在庫移動が「ready to ship」になったら、 メタフィールドops.contact_emailから移動先の運用担当者の メールアドレスを取得する。在庫移動ID、合計数量、 到着予定日、在庫移動のリンクを記載して担当者にメールする。 同じ内容をSlackの#warehouse-coordinationにも送信する。
実装の確認： 管理画面で在庫移動トリガーと担当者データを確認します。メールやSlackは設定済みアクション・コネクターによります。
プロンプト13：季節に応じて在庫アラートのしきい値を変更
プロンプト13： 毎日午前5:00に、当日が10月1日から12月31日までの 期間内であれば、在庫アラートのしきい値に2.5倍を適用する。 メタフィールド「base_threshold」がある各商品について、 調整後のしきい値＝基準値×倍率とする。 いずれかのロケーションで現在の在庫数が調整後のしきい値を 下回ったら、商品、ロケーション、現在の数量、調整後の しきい値をSlackの#inventory-peakに送信する。
実装の確認： スケジュール実行、商品データ取得、対応する比較・計算方法が必要です。記載した任意の日付計算や在庫クエリをFlowが実行できるとは限りません。使えるアクションを確認し、必要ならアプリや独自連携を使います。
プロンプト14：入荷待ちの商品と納期を顧客に通知
プロンプト14： 注文が作成され、いずれかの商品項目のフルフィルメント ロケーションで利用可能な在庫が0の場合： 「backorder」と「needs-lead-time-notice」のタグを付ける。 テンプレート「backorder-notification」を使い、 対象SKU、注文番号、7～10営業日の納期を記載した メールを顧客に送信する。入荷待ちのすべてのSKUを 列挙した非公開の倉庫向けメモを追加する。
実装の確認： 販売可能在庫、フルフィルメント拠点、配送予定がどう取得できるか確認します。顧客メールにはShopify Emailや連携アプリが必要な場合があります。仕入先や倉庫が守れる納期を使ってください。
プロンプト15：再入荷時に商品を自動公開して通知
プロンプト15： 在庫が0から1以上に更新されたら、商品を オンラインストアに公開し、「out-of-stock」タグを外す。 そのSKUの再入荷通知を登録した顧客向けに、 再入荷通知フローを起動する。商品に「restocked」 タグを付け、メタフィールド「restocked_at」に 現在のタイムスタンプを書き込む。
実装の確認： 在庫トリガー、商品公開、再入荷通知連携が使えるか確認します。有効化前にチャネルへの公開と顧客の対象条件をテストしてください。
D. 顧客体験のプロンプト
リピート購入に影響する購入後の対応を改善する、5つのプロンプトです。
プロンプト16：顧客生涯価値が高い顧客へのキャンセル後の維持メール
プロンプト16： Order canceledトリガーが発火し、その顧客の累計購入額が $1,000以上の場合：顧客に「post-cancel-retention」 タグを付ける。テンプレート「retention-followup」を使い、 15%のディスカウントコードを記載したメールを送信する。 注文番号、顧客生涯価値、キャンセル理由を記載した 社内メールをカスタマーサポートマネージャーに送信する。
実装の確認： 注文キャンセルトリガーと顧客項目を確認します。累計購入額の条件、割引発行、顧客メールには、追加データや対応アプリが必要な場合があります。
プロンプト17：配送完了後のレビュー依頼を自動化
プロンプト17： フルフィルメントステータスが「delivered」になったら 4日待ち、商品名と顧客の名を差し込んだテンプレート 「post-delivery-review-request」を使って、 件名「[Product Name]はいかがでしたか？」のメールを 顧客に送信する。「post-delivery-review-pending」 セグメントに追加する。合計金額が$300を超える場合は、 $20のストアクレジット特典を含める。
実装の確認： フルフィルメント・配送情報から信頼できる配達イベントを得られ、待機とメールを使えるか確認します。特典が利益率とレビューポリシーに合うか判断してください。
プロンプト18：休眠顧客への再購入キャンペーン（90日間注文なし）
プロンプト18： 毎日午前9:00に、各顧客の最終注文からの日数を計算する。 90日間注文がなく「win-back-sent」タグが付いていない顧客を 「win-back-90」セグメントに追加し、タグを付け、 再購入を促すメールを送信する。180日間注文がなく 「win-back-180」タグが付いていない顧客には、 20%のディスカウントメールを送信してタグを付ける。 365日以上注文がない顧客にはマーケティングを配信しない。
実装の確認： 定期的な休眠顧客フローには、利用できる顧客クエリ、日付、間隔の計算方法が必要です。顧客の対象条件とメールアクションを確認し、有効化前に少数でテストします。
プロンプト19：短時間の連続注文による不正を検知
プロンプト19： 新しい注文が作成され、同じメールアドレスから過去1時間に 3件以上の注文が行われている場合： そのメールアドレスによる過去1時間のすべての注文に 「velocity-fraud-flag」タグを付け、それぞれの フルフィルメントを保留する。メールアドレス、IP、 フラグが付いた注文の合計金額、注文間の住所比較を添えて、 Slackの#fraud-teamに緊急通知する。
実装の確認： 直近1時間の同じメールの注文数やIP・住所の比較には、不正対策アプリや外部データ保存先が必要な場合があります。1つのFlowトリガーで横断照会できると想定せず、誤検知をテストして不正対策方針に従います。
プロンプト20：フルフィルメントが滞った注文をエスカレーション
プロンプト20： 毎日午前8:00に、フルフィルメントステータスが 「in-progress」のまま5営業日を超え、 「backorder」「custom-build」「international」の いずれのタグも付いていない注文を取得する。 各注文に「fulfillment-stuck-review」タグを付け、 注文番号、滞留日数、ロケーション、顧客を 運用マネージャーにSlackで通知する。 8日を超えた場合は運用責任者にメールする。
実装の確認： フルフィルメントの経過時間を取得し、必要な日付処理を適用できるか確認します。週末・祝日の除外には独自計算やコネクターが必要な場合があります。カレンダーのルールをテストしてください。
AIが生成したFlowワークフローの確認方法
生成したフローは条件を省いたり、誤って設定したりする場合があります。 次の3点を確認してください。
- すべての条件を明示的に確認する。 ビジュアルエディターが各要件をどう表すか確認してください。
- 最近の実際の注文でテストする。 発火すべき注文と、発火すべきでない注文をそれぞれ1件選びます。
- 影響を見守れる時間帯に有効化する。 金曜日の午後5時ではなく、営業時間内に行います。最初の5～10回の実行を監視してください。
バージョン履歴で以前の版を確認します。復元は確認用の下書きを開き、稼働中のフローを即座に戻すものではありません。
よくある失敗
生成したフローで確認する3つの問題：
- メールアドレスやチャンネル名の固定入力。 担当者が退職してもワークフローが止まらないよう、IDや役割別のエイリアスを使ってください。
- メタフィールドの名前空間とキー。 各フィールドが存在し、選んだトリガーやアクションで使えるか確認します。条件が一致しない場合は実行を調べてください。
- 営業日を考慮しないスケジュールトリガーの日付計算。 「5日前」では月曜日に誤検知が起きます。営業日で計算してください。
Flowでできないことと、Revizeの役割
Flowはバックグラウンドの業務を自動化しますが、購入者が注文を編集するためのポータルは提供しません。 Revizeでは、フルフィルメント前かつ販売者が設定した期間内に、対象となる住所、数量、バリエーションの変更やキャンセルを購入者が行えます。商品追加、別商品への切り替え、割引適用、ストアクレジットでの返金はPro機能です。スタッフによる編集は開発中です。ポータルはRevizeのアプリブロックまたはメールのEdit Orderリンクから開きます。注文の対象条件はRevizeで確認してください。支払い条件だけで対応可否は判断できません。
まとめ
FlowとSidekickは自動化の作成を支援しますが、これらは検証済みのレシピではなく例です。一律に適用できる節約額も確認されていません。 利用可能なフィールドとアクションを使う低リスクのワークフローを選び、実行されるケースとされないケースをテストして、実測結果を自社の基準値と比較してください。
よくある質問
FlowとSidekickを使うにはShopify Plusが必要ですか？
いいえ。Shopify FlowはBasic、Grow、Advanced、Plusで利用できる無料アプリです。Send HTTP RequestアクションはGrow、Advanced、Plusに限られます。利用できるSidekick機能は管理画面で確認してください。
Sidekickが作成するFlowワークフローの信頼性はどの程度ですか？
生成したフローが要件を満たすと保証する公表された精度はありません。ビジュアルエディターでトリガー、条件、フィールド、アクションを確認し、実行されるべきケースと実行されるべきでないケースをテストしてください。
Flowはスケジュールに沿ってデータを取得できますか？
できます。Flowはスケジュールトリガー、Get dataアクション、ループに対応しています。Get dataアクションは最大100件のレコードを返します。現在のFlow資料で、使えるフィルターと項目を確認してください。
Sidekickはカスタムメタフィールドを使うワークフローを作成できますか？
依頼はできますが、選択したトリガーやアクションから名前空間、キー、値を利用できるか確認してください。メタフィールドを持つレコードでテストします。
SidekickとFlowをどう組み合わせますか？
SidekickにFlowのワークフロー作成や編集を依頼できます。トリガー、条件、アクション、フィールドを確認し、有効化前にテストしてください。トリガーが発生するとFlowが実行します。
Flowの自動化でどれくらい節約できますか？
一律に適用できる検証済みの数値はありません。具体的な業務について、有効化前後の作業時間、エラー率、問い合わせ量を測定してください。
生成したワークフローに問題があった場合はどうすればよいですか？
必要ならワークフローを無効にし、実行履歴を確認します。バージョンを復元すると下書きが開きます。再度有効にする前に内容を確認してテストしてください。稼働中のワークフローが即座に巻き戻るわけではありません。
FlowとSidekickの違いは何ですか？
Flowはトリガー、条件、アクションからなるワークフローを実行します。Sidekickは説明に基づくワークフローの作成や編集を支援します。提案された変更を確認し、テストしてください。
Flowの制限とプラン要件は何ですか？
無料のFlowアプリはBasic、Grow、Advanced、Plusで利用でき、使用上限はプランによって異なります。Send HTTP RequestはGrow、Advanced、Plusに限られます。各アクションの要件は最新のFlowドキュメントで確認してください。
Plusストアはどのワークフローから始めるべきですか？
利用可能なフィールドとアクションを使う低リスクのものから始めましょう。たとえば注文にタグを付け、社内通知を送るワークフローです。プロンプト1は、項目とコネクターが対応する場合のみ選択肢になります。拡張前にテストしてください。
関連記事
購入後の顧客対応にShopify Flowを活用する · Shopify注文編集の統計（2026年） · Shopifyで顧客が自分の注文を編集できるようにする方法（2026年）