動画を100MB以下に圧縮する方法｜Windowsで無料・アップロードなし

動画を送ろうとしたら「ファイルが大きすぎます」と表示された。Windowsで録画したMP4を100MB以下にしたいけれど、無料サイトへ仕事の動画をアップロードするのは避けたい。そんなときは、PC内で変換するHandBrakeを使い、動画の長さから映像の平均ビットレートを決める方法が選べます。

100MB以下を優先するなら「平均ビットレート」、容量に余裕があり見た目を優先するなら「固定品質」を出発点にします。ただし、どちらも完成後の確認は必要です。設定欄に特定の数字を入れるだけで、すべての動画が同じ容量・同じ画質になるわけではありません。

この記事ではWindows版HandBrake 1.11.2の実画面と、2種類の自作素材を実際に変換した結果を紹介します。対象は、すでに手元にある動画ファイルの容量調整です。録画方法そのもの、著作権保護の解除、動画が壊れた場合の修復は扱いません。確認日：2026年9月10日。

最初に結論：100MB以下へ圧縮する手順

時間がない方は、次の順序で進めてください。100MBはこの記事の検証目標であり、メール、チャット、応募フォームなど特定サービスの現在の上限を示す数字ではありません。提出先が50MBまでなら目標も50MBに変えます。動画の形式、長さ、解像度などが指定されている場合は、その条件を先に確認してください。

1. 元動画を残し、コピーを別名で保存できる空き容量を確保する。
2. 動画の長さを秒に直し、音声分と余裕を引いて映像ビットレートの目安を計算する。
3. HandBrakeで元動画を開き、コンテナをMP4、映像エンコーダーをH.264（x264）にする。
4. 寸法とフレームレートを確認し、意図しない切り抜き・縮小がないか確かめる。
5. 「動画」タブで平均ビットレートを入力し、複数パスの設定を確認する。
6. 「音声」タブで必要なトラックを選び、AACとビットレートを確認する。
7. 別名の保存先を指定して変換し、完成したファイルの実サイズと再生内容を確認する。

例として、長さがちょうど2分、音声が1トラックの動画なら、本記事では映像6200kbps・音声AAC 128kbpsを容量優先の比較条件にしました。映像と音声を合わせた計算上の大きさは約94.92MBです。「2分なら6200kbps」という条件付きの例なので、10分や30分の動画にそのまま使わないでください。

変換後は「100MBを下回ったか」に加えて、「必要な文字が読めるか」「最初から最後まで映像があるか」「必要な音が入っているか」を見ます。容量に収まっても、資料の数字が読めなかったり、説明の声が消えていたりすれば、目的を達成したことにはなりません。

無料ソフトの入手先と、アップロードしない範囲

HandBrakeは公式ダウンロードページから入手できます。公式案内では無料で、利用のためのアカウント登録は不要とされています。Windows版にはインストーラーとZIPパッケージがあり、CPUに合った種類を選びます。検索広告や似た名前の別サイトではなく、配布元を確認してからダウンロードしてください。

Windows版の画面を動かすため、対応するMicrosoft .NET Desktop Runtimeが必要な場合があります。今回確認した1.11.2の配布ページでは10.0系が案内されています。導入画面や必要条件は更新されるため、その時点の公式案内を優先してください。会社管理のPCでは、無料であってもソフトの導入規則を守ります。

「アップロードなし」とは、変換のために元動画をオンライン圧縮サービスへ送らず、PCの中で処理できるという意味です。ソフトのダウンロードや更新確認まで通信しない、という意味ではありません。また、保存先がOneDriveなどの同期フォルダーなら、変換後の動画がそのサービスへ同期されることがあります。機密性を重視する場合は、入力ファイルだけでなく出力先も確認してください。

100MBに収める計算：動画の長さと音声も含める

動画の容量を大きく左右するのは、1秒あたりに保存するデータ量と動画の長さです。解像度は画質や必要なデータ量に関係しますが、「1920×1080だから必ず何MB」という決まりはありません。同じ解像度・同じ長さでも、細かな動きが多い動画と、ほぼ静止したスライドでは圧縮の結果が変わります。

