Shironetsu Blog

@shironetsuのブログ

ピンクのハートはなぜ無いか - シャニマスとユニコード絵文字（１）

放課後クライマックスカラーのハートと符号位置
図1 放課後クライマックスガールズカラーのハートと符号位置

和泉愛依カラーのハート

1週間後に4thライブを控えた2022年4月16日から翌17日の2日間、「シャニマスミュージックシェア」と題する、シャニマス公式ツイッター@imassc_official上での企画が行われた。 内容は、ツイッター上に投稿されたファンのコメントをアイドル本人達が読み上げるという形で、過去の楽曲を紹介するというもの。

その中の一幕。ストレイライトからユニットを代表して黛冬優子が楽曲"Wandering Dream Chaser"を紹介する。

黛冬優子のツイート
図2 黛冬優子のツイート 1 2

ストレイライト各メンバーのイメージカラーは、

  • 黛冬優子: 緑
  • 芹沢あさひ：赤
  • 和泉愛依: マゼンタ

で、それぞれの衣装などにも取り入れられている。

ストレイライトのユニット衣装に取り入れられているイメージカラー
図3 ストレイライトのユニット衣装に取り入れられているイメージカラー

Straylight (ストレイライト) | アイドルマスター シャイニーカラーズ(シャニマス)

しかし、緑と赤はあってもマゼンタに近いピンクのハートの絵文字がない。 比較的色味の近い紫のハートによる代用は馴染まなかったのか、一案を講じてピンク色だが動きの付いているハート💗に変えようとしている（この後実際に一度💗にしてから再び紫に戻している）。

園田智代子カラーのハート

ピンクのハートの不在は他のユニットにも影響している。

黛冬優子の前日、放課後クライマックスガールズ（放クラ）を代表して登場した小宮果穂によるツイート。

小宮果穂のツイート
図4 小宮果穂のツイート

放クラ各メンバーのイメージカラーは

  • 小宮果穂：赤
  • 園田智代子：ピンク
  • 西城樹里：黄
  • 杜野凛世：青
  • 有栖川夏葉：緑

で、やはりこちらでもピンクが動きの付いたハート💗によって代用されている。 放クラの場合、戦隊ものがオマージュ元にあるため赤とピンクははっきりと分かれているし、紫に代えることもできない。 ピンクのハートの不在はストレイライトより一層重大だ。

ピンクのハートはどこに？

ピンクのハートは本当にないのだろうか。iOSの絵文字キーボードを開いてみよう。

iOSの絵文字キーボード
図5 iOSの絵文字キーボード

赤、橙、黄、緑、青、紫、黒、白、茶まで同じ形状のハートが並ぶ。 その後に続くのは、割れていたり💔燃えていたり❤️‍🔥、特殊な形状のハートたち。 そのうち、動きが付いていたり💗、キラキラしているハート💖はピンク色だが、「ただのピンクのハート」は確かにない。

ではキーボードに並んでいないだけで入力はできるのかというと、そういうわけでもない。

これは絵文字の「規格」を定めた文書からの抜粋。

ハートの絵文字の規格
図6 ハートの絵文字の規格

The Unicode Standard, Version 14.0 p.1602（100Mと大きいので注意）

表の上ではモノクロだが、

  • BLUE HEART
  • GREEN HEART
  • YELLOW HEART
  • ORANGE HEART
  • PURPLE HEART

などが見て取れる。

しかし、"PINK HEART"はどこにもない。

なぜピンクのハートはないのだろうか。そしてこの「仕様」は何だろうか。

文字コードとは

歴史を辿ろう。

文字はもともと石や紙に「形」として刻まれたものを、直接人が見て認識するものだった。 ところが、コンピュータで扱う（伝える・保存する・入力する……etc）には「形」そのままを扱うわけにはいかない。 そこで、コンピュータの内部では0と1の列（ビット）として表現し、人の目に触れる段階になって初めて「形」として表現する方法が編み出された。 これが文字の符号化である。

具体的には、例えば

十進法 二進法 十六進法 文字
0 0 00 a
1 1 01 b
2 10 02 c
… … …
25 11001 19 z

のようにa-zの26文字に0から順に整数値を割り当てる。

こうすれば、例えば"hello"は 07 04 0b 0b 0e というバイトの列で伝送したり保存したりすることが可能になる。 こういった文字列を符号化する取り決めのことを文字コードと呼ぶ。 また、ある文字に対応する数値を符号位置（コードポイント）という。 たとえば、この仮想の文字コードにおいて、cの符号位置は 02、zの符号位置は 19（それぞれ16進法）になる。

