コールセンターのAI内製化ガイド｜FAQ自動化の始め方と育て方

「問い合わせ対応をAIで自動化したい。でも、何から始めればよくて、どこで失敗するのかが分からない」。コールセンターやカスタマーサポート、社内ヘルプデスクの現場で、この声を非常によく聞きます。

採用難と高い離職率、1件あたり800〜1,200円という対応コストの中で、人を増やし続けるモデルはもう限界に近づいています。一方でAI活用の情報を調べても「導入事例」や「製品比較」ばかりで、「自社でどう作り、どう育てていけばいいか」までを具体的に書いた記事は多くありません。

本記事では、問い合わせ対応をAIで「内製化」する ー 外注に丸投げするのではなく、自社で運用・改善できる状態をつくる ー ための始め方と、実際につまずきやすい落とし穴を整理します。

「AIを入れれば減る」は誤解｜内製化の正しい始め方

まず、コールセンターを取り巻く前提から確認します。コールセンター集積地である東京の有効求人倍率は1.84倍（全国平均1.24倍を大きく上回る水準）、新規求人倍率は全国で2.22倍です。新規求人3件に対して応募者が1人という採用難が常態化しています。離職率も該当業種で23.1%（パートタイムは32.7%）、新人の1年以内離職は「21〜30%以上」という企業が半数近くにのぼります。

人件費の面でも、採用時の平均時給は1,511円、採用コストは1人あたり約42万円で、離職のたびに再発生します。電話対応は1件あたり800〜1,200円（人件費・SV・システム込みの目安）、外注しても1コール800〜1,500円が相場です。問い合わせ件数が増えるほどコストが線形に増える構造で、人員増だけで対応し続けるのは中長期的に持続しにくくなっています。

一方でAI活用の機運は高まっています。世界のコールセンターAI市場は2025年の24.1億ドルから2034年に135.2億ドル（年平均成長率20.8%）、日本のコールセンター向けAIサービスも2024年度90億円から2029年度313億円（年平均成長率31.7%）へ拡大する見込みです。ただし業界団体（CCAJ）の実態調査では、「AI活用による自動化・セルフサービス化」は重点テーマの上位でありながら、未着手の企業が最も多い項目の一つでもあります。必要性は分かっていても、どこから手を付けるかで止まっているのが現在地です。

ここで整理しておきたいのが「内製化」の意味です。内製化とは、システムをすべて自社開発することではありません。「自社の問い合わせ対応を、自社で運用・改善し続けられる状態を持つこと」を指します。外注に丸投げすると、ノウハウもナレッジも社外に蓄積され、改善のたびに費用と時間がかかります。逆に全部を自前開発するのも現実的ではありません。基盤はクラウド・SaaSを使いつつ、ナレッジ・業務設計・KPI運用を自社が握る「部分内製」が現実的な着地点です。

始める前に、入口でつまずきやすい3つの誤解を外しておきます。

• 「AIに全部任せられる」：実際には得意・不得意があり、苦手な領域は人に引き継ぐ設計が必要です
• 「ツールを入れれば問い合わせが減る」：ナレッジ整備と運用が伴わなければ減りません。導入直後の1〜2か月は減らないことも珍しくありません
• 「モデルが安い・無料だからタダ」：ナレッジ整備・運用・人の工数というコストが別にかかります

コールセンターAI活用の4つの手段と効果

問い合わせ対応は「受付（チャネル）→ 内容の特定 → 回答（調べて答える）→ 記録・後処理」という工程に分解できます。すべてを一度に自動化するのではなく、定型度の高い工程から機械に渡すのが現実的です。

自動化の手段は大きく4つに整理できます。

• FAQ自動化・チャットボット：テキストの一次対応・自己解決を担う
• ボイスボット：電話の自動応答・一次受付を担う
• RAG（検索拡張生成）による社内ナレッジ回答：社内FAQ・ヘルプデスクの回答生成
• オペレーター支援：通話要約・回答候補提示でACW（アフターコールワーク）を削減