目標容量から映像ビットレートを逆算する

MBを100万バイト、kbpsを1000bit/秒として計算すると、次の式で概算できます。1バイトは8bitなので、容量とビットレートを行き来するときには8倍・8分の1の換算が必要です。音声が複数ある場合は、それぞれのビットレートを合計して差し引きます。

全体容量の概算（MB）
＝（映像kbps ＋ 音声kbpsの合計）× 秒数 ÷ 8000

映像kbpsの目安
＝ 目標MB × 8000 × 0.95 ÷ 秒数 − 音声kbpsの合計

式の0.95は、この記事で計算上の余裕を持たせるために置いた係数です。HandBrakeの公式保証値でも、すべての動画を確実に上限内へ収める安全率でもありません。MP4の管理情報やビットレートの実際の挙動も容量へ加わるため、最後の判定は出力されたファイルのバイト数で行います。

2分なら120秒です。100×8000×0.95÷120−128＝約6205kbpsとなるため、今回の比較では入力しやすい6200kbpsへ切り下げました。ここで、目標に入れる100と音声の128を取り違えたり、120秒を2のまま計算したりすると、想定から大きく外れます。単位を式の横に書いて確認すると防ぎやすくなります。

長さ別の設定例：数字が低いほど画質にも注意

次の表は100MBを目標とし、上の式で音声AAC 128kbps・1トラックを差し引いた計算例です。余裕を持たせて映像の値を切り下げています。実測の推奨画質表ではなく、長さによって使えるデータ量が変わることを示す目安です。長い動画では、この容量の条件自体が目的に合わないこともあります。

動画の長さ	映像の平均ビットレート例	音声込みの概算	注意点
1分	12500kbps	94.71MB	短くても細かな映像では画質を確認
2分	6200kbps	94.92MB	本記事の容量優先の比較条件
5分	2400kbps	94.80MB	画面内の小さな文字に注意
10分	1130kbps	94.35MB	1080pの動きの多い映像では厳しい場合がある
30分	290kbps	94.05MB	映像の用途次第では目標の見直しが必要
60分	80kbps	93.60MB	通常の見やすい動画を期待できる値ではない

たとえば30分を100MBにするために映像を290kbpsへ下げれば、数式上は近い容量を狙えます。しかし、それが視聴に耐える品質かどうかは別問題です。細かな操作説明を読ませたいのに文字が潰れるなら、待ち時間を編集して短くする、章ごとに分ける、提出先が認める共有方法へ変える、といった調整を検討します。

Windowsで「95MB」でも安心できない？ MBとMiBの違い

容量の単位には1000を基準にする表し方と、1024を基準にする表し方があります。この記事の100MBは100,000,000バイトです。一方、100MiBは104,857,600バイトで、同じ「100」という数字でも約4.86MBの差があります。画面によっては1024基準の数字にMBと表示するため、表示された丸い数字だけで判定しないほうが確実です。

Windowsでは完成したファイルを右クリックし、プロパティの「サイズ」欄にあるバイト数を確認します。「ディスク上のサイズ」は保存装置上で占有する量なので、アップロードの容量判定に使う数字とは区別してください。上限ぎりぎりを狙うなら、この違いを見落とさないことが大切です。

100MB以下という条件に対しては、100,000,000バイト以下かをまず確認します。ただし、提出先が実際にどちらの単位で制限しているか、動画以外の添付ファイルを合算するかは別です。「ファイルは条件内なのに送れない」ときは、形式、合計容量、再生時間、アップロード中の通信エラーも確認対象になります。

HandBrakeの設定を実画面で確認する

ここでは、今回の120秒・1920×1080・30fpsの素材を基準に、各項目の役割を整理します。画面の配置や日本語表記はバージョンで変わることがあります。数字を入れた後にプリセットを選び直すと設定が変わる場合があるため、プリセットを選ぶ→必要な項目を変更する→最後に全体を確認するの順に進めてください。

1．変換元を開き、タイトル・範囲・長さを見る

