次の方法で共有


音声操作

音声認識とテキスト読み上げ (TTS または音声合成とも呼ばれます) をアプリのユーザー エクスペリエンスに直接統合します。

音声認識 音声認識は、ユーザーが話した単語を、フォーム入力、テキストディクテーション、アクションまたはコマンドの指定、タスクの実行のためにテキストに変換します。 自由テキストディクテーションと Web 検索用の定義済みの文法と、音声認識文法仕様 (SRGS) バージョン 1.0 を使用して作成されたカスタム文法の両方がサポートされています。

TTS TTS は音声合成エンジン (音声) を使用して、テキスト文字列を音声単語に変換します。 入力文字列には、基本的な、非対応のテキスト、またはより複雑な音声合成マークアップ言語 (SSML) のいずれかを指定できます。 SSML は、発音、音量、ピッチ、速度、速度、強調など、音声出力の特性を制御する標準的な方法を提供します。

その他の音声関連コンポーネント:Cortana Windows アプリケーションでは、カスタマイズされた音声コマンド (音声または入力済み) を使用してアプリをフォアグラウンドで起動するか (アプリはスタート メニューから起動されたかのようにフォーカスを取得します)、バックグラウンド サービスとしてアクティブ化します (Cortanaはフォーカスを保持しますが、アプリからの結果を提供します)。 Windows アプリ Cortana の操作を参照してください

音声操作の設計

慎重に設計および実装された音声は、ユーザーがアプリを操作したり、キーボード、マウス、タッチ、ジェスチャを補完したり、置き換えたりするための堅牢で楽しい方法です。

これらのガイドラインと推奨事項では、音声認識と TTS の両方をアプリの対話エクスペリエンスに最適に統合する方法について説明します。

アプリで音声操作のサポートを検討している場合:

  • 音声を使用して実行できるアクション ユーザーは、ページ間を移動したり、コマンドを呼び出したり、テキスト フィールド、簡単なメモ、または長いメッセージとしてデータを入力したりできますか?
  • 音声入力は、タスクを完了するための適切なオプションですか?
  • 音声入力が使用可能な場合、ユーザーはどのように認識されますか?
  • アプリは常にリッスンしているか、またはユーザーがアプリがリッスン モードに入るためのアクションを実行する必要がありますか?
  • アクションまたは動作を開始する語句は何ですか? 画面上でフレーズとアクションを列挙する必要がありますか?
  • プロンプト、確認、あいまいさを解消する画面または TTS は必要ですか?
  • アプリとユーザーの間の対話ダイアログとは
  • アプリのコンテキストには、カスタムまたは制約付きのボキャブラリが必要ですか (医学、科学、ロケールなど)。
  • ネットワーク接続は必要ですか?

テキスト入力

テキスト入力の音声は、短い形式 (単一の単語または語句) から長い形式 (連続ディクテーション) まで多岐にわたる場合があります。 短いフォーム入力の長さは 10 秒未満にする必要があります。一方、長いフォーム入力セッションの長さは最大 2 分です。 (長いフォーム入力は、ユーザーの介入なしに再起動して、継続的なディクテーションの印象を与えることができます)。

音声認識がサポートされ、ユーザーが使用できるかどうか、およびユーザーが有効にする必要があるかどうかを示す視覚的な手掛かりを提供する必要があります。 たとえば、マイク グリフを含むコマンド バー ボタン ( コマンド バーを参照) を使用して、可用性と状態の両方を表示できます。

認識中の明らかな応答不足を最小限に抑えるために、継続的な認識フィードバックを提供します。

キーボード入力、あいまいさを解消するプロンプト、提案、または追加の音声認識を使用して、ユーザーが認識テキストを変更できるようにします。

タッチやキーボードなどの音声認識以外のデバイスから入力が検出された場合は、認識を停止します。 これは、認識テキストの修正や他のフォーム フィールドとの対話など、ユーザーが別のタスクに移動したことを示している可能性があります。

音声認識が終了したことを音声入力が示さない時間を指定します。 通常、ユーザーがアプリとの連携を停止したことを示しているため、この期間の後に認識を自動的に再開しないでください。

