対話業務支援ソリューション

ビジネス現場において、対話が発生する箇所は数多くあります。近年一般的となったビデオ会議システムや、窓口での業務補助・記録保存など現場での対話業務を支援するソリューションを提供しています。

音声翻訳ソリューションは多言語への翻訳をメインとしており、音声UI構築ソリューションはチャットボットを利用した人間と機械の対話システムをメインとしています。対話業務支援ソリューションでは、人間と人間の対話に音声システムを導入することで、現場業務の効率化を実現します。 代表的な事例として、ビデオ鍵システム、窓口対話システム、インタビュー支援システムの事例をご紹介します。

ソリューション事例

ビデオ会議システムの構成例

ビデオ会議システムの構成例 ビデオ会議システムの構成例

近年、ZOOM や Microsoft Teams 等のビデオ会議サービスが幅広く普及しています。ビデオ会議サービス内に音声や映像を保存したり、それを文字化する機能が搭載されているものもありますが、多言語対応に差があったり、専門用語の認識性能が不十分であったりする場合があります。また、記録された映像や音声を後日利活用するために、重量級のシステム開発が必要になってしまう事例もあります。

このようなときに、当社の 仮想マイクドライバを利用したシステムが有効です。パソコンの物理マイクで収録された音声は、まず仮想マイクドライバに渡されます(上図緑色部分)。仮想マイクドライバは、ビデオ会議システムから見ると、ひとつのマイクとして見えています。ビデオ会議システムのアプリケーションのマイクの設定から仮想マイクドライバを選択すると、物理マイクの音声が素通しされてビデオ会議システムに渡されるため、通常通りビデオ会議サービスを利用することができます。

この裏側で並行して、仮想マイクドライバはその内部でクラウドと通信することができ、音声認識話者識別感情認識等、必要な認識を行うことができます。それらの結果をパソコンで閲覧・保存することや、別のクラウドシステムに転送して保存することも可能です。クラウドに接続できない環境であれば、パソコンのローカルシステムでこれらの認識を行うこともできます。

ビデオ会議システム側で参加者ごとに書き起こしができている場合も、リアル会場側に複数人がいるケースでは、リアル会場側で「誰が」発話したかを識別するために話者識別機能を利用するなどして、ビデオ会議システムの書き起こし記録と組み合わせて利用することも有効です。

仮想マイクドライバに接続される物理マイクは、パソコンに搭載されているマイクだけではなく、一般の USB マイクや、当社製マイクアレイのTシリーズを利用することもできます。マイクアレイを利用する場合は、上図緑色部分に XFE を搭載します。

この方式では、ビデオ会議システムに渡される前の音声をキャプチャーしているため、後段のビデオ会議システムが何であっても利用することができるという汎用的なシステムを構築することができます。また、ビデオ会議サービスの流儀によらずして音声を蓄積して利活用できるため、自社のナレッジマネジメントシステムに統合するなどの応用的な利活用が促進されます。

この構成例は、音声翻訳ソリューションのビデオ会議システムの構成例と類似例ですが、合成音声を使わない分、リアルタイム性の制約が小さく、より応用範囲が広い構成例であると言えます。

窓口音声対話記録システムの構成例

窓口音声対話システムの構成例 窓口音声対話システムの構成例

この構成例は、音声翻訳ソリューションの窓口翻訳システム とほぼ同じ構成例であり、構成のポイントについては、そちらもを合わせてご覧ください。言語識別により機械翻訳が利用できる構成ですが、日本語がメインの環境であれば単に翻訳が実行されないだけです。この構成例では窓口での対話内容を書き起こして保存することができます。

訪日観光客の増加などの国際化の影響で、日本国内にある窓口であっても日本語だけで完結するということは今後ますます少なくなっていくことが見込まれます。窓口翻訳システムと窓口での対話記録は一体のものとして利用することが好ましいといえます。

