対話型AIプロダクトの今と展望 〜ChatBot・VoiceBotの開発技術を解説〜

Transcript

1. 対話型AIプロダクトの
 今と展望
 〜ChatBot・VoiceBotの開発技術を解説〜
2. 青野健利
 github: @brn
 twitter: brn227
 
 - 開発責任者 at AI Shift
 - Contributor of V8(~ 2018)
 自己紹介
4. デジタルマーケティング分野のサービス開発を行う事業部。 全体の7割以上が技術職で構成され、広告取引の世界で培ったAI技術の適応領域を拡大中。 約350名を超える、エンジニア・研究者・データサイエンティスト・デザイナーが所属 DX AI D2C マーケ ティング AI クリエイ ティブ 対話AI 新事業 小売 医療 行政 GovTech 開発組織 DataScienceCenter データサイエンティストの横断組織 事業へのデータサイエンスの応用・実装 AI Lab AI技術の研究開発を行う専門組織 国際学会への論文投稿など学術貢献も活発 AI Tech studio ビジネスサイドと連携したプロダクト開発 接客 イベント
5. デジタルマーケティング全般に関わる、幅広いAI技術の研究開発を目的に設立。 ビジネス課題の解決と学術的貢献を目指す。 ・KDD 2022 機械学習における観測遅延問題の 改善方法を提案 ・CVPR2022 研究開発の基礎技術となる指標や 分析方法を提案（3本の主著論文採択） ・ICML2022 高次元情報を用いた逐次的な 意思決定手法を提案 ・国際カンファレンス 「IEEE RO-MAN」基調講演 ・「ACM MMAsia 2022」にAI Lab の山口光太が登壇 ・「SNL2022」にAI Lab研究員の 大谷まゆが登壇 ・「日本経済学会春季大会」に AI Labの蟻生・森脇・加藤・竹浪が 登壇 ・言語処理学会第29回年次大会 （NLP2023）にて過去最多となる 13件の発表を実施 国際トップカンファレンス での採択&発表 登壇実績 2022年 論文採択数 約 50本
6. AI Shiftについて
7. VISION 人らしい世の中を創る 『AI vs 人間』『AIが人の仕事を奪う』といったように AIと人間が対立構造として捉えられることが多くあります。 当社の考えは少し異なり、 AIは人間が使ってこそ、 はじめて価値が出ると考えております。 AIが得意なことはAIに任せることで、本来、人間がすべき 『クリエイティブ、マネジメント、ホスピタリティ』などの仕事に集中出来る、 そんな人らしい世の中が実現出来ると考えております。
8. MISSION AIを民主化する AIは人類最大の革命と言われています。 上手く活用することができれば人類の驚異的な進歩となるでしょう。 しかしながら、現在それを自在に扱える企業や人はまだ限られています。 AIを必要とする企業や人が、最適に、且つ簡単に AIを使える 『AIが民主化された社会』 を実現することが当社の使命です。
9. AI Shiftのミッション
10. チャットボット事業 ボイスボット事業 対話型AIによる チャット対応の自動化 対話型AIによる 電話対応の自動化 生成AI活用による 会話要約の自動化 LLM活用事業
11. AI Messenger Chatbot
12. AI Messenger Chatbot
13. AI Messenger Voicebot
14. AI Messenger Voicebot
15. AI Messenger Summary
16. 今後の展望 チャットボット事業 ボイスボット事業 LLMエンジンの追加 LLMによるシナリオ自 動生成 生成AIを活用した新規 事業 新規事業 ?

17. 技術スタック フロントエンド バックエンド データベース その他ツール
18. • Audioチーム • 接客対話チーム • 強化学習チーム • 完全自動対話研究センター • 東北大学　乾健太郎　教授 • 名古屋工業大学　李 晃伸教授 産学連携 AI（(ML/DS)チーム 研究体制
19. 【１】AIを活用したChatBot・VoiceBotのシステム概観 【２】マルチテナントBotを支えるインフラ構成について 【３】管理画面の複雑なUIのフロントエンド開発 Speaker：石井 俊輝 Speaker：須永 大生 Speaker：栗崎 一真
20. AIを活用したChatBot・VoiceBot のシステム概観
 株式会社 AIShift 
 Backend Engineer 石井俊輝

21. 自己紹介
 いしい としき
 石井 俊輝
 【主な業務】
 VoiceBot運用基盤/新規プロダクトの開発 
 2023年 CyberAgent 中途入社
 所属: 株式会社AIShift
 @sugar235711

22. Agenda
 1. リアルタイム応答Bot現行アーキテクチャ
 2. 現行VoiceBotの課題と対話エンジンの内製化
 3. 今後の開発展望

