YMM4で動画の容量を小さくする方法｜2026年版ビットレート実値表と削減率

YMM4（ゆっくりムービーメーカー4／饅頭遣い氏製作）で3分のショート動画を書き出したら270MBを超えていた、という相談はとても多く見かけます。先に結論だけ言い切ってしまうと、動画の容量を決めているのは解像度ではなく「ビットレート × 尺」という一本の掛け算です。ここを直接触れば、容量は数十秒で狙った値まで落とせます。解像度を下げるのは「同じ見栄えを保つのに必要なビットレートが下がる」という間接的な効果を狙う手段であって、容量削減の一次的な操作ではありません。多くの解説記事が「とりあえず解像度を下げましょう」で終わってしまうのは、この順序が逆になっているからです。

そしてもう一点、この記事の立場をはっきりさせておきます。YouTubeに投稿するだけが目的なら、容量削減はそもそも原則として不要な作業です。YouTubeはアップロードされた動画を必ず自前の設定で再エンコードして配信するため、手元のファイルを軽くしても視聴者に届く画質もデータ量も変わりません。むしろ削りすぎたファイルは、劣化した状態からさらに再エンコードされるので画質だけが二重に落ちます。それでも容量を削るべき状況は確かにあり、この記事ではその条件分岐まで含めて整理します。

この記事では、(1) 容量の一次式とつまみ別の削減率の実値、(2) ショート動画（1080×1920・最長3分）向けの推奨ビットレート実値表、(3) 「設定を変えたのに容量が小さくならない」5パターンの診断表、(4) 削るべきケースと削るべきでないケースの分岐、を順に扱います。

なお、YMM4の操作より先に「1本を最後まで作り切る順番」を知っておきたい場合は、ずんだもん動画の作り方を無料ツールだけで9ステップに分解した記事を読むと、この記事がどの工程の話なのかがはっきりします。

結論：容量は「ビットレート × 尺」で決まる

動画ファイルの容量は、次の式でほぼ説明できます。コンテナ（MP4の器）のオーバーヘッドは全体の1%にも満たないので、実用上は無視して構いません。

ファイルサイズ（MB） ≒ （映像ビットレート kbps ＋ 音声ビットレート kbps） × 尺（秒） ÷ 8192

Mbps表記で覚えるなら、「Mbps × 秒 ÷ 8 ＝ 十進MB」が最も暗算しやすい形です。たとえば 8Mbps の3分（180秒）動画なら 8 × 180 ÷ 8 ＝ 180MB。実際に書き出すと音声分が乗るので185MB前後になります。

ここで大事なのは、この式に解像度もfpsもコーデック名も一切入っていないことです。1080×1920だろうと720×1280だろうと、指定した映像ビットレートが同じなら出てくるファイルの容量はほぼ同じになります。解像度を半分にしても、ビットレート指定をそのままにしていれば容量は減りません。これが「解像度を下げたのに容量が変わらない」という定番の行き詰まりの正体です。

解像度やfpsが効いてくるのは、「その見栄えを維持するのに必要なビットレートの下限」を押し下げる方向です。つまり解像度を下げる行為は「ビットレートを下げても破綻しなくなる」という前提づくりであって、ビットレートを実際に下げる操作とセットで初めて容量が減ります。順序としては次のようになります。

1. まず映像ビットレートを目標値に直接設定する（ここで容量はほぼ決まる）
2. 書き出したものを実寸で見て、破綻していたら解像度・fps・尺のどれかを削って必要ビットレートの下限を下げる
3. 下げた下限に合わせてビットレートを再設定する

なお、Windowsのエクスプローラーが表示する「MB」は正確には MiB（1024×1024バイト）なので、上の式で出した十進MBよりおよそ5%小さい数字が表示されます。180MBと計算したファイルがエクスプローラーで「171MB」と出ても計算が間違っているわけではありません。SNSの容量上限が十進MBなのかMiBなのかは明記されていないことが多いので、上限ギリギリを狙うのは避けて1割の余裕を持たせてください。

