言語処理学会 第24回年次大会 発表論文集 (2018年3月)

多言語音声コーパスの人−機械品質検査手法
水上 悦雄

榎本 成悟

テオリン アクセル エリック

加藤 宏明

河井 恒

情報通信研究機構 先進的音声翻訳研究開発推進センター
先進的音声技術研究室{etsuo.mizukami,seigo.enomoto,axel.theorin}@.nict.go.jp{kato.hiroaki,hisashi.kawai}@.nict.go.jp

1

はじめに目標とし、そのために必要な音声コーパスを構築している。

機械学習による統計的なモデル構築手法が主流である音声認識・機械翻訳・音声合成技術において大規模なコーパスの存在が重要であることは論を待た2.1

ない。特に複数言語間の音声翻訳（Speech-To-SpeechTranslation）技術においては、多言語の大規模音声コーパス、テキストコーパスが必要となるため、一つの研究機関が自前で収録、書き起こし、テキスト作成からコーパス構築までを一貫して実施することは困難である。特に我々日本の研究機関においては日本語以外の他言語のコーパスの構築には、外注やクラウドサービスを用いて音声収録や書き起こしの業務を担ってもらうことが現実的な解となる。そこで問題となるのは、如何にその品質を保つかである。近年、クラウドソーシングを用いたデータ構築の際の品質担保のための様々な手法が検討されているが [1]、実際の大規模データを如何に検査するかは言語の壁の問題もあり、容易ではない。本稿では情報通信研究機構（以降、NICT と記述）が大規模多言語音声コーパスを構築するために用いている検査手法、構築上の課題や対策について述べる。

2

NICT 多言語音声コーパス
2014 年に総務省が掲げたグローバルコミュニケーション計画（以降、GCP と記述）に基づき、NICT でコーパス設計

音声コーパスは、その目的に依存して、大きく分けて、ドメイン（ジャンル）、話者属性、発話スタイル、音響環境の四要素を如何に適応的かつバランスよく収集するかがポイントとなる。また、音声コーパスは、音響モデル学習のために用いる1 ため、当該言語で発話され得る、多様な人による、多様な音素のパターンが、しかるべき頻度で出現する必要があるが、有限のコーパスでそれを網羅することは難しい。そのため、ある程度目的や対象を絞ってコーパスも収集することが現実的となる。

NICT が目指しているのは、訪日外国人が日本国内で旅行や生活をする際に、母語で、日本人接遇者とコミュニケーションする、あるいは、邦人が海外に赴いた際に、日本語で同様にコミュニケーションすることを支援するための音声翻訳技術である。そのため、話される内容は、観光や生活に関係することを主とし、発話のスタイルはどちらかと言えば、初対面の人同士で話される程度の、フランク過ぎず、機械へのコマンド入力でもないような発話スタイルを想定している。

2.1.1

模擬会話/独話/発話ログ

は東京オリンピックを見据えた言語の壁を超えるためそのため、開発当初の設計では、買物場面、病院窓の音声翻訳技術の研究開発を推進している。訪日イン

口、公共機関窓口、災害場面、チケット購入および公バウンド対象国、日本からのアウトバウンド対象国の共交通機関窓口での会話を想定して、客と接客者、患公用語に鑑み、2020 年までに、日本語、英語、中国語、者と病院関係者、申請者と公共機関窓口担当者のよう韓国語、タイ語、ベトナム語、インドネシア語、ミャンマー語、フランス語、スペイン語（以降、GCP10 言語と記述）の実用レベルの相互音声翻訳技術の実現を

1 書き起こしテキストは言語モデル学習にも用いるが、それだけでは十分ではないので、Web 等から収集したより大規模なテキストコーパスをベースとするのが一般的である。

― 817 ―

Copyright(C) 2018 The Association for Natural Language Processing.
All Rights Reserved.

な二者間の一連の会話を模した「模擬会話」を様々なグ」）を書き起こして、学習データに用いることがで状況を想定して収録するという形をとった。実際の場きれば、より現場音声に強い音声認識モデルを構築す面ではこの二者間では異なる言語が話されるわけであることができる。

るが、インバウンドとアウトバウンドで双方の立場がNICT の音声認識は、これら、模擬会話、独話、発あり得るため、それぞれの言語でこれらを収録すれば、話ログの三種の音声コーパスを用いて、音声認識モデ両方の立場の人の音声入力に対応できることになる。

