Web上でついにUnicodeがASCIIを越える

Mark Davisのブログの記事「Moving to Unicode 5.1」によると，Web上で使われる文字符号化の割合として，UTF-8が，ASCIIやISO-8859-1/CP-1252を越えたらしく，その様子がErik von der Poelが作成したグラフでわかる．
すでに，かなり前から既にOSやシステムの内部で用いる文字符号化はUnicode化されていたのだが，しばらくは外部との情報交換は以前としてShift-JISや既存の文字符号化を用いることが多かったし，未だにUnicode化されたことを気が付いていないユーザも多いだろう．しかし，少なくともWebに限れば，Unicode化されたシステムの普及により外部との情報交換もUnicodeでおこなうようになったことと，英語圏以外から発信される情報が増えていることが複合した結果だろう．まあ，文字符号化判定アルゴリズムや言語比率（Googleは文字符号化判定に加えて言語判定もおこなっている）がわからないと詳しいことは言えないのだが（たとえば，システムがUTF-8と宣言しても，US-ASCIIと同じ文字しか使っていない場合には，どちらにカウントされているかとか）．
なお，彼が示したグラフを見ると，US-ASCIIが占める割合は2001年以降は単調現象であるが，ISO-8859-1/CP-1252は2005年あたりをピークに減少しているのが面白い．そのために，どちらもほぼ同時期でUnicodeに抜かれている．
ただし，次の記事の以下の文章は必ずしも正しくないことに注意して欲しい．
ウェブで利用される文字コード、UnicodeがASCIIを上回る--グーグルが明らかに（CNET Japan）

ASCIIと比べたときのUnicodeの短所としては、ローマ字を格納するのに2倍のメモリ容量を必要とする点が上げられる。これはUnicodeがより多くの文字記号に対応するため、文字をより多くのバイト数で表現するためである。

つまり，Unicodeという符号化文字集合（Character Encoding Set）の実際のメモリ表現は，どのような文字符号化スキーム（Character Encoding Scheme）を使用するかによってはじめて決定される．たとえば，UTF-16（Unicode文字を16ビット単位の1〜2文字で表現する）ではASCII文字は2バイトだが，UTF-8(Unicode文字を8ビット単位の1〜4文字で表現する)では1バイトである．つまり，計算コストはまだしも，必ずしもメモリ容量的に不利であるとは限らないのだ．
追記：ちょうど今月の"Communications of the ACM"に"Web Searching in a Multilingual World"という少し関連する内容の解説記事が掲載されていた．この記事によると，2000年から2007年の間にラテン・アメリカのオンライン人口は577.3%，中東は920.2%になっているらしい．また，中国の登録ドメイン数は一年で137.5%になり，現在ではWeb上で2番目によく使われている言語になっているらしい．なお，アラビア語は22か国・2億8400万人で話され，世界で5番目によく使われている言語なのだが，Web上ではまだまだ少なく，わずか1%程度に過ぎないとか．

キーボード配列QWERTYの謎（NTT出版）

ある日，会社の机の上にあった小包を開けると，中に安岡先生のブログを見て興味を持っていたこの本が！…安岡先生，どうもありがとう！！

キーボード配列QWERTYの謎

本書は「QWERTY配列はタイプライターの機械的トラブルを回避するために，意図的に打ちにくいように設計されている」という，未だに信じている人が沢山いるようなまことしやかな嘘がどうして生まれたのか？という謎に，タイプライターの誕生からドキュメンタリータッチで迫っていく本であり，約200ページもあるが，最後まで非常に楽しく読むことができる．
本書では，我々が普段慣れ親しんでいるキーボードについて，以下の重要な事実が明らかにされる．

• キーボードはどのように誕生・発展したのか？
• タッチタイプを始めたのは誰か？
• シフト機構はなぜ生まれたのか？
• どのようにQWERTY配列に統一されていったのか？
• 文字コードはどのように生まれたのか？
• 同じQWERTY配列でも，日本とアメリカで記号の位置が異なるのはなぜか？
• ドボラック配列は本当に効率的なのか？
• なぜコンピュータのキーボードはQWERTY配列なのか？

