はじめに
音声認識やAIを活用したIVRは、最近では「導入するかどうか」ではなく、「どう活用するか」がテーマになってきています。
私が対応した案件でも、「プッシュ操作ではなく、顧客の発話内容をもとに処理を分岐させたい」という要望がありました。
ただ、従来のトーンプッシュ型IVRのように、あらかじめ決められたメニューを順番に辿る構成では、発話内容に応じて動的に変化する対話を実現するのは難しいケースがあります。顧客の発話によって次の処理が決まり、さらにその結果によって対話内容が変わる。
こうした“可変的な対話構造”を実現するために、今回採用したのが ループ型の制御アプローチです。
本記事で紹介するアプローチの概要
今回紹介する構成では、処理判定を中心に据え、対話と意図解釈の結果を再び判定ロジックへ戻す ループ型構造 を採用しています。
これにより、固定的なメニュー遷移ではなく、顧客の発話内容に応じて次の処理を柔軟に決めることができます。
下図は全体の処理イメージです。
対話処理と意図解釈を繰り返しながら処理判定へ戻ることで、継続的な対話を実現しています。
また、この構成では 「処理制御情報」 を管理しながら対話を進めます。
処理制御情報には、処理区分（QA／外線転送／内線転送／切断）と、それぞれの処理に必要なパラメータ（例：QAで顧客へ提示するプロンプトなど）を持たせています。意図解釈の結果はこの処理制御情報へ反映され、再び処理判定へ戻ることで対話が続いていきます。
ループ型対話フローの実装例
この構成では、図で示した ①〜⑤の処理を繰り返すことで対話を進めます。対話の進行状況は「処理制御情報」として管理し、その内容をもとに次に実行する処理を判定します。
- 初回QA作成
着信後、最初に顧客へ提示するQAを作成します。この段階で初期の処理制御情報を設定し、対話の開始状態を定義します。 - 処理判定
処理制御情報を参照し、次に実行する処理を判定します。処理区分に応じて
・QAを継続する
・外線転送
・内線転送
・切断
といった処理を決定します。この処理判定が対話制御の中心になります。 - QA（対話）
QA処理では、処理制御情報に基づいて顧客へプロンプトを提示し、発話を取得します。取得した音声は音声認識によってテキスト化され、顧客の発話内容として次の処理に渡されます。音声認識は
・Genesys Cloudの機能
・外部サービス
どちらを利用する構成にも対応できます。 - AIによる意図解釈
テキスト化された顧客の発話内容をもとに、AIによって顧客の意図を解釈します。この処理も外部サービスと連携することで柔軟に実装できます。 - 次処理決定
意図解釈の結果をもとに、次に実行する処理を決定します。ここで更新された処理制御情報は再び処理判定へ戻され、必要に応じて対話が継続されます。
このように、処理判定を中心に 対話処理と意図解釈をループさせることで、柔軟な対話制御を実現しています。
設計上の工夫
柔軟な対話制御を実現するため、いくつかの設計上の工夫を取り入れています。
ループ型構造による対話制御
継続的対話を実現する上で重要になるのが 対話処理をループさせる構造です。
従来のトーンプッシュ型IVRでは、あらかじめ決められたメニューを順に辿るフロー設計が一般的です。しかし、音声認識を用いた対話では、顧客の発話内容によって次の処理や対話内容が変わります。そのため、対話処理を一度のフローで完結させるのではなく、意図解釈の結果をもとに処理を決定し、再び処理判定へ戻るループ構造を採用しています。
処理判定を中心とした構造
処理判定を対話制御の中心に据えています。
すべての処理がこの判定処理へ戻る構造にすることで、処理の追加や変更を行う場合でもフロー全体への影響を最小限に抑えられます。例えば、新しい処理を追加する場合でも、処理判定に分岐を追加するだけで対応できます。
処理制御情報による状態管理
対話の進行状況は 処理制御情報 として管理しています。
処理区分や必要なパラメータをこの情報にまとめることで、対話の状態をフロー内で一元的に扱えるようにしています。例えば、QA処理では、顧客に提示するプロンプト内容をパラメータとして保持し、意図解釈の結果に応じて次に実行する処理区分を更新します。
これにより、対話の進行に応じて動的に処理を切り替えることが可能になります。
外部サービスとの連携を前提とした構成
音声認識や意図解釈は
・Genesys Cloudの機能
・外部サービス
どちらでも利用できる構成を想定しています。
そのため、これらの処理はフローの中核ロジックから分離し、外部サービスとして扱う構造にしています。
こうしておくことで、将来的にサービスを変更する場合でもフロー全体への影響を最小限に抑えることができます。
無限ループを防ぐための制御
ループ型構造を採用する場合、同じ対話を繰り返し続けてしまう可能性があります。
例えば、顧客の発話が意図解釈できない場合など、同じ質問を繰り返してしまうケースです。
そのため、本構成では対話の試行回数を管理し、一定回数を超えた場合には処理を切断またはオペレーター転送する仕組みを設けています。
このような制御を行うことで、対話が無限にループすることを防ぎつつ、顧客体験を損なわない運用が可能になります。
本アプローチのメリットと注意点
本記事で紹介した構成は、音声認識を用いた柔軟な対話制御を実現するための一つのアプローチです。ここでは、この構成を採用することで得られるメリットと、設計上注意すべき点について整理します。
メリット
柔軟な対話制御が可能
ループ型構造を採用することで、固定的なメニュー構造に依存しない対話設計が可能になります。顧客の発話内容や意図解釈の結果に応じて、動的に次の処理を決定することができます。
拡張性の高いフロー設計
処理判定を中心とした構造とすることで、新しい処理を追加する場合でも判定ロジックの分岐を追加することで対応できます。そのため、将来的な機能追加や要件変更にも柔軟に対応できます。
外部サービスとの連携が容易
音声認識や意図解釈は
・Genesys Cloudの機能
・外部サービス
どちらでも利用できる構成を想定しています。
そのため、これらの処理はフローの中核ロジックから分離し、外部サービスとして扱う構造にしています。
こうしておくことで、将来的にサービスを変更する場合でもフロー全体への影響を最小限に抑えることができます。
注意点
フロー構造が複雑になりやすい
ループ構造では分岐や状態管理が増えるため、フロー設計が複雑になりやすい傾向があります。処理制御情報などを用いた整理された設計が重要になります。
ループ制御の設計が必要
対話処理が繰り返される構造のため、同じ対話を繰り返し続けないよう試行回数の制御などが必要になります。
Genesys Cloudの制約を考慮した設計
Genesys CloudのArchitectでは、フロー内で実行できるループ回数やアクション数に上限があります。長い対話が想定される場合は、一度フローを抜けて再度呼び出す構成などを検討する必要があります。
また、アクション数が多い場合、通話ログの一部が残らなくなるケースもあるため注意が必要です。
まとめ
この記事では、音声認識IVRにおいて継続的な対話を実現するための一つのアプローチとして、ループ型のフロー構成を紹介しました。
トーンプッシュ型IVRでは、あらかじめ決められたメニュー構造に沿って処理が進みます。そのため、顧客の発話内容によって動的に対話を変化させる設計には限界があります。今回紹介した構成では、処理制御情報をもとに処理を決定し、その結果を再び判定処理へ戻すループ構造を採用することで、柔軟な対話制御を実現しています。継続的対話の実現には、機能だけでなく フロー構造や状態管理の設計 が重要になります。
今回の内容が、音声認識IVRや対話型フローを設計する際の参考になれば幸いです。
