DEIM Forum 2019 I3-4

京都インバウンド観光におけるIoT2H 観光情報アプリケーションの構築
優†

藤本まなと†

永野 一馬†

中村鈴木

吉野幸一郎†優吾†

日高 真人†

大坪

敦†

中村

哲†

田中

翔平†

NguyenQuynh Mai†
安本 慶一†† 奈良先端科学技術大学院大学 〒 630–0192 奈良県生駒市高山町 8916-5
E-mail: ysuzuki@is.naist.jp
あらまし

我々は，外国人観光者を対象としたスマートフォンアプリケーションの開発を行った．このアプリケー

ションの特徴は，チャットボットやツイート配信機能など様々な情報提供方法が備えられていること，および観光地の混雑度情報を収集していることである．開発したアプリケーションが有効であることを確認するため，京都市内嵐山地区において実証実験を行った．被験者アンケートによる主観評価によりアプリケーションの評価を行い，有効性および有用性を確認した．
キーワード 観光，スマートフォンアプリケーション，推薦，混雑度，ソーシャルメディア，対話
我々はこのような情報収集および提示技術を， IoT-to-Human

1 はじめに外国人観光客の増加に伴い，インバウンド観光は重要な産業となりつつある．旅行者の興味嗜好が多様化していることから，
より多くの観光者を呼び込むためには，これまで旅行者が訪問しなかった観光地や体験型施設に対する整備や情報提供が必要である．さらに，時事刻々と変化する情報を発信することが必要である．センサやそこで本研究では，外国人観光客を対象とした観光情報提供プラットフォームおよびスマートフォンアプ
リケーションを構築する．外国人を被験者とした実証実験を行い，提案するシステムが有効であることを実証する．
現在，観光に関する情報を提供するアプリケーションは数多く存在する．ところが，提供されている情報は取得した情報そのままであり，一次情報が提示されていることが多い．つまり，それらの情報に対する解釈やその対応などは，アプリケーショ
ンから得られるわけではない．本研究では，一次情報を解釈し，利用者にとってより理解しやすい二次情報を生成して利用者に提示することにより，より有益な観光アプリケーションを構築できると考えた．
そこで我々は本システムを構築する際に，(1) 何の情報を提供するのかと (2) どのように提供するのかの二つの点に着目し(IoT2H) と呼んでいる．
まず，(1) については，混雑度をセンシングした結果得られた情報，ソーシャルメディア上の情報，および観光地に関する基本情報の三つを収集した．混雑度を収集する方法として，設
置型センサを用いた混雑度推定システムおよびスマートフォン
アプリを用いた参加型混雑度収集システムを使用した．

(2) については，数値データを言語化して表示する方法，および元データをそのまま表示する方法の二つを用いた．表示する方法としては，アプリケーションの画面に表示する方法，および PUSH 通知の二つを用いた．
本論文では，観光客に提供する情報の対象として，寺社仏閣
やレストランなどの地点 (POI; Point of Interest) を事前に設定する．
提案手法が有効であることを示すために，京都市内嵐山地区
において実証実験を行った．16 名の外国人被験者により実際にスマートフォンアプリケーションを利用し，最後にアンケートを行うことにより主観評価を行った．その結果，提案した観光情報アプリケーションが有用であることを確認した．

2 関連研究た．現在，Web やソーシャルメディアにより膨大なデータが観光を支援するためのアプリケーションは数多く構築されてインターネット上に生成されている．さらに，IoT (Internet ofいるが，研究として公開されている部分は推薦や混雑度推定なThings) の時代が到来し，全ての「もの」がインターネット上にどの要素技術であり，著者らはこれら一体となったアプリケー

接続され，センシングすることが可能となりつつある．これらションに関する論文を見つけることができなかった．そのため，の情報は数値データの羅列であったり不要な情報が含まれたり

現在一般に使われているサービスを紹介し，本研究との差異にすることから，元データそのままでは観光客にとって理解する

ついて述べる．

ことが困難な情報である．そこで，時事刻々と分析し，自動的に観光客に合わせて理解できるような形で提示する必要がある．

現在，よく用いられている観光情報アプリケーションは Tri-

情報源

分析

言語化
言語化

混雑度

言語化

モジュール

開始

出力
混雑度の

PUSH型
通知

推薦POIの

モジュール

ソーシャル
メディア

有用な情報
を選定

規約

ホーム
画面

アンケート

利用方法

提示

ビデオ

写真テキスト
情報提示

これらのサービスでは，観光地に関する基本情報や口コミ情報，
評価などを閲覧することができる．ところが，これら提示されている観光地は場所だけが考慮されていることが多く，利用者の嗜好や混雑度などが考慮されているわけではない．また，

Google Map などでは場所の混雑度が推定されているが，それらは数値として表示されているだけであり，必ずしも利用者にとって直感的に理解しやすい伝達方法とはなっていない．本研
究では混雑度を測定し，言語化して表示することによって，利用者にとって直感的に理解しやすい方法で混雑度などの数値情報を伝達している点が利点である．
また，大量のソーシャルメディアから必要なデータを収集する際に，キーワードにより収集されることが多かった．ところが，今回用いるツイートデータは京都の観光に関する情報と広範囲なデータとなることから，適切なキーワードを設定することが困難である．そこで本研究では，設定したトピックに関係するツイートを収集し，これらを学習データとしたモデルを機
械学習により構築し，未知のツイートを分類する方法を用いた．

