Subtitle Translator レビュー: 時軸をローカルに固定し、対話文だけを翻訳エンジンへ送る設計

汎用翻訳機に字幕を貼ると壊れる2つの箇所

汎用の翻訳ツールに .srt を貼り付けると、まず時軸が書き換わります。モデルは翻訳の一環としてタイムコード行にも手を入れ、出力を再生すると字幕がずれるか、そもそもパースできなくなります。次に、ファイルが1本ずつしか処理できません。12話のシーズンを揃えるには12回のコピーと貼り付けが発生します。Subtitle Translator はこの2点を別々の方法で潰しています。時軸については、タイムコード、キューの通し番号、ASS のヘッダー、VTT のキュー ID をブラウザ内で抽出し、翻訳エンジンには対話文だけを渡します。README の表現を借りれば「the timeline physically cannot be touched」という状態を作ります。ファイル本数については、複数ファイルをまとめて投入し、各ファイルが独立して翻訳とダウンロードを行う構造にしています。対象は .srt、.ass、.vtt、.lrc で、誰向けかというと、配信作業や個人の視聴用に字幕をまとめて用意する人、あるいは字幕をスクリプトとして二次利用したい人です。

時軸を送らないという制約が生む、できないこと

構造分離は強力ですが、同時にこの道具の限界を決めています。エンジンは対話文しか見ていないので、前の行の長さや表示時間を知りません。そのため、原文より長くなった訳文が画面からはみ出す、といった問題は翻訳後に字幕エディタで調整する必要があります。また、README は .ass について「ASS headers」をローカル抽出すると書いていますが、各イベント行に埋め込まれたインラインのオーバーライドタグ（フォント指定や位置指定など）が翻訳後もそのまま維持されるかは、この資料からは確認できません。バイリンガル出力では、原文の上下どちらに訳文を挿入するかを選べ、SRT/VTT を入力にした場合は原文と訳文で別スタイルを持つ ASS として書き出せます。README が示す既定値は Default 70pt 白、Secondary 55pt シアンで、字幕エディタで変更できるとされています。スタイルを自前で作り込んだ .ass を扱う場合は、この既定スタイルへの置き換えが起きないかを先に確かめるべきです。

翻訳エンジンの選び方: 8種の従来型APIと27種のLLM経路

接続先は性格の異なる2系統に分かれます。従来型は DeepL、Google Translate、Azure Translate、DeepLX、Qwen-MT、TranslateGemma、GTX、Edge の8種です。GTX と Edge は設定不要で、README は両者が互いのフォールバックになると説明しています。つまりAPIキーを1つも持たない状態でも、とりあえず動かすことはできます。ただし無料枠はレート制限付きで、品質評価も従来型の中では低めに置かれています。LLM 系は DeepSeek、OpenAI、Claude、Gemini、Qwen、Moonshot、Doubao、Zhipu GLM、MiniMax、Baidu ERNIE、Tencent Hunyuan、Mistral、xAI、Perplexity、Cohere、YandexGPT などのプロバイダと、OpenRouter、Groq、SiliconFlow、GitHub Models、Nvidia NIM、Azure OpenAI、LiteLLM といったゲートウェイ、そして OpenAI 互換のカスタムエンドポイントです。Ollama や LM Studio、vLLM を自前で立てている場合はここに接続します。ブラウザから CORS で遮断されるプロバイダはリレー経由になり、内蔵リレーが既定で使われ、API Settings の Relay address で自前の Worker に差し替えられます。

コンテキスト翻訳の設定値と、70B という実務上の線

LLM 経路では周辺行をコンテキストとして同送できます。会話のつながりやキャラクターの口調を揃えるための機能で、設定は2つの数値で制御します。Concurrent Lines は同時に翻訳する最大行数で既定20、Context Lines は1バッチあたりに同送する文脈行数で既定50です。README は Concurrent Lines を上げすぎるとレート制限に当たると明記しています。Context Lines を増やせば一貫性は上がりますがトークン消費も増えます。ここで注意したいのは、README 自身が「Models under 70B parameters may produce misaligned output」と警告している点です。行の対応がずれる、つまり訳文が別のキューに紐づく事故が起こり得るということです。この警告は、手元のGPUで完結させたい人にとっては事実上の除外条件になります。コンテキストモードを使うなら、Claude、GPT、DeepSeek、Gemini のような大規模なオンラインモデルが推奨されています。オフライン完結を優先するなら、コンテキストモードを切るか、従来型APIに寄せる判断になります。

ブラウザで動かすか、yarn cli で回すか

