動画配信システムの構築｜トランスコードからHLS配信・視聴制御・DRMまで実装解説

動画配信システムの構築とは、動画ファイルを受け取ってから視聴者の端末で再生されるまでの処理を、変換・パッケージング・配信・視聴制御という層に分けて組み上げる作業です。サーバーに置いてリンクを配るだけなら30分で終わりますが、同時視聴が増えても止まらず、契約者以外に見られない基盤にしようとした瞬間に設計判断が増えます。この記事では、トランスコードジョブの非同期起動、ビットレートラダーの設計、CMAFでの出力一本化、CDNのキャッシュ設計、署名付きCookieによる視聴権限の制御、SPEKE経由のマルチDRMまでを実装粒度で整理します。

まとめ｜動画配信システム構築の全体設計と技術判断の要点

動画配信システムの構築は、5つの処理段階に分けて考えると設計が固まります。アップロード受け口、トランスコード（複数画質への変換）、パッケージング（HLSやMPEG-DASHへの整形）、CDN配信、視聴権限の制御です。

技術選定で迷いやすい箇所は3つです。1つ目はパッケージング形式で、HLSとMPEG-DASHを別々に生成すると容量も変換時間も倍になるため、CMAFで断片化MP4を共有する構成が基本形になります。2つ目は視聴制御で、1本の動画が数百のセグメントに分かれるHLSでは、署名付きCookieでパス配下をまとめて許可するほうが安定します。3つ目はDRMで、鍵をURLで取りに行くAES-128に対し、DRMは端末側の保護された領域で復号するため、権利者から要求される案件では代替できません。

判断の分岐点は「同時視聴数の規模」と「保護要件の強さ」の2軸です。社内研修の数百人規模で権利者要求もないならASPで足ります。数万人規模のイベント配信や有料コンテンツ、権利者からDRMを指定される映像であれば、構築を検討する価値のある領域です。方式選定そのものは動画配信システムとは、製品ごとの守備範囲は動画配信システムの比較で整理しています。

動画配信システムの構築で最初に決める配信方式と処理パイプラインの全体像

実装に入る前に範囲を確定させます。ここが曖昧なまま着手すると、ライブ配信の要件が後から差し込まれて作り直しになります。

ライブ配信とVODで構築の難易度が変わる理由と、本記事が扱う範囲

VODはあらかじめ動画ファイルを受け取って時間をかけて変換し、できあがったものを配るため、変換が多少遅れても視聴体験に響きません。ライブは映像が到着した端から数秒以内に変換して配る必要があり、エンコーダの常時稼働や取り込み経路の冗長化といった別種の設計が加わります。つまりVODは非同期バッチ処理の設計問題、ライブはリアルタイム処理と可用性の設計問題です。この記事はVODを軸に扱い、ライブの取り込みとエンコード構成はAWSとOBSによるライブストリーミングの解説、1秒未満の双方向配信が要る場合はWebRTCベースの100ms.liveの解説、配信プロトコルの前提はストリーミングとはで補完してください。

動画配信システムを構成する5つの処理と、それぞれの責務の分け方

第1段は取り込みで、管理画面やAPIから元動画（マスターファイル）を受け取りオブジェクトストレージへ保存する層。第2段はトランスコード、第3段はパッケージング、第4段はCDN配信、第5段は視聴権限の制御です。この分割で効くのは、第2段と第3段を同じジョブで完結させる一方、第5段を配信経路の外側に置く点にあります。視聴権限の判定は会員管理や購入履歴を持つアプリケーションの責務であり、CDNは署名が正しいかだけを見る役割です。

アップロードからトランスコードまでを組む変換パイプラインの設計

変換段は動画配信システムで最もコストと時間を食う部分です。ここを同期処理で組むと、アップロード直後のリクエストが数分間ぶら下がってタイムアウトで壊れます。

アップロードを受けてトランスコードジョブを起動する非同期処理

基本形は、アップロード完了をトリガーにジョブを非同期で起動する流れです。管理画面からは署名付きURLでオブジェクトストレージへ直接アップロードさせ、アプリケーションサーバーに動画本体を通しません。保存完了のイベントを受けて変換ジョブを登録し、ジョブIDを動画レコードに紐づけて状態を「変換中」にします。完了通知を受け取ったら出力先のマニフェストURLを保存し、状態を「公開可能」へ進める流れです。

