2026.08.12 インフラ

ライブ配信システムの構築｜RTMP/SRT取り込みからLL-HLS配信・冗長化・費用設計まで

ライブ配信システムの構築は、映像を送る仕組みを作る作業ではなく、遅延と可用性と費用のどれをどこまで諦めるかを決める作業です。配信ソフトからサーバーへ映像を送るだけなら半日で動くのに設計が難しくなるのは、開始時刻に1万人が同時にアクセスしても止まらず、現場の回線が切れても配信が続く基盤にしようとした瞬間に判断が増えるためです。この記事では、許容遅延と同時視聴数と配信頻度から構成を逆算する順序、RTMPとSRTの取り込み設計、Amazon IVSと MediaLive の分岐、LL-HLSのセグメント設計、そして稼働時間課金の構造までを実装粒度で整理します。VOD側の設計は動画配信システムの構築｜トランスコードからHLS配信・視聴制御・DRMまで実装解説に譲り、ここでは一対多のライブ配信だけを扱います。

まとめ：遅延目標と配信頻度で決まるライブ配信基盤の構成

ライブ配信システムの構成は、許容遅延をいくつに置くかでほぼ決まります。AWS公式ドキュメントでは、従来型のOTT配信で遅延が最大30秒に達しうるのに対し、Amazon IVSのチャンネルは5秒未満、IVSステージのリアルタイム配信は300ミリ秒未満と示されています（2026年8月時点）。この階層は、そのまま実装量と単価の階層でもあります。要件を「なるべく低遅延で」とだけ書いて着手すると、後から作り直しになります。

次に効くのが配信頻度です。エンコーダ系のサービスは、チャネルが起動している限り課金されます。AWS公式のMediaLive料金ページには、入力がコンテンツを受信していなくても、チャネルが稼働している限りコストが発生すると明記されています。週1回2時間のイベントのために常時チャネルを立てたままにすると、実配信2時間ぶんの単価で168時間ぶんの請求が来る計算です。断続イベントか常時放送かで、選ぶべきサービスが逆転します。

そして見落とされるのが取り込み側の冗長化です。クラウド側をどれだけ二重化しても、配信現場のエンコーダと回線が1系統のままなら、可用性はその1系統の信頼性で頭打ちになります。MediaLiveのSTANDARDクラスは異なるAZで2つの処理パイプラインを走らせますが、その2本に映像を届けるのは配信現場の責任です。冗長化の投資は、クラウドより先に現場側から始めてください。

ライブ配信システムの構築で最初に確定させる3つの数値と対象範囲

設計に入る前に、要件を3つの数値へ落とします。この3つが決まっていれば構成はほぼ一意に決まり、決まっていなければ何を選んでも後で揉めます。

許容遅延の目標値から配信方式を逆算する4段階の遅延の階層と条件

遅延は「短いほどよい」ではなく、業務要件から上限を決める数値です。撮影から視聴者の画面に映るまでの遅れをどこまで許せるかで、方式が4段階に分かれます。

  • 20秒から30秒：通常のHLS配信。セグメントを長めに切り、CDNのキャッシュ効率と安定性を優先する構成。講演の配信やアーカイブ前提の中継はここで足ります
  • 3秒から8秒：LL-HLS（低遅延HLS）。部分セグメントを使って再生開始までの待ちを削る構成。視聴者のコメントに配信者が反応する程度の即時性はここで成立します
  • 5秒未満：Amazon IVSのチャンネル。マネージドで低遅延の配信網まで込みで提供される階層です
  • 300ミリ秒未満：IVSステージやWebRTCベースの構成。会話が成立する水準の遅延で、双方向のやり取りが要件に入る場合の選択肢になります

判断で効くのは、視聴者が配信者に反応を返す経路があるかどうかです。一方向に流すだけなら20秒でも業務は回ります。投票やコメントに配信者が応じるなら数秒台、双方向に話すなら1秒を切る階層へ移る形です。双方向とSFUの設計はWebRTCとは？P2Pの仕組み・ICE/STUN/TURNからSFU選定・実装・運用判断までで扱っているため、そちらへ委譲してください。

