なぜ自動運転には「パッセンジャー中心設計」が必要なのか
20世紀最大のプロダクトである自動車が、自動運転を備えるということは、その移動体験そのものを、利用者に委ねることにほかならない。
本記事の構成
本記事は、Passenger-Centered Design という考え方を、背景・実験・今後 の三章構成で整理している。
- 第一章｜背景 — なぜ Passenger-Centered Design が必要になったのか
- 第二章｜実験 — 自動運転車両における Passenger App の実装と試行
- 第三章｜今後 — Passenger App と乗車体験のこれから
第一章｜背景
なぜ Passenger-Centered Design が必要になったのか
2017〜2019年ごろ、私は 日産自動車 でUXデザイナーとして働いていた。当時、EVのドライバー向けディスプレイを大型化していく方向性に、強い違和感と異論を感じていた。
UX調査の結果から明らかだったのは、運転中、ドライバーはディスプレイをほとんど見られないという事実だ。操作性を担保するためにタッチパネルを採用するが、車両制御に関わる部分では、やはりタッチ操作は怖い。その結果、物理ボタンを併用せざるを得なくなる。
UIデザインの観点で見ると、こうした諸条件を前提に「大型化していくディスプレイに、何を表示するべきか」という問いが立ち上がる。いわゆる埋め草的な発想も相まって、表示要素を無意味に拡大したり、装飾的なあしらいを追加したりする方向にしか進まない。
ビジネスの観点では、当時いわゆるカーナビがオプション品としてほぼ唯一の商材であり、その領域に大きく手を入れられないという背景もあった。
2025年現在、私は自動運転車両および車両に関わるHMIデザインに加え、DesignOps（DevOps）にも携わっている。
日本の自動運転開発の現場では、「自動運転」といっても、まずは人手不足が深刻なバス領域を対象に、政府と共同で展開されるケースが多い。技術的なアプローチとしては、米国の Waymo に倣ったルールベースが中心となり、モジュール型の自動運転システムを Autoware（オープンソース）として展開している。
一方で、米国の Tesla は、カメラセンサーを中心に、人間が運転した走行データを用いて単一のAIで処理するアプローチを採っており、思想そのものが異なる。
そのなかで、HMIやUXをどう設計するのかが、現在の私の主戦場になる。
ただし、日本の自動運転開発の現場では、実証実験を行うための車両改造という側面が中心であり、一般向けのサービス運行とはフェーズがやや異なる。
実際のサービス運行は、交通事業者や事業会社が担うため、我々はそのサポートという位置づけになる。サービス展開そのものに、直接関わることは少ない。
たとえば、一般にサービス運行している車両、いわゆる自動運転バスは、もともと我々のような車両開発会社や、自動車OEMから納品される。その後、サービス向けにさらに改造されることがほとんどだ。そのため、一般の人が目にする車内外のサイネージ類（ディスプレイ）、車両の塗装やラッピング、料金箱などの設備は、サービス事業者が取り扱う領域になる。
つまり、実証実験と称して目にする車両の多くは、開発用車両と言っていい。一般向けの利用体験が十分に考慮されているとは言い難い。
それでも、実証実験として一般試乗が行われ、ニュースや報道を通じて目にすれば、「これが自動運転か」という印象が社会に残る。もちろん、技術として優れている部分を体験してもらうことは重要だ。しかし、私が大事にしたいのは、見た目や第一印象だけではなく、一気通貫した「乗車体験」として完成していることを感じてもらうことだ。
これまで車両開発における「乗車体験」は、基本的にドライバー中心で設計されてきた。どうすれば運転しやすいか、どうすれば運転の妨げにならないか。それが設計の中心だった。冒頭に述べた日産での経験は、まさにその過渡期にあったと言える。
- 「自動運転になるから、ドライバーはハンドルから手を離せるはずだ」
- 「自動運転になるから、ドライバーは前方から目を離せるはずだ」
- 「それなら、ドライバーが目にするディスプレイも大きくていいはずだ」
- 「ドライバーが運転以外の余暇時間をどう使うか」
こうした議論の延長線上には、「余暇時間＝エンタメ」という単純化された論理構造があった。この考え方は、今もなお健在だと思う。
ただ、個人的にもっとも腑に落ちた理解は、別のところにあった。
「自動運転になるから、ドライバーがいなくなる」
という事実だ。
つまり、車両の利用者という観点で見れば、「ドライバー（運転者）」ではなく、「パッセンジャー（乗客）」しか存在しなくなる。この視点の転換こそが、私にとっては青天の霹靂だった。
こうした視点で、現在販売されている車両――特にHMIを見渡してみると、やはりパッセンジャー（乗客）がほとんど考慮されていないことに気づく。
ただし、それは自動車OEMが「乗客を無視している」という単純な話ではなく、現時点の自動運転を取り巻く現実が、そもそもドライバー中心設計を強く要請している面もある。
- 運転席のない車両は、日本ではほぼ存在しない。（例：TOYOTA e-Palette、Navya など）
- 海外では、いわゆる “トースター（toaster）” と呼ばれる、向かい合わせに座る車両コンセプトが一部に存在する。ただし、まだ限定的な事例にとどまっている。（例：Zoox、WeRide など）
- そして何より、「自動運転」と呼ばれる運用の多くは、現状では運転席のある車両でしか走行できない。少なくとも社会実装の主流はそこにある。
この前提に立てば、自動車OEMが販売している車両の多くが、ハンドルを備えた車両であるのは当然であり、結果としてそのデザインは必然的にドライバー中心になる。
ドライバーが操作しやすい位置に、ドライバーにとって有益な情報を配置し、インフォテインメントの延長線上でHMIが設計される。これは、これまでの自動車設計としては極めて自然な帰結だ。
しかし、その延長で本当にパッセンジャーの体験は成立しているのだろうか。
近年、運転席から助手席まで拡大したパノラマディスプレイを設置した車両を目にする機会も増えた。しかし、それが誰のためのディスプレイなのか。明確に説明できる人に、私はほとんど出会ったことがない。
多くの場合、それはインフォテインメントの表示サイズを単純に拡張したものに過ぎず、パッセンジャーにとってどんな意味を持つのかまで、十分に考えられているとは言い難い。
私がここで言っている Passenger Screen とは、単に「大きなディスプレイ」のことではない。ロボタクシーでいえば、後部座席に座る乗客のために用意された、情報表示と、限定的な操作のためのインターフェースである。
それは、運転を補助するための画面でも、ドライバーの余暇時間を埋めるためのエンタメ画面でもない。「いま、どこにいて、これからどうなるのか」「この乗車体験は、何を前提に成立しているのか」そうした不安や疑問に対して、最小限かつ適切に応答するためのスクリーンだ。
それは、自動運転車両にとっても、そして自動運転車両に乗るパッセンジャーにとっても、極めて重要なインターフェースだと考えている。
自動運転になると、文字どおり「自動で」車両が走行する。しかし、だからこそ、いまどこを走っているのか、どこに向かっているのかは、可視化されなければ分からない。
運転主体が人間でない以上、乗客は状況を身体感覚として把握できないからだ。その不安を解消するために、まず必要になるのが、「次の停車場所」や「到着予定」といった、移動の文脈を理解するための情報である。
だが、自動運転車両では、それだけでは十分ではない。乗客が本当に知りたいのは、「どこへ行くか」だけではなく、「なぜ安心して乗っていられるのか」という点にある。
そのためには、車両が何を検知し、どのように判断して走行しているのか――つまり、自動運転システムがどのように世界を見ているかを、適切に可視化する必要がある。
Passenger Screen が担うのは、単なる情報表示ではない。それは、乗客の不安を和らげ、理解を促し、結果として「安心」を育むためのインターフェースだ。
安心は、説明されなければ生まれない。
理解は、可視化されなければ始まらない。
Passenger Screen とは、自動運転という見えない技術と、乗客の体験とをつなぐ、もっとも人間側に近い接点なのである。
第一章｜まとめ
- 自動運転によって、車両の利用者は「ドライバー」ではなく「パッセンジャー」だけになる
- 従来のドライバー中心設計では、自動運転時代の乗車体験を説明しきれない
- Passenger-Centered Design は、この視点の転換から立ち上がる設計態度である
次章では、Passenger-Centered Design を、実際の自動運転車両における実装と実験を通して検証していく。
※この記事は、Mediumからの転載です。
