クラウドサービス

Transcoder API

アップした動画を各種フォーマット・解像度・ビットレートへ自動変換し、HLS/DASH 配信用ストリームを生成。あらゆる端末向けの配信準備を任せられる。AWS Elemental MediaConvert 相当。

基礎運用上の優秀性コスト最適化
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. Cloud Storageの動画を非同期ジョブで複数画質へ変換する。
  2. HLS・DASH・単体ファイルをCloud Storageへ書き出す。
  3. 完了・失敗はPub/Subで受け、失敗ジョブは修正後に再作成する。

解決する課題

ユーザーがアップロードした多様な形式の動画を、再生環境に合わせて変換・最適化したいときに使います。

  • スマートフォンから PC まで、端末や回線に応じた複数の解像度・ビットレートを 1 本のソースから生成したい
  • HLS や DASH といったアダプティブビットレート配信(ABR)用のストリームを作りたい
  • 動画変換のために自前で FFmpeg を動かすサーバーやワーカーを運用したくない
  • 変換処理をスパイクに合わせて自動でスケールさせ、ジョブ完了まで放置したい
  • 透かし(ウォーターマーク)・字幕・サムネイル生成などの前後処理をまとめて行いたい

主要概念と用語

  • ジョブ (Job): 1 回の変換処理の単位。入力動画と出力設定を指定して実行し、非同期で完了する。完了状態は SUCCEEDED / FAILED などで表される
  • ジョブテンプレート (Job Template): 出力設定をひな形として保存し、再利用する仕組み。同じ変換仕様を毎回書かずに済む
  • JobConfig(ジョブ設定): 入力・編集(elementary stream)・多重化(mux stream)・出力先などをまとめた設定本体。プリセット名で指定する簡易指定と、詳細を細かく書く方法がある
  • Elementary Stream(基本ストリーム): 映像・音声それぞれのエンコード設定。コーデック(H.264 / H.265 / VP9 など)、解像度、ビットレート、フレームレートを指定する
  • Mux Stream(多重化ストリーム): 映像・音声の基本ストリームを束ねて 1 つの出力ファイルやセグメントにまとめる設定
  • マニフェスト (Manifest): HLS の .m3u8 や DASH の .mpd など、ABR 再生のために複数画質を束ねる索引ファイル
  • アダプティブビットレート (ABR): 視聴者の回線速度に応じてプレイヤーが画質を切り替える方式。複数ビットレートの出力とマニフェストが前提
  • オーバーレイ / ウォーターマーク: 出力動画に重ねる画像やロゴ。著作権表示やブランディングに使う

仕様・制限・クォータ

  • 入力も出力も基本は Cloud Storage。ソース動画を Cloud Storage に置き、変換結果も Cloud Storage へ書き出すのが標準的な使い方
  • 非同期のジョブ型サービス。リクエストするとジョブが受理され、変換はバックグラウンドで進む。完了通知は Pub/Sub で受け取れる
  • 主要コーデックとして映像は H.264・H.265(HEVC)・VP9、音声は AAC などに対応。出力コンテナは MP4・HLS(fMP4/TS)・DASH などを生成できる
  • 複数の解像度・ビットレートを 1 ジョブで同時生成し、ABR 用マニフェストまで出力できる
  • リージョン単位で動作し、同時実行ジョブ数などにクォータがある。大量並列処理を行う場合は上限緩和を検討する
  • 入力動画の長さ・解像度・コーデックには対応範囲があり、対応外の形式は事前確認が必要

内部の仕組み

横にスクロール

Cloud Storageの入力動画をTranscoder APIの非同期ジョブで変換し、配信形式を保存する図
Transcoder APIはファイル変換とCloud Storage出力を担います。完了・失敗はPub/Subで受け、失敗時は原因を直して新しいジョブを作成します。

Transcoder API はフルマネージドのジョブ実行基盤です。利用者はジョブ(入力・出力設定)を送信するだけで、変換に必要な計算リソースの確保・スケール・障害時の処理はサービス側が引き受けます。サーバーやワーカープールを自分で用意する必要はありません。

