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）
www2.slideshare.net
セッション動画（YouTube）
内容解説
以下、スライドを並べながら、セッション当日言いきれなかった部分など補足しながら説明していきます。
セッションの概要
今回のセッションでは、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 のバックエンドとしても使えます。
Logic Apps の利点として Azure 内外のサービスとの連携が挙げられるのですが、Logic Apps は JSON データの扱いも得意なので、Logic Apps に用意されている既製のアクション・トリガーがないものでも JSON でやりとりさえできれば簡単に連携ができるようになります。
JSON の定義を登録すると（サンプルデータを利用できます）、JSON に含まれるプロパティなどを後続処理で選択できるようになり、慣れると簡単に JSON を使うサービス同士の連携が組めるようになります。
LINE Bot（Messaging API）との連携も簡単です。
サービス間の連携が得意な Logic Apps なので、コードで連携処理をひとつひとつ書いていくよりも断然早く実現できるので、そういった場合に使うのがおすすめです。
このような特徴から、Logic Apps を使う場面としては他サービスとの連携を行いたい場合に使うとよいでしょう。
対話を何往復かするような複雑な対話フローをもつ LINE Bot の場合は、Logic Apps 単体で組み上げるのは大変ですが、連携の強みを活かすために一部処理のみに Logic Apps を採用する、というのは十分に考えられます。
補足
「Webhook のエンドポイント」という観点からはずれますが、さまざまなイベントをトリガーにできるため、それを LINE に Push Message で通知するような Bot も容易に作ることができます。
Bot Framework Composer
続いて Bot Framework Composer です。
こちらは自分のローカル環境にインストールして使うエディターでチャットボットの対話フローを定義するノーコードツールです。
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 機能を追加したりすることが考えられます。
OS や言語、フレームワークもいろいろなものが使えるので、自分の得意な環境で LINE Bot を開発できます。
ここで書ききれないほどのメリットがありますが、特に Azure DevOps 等と組み合わせた CI/CD、スロット機能を使ったブルーグリーンデプロイメントが強力で実運用で非常に役立ちます（このあたりは次の Azure Functions と共通です）。
Azure Functions
続いて Azure Functions です。個人的には、最も手軽な Bot バックエンドとして特におすすめしたいサービスです。
いわゆる「サーバーレス」なコード実行環境で、書いたコードがすぐに動くのでシンプルな LINE Bot を作るのに最適なサービスです。
単体で HTTP の通信ができることが便利で、これだけですぐに Webhook エンドポイントとして使用できます。
そのほかにも入出力バインディングによって他サービスとの組み合わせも手軽にできます。
使用できる言語は C#、JavaScript（TypeScript）、F#、Java、PowerShell、Python ですが、カスタムハンドラーを使えば好きな言語で実装することができます（裏に Web サーバーを独自に立てる）。
また、3つの異なるホスティングプランがあることも特徴です。
コールドスタートを気にしなければ、Consumption プランが最も安価ですが、コールドスタートを気にするのであれば（＋ある程度のランニングコストを許容するなら）App Service プランや Premium プランを選択しましょう。
Durable Functions
Azure Functions には、Durable Functions という拡張機能が使えます。
こちらはサーバーレスな関数の組み合わせでステートフルな（Functions 側で状態を保持した）処理が書けるもので、例のような処理が作れます。
2020/12 現在で使用できる言語は C#、JavaScript（TypeScript）、Python、PowerShell（プレビュー）です。
基本的には、通常の Function（スターター関数と呼ぶ）からオーケストレーター関数を呼び出し、それがアクティビティ関数と呼ばれる実処理を担当する関数を呼びながら状態を都度保持していく仕組みとなっています。
それぞれの関数で使えるこれらの機能を組み合わせて、ステートフルなフローを実現します。
初見ではイメージが付きづらいかもしれませんが、コードのみでフローを作れるという点が非常に強力です。
レシピ：Durable Functionsによる LIFF 連携
個人的によく使う組み合わせなのですが、LIFF（LINE トークルーム内で使用できる Web アプリ）の処理と LINE Bot の処理を連携させる際に、Durable Functions が便利です。
Bot、LIFF 双方のバックエンドを Azure Functions で作り、イベント待機・イベント発火によって待ち合わせをします。LIFF も Bot も共通の LINE ユーザー ID がとれるので、それをキー（Durable Functions ではオーケストレーターの「インスタンス ID」を LINE ユーザー ID にする）に同一ユーザーの処理を連携できます。
こちらは以前のセッションでも紹介したものの一部になります。以下の記事で登壇内容を解説していますので合わせてみてみてください。
なお、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）も使えるようにしようと思っています。
個人で開発していますが、実プロダクトにも入れる想定で利用をしていて、現在安定的に使えるよう開発を進めています。
こちらについては、もう少し整ったら使い方など書いていけたらと思っています。
つづきます
ひとまず、ここまでを前半として、続きは後半にて書いていきます。
後半部分は年内公開間に合わずで、年をまたぐことになってしまいましたが、次回も、そして来年も、よろしければどうぞよろしくお願いします。