ボット

POI詳細

選択

ツイート

画面

表示

リアルタイム
状況表示

ビュー
POI

リスト

写真

コメント
口コミ情報の表示

既知POIを選択

図 2 スマートフォンアプリケーションの動作

図 1 データの流れ

pAdvisor 1 や Google Trips 2 ，Yelp 3 ，Pinterest 4 などがある．

推薦結果から

近隣POIを選択

メディア情報

テキスト

チャット

通知

地図

事前

POI基本

情報提示
ソーシャル

写真

PUSH

POIの詳細を

POI情報提示
アプリ
ケーション
表示

詳細表示

チャットで質問

対話による

対話

情報

開始画面

概要表示

初回

POI推薦表示
観光地

以降

起動

PUSH通知

探索

2回目

ーション

混雑度表示

POI推薦

一覧表示

アプリケ

PUSH通知

モジュール

センシング

利用者情報

ユーザ
インタフェース

る機能である．図 1 では赤実線の矢印で示している．4. 1 節で述べる．

•

POI 推薦: 観光客の状況に応じてリアルタイムに POIの状況を提示する機能である．図 1 では緑実線の矢印で示している．4. 2 節で述べる．

•

チャットボットによる基本情報提示: チャットボットにより，POI に関する基本的な情報を利用者の興味に応じて提示する機能である．図 1 では青実線の矢印で示している．4. 3 節
に述べる．

•

ソーシャルメディア情報提示: Twitter で配信されている情報から京都を観光する上で有用となる情報を収集し，情報提示を行う機能である．図 1 では黒破線の矢印で示している．

4. 4 節で述べる．
•

写真，テキスト情報共有: POI に関する写真およびテキストを利用者がアップロードし，他の利用者が閲覧可能となる機能である．図 1 では赤破線の矢印で示している．本論文では説明を省略する．

3. 2 スマートフォンアプリケーション

この方法により，キーワードを明示的に設定しなくても適切な

スマートフォンアプリケーションは Apache Cordova を利ツイートを安価に収集することが可能となる．ただ，なるべく用して実装した．そのため，Android もしくは iOS が動作す

多くの学習データを構築するために，クラウドソーシングを併るスマートフォンの両方で同等の機能を実現している．

用した方法を用いた．

スマートフォンアプリケーションの動作を図 2 に示す．以下のような手順で，利用者はアプリケーションの操作を行う．以3 観光情報提供システム
本研究で構築するシステムにおけるデータの流れを，図 1 に示す．

下で主要な操作について説明する．
（ 1 ） アプリケーションを起動し，データ取得や個人情報の扱いなどに関する規約を提示し，同意を求める．
（ 2 ） 利用者の嗜好を抽出するために，事前アンケートを実

3. 1 アプリケーションの機能
図 1 の右側に示すように，本システムは，以下のような機能を実装している．

•

施する．4. 2 節で述べる．
（ 3 ） 観光開始ボタンをタップすることにより，観光を開始
する．観光開始ボタンをタップしてから，後で述べる観光終了

混雑度表示: リアルタイムに各 POI の混雑度を測定しボタンをタップするまで，スマートフォンで取得している位置

アプリケーション上に提示，および PUSH 通知により表示す情報などのセンサ情報を情報収集配信サーバへ自動的にアップロードする．

1：https://www.tripadvisor.jp
2：https://get.google.com/trips/
3：https://www.yelp.com
4：https://www.pinterest.jp（ 4 ） ホーム画面を表示する．ホーム画面では，利用者が事前に登録した POI の一覧，システムに推薦された POI の一覧，
利用者の現在地に近い観光地の一覧，および利用者の現在地に

情報

サーバ

チャット
ボット

Twitter

により POI に関する情報を提供する．4. 3 節において述べる．

言語化

観光地

処理サーバ

•

言語化に
必要な

行った上で情報配信サーバへ送信する．4. 4 節において述べる．

Streaming
API

ツイート

収集サーバ
設置型
センサ

混雑度

収集サーバ
人手による

情報収集

配信サーバ
推薦に

スマートフォン

アプリケーション

推薦

必要な

結果

情報

推薦

混雑度

サーバ

収集

Twitter Streaming API を用いてツイート情報を収集し，機械学習や人手によりフィルタを

メッセージ

情報

ツイート収集サーバ:•

混雑度収集サーバ: 設置型センサや人手により事前に設定した POI に対して混雑度を測定し，情報収集配信サーバへ送信する．4. 1 節において述べる．

•

言語化サーバ: 混雑度収集サーバで得られる混雑度は 3段階で示された混雑度の度合いである．この度合いを人間にとって理解しやすいテキストへ変換する．4. 2. 2 節において述

図 3 システム全体図

べる．

•