ルを構築しており、これらはそれぞれに、音声認識のこの設計の問題は、その立場に成り切って発話する精度向上に寄与している。

必要があるため、客側の経験はあっても、接遇者側の経験がなければ、何を話してよいかもわからず、話し方もどうしても不自然になってしまう点である。その

2.1.2

話者バランス

ため、ある程度はどのようなことを話すのかの台詞に母語話者と一口に言っても、様々な属性があり得る。

近い原稿を用意する場合がある。そこで、原稿を用意

音声言語的に最も大きく関係するのは、性別、年齢、することはあっても、それを読み上げるのではなく、方言であろう。NICT の音声認識は、音声アプリケー

会話の流れから、自分の言葉で発話するよう教示する

ションを高頻度に使用するであろう年齢層（15〜60 歳）ようにし、書き起こしは実際の発話に基づいて作成すの男女による、各言語の標準語3 を対象としているが、るように指示した。

方言話者による標準語音声も認識できることを目標と模擬会話は、二者による交互の対話であることで、している。方言話者による音声は標準音声に比して音より自然な会話を収録することができる一方で、二者韻に変異があるため、これら方言話者の音声もしかるがその場にいなければならないという制約がある。まべき比率で音声コーパスに含まれている必要がある。

ずその二者の予定を合わせる必要がある上に、当日に模擬会話、独話を収録する際には、これら性別、年代、なってどちらかが来られないことも少なくなく、その方言地域のバランスを考慮している。

管理コストは多大である。最初から原稿が用意されていれば、相手がいることを想定して自分の発話だけをすればよく、後にこの「独話」スタイルの会話も収録

2.2

アノテーション仕様することとした。原稿として用いたのは、NICT 翻訳

音声コーパスの構築には、収集した音声から、一定技術研究室が構築した多言語パラレルコーパス [3] での基準で書き起こしを作成する必要がある。模擬会ある。多言語パラレルコーパスは、機械翻訳を目的と話、独話に関しては、そもそも書き起こせないようなしているため、対訳の対応関係がつきやすいように、音声は収集対象にならないが、発話ログは、音声入力会話と言いながらも直訳的な印象を受ける文スタイルの失敗、言語選択の失敗による他言語音声、高雑音下となっている。そのため、各言語で自然に発話できるで判別不能な音声、非母語話者による音声、など、学ように修正した原稿を用い、さらに現場でも各自が話習データとして望ましくない音声を多く含む。よって、しやすいように適宜変更して発話するように指示した。

これらを除外したうえで、書き起こしを行う。

ただし、実際に機械を介したコミュニケーションをする場合、必ずしも人同士の発話スタイルのようにはNICT における言語共通のアノテーション基本仕様は以下である。

ならず、かつ、音声認識や機械翻訳が長文を受理でき• 各言語の標準表記（正書法）で書き起こす。
• フィラーや感嘆詞はマークする（例：[あのー]）。
• 読みが特定できない、外来語表記や二桁以上の数ない（実際には、ある程度の長さの文であるほうがよいのだが）と考える話者の発話は短いフレーズのようなものが多い。また、様々な音響環境に対応するため字に関しては、標準表記とスペルアウトを併記すに、学習データに雑音を重畳して耐雑音性を強化するる（例：[110/百十] 番、[110/百トウ] 番）。
• 一文の終わりには句点/疑問符/感嘆符を打つ（通こともできるが、実環境で収録された音声を用いることができるなら、それに越したことはない。NICT で常句点を用いないタイ語等の言語でも）。
• 不明な言葉は [<unk>] とする。
• 不用意に記号は使用せず、スペルアウトあるいはは、音声翻訳技術の社会実証、社会還元を目的として、無料の音声翻訳アプリ「VoiceTra2 [4]」を公開している。VoiceTra はまさに実環境における実ユーザ発話が併記する。

収録されているため、このユーザ発話記録（「発話ロ2 http://voicetra.nict.go.jp/

3 標準語をどう規定するかは実は容易ではないが、NICT では「国営放送あるいはそれに準ずる公共機関のアナウンサーによる放送音声」を一つの基準としている。

― 818 ―

Copyright(C) 2018 The Association for Natural Language Processing.
All Rights Reserved.

