【ITニュース解説】Voice AI for Business: Evaluation Guide and Pilot Scorecard

音声AIとは、人間が話す言葉を理解したり、作り出したり、あるいはその言葉を使って対話を行うソフトウェア全般を指す。特にビジネスの現場で利用されるものは、AI音声エージェントと呼ばれ、お客様からの電話に対して、会話をしながら、承認された様々な業務（例えば、商品の在庫を確認したり、お客様の問い合わせ内容をシステムに更新したり、よくある質問に答えたり、あるいは複雑な内容であれば担当者に電話を引き継いだり）を実行する。単に自然な声で話すだけでなく、正確で、かつ後からその結果を追跡できることが、ビジネスを円滑に進める上で非常に重要となる。

どのような音声AIが必要かは、どんな仕事を解決したいかという視点から考えるのが良い。例えば、ナレーションを作成するのか、既存の声を変換するのか、お客様からの電話に応答するのかで、求められる機能は大きく異なる。ただ単にテキストを音声に変換するデモだけでは、お客様が話した日付の修正に対応できるか、外部のシステム（API）からの結果を待てるか、未解決のリクエストを適切に転送できるか、といった具体的なビジネスの課題に対応できるかは判断できない。

音声AIにはいくつかの種類がある。一つは「音声生成」で、これはテキストを音声に変換し、ナレーションやアナウンス、または視覚に障がいを持つ人への情報提供などに利用される。この場合、発音が正確か、声のトーンや話し方が一貫しているか、出力の細かい調整が可能かといった点を評価する。次に「音声理解」は、話し言葉を聞き取り、それを文字に書き起こしたり、その意味を解釈したりする。ここでは、重要な名前や数字、多様な言語、お客様が話す言葉の修正をどの程度正確に理解できるか、実際の会話の録音を使って評価することが肝要だ。そして、ビジネスにおいて最も活用が期待されるのが「AI音声エージェント」である。これは、ビジネスツールと連携しながら対話を行うもので、タスクが正確に完了するか、お客様の割り込みに適切に対応できるか、システム障害時にどう振る舞うか、誰がそのタスクの責任を持つか、そして最終的にお客様がどのような体験をするか、といった点を多角的に評価する必要がある。製品を選定する際には、単に機能リストが長いからといって優れているわけではなく、同じシナリオでのデモンストレーションを行い、期待するシステムの結果が実際に得られるかを確認することが重要だ。

ビジネス音声エージェントの一般的な仕組みは、電話システム、話し言葉を認識するシステム、会話の流れを制御するロジック、会社の業務システム、そして音声を生成するシステムが連携することで成り立つ。中には、直接話し言葉から話し言葉へ変換するモデルを使う構成もある。いずれの場合も、エージェントは会話のやり取りの中で、お客様のリクエスト内容を最後まで保持し続ける必要があり、また、「提案されたアクション」（例:「この日時に予約しますか？」）と「完了したアクション」（例:「予約が完了しました」）を明確に区別できなければならない。例えば、病院の予約を考えてみよう。エージェントは、お客様が希望する病院の支店やサービスを理解し、利用可能な日時を読み上げ、お客様の同意を得た上で、予約システムに情報を送信する。そして、予約システムが実際に予約の成功を返したときに初めて、「予約が確定しました」とお客様に伝える。もし予約システムからの応答がタイムアウトして結果が不明な場合、やみくもに再試行すると、二重に予約を作成してしまう可能性もあるため、注意が必要だ。会話の流れだけでなく、背後で行われるシステムへのデータ書き込みといった「トランザクション」の評価も非常に重要である。お客様からのリクエスト、システムへの成功した書き込み、そしてお客様への最終確認は、それぞれ独立したイベントとして管理し、確認する必要がある。不確実な結果が出た場合にどう調整するか、そして最終的に誰がその問題の責任を持つかといったフォールバックの仕組みも事前に定義しておく必要がある。

