AviUtlが重い時の対処法｜症状別の切り分けと軽くする設定一覧

「AviUtlが重い」で検索して出てきた対処法をひとつずつ試したのに、体感はほとんど変わらなかった——という人はかなり多いはずです。理由ははっきりしていて、「重い」には5種類あり、それぞれ原因も効く対処も違うからです。プレビューがカクつく原因と、出力が終わらない原因と、頻繁に落ちる原因は、ほとんど重なりません。だから「軽くする設定10選」を上から順に全部やっても、自分の症状に効く1つに当たるまでは何も変わらないのです。

顔出しなしでゆっくり解説や雑学ショートを作っている人にとって、この問題は画質の話ではなく投稿を続けられるかどうかの話です。1本あたりの編集が90分から150分に伸びれば、週5本の投稿は週3本に落ちます。投稿頻度が落ちればチャンネルは伸びません。重さ対策は「快適に作業するための贅沢」ではなく、投稿を継続するための必須メンテナンスだと考えてください。

この記事では、まず症状を5つに切り分ける表を置き、そのうえで症状ごとの対処を番号付きの手順にしています。さらに、多くの解説記事が最後に回しがちな「素材を編集用の中間ファイルに変換してから読み込む」を、あえて独立した章として真ん中に置きました。実際の相談を見ていると、AviUtlが重いケースの相当数はPCのスペック不足ではなく、編集に向かない形式の素材をそのまま読み込んでいることが主因だからです。

なお本記事は2026年9月時点の情報です。AviUtlは2019年のバージョン1.10を最後に本体（1.x系）の更新が止まっており、後継の「AviUtl ExEdit2（通称AviUtl2）」が2025年7月7日にベータ公開、2026年7月7日公開のv2.0.54でベータが外れて正式版として提供されています。1.x系と2系では設定項目の名前や場所が違う箇所があるため、該当部分は都度分けて書きます。バージョンによって画面が異なることがあるので、手元の表示と照らし合わせながら読み進めてください。

この記事はAviUtl側の設定に絞ります。台本・音声・立ち絵を含めた1本の作り方はずんだもん動画の作り方と無料ツールの組み合わせ方にまとめました。

AviUtlが重い原因は「どの操作が重いか」で決まる

結論：設定をいじる前に「どの操作をしたときに重いか」を1つに特定してください。特定しないまま対処を積み上げると、効かない設定変更ばかりが増えて、後で何が原因だったのか分からなくなります。

AviUtlの「重い」は、大きく次の5症状に分かれます。まず自分がどれに当てはまるかを決めてから、該当する章に進んでください。

複数当てはまるときの優先順位

3つも4つも当てはまる場合は、⑤→③→②→①→④の順で潰してください。落ちる・起動しないといった「作業が始められない」問題を先に片付けないと、他の対処の効果測定ができません。逆に④（出力が遅い）は最後で構いません。出力は席を外している間に回せるので、1本あたりの拘束時間への影響が一番小さいからです。

副業として続ける観点だと、実は一番痛いのは②です。プレビューは我慢して飛ばせますが、タイムライン操作が0.5秒ずつ遅れるのは編集の全工程に均等に乗ってくるので、1本の作業時間をそのまま1.5倍にするからです。

まず5分でやる設定変更チェックリスト

結論：以下の7項目は原因の特定より先にやって構いません。副作用が小さく、外れても損をしない設定だけを選んであります。

• [ ] AviUtl本体を、Cドライブ直下など日本語やスペースを含まないパスに置いているか確認する（例：C:\aviutl\）
• [ ] 素材ファイルを内蔵SSD上のローカルフォルダに置く。外付けHDD・NAS・クラウド同期フォルダ（OneDrive等）から直接読み込まない
• [ ] Cドライブの空き容量を確認し、最低でも数十GBは空けておく
• [ ] 再生時の表示倍率を1/2に下げる（プレビューの見た目が小さくなるだけで、出力画質には影響しない）
• [ ] 編集中は「ぼかし」「グロー」「発光」など重いフィルタのチェックを外し、確認時だけ有効に戻す
• [ ] 拡張編集の自動バックアップを有効にし、間隔を短め（3〜5分）にする
• [ ] Chrome・配信ソフト・ゲームランチャーなど、編集中に使わない常駐アプリを閉じる

ここまでで軽くならない場合に、システムの設定へ進みます。

