MediaPackage v2 + MediaTailor 本番運用 パッケージング・LL-HLS・SSAI広告挿入

1. この記事について — Vol1の”先”、配信の後段パイプライン

1-1. Vol1からの接続 — 配信の後段へ

Vol1では、動画・ゲーム配信の”前段”にあたる次の4サービスを扱いました。

• AppStream 2.0: クラウドゲーミングの画面をブラウザへストリーミング配信するサービス
• MediaConvert: ファイルベースの動画コンテンツをバッチでトランスコードするサービス
• MediaLive: ライブ映像をリアルタイムでエンコードするサービス
• GameLift: ゲームサーバーのホスティングとマッチメイキングを担うサービス

Vol1の中でMediaPackageは「CDNオリジン」として名前だけ触れられており、詳細な役割分担までは踏み込んでいません。

本Vol2は、そのVol1が前方参照にとどめていた領域——エンコード済みのストリームを実際に配信可能な形式へパッケージし、さらに広告を挿入してマネタイズする”後段”のパイプライン——を深掘りします。具体的には、MediaLiveやMediaConvertが生成したストリームを受け取り、視聴デバイス向けの配信フォーマット(HLS/DASH)に変換してオリジンとなるMediaPackage v2と、そのオリジンの手前でサーバーサイド広告挿入(SSAI)を担うMediaTailorの2サービスです。

境界を明確にすると、Vol1の担当範囲は「映像をどうエンコードし、どう配信素材として送り出すか」、本Vol2の担当範囲は「送り出された素材をどうパッケージし、どう収益化するか」です。Vol1で扱ったエンコード方式やHLSの基礎的な仕組みについては、重複を避けるためVol1へ委譲します。未読の方は先にVol1をご覧いただくと、本記事の連携パイプラインの全体像がつながりやすくなります。

なお、Vol1とVol2の境界を意識せずにVol1のみで配信を完結させようとすると、MediaLiveの出力を視聴者へ直接公開するような構成になりがちです。この構成でも視聴自体は可能ですが、オリジンの冗長化や広告挿入といった本Vol2で扱う機能を後から追加する際に、配信構成全体を作り直す必要が生じます。最初からVol1・Vol2の役割分担を意識した構成にしておくことで、後段機能の追加を見据えた設計がしやすくなります。

1-2. 読者像と前提

本記事は、Vol1でMediaLive/MediaConvertによるエンコード・ライブ配信の基本を理解した上で、その先のパッケージングと広告マネタイズまで一気通貫で設計したいメディア配信担当者を想定しています。具体的には、既にライブ配信基盤(MediaLive)は構築済みで、次に「配信オリジンをどう構成するか」「広告収益をどう組み込むか」という後段の設計判断に直面している方をイメージしています。

役割としては、配信基盤の設計・運用を担うインフラ/バックエンドエンジニアだけでなく、広告マネタイズの要件定義を担う配信事業側の担当者にとっても、パッケージングと広告挿入がどう連携するかという全体像を把握する材料になります。

前提知識として、Vol1相当のMediaLive/MediaConvertの役割分担、HLS/DASHといった配信フォーマットの基礎、CloudFrontによるCDN配信の基本を把握していることを前提とします。SSAI/VAST/VMAPといった広告技術用語は本記事内で解説しますが、セグメントやマニフェスト、オリジンサーバーといった動画配信のドメイン知識は既知として進めます。逆に、AppStream 2.0やGameLiftのようなゲーミング配信固有の要素は本記事のスコープ外です。

具体的な判断場面を挙げると、次のような状況にある読者にとって本記事は「次に読むべき記事」になります。1つは、MediaLiveによるライブ配信基盤は既に稼働しているものの、視聴者に配信オリジンをどう公開すべきか——MediaLiveの出力を直接視聴者へ晒すのか、専用のオリジンサーバーを間に挟むのか——という設計判断がまだ固まっていないケースです。もう1つは、広告による収益化が事業要件として上がってきているものの、プレーヤー側でのクライアントサイド広告挿入では広告ブロッカーによる収益ロスや、広告とコンテンツの切り替わり時の再生品質劣化が問題になっており、サーバー側で完結する広告挿入方式を検討し始めた、というケースです。

これらの判断に共通するのは、Vol1で扱ったエンコード・ライブ配信の知識だけでは答えが出せないという点です。オリジンサーバーの構成方法も、広告挿入の実装方式も、いずれもVol1でスコープ外とした「配信の後段」の設計判断であり、本記事が扱う領域そのものです。逆に言えば、まだMediaLiveによるライブ配信基盤自体が固まっていない段階の読者は、本記事より先にVol1から着手することを推奨します。

逆に、まだ広告収益化や配信オリジンの設計を検討する段階になく、純粋にライブ配信の画質やレイテンシ改善を優先課題としている読者にとっては、本記事より前にVol1で扱ったMediaLive/MediaConvertのエンコード設定を先に固めることを優先すべきです。パッケージングや広告挿入は、あくまでエンコード済みストリームが安定して得られていることを前提とする後段の工程だからです。

もう1つの典型的な判断場面として、既に何らかの自前パッケージングや広告挿入の仕組みを運用しているものの、運用負荷の高さやスケーラビリティの限界に直面し、マネージドサービスへの移行を検討し始めた読者も想定読者に含まれます。そうした読者にとっては、本記事のMediaPackage v2・MediaTailorの役割分担が、移行後の設計の指針になります。

いずれの判断場面にも共通するのは、「Vol1で構築した配信基盤を、どう配信可能な形にパッケージし、どう収益化につなげるか」という後段の設計課題です。本記事は、この課題に対して2サービスの役割分担と標準連携という形で具体的な答えを示します。

1-3. 本記事のゴール — パッケージングからマネタイズまで

本記事のゴールは、MediaPackage v2によるパッケージング/オリジネーションと、MediaTailorによるSSAI広告挿入を、単体機能としてではなく「MediaLive→MediaPackage v2→MediaTailor→CloudFront」という1本の連携パイプラインとして設計できるようになることです。

読み終えた時点で、次の3つの問いに自分の言葉で答えられる状態を目指します。①MediaPackage v2とMediaTailorは、それぞれパイプラインのどこを担い、なぜ2サービスに分かれているのか。②SCTE-35マーカーはどの段階で付与され、どのように広告挿入のトリガーとして機能するのか。③自組織で同じパイプラインを構築する際、どの設定項目と落とし穴に注意すべきか。§2で両サービスの役割分担と標準連携の全体像を押さえたうえで、後続の章でMediaPackage v2のリソースモデルや形式選択、MediaTailorの広告技術を深掘りしていきます。

本記事を読み終えた具体的な成果物としては、自組織の配信構成に対して「MediaPackage v2のChannel Group/Channel/Origin Endpointをどう設計するか」「MediaTailorのPlayback ConfigurationにどのADSを接続するか」という2つの設計判断について、たたき台となる構成案を描けるようになることを想定しています。実際のリソース作成手順やパラメータの詳細は§3以降で扱いますが、§1・§2を読んだ時点で、この2つの判断に必要な材料は揃います。

← Game/Media Vol1(AppStream/MediaConvert/MediaLive/GameLift)を読む

2. 配信パイプラインの後段 — 2サービスの役割と連携

2-1. パッケージングとオリジネーション — MediaPackage v2の役割

MediaPackage v2は、ジャストインタイムパッケージング(JITP)という方式で、エンコード済みの単一ソースストリームを、視聴デバイスが要求するタイミングでHLS/DASH/CMAFなどの配信フォーマットへ変換する、パッケージング/オリジネーション専用サービスです。

