今回は公式ドキュメントにある、会話をボットから人間に移行する について C# の サンプルの紹介をします。
サンプル
C# は公式のサンプルが無かったのですが、GitHub でいくつかシナリオを実現するサンプルがありました。その中でも今回は以下のものを試してみました。
GitHub: intermediator-bot-sample
動作の仕組み
BotBuilder v4.0 のミドルウェアの仕組みを使って、必要に応じて会話をチャネル間で転送する仕組みとなっています。ミドルウェアについては Bot Builder v4 でボット開発 : アダプター、TurnContext、Activity を参照してください。
図で表すと以下の様になっています。
通常フロー
- ユーザーがボットに話しかける
- ミドルウェアでは処理をバイパス
- ユーザーがメッセージを受けとる
ハンドオフフロー
- ユーザーがボットに話しかける
- ミドルウェアでハンドオフが必要と判断したら別のチャネルに転送 (ここでは Teams)
- Teams 側から担当が回答
- ミドルウェアがハンドオフ途中であることを判断して、元のチャネルに転送
- ユーザーがメッセージを受けとる
会話のステータスはすべて外部ストレージ (Azure Storage) に保存されます。
以下にいくつかサンプルアプリで重要な機能について紹介します。
接続トリガー
通常の処理とハンドオフの処理はトリガーが必要となり、公式ドキュメントでもいくつかシナリオが提示されていますが、このサンプルでは単純に "human" という文字列があればハンドオフとしています。
切断コマンド
担当がチャットをボットに戻したい場合は、disconnect コマンドを送ることで、ユーザーが通常のボットフローに戻ります。
ハンドオフ対象のチャネル
構成ファイル (appsettings.json) にある NoDirectConversationsWithChannels 設定に対して設定したチャネルは全て転送対象となります。
Watch/Unwatch
ハンドオフ対象のチャネルでも、常にハンドオフリクエストが来ないよう、コマンドでコントロールすることが出来るようになっています。
ボットアカウントを指定して watch を実行することでリクエストが来るようになります。
逆に unwatch を送信することでリクエストが来なくなります。
対応する担当の決定
構成された全てのチャネルに対して一斉通知が送られるため、だれが対応するか決める必要があります。このサンプルでは以下のようなカードを送って、初めに「Accept」を送った人が担当となります。
試してみよう
大体の流れが分かったので試してみましょう。
Azure リソースの準備
1. Azure ポータルより「Web App Bot」を追加。
2. C# の Echo Bot テンプレートで作成。
3. 任意の 2 チャネルを構成。ここでは Microsoft Teams と LINE チャネルを構成。
参考: Bot Builder v4 : Microsoft Team に接続する
参考: Bot Builder v4 : LINE に接続する
4. ストレージアカウントを追加。
5. 任意の名前を付けて作成。
6. アクセスキーから接続文字列を取得しておく。
サンプルアプリ
1. Git クローンでレポジトリをクローン。
git clone https://github.com/tompaana/intermediator-bot-sample
2. Visual Studio で IntermediatorBotSample.sln ソリューションを起動。
3. appsettings.json を開き、必要な情報を追加。
4. 発行より構築した App Service に発行。
動作の確認
1. Teams よりボットに対して @myhandoffbot watch を送信。Teams 側で待ち受け状態になったことを確認。
2. LINE より「human」を含む文章を送付。Teams 側にアシスト要求くることを確認。
3. Accept をクリック。その後 LINE からのメッセージが Teams に来ることを確認。
4. @myhandoffbot disconnect を送ってハンドオフが終了することを確認。
5. @myhandoffbot unwatch を実行してアシスト要求が来ないことを確認。
まとめ
今回のサンプルはミドルウェアを使った実装で、個人的にはとても気に入っています。他にも実装の方法はありますが、こちらも是非一度試してみてください。