• 引用符は必要に応じ当該言語で一般的に使用する二桁以上の数字表記を [括弧] で囲んだ場合、続く数詞記号を統一的に使用する。
• unicode に準拠した文字コード（UTF-8）を使用

をつなげるか、スペースを入れるかという分かち書きし、改行コードは LF とする。

も規則化が難しく、人手でのチェックが必要となる。
また、必要に応じてスペルチェックも実施する5 。

特に最後の仕様は計算機で扱う上で重要であるが、後述するミャンマー語においては単純でない問題がある。

3.1.2

VAD による分量・品質検査

前後の無音区間長を厳密に指定することは難しいので（厳密に指定すると、コストに跳ね返る）、一定のNICT のコーパス検査手法

3

無音が発声の前後に入ることは許容されるが6 、仕様

上述までの収録設計、音声書き起こしのアノテー上要求している総時間数のうち、半分が無音という状ション仕様に基づいて、話者募集、収録、音声の書き況は望ましくない。そこで、NICT では VAD（Voice

起こしまでのほとんどを NICT では外注によって実Activity Ditection）ツールを提供して7 正味の音声区施している。その場合、作成された音声、書き起こし間長で仕様要求量を指定、検査するようにしている。の品質をどのように検査するのか、という問題が生じ

また、音声区間が特定できれば、簡易的な S/N も計る4 。そこで NICT では、機械的な自動検査手法と人算ができ、逆に音声区間が特定できないものは、そも手の検査手法の二通りの検査によって、作成物の品質そも音声として問題がある場合があるため、音声自体をチェック、フィードバックすることで、最終的な音の検査にもなる。

声と書き起こしの品質を保っている。

3.1.3

自動検査手法3.1

ASR による品質検査

既に NICT では、GCP10 言語の音声認識モデルを数百時間、数十万文に及ぶ大規模な音声収録・書き構築しており、音声と書き起こしと認識（ASR）結果越しには、多数の作業者が関わる。特に書き起こし作の比較をすることで、これらの乖離があるものは、書業において、仕様通りに書き起こしが完璧になされるき起こしが誤っている可能性があるものとして検査に（100%の書き起こし精度）ことは不可能と言ってよく、役立てている。ただし、ASR の性能は 100%でないた

言語によっては全体の 5 割を超える文に何らかの誤りめ、認識結果と一致しないことが書き起こし誤りと言を含むことは珍しくない。これを全件チェックするこえるわけでもないし、そもそも、認識性能を向上させとは非現実的である。そのため、機械による自動検査るために、音響的にも言語的にも既存の学習データには必須である。

ない音声を求めているわけであるから、むしろ、認識できない音声があってしかるべきである。後述する人

3.1.1

手チェックと合わせて、より頑健な検査となるように、テキスト解析による仕様合致検査補助的な位置づけとして利用している8 。

NICT では、テキストレベルの検査は、主に以下のような仕様の処理ツールを作成して検査を実施して3.2いる。

1. 正規表現で検出可能な、フィラーやスペルアウトの記号の整合性（[括弧] の閉じ忘れなど）、句点の不備、不要な記号の検出
2. ゼロ幅スペースや不正な文字コードの検出

人手検査手法

機械的手法による自動検査には限界がある。なぜな
ら、スペルチェックや正規表現によるフォーマット違反チェック、ASR によるチェックは完全ではないし、結局「音声を聞いてみないとわからない」というのが現実である。そのため、NICT では、GCP10 言語の母語完全にエラーと特定できない場合は、アラートとして話者をチェッカーとして雇用し、抜き取り検査を行っ人手チェックを促すようにしている。例えば、ミャン
マー語ではミャンマー数字を文字として代用してしまうことがあり注意が必要である。また、韓国語でも、4 日本語（あるいは英語）であれば、分担して一定の分量を検査することはできなくはないが、その他の言語はそうもいかない。

5 現状、スペルチェッカーはフリーのツール（例えば Hunspell,https://github.com/hunspell/hunspell）を使用している。
6 むしろ前後の無音は重要な音声要素である。
7 https://github.com/ASTL-NICT/VAD から公開中。
8 実際の検査時には、純粋な抜き取りによる人手チェックをしている。

― 819 ―

Copyright(C) 2018 The Association for Natural Language Processing.
All Rights Reserved.

ている9 。NICT では、現在、JIS 規格（JIS Z 9015-1）表記で記載し、正規化するように指示している13 。音に準拠した、OC 曲線に基づく抜き取り検査を採用し、声認識という点に関して言えば、発声のまま認識結果第一種、第二種の過誤を防ぐよう努めている。

