映像フォーマット比較:MP4・WebM・MOV・AVIを用途別に選ぶ
要約 (TL;DR)
去年、映像編集者の友人が「MP4ファイルなのに、なんでPremiereが読めないんだ」と聞いてきた。拡張子は .mp4 でも、中身はHEVC 10bit 4:2:2。H.264しか想定していないツールチェーンが止まったのだった。拡張子は箱、コーデックは中身。この一文で映像フォーマットの話の9割は終わってしまう。
映像フォーマット選びで一番よくある混乱は、コンテナ(拡張子)とコーデックを同じものとして扱うことだ。MP4・WebM・MOV・AVI・MKVはコンテナで、H.264・H.265・AV1・VP9・ProResはその中に収まる実際の映像コーデックだ。結論から言うと、Web配信ならMP4 + H.264が今でも一番安全なデフォルト、サイズ効率を重視するならAV1かH.265、編集原本はMOVコンテナ + ProResが典型、長期アーカイブならMKV + AV1またはH.265が頻用される。AVIは「無条件に高画質」なのではなく、フォーマット自体が古く音声・字幕・メタデータ対応が限られたコンテナだ。H.265はH.264より約40–50%効率的だがライセンスと旧機器対応の問題があり、AV1はロイヤリティフリーだがハードウェアエンコーダがまだ限定的。だから「一番」を決めるより、対象視聴者・再生環境・編集パイプラインに合わせて組み合わせを設計する方が現実的だ。
背景・コンセプト
コンテナは映像・音声・字幕・チャプター・メタデータを一つのファイルに束ねる「箱」だ。MP4(ISO Base Media File Format)はMPEG標準、WebMはMatroskaベースのWeb向けサブセット、MOVはAppleのQuickTimeコンテナ、AVIは1992年にMicrosoftが作った初期コンテナ。MKV(Matroska)は拡張性が高く、コーデック制約がほぼない。
コーデックは実際に圧縮を行うアルゴリズムだ。H.264(AVC)は2003年に標準化されて以来20年以上も事実上の標準で、ほぼ全ての機器でハードウェアデコードされる。H.265(HEVC)は同じ品質でH.264より40–50%低いビットレートを出せるが、ライセンス費用と古いブラウザ・機器での対応問題がある。AV1はAOM(Alliance for Open Media)が2018年に公開したロイヤリティフリーコーデックで、H.265と同等かそれ以上の効率を目指す。VP9はWebMとYouTubeで広く使われている。ProResはAppleの編集用コーデックで、編集中のフレーム単位デコードを速くするためにあえて低圧縮を維持する。つまり「画質=フォーマット」ではなく、ビットレート・コーデック・設定が画質を決める。
比較・データ
| コンテナ | 代表的コーデック | ブラウザ対応 | メタデータ・字幕 | 圧縮効率 | 特徴 |
|---|---|---|---|---|---|
| MP4 | H.264、H.265、AV1 | 全ブラウザ(H.264) | 広い(ID3、チャプター) | コーデック依存 | Web配信の標準 |
| WebM | VP9、AV1 | Chrome・Firefox・Edge・Safariの新しいバージョン | WebVTT字幕 | AV1で良好 | オープン・ロイヤリティフリー |
| MOV | H.264、ProResなど | ブラウザ再生は限定的 | 非常に広い(多彩なトラック) | 編集原本向け | macOS/iOS親和 |
| AVI | Xvid、DivXなど | 再生互換性が低い | 字幕・メタデータ制限 | 旧式・非効率 | レガシー素材の互換 |
| MKV | ほぼ全てのコーデック | ブラウザ再生は限定的 | 非常に柔軟 | コーデック依存 | アーカイブ・ファン字幕 |
「50%の効率」といった数字はソース内容・ビットレート・エンコーダ設定・プリセットで大きく変わる。同じパラメータでない比較の単純数値にはあまり意味がない。
実践シナリオ
シナリオ1 — Webサイト配信用映像。 既定値はMP4(H.264 High Profile)+ AAC-LC。90秒のランディングページ紹介映像を ffmpeg -crf 23 -preset slow で書き出すと約8MB、1080p品質で十分満足だった。帯域をさらに削るなら <source> にWebM(AV1/VP9)を追加し、字幕はWebVTTで別トラック提供してアクセシビリティとSEOを確保する。
シナリオ2 — 編集原本の保管。 編集原本はMOV + ProRes 422が基本。H.265ソースをそのまま編集していてResolveのタイムラインが途切れた経験があり、ProRes 422のプロキシに切り替えたら同じプロジェクトがリアルタイム再生できるようになった。10分の1080p ProResで約8GBと大きいのが欠点で、編集後にH.264/H.265で一度だけ書き出す2段階フローが一般的だ。
シナリオ3 — 長期アーカイブ。 現時点の無難な既定値はMKV + AV1。SvtAv1EncApp --preset 4 --crf 28 で過去の4K映像を再エンコードすると、元の40–55%のサイズで視覚的な差をほとんど感じられない。MKVは複数トラック・字幕・チャプターを柔軟に扱えるので、CRFベースのエンコードと相性が良い。
よくある誤解
「AVIは無条件に高画質」。 AVIは単に古いコンテナで、画質は内部のコーデックとビットレートで決まる。同じコーデックなら MP4・MKVとほぼ差はなく、字幕・メタデータ対応はむしろ弱い。
「MOVはApple専用」。 QuickTimeに由来するが、標準に近い形で公開されていてWindowsやLinuxの多くのプレイヤーで再生できる。ただしブラウザ直接再生はMP4より互換性が劣ることがある。
「H.265は常にH.264より良い」。 圧縮効率は良いが、ライセンス費用があり、古いブラウザや低スペックのモバイル機器ではハードウェアデコードできないことがある。公開Webで多様な機器を相手にする場面では、H.264がまだ一番安全な選択だ。
「AV1は新しい標準」。 長期的にはシェアが伸びており、Intel Arc、Apple M3以降、NVIDIA RTX 40シリーズはAV1ハードウェアエンコーダを搭載しているが、2026年初頭時点でも現場のライブストリーミングチェーンの大半は依然としてH.264/H.265で回っている。リアルタイムAV1は消費電力と発熱が大きい。バッチエンコードや大容量アーカイブには向くが、あらゆるリアルタイムストリーミングに展開するにはまだ早い。
チェックリスト
- 最終目的は何か?
- 公開Web配信 → MP4 + H.264(フォールバック)、余裕があればAV1をソースに追加。
- 社内・特定プレイヤー環境 → 該当プレイヤーの互換性リストを先に確認。
- 編集原本 → MOV + ProResのような編集フレンドリーなフォーマット。
- 長期アーカイブ → MKV + AV1またはH.265。
- 視聴者の機器・ブラウザ分布は? 旧型機器比率が高ければH.264フォールバックは必須。
- サイズと品質のどちらが優先か? サイズ優先 → AV1またはH.265。互換性優先 → H.264。
- 音声・字幕・メタデータはどれくらい重要か? 多重トラック・チャプターが要るならMKVかMP4。
- コスト構造は? H.265ライセンス料、電力・エンコード時間(AV1)なども判断材料。
関連ツール
このガイドのフォーマット変換を実際に試すなら Patrache Studioの映像変換ツール でMP4・WebM・MOV間の変換をその場で試せる。映像に差し込むサムネイルやオープニングの静止画は 画像圧縮の完全ガイド のフォーマット基準に揃えるとページ全体の容量が下がるし、映像内に走査可能なQRを埋め込むなら QRコードのセキュリティ落とし穴 で静的・動的QRの違いを先に確認しておく方が安全だ。
参考文献
- MDN, “Video codecs” — https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs
- AOMedia, “AV1 Features” — https://aomedia.org/av1-features/get-started/
- Apple, “About Apple ProRes” — https://support.apple.com/en-us/102205
- ISO/IEC 14496-14:2020 (MP4 file format) — 標準文書はISOで有料配布。