問い合わせ対応をAIで自動化するには？導入手順と注意点

2026年8月10日

AIによる問い合わせ対応は、全工程を任せず「受付・分類→ナレッジ検索→回答案生成→自動回答または有人切り替え→履歴保存・改善」に分解して自動化するのが基本です。本記事では、工程ごとの自動化可否、AIチャットボット・RAG・RPAなどの選び方、エスカレーション、ログ、個人情報、PoCの実務設計を解説します。

なぜ「問い合わせ対応をAIに全部任せる」設計は失敗するのか

AI問い合わせ対応の成否は、AIモデルの性能だけでは決まりません。回答範囲、参照情報、送信権限、有人切り替え、ログを使った改善までを一つの業務として設計しなければ、誤回答や対応漏れを安定して抑えられないためです。

生成AIは自然な文章を作成できる一方で、事実と異なる内容をもっともらしく出力する場合があります。RAGで社内文書やFAQを検索させても、検索結果の選択、文脈の解釈、回答の生成という複数の段階があるため、誤回答の可能性を完全にはなくせません。

したがって、全面自動化を前提に製品を選ぶのではなく、誤った場合の影響が小さく、回答が一意に定まる業務から始めます。送料、営業時間、申請手順、製品の基本操作などは候補になりますが、クレーム、返金、契約、事故、安全、本人確認を伴う手続きは、人が判断する設計が基本です。

判断ポイント：「AIが回答できるか」ではなく、「誤回答が起きても検知・停止・訂正できるか」を基準に自動化範囲を決めます。

「ツール導入」で止まる企業と、運用に乗る企業の分岐点

運用に乗る企業は、導入時点でナレッジの更新責任者とログの確認方法を決めています。反対に、ツールの設定完了をゴールにすると、サービス変更や規程改定に回答が追随せず、時間の経過とともに精度が低下します。

問い合わせログには、FAQに存在しない質問、利用者が実際に使う表現、誤分類された質問、担当者が修正した回答が蓄積されます。これらを定期的に確認し、FAQ、検索設定、プロンプト、分岐条件を更新することが、モデルの変更以上に重要な場合があります。

改善には、問い合わせ業務を理解する部門とシステムを管理する部門の双方が関与するのが望ましい形です。カスタマーサポートだけに任せると連携改修が進まず、情報システム部門だけに任せると現場で起きている誤回答を評価しにくくなります。

自動化の前に必要な「回答元」の整備

AIに参照させる情報が古い、重複している、文書ごとに記載が矛盾している場合、RAGを導入しても安定した回答は得にくくなります。検索精度を上げるだけでなく、どの文書を正として扱うか、誰が承認し、いつ更新したかを管理する必要があります。

まず、現行のFAQ、マニュアル、利用規約、社内規程、製品情報を棚卸しします。そのうえで、文書の管理部門、適用開始日、更新日、有効期限、公開範囲を付与し、失効した情報を検索対象から外せる状態にします。

正確な回答元が存在しない業務では、AI導入よりナレッジ整備を優先するのがCREATREE編集部の提案です。担当者ごとに判断が異なる状態をAIで再現すると、属人化を解消するのではなく、不統一な判断を自動化することになります。

問い合わせ対応を5工程に分解する｜どこをAIに任せ、どこを人が持つか

問い合わせ対応は、受付・分類、ナレッジ検索、回答案生成、送信判断、履歴保存・改善の5工程に分けて設計します。工程ごとに自動化の適性と失敗時の影響が異なるため、一つのツールですべてを処理する必要はありません。

社内問い合わせでは、システム操作、申請手順、福利厚生、社内規程などが候補になります。社外問い合わせでは、在庫・配送状況、基本操作、返品手順などを検討できますが、実データの照会や変更には、本人確認とシステム権限の設計が別途必要です。

工程別の自動化適性と担当の切り分け