文字コードは、文字をやり取りする2者の間で共有されていなくてはならない。 例えば、こちらがa-zに対して0から25まで順に整数値を割り当てている一方で、 相手が逆順に（aは25に、bは24に…）割り当てていれば、こちらから送った"hello"は相手側では"svool"という意味をなさない語として読み取られてしまう。 文字化けである。

もちろん、自分が作成したテキストを保存するときと読み取るときで文字コードが異なっていても困る。

ASCIIとJIS規格

文字コードが食い違うことによる混乱を避けるため、広く共有することを目的として種々の文字コードが作られてきた。

代表的かつ基本的なのは、アメリカの規格として作られたASCIIである。

ASCIIではa-zの小文字、大文字に加え、/（スラッシュ）や:（コロン）等の記号、制御文字が全て7ビットで表現されている。

すぐに気付くように、ASCIIは専ら英語を表現するために作られているため、他の言語を扱うには別の文字コードが必要になる。

日本語用の文字コードは、国内で日本産業規格（JIS）で定められた規格として作られてきた。

ASCIIをベースに、（俗にいう）半角カタカナを追加した文字コードがJIS X 0201である。 全ての文字を1バイトで表すため、最大でも256文字しか含むことができず、当然漢字は表現できない。

後継のJIS X 0208は2バイトの文字コードで、 2^16=65536 という十分な広さの符号空間（文字の表現に使える数値の全体）が確保されたことで、日常的に用いられる漢字を収録できるようになった。

ユニコード

各言語用の文字コードが日本に限らず世界の各地域で策定される一方、 世界中の文字を収録した一つの文字コードを作るという壮大な試みがアメリカのIT企業を中心に動いていた。 ユニコードである。

ユニコードには、ラテンアルファベットベースの文字、日中韓の膨大な漢字、アラビア文字、インド系文字、様々な少数民族の言語の文字、更には古代文字が収録されている。

数学記号や音楽記号、チェスの駒♔♕♖♗♘♙やドミノのタイル🁴🀻もカバー対象。 そして、絵文字を使うことができるのもこのユニコードのおかげだ。

ユニコードでは、各文字には一意な（そして一度決まれば原則的に不変の）符号位置と名前が与えられている。たとえば、

符号位置 名前 文字
U+53 LATIN CAPITAL LETTER S S
U+3042 HIRAGANA LETTER A あ
U+9EDB CJK UNIFIED IDEOGRAPH-9EDB 黛
U+1F41F FISH 🐟

といった具合に。 なお、ユニコードの符号位置は、慣習的に U+ のあとに16進法で数値を置くことで表示する。

大きい符号位置を持つ傾向にあるとはいえ、ユニコードの世界において、絵文字はラテンアルファベットやひらがな、漢字と対等な存在なのだ。

絵文字

元々絵文字は日本の携帯会社が、国内規格であるJIS X 0208（をベースにした符号化方式のShift_JISなど）の未割当の領域に文字と同等の扱いにできるように割り当てたことで生まれた。 公的な規格としては文字が存在しない符号位置を、企業の私的な運用を目的として利用したということ。 いわゆる機種依存文字である。

2000年代初頭、当時は通信速度の制約が大きく、今でいう「スタンプ」のように画像をやりとりするのは困難だったため、その解決策としてはうまくいった。 携帯メールの爆発的な普及に伴い絵文字も浸透し、コミュニケーションに欠かせない要素になるまでにそう時間はかからなかった。

しかし、絵文字はあくまでも各企業の私的な規格である。 公的な規格でも統一の業界ルールでもないため、キャリアを跨ぐやりとりは文字化けを引き起こす。 これを解消するため、企業間で絵文字の変換ルールが定められた。 この方法はまずまずうまくいった。 とはいえ、いわば各社用の独自の文字コードが乱立したままであることに変わりはなく、状況は混沌としていた。

Unicode emojiへ

キャリア各社がめいめいに絵文字を実装してた混乱の中にグーグルが踏み込んでくる。 モバイル版gメールを提供するためである。

日本の誰が絵文字を表示してくれないメールを使うだろうか？ それほどまでに絵文字は普及していた。 日本のユーザーに使ってもらうためには何としても絵文字を扱う必要がある。

ユニコードを策定する団体、ユニコード・コンソーシアムにおいて主導的な立場にあるグーグルは、国際規格であるユニコードに絵文字を組み込むことを提案した。 これは実は兼ねてよりキャリア各社も求めていたことであった。 私的な規格に過ぎないため当初は却下されてしまったが、 絵文字の普及とグーグルの参入によって遂に検討されるに至った。 2007年のことである。