YMM4のどの設定が容量に効くのか（設定画面の対応表）

YMM4には容量に関わる設定が、プロジェクト側と出力側の二か所に分かれて存在します。この二か所を混同したまま片方だけ触ってしまうのが、最も多い失敗です。

プロジェクトの解像度は「ファイル」メニューの「動画の設定」から開くプロファイルの「画面サイズ」で変更します。縦のショート動画を作る場合はここを 1080×1920 にしておくのが基本で、横向きの 1920×1080 のまま作って出力時だけ縦にすると、左右が切れたり黒帯が入ったりします。

出力側の設定は、動画を出力するときのダイアログにまとまっています。ここに「映像ビットレート」と「音声ビットレート」があり、映像ビットレートは既定で「自動」になっていることが多いです。この「自動」が、容量が読めない最大の原因です。自動のままだとYMM4側が解像度とfpsから妥当そうな値を決めるため、こちらが容量をコントロールできません。容量を狙って作るなら、まずここを数値指定に切り替えるところから始めます。

「詳細設定」を開くと、H.264プロファイル、エンコード速度、そしてハードウェアエンコードのスイッチが現れます。ハードウェアエンコードをオンにすると、Windowsが提供する Media Foundation Transform（GPU側のエンコーダ）を使って書き出すため出力時間が大きく短縮されますが、同じビットレート指定でもソフトウェアエンコードより画質効率が落ちる傾向があります。つまり「オンにしたまま容量を削ると、思ったより汚い」ということが起きます。これは診断表で詳しく扱います。

なお、NVIDIA製GPU向けには有志製作の「YMM4_NVEncPlugin」という出力プラグインがあり、導入すると出力形式に NVENC 系の項目が増え、コーデック・出力品質・ビットレート方式などを個別に選べるようになります。ただしAMDやIntelのGPUでは動作しないなど環境の制約があるため、導入前に配布ページの動作条件を確認してください。

また、UIの表記や項目の位置はYMM4のバージョンによって変わります。本記事の項目名と手元の画面が一致しない場合は、名前が近い項目を探してください。バージョン差で存在しない項目もあるため、見つからない項目を無理に探し続けないことをおすすめします。出力設定全般の基礎についてはゆっくりムービーメーカー動画出力設定も合わせて読むと、どの項目が何のためにあるのかが整理できます。

つまみ別・容量削減率の実値表

ここからが本題です。「どのつまみを回すと何%減るのか」を実値で示します。基準は1080×1920・30fps・3分（180秒）・映像12Mbps・音声192kbpsとし、この条件での計算上のサイズは約277MBです。

映像ビットレートを下げたとき（直接効果）

※音声128kbpsを含めた値。実際の出力は可変ビットレートの挙動により数%前後します。

映像ビットレートは指定値にほぼ比例して容量が動く唯一のつまみです。半分にすれば半分になります。容量を狙い撃ちしたいなら、ここ以外を触る理由はありません。

そのほかのつまみ（間接効果）

この表で一番強調したいのは音声ビットレートの行です。「軽くしたいから音質を落とす」という発想は直感的ですが、実値で見ると3分の動画で1.4MB程度、全体の0.5%しか減りません。ゆっくり解説の合成音声は聞き取りやすさが生命線なので、ここを削るのは損しかしません。音声まわりで困っている場合は容量ではなく別の問題であることが多く、YMM4の音量が小さい対処法のような音量・音質側の調整で解決するケースがほとんどです。

逆に尺を削る行為は、唯一まったく画質を犠牲にしない削減手段です。3分の動画を2分に詰めれば、それだけで33%減ります。無駄な間、冗長な前置き、テロップを読み上げるだけの時間を切るのは、容量対策としてだけでなく視聴維持率の面でも効きます。容量に困ったらまず「この動画、本当に3分必要か」を疑うのが最短ルートです。

