コールセンターAIのUAT 更新前に現場が確かめる4つの項目
スタンフォード大学などの研究者がHarvard Data Science Reviewに発表した論文は、2023年3月版と6月版のGPT-4に同じ問題を解かせ、素数か合成数かを見分ける課題の正答率が84%から51%に下がったと報告している。利用者が何も変えていなくても、提供側の更新でAIのふるまいは変わりうるということだ。コンタクトセンター（コールセンター）では、これに自社側の変更が重なる。プロンプトの修正、ナレッジの差し替え、ボイスボットの意図（インテント）の追加、フローの分岐変更である。では、改修したAIを本番に戻してよいと、誰がどの条件で決めているだろうか。
本稿の立場を先に書く。初期導入の可否を決める試験はPoCの評価項目の記事で扱った。本稿が扱うのは、すでに稼働しているAIに変更を入れるときの受入テスト（UAT）である。米国国立標準技術研究所（NIST）のAIリスクマネジメントフレームワークは、MANAGE 4.1で、利用者などからの意見の収集、異議申立てと上書き、廃止、インシデント対応、復旧、変更管理を含む導入後の監視計画が実施されていることを求めている。つまり変更管理は導入後の運用に組み込む前提で書かれている。以下の4項目は、その運用を現場の言葉に置き換えた編集部（相原ことは）の提案である。手順・権限は自社の変更管理規程と照合して決めてほしい。
UATという言葉も確認しておく。ユーザー受入テストの略で、実際に使う人がそのシステムを受け入れられるかを確かめる試験を指す。ソフトウェアテストの国際資格団体ISTQBは受入テストの資格を設け、UATを契約上・規制上の受入テストやアルファテスト、ベータテストと並ぶ対象として扱っている。改装した店舗を、開店前に店長が客の動線どおりに歩いて確かめる作業にたとえられる。設計者の確認とは別に、使う側の目で通すところに意味がある。
変更点と影響用件を一覧化する
1つ目の項目は、今回の変更で何が変わり、どの用件に響くかを1枚にすることだ。AIの変更は見た目より影響範囲が広い。たとえば住所変更の案内文を直すつもりでナレッジを差し替えると、同じ文書を参照していた請求や解約の回答まで変わることがある。
編集部の提案は、変更ごとに「変更の種類（プロンプト／ナレッジ／モデル／フロー／連携先）」「直接の対象用件」「同じ部品を使う周辺用件」「顧客に見える変化の有無」の4列を埋めることである。部品を共有している範囲が分かれば、試験の範囲も決まる。Amazon Connectのフローのベストプラクティスは、フローをできるだけ小さく作り、小さな部品を組み合わせて全体を構成すれば、管理しやすくなり回帰試験の回数を減らせると説明している。回帰試験とは、直した箇所以外が壊れていないかを確かめ直すことで、配線工事の後に関係ない部屋の照明まで点けて回る作業に近い。部品が小さいほど、点けて回る部屋は少なくて済む。
モデルの更新を提供側が行う場合も、この一覧に載せる。先の論文が示したのは、名前が同じモデルでも時期によって結果が変わりうるという事実である。もっとも、その数字は数学の課題での測定であり、自社の問い合わせ応対で同じ幅の変化が起きると読むのは単純比較にすぎる。言えるのは、提供側の更新も自社の変更と同じく受入の対象になる、という点までである。
現場の受入ケースを選ぶ
2つ目の項目は、受入で通す問い合わせを現場が選ぶことだ。開発側の試験は仕様どおりに動くかを見るが、UATは現場が受け入れられるかを見る。選ぶ人が違えば、通すケースも変わる。
製品側には、同じ問いを繰り返し流す仕組みがある。Amazon Lexのテストワークベンチは、テストセットを作って実行し、新しい用件の追加や更新に合わせてボットの性能を測る機能として説明されている。過去の会話ログからテストセットを生成でき、意図の認識や項目の聞き取り（スロット）の結果を集計できる。先に挙げたフローのベストプラクティスも、繰り返し通る経路と回帰試験にはフローのロジックテストを使うよう勧めている。
編集部の提案は、受入ケースを3つの箱に分けて現場のSVが選ぶことである。第一に、件数の多い定番の用件。第二に、過去に誤案内やクレームにつながった用件。第三に、今回の変更で直したかった用件そのもの。RAG（社内文書を検索して答える仕組み）を使う応答なら、検索された文書が正しいかの確認もこの一部として入れる。ただし、テストセットの合格率だけで受け入れを決めない。数字で通っても、言い回しが自社の案内として不適切な場合はある。最後はSVが応答を読み、受け入れられるかを判断する。
未解決の不具合を判断する
3つ目の項目は、受入で見つかった不具合のうち、直さないまま出すものをどう決めるかである。すべてを直してから出すのが理想だが、期日のある変更ではそうもいかない。
NISTのフレームワークは、MANAGE 1.1で、AIシステムが意図した目的と目標を達成しているか、開発や導入を進めるべきかの判断が下されることを求めている。判断を下すこと自体が管理の一工程として置かれている。
編集部の提案は、未解決の不具合を次の3区分に分けて記録することだ。第一に、出荷を止める不具合。誤った金額や期限の案内、本人確認の省略、人への引き継ぎができない経路などである。第二に、回避策を付けて出す不具合。言い回しの不自然さや、特定の聞き方で意図を取り違えるが、人に回れば対応できるものが当てはまる。第三に、次回の変更に回す不具合。区分を決めるのは開発側ではなく業務責任者とし、回避策を付けた不具合は、誰がいつ再確認するかまで書く。どの不具合をどの区分に置くかは、業種や規制によって変わる。ここに挙げた例は一般的な目安であり、自社の業務ルールと照合して決める。
承認と切戻し条件を残す
4つ目の項目は、本番へ出す承認と、戻す条件を出す前に書いておくことだ。切戻しの条件を出した後に考え始めると、判断が遅れる。
製品側には戻すための部品がある。Amazon Lexのバージョンとエイリアスでは、バージョンは作業内容に番号を付けた写しで、エイリアスは特定のバージョンを指す名札である。本番用・開発用・テスト用のように名札を分ければ、本番の通話を新しい版に向ける前に別の版で試せる。同じ文書は、下書き版を指すテスト用エイリアスは手動テスト専用であり、下書きは更新されうるため本番に使わず、版を公開してエイリアス経由で使うよう求めている。停止から再開までの訓練手順はAI停止訓練の記事で扱ったので、本稿では承認の記録に絞る。
編集部の提案は、変更ごとに次の5点を1枚に残すことである。承認者と承認日時、受入ケースの結果と未解決の不具合の区分、本番へ出した版、戻す先の版、切戻しを判断する条件と判断者である。切戻しの条件は「人への転送率が通常の範囲を超えた」「出荷を止める区分の不具合が本番で1件でも見つかった」のように、当番が数字や事実で判定できる書き方にする。具体的な数値の範囲は自社の過去の実績から決める。
ここからは私の見立てとして書く。AIを入れたセンターでは、導入時のPoCには時間をかけても、その後の小さな変更は担当者の判断でそのまま本番に出されていることが多いのではないか。AIの変更は1回ごとの影響が小さく見えるため、受入の手続きが省かれやすい。しかし変更が積み重なると、導入時に確かめた状態からは遠ざかっていく。
ただし、この見立てには反論もありうる。毎週のようにナレッジを差し替えるセンターで、変更のたびに現場のSVを受入に呼ぶのは重すぎる、という指摘だ。これはもっともで、すべての変更に同じ手続きを求めるつもりはない。それでも、次の3条件のどれかに当てはまる変更には、本稿の4項目を通す価値があると考える。第一に、顧客に直接答える応答の内容や経路が変わること。第二に、金額・期限・本人確認など、誤れば取り返しにくい用件に触れること。第三に、提供側のモデル更新のように、自社で中身を確かめられない変更であること。
まとめ
第一に、稼働中のAIの変更は、プロンプト、ナレッジ、モデル、フロー、連携先のどれでも起こり、影響は直した用件の外にも及ぶ。まず影響用件を一覧にする。第二に、受入ケースは現場が選び、テストセットの合格率だけでなくSVの判断で受け入れを決める。第三に、未解決の不具合の区分と、承認者・戻す先の版・切戻し条件を、出す前に1枚に残す。いずれも編集部の提案であり、効果を約束するものではない。
あなたのセンターで、先月AIに入った変更を本番に出してよいと判断したのは誰で、その判断はどこに残っているだろうか。
よくある質問
コールセンターAIのUATとPoCは何が違いますか
PoCは、導入するかどうかを決めるための初期の試験です。UATは、稼働中のAIに変更を入れるとき、現場がその変更を受け入れられるかを確かめる試験です。本稿では後者を扱い、変更点の一覧化、受入ケースの選定、未解決の不具合の判断、承認と切戻し条件の記録の4項目を編集部案として示しました。
ナレッジを1件直しただけでもUATは必要ですか
すべての変更に同じ手続きは要らないと考えます。顧客への応答内容が変わる、金額や本人確認に触れる、自社で中身を確かめられない変更である、のいずれかに当てはまる場合に4項目を通すのが、編集部の目安です。
受入ケースは何件用意すればよいですか
一律の件数は示していません。件数の多い定番の用件、過去に誤案内につながった用件、今回直したかった用件の3つの箱から、現場のSVが選ぶことを提案しています。件数は自社の用件数と変更の範囲から決めてください。
AIベンダーがモデルを更新した場合も受入の対象ですか
対象にすることを勧めます。同じ名前のモデルでも時期によって結果が変わりうることは、研究でも報告されています。更新の予定を事前に把握できるかどうかは契約や製品によって異なるため、提供側に確認してください。
注記
本稿の事実確認日は2026年10月1日。製品の機能仕様は、確認時点のAmazon Connect管理者ガイドとAmazon Lex V2開発者ガイドに基づく。仕様は更新されることがあるため、設定の際は最新の公式文書を確認されたい。論文の正答率は数学の課題での測定値であり、コールセンターの応対品質の変化を示すものではない。本文の4項目、変更一覧の4列、受入ケースの3つの箱、不具合の3区分、記録の5点、3条件はいずれも編集部の実務設計案であり、特定の製品や手法の推奨、実証された成果ではない。取材対象者の発言ではない。本稿はAI著者（相原ことは）によるデスクリサーチであり、個人の見解を含む。
AIを業務につなぐ前提を読むなら
改修したAIを本番に出せるかどうかは、公開前の検証をどこまで業務の文脈に沿って行えるかにも左右されます。株式会社miiboの功刀雅士氏・久野祐揮氏が、AIカスタマーサポートが初期構築・公開前検証・精度向上・データ連携の4つの壁で止まる理由を語った取材を、無料会員向けに公開しています。本稿の4項目は編集部の提案であり、同記事の発言ではありません。
【コールセンターは「コンテキストセンター」になる】AIカスタマーサポートを阻む“4つの壁”の超え方（会員限定）
出典
Amazon Lex V2 開発者ガイド「Evaluating Lex V2 bot performance with the Test Workbench」
Amazon Lex V2 開発者ガイド「Versioning and aliases with your Lex V2 bot」
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
