Shopify Flowの新規トリガー「Product updated（商品が更新されたとき）」を検証。価格・タグ・メタフィールドの変更で、アプリなしでワークフローを動かす

商品の価格やタグ、メタフィールドが変わったタイミングで、Shopify Flow（以下、Flow）のワークフローを動かしたい。これは、よくいただく相談のひとつです。ところが、これまでの Flow には、商品の「どの項目が変わったか」を見分けて動くトリガーがありませんでした。そのため、変更を見張るアプリを別に入れる必要がありました。

Shopify Editions Fall '26 で紹介された「Product updated」（日本語ヘルプでは「商品が更新されたとき」）トリガーを使うと、見張る項目を自分で選べます。アプリを入れなくても、Flow だけで「価格が変わったら」「このメタフィールドが変わったら」という自動化を組めるようになりました。

本記事では、開発ストアにワークフローを8本作り、商品を15通りに変えて、どの変更で、どのワークフローが動くかを確かめました。ヘルプには書かれていない、実行履歴の読み方や、ワークフロー同士の連鎖についても紹介します。

これまでとの違い

Flow のトリガー（ワークフローが動き始めるきっかけ）には、以前から「商品が追加されたとき」など、商品に関するものがありました。ただ、商品の価格・タグ・メタフィールドといった項目ごとの変化は、区別して扱えませんでした。メタフィールドは、商品などのデータに、ストア独自の項目を足す仕組みです。

2026年7月の時点で、私も Xのポスト で「メタフィールドの更新をきっかけに Flow を動かすには、アプリが必要」と紹介していました。今回のトリガーで、少なくとも商品については、この前提が変わります。

トリガーの設定：見張る項目を最大5つ選ぶ

ワークフローのトリガーに「Product updated」を選ぶと、「product のフィールドを選択」という欄が出ます。ここで、見張る項目を1〜5個選びます。選んだ項目のどれかが変わったときだけ、ワークフローが動きます。

「フィールドを選択」を押すと、選べる項目の一覧が開きます。タイトル、タグ、ステータス、説明文、販売元、商品タイプ、カテゴリーといった商品そのものの項目のほか、バリエーションの価格・比較対象価格・バーコード、オプション、メディア、バンドル、統合リスティングの項目も選べます。在庫数は、この一覧にはありません。在庫数の変化には、以前からある別のトリガー「Product variant inventory quantity changed」を使います。

メタフィールドは「定義」か「名前空間」で指定する

メタフィールドを見張るときは、一覧の metafield.value（商品）か variants.metafield.value（バリエーション）の右にある「＋」を押します。すると、次の2通りから選べます。

• 定義を1つ選ぶ：例えば custom.release_date のように、特定のメタフィールドだけを見張る
• 「ネームスペースのみを使用」：名前空間（custom などメタフィールドをまとめる単位）を入力し、その中のメタフィールドをまとめて見張る

どちらの指定でも、5つの枠のうち1つとして数えます。定義の選択画面には「定義を追加」ボタンもあり、そこからメタフィールドの定義を新しく作れます（別のタブで定義の作成画面が開きました）。

見張る項目によって、使える変数が変わる

トリガーのあとにつなぐ条件やアクションで使える変数（商品の情報を差し込む入れ物）は、見張る項目によって変わります。バリエーションの項目（価格など）を見張ると、product と productVariant と shop が使えます。一方、販売元だけを見張るように切り替えると、それまで使っていた {{productVariant.id}} に「『productVariant』は無効です。この変数を置き換えてください。」という警告が出ました。ワークフローを複製して見張る項目を変えるときは、後ろのステップの変数も見直す必要があります。

見張る項目を変えたワークフローを7本作って試してみた

見張る項目だけを変えたワークフローを7本作りました。アクションには、実行履歴に文字を書き出すだけの「Log output」を置きました。どれも、商品のデータは変えません。販売元を見張るワークフローだけは、連鎖を確かめるために、タグを1つ付けるアクションも加えました。

このうえで、テスト用の商品を1つ作り、価格・タグ・ステータス・メタフィールド・販売元を1つずつ変えて、Flow の「最近の実行」に何が残るかを確かめました。