23. リアルタイム応答Bot
 現行アーキテクチャ

24. プロダクト概要
 自動応対可能なChatBot・VoiceBotを提供 
 • 個社ごとにシナリオ構築からBot運用まで一気通貫でサポート 

25. プロダクト概要
 自動応対可能なChatBot・VoiceBotを提供 
 • 個社ごとにシナリオ構築からBot運用まで一気通貫でサポート 

26. システムの特徴
 • マイクロサービス
 ◦ シナリオ構築/会話管理/Bot...etc 
 ◦ 双方向のリアルタイム通信
 
 
 • マルチテナントアプリケーション
 ◦ MySQLのデータベース分離によるセキュ リティ対応
 ◦ Nginxによるサブドメインの割り当て 

27. UI: ChatBot
 UI(管理画面+ウィジェット)/Backend Service 

28. アーキテクチャ: ChatBot

29. アーキテクチャ: ChatBot
 • ChatBotのメイン
 • 回答の生成と履歴の 管理

30. アーキテクチャ: ChatBot
 • リアルタイムチャット実現のために WebSocketは使用していない

31. アーキテクチャ: ChatBot
 • リアルタイムチャット実現のために WebSocketは使用していない
 ➔ FirestoreのSnapShotListenerでドキュ メントの変更を検知

32. アーキテクチャ: ChatBot
 • 会話履歴の表示
 • 有人チャットの開始

33. アーキテクチャ: ChatBot
 • サービス間のメッセージの やり取りはQueueを通す

34. アーキテクチャ: ChatBot
 • サービス間のメッセージの やり取りはQueueを通す
 ➔ メインプロセスに依存しな い非同期処理の実現
 ➔ エラー時の再送処理の保 証

35. UI: VoiceBot
 UI(管理画面)/Backend Service

36. アーキテクチャ: VoiceBot

37. アーキテクチャ: VoiceBot
 • DialogFlowを使用し対話エンジンを構築
 

38. アーキテクチャ: VoiceBot
 • DialogFlowを使用し対話エンジンを構築
 
 ➔ 顧客発話→STT→DialogFlow→TTS→VoiceApp→Twilio応答 
 
 ※DialogFlow: シナリオベースのBotを作成できるGCPのサービス 

39. 現行VoiceBotの課題と
 対話エンジンの内製化

40. 既存のVoiceBot構築の難しさ
 DialogFlowではシナリオのフローを表示するUIが存在しない 
 ➔ 手作業でフローを書き起こし、DialogFlow管理画面から入力する 
 
 
 
 DialogFlow管理画面
 フローの書き起こし

41. 既存のVoiceBot構築の難しさ
 DialogFlowではシナリオのフローを表示するUIが存在しない 
 ➔ 手作業でフローを書き起こし、DialogFlow管理画面から入力する 
 
 
 
 • リソースの多重管理(人為的ミス、工数増加)
 
 • バージョン管理が困難(シナリオを含めたアプリケーションのロールバック が難しい)
 
 • 自社独自のリソースとの連携が難しい(音声認識などのモデルがGoogle提 供のものに限られる)

42. シナリオ構築UI + 対話エンジン: DialogEngine
 DialogFlowの完全置き換えを目指し、UIと対話エンジン部分を内製化を行った 
 
 スクラッチで実装
 
 • シナリオ構築部分
 RDBによるグラフ管理
 
 • Botのワークフローの履 歴管理
 
 • 外部連携機能
 SMS/Mail/SIP転送...etc
 
 

43. アーキテクチャ: DialogEngine(Admin, Bot) 

44. アーキテクチャ: DialogEngine(Admin, Bot) 

45. アーキテクチャ: DialogEngine(Admin, Bot) 
 • シナリオ作成画面とAPIを新設
 

46. アーキテクチャ: DialogEngine(Admin, Bot) 
 • シナリオ作成画面とAPIを新設
 ➔ React Flow + RDBで軽量なシナリオ描画、か つ強整合なグラフ構造を実現

47. アーキテクチャ: DialogEngine(Admin, Bot) 
 • 適切な粒度にサービスを分割
 • 各サービス間をgRPCで繋ぎ異 なるチーム・言語での開発を可 能に

48. アーキテクチャ: DialogEngine(Admin, Bot) 
 • Botが動作するシナリオをRDBから取り出しRedis にキャッシュ

49. アーキテクチャ: DialogEngine(Admin, Bot) 
 • Botが動作するシナリオをRDBから取り出しRedis にキャッシュ
 • 以降ログをRedisに書き込み、アプリケーションの メモリ使用量を抑えつつ素早い応答を実現

50. アーキテクチャ: DialogEngine(Admin, Bot) 
 • DialogFlowで実現していた機 能をサービスに分割

