同じ動画を三つの配信先に納めたら、字幕ファイルの指定が三通りだった。YouTubeにはSRTで上げられた。ところが同じファイルを自社サイトのHTML5プレーヤーに読み込ませると、エラーも出ないまま字幕だけが一行も表示されない。プレーヤーの仕様書を確かめると、対応形式の欄に見慣れない拡張子が書いてあります。.vttです。
その正体がWebVTT(Web Video Text Tracks)です。Webブラウザでの字幕表示のために設計されたファイル形式で、土台になったのはSRTでした。 SRTファイルそのものの書式と作り方 には深入りせず、ここでは両者がどこで分かれるのか、そして納品のたびに迷わないための使い分けを、実物のテキストで確かめていきます。
WebVTTとはどんな形式か。SRTとの違いを実物で見る
WebVTTはW3Cが仕様を管理する字幕形式です。もともとはWebSRTという名前で提案された経緯があり、見た目はSRTとよく似ています。並べてみましょう。SRTのキューは「1」という連番で始まり、次の行に「00:00:05,000 --> 00:00:08,000」というタイムコード、その下に字幕本文が続きます。WebVTTで同じキューを書くと、タイムコードは「00:00:05.000 --> 00:00:08.000」になる。ミリ秒の区切りがカンマからピリオドに変わっただけです。連番はどうか。WebVTTでは任意で、書けばキュー識別子として扱われ、省いても構いません。
もう一つの違いはファイルの先頭にあります。WebVTTは1行目に「WEBVTT」という宣言を置くことが必須です。SRTにはこの種のヘッダーがなく、いきなり最初のキューから始まります。逆に言えば、テキストエディタで開いて1行目を見れば、どちらの形式かは一瞬で判別できるということです。
区切り文字が一つ、宣言が一行。それだけの差に見えますが、プレーヤーは容赦なくここで読み込みを拒否します。
そして書式の外側では、仕様の厚みが別物です。WebVTTのタイムコード行には「line:0 position:50% align:center」のような表示設定を書き足せて、字幕を画面上部に逃がしたり、左右どちらかに寄せたりできます。CSSの::cue擬似要素を使えば、Webページ側から文字色や背景を指定することも可能です。話者ごとに色を変える、テロップと重なる位置だけ字幕を上に移す、といった調整をファイルとスタイルの側で完結できる。SRTは素のテキストと最小限のタグしか持たないので、装飾や配置を指定したくなった時点で守備範囲を超えます。
どちらを使うべきかは、ファイルの行き先で決まる
では、どちらで納品すべきなのでしょうか。HTML5の<track>タグ、つまりブラウザで直接再生する動画に字幕を付けるなら、選択の余地はありません。ブラウザが解釈するのはWebVTTだけで、SRTを指定しても黙って無視されます。冒頭のプレーヤーで字幕が出なかった理由がこれです。
ストリーミング配信でも事情は同じです。 HLSやDASHといった配信方式 では、映像や音声と同じように字幕も細かく分割して配信しますが、HLSでその字幕セグメントに使われるのはWebVTTです。ブラウザ再生でもアプリ配信でも、Webの世界に出ていく字幕はWebVTTがほぼ共通語になっています。
なら全部WebVTTでよいかというと、そうもいきません。編集ソフトへの字幕搬入や、制作会社・翻訳会社とのデータの受け渡しでは、いまだにSRTが共通語です。対応ソフトの層の厚さではSRTに分があり、古い編集環境や変換ツールまで含めれば「とりあえずSRTなら読める」場面は多い。YouTubeのようにSRTもWebVTTも受け付けるプラットフォームもあります。テレビの放送波に載せる字幕はそもそもARIB規格の別世界なので、どちらの出る幕でもありません。
整理すると、Webに出すならWebVTT、制作・編集の工程内で回すならSRT、という分かれ方になります。 AI字幕生成の全体像 を見ても、字幕データそのものは一つで、書き出す形式を配信先ごとに切り替えるのが実務の形です。だからこそ、両形式の間を安全に行き来できることが重要になります。
SRTからWebVTTへ変換するときの注意点
変換そのものは単純な作業です。単純なのに、手作業やスクリプトでやると決まって同じ場所で転びます。
一つめは、さっき見たタイムコードのカンマです。「00:00:05,000」を「00:00:05.000」に直す必要がありますが、エディタの一括置換で全カンマをピリオドに変えてはいけません。字幕の本文にもカンマは普通に現れるからです。置換の対象はタイムコード行だけに限定します。
二つめはヘッダーです。ファイルの先頭に「WEBVTT」の行と、その直後の空行を書き足します。この宣言はファイルの最初に置かなければならず、前に何か挟まっているとファイル全体が不正扱いになります。
三つめが文字コードで、日本語字幕では実はここが最大の落とし穴です。WebVTTはUTF-8が前提の形式ですが、国内の制作現場から届くSRTにはShift_JISで保存されたものが混ざっています。拡張子とタイムコードだけ直して中身の文字コードを直し忘れると、プレーヤー上の字幕は文字化けの列になります。UTF-8で保存し直すこと。先頭のBOMは仕様上は許容されますが、その場合もBOMの直後にWEBVTTの宣言が来ている必要があるため、変換ツールを通した後は実際のプレーヤーで一度表示を確かめるのが確実です。
最後に連番です。SRTの各キューに付いている番号は、WebVTTでは残しても消しても動きます。残せばキュー識別子として読まれるだけです。ただし後工程のチェックや修正指示が「キュー番号の何番」というやり取りに依存しているなら、残しておくほうが安全でしょう。
NAXAの取り組み
NAXAのAI字幕生成・文字起こしサービスは、独自の音声認識エンジンで文字起こしからタイムコード付与、話者認識、ルビ振りまでを自動化し、各局・各社の制作ルールに合わせてカスタマイズして提供しています。仕上がった字幕データをどの形式で書き出すかは、まさに本記事で見てきた「配信先ごとの指定」の問題で、カンマとピリオドの置換や文字コードの統一のような細部こそ、人手から外して自動化する価値のある部分です。
SRTとWebVTTのどちらが優れているかを論じ始めると、答えは出ません。決めるのは常にファイルの行き先です。納品仕様書のフォーマット欄を最初に確認する。字幕の実務は、結局そこから始まります。Web配信向けの字幕制作や、形式変換を含む字幕ワークフローの自動化に関心のある方は、お気軽にご相談ください。