なお，誕生初期の資料が残っていないキー配列を，残っている手紙のタイプミス（その当時のキーボードは相当打ちにくかったのだと思われる）から推測していたり，QWERTY配列の歴史は，ユーザのものではなく，生産者側の論理による押しつけの歴史であったと最後に結論づけているのは興味深い．参考文献リストが16ページにも渡ることからわかるように，徹底的に証拠を集め，複数の証拠を照合することで，今まで語られていた事柄を客観的に一つづつ検証しており，学術的にも価値があるのだが，コンピュータを日常的に使っている我々なら，読んでいて非常に楽しいし，思いがけない発見が沢山ある．特に，キーボードや文字コードにこだわりを持つ人達は一度読んでみる価値はあるだろう．
私は，本書は同じ著者らによる「文字符号の歴史　欧米と日本編」の続編，つまり一章「電信符号の歴史」の前の章に当たる…つまり，あの本で書き残したことを，本書で書いているのかもしれないと感じた．としたら，あの本の後の話も，きっとそのうち書いて頂ける…と期待するのは酷な要求だろうか？（笑）

文字符号の歴史―欧米と日本編

さて，この種の「嘘」の伝播現象は現在でも見かける．たとえば，最近村田真氏のブログで，OOXMLの標準化に関する報道に誤りがいかに多いかを嘆いているが，私もJavaの標準化で同様な経験をしたことがある．単なる誤解が発端ならまだしも，それ以外の理由から意図的に誤った技術論をいかにも本当であるかのように喧伝する行為はあってはならないし，また我々としては本書の教訓を生かして，そういう行為を発見し，対処していかねばならないだろう．

Ajax IMEに関する補足

さて，先日の報告で私が聞き逃した点に関して，工藤氏にメールで伺ったところ，即座に的確な回答が返ってきた（が，またもや報告が遅れてすまない…）．
基本的には，彼のブログ「きまぐれ日記」の2007年7月8日の記事「AjaxIMEのHTTPサーバは pre-pthread」に簡単な説明が掲載されているとのことである（なお，この時には直前に彼の同僚の高林哲氏のブログの「C++と Pthreads でミニマルなHTTPサーバを書く」という記事が投稿された直後であり，こういう技術的議論がすぐ波及していく会社の雰囲気というのはいかにも活気があっていいよね…）．というわけで，この記事と彼の返事をアーキテクチャ的な観点から簡単にまとめておく．

• HTTPサーバは，事前にスレッドを生成・Mutexを使って排他的にaccept()するタイプの自作の軽量サーバ．
• 仮名漢字変換スレッドは4つ生成しておき，リクエストを取得できたスレッドがそのまま変換処理をおこなう．
• MeCabは同一プロセス内で同一辞書を開く場合に限りmmap()された辞書リソース（70MB程度）を共有することができるので，このスレッド化により辞書を共有しメモリ消費を押さえることができた（現在の運用サーバの実メモリは512MB）．
• HTTPサーバはlocalhostにしかbindせずに，そこにApacheのreverse proxyを用いてアクセスしている．
• 現在の運用状況は2変換/秒で，ロードアベレージも0.02程度．理論的には1,800変換/秒まで耐えれるはず．

大規模テキスト処理を支える形態素解析技術（工藤拓氏・Google）

第80回知識ベースシステム研究会を開催したが，二日間で58名の方々に参加して頂き，積極的に議論に加わって頂いた．この場を借りて，参加してくれた方々に感謝したい．大変遅くなった（爆）が，Googleの工藤拓氏による招待講演「大規模テキスト処理を支える形態素解析技術」の概要を，このブログで報告しておきたい．工藤氏の専門分野は統計的自然言語処理と機械学習であるが，日本語形態素解析エンジンMeCabの開発者であり，他にも自然言語処理関連の有益なツールや，Webベースの日本語入力を可能にするAjax IMEのようなユニークなサービスを提供しているなど，時代をリードする研究開発者の一人である．彼の活動に興味があれば，彼のブログ「きまぐれ日記」は必見だろう．
なお，当日は弊社側の不手際で，予定していた工藤氏の重要なデモをおこなうことができなかった．弊社はネットワーク会社であるにもかかわらず，ネットワーク接続をまともに提供できなかったのは，まさに「紺屋の白袴」であり「汗顔の至り」である．この場を借りて，参加者の皆様に心からお詫びしたい．
また，残念ながら当日発表に用いた資料は公開できないとのことだが，元になった資料が別途JATAから公開されている．残念ながら当日参加できなかった人は，この資料を参考にして頂きたい．

