対話分析に基づく視覚障害者用音声対話システム
藤原扶美*1 下永知子*1

渡辺隆行*1 西本卓也*2

Development of a dialog system for the visually impaired based on human-to-human dialog
analysis
Fumi Fujiwara*1, Tomoko Shimonaga*1, Takayuki Watanabe*1, and Takuya Nishimoto*2
Abstract-

A prototype lunch delivery Web system for the visually impaired was developed based on the analysis of human (thevisually impaired who wants to order a lunch) to human (the sighted who helps the visually impaired to decide lunch by reading
aloud lunch menu) dialog. Firstly, human-to-human dialog was analyzed qualitatively to find important points of the dialog.
Secondly, the dialog was analyzed in terms of the intension of a speaker.

Based on these analysis, the prototype system wasdeveloped, which consists of three steps: 1) rough selection (candidate items are roughly selected based on categories), 2) selectionof favorites (favorite items are selected from candidate items and stored in the system), and 3) final selection (one item is selectedwith detailed information for each item).

The evaluation of the prototype system by the visually impaired shows that 1) the user canselect a lunch item with this system, 2) the user said the system is better than human-to-human dialog because he could easily
retrieve past information, i.e. navigate back in a page, 3) the current Web page is easy to understand, 4) "go back" function isnecessary, and 5) the user prefers XHTML Web site rather than VoiceXML site.

Keywords :visually impaired, human-to-human dialog, XHTML, delivery service

1.

はじめに

成に必要な知識や経験を持っている。さらに、図書館等
において、視覚障害者と対面で依頼された書籍の朗読を視覚障害者の日常生活の中で、情報の収集に関する制
約は、最も大きな不自由のひとつである。今日、音声認
識や音声合成など諸要素技術の応用としてもさまざまな音声対話システムが研究開発されているが、視覚障害者のニーズを的確に把握して音声対話システムが開発された事例は少ない。
現在コンピュータを利用している視覚障害者は、スクリーンリーダ（画面を音声や点字でユーザに伝えるソフトウェア）によって文書を作成したりウェブやメールを利用したりしているが、いずれもコンピュータが一方的に読み上げるシステムで、人間同士で対話をするように行う、といったボランティアの経験を積んでいる。このような対面朗読者と視覚障害者の対話を分析することで、視覚障害者のニーズを満たしたシステムが実現できると期待される。
本研究ではまず、視覚障害者と対面朗読者の対面朗読実験を行い、その対話を書き起こし、意図タグを付与す
るなどの処理を行って、対面朗読者と視覚障害者の対話の構造を分析する。次に、分析の結果明らかになった対話の特徴をシステムに実装することを試みる。最後に、作成したシステムを用いて被験者実験を行い、システムの有効性を評価する。

コンピュータを扱いたいという要求とは程遠い。
2.

本研究の目的は、視覚障害者を支援する際に行われる対面朗読実験

対面朗読実験の概要

人間同士の音声対話を分析し、その結果明らかとなった

2.1

対話の構造や特徴を、音声対話システムの設計に反映す

対面朗読者と視覚障害者の対話を観察するため、対面ることである。

朗読実験を行った。1 回目の対面朗読実験は、2005 年 6

我々は、視覚障害者を支援する対話を上手に行えるの月 25 日に、対面朗読者 X さん（女性）と視覚障害者 Aは対面朗読者である、と考える。本報告の実験に協力しさん（男性）で行った。2 回目の対面朗読実験は 2006 年

た対面朗読者 X さん（女性１名）は、長期間にわたって

6 月 3 日に、前回と同じ X さんと、視覚障害者の B さん

音訳ボランティアの講習を受けており、録音図書等の作（男性）で行った。視覚障害者の A さん、B さんは、出生後まもなく視力を失った全盲の視覚障害者である。

*1: 東京女子大学現代文化学部*2: 東京大学大学院情報理工学系研究科*1: Tokyo Woman’s Christian University*2: The University of Tokyo.

課題は、両実験ともに、実在する弁当屋“元気屋” 1

1: http://www.genkiya.co.jp/

のメニューの中から食べたいものを選んで注文すること

メージしやすいラベリングすることが重要であることがである。1 回目の実験では時間制限を設けなかったが、わかった。一方、対面朗読者の発話は約 9 割が｢陳述｣で対話が余談にそれてしまったので、時間制限があった方あったことから、システムは、利用者の依頼、質問に応が効率よいお弁当選びができると考え、2 回目は 15 分のじるための情報を幅広く、そして細かく把握しておく必

時間制限を設けた。被験者のモチベーションを高めるた

要があることがわかった。さらに、対面朗読者の｢提案｣めに、昼食の時間帯から実験を始め、実際に選んだお弁によって、候補のお弁当の絞込みや追加を助けていたこ

