道案内アプリ使用時における歩きスマホ防止方法の提案

(1)

修士論文

道案内アプリ使用時における歩きスマホ防止方法の提案

早稲田大学基幹理工学研究科情報理工学専攻

鈴木拓也

学籍番号 5113B051-9

提出 2015 ^年 2 ^月 2 ^日

(2)

A Study on Preventing Texting While Walking: A Case Study on a

Guidance Application

Takuya Suzuki

Thesis submitted in partial fulfillment of the requirements for the degree of

Master in Computer Science and Engineering

Student ID 5113B051-9

Submission Date February 2, 2015

Supervisor Professor Tatsuo Nakajima

Department of Computer Science and Engineering

(3)

概要

近年の情報処理技術の発展により，外出中に得ることのできる情報量が増えた．情報が得やすくなったがために，移動中にその情報を得ようとして歩きながらスマートフォンを操作する，「歩きスマホ」が問題となっている．特に，ユーザーに目的地までの経路を示す道案内アプリの使用時には，画面から目を離せない要素が多く「歩きスマホ」状態になりやすい．

本研究ではまず道案内アプリ使用時を再現したシミュレーションゲームを作成し，画面を見るタイミングを調査した．この調査を元に，通常であれば画面を見るタイミングで目を周りに向けさせるための方法を提案し，シミュレーションゲームで実現，評価実験を行った．

さらに，その方法論を現実世界で実現するための手法を提案する．

本研究の目的は，評価実験によって道案内アプリの使用時の問題点を明らかにし，さらに提案手法をゲームに取り入れて，その手法の優位性と問題点を調べることである．また，

提案手法の現実世界において実現させるための方法と将来課題について述べる．

(4)

Abstract

Thanks to the progress of information and communication technology, we can get more data while being out. So it gets being a problem to use smartphones while walking in order to get information or watch movies. Especially, on using guidance application, we tend to be in the situations.

In this study, I propose a way of preventing texting while walking and make a simulation game of guidance application with this proposal to research the performance. And I consider how to realize the proposal in real world.

The objective of this study is to disclose the superiority and problems of the proposal by doing a simulation game and study the point that I should consider when realizing the proposal in real world.

(5)

図目次

2.1 「歩きスマホ」防止広告 . . . . 4

2.2 年別の救急搬送人員 . . . . 4

2.3 ^{場所別の救急搬送人員} . . . . 5

2.4 「歩きスマホ」時の用途内訳. . . . 6

2.5 道案内アプリ . . . . 7

2.6 音声案内使用イメージ . . . . 8

2.7 YUBI NAVI . . . . 9

2.8 YUBI NAVI^使用時 . . . . 9

3.1 ^{進路送信イメージ} . . . . 12

3.2 曲がり角直前イメージ . . . . 13

3.3 曲がり角進入中イメージ . . . . 14

3.4 補助ライト使用イメージ . . . . 15

4.1 ^{システム構成図} . . . . 16

4.2 ^{基本マップ外観} . . . . 17

4.3 センサー設置後基本マップ . . . . 18

4.4 アプリケーション画面用マップ外観 . . . . 19

4.5 ^{プレイヤー外観} . . . . 20

4.6 ^{プレイヤーの周囲} . . . . 21

4.7 歩行者を登場させたゲーム画面 . . . . 22

4.8 ライトが緑色に光る時 . . . . 23

4.9 ライトが緑色に，補助ライトが黄色に光る時の条件 . . . . 24

4.10 ^{ライトが黄色に光る時} . . . . 25

4.11 ライトが黄色に光る時の条件. . . . 26

4.12 ライトが赤色に光る時 . . . . 27

4.13 ライトが赤色に光る時の条件. . . . 28

4.14 ゲーム中にR1ボタンを押した時 . . . . 29

(8)

表目次

2.1 シミュレーション結果 . . . . 3

4.1 基本マップ構成要素 . . . . 17

4.2 アプリケーション画面用マップ構成要素 . . . . 18

4.3 ^構成要素 . . . . 19

4.4 コントローラー操作方法 . . . . 20

5.1 「歩きスマホ」に関するアンケート項目と回答数 . . . . 31

5.2 既存手法を用いた実験後操作ログ . . . . 31

5.3 提案手法１を用いた実験後操作ログ . . . . 31

5.4 提案手法２を用いた実験後操作ログ . . . . 31

5.5 目的地に行けたかどうかに関するアンケートの回答数 . . . . 32

