動画圧縮完全ガイド：1GBの動画を100MBに、画質はほぼそのまま

前端工程

動画を撮ったが、送れない

スマホで製品デモ、子どもの発表会、会議での発言——撮ってみたら2GB。微信のファイル転送アシスタントは「ファイルが大きすぎます」、メールの添付は拒否、クラウドストレージのアップロードバーはまるで眠ったように動かない。

動画はとにかく容量を食う。写真1枚が数MBなのに対し、30秒の動画はあっという間に数百MBに達する。その根源は動画が本質的に「何万枚もの画像に音声が連なったもの」だからだ。私たちがツールライブラリの動画ツールを開発してきた中で最もよく聞かれたのは「小さくしてほしい、でも画質は落とさないで」という要望だ。この記事では動画サイズの源泉と小さくする方法を一度に解説する——読み終えれば圧縮できるだけでなく、「なぜそう圧縮するのか」も理解できる。

まず区別しよう：コンテナとコーデックは別物

初心者が最も混同しやすいのが .mp4、.mov、.mkv と H.264、H.265 の関係だ。覚えておいてほしい：

  • コンテナ（Container）：.mp4／.mov／.mkv は「箱」であり、ファイルが動画・音声・字幕をどうパッケージするかを決める。
  • コーデック（Codec）：箱の中のデータをどのアルゴリズムで圧縮するか。例：H.264、H.265/HEVC、VP9、AV1。

同じ .mp4 の箱でも、中身はH.264にもH.265にもなる。サイズは主にコーデックが決め、コンテナは関係ない。iPhoneで撮った .mov は多くの場合H.265を使っているため、同じ時間のAndroidの .mp4（H.264）よりずっと小さい——これが「Appleの動画は容量を取らない」と言われる理由だ。

動画サイズはどこから来るのか

4つの要因が重なる：

  • 解像度：4K（3840×2160）のピクセル数は1080pの4倍、720pの約9倍。ピクセルが多いほどデータが肥大化する。
  • ビットレート：1秒あたりのデータ量。サイズに最も影響する「ダイヤル」だ。
  • コーデック：H.264は互換性の王者。H.265/HEVCはサイズを約半分にできるが、古いデバイスでは非対応。AV1はさらに省サイズだが、エンコードが遅い。
  • フレームレートと音声ビットレート：60fpsは30fpsの2倍のデータ量。音声320kbpsは128kbpsより大きくかさむ。

同じ内容でも、パラメータ次第でサイズは10倍違う：

設定 おおよそのサイズ（60秒）
4K＋H.264＋高ビットレート 約380MB
1080p＋H.264＋中ビットレート 約90MB
720p＋H.265＋中ビットレート 約35MB
720p＋H.264＋低ビットレート 約22MB

上記は典型的なシーンの概算。実際は画面の複雑さに依存する——静止画（会議のPPT）は小さく圧縮できるが、高速な動き（サッカー）はあまり圧縮できない。

本当に小さくできる4つのレバー

1. 解像度を下げる：最も効果が速い

1080pから720pに下げると、ピクセル数が半分以上になり、サイズも半分以上に落ちるのが普通だ。スマホの小画面で見るなら、ほとんど違いはわからない。大画面テレビに映す、編集をするのでなければ、720pで友達やグループに送るには十分だ。

2. ビットレート／CRFを調整する：最も細かく制御できるダイヤル

トランスコードツールによく登場するCRF（Constant Rate Factor）。簡単に覚えよう：CRFが大きいほど小さく圧縮され、画質はやや落ちる。一般的な範囲は18–28：

  • 18–20：ほぼ無劣化、サイズは大きめ（アーカイブマスター向け）
  • 23–24：デフォルトのスイートスポット（圧縮後、肉眼ではほぼ差がわからない）
  • 26–28：明らかに小さい、画質は多少落ちるがスマホなら問題ない

CRFは「画質に合わせてビットレートを決める」方式で、VBR（可変ビットレート）の一種。複雑な画面には多めに、単純な画面には少なめに割り当てるため、同じ画質なら最もサイズを節約できる。対照的にCBR（固定ビットレート）は「1秒あたりのデータ量を固定」するため、単純な画面でも無駄が生じ、圧縮には推奨されない。

