こんにちは、サイオステクノロジー武井です。今回は、Azureで簡単にチャットボットを作れるサービス「Azure Bot Service」を世界一わかりみ深く説明したいと思います。
全2回シリーズでお届けする予定で、今回は一番基本である「オウム返しボット(入力した言葉をそのまま返すボット)」を作成することで、Azure Bot Serviceの基本を説明していきます。
チャットボットとは
「チャット」とは、皆さん御存知の通りネットワーク上でテキストや画像などを通して、ユーザー同士がコミュニケーションを取り合う手法です。近年、代表的なものでは、Slackなどがあります。
「ボット」とは、「ロボット」の略で人間に変わり、様々な処理を自動化してくれるプログラムのことです。
この2つの言葉をかけ合わせたのが「チャットボット」であり、「チャットボット」とはチャットによるコミュニケーションにおいて、あらかじめ作成されたプログラムに基づき、人間の問いかけに対して、人間らしく適切な応答を返してくれるシステムのことです。
代表的なのが、もうサービスは終了してしまいましたが、以前マイクロソフトが提供していた元女子高生AI「りんな」です。これは「りんな」という女子高生のキャラクターと会話を楽しむことができるチャットボットサービスです。りんなはLINE上で提供されているアカウントで、他愛ない会話を楽しむことが出来ました。もちろん、「りんな」という人物は実在せず、応答しているのは、マイクロソフトが開発したAIです。以下はその会話の例です。ちょっとおかしな返答もありますが、人間っぽい会話が出来ているのがご覧いただけるかと思います。
なぜ今チャットボットなの?
チャットボットという技術は以前からありました。しかしながら、そのベースを支える技術は「人工無脳」と言われるものであり、おせじにも人間らしい対話とはかけ離れたものでした。「人工無脳」の技術も様々ですが、その一つとして「辞書型」というのがあり、あらかじめ定義した特定のキーワードに対して、特定の答えを提示するというものです。当然これでは、人間らしい会話は実現出来ず、アタマの悪いロボットと会話しているようで、かなりの違和感を感じます。
そこで「AI」の登場です。AIを用いたチャットボットは、機械学習などの技術に基づいて、ユーザーの発言パターンを学習し、より人間らしい応答を返すことができるようになりました。昨今、マイクロソフトやGoogleなどの企業がこのAI技術の発展にしのぎを削っており、AIは爆発的な発展を遂げました。
AIの発展により、チャットボットはより人間的になり、実用的で身近なものになってきました。こうした経緯により、チャットボットブームが再来したわけです。
どんなときにチャットボットは役に立つの?
では我々の生活の中でチャットボットはどのように役立っているのでしょうか?代表的な活用事例をいくつかピックアップしてみます。
一問一答系チャットボット
「電源が入らなくなったけど、どうすればいいの?」「突然画面が真っ暗になった」「VPNの使い方がわからない」などのユーザーの質問に回答する一問一答の形式で回答するチャットボットです。
一問一答系チャットボットは、カスタマーサポート系業務の代替もしくは補助として有効です。今まで、人力で電話で受けていた顧客からの問い合わせをチャットボットで対応出来れば、スタッフ手間をかなり削減することが出来るばかりでなく、電話回線が混雑しているときにも待たさせることなく、回答を提供することが可能です。
また、開発側にも大きなメリットがあります。このような一問一答系チャットボットを必要とするカスタマーサポート系業務は、大抵FAQがドキュメントになっていることが多くあります。そのFAQをそのままシステムに取り込んでしまえば、もうチャットボットシステムの出来上がりです(極端に言えばですが)。後述する会話型チャットボットのように、いくつかの質問を繰り返して、初めて顧客の意図がわかるようなフローだと、ユーザーの回答を一旦どこかの外部ストレージに格納する必要があります。いわゆるステートフルな設計がマストとなり、開発が複雑になります。
それに比べて、一問一答系のチャットボットはステートレスでよいので、開発からリリースまで比較的短時間に行えるというメリットがあります。
Azure上でチャットボットを作成するサービス「Azure Bot Service」であれば、Cortana(マイクロソフトが開発したAIアシスタントで、Windowsの右下にあるアレです)と連携が可能です。Azure Bot ServiceとCortanaを連携すれば社内ヘルプデスクのチャットボットサービスを簡単に構築でき、情シス部隊が毎日定時に帰れるようになるのも夢ではありません。
会話形チャットボット
いくつかの質問を経て、初めてユーザーの意図がわかるようなチャットボットです。例えば、会議室の予約系業務がそれに該当します。「どこの会議室を予約しますか?」「時間帯は何時から何時までですか?」「参加者は誰ですか?」といった複数の質問に全て回答して、初めて会議室予約が成立するようなパターンです。
会話型チャットボットは、ユーザーの要求をきめ細やかに聞くことができる反面、開発は複雑になります。
チャットボットの実体は、Webアプリケーションであり、RestAPIです。基本的には、発言をするごとにRestAPIが呼ばれるような実装が多くあります。
いくつかの質問を繰り返して、初めてユーザーの意図がわかるようなフローだと、ユーザーの回答を一旦どこかの外部ストレージに格納する必要があります。いわゆるステートフルな設計がマストとなり、開発が複雑になります。
通知系チャットボット
リマインド系通知など、チャットボットの方から何かしらの通知を出す形態です。飲み会などの参加可否回答のリマインダー、セミナーの受講可否リマインダーなどに活用出来ます。
雑談系チャットボット
先程ご紹介した「りんな」を始めとした、他愛のない会話を楽しむことが出来る雑談系チャットボットです。
今はまだ人間らしい対話とは程遠いですが、AI技術の革新により、自然な対話が実現できるようになれば、悩みを持った人の話し相手になり、チャットボットは人間に寄り添うセラピストに近い存在になりうるかもしれません。
会話というインターフェースについて
「会話」というインターフェースについて考えてみたいと思います。
会話は、老若男女誰にでも馴染みやすいインターフェースです。文字によるものから音声に至るまで、我々の生活は会話によって成り立っており、チャットボットは、この会話というインターフェースをベースにしているのが、最大の強みです。
数年前のスマホアプリラッシュの際には数多くのスマホアプリが連日のようにリリースされました。そのインターフェースは、アプリごとに固有のもので、中には相当に複雑なものもあり、その習熟には、かなりの時間を要します。新しいものに敏感な若者であれば、楽に使いこなすかもしれませんが、比較的年配の層は、この手のものが苦手な方が多いのが事実です。Webインターフェースはスマホアプリよりも歴史が長いですが、同様のことが当てはまると思います。
その点、会話というインターフェースにおいては、先程もご説明したように、老若男女誰にでも馴染みのあるものです。チャットボットは、この会話というインターフェースを採用しているので、スマホアプリやWebアプリのような複雑なインターフェースとは違い、あらゆる年齢層をターゲットに出来るのが最大の強みです。
また、会話というインターフェースは、開発にとっても非常にアドバンテージがあります。スマホアプリやWebアプリは、アプリケーションプログラマーに加えて、UI/UXデザイナーを必要とします。このUI/UXデザイナーの調達が実は結構手間取ったりすることが多いんですよね。もしくは、アプリケーションエンジニア自信がUI/IXデザイナーを兼ねた結果、イマイチなUIになるケースとかよく散見されます^^;しかしながら、会話というインターフェースはデザインを必要としません。もちろん、会話の流れを設計する必要はあると思いますが、専任のエンジニアが必要ではないのではないなーと思います。
チャットボットのプラットフォーム
Webアプリを公開したい場合は、自前でWebサーバーを用意するか、クラウドのサービス上にWebアプリ実行プラットフォームを用意して、アプリケーションをデプロイ、そして、何らかの手段でそのURLを周知する必要があります。スマホアプリも同様ですね。ユーザーにいかに使ってもらうかは大きな課題です。しかもスマホアプリの市場はもう飽和状態、後発のベンダーが入っていけるほど、甘いもんではありません。
その点、チャットボットは違います。チャットボットの動作するプラットフォームは、Facebook、LINE、Skype、Teamsなどのメッセンジャーアプリです。各社ともチャットボットを作成するためのAPIを提供しています。
Webアプリやスマホアプリはたくさん種類がありすぎて、ユーザーによって毎日使うアプリは異なります。しかし、メッセンジャーアプリは毎日使いますよね。LINEはほぼ毎日、たくさんのユーザーが利用しています。
数千万のユーザーが毎日のように利用している慣れ親しんだプラットフォーム、慣れ親しんだUIで、サービスを提供できるというのは非常に大きなアドバンテージと言えます。
チャットボットは万能?
残念ながら、現段階において、チャットボットは万能とは言い切れません。先ほどの、私とりんなのやり取りを見て頂ければ分かるのですが、微妙に外してるのが分かると思います。現在、マイクロソフトやFacebookなどのIT界の巨人たちがしのぎを削るAI開発によって、AIの技術が革新的に発展すれば、チャットボットは万能たる存在になり得るかもしれませんし、それはそう遠くない未来かもしれません。ただ、まだまだ、チャットボットは発展途上と言わざるを得ません。
現状では、旧来の方法(人による対応やWebアプリケーション)と、チャットボットのハイブリッドな方法がベストです。
例えば、携帯電話のプラン変更をチャットボットで行うとします。携帯のプランはご存知かと思いますが、複雑怪奇です。現段階の技術では、これをチャットボットで行うのはかなり困難ですし、無理して実現しようとして、チャットボットがわけのわからない返答をしてもユーザビリティが下がるだけで、そのチャットボットは二度と利用してもらえなくなるかもしれません。
なので、ユーザーが「携帯のプランを変更したい」と発話したら、プランを変更するWebサイトへのリンクを案内して、そちらに誘導してあげたり、もしくは適宜、人間のオペレーターが補助するというのがよくある方法です。
無理してチャットボットだけで完結しようとせず、従来のアナログな技術とのハイブリッドが、現段階では最も妥当な解といえるのかもしれません。
実例を一つご紹介致します。アスクルの個人向け通販「LOHACO」も「マナミさん」というチャットボットを展開しています。「商品を交換したい」と入力すると、購入履歴のWebサイトに誘導されているのがわかります。
Azure Bot Serviceとは?
前置きが長くなりましたが、いよいよAzure Bot Serviceについてお話したいと思います。
Azure Bot Serviceはノンコーディングでチャットボットが作成できるサーバーレスなサービスです。
※でもちょっと凝ったことしようとすると、Bot Frameworkを使ったコーディングが必須です
通常、チャットボットを作る際には、RestAPIの基盤となるWebサーバー及びアプリケーションサーバー、会話のステートを格納するためのストレージ、認証基盤、チャットボットのプログラムそのものなどなど、たくさんのものが必要になります。Azure Bot Serviceは、これらのものを1つに詰め込んだ、いわゆるオールインワンパッケージなのです。
Azure Bot Serviceでチャットボットを作成する手段はいくつかあります。本ブログでご紹介するBot Framework SDKをつかったり、GUIで構築できるBot Framework Composerを使ったり、色々あります。しかし結局はどの方法を選んでもBot Framework SDKが裏で動いているのには変わりないですし、本質を理解するためには、Bot Framework SDKという低レイヤー(?)をベースにして説明するほうがよいのかなと思いますので、Bot Framework SDKを使って説明します。
下図は、Azure Bot Serviceの構成図になります。
Azure Bot Serviceはいくつかの層で構成されております。
ユーザークライアント層
FacebookやLINEなどの、ユーザーがチャットボットを利用するためのツールがある層です。Webアプリケーションであればブラウザ、スマホアプリであればダウンロードしたアプリそのものになります。
Web層
ユーザーが発話したとき、その内容がユーザークライアント層にあるLINEやFacebookからHTTPリクエストとして送信されてきます。Web層は、そのリクエストを受け取る層であり、チャネルとApp Serivceから構成されます。
チャネルは、LINEやFacebookからのHTTPリクエストを受け取り、後述するBot Frameworkが理解出来る形式に変換します。LINE用のチャネル、Facebook用のチャネルといった形で、様々なチャネルが用意されてます。こうすることで、Bot Frameworkをベースとした、たった1つのチャットボットアプリケーションを作るだけで、LINEやTeams、Facebookなど色々なチャットボットクライアントに対応出来るのです。実際の構成は、各チャネルごとに固有のコネクタサーバーというものがあり、LINE用のコネクタサーバーが、LINEからのリクエストを受け付けます。
そしてApp Serviceの中には、Bot Frameworkという、Azure Bot Serviceを稼働させるためのコアとなるアプリケーションフレームワークがあります。通常であれば、ユーザーからの発話に対する返答、会話フローの実装、ユーザーのセッション処理などを自前で作成しなければなりませんが、この辺りの開発を楽にするライブライやクラス群を提供するのが、Bot Frameworkです。Bot Frameworkの利用言語は、C#、Java、JavaScript、Pythonになります。
Cognitiveサービス層
ユーザーとの対話をより人間らしいものにするためのAIサービスが配置される層です。後述するQuestion Answeringなどがこの層に含まれます。
外部サービス層
多種多様な認証方式を持つIDプロバイダーであるAzure AD、Office365を始めとした様々なマイクロソフトクラウドサービスへのAPIを提供しているGraph APIなど、チャットボットが応答を返すために参照する外部サービスがこの層に含まれます。もちろんマイクロソフト以外のサービスも例外ではありません。Salesforce、サイボウズなどのサードパーティー製のサービスや、自社独自開発のWebサービスが含まれることもあります。
Azure Bot Serviceの処理の流れ
先程の構成図に沿って、ユーザーが発話してから、チャットボットが応答を返すまでの流れを解説します。
まず、クライアント層にあるLINEやFacebookからユーザーが発話します。その発話内容は、HTTPリクエストに乗って、チャネルに届けられます。
チャネルは、クライアント層のFacebookやLINE固有のHTTPリクエストを、その先のApp Service上にあるBot Frameworkが理解出来る形式に変換して、Bot Frameworkに渡します。
App Service上のBot Framework(の上で動作するアプリ)は、チャネルからのHTTPリクエストを受け取り、必要に応じて外部サービスにアクセスします。Azure ADで認証したり、後述するQuestion AnsweringなどのAIサービスを利用して、人間らしいレスポンスを作成します。
Bot Frameworkは、今までのプロセスを経て作成されたHTTPレスポンスをチャネル経由でユーザークライアント層のLINEやFacebookに返します。
今までの一連のフローを見て、お気付きの方もいらっしゃるとは思いますが、チャットボットの開発は、今までのWebアプリケーション開発となんら変わりはありません。
チャネルとBotアプリケーション間のシーケンス
Azure Bot Serviceの処理の流れで紹介したフローの中で、チャネルとBotアプリケーション間のフローについて、もう少々深く掘り下げてみようかと思います。
先程ご説明した以下の図ですが、これはチャネルからBotアプリケーションにHTTPリクエストしています。
そして以下の図ですが、これは回答をBotアプリケーションから、チャネルに回答を返しています。実はこのシーケンスは、先に紹介した「チャネルからBotアプリケーションへのHTTPリクエスト」ではなく、Botアプリケーションからチャネルに対してHTTPリクエストすることで回答を返しています。
つまりシーケンス図にするとこんな感じです。Botアプリケーションは発話内容をそのままオウム返しするものとしています。「Hello」と発話したら「You said “Hello”」と返すBotアプリケーションのシーケンスです。回答を返す際は、Botアプリケーションの方からチャネルにHTTPリクエストしています。つまり「チャネル→Botアプリケーション」と「Botアプリケーション→チャネル」という感じで双方向に接続しているわけです。
なので、認証についても「チャネル→Botアプリケーション」「Botアプリケーション→チャネル」の両方のケースが発生します。これは次章で説明致します。
Azure Bot Serviceの認証
Azure Bot Serviceの認証は様々なものがありますが、最も重要なものは以下の2つとなります。
- ユーザークライアント→チャネルの認証
- チャネル→Botアプリケーションの認証
- Botアプリケーション→チャネルの認証
ユーザークライアント→チャネルの認証
ユーザークライアントとチャネル間の認証は、その名のとおりです。
例えば、Webブラウザのチャットは、チャネルに対してRest APIを発行するのですが、その際にAuthorizationヘッダーにDirect Lineトークンというものをつけます。
LINEの場合は、LINE開発者コンソールから取得できるチャネルシークレットとチャネルアクセストークンをチャネル側にも配置して、認証します。
つまり、ユーザークライアントによって、認証方法は様々ということになります。
チャネル→Botアプリケーションの認証
チャネルからBotアプリケーションに接続する際にも認証が必要になります。まぁ当然ですよね。この認証はMicrosoftアプリIDというもので行われます。実態はサービスプリンシパルです。サービスプリンシパルの詳細は以下のブログをご覧頂けますと幸いです。
認証のシーケンスは以下のようになります。MicrosoftアプリIDは、Azure Bot Serviceのリソース作成時に作成することもできますし、既存のサービスプリンシパルを使うことも可能です。
① チャネルは、Azure Active DirectoryにMicrosoftアプリID、Microsoftアプリパスワードを渡す。
② チャネルは、Azure Active DirectoryからJWT形式のトークンを受け取る。
③ チャネルは、HTTPリクエストのAuthorizationヘッダにトークンを付与して、Botアプリケーションに渡す。
④ Botアプリケーションは、公開されている鍵でJWTに付与されている署名を検証して、問題なければ認証OKとする。
説明の都合上、シーケンスはかなり省略していますが、概ね上記の流れで認証します。
Botアプリケーション→チャネルの認証
こちらで説明したとおり、回答を返す場合は、Botアプリケーションからチャネルに接続する必要があります。
基本的には先程と方向が逆になるだけで処理自体は変わりありません。
① Botアプリケーションは、アプリの設定ファイル(appsettings.json)もしくはApp Serviceの環境変数にて定義されているMicrosoftアプリID・MicrosoftアプリパスワードをAzure Active Directoryに渡す。
② Botアプリケーションは、Azure Active DirectoryからJWT形式のトークンを受け取る。
③ Botアプリケーションは、HTTPリクエストのAuthorizationヘッダにトークンを付与して、Botアプリケーションに渡す。
④ チャネルは、公開されている鍵でJWTに付与されている署名を検証して、問題なければ認証OKとする。
Azure Bot Serviceを用いた構築・開発手順
では、実際にAzure Bot Serviceで簡単なチャットボット(ユーザーが発話した内容をオウム返しするだけのもの)を構築してみましょう。
構築・開発の流れは以下のようになります。
1.Azure Bot Serviceのリソース作成
Azureでのチャットボットアプリケーション開発に必要であるAzure Bot Serviceのリソースを作成します。これは先程ご紹介した以下の図の「Azure Bot Service」に当たる部分です。
2.App Serviceの作成
BotアプリケーションをデプロイするためのApp Serviceを作成します。これは先程ご紹介した以下の図の「App Service」に当たる部分です。
3.Visual Studioで開発
Visual StudioでBotアプリケーションの開発を行います。
4.Bot Framework Emulatorでテスト
3で開発したチャットボットアプリケーションを、Bot FrameworkのエミュレーターであるBot Framework Emulatorでテストをします。
5.Visual StudioからApp Serviceへデプロイ
開発したチャットボットアプリケーションをVisual StudioからApp Serviceへデプロイします。これでチャットボットアプリケーションは本番稼働状態となります。
では、次章より、このフローに基づいて、実際に構築・開発をしていきます。
Azure Bot Serviceのリソース作成
Azureポータル画面上部の「bot」と入力して表示される「Bot Service」をクリックします。
「+作成」をクリックします。
「Azure Bot」をクリックします。
「作成」をクリックします。
適宜必要な項目を入力します。
ボットハンドル | Azure Bot Serviceの名称でAzure全体で一意である必要があります。 |
サブスクリプション |
Azure Bot Serviceを作成するサブスクリプションです。 |
リソースグループ |
Azure Bot Serviceを作成するリソースグループです。 |
価格レベル | 無料であるF0と有料であるS1があります。詳細はこちらにて記載しております。 |
アプリの種類 |
こちらで説明した「チャネル→Botアプリケーションの認証」「Botアプリケーション→チャネルの認証」で利用されるMicrosoftAppIDになります。ここで作成されるMicrosoftAppIDの実態はサービスプリンシパルであり、「シングルテナント」「マルチテナント」「ユーザー割り当てマネージドID」のいずれかを選べます。ここでは「シングルテナント」を選択します。本当はユーザー割り当てマネージドIDが良いのですが、少々話がややこしくなりそうなので、今回はシングルテナントとします。 |
作成の種類 |
新規にMicrosoft App IDを作成するか、もしくは既存のものを利用するかを選択します。 |
内容を確認して、「作成」をクリックします。
これでAzure Bot Serviceの出来上がりです。
App Serviceの作成
App Serviceを作成します。Azureポータル画面上部の「app service」と入力して表示される「App Serivce」をクリックします。
「作成」をクリックします。
適宜必要な項目を入力します。
サブスクリプション | App Serviceを作成するサブスクリプションです。 |
リソースグループ |
App Serviceを作成するリソースグループです。 |
名前 |
App ServiceをAzure全体で一意に識別する名称です。URLのホスト名にもなります。 |
公開 | 今回は「コード」とします。 |
ランタイムスタック |
.NET6(LTS)とします。 |
オペレーティングシステム |
Windowsとします。 |
地域 |
どこでもOKです。 |
App Serviceプラン |
テスト用となのであればFreeでOKです。負荷に応じて適宜選択してください。 |
内容を確認して「作成」をクリックします。
これでApp Serviceの作成は完了です。
Visual Studioで開発
BotアプリケーションをVisual Studioで開発します。開発とは言っても、今回はプロジェクトのテンプレートをそのままApp Serviceにデプロイするので、開発といった開発はありませんが(´・ω・`)
ちなみに、本ブログではVisual Studio 2022を使います。
ということで、まずはBot Framework SDKのテンプレートを以下のURLからダウンロードします。これがないとBotのプロジェクトテンプレートを作成できません(><)
https://marketplace.visualstudio.com/items?itemName=BotBuilder.botbuilderv4
インストールしたらVisual Studioを起動して、「新しいプロジェクトの作成(N)」をクリックします。
画面上部のテキストボックスに「echo」と入力すると、「Echo Bot」というプロジェクトテンプレートが表示されます。これは、入力された内容をそのままオウム返しのように返すチャットボットのテンプレートになります。このプロジェクトテンプレートを選択して「次へ(N)」をクリックします。
プロジェクト名、場所、ソリューション名などを入力して、「作成(C)」をクリックします。
プロジェクトテンプレートをそのまま適用するのもアレなので、ちょっと変えてみようと思います。通常であれば、「ほげ」と発話すると「Echo: ほげ」と返ってくるのですが、以下のように修正して「あなたは、「ほげ」と言いました」となるようにします。
// Copyright (c) Microsoft Corporation. All rights reserved. // Licensed under the MIT License. // // Generated with Bot Builder V4 SDK Template for Visual Studio EchoBot v4.15.2 using Microsoft.Bot.Builder; using Microsoft.Bot.Schema; using System.Collections.Generic; using System.Threading; using System.Threading.Tasks; namespace EchoBot1.Bots { public class EchoBot : ActivityHandler { protected override async Task OnMessageActivityAsync(ITurnContext<IMessageActivity> turnContext, CancellationToken cancellationToken) { //var replyText = $"Echo: {turnContext.Activity.Text}"; var replyText = $"あなたは、「{turnContext.Activity.Text}」と言いました。"; await turnContext.SendActivityAsync(MessageFactory.Text(replyText, replyText), cancellationToken); } protected override async Task OnMembersAddedAsync(IList<ChannelAccount> membersAdded, ITurnContext<IConversationUpdateActivity> turnContext, CancellationToken cancellationToken) { var welcomeText = "Hello and welcome!"; foreach (var member in membersAdded) { if (member.Id != turnContext.Activity.Recipient.Id) { await turnContext.SendActivityAsync(MessageFactory.Text(welcomeText, welcomeText), cancellationToken); } } } } }
Bot Framework Emulatorでテスト
Bot Framework Emulatorというものを使うと、ローカルでチャットボットアプリケーションのテストが可能です。以下のURLからBot Framework Emulatorをダウンロードして下さい。
https://github.com/Microsoft/BotFramework-Emulator/releases/
MacやWindowsなど各環境に合わせたものをダウンロードしてインストールして下さい。ウィザードに従えば猿でもインストールできます。
Visual Studioで先程のEchoBotを起動します。
するとブラウザが起動します。Bot URL(以下ではhttps://localhost:3978/api/messagesですが環境によって変わるかもしれません)をメモします。
そして次にBot Framework Emulatorを起動します。「Open Bot」をクリックします。
「Bot URL」に先程メモしたBot URLを入力して、「Connect」をクリックします。
先程Visual Studioで開発したEchoBotがBot Framework Emulatorの中で起動します。「Type your message」と書いてあるテキストボックスの中にメッセージを入れてエンターすると、オウム返ししてくれます。素晴らC。
Visual StudioからApp Serviceへデプロイ
Visual StudioとBot Framework Emulatorによる開発・デバッグが終わったので、次にApp Serviceにデプロイして本番にリリースします。
Visual Studioにて、先程のプロジェクトを右クリックして「発行」をクリックします。
「Azure」を選択して、「次へ(N)」をクリックします。
「Azure App Service(Windows)」をクリックして、「次へ(N)」をクリックします。
サブスクリプションやリソースグループ等で絞って、デプロイ対象のApp Serviceを選択して、「完了(F)」をクリックします。
「発行(U)」をクリックします。
こんなふうに表示されれば成功です。
次にAzure Bot Serviceの構成を行います。こちらで作成した「Azureボット」にアクセスして、左部メニューの「構成」をクリックします。すると「メッセージングエンドポイント」というものが見えまして、これを入力する必要があります。
ちなみに、この「メッセージングエンドポイント」とは、こちらで作成したオウム返しボットが動作するApp ServiceのURLになります。これは以下の形式になります。
App ServiceのURL/api/messages
なので、App ServiceのURLがhttps://app-echobot-prd.azurewebsites.netだとしますと、メッセージングエンドポイントはhttps://app-echobot-prd.azurewebsites.net/api/messagesとなります。
次にApp Serviceの設定を行います。こちらで作成したApp ServiceにMicrosoftアプリIDとMicrosoftアプリパスワードを設定します。
MicrosoftアプリIDとMicrosoftアプリパスワードはこちらで説明したように、Botアプリケーションがチャネルに接続する際に必要になります。
appsettings.jsonに定義してもよいのですが、環境変数で定義するとそちらのほうが優先されますので、App Serviceの「構成」から設定したいと思います。環境変数で定義したほうが、ステージングや本番など環境ごとに簡単に設定を変えられますし、ソッチのほうが便利です。
今回App Serviceに定義しなければならないのは以下の情報です。
- MicrosoftアプリID
- Microsoftアプリパスワード
- アプリテナントID
まずMicrosoftアプリIDとアプリテナントIDを調べます。「Azure Bot Serviceのリソース作成」で作成したAzure Bot Serviceにアクセスして、左部メニューの「構成」をクリックします。すると画面右部に「Microsoft App ID」「アプリテナントID」が表示されますので、メモします。
MicrosoftアプリパスワードはKey Vaultに保存されます。Azure Bot Serviceがあるリソースグループと同じディレクトリにあるKey Vaultをクリックします。
左部メニューの「シークレット」をクリックします。
「現在のバージョン」をクリックします。
「シークレット値」をコピーします。これがMicrosoftアプリパスワードになります。
「App Serviceの作成」で作成したApp Serviceにアクセスして、左部メニューの「構成」をクリックします。
「+新しいアプリケーション設定」をクリックして、以下の値を追加します。
MicrosoftAppId | 先程メモしたMicrosoft App ID |
MicrosoftAppPassword |
先程メモしたシークレット値 |
MicrosoftAppTenantId | 先程メモしたアプリテナントID |
MicrosoftAppType | SingleTenant |
これで準備は整いました。Azure Bot Serviceのリソースにアクセスして、左部メニューの「Webチャットでテスト」をクリックして、試してみてください。入力した言葉を「あなたは〜と言いました。」とオウム返ししてくれると思います。これは、先程ソースコードを修正したアプリと同じ挙動ですね。
Webチャットを作ろう
チャットボットの一連の開発・構築手順は説明しました。
ただ、肝心のユーザークライアント層がありません。以下の図の「ユーザークライアント層」と書いてある部分で、WebブラウザやLINEなどのクライアントです。
本章ではWebブラウザによるチャットクライアント(以降、Webチャットと呼称)を作ってみます。
Azure Bot Serviceの認証でもお話しましたが、ユーザークライアント層とチャネルの間にはもちろん認証が必要になります。Webチャットとチャネルの間では、Direct Lineトークンというもので認証します。
ということでそのDirect Lineトークンを取得します。Azure Bot Serviceにアクセスして、左部メニューの「チャネル」をクリックします。画面右部に表示される「Web Chat」をクリックします。
「Default Site」をクリックします。
「秘密キー」をメモします。2つありますが、どちらでもOKです。
以下のHTMLファイルをWebサーバーに配置します。「YOUR_DIRECT_LINE_TOKEN」には、先程メモした「秘密キー」を書きます。
<!DOCTYPE html> <html> <body> <div id="webchat" role="main"></div> <script src="https://cdn.botframework.com/botframework-webchat/latest/webchat.js"></script> <script> window.WebChat.renderWebChat( { directLine: window.WebChat.createDirectLine({ token: 'YOUR_DIRECT_LINE_TOKEN' }), userID: 'YOUR_USER_ID' }, document.getElementById('webchat') ); </script> </body> </html>
先程のHTMLにアクセスすると、以下のようにWebブラウザにチャット画面が表示されて、オウム返しボットが起動します。
Azure Bot Serviceの料金
本章ではAzure Bot Serviceの料金について記載します。ちょっと少々複雑な料金体系になっております。
まず、Azure Bot Serviceの料金は、利用した「チャネル」と、そのチャネルを通じてやり取りされた「メッセージ数」によって課金されます。チャネルとは冒頭に紹介した以下の構成図の赤枠で示した部分になります。
チャネルには、PremuimチャネルとStandardチャネルがあります。先程のWebでのチャットは、Premiumチャネル内にあるWeb Chatに当たります。
課金対象となるメッセージ数は、ユーザーがボット に送ったメッセージの数と、ボット からユーザーに送られたメッセージ数の合算になります。
Azure Bot Serviceの料金プランは、F0とS1の2つがあります。F0、S1ともStandardチャネルを通じてやり取りされるメッセージは課金が発生せず無制限に利用できます。
ただし、両プランで決定的に異なるのはPremiumチャネルの扱いです。F0ではPremiumチャネルに対してやり取りされたメッセージが10,000/月を超えると、エラーになり利用できなくなります。
S1ではF0のようなことはないですが、1000メッセージあたり$0.50の料金が発生します。
つまり、月に10,000メッセージ以上やりとりするのであれば、S1を選ぶ必要があります。
F0 | F1 | |
Standardチャネル | メッセージ数無制限 | メッセージ数無制限 |
Premiumチャンネル | 10,000メッセージ/月 | 1,000メッセージあたり$0.50 |
まとめ
いかがでしょうか?Azure Bot Serviceを使うと、超簡単にチャットボットを作ることができます。スゴイですね、Azure Bot Service!!