ビットレートラダーの設計指針と、解像度ごとの出力本数の決め方

アダプティブ配信は、同じ動画を複数の画質で用意し、プレイヤーが回線状況に応じて切り替える仕組みです。この画質の階段をビットレートラダーと呼び、設計の勘所は「多ければ良い」ではないことにあります。1本増やすたびに変換コスト・ストレージ・パッケージング時間が線形に伸びるためです。社内研修やeラーニングのようにPCとタブレット中心で回線が安定している用途なら、1080pと720pと480pの3段で足ります。モバイル回線からの視聴が多いなら、360pや240pの低段を足して細い回線での再生開始を担保する形です。

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
720p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480
480p.m3u8

上はマスタープレイリストの最小構成です。BANDWIDTHには実測の平均ではなくピーク相当を書くのが約束事で、ここを実態より低く申告すると、プレイヤーが細い回線でも高画質を選んでしまい再生が途切れます。

トランスコード費用が跳ねる条件と、コーデック選定で効く判断軸

AWS Elemental MediaConvertの場合、課金は出力の正規化時間（分）単位で、解像度・フレームレート・品質階層に応じた乗数がかかり、最小課金単位は10秒です（2026年7月時点の公式料金ページ）。ここで効くのが階層の区分で、AVC（H.264）などのシンプルなWeb配信向け出力はBasic階層に収まる一方、HEVCやAV1、そしてDRMを使う出力はProfessional階層となり単価の乗数が上がります。つまり「HEVCで転送量を減らす」「DRMを入れておく」という判断は、変換コスト側の単価を押し上げる判断でもあるわけです。視聴回数が少なく本数が多いライブラリ型ならAVCで変換費を抑え、少数のコンテンツを大量に視聴される用途ならHEVCで転送量を削る方向で見積もります。変換費と転送量を合算した月次の総額は、動画配信システムの費用を視聴時間から逆算した記事で実額を試算しています。

HLSとMPEG-DASHのパッケージング設計とCMAFで出力を一本化する方法

変換した映像は、そのままでは配信できません。数秒単位のセグメントに切り、どのセグメントをどの順で取りに行くかを書いたマニフェストを添えて、はじめて再生できる状態になります。

HLSとMPEG-DASHの構造の違いと、プレイヤー対応から決める選択

HLSはAppleが策定したHTTPベースの配信方式で、拡張子m3u8のプレイリストとセグメント群で構成されます。MPEG-DASHは国際標準として策定された方式で、MPDというXML形式のマニフェストを使う点が違いです。選択を決めるのは再生環境で、iOSのSafariはHLSしか再生できない制約があり、モバイル対応が要件に入るならHLSは外せません。ただしDRMを絡めると、後述のとおりコンテナごとに使えるDRM方式が変わるため、対応端末の一覧を先に確定させてください。

CMAFで配信ファイルを一本化するとストレージと転送量が減る理由

HLS用のセグメント（MPEG-2 TS）とDASH用のセグメント（断片化MP4）を別々に生成すると、同じ映像を2セット持つことになり、ストレージも変換時間も倍になります。これを解くのがCMAFです。CMAFは断片化MP4を共通のセグメント形式として使い、HLSのm3u8とDASHのMPDという2種類のマニフェストから同じセグメント群を参照させます。なおVODでは遅延の概念がないため、セグメント長は4〜6秒程度でキャッシュ効率を優先して構いません。

CDN配信とキャッシュ設計で同時視聴数と転送コストを制御する構成

CDNを使わない選択は、社内の閉じたネットワークを除いてほぼありません。オリジンの帯域は有限で、同時視聴が増えた瞬間に頭打ちになるためです。

オリジンとCDNの役割分担と、マニフェストとセグメントのキャッシュ差

