# 応用システム論文
## 小型計算機におけるサービス指向発話文解析

\author{
徳久雅人 $\dagger \cdot$ 日木村周平 $\dagger$
}

本稿では，様々なサービスを有する小型計算機に言葉による命令を受理させる手法について述べる。小型計算機における発話文解析では, サービスのための規定の発話文を必ず受理すること，および，ユーザからの発話文を追加的に学習することを低い計算コストで行うことが要求される。そこで，サービスごとに語義やチャンクを正確に区別するため，サービスごとにパージング結果を格納するアレイを設け，強化学習を用いて発話文解析を進める手法を提案する．実験において自動車旅行を支援する車載器の発話文解析に応用したところ, 軽量に動作し, クローズドテストにおいて 0.99 , オープンテストにおいて 0.81 という精度で発話文解析が可能であることを確認した。

キーワード：発話文解析, 意図解析, スロットフィリング, サービス指向解析, 強化学習

## Service-Oriented Utterance Sentence Analysis in Small Computers

\author{
Masato Tokuhisa $^{\dagger}$ and Shuhei Kimura ${ }^{\dagger}$
}

This paper addresses a method to analyze command utterance sentences in small computers providing various services. All compulsory command utterances for the services must be accepted, and the utterances by the user must be able to be learned at a low computational cost. So as to determine the chunks and their sense based on their service, our proposal method contains parsing arrays for each service and performs utterance analysis and learning through reinforcement learning. Using the results of an in-vehicle computer implementation for a car traveler, it was confirmed that the proposed method was generally successful, with an analysis accuracy of 0.99 in a closed test and 0.81 in an open test.

Key Words: Utterance Analysis, Intent Detection, Slot Filling, Service-oriented Analysis, Reinforcement Learning

## 1 はじめに

近年, $\mathrm{CPU}$ が $1.2 \mathrm{GHz}$ 程度で主記憶が $1 \mathrm{~GB}$ 程度だが安価な小型計算機が広く利用されている。その小型計算機では様々なサービスが提供されている。キーボードなどの入力装置を有


しない状態で使用される際に，小型計算機に指示を出す手段として，言葉による命令があげられる。ここで，車載器のように屋外環境での使用が想定される場合，インターネットの常時接続が期待できない。また，個人利用においてはスタンドアロンが望ましい。そのため，言語処理を小型計算機上で行うことが要求される.

小型計算機での言語処理への要件が幾つかある。一つは，サービスを操作する命令文は規定の文であれば確実に受理されることがユーザに約束できることである. サービスに応じて語義が区別されることが必要である。つまり，あるサービスにおいてはキーとなる用語であっても，別のサービスにおいてはキーにならないことが区別されることである．したがって，語義解析やチャンキングを行う際，サービスに依存することが必要である。また，一つは，少し言い回しの外れた文であっても受理されることである。単純なパターンベースの解析手法では対応がとりにくい，最後の一つは，受理されなかった言い回しは，サービスの利用中に，受理に向けて学習されることである。サービスのために CPU と主記憶の計算リソースを残しておく必要があるため，言語の解析，および，追加的に行う学習は軽量でなければならない.

関連研究として，対話処理において，対話行為を識別する手法が提案された。識別における有力な素性は, 単語 n-gram, および，直前の発話の対話行為である。対話行為毎に詳細な素性の選択を行うことで, 対話行為の識別性能の向上が示された (福岡, 白井 2017). 対話行為識別 （意図解析）の後段での応答処理のために，発話文からの情報抽出が必要である．その一つがスロットフィリングである，スロットフィリングは，確率有限状態トランスデューサ，識別器に基づく系列ラベリング, 条件付き確率場 Conditional Random Fields (CRF)の3つの解法の中でも CRF が良好に動作することが示された (Raymond and Riccardi 2007)。近年では，意図解析，スロットフィリングおよび言語モデリングを同時に行う手法が提案された (Liu and Lane 2016). この手法では, Recurrent Neural Network (RNN) により単語 n-gram 相当の特徴を含む情報を参照した意図解析が行われた。同時に，単語単位での系列ラベリングに相当する働きにより，単語とスロットとの対応が識別されることで，スロットフィリングが行われた。意図解析とスロットフィリングが同時に尤最もらしいことが評価されるため，全体の識別性能が向上したものと解釈できる。なお, Embedding からの単語ベクトルと, 前時刻（単語単位）からの意図クラスとが合わさることで，意図毎（対話行為毎）の素性選択に相当する語彙識別が働いた可能性がある．Liu らの手法を改良した RNN を用いることについて，日本語文における解析性能が報告された (長井, 突, 加藤, 山本 2018). RNN の双方向性, Attention モデル, 未知語処理が追加された.未未知語処理には汎用単語分散表現が用いられた.この分散表現の獲得には日本語 Wikipedia テキストからの word2vec での解析が行われた.

意図解析とスロットフィリングなどの言語理解の後段の処理として, 対話状態追跡, 対話ポリシの適用，自然言語生成がある。対話状態追跡では，スロット値の候補に確率を対応付けて信念状態を表す。対話ポリシの適用は，タスクとして外部知識を検索するなどを行い，応答の

ための対話行為を決める．自然言語生成は対話行為からテキストを生成する．これらの流れをニューラルネットワークを基礎として end-to-end でモデル化することが提案された (Liu and Lane 2018). システム状態の設計は複雑になりがちであるが，Liu らの手法は信念状態がニュー ラルネットワークに組み込まれることなどによりシステムの状態が定義されることで，設計の問題を回避した. さらに, 強化学習を用いることで, 状態に応じたシステムの応答を学習した.一方，音声認識，意図やスロットの解析には誤りが含まれやすい．言語理解に対する信頼性が低いことを考慮してシステムの応答を行うために部分観測マルコフ決定過程 Partially Observable Markov Decision Process (POMDP) が対話システムに導入された (Williams and Young 2007). POMDP では信念状態に対するシステムの応答を決める。対話事例から強化学習を行うことで対話ポリシをモデル化できる。後段の処理でのこれらの手法は，複数ターンに渡る発話を通じてタスクを達成させるために有益な手法である.

ここで, 本稿では, 小型計算機への命令を受理するための言語理解の段階, すなわち, 意図解析およびスロットフィリングについて議論する。言語理解の後段の処理は, 命令を受けたサー ビス処理部が対処するものとする。言語理解の段階においては, 単語 n-gram 素性, 文脈情報,意図毎の素性選択，未知語対応，および，意図解析とスロットフィリングの同時性という 5 点に着目する。しかし, 小型計算機において, RNN による意図解析・スロットフィリングの学習と解析は計算コストが高い。ここで，スロットフィリングとは，文頭から文末にかけて文の単語列をスキャンする間に，参照している単語の代入先を識別することである．スキャン（参照先を次単語に進める）と代入というアクションを，状態に応じて適切に行うことでスロットフィリングが実現できる見込みがある。状態に対するアクションを学習する方法として強化学習があげられる，そこで，本稿では，上記 5 点を考慮しつつ，サービス依存のパージングおよび強化学習を用いて, 発話文の学習と解析を行うことを目的とする. 自動車旅行を支援する車載器の上に提案手法を実装し発話文解析の評価を行う。

本稿の構成は次のとおりである。まず第 2 章では，発話事例，意図とスロットに関する諸定義，および，発話文コーパスを示す。第 3 章では提案手法を示す. 第 4 章で車載器に実装した発話文解析について性能を評価する。第 5 章で提案手法の特性を考察し, 第 6 章でまとめを述べる.

## 2 発話文と諸定義

## 2.1 車載器での発話例

本稿の車載器は表 1 に示すサービスを提供する。サービスの表現方法は, 音と映像である.音は音楽や合成音声である。映像は, 背景画像, 箇条書き表示, タイトル表示, トースト表示,動画である．表現方法が競合しない限り複数のサービスが同時に実行できる．競合する場合,
表 1 サービス一覧

 \\

& ブラウザ \end{aligned} &  \\

連携して起動されるサービスが劣位となり，ユーザから直接命令されたサービスが優位となる。

まず，簡単な発話例を以下に示す。話者に付随する数字は発話の順番を表す。

例 1 :

1 ユーザ：「音楽をかけてください」

2 ユーザ：「鳥取の地図を表示してください」

3 ユーザ：「次に変えてください」

1 文目で「音楽サービス」が起動する．以前からの続きの曲が再生される．「アルバムアートサービス」によりその曲のアルバムアートが車載器のモニ夕に表示される。 2 文目で「地図サー

ビス」が起動する，画面が書き換えられるため，「アルバムアートサービス」が終了する．画面には「鳥取県の地図」が表示される。 3 文目で「次の曲」が再生される.「次に変える」は，何を次に変えるのかが不明確であるが，「音楽サービス」が起動中であるため「次の曲の再生」という意味で処理される。なお，「地図サービス」が起動中であるため「アルバムアートサービス」 は自動的には起動しない（アルバムアートの表示が命令されれば起動する）.

