Edited at

Amazon Alexaスキル作成時に気をつけること その1


はじめに


目的

本記事は、Alexa Skill作成の練習中に躓いたAlexaスキル作成時に気をつけることを整理・記録するものです。気をつけることの範疇には、技術的観点以外のことも含めます(意外とこれが一番重要かも・・・)。同じところで躓く人が少しでも減ることを願っています。

#しょぼいつまづきポイントもありますが、ご愛嬌ということで・・・

※2018/02/13現在、審査通りました! 改良中のため、もう少しだけ更新続くかも。

ご興味のある方はAlexaスキルの"モンスターの弱点サーチ"をご参照ください。


対象読者


  • これから初めてAlexa Skillを学習される方


    • ⇒参考資料のセクションに有用なリンクを整理したいと思いますので、ご参考に。



  • 一般公開用のSkillを開発しようとされている方


    • 全ての項目ではないですが、自宅で使うだけであれば注意すべき点は減ると思います。



バリバリ開発されている方には当たり前、既知な内容かと思われます。


参考資料

作成手順や基本は、とても良い解説がありますので、本当はよく読めば躓かないことも多いかもしれません。



  • Alexaスキル開発トレーニング


    • Amazon Developer公式のトレーニング資料です。


      • 初めての方はこちらを読むのをオススメします。



    • 基本の基本である開発のためのAmazon Developer、AWSのアカウントの作成方法から、簡単なスキル、徐々に複雑な対話モデルまで、順を追って説明があり、分かりやすいです。


      • クラスメソッド様が作られているそうなので、当然といえば当然・・・!さすがです。






  • Alexa Skills Kitドキュメント


    • Alexa Skillを開発するためのKitのドキュメントです。




  • Alexaスキルの音声インターフェースとユーザーエクスペリエンスのテスト



    • Alexa Skills Kitドキュメントの一部ですが、テストの際に考慮すべき次項が整理されています。

    • 詰まった後に呼んでみると「あ、そういう意味ね!」となるんですが、逆に詰まるまでは読んでもイメージが湧かないのが難点です。。。




作成Skillの概要

ここに整理するTipsは、Skillの内容にあまり依存しない(一般的に役立つように抽象化したい)と考えていますが、説明ゼロではイメージも湧かないと思いますので極簡単にキーワードレベルで説明します。


  • 機能


    • 架空世界のモンスター名を尋ねると、弱点の属性を答える。



  • 対象ゲーム


    • モン○ター○ンター



  • 会話イメージ


    • Q「 [スキル名]でリオ○ウスの弱点を教えて」

    • Alexa「リオ○ウスはは、龍属性が良くききます。」



というふうに、ゲームコントローラを手放さずにモンスターの弱点を調べることができます。ナガラでできちゃうと嬉しいことって、意外と多い気がしますね。


Alexa Skill作成時の注意点、Tips


著作権問題

技術的なことではないのですが、一番引っかかりやすく、対応に時間がかかる問題です。


問題となるケース


  • 第三者の商標またはブランドがスキルの応答内容や、詳細ページなどに含まれている。


    • 情報自体に秘匿性がなくとも、特定の固有名詞が含まれている場合は、商標またはブランドの所有者からの許諾が無いと審査で却下されます。




    • スキル名や応答内容にに"モン○ター○ンター"が含まれていなくても、応答メッセージにゲーム内の固有名詞である"リオ○ウス"が含まれているとアウトです。



フリーではないゲーム画像や音声などは常識的にも、著作権的にも、もってのほかですが、応答内容が一般的にWebの攻略情報として出回っているものでも却下対象です。Amazonのスタンスとしては、"カスタマーへの透明性は非常に重要"としているそうで、結構厳しめかな、と思います。

#Webが無法地帯なだけ、といえばそうかもしれません。


対処方法

正攻法で商標またはブランドの所有者から許諾をいただくほか無いと考えられます。(※トライ中のため、どの程度の許可をもらえばOKなのか確認中です。)


  1. ブランド所有者へ確認

  2. Amazon(amazon-developer-program@amazon.com)へ確認結果を送付

  3. Skillも併せて申請

ちなみに、却下された場合は以下のような審査結果に対処法として以下のような案内が来ます。


ブランド所有者がコンテンツの使用を許可することを明記した署名入りの書面、またはライセンス契約等を提出する。 書面データやライセンス契約情報などのデータをお送りいただく場合は、amazon-developer-program@amazon.com 宛にメールでお送りください。


