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 Assistant、5月9日の ShopifyQL アクション、5月5日のバージョン履歴）で、Flow は本番運用に耐えるオペレーション層へと変わりました。

Shopify Flow AI の高度なプロンプト20個のライブラリです。どれも検証済みのネイティブトリガーとアクションを使っています。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」に割り当て、

注文番号、顧客名、合計、管理画面リンク付きで Slack の #ops-priority に通知する。

効果の理由: AND 条件と除外条件の組み合わせで、実運用のルーティング（高額、非 B2B、国内）を扱えます。二重タグでフルフィルメントとオペ作業を分離できます。確認: Slack 連携が接続済み、#ops-priority が存在する、「Warehouse-East」が実在するロケーション名であること。

プロンプト2: 高リスク注文の自動保留と不正チームへの通知

プロンプト:

「Order risk analyzed」トリガーが発火し、リスクレベルが「high」の場合:

注文に「fraud-review-hold」タグを付け、フルフィルメントオーダーを保留し、注文の

メモにリスク要因を記載、さらに HTTP リクエストを送って不正チームの

Slack Webhook に注文番号、合計、リスクスコア、顧客メールを送る。

効果の理由: ネイティブの「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」というプライベートメモを追加、Slack の #ops-rush に

注文番号と配送方法を通知し、保存済みの SLA データを使って

最速の配送業者を配送先に自動選択する。

効果の理由: OR 条件であらゆる速達パターンを拾えます。午後3時締切のメモが倉庫へそのまま届きます。確認: 配送業者連携が自動選択をサポートしている、倉庫がプライベート注文メモを確認していること。

プロンプト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」タグを付ける; フルフィルメントの自動開始を停止する;

注文内容と理由を support manager にメールする。

効果の理由: 複数条件の検証で、最も多い購入後問い合わせ（住所間違い）をフルフィルメント前に防げます。確認: 郵便番号のパターンが配送対象市場に合っている、「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 の参照と一致している、営業担当の連絡先が company record にあること。

プロンプト7: Net-30 売掛金の経過日数に応じた定期アラート

プロンプト:

毎日9:00 AM に Get analytics data を実行し、payment_status が

「pending」、payment_terms が「Net 30」、かつ注文日から25日以上経過した注文を取得する。各注文について:

会社名を検索し、Slack の #finance-ar に注文番号、合計、

経過日数、会社名を送る。28日で finance manager にメールする。

効果の理由: 売掛金の経年化が深刻化する前に捕捉できます。2026年5月9日の Get analytics data アクションで、3つのワークフローが1つにまとまります。確認: Slack チャンネルが存在する、財務チームが対応フローを持っている、B2B 注文に支払条件がタグ付けされていること。

プロンプト8: 営業担当レビュー用の B2B 下書き注文自動フラグ

プロンプト:

下書き注文が作成され、商品合計が10,000ドル超で、かつ

顧客が B2B 会社に属している場合: 下書き注文に「needs-rep-review」タグを付ける;

下書き注文メモを「Q2 2026 の価格ルールに従い営業担当レビュー待ち」に更新する;

Get Company data を使って担当営業を探し、

下書き注文リンクと合計を添えてその担当者へ社内メールを送る。

効果の理由: 高額 B2B の下書きを、購入者にメールされる前に担当者へ可視化できます。（Flow は割引をネイティブには適用できません。Send Admin API request で draftOrderUpdate を呼ぶか、手動で適用してください。）確認: すべての B2B company に担当営業のメールがある、レビュー SLA が文書化されていること。

プロンプト9: B2B 注文の承認閾値ルーティング

プロンプト:

新しい B2B 注文が作成されたら、合計を company の metafield

policies.approval_threshold と比較する。超過している場合: 自動フルフィルしない;

「awaiting-buyer-approval」タグを付ける; 閾値の値をメモに追加する;

承認権限のある購入者（policies.primary_approver_email metafield から取得）へ

承認依頼メールを送る。

効果の理由: 各会社が metafield で独自の閾値を設定できます。Flow 側に会社ごとのロジックを持たせる必要がありません。確認: すべての B2B company に approval_threshold と primary approver email の metafield が存在すること。

プロンプト10: 作成時の B2B 注文担当者通知

プロンプト:

関連する B2B 会社が付いた新しい注文が作成されたら:

Get Company data を使って割り当て済み営業担当のメールを検索し、

注文番号、合計、顧客名、

および管理画面の注文リンクを添えて担当者へ社内メールを送る; 注文に「rep-notified」タグを付ける。

効果の理由: 担当者が自分のアカウントの注文を、着地した瞬間に確認できます。Get Company data はネイティブです（2026年3月24日）。（発火は作成時のみ。途中変更の通知には Flow Companion アプリが必要です。）確認: すべての B2B company レコードに営業担当のメールがあること。

C. 在庫 & フルフィルメント向けプロンプト

2026年3月10日のピックアップ転送アップデートと4月30日の転送トリガーで有効になった、マルチロケーション在庫オーケストレーションのパターン5つ。

プロンプト11: ロケーション間の在庫不足自動転送

プロンプト:

毎日6:00 AM に「Warehouse-East」の在庫を問い合わせ、数量が10未満のものを取得する。

