動画配信システムのオープンソース8製品｜ライセンス条件と自前運用の限界を実装目線で判定

「動画配信システムをオープンソースで組みたい」という要望は、実際には2つの別作業に分かれます。既製のOSSプロダクトをそのまま立てるか、配信サーバーやトランスコーダを部品として組み合わせて自社基盤を作るか。前者はAnt Media ServerやOwncastのように数時間で配信画面まで到達できる代わりに、ライセンス条項と機能上限が最初から固定済みです。この記事では主要8製品のライセンス種別と最新版を2026年8月時点のリポジトリ実測で確認し、OSSで埋まる範囲、商用契約でしか越えられない領域、採用して失敗する条件を実装粒度で切り分けます。ASPと自社開発のどちらを選ぶかという上流の判断は動画配信システムとは？仕組み・配信方式と、ASP/自社開発の選び方で整理しています。

まとめ：OSSで埋まる配信機能と、商用契約でしか越えられない3つの壁

結論は明確です。映像の取り込み・トランスコード・HLS配信という配信のコア部分は、OSSで置き換えられます。SRSは6.0系でRTMPからWebRTC・SRT・HLS・MPEG-DASHまでを1プロセスで扱い、MediaMTXはLL-HLSとMedia-over-QUICまで含めてMITライセンスで公開済みです。ここに追加費用は発生しません。

越えられない壁は3つあります。WidevineやPlayReadyのマルチDRM、数千人規模の同時視聴に耐えるCDN、そして課金と視聴権限の連動です。DRMはライセンスサーバーの運営自体が各方式の提供元との契約を前提としており、OSSの暗号化機能で代替できる領域ではありません。同時視聴が数百を超えれば、自前サーバーの帯域ではなくCDNの転送量課金が主コストになります。

もう1つ、ライセンス条項が判断を左右します。PeerTubeとKalturaのサーバー実装、OvenMediaEngineはいずれもAGPL系です。改変してネットワーク越しにサービス提供する場合、改変部分のソース開示義務が生じ得ます。SaaSとして外部提供する計画がある場合、MITまたはApache 2.0の製品（SRS・MediaMTX・Ant Media Server Community Edition）に絞るほうが後工程が軽くなります。無料かどうかより、ライセンスの型で先に候補を切ってください。

動画配信システムのオープンソースが担う機能範囲と商用ASPとの境界

OSSを検討する前に、動画配信基盤が何の集合体なのかを分解します。ここを曖昧にしたまま製品名から入ると、「無料で全部できる」と「結局作り直し」のどちらかに振れます。

配信基盤の5機能のうちOSSで置き換えられる部分と外部依存が残る部分

動画配信システムは、取り込み・変換・配信・視聴制御・課金の5機能に分かれます。前3つはOSSで完結します。後2つが問題です。

• 取り込み（RTMP/SRT/ファイルアップロード）：OSSで完結する
• 変換（トランスコード・ビットレートラダー生成）：FFmpegを内蔵する製品で完結する
• 配信（HLS/LL-HLS/DASH/WebRTC）：OSSで完結するが、規模が大きくなるとCDNが必要になる
• 視聴制御（署名付きURL・DRM）：署名まではOSS、マルチDRMは商用契約が必要
• 課金・視聴権限（プラン管理・解約時の視聴停止）：ほぼ自社実装領域として残る

実務でまず押さえるべきは4つ目と5つ目です。「OSSで動画配信システムが作れるか」という問いは、正確には「視聴制御と課金を自分で書く余力があるか」という問いに置き換わります。社内研修用の動画共有なら5つ目は不要ですし、有料会員向け配信なら5つ目が開発量の半分近くを占めます。

単体プロダクト型とコンポーネント型で変わる選定時の評価軸の違い