CREATREE編集部では、繰り返し可能な処理ほど自動化し、判断の影響が大きい工程ほど人の責任を残すことを推奨します。以下は、工程別に役割を切り分けるための基本形です。

工程	自動化のしやすさ	AI・システムに任せる範囲	人が持つ責任	必要な前提条件
受付・分類	高い	チャネル統合、内容分類、担当部署への振り分け、チケット作成	分類ルールの承認、例外案件の処理	問い合わせ区分、優先度、振り分け先が定義されている
ナレッジ検索	比較的高い	FAQ・規程・マニュアルの横断検索、候補文書の提示	正本の指定、文書の更新、検索対象の承認	正確で更新された情報源とアクセス権限がある

工程	自動化のしやすさ	AI・システムに任せる範囲	人が持つ責任	必要な前提条件
回答案生成	中程度	検索結果の要約、返信文案の作成、表現の調整	内容の妥当性確認、禁止表現の定義	根拠を表示でき、根拠外の生成を制限できる
送信判断	案件による	低リスク案件の自動送信、承認依頼、有人切り替え	高リスク案件の最終判断と対外責任	回答権限とエスカレーション条件が明文化されている

工程	自動化のしやすさ	AI・システムに任せる範囲	人が持つ責任	必要な前提条件
履歴保存・改善	保存は高い、改善判断は中程度	ログ保存、未回答・低評価案件の抽出、集計	原因分析、ナレッジや運用ルールの変更	保存目的、権限、期間、改善責任者が決まっている

分類や転記のように手順が固定された処理は、RPAやワークフロー機能で対応できます。一方、文章の意味を読み取る分類や複数文書の横断検索には生成AIやRAGが適します。AIの出力を業務システムへ書き込む場合は、処理前の承認や取り消し方法も必要です。

「自動回答可能／回答案のみ／必ず有人」の3分類判断表

自動化対象は、問い合わせの難易度ではなく、回答の一意性、根拠の有無、誤った場合の影響、本人確認の必要性で判定します。同じ「返品について」という質問でも、手順案内と個別の返金可否では区分が異なります。

問い合わせ種別	判定区分	判定理由	必要な前提
営業時間、送料、申請方法、基本操作	自動回答可能	承認済みの回答があり、原則として回答が一意に定まる	最新版のFAQ、適用条件、更新責任者
複数資料を参照する製品説明やトラブル切り分け	回答案のみ生成	根拠はあるが、状況に応じた解釈や追加確認が必要	RAG、根拠表示、担当者による確認

問い合わせ種別	判定区分	判定理由	必要な前提
見積もり条件や例外的な手続き	回答案のみ生成	顧客別の条件や社内承認によって回答が変わる	顧客情報への適切な権限、承認フロー
クレーム、返金、不審請求、契約・法務判断	必ず有人対応	金銭、権利義務、企業としての意思決定を伴う	担当部署、優先度、引き継ぎ手順

問い合わせ種別	判定区分	判定理由	必要な前提
事故、安全、緊急性のある連絡	必ず有人対応	誤分類や対応遅延による影響が大きい	緊急連絡先、即時通知、時間外対応
本人確認が必要な情報照会・変更	必ず有人対応または認証済みフロー	なりすましや情報漏えいを防ぐ必要がある	本人認証、操作権限、監査ログ

判定は問い合わせの件名だけで固定せず、会話途中で変更できるようにします。定型質問から始まっても、返金要求や個人情報を含む相談へ移行した時点で、自動回答を停止して有人対応へ切り替えます。

回答権限の3段階を設定する

回答権限は、自動送信、担当者承認後に送信、回答案提示のみの3段階で設計します。自動送信は、承認済みの根拠に基づき、回答が一意で、誤答時の影響が限定的な質問に絞ります。

担当者承認後の送信は、根拠資料があるものの、顧客の状況や契約条件によって表現を調整する必要がある場合に適します。回答案提示のみは、契約、返金、法務、クレームなど、人が事実関係を確認して意思決定すべき案件に使います。

