トップ » バックナンバー » Vol.4 » ヒューマン・インターフェイス

Accumu Vol.4

ヒューマン・インターフェイス

日本アイ・ビー・エム株式会社 東京基礎研究所 ユーザーインターフェイス担当

大河内 正明

はじめに

人間が対話に使っている音声あるいは日本語というものをコンピュータでも使っていこうという研究を長年やってきましたので,その中から最近の研究成果を紹介したいと思います。

最初に,私どもの東京基礎研究所で研究している音声及び日本語関係の研究テーマを紹介します。大きく分けて日本語入力,音声情報処理,それから機械翻訳という三つの分野で研究を進めています。日本語入力は,当然漢字を伴いますので,日本語特有のいろいろな処理が必要になってきます。いちばん基礎的な「カナ漢字変換」についても更に高度化するための研究を進めています。それから,日本語の原稿の中からいろいろエラーを見つけて直すことを支援する「校正支援システム」についても研究しています。これについては,後でもっと詳しぐ述べます。その他,手書き漢字や印刷漢字を読む「OCR」,書きながら読みとる「オンライン手書き文字認識」なども研究しています。二番目の音声情報処理の分野では,しゃべった言葉をコンピュータで認識する音声認識と,コンピュータで音声を出力する音声合成を研究しています。音声合成といいますと,録音したものを単に再生するだけの単純なものもありますが,私どもは前もって録音せずに任意の文章を読み上げるテキスト音声合成を中心に研究しています。これはデータベースの内容を音声で出力するとか,翻訳電話の出力に使うなど,高度な使い方が可能になります。三番目の機械翻訳の分野では,日英翻訳と英日翻訳に取り組んでいます。これらの中から以下では,日本語校正支援システムと音声認識の二つにしぼってさらに詳しぐ述べます。

日本語校正支援システム

図1

最初に,日本語校正支援システム,フレックス(FleCS)について紹介します。これはフレキシブル・クリティーキング・システム(Flexible Critiquing System)の略で,柔軟で拡張性のある校正支援システムです。まず校正作業がどういったものであるかを具体例で示します。図1の新聞の原稿にはいくつかのエラーがあります。読者はまず先に進む前に校正してみてください。修正すべき点は図2のように11ヵ所あり,フレックスはこれらをすべて検出できます。校正というのは,簡単なようですけれど,結構人間にとっては見つけ易く,コンピュータにとっては見つけにくいものもあれば,逆に人間は見落とし易く,コンピュータに非常に得意なものもあります。そういったところを補完し合うことにより,効果的な校正支援システムができます。例えば,「どんな時」と入力したい時にローマ字漢字変換で行う場合「ん」を「NN」とキーインすることがあるのですが,それを間違えて「N」だけキーインすると,「どんな」を入力したつもりが「どんあ」になることがあります。それから,「人工知能」も四漢字のまま辞書にあり,全体で変換すれば問題ありませんが,「じんこう」,「変換」,「ちのう」,「変換」とやりますと,「じんこう」が「人工」でなく「人口」となってしまうことがあります。それから,「20万人をこえる」という場合の「こえる」は,「越える」ではなくて「超える」です。これもよく間違えるエラーです。それから,「学校に行く」と入力した後で編集している時に,「に」を削ってしまい「学校行く」となるようなエラーもよくあります。このような誤りをフレックスでは見つけることができます。その他新聞などでは使ってはいけない言葉があります。例えば「めくら」という言葉は,禁止用語となっています。その場合には「目の不自由な人」と書き換えなさいと指示を与えます。それから,人間に苦手なものとしましては,表記のゆらぎがあります。例えば,「おこなう」の表記として,「行なう」と「行う」のどちらの送り仮名も使われることがありますが,同じ文章の中でこれらが混在していればおかしいということになります。外来語も表記のゆらぎがかなりあります。例えば,「interface」のカタカナ表記は「インターフェイス」,「インターフェース」など数通りあります。どの表記も聞遅いではないですが,一つの文章の中では統一して使う必要があります。こういう表記のゆらぎは人間にとって見落としがちです。それから,「再検討し直す」というような重言もよくあります。これは「再検討する」か,「検討し直す」のように直す必要があります。それから,「です・ます調」と「である調」の文体が混在していればおかしいので,こういったものも指摘します。それから,だらだらした表現や「…でないとは言えない」のようなまわりくどい表現なども指摘します。

