loading...

道案内しながら、しゃべる広告をつくってみた。

AIチャットボットから考える、コミュニケーションのこれから №2

  • 岸本 和也

2018/02/07

道案内しながら、しゃべる広告をつくってみた。

今や自動車に欠かせない、カーナビゲーションシステム(以下「カーナビ」)。近年ではスマホがそのままカーナビとして利用可能になるアプリも登場し、最新の地図情報が使える上に高機能ということで、徐々に普及しています。

こうしたスマホのカーナビアプリには、ドライバーが運転中でもハンズフリーで操作できるように、音声入力による受け応えが可能なものがあります。具体的には、目的地の指定や地図の表示切り替え機能が、声で指示を送るだけで操作できます。

入出力の方式がテキストか音声か異なるだけで、こうした音声対話機能も「チャットボット」の一種といえるでしょう。

前回のキャラクターチャットボットに続き、今回は音声対話を生かした新しい広告のプロトタイプ制作のプロセスを紹介します。

「しゃべる広告」をざっくり解説

今回はカーナビアプリ提供会社と共同でトライアルを実施しました。アプリを利用しているドライバーに対して、目的地へのルート沿いに提携店舗があった場合、外部データに応じたお買い得情報を音声広告として伝え、店舗への誘引を狙います(今回は、あるスーパーマーケットチェーンと提携)。

この音声広告の部分には、電通が現在開発中の対話型システムのプロトタイプを組み込んでいます。アプリは、音声で最寄りの店舗へのルート変更について尋ね、ドライバーに音声入力で「了承」してもらうことでナビを開始します。

外部データには日付、その日の気象・気温情報、時間帯、ドライバー自身の属性などのデータが含まれています。これらのデータを用いることで、例えば、前日よりもグッと冷え込んだ日はお鍋料理を提案して材料となる具材を訴求したり、平日の午後の主婦に対しては時短メニューを紹介したりすることが可能となります。聞き手のタイムリーなニーズに沿った、効果的な商品訴求が実現されるのです。 

サービス提供の流れは以下の図の通りです。

図1 カーナビアプリによる「しゃべる広告」の流れ
図1 カーナビアプリによる「しゃべる広告」の流れ

4段階の制作プロセス

こうした音声広告を、私たちは下記①~④のプロセスで制作しました。それぞれ裏話を交えてご紹介します。

図2 「しゃべる広告」制作のプロセス
図2  「しゃべる広告」制作のプロセス

①距離感の検討……「ラジオのような」距離感を目指す

最初に考えたのは、生活の文脈になじむ、ドライバーとの適切なコミュニケーションの距離感についてでした。 

タイミングに応じたお買い得情報であっても、その情報を伝える相手は運転中。運転を邪魔するような一方的な広告では、すぐにスルーされたり、サービスから離れられたりしてしまいます。 

「広告は、あらかじめ、その目的がバレ切っているマイナスのステージから発信する表現なのだ」というコピーライターの仲畑貴志さんの言を引くまでもなく、そもそも広告は嫌われがちです。それは技術が進歩しても同じで、いかに耳を傾けてもらえるコミュニケーションにするかが今回の課題でした。

そこで、私たちが考えたのは「ラジオのような」距離感。あまり主張し過ぎず、運転の邪魔にはならない。その上で、毎日少しずつ話題を提供しながら、商品を訴求する文脈の会話を行い、店頭への訪問につながればいい。こうした考えに沿って対話用のスクリプト文を考えました。

ちなみに「Twitterはラジオのやりとりに似ている(※)」と指摘されることが多いですが、筆者が過去Twitterの企業アカウントの運用やTwitterを用いたキャンペーンに携わった際に、タイムリーなネタを織り交ぜたコピーを書いた経験が、今回スクリプト文を考える上で役に立ちました。 

※いずれも「リアルタイムで情報を流しっぱなしのフロー型」「たまに双方向になる」などの特徴を持つため。

②技術的制約の把握……走行中の環境を考慮したサービス設計 

意外に思われるかもしれませんが、運転中の音声入力には技術的なハードルがあります。というのも、自動車内ではスマホとドライバーの距離が離れており、特に運転中は走行音やラジオの音声などノイズが混ざってしまいます。また、走行中は振動などによる影響も大きく、機械にとって必要な音声のみに絞って聞き取ることが難しいのです。

ドライバーからの発話が長くなれば長くなるほど、ノイズや振動の影響を受け、入力された情報を誤って受け取る可能性が高まるため、今回はドライバーには「はい/いいえ」の簡単な2択(言い回しの違いにも対応)で返答してもらう会話方式になりました。また、「うるさい」「やめて」などの発話があれば、広告を止める機能も用意しました。 

加えて大前提として、発話が原因となって事故を起こしてしまっては元も子もありません。そのため、右折・左折時などの特に注意を要する運転シーンでは発話しないように設定したり、話しかける際には「ちょっとよろしいでしょうか?」などの「クッション言葉」を入れたりといった配慮を事前の要件に含めました。

③スクリプト文の作成……距離感と制約のバランスを取る

こうした技術的制約の中で、先に述べた「ラジオのような」距離感で話題を提供し、「はい/いいえ」で会話を進めるというフォーマットでスクリプト文を書いていきます。
 