予約登録やCRM更新までAIエージェントに実行させると、文章の誤回答とは異なり、誤操作が実データへ反映されます。読み取り権限と書き込み権限を分離し、重要操作には承認、処理上限、監視、取り消し手順を設ける必要があります。

手段の選び方｜AIチャットボット・RAG・RPA・AIエージェント・ボイスボットを課題別に判断する

手段は流行ではなく、解消したい負荷から選びます。回答負荷にはチャットボットやRAG、分類・転記にはRPA、複数システムをまたぐ処理にはAIエージェント、電話受付にはボイスボットが主な候補です。

実務では一つに絞るとは限りません。生成AIで問い合わせを分類し、RAGで回答根拠を取得し、RPAやAPIでチケットを登録するなど、各手段を役割ごとに組み合わせます。

手段別の比較表

比較時には、導入時の機能だけでなく、前提データ、誤回答・誤操作のリスク、継続的な更新負荷まで確認します。企業規模よりも、社内に運用担当者を置けるか、既存システムとの連携がどこまで必要かが重要です。

手段	得意な問い合わせ・処理	必要な前提データ	主なリスク	運用負荷	向く体制
ルールベース型ボット	選択式FAQ、予約案内、手続き案内	シナリオ、選択肢、固定回答	想定外の質問に対応しにくい	シナリオ更新が必要	回答範囲が限定的で、確実性を重視する企業
生成AI型	質問の意図理解、文章作成、回答案作成	指示、禁止事項、必要に応じた参考情報	回答の揺れ、根拠のない生成	出力評価とプロンプト調整が必要	担当者の文章作成支援から始めたい企業

手段	得意な問い合わせ・処理	必要な前提データ	主なリスク	運用負荷	向く体制
RAG型	社内文書やFAQを根拠にした検索・回答	整理された文書、メタデータ、更新ルール	誤検索、古い情報の参照、根拠の誤解釈	文書更新と検索精度の検証が必要	独自情報を使った回答が多い企業
RPA	分類後の転記、定型登録、帳票処理	固定された画面と処理ルール	画面変更や例外処理による停止	業務変更に伴う改修が必要	定型作業が多く、API連携が難しい企業

手段	得意な問い合わせ・処理	必要な前提データ	主なリスク	運用負荷	向く体制
AIエージェント	複数ツールの検索、判断、登録、通知	API、権限、ワークフロー、承認条件	意図しない操作、権限逸脱、連鎖的な誤処理	監視、権限管理、障害対応の負荷が高い	連携要件と管理体制が明確な企業
ボイスボット	電話の一次受付、用件確認、定型案内	会話シナリオ、音声認識辞書、転送ルール	聞き間違い、緊急性や感情の誤判定	通話ログ評価と辞書更新が必要	電話件数が多く、有人転送先を確保できる企業

料金は製品、利用量、データ連携、セキュリティ要件、初期構築支援によって変わります。比較表の価格帯だけで決めず、自社データを使った検証費用、運用担当者の工数、API利用料、保守費まで含めて確認してください。

既製ツール・個別構築・外部支援のどれを選ぶか

受付チャネルが限定され、標準的なFAQ回答と有人転送で足りる場合は、既製ツールが第一候補です。管理画面からナレッジやシナリオを更新できるため、専門人材が少ない企業でも運用しやすい傾向があります。

独自の権限管理、複数の基幹システム連携、複雑な承認、特殊な検索要件がある場合は、ノーコード・ローコード基盤による構築や個別開発を検討します。ただし、Difyやn8nなどを利用して画面上で構築できても、データ設計、例外処理、監視、セキュリティまで自動的に解決されるわけではありません。

外部支援が適するのは、業務の切り分けができない、RAGの検索精度を評価できない、既存システムとの責任分界が複雑、運用担当者を育成しながら進めたい場合です。構築を委託する場合も、ナレッジ更新やログレビューまで永続的に外部へ依存しない運用体制を検討します。

