動画配信システムのオンプレミス構築｜帯域・ストレージ・機密映像で決める判断軸

動画配信システムをオンプレミスで持つかどうかは、サーバーを自社に置くか借りるかという一般論では決まりません。同時視聴数がそのまま回線帯域に跳ね返り、素材1本がABR変換で数倍のストレージに膨らみ、既存のハードウェアエンコーダが資産として残っているという、動画固有の事情が判断を左右します。この記事では必要帯域の逆算、ストレージ量の試算、エンコーダの再利用可否、機密映像を閉域に置く必然性の4軸で、自社要件がオンプレミス側に振れるかを判定する方法を整理しました。初期費用と5年総保有コストの分岐点、採用してよい条件、そして構成が破綻する失敗パターンまで、受託開発会社の目線で条件を明示します。

まとめ：動画配信システムをオンプレミスで持つ判断を分ける4つの軸

結論から言えば、オンプレミスが妥当なのは「閉域網から出せない映像を、社内回線で捌ける規模の視聴者に配信する」ケースに絞られます。判定は4軸です。第一に帯域。1人あたり5Mbpsとすると1Gbpsの社内回線は実効ベースで同時140人前後が限界で、それを超えるとサーバーではなく回線から先に飽和します。第二にストレージ。1時間のフルHD素材はABR変換後におよそ4.5GB、原本を残せば7GB前後まで膨らみ、500時間の蓄積で3TB規模になります。

第三がエンコーダ資産です。SDI出力の収録・配信機材をすでに持ち、RTMPやSRTで送出できるなら、その投資を捨てずに済むぶんオンプレミスの相対的な不利が縮みます。第四が機密映像の性質。役員会や治験、製造ラインの実映像のように「インターネット経由の保管そのものが社内規程で許されない」ものだけがオンプレミスの必然に該当し、社外秘の研修動画程度なら署名付きURLとDRMで足ります。この4軸のうち帯域と機密性の2つが同時にオンプレミス側へ振れないなら、オリジンだけ自社に置いて配信はCDNへ逃がすハイブリッドの方が総額でも運用でも有利になります。

動画配信のオンプレミス構成が一般の業務システムと異なる負荷の前提

基幹システムや社内ポータルをオンプレミスで持つ判断と、動画配信を持つ判断は同じ枠組みで比較できません。扱うデータの単位が桁で違い、負荷のかかり方も別物だからです。

配信サーバー・エンコーダ・ストレージが担う動画配信特有の3要素

動画配信のオンプレミス構成は、大きく3つの装置に分かれます。カメラやファイルを受け取って複数画質に変換するエンコーダ／トランスコーダ、変換済みのセグメントを保持するストレージ、そして視聴者へHLSやMPEG-DASHで配る配信サーバーです。業務システムでいうアプリケーションサーバーとデータベースの2層構造とは違い、この3つは要求されるリソースの種類が完全に別れています。

エンコーダはCPUまたはGPUを張り付かせる計算負荷、ストレージは容量とシーケンシャル読み出し、配信サーバーはネットワークI/Oとコネクション数。1台のサーバーに同居させると、ライブ配信中のトランスコードがVODの読み出しを圧迫するといった干渉が起きます。オンプレミスで組む場合、この3要素を最初から別筐体に分けるか、少なくとも別リソースプールとして設計しておくことが前提です。各要素の実装レベルの構成方法はトランスコードからHLS配信・視聴制御・DRMまでの構築手順で扱っています。

同時視聴数が帯域を線形に押し上げる構造と業務システムとの負荷差

業務システムの同時接続は、1人あたりの通信量が小さく、キャッシュとセッション管理で吸収できます。動画は違います。同時視聴者が1人増えるたびに、その人のビットレート分の帯域が丸ごと積み上がる。1080pを5Mbpsで配れば、1,000人の同時視聴で5Gbpsを消費します。この線形性がオンプレミス構成の設計を支配します。

サーバーのCPU使用率にはまだ余裕があるのに、回線側が先に埋まって視聴者の再生が途切れる。オンプレミス配信で最も多いのはこの詰まり方です。フルHDの実配信では画質と符号化方式によって1人あたり4〜18Mbpsの幅があり、上限側の設定を選べば同じ人数でも必要帯域は3倍以上に跳ねます。設計時に押さえるべき数字はサーバースペックではなく、想定同時視聴数と配信ビットレートの積です。

