WO2023153314A1

WO2023153314A1 - 車内機器制御装置、車内機器制御方法

Info

Publication number: WO2023153314A1
Application number: PCT/JP2023/003449
Authority: WO
Inventors: 健史山元; 清貴田口; 静香横山
Original assignee: 株式会社デンソー
Priority date: 2022-02-09
Filing date: 2023-02-02
Publication date: 2023-08-17
Also published as: JP2023116247A

Abstract

ＨＣＵは、ドライバが運転状態である状況において、操作制限対象に設定されている画面を表示する操作を受け付けた場合、操作制限の対象となるボタンをトーンダウンさせた態様で制限対象画面を表示するとともに、新たに表示した画面に予め対応付けられている問い合わせメッセージを音声出力する。そして、音声認識機能を自動的に有効化し、ドライバの回答を取得する。ＨＣＵは、現在表示中の制限対象画面のＩＤからドライバが使用したい機能である対象機能を推定し、対象機能の推定結果とドライバの回答とを組み合わせることで、実行すべきコマンド（ジョブ）を特定し、実行する。

Description

車内機器制御装置、車内機器制御方法

関連出願の相互参照

　この出願は、２０２２年２月９日に日本に出願された特許出願第２０２２－０１８９４４号を基礎としており、基礎の出願の内容を、全体的に、参照により援用している。

　本開示は、乗員の手で操作される入力装置である操作デバイスからの信号に基づいて車内機器の動作を制御する技術に関する。

　タッチパネルやタッチパッドなどといった操作デバイスからの信号をもとに、車載ディスプレイに表示されているボタンに対する乗員の選択操作を検出し、経路案内の開始や音楽再生など、乗員の操作内容に応じた機能を実行する車内機器制御装置がある。

　このような車内機器制御装置においては、特許文献１に開示されているように、安全性向上を目的として、車両走行中は一部のボタンを乗員が選択できない態様で表示する、いわゆる操作制限機能が搭載されていることがある。

特開２０１６－２４５７９号公報

　近年は音声入力により、発話された内容に応じた機能を実施する車内機器制御装置も導入されつつある。音声入力方式によれば、乗員はシステムへの指示入力のためにディスプレイの表示内容を確認する必要がない。故に、走行中の指示入力手段としては、音声入力方式は好適である。しかし、現在一般的に使用されている音声入力では、リクエストフレーズとして、例えば「ＸＸさんに電話をかけて」や「ＸＸ駅を目的地に設定して」など、少なくとも乗員が利用したい機能を示す動詞句と、その目的語とを含むフレーズを発話する必要がある。また、乗員は音声入力を開始する際には、トークスイッチを押下したり、ウェイクワードを発話したりする必要もある。

　加えて、走行中の車内では、駆動源の動作音や、車内音楽、車外からのノイズ、同乗者の声など多様なノイズがある。当該ノイズによって乗員の発話内容を正しく認識できず、その結果として乗員の希望する機能を実施できないことが起こりうる。

　仮に車内機器制御装置が音声入力に対応している場合であっても、音声認識がうまく作動しない場合や、車内状況、乗員の好みによって、乗員は音声入力ではなく手操作にて指示を入力することがある。手入力方式によれば、乗員の確認のもと利用対象とする機能とその実行条件とが絞り込まれていく。

　そのため、手入力方式では、車内機器制御装置が乗員の希望とは異なる制御／処理を実施してしまう可能性は小さい。ここでの手入力方式とは、ディスプレイに表示したボタンに対する乗員の選択操作に基づいて実行すべき制御を特定する方式である。また、手入力方式は、周りが煩かったり、同乗者が寝ていたりするシーンでも利用しやすいといった利点も有する。しかしながら手入力方式では、機能の実行までに複数回の選択操作が必要となる事が多い。故に、車両の走行に伴う操作制限によって、一連の操作が途中で止まってしまうことがある。

　以上で述べたように、手入力方式と音声入力方式にはそれぞれ長所、短所があるが、これらを複合的に／相補的に用いて乗員が望む制御内容を特定する構成については特許文献１には何ら言及されていない。乗員の指示を取得するための構成としては改善の余地があった。

　本開示は、上記の検討又は着眼点に基づいて成されたものであり、その目的の１つは、乗員の利便性を向上可能な車内機器制御装置、車内機器制御方法を提供することにある。

　ここに開示される第１の車内機器制御装置は、ディスプレイに表示される選択肢に対する乗員の選択操作を受け付けるための操作デバイスからの信号、及び、音声認識によって特定される乗員の発話内容に基づいて車内機器を制御する車内機器制御装置であって、乗員の動き及び視線の少なくとも何れか一方を検出する乗員挙動センサの出力に基づき、運転席に着座している乗員である運転席乗員が、車両を走行させる操作をしている運転状態に該当するか否かを判定することと、操作デバイスからの信号に基づき、ディスプレイの表示画面を制御することと、運転席乗員が運転状態である状況において、操作制限の対象に設定されている画面である制限対象画面を呼び出す操作が行われたことを検出した場合には、当該制限対象画面に応じた、未入力の項目にかかる問い合わせメッセージを出力することと、問い合わせメッセージの出力と同時に又はその後に、音声認識機能を有効化することと、問い合わせメッセージ対する乗員の回答を音声認識により取得できた場合には制限対象画面に対応する機能の範囲において回答に応じた制御を実行することと、を実施するように構成されている。

　上記の車内機器制御装置によれば運転席乗員は、操作制限がかかっている状態においても、問い合わせメッセージに対して機能の実行にかかる希望の条件を発話することにより、所望の制御を実行させることができる。また、乗員の回答に基づいて上記装置が実行する機能の種別は、表示中／表示しようとしている画面に対応する機能であって、乗員が画面を見ながら選択した選択肢に対応するものである。そのため、乗員の回答に基づいて上記装置が実行する機能の種別は、操作者としての乗員の意図に沿っている可能性が高い。つまり上記構成によれば、乗員の意図しない制御を実施する恐れを低減できる。

　加えて、実行させる機能の種別は表示中／表示しようとしている画面に基づいて自動的に特定されるため、乗員は実行させたい機能にかかる動詞句を発話しなくとも良い。加えて、音声認識機能は自動的に有効化されるため、ウェイクワードを発話したり、トークスイッチを押下したりする必要もない。上記構成によれば、乗員の発話量を抑制できる。すなわち、上記構成によれば、より少ない発話量で、より精度良く所望の機能を実行させることが可能となるため乗員の利便性が向上しうる。

　また、本開示に含まれる第２の車内機器制御装置は、ディスプレイに表示される選択肢に対する乗員の選択操作を受け付けるための操作デバイスからの信号、及び、音声認識によって特定される乗員の発話内容に基づいて車内機器を制御する車内機器制御装置であって、乗員の動き及び視線の少なくとも何れか一方を検出する乗員挙動センサの出力に基づき、運転席に着座している乗員である運転席乗員が、車両を走行させる操作をしている運転状態であるか否かを判定することと、ディスプレイに表示している画面、又は、乗員によって選択された選択肢の情報に基づいて、現在の操作状態が所定の機能を実行させるための一連の操作の途中に該当するか否かを判定することと、操作状態が一連の操作の途中である状況において、運転席乗員が運転状態に移行したことに基づいて、現在の表示画面に応じた、未入力の項目にかかる問い合わせメッセージを出力することと、問い合わせメッセージの出力と同時に又はその後に、自動的に音声認識機能を有効化することと、問い合わせメッセージ対する乗員の回答を音声認識により取得できた場合には現在の表示画面に対応する機能の範囲において回答に応じた制御を実施することと、を実行するように構成されている。

　上記の第２の車内機器制御装置によれば、操作の途中で運転操作を開始した場合であっても、音声にて未入力の項目を入力することができ、所望の制御を実行させることができる。また、第１の車内機器制御装置と同様の理由により、第２の車内機器制御装置によれば、より少ない発話量で、より精度良く所望の機能を実行させることが可能となる。

　本開示の車内機器制御方法は、ディスプレイに表示される選択肢に対する乗員の選択操作を受け付けるための操作デバイスからの信号、及び、音声認識によって特定される乗員の発話内容に基づいて車内機器を制御する車内機器制御装置であって、乗員の動き及び視線の少なくとも何れか一方を検出する乗員挙動センサの出力に基づき、運転席に着座している乗員である運転席乗員が、車両を走行させる操作をしている運転状態であるか否かを判定することと、操作デバイスからの信号に基づき、ディスプレイの表示画面を制御することと、運転席乗員が運転状態である状況において、操作制限の対象に設定されている画面である制限対象画面を呼び出す操作が行われたことを検出した場合には、当該制限対象画面に応じた、未入力の項目にかかる問い合わせメッセージを出力することと、問い合わせメッセージの出力と同時に又はその後に、音声認識機能を有効化することと、問い合わせメッセージ対する乗員の回答を音声認識により取得できた場合には制限対象画面に対応する機能の範囲において回答に応じた制御を実行することと、を含む。

　上記方法は、第１の車内機器制御装置に対応する方法であって、第１の車内機器制御方法と同様の作用により同様の効果が得られる。

　なお、請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

車載システムの全体像を示すブロック図である。インパネディスプレイの一例を示す図である。ＨＣＵに連なる操作デバイスの一例を示す図である。ＨＣＵの機能ブロック図である。ホーム画面の一例を示す図である。制限対象画面の一例を示す図である。制限対象画面に設定されうる画面を説明するための図である。コマンド入力支援処理のフローチャートである。コマンド入力支援処理の他の例を示すフローチャートである。変形例におけるＨＣＵの機能ブロック図である。コマンド入力支援処理の他の例を示すフローチャートである。変形例におけるＨＣＵの作動を説明するための図である。変形例におけるＨＣＵの作動を説明するための図である。音声認識インジケータの一例を示す図である。ＨＣＵの作動の一例を示す図である。ＨＣＵの作動の一例を示す図である。ＨＣＵの作動の一例を示す図である。ＨＣＵの作動の一例を示す図である。ＨＣＵの作動の一例を示す図である。ＨＣＵの作動の一例を示す図である。ＨＣＵの作動の一例を示す図である。

　以下、車内機器制御装置及び車内機器制御方法の実施形態について図を用いて説明する。図１は、車内機器制御装置が適用された車載システムＳｙｓの概略的な構成の一例を示す図である。本開示は、車載システムＳｙｓが使用される地域の法規及び慣習に適合するように適宜変更して実施可能である。

　＜前置き＞
　本開示は、乗用車に限らず、タンクローリーやトラックなど、道路上を走行可能な多様な車両に適用可能である。以降では車載システムＳｙｓが搭載されている車両を自車両とも記載する。自車両は、個人によって所有されるオーナーカーであってもよいし、シェアカーや、レンタカーであってもよい。自車両は電動車である。もちろん、自車両は、エンジン車であってもよい。電動車の概念には、電気自動車のみならず、プラグインハイブリッド車や、ハイブリッド車、燃料電池車を含めることができる。

　車載システムＳｙｓは、別途後述する自動運行装置１７を備えることにより、自車両を所定の経路に沿って自律的に走行させる、いわゆる自動運転を実施可能に構成されている。本開示におけるドライバとは、実際に運転操作を実施している人物に限らず、自動運転終了時に車載システムＳｙｓから運転操作の権限を受け取るべき人物を指しうる。つまり本開示におけるドライバとは、実際に運転しているか否かに関わらず、運転席に着座している人物、つまり運転席乗員を指す。本開示におけるドライバとの記載は運転席乗員と置き換えることができる。

　また、本開示では車室内に存在する人物を座席に応じて区別しない場合、単に乗員と記載する。乗員には、ドライバの他、助手席に着座している人物である助手席乗員や後部座席に着座している人物を含みうる。乗員との記載はユーザと読み替えることができる。本開示におけるＤ席との記載は運転席を指し、Ｐ席とは助手席を意味する。以下に述べるＤ席用マイクとは、運転席用マイクを指す。その他、インストゥルメントパネル（ダッシュボード）のことを本開示では適宜、インパネとも省略して記載することがある。

　＜車載システムの構成＞
　図１に示すように車載システムＳｙｓは、車両状態センサ１１、周辺監視センサ１２、乗員見守りカメラ１３、無線通信機１４、ナビゲーション装置１５、オーディオ装置１６、及び自動運行装置１７を備える。また、車載システムＳｙｓは、ＨＵＤ２１、インパネディスプレイ２２、操作デバイス２３、Ｄ席スピーカ２４ａ、Ｐ席スピーカ２４ｂ、Ｄ席マイク２５ａ、Ｐ席マイク２５ｂ、トークスイッチ２６を備える。さらに、車載システムＳｙｓは、ＨＣＵ（HMI Control Unit）３０を備える。ＨＭＩは、ヒューマンマシンインターフェース（Human Machine Interface）の略である。ＨＵＤは、ヘッドアップディスプレイ（Head-Up Display）の略である。