HandBrakeの「変換元」からファイルを選びます。画面のファイル選択が開かない場合は、メイン画面でCtrl＋Oから開く方法もあります。読み込みが終わったら、選択中のタイトルと範囲を見て、変換したい動画全体が選ばれているか確認してください。ファイル名だけでは、別テイクや書き出し途中の素材を選んでいることに気づけない場合があります。

元動画が2分なのに選択範囲が10秒になっていれば、小さな出力ができても「全体を圧縮できた」とは言えません。プレビューや区間指定を使った後は、全体の処理へ戻したかも確認します。元ファイルは残し、出力ファイルは「説明動画_100MB用.mp4」のように区別できる名前にします。

2．コンテナをMP4、映像をH.264（x264）にする

コンテナは、映像・音声・字幕などを一つのファイルへまとめる入れ物です。MP4と書かれていても、中の映像形式は同じとは限りません。本記事では受け渡しの出発点としてMP4とH.264（x264）、AACを組み合わせます。提出先が特定の形式を指定しているときは、その要件に合わせてください。

「Web用に最適化」は、MP4をネットワーク越しに再生しやすくするための配置に関わる項目です。これを有効にすれば必ず大幅に容量が減る、というスイッチではありません。圧縮の調整は主に動画タブの品質・ビットレートと音声の設定で行います。目的の違う設定を一度に変更すると、どれが効いたのか判断しにくくなります。

3．寸法とフレームレートは必要な情報を残す

寸法では出力の幅・高さ、クロップ、縦横比を確認します。自動クロップで意図しない範囲が切られていないか、画面端の注釈や字幕までプレビューで見てください。今回の比較では1920×1080を維持し、クロップを行わず、画素の縦横比も通常の正方形として揃えています。

画面操作の説明では、最初から720pへ下げると、容量の問題より先に文字の判読性が損なわれることがあります。反対に、大きな被写体だけを見せる用途なら縮小を受け入れられることもあります。「とりあえず最小」を選ぶのではなく、読ませる最小の文字や見せたい細部を基準に判断しましょう。

フレームレートは1秒あたりのコマ数です。今回の素材は30fpsなので、比較も30fpsへ揃えました。元が60fpsなら、30fpsへの変更で動きの滑らかさは変わります。元が24fpsや可変フレームレートの素材へ、何も考えず30fps固定を当てはめないでください。受け渡し条件と元動画の性質を踏まえ、変更した場合は動きや音とのタイミングを確認します。

4．容量優先なら平均ビットレートと複数パス

動画タブでH.264（x264）を選び、品質の指定方法を平均ビットレートへ切り替えます。ここに入れるのは、動画全体のファイルサイズではなく映像部分のkbpsです。音声を含めて計算した値を、そのまま映像欄へ全部入れないようにしてください。

今回の条件は6200kbps、複数パス有効、高速な第1パスは無効、エンコーダープリセットfastです。複数パスは映像を調べた情報を圧縮へ活かす方式で、処理が1回で済む設定に比べて時間がかかります。画面で該当項目が選べない場合は、固定品質のままではないか、別のエンコーダーを選んでいないかを確認します。

平均ビットレートは目安となる平均を指定するもので、MP4を指定バイト数にぴったり切り揃える機能ではありません。今回も、静止した文字素材では指定値からの概算よりかなり小さい出力になりました。必要な情報量が少ない素材へ、必ず同じだけデータを使うとは限らないためです。この点も後半の実測表で確認できます。

5．音声をAACにし、必要なトラックを確認する

音声タブでは、必要な音声トラックが選択されているかを先に確認します。映像だけを見て変換を進めると、説明の声がないトラックを選んだり、複数の音声を全部残して容量が増えたりすることがあります。OBSなどでトラックを分けた録画では、特に注意してください。

今回の比較はAAC 128kbps、ステレオ、48kHz、1トラックです。これは比較条件であり、あらゆる音楽や多チャンネル音声に最適な設定を意味しません。会話、音楽、効果音の重要性に応じて、完成音声を聞いて決めます。ステレオへの変更でサラウンドの構成をそのまま維持できるわけでもありません。

