1F5-OS-09b-7 環境知能の観点から見たスマートアクセスビークルのユーザインタフェースデザイン

(1)

環境知能の観点から見た

スマートアクセスビークルのユーザインタフェースデザイン

Ambient Intelligence View of User-Interface Design for Smart Access Vehicles

中島秀之

Hideyuki Nakashima

平田圭二

Keiji Hirata

佐野渉二

Shoji Sano

公立はこだて未来大学

Future University Hakodate

We are proposing a new public transportation system, Smart Access Vehicle system, which provides mobility as a service. We conducted the field test twice in Hakodate, and weakness in the user-interface design was revealed. We will describe some revisions in the design for the next field test at JSAI 2015. We will further discuss the future direction of the UI design, relating it to Ambient Intelligence concept.

我々は人の移動を担う公共交通網を柔軟化することによって，その上で様々なサービスの連携が可能になると考えている．これによりサービス提供のユニバーサル化が進み，移動に関してインターネットの利便性に近づくことができるのではないかというのが本稿の主張である．つまり，情報に対するインターネットのようなものを，モノの移動に対して創りたい．Mobility based service unificationと仮に呼んでおく．その中心システムとしてコンピュータ制御によるスマートアクセスビークルシステム（Smart Access Vehicle System. 以後，個々の車両をSAV，全体のシステムをSAVSと呼ぶ）を提案し，実証実験を行っている[松原13]．本稿ではSAVSのユーザインタフェース(UI)に注目し，環境知能の立場から，そのデザインを行う．SAVSのUIは主としてユーザ（乗客）∗1向けのものと，ドライバ向けのものがある．

1. Smart Access Vehicle System

いくつかの自治体で「フルデマンドバス」という，固定路線や固定ダイヤを全く持たない公共交通方式が実施されているが，これらは過疎地に限ったものである[田柳13]．また，これらは人手による配車計画が中心で，コンピュータによる集中制御はあまり広まっていない．東大[大和08,坪内09]とNTT 東日本[NTT東]がそれぞれコンピュータシステムによる運行管理者の補助システムを作っているのが例外である．またこれらのオンデマンドバスシステムは事前（発車前）予約を基本としている．つまり，デマンドバスのルートをあらかじめ決めた上で運行が開始される．ルートは自由でも，１時間ごとの発車というように発車時刻を固定されているものが多い．これらに対し，我々が提案するSAVSは以下の特徴を持つ： • 少数台を限られた地域や目的で運行するのではなく，都市全体の公共交通機関を集中制御する．現在運行されているバスやタクシーの車輌を使うことができる∗2_が，運行方式の異なる，新しい公共交通システムの提案である．連絡先:中島秀之，公立はこだて未来大学，函館市亀田中野町 116-2，0138-34-6457（秘書） ∗1 本稿では「ユーザ」とは SAVS を予約するところからを含むが， 「乗客」は乗車中のユーザを指すのに使う． ∗2 現行車輌を使うことにより移行が容易であるが，将来的には乗り 合いを意識してデザインした専用車輌が望ましい． • コンピュータ制御による，デマンド応答型完全自動運行である．乗降地点の制約は無く，経路も自由である．また，運行の自由度が高いことと，集中制御方式である利点を活かし，他のサービスとの連携が容易である．移動サービスにおけるインターネットのような，サービス基盤となることを想定している． • 事前予約を前提とせず，乗りたいときに呼出すことができる． • 実時間で車両のルートを設定・管理する．このため乗客が乗車中にルートが変わることがあるが，約束した到着時間は守る．∗3 SAVSはコンピュータによる集中制御方式を採る．このため柔軟な運行管理が可能であり，従来型の路線バスやタクシーの運行方式を完全に包含している．つまり，タクシーあるいはハイヤーのようにユーザが独占する形態から，バスのように路線と停留所を固定して使うこともできる．たとえば前者は観光，後者は通勤・通学に適していると考えられる．大都市におけるバスのフルデマンド方式はユーザのリクエストに応えて回り道をするので効率が悪いのではないかという質問を多く受ける．ある程度以上の台数が確保されれば問題ないということがマルチエージェントシミュレーションで示されている[野田08]のであるが，社会常識は逆のようである．これは少数台で実証実験することによる結果にすぎないが，世界中でフルデマンドバスは僻地でしか使われていない現状は残念である． SAVSは以下の手順で呼出される： 1. ユーザが現在位置と目的地を指定して配車をリクエスト 2. サーバが最適車輛を選択[小柴14] 3. 車輛に新ルートを指示 4. ユーザにピックアップ予定時刻と目的地到着予定時刻を伝達 5. ユーザ端末はアサインされたSAVの現在位置，車載端末はユーザの現在位置を地図上に表示 ∗3 到着予想時刻はあらかじめ若干のマージンを持たせて設定する． また，飛行機や長距離列車への乗り継ぎがある場合はそれを厳守する．これらの到着時刻を超えるようなデマンドは別の車輌にアサインする．