同時視聴数から逆算する必要帯域と、社内回線が先に飽和する境界

オンプレミス採用の可否は、多くの場合この章で決着します。

1人5Mbpsで積算する必要帯域と1Gbps回線が頭打ちになる人数

計算式は単純です。必要帯域＝1人あたりのビットレート×同時視聴数。1080p／5Mbpsを基準に置くと、同時100人で500Mbps、200人で1Gbps、1,000人で5Gbpsとなります。ここで注意すべきは、公称1Gbpsの回線が1Gbpsを出し切れない点です。TCPのオーバーヘッドとバースト、他業務トラフィックとの共用を織り込むと、実効で使えるのは公称の6〜7割程度。1Gbps回線で安定して配れる同時視聴数は、5Mbps配信ならおよそ140人前後が現実的な上限になります。

社内向け配信なら、この帯域は社内LANとインターネット接続回線のどちらを通るかで意味が変わります。全員が本社の同一セグメントにいるならLAN内で完結し、10Gbpsのスイッチング能力があれば1,000人規模でも処理可能です。在宅勤務者や拠点が混ざった瞬間、その人数分がインターネット接続回線を通り、帯域の制約が一気に厳しくなります。

拠点配信でeCDNを挟んで帯域を圧縮できる条件と使えない条件

拠点をまたぐ配信の帯域を抑える手段がeCDNです。社内向けに閉じたCDNのことで、実装はマルチキャスト型、P2P型、キャッシュ型の3系統に分かれます。マルチキャスト型は同一ストリームを1本だけ拠点へ流して端末側で受け取る方式で、理論上は視聴人数が増えても拠点間の帯域が増えません。ライブ配信では最も効きます。

ただし条件が厳しい。マルチキャストは経路上のルーターとスイッチがすべてIGMPやPIMに対応し、設定が入っていなければ通りません。VPN越しやクラウド接続を挟む区間では通らないことが多く、既存ネットワークの改修が前提になります。オンデマンド視聴が中心なら、そもそも視聴タイミングがばらけるためマルチキャストは機能せず、キャッシュ型の拠点プロキシかP2P型を選ぶことになります。ライブ主体なのかVOD主体なのかで、選べるeCDN方式が変わる点は設計初期に確定させてください。

ABR変換で膨らむストレージ量と、既存エンコーダ資産の再利用可否

帯域の次に効くのがストレージ容量と、すでに持っている機材をどこまで転用できるかです。

1時間の1080p素材がABR変換後に何GBへ増えるかの試算

視聴環境に応じて画質を切り替えるABR配信では、1本の素材を複数のビットレートへ変換して並列に保持します。1080p／5Mbps、720p／3Mbps、480p／1.5Mbps、360p／0.8Mbpsの4段構成なら、合計は約10.3Mbps相当。1時間の素材でおよそ4.5GBになります。原本を保管ポリシー上残すなら、5Mbpsの元ファイル約2.2GBが加算され、1時間あたり7GB弱を見込む計算です。

この数字を蓄積時間に掛けると、必要容量が見えます。100時間で約700GB、500時間で約3.4TB、1,000時間なら7TB前後。研修動画を毎年積み増す運用では、3年で当初想定の3倍に達することも珍しくありません。オンプレミスの場合、この増分をディスク増設か筐体追加で吸収する必要があり、増設のたびに停止調整とRAID再構築の時間が発生します。ストレージが右肩上がりに増える運用は、容量を後から足せるクラウド側が構造的に有利です。逆に、蓄積量が数百時間で頭打ちになる用途なら、この不利はほぼ消えます。

SDI出力のハードウェアエンコーダを再利用できる接続条件と限界

すでに収録スタジオや会議室にSDI出力の機材を入れている企業は、その資産を転用できるかで判断が変わります。判定基準は出力インターフェースです。手元の機材がRTMPまたはSRTでの送出に対応していれば、オンプレミスの配信サーバーへ直接投げられ、追加投資はサーバー側だけで済みます。