パススルーは元の音声を再圧縮せずに引き継ぐ指定です。元音声が大きければ、その容量も引き継ぎます。音声を128kbpsとして計算していても、実際にはパススルーで高ビットレートの音声を残していたら、計算条件と出力条件が一致しません。表示されたエンコーダー名を確認してください。

6．保存先を別名にして変換し、ファイルを確認する

保存先は元動画と別名にし、十分な空き容量があるローカルのフォルダーを指定します。試行錯誤する場合は「元動画」「容量優先」「画質優先」を分けると混同を防げます。変換開始前に、終了後の動作がシャットダウンなどになっていないかも確認しておくと安心です。

エンコード開始後は、進捗表示が完了するまで待ちます。出力先にMP4が見えていても、変換中は中身が完成していない場合があります。大きさだけを見て送らず、完了状態と再生を確認してください。エラーになったときは、元動画を上書きせずにログと保存先を確認します。

実測：同じ120秒でも、圧縮結果はこれだけ変わった

検証には、文字を並べた自作の静止画面と、動くテストパターンへノイズを加えた自作の映像を使いました。どちらも120秒、1920×1080、30fps、音声は440Hzの合成テスト音です。実際の会議録画、ゲームプレイ、映画、人物の撮影映像ではありません。この2本は素材による違いを見る比較試験であり、一般的な動画の平均圧縮率を示すものではありません。

元ファイルはFFmpegで作成したMKVで、映像はH.264・CRF10・ultrafast、音声は非圧縮PCMです。動き素材ではフレームごとに変わるノイズを加えているため、元ファイルはかなり大きくなっています。一般的なスマートフォン動画より圧縮前の条件が特殊である点を差し引いて読んでください。圧縮率を大きく見せるために、同じ改善がすべての動画へ出るとは扱いません。

検証PCのCPUはIntel Core Ultra 7 265KFです。GPUのハードウェアエンコードは使わず、CPUのx264で圧縮しました。

圧縮はHandBrakeCLI 1.11.2で実行しました。本文の操作画像は同じバージョンのWindows GUIです。検証時はH.264（x264）、プリセットfast、映像処理のスレッド数4、30fps固定、寸法維持、クロップなし、音声AAC 128kbpsへ揃えています。RF22、RF28、平均6200kbps・複数パスという3条件だけを比較しました。GUIの初期プリセットを選ぶだけで、この検証と全設定が同じになるわけではありません。

素材	条件	容量（MB）	バイト数	変換時間	100MB以下
文字中心	元動画（MKV）	29.02	29,015,038	—	○
文字中心	固定品質 RF22	3.49	3,490,247	12.1秒	○
文字中心	固定品質 RF28	3.14	3,137,822	11.5秒	○
文字中心	平均6200kbps・複数パス	5.37	5,371,964	23.6秒	○
動き＋ノイズ	元動画（MKV）	3752.27	3,752,267,158	—	×
動き＋ノイズ	固定品質 RF22	122.50	122,503,827	60.3秒	×
動き＋ノイズ	固定品質 RF28	46.45	46,450,251	44.7秒	○
動き＋ノイズ	平均6200kbps・複数パス	95.07	95,072,439	72.4秒	○

所要時間は当該PCで測った参考値です。PCの性能、ほかの処理、保存装置、映像の内容で変わり、別のPCで同じ時間になるとは限りません。表の容量は実ファイルのバイト数を100万で割ったMBです。すべての出力について映像と音声のストリームを調べ、全区間のデコードがエラーなく完了することを確認しました。音の聞こえ方や個々の再生機器への対応を、その検査だけで保証するものではありません。

文字中心の素材：必要以上の容量を使わない選び方

文字素材は画面がほぼ変わらないため、RF22でも約3.49MBまで小さくなりました。RF28は約3.14MBで、差は約0.35MBです。すでに100MBを大きく下回るなら、その差のために読みやすさを犠牲にする必要があるかを考えます。設定を強くするほど常に価値が増えるわけではありません。

