Passenger-Centered Design #2: Experiments

自動運転の現場で、Passenger App はどう設計されたか

シリーズ目次

• 第一章｜背景 — なぜ Passenger-Centered Design が必要になったのか
• 第二章｜実験 — 自動運転車両における Passenger App の実装と試行
• 第三章｜今後 — Passenger App と乗車体験のこれから

Passenger Screen から Passenger App へ

「Passenger Screen」という呼称は、Waymo がロボタクシーにおいて採用している、乗客向けスクリーンの呼び名である。本章では、その開発に携わる立場として、以降これを Passenger App と呼ぶことにする。

Passenger App は、単なる表示装置ではない。

自動運転車両における「乗車体験」を、走行中の時間に限定して担うインターフェースである。

Waymo と Tesla に見る Passenger App

Passenger App という観点で、近年とくに注目を集めているのが、米国 Tesla の Robotaxi だ。

自動運転のロボタクシーといえば Waymo を思い浮かべる人が多いかもしれないが、両社の Passenger App を見比べると、いくつか興味深い共通点がある。

Waymo の車両は、運転席のある既存車両をベースに自動運転用へと改造している。一方、Tesla は Robotaxi 専用車両として、運転席そのものを持たない車両を構想している。

ただし、Tesla は専用車両に加えて、現行の量産車（運転席のある車両）でも Robotaxi の運行を行っており、その場合の Passenger App は Waymo のそれと驚くほどよく似ている。

極端にシンプルな UX

Waymo と Tesla（運転席あり車両）の Passenger App を見比べると、基本構成はほぼ共通している。

• 後部座席の乗客向け
• センターコンソール付近に約10インチ以下のディスプレイ
• UI は極めてシンプル
• 乗車後に行う操作は、ほぼ一つだけ

乗客は「Go Ride」をタップする。それだけで走行が始まる。この極端にシンプルなUXは、Passenger App 単体で成立しているわけではない。

モバイルアプリとの役割分担

このUXが成立している背景には、両社ともに 専用のモバイルアプリを用意している点がある。

• ユーザー登録
• 目的地の指定
• 支払い

これらはすべて 乗車前にモバイルアプリ側で完結する設計になっている。

言い換えれば、Passenger App は「走行中の体験」に役割を限定されたインターフェースだ。乗車してからユーザー登録をしたり、目的地を指定したりすることはできない。

Passenger App は、モバイルアプリと組み合わせて初めて成立する存在なのである。

日本の自動運転における「乗車体験」の所在

では、日本の自動運転の現場において、この《乗車体験》を担っているのは誰なのだろうか。自動車OEM、自動運転システムの開発会社、サービス運行会社という役割分担で見た場合、

乗客（ユーザー）にもっとも近い立場にいるのは、明らかにサービス運行会社だ。

少し前であれば、これを MaaS オペレーターと呼んでいたかもしれない。しかし、この MaaS オペレーターという立場で、乗車体験を一気通貫で設計することは、実際にはきわめて難しい。

分断された役割構造

日本の自動運転では、役割が細かく分断されている。

• 車両の提供：自動車OEM
• 自動運転システムの提供：開発会社
• サービス運行：MaaS オペレーター（事業会社）
• 運転・運行管理：交通事業者
• 最終責任：地方自治体（行政）

この構造の中には、「乗車体験全体」を最初から最後まで見渡し、設計できる役割が存在しない。誰もが部分最適を担っている一方で、体験の全体最適を引き受ける主体がいないのである。

実証実験とサービス運行のギャップ

実際、MaaS オペレーターの主な役割は、すでに存在する自動運転車両やモバイルアプリを活用し、どうやってサービスとして成立させ、マネタイズするかを検討することにある。

その結果、

• 多少使いにくくても既存アプリで代用
• 車両はラッピングで対応

といった対応に留まるケースが多い。

実証実験とサービス運行の間には、マーケティング用語で言えば「キャズム」と呼べるほどのギャップが存在している。

ロボバスでの実験

全国各地で運行されているロボバス（自動運転レベル2・運転手あり）では、バス運転席裏のキャビンモニターに Passenger App を表示した。

Passenger App の利用者は、もちろん乗客である。

一方で、開発フェーズでは、自動運転システム Autoware の挙動を確認するために、検知対象を可視化する開発者向けアプリ RViz を常用している。

実証実験と称して一般試乗を行う場合でも、多くの現場ではこの RViz がそのまま表示されている。

Passenger App を搭載するということは、「開発者向けではない表示」に切り替えるという意思表明でもある。しかし実証実験では、解析と改善を優先するため、開発者向け表示のまま運行されるのが実態だ。

ロボタクシーでの実験

特定エリアを周回するロボタクシー（自動運転レベル2・運転手あり）では、後部座席モニターに Passenger App を表示した。

バスと異なり、タクシーでは乗客が操作する前提となるため、

• 目的地の設定・キャンセル
• 音声対話による操作

といった機能を実装した。

音声対話エンジンには OpenAI Whisper を活用し、自然言語での対話を試みた。

操作と自動運転プロセスのズレ

実験を通じて明らかになったのは、乗客が想定する操作フローと、自動運転の実際の実行プロセスとのズレだ。

想定されがちなフロー

• 目的地設定 → 発進

実際のフロー

• 目的地設定→ ルート設定→ Autoware での自動走行開始→ 車両側での自動走行開始→ 発進

さらに実際には、人為的な安全確認や操作が加わる。このプロセスに呼応して、

• どのタイミングで
• どの情報を
• どの粒度で表示するか

を設計しなければ、乗客は「なぜ動かないのか」「何が起きているのか」を理解できない。

---

第二章｜まとめ

• Passenger App は、モバイルアプリと役割分担することで成立するインターフェースである
• 日本の自動運転開発では、役割分断により乗車体験を一気通貫で設計しにくい
• Passenger App は、技術と乗客体験をつなぐ「翻訳装置」として機能する

次章では、これらの実験を踏まえ、Passenger App を今後どのように位置づけるべきかを整理する。