外部の音声文法を使用する

対話型音声応答 (IVR) アプリケーションと、音声アプリケーションの広範な音声認識タスクでは、制約付きリストまたは "文法" ベースの認識が大きな利点を提供します。 最新の音声テキスト化 (STT) AIエンジンで使用されている従来のセマンティック ベースの音声認識を、精度、パフォーマンス、コストの面ではるかに上回るものです。 このようなパフォーマンスの向上は、文法に基づく認識では、認識出力をあらかじめ定義されたルールセットに制約することができるため、精度が向上するためです。

文法は、W3C 仕様で詳しく説明されているように、音声認識文法仕様 (SRGS) に準拠しています。 リクエストがエンジンに入ると、エンジンは話し言葉の音声 (「発話」) をテキストに変換します。 エンジンは次に、認識されたテキストを文法や、発音辞書などの関連アーティファクトと比較します。 このプロセスは、リテラル文字起こしまたは文法内で提供される情報に文法が制約する解釈を提供します。 文法に組み込まれている ECMAScript などの追加のロジックにより、解釈をさらに洗練できます。

制約付き音声認識は次のような場合に最適です:

• 制約付きリスト (住所、株価ティッカー、郵便番号、部署名など) の認識。

• 英数字文字列の認識 (追跡番号、口座番号、確認コードなど)。

  • 位置の制約を含む。 たとえば、メンバー ID の最初の 2 文字は AN、FD、NT で始まります。 位置制約のもう 1 つの例は、車両識別番号です。

• 英数字または数字の認識とチェックサムまたは同様の制約。 たとえば、Luhn チェックサムのあるクレジットカード番号。

• 特定の単語やフレーズを発言する指示対話アプリケーション。

音声文法の作成

Grammar XML (GrXML) を使用して、制約付き音声文法を記述します。 他の XML ドキュメントと同様に、文法ファイルは、文法の特定の特性を指定するヘッダーで始まる必要があります。 文法ファイルの本文は、文法によって認識される話し言葉を定義する文法規則と、認識された項目が返す対応する変数値で構成されます。

文法ファイルのヘッダー

文法ファイルのヘッダーは、XML 宣言と、ドキュメント言語、ルート、名前空間を指定する <grammar> 要素で構成されます。

<?xml version="1.0" encoding="UTF-8" ?>

<grammar xmlns="http://www.w3.org/2001/06/grammar"

version="1.0" xml:lang="en-US" root="YesNo"

tag-format="swi-semantics/1.0">

XML 宣言とエンコードの種類

ヘッダーの最初の要素は常に XML 宣言となります。 この要素は、ドキュメント (1.0 または 1.1) で使用される XML のバージョンを指定します。 ドキュメントに適用されるエンコーディングも指定され、使用できる言語とできない言語が決定します。

バージョンとエンコードは必須の属性です。 基本設定 (コンピューターの設定やテキスト処理アプリケーションなど) に適したエンコーディングを使用します。 制約付き音声認識エンジンでは、どのエンコードを使用しても問題ありません。

さまざまな言語の代表的なエンコーディングの一覧を次の表に示します:

ほとんどの言語は、複数のエンコードで表すことができます。

実行時に、Unicode 国際コンポーネント (ICU) ライブラリを使用して、文法ファイルのエンコードが UTF-16 形式に自動的に変換されます。 Unicode コンソーシアムの公式サイトは http://site.icu-project.org/ です。

言語、名前空間、セマンティック タグの形式

ヘッダーの 2 番目の要素は <grammar> 要素で、その属性はドキュメントの既定情報を指定します。 必要な属性は次のとおりです:

• xml:lang: IETF Web サイトの RFC 3066 (コメント要求) ドキュメントで定義されているように、使用する既定の人間の言語の識別子を指定します。

• Microsoft では、さまざまな言語をサポートしています。 選択する言語は、文法エンコードの種類と互換性がある必要があります。

• version: GrXML (1.0) のバージョンを指定します。

• xmlns: 文法の名前空間を指定します。 GrXML 文法の場合、この指定は常に http://www.w3.org./2001/06/grammar。

• tag-format: 文法本体の <tag> 要素内のスクリプトが値を割り当てるために使用する書式を定義します。

タグ形式は、次のいずれかの文字列である必要があります。

Dictionaries

場合によっては、制約のある音声認識エンジンでは通常解析できない単語やフレーズを文法に含める必要がある場合があります。 たとえば、名前は発音やスペルが異なる場合があります。都市名 "Worcester" の場合、発音として "wih-sta" と呼ばれることがあります。

<lexicon>要素を使用して、文法ファイル内の一致するテキストに発話をマップする辞書をインポートします。

文法ファイルの本文

文法ファイルのメイン セクションには、文法を実際に定義するルール (認識する音声の単語と語句、認識される項目ごとにメイン アプリケーションに返す値) が含まれています。

ルール

文法ファイルの本文は、GrXML <rule> 要素を使用して定義された規則で構成されます。 各ルールには一意の識別子があります。 各ルールには、<item> 要素または <token> 要素内のテキストとして認識される語句がリストされています。 これらの要素は、他の GrXML 要素内に入れ子になっている可能性があります。