fpsと解像度の削減率に幅があるのは、同じ見栄えを保つのに必要なビットレートが素材次第で変わるためです。静止画に文字が乗っているだけの動画なら720pに落としても2.5Mbpsで十分きれいですが、ゲーム画面やパーティクルが常時動いている動画では同じ設定でブロックノイズが出ます。表の数値は「その方向に効く」ことの目安として読んでください。

ショート動画向け推奨ビットレート実値表（1080×1920・最長3分）

ショート動画に絞った推奨値を出します。前提は 1080×1920（縦）、最長3分、音声はAAC 128kbps前後です。YouTubeショートは最長3分まで投稿できるため、ここでは60秒版と3分版の両方の想定サイズを載せます。

動きの多い動画（ゲーム画面、実写素材、常時アニメーション）

静止画中心の動画（立ち絵＋背景＋テロップの解説系）

音声はAAC 128kbpsを基準にしてください。YMM4の既定は192kbpsのことが多いですが、前述のとおり容量差は0.5%程度なので、192kbpsのままでも困りません。128kbpsに落としても合成音声のセリフは十分聞き取れますが、BGMに音楽性を求めるなら192kbpsを維持したほうが無難です。

ここで必ず押さえてほしいのが、上げすぎても無意味だという点です。YouTube（ショートを含む）にアップロードされた動画は、YouTube側で必ず再エンコードされて配信されます。つまり20Mbpsでアップロードしても、視聴者に届くのはYouTubeが決めたビットレートの映像です。元素材が推奨値を十分に超えていれば、そこから先はいくら上げても配信画質はほぼ変わらず、アップロード時間とローカルのディスクを消費するだけになります。

一方で、下げすぎは取り返しがつきません。低ビットレートで出したファイルには既にブロックノイズや色の帯が焼き付いており、YouTube側の再エンコードはそれを復元してくれません。むしろ汚い元素材は「複雑な映像」と判定されて、再エンコード後にさらに破綻することがあります。上の表の「容量重視」列より下は、明確な理由がない限り踏み込まない値だと考えてください。

解説系の動画なら、静止画中心・30fps・4,000〜6,000kbpsが最も費用対効果の良い着地点です。この設定なら3分でも140MB以下に収まり、どのSNSの上限にも余裕を持って通ります。ショート動画の題材や構成そのものを詰めたい場合は雑学動画の作り方で企画側の型を確認しておくと、尺のムダを削る判断がしやすくなります。

【独自視点】YouTubeに上げるなら容量削減は原則不要

ここが本記事で最も伝えたい部分です。容量削減の解説記事は「軽いほど良い」を暗黙の前提にしていますが、用途によっては削減作業そのものが完全に無駄、あるいは有害です。

YouTubeはアップロードされたファイルを受け取ったあと、解像度ごとの配信用ストリームに必ず作り直します。したがって、あなたが手元で185MBを95MBに削っても、視聴者が見る映像のデータ量も画質も一切変わりません。変わるのは「あなたのアップロード時間が短くなる」ことと、「元素材の劣化が上乗せされる」ことだけです。後者は明確なマイナスです。

では、どういうときに削るべきなのか。判断基準は次の分岐です。

アップロード時間の見積もりも計算できます。上り回線が10Mbps出ているなら、277MB（＝約2,216Mbit）のアップロードは理論上220秒ほど、実効で5分前後です。これが1Mbpsしか出ない環境だと理論値で37分、実効で1時間近くかかります。「アップロードが終わらない」は回線の問題であって画質の問題ではないので、この場合に限ってはビットレートを削る価値があります。

他SNSの上限に合わせる場合は、尺の上限と容量の上限の両方を確認してください。各社とも仕様の改定が頻繁で、無料アカウントと有料アカウントで条件が違うことも珍しくありません。本記事で具体的な数値を断定することは避けますので、投稿先の公式ヘルプで現在の値を必ず確認してから目標容量を決めてください。少なくとも「YouTubeで通ったから他でも通る」という前提は成立しません。