同時視聴数から必要帯域とラダーの本数を決める見積もりの立て方

必要帯域は単純な掛け算で、ピーク同時視聴数×視聴者あたりの平均ビットレートになります。720p相当の2.8Mbpsを5,000人が同時に見れば14Gbpsで、この規模はCDNなしでは成立しません。ライブはVODと違って視聴が開始時刻に集中するため、平均ではなくピークで設計してください。

ビットレートラダーの本数は、増やすほど画質の追従は良くなりますが、エンコーダ側の出力単価が本数ぶん線形に増えます。ライブでは変換が配信時間ぶん走り続けるためです。モバイル視聴が主体でないなら1080pと720pと480pの3本、社内向けで回線が安定しているなら720pと480pの2本まで削れます。

常時放送か断続イベントかという配信頻度が費用構造を決める理由

3つ目の数値が、月あたりの実配信時間です。AWS公式のMediaLive料金ページによれば、12か月契約の予約オプションは月180時間を超えて放送されるチャネルで効き、最大75%の割引が適用されます（2026年8月時点）。月180時間に届かない断続的なイベント配信では、この予約が空振りする形です。実配信していない時間の課金をどう避けるかが設計の中心になり、具体的な試算は後半のコスト章で行います。

RTMPとSRTの取り込み経路の設計と、配信現場側を冗長化する手順

取り込み（インジェスト）は、配信現場からクラウドへ映像を届ける区間です。唯一やり直しの効かない区間で、届かなかった映像はどんな仕組みでも復元できません。

RTMPとRTMPS、SRTの違いと回線品質から選び分ける判断軸

Amazon IVSの公式ドキュメントでは、取り込みプロトコルとしてRTMP、そのTLS版であるRTMPS、そしてSRTの3種が挙げられています。SRTについては、不安定なネットワーク上での配信を改善し、ジッタ・パケットロス・帯域変動から保護する目的で設計されたオープンソースのプロトコルと説明されています（2026年8月時点）。

選び分けの軸は回線の素性です。データセンターや専用線から送るならRTMPSで十分機能します。会場のWi-Fiやモバイル回線、長距離送出のように損失と揺らぎが避けられない経路では、SRTの再送と受信バッファが効きます。SRTはバッファぶんの遅延を先に払って映像の破綻を防ぐ、遅延と堅牢性を交換するプロトコルです。配信ソフト側の画面設定と接続手順はAWSとOBSによるライブストリーミングの概要と基本知識にまとめてあります。

エンコーダと回線を二重化する、取り込み側の冗長構成の組み立て方

MediaLiveのSTANDARDクラスは、異なるAZで2つの処理パイプラインを実行します。公式料金ページには、同一リージョンでシングルパイプラインを2つ運用するより低コストになるとも記載されています。ただしこの2本のパイプラインは、それぞれに映像が届いて初めて意味を持つ構成です。現場のエンコーダ1台から1本しか送っていなければ、AZ障害には耐えてもエンコーダの停止には耐えられません。

現場側で二重化すべきものは3つあります。エンコーダまたは配信PCを2台立てて同じ映像を別パイプラインへ送ること、上り回線を固定回線とモバイル回線のように系統の違う2本にすること、電源系統を分けることです。費用対効果が最も高いのは回線で、配信事故の原因として上り帯域の瞬断が突出して多いためです。

切り替えの設計も先に決めてください。2系統を常時送って受信側で生きているほうを使うか、主系が落ちたら手動で副系へ切り替えるかで、必要な帯域も要員も変わります。無人で回すなら常時2系統送出を選んでください。

Amazon IVSとMediaLive構成の分岐点と、OSS自前サーバーの範囲

クラウド側の処理は、マネージドサービスに任せるか、エンコーダとパッケージャとCDNを自分で組み合わせるかの二択です。作れるかどうかではなく、運用の自由度と単価のどちらを取るかの判断になります。

Amazon IVSのチャンネルタイプで足りる条件と料金の考え方