オリジンはオブジェクトストレージ、その前段にCDNを置き、視聴者はCDNのドメインだけを見る構成が標準形です。VODはセグメントもマニフェストも内容が変わらないため、どちらも長期キャッシュで構いません。ライブの場合はマニフェストがセグメント追加のたびに書き換わるため、マニフェストは数秒、セグメントは長期という非対称な設定にします。この非対称を忘れると、ライブで映像が止まる、あるいはセグメントがキャッシュされず転送費が膨らむ事故が起きます。

同時視聴数から逆算する必要帯域と、転送量課金の見積もりの立て方

必要帯域の見積もりは単純な掛け算で、同時視聴数×視聴者あたりの平均ビットレートがピーク時に必要な帯域になります。1080pで5Mbpsのラダー上位を1,000人が同時に見れば5Gbpsが要る計算で、視聴者の多くが720p（2.8Mbps）に落ち着くなら実効は3Gbps程度に収まる見立てです。転送量課金は平均ビットレート×平均視聴時間×視聴回数で概算し、2.8Mbpsを30分見れば1回あたり約630MB、月10,000回なら約6.3TBになります。初期構築費ではなく視聴が増えるほど線形に伸びる転送量が支配的なコストであり、ラダー設計が直接コストに効きます。

署名付きURLと署名付きCookieで視聴権限を制御する実装パターン

有料コンテンツや社内限定の映像を配るなら、CDNのURLを知っている人が誰でも見られる状態は許容できません。ここで使うのが署名による一時的なアクセス許可です。

署名付きURLと署名付きCookieの違いと、HLSで後者が向く理由

署名付きURLは、URLごとに有効期限と署名を埋め込み、その1ファイルへのアクセスだけを許可する方式です。署名付きCookieは、視聴者のブラウザに署名済みのCookieを持たせ、指定した範囲のファイル群へのアクセスをまとめて許可します。CloudFrontの署名付きCookieは3つのSet-Cookieヘッダーを視聴者へ返す形で成立し、限定コンテンツを要求する前に付与しておく必要があります（AWS公式ドキュメント・2026年7月時点）。HLS配信では後者が向きます。30分の動画を6秒セグメントで切れば300本になり、署名付きURLではマニフェスト内の全行に署名を埋め込み、期限のたびに作り直す羽目になるためです。

Cannedポリシーとカスタムポリシーの使い分けと有効期限の設計

CloudFrontの署名では、cannedポリシーとcustomポリシーを選べます。cannedは終了日時だけを指定する簡易版で、Resourceにワイルドカードを使った複数ファイルへの再利用、開始日時の指定、IPアドレス制限はできません。customはワイルドカードによる範囲指定、アクセス開始日時、視聴者のIPアドレス制限を任意で指定できます（AWS公式ドキュメント・2026年7月時点）。HLSのようにパス配下を丸ごと許可したいなら、必然的にcustomポリシー側です。有効期限には落とし穴があり、CloudFrontは期限をHTTPリクエストの時点で判定するため、視聴開始時に有効でも途中で期限が切れると以降のセグメント取得が失敗します。想定視聴時間より十分長い期限を置くか、再生中にCookieを再発行して延長してください。

視聴権限をアプリ側でどう判定するか、認証と署名発行をつなぐ設計

署名の発行は、配信基盤ではなくアプリケーション側の責務にします。視聴者がログインして視聴ページを開き、アプリが会員状態や購入履歴から視聴可否を判定し、可であれば署名済みCookieを発行してプレイヤーにマニフェストのURLを渡す流れです。この構成なら、プラン変更・期間限定公開・同時視聴端末数の制限といった要件が、すべて署名を発行するかどうかの判定に閉じます。秘密鍵はアプリ側で保持し、CDNには公開鍵を信頼済みキーグループとして登録する形です。AWSは悪用防止として、Cookieのドメインを最も限定的な値にすること、ExpiresとMax-Ageを付けずセッションCookieにすること、Secure属性を付けることを推奨しています。

SPEKE経由のマルチDRMを組む条件と暗号化だけで足りる場面の境界

DRMは動画配信システムの構築で最も判断を誤りやすい領域です。入れれば安心という話ではなく、入れた瞬間にコストと実装量が段違いに増えます。

AES-128の暗号化とDRMは何が違うのか、保護レベルの階層を整理