#攻略情報程度で"署名入りの書面"や"ライセンス契約"が必要になるとは思えませんが、どうなるか・・・Amazon様次第。

2018/02/13追記 審査通りました!

やったこととしては、カプ○ン様へ「著作権上問題となるような画像、音声、動画などを含まない、ネタバレ要素を含まない」などのポイントと、スキルの概要を説明し、許諾を得ました。その回答(メール)とスキルID&スキル名、問題ない旨の解釈を添えてAmazon様へ送付しました。一応、ブランド所有者がOK出した、ということで通った模様。

更に追記:ご存知のかたも多いかもしれませんが○○(非公式)みたいなスキル名でその旨をスキル説明にも書くと回避される場合があるようです。


スロット認識精度の向上(ユーザの発話の誤認識)


問題となるケース

ユーザの発話をAlexaが拾うために事前定義しておく"キーワードのリスト"をスロットと呼びます。独自のスロット値をカスタムスロットタイプとして、Alexaスキルに登録するのですが、日本語のさまざまある表記によって認識率が変わってしまいます。



    • リオレ○ア 亜種



カタカナ&漢字が混ざっており、これらを正しく認識するのは結構難しいです。

[2018/02/20追記]

モンスター名って、発音するのがそもそも難しくって、なかなか認識されないです。「ツィツィヤ○ク」とか「バゼルギ○ス」とか・・・「リオレ○ア」なんて「料理屋」によくなります。


対処方法


  1. カスタムスロットタイプに登録するスロット値にひらがなも追加して登録しましょう。

  2. スロットの値に対して、シノニム(同義語)を設定しましょう。



    • リオレ○ア 亜種

    • りおれ○ああしゅ



上記のように両方登録してしまったほうが認識率が上がり、安心ですね。

ただし、Alexaスキルのバックグラウンドで動作するAWS Lambdaに渡される値も変わりますので、複数の表記に対応したファンクションを準備する必要があります。

シノニムを登録することにより、シノニムで認識されたことをLambdaファンクション側で認識することができます。

上記のようにシノニムを登録すると、シノニムで認識した場合に受け取れるオブジェクトは、以下のようになります。

{

"name": "MonsterName",
"value": "エネルギー",
"resolutions": {
"resolutionsPerAuthority": [
{
"authority": "amzn1.er-authority.echo-sdk.amzn1.ask.skill.4f17952b-ce01-490d-9c10-760f0a501363.NameOfMonster",
"status": {
"code": "ER_SUCCESS_MATCH"
},
"values": [
{
"value": {
"name": "ねるぎがんて",
"id": "0014"
}
}
]
}
]
},
"confirmationStatus": "NONE"
}

「ねるぎがんて」のシノニムとして「エネルギー」を登録した場合、上記のように認識された結果を取得することができます。これを利用することで、「ねるぎがんて」に対応できるようにLambdaファンクションを実装しておくだけで、似たように認識されるワードや、略称などの対応を、Alexaスキル側の実装として集約することが可能です。


スロット値として想定していないキーワードもAlexaは受け付ける


問題となるケース

スロット値として事前定義していない値(つまり、スキルとしては想定外の値)を受け取った場合も、AlexaスキルからLambdaファンクションに処理が流れます。



    • モンスターの名前を想定したスロット値を準備している場合にも、自転車風船などを受け取ることができてしまいます。




対処方法

Lambda側の書き方によりますが、受け取った値を元にデータ処理を行う際、想定外の値が来た場合に分岐して処理をするようにしておきましょう。要はエラーハンドリングなのですが、Alexaスキルの挙動を知らないと抜けがちかもしれません。

今回のAlexaスキルの場合、モンスター名をキーにして配列から弱点情報を取り出すようにしていますが、存在しないキーの場合はundefinedが返るため、それを元に分岐をしています。

        if (typeof weakpointMessage !== 'undefined') {

var message = "想定内の場合のメッセージ";
this.emit(':tell', message);
} else {
var message = "想定外の場合のメッセージ";  
this.emit(':tell', message);
}

こちらのAlexa Skills Kitドキュメント 4.11.エラーハンドリングもご参考に。


セッションの管理


問題となるケース

はじめにチュートリアルに沿ってスキルを作成すると、セッションを利用(維持)する場合のAlexaスキルの作り(Lambdaファンクションの実装)になっていると思います。それを微修正してセッション不要な簡単なスキルに作り直すと、セッションを開始した場合の処理がなくてユーザとの対話が途中でブツッと切れてしまうような挙動になります。

