動画配信サービスがmp4を直接置かない理由

ストリーミングの仕組みと技術的背景

YouTubeやNetflixなど、現代の動画配信サービスを利用していると「なぜダウンロードできないのか」「なぜ再生中に画質が変わるのか」といった疑問を持つことがあるかもしれません。実は、これらのサービスはmp4ファイルを直接サーバーに置いているわけではなく、HLS（HTTP Live Streaming）やMPEG-DASHと呼ばれるストリーミング技術を使用しています。

では、なぜそのような仕組みが採用されているのか、技術的な観点から詳しく解説します。

1. mp4直置きの何が問題なのか

まず大前提として、mp4ファイルをWebサーバーに置いて配信すること自体は技術的には可能です。しかし、商用規模の動画配信においては以下のような深刻な問題が生じます。

帯域幅とコストの問題

1本の高画質動画（例：4K・2時間）は数十GBにもなります。これを何万ユーザーが同時に視聴しようとすれば、サーバーに莫大な帯域負荷がかかります。mp4はファイル全体を1つのエンドポイントから配信するため、CDN（コンテンツデリバリーネットワーク）による効率的な分散キャッシュが困難です。

ユーザー体験の問題

mp4を直接配信する場合、視聴者のネット環境に関わらず同一品質のファイルを送り続けます。低速回線ユーザーはバッファリングが発生し、逆に高速回線ユーザーには過剰なデータを配信することになります。いずれも最適なユーザー体験とは言えません。

アクセス制御とDRMの問題

mp4ファイルのURLが分かれば、誰でもそのURLに直接アクセスしてダウンロードが可能になります。コンテンツの著作権保護やアクセス制限が実装しにくい構造です。

2. HLS（HTTP Live Streaming）とは何か

HLSはAppleが2009年に策定したストリーミングプロトコルで、現在では業界標準として広く採用されています。その根本的な考え方は「動画を細かく分割して順番に配信する」というシンプルなものです。

m3u8プレイリストファイルの役割

HLSの中核となるのが .m3u8 形式のプレイリストファイルです。このファイルはテキスト形式で、動画のセグメント（断片）がどこにあるかを記述したインデックスとして機能します。

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:10.0,
segment_000.ts
#EXTINF:10.0,
segment_001.ts
#EXTINF:10.0,
segment_002.ts
...
#EXT-X-ENDLIST

上記のように、プレイヤーは最初にこのm3u8ファイルを取得し、そこに書かれたURLを順番にリクエストして動画を再生します。

マスタープレイリストと解像度選択

実際の配信では、多くの場合「マスタープレイリスト」と呼ばれる上位のm3u8ファイルが存在し、複数の画質バリエーションへのリンクが記述されています。

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=1280x720
720p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4000000,RESOLUTION=1920x1080
1080p/playlist.m3u8

プレイヤーはユーザーの回線速度を測定しながら、最適な画質のプレイリストを選択・切り替えます。これがアダプティブビットレート（ABR）と呼ばれる機能の仕組みです。

TSセグメントファイルの正体

実際の動画データは .ts（MPEG-2 Transport Stream）形式の断片ファイルとして配信されます。配信サービスによっては、このファイルの拡張子を意図的に .jpeg や .png などに偽装するケースもあります。ファイルの拡張子が示すフォーマットとは無関係に、中身はMPEG-2 TSストリームです。ffmpegなどのツールはコンテナ形式の自動検出機能を持つため、拡張子が違っても正しく処理できます。

3. アダプティブビットレート（ABR）の仕組み

HLSの最大の特長の一つが、回線速度に応じて画質をリアルタイムに切り替えるABR機能です。

ABRの動作フロー

なぜ画質が自動で切り替わるのか

例えば外出先でモバイル回線が混雑した場合、プレイヤーは自動的に低ビットレートの360pセグメントを取得し始めます。Wi-Fiに繋がって回線が安定すると、自動的に1080pへと切り替わります。この仕組みにより、途切れない再生体験と帯域の最適利用を同時に実現しています。

