文字起こしの出力形式：TXT、SRT、VTT、JSON

完成した文字起こしは6種類ほどの形式で納品でき、どれが適切かはその後の用途次第です。動画プレイヤーに埋め込む？SRTかVTTを使いましょう。ブログ記事に載せる？TXTかDOCXです。別のツールに入力する？JSONを選びましょう。このリファレンスでは、各形式に実際何が含まれているのか、どこで使われるのか、そして人がつまずきやすい癖について解説します。

TXT：プレーンテキストの定番

最もシンプルな形式です。話者ラベルと段落タイムスタンプを任意で付けられる、単なるテキストです。

[00:00:00] Speaker 1: Welcome back to the show. Today we're talking about pricing.

[00:00:18] Speaker 2: Thanks for having me. Pricing is one of those topics...

TXTは音声から読めるテキストへの最短ルートです。 特別なプレイヤーやライブラリは不要で、どんなエディタ、CMS、メールクライアントにもコピー＆ペーストできます。

TXTで失うもの：

• 動画同期のための細かいタイミング情報がない。
• 機械可読な構造がない（すべてが文字列）。
• ツールによってレイアウトが微妙に異なり、バッチ処理では問題になる。

TXTはブログ記事、ショーノート、議事録など、人間がファイルを読む場面すべてに向いています。このトレードオフが価値あるものになる状況を詳しく知りたい方は、無料vs有料の文字起こしサービスをご覧ください。

DOCX：書式付きのTXT

Microsoft Word形式です。中身はTXTと同じですが、スタイル付き見出し、話者名の太字、場合によってはメタデータ（ファイル名、日付、長さ）入りのヘッダーが付きます。

DOCXは人力文字起こしサービスの標準的な納品形式です。 法廷記録者、法務系文字起こし業者、学術系文字起こし会社はほぼ必ずDOCXで送ってきます。技術背景のないクライアントが開くことを期待する形式でもあります。

AIツールにとって、DOCXはスタイルが付いただけのTXTにすぎません。精度も内容も同一で、Wordで見た目がきれいになるだけです。受け取り手がテキストを編集するなら、Wordの変更履歴やコメント機能が正しく使えるため、PDFよりもDOCXの方が優れています。

SRT：汎用の字幕形式

SubRip Subtitle。現在最も広くサポートされている字幕形式です。YouTube、Vimeo、Premiere、Final Cut、DaVinci ResolveはすべてSRTを受け付けます。

形式：

1
00:00:00,000 --> 00:00:03,500
Welcome back to the show.

2
00:00:03,500 --> 00:00:09,200
Today we're talking about pricing models for small businesses.

各キューは4つの要素で構成されます：

1. キュー番号（1、2、3、…）。
2. HH:MM:SS,mmm形式の開始時刻 --> 終了時刻（小数点区切りがピリオドではなくカンマである点に注意）。
3. テキスト（1行以上）。
4. キューを区切る空行。

SRTの癖：

• 小数点区切りはカンマで、ピリオドではない。 00:00:03,500であり、00:00:03.500ではありません。これが最も多いSRT構文エラーです。ピリオドを使ったファイルをパーサーが拒否することは珍しくありません。
• 仕様に話者ラベルはない。 多くのツールはSpeaker 1: Welcome backのようにテキスト内に話者ラベルを埋め込みます。インラインで表示するプレイヤーもあれば、削除してしまうものもあります。
• 改行が重要。 ほとんどのプレイヤーは1キューにつき1〜2行を表示します。3行のキューは途切れたり、意図以上に映像を覆い隠したりすることがあります。
• 1行あたりの文字数制限。 小さい画面での可読性のため、慣習では1行32〜42文字です。
• キューの長さ。 1キューあたり通常2〜7秒です。1語だけのキューはギクシャクした印象になり、7秒を超えるキューは読む速度が追いつかなくなります。

プロフェッショナルな納品でSRTを受け付けないプラットフォームのひとつがNetflixです。Netflixは字幕納品にTTML1（拡張子.xmlまたは.ttml）を要求しています。Netflix担当者による明示的な例外がない限り、SRT、VTT、SCCはNetflixへの納品では受け入れられません。これはよくある誤解です。

SRTはYouTubeへのアップロード、動画編集ソフトへの取り込み、そして大半の一般向け動画プラットフォームに使用しましょう。

VTT：WebネイティブなSRTの親戚

WebVTT。W3C仕様で定義された、ブラウザ内キャプションのHTML5標準です。機能的にはSRTと似ていますが、構造と能力に顕著な違いがあります。

形式：

WEBVTT

00:00:00.000 --> 00:00:03.500
Welcome back to the show.

00:00:03.500 --> 00:00:09.200
Today we're talking about pricing models for small businesses.

SRTとの主な違い：