限界もはっきりしています。第一に、古いハードウェアエンコーダはH.264までしか対応せず、H.265やAV1で配信帯域を圧縮する構成には乗れません。第二に、機材1台が担当できるのは基本的に1系統で、同時に複数会議室から配信する要件が出た時点で台数が線形に必要になります。第三に、機材のファームウェアが更新停止していると、TLSの世代が上がったときに送出先へ接続できなくなる事故が起きます。既存機材を理由にオンプレミスを選ぶなら、そのエンコーダの保守提供が何年残っているかを先に確認してください。残存3年を切っているなら、資産の再利用は判断材料から外すのが妥当です。

機密映像を閉域で扱う必然性と、クラウドでも満たせる保護範囲の線引き

「セキュリティのためオンプレミス」という要望は頻繁に出ますが、その大半はクラウド側の機能で満たせます。本当に閉域が要る映像はごく一部です。

閉域網に置く必然がある映像と署名付きURLで足りる映像の境目

閉域に置く必然があるのは、外部事業者のストレージに保管すること自体が禁じられている映像です。具体的には、業界規制や契約で「データを国内の自社管理設備から出さない」と定められている治験・臨床の記録映像、防衛関連の設備内映像、金融機関の取締役会の録画などが該当します。ここでの制約は技術要件ではなく規程要件なので、暗号化を強化しても解消しません。

一方、社外秘の研修動画、未発表製品の社内説明会、営業ノウハウの共有映像は、閉域である必然がありません。これらは署名付きURLの短期失効、IPアドレス制限、DRMによる再生端末の制御、視聴ログの記録という組み合わせで、実務上の漏えいリスクを抑えられます。判定の質問はひとつです。「その映像がクラウド事業者のデータセンターに存在すること自体が規程違反になるか」。ならないのであれば、オンプレミスを選ぶ根拠としては弱く、帯域とコストの軸で判断すべき案件になります。

視聴ログと持ち出し制御でオンプレミスが有利になる具体的な場面

閉域の必然がなくても、オンプレミスが実務で効く場面はあります。ひとつは視聴ログの粒度です。誰がどの動画のどの秒数まで見たかを、既存の人事マスタや資格管理システムと同一DB内で結合して集計したい場合、ログをASP側から日次エクスポートして突き合わせる運用は破綻しやすい。自社DBに直接書き込める構成なら、受講完了判定をリアルタイムに他システムへ渡せます。

もうひとつは持ち出し制御を既存の資産管理エージェントと連動させる場合です。端末側のスクリーンレコード検知や画面キャプチャ禁止を、社内で既に配布しているエージェントで統一的にかけたいなら、配信基盤も社内側に置いた方が実装が単純になります。ただしこの2つは「あると便利」の水準であり、単独でオンプレミスを正当化するほどの重さはありません。

初期費用と5年総保有コストで見るオンプレミスとASPの分岐点

ここまでの技術要件を金額に置き換えます。オンプレミスは初期に寄り、ASPは運用に寄る構造なので、比較は必ず複数年の総額で行います。

サーバー・ライセンス・回線を積み上げた初期費用の内訳と金額幅

オンプレミス構成の初期費用は、大きく4項目に分かれます。配信サーバーとトランスコード用の機材、ストレージ、配信ソフトウェアのライセンス、そして回線とネットワーク機器の増強です。同時視聴100人規模・蓄積300時間程度の社内配信であれば、機材とストレージで数百万円、これに回線増強と構築費が乗る形になります。

見落とされやすいのが回線側です。既設の1Gbpsで足りるなら追加費用はゼロですが、10Gbps級への増強が必要になった瞬間、機器と月額の両方が跳ね上がります。もうひとつは冗長化。配信サーバーを1台構成にすると、故障時に配信が止まります。全社説明会のライブ配信のように失敗が許されない用途なら、最初から2台構成と切り替え手順を含めた見積が必要です。この冗長分を入れるかどうかで初期費用は倍近く動きます。

Wowza Streaming Engineなど自前運用ソフトのライセンス実額

配信ソフトウェアは、商用ライセンス製品とオープンソースのどちらかを選びます。商用側の代表であるWowza Streaming Engineは、公式のpricingページで金額が公開されている数少ない製品です。2026年8月時点では、月額課金のBasic Monthlyが1インスタンスあたり195ドル／月で、トランスコード対応チャネルを10本含み、追加チャネルは1本あたり25ドル。単月のみの利用は295ドルの買い切りが用意され、年額割引やオフラインキー対応が要るEnterpriseは個別見積となっています。

