Stable Diffusionで画像が真っ黒・グレー・NansExceptionになる時の症状別対処法

※Stable Diffisionのさまざまなエラーを解決する記事もありますので、ぜひこちらも合わせてチェックしてみてください！

Stable Diffusionで画像生成がうまくいかない？エラーになる理由と対処法を解説

Stable Diffusionを使っているときにエラーが出てしまい、困ることは多々あります。今回はそんな時のために、Stable Diffusionでよく起きるエラーの原因と対処法について徹底解説します！

romptn.com

2023.09.02

監修者_SD

監修者プロフィール

沖@AI画像生成

Xで5万人のフォロワーをかかえる、画像生成クリエイター。Stable Diffusionを中心に、様々な画像生成AIや動画生成AIを駆使し、コンテンツを制作。画像生成に関連する講演会なども多数こなす。AI画像制作の仕事も募集中。

真っ黒・NaNが起きた時の対処法

Stable Diffusionで画像が真っ黒になったりNansExceptionで止まった時、まず必要なのは「いま自分が見ている症状」を30秒で見極めることです。フラグを片っ端から追加する前に、症状を1つに絞ると当てる処方箋がぐっと近づきます。

症状を完全に真っ黒な画像が返る / グレー・ノイズだけが出る / NansException で止まる / 生成ボタンに反応しないの4つに分けて扱います。次の章の症状フローチャートで自分の症状を当てはめ、そのまま該当する切り分け節に進み、必要なフラグやVAE差し替えを上から順に試せる構成にしています！

もし真っ黒画像と一緒にコンソールへ NansException: A tensor with all NaNs was produced in Unet のような英語の文章が出ているなら、後ほどの「NansExceptionが出て止まる」と「4つのフラグの意味と推奨順序」の章がおすすめです。読み進めながら自分の環境(使っている UI と GPU)も思い出しておくと、UI別とGPU世代別の章で迷わずに済みますよ！

症状別に原因を切り分けるフローチャート

症状から原因系統を絞り込む手順を、フローチャートの形で先に示します。各分岐は2〜3ステップで閉じるので、コンソールに残っているエラーメッセージを1つ眺めながら追ってください！

大枠の対応関係はおおむね次の通りです。

• 完全に真っ黒な画像 → VAE不一致 / fp16 NaN / SDXL系のVAE不適合のいずれか
• グレーやノイズだけが出る → VAE未ロード / VAEファイルの破損 / fp16半精度の数値不安定
• NansException で止まる → fp16半精度の数値オーバーフロー(GPU適合の問題を含む)
• 生成ボタンを押しても無反応 → 依存関係・CUDAの初期化・モデル未ロードなど別系統の障害

ここから先の節では、上の4つの入口に対応する切り分け手順を1つずつ紹介していきます。

SDXL / Pony / Illustrious 系のモデルを使っているかどうかと使っている UI(AUTOMATIC1111 / Forge 系 / ComfyUI) はこの後の章で何度も分かれるので、自分の環境を先にメモしておくと節を行き来する回数が減りますよ。

①完全に真っ黒な画像が返る

生成完了後に画像が完全に真っ黒になる場合、疑う順序は「VAEの不一致 → fp16半精度のNaN → SDXL系VAEの不適合」です。エラーが出ずに黒だけが返るのが特徴で、コンソールには警告も残らないことがあります。

切り分けの早道は、いま使っているチェックポイントが SD1.5 系か SDXL 系(Pony / Illustrious / NoobAI などを含む)か を確認することです。

• SD1.5 系で真っ黒 → フラグ側の問題が中心。後ほどの「4つのフラグの意味と推奨順序」で --upcast-sampling から段階的に試す
• SDXL 系で真っ黒 → VAE側の不適合が中心。「SDXLの黒画像はVAE差し替えで根治する」の章で sdxl-vae-fp16-fix への差し替えを先に試す

古い記事でよく見る「とりあえず --no-half-vae を付ければ直る」は SD1.5 系には効きますが、SDXL 系では速度・VRAM を犠牲にする割に効果が薄く、VAE差し替えの方が筋の良い解になります！

②グレーやノイズだけが出る

画像はノイズ混じりのグレーや砂嵐で返ってくる場合、VAEが読み込まれていない・破損している・あるいは半精度演算で値が荒れていることが多いです。完全に真っ黒なケースよりも軽い症状で、VAE周りの設定を見直すだけで解決することも珍しくありません。

切り分けは次の順序が効率的です。

1. UI 上の VAE 選択欄が Automatic / None になっていないか を確認する(チェックポイント同梱の VAE が読まれていない場合がある)
2. 使っている .vae.pt / .safetensors ファイルを別のVAEに差し替えて再生成し、グレーが消えるか試す
3. それでも消えなければ、後ほどの「4つのフラグの意味と推奨順序」で --upcast-sampling → --no-half-vae → --no-half の順に試す

--no-half まで進めると速度とVRAMを大きく食うので、いきなり最後のフラグに飛ばず、上から順に効くかどうかを1つずつ確認するのが安全です！

③NansExceptionが出て止まる