窓口での対話を記録することで、どのような質問があるのか?どのような要求が多いのか?ということを定量的に把握することができるようになります。そのような定量的なデータは、業務全体の効率化のための基礎データとして利用することができます。コールセンター等で導入されているシステムと同様であり、そのリアル窓口版と言うこともできるシステムです。

インタビュー音声記録システムの構成例

インタビュー記録支援の構成例 インタビュー記録支援の構成例

上記の窓口音声対話記録システムと似た構成ですが、当社の Tumbler マイク(T-01) 等のデスクトップ型のマイクアレイを利用することで、インタビューなど少人数で行う対話記録の作成に特化したシステムを構成することができます。

Tumbler マイクを利用する場合、窓口のような 1 対 1 の対話だけではなく、麻雀卓のようにひとつのテーブルを3人または4人が囲むようなシチュエーションで、それぞれの参加者の声を別々に録音することが可能となります。インタビューや面接、グループミーティングのような場面の音声記録に有効です。このテクノロジーデモンストレーションは レコメモ を利用することで体験することができます。

まず、マイクアレイによって集音された多チャンネル音声信号から、音源定位によって、音源の方向が推定されます。次に、推定された音源の方向にビームフォーミング等の音声協調処理を行い、その方向の音声のみを集音し他の方向の雑音を抑圧する処理を行います。 これによって、例えば2人が同時に発話した場合であっても、それぞれの音声を分離して音声認識を行うことができるようになります。

このような音声強調処理は、音声UI構築ソリューションのサービスロボットの構成例や、音声翻訳ソリューションの窓口翻訳システムの構成例のように、屋外や商業施設内等の周辺雑音が大きい場所では必須です。 しかしながら、この構成例の場合は、会議室の中などの静穏環境で利用されることが想定されるため、周辺雑音を抑制するという観点からは、ビームフォーミング等の音声強調処理を必ずしも行う必要はありません。もちろん、その場合には同時に複数の発話があった場合に分離できないという問題が発生しますが、インタビューやグループミーティングの実例で、発話が重なる回数というのは必ずしも多い訳ではなく、そのような場面は捨象してしまうこともひとつの良い割り切りであると言えます。

その理由として、ビームフォーミング等の音声強調処理に足る音源定位性能は、環境によっては必ずしも達成できない場合があるという理由が上げられます。例えば、会議室にアクリルパーティションなどが設置される場合がありますが、パーティション越しの発話の場合には、音源定位性能が劣化する場合があります。別の例として、マイクに背を向けて(例えばホワイトボードの方を向いて)発話するような場合にも、音源定位性能が悪化します。 音源定位に失敗した場合、真の発話方向に安定的にビームを構築することができません。その場合であっても、適切な設計であれば無処理の場合と比較して性能が劣化するということはありませんが、発話のされ方によって同時発話には対応できないケースがあるということは事実であるため、同時発話の分離に失敗したケースへの対応が必要になり、GUI の作りこみを含めて全体システムが複雑になります。レコメモはそのようなケースまで想定して作りこまれていますが、実際には同時発話が起こる回数が多くはないことを鑑みると、必ずしも常に必要であるとは言えません。

ビームフォーミング等の音声強調処理を行わない場合、発話区間抽出された音声はそのまま音声認識が実行されます。別途音源定位が実行され、音源方向が推定されます。音源方向の推定が失敗した場合にも単に音源方向が不明であるというだけで音声認識結果は得られているためシステムとして問題はありません。前述の通り、同時発話に対応できないことと、ビデオ会議システムなど会議室に別のスピーカーがある場合に、そちらの音声に反応して不正確な音声認識結果が出てしまう可能性があることなどのデメリットは残ります。システムのシンプルさを取るか、多様なケースへの対応力を取るかというのは設計上の要点であると言えます。

