GIFをMP4に変換してファイル容量を約90%削減する方法と仕組み

5秒のアニメーションGIFは平気で8〜15MBになります。同じアニメーションをMP4にすると1MB以下。

これは誤差ではなく約10倍の差です。X（旧Twitter）やInstagramがGIFをアップロードした瞬間に内部でMP4動画に変換しているのは、まさにこの理由です。

この記事では、なぜGIFはここまで重いのか、いつMP4に変換すべきか、そして多くの変換ツールが見落としている重要なポイントを解説します。

1. GIFが巨大になる仕組み

GIFの圧縮仕様は1989年に策定されたまま、一度も更新されていません。そこから2つの本質的な問題が生じます。

フレーム間圧縮がない。 現代の動画コーデック（H.264など）は前のフレームとの「差分」だけを保存します。画面の90%が変わらなければ、その90%はほぼゼロコスト。GIFにはこの概念がなく、毎フレームがほぼ独立した画像として格納されます。

1フレーム256色の制限。 写真的なシーンを256色で表現するにはディザリング（色をばらまいて中間色を擬似的に再現する手法）が必須です。しかしディザリングが生む細かいノイズは圧縮効率を著しく下げます。色数制限を補う処理が、容量問題をさらに悪化させるという悪循環です。

H.264にはどちらの問題もありません。フレーム間で差分圧縮し、数百万色をネイティブに扱えます。

Webサイトに貼る場合 — ファーストビューに10MBのGIFを置くとCore Web Vitalsが壊滅します
X（Twitter）・Instagram・Redditへの投稿 — どうせ内部でMP4に再エンコードされます。最初からMP4で上げた方が画質を制御できます
3秒以上のアニメーション、または写真的なコンテンツ
容量制限で弾かれている場合

要するに、GIFが生き残っている理由は「自動再生・ループ・互換性」であり、画質や効率ではありません。

ここが良い変換と雑な変換を分ける最大のポイントです。

GIFはフレームごとに個別の表示時間（delay）を持っています。 GIFは一定フレームレートである必要がなく、実際多くのGIFはそうではありません。最初のフレームが2秒、次の12フレームが各40ms、最後が1.5秒——こんな構成は珍しくありません。

雑な変換ツールはフレーム数だけ見て等間隔のfpsに押し込みます。結果、再生速度がずれ、意図的なポーズ（間）が消えてしまいます。

正しい変換は、各フレームのdelayを読み取り、本来のタイムラインを再構築してから出力フレームレートにリサンプルします。元のリズムがそのまま保たれるわけです。

GIF→MP4変換ツールはフレームごとのdelayを個別に読み取り、タイムラインを忠実に再現してからエンコードします。

サーバーへのアップロードは一切なく、すべてブラウザ内で処理されます。

MP4にするとループしなくなる？ ループは再生側の設定であり、ファイルに格納される情報ではありません。Webサイトなら<video>タグにloop属性を付ければ無限ループ。SNSでは短い動画は自動的にループ再生されます。変換で実用上失うものはほとんどありません。

どのくらい小さくなる？ 一般的なアニメーションGIFで80〜90%削減が期待できます。テストでは320×320、40フレームのGIFが820KBから87KBになりました（89%減、画質劣化なし）。写真的なGIFほど削減率が高く、フラットなイラスト系GIFは差が小さくなります。

変換すると画質は落ちる？ むしろ見た目は良くなるケースが多いです。GIFの時点で256色に量子化＋ディザリング済みなので、MP4が失った色を復元するわけではありませんが、ディザリングのノイズが圧縮で目立たなくなります。

MP4からGIFに戻せる？ はい。ただしサイズは再び大きくなります。動画→GIF変換ツールでフレームレート・横幅・ディザリングを制御しながら変換できます。

出力がWebMになるのはなぜ？ H.264エンコードはブラウザの対応に依存します。FirefoxやLinuxの一部ではH.264が使えないため、VP9によるWebMにフォールバックします。WebMはChrome・Android・主要サイトで問題なく再生できます。

X（Twitter）にGIFを上げると勝手にMP4になるのはなぜ？ Xのバックエンドは帯域節約と再生品質向上のため、GIFアップロード時に即座にループMP4へ変換します。最初からMP4で投稿すれば再エンコードの劣化を避けられます。