本文へスキップ
tech公開更新約12分で読めます

高齢顧客が多い通販のボイスボット:音声認識の改善前に確かめるチャネル選択

シェア
高齢顧客が多い通販のボイスボット:音声認識の改善前に確かめるチャネル選択

CC AI Labが公開しているCOCOコンサルティングとの対談記事では、複数の相談を抽象化したモデルケースとして「顧客の大半が高齢で、電話注文を受けるボイスボットが雑音や聞き取りの問題でうまく機能しない通販センター」が取り上げられた。同社の大松祐子氏がまず投げかけたのは、音声認識の直し方ではなく、そのチャネルを顧客が望んでいるのかという問いだった。

この問いは、精度改善の打ち手を探している責任者ほど後回しにしやすい。ここで立てたい問いは、ボイスボットの精度が低いと感じたとき、技術改善に進む前に何を確かめれば、次の施策を取り違えずに済むのかである。私の立場を先に書けば、最初にやるべきは認識エンジンの比較ではなく、「何が起きて受注を取りこぼしているのか」をログで分けることと、顧客側の窓口の選び方を確かめることだ。

なお、本記事の手順・表・判断例は編集部が組み立てた独立の実務案であり、対談の話者の見解ではない。対談での診断の詳細は元記事(会員限定)で読んでほしい。また、モデルケースは特定企業の事例ではなく、本記事でも実在企業の失敗事例として扱わない。

切電と誤認識を同じ問題にしない

「ボイスボットが機能しない」という訴えの中には、性質の違う現象が混ざっている。まとめて「精度が悪い」と呼ぶと、打ち手が全部「認識エンジンを良くする」に寄ってしまう。これは、発熱・咳・腹痛をすべて「体調不良」と書いて同じ薬を出すようなものである。

主要な対話基盤も、この区別を最初から持っている。Google CloudのDialogflow CXのドキュメントは、組み込みイベントとして、入力がどの意図にも合わなかったときの「no-match」と、入力が受け取れなかったときの「no-input」を分けている。後者には、音声に認識できる発話が含まれない場合や、発話が認識される前に無音のタイムアウトが来た場合が含まれる。AWSのコンタクトセンター向けサービスのGet customer inputブロックの説明でも、分岐は「Timeout(入力がない)」「Default(入力が条件に合わない)」「Error」に分かれている。

つまり基盤側のログには、少なくとも「黙った」「言ったが合わなかった」は別々に残る。これに業務側の事実を足して、次のように5つに分けるのが編集部の整理である。

現象

ログ上の見え方

主な原因の候補

最初に疑う打ち手

応答直後の切電

最初の入力が来る前に通話終了

機械応答そのものへの抵抗、想定外の窓口

窓口の案内・選択肢の設計

無入力(no-input)

タイムアウト分岐・無音

話し始めるまでの待ち時間が短い、何を言えばよいか分からない

待ち時間・案内文言・押しボタン併用

不一致(no-match)

認識はしたが意図・項目に合わない

案内と回答形式のずれ、雑音、言い回しの幅

質問の形・選択肢の絞り込み

誤受注

ボットは完了扱い、後で人が修正

品番・数量などの誤認識を復唱で止められていない

復唱確認・受注確定前の人手確認

有人への切替要求

「人と話したい」等での転送

用件が複雑、ボットで完結させたくない

転送の設計・用件の切り分け

この5つで、打ち手は大きく違う。たとえば無入力が多いなら、エンジンを替える前に待ち時間を見直す余地がある。AWSの同じドキュメントでは、Amazon Lexに渡す設定として、顧客が話し始めないと判断するまでの「Start Silence Threshold」の既定値が3秒、話し終わったと判断するまでの「End Silence Threshold」の既定値が0.6秒と記載され、どちらも調整できる(2026年9月18日時点)。一方、応答直後の切電が多いなら、認識精度をいくら上げても数字は動かない。そもそも発話していないからだ。

誤認識そのものの切り分け方は、音声認識辞書のテスト手順と日本語音声認識の誤りの出方で整理した。本記事はその手前、技術改善に進むべきかどうかを決める段階を扱う。

顧客が使いたい窓口と必要な補助を確かめる

顧客が使いたい窓口と必要な補助を確かめる

ログを分けたら、次は顧客側を確かめる。ここで避けたいのは、年齢で能力や希望を決めつけることである。「高齢だから電話しか使えない」も「高齢だから機械応答は無理」も、どちらも確かめる前の思い込みにすぎない。

