Google日本語入力の技術講演会

Google日本語入力の、公式技術講演会に行ってきた。その次第を書きたいと思う。

今回の会場は、なんと大阪である。そのため、私のように関西圏に住んでいる人間には、参加しやすい。

まず、京都から大阪へ行く。いつも思うのだが、大阪の都市部は、まるでダンジョンだ。地上と歩道橋と地下道があって、一体どこを進んでいいのやらさっぱりわからない。大阪の立体構造を再現して、ゲームとして売り出せば、案外ヒットするのではなかろうか。

さて、受付の始まる時間になったので、会場に向かう。なんと、すでに長蛇の列であった。早くも失敗したか。もっと早くから来ていれば、前の方に座れたかもしれない。軽く失望しつつ受付を済ませると、なんと、一番前の席が、二席だけ開いているではないか。知っての通り、私はそういう性格なので、迷わず一番前に座った。ちなみに、隣の席は空いていたが、何故か誰も座ろうとしなかった。こういうのは、だいぶ性格が出るらしい。前に座った方が、スライドも見やすいし、講演者とも近い。前に座ったことで、損をすることはない。とすれば、最前列に座るのが最善であるはずだ。にもかかわらず、私が部屋に入ったときは、もうほとんど埋まっていたのだが、それでも、前の席が空いていた。

このような講演会に来るほどは積極的で、しかも最前列に座るほど積極的ではないというのは、どういうものなのだろうか。それはさておき。

肝心の内容だが、それほど目新しい情報はなかった。多くの事は、すでに技術系サイトのインタビューなどで、断片的に公開されている内容であった。それでも、実際に講演を聞くのは、得るところが多かったと思う。

特に何も言われていないので、興味のある人のために、講演会の概要をここに書いておく。また、すでに技術系サイトのインタビューなどで、既出となっている情報もあるが、特に示さない。

まず、IMEというものについて説明があった。

IMEは、ブラウザやOSにすら匹敵する、非常に大規模なシステムである。

IMEには、二つの問題がある。絶対にクラッシュできないという事と、強いセキュリティが要求されるという事だ。

もちろん、ソフトウェアは、なるべくクラッシュするべきではない。とくにIMEは、辞書などのファイル操作を伴なう。クラッシュすることによって、ファイルの書き込みが不完全になってしまうと、IMEの挙動がおかしくなってしまうかもしれない。これは、クラッシュしてはならない理由の、IME側の都合である。その他にも、クラッシュしてはならない理由がある。

Windows環境では、IMEはDLLの形で提供する。このDLLは、かな漢字変換を利用する全アプリのプロセスにロードされる。もし、IMEのDLLがクラッシュしたならば、その読み込み元のプロセス、すなわち、他人のアプリを巻き込んでしまう。したがって、IMEのDLLは、クラッシュしてはならない。

残念ながら、IMEのDLLは、実際にクラッシュする。これは、IME側の理由だけではない。もし、IM DLLを利用するアプリがクラッシュすれば、当然、そのプロセスのDLLも巻き添えを食らう。

ファイル書き込みなど、IME自体もクラッシュしてはならない理由はすでに述べた。しかし、IME側だけではどうにもならない、アプリ側のクラッシュには、一体どう対処すればいいのか。

セキュリティの問題もある。IM DLLは、アプリのプロセスに読み込まれる。つまり、IMEは、利用されるアプリと同じ権限を持つということである。つまり、管理者権限で実行されるアプリにロードされたIMEもまた、管理者権限を持つのである。たとえば、レジストリエディタだ。たとえば、ログオンプロセスだ。したがって、IMEは、絶対にセキュリティ上のヘマをしてはならない。

たとえば、IMEの変換候補ウインドウから、ブラウザを立ち上げてググれたら、便利な機能かもしれない。しかし、IMEはログイン画面で実行されることもあるということを考えれば、ブラウザを立ち上げるような、安易な行動はできないのである。ログイン画面で、ログインもせずに、管理者権限のプロセスであるIMEからブラウザを立ち上げられるような環境は、セキュリティ上、非常にまずい。

