本発明は、音声操作と画面上の操作の両者を用いて操作可能なマルチモーダルアプリケーションプログラムを自動的に生成する技術に関するものである。

画面上でのアプリケーション操作が可能なＧＵＩ(Graphical User Interface)は、パーソナルコンピュータや、カーナビゲーションシステム、携帯電話などで広く用いられている。 このようなアプリケーションプログラムを開発するためのツールや参考書は多く出回っており、開発者の数も非常に多い。

一方で、音声操作と画面上の操作の両者を用いて操作可能なマルチモーダルアプリケーションプログラムは、まだ普及しているとは言えず、その開発ツールもまだ普及していない。

さらに、ＧＵＩアプリケーションでは、ボタンなどのＧＵＩコンポーネントを画面に配置して、それらのコンポーネントがユーザによって操作されたときのシステムの動作を記述するというイベントドリブン型のプログラム形式が用いられるが、音声対話の場合、対話フローに基づく逐次的な処理が必要となり、ＧＵＩアプリケーションの開発者にとって敷居の高いものになっている。

プログラミングの出来ないユーザでも、マルチモーダルアプリケーションを作成できるツールについては、特許文献１などが公開されている。

特開平９−２５１３６８号公報

しかし、特許文献１に公開されている方式についても、複数の入出力モダリティのタイミングについて、ユーザが直接タイミングチャートを作成したり、タイミングチャートの学習のための操作ログを作成したりなど、比較的工数がかかっていた。

本発明は、上記の問題を鑑みてなされたものであり、本発明では、GUIアプリケーションと、音声対話シナリオが連携してマルチモーダルアプリケーションを実現する仕組みを提供するとともに、質問項目数、質問項目名、質問項目ごとのガイダンス、質問項目ごとの回答例、誤認識時の訂正方式という情報を与えるだけで、マルチモーダルアプリケーションを実現するGUIアプリケーションのソースコードと、GUIアプリケーションと連動する対話シナリオと、対話シナリオで利用する音声認識文法の雛形を生成する。

上記の方式によって、音声対話アプリケーションやマルチモーダルアプリケーションの実装方法に詳しくないアプリケーション開発者でも、基本的なマルチモーダルアプリケーションの雛形を簡単に生成することができ、開発効率が向上する。

図１は、本発明によるマルチモーダルアプリケーションの構成の一実施例を表した図である。 マルチモーダルアプリケーションは、ＯＳ１００上で動作する音声認識エンジン１０１と、音声合成エンジン１０２と、１つもしくは複数の対話シナリオ１０５と、１つもしくは複数の音声認識文法１０６と、対話シナリオ１０５に記述された内容に従って、音声認識エンジン１０１と音声合成エンジン１０２を利用してユーザとの対話を制御する対話制御部１０３と、ＧＵＩアプリケーション１０４から構成される。

ＯＳ１００には、ＧＵＩや音声入出力をサポートする任意の既存のＯＳを利用することができる。 音声認識エンジン１０１や音声合成エンジン１０２には、任意の既存のエンジンを利用することができる。 対話制御部１０３には、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｈｉｕｍ（以後Ｗ３Ｃと略す）が勧告するＶｏｉｃｅＸＭＬ２．０の仕様に基づいて実装されたＶｏｉｃｅＸＭＬインタプリタを用いることができるが、他の形式の対話シナリオに基づいて対話制御を行うプログラムを利用することもできる。 対話シナリオ１０５は、ＶｏｉｃｅＸＭＬ２．０の仕様に基づいて記述することができるが、他の形式に基づいて記述してもよい。 音声認識文法１０６は、Ｗ３Ｃ勧告であるＳｐｅｅｃｈ Ｒｅｃｏｇｎｉｔｉｏｎ Ｇｒａｍｍａｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（以後ＳＲＧＳと略す）の仕様に基づいて記述することができるが、他の形式に基づいて記述してもよい。
ＧＵＩアプリケーション１０４は、ボタンやドロップダウンリスト、ラジオボックスなどのＧＵＩコンポーネントをポインティングデバイスなどで選択し、操作を行うことで、ユーザがアプリケーションの動作を制御することが可能な形式のアプリケーションであり、ＣやＣ＋＋，Ｊａｖａ（登録商標）などの言語で記述することができる。
別々のスレッドもしくはプロセスで動作するＧＵＩアプリケーション１０４と対話制御部１０３が連携して、ユーザがＧＵＩでも音声対話でもアプリケーションを制御できるようにするためには、ＧＵＩアプリケーション１０４から対話制御部１０３の動作を制御する仕組みを設けるか、逆に対話制御部１０３からＧＵＩアプリケーション１０４の動作を制御する仕組みを設ける必要がある。 一般的に1回のＧＵＩ操作でユーザがシステムに対して行える指示よりも、１回の発話でユーザがシステムに対して行える指示の方が、複雑度が高い。 すなわち、ＧＵＩ操作であれば、「ファイル」→「印刷」→「プリンタ選択」→「ＯＫ」のように４ステップの操作が必要な場合においても、音声発話であれば「ＸＸＸのプリンタに印刷」のように１発話で指示が行える。 これは、音声対話の方がより複雑な制御を必要とすることを意味しているため、対話制御部１０３が、制御の単純なＧＵＩアプリケーション１０４の動作を制御する、後者の仕組みが適切である。

