Shopify FlowのAIプロンプト20選：Plus運用者向け（2026年）
Shopify FlowのAIプロンプト20選：Plus運用者向け（2026年）
Shopify FlowのAIプロンプト20選：Plus運用者向け（2026年）
Shopify Flow AI 2026: Plus運用担当者が15秒で知るべきこと
Flow AIは2026年に本番運用レベルに到達した。 5月9日のShopifyQLアクション、5月5日のバージョン履歴、3月24日のGet dataアクションでギャップが埋まった。
プロンプトがそのままワークフロー。 望む内容を平易な英語で書くだけで、Flowがトリガー、条件、アクションを組み立てる。出力はプロンプトの具体性に比例して拡張される。
以下の20の上級プロンプト は、運用領域ごとに整理済み: 注文ルーティング、B2B、在庫、顧客維持、不正対策。コピペ可能。
20以上のFlowワークフローを運用しているPlus加盟店は、年間5万～10万ドルをオペレーション工数で節約 できると、エージェンシーのベンチマークは示している。
有効化する前に必ずテストすること。 5月5日のバージョン履歴でワンクリックロールバックは可能だが、バグはテスト実行で先に見つけるべき。
Shopify Flow は2026年、Plusスタックの中で最もROIの高いツールになったが、ほとんどのPlus運用担当者はまだマーケティング用のおもちゃのように扱っている。2026年春の変更（Flow AIアシスタント、5月9日のShopifyQLアクション、5月5日のバージョン履歴）によって、Flowは本番運用向けのオペレーション層へと変わった。
20個の高度なShopify Flow AIプロンプトのライブラリ。各プロンプトは検証済みのネイティブトリガーとアクションのみを使用している。AI Assistantに貼り付け、ノートと照合して確認し、有効化する。より広い文脈については高度なShopify Flowワークフローを参照。
Flow AI Assistantへのアクセス方法
Flowを開く → 「New workflow」 → トリガー選択画面の上部にある「Create with AI」を探す。 ほとんどのPlusストアは2026年5月に利用可能になっている。
生成したワークフローを有効化する前に、2025年12月のテスト実行機能（ワークフローを開き、「Test」をクリック）を使う。実際のイベントに対してシミュレーションしつつ、アクションは実行しない。5月5日のバージョン履歴と組み合わせれば、ワンクリックでロールバックできる。
A. 注文運用プロンプト
大量処理の注文サイドに効く5つのパターン。 それぞれ、週あたり30～60分の運用時間を削減する。
プロンプト1: 複数条件の高額優先ルーティング
プロンプト：
新規注文が作成され、合計金額が500ドル以上、顧客が「wholesale」タグなし、
かつ配送先国が [US, CA] の場合: 「priority-pick」
と「vip-review」を付与し、「Warehouse-East」に割り当て、
注文番号、顧客名、合計金額、管理画面リンクを添えて #ops-priority にSlack通知する。
理由： AND条件と除外条件の組み合わせで、実運用のルーティング（高額、B2Bではない、国内配送）を処理できる。二重タグで、フルフィルメント作業と運用作業を分離できる。確認： Slack連携が接続済み、#ops-priority が存在する、「Warehouse-East」が実在するロケーション名である。
プロンプト2: 高リスク注文の自動保留と不正チーム通知
プロンプト：
Order risk analyzedトリガーが発火し、リスクレベルが「high」のとき:
注文に「fraud-review-hold」タグを付与し、フルフィルメントを保留し、
リスク要因を列挙した注文ノートを更新する; あなたの不正対策チームの
Slack Webhook に、注文番号、合計金額、リスクスコア、顧客メールを含めて HTTP リクエストを送信する。
理由： ネイティブの「Order risk analyzed」トリガーはすべての注文で発火する。Hold fulfillmentはネイティブ。SlackはHTTP Webhook経由。確認： Slack Webhookが保存済みで、不正対策チームに対応プレイブックがある。
プロンプト3: 配送会社チェック付きの急ぎ注文の優先処理
プロンプト：
新規注文が作成され、配送方法名に
「Express」「Overnight」「Next Day」または「2-Day」が含まれる場合: 「rush-order」
タグを付与し、プライベートノートに「Ship today by 3 PM cutoff」を追加する。#ops-rush に
注文番号と配送方法をSlack通知し、保存済みのSLAデータを使って
宛先に対する最速の配送会社を自動選択する。
理由： OR条件で高速配送のあらゆるバリエーションを拾える。3 PM cutoff のノートは倉庫へ届く。確認： 配送会社連携が自動選択をサポートしていること、倉庫がプライベート注文ノートを参照していること。
プロンプト4: 国際注文の通関準備
プロンプト：
新規注文が作成され、配送先の国コードが「US」以外の場合:
「international」タグ + 国別タグ（例: 「ship-CA」）を付与する。
HSコード、商業送り状、申告
価格を記載したプライベートノートを追加する。合計金額が2,500ドルを超える場合: 「compliance-review-required」タグを付与し、
コンプライアンスチームにメールする。
理由： 国別タグ付けと金額帯によるエスカレーションを組み合わせることで、ノートに倉庫へ必要書類が何かを明示できる。確認： 通関書類テンプレートが実際の輸出プロセスに合っている。
プロンプト5: 住所検証による保留
プロンプト：
新規注文が作成されたとき、次のいずれかに該当したら検証失敗にする: 国が
[US, CA, GB, AU, DE, FR, IT, ES] に含まれない、郵便番号が国の
パターンと一致しない、または住所に「PO Box」と「freight」配送が含まれる。失敗時: 「address-review-hold」
タグを付与し、フルフィルメントの自動開始を一時停止し、
注文と理由を添えてサポートマネージャーにメールする。
理由： 複数条件の検証により、最も多い購入後チケット（誤った住所）をフルフィルメント開始前に防げる。確認： 郵便番号のパターンが配送対象市場に合っていること、「freight」が実在の配送方法であること。
B. B2B & 卸売プロンプト
2026年4月2日のB2B展開以降、すべての有料プランでこれらを実行できる。 時間削減効果はスケールすると最速で積み上がる。
プロンプト6: 会社ティアと営業担当割り当てでB2Bを自動ルーティング
プロンプト：
B2B会社が紐づいた新規注文が作成されたとき: Get Company data を使って
metafield tier.level を読み取る。もし「enterprise」なら:
「b2b-enterprise」と「priority-fulfillment」を付与し、
「Warehouse-East-Priority」に割り当て、営業担当にメール + Slack DM で通知する。
もし「mid-market」なら: 「b2b-mid」タグを付与し、標準フルフィルメントに割り当てる。
理由： 2026年3月24日の「Get Company data」アクションを使ってmetafieldを読み取る。ティアベースのルーティングは、顧客リストをハードコードしなくてもスケールする。確認： tier metafieldの構造がFlowの検索方法と一致していること、営業担当の連絡先が会社レコードにあること。
プロンプト7: Net-30売掛金の経過日数アラートを定期送信
プロンプト：
毎日9:00 AMに Get analytics data: payment_status が
「pending」、payment_terms が「Net 30」、かつ25日以上前に作成された注文を取得する。各注文について:
会社名を検索し、#finance-ar に注文番号、合計金額、
経過日数、会社名をSlack通知する。28日経過時点で、財務マネージャーにメールする。
理由： 売掛金の滞留が深刻化する前に検知できる。2026年5月9日の Get analytics data アクションで、本来3つ必要だったワークフローが1つにまとまる。確認： Slackチャンネルが存在すること、財務チームが対応ワークフローを所有していること、B2B注文にpayment termsが付与されていること。
プロンプト8: 営業担当レビュー用にB2B下書き注文を自動フラグ
プロンプト：
下書き注文が作成され、明細合計が10,000ドル超 かつ
顧客がB2B会社に属している場合: 下書き注文に「needs-rep-review」タグを付与し、
下書き注文ノートを「2026年第2四半期の価格ルールに基づく営業担当レビュー待ち」に更新する。Get Company data を使って割り当て済みの営業
担当を見つけ、下書き注文リンクと
合計金額を添えて、その担当者に内部メールを送る。
理由： 高額なB2B下書きを、購買担当者にメールが届く前に担当者へ可視化できる。補足： Flowはネイティブでは割引を適用できないため、Send Admin API request で draftOrderUpdate を呼ぶか、手動で適用する。確認： すべてのB2B会社に営業担当のメールがあること、レビューSLAが文書化されていること。
プロンプト9: B2B注文の承認しきい値ルーティング
プロンプト：
新規のB2B注文が作成されたら、合計金額を会社のmetafield
policies.approval_threshold と比較する。超過している場合: 自動フルフィルメントを行わず、
「awaiting-buyer-approval」タグを付与し、しきい値の値を含むノートを追加し、
認可済み購買担当者（policies.primary_approver_email metafield から取得）に
承認を依頼するメールを送る。
理由： 各会社が自社のしきい値をmetafieldで設定できるため、Flow側で会社ごとのロジックを保守する必要がない。確認： すべてのB2B会社にapproval threshold と primary approver email の metafield が存在すること。
プロンプト10: 作成時のB2B注文担当者通知
プロンプト：
関連するB2B会社付きの新規注文が作成されたとき: Get Company data を使って
割り当て済み営業担当のメールを探し、
注文番号、合計金額、顧客名、
および管理画面の注文リンクを添えてその担当者に内部メールを送る; 注文に「rep-notified」タグを付与する。
理由： 各アカウントの注文が着地した瞬間に、担当者がすべて確認できる。Get Company data はネイティブ（2026年3月24日）。補足： これは作成時のみ発火するため、注文途中の変更通知には Flow Companion アプリが必要。確認： すべてのB2B会社レコードに営業担当メールがあること。
C. 在庫 & フルフィルメントプロンプト
2026年3月10日のピックアップ転送アップデートと4月30日の転送トリガーで使えるようになった、マルチロケーション在庫オーケストレーションの5パターン。
プロンプト11: ロケーション間の低在庫自動転送
プロンプト：
毎日6:00 AMに、"Warehouse-East" の在庫を照会し、数量が10未満のものを探す。
各低在庫SKUについて: 「Warehouse-Central」に50個以上あれば、
Central → East に30個のDRAFT転送を作成し、「auto-replenish」タグを付与し、
CentralのマネージャーにSlack通知する。Centralが在庫切れなら、購買チームにメールする。
理由： 欠品が起きる前に事前再配分する。DRAFT（自動出荷ではない）にすることで、倉庫側にレビュー工程を持たせられる。確認： 転送作成がデフォルトでドラフトになること、ロケーション名が一致していること。
プロンプト12: 出荷準備完了の在庫転送通知
プロンプト：
在庫転送が「ready to ship」にマークされたとき: 宛先の
ops連絡先メールを metafield ops.contact_email から取得する。
その連絡先に、転送ID、総数量、到着予定日、
および転送リンクをメールする。あわせて同内容を #warehouse-coordination にSlack通知する。
理由： 2026年4月30日の転送準備完了トリガーにより、倉庫間の手動引き継ぎメールが不要になる。確認： 受け入れ先ロケーションすべてでops連絡先metafieldが設定されていること。
プロンプト13: 季節要因を加味した在庫しきい値倍率
プロンプト：
毎日5:00 AMに、今日が10月1日から12月31日の間なら、在庫アラートしきい値に2.5倍の
倍率を適用する。各プロダクトについて、
metafield 「base_threshold」があれば: adjusted = base × multiplier。いずれかのロケーションで現在の
在庫が adjusted を下回ったら、#inventory-peak に
プロダクト、ロケーション、現在数量、調整後しきい値をSlack通知する。
理由： 静的なしきい値ではピーク需要を過小評価する。2.5倍にすることでBFCMの欠品パターンを防げる。スケジュールトリガー + metafield計算は2026年に新しく追加された。確認： 監視対象のすべてのプロダクトに「base_threshold」metafieldがあること、倍率が過去のピーク比率に合っていること。
プロンプト14: リードタイム付きのバックオーダー顧客通知
プロンプト：
注文が作成され、いずれかの明細のフルフィルメント先で利用可能在庫が0の場合: 「backorder」と 「needs-lead-time-notice」
タグを付与し、
テンプレート「backorder-notification」を使って、影響を受ける
SKU、注文番号、7～10営業日のリードタイムを含めて顧客にメールする; すべてのバックオーダーSKUを列挙したプライベート
倉庫ノートを追加する。
理由： 顧客がサポートへ連絡する前に期待値を設定でき、最も多い種類のチケットを減らせる。確認： メールテンプレートが存在すること、リードタイムが現在のベンダーSLAに合っていること。
プロンプト15: 通知トリガー付き再入荷の自動公開
プロンプト：
在庫が0から1以上に更新されたら: オンラインストアに
商品を公開し、「out-of-stock」タグを削除し、そのSKUを
事前登録済み顧客向けの再入荷通知フローを起動する。商品に「restocked」タグを付け、metafield 「restocked_at」
に現在のタイムスタンプを書き込む。
理由： かつて商品管理とマーケティングの間で手動調整が必要だった公開と通知の連鎖を自動化できる。確認： 再入荷通知フローが設定済みであること、販売チャネルの公開ロジックがストアに合っていること。
D. 顧客体験プロンプト
リピート購入を生む購入後のギャップを埋める5つのプロンプト。
プロンプト16: 高LTV顧客向けのキャンセル後リテンションメール
プロンプト：
Order canceledトリガーが発火し、かつ顧客の累計
支出が1,000ドル以上の場合: 顧客に「post-cancel-retention」タグを付与し、
15%割引コード付きでテンプレート「retention-followup」を使ったメールを送信する。CSマネージャーに内部メールを送り、注文
番号、顧客LTV、キャンセル理由を含める。
理由： Order canceled はネイティブトリガーで、Get customer data で累計支出を取得できる。補足： これは反応型の救済であり、上流でキャンセルを防ぐには購入者向けのセルフサービスが必要。確認： メールテンプレートが存在すること、コード「RETAIN15」が有効であること。
プロンプト17: 配送後レビュー依頼の自動化
プロンプト：
フルフィルメントステータス = 「delivered」のとき: 4日待ってから、
件名「How did the [Product Name] work out?」で顧客にメールする。
テンプレート「post-delivery-review-request」を使い、商品名と
名で差し込む。セグメント「post-delivery-review-pending」に追加する。合計金額が
300ドルを超える場合は、20ドル分のストアクレジット特典を含める。
理由： 4日遅らせることで、顧客は商品を使っているが、まだ記憶が新しいタイミングで届く。段階的な特典によりコストを抑えられる。確認： メールテンプレートが存在すること、レビュー追跡がcustomer eventsで設定されていること。
プロンプト18: ウィンバックキャンペーンのトリガー（90日非アクティブ）
プロンプト：
毎日9:00 AMに、各顧客の最終注文から何日経ったかを計算する。
90日非アクティブで「win-back-sent」タグがない場合: 「win-back-90」
セグメントに追加し、タグを付与し、ウィンバックメールを起動する。180日非アクティブ
で「win-back-180」タグがない場合: 20%割引メールを送信し、タグを付与する。365日以上
非アクティブの場合: マーケティング配信から除外する。
理由： 以前はKlaviyo + カスタムロジックが必要だった3段階自動化を、今は1つのFlowワークフローで実現できる。確認： ティアごとにウィンバックメールフローが存在すること、「WINBACK20」コードが有効で追跡されていること。
プロンプト19: 速度ベースの不正検知
プロンプト：
新規注文が作成され、同じメールアドレスが直近1時間で3件以上の注文を出している場合: そのメールの直近1時間のすべての注文に
「velocity-fraud-flag」タグを付与し、各注文のフルフィルメントを保留し、#fraud-team に
メールアドレス、IP、フラグ付き合計金額、注文間の住所比較を含めて緊急Slack通知する。
理由： 速度ベースの検知は、単一注文のリスクチェックでは見逃すカードテストパターンを捕捉できる。注文間比較で不正シグナルを裏付けられる。確認： 不正対策チームに文書化されたプレイブックがあること、フラグ時のフルフィルメント保留がポリシーであること。
プロンプト20: フルフィルメント滞留のエスカレーション
プロンプト：
毎日8:00 AMに、fulfillment_status =
「in-progress」が5営業日を超え、かつ「backorder」、
「custom-build」、または「international」タグが付いていない注文を照会する。各注文について:
「fulfillment-stuck-review」タグを付与し、注文番号、
滞留日数、ロケーション、顧客を添えて ops manager にSlack通知する。8日超では、ops lead にメールする。
理由： チケット化する前に滞留注文を可視化できる。営業日フィルターにより月曜の誤検知を防げる。確認： 営業日計算が運用カレンダーと一致していること（週末と祝日を除外）。
AI生成Flowワークフローの検証方法
生成されたワークフローは、正しいように見えても実際には正しくないことが多い。 3つの確認ポイント:
すべての条件を明示的に読む。 AIは長いプロンプトで条件を反転させることがある。ビジュアルエディタで確認する。
直近の実注文に対してテストを実行する。 発火すべきものを1件、発火すべきでないものを1件選ぶ。
影響が小さい時間帯に有効化する。 金曜の午後5時ではなく、営業時間中に行う。最初の5～10回の実行を監視する。
5月5日のバージョン履歴でワンクリックロールバックが可能。バグはテスト実行で見つける。
よくある失敗パターン
Flow AI導入で共通する4つのパターン:
メールアドレスやチャンネル名をハードコードする。 人が退職してもワークフローが壊れないよう、IDと役割エイリアスを使う。
metafield namespaceの記載漏れ。 存在しないmetafieldを参照するプロンプトは静かに失敗する。有効化前に監査する。
営業日を意識しないスケジュールトリガーの日時計算。 「5 days ago」は月曜の誤検知を発生させる。営業日計算を使う。
Flowが止まるところ（そしてRevizeが入るところ）
Flowはサーバー側の自動化を担い、購入者向けの購入後編集は担わない。 顧客がチェックアウト後に住所を変えたい、あるいはバリアントを交換したい場合、Flowだけでは顧客自身に変更させることはできない。そのギャップを埋めるのがRevizeだ。B2Bの支払い条件付き注文を含む、購入後のセルフサービス編集を提供する。Plus運用担当者は、同じワークフロー上でFlow（サーバー側）とRevize（購入者側）を組み合わせる。
結論
Shopify Flow AI Assistantは2026年に本番運用レベルとなり、このプロンプトライブラリこそが運用インパクトの本体だ。 上の20の検証済みプロンプトは、週30～60時間の手作業を置き換える。20以上のワークフローを運用するPlus加盟店は、年間5万～10万ドルを節約できる。
Flowをマーケティング用途だけで使っているPlus運用担当者へ: まずは注文運用とB2Bから始めよう。3つ選び、テストし、有効化する。初月で元が取れる。
エージェンシーへ: プロンプトライブラリのワークフローを標準化すること。出力が安定し、バージョン履歴で監査証跡も残る。
今週やること: Flowを開き、3つのプロンプトを選び、生成し、テスト実行し、有効化する。ライブラリを社内で文書化する。
よくある質問
Flow AI Assistantを使うにはShopify Plusが必要ですか？
FlowはAdvancedとPlusで利用できます。 AI Assistantは2026年第1四半期までに展開され、今ではほとんどのストアで利用可能です。「Create with AI」が表示されない場合は、Merchant Success Managerに連絡してください。
AI生成のFlowワークフローの精度はどのくらいですか？
通常は構造的には正しいですが、長いプロンプトでは条件ロジックが反転することがあります。 ビジュアルエディタで条件を確認し、直近の注文でテストを実行してください。
2026年5月9日のShopifyQL Flowアップデートとは何ですか？
Flowに「Get analytics data」アクションが追加され、ShopifyQL経由でライブデータを取得できます。 上の売掛金経過、ウィンバック、在庫しきい値のプロンプトでこれを使っています。
Flow AIはカスタムmetafieldを参照するワークフローを書けますか？
はい、ワークフロー実行前にnamespaceとkeyが存在していれば可能です。 存在しないmetafieldは条件失敗を静かに引き起こします。
SidekickとFlowはどう組み合わせればいいですか？
SidekickはShopifyQLを生成し、Flowはそれを「Get analytics data」で消費します。 Sidekickが分析上の問いに答え、Flowがアクションを実行します。
Plus加盟店はFlow自動化で実際どれくらい節約できますか？
20以上のワークフローを運用するPlus加盟店は、オペレーション工数で年間5万～10万ドルを節約できます。 不正検知だけでもチャージバックを40～60%削減でき、加盟店あたり年間1.2万～2.4万ドルの価値があります。
AI生成ワークフローに本番環境でバグがあったらどうなりますか？
バージョン履歴を開き、前のバージョンを見つけて、Restoreをクリックします。 2026年5月5日以降は、スタッフとタイムスタンプ付きで変更がすべて記録されます。ロールバックは即時です。
Flow AI AssistantとSidekickの違いは何ですか？
Flow AIはワークフローを作成し、Sidekickは分析質問に答えてShopifyQLを生成します。 SidekickがShopifyQLを作り、Flowがアクションを取ります。
実行できるFlowワークフロー数に制限はありますか？
いいえ。FlowはAdvancedとPlusで無料で、実行ごとの課金もありません。 Flowから呼び出す外部連携には別料金がかかる場合があります。
Plus運用担当者が最初に始めるべきFlowワークフローは何ですか？
高額注文をしきい値で自動ルーティングするもの（プロンプト1）です。 低リスクで可視性が高く、複雑な構築の前にAI出力を検証できます。
関連記事
上のShopify Flow AIプロンプトと組み合わせるとよい記事:
Advanced Shopify Flow Workflows 2025: AIではないパターン
Shopify Order Management 2026: Flowが動く運用レイヤー
Shopify B2B 2026 Complete Guide: プロンプト6～10の文脈
How to Edit an Order on Shopify: Flowが止まるところ
Shopify Advanced to Plus 2026 Playbook: Shopify flow ai prompts が価値を引き出すアップグレード戦略
Shopify Flow AI 2026: Plus運用担当者が15秒で知るべきこと
Flow AIは2026年に本番運用レベルに到達した。 5月9日のShopifyQLアクション、5月5日のバージョン履歴、3月24日のGet dataアクションでギャップが埋まった。
プロンプトがそのままワークフロー。 望む内容を平易な英語で書くだけで、Flowがトリガー、条件、アクションを組み立てる。出力はプロンプトの具体性に比例して拡張される。
以下の20の上級プロンプト は、運用領域ごとに整理済み: 注文ルーティング、B2B、在庫、顧客維持、不正対策。コピペ可能。
20以上のFlowワークフローを運用しているPlus加盟店は、年間5万～10万ドルをオペレーション工数で節約 できると、エージェンシーのベンチマークは示している。
有効化する前に必ずテストすること。 5月5日のバージョン履歴でワンクリックロールバックは可能だが、バグはテスト実行で先に見つけるべき。
Shopify Flow は2026年、Plusスタックの中で最もROIの高いツールになったが、ほとんどのPlus運用担当者はまだマーケティング用のおもちゃのように扱っている。2026年春の変更（Flow AIアシスタント、5月9日のShopifyQLアクション、5月5日のバージョン履歴）によって、Flowは本番運用向けのオペレーション層へと変わった。
20個の高度なShopify Flow AIプロンプトのライブラリ。各プロンプトは検証済みのネイティブトリガーとアクションのみを使用している。AI Assistantに貼り付け、ノートと照合して確認し、有効化する。より広い文脈については高度なShopify Flowワークフローを参照。
Flow AI Assistantへのアクセス方法
Flowを開く → 「New workflow」 → トリガー選択画面の上部にある「Create with AI」を探す。 ほとんどのPlusストアは2026年5月に利用可能になっている。
生成したワークフローを有効化する前に、2025年12月のテスト実行機能（ワークフローを開き、「Test」をクリック）を使う。実際のイベントに対してシミュレーションしつつ、アクションは実行しない。5月5日のバージョン履歴と組み合わせれば、ワンクリックでロールバックできる。
A. 注文運用プロンプト
大量処理の注文サイドに効く5つのパターン。 それぞれ、週あたり30～60分の運用時間を削減する。
プロンプト1: 複数条件の高額優先ルーティング
プロンプト：
新規注文が作成され、合計金額が500ドル以上、顧客が「wholesale」タグなし、
かつ配送先国が [US, CA] の場合: 「priority-pick」
と「vip-review」を付与し、「Warehouse-East」に割り当て、
注文番号、顧客名、合計金額、管理画面リンクを添えて #ops-priority にSlack通知する。
理由： AND条件と除外条件の組み合わせで、実運用のルーティング（高額、B2Bではない、国内配送）を処理できる。二重タグで、フルフィルメント作業と運用作業を分離できる。確認： Slack連携が接続済み、#ops-priority が存在する、「Warehouse-East」が実在するロケーション名である。
プロンプト2: 高リスク注文の自動保留と不正チーム通知
プロンプト：
Order risk analyzedトリガーが発火し、リスクレベルが「high」のとき:
注文に「fraud-review-hold」タグを付与し、フルフィルメントを保留し、
リスク要因を列挙した注文ノートを更新する; あなたの不正対策チームの
Slack Webhook に、注文番号、合計金額、リスクスコア、顧客メールを含めて HTTP リクエストを送信する。
理由： ネイティブの「Order risk analyzed」トリガーはすべての注文で発火する。Hold fulfillmentはネイティブ。SlackはHTTP Webhook経由。確認： Slack Webhookが保存済みで、不正対策チームに対応プレイブックがある。
プロンプト3: 配送会社チェック付きの急ぎ注文の優先処理
プロンプト：
新規注文が作成され、配送方法名に
「Express」「Overnight」「Next Day」または「2-Day」が含まれる場合: 「rush-order」
タグを付与し、プライベートノートに「Ship today by 3 PM cutoff」を追加する。#ops-rush に
注文番号と配送方法をSlack通知し、保存済みのSLAデータを使って
宛先に対する最速の配送会社を自動選択する。
理由： OR条件で高速配送のあらゆるバリエーションを拾える。3 PM cutoff のノートは倉庫へ届く。確認： 配送会社連携が自動選択をサポートしていること、倉庫がプライベート注文ノートを参照していること。
プロンプト4: 国際注文の通関準備
プロンプト：
新規注文が作成され、配送先の国コードが「US」以外の場合:
「international」タグ + 国別タグ（例: 「ship-CA」）を付与する。
HSコード、商業送り状、申告
価格を記載したプライベートノートを追加する。合計金額が2,500ドルを超える場合: 「compliance-review-required」タグを付与し、
コンプライアンスチームにメールする。
理由： 国別タグ付けと金額帯によるエスカレーションを組み合わせることで、ノートに倉庫へ必要書類が何かを明示できる。確認： 通関書類テンプレートが実際の輸出プロセスに合っている。
プロンプト5: 住所検証による保留
プロンプト：
新規注文が作成されたとき、次のいずれかに該当したら検証失敗にする: 国が
[US, CA, GB, AU, DE, FR, IT, ES] に含まれない、郵便番号が国の
パターンと一致しない、または住所に「PO Box」と「freight」配送が含まれる。失敗時: 「address-review-hold」
タグを付与し、フルフィルメントの自動開始を一時停止し、
注文と理由を添えてサポートマネージャーにメールする。
理由： 複数条件の検証により、最も多い購入後チケット（誤った住所）をフルフィルメント開始前に防げる。確認： 郵便番号のパターンが配送対象市場に合っていること、「freight」が実在の配送方法であること。
B. B2B & 卸売プロンプト
2026年4月2日のB2B展開以降、すべての有料プランでこれらを実行できる。 時間削減効果はスケールすると最速で積み上がる。
プロンプト6: 会社ティアと営業担当割り当てでB2Bを自動ルーティング
プロンプト：
B2B会社が紐づいた新規注文が作成されたとき: Get Company data を使って
metafield tier.level を読み取る。もし「enterprise」なら:
「b2b-enterprise」と「priority-fulfillment」を付与し、
「Warehouse-East-Priority」に割り当て、営業担当にメール + Slack DM で通知する。
もし「mid-market」なら: 「b2b-mid」タグを付与し、標準フルフィルメントに割り当てる。
理由： 2026年3月24日の「Get Company data」アクションを使ってmetafieldを読み取る。ティアベースのルーティングは、顧客リストをハードコードしなくてもスケールする。確認： tier metafieldの構造がFlowの検索方法と一致していること、営業担当の連絡先が会社レコードにあること。
プロンプト7: Net-30売掛金の経過日数アラートを定期送信
プロンプト：
毎日9:00 AMに Get analytics data: payment_status が
「pending」、payment_terms が「Net 30」、かつ25日以上前に作成された注文を取得する。各注文について:
会社名を検索し、#finance-ar に注文番号、合計金額、
経過日数、会社名をSlack通知する。28日経過時点で、財務マネージャーにメールする。
理由： 売掛金の滞留が深刻化する前に検知できる。2026年5月9日の Get analytics data アクションで、本来3つ必要だったワークフローが1つにまとまる。確認： Slackチャンネルが存在すること、財務チームが対応ワークフローを所有していること、B2B注文にpayment termsが付与されていること。
プロンプト8: 営業担当レビュー用にB2B下書き注文を自動フラグ
プロンプト：
下書き注文が作成され、明細合計が10,000ドル超 かつ
顧客がB2B会社に属している場合: 下書き注文に「needs-rep-review」タグを付与し、
下書き注文ノートを「2026年第2四半期の価格ルールに基づく営業担当レビュー待ち」に更新する。Get Company data を使って割り当て済みの営業
担当を見つけ、下書き注文リンクと
合計金額を添えて、その担当者に内部メールを送る。
理由： 高額なB2B下書きを、購買担当者にメールが届く前に担当者へ可視化できる。補足： Flowはネイティブでは割引を適用できないため、Send Admin API request で draftOrderUpdate を呼ぶか、手動で適用する。確認： すべてのB2B会社に営業担当のメールがあること、レビューSLAが文書化されていること。
プロンプト9: B2B注文の承認しきい値ルーティング
プロンプト：
新規のB2B注文が作成されたら、合計金額を会社のmetafield
policies.approval_threshold と比較する。超過している場合: 自動フルフィルメントを行わず、
「awaiting-buyer-approval」タグを付与し、しきい値の値を含むノートを追加し、
認可済み購買担当者（policies.primary_approver_email metafield から取得）に
承認を依頼するメールを送る。
理由： 各会社が自社のしきい値をmetafieldで設定できるため、Flow側で会社ごとのロジックを保守する必要がない。確認： すべてのB2B会社にapproval threshold と primary approver email の metafield が存在すること。
プロンプト10: 作成時のB2B注文担当者通知
プロンプト：
関連するB2B会社付きの新規注文が作成されたとき: Get Company data を使って
割り当て済み営業担当のメールを探し、
注文番号、合計金額、顧客名、
および管理画面の注文リンクを添えてその担当者に内部メールを送る; 注文に「rep-notified」タグを付与する。
理由： 各アカウントの注文が着地した瞬間に、担当者がすべて確認できる。Get Company data はネイティブ（2026年3月24日）。補足： これは作成時のみ発火するため、注文途中の変更通知には Flow Companion アプリが必要。確認： すべてのB2B会社レコードに営業担当メールがあること。
C. 在庫 & フルフィルメントプロンプト
2026年3月10日のピックアップ転送アップデートと4月30日の転送トリガーで使えるようになった、マルチロケーション在庫オーケストレーションの5パターン。
プロンプト11: ロケーション間の低在庫自動転送
プロンプト：
毎日6:00 AMに、"Warehouse-East" の在庫を照会し、数量が10未満のものを探す。
各低在庫SKUについて: 「Warehouse-Central」に50個以上あれば、
Central → East に30個のDRAFT転送を作成し、「auto-replenish」タグを付与し、
CentralのマネージャーにSlack通知する。Centralが在庫切れなら、購買チームにメールする。
理由： 欠品が起きる前に事前再配分する。DRAFT（自動出荷ではない）にすることで、倉庫側にレビュー工程を持たせられる。確認： 転送作成がデフォルトでドラフトになること、ロケーション名が一致していること。
プロンプト12: 出荷準備完了の在庫転送通知
プロンプト：
在庫転送が「ready to ship」にマークされたとき: 宛先の
ops連絡先メールを metafield ops.contact_email から取得する。
その連絡先に、転送ID、総数量、到着予定日、
および転送リンクをメールする。あわせて同内容を #warehouse-coordination にSlack通知する。
理由： 2026年4月30日の転送準備完了トリガーにより、倉庫間の手動引き継ぎメールが不要になる。確認： 受け入れ先ロケーションすべてでops連絡先metafieldが設定されていること。
プロンプト13: 季節要因を加味した在庫しきい値倍率
プロンプト：
毎日5:00 AMに、今日が10月1日から12月31日の間なら、在庫アラートしきい値に2.5倍の
倍率を適用する。各プロダクトについて、
metafield 「base_threshold」があれば: adjusted = base × multiplier。いずれかのロケーションで現在の
在庫が adjusted を下回ったら、#inventory-peak に
プロダクト、ロケーション、現在数量、調整後しきい値をSlack通知する。
理由： 静的なしきい値ではピーク需要を過小評価する。2.5倍にすることでBFCMの欠品パターンを防げる。スケジュールトリガー + metafield計算は2026年に新しく追加された。確認： 監視対象のすべてのプロダクトに「base_threshold」metafieldがあること、倍率が過去のピーク比率に合っていること。
プロンプト14: リードタイム付きのバックオーダー顧客通知
プロンプト：
注文が作成され、いずれかの明細のフルフィルメント先で利用可能在庫が0の場合: 「backorder」と 「needs-lead-time-notice」
タグを付与し、
テンプレート「backorder-notification」を使って、影響を受ける
SKU、注文番号、7～10営業日のリードタイムを含めて顧客にメールする; すべてのバックオーダーSKUを列挙したプライベート
倉庫ノートを追加する。
理由： 顧客がサポートへ連絡する前に期待値を設定でき、最も多い種類のチケットを減らせる。確認： メールテンプレートが存在すること、リードタイムが現在のベンダーSLAに合っていること。
プロンプト15: 通知トリガー付き再入荷の自動公開
プロンプト：
在庫が0から1以上に更新されたら: オンラインストアに
商品を公開し、「out-of-stock」タグを削除し、そのSKUを
事前登録済み顧客向けの再入荷通知フローを起動する。商品に「restocked」タグを付け、metafield 「restocked_at」
に現在のタイムスタンプを書き込む。
理由： かつて商品管理とマーケティングの間で手動調整が必要だった公開と通知の連鎖を自動化できる。確認： 再入荷通知フローが設定済みであること、販売チャネルの公開ロジックがストアに合っていること。
D. 顧客体験プロンプト
リピート購入を生む購入後のギャップを埋める5つのプロンプト。
プロンプト16: 高LTV顧客向けのキャンセル後リテンションメール
プロンプト：
Order canceledトリガーが発火し、かつ顧客の累計
支出が1,000ドル以上の場合: 顧客に「post-cancel-retention」タグを付与し、
15%割引コード付きでテンプレート「retention-followup」を使ったメールを送信する。CSマネージャーに内部メールを送り、注文
番号、顧客LTV、キャンセル理由を含める。
理由： Order canceled はネイティブトリガーで、Get customer data で累計支出を取得できる。補足： これは反応型の救済であり、上流でキャンセルを防ぐには購入者向けのセルフサービスが必要。確認： メールテンプレートが存在すること、コード「RETAIN15」が有効であること。
プロンプト17: 配送後レビュー依頼の自動化
プロンプト：
フルフィルメントステータス = 「delivered」のとき: 4日待ってから、
件名「How did the [Product Name] work out?」で顧客にメールする。
テンプレート「post-delivery-review-request」を使い、商品名と
名で差し込む。セグメント「post-delivery-review-pending」に追加する。合計金額が
300ドルを超える場合は、20ドル分のストアクレジット特典を含める。
理由： 4日遅らせることで、顧客は商品を使っているが、まだ記憶が新しいタイミングで届く。段階的な特典によりコストを抑えられる。確認： メールテンプレートが存在すること、レビュー追跡がcustomer eventsで設定されていること。
プロンプト18: ウィンバックキャンペーンのトリガー（90日非アクティブ）
プロンプト：
毎日9:00 AMに、各顧客の最終注文から何日経ったかを計算する。
90日非アクティブで「win-back-sent」タグがない場合: 「win-back-90」
セグメントに追加し、タグを付与し、ウィンバックメールを起動する。180日非アクティブ
で「win-back-180」タグがない場合: 20%割引メールを送信し、タグを付与する。365日以上
非アクティブの場合: マーケティング配信から除外する。
理由： 以前はKlaviyo + カスタムロジックが必要だった3段階自動化を、今は1つのFlowワークフローで実現できる。確認： ティアごとにウィンバックメールフローが存在すること、「WINBACK20」コードが有効で追跡されていること。
プロンプト19: 速度ベースの不正検知
プロンプト：
新規注文が作成され、同じメールアドレスが直近1時間で3件以上の注文を出している場合: そのメールの直近1時間のすべての注文に
「velocity-fraud-flag」タグを付与し、各注文のフルフィルメントを保留し、#fraud-team に
メールアドレス、IP、フラグ付き合計金額、注文間の住所比較を含めて緊急Slack通知する。
理由： 速度ベースの検知は、単一注文のリスクチェックでは見逃すカードテストパターンを捕捉できる。注文間比較で不正シグナルを裏付けられる。確認： 不正対策チームに文書化されたプレイブックがあること、フラグ時のフルフィルメント保留がポリシーであること。
プロンプト20: フルフィルメント滞留のエスカレーション
プロンプト：
毎日8:00 AMに、fulfillment_status =
「in-progress」が5営業日を超え、かつ「backorder」、
「custom-build」、または「international」タグが付いていない注文を照会する。各注文について:
「fulfillment-stuck-review」タグを付与し、注文番号、
滞留日数、ロケーション、顧客を添えて ops manager にSlack通知する。8日超では、ops lead にメールする。
理由： チケット化する前に滞留注文を可視化できる。営業日フィルターにより月曜の誤検知を防げる。確認： 営業日計算が運用カレンダーと一致していること（週末と祝日を除外）。
AI生成Flowワークフローの検証方法
生成されたワークフローは、正しいように見えても実際には正しくないことが多い。 3つの確認ポイント:
すべての条件を明示的に読む。 AIは長いプロンプトで条件を反転させることがある。ビジュアルエディタで確認する。
直近の実注文に対してテストを実行する。 発火すべきものを1件、発火すべきでないものを1件選ぶ。
影響が小さい時間帯に有効化する。 金曜の午後5時ではなく、営業時間中に行う。最初の5～10回の実行を監視する。
5月5日のバージョン履歴でワンクリックロールバックが可能。バグはテスト実行で見つける。
よくある失敗パターン
Flow AI導入で共通する4つのパターン:
メールアドレスやチャンネル名をハードコードする。 人が退職してもワークフローが壊れないよう、IDと役割エイリアスを使う。
metafield namespaceの記載漏れ。 存在しないmetafieldを参照するプロンプトは静かに失敗する。有効化前に監査する。
営業日を意識しないスケジュールトリガーの日時計算。 「5 days ago」は月曜の誤検知を発生させる。営業日計算を使う。
Flowが止まるところ（そしてRevizeが入るところ）
Flowはサーバー側の自動化を担い、購入者向けの購入後編集は担わない。 顧客がチェックアウト後に住所を変えたい、あるいはバリアントを交換したい場合、Flowだけでは顧客自身に変更させることはできない。そのギャップを埋めるのがRevizeだ。B2Bの支払い条件付き注文を含む、購入後のセルフサービス編集を提供する。Plus運用担当者は、同じワークフロー上でFlow（サーバー側）とRevize（購入者側）を組み合わせる。
結論
Shopify Flow AI Assistantは2026年に本番運用レベルとなり、このプロンプトライブラリこそが運用インパクトの本体だ。 上の20の検証済みプロンプトは、週30～60時間の手作業を置き換える。20以上のワークフローを運用するPlus加盟店は、年間5万～10万ドルを節約できる。
Flowをマーケティング用途だけで使っているPlus運用担当者へ: まずは注文運用とB2Bから始めよう。3つ選び、テストし、有効化する。初月で元が取れる。
エージェンシーへ: プロンプトライブラリのワークフローを標準化すること。出力が安定し、バージョン履歴で監査証跡も残る。
今週やること: Flowを開き、3つのプロンプトを選び、生成し、テスト実行し、有効化する。ライブラリを社内で文書化する。
よくある質問
Flow AI Assistantを使うにはShopify Plusが必要ですか？
FlowはAdvancedとPlusで利用できます。 AI Assistantは2026年第1四半期までに展開され、今ではほとんどのストアで利用可能です。「Create with AI」が表示されない場合は、Merchant Success Managerに連絡してください。
AI生成のFlowワークフローの精度はどのくらいですか？
通常は構造的には正しいですが、長いプロンプトでは条件ロジックが反転することがあります。 ビジュアルエディタで条件を確認し、直近の注文でテストを実行してください。
2026年5月9日のShopifyQL Flowアップデートとは何ですか？
Flowに「Get analytics data」アクションが追加され、ShopifyQL経由でライブデータを取得できます。 上の売掛金経過、ウィンバック、在庫しきい値のプロンプトでこれを使っています。
Flow AIはカスタムmetafieldを参照するワークフローを書けますか？
はい、ワークフロー実行前にnamespaceとkeyが存在していれば可能です。 存在しないmetafieldは条件失敗を静かに引き起こします。
SidekickとFlowはどう組み合わせればいいですか？
SidekickはShopifyQLを生成し、Flowはそれを「Get analytics data」で消費します。 Sidekickが分析上の問いに答え、Flowがアクションを実行します。
Plus加盟店はFlow自動化で実際どれくらい節約できますか？
20以上のワークフローを運用するPlus加盟店は、オペレーション工数で年間5万～10万ドルを節約できます。 不正検知だけでもチャージバックを40～60%削減でき、加盟店あたり年間1.2万～2.4万ドルの価値があります。
AI生成ワークフローに本番環境でバグがあったらどうなりますか？
バージョン履歴を開き、前のバージョンを見つけて、Restoreをクリックします。 2026年5月5日以降は、スタッフとタイムスタンプ付きで変更がすべて記録されます。ロールバックは即時です。
Flow AI AssistantとSidekickの違いは何ですか？
Flow AIはワークフローを作成し、Sidekickは分析質問に答えてShopifyQLを生成します。 SidekickがShopifyQLを作り、Flowがアクションを取ります。
実行できるFlowワークフロー数に制限はありますか？
いいえ。FlowはAdvancedとPlusで無料で、実行ごとの課金もありません。 Flowから呼び出す外部連携には別料金がかかる場合があります。
Plus運用担当者が最初に始めるべきFlowワークフローは何ですか？
高額注文をしきい値で自動ルーティングするもの（プロンプト1）です。 低リスクで可視性が高く、複雑な構築の前にAI出力を検証できます。
関連記事
上のShopify Flow AIプロンプトと組み合わせるとよい記事:
Advanced Shopify Flow Workflows 2025: AIではないパターン
Shopify Order Management 2026: Flowが動く運用レイヤー
Shopify B2B 2026 Complete Guide: プロンプト6～10の文脈
How to Edit an Order on Shopify: Flowが止まるところ
Shopify Advanced to Plus 2026 Playbook: Shopify flow ai prompts が価値を引き出すアップグレード戦略
RevizeでShopifyストアを刷新しましょう。顧客体験を軸にリードする。
© 著作権 2024、無断転載を禁じます
RevizeでShopifyストアを刷新しましょう。顧客体験を軸にリードする。
© 著作権 2024、無断転載を禁じます
RevizeでShopifyストアを刷新しましょう。顧客体験を軸にリードする。
© 著作権 2024、無断転載を禁じます
RevizeでShopifyストアを刷新しましょう。顧客体験を軸にリードする。
© 著作権 2024、無断転載を禁じます