動画に字幕を入れる：RendiでSRTを焼き付ける実践ガイド

動画に字幕を入れるときの結論

プレーヤー側の字幕トラック設定に関係なく、すべての視聴者に同じ字幕を見せる必要があるなら、SRTを映像へ焼き付けます。字幕の表示・非表示を切り替えたい、言語を選びたい、プレーヤーのアクセシビリティ機能を使いたい場合は、SRTを分離したまま配信します。

Rendiで確実に進める手順は次のとおりです。

1. 最終版の動画とSRTを組み合わせて確認する。
2. 両ファイルをRendiが取得できるURLに置くか、先にローカルファイルをRendiへアップロードする。
3. 公式ドキュメントに沿ったFFmpeg字幕コマンドを送信する。
4. コマンドIDをポーリングするか、Webhookで最終結果を受け取る。
5. MP4のメタデータを確認し、完成動画を最初から最後まで見てから次のジョブを送る。

この順序は重要です。エンコード自体が成功しても、字幕の表示が早すぎる、名前が間違っている、プラットフォームのインターフェースと文字が重なる、といった問題があれば納品物としては失敗です。

Rendiが担う処理

Rendiが担うのは処理基盤であり、編集作業ではありません。ローカルで実行するものと同じFFmpeg命令をHTTP API経由で渡します。リクエストは作業指示書のようなものです。入力エイリアスが素材の場所を示し、FFmpeg文字列が処理内容を指定し、出力エイリアスが完成ファイルの名前になります。

現在のリクエストスキーマでは、ffmpeg_commandとoutput_filesが必須です。入力キーはin_、出力キーはout_で始まり、その名前をコマンド内の二重波括弧にも記述します。送信に成功するとcommand_idが返り、以後はこのIDでジョブを追跡します。

最も簡単なのは、動画とSRTを、ファイル名まで含む公開HTTP URLまたは有効期限付き署名URLに置く方法です。手元のPCにあるローカルパスは入力URLとして使えません。Rendiにはローカルファイル向けのマルチパート直接アップロードもあり、最大5 TBのファイルに対応していますが、これは別の準備工程です。

焼き付け字幕と切り替え可能な字幕トラックの違い

焼き付け字幕は、デコードされるすべてのフレームの一部になります。見え方を一定にできる一方、その選択は元に戻せません。スペルを直すだけでも動画の再レンダリングが必要で、視聴者が字幕を非表示にすることもできません。

切り替え可能な字幕トラックは映像から分離されたままです。Rendiの字幕例でも、MP4のソフト字幕にはmov_textを推奨し、ビデオフィルターは使っていません。視聴者が表示を選べるうえ、文字を映像へ焼き込まずに済みます。

判断基準は明快です。見え方の統一が必要なレビュー用マスターやSNS配信用ファイルには焼き付け字幕を使います。同時に元のSRTを保管し、アクセシビリティ、検索、翻訳、視聴者による選択が重要な場面では、切り替え可能なトラックまたはサイドカーファイルも提供します。

レンダリング前にSRTを確認する

最も安く済むレンダリングは、やり直さずに済むレンダリングです。古い書き出しではなく、正確な最終カットにSRTを合わせて確認します。キューの順序、開始・終了時刻、人名や数値の表記、意図した改行、アクセント記号付き文字や非ラテン文字の代表例を点検してください。字幕がローワーサードと重なっていないか、画面下端に近すぎないかも確認します。

この工程にAI文字起こしまで含まれると考えてはいけません。音声認識で上流のSRT案を作ることはできますが、文言とタイミングを人または信頼できるレビュー工程が承認してから、このワークフローへ渡す必要があります。ここでのRendiの役割はレンダリングです。

スタイルを指定してRendiジョブを送信する

次のNode.js例では、Rendiが公開しているサンプル動画とサンプルSRTを使うため、実行に必要なのはRENDI_API_KEYだけです。ペイロードはRendiの現行OpenAPIにあるフィールド名とエイリアス規則に準拠しています。force_styleでは、白い文字、黒い縁取り、下部の余白を指定しています。libx264とAACを使い、Rendiの字幕レシピどおりのMP4を生成します。

const headers = {
  "X-API-KEY": process.env.RENDI_API_KEY,
  "Content-Type": "application/json",
};

const submit = await fetch("https://api.rendi.dev/v1/run-ffmpeg-command", {
  method: "POST",
  headers,
  body: JSON.stringify({
    input_files: {
      in_video: "https://storage.rendi.dev/sample/big_buck_bunny_720p_16sec.mp4",
      in_srt: "https://storage.rendi.dev/sample/subtitles.srt",
    },
    output_files: { out_1: "subtitled.mp4" },
    ffmpeg_command:
      "-i {{in_video}} -vf \"subtitles={{in_srt}}:force_style='FontSize=22,PrimaryColour=&H00FFFFFF,OutlineColour=&H00000000,BorderStyle=1,Outline=2,Shadow=0,MarginV=36'\" -c:v libx264 -crf 20 -c:a aac -b:a 192k {{out_1}}",
  }),
});

