Azure Cognitive Service for Language ＋ Azure Bot Service で超簡単にチャットボット作成③～LINE Botとしての公開

以下記事のつづきです。

① ナレッジベースの作成＆Webチャットの公開 himanago.hatenablog.com

② Microsoft Teamsへの簡易接続 himanago.hatenablog.com

今回は LINE Bot

Azure Cognitive Service for Language ＋ Azure Bot Service で作ったチャットボットを LINE Bot で使えるようにしてみます。

LINE も標準でサポートされているので、とても簡単です。

手順

つなぎ方のドキュメントはこちら。

docs.microsoft.com

基本的にこの通りやっていけばできます。

まずはあらかじめ LINE Developers で Messaging API のチャネルを作っておきます。

アイコンとアカウント名は、Azure Bot Service のボットプロファイルとは連動しないので、LINE 側で設定する必要があります。

また「Messaging API設定」で長期のチャネルアクセストークンを発行しておきましょう。

Official Account Manager に移動して「あいさつメッセージ」「応答メッセージ」をオフに、Webhook をオンにしておきます。

準備ができたらつないでいきます。

Azure Bot Services 側で、チャンネルに LINE を追加していきます。

LINE の Messaging API チャネル側の情報として「チャネルシークレット」「チャネルアクセストークン」を入力します。

「Webhook の URL」 をクリップボードにコピーして（LINE 側に入力します）、保存をクリックします。

保存が完了したら「閉じる」を押します。

LINE Developers のコンソール（または Official Account Manager）でコピーした Webhook URL を設定します（コピーした文字列には「https://」がついていないので注意）。

動作確認

友だち追加して会話するとこんなかんじです。

あいさつメッセージをオフにしていても、初回メッセージが友だち追加時にちゃんとくるのがいいですね。

つづく

あとひとつ、このあとは Alexa を試してみたいと思います。

Azure Cognitive Service for Language ＋ Azure Bot Service で超簡単にチャットボット作成②～Microsoft Teamsへの簡易接続

前回のつづきです。

himanago.hatenablog.com

今回は Microsoft Teams に接続

Azure Cognitive Service for Language ＋ Azure Bot Service で作ったチャットボットを Microsoft Teams で使えるようにしてみます。

Teams は標準で接続がサポートされており、（簡易な接続方法であれば）簡単な接続情報の入力だけでつなげることができます。

今回はさらっと、簡易な接続方法でやってみたいと思います。

簡易公開の手順

Azure ポータルでの作業

Azure Bot Service のリソースを Azure ポータルを開き、チャンネルの「Microsoft Teams」をクリックします。

サービス条件に同意します。

「Microsoft Teams Commercial」が選択されていることを確認して「保存」をクリックします。

保存が完了したら「閉じる」を押します。

チャンネル設定の画面に戻るので、ここで「Open in Teams」を押すと、そのまま自分が使っている Teams の「チャット」で会話をはじめることができます。

Teams で会話してみる

アプリインストール済みであれば自分の Teams が開き、「チャット」で会話ができるようになります。

チームのチャネルで使用するためにはアプリ化する必要がありますが、チャットで会話するだけであればこのリンクだけあればよいので、とても手軽です。

いろいろ話しかけてみるとこんな感じです。

最初のウェルカムメッセージは、こちらがメッセージを送ってから初めて送られてくる点に注意です。

きちんと使うにはアプリ化が推奨だけど…

この「チャット」でだけ使う方法ではタブやメッセージング拡張機能などの Microsoft Teams で特に便利な機能が使用できません。

そのため、アプリ化をして Teams に導入することが必要とされています。

アプリ化して Teams に接続する方法の詳細は以下のドキュメントとそこから飛べるページを参照。

docs.microsoft.com

上記ドキュメントにも

テスト以外の目的のために、GUID によってボットを追加することはお勧めできません。 そのようにすると、ボットの機能が厳しく制限されます。 運用環境のボットは、アプリの一部として Teams に追加する必要があります。

とあります。

なのでこの方法（ID/GUID で直接ボットと話す方式）はテスト目的にしてね、というのがドキュメントのスタンスなのですが、テナントによってはアプリの追加が管理者によって封じられているケースなどがあると思います。

そういう場合はこれがボットを利用する唯一の手段になってしまいます。機能が制限されているとはいえ、使えるだけでもありがたいのです。

チャット内なので個人利用に限られますが、今回作ったような質問回答系のチャットボットであればチームのチャネルで使うよりチャットで使うほうがなじむので、この方法でも役に立つ気がします。

制限されているテナントで、試してみる価値はありそうですね。

つづく

次は LINE につないでみようと思います。

Azure Cognitive Service for Language ＋ Azure Bot Service で超簡単にチャットボット作成①～ナレッジベースの作成＆Webチャットの公開

はじめに

QnA Maker や LUIS などが Language Studio に統合されるということで、質問対応のチャットボットを Azure でささっと作る場合は今後 Language Studio の Custom question answering を使っていくことになりそうです。

そこで触ってみたのですが、Azure Bot Service を使うとコードを一切書くことなく（ノーコード・ローコード的にロジックやステップ・フローを組んだりすることもなく）いろんなプラットフォームにチャットボットとして公開することができ、手順含めとても簡単だったので、まとめておこうと思います。

Language Studio でのナレッジベース作成

Language Studio へのサインイン

まずは Language Studio に有効な Azure サブスクリプションで使えるアカウントでサインインします。

https://language.cognitive.azure.com/

Language リソースの作成

はじめに Language のリソースを選べと言われるので、（ない場合は）はじめにそれを作ります。

最初にサインインしたときにカルーセルで使い方が表示されますが、それの最後のところからこのダイアログを表示させることができたかと思います（閉じてしまった場合は、再度サインインするとダイアログが出てきます）。

選択できるリソースがない場合は「Create a new language resource」から新規に作っていきます。クリックすると作成ダイアログが出てくるので、以下の内容を入力します。

• リソースグループ（既存のもの。新しく作りたい場合はあらかじめ Azure ポータル等で作っておく）を選択
• リソース名を入力
• リージョンを選択
• 価格を選択
• Managed Identity を ON

「Done」をクリックすると、Language のリソースが指定したリソースグループに作成されます。

