エンジニア座談会Vol.06 バリアブルフォントの可能性

はじめに

　本記事はフロントエンドに関わる人々のためのメディア「CodeGrid」（https://www.codegrid.net/）より厳選した記事をお送りします。

　JamstackでWebフォントを使うには埋め込み用のサブセットを使うという方法がありつつも、ライセンス体系がまだ整えられていなかったり、コスト面やビルド時間が読みきれないということが話題に上がりました。 また、OpenType機能とCSSの組み合わせできれいな文字組が実現しそうな一方で、OpenType機能を取り込むことによって、ファイルサイズが重くなってしまうことなど問題点があることもわかりました。 最終回である後編では、未来の有望な仕様としてバリアブルフォントが話題になります。夢の仕様とまで言われるバリアブルフォントはどのような機能を持つのでしょうか。

（※本記事は、2022年1月下旬に収録した座談会をもとにしたものです。記事中で話されている情報は、座談会当時の内容になります。また、記事へのリンク先が有料記事の場合もありますので、あらかじめご了承ください）

ゲスト

バリアブルフォントは夢の仕様？

中村：Webで日本語を扱うという観点から、WebフォントやOpenTypeフォントについて話してきましたけど、バリアブルフォントはどうでしょうか。なんとなく昔から夢の仕様みたいに言われていたものが、今わりと出てきていますよね。

バリアブルフォントは、日本語のWebフォント観点から表現が広がるというのもあるし、容量的にも1ファイルで全部対応できるならうれしいんじゃないかと僕は思うんですけど。

矢倉：日本語フォントだと、ただでさえ容量の多いファイルになりがちなのに、それがウェイト分さらに増えてしまう。もしバリアブルフォントになると、これまでの1ファイル分の容量＋少しくらいに減るはずなので、Webフォントとしてはとてもうれしいです。

鈴木：うん、そうですね。

矢倉：あと、OSに搭載するフォントとしてもうれしいですね。AndroidとかChromebookにはNoto Sans CJKが入っているんですけど、容量の都合上、バンドルするウェイトが絞られているんですね。たしか400と700ぐらいしかないんじゃないかな。

でも欧文はそんなに容量が増えないからか、けっこうウェイトがあるんです。そうなると和欧混植のときに、ウェイトの指定によっては欧文と日本語で太さにずれが出ちゃうんですよね。
たとえばYouTubeとか、トップページのサムネイルのタイトルが500だったりするんです。でもAndroidやChromeは500のウェイトの日本語フォントがないので、日本語のところが細く見えてしまう。

もし、日本語のバリアブルフォントがOSにバンドルされていれば、こうした問題は減るんだろうなと。

中村：Google Fontsのサイトではバリアブルフォントを選択できるようになっていて、欧文フォントが中心ではあるんですけど日本語もいくつかありますね。「Show only variable fonts」というチェックボックスを入れると、そこで出ますね。さらにそこで日本語を選べば……なんですけど、今のところM PLUSぐらいしかない。

バリアブルフォントの一例

國仲：M PLUSは老舗のフォントですね。

矢倉：たしか、M PLUSは作り直しているんですよね。もとからあるやつじゃなくて。

國仲：ああ、そうなんですね。すごいですね。

矢倉：Googleから支援を受けて、今までの字体とかの見直しを含めてさらにバリアブルフォントなどに対応するように作り直している。

中村：Google FontsのM PLUS、Weightを動かすスライダがありますね。たとえばWeightを400から700ぐらいに動かしてみると……。

鈴木：おおー！ ……うーん、やばい！（笑）。

國仲：「だ」の濁点のところ、Weightで移動するんですね。スライダを動かしていくとわかる。

小原：ほんとだ。

コピペで洗練された文字組を取り入れられる可能性

矢倉：日本語のバリアブルフォント、軸がwghtぐらいしかないんですよね。幅のwdthとかもあるとうれしいんだけどなと思いますね。

特にUIのボタンとかのラベルを、ちょっと狭くしたりとかしたいんですよね。モバイルなどの幅が狭い環境だと、日本語だと幅が大きくて途切れちゃったりしやすいんで。バリアブルフォントで幅をきゅっとできれば、もうちょい入れられるんじゃないかなあと。