• 小数点区切りはピリオドで、カンマではない。 00:00:03.500。SRTとは正反対です。両者間の変換で最も混乱を招くポイントです。
• WEBVTTヘッダーが必須。 ファイルは「WEBVTT」という文字列で始まり、その後に2つ以上の改行が続く必要があります。これがなければ有効なVTTファイルではありません。
• キュー識別子は任意。 キュー番号が慣習的に（厳密には必須でなくとも）使われるSRTと異なり、VTTでは不要です。
• ボイスタグに対応。 <v Speaker 1>Welcome back.</v>は、W3Cで正式に定義された話者ラベルの付け方です。CSS疑似要素を使えば、プレイヤー側で話者ごとに異なるスタイルを適用できます。
• スタイリングに対応。 イタリック、太字、色などのHTML風タグをキュー内で使えます。
• キューセッティングに対応。 位置、揃え、縦書きテキストをキューごとに指定できます。

VTTはHTML5の<track>要素が想定する形式です。ネイティブのvideo要素を使ってサイトに字幕を埋め込むなら、ブラウザがネイティブに理解できるのはVTTです。YouTubeはVTTも受け付けますが、新規クリエイターにはSRTを推奨しています。

この2つの形式とTTMLの詳しい比較については、SRT vs VTT vs TTMLをご覧ください。

TTML：放送業界の標準

Timed Text Markup Language。プロの放送局やストリーミングプラットフォームが求める、W3CのXMLベース形式です。DFXP（Distribution Format Exchange Profile）とも呼ばれますが、これはTTMLの特定プロファイルです。

TTMLは複雑なスタイリング、精密な画面位置指定、アクセシビリティ用メタデータ（SDHマーカー、話者識別）、1つのファイル内に複数言語トラックを持つことに対応しています。Netflixは全言語でTTML1を要求しており、BBC iPlayerやHuluもプロフェッショナルな納品でこれを要求します。

YouTubeへアップロードしたり自分のサイトに埋め込んだりするほとんどのクリエイターにとって、TTMLは必要ありません。重要になるのは、正式な納品仕様を持つ放送パートナーやプラットフォームへコンテンツを納品するときです。YouTubeはTTMLとDFXPも受け付けますが、ほとんどのクリエイターのワークフローはSRTかVTTで足ります。

JSON：機械可読形式

開発者にとって、JSONはロスレスの書き出し形式です。文字起こしエンジンが知っているすべての情報が、構造化され、クエリ可能な形で入ります。

{
  "transcript": "Welcome back to the show...",
  "words": [
    {"word": "Welcome", "start": 0.020, "end": 0.380, "confidence": 0.998, "speaker": 0},
    {"word": "back", "start": 0.380, "end": 0.640, "confidence": 0.997, "speaker": 0}
  ],
  "utterances": [
    {"speaker": 0, "text": "Welcome back to the show.", "start": 0.020, "end": 1.880}
  ],
  "metadata": {
    "duration": 1845.2,
    "language": "en",
    "model": "whisper-large-v3"
  }
}

JSONには、SRTとTXTでは持てない情報が含まれます。単語レベルのタイムスタンプ、単語ごとの信頼度スコア、話者割り当て、発話グループ化、モデルのメタデータです。AI対応エンジンからの任意フィールドには、トピック、センチメント、要約などもあります。

文字起こしデータの上に何かを構築する場合——独自の動画プレイヤー、検索インデックス、AIパイプライン、データ分析など——にはJSONを使いましょう。冗長な形式ですがロスレスです。文字起こしサービスがJSONを保存していれば、後から音声をエンジンにかけ直すことなく、SRTやTXTへ再書き出しできます。

PDF：洗練された納品物

PDFの文字起こしは、DOCXをPDFに書き出すことで生成されます。プロフェッショナルな見た目になり、書式が固定され、多くの法務系・学術系クライアントが期待する納品形式です。

PDFを使う場面：

• 法務関係や裁判所への提出書類。
• 学術研究の成果物。
• レイアウト固定が重要なクライアント向けレポート。
• アーカイブ保存（テキストが埋め込まれており、スキャン画像でないことが前提）。

PDFを使うべきでない場面：

• 受け取り手がテキストを編集する場合。PDFの編集は遅くミスも起きやすいため、代わりにDOCXを渡しましょう。
• 受け取り手が別のツールに入力する場合。JSONやTXTの方が互換性が高いです。

どの形式をいつ使うか

迷ったら、TXTとSRTの両方を書き出しましょう。どちらも小さなファイルなので、文字起こしをやり直すことなく、動画とテキスト両方のワークフローに対応できます。

キューの長さと改行

初めて字幕付けをする人が必ずつまずくのがここです。 多くのツールのデフォルト設定は、キューが長すぎたり短すぎたり、小さい画面で不自然に折り返されるSRTやVTTファイルを生み出しがちです。特にタイミングの判断については、文字起こしでタイムスタンプを使うべきときをご覧ください。

ベストプラクティス：