配布形態は2つあります。ひとつはホスト版のWebアプリで、URLを開くだけで使えます。README によれば翻訳内容とAPIキーはブラウザ内に留まり、LLMへのリクエストはブラウザから設定したエンドポイントへ直接送られます。翻訳結果は IndexedDB にキャッシュされ、README はこれを「Unlimited Caching」と表現しています。ブラウザのストレージ容量制限に縛られず、ページを再読み込みしても訳文が消えないという意味です。もうひとつはCLIで、yarn cli で同じエンジン、パーサー、キャッシュをターミナルから動かせるとされています。UIは next-intl による多言語化で18言語に対応します。CLI を使う場合は、ブラウザ版で設定したAPIキーやリレー設定がCLI側と共有されるのか、それとも別途設定が必要なのかを、リポジトリのCLI実装で確認する必要があります。この点は提供資料からは判断できません。

無料枠の合計文字数で見る、従来型APIの現実的な使い分け

従来型APIを選ぶ基準として、README は無料枠の文字数を表で示しています。DeepL は月50万文字、Google Translate も月50万文字、Azure Translate は最初の12か月に限り200万文字です。DeepLX は自前ホストか公開エンドポイント、Qwen-MT は Alibaba DashScope の枠、TranslateGemma は LM Studio や Ollama での自前ホストとされています。1話あたりの対話文字数が仮に1万文字程度だとすれば、月50万文字は50話分に相当します。シーズンを数本まとめて処理する程度なら無料枠で収まる計算ですが、継続的に大量処理するなら Azure の初年度枠か、自前ホストの DeepLX、TranslateGemma に移る形になります。品質と安定性の評価はREADMEの表に星で示されていますが、これは運営者の主観的な評価であり、客観的なベンチマークではありません。実際の言語ペアやジャンルによって結果は変わるので、採用前に自分の素材で比較するべきです。

Subtitle Edit や ffmpeg と何が違うのか

比較対象として分かりやすいのは Subtitle Edit のようなデスクトップ字幕エディタです。Subtitle Edit は字幕の編集、同期調整、形式変換をローカルで完結させることを主目的にしており、翻訳機能を備える版もありますが、翻訳エンジンとの接続やLLMプロバイダの切り替えは中心的な設計ではありません。一方の Subtitle Translator は、翻訳と形式変換に機能を絞り、時軸を触らないことを最優先の制約として置いています。編集やタイミング調整は想定していません。ffmpeg は字幕を映像に埋め込む、あるいはストリームから取り出す道具で、翻訳そのものは行いません。つまりこの3つは競合ではなく役割が違います。Subtitle Translator で訳文を作り、タイミングの微調整が必要なら Subtitle Edit に渡し、映像への焼き込みは ffmpeg で行う、という分業が自然です。逆に、字幕の同期ずれを直すためにこのツールを使おうとするのは誤った用途です。時軸は意図的に触らない設計だからです。

MIT ライセンスと、更新頻度から見た保守コスト

ライセンスは MIT です。商用利用を含めて自由に使え、改変や再配布も許されます。ただし、この判断は法的助言ではありません。APIキーの扱いについては別の論点があります。ブラウザ版はキーをブラウザ内に保持し、リクエストを各エンドポイントへ直接送る設計ですが、リレー経由にする場合は自前の Worker を立てるか内蔵リレーを使うかの選択になります。内蔵リレーを経由する場合、リクエストが運営者のインフラを通る点は理解しておく必要があります。更新頻度は高く、提供資料では v3.1.0 が2026年8月23日、v3.1.1 が9月1日、v3.2.0 が9月9日と、およそ1週間から2週間の間隔でリリースされています。頻繁な更新は機能追加の裏返しで、設定項目やプロバイダの挙動が変わる可能性があります。CIに組み込んでCLIを回すなら、バージョンを固定してから上げる運用のほうが安全です。

編集部の結論

採用を検討すべきなのは、シーズン単位で字幕ファイルがまとまって手元にあり、DeepL や Google の既存契約、あるいは自前の LLM エンドポイントをそのまま使いたい人です。逆に、話者ラベルや複数行にまたがる字幕の行内改行を厳密に保持したい案件、70B 未満のローカルモデルしか用意できない環境には向きません。導入前に確認するのは3点です。第一に、自分の .ass ファイルにある独自のスタイル定義やタグ付き行が、翻訳後の出力でどう扱われるかをテスト用ファイルで確かめること。第二に、CLI を使うなら yarn cli が読み込む設定と、ブラウザ版の API 設定が同じ保存領域を共有するのかを確認すること。第三に、CORS で遮断されるプロバイダを使う場合、README が案内する API Settings 内の Relay address に自前のリレー Worker を指定する必要があるかどうかを、実際のエンドポイントで試すことです。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. rockbenben/subtitle-translator on GitHub