どの変更で、どのワークフローが動いたか

テスト用の商品を1つ用意し、表の左の列にある操作を1回ずつ行いました。操作のたびに Flow の「最近の実行」を開き、どのワークフローの実行記録が増えたかを確かめています。

表の見方は次のとおりです。

• 行：商品に行った操作（上から順に実施）
• 列：見張る項目だけを変えたワークフロー
• ●：その操作の直後に、そのワークフローの実行記録が残った（＝動いた）
• –：実行記録が残らなかった（＝動かなかった）

基本の動きは、ヘルプの説明どおりでした。見張る項目として選んだものが変わったワークフローだけが動き、それ以外は動きません。例えば、ステータスを変えたときに動いたのは「ステータス」を見張るワークフローだけで、価格やタグを見張るワークフローは動きませんでした。

ただ、表をよく見ると、直感と少し違う動きが3つあります。順に説明します。

① 商品を新しく作っただけで、価格を見張るワークフローが動く

表のいちばん上の行です。商品を新しく作ると、価格を見張る2本（「価格」と「タグ＋価格」）が動きました。

理由は、価格が「商品」ではなく「バリエーション」の項目だからです。バリエーションは、サイズや色ごとの販売単位のことです。サイズや色の違いがない商品でも、Shopify の内部では必ずバリエーションを1つ持っています。そのため、商品を作ると、バリエーションも一緒に作られます。Flow からは、これが「バリエーションが追加された」＝「価格の項目が変わった」と見えるわけです。実行履歴にも、追加されたものとしてバリエーションが記録されていました（実行履歴の読み方は後述）。

一方、タイトル・ステータス・販売元は商品そのものの項目です。商品を作るときにこれらを入れても、「変更」としては扱われず、それらを見張るワークフローは動きませんでした。ヘルプの説明とも一致します。

例えば「価格が3,000円以下なら『お手頃』タグを付ける」ワークフローは、価格を後から変えたときだけでなく、新しく商品を登録したときにも動きます。新商品にも同じタグを付けたいなら好都合です。一方、登録時には動いてほしくない場合は、それを見分ける条件を入れる必要があります。

② メタフィールドは「定義」で見張るか「名前空間」で見張るかで、反応する範囲が変わる

メタフィールドの名前は、custom.release_date のように「名前空間.キー」の2段になっています。名前空間をフォルダ、キーをその中のファイル名に置き換えると分かりやすいです。custom.release_date なら、「custom というフォルダの中の release_date」です。

前述のとおり、Product updated トリガーでメタフィールドを見張るときは、「定義を1つ選ぶ」か「名前空間だけを指定する」かを選べます。この違いを確かめるため、次のように準備しました。

• メタフィールドの定義を3つ作る：flowtest.memo、flowtest.memo2、flowother.memo（最初の2つは同じ名前空間 flowtest、3つ目だけ別の名前空間 flowother）
• ワークフロー①：定義 flowtest.memo だけを見張る
• ワークフロー②：名前空間 flowtest を見張る

結果は図のとおりです。

• flowtest.memo に値を入れると、①と②の両方が動いた（どちらの範囲にも入る）
• flowtest.memo2 に値を入れると、②だけが動いた（同じ名前空間なので②の範囲には入るが、①が見張る定義とは別）
• flowother.memo に値を入れても、どちらも動かなかった（別の名前空間なので、どちらの範囲にも入らない）

つまり、定義で見張ると「その1つだけ」、名前空間で見張ると「そのフォルダの中すべて」が対象になります。名前空間で見張れば、関連する複数のメタフィールドを、5つの枠のうち1つで見張れて便利です。ただし、同じ名前空間に入っている無関係のメタフィールドが変わったときにも動きます。custom の名前空間に多くのメタフィールドを入れているストアでは、思ったより頻繁に動く可能性があります。

なお、どれも「値が空だった定義に、初めて値を入れる」操作でした。初めて値を入れた場合も、変更として扱われ、ワークフローが動きました。

③ タグと価格を両方見張ると、タグだけ変えたときにバリエーションの情報が空になる