HLSにはAES-128でセグメントを暗号化する仕組みがあり、マニフェストに鍵の取得先URLを書いておくと、プレイヤーが鍵を取りに行って復号します。ただし鍵はプレイヤーが取得できる形で渡るため、意図的に取り出そうとする相手には抗しきれません。DRMでは鍵が端末側の保護された領域へ渡り、復号と再生が保護された経路の中で行われるため、平文の映像を取り出す難易度が桁違いに上がります。整理すると、URLを推測されないだけで良いなら署名付きアクセス、社外流出を実務的に抑えたいならAES-128暗号化、権利者から保護レベルを指定されるならDRM、という三層構造です。収益モデルで求められる保護レベルは変わるため、OTTとSVOD・AVOD・TVODの整理と突き合わせると判断しやすくなります。

SPEKEで鍵プロバイダをつなぐ構成と、コンテナ別の対応の制約

SPEKE（Secure Packager and Encoder Key Exchange）は、DRMシステムがトランスコーダやパッケージャへ暗号鍵を提供し、プレイヤーへライセンスを配る役割分担を標準化したAPI仕様です。つまり自社で鍵管理基盤を作るのではなく、v1.0とv2.0の両方に対応するMediaConvertから、契約したマルチDRMベンダーのキープロバイダへつなぐのが実装形です。ここで制約になるのがコンテナとDRM方式の対応関係で、公式ドキュメントによればSPEKE v1.0はDASHがWidevineとPlayReadyのみ、Apple HLSがFairPlayのみ、CMAFは3方式すべてに対応します。v2.0ではApple HLSでもWidevineとPlayReadyが使えるため、全端末を保護したいならCMAF＋v2.0が最も出力構成を絞れます。

マルチDRMの導入コストと、それが実際に必要になる案件の条件

マルチDRMを入れると、コストは3方向に増えます。1つ目はDRMベンダーへのライセンス費用で、月額または視聴回数課金が乗る形です。2つ目は変換コストで、MediaConvertではDRM対応がProfessional階層の機能に当たるため出力単価の乗数が上がります。3つ目は実装と検証で、iOS・Android・各ブラウザの実機確認に工数が発生し、OSの更新のたびに再検証が要ります。この負担に見合うのは、権利者や取引先からDRM保護を契約条件として指定される案件、有料配信で流出が直接売上を毀損する案件です。

自社構築とASPを分ける判断軸と、構築を見送るべき場面の見極め方

構築するかどうかの判断は、技術的に作れるかではなく作る価値があるかで決めるべきです。作れる構成は標準化されており、差がつくのは運用コストと自由度のバランスになります。

自社構築が見合う条件と、ASPで足りる場面の具体的な線引きの基準

自社構築が見合うのは次のいずれかに該当する場合です。第一に、既存の会員基盤・購買履歴・学習管理と視聴権限を密結合させたい場合で、ASPの外部連携APIでは組めない粒度の権限制御（部署単位、契約プラン単位、視聴期限の動的変更など）が要るなら構築側の自由度が効きます。第二に、視聴規模が大きくASPの従量課金が構築費と運用費の合計を上回る場合で、転送量が月数十TB規模になると単価差が無視できない金額になります。第三に、DRMや配信ドメインなど事業要件で構成を指定される場合です。逆にASPで足りるのは、視聴者が数百人規模、権限が「ログインした会員なら見られる」程度で、映像に権利者要求がない場合になります。

内製で組むか受託開発に出すかを分ける、体制と運用負荷の見立て

内製が現実的なのは、クラウドインフラの設計と運用を継続的に担える人員が社内にいて、かつ動画特有の領域（コーデック、ラダー設計、プレイヤー実装、DRM検証）を学習する時間を確保できる場合です。逆に、期日までに動く基盤が要る場合やDRMまで含めた保護要件がある場合は、配信基盤の構築経験がある体制に任せ、自社は権限設計とコンテンツ運用に集中するほうが総コストで有利です。当社では会員連携や権限制御まで含めた動画配信システム開発を受託しており、ASPで足りる範囲か構築が必要かの切り分けから相談を受けています。

