EC受注作業の自動化｜任せる処理・止める条件・再実行を決める

ネットショップの注文が増えてくると、確認や出荷の作業を少しでも減らしたくなります。ただし、最初の段階で決済や在庫、出荷指示などをまとめて自動化すると、途中でつまずいたときに何がどこまで終わったのか追えなくなってしまいます。まずは前後の変化を目視で追える「一処理」から小さく立ち上げるのが安全です。

ここでは、Shopifyでギフト向け生活雑貨30商品を扱う架空の店舗を例に進めます。体制は週120注文を担当者2人で扱い、自動化の確認に週90分、追加アプリ予算は0円（2026年10月時点の想定、確認日：2026年10月9日）です。この設定は確認手順を分かりやすく示すための架空のもので、ツールの利用条件や推奨工数ではありません。今回はShopify Flowを使い、対象のSKU（色や種類ごとの商品管理単位）を含む注文へ社内確認用のタグを1つ付ける処理を題材にします。GIFT-01はその対象となる管理コードです。

最初に、どの一処理を自動化する？

受注作業を自動化するときは、業務全体から影響先を追える一処理を選び、動かす前と動いた後の状態を明確に決めます。

ワークフローとは、「特定のきっかけに応じて条件を判定し、あらかじめ決めた処理を動かす手順」のことです。今回の架空店では、注文が入ったときに「特定の商品が含まれているか」を確かめ、対象の注文詳細画面へ社内確認用のタグを1つ追加する処理だけを扱います。決済の確定や在庫の変更、倉庫への出荷指示、購入者への連絡といった他の作業は含めず、完全に別の手動作業や別工程として残します。

担当の2人は、自動化を動かす前に「タグが付く前の状態」「タグが付いた後の状態」、そして「そのタグを見て次に誰が何を確認するのか」を手順書に書き出しておきます。タグの付与を影響が小さい処理とみなすのは、自店の業務の中で他の自動連携を勝手に引き起こさないと確かめた結果であり、どんな環境でもタグ付けが無条件に安全だからではありません。

ツール上で実行が「完了（Completed）」と表示されても、それはワークフローの実行が終わったことを示すだけで、必ずタグが付いたとは限りません。条件に合わずアクションを実行せずに完了する場合もあります。そのため、Flowの実行状態だけでなく、実際の注文詳細で目的のタグが付いたかを別々に確認します。また、タグが付いたとしても、それは社内での確認準備が整った目印にすぎず、実際の包装や出荷作業が完了したわけではない点も区別しておきます。

きっかけ・条件・処理・除外をどう書く？

「注文が来たら自動で処理する」という作業は、「きっかけ」「条件」「処理」「除外」の4つに整理すると迷わず組み立てられます。

それぞれの役割と、架空店での設定内容は次の通りです。

除外のルールを作っておくと、機械が判断に迷う注文を安全に人の確認へ回せます。このとき、注文データに空欄があったとしても、システム側で勝手に「数値の0」や「確認完了」とみなしてはいけません。

また、条件に合わなかった注文（条件外）は単に対象外だっただけで、エラーではありません。除外された注文も「これから人が確認する作業が残っている注文」であり、自動処理が正常に完了した注文とは区別して数えます。なお、画面上で指定する実際の変数や演算子は自店の環境で確認し、何を対象にし、何を人の確認へ残すのかを整理して進めます。

テストで確かめられるのは、どこまで？

ワークフローのテスト機能は、分岐のロジックや変数の受け渡しを確認するためのもので、本番ストアの更新や外部連携まで完了した保証にはなりません。

Shopify Flowのテスト仕様によると、テスト実行では顧客への通知送信や注文・商品の更新といったストアのライブデータを変更するアクションは行われず、ワークフロー内で最初の変更アクションに達した時点で処理が停止します。また、外部サービスへ接続するアクションも設定のプレビューを表示するだけで、実際のデータを返すことはありません。

テストで使う入力データには、ストアで実際に操作を行ってイベントを記録する方法、既存のストアデータを使った模擬イベントの作成、Sidekickによる模擬イベントの生成があります。実操作でイベントを記録する際は本番ストアへの影響を確認し、提供元の手順に沿って安全に行ってください。

架空店では、論理の確認として次の4つのパターンを用意して分岐を確かめます。

1. 対象SKUを含み、問題のない注文（処理へ進むか）
2. 対象SKUを含まない注文（条件外へ抜けるか）
3. 備考にギフトの個別要望がある注文（除外へ抜けるか）
4. すでに該当タグが付いている注文（除外へ抜けるか）

これらは架空の検証例であり、あらゆる店舗でこの4件だけで足りるという最低基準ではありません。また、テストの実行結果は本番の実行履歴（Recent runs）には残りません。テストの成功と本番の反映確認は別物として捉えておく必要があります。

受付・注文・反映確認を、どう数え分ける？

自動化を動かし始めたら、ログに表示された数字をそのまま「処理が終わった注文数」とみなさず、単位を分けて集計します。

Shopify Flowの監視仕様では、開始時刻や実行状態、完了したアクション、エラー、再試行などが確認できます。ここでの実行記録とはワークフローが一回動いた履歴そのものを指し、注文IDとは個別の注文を識別する番号を指します。