スクリプト文の考え方は以下の2通りで考えました。 

【A】日付のデータを元に「今日は〇〇の日」といった話題を提供する発話 

【B】気温やドライバーの属性などの外部データに基づいて話題を提供する発話 

例えば【A】の考え方での「2月3日」の例は以下の通りです。 

今日2月3日は節分です。 実は節分の日は太陽の動きによって決まるため、2025年には1日早い2月2日が節分になるそうです。 

さて、節分のご準備はいかがでしょうか。〇〇マートでは豆まきの豆や、恵方巻きなどをとりそろえております。 お近くの〇〇マート☓☓店に立ち寄ってみてはいかがでしょうか。

「はい」か「いいえ」でお答えください。 

「はい」の場合→

〇〇マート☓☓店を経由地に設定しました。音声案内を開始します。 「いいえ」の場合→

分かりました。お気を付けて運転してください。         

また、【B】の考え方での「前日より最低気温が下回った日」の例は以下の通りです。 

寒い日が続きますね。風邪の予防に、免疫力を落とさないよう注意したいもの。特にたんぱく質は免疫力を強化するなら欠かせません。

〇〇マートでは、サケやマグロ、ブリなど旬の魚を安心・安全に提供しております。刺身やお鍋がおすすめです。お近くの〇〇マート☓☓店に立ち寄ってみてはいかがでしょうか。

「はい」か「いいえ」でお答えください。(以下同じ)

④フィールドテスト……あらゆる要素を検証しPDCAサイクルを回す

スクリプト文を検討したのち、実際に路上でテストを行います。一般のドライバーがアプリを利用する環境と同じ状況下で、発話のタイミング、頻度、長さや読み上げのスピードなど、さまざまな要素を検証していきます。 

テストを行うと、想定していなかった発話タイミングの遅延や、頻度が多過ぎる(あるいは少な過ぎる)、テキストが長過ぎるなどの、事前に想定できなかった課題が浮き彫りになってきます。

そうした課題に対し、録画やログ解析を行うことでその都度原因を突き詰め、問題点を修正しました。そして、再び路上でテストを行い、PDCAサイクルを回すことで改善していきました。 

このようなプロセスを経て、実証実験を行いました。1月下旬から3月末にかけてアプリ利用者にトライアルへの参加を呼び掛けたところ、サービス利用の許諾が得られた約5000人に対して、期間中に3万回強の発話がなされました。スクリプトを聞いたドライバーは、そうでないドライバーに比べて約2.3倍対象チェーンの店舗に立ち寄るという結果になりました。

「しゃべる広告」のさらなる可能性

今回は初めてのトライアルということで、基礎的な仕組みづくりが中心となりましたが、例えば下記3方向のような展開案が考えられます。

1.外部データとの連携による精緻なレコメンド

今回はアプリに登録されたドライバーの属性データや、日付や気温データに基づいた発話=レコメンドでした。今後クライアント企業が持つ外部データなどをひも付けることができれば、より精緻なレコメンドが可能になります。

例えば、購買データとひも付けることで、前の日に買って余った野菜を活用できるようなレシピの提案や、トイレットペーパーが切れそうになったタイミングでの買い足し訴求などが考えられます。

2.複数クライアントでの実施に伴う、利便性の増大とプラットフォーム化

今回のトライアルでは一つのスーパーマーケットチェーン情報のみの提供でしたが、これが複数のクライアントになった場合、より多くのお得情報を提供することができ、ドライバーにとっての利便性が増大します。

便利になるにつれてユーザー数も増大し、クライアントにとっても魅力的なプラットフォームとなるでしょう。この場合、プラットフォーマーとして、各クライアントが合意できるような発話タイミングの調整や、発話が重複した際のルールづくりが必要です。

3.継続利用による各ユーザーへの最適化

今回はユーザーの利用内容のログを取得していたものの、短期間の実施だったこともあり、ほとんどレコメンドの内容に影響することはありませんでした。ここにも改善の余地があります。

例えば、毎日の発話にちゃんと受け応えしてくれるユーザーに対して、より親密な距離感でのスクリプトに切り替えたり、ユーザーが受け応えする可能性の高い曜日・時間帯に発話のタイミングを切り替えていくなどのやり方が考えられます。

今までの電通の強み+αが必要に

音声入力式チャットボットの一番の利点、それは「入力」の手間を削減することで、日常の生活の文脈に溶け込ませやすいことでしょう。

しかし、発話内容、タイミング、期待される答えとのズレなどの要素によって生活者に不快感を与えてしまい、逆に生活の文脈からつまみ出されてしまう可能性もあります。さらに広告の場合、ただでさえ嫌われやすいという側面があり、一層の注意が必要です。

カーナビアプリの例に限らず、今後一層の普及が予想される「Amazon Echo」「Google Home」「Apple HomePod」、そしてLINEの「Clova WAVE」などのスマートスピーカーにおいても、同様の考え方でのコミュニケーションの設計が必要だと考えられます。

ここには今まで電通が培ってきたコピーライティングやコミュニケーションデザインのノウハウが生かせるでしょう。

その上で、「体験のデザイン」など、今までの電通の業務とは一見離れた領域の知見をうまく組み合わせていくことが不可欠だと考えています。