Language リソースが選択できるようになるので、選択して「Done」をクリックすると、Language Studio の画面の上部で「Create new」が使えるようになります。

Azure Cognitive Search のリソースの作成

いま作りたいのはナレッジベースなので、Language Studio の画面の上部で「Create new」から「Custom question answering」を選びます。

すると画面遷移して、今度は Azure Cognitive Search のリソースを作れと言われます。必要なリソースを次々に指示してくれるので、迷わなくていいですね。

…もちろんいっぺんにつくれればもっと早い＆わかりやすいですが、Language Studio はいろんな言語系の機能をまとめて管理できるものであって、機能ごとに必要リソースが異なるのでこのようになっているのだと思います。

「Connect to Azure search」をクリックしましょう。

別タブで Azure ポータルの Language リソースの「機能」メニューが開くので、チェックボックスを 2 つ ON にしつつ、「新規作成」をクリックします。

内容を入力して「確認および作成」をクリックします。検証 OK なら、続いて「作成」をクリックして作成できます。

さきほどの画面に戻ってくるので、作成した Cognitive Search を選択し、「適用」をクリックします。選択肢が反映されていないようならリロードすれば大丈夫です。

ナレッジベースの作成

Language Studio のタブに戻ってリロードすると、以下のような画面が表示されます。

表示されるステップに従って入力していきましょう。

名前、説明、回答が見つからなかったときの返答内容を記入します。名前に日本語は使えないので注意です。

内容を確認して問題なければ、「Create project」をクリックします。

ここからいよいよナレッジベースの作成です。

最初は「Manage sources」からナレッジベースのもととなるデータを追加していきます。

ナレッジベースは URL やファイルから作ることができますが、今回は 「Azure サポート プランに関する FAQ（https://azure.microsoft.com/ja-jp/support/faq/）」のページの URL を指定してみます。

指定した URL からナレッジベースになりうる情報を読み取って、質問と回答のペアを作ってくれるというわけです。FAQ ページなんかはそのまま使えるので、便利ですね。

「Add source」から「URLs」をクリックすると URL の追加画面が出てきます。

「Add url」を押して、ページの名前と URL を入力し「Add all」をクリックします。

追加が完了するとこのようになります。

中身を見てみるとこんな感じで、ページの内容を読み取って、質問と回答のペアを作ってくれています。

また、「Add source」からさらにナレッジベースの情報を追加することもできますが、今回は「Chitchat（おしゃべり）」を追加してみようと思います。

これはナレッジベースをチャットボット化した際、雑談のような会話をすることができるものです。

おしゃべりといっても、文脈を読んで気の利いたことを言ってくれるようなものではなく、こちらからの問いかけに1回反応してくれるだけのもので、ナレッジベース的には雑談的な質問とそれに対する回答が追加されるだけです。

ナレッジベースを作ったあとに中身を見てみると、このようになっています。

質問のバリエーションをかなり頑張っている印象ですが、答えのほうはすごくシンプルにひとまとめに答えている感じです。

回答の雰囲気はいくつか選べますが、ナレッジベース全体の回答の文章と雰囲気を合わせればよいです。今回は「Friendly」なおしゃべりを追加してみます。

なお、おしゃべりを使う場合は Language の価格レベルが Free だとサイズオーバーになってしまうので、Standard にする必要があります。

URL から生成された質問と回答、おしゃべりの内容を確認して、必要に応じて修正していきます。

「Test」では実際に質問を投げてみて、どんな回答が返ってくるか確認することもできます。

ここで想定通りの回答が返ってこなければ、別の回答を選んだり（Test の質問の吹き出しをクリックすると選択できます。新規の回答を追加することも可能）、質問のフレーズを追記して軌道修正したりしてあげます。

修正したら、「Save changes」で更新します。

実際に使い始めてからも、このあたりをどんどんチューニングして育ててあげることになります。

ある程度確認してうまく回答してくれるようになったら、メニューの「Deploy knowledge base」からデプロイします。

Azure Bot Service リソースの作成

デプロイできたらこの画面になるのですが、「Create a bot」ボタンからすぐにチャットボット（Azure Bot Service）を作ることができます。

別タブで Azure ポータルの画面が開くので、必要事項を入力していきます。

言語リソースキーは変更しないようにしてください。入力できたら「確認および作成」を押します。

ここで注意しなければいけないのが、App Service プランです。デフォルトで S1 の価格レベルなので、無料で動かしたい場合は作成後に直す必要があります。

なお、この操作では Azure AD のアプリの登録が裏で行われるはずで、もしサインインしているユーザーが AAD に関する権限を持っていないとエラーで止まります。その場合は AAD の設定で「アプリケーション管理者」ロールを割り当てるなどすれば OK です。

ボットプロファイルの設定

できあがった Bot Service のリソースを開いて、ボットプロファイルの設定からアイコン画像と名前を設定します。

Web チャットとして公開

つづいてチャンネル設定です。標準でさまざまなチャンネルが用意されていますが、まず今回は Web チャットで公開してみます。

Web チャットはデフォルトで有効化されています。「Web Chat」をクリックすると、シークレットキーと埋め込みコードが得られます。

埋め込みコード内にシークレットキーを入れて、任意の Web ページに埋め込んでみましょう。

すると、このようにちゃんと動いてくれます！

つづく

まったくコードも会話の設定もせず、チャットボットが作れてしまいました。これは便利です。

さて、次はせっかくなのでいろんなチャンネルのやり方も試してみようと思います。

個人的に Teams / LINE / Alexa あたりが気になるので、順番にやっていこうと思います！

つづき↓

himanago.hatenablog.com

LINE Bot のバックエンドにできる Azure Logic Apps のフローを GitHub のボタンから 1 クリックでデプロイできるようにしてみた

はじめに

Azure Logic Apps はコーディングなしに Azure 内外のサービスと連携できる便利なノーコード・ローコードなサービスですが、Azure 内の情報を参照したり通知を受け取ったりするのに便利なので、自分はよく Logic Apps でちょっとした LINE Bot を作って使ってます。

サービスとの接続が既存のコネクタを使えばすぐなのが便利なんですが、肝心の LINE との接続部分は HTTP のアクションを使って毎回自力で作る必要があって面倒でした。