【判断根拠】Vol1で扱ったMediaConvertは、ファイルベースの入力を事前に複数フォーマットへバッチ変換する用途に向いています。一方MediaPackage v2は、MediaLiveなどから継続的に流れ込むライブストリームを受け取り、リクエストがあった時点で必要なフォーマットへパッケージし直す点が異なります。あらかじめ全フォーマットを作り置きするのではなく、リクエスト時に必要な形式だけを生成するため、ストレージコストと運用の手間を抑えられます。

【設定/運用ハンズオン】実運用では、MediaLiveの出力をMediaPackage v2のChannelが受け取れるよう、Channel作成時に発行されるIngest URLをMediaLiveの出力先として設定します。パッケージング面(Origin Endpoint)は形式ごとに個別作成するため、HLS配信用とDASH配信用を並行提供する場合は、同一Channelの配下に複数のOrigin Endpointを用意します。1つのOrigin Endpointには1つのパッケージャーが対応するため、「同じソースから複数フォーマットを配信したい」というニーズは、Origin Endpointを形式の数だけ増やすことで満たします。形式ごとの詳細設定(セグメント長やDRMの有無)は§4で扱います。

【落とし穴】MediaPackage v2は、あくまでオリジンサーバーであり、視聴者に直接エンドポイントを公開する用途は想定されていません。CloudFrontなどのCDNを前段に配置し、オリジンアクセスを制御する構成が推奨されます。また、MediaPackage v2単体では広告挿入は行わないため、マネタイズが必要な場合は後述のMediaTailorとの連携が前提になります。もう一点、MediaConvertとは異なりバッチジョブという概念がないため、既存のMediaConvertワークフローをそのまま置き換えられるわけではなく、ライブ配信の文脈に合わせて設計し直す必要があります。

【Vol1連携】Vol1のMediaLiveが生成したライブストリームの出力先が、本節のMediaPackage v2のChannelにあたります。Vol1で「CDNオリジン」とだけ言及されていた部分の実体が、このパッケージング/オリジネーション機能です。Vol1の時点でMediaLiveの出力設定を単純なテスト用エンドポイントへ向けていた場合も、MediaPackage v2のChannelへ向け直すことで後段のマネタイズ機能へ接続できるようになります。

【補足】Origin Endpointの追加は既存のChannelやMediaLive側の設定に影響を与えないため、視聴デバイスの対応状況に応じて後から配信フォーマットを追加することも容易です。たとえば当初はHLS配信のみで開始し、Android向けにDASH配信を追加したくなった場合も、既存のHLS向けOrigin Endpointはそのままに、DASH用のOrigin Endpointを追加作成するだけで対応できます。

2-2. SSAIとマネタイズ — MediaTailorの役割

MediaTailorは、サーバーサイド広告挿入(SSAI: Server-Side Ad Insertion)を担うマネージドサービスです。視聴者からのストリーミングリクエストをMediaTailorが仲介し、広告枠が来るたびに広告を動的に取得してコンテンツと同一のストリームへシームレスに組み込みます。

【判断根拠】広告挿入の方式には、クライアント側(プレーヤーSDK)で広告を差し込むクライアントサイド広告挿入という選択肢もあります。しかしクライアントサイド方式は、広告ブロッカーによる広告除去や、コンテンツと広告の切り替わり時のバッファリング・画質劣化といった課題を抱えます。MediaTailorのSSAIは、広告もコンテンツも同一の配信ストリームとしてサーバー側で結合するため、クライアント側での広告除去が難しく、放送品質を維持したままマネタイズできる点が選定理由になります。

【設定/運用ハンズオン】MediaTailorの利用には、Playback Configurationの作成が必要です。ここでコンテンツのオリジン(本記事の文脈ではMediaPackage v2のOrigin Endpoint)と、広告在庫を管理するAd Decision Server(ADS)のエンドポイントURLを設定します。視聴者はMediaTailorが払い出す再生用URLにアクセスすることで、広告挿入済みのマニフェストを受け取ります。広告のリクエストパラメータには視聴者情報(デバイス種別・地域など)を含められるため、パーソナライズ広告の設計はこのADS連携部分が起点になります。ADS/VAST/VMAPの詳細は§6で扱います。

【落とし穴】MediaTailor自体はコンテンツを保持せず、あくまで手前のオリジン(MediaPackage v2など)からコンテンツを取得して広告を組み込む中継役です。そのため、MediaTailorの前段にコンテンツオリジンが正しく用意されていることが前提になります。オリジン側の認証設定やCORS設定が不足していると、広告挿入以前にコンテンツ取得自体が失敗する点に注意が必要です。また、広告の再生実績を可視化するレポート機能(サーバーサイド/クライアントサイド)は別途設定が必要で、有効化を忘れると広告は挿入されていてもマネタイズの効果測定ができないという事態になります(§7で扱います)。

【Vol1連携】Vol1では触れられなかった「配信したストリームからどう収益化するか」という論点に、本節で初めて踏み込みます。Vol1のエンコード・配信基盤があって初めて、MediaTailorによるマネタイズが成立します。Vol1で構築したMediaLiveのライブチャンネルは、本節以降の設定を追加するだけで広告付き配信へ拡張でき、配信基盤自体を作り直す必要はありません。

【補足】広告挿入方式は、SSAIとクライアントサイド方式のどちらか一方に限定する必要はなく、デバイスや配信面ごとに使い分けるハイブリッド構成を取ることも可能です。たとえばコネクテッドTVやセットトップボックスなど、広告ブロッカーの影響を受けにくくシームレスな視聴体験が特に重視される面ではSSAIを採用し、ウェブブラウザ向けには既存のクライアントサイド広告タグをそのまま活かす、といった使い分けが実務では行われています。

2-3. サービス選定の判断軸 — いつ何を選ぶか

MediaPackage v2とMediaTailorは、それぞれ代替となる選択肢が存在するため、なぜこの2サービスを選ぶのかという判断軸を整理しておきます。

【MediaPackage v2 vs 他のパッケージング手段】ライブストリームのパッケージング/オリジン機能は、自前でパッケージャーソフトウェアをEC2上に構築して実装できます。しかし自前構築の場合、フォーマット追加のたびにパッケージャーの設定変更・スケーリング・可用性確保を自組織で担う必要があります。MediaPackage v2を選ぶ判断軸は、①MediaLiveとのネイティブ連携が前提にある、②JITP(ジャストインタイムパッケージング)によりリクエスト時にのみ変換するためストレージコストを抑えたい、③LL-HLSのような低遅延配信を運用負荷なく実現したい、の3点がそろう場合です。逆に、既にVOD中心のパッケージング基盤(MediaConvertやv1系)が確立しており、ライブ配信への拡張ニーズが小さい場合は、無理に本サービスへ寄せる必要はありません。

【MediaTailor SSAI vs クライアントサイド広告挿入】広告挿入方式の選定は、§2-2で触れた放送品質の維持と実装コストのトレードオフで決まります。クライアントサイド広告挿入は、プレーヤーSDKへの実装だけで済むため導入は容易ですが、広告ブロッカーによる収益ロスや、広告とコンテンツの継ぎ目でのバッファリング・画質切り替えが視聴体験を損なうリスクを抱えます。MediaTailorのSSAIを選ぶ判断軸は、①広告ブロッカー耐性を確保したい、②放送品質のシームレスな視聴体験を維持したい、③ADS(広告デシジョンサーバー)との連携基盤を新たに構築するコストを許容できる、の3点です。少数の広告枠をシンプルに扱うだけであれば、クライアントサイド方式のほうが立ち上げは早くなります。