確認用に軽いファイルを別途出す運用は、実務ではかなり有効です。本番用は推奨値のまま、確認用は2,000kbps程度で出す。確認用はスマホへの転送が速く、テロップの位置やタイミングの確認には十分な画質があります。本番用と確認用でファイル名に用途を書き分けておけば取り違えも防げます。

「容量が小さくならない」5パターン診断表

設定を変えたのに容量が減らない、という状況はほぼ次の5パターンに収まります。症状から逆引きしてください。

パターン1：プロジェクト解像度が大きいまま

最頻出です。YMM4は出力時にも解像度を変えられますが、出力時の解像度変更は「縮小してから再エンコードする」だけで、ビットレート指定を据え置いたままなら容量はほとんど減りません。むしろ縮小されたぶん、余ったビットレートが使われて無駄に高画質なだけの小さい絵になります。プロジェクト解像度と出力解像度は揃えるのが基本です。

パターン2：可変ビットレートと固定ビットレートの取り違え

YMM4の映像ビットレート指定は、多くのケースで可変ビットレート（VBR）の目標平均値として働きます。つまり「6,000kbpsと指定したのに実際に出てきたファイルが7,200kbps相当だった」ということが普通に起きます。動きの激しい区間でエンコーダが上振れするためです。これは不具合ではありません。容量を厳密に守りたいなら、目標値を1〜2割低めに設定するのが現実的な対処です。60MBに収めたいなら、55MBを狙う設定値を入れておく、という運用にしてください。

パターン3：ハードウェアエンコードで画質優先の判断ができていない

ハードウェアエンコードは速度のための機能で、容量を減らす機能ではありません。同じビットレート指定ならファイルサイズはほぼ同じで、違うのは「その容量でどれだけきれいに詰められるか」です。GPUのエンコーダはソフトウェアエンコードより圧縮効率で劣ることが多いため、ビットレートに余裕がある高画質出力では差が見えませんが、容量を攻めた低ビットレート帯では差がはっきり出ます。「容量を削ったら想定以上に汚くなった」場合は、ハードウェアエンコードをオフにして同じビットレートで出し直すと改善することがあります。時間はかかりますが、投稿用の本番出力なら払う価値のあるコストです。なお改善幅はGPUの世代とドライバに依存するため、まったく差が出ない環境もあります。

パターン4：動画が長すぎる

尺は容量の式に直接掛かる変数です。ビットレートをいじる前に、尺を疑ってください。ショート動画なら、そもそも3分をフルに使う必然性がある企画は多くありません。

パターン5：中間ファイル・exo出力との混同

YMM4にはAviUtl連携用のexo出力があり、これは動画ファイルではなく編集情報のテキストです。また、YMM4で一度出力したMP4をAviUtlに読み込ませて再エンコードする運用も広く使われています。この運用をしている場合、「YMM4の出力設定をいじっても最終ファイルは変わらない」のは当然で、容量を決めているのは最後にエンコードした工程です。自分の制作フローで、最終ファイルを作っているのがどのソフトなのかを先に確定させてください。

実作業手順：3分ショートを目標容量に収める

目標容量が決まっている場合の、逆算の手順です。ここでは「3分の縦ショートを100MB以内に収める」を例にします。