3. コーデックを変える：H.265はH.264より約40%–50%小さい

同じ画質でも、H.265のファイルはより小さい。代償は互換性——古いテレビ、一部の車載システム、一部の編集ソフトでは開けない。汎用的に共有するならH.264優先。自分のエコシステム内だけでやりとりするならH.265で容量を節約しよう。

コーデックには「Profile／プロファイル」という概念もある。H.264を例に：

プロファイル 能力 用途
Baseline 最小限、互換性最高 極めて古いデバイス、リアルタイム通信
Main 中程度 標準画質ストリーミング
High 最高圧縮率 HD、Blu-ray（推奨）

4. 不要部分をカット＋音声ビットレートを下げる

頭の10秒の黒画面、最後の20秒の雑談——これらをカットすればサイズは確実に減る。音声を128kbpsに下げても会話には十分な品質だ。320kbpsのままで維持する必要はない。動画の中で音声の割合は小さいが、ないよりはましだ。

目標サイズの目安

元の状態 推奨操作 おおよその結果
1080p 1GBのデモ動画 720pに下げ＋CRF 24 約350MB
4Kスマホ画面録画2GB 1080pに下げ＋H.265 約400MB
微信で送りたい500MB 720pに下げ＋CRF 26 約120MB
メール添付25MB制限 480pに下げ＋不要部分カット 約20MB

各プラットフォームの実際のアップロード制限（変わるので目安）：微信は単ファイル約1GB（チャット）、200MB（モーメンツ）。メール添付はおおむね20–25MB。クラウドストレージは単ファイル4GB上限がほとんど。まず「どこに送るか」を考えてからパラメータを決めよう。

ツールライブラリでブラウザ上ローカル圧縮

動画圧縮ではスライダーで解像度とCRFを調整でき、ブラウザがffmpeg.wasmを使ってローカルでトランスコードする——ファイルはアップロードされず、ページを閉じればデータは消える。

便利な関連ツール：

実際のワークフロー：微信で製品デモを送る

iPhoneで撮ったMOV（H.265、1.2GB）
  → /video/to-mp4 でH.264のMP4に変換（Android／Win対応）
  → /video/trim で冒頭8秒の黒画面と最後の雑談をカット
  → /video/compress で720p＋CRF 26に圧縮
  → 出力 約110MB、微信で即送信

ローカル圧縮で足りない時

ブラウザはメモリとパフォーマンスの制約を受ける。こんな時はデスクトップのffmpegを使おう：

  • 単一ファイルが数GB以上
  • 数十ファイルを一括処理
  • 速度が最優先（WASMはネイティブよりかなり遅い）

ローカルにffmpegをインストールしたら、以下のコマンドでほとんどのシーンをカバーできる。

基本：解像度低下＋H.265＋音声調整

# 720pに下げ、H.265、CRF 28、音声128kbps
ffmpeg -i input.mp4 \
  -vf scale=1280:-2 \
  -c:v libx265 -crf 28 \
  -c:a aac -b:a 128k \
  output.mp4

パラメータの解説：

  • scale=1280:-2：幅を1280に、高さは自動で比率維持（-2 は偶数を保つための指定、エンコーダー要件）
  • libx265 -crf 28：H.265エンコード、CRF 28
  • -c:a aac -b:a 128k：音声AAC、128kbps

最大互換性を求めるなら -c:v libx264 に変更。さらに強力に圧縮するならCRFを30前後に（画質はより目立って落ちる）。

2パスエンコード（最小サイズ追求）

# 1パス目：分析、画面は出力しない
ffmpeg -i input.mp4 -c:v libx265 -b:v 800k -pass 1 -f mp4 /dev/null
# 2パス目：分析結果に基づいて精密圧縮
ffmpeg -i input.mp4 -c:v libx265 -b:v 800k -pass 2 -c:a aac -b:a 128k output.mp4