1 The 29th Annual Conference of the Japanese Society for Artificial Intelligence, 2015

(2)

システムの動作は完全自動でオペレータは介在しない．ドライバは車載端末の指示で運行する．2013年10月にフルデマンド型公共交通の世界初の複数台リアルタイム完全自動配車実験に成功し，4日間の自動運行を行った[中島14]．

2. システム構成

2.1 全体構成

SAVSは，(1)ユーザが端末（スマートフォーンを想定している）上でデマンドを入力するためのアプリケーション（ユーザApp），(2) SAVドライバが車載端末（現状ではタブレット端末を想定している∗4）上でデマンドを確認するためのアプリケーション（車載App），(3)デマンドに応じて最適な車輛と訪問順序を計画する配車システム，の3つより構成される．また，これらのサブシステムはデータベースを介したデータのやりとりによって連携を実現する（図1）．図1: SAVSの全体構成これにより，SAVSは人間のオペレータを介することなく，自動でデマンドの受付からアサインまでを行うことができる．全自動での対応は，SAVサービスの提供上重要であるのみならず，サービスを社会実装する際に有用な特徴である．つまり，全自動化を行うことで，普段は一般のタクシー配車システムとして使いながら，アルゴリズムを切り替えて特定の日や時間帯だけタクシーをSAVとして運行するという，シームレスかつ適応的な車輌運用が可能となり，事業者らが実態を見ながら徐々にSAVSを導入することが可能になる．

2.2 ユーザ App

ユーザApp（図2）は，ユーザが自身のデマンドを入力・通知するためのアプリケーションである．後述する配車システムでデマンド処理した結果，デマンドがSAVにアサインされると，何時頃に乗車・降車（目的地到着）できそうかという，見込み時刻も表示される．なお，これらのサービスを提供するために，ユーザApp起動中は常時ユーザの位置情報を収集し，送信している．ユーザAppの機能は以下である： 1. SAVリクエスト (a) 乗車位置を地図上で指定．デフォールトはユーザの現在位置．オプションとして施設名などの文字入力が可能． (b) 降車位置を地図上で指定． ∗4 タブレット端末を用いることで導入コストが安価になるが，将来 的にはカーナビとの一体化を目指したい．図2: ユーザApp画面の遷移 (c) 降車希望時刻を指定（オプション）．鉄道や航空機への接続などの締め切り時刻を指定する． 2. SAVの状況確認．SAVの現在位置を地図上で表示したり，到着予想時刻を表示する． 3. アンケート（第2回実験で実装）．特に「今回のサービスにいくらくらい払いますか」という質問で価格感を知ろうとした．

2.3 車載 App

車載App（図4）は，SAVドライバに向けて，乗客の乗車・降車位置や順序と，それらの更新を適時通知するためのアプリケーションで，タブレット型端末で稼働する（現状では携帯電話網で通信する）．配車システム（2.4節）でデマンドを処理した結果，デマンドがSAVにアサインされると，音で通知すると共に，画面上の乗客リストと地図上の訪問順序を更新する．乗客リストには，乗せ間違い防止のために乗客名，ユーザ入力による乗車地点の目印情報，乗降地点，などが表示される．ドライバが乗客の乗降をシステムに通知するために，乗客乗降を通知するボタン∗5を有する．また，車輛の位置情報を1 分ごとにサーバに自動送信する．

