顧客対応に生成AIを使ってよいか｜社外に出る出力の線引き

顧客からの問い合わせに生成AIを使いたい、ただし誤った案内が信用問題になるのは避けたい。この二つの間で判断が止まっているなら、比べる対象は製品の精度ではありません。決まっていないのは、社外に出る出力の線引きです。

結論

顧客対応に生成AIを入れるとき最初に決めるのは、製品ではなく社外に出る出力の線引きです。判断の軸は一つに絞ります。誤った回答が顧客へ届いたとき、金銭と契約の面でどこまで取り返しがつくかです。調べ直せば戻せる問い合わせはAIに単独で答えさせ、戻すのに個別交渉や費用負担が伴うものは人の確認を挟み、支払額や契約条件を確定させるものはAIの出力を顧客へ直接届けません。

線引きが定まると、残る論点は4つです。人へ渡すトリガー、AI応対であることを顧客へ伝えるかの方針、誤回答が届いたときの訂正・記録・再発防止、限定範囲から広げる段階設計です。この4つを文書にすれば、次の会議にかけられる運用ルール案になります。ただし線引きの正解は商材と顧客層と失敗コストで変わるため、試験運用で実データを見ながら更新する前提で決めます。

社内向けのルールをそのまま顧客に向けられない理由

顧客対応と社内対応では、誤答が収束するまでのコストが釣り合いません。社内なら、誤った回答は担当者に聞き直せば終わります。記録も社内に留まります。顧客が相手だと、同じ誤りが相手の意思決定の材料になり、訂正は顧客が動いたあとになります。訂正には連絡と説明が伴い、案内した条件を履行するかどうかの判断まで求められます。内容によっては、費用負担の決裁へ上がります。

もう一つの違いは、AIの回答が誰の発言として扱われるかです。社内では「AIの回答は参考値」という但し書きが機能します。顧客が同じ但し書きを自社の説明と切り離して読むとは限りません。この点について、カナダのブリティッシュコロンビア州民事解決トリビューナルは、航空会社のチャットボットが誤った案内をした事案で次のように述べています。

チャットボットには対話機能がありますが、それでもエア・カナダのウェブサイトの一部にすぎません。ウェブサイト上のすべての情報について自社が責任を負うことは、エア・カナダにとって明白であるべきです。その情報が固定ページから提供されたか、チャットボットから提供されたかによって違いはありません。

出典: Moffatt v. Air Canada, 2024 BCCRT 149 (CanLII) https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html

同トリビューナルは、企業がチャットボット利用者に対して注意義務を負うとしたうえで、回答の正確性を確保する合理的な注意を払わなかったとして過失による不実表示を認め、差額相当の賠償を命じています。

これはカナダの機関による個別事案の判断です。日本の法令の解釈を示すものでも、自社の事案にそのまま当てはまるものでもありません。それでも、チャットボットの回答を自社の説明と切り離せるかという問いに、公的な紛争解決機関が向き合った記録ではあります。設計の前提を置くときの材料として読んでください。自社の契約条件や返金可否に関わる判断そのものは、弁護士等の確認が必要な領域として切り分けます。

技術面の制約も、相手が顧客だと意味が変わります。ヘルプ記事や社内文書を参照させる方式であっても、参照先に書かれていない事項や更新が追いついていない事項には正しく答えられず、回答の質は参照データの状態に左右されます。社内の質問者なら、足りない部分を自分で補って読み替えられます。顧客にその補正は期待できません。仕組みの精度が同じでも、補正してくれる読み手がいない分、誤りはそのまま社外へ出ます。

あわせて読みたい

社内問い合わせを生成AIで自動化する｜線引き基準と4段階の進め方

顧客からの問い合わせを3種類に仕分ける

仕分けの基準は、問い合わせの難易度でも件数でもありません。誤った回答が届いたときに、金銭と契約の面でどこまで取り返しがつくかです。この一点で並べ替えると、問い合わせは3種類に整理できます。

自社のログへ当てはめる手順は単純です。直近3か月の問い合わせを件数順に並べ、1件ずつ「誤ったまま伝わると顧客は何をしてしまうか」という一文を書いてください。答えが「調べ直す」なら事実照会、「準備・移動・購入する」なら条件判断、「支払う・契約する・請求する」なら金銭・契約に関わる回答です。分類名から入ると、判定は人によって割れます。顧客の次の行動から入れば、なぜその分類に置いたかが一文で残ります。

