AIを使った問い合わせ対応支援は事業になる？人の対応との分担

AIを使う問い合わせ対応支援は、回答を自動生成する機能だけでなく、企業が安全に運用できる対応範囲と人への引継ぎを整える仕事として検討できます。最初は一つの窓口、一種類の質問に限定し、例外対応、回答根拠、更新担当を決めるのが現実的です。ここでは企業へ提供する支援サービスを扱い、SIRIUS-WEBの問い合わせフォームを変更する話ではありません。

最初の相談で「自動で答える」を分解する

問い合わせには、既に公開されている情報を案内するものと、顧客ごとの判断が必要なものがあります。前者は営業時間や利用手順などです。後者は契約変更、返金、個別の不具合、苦情などで、担当者の確認や権限が必要な場合があります。同じ窓口へ届いていても、同じ処理をしてよいとは限りません。件数が多いという理由だけで、全部をAIへ任せる提案は避けます。

受託側が提供できる仕事も複数あります。過去の質問を分類する、回答候補を整える、担当者用の下書きを作る、限定した自動案内を構築する、運用中の回答を点検する、といった範囲です。システム開発を担わなくても、情報整理や評価を提供できる場合があります。ただし、自分が動作や保守を確認できない仕組みまで一括で引き受けないようにします。

質問の種類別に、人の関与を決める

AIが判断できないときは、人へ渡すことを正常な処理として設計します。担当者へ渡るまでに何を確認し、どの情報を保存し、どの窓口へ送るかを決めます。人へ引き継ぐボタンがあっても、受け取る担当者が不在なら対応は終わりません。休日や営業時間外の案内、返答の見込み、緊急性がある場合の扱いまで顧客側と相談します。

仮定例：機器の使い方だけから始める

仮定として、業務用機器を販売する会社が、操作方法の問い合わせを減らしたいとします。最初の対象は公開マニュアル内の基本操作に限定します。故障判断や安全上の相談は担当者へ渡し、AIが独自の修理方法を提案しないようにします。対象が狭ければ、質問例と正しい案内を顧客が確認しやすくなります。

納品物には、質問の分類、参照する説明書、回答してよい範囲、引継ぎ条件、確認用の質問集を含めます。導入前に確認した例と、運用中に新しく届く質問を分けて記録します。利用者の言い方が説明書と違っていても正しい項目へ案内できるか、似た機種を混同しないかを確認します。質問に答えられない率だけを下げようとせず、誤った案内を出さないことも評価します。

現場の困りごとを確かめる方法は顧客面談の質問設計へ進めます。会社が欲しいのはAIそのものではなく、案内の負担を減らしながら顧客対応を維持する仕組みです。

回答の根拠を一つの管理場所へ揃える

社内資料に古い価格、旧サービス、例外的な説明が混在していると、AIがそれらを自然な文章にまとめても正しい回答にはなりません。現行の案内として使える資料を顧客に選んでもらい、版と確認日を残します。営業用の資料と契約上の条件が異なる場合は、どちらを回答根拠にするかを勝手に決めず、顧客側へ確認します。

新しい商品や条件が出たときに、誰が元資料を更新し、誰が回答を確認するかも必要です。受託側が毎回情報を探す契約なのか、顧客が改訂資料を渡す契約なのかで対応費が変わります。初回の構築だけで、その後の回答が常に正しい状態になるとは説明できません。更新対象、連絡方法、作業期限、対象外の変更を決めます。

知識整理を商品にする考え方は業界知識を使える形へ変える方法と関連しますが、問い合わせ支援では実際の顧客へ提示する回答を継続して管理する点が異なります。納品した資料の量だけでなく、運用中に判断できる担当者と根拠があるかを見ます。

評価用の質問は、うまく答えた例だけにしない

正しい質問文だけで動作を確かめると、実際の問い合わせでの問題が見えません。短い質問、曖昧な表現、複数の質問を含む文、対象外の依頼、古い情報を前提にした質問を用意します。個人情報を含まない仮の質問から始め、実際の問い合わせを使う場合は利用条件と取扱いを確認してください。評価用の文を変える際も、期待する案内を先に決めます。

点検記録では、適切な回答、不足情報の確認、人への引継ぎ、誤回答を別々に数えます。すべてを「回答できた」にまとめると、運用判断に使いにくくなります。回答が自然かという評価と、根拠に合っているかという評価も分けます。顧客側の確認者と評価基準が一致してから、限定した範囲で使用を始める方が問題を追いやすくなります。

問い合わせ情報を預かる条件を確認する

対応支援では、氏名、連絡先、契約情報などが含まれる可能性があります。データを誰が保管し、どのサービスへ送信し、誰が閲覧できるかを把握します。受託側が入力に使ってよいと独断で判断せず、顧客の管理方針や契約を確認します。AI利用の確認項目は入力情報と利用条件の整理を参照できます。

情報の削除、契約終了後の引継ぎ、再利用の可否も決めます。顧客の問い合わせを、別の顧客向けの見本や学習資料へ使うことは別の判断です。預かったデータの取扱いを整理し、顧客の業務に必要なアクセスだけを受け取るようにします。運用中の記録を確認する権限がなければ、品質改善を提供できる範囲にも制限が出ます。

費用の説明は初期作業と運用を分ける

停止する手順も導入前に用意します。誤った案内が見つかったとき、誰が設定を止め、通常の窓口へ戻し、過去の回答を確認するかを決めます。担当者が受託側だけでは、休日や契約終了時に顧客が操作できなくなる可能性があります。顧客側が状況を確認できる権限と、連絡できる担当を持てるようにします。人へ戻す方法は、障害時だけでなく、対象外の問い合わせが急増した場合にも必要です。

運用報告には、問い合わせ数だけでなく、どの分類が増えたかを載せます。未回答が多いのは、説明資料が足りないのか、利用者の質問が対象外なのかによって改善が違います。対象外の回答まで増やして自動対応率を上げると、当初の限定範囲が崩れます。拡大する場合は新しい質問集と確認者を用意し、変更前と同じ評価を行います。

担当者が下書きを使う方式なら、採用した回答と直した回答を分けて確認できます。直しが多い原因が情報不足か表現の問題かを調べ、根拠の資料や提示方法を見直します。ただし記録に顧客情報が含まれるなら、分析に使う権限と保存条件も確認します。運用改善のためという理由だけで、記録を無制限に受託側へ集めないことが重要です。

初期作業には質問整理、資料の確認、設定、評価が含まれます。運用には記録の点検、回答根拠の更新、引継ぎ条件の見直しなどがあります。毎月の対応を含めるなら、対象件数だけでなく、変更量や確認会議の回数も決めます。AIの使用料だけを原価とせず、顧客との調整や確認者の時間を含めて採算を考えてください。

既存業務から変更する負担は導入負担の見積もりで検討できます。問い合わせ支援に向くのは、回答根拠を管理でき、人が例外を受け取れる会社です。資料が古いまま、回答の責任者が不在、すべてを自動化したいという条件では、AIの設定より先に対応業務を整える必要があります。