価格のようなバリエーションの項目を見張るワークフローでは、productVariant という変数が使えます。変数は、条件やアクションに商品の情報を差し込むための入れ物です。productVariant には「どのバリエーションが変わったか」の情報が入り、例えば {{productVariant.price}} と書くと、変更後の価格を差し込めます。

「タグ＋価格」のワークフローは、タグと価格の両方を見張っています。見張る項目のどれかが変われば動くので、タグだけを変えたときも動きました。ここまでは想定どおりです。

問題は、このときの productVariant です。タグだけを変えた場合、バリエーションは何も変わっていません。そのため、productVariant は空になっていました。実行履歴のログでも、価格を変えたときは variantPrice=[1200.0] と価格が入っていたのに対し、タグだけを変えたときは variantPrice=[] と空でした（次の章の図の右側）。

例えば「productVariant.price が3,000円以下なら、タグを付ける」という条件をこのワークフローに置くと、タグだけが変わった実行では、空の価格で判定することになります。結果が意図とずれる恐れがあります。

対策は2つあります。

• 見張る項目を混ぜない：タグ用と価格用で、ワークフローを分ける
• 混ぜる場合は、使う前に値があるかを確かめる：productVariant を使う条件やアクションの前に、値が空でないかを確かめる条件を置く（条件の演算子には「空または存在しない」がある）。ヘルプでも、この確認を勧めています

実行履歴で、何が変わったかを確認できる

ヘルプには載っていませんが、実際に役立ったのが実行履歴です。Flow の「最近の実行」から実行を開き、トリガーの「ステップのデータ」を開くと、入力の fields_changed に、何が変わったかが残っていました。

• added：新しく加わったもの（商品の作成で増えたバリエーション、初めて値を入れたメタフィールドなど）
• updated：値が変わったもの（例：.variants[…].price、.tags）
• removed：消えたもの

出てくるのは、見張っている項目だけです。複数の項目を見張っているワークフローが、どの変更で動いたのかを後から確かめたいときに使えます。ただし、ここにも変更前の値は出てきません。値上げなのか値下げなのかは、このトリガーだけでは区別できません。

どの経路で変えても動くか

商品の変更は、管理画面の商品編集以外にも、いろいろな経路で起こります。価格を見張るワークフローで、経路ごとに試しました。

アプリや外部システムが API で価格を変えた場合も、CSV で一括更新した場合も、値が変われば動きました。反対に、同じ値を書き込んだだけでは動きません。API で同じ価格を書き込むと処理は成功しますが、ワークフローは動かず、商品の最終更新日時も変わりませんでした。毎日 CSV で全商品を上書きしている運用でも、値が変わった商品にだけ反応すると考えてよさそうです。

Sidekick は、商品編集画面のフォームの値を書き換えるところまでを行います。「反映するには、画面の保存を押してください」と表示され、保存した時点でワークフローが動きました。

Flow 自身の変更でも、ほかのワークフローが動く

販売元を見張るワークフローには、タグを付けるアクションを入れていました。販売元を変えると、このワークフローが動いてタグを付けます。すると、そのタグの追加をきっかけに、「タグ」と「タグ＋価格」のワークフローも動きました。Flow のアクションによる変更も、ほかのワークフローから見れば、ふつうの商品の更新として扱われます。

さらに、タグを見張りながら、自分でもタグを付けるワークフローを作って試しました。管理画面でタグを1つ追加すると、1回目の実行でタグ「self-loop-test」を付けます。そのタグの追加で、2回目が動きました。2回目も同じタグを付けようとしますが、すでに付いているのでタグは変わりません。3回目は起きませんでした。

付ける値が同じなら、このように自然に止まります。しかし、日時や連番など、毎回違う値を書き込むアクションを、同じ項目を見張るワークフローに入れると、止まらなくなる恐れがあります。

メタフィールドを更新するアクションでも、同じように連鎖する

タグだけでなく、「Update product metafield」（商品のメタフィールドを更新する）アクションでも試しました。販売元が変わったらメタフィールド flowtest.memo を書き換えるワークフローを作り、API で販売元を変えると、このワークフローが flowtest.memo を書き換えました。その書き換えをきっかけに、flowtest.memo と名前空間 flowtest を見張る2本のワークフローも動きました。