OSSの動画配信ソフトウェアは、性質が2種類あります。PeerTube・Owncast・Kalturaは管理画面と視聴ページまで揃った単体プロダクト型で、そのまま動画サイトとして立ち上がります。SRS・MediaMTX・nginx-rtmp-moduleは配信サーバーだけを担うコンポーネント型で、視聴ページや会員管理は別に作る前提です。

評価軸が変わります。単体プロダクト型は「自社要件に合わない部分をどこまで改変できるか」で、コンポーネント型は「周辺をどれだけ自作するか」で工数が決まります。競合記事がOBS Studioのような配信ソフトを同じ一覧に並べているのは、この区別を落としているためです。OBS Studioは映像を送出する側のツールで、配信基盤の代替にはなりません。

主要8製品のライセンス種別と最新版を実測比較した実務選定マップ

2026年8月12日時点で各公式リポジトリを直接確認し、ライセンスファイルとタグを実測しました。ライセンス欄は自社サービスとして外部提供する場合の制約に直結します。

8製品のライセンス・最新版・得意領域を並べた実測比較表による判断軸

この表で最初に見るべきはライセンス列です。Ant Media ServerのCEはCommunity Editionを指します。AGPL系が3製品（OvenMediaEngine・PeerTube・Kaltura）を占めており、外部提供型のサービスを作る計画なら候補が5製品に減ります。SRSのv6.0-r0（v6.0.184）は2025年12月3日付です。MediaMTXの1.x系はLL-HLS・Media-over-QUICに対応します。次に見るのが更新日で、nginx-rtmp-moduleだけが5年以上動いていません。

ライブ取り込み系5製品の対応プロトコルと低遅延の実力を比較する選定基準

ライブ用途では、対応プロトコルの幅が構成の自由度になります。SRSは6.0系でRTMP・WebRTC・HLS・HTTP-FLV・SRT・MPEG-DASH・GB28181に対応し、H.264とH.265のほかAV1・VP9も扱います。MediaMTXはRTSP・RTMP・SRT・WebRTC・LL-HLSに加えMedia-over-QUICまで対応し、プロトコル変換の中継役として使いやすい構成です。OvenMediaEngineはLLHLSとWebRTC、SRTで1秒未満の配信を明示しています。

Ant Media Serverは1本のリポジトリでCommunity EditionとEnterprise Editionを分けており、無償のCommunity Editionから始めて要件が超えた段階で有償版へ移る導線になっています。nginx-rtmp-moduleはRTMPを受けてHLSを吐く（設定はhls on;）用途に限れば今でも動きますが、LL-HLSの記述はドキュメントに存在しません。

ここで扱うのは製品選定までです。取り込み経路の冗長化、LL-HLSのセグメント長設計、稼働時間課金を含む費用構造はライブ配信システムの構築｜RTMP/SRT取り込みからLL-HLS配信・冗長化・費用設計までで扱っています。

VOD・動画管理系3製品の運用前提と構築工数の見積もりを判断する基準

録画済み動画を配信する用途では、製品の性格が大きく違います。Owncastは単一バイナリで動き、配信ソフトからRTMPで送れば自前の配信ページがそのまま公開されます。v0.2.5（2026年4月11日）の時点でもチャット認証やファビコン設定といった小回りの改善が続いており、個人配信から社内配信までなら初期構築は最小です。

PeerTubeの最新版はv8.2.4（2026年8月4日）で、動画投稿サイトとして必要な機能はほぼ揃った状態です。ただしFediverse連携と分散配信を前提とした設計で、閉じた社内利用ではその設計思想の分だけ設定項目が増えます。Kalturaのサーバー実装はLMS連携や動画資産管理まで含む統合基盤で、機能量に比例して構築と維持の工数も跳ね上がる構造です。数日で立ち上がるOwncastと、専任担当を置く前提のKalturaを同じ「OSS」として比較すると見積もりを外します。

AGPLとApache 2.0で変わる商用利用の条件と受託納品時の確認事項