同じ質問文でも、分類は回答の内容で変わります。「返品できますか」は、受付期限の日数を案内するなら事実照会、この商品が対象かを判定するなら条件判断、返金額を確定させるなら金銭・契約に関わる回答です。分けるのは質問の文面ではなく、回答が確定させる内容だと考えてください。ここを取り違えると、事実照会のつもりで開けた入口から契約の話が入ってきます。

AI単独可・人の確認必須・AI不可を線引き表にする

3分類が決まると、対応レベルの既定値は次の形に定まります。商材名と担当部門名を自社のものへ置き換えれば、そのまま会議へ持ち込む線引き表になります。

ここでの「AI不可」は「AIを使わない」という意味ではありません。禁じるのは、AIの出力がそのまま顧客へ届く経路です。担当者が下書きを作らせる、過去の類似案件を要約させる、回答の抜け漏れを点検させるといった使い方は、経路が人を通るため線の内側に残ります。この区別を書き分けておかないと、現場は「金銭の話が出たらAIを閉じる」という運用に寄り、下書きや点検に使える場面まで一緒に失われます。

レベルは問い合わせ単位ではなく、回答単位で持ってください。1回の会話には複数の分類が混ざります。営業時間を聞いた顧客が、その流れで解約金を尋ねることは珍しくありません。混ざった場合は、その会話に含まれる最も厳しい分類へ合わせます。この原則を先に置いておけば、会話の途中でレベルの判断が割れません。

有人対応へ切り替えるトリガーを定義する

切り替えの条件を「AIが答えられないとき」とだけ書いた設計は動きません。生成AIは、誤っているときに止まってくれるとは限らず、参照元に記述がない事項でも自然な文章で答えを埋めてしまうことがあります。判断の材料が足りない状態を検知するのは、AI自身ではなく、あらかじめ決めた条件の側です。トリガーは次の3系統で書き分けてください。

1. 顧客の状態から引くトリガー。解約、返金、キャンセル、苦情、法的手段といった語が出た場合は、回答の正誤にかかわらず即時に人へ渡します。同じ質問を言い換えて2回繰り返した場合、事故・けが・健康被害・個人情報の取り扱いに関する申し出があった場合も同じ扱いです。「担当者と話したい」という要望は無条件かつ最優先で、他のどの条件よりも先に効かせます。
2. 回答の材料から引くトリガー。参照元に該当する記述がない、複数の記述が食い違っている、顧客固有の契約内容や購入履歴を見ないと答えられない、金額・期日・可否の確定を求められている、のいずれかに当たる場合です。この系統は、AIに答えを作らせないための条件だと考えてください。
3. やり取りの経過から引くトリガー。同一論点の往復が3回を超えた、会話開始から5分を超えた、という上限です。回数と時間は初期値であり、根拠のある正解値ではありません。試験運用のログを見て、解決している会話と解決していない会話の分岐点を探し、自社の値へ入れ替えます。

トリガーだけ定義しても、切り替えの瞬間に渡す情報を決めていなければ現場は止まります。顧客へ伝えるのは、担当者に代わること、いま把握している用件の要約、待ち時間または折り返しの時刻の3点です。担当者へ渡すのは、会話の全文、AIが提示した回答と参照元、切り替えの原因になったトリガー、顧客の契約や購入履歴の該当箇所の4点です。

失敗の典型は、切り替わった直後に顧客が最初から説明し直す状態です。これを一度経験すると、顧客にも担当者にも、AI導入は対応を遅くした施策として記憶されます。線引きの妥当性を確かめる前に社内の合意が崩れるため、引き継ぎ情報の受け渡しは切り替えトリガーとセットで試してください。

AIが応対していることを顧客に伝えるか

総務省・経済産業省のAI事業者ガイドラインは、AIを提供する事業者に期待される透明性の取組として、提供するサービスにAIを利用している事実と活用している範囲を関係者へ提供・説明することを挙げています。同ガイドラインは事業者の自主的な取組を支援する位置づけで、個別の告知義務を一律に課す法律ではありません。現行版は第1.2版で、2026年3月31日に公表されています。