51. アーキテクチャ: DialogEngine(Admin, Bot) 
 • DialogFlowで実現していた機 能をサービスに分割
 • 独自のエンジンを選択できる 拡張性を持たせる

52. 今後の開発展望

53. 
 1. 運用中VoiceBotのDialogEngineへ のシナリオ移行
 2. Chat/Voiceのシナリオ構築サービ スの共通化
 3. レガシーコードのリファクタリング
 
 今後の展望
 既存
 
 1. LLMを活用のための基盤開発
 2. 既存システムへのLLMを導入
 3. 新規サービスの実装
 
 新規

54. マルチテナントBotを支える
 インフラ構成について
 株式会社 AIShift 
 Backend Engineer 須永 大生

55. 自己紹介
 すなが だいき
 須永 大生
 【主な業務】
 Chatbot,Voicebot開発/新規プロダクトの開発 
 2022年 CyberAgent 新卒入社
 所属: 株式会社AIShift

56. 利用ツール

57. アーキテクチャパターン
 ・マイクロサービス
 採用した主な理由は2つあります。 
 
 ①開発の効率性
 各サービスは独立してデプロイできるため、全体のリリースサイクルを速めることができます。AI ShiftではAIチームと開発チームが別れていることや、AIチームの中でも担当しているアプリケーショ ンが別れているので非同期的に開発ができることがメリットです。 
 
 ②技術的な柔軟性
 AIチームでは開発にPythonを利用しており、開発チームではGoを利用しています。 
 このように別の技術を同じプロダクトで利用できるのもメリットです。 
 

58. ホスティング
 ・GCPを利用 FirestoreをChatbotで利用したかったので、GCPを選択しています。 （Firestoreを利用する理由は後ほどご紹介します） ・Kubernetes（GKE）を活用 Kubernetesを利用している主な理由は2016年当時に、Container管理ツールとして良い技術であると判 断したためです。 ・リソースはTerraform管理 Terraformでインフラを管理しています。 Terraformの実行環境としてTerraformCloudを利用していて、安全な実行環境と権限管理を実現していま す。
59. CI/CD
 ・GitHub Actions
 アプリケーション側の基本的なCI/CDはGitHub Actionsを通じて実現されています。 
 
 ・ArgoCD
 Gitリポジトリに格納されたマニフェストファイルに基づいてKubernetesリソースを同期させます。これ により、デプロイメントの速度と一貫性が向上します。 
 
 

60. DB（MySQL）
 ・フローの整合性
 Botが動くフローの整合性が重要なサービスなのでRDB管理となっています。 
 
 ・マルチテナント
 ChatbotもVoicebotもマルチテナントサービスなのでRDBはテナントごとにわかれています。 
 
 
 

61. DB（Memorystore、Redis）
 ・Botの会話内容の一時保存
 何が発話されたのか、といった情報を一時的に保存し、Botが参照するために利用しています。 
 例えば、Voicebot以外のところに一時的に電話をつなぐ処理（外線転送）があり、前の会話の状態を 保存しておいて、外線転送からBotに戻ってきたときに再度コンテキストを復帰させる役割などがあり ます。

62. DB（Cloud Firestore）
 ・会話ログとして利用
 Redisで一時保存した会話情報の永続書き込み先として利用しています。 
 
 ・セキュリティルール
 Botを利用するユーザー、オペレーター、Botの管理者などのデータ参照範囲をセキュリティルールを 利用して簡単に作成できます。

63. DB（Cloud Firestore）
 
 ・Botと有人の切り替えが楽
 ChatbotではBotが応対する場合と人が応対する場合があるのですが、書き込み先はFirestoreに一 元化しています。これにより、フロントエンド側はBot発話やオペレータ発話のいずれかによらず、 Firestoreを一貫して参照するだけでよいです。 
 
 また、Chatbotの場合、Firestoreへの書き込みと同時にSubscribeしているClientへ自動配信されるこ とも重要です。
 
 
 

64. Pub/Sub
 ・非同期的な会話書き込み
 ChatbotではPub/Subを利用して非同期的に会話を書き込んでいます。これにより、メッセージのロス トの防止やスケーラビリティを担保しています。 
 
 Voicebotでも一部Pub/Subを利用していますが、Chatbotとは違い、リアルタイム性が強いサービスな ので、下記の流れ以外の非同期的な部分で利用しています。 

65. プロトコル
 ・REST
 I/FはOpenAPIで定義しており、これを参照することで、フロントエンドとバックエンドの間で齟齬が生まれな いようにしています。
 ・gRPC
 開発チームが開発しているアプリケーションとAIチームが開発しているアプリケーションの間はgRPCで連 携しています。gRPCを利用している理由は高速な通信やStreaming形式のRPCも提供している点です。 protoファイルをAIチームと開発チームで参照しあっています。
 
 ・WebSocket VoicebotではtwilioというWebサービスとBotが接続しますが、この間はWebSocketで接続されておりスト リーミング通信ができます。
 

