Voiceflow新機能発表イベント 『#VFV2』まとめ④ Designer/Developer Hand-off

Voiceflowの新機能発表イベント「VFV2」のまとめ、その４です。 今回はDesigner/Developer Hand-offについて。新機能（現時点でリリースされているものもあれば今後リリースされるものも含みます）についてはNew!をつけています。

Designer/Developer Hand-off

• プロトタイピングとデザインは多くの人にとってデザインと検証に最適だが、プロセスはそれだけでは終わらない。
• Voiceflowは、最高のデザインツールとしてだけでなく、デザインから開発にプロジェクトを最もかんたんに受け渡せるようにしたい。

• エンジニアチームは、Voiceflowが、すべてのチャンネルやユースケースで、信頼性と拡張性に最も優れたクリエイティブなツールとなるように取り組んできた。
• その結果、すべての会話コンポーネントをオープンソース化するという大規模なシフトを行った。
• これにより、企業やクリエイターがVoiceflow上で構築できるものの制限がなくなり、高いカスタマイズ性を提供できるようになった。
• Voiceflowのプロジェクトで新たに可能になったことを少しだけ紹介する。

• Voiceflowダイアログエンジン New!
  • Voiceflowで作成したフローは、シンプルなデザインで複雑な会話を表現していて美しい。
  • が、ブロックやフローそれ自体が本質的に何かをするわけではない。
  • 会話に命を吹き込むのがダイアログエンジン。
  • 既存のプロジェクト（Alexa スキル、Google アクション、プロトタイプ）もすべてこのエンジンを使っている。
• このエンジンにより、どんなインターフェースでもVoiceflowプロジェクトを実行することが可能

• 最終的な目標
  • Voiceflowの素晴らしいキャンバスシステム上でプロジェクトを設計・作成
  • ダイアログエンジンにより、プロダクション実行環境をユーザ自身で制御

• この1年間で、ダイアログエンジンをゼロから再構築し、あらゆるチャンネルに適応できるようにした。

• 高度にモジュール化されている
  • 自然言語処理（NLP）、ダイアログ管理、音声合成（TTS）などの会話コンポーネントを複数組み合わせることができる
  • 例えば、Rasaチャットボットを構築したり
  • Amazon Lex NLPをGoogle Wavenet TTSと組み合わせたり、といったことが可能

• 今まで通りVoiceflowのホスティングを使う場合もダイアログエンジンのメリットがある
  • ダイアログエンジンはテストツールで使用しておりパワフル
  • Google アシスタントやAlexa向けには、ダイアログエンジンを使うことで、プラットフォームネイティブな機能を利用することができるようになる
    • カスタムアナリティクスをフックしたり
    • アシスタントの動作を細かく制御したり
    • これまでできなかった細かいカスタマイズが可能となる

• Voiceflowは、デザインから開発への受け渡しの苦難を解決したいと考えている。
• ダイアログエンジンを使って構築する場合は、プロトタイピングと開発に最高のチーム体験を提供し、可能な限りスムーズな受け渡しができるようにしたい

• 同時に、開発者は使用するフレームワークに柔軟性と拡張性を求めており、開発者の生産性向上も重要
• 素晴らしい会話体験を作る各フェーズが最終的な製品に付加価値を与えると考えているため、同じことの繰り返しに費やす時間を避けたい

• Voiceflow SDK New!
  • デザイナーが作成したデザインを再利用可能
  • デザインをすぐにデプロイ、かつカスタマイズも可能となる
  • プロトタイピングと開発で重複した作業を排除

• ダイアログエンジンとSDKエコシステムのコア機能
  • 設定不要ですぐに使えるサービス
  • ユーザはウェブからアクセス可能
• SDKエコシステム
  • 任意のプログラミング言語で利用可能なライブラリとして提供
  • オープンソースとして提供、利用だけでなくコントリビュートも可能

• ライブアップデート
  • 一度デプロイすれば、ダイアログエンジンがデザイナーの継続的な更新に追従
  • 更新のたびに開発者が修正を行う必要はない
  • ユーザからもすぐに利用可能

• ステート管理
  • 開発者が会話体験を構築する際の最大の問題点
    • プロジェクト規模が大きくなるにしたがって、コードもさらに複雑化
    • 市場の多くのアプリはリニアかつ不自然なパスに依存してしまっている
    • 逆に会話は進化、より複雑でカスタマイズ可能な体験に対するニーズが高い
  • Voiceflow V2のステート管理
    • 完全に新しい方法
    • プロジェクトのフローは、エンジンによって自動的に翻訳、複雑な遷移をサポート

• 多言語対応
  • 19言語をサポート、さらに追加予定

• 自然言語処理（NLP）とダイアログ管理機能
  • ほとんどの会話アプリに共通の要件である、自然言語処理とダイアログ管理機能を搭載
    • これにより、ダイアログエンジンを必要最小限の設定ですぐに使える
    • ユーザーの発話に合わせたスマートで柔軟に会話体験を提供可能

• テキスト音声合成機能（TTS）
  • Amazon Polly、Google WaveNet、Azureといった最も人気のある音声から選択可能

• 自動音声認識（ASR）
  • Voiceflow上でホストされているかどうかに関係なく、音声の発話・聞き取りの両方の応答をSDKがサポート

• 独自のサービスやブロックを追加可能
  • Voiceflowのドラッグ＆ドロップなインターフェースは迅速な反復作業に最適だが、開発者はそれ以上のものを必要としている
  • 簡単で拡張可能でオープンソースのシステム

