これからの絵文字の実装指針、UTR #51“Unicode Emoji”とはなにか

1）絵文字の主な出典が、日本の携帯電話に由来する

　これも後述するように、Uniccodeに収録されている絵文字の出典は多様だ（図1）。ただし、そのうち最も主要なものは2000年のドコモiモードに始まる日本の携帯絵文字だ。

図1　Unicodeに収録されている絵文字の出典（UTR #51より作成）

　当時、キャリア3社は絵文字をインフラというより機能ととらえ、ユーザー囲い込みのため勝手な拡張を繰り返したので、雑多で日本の文化だけに依存したレパートリとなった。こうした日本人以外には意味の分からない絵文字が、実装の障壁となっている。例えば昨年、以下のような記事が話題となった。

　かねてチューリップ型名札の絵文字「」（U+1F4DB NAME BADGE）が何なのか不審に思っていたアメリカ人が、来日時に実物を目前にして「見つけた！」と写真入りでツイート。するとフォロワーのドイツ人が、冗談だろうが「それはどこでも見られる“燃える豆腐”（tofu on fire）だ」ともっともらしく切り返す。そんなやり取りと、日本のネットユーザーの反応を紹介する記事だった。

　この記事で分かるように、日本人以外にとって絵文字はエキゾチシズムの対象だ。適切な情報提供がなければ、想定外のデザインで実装されるなど、情報交換に支障をきたすおそれがある。そこで制定者による中立的な実装指針が必要になった。

2）カラーフォントが普及した

　よく知られているとおり、絵文字は日本以外でも日常的に使われている。普及の先兵は、なんといってもAppleのiPhoneだ。同製品は日本での発売開始の4カ月後、2008年11月に配布を開始したiOS 2.2から、ソフトバンクの携帯電話と互換をとるためにカラーの絵文字フォントをサポートしてきた[*5]。ただしこの当時、Unicode既収録の絵文字（後述）以外の携帯独自の絵文字については、基本的に外字領域を割り当てていた。これは他プラットフォームとの情報交換に制限があり、間に合わせの実装だったともいえる。

　外字領域を使った実装に限界を感じていたのは、Gmailで携帯絵文字への対応を進めていたGoogleも同じだった。こうした状況を変えようと、彼等は2007年から日本の携帯絵文字をUnicideに収録する提案活動を始める[*6][*7]。これにAppleも合流し、2010年10月、Unicode 6.0で携帯絵文字が収録されるのである。

　これを受けて、AppleはさっそくiOS 4.3以降のカラー絵文字フォントで、それまでの外字領域とあわせて正規のUnicode符号位置もサポートするようになる。ただし、この段階のレパートリはソフトバンクの絵文字の範囲に限定されていた[*8]。

　これがドコモ／auの絵文字の範囲までサポートするようになるのが翌2011年10月のiOS 5だ[*9]。ただし、まだこの時点ではドコモ／auの絵文字はモノクロ表示だった。これらがすべてカラーになり、加えて日本の携帯絵文字以外のUnicode絵文字まで収録を完了するのは、2012年3月のiOS 5.1まで待たねばならない[*10]。

　少し話はそれるが、ここで重要なのは、iOS 5.1で従来日本語専用だった絵文字の入力キーボードを、他の言語でも使えるようにしたことだ[*11]。現在のように世界中で絵文字が広く使われるようになった状況はここから始まる。

　話を戻そう。こうしたカラーフォントへの絵文字実装は、以前からUnicodeに収録されていたシンボル類との区別を難しくすることになった。例えば以下を見てほしい。これはUTR #51で公開されているデータファイルの1つで、絵文字の実装一覧表だ[*12]。

図2　♨（U+2668 HOT SPRINGS）、☎（U+260E BLACK TELEPHONE）の実装状況（UTR #51より）

　「♨」「☎」はどちらも1993年のUnicode 1.1から収録されているシンボルだ。ところが携帯絵文字もこれをレパートリにしている。つまり、従来どおりモノクロのテキストとして表示される場合と、カラーフォントで絵文字として表示される場合の2通りがありうるわけだ。この切り換えを解決する技術、それも排他的ではない、誰でも実装可能なガイドラインが必要となった。

3）絵文字の表語性がスマホにマッチした

　ところで、なぜ日本以外で絵文字が愛用されるようになったのだろう。これは海外、特に表音文字（アルファベット）圏のユーザーを見て感じることだが、絵文字の持つ表語文字（1つの文字が1語を表す）のはたらきが彼等には新鮮に映っているようだ。例えば、Twitterでハッシュタグ「#emojiparty」を検索すると、簡単に以下のようなツイートが見つかる[*13]。

