ルールエージェントの開始と設定ガイド

このガイドでは、ルールエージェントの使い方を説明します。ルールエージェントがどのような課題の解決に適しているかを理解し、最初のフローの作成、テスト、アクティブ化までの設定を完了できます。ルールエージェントを活用して自動化することで、タグの追加や最適なカスタマーサービス担当者への会話の割り当てなど、既存の手動作業を置き換えたり簡略化したりできます。これにより、カスタマーサービスチームは現在対応中の会話やタスクに集中でき、定型業務にかかる時間を削減できます。

ルールエージェントを初めて利用する場合は、この記事の手順を順番に実施してください。特定のノードについて確認したい場合は、「ルールエージェントノードリファレンス」を直接参照してください。

概要：ルールエージェントとは

ルールエージェントは、複数のフローを統合する自動処理エージェントです。一方、フローは実際の会話を中心に継続的に動作する自動ワークフローです。

これは、条件に一致した直後に終了する従来の自動化ルールとは異なります。代わりに、次のような処理を行える仕組みです。

• トリガーによって開始する
• 会話を中心に処理を継続する
• ワークフロー中に複数回、条件を評価してユーザーを振り分ける
• ユーザーの操作またはタイムアウトを待機する
• 結果に基づいて後続のステップを続行する

設定可能な会話フローチャートとして考えることができます。ユーザーまたは会話が開始条件を満たすと、フローは最初から開始し、目標に到達するかワークフローが終了するまで、ノードごとに進行します。

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

適切なユースケースを選択する

ビジネスプロセスを1回の一致と実行だけで完了できない場合は、フローの利用が適しています。

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

• 新規訪問者を歓迎し、適切に振り分ける
• 国、流入元、タグに基づいて異なる受付経路に振り分ける
• 返信がない訪問者や、カスタマーサービス担当者が参加していない会話に対して、自動でフォローアップまたはエスカレーションする
• 会話終了後、一定時間の経過後に満足度調査を送信する
• A/B振り分けによって異なる文言やコンバージョン経路をテストする
• AIサービスで例外が発生した場合に、会話を人間のエージェントへ自動転送し、説明メッセージを送信する
• ワークフロー中に外部システムを呼び出し、変数を書き戻したり、情報を同期したりする

開始前に：基本概念を理解する

フロー

フローは、編集、テスト、アクティブ化が可能な自動ワークフローです。

トリガー（トリガーイベント）

トリガーはワークフローの開始点です。次の内容を決定します。

• ワークフローを開始するタイミング
• 誰が参加できるか
• 参加できる頻度

ノード

ノードは、ワークフローにおける最小の機能単位です。

メッセージの送信、条件に基づく分岐、返信の待機、カスタマーサービス担当者の割り当て、情報の更新は、すべてノードによって処理されます。

終了

終了は、ノードからの出力経路です。

ノードによって、次のような終了を設定できます。

• デフォルトで継続
• 条件分岐
• 成功／失敗
• 発生／タイムアウト
• ボタンのクリック／未クリック

オーディエンス

オーディエンスは、このフローを適用する顧客または会話の対象範囲です。

目標（目標イベント）

目標は、フローがビジネス上の目的を達成したかどうかを測定するための対象イベントです。

たとえば、最初のメッセージの配信、返信の受信、評価の完了、コンバージョンの達成などがあります。

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

1. 開始方法を選択する

次の2つの方法のいずれかで開始できます。

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

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

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

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

まず、このフローを開始するイベントを決定します。

一般的な開始点は次のとおりです。

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

トリガーを設定するときは、次の項目もあわせて確認することをおすすめします。

• 対象チャネル
• 対象オーディエンス

開始条件：現在のイベントが設定されたイベントのいずれかに一致し、かつチャネルとオーディエンスの両方が指定された対象に含まれていること。

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

ビジネスプロセスに必要な順序で、キャンバス上にノードを配置します。ノードタイプは、判断と制御、メッセージ、アクションの3つのカテゴリに分かれています。ノードをクリックすると、右側に設定パネルが表示されます。

ここでパラメーターを入力し、分岐を設定し、各ノードの概要を確認します。

一般的なワークフロー設計の原則は次のとおりです。

1. 開始ノードで開始点を定義します。
2. 判断と制御のノードで経路とタイミングを決定します。
3. メッセージノードで外部への連絡やフィードバックの収集を処理します。
4. アクションノードで情報を更新し、カスタマーサービス担当者を割り当て、外部システムと同期します。

4. フローレベルのルールを設定する

ノード自体に加えて、次のようなフローレベルの情報も設定する必要があります。

• フロー名
• アクティブ化ステータス
• 終了ルール
• 重複排除設定
• 開始頻度

5. フローをテストする

