答えることと顧客の状態を変えること

公開ヘルプの説明と、ある注文の返金を確定することでは、顧客への影響が異なります。「対象になり得る」「審査を依頼した」「承認された」「処理された」はそれぞれ別の状態です。表示する前に、案件管理や決済システムで根拠を確認します。OWASPのAI Agent Security Cheat Sheet[1]は参照と変更の権限や、影響の大きい処理の直前承認を扱っています。

利用者が何をできれば完了かを考えます。利用方法の質問なら実際に機能を使えることが目的です。接続障害を担当者に相談したい場合は、同じ説明を最初からやり直さずに進めます。金銭に関わる依頼には確認済みの処理状態が必要です。Google PAIRのユーザーニーズと成功条件[2]は、成功の定義と担当者を支援する範囲の参考になります。

相談の種類別に案内・承認・引き継ぎを決める

表はオンラインサービスの例です。適用方針の責任者と、正しい状態を確認するシステムを種類ごとに追加します。顧客認証に成功しても、注文状態や権限によって許可できる操作は異なります。

相談の種類AIに任せる範囲承認・引き継ぎの条件証拠
公開ヘルプ・障害案内承認済みの文書や現在の状態を案内根拠がないか矛盾すれば担当へ文書版、取得時刻、表示内容
認証した顧客の注文照会本人の注文に必要な項目を参照所有権を確認できなければ認証へ誘導顧客と注文の確認、参照項目、結果
一般方針に沿った返金の検討適用条項と不足資料の候補を提示権限のある担当やシステムで注文・方針・残高確認注文状態、適用版、計算根拠、未確認項目
例外返金・補償受付、事実、選択肢を整理裁量、事故、複合要因は指定承認者へ例外の根拠、判断権限、要望、証拠
返金やクーポン発行承認された同一処理を限定実行期限切れ、状態不明、重複、実行値変更は保留承認値、取引・作業ID、処理結果
再問い合わせ・有人対応希望既存案件を探して要点を引き継ぐキューがない、または引受不能なら別経路へ既存案件との関連、受付、引受、次の確認時刻

公開案内では認証不要の情報を使います。地域障害を聞かれて顧客の支払い履歴を取る必要はありません。注文の照会はサーバーで所有権を確認し、必要な項目だけを渡します。チャットで名乗るだけでは本人確認になりません。住所や支払い方法の不要な表示も試験します。

方針に基づく提案には、有効な注文状態と方針の版が必要です。購入時の条件、現在の例外、販売経路、地域条件の優先順位を業務責任者が決めます。競合を解消できなければ担当者に渡し、金額は決済システムが示す残高と照合します。一部取消と返金額の整合性を参照できます。

サービスの仕組み

取引異常から対応・決済事業者との協議へ — 症状別の確認手順で取引状態を調べ、障害、返金、繰り返す問題を共通の運用手順で処理します。

架空の接続障害を受付からたどる

架空のオンライン接続サービスに「支払ったのに接続できない。返金してほしい」という相談が入ります。ヘルプには障害情報、一般的な接続手順、販売経路別の返金窓口があるとします。最初に顧客の状況を確認し、試した操作を繰り返させずに案内します。個別の確認が必要なら認証へ進みます。

認証後は注文の支払いと利用開始の状態を照会します。接続に失敗しても利用履歴が存在したり、照会システムが応答しなかったりします。見つからなかったことを「未使用」に置き換えず、「確認できなかった」と記録します。方針を適用する証拠が足りない場合は、収集済みの情報を案件に結びつけて引き継ぎます。

返金を送信しても決済サービスの応答が返らないことがあります。「返金依頼を受け付け、処理結果を確認中」と案内し、再送前に既存の取引IDで照合します。詳しくは決済と注文状態の整合性を参照できます。

例外補償では根拠と判断者を明らかにする

利用者の問題、適用可能な方針、以前の補償、同じ障害に影響を受けた注文を確認します。AIは根拠をまとめ、承認者が補償の種類、対象、条件、金額を確定できるようにします。方針に裁量がある場合は自動で補償を約束しません。認めない場合は次の案内を決め、まだ行っていない処置を完了として伝えません。

方針の解釈を担う原文と顧客への案内を結びつけます。翻訳で条件や期限を変えないようにします。受付時刻、対象地域、サポート時間も記録します。顧客の「昨日」と担当者の業務日が異なるため、日付で資格や応答予定が決まる場合はタイムゾーンを照合します。

担当者が続けられて初めて引き継ぎになる

「担当者につなぎます」と表示しても実際にキューへ届いたとは限りません。案件が作成されたことを確認してから受付IDを案内します。交代後は待機、引受、顧客応答待ち、最終対応、状態不明などを運用と画面で共通に扱います。Google PAIRのErrors + Graceful Failure[3]は、エラー後も利用者が進める経路を扱います。

引き継ぐ項目使用目的
案件IDと受付時刻再問い合わせを関連付け、変更順を確認
顧客の要望と認証状態必要な対応と追加の本人確認を判断
注文・取引の参照権限のある画面でIDと照会時刻を確認
方針と証拠適用版、注文状態、診断内容と結果
不明項目と実行中の処理利用記録の照会失敗、返金送信の有無など
顧客への案内と次の約束伝えた状態、次の窓口、確認できる時刻
キューと引受の記録担当・グループ、配分と引受の時刻、超過時の責任者

顧客が説明をやり直さずに済む資料を渡しつつ、支払い情報や無関係な顧客履歴の複製を避けます。判断に必要な事実を目立たせ、確認用の原文や根拠を参照できるようにします。希望言語や連絡方法を記録し、認証情報は管理された経路で扱います。

担当者が不在の場合は、実際の稼働時間と受付方法を伝えます。登録に失敗したら代替窓口を案内し、存在しない案件番号を出しません。同じ問い合わせは既存案件につなぎ、注文や問題が異なる場合は区別します。初回応答が速くなっても再問い合わせが増えたなら、もとの問題が解決したかを確認します。

顧客対応を検証するケースと分母

承認済みの試験アカウントと決済環境を使い、他人の注文照会、重複依頼、処理通知の欠落を再現します。回答の内容とシステム上の結果は両方確認します。Anthropicのエージェント評価資料[4]は対話の評価と実際の結果の検証を区別しています。

試験ケース期待結果
顧客が他人の注文IDを入力注文や顧客の情報を表示しない
利用履歴の照会に失敗確認不能を残し、未使用として扱わない
販売経路別の方針が異なり実際の経路も不明返金確定を保留し、資料確認や有人対応へ
返金送信後に応答が途切れる完了と表示せず既存取引を照会
相談キューが登録を拒否受付失敗と利用できる別経路を案内
交代後に担当が引き受ける同じ案件で証拠と顧客への案内を確認

初回応答率は受付のうち一度目の回答が届いた割合です。引受率は有人対応が必要な案件のうち、指定期間に引き受けられた割合です。解決率は業務結果が確認できた案件の割合を用います。仮に100件のうち90件で初回応答し、55件の解決が確認できたなら、それぞれ90%と55%です。顧客の返答待ちや決済結果の不明は別に残します。

範囲を広げる前に照会権限、方針の競合時の保留、最終状態、引受の正常性を確認します。金銭状態の誤変更や、担当者が案件を見つけられない場合は範囲を絞って該当経路を修正します。最初から人と話したい場合も確認します。