• キューの長さ： 2〜6秒。1語だけのキューはギクシャクした印象になり、7秒を超えると読む速度が高くなりすぎます。
• 1行あたりの文字数： 慣習では32〜42文字。42文字を超えるとモバイルで折り返しが不自然になります。
• 1キューあたりの行数： 最大2行。3行のキューは映像を覆いすぎます。
• 毎分ワード数： 読了速度は毎分160〜180ワードを目安に、キューの長さを話者の話すペースに合わせて調整します。

最近のツールの多くは妥当なデフォルト値を出力します。キューがおかしく出てくる場合は、手作業で編集する前に「行の長さ」や「読了速度」の設定を探してみましょう。

形式の変換

形式間の移行はたいてい手軽ですが、常にロスレスというわけではありません：

• TXT⇔DOCX： Wordは両方をネイティブに扱えます。情報は失われません。
• SRT⇔VTT： 単純なテキスト変換です。カンマとピリオドを入れ替え（またはその逆）、WEBVTTヘッダーを追加・削除するだけ。どんなスクリプト言語でも1行で書けます。
• JSON→TXT/SRT/VTT： ほとんどの文字起こしツールが自動で行います。JSONが唯一の信頼できるソースであり、他のすべての形式はそこから派生します。
• TXT→SRT/VTT： テキストを音声に再アラインする必要があり、元のタイミングデータが要ります。音声か元のJSONがなければ不可能です。
• PDF→その他： テキストから生成されたPDFの場合のみ確実です。スキャンPDFはOCRが必要で、書式は失われます。

ConvertAudioToTextを使えば、1回の文字起こしからTXT、SRT、VTT、JSON、DOCXを書き出せるため、言語や話者数などの設定を変えたときだけエンジンを再実行すればOKです。また、字幕ジェネレーターツールから直接字幕ファイルを生成することもできます。

FAQ

SRTとVTTの違いは何ですか？

どちらもほぼ同じ構造を持つタイムコード付きキャプション形式です。SRTはタイムスタンプの小数点区切りにカンマ（00:00:03,500）を使い、キュー番号が必須です。VTTはピリオド（00:00:03.500）を使い、キュー番号は任意で、ファイル先頭にWEBVTTヘッダーが必要で、さらにボイスタグ、CSSスタイリング、画面上の位置指定に対応しています。SRTはデフォルトでより多くのプラットフォームで動作し、VTTはHTML5 video要素のネイティブ形式です。

YouTubeにはどの形式を使うべきですか？

YouTubeでは実用上SRTがデフォルトです。YouTubeはVTT、SBV、TTMLなど複数の放送用形式も受け付けていますが、字幕付け初心者のクリエイター向けにYouTube自身のヘルプドキュメントが推奨しているのはSRTです。多くの書き出しツールが対応しており、特別な設定も不要です。

NetflixはSRTファイルを受け付けていますか？

いいえ、プロフェッショナルな納品では受け付けません。Netflixは字幕ファイルにTTML1（拡張子.xmlまたは.ttml）を要求しています。Netflix担当者による明示的な例外がない限り、SRT、VTT、SCCは受け入れられません。Netflixへコンテンツを納品する場合は、Netflix Partner Help Centerで最新のTTML仕様を確認してください。

JSON形式の文字起こしには、SRTやTXTにはない何が含まれていますか？

JSONには単語レベルのタイムスタンプ、単語ごとの信頼度スコア、話者割り当て、発話グループ化、モデルのメタデータが含まれます。SRTは単語レベルの詳細を持たない時間指定テキストブロックのみ、TXTは話者ラベル（任意）と段落タイムスタンプ（任意）付きの単語のみを持ちます。検索機能の構築、NLP分析、独自プレイヤーの動作などを行うなら、全データを含むのはJSONだけです。

文字起こしを再実行せずに形式間の変換はできますか？

ほとんどの変換は可能です。文字起こしサービスがJSONを保存していれば、SRT、VTT、TXT、DOCXはすべて元のJSONから音声に触れずに再生成できます。逆方向に変換できないのはTXTからSRTまたはVTTへの変換です。単語レベルのタイミングデータがなければ、タイムスタンプを正確に配置する方法がありません。

参考資料

• W3C WebVTT仕様： https://www.w3.org/TR/webvtt1/
• Netflix Timed Text スタイルガイド（一般要件）： https://partnerhelp.netflixstudios.com/hc/en-us/articles/215758617-Timed-Text-Style-Guide-General-Requirements
• Netflix IMSC 1.1 テキストプロファイル： https://partnerhelp.netflixstudios.com/hc/en-us/articles/360053755033-Netflix-IMSC-1-1-Text-Profile
• YouTubeがサポートする字幕およびクローズドキャプションファイル： https://support.google.com/youtube/answer/2734698
• MDN WebVTT APIドキュメント： https://developer.mozilla.org/en-US/docs/Web/API/WebVTT_API/Web_Video_Text_Tracks_Format