公的統計も単純な像を示していない。総務省の令和7年版 情報通信白書は、インターネット利用率が13歳から69歳までの各年齢で9割を超える一方、70歳以降は年齢が上がるにつれ低下する傾向にあると記している。白書のもとになる調査の一つである令和6年通信利用動向調査の公表資料(調査時点は令和6年8月末、公表は令和7年5月30日)では、インターネットの利用目的として、50歳以上の各年齢階層では「電子メールの送受信」の割合が最も高い。もっとも、これは全国の傾向であり、自社の顧客がどうかは別問題である。年代別の比率を自社の判断材料に使うなら、自社顧客で測り直す必要がある。

編集部案として、確かめ方は次の3つに分けると進めやすい。

  1. 使っている窓口を数える。 過去の受注がどの経路(電話・はがき・Web・同梱の注文書など)で入っているかを、顧客単位で集計する。同じ顧客が複数の経路を使い分けていることも多い

  2. 使いたい窓口を聞く。 同梱物や注文確認の電話の最後に、夜間に注文したいときの希望(翌朝の折り返し、Web、自動応答など)を短く聞く。選択肢に「その他」と「分からない」を残し、誘導しない

  3. 必要な補助を聞く。 聞き取りやすい話速、押しボタンでの操作、家族による代理注文、復唱の丁寧さなど、窓口そのものではなく「どう支えれば使えるか」を分けて聞く

3つ目は見落とされやすい。自動応答が使えない理由が、窓口ではなく補助の不足であることもある。話し始めるまでの待ち時間が短い、案内が早口、押しボタンで答えられない、といった原因なら、窓口を変えなくても設計で解ける。

聞こえや発話に困難のある顧客への対応は、別の観点からも無視できない。障害者差別解消法の改正により、令和6年4月1日から事業者による合理的配慮の提供が義務化されている。年齢そのものは障害ではないため、高齢の顧客をひとまとめにこの枠で扱うべきではない。ただ、自動応答しか入口がない設計は、個別の申し出に応じる余地を狭める。代替の窓口を残しておくことは、顧客体験の話であると同時に、この観点からも検討に入れておきたい。

有人・一次受付・自動応答を並べて選ぶ(コールセンターの受付設計)

顧客側の事実が集まったら、ようやく選択肢を並べる。ここでは「ボイスボットを続けるか、やめるか」の二択にしないことが大事である。夜間の受注を取りこぼしたくないという目的に対して、手段は少なくとも4つある。

選択肢

中身

受注確定の正確さ

顧客の負担

後工程(在庫・物流)への影響

向く用件

有人(自社または夜間委託)

人が受けて受注まで確定

高い

小さい

通常どおり

注文・変更など失敗できない用件

一次受付+折り返し

自動応答や留守電で用件と連絡先だけ受け、翌営業時間に人が確定

高い(確定は人)

折り返しを待つ負担

確定が翌日になる

急がない注文・相談

自動応答(照会系)

在庫・キャンペーン条件・ポイントなど、確定を伴わない問い合わせを自動で答える

対象外

用件次第

ほぼなし

定型の確認・照会

自動応答(受注確定まで)

商品特定・数量・支払い・配送までボットで確定

認識と復唱の設計次第

項目が多いほど大きい

誤受注は在庫・物流の手戻りに直結

項目が少なく定型の再注文など

表の読み方で押さえたいのは、受注確定まで自動化するほど、誤りのコストが後工程に回ることである。誤った注文は、在庫の引当や出荷指示を動かしてしまう。対談で大松氏が、受注は失敗できない業務だと指摘し、注文以外の問い合わせから小さく始める考え方を示したのも、この構造による。EC問い合わせのうち返品が人に残りやすい理由は、EC・通販の問い合わせ自動化の記事で外部システム連携と例外処理の観点から整理した。

編集部の判断例を架空の条件で示す。夜間の着信のうち応答直後の切電が多く、顧客調査でも「翌朝の折り返しでよい」という回答が目立つなら、受注確定の自動化を磨くより、一次受付+折り返しに切り替えて、自動応答は照会系に限定する案が有力になる。逆に、無入力と不一致が中心で、Webや自動応答を使いたいという顧客も一定数いるなら、待ち時間や押しボタン併用などの補助を整えたうえで、使える顧客には自動応答を残し、使いにくい顧客には一次受付へ逃がす併用が候補になる。いずれも、窓口を一つに決めるのではなく、顧客が選べる状態を作る発想である。

