メール添付の容量制限は小さく、容赦がありません。GmailもOutlook.comも上限は25MBで、企業向けやデスクトップ版Outlookの環境ではさらに厳しいことが多いです（10〜20MB程度のことも）。スマホの動画は数秒でこの制限を超えます。FFmpegなら収まるサイズに縮小できます——画質設定ひとつで済むこともあれば、2パスエンコードで正確な目標サイズを狙うこともあります。本記事では3つの方法と、ビットレートを決める計算式を解説します。所要時間：10分。

動作確認: FFmpeg 8.1

本記事はメール上限に特化した内容です。一般的な縮小は動画を圧縮するを、Discordの段階制限はDiscord動画圧縮を参照してください。

この記事でわかること

  1. 主なメール添付の上限（Gmail・Outlook）
  2. 手早い方法：画質（CRF）で縮小
  3. 解像度ダウンで容量を大きく削る
  4. 2パスで正確な目標サイズに合わせる
  5. サイズ上限からビットレートを逆算する計算式
  6. トラブルシューティング
  7. よくある質問

1. メール添付の上限

上限より少し下を狙いましょう。メールシステムはエンコードのオーバーヘッドを加え（Base64により転送時に約33%膨らむ）、余裕を持たせたいためです。

サービス添付上限安全な目標
Gmail25MB約18〜20MB
Outlook.com25MB約18〜20MB
Yahoo!メール25MB約18〜20MB
企業向け・デスクトップ版Outlook10〜20MB約8〜12MB

クリップが上限を大きく超えている場合、画質を下げるだけでなく解像度も下げる必要があると考えてください。

2. 手早い方法 — 画質（CRF）で縮小

最速の単一パス。FFmpegに、画質を保つためのビットレートを自動で選ばせます。-crf 28 は短いクリップなら十分に強めです。

ffmpeg -i input.mp4 -vcodec libx264 -crf 28 -preset slow -acodec aac -b:a 96k output.mp4
  • -crf 28 … CRFが高いほど小容量（低画質）
  • -preset slow … ビットレートをより活かす。追加時間の価値あり
  • -b:a 96k … 音声を96kbpsに抑える。音声・クリップには十分

出力サイズを確認します。まだ超えていればCRFを数ポイント上げるか、解像度ダウン（第3節）へ進みます。

3. 容量を大きく削る — 解像度ダウン

解像度は最大のテコです。1080pを720pに落とすと画素数が半分以下になり、同じ見た目の画質に必要なビットレートが大幅に下がります。

ffmpeg -i input.mp4 -vf scale=-2:720 -c:v libx264 -crf 28 -c:a aac output.mp4
  • -vf scale=-2:720 … 高さを720に、幅はアスペクト比を保って自動。-2 は幅を偶数に保つ（H.264の要件）

細部が不要な素材なら scale=-2:480 でさらに小さくできます。scaleフィルタの詳細は動画のリサイズ・拡大縮小を参照。

4. 2パス — 正確な目標サイズに合わせる

厳しい上限ギリギリに収めたい場合は、2パスエンコードでビットレートを狙います。1パス目は動画を解析してログを書き、2パス目はそれを使ってビットを最適配分します。以下を2つの別コマンドとして、どちらも同じ input.mp4 に対して実行します。

1パス目（解析のみ・出力ファイルなし・音声破棄）：

ffmpeg -y -i input.mp4 -c:v libx264 -b:v 1000k -pass 1 -an -f null -

2パス目（1パス目のログを使い最終ファイルを書き出し）：

ffmpeg -i input.mp4 -c:v libx264 -b:v 1000k -pass 2 -c:a aac -b:a 96k output.mp4
  • -pass 1 -an -f null - … 解析run。-an で音声を外し -f null - で出力を破棄
  • -pass 2 … 目標映像ビットレートに制約した最終エンコード
  • -b:v 1000k … 下の計算式で決めた映像ビットレート

2パスの仕組みの詳細は2パスエンコードを参照。

5. サイズ上限からビットレートを逆算する

目標サイズに合わせるには、上限とクリップの長さを映像ビットレートに変換します。音声ビットレートを引き、約10%の余裕を残します。計算式：

合計ビットレート (kbps) = 目標サイズMB * 8192 / 秒数
映像ビットレート (kbps) = 合計ビットレート - 音声ビットレート (kbps)

（8192 = 8ビット/バイト * 1024 KB/MB）。その結果からコンテナのオーバーヘッド分として約10%引きます。

計算例 — 60秒のクリップを、Outlookで安全な15MB・音声96kに収める場合：

合計  = 15 * 8192 / 60      = 約2048 kbps
映像  = 2048 - 96           = 約1952 kbps
約10%の余裕を見て            -> -b:v 1700k を使用

これを第4節の両パスの -b:v 値に入れます。クリップが長くて計算結果のビットレートが極端に小さい（約500kbps未満など）場合は、先に解像度を下げて（第3節）ビットを有効に使いましょう。

6. トラブルシューティング

まだ上限を超える

原因: クリップの長さに対してCRF／ビットレートが緩すぎる。 解決策: CRFを数ポイント上げる、解像度を下げる、または第5節で -b:v を再計算する。

height not divisible by 2 エラー

原因: 出力寸法が奇数。H.264は幅・高さが偶数である必要がある。 解決策: 自動計算する側に -2 を使う（例 scale=-2:720）。

2パスで ffmpeg2pass-0.log が残る

原因: 1パス目が、2パス目で使う統計ログを書く。 解決策: 2パス目の完了後は削除して問題ありません。

圧縮後に音声が悪くなった

原因: 96kbpsは音声には十分だが音楽には薄い。 解決策: 音声を -b:a 128k に上げ、その分映像の予算を少し減らす。

受信者が「再生できない」と言う

原因: 元素材の非標準な画素形式。 解決策: エンコードコマンドに -pix_fmt yuv420p を追加して最大の互換性を確保する。

よくある質問

Q1. なぜ上限ちょうどではなく下を狙う？ A. メールは添付をエンコード（Base64）するため転送時にオーバーヘッドが加わり、ヘッダを上限に含めるサーバーもあります。上限の約80%を狙えば想定外のバウンスを避けられます。

Q2. CRFと2パス、どちらを使う？ A. 「小さく、十分な画質で」ならCRF（第2節）。厳しい上限ギリギリに収める必要があるなら2パス（第4節）。

Q3. クリップが数分ある。それでもメールできる？ A. 可能ですが画質は犠牲になります。長いクリップは添付よりクラウド共有リンクの方が通常は適しています。

Q4. これは動画を再エンコードする？ A. はい——3つの方法すべてが再エンコード（不可逆）です。単なるリムックスではファイルは小さくなりません。動画を圧縮する参照。

Q5. 圧縮せずトリミングだけでも？ A. 一部だけが重要なら、先にトリミングするのが最も効果的な容量削減です——その後、短くなったクリップを圧縮します。

関連記事

Tested with FFmpeg 8.1 — verified with our command-check script 一次ソース: ffmpeg.org/ffmpeg.html / trac.ffmpeg.org/wiki/Encode/H.264 / trac.ffmpeg.org/wiki/Scaling