5.6 既存手法に関するアンケート項目と回答数および平均値 . . . . 32

5.7 既存手法に関するコメント . . . . 32

5.8 提案手法１に関するアンケート項目と回答数および平均値 . . . . 32

5.9 提案手法１に関するコメント. . . . 33

5.10 提案手法２に関するアンケート項目と回答数および平均値 . . . . 33

5.11 提案手法２に関するコメント. . . . 33

5.12 ゲームシステムに関するコメント . . . . 33

(9)

第 1 ^章 ^序論

1.1 ^導入

近年のスマートフォンの普及や通信速度の向上などにより，外出中に手に入れることのできる情報の量が圧倒的に増えた．人々はあるニュースを見ようとした時にすぐに，そして早く，それを見ることができる．そこで紹介されている面白い動画も，データ量が多いものだろうと見ようと思えばすぐに見ることができる．

しかし，それゆえに人々は歩きながらでも情報を得ようとして，歩きながらスマートフォンを操作する，俗にいう「歩きスマホ」という状態に陥ってしまう．「歩きスマホ」は駅のホームや道中，人通りが多さに関係なく発生している．その原因はメールの確認，ニュースの閲覧，道案内アプリの使用時など様々だ．

「歩きスマホ」の問題点は２つある．１つは画面に集中している時には周囲の状況の確認がおろそかになるという点である．画面上に多くの情報がある時，人々はその情報を見て理解しようとするために集中してしまう．「歩きスマホ」の原因の１つである道案内アプリの使用時は，自身の現在位置の把握と道順，そして道中目印になるようなものの確認など，スマートフォンの画面に集中してしまう要素が多く，それゆえに人々は周囲の確認が疎かになってしまう．

２つ目は「歩きスマホ」中は片手，あるいは両手がスマートフォンによってふさがるという点である．周りを確認していても人にぶつかる，障害物につまずくというケースは起こりえるもので，その時に手がスマートフォンによってふさがっていると，受け身を取ることが難しくなり，思わぬ怪我につながる危険性がある．

そこで本研究では，道案内アプリの使用時に焦点を当てて，ハンズフリーで「歩きスマホ」を防止する方法を提案する．スマートフォン画面上で確認していた情報を，画面を通してではなく周りの状況を用いてユーザーに提供する．本研究の目的は，この案を元にしたゲームを作成し，評価実験によってユーザーは周りを見ながらその情報を得て目的地にたどり着けるかどうか，また「歩きスマホ」における弊害をなくすことができるかどうかの調査を行うことである．さらに，現実世界におけるシステムの実現方法を提案する．

(10)

1.2 論文の構成

本論文の構成は以下のようになる．

第2章背景

本研究の背景となる状況や技術，研究について述べる．

第3章提案手法

本研究で提案する手法について述べる．

第4章道案内シミュレーションゲーム

本研究で評価実験に用いるために作成したゲームについて述べる．

第5章評価実験

評価目的や実験内容について述べる．

第6章考察と将来課題

第5章の結果からの考察および将来課題について述べる．

第7章結論

本研究の結論を述べる．

(11)

第 2 ^章 ^背景

本章では本研究の背景となる状況や技術，研究について詳細を述べる．

歩きスマホ

「歩きスマホ」の危険性は以前より指摘されていた．東京消防庁の発表では，「歩きスマホ」や自転車運転中のスマホ操作によって起きた事故により救急搬送された件数は，平成２２年から２５年の間に１２２件報告されていて．中には死亡したケースもある．

「歩きスマホ」の危険性を訴えて，規制しようとする動きは多々ある．NTTdocomo^{はあるシミュ} レーションを行い，動画を公開している[3]．この動画は，もしも渋谷のスクランブル交差点を渡る１５００人全員がスマートフォンを操作していたらという想定で行われており，結果は以下の通りとなった．（表2.1^）

表 2.1: シミュレーション結果衝突件数４４６件転倒件数１０３件スマホ落下件数２１件

横断成功者５４７／１５００名

このような極端なケースは起こり得ないとはいえ，その危険性を訴えるには十分であり，この動画の他にも以下のような広告で「歩きスマホ」をやめるように訴えている．（図2.1）

(12)

図2.1: 「歩きスマホ」防止広告

出典：https://www.nttdocomo.co.jp/info/news release/2013/12/03 00.html

しかし，東京消防庁の発表では，「歩きスマホ」等による事故は年々増えている．以下に示す．（図 2.2）

