統合
Start a conversation (会話を開始) エレメントは、Transfer chat to agent (エージェントへのチャットの転送) に名前が変更されました。
フローの統合エレメントを使用して、外部プラットフォームと接続します。
Transfer chat to agent (エージェントへのチャットの転送)
テキストベースのチャットのためにエンドユーザーをライブエージェントに転送したい時は、このエレメントを使用します。
音声チャネルを通じてエージェントに転送するには、Transfer chat to agent (エージェントへのチャットの転送) エレメントを使用します。
エレメントの構成
(任意) エレメントのサイドパネルで、会話 タグ を割り当てて、次の操作を行います。
- フローを Conversationsの関連するキューにルーティングします。
- 会話の内容をエージェントに通知します。例:data verification (データ検証) というタグを追加して、エージェントがエンドユーザーの情報を検証する必要があることを示します。
All conversation tags (すべての会話タグ) セクションで、新しいタグを作成するか、既存のタグを1 つ以上選択します。

例
このエレメントの使用例については、効率的なサインアップとアカウントの検証方法 と題したチュートリアルをご参照ください。
このエレメントはコールセッションで使用します
このエレメントは、以下の例に示すように、コール (IVR) セッションで使用できます。
-
Play (再生) エレメントを使用して、エンドユーザーが対応可能なエージェントと繋がるまで回線で待つか、WhatsAppなどのテキストベースのチャネルを使用するかを尋ねます。
例:
エージェントとテキストベースのチャットを行うには、1を選択します。待ち時間は1分です。
電話でエージェントと話す場合は、2を選択します。待ち時間は12分です。
-
エンドユーザーがテキストベースのチャネルを使用する場合は、音声セッションを Hang up (通話を終了)し、Transfer chat to agent (エージェントへのチャットの転送) エレメントを追加します。
-
エンドユーザーがエージェントと繋がるのを待つ場合は、Transfer call to agent (エージェントへのコールの転送) エレメントを使用します。

Transfer call to agent (エージェントへのコールの転送)
このエレメントを使用して、音声通話 (IVRコール) をConversations内のライブエージェントに転送します。
- このエレメントは、インバウンドIVRセッション内でのみ使用できます。
- IVRセッション以外で (即ち、テキストベースのチャットのために) エンドユーザーをエージェントに転送するには、Transfer chat to agent (エージェントへのチャットの転送) エレメントを使用します。
エレメントを構成 し、エレメント内のブランチを使って、フローの次のステップを指定します。
エレメントの構成
エレメントのサイドパネルで、以下のフィールドの構成を完了します。
Call origin (発信元)
このフィールドを使用して、会話に関するコンテキストをエージェントに提供します。例: 予定のスケジュールの再調整。Conversationsでは、この情報はポップアップメッセージとして表示されます。
Add call origin (発信元の追加) を選択し、コンテキストを指定します。
このフィールドを構成しない場合は、フロー名がコンテキストとして使用されます。
Conversation tags (会話タグ)
(任意) 会話 タグ を割り当てて、次の操作を行います。
- フローを Conversationsの関連するキューにルーティングします。
- 会話の内容をエージェントに通知します。例:data verification (データ検証) というタグを追加して、エージェントがエンドユーザーの情報を検証する必要があることを示します。
All conversation tags (すべての会話タグ) セクションで、新しいタグを作成するか、既存のタグを1 つ以上選択します。

