Shopify Flowとは、注文や在庫などストアで起きた出来事をきっかけに、タグ付けや通知、外部システムへの送信を自動で行うShopify公式の無料アプリです。コードを書かずに「トリガー・条件・アクション」を画面でつなぐだけで動き、必要ならJavaScriptやHTTPリクエストで処理を足せます。本記事では、プランごとに使える機能、最初のワークフローの組み方、外部システムへ注文を送る設定と受信側の実装、Run codeの書き方と上限値、そしてiPaaSやアプリ開発へ切り替える判断基準を、2026年10月時点の公式ヘルプと開発者ドキュメントに沿って解説します。
まとめ：Shopify Flowはストア内の定型処理を担い、外部連携は上限で線を引く
注文へのタグ付け、在庫切れ商品の非公開、スタッフへの通知といった「ストアの中で完結する定型処理」は、まずShopify Flowで組みます。アプリ代はかからず、Basicプランから使えます。
外部の倉庫・基幹システムへ注文を送るなら、Grow以上のプランでSend HTTP requestを使えば足りる場合があります。ただし応答待ちは30秒、Run codeは5秒で外部通信もできず、実行履歴の保存期間は14日です。複数システムの間でデータを突き合わせる、数千件を一度に処理する、といった要件はFlowの外に出します。
迷ったら、要件を「Flowの上限表」に当てて判断するのが近道です。
Shopify Flowとは何か、トリガー・条件・アクションの仕組みと対象プラン
Shopify Flowの公式ヘルプは、Flowを「ストア内やアプリをまたいだ作業を自動化するEコマース向けの自動化基盤」と説明しています。ストアのイベントを監視し、決められた一連の処理を走らせる仕組みです。
トリガー・条件・アクションの組み合わせと100を超える標準アクション
ワークフローは、開始のきっかけになるトリガー、処理を進めるか判定する条件、実際の処理であるアクションでできています。トリガーの一覧には、注文作成・注文の支払い完了・在庫数の変化・顧客の作成・返品リクエストのほか、決まった時刻に動く「Scheduled time」やワークフローのエラー発生まで並びます。
アクションの一覧は2026年10月26日時点で109件ありました。タグやメタフィールドの更新、商品の公開・非公開、注文のキャンセルや支払いの確定、スタッフ宛てのメール送信など、管理画面で手作業していた操作の多くが含まれます。Slackへの投稿やスプレッドシートへの行追加は、外部サービスのコネクタとして用意されています。
Basicから無料で使える機能とGrow以上・Plusに限られる機能の比較表
Flowそのものは無料ですが、一部の機能はプランで制限されています。公式ヘルプの記載を表にまとめます。
| 機能 | Basic | Grow・Advanced | Plus |
|---|---|---|---|
| Flowアプリと標準のトリガー・アクション | 使える | 使える | 使える |
| Send HTTP request（外部送信） | 使えない | 使える | 使える |
| カスタムパートナーアプリが作ったタスク | 使えない | 使えない | 使える |
| 使用量の上限 | プランごとのAPI上限に連動 | ||
実務で効いてくるのは2行目です。Basicのまま外部システムへ送る設計を立てると、後からプラン変更が必要になります。月額差と手数料差の比較はShopifyの料金プランと手数料の判断を解説した記事、Plusだけの機能の範囲はShopify Plusと通常プランの機能差の記事で扱っています。
Shopify Flowで最初のワークフローを作る手順と予約実行の設定
導入はShopify App StoreのFlowのページからアプリを入れるだけで、管理画面の「アプリ」から開けます。テンプレートから始めると、トリガーと条件が入った状態で編集できます。
5万円以上の注文にタグを付けてスタッフへメールする組み立て手順
出荷前に目視確認したい高額注文を拾う例です。画面上でブロックをつなぎます。
- 「ワークフローを作成」を開き、トリガーに「Order created（注文作成）」を選ぶ
- 条件を追加し、注文の合計金額（Total price set ＞ Shop money ＞ Amount）が50000以上、を設定する
- 条件が真の側に「Add order tags」を置き、
high-valueなどのタグ名を入れる - 続けて「Send internal email」を置き、宛先に出荷担当のアドレス、本文に注文番号の変数を入れる
- テスト注文で動作を確かめてから、ワークフローを有効にする
タグを付けておくと、注文一覧の絞り込みや後続のワークフローの条件にも使えます。通知だけで終わらせず、タグという「状態」を残す設計にしておくと、担当者が見落としたときにも追えます。
Scheduled timeとGet order dataで前日分の注文を毎朝集める設定
Scheduled timeトリガーの解説によると、繰り返しは日・週・月の単位で指定し、実行は最短でも10分に1回、間隔は最長1年です。タイムゾーンの既定値はストアの設定です。このトリガーは注文などのデータを持たないため、Get系のアクションでデータを取りに行きます。
Get order dataの解説にある書き方に沿うと、実行時刻から1日前までに更新された注文を取る検索条件は次のとおりです。
updated_at:<='{{ scheduledAt }}' AND updated_at:>'{{ scheduledAt | date_minus: "1 day" }}'1回に取れるのは最大100件で、結果はgetOrderDataという変数に入ります。1日の注文が100件を超えるストアでは取りこぼすため、この方式での日次集計は採りません。件数を数えるだけならCountアクション、全件を外部へ渡すならAPIのバルク取得に切り替えます。
Send HTTP requestで外部システムへ注文を送る設定と受信側の実装
倉庫管理や基幹システムに注文を渡す場面で、最初に検討するのがこのアクションです。Send HTTP requestの解説では、GET・POST・PUT・PATCH・DELETE・HEAD・OPTIONSの7メソッドに対応し、URL・ヘッダー・本文を指定できます。
シークレットとLiquidで認証ヘッダーと注文JSONを組み立てる設定例
トークンなどの秘密の値は、Flowの設定画面でシークレットとして登録し、{{secrets.ハンドル名}}で参照します。シークレットの値は画面上で隠され、実行ログからも消される仕組みです。ヘッダーにAuthorization＝Bearer {{secrets.wms_token}}、Content-Type＝application/jsonを入れ、本文はLiquidで次のように書きます。
{
"orderId": "{{ order.id }}",
"orderName": "{{ order.name }}",
"amount": "{{ order.totalPriceSet.shopMoney.amount }}",
"currency": "{{ order.totalPriceSet.shopMoney.currencyCode }}"
}メモ欄や住所のような自由入力の値をそのまま埋めると、引用符や改行でJSONが壊れます。本文には注文IDなど形式の決まった値だけを入れ、詳細は受信側がAdmin APIで取り直す形にすると安全です。Admin APIの呼び方とレート制限はShopify APIの使い分けとレート制限を解説した記事にまとめています。
30秒の応答待ちと最大24時間の再試行を前提にした受信側の実装
同じ解説によると、Flowは応答を最大30秒待ち、返ってこなければ接続を閉じて後で再試行します。4XX・5XX・429の応答ごとに選べる処理は、「再試行（最大24時間）」「失敗にする」「無視する」です。再試行を選ぶと同じ注文が複数回届くため、受信側は注文IDで重複を弾き、すぐに200を返します。
import express from "express";
import crypto from "node:crypto";
const app = express();
app.use(express.json());
const seen = new Set(); // 本番ではDBの一意制約で判定する
app.post("/flow/orders", (req, res) => {
const received = Buffer.from(req.get("Authorization") || "", "utf8");
const expected = Buffer.from(`Bearer ${process.env.WMS_TOKEN}`, "utf8");
if (received.length !== expected.length || !crypto.timingSafeEqual(received, expected)) {
return res.sendStatus(401); // Flow側は4XXを「失敗にする」で受ける
}
const { orderId } = req.body;
if (!seen.has(orderId)) {
seen.add(orderId);
enqueue(req.body); // 重い処理はキューに回す
}
res.sendStatus(200);
});
app.listen(3000);Flowの送信にはShopifyのWebhookのような署名ヘッダーが付かないため、共有トークンをシークレットで送って照合します。認証エラーの401を再試行させても直らないので、4XXは「失敗にする」、5XXと429は「再試行」に分けて設定します。重複を前提にした受け方の考え方は決済Webhookの署名検証と冪等な処理の記事と共通です。
Run codeとSend Admin API requestで集計とデータ更新を書く方法
条件ブロックだけでは書きにくい集計や文字列の加工は、Run codeで書けます。標準アクションに無い更新は、Send Admin API requestでAdmin APIのミューテーションを直接呼びます。
Run codeで注文明細をSKU別に集計するJavaScriptと入力クエリ
Run codeの解説では、入力をFlowの環境データに対するGraphQLクエリで、出力をGraphQLのスキーマ定義言語で書きます。入力クエリにはedgesやnodesを書きません。まず入力と出力を定義します。
# 入力（Define inputs）
{
order {
lineItems {
sku
quantity
}
}
}
# 出力（Define outputs）
type Output {
"明細の数量合計"
totalQuantity: Int!
"SKU別の数量（例: A-001:2, B-010:1）"
skuSummary: String!
"SKUが空の明細があるか"
hasMissingSku: Boolean!
}コード欄には、export defaultを付けた関数を書きます。
export default function main({ order }) {
const bySku = {};
let total = 0;
for (const item of order.lineItems) {
const key = item.sku || "NO_SKU";
bySku[key] = (bySku[key] || 0) + item.quantity;
total += item.quantity;
}
console.log(bySku); // 実行ログに出る
return {
totalQuantity: total,
skuSummary: Object.entries(bySku).map(([sku, qty]) => `${sku}:${qty}`).join(", "),
hasMissingSku: order.lineItems.some((item) => !item.sku),
};
}後続の条件で「Run code ＞ hasMissingSku が true」を見れば、SKU未登録の商品が売れた注文だけに確認タグを付けられます。公式のサンプルはGitHubのflow-code-examplesリポジトリに集められています。
5秒・10MB・fetch不可というRun codeの制約と外へ出す判断
Run codeはECMAScript 2020のJavaScriptで動き、Node.jsのAPI、モジュールのimport、fetchによる外部通信は使えません。乱数や現在時刻を返す関数も使えないため、日付はscheduledAtやcreatedAtを入力で受け取ります。
数値の上限は、実行時間5秒、メモリ10MB、コード50,000文字、入力クエリと出力スキーマが各5,000文字、出力とconsole.logの合計が50KBです。外部APIの応答を加工したいときは、先にSend HTTP requestを置き、Run codeの入力でsendHttpRequest { body }を受けてJSON.parseします。この上限を超える計算や、外部のマスタを何度も引く処理は、Flowの中に押し込まずに外で作ります。
Send Admin API requestで予約商品のテンプレートを切り替える例
Send Admin API requestの解説によると、このアクションで呼べるのはミューテーションだけです。クエリ、非推奨のミューテーション、非同期でJob型を返すもの、Nodeインターフェースを持たないもの、一部のサブスクリプション・割引関連のミューテーションは使えません。公式の例は、productUpdateを選んで入力に次のJSONを渡し、商品の表示テンプレートを予約販売用に切り替えるものです。
{
"input": {
"templateSuffix": "pre-order",
"id": "{{product.id}}"
}
}Flowが使うAdmin APIのバージョンが上がると、変更・廃止されたフィールドを使うワークフローは失敗し得ると明記されています。標準アクションで書ける処理は標準アクションで書き、このアクションは最後の手段にとどめます。
Shopify Flowの上限値と運用でつまずく制約、監視と再試行の手順
Flowは画面で組める手軽さの代わりに、件数・期間・保存日数に上限があります。設計の前に、要件を次の表に当てます。
For eachの1,000件・Waitの90日・実行履歴14日などの上限一覧
各アクションの公式ヘルプに書かれた数値を並べます。
| 対象 | 上限 | 超えたとき・注意点 |
|---|---|---|
| For each loop | リストは1,000件まで・入れ子は1段 | 超えるとワークフローが失敗し、後続も止まる |
| Get order data | 1回100件まで | それ以上は取得されない |
| Wait | 1ワークフローで最大90日 | 超える設定では有効化できない |
| Scheduled time | 最短10分に1回・最長1年 | 処理が間隔より長いと結果がずれる |
| Send HTTP request | 応答待ち30秒・再試行は最大24時間 | Basicでは使えない |
| Run code | 5秒・10MB・出力とログで50KB | 外部通信は不可 |
| 実行履歴 | 完了から14日 | それ以降は削除される |
For eachの解説には、ループの中にWait・Get data・Run codeを置けないとも書かれています。Waitの解説では、待機中の実行が再開時に使うのは、編集後のワークフローです。「90日後にフォローメール」のような長い待機を入れたワークフローを途中で書き換えるときは、この挙動を前提にします。
実行履歴の監視と手動再試行で失敗した実行を拾い直す運用担当者の手順
実行履歴の監視の解説によると、実行は「In progress」「Waiting」「Rate limited」「Canceled」「Completed」の状態で表示され、完了から14日で消えます。運用では次の順で見ます。
- トリガーに「Workflow error occurred」を使う監視用ワークフローを作り、失敗時に担当者へメールする
- 週に1回は実行一覧を「Errors」で絞り込み、同じ原因の失敗が続いていないかを見る
- 原因を直したら、終了済みの実行を手動で再試行する（元のトリガーのデータを使い、Get dataは最新の値を取り直す）
- 14日を超えて追跡したい処理は、Send HTTP requestやログ出力で外部に記録を残す
「Rate limited」が続く場合は、ストアのプランのAPI上限に当たっています。この状態が常態化したら、処理をFlowの外へ移す合図です。
アプリ開発者がShopify Flowのトリガーを自作してワークフローへ渡す実装
FlowのアプリAPIの概要によると、アプリはFlowにトリガー・アクション・テンプレートを追加できます。条件は追加できません。自社システムの出来事を起点にFlowを動かしたいときは、トリガーを作ります。
倉庫の出荷遅延を通知するトリガーの定義とアプリから発火する実装例
トリガーのリファレンスの形式に沿って、shopify.extension.tomlでアプリの拡張機能としてトリガーを定義し、flowTriggerReceiveで発火します。ここでは倉庫システムで出荷が遅れた注文を知らせる例にします。
# extensions/shipment-delayed/shopify.extension.toml
[[extensions]]
name = "Shipment delayed"
type = "flow_trigger"
handle = "shipment-delayed"
description = "倉庫で出荷が遅れた注文を通知する"
[settings]
[[settings.fields]]
type = "order_reference"
[[settings.fields]]
type = "single_line_text_field"
key = "delay reason"拡張を公開したら、アプリのサーバーからGraphQL Admin APIのflowTriggerReceiveミューテーションを呼んで発火させます。
curl -s -X POST "https://${SHOP}.myshopify.com/admin/api/2026-10/graphql.json" \
-H "Content-Type: application/json" \
-H "X-Shopify-Access-Token: ${SHOPIFY_ACCESS_TOKEN}" \
-d '{"query":"mutation($handle: String, $payload: JSON) { flowTriggerReceive(handle: $handle, payload: $payload) { userErrors { field message } } }","variables":{"handle":"shipment-delayed","payload":{"order_id":1234567890,"delay reason":"carrier pickup missed"}}}'リファレンスによると、ペイロードはキーを含めて50,000バイト未満、handleは英数字とハイフンだけ、キーは英字と空白だけで書きます。レート制限はShopify APIと共通です。Plus以外のストアでも使ってもらうには、カスタムアプリではなく公開アプリとして配布する必要があります。配布方法と審査の要件はShopifyアプリ開発の始め方を解説した記事で扱っています。
Shopify Flowで済ませる範囲と、iPaaSやアプリ開発へ移す判断基準
Flowで作れることと、Flowで作るべきことは別です。保守の手間まで含めて線を引きます。
Flowだけで完結させてよい条件と、外部ツールを足さない典型業務
処理の起点も終点もShopifyの中にあり、1回に扱う件数が100件以内に収まるなら、Flowで完結させます。高額注文や不正リスクの高い注文へのタグ付け、在庫切れ商品の非公開と再入荷時の公開、初回購入の顧客へのタグ付け、B2Bの会社作成時のカタログ割り当てがその典型です。いずれも標準アクションで書け、追加の費用もかかりません。
この範囲でZapierなどのiPaaSを足すと、同じ処理に月額のタスク課金が発生するだけです。ここではiPaaSを採用しません。
iPaaS・カスタムアプリ・API連携へ移す処理と要件別の判断表
次のどれかに当てはまったら、Flowの外に出します。表中の「ループ」はFor each、「注文取得」はGet order dataを指します。
| 要件 | Flowで詰まる理由 | 移す先 |
|---|---|---|
| kintone・会計ソフト等の複数SaaSへ送信 | 送信先ごとに設定と認証を持つ必要がある | iPaaS |
| Basicプランのまま外部へ送りたい | Send HTTP requestが使えない | iPaaS・API連携 |
| 数千件の在庫や価格を一括で更新する | ループ1,000件・注文取得100件まで | API連携（バルク処理） |
| 外部の応答を見て何段も分岐する | Run codeは5秒・外部通信不可 | API連携・カスタムアプリ |
| 連携の記録を監査用に長期保存する | 実行履歴が14日で消える | API連携 |
複数SaaSへの同時配信が主目的ならiPaaSが早く、課金の数え方はiPaaSの仕組みと料金の数え方の記事で比べられます。件数や監査の要件で詰まる場合は、APIで作るほうが運用費を下げられる選択です。iPaaSと受託開発の分かれ目はAPI連携ツールの選び方の記事にもまとめています。
開発会社へ相談する前に整理するワークフロー一覧と保守の担当範囲
Flowは管理画面から誰でも編集できるため、担当者の退職や異動でワークフローの意図が分からなくなりがちです。相談の前に、有効なワークフローの一覧、各トリガーと送信先、Send HTTP requestで使っているシークレットの持ち主、失敗時の連絡先を書き出しておくと、Flowに残す処理と外へ出す処理を短時間で仕分けられます。多店舗の在庫同期まで視野に入るなら、EC在庫管理システムの機能と選び方の記事も判断材料になります。
一創では、Shopifyのストア構築とあわせて、Flowで組める範囲の設計と、それを超える部分のAPI連携・アプリ開発を受託しています。どこまでをFlowで済ませるかから相談したい場合は、ECサイト制作・Shopify構築のサービスをご覧ください。
よくある質問
Shopify Flowについてよく寄せられる質問をまとめました。
Shopify Flowは無料で使えますか？
はい。Shopify Flowは無料のアプリで、Basic・Grow・Advanced・Plusの各プランで使えます。ただし外部へHTTPリクエストを送るSend HTTP requestを使えるのはGrow以上、カスタムパートナーアプリが作ったタスクを使えるのはPlusのみです。使用量の上限もプランのAPI上限に連動するため、処理量が多いストアでは上位プランのほうが余裕があります。
Shopify Flowではどんな作業を自動化できますか？
注文・顧客・商品へのタグ付け、在庫切れ商品の非公開、スタッフへのメール通知、注文のキャンセルや支払いの確定、メタフィールドの更新などです。2026年10月時点で標準アクションは100件を超えます。Slack投稿やスプレッドシートへの記録はコネクタで、標準に無い処理はRun codeやSend Admin API requestで補えます。
Shopify FlowのテンプレートとHTTPリクエストはどう使い分けますか？
テンプレートは、在庫通知や高額注文のタグ付けなど、よくあるワークフローを下書きの状態で取り込む機能です。まずテンプレートで近いものを探し、トリガーと条件を自社の値に直します。HTTPリクエストは、外部の倉庫や基幹システムへデータを送るときに足すアクションで、Grow以上のプランが必要です。
Shopify FlowのRun codeで外部APIを呼べますか？
呼べません。Run codeはfetchによる外部通信とモジュールのimportに対応していません。外部APIの値を使いたい場合は、前段にSend HTTP requestを置き、その応答の本文をRun codeの入力で受け取ってJSON.parseで解析します。実行時間は5秒、メモリは10MBまでなので、重い計算はFlowの外で行います。
Shopify FlowとZapierなどのiPaaSはどちらを使うべきですか？
処理がShopifyの中で完結するならFlowを使います。費用がかからず、Shopifyのデータを直接扱えるためです。kintoneや会計ソフトなど複数の外部サービスへ同時に渡す場合や、Basicプランのまま外部連携したい場合はiPaaSが向きます。Zapierの課金の仕組みはZapierの料金とタスク課金の記事で解説しています。
関連記事
- ECサイト構築とは？5つの構築方法の費用相場と、自社に合う進め方の判断軸を解説：Shopifyを含む構築方法全体の比較。
- Shopify APIとは：Admin・Storefront・Webhookの使い分けとレート制限をコードで解説：Flowの外で連携を作るときのAPI選び。
- Shopifyアプリ開発の始め方：配布方法の選び方とReact Router雛形での実装・審査要件：Flowトリガーを持つアプリの作り方。
- Shopifyの料金プランと手数料｜総額と乗り換えラインの判断：HTTP送信が使えるGrow以上への変更判断。
- iPaaSとは？仕組み・RPAとの違い・料金の数え方と導入判断をわかりやすく解説：Flowの外に出すときの選択肢。