当を実験の後に注文するという設定で行った。対面朗読とから、気の利いた情報を提案する能力があると、シス者の X さんと視覚障害者はテーブルをはさんで向かい合テムが利用者をうまくサポートした効率の良いお弁当選って座り、全ての対話の様子をビデオに録画した。

びができると思われる。

その後、文献[1]に示した方法に従って、録画した対話を全て書き起こし、意図タグを付与して分析した。
2.2

対面朗読実験の結果

2.2.1 重要点
Ａさんの実験結果は文献[2]で報告済みだが、ここでは二人の結果をまとめて報告する。

また、利用者の発話「なんとなく揚げ物は避けたい」
や「和風のものはありませんか？」から、体の調子やメニューの系統から利用者の要望に沿った絞込みが、効率
よいお弁当選びにつながるのかもしれない。
更に利用者は、このような条件を指定した後に、「ざっと順番に言って下さい」と、条件にあったお弁当名の陳

被験者を 2 名に増やして実験を行った結果、文献[2]と述を依頼していた。そして、陳述を聞いた後、「幕の内御同様に、音声対話システムには、4 つのポイントが重要

膳、ブリの照り焼き御膳、しょうが焼き弁当、すきやきであることが確認できた。具体例とともに下記に記す。

弁当が心に残りました」と発話し、これらの詳細を比較

1.

2.

目的とする情報に早く誘導する工夫

して、購入するお弁当を決定した。我々は、この 3 ステ

対面朗読者は、「どんな系統から選びたいですか？」

ップ、つまり(1) 全体メニューの中から食べたいお弁当の条や、「大雑把には、お膳物です」など、相手の希望件にあったものを抽出し、(2) その条件にあった商品の中でを聞いて絞り込もうとしたり、「大雑把には〜」と特に気に入ったものをストックし、(3) ストックしたものの詳細いう表現を用いて大まかなメニューをブラウズし比較をして、実際に購入するお弁当を決定する。が、数あるていた。

ものから一つを選ぶときに最も重要な流れではないかと

頷きや相槌、割り込みなどの双方向性考えた。

利用者は、対面朗読者の発話に対し、頻繁に相槌を3.

音声対話システムへの提案

うち、発話が順調に進んでいることを示していた。
また、相槌が行われない場合、対面朗読者は「いま申し上げたのでイメージできますか？」と利用者に3.

対面朗読実験の結果から、以下の要素が音声対話シス
テムに必要であることがわかった。
3.1

いた。

1.

理解しやすいカテゴリにわける。

2.

想像しやすいラベルをつける。

3.

予算、食材、系統、体調など、様々な条件で絞り

音訳マニュアルを活用する音声化の工夫
お弁当名や値段など、利用者が重要とする情報をは込める。

っきり発音するなどの工夫がみられた。その他、対面朗読者は、「御膳…混ぜご飯みたいな…2000 円で3.2

二重、お重、あの二重三重ってありますでしょ、何1.

しい漢字の説明を行っていた。
記憶の負荷をサポートする工夫

2.

2.2.2 で示した 3 ステップの流れを用いる。

3.

利用者が興味を示したメニューは“お気に入り”とし、システムが記憶し、後で再利用できる。

対面朗読者は、「あなたがさっき気になったとおっ
しゃったすきやき弁当の中身はですね…」というよ

音声対話の流れ
利用者がお弁当の選び方について、戦略を選択できる。

重、そのお重になっていて」というように、紛らわ
4.

メニュー

伝わっているか確認し、必要に応じて再度説明して4.

興味がないメニューは、制約条件（次回から非表示にする対象）の一つとして扱う。

うに、利用者が興味を示したお弁当を記憶していた。

音声対話の機能

2.2.2 意図タグ付与の結果

3.3

視覚障害者の発話は、約 8 割が｢検索」を求める｢依頼｣1.

常に認識可能な音声コマンドを用意する。

であり、メニューの大局的理解のために、お弁当の系統

2.

気の利いた情報をシステム側から提案する機能を用意する。

や値段の分布を検索していたことがわかった。また、
「桜」

その他

という名のお弁当など、イメージしにくい情報の補助を3.4

検索する場面も多々見られたため、メニューをわかりや

1.

音訳マニュアルの注意点に従う。

すいカテゴリにグループ分けし、すべてのカテゴリにイ

2.

相槌の確認をし、必要に応じて再度説明する。

3.

余談や笑いなどの拡張機能があれば面白い。

「自然な対話の流れで選ぶことができた」という意見が模擬対話実験

あった。ユーザを混乱させることなく、システムがうま

4.

くサポートすることができたといえよう。
上記の提案を元にメニューを再作成し、お弁当を注文する対話の流れを設計した。
メニュー作成4.1

