M3U8はHLS(HTTP Live Streaming)プロトコルが使うUTF-8テキストプレイリストです。ファイル自体には映像フレームは含まれず、動画セグメント(.tsまたは.m4s)のURL、各セグメントの長さ、利用可能なビットレートバリアントを列挙したマニフェストです。プレーヤーは.m3u8を読み、順番にセグメントを取得し、リアルタイムに縫い合わせて再生可能な動画ストリームに組み立てます——これがYouTube・Netflix・Twitch・Apple TV+など、2026年の主要なストリーミングサービスを支える中核メカニズムです。
ストリーミングサイトから動画を保存しようとして、1つの整った.mp4ではなく数百個の小さな.tsファイルになってしまったことはありませんか?あるいはブラウザのNetworkタブを開いてクリーンなダウンロードURLを期待したのに、代わりに2秒チャンクが延々と流れ込んでくる光景に出会ったことは?何も間違ったことはしていません。あなたが見ていたのはHLS、現代ウェブのストリーミング動画の大半を配信するプロトコルです。HLSは動画を単一のファイルとしては配信しません。レシピと部品として配信するのです。
レシピは.m3u8プレイリストと呼ばれる小さなテキストファイル。部品は短く独立にデコード可能な動画セグメントで、プレーヤーが走りながら縫い合わせます。HLSはAppleが2009年に初代iPhone向けに作り、RFC 8216として標準化されました。今ではほぼすべての主要ブラウザ、モバイル端末、テレビでネイティブにサポートされています。
このガイドでは、.m3u8に実際に何が入っているのか、なぜストリーミングサービスがこの設計を選んだのか、.tsとfMP4セグメントがどう組み合わさるか、2026年時点でどのプラットフォームがHLSを使っているか、そしてこれらのストリームをディスクに保存しようとしたときに何が起こるかを順に見ていきます。
重要ポイント {#key-takeaways}
- HLSはストリーミングプロトコルであり、ファイル形式ではない。 プレイリスト(
.m3u8)と短いセグメント(.tsまたはフラグメント化MP4)として、素のHTTP上で動画を配信する。 .m3u8はインデックスであって動画ではない。.m3u8ファイルだけを保存しても、材料のないレシピが手に入る。- AppleがiPhone向けに2009年にHLSを作り、2017年にRFC 8216として標準化した。今ではiOS/Safariで必須、他のほぼすべての場所でもサポートされている。
- セグメントは2〜10秒。バリアントを切り替えるには十分短く、HTTPオーバーヘッドを抑えるには十分長い。
- マスタープレイリストがバリアントを列挙し、メディアプレイリストがセグメントを列挙する。 プレーヤーはまずマスターを読み、バリアントを選び、そのバリアントのメディアプレイリストをロードする。
.tsセグメントはフラグメント化MP4(CMAF)に置き換えられつつあり、同じファイルが1つのオリジンからHLSとDASHのプレーヤー両方に配信できる。- 現代ストリーミングのほとんどはHLSかDASHに乗っている、しばしば両方を同時に。YouTube・Netflix・Disney+・Twitch・Apple TV+・Cloudflare Streamを含む。
M3U8 vs MP4:主要な違いの比較
多くの人が初めて.m3u8に出会うのは、動画をダウンロードしようとして、見慣れた.mp4の代わりに小さなテキストファイルが手に入ったときです。この2つは同じワークフローで頻繁に登場しますが、根本的に種類が違います——一方はプレイリスト(マニフェスト)、もう一方はコンテナです。日常的に検索される違いを以下の表にまとめました。
| 観点 | M3U8(HLSプレイリスト) | MP4(動画コンテナ) |
|---|---|---|
| 本質 | UTF-8テキストプレイリスト(マニフェスト) | 自己完結型のバイナリ動画コンテナ |
| 保存形態 | 1つの.m3u8 + 数十〜数百個の.ts/.m4sセグメント | 単一の.mp4ファイル |
| ファイルサイズ | マニフェストは数KB;セグメント合計は同画質のMP4とほぼ同等 | 動画全体が1ファイル |
| 画質切り替え | アダプティブビットレート対応(複数バリアントを即時切替) | 単一画質に固定 |
| ライブ配信 | ネイティブ対応(マニフェストに新セグメント追加可) | ライブには不向き |
| シーク | セグメント境界で即時シーク | サーバーのHTTP Range対応が必要 |
| 暗号化 | AES-128セグメント暗号化+FairPlay/WidevineなどのDRM層 | デフォルトでは暗号化なし、必要ならDRMを後付け |
| プレーヤー要件 | HLS対応プレーヤーが必要(Safari、VLC、IINA、hls.jsなど) | ほぼすべてのプレーヤーがネイティブ再生可 |
| 典型的な用途 | Netflix、YouTube、Twitch、Apple TV+などのオンライン配信 | ローカル再生、ダウンロード、編集、メール添付 |
| オフラインで使うなら | 全セグメントをプレイリスト順に1つのMP4へ結合する必要あり | すでに共有可能な成果物ファイル |
ひと言でまとめると:M3U8は「目次」、MP4は「完成したファイル」。 オンラインで視聴するときブラウザが受け取るのはM3U8マニフェストで、必要に応じてセグメントを取りに行きます。オフラインで長期保存したい、友人と共有したいなら、最終的にセグメントをMP4へ戻すのが一般的な流れです。
シンプルな説明
少しの間プロトコルのことを忘れてください。世界中の視聴者に、不安定なインターネット越しに完成した映画を届ける必要のある監督を想像してみてください。1つの巨大MP4を送るのは無理です。視聴者の接続が途中で切れたらゼロからやり直し、画質を切り替えるには再ダウンロードしかありません。そこで代わりに、監督は映画を数百本の6秒クリップに切り、「クリップ001を再生、次に002、その次に003……」と指示する番号付きのプレイリストを書きます。視聴者のプレーヤーはプレイリストをダウンロードし、最初の数本のクリップを取得し、後ろから残りが流れ込む間に再生を始めます。接続が遅くなれば、フレームを落とすことなく次のクリップを低画質バージョンに切り替えます。
これが一文でのHLSです。映画を短いクリップに切り、次にどのクリップを再生すべきかをプレーヤーに伝える.m3u8プレイリストファイルを添えたもの。
視聴者の席から見ると、この設計は多くの魔法を隠しています。シークが瞬時なのは、プレーヤーがファイル全体を流すのではなく、対象タイムスタンプをカバーするセグメントに直接ジャンプできるから。画質の変化がスムーズなのは、再生を再起動せずに次のセグメントだけ別バリアントから取れるから。バッファリングが穏やかなのは、ファイルの大きな塊を事前にダウンロードする必要がなく、数セグメント先(通常10〜30秒)だけ確保すればよいから。そしてライブストリーミングが成立するのは、配信者が生成するにつれて新しいセグメントをプレイリストに追加でき、プレーヤーが数秒ごとに新規エントリを求めて.m3u8をポーリングできるから。
YouTubeやNetflixのストリームがWi-Fiの揺れに合わせて滑らかに持ち直すのに、適当なサイトからの直接MP4ダウンロードが停滞して死ぬ理由を不思議に思ったことがあれば、これが答えです。スタック全体は、インターネットは乱雑で接続は出入りするものだ、という前提のうえに設計されています。プレーヤーが走りながら画質を適応する仕組みの長い議論は別記事にゆずるとして、ここではセグメント+プレイリストの設計こそが、その適応を可能にしているのだということに注目してください。
HLSは実際どう動くのか
HLSストリームは2層のプレイリストと、大量のセグメントの集合体で、すべてが普通のHTTP上で配信されます。 風変わりなものは何もなく、独自プロトコルもありません。あなたのブラウザはすでにこれらすべての部品を扱う方法を知っています。
マスタープレイリスト
プレーヤーが最初に取得するのはマスタープレイリストです。.m3u8拡張子の小さなテキストファイルで、ストリームの利用可能なバリアント(通常は異なる画質レベル)と、それぞれの帯域・解像度が列挙されています。軽く整形したリアルな例はこんな形です。
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480,CODECS="avc1.4d401e,mp4a.40.2"
480p/index.m3u8
#EXTM3U行はこのファイルが拡張M3Uプレイリストであることを示します。#EXT-X-VERSION:6は使われているHLSプロトコルのバージョンを宣言します。各#EXT-X-STREAM-INFブロックは1つのバリアントを記述します。ビットレート・解像度・コーデック文字列が並び、その下にそのバリアントの2段目のプレイリストを指すURLが置かれます。プレーヤーはこのファイルを読み、帯域を推定し、維持できると判断したバリアントを選びます。
メディアプレイリスト
プレーヤーがバリアントを選ぶと、そのバリアントのメディアプレイリストを取得します。ここに実際のセグメントURLが並びます。
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.000,
segment000.ts
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST
#EXT-X-TARGETDURATION:6は、どのセグメントも6秒を超えないことを宣言します。各#EXTINF:6.000,行は1つのセグメントの正確な尺を示し、続いてセグメントURLが並びます。#EXT-X-ENDLISTはプレーヤーにこれがVODストリームであることを伝えます。これ以上セグメントが追加されることはありません。ライブストリームでは#EXT-X-ENDLISTが省略され、プレーヤーは数秒ごとにこのプレイリストを再要求して新しいセグメントを発見します。
セグメント:.tsとfMP4
セグメントは音声と映像の短いチャンク(通常2〜10秒)で、プレーヤーが任意のセグメント先頭からデコードを開始できるよう、キーフレーム境界で切られています。プレイリストが#EXT-X-INDEPENDENT-SEGMENTSを宣言している場合、すべてのセグメントは単独で再生可能であることが保証されます。そのフラグがなければ、後続のセグメントは先行セグメントの情報に依存する場合があります。歴史的にはセグメントは.ts拡張子のMPEG-2 Transport Streamファイルです。衛星・ケーブルTVを配信するのと同じコンテナ形式です。MPEG-TSはノイズの多い放送チャネル向けに設計されているので部分的な破損に強く、.tsパケットをデコードできるプレーヤーならHLSセグメントを再生できます。
典型的なセグメント尺は2〜10秒です。短いセグメントはレイテンシが低く、ビットレート切り替えが機敏になりますが、HTTPリクエスト数と分あたりのオーバーヘッドが増えます。長いセグメントは圧縮効率が良くリクエストが減りますが、帯域変化への反応が遅くなります。Appleの原仕様では10秒を推奨していましたが、現代のサービスは2〜6秒のあたりに落ち着いています。
2016年以降、業界は.tsからフラグメント化MP4セグメントへの移行を進めています。具体的にはCommon Media Application Format(CMAF)、ISO/IEC 23000-19として標準化されているものです。CMAFセグメントはMPEG-DASHと同じMP4フラグメンテーションを使うため、CDN上の1組のファイルでHLSとDASHの両プレーヤーに対応できます。これはストリーミングサービスにとって大きなコスト勝利です。1回のエンコード、1組のバイト、2つのプロトコル。YouTube・Netflix・Apple の最新HLSストリームはほぼすべてレガシーMPEG-TSではなくCMAFです。
隅から隅までHTTP
HTTP Live Streamingの「HTTP」がオチです。有線上に特別なプロトコルはなく、HLSのすべての部分はブラウザがHTMLやJPEGに使うのと同じHTTPSリクエスト上を旅します。CDNはこれを愛します。すでにHTTP向けに最適化されているからです。ファイアウォールはこれを通します。普通のものに見えるからです。CDNは人気セグメントをエッジでキャッシュできます。レンジリクエスト・gzip・HTTP/2・HTTP/3・TLS、すべて無料で動きます。
これがHLSが勝った理由でもあります。RTMP・RTSP・MMSのような旧来のストリーミングプロトコルは、専用ポート・ステートフルなサーバー・特別なファイアウォールルールを必要としました。HLSは大量の小さなファイルを配信しているウェブサイトに見えるだけです。
ほとんどのユーザーは手動で処理する必要はありません。VidMostが.m3u8マニフェストを解析し、セグメントを裏側でクリーンなMP4にマージしてくれます。
実世界でHLSに出会う場所
HLSは2026年の事実上すべての主要ストリーミングサービスに、しばしばDASHと並んで存在しています。 Appleは2009年に初代iPhoneに動画を届けるためにHLSを発明しました。当時の端末はセルラー回線上のプログレッシブダウンロードをうまく扱えず、キャリアからはHTTPトラフィックに見えるストリーミング形式を望んでいたのです。このプロトコルはその後、インターネットの巨大な一角のデフォルトになりました。
- Appleの自社サービスはHLS専用です。Apple TV+・iTunes Store・Apple Podcastsのポッドキャスト、Safari・iOS・tvOSで再生されるすべての動画はHLSの上に乗っています。AppleプラットフォームにはMPEG-DASHのビルトインデコーダーが入っていないため、iPhoneで再生したいサービスはHLSフィードを用意する必要があります。
- YouTubeは、ウェブとAndroidではMPEG-DASHをメインに使いつつ、iOS・Safari・AirPlay・大半のTVアプリにはHLSを配信します。SafariでYouTubeを開いてブラウザの開発者ツールを覗くと
.m3u8リクエストが見え、AndroidのChromeでは代わりにDASHの.mpdリクエストが見えます。 - Netflix・Disney+・Hulu・Max・Amazon Prime Videoはすべて両方を混在して使っています。スマートテレビとコンソールのアプリは多くがFairPlayまたはPlayReady DRMを伴うHLSを使い、ウェブプレーヤーはしばしばWidevineを伴うDASHに切り替わります。同じコンテンツでクライアントごとに違うプロトコル。
- Twitchは2014年に再生側でレガシーRTMPスタックを切り捨てて以来、HLSで動いています。Twitch上のあらゆるライブ配信とVODの裏側はHLSです。
- ライブカム・クリエイタープラットフォーム(Bigo Live・Chaturbate・OnlyFansライブ・Fanslyストリーム)は、プラグイン不要で動き、不安定な接続に耐えるという理由から、ブラウザ再生にはほぼすべてHLSを使っています。
- ホスト型動画プロバイダー(Vimeo・Mux・JW Player・Cloudflare Stream)はデフォルトでHLSを配信します。ウェブサイトがVimeoやMuxのiframeを埋め込んでいれば、その下の動画はほぼ確実にHLSです。
- スポーツとニュースの放送局(ESPN・BBC iPlayer・DAZN・Sling TV)はライブイベント配信にHLSを頼りにしており、しばしばDRMを上に重ねます。
HLSがiOS出自から脱皮したのは、Apple以外にとっても現実的な問題を解いたからです。2012年にDASHが登場するまでに、HLSはすでに広範なCDNサポート、現場で稼働するプレーヤー、そして勢いを持っていました。現在は両プロトコルが共存し、考えのあるストリーミングサービスは両方をサポートし、多くは同じCMAFセグメントを2つのマニフェスト形式の下で配信しています。DASHがHLSとどう比較されるかの詳細は、兄弟記事で隅から隅までカバーしています。
動画を保存したい場合に意味すること
HLSの仕組みを知ると、ある実用的な問題が突然明白になります。「右クリック→名前を付けて保存」でHLS動画をダウンロードすることはできません。 理由のいくつかは機械的なもの、いくつかは微妙なもの、そして1つ2つは驚きかもしれません。
- ブラウザの名前を付けて保存は
.m3u8しか保存しない。.m3u8はページが再生開始時に実際にダウンロードする小さなテキストファイル。これを保存しても、レシピは手に入っても料理は手に入りません。VLCでそのファイルを開くと動くことがあります(VLCは中のURLを追います)が、元のセッションがまだ有効でURLが失効していない間だけです。 - 各セグメントは別個のHTTPリクエスト。 6秒セグメントで30分の動画なら300本の別ダウンロードです。プレイリストを列挙し、各セグメントを取得し、1つの再生可能ファイルとして正しい順序で結合する必要があります。
- バリアント選択は本当の選択。 マスタープレイリストは複数の画質を列挙します。間違ったものを選ぶと、1080pで配信されていた映画の480pコピーが手に入ります。多くは、ストレージと忍耐が許す最高帯域のバリアントが正解です。
- HTTPSは伝送中のバイトを守り、ディスク上のバイトは守らない。 セグメントURLはほぼ常にHTTPSで配信されるので、ネットワーク上の盗聴者はストリームを読めません。しかし一度ブラウザにセグメントが届けば、それは平文の動画です。TLSは、レスポンスにすでにアクセスできるツールを止めません。
- HLSはコンテンツ層としてAES-128セグメント暗号化をサポートする。
.m3u8に#EXT-X-KEYタグがあるとき、各セグメントはAES-128で暗号化され、プレイリストはプレーヤーがHTTPSで取得するキーURLを指します。キーなしでセグメントだけ保存しても、暗号文のフォルダが手に入るだけです。これはコンテンツ暗号化でトランスポートセキュリティとは別であり、エンタイトルメントチェックは組み込まれていません。キーURL自体がゲートです。 - 商用DRMは別問題。 Netflix・Disney+・Apple TV+のようなプレミアムサービスは、HLSにFairPlay(Apple)・Widevine(Google)・PlayReady(Microsoft)を重ねます。有線上の暗号化は依然としてAESベースですが、キーはプレーヤーが信頼されたデバイス上でエンタイトルメントを証明したあとにのみライセンスサーバーが発行し、復号はハードウェアバックのセキュアモジュール内で行われ、フレームがアプリケーションメモリに触れることはありません。全体像はDRM保護コンテンツとは?をご覧ください。
- トークンと署名URLは失効する。 多くの
.m3u8とセグメントURLは数分で古くなる短命トークンで署名されています。手動でダウンロードをスクリプト化している間に、半分のリンクがすでに死んでいることもあります。
ここでVidMostが引き継ぐように作られています。VidMostは、あなたが正当な権利を持ってアクセスしているHLSコンテンツを、規約に沿って手元に残すために設計されています——自分の配信のアーカイブ、購入した有料講義、自由ライセンスやパブリックドメインの動画、商用DRMが掛かっていない企業研修素材、そして利用規約がダウンロードを許可している有料サブスクリプションコンテンツなどです。.m3u8マニフェストを解析し、利用可能な最高画質のバリアントを選び、ブラウザが話していたのと同じCDNから全セグメントを並列でダウンロードし、通常のAES-128セグメント暗号化を自動で扱い、完了後にセグメントを1つのクリーンなMP4ファイルにリマックスします。Netflix・Disney+・Apple TV+などのプレミアムサービスのように、FairPlay・Widevine・PlayReadyといった商用DRMで保護されたストリームは対象外です。各プラットフォームの利用規約とお住まいの地域の法律に必ず従ってください。それ以外については、ユーザーから見える体験は「規約に沿ったURLを貼る、MP4が得られる」——プロトコルレイヤーは消えます。
よくある落とし穴と誤解
HLSに関する誤解は、フォーラムスレッドで何度も繰り返し出てきます。整理する価値があります。
- 「.m3u8は動画ファイルではない。」 これはインデックスです。実際の動画はプレイリストが参照するセグメントの中にあります。ツールが「m3u8をダウンロードします」と言うなら、それがセグメントの取得と結合も行うかを確認してください。さもなければ役に立たないテキストファイルが残るだけです。
- 「.tsファイルはほとんどのプレーヤーで直接再生できない。」 1つのセグメントはVLCで数秒再生されるかもしれませんが、動画全体はフォルダ内の
.tsファイルの並びではありません。各々を順番にデコードして縫い合わせる必要のある並びです。HLSを話せないプレーヤーは、最高でも最初のセグメントを再生して止まります。 - 「HLSは常にライブを意味するわけではない。」 「HTTP Live Streaming」は2026年では誤解を招く名前です。HLSはVODでも同じくらいうまく動きます。同じプレイリスト、同じセグメント、有限ストリームを示す
#EXT-X-ENDLISTが付くだけです。Netflix・Disney+・Apple TV+のカタログコンテンツの大半はライブではなくVOD HLSです。 - 「高ビットレートは接続が落ちると必ずしも良い画質を意味しない。」 10Mbpsバリアントは光では美しく、3Mbpsのモバイルリンクでは惨めに途切れます。アダプティブ設計のポイントは、プレーヤーが接続が維持できるものを選ぶことです。手動で上書きすると、しばしば体験は悪くなります。
- 「ブラウザのダウンロードツールは通常HLSで失敗する。」 汎用の「動画ダウンローダー」拡張は、MP4ファイルを指す
<video src="...">タグを探します。HLSストリームはそういうURLを露出しません。プレーヤーはMedia Source Extensionsを使ってvideo要素にセグメントをプログラム的に供給します。マニフェストを解析する専用ツールが存在する理由はまさにこれです。
結びに
HLSは、あなたが見るほとんどの動画の下にある静かなインフラです。これが動くのは、トランスポートを巧妙にしようとするのをあきらめたからです。独自プロトコルも特別なサーバーもなく、.m3u8テキストファイルと.tsまたはfMP4セグメントを、ブラウザがすでに話せる同じHTTP上で取得するだけ。Appleは2009年に電話の問題を解き、偶然にも次の20年の支配的ストリーミング形式を作りました。
ブラウザのネットワークタブで.m3u8リクエストを認識し、プレイリストを読めるようになると、大量のストリーミング動作(短い画質切り替え、即時のシーク、「先読みバッファ」インジケータ、結局手にしてしまった奇妙な.tsファイルのフォルダ)の謎が消えます。全部同じループです。プレイリスト取得、バリアント選択、セグメント取得、デコード、繰り返し。
プロトコルレイヤーを完全に飛ばして単に動画を保存したい場合、VidMostはHLS・DASH・fMP4・DRM保護ストリームを処理します。
関連する読み物
- オンライン動画はどう再生されるのか? — カメラから画面までのパイプライン全体。
- MPEG-DASH vs HLS — 各プロトコルが勝つ場面と、なぜ多くのサービスが両方を配信するか。
- 動画の画質が再生中に変わるのはなぜ? — あらゆるHLSとDASHプレーヤーに組み込まれているABRロジック。
- 動画コンテナとコーデック —
.mp4・.ts・.m4sの中に実際に入っているもの。 - DRM保護コンテンツとは? — Widevine・FairPlay・PlayReadyが、保存できない暗号化バリアントをどうゲートするか。