SLMをカスタマーサポートに使う方法とコスト比較

結論：カスタマーサポートへのSLM導入は範囲を絞れば費用対効果が出やすい

カスタマーサポートへのSLM活用は、汎用的な用途の中で費用対効果が計算しやすい領域だ。問い合わせの種類・件数・オペレーター稼働時間が数値化されているため、自動化の効果を金額に換算できる。ただし全件自動化を目指すのは誤りで、SLMが扱える問い合わせの種類を適切に絞ることが成功の条件になる。

本記事では、2つの導入方式の選び方、SLMが向く問い合わせの種類の見分け方、LLMとのコスト比較の考え方、品質管理の設計、導入ステップ、効果の目安を順に解説する。

カスタマーサポートに使う2つの方式

SLMをカスタマーサポートに使う方式は大きく2つに分かれる。どちらを選ぶかは問い合わせ内容の複雑さと品質管理の優先度によって変わる。

方式1：完全自動応答は、ユーザーの問い合わせをSLMが受け取り、そのまま回答を返す方式だ。オペレーターは介在しない。FAQの回答・商品ページへの誘導・手続きの案内など、答えが一つに決まる問い合わせに適している。24時間対応できる点と、オペレーターの対応時間を削減できる点がメリットだ。一方で、SLMが誤った回答を返してもそれが顧客に届くため、回答品質の管理が最重要の課題になる。

方式2：オペレーター支援は、ユーザーの問い合わせをオペレーターが受け取り、SLMがオペレーターに回答候補・関連情報・過去の類似事例を提示する方式だ。最終的な送信はオペレーターが判断する。完全自動化より誤回答のリスクが低く、複雑な問い合わせにも対応できる。オペレーターが回答を考える時間を短縮できるため、1人あたりの対応件数が増える。まずSLMをサポート業務に導入する場合の安全な出発点として、この方式から始める企業が多い。

両方を組み合わせるハイブリッド構成も現実的だ。定型FAQは自動応答にして、複雑な問い合わせや自信度が低い場合はオペレーター支援に切り替える設計だ。この場合、どの条件でエスカレーションするかの閾値設定が重要になる。

SLMが向く問い合わせと向かない問い合わせ

SLMで自動化しようとして失敗する原因の一つは、向いていない問い合わせに対して自動応答を適用しようとすることだ。

SLMが安定して対応できるのは、答えが文書に書いてある定型FAQ型の問い合わせだ。「営業時間は何時までですか」「返品の手順を教えてください」「○○の機能はありますか」といった問い合わせは、正解がFAQページや規約に明記されている。RAGでその文書を参照させれば、SLMは安定した回答を返しやすい。

商品情報の照会も向いている。型番・価格・スペック・在庫状況など、データベースから引いてきた事実を伝える問い合わせだ。SLMを使って回答文を組み立てつつ、データは確定したシステムから引く構成にすると精度が上がる。

手続き案内も向く。解約・変更・申請などの手順は決まったフローがあるため、SLMが適切な手順を案内しやすい。

一方で、感情的な不満やクレームへの対応・複数の要因が絡む複雑な交渉・個別の事情を考慮した例外対応・法的な判断が必要な問い合わせは、SLMには向かない。これらはオペレーターが対応する問い合わせとして明確に分けておく設計が必要だ。

LLMとのコスト比較：月間1万件の問い合わせを想定した試算の考え方

月間1万件の問い合わせを想定した場合の、クラウドLLM APIとSLMオンプレミスのコスト構造の違いを整理する。なお具体的な金額はAPIの料金体系・文書量・インフラ仕様によって大きく変わるため、参考の考え方として読んでほしい。最新の価格は各プロバイダーで確認が必要だ。

クラウドLLM APIのコスト構造は変動費型だ。1回の問い合わせで使用するトークン数（入力：問い合わせ文＋FAQの参照文書、出力：回答文）によって費用が決まる。1問い合わせあたり入力1,000トークン・出力200トークンと仮定すると、月間1万件で入力1,000万トークン・出力200万トークンの合計になる。GPT-4oクラスのAPIの場合、1Mトークンあたり数ドルの費用がかかる。月に数万円〜数十万円規模になるケースが多いが、問い合わせが増えると費用も線形に上がる。

SLMオンプレミスのコスト構造は固定費型だ。サーバー費用（クラウドVMかオンプレミスのサーバー）と運用コストが主な費用で、問い合わせ件数が増えてもコストは変わらない。月間1万件程度であれば、クラウドVM上でSLMを動かす場合でも月額数万円以下の計算コストで対応できることが多い。ただし初期の構築費用（FAQデータの整備・RAG構成の開発・テスト）が数十万〜数百万円のオーダーで必要だ。

月間件数が少ない段階ではLLM APIの方がコストが低い。件数が増えるほどSLMオンプレミスが有利になる損益分岐点がある。おおよそ月間数千〜1万件を超えると、固定費型のSLMが有利になる計算になることが多い。正確な試算は自社の問い合わせ量・内容・インフラ条件で行う必要がある。

SLM利用のコスト全般についてはSLMとAPIコストの比較記事も参考にしてほしい。