ライセンス費そのものは初期費用の主役ではありません。オンプレミスのコストを押し上げるのは機材・回線・運用工数の側です。ライセンス費を削る目的でオープンソースへ寄せる判断は、削減額に対して運用負荷が見合わないことが多いため、選定は費用ではなく機能要件で行ってください。オープンソース製品のライセンス条件と自前運用の限界では、製品ごとに商用利用の可否と運用上の詰まりどころを判定しています。

5年総額でASPを下回る同時視聴規模と上回ってしまう規模の境界

総保有コストの比較では、オンプレミスの初期投資を5年で按分し、ASPは月額×60か月で置きます。分岐を決めるのは同時視聴数ではなく、配信の頻度と総転送量です。ASPの課金は転送量または視聴時間に連動するものが多く、毎日配信して転送量が積み上がる用途ほどASP側の総額が伸びます。逆に、年に数回の全社イベントだけに使う構成なら、機材を遊ばせるオンプレミスが不利になります。

実務上の目安として、社内向けに毎日配信があり、同時視聴が常時100人前後で、映像が閉域要件を持つ場合は、5年総額でオンプレミスが下回る余地があります。配信が月数回以下、または視聴者に社外の不特定多数が含まれる場合は、ほぼ確実にASPかクラウド構成が下回ります。転送量ベースでの具体的な試算方法は視聴時間から逆算するASP月額と自社構築の実額にまとめていますので、自社の配信頻度を当てはめて確認してください。

オンプレミスを採用してよい条件と、見送るべき失敗パターンの判定

ここまでの4軸を、採用可否の判定として言い切ります。

オンプレミスを採用してよい3条件と、外れたときに選ぶ代替構成

オンプレミスを採用してよいのは、次の3条件をすべて満たす場合に限ります。第一に、映像が規程上クラウドへ置けない性質を持つこと。第二に、視聴者が社内ネットワークの内側に収まり、同時視聴数が既設回線の実効帯域を超えないこと。第三に、サーバーとネットワークを日常的に保守できる情報システム部門が社内に存在すること。

3つのうち1つでも外れるなら、代替構成へ寄せてください。閉域要件だけがあって運用体制が無いなら、専有型のホスティングやプライベートクラウドに置いて運用を委託する。帯域が足りないなら、オリジンだけ自社に残す構成にする。運用体制はあるが閉域要件が無いなら、素直にASPを選ぶ方が総額でも安定性でも上回ります。動画配信の構築方式そのものを整理したい段階であれば、仕組み・配信方式とASP／自社開発の選び方から先に確認するのが早道です。

セキュリティ目的だけで選んだ構成が破綻する2つの失敗パターン

実際に破綻した構成には共通点があります。ひとつめは、閉域要件が曖昧なまま「安全だから」でオンプレミスを選び、後から在宅勤務者への配信要件が追加されるパターンです。閉域網の外へ配るためにVPN経由の視聴を許可した結果、VPN装置が帯域のボトルネックになり、全社の業務通信まで巻き込んで遅延しました。閉域を選ぶなら、視聴者が閉域の内側に居続けることを組織として確約できるかを先に詰めてください。

ふたつめは、更新の設計を持たないまま導入するパターンです。配信ソフトウェアもOSも、脆弱性対応で定期更新が要ります。閉域だから更新は不要という判断で数年放置した基盤は、いざ更新しようとするとバージョン差が大きすぎて一括移行できず、結局は作り直しになります。オンプレミスを選ぶ以上、年1回の更新枠と検証環境をあらかじめ予算に含めるのが前提条件です。オンプレミスとクラウドの違いをコスト・セキュリティ・拡張性で比較した内容と併せて、動画特有の負荷を上乗せして判断してください。要件整理から構成設計までを外部に預けたい場合は、動画配信システム開発で相談を受け付けています。

オリジンだけ自社に置きCDNへ逃がすハイブリッド構成の現実解