推薦サーバ: 利用者への事前質問から得られた嗜好，利近い機能施設の一覧を表示している．利用者は，POI の一つを用者の現在地，および POI の混雑度の情報から，その利用者が選択し，詳細を表示する．

興味を持つと考えられる POI を推薦する．4. 2 節において述•

地図ビューを用いて，地図上で現在地から近い POI を

選択する．

•

POI リストを用いて，POI 名の辞書順や現在地から近い

順に POI をリスト表示したものを選択する．

べる．
それぞれのサーバ間通信，およびスマートフォンと情報収集
配信サーバとの通信には WebAPI を用いている．データ形式
は JSON を用いている．

（ 5 ） POI の詳細についての表示を行う．POI の名前や写真，説明文，風景写真などを表示する．さらに詳細を知りたい

4 要素技術場合に，チャットボット表示，ツイート表示，および写真コメントのボタンをタップする．

•

チャットボット表示では，利用者が選択した POI に対してさらに詳細な情報を知るために，次の節で述べるチャット
ボット処理サーバとのチャットを行う．

•

ツイート表示では，利用者が選択した POI に関係する

カテゴリについて最新の情報を知るために，次の節で述べるツイート収集サーバが収集したソーシャルメディア情報を表示する．

•

写真コメントでは，POI に関係する写真をスマートフォンによる撮影し，コメントと共にアップロードする．これら
アップロードされた情報は POI 詳細表示において閲覧することができるため，他の利用者がその POI を訪問するかどうかを選択する補助となる．
（ 6 ） PUSH 通知によって，利用者が事前に選択した POIの一覧，および利用者に推薦された POI の一覧において混雑度が変化したときに，リアルタイムで言語化サーバにより生成された文章を利用者に通知する．その通知画面を利用者がタップすると，その通知に対応する POI 詳細画面を表示する．

3. 3 バックエンドサーバ

3. 1 節において述べた機能を実現するため，以下のような要素技術の開発を行う．

4. 1 混雑度表示
4. 1. 1 混雑度測定
リアルタイムに各 POI の混雑度を推定し，アプリケーショ
ン上に提示および PUSH 通知により表示するため，本研究では，2 つの混雑度推定システム（1. 設置型センサを用いた混雑度推定システム，2. スマートフォンアプリを用いた参加型混雑度収集システム）を開発した．

a ) 設置型センサを用いた混雑度推定システム
図 4 に示すように，設置型センサを用いた混雑度推定シス
テムは，混雑度を測定したい POI に設置型センサを設置して使用する [1]．設置型センサは Raspberry Pi を用いて実装しており，BLE 信号（アドバタイズメントパケット）を送受信するための BLE ドングルおよび推定した混雑度をサーバに送信するための Wi-Fi ドングルもしくは 4G/LTE ドングルが取り付けられている．具体的には，測定したい各 POI に 2 台（送信側と受信側のペア）の設置型センサを設置し，混雑度を推定する．送信側の設置型センサは，BLE 信号を受信側の設置本研究で構築するサーバ全体の構成を図 3 に示す．この図で型センサへ送信する．BLE 信号を受け取った受信側の設置型示すように，本研究における実装は以下六つのサーバおよびス

センサは，BLE 信号の受信信号強度（RSSI: Received Signal

マートフォンアプリケーションにより構成されている．

Strength Indication）を計算しながら，人の通過によって生じ情報収集配信サーバ: 以下で示すサーバから得られるる RSSI の外れ値を抽出していき，実験的に決められた 60 秒

データや，POI に関するテキストや写真などの観光に必要な基のタイムウインドウ毎にそれら RSSI の外れ値の個数を計算す

本的な情報を格納し，必要な情報をスマートフォンアプリケー

ることで，混雑度を 3 段階（少，中，多）で推定する．

•

ションへ伝達する．

•

チャットボット処理サーバ: 情報収集配信サーバを介して，スマートフォンアプリケーションの利用者に対して，対話b ) スマートフォンアプリを用いた参加型混雑度収集シス
テム
上記で述べた設置型センサを用いた混雑度推定システムは，

混雑度センサ
BLE
DeviceOUTPUT(Sentence) : Gioh-ji is very crowded; thus it is
not recommended to visit now.

BLE dongle
Wi-Fi dongle

INPUT(Dialog-act pattern) : congestion=”High”,
POI=”Gioh-ji（祇王寺）”, recommended=“No”

図 4 設置型混雑度センサ

図 6 言語化モジュール

POI名て，通知を作成する．この概要を図 6 に示す．条件付き言語
生成には，Semantically conditioned long short-term memory

POI一覧(SC-LSTM) ニューラルネットワーク [2] を用いた．SC-LSTM

POI
選択

混雑度サンプル
混雑度選択ボタンは通常の LSTM の拡張であり，直前の単語 xt を入力として次の単語 xt+1 （実際の予測値は yt ）を予測する一般的な LSTM

POI地図ビュー
送信ボタン

POI選択画面

混雑度選択・送信画面

図 5 混雑度をサーバに送信する機能を持つスマートフォンアプリ

言語モデルに対して，文に含まれるべきコンテンツ制約 dt を与えるものである．このコンテンツ制約ベクトル dt の初期値
は，各スロットの値が存在するかを one-hot のベクトルとして表現したもので，文生成の際に LSTM と平行して動作する