図2.2: ^{年別の救急搬送人員}

出典：http://www.tfd.metro.tokyo.jp/lfe/topics/201403/mobile.html

さらに，この事故の多くが駅や道で起きている．以下に示す．（図2.3）

(13)

図 2.3: 場所別の救急搬送人員

出典：http://www.tfd.metro.tokyo.jp/lfe/topics/201403/mobile.html

駅や道の共通点は人や障害物が多いという点である．このような場所での「歩きスマホ」が一番事故が起こりやすく，この状況において周りを確認しながら歩くことがいかに重要かがよく分かる．

道案内アプリ

ユーザーが土地勘のない場所において，GPSと地図によって目的地までの経路を示すアプリケーションのことを本論文では道案内アプリと呼称している．

まず，「歩きスマホ」時にスマートフォンを使用している用途の内訳を図2.4に示す．

(14)

図2.4: 「歩きスマホ」時の用途内訳

出典：http://www.dims.ne.jp/timelyresearch/2014/141219/

図によると，メールの確認と道案内アプリの使用が半数を超えており，この２つが「歩きスマホ」

状態に陥りやすい用途と言える．今回はこの２つの内，道案内アプリの使用に焦点を当てた．

ユーザーが目的地を入力することで画面上には現在位置，その周囲の地図，そして目的地までの経路が示される．（図2.5）

(15)

図2.5: ^{道案内アプリ}

出典：Google Maps^{を用いて自作}

ユーザーは画面を確認し，示された経路を進むことで目的地にたどり着くことができる．

歩行時，ユーザーは常に画面を見ているわけではなく，ユーザーが画面を見るタイミングとして，

自分が経路通りに歩けているか，または曲がり角はどこかを確認するときが想定される．よって，そのタイミングで，曲がり角の場所等の情報を周りを見ながら確認することができれば，道案内アプリの使用時の「歩きスマホ」は無くせると考え，手法を考案した．

2.1 関連研究

本節では，道案内アプリの使用時に「歩きスマホ」状態ではなくなる研究や技術について，詳細を述べる．

(16)

2.1.1 音声案内

道案内アプリには，音声によって道を案内する機能をもったアプリケーションがある．これはカーナビゲーションシステムと同じように，あとどのくらい進むとどの方向に曲がればいいかを音声によってユーザーに伝えるものである．（図2.6）

図 2.6: 音声案内使用イメージ

出典：http://www.appps.jp/2105716/一部加工

画面を見ずに道がわかるため，「歩きスマホ」の状態にはならず，さらにハンズフリーであるためにもしもの状況における怪我のリスクも減らせる．

しかし，音声を聞くためにイヤホンをするために周囲の音が聞けず，得られる情報量が制限される．

さらに，複雑な曲がり角ではどの道を行けばよいかわかりづらいという欠点もある．

2.1.2 YUBI NAVI

NTTdocomoが開発した棒の形をしているデバイスで，白いウレタンゴムで覆われており固くなく，

左右にねじれる特徴がある[4]^{．以下に示す．}^（図2.7^）

(17)

図2.7: YUBI NAVI

出典：http://appllio.com/20141007-5773-docomo-yubinavi-prototype

これを手に持ち，先端のくぼんでいる部分に親指を乗せる．そのまま道を進む．（図2.8^）

図2.8: YUBI NAVI使用時

出典：http://appllio.com/20141007-5773-docomo-yubinavi-prototype

(18)

を用いてすぐに分かる．このデバイスを使用することで，「歩きスマホ」の状態ではなくなり，周囲を見て障害物などを避けることができる．また，先に挙げた音声案内とは違い，音を用いてはいないため，聴覚が制限されることがない．

しかし，手にデバイスを持っているために，ハンズフリーではなくなる．

２つの関連技術・研究を述べたが，それぞれ利点と欠点を併せ持っている．それらを解消するような手法を提案し，同時に生まれる欠点について調査することが本研究の目的の１つである．

(19)

第 3 ^章 ^提案手法

本章では，道案内アプリでユーザーに経路を提供する既存手法での欠点を解消するために考案した，

道案内アプリ使用時の「歩きスマホ」防止のための新規手法の詳細を述べる．

3.1 提案手法概念

ユーザーは道案内アプリを使用して目的地までたどり着く間，常にスマートフォン画面を見続けているわけではない．画面を見るタイミングとして，以下が想定される．

1. 自身が経路上にいるかどうかを確認するとき