そこで一実施例として、対話制御部１０３がＧＵＩアプリケーション１０４の動作を制御する仕組みについて説明する。
対話制御部１０３は、与えられた対話シナリオ１０５の記述内容に基づいて、対話の制御を行う。 図２は、ＶｏｉｃｅＸＭＬ形式で記述された対話シナリオ１０５の例である。 この対話シナリオに基づき、対話制御部１０３は、音声合成エンジン１０２を用いて、ユーザに音声で「新幹線予約システムへようこそ」「出発する駅名を発声して下さい」というガイダンスを出力する。 次に対話制御部１０３は、「departure.abnf」というファイル名で指定された音声認識文法１０６の記述内容に基づき、音声認識エンジン１０１を用いてユーザの発声を音声認識する。 音声認識結果１０７が音声認識エンジン１０１から通知されると、ユーザが適切な駅名の発声をした場合は、目的地を質問する次の対話に進み、ユーザが発声をしなかった場合<noinput>は、「東京駅のように発声して下さい」というガイダンスを出力し、再び音声認識を行う。 このように、対話制御部１０３は、ＧＵＩアプリケーション１０４とは独立して対話の制御を行うことができる。

一般的なＧＵＩアプリケーションでは、画面上に配置されたメニューやボタンなどのＧＵＩコンポーネントをポインティングデバイスで選択操作すると、そのＧＵＩコンポーネントに対応付けられた処理が実行される仕組みになっている。 しかし、本発明におけるＧＵＩアプリケーション１０４では、ＧＵＩコンポーネントが選択操作された場合に、対話制御部１０３に対して、そのＧＵＩ操作と同等の意味を持つ音声コマンドをユーザが発声した場合の音声認識結果と同等の擬似音声認識結果情報１０８を送信する。 これによって、音声コマンドを発した場合でも、ＧＵＩ操作を行った場合でも、対話制御部１０３は同じように音声対話を制御することができる。

一方、ＧＵＩ操作を行った場合や、音声コマンドを発声した場合に、ＧＵＩアプリケーション１０４にもその操作の結果が反映される必要がある。 このために、対話制御部１０３は、対話の進行状況に関する情報をＧＵＩアプリケーション１０４に対して提供する機能を持つ必要がある。 この情報提供の仕組みとして、イベントシステムを用いることができる。 対話制御部１０３にイベントリスナー登録を行うＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を用意し、対話制御部１０３の動作中に発生する、対話の進行状況に関するイベント１０９をＧＵＩアプリケーション１０４に通知すればよい。

