変更履歴

このアプリは、あなたの言語で話しかけてくれます

アプリ全体が、Shopifyの管理画面で設定された言語に合わせて表示されるようになりました。**英語、ドイツ語、フランス語、スペイン語、イタリア語、オランダ語、デンマーク語、ポルトガル語（ブラジルおよびポルトガル）、日本語、中国語（簡体字および繁体字）**に対応しています。管理画面の言語を変更すると、次のページ読み込み時にアプリもそれに合わせて変更されます。

• すべてのページ、ダイアログ、メッセージが翻訳されています。これには、権限カード、トリガー設定、およびカスタムトリガーエディタも含まれます。
• 商品ページ、注文ページ、お客様ページにあるイベントブロックも、お客様の言語で表示されます。
• Shopify Flow では、ワークフローテンプレートのタイトル、説明、および設定に関する注意事項が、お客様の言語で表示されます。
• トリガー名は英語のままです。「Shopify Flow」ではトリガー名が英語で表示されるため、アプリでも同様に表示されます。アプリに表示される名前は、常に「」に記載されているものと同じです。

監視：トリガーが機能しなくなったタイミングを把握する

何の前触れもなく動作を停止してしまうトリガーは、最も気づきにくい問題です。新しい「**モニタリング」**ページでは、任意のトリガーを監視対象に設定し、異常が発生した際にメールを受け取ることができます：

• イベントなし - 指定した時間帯には何も実行されません。たとえば、繁忙なストアでの「注文更新」など、毎日実行されるべきトリガーに最適です。
• ワークフローの確認が行われませんでした。トリガーは発動しましたが、ワークフローから応答が返されませんでした。**「ワークフローの実行を確認」**アクションをワークフローの最後のステップとして追加し、イベント ID を「eventId」に設定してください。
• 失敗 - 権限の不足など、修正可能な理由により処理が失敗したケースを指します。一時的な「Shopify」エラーはこれに含まれません。

問題が発生した際には1通のメールが届きます。チェックごとに1通ずつ送信されるわけではなく、モニターのページ上で現在の状態を確認できます。モニター機能は、すべてのプランでご利用いただけます。

このリリースには、他にも以下の内容が含まれています

• 「フローのステータスを送信」は、「ワークフローの実行を確認」という名称に変更され、フィールドの説明もより分かりやすくなりました。すでにこの機能を使用しているワークフローについては、変更なく引き続き動作します。
• 障害通知メールには、原因と影響を受けたトリガーが明記され、その対処法についても一文が記載されています。
• 「Product Update」、「Order Update」、「Customer Update」の旧値と新値は、スイッチ形式になりました。「トリガー」ページでトリガーの設定を開き、「ワークフローが changes を読み取った場合に**旧値と新値を送信する」**をオンにしてください。オフの場合、changes は空の状態で送信されます。いずれの場合でも、カスタムトリガーコードには引き続き旧値と新値が送信されます。

何かが変化したことを把握するだけでは、たいていの場合不十分です。ワークフローでは通常、変化前の状態を知る必要があります。価格が下がったのか上がったのか、その変動幅はどれくらいか、どのタグが追加されたのか、昨日のメタフィールドの値はどうだったのか、といった情報です。今回のリリースでは、アプリ全体で新旧の値を利用できるようになり、何も変化がなかった場合でも、カスタムトリガーによってワークフローを開始できるようになりました。

至る所に、古い価値観と新しい価値観が

• **メタフィールドのトリガーには、以前の値が渡されるようになりました。**すべてのメタフィールドのトリガー（汎用、商品、バリエーション、注文、顧客）は、Metafield.value のほかに、Metafield.previousValue を Flow に渡します。メタフィールドが作成されたばかりの場合は、この値は空になります。および を参照してください。
• **価格、単価、および原価の変更は数値として反映されます。**Shopify Flowでは算術演算が行えないため、「Variant Price Changed」、「Variant Unit Price Changed」、「Product Variant Cost Changed」では、新たに「delta」（新値から旧値を引いた値）、「percentChange」、および「direction」（増加、減少、変化なし）が返されるようになりました。 「価格が10%以上下落した」は、コードを必要としない単一の条件となりました。
• **「Product Update」、「Order Update」、「Customer Update」では、どのような変更があったかがわかります。**以前は、レコードが更新されたことのみが表示されていましたが、現在は「changes」が含まれるようになりました。これは、変更されたフィールドの一覧と、各フィールドの旧値および新値です。 追跡対象となるフィールドは、製品の場合は「タイトル」、「説明」、「ステータス」、「タグ」、「ベンダー」、「タイプ」、「ハンドル」です。注文の場合は「支払いステータス」、「フルフィルメントステータス」、「ラインアイテム」、「タグ」、「メモ」、「追加詳細」です。お客様の場合は「タグ」、「メモ」、「アカウントの状態」です。長い値は短縮されて表示されます。在庫の変更など、これらのフィールド以外が更新された場合は、リストは空になります。
• **「下書き注文のラインアイテムの変更」**では、注文トリガーと同様に、行ごとの変更点（追加、削除、数量・価格・バリエーションの変更など）が表示されるようになりました。
• 独自のカスタムトリガーコードでも、旧値と新値の両方を確認できます。 「」のカスタムトリガー（）は、「Product Update」「Order Update」「Customer Update」のいずれかが発生した際に、payload._changesを受け取ります。これは、変更されたすべての追跡対象フィールドであり、各フィールドにはoldValueとnewValueが設定されています。これにより、コードは「ステータスが下書きからアクティブに変わった」「注文が支払済みになった」といった状態の遷移に基づいて実行されるため、現在の値に基づく条件では表現できないような変化にも対応できます。 エディタでキャプチャできるサンプルイベントには、そのフィールドが表示されています。