次に，ユーザの発話意図が実行中のサービスの範囲に限定される発話例を以下に示す.

例 2 :

1 ユーザ : 「予定を登録してください」

2 車載器 : 「予定を話してください」

3 ユーザ :「明日の 17 時にレストランに行きます」

4 ユーザ：「その前に駅に迎えに行きます」

5 ユーザ：「以上です」

6 車載器：「登録しました」

1 文目で「スケジュール管理サービス」が起動する。後続の発話文がこのサービスに向けられていることを前提として発話文解析が行われる。 3 文目および 4 文目から伝達される事象は 「スケジュール内容」として登録される。 5 文目でこの前提が解除される.

ユーザの発話意図が強く限定される発話例を以下に示す.

例 3:

1 ユーザ :「Wikipedia で調べてください」

2 車載器：「何について調べますか」

3 ユーザ : 「東京タワーです」

1 文目で「観光ガイドサービス」が起動し，サービス処理部でクエリを待つ状態になる． 3 文目では意図解析は行われず，直接サービス処理部で文字列の処理が行われる。判定詞の除かれた文字列「東京タワー」がクエリとして扱われる。

最後に訂正を含む発話例を以下に示す。

例 $4:$

1 ユーザ :「鳥取の地図じゃなかった島根の地図を表示してください」

地図サービスは「島根県」の地図を表示する。文の解析の前半では「鳥取」が表示の対象となるが，解析の後半では「島根」だけが対象となる.

## 2.2 発話文の分類

車載器では, ユーザから話し掛けることが基本となる。ユーザの発話は次の 4 種類に分類される。

分類 1. ユーザが新規のサービスについて発話する.
分類 2. ユーザが実行中のいずれかのサービスについて発話する.

分類 3. ユーザが実行中の特定のサービスについて発話する.

分類 4. 車載器からの質問に，ユーザが回答として発話する.

前節の例でいえば，例 1 の 1 文目と 2 文目は分類 1 であり， 3 文目は分類 2 である. サービスを特定する単語の有無が分類 1 と分類 2 を区別する手がかりとなる．例 2 の 3 文目と 4 文目は分類 3 である. 5 文目のように登録を終了する意図の発話があるまでは分類 3 が想定されている。例 3 の 3 文目は分類 4 である.

これらの分類では, 実行中のサービスに発話が継続するか否かという区別がある. 分類 1 の発話は継続性が無い．本稿では「継続性 $=$ new」というフラグを用いることにする．分類 2,3 , 4 は継続性がある．本稿では「継続性 $=$ cont」というフラグを用いることにする．継続性のない発話文にはサービスを特定する手がかり語が含まれる。継続性のある発話文にはサービスを特定する語は必ずしも含まれない。一方, 分類 3 と分類 4 ではサービスの処理側で発話解析の方法が指定される。

## 2.3 意図クラスとスロット

ユーザは，発話によりサービスを起動して細かい指示を出す。本稿では，「サービス名，メソッド名，および，メソッド引数」の3つ組を意図クラスと呼ぶことにする。一般に対話理解においては，対話行為識別の後に構造解析を経て意図解析・スロットフィリングという過程がある.対話行為には対話のドメインに依存しないカテゴリとして「Inform, Request, Confirm, Question, Agreement/Disagreement」などが用いられる (Bunt, Petukhova, Traum, and Alexandersson 2017). 本稿では, (Liu and Lane 2016; 長井他 2018) のように，発話文からドメインに依存して直接的に意図解析・スロットフィリングを行うことを議論する。例えば，「音楽を再生してください」という発話文からは「serviceMusic.comPlay()」という意図クラスが同定される.「音楽が聴きたい」も「serviceMusic.comPlay()」という意図クラスが同定される。ここで，「serviceMusic」は「音楽サービス」，「comPlay()」は「曲の再生を意味するメソッド」である.

スロットはメソッドの引数と対応する。例えば，「次の曲に変えてください」という発話文には,「serviceMusic.comSelect(dir)」という意図クラスが対応し，「dir=次」というスロットフィリングが行われることを理想とする 1.

## 2.4 発話文コーパス

ユーザの発話文をコーパスに収録する。コーパスの一部を表 2 に示す。収録した項目は，「通番, 発話文, サービス，メソッド，継続性」である。1 文単位で収録する。通番は管理用である. 発話順は不問である.
^{1}$ dir は direction の略. 選曲の方向（次の曲/前の曲など）を表す。
}
表 2 ユーザによる発話文のコーパス（説明用に抜粋）

 & controller & comShutdown (obj, act) & new \\

※メソッド引数（スロット名）の意味 $:$ obj $=$ object 対象, act $=$ action 動作, dir $=$ direction 内容選択の方向, unit $=$ 単位, $l o c=$ location 場所 $\cdot$ 地名,$i o=$ zoom-in/out 拡大縮小の方向,$t m g=$ timing 日時・時間的・順序的な関係の表現, $\mathrm{msg}=$ message 用件.

