絵文字を「符号」として処理する難しさ～日本のモバイルウェブのカオスぶり

●バイドゥだけが開発に成功した、絵文字の意味検索

　Baidu（バイドゥ）はGoogle、Yahoo!に続く世界第3位の市場占有率[*1]を持つウェブ検索の会社だ。上位の会社に比べればなじみは薄いかもしれないが、中国で設立されたのが2000年、NASDAQ市場に上場したのが2005年だから、この業界では堂々たるベテランだ。

　そのバイドゥが日本に進出、ウェブ検索を提供開始したのは2年ほど前のこと。そして2009年9月には携帯電話を対象としたモバイル検索を開始した[*2]。注目すべきは、ここで絵文字による検索を可能にしていることだ。これについてINTERNET Watchでも何度か報じてきた。

　不思議なことに絵文字の検索は、GoogleやYahoo!をはじめどこでも無視されてきた。しかし日本の携帯電話は、契約ベースで1億1000万台[*3]を超える。そのほとんどに絵文字が実装されていることを考えると、バイドゥが絵文字を検索可能にした意義はきわめて大きい。

　ここでいう絵文字の検索とは、例えば＜ビールジョッキの形をした絵文字＞と「渋谷」という語を入力すれば、「渋谷でビールが飲める店」を一覧表示してくれるというようなことだ（写真1、2）。絵文字の持つ「意味」を踏まえた検索、つまり「絵文字の意味検索」だ。

写真1　絵文字によるモバイル検索（バイドゥ）。＜ビールジョッキの形をした絵文字＞を含むページがヒットしている。それだけでなく「ビール」「飲む」といった語では検索していないのにもかかわらず、そうした意味を持つページが上位にランクされている（使用機種：KDDI W56T）	写真2　絵文字によるモバイル検索（EZwebのトップ画面。検索エンジンはグーグル）。絵文字を使って検索したにもかかわらず、単に「渋谷」の検索結果が表示されている（使用機種：KDDI W56T）

　どのような技術を使うと＜ビールジョッキの形をした絵文字＞を「ビール」「飲む」などの単語と同様に扱えるようになるのだろう？　そこでバイドゥによるモバイル検索の開発過程を3回に分けて追ってみたい。取材に応じてくれたのは、同社プロダクト事業部の水野貴明、前川英之、それに萩原正人の各氏だ。

●絵文字に対応した検索エンジンの作り方

　絵文字の意味検索はチャレンジの連続だった。その中でも大きな壁は2つ。1つは絵文字を「符号」として処理する難しさ、もう1つは絵文字を「語」として処理する難しさだ。今回はそのうち前者を説明する。

　ごく大ざっぱに言って、検索エンジンの作成は、1）データの収集（クロール）、2）インデックスファイルの作成（索引化）、3）サーチフロントエンドの構築（ユーザーが望むであろう検索結果の表示）――の3段階に分かれる。携帯電話のウェブ（以下、モバイルウェブ）用の検索エンジンであっても、HTTPプロトコルが使われている以上、作成過程は変わらない。

　バイドゥがモバイル用の検索エンジンの開発をすることを決定したのは2009年初めのこと。実際にクローラーと呼ばれる収集プログラムが巡回を開始したのは同年4月だ（前述の1の段階）。

　このクローラーが集めてきた膨大なデータ（HTML）が、2）のインデックスファイルの材料となる。ここでいうインデックスファイルとは、さまざまな語とその語が記述されたページの情報とを結び付けたものだ。百科事典の索引（インデックス）を思い浮かべればよい。ごく単純化すると、検索エンジンとは、ユーザーが入力した語に対し、インデックスファイルを参照して、これと一致する語が含まれるページの情報を一覧表示するものだ。

　絵文字をこのインデックスファイルにうまく収納してやれば、絵文字の検索エンジンは半分以上は完成したと言える（インデックス化）。ところがここで日本の携帯絵文字に特有の問題が立ちはだかる。日本の絵文字は、通常の意味で符号処理できるようにはなっていない。だからインデックス化の前に、まず符号として扱うことができるように変換する必要がある。では、絵文字の何が符号処理を難しくしているのだろう？

●絵文字を符号として処理する方法とは？