名前空間 flowtest を見張りながら、同じ名前空間の flowtest.memo2 に固定の値を書き込むワークフローも、タグのときと同じく2回動いて止まりました。2回目も、同じ値を書き込む処理自体は実行されていました。

止まらなくなるのを防ぐ：「すでにその値なら何もしない」条件を置く

連鎖が止まらなくなるのを防ぐには、書き込む前に「すでに目的の値になっていれば何もしない」という条件を置きます。上のワークフローに、次の条件を足して試しました。

1. Log output のあとに「条件」を追加し、「変数を追加」→ product → metafield の「＋」から、flowtest.memo2 を選んで変数を作る（名前を付けると、条件の中で memo2.value として使える）
2. 条件を「memo2.value が fixed-2 と等しい」にする
3. False 側にだけ「Update product metafield」（memo2 に fixed-2 を書き込む）を置き、True 側には何も置かない

結果、1回目は条件が False になって fixed-2 を書き込み、自分の書き込みで2回目が動きました。2回目は条件が True になり、書き込みをせずに終わりました。実行の詳細でも、2回目は「Update product metafield」が実行されていないことを確認できます。

値が毎回変わる処理（例：最終更新日時を書き込む）では、「同じ値なら止まる」に頼れません。こうした場合も、「この実行で処理する必要があるか」を条件で判定してから書き込むようにしておくと、ワークフロー同士の連鎖を自分の側で断ち切れます。

使い方の例

今回の検証結果をふまえると、次のような自動化をアプリなしで組めます（設計例です。この記事では、ここまでの検証以外は実機で試していません）。

• メタフィールドの値でコレクションを入れ替える：custom の名前空間を見張り、値に応じて「Add product to collections」「Remove product from collections」を実行する
• 説明文や画像を差し替えた商品に「要確認」タグを付ける：descriptionHtml と media を見張り、タグを付ける。見張る項目にタグを含めなければ、自分自身を呼び出すことはありません
• 商品を公開したら、新着コレクションに入れる：status を見張り、ステータスが「アクティブ」のときにコレクションに追加する
• メタフィールドの変更を外部サービスに送る：メタフィールドを見張り、「Send HTTP request」で外部の API に知らせる

気をつけたい点

• 変更前の値は使えない：実行履歴にも出てこない。値上げか値下げかを区別したい場合は、前の値をメタフィールドなどに残しておく工夫が必要
• 価格などバリエーションの項目を見張ると、商品の作成でも動く
• 種類の違う項目を組み合わせると、データが空になることがある：使う前に、値があるかを条件で確かめる
• 見張れるのは5つまで：名前空間の指定を使うと、複数のメタフィールドを1枠で見張れる
• 連鎖とループを前提に組む：Flow のアクション（タグの追加、メタフィールドの更新）による変更でも、ほかのワークフローや自分自身が動く。書き込む前に「すでに目的の値なら何もしない」条件を置く
• 対象は商品とバリエーション：顧客や注文のメタフィールドの変化をきっかけにする用途は、このトリガーでは扱えない

まとめ

「商品のこの項目が変わったら、こうする」という自動化は、これまでアプリを入れるか、定期的に確認する仕組みを作るしかありませんでした。Product updated トリガーで見張る項目を選べるようになり、価格・タグ・ステータス・メタフィールドの変化を、Flow だけで扱えるようになりました。管理画面・一括編集・CSV・API・Sidekick と、どの経路の変更でも動き、値が変わらない書き込みには反応しない点も、運用上は扱いやすいと感じました。

一方で、商品の作成でも動く場合があること、ワークフロー同士が連鎖することは、組む前に知っておきたい挙動です。商品を書き換えるアクションを置くときは、止める条件をセットで入れておくと安心です。テストのときは、実行履歴の「ステップのデータ」で、どの変更で動いたのかを確かめながら進めるのがおすすめです。

参考

• Shopify ヘルプセンター「商品の更新」
• Shopify ヘルプセンター「Shopify Flowのトリガー」
• Shopify Editions Fall '26