そこで、ARM template を使ってそこを自動デプロイできるようにしてみたのが今回の話です。

使い方

GitHub に公開していますが、「Deploy to Azure」ボタンを押すとデプロイができる、たまに見かけるやつです。

github.com

ボタンを押すと、LINE Bot 用バックエンドを作成するための Azure Logic App（事前にLINE Messaging API との接続部分のフローが構築済みのもの）をデプロイします。

「Deploy to Azure」ボタンを押して Azure にサインイン後、

• サブスクリプション
• リソースグループ
• リージョン
• Logic App 名
• LINE Messaging API のチャネル ID
• LINE Messaging API のチャネルシークレット

を入力すると選んだサブスクリプション、リソースグループにデプロイされます。

デプロイされたら、フローを編集して Bot に好きなことをさせてあげてください。

テンプレートは、とりあえず便利ツール的な用途で一番使う

• テキストのオウム返し（リプライ）
• 友だち全員にメッセージ（ブロードキャスト）

を用意していますが、特にリプライについては他のメッセージ形式（画像や動画、スタンプなど）に対応したものとかを今後増やしたいなと思ってます。

ハンズオンとかにも使えるかなーと思いましたが、かなりのショートカットになってしまうので学習効果としては微妙…？？という感じです。

作成されるフローの中身

リプライ

テキストのオウム返し

ユーザーから送られたテキスト内容をそのまま返信するシンプルなオウム返しです（スタンプ・画像等の他のメッセージ形式に対する応答は非対応）。

作成されるフローの中身は Webhook エンドポイントとして使えるよう、Webhook の JSON を POST で受ける「HTTP 要求の受信時」です。

JSON スキーマは、今回はテキストメッセージに対応できる最低限しかいれていません。

続いてチャネル ID、チャネルシークレットをもとにチャネルアクセストークンを取得する処理です。取得したら JSON 解析して後続フローで使えるようにしてます。このあたりは定型処理なので、テンプレート化して置きたい部分の筆頭です。

そのあとはオウム返し。来たテキストをそのまま送り返す処理です。これもよく作ると思います。

最後は応答を 200 で返しています。

ただここはリクエストを受け付けたときに分岐してすぐ 200 を返すようにするのが正しいと思うので、近日中に修正すると思います。

プッシュその他

ブロードキャスト

友だち追加されているユーザー全体へのメッセージ送信を行います。自分専用のお知らせ Bot とかを作るときによく使います。

中身は、「HTTP 要求の受信時」（空の POST リクエスト）から開始して、チャネルアクセストークンを取得。

取得したトークンを使ってブロードキャストメッセージを送信、という流れ。

好きなトリガーに変更したり、送信するメッセージを自由に編集したりして使ってください。Azure のアラートとかにつなげても便利ですね。

おまけ：テンプレートの作り方

今回作ったテンプレート、作成はとっても簡単で、作成済み Logic App の「テンプレートのエクスポート」メニューから ARM Template の JSON をダウンロードできます。

ここから zip がダウンロードでき、その中の template.json がそれです。

今回の チャネルID、チャネルシークレットのような作成時のパラメーターを作りたい場合は

• エクスポート前に Logic App のデザイナー側でパラメーターを定義する
• エクスポートされた JSON の先頭部分にも追加したパラメーターを追記する

という作業が必要になります。

ボタンの作り方は README.md の中身 をみてほしいです。

おわりに

Logic App のテンプレートがワンクリックでデプロイできるのは知っていたのですが、実際使ってみるとめちゃくちゃ強力ですね。

一度組んだフローのパターンを使いまわしたいことはわりとあるので、テンプレート化して置いておくと便利だと思います。

GitHub に公開するとみんなが使えるので、便利なフローのパターンがあれば公開するという流れが増えると嬉しいなと思います！

Java 系 Web アプリの移行先としての Azure Static Web Apps + Micronaut for Azure Functions その 1

はじめに

Java 系 の Web アプリケーションを Azure で動かしたいと考えたとき、Web Apps や Azure Spring Cloud を使ってそのまま動かすのもありですが、最近 GA した Azure Static Web Apps を使ってよりサーバーレスにもっていけたりしないかな？と考えてみています。

Static Web Apps は Angular / React / Vue などで作ったシングルページアプリケーションのデプロイに最適なサービスで、静的サイトのホスティング ＋ Azure Functions によるバックエンド API のセットで構成されています。

しかしこのバックエンド API、通常は Static Web Apps 専用の Functions が裏に用意されるのですが、現状 JS / C# / Python しかサポートされていません。

docs.microsoft.com

しかし、GA された Static Web Apps には、有料のスタンダードプランで使うことのできる「Bring your own functions」機能があり、これなら別途用意した Azure Functions をバックエンド API としてつなぐことができるため、Java の Azure Functions を使うことができます。

docs.microsoft.com

これを使って別途 Functions で作成した Java ベースなバックエンドを Static Web App につないでしまおうという寸法ですが、既存の Java のバックエンドのコードをどれだけ Functions に流用できるかが勝負です。

この流用をしやすくするために、Micronaut というマイクロサービスフレームワークが適しているのではないか？と考えています。

ちょうど業務のほうでも、以前から Azure 上で Grails ¹ の Web アプリケーションを運用していて、もろもろのコストを考えてもう少しサーバーレスなかたちに移行したいと考えていたので、それを想定しつつ Java 系 Web アプリの移行先としての Azure Static Web Apps + Micronaut for Azure Functions を考えてみたいと思います。

なお、フロントエンドは Vue.js を使っていきます（これしかまともに書けない…）。

Micronaut とは

JVM ベースのマイクロサービス開発向けフレームワークです。

前にも少し紹介させていただきましたが、Azure Functions を公式にサポートしていて、Micronaut フレームワークを使って Function App の開発ができます。

himanago.hatenablog.com

Micronaut の利点としては、

• Java/Kotlin/Groovy といった JVM 言語のメジャーどころが選べる
• DI サポート
• （DI を使っても）起動が高速

というのが挙げられます。