比較画像は同じ45秒位置の同じ領域を切り出しています。ページに縮小表示された画像だけだと差を見落としやすいので、確認時は元画像を同じ倍率で見比べてください。細い線、濁点、数字、色付きの文字は、背景の大きな図形より先に変化へ気づきやすい箇所です。資料に実際に使われている最小の文字で判断することが重要です。

今回の文字素材で平均6200kbpsを指定した結果は約5.37MBでした。映像6200kbpsと音声128kbpsから計算した94.92MBに一致していません。静止した内容では指定した平均まで使わない結果があり、「平均ビットレート指定＝必ずその大きさのファイルを作る」と解釈できないことを示しています。小さくても必要な情報が残っていれば、容量を埋める必要はありません。

動きの多い素材：RFだけで容量上限は決められない

動き素材のRF22は約122.50MBで、今回の100MBの上限を超えました。一方、同じRF22を使った文字素材は約3.49MBです。長さと解像度が同じでも、内容の違いで結果に大きな差が出ています。「RF22なら100MB以下」のような固定の対応表は作れません。

RF28では動き素材が約46.45MBになりました。ただし、ノイズなどの細部を含む素材なので、サイズが下がったことだけをもって「画質を落とさず圧縮できた」とは言えません。平均ビットレートで容量に余裕を持たせる方法も含め、見た目と容量を並べて選ぶのが現実的です。

平均6200kbps・複数パスの結果は95,072,439バイト、約95.07MBで、100MB以下に収まりました。映像と音声だけの概算94.92MBとは約0.15MBの差があり、今回の出力では用意した余裕の範囲内でした。これは今回の120秒素材で確認した結果です。時間が長い動画にも6200kbpsを当てはめる、余裕を設けず100MBぎりぎりを計算する、といった使い方は避けてください。

今回の動き素材は圧縮の違いを出しやすいテストパターンです。特に細かなノイズの保存は、普段の画面操作録画とは条件が異なります。実際に送る動画でも同じくらい小さくなる、同じ設定が最も美しくなる、という結論には広げません。自分の動画の重要な場面を短く試し、その後に全体を変換してください。

容量に余裕があるなら固定品質から試す

固定品質は「指定した容量になるまで削る」という方法ではなく、選んだ品質の設定に応じて必要なデータ量を使う方法です。HandBrakeでは多くのプリセットで採用されています。動画の長さや内容によって容量が変わるので、提出上限に厳密に合わせたいときとは判断の軸が違います。

RFは小さいほど高品質。ただしエンコーダーを揃える

今回使ったx264では、RFの数値を小さくすると高品質側、大きくすると低容量側へ調整します。RF22からRF28への変更は品質を下げる方向です。数値が大きいほど画質が良い、という直感と逆になるため注意してください。無関係なスライダーを動かさず、現在選んでいる映像エンコーダーと品質方式も合わせて見ます。

HandBrake公式の画質調整ガイドでは、x264・x265の1080p向けの出発点としてRF20〜24が紹介されています。ただし、その範囲ならどんな文字も潰れないという保証ではありません。また、x264とx265やAV1の同じRF番号を同じ画質として比較することもできません。エンコーダーを変えるときは、数値をそのまま流用せず見た目を比較します。

最初に20〜30秒ほどの重要場面を試すと、全体の変換を何度も待つ負担を減らせます。スライドなら最も文字の細かいページ、操作説明なら画面をスクロールする場面、動く被写体なら動きが速い場面を含めましょう。静かな冒頭だけで良好に見えても、本編全体が良いとは限りません。

プリセットのfastは、単純な低画質スイッチではない

HandBrake全体のプリセットと、x264のエンコーダープリセットは役割が違います。前者は寸法や音声などを含む設定のまとまりで、後者のfastやmediumなどは圧縮処理にかける探索・計算の傾向を変えるものです。両方を「プリセット」と呼ぶため、作業メモではどちらを変えたか書いてください。