4軸のうち機密性だけがオンプレミス側に振れ、帯域が足りないケースは実際に多く、その場合の解はハイブリッドです。原本とトランスコード処理は自社設備に置き、配信するセグメントだけをCDNへ押し出す。原本がインターネット側に置かれない一方で、視聴者数に応じた帯域はCDNが吸収します。

この構成が成立する条件は、セグメント化された映像がCDNのキャッシュに乗ることを規程上許容できるかどうかです。許容できるなら、署名付きURLの短期失効とDRMを組み合わせて、キャッシュ上のセグメント単体では再生できない状態を作れます。許容できないなら、ハイブリッドも選べません。その場合は視聴者数を制限するか、拠点ごとにキャッシュサーバーを置く閉域完結の構成に倒すしかない。ここは妥協点を探さず、規程側の判断を先に取ってください。技術で埋められない制約を設計で誤魔化すと、監査で構成ごとやり直しになります。

よくある質問

オンプレミス構成の検討時に、発注側から実際に寄せられることの多い質問をまとめました。

オンプレミスの動画配信は本当にクラウドより安全ですか？

設備を自社に置くこと自体が安全性を高めるわけではありません。安全性を決めるのは、視聴権限の制御、通信の暗号化、更新の継続、ログの保全といった運用面です。専任の運用体制が無い状態で自社設備に置くと、更新が止まったサーバーが放置され、クラウドより脆弱になります。オンプレミスが優位なのは「データを外部設備に置けない」という規程要件がある場合であり、それ以外は運用体制の有無で安全性の順位が入れ替わります。

社内向け配信なら何人までオンプレミスで捌けますか？

視聴者が同一拠点の社内LAN内に収まるなら、10Gbps級のスイッチング環境で1,000人規模でも配信できます。制約が出るのはインターネット接続回線を経由する視聴者です。1人5Mbpsで計算すると、公称1Gbpsの回線で安定して配れるのは実効ベースで同時140人前後が上限になります。拠点や在宅の視聴者が含まれる場合は、その人数分だけを対象に必要帯域を積算してください。

既存のエンコーダ機材はそのまま使い回せますか？

RTMPまたはSRTでの送出に対応していれば、オンプレミスの配信サーバーへ直接接続できます。確認すべきは3点です。対応コーデックがH.264止まりでないか、同時に必要な系統数に対して台数が足りるか、そしてファームウェアの保守提供が何年残っているか。保守終了が3年以内に迫っている機材は、TLSの世代更新で送出できなくなるリスクがあるため、再利用を前提にした構成は避けたほうが安全です。

オンプレミスからクラウドへ後から移行できますか？

移行自体は可能ですが、コストがかかるのは映像本体ではなく視聴履歴と権限設定です。動画ファイルはストレージ間の転送で移せる一方、既存の視聴ログや受講完了判定を移行先のデータ構造へ写す作業が残ります。将来の移行を想定するなら、導入時点で視聴ログをシステム固有の形式に閉じ込めず、汎用的なスキーマで自社DBにも保持しておく設計にしておくと、移行時の工数を大きく減らせます。

ストレージはどれくらいの容量を見込めばよいですか？

1080pを4段のABR構成で変換する前提なら、1時間の素材でおよそ4.5GB、原本を残す運用では7GB弱を見込みます。100時間の蓄積で約700GB、500時間で約3.4TBが目安です。初期容量ではなく年間の増加ペースで筐体とディスク増設の計画を立ててください。

関連記事

• 動画配信システムとは？仕組み・配信方式と、ASP/自社開発の選び方を受託開発目線で解説：配信方式と構築方法の全体像を確認できます
• オンプレミスとクラウドの違いとは？コスト・セキュリティ・拡張性で比較し選び方まで解説：動画に限らないインフラの持ち方の一般的な判断軸です
• 動画配信システムの比較｜同時視聴数・DRM・課金・LMS連携で選ぶ判断軸：ASPを選ぶ場合の製品横並びの比較軸が分かります
• 動画配信システムの費用｜視聴時間から逆算するASP月額と自社構築の実額：転送量ベースの費用試算をまとめています
• 動画配信システムのオープンソース8製品｜ライセンス条件と自前運用の限界を実装目線で判定：自前運用を選ぶ場合の製品判定に使えます