if (!submit.ok) throw new Error(await submit.text());
const { command_id } = await submit.json();

for (;;) {
  const poll = await fetch(
    `https://api.rendi.dev/v1/commands/${command_id}`,
    { headers: { "X-API-KEY": process.env.RENDI_API_KEY } },
  );
  const job = await poll.json();
  if (job.status === "SUCCESS") {
    console.log(job.output_files.out_1);
    break;
  }
  if (job.status === "FAILED") throw new Error(job.error_message);
  await new Promise((resolve) => setTimeout(resolve, 2000));
}

字幕フィルターはフレームを書き換えるため、動画の再エンコードが必要です。スタイル、コーデック、品質は調整できますが、変更するたびに新しい出力としてレビューしてください。Rendi公式のFFmpegチートシートでは、fontsdirとFontNameによるカスタムフォントも説明されています。ライブラリ全体へ適用する前に、実際に使うフォントとグリフ一式をテストします。

実際に検証した範囲

2026年9月11日時点で、上記のエンドポイント、リクエストフィールド、エイリアス規則、ステータス値、レスポンスフィールドをRendiの現行OpenAPIファイルと照合しました。また、同じ字幕フィルターをFFmpeg 8.0.1で、Rendiの公開サンプル動画とSRTに対してローカル実行しています。結果は16秒、1280×720、H.264映像とAAC音声のMP4となり、5秒時点のフレームには想定どおり字幕が表示されました。

この環境にはRendiのAPIキーがなかったため、Rendiクラウドのジョブは送信していません。コードはスキーマとの整合性を確認済みで、FFmpeg処理もローカル検証済みですが、クラウドでの実行を検証済みとは主張しません。

短いジョブはポーリング、長いジョブはWebhook

Rendiのステータスエンドポイントが返す状態は、QUEUED、PROCESSING、PREPARED_FFMPEG_COMMAND、FAILED、SUCCESSです。POSTが受理されても、完成動画ができたとは限りません。最終状態まで待ち、失敗時はerror_messageを通知し、成功後に限って出力を読み取ります。

Rendiは、完了まで約30秒以下と見込まれるジョブにはポーリング、それより長い処理にはWebhookを推奨しています。Webhookでも、ポーリングと同じ完了済みコマンドデータを受け取れます。本番環境では完了ハンドラーを冪等にし、素早く応答させ、Webhook配信が最終的に失敗した場合の復旧手段としてポーリングも残します。

機密性の高い出力には、有料プランでis_private: trueを設定し、ポーリング時に署名付きURLをリクエストします。初期設定は公開ストレージです。非公開ファイルには恒久的な公開URLがなく、取得するダウンロードリンクの有効期間は最長7日です。

バッチ処理の前に出力を検査する

SUCCESSが証明するのは、FFmpegの処理が完了したことだけです。字幕の品質までは保証しません。機械可読なレスポンスと実際の映像を両方確認します。

まずoutput_files.out_1が存在し、そのstorage_urlを開けることを確かめます。返された再生時間、寸法、コーデック、ファイル形式を、予定している納品仕様と比較します。続いて動画を最初から最後まで視聴し、最初のキュー、最後のキュー、最も速い会話、改行、人名、数値、カットやグラフィックオーバーレイ付近の字幕を重点的に確認してください。

同じスタイルプリセットをキューへ投入するのは、このレビューを終えてからです。ソース動画のリビジョン、SRTのリビジョン、FFmpegコマンド、RendiのコマンドID、出力ファイルID、レビュー担当者の判断をひとまとめに保存します。この記録があれば、レンダリングの寄せ集めを運用可能な制作システムへ変えられます。

料金を決めるのは動画の長さではなくバイト数

Rendiは、入力メディアと出力メディアの合計サイズを計測します。料金例では、1 GBの入力と0.5 GBの出力を合わせて、処理量を1.5 GBとしています。この例と同じ条件なら、Freeプランの50 GB枠では完全なジョブを33件処理して0.5 GBが残り、エントリーProプランの250 GBでは166件処理して1 GBが残ります。

このジョブ件数はRendiの例を使った算術結果であり、字幕処理のベンチマークではありません。実際の焼き付け済みMP4は、ソース、コーデック設定、出力によって大きくも小さくもなります。処理量を予測する前に、自分の入力と出力を合計して測ってください。

Freeは月額$0で、50 GBの処理枠があり、1コマンドの実行時間は1分までです。エントリーProは月額$25、処理枠250 GBで、1コマンドの上限は10分に延びます。CPUを増やす構成や実行時間無制限の構成については、Rendiの料金詳細で扱っているため、ここでは同じ一覧を繰り返しません。

重要なのは運用面での比較です。Kapwing Proは、年払いの場合はメンバー1人あたり月額$16、月払いなら$24と記載されています。たまに単発で処理するなら、ビジュアルエディターのほうが簡単です。承認済み素材を起点に、字幕の仕上げを追跡可能な反復工程として動かし、担当者が毎回エディターを開かない運用にはRendiが向いています。

特に効果が高い7つのワークフロー

