「MP4」はもう時代遅れ？ AWSで構築する、YouTube並みの「爆速ストリーミング配信（HLS）」基盤

前回の記事では「画像の重さ」を解決しましたが、Webサイトを遅くするもっと大きな犯人がいます。
**動画（Video）**です。

多くのサイトが、数10MBあるMP4ファイルをそのまま video タグで貼り付けています。これは、ユーザーに「巨大な弁当箱を全部受け取るまで、一口も食べるな」と言っているようなものです。

YouTubeやNetflixが、なぜ一瞬で再生開始できるのか？ なぜ、電車のトンネルに入って回線が遅くなっても止まらずに画質だけ落として再生し続けられるのか？

それは、彼らがMP4ではなく**「HLS (HTTP Live Streaming)」という技術を使っているからです。
本記事では、AWS MediaConvert を活用し、あなたのサイトにYouTube同等の爆速動画配信基盤**を構築する手法を解説します。

---

第1章：なぜ「MP4」ではダメなのか？

従来の動画配信（MP4のプログレッシブダウンロード）と、ストリーミング配信（HLS）には決定的な違いがあります。

❌ MP4配信の弱点

• 初動が遅い: 動画のメタデータや大きな塊をダウンロードしないと再生が始まりません。
• 無駄な通信費: ユーザーが「最初の10秒」しか見なくても、裏側では動画全体（50MBなど）をダウンロードしてしまうことがあり、サーバーの転送量コスト（AWS課金）が無駄になります。
• 画質が固定: 4K動画を貼ると、スマホの遅い回線ではカクカクして見られません。

⭕️ HLS配信の革命（細切れにする）

HLSは、動画を**「5秒ごとの小さな切り身（チャンク）」**に分割します。

• 再生まで0.5秒: 「最初の5秒分（数KB）」だけ読み込めば再生できるため、待ち時間がほぼゼロになります。
• Adaptive Bitrate (ABR): これが最強の機能です。
  • Wi-Fi環境: 高画質（1080p）の切り身をダウンロード。
  • 電車内（4G）: 回線が遅くなったら、自動的に低画質（360p）の切り身に切り替える。 ユーザーは「止まる」ことなく、シームレスに視聴を続けられます。

---

第2章：AWS MediaConvert で作る「自動変換工場」

画像処理には「Sharp × Lambda」を使いましたが、動画処理には餅は餅屋、AWS Elemental MediaConvert を使います。 プロ仕様のトランスコード（変換）サービスです。

アーキテクチャ構成

1. Input: 管理者が movie.mp4 をS3（アップロード用バケット）に置く。
2. Transcode: 自動でLambdaが起動し、MediaConvertにジョブを投げる。
3. Process: MediaConvertが以下の処理を行う。
   • 動画を .m3u8（プレイリスト）と .ts（動画の切り身）に分割。
   • 1080p, 720p, 360p の3種類の解像度を同時に生成。
4. Output: 公開用S3バケットに保存され、CloudFront経由で配信される。

エンジニアが見るべき「プレイリスト (.m3u8)」の中身

HLSの実体は、ただのテキストファイルです。

Plaintext

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1920x1080
1080p.m3u8  <-- 回線が速い人はこれを見ろ
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p.m3u8   <-- 回線が遅い人はこっちを見ろ

プレイヤー（video.jsなど）がこの指示書を読み、今の通信速度に合わせて最適なファイルを勝手に選んでくれます。

---

第3章：フロントエンドの実装 (Next.js)

画像は next/image でしたが、動画は標準の <video> タグではHLSを再生できません（Safariを除く）。 Video.js や Hls.js などのライブラリを使います。

例）JavaScript

// HLS再生コンポーネントの例 (React)
import { useEffect, useRef } from 'react';
import Hls from 'hls.js';

export default function HlsVideo({ src }) {
  const videoRef = useRef(null);

  useEffect(() => {
    const video = videoRef.current;
    if (Hls.isSupported()) {
      const hls = new Hls();
      hls.loadSource(src); // .m3u8ファイルを指定
      hls.attachMedia(video);
    }
  }, [src]);

  return <video ref={videoRef} controls />;
}

これで、あなたのサイトの動画プレイヤーは、通信状況に応じて画質が自動で切り替わる「高機能プレイヤー」に進化します。

---

第4章：コストメリットとUX

「動画配信システムなんて構築したら高いのでは？」と思われがちですが、実は逆です。

1. 通信コスト削減: MP4配信では「見られていない部分」までダウンロードされますが、HLSなら**「ユーザーが見た秒数分」**しか通信が発生しません。大規模サイトほど、VercelやAWSの転送量課金を削減できます。
2. 離脱率の低下: 「再生ボタンを押して即始まる」。この体験は、LP（ランディングページ）や商品紹介動画において、コンバージョン率に直結します。

---

まとめ：動画も「アセット」から「ストリーム」へ

前回解説した「画像のAVIF化」と、今回の「動画のHLS化」。 この2つを揃えることで、あなたのサイトのメディア体験は**「重いデータをダウンロードさせる」ものから、「必要な分だけ流し込む（ストリーミング）」**ものへと変わります。

• 画像: Sharp × AVIF
• 動画: MediaConvert × HLS

これが、現代のWebパフォーマンスにおける「アセット配信の最適解」です。 ユーザーを「待機時間」から解放しましょう。

---

👇 【画像編】まだJPGを使っていますか？

【AWS】重い画像を自動で軽くする「画像パイプライン」

動画の前に、まずは基本となる「画像」を最適化しましょう。 Node.js最速のSharpを使って、画質を落とさずにサイズを半分にする手法はこちら。

👉 記事を読む：AWS Lambdaによる画像最適化パイプライン

:::

👇 【UX編】0.1秒の待ち時間が命取り

【心理学】Amazonはなぜ「0秒」で切り替わるのか？

メディアを軽量化した後は、それを「いつ」読み込むか。 ユーザーの脳をハックする「知覚パフォーマンス」の設計論。

👉 記事を読む：知覚パフォーマンスと3つの実装パターン :::

---

👉 記事を書いた人