誰が発話したか?という観点のみであれば、話者識別を利用することも有効です。音源定位の場合は、どの方向から発話されたか?という情報で誰が発話したかということを間接的に推定していました。話者識別を使う場合は、音声データのみから誰の発話であるかを直接的に推定できます。この場合は、別途マイクアレイを利用しなくても、ノートパソコンの内蔵マイクでも実現することが可能でよりシンプルです。詳細については下の囲み記事も合わせてご覧ください。

クラウド側では音声認識だけでなく、音声態度認識や、音声感情認識を組み合わせることで、ミーティングでの対話内容をより詳細に分析することができるようになります。その他にも、誰の発話時間が長かったか?複数人の参加者がいるとき誰と誰がよく対話しているか?誰が質問し誰が答えているか?など、対話を分析するための様々なメソッドが知られています。

最近では、ChatGPT のような大規模言語モデルを利用することで、対話内容を適切に要約することも可能になってきており、ミーティングの参加者それぞれの発言要旨を AI が自動的に要約して記録することができ、この構成例のようなシステムの重要性はますます大きくなってきていると言えるでしょう。

会議支援システムの典型的な構成

1. 会議支援システムの二大機能
会議支援システムには、二つの大切な機能があります。一つは誰が発話したかということ、もう一つは何の発話をしたかということです。後者は典型的に音声認識機能(書き起こし)として知られています。二つの機能をどちらも備えたシステムもあれば、どちらか片方だけしか備えていないシステムもあります。

書き起こしを行わず、誰が発話したか?という情報だけでは意味のある会議支援システムにはならないと考える人もいるでしょう。しかし、そんなことはありません。会議に参加している人同士がどのように会話をしたかという情報を解析することで、会議の質を高めることや、振り返り、教育効果を高めるなどの効果があることが知られています。 例えば、誰の発話時間が長かったか、逆に誰がほとんど発話していなかったか、誰と誰が特に会話していたかなどの情報を振り返ることなどが有効で、必ずしも書き起こしを行う必要はありません。

これとは逆に、発話内容の書き起こしのみを行うシステムとしては、いわゆる「発言録・議事録サービス」として、近年、ブラウザで利用するウェブサービスが多くの会社からリリースされています。リアルタイムで音声認識結果を表示できる機能がメインとなりますが、それらのサービスの中には、誰が発話したかという情報も同時に取得できるものもあります。

2. 誰が発話したか?を推定する手法
誰が発話したか?という観点には、二つの大きな観点が含まれます。一つ目の観点は、異なる人が発話した音声を別々に取得する(つまり分離する)という観点です。会議の音声は当然に複数人の発話が録音されていますから、誰が?を特定する前に、異なる人の発話をそれぞれ別々に取得することが必要です。誰が?を特定せずとも、異なる人が話したという情報だけでもユースケースによっては十分であることがあります。この観点は、「話者分離(Speaker Diarization)」と呼ばれる技術です。

二つ目の観点は、分離された音声に対して誰が話したか?ということを決定するという観点です。例えば、その発話は藤野の声であるということを特定するということですね。この観点は「話者識別(Speaker Identification)」又は「話者認識(Speaker Recognition)」と呼ばれる技術です。別の言葉で「話者認証」や「声紋※1認証」という言葉も聞かれると思います。それらはバイオメトリクス認証の世界に含まれる技術体系で、本人性をより強力に確認する技術であり、使われる特徴量などを含めて似た内容の技術ではありますが、目的が異なります。話者識別が複数人が含まれるグループの中から誰が発話したかをクラス分類するのに対して、話者認証は本人であるか否かを極めて正確に二値分類することを目的としているということです。

さて、すでにお気づきの方もいらっしゃるかもしれませんが、技術的に見るとこの二つの観点は、前者は教師無し学習であるクラスタリングの問題、後者は教師有り学習であるクラス分類の問題として定式化できます。それぞれ簡単に紹介します。