2パスは「目標サイズが明確」なシーン向け。1パスのCRFより制御しやすいが、処理時間は倍になる。

一部分だけ切り出す（再エンコードなし、超高速）

# 00:00:10から30秒間を切り出し、再エンコードなし（-c copy）
ffmpeg -i input.mp4 -ss 00:00:10 -t 00:00:30 -c copy clip.mp4

-c copy はほぼ一瞬で完了するが、カット位置は正確ではない（キーフレーム単位になる）。正確さが必要なら -c copy を外す（再エンコードが入るため多少遅くなる）。

ハードウェアアクセラレーション（NVIDIA／Intel）

# NVIDIA GPU：NVENCハードウェアエンコード、大幅に高速
ffmpeg -i input.mp4 -c:v hevc_nvenc -rc vbr -cq 28 -c:a aac -b:a 128k output.mp4

ハードウェアエンコードは高速だが圧縮効率はソフトウェア（CPU）エンコードに若干劣る。日常的な共有用途なら十分だ。

「画質」について：圧縮の価値をどう判断するか

ファイルサイズだけを信じてはいけない。簡単な自己チェック法：

  1. 圧縮後、全画面／大画面で重要なシーン（動き、文字、顔）を確認する。
  2. 拡大してエッジに「ブロックノイズ」（モザイクのようなもの）や文字のにじみがないか見る。
  3. 元の動画と比較し、画質が明らかに低下している時点を特定する。

肉眼で違いがわからなければ、圧縮は成功だ。CRFが30を超えたり解像度を下げすぎると、文字や高速な動きのシーンで破綻が現れる。

よくあるエラー

エラー 結果 正しい方法
同じファイルを繰り返し圧縮 品質がどんどん落ちる 元ファイルから1回で圧縮
CRFを35以上に設定 広範囲のモザイク、色むら 18–28の範囲に抑える
H.265で古いデバイスに送信 相手が開けない 汎用共有ならH.264
圧縮だけしてカットしない 無駄な部分も容量を食う 先にカット /ja/video/trim
音声ビットレートそのまま 容量が減らない 128kbpsに下げる
MOVをそのままAndroid／Winに送信 相手が開けない可能性 先にMP4に変換 /ja/video/to-mp4

よくある質問

H.264とH.265はどう選ぶ？ 他人に送る、クロスデバイス、開けないリスクを避けたい → H.264。自分のApple／モダンデバイス間だけでやりとり、容量を節約したい → H.265。

圧縮後、元の画質に戻せる？ 戻せない。圧縮は不可逆で、失われた情報は戻らない。常に元ファイルを保存しておき、削除しないこと。

スマホのブラウザでも圧縮できる？ できる。ツールライブラリの動画ツールはWebページとして動作し、スマホでも開いてローカルトランスコードできる。ただし大ファイルはPCより遅くなる。

圧縮したのにサイズがあまり減らなかったのはなぜ？ 解像度を下げていない、またはCRFが低すぎるのが原因の大半だ。まず解像度という最大のダイヤルを動かすこと——ビットレートよりも直感的に効果が出る。

GIFと動画、どちらを使うべき？ 短いアニメーションをグループに送るなら、GIFは便利だが巨大。動画（MP4/H.265）はサイズが十分の一で画質も鮮明。動画で済むなら動画を選ぶこと。

一言で判断

動画が大きすぎて送れない？
├── 手早く小さく、画質は維持したい → /video/compress（解像度＋CRF調整）
├── iPhoneで撮ったMOV → /video/to-mp4
├── 一部分だけ必要 → /video/trim でカットしてから圧縮
├── コーデックをH.265に変更 → /video/convert
└── 単体で数GB／数十ファイル一括 → デスクトップffmpeg（上記コマンド参照）

次に「送れない」大容量動画を撮ったら、上のフローに沿って操作すれば、数分で小さくて鮮明なバージョンが手に入る。圧縮したMP4から1フレームをサムネイルとして切り出したい場合は動画から画像へで必要なフレームを取得できる。

ブラウザローカルツールを無料で試す →

#视频压缩#视频格式转换#H.264#H.265#CRF#本地处理