【ハンズオン視点】実務での判断は、多くの場合「パッケージングはMediaPackage v2、広告挿入は要件次第」という組み合わせに落ち着きます。ライブ配信を扱う限りMediaPackage v2を採用しない理由は基本的にないため、真に検討が必要なのはMediaTailorのSSAIを導入するかどうかです。判断のたたき台としては、①広告在庫の管理主体(自社ADSか外部SSP経由か)、②視聴デバイスにおける広告ブロッカーの普及率、③放送品質要件の厳しさ、の3点を洗い出したうえで、クライアントサイド方式からSSAIへ移行した場合のコストを試算するとよいでしょう。

【落とし穴】広告挿入方式の選定を後回しにしたまま配信基盤を構築してしまうと、後からMediaTailorを追加する際に、Playback Configurationの設計だけでなく、CloudFrontのディストリビューション構成やオリジンのアクセス制御まで見直しが必要になります。広告収益化の要件がまだ固まっていない段階でも、将来SSAIを追加する可能性がある場合は、MediaPackage v2のOrigin Endpointをあらかじめ「MediaTailor経由での利用」を想定した設定にしておくと、後戻りが少なくなります。

2-4. SCTE-35ハンドオフ — マーカー付与から広告挿入トリガーまでの概念接続

MediaPackage v2とMediaTailorの連携において中心的な役割を果たすのがSCTE-35マーカーです。ここでは概念的な受け渡しの流れを押さえ、シグナリング形式の詳細(HLSのDaterange/enhanced CUE、DASHのEventStream等)は§4-3で扱います。

流れとしては、まずMediaLive(Vol1)が、エンコード済みのストリームに対して「ここから広告に切り替えてよい」というタイミング情報をSCTE-35マーカーとして埋め込みます。次にMediaPackage v2が、このマーカーを検知し、自身が生成する配信用マニフェスト(HLS/DASH)の中に、後段のシステムが解釈できる形でマーカー情報を再シグナリングします。ここまでがパッケージング層の役割です。

最後にMediaTailorが、MediaPackage v2の生成したマニフェストを取得する際に、このマーカーを「広告挿入を実行すべき位置」として検知し、ADSへ広告クリエイティブをリクエストするトリガーとして利用します。つまりSCTE-35マーカーは、MediaLiveが生成し、MediaPackage v2が中継・シグナリングし、MediaTailorが消費するという3段階のリレーを経て、最終的に広告挿入という機能を成立させています。この3段階のうちどれか1つでも欠けると——たとえばMediaPackage v2側でマーカーのシグナリングを設定していなければ——MediaTailorは広告挿入のタイミングを検知できず、パイプライン全体としてのマネタイズが機能しません。

【ハンズオン視点】このハンドオフが正しく機能しているかを確認する際は、MediaTailorを組み込む前に、まずMediaPackage v2単体でマニフェストを取得し、SCTE-35マーカーが期待通りシグナリングされているかを目視確認することをおすすめします。MediaTailorとの連携を先に組んでしまうと、広告未挿入の不具合が発生した際に、原因がMediaPackage v2側のマーカー未設定にあるのか、MediaTailor側のADS連携にあるのかを切り分けにくくなります。

【落とし穴】SCTE-35マーカーの受け渡しでは、マーカーの「有無」だけでなく「尺(duration)」の情報も重要です。MediaLive側で設定した広告ブレイクの尺とマニフェストにシグナリングされる尺の不一致は、MediaTailorが広告クリエイティブを尺に合わせて差し込む際に、コンテンツとの継ぎ目のズレとして表面化することがあります。パイプライン全体を疎通確認する際は、マーカーの有無だけでなく尺の一致もあわせて確認してください。

【補足】マーカーの伝搬確認は、初回のパイプライン構築時だけでなく、MediaLive側のエンコーダ設定やチャンネル構成を変更した際にも再確認することをおすすめします。設定変更のたびにパッケージング層・広告挿入層の連携が保たれているかを確認する運用を組み込んでおくと、変更に伴う広告未挿入の不具合を早期に検知できます。

2-5. 標準連携パイプライン — 4サービスの流れ

MediaPackage v2とMediaTailorを組み合わせた標準的な連携パイプラインは、次の4段階で構成されます。

1. MediaLive(Vol1): ライブストリームをエンコードし、SCTE-35広告マーカーを挿入したストリームとしてMediaPackage v2へ出力します。
2. MediaPackage v2: MediaLiveからのストリームを受け取り、HLS/DASH/CMAFなどの配信フォーマットへパッケージします。あわせてSCTE-35マーカーをHLSのDaterangeタグやDASHのイベントとしてマニフェストへシグナルし、広告挿入のトリガー情報として引き継ぎます。
3. MediaTailor: MediaPackage v2のOrigin EndpointをコンテンツオリジンとするPlayback Configurationを介して、マニフェスト中のSCTE-35シグナルを検知し、その位置にADSから取得した広告クリエイティブを差し込んだパーソナライズドマニフェストを生成します。
4. CloudFront: MediaTailorが生成したマニフェストとセグメントを視聴者へ配信するCDN層です。

各段階でやり取りされるデータの形式に着目すると、パイプライン全体の理解がより具体的になります。MediaLiveの出力は、ABR(複数ビットレート)のエンコード済みストリームであり、HLSまたはCMAF ingest形式のセグメント(コンテナとしてはTSまたはfMP4)としてMediaPackage v2のChannel ingestエンドポイントへHTTPSプッシュされ、あわせてSCTE-35マーカーが埋め込まれています。MediaPackage v2は、この入力を受け取り、Origin Endpointの設定に応じてHLSであれば.m3u8マニフェストと.ts/.fmp4セグメント、DASHであれば.mpdマニフェストとfMP4セグメントという形で出力します。マニフェスト内には、SCTE-35マーカーがDaterangeタグやEventStream要素として反映されます(§4-3で詳述)。MediaTailorは、このMediaPackage v2のマニフェストとセグメントをオリジンプルで取得する一方、ADSからはVAST/VMAP形式の広告クリエイティブ情報(広告セグメントの参照先URLを含む)を別途取得し、両者をマニフェストレベルで組み合わせた、視聴者ごとにパーソナライズされたマニフェストを生成します(セグメント自体の中身を書き換えるのではなく、マニフェストが参照するセグメントのURLを差し替える形で広告を組み込みます)。CloudFrontは、このパーソナライズドマニフェストと、そこから参照されるセグメント(コンテンツ本編・広告のいずれも)を視聴者へ配信するCDN層であり、マニフェストとセグメントとではキャッシュ挙動を分けて設計する必要がある点は本節冒頭の落とし穴でも触れたとおりです。

【判断根拠】この並び順が標準的なのは、SCTE-35マーカーの付与(MediaLive)→フォーマット変換とマーカーのシグナリング(MediaPackage v2)→マーカーを起点とした広告挿入(MediaTailor)という、各サービスが担える役割に沿って処理を分担しているためです。広告挿入をMediaPackage v2より前段(MediaLive側)や後段(CloudFront側)で行う構成は用意されていません。

【設定/運用ハンズオン】実装上のポイントは、MediaTailorのPlayback ConfigurationでコンテンツオリジンにMediaPackage v2のOrigin Endpoint(HLSであれば非暗号化エンドポイント)を指定することです。MediaTailorは、コンテンツを取得するオリジンと、広告セグメント自体を配信するもう1つのオリジン(MediaTailorが内部で払い出すエンドポイント)という、2系統のオリジンを組み合わせて1本のマニフェストを組み立てます。CloudFrontのディストリビューションは、MediaTailor向けとMediaPackage向けの2系統を用意し、視聴者からのリクエストはまずMediaTailor側のディストリビューションで受ける構成が一般的です。

