Transcoder API

解決する課題

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

• スマートフォンから 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 用マニフェストまで出力できる
• リージョン単位で動作し、同時実行ジョブ数などにクォータがある。大量並列処理を行う場合は上限緩和を検討する
• 入力動画の長さ・解像度・コーデックには対応範囲があり、対応外の形式は事前確認が必要

内部の仕組み

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

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

処理は完全に非同期で、ジョブの状態はポーリングで確認するか、完了時に Pub/Sub 通知を受け取って後続処理（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 は処理した動画の出力分（おおむね出力の長さ・解像度に応じた従量）で課金され、常時稼働サーバーの固定費が不要です。サーバーレスのジョブ型のため、変換した分だけ支払う構造です。

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

セキュリティ

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

Well-Architected の観点

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

試験で問われるポイント

関連サービス・比較

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

ハンズオン / 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) プリセットを使って変換ジョブを作成（入力と出力先を指定）
gcloud transcoder jobs create \
  --location=asia-northeast1 \
  --input-uri=gs://my-video-input/source.mp4 \
  --output-uri=gs://my-video-output/hls/ \
  --template-id=preset/web-hd

# 4) ジョブの状態を確認（SUCCEEDED / FAILED など）
gcloud transcoder jobs describe JOB_ID \
  --location=asia-northeast1 \
  --format="yaml(state, error)"

# 5) リージョン内のジョブを一覧
gcloud transcoder jobs list --location=asia-northeast1