字幕の1秒あたりの文字数(CPS):Netflixが定める上限値

1秒あたりの文字数(CPS)とは、字幕の文字数をその字幕が画面に表示されている時間で割った数値です。Netflixは成人向け英語番組を20 CPS、スペイン語を17 CPS、韓国語を12 CPS、簡体字中国語を9 CPS、日本語を4 CPSまでに制限しています。これは恣意的な社内ルールではなく、それぞれの文字体系で1文字がどれだけの言語情報を運ぶかを反映した数値です。

ほとんどの字幕ファイルは、決まって同じ場所で上限を超えます — 翻訳によってテキストが長くなったのに、タイミングはそのままだったときです。

1秒あたりの文字数は実際に何を測っているのか?

計算式がすべてです — 画面に表示されている秒数で文字数を割るだけです。40文字の行を2秒間表示すれば20 CPS、同じ行を4秒間表示すれば10 CPSになります。

ツールによって違うのは、何を「1文字」として数えるかです。ほとんどのツールはスペースや句読点も文字として数えます。キュー内の2行の間の改行まで1文字として数えるツールもあれば、数えないツールもあり、境界線上のキューがあるソフトでは上限超え、別のソフトでは範囲内という食い違いが生まれます。Netflixの韓国語ガイドはさらに一歩進んでおり、ラテン文字はハングルの音節よりも物理的に幅が狭く、行の中で占めるスペースが少ないという理由で、ラテン文字1文字を半分の文字として数えます。

Netflixにはこの問題を反対側から縛るもう2つの数値があります: 1つの字幕イベントの表示時間は最短でも6分の5秒(24fpsで20フレーム)、最長でも7秒、行数は最大2行までと定められています。

これらを組み合わせると、英語のフル長キューが取りうる範囲は算数だけで決まります。42文字の行が2行で84文字。20 CPSを下回るには最低でも4.2秒は表示しなければならず、かつ7秒を超えることもできません。Netflix準拠のファイルにおける最大長のキューは、字幕制作者がそれを意識していようといまいと、すべてこの2.8秒の範囲に収まっています。

言語ごとの上限値

以下はNetflix自身が公開している、言語別のタイムドテキストスタイルガイドから引用したものです:

注目すべきなのは、SDHの上限が低くなるのではなく高くなるという点です。韓国語の通常字幕が12 CPSまでのところ、韓国語SDHは14 CPSまで許容されています。聴覚障害・難聴のある視聴者は、音声を聞きながらではなく字幕を読むことで内容を受け取っているため、テキストに割ける注意力がその分多いのです。これは、多くの人がこの表を初めて見たときに想定することとは正反対です。

配信サービスの外では、BBCの放送ガイドラインは1秒あたりの文字数ではなく1分あたりの単語数(wpm)で表現されており、おおよそ160〜180 wpmとされています。英語は末尾のスペースを含めると1単語あたり平均およそ6文字なので、このガイドラインは16〜18 CPSの範囲に相当します。単位は違っていても、両者の基準は見た目以上に一致しています。

なぜ日本語は4 CPSに制限されているのか?

文字が意味の単位として機能する度合いが、両方の文字体系で同じではないからです。

ラテン文字1文字は単語の断片にすぎません。1秒に20文字は、英語ではおよそ3〜4語分です。一方、漢字1文字は単語1つ分を表すことが多く、ラテン文字で40文字かかる短い日本語の文が、わずか8文字で済むこともあります。したがって日本語の1秒あたり4文字は、英語の1秒あたり20文字とほぼ同じ量の言語情報になります — 上限が違うのは読み手が違うからではなく、単位そのものが違うからです。

同じ論理は1行あたりの文字数にも当てはまります。日本語は1行あたり全角13文字までに制限されているのに対し、英語は42文字、中国語と韓国語は16文字です。全角文字はラテン文字のおよそ2倍の横幅を占めるため、13文字はラテン文字26文字分と見た目の幅がほぼ同じになり、残りの差が情報密度の調整分ということになります。

だからこそ、多言語プロジェクト全体に一律のCPS上限を適用すると、両方向で同時に間違いが生じます。17 CPSに設定すれば、日本語ファイルは予算を4倍以上超過する一方、英語ファイルはそのプラットフォーム自身が許容する範囲より厳しく制限されてしまいます。

速い字幕は本当に理解を妨げるのか?

業界がこれまで想定していたほどには妨げません。しかも、ある1点に関しては、最良のエビデンスはむしろ逆方向を指しています。

PLOS ONE誌に掲載された2018年のアイトラッキング調査では、英語母語話者27人、スペイン語母語話者26人、ポーランド語母語話者21人の合計74人の視聴者を対象に、12・16・20 CPSで字幕をつけたクリップを見てもらいました。理解度のスコアは、この3つの速度の間で有意な差は見られませんでした。参加者は、いずれの速度でも字幕を読みながら映像も見る時間が十分にあったと回答しています。

アイトラッキングのデータからは、本当に意外な結果が得られました。遅い字幕は、速い字幕よりも見返される回数が多かったのです。 12 CPSでは視聴者はおよそ3分の2の字幕を見返していたのに対し、20 CPSではおよそ5分の1でした。読み終えたあとも画面に残り続ける字幕は、目をもう一度そこに引き戻してしまい、本来映像に向けられるはずだった注意力を消費します。

