Shopify Flow / 新機能

ワークフローに「バージョン履歴」
誰が・いつ・編集/有効化/無効化したか が残る

すべてのワークフローで、編集・有効化・無効化が担当者名とタイムスタンプ付きで自動記録されるように。「動かなくなった」時に、ワークフロー詳細ページから履歴を開けば誰がいつ変えたかを追える。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. 記録される3つのアクション(図解)
  3. バージョン履歴に残る情報
  4. 従来 vs 今回の比較
  5. 利用条件・アクセス権限
  6. 確認手順(3ステップ)
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

これまで Flow のワークフローは「誰がいつ変更したか」を遡る手段が乏しかった。
今回から すべてのワークフローにバージョン履歴が付き、編集・有効化・無効化が 担当者(staff member)+タイムスタンプ 付きで自動的にログされる。

従来 : 変更の追跡が困難

ワークフローが急に動かなくなっても、誰がいつ編集・有効化・無効化したのかを体系的に追う手段が乏しかった。

今回 : バージョン履歴で可視化

編集・有効化・無効化が「誰が・いつ」付きで記録される。詳細ページから履歴を開いて過去バージョンも閲覧できる。

2記録される3つのアクション

ワークフロー Shopify Flow 編集 / edit 条件・アクションの変更 有効化 / activate ON にした 無効化 / deactivate OFF にした ログに記録 👤 担当者名 🕒 タイムスタンプ バージョン履歴
記録されるのは 編集(edits)・有効化(activations)・無効化(deactivations) の3アクション。それぞれに 実行した staff member と timestamp が紐づく。詳細ページから履歴を開くと、過去のバージョンを閲覧(browse)できる。

3バージョン履歴に残る情報

項目内容記事での記載
記録されるアクション 編集 / 有効化 / 無効化 明記あり
誰が(Who) 実行した staff member(担当者) 明記あり
いつ(When) タイムスタンプ 明記あり
過去バージョンの閲覧 詳細ページから履歴を開いて browse 可能 明記あり
過去バージョンへの復元(ロールバック) 本文には「閲覧(browse)」までの記述。復元・ロールバック可否は— 記載なし
履歴の保持期間 記載なし
変更差分(diff)の表示有無 記載なし
記事の URL 系の表現には「roll it back(差し戻し)」を匂わせるものもあるが、本文中で明示されているのは「閲覧(view / browse past versions)」まで。復元操作の有無・手順はドキュメントで要確認。

4従来 vs 今回の比較

項目従来今回(バージョン履歴)
変更の記録 なし/不明瞭 自動ログ 編集・有効化・無効化を記録
担当者の特定 追いにくい staff member が紐づく
変更時刻 追いにくい timestamp が残る
過去バージョンの確認 困難 詳細ページから browse 可能
対象ワークフロー すべてのワークフロー

5利用条件・アクセス権限

すべてのワークフローで利用可能

バージョン履歴は all workflows で使える。特定の条件下のワークフローに限定されない(個別の有効化設定の記載なし)。

Flow アプリにアクセスできる staff なら誰でも閲覧可

Flow アプリへのアクセス権を持つ staff member であれば、履歴の閲覧および過去バージョンの browse ができる(閲覧の追加権限要件は記載なし)。

対応プラン・対象国・有効化の要否(自動か手動か)についての明示は本文に 記載なし。導入前に管理画面とドキュメントで実際の挙動を確認すること。

6確認手順(3ステップ)

1

Flow でワークフロー詳細を開く

Flow アプリで対象のワークフローの詳細ページ(workflow detail page)を開く。

2

バージョン履歴を開く

詳細ページから version history を開くと、編集・有効化・無効化のログが時系列で並ぶ。

3

「誰が・いつ」を確認 / 過去版を閲覧

担当者名とタイムスタンプから変更者を特定。過去バージョンを browse して内容を確認。

「動かなくなった」時の初動はここ。まず version history を開き、直近の編集・無効化が誰によっていつ行われたかを確認するのが原因究明の最短ルート。

7技術者が押さえるべき5つのポイント

1. 全ワークフローに自動適用

version history は all workflows で利用可能。特定条件への限定や個別オプトインの記述はなく、既存ワークフローも対象になると読める。

who+when

2. 記録粒度は「3アクション × 担当者 × 時刻」

edit / activate / deactivate に staff member と timestamp が付く。フィールドレベル diff や変更理由(コメント)の記載はなく、属性の詳細は要検証。

3. 閲覧権限は Flow アクセス権に紐づく

Flow アプリにアクセスできる staff member なら誰でも履歴を閲覧・browse 可能。閲覧専用ロールや権限分離の記述はない=履歴は事実上オープンと想定して運用設計を。

4. ロールバック可否は未確定

本文は「view / browse past versions(閲覧)」まで。過去バージョンへの復元(restore / roll back)操作の有無は記載なし。差し戻し前提の運用設計はドキュメント確認後に。

API ?

5. API / Webhook・保持期間・他ログとの関係は記載なし

version history の Admin API / Webhook での取得、履歴の保持期間、ストアの「アクティビティログ」など既存監査ログとの関係についての言及は無い。プログラムからの監査自動化を狙う場合は事前にサンドボックスで挙動確認が必要。

8業務に活かせる3つのユースケース

USE CASE 1

ワークフロー障害の原因究明を最速化

課題
注文タグ付けや在庫通知などの Flow が「ある日から動かない/誤発火する」。だが誰がいつ何を変えたか分からず、調査が長引く。
打ち手
詳細ページから version history を開き、直近の編集・無効化のログ(担当者+時刻)を確認。変更タイミングと障害発生時刻を突き合わせる。
効果
「変更起因か外部要因か」の切り分けが即座にでき、復旧までの時間(MTTR)を短縮。
技術メモ
過去バージョンの内容は browse で確認可能。復元操作の可否は本文記載なしのため、戻す手順は別途ドキュメントで要確認。
USE CASE 2

複数担当・代理店運用での変更ガバナンス

課題
社内複数メンバーや外部パートナーが同じストアの Flow を触る運用で、無断変更・属人化・「言った言わない」が起きやすい。
打ち手
変更後は version history で「誰が・いつ・どのアクション(編集/有効化/無効化)」を必ず確認する運用ルールを敷く。レビュー観点に組み込む。
効果
変更の説明責任(アカウンタビリティ)が担保され、無断変更の抑止と引き継ぎコスト削減につながる。
技術メモ
Flow アクセス権を持つ staff なら誰でも閲覧可。閲覧制限の記載はないため、見られて困る運用情報をワークフロー内に書かない設計が安全。
USE CASE 3

監査・引き継ぎドキュメントの簡素化

課題
セール・キャンペーン前後で Flow の有効化/無効化を切り替える運用が多く、誰がどの自動化をいつ止めた/戻したかの記録を手作業で残している。
打ち手
有効化・無効化の事実は version history が自動で記録する前提に切替。手動の変更台帳をスリム化し、履歴をエビデンスとして参照する。
効果
記録漏れの解消と運用ドキュメント作成工数の削減。担当交代時の引き継ぎが履歴ベースで完結。
技術メモ
履歴の保持期間・エクスポート可否・API 取得は本文記載なし。長期監査要件がある場合は別途ログ保全の仕組みを検討。

9提案で使える1行サマリ

「すべての Flow ワークフローに バージョン履歴 が付き、編集・有効化・無効化が 『誰が・いつ』付きで自動記録される。
Flow にアクセスできる staff なら閲覧でき、障害時の原因究明とチーム運用のガバナンスが一段強くなる。
(過去版の復元・保持期間・API 連携は本文に記載なし、要ドキュメント確認)」