Web再生に適した動画コーデックの選び方

コーデック選びは、単なる圧縮の判断ではなくプロダクト上の判断です

動画コーデックは、雑に語られがちです。誰かが AV1、H.264、VP9、HEVC を表で比較し、最もファイルサイズが小さいものを指して勝者だと宣言する。実運用のWeb再生は、そのようには動きません。

コーデックの判断は、起動時間、バッファリング、バッテリー消費、CDNコスト、デバイス互換性、エンコード基盤、法的リスク、サポート問い合わせに影響します。大規模なエンコードファームを持つストリーミングサービスにとっての「最良」のコーデックが、5本の商品動画を載せるマーケティングサイトにとっても最良とは限りません。

有用な問いは「どのコーデックが最良か？」ではありません。こうです。この視聴者に対して、最も少ない運用リスクで良好な再生を提供できるコーデックはどれか？

短く言うと：2026年に何を使うべきか

多くのWebチームにとって、実践的な答えは次のようになります。

• H.264 をベースラインとして使う。 古い形式ですが十分に効率的で、広くハードウェアデコードされており、今でも最も安全な互換レイヤーです。
• 動画量や帯域コストが見合う場合は AV1 を追加する。 AV1 は特に低ビットレートで優れた圧縮を実現できますが、エンコードは遅く、古いデバイスではフォールバックが必要になる場合があります。
• VP9 は、主に視聴者やパイプラインがすでにそれに向いている場合に使う。 WebM ワークフローや一部の Android／デスクトップ環境では今も有用ですが、将来を見据えたオープンなコーデックとしては AV1 のほうが有望です。
• Webでの HEVC 利用は慎重に。 Apple ユーザーが多い視聴者には魅力的な場合がありますが、ブラウザ／プラットフォーム対応やライセンスの複雑さにより、汎用的なデフォルトとしては適していません。

保守的に聞こえるかもしれません。実際そうです。動画の失敗は目立ちます。再生が壊れたとき、ユーザーは圧縮率の高さを評価してくれません。

主要な4つのWebコーデックを理解する

H.264：今なお重要な、退屈なデフォルト

AVC とも呼ばれる H.264 は、Webにおける最も安全な動画ベースラインであり続けています。デスクトップブラウザ、モバイルブラウザ、スマートTV、古いデバイス、ソーシャル埋め込み、ネイティブアプリのWebViewなど、ほぼどこでも再生できます。

強みは明快です。

• 非常に広い対応範囲
• 成熟したエンコードツール
• 信頼性の高いハードウェアデコード
• モバイルでの良好なバッテリー挙動
• 予測しやすいストリーミング対応

弱点も明確です。AV1 や HEVC ほど圧縮効率は高くありません。同じ品質レベルでは、H.264 は通常より多くのビットを必要とします。大量の動画を配信する場合、その差は実際のCDNコストとして効いてきます。

それでも、短いクリップ、商品動画、ドキュメント動画、低〜中程度のトラフィックのサイトでは、H.264 が最初に作るエンコードとしてたいてい適切です。

AV1：効率的だが現実的なトレードオフがあるコーデック

AV1 は、現代のWeb配信において最も有力なオープンコーデックの選択肢です。同じビットレートで H.264 や VP9 より高い品質を提供することが多く、特に低帯域のユーザーに有利です。そのため、ストリーミングプラットフォーム、メディア中心のパブリッシャー、教育サイト、転送コストを真剣に見ているチームにとって魅力があります。

ただし AV1 は無料ではありません。近年のエンコーダーやハードウェアアクセラレーションにより大きく改善されたとはいえ、エンコードの計算コストは高めです。再生対応もデバイスに依存します。新しいデスクトップ、Android デバイス、TV は対応が進んでいますが、古いスマートフォンやノートPCでは効率的なハードウェアデコードがない場合があります。

実践的なルールはこうです。AV1 は追加のレンディションとしては優秀ですが、唯一のレンディションにすべきではありません。 再生環境を厳密に制御できる場合を除き、H.264 のフォールバックと組み合わせましょう。

この判断は静止画像形式の選択に似ています。より良い圧縮は、対応状況、エンコード時間、品質が現実世界で成立して初めて有用です。同じトレードオフの考え方は、AVIF と WebP のような画像形式の判断にも当てはまります。

VP9：今も有用だが、以前ほど魅力的ではない

VP9 は、AV1 が成熟する前の主要なオープン代替でした。H.264 より大幅に効率的になり得るうえ、多くの Chromium ベースブラウザ、Firefox、Android 環境、一部のTVプラットフォームで堅実に対応されています。

VP9 が今も意味を持つのは、次のような場合です。