2.4 配車システム

配車システムはデマンドに対して適当な車輛(SAV)を探索するシステムである．これがSAVSの要であり，乗合いの為の寄り道が少ない効率の良い配車ができなければシステムとして成立しない．少数台の実証実験では車輛選択の余地があまり無いが，我々は1000台あるいはそれ以上の規模の車輛数を想定しているため，それらの中から最良の（あるいはそれに準じた）一台を選ぶことが重要課題である．逐次最適挿入法[野田08]により最も回り道の少ないSAVの探索を行っている．

3. ユーザインタフェースの現状と将来

3.1 2014 年の実験に用いた UI

第2回実験では，ユーザAppならびに車載Appのユーザインターフェース(UI)を改善した．図2のような状態遷移をデザインし，実装した（図3）．ボタンの配置や説明文の追加など，細かい点が改良されている．ユーザAppの基本機能は変わらないが，乗車位置や降車位置の指定に地図上の位置を知らない場合でも，駅，ホテルや観光地などのランドマークリストからも選択可能なようにした． ∗5 将来的には IC カード等を使って乗降確認も自動化する予定であ る．

2

(3)

これは函館を観光や仕事で訪問する人の利便性を考えたものである．車載App（図4）では，乗車（赤）と降車（緑）を色分けし，地図上の地点表示との対応付けが容易になるようにした．また左端に「休憩」「呼び出し」のボタンを配置した．ドライバからの「休憩」リクエストが入ると配車システムはそのSAVに新たなデマンドを割り付けない．乗車中の乗客がすべて降車した時点でドライバは休憩に入れる．休憩モードに入るとこのボタンは「運行開始」に変わる．つまり，有効なボタンだけを表示∗6するようにした．「呼び出し」は乗客が見つからないなどのトラブルのときに配車センターに連絡するためのボタンである．図3: 第2回実験に用いたユーザAppの画面（左はホーム，右はリクエスト中）図4:第2回実験に用いた車載Appの画面

3.2 2014 年版 UI の問題点

これまでに実施した2回の実証実験を通して得られた問題点・改善点の内，UIに関する主なものを挙げる．設計段階ではflexibilityとusabilityのトレードオフへの対処を検討したが，実際の車輌と乗客を使った実験では例外処理や人為的ミスに対する頑健性が重要であることを再認識した．以下，Uはユーザ，Dはドライバインタフェースの問題である： U リクエストを終えると自動的にデマンドが発行されてしまうので，試しにどんな感じか（たとえば何分ぐらいで着くのか）を知りたいユーザに対応できない． U 一度呼び出したSAVをキャンセルする機能がない． ∗6 UI においてボタンのデザインには二派が存在する．現在状態を 表示する（ビデオ再生中には再生状態の意味でを表示する）方式と，動作を表示する（ビデオ再生中には停止ボタンを表示する）方式である．我々はいまのところ後者を選択しているが今後の吟味が必要である． UD ボタンの押し間違いをキャンセルする機能がない． D ユーザの待っているのが道路のどちら側かを指示する機能がない． D 地図表示だけでは不足．意外なことに，地図の読めない運転手が案外と多い．通常は目印と住所で走っているため，住所の方がわかりやすいという運転手もいる．函館のタクシーにはカーナビが装着されていないものが多い． UD ランデブー機能がない．駅やスーパーマーケットなど，人と車の多い場所では互いに相手が認識できない可能性がある．地図上での位置表示は行っているが，それを見ないユーザもいることがわかったので，より親切な，できれば地図以外の方式が欲しい．

3.3 さらなる機能