OSSの動画配信製品で実務上の事故が起きるのは、性能ではなくライセンスの読み違いです。ライセンス種別ごとの一般的な違いはオープンソースソフトウェア（OSS）とは｜ライセンス種別と実装現場での採用判断・リスク管理で整理しているため、ここでは動画配信で実際に問題化する条件だけを扱います。

AGPLv3のネットワーク越し利用条項が自社サービスに及ぶ範囲

PeerTube・Kalturaのサーバー実装・OvenMediaEngineはAGPL系です。AGPLv3の特徴は、改変したプログラムをネットワーク越しに利用させる場合、その利用者に対して改変後のソースコードを提供する条件が加わる点にあります。GPLが「配布」を条件の起点にするのに対し、AGPLは「サービスとして使わせること」を起点にします。

実務上の線引きはこうです。無改変のまま社内で立てて使うだけなら開示の論点は生じません。自社ブランドの動画配信サービスとして外部の会員に提供し、その過程でコードを改変するなら、改変部分は同じライセンスで提供する前提になります。この条件を受けられないなら、AGPL系3製品は候補から外すのが早い判断です。

Apache 2.0のAnt Media CEでも有償版に閉じられる機能の見極め

Ant Media Serverのリポジトリには COMMUNITY_EDITION_LICENSE と ENTERPRISE_EDITION_LICENSE の2ファイルが並んでいます。前者の本文はApache License Version 2.0（January 2004）で、コピーレフトの制約はありません。後者は別条件で、問い合わせ窓口が案内される形式です。

気をつけるのは、ライセンスがゆるいことと機能が揃っていることが別問題だという点です。無償版で検証を進めて要件が満たせないと分かる場所は、たいていサブ秒配信・クラスタ構成・録画やDRM連携といった規模と信頼性に関わる部分です。検証は「無償版でどこまで動くか」ではなく「有償版が必要になる境界がどこか」を先に確認する順序で進めてください。

顧客納品と改変で条項が問題化する3つの具体パターンと契約確認事項

受託開発で条項が争点になるのは、次の3つの場面です。

1. AGPL系製品を改変して顧客のサービスとして納品し、顧客がエンドユーザーへ提供する場合。改変部分のソース提供義務が顧客側に発生し得るため、契約前に共有が必要になる
2. 顧客が「ソースコードの著作権を自社に帰属させる」条件を出す場合。OSS由来のコードは元のライセンスが維持されるため、帰属条項をそのまま受けられない
3. Ant Media Serverのように無償版と有償版が同一リポジトリにある製品で、検証時に有償版バイナリを使い、本番でも同じ構成のまま運用しようとする場合

いずれも設計が終わってから発覚すると、製品の入れ替えか契約条件の変更しか選べなくなります。ライセンス確認は要件定義の工程に入れるべき作業です。

オープンソースで埋まらない3領域と商用サービスへ切り替える閾値

OSSで組んだ配信基盤が要件に届かなくなる地点は、次の3つに集約されます。着手前にこの3つを確認すれば、途中での方針転換を避けられます。

マルチDRMのライセンスサーバーがOSSで代替できない理由と契約条件

OSSの配信サーバーでできるのは、AES-128などによるセグメントの暗号化までです。Widevine・PlayReady・FairPlayのマルチDRMは、再生端末側の保護環境と鍵配布の仕組みが各方式の提供元と結び付いており、ライセンスサーバーを自作して代替する設計にはなっていません。

判断はシンプルです。コンテンツホルダーからDRM必須の条件が出ている、または有料の映画・講座動画を扱うなら、OSS単体では要件を満たせません。SPEKEのような鍵プロバイダ連携を含む実装は動画配信システムの構築｜トランスコードからHLS配信・視聴制御・DRMまで実装解説で扱っています。社内研修や販促動画で「URLを知らない人に見せない」水準なら、署名付きURLと暗号化で足ります。