生成が止まり、コンソールに NansException: A tensor with all NaNs was produced in Unet や ...in the vae といったメッセージが出る場合は、半精度(fp16)演算の途中で数値が無限大や非数(NaN)に飛んだことを意味します。GTX 16XX系や一部の古い GPU、SDXL系チェックポイントとの組み合わせで起きやすい症状です。

対処は段階的に上から試すのが原則です。

1. --upcast-sampling を最初に試す(速度低下が小さく副作用も少ない、公式Wikiの推奨第一手)
2. 効かなければ --no-half-vae を追加する(VAEだけfp32に上げる)
3. それでもNaNが出るなら --precision full --no-half まで上げる(全体 fp32、VRAMを最も食う)

ここで絶対に避けたいのが --disable-nan-check をいきなり付けることです。これは「NaNを検出してもエラーで止めない」だけの検証用フラグで、根治はせずに真っ黒画像が量産される側に進んでしまいます。詳しい理由は後ほどの「–disable-nan-checkを安易に使わない理由」で扱います！

④ボタンを押しても無反応

生成ボタンを押してもプログレスバーが動かない・コンソールに何も出ない場合、原因は黒画像や NaN とは別系統です。依存パッケージのロード失敗、CUDAの初期化エラー、モデルファイル未ロードなど、画像生成の手前で詰まっていることが多くなります。

切り分けの観点は次の3つです。

• 起動時のコンソールログに CUDA out of memory 以外のエラーが出ていないか
• モデル選択欄に該当チェックポイントが表示されているか(ファイル名だけ並んでロードに失敗していないか)
• UIを再起動した直後だけでも症状が再現するか

この系統は対処順序が黒画像と異なるため、本記事ではスコープ外として扱います。詳細な切り分けは横断早見表の方が対応しやすいので、そちらを参照してください！

4つのフラグの意味と推奨順序

黒い画像とNaN対策で出てくる主要フラグは4つあります。ここではその意味と推奨順序を整理し、片っ端から追加して副作用に困らないようにします！

まずAUTOMATIC1111公式Wikiの定義に基づく整理は次の通りです。

推奨順序は --upcast-sampling → --no-half-vae → --no-half です。--upcast-sampling は公式Wikiでも「--no-half と似た結果をより省 VRAM・高速に得られる」と説明されており、第一手として外せません。--disable-nan-check は次の節で扱うように根治ではないため、トラブルシュートの定石フラグからは外して考えてください！

–disable-nan-checkを安易に使わない方が良い理由

ここで --disable-nan-check フラグだけを取り上げます。ネット上には「これを付けたら生成が通った」という記事が一定数あり、検索でぶつかった読者が真っ先に追加してしまいがちなフラグだからです…！

AUTOMATIC1111公式Wikiではこのフラグを「生成した画像やlatentにNaNが含まれているかのチェックを行わない。チェックポイントを読み込まずにCIで実行する用途に便利」と説明しています。つまり --disable-nan-check は「NaNを検出してもエラーで止めない」だけで、NaNが出る原因(半精度演算のオーバーフロー)自体を直すフラグではありません。

付けるとどうなるかは単純で、NaNを含んだlatentがそのままVAEデコードまで通り、結果として画面いっぱいの真っ黒画像が黙って量産される動きになります。「エラーは消えたけど黒画像が出続ける」状態は、ほぼこのフラグの副作用です。

根治には前節の --upcast-sampling → --no-half-vae → --no-half の順で試すか、SDXL 系なら次の章のVAE差し替えで対応します。検証目的でない限り、このフラグは外しておく方が安全です！

SDXLの黒い画像はVAE差し替えで根治する

SDXL系のチェックポイントで真っ黒画像にぶつかったら、フラグ追加よりも先に VAEそのものをfp16で安定動作するものに差し替えるのが現代の解になります。SD1.5時代の「--no-half-vae を付ければ直る」は、SDXLでは速度とVRAMを犠牲にする割に効果が薄いためです。

デファクトになっているのがHugging Faceで公開されている madebyollin/sdxl-vae-fp16-fix です。SDXLのVAEを内部のactivationがオーバーフローしにくくなるよう再ファインチューニングしたモデルで、2026年5月時点で月278,820ダウンロードと、SDXLの黒画像対策として最も広く採用されています！

導入手順は次の流れです。

1. 上記リポジトリから sdxl_vae.safetensors または sdxl.vae.safetensors をダウンロードする
2. AUTOMATIC1111 / Forge 系なら stable-diffusion-webui/models/VAE/ に、ComfyUIなら ComfyUI/models/vae/ に配置する
3. UIを再起動し、VAE選択欄でこのファイルを選んで再生成する(AUTOMATIC1111系は Settings → Stable Diffusion → SD VAE)

差し替え後は --no-half-vae を付けたままにする必要はなく、外した方がVAEのメモリ使用量も小さくなります。SDXL系で「フラグを足しても黒い」場合の本命の打ち手なので、SDXLモデルを使っているなら最初に試して構いません！

利用UI別に設定経路を読み替える方法