　ムリヤリ和訳すると「飛行機は帰ります。いつだって太陽と波が打ち寄せるロサンジェルス（？）へ。」という感じだろうか。飛行機を表すのに英語なら「p l a n e」と5回キーを押さねばならないが、絵文字なら「✈️」1回で済む。こうした絵文字の持つ「筆記の経済性」が、入力しづらいスマートフォンで歓迎され、多くのユーザーを惹きつけることとなった。

　しかし、絵文字を表語文字として適切に機能させるためには、絵文字はどの語に対応するかについて共通の指針が必要だ。また、カラー化にあたっては規格にあるモノクロの例示字形をどの程度参考にすべきか、共通の指針が必要になるだろう。

4）Apple副社長が絵文字の改善を約束した

　特にアメリカにおいて、黒い肌の絵文字がないことに不満が広がった件については、すでに以下の記事で報じている。

　ここで重要なことは、iPhoneの製造元であるAppleの副社長が、Unicodeコンソーシアムの名前を出した上で、以下のような約束をしていることだ。

　AppleはUnicodeコンソーシアム創設以来の有力な会員企業だ。この「約束」は多くのメディアが報じるところとなり、世界中に広まった。こうして同コンソーシアムは、なにがなんでもこの問題への対処をしなければならなくなった。UTR #51のうちいくつかの節は、これを解決するために書かれている。

A）絵文字実装のゴールは埋め込み画像（8 Longer Term Solutions）

　UTR #51の中程に、すべての前提となるような重要な項目が埋もれている。以下の一文だ。

　つまり、より長期的な絵文字における実装のゴールは、文字コードではなく埋め込み画像だと述べている。この方法によれば、Unicodeにおいて無制限に絵文字を追加することは避けられる。

　この埋め込み画像とは、例えば従来型携帯電話のデコメや、Skype、メッセンジャーなどで使われているものだ。すでに確立した技術であり、標準としてもHTMLのimg要素、情報交換用のファイルフォーマットとしてBASE64等がある。

　ただしこれまで埋め込み画像は、主要なOSやプラットフォームでは、ユーザーが絵文字と同じように入力できるようなサービスは存在しなかった。ところがLINEが自社テキストチャットサービスにおいて、「スタンプ」を始めてから状況が変わる。当初は標準のスタンプだけだったが、2014年にユーザーが自作スタンプを売買できる「LINE Creators Market」を創設したことで、世界的なブレイクに至ったことは承知の通り[*16]。

　ここで重要なことは、UTR #51の著者がGoogleとAppleで幹部クラスのエンジニアであることだ。実装指針というUTR #51の性質や、ここで詳述しないが、比較的踏み込んだ実装方法まで検討されていることも考えると、近い将来、iOS/OS XやAndroidで、埋め込み画像が実装される可能性は十分にあると考えられる。

B）デザインの指針（2 Design Guidelines）

　UTR #51の中で主要項目の1つだ。絵文字の実装に当たっては、規定された「コアな形状」を維持しなければ、情報交換に支障をきたしてしまう。そのためのガイドラインだ。

図3　絵文字における「コア」な形状

　上は4つの絵文字について、ぞれぞれ4つのデザイン例を示している。これを見ると、符号位置は同じでも、カラーで実装したものがあれば、モノクロもある。そしてケーキの苺の数やプリンの皿の色等、細部のデザインも異なる。しかし、違いはあっても、それぞれ「ロリポップキャンディ」「プリン」「蜂蜜壺」「ショートケーキ」と一目で分かる。これが「コアな形状」だ。一方で、もし「蜂蜜壺」と同じ「甘いもの」だからといって「角砂糖」として描くと、相互運用性に支障が出る。つまり「角砂糖」は「蜂蜜壺」の「コアな形状」から逸脱しているわけだ。

　また、民族多様化（diversity）と社会的性差（gender）に関しては、できるだけ中立であるべきとされている。例えば「U+1F477 construction worker（建設労働者）」は男女どちらでもよいし、「U+1F64B happy person raising one hand（片手を挙げる幸せな人）」のように文字名に性別が明記されていないものは、性差が分からないニュートラルな画像にするよう勧められている。

　先述した黒い肌の絵文字の問題も、デザイン（外見）に関することとして、この節で説明される（2.2 Diversity）。基本的な内容は、上述の拙稿『絵文字に平等をサポートしてください』での説明から大きくは変っていない。まず、あらかじめ淡い色調から濃い色調まで、5種の肌を表す不可視の修飾子を定義する。

図4　肌の色調を表す5種の修飾子

　これを顔や人体を表す絵文字の直後に置くことで、その絵文字の肌の色調を変化させる。

図5　肌の色調を変化させる仕組み。顔の絵文字の直後に修飾子が置かれることで、1つの文字に合成され濃い肌の絵文字になる