が出力されるほうがよいという見方もあるが、音声翻訳という観点から言えば、正規化されているほうが望ましい。将来的に end-to-end の音声翻訳技術開発が課題について4進めば、この点は問題とならない可能性はある。

以上の方法を用いても課題は残る。以下、これまでに直面している課題例を述べる。

4.1

5

おわりに大規模音声コーパスを構築するに際して、100%の文字コード精度を求めることは難しい。では、何割程度であれば、前述のように、文字コードは unicode に統一され誤りが許容されるかは、学習の結果、その誤りがどのている必要があるが、単純ではない。例えば、ミャン程度、音声認識精度に影響するかに依存するだろう14 。

マー語は、その歴史的背景から、その統一が難しい言

精度がよいに越したことはないが、それはそのままコ語である。ミャンマー国内で最も使われているのは、ストに跳ね返るので、費用対効果を考慮した精度指定

Zawgyi-One というフォント/文字コード10 であるが、と、検査手法が今後も求められるだろう。

このフォントは unicode に準拠していない。ゆえに、unicode に準拠した [2] 文字コードで書き起こしを作成するように指示しても、作業者にその経験がない謝辞ために、書き起こし作業自体が容易でないため、一旦本研究は総務省の情報通信技術の研究開発「グローZawgyi 系のフォントで作成して、それを unicode にバルコミュニケーション計画の推進-多言語音声翻訳変換するような場合もあるが、この変換が十分でない技術の研究開発及び社会実証- I. 多言語音声翻訳技術11

ことがある 。さらに、Windows や Mac OS などのの研究開発」の一環として行われました。

一般的な OS で unicode に準拠したタイプオーダーで入力して正確にミャンマー語を表示することができ、かつ unicode に準拠したタイプオーダーでないと正し参考文献

く表示されないエディタが存在しないことが大きな壁[1] 馬場雪乃. ヒューマンコンピュテーションとクラとなっている。そもそも、ミャンマー語の手書き順序

ウドソーシング. 言語処理学会第 23 回年次大会と unicode 指定のタイプオーダーには矛盾する点もあチュートリアル, 2017.

り、一般的なエディタではこれを補完するので、間違っていることに気づけないことが多い。NICT では、先[2] Martin Hosken and Maung Tuntunlwin. Repre-に示したテキストの自動検査で、最低限、あり得ない

senting Myanmar in Unicode — Details and Ex-

コードオーダーを検出するようにしている。

amples. http://unicode.org/notes/tn11/, 2012.
[3] 今村賢治, 隅田英一郎. グローバルコミュニケー

4.2

ション計画のための多言語パラレルコーパス. 言

音声と表記の整合性

語処理学会第 24 回年次大会, 3 月 2018.

実際の音声は言い怠けて発話されることも多い。また、正しい発話と、一般的な発話が必ずしも一致しな[4] 松田繁樹, 林輝昭, 葦苅豊, 志賀芳則, 柏岡秀紀,安田圭志, 大熊英男, 内山将夫, 隅田英一郎, 河い場合がある12 。日本語同様、韓国語やタイ語、ミャ井恒, 中村哲. Development of the “VoiceTra”

ンマー語など、音をそのまま表記できてしまう言語に

multi-lingual speech translation system. IEICE

おいて、標準表記と実音声のどちらを採用すべきかはTRANSACTIONS on Information and Systems,

悩ましいが、NICT では、書き起こしを正書法/標準Vol. E100-D, No. 4, pp. 621–632, April 2017.

9 検査を外部の専門業者に外注することもできるが、結局、その専門業者の作業結果を検査する必要があり、堂々巡りとなる。
10 ミャンマー語では、フォントと文字コードは非分離である。
11 現在ではほぼ 100%変換できるツールもある。
12 例えば、十個を「ジッコ」と発話する人は多くはない。

13 読み方が一般的とは言い難い場合は、実発声をスペルアウトして併記するように指示している。
14 現状、十分な量（数百時間レベル）のコーパスであれば、一文のうち、一単語の書き起こしが間違っている文が全体の 10%程度あっても、大きな問題はないと考えている。

― 820 ―

Copyright(C) 2018 The Association for Natural Language Processing.
All Rights Reserved.