絵文字の収録においては、それまでに使われていたキャリア各社の絵文字との互換性の維持が大前提とされ、既存の仕様で区別されているものはユニコードでも引き続き区別されることが提案の基礎となっていた。 日中韓の漢字の字体を統合してきたユニコードの世界において、これは破格の好待遇を求めるようなものだった。

省略されたピンク色

グーグルによる提案に含まれるデータが公開されている。

L2/08-080 Emoji Proposal Data (PDF)

ハートの絵文字の追加に関する初期の提案
図7 ハートの絵文字の追加に関する初期の提案

その中から、ハートの絵文字について記された箇所を加工の上抜粋した（図7）。 右半分にKDDI・DoCoMo・SoftBank3社の絵文字が並んでいる。 "Representation"の列は3つを代表する形、"Proposed Character Name"はユニコードに登録する際の文字名の案が書かれている。

青・緑・黄・紫のハートはそれぞれ HEART WITH （色名） COLOR の名前を付けてユニコードに含めることが提案されている。 この4つはKDDI、SoftBankで絵文字が存在することに対応したもの。 DoCoMoは対応するものがないが、変換ルール上すべて赤っぽいハートで代用されていたことが分かる。

一方、表の項目1行目、3社がピンク～赤色のハートとして表現していたものは、左端で黒塗りのハートで表現されている。 付記されたU+2764は"HEAVY BLACK HEART"という当時既に存在していた飾り文字を示している。

そう、ピンク～赤色のハートの絵文字は「ベースライン」のハートであるため、その色は提案の段階で無視されることになったのだ。 これはいたずらに文字を増やさないために、同一視できるものは統一するというユニコードの基本的な方針に則ったもの。 漢字の数多ある字体もこの原則に従って可能な限り統合されている*1。 「ベースライン」のハートと青色のハートの区別は保たれるから、互換性維持の方針には反していない。

結局、提案は若干の修正を受けた後、

符号位置 名前 文字
U+1F499 BLUE HEART 💙
U+1F49A GREEN HEART 💚
U+1F49B YELLOW HEART 💛
U+1f49D PURPLE HEART 💜

として他の数百の絵文字とともに色付きのハートたちが登録されることになった。 上で見た「規格」はこの時決まったもの。 Unicodeバージョン6.0、2010年のことである。

赤色のハート

ところで、赤色のハートはどこにあるのだろうか。

そもそも、ユニコードの仕様では色についてカラーコード等で明確に定めていない。 あくまでも参考情報として名前に色名が付いているだけである。 形でさえも「例示字形」といって「だいたいこんな形」と示されているだけで、具体的なデザインはフォントの作成者に任されている。

上述の通り、「基本」のハートの絵文字は既に存在していたU+2764 "HEAVY BLACK HEART" と統合された。 しかし「絵文字らしい」ハートも欲しい。

そこで、漢字の異体字と同じ仕組みで、それ自体は表示されない*2特殊な文字、異体字セレクタによってテキストスタイルと絵文字スタイルの記号を出しわける方法が考案された。 具体的には、U+2764 の直後に U+FE0F を置くと「絵文字らしい」ハートになることが決められている。一方、U+FE0Eなら黒塗りのハートのままだ（図8）。

テキストスタイルと絵文字スタイル
図8 HEAVY BLACK HEARTSのテキストスタイルと絵文字スタイル

参考：Emoji Presentation Sequences, v14.0

この、絵文字スタイルの "HEAVY BLACK HEART" が普通赤色のハートとして利用されているものである。

日本と欧米の文化的な差だろうか、確かなところは分からないが「普通の」ハートは赤色と決まってしまったらしい。

Unicode emojiを網羅的に収録している辞書的なウェブサイト、Emojipediaの"red heart"の項目を見ると、Apple, Google, Twitterなど、絵文字用のフォントのほとんどの実装で赤色をこの<U+2764 U+FE0F>の組合せに当てていることが分かる。

その一方、U+1F497 のGROWING HEART（大きくなるハート）💗やSPARKLING HEART（きらきら輝くハート）💖は元になった携帯電話の絵文字を踏襲してかピンク系が付けられているものが多い。小宮果穂や黛冬優子のツイートでピンクを表現するために代用されていたのがこのGROWING HEARTのほうだ。

追加された色付きのハート