発話文に挿入されるタグはスロットに代入される部分を表す。一つのスロット名が複数の部分と対応することもある（＃21での tmg夕グ．数は表 2 の通番, 以下同様).「cancel」属性のある夕グは, 前述の例 4 で示したとおりで, スロットフィリングの最終的な解とならない部分を表す (\#15, \#16). スロットに代入する語句が発話文に存在しない場合がある．つまり，文意としては代入する情報が理解できるが，その情報が陽に記述されていない場合である。この場合，夕グを付与することができない。そこで，メソッドの引数にデフォルト値を指定する形式を認めている $(\# 6, \# 9)$.

サービスとメソッド名が一致するがメソッドの引数が異なる場合, 両者の意図クラスは異なるものとして扱う $(\# 6, \# 7, \# 8, \# 9)$. 発話文の表現が異なるが，サービス，メソッド名，メソッド引数が一致する場合, 同じ意図クラスであり, 同等あるいは同類の文である $(\# 17, \# 18$,

\#19). 一方, 同じ表現の発話文であってもサービスやメソッドが異なることがあり，曖昧性のある文がある $(\# 4, \# 11)$. なお, 曖昧性の解消は, 実行中のサービスと継続性を手がかりに解析的に解消する，さらには，サービスの処理部における命令実行の成否をもって動的に解決できる。すなわち，スロットに誤った代入があったことによりサービスの処理が失敗する際，発話文解析に誤りがあったと解釈するものである.

## 3 提案手法

小型計算機における発話文の学習と解析の手法を提案する. 提案手法の流れを図 1 に示す.発話文の解析の過程は，ユーザから発話文が入力されて始まり，発話文のパージング，意図解析，スロットフィリング，解候補の選択，そしてサービスの実行を行うという流れとなる。学習の過程は，まず，発話文コーパスから語句辞書・チャンクルールを手動で設計・構築し, 次に，意図解析用事例の生成，および，スロットフィリング用ルールベースの学習を行うという流れとなる。本章での各節では，パージング，意図解析，スロットフィリング，解候補の選択の順にそれぞれを説明する。

図 1 提案手法の流れ

## 3.1 パージング

パージングでは, 形態素解析, 意味属性付与, サービス別アノテーションおよびチャンキングを行う (図 2).まず, 形態素解析器として mecab (工藤, 山本, 松本 2004) を利用し, 品詞情報を付与する。意味属性付与では日本語語彙大系 (池原, 宮崎, 白井, 横尾, 中岩, 小倉, 大山，林 1997）の名詞意味属性を付与する．次に，サービスで共有される語句辞書あるいはサー ビス毎に用意された語句辞書およびチャンクルールを用いて，品詞や語義を表す夕グの付与およびチャンキングを行う．語句辞書・チャンクルールについては次項で説明する。

サービスごとにアノテーション等を用意することで，語義やチャンクの曖昧性に対処する。例えば，「三月」という語句は，「スケジュール管理サービス」においては「日時」を表す語句としてタグが付与されることが望ましい.「音楽サービス」においては歌手・曲名の一部に使われる単語であるため「日時」の夕グ付与は望ましくない. しかし, パージングの段階では語義やチャンクの決定ができない。そこで，本稿では，サービスを仮定し，サービスが扱う語義・ チャンクに合わせてアノテーションとチャンキングを行い，その結果をサービスごとのアレイに残すことにした。

## 3.1.1 語句の定義

発話文を構成する語句は次のとおりに分類する：

・モダリティ：判定詞自体, および, 述語や判定詞に後続する表現
- 一般予約語句：サービスに関する名称, 機能, 操作量
- 組込み予約語句：実装と密接に対応する語句
- 一般語句：その他の語句

図 2 パージングの構成

モダリティは，「〜ですか」，「〜せずに」，「〜あります」，「〜たくないです」，「〜たいです」，「〜です」,「〜でした」,「〜じゃなくて」,「〜なかったです」,「〜せられ」,「〜てください」,「〜 ないでください」などの表現をカバーし，それぞれ，質問 (AAsk), 除外 (AExc), 存在 (AExi), 拒否 (AIna), 欲求 (AInd), 伝達 (AInf), 伝達（過去） (AInp), 否定 (ANeg), 不在 (ANex), 使役・受け身 (APss), 要求 (AReq), 要求（否定） (ARqn) というモダリティのタグが対応する.

一般予約語句は,「地図/マップ」，「音楽/ミュージック」などサービスを表す語句，「表示をし/表示し/表示/見せ」，「かけ/再生をし/再生し/再生」など機能・メソッドを表す語句，「上/下/左/右」,「東/西/南/北」,「前/後/次」など機能の操作量を表す語句である. サービスや機能を表す語句を「/」で隣接して列挙することで同義語のグループを定義する．操作量を表す語句を「/」で隣接して列挙することで同類語のグループを定義する。一般予約語句には「R 数字」 という語義を表すタグを用いる。数字はグループごとに自動で割り当てられる。

組込み予約語句は，サービスにおける実装と密接に対応する語句である。具体的には日時の表現である．例えば，「明日」という表現に「基準日時の翌日を求める」という処理が対応づけられている。日時の表現には TMGというタグを用いる。

一般語句とは, モダリティと予約語句にならない語句である。一般語句に対しては粗い品詞タグ付与ルール，および，後述するチャンクルールを併用する，助動詞や動詞・非自立 (A), 副詞, 形容動詞語幹, 形容詞 $(M)$, 数 (NM), サ変名詞 (NS), 名詞や名詞接辞 (N), 助詞 $(P)$, 動詞 $\cdot$自立 $(\mathrm{V})$, その他の単語 (W) という粗い品詞の夕グを用いる。また, 一般名詞意味属性を参照して, 場所（388-532. 数は一般名詞意味属性コードの範囲, 以下同様）の名詞 (NLoc), 場の関係 (2610-2669) の名詞 (NLcr), 抽象的関係 (2422-2515) の名詞 (NRel), 抽象 (1000-2715) の名詞 (NAbs) という品詞のタグを用いることがある.

## 3.1.2 チャンクルール

チャンクルールは大きく 3 種類を設けている。狭いチャンクルール, 広いチャンクルール, および，特殊なチャンクルールである.

狭いチャンクルールは, 名詞連続, 数連続, 「 $\mathrm{N}$ の $\mathrm{N}\rfloor$ 型をまとめるルールである. 広いチャンクルールは，狭いチャンクルールに加えて，動詞, 修飾語句, 数, サ変名詞, その他の単語に名詞が続く場合を名詞としてまとめるルールである．特殊なチャンクルールは, 日時のチャンク (TMG 連続や，「TMGの TMG」型をまとめる)，および，特別な助詞連続をまとめるルールである.

## 3.1.3 アレイ

図 2 におけるサービス別タグ付き文の詳細を構成するアレイについて説明する。形態素解析および意味属性付与の結果は，基礎アレイに記録される。3.1.1 項および 3.1.2 項の辞書・ルー

ルを用いるとタグが得られる。サービスに共有される語句は共有用語句辞書がカバーしており，基礎アレイを参照しながら共有用辞書を用いることで得られる夕グは共有アレイのタグ列に記録される。ここで，共有アレイは基礎アレイを継承している，共有アレイを参照しながら，サー ビス別に定義された辞書やチャンクルールを用いることで得られるタグはサービス別のアレイのタグ列に記録される。

意味列については，辞書・ルールを用いる際に参照したアレイの意味列を引き継ぐ．複数の単語・語句をまとめて 1 つの語句が得られる際は主辞の意味属性を引き継ぐ。なお，発話文は文字単位で管理し，品詞列・意味列・タグ列において対応する文字の範囲を記録している.

## 3.1.4 サービスごとの扱い

一般予約語句は，全てのサービスで共有できる部分を共有の語句辞書として収録し，サービス間で衝突する部分をサービスごとの語句辞書として収録する。例えば，「お気に入り」という語句は，「音楽サービス」においては，「プレイリスト，好きな曲」と同義語であるが，「観光スポット SNS ブラウザサービス」においては, 「ブックマーク」と同義語である.

チャンクルールに関しては，音楽サービス，ビデオサービス，観光ガイドサービス，および観光ブログ紹介サービスでは広いチャンクルールを使用する。曲名などの検索クエリには一定でない品詞列が用いられるためである。 スケジュール管理サービス，および駐車記録サービスでは特殊なチャンクを使用する。日時を正確に捉えるためである。残りのサービスでは狭いチャンクルールを使用する。

サービスへの命令文の複雑さに応じて，語句辞書およびチャンクルールを調整できる．特定のサービスのために調整を行っても，サービスごとに辞書とルールを使い分けることができるため, 他のサービスへの影響が生じない。ゆえに，サービス毎のアレイの使用には，車載器のサービスの改定が容易になるという利点がある。

パージングの解析例を示す。なお，下記のアレイはタグ列を可視化したものである.

例 5 :

発話文：「お気に入りに登録してください」

音楽サービスアレイ：お気に入り/R01003 に/P 登録し/R00080 てください/AReq ブラウザサービスアレイ：お気に入り/R08001 に/P 登録し/R00080 てください/AReq 例 6 :

発話文：「初音ミクの曲をかけてください」

駐車記録サービスアレイ：初音/NAbs ミク/N の/P 曲/R00055を/P かけ/R00056 てください/AReq

音楽サービスアレイ：初音ミク/N の/P 曲/R00055 を/P かけ/R00056 てください/AReq 例 5 において「お気に入り」の語義が区別されていることが分かる．例 6 において「初音」

という抽象名詞が，駐車記録サービスアレイにおいて確認されるが，音楽サービスにおいては粗い品詞で解釈され, かつ, 広いチャンクでまとめられた。

## 3.2 意図解析

意図解析では，実行中のサービスを考慮しながら，発話文に対応する意図クラスを最近傍法で求める。ただし，解の良さは，後段のスロットフィリングの結果にも依存するため，一定の近さにある複数の意図クラスを解候補として出力することにする。また, 継続性も解候補に添える。本節では, 最近傍法用事例の生成, 実行中のサービスを考慮した事例の選択, 近さの計算について順に説明する。

## 3.2.1 最近傍法用事例の生成

最近傍法に用いる事例をコーパスから生成する１万の最近傍法用事例を 1 つの訓練用発話事例から生成する。重複する最近傍法用事例は破棄する。最近傍法用事例は，特徴，意図クラス，および，継続性で構成する，特徴は，モダリティのタグ，予約語句のタグ，および，一般名詞意味属性に関する夕グの集合で定義する。粗い品詞のタグは集合に含めない．意図クラスは識別の目標である，継続性は文脈情報を捉えるためのもので，最近傍法用事例の照合を制限することに用いられる。以下に訓練事例の文のアレイと最近傍法用事例の例を 2 つ示す.

例 7 :

音楽サービスアレイ：音楽/R00055を/P かけ/R00056 てください/AReq

特徴 : \{AReq, R00055, R00056\}

意図クラス：serviceMusic.comPlay()

継続性：new

例 8 :

音楽サービスアレイ：スキップ/R00059 し/R00036 てください/AReq

特徴 : \{AReq, R00036, R00059\}

意図クラス：serviceMusic.comSkip(dir=次)

継続性：cont

集合は，意図クラスのサービス（正解のサービス）に対応したアレイから得る。これらの例では「音楽サービス」のアレイのタグから得た.

## 3.2 .2 文脈情報に依る最近傍法用事例の選択

最近傍法では，一般に入力事例に対して全ての事例と比較を行う。しかし，本稿では実行中のサービスを考慮して選択された事例と比較を行う。これは発話系列の文脈情報の考慮に相当する.
最近傍法用事例の選択は, 実行中のサービスと継続性を参照して行う，発話文の分類（2.2 節） で述べたとおり，実行中のサービスが発話意図を限定しない場合（分類 1,2 ）と限定する場合 （分類 3,4）がある。限定のない場合, 継続性が new である最近傍法用事例は発話文と比較される。継続性が cont である最近傍法用事例は実行中のサービスと最近傍法用事例のサービス （意図クラスを構成するサービス）とが一致すれば発話文と比較される。一方，限定のある場合,分類 3 の状況であれば，特定のサービスと一致するサービスを有する最近傍法用事例が，発話文と比較される。なお，継続性が new である最近傍法用事例であっても特定のサービスと不一致であれば比較されない，分類 4 の状況であれば，サービスに組み込まれた発話文解析となる。 サービスにパージング結果が直接引き渡される。以下に擬似コードを示す。

1：発話文（パージング結果）が入力される.

2：実行中のサービスのリストが入力される.

3：もし, サービスから発話文が予約されているならば,

4： そのサービスに発話文を送り，

5：そうでなければ以下を行う。

6：もし，特定のサービスが予約されているならば,

7：特定のサービスへの最近傍法用事例を比較対象とし，

8： そうでなければ,

9：継続性が new の最近傍法用事例, および,

10：継続性が cont かつ実行中のサービスへの最近傍法用事例を比較対象とする.

11：比較対象となった最近傍法用事例について最近傍法で解候補を作成する.

もしサービス側で分類 3 や分類 4 で発話文の解析を行う予定になっているならば, 解析実行前までに 6 行目や 3 行目の予約がそれぞれ入れられている.

## 3.2.3 発話文と最近傍法用事例の比較

発話文の特徴と最近傍法用事例の特徴を集合演算で比較し, 近さ（一致度）を算出する。発話文の特徴を集合 $U$, 最近傍法用事例の特徴を集合 $T$ とするとき，両者の近さ $d_{1}(U, T)$ を次式で算出する.

$
d_{1}(U, T)=\frac{2|U \cap T|}{|U|+|T|+\beta}
$

ここで， $\beta$ は偏りを持たせるパラメータで $\beta=0.05$ を用いた。近さは, dice 係数を基礎とした. 発話文と最近傍法用事例の間で特徴的な語句が過不足なく一致することを評価するためである. 偏り $\beta$ を持たせた根拠は, 一般の dice 係数としては同じ一致度となる場合でも, 集合のサイズが大きい場合に一致することを重く評価するためである.

## 3.3 スロットフィリング

意図解析からスロットフィリングへの入力はサービス別タグ付き文, および, 解候補（意図クラスと継続性の組のリスト）である。スロットフィリングでは各候補について，スロットフィリングの操作を試みる。その結果として，スロット値を解候補に添えて出力する。

スロットフィリングは，発話文の各語句についてスロットに代入すべきか否かを判定するものである，文頭から文末にかけてスキャンを行い，代入判定を行う．また，発話文中での言い直しがあれば代入したものを棄却することがある（2.1 節，例 4 ）、そこで，スキャン（語句を参照する位置の移動), 代入, 棄却などのアクションを解析状態に応じて適切に実行することでスロットフィリングを行う手法を提案する．実装上はルールベースによるスロットフィリングである。しかし，ルールは強化学習における $Q$ 関数に対応し，コーパスから自動的に獲得する.本節ではスロットフィリングの実行とルールの学習をそれぞれ説明する.

## 3.3.1スロットフィリングの実行

意図解析結果より，想定するサービスおよびメソッドが与えられると，スロットフィリングが始まる。まず，意図クラスおよび継続性の組に対応したルール集を用意する．次に，発話文のパージング結果のうちサービスに対応するアレイを参照する。解析者をエージェントとするが，エージェントが注目する最初の位置を文頭とする。その後，エージェントは観測する状態に応じてルールによるアクションを決定し実行する。解析の終了は, エージェントがアクション actSubmit()を実行した時点, もしくは, アクションの実行回数が上限に達した時点である.上限は文長に比例した回数である.

まず，解析用のアクションを表 3 に示す。 スロットは，メソッドに存在するスロットと一時スロットの 2 種類がある。 エージェントは, 参照する語句を一時スロットに代入し, 一時スロットの内容をメソッドのスロットに移すことができる。文末まで読み進めた後は，解析を終了することや，文頭に戻って読み直しをすることが可能である.

次に，観測される状態の素性を表 4 にまとめる．f1 は注目する語句の意味を表す．f2 は注目

表 3 解析用アクションの一覧

表 4 観測される状態の素性

 & 注目する語句の名詞意味属性を 5 種類に大別したもの. \\

先の周辺のタグの 5-gram である. f3 は注目先の周辺の語句がスロットに代入された状況を表す. f4 は各スロットにおける代入の有無を表す. f5 は一時スロットに代入されている語句の意味を表す. 66 により読み直しが何度も起こらないようにできる．f7 により発話文が訂正を含むかどうかがわかる．f8 は，「〜は〜です」の文体における解析の手助けとなる．ｆ１ から f8を 8 項組にまとめて状態とする.

ルール集は， $Q$ 関数である， $Q$ 関数は， $Q$ : state, action $\mapsto$ score である.つまり，ある状態 state の際にアクション action を選択すると得られるスコアの期待値 score を返す関数である.選択されるアクション $a^{*}$ は高いスコアを導くアクションであり， $Q$ 関数を含む次式で求める.

$
a^{*}=\arg \max _{a \in A} Q(x, a)
$

ここで, $A$ はアクション集合, $a$ はアクション, $x$ は状態である. アクション集合は, 表 3 に示したアクションの集合である．たたし，slot にはメソッドに応じて具体的なスロット名が必要数だけ展開される， $Q$ 関数の学習については次項で説明する.

## 3.3.2 ルールの学習

強化学習では，様々な状態においてアクションを選択することを繰り返し試行し，より高い報酬が得られるように $Q$ 関数を学習する。学習過程で行う $Q$ 関数の更新は動的計画法によるものである. 具体的には, 状態 $x$ で行動 $a$ を試行した結果, 報酬 $r_{n}$ が得られ, 状態が $y$ に遷移したとする。このとき, 状態 $x$ で行動 $a$ を選択することへの評価值 $Q(x, a)$ を次式で更新する.なお， $n$ は学習の時点を表す (Watkins and Dayan 1992).

$
Q_{n}(x, a)=\left(1-\alpha_{n}\right) Q_{n-1}(x, a)+\alpha_{n}\left.\{r_{n}+\gamma \cdot \max _{b \in A} Q_{n-1}(y, b)\right.\}
$

ここで， $\alpha_{n}$ は学習率, $\gamma$ は割引率である. $Q_{n-1}(x, a)$ は更新前の $Q$ 関数を表す. $A$ はアクション集合， $b$ は行動 $a$ の後に予定する行動である. ここでは $b$ は高スコアの期待される行動が仮定されている。なお，本稿では， $Q$ 関数の初期値を $50, \alpha_{n}=0.8, \gamma=0.9$ とした.

報酬の設計を表 5 にまとめる。 スロットフィリングのアクションにおいては，正しいアクションと誤ったアクションを決定論的に定義できる。そこで，アクションの試行時に報酬を与えることが可能である．報酬の值は，アクションの無駄な反復で全体の報酬が高まることのないようにした。例えば，代入と破棄 $(\operatorname{actPush}(), \operatorname{actEmpty}())$ を繰り返すことで報酬の合算値が正にならないようにした。予想を超えてアクションの組み合わせと繰り返しが行われることがあるので，報酬の值は実験的に決定した。

以下に，正例の学習，訂正を含む正例の学習，および，負例の学習を例示する．

正例の学習を例 9 を用いて紹介する.

例 9 :

発話文：<loc>鳥取く/loc>の地図を表示してください

サービス：serviceMap

メソッド：comShow(loc)

継続性：new

表 5 報酬の一覧

*cancel 付き語句を正解とみなす.
意図クラスおよび継続性の組が「serviceMap.comShow（loc）/ new」である.loc夕グで囲ま

発生する．文末まで読み進めた際，「loc=鳥取」という代入状態で完了アクション actSubmit() が行われると，正の報酬が発生する。

訂正を含む正例の学習を例 10 を用いて紹介する.

例 10 :

発話文：<loc cancel>鳥取</loc>の地図じゃなくてくloc>島根く/loc>の地図を表示してください

サービス：serviceMap

メソッド : comShow(loc)

継続性：new

この例も意図クラスと継続性の組が「serviceMap.comShow(loc) / new」であるため, 例 9 で学習された $Q$ 関数に向けて学習が行われる。最初に鳥取を参照中に $\operatorname{actPush}($ )が行われ, その後に actApply(loc) が行われると「loc=鳥取」となる. 文の前半を参照中であれば正しいので，負の報酬は発生しない。文末まで読み進めた時点で「loc=島根」となり actSubmit(）が行われると正の報酬が発生する。しかし，「loc=鳥取」や「loc=鳥取島根」という代入状態であれば actSubmit()の実行に対して負の報酬となる。このように， cancel 属性のある夕グは，代入行動においては正しいが，最終の代入状態では含まれてはならないことを意味する。

負例の学習を例 11 を用いて紹介する（1つの負例は発話文から継続性まで。※印はコメント)、スロットフィリングにおいて代入エラーを抑制するように学習を行うことができる。

例 11 :

発話文：地図を表示してください

サービス : serviceMap

メソッド : comShow(loc)

継続性：new

※ 誤ったスロットフィリング：loc=地図

※ 理想のスロットフィリング：loc=なし

※ 理想のメソッド：comShowHere()

意図解析によると，2つの意図クラス「serviceMap.comShow(loc)」と「serviceMap.comShow $\operatorname{Here}() 」$ は最近傍法用事例の特徴が等しい. スロットフィリングには， 2 つの解候補が届けられる．前者の意図クラスに対応するスロットフィリングを行うと，学習次第では「loc=地図」 という代入結果となることがある。次節で述べる解候補の選択では， スロットへの代入数が多い解候補を選択するようになっている。そのため，誤った代入があると最終的に誤った選択が生じる。ゆえに，誤った代入をしないようにスロットフィリングの学習を行う。本稿ではこれ
表 6 負例コーパス（全文）

を負例の学習と呼んでいる．負例の学習では代入する語句のないことを表す事例を強化学習にかける．すると「loc=地図」という状態を導くアクション系列は負の報酬によりスコアが低く学習される. 負例の学習データを用いた強化学習の実行方法は特別な操作はない. ゆえに, 負例の発見さえできれば，負例の学習は容易である。なお，自明であるが，負例用コーパスからは意図解析のための最近傍法用事例の生成を行ってはならない.

負例を発見する方法は，実験的な方法である。すなわち，クローズドテストでの誤り分析において，スロットに誤った代入が見られた事例に注目する。筆者らの経験では，コーパスや語句辞書に誤りがあるために学習や解析に失敗することが多かった. 次には, 強化学習において観測する状態の定義が不十分であることが失敗の原因であることがあった. コーパス・語句辞書・状態定義が十分であるが，過剰なスロットフィリングによる失敗が生じる場合に，その失敗する事例を負例コーパスに追加する。なお，誤り分析が不十分なまま，誤り事例を負例コー パスに追加してはいけない.コーパス・語句辞書・観測状態の定義における問題が検出できなくなり，本質的な問題が解決できなくなるからである.

負例コーパスを表 6 に示す. \#2では, 先の説明 $(\# 1)$ と同様にメソッド引数全てへの代入を抑制した。 $\# 3$ では，一部のメソッド引数 locへの代入を抑制した.

## 3.4 解候補からの選択

解候補からの選択では，意図解析における夕グの一致率，および，スロットフィリングにおけるスロットの代入率を参照する．多くの一致数や代入数となる解候補を優先するために，解候補を次式で評価する。

$
d_{2}(U, T, b, s)=\frac{2|U \cap T|+b}{|U|+|T|+s+\beta}
$

ここで，Uは発話文における夕グの集合， $T$ は意図解析において適合した最近傍法用事例におけるタグの集合， $s$ はスロットフィリングにおいて代入されるべきスロットの数， $b$ はスロットフィリングにおいて代入されたスロットの数である。ただし，デフォルト値を有するスロットはスロット数 $s$ および $b$ ともに含めない. $\beta$ は偏りのパラメータであり 0.05 とした.

解候補の中から，最も高い評価値を有する候補を選択する。ただ，同率で 1 位となる候補

が複数存在する場合は, 継続性が cont となるものを優先する.

## 4 応用事例および性能評価

自動車旅行を支援する車載器を Raspberry Pi 3 上に実装した。そこでの発話文解析に提案手法を適用し，解析性能を示す。

## 4.1 車載器の構成

車載器は小型計算機 Raspberry Pi 3 Model B（2016 年製, CPU: ARM $1.2 \mathrm{GHz} 4$ cores, 主記憶：1 GB）である ${ }^{2}$. Ruby を用いてサービスおよび発話文解析を実装した. 周辺デバイスとしてスマートフォン (Android 8.0), スマートウォッチ (Android 5.1) およびカー・オーディオビジュアルを用いる（図 3)，スマートフォンは $\mathrm{WiFi}$ ルータおよび GPS レシーバとして用いる. スマートウォッチは音声認識デバイスとして用いる ${ }^{3}$. 認識結果（文字列）は WiFi 経由で車載器に送られる，スマートフォンのみを用いることは可能であるが，スマートウォッチによる音声認識の方が口元で音声を集音するため車内では使いやすい（図 4). スマートウォッチによ