Recurrent Neural Network (RNN) に与えられる．RNN は文特に京都のような日本を代表とする観光地おいては設置場所がの生成が終了した段階でコンテンツ制約ベクトル d を 0 ベクト

限定される．そのため，観光地内の全ての POI を設置型センルにするという制約のみが与えられ，コンテンツ制約ベクトル

サによってカバーすることは難しい．我々はこの問題を解決す

上のどの値をどの単語を生成した段階で 0 に近づけるかについるため，スマートフォンアプリを用いた参加型混雑度収集シスては，言語モデルと同時に最適化される．

テムを新たに提案・実装した．図 5 に示すように，本システム

今回は，観光案内アプリケーションに適した言語化モジューは iOS 上で動作するスマートフォンアプリケーションとして実ルを学習するため，以下のようなコンテンツベクトルのデザイ装されている．具体的な混雑度の収集方法として，まずはじめンを行った．

に，混雑度収集のためのスマートフォンアプリケーションを立•

Name: POI の名前．Gioh-ji temple （祇王寺），Burari

ち上げると最初に表示される図 5 左側に示す POI 選択画面にArashiyama （ぶらり嵐山），Hankyu Arashiyama Station （阪おいて，混雑度を報告/更新したい POI を POI 一覧もしくは

急嵐山駅）など．

POI 地図ビューから選択する．報告/更新したい POI を選択した後，図 5 右側に示すような選択した POI の混雑度選択・送信画面に遷移する．選択した POI の現在の混雑状況ともっと•State Event: 当該 POI で開催されているイベントなど．今回のアプリケーションでは用いなかった．

•

Congestion Degree: POI の 混 雑 度 ．BLE 信 号 のも近い混雑度を画面中央に表示されている写真で示された混雑

RSSI の外れ値から混雑度を算出している．今回は混雑度を度サンプルを参考に，3 段階（少，中，多）の中から選択・送3 段階（少，中，多）としている．

信することで，混雑度を報告/更新できる．

4. 1. 2 混雑度の言語化
上記二つの混雑度推定システムから得られた混雑度の情報は，
アプリケーション表示に用いられるほか，PUSH 型通知によっ•

Recommended: 当該 POI がユーザに対して推薦されているかどうか．Yes/No の 2 値．

•

Popular: その POI が人気の場所かどうか．Yes/No の2 値．今回のアプリケーションでは用いなかった．

て，ユーザがアプリケーションを使っていない状態であってもこれらの値をランダムに埋めたコンテンツベクトルを作成

プロアクティブに送信される．本アプリケーションではユーザ

し，対応する文をクラウドソーシングによって収集した [3]．

が気になる POI をホールドする（お気に入りリストに登録す

クラウドワーカには「Name: Gioh-ji temple, Congestionる）ことができ，PUSH 型通知はこのホールドされた POI の

Degree: very high, Recommended: No」などの情報が与混雑度に関して行われる．具体的には，各アクティブユーザがえられ，この情報を元に「Gioh-ji temple is very crowdeded;

ホールドした POI の混雑度を 5 分に一度確認し，混雑度に変thus it is not recommended to visit now.」のような説明文を化があった場合に PUSH 型通知をユーザに送信する．

付与してもらう．最終的に，2,001 ペアのコンテンツ制約ベクト

実際に PUSH 通知を送る際，PUSH 通知の内容生成として

ルと文のペアを収集して学習に用いた．なお，State Event と言語化モジュール（IoT2H 言語化）を用いる．このモジュール

Popular については，学習データに含まれているが，今回のシではニューラルネットワークを用いた条件付き言語生成によっ

ステム入力としては用いられていない．また，Name，StateEvent については収集の際，当該単語が文に含まれていることを条件とした．

4. 2 POI 推薦
4. 2. 1 推薦候補 POI の決定
各ユーザ対して推薦候補の POI を決定するには，各ユーザの嗜好情報（好きな POI の特徴）を正確に取得することが非常に重要となる．本研究では，ユーザの嗜好情報を少ない労力か

言語解析

意図認識

対話モジュール• 質問応答• 概要提示つ高い精度で取得可能な一対比較法とコンジョイント分析を組合せた手法を提案・実装した．具体的には，以下の通りである．

（ 2 ） 取得したいユーザの嗜好（＝ POI の特徴）の種類数及Hi, I’ll talk about Gioh-ji temple.
Please ask me something you want toknow, like “When was it established?”or “What is famous for?”
What is famous for?
There are many maple trees on the
grounds of Gioh-ji temple, so you canenjoy beautiful autumn leaves during
autumn foliage season.

応答候補（ 1 ） 日本らしさ，自然度合い，混雑度などの特徴が異なる

POI を複数用意する．

翻
訳
A
P
I

対話履歴

You may like
推薦モジュール

び水準を直交表にあてはめ，該当する直交表に従い，合致する特性を持つ POI を l 個選択し，POI の組を m 個作成する．直Horin-ji temple Rokuo-in temple Hogon-in temple

交表とは，どの 2 列をとってもその水準の全ての組合わせが同

