himanago

Azure・C#などのMS系技術やLINE関連技術など、好きな技術について書くブログ

Azure Functions に Django で作った Web アプリをホストする

はじめに

ちょっとおもしろい記事を見つけました。

Pythonフルスタックな Web アプリケーション開発フレームワークである「Django」で作ったアプリケーションを、まるごと Azure Functions に乗せてしまうというものです。

szwarc.ai

フルスタックな Web アプリケーションフレームワークで作った重厚なアプリが、サーバーレスな関数上で動くということで、なかなかおもしろそうです。

実際にやってみた

この記事をベースに、実際に Azure 上で動くか試してみます。

Azure SQL Database の作成

まず DB を Azure 上に作ります。元記事と同じように、サーバーレスで作っていきます。

f:id:himanago:20220203002826p:plain

サーバーは新規作成で、構成は以下の通り。

f:id:himanago:20220203002711p:plain

データベースの構成は下記のような感じで。

f:id:himanago:20220203002507p:plain

f:id:himanago:20220203002557p:plain

作成されたら、ファイアウォール設定を変えておきます。

これから作る Django のアプリケーションをローカルで動かす際もこの Azure 上の DB を見に行くので、ローカルからも接続できるようにしておきます。

f:id:himanago:20220203004410p:plain

ローカルで Azure Functions のプロジェクト作成

VS Code を開き、Azure Functions 拡張機能から Python の Function App を作っていきます。

f:id:himanago:20220203003825p:plain

関数の名前は DjangoTrigger で。

f:id:himanago:20220203003838p:plain

承認レベルは必ず Anonymous にします。

f:id:himanago:20220203003920p:plain

Functions プロジェクト内に Django アプリ作成

つづいて Django アプリを作っていきます。

venv を作ってから、

python -m venv venv

requirements.txt を編集します。下3行を追記。

azure-functions
django==4.0.2
mssql-django
whitenoise

まとめて pip install します。

pip install -r requirements.txt

Django プロジェクトをつくります。

. を末尾につければ直下に直接作ってくれます。

django-admin startproject config .

ここまででこのようになっていれば OK です。

f:id:himanago:20220203005929p:plain

Function → Django をつなぐ設定

Functions から Django が呼ばれるように設定していきます。このあたりは元記事にかいてあるとおりです。

DjangoTrigger/function.json を以下のようにします("route": の行を追加)。

{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "authLevel": "anonymous",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ],
      "route": "DjangoTrigger/{*path_info}"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ]
}

DjangoTrigger/__init__.py を丸ごと書き換えます。

import azure.functions as func
from config.wsgi import application

def main(req: func.HttpRequest, context: func.Context) -> func.HttpResponse:
    return func.WsgiMiddleware(application).handle(req, context)

ここでいったん動作確認してみます。

func host start

ブラウザで開いてみても、まだ動きません。

f:id:himanago:20220203010658p:plain

より細かい設定をしていきます。Azure の SQL DB への接続もやってしまいます。

config/settings.py の内容を編集していきます。

# (略)

import os

# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

FUNCTION_APP_PATH = 'api/DjangoTrigger'   # 追加

# (略)

ALLOWED_HOSTS = ['*']  # 変更

# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'whitenoise.runserver_nostatic',  # 追加
]

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware',  # 追加
]

# (略)

# 変更
DATABASES = {
    'default': {
        'ENGINE': 'mssql',
        'NAME': 'xxxx-xxxx-xxxx',       # SQL DB の名称
        'USER': 'xxxxxxxx',                   # サーバー管理者ログイン
        'PASSWORD': '************',    # サーバー管理者パスワード
        'HOST': 'xxxxxxx.database.windows.net',  # ホスト名
        'PORT': '',
        'OPTIONS': {
            'driver': 'ODBC Driver 17 for SQL Server',
        },
    }
}

# (略)

STATIC_URL = '/' + FUNCTION_APP_PATH + '/static/'   # 変更

つづいて config/urls.py を書き換えます。

from django.contrib import admin
from django.urls import path
from config.settings import FUNCTION_APP_PATH   # <- import our FUNCTION_APP_PATH constant from settings.py file

urlpatterns = [
    path(FUNCTION_APP_PATH + '/admin/', admin.site.urls),  # <- change "path" to include FUNCITION_APP_PATH
]

ここまでできたら、もう一度起動してみます。

func host start

このタイミングで DB につなぐので、ODBC Driver がインストールされていないと起動できません。

インストールされていなければ、入れておきましょう。

docs.microsoft.com

自分が Mac でやったときは Xcode を最新化する必要があったりで結構面倒でした。

