Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

青野健利
 github: @brn
 twitter: brn227
 
 - 開発責任者 at AI Shift
 - Contributor of V8(~ 2018)
 自己紹介

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

デジタルマーケティング分野のサービス開発を行う事業部。 全体の7割以上が技術職で構成され、広告取引の世界で培ったAI技術の適応領域を拡大中。 約350名を超える、エンジニア・研究者・データサイエンティスト・デザイナーが所属 DX AI D2C マーケ ティング AI クリエイ ティブ 対話AI 新事業 小売 医療 行政 GovTech 開発組織 DataScienceCenter データサイエンティストの横断組織 事業へのデータサイエンスの応用・実装 AI Lab AI技術の研究開発を行う専門組織 国際学会への論文投稿など学術貢献も活発 AI Tech studio ビジネスサイドと連携したプロダクト開発 接客 イベント

Slide 5

Slide 5 text

デジタルマーケティング全般に関わる、幅広いAI技術の研究開発を目的に設立。 ビジネス課題の解決と学術的貢献を目指す。 ・KDD 2022 機械学習における観測遅延問題の 改善方法を提案 ・CVPR2022 研究開発の基礎技術となる指標や 分析方法を提案（3本の主著論文採択） ・ICML2022 高次元情報を用いた逐次的な 意思決定手法を提案 ・国際カンファレンス 「IEEE RO-MAN」基調講演 ・「ACM MMAsia 2022」にAI Lab の山口光太が登壇 ・「SNL2022」にAI Lab研究員の 大谷まゆが登壇 ・「日本経済学会春季大会」に AI Labの蟻生・森脇・加藤・竹浪が 登壇 ・言語処理学会第29回年次大会 （NLP2023）にて過去最多となる 13件の発表を実施 国際トップカンファレンス での採択&発表 登壇実績 2022年 論文採択数 約 50本

Slide 6

Slide 6 text

AI Shiftについて

Slide 7

Slide 7 text

VISION 人らしい世の中を創る 『AI vs 人間』『AIが人の仕事を奪う』といったように AIと人間が対立構造として捉えられることが多くあります。 当社の考えは少し異なり、 AIは人間が使ってこそ、 はじめて価値が出ると考えております。 AIが得意なことはAIに任せることで、本来、人間がすべき 『クリエイティブ、マネジメント、ホスピタリティ』などの仕事に集中出来る、 そんな人らしい世の中が実現出来ると考えております。

Slide 8

Slide 8 text

MISSION AIを民主化する AIは人類最大の革命と言われています。 上手く活用することができれば人類の驚異的な進歩となるでしょう。 しかしながら、現在それを自在に扱える企業や人はまだ限られています。 AIを必要とする企業や人が、最適に、且つ簡単に AIを使える 『AIが民主化された社会』 を実現することが当社の使命です。

Slide 9

Slide 9 text

AI Shiftのミッション

Slide 10

Slide 10 text

チャットボット事業 ボイスボット事業 対話型AIによる チャット対応の自動化 対話型AIによる 電話対応の自動化 生成AI活用による 会話要約の自動化 LLM活用事業

Slide 11

Slide 11 text

AI Messenger Chatbot

Slide 12

Slide 12 text

AI Messenger Chatbot

Slide 13

Slide 13 text

AI Messenger Voicebot

Slide 14

Slide 14 text

AI Messenger Voicebot

Slide 15

Slide 15 text

AI Messenger Summary

Slide 16

Slide 16 text

今後の展望 チャットボット事業 ボイスボット事業 LLMエンジンの追加 LLMによるシナリオ自 動生成 生成AIを活用した新規 事業 新規事業 ?


Slide 17

Slide 17 text

技術スタック フロントエンド バックエンド データベース その他ツール

Slide 18

Slide 18 text

● Audioチーム ● 接客対話チーム ● 強化学習チーム ● 完全自動対話研究センター ● 東北大学　乾健太郎　教授 ● 名古屋工業大学　李 晃伸教授 産学連携 AI（(ML/DS)チーム 研究体制