• すでに VP9 のエンコードパイプラインがある
• 視聴者の多くが Chrome、Firefox、Android、またはスマートTVである
• WebM 配信が必要である
• AV1 のエンコードコストがまだ許容できない

ただし、2026年に新しいパイプラインを作るなら、VP9 を長期的な高度コーデックとして正当化するのは難しくなっています。H.264 を超えるなら、通常は AV1 のほうが戦略的に有利です。

HEVC：技術的には強いが、運用上は扱いにくい

H.265 とも呼ばれる HEVC は効率的で、一部のエコシステムでは広く使われています。特に Apple デバイスではハードウェア対応が一般的なため重要です。

問題は品質ではありません。問題はWebでの実用性です。ブラウザ対応は歴史的に断片的で、ライセンスはオープンコーデックより複雑であり、クロスプラットフォームでの挙動も均一とは限りません。HEVC は Apple ユーザーが多い視聴者や、ネイティブアプリに近いワークフローでは賢い追加選択肢になり得ますが、汎用的なWebのデフォルトとして最もすっきりした選択肢であることはめったにありません。

分析データで Safari／iOS／macOS が非常に多いと分かっているなら、HEVC を試す価値はあります。広いWeb向けに高度なコーデックを1つ選ぶなら、AV1 を優先しましょう。

コーデック表ではなく、視聴者から始める

形式を選ぶ前に、自社の分析データから3つの質問に答えましょう。

1. 実際に動画を視聴しているブラウザとデバイスは何か？ デスクトップの Chrome は、ローエンドの Android、iPhone 上の Safari、アプリ内ブラウザ、スマートTVとは同じではありません。
2. 動画の長さはどれくらいか？ 12秒のヒーローループと90分の授業動画では、経済性が大きく異なります。
3. ユーザーは実際にどれくらい動画を消費しているか？ ページビューは視聴時間ではありません。帯域削減が最も効くのは、コーデックの差が意味を持つだけの秒数を人々が視聴する場合です。

動画トラフィックが軽いなら、適切に圧縮された H.264 MP4 で十分かもしれません。動画がプロダクトの中心なら、複数のレンディションと現代的なコーデックを使いましょう。

コーデック選択を配信モデルに合わせる

シンプルな埋め込み動画

少数の動画を持つ小規模サイトでは、次から始めましょう。

• H.264 動画
• AAC 音声
• MP4 コンテナ
• 妥当な解像度とビットレート
• ポスター画像
• 適切な場所での遅延読み込み

この組み合わせは華やかではありませんが、機能します。必要に応じて、MP4 フォールバックの前に WebM ソースとして AV1 または VP9 を追加できます。

<video controls preload="metadata" poster="poster.jpg">
  <source src="demo-av1.webm" type="video/webm; codecs=av01.0.05M.08">
  <source src="demo-h264.mp4" type="video/mp4; codecs=avc1.4d401f, mp4a.40.2">
</video>

ブラウザは再生できる最初のソースを選びます。開発用ノートPCだけでなく、実機でテストしてください。

ストリーミングと長尺再生

長いコンテンツでは、単一のコーデックよりもアダプティブビットレートストリーミングのほうが重要です。HLS と MPEG-DASH により、プレーヤーはネットワークやデバイスの状況に応じて品質レベルを切り替えられます。

実践的なストリーミングラダーには、次のようなものを含めます。

• 広い互換性のための H.264 レンディション
• 対応する現代的なクライアント向けの AV1 レンディション
• 複数の解像度とビットレート
• 有用な場合は分離された音声レンディション
• 起動と切り替え挙動に合わせて調整されたセグメントサイズ

コーデック選択とビットレートラダー設計は、あわせてテストすべきです。ある1つのビットレートで美しい AV1 エンコードができても、起動が遅い、セグメントが大きすぎる、中位のデバイスでデコードが苦しいなら役に立ちません。

ハードウェアデコードを無視しない

ソフトウェアで対応しているコーデックと、うまく対応しているコーデックは同じではありません。ソフトウェアデコードはCPU使用率を上げ、バッテリーを消費し、フレーム落ちを引き起こす可能性があります。これは特にモバイルユーザー、バッテリー駆動のノートPC、4K再生で重要です。

テスト時には、次を確認しましょう。

• CPU と GPU の使用率
• バッテリー消費
• フレーム落ち
• ノートPCのファン音
• スマートフォンの発熱
• 起動遅延
• シークの応答性

ここでは「最高の圧縮」が「十分に良く、ハードウェアデコードされる」ものに負けることがあります。古いハードウェアでユーザーのバッテリーを消耗させる小さな AV1 ファイルより、滑らかに再生される大きめの H.264 ファイルのほうが優れている場合があります。