　まず、絵文字はキャリアによって符号位置が違う。関連して、これは符号処理とは別問題だが、文字名やデザインも一見同じように見えて微妙に異なるものが多い（図1）。

図1　キャリアによって符号位置、デザイン、文字名が異なる絵文字。同じような絵文字なのに、キャリアによってすべて符号位置が違う。さらに上段では、文字名がドコモ、ソフトバンクは「Phone to」（電話をかける）なのに対し、KDDIは反対の「終了」になっている。下段ではデザインがKDDIとソフトバンクは「ラーメン」で麺が見えるのに対し、ドコモは中味の見えない「どんぶり」で、丼物全体を包摂すると考えられる。なお、符号位置はすべてシフトJIS

　さらに日本の携帯電話では、キャリアが異なっても絵文字を含んだメールのやり取りができる「相互変換サービス」が提供されているが、そこできわめて複雑な対応が定められている。情報交換では往復の対応だけなのが大原則だが、片道の、しかも1対多の対応を定めている。さらに文字列に対応させる場合まである（図2）。

図2　携帯絵文字におけるキャリアごとの複雑な対応の例。本来は情報処理において往復2回の情報交換をしても符号が変わらないのが大原則（往復の対応）。ところが相互変換サービスでは、往復の対応以外に片道の対応が定められている。その結果、KDDI「熱」は、ソフトバンク→ドコモ→ソフトバンク／KDDI→ドコモの順で情報交換をした場合、最後は正反対の「ほっとした顔」に化けてしまう。一方、ドコモは、KDDI「熱」に似た絵文字を持たないので、窮余の策として片道の対応で「熱」という文字に対応させている

　このような状況の中で、絵文字を符号として処理するにはどうすればよいのか。水野氏は言う。

　「各社の絵文字を、1つの符号体系に変換してあげればいいわけです。変換ルールは、グーグルさんがオープンソースで公開を始めていた『emoji4unicode』[*4]をベースにしました。当時まだドラフトだったと思いますが、3社間の対応がきちんとできていて、我々にとってそれが重要でした。このルールに従って絵文字を1個1個の符号として扱えるようにしました。」

　つまりバイドゥ独自の内部コードに変換することで、符号としての処理を可能にしたということだ。ところで、emoji4unicodeはキャリア各社の絵文字とUnicodeとの対応を定めたものだ。ということは、この内部コードはUnicodeとは違うものなのだろうか？

　「いえ、Unicodeのコードポイントとして扱うのでなく、emoji4unicodeのルールに従って内部コードに変換して使ったということです。なので、Unicodeでどこにマッピングされているかは、あまり関係ない。」

　なるほど、内部コードはUnicodeとは別物。そして、すべての文字をこの内部コードに変換してインデックスファイルに収納しているが、そのうち絵文字に関してだけは、emoji4unicodeの対応ルールを流用して変換することにしたということだ。

●符号化方法の判別から見えてくる、モバイルウェブの現実

　絵文字の変換ルールが決まったら、いよいよ符号処理だ。インデックスファイルを構築するにあたり、必要になる処理は、a）符号化方法の判別、b）絵文字のキャリア判別――の2つ。このうち、b）がモバイルウェブを対象とした場合特有のものだが、その前にまず、a）から説明しよう。

　クローラーが集めてきたデータは、ページごとに分かれてはいても中味はただ符号が並んでいるだけにすぎない。そのままでは、その符号がどういう文字を表しているのすら分からない。

　符号と文字の対応を決めたものが符号化方法（文字コード）だ。多くの場合、モバイルウェブの符号化方法はシフトJISかUTF-8のいずれかだが、そのどちらなのか、あるいは全く別の符号化方法なのかを判別しないと、この先の処理ができない。ところが、ここで日本のモバイルウェブ特有の事情が立ちはだかる。水野氏は続ける。

　「ウェブの標準では、コンテンツの符号化方法はHTTPのヘッダや、HTMLのメタ要素で指定することになっています。だからこれらを参照すれば、そのページの符号化方法は分かるはずです。ところが間違っていることがけっこう多い。なのに実機（携帯電話）ではちゃんと見えちゃったりする。一筋縄ではいかない世界です。」

