動画がメールに添付できないときは、先にエラーの容量上限を確認してください。 必要な場面だけを送るなら切り取り、少し小さくしたいなら圧縮、画質を残して長い動画を送るなら共有リンクが候補です。
1. 送信先の上限と、何を残したいかを確認
個人用Gmailは添付ファイルの合計25 MBが上限です。仕事・学校用アカウントでは管理者の設定を確認してください。大きなファイルはGoogleドライブのリンクとして送る方法もあります。 Gmail公式ヘルプ
Outlookはアプリ・アカウント・組織の設定で条件が変わります。Microsoftの案内にはインターネットメールで20 MB、Exchangeの既定で10 MBというメッセージ全体の上限が記載されています。すべてのOutlook環境が25 MBとは限りません。 Outlook公式ヘルプ
| 残したいもの | 最初の選択 | 確認すること |
|---|---|---|
| 数秒の出来事 | 不要な前後を切り取る | 必要な音や場面が残っているか |
| 短い動画の全体 | 容量を指定して圧縮 | 文字・顔・音が確認できるか |
| 長さと画質 | 共有リンクを送る | 宛先に閲覧権限があるか |
ブラウザで小さくして送る手順
- 元動画を残し、圧縮ツールでコピーを選びます。ファイルはサーバーへ送信されません。
- 画質モードで試すか、実際のメール上限より余裕のある目標容量を指定します。長さを取得できない場合は、容量指定ツールで正しい秒数を入力できます。用途はDiscordに限定されません。
- 完了した出力の容量を確認します。上限を超えていれば、そのまま添付せず設定を見直します。
- 冒頭・中間・最後を再生し、説明の文字と音声が残っているか確認します。
- 添付するか共有リンクを送ります。リンクの場合は閲覧権限・有効期限・送信先を確認し、機密動画を誰でも見られる設定にしないでください。
圧縮率は素材で変わります。10秒・音声なしの動画では、23.28 MBから1.83 MBへ縮んだ設定があります。 実測値・画像・条件を確認
スマホで処理が止まる場合
動画の大きさだけでなく、解像度・長さ・端末のメモリが影響します。短い素材で試し、ページを開いたまま待ちます。それでも失敗する場合はPCで処理するか、動画を再圧縮せず共有リンクを使う方法を検討してください。
圧縮せず送れるなら、その方がよい？
すでに容量内で、相手も再生できるなら再圧縮は不要です。繰り返し圧縮すると画質が落ちます。容量内なのに失敗する場合は、宛先側の制限、添付の合計、ネットワーク、アカウントの設定も確認してください。
PC版FFmpegで細かく調整する
ここからはコマンドを使う方向けです。目標容量は計算上の値なので、実際の出力とメールの送信結果を確認してください。
2. 画質（CRF）で縮小
エンコードが1回で済む方法です。画質を保つためのビットレートは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は幅を偶数に保つ（一般的な4:2:0形式の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 -… 解析だけの実行。-anで音声を外し-f null -で出力を破棄-pass 2… 目標映像ビットレートに制約した最終エンコード-b:v 1000k… 下の計算式で決めた映像ビットレート
2パスの仕組みの詳細は2パスエンコードを参照。
5. サイズ上限からビットレートを逆算する
目標サイズに合わせるには、上限とクリップの長さを映像ビットレートに変換します。音声ビットレートを引き、約10%の余裕を残します。計算式：
合計ビットレート (kbps) = 目標サイズMB * 8000 / 秒数
映像ビットレート (kbps) = 合計ビットレート - 音声ビットレート (kbps)（1 MB = 1,000,000バイト、1 kbps = 1000 bit/秒なので係数は8000）。出力は計算より少し大きくなることがあるので、その結果から約10%引きます。
計算例（60秒のクリップを、仮の目標15MB・音声96kに収める場合）：
合計 = 15 * 8000 / 60 = 約2000 kbps
映像 = 2000 - 96 = 約1904 kbps
約10%の余裕を見て -> -b:v 1700k を使用これを第4節の両パスの -b:v 値に入れます。クリップが長くて計算結果のビットレートが極端に小さい（約500kbps未満など）場合は、先に解像度を下げて（第3節）ビットを有効に使います。
6. トラブルシューティング
まだ上限を超える
原因: クリップの長さに対してCRF／ビットレートが緩すぎる。
解決策: CRFを数ポイント上げる、解像度を下げる、または第5節で -b:v を再計算する。
height not divisible by 2 エラー
原因: 出力寸法が奇数。H.264の一般的な4:2:0出力では幅・高さを偶数にします。
解決策: 自動計算する側に -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. 一部だけが重要なら、先にトリミングします。短いほど、同じ画質でも容量は小さくなります。その後、短くなったクリップを圧縮します。