Plus運用を自動化するShopify Flow AIプロンプト20選 (2026)

Shopify Flow AI 2026: Plusオペレーターが15秒で理解すべきこと

• Flow AIは2026年に実用レベルに達しました。 5月9日のShopifyQLアクション、5月5日のバージョン履歴、3月24日のデータ取得アクションにより、機能の隙間が埋まりました。

• プロンプトがそのままワークフローになります。 英語の自然言語で要望を入力すると、Flowがトリガー、条件、アクションを構築します。出力の精度は、プロンプトの具体性に比例します。

• 以下に20の高度なプロンプトを紹介します。注文ルーティング、B2B、在庫、顧客維持、不正解析などの業務領域別に分類しており、コピー＆ペーストしてそのまま使用可能です。

• Plusマーチャントは20以上のFlowワークフローを実行することで、年間$50Kから$100Kの運用人件費を削減可能（エージェンシーのベンチマークに基づく）。

• 有効化前のテスト実行は必須です。 5月5日のバージョン履歴によりワンクリックでロールバック可能ですが、バグはテスト段階で検知してください。

Shopify Flowは2026年にPlusスタックで最もROIの高いツールとなりましたが、多くのPlusオペレーターは依然としてこれをマーケティングの玩具のように扱っています。2026年春のアップデート（Flow AI Assistant、5月9日のShopifyQLアクション、5月5日のバージョン履歴）により、Flowは実用的な運用レイヤーへと進化しました。

実用的なShopify Flow AIプロンプト20本のライブラリです。すべて検証済みのネイティブなトリガーとアクションを使用しています。AI Assistantにコピーし、注意点を確認して有効化してください。より詳細な背景については、Advanced Shopify Flow Workflowsを参照してください。

Flow AI Assistantへのアクセス方法

Flowを開く → 「New workflow」 → トリガー選択画面の上部にある「Create with AI」を確認します。 2026年5月時点で、ほとんどのPlusストアがアクセス可能です。

生成されたワークフローを有効化する前に、2025年12月のテスト実行機能（ワークフローを開き、「Test」をクリック）を使用してください。アクションを実行することなく、実際のイベントに対してシミュレーションを行います。5月5日のバージョン履歴機能と併用することで、ワンクリックでのロールバックが可能です。

A. 注文管理プロンプト

大量の注文を処理するための5つのパターン。 それぞれ毎週30〜60分の運用時間を削減します。

プロンプト 1: 複数条件による高額注文の優先ルーティング

プロンプト:

When a new order is created with total of $500 or more, customer NOT tagged

"wholesale", and shipping country in [US, CA]: tag "priority-pick"

and "vip-review", assign to "Warehouse-East", and Slack #ops-priority

with order number, customer name, total, and admin link.

機能する理由: AND条件および除外条件の組み合わせにより、実際のルーティング（高額注文、B2Bを除く、国内配送）を処理します。ダブルタグにより、フルフィルメント作業と運用確認作業を分離します。検証ポイント: Slack連携が接続されていること、#ops-priorityチャンネルが存在すること、"Warehouse-East"が実際のロケーション名と一致していることを確認してください。

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

プロンプト:

When the Order risk analyzed trigger fires and risk level is "high":

tag order "fraud-review-hold"; hold fulfillment order; update order

note listing the risk factors; Send HTTP request to your fraud team's

Slack webhook with order number, total, risk score, and customer email.

機能する理由: ネイティブの「Order risk analyzed」トリガーはすべての注文に対して実行されます。フルフィルメントの保留はネイティブ機能であり、Slack通知はHTTP Webhook経由で行われます。検証ポイント: Slack Webhookが保存されていること、不正対策チームに対処用のプレイブックがあることを確認してください。

プロンプト 3: 配送方法確認を伴う急ぎ注文の優先処理

プロンプト:

When a new order is created and shipping method title contains

"Express", "Overnight", "Next Day", or "2-Day": tag "rush-order";

add private note "Ship today by 3 PM cutoff"; Slack #ops-rush with

order number and method; auto-select the fastest carrier to

destination using stored SLA data.

機能する理由: OR条件により、迅速な配送オプションのバリエーションをすべてキャッチします。午後3時の締め切りに関するメモが倉庫に共有されます。検証ポイント: 配送キャリアの連携が自動選択に対応していること、倉庫側で注文のプライベートメモを確認するフローになっていることを検証してください。

プロンプト 4: 海外注文の税関処理準備

プロンプト:

When a new order is created and shipping country code is not "US":

tag "international" + country-specific tag (e.g., "ship-CA").