2.1. 話者分離(スピーカーダイアリゼーション)
複数の人が交代交代に発話をしている状況で、発話を発話者ごとに分類する技術です。最初の発話はAさんの発話、次の発話はBさんの発話、そしてまたAさんに戻って…というような具合ですね。この段階では「誰が?」は未決定なので、便宜的にAさん、Bさんとしていますが、話者が異なるということしか分かっていない状況です。これだけでも十分有用であり、例えば Google Cloud Speech-to-Text サービスでは、スピーカーダイアリゼーション機能がプレビュー版として公開されています。多くのウェブベースの議事録システムは、このようなメガIT企業のクラウドサービスに実装された話者分離機能を利用しているのではないでしょうか。

話者分離の内部処理としては、基本的には入力音声を発話区間に区分け※2したあと、発話区間ごとに「話者ベクトル」と呼ばれるその人特有の声の特徴量を算出し、クラスタリングしていくことで着目している発話区間がどの話者クラスタに含まれるかを推定します。話者ベクトルの算出方法や、クラスタリングの手法などは現在も研究が進んでいる分野です。 発話区間ごとに算出される特徴量に依存した手法であるため、発話区間が短すぎる場合、例えば、「はい」や「うん」などの短発話の場合には、話者ベクトルの信頼性が低くなり、適切にクラスタリングできないという本質的な課題があります。

ここで、複数の人が同時に発話してしまった場合に、重なった音声を分離してそれぞれの人の音声を抽出するということは基本的には話者分離のタスクの範囲外です。話者分離のタスクでは、発話が重なる(overlapped)状況は基本的には想定されていません。発話が重なった場合、話者ではなく、音声データ自体を分離しなければならないことになり、これは「音声分離(Sound Source Seperation)」と呼ばれる技術体系になります。話者分離と音声分離は異なる技術です。

さて、このような話者分離アルゴリズムは特徴として、入力音声がモノラル音声でも利用できます。つまり、ノートパソコンに内蔵された普通のマイクでもそのまま利用できるということで利便性が高いものです。しかしその反面として、発話が重なってしまった場合に対応できないといった課題もあります。

ここで、マイクアレイというデバイスが登場します。マイクアレイとは、複数のマイク素子が並んだ特殊なマイクで、入力音声が多チャンネル音声になります。ステレオ音声と言えば、左と右の2チャンネル音声として有名ですが、マイクアレイの多チャンネル音声は、マイク素子の数だけチャネル数があることになりますので、例えば4チャンネル音声や、8チャンネル音声なども一般的になります。USBなどでパソコンに接続する外付けデバイスで、当社でも Tシリーズ として販売しています。

このような多チャンネル音声を利用することで、新たに音源方向の推定ができるようになります。音がどっちの方向からやってきたか分かるということですね。この技術は「音源定位」と呼ばれる技術で、当社では XFE ライブラリ の LOC モジュール として提供しています。

これまでの話では、話者ベクトルをクラスタリングすることで異なる人の発話を識別していました。音源の方向が分かるということは、「異なる方向からやってきた音声は、異なる人が話した音声である」という前提が正しければ一発で異なる人の発話を識別できることになりますね。そしてこの前提は、会議室などではおおむね正しいと言えます。例えば麻雀卓などを想像してください。それぞれの席は固定されており、方向が違えば違う人の発話だと言えそうですね。この考え方が、音源定位を用いた話者分離です。

音源方向は、「はい」や「うん」のような短発話であっても比較的精度よく推定できるため、話者ベクトルのクラスタリングの手法と比べて短発話にも相対的に頑健であるという特徴があります。ただし、音源定位の角度情報、例えば0°方向といった数値の実環境での決定精度は十分高くはないため、だいたい0°~20°といった範囲で推定されます。

そして多チャンネル音声を利用することでもうひとつ良いことがあります。それは、前述の音声分離が容易になるということです。複数の人が同時に発話してしまったとき、それぞれの人の発話音声を分離して取得することができるようになるのです!片方の人の発話が綺麗に消えるので、まるで魔法のような感じがします。

