開発プロジェクトなしで障害発生時に音声エージェントが話す内容を変更するには、まずメッセージ用のスロットをエージェントに一度だけ組み込みます。何か起きたときは、そのスロットの値を変更するだけです。これにより、更新はリリースではなく、ワンステップでロールバックできる設定変更になります。運用チームがこの変更をどれだけ速く安全に行えるかは、購入担当者の間で「コンテンツアジリティ」と呼ばれています。音声AIを評価する際には、必ず確認すべき項目です。
この記事では、自社側で発生する障害、ローンチ、サービス更新を扱います。Retellが自社プラットフォームをどのように稼働させ続けているかについては、Retellの障害対応と稼働率をご覧ください。
音声エージェントでは、なぜ障害時メッセージがより重要なのか？
音声エージェントは、誰かが変更するまで、現在の設定のまますべての電話に応答し続けるからです。人間のチームであれば、シフト開始時にブリーフィングを受けられます。一方、エージェントが受け取るのは、プロンプトとオープニングメッセージに書かれている内容だけです。
請求ポータルがダウンしたり、配送パートナーの配達が1日遅れたりしたとき、発信者が求めるのは次の3つです。企業が問題を把握していることの確認、今できること、そしていつ再確認すればよいかです。エージェントがこれらを伝えられなければ、発信者は一人ひとり最初から問題を説明し、担当者につなぐよう求めます。その結果、守りたかったはずのキューの負荷がかえって増えてしまいます。
リリースなしでチームが変更できるべきものは？
ほとんどのインシデントやローンチは、次の4つでカバーできます。
- オープニングメッセージ：発信者が何かを説明する前に、お知らせを聞けるようにします。
- 通話中にエージェントが説明できるお知らせ：「もう直りましたか？」という質問に、一貫して答えられるようにします。
- 転送先：エスカレーションをオーバーフローチームに回せるようにします。
- 参照情報：新プランの詳細や祝日の営業時間など、ローンチやポリシー変更に関する情報です。
Retellでは、動的変数をこれらすべての場所で使用できます。具体的には、オープニングメッセージ、エージェントのプロンプト、Conversation Flowの固定文、転送先番号、SMSテキストです。これにより、リリース不要の変更が可能になります。
1回の変更でお知らせをオンにできるよう、エージェントをどう設定するか？
必要になる前に、次の設定を一度だけ行っておきます。
お知らせ用の変数を追加する。カスタムウェルカムメッセージに{{service_notice}}を入れます。例：「お電話ありがとうございます。{{service_notice}}本日はどのようなご用件でしょうか？」プロンプトにも対応する一文を追加します。例：「現在のサービスに関するお知らせ：{{service_notice}}。空でない場合は、冒頭付近で一度だけ伝え、質問にはこのテキストのみを使って回答してください。」
空のデフォルト値を設定する。Retellでは、値のない変数は{{service_notice}}というテキストのままメッセージ内に残ります。一方、空文字列を設定すると何も表示されません。Security & fallback settingsでエージェントレベルのデフォルト値を""に設定しておけば、通常の日はエージェントが普段どおりに話します。
本番の電話番号をprodタグに向ける。Retellの環境タグは、エージェントのバージョンを指す名前です。タグに割り当てられた電話番号は、そのタグに追従します。バージョンに直接割り当てられた番号はそのバージョンに固定されたままなので、今のうちにすべての本番番号を確認してください。
お知らせの経路をテストする。Retellのシミュレーションテストケースでは、動的変数をあらかじめ設定できます。サンプルのお知らせを入れたテストケースを1つ用意しておきます。エージェントがそれを読み上げ、そのうえで通話を最後まで完了できることを確認してください。
障害発生時にメッセージをオンにするには？
お知らせは、エージェントではなくタグに設定します。エージェントのヘッダーでEnvironmentを開き、Configure Tagsを選択します。次にprodを選び、service_noticeに承認済みのテキストを設定します。Retellは、通話がタグを使用する際にタグの値を適用します。タグの値は、エージェントのデフォルト値より優先されます。障害時にこの方法に頼る前に、テスト通話を行い、次の通話で新しい値が反映されることを確認してください。
同じ方法でルーティングも制御できます。転送先を変数にしておけば、タグで値を設定してエスカレーションをオーバーフロー回線に送り、終了後に元に戻せます。
すでに進行中の通話については、開発者がRetellのUpdate Live Call APIを使用できます。このAPIは進行中の通話の動的変数を上書きし、変更は即座に反映されます。
ロールバックするには、タグの値をクリアします。次の通話から、空のエージェントデフォルト値が再び適用されます。
新しいバージョンとして変更すべきなのはどんなときか？
言葉だけでなく、動作を変更する場合です。新しい質問、新しいツール、異なる通話経路を追加する製品ローンチは、バージョン変更にあたります。
Retellでの手順は次のとおりです。
prodが指しているバージョンからドラフトを作成します。ドラフトは編集可能なコピーで、元のバージョンには影響しません。- ドラフトを編集し、テスト通話またはシミュレーションテストケースでテストします。
- 公開ダイアログからバージョン比較を開きます。セマンティック差分には、変更されたすべてのフィールドが一覧表示されます。長いテキストでは、追加・削除された語句が正確にハイライトされます。
- 公開すると、そのバージョンは読み取り専用になります。その後、
prodタグをそのバージョンに移動します。
ロールバックするには、prodを以前のバージョンに戻します。タグに割り当てられた番号も、それに追従します。
自社システムからメッセージを自動でトリガーできるか？
はい、一度構築すれば可能です。Retellのインバウンドコールwebhookは電話番号ごとに設定し、着信時に指定したendpointを呼び出します。レスポンスでは、動的変数を設定したり、オープニングメッセージやリンクされたナレッジベースを上書きしたりできます。これらはその通話にのみ適用され、上書き内容は保存済みのエージェントには残りません。
つまり、自社のステータス管理ツールにあるインシデントフラグで、発信者が聞く内容を決められます。インシデント中にダッシュボードを編集する必要はありません。ただし、番号にはデフォルトのインバウンドエージェントを設定しておきましょう。endpointが3回の試行すべてに失敗した場合、Retellはそのエージェントに通話を接続しようとします。設定がなければ、通話は切断されます。
ナレッジベースはどこで役立つか？
ナレッジベースは、ライブのインシデント状況ではなく、ローンチやサービス更新の詳細に使用します。プランの詳細や影響を受ける地域の一覧など、エージェントが参照する事実情報に適しています。なお、Retellのドキュメントでは、指示はナレッジベースではなくプロンプトに記載することを推奨しています。
注意点が2つあります。まず、URLおよび同期ドキュメントのソースは24時間ごとに自動更新されます。そのため、1時間ごとに変わる状況の反映には遅すぎます。次に、ナレッジベースは独立したオブジェクトとしてエージェントにリンクされています。一時的なお知らせを追加する前に、どのエージェントがそのナレッジベースを使用しているか確認してください。構成方法については、音声AIのナレッジベースの構成方法をご覧ください。
優れた障害時メッセージのプレイブックとは？
インシデント発生前に以下のメッセージを作成・承認しておき、当日は括弧内を埋めるだけにします。
| トリガー | エージェントが話す内容 | 承認者 | ロールバック方法 |
|---|
| 顧客向けシステムの障害が確認された場合 | 「現在、[システム]がご利用いただけないことを把握しております。ご報告いただく必要はありません。[発信者が代わりにできること]。」 | インシデントリーダー（文言はCXリーダーが承認） | prodタグのservice_noticeをクリア |
| サービス低下（遅延、一部障害） | 「本日、一部の[機能]のリクエストで通常より時間がかかっています。お急ぎの場合は[対応]いたします。」 | CXリーダー | prodタグのservice_noticeをクリア |
| 計画メンテナンスの時間帯 | 「[システム]は[タイムゾーン]の[開始]から[終了]までご利用いただけません。」 | 運用リーダー（事前にスケジュール） | メンテナンス終了時にタグの値をクリア |
| 人によるオーバーフロー対応が必要な急増時 | 通常のあいさつ。エスカレーションはオーバーフロー回線へ | ワークフォースマネージャーまたはキューマネージャー | タグの転送変数をリセット |
| 製品ローンチまたはポリシー変更 | 更新されたナレッジベースの内容に基づく新しいスクリプトと質問 | プロダクトオーナー（開示事項に関わる変更はコンプライアンス部門も承認） | prodを以前のバージョンに戻す |
| 自社のインシデントフラグによるインバウンドのお知らせ | webhookから設定する通話ごとのオープニングメッセージまたは変数 | ルールで自動設定（ルール自体を一度承認） | 自社システムでインシデントフラグをオフにする |
各お知らせは、1〜2文の短い文にまとめます。何が影響を受けているか、発信者に何ができるかを伝えてください。復旧時刻は、エンジニアリングチームが確認した場合にのみ伝えます。
誰に変更を許可すべきか、また成功したかをどう確認するか？
編集権限はロールで制限します。Retellのアクセス制御では、AdminロールとDeveloperロールはエージェントとナレッジベースを編集でき、Memberロールは読み取り専用です。Retellのドキュメントには、製品内の承認ステップについての記載はありません。そのため、上の表のように、各トリガーの承認者をインシデントランブックに明記してください。
次に、結果を確認します。Live Monitoringを使えば、スーパーバイザーが進行中の通話を聞けるため、最初の数人の発信者にお知らせが届いているか確認できます。Retellのアラートルールでは、成功率の低下やAPIエラーの増加時に、メール送信やwebhookの呼び出しを行えます。これはインシデントの検知と復旧の確認の両方に役立ちます。インシデントレビューに向けて、お知らせを音声エージェントのQAスコアカードに追加しましょう。
コンテンツアジリティについて、音声AIベンダーに何を確認すべきか？
説明を聞くだけでなく、以下の各項目を実際に見せてもらいましょう。
- エンジニア以外の担当者が、リリースなしでオープニングメッセージと通話中のお知らせを変更できるか？
- 本番番号がポインターに追従し、公開とロールバックをそれぞれワンステップで行えるか？
- 発信者に届く前に、保存済みのシナリオで変更をテストできるか？
- バージョン間の変更内容を、単語レベルの差分で確認できるか？
- 自社システムがインシデントフラグに基づいて、通話ごとにメッセージを設定できるか？
- すでに進行中の通話を更新できるか？
- どのロールが編集でき、どのロールが読み取り専用か？
そのうえで、パイロット期間中にこの一連の作業の所要時間を自分たちで計測してください。その他のテスト項目については、本番稼働前に音声エージェントプラットフォームを評価する方法のガイドで解説しています。
Retellは、バージョン管理されたエージェント、環境タグ、タグごとの変数、通話ごとの上書き機能をコンタクトセンターチームに提供します。これにより、キューを運用する担当者が、発信者に聞こえる内容を変更し、ワンステップで元に戻すことができます。自社の業務にどのように適合するかは、Retellエンタープライズプラットフォームのページでご確認ください。