対話の進行状況に関するイベントとしては、対話シナリオ１０５をＶｏｉｃｅＸＭＬで記述した場合、対話の開始を表すイベント、フォームの実行開始を表すイベント、フォーム内の特定の項目の実行開始を表すイベント、フォーム内で定義されているフィールドにユーザ入力により値が代入されたことを表すイベント、対話シナリオ内で定義されている変数の値が変更されたことを表すイベント、対話の終了を表すイベントなどが考えられる。 これらのイベントをＧＵＩアプリケーションが受け取り、その内容に基づいて画面表示を変更するなどの処理を行えばよい。 例えば図３は、図２の対話シナリオと連携してマルチモーダルアプリケーションを実現するＧＵＩアプリケーション１０４の画面の例であり、「出発駅」の選択に対応したリストボックス３０１の値を、フィールドdepartureにユーザ入力により値が代入されたことを表すイベントが通知されたときに、変更すればよい。 ユーザが1回の発声で複数の項目に対して回答するような発声を行った場合は、フォーム内で定義されているフィールドにユーザ入力により値が代入されたことを表すイベントを複数回連続して発行することで、ＧＵＩアプリケーションを複数回操作した場合と同等の効果を得ることができる。

図２で例示した対話シナリオでは、質問項目を順次ユーザに尋ねる方式の対話を行っている。 図３のＧＵＩアプリケーション１０４では、３つの入力項目がすべて表示されているが、対話の制御を対話制御部１０３で行うことを考えると、対話制御部１０３が受け付けることのできない入力は、ＧＵＩアプリケーション１０４においても受け付けるべきではないので、出発駅の入力を要求している状況では、図３のようにリストボックス３０２と３０３、及びボタン３０４と３０５は入力不可状態にしておくことが望ましい。 同様に、音声対話シナリオ１０５及び、音声認識文法１０６が複数の入力項目に関する入力を同時に受け付けられるように記述されている場合は、ＧＵＩアプリケーション１０４においても、同時受付している入力項目のＧＵＩコンポーネントだけを入力可能状態にし、他のＧＵＩコンポーネントは入力不可状態にしておくことが望ましい。

次に、本発明によるマルチモーダルアプリケーション生成ウィザードの一実施例について図を参照して説明する。
図１１は、本発明によるマルチモーダルアプリケーション生成ウィザードのフローの一実施例を示したものである。 本フローに従い、具体的に生成すべきソースコード、対話シナリオ、音声認識文法の形式について説明を行う。

マルチモーダルアプリケーション生成ウィザードが実行を開始する（Ｓ０１）と、アプリケーションを生成するのに必要な情報が記載されたアプリ定義ファイルを読み込む（Ｓ０２）。 アプリ定義ファイルには、少なくとも(1)質問項目の数、(2)各質問項目の名称、 (3)各質問項目に対する典型的な回答例の３種類の情報が含まれている必要がある。

アプリ定義ファイルには、オプションとして(4)直前の入力の訂正を許可するかどうかの情報及び、(5)各質問項目に関するガイダンス情報を含めても良い。

図４(a)(b)は、本発明によるマルチモーダルアプリケーション生成ウィザードが生成するマルチモーダルアプリケーションの対話シーケンスの例を表した図である。 この例では、それぞれ(1)出発駅名(departure)、(2)到着駅名(destination)、(3)座席のクラス(class)をユーザが入力すべき項目としている。 また、両者とも各入力項目を順番に入力することをユーザに求める形式になっている。 (a)と(b)で異なるのは、音声認識エンジン１０１が認識結果を誤ったり、ユーザが入力を誤ったときに、その場で直前の入力を訂正することができるかどうかであり、アプリ定義ファイルに記載された(4)の情報によって、どちらの形式の対話を生成するかを決める。 オプションが与えられなかった場合は、いずれかの形式の対話をデフォルトで生成すればよい。

次に最初の質問項目に対する音声認識文法１０６を生成する（Ｓ０３）。 最初の質問項目では、訂正発話の可能性がないため、図４の(a)(b)の対話形式ともに同一形式の音声認識文法を生成すればよい。

音声認識文法１０６の生成には、(3)の各質問項目に対する典型的な回答例の情報を利用することができる。 発音と表記の組を複数、回答例として与えた場合、図６(a)のような音声認識文法１０６を生成することができる。 この音声認識文法の例は、Ｗ３Ｃの勧告するＳＲＧＳで定義されたＡＢＮＦ形式に基づいた表記方法を用いている。 「発音 { 質問項目の名称 = "表記"}」という形式で、開発者から与えられた情報を用いている。 発音の表記の組をただ１つ与えた場合は、図６(b)のような音声認識文法１０６を生成することができる。 このような音声認識文法１０６を生成することで、発話例を後から増やす場合に、どのような記述を行えば良いのか、開発者に知らせることができる。