Slide 19

Slide 19 text

【１】AIを活用したChatBot・VoiceBotのシステム概観 【２】マルチテナントBotを支えるインフラ構成について 【３】管理画面の複雑なUIのフロントエンド開発 Speaker：石井 俊輝 Speaker：須永 大生 Speaker：栗崎 一真

Slide 20

Slide 20 text

AIを活用したChatBot・VoiceBot のシステム概観
 株式会社 AIShift 
 Backend Engineer 石井俊輝


Slide 21

Slide 21 text

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


Slide 22

Slide 22 text

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


Slide 23

Slide 23 text

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


Slide 24

Slide 24 text

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


Slide 25

Slide 25 text

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


Slide 26

Slide 26 text

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


Slide 27

Slide 27 text

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


Slide 28

Slide 28 text

アーキテクチャ: ChatBot


Slide 29

Slide 29 text

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


Slide 30

Slide 30 text

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


Slide 31

Slide 31 text

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


Slide 32

Slide 32 text

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


Slide 33

Slide 33 text

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


Slide 34

Slide 34 text

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


Slide 35

Slide 35 text

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


Slide 36

Slide 36 text

アーキテクチャ: VoiceBot


Slide 37

Slide 37 text

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


Slide 38

Slide 38 text

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


Slide 39

Slide 39 text

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


Slide 40

Slide 40 text

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


Slide 41

Slide 41 text

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


Slide 42

Slide 42 text

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


Slide 43

Slide 43 text

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


Slide 44

Slide 44 text

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


Slide 45

Slide 45 text

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


Slide 46

Slide 46 text

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


Slide 47

Slide 47 text

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


Slide 48

Slide 48 text

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


Slide 49

Slide 49 text

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


Slide 50

Slide 50 text

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


Slide 51

Slide 51 text

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


Slide 52

Slide 52 text

今後の開発展望


Slide 53

Slide 53 text


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


Slide 54

Slide 54 text

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


Slide 55

Slide 55 text

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


Slide 56

Slide 56 text

利用ツール


Slide 57

Slide 57 text

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


Slide 58

Slide 58 text

ホスティング
 ・GCPを利用 FirestoreをChatbotで利用したかったので、GCPを選択しています。 （Firestoreを利用する理由は後ほどご紹介します） ・Kubernetes（GKE）を活用 Kubernetesを利用している主な理由は2016年当時に、Container管理ツールとして良い技術であると判 断したためです。 ・リソースはTerraform管理 Terraformでインフラを管理しています。 Terraformの実行環境としてTerraformCloudを利用していて、安全な実行環境と権限管理を実現していま す。

Slide 59

Slide 59 text

CI/CD
 ・GitHub Actions
 アプリケーション側の基本的なCI/CDはGitHub Actionsを通じて実現されています。 
 
 ・ArgoCD
 Gitリポジトリに格納されたマニフェストファイルに基づいてKubernetesリソースを同期させます。これ により、デプロイメントの速度と一貫性が向上します。 
 
 


Slide 60

Slide 60 text

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


Slide 61

Slide 61 text

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


Slide 62

Slide 62 text

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


Slide 63

Slide 63 text

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


Slide 64

Slide 64 text

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


Slide 65

Slide 65 text

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


Slide 66

Slide 66 text

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


Slide 67

Slide 67 text

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


Slide 68

Slide 68 text

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


Slide 69

Slide 69 text

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


Slide 70

Slide 70 text

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


Slide 71

Slide 71 text

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


Slide 72

Slide 72 text

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


Slide 73

Slide 73 text

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


Slide 74

Slide 74 text

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


Slide 75

Slide 75 text

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


Slide 76

Slide 76 text

コンポーネント設計 ~ コンポジションパターン
 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 
 より詳しくは以下を参照


Slide 77

Slide 77 text

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


Slide 78

Slide 78 text

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


Slide 79

Slide 79 text

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


Slide 80

Slide 80 text

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


Slide 81

Slide 81 text

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


Slide 82

Slide 82 text

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