ツール選定時に確認する評価軸

ツール選定では、デモの回答が自然かどうかだけでなく、自社の誤答例や例外案件を使って検証します。商談、PoC、契約確認の各段階で、次の項目を確認してください。

回答精度をどのテストデータと判定基準で検証できるか
CRM、問い合わせ管理、FAQ、ストレージとの連携が可能か
APIやWebhookが提供され、失敗時の再実行を制御できるか
SlackやMicrosoft Teamsなど、利用中のチャネルに対応するか
NGワード、禁止回答、回答範囲、参照元を設定できるか
ISMS、プライバシーマーク、SSO、権限管理など自社要件を満たすか
初期のナレッジ整備と導入後の改善を誰が支援するか
自社と近い業種だけでなく、同程度のリスクと連携要件を扱った事例があるか
質問、参照元、回答、操作、エラーの監査ログを取得できるか
契約終了時にデータを削除・移行できるか

特に回答精度は、ベンダーが用意した質問ではなく、自社の過去ログから抽出した正常例、曖昧な質問、対象外質問、高リスク質問で検証します。「正答したか」だけでなく、答えるべきでない質問を適切に有人へ渡せたかも評価対象です。

有人切り替えとログ管理の設計｜自動化を安全に広げる土台

有人切り替えは、AIが失敗した後の救済策ではなく、自動化フローの一部です。切り替え条件、担当部署、通知方法、引き継ぐ情報を事前に定め、同じ説明を利用者に繰り返させない設計にします。

有人対応へ移行した際は、それまでの会話、AIの分類、参照した情報、切り替え理由を担当者へ渡します。単に「回答できません」と表示して別窓口を案内すると、利用者の負担が増え、自動化の利用率を下げる原因になります。

有人へ切り替える条件の設計

切り替え条件は、質問の種類、検索結果、会話状態、顧客属性、操作内容を組み合わせて判定します。次の条件に該当する場合は、自動回答を停止するか、少なくとも担当者の承認を必須にします。

承認済みの参照根拠を取得できない
検索結果が複数に分かれ、回答を一意に決められない
AIの確信度や事前に定めた検証条件が基準を下回る
クレーム、苦情、解約意思が含まれる
事故、安全、障害など緊急性がある
契約、返金、補償、法務上の判断を伴う
本人確認が必要な照会や変更手続きである
要配慮個人情報や機微な相談内容を含む
同一顧客から同じ内容の再問い合わせがある
利用者が明示的に担当者対応を希望している

確信度の数値だけに依存するのは避けます。AIが高い確信を示しても誤っている可能性があるため、禁止テーマ、根拠の有無、本人確認、金銭的影響などの業務ルールを優先させます。

判断ポイント：有人切り替え率が高いことを一律に失敗と捉えず、危険な問い合わせを正しく止められた割合と、不要な切り替えの割合を分けて評価します。

保存すべきログ項目と、その使い道

改善に必要なのは、最終回答だけではありません。どの質問をどう分類し、何を根拠に回答し、どの段階で人が修正したかを追跡できるログが必要です。

ログ項目	保存目的	改善への使い道
質問文・会話履歴	利用者の意図と文脈を確認する	表現揺れ、未登録FAQ、離脱原因を把握する
分類結果	振り分けの妥当性を確認する	分類ルールと学習例を修正する

ログ項目	保存目的	改善への使い道
参照した情報源	回答根拠を追跡する	誤検索、古い文書、情報不足を特定する
生成した回答	AIの出力を再確認する	プロンプト、禁止表現、回答形式を改善する

ログ項目	保存目的	改善への使い道
送信可否・承認結果	回答権限の運用を確認する	自動送信範囲と承認条件を見直す
有人による修正内容	AI回答との差分を把握する	不足ナレッジや頻出する誤りを特定する