すべては追加形式です。すでに構築済みのワークフローは、変更されることなく引き続き動作します。各トリガーごとの完全なフィールド一覧については、「」のトリガーリファレンス（）をご覧ください。

どの変更が「更新」トリガーを発動させるかを選択してください

「Product Update」、「Order Update」、「Customer Update」には、の「Triggers」ページ（）にある各スイッチの横にある歯車アイコンの背後に、新しい設定が追加されました。これにより、トリガーの発動条件が変更されます。

• **チェックされている項目はありません：**トリガーは、これまでとまったく同じように、更新のたびに発動します。
• **チェックされたフィールド：**それらのいずれかが変更された場合にのみ実行されます。それ以外の更新はスキップされ、ご利用プランのカウント対象にはなりません。

これは、ワークフローが自分自身をトリガーしてしまうのを防ぐための適切な方法でもあります。「Product Update」で開始され、その後、再び自分自身を起動するために使用される製品のメタフィールドを書き込むワークフローがあります。トリガー対象を必要なフィールドに絞り込めば、その2回目の更新は実行されなくなります。

その他のトリガーについては、この選択による影響はありません。「注文の更新」の対象を支払いステータスに限定しても、「注文タグの追加」がトリガーされるタイミングは変わりません。

スケジュールに従って実行されるカスタムトリガー

Shopify Flow 何かが起こったときに反応します。何も起こらないときには反応できず、ストアの外にあるものは認識できません。のカスタムトリガー「」なら、それが可能です。エディタでは、「このトリガーを実行する条件：Shopifyのイベント****が発生したとき、またはスケジュールに従って」と尋ねられます。 「スケジュールに従って」を選択すると、コードは30秒ごとに、1日1回を上限として実行されます。前回の実行時に検知した内容を記憶しており、ストアの状態を読み取り、パブリックインターネット上の任意のサービスを呼び出すことができ、何が変更に該当するかを独自に判断します。

テンプレートを基に、上部の数値を編集してください：

• N日間更新されていない商品、注文、またはお客様 ― 古くなったカタログのレビュー、滞留している注文、お客様の呼び戻し。各レコードは、活動がない期間ごとに1回ずつトリガーされます。機能を有効にした時点で既に期限切れとなっているものについては、一度にまとめてトリガーされることはありません。
• Shopify 以外の値が変更されました。具体的には、サプライヤーの在庫データ、為替レート、価格表などです。変更前後の値、および数値の場合はその差額とパーセンテージが表示されます。
• RSS または Atom フィードの新規アイテム ― サプライヤーのニュース、商品リストフィード、ステータスページなど。
• N時間注文がない場合 ― ストアの「心拍」のようなものです。注文が途絶えたときと、注文が再開したときにそれぞれ1回ずつ発火します。

スケジュールされたトリガーの初回実行では、その時点で確認された内容のみが記録されるため、トリガーを有効にしてもワークフローが過剰に処理されることはありません。Shopify Flow には、ハンドル名でフィルタリングされた**「カスタムトリガー**」として表示され、レコードはその ID として表示されます。トリガーが作動したかどうかに関わらず、すべての実行回数はプランの消化対象となります。エディタには、各間隔ごとに合計される実行回数が表示されます。 「**テスト」では、**何もトリガーすることなくコードを1回実行します。

イベントベースのカスタムトリガー用テンプレート

Shopifyイベントを監視するカスタムトリガーにも、テンプレートが追加されました。「テンプレートから開始」からテンプレートを選択すると、イベントが選択され、コードが自動的に入力されます。各テンプレートは、変更前後の値を読み取ります：