Amazon IVSは、取り込みからエンコード、配信網、プレイヤーSDKまでを一体で提供します。公式料金ページによれば、ライブ動画入力は標準チャンネルが1時間2.00 USD、アドバンストHDが0.85 USD、アドバンストSDが0.50 USD、ベーシックが0.20 USDで、標準のマルチトラック配信は0.50 USDです。視聴側の出力は北米でHDが1時間0.0720 USDから0.0480 USD、フルHDがその倍という階層制で、使用量が増えるほど単価が下がります（2026年8月時点）。

IVSで足りるのは、遅延5秒未満で足り、配信網やDRMの構成をこちら側で指定する必要がなく、配信が断続的な場合です。入力時間に対する課金のため、配信していない時間にコストが積み上がりません。イベント型で構成を一から組む価値があるケースは、実際には多くありません。

MediaLiveとMediaPackageで自前構成を組むべき3つの条件

自前構成へ進む理由は3つに絞られます。第一に、出力プロファイルやパッケージング形式を細かく指定する必要がある場合です。独自のマニフェスト加工や既存の配信網への接続といった要件は、マネージドの枠に収まりません。第二に、既存のAWS環境と権限・監視・ログを同じ基盤に載せたい場合です。第三に、月あたりの配信時間が長く、予約料金で単価を落とせる場合になります。

米国東部のオンデマンド料金では、HD 1080p のHEVC入力（20Mbps）が1時間0.588 USD、HD 1080p のAVC出力（5Mbps・30fps）が0.702 USD、SD 576p のAVC出力（1.2Mbps・30fps）が0.354 USDです（2026年8月時点）。ラダーを3本組めば出力だけで1時間あたり1.5 USD前後になり、STANDARDクラスで2パイプラインを走らせればおおむねその倍を見込む形になります。

SRSやnginx-rtmpで自前サーバーを立てる選択が成立する範囲

SRSやnginx-rtmp-moduleを使えば、EC2やオンプレのサーバー1台でRTMP受けからHLS出力までを組めます。ライセンス費用はかからず、サーバー代だけで動きます。検索で上位に出てくる構築記事の多くはこの構成です。

成立する範囲は限定的で、同時視聴が数十人規模、視聴者が社内など閉じたネットワークにいて、配信が止まっても業務が停止しない場合に限られます。オリジン1台の帯域が同時視聴数の上限に直撃し、その1台が落ちれば配信も落ちるためです。前段にCDNを置けば帯域の問題は解けますが、エンコード処理の冗長化と障害時の自動復旧を自前で組む工数が残ります。検証環境や社内配信の受け皿としては妥当で、対外的なイベント配信の本番系としては勧められません。

SRSやnginx-rtmp-module以外の選択肢も含めた製品選定は、動画配信システムのオープンソース8製品のライセンス条件と自前運用の限界を判定した記事で、Ant Media ServerやMediaMTXまで含めた実測版数とAGPL条項の扱いを整理しています。

LL-HLSのセグメント設計と、CDNキャッシュを非対称に設定する理由

配信側では、映像を細切れにしてマニフェストと一緒に配ります。ライブではこのマニフェストが数秒ごとに書き換わるため、VODと同じ設定をそのまま持ち込むと事故ります。

セグメント長と部分セグメントで遅延と安定性の折り合いをつける

HLSの遅延は、おおむねセグメント長の3倍前後に落ち着きます。プレイヤーが再生を始める前に複数のセグメントを溜めるためで、6秒セグメントなら20秒前後、2秒なら7秒前後が目安です。セグメントを短くするほど遅延は縮みますが、リクエスト数が反比例して増え、CDNとエンコーダの負荷が上がります。

LL-HLSは、セグメントを完成前に部分単位で配ることでこの折り合いを変えます。セグメント長は従来どおり保ちつつ、生成途中の部分セグメントを先に配って再生開始を早める仕組みです。プレイヤー側の対応が前提になるため、視聴環境を先に確定させてから採否を決めてください。ブラウザとバージョンを揃えられる社内配信なら導入しやすく、不特定多数が対象なら通常のHLSへ落とすほうが安定します。

マニフェストは短命、セグメントは長寿というキャッシュの非対称

