※本記事はアフィリエイト広告を含みます。
クラウドベースのAI画像生成サービスは確かに便利です。
しかし、月額のサブスクリプション費用、突然の仕様変更、そして運営側の意向による生成制限（フィルター）など、常に他者のプラットフォームに依存し続けるリスクを孕んでいます。
真にコントロール可能で、制限のない生成インフラを求めるなら、論理的な最適解は「完全オフラインで稼働するローカル環境の構築」に行き着きます。
本記事では、ミドルクラスのGPUを搭載したWindows環境において、「Stable Diffusion WebUI Forge」を導入し、外部通信に一切依存しない無料の画像生成環境を構築する手順を解説します。
ただし、これは単なる「ワンクリック導入ガイド」ではありません。
構築の裏でシステムが引き起こす「PythonのPATH未設定」「pkg_resourcesの消失」「NumPyとOpenCVの致命的なバージョン不整合」といった、初心者が必ず挫折するブラックボックスに対し、コマンドラインから手動でどう論理的にデバッグし、システムを正常化させたのか。そのリアルなトラブルシューティングの全記録を公開いたします。
なぜ今、ローカル完結のAI画像生成環境を作るのか
わざわざ手間をかけてまで、自分のPCに環境を構築する価値はあるのか？
クラウドサービスと比較した際の、圧倒的なメリットとデメリットを以下の表にまとめました。
| 項目 | ローカル環境（今回の構築） | クラウドサービス（Midjourney, DALL-E等） |
| コスト | 完全無料（電気代のみ） | 月額サブスクリプション制（制限あり） |
| 生成制限（検閲） | 一切なし（完全な自由） | 運営の規約・フィルターによる制限あり |
| インフラ依存 | オフライン稼働可（サービス終了リスクゼロ） | ネットワーク必須。運営の仕様変更に依存 |
| プライバシー | PC内で完結（機密情報の入力も安全） | プロンプトや画像が学習データにされるリスク |
| 導入ハードル | 極めて高い（エラー解決のITリテラシー必須） | 極めて低い（ブラウザで完結） |
| 要求スペック | 高い（VRAM 8GB以上のGPUが必須） | 低い（スマホでも可能） |
この表の通り、導入のハードル（エラー解決の手間）さえ乗り越えてしまえば、あとは「完全に自分の好みで自由に画像生成できる環境」が手に入ります。本記事はそのハードルを論理的に排除するための記録です。
検証環境と要求スペック：RTX 2070 SUPER（VRAM 8GB）での限界値
今回の構築にあたり、ベースとしたPCスペックは以下の通りです。
- OS：Windows 11
- CPU：Core i7-9700 3.00GHz
- メモリ：32GB
- GPU：RTX 2070 SUPER（VRAM 8GB）
- ストレージ：1TB
ローカルAI環境において、RTX 2070 SUPERの「VRAM 8GB」は快適に動作する基準値となります。
このスペックであれば、Stable Diffusion 1.5系モデルを使用した高画質生成が十分に可能です。
ただし、LLM（大規模言語モデル）との同時起動はVRAM枯渇によるシステムフリーズ（最悪のシナリオ）を招くため、タスクを切り替えて運用するメモリ管理が必須となります。
必須となる事前準備
環境構築を始める前に、以下の3つの要素をローカル環境へ揃える必要があります。
- Python 3.10.6 のインストール
- Git のインストール
- 画像生成モデル（CheckpointとVAE）のダウンロード
Python 3.10.6 のインストール、Stable Diffusion系の動作において、Python 3.10.6は最もバグが少なく、予期せぬ不具合を起こしにくいバージョンです。公式ページからWindows installer（64-bit）をダウンロードして実行します。
この際、最初の画面下部にある「Add Python 3.10 to PATH」というチェックボックスに必ずチェックを入れてください。これを忘れるとシステムがPythonを認識できず、後の全工程が破綻します。
Git のインストール、GitHubから必要なシステムファイルをクローン（複製）するために必須のツールです。公式サイトからWindows版をダウンロードし、標準設定のまま（次へ次へと）インストールを完了させます。
画像生成モデル（CheckpointとVAE）のダウンロード、システムが「どう絵を描くか」を決定する脳となるデータです。
DreamShaper※準備中
CivitaiやHugging Face等のサイトから、メインモデルとなるCheckpoint（.safetensors形式、容量2GB〜4GB程度）と、色味の崩れ（白飛び等）を防ぐ補正データであるVAE（vae-ft-mse-840000-ema-pruned.safetensors等）を、オンライン環境のうちにダウンロードしておきます。
ローカル環境のベース構築
事前準備が完了したら、以下の手順でForgeのベースシステムを構築します。
- リポジトリのクローン
- 初回起動バッチ（webui-user.bat）の実行
リポジトリのクローン、コマンドプロンプトを起動し、インストールしたい任意のディレクトリ（例：C:\AI など）に移動した後、git clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git を実行してシステム一式をダウンロードします。
初回起動バッチの実行、クローンしたフォルダ内にある webui-user.bat をダブルクリックして実行します。正常であれば、数GBに及ぶ必須ライブラリが自動でダウンロードされ、ローカルサーバーが立ち上がります。 しかし、現実のインフラ構築において、ここでストレートに完了することは稀です。次項で、実際に発生した依存関係エラーとその解決策を解説します。
【実録】依存関係エラー地獄のデバッグログ
webui-user.bat の実行中に発生した4つの致命的なエラーと、その論理的な突破方法を時系列で記載します。
- エラー1：exit code 9009（Python未認識）
- エラー2：No module named ‘pkg_resources’（CLIPのインストール失敗）
- エラー3：numpy.dtype size changed（NumPyのバージョン不整合）
- エラー4：pip’s dependency resolver conflict（OpenCVの依存関係エラー）
exit code 9009の原因は、WindowsがPythonコマンドを認識できていないことです。Pythonインストール時に「Add Python 3.10 to PATH」のチェックを忘れた、あるいは環境変数の反映前にコマンドプロンプトを開きっぱなしにしていた場合に発生します。Pythonを正しく再インストールし、コマンドプロンプトを必ず再起動することで解決します。
No module named ‘pkg_resources’は システムの仮想環境（venv）が自動で最新のセットアップツールをダウンロードした結果、古い仕様で作られた clip というパッケージと互換性が合わずに無限ループに陥るバグです。これを解決するには、自動処理（隔離ビルド）を強制的に禁止し、手動で基礎ツールとパッケージをねじ込む必要があります。コマンドプロンプトで venv\Scripts\activate を実行して仮想環境に入り、以下のコマンドを順に実行して強制インストールしました。
pip install wheelpip install https://github.com/openai/CLIP/archive/d50d76daa670286dd6cacf3bcd80b5e4823fc8e1.zip --no-build-isolation
次にnumpy.dtype size changed。長時間のダウンロード後、起動の最終盤で発生します。Forgeの一部が古いNumPy 1.x系を前提としているにも関わらず、システムが勝手に最新のNumPy 2.x系をインストールしたことによるバイナリ互換性の崩壊ですね。これも手動で介入し、pip install numpy==1.26.4 を実行して安定版へ強制ダウングレードさせることで解決しますし、そのやり方で解決しました。
そして最後、pip’s dependency resolver conflict、NumPyをダウングレードした直後に発生する連鎖エラーです。裏でインストールされていたOpenCVパッケージが「NumPy 2.0以上じゃないと動かない」と警告を出します。 妥協せず、OpenCV側も足並みを揃えさせるため、pip install opencv-python-headless==4.9.0.80 opencv-contrib-python==4.9.0.80 を実行し、完全な論理的整合性を取り戻しました。
モデルファイルの正確な配置（ヒューマンエラーの罠）
全てのエラーを排除し、Running on local URL: http://127.0.0.1:7860 が表示されたら、ブラウザからUIへアクセスします。しかし、ここで事前にダウンロードしたモデルファイルを正しい場所に配置しなければ画像は生成できません。
- Checkpointの配置先
- VAEの配置先
- 「modules」と「models」の罠
CheckpointとVAEの配置先であるCheckpointファイルは、 stable-diffusion-webui-forge\models\Stable-diffusion のフォルダ内に、VAEファイルは stable-diffusion-webui-forge\models\VAE のフォルダ内に配置します。
「modules」と「models」の罠も見落としやすい… ここで誰もが陥りやすいヒューマンエラーがあります。フォルダ階層の中に「modules」と「models」という非常に似た名前のフォルダが存在することです。誤って「modules」側にファイルを配置しても、システムは永遠にそれを認識しません。「神は細部に宿る」。1文字の違いがシステムの沈黙を招くため、絶対パスを正確に確認して配置し、UI上の青い更新ボタン（リフレッシュ）を押して反映させます。
クオリティを劇的に上げる「Hires. Fix（高解像度補助）」設定
初期設定のままでは、出力される画像の仕上がりはイマイチです。Stable Diffusion 1.5系モデルは、最初から大きいサイズで生成すると構図が崩壊する仕様上の弱点を持っています。 これを回避し、圧倒的な高画質を引き出すための論理的な解が「Hires. Fix（高解像度補助）」です。一旦低解像度で構図を確定させ、AIの力で高解像度化して書き込みを増やすという処理を行います。
必須パラメータの設定値
必須パラメータの設定値 UIの「Hires. fix」にチェックを入れ、以下の数値を厳密に設定します。
- Upscaler：
R-ESRGAN 4x+（万能で高性能） - Hires steps：
15～20 - Denoising strength：
0.55（元の絵から離れすぎず、かつ精細さを増す黄金比） - Upscale by：
2.0（解像度を2倍に拡大） - Sampling method：
DPM++ 2M Karras等（Euler aよりも書き込み密度が高い） - 基礎解像度（Width / Height）：
512 x 768または768 x 512
これらの設定を適用し、プロンプトに細かな情景描写（例：サイバーパンク、光の表現など）を入力して「Generate」を実行することで、完全にコントロールされた高品質な画像が、オフラインのローカルPCから生み出されます。
一昔前の生成AI画像って感じですな笑
指が変だったり、おかしなシチュエーションだったり・・・PCでのスペックが低いのか、プロンプトが悪いのか、設定なのか・・・まぁでも今後が楽しみであり、PCではのスペック（というかグラボですね）を上げればさらに良いものが出来るんでしょうね。(^_^;)
でもこれがオフラインで試し放題というが凄い所です。
まとめ：環境依存ゼロの生成インフラを手に入れる価値
無数のエラーとバグの連鎖を一つひとつ論理的に叩き潰すプロセスは、決して容易なものではありません。
しかし、それを乗り越えて構築した環境は、突然の仕様変更や不条理な制限に振り回されることのない、完全に独立した「インフラ」となります。
一度必要なデータをローカルに落とし込み、バッチファイルを適切に設定（--api など）すれば、LANケーブルを抜いた状態でもシステムは稼働し続けます。
外部に依存しない圧倒的な技術的優位性を手に入れるために、本記事のデバッグ録が役立てば幸いです。