同じ症状でも、使っているUIが違えば「どこにフラグを書くか / どこでVAEを選ぶか」が異なります。古い記事の手順をそのまま追っても項目が見つからずに詰まる原因はここにあるので、自分のUIに応じて読み替えできる形で並べておきます！

2026年5月時点での主要UIの状態は次の通りです。

• AUTOMATIC1111(本家)：最終commitが 2025年2月9日で、約1年3ヶ月メンテが止まっている状態。設定経路は安定している反面、新しいモデル対応は手が入りにくい
• Forge 系(lllyasviel/forge と派生)：本家停滞をきっかけに reForge / forge-classic / forge-neo など派生が並んで存在する。A1111と似たUIを保つものが多い
• ComfyUI：2026年5月13日にもcommitがあり、現在メンテ中。ノードベースで設定経路はA1111とは別物

次の章で3つのUIごとに、フラグの書き場所とVAE選択の場所を順に見ていきます。自分が使っていないUIの節は読み飛ばして構いません！

①AUTOMATIC1111での手順

AUTOMATIC1111ではフラグの書き場所は起動スクリプトの COMMANDLINE_ARGS 行です。Windowsなら webui-user.bat、macOS /Linux なら webui-user.sh をテキストエディタで開いて編集します。

例えば --upcast-sampling と --xformers を有効化する場合、行はこうなります。

set COMMANDLINE_ARGS=--upcast-sampling --xformers

VAEの選択はUI側です。Settings → Stable Diffusion → SD VAE のドロップダウンから使いたい .safetensors ファイルを選び、Apply settings を押してから生成を試してください。前章で扱った sdxl_vae.safetensors もここから選択します！

なおAUTOMATIC1111の本家リポジトリは 2025年2月9日を最後にcommitが止まっており、新しいSDXL派生モデルへの追加対応は手が入りにくい状態が続いています。最新派生モデルを追う比重が高い場合は、次のForge系かComfyUIへの乗り換えも検討材料になります。

②Forge系での手順

Forge系は本家 lllyasviel/forge と、そこから派生した reForge / forge-classic / forge-neo などをまとめた呼び方です。forkごとにUIの細部が違うため、本記事では「A1111と同等の項目を、似た場所で探す」という方針で扱います。

探し方の指針は次の2つです。

• フラグ追記：A1111と同じく webui-user.bat / webui-user.sh の COMMANDLINE_ARGS 行に書ける派生が多い。なければリポジトリのREADMEで「command line arguments」と検索する
• VAE 選択：Settings配下に SD VAE 相当のドロップダウンを持つ派生が多い。見当たらない場合はVAEでUI内検索する

特定forkに固有のUIラベル(『Patches』タブの中の何々、など)は派生によって変わりやすいので、本記事ではあえて踏み込みません。「A1111ならどこを触るか」を先に思い出してから、Forge系UIで同じ目的の項目を探す読み替えが、結果として最短ルートになります。

VAE差し替え自体はA1111と同じ models/VAE/フォルダ配下にファイルを置く形が共通で、ComfyUIの models/vae/とはパスが微妙に異なる点だけ注意してください！

③ComfyUIでの手順

ComfyUI はノードベースのUIなので、A1111系とは設定の発想が違います。フラグで挙動を切り替えるのではなく、ワークフロー上に明示的に「Load VAE」ノードを置いて差し替えるのが基本です。

黒画像対策で SDXL用VAEを差し替える流れは次の通りです。

1. sdxl_vae.safetensors を ComfyUI/models/vae/ に配置する
2. ワークフローに Load VAE ノードを追加し、ドロップダウンから配置したVAEを選ぶ
3. チェックポイント側のVAE出力ではなく、Load VAE 側のVAEを後段の VAE Decode に繋ぎ直す

fp16半精度の不安定さでNaNが出る場合は、起動オプションとして --force-fp32 などのコマンドラインを使う方法もありますが、まずはワークフロー側でVAEを差し替えてみる方が副作用が少なくて済みます。

ComfyUIの本体リポジトリは 2026年5月13日にもcommitが入っており、本記事執筆時点で最もメンテが続いているUIです。新しいSDXL派生モデルや最近のVAEへの対応はこちらが早く揃う傾向にあります！

GPU世代別の推奨フラグ一覧

GPUの世代によっても、最初に試すべきフラグの組み合わせは変わります。公式Wikiのトラブルシューティングに沿って、4つの代表ケースを表で整理します。

Apple SiliconはMPSバックエンド固有の問題が絡むため、本記事では深追いせず、横断早見表側のMPS関連節を参照してください。NVIDIA / AMD系は上の表の自分の行から第一手を試し、効かなければ右に進むのが最短ルートです！

よくある質問

本文では拾いきれなかった、読者から特に多い質問への短い回答をまとめました！

まとめ

Stable Diffusionで画像が真っ黒・グレー・NansExceptionになった時の対処を、症状起点で1本の流れに整理してきました。

最後にもう一度、行動レベルでまとめておきます！

一手目を当てたい時はまず本記事の症状フローチャートに戻り、該当する節の段階処方を上から試してください。

横断早見表が必要な場合は冒頭で紹介した記事も合わせて活用してくださいね！