特別企画

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

はじめに

 UTR #51“Unicode Emoji”[*1]は国際的な文字コード策定団体、Unicodeコンソーシアムが発行する絵文字の実装指針文書だ。同コンソーシアムはGoogle、Apple、Microsoft、IBM等をメンバーとするが、今後これら会員企業はUTR #51に基づき自社製品における絵文字の実装を進めることになる。現在ドラフト段階で、今年1月26日まで公開レビューが行われていた。

 ところで、過去何回か絵文字について記事にしたことがあるが、読者の反応を見ると、「今すぐUnicodeから絵文字を削除すべき」等、ネガティブな反応が目立つ。過去の携帯絵文字について詳しい人ほど、そうした声が多いようだ。

 しかしここ数年、海外において絵文字が広く一般に普及したことにより、これから登場する各種ソリューションやサービスにおいて、絵文字の対応は必須になりつつある。つまりワールドワイドから見れば、絵文字は最も「旬」な技術の1つなのだ。そうしたものについて、過去の経験を理由に背中をむけるのは、損な態度といえないだろうか。

 まず最初に文書の位置付けから説明しよう。国際文字コードUnicodeは、コード表を含む規格本文を補完する文書として、3種類のTechnical Reportを規定している。1つめが規格本文に準じるUnicode Standard Annex(UAX)、2つめがUnicodeとは独立した仕様であるUnicode Technical Standard(UTS)、そして3つめがUnicodeの実装上で参考になる情報をまとめたUnicode Technical Report(UTR)だ[*2]

 UTR #51はUnicode Technical Reportの、識別番号51という意味。同じUTRとして、例えば縦書き中の文字を正立させるか・横転させるかのガイドライン、UTR #50“Unicode Vertical Text Layout”[*3]があるといえば、UTRの持つ「実装の参考情報」という性質がお分かりいただけるだろうか。

 UTR #51の共同著者はGoogleのマーク・デイビスとAppleのピーター・エドバーグだ。このうちマーク・デイビスはUnicodeコンソーシアムの共同創設者で、1991年以来会長を務めてきた重鎮だ[*4]。後述する理由でAppleもこのUTR #51を積極的に推進しなければならない事情がある。こうしたことからUTR #51の内容は、近い将来、AndroidやiOSで実装される可能性が高いともいえる。

なぜ、UTR #51が必要になったのか

 UTR #51の内容を説明する前に、この文書が必要になった背景について説明しておこう。大きく分けて4つある。

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

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

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

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