(a) 車載器一式

(b) 設置例

図 3 機材の様子. 図 3(a) 上側の機材は, $\mathrm{AV}$ ケーブル, シガーソケット電源. 下側の機材は, スマートフォン，USBメモリと音源ボードを装着した Raspberry Pi 3 Model B，スマートウォッチ，テンキー，収納ケース，図 3(b) コンソールにテンキーを設置。車載器本体をケースに入れて助手席シー トの真下に設置. 電源をスマートフォンと本体に供給.


図 4 使用の様子，スマートウォッチに話し掛けて命令、ステアリングを握ったままでも良いが， 口元に左手を近づけて発話すると高い可能性で命令できる.

る音声認識は走行中であっても十分である。逆に，スマートウォッチのみを用いることも可能であるが，終日のドライブにおいてはバッテリーが不足する恐れがある（スマートウォッチは充電しながらの使用が難しい)，車載器のサービスはカー・オーディオビジュアルにより表出する. なお, 補助としてテンキーによる操作も可能である.

スマートウォッチでの使用の様子を説明する。通常時でのスマートウォッチへの操作は最小で 1 タッチ，最大で 2 タッチである，具体的には，スリープ中は電源ボタンへのタッチ，および，スクリーンへのタッチにより音声認識が始まる。「ですます調」で発話を行った場合は語尾により発話文の終了が確定される。それ以外の調子で発話をした場合は「どうぞ」と言うことで発話文の終了が確定される。発話の途中で「取消」と言うと，始めから発話し直すことができる.