同時視聴数が数百を超えた時点でCDN前提に切り替わる境界と費用条件

自前サーバー1台で配信を受け止められる同時視聴数は、帯域から逆算できます。1本2.8Mbpsで100人が同時視聴すれば280Mbps、1,000人なら2.8Gbpsです。後者はサーバー1台の回線で受けられる規模ではありません。

つまりOSSの選定で解けるのは配信ソフトウェアの問題だけで、同時視聴数の問題はCDNの契約と転送量課金の問題に変わります。ここまで来ると「OSSだから無料」という前提は崩れ、月額はCDNの転送量に比例します。社内配信で同時数十人なら自前で完結し、外部公開で数千人規模ならCDNを含む構成が前提です。

課金と視聴権限の管理が自社実装として残る理由と工数の見積もり内訳

3つ目が、単体プロダクト型を選んでも残る領域です。有料配信では、契約プランと視聴可能なコンテンツの対応、解約時の視聴停止、支払い失敗時の扱いといった状態管理が必要になります。PeerTubeもOwncastも会員課金を前提とした製品ではないため、この部分は決済サービスとの連携を含めて自社で書くことになります。

工数の目安は、配信基盤の構築そのものより大きいのが実態です。プラン管理と視聴権限判定、決済Webhookの受け口、失敗時のリトライまで含めれば、単純な動画共有サイトを立てる作業とは桁が変わります。無料のOSSを選んだのに開発費が膨らむ案件は、ほぼこの領域で膨らんでいます。

オープンソース採用が成立する条件と着手した時点で失敗する4類型

ここまでの実測を踏まえて、採用可否を言い切ります。玉虫色にせず、条件で切り分けます。

社内配信と閉域運用でOSSが第一候補になる具体条件と必要な運用体制

次の条件が揃うならOSSで組むほうが合理的です。視聴者が社内または限定メンバーで同時視聴が数十人規模、DRM要件がなく署名付きURLで足りる、映像を社外のASPに預けたくない機密性がある、そして障害時に数時間の停止を許容できる。この範囲ならOwncastやSRSで構築でき、月額はサーバー費用だけに収まります。

特に効くのが3つ目です。人事評価や製造ラインの映像のように外部サービスへ預けることが承認されないコンテンツでは、ASPが候補から消えるため自前構築が唯一の選択肢になります。この場合、OSSは消極的な選択ではなく要件に沿った選択です。

外部有料配信とDRM必須要件で導入を見送るべき判断基準と確認条件

逆に、次の4類型はOSSでの着手自体が失敗になります。

• DRMが契約条件に入っている外部向け有料配信。ライセンスサーバーを自作できないため、着手時点で要件未達が確定する
• 同時視聴が数千人規模のイベント配信。OSSの選定ではなくCDNと冗長化の設計が本題になる
• 24時間365日のSLAを顧客と結ぶ配信。パッチ適用と障害対応を担う専任体制が前提になる
• インフラ運用の専任者が不在の組織。PeerTube v8.2.4がセキュリティ修正で出ているように、更新追従を止めた瞬間に公開サーバーがリスクになる

4つ目は特に見落とされます。構築は外注できても、脆弱性対応は運用が続く限り毎月発生します。この体制が描けないなら、ASPを選ぶか、構築と保守を含めて動画配信システム開発のような受託開発に切り出す判断が現実的です。

人件費とASP月額が逆転する損益分岐点の試算と目安を判断する条件

OSSの費用は、ライセンス料ゼロと引き換えにエンジニアの時間で支払う構造です。構築に20人日、その後の運用に月2人日かかると仮定すると、単価を1人日5万円で置いた場合の初期100万円・月額10万円相当になります。ASPの月額が数万円台で収まる規模なら、金額だけで見れば逆転しません。