お弁当の値段と中身を参考に、イメージしやすいお弁
当名と、イメージしやすいお弁当の種類（特上、上、並）、
和洋中の系統 2、メインディッシュの系統（肉、魚、ごはん）2 の属性を各お弁当に付加し、計 6 項目の情報で一覧表にまとめた。
対話の流れの作成

4.2

3.2 をもとに、音声対話の流れを図式化したフローチャートを作成した。
模擬対話実験概要

4.3

これらをシステムに実装する前に、4.1 と 4.2 をもとに模擬対話実験の結果、音声対話システムにおいて以下のことが特に重要であることが確認できた。この結果をもとに次章で述べるシステム実装に取り組んだ。
1.

戦略をユーザが選択できるようにする。

2.

イメージしやすい情報を与える。

3.

絞り込みやすいカテゴリ（値段、系統、メインディッシュの系統など）を用意する。

4.

るようにする。
5.

次の 3 ステップを用いる。
(1)全メニューから食べたいお弁当の候補のカテゴリを絞り込む。

有効性を評価した。

(2)カテゴリの中のお弁当名を聞いて 5 品未満のお実験は、2006 年 8 月 29 日と 30 日に東京女子大学で行気に入りを選ぶ。

った。被験者はこの研究のことをまったく知らない女子(3)お気に入りのお弁当の詳細比較をして決定す大生 4 名である。二人一組になってもらい、一人がシス
定で 1 日 1 回計 2 回行った。実験者は、データベース検利用者が混乱していたり、迷ったりして返答がない場合は、システムが提案する。

6.

マニュアル（付録参照）を作成し、模擬対話実験でそのテム側、もう一人がユーザ側（視覚障害者役）という設品数を適宜表示し、次の行動を利用者が判断できる。
7.

常に認識可能なコマンドとして、「メインメニュ
ー」「戻る」「もう一度」「終了」を用意する。

索係が一人、メモ係が一人である。また、ビデオ収録も5.

行った。
課題は、システム側がマニュアル通りに対話を進めて

5.1

XHTML 実装

XHTML 実装の概要

いき、ユーザ側がシステム側との対話だけで、お弁当の我々は、模擬対話実験の結果をもとに、VoiceXML を

メニューの中から食べたいものを選ぶというものである。

用いた実装と XHTML を用いたサイト実装を考えている。

ユーザ側とシステム側はお互いの顔が見えないよう、二

本論文では、このうち XHTML の実装について述べる。

人の間についたてを用意し、実験者は対話に介入しないという原則を設けて行った。
ユーザは、初回は自分の好きなようにお弁当を選び、模擬対話実験から得られた結果をもとに、XHTML でお弁当を注文するページを実装した。その際、音声ブラ
ウザでの閲覧にも配慮した。
XHTML 実装の詳細

その後、実験者の指示により、別の戦略（マニュアルの5.2

ステップ１で提示する 3 種類の方法）でお弁当を選ぶ課

XHTML 実装にあたっては、ユーザの選択により提示題を行った。
4.4

模擬対話実験結果する情報を変えるため、PHP と PostgreSQL を使用した。
また、クライアント側で JavaScript を使用した。これ

対面朗読実験では、お弁当選びに、A さんは 40 分、Bは、商品の詳細情報を表示するのにポップアップで出しさんは 20 分かかった。それに対し、今回の模擬対話実験

たウィンドウを閉じるためと、フォームから情報を送信

では、時間制限を設けなかったにも関わらず、6 回全てする際に全てのチェックボックスにチェックが入っていのお弁当選びが 15 分以内に収まった。このように短い時なければアラートを出すために使った。

間で課題を達成できた理由として、以下二つが考えられ5.2.1 データベース

る。

PostgreSQL には、模擬対話実験でシステム側が保持し

1.
2.

対面朗読実験で得た知見をもとに、3 章で示したていた情報（メニュー、候補リスト、制約リスト、お気ような点に注意してマニュアルを作成した。

に入りリスト）を保持した。また、ログを取るためのテ

データベース検索係がコンピュータを使用して素ーブルも用意した。

早い検索をしたり、システム側の人間がお気に入りや制約条件を記憶したりして、利用者の記憶の負荷を軽減した。
実験後にユーザ役に対して行ったインタビューでは、

2: 模擬対話実験以前は 5 項目あったが、実験により、5つは記憶に負荷がかかることがわかったため、3 項目にまとめた。

表１ products テーブル
Table 1 Table “products”.
カラム名product_id
product_namepricekind_idcontents
style1style2style3
main1
main2
main3

説明
商品 ID
商品名
値段
お弁当の種類（特上、上、並）
商品（お弁当）の中身「和風」か否か「洋風」か否か「中華風」か否か「肉メイン」か否か「魚メイン」か否か「ごはんメイン」か否か