小原：文字幅の調整かあ……。紙のデザイン（DTP）でその調整を大量にやっていた側からすると、Webでそれができるようになったら、いやー大変だろうなって（笑）。「もうちょっと縮めると1行に入るのでっ！」っていうオーダーに対応できちゃうから、めちゃくちゃ調整しなくちゃいけなくなる。100%だと入らないけど98%だと確かに入る。

鈴木：使う側が大変ということですよねえ。バリアブルフォントって、フォントの話になると最近の話題としてよく上がるんですけど、「どのくらい使いこなせるだろうか、僕たちは」って思っちゃうんですよね。

矢倉：うん、ありますよね。

鈴木：今、小原さんが言った、文字幅もそうだし、あとウェイトも、そこまで緻密にデザインできるものか？ と思ってしまうんですよね。それよりも始めからウェイトが10ぐらいと決まっていたほうが使いやすいんじゃないかなと思ったりしますけどね。

小原：ただ、僕はバリアブルを歓迎しているところがあるんですよね。さっきも話に出たけど（編集部注：2回目で出てきました）、やっぱり読み物系で和欧混植するときに、字面のボリュームは揃えたいじゃないですか。混植したときに、欧文書体のサイズを105%にすると文字サイズのバランスはよくなるんだけど、5%大きくした分、ウェイトがちょっと太るんですよね。そうなると日本語とアルファベットが均一には見えなくなってしまい、欧文がなんか強調されて見えちゃう。

そういうときの、「5%を細くしたい」というのが、バリアブルフォントだとできるかなと。というのがメリットかなあって僕は見ていますね。

鈴木：……そうだけど、でもそこまでやれる人はなかなかいないっていうか……（笑）。

小原：（笑）

鈴木：font-feature-settingsのpaltの話もそうだけど、やっぱり使う側の技量がより求められる気がしちゃうんですよね。っていうと、言い方悪いですけど。

バリアブルフォントを見ていても、ちょっと遊びっぽい絵文字的な使い方というか、そういうのでみんな実験しているのが主で、まだ読みやすさとか読み心地にフォーカスするところまでいけていない気がしていて。

小原：そういう意味では、paltがfuture-font-setting用の設定値に見えるくらい流行っちゃったのは、コピペができるからっていう部分があるのかな？ 容易に取り入れられるっていう部分が。

鈴木：ああ、うんうん。

小原：良し悪しでちょっと悪く働いちゃった部分かもしれないけど、でも、和欧混植のセッティングをコピペできるというのは、もしかしたら読み心地をよくしていこうという流れの底上げにつながるかもしれないですね。

今まで微妙だったところだったところが、容易にコピペしてもらって簡単に手に入れられる可能性はあったりして。安直にやってみたら、結構よくなった、というようなことがあるかもしれないなって思いましたね。そういう「コピペで使う」ことって、Webならではというか。

鈴木：うんうん。

フォントを作る側・提供する側の準備

鈴木：でもそうなってくると、バリアブルフォントとしてそのフォントが用意されていなきゃいけないからWebフォントで利用ってことになるし、OpenType機能とか、和欧混植のサイズ調整とかも、提供側、フォントサービスやフォントメーカーが用意しないといけないですよね。OSに入るのは結構先の話になると思うので。

そういう意味では、Webフォントサービスを使う理由になると思いますね。Webフォントサービスに関わってる僕が言うと、ちょっといやらしい言い方になりますけど（笑）。

矢倉：ただ、実際に今、書体を作るワークフローが、バリアブルフォントに向いたワークフローなのかな？ というのが気になっていて。バリアブルフォントは、おそらくポイントがどんな値に沿って移動するかの関数を書かないといけないですよね。そう考えると、フォントをデザインする側としても、今までにないチャレンジがありますよね。

鈴木：あると思います。社内でも研究はしているんですが、やっぱり僕の見ているかんじだと、バリアブルフォントは最初からバリアブルフォントとしてデザインしなきゃいけないんじゃないかなと思っていて。

たとえば1つの書体で、ウェイトが10個ぐらいあったとしても、単純に太くする・細くするという話じゃないんですよね。10個揃ってファミリーってことになっていますけど、一個一個別々の書体として書体デザイナーは捉えているんですよね。レギュラーはレギュラー、ライトはライト、ボールドはボールドで。

矢倉：ああ。

鈴木：たぶん、書体デザイナーはあんまり数字で見ていないんじゃないかな、と僕は思っていて。