　さらにUTR #51では、修飾子の合成対象が2つのグループに分け定義されている。27文字からなる必須のミニマルセットと、102文字からなる選択的なオプショナルセットだ。個別の文字が掲載された表は、原文「2.2.1 Implementations」を参照してほしい。

　ところで前掲の拙稿『どんな人々がUnicodeの絵文字に「民族の多様性」を求めているのか？』の末尾で、肌の色だけでなく髪の色や目の色は変更しなくてよいのかと疑問を述べた。じつはその回答もこの節にある。人間のあらゆる外見を表示し分けることは、Unicodeのスコープ（適合範囲／目的）ではないので、そうした需要は前述の埋め込み画像のサポートで達成すべき、そのように書いてある。

C）表示のスタイル（4 Presentation Style）

　これは先述 2）で書いた問題、つまりカラーとモノクロの表示し分けるための技術だ。そのために、Unicodeは「Standardized Variants」[*17]という枠組みを使って、2種のバリエーションセレクタ（字形選択子）を登録している。

• U+FE0E for a text presentation（テキスト表示のためのU+FE0E）
• U+FE0F for an emoji presentation（絵文字表示のためのU+FE0F）

　これは不可視の文字であり、特定の絵文字の直後に置かれることで、強制的にU+FE0Eならモノクロ表示、U+FE0Fならカラー表示にする。合成することで任意の外見に変えるという意味では、前項で述べた修飾子と似ている。

　図1、図2にあるような、Unicode 6.0よりも前に収録されていた絵文字で、かつ日本の携帯絵文字にも含まれていた絵文字は、たとえばiPhone／iPadではiOS7、OS Xでは10.9以降では、入力の際に（大方の人は気づいてないだろうが）自動的にこのバリエーション・セレクタが同時に入力されている。

　これらバリエーション・セレクタによって実装者の混乱をまねかないよう、UTR #51ではUnicodeに収録された全ての文字について、3種類の「デフォルトの文字表示」を定義している。

• emoji-default　デフォルトはカラー表示だが、モノクロもありえる
• text-default　デフォルトはモノクロ表示だが、カラーもありえる
• text-only　モノクロのみでカラーはありえない

　個別の文字の定義は、UTR #51のデータファイル「Draft Emoji Data (Full)」のカラム「Default」を確認してほしい（[*11]として前掲）。そして、このファイルにないUnicodeの文字は、すべて3番目の「text-only」となっている。

D）照合順番とグルーピング（5 Ordering and Grouping）

　雑多なレパートリである絵文字は、既成の照合順番では適切にソートできない。より自然なソート結果（並び）と同時に、絵文字をグループ分けするために作られたのが、データファイル「emoji-ordering」だ[*18]。

E）入力（6 Input）

　この節では、「あるべき絵文字キーボードの実装方法」について書かれている。入力で必要となるのは、絵文字1文字ごとの注釈（annotation）だ。例えば、U+23F3「」の正式な文字名は「HOURGLASS WITH FLOWING SAND」という長ったらしいものだが、スマートフォンで入力するのに、いちいち長い文字名を入力させるわけにはいかない。英語なら「clock / hourglass」等で変換されるようにすべきだ。つまり、絵文字の「意味／派生イメージ」にあたる語なのだが、これが注釈だ。

F）検索（7 Searching）

　前項の注釈を検索に使うと、新しい表語文字としての絵文字のメリットが発揮できる。例えばウェブ検索のキーワードとして、たった1文字「」を入力するだけで、時計に関する検索結果が返ってくる「絵文字検索」が考えられる。そこでは絵文字を注釈に置き換え、これを検索語にすればよい（実際にマイクロソフトのBinghttp://www.bing.com/やyelphttp://www.yelp.com/では実装済み）。

　この注釈のデータファイルが「emoji-annotations」だ[*19]。ここには、英語の注釈と、それに対応する絵文字がリストとして掲載されている。もちろん絵文字と注釈は一対一対応でなくともよく、多対一対応の場合もある。ただし、注意が必要なのは、注釈は言語に依存せざるを得ないこと。例えば「face」（顔）。

図6　UTR #51の注釈データ、emoji-annotationsにおける「face」

　「face」に対応する絵文字の中に時計の文字盤（clock face）もある。日本語を使う人に、これが「顔」に対応する絵文字だと言われれば違和感があるだろうがが、英語を使う人から見れば自然な対応だろう。これが言語依存の例だ。つまり、もし日本語で絵文字検索を実現したいなら、英語の「emoji-annotations」を元に日本語版を作る必要がある。

G）データファイル（10 Data Files）

　ここまで述べたように、UTR #51では各種のデータファイルを提供している。どれも絵文字の実装をするのに有用なリストだ。