とはいえ、これによって上限そのものが無意味になるわけではなく、その理由もきちんと述べておく価値があります — 1つの研究結果を免罪符にしてはいけません。この研究の対象は、読字に支障のない成人が、実験室の条件下で短いクリップを見たケースです。読み上げ速度の上限は、この研究では測定されていない層のために存在します: 子供、第二言語で視聴している人、弱視やディスレクシアのある人、そして音声という頼れる手段を持たない聴覚障害・難聴の視聴者です。上限とは、最悪のケースを支える下限であって、平均的な視聴者の姿を描写したものではありません。

実務上の教訓はもっと狭く、もっと役に立つものです: 低いCPSの数値に合わせるためだけにキューを間延びさせないこと。 2.4秒で無理なく読める行を4秒間表示しても、誰の得にもなりません。

翻訳がCPSを崩す理由

実際のプロジェクトにおけるCPS違反のほぼすべては、もともとは正しくタイミング調整されたソースファイルから始まります。

翻訳するとテキストは長くなります。英語からスペイン語やフランス語への翻訳は通常20〜25%長くなり、ドイツ語は複合語が句をまるごと置き換えることもあって35%に達することもあります。短い文字列は、長い文字列よりも比率にして大きく膨張します — W3Cのローカライズガイドラインは、viewsがvisualizzazioniになる例、つまり5文字が15文字になる例でこの点を指摘しています。そして字幕のキューは、定義上まさに短い文字列です。

ごく普通の1行で、実際に計算してみましょう:

• 42文字の英語のキューを3秒間表示すると14 CPS。快適な範囲です。
• 同じキューがスペイン語で25%膨張すると、同じ3秒間で53文字になり、17.5 CPS――スペイン語の上限を超えています。
• ドイツ語で35%膨張すると57文字になり、19 CPSです。

タイミングは一切動いていません。同期は完璧です。ただ、そのキューが単純に読み切れなくなっているだけであり、何も同期はズレていないのでタイミングチェックツールは何の問題も報告しません。これこそが、あらゆる自動チェックを通過しているのに、翻訳された字幕ファイルがオリジナルよりも出来が悪く感じられる、最も多い原因です。

だからこそ、言語ごとに文字起こしをやり直すのではなく字幕ファイルを翻訳するというアプローチをとっても、まだやるべき作業は残ります。タイミングを保持すること自体は正しい選択ですが、それは負担のすべてを文言側に移しているだけだからです。同じ動画を複数言語で公開するなら、読み上げ速度のチェックは1回で終わる作業ではなく、言語ごとに行う作業です。

読み上げが速すぎるキューを直す方法

直すのはテキストか表示時間です。同期は変えないでください。

アウト点の延長がまず最初の一手になるのは、たいていコストがかからないからです。字幕はセリフが終わると同時に終える必要はなく、次のキューまでの間隔は使われていない空白の時間です。そこにアウト点を押し込むことで、誰にも負担をかけずに読む時間を稼げます。

短縮は2番目の一手であり、スキルが求められる作業です。字幕は文字起こしではありません。話し言葉特有のフィラーや冗長な代名詞、繰り返される名前を削ぎ落とすのは通常の作業であり、妥協ではありません。決して許されないのは、数値を合わせるために内容そのものを削ることです — 意味が収まらないなら、必要なのは分割であって、切り詰めではありません。

焼き込み出力に特有の落とし穴が1つあります: いったんキューが映像に焼き込まれると、その読み上げ速度は変更できなくなります。ソフト字幕ファイルであれば、あとからテキストエディタで再タイミングできます。ハードサブはフル再レンダリングが必要になるため、読み上げ速度のチェックは書き出しの後ではなく前に済ませておくべきです。

編集しながら読み上げ速度を確認する

CPSの数値は、行を書いているまさにそのときに表示されてこそ意味を持ちます。だからこそ、別工程の品質チェックではなく、エディタ自体に組み込まれているべきものです。

Sablateはエディタ内で選択中のキューの読み上げ速度を表示し、17 CPSを超えるものは快適とされる範囲を超えたとしてフラグを立て、表示時間を延ばすかテキストを短くするよう提案します。計算方法は単純で、キュー内のすべての文字(スペースと改行を含む)を表示時間で割るだけなので、空白を無視するツールよりも数値はわずかに高めに出ます。翻訳は別ジョブではなく同じタイムライン上のレイヤーであるため、この警告は元のタイミングがすでに設定された翻訳レイヤーの上で表示されます — つまり、まさに問題が現れるその瞬間に発生するということです。

ただし、正直に言えば2つの限界があります。この閾値はすべての言語で一律17という数値であるため、英語に対しては厳しすぎ、日本語・中国語・韓国語に対してははるかに緩すぎます — ラテン文字系言語向けの目安として扱い、それ以外の言語は上の表を参照してください。そしてこれは警告するだけで、直してはくれません。Subtitle Editは無料で、1秒あたりの文字数の上限を自分で設定でき、プラットフォームごとに切り替えられるルールプロファイルも備えています。読み上げ速度への準拠が作業の一工程ではなく作業の中心そのものであるなら、そちらの方が柔軟に設定できるツールであり、しかも無料です。

キューを上限内に収める自動リフロー機能はProの一部で、料金ページに記載のとおり$29の一度きりの支払いで利用できます。

まとめ

文字数を秒数で割った数値であり、実用上の上限はラテン文字系で17 CPS、韓国語で12 CPS、中国語で9 CPS、日本語で4 CPSです。チェックすべきは文字起こしの後ではなく翻訳の後です — そここそが崩れる場所であり、タイミングは正しいままテキストだけが20〜35%長くなるからです。直すときは、まずアウト点を延長し、次に文言を短くし、それでも足りなければキューを分割してください。