次のステップ
次のステップの操作には、エレメント内の下記のブランチを使用します。
ブランチ | コールセッションのステータス |
---|---|
Call forwarded (コールを転送) | コールが転送され、エンドユーザーと転送先の間でコールセッションが正常に成立したことを示します。この時点でフローはコールセッションから抜けます。 |
Call not forwarded (コールを転送できず) | フローはコールを転送できず、エンドユーザーと転送先の間でコールセッションが成立しなったことを示します。この場合、コールセッションは、エンドユーザーとフローの間で続行されます。 |
Call ended (コールが終了) | コールがエンドユーザーによって、またはネットワークの問題が原因で転送される前に終了したことを示します。 |
音声アプリケーションへのコールの転送
このエレメントを使用して、音声通話 (IVRコール) をフローからカスタムアプリケーションのコールAPIに転送します。これにより、アプリケーション内でコールを管理できるようになります。
このエレメントは、IVR セッション内でのみ使用できます。
前提条件
- IVRコールの転送先となる コールAPIベースのアプリケーション (opens in a new tab) が必要となります。このアプリケーションは、アプリケーション転送リクエストイベントを処理できるようにしておく必要があります。
- 一意のIDを持つ コール構成 (opens in a new tab) を完了しておく必要があります。
エレメントの構成
エレメントのサイドパネルで、以下のフィールドの構成を完了します。
- Calls configuration ID (コール構成ID):アプリケーションのコール構成ID を選択します。
- Custom data (カスタムデータ) (任意):必要に応じて、キーと値のペアを使用してカスタムデータを追加します。このデータはアプリケーションに送信されます。

次のステップ
エレメント内の出口ブランチごとに、次のステップを構成します。
各ブランチについては、以下の表を使って説明します。
イベント | 説明 |
---|---|
Call transferred (コールを転送) | フローがIVRコールをアプリケーションに転送し、エンドユーザーとアプリケーションの間でコールセッションが正常に成立したことを示します。この時点でフローはコールセッションから抜けます。 |
Call not transferred (コールを転送できず) | フローはIVRコールをアプリケーションんに転送できなかったことを示します。これにはいくつかの理由が考えられます。例:APIコール自体が失敗に終わったため。または、エンドユーザーとアプリケーションの間でコールセッションが成立しなかったため。この場合、コールセッションは、エンドユーザーとフローの間で続行されます。 |
Call ended (コールが終了) | IVRコールがエンドユーザーによって、またはネットワークの問題が原因で転送される前に終了したことを示します。 |
エレメントの機能テスト
Transfer call to voice application (音声アプリケーションへのコールの転送) エレメントの機能を確認するには、カスタムウェブフックを使用します。フローからウェブフックへのコールの転送をテストします。
コール転送用のシステムのセットアップ
- IVRコールの転送先となるウェブフックを構成します。
- 一意のIDを持つ コール構成 (opens in a new tab)を作成します。
- 通知プロファイル を作成します。
- ウェブフックのURLを使用します。
- サブスクリプション を作成します。
- Voice チャネルを選択します。
- 必要なイベントを選択します。
- 作成した通知プロファイルを選択します。
フローの構成
-
フロー内のIVRセッションに、Transfer call to voice application (音声アプリケーションへのコールの転送) エレメントを追加します。
-
エレメント内の以下のフィールドの構成を完了します。
- Calls configuration ID (コール構成ID):作成したコール構成IDを選択します。
- Custom data (カスタムデータ) (任意):必要に応じて、キーと値のペアで構成するカスタムデータを追加することもできます。このデータは、リクエスト本文に含めてウェブフックに送信されます。
-
エレメント内の出口ブランチごとに、次のステップを構成します。
-
必要に応じてフローの構成も調整します。
-
フローをアクティブにします。
これで、コール情報をお使いのウェブフックで取得できるようになります。

