電話応対AIを作る方法
KyoungTae Doh氏（以下、KyoungTae）：みなさん、こんにちは。本日はお越しいただき、ありがとうございます。私はKyoungTae Dohと申します。AIエンジニアです。本日、このタイトルでお話しします。「DUET：電話応対AIを作る方法」です。
まずは、みなさんの中には「DUET」と「LINE AiCall」を混乱されている方がいらっしゃるかもしれません。ですので、こちらをまずは紹介したいと思います。「DUET」はプロジェクトの名前で、「LINE AiCall」はプロダクトの名前です。では、まず短い動画をご覧ください。
ナレーション：忙しいお店のためにAIサービスにできることは何でしょうか？ ご予約のお電話はお客様とお店が初めて出会うところでもあります。ただ、時々あまりにも忙しく心を込めた応対ができないこともあります。LINE BRAINはお店で働くみなさまのために考えました。忙しさの中での電話応対に対して、私たちはどうお役に立てるのか？
お客様1：すみません。来週予約したいんですけど。
店員：少々お待ちください。来週の予約ですね。確認させていただきます。
お客様1：コースのメニューとかもありますか？
店員：えっと、そうですね……。
ナレーション：お店での電話応対をお手伝いするAI電話応対「DUET」を紹介します。
DUET：お電話、ありがとうございます。bills Ginza Tomomiが承ります。
お客様2：あ、もしもし？ 予約したいんですけど。土曜日の14時から4名で席は空いていますか？
DUET：申し訳ありません。14時は満席です。15時でしたらご予約をお受けできますが、いかがでしょうか？
お客様2：あっ。じゃあ、それで大丈夫です。メニューなんですけど、何かおすすめはありますか？
DUET：はい。bills クラシックメニューのアボカドトーストや、季節の新メニューもございます。
お客様3：席は窓側でお願いできたりしますか？
DUET：はい。窓側のお席をご用意いたします。ほかには何かございますか？
お客様3：いいえ、大丈夫です。
DUET：それでは、今週の土曜日、午後15時から4名様でお待ちしております。土曜日は雨だそうです。お気をつけてお越しください。
お客様3：はい、ありがとうございます。
DUET：失礼いたします。
ナレーション：DUETはお客様からの予約を承り、お客様のニーズをうかがい、難しいメニューの問い合わせにも対応いたします。お客様からのお電話に対応し、ご予約とお問い合わせを承るAI電話応対「DUET」がお店で働くみなさまを応援します！
（映像終わり）
なぜプロジェクト「DUET」を始動したか
KyoungTae：いかがでしたでしょうか？ 私自身、周りから「本当にこんなことができるのか？」とよく聞かれました。そこでまずは、このプロジェクトをなぜ始めたかについてご紹介します。
プロジェクト開始当初によく聞かれたことがあります。「レストランに電話で予約をする人自体が最近そもそも減ってるんじゃないか？」という疑問です。どう思いますか？ 今はスマホもありますし、対話型の音声認識サービスのIVRもあります。たくさんのシステムがあります。
ですので、もう1つ質問をしたいと思います。レストランの予約にはどの手段が一番使われていると思いますか？
65パーセント対35パーセント。おそらくみなさんは35パーセントぐらいの人が電話で予約をすると思いませんか？ でも、それは違います。実際には65パーセントの人が電話で予約をしているのです。（※NAVERが韓国にて提供中の予約サービスにおける統計データ）
推測や仮説は現実とは必ずしも合致しません。だからこそ、ユーザーとの対話が必要です。新しい領域に踏み出すときには異なるアプローチが必要になります。データは非常に重要です。このように新しい領域に踏み出すときにはデータが重要なんです。そこがLINEとNAVERの強みでもあります。
開発を始める前に、私たちは最初にとにかく何度も電話をかけました。3つの重要な発見がありました。
1つ目、電話応対が得意ではない店員さんたちが多いことです。これが一番最初の発見でした。人間同士でも電話だと、うまく会話ができないこともあります。パートタイマーの方々やほかの人たちは、必ずしもトレーニングを受けているわけでもありません。
そこから得た結論があります。私たちは「空の果て」を目指しているわけではないです。まずは、そのコストを削減できるのではないかと思いました。
2つ目、スマートスピーカーとのコミュニケーションは、電話でのコミュニケーションとは違います。
例えばスマートスピーカーを使っていると想像してください。このときはCommand and Controlという仕組みが使われています。例えば曲を聞きたいとき、「ねぇClova、BTSの曲をかけて」と話しかけます。Clovaが応答して曲をかけてくれます。
でも、電話になるとどうでしょうか？ 違いますよね。これをBuild-upパターンと呼んでいます。
レストランに電話をかけるときには、まず「もしもし」と言いますよね。店員さんが「レストランAです。何か要件はありますか」と聞かれると思います。そうすると「予約をお願いします」「行き方を教えてください」と聞きますよね。そうするとレストランは答えてくれます。これをBuild-upと呼んでいて、スマートスピーカーとは異なります。
最後の発見です。電話での対応はチャットボットともまったく異なります。チャットボットは画面に表示されます。これが大きな違いです。会話内容全体が表示されます。でも、電話ですと、ユーザーはすべて会話の内容を覚えているわけではありません。その点が非常に異なります。チャットボットはマルチモーダル・インターフェースを使っていますが、電話は音声だけを頼りにしています。
そのため、ここで会話型のUXについて話したいと思います。そのあとに技術的な話をします。
自然な会話を実現するためにやったこと
では、私たちのUXチームデザイナーの動画をご覧ください。
（映像が流れる）
私たちは会話全体をスペースとして捉えています。このグラフはよくある通話パターンです。ご存じのとおり、最初は「もしもし」から始まって「ご用件をおうかがいします」の返答が続きます。これが開始（Opening）です。そのあと本題（Body）に入ります。話が終わったら「では、失礼します」といって電話を切ります。これが終了（Closing）です。
そのため会話は、Opening、Body、Closingの3つで成り立っています。OpeningからClosingまで「time space」と呼んでいます。
電話をしているときに呼びかけの言葉はありません。例えばスマートスピーカーを使っているときには「ねえ、Clova」と呼びかけますが、このwake wordはありません。でも、電話ではこういったwake wordを使わないので、すぐに会話が始まります。ただ会話がすぐに始まっていくんです。
エンドユーザーが最初に話しかけます。でも、スマートスピーカーではまずは指令を出して、そのあとに反応が返ってきますので、その点が異なります。ユーザーは会話を、まずは相手のできることを確認して始めます。例えば「赤ちゃん用のいすはありますか？」などをレストランにも聞きます。
最後の会話終了のシグナルもあります。これは非常におもしろい点です。このプロジェクトの中でもおもしろい点でした。みなさん、通話終了が起こることはわかりますよね？ 人間であれば、その通話終了がいつ起こるのかがわかります。
韓国では「ありがとうございます」と言ったら通話終了のシグナルとわかります。日本ではどうかわかりませんが、おそらく似たような感じだと思っています。
話し言葉の特徴も理解する必要があります。電話ではユーザーは自然でスムーズな会話を期待します。自然な会話を実現させるためには、時間の制約を理解する必要があります。
この図ですが、これはタイムラインです。Overlap、Balance、Silenceで成り立っています。
つまり、友達と会話をしていることを想像してみてください。話しているときに、一緒にお互いの声がかぶってしまうことがあると思います。それをOverlapと呼んでいます。BalanceはOverlapがないので話がかぶっていることがなく、お互いに交互に話している状況です。そして、沈黙も会話のときには起こると思います。こういった要素が非常に重要です。
このシステムにとっても重要な点でした。会話の中ではそれぞれの会話が重なることがあります。なので、システムもこれを自然に対応する必要があります。また、発言の長さのバランスを取ることも重要です。このような会話のシステムは発言の長さをしっかりとコントロールしなければなりません。
また、沈黙（Silence）も非常に重要です。スマートスピーカーでは問題ではありません。というのも、常に沈黙だからです。スマートスピーカーになにも話しかけていないときは常に沈黙です。でも、電話をしているときには、例えば友達と通話をしているとき、なにか沈黙があるとちょっと気まずいですよね。なにか怒ってしまったのではないかと不安になるかもしれません。なので、この要素も考慮に入れる必要がありました。
会話デザインフレームワークの基本単位4つ
では、さらに深堀りしていきましょう。会話デザインフレームワークです。4つの重要な基本単位があります。Turn、Sequence、Activity、Taskです。Turnは会話をしているときの単位で、Taskが一番大きい単位になります。
では、この15秒のスクリプトをご覧ください。これは予約Taskです。つまりTaskが予約を取るということです。この中には3つのActivityがあります。Opening、Scheduling、Confirmation。この3つのActivityがあります。
それぞれのActivityにSequenceがあります。Opening、Confirmationは1つのシークエンスではありますが、Schedulingは2つのSequenceがあります。そして8つのTurnがあります。ご覧いただけますでしょうか。
では、Sequenceとその詳細についてお話しします。Sequenceについてはご存じかと思います。これは非常に簡単な図になります。
AIエージェントに対して質問があれば、例えば「赤ちゃん用のいすはありますか？」と聞くでしょう。そして答えが返ってきます。
AiCallがみなさんの情報や期待に沿ったかたちで回答できれば、問題はありません。でも、実際にはそういった状況ばかりではないと思います。AIエージェントはたくさんの情報を与えてくるか、または情報が足りないこともあります。
ここでもし、たくさんの情報が与えられると、みなさんにはまた新しい疑問が浮かびます。どういうことだったんだろうかと。期待していたよりも情報が少ないと、新しい質問、疑問が出てくるでしょう。これをSequence Expansion、拡大と呼んでいます。
これがSequence Expansionの例です。Definition Requestの会話を読んでいただけるとわかると思います。「両親と一緒にうかがいますが、何かおすすめのメニューはありますか？」という質問をしたとします。そうするとレストランはTenderloin SteakとToowoomba Pastaと答えます。これは1つのSequenceです。
Tenderloin SteakとTenderloin Steakについて、みなさんご存じですか？ 私は知りません。なので、ユーザーは「Toowoomba Pastaは何ですか？」というふうに聞きますよね。これがDefinition Requestです。
そして、Partial Requestについて。例えば「行き方を教えてください」とレストランへ聞いたとします。そうすると「地下鉄の駅から2分ぐらいですよ」と返ってきます。この回答を受けても、例えば理解できない場合もあると思います。「どこからとおっしゃいましたか？」。そうすると部分的な質問の繰り返しが起こります。
Taskのサブセット「Activity」の詳細
では、次にActivityについて説明します。ActivityはTaskのサブセットで、Sequenceが中にあります。達成すべき明確なゴールがあります。例えば、Opening、Scheduling、予約の空き情報の確認であったり予約確認、そしてClosingなどです。これはモジュールのようなものです。
それぞれのTaskの中でカスタム化を行うことができます。それを図で表してみました。ActivityとTaskの図です。
レストランに電話をして、緑色の丸は訪れたActivityです。黒色の丸については、会話機能として想定していたActivityですが、実際には訪れなかったものです。そしてピンク色は複数回訪れたActivityです。
Activity 0は例えばOpeningだとします。そしてActivity 7は例えば確認やClosingだとすれば、想像できるんじゃないでしょうか。
このUXセッションの中で、これは非常なメッセージです。電話をする上でこの考えが非常に重要です。会話には失敗という概念はないのです。
スマートスピーカーでは失敗することはあります。「BTSの曲を流してください」と言ってそれが流れてこなかったら、それは失敗ですよね。でも、通話や会話になると、先ほども申し上げたように、会話を積み上げていくことが非常に難しいです。そのため、失敗はありません。なにかわからなければ、もう一度聞けばいいのです。この考えが非常に重要です。
