.NETラボでTizen .NET Developer Preview2リリースについてLTしてきました。
3月25日の.NETラボ勉強会でTizen .NET Developer Preview2リリースについてLTしてきました。
当日はBotFrameworkについてのセッションで登壇したのですが、Tizenについても語りたいので資料を作成しました。いつものネタ枠です。
内容について以下に補足します。
Tizen .NET Developer Preview2 リリース内容
- 2017/1/31 リリース
- Visual Studio Tools for TizenがVisual Studio 2017に対応
Preview1の時は2015にしか対応していなかったですが、Preview2で2017に対応しました。 また、Tizenの.NET対応についてMicrosoftからの反応もConnect();2016に引き続き観測できています。
Visual Studio 2017 launch eventではミゲルからTizenという言葉が出ていました。
日本マイクロソフトのVisual Studio 2017 Release Celebrationでもスライドで
「Visual Studio Tools for Tizen for Visual Studio」
という表記がありました。明らかにVisual Studioが被っているのをおかしいと思わなかったのかな...
Tizenの.NET対応やXamarin.Forms対応はMS主導ではないので、MS側からの情報発信はあまりないのかな、と思っていたのですが、発信してくれているようです。
- TVアプリケーションの開発に対応
Preview2からTVアプリケーションも.NETで開発できるようになりました。
- プロジェクトウィザードを実装
パッケージ名の入力や、Mobile,TVのProfileに対応するか否かを選択できるようになりました。
- 証明書マネージャ
Preview1ではダミーのものを入れることしかできませんでしたが、ちゃんとGUIから作成して管理できるようになりました。
- マニフェストエディタ
Preview1ではマニフェストファイルを直接編集していましたが、GUIから編集できるようになりました。
- エミュレータマネージャ
以前は単一のスマートフォンエミュレータのみだったのですが、画面サイズの指定ができるようになり、TVかモバイルかを選べるようになりました。
バッテリー状況やGPS情報などをGUIからコントロールできるようになりました。
- プラットフォーム固有のAPIを追加
- Media Recorder (capi-media-recorder)
- Push (libpush)
- Smart Card (capi-network-smartcard)
- NFC (capi-network-nfc)
- System Setting (capi-system-system-settings)
- Media Controller (capi-media-controller)
- Web URL Download (capi-web-url-download)
- Speech to Text (stt)
- Text to Speech (tts)
- Account Service (account-svc)
- Media Vision (capi-media-vision)
- Geofence Manager (capi-geofence-manager)
- OAuth2 (liboauth2)
- WiFi Direct (capi-network-wifi-direct)
Preview1リリース時は60%しか対応していないとしていましたが、だいぶ追加してきたようです。
Roadmap
これは若干悲しい発表でした。
たぶんTizen3.0では正式に.NET対応をリリースせず、Tizen4.0のリリースに合わせてくる内容だったからです。
Tizen4.0の一部として2017年9月にリリースするとありますが、Tizen4.0はPublicM2が2017年10月ということなので正式リリースは年末か年明けになるんじゃないでしょうか。
Tizen.NETを実機で動かせる日が待ち遠しいですね。
.NETラボでBot Frameworkについて登壇してきました。
3月25日の.NETラボ勉強会でBot Frameworkについて登壇してきました。
Bot Frameworkについてのノウハウが蓄積してきたので、.NETラボ主催者の木澤さんに登壇を申し出たところ、枠を確保してくださいました。
そんなわけでTwitterでつぶやいたところ、以下のようにテーマが重なっていることが判明。
@nakasho_dev まじすかっ♪私もBot xLUISでお願いされてたので...調整した方がいいかもですね♪内容特に決まってないんですがw
— BEACHSIDE (@BEACH_SIDE) 2017年3月11日
でも、俯瞰的な内容メインとLUISメインでそんなに重ならないかな、と思いつつ、より俯瞰的な資料にしようとして作成したものがこちらです。
内容について以下に補足します。
P.4 ~ P.6 チャットサービス
チャットを利用している人は年々増え、チャットボットプラットフォームも様々なものが増えています。
なぜ、チャットボットプラットフォームが増えているのでしょうか。
それにはチャットボットの可能性について色々な期待があるからです。
P.7 ~ P.10 チャットボットへの期待
チャットボットへの期待について以下の方々からの意見を載せています。
- 三菱総合研究所
- 野村総合研究所
- Facebook CEO マーク・ザッカーバーグ氏
- Microsoft CEO サティア・ナデラ氏
なぜ、IT業界だけでなくシンクタンクの情報を重視するかというとお客様や自社の営業に提案する際には有効だからです。
ITに詳しくない人へFacebookやMicrosoftのCEOの意見だけ見せても、売りたいものを魅力的に言っているんでしょ、と判断されてしまうことがあります。また、直接のお客様担当者はITの知識があり魅力的に思っても、その上長や役員クラスを担当者が説得できないこともあります。
そんなとき、国内のメジャーなシンクタンクの記事や総務省の情報通信白書は経験上有効です。古い体質の大きな会社ほどその傾向があります。
今回の資料にはありませんでしたが、以下のような記事も参考になります。
P.11 ~ P.12 Microsoftによる知的アシスタントといえば
笑いを取ろうと狙っていたのは事実ですが、イルカも立派な対話的インタフェースでした。
MicrosoftはこのころからAIに力をいれていたと考えさせられます。
セッションでは伝え忘れてしまいましたが、りんなはしっかりビジネス展開できていることも紹介したかったです。
また、Tayによる失敗の際にナデラ氏が語ったことは非常に前向きで共感できました。
- 「我々が対処した最初の方法は、実際にリスクを取った行為をチームが悔やまないように念押しすることだった」
- 「もし過ちを犯したら、必ず(過ちから)学ぶようにしなければならない」
P.13 AIの民主化
誰もが人工知能の恩恵を受ける世の中にあるとき、人間との橋渡しの一部はチャットボットが担うと私は考えています。
P.16 ~ P.19 BotFramework関連図
Bot Connectorの説明でワンソースでマルチチャネルの説明の際にXamarinの話を絡めたのは意図的です。だってJXUGだもの。
P.20 ~ P.32 Bot Builder
ワンソースでマルチチャネルと言っても、チャットサービスによっては対応できないものもあります。
それをかくにんするのにChannel Inspectorは重要です。
サンプルアプリはDialogやStateの使い方がすごく参考になります。
また、ここで紹介するのを忘れたのですが、なぜかDirectX関連のGitHubのところにもサンプルがあります。
P.33 ~ P.42 Developer Portal
Botの登録・管理について説明しました。
各チャットサービスとの連携方法についてDeveloper Portal上で丁寧に説明してくれているのはありがたいです。
チャネルについて説明ついでにDirectLineAPIについて説明しました。
LINEに公式対応して欲しいですね。
また、DirectLineAPIの紹介でXamarinのサンプルを絡めたのは意図的です。だってJXUGだもの。
P.43 ~ P.45 Bot Directory
そういや公式には検索機能があるって記述あるけど検索フォームなくなっていますよね。
P.46 Azure Bot Service
・・・
P.47 ~ P.51 サーバ構成例
全部Azure上で構築したほうがレスポンスは速くなります。
クラウドには社内ルール等で置けない情報資産を扱う場合はオンプレミスでの方法もあるが、インターネット上の通信が多くなるのでレスポンスが遅くなる懸念があります。
オンプレミスの注意点として.NET Coreに対応していないので原則WindowsServerとなります。
現在、コミュニティがPorting中だけれど待てない人はmonoでXSPを使いましょう。
自分でPortingしてContributeするのもありですね。
P.52 情報資産に関する注意点
Bot Directoryで公開することが前提であり、Bot Connectorは会話情報を匿名化してサービス改善の目的で使用するかもしれません。
でも、Skype for Business や Microsoft Teamsなど、守秘義務を扱いそうなサービスでもBot Frameworkの利用を促しているので、方針変更するのを期待しています。
P.53~P.56 関連情報
参考になるので見てください。
では、楽しいチャットボットライフを!
.NETラボでXamarin.Formsについて登壇してきました。
1月28日の.NETラボ勉強会でXamarin.Formsについて登壇してきました。
登壇するきっかけは11月の.NETラボ勉強会でMicrosoftMVPの西村誠さんが登壇された「Xamarin入門(技術というより心構え編)」というセッションで色々とコメントしたら、西村さんから「君がXamarinについてしゃべりなよ」と言われたので、登壇することとなりました。
Xamarinを始めたのが昨年の無償化後で、まだまだXamarinが使えているとは言えない状況の自分ですが、ハンズオンのメンターなどを何度か経験し、初心者向けのセッションであれば対応可能だと判断しました。
そんなわけでタイトルは「Xmarin.Formsから始めるクロスプラットフォーム開発」として、資料を作成しました。
構成は以下のようにしました。
- Xamarin
- Xamarin.Forms
- コードの共通化
- Xamarin.FormsでPlatform固有の機能を扱う手段
- Xamarinのデメリット
- Xamarin.Formsの学び方
- 書籍編
- ハンズオン編
- ツール・ライブラリ編
- Prism編
- Azure編
- DevOps編
- サンプルアプリ編
- コミュニティ編
- Xamarin関連情報
- Xamarin Advent Calendar 2016
40分も時間をいただいたので、なるべく詰め込もうとしたらスライド88枚にもなり詰め込みすぎ感が...
また、発表練習が足りず、だいぶパワポのメモに頼ったスピーチになってしまいました。参加者の方からは「スライドを見ながらナレーションを聞いているようで聞きやすかった」との意見ももらいましたが、メモを見ずにスピーチしたいものです。
今回の発表で自分にとって良い復習にも予習にもなりました。 今後もセッションの機会があれば積極的に対応したいと思います。
後日共有いただいたアンケート結果では、このセッション目当ての方もけっこういらっしゃって期待に応えられたか不安ではあるのですが、おおむね好意的な意見を頂けました。
もっと突っ込んだ内容が聞きたかったという意見の方は、なぜ隣の部屋でやっていたJXUGのイベントに行かなかったんだ、と小一時間問い詰めたい。
おまけ
真面目にしゃべったら知恵熱が出てしまったので、ネタをやらねばとLT枠でTizenについて発表してきました。
Tizenの.NET対応についての始まりとこれから
はじめに
本エントリーは、 Xamarin(その2) Advent Calendar 2016 の13日目です。
Tizen の.NET対応の発表について
記憶に新しい Connect(); 2016 では様々な発表がありました。
皆さんは何が一番のサプライズでしたでしょうか。
もちろん
Xamarin.Forms.Platform.Tizen
の発表ですよね。
そこで、本記事ではTizenの.NET対応についての始まりとこれからを探っていきたいと思います。
MonoTizen
Xamarin.Forms.Platform.Tizenが初めての.NET対応ではありません。 Tizenの.NET対応としてMonoTizenが世に出ています。
MonoTizenの誕生
2014年5月20日 Kitsilano Software がMonoTizenを発表しました。
MonoTizenkitsilanosoftware.wordpress.com
この会社は「C#と.NET開発の生産性をGNU / Linuxモバイルにもたらす」というコーポレートスローガンをを持っています。
Tizenの.NET対応を推進するのにふさわしそうなスローガンですよね。
MonoTizenのロゴは以下になります。可愛いですよね。
そして、2014年6月4日からGitHubにて開発がスタートしました。
Tizen向けアプリの開発者たちは完成を待ちわびたことでしょう。
MonoTizenの開発延期
なんということでしょう。
2014年8月13日にMonoTizenの開発が延期になりました。
誕生したばかりで、停止?とお思いでしょうが停止にあたって、 Kitsilano Software は明確な意思表示をしています。
MonoTizenの開発は当面延期されます。 私たちは将来復帰したいと考えていますが、Tizenプロジェクトがポジティブな方向に変わらない限り復帰できません。 ロードマップを持たず、パートナーとの有意義なコミュニケーションがないプラットフォーム上ではソフトウェアビジネスはできません。(意訳)
Tizenを推進するはずのサムスンの対応を見限っての発言かもしれません。
その時の気持ちはどのような気持ちだったのか想像に難くありません。
某D社のTizen版xxモードやTizen版専用アプリの開発や端末検証を担当していた某下請け会社も「有意義なコミュニケーションがない」には同意するのではないでしょうか。
そして開発は延期になりましたが、2014年10月20日に Kitsilano Software はTizen AssociationにJoinしました。
Tizen AssociationはTizenの産業的役割を主導するために組織された非営利コンソーシアムです。
MonoTizenの開発復帰に向けて、ビジネスの在り方を議論したかったのかもしれません。
Kitsilano Software joins the Tizen Associationkitsilanosoftware.wordpress.com
Tizen.NET
時は移り行き、2016年。Xamarin.Forms.Platform.Tizenが誕生します。
サムスンの.NET FoundationへのJoin
2016年6月27日 サムスンが.NET FoundationのTechnical Steering GroupにJoinします。
.NET Foundation - Samsung joins the .NET Foundation Technical Steering Group
この時、Tizenの.NET対応について想像された方もいらっしゃると思います。
Connect();2016でTizenが公式に.NETに対応したと発表
Congratulations Samsung!
Xamarin.Forms.Platform.Tizenの発表に全世界が歓喜したことでしょう。
しかし、この発表に最も驚いた人は Dimitar Dobrev さんではないでしょうか。
この方はみなさんもご存知の通り、MonoTizenのリード開発者の一人です。
.NETへの対応が発表されたTizenProjectの以下のBlogに彼はコメントしています。
BY Dimitar Dobrev, 17 NOV 2016 9:09 AM
Hello,
My name is Dimitar Dobrev. I developed the C# language bindings for MonoTizen by Kitsilano Software. That effort unfortunately got suspended for financial reasons but I believe my expertise can help you with your current work.
MonoTizen stepped on CppSharp (hosted at GitHub) of which I am one of the lead developers. It is an open source project which generates C# wrappers for C++ libraries. The process is fully automatic and only requires passing the headers and libraries as file paths. I believe Tizen can use it to automatically generate the C# layer instead of it being slowly and expensively coded by hand.
I think I can be of great help to you and Tizen .NET. I would really like to start a discussion about this possibility.
Best regards,
Dimitar Dobrev
MonoTizenの立役者だった一人であるのに何も知らされていなかった感がありありですが、彼の熱意が伝わってきますね。
ぜひとも彼には Tizenの.NET対応のリードを頑張っていただきたいです。
Tizenの.NET対応状況
Tizenのページを見ても発表以降更新はないです。以前の記事をみてください。
NuGetでのライブラリのバージョンは上がっているのだからWebページも更新してよ、とは思います。
でも、Tizenに興味津々で公式からの発表が待ちきれない人も大勢いますよね。
そんな人たちはソースを見ましょう!Tizenはオープンソースです。
Tizenの.NET関連のソース
TizenのソースはGitで管理されています。以下のサイトで確認できます。
.NET 対応に関するリポジトリは以下を確認しました。 ※他にもあるかもしれません。
csapi
TizenのネイティブをC#で呼び出すラッパーAPIを管理しています。
リポジトリを確認すると、対応していないはずのTelephonyなどが存在し、今後の拡張に期待が持てます。
また、プラットフォーム固有のAPIにはUI関連がないと思ったのですが、ElmSharpにより実現しているようです。そもそもプラットフォーム固有のAPIがなくて、どのようにXamarin.Formsを実現するんだ、って話になりますよね...
ElmSharpとはTizen NativeのUI FrameworkであるEFLをベースに開発したもののようです。
Xamarin.Forms.Platform.TizenのUIはこのElmSharpを使用して実現しています。
dotnet
ビルドツール等を管理しているようです。
xamarin-forms
皆さんの本命、Xamarin.Forms.Platform.Tizenについて管理しています。
ソースツリーを見ると何やら、まだNuGetからダウンロードしたものには存在しないクラスがあります。
おや?
なんと! Xamarin.Forms.Maps.Tizenが!
さっそくXamarin.Forms.Maps.Tizen.MapControl.csのソースを見てみます。
using TLabel = Xamarin.Forms.Platform.Tizen.Native.Label; namespace Xamarin.Forms.Maps.Tizen { public class MapControl : TLabel { public MapControl(ElmSharp.EvasObject parent) : base(parent) { Text = "Can not supported Maps"; TextColor = ElmSharp.Color.Red; } } }
"Can not supported Maps"...
期待した私が愚かだったのでしょうか。
しかし、リポジトリに登録しているからは実装しようという意気込みは感じます。
そしてオープンソースなので、自分でcsapiを増やして現在のネイティブにないものも対応することは可能だと思われます。
おわりに
いかがでしたでしょうか。
Tizenの.NET対応についての始まりとこれからを紹介しました。
過去に停滞していたTizenプロジェクトですが、Connect();2016から再始動した感じはありありと伝わってきました。
しかし、Tizenプロジェクトの本気度を確認するのはこれからです。
皆さんも早くTizenの開発をしたくなったのではないでしょうか。
Tizen 3.0の正式リリースが待ちきれません。
docomoの発話理解APIからLUISの扱い方を学ぶ
はじめに
この記事は「Microsoft Cognitive Services & Bot Framework - Qiita」の8日目になります。
概要
LUIS(Language Understanding Intelligent Service)は非常に優秀な自然言語解析ツールですが、日本語ではサンプルモデルが存在せず、どのようなIntentとそのパラメータ、および、Entityを扱えばよいか困っている人もいることでしょう。
そこで本記事、『docomo Developer support | NTTドコモ』で提供している発話理解APIを元に学んでいきます。
LUISの基本知識はある程度省略しますので、
本記事を読み進める前に以下の記事を読んでいただけると理解が深まります。
docomoの発話理解API
発話理解APIは発話文をテキストでインプットすると、文脈を解析し、その意図に沿った『コマンド名』及び『スロット名』に該当する値を返却するAPIです。
LUISですと『コマンド』がIntent、『スロット』がパラメータにあたります。
発話理解APIで取得できるコマンド
発話理解APIのリファレンスで紹介しているコマンド一覧は以下になります。
commandID | commandName | 説明 | スロット名 |
---|---|---|---|
BC00101 | 雑談 | あいさつなど雑談 | |
BK00101 | 知識検索 | Q&Aの検索 | |
BT00101 | 乗換案内 | 乗り換え案内を検索 | stationTo, stationFrom |
BT00201 | 地図 | 地図の表示 | searchArea, hereArround, facilityName |
BT00301 | 天気 | 天気の検索 | searchArea, hereArround, date |
BT00401 | グルメ検索 | 飲食店の検索 | gourmetGenre, searchArea, hereArround |
BT00501 | ブラウザ | ブラウザアプリの起動 | browser, website |
BT00601 | 観光案内 | 観光地の検索 | searchArea, hereArround, sightseeing |
BT00701 | カメラ | カメラアプリの起動 | |
BT00801 | ギャラリー | ギャラリーアプリの起動 | |
BT00901 | 通話 | 電話アプリの起動 | phoneTo |
BT01001 | メール | メールアプリの起動 | mailTo, mailBody |
BT01101 | メモ登録 | メモの生成 | memoBody |
BT01102 | メモ参照 | メモの参照 | memoBody |
BT01201 | アラーム | アラーム設定 | time |
BT01301 | スケジュール登録 | スケジュールの登録 | date, time, scheduleBody |
BT01302 | スケジュール参照 | スケジュールの参照 | date, time |
BT01501 | 端末設定 | 端末設定の起動 | setting |
BT01601 | SNS投稿 | SNSへの投稿 | snsSource, snsBody |
BT90101 | キャンセル | キャンセルコマンド | |
BM00101 | 地図・乗換 | 地図・乗換いずれかのタスク | searchArea |
BM00201 | 通話・メール | 通話・メールいずれかのタスク | phoneTo |
SE00101 | 判定不能 | 判定不能 | |
SE00201 | サーバエラー1 | サーバエラー | |
SE00202 | サーバエラー2 | サーバエラー | |
SE00301 | ライブラリエラー | ライブラリエラー |
余談ですが上記の表はdocomoの公式のHTMLからExcelにコピーし、以下のアドインを使ってExcelからMarkdown形式に変換しています。便利です。
発話理解APIで取得できるスロット
スロット一覧は以下になります。
スロット名 | 説明 | タイプ |
---|---|---|
browser | ブラウザ名を格納 | browser |
date | 日付,曜日,相対日付を格納 | date, datePnoun, dateWeek, dateRelative |
facilityName | 検索対象の施設名を格納 | gpoi |
gourmetGenre | グルメ検索ジャンルを格納 | food, drink |
hereArround | 現在地周辺を表す言葉を格納 | hereArround |
mailBody | メール件名を格納 | mailBody |
mailTo | メール宛先を格納 | fullName, lastFirstName, firstName, lastName, postName, otherAddress, upoi, gpoi |
memoBody | メモの本文を格納 | memoBody |
phoneTo | 電話宛先を格納 | phoneNumber, fullName, lastFirstName, firstName, lastName, postName, otherAddress, upoi, gpoi |
scheduleBody | スケジュール内容を格納 | scheduleBody |
searchArea | 検索対象の地名を格納 | address, upoi |
setting | 設定項目を格納 | setting |
sightseeing | 観光関連用語を格納 | sightseeing |
stationFrom | 乗車駅を格納 | stationFrom, hereFrom, station, here |
stationTo | 降車駅を格納 | stationTo, hereTo, station, here |
snsBody | SNSの本文を格納 | snsBody |
snsSource | SNSの投稿先を格納 | snsSource |
time | 時刻,または相対時間を格納 | time, timeRelative, timeHour |
website | Webのサイト名を格納 | website |
余談ですが上記の表は(ry
発話理解APIの実行例
docomo Developer support ではAPIを実行するコンソールが提供されています。
ユーザ登録をすると利用できます。
実行例を示します。
「品川で焼肉を食べたい」の結果
「品川で焼肉を食べたい」で実行した結果の一部が以下になります。
この場合、コマンド名として「グルメ検索」、ジャンルとして「焼肉」、対象エリアとして「品川」が抽出できました。
ちなみに「現在地周辺の焼肉屋は?」としたときはhereArroundに「現在地」が格納されました。
LUISへの応用
グルメ検索をLUISで同じようなことを実現しようとした場合、あらかじめ「groumetGenre」、「searchArea」、「hereArround」をパラメータとした、「searchGroumet」というIntentを作成することとなります。
Entityの作成
ここでEntityを作成する際は一工夫必要です。
「groumetGenre」はおそらくグルメのジャンルで他と被ることもなさそうです。なので、「groumetGenre」というEntityを作成してよいでしょう。
「searchArea」は検索目的でなくてもエリアという概念はあるので、「Area」というEntityを作成したうえで「searchArea」というchildrenを作るとよいでしょう。
こうすることで検索目的ではないAreaのchildren作成時にも学習効果が期待できます。
「hereArround」は現在地周辺ということなので、hereだとかhereArroundのままでよいと思います。
Intentの作成
先ほど作成したEntityを元に「searchGroumet」というIntentを作成します。
学習
作成したIntentを学習させます。
学習を繰り返して、このIntentの精度を高めます。
まとめ
いかがでしたでしょうか。
今回はAdventCalendarの空きが出ないために急いで作ったためグルメ検索のみの紹介でした。
docomoの発話理解APIには、よくあるポータル検索ではなくスマートフォンの機能を使用するためのコマンドをそろえているのが特徴的です。
もし、LUISを使ってスマートフォンのコンシェルジュ的なアプリを作成するときは、この発話理解APIのスマートフォン向けコマンドが参考になるかもしれません。
docomoの発話理解APIは無料で使えますが、自分が好きなように学習させる機能はありません。
発話理解のノウハウをdocomoから学んで自分好みの学習をLUISで実現してみてはいかがでしょうか。
ちなみにdocomo Developer SupportではAPIを活用したサービスを考案された方には事業化支援金の提供も含めた支援プログラムがあります。
docomoのAPIとMicrosoft Bot Frameworkを組み合わせたサービスでも支援してもらえるかもしれませんね。
以上です。
LUISとAzure Bot Serviceを利用してMicrosoft Teamsで在庫管理ボットを動作させる
はじめに
この記事は「Microsoft Cognitive Services & Bot Framework - Qiita」の6日目になります。
概要
自身の前記事のいい加減さに反省して、もう一件記事を書きます。
LUISとAzure Bot Serviceを利用してMicrosoft Teamsで在庫管理ボットを動作させる例を紹介します。
LUISの構築やAzure Bot Serviceの構築はある程度省略しますので、
本記事を読み進める前に以下の記事を読んでいただけると理解が深まります。
LUISの設定
Phrase Listの設定
在庫管理対象となるものをPhrase Listに登録します。
今回はProductという名前で以下のように登録しました。
Entityの設定
製品のEntityとしてProductを登録します。
実際にはもっと子要素を増やすべきですがサンプルなので割愛します。
Intentの登録
製品の在庫数を取得するためのIntentをGetZaikoとして作成しました。
Actionパラメータには先ほど作成したPhraseやEntityのProductを指定し、NameもProductとしています。
(※違う名前にしたほうがわかりやすかったです。)
LUISを学習させる。
GetZaikoとなる文章パターンを覚えさせます。
何パターンかSubmitし、Trainで学習させ、Publishします。
「レモンの残りは?」のQueryの結果は以下のようになりました。
Azure Bot Serviceの実装
LUIS向けのAzure Bot Serviceの初期構築が完了している想定で進めます。
LUIS向けで構築する際に作成されるBasicLuisDialog.csxの末尾に以下のメソッドを登録します。
記事の可視性のためにメソッド内に処理をすべてまとめています。
実際はDBやWebAPI等からデータを取得することとなります。
今回、Entityが一つである前提のため、result.Entities[0].Entity という取得方法を実施していますが、通常はtypeやscoreの値をみて判断すべきだと思います。
Azure Bot Serviceのチャットウィンドウで動作を確認します。
期待通り動作しました。
Microsoft Teamsへの登録
https://dev.botframework.com/ にアクセスしてログインします。
Azure Bot Serviceでは作成した時点でMyBotsに登録されているところが便利だと思います。
Add another channel から Microsoft Teamsの行のAddを選択します。
Microsoft Teamsとの連携を有効にし、「I'm done configuring Microsoft Teams」のボタンをクリックします。
ChannelsにMicrosoft Teamsが加わりました。
Test linkの「Add to Teams」をクリックするとTeamsのアプリケーションが起動し、chatbotとのチャット画面が開きます。
以上でTeamsとの連携まで完了しました。
まとめ
在庫管理っぽいことをするボットを作成してみました。
例えば製品販売店であれば、実際の在庫管理システムとリンクさせたボットを公開し、顧客の購買部のメンバーが参加するTeamsに登録いただくなんてことも考えられます。
ボットを活用して問い合わせに対する時間が削減できるとよいですよね。
余談
なぜ、今回の記事の連携先にMicrosoft Teamsを選んだかというと、個人でOffice365 Business Premiumを契約しているけど、契約人数が一人のため、Teamsのチャットがつまらなかったからです。
もうこれで1人じゃないよ! このボットは自分自身への最高の誕生日プレゼントです。
Microsoft Bot Framework と docomo Developer Support 雑談対話APIの連携
はじめに
この記事は「Microsoft Cognitive Services & Bot Framework - Qiita」の5日目になります。
概要
Bot Frameworkと連携できるのはCognitive Serviceのみではありません。
本記事ではdocomo Developer Supportで提供されるAPIを使用して、Botアプリケーションを作成することで、チャットボットの可能性を広げて行きたいと考えています。
と大層なことを言っている割に雑談対話APIとの連携のみとなってしまいました。
docomo Developer Supportとは
docomo Developer supportをご存知でしょうか
サイトには以下のように紹介されています。
docomo Developer supportは、ドコモやパートナー企業が持つ様々なアセットを「API」として汎用化して提供し、開発者へ展開することで、新たな事業の創出を推進する協創プラットフォームです。ドコモは、中期目標に向けた取り組みとして、世の中の様々なパートナーの皆さまとのコラボレーションにより新たな付加価値を創造する「協創」を進めていきます。
どのようなAPIがあるか
| docomo Developer support | NTTドコモ
対話AI向けとして以下を提供しています。
雑談対話APIとの連携
パラメータは以下のページで紹介しています。
発言したいテキストのみをパラメータに渡しても問題ありませんが、botに話しかけるユーザの属性を付与することで、雑談の内容が変わるようです。
リクエスト
Bot Frameworkを利用したアプリケーションから以下の形式でリクエストを投げるようにしました。
- リクエストURL
- メソッド : POST
- 文字コード : UTF-8
- リクエストヘッダ:Content-Type:application/json
- リクエストクエリパラメータ
- APIKEY(ユーザ登録後発行されるキーです)
- リクエストボディ(JSON形式)
{
"utt": "こんばんは",
"context": "100001",
"nickname": "なかしょ",
"nickname_y": "ナカショ",
"sex": "男",
"bloodtype": "A",
"birthdateY": "1978",
"birthdateM": "12",
"birthdateD": "6",
"age": "37",
"constellations": "射手座",
"place": "東京",
"mode": "dialog",
"t": "20"
}
utt(発言内容)はBotFrameworkを利用したactivity.Textから取得したものを当てはめています。
contextはレスポンスから取得した値を次の発言時に含めることで意味のある会話を継続できるようです。特にしりとり機能を使用時では必要となります。
今回はuttとcontext以外は固定値を使用しています。
modeは何も選択しなければ「dialog」が適用されて通常の会話になります。「srtr」を指定するとしりとりのモードになります。
tはキャラクタ選択で今回は「20:関西弁キャラ」を選択しています。
レスポンス
以下のようにレスポンスを受け取りました。
{
"utt":"こんありやけど",
"yomi":"こんありやけど",
"mode":"dialog",
"da":"0",
"context":"100001",
}
uttの値を返信テキストとして、ReplyToActivityAsyncに渡してBotから返信させるようにしています。
連携例
エミュレータのキャプチャを以下に示します。
簡単ですが以上です。
Microsoft Cognitive Servicesでは雑談対話の仕組みはなく、LUISで雑談できるまで学習させるのも大変です。
例えばLUISでintentのscoreが低いものばかりの時は的外れな回答をしてしまう可能性が高いです。そういう場合は条件に該当しないと判断して、この雑談対話APIで返信内容をゲットするのもありかなぁと思っています。
正直雑談対話が成り立っていない時も多々見受けられますが...