次に、直前の入力の訂正が可能な対話を生成するか否かで、処理を振り分ける（Ｓ０４）。 まず、直前の入力の訂正ができない図４の(a)の対話形式のアプリケーションの生成フローについて説明する。

図４の(a)の対話形式の場合、訂正発話を受理する必要がないため、生成する音声認識文法１０６は、全ての質問項目に対して図６の形式のものを生成すればよい。 さらに、最終確認用の音声認識文法１０６として、「はい」「いいえ」を認識語彙の音声認識文法を出力する（Ｓ０５）。

次に、対話シナリオ１０５を生成する（Ｓ０６）。 図５は、本発明によるマルチモーダルアプリケーション生成ウィザードが生成した図４の(a)の対話形式のマルチモーダルアプリケーションを構成する対話シナリオ１０５の一例であり、ＶｏｉｃｅＸＭＬ形式で記述されている。 この記述方式においては、(1)の質問項目の数は、生成するＶｏｉｃｅＸＭＬドキュメントに含まれる<field>要素の数として扱うことができる。 また(2)の各質問項目の名称は、各<field>要素のname属性の値及び参照する音声認識文法１０６の名称として扱うことができる。 (5)の各質問項目での音声ガイダンスは、各<field>要素内の<prompt>要素の内容として扱うことができるが、指定がなかった場合は、図５のように「質問項目名称の発声を促すガイダンス」という文字列を出力しておき、後で開発者が簡単に修正できるようにしておけばよい。 さらに発声がなかった場合のガイダンス音声に関する記述例や、全ての質問項目が入力された後での確認ガイダンスの例や、確認が肯定的だった場合と、否定的だった場合のそれぞれの処理の例を自動生成することで、開発者の工数を削減することができる。 確認ガイダンスの例としては、入力された各質問項目の内容をユーザに聞かせることが有効なので、<value>要素を用いて各入力内容を参照したガイダンス文章の例を自動生成することが望ましいが、開発者は自分の判断によってガイダンスを修正することも可能である。

次に、ＧＵＩアプリケーション１０４のソースコードを生成する（Ｓ０７）。 図７は、本発明によるマルチモーダルアプリケーション生成ウィザードが生成したＧＵＩアプリケーション１０４のソースコードの一例であり、Ｊａｖａで記述されている。

図７(a)は、質問項目に対応するＧＵＩコンポーネントを生成するコードである。 現在の音声認識システムの性能では、ＧＵＩでのテキストボックスのような自由入力をサポートすることは困難であるとともに、例え音声認識が正確にできたとしても、その内容を理解して対話を進めることも困難である。 従って、各質問項目に対応したＧＵＩコンポーネントとしては、あらかじめ決まった複数の選択肢から選択を行うタイプのもの、すなわちドロップダウンリストや、ラジオボックスなどが適している。 どのＧＵＩコンポーネントを利用するかは、開発者に問い合わせてもよいし、選択肢の個数を開発者に問い合わせて、数が多い場合はドロップダウンリストを用い、少ない場合はラジオボックスを用いるなどしてもよい。 図７(a)の例では、ドロップダウンリストを生成している。 ドロップダウンリストを説明するラベルコンポーネントのタイトルには、(2)の質問項目の名称が利用されている。 また、(3)の各質問項目に対する典型的な回答例は読みと表記の情報が利用されている。 音声認識文法では、図６(a)のように１つの選択肢に対して複数の読みを用意することがあるが、ＧＵＩコンポーネントでは冗長となるので、表記が同じ回答例については、１つだけ選択して用いることが望ましい。 ＧＵＩコンポーネントの生成コードは、(1)の入力項目数だけ生成する。