「システムの設定」の推奨値と、上げすぎたときの副作用

AviUtl 1.x系では ファイル → 環境設定 → システムの設定 から変更します。設定変更はAviUtlを再起動しないと反映されません。

ここで一番言いたいのは「キャッシュは大きいほど速い」ではないということです。AviUtlのキャッシュはあくまでメモリ上の作業領域なので、搭載メモリを超える設定にするとOSがディスクへの退避（スワップ）を始め、体感は逆に悪化します。8GB搭載機で「キャッシュ8GB」にするのは典型的な失敗パターンです。

AviUtl2（ExEdit2）では項目の場所が変わり、設定 → キャッシュサイズの設定 から画像キャッシュサイズとプレビュー再生のバッファリング時間を指定します。シーク時にもたつく報告では、このバッファリング時間を初期値の500から100程度まで下げると改善したという事例が共有されています。数値の意味合いが1.x系のキャッシュとは別物なので、1.x系の感覚で大きくしないでください。

症状①：プレビュー再生がカクカクする

結論：プレビューのカクつきは「出力結果の品質」とは無関係です。まずは表示を軽くする方向で対処し、それでも足りないときにフィルタと素材に手を入れます。

多くの人がここで「PCが弱いから」と結論を出してしまいますが、順番が逆です。プレビューはリアルタイムに全フィルタを計算し直しているので、計算量そのものを減らすのが正攻法です。

1. 再生時の表示倍率を下げる。 メニューの「表示」から拡大表示を1/2にします。表示ピクセル数が1/4になるので、ここだけで体感が変わることが珍しくありません。文字の位置決めなど細部を見るときだけ等倍に戻します。
2. 「画像処理を間引いて表示」を有効にする。 出力時以外は重いフィルタの処理を簡略化して描画してくれます。プレビューと最終出力の見え方が変わる点だけ注意してください（最終確認は必ずオフに戻すか、テスト出力で行う）。
3. 編集中だけ重いフィルタを無効化する。 各オブジェクトのフィルタ効果には有効・無効のチェックがあります。作り込みが終わったエフェクトは、位置合わせやカット編集の間はオフにしておきます。
4. 重いフィルタを軽い代替に置き換える。 AviUtlには「発光」に対する「発光(軽量)」のように、負荷の軽い派生フィルタが用意されているものがあります。仕上がりの差が許容範囲なら軽量版で作り、必要な場面だけ通常版に差し替えます。
5. 拡張編集RAMプレビューを導入する。 レンダリング結果をメモリにキャッシュして、指定範囲だけを滑らかに再生できるプラグインです。範囲を選んでキャッシュを作成し、確認が終わったらキャッシュを消去してメモリを解放します。メモリに余裕がある環境（目安8GB以上）でこそ効く対処で、メモリが逼迫している環境では逆効果になり得ます。
6. 同一フレーム上のオブジェクト数を減らす。 同じフレームに動画ファイルを何本も重ねていると急激に重くなります。背景・立ち絵・テロップを別プロジェクトで作って中間ファイル化し、1本の動画として読み込む構成に変えると劇的に軽くなることがあります。
7. 素材そのものを軽くする。 ここまでで改善しないなら原因は素材側です。次章の中間ファイル化に進んでください。

フィルタの負荷の目安と、代替の考え方

正確な負荷はバージョン・解像度・パラメータで変わるため、あくまで傾向として捉えてください。実測は自分のプロジェクトで、フィルタを1つずつオン・オフして確認するのが確実です。

ぼかし系とシャドー系は、かける対象のサイズに比例して重くなります。1080×1920のショートで画面全体にぼかしをかければ当然重くなりますが、テロップの縁だけに影を付けるなら影響は限定的です。「どのフィルタを使ったか」ではなく「どの面積に何回かけたか」で考えると、削りどころが見えてきます。

症状②③：タイムライン操作が引っかかる・起動やプロジェクト読み込みが遅い

結論：この2症状は「AviUtlが同時に抱えているファイルの数」と「プラグインの総量」が原因であることがほとんどです。設定の数値より、プロジェクトの構造を見直す方が効きます。

タイムライン操作が引っかかるときの手順

