Amazon Lexで組み込みスロットタイプAMAZON.Confirmationが全ロケール対応したので日本語で試してみた
はじめに
Amazon LexのAWSドキュメントのDocument historyでは、8月に組み込みスロットタイプAMAZON.Confirmationがすべてのロケールでサポートされるようになったと記載されていました。
AMAZON.Currency and AMAZON.Confirmation built-in slot types now support all locales. For more information, see Built-in slot types.
AMAZON.Confirmationスロットタイプは、Amazon Lex V2で「はい」、「いいえ」、「多分」、「わからない」に対応する入力フレーズを認識し、4つの値（Yes、No、Maybe、Don't know）のいずれかに変換します。
これを使用して、ユーザーからの確認や承認を取得できます。
スロットの値に応じて条件分岐を作成し、それぞれに適した処理フローを設計することが可能です。
今回は、日本語での認識精度と各カテゴリへの分類結果を検証してみます。
検証用インテントの作成
Confirmationという名前のインテントを作成し、AMAZON.Confirmationスロットタイプを使用する設定を行いました。
検証
Yesに分類されたフレーズ
以下のフレーズはYesにスロット解決されました。日本語の肯定表現として適切に認識されています。
- はい
- うん
- わかった
- OK
- 了解
- 承知しました
フォーマルな表現（「承知しました」）からカジュアルな表現（「うん」）、さらには英語の「OK」まで幅広く対応されています。
Noに分類されたフレーズ
以下のフレーズはNoにスロット解決されました。日本語の否定表現として適切に認識されています。
- いいえ
- 違う
- いらないです
- もういい
- ノー
- 否定します
Yesと同様に、フォーマル（「否定します」）からカジュアル（「もういい」）な表現まで対応されています。「いらないです」のような丁寧語での断りや、「違う」のような直接的な否定も適切に認識されており、日本語の多様な否定表現をカバーしています。カタカナ表記の「ノー」も認識されるため、ユーザーの入力パターンに柔軟に対応できそうです。
Maybeに分類されたフレーズ
以下のフレーズはMaybeにスロット解決されました。
- 多分
- たぶん
一方で、以下のような課題が確認されました。
Maybeと判定されるべきフレーズがNoとスロット解決されるケース
- 可能性はある
- そうかもしれない
- かもしれない
Maybeと判定されるべきフレーズがYesとスロット解決されるケース
- もしかしたら
Maybeと判定されるべきフレーズがインテント名FallbackIntentでトリガーされるケース
- おそらく
- ことによると
この結果から、Maybeカテゴリは英語の"maybe"に直接対応する日本語表現（「多分」「たぶん」）のみに厳格に限定されていることが分かります。
日本語では曖昧な表現が非常に多様で豊富であるため、この制限は実際のユーザー対話において期待通りに動作しない可能性が高いと言えます。
Don't knowに分類されたフレーズ
以下のフレーズはDon't knowにスロット解決されました。
- わからない
- 知らない
基本的な「わからない」「知らない」は正しく認識されていますが、こちらも認識範囲が限定的です。
ただし、以下のような課題も確認されました。
Don't knowと判定されるべきフレーズがNoとスロット解決されるケース
- はっきりしない
- 不明
Don't knowと判定されるべきフレーズがインテント名FallbackIntentでトリガーされるケース
- 誰も知らない
Don't knowについても、直接的な表現（「わからない」「知らない」）のみが認識され、より丁寧な表現（「はっきりしない」「不明」）や文脈的な表現（「誰も知らない」）は適切に分類されません。
まとめ
検証の結果、基本的な日本語表現（「はい」「いいえ」「多分」「わからない」など）は適切に認識されることが確認できました。YesとNoのカテゴリについては、フォーマルからカジュアルまで幅広い表現に対応しており、実用性があると言えます。
一方で、MaybeとDon't knowについては認識される表現の幅が限定的で、より複雑な表現や文脈的なニュアンスを含むフレーズについては、期待される分類とは異なる結果になることがありました。これは日本語の豊富な表現パターンに対する対応の限界を示していると考えられます。
このスロットタイプを活用した条件分岐として、以下のような処理フローが考えられます。
- Yes: 処理を実行
- No: 処理をキャンセル、代替案を提示
- Maybe: 追加情報を提供、再確認
- Don't know: 詳細説明、サポートへ案内
YesとNoのみの二択であれば確認処理でよく使われますが、4つのカテゴリを活用するユースケースは限定的かもしれません。ただし、ユーザーの意図をより細かく分類できるため、より柔軟な会話フローの設計が可能になります。実際に導入する際は、認識精度の制限を考慮し、重要な判定については追加の確認フローを設けることをお勧めします。