2. 曲がり角にあとどのくらい進めば着くのか，そしてその時の曲がる方向を確認するとき上記のタイミングの時に「歩きスマホ」が発生すると考えた．つまり，「歩きスマホ」を無くすためには，その時に画面ではなく周囲を確認している必要がある．そこで，周囲にいる人々や物に発光物を取り付けて，それから発生する光を確認することで，ユーザーを誘導するような手法を考えた．

(20)

3.2 提案手法詳細

周囲の人々は自身の進む経路を事前に設定し，その通りに歩く事を前提としている．そして，ユーザーはまず道案内アプリで目的地等を入力し，経路を設定する．

3.2.1 進路送信

ユーザーがどこでどの方向に曲がるかを周囲に発信し，周囲の人々はそれを受信する．（図3.1^）

図3.1: ^{進路送信イメージ}

(21)

3.2.2 曲がり角直前通知

そして，自身の経路とマッチングを行って，ユーザーと同じ曲がり角を通るのであれば，曲がり角の直前で発光物を発光させる．この光を確認することで，ユーザーは自身の曲がるべき曲がり角が近い事を確認できる．（図3.2）

図 3.2: 曲がり角直前イメージ

(22)

3.2.3 曲がる方向通知

さらに，曲がる方向まで同じ場合は発光させ続ける．（図3.3）

図3.3: 曲がり角進入中イメージ

ユーザーは曲がるときに，発光している発光物をつけた人々に着いて行くことで，適切な曲がり角で曲がることができる．

(23)

3.2.4 補助ライト

補助として，曲がり角の四方にも発光物を取り付けて，ユーザーが曲がるべき曲がり角に差し掛かった時に適切な発光物を発光させることで，もしも同じ方向に曲がる人が周囲にいない場合にも，

ユーザーは適切な曲がり角で適切な方向に曲がることができる．（図3.4）

図3.4: 補助ライト使用イメージ

周囲の人々が曲がる直前と，曲がっている最中の発光のパターンを変えることで，ユーザーはその違いを認識することができる．

(24)

第 4 ^章道案内シミュレーションゲーム

本章では，評価実験に用いるために，既存手法と提案手法を取り入れたシミュレーションゲームの実装について述べる．

4.1 システム構成

評価実験を行うシステムの構成を以下に示す．

図4.1: ^{システム構成図}

(25)

4.2 システム詳細

道案内シミュレーションゲームの詳細を述べる．

4.2.1 マップ

今回マップを２つ作成した．それぞれの構成について述べる．

基本マップ

プレイヤーを実際に移動させる基本マップの仕様を表4.1^に示す．

表4.1: 基本マップ構成要素

構成要素仕様

床 Plane／白／大きさ（１７×１×１７）／１個

壁 Cube／青／大きさ（１０×１０×１０）／８１個センサー Cube／赤／大きさ（１１×１０×１１）／６４個

基本マップの外観を図4.2に示す．

図4.2: ^{基本マップ外観}

そして，各曲がり角にセンサーを配置する．センサーを設置した状態の基本マップを図に示す．

(26)

図4.3: センサー設置後基本マップ

図では赤くなっているが，ゲームをスタートさせると透明になる．

アプリケーション画面用マップ

プレイヤーがスマートフォンを操作して，道案内アプリを見ているような状況を作るためのマップを別途作成する．仕様を表4.2に示す．

表 4.2: アプリケーション画面用マップ構成要素

構成要素仕様

床 Plane／白／大きさ（１７×１×１７）／１個

壁 Cube／青／大きさ（１０×５×１０）／８１個道順用タイル Cube^{／黄緑／可変／可変}

R1ボタンを押すと，押している時間だけそのマップを映した画面に切り替わり，離すと元の画面に戻る．つまり，R1ボタンを押しているときは「歩きスマホ」状態になっている．アプリケーション画面用マップを図4.4^に示す．

(27)

図4.4: アプリケーション画面用マップ外観

4.2.2 要素

マップ上に登場させる要素を表4.3^に示す．

表4.3: ^構成要素

構成要素仕様

プレイヤー白／大きさ（１×１．２×１）／１個

歩行者色々／大きさ（１．５×１．５×１．５）／２５６体ライト Cube／色々／大きさ（０．１×０．１×０．１）／

２５６個（歩行者用）＋２５６個（曲がり角用）

以下に，それぞれの要素について述べる．

プレイヤー

(28)

図4.5: プレイヤー外観

表4.4: コントローラー操作方法