• <one-of>要素には、許容される代替手段の一覧が表示され、ルールをアクティブ化するために必要な代替手段は 1 つだけです。

• <ruleref> 要素は、サブルーチンに関して別のルールを参照します。

• <tag>要素は、実行するアクションまたは変数に割り当てる値を指定します。 タグ形式言語で記述されたスクリプトが含まれる場合があります。

ユーザーがルールの対象となる単語または語句を発声すると、その発話に対して定義されたアクション、値の割り当て、またはその他のコードがルールによって実行されます。

ルート ルール

ヘッダーで特に指定されていない限り、 ルート 規則はファイル内の最初の規則です。 これは既定の操作レベルの規則として機能します。 検索する規則を指定せずに文法を参照する場合、このルート規則が最初に参照されます。

ルールのスコープ

文法ファイルの本文内の各ルールを スコープとして割り当てます。 スコープは、外部ファイル (パブリック) から独立して規則を参照できるか、同じ文法 (プライベート) 内の別の規則によってのみ参照できるかを示します。 すべてのルールは、パブリックとして定義しない限り、既定ではプライベートです。

ルールがパブリックの場合は、その ID 属性を他のドキュメントからの参照のアンカーとして使用できます。 たとえば、次のような構文を考えてみましょう:

<grammar src="../grammars/universals.grxml#YesNo"/>

この文法要素を呼び出すと、ファイルのルート規則かどうかに関係なく、 universals.grxml ファイル内のパブリック "YesNo" 規則を直接参照します。

意味を抽出して結果を返す

SWI_meaning キーには、認識された語句のセマンティックな意味が含まれます。 ルート ルールに対してのみ設定できます。 このキーは既定で swirec_extra_nbest_keys リストに含まれているため、文法でこのキーが設定されている場合は XML 結果に表示されます。

SWI_meaning は冗長な答えをフィルターするため、n-best リストのエントリが確実に区別されます。 冗長性を排除すると、信頼度スコアと n-best リストの有用性が向上します。

認識された語句が文法内の別の語句と類似している場合、制約付き音声認識エンジンがどの語句が正しいかわからないため、信頼スコアが低くなる場合がよくあります。 SWI_meaningを適切に使用すると、制約付き音声認識エンジンは冗長な解釈を n-best リストの同じスロットにグループ化します。 次の例では、認識された語句が 「direct my calls home 」であっても 「please direct my calls home 」であっても、SWI_meaning は 「direct calls home 」に設定されます。

SWI_meaning がなければ、文法は次のような n-best リストを生成する場合があります:

SWI_meaningを使用すると、制約付き音声認識エンジンは、読み上げられた正確な語句ではなく解釈の意味によって n 個の最適なリストを配置し、n-best リストのエントリが本当に区別されるようにします。

制約付き音声認識エンジンは、文法内のスクリプトで明示的に設定しない場合でも、 SWI_meaning 自動的に設定されます。

ルートで SWI_meaning を明示的に定義しない場合は、ルートで定義されているすべてのキーとその値を連結して構築されます。 ただし、この構築は、SWI_など、SWI_literal以降のキーには適用されません。 キーと値のペアは、最初にアルファベット順に並べ替えられます。 その理由は、アプリケーションに関する限り、返されるキーのセットは文の意味であるためです。

キーがない場合、結果は SISR セマンティクスと SWI セマンティクスのどちらを使用しているかによって異なります。 SISR では、キーがなければ SWI_meaning キーはセットされません。 これに対し、SWI セマンティクスでは、SWI_meaning は次のように設定されます。

{SWI_literal:<literal>}

SWI_meaning がオブジェクトの場合は、文字列形式に変換されます。

アプリケーションは SWI_meaningにアクセスできますが、特に定義されている他のキーと値のペアを使用することがよくあります。

Azure Storage を使用して音声文法をホストする

Copilot Studio では、音声認識の文法による制約付き音声認識がサポートされています。 ただし、これらの文法の直接作成、テスト、ホストはサポートされていません。 文法をホストする場合は、Microsoft Azure Storage を使用して、音声対応エージェントと文法ストレージの間に信頼されたセキュリティで保護された接続を作成します。

Azure ストレージ アカウントを設定する

Azure ストレージ アカウントを作成します。 新しいストレージ アカウントのサブスクリプション、リソース グループ、リージョン、リソース名が組織のポリシーに従っていることを確認します。 次の設定を使用します。

• プライマリ サービスの場合は、Azure Blob Storage または Azure Data Lake Storage Gen 2 を選択します。

• [パフォーマンス] に [Premium ] を選択します。

詳細については、 Azure ストレージ アカウントの作成に関するページを参照してください。

ストレージ コンテナーを設定する

アップロードした文法ファイルのストレージ コンテナーとして 静的 Web サイト を使用します。 ストレージ コンテナーは、Web サイトのプライマリ エンドポイントとセカンダリ エンドポイントを提供します。