構築後に効いてくる運用設計と、見落とされやすい運用コストの要因

構築の見積もりで抜けやすいのが、公開後に継続的に発生する作業です。元動画の保管とライフサイクル管理（マスターを消すと再変換ができなくなる）、変換失敗の検知と再実行、プレイヤーやブラウザの更新に伴う再生確認、署名鍵のローテーションが代表例になります。もう1つ見落とされるのが、コンテンツ本数の増加に伴うストレージの伸びです。ラダー3段＋マスターを保持すると元動画の2倍前後の容量を持つことになり、本数が積み上がるほど効いてきます。古いコンテンツを低頻度アクセス向けの保管階層へ移す運用を設計に入れてください。

よくある質問

動画配信システムの構築にはどれくらいの期間がかかりますか？

アップロード・変換・CDN配信・署名付きの視聴制御までの基本形であれば、クラウドのマネージドサービスを組み合わせて1〜2か月程度が一つの目安です。会員基盤との連携、管理画面、視聴ログの集計が加わると3か月前後になります。マルチDRMを入れる場合はベンダー選定と実機検証に時間が乗るため、さらに1〜2か月を見込むと安全です。

HLSとMPEG-DASHはどちらか一方だけで足りますか？

再生環境とDRMの有無で決まります。iOSのSafariでの再生が要件に入るならHLSは外せないため、社内のWindows端末だけといった環境を除き、HLSは基本的に必要です。DRMを入れない、あるいはAES-128暗号化までならHLS単独で組んで問題ありません。全端末をDRMで保護する場合は、CMAFでセグメントを共通化しつつ2種類のマニフェストを出す構成が現実的になります。

DRMは必ず入れる必要がありますか？

要りません。権利者から保護レベルを指定されている、有料コンテンツで流出が売上を直接毀損する、機密映像を外部へ配る、といった条件に当てはまらなければ、署名付きアクセスとAES-128暗号化で実務上は足ります。DRMはライセンス費用・変換単価・端末検証工数の3方向でコストが増えるため、必要性が確定してから入れる順序が妥当です。後からDRMを足せるようCMAFでパッケージングしておくと、移行の手戻りが小さくなります。

自前のサーバーで配信すればCDN費用を抑えられますか？

視聴規模が小さいうちは成立しますが、規模が伸びると逆転します。オリジン1台では同時視聴数が帯域の上限に直撃する形です。帯域を確保するために回線とサーバーを増やすと固定費が積み上がり、さらに冗長化と監視の運用が乗る形です。CDNは従量課金ですが、ピークに合わせた設備を持たずに済む点が実質的な価値になります。

動画の無断ダウンロードやコピーは完全に防げますか？

完全には防げません。DRMを入れても、画面を別の機器で撮影する経路までは塞げないためです。現実的な目標は、攻撃者の手間を得られる利益に見合わない水準まで引き上げることに置きます。署名付きアクセスでURL共有を無効化し、暗号化で単純な保存を防ぎ、DRMで平文の抽出難度を上げる。加えて視聴者IDを映像に重ねる可視ウォーターマークを入れると、流出時の追跡と抑止に効きます。

関連記事

• 動画配信システムとは？仕組み・配信方式と、ASP/自社開発の選び方を受託開発目線で解説：配信方式の全体像とASPと自社開発の判断軸を確認できます。
• 動画配信システムの比較｜同時視聴数・DRM・課金・LMS連携で選ぶ判断軸：主要な製品の守備範囲を保護レベルの軸で比較できます。
• ストリーミングとは？仕組み・種類・配信を支える技術をわかりやすく解説：前提になる配信プロトコルとバッファリングの基礎を整理できます。
• AWSとOBSによるライブストリーミングの概要と基本知識：ライブ配信での取り込みとエンコード構成を確認できます。
• 100ms.liveとは？WebRTCベースのライブ動画配信プラットフォームの概要と特徴：1秒未満の低遅延が要件になる場合の選択肢を確認できます。
• OTTとは？意味・種類（SVOD/AVOD/TVOD）と代表的なサービス・VODとの違い：収益モデル別に求められる保護レベルを整理できます。