　車両状態センサ１１は、車両の状態に関する情報を検出するセンサである。車速センサ、操舵角センサ、シフトポジションセンサ、ブレーキペダルセンサ、アクセルペダルセンサ、ステアリングセンサ等が車両状態センサ１１に該当する。車速センサは、自車の車速を検出する。操舵角センサは、操舵角を検出する。シフトポジションセンサは、シフトポジションを検出する。ブレーキペダルセンサは、ドライバによるブレーキペダルの踏込量／踏込力を検出するセンサである。アクセルペダルセンサは、ドライバによるアクセルペダルの踏込量／踏込力を検出するセンサである。ステアリングセンサは、ドライバがステアリングホイールを把持しているか否かを示す信号を出力するセンサであって、静電容量式のタッチセンサであってよい。ステアリングセンサは、操舵トルクを検出するセンサであっても良い。アクセルペダルセンサやブレーキペダルセンサ、ステアリングセンサはドライバの挙動を検出するセンサ、換言すれば乗員挙動センサの一種に相当する。

　車両状態センサ１１は、検出対象とする項目の現在の値／状態を示す信号をＨＣＵ３０に出力する。車両状態センサ１１として車載システムＳｙｓが備えるべきセンサの種類は適宜設計されればよい。車載システムＳｙｓは、上述した全てのセンサを備えている必要はない。また、車載システムＳｙｓは上記以外のセンサを車両状態センサ１１として備えていても良い。座席ごとの着座センサやシートベルトセンサも車両状態センサ１１に含めることができる。着座センサは、人間が着座していることを検知するセンサであって、着座面に埋設された圧力センサである。シートベルトセンサはシートベルトの装着状態に応じた信号を出力するセンサである。着座センサやシートベルトセンサの出力信号は、助手席乗員がいるか否かの判断材料となりうる。着座センサやシートベルトセンサは助手席乗員の有無を判断するための車載センサの一種に相当する。

　周辺監視センサ１２は、自車両の周辺環境を監視する自律センサである。周辺監視センサ１２は、自車両周囲の検出範囲から予め規定された移動物体及び静止物体を検出する。車室外を撮像するカメラや、ミリ波レーダ、ＬｉＤＡＲ、ソナーなどが周辺監視センサ１２に該当する。ＬｉＤＡＲは、Light Detection and Ranging、又は、Laser Imaging Detection and Rangingの略である。車載システムＳｙｓは、周辺監視センサ１２として、車両前方を所定の画角で撮像するように配置された、前方カメラを備える。前方カメラは、フロントガラスの車室内側の上端部や、フロントグリル、ルーフトップ等に配置されている。前方カメラは、画像フレームに対して認識処理を施すことで、歩行者や、他車両などの移動体を検出する。また、前方カメラは、信号機及びその点灯状態も検出しうる。周辺監視センサ１２の検出結果はＨＣＵ３０に入力される。

　乗員見守りカメラ１３は、可視光／赤外線カメラであって、少なくともドライバの顔部を撮像可能な位置および姿勢で車室内に配置されている。乗員見守りカメラ１３は、運転席のヘッドレスト部に光軸を向けた姿勢にて、ステアリングコラムカバーの上面や、インストゥルメントパネルの上面、フロントガラスの上端部等に配置されていてよい。

　乗員見守りカメラ１３は、撮影映像に含まれるドライバの顔画像に基づいてドライバの状態を逐次検出する。乗員見守りカメラ１３は、ドライバの状態として、ドライバの顔の向きや視線方向、瞼の開き度合い（いわゆる開眼度）等を逐次検出しうる。乗員見守りカメラ１３は、ドライバの姿勢やステアリングホイールの把持状態、操作デバイス２３を操作しているか否かを検出可能に構成されていてもよい。乗員見守りカメラ１３は、撮影画像から特定したドライバの状態を示す情報をドライバ状態データとしてＨＣＵ３０へ逐次出力する。なお、カメラの映像信号に基づきドライバ等の状態を検出する機能は、ＨＣＵ３０が備えていても良い。

　なお、乗員見守りカメラ１３は、助手席乗員の顔部を撮像可能なようにインストゥルメントパネルの車幅方向中央部に配置されていてもよい。乗員見守りカメラ１３は、フロントガラスの上端部や、オーバーヘッドコンソールなどに設けられていても良い。乗員見守りカメラ１３は、助手席乗員の有無、及び、助手席乗員が存在する場合にはその姿勢や、操作デバイス２３を操作しているか否かを検出可能に構成されていてもよい。乗員見守りカメラ１３は複数あってもよい。乗員見守りカメラ１３は、座席ごとに配置されていても良い。助手席を撮像範囲に含む乗員見守りカメラ１３もまた助手席乗員の有無を判断するための車載センサに該当しうる。また、乗員見守りカメラ１３は、乗員挙動センサに相当しうる。

　無線通信機１４は、自車両が他の装置と無線通信を実施するための装置である。無線通信機１４は、セルラー通信を実施可能に構成されている。セルラー通信とは、ＬＴＥ（Long Term Evolution）や４Ｇ、５Ｇなどの規格に準拠した無線通信である。ＨＣＵ３０は、無線通信機１４との協働により、音声認識サーバから乗員の発話音声を示すテキストデータ、又は、発話音声に応じたコマンドを取得しうる。無線通信機１４は、道路沿いに設置された通信設備である路側機からの配信データを受信可能に構成されていてもよい。無線通信機１４は、路側機から信号機の点灯スケジュール情報を示す信号を受信した場合には、当該点灯スケジュール情報をＨＣＵ３０や自動運行装置１７に送信してよい。点灯スケジュール情報は、現在の点灯状態（点灯色）や、現在の点灯状態を維持する残り時間、次の点灯色などを示す。

　また、無線通信機１４は、Bluetooth（登録商標）やＷｉ－Ｆｉ（登録商標）などの規格に準拠した通信を実施可能に構成されている。無線通信機１４は、乗員（主としてドライバ）によって車室内にも着込まれた携帯端末である持込端末４０とＨＣＵ３０とが相互通信を実施するためのインターフェースとして機能しうる。持込端末４０は、携帯型の情報処理端末であって、スマートフォンやタブレット端末などである。

　車載システムＳｙｓに持込端末４０が通信接続している場合、ＨＣＵ３０は、持込端末４０の画面をインパネディスプレイ２２に表示したり、持込端末４０にインストールされているアプリケーションを実行したり可能となる。なお、持込端末４０と車載システムＳｙｓとの接続態様は、無線に限らない。持込端末４０と車載システムＳｙｓは、通信ケーブルを用いて接続されても良い。

　ナビゲーション装置１５は、地図データを用いて、現在地周辺の地図画像をインパネディスプレイ２２に表示させたり、現在地から目的地までの走行を案内する経路案内処理を実施したりする。周辺地図の表示や経路案内など、ナビゲーション装置１５が備える機能を本開示ではナビゲーション機能と称する。経路案内を開始するための操作は、目的地の入力操作や、経路候補から実際に採用する経路を選択する操作を含む。目的地の入力時には、検索方法として住所、施設名、電話番号のいずれを使用するかなど、複数の操作が必要となりうる。なお、ナビゲーション機能は、ＨＣＵ３０又は持込端末４０が備えていても良い。

　オーディオ装置１６は、ＨＣＵ３０からの指示に基づいて、ローカルストレージ又はクラウド上に保存されている楽曲データを再生するデバイスである。楽曲データは、メタデータとして、その楽曲データが収録されているアルバムの情報や、アーティスト情報、曲名、演奏時間などを含んでいる。楽曲を再生するための操作は、アーティスト、アルバム、又はジャンルの選択など複数の操作を含みうる。楽曲再生やラジオの受信にかかる機能を本開示ではオーディオ機能と称する。オーディオ機能は、ＨＣＵ３０又は持込端末４０が備えていても良い。

　自動運行装置１７は、周辺監視センサ１２の検出結果などをもとに走行アクチュエータを制御することにより、運転操作の一部又は全部をドライバの代わりに実行する装置である。走行アクチュエータとは、車両の加速、減速、旋回を実施するためのアクチュエータであって、制動装置としてのブレーキアクチュエータや、電子スロットル、ＥＰＳ（Electric Power Steering）モータなどを指す。

　自動運行装置１７は、プロセッサ、メモリ、ストレージ等を備えたコンピュータを主体として構成されている。運転操作の自動化レベルが異なる複数の動作モードを備える。ここでは一例として自動運行装置１７は、完全手動モード、運転支援モード、及び自動運転モードを切替可能に構成されている。自動運行装置１７の動作モードは運転モードと言い換えることもできる。

　完全手動モードは、ドライバがすべての運転タスク（運転操作）を実行する動作モードである。運転支援モードは、自動運行装置１７が加減速及び操舵操作の少なくとも何れか一方をシステムが実行する動作モードである。完全手動モード及び運転支援モードは、ドライバが少なくとも一部の運転タスクを実行する運転モードである。そのため本開示では、完全手動モード及び運転支援モードを区別しない場合には乗員関与モードとも記載する。乗員関与モードは、自動運転モードの対義語としての手動運転モードと呼ぶこともできる。

　自動運転モードは、所定の運行設計領域（ＯＤＤ：Operational Design Domain）内に車両が存在することを条件として、システムがすべての運転タスクを実行する動作モードである。本実施形態の自動運行装置１７は、自動運転として、緊急時にはシステムからドライバに運転交代を要求する、いわゆる自動化レベル３相当の制御を実施する。

　ＯＤＤは、自動運転を実行可能な条件を規定するものである。ＯＤＤとしては、例えば（ａ）走行路が高速道路又は中央分離帯とガードレール等が整った自動車専用道路であること、（ｂ）降雨量が所定の閾値以下であること、（ｃ）全て／所定数以上の周辺監視センサ１２が正常に動作していること等が挙げられる。自動運転可能／不可と判定する条件、換言すればＯＤＤを定義する詳細条件は、適宜変更可能である。

　もちろん、自動運行装置１７は、自動化レベル４又は５相当の自動運転を実施可能に構成されていても良い。レベル４は、対応不可能な所定の道路、極限環境等の特定状況下を除き、システムが全ての運転タスクを実施するレベルである。レベル５は、あらゆる環境下でシステムが全ての運転タスクを実施可能なレベルである。

　自動運行装置１７の動作モードは、操作デバイス２３に対する乗員の操作又は音声入力に基づき切り替えられる。自動運転モードは、ドライバ操作（いわゆるオーバーライド）の他、システム限界や、ＯＤＤの退出等に起因して終了される。システムからドライバに運転権限を移譲する処理は、アナウンスや画像表示、インジケータの点灯、振動などにてドライバに運転操作を引き継ぐように要求することを含む。このような運転交代の要求処理は、Take-Over Request（ＴＯＲ）又はRequest To Intervene（ＲＴＩ）などとも称される。運転交代の要求を開始してから、運転交代が完了するまでの期間を本開示では運転交代中と称する。自動運行装置１７は、現在の動作モードである現行モードを示す信号をＨＣＵ３０に出力する。また、自動運行装置１７は、運転交代中か否かを示す信号をＨＣＵ３０に出力する。

　ＨＵＤ２１は、ＨＣＵ３０から入力される制御信号及び映像データに基づき、フロントガラスの所定領域に画像光を投影することにより、画像を前方景色に重畳表示する装置である。ＨＵＤ２１は、インストゥルメントパネル内の収容空間に収容されていてよい。

　インパネディスプレイ２２は、インストゥルメントパネルに設けられたディスプレイである。インパネディスプレイ２２は、フルカラー表示が可能なものであり、液晶ディスプレイ、有機ＥＬディスプレイ等を用いて実現されている。インパネディスプレイ２２は、ＨＣＵ３０からの指示に基づいてテキストや画像を表示する。

　本実施形態のインパネディスプレイ２２は、インストゥルメントパネルの上端部において、略右端から略左端まで連続的に形成されている。当該インパネディスプレイ２２は、ピラー・トゥ・ピラー・ディスプレイ、或いは、インパネ全面ディスプレイと呼ぶこともできる。インパネディスプレイ２２は横幅０．６ｍ以上の表示画面を有し、それぞれの異なる機能についての複数の操作画面（ウィンドウ）を並列的に表示可能に構成されている。インパネディスプレイ２２に複数の操作画面が表示されている場合、以降における表示画面／操作画面とは、それらのうち乗員が選択中／作業中の（つまりアクティブな）ウィンドウを指す。

　インパネディスプレイ２２が備える表示画面は、図２に示すように、運転席の正面に位置するＤ席用表示エリアＡ１と、助手席の正面に位置するＰ席用表示エリアＡ２と、それらの間に位置する中央表示エリアＡ３とに区分可能である。Ｄ席用表示エリアＡ１は主として走行速度やシフトポジション、バッテリ／ガソリン残量など、運転操作に必須の情報表示に使用される。中央表示エリアＡ３はドライバ及び助手席乗員の両方が使用／視認可能なエリアであるため、共用エリアと呼ぶこともできる。各表示エリアを区切る明確な境界線は存在せず、ＨＣＵ３０は、２つの表示エリアをまたぐように１つの機能の操作画面（ウィンドウ）を表示することもできる。

　なお、他の態様として、インパネディスプレイ２２はインパネの運転席正面領域に配置されたメータディスプレイであってもよいし、車幅方向中央部分に配置されたセンターディスプレイであっても良い。車載システムＳｙｓは、インパネディスプレイ２２として、それぞれ物理的に独立した複数のディスプレイを備えていても良い。車載システムＳｙｓは、メータディスプレイと、センターディスプレイと、助手席正面に配置されたディスプレイとを備えていても良い。各ディスプレイ／表示エリアに表示する内容はＨＣＵ３０によって制御される。

