



\documentstyle[epsf,jnlpbbl]{jnlp_j}

\setcounter{page}{43}
\setcounter{巻数}{9}
\setcounter{号数}{1}
\setcounter{年}{2002}
\setcounter{月}{1}
\受付{2001}{6}{29}
\再受付{2001}{9}{14}
\採録{2001}{9}{28}

\setcounter{secnumdepth}{2}

\title{システム知識制限下での効率的音声対話制御法}
\author{堂坂 浩二\affiref{NTT} \and 安田 宜仁\affiref{NTT}
 \and 相川 清明\affiref{NTT}}

\headauthor{堂坂 浩二, 安田 宜仁, 相川 清明}
\headtitle{システム知識制限下での効率的音声対話制御法}

\affilabel{NTT}{日本電信電話株式会社, NTTコミュニケーション科学基礎研究
所}{NTT Communication Science Laboratories, NTT Corporation}

\jabstract{
本稿では，音声対話システムがシステム知識として保有するデータベースの内容
に依存して，できるだけ短い対話でユーザの必要とする情報を伝達するためのデュ
アルコスト法と呼ぶ対話制御法を提案する．音声対話システムは，音声認識誤り
のために，ユーザ要求内容を確定することを目的とした「確認対話」を実施する
必要がある．長い確認対話は対話の円滑な流れを阻害するので，確認対話は簡潔
であることが望ましい．ユーザは対話時点でのシステム知識の内容を知らないの
で，システムが詳しい情報を保有していない事柄に関して詳細な情報を要求する
場合が頻繁に起きる．そのような場合にも，従来法ではユーザ発話内容を逐一確
認するので，無駄な確認が増えてしまうという問題があった．この問題を解決す
るために，確認コストと情報伝達コストと呼ぶ2 種類のコストを導入する．確認
コストは確認対話の長さであり，音声認識率に依存する．情報伝達コストは，確
認対話でユーザ要求を確定した後，ユーザに情報を伝達する際のシステム応答の
長さであり，システム知識の内容に依存する．デュアルコスト法は，この2 つの
コストの和を最小化することにより対話を制御する方法であり，従来法が避ける
ことができない無駄な確認対話を回避しながら，短い対話でユーザ要求に応じた
情報を伝達することができる．

}

\jkeywords{音声対話，対話制御，対話管理}