車載器は, 2016 年 5 月より走行時に利用しており 2018 年 12 月までの約 2 万キロの走行の間, 各種サービスの提供を行ってきた。初期は USB ヘッドセット型マイクを備え，音声認識のオープンソフトウエアを利用していた。 2017 年 8 月より Android の音声認識を利用するように変更した，安全性の懸念から開発者によるクローズドテストが繰り返し行われ，慣れた利用者においては発話文解析は十分な性能となった。また, サービスの種類を徐々に増やしてきたが，コーパスおよび語句辞書の単純な追加・変更により発話文解析の増強ができた．図 5 に車載器の実行の様子を示す。以下では, クローズドテストの性能および新たな利用者における解析性能を示す.

(a) センターディスプレイへの表示例

(b) 別車種での表示例

図 5 車載器の表示例. 図 5(a) ではカーオーディオビジュアルのセンターディスプレイを使用. Wikipedia の鳥取砂丘の記事を読み上げている場面. 図 5(a) ではレーダー探知機をモニタとして使用.観光スポット SNS サイトをブラウズして大山滝を提示している場面. 背景画像および情報は https://minkara.carview.co.jp/userid/309487/spot/800570/をブラウズした結果である（2018 年 9 月 13 日時点).

## 4.2 性能評価

学習用コーパスは正例コーパスが 2,147 文, 負例コーパスが 3 文である。意図クラスは 181 種類となった. 意図解析のための最近傍法用事例は 890 件となった. ルールベース（ $Q$ 関数） は，「意図クラスおよび継続性」の組ごとに作られ，191 件となった。総ルール数 $(Q$ 関数での状態・アクションとスコアの対の総数）は 173,864 件となり 1 ルールベースあたり平均 910 件 （最小は 32 件, 最大は 20,917 件）となった. ルールベースの実装にはデータベース GDBM を用いた。合計約 $26 \mathrm{MB}$ となた。

正例コーパスのパージングは約 71 秒であった. 1 回目の学習では正例コーパスを用いて最近傍法用事例の生成と強化学習を行った。約 9 分 43 秒かかった. 主記憶の使用量は約 $70 \mathrm{MB}$ であった. 2 回目の学習では負例コーパスを用いて強化学習を行った (約 20 秒). 3 回目の学習では正例コーパスを用いて強化学習を再度行った（約 8 分 26 秒）.

ここで，コーパスを用いた強化学習では，「意図クラスおよび継続性」の組の一致する文をグループ化して, グループ内の文が全て解析できるまで学習を行った. グループ内での全文の学習とテストを繰り返すが, 最大 30 回を限度とした. 文の学習では, アクション系列の試行を 15 回 (のべ 15 文) 行った. アクション系列は最長で文長の 4 倍（語句単位）までとした. 1 アクションごとに $Q$ 関数を更新した.

クローズドテストによると, 正解率は $0.995 （ 2,136$ 文成功 $/ 2,147$ 文入力）となった. ここで,出力された意図クラスおよびスロット値が正解の值と完全一致したものを成功とした。ユーザ

に約束する発話文が確実に解析できることが確認できた.

主な誤り事例は以下のとおりである。

例 12 :

発話文：「詳しい観光ガイドをしてください」

出力： serviceGuide.comGuideInDetail() / cont

正解： serviceGuide.comGuideAll() / new

例 13 :

発話文：「レーダーに道の駅を表示してくたさい」

出力： serviceRadar.comSearchTarget (obj=道の駅) / new

正解： serviceRadar.comSelectLandmark(obj=道の駅) / new

例 14 :

発話文：「馬の背を見ます」

正解： serviceScheduler.comInformEvent（msg=馬の背を見）／cont

例 12 , 例 13 は, サービスを操作する台詞がそもそも曖昧であるため発話文解析が誤りとなっている。例 14 において, loc は移動先を対応させる仕様であるので，「馬の背」だけをみると観光スポット名であり場所を表す名詞であるため代入可能に思えるが，「馬の背を見」までみると観測の対象であり必ずしも移動先とはいえないため誤りである．動詞の結合価を解析していないため誤りが生じた.

スケジュールサービスや駐車記録サービスではユーザの体験を表す発話文を解析することが多い. ユーザの体験談に対しては，サービス用の予約語句が対応しないため，粗い品詞夕グの列における発話文解析となる。特徴的でないため解析に失敗しやすい。すなわち, 自由発話に対しては本手法は改善の余地がある。サービスを表さない単語を解析することは今後の課題とする。

## 4.3 追加学習

車載器の操作中に発話文が認識されないことがある。車載器に備わる命令文と同じ意味だが言い方が異なる場合，および，用語が不足する場合については，それぞれ追加学習が可能である。追加学習はユーザが学習を要求する発話を行うことで, 対話的に進められる.

## 4.3.1 命令文の学習

新しい命令文と既知の命令文を指定することで，命令文の学習を行うことができる．以下にその様子を示す。
例 15 ：

（音楽サービスを実行中）

1 ユーザ：「曲は前のにしてください」

車載器 (エラーを表示)

2 ユーザ：「発話文を学習してください」

車載器（曲は前のにしてください，を表示）

3 車載器 : 「別の言い方をしてください」

4 ユーザ：「前の曲にしてくたささい」

車載器 (serviceMusic.comSelect(dir) / cont, dir=前, と認識し表示)

車載器（曲は<dir>前</dir>のにしてください，を表示）

車載器 (未知の用語なし, を表示)

5 車載器：「これで良いですか」

6 ユーザ :「はい構いません」

車載器 (学習を実行)

7 車載器：「学習しました」

こうして, 最近傍法用事例の追加および強化学習によるルールベースの学習が行われた。この例での学習の実行時間は約 2 秒である.

## 4.3.2 語句の学習

新しい語句と既存の語句を指定することで，語句辞書への登録が可能である．以下にその様子を示す.

例 16 :

1 ユーザ : 「単語を学習してください」

2 車載器 : 「新しい語句は何ですか」

3 ユーザ：「楽曲です」

4 車載器 : 「類似する既存の語句は何ですか」

5 ユーザ：「音楽です」

車載器 (new：楽曲, org: 音楽, サービス: 全般, を表示)

6 車載器 : 「これで良いですか」

7 ユーザ :「構いません」

車載器 (語句辞書に「楽曲」を登録)

8 車載器 : 「語句を登録しました」

語句辞書への登録により「楽曲」が「一般的な単語」から「予約語句」になった。すなわち,語句辞書において「音楽/ミュージック」というグループから「音楽/ミュージック/楽曲」とい

うグループになった.

以上の通り, 命令文の言い方の違いや用語の不足に対して追加を容易に行うことができた.

## 4.4 オープンテスト

発話で車載器を操作することについてオープンテストを行う。被験者には車載器のサービス内容を理解しておいてもらい，非走行の状態で発話で操作を行ってもらう．被験者は大学生 4 名である．被験者は一人ずつ操作を行う．被験者間で操作内容がほぼ同一となるように，シナリオに沿った操作を依頼した。シナリオは，車載器の利用者の心境を「音楽を聴こうと思います」などのように記述したものである。サービスの主要な操作を網羅している。

被験者の発話のうち, 音声認識エラーとなった発話 (28 文), 文法が大きく誤っている発話 (3 文)，スマートウォッチの操作ミスを伴う発話（1文), 存在しないサービスへの発話（13文）の合計 45 文については無効な発話文とした。無効な発話文は, 総文数の $15 \%$ (45/301) という割合で存在した．音声認識エラーにおいて，地名が誤り易かった．被験者側の問題としては，発する単語が間延びしたことが挙げられる。これは，発話中に音声認識にタイムアウトが発生する原因である。この不明瞭な発話は, 被験者がサービス内容（機能・名称）を熟知しておらず，言葉を考えながら発話する際に見られた。ゆえに，ユーザが言い慣れた発話文を追加的に学習する機能により，無効な発話文が減少する可能性がある.

