この記事でわかること
この記事の目次Contents閉じる開く
在庫が切れたら通知したい。高額注文にタグを付けたい。毎朝、未発送の注文をまとめてメールで受け取りたい。
こうした業務の自動化を検討すると、App Storeには相応の数のアプリが並んでいます。ただ、その前に確認しておく価値があるのがShopify Flowです。Basic、Grow、Advanced、Plusのすべてのプランで無料で使える、Shopify標準の自動化ツールです。
問題は、Flowで足りるのか、アプリが必要なのかの判断が難しいことです。「Flowでできます」という情報も「Flowでは限界があります」という情報も両方あり、どちらも部分的には正しいためです。
幸い、Flowの制限値はShopifyヘルプセンターに具体的な数字で公開されています。 この記事では、その上限を一覧にまとめ、Flowで完結するケースとアプリが必要になるケースの境界線を整理します。調査日は2026年8月31日です。
先に結論
Flowは全プランで無料ですが、プランによって使える機能が違います。 外部サービスへHTTPリクエストを送るアクションはGrow以上、カスタムパートナーアプリのタスクはPlus限定です。Basicプランでは外部システム連携が事実上できません。
制限値は公開されています。 ワークフロー1,000本、データ取得アクションあたり100オブジェクト、待機ステップ40個、スケジュール実行の最短間隔10分。これらを超える要件があるなら、アプリの検討に進む合理性があります。
もっとも多い誤解は「Flowは通知しかできない」というものです。 実際にはタグ付け、コレクション追加、商品の公開・非公開、メタフィールド更新、顧客削除、下書き注文の集計といった書き込み操作が可能で、スケジュール実行にも対応しています。
逆に、Flowで足りるのにアプリを入れているケースもよくあります。 在庫アラート、注文タグ付け、日次サマリーメールあたりは、Flowの公式テンプレートでそのまま作れます。
Flowの基本構造とプラン要件
Flowは、ストアやアプリで起きたイベントを監視し、それに応じた処理を実行する仕組みです。トリガー（何が起きたら）、条件（どういう場合に）、アクション（何をするか）を組み合わせてワークフローを作ります。
使うには、App Storeから無料のShopify Flowアプリをインストールします。
プラン要件は次のとおりです。
| 項目 | 対応プラン |
|---|---|
| Shopify Flow本体 | Basic / Grow / Advanced / Plus（無料） |
| Send HTTP Request アクション | Grow / Advanced / Plus |
| カスタムパートナーアプリが作成したタスク | Plus のみ |
| 使用量の上限 | プランごとのAPIレート制限に準拠 |
ここで実務上いちばん効くのがSend HTTP Requestです。任意の外部サービスへリクエストを送るアクションで、これが使えるかどうかで「Shopifyの中で完結する自動化」と「社内システムや外部SaaSと連携する自動化」の境目が決まります。Basicプランの場合、外部連携は基本的にできないと考えたほうが安全です。
公開されている上限値の一覧
Shopifyヘルプセンターのトラブルシューティングページと最適化ページに記載されている制限を、一覧にまとめます。これがFlowとアプリの境界線を判断する材料になります。
| 制限項目 | 上限 |
|---|---|
| ストアあたりのワークフロー数 | 1,000本（有効・無効を問わず） |
| 同一トリガーを使うワークフロー | 10本を超えると警告が表示される |
| ワークフロー内の待機ステップ | 40個 |
| 待機ステップの合計待機時間 | 90日 |
| 条件の設定値のサイズ | 50KB未満 |
| データ取得アクションが返すオブジェクト | 1ワークフローあたり最大100件 |
| スケジュール実行の最短間隔 | 10分 |
| スケジュール実行の最長間隔 | 1年 |
| ワークフローの各セクションの実行時間 | 36時間 |
いくつか補足します。
ワークフロー1,000本は、通常のストアではまず届きません。 ただしテンプレートの取り込みや複製を繰り返すと近づきます。上限に達すると新規作成、複製、インポート、テンプレートのインストールがすべてブロックされます。
同一トリガー10本の警告は、性能上の意味があります。 同じトリガーを使うワークフローは並列で実行されるため、イベントが起きるたびに全部が同時に走ります。互いに競合したり、APIレート制限を食い合ったりします。Shopifyの推奨は、条件分岐で1本にまとめることです。
データ取得の100件上限が、実務でいちばん引っかかります。 「Get order data」「Get product data」といったアクションは、1ワークフローあたり100オブジェクトを返す設計です。これを超えると性能問題が起きます。回避策として示されているのは、ワークフローの実行頻度を上げてクエリの結果を100件未満に収めることです。
セクションの36時間制限は、待機ステップで区切られます。 待機ステップのないワークフローは全体で1セクション扱いです。一時的なエラーが発生した場合、Flowはリトライを繰り返しますが、この36時間を超えると失敗します。
Flowで完結できること
制限を先に見たので、次はできることを整理します。
イベント駆動の処理。 注文作成、在庫数変更、顧客タグ追加、フルフィルメント準備完了など、ストア内の出来事をトリガーにできます。アプリが提供するトリガー（レビュー投稿など）も利用できます。
スケジュール実行。 「Scheduled time」トリガーを使うと、指定した日時に実行したり、日次・週次・月次で繰り返したりできます。繰り返しを止める終了条件（回数指定、日時指定）も設定できます。ただしこのトリガーはストアのデータを持ってこないため、「Get product data」などのデータ取得アクションと組み合わせる必要があります。
書き込み操作。 タグの追加・削除、コレクションへの商品追加、商品の公開・非公開、メタフィールドの更新、顧客の削除、フルフィルメントオーダーの処理。読み取り専用のツールではありません。
繰り返し処理。 「For each」アクションでリストをループできます。データ取得アクションはリストを返すため、単一のリソースを要求するアクション（タグ追加など）と組み合わせる際は、この For each が必須になります。Flowで最初につまずくポイントがここで、「Data not found」というエラーの主因です。
外部への通知と連携。 メール送信、Slack通知、Google Sheetsへの書き込み。Google Sheetsについては専用のコネクタがあり、Googleアカウントを連携させて使います。
エラーの検知。 「Workflow error occurred」トリガーを使えば、ワークフローが失敗したときに通知を受け取るワークフローを作れます。公式テンプレートも用意されています。自動化を業務に組み込むなら、これは最初に作るべき1本です。
Shopifyは公式テンプレートを多数用意しており、たとえば次のようなものが該当します。毎日、在庫ゼロの商品をメールでまとめて送る。2日以上未発送の注文にタグを付ける。作成から90日経った商品の「新着」タグを外す。週次で在庫僅少バリアントの一覧をメールする。チャージバックのあった注文の顧客にタグを付ける。
このあたりの用途で有料アプリを検討しているなら、まずテンプレートを確認する価値があります。
アプリが必要になる境界線
では、どこからがアプリの領域か。判断基準を4つに整理します。
外部システムとの連携が必要で、Basicプランの場合
Send HTTP RequestがGrow以上のため、Basicプランでは外部APIを叩けません。基幹システム、社内の在庫管理、外部の帳票サービスなどと繋ぎたい場合、Basicプランのままなら連携アプリが必要になります。プランを上げるか、アプリを入れるか、というコスト比較になります。
一度に100件を超えるデータを処理したい場合
データ取得アクションの100件上限は、回避策があるとはいえ扱いにくい制約です。数千件の商品を一括で更新する、全顧客をセグメント分けし直す、といったバッチ処理には向きません。この領域は、一括編集系のアプリの守備範囲です。
Shopifyが示す回避策（実行頻度を上げて100件未満に分割する）は、「processed」のようなタグで処理済みを管理する設計になります。作れないわけではありませんが、設計と検証の手間を考えると、既存のアプリを買ったほうが安いケースは多いはずです。
高頻度トリガーと大量データが重なる場合
在庫数変更のような高頻度トリガーは、ストアで在庫が動くたびに発火します。ここに大量のデータ取得を組み合わせると、APIレート制限に達して「GraphQL throttled」エラーが出ます。このエラーは他のワークフローの実行にも影響するため、放置できません。
Shopifyは条件と待機ステップの組み合わせでワークフローを分割する方法を示していますが、要件によっては素直に専用アプリを使うほうが確実です。
Flowにトリガーやアクションが存在しない領域
Flowが扱えるのは、Shopifyが提供するトリガー・アクションと、アプリが提供するタスクの範囲です。たとえばテーマの編集、商品画像の生成、記事本文の作成といった処理は、Flowの守備範囲外です。
なお、アプリが提供するトリガーは必要なデータを持っていないことがあります。「レビュー投稿」トリガーがメールアドレスだけを返し、顧客オブジェクトを返さない、といったケースです。この場合は「Get customer data」でデータを取り直す必要があり、それでも解決しなければアプリ開発者に問い合わせることになります。
Flowを実務で安定させるコツ
導入時に押さえておくと事故が減る点をまとめます。
データ取得アクションには必ずクエリフィルターを付けます。 フィルターがないと、APIは全件を返すか何も返さないかのどちらかになります。性能問題だけでなく、意図しない対象に処理が走る危険があります。
クエリフィルターの構文と値は必ずテストします。 間違ったフィルターを書くとクエリ全体が無視され、フィルターなしと同じ状態になります。「Log Output」アクションで返ってきたデータを確認するのが確実です。
リストとメタフィールドの扱いに注意します。 metafields のリストをループするのではなく、metafield オブジェクトで個別に取得します。HTMLを含むメタフィールドをループすると、処理するデータ量が跳ね上がります。
有効化する前にテストデータで検証します。 Flowにはテスト機能があり、実データに触れる前に動作を確認できます。
エラー通知のワークフローを最初に作ります。 通知は1つのワークフローバージョンにつき1回に制限されているため、通知そのものが騒がしくなることはありません。
同じデータを複数のステップで使うことは、最適化の対象外です。 Flowは同じフィールドの利用を解析して1回だけ取得するため、ここを気にする必要はありません。
まとめ
Shopify Flowは全プランで無料の標準機能で、通知だけでなくタグ付け、コレクション操作、メタフィールド更新、スケジュール実行まで対応しています。在庫アラートや日次サマリー、注文タグ付けといった定番の用途は、公式テンプレートでそのまま作れます。
一方で、制限値も明確です。データ取得100件、ワークフロー1,000本、待機ステップ40個、スケジュール最短10分。そしてBasicプランではSend HTTP Requestが使えず、外部連携ができません。
アプリを検討する前に確認すべきなのは、その業務がこの制限の内側にあるかどうかです。内側なら、Flowで作って月額のコストをゼロにできます。外側なら、アプリを入れる合理的な理由があります。
自動化アプリの比較記事は数多くありますが、「そもそもFlowで足りないか」を先に判定するほうが、選定の精度も運用コストも改善します。
Sources:
自分が所有する2つのShopifyストアの間を、Shopifyは何も同期しません。ロケーションは1ストアの中の概念、Marketsは1ストアから多国を売る機能、Shopify Collectiveはドロップシップの関係で、1商品100バリエーションの上限があり、アンインストールすると取り込んだ在庫が0になります。つまりマルチストア同期は完全にアプリの領域なのですが、実在する6本のアプリは6種類の別々の単位で課金しています。Syncioは宛先ストアに商品数、供給元に注文数。Tipoは宛先ストアの全バリエーション数（同期していない分も含む）。Synkroの月25ドルプランは接続ストアごとに25ドル。Trunkは全チャネル合計の直近3か月平均注文数。同一条件の2ストア構成で見積もると、月額はおよそ10ドルから119ドルまで開きます。2026年9月2日にShopify App Storeで確認しました。