音声インタフェースは本当に人に優しいか？
Does Voice User Interface Realize the Human Centered System?
西本 卓也
Takuya NISHIMOTO
東京大学大学院 情報理工学系研究科
Graduate School of Information Science and Technology,
The University of Tokyonishi@hil.t.u-tokyo.ac.jp
Abstract
This paper outlooks the VoiceXML technology and gives the future directions of the voiceuser interface (VUI) systems. Though VoiceXML has the capability of writing a variety of interaction styles
using voice input and output eﬃciently, the usability of the applications which are built using the technology
is not considered. We give some investigations into the practical issues in building voice-portals and other
VUI applications, from the viewpoint of the human centered systems.

はじめにポータル（玄関）という考え方は Web のポータルサイトに由来する．一つの電話番号にアクセスすれインターネット関連技術を自動電話応答システム ば，電話をかけ直すことなしにさまざまなサービスをに応用したい，という要求から，XML (Extensible 続けて使えることがボイスポータルの利点である．
Markup Language) をベースとする音声対話パター
しかし，残念ながら，従来のパソコンや携帯電話のンのマークアップ言語 VoiceXML∗ が登場している． Web ブラウザに対応した HTML ベースの情報やサー音声を使ってインターネットに電話でアクセスできビスが，そのままボイスポータルで利用できるわけでるシステムは「ボイスポータル」と呼ばれている．す はない．Web の情報をそのまま音声化するのではな
でに実用化されているサービスを例に挙げると，明日
く，音声に適した表現に加工して提供することが重要の東京の天気を知るには、音声ガイドに従いながら順であり，それが VoiceXML という新たな記述言語が番に「天気案内」「東京都」「東京」「明日」と音声で命 必要とされた理由である．
令するだけで欲しい情報を聞くことができる．また，現在ボイスポータルで使われている技術では，定型乗換案内を検索する場合には「東京駅」「表参道」の 的な文法に従った音声入力しか行うことができない．
ように駅名をそのまま音声で入力できる．このように
しかし今後，自由な喋り方によって欲しい情報を選択
音声認識を用いることで，ボタンを押して操作していしたり，複雑な交渉を音声で行うことができるようにた従来の電話応答システムと比べて，使いやすく高機なると期待される．また，音声で検索した情報を携帯能になっている．
電話などの画面に表示する，いわゆるマルチモーダル
ボイスポータルによるサービスとしては，幅広い利ブラウザの技術も開発されている．
用者を対象とした一般向けサービスと，特定の利用本稿では，ボイスポータルと VoiceXML の技術を者に向けて企業などが行うサービスが考えられる．一 概観しつつ，「音声インタフェースは本当に人に優し
般向けサービスの主な内容としては，ニュース，天気いか？」という視点から，これらの技術が抱えている予報，占い，バンキング（銀行口座の振り込みや残高問題点を考察する．
確認など），株価情報，電子メールの読み上げ，など
音声インタフェース (Voice User Interface, VUI)†が挙げられる．また，特定の利用者向けのものとしてのためのさまざまな技術がすでに実用化の段階にあは，通信販売のテレビ番組を視聴した人が注文や問いる．しかし例えば，我々はいま気軽にボイスポータル合わせをする，航空会社の利用者がチケットの予約やを使いこなしているだろうか？活用されていないとす変更をする，といったサービスを人手によらずに提供れば，音声認識の性能が不十分だから，というだけのできる．
理由だろうか？

1∗ 現在 W3C より VoiceXML 2.0 Last Call Working Draftが公開中．http://www.w3.org/Voice/† 音声入出力を用いるインタフェースで，視覚等のモダリティを伴わないものをここでは VUI と呼ぶ．

表 1: VoiceXML を構成する技術入力出力転送

連続音声認識(Augmented BNF 相当の文法記述)，
数字キー入力 (DTMF)，
音声録音 (<record>)
音声合成 (TTS)，
録音音声 (<audio>)
ブリッジ転送およびブラインド転送 (<transfer>)

