Rule Agentの概要と設定の開始

このガイドでは、Rule Agent を紹介します。Rule Agent で解決できる課題を説明し、最初のフローの作成、テスト、有効化までの手順を案内します。Rule Agent の自動化により、ラベル追加や会話の最適な担当者への割り当てなど、既存の手動プロセスを置き換えて簡素化できます。これにより、サポートチームのメンバーは現在進行中の会話や業務に集中でき、定型作業に費やす時間を削減できます。

初めて利用する場合は、このガイドの手順を順番に進めてください。特定のノードについて確認したい場合は、Rule Agent Node Reference を参照してください。

概要：Rule Agentとは

Rule Agent は、複数のフローを統合して実行する自動処理エージェントです。フローとは、実際の会話を中心に継続的に実行される自動化機能です。

トリガー後すぐに終了する従来の自動化ルールとは異なり、フローでは次のことができます。

• Trigger によって開始される
• 会話をコンテキストとして継続的に進行する
• フローの途中で複数回判断し、分岐する
• ユーザーの操作またはタイムアウトを待機する
• 結果に基づいて後続のステップを続行する

これは、設定可能な会話フローチャートと考えることができます。
ユーザーまたは会話が開始条件を満たすと、フローは先頭から開始され、目標に到達するか終了するまでノード単位で実行されます。

フローと従来の自動化ルールの違い

適切なユースケースを選ぶ

業務プロセスが1回の条件一致と1つのアクションだけで完了しない場合は、フローを使用してください。

一般的なユースケースは次のとおりです。

• 新規訪問者への歓迎対応と振り分け
• 国、流入元、またはラベルに応じて異なる受付経路に分岐する
• 訪問者が返信しない場合や担当者が引き継がない場合に、自動でフォローアップまたはエスカレーションする
• 会話終了後に遅延して満足度アンケートを送信する
• A/B ルーティングによって異なる文言やコンバージョン経路をテストする
• AI 対応が失敗した場合に、自動で人間の担当者へ引き継ぎ、説明メッセージを送信する
• 外部システムを呼び出し、変数を書き戻し、またはフロー中にデータを同期する

開始前に理解しておくべきコア概念

Flow

Flow は、編集、テスト、有効化または無効化が可能な自動化プロセスです。

Trigger

Trigger はフローの開始点です。以下を決定します。

• フローがいつ開始するか
• 誰がフローに入れるか
• どの頻度で入れるか

Node

ノードは、フロー内で最小の機能単位です。
たとえば、メッセージ送信、条件分岐、返信待機、担当者割り当て、データ更新はいずれもノードです。

Exit

Exit はノードからの出力経路です。
ノードによって異なる Exit を持つ場合があります。例：

• デフォルトで続行
• 条件分岐
• Success / failure
• 発生 / タイムアウト
• ボタン分岐 / 未クリック

Audience

Audience は、フローが適用される顧客または会話の範囲を定義します。

Goal

Goal は、フローが業務目標を達成したかどうかを測定するためのイベントです。
たとえば、最初のメッセージ配信、返信受信、評価完了、またはコンバージョン達成などです。

最初のフローを作成して公開する

1. 開始方法を選ぶ

開始方法は次のいずれかです。

• 空白のキャンバスから新しいフローを作成する

• シナリオテンプレートから開始する

これが初めての設定である場合は、テンプレートから開始し、そのパラメータを自社の業務内容に置き換えることをおすすめします。

2. イベントトリガーを設定する

まず、どのイベントがフローを開始するかを定義します。

一般的な開始イベントは次のとおりです。

• 訪問者がメッセージを送信する
• 会話が作成される
• 指定したイベントが発生する
• タイムアウトが発生する
• AI またはシステムイベントが発生する

トリガーを設定する際には、以下も確認してください。

• 対象チャネル
• 対象 Audience

開始条件：設定されたイベントのいずれかが発生し、かつチャネルと Audience の両方が指定された対象に一致していること。

3. フローノードを構成する

業務の順序に沿ってキャンバス上にノードを構築します。ノードタイプは、Decision & Control、Messaging、Action の3つのカテゴリに分かれます。ノードをクリックすると、右側にその設定パネルが表示されます。
ここでノードパラメータの入力、分岐の設定、概要の確認を行います。

一般的な進め方は次のとおりです。

1. Entry ノードで開始点を定義する。
2. Decision & Control ノードで経路とタイミングを決定する。
3. Messaging ノードでユーザーに接触する、またはフィードバックを収集する。
4. Action ノードでデータ更新、担当者割り当て、または外部システム同期を行う。

4. フロー全体のルールを設定する

各ノードに加えて、次のようなフロー全体の情報も設定します。

• フロー名
• 有効化ステータス
• Exit ルール
• 重複排除設定
• 開始頻度

5. フローをテストする

テストはフロー利用において重要な工程です。公開前にテスト機能を使用し、下部の会話ウィンドウでイベントがどのようにフローをトリガーし、実行するかをシミュレーションしてください。左側のシミュレーション操作では条件オプションを設定でき、右側の会話ウィンドウでは実行結果を確認できます。

フローを有効化する前に、少なくとも次の点を確認してください。

• Trigger が正しく一致している
• 条件分岐が想定どおりの経路をたどっている
• 待機およびタイムアウトの Exit が正しい
• 文言、ボタン、リンクが正しい
• データ更新、割り当て、外部呼び出しが適切である

6. フローを有効化し、結果を監視する

