カスタマーサポート チャットボット外注の費用相場｜発注前に整理する5要件

「来期予算でチャットボットを入れて CS 工数を 30% 削減したい」——経営からこう指示が降りてきたとき、稟議書の下書きを任された担当者がまず直面するのは、費用相場と選択肢の広さです。SaaS の資料をいくつか請求しても、月額数千円〜数十万円まで価格帯が広く、比較軸がわからないまま時間だけが過ぎていくケースが少なくありません。

さらに厄介なのは、カスタマーサポート（以下 CS）領域には他の業務では発生しない固有の要件があることです。有人オペレーターへの切替設計、CSAT（顧客満足度）や自己解決率といった KPI との連動、現場オペレーターがナレッジを更新し続ける運用体制——これらを発注要件から漏らすと、「導入したが現場が使わない」という最も避けたい失敗に直結します。

本記事では、CS 部門の責任者が稟議書を書く前に押さえるべき情報を、次の順で整理して解説します。

1. 外注の 3 つの選択肢（SaaS 導入・開発発注・CS 代行）と使い分け
2. CS 特化ならではの 4 つの要件（有人切替・多チャネル・KPI 連動・運用体制）
3. タイプ別の費用相場（初期・月額・追加費用）
4. 経営層に説明する ROI 試算の型
5. 発注前に自社で整理すべき 5 つの要件
6. ベンダー選定の評価軸と商談で確認すべき質問
7. 発注後によくある失敗と、契約書で防ぐ方法

読み終えた頃には、稟議書に盛り込む予算レンジ・選定理由・投資回収期間の骨格が組み立てられるはずです。

カスタマーサポート・チャットボット外注の全体像と3つの選択肢

「チャットボットを外注する」と聞くと、多くの方が「開発会社にフルスクラッチで作ってもらう」ことを思い浮かべます。しかし CS 領域では、外注の形は大きく 3 つに分かれます。この 3 択のどれが自社に合うかを最初に見極めることが、稟議書の選定理由を書く際の骨格になります。

カスタマーサポート業務でチャットボットが担える範囲

CS 向けチャットボットが担える主な業務は次の 4 つです。

• FAQ 応答: 「送料はいくらですか？」「返品方法を教えてください」など、定型的な問い合わせへの自動回答
• チケット振り分け: 問い合わせ内容を分類し、担当部署・担当者に自動で割り振る
• 有人切替（エスカレーション）: 解決できない問い合わせを、状況を引き継いだうえで有人オペレーターへ切り替える
• アンケート回収・満足度計測: 対応後の CSAT アンケート送付・回収

問い合わせ全件のうち、自己解決可能な定型問い合わせは 3〜5 割を占めるケースが一般的とされています。CS 特化の SaaS を提供する Karakuri の公開資料でも、AI チャットボット導入により定型問い合わせを大幅に自動化した事例が紹介されています（出典: KARAKURI chatbot 導入事例 など）。ここを自動化できれば、有人オペレーターは複雑な問い合わせに集中でき、SLA 短縮と工数削減を両立できます。

なお、近年は「チャットボット」と並んで「AI エージェント」という語も CS 領域で使われるようになりました。両者の違い（自律的なタスク実行の有無・想定される活用範囲）を整理してから発注選定に入りたい方は、チャットボットとAIエージェントの違いもあわせてご覧ください。

外注の3つの選択肢（SaaS導入・開発発注・CS代行）

本記事では主に (B) 開発ベンダーへの発注 を軸に解説しますが、「そもそも (A) SaaS で足りるのでは？」という判断ができないと、フルスクラッチ発注はほぼ間違いなくオーバースペックになります。以下の判定基準で自社の型を仮決めしましょう。

どの選択肢が自社に合うかを判定する5つの質問

次の 5 問に答えると、3 択のどれに寄せるべきかが見えてきます。

1. 既存 SaaS で対応できない独自要件があるか？（例: 基幹システムとリアルタイム連携・独自の会員 DB 参照）
2. チャットボットに投資できる予算は年間 300 万円以上か？
3. 社内に FAQ の棚卸し・ナレッジ更新を担当できるメンバーがいるか？
4. 問い合わせ月間件数は 3,000 件以上か？（少ないと ROI が出にくい）
5. 有人オペレーターを自社で抱えているか？（抱えていない場合は CS 代行との組み合わせが有力）