このうち①〜③は「人の代わりに答える」方向、④は「人を支援する」方向です。自社の課題がどのチャネル・どちらの方向にあるかで、選ぶ手段が変わってきます。

実際の効果も国内事例の数値で確認できます。テキストの一次対応をAIに任せた事例では、メルカリのAIチャットボットで自己解決率が+17ポイント、コープ共済のLINEチャットボットで自己解決率が80%を超えました。高精度チャットボットの事例では正答率90%・1件あたり60円の削減で年間約6.5億円相当のコールコスト圧縮を試算した例もあります。

電話チャネルの自動化（ボイスボット）では、入電の20%以上を自動応答化し平均待ち時間を40%短縮した事例、待ち時間を45%短縮し夜間の自己解決件数が月3.1万件から8.9万件へ増加した事例が報告されています。24時間365日の自動受付が、混雑時間帯のあふれ呼や夜間の取りこぼしを回収します。日本のボイスボット市場も2023年度37億円から2029年度191億円へ伸びる見込みです。

「人の代わり」だけでなく「人を支援する」自動化も効果があります。北國銀行は音声認識と生成AIによる通話要約を導入し、後処理時間（ACW）を平均約5分から約3分30秒へ、3か月で約30%削減しました。従来オペレーターが聞き直しながら手入力していた応対履歴が自動生成され、確認・修正だけで済むようになった結果です。完全自動化より先に、まず「人の負担を軽くする支援」から内製化を始めるという選択肢もあります。

問い合わせはどう自動応答されるか｜RAGの6ステップ

自動化の核となるのがRAG（Retrieval-Augmented Generation・検索拡張生成）です。汎用AIは学習した知識から「それらしく」答えるため、社内ルールや最新の製品仕様には的外れになりやすい弱点があります。RAGは、答える前に自社の資料を検索し、その検索結果の範囲で回答を組み立てる仕組みです。

家電メーカーのサポート窓口を例に、具体フローを追ってみます。顧客が「型番KX-100の電源が入らない」と入力したとします。

1. 受付：チャットや電話の内容を文字化する
2. 意図特定：製品が「KX-100」、カテゴリが「故障」だと判定する
3. 検索：メタデータで製品KX-100・現行版に絞り込み、ベクトル検索とキーワード検索を組み合わせて該当マニュアル箇所を取得する
4. 回答生成：取得した箇所だけを根拠に対応手順を提示し、出典も併記する
5. 確信度判定：検索でのヒットが弱い、または内容が曖昧な場合は無理に回答しない
6. 有人引き継ぎ：確信度が低い場合や、解約・高額な相談は会話履歴ごとオペレーターへ転送する

この6ステップのうち、③検索と④回答生成が前段で紹介したRAGの核にあたります。前提として、検索対象となる参照資料が整っている必要があります（この整え方は後述します）。

自動化はいきなり対顧客から始めるより、まず社内から始めるのが現実的です。情シス・人事・経理など定型質問が多いバックオフィスの社内FAQでまず試すと、ナレッジ整備のやり方・ハルシネーション対策・有人エスカレーション・運用ルールという「型」を、リスクの低い社内環境で蓄積できます。家電メーカーの例なら、まず社内ヘルプデスク（経費・勤怠・社内システムの問い合わせ）でRAGを立ち上げ、同じパイプラインのまま参照ナレッジを製品マニュアル・FAQに差し替えて対顧客サポートへ横展開する、という進め方です。

内製化の現実解｜「借りる」と「握る」の切り分け

作り方を考えるうえで重要なのが、何を借りて何を自社で握るかの線引きです。

借りる（差別化源になりにくい基盤部分）

• 基盤LLM（APIを叩くだけ・将来乗り換え前提）
• RAGフレームワーク（検索と回答生成をつなぐ既製の枠組み）
• ベクトルDB（検索インデックスの置き場）
• 必要なら既製のチャットボット・ボイスボットSaaS（UI・電話接続）

握る（品質と競争優位を決める自社固有部分）

• ナレッジ整備（FAQ化・粒度・メタデータ・版管理）
• チャンク・検索設計
• プロンプト設計（トーン・禁止事項・「分からない時は答えない」）
• 回答評価
• 有人エスカレーション設計
• KPI運用と改善ループ