ネットワーク接続が使用できない場合は、すべての継続的認識 UI を無効にし、認識セッションを終了します。 継続的な認識には、ネットワーク接続が必要です。

コマンド実行

音声入力では、アクションの開始、コマンドの呼び出し、タスクの実行を行うことができます。

領域が許可されている場合は、有効な入力の例と共に、現在のアプリ コンテキストでサポートされている応答を表示することを検討してください。 これにより、アプリで処理する必要がある潜在的な応答が減り、ユーザーの混乱も排除されます。

可能な限り具体的な回答を引き出すように、質問をフレームに収めてみてください。 たとえば、"今日は何をしたいですか?" は自由に応答ができる質問であり、さまざまな応答の可能性があるため膨大な量の文法定義が必要になります。 または、"ゲームをプレイしますか、それとも音楽を聴きますか?" という質問では、2 つの有効な回答のいずれか 1 つに応答が制限されます。このため、文法定義の量も少なくなります。 小さな文法を作成すると、はるかに簡単に作成でき、より正確な認識結果が得られます。

音声認識の信頼度が低い場合は、ユーザーに確認を要求します。 ユーザーの意図が明確でない場合は、意図しないアクションを開始するよりも明確にすることをお勧めします。

音声認識がサポートされ、ユーザーが使用できるかどうか、およびユーザーが有効にする必要があるかどうかを示す視覚的な手掛かりを提供する必要があります。 たとえば、マイク グリフを含むコマンド バー ボタン (コマンド バーの場合は Guidelines を参照) を使用して、可用性と状態の両方を表示できます。

音声認識スイッチが通常表示外の場合は、アプリのコンテンツ領域に状態インジケーターを表示することを検討してください。

ユーザーが認識を開始する場合は、一貫性のために組み込みの認識エクスペリエンスを使用することを検討してください。 組み込みのエクスペリエンスには、プロンプト、例、あいまいさの解消、確認、エラーを含むカスタマイズ可能な画面が含まれます。

画面は、指定された制約によって異なります。

  • 定義済みの文法 (ディクテーションまたは Web 検索)

    • Listening画面。
    • シンク画面。
    • あなたが言った画面またはエラー画面。
  • 単語または語句の一覧、または SRGS 文法ファイル

    • Listening画面。
    • ユーザーが言ったことが複数の潜在的な結果として解釈される可能性がある場合は、 Did 画面。
    • あなたが言った画面またはエラー画面。

Listening画面では、次のことができます。

  • 見出しテキストをカスタマイズします。
  • ユーザーが言うことができる内容のテキストの例を指定します。
  • 聞こえる画面を表示するかどうかを指定します。
  • 認識された文字列を、 Heard 画面でユーザーに読み取ります。

SRGS で定義された制約を使用する音声認識エンジンの組み込み認識フローの例を次に示します。 この例では、音声認識は成功しています。

sgrs 文法ファイルに基づく制約の初期認識画面

sgrs 文法ファイルに基づく制約の中間認識画面

sgrs 文法ファイルに基づく制約の最終認識画面

常にリッスンしている

アプリは、ユーザーの介入なしに、アプリが起動されるとすぐに音声入力をリッスンして認識できます。

アプリのコンテキストに基づいて文法の制約をカスタマイズする必要があります。 これにより、音声認識エクスペリエンスが非常にターゲットを絞り、現在のタスクに関連し、エラーを最小限に抑えることができます。

音声操作の項目

音声入力が有効になっている場合、ユーザーが理解できる内容と実行できるアクションを見つけやすくすることが重要です。

音声認識が有効になっている場合は、コマンド バーまたはメニュー コマンドを使用して、現在のコンテキストでサポートされているすべての単語と語句を表示することを検討してください。

音声認識が常に有効になっている場合は、すべてのページに "音声操作の項目" という語句を追加することを検討してください。 ユーザーがこの語句を言うときは、現在のコンテキストでサポートされているすべての単語と語句を表示します。 このフレーズを使用すると、ユーザーがシステム全体で音声機能を検出するための一貫した方法が提供されます。

認識エラー

音声認識は失敗します。 エラーは、オーディオ品質が低い場合、語句の一部のみが認識されたとき、または入力がまったく検出されない場合に発生します。