図 7 チャットボットによる情報提示

数回現れる配列のことで，この性質を実験計画法における因子と水準の割り付け表に適用することで試験回数を削減できる．
（ 3 ） ユーザには各組に対し，どちらの方がどの程度好きかを回答してもらう．これを一対比較法と呼び，被験者に刺激を複数の中から 2 つずつの組にして提示し，感覚的印象の大小や好嫌等について評定あるいは選択させることで，刺激の主観的価値を計量化する手法である．
（ 4 ） （3）で得た回答から l 個の POI に関する全体効用値を算出する．ここで得た全体効用値を用いて重回帰分析を行う
ことで，各 POI の特徴から部分効用値を算出する．これをコンジョイント分析と呼び，消費者や顧客の商品やサービスに対する選好順位データを用いて，商品やサービスなどの選択対象が持つ属性ごとの効用（部分効用）と，それらから同時に選択対象に対する全体効用を求める手法である．本研究では，8 つの観光スポットに対する 8 回の 1 対比較を実施した．
（ 5 ） 最後に，各 POI の持つ特性と（4）で得られたユーザの嗜好データから，ユーザの現在地や混雑度などの情報を考慮することで，推薦候補 POI をオンサイトかつリアルタイムで決定する．

4. 2. 2 言 語 化
各ユーザへの推薦が POI 推薦モジュールによって決定された後，推薦結果を共有データベースに書き込む．PUSH 型通知システムはこのデータベース上の結果を 10 分に一度参照し，前回の参照結果から変化があった場合に，ユーザへプロアクティ
ブに通知する．この通知文の生成には，4. 1 節で述べた IoT2H
言語化モジュールを用いた．

4. 3 チャットボットによる基本情報表示
チャットボットによる基本情報表示においては，図 7 に示すようなテキストチャットインタフェースでユーザが必要とする情報を提示する．本アプリケーションでは，我々が提案した対しく教えて」などのより一般的な情報要求に答えるモジュールである．質問応答および概要提示のどちらのモジュールを用い
るかについては，ユーザの発話意図を推定するロジスティク回
帰モデルによって決定する．質問応答については，あらかじめ
各 POI に用意された 20 文の説明文を回答候補として用いた．
ユーザ発話および各回答候補文の内容語（名詞，動詞，イ形容
詞，ナ形容詞）を分散表現 [5] に変換し，発話内・文内で平均を取ったもののコサイン距離により，応答に利用する候補文を選択した．この分散表現は，Wikipedia から構築した日本の地
名・名勝・寺社仏閣に関わるテキスト 2,088,988 文から学習を行った．概要提示については，あらかじめ各 POI に用意された 20 文の説明文を，順番に利用した．
ユ ー ザ 発 話 お よ び 各 回 答 候 補 文 は ，JUMAN7.0 5 お よ び

KNP4.1 6 を用いた．また，チャットボットで用いる十分な
言語リソースは日本語にのみ存在し，チャットボットそのもの
も日本語を対象に実装されているため，入出力に対して国立研
究開発法人情報通信研究機構（NICT）が開発したみんなの自動翻訳＠ TexTra 7 を利用し，英語対応を行った．
また，各 POI に含まれる回答候補文の内容語ベクトル全ての平均を取ったものを各 POI の代表ベクトルとし，過去のユーザ
発話に含まれる内容語ベクトル全ての平均を取ったものをユー
ザの興味ベクトルとした．各 POI のベクトルとユーザの興味
ベクトルのコサイン距離をユーザ発話があるごとに計算し，この距離が近いもの上位 3 件を，対話システムからユーザへのPOI 推薦として用いた（図 7 における “You May Like” 部分の表示）．

4. 4 ソーシャルメディア情報表示
本機能の目的は，京都の観光に役立つと考えられる最新の情話システム [4] における質問応答 (Question Answering) と概
要提示 (Storytelling) の機能を用いた．質問応答はユーザの具

5：http://nlp.ist.i.kyoto-u.ac.jp/index.php?JUMAN

体的な質問に答えるモジュールであるのに対し，概要提示は「詳6：http://nlp.ist.i.kyoto-u.ac.jp/index.php?KNP
7：https://mt-auto-minhon-mlt.ucri.jgn-x.jp/

報を Twitter から収集することである．Twitter では大量の情（ 2 ） 実験補助員を各 10 名募集した．実験補助員は，5 節報が流通しているが，京都観光に関係するツイートは極めて少で示した人手による混雑度測定の作業に従事した．嵐山地域をない．事前の実験では，無作為に選んだ 100, 000 件のツイート

五つのエリアに分割し，一つのエリアに対して 2 名の実験補助のうち，京都観光に関係するツイートが最大 1 件程度の割合で員を割り当てた．

含まれることがわかった．機械学習による分類では一般的に，（ 3 ） 今回提案する各手法の有効性について比較評価を行う

正例と負例の数が極端に異なる分類を行うことが難しいと考えため，被験者 14 名は表 1 の通り条件を分けて実験を行った．

られている．そこで，機械学習とクラウドソーシングを併用す

一つの条件に 2 グループの被験者を割り当てた．グループ G

