この記事の要点
- AIによる問い合わせ対応の自動化は「全件をAIに任せる」ものではなく、自動応答に回す範囲と人が対応する範囲を線引きする設計作業です
- 自動応答に回してよいのは「回答が一意に決まる」「金銭・契約に直接影響しない」「感情的な対応が要らない」の3条件をすべて満たす問い合わせだけです
- 誤回答が起きたときの顧客対応責任は発注者側に残るのが一般的です。承認者・エスカレーション基準・ログ保全を発注前に決めておく必要があります
- 効果は問い合わせの定型率とナレッジの整備度に強く依存します。削減率を先に約束できる類の施策ではありません
問い合わせ件数が増えて対応が追いつかない。特定の担当者しか答えられない質問が溜まっている。そうした状況から「AIで問い合わせ対応を自動化できないか」と考え始める会社は多いはずです。ただ、いざ検討を始めると製品紹介ばかりが出てきて、肝心の「自社の問い合わせのうちどこまでAIに任せてよいのか」が分かりません。
この記事はツールの比較ではなく、発注前に自社で決めておくべき運用設計の判断材料を扱います。具体的には、自動応答と有人対応を分ける条件、誤回答時の責任の置き方、着手の順番、費用の見方です。チャットボット製品の選定基準そのものについては、別記事「AIチャットボットの導入」で扱っているため、本記事では最小限に留めます。
目次
AIによる問い合わせ対応の自動化とは？何がどこまで自動化できるのか
AIによる問い合わせ対応の自動化とは、寄せられた問い合わせを「顧客への一次回答」「担当部署への振り分け」「オペレーターへの回答下書き」の3層に分け、AIに任せられる部分だけを切り出して処理させる仕組みです。全問い合わせにAIが自動で答える仕組みではありません。どの層をどこまで任せるかを決める作業が、導入検討の実体になります。
自動化できる3つの層（一次回答・振り分け・回答下書き）
自動化は3層に整理できます。顧客と直接接するか、人が最終確認を挟むか、誤回答が起きたときのリスクがどれくらいかで性質が大きく変わるためです。
| 層 | やること | 顧客と直接接するか | 誤回答時のリスク |
|---|---|---|---|
| 一次回答 | 顧客の質問にAIが直接回答を返す | 接する | 高い（顧客に誤情報が届く） |
| 分類・振り分け | 内容から担当部署・優先度を判定して割り振る | 接しない | 中（対応が遅れる程度） |
| 回答下書き | 担当者向けに回答案とソースを提示する | 接しない（人が確認して送信） | 低い（送信前に止められる） |
リスクが低く、それでいて負荷軽減の実感が得やすいのは振り分けと回答下書きです。特に回答下書きは、人が最終確認するため誤回答が外に出ません。にもかかわらず、検索して出てくる事例の多くは顧客向けチャットボットの話に寄っています。いきなり顧客への直接自動応答から入ると、精度の議論と顧客対応の責任問題を同時に抱えることになります。段階を踏むほうが安全です。
チャットボット・FAQ AI・メール自動応答の違いと使い分け
問い合わせ AI 自動応答と一口に言っても、対話形式のチャットボット、既存文書から回答を生成するFAQ AI、非同期で下書きを作るメール・フォーム自動応答では、向いている問い合わせも必要な準備も違います。
| 方式 | 向いている問い合わせ | 必要な事前準備 | 人の介在ポイント |
|---|---|---|---|
| チャットボット（対話型） | その場で解決したい定型質問、営業時間外の一次受け | 想定質問と回答、有人チャットへの引き継ぎ導線 | エスカレーション後の対応 |
| FAQ AI（文書検索・生成型） | マニュアルや規程に答えが書いてある質問 | 参照させる文書の整理と公開可否の分類 | 参照元文書の承認・更新 |
| メール・フォーム自動応答 | 回答に確認や判断を伴う問い合わせ | 過去の対応履歴、テンプレート文 | 送信前の内容確認（必須） |
faq ai と呼ばれる方式は、既存のマニュアルやFAQページを情報源として回答を組み立てます。想定質問を1問ずつ登録しなくてよい代わりに、参照される文書が古ければ古い回答がそのまま出ます。準備の重心が「質問の登録」から「文書の整備」に移ると考えてください。
生成AI登場で変わった点・変わらない点
生成AIによって変わったのは、想定質問をすべて登録しなくても、表記ゆれや言い回しの違いを吸収して回答できるようになった点です。変わっていないのは、社内に正しい情報が文書として存在しなければ回答できないという制約です。ここを取り違えると期待値がずれます。
シナリオ型のボットは、登録されていない質問には「該当する回答が見つかりません」と返すだけでした。生成AIを使った仕組みは、関連しそうな文書を探して回答を組み立てます。便利になった反面、情報源が曖昧なときに、それらしい誤答を返す可能性が残ります。誤回答の確率をゼロにはできません。この前提を運用設計に織り込む必要があります。
どの問い合わせをAIに任せてよい？自動応答と有人対応を分ける3つの条件
自動応答に回してよいのは「①回答が一意に決まる ②金銭・契約に直接影響しない ③感情的な対応を必要としない」の3条件をすべて満たす問い合わせだけです。1つでも外れるものは、AIが下書きを作っても人が確認して送る、あるいは最初から有人に回す設計にします。AIの能力側ではなく、業務側から線を引くのが実務的です。
判定の流れはシンプルです。
- その質問の答えは、資料上で一つに定まるか → 定まらないなら有人
- 回答が料金・契約・個人情報に影響するか → 影響するなら人の確認を挟む
- 相手が不満や不安を抱えている状況か → そうなら最初から有人
- 3つとも通過したものだけを自動応答の対象にする
条件1：回答が一意に決まるか（社内で答えが割れる質問は渡さない）
自動応答の候補になるのは、正解が資料上で一意に定まり、どの担当者が答えても同じ回答になる質問です。担当者によって回答が変わる質問は、AIに任せても回答が安定しません。人が判断していた部分を機械が肩代わりできないからです。
一意に決まる例は、営業時間、返品可能期間、対応している仕様やファイル形式、手続きに必要な書類、配送の目安日数といったものです。決まらない例は「うちの環境でも使えますか」「この場合は特例扱いになりますか」のように、前提条件によって回答が分岐する質問です。
判定は感覚ではなく作業で行えます。過去の問い合わせログを抽出し、同じ趣旨の質問に対して複数パターンの回答が存在するものを探してください。回答が割れている質問は、その時点で自動応答の対象から外します。割れている理由が「社内ルールが決まっていないから」であれば、AI導入以前にルールを決める話になります。
条件2：金銭・契約・個人情報に関わるか（誤りが取り返しのつかない領域）
料金、請求、解約、契約条件、個人情報の開示や変更に関わる問い合わせは、誤回答が金銭的な損害や契約トラブルに直結します。AIが回答文を作ってもよいものの、人が確認してから送る設計にしてください。カテゴリを3段階に分けると整理しやすくなります。
| 区分 | 対象カテゴリの例 | 設計 |
|---|---|---|
| AIが直接答えてよい | 営業時間、仕様、操作手順、配送状況の一般案内、手続きの必要書類 | 自動応答＋有人窓口への導線 |
| 人の確認を挟む | 請求内容の確認、返金可否、契約更新の条件、納期の個別回答 | AIは下書きのみ生成、担当者が承認して送信 |
| AIに触れさせない | 見積・割引交渉、解約条件の個別調整、個人情報の開示請求、法的な照会 | 受付時点で有人に振り分け |
特に見積・割引・解約条件は個別契約に依存します。「一般的にはこうです」という回答が、その顧客の契約では違うということが起きます。自動応答から外すのが安全です。個人情報を含むやり取りを外部のAIサービスに通す場合は、取得時の利用目的の範囲内かどうかも確認が必要です※1。
条件3：感情的な対応が必要か（クレーム・障害時は最初から人へ）
クレーム、障害や不具合の申告、解約の申し出など、相手が不満や不安を抱えている問い合わせは、内容として正しい回答でも自動応答では逆効果になります。「まず状況を受け止めてほしい」という要求に、正確な情報提供は噛み合いません。最初から有人に振り分けます。
検知をAIの感情分析だけに頼るのは避けてください。判定を外したときの損失が大きいためです。実装としては、特定キーワード（「解約したい」「使えない」「壊れた」「責任者を出して」など）でのルールベース振り分けを先に置き、そのうえで2往復しても解決しない場合は強制的に有人へ引き継ぐ、という二段構えが現実的です。障害発生中は自動応答そのものを停止し、状況案内と有人窓口だけを出す運用も有効です。
3条件で自社の問い合わせを仕分けする手順
直近3〜6か月の問い合わせログから100〜300件をサンプリングし、3条件で「自動応答」「人が確認して送信」「完全有人」の3分類にタグ付けしてください。この作業をすると、自動化できる問い合わせが実際には何割なのかが数字で見えます。
仕分けシートは次の列で足ります。
- 問い合わせ内容（要約）
- 同種の件数
- 回答が一意に決まるか（○／×）
- 金銭・契約・個人情報に関わるか（○／×）
- 感情的対応が必要か（○／×）
- 分類結果（自動／確認付き／有人）
- 回答の根拠となる文書の有無
この表を発注前に自社で作っておくと、見積の精度が上がります。ベンダー側は「どの質問に、どの文書を根拠に答えるのか」が分からないと工数を出せません。逆に言えば、この表がないまま出てきた見積は、前提が曖昧なぶん幅を持たせた金額になっていると考えたほうがよいでしょう。
※1 個人情報保護委員会「個人情報保護法」リンク
AIが誤回答したら誰が責任を負う？発注前に決めておく5つのこと
AIが誤った回答を返して顧客に迷惑がかかった場合、その顧客対応の責任は原則としてサービスを提供している発注者側に残ります。ベンダーとの契約では、AIの出力精度や回答の正確性が保証対象外とされることが多いためです。だからこそ、責任分界・承認者・エスカレーション基準・ログ保全・利用者への表示を、発注前に文書で決めておく必要があります。
ベンダー契約で確認すべき責任範囲（精度保証は付かない前提で読む）
AI関連の開発契約やSaaS利用規約では、回答の正確性や特定の精度を保証しない旨が明記されているのが一般的です。「正答率◯%を保証」という条項はまず付きません。したがって、誤回答が顧客に届いたときの一次対応と是正は発注者の仕事になる前提で読んでください。
契約書で確認したい点は次のとおりです。
- 精度・品質に関する保証の有無と、免責の範囲
- 入力したデータが学習に利用されるかどうか、保存先と保存期間
- 回答の元になるナレッジの整備・更新は、どちらの責任か
- チューニングや再設定が保守に含まれるか、都度見積か
- 障害時の復旧目標（SLA）と連絡体制
- 契約形態が請負か準委任か（準委任では成果物の完成義務を負わないのが通常）
AIを事業に組み込む側の役割や、透明性・説明責任に関する考え方は、国のガイドラインでも整理されています※2。契約の議論に入る前に一度目を通しておくと、ベンダーとの責任分担の会話がしやすくなります。
社内の責任分界：回答内容の承認者とエスカレーション基準を決める
社内では、AIの回答ソースになるFAQ・ナレッジの内容承認者と、AIから人へ引き継ぐ基準を運用開始前に文書化してください。決まっていないまま公開すると、誤回答が起きたときに誰も止められません。
役割は3つに分けると割り当てやすくなります。ナレッジの正しさに責任を持つ人、エスカレーションされた問い合わせに対応する人、誤回答が発生したときの報告と是正を仕切る人。兼務でも構いませんが、名前を書いておくことが重要です。
エスカレーション基準は「AIが判断する」ではなく、条件で書きます。回答の信頼度スコアが閾値を下回った場合、2往復で解決しない場合、指定キーワードを検出した場合、同一顧客から短時間に複数回問い合わせがあった場合。こうした条件を並べておけば、運用担当者が変わっても判断がぶれません。
誤回答を検知・是正する仕組み（ログ保全と定期レビュー）
問い合わせと回答のログを全件保存し、月次で「解決しなかった質問」と「エスカレーションされた質問」を抽出してナレッジを更新する運用が要ります。これがないと、誤回答は誰にも気づかれないまま繰り返されます。
ログに残すべき項目は、質問文、返した回答文、参照したソース文書、信頼度、エスカレーションの有無、対応した担当者、日時です。特に「参照したソース」が残っていないと、誤回答の原因が文書側なのか回答生成側なのかを切り分けられません。発注時にログの出力仕様を確認してください。
レビュー頻度は、公開直後は週次、安定後は月次が一つの目安です。是正のリードタイムも決めておきます。「重大な誤回答は当日中に該当質問を停止、文書修正は5営業日以内」といった形です。この運用工数は導入後ずっと発生します。見積の段階で人件費として計上しておかないと、後から「担当がいない」という理由で放置されます。
利用者への表示（AI回答であることの明示と免責の伝え方）
回答がAIによる自動生成であること、内容の正確性には限界があること、正式な回答は有人窓口で得られることを画面上で明示しておくと、誤回答が起きたときのトラブルを軽くできます。隠して運用するメリットはほとんどありません。
表示文言は、たとえば「この回答はAIが自動生成しています。内容に誤りが含まれる場合があります。正式なご回答が必要な場合はお問い合わせ窓口へご連絡ください」といった形で十分です。あわせて、有人窓口へのボタンを常時見える位置に置いてください。導線が分かりにくいと、解決できなかった顧客の不満が積み上がります。
社内向けに使う場合は、逆方向の注意が必要です。社外秘や個人情報を含む文章を、契約上学習利用の対象になるサービスへ入力しないというルールを、利用開始前に周知してください。
※2 経済産業省・総務省「AI事業者ガイドライン」リンク
問い合わせ対応の自動化はどう進める？5つのステップ
進め方は「①問い合わせログの棚卸し ②3条件での仕分け ③ナレッジ整備 ④限定範囲でのPoC ⑤運用・改善体制の構築」の5段階です。最初に着手すべきはツール選定ではなく、ログの棚卸しです。何を自動化するかが決まっていない状態で製品を選んでも、比較の軸を作れません。
STEP1〜2：問い合わせログの棚卸しと自動化対象の仕分け
直近数か月の問い合わせを内容別に集計し、件数の多い順に並べます。上位2〜3割の質問が全体の何割を占めるかを見てください。ここが厚いほど自動化の効果が出やすくなります。そのうえで、前章の3条件で自動応答の対象を絞り込みます。成果物は「問い合わせ分類表」です。
実務上つまずくのは、ログが分散しているケースです。メール、問い合わせフォーム、電話、チャット、営業担当への直接連絡と入口が複数あると、全体像が見えません。まずはメールとフォームのように文字で残っているものから集計し、電話は対応履歴メモや日報から拾って補います。電話は音声のため定量化が難しく、件数を正確に出そうとすると作業が止まります。おおよその割合が分かれば十分です。
この2ステップは自社でやるべき範囲です。ベンダーに丸投げすると、社内の事情を知らない人が分類することになり、結局レビューに同じ時間がかかります。
STEP3：AIが参照するナレッジ（FAQ・マニュアル）の整備
AIの回答品質は、ツールの性能よりも参照するドキュメントの質でほぼ決まります。そして、このナレッジ整備が全工程で最も工数を食います。ここを軽く見積もると、スケジュールが必ず後ろにずれます。
整備の判断軸は4つです。情報の鮮度（最終更新日が古い文書は誤回答の原因になる）、粒度（1文書1テーマ、できれば1問1答に分解されているか）、公開可否（社外に出してよい情報とそうでない情報が混ざっていないか）、表記ゆれと重複（同じ内容が複数の文書に違う書き方で存在していないか）。
既存FAQが数年更新されていない場合、自動化より先に棚卸しが必要です。古い情報を情報源にすると、AIは古い回答を自信を持って返します。これは技術で解決できません。逆に言えば、ナレッジ整備は自動化を見送っても無駄にならない投資です。
STEP4：小さく試す（対象を絞ったPoCの設計と評価指標）
最初から全問い合わせに適用せず、質問カテゴリか対象ユーザーを絞って試します。評価指標と合格ラインを事前に決めておくことが、PoCが宙に浮かないための条件です。「やってみて感触を見る」だけで終わると、拡大の判断ができません。
見るべき指標は、正答率（サンプル質問に対して正しく答えられた割合）、エスカレーション率（人に引き継がれた割合）、解決率（利用者が解決したと回答した割合）、そして誤回答の内容と原因です。合格ラインは業務によりますが、「エスカレーション率が高くても誤回答がゼロに近い」ほうが、公開初期としては望ましい状態です。
適用先の順番としては、社内問い合わせ（情シス・人事・総務への質問）から始めると誤回答のリスクが小さくて済みます。相手が社員であれば、間違いを指摘してもらえますし、対外的な信用の問題になりません。
STEP5：運用・改善体制をつくる（作って終わりにしない）
公開後は月次でログをレビューし、回答できなかった質問をナレッジに追加する担当と作業時間を確保してください。これがないと、数か月で回答内容が実態からずれていきます。製品や料金が変わっているのに、AIだけが古い情報を返し続ける状態が一番危険です。
運用工数の目安は、対象文書の量と更新頻度の掛け算で考えます。月に何本の文書が更新される業務なのか、そのうちAIの情報源になるものはどれか、を数えてみてください。兼務にする場合、繁忙期に真っ先に後回しになるのがこの作業です。月末の定例に組み込むなど、時間を先に押さえる工夫が要ります。
ベンダーの保守契約に何を含めるかも、ここで決まります。文書更新は自社、システム側のチューニングと障害対応はベンダー、といった切り分けを契約書に書いておくと後で揉めません。
費用の考え方と、効果が出るケース・出ないケース
費用はツール利用料だけではありません。「初期構築・連携」「ナレッジ整備」「運用改善」の3つが加わります。見落とされやすいのは、ナレッジ整備と運用の人件費です。効果の大きさは問い合わせ件数・定型率・ナレッジ整備度で決まるため、導入前に削減率を約束できるものではありません。
費用の内訳：SaaS利用料・初期構築・ナレッジ整備・運用工数
見積を比較するときは、次の4つに分けて並べ替えると差が見えます。
| 費目 | 内容 | 変動する要因 |
|---|---|---|
| ツール／API利用料 | 月額または従量課金 | 問い合わせ件数、ユーザー数、対象文書量 |
| 初期構築・連携 | 設定、既存システムとの連携、チューニング | 連携先の数、既存システムのAPI有無 |
| ナレッジ整備 | 文書の棚卸し、分解、公開可否分類 | 既存FAQの状態、文書量 |
| 運用改善 | ログレビュー、ナレッジ更新、精度調整 | 更新頻度、対象範囲の広さ |
既製SaaS型は初期構築が軽く、月額中心のコスト構造になります。自社データを使った個別開発（社内文書を情報源にする仕組みの構築）は、初期構築と連携の比重が大きくなります。ソフトウェア開発の費用が規模や工数と相関することは、公開されている実績データからも確認できます※3。見積の金額だけを見るのではなく、想定している工数と前提条件を出してもらってください。
比較時に必ず確認したいのは、どこまでが初期費用に含まれるのか、ナレッジ整備は自社負担かベンダー負担か、公開後のチューニングは保守に含まれるのかの3点です。この3つが曖昧な見積は、後から追加費用が出やすくなります。なお、条件を満たせばIT導入補助金などの制度が使える場合もありますが、対象要件や補助率は年度ごとに変わります※4。検討する場合は、その時点の最新の公募要領で必ず確認してください（記載は2026年時点の情報です）。
効果が出やすい条件（件数・定型率・ナレッジの整備度）
効果が出やすいのは、同じ質問が繰り返し来ていて、その回答が文書化されており、問い合わせ件数が一定量ある業務です。逆に、毎回内容が違う相談型の問い合わせが中心の業務では、自動応答の対象がほとんど残りません。
効果は削減率ではなく、算式で自社試算してください。「3条件を満たした問い合わせの月間件数 × 1件あたりの平均対応時間 × 自動応答で解決する割合」。この解決割合は導入前には分からないため、PoCの結果を入れて計算します。最初から「◯%削減できます」と提示してくる見積があれば、その根拠を尋ねてみてください。
件数削減以外の価値も見落とさないでください。夜間・休日の一次対応ができるようになる、繁忙期のピークを吸収できる、新人でも回答下書きを使って一定品質で返せる、といった効果は工数削減の数字には表れにくいものの、実務では効いてきます。
効果が出ない・失敗する典型パターン
失敗は4パターンに集約されます。それぞれ、事前に何を確認していれば避けられたのかをセットで押さえてください。
- ナレッジが未整備のまま導入した：情報源がないので回答できず、使われなくなります。→ 発注前に参照文書の鮮度と粒度を確認しておきます
- 自動応答の範囲を広げすぎた：契約や金銭に関わる質問まで自動で返し、トラブルになります。→ 3条件で対象を絞ってから公開します
- 有人への導線が分かりにくい：解決しない顧客がボットから抜け出せず、満足度が下がります。→ 有人窓口ボタンを常時表示し、2往復ルールを入れます
- 運用担当が決まっていない：誤回答が放置され、情報が古いまま残ります。→ 承認者とレビュー頻度を運用開始前に文書化します
自社でやるか、外注するかの判断基準
既製SaaSで足りて、社内に文書を整備できる人がいるなら内製寄りで進められます。基幹システムや顧客データとの連携が必要な場合、あるいは責任分界とセキュリティ要件を整理する必要がある場合は外注寄りです。判断は次の4軸で切ると迷いにくくなります。
| 判断軸 | 内製で進めやすい | 外注を検討したい |
|---|---|---|
| システム連携 | 連携なし、FAQページや文書を読ませるだけ | 基幹システム・CRM・在庫データと連携する |
| 扱う情報の機微度 | 公開情報が中心 | 個人情報や契約情報を参照させる |
| 社内の運用体制 | 文書を管理している担当がいる | 担当が不在、または兼務で時間が取れない |
| 改善の継続性 | 月次でログを見る運用を組める | 設計から運用フローごと整備が必要 |
どちらの場合でも、問い合わせログの仕分けまでは自社で終えてから相談したほうが、要件も見積も固まりやすくなります。「何を自動化したいか」が数字で示せる状態と、そうでない状態では、返ってくる提案の具体性がまるで違います。
※3 IPA「ソフトウェア開発分析データ集」リンク
※4 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク
自動化の範囲と責任分界、一緒に整理します。hikeに相談する
まとめ：自動化の成否は「線引き」と「責任の所在」で決まる
AI 問い合わせ対応 自動化の成否は、ツールの性能よりも、どこまでを自動応答に回しどこから人が対応するかの線引きと、誤回答時の責任の置き方で決まります。要点を整理します。
- 自動化は全件対応ではなく、範囲を切る設計作業です
- 自動応答に回してよいのは「回答が一意に決まる」「金銭・契約に関わらない」「感情的対応が不要」の3条件を満たすものだけです
- 誤回答の顧客対応責任は発注者側に残る前提で、承認者・エスカレーション基準・ログ保全を発注前に決めます
- 着手順はログ棚卸し → 3条件で仕分け → ナレッジ整備 → 範囲を絞ったPoC → 運用体制の構築です
- 効果は件数・定型率・ナレッジ整備度に依存し、導入前に削減率を約束できるものではありません
次の一歩として、直近3か月の問い合わせログから100件を抽出し、3条件で仕分けしてみてください。1日か2日で終わる作業ですが、自動化できる割合と、そもそも社内のルールが決まっていない領域の両方が見えてきます。その結果を持って相談すれば、要件と見積は格段に固まりやすくなります。
よくある質問
FAQが整備されていなくてもAIで問い合わせ対応を自動化できますか
過去の問い合わせ履歴や既存マニュアルから回答の元になる文書を作ることはできます。ただし、社内のどこにも答えが存在しない質問には、AIも答えられません。結局はナレッジ整備の工程を通ることになります。FAQがない状態からの導入は不可能ではありませんが、整備工数を見積に含めておく必要があります。
電話の問い合わせも自動化できますか
音声認識とAIを組み合わせた一次受けは技術的に可能です。ただし、聞き取り精度や感情的な対応の難しさを考えると、予約受付、営業時間案内、在庫や配送状況の確認といった定型用途に限定するのが現実的です。複雑な相談や不満を伴う内容は、早い段階で人に転送する設計にしてください。
社内問い合わせ（情シス・人事・総務）にも使えますか
むしろ最初の適用先として向いています。相手が社員であるため誤回答による対外的な損失が発生せず、間違いも指摘してもらいやすいからです。規程やマニュアルという文書がすでに存在している点も有利です。社内で運用の型を作ってから、顧客向けに広げる順序をおすすめします。
個人情報や社外秘を含む問い合わせを扱っても大丈夫ですか
契約と設定の確認が前提になります。入力したデータが学習に利用されるか、保存先はどこか、保存期間はどれくらいか、アクセス権限を業務単位で分けられるかを確認してください。あわせて、取得時に伝えた利用目的の範囲内かどうかも法令面で確認が必要です。社外秘の入力禁止ルールの周知も忘れずに。
導入までどれくらいの期間がかかりますか
既製SaaSで対象を絞った限定運用なら短期間で始められますが、既存システムとの連携や自社文書を使った個別構築を伴うと長くなります。期間を最も大きく左右するのはナレッジの整備状況です。参照させる文書が最新かつ整理済みなら短く、棚卸しから始めるなら数か月単位を見ておいたほうがよいでしょう。
有人対応の担当者は減らせますか
問い合わせ全体に占める定型質問の割合次第です。人員削減を先に見込むより、一次対応の負荷を下げ、判断が必要な問い合わせに時間を回せる状態を目指すほうが現実的です。定型質問が全体の一部しかない業務では、人員構成が変わるほどの効果は出にくくなります。まずはログの仕分けで割合を確認してください。