チャットボット運用ルールの作り方：回答範囲と有人対応を決める

## チャットボット運用ルールで最初に決めること チャットボットの運用ルールを作るときは、回答範囲、回答根拠、更新担当、有人対応、見直し方法の五つを最初に決めます。これらを一枚の運用表にまとめれば、日常の運用判断と公開前テストに共通の基準を使えます。 回答範囲では、チャットボットが回答する質問と、回答せずに担当者へ渡す質問を切り分けます。回答根拠で定めるのは、使用できる資料と、情報が食い違った場合の優先順位です。更新担当については、ログの確認、正しい情報の提供、公開の承認を誰が担うかを明確にします。有人対応では、自動回答を止める条件と引き継ぎ先を決めておきます。見直し方法には、未回答や情報変更の確認から修正までの流れを記載します。 特に重要なのは、何を回答するかだけでなく、どのような場合に回答してはいけないかを明文化することです。判断が分かれる質問は、最初から回答対象に含めません。根拠と対応方法を確認し、承認を得たものから段階的に追加します。 ## 質問ログを分類して運用対象を切り分ける チャットボットの運用設計は、担当者の想定だけで作らず、過去のメール、電話メモ、問い合わせフォーム、既存FAQなどに残っている実際の質問から始めます。個人名や連絡先など、分類に不要な情報は取り除いて扱います。 集めた質問は、まず次の四つに分類します。 - 定型的に回答できる質問 - 条件を確認すれば回答できる質問 - 個別の判断が必要な質問 - 自社の担当範囲ではない質問 営業時間のように、公式情報を根拠として一律に案内できる質問は、定型的な回答の候補です。一方、「返品できますか」という質問は、購入日、商品の状態、購入方法などによって結論が変わります。この場合は、一律に説明できる条件までをチャットボットが案内し、購入状況の確認や例外判断は有人対応へ引き継ぎます。 分類するときは、問い合わせ件数だけで優先順位を決めません。回答内容が安定しているか、根拠となる情報が変わりやすいか、誤った案内が利用者に与える影響が大きいかを確認します。件数が多くても個別判断を伴う質問は、自動回答には適しません。件数が少なくても、根拠が明確で回答が固定されている質問なら、回答対象にできる場合があります。 ## チャットボットが回答する範囲と回答しない範囲を決める 回答対象にしやすいのは、参照する根拠が明確で、利用者ごとに結論が変わりにくい情報です。営業時間、所在地、一般的な申込手順、必要書類などが該当します。ただし、臨時休業や受付条件の変更がある情報は、更新担当と反映方法も同時に決めなければなりません。 回答しない範囲には、契約上の最終判断、例外対応、本人確認を伴う照会、個別の在庫や進行状況、苦情への判断などを置きます。法務や医療をはじめ、専門的な判断が必要な内容をチャットボットに代替させる運用も避けます。一般的な手続きや窓口だけを案内し、個別の結論は担当者へ引き継ぎます。 たとえば、個別契約の変更相談では、変更手続きの窓口や事前に用意する情報までは案内できます。しかし、実際に変更できるかどうかは、契約内容や利用状況の確認が必要です。チャットボットでは可否を断定せず、必要な確認事項と連絡先を提示します。 回答可否について担当者の意見が分かれた質問は、いったん回答しない範囲に置きます。業務担当が根拠と例外条件を整理し、承認担当が公開可能と判断してから回答対象へ移します。 ## 回答に使える根拠と情報の優先順位を定める 回答に使用できる情報源は、運用開始前に限定します。公式の規程、承認済みの商品・サービス資料、社内で管理している手続き書、公開済みの案内、承認済みFAQなどが候補です。担当者の記憶や、出所を確認できないメモは、そのまま回答根拠にしません。 各情報源には、管理部署、公開日または更新日、内容の確認先を記録します。複数の資料で内容が食い違った場合に備え、どの資料を優先するかも決めます。料金表と社内FAQの記載が異なる場合に、対応者がその場で正しい資料を選ぶ運用にはしません。優先する資料と確認先を運用表に記載します。優先順位を決められない場合は回答を止め、情報を管理する部署へ確認します。 根拠が見つからない質問に対して、前後の文脈から回答を作ることも避けます。「確認できる根拠がない場合は回答しない」という停止条件を設け、有人対応または適切な案内先へ切り替えます。 どの情報を登録し、何を対象外にするかは、[チャットボットのナレッジ登録方法](/usage/knowledge-registration)で詳しく確認できます。運用表の「回答根拠」欄を記入する前に参照すると、登録する資料を切り分けやすくなります。 ## 更新担当・確認担当・承認担当の範囲を分ける 運用体制では、ログを確認する担当、正しい情報を提供する担当、公開の可否を承認する担当を分けて記録します。役職名だけではなく、それぞれが担当する作業まで明記します。 ログ確認担当は、未回答、質問意図と異なる回答、古い回答、有人対応へ適切に移せなかった会話を抽出します。情報提供担当は、商品、店舗、契約、配送など、該当する業務情報を確認します。承認担当は、修正案の根拠と回答範囲を確認し、公開してよいかを判断します。 小規模な組織では、一人が複数の役割を兼ねることがあります。その場合も、情報の確認と公開の承認は別の作業として記録します。担当者の不在によって更新が止まらないよう、代理担当と連絡方法も決めておきます。 情報変更を把握してから回答へ反映するまでの手順は、[ナレッジを更新する流れ](/usage/how-to-update-knowledge)で確認できます。回答文だけでなく、根拠資料と変更記録も併せて修正するときの参考になります。 ## AIチャットボットから有人対応へ切り替える条件を決める AIチャットボットから有人対応へ切り替える条件は、質問分類ごとに定めます。少なくとも、次のような状態は切り替えの候補です。 - 回答の根拠を確認できない - 質問の意図を特定できない - 同じ確認を繰り返している - 個別情報や本人確認が必要である - 契約や返品などの例外判断を伴う - 苦情、事故、緊急性のある連絡である - 利用者が担当者との会話を希望している 質問の意図を特定できないまま推測で回答を続けると、求められていない案内を重ねるおそれがあります。確認を繰り返しても解決しない場合は自動回答を止め、質問内容と確認済みの事項を担当者へ渡します。 有人対応を常時提供できない場合は、受付時間、回答方法、連絡先、返信時期の案内方法を決めます。即時対応できない時間帯でも、利用者が次に取るべき行動を判断できる案内にします。 切替条件と引き継ぎ先の役割をさらに詳しく整理するときは、[有人対応への引き継ぎ設計](/usage/human-handoff-strategy)を参照できます。チャットボットが回答を止める条件と、引き継ぎを受ける担当者の範囲を併せて確認できます。 ## 有人対応へ引き継ぐ情報を統一する 有人対応へ切り替えても、担当者に必要な情報が渡らなければ、利用者は同じ説明を繰り返さなければなりません。引き継ぐ項目をあらかじめ固定し、質問分類ごとに必要な内容を定めます。 基本項目は、質問内容、チャットボットが提示した回答、未解決の点、確認済みの事項、希望する連絡方法です。返品相談であれば、購入方法や商品の状態など、判断に必要な項目を業務担当と確認したうえで追加します。 個人情報は、対応に必要な範囲だけを収集します。引き継ぎに不要な住所、電話番号、契約情報などを一律に求めてはいけません。チャット上では収集しない情報がある場合は、担当者が別の確認方法を案内する手順を決めます。 ## 一枚の運用ルール表にまとめる手順 運用ルール表には、「質問分類」「回答可否」「回答根拠」「更新担当」「承認担当」「有人切替条件」「引継項目」「確認日」の列を設けます。必要に応じて、代理担当、案内先、変更履歴の列も追加します。 |質問分類|回答可否|回答根拠|更新担当|承認担当|有人切替条件|引継項目|確認日| |---|---|---|---|---|---|---|---| |営業時間|回答する|公式の営業時間情報|店舗情報担当|店舗責任者|臨時営業の情報を確認できない|対象店舗、質問日時|運用開始前に記入| |返品可否|条件案内まで回答する|承認済みの返品規程|販売担当|販売責任者|購入状況の確認や例外判断が必要|購入方法、商品状態、未解決点|運用開始前に記入| |個別契約の変更|一般手続きのみ回答する|承認済みの契約手続き案内|契約担当|契約責任者|個別契約の確認と可否判断が必要|相談内容、案内済み事項、連絡方法|運用開始前に記入| 作成するときは、質問ログから代表的な質問を選び、一行ずつ各列を埋めます。空欄が残ったら、運用開始後の判断に持ち越さず、公開前に関係者へ確認します。特に、回答根拠、承認担当、有人切替条件が空欄のままでは、回答の可否や引き継ぎの判断が安定しません。 完成した表は保管するだけでなく、公開前テストの判定表として使用します。テストで想定外の動作が見つかったら、チャットボットの設定だけでなく、表に記載した判断基準も更新します。 ## 公開前テストで運用ルールが機能するか確認する 公開前テストでは、回答対象の質問へ正しく答えられるかだけを確認しません。回答してはいけない質問で停止できるか、必要な場面で有人対応へ切り替えられるかも確認します。 テストには、通常の質問、曖昧な質問、対象外の質問、古い情報を含む質問、有人判断が必要な質問を含めます。たとえば、「営業時間は？」「今日も通常営業？」「契約を特例で変更してほしい」と質問します。 「営業時間は？」は、公式情報に基づいて回答できるかを確認する質問です。「今日も通常営業？」では、臨時営業の情報まで確認できるかが判断点になります。「契約を特例で変更してほしい」には可否を断定せず、一般的な手続きの案内後に担当者へ引き継げるかを確認します。 判定結果は、「合格」「修正後に再確認」「回答対象外」などに分けて記録します。期待した結果にならなかった質問は、原因が回答範囲、根拠、表現、切替条件、引継項目のどこにあるかを切り分けます。修正後は同じ質問に加え、表現を変えた質問でも再確認します。 ## 公開後は質問ログと情報変更を起点に見直す 公開後は、未回答、質問意図と異なる回答、古い回答、有人対応へ適切に渡せなかった会話を分類します。確認のタイミングは一律に決めず、問い合わせ量、情報変更の頻度、誤回答時の影響を踏まえて設定します。 問題が見つかったときは、回答文だけを修正して終わらせません。原因が回答範囲、根拠資料、質問表現の違い、切替条件のどこにあるかを確認します。古い案内が見つかった場合は、回答内容とともに、根拠資料、更新担当、変更記録も更新します。 変更記録には、変更内容、理由、根拠、承認者、反映日を残します。反映後は、問題が起きた質問をもう一度試します。類似する質問も確認し、同じ原因による問題が残っていないかを判断します。 運用ルールを整えた後、改善状況をどの指標で確認するか検討するときは、[チャットボットの効果測定とKPI](/usage/chatbot-effect-measurement-kpi)が参考になります。未回答や有人対応への移行を、改善判断へつなげる段階で参照してください。 ## 運用ルールが機能しない場合に確認するポイント 運用ルールを作っても判断が安定しない場合は、次の状態に該当していないかを確認します。 - 回答範囲が広く、個別判断まで自動回答の対象になっている - 回答根拠の保存場所や優先順位が分からない - 更新担当または代理担当が決まっていない - 承認待ちのまま情報更新が止まっている - 有人対応の条件はあるが、引き継ぎ先が決まっていない - 質問ログを確認しても、修正の判断基準がない - 回答文だけを修正し、根拠資料や変更記録を更新していない 問題が見つかっても、表全体を作り直す必要はありません。該当する質問分類の行を確認し、空欄や判断が曖昧な項目を修正します。複数の分類で同じ問題が起きている場合は、情報源の管理方法や承認手順など、共通する運用ルールを見直します。 ## チャットボット運用ルールの作成チェックリスト 公開前に、次の項目が決まっているかを確認します。 - 回答対象となる質問を分類した - 回答しない質問と停止条件を決めた - 使用できる回答根拠を限定した - 情報が食い違った場合の優先順位を決めた - ログ確認、情報提供、承認の担当を決めた - 不在時の代理担当を決めた - 有人対応へ切り替える条件を決めた - 引き継ぐ情報と引き継ぎ先を決めた - 有人対応できない時間帯の案内を決めた - 通常、曖昧、対象外、古い情報、有人判断の質問をテストした - 変更内容、理由、承認者、反映日を記録できる 未決定の項目がある場合は、公開後の担当者判断に任せず、該当する質問分類、確認担当、対応方法を公開前に確定します。 ## よくある質問 ### チャットボットの運用ルールは誰が作りますか？ ログを確認する担当、業務情報を管理する担当、公開を承認する担当が共同で作ります。小規模な組織で一人が複数の役割を兼ねる場合も、作業ごとの責任は分けて記録します。 ### 運用ルールはいつ見直しますか？ 未回答、誤った案内、質問意図とのずれ、情報変更、有人対応への引き継ぎ失敗が見つかったときに見直します。確認のタイミングは、問い合わせ量、情報変更の頻度、誤回答時の影響に応じて決めます。 ### 回答範囲に迷う質問はどう扱いますか？ 最初は回答しない範囲に置きます。業務担当が根拠、例外条件、誤回答時の影響を確認し、承認を得てから回答対象へ追加します。 ### 有人対応を常時提供できない場合はどうしますか？ 受付時間、連絡方法、返信時期、緊急時の別窓口を案内します。即時対応できない時間帯には、すぐ担当者につながると誤解させる案内をしないことも運用ルールに含めます。 ## 運用表を作成して公開前の判断基準をそろえる チャットボットの運用ルールは、質問ログを基に問い合わせを分類し、回答範囲、回答根拠、更新と承認の担当者、有人対応への切替条件、引継項目を一枚の表にまとめると実行しやすくなります。その表を公開前テストの判定基準として使い、公開後は未回答、誤回答、情報変更を起点に更新します。 まずは、営業時間、返品、個別契約の相談など、代表的な質問を運用表へ記入します。回答できる条件を増やす前に、回答を止める条件と有人対応の受け皿を確認してください。これにより、自動回答させない範囲から先に確定できます。 自社の運用表を作成したうえで、Socratesを利用する場合の回答範囲、ナレッジ更新、有人対応の設計を確認したい場合は、Socratesの案内窓口へご相談ください。現在の問い合わせ分類と、未決定の運用項目を整理しておくと、確認すべき内容を具体化できます。