　例えばHTTPのヘッダでシフトJISが指定されているにもかかわらず、実際のデータはUTF-8で符号化されていることがある（図3）。意外なことにページビューが比較的多いサイトでも、そうしたページが見られたりする。

図3　HTTPのヘッダでシフトJISが指定されているにもかかわらず、実際のデータはUTF-8で作成されているモバイルページの例。Firefoxでモバイルページをシミュレートできるアドオン『FireMobileSimulator』[*5]を使用して、問題のページ（1）とそのソース画面（2）を表示、同時にソースファイルをバイナリエディタに読み込んだ（3）。ソース画面を見ると、HTTPのヘッダでシフトJIS（Shift_JIS）を指定してある（4）。ところがこのページにある「無」という文字をバイナリエディタで探すと、シフトJISならば「96 B3」という符号の並びであるはずが、UTF-8である「E7 84 A1」になっている（5）～（8）

　このようにHTTPヘッダの情報を鵜呑みにできないので、データそのものから判定する必要がある。前述したようにモバイルウェブでは、大半がシフトJISかUTF-8のいずれかだ。符号化方法の判別方法はいくつかあるが、最もよく知られているのは、文字の使用頻度の偏差を利用するものだ。

　例えばUTF-8で符号化すると、日本語文で使われるカタカナ、ひらがな、漢字は3バイトになるが、その第1バイトは必ず16進表記で「E0～EF」の範囲になる。一方でシフトJISでもこの範囲が符号として使われるが、これは使用頻度の低いJIS X 0208の第2水準にあたる（シフトJISでは0xE040～0xEAA4の範囲）。そこで符号の並びに「E0～EF」が頻繁に現れた場合、まずUTF-8だろうということになる。

　もっとも、どんな方法でも判別できないページが存在するのが、モバイルウェブの現実でもある。例えば1つのページに複数の符号化方法が使われているようなページ。この場合、もちろんブラウザーはまともに表示ができない（図4）。

図4　1つのページに複数の符号化方法が使われているページの例（FireMobileSimulatorによりKDDI W56Tの表示をシミュレート）

　こうした現象はウェブサイトを総合的に管理・運営できるコンテンツマネジメントシステム（CMS）を使って、自動生成されたコンテンツをページの一部分に当てはめる作り方をした場合に起きるようだ。こうしたシステムではPC用ページと同時にモバイル用ページも吐き出すものが多い。そこで管理者が符号化方法の適切な変換の設定をしなかったり、あるいはシステムのバグによって、自動生成した部分だけが文字化けしたりしてしまう。ところが、すべてのウェブサイトがモバイル用を想定しているわけではないので、管理者がこうした現象を見逃してしまったりする。

　「まあ、あまり大きいサイトだと、こちらから化けてますよと連絡してあげることもあります。どっちかというと、自分達のインデックスをきれいにしたいだけなんですけど（笑）。」

　少し話はそれるが、こうして彼等の話を聞いていると、検索エンジンの開発者というのは、インターネットのあらゆる矛盾を肌で知っているように思えてくる。

　「まあ、我々は人が作ったウェブページを収集してくる立場なので、さまざまな状況を考慮しなければならないんですよ。逆にコンテンツプロバイダーのように自分で作ったページを公開する立場だったら、自分で符号化方法を選んで作ればいいんですから、我々のように矛盾ばかり見えないでしょう。それにウェブって、大ざっぱさが発展のキーになっている部分があるんで、あまり口うるさいことを言っているように思ってほしくないんです。やっぱり“集めさせてもらっている”立場ですから。」

●全部で18種類ある絵文字の表現方法

　ここまでで符号化方法の判別が終わった。これがPC用の検索エンジンであれば、ただちにインデックスファイルの作成に進ことができる。ところがモバイルウェブを対象とした場合、もう一手間が必要となる。ページの中で使われている絵文字が、どこのキャリアのものなのかを判別しないといけない（前述b）。

　絵文字に割り当てられている符号化領域（コードレンジ）そのものは、それぞれシフトJISでもUTF-8でも一定だ。これはキャリアによっても変わることはない。だから絵文字であること自体は、符号化方法さえ分かればコードレンジで見分けられる。