従来のIMEの実装は、DLLで、ユーザーの入力やら、かな漢字変換やら、結果の表示やらを、すべてやっていた。その結果、DLLは非常に肥大化した。巨大になるということは、それだけクラッシュする要因が増えるということである。

Google日本語入力は、既存の価値観に縛られない、斬新な発想で設計された。

Chromeでもおなじみの、マルチプロセスとsandboxである、

Google日本語入力を、大別すると、以下のようになる。

IM DLL（GoogleIMEJaTIP32.dll）

全プロセスに読み込まれるDLL。従来のIMEは、主にこれを指す。Google日本語入力では、IM DLLは、ユーザーからの入力を受け取り、Converterに渡し、結果を表示するだけの処理をする。

Converter（GoogleIMEJaConverter.exe）

変換エンジン。IM DLLから、ユーザーの入力を受け取り、かな漢字変換の処理を行い、結果をIM DLLに返す。

Renderer（GoogleIMEJaRenderer.exe）

変換の候補ウインドウを表示する。

IM DLLは、最小限の処理しかしない。ユーザーの入力を受け取り、変換エンジンに丸投げし、結果を表示するのである。IMEの肝心要の、かな漢字変換機能は、Converterが処理する。

ConverterやRendererは、必要最低限の権限しか持たない。Windowsでは、プロセスの持つ権限を制限することもできる。Chromeでもおなじみの手法である。

このように、プロセスで分けることによって、クラッシュ耐性とセキュリティを確保している。IM DLLがクラッシュしても、Converterには被害が及ばないし、逆に、Converterがクラッシュしても、IM DLLには被害が及ばない。

また、移植性（portability）も確保できる。たとえば、64bit版は、わずか一日で移植された。テストに十日かかった。わずか一日で移植できた理由は、マルチプロセス、プロセス間通信という設計なので、アプリに読み込まれるIM DLLさえ64bitコードに移植すれば、ConverterやRendererは、32bitプロセスでも、問題はないからであった。

Converterは、クラッシュしても全く問題ないようになっている。ためしに、タスクマネージャからConverterのプロセスを強制終了しても、全く問題がない。Converterプロセスが終了したことを検知し、自動的に再起動される。

デモでは、4秒おきに、Converterプロセスを強制終了する、極悪なスクリプトを走らせた状態においても、IMEが全く問題なく使えるということを実演していた。

しかし、ユーザーの入力中に、Converterが終了したら、どうするのか。たとえ、Converterプロセスを再起動できたとしても、また変換の確定していない、入力中の文字列は、一体どうすればいいのか。

これも、問題ない設計になっている。IM DLLは、ユーザーの一連のキーシーケンスを保持している。Converterプロセスが不意に終了した場合、このキーシーケンスを再び送り返すことによって、元の状態に戻すことができる。だから、4秒おきにConverterが強制終了するというような、極悪な環境下でも、ユーザーはまったく気にせず、入力ができるのである。

一連のキーシーケンスとは何か。これは、Enterキーを押して、変換を確定するまでを指す。

ちなみに、4秒ごとにConverterを殺すデモでは、全員、無反応であった。というのも、あまりに普通に動きすぎて、ユーザー側からみると、Converterが4秒おきに殺されているなんて、全く分からなかったからだ。「ここは、驚くところなんですけどね」という講演者の声が、むなしく響いた。それぐらい、あまりにも普通に動きすぎていた。

また、この機能は、デバッグにも役立つ。たとえば、あるキーシーケンスでConverterがクラッシュする場合を、容易に補足できるし、また、問題の再現が簡単である。自動テストでは、様々なキーシーケンスを、非常に過酷な状況（CPUが遅い、メモリが不足している）で流し込み、延々と走らせ、クラッシュする場合を探している。

さて、では肝心の、かな漢字変換は、どうなのか。これは、具体的なアルゴリズムは公開できないものの、教科書に乗っているぐらい、基本的なものを使用しているとのことであった。