1. 拡張編集の環境設定を開く。 拡張編集のタイムライン上で右クリックし「環境設定」を選びます。
2. 「動画ファイルのハンドル数」を確認する。 これは同時に扱える動画ファイルの最大数です。この数を超える動画ファイルを同一フレームで読み込むと、極端に重くなります。使っている動画素材の本数に合わせて引き上げます。
3. ただし上げすぎない。 ハンドル数を大きくするとメモリエラーが起きやすくなると広く報告されています。根本的には「同時に読み込む動画ファイルを減らす」方が安全です。
4. 「画像データのキャッシュ数」を確認する。 画像素材（png連番、立ち絵など）を大量に使う場合はここを増やすと軽くなることがあります。ただし1枚あたりのメモリ消費は「最大画像サイズ」に依存するため、最大画像サイズを過大にしていると効果より副作用が勝ちます。
5. オブジェクトをグループ化・シーン化する。 完成したパートは別シーンにまとめ、メインのタイムラインからは1オブジェクトとして参照する構成にします。これは設定変更ではなくプロジェクト設計の話ですが、効果は設定変更より大きいことが多いです。

起動・読み込みが遅いときの手順

1. プラグインとスクリプトを棚卸しする。 起動時に全プラグイン・全スクリプトを読み込むため、入れっぱなしの未使用スクリプトは純粋に起動時間を伸ばします。使っていないものは別フォルダへ退避してください（削除ではなく退避にすると戻せます）。
2. L-SMASH Worksのインデックスを事前に作る。 L-SMASH Worksは動画を初めて読み込むときにインデックスファイル（拡張子 .lwi）を生成します。長尺・大容量の素材ほどこの生成に時間がかかるので、編集を始める前に素材をまとめて一度読み込んでおくと、本番の編集中に固まらなくなります。
3. 素材をローカルSSDに移す。 外付けHDD、NAS、OneDrive等の同期フォルダから直接読むと、読み込みのたびに待たされます。作業用フォルダは内蔵SSD上に作り、完成後にアーカイブへ移す運用にします。
4. InputPipePluginを検討する（1.x系）。 L-SMASH Works File Readerを別プロセスで動かすことで、AviUtl本体側のメモリ使用量を減らす入力プラグインです。InputPipePlugin.aui と InputPipeMain.exe を lwinput.aui と同じ場所に置き、ファイル → 環境設定 → 入力プラグイン優先度の設定 で「InputPipePlugin」を「L-SMASH Works File Reader」より上に配置します。32bitアプリであるAviUtl 1.x系のメモリ上限に効く対処なので、64bitのAviUtl2では前提が変わります。
5. プロジェクトファイルを分割する。 10分超のプロジェクトに全パートを詰め込むより、パート単位でaupを分けて、最後に中間ファイルを繋ぐ方が読み込みは速くなります。ショート量産なら、そもそも1本1プロジェクトにしておけばこの問題はほぼ起きません。

古いバージョンのプラグインが原因で不安定になる例も報告されているため、導入済みプラグインは配布元で最新版を確認しておくのが安全です。特にInputPipePluginやL-SMASH Worksは更新履歴を追いやすいので、年1回でも見直す価値があります。

症状④⑤：出力が終わらない・頻繁に落ちる／フリーズする

結論：出力が遅いのは設定、落ちるのはメモリかプラグイン競合。この2つは切り分けが違うので、同時に対処しないでください。

出力（エンコード）が終わらないときの手順

1. どこで止まっているか確認する。 進捗が0%のまま動かないのか、途中で急激に遅くなるのかで話が違います。0%のまま／出力ファイルが0秒になる場合は、そもそも出力設定や入力プラグイン側の問題である可能性が高いので、AviUtl 出力できない 0秒で症状を確認してください。
2. x264guiExなどの出力プリセットを速度寄りに変える。 プロファイルに用意されている高速寄りのプリセットに切り替えるだけで、所要時間が大きく変わります。ショート動画の投稿用途では、最高品質プリセットの必要はほぼありません。
3. スレッド数は「0（自動）」のままにする。 手動でスレッド数を固定すると、使用スレッドがその数に固定されて逆に大幅に遅くなることがあると報告されています。触っていた場合は0に戻してください。
4. ビットレートを見直す。 目標ビットレートを上げるほど画質は上がりますが、エンコード時間も増えます。1080×1920のショートなら、まず一般的な推奨レンジで出力して、目視で問題がなければ上げない判断でよいはずです。
5. 自動マルチパスの回数を減らす。 多パスは時間を素直に倍増させます。投稿頻度を優先するなら、回数を絞るか単パスで運用します。
6. 重いフィルタを含むパートだけ先に中間ファイル化する。 全編に重いエフェクトがかかっているのではなく、特定パートだけが重いなら、そのパートを先に書き出して差し替えると全体の出力時間が短縮できます。
7. 出力中は他の作業をしない。 CPUを取り合うと単純に遅くなります。出力は席を離れるタイミングに回すのが結局いちばん効率的です。