在庫不足の SKU ごとに、「Warehouse-Central」に50ユニット以上ある場合、

30ユニットを Central → East に DRAFT 転送作成し、「auto-replenish」タグを付け、

Central のマネージャーへ Slack 通知する。Central に在庫がなければ購買チームへメールする。

効果の理由: 欠品前に先回りで在庫を再配分できます。ドラフト（自動出荷ではない）なので倉庫側に確認ステップを持たせられます。確認: 転送作成の既定がドラフトであること、ロケーション名が一致していること。

プロンプト12: 出荷準備完了の在庫転送通知

プロンプト:

在庫転送が「ready to ship」になったら、

転送先の ops 連絡先メールを metafield ops.contact_email から検索する。

転送 ID、合計数量、到着予定日、

転送リンクをその連絡先へメールする。同じ内容を Slack の #warehouse-coordination にも送る。

効果の理由: 2026年4月30日の transfer-ready トリガーで、倉庫間の手動引き継ぎメールが不要になります。確認: 受け取り側の各ロケーションに ops contact の metafield が設定されていること。

プロンプト13: 季節別在庫閾値の倍率調整

プロンプト:

毎日5:00 AM に、今日が10月1日から12月31日の間なら、在庫アラート閾値に2.5倍の

倍率を適用する。metafield「base_threshold」を持つ各商品について、

adjusted = base × multiplier とする。いずれかのロケーションで現在の

在庫が adjusted 未満なら、Slack の #inventory-peak に

商品、ロケーション、現在数量、調整後閾値を送る。

効果の理由: 固定閾値ではピーク需要を過小評価してしまいます。2.5倍にすることで BFCM 時期の欠品パターンを防げます。スケジュールトリガー + metafield 計算は 2026年の新機能です。確認: 監視対象のすべての商品に「base_threshold」metafield があること、倍率が過去のピーク比率に合っていること。

プロンプト14: リードタイム付きのバックオーダー通知

プロンプト:

注文が作成され、いずれかの line item のフルフィルメントロケーションで利用可能在庫が0の場合:

「backorder」と「needs-lead-time-notice」タグを付ける;

影響を受ける SKU、注文番号、7〜10営業日のリードタイムを含むテンプレート「backorder-notification」で顧客へメールする;

バックオーダー対象のすべての 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」タグを付け、

それぞれのフルフィルメントを保留し、メール、IP、フラグ付き合計額、

注文間の住所比較を含めて #fraud-team に緊急 Slack 通知する。

効果の理由: 速度ベース検知は、単一注文のリスクチェックでは見逃しやすいカードテストのパターンを捉えます。注文横断の比較で不正シグナルを裏付けられます。確認: 不正チームに文書化された対応手順がある、フラグ時のフルフィルメント保留がポリシーであること。

プロンプト20: フルフィルメント停滞のエスカレーション

プロンプト:

毎日8:00 AM に、fulfillment_status が

「in-progress」で5営業日超の注文を検索し、かつ「backorder」、

「custom-build」、「international」のいずれもタグ付けされていないものを対象にする。各注文について:

「fulfillment-stuck-review」タグを付け、Slack の ops manager に注文番号、

停滞日数、ロケーション、顧客を送る。8日超なら ops lead にメールする。

効果の理由: 停滞注文を問い合わせ化する前に可視化できます。営業日フィルターで月曜の誤検知を防げます。確認: 営業日計算が運用カレンダー（週末と祝日除外）と一致していること。

AI 生成 Flow ワークフローの検証方法

生成されたワークフローは、正しく見えることが多いだけで、実際に正しいとは限りません。 3つの確認ポイント:

1. すべての条件を明示的に読む。 AI は長いプロンプトで条件を反転させることがあります。ビジュアルエディタで確認してください。

2. 最近の実注文でテストする。 発火すべき注文と、発火してはいけない注文を1件ずつ選びます。

3. 影響の少ない時間帯に有効化する。 金曜17時ではなく、営業時間内に。最初の5〜10回を監視します。

5月5日のバージョン履歴でロールバックはワンクリックです。テスト実行でバグを見つけてください。

よくある失敗パターン

Flow AI 導入で共通する4つのパターン:

• メールアドレスやチャンネル名のハードコード。 人が辞めてもワークフローが壊れないよう、ID と役割エイリアスを使ってください。

• metafield の namespace 不足。 存在しない metafield を参照するプロンプトは、エラーなく失敗します。有効化前に監査してください。

• 営業日を考慮しないスケジュールトリガーの日時計算。 「5日前」は月曜に誤検知を起こします。営業日ベースの計算を使ってください。

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年 Q1 を通じて展開され、現在ではほとんどのストアで使えます。「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店舗あたり年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 プロンプトと組み合わせる記事:

• 高度な Shopify Flow ワークフロー 2025: 非 AI パターン

• Shopify 注文管理 2026: Flow が動くオペレーション層

• Shopify B2B 2026 完全ガイド: プロンプト6〜10の文脈

• Shopify で注文を編集する方法: Flow が止まる場所

• Shopify Advanced から Plus への 2026 プレイブック: Shopify flow ai prompts が価値を解き放つアップグレード手順