LLMやベクトルDBを乗り換えても、握る部分が社内に残っていれば資産が積み上がります。逆に、握るべき部分まで外部に委ねてしまうと、改善のたびに時間と費用がかかる構造から抜け出せません。

借りる側の具体的な選択肢も4レイヤーで整理しておきます。①基盤LLM APIは汎用API型（Claude・OpenAI GPT・Gemini）か、既存クラウド統合・監査ログを重視するならBedrock・Azure OpenAI。国内データ保管が要件なら、日本リージョンかつVPC内に閉じ、個人情報はゲートウェイでマスキングする構成が現実的です。②RAGフレームワークは、開発リソースが薄ければノーコードのDify、チューニングを自社で握りたければLlamaIndex（RAG主役）やLangChain（多段ロジック）。③ベクトルDBは、PoC・小規模で既存PostgreSQLがあればpgvector、コスト重視・中〜大規模ならQdrant、運用したくなければマネージドのPinecone。④UI・チャネルは、自前のWeb・LINE・Teams・Slackボットでも、既製SaaS（テキストならKARAKURI・PKSHA・Helpfeel・miibo、電話ならミライAI・Amazon Connect+Lex）でも構いません。まず既製SaaSでPoCを行い、効果が確認できたら自前RAGへ移行する二段構えが定石です。

自社にとって「内製と外注のどちらが向いているか」「費用感がどのくらいになるか」は、扱うデータ量やチーム体制によって変わります。この切り分けに迷う場合は、一度整理の壁打ちをするだけでも進め方が見えてきます。

コールセンターAIの内製化について相談したい方は、無料個別相談をご利用ください。

ナレッジ基盤をつくる8工程

「ナレッジ基盤をつくる」とは、具体的に何をすることを指すのでしょうか。家電メーカーの製品情報を例に、8つの工程で見ていきます。

1. 収集：散在するマニュアル・FAQ・仕様書に加え、コールセンターに大量にある過去応対ログ（通話記録・チャット履歴・問い合わせ履歴・対応メモ）をAPI連携やクローラで1か所に集めます。直近6〜12か月のログと現行版マニュアルが目安です
2. クリーニング：PDF・画像はOCRでテキスト化し、不要部分を除去、製品名の表記ゆれを統一します。通話ログは音声認識で文字化し、個人情報をマスキングします（マスキングの方法は後述）
3. チャンク分割：長いマニュアルを見出しと段落で意味のまとまり（日本語で400〜800字・10〜20%重ねる）に切ります
4. 埋め込み：各チャンクを日本語対応の埋め込みモデル（OpenAI text-embedding-3、multilingual-e5等）でベクトル化します
5. ベクトルDB化：ベクトルと本文を検索インデックス（pgvector・Qdrant・Pinecone等）に格納します
6. メタデータ付与：製品名・カテゴリ・版・更新日・文書種別（公式マニュアル・過去ログ由来）を各チャンクに付け、検索時に絞り込めるようにします
7. Q&Aペア化：よくある質問をQ&Aに整えます。マニュアルからはLLMで想定質問を生成し、過去ログからは「実際に来た質問」とオペレーターの回答を起こします
8. 版管理：仕様変更時は該当文書だけ再取り込みし、旧版は検索から除外します

このうち①と⑧には、過去ログの「継続取り込み」が組み込まれています。新しく溜まった過去ログを定期的に取り込み直し、古いFAQの更新と新規Q&Aの追加を続けるのが、次に説明する運用ループにつながります。

回答精度を直接左右するのは「Q&Aの粒度」と「検索設計」です。長文マニュアルをそのまま読ませるより、ユーザーが実際に聞く質問単位でQ&Aを切り出したほうが検索・要約が正確になります。1つのQ&Aは1論点に絞り、表現のゆれ（同義の別の言い方）も拾えるようにします。検索は、意味で探すベクトル検索だけでなく、型番・エラーコードなど語の一致が必要な質問のためにキーワード検索（BM25）を併用するハイブリッド検索が効きます。さらに候補の並べ替え（リランキング）を加えると、上位の的中率が上がります。

