AIカスタマーサポート主要5社の見分け方 | 挿し込み位置と人の戻し先で読む

AIカスタマーサポート主要5社（Sierra AI、Intercom、Ada、Forethought、Kustomer）を機能一覧で並べても、違いはほとんど見えてきません。回答品質、多言語対応、ノーコード編集、handoff機能。どの公式ページを開いても、似たような項目が同じように「できます」と書かれています。

私はこの5社を選ぶ判断は、機能比較ではなく2つの問いに置き換えた方が早いと考えています。AIをどこに挿すか（会話の面を専用に新設するのか、既存の運用面に内蔵するのか、それとも既存のヘルプデスクやCRMの上に重ねるのか)と、AIが間違えたときに誰が引き取るかです。この2点は各社のアーキテクチャに固定されていて、契約したあとではほぼ動かせません。逆に言えば、機能の細部は今後半年でどの会社も変わります。

断っておくと、私はこの5社を本番環境で並行運用して比較した経験を持っているわけではありません。根拠にしているのは各社の公式ドキュメント・導入事例と、このブログでSierra・Intercom・Ada・Forethought・Kustomerそれぞれのdeep-dive記事を書く過程で読み比べた一次情報です。

実際に読み比べて一番差を感じたのは、機能ページの文言ではなく、handoffやIntegrations、Trust関連のドキュメントの厚みでした。SierraはTrust and reliabilityページでsecure integrationやsupervisor models、PII maskingまで踏み込んで説明し、Agent Studioではsimulationとregression testingを検証の中心に据えています。Intercomも同様に、Fin 3のProceduresとSimulationsという機能名で、handoffと検証の設計思想を具体的に開示していました。ForethoughtはIntegrationsページで70以上の連携先を明示し、Discover/Solve/Triage/QA/Copilotという役割分担を細かく説明しています。一方でAdaとKustomerのdeep-diveは、公式の機能ドキュメントよりも創業者インタビューや導入事例、報道記事から組み立てた部分が多く、handoffの条件をどこまで運用画面で明文化しているかという一次情報は、他の3社ほど厚くありませんでした。この厚みの差自体が、公式ページだけで判断できる会社と、導入事例や営業資料まで当たる必要がある会社を分けるシグナルだと考えています。

なお、価格や機能の細部は変わりやすいので、最終確認は各社の公式ページで行ってください。

---

前提: 何を見れば選定は決まるのか

挿し込み位置

5社は回答の賢さで競っているように見えて、実際にはAIを製品のどこに置くかで分かれています。本記事ではこれを挿し込み位置と呼びます。挿し込み位置とは、AIの意思決定点をどの面（会話専用の新設面、既存の運用面、既存のヘルプデスク、CRMのデータモデル)に置くかという設計上の選択です。

5社の挿し込み位置は、次の5パターンに分かれます。

• 会話の面を専用に新設する(Sierra AI)
• 既存の会話運用面に内蔵する(Intercom)
• 運用担当が自走できる面を作る(Ada)
• 既存のヘルプデスクの上に重ねる(Forethought)
• CRMのデータモデル側に置く(Kustomer)

挿し込み位置を後から変えるのは、事実上ベンダーを乗り換えるのと同じコストがかかります。

人の戻し先

もう一つの軸は人の戻し先です。AIが誤答したり、想定外の問い合わせに当たったとき、誰が、どの画面で引き取り、何を最終的に確定させるかという運用上の受け皿を指します。handoffという機能名はどの製品ページにも書いてありますが、それは「渡すボタンがある」という話でしかありません。知りたいのは、渡した先で誰が何を直すか、という一段具体的な運用設計です。

この軸は、以前BPOの業務分解を整理したときに使った「AIは草案・一次判定を出し、人が最終の閉じ方を持つ」という枠組みを、そのままカスタマーサポート選定に持ち込んだものです。

なぜこの2つで決まるのか

AIの回答そのものの品質差は、この先さらに縮んでいくのではないかと私は見ています。各社ともLLMの進歩をそのまま取り込めるため、回答生成の巧拙は差別化の軸として長くは持ちません。一方で、挿し込み位置と人の戻し先は製品のアーキテクチャに固定されていて、導入後に組み替えるのは簡単ではありません。