辞書について。語彙は重要だが、多ければ多いほどいいというわけではない。英文のスペルチェックでも、既存の辞書のすべての単語を、スペルチェックの辞書に詰め込むと、普段使わないような文字の組み合わせでも、妥当な単語として認識されてしまう。

しかし、豊富な語彙は必要である。しかし、あまりに多すぎると、メモリを大量に消費してしまう。第一、辞書ファイルの破損の問題もある。一体どうすればいいのか。

まず、辞書のデータ構造だが、これはTRIEと呼ばれているツリーのような構造を用いている。これは、決して高速なデータ構造ではないが、辞書サイズの圧縮に役だつ。また、かな漢字変換の単語検索には、完全一致（exact match）ではなく、たとえば、「あ」なら、あに続く単語（亜、愛、愛子、アイス等）も必要になる。この要求も満たしている。

さらに、このTRIEというデータ構造を、LOUDSという手法で実装して、データ量を圧縮している。ハフマン符号で、さらに圧縮をしている。別になにか特別な改良版アルゴリズムを使っているということはなくて、基本的には、教科書通りのハフマンらしい。

データ構造の圧縮と最適化については、タバタさんという職人気質なGoogle社員が、20%ルールでやっているそうである。タバタ・メソッドと呼ばれているとか、いないとか。

LOUDSで、辞書を70MBまで圧縮し、ハフマンで35MBまで圧縮しているらしい。

たったの数十MB程度のファイルサイズだが、語彙は膨大なものになるらしい。語彙がどのくらいあるのかということは、公開できないとのことだ。

辞書はどうやって生成するのか。これは、Web上からのデータから、自動的に生成している。人力ではない。ただし、ある程度の基本的な単語（食べる、歩く等）は、自動生成ではない辞書を持っている。

辞書のデータをどのように保持するのか。これは、辞書ファイルというものがあるのではなく、実行形式のバイナリに、そのまま埋め込んでいる。つまり、Converterに埋め込んでいる。

この設計の利点は、辞書をstatelessにできるということだ。辞書への書き込みが行われないので、辞書ファイルの破損ということはなくなる。何らかの理由で辞書が破損した場合（HDDが壊れたなど）、Converter自体が動かなくなる。つまり、破損した辞書ファイルのまま、中途半端に動くということがなくなる。

また、自分でメモリ管理をしなくていいという利点もある。なぜなら、Windowsでは、実行ファイルは、メモリ上にマップされる。メモリ管理は、OSが自動でやってくれるのである。

このため、OSのメモリ管理の戦略がヘボいと、IMEのパフォーマンスも落ちてしまう。具体的には、Windows XPだ。Vista以降なら、メモリ管理のアルゴリズムも賢くなっている。まあ、XPの欠点は、すでによく知られた話だが。この問題は、昼休みから帰ってくると、メモリがスワップアウトしていて動作がモッサリになるので、そのような名前をつけられていた気がする。

また、辞書のデータ構造の互換性に悩まされなくてもよいという利点もある。データ構造を改良した結果、下位互換性がなくなったとしても、辞書は、Converterそのものなので、Converterを差し替えればよい。すでに述べたように、Converterが不意に終了しても、全く問題ない設計になっているので、アップデートも、簡単にできる。最も、アップデートの際は、IMEがONになった時点とか、比較的安全な、都合のいい時を選ぶらしいが。

Google日本語入力は、「もしかして」機能から始まった。もしかして機能の利用結果を調べたところ、既存のIMEの誤変換によるものと思われる入力間違いが、非常に多かった。そして、もしかして機能は、正しい結果を返すことができていたのである。とすると、これはIMEにも利用出来るのではないかと考えた。

Googleには、有名な20%ルールがある。これは、「20%の時間を使ってもいいよ」という権利ではなくて、「20%は別のことをしなさい」という要求であるらしい。実際、何もしていないと、「何でお前は何もしていないんだ」と文句がくるらしい。Google日本語入力は、当初、20%ルールとして発足した。今は、本プロジェクトになっている。

Google社内には、日本語処理や、IMEの開発に携わっていたプログラマが、何人もいた。そういう人達が集まって、IMEの設計のディスカッションをし始めた。IMEの設計はどうあるべきなのか。

