配信がカクつく、録画が重い、書き出しが荒い。x264の設定は項目が多く、同じ言葉でもOBSとFFmpeg、AviUtlで意味がズレるため、「結局どれが正解なのか」が分からなくなりがちです。しかも、配信は安定性が最優先、録画は画質と容量のバランス、書き出しは上限制約や納品条件など、用途が変われば最適解も入れ替わります。
本記事では、まず最初に“迷いを消すための4つの決め事”をチェックリストで整理し、次にOBS配信・OBS録画・FFmpeg・AviUtl（x264guiEx）それぞれの用途別テンプレを提示します。さらに、カクつき・ブロックノイズ・音ズレなど、よくある失敗を「症状→原因→直し方」で切り分けできるようにまとめました。読み終えたときには、あなたの環境で再現できる設定が一本に絞れ、次に何を調整すべきかも迷わなくなります。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
x264設定で最初に決めるべきこと
用途が配信か録画か書き出しかで正解が変わる
x264の設定で迷う最大の理由は、「同じH.264でも、使う場面によって最適解がまるで違う」点にあります。配信・録画・書き出しは、求められる条件がそれぞれ異なり、優先順位が入れ替わります。ここを曖昧にしたまま設定を探すと、他人の成功例を真似したのに自分の環境では失敗する、ということが起こりがちです。
まず押さえたいのは、x264はCPUで映像を圧縮する方式で、設定次第で「画質」「ファイルサイズ」「処理の重さ（負荷）」「遅延・安定性」が大きく変わることです。そして、用途ごとに“守るべきルール”が変わります。
配信（OBS）
配信はリアルタイムです。映像は決められた速度でエンコードし続ける必要があり、途中で詰まると「エンコード遅延」「フレーム落ち」「音ズレ」「配信停止」などの事故に直結します。さらに配信先の推奨や上限、視聴者側の回線事情が関わるため、安定性と再生互換が最優先になりやすいです。録画（OBS）
録画は自分のPC内に保存するため、配信ほどの制約はありません。多少ビットレートが上下しても問題になりにくく、画質を軸に効率よく保存できます。一方で、録画中にゲームをするならCPU/GPUの取り合いは起きるため、負荷配分は重要です。書き出し（AviUtl/FFmpeg）
書き出しはリアルタイムである必要がありません。時間をかけて高画質を狙うこともできますし、投稿先の上限に合わせて容量を調整することもできます。つまり、品質優先にも、容量狙い撃ちにも振れるのが書き出しです。
この3つを最初に決めるだけで、設定の迷いは半分以下になります。「配信なのにCRFの話を読んでいた」「録画なのにCBR固定のまま容量に悩んでいた」のようなズレを避けられるからです。
画質・容量・遅延・互換性の優先順位を決めるチェックリスト
次に重要なのは、何を優先するかを“先に”決めることです。x264の設定は「これが絶対正解」というものではなく、目的に合わせてトレードオフを選ぶ作業です。優先順位が曖昧だと、設定を触るたびに別の問題が出て、永遠に落ち着きません。
以下のチェックリストを埋めてください。ここが埋まると、設定の選択肢が一気に減ります。
用途：配信／録画／編集して投稿／長期保存
画質の基準：文字が読めればOK／ゲームの動き重視／実写や暗部を丁寧に残す
上限（制約）：配信先の上限、回線の上り速度、投稿サイトの容量制限、保存容量
負荷許容：ゲーム優先で軽くしたい／多少重くても画質を上げたい
解像度・fps：1080p60、1080p30、720p60、720p30など
PC構成：CPUの世代・コア数、GPUの余力、同時起動するアプリ
視聴・利用環境：スマホ視聴が多い／PC視聴中心／後で編集する予定がある
ここでありがちな落とし穴は、「画質を上げたい」だけを目的にして、制約（上限・負荷）を後回しにしてしまうことです。配信は特に、上限を超えた瞬間に“画質が良い”以前に成立しなくなります。逆に録画や書き出しは、上限が緩い分、画質基準（CRF）中心に設計した方が満足度が高くなるケースが多いです。
用語の混乱を防ぐ CRF と CBR とプリセットの関係
x264設定の混乱は、用語が似ているのに役割が違うことから生まれます。ここでは最短で整理します。覚えるべきなのは「CRF」「CBR」「プリセット」の3つの役割です。
CRF（品質基準）
画質を基準にして必要なだけビットレートを使う方式です。数値が小さいほど高画質（＝サイズ増加）、大きいほど低画質（＝サイズ削減）になります。録画や書き出しで強力です。
ただし、動きが激しい場面ではビットレートが跳ねやすいので、上限が厳しい用途（配信や厳格な仕様）では扱いに注意が必要です。CBR（固定ビットレート）
ビットレートを一定に保つ方式です。配信でよく使われるのは、回線や配信サーバーの挙動を安定させやすいからです。
ただし、固定である以上、複雑な場面ではビット不足になりやすく、単純な場面ではビットが余りやすい、という性質があります。つまり、上手く使えば安定する一方、画質の伸びしろは制約されます。プリセット（速度と圧縮効率の交換）
ざっくり言えば「同じ画質を狙うために、どれだけ計算を頑張るか」です。遅いプリセットほど圧縮効率が上がりやすく（同じ画質でサイズが小さくなりやすい）、その代わりCPU負荷が増えます。
配信では、遅いプリセットにするとCPUが耐えられず事故になりやすいので、まずは安定重視で選ぶのが鉄則です。
関係を一言でまとめると次の通りです。
CRF／CBRは「ビットの使い方のルール」
プリセットは「そのルールの中で、どれだけ賢く圧縮するか」
この整理ができると、設定画面で何を触れば良いかが明確になります。
x264の基本設定を理解する
プリセットが効く理由と medium が基準になる根拠
プリセットは、x264の内部で使う圧縮手法の強度をまとめたパッケージです。遅いほど探索や分析を丁寧に行うため、同じビットレートなら画質が上がりやすく、同じ画質ならビットレートを下げやすくなります。
ただし、ここで誤解が多いのが「プリセットを遅くすれば画質が劇的に上がる」という期待です。実際は、画質の差は“じわじわ”です。特に配信のようにビットレート上限が決まっている場合、プリセットを遅くしても劇的改善にはならず、CPU負荷だけが増えることもあります。そのため、配信では「遅くできるなら遅く」ではなく「安定する範囲で最適」を狙うのが現実的です。
一方で、書き出しのように時間が許すなら、fast→medium→slowと段階的に遅くすることで、同程度の画質でもサイズがわずかに削れたり、破綻が目立ちにくくなったりすることがあります。特に暗部のノイズや激しい動き、細かい文字などで差が出やすいです。
プリセット選びは次のように考えるとブレません。
配信：まずveryfast〜fasterで安定 → 余裕があればfastへ
録画：fast〜medium中心 → 重ければveryfastへ、余裕があればslowも検討
書き出し：medium〜slow中心 → 時間をかけられるならveryslowまで視野
「mediumが基準」という話が出てくるのは、x264における標準的なバランス点として扱われることが多いからです。とはいえ、基準＝正解ではありません。用途に合わせて基準点を動かすのがコツです。
CRFの目安と数値の読み方
CRFは、x264設定で最も強力な“迷いを減らす仕組み”です。理由は単純で、ビットレートをいちいち決めなくても、画質基準で自動的に配分してくれるからです。
ただし、CRFには落とし穴があります。それは「数値だけ見ても最終ファイルサイズが読みにくい」ことです。同じCRFでも、内容が静止画に近いか、動きが激しいか、暗部が多いかで必要ビットレートが変わるため、結果のサイズも変動します。つまりCRFは、品質を安定させる代わりに、サイズが変動する方式です。
目安としては次のように捉えると扱いやすいです。
18〜20：かなり綺麗。素材が良いほど差が見える。容量は増えやすい。
21〜23：バランス帯。迷ったらここから。
24〜28：容量重視。文字や暗部、早い動きで破綻が出たら戻す。
実運用では「一発で決める」より、「短尺のテストで決める」が失敗しません。特に、次のシーンで必ず確認してください。
テロップやUIなど、細い線と文字
暗い場面（夜、影、室内）など、暗部の階調
激しい動き（FPSの視点移動、格闘、スポーツ）など、動きが速い場面
この3箇所で破綻が出ないCRF値が、その素材にとっての“使える値”です。
2passとABRが向くケース
2pass（2パス）は、容量を狙い撃ちしたいときの王道です。1回目のエンコードで映像の複雑さを解析し、2回目で「どこにビットを割り当てるか」を最適化します。結果として、指定した平均ビットレート（ABR）に近づけつつ、画質のムラを抑えやすくなります。
2passが向く代表例は次の通りです。
投稿サイトの仕様で「この容量以下」と決まっている
クライアントワークや納品で、平均ビットレート指定がある
長尺動画で、容量を厳密に管理したい
逆に向かないのは、リアルタイム性が必要な配信や、手早く録画したいケースです。2passは2回エンコードするので時間が倍近くかかります。また、最近の用途では「画質はCRFで決め、容量は多少ブレてもよい」という考え方の方が運用しやすい場面も多いです。容量が厳しいときだけ2passに切り替える、という持ち方が現実的です。
VBV maxrate と bufsize が必要になる場面
VBV（最大ビットレート制御）を理解すると、設定の“事故”が減ります。CRFは品質基準でビットを使うので、複雑な場面で一時的にビットレートが跳ね上がることがあります。保存用途なら問題になりにくいのですが、次のような場面では困ります。
デバイス側や配信先が「最大ビットレート」を前提にしている
ネットワークが不安定で、ピークが高いと破綻しやすい
仕様上「この上限を超えるな」と決まっている
VBVの考え方は、「瞬間的なピークを抑えるために、バッファを用意して制御する」です。maxrateが上限、bufsizeがバッファ量だと考えると理解しやすいです。上限が必要な用途では、CRFを使いつつVBVでピークだけ抑える、という設計が有効になります。
ただし、VBVを強くかけすぎると、複雑な場面でビットが足りなくなり、ブロックノイズが増えることがあります。上限に合わせる必要がある場合でも、解像度やfpsを落として“必要ビット量そのもの”を減らす方が、見た目が良くなるケースは多いです。
OBS配信でのx264おすすめ設定
配信プラットフォームの上限を先に確認する
配信設定の第一歩は、x264の項目を触ることではありません。配信先と配信フォーマット（解像度・fps）を決めることが最優先です。配信先には推奨や上限があり、視聴者側の受け取りやすさにも影響します。
ここが曖昧なまま「ビットレートは高いほど良い」としてしまうと、回線が詰まり、結果として画質が落ちたり、止まったり、音ズレしたりします。配信は“安定して届いて初めて画質が意味を持つ”ので、上限内で最大の見栄えを狙うのが基本です。
手順としては次の順番が安全です。
配信先（YouTube/Twitch等）を決める
視聴者が多いデバイス（スマホ/PC）を想定する
解像度とfpsを決める（迷ったら720p60 or 1080p30）
回線の上り速度を測る（余裕を残す）
上限内でビットレートを決める
そのビットレートで安定するプリセットを選ぶ
1080p/720p別の設定テンプレ
まずは“動く”テンプレを持つことが重要です。以下はOBS配信向けのスタート地点として使えます。配信先の推奨・上限や、自分の回線に合わせて調整してください。
| 目的 | 解像度/FPS | レート制御 | ビットレート目安 | キーフレーム間隔 | x264プリセット | 使いどころ |
|---|---|---|---|---|---|---|
| 安定最優先 | 720p/30 | CBR | 2500〜4000 | 2秒 | veryfast | 回線弱め、PC負荷高め |
| バランス | 720p/60 | CBR | 3500〜6000 | 2秒 | veryfast〜faster | 動きのあるゲーム向き |
| 高精細寄り | 1080p/30 | CBR | 4500〜6500 | 2秒 | faster〜fast | 文字も見せたい配信 |
| 高負荷構成 | 1080p/60 | CBR | 上限内 | 2秒 | faster〜fast | CPUに余力がある場合のみ |
重要なのは、「解像度・fps・ビットレート・プリセットはセットで考える」ことです。1080p60は必要ビット量も処理負荷も大きいため、無理に狙うと破綻しやすくなります。実際の視聴体験で差が出やすいのは、1080p60よりも「止まらない」「文字が読める」「ブロックが少ない」ことだったりします。
プリセット選び（veryfast〜slow）の判断基準
配信でプリセットを選ぶときは、画質から入ると失敗しやすいです。まずは安定し、余力があるなら改善する、という順番が安全です。
判断の基準は次の通りです。
配信中にゲームがカクつく／PCが重い
→ veryfastへ寄せる。必要なら解像度やfpsも落とす。配信は安定しているが画質が荒い
→ まずビットレートが足りているか確認。足りないなら解像度/fpsを調整。
→ CPUに余裕があるならfaster→fastへ。CPU使用率が常に高い
→ プリセットを遅くするのではなく、逆に速くする。
→ どうしても画質を上げたいなら、NVENCなどGPUエンコードへの切り替えも選択肢。
「プリセットを遅くすれば画質が上がる」という直感は半分正しいのですが、配信では“遅くした瞬間に事故る”ことがあるので、まず安定を守るのが鉄則です。
配信が重い・カクつくときの切り分け
トラブル時に最短で復旧するには、原因を一気に当てにいかず、症状別に切り分けることです。以下の表を使うと、修正の順番が固定でき、迷いが減ります。
| 症状 | よくある原因 | まず試す | 次に試す |
|---|---|---|---|
| エンコード遅延が増える | プリセットが重い／解像度・fps過大 | presetをveryfast側へ | 720p/30へ落とす |
| スキップフレームが増える | 描画負荷（ゲーム/フィルタ/ソース） | ゲーム設定を下げる | OBSのソース/フィルタ簡素化 |
| 視聴者側で止まる | 回線上り不足／ビットレート過大 | ビットレートを下げる | 解像度/fpsを下げる |
| 画質がブロック化 | ビット不足／動きが激しい | 720pへ落とす | fpsを30へ |
| 音ズレ | 取り込み負荷／遅延蓄積 | 負荷を下げる | 音声デバイス設定見直し |
ここでのコツは、「プリセットだけで解決しようとしない」ことです。根本的に必要ビット量が多い（1080p60の高速ゲーム等）場合、プリセットを遅くしても追いつかず、むしろ悪化します。解像度・fpsを落とす方が、視聴体験は改善しやすいです。
OBS録画でのx264おすすめ設定
録画はCBR固定にしない方が良いケース
録画で「容量が大きすぎる」「画質が安定しない」と悩む人は多いのですが、原因の一つがCBR固定です。CBRは固定ビットレートなので、簡単な場面でも一定量を使い続けます。結果として、必要以上にサイズが増えやすくなります。
録画は配信より自由度が高いので、品質基準で可変にする方が効率が良いケースが多いです。つまり、CRF（またはそれに相当する品質ベース）を使うと、「簡単な場面は軽く」「難しい場面は必要なだけ使う」が自動で起こり、見た目の満足度が上がりやすくなります。
ただし、録画でも注意点があります。録画中にゲームをするなら、CPUがx264に持っていかれすぎるとゲーム側が不安定になることがあります。その場合は、CRF方式にしてもプリセットをveryfast寄りにしたり、解像度やfpsを調整したりして、負荷のバランスを取る必要があります。
CRF目安と画質優先の考え方
録画でのおすすめは、「まずCRF 20〜23で短尺テスト」です。ここから始めれば、ほとんどの用途で大外ししません。
まずはCRF 23：標準のバランス帯
画質が不満なら 23→22→21
容量が気になるなら 23→24→25（破綻が出たら戻す）
プリセットは、ゲームをしながら録画するなら veryfast〜fast、録画専用で余裕があるなら fast〜medium がスタート地点になります。録画は配信より安全ですが、結局のところ「録画中の体感」が悪くなれば意味がないので、負荷と品質の両立を狙うのがポイントです。
ここでも“確認すべき場面”は同じです。文字、暗部、激しい動き。この3つで破綻しないCRF値が、その環境の正解です。
編集耐性を上げる設定の考え方
録画した素材を後で編集する場合、圧縮しすぎると編集のたびに劣化が目立ちやすくなります。特にテロップを入れたり、色補正をしたり、拡大したりすると、元の圧縮ノイズが強調されて見えることがあります。
編集耐性を上げるための考え方は次の通りです。
CRFを少し下げる（例：23→21）
プリセットを少し遅くする（耐えられる範囲でfast→medium）
文字や細線が多いなら、解像度をむやみに上げず、読みやすさを優先する
長期的に何度も使う素材なら、保存容量よりも品質を優先し、後で最終出力で圧縮する
「録画は最終成果物ではなく素材」という意識があると、ここでの品質投資が後工程のストレスを減らします。
FFmpeg libx264で再現性ある設定テンプレ
まずはCRF＋presetで決める定番コマンド
FFmpegでlibx264を使う最大のメリットは、設定がテキストで再現できることです。「この動画はこの条件で作った」というレシピが残り、同じ結果を何度でも作れます。まず最初は、定番のCRF＋presetで決めるのが最短です。
例として、次の形を基本形として覚えておくと便利です。
ここから調整するポイントはシンプルです。
画質を上げたい →
-crfを下げる（23→21）サイズを下げたい →
-crfを上げる（23→25）処理を速くしたい →
-presetを速く（medium→fast）同画質で少しでもサイズを削りたい →
-presetを遅く（medium→slow）
“まずはこの型”を持つだけで、迷いが大きく減ります。
ビットレート上限があるときのVBV付きコマンド
投稿先や再生環境に上限がある場合、CRFだけだとピークが跳ねる可能性があります。そこでVBVを足します。イメージは「普段はCRFで品質を守りつつ、ピークだけ上限に収める」です。
このときの考え方は次の通りです。
maxrateは「絶対に超えたくない上限」bufsizeは「どれくらいの揺れを許容するか」上限が厳しいほど、画質は落ちやすい → 必要なら解像度・fpsを下げる
VBVを入れても破綻が見える場合は、CRFやプリセットを弄る前に、まず出力の解像度やfpsを見直す方が効きます。必要ビット量が減ると、同じ上限でも見た目が改善しやすいからです。
2passで容量を狙い撃ちするコマンド
容量を厳密に合わせたいなら2passです。たとえば「10分で100MB以内」のような制約があるときは、2passが安定します。例は以下です。
Windowsの場合、/dev/nullの代わりにNULを使います。
2passのコツは「目標ビットレートを決める」ことです。計算は次の流れで考えます。
目標容量（例：100MB）をビットに換算
音声分（例：192kbps）を差し引く
残りを映像に割り当てる
その結果を
-b:vに設定する
慣れると、容量制限のある場面で非常に強い武器になります。
よくある失敗例（音ズレ・互換性・画質崩れ）
FFmpegでありがちな失敗は、原因が複数にまたがりやすいことです。代表例と対処の方向性をまとめます。
音ズレ
可変フレームレート素材や、編集済み素材でタイムスタンプが不安定な場合に起こりやすいです。まずは入力素材の性質を疑い、問題が起きる箇所を短尺で検証します。必要なら、一定fpsに揃えてから再エンコードするなど段階的に対処します。互換性の問題
特殊なオプションを詰めすぎると、再生環境によっては不具合が出ます。困ったときは、CRF＋presetの基本形に戻して再現性を確保し、そこから段階的に足すのが安全です。画質崩れ（ブロックノイズ）
CRFが高すぎる、またはVBV上限が厳しすぎてビット不足になっているケースが多いです。解像度/fpsを下げる、CRFを下げる、上限を緩める、の順で改善を試します。特に動きの激しい動画は“必要ビット量”が大きいので、条件を現実に合わせることが重要です。
AviUtl x264guiExの設定ポイント
触る場所を最小化する方針
AviUtlのx264guiExは項目が多く、「全部理解しないと怖い」と感じやすいのが難点です。ですが実際に成果へ効くのは一部で、最初から細部まで触ると迷いが増えます。
方針としては、次の“3点だけ”に絞ると失敗が減ります。
品質の決め方（CRF相当か、ビットレート指定か）
プリセット（速度と圧縮効率）
上限がある場合の合わせ方（必要なら）
細かいチューニング（tuneやpsy設定等）に手を出すのは、短尺で比較できるようになってからで十分です。まずは「投稿できる」「保存できる」状態を安定させる方が、結果的に近道です。
投稿向け・保存向けの考え方
AviUtlの書き出しは、目的で設計が変わります。大きく分けて次の2つです。
投稿向け
投稿先の推奨や上限があるなら、それに合わせます。上限が厳しいなら2pass（またはビットレート設計）を選び、上限が緩いならCRF中心で画質を守る、という考え方が使えます。
投稿向けで大事なのは、最終視聴環境（スマホ・PC）を意識し、無理に高解像度にしないことです。高解像度にしてもビットが足りないと破綻が目立ち、結果として見栄えが悪くなることがあります。保存向け（アーカイブ）
後で見返す、再編集する、長期保存するなら、CRFをやや低め（高画質側）にしておく方が満足度が高いです。特に実写や暗部が多い素材は、圧縮ノイズが気になりやすいので、ここでケチると後悔しがちです。
迷ったときは「投稿向け＝制約優先」「保存向け＝品質優先」と覚えると判断がぶれません。
ありがちなミスと確認ポイント
AviUtl周りは設定以前に、導線のミスで詰まることがあります。以下のチェックをすると、初歩的な落とし穴を避けられます。
拡張出力で x264guiEx を選べている
出力先のコンテナ（mp4等）が意図通り
音声設定が極端になっていない（無音・低ビット・別形式で問題が出ていない）
出力前に短尺テストを行い、文字・暗部・激しい動きを確認した
破綻が出た場合、CRFや上限だけでなく、解像度/fpsも見直した
「テストをしないで長尺を回す」のが最も時間を失う行為です。1分で良いので、必ずテストしてから本番を書き出すのが鉄則です。
よくある質問
CRFはどれくらいが無難か
迷ったら 23 を起点にするのが無難です。そこから、素材と目的に合わせて上下させます。
画質が不満 → 23→22→21
容量が大きい → 23→24→25（ただし破綻チェック必須）
「無難」はあくまで起点で、正解は素材で変わります。UIや文字が多い動画、暗部が多い実写、激しい動きが多いゲームは、同じCRFでも破綻が出やすいので、短尺テストで判断するのが確実です。
プリセットを遅くすると何が良くなるか
プリセットを遅くすると、一般に圧縮が賢くなり、同じ画質ならサイズが減りやすく、同じサイズなら画質が上がりやすくなります。ただし“劇的”ではなく、“積み上げ型の改善”です。特に配信では、遅くした結果CPU負荷が上がって事故ると元も子もありません。
おすすめは「配信は安定が最優先」「書き出しは時間が許すなら遅くする価値がある」という使い分けです。録画はその中間で、ゲーム体感を犠牲にしない範囲で調整するのが現実的です。
CBRにすべきかVBRにすべきか
用途で決めるのが最短です。
配信：基本はCBR（安定して届けるため）
録画：CRF（品質基準）中心が扱いやすい
書き出し：CRFで品質を守る／容量制限があるなら2passで狙い撃ち
VBRという言葉は文脈で意味がぶれやすいのですが、「場面に応じてビットを変える」という思想そのものは、録画や書き出しで非常に有利です。一方で配信は、変動が大きいと回線や受け側で問題が出やすいので、安定志向で設計するのが基本です。
NVENCとx264はどちらが良いか
どちらが良いかは「何を優先するか」で変わります。
ゲームをしながら配信してCPUが苦しい → NVENCなどGPUエンコードが有利になりやすい
CPUに余裕があり、同条件で少しでも圧縮効率を取りたい → x264が選ばれる場面がある
とにかく安定させたい → 負荷が少ない方式（多くの環境でGPU）が有利になりやすい
結局は、配信が成立しなければ意味がありません。まずは安定を確保し、そのうえで「画質を上げたい」「容量を減らしたい」といった改善に進むのが失敗しない順番です。もしx264で負荷が高すぎるなら、プリセットをveryfast寄りにする、解像度/fpsを落とす、あるいはNVENCへ切り替える、といった現実的な選択肢を持っておくと安心です。