\etitle{Efficient Spoken Dialogue Control \\ 
under System's Limited Knowledge} 
\eauthor{Kohji Dohsaka \affiref{NTT} \and Norihoto Yasuda \affiref{NTT}
\and Kiyoaki Aikawa \affiref{NTT}}

\eabstract{
We present a dialogue control method called the ``dual-cost method'',
by which a spoken dialogue system conveys information relevant to a
user request by a concise dialogue within the confines of the system's
knowledge stored in its database.  Due to speech recognition errors, a
system has to carry out a ``confirmation dialogue'' to clarify the user
request. A confirmation dialogue should be concise since a lengthy one
destroys the flow of the overall dialogue. There are cases where the
user request is beyond the system's knowledge since a user does not
know what knowledge the system has. In such cases, conventional
methods have a problem of invoking unnecessary confirmations since
they attempt to confirm the whole contents of the request. To resolve
this problem, we introduce the notions of confirmation cost and
information transfer cost. The confirmation cost is the length of a
confirmation dialogue and depends on the speech recognition rate.  The
information transfer cost is the length of a system response and
depends on the system's knowledge.  The dual-cost method controls a
dialogue based on the minimization of these two costs and can avoid
unnecessary exchanges, which are inevitable in conventional methods.

}

\ekeywords{Spoken Dilaogue, Dialogue Control, Dialogue Management}

\begin{document}
\maketitle



\section{はじめに}
\label{sec-intro}

音声対話システムとは，ユーザとの音声対話を通して，あらかじめ決められたタ
スクをユーザと協同で実行するシステムである．タスクとは，音声対話システム
ごとに定められた作業のことであり，たとえば，各種の予約，個人スケジュール
の管理といったタスクがある．近年の音声情報処理技術，自然言語処理技術の発
展に伴って，様々なタスクにおいて音声対話システムが実現されてきている~
\cite{TRIPS,DUG1,PEGASUS}．

音声対話インタフェースは，人にとって親しみやすく，手や目を占有しないとい
う利点をもつ．人とコンピュータが，円滑な音声対話を通して意思疎通できるよ
うになれば，音声対話は理想的な人−コンピュータのインタフェースとなること
が期待される．しかし，円滑な音声対話を実現するためには，音声認識誤りに対
処することが必要となる．システムは，ユーザ音声の認識結果からユーザ要求の
内容を理解し，ユーザ要求内容に応じて適切な情報をユーザに伝達しなければな
らないが，音声認識誤りの可能性があるため，ユーザ音声の認識結果のみに頼っ
てユーザ要求の内容を確定してしまうと，ユーザ要求通りに正しくタスクを遂行
できない場合が生じる．音声対話システムでは，この問題に対処するために，ユー
ザとの間で確認対話と呼ぶ対話を行い，確認対話を通してユーザ要求内容を確定
するという方法をとることが普通である．音声認識誤りのため確認対話は必須で
あるが，確認対話の最中にも音声認識誤りが起きる可能性があるので，確認対話
が長ければ長いほど，対話の円滑な流れが阻害される危険性が高まる．したがっ
て、不必要な確認対話はできる限り避けることが望ましい．

不必要な確認対話の一つの典型は，ユーザ要求内容がシステムの限られた知識の
範囲を越えている場合に，システムがユーザ要求内容のすべてを逐一確認する場
合に起きる．ここで，システム知識とは，システムが対話時点でデータベース内
に保持しているタスク遂行のために必要なデータの集合を意味する．また，ユー
ザ要求内容がシステムの限られた知識の範囲を越えている状況とは，システムが
ユーザ発話を理解できるのだけれども，システムが保有していない情報をユーザ
が要求している，あるいは，システムが詳しい情報を保有していない事柄に関し
て，ユーザが詳細な情報を要求しているという状況である．\footnote {本稿で
は，システムが認識できる語彙の集合が限られているために，システムがユーザ
発話を理解できない状況や，ユーザが期待するタスクとシステムが想定するタス
クが相違しているために、ユーザが期待するタスクをシステムが実行できない状
況は扱わない．}

音声対話システムとユーザの対話は，ユーザの要求内容を確定するために確認対
話を行い，その後で，確定した要求内容に応じて適切な情報をユーザに対し応答
するという順序で進行する．確認対話でユーザ要求内容をすべて確認したところ
で，確認対話に続くシステム応答の長さを考慮しなければ，対話全体を効率的に
実施することにはならない．システム応答の長さは，対話時点のシステム知識の
内容に依存するので，システムの限られた知識の範囲を考慮した上で，対話全体
を制御する必要がある．

例として，気象情報を案内する音声対話システムを考える．システムは，各場所
ごとに予報されている気象情報や，現在発表されている警報についてのデータを
システム知識として保有している．今，ユーザが神奈川県に大雨警報が発表され
ているかどうか尋ねているとシステムが理解した状況を想定する．また，どこに
も警報が発表されていない，あるいは，警報が発表されている場所は少数である
という知識をシステムが保有しているとする．このとき，ユーザが関心のある場
所が神奈川県であることや，警報の種別が大雨であるといった項目は確認する必
要がない．なぜなら，システムは，ユーザ要求内容に含まれる場所や警報の種別
が何であるかということを識別するに足るほど詳しい情報を保有しておらず，場
所や警報の種別についての確認なしでも，システム応答の長さはほとんど同じで
あり，対話全体の長さが増大することもないからである．また，システムが認識
している神奈川県，大雨といった項目は認識誤りかもしれず，それらの項目を確
認すると，ユーザの訂正発話を招き，対話が不必要に長くなる危険性が高い．

音声対話システムとユーザの間で効率的な対話を実現するための対話制御法につ
いて盛んに研究が進められている
\cite{Chu:00,LPE:98,Niimi:96,LKSM:00,RPT:00}．これらの従来法は，音声認識
結果の信頼度，音声認識率，システム理解状態といった情報を利用して，確認対
話の長さを削減することに注目している．しかし，確認対話に続くシステム応答
の長さを含めて対話全体を効率的に実施することは行っておらず，ユーザ要求内
容がシステムの限られた知識の範囲を越えている場合に，著しく無駄な対話を行っ
てしまうという問題点がある．

従来法の中には，強化学習を利用して最適な対話戦略を学習するという方法があ
る~ \cite{LPE:98,LKSM:00,RPT:00}．これらの従来方法では，対話戦略の効率性
を評価するための報酬関数あるいはコスト関数を定義し，システムとユーザの間
の多くの対話例を使って，報酬関数を最大化あるいはコスト関数を最小化するよ
うな対話戦略が学習される．しかし，これらの従来法はシステムが対話時点で保
有する知識の範囲が対話の効率性に対して及ぼす影響を報酬関数やコスト関数に
組み入れてはいない．したがって，強化学習に基づく従来法によって学習される
対話戦略を使っても，本稿で問題としているような無駄な対話を避けることはで
きない．

ユーザ発話内容が曖昧なときに，ユーザ発話内容の曖昧さを解消してもシステム
応答が同一で変化しないなら，ユーザ発話内容の曖昧さを解消せずに応答を生成
するという方法が提案されている~\cite{Ardissono:96,RasZuk:94,vBkCoh:91}．
これらの従来法は，システム応答の同一性が保証されていない場合には適用でき
ないという問題がある．また，音声認識誤りにより発生する余分な対話について
は考慮されていない．

そこで，本稿では，ユーザ要求内容がシステムの限られた知識の範囲を越えてい
る場合であっても，無駄な確認を避けて効率的な対話を実施することを目的とし
た方法として，デュアルコスト法とよぶ対話制御法を提案する．デュアルコスト
法では，確認対話の長さを表す確認コストと，確認対話後のシステム応答の長さ
を表す情報伝達コストという2つのコストを導入し，確認コストと情報伝達コス
トの和を最小化するように対話を制御する．音声認識が誤っていると，余分な確
認を行わないといけないことを反映して，確認コストは音声認識率に依存する．
情報伝達コストはシステムが対話時点で保有する知識の内容に依存する．確認コ
ストと情報伝達コストという2種類のコストを導入するのは，対話全体を効率的
に実施するためには，確認対話の長さだけでなく，システム応答の長さを考慮す
る必要があるためである．すなわち，確認対話に手間をかければかけるほど対話
全体を効率的に実施できるというわけではなく，ユーザ要求内容確定のための手
間は，システム応答の長さとのバランスによって決める必要があるということで
ある．この2つのコストの和を最小化することにより，システム知識の内容に応
じて，無駄な確認を避け，対話全体を効率的に実施することが可能となる．この
提案方法は，システム応答の同一性が保証されない場合であっても，情報伝達コ
ストの増大が確認コストの減少に見合う範囲内であれば，ユーザ発話理解結果の
一部を確認しないという方法であり，従来方法~
\cite{Ardissono:96,RasZuk:94,vBkCoh:91}を一般化したものとなっている．ま
た，デュアルコスト法とユーザ要求内容のすべてを逐一確認する従来方法を対話
の効率性の観点から比較したシミュレーション対話実験の結果を示し，デュアル
コスト法が従来法よりも効率的に対話を実施できることを論じる．


\section{音声対話システムの対話制御}
\label{sec-system}

\begin{figure}[t]
\begin{center}
\atari(130,42.7)
\end{center}
\caption{音声対話システムの構成}
\label{fig-system} 
\end{figure}

ここで想定している音声対話システムの構成を図~\ref{fig-system}に示す．シ
ステムは，音声理解，発話生成，対話制御を行う各モジュールとデータベースか
ら構成される．データベースの内容は一定ではなく，日々内容が更新されるよう
なタスクを想定する．音声理解モジュールはユーザ音声からユーザ発話内容を理
解し，理解した結果はシステム理解状態として保持される．対話制御モジュール
は，以下に述べるように，システム理解状態と現在のデータベースの内容に基づ
いて，システム行動を決定する．発話生成モジュールは，対話制御モジュールの
決定にしたがって，システム応答の言語表現を生成し，音声として出力する．

音声対話システムとユーザの対話は，ユーザ要求確定フェーズとシステム情報伝
達フェーズという2つの対話フェーズの間を移行しながら進行する．ユーザ要求
確定フェーズにおいて，ユーザはシステムに対する要求を音声によって伝える．
システムとユーザは確認対話を通してユーザ要求内容を確定する．ユーザ要求内
容を確定した後，対話はシステム情報伝達フェーズに移行し，確定したユーザ要
求にしたがって情報を伝達するためのシステム応答が生成される．

システム理解状態は，3つ組 $<$属性，値，確定フラグ$>$ の集合として保持さ
れる．ユーザ要求タイプの種類と属性の全体集合はタスクごとに決まっている．
各ユーザ要求タイプについて，ユーザ要求の内容として含むことができる属性と，
各属性がとりうる値の範囲が決まっている．各ユーザ要求タイプについて，ユー
ザ要求内容として含むことができる属性を有効な属性，値としてとりうる属性値
を有効な属性値とよぶ．有効でない属性，属性値を無効な属性，属性値とよぶ．
確定フラグは，属性の値が確認対話により確定するまで「未」という値をとり，
確認対話により確定されると「済」という値をとる．

ユーザ要求確定フェーズでは，システム理解状態にしたがって，確認行動，情報
要求行動のいずれかのシステム行動を行う．確認行動とは，システム理解状態に
おいて値が与えられている属性について，ユーザに対して属性値を確認する発話
（確認発話）を行い，「はい」といったユーザの肯定的な発話(承認発話)によっ
て属性値が確定されるまで，その属性の値の確認を繰り返すという行動である．
ユーザは，承認発話以外に，システムの確認内容を訂正する発話(訂正発話)を行
うことができる．情報要求行動とは，システム理解状態において値が与えられて
いない属性について，ユーザに対して属性の値を要求する発話（情報要求発話）
を行い，その後，その属性についての確認行動を実施するという行動である．す
なわち，情報要求行動とは一つの情報要求発話に続く確認発話の繰り返しである．

ユーザ要求確定フェーズにおいて，ユーザ要求タイプが一意に決定されており，
その時点で確定しているユーザ要求内容にしたがってシステム応答を生成するこ
とが適切であると判断されると，システム情報伝達フェーズに移行する．システ
ム情報伝達フェーズにおいて，確定済みのユーザ要求内容に応じて情報をユーザ
に伝達するためにシステム応答を生成するという行動を情報伝達行動と呼ぶ．

対話制御とは，対話の各時点において，対話を効率的に実施するという観点から
最適なシステム行動を決定することである．システム行動としては，確認行動，
情報要求行動，情報伝達行動がある．情報伝達行動を選択するということは，ユー
ザ要求確定フェーズからシステム情報伝達フェーズへの移行を決定することと同
等である．

\begin{table}
\begin{center}
\begin{tabular}{|l||c|c|c|c|}
\hline
& \multicolumn{4}{|c|}{\bf 属性} \\ \cline{2-5} 
\multicolumn{1}{|l||}{\bf ユーザ要求タイプ}
 & \multicolumn{1}{c|}{場所}
 & \multicolumn{1}{c|}{日}
 & \multicolumn{1}{c|}{警報種別}
 & \multicolumn{1}{c|}{情報種別} \\ \hline
天気問い合わせ      & ◯ & ◯ & × & \multicolumn{1}{l|}{◯ (値は天気のみ)} \\ \hline
気温問い合わせ      & ◯ & ◯ & × & \multicolumn{1}{l|}{◯ (値は気温のみ)} \\ \hline
降水確率問い合わせ  & ◯ & ◯ & × & \multicolumn{1}{l|}{◯ (値は降水確率のみ)} \\ \hline
警報問い合わせ      & ◯ & × & ◯ & \multicolumn{1}{l|}{◯ (値は警報のみ)} \\ \hline
\end{tabular}
\end{center}
\caption{天気情報案内タスクにおけるユーザ要求タイプと属性の関係}
\label{tab-task}
\end{table}

本稿では気象情報案内を行う音声対話システムを想定する．ユーザ要求タイプと
して，警報問い合わせ，天気問い合わせ，気温問い合わせ，降水確率問い合わせ
の4種類のユーザ要求タイプを考える．属性の全体集合は，場所，日，警報種別，
情報種別の4つの属性から成る集合である．ユーザ要求タイプと属性との間の関
係を表~\ref{tab-task}に示す．各ユーザ要求タイプについて，有効な属性を◯，
無効な属性を×で示している．場所属性は，どのユーザ要求タイプでも有効な属
性であり，特定の場所の名前を値としてとる．日属性は，ユーザ要求タイプが天
気，気温，降水確率の問い合わせであるなら，今日か明日という値をとる．警報
問い合わせでは，日属性は無効な属性である．警報種別属性は，大雨，洪水といっ
た値をとり，天気問い合わせ，気温問い合わせ，降水確率問い合わせの各ユーザ
要求タイプにとっては無効な属性である．情報種別属性は，ユーザ要求タイプに
応じて，警報，天気，気温，降水確率という値をとる．警報という属性値は，ユー
ザ要求タイプが警報問い合わせであるときにのみ有効であり，他のユーザ要求タ
イプでは無効である．天気，気温，降水確率という属性値についても，同様であ
る．

たとえば，ユーザ要求確定フェーズにおいて，ユーザが神奈川県という場所を指
定したとシステムが理解したという状況を想定すると，システム理解状態は次の
ようになる．

$${\bf S_{1}} = \{<場所，神奈川県，未>\}$$

ここで，システムがとりうる行動として，場所属性についての確認行動と，情報
種別属性についての情報要求行動を考える．まず，場所属性についての確認行動
をとるとすると，システムは「神奈川県ですか？」といった確認発話を行う．シ
ステムは，ユーザが肯定的な応答で承認したとシステムが認識するまで，場所属
性の値の確認を続ける．${\bf S_{1}}$におけるシステム確認発話「神奈川県で
すか？」に対して，ユーザが肯定発話で応じたとき，システム理解状態は次のよ
うになる．

$${\bf S_{2}} = \{<場所，神奈川県，済>\}$$ 

あるいは，${\bf S_{1}}$において，情報種別属性についての情報要求行動をと
るとすると，システムは「お尋ねの情報種別は何ですか?」，「天気についてお
尋ねですか?」といった情報要求発話を行う．ユーザは情報種別属性の値を伝達
する．その後，システムは確認発話によって情報種別属性の値を確定していく．
ユーザが知りたい情報種別が警報であったとすると，情報要求行動が完了したと
きのシステム理解状態は次のようになる．

$${\bf S_{3}} = \{<場所，神奈川県，未>，<情報種別，警報，済> \}$$ 


\section{デュアルコスト法}
\label{sec-dualcost}

\subsection{対話コスト}
\label{sec-cost-intro}

デュアルコスト法は，対話の効率を確認コストと情報伝達コストの和として計量
し，2つのコストの和を最小化することにより，対話を制御する方法である．確
認コストと情報伝達コストの和を対話コストと呼ぶ．確認コストはユーザ要求確
定フェーズにおける確認対話の長さの期待値と定義し，情報伝達コストはシステ
ム情報伝達フェーズにおけるシステム応答の長さの期待値と定義する．

確認コスト，情報伝達コストという2種類のコストを導入するのは，できるだけ
短い対話で，ユーザが必要とする情報を伝達するためには，確認対話の長さだけ
でなく，それに続くシステム応答の長さも考慮する必要があるためである．たと
えば，ユーザ要求タイプが警報問い合わせであり，現在のデータベースの内容が，
多くの場所に警報が発表されているという内容である場合を想定する．この場合，
ユーザが関心のある場所について確認対話を行わないとすると，システム応答が
極端に長くなってしまう．ユーザが関心のある場所を確定することによって，対
話全体を短くすることができるので，場所についての確認は行う価値があると言
える．しかし，どこにも警報が発表されていない，あるいは，ごく少数の場所に
しか警報が発表されていないというデータベースの内容である場合には，場所の
確認を行わなくても，システム応答が極端に長くなることはなく，むしろ場所の
確認を行わないことで，対話全体を短く済ますことができる可能性がある．この
ように，システムのデータベースの内容に応じて，最も短い対話でユーザが要求
する情報を伝達するためには，確認コストという確認対話の長さの期待値と情報
伝達コストというシステム応答の長さの期待値の双方を考慮する必要がある．

\subsection{処理の流れ}
\label{sec-procedure}

デュアルコスト法の対話制御手順を説明する．

\begin{description}
\item[(Step1)] ユーザ要求確定フェーズにおいて，現時点のシステム理解状態
で確定済となっている属性値が無効となるようなユーザ要求タイプを排除するこ
とにより，現時点で可能なユーザ要求タイプを導き出す．可能なユーザ要求タイ
プごとに，可能な対話プランをすべて生成する．対話プランとは，
\ref{sec-plan}節で説明するように，ユーザ要求内容を確定するために確認行動
と情報要求行動を繰り返し，その後，確定されたユーザ要求内容にしたがって情
報伝達行動を実行するという一連の手順を記述したものである．
\item[(Step2)] ユーザ要求タイプごとに，各対話プランの確認コストと情報伝
達コストを計算し，対話コスト(確認コストと情報伝達コストの和)が最小となる
ような対話プランを選択する．そのプランを各ユーザ要求タイプの最適プランと
呼び，最適プランの対話コストを各ユーザ要求タイプの最適コストと呼ぶ．
\end{description}

ここで，ユーザ要求タイプが一意に決まっている場合には，その最適プランにし
たがって，システム行動を選択すればよい．問題となるのは，現在のシステム理
解状態からはユーザ要求タイプが曖昧で一意に決めることができない場合である．
この場合に対処するために，システム行動の損失という概念を導入する．一つの
ユーザ要求タイプを仮定するとき，システム行動の損失とは，その行動をとった
がゆえに，ユーザ要求タイプの最適コストと比較して余計に費すことになるコス
トであると定義する．その行動が最適プランに沿ったものであるならば，損失は
$0$であるが，さもなければ，損失は正値をとる．損失という概念を用いて，次
の手順に進む．

\begin{description}
\item[(Step3)] 
現時点で実行可能なシステム行動をすべて生成し，ユーザ要求タイプごとに各シ
ステム行動の損失を計算する．

\item[(Step4)] 
ユーザ要求タイプの確率分布に基づいて，各システム行動の損失の期待値を計算
する．損失の期待値を期待損失とよぶ．最小の期待損失をもつシステム行動を選
択する．

\item[(Step5)] 
選択されたシステム行動を実行し，ユーザからの応答を待って，システム理解状
態を更新する．

\item[(Step6)] 
ユーザ要求タイプが一意に決まっており，これ以上システム行動を実施しても対
話コストが下がらないなら，システム情報伝達フェーズに移行する．さもなけれ
ば，{\bf (Step1)}に戻る．
\end{description}

以下においては，例として，ユーザが場所属性を神奈川県と指定したとシステム
が認識したという状況を考える．この状況は，ユーザが「神奈川県」とだけ発話
したとシステムが認識した場合に相当する．システム理解状態は，
\ref{sec-system}節で示した${\bf S_{1}}$によって表される．${\bf S_{1}}$ 
から導き出されるユーザ要求タイプは曖昧であり，警報問い合わせ，天気問い合
わせ，気温問い合わせ，降水確率問い合わせの4つの要求タイプが導き出される．
また，システム知識の内容は，どの場所にも警報は発表されていないという内容
であるとする．

\subsection{対話プランの生成}
\label{sec-plan}

システムの対話プランとは，確認行動と情報要求行動の任意回の繰り返しと，そ
れに続く一つの情報伝達行動から成る． {\bf (Step1)}では，現在のシステム理
解状態から可能なユーザ要求タイプを導出した後，ユーザ要求タイプの各々につ
いて，可能な対話プランを網羅的に生成する．そのために，まず，各ユーザ要求
タイプについて有効な属性を選びだし，有効な属性の中で既に値が確定したもの
を除いた残りの属性に注目する．それらの属性すべての値を確定するための対話
プランとして，次の条件を満たす確認行動，情報要求行動，情報伝達行動から成
るプランを網羅的に生成する．ただし，一つのプランの中で，一つの属性が異な
る確認行動や情報要求行動の対象になることはないものとする．

\begin{itemize}
\item[(a)] システム理解状態で値が与えられている属性の部分集合${\bf A}$に
ついて，${\bf A}$に含まれるすべての属性の値を確定するための確認行動．
\item[(b)] システム理解状態で値が与えられていない1つの属性について，そ
の属性の値を確定するための情報要求行動．
\item[(c)] プランに含まれるすべての確認行動と情報要求行動によってユーザ
要求内容が確定したと仮定したときに，確定した要求内容に応じてユーザに対し
情報を伝達するための情報伝達行動．
\end{itemize}

本稿では，属性を確認する順序によって確認コストは変わらないと仮定する．し
たがって，プランの中の確認行動と情報伝達行動の順序を入れ換えても確認コス
トは変わらない．情報伝達行動の生成は，ユーザ要求内容が確定したと仮定した
上で，データベースを検索し，ユーザ要求内容に対するシステム応答内容を仮想
的に生成することによって行う．

例として，システム理解状態${\bf S_{1}}$の下での対話プランについて考える．
まず，ユーザ要求タイプが警報問い合わせの場合を想定する．可能な対話プラン
は多数あるが，簡単のため，情報種別を確認してから応答を行うプラン
$Plan_{1}$と，場所と情報種別を確認してから応答を行うプラン$Plan_{2}$に注
目する．2つのプランは次のように表記される．$A_{1} \Rightarrow A_{2}$は，
行動$A_{1}$に続いて行動$A_{2}$ を実行することを意味する．

\begin{description}
\item[$Plan_{1}$] := $(Act_{1} \Rightarrow Res_{1})$
\item[$Plan_{2}$] := $(Act_{2} \Rightarrow Act_{1} \Rightarrow Res_{2})$
\end{description}

\noindent ただし，
\begin{description}
\item[$Act_{1}$] := 情報種別属性についての情報要求行動
\item[$Act_{2}$] := 場所属性についての確認行動
\item[$Res_{1}$] := どこにも警報が発表されていないことを伝達するための情
報伝達行動．
\item[$Res_{2}$] := 確定された場所には警報が発表されていないことを伝達す
るための情報伝達行動．
\end{description}

ユーザ要求タイプが天気問い合わせ，気温問い合わせ，降水確率問い合わせの場
合に，次の対話プランを考える．

\begin{description}
\item[$Plan_{3}$] := $(Act_{2} \Rightarrow Act_{1} \Rightarrow Act_{3} \Rightarrow
Res_{3})$,
\end{description}

\noindent ただし，
\begin{description}
\item[$Act_{3}$] := 日属性についての情報要求行動．
\item[$Res_{3}$] := 確定された場所，日における天気(あるいは，気温，降水
確率)を伝達するための情報伝達行動．
\end{description}

\subsection{対話コストの計算}
\label{sec-cost}

確認コストを計算するために，まず，一つの確認行動あるいは情報要求行動が完
了するまでに要するターン数の期待値について考える．一つのターンは，システ
ムの確認発話(例：「神奈川県ですか?」)あるいは情報要求発話(例：「いつです
か?」)と，ユーザの訂正発話(例：「香川県です」)あるいは承認発話(例：「は
い」)から成るとする．

システムが各属性の値を正しく認識する確率を属性認識率とよぶ．属性認識率は
$0$よりも大きく，$1$よりも小さな値であり，前もって与えられていることを前
提とする．また，属性の集合が与えられるとき，その集合に含まれるすべての属
性の値を一度に正しく認識する確率を属性集合の認識率とび，各属性の属性認識
率の積として計算できるものとする．また，システムはユーザの承認発話を常に
正しく認識できるものと仮定する．

属性の集合が与えられるとき，その集合に含まれるすべての属性の値を確定する
ための確認行動について考える．システムとユーザの対話は，システムがすべて
の属性値を一度に提示することにより確認発話を行い，システムが提示した属性
の値が一つでも誤っているなら，ユーザはすべての属性値を提示することにより
訂正発話を行うというターンを繰り返していき，システムの提示する属性値がす
べて正しければ，ユーザは承認発話を行い，そこで確認行動が完了するという動
作系列であると仮定する．属性集合の認識率を$p$とするとき，確認行動が完了
するまでのターン数の期待値は，次の式で与えられる\cite{YDK:01}\footnote
{式の導出過程は付録で説明する．}．

\begin{equation}
\label{turnc-label}
TURN_{c} = \sum_{i=1}^{\infty}i(1-p)^{(i-1)}p = \frac{1}{p}
\end{equation}

情報要求行動は，属性の値が与えられていないときに，最初に情報要求発話を1 
回行い，その後は確認行動と同じ動作系列をとる．したがって，情報要求行動が
完了するまでのターン数の期待値は，次の式で与えられる．

\begin{equation}
TURN_{d} = 1+ TURN_{c} = 1+\frac{1}{p}
\end{equation}

次に，確認行動，情報要求行動の長さについて考える．各行動の長さは，行動を
遂行するために要する各ターンに含まれるシステム発話とユーザ発話の長さの和
である．ここでは，確認発話，情報要求発話，訂正発話においては，一つの属性
が一つの名詞句として実現されると仮定し，発話の長さを発話に含まれる名詞句
の延べ数と定義する．また，承認発話は，1個の肯定的な応答表現(例：「はい」) 
によって実現されると仮定し，その長さを1と定義する．

まず，確認行動の長さについて考える．確認すべき属性の数を$m$個とすると，
システム確認発話，ユーザの訂正発話においては，常にすべての属性値が言及さ
れると仮定しているので，最後の1回を除くターンには，長さ$m$のシステム確認
発話，長さ$m$のユーザ訂正発話が含まれ，最後1回のターンには，長さ$m$のシ
ステム確認発話，長さ$1$のユーザ承認発話が含まれることになる．したがって，
一つの確認行動の長さは，次の式で定義される．

\begin{equation}
LEN_{c} = 2m(TURN_{c}-1) + m + 1 = \frac{2m}{p} - m + 1
\end{equation}

次に，一つの情報要求行動の長さは，次の式で定義される．

\begin{equation}
LEN_{d} =2m(TURN_{d}-1) + m + 1 = \frac{2m}{p} + m + 1
\end{equation}

確認行動と情報要求行動の長さの定義に基づいて，対話プランの確認コストは，
対話プランに含まれるすべての確認行動と情報伝達行動の長さの和と定義する．

次に，情報伝達コストの算出について説明する．情報伝達コストは，情報伝達行
動を実施するために生成されるシステム応答の長さの期待値であるとする．シス
テム応答の長さは，応答に含まれる内容語の延べ数の期待値であると定義する．
たとえば，情報伝達行動が「警報はどこにも発表されていない」というシステム
応答として実行されるなら，内容語として，「警報」，「どこにも」，「発表さ
れていない」の3つの内容語を含むので，情報伝達コストは3となる．

対話プランによっては，確認行動や情報要求行動によって確定される属性の値が
複数通りあり，対話を実際に行ってみないことには値が決まらず，情報伝達行動
として生成されるシステム応答も一意に決まらないという場合がある．こういっ
た場合には，属性がとりうる値の生起確率は等確率であると仮定した上で，すべ
ての値の組合せを考慮したときのシステム応答の長さの期待値が情報伝達コスト
であると定義する．たとえば，プラン$Plan_{3}$では，場所属性，日属性の値は，
実際に対話を行ってみないと決まらない．$Plan_{3}$の情報伝達コストは，場所
属性，日属性のとりえる値のすべての組合せを考慮したときのシステム応答の長
さの期待値となる．


\subsection{最適な対話プランの決定}

{\bf (Step2)}では，\ref{sec-cost}節で説明したコスト計算方法にしたがって，
各対話プランの対話コストが計算される．

今取り上げている例において，ユーザ要求タイプが警報問い合わせである場合を
考える．各属性の認識率は0.8であるとする．$Plan_{1}$の確認コストは，
$Act_{1}$の長さと等しい．$LEN_{d}$によって，確認コストは，$2/0.8 + 1 + 1
= 4.5$となる．$Res_{1}$は，「どこにも警報は発表されていない」という応答
文で実行されると仮定する．情報伝達コストは3となる．したがって，
$Plan_{1}$ の対話コストは$7.5$となる．$Plan_{2}$の確認コストは，
$Act_{2}$と$Act_{1}$ の長さの和である．$Act_{1}$の長さは$2/0.8 + 1 + 1 =
4.5$，$Act_{2}$の長さは$2/0.8 - 1 + 1 = 2.5$であるので，確認コストは$7$ 
となる．確認行動によって確定する場所属性の値を$v$とするとき，$Res_{2}$は
「$v$には警報は発表されていません」という応答文で実行されると仮定する．
情報伝達コストは$3$となる．したがって，$Plan_{2}$の対話コストは$10$とな
る．結局，最適プランは$Plan_{1}$であり，最適コストは$7.5$である．

次に，ユーザ要求タイプが天気問い合わせである場合を考える．ここでは，簡単
のため，$Plan_{3}$が最適プランであると仮定する．これは，天気問い合わせの
場合は，場所や日が未定であると，すべての場所や日についての天気情報を伝達
しなければならず，情報伝達コストが極端に増大すると考えるのが自然であるか
らである．また，属性を確認する順序によって確認コストは変わらないと仮定し
ているので，$Plan_{3}$に含まれる確認行動，情報伝達行動の順序を入れ換えた
プランも最適プランとなる．最適プラン$Plan_{3}$の確認コストは，$2.5 + 4.5
+ 4.5 = 11.5$となる．応答文は「晴れです」といった文であると仮定する．情
報伝達コストは$1$となる．したがって，最適コストは$12.5$となる．同様に，
気温問い合わせ，降水確率問い合わせの場合も，最適プランは$Plan_{3}$と
$Plan_{3}$に含まれる確認行動と情報伝達行動の順序を入れ換えた対話プランで
あると考える．

なお，ここでは，簡単のため$Plan_{3}$が最適プランであると仮定しているが，
システムのデータベースに登録されている場所の数が少ない場合には，場所属性
についての確認を行わないで，すべての場所の天気情報をユーザに対し伝達する
という対話プランが最適プランになることもありえる．

\subsection{システム行動の選択}

{\bf (Step3)}では，各ユーザ要求タイプごとにシステム行動の損失が計算され
る．システム行動$Act$の損失を計算するためには，まず，システム行動$Act$ 
を含むような対話プランで，最小の対話コストをもつプランが探索される．その
プランをシステム行動$Act$のための準最適プランとよび，その対話コストを準
最適コストとよぶ．システム行動$Act$の損失は最適コストと準最適コストの差
であると定義する．

例として，$Act_{1}$と$Act_{2}$の2つの行動に注目する．警報問い合わせに関
して，$Act_{1}$の準最適プランは，最適プラン$Plan_{1}$に等しく，$Act_{1}$ 
の損失は0である．$Act_{2}$の準最適プランが$Plan_{2}$であるとすると，
$Act_{2}$の損失は$10 - 7.5 = 2.5$となる．

天気問い合わせ，気温問い合わせ，降水確率問い合わせに関しては，最適プラン
$Plan_{3}$の中に$Act_{1}$，$Act_{2}$が含まれているので，$Act_{1}$，
$Act_{2}$の損失はいずれも0となる．

次に，{\bf (Step4)}において期待損失が計算される．今取り上げている例では，
ユーザ要求タイプの確率分布によらず，$Act_{1}$の期待損失は0であり，
$Act_{2}$の期待損失は正値をとるので，$Act_{1}$が次のシステム行動として選
択される．すなわち，ユーザが「神奈川県」といった発話を行ったとシステムが
認識した場合には，対話全体を効率的に進めるという観点からは，「神奈川県で
すか?」と場所の確認をするのではなく，「どういった情報をお尋ねですか?」，
「天気についてお尋ねですか?」といった情報種別を要求する発話を行うことが
望ましい．

さらに複雑な例においては，期待損失を計算するためにユーザ要求タイプの確率
分布が必要となる．ここでは，ユーザ要求タイプのシステム理解状態に対する適
切度\cite{YDK:01}という概念に基づいて，ユーザ要求タイプの確率分布を近似
的に求める．

現在のシステム理解状態において，各属性 $attr_{i}\ (i=1,...,n)$ が値
$v_{i}$をとっており，各属性の属性認識率は$r_{i}$であるとする．このシステ
ム理解状態から導かれる可能なユーザ要求タイプが$REQ_{j}\ (j=1,...,m)$であ
るとする．このとき，ユーザ要求タイプ$REQ_{j}$として有効な属性の個数を
$N_{REQ_{j}}$，属性値$v_{i}$が有効となるようなユーザ要求タイプの個数を
$M_{v_{i}}$とするとき，ユーザ要求タイプ$REQ_{j}$の現在のシステム理解状態
に対する適切度$Relevance(REQ_{j})$を次のように定義する．

\begin{equation}
Relevance(REQ_{j}) = \frac{1}{N_{REQ_{j}}}\sum_{i=1}^{n}\frac{r_{i}}{M_{v_{i}}}
\end{equation}

デュアルコスト法は，各ユーザ要求タイプの適切度を正規化したものをユーザ要
求タイプの確率分布として用いている．例として取り上げているシステム理解状
態${\bf S_{1}}$では，各ユーザ要求タイプの確率は等確率で$0.25$となる．し
たがって，$Act_{1}$の期待損失は$0$，$Act_{2}$の期待損失は$2.5 \times
0.25 = 0.63$となる．


\section{評価}
\label{sec-experiment}

システムと模擬ユーザとの間のシミュレーション対話実験によって，デュアルコ
スト法の評価を行った．模擬ユーザとは，実ユーザの振舞をシミュレートしなが
らシステムと対話するエージェントである．各対話の初期時点において，模擬ユー
ザはシステムに対する要求内容を保持している．ユーザはシステムに要求内容を
伝え，ユーザとシステムは確認対話を通して要求内容を確定する．要求内容が確
定すると，システムは確定したユーザ要求内容に応じたデータをユーザに伝達す
る．システムと模擬ユーザは，音声で対話するのではなく，発話内容を属性と値
の対のリストとして表現した上で、属性と値の対のリストをやり取りすることに
よって対話を行う．ユーザの発話内容をシステムに送るときには，属性認識率に
応じて属性値に誤りが含まれるように，システムの音声認識誤りをシミュレート
した．

実験で用いたタスクは，\ref{sec-system}節で述べた気象情報案内タスクである．
場所は50個の都市，日は今日か明日の2通りである．警報種別としては，洪水，
大雨など10個の種別がある．システムは，データベースの中に，各都市の今日，
明日の天気，最高気温と最低気温，6時間ごとの降水確率のデータを保持してい
る．また，警報については，現在どこにも警報は発表されていないということを
データとして保持している．このデータベースの内容の場合，警報の問い合わせ
に関しては，情報種別だけを確認することが，最適な対話プランとなる．天気，
気温，降水確率の問い合わせに関しては，たいていの場合，場所，日，情報種別
の属性をすべてを確認することが最適な対話プランとなる．ただし，属性認識率
が低い状況においては，日属性の確認を行わずに，今日と明日の両日の気象情報
を伝達することが，最適なプランとなる場合もある．これは，属性認識率によっ
ては，日属性の確認をするための確認対話が，一日分の気象情報を伝達するため
の応答文よりも長くなる場合があるからである．

デュアルコスト法と比較するために，システム知識の範囲にかかわらずユーザ要
求の内容のすべてを逐一確認する2つの従来方法として，従来法1，従来法2と呼
ぶ対話制御方法を用いた．従来法1は，できるだけ多くの属性を一度に確定しよ
うとする方法であり，従来法2は，属性を一つずつ確定する方法である．従来法1 
は次のように動作する．なお，従来法1，従来法2とデュアルコスト法の違いは，
以下に述べる点のみである．

\begin{description}
\item[(C1-1)] システム理解状態から可能なユーザ要求タイプを導き出す．
\item[(C1-2)] システム理解状態において，既に値が与えられている属性がある
なら，そういった属性の値をできるだけ多く一度に確定するための確認行動を選
択し，{\bf (C1-4)} へ移行する．さもなければ，{\bf (C1-3)}へ移行する．
\item[(C1-3)] できだけ多くのユーザ要求タイプで有効となる属性を優先するよ
うに，値が与えられていない属性を一つ選択し，その属性のための情報要求行動
を選択する．
\item[(C1-4)] 選択されたシステム行動を実行し，ユーザからの応答を待って，
システム理解状態を更新する．
\item[(C1-5)] ユーザ要求タイプが一意に決まっており，その要求タイプの属性
値がすべて確定しているなら，システム情報伝達フェーズに移行する．さもなけ
れば，{\bf (C1-1)}に戻る．
\end{description}

従来法2は，従来法1の{\bf (C1-2)}を次の{\bf (C2-2)}に置き換えた方法である．

\begin{description}
\item[(C2-2)] システム理解状態において，値が既に与えられている属性がある
なら，それらの属性の一つを確定するための確認行動を選択し，{\bf (C1-4)}へ
移行する．さもなければ，{\bf (C1-3)}へ移行する．
\end{description}

模擬ユーザの振舞は以下の通りである．

\begin{description}
\item[(U1)] 対話の開始時点で要求内容の一部をシステムに伝える．
\item[(U2)] システムの確認発話に対して，訂正発話か承認発話を行う．訂正発
話は，システムの確認発話に含まれるすべての属性の値を伝達することによって
行う．
\item[(U3)] システムの情報要求発話に対して，属性の値を伝達するための発話
を行う．
\item[(U4)] システムがユーザ要求タイプにとって無効な属性の値を要求してき
たならば，システム発話を拒否する．
\end{description}

{\bf (U4)}は，ユーザ要求タイプが天気問い合わせであるにもかかわらず，シス
テムが警報種別属性の値を要求してくるような場合に相当する．そういった場合，
ユーザはシステムの情報要求に応えることができないことを伝えるための発話
(拒否発話)を行う．システムは，ユーザの拒否発話を受け取ると，現在の行動を
あきらめ，別のシステム行動を選択し，実行する．各方法において別のシステム
行動を選択する際の基準を説明する．デュアルコスト法では，損失ができるだけ
小さい行動を優先して選択する．従来法1 では，{\bf (C1-2)}で選んだ確認行動
が拒否されたなら，まだ確認を試みていない属性の組合せのうち，できるだけ多
くの属性の値を一度に確定する確認行動を優先して選択し，{\bf (C1-3)} で選
んだ情報要求行動が拒否されたなら，まだ情報要求を試みていない属性のうち，
できだけ多くのユーザ要求タイプで有効となる属性を優先して選び，その属性の
ための情報要求行動を選択する．従来法2では，{\bf (C2-2)}で選んだ確認行動
が拒否されたなら，値が与えられている別の属性を任意に選び，その属性につい
ての確認行動を選択する．{\bf (C1-3)} で選んだ情報要求行動が拒否された場
合は，従来法1と同様である．

シミュレーション対話実験では，4つのユーザ要求タイプごとに，ユーザの要求
内容をランダムに生成した．各属性の属性認識率を等しく0.5から1.0まで0.005 
刻みで変化させていった．各認識率において5000回のシミュレーション対話が実
施された．3つの対話制御法の性能を対話の効率性の観点から比較した．対話の
効率性は，タスクが完了するまでの対話の長さの平均によって評価した．対話の
長さは，\ref{sec-cost}節で述べた基準に加えて，模擬ユーザの振舞{\bf (U4)} 
におけるユーザ拒否発話は簡潔な否定的表現(例：「いいえ」，「分かりません」)
として実現されると仮定した上で，拒否発話の長さは1であるという基準にした
がって計算した．


\begin{figure}[t]
{
\begin{center}
\atari(76.2,53.3)
\end{center}
\caption{ユーザ要求タイプが警報問い合わせの場合における属性認識率に応
じた対話の長さの平均}
\label{p-a-1-graph} }
\end{figure}

\begin{figure}[t]
{
\begin{center}
\atari(76.2,53.3)
\end{center}
\caption{ユーザ要求タイプが気温問い合わせの場合における属性認識率に応
じた対話の長さの平均}
\label{p-a-3-graph} }
\end{figure}

シミュレーション対話実験の結果を示す．図~\ref{p-a-1-graph}は，ユーザ要求
タイプが警報問い合わせの場合における属性の認識率に応じた対話の長さの平均
の推移を示しており，図~\ref{p-a-3-graph}は，ユーザ要求タイプが気温問い合
わせの場合における属性の認識率に応じた対話の長さの平均の推移を示している．
警報問い合わせと気温問い合わせの2例を取り上げたのは，警報問い合わせの場
合は，場所属性の確認を回避できるという点で，デュアルコスト法の効果が最も
発揮されやすい場合であり，気温問い合わせの場合は，デュアルコストであって
も，場所属性，日属性，情報種別属性のすべてを確認しなければならない場合が
ほとんどであり，デュアルコスト法の効果を発揮することが困難な場合であるか
らである．両極端な場合を取り上げることにより，デュアルコスト法にとって有
利な状況では，デュアルコスト法が実際に効果を上げることができ，そうでない
状況であっても，従来法に比べて対話の効率を低下させないことを実証すること
を目的とする．

図\ref{p-a-1-graph}から分かるように，ユーザ要求タイプが警報問い合わせの
場合，デュアルコスト法は，従来法1，従来法2と比較して，より効率的に対話を
実施できた．警報問い合わせの場合には，警報がどこにも発表されていないとい
うデータベースの内容であるにもかかわらず，場所属性の確認をすると対話が著
しく無駄になる場合があるが，デュアルコスト法は，従来法1，従来法2が避ける
ことができない無駄な対話を回避することによって，対話を効率的に実施できた
ことが分かる．

この実験においては，システムは模擬ユーザ発話を正しく認識できるとは限らず，
模擬ユーザが警報の問い合わせを行ったとしても，システムは天気，気温，降水
確率の問い合わせであると誤認識する場合がある．また，ユーザは対話開始時点
において要求内容のすべてを伝えるとは限らない．そのような場合にはシステム
理解状態からはユーザ要求タイプを警報問い合わせであると一意に決定すること
はできないが，デュアルコスト法は，期待損失という概念を活用することによっ
て，対話全体の効率性を向上させるように対話を制御できたことが分かる．

図\ref{p-a-3-graph}から分かるように，ユーザ要求タイプが気温問い合わせの
場合には，デュアルコスト法による対話の効率性は，従来法2とほぼ同じである．
これは，気温問い合わせの場合には，デュアルコスト法であろうと，場所属性，
日属性，情報種別属性をすべて確認しなければならない場合がほとんどであるか
らである．データベースの内容によらずユーザ要求のすべてを逐一確認しなけれ
ばならないような場合であっても，デュアルコスト法が対話の効率を低下させる
ことはない．このことから，デュアルコスト法は圧倒的に効果を発揮しやすい場
合から，効果を発揮することが困難な場合まで，すべての場合で有効であること
が言える．

なお，図\ref{p-a-1-graph}，図\ref{p-a-3-graph}の双方において，属性認識率
が低い状況では，従来法1の効率が極端に低い．これは，認識率が低い状況では，
できるだけ多くの属性の値を一度に確定するという従来法1の戦略が，模擬ユー
ザからの多くの訂正発話を引き起こしてしまうため，不利に働くからある．認識
率が低い状況では，属性の値を1個ずつ確定するという従来法2の戦略の方が有利
に働く．また，図\ref{p-a-3-graph}において，従来法2が，属性認識率が1.0に
近づくと，デュアルコスト法より効率が低下していくのは，認識率が高い状況で
は，複数の属性の値をまとめて確定した方が有利であるにもかかわらず，従来法
2が属性の値を常に1個ずつ確定する戦略をとるからである．デュアルコスト法で
は，一度に値を確定する属性の可能な組合せごとに異なる対話プランを用意し，
認識率に応じて自動的に適切なプランを選択することができる．このことにより，
デュアルコスト法は，認識率が高い状況では，複数の属性の値を一度に確定する
対話プランを選択することになり，従来法2より有利であったと考えることがで
きる．


この実験においては，4つの属性から成るタスクを用いたが，属性の数はデュア
ルコスト法にとっては本質的なことではない．属性の数が多くなっても，ここで
用いた気象情報案内タスクのように，データベースの内容が日々更新され，対話
時点のデータベースの内容に依存して対話を制御しないことには，短い対話でユー
ザの必要とする情報を伝達することができないようなタスクであれば，デュアル
コスト法は効果を発揮する．


\section{おわりに}
\label{sec-concl}

本稿では，音声対話システムが対話時点でデータベース内に保有する知識の制限
下でユーザとの間で効率的な対話を実施するための対話制御法として，デュアル
コスト法を提案した．デュアルコスト法によって，システムが詳しい情報を保有
していない事柄に関して，ユーザが詳細な情報を要求する場合であっても，シス
テムは，現在のデータベースの内容に応じて，短い対話でユーザが必要とする情
報を伝達することができる．デュアルコスト法は，対話の各時点において，確認
コストと情報伝達コストという2つのコストの和を最小化するという原理に基づ
いて，システム行動を選択する．このことにより，デュアルコスト法は，対話全
体の長さを最小化するように対話を制御し，従来の方法では避けることができな
かった無駄な確認を回避しながら、短い対話でユーザの必要とする情報を伝達す
ることができる．また，システムと模擬ユーザの間のシミュレーション対話実験
によって，デュアルコスト法が，ユーザ要求内容のすべてを逐一確認する従来法
と比較して，より効率的に対話を実施できることを実証した．


\acknowledgment

日頃よりご指導いただくNTT先端技術総合研究所 東倉洋一所長，コミュニケーショ
ン科学基礎研究所 石井健一郎所長，メディア情報研究部 村瀬洋部長，ATRメディ
ア情報科学研究所 萩田紀博所長，熱心に討論してくださるNTTコミュニケーショ
ン科学基礎研究所 メディア情報研究部 マルチモーダル対話研究グループの諸氏
に感謝致します．



\bibliographystyle{jnlpbbl}
\bibliography{dohsaka-bib}


\section*{付録}

\subsection*{ターン数の期待値$TURN_{c}$の導出}

ここでは，\ref{sec-cost}節の式(\ref{turnc-label})で示した確認行動が完了
するまでのターン数の期待値$TURN_{c}$の導出過程を説明する．

確認対話を通して値を確定すべき属性の集合${\bf A}$が与えられている．属性
集合${\bf A}$の認識率を$p$($0<p<1$)とする．\ref{sec-cost}節で定義した通
り，属性集合${\bf A}$の認識率とは，${\bf A}$ に含まれるすべての属性の値
を一度に正しく認識できる確率である．また，ユーザの承認発話は常に正しく認
識されるものと仮定する．

確認対話は，システムの確認発話とそれに続くユーザの承認発話あるいは訂正発
話から成るターンが繰り返されることによって進行する．各ターンにおいて，シ
ステムとユーザは次のように行動すると仮定する．

\begin{description}
\item[\bf (システムの確認発話)]
システムは，システム理解状態にしたがって，${\bf A}$に含まれるすべての属
性の値を提示する．

\item[\bf (ユーザの承認発話あるいは訂正発話)]
システムが提示した属性値がすべて正しいなら，ユーザは承認発話を行う．さも
なければ，ユーザは${\bf A}$に含まれるすべての属性の正しい値を提示するこ
とにより，訂正発話を行う．
\end{description}




ユーザが承認発話を行う場合，システムは承認発話を常に正しく認識すると仮定
しているので，その時点で確認対話は終了する．ユーザが訂正発話を行う場合，
システム理解状態はユーザ訂正発話の認識結果にしたがって更新され，次のター
ンが始まる．

システムがユーザによって提示された属性値をすべて正しく認識する確率は$p$ 
であるので，確認対話が1ターンで終了する確率は$p$となる．次に，確認対話が
2ターンで終了する確率を考える．確認対話が2ターンで終了するということは，
1ターン目の冒頭では，システムがいずれかの属性の値を正しく認識できておら
ず，2ターン目の冒頭では，1ターン目のユーザ訂正発話にしたがって，システム
が属性の値をすべて正しく認識していることを意味する．したがって，確認対話
が2ターンで終了する確率は$(1-p)p$となる．同様に，3ターンで終了する確率は
$(1-p)^{2}p$，$i$ターンで終了する確率は$(1-p)^{(i-1)}p$となる．

結局，確認対話が終了までに要するターン数の期待値は，次の式で与えられる．

\begin{equation}
\label{e1}
TURN_{c} = \sum_{i=1}^{\infty}i(1-p)^{(i-1)}p
\end{equation}


次に，式(\ref{e1})の値が$\frac{1}{p}$となることを導出する．式(\ref{e1}) 
の右辺の$n$項までの和を$S(n)$とおく．

\begin{equation}
S(n) = \sum_{i=1}^{n}i(1-p)^{(i-1)}p
\end{equation}

$TURN_{c}$は，$S(n)$を使って，次のように書ける．

\begin{equation}
\label{e2}
TURN_{c} = \lim_{n \rightarrow \infty}S(n)
\end{equation}

ここで$S(n) - (1-p)S(n)$を計算する．


\begin{eqnarray}
\lefteqn{S(n) - (1-p)S(n)=} \nonumber \\
& p & + 2(1-p)p + \cdots + n(1-p)^{(n-1)}p \nonumber \\
&   & - 1(1-p)p - \cdots - (n-1)(1-p)^{(n-1)}p - n(1-p)^{n}p = \nonumber \\
\label{e3}
& p & + (1-p)p + \cdots + (1-p)^{(n-1)}p - n(1-p)^{n}p
\end{eqnarray}

式(\ref{e3})の最初のn項の和は，初項$p$，公比$1-p$の等比数列の$n$項までの
和であるから，次が導かれる．

\begin{equation}
S(n) - (1-p)S(n) = \frac{p((1-p)^{n} -1)}{(1-p)-1} - n(1-p)^{n}p
\end{equation}

辺々を変形すると，

\begin{equation}
pS(n) = -(1-p)^{n} + 1 - n(1-p)^{n}p
\end{equation}

$p$は$0$よりも大きな値を仮定しているので，辺々を$p$で割ると，

\begin{equation}
\label{e4}
S(n) = -\frac{(1-p)^{n}}{p} + \frac{1}{p} - n(1-p)^{n}
\end{equation}

$p$は$1$よりも小さな値であることを仮定しているので，式(\ref{e4})の右辺の
第1 項と第3項は，$n$を無限大に近づけると，$0$に収束する．したがって，式
(\ref{e2})，(\ref{e4})より，次を得る．

\begin{equation}
TURN_{c} = \lim_{n \rightarrow \infty}S(n) =  \frac{1}{p}
\end{equation}



\begin{biography}
\biotitle{略歴}
\bioauthor{堂坂 浩二}{
1984年大阪大学基礎工学部情報工学科卒業．
1986年同大学院博士前期課程了．
同年，日本電信電話(株)入社．
現在，NTTコミュニケーション科学基礎研究所勤務．
音声対話システム，言語生成，文脈理解の研究に従事．
情報処理学会平成9年度論文賞受賞．
言語処理学会，ACL，情報処理学会，電子情報通信学会，人工知能学会各会員．}
\bioauthor{安田 宜仁}{
1997年京都大学総合人間学部基礎科学科卒業．
1999年同大学院人間・環境学研究科修士課程了．
同年，日本電信電話(株)入社．
現在，NTTコミュニケーション科学基礎研究所勤務．
音声対話システムの研究に従事．
}
\bioauthor{相川 清明}{
1975年東京大学工学部電子工学科卒業．
1980年同大学院博士課程了．工学博士．
同年，日本電信電話公社武蔵野電気通信研究所入所．
現在，NTTコミュニケーション科学基礎研究所勤務．
連続音声認識，聴覚モデル，ニューラルネット，音声対話システムの研
究に従事．
1997年テレコムシステム技術賞，日本音響学会佐藤論文賞受賞．
IEEE，ASA，日本音響学会，電子情報通信学会，情報処理学会各会員．}

\bioreceived{受付}
\biorevised{再受付}
\bioaccepted{採録}

\end{biography}

\end{document}
