メールでの問い合わせ対応に、他社のSaaSを使っていたものの、月額費用が積み重なる、欲しい機能を追加できない、という状況になることがあります。そこで、SaaSが担っていた機能をFirebaseで自社開発に置き換えた事例をもとに、進め方と工夫したポイントを整理します。
置き換えを考えた理由
もともと使っていたSaaSは、問い合わせ内容の振り分けには使えるものの、次のような点で限界がありました。
- 月額費用がかかり続ける
- 自社の業務フローに合わせた拡張ができない
- AIによる自動応答のような機能を追加したくても、SaaS側の仕様に縛られる
「SaaS費用を削減したい」と「AIによる自動応答に向けて自社で拡張したい」という2つの目的を同時に満たすため、機能を自社開発に置き換えることにしました。
仕組みの概要
開発した仕組みは、次のような構成です。
| 機能 | 内容 |
|---|---|
| 受信 | メールでの問い合わせを取り込む |
| 分類 | RAG（検索を組み合わせたAI生成）でカテゴリを分類 |
| 回答例の表示 | 分類結果に応じて、過去の回答例を提示する |
| 担当者の割り振り | カテゴリに応じて担当者へ自動で振り分ける |
| 精度向上 | 分類結果に対するYES/NOのフィードバックを記録する |
土台となるシステムはFirebaseで構築しています。SaaSを使っていたときと同じ「分類して、担当者に振る」という基本機能はそのまま再現しつつ、AIによる回答例の提示という新しい機能を追加しました。
精度はどれくらいか、どう向上させているか
分類の精度は、現時点でおおむね8割程度です。100%を目指すのではなく、次のような仕組みで精度を上げていく方針にしています。
- 分類結果に対して、担当者がYES/NOで合っているかを記録する
- 間違っていた分類のパターンを蓄積し、ルールやプロンプトを見直す
- 「分類が合っているか」と「回答例が役に立ったか」を分けて評価する
最初から完璧な分類を目指すと開発期間が延びてしまうため、「8割合っていれば運用が回る」という前提で先にリリースし、フィードバックをもとに継続的に精度を上げる進め方を取っています。
もう一つの目的：新人でも対応できる仕組みにする
このツールを作った目的は、コスト削減だけではありません。問い合わせ対応の経験が浅い担当者でも、ある程度の対応ができるようにすることも狙っています。
- 分類結果と一緒に、過去の回答例を表示する
- 担当者は、回答例を参考にしながら自分の言葉で仕上げる
- 「何も分からない状態から書く」のではなく、「参考例から調整する」状態を作る
回答例を表示するUI部分の改善は、AIの分類精度そのものよりも、担当者の学習コストを下げる効果として重要だと感じています。AIの精度が8割でも、担当者が「違っていたら自分で判断して直す」という前提を持っていれば、運用上は十分機能します。
自社開発に置き換えるときに考えたこと
SaaSを自社開発に置き換える判断は、どの業務でも有効というわけではありません。次のような観点で検討しました。
- 月額費用が、開発・保守コストを上回りそうか
- 自社の業務フローに合わせた拡張を、今後も続けたいか
- SaaS側の仕様変更や終了リスクに依存したくないか
- 自社にAIコーディングで開発・保守できる体制があるか
「全部のSaaSを置き換えるべき」ではなく、拡張したい機能がある、費用が見合わなくなってきた、という条件がそろったときに検討する判断軸として持っておくとよいです。
まとめ
問い合わせ対応のSaaSを自社開発に置き換える場合、次の視点が役立ちます。
- コスト削減と機能拡張、2つの目的を整理してから着手する
- 分類精度は100%を目指さず、フィードバックで継続的に上げる前提で設計する
- AIの分類だけでなく、担当者が使いやすいUIまで含めて設計すると、学習コスト削減につながる
- 置き換えるかどうかは、費用・拡張性・保守体制の3点で判断する
問い合わせ対応・業務自動化の相談
local-navi.jpでは、問い合わせ対応の自動分類、SaaSからの自社開発への置き換えについて相談を受けています。
まずはLINEからの無料相談、または1回1万円程度のオンラインヒアリングから、現在の業務とSaaS費用感を整理することも可能です。