ヒューマンインタフェース技術は「人に優しい」ものでなければ，サービスやアプリケーションの利用者（ユーザ）に支持されない．また，ユーザに支持されるサービスやアプリケーションが，サービスやアプリケーションの開発者にとって容易に実現できるものでなければ，現実的な応用として普及しない．
実用サービスを前提に VUI 技術に取り組んでいる開発者と，長期的なビジョンを持って研究を進める音
声・対話研究者の間には，問題意識のギャップがあるように思われる．本稿がこのようなギャップを埋める一助になれば幸いである．

2

実行環境

VoiceXML を構成する技術を表 1 に挙げる．ボイ
スポータルはこれらの要素を用いて実現される．
VoiceXML を用いることにより，VUI と Web で提供される情報サービスが分離される．これは Web で動的なページを生成する処理系に似ており，VoiceXML
処理系（音声ブラウザ）は HTTP プロトコルでドキュメントサーバと通信する (図 1)．
音声ブラウザは 1 つのセッション（1 回電話をかけることに相当する）の中で複数の Web サーバと通信をすることができる．これが従来の電話音声応答シス
テムとの相違点である．パソコンに例えると，シング
ルタスク OS である DOS から複数のタスクを同時に起動して切替えながら使える Windows に移行したよ
うな状況である．

2.2

表 2: VoiceXML における対話制御
ダイアログ（対話）を単位とする記述
メニュー（システム主導）
フォーム（システム主導／混合主導）
グローバルな処理の概念
リンク（ユーザ主導）
グローバル変数による文脈情報管理
プログラミング言語
ECMAScript (JavaScript)

VoiceXML の現実

開発者が音声認識・合成の低レベルな制御を記述しなくても，VUI を用いたシステムを実現できるのがVoiceXML の特長である．本章では VoiceXML を構成する技術と主な機能について述べる．

2.1

図 1: VoiceXML と Web アーキテクチャの比較

対話制御対話は VoiceXML ドキュメントの遷移によって記述されるが，表 2 のようなさまざまなレベルの記述が混在可能になっている．
メニュー (<menu>) は，選択肢を列挙して音声で読み上げ，その内容を文法とする（文法の自動生成を行なう）ための簡略表記である．選択肢 (<choice>)には自動的に通し番号をつけることができ，DTMFの数字でも選択可能である．ユーザにとって音声認識を使うことは，「どの選択肢が何番であるか」を覚えるよりも，選択肢を名前で直接言える方が有益である，という場合であれば（数字キー操作と比較して）メリットが生じる．
フォーム (<form>) は，主に入力を行なうための対話要素であり，特長は発話の主導権を柔軟に制御できることである．変数に対応するフォーム項目 (<ﬁeld>)，入力を伴わないフォーム項目 (<block>)，非フォーム
項目の変数，イベントハンドラ，入力の後処理 (<ﬁlled>アクション) などを含む．フォームの実行には FIA(Form Interpretation Algorhythm) が用いられ，各フィールドに入力済みフラグを立てながら未入力のフィールドをシステム主導的に埋める手順が VoiceXML
仕様によって定義されている．

2.3

混合主導型対話

混合主導型フォームは，• フィールドを任意の順番で埋められる表 3: 対話タスクの分類と実現手法
a. 受動的な情報の取得<block>,<prompt> ，システム主導的，出力のみ
b. ページやサイトの選択（ナビゲーション）<menu>,<link>，システム主導的，孤立単語認識
c. 対話的な応対（トランザクション）<form> ＋ VoiceXML 動的生成
混合主導的 ABNF ベースの音声認識
d. 知的な検索や交渉（ネゴシエーション）
ユーザ主導的，ABNF ＋ NL Semantics

図 2: Voice Browser WG による標準化活動• 一つの発話で複数のフィールドを埋められるというユーザ発話から，• Region: 京都, HotelType:旅館という機能を持つものとして定義される．というスロット値は（複雑な記述によって）生成可システム主導対話のフォーム記述に対して，フォー 能だろう．
ムレベルの文法（スロット値を生成する属性が付与さ
しかし，真に自発発話で操作できるためには，ユーれる）と <initial> 要素を追加するだけで混合主導対 ザが任意の状態で発話 (1) を入力した場合に，話が記述できる．フォーム記述の仕様はすっきりして
1. Region と HotelType を入力するフォームに移いるが，フォームレベルの文法記述が複雑になるため，動する多くの開発者には使いこなしにくいと思われる．