表５ log_category テーブル
Table 5 Table “log_category”.
カラム名
log_category_id
kind1
kind2
kind3
price1
price2
price3style1style2style3
main1
main2
main3

説明
カテゴリ絞り込み ID「特上弁当」を選択したか否か「上弁当」を選択したか否か「並弁当」を選択したか否か「800 円未満」を選択したか否か「800 円以上 1000 円以下」を選択したか否か「1200 円以上」を選択したか否か「和風」を選択したか否か「洋風」を選択したか否か「中華風」を選択したか否か「肉メイン」を選択したか否か「魚メイン」を選択したか否か「ごはんメイン」を選択したか否か

表２ log_t テーブル
Table 2 Table “log_t”.
カラム名
log_idsession_id
page
step1
optionlog_restrict_id
log_bookmark_id
flag
create_date
update_date

説明
ページ遷移ログ ID
セッション ID
ユーザが見たページ
ステップ 1 で選んだ選択肢
各選択肢による情報
制約リスト ID
お気に入りリスト ID
有効なログか否か
ログ作成日時
ログ最終更新日時表３ log_bookmark テーブル
Table 3 Table “log_bookmark”.
カラム名
log_bookmark_id
product_id

説明お気に入りリスト ID
商品 ID

表６ log_search テーブル
Table 6 Table “log_search”
カラム名
log_search_id
log_keyword_id

説明
検索 ID
検索キーワード ID

表７ log_keyword テーブル
Table 7 Table “log_keyword”
カラム名
log_keyword_id
keywordkeyword_flg

説明
検索キーワード ID
キーワード
キーワードを含むものを検索する
か、含まないものを検索するか

3 の log_bookmark テーブルと表 4 の log_restrict テーブルで商品 ID と結び付け、各リスト情報を保持した。リストに変更が加えられると新しいリスト ID が振られ、新たに

表４ log_restrict テーブル
Table 4 Table “log_restrict”.
カラム名
log_restrict_id
product_id

説明
制約リスト ID
商品 ID

情報がテーブルに挿入される。step1 には、ステップ 1 で選んだ選択肢の番号が入る。option に入る情報はステップ 1 で選んだ選択肢によって変わる。ステップ 1 で選択
肢 1 を選んでいればカテゴリ絞り込み ID が入り、選択肢
2 を選んでいれば検索 ID が入る。それらの ID は表 5 の
log_category、表 6 の log_search でお弁当選択の情報と結びつけられる。カテゴリ絞り込みの情報や選択肢 3 を選

模擬対話実験で作成したメニュー情報は、表 1 のproducts テーブルに保持した。

んでいれば、全ての商品を値段の高い順に読み上げるか安い順に読み上げるかという情報が入る。

新しいページへ移る度に、どのページを開いたかといステップ 1 で選択肢 1 を選んだ場合、表 5 のう情報とともに状態や選択した情報を表 2 の log_t テーブ

log_category テーブルにどのようにカテゴリを絞っていルに保持した。まず、この XHTML 実装では、ユーザのるかという情報を保持した。

判別にセッションを使用している。このテーブルにセッステップ 1 で選択肢 2 を選んだ場合、表 6 の log_search

ション ID を保持することで、ユーザとユーザごとの情報

テーブルと表 7 の log_keyword テーブルに、どのような（制約リストとお気に入りリスト）とを結び付けた。制キーワードをどう組み合わせて検索しているかという情約リストとお気に入りリストにはそれぞれ ID を振り、表報を保持した。

に戻す。

5.2.2 模擬対話マニュアルに基づく設計
模擬対話実験で作成したマニュアル（付録参照）を適用する。
まず、マニュアルをもとに、一ページにつき一質問を

3.

ステップを「戻る」。前のステップとそのときの状態に戻したり、ステップを繰り返す前の状態に戻したりする。

原則として、フォームの送信かリンクの選択によってペまず、1 の「戻る」については、ページ単位ではなくージを遷移させる。たとえば、ステップ 1 の、まずお弁セッションとデータベースで情報を保持しているため、当の種類を選び、次にさらに絞り込むか聞き、「はい」で使用を禁止した。

あれば値段、和洋中、メイン…と聞いていくところの場

次に、2 の「戻る」については、同じ意味を持つ「戻合、一般的なサイトであれば、それらをまとめて一ペーる」コマンドが模擬対話実験で使われなかったため、実ジの一フォームで入力してもらい、一度に結果を表示す

装しなかった。

るだろう。しかし、我々はマニュアルに基づいて、判断

そして、3 の「戻る」については、マニュアルにしたの最小単位ごとにフォームで送信してもらい、ページをがって、ステップ 2 の最後とステップ 3、ステップ 1 で遷移させた。また、模擬対話実験結果より、分類は 5 種