チームが認める以上に、ビットレートは重要です

コーデック選択は、雑なビットレートラダーを救ってはくれません。多くのWeb動画が無駄に重いのは、制作マスター用の設定で書き出され、まともな配信計画なしにアップロードされているからです。

H.264 SDR のWeb再生における大まかな出発点は次のとおりです。

• 720p：約 2〜4 Mbps
• 1080p：約 4〜8 Mbps
• 4K：約 12〜25 Mbps

AV1 と HEVC は、同程度の知覚品質でさらに低くできることがよくありますが、コンテンツによって変わります。トーキングヘッドの映像は、ゲームキャプチャ、画面録画、アニメーション、スポーツ、粒状感のあるフィルムとは圧縮のされ方が異なります。

必ず目視でテストしましょう。圧縮指標は役立ちますが、その動画が許容できるかどうかを決めるのは人間の知覚です。

コンテナと MIME type も仕事の一部です

コーデックはファイル形式ではありません。H.264 は一般に MP4 で配信されます。AV1 は、対象の対応状況やパイプラインに応じて WebM または MP4 で配信される場合があります。VP9 は一般に WebM です。音声コーデックの選択も重要です。AAC は今も MP4 音声の安全なデフォルトであり、Opus は WebM ワークフローで優れています。

正しい MIME type を配信してください。レンジリクエストが機能することを確認しましょう。キャッシュは意図的に設定します。壊れたヘッダーは、動画のシークを失敗させたり、不要な再ダウンロードを強制したりします。動画がローカルと本番で異なる挙動をする場合は、実際の HTTP レスポンスを調べてください。本番環境でリダイレクトと HTTP ヘッダーをデバッグするときのアプローチは、メディア配信にもそのまま当てはまります。

ページ速度だけでなく、再生を測定する

一般的なパフォーマンススコアは重いページを示すことはできますが、動画体験を完全には説明できません。動画固有のシグナルを追跡しましょう。

• 最初のフレームまでの時間
• 起動遅延
• 再バッファリング率
• 配信された平均ビットレート
• フレーム落ち
• ブラウザとデバイス別のエラー率
• 視聴時間と離脱ポイント

ページ監査は、周辺の問題を見つけるうえでは今も有用です。大きすぎるポスター、レンダリングをブロックするスクリプト、不適切な遅延読み込み、プレーヤー周辺のレイアウトシフトなどです。チームが Lighthouse を最初の確認に使っているなら、それを判決ではなく優先順位付けの道具として読みましょう。特にメディアの多いページでは、Lighthouse レポートには解釈が必要です。

実践的な判断ツリー

出発点として使ってください。

1. 最大限の互換性が必要か？ H.264 MP4 を使う。
2. ユーザーごとに多くの分数の動画を配信するか？ 対応している環境向けに AV1 レンディションを追加する。
3. 視聴者の多くが Apple デバイスか？ HEVC を追加レンディションとして検討する。ただし唯一の選択肢にはしない。
4. すでに VP9 に投資しているか？ うまく機能しているなら維持する。根拠なしに急いで移行しない。
5. 長尺または変動の大きいネットワークか？ 1つのコーデックにこだわる前にアダプティブストリーミングを使う。
6. ローエンドのモバイル視聴者が多いか？ ハードウェアデコードされる形式と控えめなビットレートを優先する。
7. 短い装飾動画か？ そもそも動画であるべきかを検討する。静止画像、アニメーション、より短いループのほうが良い場合があります。

<!-- tool-cta:start -->

💡 お試しください: Video Converterでさまざまなコーデックがあなたのコンテンツでどのような結果になるかをテストし、一般的なベンチマークではなく実際の出力に基づいて判断できるようにしましょう。

<!-- tool-cta:end -->

健全なデフォルトの推奨

今日、Web動画パイプラインを構築または刷新するなら、ここから始めましょう。

• 信頼できる H.264/AAC MP4 フォールバックをエンコードする。
• 恩恵を受けるブラウザとデバイス向けに AV1 を追加する。
• 長尺コンテンツにはアダプティブストリーミングを使う。
• 古いハードウェアやローエンドのハードウェアを含め、実機でテストする。
• リリース後に再生エラーとバッファリングを監視する。

コーデック選択は一度きりの宣言ではありません。保守の判断です。ブラウザ対応は改善し、ハードウェアは変わり、エンコードツールは速くなり、視聴者も移り変わります。定期的に判断を見直しましょう。ただし、新しいコーデックの発表をすべて追いかける必要はありません。適切なコーデックとは、ユーザーが無駄な帯域を使わず、配信スタックを脆くすることなく、許容できる品質で滑らかに再生できるものです。