チューリップ型の名札を見た外国人の反応がジワジワ来ると話題に(亀井二郎、IRORIO)
http://irorio.jp/kamejiro/20141022/171989/

 かねてチューリップ型名札の絵文字「」(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コンソーシアムの名前を出した上で、以下のような約束をしていることだ。

我々の絵文字はUnicode標準に基づいており、それはたくさんのプラットフォーム間で適切に表示されるために無くてはならないものです。絵文字のセットはより多様性が必要であり、我々は標準をアップデートするため、Unicodeコンソーシアムとともに密接に連携します。[*14]

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

UTR #51はなにが書かれているのか

 では順次内容を紹介していこう。ただしこのスペースでは、とても全部は紹介できない。ポイントにとどまるので、興味をもった方はぜひ原文を参照されたい。

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

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

〈拙訳〉実装のためのより長期のゴールは、埋め込み画像をサポートすることです。それは任意の絵文字を可能にして、追加のUnicode符号化に依存しません。(8 Longer Term Solutions/より長期の解決法)[*15]

 つまり、より長期的な絵文字における実装のゴールは、文字コードではなく埋め込み画像だと述べている。この方法によれば、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では各種のデータファイルを提供している。どれも絵文字の実装をするのに有用なリストだ。

おしまいに

 後半は駆け足になってしまったが、UTR #51について説明した。絵文字という一筋縄でいかない文字を、データとルールを整備することで、力尽くで実装しようという、ある意味Unicodeらしい仕様だということをお伝えしたかった。

 スペースの関係でだいぶ省略したのが心残りだ。例えばAnnex Cでは、これから絵文字を追加するに辺り、企業ロゴはダメとか、使用頻度が低いとダメなどといった、選択の基準を述べた興味深いものだ。

 関連して、Annex Dでは今年中ごろに予定されているUnicode 8.0での追加候補という絵文字をリストアップしている。じつは、これらの文字はUnicodeと同期する公的な国際文字コード規格、ISO/IEC 10646の審議過程から見ると、横紙破りというしかない。一般に文字を規格に収録するには、審議と投票に最低でも3~4年はかかる。しかし、これらの文字は1月に提案されたばかりだ[*20]。たった数カ月でどうやって押し込もうというのか、まさに前代未聞の状況なのだ。さすが力尽くのUnicodeコンソーシアムである。詳しい分析をしたいところだが、別の機会にゆずろう。

注釈

[*1]……Mark Davis(Google Inc.), Peter Edberg(Apple Inc.)“UTR #51 Unicode Emoji” 2014-12-17
http://www.unicode.org/reports/tr51/

[*2]……“About Unicode Technical Reports”
http://www.unicode.org/reports/about-reports.html

[*3]……石井宏治 “UTR #50 Unicode Vertical Text Layout” 2014-09-22
http://unicode.org/reports/tr50/

[*4]……“Unicode Directors, Officers and Staff”
http://unicode.org/consortium/directors.html#execofficers

[*5]……園部修「iPhone 2.2アップデート開始──絵文字やGoogleストリートビューなどに対応」ITmedia Mobile、2008-11-21
http://www.itmedia.co.jp/mobile/articles/0811/21/news073.html

[*6]……Kat Momoi et al. “Working Draft Proposal for Encoding Emoji Symbols” 2007-08-03
http://unicode.org/L2/L2007/07257-emoji-wd.html

[*7]……Markus Scherer「絵文字のユニコード符号化: 符号化提案用のオープンソースデータ」Google Blog、2008-11-27
http://googlejapan.blogspot.jp/2008/11/blog-post_27.html

[*8]……NAOI「iPhone絵文字についてUnicodeの視点からまとめてみた」Mac OS Xの文字コード問題に関するメモ、2011-06-28
http://d.hatena.ne.jp/NAOI/20110628

[*9]……NAOI「iOS 5の絵文字はどこが変わったのか」Mac OS Xの文字コード問題に関するメモ、2011-10-18
http://d.hatena.ne.jp/NAOI/20111018/1318921501

[*10]……NAOI「Appleカラー絵文字は10.7.3でどう変わったのか」Mac OS Xの文字コード問題に関するメモ、2012-02-14
http://d.hatena.ne.jp/NAOI/20120214/1329198878

[*11]……iautotext keyboard ”New Emoji 2 keyboard: How to enable 300+ New Emoji 2 in iOS 5.1” 2012-04-21
http://www.youtube.com/watch?v=IHGu0JgZ9X4

[*12]……Draft Emoji Data(Full)
http://www.unicode.org/Public/emoji/1.0/full-emoji-list.html

[*13]……https://twitter.com/vinnieferra/status/557690139477311490

[*14]……Joey Parker “What Does Apple Think About The Lack Of Diversity In Emojis? We Have Their Response” MTVact, 2014-3-25
http://act.mtv.com/posts/apple-responds-to-lack-of-diversity-in-emojis/

[*15]……原文は以下の通り。
“The longer-term goal for implementations should be to support embedded graphics. That would allow arbitrary emoji symbols, and not be dependent on additional Unicode encoding.”(8 Longer Term Solutions)

[*16]……Line『「LINE Creators Market」の販売対象国を拡大、全世界のLINE内スタンプショップでクリエイターズスタンプが購入可能に』2014-06-27
http://linecorp.com/ja/pr/news/ja/2014/769

[*17]……“Standardized Variants” 2013-11-27
http://unicode.org/Public/UNIDATA/StandardizedVariants.html

[*18]……“Draft Emoji Ordering”
http://www.unicode.org/Public/emoji/1.0/emoji-ordering.html

[*19]……Draft Emoji Annotations
http://www.unicode.org/Public/emoji/1.0/emoji-annotations.html

[*20]……Michel Suignard “Additional repertoire Amendment 2.3 to ISO/IEC 10646:2014(4th edition)” 2015-01-28
http://www.unicode.org/L2/L2015/15028-n4658-pdam23-charts.pdf

【記事訂正 2015/2/3 21:50】
 以下のように訂正いたします。直井靖さんのご指摘に感謝いたします。

その1

 図1のうち、U+1F60Eが日本の携帯会社をソースとするというのは誤りだった。これは原文であるUTR #51の誤りだ。本稿ではより適切なU+1F60Dに差し替える。なお、Uniciodeコンソーシアムへはこの件をフィードバックした。

その2

修正前:

同製品は2008年7月に日本で新発売された当初から、日本の携帯電話と互換をとる必要上、カラーの絵文字フォントを実装してきた。

修正後:

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

[*5]……園部修「iPhone 2.2アップデート開始──絵文字やGoogleストリートビューなどに対応」ITmedia Mobile、2008-11-21
http://www.itmedia.co.jp/mobile/articles/0811/21/news073.html

その3

修正前:

翌2011年10月、AppleはiOS 5のカラー絵文字フォントをアップデートし、Unicodeの正式な符号位置をサポートする[*7]。ただし、この時点ではドコモ/auとの互換目的の絵文字はまだモノクロ表示で、すべてがカラーになるには2012年3月のiOS 5.1まで待たねばならない。

修正後:

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

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

[*8]……NAOI「iPhone絵文字についてUnicodeの視点からまとめてみた」Mac OS Xの文字コード問題に関するメモ、2011-06-28
http://d.hatena.ne.jp/NAOI/20110628

[*9]……NAOI「iOS 5の絵文字はどこが変わったのか」Mac OS Xの文字コード問題に関するメモ、2011-10-18
http://d.hatena.ne.jp/NAOI/20111018/1318921501

[*10]……NAOI「Appleカラー絵文字は10.7.3でどう変わったのか」Mac OS Xの文字コード問題に関するメモ、2012-02-14
http://d.hatena.ne.jp/NAOI/20120214/1329198878

小形 克宏

文字とコンピューターのフリーライター。2001年に本誌連載「文字の海、ビットの舟」で文字の世界に漕ぎ出してから早くも15年が過ぎようとしています。知るほどに「海」の広さ深さに打ちのめされる毎日です。Twitterアカウント:@ogwata