逆転が起きるのは、視聴量が増えてASPの従量課金が跳ねる場合と、ASPでは実現できない改変が必要な場合です。前者は視聴時間あたりの単価で計算でき、判断材料は動画配信システムの費用｜視聴時間から逆算するASP月額と自社構築の実額に整理しています。年間の視聴時間が小さいうちはOSSの人件費のほうが高くつくと考えて構いません。

よくある質問

動画配信システムをOSSで組む検討時に、実装前によく問われる論点をまとめます。

動画配信システムをオープンソースで作ると本当に無料で済みますか？

ソフトウェアのライセンス料は無料でも、総額は無料になりません。サーバー費用、外部公開時のCDN転送量、そして構築と月々の脆弱性対応に充てるエンジニアの工数が発生します。構築20人日・運用月2人日という前提で試算すると、ASPの月額数万円を超えるケースが多くなります。無料が効くのは、社内配信で同時数十人・機密性が高くASPを使えない、といった条件が揃った場合です。

オープンソースの動画配信システムでDRMによる著作権保護はできますか？

AES-128などのセグメント暗号化までは可能ですが、Widevine・PlayReady・FairPlayのマルチDRMはOSS単体では実現できません。これらは再生端末側の保護環境と鍵配布が各方式の提供元と結び付いており、ライセンスサーバーを自作して置き換える設計になっていないためです。DRMが契約条件に入っている案件では、商用のDRMサービスかDRM込みのASPを前提に構成してください。

PeerTubeやOwncastは企業の社内動画配信に使えますか？

社内動画配信に使えます。Owncastは単一バイナリで動くため初期構築が軽く、社内のライブ配信やイベント中継なら短期間で立ち上がります。PeerTubeはv8.2.4（2026年8月4日時点）まで版が進み、動画投稿サイトとしての機能は揃った状態です。ただし会員課金や視聴権限の細かい制御は前提にない製品のため、有料配信や部署単位の視聴制御が要件なら追加開発が必要です。

AGPLのソフトを使うと自社のソースコードを公開する義務が生じますか？

無改変のまま社内で立てて使う範囲では、開示の論点は生じません。条件が加わるのは、改変したプログラムをネットワーク越しに外部の利用者へ使わせる場合で、その利用者に対して改変後のソースを提供する前提になります。PeerTube・Kalturaのサーバー実装・OvenMediaEngineがこの型です。外部提供型のサービスを計画しているなら、MITのSRSやMediaMTX、Apache 2.0のAnt Media Server Community Editionを候補にするほうが調整が少なくなります。

nginx-rtmp-moduleは今から採用しても問題ありませんか？

新規案件では推奨しません。最新タグはv1.2.2（2021年5月30日）で、その前がv1.2.1（2017年11月29日）と更新が事実上止まっており、ドキュメントにLL-HLSの記載もありません。RTMPを受けてHLSを出すだけの閉じた用途なら今でも動作しますが、同じMITやBSD系の選択肢としてSRSやMediaMTXが継続的に更新されているため、新規で組むならそちらを起点にするほうが安全です。

関連記事

• 動画配信システムとは？仕組み・配信方式と、ASP/自社開発の選び方を受託開発目線で解説：ASPと自社開発のどちらを選ぶかという上流の判断軸を確認できます
• 動画配信システムの構築｜トランスコードからHLS配信・視聴制御・DRMまで実装解説：自前構築を選んだ後のVOD側パイプラインと視聴制御の実装を扱っています
• ライブ配信システムの構築｜RTMP/SRT取り込みからLL-HLS配信・冗長化・費用設計まで：ライブ用途の取り込み経路・冗長化・稼働時間課金の設計を扱っています
• 動画配信システムの比較｜同時視聴数・DRM・課金・LMS連携で選ぶ判断軸：OSSを見送る場合の商用ASPの選定軸を整理しています
• 動画配信システムの費用｜視聴時間から逆算するASP月額と自社構築の実額：損益分岐の判断に使う視聴時間あたりの費用計算を扱っています