1. 目標容量から許容ビットレートを逆算する。 100MB ÷ 180秒 × 8192 ＝ 約4,551kbps。ここから音声128kbpsを引いて、映像に使えるのは約4,400kbps。
2. 可変ビットレートの上振れを見込んで1〜2割引く。 4,400 × 0.85 ＝ 約3,700kbps を設定値にする。
3. プロジェクト側を確認する。「ファイル」→「動画の設定」で画面サイズが1080×1920、フレームレートが30fpsになっているかを見る。60fpsで作っていて3,700kbpsは厳しいので、この段階で30fpsに落とす判断をする。
4. 出力ダイアログを開き、映像ビットレートを「自動」から数値指定に切り替え、3,700kbpsを入力する。
5. 音声ビットレートを128kbpsに設定する。（192kbpsのままでも容量差は1MB程度なので、こだわらなくても構いません）
6. 「詳細設定」でハードウェアエンコードの状態を確認する。 容量を攻める回なのでオフを推奨。時間がない場合はオンのままでも構いませんが、出力後の画質確認を必ず行う。
7. 出力し、実ファイルサイズを確認する。 目標を超えていたら設定値を1割下げて再出力。下回りすぎていたら1割上げる。1〜2回の往復で必ず収束します。
8. 等倍・実寸で再生して破綻を確認する。 PCの小さいプレビューではなく、スマホの画面で見るのが確実です。テロップの縁、暗いシーンのグラデーション、動きの速い箇所にノイズが出ていないかを見る。
9. 破綻していたら、ビットレートではなく解像度・fps・尺のどれかを削る。 ビットレートを上げると目標容量を超えるので、必要ビットレートの下限そのものを下げにいきます。

この逆算方法は目標容量が決まっているすべてのケースで使えます。覚えておくべきは 「目標MB ÷ 秒 × 8192 ＝ 総ビットレート kbps」 という一行だけです。

出力後のチェックリストも置いておきます。容量を攻めた回は、次の項目を確認してから投稿してください。

• [ ] ファイルサイズが目標値に収まっているか（エクスプローラー表示はMiBなので5%小さく出る）
• [ ] スマホの実機で全編を通して再生したか
• [ ] 暗いシーン・グラデーション部分に色の帯（バンディング）が出ていないか
• [ ] テロップや細い線の周りにモヤ（モスキートノイズ）が出ていないか
• [ ] 動きの速いカットでブロック状の崩れが出ていないか
• [ ] 音声が途切れていないか、映像とズレていないか
• [ ] 投稿先の尺・容量の上限を公式ヘルプで確認したか
• [ ] 本番用と確認用のファイルを取り違えていないか

画質を落とさずに容量を削る手筋と、制作ルートの選択肢

ビットレートを下げる以外にも、画質の犠牲がほぼゼロの削減手筋があります。効果の大きい順に挙げます。

1. 尺を削る。 繰り返しになりますが、これが唯一の完全無劣化の削減手段です。導入の挨拶、同じ内容の言い換え、テロップを読み上げるだけの間。これらを落とすと容量も視聴維持率も同時に改善します。

2. 素材画像を適正サイズにしてから配置する。 4000px幅の画像を1080px幅のプロジェクトに置いて縮小表示すると、編集中の処理負荷が上がり、細かいディテールがエンコーダにとってのノイズになって圧縮効率を下げます。あらかじめ表示サイズに近い解像度にリサイズしてから読み込むと、同じビットレートでも結果がきれいになります。

3. 常時動く背景・パーティクル・激しい画面効果を減らす。 エンコーダは「画面のどれだけが前フレームから変化したか」でビットを配分します。全画面で細かく動き続ける背景は、内容に寄与しないのにビットレートを食い潰す最大の要因です。背景を静止させるだけで、同じビットレートでのテロップの解像感が目に見えて上がります。

4. ノイズやグレインの強い素材を避ける。 ランダムなノイズは圧縮が最も効かない情報です。素材選びの段階で回避できます。

5. H.265（HEVC）を検討する。 同じ画質を同じ尺で3〜5割軽くできますが、コーデックの選択肢はYMM4のバージョンやプラグイン導入状況に依存し、投稿先やチャット共有時の再生互換性の問題も残ります。YouTube投稿のためだけに導入する必然性は薄いので、ローカル保管の圧縮が主目的の場合にだけ検討してください。