Add private note listing HS codes, commercial invoice, declared

value. If total is above $2,500: tag "compliance-review-required" and

email the compliance team.

機能する理由: 国別のタグ付けと、注文金額に応じたエスカレーションを組み合わせています。メモによって、倉庫側が添付すべき通関書類を把握できます。検証ポイント: 通関書類のテンプレートが実際の輸出プロセスと一致していることを確認してください。

プロンプト 5: 住所検証エラーに伴う保留

プロンプト:

When a new order is created, fail validation if any: country NOT in

[US, CA, GB, AU, DE, FR, IT, ES], postal code does not match country

pattern, OR address contains "PO Box" with "freight" shipping. On

failure: tag "address-review-hold"; pause fulfillment auto-start;

email support manager with order and reason.

機能する理由: 複数の条件を組み合わせた検証により、フルフィルメント開始前に最も発生頻度の高い購入後問い合わせ（住所間違い）を防止します。検証ポイント: 郵便番号のパターンが対象市場と一致していること、"freight"が実際の配送方法として設定されていることを確認してください。

B. B2B & 卸売プロンプト

2026年4月2日のB2Bアップデートにより、すべての有料プランでこれらのプロンプトが実行可能です。 運用規模が大きくなるほど、時間削減効果が累積します。

プロンプト 6: 企業ランクに応じたB2B自動ルーティングと担当営業の割り当て

プロンプト:

When a new order is created with a B2B company associated: use Get

Company data to read metafield tier.level. If "enterprise": tag

"b2b-enterprise" and "priority-fulfillment", assign to

"Warehouse-East-Priority", notify sales rep via email + Slack DM.

If "mid-market": tag "b2b-mid", assign to standard fulfillment.

機能する理由: 2026年3月24日の「Get Company data」アクションを使用してメタフィールド値を読み込みます。ランクに基づくルーティングにより、ハードコードされた顧客リストを管理する手間を省きます。検証ポイント: ランクのメタフィールド構造がFlowのルックアップ設定と一致していること、企業レコードに担当営業の連絡先が設定されていることを確認してください。

プロンプト 7: Net-30 売掛金（AR）回収期限のスケジュールアラート

プロンプト:

Daily at 9:00 AM, Get analytics data: orders with payment_status

"pending", payment_terms "Net 30", placed 25 or more days ago. For each:

look up company name; Slack #finance-ar with order number, total,

days outstanding, company. At 28 days, email finance manager.

機能する理由: 回収が遅延する前に売掛金の未回収状況を把握します。2026年5月9日の「Get analytics data」アクションにより、かつて3つのワークフローが必要だった処理を1つに集約します。検証ポイント: Slackチャンネルが存在すること、財務チームが対応フローを把握していること、B2B注文に支払い条件が正しくタグ付けされていることを確認してください。

プロンプト 8: 営業による確認が必要な高額B2B下書き注文の自動フラグ付け

プロンプト:

When a draft order is created with line items above $10,000 AND

customer is in a B2B company: tag the draft order "needs-rep-review";

update draft order note "Awaiting sales rep review per Q2 2026

pricing rules"; use Get Company data to find the assigned sales

rep; send internal email to the rep with the draft order link and

total.

機能する理由: 購入者にメールが送信される前に、高額なB2B下書き注文を担当営業に通知して確認を促します。（Flowはネイティブで割引を適用できないため、draftOrderUpdateを呼び出す「Send Admin API request」を組み合わせるか、手動で適用してください。） 検証ポイント: すべてのB2B企業レコードに担当営業のメールアドレスが登録されていること、確認のためのSLAが定義されていることを確認してください。

プロンプト 9: B2B注文の承認しきい値に応じたルーティング

プロンプト:

When a new B2B order is created, compare total to company metafield

policies.approval_threshold. If exceeded: do NOT auto-fulfill; tag

"awaiting-buyer-approval"; add note with threshold value; email

the authorized buyer (from policies.primary_approver_email metafield)

requesting approval.

機能する理由: メタフィールドを利用して企業ごとに個別のしきい値を設定するため、Flow側で個別企業向けのロジックを管理する必要がありません。検証ポイント: すべてのB2B企業レコードに承認しきい値とメイン承認者のメールアドレスのメタフィールドが設定されていることを確認してください。

プロンプト 10: B2B注文作成時の担当営業への自動通知

プロンプト:

When a new order is created with an associated B2B company: use

Get Company data to look up the assigned sales rep email; send

internal email to the rep with order number, total, customer name,

and a link to the order in admin; tag order "rep-notified".

