記事公開日
Fast TranscriptionとAzure Translatorで動画の翻訳字幕生成アプリを作ってみた
この記事のポイント
Azure の Fast Transcription と Azure Translator を組み合わせて、動画の翻訳字幕を生成するアプリを作成しました。
筆者が検証した構成の選定理由と、翻訳が不自然にならないコツを紹介します。
- 目的に合うサービスを選ぶ：
録画済みの動画から字幕だけを作るなら、Fast Transcription ＋ Azure Translator が扱いやすい構成です。公式ドキュメントでは、Fast Transcription の入力は長さ 5 時間未満・サイズ 500 MB 未満のオーディオ ファイルとされています。 - 各ステップの成果物を残す：
文字起こしと翻訳の結果をファイルに残すことで、エラー時は一つ前から再開でき、翻訳だけ・字幕だけの再実行もできます。 - 「文単位で翻訳してから分割」の順番にする：
字幕向けの整形を翻訳より先に行うと、文の途中で切れた断片が翻訳されて不自然になります。LLM で文単位に区切ってから訳し、そのあとで行を分けることで、自然な字幕になりました。
こんにちは。DXソリューション営業本部の野村です。
海外の動画を見たいのに、日本語字幕がないなんて経験はありませんか？
字幕を手作業で付けるのは時間がかかりますし、専用サービスを使うにしても、どれが自分の用途に合うのか迷いますよね。
そこで筆者は、Azure の「Fast Transcription（高速文字起こし）」と「Azure Translator（翻訳サービス）」を組み合わせて、動画の翻訳字幕を生成するアプリを作ってみました。
本記事では、この構成を選んだ理由、アプリの処理フロー、そして修正前の実行で見つかった「文が中途半端に切れて翻訳が不自然になる」課題とその修正を、実際の画面とあわせてご紹介します。
翻訳字幕を低コストで作る方法を探している方や、Azure の音声・翻訳サービスの使い分けを知りたい方の参考になれば幸いです。
なぜ Fast Transcription ＋ Azure Translator なのか
既存の動画ファイルから翻訳字幕を作るなら、筆者は Fast Transcription ＋ Azure Translator の組み合わせが扱いやすいと考えています。
音声ファイルの文字起こしを素早く行い、翻訳は文字数ベースで別サービスに任せるため、必要な処理だけに費用と時間をかけられるからです。
Azure で動画の翻訳字幕を作る方法は、大きく分けて次の3つが候補になります。
それぞれの特徴を、筆者なりに整理したのが次の表です。
| 比較項目 | ① Fast Transcription ＋ Azure Translator | ② Speech Translation API | ③ Azure AI Video Indexer |
|---|---|---|---|
| 主な設計思想 | 事後処理・高速な字幕化 録音・録画済みのファイルから字幕を作成 |
リアルタイム通訳・ストリーミング 音声入力と同時に翻訳 |
動画の多角的な AI 分析・管理 音声と映像のメタデータを統合して抽出 |
| 入力データ | 録音・録画から取り出した音声ファイル（WAV、MP3 など） | リアルタイムの音声ストリーム、音声ファイル | 動画・音声ファイル（Blob Storage 経由など） |
| 処理方式 | 同期処理 リクエストに対して、音声の長さよりも短い時間で結果が返る |
ストリーミング 話している最中に、低遅延で文字・翻訳を出力 |
非同期バッチ ジョブを投稿し、解析の完了を待つ |
| タイムスタンプ | 単語・フレーズ単位の開始／終了時間を取得できる | リアルタイムで逐次出力・翻訳されるため、文全体の正確な開始/終了タイミングを取得できない | 時間軸に紐づいた字幕・メタデータを出力できる |
| コストの目安 | 低〜中 音声の処理時間と翻訳文字数に応じた従量課金 |
低〜中 ストリーミング処理時間に応じた課金 |
音声解析のみ：低～中 映像解析込み：高め 動画時間に応じた課金 |
| 映像解析（OCR・顔検出など） | なし | なし | あり（顔検出、OCR、ラベル識別など） |
| 手動編集用の UI | なし | なし | Web 画面上で字幕を確認・修正できる画面部品がある |
※上の表は筆者による整理です（2026年10月時点）。
コストや機能の詳細は変更される可能性があるため、導入時は各サービスの公式ドキュメントと料金ページを事前にご確認ください。
使い分けの目安：
既存の動画ファイルから、高速かつ低コストに字幕を作りたいなら ① です。
ライブ配信や Web 会議など、「いま話している声」をその場で翻訳したいなら ② です。
字幕だけでなく、人物識別や画面内テキスト（OCR）、トピック分析まで含めて動画全体を検索・管理したいなら ③ が向いています。
公式ドキュメントでも、Fast Transcription は「音声またはビデオの文字起こし、字幕、編集を簡単に行う」ような、録音の文字起こしを予測しやすい待ち時間でできるだけ早く得たい場面に使うと説明されています（高速文字起こしの使用）。
また、Video Indexer は顔検出や OCR などの映像モデルまで含めた分析サービスです（Azure AI Video Indexer の概要）。
今回は「字幕だけ欲しい」という目的だったため、① を選びました。
なぜ文字起こしと翻訳を分けるのか：
文字起こし（音声をテキストにする処理）と翻訳（テキストを別の言語にする処理）を別々のサービスにすると、間に自分で処理を挟めるようになります。
たとえば、翻訳前の文章を整えたり、翻訳だけを何度もやり直したりできます。
この「間に手を入れられる」性質が、後述する課題の修正で役立ちました。
音声ファイルの文字起こしは Fast Transcription、翻訳は Azure Translator に任せる、という役割分担です。
では、実際にどのようなアプリにしたのか、次の章で処理フローを見ていきましょう。
作成したアプリの全体像と処理フロー
作成したアプリは、動画ファイルを渡すと、翻訳字幕付きの動画を再生できる HTML ファイルを出力するコマンドラインアプリです。
簡易的に作ったため、英語から日本語への翻訳のみ、字幕を付けるまでの操作用の画面は作成していません。
処理は5つのステップに分かれており、各ステップの成果物をファイルとして残す構成にしています。
字幕の出力では、字幕用のテキスト形式である vtt（WebVTT）ファイルを、英語と日本語それぞれ作成します。
| 手順 | 処理 | 成果物 |
|---|---|---|
| 1 | 動画ファイルを受け取り、音声ファイルに変換する | 音声ファイル |
| 2 | 音声ファイルを Fast Transcription で文字起こしする | transcript.json |
| 3 | 文字起こしされた内容を Azure Translator で翻訳する | translated.json |
| 4 | 翻訳結果から、英語字幕と日本語字幕を出力する | en.vtt（英語字幕）、jp.vtt（日本語字幕） |
| 5 | 字幕付きの動画を再生できる HTML ファイルを出力する | 字幕付き再生用 HTML |
各ステップの成果物を残しておくと、エラーが起きたときに、一つ前の成果物から処理を再開できます。
たとえば翻訳でエラーになっても、文字起こしからやり直す必要はありません。
また、翻訳だけ、字幕の HTML 出力だけを再実行することもできます。
なぜ動画を音声ファイルに変換するのか：
公式ドキュメントでは、Fast Transcription の入力は「オーディオ ファイル」（WAV、MP3 などの音声ファイル）とされており、長さ 5 時間未満、サイズ 500 MB 未満という条件も示されています。
そのため、動画ファイルはいったん音声に変換してから渡しています。
なお、Fast Transcription は字句（読み上げたとおりの表記）ではなく、表示形式（句読点などが整った表記）でのみ文字起こしを生成すると、公式ドキュメントに明記されています。
今回の Fast Transcription と Azure Translator のリソースは、Foundry ポータルでプロジェクトを作成し、まとめて用意しました。
サービスごとにリソースを個別に作る手間が省けて便利でした。
実行結果
動作確認には、AI に作成してもらった英語のスピーチ原稿を読み上げた動画を使用しました。
処理が終わると、字幕付きの動画を再生できる HTML ファイルが出力されます。
この HTML をブラウザで開いた画面が、次の画像です。
画面左で動画を再生すると、日本語の字幕が重なって表示されます。
字幕は「日本語」「英語」「両方」「なし」から切り替えられ、再生速度も変更できます。
画面右には、タイムスタンプ付きで英語の原文と日本語訳が一覧表示されます。
行をクリックすると、その位置へ動画がジャンプするため、訳文を確認しながら修正箇所を探すのにも便利です。
実際の字幕付き動画は、次のとおりです。
音声と字幕のタイミングのずれは、ほとんど気になりませんでした。
一見うまく動いているように見えますが、字幕の中身を細かく見ていくと、気になる点がありました。
次の章で詳しく見ていきます。
修正前の課題：文が中途半端に切れて翻訳が不自然に
修正前の実行では、文が途中で切れて、翻訳が不自然になる箇所が多く見つかりました。
タイミングは合っていても、読んで意味が通らない字幕では意味がありません。
具体的には、次のような例です。
どちらも、上段が英語の原文、その下が日本語訳です。
この例では、一つの英文が複数の行に分断されています。
さらに、「未来」や「のか」といった言葉が、行の途中で切れて折り返されています。
こちらでは、「Of course, this transition will」と「not happen without its challenges.」のように、一つの文が途中で二つの行に分かれています。
訳文も、本来は「この移行は困難なしには実現しません。」と訳されるところが「この移行は」「それは困難なしには実現しなかった。」と分断され、時制や主語も原文とずれてしまっています。
これでは、動画を見ながら読むには違和感が大きいですね。
筆者もこの結果を見て、「タイミングは合っているのに、これでは使えない」と感じました。
そこで、原因を調べることにしました。
原因と修正：LLM で文単位に区切ってから翻訳し、行を分割する
原因は、文字起こしの結果を字幕向けに整形してから翻訳していたことでした。
文単位に区切ってから翻訳し、そのあとで行を分割する順番に変えることで、解決できました。
原因：整形してから翻訳していた
修正前のアプリは、文字起こしのあとに、字幕向けの整形を行っていました。
具体的には、次のような処理です。
- 文字数と表示時間による分割：
1行あたりの文字数と表示時間（概ね 1〜7秒）で分割して、英語字幕用のセグメント（字幕1枚分の区切り）を作る
この分割を経たあとで翻訳していたため、文の切れ目が不自然な位置になり、前後の流れも途切れていました。
つまり、翻訳サービスには「文の途中で切られた断片」が渡っていたのです。
なぜ文の途中で切ると翻訳が不自然になるのか：
翻訳は、文の前後関係を手がかりに、主語や述語、語順を決めます。
文が途中で切られると、その手がかりが失われ、断片ごとに別々の文として訳されてしまいます。
筆者の検証では、この断片ごとの翻訳が、不自然な訳文につながっていると考えられました。
修正：LLM で文単位に区切り、訳したあとに行を分ける
修正では、処理の順番を入れ替えました。
まず LLM（大規模言語モデル）で文単位に区切り、Azure Translator で翻訳してから、字幕向けの行に分割するようにしています。
処理フローでいうと、「翻訳」の前に、LLM による文の区切りを加えた形です。
| 修正前 | 修正後 | |
|---|---|---|
| 処理の順番 | 文字数と表示時間（概ね 1〜7秒）で分割し、英語字幕用のセグメントを作ってから翻訳 | LLM で文単位に区切り、Azure Translator で翻訳してから、字幕向けの行に分割 |
| 翻訳に渡すもの | 文の途中で切れた断片 | 文として完結した単位 |
| 行の分け方 | 文字数と表示時間に合わせて機械的に分割 | 句読点の直後で分割。なければ文節の切れ目らしい位置で、均等な行に分割 |
LLM を利用した文の区切り方
文の区切りには、LLM（今回は gpt-5-mini）を利用しています。
文字起こしデータの JSON ファイル（transcript.json）を、そのまま LLM に渡します。
その際、「単語の変更や削除などの編集は加えない」ことを指示したうえで、文末に指定した区切り文字を挿入してもらいます。
この区切り文字を目印にして、文単位に分割します。
LLM の出力は、念のため検証してから次の処理に進む設計にしました。
LLM の返答から区切り文字を取り除いたものと、元の JSON ファイルの内容が完全に一致することを確認し、一致を確認できてから翻訳に進みます。
一致しなかった場合は再試行し、再試行でも一致しなかった場合は、エラーとして処理を止めます。
なぜ文の区切りに LLM を使うのか：
修正前の分割は、文字数と表示時間を基準にしていたため、文の意味を考慮できていませんでした。
文の切れ目を判断するには、文の意味を理解する必要があります。
そのため筆者は、この判断を LLM に任せるのが合っていると考えました。
なぜ小型のモデルで十分なのか：
LLM に任せているのは、文の切れ目に区切り文字を挿入するだけの作業です。
文章を新しく生成したり、翻訳したりするわけではないため、筆者は小型のモデルで十分だと判断し、gpt-5-mini を選びました。
また、出力は元のデータと一致するか検証するため、万一余計な編集が入っても検出できます。
なぜ元のデータと完全一致するか確認するのか：
LLM は、編集しないよう指示しても、単語を言い換えたり、一部を抜いたりする可能性があります。
字幕は音声の内容と対応していることが前提です。
そこで、区切り文字を除いた結果が元の内容と一致することを機械的に確かめてから、次の処理へ進むようにしました。
一致しない場合は再試行し、それでも一致しなければエラーとして止めることで、内容がずれたまま翻訳が進むことを防いでいます。
訳したあとの行の分け方
行の分け方も工夫しています。
訳した文は、まず句読点の直後で区切ります。
句読点がない場合は、文節（意味のまとまり）の切れ目らしい位置を探し、行の長さが均等になるように分けます。
これにより、行頭に読点が来たり、単語の途中で折り返されたりすることを避けられます。
各ステップの成果物を残す構成のため、修正後も必要な処理から再実行しやすいのは利点でした。
では、修正の効果を見てみましょう。
修正後の処理フローと実行結果
修正後のアプリは、修正前の処理フローに、LLM による文の区切りを加えた構成です。
文字起こしのあと、翻訳の前に、LLM で文単位に区切る手順を挟んでいます。
| 手順 | 処理 | 成果物 |
|---|---|---|
| 1 | 動画ファイルを受け取り、音声ファイルに変換する | 音声ファイル |
| 2 | 音声ファイルを Fast Transcription で文字起こしする | transcript.json |
| 3 | 【追加】LLM（gpt-5-mini）で文単位に区切る | 文単位に区切った文字起こしデータ |
| 4 | Azure Translator で翻訳する | translated.json |
| 5 | 翻訳結果から、英語字幕と日本語字幕を出力する | en.vtt（英語字幕）、jp.vtt（日本語字幕） |
| 6 | 字幕付きの動画を再生できる HTML ファイルを出力する | 字幕付き再生用 HTML |
手順3が、今回追加した部分です。
LLM の出力が元のデータと一致しなかった場合は再試行し、再試行でも一致しなければエラーとして処理を止めます。
手順4の翻訳には、文として完結した単位が渡されるようになりました。
修正後のアプリで実行した、字幕付き動画は次のとおりです。
次の章で、修正前と修正後の字幕を並べて比較します。
修正前後の比較
修正後は、文のまとまりが保たれ、訳文が自然に読めるようになりました。
同じ箇所を、修正前（左）と修正後（右）で並べて比較します。
比較1：冒頭の挨拶部分
| 修正前 | 修正後 |
|---|---|
|
 |