• MeCab　汎用日本語形態素解析エンジン

さて，今回の講演は，前半の形態素解析の技術に関する学術寄りの話と，後半のMeCabを汎用テキスト処理ツールとして使う開発寄りの話の二部構成であった．形態素解析の技術に関しては，彼の出身研究室である松本研では，松本教授が作られたというPrologによるプロトタイプから，Chasen，MeCabなどの実用に耐えるプログラムなど多くの実装が存在し，まさに日本語形態素解析の歴史そのものであると言える．歴史的には，1980年代はヒューリスティクスに基づいていた時代（例，kakasi），1990年代始めは最小コスト法（Viterbiアルゴリズム）の時代（例，juman），1990年代後半は統計処理の時代で，ChaSenが隠れマルコフモデル（HMM, Hidden Markov Model）を，MeCabがCRF（Conditional Random Fields）を用いている．この違いは，HMMは同時確率に基づくので状態が一つしか持てないのに対して，CRFは条件付き確率に基づくので，状態を複数持てることらしい．一言で言えば，HMMは形態素解析を間接的に解いていて，CRFは直接的に解いていることに相当するそうである．
当日は工藤氏からは詳しくは説明されなかったが，MeCabには岡本隆史氏によるJavaへの移植版Sen（と書いて「ちひろ」と読む（笑））が存在する．なお，この改良・派生版としてGoSenがあるが，Senの次期バージョンで統合される予定らしい．
本講演の冒頭で，「MeCabを形態素解析器以外の目的に使っているか？」という質問がおこなわれた（ちなみに，誰も挙手しなかった）ように，工藤氏はMeCabを汎用テキスト処理ツールとして考えて貰いたいようだ．応用例としては，はてなキーワードのように自動的にリンクを張る機能，T9風の予測変換，子音だけによる日本語入力（例えば，東大の田中久美子准教授の研究が参考になるかもしれない），ルー語変換，辞書の素性を活用する例などが，デモと共に紹介された．このデモの中には，残念ながら実用には耐えないものもあったが，有益なアルゴリズムを実装したソフトウェアを汎用に実装すれば，さまざまな分野に応用できるという可能性を示していた．
なお，質疑応答に関しては，みなさん遠慮しているのか質問をされる人が少なく，どうも私の一人舞台となった感がある（苦笑）ここで，その質問のうち，覚えているものをまとめておこう．