エンコーダープリセットを遅い方向へ変えると処理時間が増える一方、容量と品質の関係が改善する場合があります。しかし、この比較試験ではfast以外の速度を実測していないため、mediumやslowへ変えれば何％小さくなる、とは言えません。大量変換であっても、まず同じ短い場面で所要時間と結果を確かめます。

仕事をしながら変換するときは、同時に複数の重い処理を走らせないようにします。ノートPCでは電源状態や温度、デスクトップでもほかのエンコード処理が時間に影響します。この記事の所要時間だけを基準に、遅いから故障していると判断しないでください。

まだ100MBを超えるときは、この順番で見直す

1．計算の前提と実際の設定が一致しているか

最初に確認するのは動画の長さです。2分だと思って計算した動画が2分20秒なら、同じビットレートでも長い分だけ容量は増えます。端数を切り捨てず、実際の秒数で計算し直します。チャプターや複数タイトルがある場合も、処理した範囲を見ます。

次に、音声のトラック数、ビットレート、パススルーの有無を確認します。音声を1本の128kbpsとして予算を組んだのに、出力では2本の320kbpsを残していないでしょうか。映像の平均ビットレートと音声を別々に確認し、固定品質へ戻っていないかも確かめます。

最後に、送ろうとしているファイルが今回の出力かを確かめます。似た名前の前回ファイルや、元動画を選んでいるケースは意外と見落としがちです。更新時刻、保存先、バイト数をセットで照合すると、設定を無駄にやり直さずに済みます。

2．少しだけ超過したなら、余裕を増やして再計算する

計算条件が合っていても上限を少し超えた場合は、映像に割り当てるデータ量を下げて再変換します。たとえば0.95の係数で余裕が不足したなら、0.90へ変えて計算し直す方法があります。これは調整の考え方であって、係数を変えれば必ず一度で成功するという保証ではありません。

再変換するときは、圧縮済みの失敗作ではなく、保存しておいた元動画からやり直します。圧縮を重ねても消えた情報は戻らず、余計な劣化を招く可能性があります。元動画・試作・採用版のファイル名を分け、採用版が決まるまで元動画を残してください。

目標を超えているかどうかは数値で判定できますが、どこまで画質を下げてよいかは用途による判断です。容量を下げた後の確認項目を省かず、送信先で重要な情報が読めるかに戻って評価します。

3．内容を削らずに待ち時間や不要区間を短くする

長い待ち時間、録画開始前の準備、終了後の無操作があるなら、必要のない区間を取り除くと、見やすさと容量の両方に効くことがあります。同じ平均ビットレートなら、時間が短くなった分だけ概算容量も減ります。内容の価値を落としにくい調整として、極端な画質低下より先に検討できます。

ただし、提出要件で無編集の連続記録が必要な場合や、前後の文脈が大切な動画では勝手に切り詰められません。編集してよい範囲を確認し、操作説明ならどこからどこまでが必要な手順かを先に整理してください。切り詰めによって音と映像のつながりが不自然にならないかも見ます。

4．解像度・FPSを変えるなら、変えた部分だけ評価する

大きな映像を小さい画面で見てもらう用途では、1080pから720pへの縮小が選択肢になります。ただし、細い文字が主役の動画では、縮小で読めなくなった文字を品質スライダーだけで戻すことはできません。先に「読む必要のある情報は何か」を決めてください。

60fpsから30fpsへの変更も、動きの滑らかさとの交換になります。全体の平均ビットレートを固定している場合、解像度やFPSを下げただけで計算上の容量が自動的に半分になるわけではありません。使えるデータ量を、残した画素やフレームへ配分しやすくする面があります。容量と見た目の関係を分けて考えます。

寸法・FPS・ビットレートを一度に変えると、悪化した原因を追いにくくなります。最初は一つだけ変更し、同じ場面を比較してください。その記録が残っていれば、別の動画を作るときにも判断を再利用できます。

5．条件が厳しすぎるときは、渡し方を相談する

1時間の操作説明を100MBへ押し込むような条件では、残したい情報と容量が両立しないことがあります。その場合は、章ごとに分割してよいか、共有リンクで渡してよいか、資料のPDFと短い補足動画へ分けてよいかを提出先へ相談します。圧縮の設定だけで解決すべき問題とは限りません。