• プライバシー保護
  • Voiceflow上でダイアログエンジンをホストする場合にはユーザーセッションを保存しない。
  • プロジェクトはオープンソースで公開しているのでぜひチェックしてみてほしい。

• エクスポート可能
  • アプリの開発と実行をユーザ自身が用意したインフラストラクチャ上で行うことが可能
  • HIPAA、GDPR、CCPA、などのコンプライアンス規格に対応可能
  • 独自のNLP、ASR、TTSコンポーネントで拡張することが可能

• SDKを使ってみる
  • 銀行のためのシンプルなウェブサイトを例に紹介
  • チャットウインドウが用意されている
  • ただしまだチャットエンジンの実装はされていない。

• サンプルはシンプルなHTML/CSS/JSで構成
  • HTMLでダイアログエンジンSDKをインポート

• Chatクラスを使ってユーザーからの入力に対する応答を得るためののロジックはコントローラ内に存在

• Chatクラスは、2つのメソッドとアトリビュート
  • startInteractionメソッド
    • チャットウィンドウが最初に開かれた時に使用される
  • interactionメソッド
    • ユーザーが入力を送信するたびに使用される
  • stateアトリビュート
    • 会話の終了を教えてくれる
• 例では、startInteractionとinteractionにそれぞれプレースホルダが設定されていてそれを返すだけで何も実装されていない
  • "Welcome, how can I help you?"
  • "Sorry, I have not been implemented yet."

• インポートしたダイアログエンジンSDKを利用して実装していく

• 最初のステップ：ダイアログクライアントのインスタンス作成
  • 銀行チャットボットのVoiceflowプロジェクトを再利用するサンプル
    • 必要なオプションはバージョンIDのみ
    • ダイアログクライアントはデフォルトでは、すべてのSpeakブロックのトレースを公開する
    • チャットウィンドウのビジュアルを扱う場合にはVisualタイプもインクルードする
    • オーディオやチップのような他のタイプもこの配列にインクルード可能

• 対話の開始メソッドの実装
  • プレースホルダを実際の実装に置き換え
  • ダイアログエンジンを起動すると、会話の状態を含むContextと、ユーザに提示するのに必要な出力に関する一連のトレースを返してくれる

• Contextを処理する関数の作成
  • Contextが保持している値でstateを終了状態に設定
  • Contextからすべてのレスポンスを受け取り、Trace Processorに渡す

• Trace Processorの作成
  • SDKのヘルパービルダーを使用
  • 処理する必要がある各タイプ（この例では"speak" と "visual" ）に対して、トレースを引数として受けて、出力を返す関数を渡す

• interactメソッドの実装
  • 会話が終了した場合は start をもう一度呼び出す
  • それ以外の場合はsendTextを呼び出す。sendTextはContextを返すので、先ほどのprocessContextメソッドと同じように処理する。
• これで実装は終了

• 実際に動いているかを確認
  • Voiceflowのプロジェクトで作成した会話フローが使用されている
  • VisualとSpeakブロックが表示されている

• フローに従って対話

• 処理結果
  • ユーザの発話に応じた処理が行われ、その結果がVisualとSpeakブロックで定義したとおりに表示される
  • 最後にフローを終了
  • プロジェクトにダイアログエンジンSDKを実装することでチャットが完全に機能

• SDKのメリット
  • この例で使用したコードはすべてのユースケースに適用可能
    • カスタムなウェブサイト上のチャットボット
    • メッセンジャーボット
    • 開発者は、対話ロジックを開発する必要がなく、アプリケーションロジックに集中できる
  • Voicwflow上のプロジェクトが更新されれば、SDKを利用したアプリ上にも反映される
• ダイアログエンジンとSDKエコシステムへのアクセスについて
  • 開発者向けの技術的な機能を提供するが、同時ににシームレスなローコード体験のためのビジュアルレイヤーを提供することも計画している
  • 我々はゆっくりとクリックして簡単にアップロードできる統合機能をこれらの新しいチャンネルに追加していく予定
  • デモやドキュメント、さらなる詳細を含めた開発者向けSDKスターティングパックの申込についてメールで周知する予定。
  • Voiceflowをいろんなインタフェースで利用するためにSDKに興味があれば誰でも申込可能。

まとめ

Designer/Developer Hand-offというテーマで開発者向けの機能紹介でした。今回は特に技術的な内容だったので、ノンコーディングプラットフォームという観点からすると少し難しい内容だったかもしれません。

ただ、SDKがリリースされることで、巷でよく言われる「ノンコーディングはできることが限られている・限界がある」というようなことはもう言えなくなるほどの拡張性が得られる可能性がありますし、多数のユースケースに対応できるカスタムアシスタントはもちろん、これまで利用できなかったAlexaやGoogleなどの音声プラットフォームが提供する独自機能への対応というところも可能になるのではないかと思います。非常に可能性が感じられるアップデートですね！

もともとノンコーディングは、開発（コーディング）に対する敷居を下げることで誰でも参入しやすいという特徴があります。それが往々にしてコーディング VS ノンコーディングという対立構造にされがちなのですが、そうではなく、それぞれの得意分野に沿って最適な形で提供することでお互いのメリットを活かすことができますし、その間の連携がうまく取れればお互いにハッピーですよね。柔軟かつスピーディーなテストツールによるプロトタイピングと、拡張性に優れたSDKの組み合わせは、非常に期待が持てる良いアップデートになるのではないかと思います。

ちなみにSDKのベータテストへの申込は以下より行えます。興味のある方はぜひ！

https://airtable.com/shrQWZwypDQTOrt0I

次回は最後にNo Code Capabilities to Allについてまとめます。