さらに，将来は以下のような機能を付加したいと考えている（UIだけの問題ではない機能もある）： U 自宅や病院，会社，学校など頻繁に訪問する場所の登録機能．あるいは履歴機能． U 入力を容易にするために音声認識などを併用する可能性もある．特に地名や施設名などの入力にSiriなどのプログラムを連携して使うことを考えると，テキスト入力も用意しておいた方が良いかもしれない．テキストは万能のインタフェースだから，Siriから入力できるはずである． U 時刻表検索との連携機能．電車やバスとならんでSAVの可能性（所要時間や料金）も表示される他に，電車や飛行機との接続を考えてSAVをリクエストする機能． U 複数候補の表示．最も早いが値段も高い候補から，遅めで安い候補までをいくつか示し，ユーザに選択させる機能． U 乗合い相手指示機能．大型のバスの乗り合いではあまり問題にならないが，小型車輌の場合は誰と乗り合わせるかにも気を使う．特に若い女性と酔った男性の組み合わせ（あるいはその逆）などは避けたい．都市部の電車に倣って，女性限定車輌の指定などができる機能が必要かもしれない．公共交通は全面禁煙になっているから，禁煙車の設定は不要であろうが，逆に喫煙車というサービスがありうるかもしれない． D なんらかの都合で，システムの指示を変更する必要があるかもしれない．例えばルートを変えてピックアップの順序を変えるとか，乗車中の乗客が降車地点を変更したい場合などが考えられる．このための機能は現在は全く考えられていない．

4. 環境知能とユーザインタフェース

環境知能[Nakashima 10]とは，環境にセンサやアクチュエータを埋込み，環境の状態を把握しながら，人間の活動を知的に支援する仕組みのことである．SAVSでは全車輌の位置情報が GPSによって特定され，システムにシェアされていることが前提である．これは環境知能のインフラとしての最低限のことである．環境知能の観点から考えると，さらに二つの方向性が見える．一つは環境からの情報を利用してSAVの運行効率を上げること，もう一つはSAVをセンサやアクチュエータとして使うことである．以下，順に議論する．

3

(4)

4.1 実世界インタフェース

ランデブー機能の実現には環境の助けが必要である．乗客にSAVの位置を知らせるには，現状では端末上の地図表示くらいしか手段がないが，将来的には以下のことが考えられる： • 乗客の位置さえ同定できれば，車の側は様々な装置が使えるので楽である．たとえばヘッドアップディスプレーでユーザを指示することも可能であろう．ユーザ側の表示には一工夫が必要である． • Appのボタンを押すとSAVの屋根の表示灯が点滅する． ITSで開発されるつある近距離通信を使うと実現可能である． • 拡張現実の利用．SAVが視野に入っている場合，端末の画面をかざすとSAVがハイライトされる．これも近距離通信を使うか，SAVに光（赤外線）デジタル通信装置を積むことで実現できる．なお，拡張現実を使えば，SAVの停車場所を画面に指示し，乗客を誘導することも可能であるから，多数の停留所を設置するフレックスルート方式[田柳13]の運行にも便利である．

4.2 交通状況のアクティブセンシング

SAV自体がプローブカーとして使える．函館市街地は100 平方km程度の広さだが，そこに1000台程度のSAVが走ると想定している．平均して1平方kmあたり10台の車が走ることになるので，各道路の混み具合などが実時間でセンシング可能である．さらに，一部の車メーカーがサポートしている，ABS作動状況などをシェアすることができれば，雨や雪などの路面状況も把握できる[秋山11]．中越沖地震や東北沖地震で道路の通行可能性をカーナビデータから表示したマップ [秦09,野田12]は有名であるが，これと同等のものがSAV運行時に作成できるし，通過時間を表示すれば混雑度もわかる．また，SAVが交通状況を刻々とレボートするので，信号制御の実時間制御も都市規模で実行できる．現状でそれを実行しようとすると各交差点に車両通過センサーを設けるなどの必要があり，インフラのコストが高くなるが，SAVを使えばそれらが不要となり，交通状況の安価なセンシングが可能となる．都市部では幹線道路のスルーバンド（自動車が信号機に妨げられずに走りぬけることができる時間の帯）最大化の研究が行われているが，SAVの場合は1台の車輌が複数の交差点を連続的に通過する状況が把握できるので，各交差点で個別にセンシングする方式（個々の車輌の動向はカメラによるナンバー読み取りなどを行わないと同定できない）より容易に，実時間で制御できる．さらに，SAVは中央制御で運行されるため，受動的に情報を収集するだけではなく，それを運行に反映できる．つまり両方向の情報経路が存在しているのが強みである．たとえば， SAVを積極的に状況観察に使うこともできる．道路状況が不明の場所を意図的に走らせたり，火事や事故の情報が入ったときに近くのSAVを現場に向かわせて情報を得たり，運送などの救援行動をとらせたりすること等が可能である．