VoiceXML の限界

3

現在 W3C の Voice Browser WG が VoiceXML 周辺技術（図 2）の標準化を進めている．本章では，この中の自然言語処理（意味解析・文脈解析など）モジュールを用いてどのような対話までが可能かを考察する．

3.1

対話タスクの分類と実現手法

ボイスポータルで実現しようとする対話タスクとVoiceXML アーキテクチャによる実現手法を表 3 に示す．要求する技術レベルの低い順に並んでおり，現在の VoiceXML では頑張れば c. が実現できる，という状況であるが，音声認識と対話制御の間で自然言語処理を行なえば d. を実現できる．

3.2

2. 当該フォームで (Region:京都, HotelType:旅館)を埋めるという処理を（1 発話に対して）実行して欲しい．
このように状態遷移を伴う代入は，現在の VoiceXMLでは不可能である．
また，どのような機能が使えるかユーザが分からない場合には，• 発話 (2) 料金も指定できるんですか？など逆質問の要求もある．この場合は，適切なヘルプを提示して，元のフォームに戻る必要がある．いったん他の状態に遷移した後に過去の対話状態に戻る制
御は，VoiceXML では簡潔に書けない．元の対話に遷移して，各変数の値も元の値を再現することは，スクリプトや動的ドキュメントを使わないと不可能である．これでは VoiceXML のメリットが活きているとは言えない．

自然言語処理と対話制御

VoiceXML における自然言語処理は，VoiceXML のスロット値や入力イベントと対応すると想定されている．
例えば，ホテル検索システムにおいて，• 発話 (1) えっとー，京都で宿泊を探しているんですけど，できれば和室でホテルじゃない方がいいです3.3

VoiceXML の課題

VoiceXML は電話音声応答システムに求められる現実的な要求を満たしつつ，スロットフィリング的な音声対話をうまく抽象化して取り入れている．しかし，全体としては「ページの更新＝状態遷移＝ドキュメントの切替」という HTML 的な発想，あるいは，「数字入力を想定したインタフェース」の影響を強く受けていて，必ずしも構築されたシステムの使い勝手は考慮されていない．
VoiceXML やボイスポータルといった技術は，限られた応用分野では生き残るかも知れない．しかし，使いやすいシステムを実現するために，複雑なプログラミングを併用したり，門外不出のノウハウを用いることが必須なのであれば，ボイスポータルはマイナーな技術に留まるだろう‡ ．開発者の裾野が広がれば広がるほど，使いにくい音声インタフェースが広まってしまう，という皮肉な状況になる．
複雑な技術を隠蔽して使いやすい VUI を作るためには，プロトタイピングツールが有効である．しかし，プロトタイピングツールを用いた場合でも，どのような VUI がユーザにとって使いやすいか，といった知見は必要である．さらには，開発者が素直に使えば，使いやすい VUI しか作ることができない，といったプロトタイピングツールが望ましい．

ボイスポータル向け音声合成がお金になるためには，ボイスタレントを雇うよりも高品質な音声が，安く実現できなくてはならない．
さらに，音声というモダリティに特有の要求として，情報をわかりやすく伝えるための語順の変更や，同音意義語を避けるための言い替えなども重要である（新聞記事テキストとニュース読み上げ原稿の違いにあたる）．
「モダリティ間のポータビリティ」を実現するためにはこのような問題も考慮しなくてはならない．

4.2

非言語音声の利用