機能する理由: 担当営業は、自身のアカウントからのすべての注文を発生時に即座に把握できます。「Get Company data」はネイティブ機能です（2026年3月24日実装）。（これは新規作成時のみ実行されます。注文編集時の通知には、Flow Companionアプリが必要です。） 検証ポイント: すべてのB2B企業レコードに担当営業のメールアドレスが設定されていることを確認してください。

C. 在庫・フルフィルメントプロンプト

3月10日の受取転送アップデートと4月30日の転送トリガーによって可能になった、複数拠点における5つの在庫管理パターン。

プロンプト 11: 拠点間における在庫切れ未然防止の自動在庫転送

プロンプト:

Daily at 6:00 AM, query inventory at "Warehouse-East" where qty is below 10.

For each low-stock SKU: if "Warehouse-Central" has 50 or more units,

create DRAFT transfer of 30 units Central → East, tag "auto-replenish",

Slack the Central manager. If Central is out, email purchasing team.

機能する理由: 在庫切れが発生する前に、予防的に在庫を調整します。自動発送ではなく「下書き（DRAFT）」として作成することで、倉庫側で確認ステップを挟むことができます。検証ポイント: 転送作成のデフォルト設定が下書きになっていること、および拠点名が一致していることを確認してください。

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

プロンプト:

When an inventory transfer is marked "ready to ship": look up the

destination's ops contact email from metafield ops.contact_email.

Email that contact with transfer ID, total units, expected arrival,

and transfer link. Also Slack #warehouse-coordination with same.

機能する理由: 2026年4月30日に実装された転送準備完了（transfer-ready）トリガーにより、倉庫間における手動の引き継ぎ連絡メールを削減します。検証ポイント: すべての受取拠点に運用窓口用の連絡先メタフィールドが設定されていることを確認してください。

プロンプト 13: 繁忙期における在庫アラートしきい値の動的変更

プロンプト:

Daily at 5:00 AM, if today is between Oct 1 and Dec 31, apply 2.5x

multiplier to inventory alert thresholds. For each product with

metafield "base_threshold": adjusted = base × multiplier. If current

inventory < adjusted at any location, Slack #inventory-peak with

product, location, current qty, and adjusted threshold.

機能する理由: 固定のしきい値では繁忙期の需要過多に対応できません。2.5倍の係数を適用することで、BFCM（ブラックフライデー・サイバーマンデー）時の在庫切れを防止します。スケジュールトリガーとメタフィールド計算の組み合わせは2026年の新機能です。検証ポイント: 監視対象のすべての商品に "base_threshold" メタフィールドが定義されていること、および適用する倍率が過去の繁忙期のデータに即していることを確認してください。

プロンプト 14: 納期情報を伴うバックオーダー（入荷待ち）購入者通知

プロンプト:

When an order is created and any line item has 0 available inventory

at its fulfillment location: tag "backorder" and "needs-lead-time-notice";

email customer using template "backorder-notification" with affected

SKU, order number, lead time of 7 to 10 business days; add private

warehouse note listing all backordered SKUs.

機能する理由: 購入者がサポートへ問い合わせる前に状況を通知し、最も問い合わせ件数の多いチケットカテゴリの発生を防止します。検証ポイント: メールテンプレートが存在すること、通知に記載する納期が実際のサプライヤーの最新SLAと一致していることを確認してください。

プロンプト 15: 在庫復帰時の自動再販売と再入荷通知トリガー

プロンプト:

When inventory updates from 0 to above 0: publish

product to online store, remove "out-of-stock" tag, trigger

back-in-stock notification flow to signed-up customers for that

SKU. Tag product "restocked" and write metafield "restocked_at"

with current timestamp.

機能する理由: これまでマーチャンダイジングとマーケティングの間で手動調整が必要だった「再販売と通知」の連動を自動化します。検証ポイント: 再入荷通知フローが設定されていること、販売チャネルでの公開ロジックがストアのルールと一致していることを確認してください。

D. 顧客体験（CX）プロンプト

リピート購入率に直結する、購入後のフォローを自動化する5つのプロンプト。

プロンプト 16: 高LTV（顧客生涯価値）顧客向けのキャンセル後引き戻しメール

プロンプト:

When an Order canceled trigger fires AND the customer's lifetime

spend is $1,000 or more: tag the customer "post-cancel-retention";

send an email using template "retention-followup" with a 15%

discount code; send internal email to the CS manager with order

number, customer LTV, and cancellation reason.