ライブのマニフェストは、セグメントが1本追加されるたびに内容が変わります。ここに長いキャッシュを設定すると、視聴者は古いマニフェストを読み続け、映像が途中で止まったように見えます。一方でセグメント自体は一度生成されたら不変で、こちらに短いキャッシュを設定すると同じファイルを何度もオリジンへ取りに行き、転送費とオリジン負荷が跳ね上がる形です。

設定はマニフェストが1秒から数秒、セグメントが数時間以上という非対称にしてください。この非対称を揃えてしまう設定ミスは、ライブ配信で最も頻出する事故のひとつです。VOD側は両方とも長期キャッシュで構わないため、同じCDNで混在させるならパスでビヘイビアを分けてください。

稼働時間課金の落とし穴と、イベント型と常時型で逆転する総額の構造

ライブ配信の費用は、構築費よりも運用時の従量課金が支配的です。そして従量課金の読み違いは、ほぼすべてが稼働時間の扱いから生まれます。

チャネルが起動しているだけで課金される、稼働時間課金という性質

AWS公式のMediaLive料金ページには、入力がコンテンツを受信していなくても、出力がコンテンツを生成していなくても、チャネルが稼働している限りコストが発生すると明記されています。各実行リソースの所要時間は最小10分で、毎分ごとの切り上げです（2026年8月時点）。

この性質が効くのは、設定作業のためにチャネルを立てたまま週末を挟んだ場合や、イベント終了後に停止を忘れた場合です。ラダー3本のSTANDARDチャネルを1時間3 USD前後と見れば、金曜夕方に停止し忘れると月曜朝までに200 USDを超えます。対策は運用ではなく仕組み側に置いてください。配信予定をトリガーに起動し終了イベントで停止する自動化を最初のスコープへ入れ、稼働時間の閾値でアラートを出す形が確実です。

3時間のイベントを1,000人が同時視聴する場合の実額を試算する

公表単価から、単発イベントの実額を出してみます。3時間のイベントをHD画質で1,000人が通しで視聴する条件です。IVSの標準チャンネルなら、入力が3時間×2.00 USDで6.00 USD、出力が3,000視聴時間×0.0720 USDで216 USD、合わせておよそ222 USDになります。

MediaLive構成では、入力と3本のラダー出力でSTANDARDならおおむね1時間3 USD前後、3時間で10 USD前後です。エンコード側だけを見ればIVSより安く見えますが、視聴側の転送量が別途かかります。2.8Mbpsを1時間視聴すると約1.26GBで、3,000視聴時間なら約3.7TBのCDN転送が乗る計算です。ここで分岐点が出ます。IVSのHD出力0.0720 USDを1.26GBで割ると1GBあたり約0.057 USDとなり、自社のCDN実効単価がこれを下回れば自前構成が視聴側で有利、上回ればIVSが有利という読み方になります。

単発イベントでは、この差額よりもチャネル構築・冗長化・監視の工数のほうが大きくなります。年に数回の配信のために自前構成を組む判断は、金額面では正当化しにくい領域です。

予約料金とマルチトラック配信で単価が下がる損益分岐点の見極め方

構造が逆転するのは常時放送です。24時間×30日で720時間を配信する場合、IVSの標準チャンネルは入力だけで1,440 USD（アドバンストSDなら360 USD前後）になります。MediaLive構成では、月180時間を超えるチャネルに12か月契約の予約オプションが効き、最大75%の割引が適用されます。

つまり損益分岐は月180時間付近です。これを超える常時放送型なら予約を効かせた自前構成、下回る断続イベント型ならIVS、というのが単価だけで見た線引きになります。IVS側にも標準チャンネルのマルチトラック配信という単価0.50 USDの選択肢があるため、ラダーを複数本必要とするなら比較してから決めてください。視聴時間から総額を逆算する手順は動画配信システムの費用｜視聴時間から逆算するASP月額と自社構築の実額で扱っています。

自社構築を見送る判断と、外部サービスで足りる規模と要件の線引き

ここまでの構成はすべて作れますが、作るべきかは別の問いです。ライブ配信は、外部サービスの完成度が高い領域でもあります。