ることにより，この問題に対応した．

は，午前に TripAdvisor を利用して観光を行い，午後は我々が一般に，あるトピックに関係するツイートを収集する際には構築したスマートフォンアプリケーションを利用する．グルー

キーワードを用いられる．たとえば今回の目的であれば「京都」プ H はグループ G と午前と午後に利用するアプリケーション

や「観光」などをキーワードとすることが考えられる．つまり，を逆にした．これは，順序によって生じる印象の差を考慮する

Twitter Streaming API によりリアルタイムに情報を取得し，ためである．

キーワードによる条件に適合したツイートだけを抽出する方法（ 4 ） 実験被験者は被験者 ID に応じて割り当て機能を有効である．ところが，必ずしも必要ツイートにこれらのキーワー化および無効化されたアプリケーションを用い，実験時間中にドが含まれるとは限らない．一方で，”and” や ”or” を含む複少なくとも 3 個の POI にチェックインし，チェックイン時に雑なキーワード指定を行うことは難しい．

アプリケーションから要求された機能を利用した．一つの POI

そこで本研究では文献 [6] で提案した，機械学習における分に滞在できる時間は最大で 1 時間とした．実験時間は朝 10 時

類器を用いて必要なツイートだけを抽出する方法を利用する．

から午後 3 時までの 5 時間である．この時間には，昼食や休憩

つまり，機械学習により抽出された情報を人手により再度有用なども含まれる．

であるかどうかを分類し，有用であると判定されたものをシス（ 5 ） 実験終了後にアンケートを行い，アプリ全体および各テムに登録した．

機能に関する評価を行った．

今回の実験では，数量が多いと思われる日本語により書かれなお，スマートフォンアプリケーションは 1 回目の実証実験

たツイートを対象とした．ツイートを英語に翻訳するため，国の後で改善を行い，2 回目の実証実験を行っている．そのため，

立研究開発法人情報通信研究機構 (NICT) が開発したみんなの基本的なスマートフォンアプリケーションの動作は 1 回目と 2

自動翻訳＠ TexTra 8 を利用した．

回目で同じであるが，細部で異なる．

5 評価実験

5. 2 実 験 環 境
評価実験は，京都府京都市の嵐山地区において行った．事前

本提案システムが実際に動作することを確かめるために，2回の実証実験を異なる日に行った．1 回目の実証実験では大学に 100 箇所程度の POI を設定し，それぞれの場所に関する写真や説明文を作成した．

院生を対象とし，主にシステムが適切に動作することを検証し設置型混雑度センサを阪急嵐山駅前，嵐山公園（中之島地

た．2 回目の実証実験では，より実際の利用者に近い外国人被区），およびぶらり嵐山（嵐山地区中心にある休憩・物販施設）

験者を募集し実験を行った．システム全体を評価することを目の三箇所に，それぞれ一つずつ設置した．また，人手による混的として，システム全体および個別の部分に対する主観評価を

雑度測定を行う実験補助員は，実験開始 10 分前から割り当て行った．

スポットに向かい，混雑度測定を行った．

5. 1 実 験 方 法

5. 3 実 験 結 果

2 回の実証実験を通して，以下の手順によって実験を行った．

実験 1 および実験 2 における被験者へのアンケート結果結果（ 1 ） 外国人の被験者を，それぞれ 14 グループずつ募集しを，表 2 および表 3 にそれぞれ示す．表における被験者へのア

た．それぞれ，外国人籍で英語ネイティブ，またはネイティブ

ンケートの項目は，それぞれ以下の通りである．

と同程度に英語が利用可能な大学院生および一般人である．1• （アプリ全体）How satisfied with this application over-

回目の実験では奈良先端科学技術大学院大学に在籍する大学院all?

生を被験者とした．1 グループは 1 名である．
，2 回目の実験で•

は嵐山地域に来たことが無い一般人を被験者とした．1 グルー（Chatbot）How satisfied are you with Chatbot func-tion over all?

プの人数は 1 名もしくは 2 名である．1 グループ 2 名のとき，• （SNS 情報）How satisfied are you with Tweet function?

グループ内で利用するスマートフォンアプリケーションは一つ•だけとした．すべての被験者に対して，本システムで利用してfication?

いる技術については伝えず，スマートフォンアプリケーションに実装された機能の説明だけを行った．

•（混雑度表示）How satisfied are you with Congestion

function?
•

8：https://mt-auto-minhon-mlt.ucri.jgn-x.jp/（PUSH 通知）How satisfied are you with Push noti-（推薦機能） How satisfied are you with YOU MAY

表1 実験条件
グループ 提案アプリケーション内の機能 比較アプリケーション

Chatbot SNS 写真

TripAdvisor

A

〇

〇

〇

〇

×

B

×

〇

〇

〇

×

C

〇

×

〇

〇

×

D

〇

〇

×

〇

×

E

〇

〇

〇

×

×

F

×

×

×

×

×

G

〇

〇

〇

〇

午前

H

〇

〇

〇

〇

午後

表 2 実験結果（実験 1）
対象

Push

回答数

た．この理由として，本研究では PUSH 通知を行うタイミン