機能する理由: 注文キャンセルはネイティブトリガーであり、顧客データの取得アクションからLTV情報を参照できます。（これはリアクティブな補填です。事前にキャンセルを防止するには、購入者自身が操作できるセルフサービス機能を導入する必要があります。）検証ポイント: メールテンプレートが存在すること、クーポンコード「RETAIN15」が有効化されていることを確認してください。

プロンプト 17: 商品配送完了後のレビュー依頼自動化

プロンプト:

When fulfillment status = "delivered": wait 4 days, then email

customer with subject "How did the [Product Name] work out?" using

template "post-delivery-review-request" populated with product and

first name. Add to segment "post-delivery-review-pending". If total

is above $300, include $20 store credit incentive.

機能する理由: 4日間の遅延を挟むことで、購入者が商品を使用しつつも記憶が新しいタイミングでアプローチし、購買金額に応じたインセンティブで費用対効果を最適化します。検証ポイント: メールテンプレートが存在すること、顧客イベントでレビューの追跡設定が機能していることを確認してください。

プロンプト 18: 顧客復帰（ウィンバック）キャンペーンのトリガー（90日間購入なし）

プロンプト:

Daily at 9:00 AM, calculate days since each customer's last order.

For 90-day inactive without "win-back-sent" tag: add to "win-back-90"

segment, apply tag, trigger win-back email. For 180-day inactive

without "win-back-180" tag: send 20% discount email, apply tag. For

365+ day inactive: suppress from marketing.

機能する理由: かつてKlaviyoとカスタムロジックの併用が必要だった3段階の自動化を、単一のFlowワークフローで実現します。検証ポイント: 対象セグメントごとのウィンバック配信用メールフローが存在すること、およびクーポンコード「WINBACK20」が有効化され、追跡可能であることを確認してください。

プロンプト 19: 高頻度の大量不正注文の検知（ベロシティ検出）

プロンプト:

When a new order is created and the same email has placed 3+ orders

in the last 1 hour: tag all of that email's orders from the last hour

"velocity-fraud-flag", hold fulfillment on each, urgent Slack to

#fraud-team with email, IP, total flagged value, and address comparison

across orders.

機能する理由: 単一の注文リスク検証では検知しづらい、カードの有効性テストなどの同一メールアドレスによる短時間での連続不正注文を検知・比較し、フラグを立てます。検証ポイント: 不正対策チームに対応マニュアルがあること、およびフラグ検知時のフルフィルメント保留ルールが運用ポリシーに沿っていることを確認してください。

プロンプト 20: フルフィルメント未完了ステータスの長期滞留注文の調査

プロンプト:

Daily at 8:00 AM, query orders where fulfillment_status =

"in-progress" for more than 5 business days AND NOT tagged "backorder",

"custom-build", or "international". For each: tag

"fulfillment-stuck-review", Slack ops manager with order number,

days stuck, location, customer. Over 8 days: email ops lead.

機能する理由: 顧客からの問い合わせが発生する前に滞留している注文を検知します。営業日ベースのフィルタリングにより、土日祝日を挟むことによる誤検知を防止します。検証ポイント: 営業日の計算ルールが実際の営業カレンダー（週末や祝日の除外設定など）と一致しているか確認してください。

AIで生成したFlowワークフローの動作検証方法

AIによって構築されたワークフローは、「正しく見える」が「実際には間違っている」ことがよくあります。 以下の3段階でチェックを行ってください。

1. すべての条件設定を明示的に確認する。 プロンプトが長い場合、AIは条件の肯定・否定（真偽）を逆転させて解釈することがあります。ビジュアルエディターを必ず確認してください。

2. 直近の実際の注文データを使用してテストを実行する。 トリガー条件を満たすべき注文と、満たさないはずの注文の両方でシミュレーションしてください。

3. 業務時間内の影響が少ない時間帯に有効化する。 金曜の午後5時などは避け、平日の日中に有効化し、最初の5〜10件の動作を注意深く監視してください。

5月5日のバージョン履歴機能によりワンクリックでロールバック可能です。まずはテスト実行で不具合を検知してください。

よくある失敗パターン

Flow AI導入時に見られる4つの失敗パターン：

• メールアドレスやチャンネル名のハードコーディング。 担当者の変更や退職によるワークフローの破損を防ぐため、可能な限りIDや役職のエイリアス（グループアドレスなど）を使用してください。

• メタフィールドの名前空間（Namespace）の指定漏れ。 存在しない、または指定に誤りがあるメタフィールドを参照するプロンプトはエラーにならず無反応（サイレントフェイル）になります。有効化前の動作確認を必ず行ってください。