たとえば筑紫明朝という書体があるんですけど、L（レギュラー）、R（ライト）のほかに、横画をちょっと太らせたLBとかRBというバリエーションがあったりするんですよ。

筑紫明朝の書体ウェイトバリエーション（一部）

これは昔、「黒地に印刷したときにかすれて見えるからちょっと横画を太くした」という経緯があるみたいなんですよね。そういうかんじで、単純な軽い重いだけじゃない調整をいろいろしていたりとか、用途を考えてデザインしていたりする。そういうふうにデザインしてきた人たちに、これまでのフォントをバリアブルフォント化しようといっても、「いやいや……」みたいな。

矢倉：そうは作っていないから、ということですよね。

鈴木：そうそう。なので、本当にバリアブルに作るなら、最初からバリアブルを想定して作らないと結構きついんじゃないかな。

矢倉：じゃあ、既存のフォントの資産を活かしてバリアブルフォントにしよう、というのは、ちょっと考えとしては難しい？

鈴木：「あの名作書体がバリアブルに！」みたいなのは、なかなか日本語では難しいんじゃないかと思いますね。

たぶん、Noto Sansや源ノ角ゴシックのシリーズは、ある程度システマチックに最初から作っているんじゃないかなという気はしていますけど。

書体も最初から10ウェイトとか揃っているっていうのはあんまりなくて。最初はレギュラーだけとか、ボールドだけとかで出して、これファミリー化してくださいという要望があったらちょっと増やすとか、そいういうパターンもありますし。結構、一筋縄ではいかないですね。

矢倉：ああ、そうか、バリアブルフォントだと、これまでのウェイトごとにフォントを販売できるというビジネスモデルも、ちょっと変わりますよね。そことの折り合いとかもありそうですね。

小原：めちゃくちゃありそうですね。かといって、じゃあバリアブルフォントになったから10倍の値付けができるかといえば……買う人いなくなっちゃいそう（笑）。

鈴木：そうそう。なので、バリアブルフォントの話になると歯切れが悪くなっちゃうというか（笑）。「いや、おもしろいと思うんです。けどね……」みたいな。

バリアブルネイティブなフォントデザインの可能性と課題

鈴木：これから若い世代のデザイナーが、バリアブルならではの可読性みたいなものを考えて、それこそ明朝でもゴシックでもないようなフォントを考えてくれたりするかもなと思ったりはしますけど。

矢倉：そういうバリアブルネイティブなフォントがもうちょっと増えてくると、Webでの日本語のフォントの採用率にも、きっと寄与しますよね。やっぱり日本語フォントの場合は容量の問題があるので。それがバリアブルフォントだと、1ファイルでいろんな表現ができるので、うれしさは変わってくるんですよね。

鈴木：それでいうと、足並みが揃っていないときついなと思っていて。ローカルに入っているフォントだと。

たまにOSがアップデートすると、何もしてないのに文字の表示が昨日より太くなっちゃったんだよみたいなことがあるじゃないですか。iOSがアップデートしたらヒラギノのウェイトが増えて、当初の想定より太くなっちゃうとか。

矢倉：ああ、ありましたね。

鈴木：なので、それはそれで、ウェイトのバリエーションが少なかったほうがコントロールしやすいというか、読みやすかったみたいのは正直ありますよね。欧文フォントばっかりバリアブル化されちゃうと、和文がついていけなくてちぐはぐな感じになったりとか。

矢倉：そうですね、たとえばWordPressのテーマで海外で流行っているものを使う、みたいのがあるじゃないですか。そうすると、日本語には存在しないウェイトが使われていて、日本語だとすっごく細いんだけど英語はちょうどいいみたいな、ちぐはぐな見た目になってしまう。

鈴木：あるある。

矢倉：そういうのはやっぱりいっしょについてこないと、困るということはありますよね。むずかしいんだなあ。

小原：夢はつまっているんですけどねえ。

鈴木：（笑）そうそう、そうなんですよ！

小原：「わ〜、これすげえ！ これがフォントの未来だ！」って思ったんですけどね、最初見た時は。だって、みんなやりたかったじゃないですか、もうちょい調節できればうれしいんだけどみたいのが。でも、今日話していて、やっぱりそう簡単ではないとわかりました。

矢倉：ただ、Webフォントを考えるとめちゃめちゃ欲しいものであるのは間違いないんだよなあ。