IMEは膨大である。当初は、ただひたすらディスカッションだけに、半年もの時間が費やされた。ある日、「誰もコードを書いていないではないか！」、ということに気がついた。それからは、週に一度、集中的にコードを書く日を設けることにした。

出来上がったデモ版は、はじめからかなり精度が高かった。これならイケるということで、社内でdogfooding（自社製品を社員が率先して使うという意味のMS用語）が始まった。多くのフィードバックが得られたが、特に多かったのが、「俺の使っている、既存の某IMEにある、この便利な機能がないぞ」というものであった。既存のシステムからの移行を用意にするため、既存のIMEのキーバインドや、メジャーな機能を、なるべく提供するようにした。Google日本語入力独自の売りは、サジェスト機能と語彙である。

あとはひたすらテスト、テスト、テスト。

テストが通らず、やむなく落としている機能も、二、三あるという話である。どのような機能かは公開できないが、いずれ、公にする日が来るだろうとのことであった。

Google日本語入力は、斬新な設計である。クラッシュを前提にした、クラッシュしても問題のない設計。そのためのマルチプロセスを利用したsandbox化。Web上から自動的に辞書を生成。辞書の圧縮と、辞書をプログラムのバイナリに含めること。

興味深い質疑応答を取り上げると。

今後のリリース期間はどうなるのか。定期的なバージョンアップなどはあるのかという質問に対しては、まだプロジェクトが始まったばかりなので、決まっていないが、できれば常に最新版を提供して行きたいとの答えであった。

Web上のデータは、信頼性の高いデータと、あまり文法的に正しくない文章の使われている可能性の高い、信頼性の低いデータが混在している。Web上から辞書を自動生成する際に、データごとの重み付けをおこなっているのかという質問に対しては、そのような重み付けは行っていないとの答えであった。

Web上のデータからの辞書生成には、品詞を推定してつけている。完璧とは言わないが、ある程度は動いている。

ユーザーの実行環境は様々である。一体、何が最も、パフォーマンス上のボトルネックになるのかという質問に対しては、メモリとの答えであった。Windows XPのメモリ管理の戦略が、相当ひどいらしい。Vista移行なら問題ない。これは元々質問だったが、興味深かったので、上でも言及した。

コマンドプロンプトではGoogle日本語入力を使えないが何故かという質問に対しては、Vista以降なら使える。XPはTSSのサポートがまだ不十分なのだ。Vista以降を使えば問題ないという答えであった。

Web上のデータは、偏りすぎているのではないか。普通の文章が書きにくいのではないか。ユーザーの特性を判定して、単語のランクを変えるというのはどうかという質問に対しては、いい意見だとの答えであった。

放送禁止用語はどうするのか。他のとあるIMEは、放送禁止用語を省いていることを、「機能」だと謳っているそうである。現在のGoogle日本語入力には、放送禁止用語が多数含まれている。これを自主規制することは考えていないのかという質問に対しては、Googleはあくまで、Web上の単語のランクに基づいて辞書を生成し、人の手を加えることがないようにするのが、基本理念なので、そういうことはしないとのことであった。

個人的な意見では、自主規制は、すべきではない。だいたい、身体障害者を意味する、片輪だって、本来は、湾曲表現だったのだ。最近、とある政治家が、障害者ですら差別的に聞こえるから、障がい者としようなどと行っているらしいが、これとて本来は、障碍者だったのである。また、そもそも障害者という言い方をやめて、フィジカリー・チャレンジド・ピーポー（Physically Challenged People：肉体的に、神から試練を与えられた人々）にしようなどとたわけた事を抜かす政治家もいるようだが、アホらしすぎてまともに反論する気さえない。

こうなってくると、私には、Political Correctnessを、「政治的に正しい」と訳すのは、妥当な翻訳であると思えてしまう。実際、その正しくなさが、自己言及的に正しいと思う。

話がそれた。私信を終わる。