選択肢 2 を選び、検索に該当する商品がなかった場合の類でも記憶に負荷がかかり、3 種類に統一することが望ページに、前のステップに戻る機能をつけた。

ましいことが分かっている。各条件についての質問を同

5.2.4 ユーザビリティとアクセシビリティ

時に行えば、分類が増えることによるものだけでなく、音声ブラウザを使って閲覧することを意識し、ユーザ複数の質問を覚えることによる記憶の負荷も予想される。

ビリティとアクセシビリティを考慮した。

よって、まずお弁当の種類を選ぶページがあり、次にさらに絞り込むか聞くページを出し、「はい」であれば、値段は値段のページ、和洋中は和洋中のページ、メインディッシュはメインディッシュのページで聞くようにした。
ただし、ステップ 2 の「候補からお気に入りを選ぶ」
については、マニュアルでは商品ごとに残すか消すか詳細を聞くか尋ねていたが、商品ごとにページを分けると読み直して商品を比較することができなくなるため、一ページで表示した。また、「候補からお気に入りを選ぶ」
ページから詳細情報を見る場合は、ユーザが各商品の詳細情報を見るかどうか選べるようにするためと、すぐに「候補からお気に入りを選ぶ」ページに戻れるようにするため、ポップアップで新しいウィンドウを開くものとした。
5.2.3 常に使用可能なコマンド
模擬対話実験では常に使用可能なコマンドとして「メインメニュー」「戻る」「もう一度」「終了」を用意した。
今回はそのうち、「メインメニュー」と「終了」コマンドを常に実行可能なコマンドとする。また、現在のお気に入り商品について、常に表示する。それらのコマンドと情報は、各ページの最後（最下部）に表示する。
「もう一度」については、ユーザが音声ブラウザで同じページをもう一度読み直すことが可能なので、XHTML
側では実装していない。
「戻る」についてだが、まず「戻る」には三種類ある。
1.

履歴を「戻る」。前に表示したページを単純にもう一度表示する。ページ外の情報（セッションや
データベースに保持されているもの）は戻る前のままである。

2.

ページを「戻る」。前に表示したページを単純にもう一度表示するだけでなく、ページ外の情報も含め、そのページを以前表示したときと同じ状態

図１ ページの例（メニュー選択）
Fig.1 Example Web page (Menu selection).
たとえば、図 1 のメニュー選択ページでは、テーブルを使っている。テーブル一行目の列名、「メニュー名」「説明」「候補に残す」はそれぞれ th 要素としており、
scope 属性を col（列）としている。このようにして、「特上弁当」は「メニュー名」に、チェックボックスは「候補に残す」に関連付けられている。同様に一列目のメニ
ュー名、「特上弁当」「上弁当」「並弁当」は th 要素で
scope 属性を row（行）としている。これによって、音声
ブラウザを設定すれば、セル内の情報を読むときに、どのメニューについての何の情報かということも同時に読み上げられる。
また、このテーブルには「候補に残すメニュー」という caption 要素と「メニューの中で候補に残すものを選び

実験結果ます。3 列目にチェックボックスがあり、候補に残す場

6.3

合はこのチェックボックスをチェックしてください。」とA さんは最初、ステップ 1 で、マニュアルにおける選いう summary 属性をつけた。音声で読み上げたときに、択肢 1「条件に従ってお弁当のカテゴリを絞り込む」を「何のテーブルか」「どこに何があるのか」「何を選択す選んだが、メニュー全体の説明を聞いたところでやめた。

ればいいのか」という情報を、あらかじめ提供するため

そして、メインメニューに戻り、選択肢 3「73 品全てのである。

お弁当を読み上げる」方法をとった。後でインタビュー

その他、ページのコンテンツとページ下部の共通ナビ

したところ、ステップ 1 で一つ目のカテゴリがほぼ値段

ゲーションを視覚的にだけではなく音声的にも区切るたで分けられていることを知り、下手なカテゴリで分けらめに、「メインメニュー

終了」の前に透明な gif 画像をれているよりは 73 品くらいであれば全て聞こうと思っ

入れ、画像の alt 属性を「ここから共通ナビゲーションでたと言う。73 品の名前をざっと聞き、取捨選択し、気にす」とした。

なるものについては詳細情報を調べた。もし全ての商品ページの最初の「メニュー選択」はレベル 1 の見出し数がその倍あったならば、全てを読み上げず、違う方法であり、ページのトピックを示している。他のページにをとっていたかもしれないが、まず最初に全体を見通しついても同様にトピックを示す見出しをつけた。

たいと言うことだった。

視覚障害者による XHTML 版の評価

6.