音声が絡む不調（出力後に音がずれる、途中から合わなくなる）はエンコード速度とは別問題です。原因の切り分けはAviUtl 音ズレ 直し方にまとめている観点で進めてください。

頻繁に落ちる・フリーズするときの手順

1. 先に自動バックアップを確保する。 拡張編集には自動バックアップ機能があり、既定では一定間隔（初期値は5分程度）でバックアップが作られます。拡張編集の環境設定で有効になっているかを確認し、間隔を短めにしておきます。復元は拡張編集の右クリックメニューから「バックアップファイルから新規作成」で行えます。落ちる原因を探す前に、落ちても失わない状態を作るのが先です。
2. 最大画像サイズを見直す。 過大な最大画像サイズは、メモリ確保の失敗を招いて落ちる原因になり得ます。編集解像度に対して極端に大きい設定になっていないか確認してください。
3. メモリ使用量を実測する。 タスクマネージャーでAviUtlのメモリ使用量を見ます。1.x系は32bitアプリなので、1プロセスが扱えるメモリには上限があります（LargeAddressAwareが有効でも最大4GB程度）。この壁は搭載メモリを増やしても超えられません。InputPipePluginで読み込み分を別プロセスに逃がすか、素材を軽くするしかありません。
4. プラグインを1つずつ切り分ける。 プラグインフォルダの中身を半分退避して起動し、症状が出るかを見る二分探索が確実です。特定のプラグインで固まるという報告は個別に存在するので、「入れた直後から不安定になった」ものから疑ってください。
5. 入力プラグインを変える。 入力プラグインの相性でエンコード中にエラーが出る例が報告されています。DirectShow経由で読んでいる素材があれば、L-SMASH Works経由に統一すると安定することがあります。
6. ウイルス対策ソフトの除外設定を試す。 常駐スキャンが編集フォルダや出力先を毎回スキャンしていると、書き込みのたびに待たされます。作業フォルダとAviUtlの実行ファイルを除外対象にできるか確認してください（会社支給PCなど、設定を変えられない環境では無理をしないこと）。
7. それでも直らないならクリーンな環境で再現テスト。 AviUtl一式を別フォルダにまるごとコピーし、プラグインを入れずに素材だけ読み込んで落ちるか試します。ここで落ちないなら原因はプラグイン側、落ちるなら素材側かPC側です。

重い素材を「編集用の中間ファイル」に差し替える

結論：AviUtlが重い相談で最も効くのに最も実行されていないのが、この中間ファイル化です。素材を編集向きの形式に一度変換してから読み込むだけで、設定を何も変えずに体感が変わることがあります。

なぜ効くのか。AviUtlは再生・シーク・出力のたびに、読み込んだ動画をデコードしています。HEVC（H.265）や可変フレームレート（VFR）の素材、スマホ撮影の高圧縮ファイル、4K素材などはデコード自体が重いので、フィルタを1つも足していなくても重くなります。つまり「フィルタを減らしても軽くならない」ケースの多くは、ここが原因です。

さらにVFR素材には別の問題もあります。AviUtlは基本的に固定フレームレート（CFR）として扱うため、元がVFRの素材は映像と音声がずれる要因になります。L-SMASH Works File Readerの設定には「VFR→CFR」を指定する項目があるので、そこで固定するか、事前にCFRへ変換しておくのが安全です。

中間ファイル化の手順