ボイスポータルでは効果音や音楽などの非言語音声も重要であり，ユーザの認知負荷を下げる効果が期待される（音声言語と効果音は互いに干渉せずに知覚可能である，という仮説について，認知心理学的な検証が多く試みられている [4]）．視覚を伴わない VUI においては，ユーザは情報を聞いている間も「バージインするかしないか」を常に判断し続けている．従って，
4 VUI と対話研究の課題
ある情報の属性をユーザが短時間で知覚できる聴覚ア
音声入力をいかに使用し，対話制御をいかに行な イコンの役割は重要である [5]．
非言語音声の用法のお手本は放送（特にラジオ放送）
うべきか，といった問題には多くの研究成果があるが[1]，多くの開発者は使いやすいシステムを作るために であるが，記述方法としては Web のスタイルシート試行錯誤を続けている．本章では，VUI の構成要素 に類似した仕組みが好ましい．Web では HTML ファ
イルにコンテンツと属性（クラス名）のみを記述し，ごとに，いくつかの現実的な課題について論じる．
各クラスに対応するフォント，罫線，枠線といった情報はスタイルシートとして分離する．これと同様に，
4.1 音声出力の課題
VoiceXML の各プロンプトに，テキストとクラス名ボイスポータルの音声出力に求められているのは， のみを記述し，プロンプト開始や終了の効果音などの高い品質であり，ライバル（あるいは味方にすべき） 属性は外部のスタイルファイルを参照すればよい．
は「放送」である．
音声対話システムのユーザは一般的に，テキスト音
4.3 ヒューメイン・インタフェース
声合成の品質に不満を持っている．電話音声対話シス
人の要求に打てば響くように応答し，人の弱さに寛テムのスタイルガイド [2] や実践報告 [3] では，シス
Raskin[6] はヒュー容であるようなインタフェースを，テム発話には，やむを得ない場合を除いて録音音声をメイン（Humane, 人に優しい）インタフェースと呼使うべし，とされている．さらに，アプリケーション
んでいる．ヒューメイン・インタフェースは経験則でにふさわしい雰囲気を演じられるボイスタレント（ナはなく一般的な原則から導かれる，とされている．
レーターや声優）を選ぶこと，テキスト音声合成と混Raskin の主張する原則を以下に挙げる§ ．
在した場合に違和感が少ない声であること，よい環境や条件で収録を行なうこと，とされる．
1. ユーザの入力は絶対である
ボイスタレントの起用や収録にはコストがかかる．
ユーザの入力を無駄にしてはいけない「お金でクオリティが買える」のは出版・放送・広告
2. 時間の無駄・不要な作業をユーザに要求しないの業界構造である．すでに Web では即時性・応答性
ターン数や所要時間を短縮するや使いやすさが重視され，「クオリティよりもユーザビ自明なことをユーザに聞かないリティ」の時代になりつつある．しかし，ボイスポー
タルの世界ではまだ，音声出力のクオリティがインタ
3. ユーザのペースに合わせるフェース全体の足を引っ張っている．
不必要にユーザを待たせない
ユーザが時間を必要とするときには急かさない‡
余談だが，仮に VoiceXML が普及したら，VoiceXML のみでしか提供されないサービスが存在し得る．今度はアクセシビリ
ティの観点から，代替手段（例えばキーボード入力と画面表示）のみで利用できる VoiceXML ブラウザが必要になるだろう．

§ これらの原則を満たすインタフェース設計にあたって Raskin
は，定量的分析手法（情報理論的効率性）と定性的・発見的手法をバランスよく用いるべきである，と主張している．

4.5

モードレスなインタフェース