今回は Grails からの移行ということで、同じ Groovy 言語が使える、DI があるので移行元で使っていたサービスクラスをそのまま流用できるなどの利点が見込めそうです（これがこの構成をとるいちばんの理由）。

ローカルでの環境構築・開発

ということで、ローカルに環境を作って動かすところまでやってみます。

今回は Mac 想定で進めるので、Windows だと多少コマンドなど異なるかもしれません。そのあたりはご注意ください。

今回の検証環境：

• OS: macOS Catalina 10.15.7
• JDK: 8.0.292-zulu
• Micronaut: 2.5.7

開発環境構築

まずは以下をいれておきます。

VS Code と拡張機能

エディターは VS Code を使います。

以下の拡張機能を入れておきます。

• Azure Static Web Apps

SDKMAN!

Java や Groovy、Micronaut などをインストール・アップデートできる SDK マネージャーです。

Home - SDKMAN! the Software Development Kit Manager

未インストールであれば

curl -s "https://get.sdkman.io" | bash

でインストールし、インストール済みであれば以下で更新しておきます。

sdk update

JDK

Java 8 を使う必要があるので、JDK 8 を入れておきます。

sdk install java 8.0.292-zulu
sdk default  java 8.0.292-zulu

java -version して入れた JDK が出てくるようになっていれば OK です。

SDKMAN ではなくインストーラー経由で別バージョンの JDK を入れている場合はなおすのがちょっと面倒かもしれませんので、JDK は SDKMAN で管理するように切り替えておくとよいでしょう。

Micronaut

続いて Micronaut の本体です。

sdk install micronaut

vue-cli

Vue.js 開発用。Vue を使わない場合は当然不要です。

npm install -g @vue/cli

Static Web Apps CLI

ローカルで Static Web Apps を動かしたりできる CLI ツールです。

npm install -g @azure/static-web-apps-cli

とりあえず、使うツールは以上です。

フロントエンド（Vue.js）プロジェクトの作成

適当なフォルダに、Vue.js のアプリをつくります。ターミナルから

vue create static-web-app-micronaut-sample

を実行します。

Manually select features で、今回はこんなかんじにしておきます（このあたりはなんでもよいはず）。

? Please pick a preset: Manually select features
? Check the features needed for your project: Choose Vue version, Babel, Router
? Choose a version of Vue.js that you want to start the project with 2.x
? Use history mode for router? (Requires proper server setup for index fallback in production) Yes
? Where do you prefer placing config for Babel, ESLint, etc.? In dedicated config files

できあがったら、 cd して code を開きます。

cd static-web-app-micronaut-sample/
code .

ここから先は VS Code で作業です。

バックエンド（Micronaut）プロジェクトの作成

フロントエンドの Vue のプロジェクトを VS Code で開いたところですが、ここでバックエンドのプロジェクトを作成します。

フロントエンドとバックエンドは同一リポジトリにあげる monorepo で運用すると楽なので、Vue のプロジェクトのフォルダ内に Micronaut のプロジェクトを作っていきます。

VS Code のターミナルから、以下のコマンドを実行します。

mn create-function-app --build=gradle --jdk=8 --lang=groovy --test=spock --features=azure-function com.example.swa.api

パッケージ名とかは適当ですが、最後の api という部分が生成されるフォルダ名になるので、バックエンド・API あることがわかりやすい名前にしておくとよいでしょう。

ほぼ Java の簡易版なコード & Grails からの移行を見越している、ということでここでは言語を Groovy にしていますが、もちろん Java でも Kotlin でも大丈夫です。

ちなみに、上記のコマンドはこちらのサイトで生成可能です。

micronaut.io

使いたい機能を選択すると、オプションつきのコマンド文字列が得られます。ひながたを ZIP で落とすことも可能。

では、少し実装をいじっていきます。

GreetingService.groovy

DI を試したいので、簡単なサービスクラスを作っておきます。

package com.example.swa.services

import javax.inject.Singleton

@Singleton
class GreetingService {
    String greet(String name) {
        "Hello, ${name}!"
    }
}

Function.groovy

ひながたにある Function.groovy をそのまま使って、DI によるサービスクラスの利用をやってみます。

package com.example.swa

import com.microsoft.azure.functions.HttpStatus
import com.microsoft.azure.functions.ExecutionContext
import com.microsoft.azure.functions.HttpRequestMessage
import com.microsoft.azure.functions.HttpMethod
import com.microsoft.azure.functions.HttpResponseMessage
import com.microsoft.azure.functions.annotation.AuthorizationLevel
import com.microsoft.azure.functions.annotation.FunctionName
import com.microsoft.azure.functions.annotation.HttpTrigger
import com.example.swa.services.GreetingService
import io.micronaut.azure.function.AzureFunction
import java.util.Optional
import javax.inject.Inject

public class Function extends AzureFunction {
    @Inject
    GreetingService service

    @FunctionName("HttpTrigger")
    public HttpResponseMessage hello(
            @HttpTrigger(
                    name = "req",
                    methods = [HttpMethod.GET],
                    authLevel = AuthorizationLevel.ANONYMOUS)
                    HttpRequestMessage<Optional<String>> request,
            ExecutionContext context) {

            String message = service.greet("sample")

            request.createResponseBuilder(HttpStatus.OK).body(message).build()
    }
}

クラスの先頭で GreetingService を DI しているだけのシンプルな処理で、これを HttpTrigger という名前の関数にしています。

HelloWorld.vue

Vue.js で最初から作られている src/components/HelloWorld.vue に以下のような処理を追記します。

<template>
  <div class="hello">
    <h1>{{ msg }}</h1>
    <p>from api: {{ apiMessage }}</p>
  <!-- 中略 -->
</template>

<script>
import axios from 'axios'

export default {
  name: 'HelloWorld',
  props: {
    msg: String
  },
  data: () => {
    return {
      apiMessage: ''
    }
  },
  created: function() {
    axios.get('/api/HttpTrigger')
      .then(response => {
        console.log(response.data);
        this.apiMessage = response.data;
      }).catch(err => {
        console.log(err.response);
        this.apiMessage = err.response.statusText;
      });
  }
}
</script>
<!-- 以下略 -->

axios を使って /api/HttpTrigger を叩いて、返ってきた内容を画面に表示させています。