有効な発話文については，成功文と失敗文に分けた。成功文は，サービス，メソッド，スロッ卜値が正しく解析できた文である。成功文数 $S$, 失敗文数 $F$ を含む次式により解析性能を精度 $A$ で評価する。

$
A=\frac{S}{S+F}
$

実験結果を表 7 に示す。発話文の解析が失敗となった際，別の言い方で発話をしてもらい， シナリオを進めた．被験者からの感想によると，サービス名や操作の言い方を考えることに手間取ったという。もし取扱説明書を読んでおき, 主要な用語を覚えていれば, より円滑に命令

表 7 オープンテストの結果

を発話できたことと思われる。シナリオを達成することができたことより, 全体の精度が 0.81 とは本稿の場合では支障のない水準であると解釈した.

失敗文を分析した結果を表 8 に示す。命令文の網羅性が不足すること，語句の網羅性が不足することが主な解析誤りの原因である，前者は，格要素の順序の違い，「は」と「を」の使い分けについて網羅性が不足した。スロットフィリングのために用いた強化学習では，人の目でみて僅かな違いの状態同士であったとしても，全く異なる状態として扱うため，訓練用コーパスにおいては格要素の順序や助詞の種類について網羅的に用意する必要がある. 非命令文による命令とは，ユーザが主語となる操作に見られる意図の表現である。「ブラウザを使いたい」という心境がシナリオに示されたことに対して，「ブラウザを使います」という宣言を車載器に伝えることで「ブラウザの起動」を被験者は狙った。ゆえに，今後，命令文のコーパスを構築する際，コーパスの基本的な網羅性を高めるために，ユーザを主語にする言い方と，システムを主語にする言い方の両方を想定するべきである.

語句や発話文の網羅性を解消するために，学習サービスが車載器に備わっている．格要素の順序や助詞の違いによる失敗は学習できる。例えば，「この旅館を説明してくたさい」は既に受理可能であり，「説明する」と「教える」が同義として語句辞書に登録されているので，「を」を使う事例の他に「について」を使う事例として「この旅館について教えてください」を学習することが可能である。「（音楽を）始める」が音楽サービスにおいて「再生する」と同義であることを語句の登録として実行できる。車載器のユーザは，自分の慣れた言い方を学習させることができる.

本実験において学習の可能な事例は， 37 件であった．語句や発話文の追加学習の効果を表 9 に示す. 以上により，本稿の提案手法はサービスの実行を命令する上で十分な性能を有することが確認できた，たたし，車載器に必ず受理される言い方や語句をユーザが確実に発話する必要がある。実利用においては追加的な学習が不確実である。追加的な学習を確実に行う仕組みについては今後の課題である.

表 8 失敗文の分類

表 9 学習可能性の評価結果

## 4.5 比較実験

意図解析およびスロットフィリングにおいて一般的な方法と比較を行う。一般的な方法は,識別器および素性に関して幾つかの組み合わせがある。識別器には，サポートベクトルマシン (SVM)，ロジスティック回帰（ここではLR と略す），ニューラルネットワーク（ここでは NN1， NN2 と略す), 条件付き確率場 (CRF) を挙げる。素性には, 単語のみ, 単語および品詞の n-gram を挙げる。ここで, 提案手法は学習器が最近傍法および強化学習であり, 素性はサービス別アレイを参照して得られるタグの n-gram である。ゆえに，比較のため SVM/CRF においてもサー ビス別アレイを参照する実験を行う。

評価の観点は, 4.4 節の精度 $A$ だけでなく, 小型計算機での実行可能性も含める. 小型計算機は, サービスの提供が主目的である。言語処理のための学習と解析に CPU および主記憶を多く使用することは望まない。具体的には，Raspberry Pi 3 を想定し， CPU が $1.2 \mathrm{GHz} 4$ cores,主記憶が 1 GB というハードウエア上での動作を要求する。サービスのために CPU 2 cores,主記憶を $300 \mathrm{MB}$ 使用する。ビデオ RAM および共有メモリ用に $600 \mathrm{MB}$ を使用する。ゆえに，言語処理には CPU を 2 cores，主記憶を $100 \mathrm{MB}$ を使用することを想定する.