• 営業日を考慮しないスケジュールトリガーの日付計算。 単純に「5日前」と計算すると、月曜日の朝に土日を挟んだことによる誤検知を多発させます。稼働日・営業日ベースのロジックを用いてください。

Flowの限界とRevizeによる補完

Flowはサーバー側の自動化処理を担当するものであり、購入者が操作する購入後の注文編集には対応していません。 購入完了後に配送先住所の変更や、バリエーションの変更を行いたい場合、Flowでは購入者自身による自己解決を促すことはできません。この機能のギャップを埋めるのが Revize です。売掛条件のB2B注文を含め、購入完了後のセルフサービスでの注文内容変更を可能にします。Plusオペレーターは、同じ処理フロー内でサーバーサイド処理にFlowを、購入者側（フロントサイド）の処理にRevizeを組み合わせて運用しています。

結論

Shopify Flow AI Assistantは2026年現在すでに実用に耐えうるレベルであり、このプロンプトライブラリの活用こそが運用の最適化に直結します。 上記20個の検証済みプロンプトは、週に30〜60時間の現場の手作業を代替し、20以上のワークフローを稼働させるPlusマーチャントでは年間$50K〜$100K規模のコストを削減できます。

Flowをマーケティング用途でのみ使用しているPlusオペレーターへ： まずは注文処理とB2Bの自動化から始めてみてください。3つを選び、テストし、有効化するだけで、初月から十分な投資回収効果を得られます。

支援パートナー企業（エージェンシー）へ： プロンプトライブラリを用いたワークフローの実装を標準サービス化してください。標準化された再現性の高いアウトプットが可能になり、バージョン履歴機能がそのままクライアントへの作業ログ（監査トレイル）となります。

今すぐFlowを開き、3つのプロンプトを選択して、生成、テスト、有効化を試してください。そして、自社向けにこのプロンプトライブラリのドキュメント化を進めてください。

よくある質問（FAQ）

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はカスタムメタフィールドを参照するワークフローを記述できますか？

はい、ワークフローが実行される前にメタフィールドのネームスペース（Namespace）とキーが存在していれば可能です。 参照先のメタフィールドが存在しない場合、条件判定でエラーにならず「不一致」として処理されます。

SidekickとFlowをどのように組み合わせて使用しますか？

SidekickがShopifyQLを生成し、Flowがそれを「Get analytics data」を介して読み込みます。 分析に関する質問への回答や集計はSidekickが行い、それをトリガーにした自動アクションをFlowが実行します。

PlusマーチャントがFlow自動化を導入した場合、実際にどれくらいのコスト削減が可能ですか？

20以上のワークフローを稼働させるPlusマーチャントでは、年間$50K〜$100Kの運用人件費の削減が見込めます。 たとえば、不正注文検知フローを導入するだけでもチャージバックを40〜60%削減でき、これだけで年間$12K〜$24K相当の損失防止効果が得られます。

AIで生成して本番環境に適用したワークフローにバグがあった場合はどうすればよいですか？

「バージョン履歴（Version history）」を開き、変更前のバージョンを選択して「Restore」をクリックしてください。 2026年5月5日のアップデート以降、操作したアカウントとタイムスタンプ付きですべての変更が記録されているため、即座に以前の状態に切り戻しが可能です。

Flow AI AssistantとSidekickの違いは何ですか？

Flow AIは処理フロー（自動化）を構築するツールであり、Sidekickはデータに関する質問への回答や、ShopifyQLを自動生成するアシスタントです。 Sidekickが分析を支援し、Flowが実際の自動処理を実行します。

Flowで実行できるワークフローの数に上限はありますか？

上限はありません。FlowはAdvancedプラン、Plusプランにおいて無料で利用でき、実行回数による追加課金もありません。 ただし、Flowからサードパーティの外部アプリやツールへ接続する場合、そのツール側で発生するAPI通信費用やプラン料金が別途必要になる場合があります。

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の前提知識となるB2B機能ガイド

• How to Edit an Order on Shopify：Flowでは自動化できない注文編集領域についての解説

• Shopify Advanced to Plus 2026 Playbook：Shopify Flow AIを活用してビジネス価値を最大化するためのアップグレード移行手順書

2026年8月更新。 Revizeは、購入者がセルフサービスで配送先住所の変更、商品のバリエーション交換、キャンセルおよび返金・ストアクレジット発行をフルフィルメント開始前に行うことができるShopifyアプリです。サポートへの問い合わせを増やすことなく注文編集を受け付けることができます。詳細については letting customers edit their own Shopify orders をご覧いただくか、Revize on the Shopify App Store にてアプリをご確認ください。