• 製品、注文、またはお客様のフィールドの値が変更されました。たとえば、ステータスが「下書き」から「有効」に変わった場合や、注文が「支払い済み」になった場合などです。
• 価格がN％以上値下がりしました。これは単なる価格の修正ではなく、本格的な値下げです。
• 在庫が閾値を下回りました。在庫がそのラインを越えた瞬間に1回だけ発火します。在庫がすでに少ない状態でも、販売のたびに発火するわけではありません。
• 商品のメタフィールドの数値が閾値を超えました。具体的には、評価が3を下回り、マージンが40を上回りました。
• 「高額お客様による注文」――ctx.shopify() を使用して、当店のお客様の累計購入額を読み取り、設定した金額を超えた場合にのみトリガーされます。

レコードのトリガーイベント（そのレコード専用の管理ページ上）

新しい管理ブロックでは、Shopifyの管理画面において、現在表示中のレコードに関する最新のトリガーイベントが、そのレコードのページ上に直接表示されます。各イベントには、「price: 100.00 -> 85.00」といった「旧→新」の短い説明文が付いています。そこから、そのイベント自体、またはそのレコードの「イベント履歴」を開くことができます。

商品、バリエーション、注文、下書き注文、お客様、コレクション、会社、および会社のロケーションでご利用いただけます。ページの「カスタマイズ」メニューから、このブロックを一度追加してください。 個人データを扱うトリガーは、その値が省略された状態で一覧表示されています。製品、注文、顧客ページを例に、追加方法をご説明します：レコードの管理ページでのトリガーイベント。

「Generate with AI」に対応するAIプロバイダーがさらに増えました

AI では、Anthropic や OpenAI に加え、Google Gemini および OpenRouter にも対応するようになりました。OpenRouter を利用すれば、1 つのキーで多くの会社のモデルを利用でき、入力した任意のモデル ID にも対応しています。 **「Developer」→「Connections」**でキーを接続してください：。Gemini APIキーの取得はこちら：、または。OpenRouter APIキーの取得はこちら：。従来と同様に、生成処理はご自身のプロバイダーアカウント上で実行され、キーは暗号化されるため、二度と表示されることはありません。

ShopifyのWebコンポーネントを基盤とした、より高速なインターフェース

このアプリのすべてのページは、Shopifyの新しい管理用Webコンポーネントに基づいて再構築されています。これは、Shopifyの管理画面自体が使用しているのと同じ構成要素です。

• **読み込みが速くなりました。**このアプリでは、インターフェースライブラリの独自コピーを同梱しなくなりました。コンポーネントは Shopify から取得され、管理画面の他の部分と共有されており、通常はすでにブラウザのキャッシュに保存されているため、各ページが表示されるまでにダウンロードする必要があるデータ量が大幅に少なくなっています。
• **まるで管理画面のようです。**ボタン、表、スイッチ、ダイアログ、フォームは、キーボードによるナビゲーションやスクリーンリーダーの対応を含め、Shopifyの他のどこでも使用しているものと同じ見た目と動作をしています。
• **常に最新の状態を維持します。**Shopifyがコンポーネントを改善した場合、当アプリは当社による更新を行わなくても、その改善を自動的に反映します。

何も変わっていません。すべてのページ、設定、リンクは以前と同じ場所にあります。

このリリースには他にも以下の内容が含まれています

• 「権限」ページにある「すべて許可」と「すべて取り消し」の機能をご利用ください。「すべて許可」を選択すると、カードごとに個別に表示されるのではなく、1つのShopifyダイアログで、不足しているすべての権限を一括して許可するよう求められます。「すべて取り消し」を選択すると、まず確認を求められ、その意味についても説明が表示されます。つまり、トリガーは有効なままですが、再度アクセス権を許可するまではトリガーが作動しなくなります。
• カスタムトリガーコードでは、ctx.fetch() による自社ストアへのアクセスだけでなく、ctx.shopify() による外部インターネットへのアクセスも可能です。内部アドレスからのアクセスは拒否されます。
• **カスタムトリガーとストアフロントのトリガーは、これと同じ動作をするようになりました。**編集したい行をクリックすると、右側にステータスが表示されます。
• 「トリガー」ページでは、タイトルの横に有効になっているトリガーの数が表示され、4つのタイプ別メタフィールドトリガーには、リスト内にそれぞれ専用の切り替えスイッチが追加されました。
• 必須項目は、カスタムトリガー、ストアフロントトリガー、および接続フォーム上で明示されています。
• **修正：イベント履歴の日付フィルターが解除できない不具合がありました。**日付チップを削除したり、「すべてクリア」を選択したりしても、適用された日付が残っていました。現在は、どちらの方法でも日付がクリアされるようになりました。
• イベント履歴の行は、青いリンクではなくプレーンテキストで表示されます。行全体は引き続きクリック可能です。

これまでのところ、このアプリのトリガーはすべて、管理画面で発生した事象（注文の支払い完了や商品の更新など）をきっかけとして発動していました。今回のリリースでは、お客様がストアフロントで行った操作をきっかけとして発動するトリガーが追加されました。