視覚障害者に XHTML で実装したサイトを使用してもらい、使用状況の観察、分析、実験後のインタビューをもとに XHTML 版の評価、考察を行った。
6.1

目的

以下の点を調べることを目的とする。
1.

人間同士の対話からの知見が、音声ブラウザを使って読まれるサイトの作成に有効か。

2.

模擬対話実験結果から得た音声対話システムにおける重要点（4.4 参照）の評価。

3.

人間同士の対話からの知見を活かしたサイトと、
一般的なサイトとの相違点。

6.2

方法

実験は、2006 年 11 月 3 日に東京女子大学で行った。
被験者は、視覚障害者の A さんである。A さんは 2005
年 6 月に行った対面朗読実験の被験者でもある。
課題は、XHTML 実装したサイトを使い、4.1 で作成したメニューの中から食べたいものを選ぶというものである。また、ブラウザの「戻る」は使ってはならない、と教示した。
実験は、スクリーンリーダ JAWS 6.2 を使って行った。
A さんは、JAWS を一年以上使っており、操作に慣れている。しかし、パソコンはこちらが用意したものである
ため、実験に入る前に自由に操作させ、キー配列を覚えたり、自分が使いやすいよう JAWS の設定を行ったりした。話速は標準の 3 倍速に設定された。
XHTML 実装したサイトを使用する様子をビデオ録画するとともに、ページ遷移とフォームに入力した情報の記録を PHP で自動的に取った。また、課題達成後にインタビューを行い、XHTML 実装の主観的評価をしてもらった。一度実験を終えた後、今度は違う戦略でもう一度お弁当を選んでもらった。
今回は、課題達成時間も評価に用いるため、対面朗読
実験における 15 分という時間制限はなくした。

ステップ 1 で選択肢 3 を選ぶと自動的にステップ 2 に進む。ここで A さんは、全ての商品 73 品からお気に入り 19 品に絞った。ここで 17 分 33 秒かかった。お気に入りに残った 19 品のうち、このとき詳細を読んだのは 12品であり、詳細を読んだがお気に入りにしなかった商品
は 3 品だった。
次に、ステップ 2 を繰り返し、お気に入り 19 品の中から 8 品に絞った。ここでは 2 分 42 秒かかった。このとき詳細を読んだのは 1 品である。この商品は、19 品に絞ったときにも詳細を読んでいるが、ここでお気に入りから消された。
その後、もう一度ステップ 2 を繰り返し、お気に入り
8 品の中から 1 品に絞った。ここでは 1 分 29 秒かかった。
このとき詳細を読んだのは 4 品である。そのうち詳細を読むのが 2 回目なのは 3 品で、その 3 品の中から 1 品をお気に入りに残した。
最後に、ステップ 3 に進み、その商品に決定した。すべてを終えるまで、26 分 59 秒かかった。73 品全ての商
品を読み上げる方法をとってから、24 分 31 秒である。
次に、インタビューの結果を述べる。
A さんは普段、「戻る」を多用する。これは、5.2 で挙げた三種類の「戻る」のうち、履歴の「戻る」である。
しかし、今回はブラウザの「戻る」を使えなかった。そのため、「絞りこみすぎると戻れない」という考えから慎重策をとったと言う。
二度目の実験は、お弁当のカテゴリを絞る方法をとる
ように指示した。このとき、「きちんとしたカテゴライズがされている」という評価を受けた。しかし、どういう順でカテゴリを絞っていくか先行きが分からず、また、ユーザからは何で絞るかという選択や優先順位付けができないため、「肉メインのものが食べたいのに、値段や和洋中で絞られてしまったら」というような心配をしたと言う。
対面朗読実験と今回の実験を比較した結果、A さんは今回の方が良い印象を持ったそうだ。ページ内の情報であればカーソル移動で簡単に読み直すことができるから「5. 利用者が混乱していたり、迷ったりして返答がなである。これらのことを、言語で対面朗読者に伝えて行い場合は、システムが提案する」について、今回はまだってもらうのは大変だと言う。仮に音声認識を用いたと実装できていない。

しても読み直しの指示が面倒だと思われるので、A さん
は XHTML 版の方がいいと言う。
楽天のショッピングサイトと比較してもらったところ、「7. 常に認識可能なコマンドを用意する」について、
今回、5.2.3 で挙げた中の「ステップを『戻る』」しか用意していなかった。しかし、ステップ間の「戻る」だけ

このサイトは、ページにコンテンツを絞り込めている点ではなく、その時の状態も含めてページごとの「戻る」が良い、という評価だった。ナビゲーションスキップがも必要だということがわかった。

入っているサイトも、読み上げられる中で「本文へジャ

まとめ

7.

ンプ」を選択するのが大変であり、今回のサイトのように本文がページの最初に来て欲しいと言う。
6.4

