# OTTプラットフォームのスケーラビリティ：10万人超の同時視聴に耐える

**Source:** https://vodlix.com/ja/blog/ott-platform-scalability  
**Summary:** スケーラブルなCDN、アダプティブ配信、耐障害性の高いインフラ、モニタリング、負荷テストによって、OTTプラットフォームが10万人を超える同時視聴者をどう支えるかを解説します。  
**Published:** 2026-08-11  
**Publisher:** Vodlix

---

ライブ配信は1万人の視聴者では問題なく動いていても、数分のうちに10万人が参加した途端に破綻することがあります。

それこそが**OTTプラットフォームのスケーラビリティ**という本当の課題です。

ライブスポーツ、速報ニュース、コンサート、製品発表、宗教行事、大型エンタメ作品の配信開始は、通常の視聴需要とはまったく異なる急激なトラフィックの山を生みます。プラットフォームは、何千もの視聴者がほぼ同時に流入するなかで、映像の取り込み、処理、認可、配信、監視をこなさなければなりません。

答えは単にサーバーを増やすことではありません。スケーラブルなOTTアーキテクチャは、配信処理の大半をエッジへ寄せ、オリジンを守り、アダプティブビットレート配信に対応し、障害に耐えられるだけの冗長性を備えている必要があります。

本ガイドでは、OTTプラットフォームを**10万人超の同時視聴者**に備えるために何が必要か、そして大規模なライブイベントの前に配信事業者が何をテストすべきかを解説します。

## なぜ10万人の同時視聴は難しいのか {#なぜ10万人の同時視聴は難しいのか}

同時視聴者数は、総視聴者数とは別物です。

登録ユーザーが数百万人いても、同じ瞬間に視聴しているのはごく一部にすぎません。しかし大型イベントでは、何千人ものユーザーがほぼ同時に押し寄せます。

たとえば、普段は1万5,000人の同時視聴者に対応しているプラットフォームを想像してください。優勝を懸けた試合が始まり、数分のうちに10万人が視聴しようとします。

これは複数のレイヤーに負荷をかけます。

- 映像の取り込み
- エンコードとトランスコード
- オリジンのインフラ
- CDNによる配信
- 認証
- DRM
- APIとデータベース
- プレーヤーからのリクエスト
- アナリティクス
- 決済・視聴権限のシステム

したがって、最も重要な原則はシンプルです。

**10万人の視聴者が生むトラフィックを、あたかも1人ひとりが独立した映像コネクションであるかのようにオリジンへ到達させてはいけません。**

配信負荷の大部分はCDNが吸収すべきです。動画CDNはコンテンツを視聴者の近くまで届け、オリジンへ戻る必要のあるトラフィックを減らします。

## スケーラブルなライブ配信を支えるアーキテクチャ {#スケーラブルなライブ配信を支えるアーキテクチャ}

高同時接続のOTTアーキテクチャは、一連のパイプラインとして捉えられます。

**ライブソース → 取り込み → エンコード → パッケージング → オリジン → CDN → プレーヤー**

各レイヤーの役割はそれぞれ異なります。

### **1. 信頼できる取り込み**

起点となるのはライブの入力信号です。入力が落ちてしまえば、どれだけCDN容量があっても配信は救えません。