告知しない選択も取り得ます。その場合に残るのは、次の3点です。

• 顧客が人と話しているつもりで、個人的な事情や機微な内容を書き込む可能性があります
• 誤回答が起きたとき、告知していなかったという事実そのものが二次的な不信の材料になります
• 顧客は、自分から有人対応を求める機会を会話の入口で失います

伝える場合は、次の3か所へ短い文言を置くと運用しやすくなります。文言の目的は免責ではなく、顧客がどの内容を人に確認してもらうべきか判断できるようにすることです。

• 会話の開始時に一度: 「このチャットはAIが自動で回答します。担当者の確認が必要な内容は、担当者へおつなぎします。」
• 一般的な案内にとどまる回答の末尾: 「一般的なご案内です。お客様のご契約内容に当てはまるかは、担当者が確認いたします。」
• 有人へ切り替える瞬間: 「ここから担当者が対応します。」

告知方針は線引き表と連動します。AI応対であることを開示していれば、一般的な案内であるという但し書きがそのまま読まれる余地が生まれ、事実照会の範囲は広めに取りやすくなります。開示しない前提で設計するなら、条件判断へ踏み込む余地はさらに狭めるのが筋の通った選択です。

誤回答が顧客に届いたときの回復手順

回復手順は、事故が起きてからでは作れません。誰が動くかを決めていない状態では、最初の数時間が「誰に報告すべきか」の確認に費やされます。担当と期限を先に埋めておきます。

1. 検知（担当: 一次対応者／目安: 気づいた時点で即時）。顧客の指摘、担当者の気づき、会話ログの点検のいずれかで拾います。誤りかどうかを自分で判断させず、「誤りかもしれない」の段階で運用責任者へ上げてよいと明文化してください。
2. 事実の固定（運用責任者／当日中）。いつ、どの質問に、どう答えたか。参照元には何と書かれていたか。同じ誤りが他の顧客へ何件届いたか。この時点で会話ログを保全します。
3. 一時停止の判断（運用責任者／事実の固定と同時）。同じ誤りが再現するなら、該当分類のAI回答を止めて有人受付へ寄せます。止める権限が特定の役職に割り当てられていないと、この判断は会議待ちになります。
4. 影響範囲の切り分け（運用責任者と所管部門／当日中）。顧客が誤情報にもとづいてまだ動いていなければ、訂正で収まります。すでに動いている場合は費用負担の判断が必要になるため、決裁権のある部門へ上げます。
5. 顧客への訂正（所管部門の担当者／原則として翌営業日まで）。誤った内容、正しい内容、AIの応対による回答であったこと、今後の扱いを伝えます。金銭や契約条件の解釈を含む訂正になる場合は、法務または顧問弁護士の確認を通してから発信します。
6. 記録（運用責任者／3営業日以内）。下記の項目を残します。
7. 線引きとナレッジの更新（運用責任者と所管部門／2週間以内）。分類の移動、参照元の修正、切り替えトリガーの追加まで行います。ここを飛ばすと、同じ誤りが同じ経路で戻ってきます。

記録に残す項目は、次の7つを型にしてください。

• 発生日時と検知の経路
• 顧客の質問文とAIの回答文
• 参照した情報源と、そこに実際に書かれていた内容
• 誤りの型（記載がない／情報が古い／解釈を誤った／そもそもAI不可の領域だった）
• 影響範囲（対象顧客数、顧客が行動済みかどうか）
• 実施した訂正の内容と費用負担の有無
• 変更した線引き・トリガー・参照元

試験運用から適用拡大までの段階設計

顧客接点へ出す前に、次の4点が揃っているかを確認します。どれか1つでも欠けたまま進めると、誤回答が起きたときに手順が動かず、記録も残りません。

• 分類ごとの線引き表が承認されている
• AIに参照させる情報の更新責任者が情報源ごとに決まっている
• 有人切り替え先の受付時間と担当が決まっている
• 誤回答時に運用を止める権限を持つ人が決まっている

段階は3つに分け、それぞれ次へ進める条件を先に書いておきます。

一度に2つ以上広げないのは、問題が起きたときに原因を分離できなくなるためです。チャネルと時間帯を同時に広げた翌週に誤回答が増えても、どちらを戻せばよいか判断できません。