フローの公開後も、継続して次の点を監視してください。

• 十分な一致件数を受け取っているか
• 実際の経路が想定どおりか
• ノードが頻繁に失敗またはスキップされていないか
• 目標イベントが実際に改善されているか

7. フローを管理する

一覧ページはフロー管理の入口です。次の用途に使用します。

• すべてのフローを表示する
• ステータスで絞り込む
• 特定のフローを検索する
• テンプレートからフローを作成する
• 実行モードを設定する：Exclusive Matching と Parallel Matching。Exclusive Matching モードでは、同じ開始イベントは最も優先度の高い一致フローにのみ入ります。Parallel Matching モードでは、同じイベントが複数の一致フローに入ることができます。

フローの実行方法

ユーザー視点では、フローは通常次の順序で実行されます。

1. Trigger 条件が発生する。
2. システムが、その会話がフローに入れるかどうかを判断する。
3. フローは開始ノードから始まる。
4. 実行中に、メッセージ送信、条件評価、データ更新、または外部システム呼び出しを行う場合がある。
5. 待機ノードに到達すると、フローは一時停止する。
6. 待機していたアクションが発生するか、タイムアウトすると、フローは続行する。
7. Goal、エンドポイント、または Exit 経路に到達すると、フローは終了する。

重要なのは、フローはすべてのロジックを一度に計算するわけではないという点です。代わりに、実際の会話のコンテキスト内で段階的に進行します。

ベストプラクティスと制限事項

フロー設定前にGoalを定義する

最初からノードを積み上げて始めないでください。
より確実な方法は、まず次の点を決めることです。

• フローが解決する課題は何か
• ユーザーをどこへ導きたいか
• どのイベントを成功とみなすか

先にAudienceと開始頻度を定義する

Audience が広すぎたり、開始頻度が高すぎたりすると、ユーザーに繰り返し連絡してしまう可能性があります。
優先して確認すべき点は次のとおりです。

• どのユーザーが入れるか
• 同じユーザーがどの頻度で入れるか
• 同じ会話が繰り返し入れるか

ボタン分岐にはフォールバック経路を用意する

メッセージノードで分岐ボタンを使用する場合は、クリック後の経路だけでなく、次の点も考慮してください。

• ユーザーがクリックしなかった場合に何が起こるか
• どのくらいの時間を未クリックとみなすか
• クリックされなかった後に終了、リマインド、または別経路へ振り分けるか

Waitノードでは必ずタイムアウトを考慮する

返信、クリック、イベントのいずれを待つ場合でも、一般的にはタイムアウト Exit を設定することをおすすめします。
そうしないと、フローが途中で停止したままとなり、続行できなくなる可能性があります。

チャネルごとに利用可能な機能が異なる場合がある

フローが複数チャネルを対象とする場合、それらのメッセージ機能が完全に同一とは限りません。たとえば次のような違いがあります。

• サポートされる添付ファイルの種類が異なる場合がある
• リッチメディアの表示方法が異なる場合がある
• ボタン操作の機能が異なる場合がある
• 文言の長さやファイル制限が異なる場合がある

メッセージノードを設定する際は、すべての対象チャネルに適用できることを確認してください。

割り当てアクションはチャネルルールに従う必要がある

担当者、チーム、または AI を割り当てる際は、その割り当てがシステムの既存スコープと業務ルールを満たしている必要があります。
対象を現在の会話に割り当てられない場合、フローは想定どおりに引き継ぎを完了できない可能性があります。

WebhookとAPI呼び出しを区別する

• Webhook は、現在のイベント情報またはフロー情報を外部システムへプッシュする用途に適しています。
• API 呼び出しは、外部システムからデータを取得し、その結果を後続の判断に利用する用途に適しています。

この2種類のノードを同じものとして扱わないでください。

公開前に4種類の経路をテストする

• デフォルトの主要経路
• 失敗経路
• タイムアウト経路
• ユーザーが何もしない経路

トラブルシューティングとFAQ

フローがトリガーされなかったのはなぜですか？

まず次の点を確認してください。

• Trigger イベントが実際に発生したか
• 現在のユーザーが対象 Audience に属しているか
• チャネルが対象範囲内か
• 開始頻度によって再入場が防止されていないか
• 他のフローのガバナンスルールによってブロックされていないか

なぜ別の分岐に進んだのですか？

よくある原因は次のとおりです。

• 現在の会話プロパティが想定と異なっている
• 条件の順序が異なる
• フォールバック分岐に一致した
• 外部結果または変数値がテスト時の想定と異なる

ボタンがクリックされなかった場合はどうなりますか？

メッセージノードに未クリックの時間枠が設定されている場合、タイムアウト期限が切れると、フローは未クリック経路を通って続行します。

フローを長時間実行できますか？

はい。ただし、フローの実行時間が長くなるほど、次の点により注意を払う必要があります。

• 開始頻度
• タイムアウト設定
• Goal イベント
• 他のフローとの競合ガバナンス

どのような場合にプロセスを2つのフローに分けるべきですか？

2つの業務目標、Audience、ガバナンスルール、またはフローの進行ペースが大きく異なる場合は、通常、別々のフローに分ける方が適切です。

すべてのロジックを1つのフローに入れるのを避けるべきなのはどのような場合ですか？

1つのフローで、歓迎対応、コンバージョン、アフターサービス、満足度回収を同時に扱うと、後の保守やテストが通常より複雑になります。
各フローは1つの業務目標を中心に構築してください。