YouTube LiveやZoomで足りる条件と、構築が要る境界の引き方

次の条件をすべて満たすなら、基盤を組む必要はありません。視聴者の識別が「URLを知っている人」か「招待した人」の粒度で足りること、プレイヤーの挙動を自社仕様にする要件がないこと、視聴ログを自社の分析基盤へ取り込む必要がないこと、配信先の規約と広告表示を受け入れられることです。

逆に境界を越えるのは、会員基盤や購買履歴と視聴権限を結びつける場合、視聴データを自社プロダクトの一部として扱う場合、配信ドメインや保護要件を取引先から指定される場合です。この3つのいずれかに該当したとき、初めて構築の検討に入ってください。方式選定の全体像は動画配信システムとは？仕組み・配信方式と、ASP/自社開発の選び方で整理しています。

自社構築でしか満たせない要件と、受託に出すべき工程の切り分け

自社に残すべきは、遅延の許容値、ピーク同時視聴数の見立て、配信頻度、そして視聴権限のルールです。この4つは事業側にしか決められません。外部の技術者は、そのイベントに何人来るのか、遅延が何秒まで許されるのかを知る立場にないためです。

一方、取り込み経路の冗長化、エンコーダとパッケージャの構成、CDNのビヘイビア設計、障害時の切り替え運用は外へ出して構いません。ライブ配信は失敗が本番中にしか現れない領域で、故障パターンを事前に潰した経験の有無が結果を分けます。取り込みの二重化から視聴権限の制御までを含めた動画配信システム開発（ライブ配信基盤の設計・構築）を当社で請け負っており、外部サービスで足りるかの切り分けから相談を受けています。

よくある質問

ライブ配信基盤の相談で実際に聞かれることの多い5つに答えます。

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

マネージドサービスで取り込みから配信と視聴権限の制御までを組む基本形なら、1か月から2か月程度が目安になります。取り込みの二重化、会員基盤との連携、視聴ログの集計を加えると3か月前後です。自前でエンコーダとパッケージャを組む構成は障害時の切り替え検証に時間がかかるため、さらに1か月ほど余裕を見てください。

RTMPとSRTはどちらを選べばよいですか？

回線の素性で決まります。データセンターや専用線から送るならRTMPSで足り、対応する機材とサービスの選択肢も広く取れる領域です。会場のWi-Fi、モバイル回線、長距離送出のように損失や揺らぎが避けられない経路ではSRTが効きます。AWS公式ドキュメントでもSRTは不安定なネットワークでの配信を改善する目的の設計と説明されており、受信バッファぶんの遅延を払って映像の破綻を防ぐプロトコルだと理解してください。

ライブ配信で遅延を1秒以下にすることはできますか？

できますが、HLS系の配信方式では届きません。AWS公式ドキュメントによれば、IVSステージのリアルタイム配信は300ミリ秒未満、IVSチャンネルは5秒未満です。1秒を切る要件はWebRTC系が前提になり、視聴者数のスケールとコストの性質がHLS系とは別物です。会話が成立する双方向性が本当に要るのか、数秒台の即時性で足りるのかを先に確認したほうが、総コストは下がります。

ライブ配信の費用で一番見落とされやすいものは何ですか？

配信していない時間の課金です。MediaLiveのようなエンコーダ系サービスは、公式料金ページに明記されているとおり、入力が来ていなくてもチャネルが稼働している限り課金されます。検証でチャネルを立てたまま放置すると、実配信ゼロで数百USDが積み上がる形です。配信予定に連動した起動と停止の自動化と稼働時間の閾値アラートを、運用ルールではなく仕組みとして最初から入れてください。

オンプレミスのサーバーでライブ配信基盤を組むことはできますか？

組めます。SRSやnginx-rtmp-moduleを使えば、RTMP受けからHLS出力までをサーバー1台で構成できます。成立するのは、同時視聴が数十人規模で視聴者が閉じたネットワークにおり、配信が止まっても業務が停止しない条件のときです。対外配信ではオリジン1台の帯域が同時視聴数の上限に直結し、CDNで帯域を解いてもエンコード側の冗長化を自前で作る工数が残ります。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る