　操作デバイス２３は、車載システムＳｙｓに対する乗員の指示操作を受け付けるための装置である。操作デバイス２３は、乗員の手指で操作されるデバイスである。車載システムＳｙｓは操作デバイスとして、図３に示すようにタッチパネル２３Ａ、タッチパッド２３Ｂ、及びステアリングスイッチ２３Ｃを備える。タッチパネル２３Ａは、インパネディスプレイ２２に積層されている。タッチパッド２３Ｂは、操作面上における指の操作位置を検出し、インパネディスプレイ２２の画面上に表示されるカーソルＣの移動、及び当該カーソルＣが指し示す対象の選択などを行うポインティングデバイスとして機能する。タッチパッド２３Ｂは、センターコンソールなど、インパネディスプレイ２２とは離れた位置に設けられている。ステアリングスイッチ２３Ｃは、ステアリングホイールに設けられたスイッチである。

　タッチパッド２３Ｂなどは、カーソルＣの移動及び選択操作に反応して操作面を振動させる、触覚フィードバック機能を有していても良い。カーソルＣが背景画像領域からボタン上に移動した時には、タッチパッド２３Ｂは振動アクチュエータを動作させることによって、そのボタンを触ったかのような触覚をドライバの指に付与してよい。

　なお、車載システムＳｙｓは操作デバイス２３として、ジョイスティック型のハプティックデバイスやマウスなどを備えていても良い。また、手や指を特定のパターンで動かしていること（つまりジェスチャー）を検出することで乗員の指示操作を受け付けるジェスチャー／モーションセンサも操作デバイス２３に含める事ができる。操作デバイス２３に対する乗員の操作は、車載システムＳｙｓに対する指示入力と読み替える事ができる。各操作デバイス２３は、乗員が行った操作に対応する電気信号を操作信号としてＨＣＵ３０に出力する。操作信号は、乗員の操作内容を示す情報を含む。

　Ｄ席スピーカ２４ａ及びＰ席スピーカ２４ｂは何れも、ＨＣＵ３０から入力される信号に対応する音を出力するスピーカ２４である。本開示における「音」との表現には、通知音のほか、音声（アナウンス）や、音楽なども含まれる。Ｄ席スピーカ２４ａは、運転席用ドアや、運転席側のＡピラーなど、運転席周りに配置されている。Ｐ席スピーカ２４ｂは、助手席用のドアや、インパネの助手席正面領域、或いは、Ｐ席側のＡピラーなど、助手席周りに配置されている。Ｄ席スピーカ２４ａが運転席用スピーカに相当し、Ｐ席スピーカ２４ｂが助手席用スピーカに相当する。なお、車載システムＳｙｓはＤ席スピーカ２４ａ及びＰ席スピーカ２４ｂの代わりに／それらに加えて、インパネの中央部／オーバーヘッドコンソールに配置された中央スピーカを備えていても良い。

　Ｄ席マイク２５ａ及びＰ席マイク２５ｂは何れも、乗員が発話した音声を、電気的な音声信号に変換してＨＣＵ３０に出力するマイク２５である。Ｄ席マイク２５ａは、ステアリングコラムカバーの上面部や、ステアリングホイールのスポーク部、運転席のヘッドレスト等の、運転席乗員の発話音声を拾いやすい位置に設けられる。Ｐ席マイク２５ｂは、助手席乗員の発話音声を集音するためのマイク２５である。Ｐ席マイク２５ｂは、インパネの助手席正面領域などに配置されている。Ｄ席マイク２５ａが運転席用マイクに相当し、Ｐ席マイク２５ｂが助手席用マイクに相当する。

　トークスイッチ２６は、乗員が音声入力を開始する旨を指示するためのスイッチである。トークスイッチ２６は、ハードウェアスイッチであっても良いし、表示画面内に設けられたボタンであってもよい。

　ＨＣＵ３０は、操作デバイスからの信号及び乗員の発話内容に基づいて、車両内において乗員が利用可能な機能／車内機器の動作を制御する装置である。ＨＣＵ３０は、プロセッサ３１、ストレージ３２、メモリ３３、通信インターフェース３４、及びこれらを接続するバス等を備えたコンピュータを主体として構成されている。プロセッサ３１は、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）等といった、演算コアである。プロセッサ３１は、メモリ３３へのアクセスにより、種々の処理を実行する。ストレージ３２は、フラッシュメモリなどの書き換え可能な不揮発性である。ストレージ３２には、プロセッサ３１によって実行されるプログラムである車内機器制御プログラムが格納されている。プロセッサ３１が車内機器制御プログラムを実行することは、車両制御方法が実行されることに相当する。メモリ３３は書き換え可能な揮発性の記憶媒体であってＲＡＭ（Random Access Memory）である。ＨＣＵ３０が車内機器制御装置に相当する。

　また、ＨＣＵ３０は、ストレージ３２にインストールされているソフトウェアを実行する事により、多様なアプリ３５を実施する。ここでのアプリ３５は機能／サービスと言い換える事ができる。ＨＣＵ３０は、通話アプリや、ウェブブラウザ、動画再生アプリなどを備える。通話アプリは、電話の発着信に関連する機能である通話機能を提供するアプリである。ＨＣＵ３０は、通話アプリを備えることにより、乗員が指定する相手に電話をかける処理を実行可能となる。ウェブブラウザは、無線通信機１４と協働して、インターネットにアクセスし、乗員操作に応じたＷｅｂページを取得し、インパネディスプレイ２２に表示するアプリである。動画再生アプリは、テレビや映画などの動画をインパネディスプレイ２２の所定領域に表示するアプリである。動画再生アプリは、動画配信サービスに対応するアプリであってもよい。

　ナビゲーション機能や、オーディオ機能、通話機能、ウェブ検索機能、動画再生機能などが、車内において乗員が利用可能な機能に該当する。一部の機能は、ナビゲーション装置１５や持込端末４０など、ＨＣＵ３０に接続するデバイスによって提供されうる。ナビゲーション装置１５やオーディオ装置１６、持込端末４０などが車内機器に相当する。車内機器の概念には、ＨＣＵ３０やＨＵＤ２１、インパネディスプレイ２２、スピーカ２４、マイク２５なども含まれる。なお、車載システムＳｙｓは上述した以外にも、車載空調装置の動作設定を変更するための空調機能や、メッセージ／メールの送受信を行うメッセージ機能、ドライバのスケジュールを管理するスケジュール機能などを備えうる。操作デバイス２３を介して乗員が利用可能な機能には、ＡＣＣ（Adaptive Cruise Control）やＬＣＡ（Lane Change Assist）などの運転支援機能を含めることができる。

　＜ＨＣＵの機能について＞
　このＨＣＵ３０は、機能部として図４に示すように、情報取得部Ｆ１、表示制御部Ｆ２、選択操作受付部Ｆ３、操作状態判定部Ｆ４、対象機能推定部Ｆ５、運転状態判定部Ｆ６、音声認識部Ｆ７、コマンド特定部Ｆ８、及びコマンド実行部Ｆ９を備える。これら機能部は、プロセッサ３１が車内機器制御プログラムを実行することにより実現される。もちろん、ＨＣＵ３０が備える機能部の一部又は全部は、ＩＣ（Integrated Circuit）やＦＰＧＡ（Field-Programmable Gate Array）を用いて実現されていてもよい。ＩＣの概念には、ＡＳＩＣ（Application Specific Integrated Circuit）も含まれる。

　情報取得部Ｆ１は、車両状態センサ１１などから、車内機器の制御に必要な多様な情報を取得し、メモリ３３に一時保存する。情報取得部Ｆ１は、車両状態センサ１１から、自車両の走行速度や加速度、ブレーキペダルの操作状態、アクセルペダルの操作状態、操舵状態などといった車両情報を取得する。これらの車両情報は、ドライバが運転状態にあるか否か、運転を開始したか否かの判断材料、及び、操作制限を実施するべきか否かの判断材料として機能しうる。操作制限に関しては別途後述する。

　また情報取得部Ｆ１は、乗員見守りカメラ１３から、ドライバや助手席乗員といった乗員ごとの状態を示す情報を取得する。乗員の状態を示す情報としては、視線方向や、姿勢、手の位置などがある。ドライバの状態を示す情報には、ステアリングホイールを把持しているか否か、前方など車外における進行方向を見ているかなどが含まれる。なお情報取得部Ｆ１は、乗員見守りカメラ１３の映像を解析することで、ドライバや助手席乗員の挙動を検出するように構成されていても良い。本開示における「取得」には、他の装置／センサから入力されたデータなどを元に内部演算によって生成／検出することも含まれる。システム内の機能配置は適宜変更可能であるためである。

　情報取得部Ｆ１は、ＨＣＵ３０に接続している機器（以降、接続機器）から、現在の動作状況等を示す情報を取得する。情報取得部Ｆ１は自動運行装置１７から現在の動作モードや、運転交代中か否かを示す信号を取得する。その他、ＨＣＵ３０は、動作中の接続機器から、インパネディスプレイ２２に表示するための映像データや、スピーカ２４から出力するための音声データを取得しうる。

　表示制御部Ｆ２は、ＨＵＤ２１の表示内容を制御する。表示制御部Ｆ２は、ＨＵＤ２１に現在の車速や、進路を示す矢印画像或いは走行予定軌跡を示す画像などを表示する。ＨＵＤ２１への表示する画像は、ナビゲーション装置１５や自動運行装置１７からの入力信号に基づき調整される。

　また、表示制御部Ｆ２は、インパネディスプレイ２２の表示画面を制御する。表示制御部Ｆ２がインパネディスプレイ２２に表示する種々の操作画面には、画面毎に固有の識別番号である画面ＩＤが設定されている。各操作画面には、乗員によって選択可能な少なくとも１つのボタンを含む。ボタンは、操作画面に含まれる表示要素であって、アイコン、マーク、選択項目などと呼ぶこともできる。ボタンが選択肢に相当する。インパネディスプレイ２２に表示されるボタンには、ボタン毎に固有のボタンＩＤが設定されている。ボタンＩＤは、遷移先画面のＩＤや、機能及び実行条件を構成する要素などと対応付けられている。

　乗員は、インパネディスプレイ２２に表示されているボタンを選択することによって、別の画面に表示させたり、任意のコマンドを実行させたりできる。すなわち、ボタンは、ＨＣＵ３０が乗員の希望する制御内容であるコマンドを特定するための選択肢に相当する。本開示のコマンドとは、対象機能に対応する車内機器が実行するべき制御／処理と解することもできる。コマンドは、アクションやジョブと呼ぶこともできる。

　コマンドは、対象機能と、その実行条件の組み合わせによって特定される。実行条件は、実行パラメータと解することもできる。ナビゲーション機能の実行条件とは、目的地情報である。つまり、ナビゲーション機能においては「どこに」を指定する要素が実行条件に相当する。なお、時間優先や、有料道路優先、距離優先など、経路計算に係る条件、換言すれば、「どうやって」を指定する要素もまた、ナビゲーション機能の実行条件に相当しうる。また、オーディオ機能の実行条件とは、曲名／アルバム名／アーティスト名／ジャンルなどである。通話機能の実行条件とは、電話を掛ける相手（発信先）、すなわち「誰に」に相当する要素である。ウェブ閲覧機能に対応する実行条件とは、検索語である。動画再生機能に対応する実行条件とは、番組名／チャンネル／映画名／カテゴリなどである。

　表示制御部Ｆ２は、最も上位の画面としてホーム画面をインパネディスプレイ２２に表示する。ホーム画面は、乗員が利用する機能を選択するための画面である。ホーム画面は、図５に示すように機能選択ボタンＢ１～Ｂ６を含みうる。機能選択ボタンＢ１～６は何れも、乗員が利用／操作の対象とする機能である対象機能を選択するためのボタンである。

　なお、図５中のＢ１は、ナビゲーション機能の操作画面を呼び出すためのボタンであり、Ｂ２は、オーディオ機能の操作画面を呼び出すためのボタンである。Ｂ３は、通話機能画面を呼び出すためのボタンであり、Ｂ４は、ウェブブラウザ画面を表示するためのボタンである。Ｂ５は、動画再生機能にかかる画面を呼び出すためのボタンであり、Ｂ６は、各種設定を変更するための画面である設定変更画面を呼び出すためのボタンである。各機能に対応するボタンは、アイコンと呼ぶ事もできる。

　表示制御部Ｆ２がインパネディスプレイ２２に表示させる種々の操作画面は、ツリー／階層構造を有する。ホーム画面から分岐する機能毎の画面は、より下位の画面となるに従って、より具体的な実行条件を指定（選択）するための画面となっていく。

　なお、表示制御部Ｆ２は、乗員がボタンを選択するための要素として、画面上における現在の入力位置を指し示すカーソルＣも表示する。図５ではカーソルＣを矢印型としているが、任意の図形や記号を採用可能である。カーソルＣの位置は、タッチパッド２３Ｂなどのポインティングデバイスからの信号に基づいて変更されうる。乗員は操作デバイス２３を操作することによって、表示画面内のカーソルＣを移動させ、所望のボタンを選択できる。もちろん、乗員はカーソルＣを用いることなく、タッチパネル２３Ａを介して直接的にボタンを選択することもできる。