図７(b)は、これらのＧＵＩコンポーネントの登録と、このＧＵＩコンポーネントが操作されたときの動作を表すソースコードの一例である。 一般的には、ＧＵＩコンポーネントが操作された場合の処理は各アプリケーションによって異なるため、自動生成は困難であるが、ここでは対話制御部１０３に対して、擬似音声認識結果を通知するコードのみを生成している。 これによってＧＵＩ操作を行った場合も、音声で操作した場合と同様に対話を進行させることができる。 対話制御部１０３は、本当の音声認識結果が得られた場合でも、擬似音声認識結果が与えられた場合でも、音声認識結果によって、ＶｏｉｃｅＸＭＬの仕様に従って、適切なフィールドに値を代入すればよい。 音声認識結果はＷ３Ｃが標準化を進めているＳＩＳＲ（Ｓｅｍａｎｔｉｃｓ Ｉｎｔｅｒｐｒｅｔａｔｉｏｎ ｆｏｒ Ｓｐｅｅｃｈ Ｒｅｃｏｇｎｉｔｉｏｎ）に基づいた記述方式で表現できる。 例えば名称が「departure」である質問項目に関して、「東京」という入力が、ＧＵＩもしくは音声で行われた場合は、入力された内容が属するカテゴリーとその値のペアという形式で、「{ departure : "東京"}」と表現することができる。 図７(b)のソースコードでも、ＧＵＩで選択された項目に対して、上記の音声認識結果を表現する文字列を生成している。 カテゴリー情報とその値のペアという形式を用いることによって、どの質問項目に対する入力であるかが、入力方法を問わず明確になるとともに、音声入力によって複数の質問項目に対して入力が行われた場合でも対応できるという利点がある。

対話制御部１０３の処理において、フィールドに値が代入されると、対応するイベントがＧＵＩアプリケーション１０４のイベントハンドラに通知される。 図７(c)は生成するイベントハンドラの一例である。 値が代入されたフィールド名と、代入された値が対話制御部１０３から通知される。 フィールド名には開発者が与えた質問項目名称を用いているので、ここでも質問項目名称を用いて、どの質問項目に対する入力があったのかを判断して、処理を振り分けるコードを生成すればよい。 各質問項目への入力に対する処理は、通知された入力内容に応じてＧＵＩコンポーネントの選択項目を変更する処理（choice1.select(argValue)）と、対話の進行状況に応じてＧＵＩコンポーネントの入力可能/不可能状態を変更するコードを呼び出すコード(setDialogStatus(1))を生成すればよい。

図７(d)は、対話の進行状況に応じてＧＵＩコンポーネントの入力可能/不可能状態を変更するコードの実体である。 図４の(a)の形式の対話では、現在質問している項目以外は、入力不可能な状態であることが望ましいため、全てのＧＵＩコンポーネントを入力不可能状態にしてから、対話の進行状況に応じて現在の質問項目に対応したＧＵＩコンポーネントを入力可能状態にするコードを生成すればよい。

次に、直前の入力内容を訂正する発話や、ＧＵＩ操作を許容するように開発者がウィザードに対して指示した場合のウィザードのフローについて説明する。

図４の(b)の対話形式において、出発駅が入力された後、到着駅の入力が要求されている段階で、ユーザに許容されている操作が次の４つになるようにマルチモーダルアプリケーションを生成することが望ましい。 すなわち(A)音声操作で到着駅（現在の質問項目）を選択、(B)音声操作で出発駅（直前の入力項目）を訂正、(C)ＧＵＩ操作で到着駅（現在の質問項目）を選択、(D)ＧＵＩ操作で出発駅（直前の入力項目）を訂正である。 以下の対話シーケンスにおいても同様である。