ボタン動き

左スティック上前に進む左スティック下後ろに下がる左スティック右右に平行移動左スティック左左に平行移動右スティックカメラ操作

R1^ボタン ^{画面切り替え}

プレイヤーには，プレイヤーを中心に範囲を決めて，それをプレイヤーの周囲と定義する．プレイ

(29)

図4.6: ^{プレイヤーの周囲}

歩行者

プレイヤー以外の歩行者をマップに登場させる．歩行者はランダムで曲がり角を曲がり，進み続ける．プレイヤーとぶつかった場合は特に反応せずすり抜ける．その時カウントは１増えて，最終的にそのカウントがぶつかった回数となる．基本マップに歩行者が登場している図を図4.7に示す．

(30)

図4.7: 歩行者を登場させたゲーム画面

ライト

歩行者の頭上と各曲がり角の四方にはライトを設置してある．このライトが光ることで，被験者に曲がるタイミング，あるいは曲がる方向を示す．光る条件は以下のとおりである．なお，ライトが光るのはプレイヤーの周囲にいる歩行者のみである．

1. プレイヤーが曲がるべき曲がり角に近づいている場合

プレイヤーが曲がるべき曲がり角に近づいた時，その曲がり角の直前にいて，プレイヤーの進行方向と同じ方向に進んでいる歩行者の頭上のライトが緑色に光る．この場合のゲーム画面を図4.8^に示す．

(31)

図 4.8: ライトが緑色に光る時

近づいているというのは，プレイヤーの周囲を示す範囲に曲がるべき曲がり角が入った状態を指す．

また，曲がり角の四方に設置したライトについては，プレイヤーが曲がるべき曲がり角において，右に曲がるべき時は向かって右のライトが，左に曲がるべき時は向かって左のライトが黄色に光る．

以下にこの時の条件を図4.9に示す．

(32)

図4.9: ライトが緑色に，補助ライトが黄色に光る時の条件

被験者は緑色のライトを見ることで，プレイヤーが曲がるべき曲がり角に近づいていることを確認でき，さらに曲がり角のライトを確認することで，プレイヤーの曲がるべき曲がり角と曲がる方向を知ることができる．

(33)

2. プレイヤーが曲がるべき曲がり角に近づいていて，かつ歩行者が曲がっている場合この時，歩行者は２通りの場合がある．

(a) プレイヤーと同じ方向に進む場合 (b) プレイヤーとは違う方向に進む場合

プレイヤーと同じ方向に進む場合は，ライトが黄色に光る．そして，プレイヤーとは違う方向に進む場合はライトが消える．被験者は黄色に光っているライトを持った歩行者を見ることで，

プレイヤーの進むべき方向を確認することができる．この場合のゲーム画面を図4.10に示す．

図 4.10: ^{ライトが黄色に光る時}

また，この時の条件を以下に図4.11^に示す．

(34)

図4.11: ライトが黄色に光る時の条件

(35)

3. プレイヤーがゴールに近づいていて，かつ歩行者がゴールにいる場合

この場合，歩行者の頭上のライトは赤色に光る．被験者は赤色に光っているライトを見て，

ゴールが近い事を確認できる．この場合のゲーム画面を図4.12に示す．

図 4.12: ライトが赤色に光る時

また，この時の条件を以下に図4.13^に示す．

(36)

図4.13: ライトが赤色に光る時の条件

プレイヤー２

アプリケーション画面用マップに登場する．プレイヤーと同じをして，マップ上で自身が今どこにいるかを被験者に示す役割がある．

道順

アプリケーション画面用マップに登場する．プレイヤーの経路を示す．以下にゲーム中におけるアプリケーション画面用マップを図で示す．（図4.14）

(37)

図4.14: ゲーム中にR1ボタンを押した時

4.3 ゲームモード

上記の要素を組み合わせて，提案手法と既存手法とに分ける．

既存手法は，R1ボタンを使用して経路の確認をしながら進んでいく．

提案手法はR1ボタンを使用せず，代わりにライトを使用して進んでいく．補助ライトを使用しない場合を提案手法１，使用する場合を提案手法２とした．

(38)

第 5 ^章 ^評価実験

本章では，本研究で行った実験概要とその結果について述べる．

5.1 実験概要

5.1.1 被験者

実験は10代の女性1名，20代の男性5名，女性2名，40代の女性1名，50代の男性1名の計10 名に行った．

5.1.2 目的