npm install axios しておきましょう。

Static Web Apps のいいところのひとつが、こうやってフロントエンドと同一のルートからのパスで API が叩けるところですね。

ローカルでの実行

ここまできたら実行してみましょう。

コマンドから、まずはフロントエンドとバックエンドを VS Code でそれぞれ別のターミナルから立ち上げます。

フロントエンド（Vue.js）

npm run serve

バックエンド（Micronaut）

ターミナルをもうひとつ開き、以下のコマンドを実行します。

cd api
./gradlew clean azureFunctionsRun

Static Web App としての実行

SWA CLI の機能で、同一のルートにフロントエンドもバックエンドも配置されている状況を再現できます。

さらにターミナルを立ち上げて、以下のコマンドを実行します。

swa start http://localhost:8080/ --api http://localhost:7071

するとこのように、Static Web Apps 同様、同一の URL にフロントエンドもバックエンドもあるような状態をローカルでエミュレートしてくれます。

表示された URL にアクセスすると、このように表示されます。

ちゃんと Micronaut の API も呼んでくれているのがわかりますね。

まとめ

Micronaut 自体がおもしろいフレームワークですが、Azure Static Web Apps との組み合わせもなかなか強力そうな予感がしています！

今回はとりあえずローカル実行するところまで書いてみましたが、長くなりそうなので続きは別記事にしていきたいと思います。

このあとは、

• Azure AD の適用
• Azure へのデプロイ
• CI/CD まわり

あたりを検証していこうかなと思っています。

---

1. Grails は JVM 言語の Groovy ベースの Web アプリケーションフレームワークで、いってしまえば Java 系です。↩

LPF REV UP 2020「あなたならどう使う？最新Azureレシピ for LINE Platform」フォローアップ（後半）

はじめに

年が明けて ２０２１年となりはや1ヶ月。。

年を跨ぎつつまたもや間が空いてしまいましたが、REV UP 2020 でのセッション内容の振り返り後半を書いていきます。
※前半はこちら

Azure × Messaging API（サブ編）

前回は「メイン編」と称して LINE Bot のバックエンドとして使えるサービスを紹介しましたが、「サブ編」ではそれと組み合わせると便利な Azure サービスを紹介します。組み合わせて使うものということで、具体的なレシピも多めに紹介していきます。

Azure Cosmos DB

まずは Azure における NoSQL データベース、Cosmos DB です。

無料枠ができ俄然使いやすくなった Cosmos DB は、小規模サービスとして開発することも多い LINE Bot でも特におすすめできるようになりました（もちろん、登場当初と同じように惑星規模のサービスにも対応できます）。

Cosmos DB の便利な機能は Change Feed（変更フィード）です。Cosmos DB のコレクションへデータ追加・変更があったことを検知し、Azure Functions などにつなげることができます。

docs.microsoft.com

これを利用することで CQRS パターン（コマンド・クエリ責任分離）が実装でき、特に LINE Bot においてはデータの変更をトリガーとして Bot から Push メッセージを送信したり、逆に Bot の操作によって起きたデータの変更を別のアプリ・サービスに通知することができます。

もちろんデータ操作とその結果通知は同一の処理で行っても良いですが、サーバーレス・イベント駆動なアーキテクチャでシステムを組む場合は、データ操作と通知を別々の処理として実装しておくことで、それぞれの処理がシンプルになりつつそれぞれ独立したスケールが可能となります。

docs.microsoft.com

レシピ：リッチメニューの切り替え

Change Feed を使った LINE Bot レシピをひとつ紹介です。

Messaging API ではリッチメニューをユーザーごとに動的に切り替えることのできる API が用意されていますが、Bot を利用している中で、ユーザーの状態に応じてリッチメニューを切り替えたいというケースです。

そのリッチメニューの切り替えを、ユーザーによる Bot の利用によるデータの更新（Bot のメインの処理）と、その結果に応じたリッチメニューの切り替えを分けて実装します。

リッチメニューの切り替えはデータ更新をトリガーとして動く関数（Change Feed によって起動する Cosmos DB トリガーの Azure Functions）とすることで、作りがシンプルになりながら、処理がお互い依存しなくなるため拡張性も高くなります（たとえば、システム管理機能や別の Web アプリなどをユーザーの Bot 利用以外でデータが更新されたときにも、同じリッチメニュー切り替え処理が動いてくれる）。

Azure SignalR Service

つづいては SignalR Service です。

こちらは Web ページなどのクライアントに対してサーバー側の変更を通知しリアルタイム更新を促すためのしくみを提供するサービスで、直接 LINE Bot に対して何かできるわけではありません。

ですが、Azure Functions・Cosmos DB とセットで使うと簡単におもしろいことができます。

SignalR Service は Functions と統合されており、「出力バインディング」によって少ないコードでクライアントへのリアルタイム通知処理が実現できます。

docs.microsoft.com

さらに Cosmos DB の変更フィード（Change Feed）と組み合わせれば、データの変更をクライアントにリアルタイムで通知する処理がとても手軽に実現できます。

これによって、たとえば LINE Bot を入力・Webページを出力とするようなシステムが本当に簡単に構築できます。

レシピ：LINE Botからのメッセージをリアルタイム表示

それがこちら。

Bot からのメッセージをリアルタイムに表示する Web ページを簡単に開発できるのですが、以前公開したハンズオンがまさにこの構成なので、まだこの構成を試したことがない方は、ぜひつながっていく感動を味わってほしいです。

github.com

Azure Cognitive Services

続いて Azure Cognitive Services です。

これはコグニティブ機能を実現する「AI パーツ」ということで、REST API やクライアント SDK から簡単に利用できるもので、ちょっと AI っぽい処理を追加したいな、というときにオススメのものになります。

QnA Maker

特に LINE Bot にオススメなのは、QnA Maker です。事前に用意したナレッジベースを元に、ユーザーからの質問に回答する AI を作成することができるものになります。

ナレッジベースは FAQ ページ等から自動生成して、さらにそこからカスタマイズしていくこともできます。

docs.microsoft.com

LUIS

Bot でよく使うのは、自然言語処理の LUIS（Language Understanding）です。