　選択操作受付部Ｆ３は、種々の操作デバイス２３から入力される操作信号に基づいて、インパネディスプレイ２２に表示しているボタンに対する乗員の選択操作を受け付ける。選択操作受付部Ｆ３は、操作デバイス２３からの信号に基づき、表示画面に表示しているボタンに対する乗員の選択操作を検出した場合、その選択されたボタンのＩＤを表示制御部Ｆ２に通知する。表示制御部Ｆ２は、選択されたボタンのＩＤに基づいて、次に表示する画面ＩＤを特定し、その画面を表示する。なお、画面が備えるボタンの位置は、画面毎に予め設定されてあって、現在表示している画面ＩＤとカーソル位置から、選択操作受付部Ｆ３は、乗員が選択したボタンのボタンＩＤを特定することができる。

　操作状態判定部Ｆ４は、現在表示している操作画面である現行画面のＩＤまたは乗員によって選択されたボタンのＩＤに基づいて、乗員の操作状態が、所定の機能を利用するための一連の操作の途中であるか否かを判定する。操作が途中の状態とは、目的地の入力が完了していない状態や、楽曲／アルバム／アーティストのリストを表示している状態、映画のリストを表示している状態などである。

　操作途中の状態は、１つの局面においては、機能を実行開始させるためのボタンである実行ボタンがまだ押下されていない状態に相当する。実行ボタンの押下をトリガとしてＨＣＵ３０は、経路案内、音楽再生、電話発信等が開始する。ナビゲーション機能においては、案内開始を指示するボタンが実行ボタンに相当する。また、通話機能においては発信先の選択後に表示される発信ボタンが実行ボタンに相当する。実行ボタンとして振る舞うボタンは、適宜設計されうる。

　実行ボタンを選択する操作を、本開示では機能を実行させるための最終操作／実行指示とも称する。また、本開示では機能を実行するための一連の操作のうちの最終操作以外の操作を、非最終操作と称する。非最終操作は、途中操作と呼ぶこともできる。なお、非最終操作は、目的地や発信先などといった実行条件の入力に係る操作であるため、条件入力操作と呼ぶこともできる。

　対象機能推定部Ｆ５は、現行画面のＩＤまたは乗員によって選択されたボタンのＩＤに基づいて対象機能を推定する。対象機能推定部Ｆ５は、現行画面がナビゲーション機能に紐づく画面である場合、対象機能はナビゲーション機能であると判定してよい。対象機能を推定することは、操作者としての乗員が何をしたいのかを推定すること、換言すれば、操作対象とする車内機器を推定することに対応する。

　運転状態判定部Ｆ６は、ドライバが運転している状態（つまり運転中）であるか否かを判定する。例えば運転状態判定部Ｆ６は、ドライバが運転状態であるか否かを判断するための準備処理を実行してよい。準備処理は、車両状態センサ１１から入力される車両情報に基づき自車両が走行しているか否かを判定することであってよい。運転状態判定部Ｆ６は、車速が所定の閾値（例えば３ｋｍ／ｈ）以上となっている場合には走行していると判定し、車速が所定の閾値未満となっている場合には走行していないと判定してよい。また、運転状態判定部Ｆ６はシフトポジションが駐車ポジションとなっている場合や、パーキングブレーキがオンとなっていることに基づいて自車両は走行していないと判定してもよい。自車両が停止していると判断する条件は適宜変更可能である。

　運転状態判定部Ｆ６は、自車両が走行している場合、自動運行装置１７から入力される動作モード情報に基づいて、ドライバが運転状態であるかを判定する。運転状態判定部Ｆ６は車両が走行している場合であっても、自動運転モードである場合にはドライバは運転状態ではないと判定してよい。一方、自動運転中ではなく、かつ、自車両が走行している場合、運転状態判定部Ｆ６は、ドライバは運転状態であると判定してよい。なお、自車両が自動運転機能を備えない場合、運転状態判定部Ｆ６は自車両が走行していることに基づいてドライバは運転状態であると判定しても良い。

　また、運転状態判定部Ｆ６は、自車両が走行していない場合には、ドライバは運転状態ではないと判定する。なお、広義においてはブレーキペダルを踏んで車両を停止させ続けることも運転操作の一部とみなされることがある。しかしながら、本開示における運転状態とは、車両を走行させるための操作を実施している状態を意味するものとし、停車中は運転状態に含まれないものとする。本開示では運転状態ではないドライバの状態を非運転状態とも称する。非運転状態から運転状態へ移行する場面、つまり運転開始の具体的な場面には、手動運転中に信号待ち等で停車している状態から発進させる場合だけでなく、自動運転から手動運転に切り替える場合も含まれる。

　音声認識部Ｆ７は、乗員が発話した内容を解析する構成である。音声認識部Ｆ７は、特定の音声認識開始イベントが生じたことに基づいて、音声入力待機状態となり、マイク２５を介して乗員が発話した音声データを取得する。そして、その音声データに対して音声認識処理を実施し、音声データに対応するテキストデータを取得する。音声入力待機状態とは、マイク２５から入力されるデータを、音声認識対象として取得する状態である。音声入力待機状態が、音声認識機能が有効化された状態に相当する。

　音声認識開始イベントとしては、トークスイッチ２６の押下を採用可能である。また、後述するように、ドライバが運転状態である状況下で操作制限の対象画面に遷移する操作を受け付けたことや、操作制限の対象画面を表示中にドライバが運転状態に移行したことなども音声認識開始イベントに含まれる。その他、ウェイクワードの発話検知も音声認識開始イベントに含めることができる。ウェイクワードは、音声認識（音声入力）を有効化するための規定フレーズであって、ホットワード、トリガーワード、ウェイクアップワードなどとも呼ばれうる。なお、本実施形態では、ＨＣＵ３０内部で音声認識処理、つまり発話内容の解析を実施する。もちろん他の態様として音声認識処理は、車両に外部に設けられた音声認識サーバで実施されても良い。

　音声認識部Ｆ７は、発話音声の取得に際し、車内状況や対象機能に応じて有効化するマイク２５を取捨選択してもよい。ドライバによる音声指示も受け付けるべき状況においてはＤ席マイク２５ａとＰ席マイク２５ｂの両方を有効化する。また、ドライバの運転負荷が高い場合や、操作デバイス２３を操作している人物は助手席乗員であると判定されている場合には、Ｐ席マイク２５ｂのみ有効化する。マイク２５の有効／無効はソフトウェア的に切替可能である。当該構成によれば、ドライバに煩わしさを与える可能性や、システム誤作動の可能性を低減できる。

　コマンド特定部Ｆ８は、選択操作受付部Ｆ３が取得した乗員の操作内容と音声認識結果の少なくとも何れか一方に基づいて、実行すべきコマンドを特定する。コマンド特定部Ｆ８は、機能実行のための操作デバイス２３に対する乗員の一連の操作が完結した場合には、当該操作内容に基づいてコマンドを特定する。当該ケースは、操作デバイス２３からの信号のみでコマンドを特定するケースに相当する。また、コマンド特定部Ｆ８は、音声認識結果として、実行させたい機能を示す動詞句とその目的語を含むフレーズであるリクエストフレーズを取得した場合には、当該発話内容に応じてコマンドを特定する。リクエストフレーズとは、例えば、「ＸＸさんに電話をかけて」や、「ＸＸ駅を目的地に設定して」などである。「電話をかけて」や「目的地に設定して」などが、対象機能を示す動詞句に相当する。また、「ＸＸさん」や「ＸＸ駅」などといった目的語としての単語が実行条件に相当する。

　加えて、コマンド特定部Ｆ８は、操作制限等の理由により、操作デバイス２３に対する乗員の操作が途中で止まった場合には、それまでの乗員の入力内容と音声認識処理とを相補的に組み合わせてコマンドを特定する、コマンド入力支援処理を実行する。コマンド入力支援処理の詳細は別途後述する。コマンド実行部Ｆ９は、コマンド特定部Ｆ８が特定したコマンドを実行する構成である。コマンドの実行は、対象機能に対応する車内機器との協働によって実現される。仮にコマンド特定部Ｆ８が特定したコマンドがナビゲーション機能に関するものである場合には、ナビゲーション装置１５に対して、目的地等の情報を送信し、コマンドを実行させる。

　＜表示制御部の補足＞
　表示制御部Ｆ２は、車両が走行中であることを条件として、画面表示に関わる乗員の入力操作を制限する、操作制限処理を実行することがある。操作制限は、走行強制とも称される。操作制限は、具体的には、ナビゲーション装置１５やオーディオ装置１６、通話機能等に対する乗員の操作を制限することに対応しうる。操作制限は、運転中のドライバが、インパネディスプレイ２２を注視し続けることを抑制するための処理である。

　ＨＣＵ３０には操作制限の対象とする操作画面である制限対象画面が予め登録されている。ＨＣＵ３０には制限対象画面のＩＤのリストが登録されている。或いは、画面ごとに、操作制限の対象であるか否かを示すフラグが設定されている。ＨＣＵ３０は、画面ＩＤに基づいて、現行画面、及び、遷移先画面が制限対象画面かどうかを判別可能に構成されている。なお、遷移先画面とは、次に表示する画面であって、乗員に選択されたボタンのＩＤによって特定される。

　ＨＣＵ３０は操作制限を適用している場合、制限対象画面に含まれるボタンのうち、機能の実行にかかるボタンが押下されてもそのボタンに紐づく処理を実行しない。つまり、機能に実行にかかるボタンを無効化する。機能の実行にかかるボタンとは、実行条件を指定するためのボタンである。操作制限によって無効化されたボタンは、選択不能であることがドライバに伝わるように、トーンダウンした態様で表示されてよい。トーンダウン表示については後述する。

　もちろんＨＣＵ３０が、現行画面が制限対象画面であっても、いつも操作制限を適用するわけではない。車両が停止中である場合など、特定の条件を充足する場合には操作制限を適用しない。操作制限を適用する場合とは、基本的に、ドライバが運転状態である場合である。ただし、本開示のＨＣＵ３０は、別途後述するように操作デバイス２３の操作者が助手席乗員などドライバではないことが確認できている場合には、ドライバが運転状態であっても、操作制限を適用しない。操作制限を適用する条件は適宜設計されうる。

　ＨＣＵ３０は、操作制限を適用する場合、制限対象画面に含まれる、機能の実行にかかるボタンを乗員が選択不能な態様で表示する。選択不能な態様とは、外観上は、ボタンを構成する画像やテキストを通常時よりもトーンダウンさせた態様を意味する。トーンダウンは、彩度を低下させること、灰色にすること（いわゆるグレーアウト）、輝度を低下させること、表示に用いる線を実線から破線に変更すること等に相当する。通常時とは、操作制限が適用されていない場合、換言すれば、乗員がボタンを選択可能な状態を意味する。

　なお、操制限対象画面に設定される操作画面とは、乗員の視認時間が長くなりやすい画面である。各画面には、制限対象画面か否かを区分するために、乗員が当該画面を視認する時間の想定値である想定視認時間が設定されている。或る画面についての想定視認時間は、当該画面での入力が完了するまでの時間の想定値に相当する。画面ごとの想定視認時間は、画面が備える選択肢の数や、画面の切り替えるために必要な乗員の操作数に応じて設計されている。操作画面が備える選択肢（ボタン）や入力項目数が多いほど、想定視認時間は長くなる。制限対象画面とは、想定視認時間が所定値以上となる画面とすることができる。図６に示す発信先選択画面は、制限対象画面に設定されうる。発信先選択画面は、発信先を選択する画面であって、通話機能を利用するための画面の１つに相当する。

　また、本実施形態では累積視認時間が所定値以上となる操作画面もまた、制限対象画面に設定されている。累積視認時間はホーム画面からの想定視認時間の累積値である。当該累積視認時間については図７を用いて説明する。

　図７は、機能実行までに第１画面から第４画面までの４回の画面遷移が生じるケースを示している。第１画面はホーム画面の次に表示される画面である。ナビゲーション機能を例にとると、第１画面は、住所や、施設名、電話番号など、何れの観点から目的地を入力するかを選択する画面である。また、第２画面は、都道府県や市町村を入力するための画面であり、第３画面は番地等を入力するための画面である。第４画面は、入力された目的地周辺の地図画像を表示することで、目的地の設定を確認するための画面である。なお、ナビゲーション機能においては、第５画面として、距離優先や時間優先など、それぞれ異なる観点で算出された複数の経路候補の中から走行経路を選択するための画面を含んでいてもよい。

　前述の通り各画面には、画面構成に応じた想定視認時間が設定されている。図７では、第１～第４画面の想定視認時間は順に５秒、６秒、１０秒、５秒に設定されている場合を示している。図中のＶＴは想定視認時間を示している。また、ＣＶＴは累積視認時間を示している。或る画面についての累積視認時間は、当該画面に至るまでの画面の想定視認時間の合算値に、さらに、当該画面での想定視認時間を加算した値である。第３画面の累積視認時間は、第１画面、第２画面、及び第３画面の想定視認時間の和である。図７に示す例では、第３画面の累積視認時間は２１秒である。仮に操作制限を適用するための累積視認時間に対する閾値が１６秒に設定されている場合、第３画面以降が制限対象画面として登録される。もちろん、累積視認時間に対する閾値によって、制限対象画面は異なりうる。累積視認時間に対する閾値が１０秒に設定されている場合、第２画面以降が制限対象画面に該当する。なお、以上で述べた制限対象画面の設定例は一例であって適宜変更可能である。