エラーなく起動したら、http://localhost:7071/api/DjangoTrigger/admin/ をブラウザで開いてみます。

以下のようなログイン画面が表示されれば、OK です(Django が動いてますね!)。

f:id:himanago:20220203092807p:plain

データベースへのテーブル作成

より本格的に使えるか試すため、SQL DB にテーブルを作っていきます。

python manage.py migrate

Mac でやったときはここで

[08001] [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection (0) (SQLDriverConnect)

というエラーが出てしまいました。どうも Mac に入っている OpenSSL が悪いらしく、LibreSSL から OpenSSL@1.1 にしたり

github.com

を参考にいろいろやったりしてなんとか解消しました(ちなみに Windows の環境でやったときはすんなりでした)。

ログインユーザー作成

うまく動いたら、続いてアプリの管理者ユーザーを作ります。

コマンドで作成します。

python manage.py createsuperuser

指示に従って、ユーザー名、メールアドレス、パスワードを設定します。

モデルクラス&テーブル作成

元記事にはないですが、新しいモデルクラスとテーブルも作ってみます。

作るテーブルは公式チュートリアルのものを使います。

docs.djangoproject.com

python manage.py startapp polls

ファイルが作られるので、その中の polls/models.py を以下のようにします。

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

config/settings.py にさらに追記します。

INSTALLED_APPS = [
    'polls.apps.PollsConfig',  # これを追加
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'whitenoise.runserver_nostatic',
]

コマンドを実行します。

python manage.py makemigrations polls
python manage.py sqlmigrate polls 0001
python manage.py migrate

Azure 上の SQL DB に、作ったモデルクラスにあったテーブルが作成されます。

最後に polls/admin.py を以下のようにします。

from django.contrib import admin
from .models import Question
from .models import Choice

admin.site.register(Question)
admin.site.register(Choice)

ローカルでの動作確認

func host start でローカルで実行して、以下の http://localhost:7071/api/DjangoTrigger/admin/ にアクセスしてみます。

createsuperuser で作った ユーザー名とパスワードでログインすると、以下のようになります。

f:id:himanago:20220203181751p:plain

ちゃんと動いてるっぽいです!

Function App のデプロイ

ではいよいよ Azure に Function App としてデプロイしてみます。

VS Code拡張機能を使っていきます。

Azure にサインインします。

f:id:himanago:20220204142809p:plain

「Deploy to Function App...」をクリック。

f:id:himanago:20220204142957p:plain

あとはプロジェクト、サブスクリプション、リージョンなどを指示通りに指定していけば作成・デプロイされます。

Azure 上での動作確認

デプロイ後は、Azure ポータルにいかずとも VS Code 上で関数 URL を得られます。

f:id:himanago:20220204143546p:plain

コピーした URL をもとにして、https://xxxxxxxxxx.azurewebsites.net/api/DjangoTrigger/admin/ となるように編集(大文字小文字に注意!)してアクセスしてみます。

ログイン画面 f:id:himanago:20220204144007p:plain

管理画面 f:id:himanago:20220204144300p:plain

データ追加 f:id:himanago:20220204144723p:plain

f:id:himanago:20220204144733p:plain

f:id:himanago:20220204144743p:plain

f:id:himanago:20220204144753p:plain

ちゃんと動いてます!

おわりに

このままでは URL に api などが入っていていまいちなのですが、Web アプリがまるごと Function App に乗るのはなかなかおもしろいですね。

Consumption プランで乗せてしまえば、コールドスタートの問題はあるものの低価格&スケーラブルに Django アプリが運用できます。

ちなみにログイン機能で使われるセッションキーについてですが、サーバー側はデータベースに保存されるようになっているので、サーバーレスでも運用できそうです。

Azure Cognitive Service for Language + Azure Bot Service で超簡単にチャットボット作成④~Alexa スキルとしての公開

以下のつづきです。たぶん今回が最終回。

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

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

③ LINE Botとしての公開 himanago.hatenablog.com

最後は Alexa

Azure Cognitive Service for Language + Azure Bot Service で作ったチャットボットを、最後は Alexa スキルとしてスマートスピーカーから使えるようにしてみます。

ドキュメントの手順どおりやればたしかに簡単に公開できるのですが…ちょっといままでと違ってそのままで OK!とはならなそうです。

さっそく手順をみていきましょう。

手順

接続方法はこちらにまとまっています。

docs.microsoft.com

このとおりにやってみます。

Alexa Developer Console でのスキル作成

Alexa Developer Console にログインし、「スキルの作成」ボタンをクリックします。

f:id:himanago:20220131230021p:plain

新しいスキルの名前を入力し、「日本語」「カスタム」「ユーザー定義のプロビジョニング」を選択して、最後に上部の「スキルを作成」をクリックします。

f:id:himanago:20220131230615p:plain

「スクラッチで作成」が選択された状態で「選択」をクリックします。

f:id:himanago:20220131230823p:plain

するとスキルが作成されます。

対話モデル JSON の登録

通常はここからスキルとの対話をどのように行うかを設計し、対話モデルを作っていくのですが、Azure Bot Service とつなぐ場合はそこはいりません。対話は Azure Bot Service 側ですべて処理するので、Alexa スキルはユーザーからの入力をそのまま伝える役割しか担わないのです。

Alexa スキルの場合、phrase スロットを使うと入力そのままを処理できます。

とてもシンプルなモデルになるので、ドキュメントにはあらかじめ JSON で定義された対話モデルが用意されています。

スキルダッシュボードの左側のメニューの「対話モデル」の「JSON エディター」に、以下の JSON を設定します。

一番上の呼び出し名と、一番下発話例3つが自分で考える部分です。

{
    "interactionModel": {
        "languageModel": {
            "invocationName": "アジュールサポート使い方ボット",
            "intents": [
                {
                    "name": "GetUserIntent",
                    "slots": [
                        {
                            "name": "phrase",
                            "type": "phrase"
                        }
                    ],
                    "samples": [
                        "{phrase}"
                    ]
                },
                {
                    "name": "AMAZON.StopIntent",
                    "samples": []
                }
            ],
            "types": [
                {
                    "name": "phrase",
                    "values": [
                        {
                            "name": {
                                "value": "サポートの使い方を教えて"
                            }
                        },
                        {
                            "name": {
                                "value": "サポートの対応言語を教えて"
                            }
                        },
                        {
                            "name": {
                                "value": "こんにちは"
                            }
                        }
                    ]
                }
            ]
        }
    }
}

起動名は、音声入力できちんと一致するような表現にしてあげないといけないので、実機テストをしながら誤動作しないような名前にしてあげましょう。

また、JSON エディター上では IME がオンだとうまく入力ができないので、JSON を完成させてからコピペするようにしたほうがいいです。

「モデルの保存」をクリックし、その後活性化される「モデルのビルド」をクリックします。これで対話モデルがスキルに反映されます。

f:id:himanago:20220131231851p:plain

Azure Bot Service との接続

Alexa 側のスキル ID を取得して Bot Service へ設定し、Bot Service の URL を Alexa スキルのエンドポイントに設定します。

ドキュメントでは Alexa Developer Console の最初のページを開けと書いてありますが、「エンドポイント」セクションを開くのが早いです。

スキル ID が表示されているので、これをコピーします。

f:id:himanago:20220131232413p:plain

Azure ポータルを別タブで開き、Azure Bot Service のチャンネルを有効化します。

f:id:himanago:20220126232903p:plain

スキル ID を貼り付け、エンドポイント URI をコピーします(まだ保存は押さない)。

f:id:himanago:20220131232931p:plain

Alexa Developer Console に戻り、サービス エンドポイントの種類を「HTTPS」に変更し、「デフォルトの地域」にコピーしたエンドポイント URI の値に設定します。

その下にの選択は「開発用のエンドポイントは、証明機関が発行したワイルドカード証明書をもつドメインサブドメインです」にします。

f:id:himanago:20220131233007p:plain

設定したら、上部の「エンドポイントを保存」をクリックします。

これで完成です!

動作確認

Developer Console の「テスト」から、「スキルテストが有効になっているステージ」を「開発中」にするとシミュレーターや実機で動作確認できます。

f:id:himanago:20220131235512p:plain

スキル起動後にあいさつが返ってきて、その後リスニング状態になります。

質問をすると回答が返ってきて再びリスニング状態に…という繰り返しで動きます。

おしゃべりもちゃんと対応してくれますし、音声認識による表現のぶれなども吸収してくれます。

ただ、回答が長いので VUI 向きではないかなと思うものも多いです。画面付きでなければ正直きついです。

やはりスマートスピーカーで使う場合は、音声になじむように回答を作らないといけないですね。

おわりに

クロスプラットフォームにチャットボットをまったくの実装なしに公開できる、というのは非常に優れたサービスだと思います。

とはいえ、チャットボット(スマートスピーカースキル)はそれぞれのプラットフォームや形式ごとに適した UI/UX が存在します。

質問・回答の1対1の対話だとしても、それぞれのチャンネル(プラットフォーム)に適した回答のしかたをするべきで、安易にそのまま公開すればよいというものではなさそうです(特に Alexa)。

実際複数のチャンネルに公開したい場合は単純に Language の質問回答をつなげただけで要件を満たすことはないと思うので、素直に Bot Framework で各チャンネル固有の実装をしてカスタマイズすべきでしょう。

限られた用途なら、今回紹介した手順でささっと公開することはありだと思います。

公開したいチャンネルの特性を踏まえて質問・回答をチューニングして、用途を絞って使っていきましょう。

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設定」で長期のチャネルアクセストークンを発行しておきましょう。

f:id:himanago:20220123112049p:plain

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

f:id:himanago:20220123111944p:plain

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

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

f:id:himanago:20220123112326p:plain

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

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

f:id:himanago:20220123112923p:plain

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

f:id:himanago:20220123113242p:plain

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

f:id:himanago:20220123113639p:plain

動作確認

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

f:id:himanago:20220123115050p:plain

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

つづく

あとひとつ、このあとは 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」をクリックします。

f:id:himanago:20220123100306p:plain

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

f:id:himanago:20220123100404p:plain

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

f:id:himanago:20220123100803p:plain

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

f:id:himanago:20220123113242p:plain

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

f:id:himanago:20220123101039p:plain

Teams で会話してみる

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

f:id:himanago:20220129201103p:plain

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

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

f:id:himanago:20220123101406p:plain

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

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

この「チャット」でだけ使う方法ではタブやメッセージング拡張機能などの 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/

f:id:himanago:20220128000536p:plain

Language リソースの作成

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

f:id:himanago:20220128003856p:plain

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

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

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

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

f:id:himanago:20220129001059p:plain

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

Azure Cognitive Search のリソースの作成

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

f:id:himanago:20220129002640p:plain

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

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

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

f:id:himanago:20220129003024p:plain

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

f:id:himanago:20220129004024p:plain

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

f:id:himanago:20220129004326p:plain

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

f:id:himanago:20220129005030p:plain

ナレッジベースの作成

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

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

f:id:himanago:20220129005452p:plain

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

f:id:himanago:20220129005722p:plain

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

f:id:himanago:20220129005942p:plain

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

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

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

f:id:himanago:20220123002514p:plain

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

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

f:id:himanago:20220129010736p:plain

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

f:id:himanago:20220129011120p:plain

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

f:id:himanago:20220129011346p:plain

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

f:id:himanago:20220129012313p:plain

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

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

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

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

f:id:himanago:20220129012104p:plain

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

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

f:id:himanago:20220129011558p:plain

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

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

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

f:id:himanago:20220129012819p:plain

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

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

f:id:himanago:20220129012915p:plain

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

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

f:id:himanago:20220129013135p:plain

Azure Bot Service リソースの作成

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

f:id:himanago:20220129013422p:plain

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

f:id:himanago:20220129013941p:plain

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

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

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

f:id:himanago:20220123012710p:plain

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

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

f:id:himanago:20220123095444p:plain

Web チャットとして公開

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

f:id:himanago:20220123100109p:plain

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

f:id:himanago:20220129104544p:plain

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

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

f:id:himanago:20220126235240p:plain

つづく

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

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

個人的に 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

f:id:himanago:20211231004821p:plain

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

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

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

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

f:id:himanago:20211231021114p:plain

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

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

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

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

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

作成されるフローの中身

リプライ

テキストのオウム返し

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

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

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

f:id:himanago:20211231023024p:plain

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

f:id:himanago:20211231023305p:plain

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

f:id:himanago:20211231023405p:plain

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

f:id:himanago:20211231023903p:plain

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

プッシュその他

ブロードキャスト

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

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

f:id:himanago:20211231021503p:plain

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

f:id:himanago:20211231021637p:plain

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

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

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

f:id:himanago:20211231022144p:plain

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

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

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

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

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

おわりに

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

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

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

2019年11月〜2020年7月の LINE Messaging API のアップデート

はじめに

LINE Messaging API の C# コミュニティ SDK の更新が長らくされていないなぁと思い、Messaging API そのもののアップデートをメモします(ほぼ個人用。プルリク出したい)。

2021年12月時点でどうなっているかを知りたいだけなので、該当期間中に追加されて廃止されたものについてはあえて触れません。

更新内容

2019年11月〜12月

スタンプの送信を通知するWebhookイベントに新しいプロパティが追加されました

スタンプの送信を通知するWebhookイベントに、stickerResourceType プロパティが追加。

ビーコンイベントにstayイベントが追加されました

ビーコンイベントに、ユーザーがビーコンの電波の受信圏に滞在していることを示す stay イベントが追加
※2021/1 時点で利用の新規受付停止中

Webhookイベントにmodeプロパティが追加されました

Webhookイベントに mode プロパティが追加。

2020年1月〜3月

Messaging APIにナローキャストメッセージを送信するエンドポイントが追加されました

ナローキャストメッセージを送信するエンドポイントが追加。

アイコンおよび表示名が変更できるようになりました

メッセージを送る際に任意のアイコンおよび表示名が指定できるように。

これはけっこう気に入ったアップデートだったので、すでに C# SDK にプルリクを出して更新済み。

イベントでも話しました。

www.slideshare.net

一部のエンドポイントのドメイン名変更

以下のエンドポイントのドメイン名を「api.line.me」から「api-data.line.me」に変更。

スタンプの送信を通知するWebhookイベントに新しいリソースタイプが追加されました

メッセージスタンプ(カスタマイズされたテキストを含むスタンプ)が発売されたことに伴い、スタンプの送信を通知するWebhookイベントの stickerResourceType プロパティに PER_STICKER_TEXT が追加。

チャネルアクセストークンv2.1をリリースしました

トークンの有効期限指定ができるようになったチャネルアクセストークンの新バージョン。
チャネルシークレットの代わりにJSON Web Token(JWT)を使用するようになったことでセキュリティが強化された。

2020年4月

テキストメッセージでLINE絵文字を送信する

テキストメッセージを送信する際、LINE 絵文字が送信できるように。

// LINE絵文字を含むテキストメッセージの例
{
    "type": "text",
    "text": "Look at this: $ It's a LINE emoji!",
    "emojis": [
        {
            "index": 14,
            "productId": "5ac1bfd5040ab15980c9b435",
            "emojiId": "001"
        }
    ]
}

ユーザーの言語を取得する

プロフィールを取得するエンドポイントで、既存のユーザープロフィール情報に加えて、language プロパティが返されるように。

マルチキャストの受信者数制限が削除

マルチキャストメッセージを送る エンドポイントで、1分間当たりの受信者数に制限があったがそれが削除。

2020年5月

メッセージの文字数制限やメディアファイルの使用条件が変更されました

テキストメッセージの文字数制限や、使用できるメディアファイルの条件が変更。

WebhookイベントのテキストメッセージオブジェクトからLINE絵文字情報を取得する

ユーザーが送信したテキストにLINE絵文字が含まれる場合にWebhookで届くテキストメッセージオブジェクトの emojis プロパティに、使用されているLINE絵文字の情報がLINE絵文字オブジェクトとして格納されるようになった。LINE 絵文字の種類は productId および emojiId で取得。

失敗したAPIリクエストを安全に再試行する

エラー/タイムアウト等でユーザーに正しくメッセージが配信されたかわからない場合に、安全に同じリクエストの再試行ができるよう HTTP リクエストヘッダーにリトライキー(X-Line-Retry-Key)を追加できるように(もし最初のリクエストでメッセージ配信がされていれば二重送信されずに済む)。

※このアップデートに関しては Cosmos DB との相性がいいよ!というセッションを10月にしました

www.slideshare.net

2020年6月①

グループの概要を取得する

LINE公式アカウントが参加しているグループのグループID、グループ名、アイコンのURLを取得するエンドポイントが追加。

グループに参加しているユーザーの人数を取得する

グループに参加しているユーザーの人数を取得するエンドポイントが追加。

トークルームに参加しているユーザーの人数を取得する

トークルームに参加しているユーザーの人数を取得するエンドポイントが追加。

2020年6月②

チャネルアクセストークンを識別するためのキーIDが追加されました

チャネルアクセストークンv2.1を発行する際に、トークンと対になる一意のキーID(key_id)を返すようになり、新たに追加されたすべての有効なチャネルアクセストークンv2.1のキーIDを取得するエンドポイントを利用して、キーIDと対になるチャネルアクセストークンを識別できるようになった。

2020年7月

LINEのAPIがTLS 1.3に対応しました

以下の LINE の API が、新たに TLS 1.3 に対応。※2020年8月4日以降

いったんここまで

実は結構前からまとめようとしていたのですが、なかなかまとめるのが大変で。。

https://developers.line.biz/ja/news/からピックアップしてるんですが、Messaging API のアップデート情報だけ絞って表示とかできないんですよね…。できる方法だったり別の場所にアップデート情報まとまってたりしたら教えてください。

中途半端なところですが、今回一記事にまとまらなかったので、次回に続きます。