本実験の目的は，提案手法が既存手法での問題点である「歩きスマホ」状態が解消されているか，

そして実際に提案手法で目的地に辿り着けるのかを明らかにすることである．

5.1.3 実験手順

提案手法と既存手法を比較するため，両方の手法を試してもらう．以下に実験手順を示す．

1. 実験前アンケートに回答してもらう

2. 既存手法を用いて，被験者にプレイヤーを目的地まで操作してもらう 3. 提案手法１を用いて，被験者にプレイヤーを目的地まで操作してもらう 4. 提案手法２を用いて，被験者にプレイヤーを目的地まで操作してもらう 5. 実験後アンケートに回答してもらう

5.2 実験結果

5.2.1 実験前アンケート

(39)

表5.1: 「歩きスマホ」に関するアンケート項目と回答数

項目はいいいえ

「歩きスマホ」はしますか？ 8 2

「歩きスマホ」中に人・物に衝突

したことはありますか？ 1 9

「歩きスマホ」中に危険だと思っ

たことはありますか？ 7 3

5.2.2 実験後操作ログ

実験を行った結果ログに残された値を以下にに示す．被験者10名をA Jとし，既存手法を用いた実験についての結果を表5.2に，新規手法１を用いた実験についての結果を表5.3に，新規手法２を用いた実験についての結果を表5.4にそれぞれ示す．

表5.2: 既存手法を用いた実験後操作ログ

被験者 A B C D E F G H I J ^平均値衝突回数 33 28 25 40 35 44 22 18 8 25 27.8 R1 ^{ボタンを押し}

た回数 39 40 40 43 32 53 20 15 17 20 31.9

表5.3: 提案手法１を用いた実験後操作ログ

被験者 A B C D E F G H I J 平均値衝突回数 30 24 27 25 30 29 20 14 7 24 23

表5.4: 提案手法２を用いた実験後操作ログ

被験者 A B C D E F G H I J ^平均値衝突回数 35 20 28 23 29 31 15 11 9 22 22.3

5.2.3 実験後アンケート

(40)

うかに関するアンケートの回答数を，表5.6に既存手法に関するアンケート項目と回答数および平均値を，表5.7に既存手法に関するコメントを，表5.8に提案手法１に関するアンケートの項目とそれぞれの回答数および回答の平均値を，表5.9に提案手法１に関するコメントを，表5.10に提案手法２に関するアンケートの項目とそれぞれの回答数および回答の平均値を，表5.11に提案手法２に関するコメントを，表5.12に今回のゲームのシステムに関するコメントを示す．

表5.5: 目的地に行けたかどうかに関するアンケートの回答数

項目はいいいえ

既存手法を用いた場合 10 0 提案手法１を用いた場合 9 1 提案手法２を用いた場合 10 0

表 5.6: 既存手法に関するアンケート項目と回答数および平均値項目はいどちらかと

言うとはい

どちらでもない

どちらかと言うといいえ

いいえ平均値

「歩きスマホ」を再現

出来ていましたか？ 3 5 2 0 0 4.1

マップは見やすかった

ですか？ 0 6 2 2 0 3.4

表5.7: 既存手法に関するコメントコメント

マップが回転するため，方角など基準となるものが欲しかった．

「歩きスマホ」中でも周りは多少見えているが，このゲームでは再現出来ていない．

表 5.8: 提案手法１に関するアンケート項目と回答数および平均値項目はいどちらかと

言うとはい

いいえ平均値

(41)

表5.9: 提案手法１に関するコメントコメント

現実では，頭上にはライトはない．

行くべき方向がわかりやすかった．

直線を進んでいる時，道なりに進めているか心配になった．

表 5.10: 提案手法２に関するアンケート項目と回答数および平均値

項目はいどちらかと言うとはい

いいえ平均値

常に周りを確認しなが

ら歩けましたか？ 10 0 0 0 0 5.0

補助ライトは見やすか

ったですか？ 5 3 2 0 0 4.3

表5.11: 提案手法２に関するコメント

避けることに必死で，補助ライトまで見ることができなかった．

自分と同じ方向に行く人がいない場合でも，曲がることができる．

表5.12: ゲームシステムに関するコメント

歩行者を避けることが難しい．

人の流れを再現出来ておらず，歩行者が無秩序の歩いている．

歩行者は回避行動を取らないため，後ろからぶつかってきて，それも衝突回数に数えられている．

(42)

第 6 ^章 ^{考察と将来課題}