「1 が Yes」なら (B) 開発発注が視野に入ります。「1 が No + 3 が Yes」なら (A) SaaS で十分。「3 が No」なら (C) CS 代行の検討が現実的です。稟議書には「なぜこの選択肢を選んだか」を書く必要があるため、この判定結果を選定理由の一次資料として残しておくと後工程が楽になります。

カスタマーサポート特化のチャットボット外注ならではの要件

一般的なチャットボット外注ガイドは「シナリオ設計・LLM 選定・API 連携」を横並びで扱いますが、CS 領域ではそれだけでは足りません（チャットボット外注全般の費用構造・発注ステップはチャットボット開発 外注にまとめています）。CS 特化で発注要件に必ず含めるべき 4 つの要件を紹介します。

有人切替とエスカレーション設計の3パターン

CS チャットボットで最も失敗が多いのが「有人切替がうまくいかない」ことです。切替設計は次の 3 パターンに分けて整理しましょう。

• 閾値切替: 3 往復以上解決しない、AI の回答信頼度スコアが閾値を下回った場合に自動で有人へ切り替える
• キーワード切替: 「解約」「クレーム」「至急」など特定キーワードを検出した瞬間に有人切替
• 顧客要求切替: 顧客がボタン等で「オペレーターと話す」を選択したときに即切替

いずれのパターンでも、切替時点までの対話履歴を有人オペレーターに引き継ぐ設計が必須です。引き継ぎがないと顧客は同じ質問を繰り返す羽目になり、CSAT が急落します。「引き継ぎフォーマット」「保留メッセージ文言」「切替後の返信 SLA」まで発注要件に含めることが、後からの追加見積もりを防ぐポイントです。

マルチチャネル対応で失敗しないための基本設計

CS チャットボットは Web ウィジェットだけでなく、LINE 公式アカウント・メール・社内 Slack など複数チャネルで運用されるのが一般的です。ここで発注時に見落としがちな観点は次の 3 点です。

• ナレッジの一元管理: 各チャネルで別々の FAQ を持つと更新が破綻するため、ナレッジは 1 か所に集約し全チャネルが参照する設計を要件化する
• チャネル別 UI 差異の吸収: LINE はカルーセル UI、Web はサイドバー UI など表示形式が異なるため、コンポーネント抽象化を要件に含める
• 将来のチャネル追加コスト: 「初期は Web のみ、来年 LINE 追加予定」といったロードマップを共有し、追加時の見積もり条件を事前に握る

CS特化KPIに連動させる測定設計

導入後に「効果があったのか」を経営層に説明できるかどうかは、測定設計にかかっています。CS で重要な指標は次のとおりです。

• 自己解決率: チャットボットが有人切替なしに解決した問い合わせ割合
• CSAT（顧客満足度）: 対応後のアンケート結果
• AHT（平均応答時間 / Average Handle Time）: 対応開始から完了までの平均時間
• 一次解決率: 一度のセッションで解決した割合
• チャットボット経由の CV 貢献: EC 事業者などでは特に重要

これらの計測基盤（ダッシュボード・データ連携）を発注要件に含めないと、後から「効果測定できません」と言われて追加費用が発生します。「どの指標をどの粒度で計測するか」を要件書段階で明文化しておきましょう。

現場オペレーターが使いこなすための運用体制

導入後に最も多い失敗は「現場オペレーターがチャットボットを信頼しない」ことです。これを防ぐには、次の 3 つを発注時に押さえます。

• 誤回答フィードバックループ: オペレーターが誤回答を見つけたら 1 クリックで報告できる UI
• ナレッジ更新体制: 誰が・いつ・どの頻度で FAQ とシナリオを更新するかを明文化
• オペレーター向け説明会: ベンダー主導での導入時トレーニング・運用開始後の Q&A 会

これらの運用支援は「導入後の保守契約」に含まれるかどうかで大きく費用が変わります。保守契約の範囲に「ナレッジ更新支援」「オペレーター向けトレーニング」が入っているかを必ず確認しましょう。

カスタマーサポート・チャットボット外注の費用相場【2026年版】

ここからが本題です。稟議書に必要な費用レンジを、タイプ別に整理します。なお本セクションで扱う費用は、SaaS 導入・フルスクラッチ・CS 代行の 3 タイプすべてを横断した「外注」費用です。「開発」という語感からフルスクラッチのみをイメージしがちですが、3 タイプ全体の相場を把握することが選択肢比較の前提になります。