サンプルの文章を登録して、そのインテント（意図）とエンティティ（文章中の、パラメータ的な意味のある要素）を指定して、自然言語のテキストを理解できるようにするものになります。

これを使うことで自然な会話ができる Bot を作ることができます。Bot Service / Bot Framework Composer の裏でも LUIS が使われているので、Azure における Bot 開発では合わせて使うことが多いものになります。

docs.microsoft.com

Computer Vision

続いて画像系のサービスですが、LINE Bot のある機能と相性がいい Computer Vision を紹介します。

docs.microsoft.com

Computer Vision は画像分析に関する機能を提供するサービスですが、この中に「サムネイル生成」の API があります。

大きな画像を投げると、そこから重要な部分（関心領域）を残してトリミングをして小さいサイズの画像作ってくれます。

docs.microsoft.com

LINE Bot で画像メッセージを送るとき、オリジナル画像と小さいサイズのサムネイル用のプレビュー画像の2つを指定しますよね。このプレビュー用画像を生成するのに、この機能がぴったりなんです。

Azure Blob Storage

続いて Blob Storage です。

ひとつ前に紹介した画像メッセージにも絡みますが、Blob Storage が静的リソースの置き場に適しています。

docs.microsoft.com

LINE Bot の画像メッセージや動画メッセージなどでどのデータを送るか指定する際には、その URL を指定します。

任意の画像を用意し、その URL を得る 1 番簡単な方法は、Blob Storage に画像を置き、パブリックアクセスを許可する設定にすることです。

公開 URL が1つ1つのファイルに対して得られるので、それを LINE Bot で送ってやればよいです。

しかし、問答無用で公開する設定にするのが憚られる場面もあるでしょう。一つのファイルの URL から、同じストレージ上の別ファイルの URL を推測されてしまう危険性もあります。

こういった危険を避けるための方法として紹介したいのが、SAS トークンを使ったセキュア運用です。

SAS（Shared Access Signatures）で Azure Storage のへのアクセス制限をかけることができ、リクエストの有効性を確認する「SAS トークン」をBlob単位・アクセス単位で生成し、URL に付与することで Blob コンテナーのパブリックアクセスレベルを「プライベート」のまま、SAS トークン入りの URL を知っている人のみにアクセスできるようにすることができます。

docs.microsoft.com

こちらに関しては、以前に記事を書いたのであわせてみていただけたらと思います。

himanago.hatenablog.com

コンテナのパブリックアクセスレベルが匿名アクセスできないような形になっていても、このトークンつきの URL からならアクセスできるので、LINE Bot で画像等を送信する時にこのトークンを発行して、そのURLを送ってあげると、よりセキュアに運用できるんじゃないかな、ということでぜひ使ってみてほしい機能です。

レシピ：画像メッセージ用リソースの作成

Computer Vision を活用したレシピです。

サムネイル画像を Logic App で作成するような連携処理を組むことで、LINE Bot で使用するリソースを効率よく作ることができます。

…と思ってスライドを作ったんですが、 「Blob に画像を置いたらサムネイルが自動で作られる」というふうに Logic App でフローを組むほうが手軽かつ便利そうです（そのうち記事を書きます）。

Azure × LIFF/ミニアプリ

概要

LIFF と Azure の組み合わせについては、そもそも LIFF が Web アプリになりますので、通常の動的な Web アプリであれば、Web Apps で全然開発が可能です。

認証の統合ができるようになっているので、Azure AD B2C で LINE ログインと連携したものを組み込むことで、LIFF アプリとしていい感じに動くので便利です。

docs.microsoft.com

Azure AD B2C

Azure AD B2C では、外部の ID プロバイダーとの連携を Azure に組み込むためのものですが、LINE ログインも「カスタムポリシー」を作成すれば実現可能になっています。

カスタムポリシーの作成は結構難しいのですが、これを作れば Web アプリへの LIFF・LINE ログインの統合ができます。

docs.microsoft.com

Azure Static Web Apps

バックエンドで Java や .NET が動くような動的な Web アプリであれば、Web Apps を使いますが、静的な Web アプリであれば、Static Web Apps がおすすめです。

docs.microsoft.com

静的な Web アプリは、クライアントサイドで JavaScript が動いて実現するようなウェブサイトのことですが、もともと Azure には静的サイトホスティングのために Blob Storage で Web ページとして公開できる機能がありました。

docs.microsoft.com

ただ、機能としては貧弱だったので、より高機能な Static Web Apps が登場しました。

Static Web Apps は、GitHub との統合によって、リポジトリの更新のたびに自動でビルド・デプロイされるようになっています。

また、同時にバックエンドの API が開発できるようになっており、LIFF と Bot・連携機能まで同時に開発したりなどができます。

まだプレビューですが、GA のタイミングではもっと便利になるのではと思ってすごく期待しております（個人的には Azure DevOps 対応を待っています。GitHub を見る限り、もうすぐな様子）。

※以前ハンズオンイベントで簡単にまとめたスライドを作って発表しましたのでこちらもよろしければご参考に。

15分でわかる！Azure Static Web Apps from 拓将 平林

www.slideshare.net

その他便利な Azure サービス

そのほか、開発・運用サポートの面で LINE プラットフォームと相性がいいサービスを紹介です。

Azure Key Vault

シークレット情報や設定内容などを保存するのに便利。

docs.microsoft.com

Azure DevOps

ソースコード管理からプロジェクト管理、CI/CD パイプラインなどを提供。Azure 以外でも組み合わせて使えるので広く使われてほしいサービスです。

5人まで無料だし、Azure サブスクリプションとは関係なしに使えるので、ぜひ！

Application Insights

「Azure Monitor」と呼ばれる、監視系サービス群のひとつ。使用しているアプリのログを貯めておいたり、アラートを受け取ることができます。

docs.microsoft.com

アプリケーションマップという、システムで使用しているサービスの全体像と障害箇所を確認できる機能もあります。

docs.microsoft.com

アラートはすばやく障害を検知するために、Logic Apps と連携してそこから Teams や Slack といったチャットを投げるように組んでおくのがおすすめです。

もちろん障害通知専用の LINE Bot を作っても OK。障害通知だけなので Push も確実に無料枠に収まります（おさまらないならそれはシステムがやばい…）。

