「実際のショップデータ」で ワークフローを試せるようになった

図解 ： Shopify Flow — 既存ショップデータでワークフローのテストイベントを生成 Shopify Flow / 改善（Apps） 「実際のショップデータ」で ワークフローを試せるようになった 過去の注文・顧客などの本物のレコードをテストイベントとして指定可能に。さらに Sidekick が AI で分岐パスを解析し、テストケースを自動生成してくれる。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： テスト実行までの流れ 「実データテスト」で何ができるか 従来 vs 今回アップデートの比較 利用イメージ（4ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか Shopify Flow のワークフローを 「実際のショップデータ」を使ってテスト できるようになった。 さらに「Generate test events」ボタンで Sidekick がワークフローの分岐パスを解析し、テストケースを自動生成 する。 従来 ： ダミーデータで動かす テストするには、ありえそうなデータを手で書いて流すしかなかった。本当に作動するか自信が持てない。 今後 ： 本物の注文・顧客を選ぶ 「先週の不正注文」「特定の顧客」を指名してテストできる。Sidekick はそれらを自動でかき集めて分岐網羅もしてくれる。 2 仕組み図解 ： テスト実行までの流れ Sidekick が ワークフロー側の if 分岐／条件を読んで 「このパスを通すための実データはどれか」を探してくる流れ。 生成されたケースは レビュー・編集・削除可能 、自分でケースを追加することもできる。生成直後にそのままテスト実行できる（追加セットアップ不要）。 3 「実データテスト」で何ができるか 回帰テスト 「次は止まるか」を確認 先週の不正注文を再生し、組んだブロック用ワークフローが本当に発火するかを確認できる。 誤発火チェック 「他は止めないか」を確認 通常の注文に対してブロックが誤発火しないかをテストとして追加できる。 分岐網羅 パスを自動で網羅 Sidekick がワークフロー内の分岐を解析し、それぞれを通す候補データを引っ張ってくる。 4 従来 vs 今回アップデートの比較 項目 従来 今回アップデート テストデータ 手作り ダミー値を都度入力 実データ ショップの過去レコードから選ぶ 分岐パスの洗い出し 人がワークフローを読んで決める Sidekick が自動解析 テストケースの作成 1件ずつ手で作る 「Generate test events」で一括生成 生成後の編集 — 編集・削除・自分で追加が可能 セットアップ テスト用のデータを別途用意 no further setup required ボタンで即実行 5 利用イメージ（4ステップ） 1 ワークフローを開く テストしたい Flow のワークフローを開く。 2 「Generate test events」 Sidekick が分岐を解析し、実データを当て込んだケースを自動生成。 3 ケースをレビュー 不要なケースを削除、必要なケースを追加。手動の指名もここで。 4 そのままテスト実行 追加セットアップ不要で即時に動作確認。 本文の " You can test it immediately, no further setup required. " の通り、生成直後にそのまま走らせられる点が運用上の大きな改善点。 6 技術者が押さえるべき5つのポイント 1. Sidekick がコアエンジン テストケースの自動生成は Shopify の AI アシスタント「Sidekick」が担当。ワークフロー側の分岐構造を読み、各パスを通すデータを実データから探し当てる。 2. テスト対象は「実データ」 orders／customers など実際のショップレコードを指名できる。本番に近い検証が ipso facto 可能になる一方、 本番データを参照する点 は運用ポリシーで意識すること。 3. 生成結果は編集可・追加可 「Review the generated cases, edit or remove any that don't apply, and add your own.」と明記。AI 任せにせず、運用観点で必要なケースを足し引きする使い方を前提に設計されている。 4. 「発火する／しない」の両面が組める 「不正注文 → ブロック発火」と「通常注文 → ブロックしない」の 正例／負例 を 1 ワークフローに同居させられる。回帰テストの観点で重要。 5. API／対応条件の言及は記載なし Changelog 本文には 対応プラン・対応リージョン・API 経由の操作可否 については記載がない。Admin GraphQL での自動化や、CI から呼び出す等のニーズは ドキュメント側で別途確認 すること（記事は documentation と Shopify community への参照リンクを提示している）。 7 業務に活かせる3つのユースケース USE CASE 1 不正注文ブロック ワークフローの回帰テスト整備 課題 「次の不正注文をブロックする」ワークフローを組んだが、本当に発火するか・通常注文を巻き込んでいないかが確認しづらかった。 打ち手 過去の不正注文を指名してテスト ＋「通常注文では発火しない」テストも追加 → 双方向のテストケースを Flow 内に常備する。 効果 ワークフロー改修時の検証コスト削減。Sidekick の生成ケースで分岐網羅も担保しやすい。 技術メモ 正例（ブロック発火）と負例（通過）を意識的に並べることで、運用変更時の「気づかぬ誤発火」を発見しやすくなる。 USE CASE 2 複雑な分岐ワークフロー（VIP 判定／在庫補充／返品トリアージ等）の網羅テスト 課題 条件分岐が多いワークフロー（VIP 顧客判定、自動補充、返品ルーティング等）は、人が想像しただけではパス漏れが起きやすい。 打ち手 「Generate test events」でパス別ケースを自動生成 → 出てきたケースを「これは現実に起きる／起きない」で取捨選択。 効果 テスト設計の人件費を削減しつつ、抜け漏れに気づける。新規実装時のコールドスタート問題に効く。 技術メモ Sidekick の提案 ＝ そのまま採用ではない前提（記事も「edit or remove」を明言）。レビュー工程を運用フローに組み込むこと。 USE CASE 3 受託案件の「動作保証エビデンス」としてテストイベントを納品物に組み込む 課題 Flow を構築納品しても、クライアント側で「本当に意図通り動くのか」を判断する材料がなく、口頭説明に頼っていた。 打ち手 Sidekick 生成 ＋ 自前追加で代表的なケースを Flow に登録し、ワークフローと一緒にテストイベント群を引き渡す。 効果 納品後のクライアント自身の検証・改修判断が容易に。バグ報告時の再現データとしても流用できる。 技術メモ テストイベント自体が「仕様の生きたサンプル」になる。要件定義書の補完ドキュメントとして位置づけられる。 8 提案で使える1行サマリ 「Shopify Flow のワークフローを 本物のショップデータ でテストできるようになり、 さらに Sidekick が分岐パスを解析してテストケースを自動生成 。 『発火する／しない』の両方を実データで検証でき、追加セットアップ不要でその場で実行できる。」 source ： changelog.shopify.com / flow-sidekick-generates-test-cases-for-your-workflows generated 2026-05-23