一体、どうやってIMEで利益を出すのかという質問に関しては、現時点では、IMEで直接利益を上げることは考えていないとのことであった。IMEを使うことによって、プログラマやユーザーがより便利になれば、間接的に、Googleの利益にもなるだろうという旨のことを答えていた。

Linux版は、本当に出してくれないのかという質問に関しては、Linux版はださないという答えであった。ただし、Chrome OS関連で、オープンソース化されるので、Linuxに移植したい人がいれば、ご自由にどうぞというスタンスらしい。

他の言語、たとえば英語とか、アラビア語とかのIMEを統合して、開発する予定はないのかという質問に対しては、そのような予定はないとの答えであった。ただし、Googleは中国語版のIMEを開発していて、すでにリリースされているらしい。

私は、ユーザー辞書について質問したいと考えていたのだが、それは何人も質問していた。そこで、前々から気になっていた事を質問することにした。

それは、学習機能である。多くのIMEは、ユーザーの入力から学習して、文節の区切りや単語のランクを変更する。ところが、この学習が愚直で、大昔にただ一度だけ入力した変な変換結果を、そのまますべての変換に適用し、その結果、学習すればするほど、おバカになっていくということが、ままある。これを改善できないのかと質問した。まったく具体的な技術とは関係ない、単なる要望である。

答えは、それは、IME各社とも、非常に悩んでいる問題である。改善したいとは思っているとのことであった。

その後、Googleの新卒採用と、採用試験の方法についての説明があった。とくに真新しい情報はなかった。中途採用も年中募集中らしい。

なんだか、Googleで働きたくなってしまった。しかし、今私が最優先すべきなのは、C++の参考書の執筆である。働きながら執筆というわけにはいかない。私がGoogleにレジュメを送るとしたら、前回のC++WG会議で、一生さんに語ったあのネタを、本気で実行するしかない。

さて、Googleの講演会なので、いくつかのGoogleグッズをもらった。

Googleのロゴ入りボールペン。残念ながら、私は、万年筆を使っているので、ボールペンを使うことはないのだが、なかなかカッコいい。

Googleのロゴ入り携帯ストラップ。これもシンプルでカッコいい。

Googleのロゴ入り手提げバッグ。単なる安物の買い物袋である。Googleのロゴが入っているのでカッコいい。

Googleのロゴ入りTシャツ。質問をした人、全員に配られた。前に円を主体とした幾何学模様、後ろの首の部分に、Googleのロゴが入っている。カッコいい。

講演会は非常に楽しかった。終わってから、「やあ、本はどうですか」と声を書けられた。誰かと思えば、redboltz氏である。氏もこの講演会に参加していたとは、全く気がつかなかった。しかも、質問までしたというではないか。いやはや。

氏とC++0xの本について話しながら、大阪駅まで歩いた。相変わらず、大阪のマップはダンジョンである。幸い、氏が先達となってくれたので、私は無事に、迷路のような地下道を脱出して、大阪駅にたどり着くことができた。

氏に、「君はGoogleに向いているのではないか」と言われた。英語はともかく、その他はどうだろうか。最近の私は、言語仕様専門なのだ。アルゴリズムといえば、入門書に乗っているような基礎的なものしかしらない。しかも、主に考えることは、このアルゴリズムを、C++でジェネリックに実装したらどうなるか、ということである。それに、今の最優先事項は、C++0x本の執筆である。C++0x本の執筆に、時間が必要である。フルタイムの時間が必要である。

本の執筆には、金がいる。海外で行われる標準化委員会のmeetingに出席したいし、なにより私は、生活していかなければならないのだ。しかし、執筆以外の仕事に時間をとられているわけにはいかない。あの理想主義者のネタしかしないのか。

まあ、レジュメを送ってみるか。

追記：氏はTwitterを使っているが、私のGoogle Readerからは漏れていた。フィードに放り込んでおけば、あらかじめ、気がつけたかもしれない。私はすでに、10人以上ものTwitterアカウントを、Google Reader経由で閲覧している。結局のところこれが、Twitterに賛同できない私の、最低限の落しどころである。Twitterよりブログの方が楽だと思うのだが。