1. 重い素材を特定する。 プロジェクトから素材を1つずつ外して、どれを外したときに軽くなるかを見ます。だいたい犯人は1〜2ファイルです。
2. 変換ソフトを用意する。 無料ならFFmpegやHandBrakeなど、コマンドやGUIで再エンコードできるものを使います。すでに使い慣れた変換ソフトがあるならそれで構いません。
3. 編集用の解像度に落とす。 4K素材を1080pのショートで使うなら、読み込む前に1080p相当へリサイズします。最終出力より大きい解像度の素材を編集中に抱える意味はありません。
4. 編集に向いたコーデックへ変換する。 一般的には、可変長のGOPを持つ高圧縮コーデックより、フレーム単位で扱いやすい形式のほうがシークが速くなります。H.264でGOPを短くする、あるいは編集向けの中間コーデックに変換する、といった選択肢があります。どの形式が最速かは環境で変わるので、候補を2つ作って同じプロジェクトで実測するのが確実です。
5. フレームレートを固定（CFR）にする。 30fpsなら30fps、60fpsなら60fpsに固定します。VFRのまま読むと重さと音ズレの両方を引き込みます。
6. 音声を分離しておく。 動画と音声が一体のファイルより、音声を別のwavとして扱ったほうが、タイムライン上の取り回しが軽くなる場合があります。
7. 変換後の素材でプロジェクトを作り直す。 素材の差し替えではなく、最初から変換後ファイルで組むほうが取りこぼしがありません。

素材タイプ別の対処

この方法が効かない条件

正直に書いておくと、中間ファイル化が効かないケースもあります。素材が最初から軽い形式（1080p・H.264・CFR）なのに重い場合は、原因は素材ではなくフィルタの多重がけかプロジェクト構造です。また、変換にはディスク容量と変換時間のコストがかかります。1本30秒のショートで素材が数本しかないなら、変換の手間のほうが大きいこともあります。素材が3本以内・すべて1080p以下なら、この章は飛ばして構いません。

もう1点、変換は再エンコードなので画質はわずかに落ちます。とはいえショート動画の視聴環境はスマホの縦画面で、さらにプラットフォーム側で再圧縮がかかります。編集用素材の画質を最終出力より過剰に高く保つ必要はほぼありません。ここを割り切れるかどうかが、編集時間を短縮できるかの分かれ目です。

ショート動画（1080×1920）制作に最適化した設定

結論：ショート専用に設定を切り替えると、横動画と同じ設定のまま作るより軽くなります。特に「最大画像サイズ」は縦向けに直さないと、そもそも1080×1920を扱えないことがあります。

縦動画特有の落とし穴として、AviUtlの最大画像サイズは初期状態だと高さ側が1920に届かない設定になっていることがあります。この場合、ファイル → 環境設定 → システムの設定 で最大画像サイズを変更し（値は8の倍数）、AviUtlを再起動します。それでもサイズ指定に出てこない場合は、その下の「リサイズ設定の解像度リスト」に 1080x1920 を追加し、設定 → サイズの変更 → 指定のサイズ で幅1080・高さ1920を指定します。

ショート量産で本当に効く「テンプレート化」

軽量化の話から少しずれますが、量産している人にとって最大の時短は毎回プロジェクトを一から作らないことです。背景・テロップの位置・フォント・BGMの音量・書き出し設定まで含んだテンプレートaupを1つ作り、毎回それをコピーして中身だけ差し替える運用にします。

これは軽量化でもあります。テンプレートは一度動作確認済みなので、重いフィルタを毎回試行錯誤で足す工程がなくなるからです。実際、編集時間が伸びている原因は「AviUtlが遅い」ではなく「毎回同じ装飾を作り直している」ことだった、という例は珍しくありません。

出力設定を含めたショート特有の詰まりどころはAviUtlショート動画 サイズ 出力設定にまとめています。企画側の作り方——どんな雑学ネタをどう構成するか——は雑学動画 作り方を参照してください。編集が軽くなっても、企画とテンプレートが固まっていなければ投稿本数は増えません。

PCの買い替え前にやる順番と、AviUtlを続けるか乗り換えるかの判断基準

結論：買い替えは最後の手段です。順番を守れば、多くの環境は買い替えなしで実用域に戻ります。

買い替えの前にやる順番

1. 素材の中間ファイル化（費用0円・効果が最も大きいことが多い）
2. 設定の見直し（キャッシュ、最大画像サイズ、表示倍率）
3. 不要プラグイン・スクリプトの退避（起動と安定性に効く）
4. 常駐ソフトの整理とウイルス対策ソフトの除外設定
5. ストレージの空き確保（Cドライブが逼迫していると全体が遅くなる）
6. HDDで作業しているならSSDへ移行（部分的なパーツ交換で済むことが多い）
7. メモリ増設（1.x系は32bitのため、増設しても本体が使える量には上限がある点に注意）
8. CPUの買い替え（エンコード時間に直結するが、費用対効果の検証は最後でよい）

