--- title: "誰も教えてくれない字幕のルール：1秒17文字と、あなたの字幕が慌ただしい理由" description: "読む速さ、行の長さ、最短表示時間。4つの数字が、字幕を快適にも疲れるものにも変えます。放送規格が実際に定めている数値と、自分のファイルを1分で点検する方法。" canonical: "https://speecho.app/ja/blog/subtitle-timing-rules/" language: "ja" author: "Speechoチーム" date_published: 2026-08-13 date_modified: 2026-08-13 publisher: "Speecho" --- # 誰も教えてくれない字幕のルール：1秒17文字と、あなたの字幕が慌ただしい理由 > 読む速さ、行の長さ、最短表示時間。4つの数字が、字幕を快適にも疲れるものにも変えます。放送規格が実際に定めている数値と、自分のファイルを1分で点検する方法。 _Speechoチーム · 2026-08-13 · Canonical: https://speecho.app/ja/blog/subtitle-timing-rules/_ 自動生成された字幕は、たいてい正確なのに読みづらい。言葉は合っているし、タイミングも音声とミリ秒単位で一致している。それでも字幕を出したまま見ていると、なぜか疲れます。これは文字起こしの問題ではなく、タイミングの問題です。そして放送の字幕制作が何十年も使ってきた、4つの数字に行き着きます。 ## いちばん重要な数字：1秒あたり17文字 読む速さがすべてを決めます。60文字の字幕を2秒表示するのは、映像も見ながら1秒に30文字読めと要求しているのと同じです。それは無理なので、視聴者は2つのうちどちらかをします——動画を止めるか、読むのをやめて字幕をただのノイズにするか。 業界がおおむね収束している基準は、成人向けコンテンツで**1秒17文字（17 CPS）**です。Netflixのタイムドテキスト・スタイルガイドにある数値で、私たちの[読みやすさチェッカー](/ja/tools/subtitle-readability-checker/)が既定でこの値を使っています。子ども向けはもっと遅く、13前後が普通です。コメディの速い掛け合いなら数キューだけ超えても問題ありませんが、平均が20 CPSを超えるファイルは、まじめに読む人を確実に消耗させます。 17 CPSで具体的に言うと、こうなります。 | 字幕の文字数 | 最低限必要な表示時間 | |——-|——-| | 30文字 | 1.8秒 | | 42文字 | 2.5秒 | | 60文字 | 3.5秒 | | 84文字（2行いっぱい） | 5.0秒 | 自動生成の字幕がこれを頻繁に破るのは、「読むのにかかる時間」ではなく「音声の切れ目」で区切るからです。長い一文を一息で話す人がいると、90文字・表示3秒というキューができます。同期は完璧、実用性はゼロです。 ## 1行42文字、最大2行 2つめの数字は行の長さです。おおよそ**42文字**を超えると、目が水平方向に動く距離が長くなりすぎて次の行の頭を見失います。スマホでは文字が縮むか、変な位置で折り返されます。 そこから3つめの数字が出てきます。**同時に表示するのは2行まで**。3行の字幕は映像を覆い、読むか見るかの二択を強います。2行×42文字に収まらない文は、1つの字幕ではなく2つです。 そして分割するときは、文法の切れ目で分けること。「その」や「〜の」で改行される行は、読み手に半端な句を抱えたまま行を飛ばさせます。 ``` 悪い例： 良い例： ローンチを3月に ローンチを 延期することにしたのは 3月に延期することにしたのは ``` 縦動画では、2行に抑える理由がもう一つあります。3行の字幕はアプリのUIが隠す帯に届くほどの高さになるからです。[字幕セーフゾーンチェッカー](/ja/tools/caption-safe-zone-checker/)は、その帯を自分のフレームの上に描いて見せてくれます。 ## 4つめの数字：点滅させない 1秒未満で現れて消える字幕は、実際にその長さで発話されていたとしても、点滅にしか見えません。放送実務での下限は**6分の5秒**（約0.83秒）、オンラインなら1秒あればより安全です。「はい。」「ですね。」のような短い相づちこそ、自動ツールが速すぎるタイミングで出してしまうものです。音声が本当にその長さだからです。 対処は、すべてのキューを長く表示することではなく、統合することです。300ミリ秒しか離れていない1語のキュー2つは、1.5秒表示される1つのキューにすべきです。 ## 自動字幕が構造的にここを外す理由 自動字幕は同期を最適化していて、読みやすさは見ていません。各単語がいつ発話されたかを知っているので、波形に合わせてキューを置きます。その結果、音声には完全に忠実で、読み手には無関心な字幕ができます。 - 速く話された長い文は、密度の高い1つのキューになる - 自然な間がそのままキューの境界になる（文の途中でも） - フィラーが独立したミニキューをもらう - そして何も統合されない。読む時間を測っている仕組みがないから 「文字起こしの精度は99%」と「字幕が読みづらい」が同じファイルについて同時に成り立つのは、このためです。 ## ファイルを1分ほどで点検する 400個のキューを目視する必要はありません。SRTかVTTを書き出して[読みやすさチェッカー](/ja/tools/subtitle-readability-checker/)に入れれば、CPSの上限を超えたキュー、行の長さを超えたキュー、行数が多すぎるキュー、最短表示時間に届かないキューを一覧にします。既定値は17 CPS・42文字・2行です。配信先に独自の基準があるなら変更してください。 直す順番はこれです。各ステップが次の作業量を減らします。 1. **点滅を統合する。** 隣接する1秒未満のキュー。 2. **密なキューを分割する。** CPS上限を超えたものは、意味の切れ目で2つに。 3. **長い行を折り返し直す。** 42文字目ではなく、句の切れ目で。 4. **もう一度チェックする。** きれいなファイルなら通過率90%超が普通です。100%を追うのは割に合いません。本当に速い会話で数個速いキューが残るのは問題ありません。 別のツールから違う形式で出てきた字幕は、[字幕コンバーター](/ja/tools/subtitle-converter/)でSRT・VTT・プレーンテキストの間を、タイミングに触れずに変換できます。 ## 数字がカバーしないこと 規格は「何を字幕にするか」については何も言いません。どんなタイミング規則よりも快適さに効く習慣が2つあります。意味を持たないフィラー（「えー」「なんか」）を落とすこと。そして音声なしで見ている人のために、意味のある音——ドア、笑い声、始まる音楽——を字幕にすること。どちらもCPSレポートには現れませんが、「規格に適合した字幕」と「実際に良い字幕」を分けるのはここです。