架空店における7日間の集計例を以下の表にまとめました。

表の中で、受信記録の126回と固有注文の120件には6回の差があります。この差は原因が確認できるまで未確認としてログを調べ、安易に通信の重複や再送と決めつけないようにします。また、タグの付与が確認できた20件についても、社内タグが付いたことの確認であり、実際の包装や出荷準備が完了したわけではない点に注意します。

エラーの後、すぐ再実行してよい？

実行ログにエラーが出たときは、原因を直さずにすぐ再実行ボタンを押してはいけません。状況を確かめずに動かすと、外部連携の二重処理や、内容が変わった注文への誤適用につながるためです。

再実行とは過去の処理をもう一度動かす操作であり、データを元の状態に戻す巻き戻しではありません。Shopify Flowの手動再試行仕様によると、手動再試行では注文作成時の元トリガーデータが使われる一方で、Get data（データ取得）アクションや条件判定、実行アクションでは再試行した時点の「最新データ」が参照されます。最初のエラー以降に注文のキャンセルや住所変更、手動でのタグ付けが行われていると、当時のデータと現在のデータの食い違いによって予期せぬ結果になります。

Shopify Flowで手動再試行を行うには、以下の条件を満たしている必要があります。

• 元の実行が「実行中（In progress）」や「待機中（Waiting）」でないこと
• 関連するワークフローが現在も有効（オン）になっていること
• 再試行するトリガーが、元の実行トリガーと一致していること
• 先にエラーの原因が特定され、修正されていること

架空店でエラーとなった1件についても、担当者はすぐ再実行せず、注文詳細を開いて該当タグがすでに付いていないか、キャンセルや配送先変更がないか、外部への連絡が飛んでいないか、元の実行IDは何だったかを確認します。状況がはっきりしない場合は自動で再実行せず、手作業の確認ラインへ回します。

異常時は、何を止めて手作業へ戻す？

動作に異常を感じたときは、影響が出ている個別の実行と、該当するワークフローの新規開始を分けて止めます。販売の受付自体まで止める必要があるかどうかは、業務への影響を確認したうえで店舗ごとに判断します。

Shopify Flowの個別取消しと監視仕様で示されている通り、進行中やレート制限中の個別実行を取り消すことができます。個別の実行を取り消してもワークフロー自体はオンのままなので、新しい注文が入れば再び処理が動きます。一方、ワークフロー自体をオフにすると、新しい実行の開始が止まり、進行中だった実行も取り消されます。

注意したいのは、個別取消しやワークフローの停止を行っても、すでに実行が完了したデータ（すでに付いたタグや送信済みの外部データ）が元に戻るわけではない点です。取消しは巻き戻しではないため、すでに完了したアクションの結果は人の目で確認する必要があります。操作を行ってから反映されるまでに時間がかかる場合もあるため、停止状態が画面に反映されたことを確かめます。

架空店では、手動作業へ切り替える際に以下の項目をシートで共有しています。

• 自動処理を停止する権限を持つ担当者
• 停止時点で未処理だった注文IDの一覧
• 注文詳細や外部ツールでどこまで反映されたかの確認手順
• 引き継ぎ後に手作業で確認を行う担当者
• 原因が解消された後に自動化を再開するための条件

何件のエラーで止めるかという共通の基準はありません。自店の体制で手作業のリカバリーが追いつかなくなる前に止める基準を、現場の2人で決めておきます。

再開前に、どの記録を残す？

エラーの原因を解消しても、必要な記録を残さず、手作業の引き継ぎが中途半端なままワークフローをオンに戻してはいけません。

再開前に記録しておく項目は次の通りです。

• 該当の実行ID
• 対象となった注文ID
• 入力されたトリガーデータ
• 通過した条件分岐の経路
• 実行されたアクションの内容
• エラーメッセージの内容
• 外部連携への反映状況
• 手動で対応した内容
• 再試行を行った場合はその日時と結果

これらの記録を自社で保管しておくべき理由として、プラットフォームのログ保持期間があります。Shopify Flowの実行履歴保持仕様の通り、Flowの実行履歴は完了後「14日間」で削除されます。架空店では週90分の確認枠の中で、重要な記録を消える前に自社の台帳へ移します。この14日間はツールの画面仕様であり、店舗の法定帳簿保存期間とは異なります。

また、再開前には手動引き継ぎ中や手動対応済みの注文を台帳に記録し、自動の再実行や再試行の対象から外す運用を決めておきます。既タグの除外条件だけでは、手動確認中でまだタグが付いていない注文をカバーできないためです。

原因の修正が完了し、手動へ渡した注文の扱いが確定して、今回のタグ処理で宙に浮いた未処理の注文がゼロになったことを確認したうえで自動化を再開します。ここでいう未処理ゼロとは全商品の出荷完了待ちではなく、タグ付けの対象注文がすべて整理された状態を指します。

---

関連記事

• 受注管理システム（OMS）の選び方｜導入時期・比較項目・費用対効果
• ネットショップのギフト対応｜ラッピング・納品書・送り先を間違えない手順
• ネットショップの誤出荷防止｜ピッキング・検品・梱包の確認手順