テストはフローの重要な機能であり、正式公開前に利用できます。下部の会話ウィンドウでは、イベントによってフローがどのようにトリガーされ、実行されるかをシミュレーションして確認できます。左側のシミュレーションコントロールパネルには条件オプションが表示され、右側の会話ウィンドウには実行結果が表示されます。

アクティブ化する前に、少なくとも次の項目を確認することをおすすめします。

• トリガーが正しく一致するか
• 条件分岐が想定した経路に従うか
• 待機およびタイムアウトの終了が正しいか
• 文言、ボタン、リンクが正しいか
• 情報の更新、割り当て、外部呼び出しが適切か

6. アクティブ化して結果を監視する

公開後は、次の項目を継続的に監視することをおすすめします。

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

7. フローを管理する

一覧ページは、フロー管理の入口です。次の操作に使用できます。

• すべてのフローを表示する
• ステータスで絞り込む
• 指定したフローを検索する
• テンプレートから新しいフローを作成する
• 実行モードを設定する：排他的マッチングと並列マッチングを区別します。排他的モードでは、同じ開始イベントは最も優先順位の高い一致フローにのみ入ります。並列モードでは、同じイベントが複数の一致フローに入ることができます。

フローの実行方法

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

1. トリガー条件が発生します。
2. システムが、会話をフローに参加させられるかどうかを判断します。
3. フローが初期ノードから実行を開始します。
4. 実行中に、メッセージ送信、条件評価、情報更新、外部システムの呼び出しなどが行われます。
5. 待機ノードに到達すると、ワークフローが一時停止します。
6. 想定されたアクションが発生するか、タイムアウトに達すると、ワークフローが続行します。
7. 目標に到達する、終了ノードに到達する、または終了経路がトリガーされると、ワークフローが終了します。

次の点を理解しておくことが重要です。

フローはすべてのロジックを一度に計算するわけではありません。実際の会話コンテキストの中で、ステップごとに処理を進めます。

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

ワークフローを設定する前に目標を定義する

最初からノードを追加し始めないでください。

より信頼性の高い方法は、まず次の項目を明確にすることです。

• このフローで解決する課題
• ユーザーを最終的にどこへ導きたいか
• どのイベントを成功とみなすか

まずオーディエンスと開始頻度を決定する

オーディエンスが広すぎたり、開始頻度が高すぎたりすると、ユーザーに繰り返し連絡することになります。

まず、次の項目を確認することをおすすめします。

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

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

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

• ユーザーがクリックしなかった場合にどうなるか
• アクションが未クリックとみなされるまでの時間
• クリックされなかった場合に、ワークフローを終了するか、リマインダーを送信するか、別の経路に切り替えるか

待機ノードではタイムアウトを考慮する

返信、クリック、イベントのいずれを待機する場合でも、通常はタイムアウトの終了を設定することをおすすめします。

設定しない場合、ワークフローが途中で停止し、そのまま続行できなくなる可能性があります。

チャネルによって利用可能な機能が異なる場合がある

同じフローを複数のチャネルに適用する場合、メッセージ機能がチャネル間で完全に一致しないことがあります。たとえば、次のような違いがあります。

• 添付ファイルの種類が異なる
• リッチメディアの表示方法が異なる
• ボタン操作が異なる
• 文言の長さやファイル制限が異なる

そのため、メッセージノードを設定するときは、すべての設定が対象チャネルで利用可能であることを確認してください。

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

カスタマーサービス担当者、チーム、またはAIを割り当てる場合、その割り当ては、システムにあらかじめ設定されている割り当て範囲とビジネスルールに従う必要があります。

対象が現在の会話で割り当て可能な範囲に含まれていない場合、ワークフローによる引き継ぎが想定どおりに完了しない可能性があります。

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

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

この2種類のノードを混同しないでください。

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

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

トラブルシューティングとよくある質問

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

まず、次の項目を確認してください。

• トリガーイベントが実際に発生したか
• 現在のユーザーが対象オーディエンスに含まれているか
• チャネルが設定範囲に含まれているか
• 開始頻度によって繰り返し参加が制限されていないか
• 別のフローのガバナンスルールによってブロックされていないか

フローが別の分岐に進んだのはなぜですか？

通常、次のいずれかが原因です。

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

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

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

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

はい。ただし、ワークフローが長くなるほど、次の項目に注意する必要があります。

• 開始頻度
• タイムアウト設定
• 目標イベント
• 他のフローとの競合に関するガバナンス

フローを2つに分割するのはどのような場合ですか？

ビジネス目標、対象オーディエンス、ガバナンスルール、またはワークフローの進行ペースが大きく異なる場合は、通常、フローを分割した方が適切です。

すべてのロジックを1つのフローにまとめることが推奨されないのはどのような場合ですか？

1つのフローで、ウェルカム、コンバージョン、アフターサービス、満足度調査など複数の目的を処理すると、その後のメンテナンスやテストが複雑になりやすくなります。

1つのビジネス目標を中心にワークフローを構築することをおすすめします。