まず(A)(B)を実現する音声対話シナリオ１０５を生成する（Ｓ０８）。 図８は、本発明による対話ウィザードが自動生成する対話シナリオ１０５の一例である。 <field>要素の数や、各要素name属性の名称、<prompt>の内容などを開発者が入力した情報から生成していることは図５の対話シナリオ１０５の例と同様である。 図５と異なるのは、直前の入力内容をユーザに提示し、現在の質問項目に加えて訂正発話も受理する音声認識文法を指定し、現在の質問項目への入力か、訂正発話かで、それに応じた処理を行う部分である。 具体的には、<prompt>の内容として開発者が与えた質問項目に加え、直前の入力内容を確認する文章（<value expr=”直前の質問項目名称”/>ですね？>）を自動生成することが望ましい。 また参照する音声認識文法１０６の名称も「現在の質問項目名称_correct.abnf」と設定することで、開発者が生成された対話シナリオを見たときに、訂正が許容されることが分りやすくなる。 ユーザの発声が、現在の質問項目に対する入力であるか、直前の入力内容に対する訂正であるかを判断するためには、すでに説明した音声認識結果の表現形式である「{ destination : "大阪"}では、情報が足りない。そこで、訂正発話を表現として「{ destination : { correct : "true" departure : "名古屋"}}」のような形式を用いる。 この例では、destinationを入力するステップにおいて、訂正発話が行われ、直前のdepartureの内容が名古屋に訂正されたという意味である。 一方、現在の質問項目に対する入力を表す表現形式は、「{ destination : { correct : "false" destination : "東京"}}」のようになる。 訂正発話を許容する各<field>要素内で、<if>要素を用いてcorrectの内容を判断し、訂正発声と判断された場合は、直前の入力内容を<asign>要素を用いて、「現在の質問項目名称.直前の質問項目名称」という変数で書き換え、まだ入力が完了していない現在の質問項目のフィールド変数をクリアする記述を自動生成し、訂正発話ではないと判断された場合は、現在の質問項目のフィールド変数の値を「現在の質問項目名称.現在の質問項目名称」という変数の値で書き換える記述を自動生成することが望ましい。
図８の例では、最終確認のステップでは、直前の「class」が訂正できないようになっているが、開発者が最終確認のステップでの訂正発話を許容するかどうか選択できることが望ましい。 最終確認のステップでの直前の入力内容に対する訂正発話を許容する場合は、参照する音声認識文法１０６の名称を「yesno_correct.abnf」など分りやすい名称にし、認識結果が訂正発話であるかどうかを判断する<if>要素も自動生成すればよい。

次に直前の入力内容に対する訂正発話を許容する音声認識文法１０６ついて説明する。 直前の入力内容に対する訂正発話としては「大阪ではなくて名古屋」のような言い回しが考えられる。 このとき「ｘｘｘではなくてｙｙｙ」のような言い回しを全てのパターンについて受理可能な音声認識文法１０６を自動生成することが考えられる。 しかしこの場合、直前の入力内容が「大阪」だった場合でも「東京ではなくて名古屋」のような発声を受理してしまうことと、全てのパターンを受理するために音声認識文法１０６のサイズが大きくなってしまうことから、最適な方法ではない。 別の方法として、直前の入力内容から参照する音声認識文法１０６の名称を動的に決定する方法が考えられる。 例えばＷ３ＣのＶｏｉｃｅＸＭＬ２．１Ｗｏｒｋｉｎｇ Ｄｒａｆｔに記載の音声認識文法指定方法であれば、「<grammar srcexpr="departure + '_correct.abnf'"/>」のように記述することで、「大阪」という直前の入力に対して、「大阪_correct.abnf」という音声認識文法１０６を次の質問項目のステップで参照することができる。 この方法により、適切でない言い回しを排除できるため有利である。 また別の方法としては、参照する音声認識文法１０６の名称は「現在の質問項目名称_correct.abnf」に固定してＧＵＩアプリケーション１０４がこのファイル名を持つ音声認識文法１０６を自動生成する方法が考えられる。 ここでは、最後の自動生成を行う方式に基づいて説明するため、マルチモーダル生成アプリケーションの次のフローは音声認識文法を自動生成するソースコードの生成となる（Ｓ０９）。
図９は、ＧＵＩアプリケーション１０４が自動生成する、直前の入力内容を考慮した音声認識文法１０６の一例である。 すでに説明した訂正発話かどうかが判断可能な形式の認識結果が得られるようにＳＲＧＳ形式で記述されている。 直前の入力内容にかかわらず文法の構造は同一であり、直前の入力内容によって変化する部分は、$correctの先頭の単語が直前の入力内容であることと、$correctの末尾にある訂正候補のリストから直前の入力内容が除外されていることである。 本発明によるウィザードでは、直前の入力内容の読みと表記を与えることで、上記のような音声認識文法１０６を生成するコードをＧＵＩアプリケーション１０４の中に自動生成できる（Ｓ０９）。