品質管理の方法：ハルシネーション対策とエスカレーション設計

カスタマーサポートで生成AIを使う際に最も慎重に設計すべきなのが品質管理だ。誤った情報を顧客に伝えると、信頼の損失と対応コストが増える。

ハルシネーション対策の基本は、SLMが参照できる情報源を文書に限定することだ。完全な自由生成ではなく、RAGで検索した社内FAQや商品情報のみを根拠として回答を生成させる。プロンプトに「提供された文書に書かれていないことは答えないでください。分からない場合は『担当者に確認して改めてご連絡します』と答えてください」という制約を明記する。

加えて、SLMに自信度スコアを出力させる方法がある。回答の自信度が閾値を下回る場合は自動応答せず、オペレーターに転送する設計だ。SLMに「この回答にどの程度確信がありますか。1〜5で評価してください」と出力させ、3以下の場合はエスカレーションするような実装が一例だ。

エスカレーション設計はシステムの品質を保つための最重要の仕組みだ。次のような条件でオペレーターへの転送を自動実行する設計が基本になる。SLMの自信度スコアが閾値以下、問い合わせにクレーム・怒り・返金要求などのキーワードが含まれる、同じユーザーが同一内容を2回以上問い合わせている、SLMが3回以上回答を試みても解決しない。

定期的な回答品質の監査も必要だ。週または月単位でサンプリングして、SLMが返した回答が正確だったかをオペレーターがチェックする。誤答のパターンが見つかったら、対象のFAQ文書を修正するかプロンプトを調整する。この監査サイクルを回すことで、システムの精度が継続的に向上する。

導入の3ステップ

ステップ1：FAQ整備

まず問い合わせログを分析して、よく来る問い合わせのカテゴリと頻度を把握する。月間1万件の問い合わせがあっても、上位20種類の質問タイプで全体の60〜70%を占めることが多い。この上位の問い合わせに対応するFAQ文書を正確に整備することが、システムの精度を決める最も重要な作業だ。

FAQの整備で重要なのは、実際に使われている言葉で書くことだ。顧客は「解約方法」と聞く場合もあれば「やめたい」「止めたい」という言葉を使う場合もある。両方を網羅した表記にするか、同義語をシステム側で処理する設計が必要だ。

ステップ2：SLM+RAG構築

整備したFAQ文書をベクトル化してベクトルDBに格納し、SLMをRAGの推論エンジンとして接続する。SLM+RAGの具体的な実装についてはSLMとRAGを組み合わせた社内検索の記事で詳しく説明している。カスタマーサポート向けの調整点として、プロンプトに「丁寧で簡潔な敬語で回答する」「200字以内で答える」といった制約を加える。

エスカレーションのロジックとインターフェースも合わせて設計する。既存のチャットシステムへの組み込みか、新たなチャットUIの構築かを決め、ユーザー側の画面とオペレーター管理画面を作る。

ステップ3：テスト運用

最初の1〜2ヵ月は限定的な範囲でテスト運用する。全問い合わせへの展開ではなく、特定の問い合わせカテゴリのみに適用するか、チャットの一部窓口だけで試す。テスト期間中は全回答をオペレーターが確認し、SLMの誤答をログに記録する。一定の誤答率（5%以下など、自社基準で設定する）を下回ったら本番展開に進む判断ができる。

実際の効果の目安

運用例として参考になる数値を示す。これらは業種・問い合わせ内容・運用設計によって変わるため、目安として使ってほしい。

応答時間は、FAQへの回答であれば2〜5秒での返答が目安だ。クラウドAPIのレスポンスタイムと変わらないか、SLMをローカルやプライベートネットワークで動かす場合は短縮できる。ユーザーが「すぐに答えが返ってきた」と感じる閾値は3秒以内とされており、RAGの検索+SLMの生成全体でこの範囲に収まる設計が目標になる。

自動対応率の現実的な目安は、全問い合わせの30〜50%程度だ。定型FAQに絞っても半数以下になることが多い。50%を超えるには、問い合わせの種類が限定的で、FAQがよく整備されているサービスである必要がある。最初から高い自動化率を目標にせず、品質を保てる範囲で少しずつ対応範囲を広げる方が長続きする運用になる。

オペレーター稼働への影響は、自動化される問い合わせ分の工数削減に加え、オペレーター支援型を採用している場合の1件あたりの対応時間の短縮にもある。回答候補が即座に提示されることで、オペレーターが回答文を考える時間が1件あたり2〜4分削減されるという事例がある。1日100件対応するオペレーターなら、1日あたり最大400分の作業時間に相当する。

生成AIの導入コストと効果の評価方法全般については生成AI導入の費用対効果を解説した記事が参考になる。

まとめ

SLMをカスタマーサポートに導入する場合、まずオペレーター支援型から始め、定型FAQに絞った完全自動応答に段階的に広げる進め方がリスクが低い。コスト面では、月間件数が多くなるほどSLMオンプレミスがAPIより有利になる構造がある。最も重要なのは品質管理の設計で、FAQをRAGで参照させる構成・エスカレーション設計・定期監査のサイクルを最初から組み込んでおくことが、長期的に使えるシステムの条件になる。