66. フロントエンド
 複雑な管理画面UIの開発

67. 自己紹介
 
 栗崎一真
 2023.5 AI-SHIFT 中途入社
 2023.5 AI-SHIFT 中途入社
 X: @KK_sep_TT
 主な業務
 chat bot, voicebot, 新規プロダクトのフロントエンド開発

68. Index
 • toB SaaS フロントエンド開発について 
 • 使用技術
 • どうやって複雑さに立ち向かうか 
 • 今後の展望

69. toB SaaS に求められる要件
 あまり重要ではないこと 
 重要なこと
 • SEO
 • 初期ロードの速度
 • 動作が軽いこと
 • 操作がわかりやすいこと
 SSRを使用しないSPAで構築 

70. ChatBot, VoiceBot 管理画面開発
 私たちの toB SaaS の特徴
 
 • 複雑な画面が多い
 • API 連携が多い
 • フロントにもロジックがある

71. 使用技術
 言語: Typescript
 UIフレームワーク: React
 状態管理: Redux
 認証: Firebase Auth

72. どうやって複雑さに立ち向かうか
 コンポーネント設計
 純粋な関数への分割 
 ライブラリの利用

73. コンポーネント設計 ~ Atomic Design からの脱却
 Atomic Design の問題点
 
 • コンポーネントの配置に悩む (特に Molecules or Organisms) 
 • Atoms 以外で再利用性の高いコンポーネントは少ない 
 • 実際に使用される場所から遠くに置かれて、どこから使用されているか分かりづらい 

74. コンポーネント設計 ~ Colocation
 依存関係が分かりやすくなった
 Atomic Design の Atoms 以外の大部分を使用するリソースと同じディレクトリに配置 
 
 Colocation: 関連するリソース同士を近くに置いておくという考え方 
 

75. コンポーネント設計 ~ 多段階バケツリレー
 バケツリレー自体は悪いことではない (依存関係が分かりやすくなる)　 
 
 バケツリレー自体は悪いことではない (依存関係が分かりやすくなる)　 
 
 – しかし複雑なUIではpropsを自身は使わないのに受け取るコンポーネントが現れることがある
 Bはpropsを自身で使用しないで子に流すだけ
 
 Bが親と子両方と密結合になってしまっている 
 

76. コンポーネント設計 ~ コンポジションパターン
 Bが不要なpropsを受け取らなくなった
 Bの責務(レイアウト)が明確に
 Bがコンポーネントをpropsで受け取るように変更
 【React】Context を使う前に #2 コンポジション (ReactNode 型の Props) を使え https://qiita.com/honey32/items/4d04e454550fb1ed922c 
 propsのバケツリレー対策でGlobal Stateを使うその前に... https://speakerdeck.com/taro28/propsnohaketuriredui-ce-teglobal-statewoshi-usonoqian-ni 
 より詳しくは以下を参照

77. コンポーネント設計 ~ 試行錯誤 
 コンポーネント設計で考えることは多い
 
 再レンダリング
 ディレクトリ構造
 ビューとロジックの分離 
 コンポーネント粒度
 コンポジション
 props設計
 ユースケースに合わせて最適なアーキテクチャを考えていく必要がある 
 state管理
 CSS

78. 純粋な関数への切り出し
 UIと関係ない複雑なロジックはReactから切り出して、純粋なTS関数とする 
 単体テストがやりやすい & 可読性の向上 

79. 複雑なロジックの例
 • Firestore の データの詳細検索
 ◦ Firestoreの検索はそこまで強くないのでTSで絞り込む必要がある。 
 
 • グラフのnodeの変換ロジックをフロントが持つ 
 ◦ フロントで node を繋げたりするので、nodeの型変換のロジックが必要 
 純粋関数を結構書く

80. ライブラリのちからを借りる ~ React Hook Form
 管理画面には複雑なFormが多くある 
 自前で実装するのは大変
 swap
 append
 remove
 React Hook Form の便利なAPI
 useFieldArray
 • append
 • remove
 • swap
 動的なフォームのサポート

81. ライブラリのちからを借りる ~ React flow
 フローチャートUIをサポート
 • Node, Edge のカスタマイズ性が高い
 • 高パフォーマンス
 • TSの型サポート

82. 今後の展望
 既存のリファクタ
 新規プロダクト開発
 コンポーネントの設計 
 Fetcher ライブラリの導入 
 Vite 移行
 etc...
 新機能の追加
 完全新規プロダクト開発