5. 今後の予定

現在，この論文が発表される人工知能学会国内大会期間中のSAVSサービス提供の準備中である．アプリのユーザインタフェースの向上を計ると共に，必要となる車両台数を見積もるシミュレーションを行っている．学会参加者だけを対象に，函館市中心部と空港やトラピスチヌス修道院を結ぶエリアで，毎分1件（1時間に60件）のデマンドがランダムに発生した場合は30台，2分に1件だとすると20台程度の車両で良さそうであるとの感触を得ている．これらの見積もりの正確性や実験結果は大会終了後にまとめて報告したい．この実験を最後に，技術的課題はほぼクリアできると考えているので，続く課題は実装である．我々としては地元函館で実現したいのだが，それが無理な場合は，もう少し小さな都市での実現を考えたい．また，本論文で述べた環境知能の利用の実装については，それ以降の課題と考えている．最終的にはインターネットの移動サービス版を都市に作り上げたい．

参考文献

[Nakashima 10] Nakashima, H., Aghajan, H., and Au-gusto, J. C. eds.: Handbook of Ambient Intelligence and Smart Environments, Spirnger (2010)

[野田08] 野田五十樹, 篠田孝祐,太田正幸,中島秀之：シミュレーションによるデマンドバス利便性の評価,情報処理学会論文誌, Vol. 49, No. 1, pp. 242–252 (2008) [NTT東] NTT 東日本：デマンド交通システム, http://www.ntt-east.co.jp/business/solution/ transport/index.html [秋山11] 秋山聡：ITSにおける日本の新たな取り組み状況, Technical report,国土技術研究センター(2011) [小柴14] 小柴等,野田五十樹,平田圭二,佐野渉二,中島秀之：Smart Access Vehiclesの社会実装–シミュレーションを通じた分析と実証–,情報処理学会研究報告知能システム(ICS), Vol. 2014-ICS-174, No. 1, pp. 1–8 (2014) [松原13] 松原仁,中島秀之,平田圭二,佐野渉二：新しい都市型公共交通サービスのデザイン,サービス学会第一回国内大会, pp. 304–307 (2013) [秦09] 秦康範,鈴木猛康,下羅弘樹,目黒公郎, 小玉乃理子：新潟県中越沖地震における通れた道路マップの提供とプローブカー情報の減災利用実現に向けた課題と展望,日本地震工学会論文集, Vol. 9, No. 2, pp. 148–159 (2009) [大和08] 大和裕幸, 稗方和夫, 坪内孝太：オンデマンドバスのためのリアルタイムスケジューリングアルゴリズムとシミュレーションによるその評価,運輸政策研究, Vol. 10, No. 4, pp. 2–10 (2008) [中島14] 中島秀之, 小柴等, 佐野渉二, 白石陽：Smart Access Vehicleシステムの実装, in DICOMO 2014 (2014) [坪内09] 坪内孝太, 大和裕幸, 稗方和夫：過疎地における時間指定のできるオンデマンドバスシステムの効果,日本ロボット学会誌, Vol. 27, No. 1, pp. 115–121 (2009) [田柳13] 田柳恵美子,中島秀之,松原仁：デマンド応答型公共交通サービスの現状と展望,人工知能学会全国大会 2J4-OS-13a-1, pp. 1–4 (2013) [野田12] 野田五十樹：災害救助支援のための情報共有プラットフォーム, Synthesiology, Vol. 5, No. 2, pp. 113–125 (2012)