--- type: feature title: "EC向けビジュアルワークフロー自動化ツール" description: "Runner AIのビジュアルワークフロー自動化ツールでストアイベントのフローを構築し、ペイロードをシミュレーションして、公開前にノード結果と下書きを確認できます。" category: ai-marketing h1: "ビジュアルワークフロー自動化ツールでストアのフローを構築" image: "https://storage.googleapis.com/runner-blog/features/visual-workflow-automation-tool/hero.png" keyword: "ビジュアルワークフロー自動化ツール" legacyKind: structured --- Runner AIの**ビジュアルワークフロー自動化ツール**では、EC運営者が接続されたステップを配置し、ストアイベントまたは手動入力を指定して、公開前に下書きをシミュレーションできます。テストごとに、ノード単位の結果とトレースを含む確認可能な実行履歴が作られます。見えない自動処理をそのまま信頼するのではなく、どのステップがデータを受け取り、どこでデータが変わり、どこでフローが止まったかをチームで確認できます。 ## 確認手順からビジュアルワークフロー自動化ツールを評価する ビジュアルキャンバスが役立つのは、運用ロジックを確認しやすくするときだけです。Runner AIでは、各ワークフローをストアプロジェクト内に保ち、処理を接続されたノード、入力、出力として表します。運営者は空白のワークフローから始めるか、利用可能なテンプレートを選び、実際のストア業務に合わせてフローを整えられます。同じワークスペースで下書きの変更とデプロイ済みバージョンを区別し、ワークフローが公開中、一時停止、ブロック、予約済み、実行中、完了、失敗のどの状態かを表示します。 この状態モデルによって、確認者は各段階で実用的な問いを立てられます。今は何が設定されていて、本番環境では何が実行されるのか。実行できない図は文書にすぎず、分岐が隠された自動化は承認しにくいものです。Runnerのビルダーは、ビジュアルモデルをシミュレーションと実行履歴へつなぎます。自動化に依存する前にフローを見て、入力をテストし、実際の結果を確認したいチームのための設計です。 ## テンプレートまたは空白のストアワークフローから構築する 開始方法は業務に合わせて選びます。空白のワークフローでは、運営者がノードと接続を直接制御できます。利用可能なテンプレートなら、チームが自分たちのプロジェクトに合わせて調整できる既知の構成から始められます。どちらの場合も、役立つ入力は具体的です。ストアイベントまたは手動トリガーを指定し、各ステップに必要なデータを特定し、期待する変換やアクションを定義して、テストが正しく動いたことを示す証拠を決めます。 たとえば、注文イベントからサンプルの注文IDを判断ステップへ渡し、その後にメールアクションや在庫関連のアクションへ進められます。利用できる正確なノードは、現在のワークフローカタログとプロジェクトに接続されたサービスによって異なるため、このページではあらゆる連携を提供するとは約束しません。確認の原則は変わりません。イベントデータを見える状態に保ち、ストアに必要なステップだけを接続し、キャンバスをテスト対象のバージョンとして扱う前に下書きの変更を保存します。 イベントグラフではなく、商品、顧客、承認範囲から始めるキャンペーン業務については、関連する計画手順を扱う[EC向けマーケティングキャンペーン管理ソフトウェア](/ja/marketing-campaign-management-software)を参照してください。ビジュアルワークフローのページが扱うのは、実行可能なノード接続を構築してテストするという、より限定された評価作業です。 ## デプロイ前にストアイベントをシミュレーションする Runner AIは、直接入力とイベントペイロードを使ったワークフローのシミュレーションに対応しています。チームは入力ノードへサンプル値を指定するか、`order.created`などのイベントについてシミュレーションダイアログを開き、サンプルペイロードを確認して、シナリオに必要なテストデータへ置き換えられます。シミュレーションは本番の結果をキャッシュせず、ビルダーは実行を始める前にキャンバスの未保存の変更を保存します。保存に失敗した場合、その実行を古い、または一部しか保存されていないグラフの証拠として扱うべきではありません。 この区別はEC運営で重要です。もっともらしいキャンバスにも、誤った項目、分岐、アクションの順序が含まれる可能性があります。テストペイロードを使えば、注文IDが意図したノードへ届いたか、判断に期待した値が使われたか、後続のステップが結果を受け取ったかを確認できます。また、シミュレーションとデプロイを分けて扱えます。サンプルデータで下書きを実行することは検証の一段階であり、ワークフローが実際のストアイベントを処理することを許可するものではありません。 ## ノード結果、トレース、ワークフローの状態を確認する 確認可能な実行履歴には、最終的な成功バッジ以外の情報も必要です。Runnerの実行履歴では、テストと本番の処理を区別し、シミュレーションの進行状況を表示して、各ノードに対応する結果を確認できます。シミュレーションのトレースは、外部サービスに対して実行せずスキップしたステップも含め、テストで何が行われたかを示します。実行が失敗した場合、トレースとノード結果を使うことで、不透明な処理全体を再実行するよりも調査範囲を絞れます。 運営者は下書きに戻り、該当するノードや入力を変更して保存し、もう一度シミュレーションを実行できます。ワークフロー一覧では検索と状態による絞り込みができるため、下書き、公開中のフロー、一時停止中のバインディング、完了した実行、失敗を一つの未分類キューで扱う必要はありません。管理作業向けの一括操作もありますが、確認範囲は限定してください。何かを一時停止または削除する前に、本番で有効なトリガーを確認し、一つのサンプルが成功しても、すべての実際のペイロードを網羅したとは考えないでください。 ワークフローに顧客向けのキャンペーンメールが含まれる場合は、[ECキャンペーン向けAIメール生成ツール](/ja/ai-email-generator)を使い、件名、プリヘッダー、構造化された本文、保存済みプレビューを別の成果物として確認してください。ワークフローのトレースではメールステップが実行されたことを確認できますが、内容の確認はメールプレビューで行います。 ## 確認したいストアイベントを基準にツールを選ぶ 一般的な自動化ツールの比較では、コネクター数、ホスティング方式、時間短縮に関する広い主張が先に挙げられがちです。これらの基準も重要ですが、EC運営者には、提案されたフローを公開前に代表的なストアデータでテストできるかどうかも必要です。範囲を限定した一つのイベントと、観察可能な一つの結果から評価を始めます。ペイロードを定義し、必要最小限のノードを接続してシミュレーションを行い、各結果を期待する経路と照合します。 ビジュアルキャンバスは、分岐数を最大化するのではなく、分岐を理解しやすくするために使います。テンプレートのロジックがストア業務に合う場合に限り、設定を減らすために利用します。実行履歴を使って、実際に起きたことと下書きが示す内容を比較します。シミュレーションの証拠を確認した後に、デプロイを別の判断として行います。この構築、テスト、確認の順序が、Runner AIによるビジュアルワークフロー自動化の具体的な形です。キャンバス、イベントペイロード、保存済みの下書き、トレースが、同じストアプロジェクト内でつながったままになります。 > ストアイベント、サンプルペイロード、必要な判断ルール、実行したいアクションから、EC向けのビジュアルワークフローを構築してください。下書きのままサンプルデータでシミュレーションを実行し、デプロイ前に確認できるノードごとの結果と実行トレースを返してください。 [Runner AIでビジュアルワークフロービルダーを開く](https://www.runnerai.com/ja/auth/login?prompt=%E3%82%B9%E3%83%88%E3%82%A2%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%80%81%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%83%9A%E3%82%A4%E3%83%AD%E3%83%BC%E3%83%89%E3%80%81%E5%BF%85%E8%A6%81%E3%81%AA%E5%88%A4%E6%96%AD%E3%83%AB%E3%83%BC%E3%83%AB%E3%80%81%E5%AE%9F%E8%A1%8C%E3%81%97%E3%81%9F%E3%81%84%E3%82%A2%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%8B%E3%82%89%E3%80%81EC%E5%90%91%E3%81%91%E3%81%AE%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%95%E3%83%AD%E3%83%BC%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%97%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84%E3%80%82%E4%B8%8B%E6%9B%B8%E3%81%8D%E3%81%AE%E3%81%BE%E3%81%BE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%83%87%E3%83%BC%E3%82%BF%E3%81%A7%E3%82%B7%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%97%E3%80%81%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E5%89%8D%E3%81%AB%E7%A2%BA%E8%AA%8D%E3%81%A7%E3%81%8D%E3%82%8B%E3%83%8E%E3%83%BC%E3%83%89%E3%81%94%E3%81%A8%E3%81%AE%E7%B5%90%E6%9E%9C%E3%81%A8%E5%AE%9F%E8%A1%8C%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%E3%82%92%E8%BF%94%E3%81%97%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84%E3%80%82) ## ビジュアルワークフロー自動化ツールについてよくある質問 ### ビジュアルワークフローを構築するには、どのような入力が必要ですか？ ストアイベントまたは手動トリガー、代表的なサンプルペイロード、ワークフローで必要な判断、各分岐の後に実行するアクションを指定します。重要なノードごとに期待する結果も示してください。テストデータには実際の顧客の機密情報を使わず、必要な項目の構造を保ちながら確認者が経路を検証できる安全なサンプルを使います。 ### イベント駆動型ワークフローを公開前にテストできますか？ はい。Runnerのワークフロービルダーでは、直接入力またはイベントペイロードをシミュレーションし、テスト実行を記録できます。シミュレーションを始める前に下書きを保存し、得られたノード出力とトレースを期待する経路と比較してください。サンプルが成功しても、そのシナリオの証拠になるだけで、デプロイの許可でも、すべての本番ペイロードが成功する証明でもありません。 ### ワークフローのシミュレーション後に何を確認できますか？ 実行状態、テストに指定した入力、各ノードに対応する結果、実行トレースを確認できます。シミュレーション中に意図してスキップされたアクションがあるか、失敗したノードが期待したデータを受け取っていたかを確認してください。観察した内容を基に、下書きの関連する最小範囲を修正し、保存してもう一度シミュレーションします。 ### Runner AIはグラフの生成後にワークフローをデプロイしますか？ いいえ。グラフの構築やシミュレーションと、本番バインディングの有効化は別です。Runnerは下書きの変更とデプロイ済みバージョンを区別し、ワークフロー一覧では公開中、一時停止、ブロック、予約済み、実行中、完了、失敗、下書きなどの状態を表示します。対応するデプロイ操作を選ぶ前に、有効なトリガーと直近に保存したシミュレーションの証拠を確認してください。 ### ビジュアルワークフローとメールキャンペーンの下書きは同じものですか？ いいえ。ビジュアルワークフローは、接続されたトリガー、判断、アクションを定義します。メールキャンペーンの下書きは顧客向けのコンテンツ成果物で、独自の件名、プリヘッダー、本文、プレビュー、対象読者、配信確認があります。ワークフローにメールアクションを含めることはできますが、実行トレースは保存済みメール自体の確認に代わるものではありません。 [ECマーケティングカレンダーでタイミングを調整する](/ja/ecommerce-marketing-calendar)。 [Runner AIの全機能を見る](/ja)