エラーを適切に処理し、認識に失敗した理由をユーザーが理解し、回復できるようにします。

アプリは、ユーザーが理解されておらず、もう一度試す必要があることをユーザーに通知する必要があります。

サポートされている 1 つ以上のフレーズの例を提供することを検討してください。 ユーザーは、推奨されるフレーズを繰り返す可能性が高く、認識の成功率が向上します。

ユーザーが選択する可能性のある一致の一覧を表示する必要があります。 これは、再び認識プロセスを実行するよりもはるかに効率的です。

代替入力の種類は常にサポートする必要があります。これは、認識エラーの繰り返し処理に特に役立ちます。 たとえば、ユーザーがキーボードを使用しようとしたり、タッチやマウスを使用して一致する可能性のある一覧から選択したりすることを提案できます。

組み込みの音声認識エクスペリエンスを使用します。これには、認識が成功しなかったことをユーザーに通知し、ユーザーが別の認識を試みることができる画面が含まれているためです。

オーディオ入力の問題をリッスンして修正してみてください。 音声認識エンジンは、音声認識の精度に悪影響を与える可能性があるオーディオ品質の問題を検出できます。 音声認識エンジンによって提供される情報を使用して、問題をユーザーに通知し、可能な場合は修正措置を取るようにすることができます。 たとえば、マイクの音量設定が低すぎる場合は、ユーザーに大きな声で話すか、音量を上げるよう求めることができます。

制約

制約 (文法) では、音声認識エンジンで照合できる音声の単語と語句を定義します。 定義済みの Web サービス文法のいずれかを指定することも、アプリと共にインストールされるカスタム文法を作成することもできます。

定義済みの文法

定義済みのディクテーションと Web 検索文法は、文法を作成しなくてもアプリの音声認識を提供します。 これらの文法を使用する場合、音声認識はリモート Web サービスによって実行され、結果はデバイスに返されます

  • 既定のフリー テキストディクテーション文法では、ユーザーが特定の言語で言うことができるほとんどの単語や語句を認識でき、短い語句を認識するように最適化されています。 フリー テキストディクテーションは、ユーザーが言える内容の種類を制限したくない場合に便利です。 一般的な用途としては、ノートの作成やメッセージのコンテンツのディクテーションなどがあります。
  • ディクテーション文法のような Web 検索文法には、ユーザーが言う可能性のある多数の単語や語句が含まれています。 ただし、ユーザーが Web を検索するときに通常使用する用語を認識するように最適化されています。

Note

定義済みのディクテーションと Web 検索の文法は大きくなる可能性があり、オンラインであるため (デバイス上にないため)、デバイスにカスタム文法がインストールされている場合ほどパフォーマンスが速くない可能性があります。

これらの定義済みの文法は、最大 10 秒の音声入力を認識するために使用でき、作成作業は必要ありません。 ただし、ネットワークへの接続が必要です。

カスタム文法

カスタム文法はユーザーによって設計および作成され、アプリと共にインストールされます。 カスタム制約を使用した音声認識は、デバイスで実行されます。

  • プログラムによるリスト制約は、単語または語句のリストを使用して簡単な文法を作成するための軽量なアプローチを提供します。 リスト制約は、短い個別の語句を認識する場合に適しています。 文法内のすべての単語を明示的に指定すると、音声認識エンジンは一致を確認するために音声のみを処理する必要があります。そのため、認識の精度も向上します。 一覧はプログラムで更新することもできます。

  • SRGS 文法は、プログラムによるリスト制約とは異なり、 SRGS バージョン 1.0 で定義された XML 形式を使用する静的ドキュメントです。 SRGS 文法では、1 回の認識で複数のセマンティック意味をキャプチャできるため、音声認識エクスペリエンスを最大限に制御できます。

    SRGS 文法を作成するためのヒントを次に示します。

    • 各文法を小さくします。 語句が少ない文法では、多くの語句を含む大きな文法よりも正確な認識が提供される傾向があります。 アプリ全体に対して 1 つの文法を使用するよりも、特定のシナリオに合わせていくつかの小さな文法を使用することをお勧めします。
    • アプリ コンテキストごとに何を言うかをユーザーに知らせ、必要に応じて文法を有効または無効にします。
    • ユーザーがさまざまな方法でコマンドを話すことができるように、各文法を設計します。 たとえば、 GARBAGE ルールを使用して、文法で定義されていない音声入力と一致させることができます。 これにより、ユーザーはアプリに意味のない追加の単語を話すことができます。 たとえば、"give me"、"and"、"uh"、"maybe"などです。
    • sapi:subset 要素を使用して、音声入力の照合に役立ちます。 これは、部分的な語句の照合に役立つ SRGS 仕様の Microsoft 拡張機能です。
    • 1 つの音節のみを含む語句を文法で定義しないようにします。 2 つ以上の音節を含む語句では、認識がより正確になる傾向があります。
    • 似た音の語句は使用しないでください。 たとえば、"hello"、"bellow"、"fellow" などの語句は、認識エンジンを混乱させ、認識精度が低下する可能性があります。