SaaSpocalypseの整理で見たように、Intercomはすでに「席数」ではなく「解決件数」でFinの価格を作っています。課金の単位が変わるということは、それだけ挿し込み位置と人の戻し先の設計が製品の中心に来ているということです。だから選定で機能一覧を見比べるのはほぼ時間の無駄で、決めるべきはこの2点だと私は考えています。

---

全体像: 挿し込み位置で5社を並べる

ポジショニングマップ

この並びは、価格や機能の細部ではなく、後から変えにくい設計の分岐です。各社の詳細を見ていきます。

---

1. Sierra AI: 会話の面を専用に新設する

Sierra AIは、企業ごとのブランド体験や運用ルールに合わせて会話フローを深く設計したいチーム向けの会話型AIエージェントです。FAQ回答だけでなく、返品処理、サブスクリプション更新、注文管理のような業務アクションまでAIに担わせる設計を前提にしている点が、他の4社との違いです。既存の会話面に足すのではなく、AI専用の会話面を新しく作るという発想なので、消費者向けブランドや大規模な運用フローを持つ企業で検討されやすくなります。

“

Bret Taylorの言葉

“

"Every company will want to have its own AI agent, and will devote as much attention and effort to their AI agents as they do building their websites and mobile apps."

「すべての企業が独自のAIエージェントを持ちたいと思うようになり、ウェブサイトやモバイルアプリを構築するのと同じくらいの注意と労力をAIエージェントに注ぐようになるでしょう。」

— Bret Taylor, CEO

導入前に見ておきたいのは次の3点です。

• 実際にどこまで業務アクションを許可できるか
• ブランドトーンや例外処理をどの程度細かく設計できるか
• 自社と近い業種の導入事例が公開されているか

創業経緯と、更新耐性・outcome境界という評価軸の詳細はSierra AIは「賢いbot」ではなく「更新耐性」で評価すべき理由にまとめています。

---

2. Intercom: 既存の会話運用面に内蔵する

Intercomは、Inbox、Help Center、AIエージェントを同じ運用面で扱えるカスタマーサービスプラットフォームです。SaaS・テック企業や、プロダクト主導でサポート体験を整えたいチームと相性がいいのは、AIを別の画面に足すのではなく、担当者が普段見ているInboxの中にAI(Fin)を組み込んでいるからです。

確認しておきたいのは次の3点です。

• Finの回答品質、handoff設計、ナレッジベースとの連動
• Inbox・Help CenterとAIをどこまで同じ運用面で扱えるか
• プロダクト内メッセージングやOutbound施策まで一本化できるか

Finのper-outcome課金や、suite/layer戦略の詳細はIntercomは「払う相手」か「差す部品」かで整理しています。

---

3. Ada: 運用担当が自走できる面を作る

Adaは、ノーコードでAIエージェント運用を始めたいチーム向けのカスタマーサービス自動化プラットフォームです。エンジニアを介さずに運用担当がビルダー画面で改善サイクルを回せる設計になっているため、多言語運用やFAQ整理を運用側で主体的に回したいチームで検討されやすくなります。

確認しておきたいのは次の2点です。

• エンジニア不在でも運用改善を回せるか
• 多言語の品質管理をどこまで運用面で支えられるか

運用設計の詳細はAdaをどう読むかにまとめています。

---

4. Forethought: 既存ヘルプデスクの上に重ねる

Forethoughtは、既存ヘルプデスクの上にAIエージェント、チケット分類、エージェント支援を重ねたいチーム向けの製品群を持つ会社です。ZendeskやSalesforce系の運用をそのまま残しながらAIレイヤーだけを足せる設計なので、既存スタックを壊したくないチームに向いています。

確認しておきたいのは次の2点です。

• 既存のヘルプデスク、CRM、ITSMとどう連携するか(Integrationsのページを見る)
• 顧客向けAIとエージェント支援を段階的に導入できるか

Autoflowsとの統合を含む詳細はForethoughtとはで扱っています。

---

5. Kustomer: CRMのデータモデル側に置く