次に、直前の入力内容を訂正可能で、対話シナリオ１０５と連携可能なＧＵＩアプリケーション１０４のソースコードの自動生成（Ｓ１０）について説明する。
図１０は、本発明によるウィザードが自動生成するＧＵＩアプリケーション１０４のソースコードの一例である。 図１０(a)では、図７(a)の例と同様に、ドロップダウンリストを生成している。 ドロップダウンリストを説明するラベルコンポーネントのタイトルには、(2)の質問項目の名称が利用されている。 また、(3)の各質問項目に対する典型的な回答例は読みと表記の情報が利用されている。 図１０(b)は最初の質問項目、(d)はそれ以降の質問項目に対するＧＵＩコンポーネントが操作された場合のイベントハンドラである。 変数stateは対話の進行状況を表す変数であり、同じＧＵＩコンポーネントが操作された場合でも、現在の質問項目に対しての入力なのか、次のステップに移った後での訂正入力なのかを区別することができる。 図１０(b)は、最初の質問項目に対するイベントハンドラであるため、現在最初の質問項目のステップにある場合(state=0)は、訂正する内容がないため、「{ departure : "大阪"}」のような認識結果表現を生成するためのコードを自動生成し、次のステップに移っている場合(state=1)は、「{ destination : { correct : "true" departure : "名古屋"}}のような、次のステップで直前の入力内容に対する訂正発話を行った場合と同様の認識結果表現を生成するためのコードを自動生成すればよい。図１０(d)では、現在の質問項目に対する入力を表す認識結果表現も、「{ destination : { correct : "false" destination : "東京"}}のような訂正入力かどうかの判断ができる記述形式で生成するコードを自動生成すればよい。図１０(c)の<field>要素に値が代入された場合のイベントハンドラコードは、図７(c)のコードとほぼ同一のものを自動生成すればよいが、異なるのは入力内容によって、次のステップでの音声認識文法１０６を自動生成するコードを呼び出すコード（makeDic(argValue)）が追加されていることである。図１０(e)は、上で述べたユーザ操作に関する制限の(c)(d)を実現するためのコードであり、ウィザードは、現在の質問項目と、直前の質問項目以外のＧＵＩコンポーネントを操作できないようにするコードを自動生成すればよい。そのためには、最初の質問項目の場合(step=0)は、最初の質問項目に対するＧＵＩコンポーネントのみを有効にするコードを自動生成し、それ以降の状態では、現在の質問項目と直前の質問項目だけを有効にするコードを自動生成すればよい。

本発明は、パーソナルコンピュータや、ＰＤＡ、カーナビゲーションシステムなど、音声対話機能とＧＵＩ操作機能を搭載する情報機器向けのプログラム開発に利用することが可能である。

マルチモーダルアプリケーションの構成の一実施例を表す図。

対話シナリオの記述例の一実施例を表す図。

ＧＵＩアプリケーションの画面の位置実施例を表す図。

自動生成されるマルチモーダルアプリケーションの対話シーケンスの一実施例を表す図。

自動生成されるマルチモーダルアプリケーションの対話シナリオの一実施例を表す図。

自動生成されるマルチモーダルアプリケーションの音声認識文法の一実施例を表す図。

自動生成されるマルチモーダルアプリケーションのＧＵＩアプリケーションソースコードの一実施例を表す図。

自動生成されるマルチモーダルアプリケーションの対話シナリオの一実施例を表す図。

自動生成されるマルチモーダルアプリケーションのＧＵＩアプリケーションが自動生成する音声認識文法の一実施例を表す図。

自動生成されるマルチモーダルアプリケーションのＧＵＩアプリケーションソースコードの一実施例を表す図。

マルチモーダルアプリケーションの自動生成フローの一実施例。

符号の説明

１００・・・ＯＳ
１０１・・・音声認識エンジン１０２・・・音声合成エンジン１０３・・・対話制御部１０４・・・ＧＵＩアプリケーション１０５・・・対話シナリオ１０６・・・音声認識文法１０７・・・音声認識結果１０８・・・擬似音声認識結果１０９・・・対話の進行状況を表すイベント３０１・・・現在入力対象となっているドロップダウンリスト３０２・・・現在入力対象外のドロップダウンリスト３０３・・・現在入力対象外のドロップダウンリスト３０４・・・現在入力対象外のボタン３０５・・・現在入力対象外のボタン。