【落とし穴】MediaPackage v2側でSCTE-35マーカーの付与設定を有効化し忘れると、MediaTailorに広告挿入のトリガーが渡らず、広告が一切挿入されないままコンテンツだけが配信されてしまいます。パイプライン全体を疎通確認する際は、MediaPackage v2のマニフェスト上にマーカーが実際にシグナルされているかを、MediaTailor連携の前に単独で確認しておくことが重要です。もう一つの典型的な落とし穴は、CloudFrontのキャッシュ設定です。MediaTailorが生成するマニフェストは視聴者ごとにパーソナライズされるため、マニフェスト自体をCDNで長時間キャッシュしてしまうと、広告の出し分けが機能しなくなります。マニフェストとセグメントでキャッシュ挙動を分けて設計する必要があります。

【Vol1連携】Vol1のMediaLiveで解説したライブエンコードの出力設定に、SCTE-35マーカー付与という新たな設定項目が本記事で加わります。Vol1側の設定を変更する場合は、本節の連携パイプラインに影響が及ぶ点を踏まえて調整してください。Vol1で単一のCloudFrontディストリビューションのみを構築していた場合は、本節を機にMediaTailor向けディストリビューションを追加する構成変更が必要になります。

【具体例】1つの広告ブレイクがパイプラインを通過する様子を追うと、次のようになります。まずMediaLiveが、番組内のCM入れ替えタイミングでSCTE-35マーカーを埋め込んだストリームを送出します。MediaPackage v2はこれを受け取り、該当箇所にDaterangeタグ(またはEventStream要素)を付与したマニフェストを生成します。視聴者からの再生リクエストを受けたMediaTailorは、このマニフェストを取得する過程でマーカーを検知し、ADSへ広告クリエイティブをリクエストします。取得した広告クリエイティブのURLをマニフェストへ組み込んだ、視聴者ごとにユニークなパーソナライズドマニフェストが生成され、CloudFront経由で視聴者へ配信されます。1回の視聴リクエストのたびにこの一連の処理が動的に実行される点が、あらかじめ広告を焼き込んでおく方式との違いです。

【補足】この一連の処理は視聴セッションごとに独立して実行されるため、同じ番組を視聴している複数の視聴者に対して、それぞれ異なる広告クリエイティブを配信するパーソナライズが実現します。マニフェスト生成の負荷はMediaTailor側で吸収されるため、視聴者数の増減に応じてMediaPackage v2やMediaLiveの構成を変更する必要はありません。

2-6. 東京リージョン・提供状況

MediaPackage v2・MediaTailorともに、東京リージョン(ap-northeast-1)で提供中です。本シリーズで扱うMediaLive/MediaConvert/CloudFrontと同一リージョンで完結してパイプラインを構築できます。

なお、MediaPackage v2自体は2023年5月に現行世代としてローンチされていますが、東京リージョンでのMediaPackage v2の提供開始日については一次情報で明確な日付を確認できなかったため、本記事では断定を避けます。現時点で東京リージョンのエンドポイントが提供されていることは公式情報で確認済みです。

旧世代のMediaPackage v1は、v2が現行推奨世代となった後もサービス終了(EOL)はしておらず、既存ユーザー向けに稼働を継続しています。ただしv1からv2への自動移行機能は用意されておらず、移行は手動での作業が必要です(移行の実務は§5-3で扱います)。

【判断根拠/落とし穴】新規にパイプラインを構築する場合は、現行世代であるv2を選ぶのが基本方針になります。一方で、既にv1で運用中のパイプラインを持つ組織は、移行タイミングを急ぐ必要はありません。v1は非EOLのため、東京リージョンを含めて稼働を継続できますが、v2で追加された機能(クロスリージョンフェイルオーバーなど)を利用したい場合は、手動移行の計画を別途立てる必要があります。マルチリージョン構成を検討する際は、東京以外のリージョンでのサービス提供状況もあわせてAWS公式のリージョン別サービス一覧で確認してください。

【補足】東京リージョンでの提供状況を確認する際は、MediaPackage v2・MediaTailorの両方だけでなく、本シリーズで組み合わせるMediaLive・CloudFrontも同一リージョンで揃っているかをあわせて確認すると、リージョンをまたぐ通信によるレイテンシの発生を防げます。

2-7. 概念のまとめ — 責任分界と全体像

ここまでの内容を踏まえて、MediaPackage v2とMediaTailorがなぜ1つのサービスに統合されず、あえて2サービスに分かれているのかを整理します。

パッケージング(MediaPackage v2)と広告挿入(MediaTailor)は、それぞれ変更の頻度も性質も異なります。パッケージング設定は、配信フォーマットやDRMポリシーの変更といった比較的低頻度な意思決定である一方、広告挿入まわりの設定(ADSの切り替え、広告主・広告プラットフォームとの連携)は、マネタイズ戦略の変化に応じてより高頻度に見直される傾向があります。この2つを1つのサービスに統合してしまうと、広告まわりの頻繁な変更のたびにパッケージング設定へ影響が及ぶリスクを伴うため、責任範囲を分離しておくメリットがあります。

もし本記事の2サービスのうちどちらか一方が欠けた場合を考えると、両者の役割がより明確になります。MediaPackage v2だけでは、配信フォーマットへの変換とオリジン機能は満たせますが、広告によるマネタイズの手段がありません。逆にMediaTailorだけでは、そもそも配信可能な形式へパッケージされたコンテンツオリジンが存在しないため、広告を挿入する対象自体が用意できません。両者が揃って初めて、パッケージングとマネタイズを兼ね備えた配信パイプラインが完成します。

この責任分界を理解しておくことが、§3以降で個々のサービスの詳細な設定・運用ハンズオンを読み進める際の土台になります。

この責任分界はコスト構造にも表れています。次項で扱うように、パッケージングと広告挿入は課金の単位も性質も異なるため、責任分界を明確にしておくことは、コスト配分を把握するうえでも役立ちます。

2-8. コスト構造の考え方 — 従量課金の設計インパクト

MediaPackage v2とMediaTailorを組み合わせて運用する際は、それぞれの課金体系の違いを理解しておくことが、全体のコスト設計に役立ちます。

MediaPackage v2は、主に入力されたデータ量とパッケージング処理(JITPによるフォーマット変換)、および視聴者への出力データ量に応じた従量課金です。一方MediaTailorは、広告挿入のためのマニフェスト書き換え処理(ad decisioning)のリクエスト数や、パーソナライズされたマニフェストの生成量に応じて課金されます。

判断根拠として重要なのは、視聴者数が増えるほどMediaTailor側の従量コストが広告挿入の処理量に比例して増加する点です。広告収益によるマネタイズ効果と、MediaTailor導入によるコスト増加分を、事前に試算しておくことが望ましいといえます。

一方MediaPackage v2側のコストは、パッケージング形式の数(Origin Endpointの数)や入力冗長化の有無によっても変動します。配信フォーマットを増やすほど、あるいは入力冗長化を組むほど処理量が増えるため、視聴者数の増加だけでなく、これらの構成要素の増減もコスト設計に織り込んでおく必要があります。

【落とし穴】正確な料金体系や単価はサービスアップデートにより変更される可能性があるため、本記事では具体的な金額には踏み込みません。実際の設計では、必ずAWS公式の料金ページで最新の課金項目を確認したうえで、想定視聴者数・広告在庫量に基づいて試算してください。

【運用ハンズオン】CloudWatchでMediaPackage v2とMediaTailorそれぞれのメトリクスを分けて監視し、月次のコスト推移をサービス単位で追跡できるようにしておくと、広告収益とコストのバランスを継続的に評価しやすくなります。

3. MediaPackage v2 — Channel Group/Channel/Origin Endpoint

3-1. 3階層 — Channel Group/Channel/Origin Endpoint

MediaPackage v2のリソースは、Channel Group・Channel・Origin Endpointという3階層で構成されています。この階層構造を理解することが、v2を正しく設計・運用するための出発点になります。