考察

お弁当を注文するタスクを行っている視覚障害者と対面朗読者の対話を分析した知見を、XHTML 版のお弁当
注文システムに実装することができた。
今回実装した XHTML 版のお弁当注文システムは、より主体的に操作し、情報を得ることができるため、達成
感につながりやすい。これは、「シュナイダーマンの対話設計における 8 つの黄金律[5]」の「達成感を与える対話の実現」にあたる。実験で被験者は全ての商品の名前を聞いており、さらに 16 品については詳細を聞いている。
被験者は「できることはやった」とインタビューで答えており、ユーザに達成感を与えるサイト構造ができている。

本研究ではまず、視覚障害者と対面朗読者の対面朗読実験を行い、意図タグを付与するなどして、対面朗読者と視覚障害者の対話の構造を分析した。その結果、対話の流れや、常に使用可能なコマンドの種類などについて知見を得た。そして、その知見を反映したシステムを用いて被験者実験を行った結果、被験者は、対面朗読実験
より主体的に操作できる本システムの方に良い印象を持った。また、戦略をユーザが選択できるようにする、イ
メージしやすい情報を与える、というような知見が有効だということが分かった。
今回実装した XHTML 版のシステムは、まだ本当の音
声対話システムではない。今後、双方向のインタラクシ
ョンを用いるなどして、VoiceXML などの技術を用いた音声対話システムにつなげていきたい。
謝辞

XHTML 版の評価から、4.4 の音声対話システムにおける重要点について個別に考察する。
「1. 戦略をユーザが選択できるようにする。
」と「6. 次の 3 ステップを用いる」をサイトの構造に反映し実験したところ、良い評価を受けたので、有効ではないだろう

本研究は、科学研究費補助金特定研究「情報福祉の基礎」Kiki 班計画研究「視覚障害者の聴覚認知の解明と音声対話への利用」(課題番号 16091210)による。
本研究に関してさまざまな助言を下さった安村通晃教

か。しかし、ステップ 1 で選択肢 3 を選ぶと他の戦略と授(慶應義塾大学)、梅垣正宏氏(電気通信大学)、実験に協組み合わせられなかったり、商品名を読み上げてお気に力してくださった方々に感謝する。

入りリストに残さないと自動的に制約リストに入れられ、参考文献

他の戦略をとったときにも選べなくなってしまったりする。戦略を選択できるだけではなく、戦略をより自由に[1]て;東京女子大学卒業論文,(2005)

組み合わせられるようにすることが重要である。
「2. イメージしやすい情報を与える」について、

[2]
[3]

全国視覚障害者情報提供施設協会:初めての音訳,(1999)

すい情報が重要だとわかる。
「3. 絞り込みやすいカテゴリを用意する」について、

西本,小川,渡辺:対面朗読者と視覚障害者の対話の分析;信学技報 WIT2005-75, pp.7-12, (2006)

XHTML 版の評価実験でも、詳細を調べる前にほとんどを商品名で取捨選択をしていることから、イメージしや

小川:コンピュータと視覚障害者の音声対話に向け[4]

渡辺:視覚障害者の Windows パソコン及びインター

A さんの評価から、本システムに実装できている。 こ

ネット利用・学習状況;財団法人電気通信普及財の重要点は、サイトの構造を他のシステムに適用させる団,(2003)

際、さらに重要になるだろう。
「4. 品数を適宜表示し、次の行動を利用者が判断できるようにする」について、ページの先頭に現在のお気に入りなどの品数を表示するよう実装した。しかし、イン
タビューで A さんは、フォームの情報を送信する前にも、自分がチェックした商品の一覧を簡単に確認したいと話した。こうした機能も必要かもしれない。

[5]

Shneiderman, B.: Designing theUser Interface (3rd Ed.);
Addison-Wesley,(1998)

付録

模擬対話実験マニュアルの抜粋＜＜ステップ１：メインメニュー＞＞
メインメニューです。食べたいお弁当のカテゴリは，以下の 3 種類の方法で選ぶことができます。
１.

条件を指定して，候補に残すお弁当のカテゴリを絞り込む．

２.

キーワードを入力して，お弁当を絞り込む．

３.

73 種類全てのお弁当を読み上げて，その中からお気に入りを選ぶ．番号をどうぞ．