字幕を付ける人すべてに最適というわけではありません。すでに承認済みのSRTがあり、最終レンダリングを繰り返しているチームほど大きな効果を得られます。

構築する価値がある3つのプロダクト

1. ブランド基準を守る字幕バッチ仕上げツール

最も有望な機会です。コンテンツチームや制作会社向けに、用途を絞ったポータルを作ります。受け付ける動画URL、承認済みSRT、名前付きスタイルプリセット、レビューページ、ダウンロード可能なMP4を揃えます。売るのは多機能エディターではなく、再現性と承認プロセスです。

米国ではadd subtitles to a videoが月間約1,900回検索され、Kapwing Proは年払いでメンバー1人あたり月額$16からです。ユーザーを獲得できるだけの幅広い需要があり、チームで繰り返す用途は、特化型プロダクトとして成立するほど明確です。

販売可能な最小構成に必要なのは、署名付きURL入力、SRT検証、少数の固定ブランドプリセット、Rendiへの送信、Webhook処理、出力メタデータ、人による承認または却下です。課題は模倣されにくさです。FFmpeg呼び出しを1つのフォームで包むだけなら、簡単にコピーされます。持続的な価値は、承認履歴、再利用可能なブランドルール、リビジョンの対応付け、確実な障害復旧から生み出す必要があります。

2. 自動化を前提にした字幕レンダリングAPI

クライアントへFFmpegの構文を見せたくない制作会社に、安定したエンドポイントを提供します。顧客が動画URL、SRT URL、プリセット名、コールバックURLを送り、サービス側でプリセットをレビュー済みコマンドへ変換し、正規化したジョブ結果を返す仕組みです。

Burn subtitles into videoの米国での検索数は月間40回、CPCは$8.16です。検索数は少ないものの、意図は非常に明確です。PAAにある「SRT字幕を動画へ恒久的に焼き付けるには？」という質問は、ほぼそのままプロダクトへの要望になっています。

MVPには、認証、リクエスト検証、Rendiジョブとの対応付け、冪等性キー、Webhook検証、再試行に耐える状態管理、利用記録が必要です。課題は顧客獲得経路です。検索流入だけでは事業を支えられず、Rendi自身が基盤となるAPIをすでに公開しています。このラッパーは、制作会社向け連携、プリセット、可観測性、サポートで選ばれる必要があります。

3. 字幕の事前検査と2種類の出力をまとめる引き渡しツール

1つのSRTと1つの最終動画を照合するレビューゲートを作り、承認した組み合わせから、焼き付け字幕のレビュー用MP4と、切り替え可能な字幕トラック付きの納品用MP4を生成します。どの字幕リビジョンがどのカットに対応するのか分からなくなる問題を繰り返す、ローカライズ、研修、メディア運用の各チームが購入者です。

実際のPAAにある「SRT字幕を動画に追加するには？」という質問は、現在の検索結果で繰り返されている、恒久字幕と切り替え可能な字幕の混同と隣り合っています。このプロダクトなら、担当者だけでコンテナの仕組みを判断させることなく、両方の用途へ対応できます。

MVPには、キュー解析、再生時間の比較、セーフエリアのプレビュー、リビジョンID、管理された2つのFFmpegレシピ、承認記録が必要です。課題は、基本的なSRT検証だけでは1機能にすぎず、単独の事業にはならないことです。レビュー履歴と引き渡し管理に、チームが公開工程で使い続けるだけの価値を持たせなければなりません。

制約と率直な評価

Rendiは、このワークフローからFFmpegインフラの運用を取り除きますが、編集上の責任まではなくしません。文字起こしの修正、ずれたタイミングの調整、読みやすい改行の選択、アクセシビリティ形式として焼き付け字幕が適切かどうかの判断は行いません。

また、字幕の焼き付けをロスレスにすることはできません。字幕フィルターが動画フレームを書き換えるため、動画は再エンコードされます。品質、実行時間、出力サイズは、コマンドとソース次第です。APIの既定の安全上限は300秒で、実際に指定できる最大値はプランで決まります。長時間または高負荷のジョブには、実際のエンコード時間に見合うコマンド実行上限を持つプランが必要です。

無料のブラウザツールで解決できるカジュアルな単発クリップに、この方法を使う必要はありません。視聴者が字幕を切り替える必要がある場合は焼き付けず、未レビューのスタイルを一括処理してはいけません。同じ承認済みの仕上げルールを多数の素材へ確実に適用するとき、Rendiの強みが生きます。

月曜日にまず試すこと

短い承認済み動画と最終版のSRTを1組用意します。両方を取得可能なURLに置き、選んだスタイルでサンプルペイロードを実行し、返されたメタデータを確認して、対応対象の中で最小の画面でMP4を最初から最後まで視聴します。そのレビューを通過してから、受け入れたコマンドをプリセットとして保存してください。続いて、ワークフロー上ですでに動画と字幕を承認している地点に、そのプリセットを接続します。

レビュー済みのメディア制作パイプラインを事業へ組み込みたい場合は、AI制作システムをご覧ください。