Satisfied 以上

グについて考慮していない点が挙げられる．また，ユーザイン

5 4

3

2 1

の割合

アプリ全体

1 1

8

3 1

71.4%

Chatbot

0 3

2

3 0

62.5%

SNS 情報

0 0

3

2 2

43%

Push 通知

1 1

5

1 4

58%

た情報収集配信サーバの性能が十分ではなかったことによりス

混雑度表示

2 1 10 0 1

92.9%

マートフォンアプリケーションの動作速度が低下し，利用者の

推薦機能

1 6

1

4 1

61.5%

満足度が低下した点が課題である．

TripAdvisor と比較 0 1

0

2 0

33.3%

タフェースに改善の余地がある，コンテンツの内容が不十分である，不正確であるという意見もあり，その分アプリ全体の評価を下げた結果となったと考えられる．特に，本研究で構築しチャットボットについては，質疑応答に分散表現を用いることによって，発話の精度が向上していることが確認できた．そ

表 3 実験結果（実験 2）
対象の一方で，利用者はチャットボットに対してどのような質問を

回答数

Satisfied 以上

5 4 3 2 1

の割合

アプリ全体

1 2 5 6 0

57.1%

れるのが不明である問題が生じた．この問題を解決するため

Chatbot

0 3 3 3 066.7%に，質問例を利用者に提示したが，この方法がユーザの満足度

SNS 情報1 1 3 3 062.5%

向上に寄与したのかについてはさらに分析を行う必要がある．

Push 通知2 1 3 3 1

60.0%

また，対象 POI を増やした場合にどのように機能を拡張して

混雑度表示

5 3 3 2 0

84.6%

いくかは今後の課題である．

推薦機能

1 2 6 3 075.0%

Trip Advisor と比較 0 0 1 1 0

50.0%

投げかけたら良いかが分からない，どのような質問に答えてく

ツイート表示については，そもそも特定エリアの観光に関する最新の情報をソーシャルメディアから得ることが極めて困難であることが分かった．嵐山の特定の観光地に関するツイート

LIKE function?
•（TripAdvisor と比較）TripAdvisor app or this app,which application shows better sightseeing spots?
また，表の各スコアは，アンケート上では実際には以下のように表示したものである．

は，1 日の単位ではどの観光地に関してもほぼ存在しないため，
ある程度古い情報，幅広い情報を収集する必要があった．そのため，ツイートなどのソーシャルメディアに観光地の情報を積極的に投稿する仕組みなど，観光に有用なコンテンツをソー
シャルメディア上で流通させる仕掛けが必要である．

•

5: Very Satisfied

混雑度については，多くの被験者から有用であるという評価•

4: Rather Satisfiedを受けた．センサによる混雑度測定システムの多くは，利用者•

3: Satisfiedの個人情報を得ることにより測定を行うため，センサの設置に•

2: Not Satisfied

関してプライバシーに配慮するための仕組みが必要となる場合•

1: Not Satisfied at Allがあったり，測定される人はスマートフォンや携帯電話などの表 2 および表 3 からアプリ全体に関する評価において，Sat-

機器を所持していることを前提としている場合がある．本研究isfied 以上の割合は，実験 1 で 71.4%，実験 2 で 57.1%であり，で利用したシステムでは，測定される人の個人情報を取得しな

多くの被験者から本アプリが有用であると評価された．

いため，設置に関してプライバシーに配慮する必要が無く，ス

5. 4 考ムーズに設置を行うことができた．また，人手によるセンシン

察まず，スマートオフォンアプリケーション全体についての考察を行う．実験結果から，被験者からは全体的にシステムが有用であるという評価を得たと考えている．ところが，POI 推
薦や混雑度の PUSH 通知については，被験者の評価が分かれグにおいても，10 人から 15 人程度の少人数で嵐山地区の 100件近くの POI の混雑度を高い頻度で測定することが可能となることが明らかとなり，有用性を示すことができた．ところが，
本実験では被験者とは別に混雑度を測定する実験補助員を配置したため，実験補助員が存在しなければ人手によるセンシングがある．また，利用者の嗜好を適切に反映した POI が推薦されを行うことができない．そこで今後は，スマートフォンアプリ

ているかどうかなどについてもさらに分析を行う必要がある．

ケーション利用者による参加型センシングを行う仕組みを構築

本実証実験では，アプリケーション全体の評価を主に行った．

することにより，実験補助員が不要なシステムを構築する必要

これは，それぞれの要素技術はそれぞれ客観的な指標によってがある．

評価する必要があると考えたためである．一部の要素技術につPUSH 通知や混雑度の言語化については，多くの被験者から直感的に理解しやすいという意見を得ることができた．そのた

いては参照した論文においてすでに評価結果を示しているが，全ての要素技術について，客観的な評価を行う必要がある．

め，これらの言語化はスマートフォンアプリケーションの満足

本研究では，京都府京都市の嵐山地区を対象とした実証実験

度向上に寄与していると考えられる．一方で，いずれの実験にを行ったが，他の地域でも本システムを適用することができる

おいても「Not Satisfied at all」と回答したユーザが存在した．