ログ項目	保存目的	改善への使い道
担当者・日時	対応経路と責任範囲を追跡する	滞留時間、時間帯別の体制を見直す
切り替え理由	エスカレーションの妥当性を確認する	過剰・不足な切り替え条件を調整する

ログ項目	保存目的	改善への使い道
利用者評価	回答が問題解決につながったか確認する	低評価回答を優先的に分析する
システム操作・エラー	誤操作や連携失敗を追跡する	再実行、切り戻し、権限設定を改善する

有人修正が繰り返される質問は、回答文だけを直すのではなく、分類、検索、根拠文書、生成、送信判断のどこで問題が起きたかを切り分けます。原因によって、FAQ追加、文書更新、検索設定、プロンプト、切り替え条件のどれを直すべきかが変わります。

ログ保存に伴う権限・保存期間の取り扱い

問い合わせログには、氏名、連絡先、相談内容、契約情報、営業秘密などが含まれる場合があります。分析に便利だからという理由だけで、全項目を無期限に保存する設計は避けるべきです。

注意点：ログの保存前に、保存目的、対象項目、保存期間、アクセス権限、外部提供の有無、削除方法を定めます。開発・検証環境へ複製する場合も、本番環境とは別に権限と削除手順を設定してください。

閲覧権限は、問い合わせ対応、品質改善、システム保守、監査などの目的ごとに分けます。改善用データでは、氏名や連絡先を削除・置換し、原文を閲覧しなくても分析できる状態を優先します。

個人情報とセキュリティ｜外部AIに送信する前に決めておくこと

問い合わせデータを外部AIへ送信できるかは、情報の種類だけでは判断できません。利用目的、送信先、契約関係、保存・学習利用、安全管理措置、国外での取り扱いなどを確認し、利用シナリオごとに決定します。

生成AIサービスへ個人データを入力する場合は、利用目的の範囲内で取り扱うことに加え、提供事業者が入力情報を機械学習に利用するかどうかなどを十分に確認する必要があります。製品や契約プランによって条件が異なるため、実際に契約するサービスの最新規約と公式文書を確認してください。

また、要配慮個人情報の取得には、法令上の例外を除き、原則として本人同意が必要です。医療、犯罪被害、信条などの情報を含む可能性がある窓口では、通常のFAQ窓口とは分離し、AIへの送信を停止する設計も検討します。

入力可否を判断するデータ分類

データ分類はAI専用のルールにせず、クラウドやSaaSを含む外部サービス全体の管理基準と整合させます。以下は初期分類の例であり、最終的には自社の契約、法務、情報セキュリティ基準に合わせて調整してください。

データ区分	外部AIへの入力可否の考え方	必要な前処理・条件
公開情報	原則として利用候補	公開範囲、著作権、情報の最新性を確認する
一般社内情報	承認済みサービスに限定して検討	アクセス権限、保存先、学習利用、再利用条件を確認する

データ区分	外部AIへの入力可否の考え方	必要な前処理・条件
社外秘・機密情報	原則制限し、業務上必要な場合だけ個別審査	契約上の秘密保持、暗号化、権限、保持期間を確認する
個人情報	利用目的と法的関係を整理したうえで判断	データ最小化、マスキング、委託先管理を行う

データ区分	外部AIへの入力可否の考え方	必要な前処理・条件
要配慮個人情報・高リスク情報	原則として入力を避け、必要時は専門的な確認を行う	同意や法令上の要件、専用環境、厳格な権限を確認する
認証情報	入力禁止	パスワード、APIキー、秘密鍵を自動検知して遮断する

データ区分	外部AIへの入力可否の考え方	必要な前処理・条件
特別な高機密情報	原則として入力禁止	未公開の重要情報や再委託不可データを分離する

問い合わせ文章には複数区分の情報が混在します。そのため、フォーム項目だけでなく自由記述欄も検査し、送信前のマスキング、特定区分の遮断、有人窓口への切り替えを実装します。