タイプ別費用相場（SaaS / フルスクラッチ / CS代行）

（費用レンジは各社公開資料および業界一般的な相場に基づく目安です。案件規模・要件によって上下します。参考: チャットボット導入費用の相場（Helpfeel）、AIチャットボット開発の外注費用（koromo） など）

稟議書では「まずは AI/RAG 型 SaaS でスタートし、効果が確認できたら次期予算でフルスクラッチ移行を検討」のような段階投資が経営層に通りやすい構造になります。

初期費用の内訳と、削れる項目・削れない項目

フルスクラッチ発注の場合、初期費用の内訳は概ね次のようになります。

削れないのは「要件定義」と「テスト」です。ここを削ると PoC 段階で必ず躓きます。逆に 「データ準備・FAQ 整備」は発注者側で対応すれば大幅にコストダウンできます（後述の「発注前に整理すべき5つの要件」で FAQ 棚卸しの進め方を解説します）。

月額運用費の内訳（LLM従量費の見積もり方）

月額費用は次の要素で構成されます。

• ホスティング・インフラ費: 数千円〜数万円（AWS / Azure 等）
• 保守・障害対応: 5〜20 万円
• ナレッジ更新支援: 5〜30 万円
• LLM API 従量費: 問い合わせ件数 × トークン数 × 単価

LLM 従量費の概算は、OpenAI の GPT-4o mini や Anthropic Claude Haiku などの安価モデルを使う場合、1 問い合わせあたり数円〜十数円程度が目安になります（モデル・応答長により変動）。月間 5,000 件の問い合わせなら、LLM 費だけで 5 万円前後になる計算です。稟議書では 「問い合わせ件数 × 単価」で LLM 費を試算する枠を必ず設けましょう。

追加費用の落とし穴（要件変更・チャネル追加・シナリオ拡張）

初期見積もりだけを見て稟議を通すと、運用開始後に追加費用が跳ねて後悔するパターンが多く発生しています。特に注意すべき追加費用は次の 4 つです。

• 要件変更: 「実装してみたら想定と違った」で発生。要件定義段階で PoC を必ず入れる
• チャネル追加: 「Web だけの契約」から「LINE 追加」で数十万円かかる
• シナリオ拡張: FAQ を 100 件追加するたびに追加見積もり
• LLM モデル更新: モデル変更時のチューニング再実施費用

これらは 契約書の「変更管理条項」と「単価表」 に明記されているかで扱いが変わります。契約前に必ず確認しましょう。

費用対効果を経営層に説明するROI試算の型

稟議書の最大の関門は「投資回収期間はどれくらいか」への回答です。CS 領域で経営層が納得しやすい ROI 試算の型を紹介します。

CS領域のROIで使う3指標と計算式

CS チャットボットの ROI は、次の 3 指標を軸に試算します。

1. 削減工数 × 時給

   • 計算式: 削減時間（時間/月）× オペレーター平均時給（円）× 12 ヶ月
   • 例: 月間 100 時間削減 × 3,000 円/時 × 12 ヶ月 = 360 万円/年の人件費削減

2. 自己解決率 × 問い合わせ件数

   • 計算式: 問い合わせ月間件数 × 自己解決率向上分（%）× 1 件あたり対応コスト
   • 例: 月間 5,000 件 × 自己解決率 30%pt 向上 × 500 円/件 = 月 75 万円 = 年 900 万円のコスト削減

3. 応答速度改善によるCSAT / 解約率影響

   • 計算式: CSAT 改善による解約率低下 × ARPU × 顧客数
   • 例: 解約率が 5% → 4% に改善、ARPU 5,000 円/月、顧客数 10,000 名 → 年 600 万円の解約防止効果

保守的・標準・攻めた3パターンの試算テンプレート

経営層から「試算根拠は？」と問われたときのために、3 パターンの試算を用意すると通りやすくなります。

稟議書には「標準」を主線とし、「保守的」を最低ラインとして併記するのが実務的です。「攻めた」試算は参考値扱いにとどめ、期待値を過度に上げないことが後の失敗リスクを下げます。

経営層から必ず聞かれる3質問と回答準備