文法ファイルをアップロードしたら、ディレクトリからファイルを選択して、ファイルのプロパティと詳細を表示します。 ファイルの URL を次の形式で保存します。

https://{resourceName}.blob.core.windows.net/\$web/{grammarFileName}

詳細については、「 コンテナーの作成」を参照してください。

制約付き音声認識エンジンを認証する

制約付き音声認識を音声対応エージェント内で機能させるには、システムは、前の手順で作成したストレージ アカウントを信頼できる場所として使用して認証する必要があります。 この認証には、 ストレージ BLOB データ閲覧者 ロールが必要です。

Azure ポータルで Azure ロールを割り当てる方法について学ぶには、こちらをご覧ください。

Azure portal にサインインし、Azure Cloud Shell セッションを開き、次のコマンドを実行して、テナントに制約付き音声認識エンジン サービス プリンシパルを作成します。

az ad sp create --id e0e7bef0-777c-40ef-86aa-79d83ba643c7

Copilot Studio で制約付き音声を使用する

外部エンティティを作成する

Copilot Studio 内の エンティティ は、特定の種類の現実世界の主題を表す情報の単位と考えることができます。 たとえば、電話番号、郵便番号、市区町間、または人の名前などを表します。 エンティティを使用することで、エージェントはユーザー入力から関連情報を認識し、後で使用できるように保存できます。 このシナリオでは、制約付き音声認識文法によって認識が実行されます。

外部エンティティを使用して、音声文法を参照します。 外部エンティティを作成するには、音声対応エージェントを開き 、設定>Entities>エンティティの追加>外部エンティティの登録に移動します。

次の情報を入力してください。

• 名前: https://{resourceName}.blob.core.windows.net/\$web/{grammarFileName}?constrainedrequired=true 形式の文法 URL

  Note

  URL では大文字と小文字が区別されます。

既定の認識モードは Speech Only です。 別の文法構成については、次の表を参照してください。

たとえば、2 つの同じ文法セットがあり、1 つは英語用、1 つはスペイン語用で、それぞれが異なるサブディレクトリに格納されているとします。 多言語エージェントは、英語と同様にスペイン語で会話するときに、英語の文法を使用できる必要があります。 この場合、文法 URL は次のようになります。 {Env.BaseURL}/common/**{System.User.Language}**/{grammarFileName}?

System.User.Languageがen_USまたはes_USされ、エージェントで言語が切り替わると変更されます。

• 説明: キャンバス上のセレクターがエンティティ名として参照する文法の簡単な説明。 たとえば、"クレジット カード番号" などです。

• データ型: レコードのデータ型を選択し、応答で予想されるタグのスキーマを定義します。 たとえば、文法が SWI_meaning と市区町村を返す場合、 レコードのスキーマは次のようになります。

  kind: Record
  properties:
    city: String
    SWI_meaning: String
  

[保存] を選択すると、エンティティが一覧に表示されます。 ボット作成キャンバスで質問ノードにアクセスします。 従来のエンティティの場合と同様に、プロンプトに対するユーザーの応答の結果としてエージェントに認識させたい外部エンティティ (文法に付属) を選択します。

ランタイムの動作

音声対応エージェントが実行され、外部文法を使用するロジックが検出されると、音声対応エージェントは Azure ストレージ アカウントに到達し、解釈のために文法を取得します。 次にエージェントは、文法内で適用された制約とユーザーの発言を照合します。 一致に成功すると、外部エンティティで定義されたスキーマに従って、Record 変数に応答が返されます。

キャンバス ロジック

ノードの変数に保存された結果は、常に、外部エンティティのスキーマで定義されている レコード 型になります。 作成者は、この Record 変数を使用して、 variableName.SWI_meaning やドット表記による variableName.city など、スキーマで定義されているキーにアクセスできます。

デバッグ

エラー コード

SWI_Literal

制約付き音声認識エンジンで動作する多くの文法では、 SWI_Literal 機能は、解釈された結果ではなく、ユーザーが発したリテラル ステートメントを返します。 デバッグに役立つ Copilot Studio の出力の 1 つとしてこの値をログに記録します。

既知の制限

このソリューションには、以下の制限があります:

• 個々の文法ファイルの最大サイズは、現在 100 MB に制限されています。
• 変数の受け渡しはサポートされていません。
• ストレージ アカウントは、エージェントと同じテナント内にある必要があります。
• URL のサイズは 500 文字を超えることはできません。
• Azure ストレージ アカウントのエンドポイントのみが許可されます。
• サブプログラムは、同じストレージ アカウントでのみホストできます (認証に同じ FPA を使用)。
• セキュリティで保護された XML パーサー (つまり、DTD は許可されておらず、SRGS/SISR スキーマに対して検証する必要があります)。
• NLSML 出力形式のみが内部でサポートされます。
• 従来の swirec_simple_result_key パラメーターには効果がなく、すべてのタグが返されます。

法務

Microsoft Dynamics サービスは、制約付き音声認識システムを処理します。 このエクスペリエンスを使用することにより、Dynamics の利用規約に同意したものとみなされます。