AI音声エージェントを導入する際には、最初から全てを任せるのではなく、まず範囲が明確で、チームが結果をしっかりレビューできる一つの具体的な業務から始めることが成功への近道だ。広範な質問に答えさせようとするよりも、特定のタスクに絞ったパイロット導入の方が、問題が発生した際に原因を特定しやすい。会話を設計する前に、許可されるタスク、入力必須項目、処理の境界を明確に定義しておくべきだ。例えば、クリニックの受付であれば、「正確に予約が確定できたか、または担当者への引き継ぎが適切に行われたか」といった具体的な結果を測定する。リード獲得であれば、「合意された資格情報と次のステップが確認できたか」を測定する。タスク完了率を評価する際には、留守番電話になった通話など、タスク自体が開始されていない通話を含めて計算しないよう注意が必要だ。また、エージェントが報告する完了状況だけでなく、実際の業務システム（予約システムやCRMなど）に記録された結果をサンプルで確認し、それが本当に正確な情報であるかを検証する必要がある。

多言語に対応する音声AIを評価する際には、単に挨拶が複数の言語に対応しているかを見るのではなく、実際にタスクの成否を左右する言葉の組み合わせでテストすることが重要だ。特にインドのような多様な言語が使われるビジネス環境では、複数の言語が混ざった表現（コードスイッチング）、地元の名前、英語のサービス名、修正された日付などが日常的に使われる。そのため、実際の利用者が話す言語の組み合わせでテストセットを作成するべきだ。お客様の名前や場所だけで、どの言語を好むかを推測してはならない。例えば、予約のテストでは「金曜日に予約が欲しい。ごめんなさい、土曜の午後。Dr. メータで、Dr. メーラじゃない。」といった、実際の会話に近い複雑な修正や指示が含まれたシナリオを試すことが肝要だ。正しい結果とは、最終的に修正された「土曜の午後、Dr. メータ」を予約できることである。流暢な返答が返ってきても、間違った情報を保持していれば、それはタスク失敗となる。また、自然なアクセント、似た名前、割り込まれた回答、曖昧な金額、実際の環境に近い背景ノイズを含めるべきだ。テスト用音声素材を作成する際には、その言語に慣れている人に確認してもらい、デモンストレーション用に設定したデータセットとは別に、評価専用の「ホールドアウトセット」を用意することも重要だ。

導入に向けた評価では、具体的なスコアカードを使うと効果的だ。同じテストセットを使い、各システム構成に対してスコアをつける。評価する前に、各項目の重要度を示す重みを決定し、それぞれのテストケースでの合格条件を文書化する。例えば、「タスクが検証済みで完了したか（35%）」「重要な情報（クリティカルフィールド）の正確性（25%）」「お客様による修正に対応できたか（15%）」「担当者への引き継ぎが完全な情報を持って行われたか（15%）」「定められた時間内に応答できたか（10%）」といった項目に重み付けをして採点する。たとえ平均スコアが高くても、重要なアクションの失敗や、システムへの不正な書き込み、あるいは誤った情報でお客様に確認してしまうようなクリティカルな問題があれば、それは導入を妨げる要因とすべきだ。これらの問題は、個別の「導入許可条件」として設定することが重要である。また、評価時には、テストのサンプル数、対象となったワークフロー、使用言語、モデルのバージョン、連携したツールの設定なども記録しておくべきだ。特定の言語グループでの評価が少ない場合は、その限界も報告し、タイミングの比較などを行う際は、発信者の発話終了から最初の意味のある応答まで、といった同じ定義で計測することが大切だ。

音声AIの価格を比較する際は、単に1分あたりの料金を見るだけでは不十分である。「正しい結果あたりのコスト」で比較することが肝要だ。電話サービス、音声認識・生成サービス、会話モデルの利用料、プラットフォーム利用料、システム構築費用、サポート費用、そしてAIでは対応できなかった場合に人間が行うフォローアップの費用など、何が費用に含まれているのかを確認する必要がある。競合する複数の見積もりを比較する際は、同じ作業量と、実際にレビューして確認されたタスクの結果に基づいて、費用の内訳を標準化し、比較可能な形に整理する。例えば、月間の接続通話数、1通話あたりの平均時間、固定費、人間によるフォローアップ費用などを考慮し、「正しいタスク完了1件あたりにかかる費用」を算出する。もし、1分あたりのコストが安くても、エラーが多くて手動での修正が多く発生するようであれば、結果的に1タスクあたりの費用は高くなってしまう可能性があるため、注意が必要だ。