多チャンネル音声を利用した音声分離には多くの手法が知られていますが、当社ではビームフォーミングという技術体系を利用した音声分離手法を主に採用しており、 XFE ライブラリの BF モジュール として販売しています。なお、多チャンネル音声を利用せず、モノラル音声での音声分離も研究されていますが実用的な性能を出すには至っていません。

いろいろな概念が登場しましたが、まとめると、話者分離の実現方法には、話者ベクトルをクラスタリングする方法と、音源定位を用いる方法があります。前者はモノラル音声でも実現できる反面、短発話に弱く、複数人の発話が同時に重なったときには対応できません。後者は多チャンネル音声が必要なのでマイクアレイという専用デバイスが必要になる反面、短発話にも強く、複数人の発話が同時に重なっても、それぞれの音声を分離して取得することができるという特徴があるということです。

次の節では、一歩進んで、誰の?を特定する話者識別について簡単に見ていきましょう。

2.2. 話者識別
われわれ人間は、声を聴くだけで、誰の声であるかが分かります。これを機械に実行させる技術であり、「話者識別」もしくは「話者認識」と呼ばれます。

事前に発話者の声を学習させておき、入力音声が事前学習されたどの話者であるかをクラス分類します。入力音声が事前学習された話者ではないと判定された場合、登録外の話者であるという出力が得られます※3。当社では、 mimiⓇ SRS という名称でクラウドサービスを提供しており、2分程度の短い音声のみで事前学習が完了します。

識別を行うときには、少なくとも5秒程度の音声が必要になります。このため、「はい」や「うん」といった短発話のみでは正確な話者識別結果を得ることができません。アカデミックな研究課題として「short utterance(短発話)話者識別」という分野はありますが、未だ研究途上で実用に足る性能には至っていないといえます。私たちの直観には反するかもしれませんが、私たち人間もこのような短発話を音声だけで識別していない可能性が高く、対話内容の文脈や、音源方向、視覚など、他のモダリティを無意識的に組み合わせて識別しているようです。

話者識別の処理の流れは、前述の話者分離において、異なる人の発話であると判定された各発話について、それぞれ話者識別器に入力し、その発話が誰の発話であったかを判定するという流れになります。

ここで、話者分離が話者ベクトルに基づくクラスタリングで実現されている場合、各発話にはAさん、Bさんというように仮ラベルが振られている状況です。それぞれの仮ラベルに対して話者識別が実行され、例えばAさんは藤野だった、ということが決定されます。短発話に弱いという特徴は引き継がれています。また、複数人の同時発話が存在する場合には、話者分離精度も劣化する上、話者識別精度も大きく劣化するため、その区間についてはほぼ決定できないことになります。

これに対して、話者分離が音源定位に基づいて実現されている場合、各発話には、音源方向が推定されている状況です。例えば、ある発話は0°方向、ある発話は90°方向といった具合ですね。それぞれの方向(の範囲)に含まれる発話に対して話者識別が実行され、例えば、0°方向の音源は、藤野の声だった、ということが決定されます。音源定位は相対的に短発話に強いので、話者分離が短発話に弱いという特徴をカバーしてくれています。さらに音源分離が実行できているため、同時発話にも対応できます。

話者識別には事前学習が必要でした。つまり、会議支援サービス利用とは別のタイミングでユーザーに学習用音声を録音してもらう必要があり、これは煩雑なUXです。このため、事前学習とサービス利用を同時化させる工夫がなされることがあります。話者分離された各発話の音声を学習データとして利用するという方法です。 サービス利用の初回時には、誰が発話したかは判定できないので、その仮ラベルは、もしくはその方向の音声は、藤野の音声である、竹崎の音声である、というように正解を与えます。それによって話者識別器を学習させることができるということです。

このように、話者分離さえ適切に実行できていれば、そのシステムに話者識別を後付けで導入することは技術的にもUX的にも自然な形で導入することが可能になります。

