滑らかなAI返信にも、文ごとのサポート品質チェックが必要

「全額返金を承認しました」という丁寧な返信でも、承認の事実がなければ送れません。感じのよさだけでは、顧客の質問に答えているかも分かりません。サポート責任者には、直すべき文と理由が必要です。

Agentは欠陥表と修正版を作成し、人が送信の判断を残します。

根拠が固定された架空のケース

これは実際の顧客対応ではなく訓練例です。Q1は注文DEMO-17について、荷物の場所、返金の可否、次の手順を質問しています。注文記録O3は「輸送中、配送会社のスキャン欠落、到着日不明」。承認済み方針P4第2節は、欠落を調査できるが返金は担当者の審査が必要と定めます。第3節で必要なのは注文IDと登録済み連絡先で、カード番号全桁ではありません。

方針同士に矛盾はありません。競合するサポート資料の選択とは別の作業です。

悪い草稿D1：「明日届きます。全額返金を承認しました。カード番号を全桁お送りいただければ、すべて対応します。」

顧客の三つの質問を先に列挙し、各文を事実、約束、提案、不明に分けます。

重大な問題を平均化しない

これはチーム向けの提案基準です。「送信不可」は人が承認しない運用判断で、Budaの組み込み強制ゲートを意味しません。文ID、原文、引用箇所、欠陥分類、重大度、修正案を出力させます。丁寧な挨拶で架空の返金承認を相殺してはいけません。

重大項目を直した後で、場所、返金条件、次手順の回答漏れを確認します。その後に語調を整えます。ブランド文体のフィードバックは事実の確認を代替しません。

修正版と未決事項を一緒に出す

修正版D2：「注文記録では輸送中ですが、最新の配送スキャンが欠けており、到着日はまだ確認できません。この状態で返金が自動的に認められるわけではなく、サポートによる審査が必要です。登録済みの連絡先を通じて注文IDを確認してください。スキャン欠落の調査に使用します。カード番号全桁は送らないでください。」

到着日、返金判断、調査結果は未決です。調査を提案しただけでチケット作成済みや返金実行済みとは書けません。実行証拠または権限ある担当者の確認が必要です。確定した期限がなければ「24時間以内」も追加しません。

草稿と資料の版を対応させる

Q1、D2、O3、P4、レビューR2を一覧に残します。方針変更時には影響する文と全重大項目を再確認し、古い承認の根拠だけを黙って入れ替えません。

別のSessionでも同じ版を渡して再確認できます。ただし同じAgentのSessionはDriveを共有し、権限隔離ではありません。二度目のAIも誤るため、人が引用を確かめます。

Budaのサポート業務で、匿名化ケース、基準、承認例をDriveに保存します。ファイル編集はモデル学習でも次回返信の自動承認でもありません。Buda AIのMarketplaceでSkillを検索・インストールする際は説明と権限を読み、適切なものがなければ限定的なQA手順を作ります。特定の既製Skillがあるとは仮定しません。

誤約束、回答漏れ、機微情報要求、根拠のそろった正解の四例で試す方法を提案します。重大項目を見つけ、正解に新事実を足さないことを確認します。実施済み試験や改善率ではありません。

実務上の疑問

資料がない文は？

未検証とし、必要な資料と担当確認を求めます。ありそうな方針で埋めません。

レビュー担当の判断が違う場合は？

原文と双方の解釈を残し、責任者が適用範囲を決定します。基準を版管理して影響する例を再確認します。

合格なら自動送信してよい？

この手順は送信を許可しません。人が修正版、未決事項、宛先の文脈を確認します。送信連携には別の権限設計が必要です。

まず匿名化した一件で質問一覧、欠陥表、修正版、未決一覧を作り、人が確認してからキューへ広げます。