Start chatbot (チャットボットを開始) (Answers)
エンドユーザーをフローからAnswers チャットボットに振り向けたい時は、Start chatbot (チャットボットを開始) (Answers) エレメントを使用します。チャットボットセッションが終了すると、エンドユーザーはフローに戻ります。
前提条件
-
NTT CPaaSのアカウントでAnswersを有効化 すると、フロー内のStart chatbot (チャットボットを開始) (Answers) エレメントにアクセスできるようになります。
-
SMS、Viber、WhatsAppなどのテキストベースのチャネルを使用するアクティブなAnswersチャットボットを作成するには、Answers について詳述しているドキュメントをご参照ください。
Answersチャットボットは、フローで使用しているのと同じチャネルと送信者を使用する必要があります。
フローの設計基準
- チャットボットセッションは、エンドユーザーから最初のメッセージを受信した後にのみ開始できます。インバウンドメッセージの評価 エレメントを使用して、エンドユーザーのメッセージを取得します。
- Start chatbot (チャットボットを開始) (Answers) エレメントは、Evaluate inbound message element (インバウンドメッセージエレメントの評価) の後にのみ追加できます。そのため、この2つのエレメントはフロー内の同じブランチの中にある必要があります。
- エージェントへの転送はフローで行う必要があります。チャットボットにTo agent (エージェントへ) エレメントが含まれていて、エンドユーザーがこのエレメントに到達した場合、エンドユーザーはフローに戻ります。フローのTransfer chat to agent (エージェントへのチャットの転送) (integrations#transfer-chat-to-agent-integrations) エレメントを使用して、エンドユーザーをエージェントに繋ぎます。
プロセスの概要
- Evaluate inbound message (インバウンドメッセージの評価) エレメントからのエンドユーザーのメッセージは、LastInboundMessage (最後のインバウンドメッセージ) 変数を通じて Start chatbot (チャットボットを開始) (Answers) エレメントに送信されます。
- エンドユーザーが Start chatbot (チャットボットを開始) (Answers) エレメントに到達すると、フローは、Evaluate inbound message (インバウンドメッセージの評価) エレメントで構成されているのと同じチャネルと送信者を使用するチャットボットを自動的に選択します。
- チャットボットは、Start chatbot (チャットボットを開始) (Answers) エレメントからメッセージを受信します。
- チャットボットセッションが開始され、エンドユーザーがチャットボットにリダイレクトされます。
- チャットボットセッションが終了すると、エンドユーザーはフローに戻ります。
- エンドユーザーは、フロー構成に基づいてそれぞれのフロージャーニーを続行します。
フローは、ユーザーを送信者に関連付けられているアクティブなチャットボットにリダイレクトします。そのため、関連付けられたチャットボットが停止され、同じ送信者で新しいチャットボットが作成された場合、フローはエンドユーザーを新しいチャットボットにリダイレクトします。
フローをキャンセルしても、関連するチャットボットは影響を受けません。
フローの作成
-
Evaluate inbound message (インバウンドメッセージの評価) エレメントをフローに追加します。
-
送信者と条件に関するエレメントの構成を完了します。
-
Start chatbot (チャットボットを開始) (Answers) エレメントを同じブランチに追加します。
-
エレメント内の以下のフィールドの構成を完了します。
-
Chatbot sender (チャットボットの送信者):このフィールドには、Evaluate inbound message (インバウンドメッセージの評価) エレメントの To recipient (受信者へ) フィールドの送信者が事前に入力されています。
Evaluate inbound message (インバウンドメッセージの評価) エレメントで送信者を更新する場合、Start chatbot (チャットボットを開始) (Answers) エレメントで送信者を更新する必要があります。これを行うには、Update chatbot sender (チャットボットの送信者の更新) を選択します。
-
Message received by chatbot (チャットボットが受信したメッセージ):デフォルトでは、このフィールドにLastInboundMessage (最後のインバウンドメッセージ) 変数が入力されています。チャットボットと共有する追加情報とコンテキストを指定します。
このフィールドの内容はチャットボットに送信されます。
-
Condition (条件) (任意) : 1つ以上の終了条件を選択して、チャットボット セッションで発生する内容に基づいてフローをリダイレクトします。Start chatbot (チャットボットを開始) (Answers) エレメントには、選択した条件ごとに終了ブランチが自動的に追加されます。
-
-
Start chatbot (チャットボットを開始) (Answers) エレメントの終了ブランチごとに、次のステップを構成します。
以下の表に、各条件の説明と条件に関する次のステップの例を示します。
条件 | 説明 | 次のステップの例 |
---|---|---|
Session not started (セッションが開始されていない) | チャットボットセッションを開始できませんでした。これにはいくつかの理由が考えられます。例: フローがアクティブ化された後、チャットボットが非アクティブ化されたため | |
Session ended externally (new session started) (セッションが外部で終了 (新しいセッションが開始)) | 新しい外部セッションが開始されたため、チャットボットセッションが終了しました。例: エンドユーザーに対して Conversations を介して新しいセッションが開始されたため | |
Session expired by timeout (セッションがタイムアウトによって期限切れ) | チャットボットがエンドユーザーから応答を受信しなかったため、チャットボットセッションがタイムアウトしました。 | 翌日にエンドユーザーを再びターゲットにして、リクエストが正常に解決されたかどうかを確認するようにします。 |
Closed by Close session element (セッションがClose session (セッションをクローズ) エレメントによってクローズ) | チャットボットセッションは、チャットボットの Close session (セッションをクローズ) エレメントによって終了しました。 | |
Chatbot deactivated (チャットボットが非アクティブ) | チャットボットは、エンドユーザーがチャットボットセッション中に非アクティブ化されました。 | |
Redirect to agent failed (エージェントへのリダイレクトに失敗) | チャットボットが会話をエージェントに転送できませんでした。 | Transfer chat to agent (エージェントへのチャットの転送) エレメントをこのブランチに追加して、エンドユーザーをエージェントにリダイレクトします。 |
Session ended by user (セッションがユーザーによって終了) | エンドユーザーがチャットボットセッションを終了しました。 |
アナリティクス
Start chatbot (チャットボットを開始) (Answers) エレメントの分析情報を表示するには、フローのエレメントにカーソルを合わせます。

Add to Flow (フローを追加)
Add to Flow (フローに追加) エレメントは、ユーザーを別の「セカンダリ」フローに送信する場合に使用します。これは、非常に複雑なフローを管理しやすくするために、より小さなフローに分割するのに役立つモジュラーフローの作成に使用する非常に強力なエレメントです。 詳細については、モジュラーフローのすべての利点やそれらを使用するタイミングなどを、いくつかの例を使って解説するドキュメントとして提供しているモジュラーフローの利点 セクションをご参照ください。
エレメントはフロー1つ当たり100個の制限があるため、フローにこの数を超えるエレメントがある場合、エレメントを追加することはできず、モジュラーフローを使用してフローを分割する必要が出てきます。
[Add to Flow (フローを追加)] エレメントは、フロー内のどのタイミングでも使用できます。exit (終了) エレメントの直前に [Add to Flow (フローを追加)] エレメントを使用すると、ユーザーは現在のフローを終了し、定義した別のフローに移動します。一方、フローの別のステップ (最後のステップ以外) にエレメントを追加した場合、ユーザーは両方のフローでそれぞれのフロージャーニーを続行することができます。
Add to Flow (フローを追加) エレメントを使用する前に、接続するすべてのフローが作成されていること、およびそれらのフローに適切な既存フローのエントリーポイント があることをご確認ください。その後、エレメントをフローに追加すると、使用可能なすべてのフローから選択できるようになります。

変数と変数値は、Add to Flow (フローを追加) エレメントを使用して、フローから選択したフローに移動することもできます。これにより、ユーザーがフロー間を移動する時に、対応するプレースホルダーのデータも確実に移動されます。
また、グッドプラクティスとして、[Add to Flow (フローを追加)] エレメントの「in all other cases (その他のすべての場合)」にフェイルオーバーのブランチを含めておくことをお勧めします。これにより、ユーザーをセカンダリフローに転送できない場合 (例えば、セカンダリフローがドラフトに設定されている場合やキャンセルされている場合) でも、ユーザーはジャーニーを続行できます。
セカンダリフローの参加者
デフォルトでは、[Add to Flow (フローを追加)] エレメントを通過するユーザーはすべて、セカンダリフローにも入るようになっています。ユーザーはフローを終了するまで、プライマリフローとセカンダリフローの両方に参加することになります。
また、連絡先情報に基づいて別のユーザーがフローを通過できるようにエレメントを構成することもできます。これを行うには、Add to Flow (フローを追加) エレメントを追加する時に、別の参加者を追加するように切り替えます。すると、この参加者に使用する主要な連絡先情報 (電話番号またはメール) でフロー変数、または現在フローに参加している人の標準/カスタム属性に一致するものを定義できるようになります。
参加者がPeopleにいる場合、連絡先情報によって識別されるユーザーに対してフローが開始され、フロー内で言及されている属性はすべて更新されます。ユーザーがPeopleにいない場合は、そのユーザーのプロファイルが作成され、属性値がプロファイルに割り当てられます。
セカンダリフロー参加者機能を使用する良い例としては、紹介プログラムがクライアントに友人や家族の連絡先情報を共有して特典を受けさせるユースケースがあります。例えば、メッセンジャーで友人のメールを共有するようにクライアントに依頼します。次に、インバウンドメッセージ からメールを解析し、値を変数 に保存します。
これにより、[Add to Flow (フローを追加)] エレメントを使用して、変数から抽出された連絡先情報とメールで、別のユーザーのフローを開始できるようになります。これはリーチを拡大するための優れた方法ですが、お住まいの地域のデータ要件を順守するため、対象の友人やご家族から必ずオプトインの承諾を得るようにしてください。

コールAPI
コールAPI を使用すると、フローと外部システム (ウェブサイトやCRMなど) とのリアルタイムの対話が可能になります。このエレメントを使用して、サードパーティのシステムまたはデータベースから情報をリクエストし、応答をフロー変数に保存します。その後、応答を使用してコミュニケーションをパーソナライズし、通信フローをルーティングできます。
エレメントのサイドパネルで、以下のフィールドの構成を完了します。
リスト変数は、Call API (コールAPI) エレメントでは使用できません。
リクエスト
以下のリクエストパラメーターの構成を完了します。
リクエストURL
フローが通信するサードパーティシステムのURLのことです。サードパーティーサービスが、フローが必要とするデータを受信または送信します。
予約済み文字、安全でない文字や非ASCII文字を含む属性がURLに含まれている場合は、Enable escaping of URL characters (URL文字のエスケープの有効化) を選択します。
Method (メソッド)
APIを呼び出すために使用されるメソッドのことです。各メソッドは、様々なユースケースに使用されます。
以下のいずれかのメソッドを選択します。
- POST:呼び出されるAPIは、提出されたリクエストを処理する必要があります。多くの場合、POSTは、サードパーティシステムで新しいエンティティを作成したり、既存のを更新したりするために使用されます。
- GET:サードパーティのシステムから情報を取得するために使用されます。
- PUT:サードパーティのシステムに情報を保存するために使用されます。
- DELETE:サードパーティシステムから情報を削除するために使用します。
- PATCH:サードパーティシステムの情報を部分的に変更するために使用されます。
Header (ヘッダー)
URLと共に送信する必要があるデータのヘッダーのことです。
データをキーと値の形式で入力します。
例:
ユーザー名:user1
パスワード:password123
デフォルトでは、ヘッダーは空です。但し、ほとんどのウェブフレームワークとサービスでは、リクエストを正しく処理するためにリクエストに content-type ヘッダーが必要です。そのため、ヘッダーを含めることをお勧めします。
例: JSON 形式でデータを送信する場合は、Key (キー) としてContent-type、Value (値) としてapplication/json を含むヘッダーを追加します。
Body (本文)
URLと共に送信する必要があるデータの本文のことです。
データは、次のいずれかの形式で入力できます。
-
Key-Value format (キーと値の形式):例 - 名前:Tom、または外部ユーザーID
-
JSON format (JSON 形式):例 - {'name': 'Tom'} この形式は、次の型をサポートしています。
- JSON:デフォルトでは、データはJSONとして送信されます。
- URL encoded form (URLエンコード形式):この形式でデータを送信するには、Key (キー) としてContent-type を、Value (値) として application/x-www-form-urlencoded を含むヘッダーを追加します。
各APIコールの認証
各コールを認証するには、次の操作を行います。
- Header (ヘッダー) に、ユーザー名とパスワードを入力します。
- Body (本文) で、API コールに含める各エンドユーザープロファイルの外部IDを渡します。これにより、サードパーティシステムは、どのエンドユーザーのデータを保存またはフェッチする必要があるかを知ることができます。エンドユーザープロファイルの外部IDは、Peopleに格納されます。
Response (応答)
次の応答パラメーターの構成を完了します。
Wait until response is received (応答が受信されるまで待機)
フローの次のステップを応答の受信後にのみアクティブにする場合は、このオプションを有効にします。
他の応答パラメーターを構成する時も、このフィールドを有効にする必要があります。
Response header variable (応答ヘッダー変数)
サーバーが、ステータス行に配置できない応答に関する追加情報を渡すことができるようにします。ヘッダーのフィールドでは、サーバーに関する情報やRequest-URI によって識別されたリソースへの更なるアクセスに関する情報が提供されます。

Response body variable (応答本文変数)
外部システムから受信したAPIデータをフロー変数に保存しておくと、そのデータをフローの残りの部分で使用できるようになります。
フロー変数への保存は、次のいずれかの方法で行うことができます。
- JSONパス
- 応答の本文全体を保存する
JSONパスを保存する
データを変数に保存するには、次の操作を行います:
- Body response (本文応答) フィールドで、JSONパス を選択します。
- データを変数に保存するには、_$. loyalty_points_などのJSONパス式を入力します。パスは1つの値を指す必要があります。値が配列またはオブジェクトの場合、エラーと見なされ、変数は NULL に設定されます。
- Variable (変数) フィールドで、フロー変数を選択します。

応答の本文全体を保存する
本文全体を保存できるのは、テキスト または ファイル 型のフロー変数のみです。
- Body response (本文応答) フィールドで、Whole body (本文全体) を選択します。
- Variable (変数) フィールドで、フロー変数を選択します。
- フロー変数が File (ファイル) 型の場合は、Fine name (ファイル名) とその拡張子を追加します。

ステータスコードの処理方法
応答が受信されたかどうか、または応答のステータスコードに基づいてフローを分岐できます。必要なステータスコードを選択します。ステータスコードごとに、コールAPIエレメントにブランチが追加されます。各ブランチに対して実行するアクションを指定します。
応答ステータスコードには、次の種類があります。
- On success (成功時) - 終了:2XXエラーの場合。アクションは必要ありません。
- On error (エラー時) - 終了: エラーが発生した場合。
- All client error codes (全クライアントのエラーコード) - 終了: 4XXエラーの場合。
- Server error codes (サーバーのエラーコード) - 終了:5XXエラーの場合。

スケジュール設定
スケジュール設定オプションは、データ交換の合理化に役立ちます。スケジュール設定を開始するには、Scheduling (スケジュール設定) タブで以下の機能を1つ以上有効にします。
Delivery time window (配信時間枠)
フローがサードパーティシステムと通信する期間を設定します。
詳細については、配信時間枠 について詳述しているドキュメントをご参照ください。
Define message sending speed (メッセージ送信速度の定義)
特定の期間内に配信したいメッセージの数を指定します。
詳細については、メッセージ送信速度 について詳述しているドキュメントをご参照ください。
Exchange用のカスタムエレメント
Exchange でカスタムエレメントを作成し、それらをフローに新しい機能として追加します。
例:カスタムエレメントを作成して、フローをサードパーティシステムと統合します。サードパーティのAPIを呼び出し、応答に基づいてフロージャーニーをパーソナライズします。
エレメントを一度構成すると、複数のコミュニケーションで再利用できます。
以下に、いくつかのユースケースの例を示します。
- フローをウェビナープラットフォームと統合して、エンドユーザーを会議に自動的に登録する場合。
- フローをGenAIプラットフォームに接続して、フロー内でパーソナライズされたコンテンツを生成する場合。
- フローをCRMに接続して、データを転送したり、特定のグループにプロファイルを追加したりする場合。
詳細については、NTT CPaaSと開発 と題したドキュメントをご参照ください。