4Kに上げた動画が元ファイルの8倍重くなる理由 — ビットレートで判断する

4Kに高画質化した動画のファイルサイズを見て驚いたことはないでしょうか。1080pで200MBだったクリップが、4Kにすると1.6GBになる。これは正常な動作です。問題は「その重さに見合う情報が入っているか」です。

この記事では、ファイルサイズではなくビットレートで判断する方法を書きます。

なぜ8倍になるのか

4Kは1080pの4倍の画素数です。同じ圧縮率なら単純に4倍。ここに高画質化モデルの出力特性が加わって、実際には6〜10倍になることが多い。

理由は3つあります。

1. 画素数の増加 — 1920×1080 → 3840×2160 で4倍
2. ノイズの増幅 — モデルが推定した細部は、圧縮しにくい高周波成分として現れる
3. エンコーダ設定の据え置き — 解像度だけ上げてCRFをそのままにすると、ビットレートが自動的に膨らむ

ビットレートで見るべき数字

結論から書きます。1080p30の動画は8〜12 Mbps、4K30は35〜45 Mbps が実用的な目安です。

重要なのは「元のビットレートを下回らないこと」です。

720p 5 Mbpsの素材を4Kにして3 Mbpsで書き出すと、解像度は4倍なのに情報量は6割に減ります。これは高画質化ではなく劣化です。

よくある失敗：解像度だけ上げる

元: 1280x720, 5 Mbps, H.264
×: 3840x2160, 3 Mbps, H.264  ← 失敗
○: 3840x2160, 40 Mbps, H.265 ← 正しい

解像度を上げたら、ビットレートも上げる必要があります。これは当たり前のことですが、書き出し設定を変え忘れて「4Kにしたのに汚くなった」となるケースが非常に多い。

H.265（HEVC）にすれば、同じ画質でビットレートを30〜40%削減できます。4Kでは特に効果的です。

8倍の重さは許容すべきか

ケースバイケースですが、判断基準を書きます。

許容すべきケース：

• 元のビットレートが十分高い（1080p 15 Mbps以上）
• 配信先が4Kを要求する（YouTube、放送、クライアント納品）
• アーカイブとして保存する

許容すべきでないケース：

• 元が3 Mbps以下の低ビットレート素材 → 4Kにしても情報は増えない
• Webページに埋め込む → 読み込み時間が実害になる
• SNS投稿 → プラットフォームが再圧縮するので無意味

元が低ビットレートなら、4Kにせず1080pのまま高品質で書き出す方が結果が良くなります。

実際に測ってみた

720p / 4.8 Mbps / 30fps / 12秒のクリップで試しました。

注目すべきは3行目と2行目です。 4Kにしても1080pと見た目がほぼ変わらないのに、サイズは3倍。元が720pだったため、4Kにする情報がそもそも存在しないからです。

最終的に私は1080p（12 Mbps）を採用しました。

判断フロー

1. 元のビットレートを確認する（ffprobe または ファイルの詳細）
2. 元が10 Mbps未満 → 1080pで止める
3. 元が15 Mbps以上 → 4Kを検討してよい
4. 4Kにするなら 35 Mbps以上 を確保
5. H.265が使えるなら使う（同じ画質で3割軽い）
6. 書き出し後に100%表示で元と並べて確認

この方法で解決できないこと

• 元の情報量は増えない。 ビットレートを上げても、記録されていない細部は戻りません。
• 再圧縮のたびに劣化する。 4K化 → H.265化 → アップロード で3回圧縮すると、最初の改善が消えます。
• プラットフォーム側の再圧縮は制御できない。 YouTubeに4Kで上げても、視聴者には別のビットレートで届きます。

まとめ

ファイルサイズの大きさは品質の証拠ではありません。ビットレートが解像度に見合っているかだけを見てください。

元が720p 5 Mbpsなら、4Kにする意味はほぼありません。1080p 12 Mbpsの方が軽くて高品質です。

ブラウザで完結するツールなら、書き出し設定を変えながら試せます。UpgoLAB の日本語ページ から、インストールなしで確認できます。

プリセットの選び方はこちら、元動画の重要性はこちらに書いています。

The measurements behind this post, with the browser tests reproduced: making a 4K thumbnail that survives compression.
Everything else in the cluster: AI upscaling notes.