4. CDNとの組み合わせによる大規模配信の実現

HLSが強力な理由のひとつは、CDN（コンテンツデリバリーネットワーク）との相性の良さにあります。

セグメント分割がキャッシュ効率を上げる理由

CDNはコンテンツをエッジサーバー（ユーザーの近くにあるサーバー）にキャッシュすることで配信を高速化します。しかし、単一の巨大なmp4ファイルはキャッシュ効率が悪く、途中からの再生（シーク）にも対応しにくい性質があります。

一方でHLSのセグメントファイルは通常2〜10秒程度の小さなファイルです。これらは個別にCDNでキャッシュでき、世界中のエッジサーバーに効率よく分散配置できます。

ポイント：小さなファイルを多数配信するHLSの構造は、CDNのキャッシュヒット率を最大化し、オリジンサーバーへの負荷を劇的に削減します。

配信コストへの影響

CDNキャッシュが機能することで、同じセグメントを100万人が視聴してもオリジンサーバーへのリクエストは最小限に抑えられます。大規模配信においてこのコスト差は非常に大きくなります。

5. セキュリティとアクセス制御

mp4を直接置かない理由として、アクセス制御の観点も重要です。

署名付きURLとトークン認証

HLSでは、m3u8ファイルや各セグメントのURLに対して署名付きURL（Signed URL）やトークン認証を容易に組み込めます。例えば以下のような仕組みが一般的です。

• ログインユーザーにのみ有効期限付きのm3u8 URLを発行する
• URLに含まれるトークンをサーバー側で検証し、不正なアクセスを拒否する
• 同一URLの多重使用や地域外アクセスをブロックする

DRM（デジタル著作権管理）との統合

HLSはAppleのFairPlay、Google Widevine、Microsoft PlayReadyといった主要DRMシステムと統合可能です。これにより、暗号化された状態でセグメントを配信し、正規のプレイヤーだけが復号できる仕組みを実現できます。

6. MPEG-DASHとの比較

HLSと並んでよく使われるのがMPEG-DASH（Dynamic Adaptive Streaming over HTTP）です。両者はコンセプトが非常に近く、どちらもアダプティブビットレートストリーミングを実現しますが、いくつかの違いがあります。

近年はHLSのセグメント形式としてfMP4（Fragmented MP4）が採用されるケースも増えており、DASHとの差異は縮まっています。

7. パフォーマンスログからのm3u8検出という手法

WebブラウザのChrome DevToolsやSeleniumなどの自動化ツールでは、パフォーマンスログ（performance log）を通じてネットワーク通信の詳細を取得できます。動画プレイヤーがm3u8 URLへアクセスする際のリクエストもこのログに記録されます。

ログから読み取れる通信の流れ

1. ブラウザが動画ページを読み込む
2. JavaScript製プレイヤー（HLS.jsやVideo.jsなど）が動作を開始
3. プレイヤーがAPIやページ内スクリプトからm3u8 URLを取得
4. m3u8ファイルへのHTTPリクエストが発生
5. パフォーマンスログにそのURLが記録される

この仕組みは、Webアプリケーションのデバッグや通信解析に広く活用される正当な技術です。ブラウザの開発者ツールの「Network」タブでも同様の情報が確認できます。

8. セッションとCookieの引き継ぎが必要な理由

HLSのセグメントURLにトークン認証が設定されている場合、m3u8ファイルを取得したのと同じセッション（CookieやAuthorizationヘッダー）を、セグメントのリクエストにも引き継ぐ必要があります。

認証付きHLS配信の典型的な構成

クライアント
  │
  ├─ [1] ログイン → セッションCookie取得
  │
  ├─ [2] GET /video/xxx/master.m3u8
  │        └─ Cookie: session=... → サーバーが認証確認
  │
  ├─ [3] GET /video/xxx/720p/playlist.m3u8
  │        └─ 同じCookieが必要
  │
  └─ [4] GET /video/xxx/720p/segment_001.ts
           └─ 同じCookieが必要（なければ403エラー）