前へ進む条件と同じ重さで、戻す条件も決めます。同じ型の誤りが3回続いた場合、切り替え後の引き継ぎが機能していない場合、参照元の更新が止まった場合のいずれかで、前の段階へ戻します。そう書いておけば、判断のたびに社内で合意を取り直さずに済みます。

なお、AIへ入力するデータの取り扱いや情報漏洩への備えは、この線引きとは別の軸で決める論点です。

あわせて読みたい

法人の生成AI利用リスクと情報漏洩対策｜経営者が導入前に確認する判断軸

責任者と最終責任の置き場所

AIの回答を自社の回答として扱う前提に立てば、責任の置き場所は既存の分掌をなぞる形に決まります。回答内容の最終責任は、人が同じ内容を答えていたら責任を負っていたはずの部門が持ちます。返金条件の案内なら条件を決めている部門、商品仕様なら商品部門です。AIを介したという理由でこれをシステム部門やベンダーへ移すと、内容を判断できない部署が回答の可否を握ることになります。

役割は3つに分けて指名します。

• 運用責任者（1名）: 線引き表の管理、運用を止める権限、記録の保全、更新の実行を担います。顧客対応の現場を持つカスタマーサポート部門長が務めるのが自然な形です。
• 内容の最終責任部門: 分類ごとに指名します。金銭・契約に関わる領域は、その条件を決めている部門が負います。
• 参照元の更新責任者: 情報源ごとに1名を置きます。ここが空席だと参照元が古いまま残り、事実照会をAI単独可に置いた前提が崩れます。

会議の議題は、ここまでの決定事項を8項目に並べた形にできます。

1. 問い合わせ上位の項目を3分類へ仕分けた表があるか
2. 各分類の既定レベル（AI単独可／人の確認必須／AI不可）が決まっているか
3. 迷った項目が安全側に置かれ、再判定の時期が決まっているか
4. 有人切り替えの3系統トリガーが、具体的な語・状況・回数で書かれているか
5. 切り替え時に顧客へ伝える内容と、担当者へ渡す情報が決まっているか
6. AI応対であることの告知方針と文言が決まっているか
7. 誤回答時の担当・期限・記録項目・停止権限が決まっているか
8. 第1〜第3段階の範囲と、次へ進める条件・前へ戻す条件が決まっているか

この8項目に空欄がなくなった時点が、顧客接点へ出す判断を下せる状態です。空欄が残るうちは、製品の検討をどれだけ進めても決めるべきことは減りません。

法人AI研修で支援できる範囲

法人AI研修は、Claude・ChatGPT・Geminiなどの生成AIを自社の業務課題に合わせて学び、部門別演習からAI成果物の実装、研修後の定着支援まで伴走する法人向けサービスです。相談領域はカスタマーサポート・現場を含む4つから選べます。

顧客接点の線引きそのものは、商材と失敗コストを持つ自社が決める部分です。研修で扱えるのは、決めた内容を現場が実行できる形へ落とす工程になります。相談テーマによって成果物は変わりますが、回答可否とエスカレーション基準の設計、検索・回答範囲の設計、精度検証と例外処理設計といった項目を研修内の成果物として扱っています。カスタマーサポート領域の成果物例には、ヘルプ記事と問い合わせ内容からFAQを生成し、自己解決率を高める仕組みがあります。

伴走支援では、運用ルールの整備とナレッジの継続更新体制の構築を扱います。研修後は、成果物が業務で使われ続けているかを確認し、つまずきの解消や他部門への横展開を支援する定着支援を研修とセットで設計しています。

進め方は、初回無料ヒアリングから始まります。現状の課題や時間のかかっている業務を伺い、研修プランを一緒に立てます。現状課題・部門・業務フローをヒアリングして実務テーマと成果物まで設計するパーソナライズ研修と、標準カリキュラムをベースに始めるパッケージ研修のどちらから入るかも、この段階で相談できます。

よくある質問

線引き表とトリガーの案そのものは、社内で作れます。ただ、それが自社の失敗コストに見合っているかどうかは、内側の目だけでは確かめにくいところです。第三者と条件を突き合わせたい場合は、次からご相談ください。