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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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