　＜コマンド入力支援処理について＞
　ここでは、ＨＣＵ３０が実施するコマンド入力支援処理について図８に示すフローチャートを用いて説明する。図８に示すフローチャートは、画面遷移を生じさせる非最終操作を受け付けた場合に実行される。図８に示すフローチャートは一例としてステップＳ１０１～Ｓ１０３、Ｓ１１０、Ｓ１２０～Ｓ１２６を含む。各ステップは図８に示す矢印に従って順に実行される。ステップの実施主体としてのプロセッサ３１との記載は、適宜、情報取得部Ｆ１～コマンド実行部Ｆ９といった、ＨＣＵ３０が備える複数の機能部の何れかに読み替え可能である。

　ステップＳ１０１は、プロセッサ３１が以降の処理で使用する種々の情報を取得するステップである。情報取得部Ｆ１は、車両状態情報や、ドライバの状態情報などを取得する。また、ステップＳ１０１では、非最終操作として乗員によって選択されたボタンのＩＤを取得するとともに、当該ボタンＩＤに基づいて、遷移先画面のＩＤを取得する。

　ステップＳ１０２はプロセッサ３１が、ステップＳ１０１で取得したボタンＩＤ／遷移先画面ＩＤに基づいて、遷移先画面が制限対象画面に該当するか否かを判定する。遷移先画面が制限対象画面に該当する場合（ステップＳ１０２　ＹＥＳ）、プロセッサ３１は車両状態センサ１１の出力信号に基づいてドライバが運転状態であるか否かを判定する。遷移先画面が制限対象画面に該当し、かつ、ドライバが運転状態である場合には（ステップＳ１０３　ＹＥＳ）、プロセッサ３１は遷移先画面をトーンダウン表示する（Ｓ１２０）。トーンダウン表示とは、前述の通り、実行条件の入力に係るボタン類を選択不能な態様で表示することを意味する。なお、制限対象画面をトーンダウン表示する場合においてもプロセッサ３１は、実行条件の入力とは関係しない所定ボタンについては選択可能な態様で表示しうる。実行条件の入力とは関係しないボタンとは、現在位置周辺の地図を表示するためのボタンや、ホーム画面に戻るためのボタンなどを意味する。

　一方、遷移先画面が制限対象画面に該当しない場合（ステップＳ１０２　ＮＯ）や、ドライバが運転状態ではない場合（ステップＳ１０３　ＮＯ）には、遷移先画面を通常表示する。通常表示とは、実行条件の入力に係るボタン類を選択可能な態様で表示することを意味する。

　ステップＳ１２１はプロセッサ３１が現行画面のＩＤに基づいて対象機能を推定するステップである。なお、現行画面は、最後に選択されたボタンのＩＤに紐付いているため、画面ＩＤに基づいて対象機能を推定することは、乗員に選択されたボタンのＩＤに基づいて対象機能を推定することに対応する。

　ステップＳ１２２は、プロセッサ３１が現行画面に紐づく問い合わせメッセージを音声出力する。例えば現行画面が発信先選択画面である場合、プロセッサ３１は「誰に電話をかけますか？」といった質問を音声出力（アナウンス）させてよい。また、現行画面が目的地としての住所を入力するための画面である場合には、「どこに行きたいですか？」といった問い合わせメッセージを音声出力する。現行画面がオーディオ機能に係る楽曲選択画面である場合には「どの曲を聞きたいですか？」といった問い合わせメッセージを音声出力する。

　問い合わせメッセージは、ドライバが前方の交通状況を見ている状態でも認識可能なように音声としてスピーカ２４から出力することが好ましい。もちろん、問い合わせメッセージは、画像としてＤ席用表示エリアＡ１やＨＵＤ２１に表示されてもよい。なお、ステップＳ１２２で出力する問い合わせメッセージは、以下で説明するように、乗員に目的地等の実行条件を音声入力させるための呼び水（トリガ）として作用する。

　ステップＳ１２２にて表示／音声出力する問い合わせメッセージは、画面ＩＤごとに予めストレージ３２等に登録されている。なお、問い合わせメッセージの内容は、現行画面の選択肢に直接的に対応するものであっても良い。仮に現行画面が、目的地設定において、目的地が属する州／県を選択する画面である場合、「どの州／県に行きたいですか」といった問い合わせメッセージを出力してもよい。ただし、当該問い合わせ方式では、未入力の項目ごと、或いは、操作画面ごとに乗員が回答を発話する必要が生じうる。そのような課題に対し、本実施形態のＨＣＵ３０は、現行画面に縛られずに、本来の目的を達成できる質問を投げかける。すなわち、対象機能に対応する動詞句の目的語を質問する。当該構成によれば乗員が発話する回数を低減可能となり、利便性を高めることができる。

　ステップＳ１２３はプロセッサ３１が、音声認識機能を有効化するステップである。すなわち、音声入力待機状態に移行する。ステップＳ１２４は、乗員の発話音声を取得し、その認識結果を取得するステップである。なお、一定時間待機しても乗員の発話を検出できなかった場合には、タイムアウトとして本フローを終了する。

　ステップＳ１２５は、ステップＳ１２１で特定された対象機能と、ステップＳ１２４で取得した発話内容とから、乗員が希望するコマンドを特定する。ステップＳ１２４で取得する発話内容には、目的地や、曲名、電話の発信先、検索語などの実行条件に相当する目的語が含まれていることが期待できる。プロセッサ３１は、発話内容から目的語を抽出し、当該目的語と対象機能とを組み合わせることにより、コマンドを特定する。仮に対象機能がナビゲーション機能と特定されている状況において、目的語として「ＸＸ駅」を取得した場合には、ＸＸ駅までの経路案内をコマンドとして取得する。また、対象機能が通話機能と特定されている状況において、目的語として人の名前（例：ＸＸ）を取得した場合には、ＸＸさんに発信することをコマンドとして取得する。

　なお、「誰に電話をかけますか？」といった通話機能に係るシステムからの質問に対する回答としては、以下（１）～（３）の３つのパターンに層別可能である。（１）連絡先のリストに登録済みの人、（２）代名詞、（３）未登録の名前。プロセッサ３１は、（１）～（３）の何れのパターンにも対応可能に構成されている。発信先を示す代名詞とは、さっき電話かけてきた人、父、母、学校などである。発話された発信先が（３）のパターンに該当する場合、プロセッサ３１は、発話された名称をインターネット検索し、電話番号を取得すればよい。

　ところで、対象機能の推定結果に音声認識結果を組み合わせてコマンドを特定する処理に関し、プロセッサ３１は、次のように作動しても良い。すなわち、プロセッサ３１は、発話内容として取得した目的語（Ｏ：object）に、現行画面のＩＤ（対象機能）に対応する動詞句（Ｖ：verb）を補完することにより、擬似的にリクエストフレーズを生成する。そして、当該擬似的なリクエストフレーズを用いてコマンドリストの中から、最も尤度の高いコマンドを取得しうる。コマンドリストは、車載システムＳｙｓが実行可能なコマンドのリストであって、乗員が操作／利用可能な機能と、対象機能が実行可能な制御／処理の一覧をまとめたものである。前述の通り、機能は、車内機器／アプリなどと言いかえることができる。

　また、発話内容から実行条件に相当する目的語を抽出する際、プロセッサ３１は対象機能の情報を用いて高精度化又は処理負荷低減を図ってもよい。プロセッサ３１は、音声認識で取得した発話内容の全文のうち、対象機能に関連性が高いワードを優先的に実行条件として抽出しても良い。さらにＨＣＵ３０は、機能ごとに当該機能に対応する目的語を取得するための音声認識データベースを備えていても良い。その場合、プロセッサ３１はステップＳ１２１で特定された対象機能に応じて、音声認識に使用するデータベースを使い分ける。プロセッサ３１は対象機能に応じた音声認識データベースを用いて発話内容を解析し、目的語を抽出する。当該構成によれば、目的語の探索範囲が対象機能に応じて限定的となるため処理負荷を低減できるとともに、音声認識の精度の向上効果が期待できる。その他、ＨＣＵ３０は、目的語から直接的にコマンドを特定可能なコマンドリストを、機能ごとに備えていても良い。

　ステップＳ１２６は、ステップＳ１２５で特定されたコマンドを実行するステップである。仮に特定されたコマンドが「ＸＸ駅までの経路案内」である場合には、当該コマンドに対応する制御信号をナビゲーション装置１５に出力し、ナビゲーションを開始させる。

　本開示では、ステップＳ１２１からステップＳ１２６までの一連のシーケンスを音声補完処理とも称する。また、現行画面に応じた問い合わせメッセージを出力すると同時に／その直後に、音声認識機能を自動的に有効化する処理（Ｓ１２２～Ｓ１２３）を音声入力案内処理とも称する。音声入力案内処理は未入力の項目、換言すれば、機能対象に対応する他動詞の目的語を音声入力するように促す処理に相当する。

　＜上記実施形態の効果について＞
　以上の構成は、１つの局面において、ドライバが運転中に、操作制限が適用される画面に遷移した場合に、その操作の続きを音声入力にて取得する構成に相当する。当該構成によれば、運転開始等により操作が途中で止まってしまい、ドライバの利便性が低下することを抑制できる。換言すれば、操作制限が適用される機能に関しても、ドライバは音声入力にて使用できる。

　またＨＣＵ３０はドライバが運転中に表示画面が制限対象画面に遷移したことに基づいて、自動的に音声認識機能を有効化する。そのため、ドライバ等の乗員は、音声入力に際してトークスイッチ２６の押下やウェイクワードを発する必要がない。

　加えて、乗員はシステムからの問い合わせに対して回答する形で、実行条件を示す目的語を発話すればよい。つまり、乗員は動詞句と目的語とを含むリクエストフレーズ全体を発する必要がない。そのため、乗員の発話量を低減できる。また、解析対象とする発話内容が短縮されるため、認識精度自体も向上しうる。よって、誤作動の恐れも低減できる。

　加えて、一般的な音声認識では、「お話ください」等の漠然とした問いかけを行うため、乗員は何を話していいのか分かりにくい。そのような課題に対し、本開示のＨＣＵ３０は、対象機能に関連する動詞句を含む、回答の範囲を限定しうる質問を投げかける。そのため、乗員も何を話せばよいのか分かりやすいといった利点を有する。

　また、プロセッサ３１は、直前の乗員の操作内容に基づいて対象機能を特定し、当該対象機能が実施可能な範囲において発話内容に応じた制御を実施する。対象機能の特定は、乗員の選択操作に基づくものであるため、誤判定の可能性が低い。よって、乗員が意図しない機能を作動させてしまう恐れも低減できる。

　また、ホーム画面から機能を選択する部分など、最初の操作は停車時と同様に手操作で実施可能である。そのため、音声入力ではなく操作デバイス２３による入力を好んで使う乗員にとっても違和感が少なく、使いやすいインターフェースとなりうる。その他、音声認識を開始する前に対象機能を特定しているため、乗員が発話しうる単語の範囲を絞り込むことができ、音声認識精度を高めることができる。

　その他、上記ＨＣＵ３０は、１つの局面において、操作制限がかかる画面、換言すれば、手操作では時間がかかる画面以降の入力を音声入力に切り替える構成に相当する。当該構成によれば、乗員の操作数を低減でき、周辺環境の確認に利用可能な時間を増やす効果が期待できる。また、上記構成は、手操作から音声入力に切り替えるものであって、音声入力から手操作に切り替えるものではない。音声認識に失敗したことに基づいて入力手段を手操作に切り替えるものでもない。認識等の失敗をトリガとして、最初から又は所定量前の工程から指示入力をやり直すものでもない。上記構成は、手入力された情報を引き継いで音声認識によってコマンドを特定及び実行するものであるため、乗員－システム間のやり取りを抑制できる。ひいては、乗員が入力操作に意識を取られる時間が少なくなるので、ドライバ等の乗員は周囲の安全確認を集中しやすくなる。

　また、一般的に、音声入力の成功率を高めるためにはリクエストフレーズを所定値以上の音量ではっきりと発話することが好ましいが、車内の状況は様々であり、同乗者が寝ている場合や電話をしている場合など、大きな声を出したくないシーンもある。上記の構成によれば乗員の発話量を抑制できるため、乗員が大きな声で発話することが発話しにくいシーンにも好適である。なお、ＨＣＵ３０は乗員見守りカメラ１３からの信号に基づき、電話をしている同乗者や寝ている同乗者を検出した場合には、問い合わせメッセージを音声ではなく画像にて出力してもよい。ＨＣＵ３０は車内の状況に応じて問い合わせメッセージの出力態様を変更してもよい。当該構成によれば利便性／快適性がより一層向上しうる。

　以上、本開示の実施形態を説明したが、本開示は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本開示の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。下記の種々の補足や変形例などは、技術的な矛盾が生じない範囲において適宜組み合わせて実施することができる。なお、以上で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略することがある。また、構成の一部のみに言及している場合、他の部分については上記説明を適用することができる。

