「字幕ファイルをアップロードしてください」。YouTube Studioの画面でそう求められて、初めてSRTという拡張子を検索した。この記事を開いた方の多くは、いまそういう場面にいるのではないでしょうか。動画の編集は覚えたのに、字幕になった途端にファイル形式の話が始まる。少し理不尽に感じるかもしれません。
けれども、SRT(SubRip Text)ほど覚えることの少ないファイル形式もまた珍しいのです。メモ帳で開けて、メモ帳で書ける。もともとはDVDから字幕を抽出するソフト「SubRip」が書き出していた形式で、公式の厳密な仕様書を持たないまま、そのシンプルさゆえに事実上の標準になりました。フランス生まれのソフトだったため、秒の小数点にカンマを使います。この小さな癖が、後で意外と効いてきます。
SRTファイルの中身は4つの要素でできている
SRTファイルとは、この4要素だけで字幕の表示内容とタイミングを表すプレーンテキスト形式です。
実物を見るのが早いでしょう。SRTファイルをテキストエディタで開くと、「キュー」と呼ばれる塊が並んでいます。1つのキューは、連番、タイムコード、本文、空行の4要素だけでできています。
連番:字幕の通し番号です。1から順に振ります。
タイムコード:「00:00:01,000 --> 00:00:03,500」のように、表示の開始と終了を「時:分:秒,ミリ秒」で書きます。矢印の前後には半角スペースが入ります。
本文:画面に表示するテキストです。1行でも2行でも構いません。
空行:次のキューとの区切りです。ここを忘れると、以降の字幕が丸ごと崩れます。
実務上の注意は2つだけです。秒とミリ秒の区切りはピリオドではなくカンマであること。そして文字コードはUTF-8で保存すること。YouTubeもVimeoも、文字化けの原因の多くはこの2点に集約されます。ルールがこれだけしかない形式が、なぜ世界中の動画で使われているのでしょうか。
なぜ、どこでも通じるのか
対応環境の広さは、字幕形式のなかで頭ひとつ抜けています。公開先ではYouTubeとVimeoがどちらもSRTのアップロードに対応しています。編集ソフト側でも、Premiere ProはSCCやTTMLと並んでSRTの読み込みをサポートし、Final Cut ProはCEA-608・iTTとともにSRTをインポートでき、DaVinci ResolveにもSRTの読み込み機能があります。どこで編集し、どこに公開するとしても、SRTを1本持っていればまず困りません。
理由は構造の単純さに尽きます。読み書きのプログラムが半日で書けてしまう形式だから、どのソフトも対応した。多機能な字幕形式が乱立するなかで、いちばん機能の少ない形式が共通言語として生き残ったわけです。ただし、その「機能が少ない」ことは、あとで壁としても現れます。
WebVTTとは何が違うのか
SRTを調べると、必ず隣に現れるのが WebVTT(.vtt) です。見た目はよく似ています。まず目につく違いは小数点で、SRTはカンマ(00:00:01,000)、WebVTTはピリオド(00:00:01.000)。冒頭でカンマの癖に触れたのはこのためで、変換ツールを使わず拡張子だけ書き換えると、この1文字の差で読み込みに失敗します。WebVTTはさらに、ファイル先頭に「WEBVTT」という宣言行を必要とします。
本質的な違いは機能の側にあります。WebVTTはHTML5のvideo要素で使うためにW3Cで標準化された形式で、字幕の表示位置の指定やスタイル付けの仕組みを備えています。自社サイトに動画を直接埋め込み、字幕の見た目まで制御したいならWebVTT。プラットフォームや編集ソフトに渡す持ち運び用にはSRT。現場の使い分けは、おおむねこの線に落ち着いています。
SRTにできないこと
万能に見えてきたところで、できないことを挙げておきます。
ルビ:難読語や人名にルビを振る仕組みはSRTにありません。日本語字幕では意外と切実な制約です。
表示位置:テロップを避けて画面上部に逃がす、話者ごとに位置を変える、といった指定はできません。解釈してくれるプレーヤーもありますが、互換性は保証されません。
文字装飾:色・縁取り・フォントは表示側に委ねられます。斜体などのタグを解釈するプレーヤーもある、という程度に考えておくのが安全です。
そして最大の「できないこと」が放送納品です。テレビ局に字幕データを納める場面ではARIB STD-B36という規格のファイルが求められ、SRTを送るとまず差し戻されます。ルビも表示位置も、放送字幕ではまさに必須の機能だからです。 ARIB STD-B36という規格の考え方 も、あわせて解説しています。Web動画の字幕と放送の字幕は、地続きに見えて別のルールで動いています。
手で書いてみるとわかる、タイミングという壁
ここまで読めば、SRTは今日から手で書けます。実際、数分の動画なら、再生しては止めて時刻をメモし、聞き取ったテキストを打ち込むという繰り返しで完成してしまいます。問題は、それが通用するのは数分の動画までだということです。
10分の動画につく字幕は、切り方にもよりますがおおむね150枚から200枚。1枚ごとに開始と終了を合わせ、読みやすい長さに切り、表示が短すぎないかを確かめる。やってみると、時間を奪うのは書き起こしそのものではなく、「どこで切るか」「何秒出すか」の調整だと気づくはずです。字幕制作の労力の正体は、タイピングではありません。
AIで作るSRTの精度を決めるのは、音声認識だけではない
そこで音声認識の出番です。動画を渡せばSRTが返ってくるサービスは、今や珍しくありません。ただ、「認識精度99%」のような数字だけで選ぶと、納品されたSRTの手直しに結局時間を取られることがあります。字幕の品質は、認識の後の工程で決まる部分が大きいからです。 AI字幕生成の全体の仕組み は別途解説しましたが、SRTの品質に効く工程を挙げるなら次の4つです。
整文:「えー」「あのー」や言い直しを除き、話し言葉を書き言葉に整える工程です。認識が正確であるほど、そのままでは字幕として読めません。
分割:1枚に収める文字数と行の折り返し位置を決める工程です。文節の途中で切れた字幕は、内容が正しくても読めません。
タイミング:表示秒数を読む速さに合わせる工程です。一瞬で消える正確な字幕より、読み切れる字幕のほうが役に立ちます。
辞書:人名・製品名・専門用語を事前登録できるかどうか。固有名詞の誤りは、視聴者の信頼に最も直結します。
並べてみると、手作業の壁だった「どこで切るか」「何秒出すか」が、そのままAIを評価する軸になっていることがわかります。SRTの構造を最初に確認したのは、この判断を自分でできるようにするためでした。生成されたファイルをテキストエディタで開き、切り方と表示秒数を見れば、そのサービスの実力はかなりの部分まで読み取れます。
NAXAの取り組み
NAXAは、放送・映像業界向けのAI字幕生成サービス「Subtitle Generator」を開発・提供しています。音声認識に整文・分割・タイミング調整までを組み合わせて字幕の初稿を生成し、Web動画向けのSRT/WebVTTに加えて、放送向けのARIB STD-B36/NAB形式、編集ソフト連携用のXMEMLでの出力に対応しています。テレビ大阪や北海道文化放送(UHB)などでの導入実績があり、素材を外部に出せない案件にはオンプレミス/オフライン構成も選べます。
SRTは、手で書ける最後の字幕形式かもしれません。だからこそ最初の1本は、手で書いてみる価値があります。そのうえで、次の10本、100本をどう作るかを考える段になったら、AIに任せる工程と人が仕上げる工程の線引きを、私たちと一緒に設計してみませんか。