図2

ここで,図1の新聞記事原稿の校正結果(図2)について,若干補足しておきます。「…その後遺体で見つかったが,死因や動機などが不明だが,…」のように,「何々だが,何々だが,…」と続くとわかりにくいので,どちらかの文章を「。」で閉めて,もう一回文章を始めてくださいと指摘します。例えば,この場合ですと「その後遺体で見つかった。死因や動機など不明だが…」とすると,非常に締った文章になります。次に,「…警察によると,男は同日」は,「同日」と言いながら前の方に何日かが書いてありません。初めの原稿では何日に事件が起きたか書いてあったのでしょうが,多分記事を短くするために編集してその部分を消してしまって,それを引用する部分はそのまま残っているのでしょう。こういう類のエラーはよくあります。それから,新聞では「0時」とは書かず,常に「零時」と書くそうです。「カフェテリヤ」と「カフェテリア」はどちらもよく使いますが,同じ文章の中で混在しているとおかしいので,「どちらかに統一してください」とコンピュータではメッセージが出てきます。

図3・4

フレックスのシステム構成は次のようになっています。まずエディターがあって,そこで文章をカナ漢字変換によって入力したり,編集したりします。誤りの検出は,いわゆる文法解析と,ルールベースシステムの二つを組み合わせて行っています。エディターはいろいろなものが使えるようになっています。例えば,図3の画面は実際にIBMのマニュアルの原稿の校正に適用した時のエディターの両面です。ここでは「オペレーテイングシステム」というエラーが検出されています。当然「オペレーティング」ですから「イ」は小さくなくてはいけません。これは結構人間が見落とし易いエラーです。画面上には「オペレーテイング」というのは未知語,つまり辞書にはない言葉で,しかも文章の中に「オペレーテイング」と「オペレイティング」の,似た単語が二つあるけれど,これらを同じ意味で使っているのならば統一してください,とメッセージが出ています。図4は,新聞記事用の縦書きのエディターの画面です。この場合ですと,新聞記事の原稿中に,二つの誤り候補が検出されています。「成長の」というのは,文脈から見て使い方がおかしい。また,「どーむ」は未知語であるということです。

フレックスは実際にIBMのパソコンPS/55上で,OS/2というオペレーティングシステムの下で動いています。実際このシステムは日本IBMのマニュアルを作る部門で,OS/2のマニュアルの原稿に対して適用しています。最初合計1万ページ以上を,ある程度人手でチェックした後で,このフレックスをかけてみたところ,2ページに一ヵ所くらい,更に見落としのエラーが見つかりました。前述の「オペレーテイング」もその例です。実際にフレックスを通した後でも,まだ見落としのエラーがありましたが,修正すべき箇所のうちの八割は,このフレックスで見つけることができました。有効性が実証されたので,今では日本語のマニュアルに関しては,全部このフレックスを使っていこうということになっています。一方,問題点としましては,どのくらい厳しくチェックするかという点があります。あやしい所に全部ウォーニングを出すと,煩わしいという人も出てきます。どのくらい厳しいチェックをするかは,人によって,あるいは分野によって違ってきます。それから当然のことながら,どういうエラーを検出すべきか,というのも変わってきます。例えば新聞記者ですと,記事の書き方のガイドブックがあり,それに従って書かないといけません。しかし,一般の人にはもっといろいろな表現が許されるべきでしょう。

フレックスは,誤りの検出能力が高いだけではなく,ユーザーの要求の多様さにも対応できる柔軟性と拡張性をもっています。しかも,パソコン上で対話的に使えます。このようにフレックスは,先進的な校正支援システムです。

音声認識

次に,音声認識について紹介しましよう。音声認識は人間のしゃべった言葉を認識することが目的ですが,それに対する代表的手法としては,大きく分けて三つあります。一つはDPマッチング。DPというのはダイナミック・プログラミング。動的計画法という最適化手法を使うことを意味しています。二つ目は,ヒドゥンマルコフモデル(Hidden Markov Model-HMM),三つ目が,最近よく話題になるニューラルネットワークです。