　＜変形例（１）＞
　プロセッサ３１は、ドライバが運転状態ではないと判定している場合には運転準備状態に該当するか否かを判定し、当該判定結果に基づいて制限対象画面の表示態様や、音声認識機能の動作状態を制御しても良い。運転準備状態とは、たとえばインパネディスプレイ２２を見ていない状態、より具体的にはドライバが車両前方を見ている状態である。ドライバが運転準備状態に該当するか否かは、乗員見守りカメラ１３からの信号に基づき定まるドライバの視線方向／顔の向きから判断可能である。

　また、プロセッサ３１は、自車両が停車している状態において、周辺監視センサ１２にて先行車両の発進が検出されたことに基づいて、ドライバは運転準備状態に移ったと判定しても良い。さらに、プロセッサ３１は信号機の指示にて自車両が停止中、信号機の点灯状態が自車両の通行を許可する点灯状態に移ったことが周辺監視センサ１２にて検出されたことに基づいて、ドライバは運転準備状態に移ったと判定しても良い。自車両の通行を許可する点灯状態とは、緑色灯火が点灯している状態に加えて、自車両の進行方向に応じた矢印型の補助灯が点灯している状態を含む。なお、信号機の点灯状態は周辺監視センサ１２としてのカメラによって認識されうる。また、信号機の点灯状態は、路側機から配信される点灯スケジュール情報に基づいて特定されても良い。

　その他、プロセッサ３１は、自車両が自動運転モードであって、かつ、運転交代中である場合や、所定時間（１０秒）以内に運転交代処理を開始することが計画されている場合に、ドライバは運転準備状態であると判定してもよい。

　図９はドライバが運転準備状態に該当するか否かを判定するステップを含むコマンド入力支援処理についてのフローチャートである。図９に示すように、プロセッサ３１は制限対象画面を表示する際、ドライバがまだ運転状態ではない場合には（ステップＳ１０３　ＮＯ）、ドライバが運転準備状態に該当するか否かを判定する（ステップＳ１０４）。運転準備状態に該当するか否かは、前述の通り、ドライバの視線方向、先行車両の挙動、信号機の点灯状態、及び、運転交代処理の実施計画に基づいて判断される。ここで、ドライバが運転準備状態に該当すると判定しなかった場合には（ステップＳ１０４　ＮＯ）、遷移先画面を通常表示する（ステップＳ１１０）。一方、ドライバが運転準備状態に該当すると判定した場合には（ステップＳ１０４　ＹＥＳ）、制限対象画面をトーンダウン表示した上で音声補完処理を実施する（ステップＳ１２０、Ｓ１３０）。つまり、まだドライバが運転操作を開始していない状態であっても運転準備状態に該当する場合には、音声入力案内処理を実施し、対象機能と推定結果と音声認識結果との組み合わせにより、乗員の望むコマンドを特定及び実施する。

　このような構成によれば、ドライバが運転準備状態に移ったタイミングで、音声にて未入力の実行条件を入力可能となる。これに伴いドライバは、操作画面から目を離し、余裕を持って車両前方を含む周辺の交通状況を確認可能となる。つまり、安全性を高めつつ、ドライバの利便性も向上可能となる。加えて、上記構成によれば、問い合わせメッセージが音声出力されたことに基づいて、ドライバは速やかに運転操作を開始する必要があることを認識しやすくなる。

　＜変形例（２）＞
　ＨＣＵ３０は、操作デバイス２３の操作者が助手席乗員か否かに応じて、乗員の入力操作に対する挙動（応答）を変更しても良い。そのような技術思想に対応する実施例（変形例）を図１０及び図１１を用いて説明する。なお、本開示での操作者とは、操作デバイス２３を操作することでインパネディスプレイ２２に表示されているボタンを押下している人物である。操作者は、実行条件を入力している人物であるため、実行条件／コマンドの入力者と呼ぶこともできる。

　図１０は上記技術思想に対応するＨＣＵ３０の機能を示すブロック図である。本変形例におけるＨＣＵ３０は、図１０に示すように、助手席乗員検出部Ｆａ、操作者特定部Ｆｂ、及び実視認時間計測部Ｆｃを備える。これらの機能部もまた、プロセッサ３１が車内機器制御プログラムを実施することで実現されうる。

　助手席乗員検出部Ｆａは、助手席に乗員が存在するか否かを検出する。助手席乗員がいるか否かは、助手席に設けられた着座センサやシートベルトセンサの出力信号に基づいて判定可能である。また、助手席乗員検出部Ｆａは乗員見守りカメラ１３からの信号に基づいて、助手席乗員の有無を判定しても良い。

　操作者特定部Ｆｂは、操作デバイス２３の操作者を特定する構成である。助手席乗員が検出されていない場合、操作者特定部Ｆｂは、操作者はドライバと判定する。一方、助手席乗員が検出されている場合、操作者特定部Ｆｂは、乗員見守りカメラ１３の映像を解析することでドライバと助手席乗員のどちらが操作者に該当するかを判定してよい。操作者の判断材料としては、乗員ごとの姿勢や顔の向き、手の動きなどを採用可能である。操作者特定部Ｆｂは、操作デバイス２３を触っている人物、或いは、インパネディスプレイ２２を見ている人物を操作者と判定する。仮に車載システムＳｙｓが、操作デバイス２３付近における指や腕の運動を赤外線センサやミリ波レーダ等を用いて検出可能に構成されている場合、操作者特定部Ｆｂは指や腕の運動方向などに基づいて操作者を判定してもよい。また、操作者特定部Ｆｂは、消去法的に操作者を特定しても良い。操作を受け付けた時点において、ドライバが前方を見ており、かつ、ドライバの両手或いは操作画面に近い方の手がステアリングホイールを把持していることを確認できている場合、操作者特定部Ｆｂは、操作者は助手席乗員と判定しても良い。

　実視認時間計測部Ｆｃは、操作者がインパネディスプレイ２２を見続けている時間を計測する構成である。インパネディスプレイ２２を見続けている時間は、操作者の視線が操作画面或いはカーソルが存在する方向と一致している時間に相当する。操作者の視線方向は、前述の通り乗員見守りカメラ１３からの信号によって定まる。ここでの一致とは完全一致に限らず、３０度程度ずれている場合、すなわち略一致を含む。

　本変形例のＨＣＵ３０は、コマンド入力支援処理として図１１に示すフローを実行する。図１１に示すコマンド入力支援処理は、前述の図９等に示す処理と適宜組み合わせて実施可能である。図１１に示すコマンド入力支援処理もまた、図８や図９に示すコマンド入力支援処理と同様に、画面遷移を生じさせる非最終操作を受け付けた場合に実行される。図１１に示すコマンド入力支援処理はステップＳ２０１～ステップＳ２０４、ステップＳ２１０、ステップＳ２２０、及びステップＳ２３０を備える。各ステップは図１１に示す矢印に従って順に実行される。

　ステップＳ２０１～ステップＳ２０３は前述のステップＳ１０１～ステップＳ１０３と同じである。ステップＳ２０４は、操作者がドライバであるか否かを判定するステップである。操作者がドライバであると判定されている場合には（ステップＳ２０４　ＹＥＳ）、遷移先画面をトーンダウン表示した上で（ステップＳ２２０）、音声補完処理を実行する（ステップＳ２３０）。ステップＳ２２０及びステップＳ２３０の具体的な内容はステップＳ１２０、ステップＳ１３０と同様である。一方、操作者はドライバではない、すなわち、操作者は助手席乗員であると判定されている場合には（ステップＳ２０４　ＮＯ）、ステップＳ２１０として遷移先画面を通常表示する（ステップＳ２１０）。

　以上の構成によれば、遷移先画面が制限対象画面であってかつドライバが運転状態である場合であっても、操作者が助手席乗員である場合、ＨＣＵ３０は操作制限を適用せずに、実行条件の入力にかかるボタンを選択可能な態様で表示する。当該構成によれは、助手席乗員にとっての車載ＨＭＩの操作性を向上できる。

　＜変形例（３）＞
　プロセッサ３１は、ドライバが非運転状態であること、又は、操作者が助手席乗員であること等に由来して遷移先画面を通常表示している状況において、特定の入力支援条件が充足した場合には、音声補完処理を実施しても良い。図１２は当該技術思想に対応するフローを示したものであってステップＳ３０１は入力支援条件が充足したか否かを判定するステップである。またステップＳ３０２は音声補完処理を実行するステップである。

　入力支援条件とは、操作制限を適用しない場合においても音声補完処理を実施する条件に相当する。音声補完処理を実行することは、未入力の項目を音声入力にて取得（補完）すること、換言すれば、実行条件の入力手段を音声入力に切り替えることに相当する。故に入力支援条件は、実行条件の入力手段を音声入力に切り替える条件と解することができる。

　プロセッサ３１は、操作画面を表示した後、所定経過しても選択操作が実施されない場合に、音声補完処理を実行する。表示画面切り替え後、所定経過しても選択操作が実施されないということは、操作者が迷っている、或いは、操作が分からず困っている状況であることを示唆する。そのような状況に対し、上記構成によれば、システムが質問を投げかけることで、操作者は希望の機能を利用しやすくなる。

　また、プロセッサ３１は、スクロールや、ページめくり、カーソルの移動等は観測されているものの、同一種別の画面が表示されている状態が所定時間継続したことに基づいて音声補完処理を実行しても良い。プロセッサ３１は、キーボード画面を表示してから所定時間が経過しても入力完了ボタンが押下されない場合に、音声補完処理を実行しても良い。キーボード画面は、検索語としての任意の文字列を入力可能な入力フォームを備える画面である。入力完了ボタンは、文字列の入力が完了したことを操作者がシステムに伝えるためのボタンである。ＨＣＵ３０は、入力完了ボタンが押下されたことに基づいて、入力されている文字列をキーとした検索等の後続処理を実行する。

　その他、プロセッサ３１は、１つ前の画面に戻る操作／処理が実行されたことに基づいて音声補完処理を実行しても良い。１つ前の画面に戻る操作／処理が実行される場合には、目的地設定に係るキーボード画面で文字入力を完了させたが、検索結果として入力文字列に該当する住所／施設等が発見できなかった場合が含まれる。上記の操作／処理がなされたということは、操作者が希望する選択肢が見つからずに困っていることが想定される。

　表示画面切り替え後、所定経過しても別の画面に移るための選択肢が選択されなかった場合や、前の画面に戻る操作／処理が実行された場合などが、入力支援条件が充足した場合に対応する。また、検索語として入力された文字列に対応する情報が見つからなかった場合も入力支援条件が充足した場合として取り扱うことができる。上記条件によって音声補完処理を実施する構成によれば操作者の機能を利用しやすくなる。なお、上記入力支援条件が充足したことに基づく音声補完処理の実行は、操作者が助手席乗員と判定されている場合にのみ実施されても良いし、操作者に関わらずに実施されても良い。

　＜変形例（４）＞
　プロセッサ３１は、操作者が助手席乗員であると判定していることに条件に制限対象画面を通常表示している状況において、ドライバが操作しようとしたことを検知した場合には、音声補完処理を実行しても良い。当該構成によれば、ドライバが運転中にインパネディスプレイ２２を見続ける恐れを低減できる。

　図１３は当該プロセッサ３１の作動を示すフローである。当該処理フローは、前述の種々の処理と並列的に、又は、組み合わせて、又は置き換えて実施可能である。図１３に示すフローは、ステップＳ２１０の後工程として実施されうる。図１３に示すステップＳ３１１は、助手席乗員が操作中であることに基づいて制限対象画面を通常表示している状態か否かを判定するステップであり、ステップＳ３１２はドライバが操作デバイス２３を操作しているか否かを判定するステップである。ステップＳ３１２は、ドライバが操作デバイス２３を操作しようとしているか否かを判定するステップであっても良い。ドライバが操作デバイス２３を操作しているか／操作しようとしているか否かは、操作者の識別方法と同様に、乗員見守りカメラ１３からの信号に基づいて判定されうる。ステップＳ３１３は現行画面の表示態様をトーンダウン表示に切り替えるステップであり、ステップＳ３１４は音声補完処理を実施するステップである。

　その他、プロセッサ３１は、乗員見守りカメラ１３からの信号に基づいて、ドライバがインパネディスプレイ２２を見ていると判定している場合、ドライバがインパネディスプレイ２２を見続けている時間を計測しても良い。プロセッサ３１は、助手席乗員が操作中であることを条件として制限対象画面を通常表示している状況において、ドライバがインパネディスプレイ２２を見続けている時間が所定値以上となった場合には音声補完処理を実施しても良い。当該構成によっても、ドライバが運転中にインパネディスプレイ２２を見続ける恐れを低減できる。

　＜変形例（５）＞
　プロセッサ３１は、インパネディスプレイ２２の所定位置に、音声認識機能の作動状態（オン／オフ）を示す画像である音声認識インジケータをインパネディスプレイ２２の所定位置に表示しても良い。音声認識インジケータは、音声認識機能の作動状態に応じて一部の形状／色合いが変化するアイコン画像である。音声認識ステータス画像は、マイクを模した画像でも良いし、顔を模した画像であっても良い。音声認識インジケータは、図１４に示すようにマイク画像と顔画像を組み合わせて実現されていても良い。図１４に示す（Ａ）は問い合わせメッセージを出力しているシーンでの表示形態を示しており（Ｂ）は音声入力待機中であることを示す表示形態である。図１４の（Ｃ）は、問い合わせメッセージの出力も、音声入力の待機も行っていないシーンでの表示形態を示している。もちろん、これらは一例であり、音声認識インジケータの具体的態様は適宜変更可能である。