比較手法においては，実装すると実行条件が充足できないものがある。一般的な計算機として CPU が Intel Core i5, 3.3 GHz, 4 cores, 主記憶が 16 GB のものを用いる.

クローズドテストを通じて，精度，使用する主記憶，および，学習時間を比較する。オープンテストを通じて精度を比較する。

クローズドテストにおける比較結果を表 10 に示す. NN1 および NN2 は, Python, Tensorflow， Keras をバックボーンとし, Embedding + LSTM + MultiDenseLayers という構成とした. NN1 では Dense 層を 2 つ, NN2 では Dense 層を 3 つとした。語彙数の上限を 1,024 , 最大文長を 20 , バッチサイズを 32 , エポック数を 1,600 とした. LR は, Python, scikit-learn をバックボーンとした. SVM は TinySVM を使用し one-vs-rest を行った. ここで正例と負例に同一のべクトルが与えられ得る際は正例のみを与えた． CRF は CRF++を使用し CPU の割当てを 2 cores に制限した上で $\mathrm{CRF}++$ のサンプルにあるテンプレートを利用した。なお， $\mathrm{NN} 1, \mathrm{NN} 2$ および LR は学習時間および主記憶を多く要するため小型計算機による実行を行っていない。意図解析とスロットフィリングの両方を解析することも, 小型計算機で実行可能な手法のみを示した.

意図解析では曖昧性の問題で精度が 1.0 にはならなかった. NN1, LR および SVM において
表 10 クローズドテストにおける比較結果

} & \multicolumn{2}{|c|}{ 学習時間 } \\

※テスト文数は 2,147 文.

SVM の精度が低い．SVM では単語や品詞の重要度が学習されないためである。サービス別の素性では重要な語句のみがべクトル化されるため改善したと解釈する．提案手法での最近傍法も 1-best では SVM と同程度の精度であるかもしれないが, 複数候補を残し，スロットフィリングの結果を用いて総合的に選択を行うため精度が高いと解釈する。スロットフィリングにおいては，例えば，都道府県名を<loc>とする場合と<pref>とする場合があるため精度が 1.0 にはならなかった．意図とスロットの両方を正しく解析することを評価したところ，提案手法の精度が良いことを確認できた。素性をサービス別に用意することも有効であることが確認できた。

オープンテストにおける比較結果を表 11 に示す. NN1 および NN2 は単語の網羅性による問題が大きい．多様な表現を含むコーパスからの学習や，外部リソースによる Embedding 層の学習を行えば改善すると思われる（本実験は簡易実装により実行可能性を調べた実験である。一般でのニューラルネットによる手法を否定するものではない)．LR は一般的な識別器において性能が良かった． CRF はスロットフィリングに有効であることが確認できた． CRF によるスロットフィリングでは素性による精度の差が小さかった。意図とスロットの両方を解析する際は意図の識別性能の低さのため精度が悪くなった。提案手法はいずれにおいても相対的に良い精度であった。

一般的な方法を用いるとすれば，主記憶の使用量からみると SVM+CRF があげられる。しかし，本稿では言い回しの違いを追加的に学習するため, CRF の使用はできない. 数事例の追加であっても全事例を用いた再学習が発生することがデメリットである。ただし, 追加的な学習を不要とするならば CRF の使用は否定されるものではない。一方，提案手法では追加する
表 11 オープンテストにおける比較結果

※テスト文数は 256 文.

事例のぶんだけ強化学習を実行すればよいためこのデメリットがない 4.

## 5 考察

本章では，まず，語句辞書の設計はサービスの設計とともにあるため手動による基礎の構築は必然であることを述べる．次に，定型的な発話文を受理する予定であってもパターンベースの解析手法では柔軟性に欠けるため採用しなかったことを述べる。最後に, 強化学習ではコー パスの正確性が要求されることを述べる.

## 5.1 語句辞書の設計

一般の自然言語処理では，言語解析結果を利用する側の情報を解析の段階に持ち込まない.すなわち, 言語解析のモジュール性が高い. しかし, 本稿では, サービスと発話文解析のモジュー ルの関係が強いことを前提とする。とりわけ，語句辞書は，サービスを設計すると同時に設計される必要がある，本節では，語句辞書の設計について述べる.

語句の種類には，サービスや機能を表す語句や，操作量を表す語句があることを述べた。サー ビスの実行のための発話文では, これらの語句が含まれるはずである，例外は，ユーザの体験談や行動予定を車載器に述べる場合，および，音楽や観光地などを検索するクエリのみを発話する場合である。サービスを設計する際，サービス名，メソッド名，操作量を表す語句を必ず設
^{4}$ ただし，検証のため同一の $Q$ 関数を用いる事例をテストすることが望ましいが，それを行ったとしても，本実験における識別器の中では最小の時間で学習できる。
}
計する。語句辞書の作成はその過程で生じるため負担ではない。他のサービスと語句のグルー プが競合する場合でも，サービスごとに語句辞書を構築するため，競合に配慮しやすい.

サービス間で共通とする語句辞書を認めている。その場合, 車載器の全体のバージョンアップがあり，サービスの追加がある際は注意が必要である．新たに追加されるサービスが，共通の語句を特別な意味で使うものであれば，共通語句辞書からその語句を外す必要がある．既存のサービスのうちその語句を用いているならば，そのサービス用の語句辞書にこれまでのその語句の定義を移動する必要がある。

## 5.2 パターンベース手法との比較

サービスが確定して命令文が確定したならば，発話文の解析方法として文型パターンを用いる方法が挙げられる。本稿で，文型パターンを用いなかった理由を述べる。

文型パターンは，字面，変数，演算子等で構成することがある．大規模なパターン辞書を構築した鳥バンクでは，文の意味を捕まえるためにこれらの記述子が用いられた (池原，阿部，徳久，村上 2004). 文型パターンには次の弱点があるため, 本稿では用いなかった.

・ 発話文の事例から文型パターンを自動的に生成することが難しい

・ 変数や記号が対応する語句を定義することが難しい

・ 文型パターンの一部の特徴を利用することができない

発話文の事例から，変数化する部分を決めることは， スロットの対応する部分を決めることと等価であり，スロット名の夕グ付き文を利用することで実現できる，しかし，文型パターンには，文とパターンの照合が柔軟に行えるように，語順の入れ替え可能な箇所，任意に修飾表現を插入できる箇所を示す記号を組み込む必要がある。また, さらに，名詞句の変数や地名を表す変数が導入されたとして，その変数に適合する条件を定義する必要がある．任意に修飾表現を挿入できる箇所を示す記号においても同様に定義を与える必要がある。それらの定義は, サービスごとに異なるものであるが, 発話文の事例集が改訂されるごとに見直しが必要である.文型パターンは 1 文の構造を表すのだが，語句の合成の仕方が複数通り存在し，そうした合成の仕方が複数種類の組み合わせで 1 文が構成されるとき，組み合わせ数が膨大になる．例えば，「場所+に/へ」の言い方と「時間＋に/まで/より/から」の言い方が組み合わさるとき, 16 通りになる，助詞の組み合わせと，格要素の入れ替えを記号で表すことで 1 通りの記述に抑えられているが, そのためには手動での分析が必要となる.

本稿の強化学習では, 語句へのタグの 5-gram を参照した状態認識を行っている，字面の 5gram を参照するのでは状態数が多すぎるので，夕グの 5 -gram としている（たたし助詞は字面と対応したタグ)。これにより，スロットに代入可能な部分の定義や, 助詞の組み合わせ方について強化学習において学習される。なお, チャンキングを簡単なルールで行っているが, その結果に応じて強化学習が文の部分構造（パターン手法でいうところの変数定義）を学習するた

め，チャンクルールの性能はあまり重要ではない。また， $Q$ 関数をサービスごとに使い分けている。そのためサービスに応じた文の部分構造が学習される。

## 5.3 強化学習を用いる上での難しい点

強化学習は，マルコフ決定過程に基づく判定を行っている。ゆえに，必ず解があり十分な状態の定義と十分な試行が行われるのであれば，学習は収束し，解析も正しい，学習用の発話文コーパスにおいて，スロットの対応箇所を表すタグの付与が一貫していれば正しく学習と解析が行われる。しかし，コーパスにおいて矛盾する箇所が 1 つでもあれば学習が収束せず，解析時にも誤りが生じやすくなる，例えば，「地図を<io>拡大</io>してください」とする事例と「鳥取の地図をくio>拡大し</io>てください」とする事例が混ざっている場合，io夕グの範囲に矛盾があるため，正しく学習されない，コーパスを正確に作成する必要がある.