稟議の場で経営層から必ず聞かれる 3 つの質問と、回答準備の要点を挙げておきます。

1. 「本当に自己解決率が上がるのか？」

   • 回答: PoC フェーズで実データを使った検証を行い、社内で 30〜60 日間の検証結果を提示できる状態にする
   • ベンダー選定時に「PoC 支援があるか」を必ず確認する

2. 「投資回収期間はどれくらいか？」

   • 回答: 上記 3 パターンの試算テーブルを提示し、「標準ケースで 1〜1.5 年」と明示する

3. 「失敗した場合の撤退コストは？」

   • 回答: SaaS の場合は月次解約可能。フルスクラッチの場合は契約書に「撤退条項」を含めることで最小化する
   • 「データ所有権が発注者にあること」を契約書で明記しておく

発注前に整理すべき5つの要件（RFP作成前のチェックリスト）

ベンダーとの初回打ち合わせ前に、発注者側で整理しておくべき情報が 5 つあります。これらを準備せずに商談に臨むと、要件定義フェーズだけで数百万円の追加費用が発生することもあります。

FAQ棚卸しの進め方（100件・カテゴリ分類・回答統一）

まず着手すべきは FAQ の棚卸しです。目安は 想定 FAQ 100 件です。

• 収集元: 過去 6 ヶ月分の問い合わせログ・オペレーターの記憶・既存 FAQ ページ
• カテゴリ分類: 5〜10 カテゴリに分ける（配送・返品・アカウント・料金・機能など）
• 回答統一: 同じ質問に複数の回答が存在しないか確認。オペレーター間で回答がぶれているものは統一する

この作業は発注者側でしかできません。「ベンダーにやってもらう」を選ぶと 30〜100 万円の追加費用と 1〜2 ヶ月の遅延が発生します。

有人切替ルール設計の型

有人切替のルールを事前に決めておきます。少なくとも次の 3 軸で整理しましょう。

• 時間軸: 何往復・何分で切り替えるか
• キーワード軸: どのキーワードを検知したら切り替えるか
• 顧客属性軸: 高額顧客・VIP 顧客は即座に有人へ切り替えるか

連携システム棚卸しと、連携コストが跳ねる典型パターン

チャットボットが参照・書き込みを行う社内システムを棚卸しします。

• 参照系: 会員 DB・在庫管理・注文履歴・契約情報
• 書き込み系: CRM・チケット管理・お問い合わせ履歴

特に注意すべきは「レガシー基幹システムとの連携」です。API が未整備の場合、連携開発だけで 200〜500 万円かかることもあります。連携要否を早期に判断し、必要な場合は初期見積もりに含めておきましょう。

KPI設計と測定基盤の準備

計測する指標と、その粒度・頻度を決めます。

• 指標: 自己解決率・CSAT・AHT・チャットボット経由 CV
• 粒度: 全体・カテゴリ別・チャネル別
• 頻度: 日次ダッシュボード + 週次レビュー + 月次経営報告
• 測定基盤: Google Analytics 4・BI ツール（Looker Studio 等）・自社データ基盤

現状値（Baseline）を導入前に測っておかないと、導入後の効果を証明できません。導入決定と同時に現状値の計測を開始しましょう。

運用体制の役割分担表

導入後の運用体制を「誰が・何を・いつ」の形で整理します。

この体制表がないと「導入したが誰も更新しない」失敗に直結します。稟議書には運用工数（人月換算）も併記しましょう。

開発会社・ベンダー選定の見極めポイント

要件が固まってきたら、ベンダー選定に入ります。CS 特化の観点で見るべき評価軸と、商談で確認すべき質問を紹介します。

ベンダー選定の5つの評価軸

• CS 領域の実績: B2C / B2B / 業界特有ドメイン（EC・SaaS・金融・製造など）での過去実績
• PoC 支援体制: PoC 実施の可否・PoC の期間と費用・PoC 結果に基づく本発注判断の柔軟性
• 本番運用支援: ナレッジ更新支援・LLM モデル更新対応・追加チャネル対応の伴走可否
• 有人切替設計の経験: LivePerson・Zendesk など主要な有人チャットツールとの連携経験
• 契約条件の柔軟性: 撤退条件・データ所有権・変更管理条項の明確さ

商談で確認すべき8質問リスト

初回商談では次の 8 問を必ず質問し、比較表を作れる状態にしましょう。