かどうかを確かめる必要がある．要素技術については地域を限

これは，本研究では PUSH 通知のタイミングについては 5 分

定した部分は無く，コンテンツの準備および設置型センサの設

おきの定間隔としており，この間隔が適切でなかった可能性が置を行うことが可能であれば，本アプリケーションは他の地域ある．PUSH 通知では特に通知のタイミングが重要であるたに適用可能であると考えることができるが，実証実験を行うこめ，今後はこのタイミングを適切に設定する方法について検討とによって確かめる必要がある．

する必要がある．

最後に，本アプリケーションの今後の展望について述べる．

設置型センサの設置についての課題について述べる．嵐山地

本アプリケーションの目的は，適切な観光地を観光客に推薦す区において設置型センサの設置を行うにあたり，その土地を所るだけではなく，観光地の最適化による受け入れ観光客の向有する企業や官公庁と交渉を行った．ところが，本アプリケー

上を考えている．現在，京都などの有名な観光地では，有名なションが出力した結果によってどのような表示が行われるのPOI に多くの観光客が集まり混雑していることに対して，有名

か，どのような影響があるのかについてが不明である状況であではないが魅力があると考えられる POI にはほとんどの観光るため，設置を断られてしまう事例があった．今回の実証実験

客が来ない．そのため，観光地全体としては受け入れられる人によって出力および利用者への影響がある程度明確となったた数を大幅に超え，これ以上の観光客を集めることができない．

め，今後設置によるメリット等をより明確に説明できると考え観光アプリケーションにより観光客に有名ではないが魅力のあられる．

る POI を薦めることによって，より多くの観光地に多くの観また，設置型センサの形状や管理についても考慮する必要が

光客を集めることができるような行動変容を生み出すことがである．2 回目の実証実験において，設置型センサを見た一般のきれば，一つの観光地により多くの観光客を呼ぶことができ，観光客から，不審物と間違えられる問題があった．常時設置型

それぞれの観光客の満足度を向上させることができると考えてセンサを監視することによりこの問題に対応したが，形状を工いる．

夫することや，常時設置することが可能な体制を整えるなどの方法で，より適切な測定方法を考える必要がある．

謝

辞本研究の一部は，情報通信研究機構 (NICT) 委託研究の成果

6 おわりに
本研究では，観光情報提供システムの構築を行った．チャットボット，ソーシャルメディア情報，混雑度情報など様々な情である．評価実験を行う上で，京都府および阪急電鉄株式会社には多大なご協力をいただいた．また，本研究に関する実装の一部はスターマーク株式会社 9 によるものである．ここに記して謝意を表す．

報を統合し，観光客に対して情報を提示することによって，観光に対する満足度を高めることが可能なスマートフォンアプリ
ケーションを構築した．各要素技術を開発し，それらの入力および出力を統括する情報収集配信サーバを構築することによって，それぞれの要素技術を統合的に扱うことができるシステムを構築した．

2 回の実証実験により被験者による主観評価で提案手法を評価した結果，提案手法の有効性を示した．今回構築したすべての要素技術が少なくとも半分以上の被験者から高評価を得ることができた．さらに，アプリケーション全体についても高い評価を得られたことから，提案するアプリケーションの有効性を確認することができた．
今後の課題は，以下の通りである．本実験結果の分析は初期段階のものであり，実験条件の違いによる満足度の違いや，要文

献[1] Kazuhito Umeki, Yugo Nakamura, Manato Fujimoto, Yutaka Arakawa, and Keiichi Yasumoto. Real-time congestion
estimation in sightseeing spots with ble devices. In Proceedings of 2018 IEEE International Conference on Pervasive Computing and Communication Workshops (PerCom
Workshops), pp. 430–432, 03 2018.
[2] TH Wen, M Gašić, N Mrkšić, PH Su, D Vandyke, andS Young. Semantically conditioned lstm-based natural language generation for spoken dialogue systems. In Conference Proceedings-EMNLP 2015: Conference on Empirical
Methods in Natural Language Processing, pp. 1711–1721,
2015.
[3] 生田和也, 品川政太朗, 吉野幸一郎, 鈴木優, 中村哲. 観光案内におけるニューラル言語モデルを用いた説明文の生成. 人工知能学会全国大会論文集 2018 年度人工知能学会全国大会 (第 32 回)

素技術の組み合わせと満足度の差など，様々な分析を行う必要
9：https://starmark.co.jp/

論文集, pp. 2K103–2K103. 一般社団法人 人工知能学会, 2018.
[4] Koichiro Yoshino, Yu Suzuki, and Satoshi Nakamura. Information navigation system with discovering user interests.
In Proceedings of the 18th Annual SIGdial Meeting on Discourse and Dialogue, pp. 356–359, 2017.
[5] Tomas Mikolov, Ilya Sutskever, Kai Chen, Greg S Corrado,and Jeﬀ Dean. Distributed representations of words andphrases and their compositionality. In Advances in neural
information processing systems, pp. 3111–3119, 2013.
[6] Yu Suzuki. Twitter stream filtering using crowdsourcing
and machine learning. Journal of Information Processing,2019.