問い合わせ履歴をAIに活用する場合の匿名化・マスキング

過去の問い合わせ履歴をFAQ作成やRAGの検索対象にする場合は、氏名、メールアドレス、電話番号、住所、顧客番号などを事前に除去します。固有名詞を単純に削除すると文脈が失われるため、「顧客A」「製品B」のような一貫した置換も検討します。

個人情報の除去は、自動検知だけで完了させず、人による抽出検査または高リスクデータの全件確認を組み合わせます。公開されている決済サービスの事例でも、生成AIで個人情報を除去した後に人が目視確認し、不要な文章改変があれば再生成する二段階の処理が採用されています。

なお、氏名を削除しても、所属、事象、日時などの組み合わせから個人を識別できる場合があります。仮名化やマスキングを行っただけで安全と判断せず、利用目的に必要な情報だけを残すデータ最小化を優先します。

ベンダー・AI提供者との契約で確認する事項

セキュリティページだけでなく、利用規約、プライバシーポリシー、データ処理契約、再委託先の一覧、サービス仕様を確認します。営業担当者の口頭説明と契約文書に差がある場合は、適用条件を書面で明確にします。

入力データ、添付ファイル、ログの送信先と保存先
入力・出力データがモデル学習やサービス改善に使われるか
データとバックアップの保持期間、削除方法
管理者権限、SSO、アクセス制御、監査ログの仕様
AIの機能、性能、限界、禁止用途に関する説明
再委託先と国外での取り扱い
障害、不具合、情報漏えい、誤出力時の連絡と対応
ログ提供と原因調査への協力範囲
アップデートによる仕様変更の通知条件
損害賠償、補償、責任制限の範囲
契約終了時のデータ返却、移行、消去方法

確認結果は法務・情報システム部門だけが保管するのではなく、問い合わせ対応の運用ルールへ反映します。例えば、添付ファイルを送信できない契約なら、現場が誤ってアップロードしないよう、画面上でも機能を無効化します。

PoCから本番運用までの進め方と改善サイクル

PoCでは、多機能な仕組みを作ることより、自動化できる範囲と停止すべき条件を検証します。過去ログからテストデータを作り、限定されたチャネルと問い合わせ種別で試した後、実運用ログを基に段階的に対象を広げます。

チャネル・件数・種類・対応手順を棚卸しする
電話、メール、フォーム、チャット、社内チャットなどの受付経路を洗い出し、問い合わせ種類、担当部署、回答時間、転記先を整理します。件数だけでなく、同じ内容が繰り返されているか、回答が一意か、誤答時の影響が大きいかを確認します。
問い合わせを3分類する
各問い合わせを「自動回答可能」「回答案のみ生成」「必ず有人対応」に分類します。判断が割れるものは自動化せず、有人確認から始めます。
工程ごとに方式を選ぶ
固定FAQで足りるのか、RAGによる検索が必要か、分類や転記にRPAを使うかを決めます。ツールありきではなく、5工程のどこに何が必要かを対応付けます。
回答権限とエスカレーション条件を設定する
自動送信、承認後送信、回答案提示のみを問い合わせ区分ごとに定めます。根拠なし、クレーム、返金、契約、本人確認など、有人へ切り替える条件と担当部署も決めます。
ログ項目・権限・保存期間を設計する
質問、分類、参照元、生成回答、修正内容、担当者、日時、切り替え理由、評価を保存します。個人情報を含むログについては、閲覧者、保存期間、マスキング、削除方法を定めます。
限定範囲でPoCを実施する
一つのチャネルや少数の定型質問に絞り、まずは担当者向けの回答案生成として試します。正常な質問だけでなく、曖昧な質問、根拠がない質問、禁止テーマ、個人情報を含む質問もテストします。
ログをレビューして原因別に修正する
誤分類、誤検索、誤回答、不要な有人切り替え、切り替え漏れを分けて評価します。FAQ、文書、検索設定、プロンプト、権限、分岐条件のどこを直すかを決定します。
本番化し、対象範囲を段階的に広げる
限定された問い合わせから自動送信を開始し、安定した区分だけを追加します。新商品、規程改定、システム変更があった際は、公開前にナレッジとテストデータを更新します。