Shopify 閲覧行動に関するWebhookは送信されませんので、これらはアプリが自動的にインストールするのウェブピクセルによって収集されます。 - テーマの編集も、コードの貼り付けも不要です。

ストアフロントのトリガー

設定、権限、および各トリガーが送信する内容については、をご覧ください。ストアフロントのトリガーについては、 をご覧ください。

• ストアフロントで閲覧された商品およびストアフロントで閲覧されたコレクション
• ストアフロントの商品をカートに追加・削除しました
• ストアフロントのカートが表示されました
• ストアフロントでのチェックアウトが開始されました
• 「ストアフロント Search」と「ストアフロント Search Returned No Results」――後者は、買い物客が貴社で販売しているものと期待していた商品のリアルタイムリストです。1回の検索で、この2つのうち正確に1つだけが実行されるため、重複カウントすることなく両方を有効にすることができます。2つのトリガーの割り当て方法については、 をご覧ください。
• 「在庫切れのバリエーションが閲覧されました」――実際の購入希望者が、販売できない商品を閲覧しました。これは、商品単位ではなくバリエーション単位での再入荷要請のシグナルとなります。「在庫切れ」の定義については、 をご参照ください。
• 「ログイン済み顧客による訪問」および「B2Bバイヤーによる訪問」――リピーターのお客様が貴店のサイトにアクセスしています。繰り返し行われるページビューは、お客様ごとまたは会社ごとに、ご指定いただいた訪問期間に集計されます。訪問期間の説明はこちら。

チェックアウトのトリガー

詳細：チェックアウトが行われると、 がトリガーされます。

• チェックアウトエラーが表示されました ― サポートチケットを待つことなく、チェックアウトが失敗している原因を特定しましょう。
• チェックアウト時のディスカウントコードが拒否されました ― お客様がコードを入力しましたが、チェックアウト時にそのコードが受け入れられませんでした。通常、キャンペーンの有効期限が切れているか、メールで受け取ったコードが有効化されていない場合です。
• 初回注文 - これまで注文したことがないお客様からの注文で、お客様と注文がネイティブのFlow参照として扱われます。これはShopifyの注文Webhookから送信されるため、上記の2つとは異なり、管理トリガーと同様に信頼性が高いものです。トリガーリファレンス に掲載されています。

カスタムストアフロントのトリガー

Shopifyがまったく報告しない事項については、テーマから1行のJavaScriptで独自のイベントを送信すれば、それがShopify Flowのトリガーとなります。手順を順を追って説明します。コピー用のスニペットはこちらです：カスタムストアフロントトリガー。

最もわかりやすい例は、カートドロワーです。Shopifyのカート表示イベントは、/cartページでのみ発生しますが、最近のテーマの多くは、代わりにドロワーをスライドさせて開き、そのページへ遷移することはありません。ドロワーが開いた際に独自のイベントを発火させることで、このギャップを埋めることができます。ウィッシュリストへの追加、サイズガイドの表示、バリエーションの切り替えも、同様の仕組みで機能します。

登録済みのイベント名のみが転送されるため、ページ上の他のスクリプトがあなたの割り当て分を使い切ることはありません。イベントに「」という名前を付け、「」として、「Shopify Flow」内でこれを使用します。。

これらをオンにする前に

• これらのユーザーには、新しい「ストアフロント Behaviour」権限が必要です。この権限は、他の権限と同様に「Permissions」ページから付与されます。この権限の対象範囲については、 をご参照ください。
• **お客様の同意は尊重されます。**お客様が分析に関する同意を与えていない場合、そのイベントはお客様のブラウザ内で破棄され、当社には一切送信されません。これにより、お客様に費用は一切発生せず、ワークフローも開始されません。同意の取り扱いについては、 をご覧ください。
• **これらは、管理用トリガーよりもはるかに処理量が多くなります。**繁盛しているストアでは、1日あたりの商品閲覧数が1年間の注文更新数よりも多くなりますが、どのイベントもプランの利用量にカウントされます。ワークフローで使用する機能のみを有効にしてください。プランと利用状況。
• **これらはベストエフォート方式であり、保証されるものではありません。**タブを閉じたり、接続が切断されたり、広告ブロッカーが動作したりすると、イベントは届かなくなります。これらをシグナルやリアクションとしてご利用ください。イベントの受信漏れが正確性の問題につながるような用途には使用しないでください。

「在庫切れのバリエーションの表示」が、どのような条件を「在庫切れ」とみなすかを含め、詳細については、『』のストアフロント・トリガーに関するガイド（）をご覧ください。

AIを使ってトリガーコードを生成する

カスタムトリガーの動作内容を平易な言葉で説明すれば、AIがコードを生成してくれます。**「Developer」→「Connections」**で、ご自身のAnthropicまたはOpenAIのAPIキーを追加してください。コード生成はお客様のアカウント上で実行され、APIキーは暗号化されるため、二度と表示されることはなく、トリガーコード内で実行されることもありません。詳細なガイドはこちら：AIでトリガーコードを生成する。 まずキーが必要ですか？ Anthropic（Claude）APIキーを取得するには または 、OpenAI APIキーを取得するには をご覧ください。