最上位に位置するChannel Groupは、配下に属するすべてのChannelとOrigin Endpointが同一のegress(出力側)ドメインを共有するという特性を持ちます。MediaPackageはChannel Groupを作成する際に、この共有egressドメインを1つ発行します。判断根拠としては、この設計のおかげで視聴側やCDN(CloudFront)は個々のリソースのFQDNを意識せず、Channel Group単位で予測可能なURL体系を組めるという利点があります。

Channelは、MediaLiveなどのアップストリームエンコーダが送信してくるABR(Adaptive Bitrate)ストリームの「入口」です。1つのChannelは1系統の入力ストリームセットに対応し、ここでコンテンツを受け取ったMediaPackageが、以降のOrigin Endpointへパッケージ済みのコンテンツを引き渡します。

Origin Endpointは、Channelに対して作成する「出口」であり、実際にどのストリーミング形式(HLS/LL-HLS/DASH/CMAF)でどのようなパッケージング設定を使うかを決めるのはここです。ハンズオン視点で重要なのは、1つのOrigin Endpointには必ず1つのPackagerしか設定できないという制約です。同じソースコンテンツを複数の形式(たとえばHLS向けとDASH向け)で同時配信したい場合は、同じChannelに対して形式ごとにOrigin Endpointを追加作成する必要があります。

落とし穴として、Channel Group単位で固定されるのはegressドメイン(出力側)だけであり、ingest(入力側)のドメインはChannel単位で発行される点に注意してください。この違いを混同すると、次項の入力冗長化の設計を誤ります。

Vol1連携の観点では、Vol1で扱ったMediaLiveの出力設定は、本節のChannelに対する入力(ingest)そのものに相当します。MediaLiveのOutput Groupの送信先URLを設計する際は、ここで作成するChannelのingestドメインを指定することになります。

設計ハンズオンとして押さえておきたいのは、Channel Groupの命名設計です。egressドメインはChannel Group単位で決まるため、たとえば地域別や事業ライン別にChannel Groupを分けておくと、URL体系そのものが組織構造を反映した形になります。逆に、すべてのチャンネルを1つのChannel Groupにまとめてしまうと、egressドメインは1系統へ集約される一方で、リソースの権限分離やアクセス制御の粒度は粗くなる点にも注意が必要です。運用規模やチーム体制に応じて、Channel Groupの分割単位を事前に設計しておくことをおすすめします。

3-2. v2のスコープ — ライブ特化とv1との関係

MediaPackage v2を利用するうえで最も重要な前提は、v2がライブオリジンに特化したサービスであり、VOD(ビデオオンデマンド)専用のOrigin Endpointは提供されていないという点です。これはAWS公式ドキュメントでも明示されている仕様であり、「v2でVOD専用配信ができる」という理解は誤りです。

VODコンテンツを配信したい場合は、v1系列に用意されているVOD専用リソース(mediapackage-vod)を利用するか、v2のライブチャンネルでハーベスト(録画)したコンテンツを別途VOD配信基盤に渡す構成を取る必要があります。判断根拠としては、v2はあくまで「ライブのJIT(ジャストインタイム)パッケージングとオリジネーション」に機能を集中させて設計されているためです。

v1はレガシー世代という位置づけですが、廃止(EOL)されたわけではありません。2023年5月にv2が現行推奨世代として提供開始されて以降も、v1は既存ユーザー向けに提供が継続されています。実務では「レガシー=使えなくなる」と早合点せず、v1の提供状況を都度確認することが大切です。

落とし穴として最も見落とされやすいのが、v1からv2への自動移行パスが用意されていないという点です。v2のリソース(ARNやAPIエンドポイント名)には”mediapackagev2″という文字列が含まれ、v1とは別物として扱われます。そのため、v1に構築済みのChannel/Endpointをv2へ移行するには、Channel Group/Channel/Origin Endpointを手動で新規設計・再構築する前提としてスケジュールを組む必要があります。

Vol1連携としては、Vol1でMediaLiveの出力プロファイルを設計する段階から、配信がライブ専用なのか将来VODも扱うのかを見極めておくことが重要です。ライブ配信のみであればv2で完結しますが、VOD配信も視野に入れる場合は、Vol1で解説したMediaConvertによるファイルベース変換や、v1・harvestとの組み合わせを検討する必要があります。

具体的な設計判断としては、まず本番のライブ配信をv2へ集約し、視聴済みライブ配信のハイライトやアーカイブ配信が必要になった段階で、ハーベストジョブによる録画コンテンツをMediaConvertやv1 VODのワークフローへ引き渡す、という二段構えの構成が現実的です。ライブとVODを最初から1つのサービスで賄おうとせず、「ライブはv2」「VODは既存のMediaConvert/v1資産」という役割分担を明確にしておくと、将来の機能追加や移行作業の影響範囲を小さく保てます。

3-3. 入力とinput redundancy

MediaPackage v2への入力は、HLSまたはCMAF ingestのいずれかの形式で、MediaLiveなどのエンコーダからHTTPSプロトコルによるプッシュ(push)方式で送信されます。ソースには少なくとも1つの映像トラックが必須で、映像トラックを含まない入力はサポートされません。

入力の冗長化(input redundancy)は、ライブワークフローでのみ提供される機能です。MediaPackageはChannelを作成する際に2つのingestドメインを発行し、それぞれに同一内容のストリームを送信することで、一方に障害が発生してももう一方へ自動的にフェイルオーバーする仕組みになっています。片方が「アクティブ」として実際の配信元になり、もう片方は「パッシブ」として受信を継続する構成です。

ハンズオンの注意点として、MediaLive以外のエンコーダを使って冗長構成を組む場合は、2つのストリームのエンコーダ設定とマニフェスト名を完全に一致させる必要があります。設定を完全に一致させないと、フェイルオーバー時にコンテンツの切り替えに失敗し、再生の途切れにつながります。

落とし穴として、入力冗長化はChannel単位の機能であり、Channel Group単位で共有されるのはegressドメイン(出力側)だけである点を再確認してください。「Channel Groupを作成すれば入力も自動的に冗長化される」という誤解をしないよう注意が必要です。

Vol1連携の観点では、Vol1で構築したMediaLiveの冗長出力設定(プライマリ/バックアップの2系統出力)が、そのままこの2つのingestドメイン宛の送信先に対応します。エンコード段とパッケージング段が対になって冗長化設計を構成していると捉えると、理解しやすくなります。

運用ハンズオンとして、冗長化を組んだ後はCloudWatchメトリクスで両方のingestドメインの受信状況を継続的に監視することをおすすめします。アクティブ側の受信が途絶えてパッシブ側へ切り替わった際に、アラームで検知できる体制を整えておかないと、フェイルオーバー自体は成功していても、根本原因(エンコーダ障害やネットワーク経路の問題)への対応が遅れてしまいます。冗長化は「切り替わって終わり」ではなく、切り替わりが発生したこと自体を運用チームが把握できる仕組みとセットで設計する必要があります。

4. パッケージング形式とコンテンツ保護 — LL-HLS/CMAF/DRM/SCTE-35

4-1. パッケージング形式の選択 — LL-HLSと低遅延

MediaPackage v2のOrigin Endpointでは、HLS/LL-HLS/DASH/CMAFという複数のパッケージング形式を選択できます。判断根拠となるのは、視聴体験として許容できる遅延と、配信先デバイスの互換性です。

標準的なHLSは、多くのApple端末やブラウザで広くサポートされている一方、レイテンシは18〜30秒程度になります。これに対しLL-HLS(Low-Latency HLS)は、標準HLSを拡張した仕様で、レイテンシを3〜5秒まで短縮できます。ライブスポーツ観戦やリアルタイム性が重視されるインタラクティブ配信では、このLL-HLSの選択が判断の分かれ目になります。