• 「MeCabがトリプルライセンスになったのは，Apple Computerからの要求であったと，エンジニアの木田泰夫氏（Mac OS Xのことえり，日本語形態素解析エンジン，ヒラギノフォントなどの開発エンジニア）から聞いているが，一体どこに使われているのか？」→「知らない」そこで，木田氏に突撃取材を試みたところ，「MeCabはSpotlight用（！）の日本語と中国語（！！）の解析に使用している．実は，まだ工藤さんには言ってない（！！！）ので，ブログは言った後に書いてね（←義兄ながら本当にひどい奴だ（苦笑））．」ということであった．そう言えば，以前に「工藤さんは凄いプログラマだ．MeCabはアップルで作った日本語形態素解析エンジンより，遙かに素晴らしい．」とベタ褒めしていたので，自社のコードから乗り換えたのかもしれない．
• 「Mac OS X 10.5では，入力された日本語ユーザ名のローマ字表記を用いてホストの識別子を自動生成するために，どうも日本語形態素解析を利用しているようである．このような使い方というのは，よくあるのか？」→「あまり聞かない」ただ，日本人にとって理解しやすい識別子を，どんな文字でも受け付けるように仕様や実装を変更する（例えば国際化ドメイン的アプローチ…これは非常にコストと時間が掛かる）のではなく，日本語をローマ字変換することで実現するのは，妥当で便利な方法だと思う．
• 「AJAX IMEはどのようなアーキテクチャになっているのか？」→「説明しようと思っていたけど，ネットワークが繋がらないから…」すまない（爆）…ただ，ということは，どこかネットワークから見えるところにアーキテクチャ図か説明はあるのかな？（←聞いておかねば…→追記：彼の回答をまとめてみた）
• 「AJAX IMEのユーザ操作履歴は何に使っているのか？」→「まだ使っていない．」ただ，ユーザがしっかり付いているようなので，結構なログは貯まるはずなので，そのうち工藤氏ならではの有益な使い方をしてくれることを期待したい．
• 「大規模日本語n-gramデータを公開した経緯は？」→「2007年3月にある大学の先生のところに伺って雑談していた時にそういう話になり，急遽言語処理学会の全国大会で特別セッションをすることになった．」まさか，そんな急に進んだ話だとは思わなかった．
• 「日本語n-gramデータの作成方法は？どこが大変だったのか？」→「特に大変ではなかった．Googleではサードパーティのライブラリを置けるディレクトリがあるので，そこにMeCabのプログラムと辞書をインストールしておいて，あとはMapReduceのプログラムを書いてGoogleの巨大な計算機クラスタで処理した．約一日ぐらいで，日本語形態素解析そのものには，あまり時間が掛かっていない．」（詳しくはGoogle Japanのオフィシャルブログの記事を見て頂きたい）実は，講演の冒頭で「講演名に「大規模テキスト処理を支える」と付いていますが，今日はあまり関係のない話をします．」と言っていたのだが，ここで私はようやく自分の勘違いに気が付いた．現在，学会に行くと，この手のテキスト処理に数日〜数十日掛かったとか，大変という話を聞くことが多いのだが，彼らにとっては何も大変じゃないのだ…そもそもスタートポイントが違うのである．当日工藤氏に聞いても知らなかったのだが，実はGoogleやIBMがアメリカの大学に大規模クラスタ環境を提供する話がある．今後，このスタートポイントが違うという点は，日米の大学のレベルや技術格差に大きな影響を与えそうだ．
• 「新たに未知語を追加登録した辞書を使いたい場合に，今回作成したような日本語n-gramデータはそのままでは使えないと思うが，何とかならないだろうか？」→「辞書が違うと難しい．最初から作り直すしかないが，それは（工藤氏にとっては）難しくはない．」なお，MeCabには未知語処理をする機能が追加されているのだが，結局擬似単語生成をしても99%以上は無駄なので，現在は品詞だけしか推定していないそうである．

なお，工藤氏は講演中で「Webをgrepする」という印象的な表現を何度も使っていた．「現在Webを簡単にgrepできる人は限られているが，もし日本語n-gramデータの提供のように，技術の発展に役立つような有益なアイデアがあれば，前向きに検討したいので，一度相談して欲しい．」と言って頂いた．我々としても，ぜひ良いアイデアを考えて提案し，一緒に技術を発展させて行きたいと思う．
最後に，本研究会の私の幹事としての任期は四年…つまり残りは二年あり，来年も同種の特集テーマで発表を募集したり，有益な招待講演をおこなうことを予定しているので，来年も発表や聴講を検討して頂きたい．また，「こんなことやりましょうよ！」という提案も歓迎である．では，来年もよろしく！

第80回人工知能学会 知識ベースシステム研究会 (SIG-KBS)発表募集