追加学習において，ユーザがスロットの対応箇所を指定するならば，学習に失敗する恐れが生じる，本稿では，受理された類似文を用いるため，スロットの対応箇所は文字列レベルで一致するようにした。これによりユーザによる誤った学習事例の使用を低減した.

しかし，誤った学習をした場合，そこから回復させる直接的な方法がない．正しい事例の学習を再度行うことで回復が可能だが, 強化学習での試行回数が多くなる場合は学習時間を要し,主たるサービスの実行に支障の生じる恐れがある.

## 6 おわりに

本稿では，小型計算機における多様なサービスを発話で操作することを目標として，発話文の解析と学習の手法を示した.

小型計算機は，自動車旅行を支援する車載器であり，そこでの 163 種のサービスとその多様な操作を行うために発話文解析を必要とした。操作のための基礎の発話文が必ず受理され，かつ, 異なる発話文の受理も可能であること, さらにこれらのための言語解析と学習を低い計算コストで行うことが要件にあった.

本手法の解析は, サービスに依存した品詞・語義・チャンクの解析, 発話意図解析, および, スロットフィリングを行うものである。発話文への品詞や語義などの夕グ付与をサービスの種類ごとに実施し，それぞれのパージングのアレイに結果を格納することとした．語義やチャンクの曖昧性解消がサービスに合わせて行われた。文脈情報として実行中のサービスを参照したところ，サービスに応じた語句の情報を得ることができ，最近傍法による発話意図の解候補を限定することができた．強化学習による $Q$ 関数をルールベースとし，ルールベースによるスロットフィリングを実現した， $Q$ 関数の参照する状態には夕グ n-gram やスロットの代入状況などを含めた。意図解析の解候補についてスロットフィリングを実行し，意図解析とスロット

フィリングにおいて同時に望ましい解析結果となるものを発話文解析結果として選択した。一方，学習に関しては，サービスの設計時に，語句辞書やチャンクルール，および，規定となる命令の発話文セット（コーパス）が定まることとした。意図解析のための最近傍法用事例の生成，および，スロットフィリングのためのルールベース（ $Q$ 関数）は車載器のサービスの開始以前にコーパスから学習した。主たるサービスの実行時においても，同義・同類の語句の追加, および，既存の発話意図と同義で新しい言い回しの発話文の追加を可能とした.

評価実験において，発話文の解析精度は，クローズドテストにおいて 0.99 およびオープンテストにおいて 0.81 という結果がそれぞれ得られた。小型計算機において，主たるサービスの実行を妨げること無く，発話文の解析と学習をスタンドアロンで行うことが可能であることを確認した。サービスと言語処理の結び付きが強い中で，車載器におけるサービスの増強に対して，本手法はコーパスと語句辞書への単純な追加・修正で対応できた.

以上のとおり，既存の研究において発話文解析に有効とされる要素を踏襲しながら，サービスに向けたパージングのアレイおよび強化学習によるスロットフィリングを解析手法に導入した本手法は，小型計算機における応用システムにおいて有効であることが確認された。

## 謝 辞

本研究は JSPS 科研費 JP19K12548 の助成を受けたものです.

## 参考文献

Bunt, H., Petukhova, V., Traum, D., and Alexandersson, J. (2017). "Dialogue Act Annotation with the ISO 24617-2 Standard." In Multimodal Interaction with W3C Standards: Toward Natural User Interfaces to Everything, pp. 109-135.

福岡知隆, 白井清昭 (2017). 対話行為に固有の特徴を考慮した自由対話システムにおける対話行為推定. 自然言語処理, 24 (4), pp. 523-546.

池原悟, 宮崎正弘, 白井諭, 横尾昭男, 中岩浩巳, 小倉健太郎, 大山芳史, 林良彦 (1997). 日本語語彙大系. 岩波書店.

池原悟, 阿部さつき, 徳久雅人, 村上仁一 (2004). 非線形な表現構造に着目した重文と複文の日英文型パターン化. 自然言語処理, 11 (3), pp. 69-95.

工藤拓, 山本薰, 松本裕治 (2004). Conditional Random Fields を用いた日本語形態素解析. 情報処理学会研究報告自然言語処理 (NL), 2004 (47), pp. 89-96.

Liu, B. and Lane, I. (2016). "Joint Online Spoken Language Understanding and Language Modeling with Recurrent Neural Networks." In the SIGDIAL 2016 Conference, pp. 22-30.

Liu, B. and Lane, I. (2018). "End-to-End Learning of Task-Oriented Dialogs." In NAACL-HLT 2018, Student Research Workshop, pp. 67-73.

長井敦，呉剣明，加藤恒夫，山本誠一 (2018). Attention-based RNN model を用いた日本語モジュールの意図クラス推定とスロットフィリングにおける未知語対策. 言語処理学会第 24 回年次大会発表論文集, pp. 1054-1057.

Raymond, C. and Riccardi, G. (2007). "Generative and Discriminative Algorithms for Spoken Language Understanding." In INTERSPEECH 2007, pp. 1605-1608.

Watkins, C. and Dayan, P. (1992). "Q-Learning." Machine Learning, 8, pp. 279-292.

Williams, J. D. and Young, S. (2007). "Partially Observable Markov Decision Processes for Spoken Dialog Systems." Computer Speech and Language, 21, pp. 393-422.

## 付録

## A. オープンテストにおけるシナリオ

ノートパソコンにプレゼンテーションソフトの画面を表示し, シナリオを被験者に提示した.下記の通番は，被験者に提示する 1 画面ぶんの情報である。音楽，地図などの見出し（下線部） も提示した。なお，シナリオ中盤の (13) は，運転手が行うべきでない操作である．実験の緊張をほぐす目的で状況を設定した。

(1) 実験準備
- 心境を指定するので口頭で命令してください.
- 車載器に命令するときの口調

「ですます」調. 〜してください

音楽

(2) 音楽を聞こうと思います.

(3) 駐車場の人と話をするところです。音楽をとめようと思います.

(4) 再び音楽を聞こうと思います.

(5)この曲に飽きました。別の曲を聞こうと思います.

地図

（6）国道 29 号線を走っています。青い標識を見て，右折した先が気になりました.

※ 実験時には写真を掲載. 写真 : 右折先は国道 429 号線, 朝来方面.

(7) 地図の字が小さくて読めません.

(8) 北の方を見たいと思います.

観光レーダ

(9) 退屈です. 観光地がないかレーダを見たいです.

(10)とりあえず何かガイドをしてもらいたいです.

(11) 鳥取砂丘に着く前に Wikipedia で調べようと思います.

(12) ガイドをとめたいと思います.

ビデオ

(13) 高速道路にのりました. 中国自動車道はガラガラなのでビデオをみようと思います.

(14) 別のものを見ようと思います.

(15) ビデオをやめます.

ブログ

(16) ブログの話を聞こうと思います.

(17) ブログの話はやめます.

駐車記録

(18) 記録を残します.
- 見た物，食べたもの，行ったところ
- 楽しい，つまらない
- 「以上です」で終了

天気

(19) 今日の天気が気になります。天気図を見ようと思います.

(20) 降水状況が心配です.

(21) 岡山の天気を調べようと思います.

観光スポット・ブラウザ

(22) 観光スポットを調べるためにブラウザを使いたいと思います.

(23) ラーメン屋の記事を読みたいと思います.

(24) 場所を知りたいです.

スケジュール

(25) 予定をたてようと思います.
- 18 時にラーメン屋に行きます.
- その前にイオンに行きます
- やっぱり，順番を変えます.
- 「以上です」で終了

シャットダウン

（26）車を駐車しようと思います。シャットダウンをします.

## 略歴

徳久雅人：1995 年九州工業大学大学院情報工学研究科博士前期課程修了. 1995 年九州工業大学情報工学部助手. 2002 年鳥取大学工学部助手. 2010 年 2 月より鳥取大学工学部講師. 博士 (工学). 自然言語処理を応用した観光情報処理の研究に従事.

木村周平：1998 年京都大学大学院工学研究科修士課程修了. 2001 年東京工業大学大学院総合理工学研究科博士後期課程修了. 2001 年 4 月理化学研究所ゲノム科学総合研究センター研究員. 2004 年 10 月鳥取大学工学部准教授（助教授)。2014 年 1 月より鳥取大学工学部教授. 博士 (工学)。進化計算, バイオインフォマティクスなどの研究に従事.

(2018 年 12 月 19 日受付 $)$
$(2019$ 年 4 月 5 日 $\quad$ 再受付 $)$
$(2019$ 年 5 月 22 日採録)