小原：うん、Webらしい、効率的な感じがすごくありますよね。

鈴木：たしかにね。そうですね。今はやっぱり、従来のDTPをどうにか模倣しているみたいなところもあるから。バリアブルフォントは、Webらしいといえば、Webらしいですよね。

サブセット問題を解決できるか、IFT

小原：ちょっと話が戻るんですが、Webフォントのサブセットを分けるときの問題で、カーニングの情報とかグリフ情報とかを分けられないのが問題の一つという話がありましたよね。

でも、それができないのって現状のフォントファイルの仕様の問題ですよね。外部ファイル的な感じで参照できる仕組みを作ってしまって、あとから別のところを指示してあったらそっちから読み込むみたいなことにしておくと、読み込みをバラけさせるっていうのもできなくはないということになるんですかね？

矢倉：それはまさに今ある話で、Incrimenntal Font Transifar、IFTと呼ばれている仕組みがW3Cで検討されているんですよね。これが来ると日本語のWebフォントでもかなりうれしくなりそう。

• Incremental Font Transfer

どんなものかというと、インクリメンタルとあるとおり、増えた文字の分のフォントだけ部分的に取ってくるって仕組みです。よりネイティブなサブセット技術といえばいいのかな。

静的サブセットだと大まかな文字の範囲でフォントファイルを分けているわけですが、これだとほんの一部の文字しか使ってなくても、ファイルを1つダウンロードしてしまうので、その部分が無駄になってしまいます。あと、小原さんの言うようにカーニングとか、文字のペアに関する情報がファイルをまたいでしまうと入れられない。

IFTでは、フォントは基本的に1つのファイルになります。ページを移動したり、動的にコンテンツが追加されたりして文字が増えたら、それに必要なフォントを同じURLにリクエストするものらしいです。

IFTのモチベーションの一つに、CJKでのWebフォントのパフォーマンスをいまよりもひどくないものにしたいというのがあるらしいです。IFTの仕様でどれくらい良くなるかという評価レポートがあるんですが、unicode-rangeを使った今の静的サブセットよりも、ダウンロードするバイト数がだいぶ削減できそうな感じです。

IFTの仕様書にはGoogleやAppleの名前があります。GoogleはGoogle Fontsでやっぱり使いたいんでしょうね。

まあ、Webフォントの仕組み側、仕様とかフォントファイルの側でも、まだまだ改善の余地があるけれど、それに向かって動いてはいる、というかんじですね。

中村：IFTが実現できたら、より日本語のWebフォントが普及しそうですよね。

矢倉：ただ、これはたぶんサービス側の対応がめちゃくちゃ大変なような気がしていますね。Range Requestはブラウザ側の対応かもしれないですけど、Patch Subsetはセブセット用の仕組みが新たに提案されているので、それをサーバーサイドで実装しないといけないですし。

今がんばって動的サブセッティングをやっているのが、ある程度標準仕様の中でもカバーできるようなことを考えてはいるというかんじですね。ブラウザに実装されるのはもうちょい時間がかかるだろうけど、期待したいですね。

鈴木：IFTは期待したいですね。でも、もうちょいって、どれくらいなんですかね？

矢倉：んーと、仕様の「もうちょい」は、めちゃくちゃ先ですけど（笑）。

鈴木：（笑）

矢倉：ただ、こういうのはある程度ベンダーの中で試しに実装しているものがもとになっていたりもするんですよね。WOFF2とかはまさにそんなかんじで、Googleが提案していたものだったはず。だから、ものによっては早いんじゃないでしょうか。

あとはブラウザ業界とかフォント業界とかの業界のニーズが広くあれば。WOFFについては、フォント業界のニーズもあったと思うんです。Webにこれまで出せなかった書体を出せるようになる、それがビジネスチャンスになるから、というところで、かなり進んだ気がするんですけど。

IFTはどうなるかな。わかんないですけど、ニーズがあり、実装する力がある人たちが興味を示せば、まあまあ早いんじゃないかなあと思いますね。

小原：でも、なんとなく、CJKのニーズって……。

矢倉：ないがしろにされがちではありますね……。

鈴木：（笑）話だけ聞いていると、それできたら最高なんだけどって思うんだけど、こんな夢のようなものが本当にできるんですか!? って思っちゃいますよね。

