音声操作
音声認識や音声合成 (TTS: text-to-speech) をアプリのユーザー エクスペリエンスに直接統合します。
音声認識: ユーザーが発声した単語を、フォーム入力やテキストのディクテーション用にテキストに変換し、操作やコマンドを指定したり、タスクを実行したります。 この機能は、フリーテキストのディクテーションと Web 検索向けの定義済みの文法、および Speech Recognition Grammar Specification (SRGS) バージョン 1.0 を使って作成されたカスタム文法をサポートしています。
TTS: 音声合成エンジン (声) を使って、テキスト文字列を音声に変換します。 入力文字列は、基本的でシンプルなテキスト、またはより複雑な Speech Synthesis Markup Language (SSML) のいずれかになります。 SSML は、発音、音量、ピッチ、速度、強調など、音声出力の特性を制御する標準的な方法です。
その他の音声関連のコンポーネント:Windows アプリケーションの Cortana ではカスタマイズした音声コマンド (発声したコマンドまたは入力したコマンド) を使って、アプリをフォアグラウンドで起動したり (スタート メニューから起動した場合と同様にアプリがフォーカスを取得します)、バック グラウンド サービスとしてアクティブ化したりすることができます (Cortana がフォーカスを維持しますが、アプリからの結果を表示します)。 Cortana UI でアプリの機能を公開する場合は、「Cortana voice command (VCD) guidelines」(Cortana 音声コマンド (VCD) のガイドライン) をご覧ください。
音声操作の設計
音声機能が適切に設計され、実装されていると、ユーザーがアプリを楽しく確実に操作できる手段になります。音声機能によって、キーボード、マウス、タッチ、ジェスチャを補完することも、場合によってはこれらの代替として使うこともできます。
次のガイドラインと推奨事項では、最適な形で音声認識と TTS をアプリの操作エクスペリエンスに統合する方法について説明します。
アプリで音声操作のサポートを検討している場合:
- 音声認識では、どのような操作を実行できるか。 ユーザーは、ページ間の移動やコマンドの呼び出しを実行できるか。また、データをテキスト フィールド、簡単なメモ、長いメッセージとして入力できるか。
- 音声入力はタスクの実行に適した機能であるか。
- 音声入力が利用可能になっていることをユーザーはどのように認識するか。
- アプリが常に聞き取りを行っているか、またはユーザーが操作を実行してアプリを聞き取りモードに切り替える必要があるか。
- どのような語句が操作や動作を開始するか。 語句と操作を画面に列挙する必要があるか。
- プロンプト画面、確認画面、不明瞭解消画面、TTS が必要か。
- アプリとユーザー間の対話ダイアログは何か。
- アプリのコンテキストに対してカスタムのボキャブラリや制約のあるボキャブラリが必要か (医学、科学、ロケールなど)。
- ネットワーク接続が必要か。
テキスト入力
テキスト入力用の音声は、短い形式 (1 つの単語または語句) から長い形式 (継続的なディクテーション) までさまざまなものがあります。 短い形式の入力は 10 秒未満の長さにする必要があり、長い形式の入力セッションは最大で 2 分の長さにすることができます (長い形式の入力はユーザーが操作しなくても再開でき、継続的なディクテーションのような印象を与えることができます)。
音声認識がサポートされていて、利用可能になっていること、およびユーザーが音声認識を有効にする必要があるかどうかを示すために、視覚的な合図を使うことをお勧めします。 たとえば、マイクのグリフが表示されるコマンド バー ボタン (「コマンド バー」をご覧ください) を使って、音声認識が利用可能になっていることやその状態を示すことができます。
実行中の音声認識に対するフィードバックを提供することで、音声認識を実行しているときに、不十分な応答性を最小限に抑えることができます。
キーボード入力、不明瞭解消のプロンプト、修正候補、追加の音声認識を使って、ユーザーが認識テキストを変更できるようにします。
入力が音声認識以外のデバイス (タッチ入力やキーボードなど) から検出された場合は、認識を停止します。 このような入力は、ユーザーが他のタスク (認識テキストの修正や他のフォーム フィールドの操作など) に移行したことを示している可能性があります。
音声入力がないときに認識を終了までの時間を指定します。 この時間が経過した後で音声認識を自動的に再開しないでください。これは、ユーザーがアプリの操作を停止したことを示している場合が多いためです。
ネットワーク接続が利用できない場合は、すべての継続的な認識 UI を無効にし、認識セッションを停止します。 継続的な認識には、ネットワーク接続が必要です。
コマンド実行
音声入力によって、操作の開始、コマンドの呼び出し、タスクの実行を行うことができます。
画面に余裕がある場合は、現在のアプリのコンテキストでサポートされている応答を、有効な入力の例と一緒に表示することを検討してください。 これにより、場合によっては、アプリで処理する必要がある応答を減らすことできます。また、ユーザーが入力に迷うことが少なくなる場合もあります。
できる限り具体的な応答を引き出せるように、質問を構成します。 たとえば、"今日は何をしたいですか?" は自由に応答ができる質問であり、さまざまな応答の可能性があるため膨大な量の文法定義が必要になります。 または、"ゲームをプレイしますか、それとも音楽を聴きますか?" という質問では、2 つの有効な回答のいずれか 1 つに応答が制限されます。このため、文法定義の量も少なくなります。 文法定義の量が少ないと作成が容易になり、認識結果の精度が向上します。
音声認識の信頼性が低い場合には、ユーザーに確認を求めます。 ユーザーの意図が明らかでない場合は、ユーザーが意図していない操作を開始するよりも、ユーザーの意図を明確にする方が、良い結果につながります。
音声認識がサポートされていて、利用可能になっていること、およびユーザーが音声認識を有効にする必要があるかどうかを示すために、視覚的な合図を使うことをお勧めします。 たとえば、マイクのグリフが表示されるコマンド バー ボタン (「コマンド バーのガイドライン」をご覧ください) を使って、音声認識が利用可能になっていことやその状態を示すことができます。
通常、音声認識のスイッチが画面から消える場合は、アプリのコンテンツ領域に状態インジケーターを表示することを検討してください。
音声認識がユーザーによって開始される場合は、一貫性を維持するために組み込みの認識エクスペリエンスを使うことを検討してください。 組み込みのエクスペリエンスには、プロンプト、例、不明瞭解消、確認、エラーが表示されるカスタマイズ可能な画面が含まれています。
画面は、指定した制約によって異なります。
定義済みの文法の場合 (ディクテーションまたは Web 検索)
- [聞き取り中] 画面。
- [認識中] 画面。
- [聞き取りの確認] 画面またはエラー画面。
単語や語句の一覧または SGRS 文法ファイルの場合
- [聞き取り中] 画面。
- [確認] 画面 (ユーザーの発言が複数の潜在的な結果として解釈できる場合)。
- [聞き取りの確認] 画面またはエラー画面。
[聞き取り中] 画面では、次の操作を実行できます。
- 見出しテキストのカスタマイズ。
- ユーザーが声に出すことができる内容のサンプル テキストの指定。
- [聞き取りの確認] 画面が表示されるかどうかの指定。
- 認識された文字列を [聞き取りの確認] 画面でユーザーに対して読み返す。
SRGS で定義された制約を使う音声認識エンジンにおける組み込みの認識フローの例を、次に示します。 この例では、音声認識に成功しています。
常に聞き取る
ユーザーが操作しなくても、アプリを起動してすぐに、音声入力の聞き取りと認識を実行できます。
アプリのコンテキストに基づいて、文法の制約をカスタマイズしてください。 これにより、音声認識エクスペリエンスがターゲットとして維持され、現在のタスクとの関連が継続されます。また、エラーを最小限に抑えることができます。
音声操作の項目
音声入力が有効になっているとき、どのような単語と語句が正確に理解されるか、またどのような操作を実行できるかを、ユーザーが検出できるようにすることが重要です。
音声認識がユーザーよって有効化される場合は、コマンド バーやメニュー コマンドを使って、現在のコンテキストでサポートされているすべての単語と語句を表示することを検討してください。
音声認識が常に有効になっている場合は、すべてのページに "音声操作の項目" という語句を追加することを検討してください。 ユーザーがこの語句を発声すると、現在のコンテキストでサポートされているすべての単語と語句が表示されます。 このフレーズを使うと、ユーザーは一貫した方法でシステムに実装されている音声機能を検出することができます。
認識の失敗
音声認識は失敗する場合があります。 オーディオ品質が低い場合、語句の一部しか認識できない場合、または入力がまったく検出されない場合は、音声認識が失敗する可能性があります。
失敗を適切に処理することで、ユーザーは認識が失敗した理由を理解し、回復することが可能になります。
音声入力が理解されなかった点と再試行する必要がある点を、アプリでユーザーに伝えてください。
サポートされている 1 つ以上の語句を例として提示することを検討します。 ユーザーは提示された語句を再度入力する可能性があります。これにより、認識が成功する確率が高くなります。
一致する可能性がある語句の一覧を表示し、ユーザーが選ぶことができるようにすることをお勧めします。 こうした対処方法は、認識プロセスを再度やり直すよりも効率的です。
別の種類の入力方法を常にサポートしてください。認識の失敗が繰り返し発生した場合、その失敗を処理する際に特に役立ちます。 たとえば、キーボード、タッチ入力、またはマウスを使って、一致する可能性がある語句の一覧から選ぶように提案します。
組み込みの音声認識エクスペリエンスを使います。この音声認識エクスペリエンスには、音声認識に失敗したことをユーザーに通知し、ユーザーが音声認識をもう一度試行できる画面が含まれています。
オーディオ入力の問題を検出し、修正を試みます。 音声認識エンジンでは、音声認識の正確さにマイナスの影響を与える可能性があるオーディオ品質の問題を検出できます。 音声認識エンジンから提供される情報を使うと、問題をユーザーに通知し、可能であれば対処するように指示することができます。 たとえば、マイクの音量設定が低すぎる場合は、もっと大きな声で話すことやボリュームを上げることをユーザーに求めることができます。
制約
制約 (文法) は、発声される単語や語句を定義します。これらの単語や語句は、音声認識エンジンによって照合することができる単語や語句です。 定義済みの Web サービスの文法のいずれかを使ったり、アプリと共にインストールされるカスタムの文法を作成したりすることができます。
定義済みの文法
定義済みのディクテーション文法と Web 検索文法を使うと、文法を作らずにアプリに音声認識を実装できます。 これらの文法を使った場合、音声認識がリモート Web サービスで実行され、結果がデバイスに返されます。
- 既定のフリーテキストのディクテーション文法では、ユーザーが特定の言語で話すほとんどの単語と語句を認識できます。これは短い語句の認識に最適化されています。 フリーテキストのディクテーションは、ユーザーが話す内容を限定しない場合に便利です。 一般的な用途としては、メモの作成やメッセージ内容の口述などがあります。
- Web 検索文法は、ユーザーが話す可能性のある多数の単語と語句を含んでいる点でディクテーション文法と似ています ただし、ユーザーが Web 検索で一般的に使う用語の認識に最適化されています。
注意
定義済みのディクテーション文法と Web 検索文法は容量が大きく、(デバイス上ではなく) オンライン上に存在するため、カスタム文法をデバイスにインストールした場合に比べるとパフォーマンスが劣る可能性があります。
このような定義済みの文法は、10 秒までの長さの音声入力を認識でき、開発者による作成作業は必要ありません。 ただし、ネットワークへの接続が必要になります。
カスタム文法
カスタム文法はお客様が設計および作成を行い、アプリと共にインストールされます。 カスタム制約を使う音声認識は、デバイスで実行されます。
プログラムによる一覧の制約は、単語や語句の一覧を使って単純な文法を作成する手法で、軽量です。 個別の短い語句を認識するには、一覧の制約が適しています。 文法にすべての単語を明示的に指定すると、音声認識エンジンは音声と単語の一致を確認する際に音声だけを処理すればよいので、認識の精度が向上します。 また、一覧はプログラムで更新することもできます。
SRGS 文法は静的ドキュメントで、プログラムによる一覧の制約とは異なり、SRGS Version 1.0 で定義された XML 形式を使います。 SRGS 文法では、1 回の認識で複数の意味をキャプチャすることができるため、音声認識エクスペリエンスを最大限に制御することができます。
SRGS 文法を作成するためのヒントを次にいくつか紹介します。
- 各文法の規模を小さくします。 文法に含める語句を少なくする方が、規模の大きな文法に多数の語句が含まれている場合よりも、認識精度が高くなる傾向があります。 アプリ全体に対して 1 つの文法を設定するよりも、特定のシナリオごとに別々の小規模な文法を設定することをお勧めします。
- ユーザーには、各アプリのコンテキストに基づいて何と話しかければよいかを知らせ、必要に応じて文法を無効にします。
- 文法は、ユーザーがさまざまな形でコマンドを音声入力できるように設計します。 たとえば、GARBAGE 規則を使って、文法で定義されていない音声入力を照合することができます。 これにより、ユーザーはアプリにとって意味を持たない語句を含めて話すことができます。 たとえば、"お願い"、"それと"、"ええと"、"多分" などの語句を含めることができます。
- 音声入力の認識率を高めるには、sapi:subset 要素を使います。 この要素は、部分的な語句の照合をサポートするための、SRGS 仕様に対する Microsoft の拡張機能です。
- 音節が 1 つしかない語句は、文法に定義しないようにしてください。 音節が 2 つ以上ある語句の方が、正確に認識されやすくなります。
- 同じように聞こえる語句を使わないようにしてください。 たとえば、"hello"、"bellow"、"fellow" などの語句を使うと音声認識エンジンが混乱し、認識精度が低くなる可能性があります。
注意
どの種類の制約を使うかは、作成する認識エクスペリエンスの複雑さによって決まります。 どの種類の制約も特定の認識タスクに最適な選択肢となる可能性があり、アプリですべての種類の制約を使う場合もあります。
カスタムの発音
一般的ではない単語や架空の単語を含む特殊なボキャブラリや、普通とは異なる発音の単語がアプリに含まれる場合は、カスタムの発音を定義することで、認識性能が高まる可能性があります。
単語や語句の一覧が小規模な場合や、あまり使われない単語や語句の一覧の場合、カスタムの発音を SRGS 文法で作成できます。 詳しくは、「token 要素」をご覧ください。
単語や語句の一覧が大規模な場合や、頻繁に使われる単語や語句については、発音辞書のドキュメントを別途作成することもできます。 詳しくは、辞書と音標文字に関するページをご覧ください。
テスト
音声認識の精度のテストとサポートされている UI のテストは、アプリの対象ユーザーに対して行います。 このようなテスト方法は、アプリの音声操作エクスペリエンスの有効性を判断するために最適な方法です。 たとえば、アプリが一般的な語句を聞き取らないために、ユーザーが良好な認識結果を得られない可能性があります。
このような場合は、該当する語句をサポートするように文法を変更したり、サポートされている語句の一覧をユーザーに提供したりします。 サポートされている語句の一覧を既に提供している場合は、その一覧を簡単に見つけることができるかどうかを確認してください。
音声合成 (TTS)
TTS では、プレーンテキストまたは SSML から音声出力が生成されます。
ていねいな言葉使いで音声入力を促すようなプロンプトを設計します。
長いテキスト文字列を読み取る必要があるかどうかを検討します。 1 つのテキスト メッセージを聞き取ることと、記憶するのが困難な長い検索結果の一覧を聞き取ることは別のことです。
ユーザーが TTS を一時停止または停止できるように、メディア コントロールを用意します。
すべての TTS 文字列を聞き取り、それらの文字列が明瞭かつ自然な話し方になっていることを確認します。
- 単語が不自然な順番で連続している場合や、文字列に含まれる数値や句読点を発声する場合に、語句が不明瞭になる可能性があります。
- 韻律や抑揚がネイティブ スピーカーによる発声と異なると、音声が不自然に聞こえる場合があります。
どちらの問題も、スピーチ シンセサイザーへの入力にプレーン テキストではなく SSML を使うことで対処できます。 SSML について詳しくは、「SSML による合成音声の制御」と「Speech Synthesis Markup Language (SSML) のリファレンス」をご覧ください。
このセクションの他の記事
トピック | 説明 |
---|---|
音声認識 | 音声認識を使って、入力を行ったり、操作やコマンドを指定したり、タスクを実行したりできます。 |
音声認識エンジンの言語の指定 | 音声認識に使われるインストール済みの言語を選ぶ方法について説明します。 |
カスタム認識の制約の定義 | 音声認識のカスタム制約を定義して使う方法について説明します。 |
継続的なディクテーションの有効化 | 長い形式の継続的なディクテーション音声入力をキャプチャし、認識する方法について説明します。 |
音声入力の問題の管理 | オーディオ入力の品質が原因で発生する音声認識の精度の問題を管理する方法について説明します。 |
音声認識のタイムアウトの設定 | 音声認識エンジンが無音または認識できないサウンド (雑音) を無視し、音声入力を待機する時間の長さを設定します。 |
関連記事
サンプル
Windows developer
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示