AI電話の設定変更履歴は、誰が管理画面を操作したかだけでは足りません。実際の通話で使われた設定の組み合わせを後から再現できる記録が必要です。対象は会話と参照知識に加え、転送・通知や外部連携まで含みます。

編集を始める前に変更IDを一つ発行します。変更理由と候補版を記録し、試験結果と承認も同じIDへ結び付けます。公開版と戻し先も同じ記録へ加えてください。まず、直近の変更一件について「その変更後に応答した版」を一意に答えられるか確認します。

編集前に一つの変更IDを発行する

変更履歴は、公開後に作る作業報告ではありません。会話文や転送条件を編集する前に変更IDを発行し、対象業務と変更理由を一文で残します。「応答を改善する」ではなく、「営業時間外の問い合わせを翌営業日の折り返し受付へ変える」のように終了状態まで書いてください。

同じ目的の変更を複数の依頼へ分けないことも重要です。会話設定を変えた結果、通知項目やCRMの結果区分も変わるなら、一つの変更IDへまとめます。別々に公開すると、どの組み合わせを試したのか分からなくなります。

NIST SP 800-53 Rev. 5のCM-3は、管理対象の変更を定め、セキュリティとプライバシーへの影響を考慮して承認する管理策です。判断の記録と承認済み変更の実施、記録の保持やレビューも含みます。ここでは運用設計の参考として使い、すべてのAI電話利用企業に一律の義務があるという意味では扱いません。

四つの設定を一つの変更範囲にまとめる

AI電話の応答は、会話文だけで決まりません。会話・プロンプトと参照知識を確認します。転送・通知とAPIやCRM連携も対象です。変更しない項目も「変更なし」と記録してください。

たとえば営業時間の知識を直しても、時間外の転送先が古いままなら業務は完了しません。CRMへ返す結果区分が変わる場合は、集計や担当者の次の行動にも影響します。通話の入口から終了後の記録までを一つの変更範囲として扱います。

外部連携の認証情報そのものは履歴へ貼りません。連携先、利用する権限、認証情報の識別名を残します。秘密値を複製せず、どの連携設定を使ったかだけを追える状態にします。

変更前後の設定を版として保存する

スクリーンショットだけでは、長い会話設定や分岐条件を復元できません。製品に版管理がある場合は変更前と候補版の識別子を残します。版管理がない場合は、エクスポートした設定と参照資料を変更IDの保管先へ保存してください。

Dialogflow CXのバージョンと環境では、フローと関連する意図・エンティティ・Webhookなどの設定を、変更できない版として保存できます。テスト環境と本番環境へ版を分けて展開でき、本番では下書きではなく版を使うことが推奨されています。ただし、外部Webhookのプログラムや参照先データまで同じ版で保存されるとは考えず、外部側の変更も対応付けます。

参照知識が別のファイルやWebページなら、その版も必要です。URLだけでは後から内容が変わるため、確認日時と文書の版を残します。会話設定と知識のどちらか片方だけを戻す状態は避けてください。

試験結果と承認を候補版へ結び付ける

試験記録には「確認済み」とだけ書かず、試験IDと期待結果を残します。正常な用件と聞き返しを候補版で試してください。有人切替と担当者不在、外部連携失敗も試し、実際の結果を記録します。

試験後に候補版を編集した場合は、同じ試験結果を流用できません。変更後の版を新しく保存し、影響する試験をやり直します。承認者は文章案だけでなく、公開する版の識別子と試験結果を確認します。

小さな変更にも同じ考え方を使います。ただし、誤字修正と転送条件の変更で承認者を同じ人数にする必要はありません。影響の大きさで確認者を変えられます。それでも変更IDと候補版の対応は省略せず、試験と承認も同じ記録へ残してください。

公開した版と最初の通話を記録する

Dialogflow CXでは通話などのセッションが続いている間の版変更でエラーが起きる可能性も案内されています。利用製品の切り替え条件に合わせ、停止時間や利用の少ない時間帯を選びます。

公開時には、予定していた候補版ではなく、実際に本番へ展開された版を記録します。公開日時と公開者を変更IDへ追加してください。本番環境と公開版も記録し、候補版と一致するか確認します。

公開直後は、対象業務の最初の通話を確認します。通話IDと使われた設定版を残してください。終了状態も記録すると、設定が実際の応答へ反映されたことを確認できます。通話が来ない場合は、本番環境を指定した合成テストで確認します。

同じ時間帯に別の変更を重ねると、結果が変わった理由を切り分けにくくなります。緊急でなければ、最初の通話を確認するまで次の変更を公開しません。複数変更を同時に出す場合は、一つの公開単位として試験してください。

戻し先を公開前に決めておく

戻し先は「変更前へ戻す」では不十分です。戻す会話版と参照知識を指定します。転送・通知と外部連携も同じ組み合わせで指定してください。戻した後に試す通話と、再開を判断する人も変更履歴へ残します。

Amazon Connect Customerのフロー版管理では、以前に公開した版を確認し、その版を再び本番へ公開できます。変更履歴は日時や利用者で絞り込めますが、タグベースのアクセス制御がある利用者は選択できる版に制限があります。実際に復旧を担う権限で試してください。製品に同様の機能がない場合は、保存した設定を読み戻せるか確認します。

緊急修正も履歴の対象です。事前承認を短縮した場合は、その理由と実施者を先に残します。公開版と直後の確認も記録し、事後レビューの期限を決めてください。履歴を後から整えるのではなく、緊急時に必要な項目だけでも変更IDへ記録します。

最初の作業は、直近に公開した変更を一件選ぶことです。候補版と承認した版が同じ変更IDから追えるか確認します。本番で動いた版と戻し先も追えなければ、次の変更を公開する前に記録方法を整えてください。