発話が再開される．このように，発話内容が完全に決定するのを待たずに，話し 言葉特有の小さな発話単位による発話が可能となった時点で発話を開始できるの で，システムは発話すべきときに即座に発話を開始することが容易となる．以上 の方法によっても時間制限内に発話を開始することができず，ポーズ監視部によっ てポーズが一定の時間制限を越えたことが検出された場合には，対話制御部は発 話生成部につなぎ語(例：「えーっと」)を出力するように命じる5．
システム発話の途中にユーザからのアイヅチや割り込み発話が発生すると，発 話生成部は，発話理解部，対話制御部と連動して，協調的対話原則にしたがって ユーザのアイヅチ，割り込み発話に対処する．発話理解部は，現在の対話状態に 依存してユーザ応答タイプを分類し，対話制御部に知らせる．システムのどの対 話行為に対してユーザ応答が起きたのかが対話状態に書き込まれる．対話制御部 は，応答タイプと協調的対話原則にしたがって，必要なら発話を中断し，発話プ ランを変更するように発話プランニング部に指令する．システムは話し言葉特有 の小さな発話単位を使って段階的に情報を伝達しているので，ユーザのアイヅチ や割り込みに即座に対処でき，協調的対話原則にしたがって臨機応変に話の進め 方を変更しながら，自然な発話を生成することができる．
これらはGriceによる協調の原則 [33]の一例とみなすことができる．協調的対 話原則7と協調的対話原則8は，整然と話せ，簡潔な言い方をせよというGriceの 様態の原則の一例であり，協調的対話原則 9は，現在の対話目的と関連のあるこ とを話せという関連性の原則の一例である．
対話状態には，発話プラン，ユーザに伝達済みの情報，ユーザ応答の履歴，注 視状態 [34]が書き込まれる．発話プランニング部は発話プランを対話状態に書き 込む．発話実行部は，発話プランに含まれる個々の対話行為の実行が完了したら，
その対話行為が実行済みであることを対話状態に書き込む．このことによってユー ザに伝達済みの情報が何かを判断することができる．発話理解部は，システムの 発話に対してユーザからの応答が発生したら，ユーザ応答がどのシステム対話行 為に対して行われたかを対話状態に書き込む．
注視状態の追跡は，注視状態の移行を伴う言語表現ごとに，注視状態を追跡す るためのルールを書くことによって行っている．たとえば，交通経路案内の対話 において場所S から路線Lで場所D まで移動するという行為の内容を「行く」，
「出る」といった主動詞を使って記述するための一連の発話を行うとする．この一 連の発話が実行された後では，注視される対象はDに移行する．また，この一連 の発話が注視状態に対して適切であるためには，発話を開始した時点で場所Sが 注視されている必要がある．もし場所Sが注視されていないなら，場所Sを提題 化する必要がある．
4.5 問題解決
問題解決とは与えられた問題を解くドメインプランを立案することである．ド メインプランはドメイン行為の列として表される．交通経路案内に関する対話で は，ドメイン行為は主としてある場所から別の場所まで交通機関を使って行くと いう移動行為である．ドメインプランは階層的プランニングの技法を使って段階 的に詳細化されるとする．問題解決のメカニズムは漸次的発話生成手法の理解に 直接関与しないので，その詳細には立ち入らない．ここでは，図4.4に示す路線図 において武蔵野センタから厚木センタまで行くという問題が与えられた場合を例 にとって，問題解決部の振舞いを例示する．
ෘᧁ⎇ⓥࡦ࠲
ᱞ⬿㊁⎇ⓥࡦ࠲
ਃ㣔 ศኹ
ᣂኋ
ਅർᴛ
ᗲ↲⍹↰
ࡃࠬ ࡃࠬ ਛᄩ✢
ዊ↰ᕆ✢
ߩ㗡✢
ࡃࠬ
図 4.4: 路線図の例
この場合，最初に立案されるドメインプランは，武蔵野センタからバスでその 最寄り駅に移動し，そこから厚木センタの最寄り駅まで移動し，そこからバスで 厚木センタに移動するという3つの行為 a1, a2, a3 から成る抽象的なドメインプ ランである．このプランは次の表現(4.1)で表され，各行為の情報内容は(4.2)の ように表される．cont(X, Y)はXの情報内容が論理式の集合Y で表されることを 意味する．また，行為の行為者を表す引数は本章を通じて簡単のため省略する．
plan([a1, a2, a3]). (4.1)
cont(a1, {type(a1, move), source(a1, x1), (4.2) manner(a1, x2), dest(a1, x3)}).
cont(x1, {type(x1, building), named(x1, “武蔵野センタ”)}).
cont(x2, {type(x2, bus)}).
cont(x3, {type(x3, station), nearest(x3, x1)}).
cont(a2, {type(a2, move), source(a2, x3), dest(a2, x4)}).
cont(a3, {type(a3, move), source(a3, x4),
manner(a3, x5), dest(a3, x6)}).
cont(x4, {type(x4, station), nearest(x4, x6)}).
cont(x5, {type(x5, bus)}).
cont(x6, {type(x6, building), named(x6, “厚木センタ”)}).
次に，問題解決部はより詳細なドメインプランの立案を進める．与えられた問 題を解く二つ以上のドメインプランが可能なら，最短時間で目的地点まで移動で きるドメインプランを選択する．図 4.4に示す路線図においては，選択されるド メインプランは，武蔵野センタからバスで吉祥寺へ移動し，そこから井の頭線で 下北沢へ移動し，そこから小田急線で愛甲石田へ移動し，そこからバスで厚木セ ンタへ移動するという4つの行為a4, a5, a6, a7 から成るプランである．このプラ
ンは次の(4.3)で表され，行為a4の情報内容は(4.4)で表される．他の3つの行為
a5, a6, a7の内容を記述するための表現は簡単のため省略する．
plan([a4, a5, a6, a7]). (4.3)
cont(a4, {type(a4, move), source(a4, x1), (4.4) manner(a4, x2), dest(a4, x7)}).
cont(x7, {type(x7, station), named(x7, “吉祥寺”)}).