共有リンクを使う場合は、閲覧権限、ダウンロード可否、期限、第三者への転送を含めて確認してください。オンラインへのアップロードを避けるためにこの記事へ来た方は、便利さだけで公開リンクに切り替えないようにします。会社や顧客のルールに合わない方法は選びません。

小さくならない・画質が悪いときのよくある誤解

ZIPにすれば動画も大幅に縮む？

MP4の中の映像は、すでに圧縮されていることが多いため、ZIPへまとめても期待するほど小さくならない場合があります。ZIPは複数ファイルをまとめる用途には使えますが、映像の品質とデータ量を調整する処理とは違います。提出先がMP4を要求しているなら、ZIPへ変えることで形式条件から外れる可能性もあります。

今回はZIP圧縮の容量比較までは実測していません。そのため、何％しか減らないという一律の数字は示しません。少なくとも、動画を100MB以下へ調整したい目的で、ZIPだけを繰り返し試す必要はありません。

拡張子をMP4に変えるだけでは変換にならない

ファイル名の末尾を.mkvから.mp4へ書き換えても、中身の形式は変わりません。拡張子は名前の一部であり、動画データを作り直す命令ではないためです。別のコンテナへ移すだけの処理と、映像を再圧縮して容量を調整する処理も区別してください。

元がMP4だからHandBrakeへ入れられない、というわけではありません。MP4からMP4へ変換しても、中の映像・音声の設定を変えれば容量は変わります。逆に、元が十分に小さく効率よく圧縮されていれば、設定次第で大きくなることもあります。

変換したのに大きくなった場合

元の動画より高品質側の設定へ変える、解像度やFPSを不必要に増やす、大きい音声を追加する、といった条件では出力が大きくなることがあります。HandBrakeへ入れるだけで必ず小さくなるわけではありません。元動画と出力の長さ・解像度・映像形式・音声数を比べ、何を変えたのか確認します。

高品質設定へ変換しても、元の圧縮で失われた細部が戻るとは限りません。たとえば文字がすでにぼやけている元動画を高ビットレートで書き出しても、読める文字へ復元できるという保証はありません。容量だけ増えた場合は、もっと情報の残っている元録画や、編集前の素材へ戻れるかを検討します。

音声を削れば十分小さくなる？

AAC 128kbpsの音声が120秒あると、計算上は約1.92MBです。映像の容量が何百MBもある場合、音声を消すだけで目標へ届くとは限りません。動画の主な情報が説明の声なら、それを削ることは目的に反します。音声の重要性と、削減できる容量を両方見て判断します。

反対に、長い動画や複数音声トラックでは音声の占める量が無視できなくなります。どれを消してよいか分からない場合は、トラックごとに内容を確認し、必要な声や音楽を残します。完成後に無音と分かった場合、容量の設定を直す前に入力・出力の音声の選択を調べてください。

送信前のチェック：小さいファイルを作って終わりにしない

最後は、実際に相手へ渡すファイルを開いて確認します。元動画の再生画面を見ながら出力の出来を判断していないか、ファイル名と場所を見直してください。変換が成功したという表示は、必要な内容をすべて残せたという編集上の判断とは別です。

• 容量：ファイルの実バイト数が目標以下か。複数添付するなら合計条件も確認。
• 長さ：冒頭・中盤・終盤があり、意図せず区間が切れていないか。
• 文字：数値、注釈、メニュー、字幕が提出先で見る大きさでも読めるか。
• 動き：スクロールや速い場面が不自然になっていないか。
• 音：説明の声や必要な音楽が入り、急な音量変化や無音区間がないか。
• 同期：操作と説明、映像と音のタイミングがずれていないか。
• 共有条件：形式、長さ、ファイル名、提出先の権限・締切条件を満たしているか。
• 原本：採用版を確認するまで元動画を残しているか。