PoCの評価指標は、自動回答率だけにしません。正答、根拠提示、適切な有人切り替え、担当者の修正量、未解決、再問い合わせ、処理時間などを組み合わせ、利用者の体験とリスクの両面で判断します。

注意点：検証環境で高い正答率が出ても、テスト質問が実際の利用者の表現を反映していなければ本番では再現しません。過去ログから抽出した質問に加え、入力ミス、略称、複数の要件を含む質問もテストしてください。

まとめ

AI問い合わせ対応は、全面自動化ではなく、工程とリスクを分けて設計することが重要です。定型質問から始め、根拠、回答権限、有人切り替え、ログ、個人情報の扱いを整えたうえで、検証可能な範囲だけを広げます。

最初の行動は、過去の問い合わせを「自動回答可能」「回答案のみ生成」「必ず有人対応」の3区分に整理することです。その後、参照するナレッジ、連携先、回答権限、エスカレーション条件、保存ログを一枚の業務フローにまとめれば、既製ツールで足りるか、RAGやRPAを組み合わせるか、個別構築が必要かを判断しやすくなります。

自動化対象を切り分けられない、既存FAQや問い合わせ管理システムと連携したい、Dify・n8n・RAGなどを含む構成を検討したい、有人切り替えやログ管理まで設計したい場合は、CREATREEへの相談をご検討ください。相談時に現在の受付チャネル、主な問い合わせ種類、利用中のシステム、希望する自動化範囲を整理しておくと、要件確認を進めやすくなります。

よくある質問

ChatGPTなどの生成AIに問い合わせ対応をすべて任せても問題ありませんか？: すべてを任せる設計は推奨できません。承認済みの根拠があり、回答が一意で、誤答時の影響が小さい質問だけを自動送信の候補にし、契約、返金、クレーム、本人確認、事故・安全に関する問い合わせは有人確認へ回してください。
AIが回答できない問い合わせを担当者へ自動で引き継ぐにはどう設計しますか？: 根拠を取得できない、禁止テーマに該当する、同じ質問が繰り返される、利用者が有人対応を希望するなどの条件を設定します。切り替え時には、会話要約、分類、参照元、生成回答、切り替え理由をチケットやCRMへ渡し、担当部署へ通知します。
問い合わせ内容に個人情報が含まれる場合、何を確認すべきですか？: 利用目的、外部AIへの送信に関する法的・契約上の整理、保存先、学習利用、保持期間、再委託、国外での取り扱い、安全管理措置を確認します。必要最小限のデータだけを送り、マスキングを行い、要配慮個人情報や認証情報は通常フローから分離してください。
AIチャットボット、RAG、RPA、ボイスボットはどのように使い分けますか？: 定型FAQにはルールベース型、文章理解や回答案には生成AI、社内文書を根拠に回答する場合はRAG、分類後の転記や定型登録にはRPA、電話の一次受付にはボイスボットを使います。複数システムを操作する場合はAIエージェントも候補ですが、権限、承認、監視、切り戻しが前提です。
導入後に保存すべきログと、回答精度を改善する方法を教えてください: 質問、分類結果、参照情報、生成回答、送信可否、有人修正、担当者、日時、切り替え理由、利用者評価を保存します。誤りを分類・検索・生成・送信判断に分け、原因に応じてFAQ、ナレッジ、検索設定、プロンプト、エスカレーション条件を更新してください。

参考情報・出典

著者プロフィール

この著者の記事一覧へ

著者 藤村隼人 CREATREE合同会社代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。

AI業務自動化