従来の音声認識の製品のほとんどは,DPマッチングに基づいています。DPマッチングは,簡単に言いますと,訓練する時には,例えば一回「トーキョー」とか「キョート」とかしゃべって,それらのパターンを保存しておいて,認識する時には,新たにしゃべった,例えば「キョート」というパターンを,保存しておいた各パターンと重ね合わせて,いちばん重なりのいいものを選ぶというものです。ただし,最初に「トーキョー」とか「キョート」としゃべった時と,認識させる時にしゃべる「トーキョー」,「キョート」とは,同じようにしゃべったつもりでも音声パターンはずれます。ですから,そのずれをいかに補正するかが重要です。特に時間伸縮に関して補正するようにしたのがDPマッチングです。例えば,「京都」としゃべる場合でも,長くしゃべれば「キョオート」となり,母音の「オ」が伸びます。「キョ」のような子音の部分はあまり伸び縮みしません。このように伸び縮みが一様ではないので,これを補正するようにしたのがDPマッチングです。DPマッチングに基づく音声認識の製品が実用化されていますが,認識できる単語数は自分の声を前もって登録する,いわゆる特定話者のもので,200~300単語程度です。自分の声を登録しないで使える,いわゆる不特定話者のものではもっと少なくなります。例えば,電話で銀行の残高問い合わせをするシステムが実用化されていますが,扱える単語数は,数字と,「はい」「いいえ」など16単語くらいです。電話を使わないものでも,不特定話者用ですと,100単語くらいというのが従来技術の現状です。最近もっと高度な音声認識を目指した研究が盛んになるにつれて,音声のゆらぎを,もっと理論的に正確に反映できないかということで,HMMやニューラルネットワークなどの統計的な手法が着目されてきています。

HMMというのは,音声のゆらぎを確率的にモデル化しています。時間伸縮のゆらぎだけではなくて,スペクトル的なゆらぎも確率的に表現しています。確率というものを基本にしているので,確率に基づいた統計理論や情報理論などを用いて理論的な展開ができます。また他の手法,他の処理との統合も容易になります。例えば,確率的言語モデルというものが盛んに研究されていますが,その確率的概念を使い,HMMによる音声認識と容易に統合できます。その意昧でも非常に有効な枠組みとなっています。IBMはHMMによる音声認識を,アメリカのワトソンの研究所で20年ぐらい前から研究してきており,私どもの東京基礎研究所でも,10年ぐらい前から研究を進めてきています。最近ではIBMだけではなく,各国の研究機関で研究されており,日本でもHMMを手がけていないところはないくらいに盛んに使われてきています。

ニューラルネットワークも最近着目されていますが,ニューラルネットワークを一言で言うと,パターンの分類の仕方を多量のデータから自動的に学習しようとするものです。分類アルゴリズムが無くても,力づくで分類の仕方を学習しようというもので,特にカテゴリーが少ない場合に効果的だという報告があります。ただし,パラメータの理論的な意昧づけが困難であり,ニューラルネットの中で閉じて扱っている分にはいいのですが,例えば,言語処理とどのように統合したらいいか,それから出てくるパラメータをどのように解釈したらいいか,という所で難しい点があります。いずれにしろ,ニューラルネットの長所も,HMMの理論的にすっきりした大きな枠組みと組み合わせられて,発展していくのではないかと思います。ちょっと位置付けに長くなりましたけれど,この後,HMMというものを使った音声認識の具体的な内容について,紹介します。

図5

HMMによる音声認識の基本的なシステム構成は図5のようになります。入力音声は,まず音声分析によって,10ミリ秒ぐらい毎にスペクトル・パターンなどに変換されます。それを,例えば「オ」に近いスペクトルだという形で分類してラベル付けしています。そういったラベルを,HMMの訓練にも認識にも使っています。

図6