矢倉：あと、転送量とかの問題はよくなるのかなあと思いますけど、やっぱり動的に持ってくることには変わりないんで、新しく持ってきたフォントが反映するときのチカチカは抑えられないでしょうね。IFTが、Webフォントのすべてを解決するわけではない。

中村：いくつか問題はあるかもしれないけれど、仕様のレベルでパフォーマンス問題が解決できそうな検討が進んでいるというのはWebフォントの未来としてうれしい話ですね。

丈さん、今日は座談会に参加してくださいまして、ありがとうございました！

座談会を終えて

小原：僕はUIデザイナーなので、仕事柄まず見た目を作っていくということがありますけど、その際、必ずフォントはどうしようかというのが出てくるんですよね。その選択肢として気軽に選べる選択肢が増えてくれるのはいいことだと思っています。選択肢が狭いほうが楽ではあるんだけど、それでは表現の幅も狭くなる。表現の幅が広くなるから、フォントも気軽に選べるようになったらうれしいなと思います。

國仲：Webフォントに関してはそんなに言いたいことはないんですけど、OpenType機能で、paltしか知らないみたいな現状はどうかとは思ってはいます。使う側の意識として、もうちょっと、「こんなことができるんですよ」というのを知っておく。そして、Webフォントをもっとうまく使えるようになっていけばいいと思いますね。知識を増やしていけるようになれば、もっと楽しくなると思います。

矢倉：フォントには、いろいろ思うところがあります。Webフォントは表現力はいいですし、これまで使えなかったいろんな文字の見た目になるのはうれしいと思っています。ただ、読むことが考えられていないフォントの設定にしている実装も多いのかな。

いろんな技術を応援したい反面、自由度が上がることよって、僕の自由度が失われてしまうんじゃないかなみたいな、もやもやを感じながら、技術の進化に楽しみと不安を思っています。

まだまだ使われていない機能とか、実装がまちまちな機能とかもあって、これから期待できるIFTみたいな仕様もあるので、日本語フォントに関してもそれなりに進んでいく余地があるとは思っています。だから、「日本語フォントだと遅くなるんだろ」みたいに腐さず、ちゃんと使いどころを考えていけるといいなと思いますね。ただ「Lighthouseに怒られるからWebフォントは使わない」みたいな、そういう気持ちでフォントをナメないでほしいと思いますね。

中村：日本語のWebサイトが、パフォーマンスが気にせずにWebフォントを使えるようになると良いなと思います。

Webサイトは文字が主体だと思っているので、文字にいろいろな表情をつけられたりと、フォント自体がいろいろ使えるようになるとうれしいと思っています。最初は変な使われ方をするかもしれないけど、だんだん「デザインとか読みやすさとか大事だよね」みたいなところが広まっていけば、よりきれいなWebサイトができるんじゃないでしょうか。そういった意味でも、Webフォント周りには期待していますね。もっとみんなうまいこと使ったら良いのにと思うし、技術的な問題も解決されるといいなと思います。

鈴木：WebフォントとかWebタイポグラフィとかは、技術者・開発者と、デザイナーの間に落っこちがちなジャンルじゃないかなと、僕は前から思っています。デザイナーは使いたいけど、開発者はパフォーマンスを気にしてあんまり使いたくないとか。あるいはデザイナーの側がWeb技術の知見がなくて、どこまでできるかわからなかったりとか。そういう状況って結構ある気がしています。

そういう中で、ここ数年はWeb業界全体がパフォーマンスにコンシャスになったというか、高いパフォーマンスが求められるようになったりして、僕自身、結構危機感があったりします。このままWebフォントが使われなくなったら残念です。ですので、座談会でも話題に出た新しい技術にも期待していますし、使う側には表現としてこういところで使うといいですよ、といういような良さをアピールしていけるといいかなと思っています。

フォントは、どうしても「読めればいいじゃん」というところに話が行きがちです。たとえばiPhoneならヒラギノとか、Windowsならメイリオがあるので、それで問題なく読める。けれど、ヒラギノにしてもメイリオにしても、だれかが何年も時間をかけて作ったものですよね。そういうフォント業界にも健全にお金が入っていくようにしないと。そういった意味でも、提供する側が、もっと普及と発展に努めていかなきゃというところもあります。フォントというものが廃れないように、がんばっていきたいと思います。

（了）