[実装例] Azure × LINE Platform によるチャットシステムの構築

最後に実装例です。

Azure と LINE プラットフォームによるチャットシステムの構築です。

このような Web 画面を用意して、Web と LINE Bot でやりとりをする、というものです。

上で Cosmos DB と SignalR Service で画面を更新する話を書きましたが、LINE → 画面がそれ。

そして画面 → Web はその逆です。

画面側から送ったメッセージにも、この Change Feed の流れをそのまま活かして Push メッセージが送れます。

Azure Communication Service

上のような構成で Bot と Web 画面で双方向にやり取りができるようなシステムを作ることができますが、最近プレビューで登場してた Communication Service を使うと、これだけで往復の処理が作れるようになります。

docs.microsoft.com

実装についてはこちらの記事に書いています。

himanago.hatenablog.com

実際に動かしたデモです。セッション当日はうまくいかなかったので（スマホのミラーリングが止まってしまった…）、終了後に突貫で撮ったものがこれです。

今日のセッション、デモができなくてすみません！！
いま動画とりました。こんなかんじで動きます（ブロック解除から始まってるのは友だち追加処理から始めたいからです）。 #lpf_revup #lpf_revup_t
記事はこちら↓https://t.co/OUcyjqyNPb pic.twitter.com/KjZtoK7SNn

— ひらりん (Takumasa Hirabayashi) (@himarin269) 2020年11月14日

デモのもとになったサンプルアプリはこちらです。

docs.microsoft.com

まとめ

Azure は PaaS がやっぱり強い！ので、（特に小規模向けや個人開発などでは）あまり複雑なことを考えたり設定したりしなくても、コツさえつかめば簡単に動くものが作れてしまいます。

おなじく手軽に UI が手に入る LINE Bot と組み合わせることで、すぐに面白いものが作れます。なので、どんどん LINE × Azure を試してほしいと思っています。

おわりに

長い…

とりあえず、いままで Azure × LINE でいろいろやってきて、それの総まとめ的なものにしたかったセッションです。

詰め込みすぎた感はありますが、詰め込めるだけ詰め込んでしまいたい！という気持ちでした。

実はまだまだ紹介し足りない部分も多いですが（たとえば大規模向けの話とか…）、ひとまず今回まではここまでです。ありがとうございました。

LPF REV UP 2020「あなたならどう使う？最新Azureレシピ for LINE Platform」フォローアップ（前半）

2020年ももう終わりですね…。
2020年を振り返り…たいところですが、直近11月・12月を振り返っていなかったので振り返っておきます。

はじめに

1か月半ほど前になってしまいますが、LPF REV UP 2020 という LINE 系コミュニティの大型イベントで登壇しました。 revup.jp

こちらは LINE Developer Community（東京）、LINE Developer Group Kansai（関西）、LINE Developer Group Q-shu（九州）の合同カンファレンスで、オンラインイベントながら東京/大阪/福岡の3トラックで行われたわりと大きいイベントでした。

本記事はこちらで登壇させていただいた、「あなたならどう使う？最新Azureレシピ for LINE Platform」というセッションのフォローアップ記事になります。

スライドと本記事双方で Azure の公式ドキュメントへのリンクを掲載していますので、詳細情報へのアクセスの足掛かりとしても使っていただけたら、と思います。

まずは、先にスライドと動画を置いておきます。

スライド（SlideShare）

[REV UP] あなたならどう使う？最新Azureレシピ for LINE Platform from 拓将 平林

www2.slideshare.net

セッション動画（YouTube）

youtu.be

内容解説

以下、スライドを並べながら、セッション当日言いきれなかった部分など補足しながら説明していきます。

セッションの概要

今回のセッションでは、LINE API を使った開発を Microsoft Azure で行った場合の Tips を知っている限りたくさん集めました。

※セッション概要

Microsoft Azureをはじめとしたパブリッククラウドには便利なサービスがたくさんあり、それらをうまく組み合わせれば機能・コストに優れたサービス・システム構築が可能となります。 しかし、クラウドプラットフォームには把握し切れないほどの種類のサービスが存在し、どれをどのように使えば効果的なのかわかりにくいことがあるかと思います。 本セッションでは、「LINE Platform との組み合わせ」をテーマにAzureサービスの "使いドコロ" を、LINE Bot / LIFF 開発事例を交えて紹介します。

内容は以下の通り。

本記事も同じ流れで書いていきますが、今回は前半戦ということで、「Azure × Messaging API」のメイン編について書いていきます。

Azure × Messaging API（メイン編）

まずは基本の、LINE Bot のバックエンド（Webhook エンドポイント）として使えるサービス群の紹介です。

Messaging API の Webhook エンドポイント

LINE Bot を構築するときは、Messaging API を使ってユーザーからのメッセージ送信等のアクションに対応する処理を作りますが、HTTPS・JSON でのやりとりになるので、HTTPS で JSON の送受信ができるようなものであれば使うことができます。

Azure では大きくコードを書かないものとコードを書くものに大別でき、それぞれいくつかずつ見ていきます。

Azure Logic Apps

Logic Apps は、Azure が誇るノーコード/ローコードサービスで、多種多様なサービス同士をコーディングなしでつなげていくことを得意とします。

さまざまなイベントをトリガーに動作する自動化フローが組めますが、HTTP 受信時に動くものも作れるので、LINE Bot のバックエンドとしても使えます。

docs.microsoft.com

Logic Apps の利点として Azure 内外のサービスとの連携が挙げられるのですが、Logic Apps は JSON データの扱いも得意なので、Logic Apps に用意されている既製のアクション・トリガーがないものでも JSON でやりとりさえできれば簡単に連携ができるようになります。

JSON の定義を登録すると（サンプルデータを利用できます）、JSON に含まれるプロパティなどを後続処理で選択できるようになり、慣れると簡単に JSON を使うサービス同士の連携が組めるようになります。

LINE Bot（Messaging API）との連携も簡単です。

サービス間の連携が得意な Logic Apps なので、コードで連携処理をひとつひとつ書いていくよりも断然早く実現できるので、そういった場合に使うのがおすすめです。

docs.microsoft.com

このような特徴から、Logic Apps を使う場面としては他サービスとの連携を行いたい場合に使うとよいでしょう。

