Shopify Flowのテスト実行では、ストアデータを変更するアクションは実行されないとShopifyが説明しています。したがって、まずテストイベントで起動条件、条件分岐、変数の値を確かめ、外部サービスや実注文に影響する動作は別途管理された方法で確認してから有効化します。(公式のワークフローテスト説明)
この記事は、注文処理を自動化する越境セラー、店舗運営担当者、チーム責任者向けです。
米国など複数市場の注文条件や、Shopify Marketsの情報を含む分岐を確認したい場合にも使えます。
テスト記録、承認、実行後の確認をチームで引き継ぐための手順も整理します。
店主は自動化する範囲と例外を先に決める
最初に、ワークフローで減らしたい手作業と、自動処理の対象外にする注文を区別します。たとえば注文へのタグ付けを自動化する場合でも、住所や決済状態に不整合がある注文は手作業で確認する、といった業務ルールを先に書き出します。
Shopify Flowは、設定したトリガーから条件判定を経てアクションを実行するワークフローです。作成画面の流れと店舗独自の処理ルールを合わせて確認し、Shopifyのワークフロー作成説明を参照しながら、対象範囲を明確にします。
有効化前に人が確認する操作も決めます。支払い状態の確認、返金やキャンセルの判断、出荷保留の解除など、結果が顧客や在庫に影響する処理を自動化に含めるなら、例外時の担当者と停止方法が決まるまで有効化を保留します。
判断条件リスト
- 例外注文を手作業に回す条件と担当者が明確なら、例外用の条件分岐を設けます。決まっていなければ、自動処理の対象を限定します。
- 自動化の結果が注文や顧客への実際の通知に影響するなら、通知先と確認責任者を明記します。責任者が不明なら、そのアクションは承認まで保留します。
- 実注文への変更をテスト画面だけで確認しようとしているなら、テスト結果を実動作の証明にせず、管理された別の確認手順を用意します。
フロー作成担当者はイベントとテストデータを揃える
トリガーは、ワークフローが応答すべき注文イベントに合わせて選びます。イベントの選択が異なると、条件式が正しくても期待する場面でワークフローが起動しないため、画面上の名称だけで決めず、店舗で起こる業務イベントとの対応を確認します。
Shopify Flowの公式説明では、テストに記録済みのイベントを使う方法と、テストイベントを作成する方法が案内されています。記録済みイベントは実際のイベント情報を参照したい場合に、作成するテストイベントは必要な条件を含むデータが手元にない場合などに検討できます。利用できる方法や画面は、実際の管理画面と公式テスト手順で確認してください。
テストイベントに注文と市場に関する情報が不足していれば、Shopify Marketsの条件を狙いどおりに検証できません。Marketsの仕組みや店舗側の設定を確認し、テスト対象イベントに判定材料が含まれるかを確かめます。Flowで市場情報を扱う場合は、Marketsの公式説明とGet market dataアクションの説明を参照し、対象の値と処理の範囲を確認します。
運営担当者は分岐と変数を照合する
条件分岐は、条件を満たすケースだけでなく、満たさないケースも用意して確認します。両方の結果を見れば、条件の記述ミスだけでなく、条件に使うデータ自体がイベントに含まれていない問題も切り分けやすくなります。
変数のプレビューでは、画面に表示された値を予想だけで判断せず、テストイベントに含まれる注文情報と照合します。市場名や注文属性を条件に使う場合、イベントの値と条件式が同じ意味を指しているかを確認し、食い違いがあれば条件かデータのどちらに原因があるかを調べます。
確認内容を、たとえば次のような記録にまとめます。これは記入例であり、実際のイベント名や結果は店舗のテスト内容に合わせて置き換えます。
workflow: "注文処理（記入例）"
test_event: "[イベント名]"
market_value: "[イベントに含まれる市場情報]"
expected_branch: "[条件成立時の想定経路]"
observed_branch: "[実行結果で確認した経路]"
variable_check: "[注文データとの照合結果]"
external_action: "未検証"
approval: "保留"
受け入れ記録の見方： 想定経路と確認した経路が一致し、変数が対象注文の値と合っていることを確かめます。「未検証」が残るアクションがある場合は、テスト通過とは分けて記録します。
テスト結果が期待と違うときは、すぐに条件式を書き換えず、テストイベントに判定に必要な値があるかを先に確認します。入力データが違っていれば、条件を変更しても誤った分岐を隠すだけになることがあります。
履行・カスタマーサポート担当者は実際の影響を分ける
アクションは、テスト画面で結果を確認するもの、外部サービスと連携するもの、実際の注文や履行に関わるものに分けて扱います。Shopifyは、テスト実行ではストアデータを変更するアクションを実行せず、外部サービスへのアクションはテストでシミュレーションできない場合があると説明しています。(テスト実行の制限)
このため、プレビューでアクションが表示されたことを、メール通知が届いた、外部サービスで処理が完了した、履行が進んだという証拠にしないでください。担当者は、実際の通知先や外部側の記録を確認する方法を決め、実運用での確認が必要な操作には実施者と確認者を割り当てます。
ログ出力を診断に使う場合は、値を何の確認に使うのかを決めてから設定します。ShopifyのLog outputアクションの説明も確認し、個人情報や注文情報を記録へ含める必要があるか、チームの情報管理ルールに沿って見直します。
責任者は承認と運用記録を引き継ぐ
有効化の前には、店主が決めた適用範囲、フロー作成担当者のテストイベント、運営担当者の分岐確認、履行担当者が残した未検証項目を一緒に確認します。責任者は、例外の処理方法と未確認の外部アクションを把握したうえで、対象店舗と有効化の可否を承認します。
有効化後は、Shopify Flowの実行記録を見て、想定しない経路や失敗がないかを確認します。記録は無期限の監査保管庫として扱わず、公式のワークフロー監視と実行記録の説明で保持範囲を確認します。チームで長く参照する証跡が必要な場合は、必要な情報を社内記録にも残します。
引き継ぎカードには、次の項目を含めます。
- ワークフローの目的と適用する店舗・注文
- 使用したテストイベントと、想定・確認した分岐
- 変数の照合結果と、未検証の外部アクション
- 有効化の状態、承認者、運用記録の確認担当
- 異常時に手作業へ戻す条件と、連絡先
複数の担当者が別の時間帯から確認する場合は、ワークフローの実行結果と、使用した端末や接続環境の違いを別々に記録します。脱敏した画面記録には、確認日時、対象の画面、確認者を添え、注文者情報や認証情報は写さないようにします。
よくある質問
テストイベントはどのように選びますか？
確認したいトリガーと条件に必要な注文情報が含まれるものを選びます。記録済みイベントで必要な値が不足している場合は、テストイベントの作成を検討し、管理画面で使える方法を確かめます。
テスト実行で実際の注文は変更されますか？
Shopifyの説明では、テスト実行でストアデータを変更するアクションは実行されません。ただし、この制限を外部サービスの動作確認にまで広げて解釈せず、連携先での結果は別途確認します。
条件分岐を確認したのに結果が想定と違う場合はどうしますか？
まずイベントに含まれる値を確認し、その後に条件式と変数の参照先を照合します。入力の不一致が解消するまでは有効化せず、条件成立・不成立それぞれの結果を記録します。
テストが通れば、そのまま有効化できますか？
テスト通過だけでは、外部サービスへの連携や実注文に関わる実動作まで検証できたことになりません。未検証の操作、例外時の担当者、承認範囲を確認し、必要な実環境確認を済ませてから有効化します。
遠隔Macは実行条件ではなく確認環境の選択肢
Shopify Flowの利用に遠隔Macが必須というわけではありません。すでにチームで安全に管理できる端末があり、管理画面の確認や記録に支障がなければ、現在の環境で受け入れ手順を運用できます。
一方、担当者ごとに端末の状態が異なる、交代勤務で同じ管理環境を引き継ぎにくい、macOS上の管理画面表示も確認したい、といった課題がある場合は、確認用の環境を別に用意する選択肢があります。NodeMiniのシリコンバレーのMac環境やバージニアのMac環境は、遠隔からMacで管理画面を確認する用途の候補として、利用条件と環境を個別に確認できます。
共有端末の利用には、ブラウザーの状態や作業者の交代で確認条件が揺れやすい面があります。自前のMacを買う方法なら継続利用しやすい一方、購入費用と保守を負担します。遠隔レンタルは手元に実機を置かずに利用できますが、物理機器への接続が必要な作業や、長期の高負荷利用には適さない場合があります。Flowのテスト・承認手順を先に整えたうえで、跨時区での管理画面確認や記録用にMac環境も必要なら、NodeMiniの利用条件を照らし合わせて選びます。