なお、ボイスボットを続ける判断になった場合の製品評価の軸は、ボイスボットの選び方の記事で整理している。本記事は特定の製品や方式を推奨するものではない。

ここからは私の見立て

ここからは私の見立てとして書く。高齢の顧客が多い通販でボイスボットがうまくいかないとき、原因の多くは認識エンジンの性能ではなく、顧客の選び方を確かめる前に、受注という最も失敗できない用件から自動化を始めた順番にあると見ている。精度の議論は、その順番の問題が表に出た結果にすぎないことが多い。

自己反証を置く。この見立ては、夜間の人手を確保できない小規模センターの事情を軽く見ているかもしれない。夜間委託の費用が合わず、折り返しの人手も足りないなら、受注の自動化を磨く以外に選択肢がないという現場もあるだろう。その場合でも、ログを5つに分けて「どの現象を減らせば取りこぼしが減るか」を先に決めることは、技術改善の的を絞るうえで無駄にならない。

条件を書くなら、技術改善から着手してよいのは、①ログで無入力・不一致・誤受注が主因と確認でき、②顧客の一定数が自動応答を使いたい、または使ってもよいと答え、③誤受注を確定前に止める復唱や人手確認の仕組みがある場合である。この3つがそろわないうちは、エンジンの比較より窓口の選び方を見直すほうが先だろう。

まとめ

第一に、「精度が悪い」には、応答直後の切電・無入力・不一致・誤受注・有人切替要求という性質の違う現象が混ざっており、ログで分けないと打ち手を取り違える。第二に、顧客の窓口の希望と必要な補助は、年齢で決めつけず、自社の顧客で数えて聞いて確かめる。第三に、夜間の取りこぼし対策は、有人・一次受付+折り返し・照会系の自動応答・受注確定までの自動応答を並べ、誤りのコストが後工程に回るかどうかで選ぶ。

問いを残しておきたい。自社のボイスボットで「うまくいかなかった通話」は、いま何件あり、そのうち何件が、そもそも話し始める前に終わっているだろうか。

この論点の出発点になった対談

本記事の出発点になったモデルケースと、センター運営のプロによる診断は、次の対談記事で読める(会員限定)。受注を自動化の最初に置くべきか、どこから小さく始めるかについての話者自身の考えは、こちらを参照してほしい。

小規模センターは、生成AIとどう付き合うべきか ー 3つの相談ケースをプロが診断(COCOコンサルティング)(会員限定)

よくある質問

Q. 高齢の顧客が多ければ、ボイスボットはやめるべきですか。 A. 年齢だけでは決まりません。まずログで切電・無入力・不一致・誤受注を分け、自社の顧客が使いたい窓口と必要な補助を確かめてから判断するのが本記事の提案です。照会系の用件に限って残す、使える顧客と使いにくい顧客で窓口を分ける、といった併用も選択肢になります。

Q. 切電と誤認識はどう見分けますか。 A. 最初の入力が来る前に通話が終わっていれば切電、タイムアウトや無音なら無入力、認識はしたが意図に合わなければ不一致として分けます。多くの対話基盤はこの区別をイベントや分岐として持っているため、まずその集計から始められます。

Q. テレビの音などの雑音対策は、エンジン変更で解決しますか。 A. 雑音が不一致や誤受注の主因だとログで確認できた場合は、技術的な対策の検討に進む意味があります。ただし、切電や無入力が中心であれば、エンジンを替えても数字は動きにくいため、先に窓口の案内や待ち時間、押しボタン併用の設計を見直すほうが効果を測りやすいです。

Q. 本記事の表や判断例はどこまで信頼できますか。 A. 表・手順・判断例は編集部が作成した実務設計案であり、対談の話者やベンダーが定めたものではありません。各機能の仕様は本文で参照した公式ドキュメントで、自社への適用可否は自社のログと顧客調査で確認してください。


注記: 本記事は2026年9月18日時点で確認できた公開情報にもとづく。各サービスの機能名・既定値は提供形態やバージョンによって変わりうるため、実装時は一次ドキュメントで再確認が必要である。本文中の判断例の条件はすべて架空であり、対談で扱われたモデルケースも複数の相談を抽象化したもので、特定の企業を表すものではない。対談の話者の見解は元記事に帰属し、本記事の手順・表・判断例は編集部の独立した案である。「私の見立て」以降は筆者個人の分析である。本記事はAI著者によるデスクリサーチであり、一次取材にもとづくものではない。


出典

この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと隔週ニュースレターを受け取れます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア