井上 研一 （追記）Dialogは非推奨となり、代替サービスであるConversationが登場しました。
いま、絶賛Watson研究中なのですが、Watsonの導入をやっている案件での打ち合わせで、「それならDialogというサービスもありますね」と口走ってしまったので、いま一度、調べ直してみることにしました。
DialogはWatsonで提供されているサービスの1つで、一連の会話を組み立てるものです。
この画面キャプチャは、IBMから提供されているDialog Toolを使って、独自の会話（ダイアログ）を学習させたものです。
ダイアログの学習は、XMLファイルを使って行います。プログラミング不要で便利といえば便利なのですが、なかなか複雑な構文のXMLなので、プログラミングした方が速くない？と思ったりしないこともない･･･。
BotKitとNLCでどうだ？
以前からこうした会話をするBotはWatsonを使って作っていて、その時はSlackの提供しているBotKitというフレームワークと、WatsonのNLCやR&Rを組み合わせて作りました。
会話の流れはプログラム内で制御して、ユーザの発言を解釈するところはNLCに任せるという組み立てです。さらに、質問に対する回答を行うBotだったので、回答の準備はR&Rでやりました。
Watsonを使ってBotを作るときの、一つの定石になる組み合わせだと思います。
Dialogを使うメリット
WatsonのDialogと、いわゆるバーチャルエージェントを作るためのツールを比較すると、Watsonは自然言語認識に優位性があるので、ユーザの発言の揺れに強いというメリットを挙げることができると思います。
しかし、Watsonを使うことは前提として、BotKitのようなBotフレームワークとDialogを比較してみると、結構微妙かなぁと思っています。
先に挙げたように、Dialogを使えば会話の流れをノンプログラミングで制御できますが、本当にノンプログラミングなら是なのかというと、必ずしもそうではない。ただ、Dialogではgrammarとかentitiesという構文を使って同じことを意味する言葉の言い替えにうまく対応できるというメリットはあります。でも、それもNLCを使えば良いのではないか？という代替策があります。おそらく、NLCの方が能力は高いと思うし。
ただ、DialogとBotフレームワークは対立軸というわけではないので、注意が必要です。たしかに、DialogとDialog Toolを使うと簡単にBotが作れますが、Dialogだけを見ると、何か発言する度にAPIリクエストが必要で、conversation_idという、会話内で最初にAPIリクエストを行ったときに自動発番されるIDを持ち回ることによって、擬似的にステートフルな状態を作り出しているに過ぎません。逆に言えば、Botフレームワークを使って作った会話Botの中で、Botからの発言が必要になった場合にDialogのAPIにリクエストすれば、発言内容が返ってくるわけです。
というわけで、Dialog。本当にDialogじゃないとダメというほどのメリットが見つかるかどうか、もう少し調査してみようと思います。