本章では第5章で示した実験結果に対する考察を行い，将来課題を示す．

6.1 考察

6.1.1 ゲームシステム

各実験後の操作ログから，衝突回数が提案手法を用いることで減少していることは確認できなかった．なぜなら，今回実験で使用したゲームは，現実世界を再現しているとは言えなかったためだ．今回歩行者は他の歩行者，あるいはプレイヤーと衝突しそうになった際，回避行動をしないでそのまま通り過ぎることにした．この時，プレイヤーの背後から衝突する歩行者も発生するが，それら全てを衝突回数としてカウントしている．さらに，例えば現実世界において曲がり角を左に曲がろうとする際には，あらかじめ左に寄ってから曲がる．しかし，今回ゲーム上では，直線は真っすぐ進み，曲がる際には道を横断するような形で曲がることで歩行者を再現している．これは現実世界ではほとんどない動きで，ゲームが現実世界を忠実に再現しているとは言えない．

将来課題

これらを踏まえて，このゲームを以下の点で修正する必要がある．

1. ^{歩行者の動き}

今回歩行者は直線ではまっすぐ進むことしかしていないため，斜めの動きを加える事で，曲がり角において事前に，曲がる方向に寄る動きを実現できる．さらに，別の歩行者，またプレイヤーに対してぶつかりそうになった時に多少の回避行動をすることで，歩行者の動きはさらに現実に近づくだろう．

2. 衝突判定

今回はプレイヤーにぶつかった回数を記録する際，前後左右どこからぶつかっても衝突したという判定にした．しかし，実際には後ろからぶつかることは少なく，衝突の多くはすれ違うときに起こる．よって，衝突時の方向も加味して判定するようにすると，現実世界へさらに近づ

(43)

いうケースも多かった．さらには，曲がり角において，今回は交差点のみで作っているが，実際は三叉路や突き当りという場合もある．そこで，マップを複雑にし，さらに階段を採用するなど障害物への考慮も取り入れると良いと思われる．

6.1.2 既存手法

今回，R1ボタンで「歩きスマホ」を実現した．これは，被験者がR1ボタンを押すことによって，

カメラを切り替えて，別に作成した道案内アプリ用マップを見せることで実現している．しかし，現実では「歩きスマホ」中でも周りが多少見えている．そのわずかな視界で歩行者や障害物に気づく場合もあり，この点を考慮していないとのコメントも被験者より頂いた．

将来課題

これを踏まえて修正する必要がある．カメラの位置を変えプレイヤーの手元が映るようにし，そこに別に作成した道案内アプリ用マップを表示することで，現実世界における「歩きスマホ」に近づけることができると思われる．

6.1.3 提案手法

提案手法では，既存手法での「歩きスマホ」をすること無く，さらに常に周りを見ながら操作できたという結果やコメントが得られた．しかし，提案手法１では目的地に着かなかったというケースが発生した．これは，自分と同じ方向に行く歩行者がたまたまいなかったことで，誘導が出来なかったためだ．この事から，提案手法は人の多さによって信頼性が変わるという特徴があることがわかった．

ここで，「歩きスマホ」によって事故が起こる状況を考えると，その多くが本論文の第２章にあるように，人通りの多いところで起きている．よって，人通りが多ければ「歩きスマホ」による事故が起きやすく，本手法も使いやすい．逆に人通りが少なければ，「歩きスマホ」による事故は起きにくく，同時に本手法は使いにくいということがわかる．しかし，人通りが少なくても事故は起きているため，

人通りには左右されず，本手法の信頼性を上げる必要がある．

将来課題

本手法の信頼性を上げるために考えたものが補助ライトである．これは曲がり角に設置し，曲がる方向をユーザーに教えるもので，実験ではこれも用いた提案手法２によって誘導ミスがなくなった．

しかし，人を見て避けることに必死になり，補助ライトはよく見えなかったというコメントを頂いた．

そこで，人の流れを再現するなどして修正したゲームにおいて，補助ライトがしっかり見えるのかどうかを確かめる必要がある．

(44)

6.2 現実世界での実現

提案手法を現実で再現するためには，自分の周囲に自身の経路情報を送れなければならない．それに適しているのがiBeacon[7]である．これはBluetooth Low Energy（BLE）を用いて周囲の複数端末に情報を送る事ができる．iBeaconでは，自身のユニークなID^や，major^・minor^{といった任意の} データを送ることができる．しかし，送ることができる任意のデータは容量が少ないため，それを考慮する必要がある．そこで，ユーザーは自身の経路全てではなく，直近の曲がり角とその方向を送信することにする．受信した歩行者は自分の経路とマッチングを行い，合っていればライトを光らせる．