過去ログを資産に変える｜精度が運用で育つループ

ここが、今回いちばん伝えたい内容です。RAGは一度作って終わりではなく、応対のたびに溜まる新しいログを取り込み直して精度を上げ続けます。これがコールセンターの強み ー 過去の応対が大量にある ー を活かす要になります。

運用は5ステップのループで回します。

1. 記録：質問文・取得した参照文書とスコア・AIの回答・ユーザー評価（👍👎）・有人転送フラグをすべてログに残します
2. 抽出：「ゼロヒット（参照0件・確信度が低い）」「低評価（サムズダウン）」「有人にエスカレーションされた会話」を毎週レビューで拾います。FAQ分析でも0件ヒット・低解決率を重点的に見るのが定石です
3. FAQ化：オペレーターが実際に答えた回答を「誰が見ても分かる」Q&Aに書き直し、表現ゆれ（ユーザー語と社内用語）を足してナレッジに追加します。頻度は少なくても影響が大きい障害・クレーム系は優先度を上げます
4. 更新：追加・修正したQ&Aだけ再ベクトル化してインデックスを更新します。月次が目安ですが、立ち上げ初期の1〜3か月は週次〜隔週で集中的に行います
5. 回帰テスト：代表質問セット（最初は50〜100問。各設問に正解と根拠文書を紐付ける）を更新のたびに走らせ、正答率80%以上・前回比で悪化なしを満たさなければロールバックします

立ち上げ初期に精度を80%程度まで一気に引き上げ、その後はゆるやかに右肩上がりになっていくのが、このループを回した場合の一般的な精度カーブです。

個人情報を含む過去ログを安全に処理する｜ローカルAIの使いどころ

運用ループの入口にある「過去ログを取り込む」を、安全かつ低コストに行う手段としてローカルLLM（オンプレ・閉域で動かすAI）の使いどころを確認しておきます。

コールセンターの過去応対ログは件数が膨大で、氏名・電話番号・住所・契約情報などの個人情報を多く含むため、そのままクラウドに出しにくいケースが少なくありません。そこで、出せない情報の前処理をローカルで行います。代表的なモデルはLlama系・Qwen・Gemma・ELYZA（日本語特化で要約・分類に強い）です。

具体的な使い方は二段構えになります。

① ローカルで前処理する

• 個人情報マスキング：正規表現と辞書で電話番号・メールアドレス・住所を、固有表現抽出（GiNZA・spaCy・Presidio等）で氏名・組織名を検出し、ローカルLLMで文脈依存の取りこぼしを補完します。氏名は苗字だけ残す等のポリシーをコンプライアンス部門と合意しておきます
• 通話・チャットの要約
• Q&A抽出

② クラウドに出せると審査したデータだけをRAGに載せる

• マスキング済みデータだけをクラウドLLM＋RAGに載せ、対外回答の生成はクラウド・ローカルを使い分けます

コスト面では、大量のログ処理をクラウドAPIだけで回すとトークン課金がかさむため、ローカルでのバッチ前処理がコスト面で有利になる場合があります。LlamaIndexやLangChainは接続先をローカルLLMに切り替えられるため、同じパイプラインでクラウド版・ローカル版を使い分けられます。ただし高品質な日本語対話や長文推論はクラウドLLMが一歩リードしており、GPUコストとMLOps負荷も伴うため、「クラウドに出せない絶対要件がある領域」「大量推論でコスト有利な前処理」に絞って使うのが実務的です。

陥りやすい5つの落とし穴

導入では、決まったところでつまずきやすいポイントがあります。5つに整理して対策とセットで確認します。

① ハルシネーション（誤回答）
もっともらしい誤回答のことです。実際にカスタマーサポートで「存在しない割引制度や条件」を案内した事例があり、クレームや金銭的損失、法的リスクに直結します。対策は、回答範囲をFAQ・マニュアルに限定する（RAG）、自信がなければ「分からない」と返し有人へ引き継ぐ、重要・法令が絡む回答は人が必ず確認する、の3点です。