システムのデプロイメント（導入形態）については、クラウドとオンプレミスのどちらを選ぶかを検討する際、オーディオデータ、文字起こしデータ、会話モデル、ビジネスツール、そしてログデータがどこで処理され、どこに保存されるのか、全体のデータ経路を明確に書き出すことが重要である。例えば、AIモデルが自社のサーバー（オンプレミス）で稼働するとしても、連携する顧客管理システム（CRM）がクラウド上にある場合、電話回線が外部のサービスである場合、あるいはサポートシステムがクラウドにある場合、データの一部は依然として自社の境界外で処理されることを理解しておく必要がある。オンプレミスでの導入を検討する場合は、外部との接続が許可される範囲、システムのアップデート方法、バックアップ体制、オペレーターのアクセス権限、そしてピーク時の同時通話処理能力などを文書化し、実際に使用するハードウェアと設定に基づいた証拠を要求すべきだ。単に「月間何分使えるか」だけでなく、「同時に何件の通話に対応できるか」というキャパシティの確認も重要である。

デモンストレーション段階から実際の業務での稼働に至るまでには、実践的な手順を踏むことが推奨される。まず、解決したいタスクを一つに絞り、必須となる情報、成功の基準、行ってはいけないアクション、そしてAIで対応できない場合の最終的な担当者を明確に定義する。次に、通常の会話だけでなく、お客様による修正、言語の切り替え、曖昧なリクエストなど、現実的な代表的な会話パターンをテストする。さらに、システム障害が発生した場合（例えば、予約枠が満杯で取得できない、権限エラーが発生する、外部システムがタイムアウトする、データ書き込みが不確実になるなど）に、AIがどのように対応するかをテストすることも非常に重要だ。これらのテストを経て、限定的な範囲でパイロット導入を行い、実際の業務システムに記録された結果や、AIでは解決できなかった通話の内容を詳しくレビューし、そのフィードバックを元に設計を改善していく。本格的な展開時には、完了率、重大なエラー、エスカレーションされた通話の担当者、そしてワークフローや言語ごとのコストを継続的に監視する仕組みを構築する。そして最も重要なのは、導入前に必ず「ロールバックパス」、つまり問題が発生した際に、すぐに以前の状態に戻したり、人間に通話を転送したりする緊急対応策を準備しておくことだ。AIのプロンプト、モデル、ビジネスルール、連携するAPIのバージョンなどを変更した後は、以前は問題なく動作していたとしても、改めて障害がないかを確認する必要がある。

最後に、よくある疑問について触れておく。音声AIは音声認識や音声生成を含む広い概念であり、AI音声エージェントはその中で、対話を通じて特定のタスクを処理し、ツール連携や担当者への引き継ぎを行うシステムを指す。AI音声エージェントは、既存の自動音声応答システム（IVR）の一部を自然言語で処理できるよう置き換えることができるが、ダイヤルボタン入力（DTMF）、通話キュー、人間への転送といった機能は、依然として有用なフォールバック（代替手段）として残る可能性がある。最適な音声AIプラットフォームは、その企業のタスク、使用言語、既存システムとの連携要件、デプロイ形態、予算によって異なり、同じテストセットとシステム結果に基づいて比較することが不可欠だ。多言語AIは、一部のシステムで複数の言語が混ざった会話（コードスイッチング）に対応できるが、その能力は、実際の利用環境における名前、金額、修正日付などの複雑な言語の組み合わせで評価すべきだ。予約システムがタイムアウトした場合、結果は不確実なことが多い。その際は、リクエストIDなどを使って結果を照合し、やみくもな再試行は避け、予約が確認できない場合には担当者によるフォローアップを提案することが重要であり、未検証の予約を「確定済み」と報告してはならない。