MP4 vs WebM: 2026年のWeb動画に最適なフォーマットはどっち？
手っ取り早い答え（と、なぜ一筋縄ではいかないのか）
2026年のWebで動画フォーマットを1つだけ選ぶ必要があるなら、答えはH.264でエンコードされたMP4です。純粋な互換性では、今でもこれが最強です。あらゆるブラウザ、デバイス、スマートテレビで何の問題もなく再生できます。VP9やAV1でエンコードされたWebMは、同じファイルサイズでより優れた圧縮率と画質を提供しますが、いくつか厄介な点があります。SafariがAV1のハードウェアデコードに完全対応したのは2024年後半ですし、古いAndroidデバイスの一部ではVP9の再生がカクつくことがあります。 ほとんどの配信者にとって、本当の答えはシンプルです。両方を提供することです。WebMファイルをメインのソースとし、MP4をフォールバックとして用意すれば、99.8%のデバイスをカバーでき、品質と帯域幅の両方で最高の体験を提供できます。HTML5の<video>要素は、複数の<source>タグを使うことで、これを驚くほど簡単に実現してくれます。本当の複雑さはコードではなく、ロジスティクスにあります。エンコード時間、ストレージコスト、CDN料金、そしてそもそもCMSや動画プラットフォームが同じファイルの2つのバージョンをアップロードさせてくれるか、といったことを考慮しなければなりません。この記事では、そうしたトレードオフを実際の数値で解き明かし、理論上の理想ではなく、あなたの実際のワークフローに合った解決策を選ぶ手助けをします。
コーデックの分解：コンテナの中身を徹底解説
MP4とWebMは単なるコンテナです。圧縮された映像と音声ストリームを保持するZIPファイルのようなものだと考えてください。コンテナフォーマット自体よりも、その中で重労働をこなしているコーデックの方がはるかに重要です。 MP4ファイルには、ほぼ常にH.264 (AVC) 映像とAAC音声が含まれています。H.264は2003年からある古い規格ですが、20年以上にわたって改良が続けられてきました。4Mbpsの1080p H.264ストリームは、ほとんどの画面で素晴らしく見えます。MP4はH.265 (HEVC) もサポートしており、これは半分のビットレートで同等の品質を提供しますが、その採用はめちゃくちゃでした。ライセンス料がブラウザベンダーを躊躇させ、2026年半ばになっても、ChromeはすべてのプラットフォームでHEVCをネイティブにデコードしません。 GoogleはWebMを、Web向けのオープンでロイヤリティフリーなフォーマットとして設計しました。VP8、VP9、またはAV1コーデックを、VorbisまたはOpus音声と共に使用できます。VP9はH.264よりも同じ品質で30～50%優れた圧縮率を提供します。AV1はさらにその上をいき、YouTubeの内部テストでは、VP9と比較してさらに30%ファイルを小さくできることが示されています。しかし、その効率性には高い代償が伴います。それがエンコード時間です。最も遅く、最高品質のプリセット（cpu-used=0）では、libaomを使ったAV1エンコードは、標準的なH.264エンコードの50倍から100倍もの時間がかかることがあります。 実用的なWeb配信という観点から見ると、2026年においてはWebMのVP9がスイートスポットだと言えます。H.264を大幅に上回る圧縮率を得られ、かつ、専用のサーバーファームを必要としない、現実的に管理可能なエンコード速度を実現できます。
2026年におけるブラウザとデバイスのサポート状況
ブラウザのサポート状況は常に変化するターゲットです。2026年半ば時点での状況は以下の通りです。 MP4/H.264のサポート状況はシンプルです。ユニバーサル、つまり普遍的です。Chrome、Firefox、Safari、Edge、Opera、Samsung Internetなど、あらゆるプラットフォームの主要なブラウザがネイティブで対応しています。例外も注釈もありません。 WebM/VP9も広くサポートされており、Chrome (v29以降)、Firefox (v28以降)、Edge (v14以降)、Operaで利用可能です。Appleは2020年のSafari 14でついにVP9をサポートし、iOS 14とmacOS Big Surをカバーしました。落とし穴は？iOS 13以前で止まっているデバイスです。トラフィックのごく一部ではありますが、無視できないセグメントです。『自分のオーディエンスには関係ない』と決めつけず、アクセス解析をチェックしてください。企業や教育機関のユーザーは、驚くほどデバイスのアップグレードサイクルが長いことがあります。 WebM/AV1のサポート状況は数年前に比べて格段に良くなりました。Chrome、Firefox、Edgeは以前からAV1をデコードできます。Apple側では、Apple Silicon搭載のMac上のSafariや、iPhone 15 Pro以降のモデルでは、ハードウェアアクセラレーションによるAV1デコードが利用できます。それより古いiPhoneはソフトウェアデコードにフォールバックしますが、これはバッテリーを消耗し、4K動画ではフレーム落ちの原因にもなります。ソフトウェアデコードは、スマホが熱くなり、ユーザーは不満顔、という最悪のシナリオです。もしあなたのオーディエンスがiOSベースで、彼らのバッテリー寿命を気にかけるなら、WebMコーデックはVP9の方が安全です。 結論として、デスクトップとモバイルのユーザーが混在する一般的なサイトでは、WebM/VP9をプライマリソースとし、MP4/H.264をフォールバックとするのが、最も安全で賢い構成です。
ファイルサイズと画質：実際の数値で比較
圧縮率に関する抽象的な主張は、ストレージ予算の役には立ちません。FFmpegとCocoConvertのパイプラインを使ってエンコードした、2分間の1080p 30fpsのソースクリップから得られた実際の数値を見てみましょう。 ベースラインはMP4/H.264（x264, CRF 23, mediumプリセット）で、ファイルサイズは87MBになりました。これは多くの開発者にとってのデフォルト設定で、品質はしっかりしており、このクリップのVMAFスコアは約93です。 WebM/VP9（libvpx-vp9, CRF 33, 2パス）に切り替えると、ファイルサイズは54MBにまで減少します。VMAFスコアはわずかに高い94で、これはファイルサイズが小さいにもかかわらず、画質がわずかに向上したことを意味します。しかし、その効率性には代償が伴います。2パスエンコードには、同じマシンでH.264版の約4倍の時間がかかりました。 WebMコンテナに入ったAV1エンコード（libaom-av1, CRF 30, cpu-used=4）では、わずか41MBまでファイルサイズを削減でき、VMAFスコアは95です。`cpu-used=4`という設定は良い妥協点で、ほとんど実用的でない`cpu-used=0`設定よりはるかに高速でありながら、H.264のベースラインよりは約12倍遅いです。 これはあなたの予算にとって何を意味するでしょうか？平均90秒の商品動画が500本あるサイトの場合、H.264のみからVP9を優先するアプローチに切り替えることで、プライマリ動画ストレージを約3.2TBからわずか2.0TBに削減できます。1GBあたり約3円から13円という一般的なCDN価格では、スケールが大きくなるにつれて、これらのストレージと帯域幅の節約は急速に積み上がっていきます。 CocoConvertのAV1設定に関する簡単な注記：共有インフラストラクチャでの変換を高速に保つため、`cpu-used=5`を使用しています。アーカイブ用に絶対的な最高品質のAV1エンコード（`cpu-used=0`または`1`）が必要な場合は、ローカルのFFmpeg環境か、これらのプリセットを設定できる専用のトランスコーディングサービスが必要になります。
WebMではなくMP4を選ぶべき時
時として、MP4は単なるフォールバックではなく、唯一の賢明な選択肢となります。WebMはWeb配信には最適ですが、いくつかの重要な分野で力不足です。 **メールとメッセージング：** メールへの動画埋め込みは悪名高い地雷原です。Windows版のOutlookは、あなたのHTML5 videoタグを完全に無視します。Apple MailはiOS上でMP4をインライン再生しますが、主要なクライアントでWebMファイルに対応しているものはありません。メールキャンペーンでは、MP4が唯一の選択肢です。 **動画のダウンロード：** ユーザーがオフラインで視聴するために動画をダウンロードできるようにするなら、MP4を提供しましょう。VLCを使えるパワーユーザーは何でも再生できますが、Windows、macOS、そしてほとんどのスマートテレビのデフォルトのメディアプレーヤーはWebMを扱えません。MP4を使うことで、『動画が再生できません』というサポートへの問い合わせが殺到するのを防げます。 **ソーシャルメディアへのアップロード：** Twitter/X、Instagram、TikTok、LinkedIn、Facebookといったあらゆるソーシャルプラットフォームは、MP4を中心に構築されています。彼らはMP4を受け入れ、自社側で再エンコードします。ほとんどのプラットフォームはWebMのアップロードを完全に拒否するか、最悪の場合、めちゃくちゃに変換して視聴不能なものにしてしまいます。ソーシャルメディア用のコンテンツは必ずMP4で書き出しましょう。 **レガシーなCMSプラットフォーム：** ライブラリにある大量のファイルをWebMにエンコードするのに何時間も費やす前に、あなたのプラットフォームがそれを使えるかどうかを確認してください。古いWordPressプラグインや特定のLMSシステム、さらには一部のバージョンのWistiaでさえ、MP4のアップロードしか受け付けません。ドキュメントをさっと確認するだけで、大きな頭痛の種を避けられます。 **ハードウェアと編集：** カメラやスクリーンレコーダー、キャプチャーカードからのソース映像は、ほとんどの場合MP4かMOVです。WebMは配信フォーマットであり、制作用フォーマットではありません。プロのビデオエディターがプロジェクトでWebMを使うことはありません。これはゴールラインで使うものであり、スタートラインで使うものではないのです。
両方のフォーマットを実装する方法：HTMLとワークフロー
両方のフォーマットを提供するのは、ほとんどの開発者が思うよりずっとシンプルです。その魔法はHTML5の`<video>`要素にあり、この要素は`<source>`タグを上から順にチェックし、最初に理解できたものを再生します。 <video controls width="1280" height="720" preload="metadata"> <source src="/video/product-demo.webm" type="video/webm; codecs=vp9,opus"> <source src="/video/product-demo.mp4" type="video/mp4"> Your browser does not support HTML5 video. </video> VP9 WebMを扱えるモダンなブラウザは最初のソースを再生します。それ以外のすべてのブラウザは、MP4へと適切にフォールバックします。`type`属性に`codecs`パラメータを含めるのは賢い最適化です。これにより、ブラウザはファイルの一部をダウンロードすることなく、より迅速に判断できます。 単一のマスターファイルから両方のファイルを作成するワークフローは簡単です。CocoConvertのバッチ変換ツールを使えば、ソースファイルのフォルダからMP4とWebMの両方を同時に出力できます。マスターをアップロードし、目的の出力として「MP4 (H.264)」と「WebM (VP9)」を選び、品質設定を調整すれば、両方のバージョンが入ったZIPファイルが手に入ります。一般的な1080pのWeb動画では、H.264にCRF 23、VP9にCRF 33を設定すると、ほぼ同等の視覚的品質が得られます。 自動化のための重要なヒントがあります。拡張子以外のファイル名を同一に保つことです（例：`product-demo.webm`と`product-demo.mp4`）。これにより、テンプレートシステムが動画ごとにデータベースを検索することなく、簡単に`<source>`のパスを構築できます。 このアプローチの限界を知っておくことも重要です。CocoConvertは現在、HLSやDASHのようなアダプティブビットレート（ABR）ストリームを生成しません。ユーザーがシークしたり、ネットワーク速度が変動したりする可能性のある長編動画を扱う場合は、ABRが必要になります。これには専用の動画プラットフォーム（Mux、Cloudflare Stream、Bunny.netなど）か、より複雑な自己ホスト型のFFmpeg設定が必要です。しかし、10分未満の短いクリップであれば、この単一ファイルのWebM/MP4配信方法は全く問題ありません。
2026年の結論
純粋な技術的メリットだけで見れば、2026年のWeb動画にはVP9を使ったWebMの方が優れたフォーマットです。同等かそれ以上の品質でより小さなファイルを提供でき、ブラウザのサポートもほとんどのウェブサイトで第一の選択肢となるほど広がりました。AV1が次期エースであることは間違いありませんが、エンコードコストの高さと、iOSのハードウェアサポートにまだ隙間があることから、単純なデフォルトではなく、戦略的な選択肢に留まっています。 しかし、H.264を使ったMP4も決して時代遅れではありません。普遍的なフォールバックとして絶対不可欠な存在であり続けています。また、メール、ソーシャルメディアへのアップロード、ダウンロード、そして多くの古いプラットフォームで機能する唯一のフォーマットでもあります。これがどこかへ行くことはないでしょう。 というわけで、私の実用的な推奨事項は以下の通りです： * **一般的なウェブサイト動画：** WebM/VP9をプライマリソースとし、MP4/H.264をフォールバックとして使用する。 * **ソーシャルメディアとメール：** MP4のみ。例外なし。 * **ダウンロード用ファイル：** 互換性を最大化するためにMP4のみ。 * **トラフィックの多いサイト：** CDNコストが大きな懸念事項である場合、多層的なフォールバックを検討する価値がある。最新ブラウザにはAV1、次にVP9、そしてH.264。 * **非常に短いクリップ（30秒未満）：** ごく短い動画ではファイルサイズの差はごくわずか。MP4だけに絞る方がシンプルで全く問題ない。 最終的に、あなたは4つの要素のバランスを取ることになります。互換性、ファイルサイズ、エンコード時間、そしてワークフローの複雑さです。正しい答えは、あなたのオーディエンスのデバイス、ホスティング予算、そして動画パイプラインにどれだけ時間をかけたいかによって完全に変わってきます。ほとんどの中小規模のサイトにとって、2フォーマット方式は素晴らしいスイートスポットです。セットアップに30分もかからず、互換性の問題を引き起こすことなく、すぐに帯域幅の節約を開始できます。