#単純に凡ミスですが、まずはセッション維持なしの簡単なスキルの作成から行うほうが分かりやすいと思います。


対処方法

Alexa のレスポンスアクション(メッセージを送るためのメソッドの使い方)は大きく2通りあります。聞かれたことに返事をして処理を終了する場合、":tell"を使いましょう。逆に会話を継続する場合は":ask"を使いましょう。


  • :tell :単発のレスポンスを返す(セッションを維持しない

  • :ask :レスポンスを返した上で、セッションを維持する

以下に会話の流れの例を挙げます。どんな挙動にしたいのかによって使い分けましょう。


  • セッションを維持する場合(:ask)


    • Q 「[スキル名]を開いて」

    • Alexa 「[スキル名]の説明~(○○の弱点を教えて、というふうに聞いてください。)」

    • Q 「○○の弱点を教えて」

    • Alexa 「○○の弱点は✕✕です」



  • セッションを維持しない場合(:tell)


    • Q 「 [スキル名]で○○の弱点を教えて」

    • Alexa 「○○の弱点は✕✕です」




スキルのバージョン管理


問題となるケース

Alexaスキルの以下の要素を変更したい場合には、再審査が必要となります。

- スキルの説明や、発話のサンプルなどの情報

- 対話モデル(インテントやスロットなど)

スキル公開後も修正、拡張を行いたい場合、スキルのバージョン管理していないと本番環境しかいじれるものがない・・という状況になってしまいます。しかしながら、Alexaスキル自体(Lambdaを含まない部分)にはバージョン管理機能が見当たりません。



※元画像は参考資料のページからお借りしました。

一方で、実は、Lambdaファンクションの処理については、変え放題です。直接の審査対象ではなく、Skillからの応答部分のみを見て(聞いて)判断されているためです。しかしながら、サービスインしたスキルのバックエンドをホイホイいじるのは怖いですよね。Alexaスキルとして正しい応答ができない状態になっていると「スキルの応答が適切でない」旨のアナウンスが利用者に流れてしまいます。


対処方法


  • Alexaスキルは、開発用にもう一つ準備してしまいましょう。

  • Lambdaファンクションについては、審査の対象ではありませんが、バージョン管理を行いましょう。


    • Serverless Frameworkを使えば、stageとして管理が容易です。




serverless.yml

provider:

name: aws
runtime: nodejs6.10
stage: prod #default stage, overwrite by --stage option

AlexaスキルとLambdaファンクションの関連付けは、開発用AlexaスキルのアプリケーションIDとLambdaファンクションのARNを紐付ければOKです。

2018/02/17追記

新しいコンソールでは、公開中(Liveステータス)のものの下に編集(Edit)できる状態のスキルが表示されています。これで修正できそう!切り替え方式などはこれから調べてみます!

2018/02/23追記

すでに公開中(Liveステータス)のスキルと同名スキルで、開発中(in Developmentステータス)のスキルを編集、申請への公開を行うことができました。承認が通ると、Liveステータスのものが新しい内容に置き換わります。

ちなみに、開発中ステータスのものをどのようにテストするのか最初はわかりませんでしたが、どうやらβテストユーザには、開発中ステータスのものがAlexaからは見えるようです。本番スキルとAlexaスキルIDは共通であるため、やはり、以下に気をつけましょう。


  • Lambdaファンクションは、本番用と開発用で別ける。


    • AlexaスキルIDをは共通であるため、一つのAlexaスキルIDに複数のLambdaファンクションが関連付けられている状態になります。どちらを呼ぶのかは、Alexaスキルの「Endpoint」の設定ですので、公開後のものを修正する場合は、まずはここを開発用のLambdaへ向けることを忘れずに。

    • βテスト用(のAlexaアカウントを関連付している)Echoしか無い状態で、本番用Lambdaを弄ってしまった場合、正常に動作しているか試すのに手間がかかると思います。(βテストを一度終了するしかない・・はず。)




おわりに

現在もスキルは作成中ですので、実装していく中で躓いたところを追記したいと思います。

2018/02/25追記

公開後、ある程度の修正が完了し、落ち着いてきた気がするので、本記事の更新はここまでにしたいと思います。次は、もう少し複雑なスキル(セッション管理を行うようなもの)を作成してみたいですね。

Amazon Alexaスキル作成時に気をつけること その2