ジョブを受理すると、サービスは入力動画をデコードし、指定された各基本ストリーム(映像・音声)へ並行してエンコードします。複数画質を要求した場合は、それぞれの解像度・ビットレートで並列にトランスコードし、多重化ストリームとしてファイルやセグメントへまとめます。HLS / DASH を指定すると、各画質のセグメント群に加えてマニフェスト(索引ファイル)が生成され、そのまま ABR 配信に使えます。

処理は完全に非同期で、ジョブの状態はポーリングで確認するか、完了または失敗の終端状態を Pub/Sub 通知で受け取って後続処理(CDN への反映、失敗隔離、メタデータ更新など)をトリガーします。失敗したジョブは原因と設定を直して新しいジョブとして再作成します。ジョブテンプレートを使うと、同じ出力仕様を毎回定義し直さずに済み、設定の標準化と再利用が容易になります。

そのまま配信につなげる

Transcoder API の出力は Cloud Storage に置かれるため、Cloud CDN(または Media CDN)のバックエンドバケットとして紐づければ、変換後すぐにエッジ配信へ載せられます。「変換は Transcoder API、配信は CDN」と役割を分けて考えると設計が整理しやすいです。

設計パターン / ベストプラクティス

  • アップロード → 変換 → 配信のパイプライン化。Cloud Storage への動画アップロードを Eventarc / Cloud Functions で検知し、Transcoder API ジョブを起動、完了を Pub/Sub で受けて CDN 反映やDB更新へつなぐ
  • ジョブテンプレートで出力仕様を標準化する。画質セット(例: 1080p/720p/480p の 3 段)をテンプレート化し、アプリ側は入力と出力先だけを指定する
  • ABR 配信を前提に複数ビットレートを出力し、HLS/DASH マニフェストまで生成しておく。単一画質だけだと回線変動に弱い
  • 完了通知は Pub/Sub で受ける。ポーリングで待ち続けるより疎結合で、失敗時のリトライ制御もしやすい
  • 出力先バケットを入力と分ける。元動画と変換結果のライフサイクル(保持期間・公開範囲)を別管理にできる

運用・監視

  • Cloud Monitoring / Cloud Logging でジョブの実行状況とエラーを監視する。失敗ジョブの状態理由(入力フォーマット非対応、参照先の権限不足など)はログで原因を切り分ける
  • ジョブの成功 / 失敗件数と所要時間を主要指標として追う。失敗が増えたら入力動画の品質やコーデック対応範囲を疑う
  • Pub/Sub 完了通知 を運用フローに組み込み、失敗時はデッドレターや再投入の仕組みで取りこぼしを防ぐ
  • 大量の同時変換を行う場合は同時実行ジョブのクォータに注意し、必要なら上限緩和を申請。バックログが滞留しないようジョブ投入レートを制御する

コスト

Transcoder API は処理した動画の出力分(おおむね出力の長さ・解像度に応じた従量)で課金され、常時稼働サーバーの固定費が不要です。サーバーレスのジョブ型のため、変換した分だけ支払う構造です。

コスト要素考え方最適化のポイント
トランスコード処理出力した動画の長さ・解像度に応じた従量課金不要な高解像度出力を削り、必要な画質セットに絞る
出力ストレージ変換結果を保持する Cloud Storage 料金古い変換物はライフサイクルで自動削除・低頻度クラスへ移行
配信(egress)視聴者への転送は CDN / Cloud Storage 側の料金Cloud CDN でキャッシュしオリジン転送を削減
完了通知・連携Pub/Sub などの周辺サービス利用料通知ベースにし無駄なポーリングを避ける

同じソースを何度も変換し直さないよう、変換結果をキャッシュ/保持し再利用することが地味に効くコスト最適化です。

セキュリティ

  • サービスアカウントと IAM で権限を最小化する。ジョブ実行に使う ID には、入力バケットの読み取りと出力バケットの書き込みに限った権限だけを付与する
  • 入力・出力 Cloud Storage バケットを公開しない。変換前後の動画は IAM か署名付き URL で必要範囲のみに限定する
  • 保存データは Google 管理鍵で既定暗号化。要件に応じて CMEK(顧客管理鍵, Cloud KMS) を出力バケットに適用する
  • 認証情報のハードコードを避け、ワークロードに紐づくサービスアカウントを直接利用する(AWS の IAM ロール相当)
アンチパターン