対話を何往復かするような複雑な対話フローをもつ LINE Bot の場合は、Logic Apps 単体で組み上げるのは大変ですが、連携の強みを活かすために一部処理のみに Logic Apps を採用する、というのは十分に考えられます。

補足

「Webhook のエンドポイント」という観点からはずれますが、さまざまなイベントをトリガーにできるため、それを LINE に Push Message で通知するような Bot も容易に作ることができます。

Bot Framework Composer

続いて Bot Framework Composer です。

こちらは自分のローカル環境にインストールして使うエディターでチャットボットの対話フローを定義するノーコードツールです。

docs.microsoft.com

Bot Framework Emulator を使って動作確認しながら開発していきます。

ノーコードなツールとはいえ、実体は Bot Framework で、Git など開発者向けツールを前提としたものであるので、基本的には開発者向けのツールといえます。

また、できあがったチャットボットを Azure にデプロイすると、Cosmos DB や LUIS、Bot Service といった複数のサービスの組み合わせで実現されるため、それぞれのサービスの使用方法を知っている必要があります。

なお、Azure にデプロイしたチャットボットは Azure Bot Service を使用するので、LINE Bot との接続も簡単です。

Azure Web Apps

続いてコードを書く系のサービスです。

HTTPS で JSON の送受信をする仕組みをシンプルに Web アプリで実現する方法です。

Azure には Web Apps という Web アプリ実行用の非常に優秀な PaaS が用意されています。

こちらに LINE Bot のバックエンドをデプロイしたり、既存 Web アプリに LINE Bot 機能を追加したりすることが考えられます。

docs.microsoft.com

OS や言語、フレームワークもいろいろなものが使えるので、自分の得意な環境で LINE Bot を開発できます。

ここで書ききれないほどのメリットがありますが、特に Azure DevOps 等と組み合わせた CI/CD、スロット機能を使ったブルーグリーンデプロイメントが強力で実運用で非常に役立ちます（このあたりは次の Azure Functions と共通です）。

Azure Functions

続いて Azure Functions です。個人的には、最も手軽な Bot バックエンドとして特におすすめしたいサービスです。

いわゆる「サーバーレス」なコード実行環境で、書いたコードがすぐに動くのでシンプルな LINE Bot を作るのに最適なサービスです。

docs.microsoft.com

単体で HTTP の通信ができることが便利で、これだけですぐに Webhook エンドポイントとして使用できます。

そのほかにも入出力バインディングによって他サービスとの組み合わせも手軽にできます。

使用できる言語は C#、JavaScript（TypeScript）、F#、Java、PowerShell、Python ですが、カスタムハンドラーを使えば好きな言語で実装することができます（裏に Web サーバーを独自に立てる）。

docs.microsoft.com

docs.microsoft.com

また、3つの異なるホスティングプランがあることも特徴です。

コールドスタートを気にしなければ、Consumption プランが最も安価ですが、コールドスタートを気にするのであれば（＋ある程度のランニングコストを許容するなら）App Service プランや Premium プランを選択しましょう。

docs.microsoft.com

Durable Functions

Azure Functions には、Durable Functions という拡張機能が使えます。

こちらはサーバーレスな関数の組み合わせでステートフルな（Functions 側で状態を保持した）処理が書けるもので、例のような処理が作れます。

2020/12 現在で使用できる言語は C#、JavaScript（TypeScript）、Python、PowerShell（プレビュー）です。

docs.microsoft.com

基本的には、通常の Function（スターター関数と呼ぶ）からオーケストレーター関数を呼び出し、それがアクティビティ関数と呼ばれる実処理を担当する関数を呼びながら状態を都度保持していく仕組みとなっています。

それぞれの関数で使えるこれらの機能を組み合わせて、ステートフルなフローを実現します。

初見ではイメージが付きづらいかもしれませんが、コードのみでフローを作れるという点が非常に強力です。

レシピ：Durable Functionsによる LIFF 連携

個人的によく使う組み合わせなのですが、LIFF（LINE トークルーム内で使用できる Web アプリ）の処理と LINE Bot の処理を連携させる際に、Durable Functions が便利です。

Bot、LIFF 双方のバックエンドを Azure Functions で作り、イベント待機・イベント発火によって待ち合わせをします。LIFF も Bot も共通の LINE ユーザー ID がとれるので、それをキー（Durable Functions ではオーケストレーターの「インスタンス ID」を LINE ユーザー ID にする）に同一ユーザーの処理を連携できます。

こちらは以前のセッションでも紹介したものの一部になります。以下の記事で登壇内容を解説していますので合わせてみてみてください。

himanago.hatenablog.com

なお、Durable Functions の最近のアップデート（v2.4.0）で Durable Client Factory という機能が追加されました。これは、なんと Durable Functions の機能を利用するクライアントクラスの生成を実現する機能で、Azure Functions 外からも利用できます。

これにより Azure Functions でない、たとえば ASP.NET Core で開発した Web App だったり、Bot Framework で作った Bot Service だったりから Durable Functions の機能を呼び出すことができるので、Azure Functions 同士でなくてもこの待ち合わせの連携処理を利用することができるようになるようです。

公式より、ASP.NET Core から呼び出すサンプル（C#）が公開されているので、こちらを見るとわかります。 azure-functions-durable-extension/samples/todolist-aspnetcore at dev · Azure/azure-functions-durable-extension · GitHub

オリジナルフレームワーク「DurableBotEngine」について

実はこの Durable Functions のステートフルな機能を利用して、LINE Bot の対話フローを管理するためのフレームワークを開発しています。

現在は自然言語処理に Dialogflow（Google）の利用が前提となっていますが、LUIS（Azure）も使えるようにしようと思っています。

個人で開発していますが、実プロダクトにも入れる想定で利用をしていて、現在安定的に使えるよう開発を進めています。

こちらについては、もう少し整ったら使い方など書いていけたらと思っています。

www.nuget.org

つづきます

ひとまず、ここまでを前半として、続きは後半にて書いていきます。

後半部分は年内公開間に合わずで、年をまたぐことになってしまいましたが、次回も、そして来年も、よろしければどうぞよろしくお願いします。