• **トリガーが実際に受け取る内容に基づいています。**ジェネレーターには、このアプリの実行時契約、Shopify管理API、そして（一度キャプチャできれば）実際のイベントペイロードが渡されます。そのため、名前を推測するのではなく、フィールドを直接確認できるため、payload.total_priceと記述します。ジェネレーターが把握している情報。
• **既存のものを基に構築されます。**すでにコードがある場合は、一から作り直すのではなく、そのコードを編集するため、「さらにXも実行する」といった処理が可能になります。
• **自動的に保存されることはありません。**生成されたコードは、保存されていない変更としてエディタに表示されます。キャプチャしたペイロードに対してテストを行い、どのようなトリガーが発動するかを確認してから、保存してください。カスタムトリガーを生成する.
• 「カスタムストアフロントトリガー」用のテーマスニペットを作成します。テーマごとに要素の名称が異なるため、多くの人がここでつまずいてしまう部分です。ストアフロントスニペットを生成する.

また、以下の点も修正されました

• 「メタフィールド・トリガー」の「トリガーの追加」リストは、権限を付与した後、最大1時間ほど空のままになることがありました。これは、実際には定義が存在しているにもかかわらず、「定義が存在しない」と表示されていたためです。この空の状態がキャッシュされていたためですが、現在はキャッシュされなくなりましたので、次回リストを開いた際には内容が反映されるようになります。メタオブジェクトのリストについても同様の現象が見られました。 詳細は、（メタフィールド・トリガー） および （メタオブジェクト・トリガー） をご参照ください。
• 「チャネルへの公開」および「チャネルからの公開解除」処理において、新しく作成された商品の最初の変更が反映されませんでした。 このアプリは、レコードを初めて検出した際にベースラインを保存し、それとの差異がある場合にのみトリガーを発動しますが、パブリケーションについては、作成時にベースラインが書き込まれていませんでした。そのため、商品作成後の最初のパブリッシュは黙ってスルーされ、2回目のパブリッシュでのみトリガーが発動していました。現在は、最初の変更から両方が正常に動作するようになりました。参照用ドキュメント「」における商品トリガーについて。

サポートチケットを通じて報告された2つの修正です。報告してくださったマーチャントの皆様に感謝いたします。

• **イベント履歴は、イベント数が非常に多いストアでも瞬時に読み込まれるようになりました。**30日間の履歴に数百万件ものイベントが保存されているストアでは、ページの読み込みに非常に長い時間がかかるか、まったく読み込まれないことがありました。現在は、イベント数に関係なく1秒をはるかに下回る時間で表示され、すべてのフィルターも以前と同様に機能します。
• スナップショットベースのトリガーにおけるベースライン同期が、自動的に開始されるようになりました。 保存されたベースライン（タグ、ステータス、タイトルなど）との変更を比較するトリガーは、ワークフローで使用される前にトリガーが有効化された場合、「同期されたレコード数：0」という状態で無期限に待機してしまうことがありました。現在、このようなトリガーを有効にすると、自動的に初期同期が開始されるため、最初の実際の変更が発生した時点でトリガーが作動します。

このアプリがリリースされて以来、最大規模のアップデートとなり、トリガーの設定方法が変更されました。

カスタムトリガー

組み込みのトリガーが適合しない場合は、独自のトリガーを作成してください。Shopifyのイベントを選択し、ストアから実際のペイロードを取得して、いつトリガーを発動させるか、何を送信するかを決定する簡単な変換を作成してください。

• ご自身の条件に合致する場合にのみ実行してください。「あらゆる製品の更新」ではなく、一定額以上の注文のみ、特定のベンダーの製品のみ、あるいは実際に重要だと考える変更のみを対象としてください。
• Shopify Flowには、ワークフローの要件に合わせて、必要なフィールドのみを適切な形式で送信してください。
• イベントに含まれていないデータを取得します。ctx.shopify()は、トリガー内部からAdmin GraphQLクエリを実行するため、ストア内のあらゆるデータを用いてイベントを充実させることができます。
• 出荷前に、実際にキャプチャしたペイロードを用いてテストを行い、出力とログを並べて確認してください。

ご指定のコードは、Shopify Flow に「**カスタムトリガー」**として、そのハンドル名でフィルタリングされた状態で表示されます。そのため、1つのワークフローが、ご指定のトリガーのうちまさに1つにのみ反応することになります。

「設定」は「トリガー」ページになりました

9つの「設定」タブはなくなりました。すべてのトリガーは、検索機能とともに1つのページにまとめられ、それぞれに独自のオン／オフスイッチが設けられています。