　音声認識インジケータは、任意のキャラクター画像を用いて実現されていても良い。プロセッサ３１は、質問を音声出力する際、音声認識インジケータを構成するキャラクターの口を当該アナウンスに連動させて開閉させることにより、当該キャラクターが質問していることを表現してもよい。当該制御態様によればユーザビリティが向上しうる。

　プロセッサ３１は、図１５に示すように乗員見守りカメラ１３からの信号に基づいて、乗員が音声認識見続けていることを検出した場合には（ステップＳ３２１　ＹＥＳ）、音声補完処理を実行しても良い（ステップＳ３２２）。なお、図１５に示すフローは、ステップＳ１１０やステップＳ２１０の後工程として実施されうる。

　＜変形例（６）＞
　プロセッサ３１は、乗員が利用しようとしている機能が運転関連機能かどうか、或いは、操作者がドライバであるか助手席乗員であるかによって、操作画面（ウィンドウ）の表示位置を調整しても良い。運転関連機能とは、ドライバの運転操作やドライバにとっての車内環境に影響を与える機能を意味する。運転関連機能には、例えばナビゲーション機能が含まれる。なお、車内に流れる音楽や空調はドライバに影響を与えうるため、オーディオ機能や空調機能もまた、運転関連機能に含めることができる。一方、動画再生機能やウェブブラウジング機能などといった、エンターテイメント系の機能は、運転関連機能に該当しない。運転関連機能とする機能種別は予め登録されていれば良い。

　プロセッサ３１は、ホーム画面に対する機能の選択操作を受け付けた場合、図１６に示すように、選択機能が運転関連機能かどうかを判定する（ステップＳ３３１）。選択機能とは、乗員が利用しようとしている機能であって、上述した対象機能に対応する。選択機能は、乗員によって選択されたボタンＩＤ又は遷移先画面のＩＤに基づいて特定される。

　プロセッサ３１は、選択機能が運転関連機能に該当すると判定した場合には（ステップＳ３３１　ＹＥＳ）、操作画面を中央表示エリアＡ３に表示する（ステップＳ３３２）。一方、プロセッサ３１は、選択機能が運転関連機能に該当しないと判定した場合には（ステップＳ３３１　ＮＯ）、操作者はドライバであるか否かを判定する（ステップＳ３３３）。

　プロセッサ３１は、選択機能が運転関連機能ではないものの、操作者はドライバである場合には（ステップＳ３３３　ＹＥＳ）、操作画面を中央表示エリアＡ３に表示する（ステップＳ３３２）。一方、選択機能が運転関連機能ではなく、かつ、操作者は助手席乗員である場合には（ステップＳ３３３　ＮＯ）、操作画面をＰ席用表示エリアＡ２に表示する（ステップＳ３３４）。

　上記の構成によれば、助手席乗員の操作によって起動した、動画再生アプリなどの操作画面は、Ｐ席用表示エリアＡ２に表示され、ドライバの視界に入りにくい。故に、助手席乗員の操作に起因する画面表示によってドライバに煩わしさを与える恐れを低減可能となる。なお、プロセッサ３１は、選択機能が運転関連機能に該当すると判定し、且つ、操作者はドライバであると判定した場合には、操作画面をＤ席用表示エリアＡ１に表示しても良い。

　ところで、操作者がドライバであるか助手席乗員であるかの判定は、助手席乗員が存在することを前提とする。上記構成は、助手席乗員が存在すると判定されているか否か、及び、選択機能が運転関連機能に該当するか否かの組み合わせに基づいて、選択機能に対応する操作画面の表示位置を変更する構成の一例に相当する。図１６に示すフローチャートには、助手席乗員が存在するか否かを判定するステップが内在している。

　また、他の態様として、プロセッサ３１は選択機能の種別と操作者の何れか一方のみを用いて操作画面の表示位置を調整しても良い。ホーム画面における機能選択ボタンを押した人物（つまり操作者）が助手席乗員であると判定している場合、プロセッサ３１は、選択された機能の操作画面をＰ席用表示エリアＡ２に表示する。一方、機能選択ボタンを押下した人物はドライバであると判定している場合には中央表示エリアＡ３に表示しても良い。

　＜変形例（７）＞
　プロセッサ３１は、乗員が利用しようとしている機能が運転関連機能であるか否か、又は、操作者がドライバであるか否かに応じて、音声補完処理で使用するスピーカ２４及びマイク２５の組み合わせを変更しても良い。プロセッサ３１は、音声補完処理で使用するスピーカ２４及びマイク２５の組み合わせとして、次の（Ａ）～（Ｃ）の３パターンを選択的に採用可能である。（Ａ）Ｄ席、Ｐ席の両側のスピーカ２４及びマイク２５を使用する、（Ｂ）Ｄ席側のスピーカ２４及びマイク２５を使用する、（Ｃ）Ｐ席のスピーカ２４及びマイク２５を使用する。パターンＢではプロセッサ３１は、Ｐ席スピーカ２４ｂからは問い合わせメッセージを出力せず、かつ、Ｐ席マイク２５ｂを一時的にオフにする。また、パターンＣではプロセッサ３１は、Ｄ席スピーカ２４ａからは問い合わせメッセージは出力せず、かつ、Ｄ席マイク２５ａを一時的にオフにする。

　上記のように音声補完処理で使用するスピーカ２４及びマイク２５の組み合わせを変更することは、対象機能の実行条件の問い合わせ先を制限することに相当する。パターンＡは、ドライバと助手席乗員の両方に対して目的語の発話を要求するパターンに相当する。パターンＢは、主としてドライバに目的語の発話を要求するパターンに相当する。パターンＣは、主として助手席乗員に目的語の発話を要求するパターンに相当する。

　プロセッサ３１は、ホーム画面に対する選択操作を受け付けた場合、図１７に示すように、選択機能が運転関連機能かどうかを判定する（ステップＳ３４１）。プロセッサ３１は、選択機能が運転関連機能に該当すると判定した場合には（ステップＳ３４１　ＹＥＳ）、Ｄ席側、Ｐ席側の両方のスピーカ２４及びマイク２５を使って音声補完処理を実行する（ステップＳ３４２）。つまり、プロセッサ３１は音声補完処理で使用するスピーカ２４及びマイク２５の組み合わせとしてパターンＡを採用する。

　一方、プロセッサ３１は、選択機能が運転関連機能に該当しないと判定した場合には（ステップＳ３４１　ＮＯ）、操作者はドライバであるか否かを判定する（ステップＳ３４３）。プロセッサ３１は、選択機能が運転関連機能ではないものの、操作者はドライバである場合には（ステップＳ３４３　ＹＥＳ）、パターンＡを採用する（ステップＳ３４２）。

　プロセッサ３１は、選択機能が運転関連機能ではなく、かつ、操作者は助手席乗員である場合には（ステップＳ３４３　ＮＯ）、Ｐ席側のスピーカ２４及びマイク２５を使って音声補完処理を実施する（ステップＳ３４４）。つまり、プロセッサ３１は音声補完処理で使用するスピーカ２４及びマイク２５の組み合わせとしてパターンＣを採用する。

　上記の構成によれば、助手席乗員の操作によって起動した、動画再生アプリなどについての問い合わせは助手席乗員にのみ実施されるため、ドライバに煩わしさを与える恐れを低減可能となる。このように選択機能の種別及び操作者に応じて、実行条件の問い合わせ先を変更することにより、ドライバの快適性／利便性を高める事ができる。上記構成は、助手席乗員が存在すると判定されているか否か、及び、選択機能が運転関連機能に該当するか否かの組み合わせに基づいて、音声補完処理で使用するスピーカ２４及びマイク２５の組み合わせを変更する構成に相当する。

　なお、プロセッサ３１は選択機能の種別と操作者の何れか一方を用いて目的語の取得に使用するマイク２５の組み合わせを変更しても良い。プロセッサ３１は、選択機能が運転関連機能ではない場合には、操作者によらず、パターンＣを採用するように構成されていても良い。選択機能が運転関連機能ではない場合とは、選択機能が動画再生アプリなどの場合である。

　＜変形例（８）＞
　プロセッサ３１は、画面操作途中においてドライバが非運転状態から運転状態に移行することをトリガとして、音声補完処理を実行しても良い。プロセッサ３１は、図１８に示すフローに沿って、実行条件の取得手段を手操作から音声入力に切り替えてよい。図１８に示すフローは、ステップＳ４０１～ステップＳ４０４、ステップＳ４２０、ステップＳ４３０を含み、図中の矢印に従って順に実行されうる。なお、図１８に示す処理フローは、前述の種々の処理と並列的に、又は、組み合わせて、又は置き換えて実施可能である。図１８に示すフローは、任意の機能にかかる操作画面を表示している状況において、例えば２５０ミリ秒や５００ミリ秒、１秒などの所定間隔で定期的に実施されうる。

　ステップＳ４０１は、ステップＳ１０１等と同様に、車両情報やドライバの状態情報など、プロセッサ３１が以降の処理で使用する情報を種々のセンサ／装置から取得するステップである。ステップＳ４０２は、現行画面のＩＤに基づいて、操作が途中の状態であるか否かを判定するステップである。

　操作途中である場合（ステップＳ４０２　ＹＥＳ）、プロセッサ３１はドライバの状態が非運転状態から運転状態に遷移したか、つまり運転を開始したか否かを判定する（ステップＳ４０４）。運転を開始したと判定する場合には、ドライバ自身によるアクセルオン又はブレーキオフによって車両を発進させた場合の他に、自動運転モードから手動運転モードに切り替わった場合も含めることができる。

　ドライバが運転を開始したと判定した場合には（ステップＳ４０３　ＹＥＳ）、現行画面の表示態様をトーンダウン表示に切り替え（ステップＳ４２０）、音声補完処理を実施する（ステップＳ４３０）。一方、現行画面が制限対象画面ではない場合（ステップＳ４０２　ＮＯ）や、ドライバがまだ運転を開始していない場合（ステップＳ４０３　ＮＯ）には、プロセッサ３１は乗員の操作を待機する（ステップＳ４０４）。

　上記の構成によっても前述の実施形態と同様の効果を奏する。また、ドライバからすると運転開始後も、音声にて未入力の項目（換言すれば実行条件）を引き続き入力可能となる。ひいては、利用したい機能を速やかに実行させることが可能となる。なお、上記の処理は、現行画面が制限対象画面であることを条件として実施するように構成されていても良い。現行画面が制限対象画面ではない場合、ステップＳ４２０として表示態様の切り替え処理は省略されても良い。

　ところで図１８に示す音声入力案内処理では、問い合わせメッセージとして、現行画面／入力済みの内容に応じた質問を出力する。ここで出力するメッセージの内容は、操作の途中度（進行度）に応じて変更されてもよい。例えば目的地設定にかかる住所入力画面において、目的地が所属する「ＸＸ県／州」までの入力が完了しており、現行画面が市町村の選択画面の場合、「ＸＸ県／州のどこにいきますか？」といったメッセージを音声出力してもよい。また、目的地設定にかかる住所入力画面において、目的地が所属する「市町村」までの入力が完了しており、現行画面が番地の入力画面の場合、「番地を教えて下さい。主要部までの案内でもよいですか」といった内容のメッセージを音声出力してもよい。なお、上記質問に対して数字以外の回答が得られた場合には、主要部を目的地に設定した経路案内をコマンドとして実行しても良い。プロセッサ３１は、入力済みの内容に応じて質問内容を具体化しても良い。また、プロセッサ３１は、取得できた乗員からの回答の内容では、実行条件を一意に特定できなかった場合には、更に絞り込みのための質問を音声出力してもよい。

　加えて、プロセッサ３１は、現行画面が検索語を入力するためのキーボード画面であって、ドライバ運転開始時に所定数以上の文字／単語が入力された状態である場合には、入力済みの文字列を用いていったん検索を行ってもよい。そして、プロセッサ３１は検索ヒット数に応じて、その後の制御（応答）を変更しても良い。プロセッサ３１は検索ヒット数が所定値（例えば５件）以上である場合には、「行きたい施設名称を言ってください」といった問い合わせメッセージを出力してよい。一方、検索ヒット数が所定値未満である場合、プロセッサ３１は検索結果の中から最も尤度が高いものを選択し、「行きたい場所は、ＸＸですか？」と問い合わせてもよい。尤度は過去のドライバの目的地の設定履歴や、行動履歴など、現在地からの距離に応じて算出されれば良い。検索結果のなかに過去に訪れたことがある施設が含まれている場合には、当該施設を目的地に設定するか否かを問い合わせても良い。

　＜その他の変形例（９）＞
　プロセッサ３１は、図１９に示すように、ホーム画面以外の操作画面を表示している状況においてトークスイッチ２６が押下されたことに基づいて（ステップＳ４１１　ＹＥＳ）、当該操作画面に対応する音声補完処理を実施しても良い（４３０）。