　しかし、こうした公開資料から分かることだけでは済まないのがモバイルウェブの世界だ。じつは1つの絵文字を表す表現方法が、公開されている仕様以外に、何通りも種類があるのだった（図5）。

図5　「太陽」を表すさまざまな表現方法。3キャリア全部合わせると18通りもある！

　もともと絵文字にはシフトJIS、UTF-8の符号位置の他に、数値文字参照による表現方法が用意されているのだが、ドコモとKDDIはこの数値文字参照の数値部分をシフトJISの符号位置（！）を書く記法を追加している[*6]。さらにKDDIは数値文字参照の記法としてUnicodeとシフトJISのそれぞれに10進法と16進法を許し、その上IMG要素による表現が2種類、加えてUTF-8の符号位置が正規以外に「裏KDDI Unicode」と呼ばれるものまである[*7]。こうしてKDDIにおける絵文字の表現方法は、全部合わてなんと8種類に上る。他にもソフトバンクではウェブコードと称する独自のエスケープシーケンス（！）を使った表現方法が規定されている[*8]。

　当然ながら（？）こうした情報はすべてが公開されているわけではない。この部分を担当した水野氏は、実態を把握するまで非常に苦労したようだ。前川氏が語る。

　「クロールを開始する前から、ある程度は水野が知識を持っていたので、複雑だろうとは想定していました。ところが集めてみたら、ルールに合わないようなウェブページが出てきて……。」

　水野氏が続ける。

　「もう泣きながらやりました。思ったよりもカオスでした。情報があまりないので、なかなか最適に変換してくれなくて。符号化方法の指定もそうなんですが、携帯ならではという間違い方が多い。そういうのをきちんとすり抜けてあげないと。」

●キャリアが違うのに符号位置が同じ絵文字の処理

　水野氏の苦労の甲斐あって、文書化されていない情報を含めて1文字ごとの表現方法が分かってきた。これさえ分かればキャリアも判別できる。ところがまだ問題が続く。

　「それぞれの表現方法の内部で、キャリア同士が少しずつ重なっているんです。ある程度考慮して若干ずらしてくれていたりするんですが、どこかしら重なっている。公開資料から分かってはいたんですが、判別は苦労しました。」（水野氏）

　符号位置が分かればどこのキャリアの絵文字か判別できる。しかしキャリア同士で符号位置が重複してしまうと、それだけではどちらのキャリアが判別不可能になる。

　例えばドコモの「1」を表す絵文字は、シフトJISでは0xF987だが、ソフトバンクの「ケーキ」を表す絵文字もシフトJISの同じ符号位置だ（図6）。0xF987という符号をシフトJISで復号すると、ドコモの「1」にもソフトバンクの「ケーキ」にもなりうることになる。

図6　キャリア公式情報に見る符号位置の重複。左はドコモ『基本絵文字』（http://www.nttdocomo.co.jp/service/imode/make/content/pictograph/basic/）、右はソフトバンク『ウェブコンテンツ開発ガイド HTML編 ver. 2.0.2』P.212。赤枠内のシフトJISの符号位置が重複していることが分かる

　とはいえ、たいていの場合は他の重複していない絵文字の符号位置を調べれば、キャリアの判別はできる。しかし、もしもそのページに重複した絵文字しか存在しなければ、判別の手がかりがなくなってしまう。

　この場合、例えばドコモの「1」とソフトバンクの「ケーキ」ならば、前者はメニュー等でよく使われることから圧倒的に使用頻度が多い。そこでこれをドコモとするというように、「絵文字の使われやすさ」を考慮に入れて判別していった。

　これでようやく、ある符号がどこのキャリアの何という絵文字かが確定できるようになった。キャリアが分かったら、最初の方で述べたようにemoji4unicodeの対応ルールに基づき内部コードに変換していく。

　しかしここまで説明した作業は、まだインデックスファイルを作る準備が終わった段階にすぎない。冒頭で「絵文字の意味検索」とは、絵文字の持つ「意味」を踏まえた検索だと書いた。ではバイドゥは、絵文字の持つ「意味」を、どのようにして解析していったのだろう？　それこそが絵文字を「語」として処理する難しさだ。どうか次回をお楽しみに。

●注釈