Note

使用する制約の種類の種類は、作成する認識エクスペリエンスの複雑さによって異なります。 特定の認識タスクに最適な選択肢は任意であり、アプリ内のすべての種類の制約の用途が見つかる場合があります。

カスタム発音

通常とは異なる単語や架空の単語を含む特殊なボキャブラリや、一般的でない発音の単語がアプリに含まれている場合は、カスタム発音を定義することで、それらの単語の認識パフォーマンスを向上させることができます。

単語や語句の小さなリスト、または使用頻度の低い単語やフレーズの一覧については、SRGS 文法でカスタム発音を作成できます。 詳細については、「 token 要素 」を参照してください。

単語や語句の一覧が大きい場合、またはよく使用される単語や語句の場合は、個別の発音辞書ドキュメントを作成できます。 詳細については、「 語彙と音素アルファベット について」を参照してください。

テスト

音声認識の精度とサポート UI をアプリの対象ユーザーでテストします。 これは、アプリでの音声操作エクスペリエンスの有効性を判断するための最適な方法です。 たとえば、アプリが一般的な語句をリッスンしていないために、ユーザーの認識結果が低くなっているとします。

この語句をサポートするように文法を変更するか、サポートされている語句の一覧をユーザーに提供します。 サポートされている語句の一覧を既に指定している場合は、簡単に検出できることを確認します。

テキスト読み上げ (TTS)

TTS は、プレーン テキストまたは SSML から音声出力を生成します。

丁寧で励みになるプロンプトを設計してみてください。

長い文字列のテキストを読む必要があるかどうかを検討します。 テキスト メッセージを聞くのは 1 つのことですが、覚えにくい検索結果の長い一覧を聞くのもまったく別の方法です。

ユーザーが TTS を一時停止または停止できるようにメディア コントロールを提供する必要があります。

すべての TTS 文字列が理解可能で自然な音になるように聞く必要があります。

  • 通常とは異なる一連の単語を一緒に文字列化したり、パート番号や句読点を話したりすると、語句が理解できなくなる可能性があります。
  • プロソディやケイデンスがネイティブスピーカーがフレーズを言う方法と異なる場合、音声は不自然に聞こえる可能性があります。

どちらの問題も、スピーチ シンセサイザーへの入力にプレーン テキストではなく SSML を使うことで対処できます。 SSML の詳細については、「 SSML を使用して合成音声を制御する および Speech 合成マークアップ言語リファレンスを参照してください。

トピック 説明
音声認識 音声認識を使用して入力を提供し、アクションまたはコマンドを指定し、タスクを実行します。
音声認識エンジンの言語を指定する 音声認識に使われるインストール済みの言語を選ぶ方法について説明します。
カスタム認識制約を定義する 音声認識のカスタム制約を定義して使う方法について説明します。
継続的なディクテーションを有効にする 長い形式の継続的なディクテーション音声入力をキャプチャし、認識する方法について説明します。
音声入力の問題の管理 オーディオ入力の品質が原因で発生する音声認識の精度の問題を管理する方法について説明します。
音声認識のタイムアウトを設定する 音声認識エンジンが無音または認識できないサウンド (雑音) を無視し、音声入力を待機する時間の長さを設定します。

 サンプル