スマートスピーカーのスキルは、基本的にスマートスピーカーが受け取った音声をテキスト化する部分、テキストから意図（インテント）とキーワード（スロットとかエンテティとかって言われる）を抜き出すところまで、各スマートスピーカーを提供してくれているベンダーが面倒見てくれます。
そして、そこから解析結果が詰まった JSON を Webhook めがけて投げてくれます。 開発者がゴリゴリコードを書いてカスタマイズできる部分は、この Webhook の先のコードという形が一般的です。
ちなみに、Microsoft の Bot Framework を使った場合は意図やキーワードを抜き出すことはしてくれないです。 その代わり SDK 側に Microsoft の LUIS と呼ばれるテキストから意図やキーワードを抜き出すサービスとの連携機能があるので、自分で好きなように呼び出すことが出来るようになっています。
例えば、その時の会話の状態に応じて LUIS を呼び分けるといったことが出来ます。最初はおおまかに何がしたいかを判別することに特化して学習させた LUIS に解析をお願いして、その先では、それぞれのやりたいことに特化して学習させた LUIS を呼び出すといったことが出来ます。 手間がかかるぶんこったものを実現可能になっている感じですね。
さて、話しを戻します。
Webhook で飛んでくる JSON ですがスマートスピーカーのプラットフォームごとに互換性がありません。ですが、その先でやりたいことはだいたい共通でしょう。
ということで、受け口と必要なデータを抜き出す部分だけ別関数（HTTPのエンドポイントが別になる）に分けておいて、そこから共通ロジックを呼ぶ形で 1 つの Azure Functions で対応可能になります。
このとき node.js でやるなら公式の SDK が使えるのでは…と思います。express に依存している場合は azure-functions-express というパッケージで結構動きます。例えば Clova の場合は以下のような感じ。
C# の場合は、野良 SDK などを駆使することになります。
Clova の場合はこんな感じ。
Google Home の場合はこんな感じ。唯一公式 SDK (ただし、まだベータ）
Alexa の場合は、ブログには書いてませんが Alxa.NET というパッケージがあります。
以下の記事は Lambda を使ってますが、基本的にリクエストのボディを SkillRequest に JSON.NET を使ってパースして、 SkillResponse を作って new OkObjectResult(response);で返してやる感じです。
まとめ
ということで、複数スマートスピーカーに対応したい人は昔から GUI アプリケーション開発で言われていた見た目とロジックの分離と同じようにスマートスピーカーに依存する部分とロジックを分離することで、低コストで対応が可能になるのではと思います！
ちなみに
ここでは Azure Functions と言ってますが、何を使っててもプラットフォーム依存の部分とそうでない部分を分離して書くことで今回のと同じように 1 つのアプリで 3 プラットフォーム対応とか出来ます。AWS Lambda でも Heroku 上にデプロイしたものでも、レンタルサーバー上にデプロイしたアプリでも！
それでは、良い VUI ライフを！