細かい確認が必要な仕事用の動画では、数秒だけを見て終わらず、できるだけ全体を再生します。重要な箇所には時刻のメモを付け、変換前後で同じ位置を比べると確認漏れを減らせます。再生ソフトによる違いを疑う場合は、提出先が使用する環境や指定の確認方法に合わせます。

なお、元録画からマイクの声が小さい、配信や録画の段階でカクついている、といった問題は、完成動画の圧縮だけでは直らないことがあります。録画前の設定を見直す必要がある場合は、次の関連記事も参照してください。

動画の容量圧縮でよくある質問

画質を一切落とさずに100MB以下へできますか？

元動画と目標容量によるため、できるとは約束できません。本記事のH.264設定は、元の情報をすべてそのまま保存する変換ではありません。見た目の変化が気にならない場合でも、数学的に無劣化という意味にはなりません。情報を保ったままの容量削減が可能かと、見た目を許容できるかは別の判断です。

10分の動画を100MB以下にすると、必ず荒くなりますか？

内容によります。ほとんど静止した大きな文字のスライドと、細かな動きやノイズの多い映像では必要なデータ量が違います。表の1130kbpsは容量の計算例であり、10分動画の品質保証ではありません。最も厳しい場面を試し、必要な情報が残らなければ時間や共有方法を見直してください。

複数ファイルをまとめて100MBにする場合は？

まず合計で100MBなのか、1ファイルにつき100MBなのかを確認します。合計なら、各動画へ容量の予算を割り振る必要があります。同じ配分にするより、長さや内容の細かさ、重要度に合わせて分けるほうが合理的な場合があります。各ファイルが個別に100MB以下でも、合計の条件を満たすとは限りません。

Windowsで変換したMP4をスマホで見てもらえますか？

MP4・H.264・AACは受け渡しでよく使われる組み合わせですが、拡張子だけで全機種・全アプリでの再生を保証できるわけではありません。解像度、プロファイル、音声、受け渡し方法によって差が出ることがあります。相手の環境に指定があれば従い、可能なら短い試作を確認してもらってから全体を作ります。

機密動画なら必ず安全ですか？

ローカル変換は、オンライン圧縮サービスへ元動画を渡さずに済む選択肢です。ただし、PCの管理状態、ソフトの配布元、保存先の同期、完成ファイルの共有権限まで自動的に安全になるわけではありません。機密情報や第三者の映像を扱う場合は、所属先の規則や利用許可を優先してください。

容量は減ったのに音が消えたら、やり直せますか？

元動画に必要な音が記録されていて、その元動画を残していれば、音声トラックを選び直して変換する余地があります。元の時点で記録されていない音を、圧縮の設定だけで復元することはできません。いきなり有料修復ソフトへ進まず、まず元動画を再生し、音声トラックの存在と内容を確認します。

まとめ：容量は計算で狙い、完成ファイルで確かめる

100MB以下を優先するときは、動画の長さを秒で確認し、音声分と余裕を引いて映像の平均ビットレートを決めます。HandBrakeでは元動画を残したままMP4へ変換し、出力のバイト数と必要な映像・音声を確認してください。容量に余裕があるときは固定品質を試し、見た目が良い条件を選べます。

今回の比較では、同じ120秒・1080p・RF22でも、文字素材は約3.49MB、動き素材は約122.50MBでした。設定の数字だけで結果は決まりません。「100MBに入ったか」と「相手に必要な情報が伝わるか」を両方満たしたファイルを採用することが、この作業のゴールです。

参照した公式資料と検証の範囲

• HandBrake公式：ダウンロードと配布元の案内
• HandBrake公式：品質の調整
• HandBrake公式：固定品質と平均ビットレート（draft表記のある資料。本文の数値例とは区別）
• HandBrake公式：CLIオプションの説明
• HandBrake公式：変換元を開く

確認日は2026年9月10日です。UI画像は検証用のWindows環境で撮影し、比較画像は自作動画の同じ時刻から作成しました。音声は合成テスト音で、人の会話や音楽の聞きやすさを評価した試験ではありません。計算例・自作素材の実測・一般的な確認手順を区別して掲載しています。