3. 音声認識による書き起こしと同時発話
話者分離と音声認識は独立した概念であり、話者分離を行わなくても音声認識だけを行うことはできます。当社では多言語の音声認識による書き起こし機能を mimiⓇ ASR というクラウドサービスとして提供しています。これに対して、音声分離と音声認識は関連する概念です。二人が同時に発話して音声が重なってしまうと、その音声を分離しなければ、それぞれの発話を正確に音声認識することはできません。

しかしながら、実際の会議シーンで、二人以上の意味のある発話が同時に重なる場面というのは多くはありません。もちろん「相槌」を打つということはありますが、相槌の音声というのは通常は音量が小さく最近の音声認識エンジンであれば、相槌程度の雑音であればそれを無視してメインの発話のみを正確に書き起こす性能があります。

次に多いのは、相手の発言の末尾を「食う」ような、発話末に重ねて次の人が発言するような場面です。これを正確に音声認識するためには確かに音声分離が必要になり、多チャンネル音声を利用したビームフォーミングなどの音声分離技術は有効です。会議とは異なりますが、窓口での係員と顧客の対話などではこのような音声の重なりの頻度は大きくなる傾向がありますが、このようなシーンに対応するか、頻度が少ないとして無視するかは、製品企画・システム設計上のひとつの要点であると言えるでしょう。

4. 現実の会議室への適応
マイクアレイを用いたシステムは、専用デバイスが必要であることを除けば良いことばかりであるように思えます。しかし、現実の会議室では必ずしも理論通りに上手くいくとは限らないということが知られています。

まず、話者分離の基本となる音源定位ですがこの性能が出ない場面があります。例えばアクリルパーティションの存在が挙げられます。感染症予防対策などで導入が進んだ会議室のアクリルパーティションですが、この存在が音源方向推定を大きく惑わします。アクリルパーティション越しの直接的な発話であっても音源方向がボヤケますが、複数のアクリルパーティションが置いてあると、マイクとパーティションと発話者の位置関係に依存して複雑な反射波が発生してしまうということも原因のひとつです。

次に、発話者の発話の仕方によっても音源定位の性能が劣化する場合があります。上で麻雀卓の例を説明しましたが、現実の会議では必ずしも同じ位置に座ったまま発言をしているだけではありません。例えば、立ち上がってホワイトボードに書きながら(ホワイトボードの方を向いたまま)発話するというシーンもあるでしょう。マイクの方を向かず、ホワイトボードの方を向いているので、ホワイトボードに反射した音声がマイクに到達することになります。このような状況でもやはり音源定位性能が劣化します。会議室のサイズが大きすぎる場合なども同様で、参加人数が多すぎると、音源方向の差が小さくなってしまい、精度が足りないということも発生します。

会議支援システムには、これらの精度不足によって発生する出力の間違いを後から簡単に修正できるユーザーインターフェースを持つことが重要であるといえます。当社では、2020年にリリースした レコメモ というデモサービスを通して、マイクアレイを利用した会議支援システムが、どのようなUI/UXを持つべきかという知見を蓄積しています。

また、最近の会議では、オンライン・オフラインのハイブリッド会議も多く見られます。オンライン会議の音声データについては、例えば Microsoft Teams などでは、その内部で参加者ごとに書き起こしを実行することができます。この場合は会議室側にあるスピーカーから出力される音声については、会議支援システムとしては無視できることが好ましいと言え※4、マイクアレイに対してある特定の方向から到来した音声は無視するというような仕組みとすることもよい仕組みであると言えます。どのような仕組みであるにせよ、ハイブリッド会議において、ビデオ会議システムが出力する認識結果と、リアル会議室側に参加している複数の参加者の認識結果をどのように統合していくかということは今後の課題のひとつであるといえるでしょう。

