AIが700人分の人手を削減、Klarnaは「品質が下がった」と言う
- 2026年6月前後、Salesforceが約36億ドルでFinを買収、NICEがCognigyを、ZendeskがForethoughtを買収し、Sierraの評価額は100億ドルに。AIカスタマーサポートが一斉に企業の中核予算へ入り込んだ。
- Klarnaは2024年2月、AIカスタマーサポートが問い合わせの3分の2をカバーし、フルタイム700人分に相当すると公表。約1年後、CEOはコストを過度に重視したことが「品質低下」を招いたと認めた。
- アリババによる256万件の対話を対象とした4週間のランダム実験では、AIが問題の識別を8.2%速め、その場の満足度を1.2%高めた一方、3日以内に同じ問題で再び連絡する確率は統計上ほぼ変わらなかった。
- 既存の主要4指標（自動解決率／処理時間／人へのエスカレーション率／1件あたりコスト）はいずれも企業目線でコスト削減を測るもので、自信たっぷりの誤答ですら、すべての指標を良く見せられる。
- 著者のLuciusは新たなフレームワークを提唱する——サポート品質 = 解決率 × コンテキスト × 信頼 × 学習 × 体験。コスト削減ではなくユーザーの全旅程を中核の指標に据える。
1か月で4件の大型買収、AIカスタマーサポートが突如メイン市場に
2026年6月15日、Salesforceが約36億ドルでAIカスタマーサポート企業Finの買収を発表。同じ時期に、NICEがCognigyを、ZendeskがForethoughtを買収し、Sierraは新たな資金調達を完了して評価額は100億ドルに達した。
Klarna：指標は全部グリーン、1年後にCEOは「我々は間違えた」と語る
旧来の評価表は、かつて第一世代のAIカスタマーサポートに見事な成績表を付けた。
2024年2月、KlarnaはAIアシスタント稼働初月で230万件の対話を処理し、サポート問い合わせの約3分の2をカバー、作業量はフルタイム700人分に相当すると発表した。平均解決時間は11分から2分に短縮し、同社は同年の利益がこれにより約4000万ドル改善すると見込んだ。サポート予算を預かる人間からすれば、文句のつけようがない数字だ。
- 2.3M 初月の対話量
- ≈700 フルタイム換算の人数
- 11→2 分、解決時間
- $40M 見込み利益改善（自社推計）
会社が「コストを過度に重視」した結果、「lower quality（より低い品質）」に陥った。CEOのSebastian Siemiatkowskiは、改めて人によるサポートを重視するようになった。
この2つの主張は同時に成り立ち、矛盾しない。AIは確かにより多くの対話を処理し、確かにコストを押し下げた。問題は「成功」という言葉をどう定義するかにある。
いまの評価表は、会社がいくら節約できたかしか測っていない
自動解決率、平均処理時間、人へのエスカレーション率、1対話あたりコスト——この主要4指標はいずれも会社側から数値化したものだ。待ち行列がどれだけ短くなったか、人手がどれだけチケットを避けられたかは教えてくれるが、ユーザーが正しい答えを得たか、同じことを何度も言わされていないか、複雑な問題に対応する人がいるかには答えられない。
ここでひとつキーワードがある——転移率（Deflection rate、偏向率とも）：AIが自ら解決し、人に回さなかった対話の割合。人に渡しさえしなければ「成功」とみなされる。
行列に並ぶ人をセルフ機の前へ誘導しさえすれば「対応完了」とみなすようなもの。その人が用を本当に済ませたかどうかは、誰も記録しない。
「転移率」が目標になると、製品はいくつかの動きへと押しやられる——ユーザーをできるだけ自動化の中に留める、人への引き継ぎを先延ばしにする、曖昧な質問を既存の答えに無理やり押し込む、閉じやすいチケットを優先して閉じる。どの動きも自動化指標を良く見せられるが、どの動きもユーザー体験を悪化させかねない。自信たっぷりの誤答でも、変わらず「成功」とされる。
ユーザーは自動化フローに行き詰まり、何度も自分のことを繰り返す。その間、システムは「効率的な応答」を何度も記録する。たとえユーザーが最後に諦めても、処理時間もチケット量も見栄えはよい。第一世代のAIカスタマーサポートは自動化をうまくやってのけた。弱点は、会社が削減したコストを、ユーザーが得た成果と取り違えたことだ。
アリババの256万件の対話実験が、ひとつの精密な数字の裂け目を示した
4週間にわたるランダム実験で、アリババは5940人のオペレーター、約256万件の対話、39万件のユーザー評価を観察した。生成AIを導入した後、いくつかの指標がそろって改善した。
前の4項目はいずれも改善したが、最後のひとつ——3日以内に同じ問題で再びサポートに連絡する確率だけは、統計上有意でなかった（検出できる変化がなかった）。そしてそれこそ、この中で唯一「問題が本当に解決したのか」を測る指標なのだ。
速くなり、ユーザーはその場ではより良いと感じた。だが戻ってくる割合は下がらなかった。速さと満足は体験の一部を説明するにすぎず、問題が結果に向かったかどうかは、別に勘定しなければならない。
新フレームワーク：「いくら節約したか」から「ユーザーの旅程が完了したか」へ
企業のカスタマーサポートがユーザーの旅程全体を担うなら、評価表もその全体をカバーしなければならない。Luciusはサポート品質を、まとめて測る5つの次元に分解する。
前世代のダッシュボードが数えたのは、AIが何件返信したか、人件工数を何時間削減したかだった。このフレームワークは5つの問いに答える——ユーザーは結果を得たか？ コンテキストは追いついていたか？ 今回、信頼を消耗しなかったか？ 今回は次回をより良くしたか？ ユーザーはコミュニティに留まりたいと思うか？ 各レイヤーを開いて、旧来の仕組みが何を測り、このレイヤーが何を補うかを見てほしい。
1解決率問題は結果に向かったか？+
転移率、処理時間。待ち行列が縮んだかしか見ない。
タスク成功率、初回連絡での解決率、再連絡率、チケット再オープン率、そして明確な担当者と次の一手があるか。
2コンテキスト情報は追いついているか？+
ナレッジベースがどれだけ大きいか、何件のドキュメントを詰め込んだか。
会社の状態＋ユーザーの状態のリアルタイムなスナップショット。内容が最新で、範囲が定まり、実行可能か——流暢に答えても中身が旧バージョン、では困る。
3信頼今回、関係を消耗したか？+
ほぼ測らない。AIは会社の名義で返答し、ひと言の誤りも会社の約束とみなされる。
情報が足りないとき立ち止まれるか、軽率に約束しないか、機微な問題をプライベートな流れに移せるか、返金やコンプライアンスの約束が絡むとき証拠の連鎖を残せるか、問題が起きたとき責任を追えるか。
ITProが引用するSinchの調査によれば、74%の回答企業がガバナンスの失敗により、サポートAI agentをロールバックまたは停止したことがある。主な原因：顧客データの漏洩 31%、ハルシネーションやブランドリスク 22%、監査可能性の欠如 16%。会社が気にするのはAIが人らしいかどうかではなく、安心してサービスを任せられるかどうかだ。
4学習今回は次回をより良くしたか？+
測らない。対話は毎回使い捨てで、処理が終われば終わり。
不確かな問題がシステムの新しい知識になったか。今回ユーザーがはまった落とし穴、詰まった点、最後の突破が、次回に再利用できる経験として蓄積されたか。
5体験ユーザーはまだ留まりたいか？+
ひとつの満足度スコアが、過程で起きたすべてを覆い隠す。
ユーザーは元の場面で理解されるのか、それとも別の入口へ追いやられ、ログインし直し、フォームを埋め、問題をもう一度語らされるのか。公開された返答の一つひとつが、この組織が助けを求めて口を開いた人をどう扱うかを示している。
ひとつの例：初心者が初めて自分のアイデアでプロジェクトを作る
あるツールのコミュニティで、初心者が初めて自分のアイデアでプロジェクトを作った。ワークフロープラットフォームとローコードツールを組み合わせ、記事の内容とAPIの認証情報を入力し、ワンクリックで記事を下書き箱に送るページを作りたかった。プロジェクトは返り値の構造、APIフィールド、変数バインディング、結果表示、そして60秒のタイムアウトで詰まったが、最終的に全体の流れが通った。終わった後、彼はコミュニティのAIキャラクターに、最初のひと言の対話から全体を再利用可能な一本の道筋へ整理してもらった——プロジェクトの目標、全体アーキテクチャ、5つの段階、各エラー、現在の状態と次の一手まで含めて。彼は言う。自分のアイデアで何かを作れると初めて思えた、AIはまるで全過程を頭に記憶し、自分を前へ連れて行ってくれるようだった、と。データベースから答えを探すだけの旧式のサポートは、こうしたエンドツーエンドの伴走を支えきれない。
本当の「解決」は、ユーザーが口を開く勇気を持てるかから始まる
解決は「AIが答えたか」から始まるのではなく、ユーザーが口を開く気になるかから始まる。
教育心理学に、関連する概念で質問不安（Question-asking anxiety）というものがある——相手が権威的で、形式的で、自分を評価しかねないと感じると、人は自分の質問を吟味し始める。バカすぎないか、素人っぽく見えないか、人の邪魔にならないか、と。カスタマーサポートでも同じだ。あまりに堅苦しく冷たい入口は、ユーザーにまず自分が質問する「資格があるか」を値踏みさせる。標準的な答えしか返さない公式の窓口は、多くの初期段階の質問をユーザーの頭の中に押し戻してしまう。本当に助けを求めに来る頃には、問題はたいてい一段と複雑になっている。
速さは役に立つ。ユーザーが口を開いたばかりのとき、問題はまだ新鮮で、感情も発酵しておらず、足りないコンテキストもいちばん補いやすい。もしシステムがこのとき別の入口へ突き放し、フォームの記入を求め、メールを待たせれば、彼は次から尋ねなくなるかもしれない。本当の解決とは、システムがユーザーに結果への道筋を見せることだ——誰が担当し、次に何が起き、いつ更新があり、いまどこで詰まっているのか。ユーザーを別の人、別のチャネル、別のフォームに回すのは、問題が別の場所へ移されたことを示すにすぎない。誰が、いつ、どこまで進めるのかをユーザーが知らないままなら、問題は前に進んでいない。
これはまさにアリババの実験のあの裂け目と呼応する——AIはその場の感じを良くしたのに、再連絡率は下がらなかった。「速く答える」ことは「正しく答え、しかも次の一手を示す」ことと同じではない、ということだ。
Luciusが「解決率」を測る8つのシグナル
タスク成功率 · 初回連絡での解決率 · 再連絡率 · チケット再オープン率 · 解決所要時間 · エスカレーション成功率 · 担当者割り当て率 · 次の一手が明確か（多少の主観的判断を含む）。
コンテキストはナレッジベースではなく、同時に走る2本のリアルタイムな軌道だ
コンテキストには同時に変化する2つの記録が入っている——会社の状態とユーザーの状態。どちらかが欠ければ、古い答えで新しい問題に答えることになる。
多くの会社はナレッジベースの規模を誇る。本番環境はもっと難しい問いを突きつける——その中身はまだ成り立っているのか？ 機能は変わり、価格は変わり、ポリシーは変わり、社員は言い回しを変え、ユーザーは新しい約束を受け取る。ドキュメントが一度遅れれば、AIは変わらず答えられるが、ただ流暢な言葉で古い答えを返すだけだ。コンテキストが役に立つのは、それが最新で、範囲が定まり、実行可能であることが前提だ。
ここでひとつ言葉を区別しておきたい——ワーキングメモリ（Working memory）：AIがこのチケットを処理する過程でリアルタイムに付ける帳簿。何を集めたか、どんな操作を実行したか、いまどの段階で詰まっているか。
それはカルテ（ナレッジベース）ではなく、「この手術がいま何ステップ目か」を示すリアルタイムの手術記録だ。
1億人を超えるユーザーにサービスを提供するNubankのサポートシステムでは、指示、フロー、マクロ、ツールの説明、ワーキングメモリが、それぞれ独立してバージョン管理されるコンポーネントとして扱われる。ワーキングメモリは、すでに集めた情報、ツールの実行結果、いまどの段階まで処理したかを記録する。確信度の低い問題を人に引き継ぐとき、対話のコンテキスト全体も一緒に移り、ユーザーが自ら「コンテキストの配達人」を務めずに済む。これはプロンプトにより多くのドキュメントを無理に詰め込むより、本番に乗せられるコンテキスト管理に近い——システムは現在の事実を知ると同時に、タスクの現在の状態も知っていなければならない。
ナレッジベースを月1回しか更新しなければ、その間の変化は古い答えで返される
同じコンテキストでも、メンテナンスのリズムが違えば、AIが古い答えで新しい問題に答える確率も違ってくる。
従来のナレッジベースのメンテナンスはここで行き詰まる——多くのチームはこれまで月に1回しかドキュメントを更新せず、更新してもAIが正しい1件を検索できる保証はない。そこでドキュメントをますます小さな断片に切り刻む。細かく切っても検索が正確になるとは限らず、かえって似たような断片を増やし、どれがまだ成り立つのかをシステムが判断しづらくする。
チームはドキュメントを手動でメンテナンスする必要がない。Luciusが不確かな問題を彼らにルーティングし、彼らはメッセージに返信するように答えるだけで、システムが学習する。逆に言えば、この400回の更新が月1回の手動整理に圧縮されれば、その間の大量の新しい見解、例外、ユーザーへの約束、製品変化は、空白期間の中で消えてしまう。これらのコンテキストに手が届かないシステムは、古い答えで新しい問題に答えるしかない。
需要はすでに目覚めたが、提供できる会社はまだ追いついていない
市場は方向を見たが、移行は完了していない。このギャップこそ、先に動く者の好機だ。
多くの会社はいまだ旧システムに行き詰まっている——ドキュメントはあちこちに散らばり、過去の対話はチャネルに埋もれ、サポートのフローはコミュニティの現場から切り離され、人への引き継ぎには証拠の連鎖がなく、AIの返答には境界も記憶もない。多くの人はAIカスタマーサポートの問題を「人間らしさが足りない」と読み違え、口調、ペルソナ、アイコン、あいさつを繰り返し磨く。だがユーザーが気にしているのは別のことだ——システムはこの問題を本当に分かっているのか。Luciusによれば、同社のシステムを使うサポートコミュニティでは、ユーザーが自ら人への引き継ぎを求める割合を 0.1% 未満に抑えられるという（Lucius自社サンプル）。
ユーザーが一度「口を開けば、システムは私が誰かを知っていて、繰り返さずに済み、前回どこで詰まったかを覚えていて、人を呼ぶべきときには呼んでくれる」という体験を味わってしまえば、旧式のサポートはダイヤルアップ接続のように時代遅れになる。前世代のチャットボットでユーザーを引き止め続ける会社は、遅かれ早かれ追いつかねばならない。そしてそのとき向き合うのはもはや技術調達の問題ではなく、信頼回復の問題だ。
第一世代のAIカスタマーサポートは会社を中心に作られた。次世代はユーザーの旅程全体を中心に作られる。Lucius / X · 2026年6月29日