以前のページには、動作方向が逆の2種類のスイッチがありました。ほとんどのトリガーは、オンにするまではオフの状態でしたが、... Updateの広範囲なトリガーはデフォルトでオンになっており、オフにするための「サプレッサー」という別のタブが用意されていました。現在では、どこでも1つのルールが適用されています。つまり、スイッチがオンの間、トリガーは発動します。

• トリガーがどのタブに分類されているかを推測するのではなく、名前で検索してください。
• **83個のトリガーはすべて切り替え可能です。**以前は、トリガー用の行を作成した場合にのみ、そのトリガーに切り替え機能が用意されていました。
• 一括で有効化または無効化でき、検索結果にのみ適用することも、すべてに適用することも可能です。
• **権限は、操作を行ったその場で付与されます。**権限が必要なトリガーを有効にすると、その場で権限の許可を求められます。2つの権限が必要な場合は、両方をまとめて表示するダイアログが1つ表示されます。

設定内容に変更はなく、以前の「設定」リンクも引き続きご利用いただけます。以前無効にしていたトリガーは、現在は単に「オフ」と表示されるようになっています。

トリガーをシミュレートする

以前は、ワークフローをテストするには、実際にストアで操作を行う必要がありました。つまり、商品の編集、注文の確定、投票の結果待ちなどです。しかし今では、必要に応じてトリガーを実行できるようになりました。「イベント履歴」で任意のイベントを開き、「シミュレート」を再度選択するだけで済みます。

シミュレーションは、実際のShopify Webhookと同じパイプラインを通るため、ワークフローには本番環境とまったく同じデータが送信されます。ドライラン機能を使用すれば、実際に処理を実行することなく、ペイロードをプレビューすることができます。シミュレートされたイベントはテストとして記録されるため、統計には反映されず、プランの使用量にもカウントされません。

なお、シミュレートされたトリガーはワークフローを実際に実行します。つまり、ワークフローによって注文にタグが付けられたり、メールが送信されたりした場合、それらは実際に実行されます。

開発者向けAPIとMCP

• APIキーを作成するための開発者向けページです。Claude、Cursor、VS Codeなどに対応した接続コマンドが掲載されています。
• ストアのすべてのトリガーとそのステータスを一覧表示したり、イベント履歴や統計情報を確認したり、付与済みの権限を確認したりできるREST APIです。
• MCPサーバーです。これにより、AIアシスタントがお客様の設定を確認し、会話の中でトリガーをシミュレートすることができます。
• 3つのアクセスレベルがあり、各レベルではシミュレーションやカスタムトリガーの実行が可能であるため、通常の読み取りキーではオートメーションを起動することはできません。

トリガーコードはGitHubに保管しておいてください

GitHubリポジトリを連携すると、カスタムトリガーが自動的にそのリポジトリにプッシュされます。お使いのエディタでファイルを編集すると、その変更がアプリに反映されます。すべてのバージョンがコミットとして記録されるため、変更内容は確認・元に戻すことが可能で、アプリから任意の以前のバージョンにロールバックすることもできます。

このリリースには他にも以下の内容が含まれています

• データの同期状況は、単にレコード数のみが表示されるのではなく、**「同期済み」**と表示されるようになりました。また、ストアのタイムゾーンに基づいた直近の完全同期の日付も表示されます。初期データの一括読み込みは1回のみ行われ、その後はスナップショットが自動的に最新の状態に保たれます。
• 「製品」または「注文」へのアクセス権を付与すると、そのリソースの広範な「更新」トリガーが有効になり、イベントがすぐに流れ始めます。
• 実際の操作手順に沿った、よりわかりやすいセットアップガイドです。トリガーの選択、アクセス許可の設定、ワークフローの作成、そしてその実行状況の確認という流れに沿って進めます。

**「商品、バリエーション、コレクション」へのアクセス権は、もはや自動的に付与されなくなりました。**以前は必須の権限であり、インストール時に自動的に含まれ、削除することもできませんでした。現在は他の権限と同様にオプションとなっています。「権限」ページから付与し、いつでも取り消すことができます。この権限を付与すると、ストアの「商品」および「コレクション」のトリガーが即座に登録されます。

すでに導入済みのストアはそのまま維持してください。特に何もする必要はありません。

はるかに高速なダッシュボード

ダッシュボードは、数値を算出するためにイベント履歴全体を読み込むことはなくなりました。 日別、トピック別、ステータス別の集計値は、事前に集計されたサマリーから取得されるようになり、ご利用状況の数値は、実際にプランの制限を適用しているカウンターから直接読み取られるようになりました。そのため、リアルタイムで表示され、常に正確な数値が反映されます。数百万件ものイベントがあるストアでは、これがダッシュボードがタイムアウトしてしまうか、瞬時に読み込まれるかの違いとなります。

新しいヘルプセンター