② FAQの陳腐化・メンテ負荷
導入後に効果測定や見直しをせず放置すると、古いルールの回答を返し続け、「使えないボット」と見なされて使われなくなります。運用担当を導入前に複数人体制で決めておくこと、答えられなかった質問・離脱した対話を分析してナレッジを補強すること、制度変更時の更新フローと責任者を明確にすることが対策です。

③ エスカレーション設計
回答できない場合のフローを決めずに「AIだけで完結」を狙うと、ユーザーが行き詰まり不満につながります。AIの得意（料金説明・住所変更などの定型手続き）と苦手（解約抑止・大規模障害・高額取引・クレーム）を切り分け、苦手はすぐ人へ回します。いつでも「人につなぐ」を選べるUIにし、AIとの会話履歴をオペレーターに引き継いで「最初から説明し直し」を防ぐことも重要です。

④ KPIなき運用・PoC止まり
効果指標を決めずに運用すると、本当に役立っているかが判断できず、改善も追加投資も進みません。件数が多く定型度の高い領域を選び、3か月で何をどこまで改善したら次フェーズへ進むかを先に定義しておきます。短期で見える成果が、経営層の理解と次の投資を引き出します。

⑤ 現場浸透
「AIで人を減らす」前提だと現場の協力が得られず、ツールも使われなくなります。重要なのは「AIで人を置き換える」のではなく「人を最も得意な領域に配置する」ことです。定型はAIに任せ、生まれた余力をVIP対応・難しいクレーム対応・VOC分析といった付加価値業務へ振り向けます。

まとめ

コールセンターの問い合わせ対応は、採用難とコストの面で「人だけで支える」限界に近づいており、AIによる自動化はほぼ必然になっています。手段はFAQ自動化・チャットボット・ボイスボット・オペレーター支援の4つで、問い合わせは「受付→意図特定→社内検索→回答生成→確信度判定→有人」というRAGのフローで自動応答されます。

作り方は「部分内製」が現実解です。基盤（LLM API・RAGフレームワーク・ベクトルDB・既製SaaS）は借り、ナレッジ・設計・運用は自社で握ります。中核となるナレッジ基盤は、収集からクリーニング・チャンク・埋め込み・ベクトルDB化・メタデータ・Q&Aペア化・版管理までの8工程で作ります。

そして最大のポイントは「育て方」です。コールセンターに大量にある過去応対ログを資産として扱い、個人情報を含むログはローカルAIでマスキング・要約・Q&A抽出して安全・低コストに前処理します。答えられなかった質問・低評価回答を毎週拾って月次でFAQ化・更新し、記録→週次で拾う→月次でFAQ化→回帰テストのループを回すことで、精度は運用とともに上がっていきます。

自己解決率・入電削減・ACW・CSAT・コストといったKPIを先に決め、件数が多く定型度の高い領域から小さく試すこと。そしてハルシネーション・陳腐化・エスカレーション・PoC止まり・現場浸透という5つの落とし穴を先に設計で避けること。これが、コールセンターのAI内製化を成功させる地図です。

ウェビナー資料（ホワイトペーパー）のダウンロード

本記事の内容をより詳しく解説したウェビナー資料を無料で配布しています。家電メーカーのサポート窓口を例にした具体フロー図や、ナレッジ基盤づくりの8工程の詳細も収録しています。

⇨ウェビナー資料のダウンロードはこちら

コールセンターAIの内製化は「リベルクラフト」へ

こんな方は、ぜひ一度ご相談ください。

• 問い合わせ対応をAIで自動化したいが、どこから始めるか決めかねている方
• 社内に散在するFAQ・マニュアルを、AIが答えに使える形に整えたい方
• チャットボットやRAGを試したが、精度や運用で止まってしまった方
• 内製と外注のどちらで進めるか、費用感も含めて整理したい方

リベルクラフトでは、社内ナレッジ検索をすぐ試せるデモ環境（ソクラグ）もご用意しています。まずは小さく試すところから、一緒に設計しませんか。

⇨リベルクラフトへの無料相談はこちら