例えば,図6のように「東京」に対応するHMMがあったとします。HMMはマルコフモデルですので,いくつかの状態があり,ある確率で状態を遷移します。この場合ですと,四つの状態S1…S4があり,例えばS1からS2に30%の確率で遷移し,S3には20%の確率で遷移し,S1自身には50%の確率で遷移するというように,ある遷移確率でもって状能を遷移します。その遷移の際に,ある出力確率でラベルを出力します。例えば「オ」に近いあるラベルが,3%の確率で出るという具合です。この確率をラベル出力確率と言います。このように,状態をある確率で遷移しながら,しかも,その際にある確率でラベルを出すのがマルコフモデルです。こういったマルコフモデルは,例えば「東京」という言葉を何回かしゃべって訓練しますと,逆にこのマルコフモデルは「東京」に近いラベル列を出し易くなります。例えば,「toookyooo」は0.1の確率で出力し,「tookyo」は0.08の確率で出力します。また,「東京」に対応しない「pookyo」や「kyooto」なども低い確率で出力します。ともかく,どんなラベルに対しても,何らかの確率で出そうとします。

図7

ここで「東京」,「京都」,「大阪」の三単語の音声認識を考えてみましょう。今,入力音声に対応して,「トーキョー」に近いラペル列が入ってきたとしますと,今三つの単語に対応する各HMMに対して,このラベル列を出力するとしたらどのくらいの確率で出力するかを見積もらせます。そうしますと,図7のように,この「東京」に対応するマルコフモデルは,例えば「このラベル列は私の得意なパターンだから,0.1の確率で出します」と見積りをするわけです。「京都」というモデルに対して,同じように見積りさせると,「自分は東京に対して訓練されているから,『トーキョー』に近いものに対しては,高い確率で出すのだが,まあ『キョート』も『トーキョー』にちょっと似てるから,0.003くらいの確率で出そうじゃないか」と見積ります。「大阪」のモデルになると,「『オーサカ』は,私の得意なパターンとかけ離れているが,無理に出せと言うなら0.001の確率と,お付き合い程度に見積りましょう」ということになります。それぞれの見積りの確率で,一番高い確率を出した「東京」のモデルが選ばれて,「東京」が認識結果になります。このように基本原理はきわめて単純です。まとめますと,HMMは音声の時間伸縮のゆらぎもスペクトル的なゆらぎも,確率的に表現します。認識時には,入力音声に対して,各モデルに見積りをさせまして,それで,最も高い確率で見積もったモデルを認識結果とします。

私どもでは,HMMに基づいた音声認識を去年の暮れに製品化しています。IBM日本語音声認識合成アダプターという製品です。これは,パソコンに一枚のボードをさすだけで,音声認識,音声合成,テープレコーダのように録音したり再生したりする機能,及び電話をかけたり電話を受けたりする機能の,四つの機能を実現しています。その音声認識の機能は,最大1000単語まで認識するようになっています。製品としては最大レペルだと言えると思います。一方,大語彙になると,単語を登録するのに時間がかかります。例えば,1000単語をしゃべって登録するのに,1時間以上かかります。ですから,使う人全員に「長時間しゃべって下さい。そうしないと使えませんよ」というのは大変なので,最初の人が1000単語全部登録すると,二人目からはそのうちの一部,例えば50単語だけしゃべれば,システムの方はその人の声の特徴を調べて,1000単語分のパラメータを新しい人用に修正して,1000単語全部使えるようにする,話者適応という学習機能があります。50単語をしゃべるだけでしたら数分で終わります。これも一つの大きな特徴となっています。それから,実用上はノイズに対する対策も非常に重要です。例えば,そばで電話が鳴ったからといって,音声認識が勝手に誤動作しても困りますので,音声でないものには反応しないようにする機能も入っています。このように,本システムは数々の特徴をもっています。初めにも述べたように,コンピュータはますます人間に使い易いものになっていく必要があります。その中でも特に,人間同士の会話で使われている音声や日本語の役割が重要になっていくと思われます。

(京都コンピュータ学院京都駅前校舎竣工記念フェスティバルより)

この著者の他の記事を読む
大河内 正明
Masaaki Okawachi
  • 日本アイ・ビー・エム株式会社
    東京基礎研究所
    ユーザーインターフェイス担当

上記の肩書・経歴等はアキューム4号発刊当時のものです。