修正前は、一つの英文が複数の行に分かれ、訳文も細切れでした。
修正後は、「今日は、私たち一人ひとりに直接影響を与えるテーマについてお話ししたいと思います。」のように、一文がひとまとまりで表示されています。
意味の通る形で読めるようになったことがわかります。
比較2：「課題の克服と継続的な学び」について話す部分
| 修正前 | 修正後 |
|---|---|
|
 |
こちらの例では、修正前は、見出しの「Overcoming Challenges and Continuous Learning」が次の文の冒頭と一続きになり、「Of course, this transition will」と「not happen without its challenges.」のように一つの文が途中で分かれていました。
修正後は、見出しと本文が別の行に分かれ、「もちろん、この移行は課題なしには実現しません。」と一文でつながっています。
修正前は「実現しなかった」となっていた時制も、原文に合った表現になりました。
なお、修正後の一文は、1つの字幕としては長めになる場合があります。
画面に表示する際は、先ほど説明した「句読点の直後、なければ文節の切れ目らしい位置」で均等な行に分けて表示します。
字幕としての見やすさは、動画で実際に確認していただくのが一番わかりやすいと思います。
よくある質問
Q. 動画ファイルをそのまま Fast Transcription に渡せますか？
公式ドキュメントでは、入力は WAV や MP3 などのオーディオ ファイル（長さ 5 時間未満、サイズ 500 MB 未満）とされています。
そのため、本アプリでは動画ファイルをいったん音声ファイルに変換してから渡しています。
対応形式の詳細は、事前に公式ドキュメントでご確認ください。
Q. Fast Transcription と Speech Translation API はどう使い分けますか？
録画済みのファイルから字幕を作りたい場合は Fast Transcription、ライブ配信や Web 会議のように、いま話している声をその場で翻訳したい場合は Speech Translation API が向いています。
本記事の比較表も参考にしてください。
Q. 字幕の翻訳が不自然になるときは、どこを見直せばよいですか？
筆者のケースでは、翻訳前に文が途中で切られていたことが原因でした。
文字起こしの結果を字幕向けに整形する前に、LLM で文単位に区切ってから翻訳し、訳したあとで行を分割する順番に変えたところ、訳文が自然になりました。
Q. 字幕の行を分けるときは、どのような点に注意しましたか？
行頭に読点が来たり、単語の途中で折り返されたりしないよう、分け方を工夫しました。
訳した文は、まず句読点の直後で区切ります。句読点がない場合は、文節（意味のまとまり）の切れ目らしい位置を探し、行の長さが均等になるように分けています。
字幕としての読みやすさは、動画で実際に確認することをおすすめします。
Q. Fast Transcription で、話者ごとに文字起こしを分けられますか？
今回の検証では使用していませんが、話者分離（誰が話したかの識別）に対応しており、1つの録音で最大35人まで識別できます。超えるとエラーになります（音声テキスト変換の概要）。
ただし、話者分離はシングル チャネル（モノラル）の音声でのみサポートされます。また、既定ではすべての入力チャネルが1つにマージされ、チャネルごとに個別に文字起こしできるのは最大2チャネルまでで、話者分離が無効の場合に限られます（高速文字起こしの使用）。
まとめ：成果物を残す構成と「文単位で翻訳してから分割」で、自然な翻訳字幕を作る
本記事では、Fast Transcription と Azure Translator を使った、動画の翻訳字幕生成アプリをご紹介しました。
筆者が得た学びは、次の3つです。
- 目的に合うサービスを選ぶ：
録画済みの動画から字幕だけを作るなら、Fast Transcription ＋ Azure Translator が扱いやすい構成でした。リアルタイム翻訳なら Speech Translation API、動画全体の分析なら Video Indexer が候補になります。 - 各ステップの成果物を残す：
文字起こし、翻訳、HTML 出力の成果物をファイルに残すことで、エラー時は一つ前から再開でき、翻訳だけ・字幕だけの再実行もできました。 - 「文単位で翻訳してから分割」の順番にする：
字幕向けの整形を先に行うと、文の途中で切れた断片が翻訳されて不自然になります。LLM で文単位に区切ってから訳し、そのあとで行を分けることで、自然な字幕になりました。
今回は字幕生成の検証をメインとしていたため、英語から日本語への翻訳のみに対応した、簡単なつくりのコマンドアプリとして作成しました。
翻訳元の言語を自動判定させたり、専門用語に対応できるようにしたりと、用途に合わせてカスタマイズすることも可能です。
専門用語への対応は、用語集を用意して、Fast Transcription と Azure Translator の両方に渡す形が考えられます。
音声と字幕のタイミングが合っていても、訳文の読みやすさは別の問題です。
まずは短い動画で試して、字幕の読みやすさを確認してみてはいかがでしょうか。
本記事で参照した Microsoft Learn のドキュメントは、次のとおりです。
QUICK E-Solutionsでは、AIを活用した業務効率化・システム導入のお手伝いをしております。
それ以外でも 様々なアプリケーションの開発・導入を行っております。提供するサービス・ソリューションにつきましては こちら に掲載しております。
システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味を抱かれましたら、ぜひ一度 お問い合わせ ください。
※このブログで参照されている、Microsoft、Azureは、米国およびその他の国におけるMicrosoft Corporationの商標または登録商標です。
OpenAI、GPTは、OpenAIの商標または登録商標です。