GUI においては，変化する画面の各状態がシステムのモードと対応しており，このような可視性が重要である [8]．VUI においては，ユーザにはモードが不可視である．ユーザがモードを意識して発話できないのであれば，すべての音声コマンド（文法）がグローバルに有効であるべきだ（特に車載用システムでの重要性は [9] で指摘されている）．
つまり，特定の語彙を一時的に無効化する（各フォームやメニューに含まれた文法のみを有効にする）のではなく，すべての発話を受理しつつ，ユーザの属性，
図 3: 学園祭案内のための音声応答システムの例
対話の履歴（ユーザが対話を通じて経験したものすべて），トランザクションの結果，などに応じて入力のVUI においては，例えば項目 1. から導かれるのは， 解釈を変えるべきである．
特に，検索機能は，ユーザをモードやコンテクストユーザ発話の履歴を音声データとして保存しておき，から解放する重要な機能である．例えば，ユーザの第認識エンジンがリジェクトした発話に対しても，対話一発話だけユーザ主導の自発発話を受理し，各タスクが進んだ後で過去の発話の認識を試みて，ユーザの再への分岐を行なう，といった手法は，VoiceXML では，発話の手間を減らす，といった手法である．
対話レベルではなく，アプリケーション（グローバル）レベルでの <link> 機能で実現できる．フォーム入力
4.4 ナビゲーション履歴の利用
中に履歴参照のメタコマンドを処理したり，ユーザがVoiceXML を使うと，HTML と同じ感覚で音声イ 怒ったら（怒ったということをスロット値やイベントとして認識して）人間のオペレータに転送する，とンタフェースを構築できる．だから，多くの開発者がHTML と同様，階層型のメニュー構成でサービスを いったことが，VoiceXML の枠組を活かしながら実現できる．
構築してしまう．しかし，視覚を伴わない音声ブラウ
ザで，階層メニュー構造を移動するのは大きな負担になる [7]．
4.6 発話タイミングの利用
例えば，図 3 のようなシステムで，交通アクセス認識できる語彙数が限られていても，バージインにを利用中のユーザが「映画情報」と発話する．システ
ムは映画情報に遷移するが，そこでユーザは交通ア よる入力タイミングを活かしたインタフェースは可能
クセスに戻りたいと思い，「戻る」と発話する．しか である．例えば，選択肢をシステムがゆっくり読み上げて，ユーザは選択したい項目で「それ」と発話する
し，VoiceXML には履歴管理の概念がないので，「戻だけの音声インタフェースが考えられる（VoiceXMLる」は多くの場合，一階層上の状態に戻る，としか定でも <noinput> で実現可能）．
「何も入力しないこと義されない．したがって，ユーザが意図しない状態にも，一つの操作と見なす」と考えればよい．
遷移し，ユーザは裏切られる．
ボイスポータルにおいて，目当ての情報に到達し「戻る」などの操作はメタコマンドの一種であるが，たあとで，情報をユーザが聞きとる段階は，使いやす
一階層上の状態に移動する機能を「戻る」メタコマンドに割り当ててしまうのは破綻しやすい仮定である． さの考慮が見落とされやすい．逆に，誰にでも使いこ特に VUI においては，ユーザはサイトの階層構造 なせる（ユーザがまったく操作しなくてもよい）究極のボイスポータルは 177（天気予報）などの音声情報を見通すことができない．また，状態がいつどのようサービスだろう．に遷移したかも，明示されないことが多い．このよう音声情報サービスの使い勝手を保ちながら対話的なな状況では，ユーザはただ時系列的にシステムを把握している．したがって，ユーザにとって「戻る」は，そ 検索を許す，聞き流し型（放送型）インタフェースというものが考えられる．我々が提案しているシステムのセッションの操作履歴の中を戻る操作でなくてはな
RadioDoc[10]は，階層的な情報を操作なしで聞き流らない（ただし VoiceXML では実装しにくい）．Web
ブラウザの「戻る」「進む」メタコマンドと同等の機 せる，グローバルな音声コマンドやメタコマンドで検索や頭出しができる，効率的にコンテンツを記述でき能を音声ブラウザが持つべきであり，履歴の中を音声る，といった特徴を持つ．
操作で自由に検索・移動できるべきだ．

認知負荷の低い対話ジェントなど他のコンテクストで流用されていくだろう．我々も独自の対話処理系 [11] に本稿で挙げたアイ
Web ブラウザのブックマーク機能を覚えないで，特 ディアを実装し検証する予定である．
定のサイトを開くために検索エンジンを使うユーザはユーザが喋る必然性のあるアプリケーション選びも多いようだ．効率的かどうかわからない新たな機能を重要である．ハンズフリー・アイズフリーが要求され学ぶよりも，毎回同じ操作で目的が達成できることがる車載機器が代表的だが，我々は，音声の録音そのも好まれている．のが目的であるアプリケーション [12][13] では VUI がRaskin[6] は，ある作業を達成するために方法が一 受け入れられると予想する．視覚障害者や高齢者のたつしか用意されておらず，コマンドと操作が一対一にめの応用も重要である．新たなアプリケーションを提対応するならば，学習容易性（慣れるに値する，やみ案することで，有用な VUI の選択肢が広がるものとつきになる）など大きなメリットがある，と主張する． 考えている．
このような性質はモノトニーと呼ばれており，モードレスと対を成す重要な概念だとされている．
参考文献
慣れるに値するインタフェースとは，単に定量的に効率性が求められるだけではなく，例えば車載イン[1] 新美康永: 音声対話システムの対話制御, 日本音響学会誌 54 巻 11 号, pp.791-796, 1998.
ターネット機器などに用いた場合に認知負荷が低い（運転の妨げにならない）といったものであろう．そ[2] Bruce Balentine, David P. Morgan: How to Builda Speech Recognition Application, 2nd Ed., EIG
こで我々は，二重課題法 (dual-task performance)[4]Press, 2001.
を用いて音声対話そのものの負荷測定を試みている．