1. CS 領域での過去実績: 「弊社と似た規模・業種の導入事例を 2〜3 件教えてください」
2. PoC の内訳: 「PoC の期間・費用・成果物・判断基準は？」
3. 撤退条件: 「途中解約時の費用精算方法と、データ引き渡しの範囲は？」
4. 保守 SLA: 「障害対応の応答時間・復旧時間の SLA は？」
5. データ所有権: 「学習データ・対話ログ・チューニング結果の所有権はどちらに帰属しますか？」
6. LLM 変更時対応: 「LLM モデルを変更する場合の再チューニング費用・期間は？」
7. 追加費用条件: 「シナリオ追加・チャネル追加の単価表を見せてください」
8. 成功事例の詳細: 「導入後の自己解決率・CSAT 改善・回収期間の数値を教えてください」

見積もり比較で「同一条件」に揃えるためのチェック項目

複数ベンダーから見積もりを取る際、条件を揃えないと単純比較できません。次のチェックリストで見積もり依頼書を統一しましょう。

• 対象問い合わせカテゴリ数（例: 5 カテゴリ）
• 想定 FAQ 件数（例: 100 件）
• 対応チャネル（例: Web + LINE）
• 連携システム（例: CRM + 会員 DB）
• 想定月間問い合わせ件数（例: 5,000 件）
• KPI 測定要件（例: 自己解決率・CSAT・AHT の 3 指標）
• 保守範囲（例: ナレッジ更新支援を含む）
• PoC 有無（例: 2 ヶ月の PoC 実施）

発注後によくある失敗パターンと回避策

最後に、発注後によくある失敗を 5 パターン紹介します。いずれも 発注時の契約書・要件書で予防できるものです。

失敗パターン1: FAQ準備不足によるPoC停滞

• 典型例: FAQ が 20 件しか用意できず、PoC で回答精度が測れない
• 回避策: 発注前に FAQ 100 件を棚卸ししておく（先述の「発注前に整理すべき5つの要件」のとおり）。契約書の「発注者責任」欄に FAQ 準備の担当を明記する

失敗パターン2: 現場オペレーターへの説明不足で運用が形骸化

• 典型例: 導入後に現場オペレーターが「AI の回答は信用できない」と使わなくなる
• 回避策: ベンダー主導でのオペレーター向けトレーニング会を保守契約に含める。誤回答フィードバック UI を導入して、現場の意見が反映される仕組みを可視化する

失敗パターン3: ナレッジ更新体制が決まらず精度が劣化

• 典型例: 導入 3 ヶ月後から回答精度が下がり、有人切替が増える
• 回避策: 「誰が・週何回・どの粒度で」FAQ を更新するかを契約前に確定させる。ベンダーの保守契約に「ナレッジ更新支援」が含まれるか確認する

失敗パターン4: チャネル追加のたびに追加見積もりが発生

• 典型例: 「Web だけの契約」から「LINE 追加」で 80 万円の追加見積もりが来る
• 回避策: 契約書に「チャネル追加時の単価表」を含める。初期契約時に将来のチャネル追加ロードマップをベンダーと共有する

失敗パターン5: LLMモデル変更時の再チューニング費用が想定外

• 典型例: 使用中の LLM がバージョンアップし、再チューニングに 200 万円かかると言われる
• 回避策: 契約書に「LLM モデル変更時の対応条件」を明記する。データ所有権を発注者に確保し、必要に応じて他モデルへ移行できる余地を残す

次のアクション

ここまで読み進めていただいた方は、稟議書に必要な情報（3 択の選定理由・費用レンジ・ROI 試算・発注前準備・ベンダー質問リスト）の骨格を掴めているはずです。次のステップとして、社内で FAQ 棚卸しと現状値計測を開始することをおすすめします。ベンダー選定と並行して進めることで、発注後の追加費用と遅延を大幅に削減できます。

CS 領域のチャットボット外注を含む、外部人材・開発リソース活用の要件整理に役立つお役立ち資料をご用意しています。稟議書のたたき台や発注前チェックリストとしてご活用ください。詳しくはお役立ち資料一覧をご覧ください。

CS チャットボット導入・外注の具体的な要件整理でお困りの方は、お問い合わせフォームからご相談ください。要件が固まっていない段階からのご相談にも対応しています。