変換結果のバケットに allUsers 読み取りを付けて丸ごと一般公開するのは避けること。限定配信したい動画まで誰でも取得できてしまいます。配信は Cloud CDN + 署名付き URL などで制御し、オリジンバケット自体は非公開のままにします。

Well-Architected の観点

  • 運用上の優秀性 (operational): 変換基盤を自前運用せずマネージドに委ねることで、FFmpeg ワーカーの保守・スケール・パッチから解放される。ジョブテンプレートで設定を標準化し、Pub/Sub 通知でパイプラインを自動化できる
  • コスト最適化 (cost): 固定サーバーを持たず、変換した分だけの従量課金。不要な高解像度出力の削減、変換結果の再利用、出力ストレージのライフサイクル管理でコストを抑えられる

試験で問われるポイント

頻出
  • 「動画を複数フォーマット・解像度へ変換」「HLS/DASH のアダプティブ配信用ストリームを生成」なら Transcoder API を選ぶ
  • AWS の Elemental MediaConvert に相当する、というサービス対応を押さえる
  • 入力・出力はともに Cloud Storage が基本。変換結果を配信するのは Cloud CDN / Media CDN で、役割が別であることを区別する
  • 非同期のジョブ型で、完了は Pub/Sub 通知で受け取る設計が定番。Eventarc/Functions と組み合わせた自動パイプラインが問われやすい
  • 「ライブ配信のリアルタイム処理」とは別物。Transcoder API は主に蓄積された動画(VOD)のファイル変換を担う

関連サービス・比較

Transcoder API は機能的に AWS の Elemental MediaConvert に対応します。どちらも「VOD 向けのファイルベース動画変換」を担うサーバーレスのジョブ型サービスです。

観点Transcoder API (GCP)Elemental MediaConvert (AWS)
位置づけVOD 向けファイル変換のマネージドサービスVOD 向けファイル変換のマネージドサービス
入力・出力Cloud Storage が基本Amazon S3 が基本
実行モデル非同期ジョブ(従量課金・サーバー不要)非同期ジョブ(従量課金・サーバー不要)
設定の再利用ジョブテンプレートジョブテンプレート / プリセット
完了通知Pub/SubCloudWatch Events / EventBridge
配信との連携Cloud CDN / Media CDNAmazon CloudFront
権限付与サービスアカウント + IAMIAM ロール
VOD 変換とライブ配信は別物

Transcoder API は蓄積済み動画のファイル変換(VOD)が主眼です。低遅延のライブ映像をその場でエンコード・配信する用途は領域が異なるため、要件が「リアルタイム配信」なら専用のライブ配信構成を検討します。AWS でも MediaConvert(ファイル)と MediaLive(ライブ)が分かれているのと同じ整理です。

ハンズオン / CLI例

# 1) 入力動画を置く / 出力先となる Cloud Storage バケットを用意
gcloud storage buckets create gs://my-video-input --location=asia-northeast1
gcloud storage buckets create gs://my-video-output --location=asia-northeast1

# 2) ソース動画をアップロード
gcloud storage cp ./source.mp4 gs://my-video-input/source.mp4

# 3) プリセットを使って変換ジョブを作成(REST API を curl で叩く)
curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  https://transcoder.googleapis.com/v1/projects/PROJECT/locations/asia-northeast1/jobs \
  -d '{
    "inputUri": "gs://my-video-input/source.mp4",
    "outputUri": "gs://my-video-output/hls/",
    "templateId": "preset/web-hd"
  }'

# 4) ジョブの状態を確認(SUCCEEDED / FAILED など)
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  https://transcoder.googleapis.com/v1/projects/PROJECT/locations/asia-northeast1/jobs/JOB_ID

# 5) リージョン内のジョブを一覧
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  https://transcoder.googleapis.com/v1/projects/PROJECT/locations/asia-northeast1/jobs

Google Cloud Service

Transcoder APIを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

メディア

比較で見る軸

クラウド: Google Cloud / カテゴリ: メディア / 難易度: basic

導入後に効く点

HLS・DASH・単体ファイルをCloud Storageへ書き出す。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Google Cloud
カテゴリ
メディア
難易度
basic
関連資格
設計柱
operational / cost

判断チェックリスト

  • 自社の用途が「メディア / operational」に近いか確認する。
  • 強みである「Cloud Storageの動画を非同期ジョブで複数画質へ変換する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

メディアoperationalcost