ハンズオンの観点で重要なのは、LL-HLSを有効にする場合、EXT-X-PROGRAM-DATE-TIME(PDT)タグの付与が必須になる点です。標準HLSではPDTは任意設定ですが、LL-HLSでは低遅延を実現する仕組み上、必須要件として扱われます。

CMAFは、HLSとDASHの両方から参照できる共通コンテナ形式で、H.265やHDR-10といった高度なコーデックにも対応します。なお、AV1コーデックはCMAFエンドポイントでのみサポートされ、TS(MPEG-2 Transport Stream)エンドポイントでは利用できない点に注意してください。

2025年には、MediaPackage v2にDVB-DASHのサポートが追加されました。DVB-DASHは、欧州の放送業界標準であるDVB(Digital Video Broadcasting)がMPEG-DASHをベースに策定した配信仕様で、字幕形式のEBU-TT-Dにも対応しています。判断根拠としては、欧州の放送事業者や、DVB準拠のセットトップボックス・スマートTVをターゲットに含む配信では、標準DASHではなくDVB-DASHでの配信が要件になる場合があります。ハンズオンとしては、Origin Endpoint作成時のDASHマニフェスト設定画面で、字幕形式としてIMSC-1かEBU-TT-Dのいずれかを選択できるようになっています。「DASHで配信していれば欧州の要件も自動的に満たす」と早合点せず、対象マーケットの仕様書でDVB-DASH準拠が求められているかを確認することが大切です。

各形式の使い分けの目安を、以下の表にまとめます。

落とし穴として、LL-HLSを配信側で有効にしても、再生側のプレイヤーが低遅延拡張タグ(EXT-X-PART、EXT-X-PRELOAD-HINTなど)に対応していなければ、低遅延化の恩恵は得られません。エンドポイント設定だけでなく、視聴環境全体の対応状況を確認する必要があります。

Vol1連携としては、Vol1でMediaLive側の低遅延入力を設定していても、パッケージング層であるMediaPackageでLL-HLSエンドポイントを作成しなければ、配信全体としての低遅延は実現しません。エンコード段とパッケージング段の両方で低遅延設定が揃って初めて、エンドツーエンドの低遅延配信が成立します。

4-2. コンテンツ保護 — SPEKE v2 DRM

SPEKE(Secure Packager and Encoder Key Exchange)は、パッケージャとDRMキーサーバーとの間の鍵交換を標準化するプロトコルです。MediaPackageはSPEKE v1とv2の双方をサポートしており、v2はCPIX(Content Protection Information Exchange)バージョン2.3に準拠した仕様として位置づけられています。

判断根拠として重要なのは、SPEKE v2.0を選ぶ最大の利点が、複数の異なる暗号化キーを使い分けられる点にあることです。具体的には、ライブのDASH/CMAFストリームに対して、映像トラック用と音声トラック用に別々の鍵を割り当てられます。単一の鍵で足りるシンプルな要件であればSPEKE v1でも運用できますが、より高度なコンテンツ保護要件がある場合はv2を選択します。

ハンズオンの手順としては、SPEKE v2.0を選択する際に、Video encryption presetとAudio encryption presetをそれぞれ個別に指定します。この2つのプリセットの組み合わせが、実際にストリームへ適用される暗号化キーの体系を決定します。

対応するDRMシステムは配信形式によって異なります。HLSエンドポイントではAES-128またはSample AES暗号化方式が使え、Sample AESはFairPlayと、AES-128はClear Keyと組み合わせます。一方、DASH/CMAFエンドポイントでSPEKEを利用する場合は、Widevine・PlayReady・FairPlayといった主要DRMシステムに対応します。

SPEKE v2.0対応のDRMプラットフォームパートナーには、Axinom・BuyDRM・castLabs・Inka Entworks・Intertrustなどがあります。ハンズオンの実務では、これらのパートナーのキーサーバーをSPEKEエンドポイントとして設定し、MediaPackage側からのキー要求に応答できるよう準備しておく必要があります。マルチDRM(複数のDRMシステムを同時に使う構成)を組む場合は、キーサーバー側がWidevine/PlayReady/FairPlayそれぞれに対応した鍵を返せるかどうかを事前に確認しておくことが重要です。

落とし穴として、HLSとDASH/CMAFとで対応可能なDRM方式の組み合わせが異なるため、複数プラットフォーム向けに同時配信する場合は、エンドポイントごとに適切な暗号化設定を個別に組む必要があります。「1つの設定で全デバイス向けのDRMを賄える」という誤解は避けてください。

Vol1連携の観点では、Vol1で解説したMediaConvertによるファイルベースの事前エンコード・暗号化と、本節のMediaPackageによるライブストリームへのリアルタイム暗号化は、鍵管理の仕組みが異なります。VOD向けの暗号化設計とライブ向けの暗号化設計を混同しないよう注意が必要です。

4-3. 広告マーカー(SCTE-35) — MediaTailorへの橋渡し

SCTE-35は、放送業界標準の広告切り替えシグナリング規格です。コンテンツストリームの中に「ここから広告に切り替えてよい」「ここで本編に戻る」といったタイミングをマーカーとして埋め込みます。

MediaPackage v2は、HLSマニフェストにおいて、Daterange形式またはSCTE-35のenhanced CUEタグという2つの方式でこのマーカーをシグナリングできます。DASHマニフェストの場合は、EventStream要素を使い、マーカー情報をXML要素として展開する「XML形式」と、base64エンコードされたSCTE-35マーカーを1つのSignal要素にまとめる「Binary形式」のいずれかを選択します。

判断根拠としては、後段のマニフェスト消費者(プレイヤーや広告挿入システム)がどちらの形式を期待しているかに応じて選びます。次章で扱うMediaTailorのSSAI(サーバーサイド広告挿入)は、まさにこのSCTE-35マーカーを検知して広告差し替えのトリガーとする仕組みです。

ハンズオンとしては、Origin Endpointの作成・編集時にAd markers設定項目でシグナリング方式を指定します。実運用では、MediaLive側で広告挿入ポイントにSCTE-35マーカーを打ち込み、MediaPackageがそれを受け取ってマニフェストへ反映するという流れになります。

シグナリング方式を選ぶ際は、配信先のマニフェスト形式だけでなく、後段のMediaTailorやサードパーティの広告挿入システムがどちらの表現形式をパースできるかも合わせて確認しておくと、後工程での手戻りを避けられます。HLS/DASHを両方配信する構成では、それぞれのOrigin EndpointでAd markers設定を個別に指定する必要がある点も、見落としやすいポイントです。

落とし穴として、このSCTE-35マーカーの設定を怠ると、後段のMediaTailorが広告挿入タイミングを検知できず、SSAIそのものが機能しません。パッケージング層(本章)と広告挿入層(次章)は密接に連動しているため、どちらか一方だけを設定しても配信パイプライン全体は完成しない点に注意してください。

Vol1連携としては、Vol1のMediaLiveで広告挿入ポイントの設計(SCTE-35マーカーを打ち込むタイミングの設計)を済ませておくことが前提になります。本Vol2のMediaPackageは、そのマーカーを中継・シグナリングする役割を担うのであり、マーカー自体を生成する役割ではありません。

5. MediaPackage v2の運用 — 冗長化・タイムシフト・移行

5-1. タイムシフト/DVR — ライブ視聴体験

MediaPackage v2のタイムシフト視聴(Time-shift Viewing)は、現在時刻より前の時点からストリームを再生できる機能です。スタートオーバー(番組冒頭からの視聴)、キャッチアップTV(見逃し視聴)、タイムディレイ(遅延視聴)のいずれもサポートしています。