詳細なドキュメントは、、docs.workflow-trigger-extensions.app、 でご覧いただけます。各トリガーのリファレンス、設定や権限に関するガイド、トラブルシューティング、動画付きのステップバイステップのワークフローガイドなどが掲載されています。バグの報告、機能のリクエスト、またはスクリーンショットを添付して直接弊社へご連絡いただく場合は、専用フォームをご利用ください。

アプリ内のチャットバブルは、すべてのページに表示されるようになりました。また、ダイアログが開いている間は、画面から非表示になります。

このリリースには他にも以下の内容が含まれています

• ShopifyのSidekickに、トリガーについてお尋ねください。設定されているトリガー、あるトリガーが作動しない理由、最近作動したトリガー、使用済み上限の残量などについて確認できます。読み取り専用であり、設定を変更することはできません。
• **修正済み：「Customer Note Changed」および「Customer State Changed」がトリガーされませんでした。**変更内容が、アプリが実際には読み取っていない値と比較されていたためです。現在はどちらも正常に動作しています。
• **修正点：「注文の配送先住所の変更」操作が、「**お客様データへのアクセス」権限も付与されていない場合、何の変化も生じませんでした。今回の修正により、アプリは操作が静かに失敗するのではなく、その旨を事前に通知するようになりました。
• **修正済み：**トリガーサブスクリプションの数が非常に多いストアでは、権限を付与する際に1つ見落とされたり、権限を取り消す際に1つ取り残されたりすることがありました。
• セットアップガイドは、一度折りたたむと、その状態のままになります。
• このアプリは現在、「Workflow Trigger Extensions」として掲載されています。アプリ自体は同じで、インストール方法も変わりませんが、名称が新しくなりました。

「商品バリエーションの単価変更」イベントは、バリエーションの1個あたりの単価が変更された際に発生します。これは、利益率の再計算、価格改定ルール、または購買部門への通知を目的としています。

なぜこれ専用のトリガーが必要だったのか、その理由を知っておくとよいでしょう。コストは「製品」ではなく「在庫アイテム」に紐づいているため、コストのみが変更された場合、Shopifyは製品の更新を発行しません。製品の更新を監視しているものは、その変更を検知できません。このトリガーは、在庫アイテムを直接監視しています。

商品、バリエーション、SKU、および新旧の原価を金額として返します。既存の「在庫」権限とその「設定」タブを使用します。

Shopify

• ロケーションにおける在庫レベルの変動 - 特定のロケーションにおける利用可能数量が、増減を問わず変更された場合。
• 「ロケーション在庫切れ」 - 在庫数がゼロになった際に表示されます。
• ロケーションでの在庫が復活しました ― プラス水準に戻った時点で発火します。

各イベントには、ロケーションとその名称、バリエーションとSKU、および旧数量、新数量、差分数量が含まれています。そのため、あるフルフィルメント拠点で商品が在庫切れになった場合にのみ、その商品の公開を停止したり、ある倉庫の在庫が少なくなった一方で別の倉庫に余剰在庫がある場合に、在庫移動を実行したりすることができます。

新しい「在庫データへのアクセス」権限が必要となります。これには「ロケーションへのアクセス」も含まれているため、イベントにはIDだけでなくロケーション名も付加されます。いずれかを有効にすると、まず現在の在庫レベルが遡及的に反映されるため、最初の実際の変更がトリガーされます。

B2Bアカウントのメンバーシップに関する2つのトリガーです。いずれも、既存の「会社」権限を使用します：

• 「お客様を会社から削除」 - お客様が会社の連絡先から削除された際に発火します。離脱処理として、ERPへのアクセス権を無効化し、アカウントマネージャーに通知し、レコードをアーカイブします。
• 「会社の連絡先」が更新されました - 連絡先の役割や詳細が変更された際に発火します。

どちらも、お客様と会社の両方を併せて表示し、さらに担当者の役職も表示されます。

「お客様が会社に追加されました」という項目は、あえて追加しませんでした。Shopify Flowには、すでにそのためのネイティブトリガーが用意されているためです。

• 「お客様メモの変更」 - お客様のメモが追加、編集、または削除された際に、新旧の値を併せて通知されます。
• お客様ステータスの変更 - アカウントのステータスが「無効」、「有効」、「招待済み」、「招待拒否」の間で変更された際に発火します。
• 会社のロケーションに関する免税設定の変更 ― あるマーチャントから、B2Bのロケーションの税設定を編集しても、何の変化も起きないとの報告がありました。Shopifyは、この変更に対して更新イベントを一切発信しないため、本機能ではポーリングによって変更を検知します。 このイベントは、追加された、削除された、および現在有効な免税措置を、読みやすいラベル付きのコード一覧と税登録IDとして発行します。

また、8つの下書き注文トリガーについて、イベント履歴に誤った名前が表示されていた問題を修正いたしました。

