Bot Framework Composer を使うと Q&A Bot / FAQ Bot が簡単に作れます。多分ご存じの通り。
QnA Maker との連携方法は 3通りあって、それぞれ特徴があります。
今回は 3通りの連携方法の紹介とそれぞれのメリット・デメリットがあります。（ただし私見を含みます）
- Knowledgebase 管理 + QnA Intent Recognizedトリガー
- Connect to QnA Knowledgebase
- Send an HTTP request (詳しくは 次回)
手順が一番簡単なのがトリガー、一番柔軟性があるのが Send http request です。
順番に見ていきます。
■ Knowledgebase 管理 + QnA Intent Recognized トリガー
Composer で Q&A ボットを作る方法で一番簡単です。
メリットはなにしろ簡単に Q&A ボットを作れること。
ナレッジベースを Composer で管理するだけで、問い合わせのトリガーを生成してくれたり QnA Maker リソースに発行してくれたりします。
他に何もしなくても Q&A ボットが完成します。
Bot のロジックとナレッジベースとを一元管理できるのもメリットです。
このやり方が適するシナリオにはこんなものがあると思います。
ボットがユーザーの意図を誤解することがないか誤解しづらいシナリオです。
- 他の機能を持たない Q&A 単機能のボット
- 質問以外の入力（命令、コマンド）が少ない場合、質問と命令との差異が明確な場合
メリットの裏返しで、このやり方があまり適さないシナリオとしては以下が考えられます。
- ナレッジベースの更新頻度が高い場合
ナレッジベースの編集に Composer を気にしなくていいので、QnA Maker で編集するほうが楽だと思います。 - 質問とそれ以外のユーザー入力とで似ているものがある場合
簡単な方法なのですが、推論のしきい値チューニングは苦手です。
例えば「会議室を予約したい」という意図と「会議室予約の方法を教えて」という質問が共存する場合はボットがどちらの意図かを推論しづらくなり間違った処理を行う可能性が高くなります。
メリットを理解した上でこの方法を選択すれば、作り方はともかく簡単です。
[Configure] – [Development resouces] で QnA Maker のリソースを指定して、[Knowledge base] メニューでナレッジベースと管理するだけです。
ナレッジベースを登録すると “QnA Intent recognizer” トリガーのフローが自動的に追加されます。それだけで Q&A 機能が完成です。
非常に簡単に開発できますが、ひとつだけ注意が必要です。
Composer と QnA Maker ポータルの両方でナレッジベースの編集は可能ですが、Composer で編集するとビルドのタイミングで QnA Maker のナレッジベースが上書きされます。逆に QnA Maker ポータルで編集したものは明示的に Composer にインポートしない限り同期が取れません。
開発が簡単な分、運用時はプロジェクトごとのルールを決める必要がありそうです。
■ Connect an QnA Knowledgebase
Composer v1 の頃からあった QnA Maker 連携の方法です。
こちらはナレッジベースの管理は QnA Maker ポータルで行う必要がありますが、Composer に用意されている [Connect to QnA Knowledgebase] アクションをフローに追加するだけです。
このアクションは QnA Maker への REST 呼び出しをラップしたものです。アクションひとつ追加するだけで回答をユーザーに返すところまで行われます。
このやり方は、Q&A 以外の機能を持つシナリオで使いやすいと思います。
例えば総務ボットで、総務への質問と会議室予約、経費精算など複数の機能を持つボットです。
このような場合は、ユーザーの入力がコマンドなのか質問なのかを正しく推論できるかが大事です。
そこで、
- Language Understanding でユーザー入力が命令やコマンドなのかを推論する（Composer では “Intent trigger” で実装）
- Language Understanding でしきい値以下のスコアしか得られなかった場合は、ユーザー入力は質問であると考えて QnA Maker に問い合わせる
- （不要なこともありますが）QnA Maker からのスコアがしきい値以下であれば、ユーザーの意図が分からなかったものとして「ごめんなさい」メッセージを応答する
の流れでユーザー入力の意図を判断していきます。
このような柔軟な仕様にできるのがこのやり方です。
適さないシナリオというほどではありませんが、Q&A 単機能のボットはあえてこのやり方を選択する必要はないと思います。上で紹介した QnA Intent Recognizer のほうが楽です。
ただしナレッジベースの更新頻度が高い場合は別で、ここで紹介した Connect to QnA Knowledgebase アクションのほうが管理が楽になると思います。
ナレッジベースは QnA Maker ポータル で管理するので、まずはポータルの [SETTINGS] – [Deployment details] で Knowledge Id, Host, Authorization Endpointkey の値を取得します。
Composer の [Configure] – [Advanced Settings View (json)] で “qna” セクションにこれらの値をコピーします。
なお Composer でナレッジベースの管理をしないので、[Knowledge base] メニューのナレッジベースは削除しておきます。Composer のナレッジベースを削除したら Configure の “qna” セクションで “subscriptionKey” は不要なので空にします。
あとは “Unknowwn intent” トリガーに [Access external resouces] – [Connect to QnA Knowledgebase] アクションを追加します。
アクションを追加する場所はほとんどの場合は “Unknown intent” になると思います。つまり命令やコマンドなど Language Understanding では該当するインテントがないことが分かったところで（つまり “Unknown intent”）、ユーザー入力を質問として処理するということです。
Unknown intent 以外で質問を処理したいことがあるかもしれませんが、その場合は適切な個所にアクションを追加します。
■ Send an HTTP request
一番柔軟なやり方です。その代わり多少の開発が必要です。
アクションの追加やプロパティの設定だけですが、上の二つと比べれば作業量は多くなります。
複数個の回答を返すとか、回答の文章と一緒にスコアを返すとか、上の二つでやった “回答 1件を返すだけ” を超えた処理を実現できます。
例えば、複数個をカードで返すとか、設定値よりスコアが低い場合は「自信がないけど、これらが近そうです」メッセージを追加して応答するとかのシナリオが考えられます。
このやり方は回答の書式を変更するものなので、ユーザー入力の意図を類推するところは一つ上の Connect to QnA Knowledgebase と同じです。
Get Started の範囲よりは Composer に馴染んでいる必要があります。まずは一度 Composer で簡単なボットを作ってみた後でやってみるといいと思います。
また、応答の書式をカスタイマイズしたいとか複数個を返したいとかの場合に使うものなので、逆に単純に回答ひとつを返すだけでいい場合には、あえてこのやり方を選択する必要はありません。
Send an HTTP request での手順については、長くなりそうなので 回を改めて整理 します。
Composer は QnA Maker との連携について考慮されているので、今回紹介した 3種類の方法で Q&A ボットを開発できます。
それぞれ適するシナリオや開発のレベルの違いがあるので、適切なやり方を選択して Q&A ボットを実装してみてください。
技術との戯れ 
いつも読ませて頂いており勉強になります。
「Language Studio」と「Bot Framework Composer」連携方法が知りたいのですが情報ありますでしょうか。
スレッド違いかもしれませんがご回答頂ければ幸いです。
現状では Send an HTTP request で呼び出す必要があります。
公式には今のところLangStudio対応についてはアナウンスがありませんが、今後も難しいかもしれないです。
流れとしてはプロの開発者は Bot Service を使って、ビジュアル開発はPower Virtual Agentsを使うというすみ分けになりそうですね。