明示的に色が指定されたハートの絵文字は、最初は青・緑・黄・紫の4つだったが、その後、携帯電話の絵文字にはなかった黒・橙・白・茶が追加されて8つとなっている。

符号位置 名前 文字 追加されたバージョン
U+1F5A4 BLACK HEART 🖤 9.0
U+1F9E1 ORANGE HEART 🧡 10.0
U+1F90D WHITE HEART 🤍 12.0
U+1F90E BROWN HEART 🤎 12.0

参考：What Every Heart Emoji Really Means

現行のUnicodeのバージョンは14.0で、既にTwitter等でもよく見るようになった U+1FAF6 HEART HANDS🫶（【きゅん♡コメ】八宮めぐる） や U+1FAE0 MELTING FACE🫠 がこのバージョンで新しく加わっている。

参考：What's New in Unicode 14.0

オレンジ色のハートを追加するための提案に含められた理由の一つが虹を構成するために欠けた色だったことであったことは注目に値する。 紫💜青💙緑💚黄💛橙🧡赤❤の6色で虹ができるということ。 283プロの7ユニットのカラーで虹を作りたい我々にとってはこれでは足りない。 やはりアルストロメリアのピンクだけが欠けている。

ではピンク色のハートはどうなっているかというと、一般ユーザーの根強い要望にもかかわらず、最新のバージョン14.0でも追加はならなかった。

以上が黛冬優子のツイート

ピンクの♡があれば綺麗にストレイライト色で揃えられるんだけどなぁ……

💗の方がいいかなぁ……？🤔

の裏にある歴史的背景である。簡単にまとめると、

  • Twitter上では文字コードとしてユニコードの使用が前提となっている
  • ユニコードには日本で携帯電話メールを提供する三大キャリア（DoCoMo・au・SoftBank）の絵文字が取り込まれた
  • 青・緑・黄・紫色のハートはauとSoftBankを引き継いで独自の色を持つものとみなされた一方、ピンク～赤色は「ベースライン」のハートとみなされた
  • その結果、ユニコードにおいてピンク色のハートの絵文字は仕様として定められず、絵文字スタイルのハートは専ら赤に塗られるようになった

ということ。 ゲーム本編ではないとはいえ、キャラクターが実在の規格に起因する事情に言及する貴重なシーンである。

「ガラケー」はもはやアニメや漫画のキャラクターが持つことはなくなった。 けいおん！！22話で中野梓が先輩4人からの合格の報せを桜の絵文字4つで表したシーンは、理解に歴史学的な知識を要するものになりつつある。 そんな時代の名残がこうして黛冬優子のツイートに現れているとは、何とも奇妙で面白いことのように思う。

Unicode 15.0

さて、この記事を書いている時点でピンクのハートの絵文字は存在しない。 しかし状況は変わりつつある。

Emojipediaの記事 "Pink Heart Emoji Might Finally Become Reality"（ついにピンク色のハートの絵文字が実現するかもしれない）では、ユニコードの次期バージョン15.0にピンク・グレー・薄青の3色のハートが追加される事に関して、かなり希望的な観測が述べられている。 順調にいけば2022年9月に正式に発行され、その後半年程度で各プラットフォームがそれに対応したフォントを実装していくことになる。

背景にあるのは、この3色がハートの絵文字たちによるの色相環上の空白地帯になっていることや、ハートによって所属やアイデンティティを表現するという需要の高まり。 青と黄のハート💙💛でウクライナへの連帯を表すという用途は一度ならず目にしたことだろう。

ピンクのハートを表現できないという悩みもまた、1年以内に過去のものになるかもしれない。

シャニマスと絵文字

シャニマスは他のツイッター上の企画（特に2021年8月30日のノクチルツイッター企画以後）でも積極的にユニコード絵文字を利用している。 次の記事ではシャニマスがユニコード絵文字をどう取り込んでいるか、他の実例を見る。

リファレンス

雑誌・書籍

Webサイト

*1:とはいえ、慣習上別の字として扱われる「桜」と「櫻」は区別されているし、 異体字セレクタで微妙な差異を表現するための方法も用意されている。

*2:こういった表示上の幅がなく、他の文字と組み合わせて一つの単位となるような文字の存在がユニコードで「文字数」を数えることを難しくしている。人が見て「1文字」と認識する単位のことを書記素クラスタという。カーソルの移動一つ分は書記素クラスタ1個分になる。書記素クラスタはユニコードの仕様として厳密に定まっているため、適切なライブラリさえ使えば問題は回避できる。