GPUについては期待しすぎないでください。AviUtl 1.x系の処理は基本的にCPU中心で、GPUを使うのは一部のプラグインやスクリプトに限られます。一方でAviUtl2（ExEdit2）はDirectX 11.3とAVX2対応環境を要件としており、描画まわりの前提が1.x系とは異なります。「GPUを積めばAviUtlが速くなる」という単純な話ではないので、GPU目当ての買い替えは、自分が使っているバージョンと機能を確認してから判断してください。

AviUtlを使い続けるか、他ツールに移るかの判断基準

乗り換えを煽るつもりはありません。AviUtlは無料で、ゆっくり解説・雑学ショートの制作資産（スクリプト、テンプレート、解説記事）が圧倒的に豊富です。すでに慣れているなら、慣れ自体が最大の資産です。そのうえで、条件で分けます。

AviUtl2への移行は「新しいから移る」ではなく、1.x系の32bitという構造的な制約に自分がぶつかっているかどうかで決めるのが合理的です。落ちないし遅くないなら、移行コスト（プラグイン再導入、テンプレート作り直し）を払う理由はありません。

制作フローごと見直す選択肢

編集の重さを削り切っても投稿本数が増えないなら、ボトルネックは編集ソフトではありません。その場合の選択肢として、AviUtlで作り込む部分と、別ツールで自動化する部分を分ける考え方があります。

どれか1つが正解ということはなく、「作り込む1本」と「数を出す1本」で道具を変えるのが現実的です。全部をAviUtlでやろうとして重さと戦い続けるより、工程を分けたほうが投稿は続きます。

よくある質問

AviUtlが重いのはPCのスペックが低いからですか？

スペックが原因のケースもありますが、まず疑うべきは素材の形式とプロジェクト構造です。1080p以下の素材で重いなら、買い替えより先に中間ファイル化と設定見直しを試してください。

具体的には、HEVCや可変フレームレートの素材、4K素材、巨大なpng連番が入っていないかを確認します。これらはフィルタを1つも足していなくてもデコード負荷だけで重くなります。高スペック機に買い替えても、同じ素材を読み込めば同じように重くなることは十分あります。

キャッシュサイズは大きくすればするほど軽くなりますか？

いいえ。搭載メモリを超える設定にするとスワップが発生して逆に遅くなります。目安は搭載メモリの1/4程度、上限でも「搭載メモリ−2GB」程度に留めてください。

古いバージョンの「キャッシュフレーム数」も同様で、8〜32程度が目安とされており、極端に大きくすると不安定になったり出力時にエラーが出ることがあります。「メモリが余っているから全部割り当てる」という発想は、AviUtlに関しては裏目に出やすい設定です。

最大画像サイズは大きくしておけば安心ですか？

安心ではありません。最大画像サイズは1フレームあたりに確保するバッファのサイズに影響するため、必要以上に大きくするとメモリを圧迫して逆に重く・落ちやすくなります。

推奨は「実際に編集する解像度より少し大きい値」です。1080×1920のショートしか作らないなら、幅1088・高さ1936程度で足ります。「とりあえず5000×5000」のような設定は、扱う素材が小さい環境ではデメリットのほうが大きくなります。値は8の倍数で指定し、変更後は必ずAviUtlを再起動してください。

プレビューがカクカクしても、出力した動画は問題ありませんか？

はい。プレビューはリアルタイムに全処理を計算しているだけなので、カクついても最終出力の品質やフレームレートには影響しません。プレビューの見た目と出力結果は別物です。

ただし「画像処理を間引いて表示」を有効にしている間は、プレビューの見え方が最終出力と変わります。エフェクトの仕上がりを確認するときはこの設定をオフに戻すか、短い範囲をテスト出力して確認してください。

拡張編集RAMプレビューを入れれば全部解決しますか？

しません。RAMプレビューが効くのは「プレビュー再生がカクつく」症状だけで、タイムライン操作の引っかかりや出力の遅さには効きません。またメモリを大きく消費するため、搭載メモリが少ない環境では逆効果になり得ます。

使い方も「常時ONで軽くなる」ものではなく、確認したい範囲を選んでキャッシュを作成し、確認が終わったらキャッシュを消去する運用です。メモリに余裕がある環境（目安8GB以上）で、仕上げ確認の工程に限定して使うのが現実的です。

出力が遅いとき、スレッド数を上げれば速くなりますか？