判断根拠として、スポーツ中継やイベント配信では「視聴を開始した時点で既に試合が始まっている」という体験が視聴離脱の一因になります。タイムシフトを組み込むことで、視聴者は任意のタイミングで参加しても番組冒頭から視聴を開始でき、Vol1で構築したMediaLiveのライブ配信の価値を最大化できます。

ハンズオンの勘所としては、Origin Endpoint側の再生ウィンドウ設定でタイムシフト可能な範囲(何分前まで遡れるか)を決定します。この範囲はChannel側のマニフェスト保持期間と密接に関係するため、想定する最大タイムシフト幅に合わせてChannelの保持設定も合わせて見直す必要があります。

★落とし穴として、タイムシフト機能はライブワークフローでのみ提供される点に注意してください。VODコンテンツには適用されず、また後述のとおりMediaPackage v2自体に専用のVODエンドポイントも存在しません(詳細は3-2参照)。「録画済みコンテンツもタイムシフトで遡れる」という誤解をしないよう、設計段階で用途を明確にしておくことが重要です。

5-2. クロスリージョンフェイルオーバー — 高可用性設計

2024年6月、MediaPackage v2にクロスリージョンフェイルオーバー機能が追加されました。これは、CDNが複数リージョンに配置したMediaPackage Liveオリジン間で透過的にフェイルオーバーできるようにする高可用性設計です。単一リージョン障害時でもライブ配信を継続できるため、Vol1で扱ったGameLiftのようなミッションクリティカルな配信基盤との親和性が高い機能です。

判断根拠は、CDN側から見て複数オリジンが「対称的(symmetric)」に見える必要がある点です。具体的には、関与する全リージョンのChannelとOrigin Endpointで、URLパス・セグメンテーションパラメータ・暗号化設定を厳密に一致させます。また入力形式はCMAF Ingest(Interface-1)であることが前提です。

ハンズオンでは、プライマリ側のOrigin Endpointにforce-endpoint error設定(stale manifest・incomplete manifest・slate inputなど)を積極的に有効化し、バックアップ側では有効化しないのが推奨構成です。CDN(CloudFront等)のディストリビューション側は、ネットワーク接続エラーやHTTP 404応答を検知したらオリジンフェイルオーバーをトリガーするよう設定します。

★落とし穴は、プライマリとバックアップの設定が非対称だと、CDN側の自動フェイルオーバー判定そのものが機能しなくなる点です。また、この機能自体は追加コストなしで有効化できますが、MediaLive側(Vol1)でも同様にリージョン跨ぎの入力冗長化を組んでおかないと、パイプライン全体としての高可用性は完成しません。

5-3. v1→v2移行 — 手動移行の勘所

MediaPackage v1からv2への移行について、AWS公式ドキュメントは「自動移行プロセスは存在しない」ことを明記しています。v2はv1の後継として2023年5月に登場した現行世代ですが、v1はレガシー化しているだけで廃止(EOL)されたわけではなく、v1向けユーザーガイドも提供が継続されています。

判断根拠として、v1とv2はリソースの命名体系(v2はARN/URLに”mediapackagev2″を含む)からAPI/CLIまで別系統で設計されており、v1のCLI/APIからv2リソースへ、あるいはその逆にアクセスできません。そのため移行は「置き換え」ではなく「並行構築→切替」という手順を取ります。

ハンズオンの手順としては、①v2側でChannel Group/Channel/Origin Endpointを新規作成、②MediaLive(Vol1)のエンコーダ出力先をv2の新しいIngest URLに切替、③視聴側(プレーヤー/CDN)のマニフェストURLをv2のOrigin Endpoint URLに切替、という順序が基本です。

★落とし穴として、既存のVODワークフローをv1で運用中の場合は、無理にv2へ寄せる必要はありません。v2はあくまでライブ配信の後継世代であり、VODは引き続きv1系またはMediaConvert(Vol1)による別経路での配信が現実的な選択肢になります。移行を検討する際は、まずライブ配信の範囲から段階的に着手し、二重運用期間を設けてマニフェストURL切替の影響を検証してから本切替するのが安全です。

6. MediaTailor — SSAI/ad decisioning/Channel Assembly

6-1. ad decisioning — ADSとVAST/VMAP

MediaTailorは、コンテンツ内のSCTE-35広告マーカー(§4-3でMediaPackage v2が付与)を検知すると、設定済みの広告デシジョンサーバー(ADS)へリクエストを送信します。このリクエストには視聴者パラメータや広告ブレイクの尺(duration)が含まれ、ADSはIAB準拠のVAST(pre-roll中心の単一広告向け)またはVMAP(pre/mid/post-rollの配置情報を含む)形式で応答します。

判断根拠として、VASTとVMAPの使い分けは「広告ブレイクの配置をどちらが管理するか」で決まります。マニフェスト側にSCTE-35マーカーがある場合はそのマーカー位置に沿って広告を挿入しますが、マーカーがない場合はADSがVMAPで返す配置情報(pre/mid/post-rollのオフセット)に従って広告ブレイクを組み立てます。

ハンズオンの勘所は、ADSへのリクエストからマニフェスト配信までが一連のタイムアウト管理下で進む点です。ADSが設定済みのタイムアウト閾値(Playback Configuration側で管理する設定項目)を超えて応答しない場合はADS_TIMEOUTとして広告挿入がスキップされ、コンテンツ本編の再生がそのまま継続されます。AWS公式ドキュメントでは、広告機会の検知からパーソナライズドマニフェスト配信までの一連の処理が概ね2〜5秒程度で完了することを目安として示しており、この時間内に収まるようADS側の応答性能を設計することが推奨されています。

★VAST/VMAP応答内にリダイレクト(wrapper)が含まれる場合、MediaTailorは最大7階層までのwrapper redirectを追跡します(HTTPリダイレクト自体には階層の上限がありません)。redirectチェーンが深いプログラマティック広告構成では、階層が増えるほど累積の応答時間が伸びタイムアウトに達しやすくなるため、ADSパートナー側のリダイレクト段数をあらかじめ把握しておくことが落とし穴の回避につながります。

Vol1で構築したMediaLiveのライブ配信にSCTE-35マーカーを含めておくことが、この章で扱うad decisioningの前提になります。マーカーが正しく伝搬していない場合、ADSへのリクエストは発生しません。広告未挿入の不具合が起きた際は、まず§4-3のSCTE-35付与設定から確認してください。

6-2. Channel Assembly — VODからリニアチャンネル

Channel Assemblyは、既存のVODコンテンツ(とライブコンテンツ)を組み合わせてリニア配信チャンネルを生成する、マニフェストオンリーのサービスです。★MediaTailorはコンテンツセグメント自体には一切手を加えず、視聴者へは常にオリジンサーバーから直接セグメントが配信されます。MediaTailorが行うのは、オリジンのマニフェストを取得し、メディアシーケンス番号などを管理しながらスライディングウィンドウ型のライブマニフェストへ組み立てる処理だけです。

判断根拠として、この方式は既にマルチビットレートでエンコード・パッケージ済みのVODアセットをそのまま流用できるため、24時間リニアチャンネルを低コストで構築できる点にあります。Vol1のMediaConvertで作成済みのVODライブラリを、そのままリニア編成に転用できるのが大きな利点です。

ハンズオンは、①Source Location(コンテンツの取得元)の登録、②Channel(配信単位)の作成、③Program(番組スケジュール)の追加、という3段階で進めます。★Channel AssemblyはSCTE-35マーカーによるコンテンツの事前条件付けなしで広告ブレイクを挿入できるため、MediaTailorの広告挿入機能や任意のサーバーサイド広告挿入サービスと組み合わせてマネタイズが可能です。

★落とし穴は、セグメント自体を改変しないという設計上、配信品質(ビットレート/コーデック/パッケージ形式)は元のVODアセットの品質にそのまま依存する点です。低ビットレートでしかエンコードしていないVODをリニア編成に転用すると、視聴体験もそのまま低品質になってしまいます。