大型イベントでは、取り込み経路の冗長化を検討する価値があります。[AWS](https://aws.amazon.com/media/resources/live-streaming/)のライブ配信ソリューションのようなリファレンスアーキテクチャでは、耐障害性を高めるためにプライマリとセカンダリの入力が使われています。

### **2. アダプティブビットレートのエンコード**

高ビットレートの単一ストリームは、すべての視聴者に適しているわけではありません。

エンコーダーは複数の品質レベルを生成し、プレーヤーが利用可能な帯域やデバイス性能に応じて切り替えられるようにすべきです。

たとえば：

| **品質** | **主な用途** |
| --- | --- |
| 360p | 低帯域・モバイル |
| 480p | 標準的な視聴 |
| 720p | HD配信 |
| 1080p | フルHD |
| 4K | プレミアム・高帯域での視聴 |

具体的なビットレート階層は、コンテンツ、デバイス、コーデック、対象視聴者に応じて設計する必要があります。

Vodlixは[HLSとMPEG-DASHのアダプティブ配信](https://vodlix.com/features/hls-mpeg-dash)に対応しており、Web・モバイル・テレビの各環境へ複数の品質バリエーションを届けられます。

### **3. CDNファーストの配信**

同時接続の急増に対処するうえで、CDNは最も重要な構成要素のひとつです。

各視聴者がオリジンへ何度も映像セグメントを要求する代わりに、CDNのエッジロケーションがキャッシュ済みのコンテンツをユーザーの近くから配信できます。

AWSのライブ配信リファレンスアーキテクチャでは、オリジン／パッケージング層をAmazon CloudFrontの背後に置き、視聴者への配信はCDNが担います。

10万人規模のイベントでは、この違いが決定的になります。

アプリケーションサーバーは主にアプリケーションロジックを担当し、重い映像配信の負荷はCDNが引き受けるべきです。

## オリジンをボトルネックにしない {#オリジンをボトルネックにしない}

ライブ配信における最大級の誤りは、オリジンが視聴者数に合わせて自然にスケールするという前提で設計してしまうことです。

10万人が同じライブセグメントを要求する場面を想像してください。そのリクエストが繰り返しオリジンへ届けば、インフラはあっという間に限界を迎えます。

だからこそ、キャッシュ戦略、オリジンシールド、効率的なセグメント配信が重要になります。

ライブ配信が特に難しいのは、マニフェストが絶えず更新され、セグメントが短い間隔で届くからです。したがってアーキテクチャは、通常のWebトラフィックと同じように扱うのではなく、ライブ映像特有のリクエストパターンを前提に設計しなければなりません。

役立つ原則があります。

**アプリケーションサーバーだけでなく、配信レイヤーをスケールさせること。**

[Cloudflare](https://www.cloudflare.com/learning/video/what-is-a-video-cdn/)も同様に、動画CDNはコンテンツを視聴者の近くで配信することでレイテンシを下げつつ、オリジンの過負荷を防ぐと指摘しています。

## 平均ではなくピークに備える {#平均ではなくピークに備える}

平常時のトラフィックが同時2万人なら、ちょうど2万人ぶんのインフラを設計するのは危険です。

重要なのは、**想定されるピーク同時接続数に安全余裕を加えた値**です。

シンプルな試算モデルで考えてみましょう。

**想定ピーク＝10万人**

10万をシステムが耐えるべき上限として扱うのではなく、想定外の需要とインフラ障害に備えて追加のキャパシティを確保してください。

キャパシティ計画では次の点を考慮すべきです。

- ピーク時の同時視聴者数
- 視聴者の増加ペース
- 平均映像ビットレート
- CDNのリージョン数
- セグメント長
- 品質バリエーションの数
- 認証リクエスト
- APIトラフィック
- アナリティクスのトラフィック
- DRM／ライセンスのリクエスト
- 想定される地域別のトラフィック分布

必要な帯域幅も、ビットレート次第で大きく変わります。

たとえば、平均配信ビットレートが5Mbpsの場合：

**10万人 × 5Mbps = 500Gbps**

このトラフィックをアプリケーションサーバーや単一のオリジンに直接通そうとするのが妥当な設計とは言えない理由が、ここにあります。

## 認証とDRMにも独自のスケーラビリティ計画が必要 {#認証とdrmにも独自のスケーラビリティ計画が必要}

映像配信はシステムの一部にすぎません。

大型イベントが始まると、視聴者は同時に次の操作を行う可能性があります。

1. アプリを開く。
2. ログインする。
3. サブスクリプションを確認する。
4. 再生の認可を要求する。
5. DRMライセンスを要求する。
6. ストリームを読み込む。
7. アナリティクスのイベントを送信する。

これらのリクエストがすべて同じバックエンドサービスに集中すれば、CDNが完璧に機能していてもアプリケーションは倒れかねません。

可能な範囲でワークロードを分離しましょう。

認証、視聴権限のチェック、API、DRM、アナリティクス、映像配信が、ひとつの長い依存の連鎖になってはいけません。

プレミアムコンテンツでは、高負荷時にもセキュリティを維持する必要があります。VodlixはOTTプラットフォームの一部として、ライブ配信向けのセキュリティ機能、コンテンツ管理、マルチプラットフォーム対応のDRM機能を提供しています。

## イベント開始前にモニタリングを整える {#イベント開始前にモニタリングを整える}

スケーラビリティは、イベントが始まってからサーバーのCPUを眺めて確認できるものではありません。

配信パイプライン全体をリアルタイムに可視化する必要があります。

重要な指標には次のようなものがあります。

- 同時視聴者数
- 再生開始数
- 起動時間
- バッファリング率
- 映像ビットレート
- CDNのキャッシュヒット率
- オリジンへのトラフィック
- HTTPエラー率
- 認証のレイテンシ
- DRMの応答時間
- セグメント配信のエラー
- 再バッファリングの発生
- 地域ごとのパフォーマンス

Vodlixには、映像と視聴者のパフォーマンスを監視するためのリアルタイム分析・レポート機能が備わっています。さらに近年は、[配信におけるAI](/blog/ai-in-streaming)がコンテンツの拡充とアクセシビリティ向上を大規模に後押ししています。

目指すべきは、**視聴者が不具合を報告し始める前に**品質低下を検知することです。

## 負荷テストは必須 {#負荷テストは必須}

同時10万人が見込まれるイベントなら、その本番配信を初めてのスケーラビリティテストにしてはいけません。

公開前にテストしましょう。

有効なテストの段取りは、たとえば次のようになります。

| **テスト段階** | **目的** |
| --- | --- |
| 1万ユーザー | ベースラインの確認 |
| 2万5,000ユーザー | 初期のボトルネックの発見 |
| 5万ユーザー | スケーリング挙動の検証 |
| 7万5,000ユーザー | ピーク対応準備の検証 |
| 10万ユーザー超 | 想定イベント規模の検証 |
| 障害テスト | 冗長性と復旧の確認 |

テストで再現すべきなのは、映像再生だけではありません。

ログインの集中、APIリクエスト、再生認可、マニフェスト取得、CDN配信、DRM、アナリティクス、そしてコンポーネント障害からの復旧までをテストしてください。

最も価値のあるテストは、存在に気づいていなかったボトルネックを見つけ出すテストであることが少なくありません。

## 大型ライブイベント前にOTT事業者がすべきこと {#大型ライブイベント前にott事業者がすべきこと}

実務的な事前チェックリストには、次の項目を入れましょう。

**1. ピーク同時接続数を確定する。**  
過去のイベント、登録者数、マーケティングのリーチ、[過去のトラフィック](/blog/state-of-ott-streaming)をもとに想定視聴者数を見積もります。

**2. CDNのキャパシティを検証する。**  
想定される地域分布と帯域需要に配信アーキテクチャが耐えられるか確認します。

**3. オリジンをテストする。**  
オリジンのインフラが突発的なリクエストの殺到から守られていることを確かめます。

**4. 認証とDRMをテストする。**  
ユーザーが再生の認可を得られなければ、スケーラブルな映像パイプラインも意味がありません。

**5. 複数のビットレートプロファイルをテストする。**  
視聴者が再生を止めずに品質を切り替えられるか確認します。

**6. 現実的な負荷テストを実施する。**  
目標値で止めず、想定ピークを超えるところまでテストします。

**7. モニタリングとアラートを整備する。**  
どの指標がエスカレーションの引き金になるかを明確にしておきます。

**8. フォールバックを用意する。**  
重要な配信では、可能な範囲で取り込み・処理・配信に冗長性を持たせるべきです。

## Vodlixがスケーラブルな OTT 配信をどう支えるか {#vodlixがスケーラブルな-ott-配信をどう支えるか}

こうしたインフラを自社ですべて構築するには、エンジニアリング、クラウド、CDN、セキュリティ、モニタリング、運用にわたる相当な専門知識が必要になります。

ゼロから[OTTスタック全体](https://vodlix.com/features)を作らずにサービスを立ち上げたい配信事業者に向けて、Vodlixは[ライブ配信](https://vodlix.com/features/stream-live-video-online)、[VOD](https://vodlix.com/features/vod)、テレビ放送、CDN連携、アダプティブ配信、アナリティクス、収益化、マルチプラットフォーム配信をカバーする、すぐに導入できるOTTプラットフォームを提供します。Vodlixは完全な[ホワイトラベルOTTプラットフォーム](https://vodlix.com/features/white-label)であり、自社ブランドのまま立ち上げて拡大できます。

Vodlixのライブ配信インフラはトップクラスのCDNを利用し、スケーラブルなライブ配信を前提に設計されています。HLSとMPEG-DASH、アダプティブビットレート配信、リアルタイム分析にも対応し、Web・モバイル・[テレビアプリ](https://vodlix.com/features/tv-apps)でライブコンテンツを届けられます。

大型ライブイベントを控える事業者にとってこれは、インフラの各要素を個別に作り込むことから、コンテンツ・視聴者・収益化・視聴体験の運営へと注力先を移せることを意味します。

## まとめ {#まとめ}

10万人超の同時視聴に対応するとは、10万人を支えられるほど強力な1台のサーバーを探すことではありません。

これはアーキテクチャの問題です。

スケーラブルなOTTプラットフォームは、映像配信をアプリケーションの処理から切り離し、CDNでコンテンツを配信し、オリジンを守り、アダプティブビットレート配信に対応し、認証とDRMをスケールさせ、視聴体験をリアルタイムに監視し、本番前にピーク条件をテストします。

そして何より、スケーラビリティはトラフィックの山が来る**前に**設計しておくべきものです。

大型ライブイベントを見込む事業なら、平均的な視聴者数に合わせた設計では足りません。全員が同時に再生ボタンを押す、その瞬間に合わせて設計してください。

**Q: OTTプラットフォームのスケーラビリティとは何ですか？**

OTTプラットフォームのスケーラビリティとは、視聴者数、動画リクエスト、帯域要件、アプリケーショントラフィックの増加を、目立った性能低下なく処理できる配信サービスの能力を指します。

**Q: OTTプラットフォームはどうすれば10万人の同時視聴に対応できますか？**

スケーラブルなアーキテクチャは通常、CDNによる配信、アダプティブビットレート配信、耐障害性の高いオリジン、スケーラブルな認証、モニタリング、十分な負荷テストを組み合わせています。

**Q: ライブ配信でCDNが重要なのはなぜですか？**

CDNは映像を視聴者の近くまで届け、オリジンが直接さばくべきトラフィックを減らすため、スケーラビリティと再生性能の向上につながります。

**Q: アダプティブビットレート配信はスケーラビリティを高めますか？**

帯域の管理に役立ち、再生品質も向上します。各視聴者がネットワークやデバイスの状況に応じた品質を受け取れるためです。

**Q: 10万人規模のイベント前に何をテストすべきですか？**

映像配信、CDNの性能、オリジンの負荷、認証、DRM、API、アナリティクス、再生開始、バッファリング、障害からの復旧をテストしてください。

**Q: 10万人の同時配信にはどれくらいの帯域が必要ですか？**

配信ビットレート次第です。視聴者1人あたり平均5Mbpsなら、同時10万人で合計およそ500Gbpsの映像スループットに相当します。

**Q: Vodlixはライブ配信に対応していますか？**

はい。Vodlixはライブテレビ、ライブイベント、HLSおよびMPEG-DASH配信、CDN配信、アダプティブビットレート配信、アナリティクス、収益化、複数プラットフォームへの配信に対応しています。

**Q: OTTプラットフォームは平均トラフィックとピークのどちらに合わせて設計すべきですか？**

追加のキャパシティと冗長性を確保したうえで、想定されるピークトラフィックに合わせて設計・テストすべきです。大型ライブイベントでは平均値は信頼できる指標になりません。

**Q: ライブ配信プラットフォームがトラフィック急増時に落ちる原因は何ですか？**

よくある原因は、CDN容量の不足、オリジンの過負荷、認証のボトルネック、DRMのボトルネック、テスト不足のAPI、不十分なモニタリング、冗長性の欠如です。

**Q: ライブOTTプラットフォームに負荷テストは必要ですか？**

はい。負荷テストは、実際のイベントが想定外の同時接続の山を生む前に、インフラのボトルネックを洗い出すのに役立ちます。