ユーザーに曲がり角が近いことを知らせるときには，歩行者がその曲がり角までの距離をGPS等を使って測り，ある一定の距離になったらそれをユーザーに知らせる．iBeacon^{は常にデータを送信し} 続ける特性があるために，曲がり角を曲がったらすぐに次のデータを送ることができ，さらにその範囲も限られる．この方法で実現する際の課題点を以下に示す．

6.2.1 使用者が複数人数の場合

今回はユーザーが１人であるという前提で提案しているが，近くに他のユーザーがいた場合に，光が自分に対してのものなのか，他のユーザーに対してのものなのかを判別しなければならない．そのためには，光の色を変えることが考えられる．そして，ユーザーに曲がり角が近いことを知らせるときには点滅，曲がる方向を知らせるときには点灯，ゴールが近いことを知らせるときには別の点滅パターンを用いるなど，ライトの点灯パターンを変えると，複数ユーザーに対応出来る可能性がある．

しかし，色の種類には限度があり，ユーザーの数によっては動的に色を変えていかなければならず，

そしてそれをユーザーにどのように伝えるかが問題となる．

6.2.2 補助ライト

補助ライト用に，各曲がり角にiBeaconを設置する．そして，そこでも経路のマッチングを行って，

補助ライトを光らせる．iBeacon端末にはユニークなIDがあるために，それが住所のような役割をする．よって，曲がり角のマッチング自体は簡単にできるだろう．しかし，現実世界で実際に補助ライトを点けても，看板などの装飾に使われている電飾にまぎれてしまって，よく見えなくなる恐れがあり，適切な設置位置と光量などを今後の研究で明らかにしなければならない．

(45)

第 7 ^章 ^結論

本研究では，道案内アプリ使用時の「歩きスマホ」を防止するための手法を提案し，シミュレーションゲームを用いてその有用性を実験した．実験の結果，提案手法は「歩きスマホ」を防止することができることが示された．しかし，ゲームの問題点により，提案手法による衝突回数の減少を確認することはできなかった．さらに，現実世界において実現するためにはいくつかの課題があることも同時にわかった．本研究から得られた知見を元に，シミュレーションゲームの改良をして，提案手法によって衝突回数は減少するかを検証する必要がある．また，現実世界での提案手法の実現のために，

考えたシステムを構築することが今後の研究の目標となる．

(46)

参考文献

[1] 「歩きスマホ」に関するアンケート/ネットリサーチDIMSDRIVEの公開アンケート調査結果

【DIMSDRIVE】: http://www.dims.ne.jp/timelyresearch/2014/141219/

[2] 東京消防庁＜安心・安全＞＜トピックス＞＜歩きスマホ等に係る事故に注意！！＞: http://www.tfd.metro.tokyo.jp/lfe/topics/201403/mobile.html

[3] 全員歩きスマホin渋谷スクランブル交差点-もしもスクランブル交差点を横断する人が全員歩きスマホだったら?-: https://www.youtube.com/watch?v=3NDuWV9UAvs

[4] ドコモ、クネっと動きムクっと隆起する棒型デバイス「YUBI NAVI」を展示 CEATEC —アプリオ: http://appllio.com/20141007-5773-docomo-yubinavi-prototype

[5] 報道発表資料 : 歩きスマホ防止の新たな取り組みについて— お知らせ — NTTドコモ: https://www.nttdocomo.co.jp/info/news release/2013/12/03 00.html

[6] 掌田津耶乃，見てわかるUnity JavaScript超入門，秀和システム，2014

[7] iBeacon for Developers - Apple Developer: https://developer.apple.com/ibeacon/

[8] Is Wibree going to rival Bluetooth? - HowStuﬀWorks:

http://www.howstuﬀworks.com/wibree.htm

[9] aBeacon iBeacon をAndroid で受信する — ピックアップ — ギャップロ: http://www.gaprot.jp/pickup/ibeacon/abeacon/

(47)

謝辞

本研究の機会を与えて下さり，懇切丁寧なご指導を賜りました中島達夫教授に深く感謝，御礼申し上げます．

また，シミュレーションゲーム作成の際にアドバイスを頂いた先輩方，同輩に深く感謝致します．

道案内アプリ使用時における 歩きスマホ防止方法の提案

修士論文