6-3. パーソナライズとMediaPackage/CloudFront連携

MediaTailorは、標準連携パイプライン(§2-3)ではMediaPackage v2のOrigin Endpointをオリジンとして利用し、視聴者ごとにパーソナライズしたマニフェストを生成した上でCloudFrontを介して配信します。

判断根拠となる推奨アーキテクチャは、CDN(CloudFront)を視聴者とMediaTailorの間に配置し、MediaTailorとオリジン(MediaPackage v2)の間にはCDNを挟まない、という構成です。MediaTailorが直接オリジンへリクエストしてマニフェストを取得し、広告を挿入したのち、CDN経由で視聴者へ配信する流れになります。

ハンズオンの注意点として、★MediaTailorとオリジンサーバー間の通信はポート80/443のみをサポートしており、カスタムポートは利用できません。既存のオリジン構成がカスタムポートを使っている場合は、MediaTailor連携にあたって標準ポートへの変更が必要です。

★落とし穴は、「オリジン側の負荷分散のために」とMediaTailorとMediaPackage v2の間に独自のCDNやリバースプロキシを挟んでしまう構成です。この構成は非推奨とされており、キャッシュ挙動によって広告パーソナライズ用のマニフェストが意図せずキャッシュされ、全視聴者に同一の広告が配信されてしまうといった不具合の原因になります。CDNは常に「視聴者側」に配置するのが鉄則です。

7. MediaTailorの運用 — レポート・2026新機能

7-1. 広告レポート — サーバー/クライアントサイド

MediaTailorの広告視聴計測には、サーバーサイドとクライアントサイドの2方式があります。どちらを選ぶかは、既存の広告計測基盤をそのまま活かしたいか、プレーヤー実装を軽量に保ちたいかという判断軸で決まります。

サーバーサイド方式では、MediaTailorが広告クリエイティブの再生状況を検知し、インプレッション/クオータイル(25/50/75/100%)などのトラッキングURLへ直接HTTPコールバックを送信します。プレーヤー側に追加のビーコン実装は不要で、SSAIの強みである「放送品質のまま計測できる」利点をそのまま活かせる方式です。

クライアントサイド方式では、プレーヤー自身が再生進捗に応じてビーコンを発火し、広告主/DSP側の既存計測タグと直接連携します。広告販売側がクライアントサイドのビーコン計測しか受け付けない場合や、視聴デバイス側でのアドフラウド検知を重視する場合に選ばれます。

運用ハンズオンとしては、Origin Endpointの設定でトラッキング挙動を確認したうえで、CloudWatchのメトリクス/ログでビーコン到達率やADS応答の異常を継続的に監視する体制を組みます。落とし穴として、広告主側の計測要件がどちらの方式を前提にしているかを事前にすり合わせないと、レポートの数値が広告主側の計測結果と食い違い、マネタイズ効果の検証ができなくなる点に注意が必要です。

7-2. 2026年の新機能 — Monetization Functions等

MediaTailorは2026年に入り、マネタイズ運用を強化する新機能を相次いで提供しています。いずれも公式の発表(AWS What’s Newおよびドキュメント)で確認済みの内容です。

1つ目は、2026年5月7日にGA(一般提供開始)となったMonetization Functionsです。これは、ADS(広告配信サーバー)へのリクエスト内容やセッションデータの変換を、プレーヤーとADSの間にミドルウェアを構築せずに実行できる仕組みです。ハッシュ化されたメールアドレスをLiveRampのようなIDプロバイダーでプライバシー準拠のID情報に解決したり、Gracenoteのようなコンテンツメタデータサービスからの情報を広告リクエストに付加したり、The Trade Deskのようなヘッダービディング連携をしたりと、最大5つの関数をチェーンして構成できます。各関数はfail-open設計のため、エラーやタイムアウトが発生してもデフォルトの広告挿入にフォールバックし、視聴体験を止めません。課金は関数の数や複雑さによらず、呼び出し単位の定額です。

2つ目は、Google Ad Manager(GAM)・Google Campaign Manager(GCM)・Display & Video 360(DV360)とのサーバー間連携の自動化です。従来はAWSサポートケース経由でのアローリスト登録が必要でしたが、現在はMediaTailorがGoogle広告サーバー宛てのリクエストを自動検知し、認証済みの安全な接続を自動確立します。東京リージョンを含む主要リージョンで追加費用なく利用できます。

3つ目は、2025年11月にGAとなったライブストリーム向けHLS Interstitialsです。EXT-X-DATERANGEとX-ASSET-LISTタグでインタースティシャル(広告)コンテンツをプレーヤーに伝え、HLS.js/Shaka Player/Bitmovin PlayerやiOS/tvOS 16.4以降のネイティブプレーヤーで再生できます。LL-HLSの低遅延タグ(EXT-X-PRELOAD-HINT等)との共存にも対応しており、広告break中は完全セグメント配信に切り替えたうえで、本編再開時に低遅延の部分セグメント配信へ戻る設計です。

判断根拠としては、これらはいずれもミドルウェア運用負荷や手動申請といった従来の運用上の摩擦を取り除く方向の機能強化であり、マネタイズ設計をシンプルに保ちたい配信事業者にとって採用メリットが大きいといえます。

7-3. マネタイズ設計の要点

マネタイズ設計をまとめると、MediaTailorはSSAIによって放送品質を維持したまま広告を挿入し、VAST/VMAP・Channel Assemblyという2つの広告配信の仕組みを状況に応じて使い分けます。2026年の新機能はいずれも「広告連携の運用負荷を下げる」方向で共通しており、既存のADS/広告プラットフォームとの連携をより少ない実装量で維持できるようになっています。Vol1で構築したエンコード/ライブ配信の基盤の上に、本章までのSSAI連携を重ねることで、視聴体験を止めずに収益化する配信パイプラインが完成します。

8. まとめ — 完成した配信パイプライン

8-1. この記事の振り返り

本記事では、動画配信パイプラインの後段にあたる2サービスを扱いました。MediaPackage v2は、Channel Group/Channel/Origin Endpointの3階層でライブオリジンとパッケージングを担い、LL-HLS/CMAF/DASHといった配信形式の選択、SPEKE v2によるDRM、SCTE-35による広告マーカー付与までを受け持ちます。MediaTailorは、そのSCTE-35マーカーを起点にSSAI(サーバーサイド広告挿入)を担い、VAST/VMAP連携やChannel Assembly、そして2026年の新機能群によってマネタイズ運用を支えます。

MediaLive(Vol1)からMediaPackage v2、MediaTailor、CloudFrontへと連なる一連の流れによって、パッケージング(配信品質)とマネタイズ(収益化)の両方を備えた本番運用パイプラインが完成します。

8-2. Vol1との結線とこの先

Vol1では、AppStream/MediaConvert/MediaLive/GameLiftを扱い、コンテンツのエンコードとライブ配信、ゲーム配信の基盤を構築しました。本Vol2は、その先にあるパッケージングと広告挿入のレイヤーを深掘りし、Vol1が前方参照で触れるにとどめていた領域を完成させています。

Vol1とVol2を合わせることで、動画配信パイプラインはエンコード・配信からパッケージング・マネタイズまでの一巡を成しています。一方で、本Vol2はパイプライン連携の視点を優先しており、DRM(SPEKE/FairPlay等)の実装詳細やVAST/VMAPの高度な広告在庫設計といった専任テーマを網羅的に深掘りするには至っていません。これらをexhaustiveに扱うテーマは、MediaTailor専任のVol3として後続化する余地があります。

← Game/Media Vol1を読む

← Game/Media Vol1を読む