\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}に示す．各ユーザ要求タイプについて，有効な属性を◯，無効な属性を×で示している．場所属性は，どのユーザ要求タイプでも有効な属性であり，特定の場所の名前を値としてとる．日属性は，ユーザ要求タイプが天気，気温，降水確率の問い合わせであるなら，今日か明日という値をとる．警報問い合わせでは，日属性は無効な属性である．警報種別属性は，大雨，洪水といった値をとり，天気問い合わせ，気温問い合わせ，降水確率問い合わせの各ユーザ要求タイプにとっては無効な属性である．情報種別属性は，ユーザ要求タイプに応じて，警報，天気，気温，降水確率という値をとる．警報という属性値は，ユーザ要求タイプが警報問い合わせであるときにのみ有効であり，他のユーザ要求タイプでは無効である．天気，気温，降水確率という属性値についても，同様である．たとえば，ユーザ要求確定フェーズにおいて，ユーザが神奈川県という場所を指定したとシステムが理解したという状況を想定すると，システム理解状態は次のようになる．$${\bfS_{1}}=\{<場所，神奈川県，未>\}$$ここで，システムがとりうる行動として，場所属性についての確認行動と，情報種別属性についての情報要求行動を考える．まず，場所属性についての確認行動をとるとすると，システムは「神奈川県ですか？」といった確認発話を行う．システムは，ユーザが肯定的な応答で承認したとシステムが認識するまで，場所属性の値の確認を続ける．${\bfS_{1}}$におけるシステム確認発話「神奈川県ですか？」に対して，ユーザが肯定発話で応じたとき，システム理解状態は次のようになる．$${\bfS_{2}}=\{<場所，神奈川県，済>\}$$あるいは，${\bfS_{1}}$において，情報種別属性についての情報要求行動をとるとすると，システムは「お尋ねの情報種別は何ですか?」，「天気についてお尋ねですか?」といった情報要求発話を行う．ユーザは情報種別属性の値を伝達する．その後，システムは確認発話によって情報種別属性の値を確定していく．ユーザが知りたい情報種別が警報であったとすると，情報要求行動が完了したときのシステム理解状態は次のようになる．$${\bfS_{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}節で示した${\bfS_{1}}$によって表される．${\bfS_{1}}$から導き出されるユーザ要求タイプは曖昧であり，警報問い合わせ，天気問い合わせ，気温問い合わせ，降水確率問い合わせの4つの要求タイプが導き出される．また，システム知識の内容は，どの場所にも警報は発表されていないという内容であるとする．\subsection{対話プランの生成}\label{sec-plan}システムの対話プランとは，確認行動と情報要求行動の任意回の繰り返しと，それに続く一つの情報伝達行動から成る．{\bf(Step1)}では，現在のシステム理解状態から可能なユーザ要求タイプを導出した後，ユーザ要求タイプの各々について，可能な対話プランを網羅的に生成する．そのために，まず，各ユーザ要求タイプについて有効な属性を選びだし，有効な属性の中で既に値が確定したものを除いた残りの属性に注目する．それらの属性すべての値を確定するための対話プランとして，次の条件を満たす確認行動，情報要求行動，情報伝達行動から成るプランを網羅的に生成する．ただし，一つのプランの中で，一つの属性が異なる確認行動や情報要求行動の対象になることはないものとする．\begin{itemize}\item[(a)]システム理解状態で値が与えられている属性の部分集合${\bfA}$について，${\bfA}$に含まれるすべての属性の値を確定するための確認行動．\item[(b)]システム理解状態で値が与えられていない1つの属性について，その属性の値を確定するための情報要求行動．\item[(c)]プランに含まれるすべての確認行動と情報要求行動によってユーザ要求内容が確定したと仮定したときに，確定した要求内容に応じてユーザに対し情報を伝達するための情報伝達行動．\end{itemize}本稿では，属性を確認する順序によって確認コストは変わらないと仮定する．したがって，プランの中の確認行動と情報伝達行動の順序を入れ換えても確認コストは変わらない．情報伝達行動の生成は，ユーザ要求内容が確定したと仮定した上で，データベースを検索し，ユーザ要求内容に対するシステム応答内容を仮想的に生成することによって行う．例として，システム理解状態${\bfS_{1}}$の下での対話プランについて考える．まず，ユーザ要求タイプが警報問い合わせの場合を想定する．可能な対話プランは多数あるが，簡単のため，情報種別を確認してから応答を行うプラン$Plan_{1}$と，場所と情報種別を確認してから応答を行うプラン$Plan_{2}$に注目する．2つのプランは次のように表記される．$A_{1}\RightarrowA_{2}$は，行動$A_{1}$に続いて行動$A_{2}$を実行することを意味する．\begin{description}\item[$Plan_{1}$]:=$(Act_{1}\RightarrowRes_{1})$\item[$Plan_{2}$]:=$(Act_{2}\RightarrowAct_{1}\RightarrowRes_{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}\RightarrowAct_{1}\RightarrowAct_{3}\RightarrowRes_{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}デュアルコスト法は，各ユーザ要求タイプの適切度を正規化したものをユーザ要求タイプの確率分布として用いている．例として取り上げているシステム理解状態${\bfS_{1}}$では，各ユーザ要求タイプの確率は等確率で$0.25$となる．したがって，$Act_{1}$の期待損失は$0$，$Act_{2}$の期待損失は$2.5\times0.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}$の導出過程を説明する．確認対話を通して値を確定すべき属性の集合${\bfA}$が与えられている．属性集合${\bfA}$の認識率を$p$($0<p<1$)とする．\ref{sec-cost}節で定義した通り，属性集合${\bfA}$の認識率とは，${\bfA}$に含まれるすべての属性の値を一度に正しく認識できる確率である．また，ユーザの承認発話は常に正しく認識されるものと仮定する．確認対話は，システムの確認発話とそれに続くユーザの承認発話あるいは訂正発話から成るターンが繰り返されることによって進行する．各ターンにおいて，システムとユーザは次のように行動すると仮定する．\begin{description}\item[\bf(システムの確認発話)]システムは，システム理解状態にしたがって，${\bfA}$に含まれるすべての属性の値を提示する．\item[\bf(ユーザの承認発話あるいは訂正発話)]システムが提示した属性値がすべて正しいなら，ユーザは承認発話を行う．さもなければ，ユーザは${\bfA}$に含まれるすべての属性の正しい値を提示することにより，訂正発話を行う．\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}