逆効果になることがあります。x264guiExではスレッド数を「0（自動）」にしておくのが基本で、手動で固定すると使用スレッドがその数に固定され、大幅に遅くなると報告されています。

出力時間を縮めたいなら、プリセットを速度寄りに変える、自動マルチパスの回数を減らす、目標ビットレートを過剰に上げない、といった方向のほうが確実です。ショート動画の投稿用途では最高品質プリセットが必要になる場面はほとんどありません。

AviUtl2（ExEdit2）に移行すれば重さは解決しますか？

64bit化されているためメモリ上限の制約は緩和されますが、素材が重いことに起因する重さは変わりません。移行は「1.x系の32bitの壁にぶつかっている場合」に検討する選択肢です。

AviUtl ExEdit2は2025年7月にベータ公開され、2026年7月7日公開のv2.0.54でベータが外れて正式版になっています。動作には64bit版のWindows 10以降、DirectX 11.3、AVX2対応環境が必要です。ただし使っているプラグインやスクリプトが2系に対応しているかは個別に確認が必要なので、資産が多い人ほど移行判断は慎重に行ってください。

立ち絵のpsdが重いのですが、どうすればいいですか？

psdはレイヤー構造を都度処理するため負荷が高くなります。まず「実際に使う表情だけに絞る」、次に「表情が変わらないパートは書き出したpng画像に置き換える」の2段構えが現実的です。

立ち絵を複数人ぶん同一フレームに並べている場合は、それだけで処理量が人数倍になります。会話パートを別プロジェクトで作って中間ファイル化し、メインのタイムラインでは1本の動画として扱う構成にすると、体感が変わることがあります。

ウイルス対策ソフトを止めれば軽くなりますか？

常駐スキャンが編集フォルダを毎回スキャンしている場合は、除外設定で改善することがあります。ただしソフト自体を止めるのは推奨しません。作業フォルダとAviUtlの実行ファイルを除外対象に指定する方法を先に検討してください。

なお、会社支給PCなど設定を変更できない環境では無理に触らないでください。その場合は素材の中間ファイル化やプロジェクト分割など、ソフト側で完結する対処に絞ったほうが安全です。

設定を変えたのに何も変わりません。どうすればいいですか？

まずAviUtlを再起動してください。システムの設定の多くは再起動しないと反映されません。そのうえで変わらないなら、症状の切り分けが間違っている可能性が高いです。

冒頭の表に戻り、「どの操作をしたときに重いか」を1つだけ選び直してください。プレビュー向けの対処をいくら積んでも、原因がタイムラインのオブジェクト数や出力設定にあるなら効きません。切り分けを間違えたまま設定を増やすと、後で原因を追えなくなるので、一度設定を初期値付近まで戻して1つずつ試すほうが結局早いです。

まとめ

AviUtlの「重い」は、①プレビューのカクつき、②タイムライン操作の引っかかり、③起動・読み込みの遅さ、④出力の遅さ、⑤フリーズ・強制終了の5種類に分かれ、それぞれ原因も対処も違います。まず自分の症状を1つに特定することが、遠回りに見えていちばん速い道です。

そのうえで押さえるべきは3点です。第一に、キャッシュも最大画像サイズも「大きくすれば軽くなる」ものではないこと。搭載メモリを超えた設定はスワップを招き、過大な最大画像サイズはメモリを圧迫します。第二に、設定より素材のほうが効くこと。HEVC・VFR・4K・巨大な連番といった編集に向かない形式のまま読み込んでいるなら、編集用の中間ファイルに変換するだけで体感が変わることがあります。第三に、買い替えは最後であること。中間ファイル化・設定見直し・プラグイン整理・SSD化まで済ませてから検討しても遅くありません。

顔出しなしの副業として動画を作っているなら、最終的な目的は「AviUtlを軽くすること」ではなく「1本あたりの制作時間を短くして投稿を続けること」です。重さ対策を一通り終えたら、次はテンプレート化と工程の分業に手を付けてください。編集の速さより、同じ手順を毎回繰り返せる状態にすることのほうが、投稿本数への効き目は大きくなります。

本記事は2026年9月時点の公開情報と一般的な運用知見に基づいています。バージョンやプラグインの仕様は更新されるため、設定項目名が見当たらない場合はお使いのバージョンの配布元情報を確認してください。ここに書いていない挙動については、公開情報では確認できないため断定を避けています。