ここまではYMM4の中で完結する話ですが、そもそも制作ルート自体を選び直すという選択肢もあります。ショート動画を毎日出す運用だと、出力・容量調整・アップロードの往復そのものが時間を食います。参考として主なルートを並べておきます。

3つ目のAI生成ツールの例として、当サイトが開発・運営しているAIショート動画生成ツールShortyがあります。台本からショート形式の動画を生成するため、ビットレートや解像度の指定という工程自体が発生しないのが特徴です。ただし無料プランには 1本あたり30秒まで／30日で5本まで／保存期間は7日間／出力はショート形式のみ という制約があるため、3分のショートを作りたい場合や立ち絵を細かく動かしたい場合はYMM4のほうが適しています。どちらが優れているという話ではなく、作りたいものと作業時間で選び分けるのが現実的です。ほかにもVidnoz AIの使い方で紹介しているような外部のAI動画ツールもあり、それぞれ得意な形式が違います。用途に合わない道具を無理に使うより、工程ごとに向いたものを組み合わせるほうが結果的に早くなります。

よくある質問

YMM4で容量を一番手っ取り早く小さくする方法は？

出力ダイアログの映像ビットレートを「自動」から数値指定に変え、半分の値を入れることです。容量はほぼ指定値に比例するため、これだけで約50%減ります。

たとえば12,000kbpsで出ていたものを6,000kbpsにすれば、3分の動画で277MBが140MB前後になります。解像度やfpsを触るよりも確実で、往復が1回で済みます。画質が許容できるかは出力後に実機で確認し、破綻していたら解像度やfpsを下げてから再挑戦してください。

解像度を下げたのに容量が変わりません。なぜですか？

映像ビットレートの指定を変えていないからです。容量はビットレート×尺で決まるため、解像度だけ下げてもビットレート指定が同じなら容量はほぼ同じになります。

解像度を下げる本当の効果は「同じ見栄えを保つのに必要なビットレートの下限が下がる」ことです。つまり解像度を下げたあとにビットレートも下げて、初めて容量が減ります。またプロジェクト側の解像度が大きいまま出力時だけ縮小している場合も、同じ理由で容量は減りません。

音声ビットレートを下げれば軽くなりますか？

ほとんど効果がありません。192kbpsを128kbpsに下げても、3分の動画で約1.4MB、全体の0.5%程度しか減りません。

音声は映像に比べて桁違いにデータ量が小さいため、ここを削るのは労力に見合いません。むしろゆっくり解説では音声の聞き取りやすさが視聴維持率に直結するので、削らないほうが得策です。容量に困っているなら映像ビットレートか尺を見てください。

ハードウェアエンコードをオンにすると容量は減りますか？

減りません。ハードウェアエンコードは出力速度を上げるための機能で、同じビットレート指定ならファイルサイズはほぼ同じです。

違いが出るのは「その容量でどれだけきれいに圧縮できるか」です。GPUのエンコーダは圧縮効率でソフトウェアエンコードに劣ることが多く、低ビットレート帯ほど差が目立ちます。容量を攻めた出力で画質が想定より悪い場合は、オフにして出し直すと改善することがあります。ただし改善幅はGPUの世代やドライバに依存し、差が出ない環境もあります。

YouTubeショートに上げるなら容量はどれくらいが適正ですか？

静止画中心の解説系なら1080×1920・30fpsで4,000〜6,000kbps、3分で95〜140MBが目安です。動きが多い動画なら8,000〜10,000kbps程度を見てください。

YouTube側で必ず再エンコードされるため、この帯域を大きく超えて上げても配信画質はほとんど変わりません。逆に極端に下げたファイルは劣化が焼き付いたまま再エンコードされるので、削りすぎのほうがリスクが大きいと考えてください。

容量を小さくすると画質が落ちますか？

ビットレートを下げれば必ず落ちます。ただし尺を削る場合と素材を適正サイズにする場合は、画質を落とさずに容量を減らせます。