この設計により、認証されたセッションを持つユーザーだけが動画セグメントを取得できる仕組みが成立しています。

9. ffmpegによるセグメント結合の仕組み

HLSのTSセグメントを結合して単一の動画ファイルを生成する際、ffmpegが広く使われます。ffmpegのconcatデマルチプレクサは、複数のファイルを列挙したリストを読み込み、再エンコードなしにコンテナを結合（コピーモード）できます。

concatモードの動作原理

ffmpegはファイルの拡張子ではなく、バイト列の先頭（マジックバイト）でフォーマットを自動検出します。そのため、中身がMPEG-2 TSストリームであれば、ファイル名が .jpeg であっても正しく処理されます。

• -f concat：結合モードを指定
• -safe 0：絶対パスや外部パスを許可
• -i file_list.txt：結合するファイルのリストを指定
• -c copy：再エンコードせずにストリームをコピー

再エンコードなしのコピーモードは、画質劣化がなく処理速度も非常に高速なため、ストリーミングセグメントの結合に最適な手法です。

まとめ

動画配信サービスがmp4を直接置かずにHLSストリーミングを採用する理由は、単一の技術的課題ではなく、複数の要因が絡み合っています。

HLSは「シンプルなHTTPを使って動画を効率よく届ける」という目的に対して非常にエレガントな設計を持つプロトコルです。m3u8・TSセグメント・ABR・DRMといった技術スタックの理解は、Web開発者やインフラエンジニアにとって現代の動画配信を理解する上で不可欠な知識と言えるでしょう。

補足：大手サービスが実際に使っている技術スタック

ここまで解説してきた技術が、実際の大手サービスでどのように組み合わされているかを整理します。「うちのサービスはこうなっている」とエンジニアブログや公式ドキュメントで公開されている情報をもとにまとめました。

YouTube

YouTubeはデバイスによってプロトコルを使い分けています。Chrome・Firefox・EdgeなどのデスクトップブラウザではMPEG-DASHが主プロトコルとして採用されており、iOS・Safari向けにはHLSを使用しています。

YouTubeがDASHのセグメント長を短く設定しているのは、回線速度の変化により素早く対応するためで、モバイル環境でのバッファリング発生率を最大30%削減する効果があるとされています。

Netflix

Netflixはコンテンツ保護に特に力を入れており、マルチDRM構成が特徴的です。プロトコルはAndroid・ウェブ向けにMPEG-DASH、Apple製品向けにHLSを使用し、DRMはデバイスに応じてWidevine・FairPlay・PlayReadyを使い分けます。

Netflixの特徴的な取り組みとして「per-title encoding（コンテンツごとの最適エンコード）」があります。アニメのように動きが少ないコンテンツには低ビットレートでも高品質を維持でき、アクション映画には高ビットレートを割り当てるという、コンテンツの特性に合わせたエンコード戦略を採用しています。

Twitch

ゲーム配信に特化したTwitchは、配信者（ストリーマー）からのアップロードとの視聴者への配信でプロトコルを分けています。

Twitchは受け取ったRTMPストリームをリアルタイムで複数のHLSバリアントにトランスコードしています。60fpsのゲーム映像をリアルタイムで6種類の品質に変換しながら世界中に配信するという処理は、技術的に非常に高度な仕組みです。

AbemaTV（日本）

サイバーエージェントが運営するAbemaTVも、HLSベースのストリーミングに独自のライセンス認証システムを組み合わせています。プレミアムコンテンツにはデバイス認証トークンを用いた独自の暗号化方式を採用しており、m3u8のURLとは別に専用のライセンスAPIへのリクエストが発生する構成になっています。

サービス別技術スタック早見表

ポイント：プロトコルの選択はサービスによって異なりますが、「HLSかDASH（またはその両方）を使い、CDNで分散配信し、必要に応じてDRMで保護する」という基本構成はすべてのサービスに共通しています。