来年の1/15(火)〜16(水)に，NTT武蔵野研究開発センターで，人工知能学会 知識ベースシステム研究会を開催する予定である．
第80回 人工知能学会 知識ベースシステム研究会 (SIG-KBS)
なお今年も「Web情報処理」というテーマで，特にWeb上の情報の処理に関する論文を特集する予定である．たとえば，非常に膨大で，多様であるという特徴を持つWeb上の情報を扱うことの利点や問題点，またハイパーリンク，トラックバック，ソーシャルブックマークなどの不特定多数のユーザによって作られたネットワーク構造をどのように利用するかなどについて議論できたら幸いである．
さらに，昨年度の東大の豊田正史准教授の招待講演に引き続き，今年はGoogleの工藤拓氏に「大規模テキスト処理を支える形態素解析技術」という講演をして頂くようにお願いした．Google，Yahoo!，Microsoftなどの，すでに膨大な情報を扱うインフラを提供している企業に対して，大学では必ずしも充分なインフラを確保できているとは限らず，またその多様さゆえに起こる問題を結局力業でやってしまっていることも多く，様々な悩みを抱えている人は多いように思う．そこで今回は，工藤氏が開発している日本語形態素解析エンジンであるMeCabによる大規模テキスト処理などの試みについて話して貰うようにお願いした．なお，Google社の公式プロジェクトではなく，わざわざ彼の個人的なプロジェクトの方をお願いしたのは，その方が細かい処理や具体的な問題点や実装について忌憚なく議論できるだろうという私の目論見である．
もし，ここを読んでいる関連分野の研究者がいたら，ぜひ投稿・参加を検討して頂くようにお願いしたい．

Fonts & Encodings（Oreilly & Associates, Inc）

オライリージャパンの某編集者に，今度こういう書籍が出たんですけど…と，次の本を献本して頂いた．

Fonts & Encodings: From Advanced Typography to Unicode and Everything in Between

作者のYannis Haralambousはギリシャ人で，原著「Fontes & codages」はフランス語で書かれていた．この本は，P. Scott Horneが翻訳した英語版であり，1000ページを少し越え．約1100ページの「CJKV Information Processing」と並ぶ大作である．原著がフランス語ということで，購入に二の足を踏んでいた人も多かったようだが，これで心おきなく買えると思う．なお，本書の表紙の動物は「鹿」である（Amazonでは青色の表紙だが，私が持っているのは赤色である…なぜ違うんだろう？←追記：Amazonには書籍発行の数ヶ月前に表紙カバーデータを送ってプロモーションするのだが，本書はその際はXML関連書籍と同じカテゴリだったので緑色だったのだが，発刊間近にやはりCJKVやUnicode Explainedと同じカテゴリの赤色に変更されたらしい）．
詳しい内容は，オライリーのサイトを見て頂きたいが，文字コードやUnicodeの話から始まり，Macintosh，Windows，X Window，TeX，Webページなどの各環境におけるフォントの話や，英文書体の歴史や分類，フォント関連ツールなどにも言及し，各フォントフォーマットが付録に付く，非常に資料性の高い一冊である．
残念ながら日本語訳の可能性はあまりないように思う．というのは，まずこの出版業界が不景気な時に分厚い翻訳を出しにくいということと，「CJKV日中韓越情報処理」と異なり，日本固有の記述が少ないために，日本語に訳したからと言って売り上げが伸びるとは思えないからである．ただ，この分野の人達は資料として一冊持っておきたいと思うかもしれない．
なお，ざっと目を通した時に，本書の55ページの「Philosophical issues: characters and glyphs」という節で，花園大学の師 茂樹さんの"Surface or Essence: Beyond Character Model Set"（邦題は「表層か本質か　―符号化文字集合モデルの限界とその克服―」）という論文が引用されているのを見つけた．この論文は，京大の守岡さんが開催した書体・組版ワークショップで発表されたものであり，著者も「Using OpenType-based Fonts with Omega」という発表をされていたようである．興味があれば，師さんのブログも見て頂きたい．

NIO.2関連記事

少し忙しかったので翻訳や紹介が遅れてしまったが，NIO.2関連記事を紹介しておこう．
【コラム】Java API、使ってますか?(11) "NIO.2"がやってきた - JSR 203: More New I/O APIs for the Java Platform
なお，仕様リードのAlan Batemanからも「Google alertsが教えてくれたけど，これって私達のJSRの紹介記事？」という問い合わせが来たので，そうだと言ったら，Google translationで英語に翻訳して読んでくれたようで，"It looked to be a good summary."だそうである．