最近ではChatGPTに代表される大規模言語モデルを利用することで、長い文章を適切に要約することも可能になってきています。「誰が、何を、いつ、どのように発話したか」という情報を記録できる発言録システムのニーズは今後ますます高まっていくものと予測されます。

脚注


[1] 慣用的に良く言われる「声紋」ですが、指紋のように明確なものとは異なります。テレビ番組などではよく周波数スペクトルを表示してそれがあたかも声紋であるかのように表現していますが、それは単なるスペクトルであって、直ちに話者を識別できるものではありません。つまり、そこから何らかの特徴量が得られて、その特徴ベクトルこそが声紋足り得る存在であると理解する方が現代的ではないでしょうか。これは、話者識別の研究の世界では「話者ベクトル」と呼ばれるもので、この話者ベクトルの中身はディープラーニング技術の発展に伴ってより洗練されたものとなっています。

[2] 発話区間抽出器(Voice Activity Detector)、略称VADが利用されます。入力音声に含まれる無音の時間などを手掛かりに、長い音声から発話区間を抽出していきます。当社でも XFE ライブラリの VAD モジュールとして提供しています。

[3] これは当然のことであるように思われますが、ナイーブに実装すると最も似た声質の話者を返すという仕組みになってしまい、実用上の問題が発生します。登録外の話者であるということを判定するためには話者識別器に工夫が必要です。

[4] 会議システムを通することで音声が劣化し、会議室のパソコンもしくはモニターのスピーカーから再生されることでさらに劣化し、さらにそのスピーカーとマイクアレイとの間には通常数メートル程度の距離があるため、その距離によっても音声認識率は低下します。このため、会議システムの音声は会議システム側(もしくは仮想オーディオドライバを組み込んだローカル側)で認識することが好ましいといえ、スピーカーから会議室に再生された音声を利用するべきではありません。

使用シーン例

  • サイネージ

    サイネージ

    多言語対応の音声案内サイネージに利用可能です。外国人観光客等が、何の事前準備もなく、単にサイネージに話しかけるだけで動作するため、直観的に利用してもらうことができます。

  • スマホ

    スマホ

    多くの機械翻訳専門アプリがありますが、そういった専門アプリの開発だけでなく、自社アプリの中に翻訳機能を埋め込む等の付加価値向上が可能です。チャットツールへの翻訳機能の追加は特に利便性を高めます。

  • 公共交通機関

    公共交通機関

    バスやタクシー等の座席に設置されているタブレット端末を多言語音声対応させることが可能です。特に XFE と組み合わせることで、車内の走行音等を抑制し高精度な音声認識を実現することができます。

  • 窓口対応

    窓口対応

    小型で持ち歩ける翻訳専用端末などを利用することもできますが、透明ディスプレイやタブレット端末等の窓口に設置できるタイプの非接触型翻訳システムとして利用することができます。

  • ウェブ会議

    会議

    ウェブ会議システムでは、ベンダーが翻訳機能を組み込んで提供している場合も多くありますが、翻訳機能のないウェブ会議システムや、独自の WebRTC ベースの通信システム等に外部的に音声翻訳機能を付与することができます。

導入事例

駅案内ロボット

mimiエッジAIとクラウドAIの多くの機能を活用した駅構内・周辺案内業務用コミュニケーションロボットです。多くの人が行きかう雑踏騒音環境でも、目の前の人の声だけを聞き取り正確な応答を実現しています。話しかけた言語は自動で識別され、多言語での応答を行うことができます。これにより駅員の質問対応業務時間を削減することに成功しました。

オムロンソーシアルソリューションズ株式会社

詳しく見る

導入事例

バーチャルアテンダント

mimiエッジAIとクラウドAIの多くの機能を活用したデジタルサイネージ向けの音声対話システムです。多くの人が行きかう雑踏騒音環境でも、目の前の人の声だけを高速かつ正確に聞き取り、画面表示と連動した分かりやすく親しみやすい応答を実現しています。

株式会社モノゴコロ

詳しく見る