　また、プロセッサ３１は、ステップＳ１２４にて乗員の発話内容の取得に失敗した場合には、対象機能が運転関連機能に該当するか否かに応じてその後の応答を変更しても良い。図２０に示すように、対象機能が運転関連機能である場合、特にナビゲーション機能などの運転操作との関連性が高い機能である場合（ステップＳ４２１　ＹＥＳ）、再試行処理を実施する（ステップＳ４２２）。再試行処理は、再度、音声入力案内処理を実施することに対応する。

　一方、発話内容の取得に失敗した際に、対象機能が運転関連機能ではない場合（ステップＳ４２１　ＮＯ）には、プロセッサ３１は、最寄りの安全に停車可能なスペースにて続きの操作を実施することを提案しても良い。安全に停車可能なスペースとは、サービスエリアやパーキングエリア、退避スペースなどを意味する。プロセッサ３１は音声認識に失敗した場合には、「５ｋｍ先にサービスエリアがあるので、停車して安全に操作しましょう」と提案してもよい。当該応答によれば、ドライバが運転中においてシステムに意識を向ける時間を抑制可能となる。

　その他、プロセッサ３１は、音声補完処理を実行することを決定した場合、運転交代処理を実行中かどうかに応じて、問い合わせメッセージの出力タイミングを調停しても良い。プロセッサ３１は図２１に示すように運転交代処理を実行中である場合には（ステップＳ４３１　ＹＥＳ）、問い合わせメッセージの出力を運転交代が完了するまで保留とする（ステップＳ４３２）。一方、運転交代中ではない場合には（ステップＳ４３１　ＮＯ）、問い合わせメッセージの出力を実施する。

　一般的に、運転交代中、ドライバは周囲の交通状況の把握や、自車両の状態、走行経路の確認などを実施するため、ドライバの負荷は高い状態となる。そのような状況下で問い合わせメッセージを出力すると、ドライバに煩わしさを与えうる。本変形例は上記の着想に基づいて創出されたものであって、本変形例によればドライバに煩わしさを与える恐れを低減できる。もちろん、他の態様として、運転交代中においても随時問い合わせメッセージを出力しても良い。

　上述した実施形態ではＨＣＵ３０は、回答範囲が対象機能に関連する範囲に限定されるセミクローズド・クエスチョンの態様で、実行条件にかかる質問を行う態様を例示したが、これに限らない。ＨＣＵ３０はフルクローズド・クエスチョンで質問しても良い。フルクローズド・クエスチョンはＹＥＳ／ＮＯなどの２択で回答可能な質問の仕方を意味する。セミクローズド・クエスチョンとは「どこに行きますか？」「何を聴きますか」「どの映画を見ますか？」といったように、回答の範囲が限定されているものの、回答の自由度が相対的に高い質問の仕方を意味する。セミクローズド・クエスチョンはセミオープンクエスチョンと呼ぶこともできる。なお、「お話しください」といった漠然とした問いかけはフルオープン・クエスチョンに相当する。

　＜付言（１）＞
　本開示に示す種々のフローチャートは何れも一例であって、フローチャートを構成するステップの数や、処理の実行順は適宜変更可能である。また、本開示に記載の装置、システム、並びにそれらの手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。本開示に記載の装置及びその手法は、専用ハードウェア論理回路を用いて実現されてもよい。本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。ＨＣＵ３０が備える機能の一部又は全部はハードウェアとして実現されても良い。或る機能をハードウェアとして実現する態様には、１つ又は複数のＩＣなどを用いて実現する態様が含まれる。プロセッサ（演算コア）としては、ＣＰＵや、ＭＰＵ、ＧＰＵ、ＤＦＰ（Data Flow Processor）などを採用可能である。ＨＣＵ３０が備える機能の一部又は全部は、システムオンチップ（ＳｏＣ：System-on-Chip）を用いて実現されていても良い。

　また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体（non- transitory tangible storage medium）に記憶されていればよい。プログラムの記録媒体としては、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等を採用可能である。コンピュータをＨＣＵ３０として機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体等の形態も本開示の範囲に含まれる。

Claims

　ディスプレイに表示される選択肢に対する乗員の選択操作を受け付けるための操作デバイスからの信号、及び、音声認識によって特定される前記乗員の発話内容に基づいて車内機器を制御する車内機器制御装置であって、
　前記乗員の動き及び視線の少なくとも何れか一方を検出する乗員挙動センサの出力に基づき、運転席に着座している前記乗員である運転席乗員が、車両を走行させる操作をしている運転状態に該当するか否かを判定することと、
　前記操作デバイスからの信号に基づき、前記ディスプレイの表示画面を制御することと、
　前記運転席乗員が運転状態である状況において、操作制限の対象に設定されている画面である制限対象画面を呼び出す操作が行われたことを検出した場合には、当該制限対象画面に応じた、未入力の項目にかかる問い合わせメッセージを出力することと、
　前記問い合わせメッセージの出力と同時に又はその後に、音声認識機能を有効化することと、
　前記問い合わせメッセージ対する前記乗員の回答を音声認識により取得できた場合には前記制限対象画面に対応する機能の範囲において前記回答に応じた制御を実行することと、を実施するように構成されている車内機器制御装置。
　請求項１に記載の車内機器制御装置であって、
　前記問い合わせメッセージは、前記制限対象画面に対応する機能を前記乗員が利用するために必要な項目についての質問である車内機器制御装置。
　請求項１又は２に記載の車内機器制御装置であって、
　前記ディスプレイに表示している画面又は前記乗員によって選択された前記選択肢の情報に基づいて、現在の操作状態が所定の機能を実行させるための一連の操作の途中に該当するか否かを判定することと、
　前記操作状態が前記一連の操作の途中である状況において、前記運転席乗員が運転状態に移行したことに基づいて、現在の表示画面に応じた問い合わせメッセージを出力することと、
　前記問い合わせメッセージの出力と同時に又はその後に、音声認識機能を有効化することと、
　前記問い合わせメッセージ対する前記乗員の回答を音声認識により取得できた場合には前記現在の表示画面に対応する機能の範囲において前記回答に応じた制御を実施する車内機器制御装置。
　請求項１から３の何れか１項に記載の車内機器制御装置であって、
　前記運転席乗員は前記運転状態ではないと判定している場合には、さらに、前記乗員挙動センサ、又は、周辺監視センサ、又は、自動運行装置からの信号に基づいて、前記運転席乗員が運転準備状態に該当するか否かを判定し、
　前記運転席乗員が前記運転準備状態であると判定されている状況において、前記制限対象画面を表示する場合には、前記問い合わせメッセージの出力及び音声認識機能の自動的な有効化を含む音声入力案内処理を実施する車内機器制御装置。
　請求項１から４の何れか１項に記載の車内機器制御装置であって、
　前記乗員挙動センサの出力に基づいて、前記操作デバイスの操作者が前記運転席乗員であるか助手席乗員であるかを判別し、
　前記運転席乗員が前記運転状態である状況において、前記制限対象画面を呼び出す操作が行われたことを検出した際、前記操作者が前記運転席乗員と判定している場合には、前記問い合わせメッセージの出力及び音声認識機能の自動的な有効化を含む音声入力案内処理を実施する一方、前記操作者が助手席乗員と判定されている場合には少なくとも表示画面を切り替えてから所定時間は前記音声入力案内処理を実行しないように構成されている車内機器制御装置。
　請求項５に記載の車内機器制御装置であって、
　前記運転席乗員が前記運転状態である状況において前記制限対象画面を呼び出す操作が行われたことを検出した際、前記操作者が前記運転席乗員である場合には前記機能の実行にかかる選択肢を選択不能な態様で前記制限対象画面を表示する一方、前記操作者が前記助手席乗員である場合には前記機能の実行にかかる選択肢を選択可能な態様で前記制限対象画面を表示する車内機器制御装置。
　請求項５又は６に記載の車内機器制御装置であって、
　前記操作者が前記助手席乗員であると判定されている状況において、前記制限対象画面を表示してから所定時間経過しても他の画面に移る選択肢が選択されなかった場合、１つ前の画面を再表示した場合、及び、検索語として入力された文字列に対応する情報が見つからなかった場合の少なくとも１つの場合には、前記音声入力案内処理を実行するように構成されている車内機器制御装置。
　請求項５から７の何れか１項に記載の車内機器制御装置であって、
　前記運転席乗員が運転中、前記操作者が前記助手席乗員であることを条件に前記制限対象画面を前記乗員が選択操作可能な態様で表示している状況において、前記乗員挙動センサからの信号に基づいて前記運転席乗員が選択操作をしようとしていることを検知した場合には、前記音声入力案内処理を実行するように構成されている車内機器制御装置。
　インストゥルメントパネルの運転席の正面領域から助手席の正面領域まで伸びる連続的な表示画面を備える前記ディスプレイと接続されて使用される、請求項１から８の何れか１項に記載の車内機器制御装置であって、
　前記操作デバイスからの信号又は前記ディスプレイに表示している画面の種別に基づいて、操作者としての前記乗員が利用しようとしている機能である対象機能を特定することと、
　前記対象機能が、運転操作に関連する予め定められた運転関連機能に該当するか否かを判定することと、
　車載センサの出力信号に基づいて、助手席乗員がいるか否かを判定することと、
　前記助手席乗員が存在すると判定されているか否か、及び、前記対象機能が前記運転関連機能に該当するか否かの組み合わせに基づいて、前記ディスプレイの表示画面内における、前記対象機能に対応する操作画面の表示位置を変更することと、を実施するように構成されている車内機器制御装置。
　運転席用マイク、運転席用スピーカ、助手席用マイク、及び助手席用スピーカのそれぞれと接続されて使用される、請求項１から９の何れか１項に記載の車内機器制御装置であって、
　前記操作デバイスからの信号又は前記ディスプレイに表示している画面の種別に基づいて、操作者としての前記乗員が利用しようとしている機能である対象機能を特定することと、
　前記対象機能が、運転操作に関連する予め定められた運転関連機能に該当するか否かを判定することと、
　車載センサの出力信号に基づいて、助手席乗員がいるか否かを判定することと、
　前記助手席乗員が存在すると判定されているか否か、及び、前記対象機能が前記運転関連機能に該当するか否かの組み合わせに基づいて、前記問い合わせメッセージを出力させるスピーカ、及び、音声認識に使用するマイクの組み合わせを変更することと、を実行するように構成されている車内機器制御装置。
　請求項１から１０の何れか１項に記載の車内機器制御装置であって、
　前記機能の実行にかかる選択肢を選択可能な態様で前記制限対象画面を表示している状況において、
　前記乗員挙動センサの出力に基づき前記運転席乗員が前方に目を向けていることを検知した場合、
　周辺監視センサからの信号に基づき先行車両の発進を検知した場合、及び、
　前記周辺監視センサからの信号又は無線通信で外部から受信した信号に基づき、前方にある信号機が自車両の通行を許可する表示に切り替わったことを検知した場合の少なくとも何れか１つの場合には、
　前記制限対象画面に含まれる選択肢を選択不能な状態に切り替えることと、前記問い合わせメッセージを音声出力することと、音声認識機能を自動的に有効化することと、を実施するように構成されている車内機器制御装置。
　ディスプレイに表示される選択肢に対する乗員の選択操作を受け付けるための操作デバイスからの信号、及び、音声認識によって特定される前記乗員の発話内容に基づいて車内機器を制御する車内機器制御装置であって、
　前記乗員の動き及び視線の少なくとも何れか一方を検出する乗員挙動センサの出力に基づき、運転席に着座している前記乗員である運転席乗員が、車両を走行させる操作をしている運転状態であるか否かを判定することと、
　前記ディスプレイに表示している画面、又は、前記乗員によって選択された前記選択肢の情報に基づいて、現在の操作状態が所定の機能を実行させるための一連の操作の途中に該当するか否かを判定することと、
　前記操作状態が前記一連の操作の途中である状況において、前記運転席乗員が運転状態に移行したことに基づいて、現在の表示画面に応じた、未入力の項目にかかる問い合わせメッセージを出力することと、
　前記問い合わせメッセージの出力と同時に又はその後に、自動的に音声認識機能を有効化することと、
　前記問い合わせメッセージ対する前記乗員の回答を音声認識により取得できた場合には前記現在の表示画面に対応する機能の範囲において前記回答に応じた制御を実施することと、を実行するように構成されている車内機器制御装置。
　ディスプレイに表示される選択肢に対する乗員の選択操作を受け付けるための操作デバイスからの信号、及び、音声認識によって特定される前記乗員の発話内容に基づいて車内機器を制御する車内機器制御装置であって、
　前記乗員の動き及び視線の少なくとも何れか一方を検出する乗員挙動センサの出力に基づき、運転席に着座している前記乗員である運転席乗員が、車両を走行させる操作をしている運転状態であるか否かを判定することと、
　前記操作デバイスからの信号に基づき、前記ディスプレイの表示画面を制御することと、
　前記運転席乗員が運転状態である状況において、操作制限の対象に設定されている画面である制限対象画面を呼び出す操作が行われたことを検出した場合には、当該制限対象画面に応じた、未入力の項目にかかる問い合わせメッセージを出力することと、
　前記問い合わせメッセージの出力と同時に又はその後に、音声認識機能を有効化することと、
　前記問い合わせメッセージ対する前記乗員の回答を音声認識により取得できた場合には前記制限対象画面に対応する機能の範囲において前記回答に応じた制御を実行することと、を含む車内機器制御方法。