Kustomerは「顧客中心」のカスタマーサービスCRMプラットフォームです。Zendesk(チケット中心)やIntercom(会話中心)とは異なり、全インタラクションを単一タイムラインで管理するアプローチを取っています。AIエージェントは会話面の機能ではなく、このタイムラインというCRMのデータモデルの上に載る形で提供されます。

確認しておきたいのは、顧客タイムラインと既存CRM/ECデータをどう統合するか、そしてAIレイヤーを顧客向けと担当者向けの両方でどう使い分けられるかです。

詳細はKustomerとはにまとめています。

---

人の戻し先で並べ直す

同じ5社を、挿し込み位置ではなく人の戻し先で並べ直すと、別の顔が見えてきます。

人の戻し先を実際に設計または観察した経験は、正直に言うとこの記事の中で最も薄い部分です。手がかりにできるのは、以前BPOの業務分解で整理した例外処理の見方です。あの記事では、例外キューは「困ったら人へ送る」だけでは足りず、どの条件で止めるか、どの担当へ渡すか、再投入の入口をどうするかまで決めておく必要があると整理しました。この見方をカスタマーサポートの5社に当てはめると、戻し先の違いは「誰が対応するか」ではなく、「例外をどの条件で止め、どの画面で誰が最終確定させるか」という設計の違いとして読めるはずだと私は考えています。

同じ原則を敷衍するなら、選定の初期段階で機能デモより先に、この戻し先の画面を実際に触らせてもらうべきだと私は考えています。デモで見せられるのはAIがうまく答える場面がほとんどで、渡した先で人がどれだけ迷わず閉じられるかは、実際の画面を触らないとわからないからです。

挿し込み位置で見た並びと、人の戻し先で見た並びは、ほぼ同じ順序になります。AIをどこに置くかを決めた瞬間に、誰が拾うかもほとんど決まっているということです。

---

日本語運用で確認したいこと

日本語の問い合わせでは、敬語、曖昧表現、配送や請求まわりの固有語彙、有人対応への切り替え条件が、そのまま品質差になります。5社とも「日本語対応」を謳っていますが、この対応の中身は、言語モデルが日本語を話せるかではなく、日本語の運用フロー(FAQのトーン、有人切り替えの条件、監査ログの言語)をどこまで作り込めるかで決まります。

公式ドキュメントやデモだけでこの差を確認するのは難しいので、実際に一つの問い合わせフローを日本語で試し、有人切り替えが起きた瞬間に何が起きるかを見るのが、最も早い検証方法だと思います。

---

結び: これはベンダー比較ではなく、運用モデルの選択

ここまで5社を挿し込み位置と人の戻し先という2つの軸で並べ直すと、見えてくるのは「どのAIが賢いか」ではなく「自社の運用をどの形に合わせるか」という選択です。機能比較表がこの選定にほとんど効かないのは、そもそも機能比較表が答えようとしている問いが、実務で決めるべき問いとずれているからだと私は考えています。

検証の順序をこう組み立てる理由も、ここで説明しておきます。まず1つのユースケースだけを選ぶべきなのは、Sierraのdeep-diveで整理したBuild/Optimizeの層にあるように、simulationやregression testingはテストする対象であるknowledgeやpolicyそのものが最新でなければ意味を持たないからです。対象を絞らないまま検証を始めると、テストの土台がぐらついていること自体に気づけません。次に人の戻し先を先に決めるべきなのは、この記事の再ソートで見た通り、挿し込み位置を決めた時点でおおよその戻し先も決まってしまい、後から戻し先だけを設計し直す余地が小さいからです。最後に更新耐性を確認する理由は、知識やSOPが変わったときにagentを壊さずに更新し続けられるかどうかが、会話の自然さよりよほど長く効く軸だと私は見ているからです。

この考え方を踏まえて、もし私がこの5社のどれかを検証するとしたら、順序はこうします。まず1つのユースケースを選ぶ(全業務を一度に置き換えようとしない)。次にそのユースケースの人の戻し先を先に決める(AIを入れてから決めるのではなく、入れる前に決める)。最後に、その更新耐性の考え方を使って、知識やSOPが変わったときにこの設定がどれだけ壊れずに保てるかを確認します。

この順序も、5社を並行運用した結果からではなく、公式情報を読み比べた範囲での暫定的な判断です。実際に運用して覆ることがあれば、この記事も書き直します。