定期的なセキュリティメンテナンス：アプリ全体の依存関係の更新およびセキュリティ強化を行います。お客様による対応は不要です。

• 「お客様のEメールマーケティングに関する同意の変更」および「お客様のSMSマーケティングに関する同意の変更」 - 同意の状態が変更された瞬間に、新しい状態（購読中、購読解除、または保留中）、オプトインレベル、およびタイムスタンプを通知します。GDPRやマーケティングコンプライアンスの自動化、あるいは除外リストの同期維持に活用できます。
• 「販売チャネルへの商品公開」および**「販売チャネルからの商品非公開**」 - 商品が販売チャネルで公開された、または販売チャネルから削除されたタイミングを把握できます。各イベントには、追加されたチャネル、削除されたチャネル、および現在のチャネルが適切なリストとして含まれているため、テキストを解析する代わりに、Shopify Flow内でそれらを反復処理することができます。 このイベントは、変更ごとに1回発生し、チャネルごとに1回発生するわけではありません。新しい「**Publications Data Access」**権限が必要です。
• 「マーケットの状態が変更されました」 - マーケットの状態が「下書き」から「アクティブ」へ、あるいはその逆へ変更された際に、変更前の状態と変更後の状態と共に通知されます。設定に新しい「**マーケット」**タブが追加されました。

これまでで最大規模のリリースであり、独自のメール通知機能を備えた初めてのリリースです。

上限および障害アラート

ダッシュボードのベルアイコンから開く通知システムです。月間利用枠に近づいたとき、利用枠に達したとき、およびトリガーの失敗が通常より多くなったときに、メールが届きます。ストアオーナー以外の受信者を追加することも可能です。

下書き注文のトリガー (7)

新しい「下書き注文データアクセス」権限により、下書き注文のライフサイクル全体が利用可能になります。これは、注文が確定する前に交渉が行われるB2Bや卸売向けに設計されています。

• 「下書き注文」の更新情報 ― 変更があるたびに通知が表示されます。以下の特定の通知のみを受け取りたい場合は、設定で非表示にしてください。
• 下書き注文のタグの追加／削除案 - タグに基づく承認ゲート。
• 下書き注文のメモが変更されました ― 旧メモと新メモを併記します。
• 下書き注文の属性が変更されました。PO番号、納期、ギフトオプションについて、キーごとの内訳として、追加、削除、変更された項目が記載されています。
• 注文明細の変更案 ― 交渉の過程で、品目、数量、価格、またはバリエーションが調整されたもの。
• 注文ステータスの変更 - 「未処理」、「請求書送信済み」、「完了」の間でステータスが移行します。支払いのリマインダーを定期的に送信するのに最適です。

下書きが作成されるとベースラインが設定されるため、作成後の最初の実際の変更が正しく反映されます。特定のトリガーを有効にすると、既存の下書きにもその変更が遡及的に適用されます。

Shopify Flow 「下書き注文が作成されました」と「下書き注文が削除されました」については、すでにネイティブで対応済みですので、これらについては意図的に重複させないようにしています。

マーケットとロケーション（8）

• マーケットの作成／更新／削除 ― 国際販売およびB2B販売向け。
• ロケーションの作成／更新／削除／有効化／無効化 ― 倉庫、ストア、および受け取り拠点。

注文および商品の詳細

• 注文の財務状況が変更されました - 支払状況の遷移（例：保留中→支払済み、または返金済みなど）。
• 「商品タイプの変更」と「商品ベンダーの変更」――これらはそれぞれ独立してトリガーされるため、ワークフローはベンダーの変更に対して反応しつつ、商品の編集のたびに実行されることはありません。

また

• **「Built for Shopify」**バッジの認定を受けました。
• 安定性とパフォーマンスの改善、および一連のUIの修正が行われました。

Shopify Flow お客様や製品が更新されたことは通知できますが、タグが変更されたことまでは通知できません。これら4つのトリガーは、タグの変更そのものが発生した場合にのみ発動します。

• 追加されたお客様タグ／削除されたお客様タグ
• 追加された商品タグ／削除された商品タグ

それぞれについて、追加されたタグ、削除されたタグ、および変更前後の完全なリストが表示されます。そのため、レコードを改めて読み直す必要はなく、具体的に何が変更されたかに基づいてブランチを作成することができます。

これら4つすべては、「設定」からオプトインで有効にできます。アプリがレコードを初めて検出した際、イベントを発火させることなくベースラインを保存するため、これらの機能を有効にしても、すでに存在していたタグに関するイベントがワークフローに大量に流れ込むことはありません。

また、4つのバリエーション変更トリガーのペイロードから、SKU、バーコード、価格が欠落していた問題も修正されました。

なお、コレクションのタグトリガーは存在しません。Shopifyのコレクションにはタグがありません。代わりに、コレクションのメタフィールドと「Metafield Update」を使用してください。