コールセンターの音声認識は、通話内容の文字起こしや応対履歴の作成、音声マイニング、ボイスボットによる一次対応などに活用できます。一方、氏名や住所、型番、業界用語、重なった発話などは、認識精度が低下する場合があります。
この記事では、コールセンターにおける音声認識の活用方法や精度が出ない理由、自社環境での確認方法、認識の誤りを補う方法、システムの種類、導入事例、導入前の確認事項を解説します。
株式会社ストラーツの「電話応対AIサービス」は、氏名や住所など認識が難しい情報について、業務に合わせてヒアリング方法を調整する設計に対応しています。コールセンターへのAI導入をご検討の場合は、ぜひご相談ください。
1．音声認識で条件付きできること・事例
音声認識によってコールセンター業務のどこまでを効率化・自動化できるか、利用するための条件や人による確認範囲、導入事例とあわせて解説します。
（1）通話音声をリアルタイムで文字起こしする
リアルタイム文字起こしは、顧客とオペレーターの発話を通話中にテキスト化し、画面へ表示する方法です。オペレーターは表示された内容を確認しながら応対できるため、通話中のメモ作業を減らせます。
| 利用するための条件 | 文字の表示が会話を妨げない速さであり、 誤認識した箇所を確認・修正できる画面と手順がある |
|---|---|
| 人による確認・修正が必要な範囲 | 誤認識した発話や、 氏名・住所・電話番号・型番など正確な記録が必要な情報 |
■ リアルタイム文字起こしの導入事例
東邦ガスは、AIが顧客との会話を通話中にテキスト化し、その内容に応じたマニュアルをオペレーターの画面へ提示する業務支援システムを導入しています。同社ではリアルタイムの文字起こしにとどまらず、通話後の要約作成や管理者への引き継ぎ支援も同一システム内で自動化しています。
同社では、通話後の要約作成や管理者への引き継ぎ支援も同一システム内で自動化しています。これにより、通話後の記録入力にかかる後処理時間は最大約88％、管理者による応対評価業務は約25％削減されました。結果として、顧客の待ち時間短縮と繁忙期の対応件数拡大にもつながっています。
参考：https://www.nikkei.com/article/DGXZQOFD171810X10C26A2000000/
なお以下の記事では、コールセンターにおけるAI導入について包括的に解説しています。
（2）応対履歴の作成や音声マイニングに活用する
音声認識で文字起こしした通話内容は、応対履歴や要約の作成に活用できます。応対履歴の作成や音声マイニングは、オペレーターが通話後に記録を一から作成する作業を減らし、後処理時間（ACW）の短縮につなげる方法です。
また、文字起こしした通話を蓄積すると、発話内容の検索や問い合わせ傾向の分析、応対品質の評価にも利用できます。応対履歴の作成が個別の通話を記録する用途であるのに対し、音声マイニングは蓄積した通話データを検索・分析する用途です。
| 利用するための条件 | 生成された応対履歴や要約を保存する前に、 確認・修正する手順がある |
|---|---|
| 人による確認・修正が必要な範囲 | 誤認識した発話、要約内容、氏名や受付内容など 記録・分析に使用する情報 |
誤認識を含む記録を蓄積すると、後の検索結果や分析にも影響します。保存前に確認する項目と修正する担当者を決め、確認済みの記録を蓄積する運用が必要です。
■ 応対履歴の作成や音声マイニングの導入事例
JR西日本カスタマーリレーションズは、月間約7万件の電話問い合わせを受け付けています。従来は応対後にオペレーターが通話内容を要約し、スーパーバイザーがその内容を確認する運用を取っていたため、後処理の負担が大きく、要約の品質にもばらつきが生じていました。
同社は言語生成AIを導入し、音声認識で書き起こした通話テキストから要約案を自動生成する仕組みを構築しています。実証実験では、問い合わせ、ご意見・ご要望、介助申込の3業務を対象に後処理時間を18〜54％削減しました。あわせて、要約作成と確認にかかる負荷の軽減、要約品質の均質化、蓄積したデータのVOC分析への活用が見込まれています。
参考：https://www.westjr.co.jp/press/article/items/20230921_00_press_customercenter_ai.pdf
（3）ボイスボットと組み合わせて一次対応を自動化する
ボイスボットによる一次対応は、音声認識と自動応答を組み合わせ、顧客の発話に応じて案内を進める方法です。用件の聞き取りや問い合わせ先の振り分け、定型的な案内などを自動化できます。
| 利用するための条件 | 認識できなかった場合に、 聞き直し、有人転送、SMS入力、折り返し予約などへ切り替える動線があること |
|---|---|
| 人による確認・修正が必要な範囲 | 氏名・住所・注文内容など正確な取得が必要な情報や、音声認識の信頼度が低い発話 |
導入時には、自動応答だけで完結させる用件、確認を挟む用件、有人対応へ切り替える用件を分けて設計します。
■ ボイスボットによる一次対応の導入事例
中国電力は、電気契約や料金、設備に関する問い合わせを受け付けるコールセンターにおいて、繁忙期やピーク時間帯の安定稼働を課題としていました。加えて、悪天候や感染症の影響でオペレーターが出勤できない状況でも業務を継続できる体制の構築が求められていました。
同社はAI自動応答サービスを導入し、契約番号と契約名義を音声認識で聞き取ったうえで、本人確認から受付結果の連携までを自動化しています。導入後はAIが問い合わせの一部を自動応答することでオペレーターの対応件数が減少し、繁忙期でも電話がつながりやすくなった結果、電話応答率は前年比で8％向上しました。契約名義の認証率は約97％以上に達しています。
参考：https://aismiley.co.jp/ai_news/ai-confirms-identity/
2．コールセンターの音声認識で精度が出ない理由と対処法
音声認識の精度は、取得する情報や話し方、通話環境、登録されている語彙、会話の進め方によって変わります。ここでは、認識精度が低下する4つの条件と、それぞれの対処法を解説します。
（1）氏名・住所・型番の認識は読み上げ確認やデータ照合で補う
音声認識は、入力された音声に対して、学習済みの語彙から確からしい候補を選び、テキストへ変換します。そのため、氏名や住所、製品の型番など、候補の組み合わせが多い情報は正確に認識しにくくなります。
氏名は同じ読み方でも漢字が異なる場合があり、音声を正しく認識できても表記までは確定できません。
住所も、地名に一般的な読み方とは異なる読みが含まれると、別の文字へ変換される場合があります。電話番号や注文番号では、「いち」と「しち」のように音が近い数字や、数字の区切り方によって認識結果が変わります。
こうした情報は、音声認識だけで取得を完結させず、次の確認方法を組み合わせます。
- 認識した氏名や住所、番号を読み上げ、顧客に確認してもらう
- SMSで入力フォームを送り、顧客自身にテキストで入力してもらう
- 電話番号などを既存の顧客データベースと照合し、候補を絞り込む
例えば、着信した電話番号から既存顧客を特定できれば、氏名や住所を一から音声で取得する必要がなくなります。データベースに複数の候補がある場合は、認識結果と照合したうえで、必要な項目だけを顧客へ確認します。
（2）方言・話速・回線品質の影響は実際の録音で検証する
音声認識の精度は、話し方や通話環境によって変わります。整った環境で測定された認識率だけでは、自社の通話における精度を判断できません。導入前には、自社の実際の入電から通話を抽出し、次の条件を含めて検証します。
| 検証する条件 | 確認する内容 |
|---|---|
| 方言・話し方 | 地域ごとの語彙やイントネーション、 話す速さによる認識結果の違い |
| 顧客層 | 年代などによる発話の違い |
| 通話環境 | 周囲の騒音、携帯回線の音質劣化、 通話機器のマイク性能による影響 |
| 問い合わせ内容 | 氏名、住所、電話番号、受付内容など、 業務に必要な項目を取得できたか |
全国から入電を受ける業務と、特定地域の顧客を対象とする業務では、通話に含まれる方言や話し方の分布が異なります。自社の入電に地域や年代などの偏りがある場合は、その条件を含む録音を検証対象にします。
あわせて、認識の信頼度が低い発話を有人対応へ切り替える基準を設定します。実際の録音から認識が崩れる条件を把握し、自動対応を継続する範囲と有人対応へ切り替える範囲を分けます。
（3）業界用語や製品名は辞書へ登録して継続的に更新する
製品名、業界用語、社内の略称、部署名などは、汎用的な音声認識モデルの語彙に含まれていない場合があります。登録されていない言葉は、音が近い一般的な言葉へ変換される場合があるため、通話内容を正しく認識できない原因になります。
こうした固有の語彙は、音声認識システムの辞書へ登録して補います。ただし、言葉を登録するだけで精度が上がるとは限りません。正式名称に加えて、顧客やオペレーターが実際に使う読み方や略称も登録します。
| 更新が必要になる場面 | 辞書で確認・更新する内容 |
|---|---|
| 新商品・サービスの追加 | 正式名称、読み方、呼び方の違い |
| キャンペーン名の変更 | 新しい名称と読み方 |
| 組織改編 | 部署名、社内で使用する略称 |
| 誤認識の発生 | 誤って変換された言葉と正しい候補 |
導入時には、辞書を更新する担当者、更新する頻度、誤認識した言葉を収集して反映する手順を決めます。社内で更新作業を担当できない場合は、提供会社が辞書登録や精度調整を行う契約形態を選び、対応範囲や更新条件を確認します。
（4）重ね発話や断片的な発話は質問項目を分けて防ぐ
オペレーターと顧客が同時に話す重ね発話や、途中で途切れた断片的な発話では、音声認識の精度が下がります。相槌が顧客の発話に重なった場合や、保留から復帰した直後に会話が始まった場合も、必要な情報が正しく文字起こしされない場合があります。
話者分離機能を備えたシステムでも、重なった音声を完全に分離できるとは限りません。ボイスボットでは、顧客がガイダンスの途中で話し始める割り込み発話への対応も必要です。
| 認識が崩れやすい場面 | 質問・応答の調整方法 |
|---|---|
| 氏名と電話番号を一度に尋ねる | 氏名と電話番号を別々に質問する |
| 顧客の回答中に相槌を入れる | 回答が終わってから次の案内を始める |
| 保留解除の直後に質問する | 顧客が応答できる状態を確認してから質問する |
| ガイダンス中に顧客が話し始める | 割り込み発話を受け付ける範囲を決める |
特に氏名、住所、電話番号などを取得する場面では、一度に複数の項目を尋ねず、一項目ずつ質問して回答を待ちます。質問を分けると応答回数は増えますが、発話の重なりや情報の取り違えを抑えられます。
認識できなかった場合は、質問を短くして聞き直すか、有人対応へ切り替えます。重要な情報を取得する場面ほど、会話の速さよりも、一つの質問に対して一つの回答を受け取る構成が必要です。
3．自社環境での音声認識精度を確認する方法
ここでは、自社の実際の通話データを使い、業務に必要な情報を正しく取得できるか確認する方法を解説します。
（1）業務上正確に取得すべき情報を整理する
音声認識の精度を確認する前に、通話の中で正確に取得しなければならない情報を整理します。確認対象は、後続の処理で使用する項目ごとに設定します。
| 確認対象 | 評価する単位 |
|---|---|
| 氏名 | 姓と名を分け、必要な表記で取得できたか |
| 住所 | 郵便番号、地名、番地などを項目別に取得できたか |
| 電話番号 | 数字列全体を正しい順序で取得できたか |
| 注文番号・製品の型番 | 数字や英字を含む文字列全体を取得できたか |
| 問い合わせ内容 | 用件や対象となる商品・サービスを判定できたか |
あわせて、表記まで一致させる必要がある項目と、発話の意味を把握できればよい項目を分けます。例えば、氏名や注文番号は文字列の正確さが必要ですが、問い合わせ内容は用件を正しく分類できることが評価基準になります。
検証前に項目ごとの正解条件を決めておくことで、評価する担当者による判定の違いを防ぎます。
（2）実際の録音データを使って検証する
音声認識の導入可否は、自社のコールセンターで録音した実際の通話を使って判断します。
顧客の話し方や通話環境、問い合わせ内容を含む録音でなければ、運用時の認識精度を確認できないためです。検証は、次の手順で進めます。
| 手順 | 実施内容 |
|---|---|
| 1．通話を抽出する | 実際の入電から検証対象となる録音を抽出する |
| 2．条件を分ける | 地域、年代、問い合わせ内容、利用回線などの条件を整理する |
| 3．正しい内容を確認する | 録音を人が聞き、評価対象となる情報の正しい内容を確定する |
| 4．音声認識を実行する | 録音データを使用して文字起こしを行う |
| 5．認識結果を比較する | 氏名、住所、電話番号、型番などを項目別に照合する |
| 6．誤認識の条件を整理する | 認識できなかった情報や、精度が低下した通話条件を記録する |
自社の入電に地域や顧客層の偏りがある場合は、その分布を含む録音を検証対象にします。また、各評価項目について判定できるだけの通話が含まれているか確認します。音質のよい通話や認識しやすい用件だけに偏ると、実際の運用環境における結果を確認できません。
検証結果には、どの項目が、どの条件で誤認識されたかを記録します。これにより、辞書登録や質問方法の調整で対応する範囲と、有人対応へ切り替える範囲を分けられます。
（3）通話全体ではなく項目別の取得率を測る
導入可否を判断するときは、業務に必要な項目ごとに、音声認識直後の結果を正しく取得できた件数を測ります。人が修正した後の結果を含めると、音声認識そのものの精度を判断できないためです。
| 評価指標 | 計算方法 | 判断できること |
|---|---|---|
| 通話全体の認識率 | 通話全体で正しく文字起こしできた割合 | 要約、検索、傾向分析に利用できるか |
| 項目別の取得率 | 対象項目を最初から正しく取得できた件数÷対象項目が含まれる件数 | 本人確認、受付、受注などに利用できるか |
| 最終的な取得率 | 確認や修正を経て正しく取得できた件数÷対象項目が含まれる件数 | 補完手順を含めて業務を完了できるか |
項目別の取得率は、次の式で算出します。
項目別取得率（％）＝正しく取得できた件数÷対象項目が含まれる件数×100
氏名、住所、電話番号、注文番号、型番などは、それぞれ分けて取得率を計算します。すべての項目をまとめて平均すると、認識しやすい項目の結果によって、認識しにくい項目の問題が見えにくくなるためです。
（4）聞き直しや再確認の発生率を測る
音声認識の評価では、取得するまでに聞き直しや訂正が発生したかも計測します。最終的な取得結果が正しくても、同じ質問を繰り返している場合は、通話時間や顧客の負担に影響するためです。
| 記録するやり取り | 記録方法 |
|---|---|
| 質問の繰り返し | 認識できず、同じ項目を再度尋ねた回数を記録する |
| 読み上げ確認 | 読み上げた内容が異なり、顧客が訂正した件数を記録する |
| 認識結果の訂正 | SMS入力や有人対応へ切り替えた件数を記録する |
| 取得方法の切り替え | 認識失敗による再確認とは分けて記録する |
読み上げ確認をすべての通話で行う設計の場合、その確認は音声認識の失敗によって発生したものではありません。予定していた確認と、誤認識によって追加で発生した聞き直し・訂正を分けて集計します。
再確認の発生率は、次の式で算出します。
再確認発生率（％）＝追加の聞き直し・訂正が発生した件数÷評価した件数×100
通話単位で測る場合は「再確認が発生した通話数」、項目単位で測る場合は「再確認が発生した対象項目数」を分子にします。結果を比較できるように、分母と分子の単位は統一します。
項目別取得率と再確認発生率をあわせて確認することで、その情報を取得するまでに必要だった追加対応も把握できます。
4．コールセンター向け音声認識システムの種類とおすすめサービス
音声認識システムは、機能だけでなく、自社の運用体制や既存環境に合う種類を選ぶ必要があります。音声認識を含むAIの導入には、予算や人員に加え、運用を担う人材、社内データ、既存システムと連携できる技術環境が関係するためです。選定の起点となるのは次の2つの条件です。
| 既存の電話環境を維持する | 電話環境ごと入れ替える | |
|---|---|---|
| 社内に開発体制がない | ・パッケージ型 ・録音・データ管理基盤型 | 電話・CTI一体型 |
| 社内に開発体制がある | 音声認識エンジン・API型 | 音声認識エンジン・API型＋自社開発 |
既存のPBXやCTIを残したまま音声認識を追加するのか、電話基盤ごと入れ替えるのか。この分岐が導入コストとプロジェクト期間を最も大きく左右します。以下、4類型それぞれの位置づけと代表的なサービスを整理します。
（1）コンタクトセンター向けパッケージ型
コンタクトセンター業務専用に設計され、音声認識エンジンと業務機能が一体で提供される形態です。リアルタイム文字起こし、応対履歴の作成、品質評価、VOC分析までを1つの製品でカバーするため、自社開発を伴わずに導入できます。数十席以上の規模で、音声認識を応対品質管理まで含めて活用する場合の標準的な選択肢となります。
一方で、既存のPBXやCTIとの接続設計が必要になり、導入までに数か月を要する場合があります。予算規模と構築期間を前提に置いた検討が求められます。
①電話応対AIサービス
電話応対AIサービスは、音声認識による文字起こしに加え、感情分析や自動要約を搭載でき、オペレーターの対応負荷を軽減します。
認識したテキストを発話の認識から応答の生成までをAIが担う構成を提供する点が、同類型の他サービスとの機能設計上の違いにあたります。
導入先の業務に合わせたフルカスタマイズに対応しており、既存システムとの連携や機能追加も個別に設計されます。料金は、基幹システム連携時に別途費用が発生する体系です。実際のAI応対を確認できる電話でのデモ体験（050-1724-1373）も提供されています。
業務に合わせた個別設計を前提とするサービスです。自動化する用件の範囲と、有人対応へ切り替える条件を業務側で整理したうえで要件定義を行います。
②AmiVoice Communication Suite
AmiVoice Communication Suiteは、コンタクトセンターの会話に特化した音声認識エンジンを採用したソリューションで、全通話のリアルタイムテキスト化、応対品質評価、感情解析、要約生成に対応します。
生成AIの活用については、ローカル環境で動作するLLMとクラウド型の生成AIを使い分けられます。
50席1拠点の構成で導入までに平均3〜5か月を要します。期間は機器構成、認識処理方式、利用形態、拠点数、連携するPBXによって変動するため、要件を確定させたうえでスケジュールを設定します。
③ForeSight Voice Mining
ForeSight Voice Miningは、NTT研究所が開発した音声認識技術を活用した音声データ活用サービスです。
通話内容はリアルタイムにテキスト表示され、あらかじめ設定した注目ワードはハイライト表示されます。通話内容からコールリーズンを抽出して重要事項の一覧を自動表示し、発話内容に応じて自動でチェックする機能も備えます。
オンプレミス環境での提供が基本構成です。クラウドでの利用を想定する場合は、本製品をクラウドサービス化したCOTOHA Voice Insightの上位プランが該当するため、提供形態から検討します。
④Omnia LINK
Omnia LINKは、リアルタイム音声認識を標準搭載し、そのテキストを活用した機能でオペレーターを支援します。管理者は座席表から複数オペレーターの応対内容をリアルタイムにテキストでモニタリングでき、在宅や他拠点のオペレーターも同様に管理できます。キーワードアラートや生成AIによる自動要約などの機能をオールインワンで搭載しています。
リアルタイム音声認識を標準搭載した構成です。在宅勤務や複数拠点のオペレーターを含めた運用管理を要件とする場合、管理画面で確認できる範囲を実機で確認します。
（2）音声認識エンジン・API型
音声認識エンジン・API型は、音声認識の機能をAPIやSDKとして提供する形態です。既存の業務システムやCTIへ組み込んで利用するため、認識結果を表示する画面やデータの蓄積方法を自社で設計できます。通話以外の音声も同一エンジンで処理できる構成が一般的です。
CTIとの接続、テキストの表示画面、修正手順、蓄積データの検索機能は導入側の開発範囲となります。社内またはパートナー企業に開発体制があることが利用の前提です。
①AmiVoice Cloud Platform
AmiVoice Cloud Platformは、医療・保険・金融といった領域特化エンジンが用意されており、業界チューニング済みのエンジンを選択できます。提供形態は、従量課金制のクラウド音声認識API、専用サーバーを構築するオンプレミス型、オフラインで利用する端末組み込み型の3種類です。
利用できるエンジンはプランによって異なり、氏名・住所エンジンは専用サーバー構築型以上での提供となります。認識対象とする情報の種類を整理したうえでプランを選定します。
②SpeechRec
SpeechRecは、音声や映像など複数メディアのAI処理を統合的に扱えるAPIサーバとして提供されます。純国産のAIエンジンを採用しており、IVRやコールセンター会話などコンタクトセンター領域での提供実績があります。
NTT研究所で開発された深層学習ベースの音声認識エンジンを搭載した音声認識ソリューションで、電話・スマートフォン・マイクから入力された音声を認識します。
オンプレミスやプライベートクラウドへの構築に対応します。サーバーの設計・運用と、認識結果を利用する画面の開発は導入側の作業範囲となるため、体制と工数を含めて検討します。
③RECAIUS 音声認識サービス
RECAIUS 音声認識サービスは、クラウド型の音声認識エンジンをWeb APIで利用するPaaSサービスです。
ディープラーニング手法により話し言葉の認識に対応し、少量のデータで精度を高める辞書チューニング技術を備えます。入力音声は8kHzおよび16kHzのサンプリング周波数に対応します。
利用者ごとの辞書カスタマイズは標準のWebAPI提供ではなく個別対応となります。自社の商品名や業界用語を登録する運用を想定する場合、対応範囲を事前に確認します。
④COTOHA Voice Insight
COTOHA Voice Insightは、管理画面から商品名やサービス名などの固有名詞、業界用語を辞書登録でき、専用モデルの作成・学習にも対応します。
顧客の発話から感情の推移を表示する感情認識、オペレーターの話し方を自動評価する応対分析、要約などがオプションとして用意されています。
コンタクトセンター向けの音声マイニングプランとモバイル回線利用者向けのビジネス通話プランが用意されています。認識機能のみを自社システムへ組み込むのか、分析機能を含めて利用するのかを整理してプランを選定します。
（3）電話・CTI一体型
電話・CTI一体型は、クラウドPBXやIP電話サービスとして提供され、契約後に通話録音と文字起こしを利用できる構成が中心です。サーバー構築や既存PBXとの接続を伴わないため、導入までの期間が比較的短く、席数単位での契約に対応しやすい傾向にあります。
導入時には電話基盤の入れ替えを伴うことが一般的です。電話環境の刷新とあわせて検討する場合に該当する類型です。
①MiiTel Phone
MiiTel Phoneは、物理的な電話機を導入する必要がなく、インターネットに接続できる環境であれば場所を選ばず利用できます。通話録音、文字起こし、音声解析の機能が集約されており、Salesforceやkintoneなど外部ツールとの連携に対応します。
生成AIによる電話応答のフィードバック機能や、成果を上げているオペレーターの特徴を可視化してチーム内で共有する機能も実装されています。
オペレーターの応対内容の可視化とチーム内共有に対応した機能構成です。センター全体のVOC分析まで含めて要件とする場合は、分析対象とするデータの範囲と出力形式を確認します。
②BIZTEL コールセンター
BIZTEL コールセンターは、PBX機能とCTI機能をパッケージ化したクラウド型CTIです。音声認識・テキスト化機能を搭載しており、リアルタイムの文字起こしに対応します。
管理者が通話内容を確認し、オペレーターへのサポートを行う運用が可能です。CRMをはじめとする外部サービスとの連携にも対応します。
音声認識の対象範囲と課金条件は契約構成によって異なるため、見積時に確認する必要があります。
③InfiniTalk
InfiniTalkは、通話録音、自動音声応答システム、チャットアプリ、CRMなど、コールセンター業務で利用する機能を備えます。クラウド型に加えオンプレミス型も提供されており、社内規程や既存設備に応じて構成を選択できます。
クラウド型のCTIシステムで、複数のコールセンターやオフィスへの導入実績があります。
クラウド型に加えオンプレミス型も提供されています。音声認識を利用する場合の構成と対応エンジンについては、公開情報では確認できないため、問い合わせ時に個別に確認します。
④pickupon
pickuponは、通話音声をSalesforce、Mazrica Sales、HubSpotなどのCRM・SFAへ自動でテキスト入力するクラウドサービスです。AIが会話の重要な点を抽出し、顧客の言葉遣いや表現から性格傾向を分析します。受注数やコンタクト数を可視化する機能も備えます。
通話後に架電結果を確認する運用を前提とした設計です。通話中のリアルタイムモニタリングを要件に含める場合は、対応可否と代替手段を確認します。
（4）録音・データ管理基盤型
通話の録音と保管を主な機能とし、蓄積した音声のテキスト化・検索・チェックを扱う形態です。応対中の支援ではなく、通話後の記録管理とコンプライアンス対応を用途とします。既存の電話環境を維持したまま導入できる構成が中心です。
この類型では、認識機能に加えて保存期間、アクセス権限の設定粒度、暗号化の仕様が選定条件となります。記録の保存が求められる業種では、要件との照合を先に行います。
①YouWire
YouWireは、固定電話や携帯電話を用いた通話と、オフライン・オンラインの会議音声を一括で管理する録音システムです。書き起こし機能、頻出ワードやコンプライアンスリスクの検出、アクセス権限の管理に対応します。
録音データは暗号化され、音声認識エンジンによるテキスト化を経て分析データとして利用できます。オフィス電話、社用携帯、コールセンターの通話を自動録音してテキスト化する用途に特化した構成です。
大手キャリアの携帯電話や複数のPBXに対応しています。録音対象とする回線の範囲と、アクセス権限の設定粒度を自社の運用ルールと照合します。
②AI Log
AI Logは、通話内容をAIで自動テキスト化し、全件チェックを行う応対品質管理支援サービスです。テキスト化された通話は顧客とオペレーターの会話形式で表示され、再生音声に合わせて自動スクロールします。事前に登録した禁則ワードはハイライト表示され、コールスクリプトごとに登録した必須ワードが会話の一定範囲内に含まれるかを自動検知します。
夜間バッチまたは手動での音声ファイルアップロードによる運用を前提とします。料金は初期費用と月額費用に加え、音声認識エンジンの利用料で構成されます。チェック対象とする通話量と運用工数を踏まえて費用を試算します。
③GoodLine
GoodLineは、クラウド型PBXの機能として、場所に依存せず通話を録音します。録音データは通話時間に関係なく1年間分を保管でき、電話番号単位での録音可否の設定や、録音再生の権限設定に対応します。
オールインワンの基本機能に加えて独自機能を追加料金なしで提供する料金体系です。
クラウドPBXの機能として録音を提供する構成です。既存の電話環境を維持する前提か、回線の見直しを含めて検討するかによって、適合する範囲が変わります。
5．まとめ
音声認識は、定型的な会話であれば実用水準に達している一方で、氏名や住所、型番といった業務上重要な情報では認識が崩れます。通話全体の認識率という単一の指標で判断せず、項目別の取得率で評価することが、導入後の評価と想定を一致させる前提になります。
導入を検討する段階では、製品の比較よりも先に、自社の通話が定型化しているか、正確な取得が必要な情報の頻度が高いか、辞書更新を担う体制があるかを確認してください。この3点で適合するタイプが絞られ、比較の対象そのものが変わります。
株式会社ストラーツの「電話応対AIサービス」は、音声認識から応答の生成までをAIが担い、導入先の業務に合わせた個別設計に対応しています。氏名や住所など認識しにくい情報のヒアリング方法を調整できるほか、既存システムとの連携や必要な機能の追加も可能です。自社の電話業務に適したAI活用をご検討の場合は、ぜひご相談ください。実際のAI応対は、電話デモ（050-1724-1373）でも体験できます。