＜ユーザの選択肢が１の場合＞
メニュー全体の説明を聞きますか？「はい」「いいえ」でどうぞ。
＜はいの場合＞
お弁当は、特上弁当、上弁当、並弁当に分かれています。
特上弁当は、1200 円から 1600 円の高級感漂うお弁当で、全 19 種類あります。型に入れた白いご飯にゴマをふったものとおかずの組み合わせからできており、サラダが充実しています。特上弁当を候補に残しますか？「はい」「いいえ」でどうぞ。
次に、上弁当は、1200 円のお弁当で、華やかな化粧箱に入っています。5 種類あり、お肉もお魚も楽しみたい方におすすめのお弁当です。上弁当を候補に残しますか？「はい」「いいえ」でどうぞ。
最後に、並弁当は、600 円から 1200 円の一般的なリーズナブルなお弁当です。揚げ物弁当、どんぶり弁当、カレーなど種類が豊富で、約 50 種類あります。並弁当を候補に残しますか？「はい」「いいえ」でどうぞ。
＜いいえの場合→全てのお弁当が候補商品となる＞
該当商品は、＊品です。

＜7 品以下の場合は，ステップ２へジャンプ＞

続いて、値段や中身の系統を条件として，候補となるお弁当を絞り込むことができます。条件を追加しますか？
「はい」「いいえ」でどうぞ。
＜いいえの場合は☆へジャンプ＞＜はいの場合＞
値段は３種類にわかれています。複数を選んでもかまいません。
１.800 円未満

2.800 円以上 1000 円以下

該当商品は ＊品です。

3.1200 円以上

番号をどうぞ。

＜7 品以下の場合は，ステップ２へジャンプ＞

和洋中の系統は 3 種類に分かれています。複数を選んでもかまいません。
１. 和風

２. 洋風

３. 中華風

該当商品は ＊品です。

番号をどうぞ。
＜7 品以下の場合は，ステップ２へジャンプ＞

メインディッシュの系統は 3 種類にわかれています。複数を選んでもかまいません。
１. 肉メイン ２. 魚メイン ３. ごはんメイン
該当商品は ＊品です。

番号をどうぞ。

＜7 品以下の場合は，ステップ２へジャンプ＞＜☆へ ジャンプ＞＜ユーザの選択肢が２の場合＞
キーワードに合致するものを検索することも、合致しないものを検索することもできます。キーワードをどうぞ。
「（キーワード）」を含むものを検索するときは「1」、「（キーワード）」を含まないものを検索するときは「2」
番号をどうぞ。
該当商品は ＊品です。＜☆へ＞＜☆＞該当商品は、＊品です。

該当商品を，食べたい候補のお弁当として次に進むときは「１」→＜ステップ２へ＞
今までの選択をクリアしてやり直す時は「２」→＜ステップ１に戻る＞

番号をどうぞ。

＜ユーザの選択肢が 3 の場合＞値段の高い順から読む場合は「1」、値段の安い順から読む場合は「2」、番号をどうぞ。＜ステップ２へ＞＜＜ステップ 2：候補からお気に入りを選ぶ＞＞
順番に読み上げるので、それぞれについて、お気に入りに残すなら「残す」、候補から消すなら「消す」、詳細を知りた
いときは「くわしく！」と答えてください．
１「AAA」＜ユーザが「残す」または「消す」と発話したら次へ＞＜ユーザが答えない場合＞「AAA を残しますか？消しますか？詳しく述べますか？」
２「BBB」＜ユーザが「詳しく」と発話したら＞「BBB＋値段＋中身

BBB を残しますか？消しますか？」３「･･･」
候補は以上です。お気に入りに残ったお弁当は全部で ＊品です。
＜お気に入りとなったお弁当の数が５品以上の場合は以下を発話＞「最終決定をしやすくするため、お気に入りのお弁当をさらに絞りこみませんか？「はい」「いいえ」でどうぞ。」＜はいの場合→ステップ２の情報を保存したまま，ステップ２の始めに戻る＞＜いいえの場合、5 品未満の場合は以下を発話＞
お気に入りの中から最終決定するときは「１」→＜ステップ３へ進む＞
お気に入りのお弁当を追加するときは「２」→＜ステップ 1 へ戻る＞
はじめからやり直すときは「３」→＜ステップ 1 からやり直す＞

番号をどうぞ。

＜＜ステップ３：お気に入りの中から最終決定＞＞
お気に入りのお弁当は＊品です。お気に入りのお弁当の中から購入するお弁当を選びましょう！お弁当の中身も合わ
せて，安い順に述べていきます。決定するものをあとで番号で答えてください。
1.（お弁当名）＋（値段）＋（中身）、2. （お弁当名）＋（値段）＋（中身）、3.・・・・・・
この中から購入するお弁当をひとつ選ぶことができますか？「はい」「いいえ」でどうぞ。
＜いいえの場合＞
初めからやり直すときは「１」→＜ステップ１へ＞
今の候補リストからお気に入りのお弁当を選びなおすときは「２」→＜ステップ２へ＞＜はいの場合＞
何番のお弁当にしますか？ 番号をどうぞ。「（お弁当名），（値段）」に決定しました。

番号をどうぞ。