4.7

4.8

定番化と抽象化Web の黎明期にはサイトごとに多様な画面デザインが用いられたが，現在はタイトル，コンテンツ，ナビゲーション，検索ボックスなどを有する定番デザインが確立している．同様の「VUI の定番化」が進めば，有用な対話制御方式が仕様の一部となり，繁雑な記述をせずともコンテンツが記述できるようになるだろう．
VoiceXML はスロットフィリングの記述性がすぐれているが，コンテンツとインタフェースがうまく分離できていない部分が多い．開発者が静的情報としてタスクのみを抽象的に表現し，ユーザ属性や履歴に依存した動的な対話制御は音声ブラウザが自動実行するようになればよい．

5

まとめ[3] 大本浩司，牛田博英，中嶋宏，石田勉: 電話音声で情報提供を行なうアプリケーションの UI 設計と評価の実践報告, ヒューマンインタフェース学会研究報告集
Vol.3, No.4, pp.35-40, 2001.
[4] Nick Rund: Attention and Pattern Recognition,
Routlege Modular Psychology Series, 2001.
[5] 高山元希, 西本卓也, 荒木雅弘, 新美康永: 電話音声応答システムにおける効果音の役割, 信学技報, SP-2001132, pp.55-62, Jan., 2002.
[6] Jef Raskin （村上雅章 訳）: ヒューメイン・インタ
フェース, ピアソン・エデュケーション, 2001.
[7] 西本卓也, 荒木雅弘, 新美康永: 擬人化音声対話エー
ジェントのためのタスク管理機能, 日本音響学会講演
論文集, 1-5-15, pp.29-30, Mar., 2002.
[8] Donald A. Norman, （野島久雄 訳）: 誰のためのデザイン？−認知科学者のデザイン原論, 新曜社, 東京,
1990.
[9] 北岡教英，加藤利文，杉浦恒，赤堀一郎: 車載機器用音
声対話システム, 情報処理学会研究報告, 96-SLP-1212, pp.57-62, 1996.
[10] Takuya Nishimoto, Masahiro Araki, Yasuhisa Ni-imi: RadioDoc: A Voice-Accessible Document Sys現在の VoiceXML は，数字入力 (DTMF) 時代のtem, Proc. ICSLP2002, pp.1485-1488, Denver, Sep.,
発想で設計されている．また，GUI と VUI が同じよ2002.
うなものである，という誤解もあったようだ．結果的[11] 岐津三泰, 西本卓也, 荒木雅弘: 擬人化エージェントのに，スタイルガイドやノウハウなしに構築されたボイための VoiceXML 処理系の開発, 人工知能学会 SIGSLUD-A201-01, pp.1-6, Jun., 2002.
スポータルは VUI の利点を生かせていない．
洗練された VUI のスタイルは，人に優しいインタ[12] 西本卓也, 幸英浩, 川原毅彦, 荒木雅弘, 新美康永: 非同フェース，という視点から確立されるべきである．そ期型音声会議システム AVM の設計と評価, 電子情報通信学会論文誌 D-II, Vol.J83-D-II, No.11 pp.2490のために，有用性が示された研究レベルの技術も，既2497, 2000.
存の技術に当てはめつつ，盛り込んでいくべきである．
[13] 住吉悠希, 西本卓也, 荒木雅弘, 新美康永: インター
将来的に VUI 記述言語は，現在の VoiceXML 仕様
ネットラジオ番組制作支援ツール, インタラクションが持つタスクの抽象的記述機能のみが独立して，ユー
2002, pp.153-154, Mar., 2002.
ザと開発者の双方に有用なものに発展するだろう．また，汎用性の高い機能はマルチモーダルや擬人化エー