画質の落ち方は素材に依存します。静止画に文字が乗っているだけの解説動画は低ビットレートでも破綻しにくく、常時動く背景やゲーム画面は同じ設定でもブロックノイズが出やすくなります。出力後に等倍でスマホ再生して、暗いシーンとテロップ周辺を確認するのが確実です。

ビットレートを指定したのに、出力されたファイルのビットレートが違います

可変ビットレート方式では、指定値は目標平均値として扱われるためです。動きの多い区間でエンコーダが上振れし、指定より高い平均値になることがあります。

不具合ではなく仕様の範囲です。容量を厳密に守りたい場合は、目標値より1〜2割低い値を設定しておくと現実的な範囲に収まります。それでも大きく外れる場合は、尺の長い高速シーンがないか、あるいはプロジェクト解像度と出力解像度が食い違っていないかを確認してください。

出力したファイルを後から圧縮しても大丈夫ですか？

可能ですが、一度エンコードした動画を再度エンコードすることになるため、同じビットレートでもYMM4から直接出したものより画質は劣ります。

やむを得ずローカルの保存容量を空けたい場合には有効な手段です。ただしYouTube投稿用のファイルを後から圧縮するのは、YouTube側でさらに再エンコードされることを考えると劣化の重ね掛けになります。投稿用は最初から目標容量で出し直すほうが結果は良くなります。

3分より短い動画なら設定は変えなくていいですか？

尺が短ければ同じビットレートでも容量は比例して小さくなるので、60秒以内なら推奨値のままでもほとんどの場面で問題は起きません。

60秒・1080×1920・30fps・6,000kbpsなら約47MBで、多くの共有手段の上限に収まります。設定を見直す必要が出てくるのは、3分近い動画を60fpsで作る場合や、上り回線が細い環境でアップロードに時間がかかっている場合です。

YMM4で出力すると容量が大きくなりやすいと聞きましたが本当ですか？

出力時の映像ビットレートが既定で「自動」になっており、高めの値が選ばれやすいことが理由と考えられます。ソフト自体に容量を膨らませる欠陥があるわけではありません。

自動設定は破綻しない安全側の値を選ぶため、静止画中心の動画には過剰なビットレートになりがちです。数値指定に切り替えるだけで、画質を体感的に落とさずに大幅に減らせるケースが多くあります。まずは自動をやめるところから試してください。

まとめ

YMM4で動画の容量を小さくする方法は、突き詰めると次の4行に収まります。

1. 容量はビットレート×尺で決まる。 映像ビットレートを「自動」から数値指定に変えるのが最初の一手で、指定値に比例して容量が動きます。
2. 音声ビットレートは削っても0.5%しか減らない。 削るなら映像か尺です。尺を削るのは唯一の無劣化な削減手段でもあります。
3. 解像度とfpsは間接的な手段。 これらを下げるだけでは容量は減らず、必要ビットレートの下限を下げたうえでビットレートも合わせて下げて初めて効きます。
4. YouTubeに上げるだけなら、そもそも削る必要はない。 削るべきなのは、アップロードが終わらない・ローカルの保存容量が足りない・他SNSの上限に引っかかる、という具体的な理由があるときだけです。

目標容量が決まっているなら、「目標MB ÷ 秒 × 8192 ＝ 総ビットレート kbps」を計算し、可変ビットレートの上振れを見込んで1〜2割引いた値を設定する。これで1〜2回の再出力で必ず収束します。設定を変えても減らない場合は、本記事の5パターン診断表でプロジェクト解像度・自動設定・ハードウェアエンコード・尺・中間ファイルの取り違えを順に潰してください。

なお、UIの項目名や位置はYMM4のバージョンによって変わり、ハードウェアエンコードの効果はGPU環境によって差が出ます。本記事の数値は計算に基づく目安であり、実際の出力は素材の内容によって前後します。最終的には、自分の素材で1回出力して実サイズを測るのが最も確実です。