フロー＆自動化

フロー（flow）は、エージェントのAIの上で動作する視覚的かつ決定論的なスクリプトで、リード獲得、資格確認、サポートの引き継ぎ、予約、決済、外部連携などに使用します。フローはターンをまたいで回答を記憶し、話題が逸れたメッセージの前後で一時停止・再開し、エージェントの通常のAI応答と並行して動作します。

フローを構築する場所

1. エージェントを開き、Automationsを選択します。
2. Automations一覧には、このエージェントに紐づくフローが表示されます。フローをクリックしてエディタを開くか、新規フローを作成します。
3. エディタ内で、パレットからノードをドラッグして接続し、ロジックを構築します。

フローの開始条件

すべてのフローは、発火条件を定義するStartノードから始まります。メッセージが届くと、ルーターはすべてのアクティブなフローのStartトリガーと照合します。複数のフローが該当する可能性がある場合、優先度の高いものから先にチェックされ、最初に一致したものが採用されます。

Startトリガーは4つのモードに対応しています。

フローの実行

会話がフローに入ると、実行エンジンは接続されたノードを1つずつ順に進み、各ノードの出力を次のノードへとつなげていきます。

• 質問はフローを一時停止させます。 顧客に何かを尋ねるノード（Ask QuestionやFormなど）は、返信があるまで停止して待機します。
• 回答は記憶されます。 顧客が提供した情報は保存され、後続のフロー内で再利用できます — 例えば、メッセージやWebhookの中で使用できます。
• 顧客は話題を逸らすことができます。 フローの途中で無関係な質問をされた場合でも、エージェントは通常のAIチャットとして応答できます。フロー自体は一時停止され、顧客は後で再開するか、別のフローを開始できます。
• アクションは二重に発火しません。 あるステップがアクション（Webhookの送信やリードの作成など）を実行した場合、そのステップを再実行してもアクションが繰り返されることはありません。

1ターンあたりにフローが進めるステップ数には上限があるため、1つのメッセージでフローが無限にループすることはありません。

下書きと公開の違い — 公開するまで変更は反映されません

すべてのフローには2つのバージョンがあります。

• Draft（下書き） — フローエディタで表示・編集する内容です。下書きが実際の顧客に対して実行されることはありません。
• Published（公開済み） — 実際のライブ会話で使用されるバージョンです。

Publishをクリックすると、Omagoはフローが有効であること（Startノードが存在し、ノードの設定が正しく、パスが適切に接続されていること）を検証したうえで、新しい公開バージョンを作成します。検証に失敗した場合、公開はブロックされ、下書きは編集可能な状態のまま残るため修正できます。

これはフローに関する最も一般的な問題です — フローを編集してもライブチャットに変更が反映されない、というものです。 ルーターは常に公開済みのバージョンのみをテストします — どんなに小さな変更であっても、編集のたびに再度公開する必要があります。

構成要素: ノード

フローは、キャンバス上で接続するノードから構築されます。各ノードは1つの役割を担い、出力ポートを通じて次のノードに制御を渡します。ほとんどのフローでよく使われる代表的なノードは以下の通りです。

• Start — フローを開始するトリガーを定義します。
• Send Message — 顧客にメッセージを送信します。これまでの回答内容を含めることもできます。
• Ask Question / Form — 顧客から情報を収集し、返信があるまで一時停止します。
• Save Contact — これまでに収集した情報からリードを作成または更新します。
• Handoff — 顧客を有人対応に引き継ぎます（詳細は後述）。
• Payment Link / Booking Link — チャットを離れることなく、顧客が決済や予約を行えるようにします（詳細は後述）。

このほかにも、分岐ロジック、AI生成の返信、サポートチケット、Webhook、CRM連携など、さまざまなノードタイプがあります — フローエディタのノードパレットを開くと、カテゴリ別（Routing、Messaging、Input、Actions、Lead Management、Support）にグループ化された全ノードを確認できます。

会話を有人対応に引き継ぐ

顧客を担当者に引き継ぎたい箇所にHandoffノードを追加します。これにより、顧客が直接担当者に連絡できるWhatsAppのディープリンクまたはリンクカードが生成されます。

これはアプリ内でのリアルタイムな引き継ぎではありません — 誰かが密かに会話を監視していたり、既存のチャットスレッドに割り込んだりすることはありません。あくまで、WhatsAppまたは設定した別のリンク先で担当者との会話を開始する手段を顧客に提供するものです。

入力系ノード（Ask Question、Form）は、顧客が何度か試行しても応答しない場合、自動的にHandoffのパスへとルーティングされます。そのため、行き詰まった顧客のために、常にHandoff（またはその他の逃げ道）を設計しておくことをお勧めします。

チャット内で顧客に決済・予約をしてもらう

1. まず該当する連携を接続します。決済にはStripe、予約には利用中の予約プロバイダー（CalendlyまたはCal.com）を、Settings → Integrationsから設定します。
2. フロー内で、決済URLを生成するPayment Linkノード、または顧客の情報があらかじめ入力された予約リンクを生成するBooking Linkノードを追加します。
3. フローをPublishします — 他の変更と同様、公開するまでライブチャットには反映されません。

いずれのノードも、顧客にアクションを完了させるためのリンクまたはカードを提供します。リクエストが失敗した場合（例えば連携が未接続の場合など）、フローは成功として扱う代わりに、別のエラーパスへとルーティングできます。

次のステップ

• フローエディタのノードパレット全体を確認し、利用可能な全ノードタイプを把握しましょう。
• Settings → IntegrationsでStripe、予約、CRMプロバイダーを連携しましょう。
• Leadsタブで獲得したリードを確認しましょう。