Stable DiffusionとAudioCraftの、Google Colab版でなくオフライン実行環境を作る手順（2025/6時点）
なぜローカル環境で実行したいのか
まず、私はGoogle Colabがあまり好きでないです。
Jupyter Notebookも好きでない。
VSCodeで、Vimキーバインドで書いて実行したいから。
要件や仕様や設計をClaude Codeに語って、CLAUDE.mdを作ってもらったあと
初めて実装に入りたいから。
要素検討だろうと、ローカルの仮想環境に
作っては壊し、作っては壊し、するほうがリラックスできて
Google ColabやJupyter Notebookで要素検討ができたとしても
その成果をプロジェクトにマージする手間が無駄で
最初からプロジェクトの一部として、コミットしながらやったほうが保険が効く。
ニュータイプな未来にいるのはCLAUDE.md、って感触があって
企業が用意したオンラインの実行環境って
最適でないのに候補に上がってくる、オールドタイプなノイズに感じるのです。
初心者向けのPC雑誌は、1年で内容がループしてるのだけど
オンラインにある初心者向けの記事も、多くの山師がコピペで増殖させるので
（つまり、初心者が初心者向けの記事を書くので）
誤った記述、古い内容がいつまでもデブリになってる。
生成AI系の記事は、そーゆーのが多いジャンル。
でも、手段（環境構築）が目的化してるよりは
目的（萌え）に向かって一直線に、最短で進みたいって気持ちは好きだし
Stable Diffusionで検索した時に、Google Colabで実行する記事が中心なのは
それで良いと思う。
そういえば
私はGoogle Colaboratoryを略してGoogle Colabと書くのだと思ってたけど
公式は、もうGoogle Colabに統一されてた。
Colaboratory表記が残ってるのは、ヘルプページのURLくらい？
Jupyter NotebookはJupyterLabに変わったと思ってたけど
いまだにJupyter Notebookと紹介した記事が多い。
旧版として、いまでも使えるから？
この記事の発端は
ゲーミングPCを持ってて
Stable DiffusionとAudioCraftを使ってみたくなったこと。
Google Colabが楽！とオススメする記事を見て
試してみたら、ぜんぜん楽じゃなかった。
調べると
昔は楽だったけど、Google Colab内のPythonのバージョンをGoogleがどんどん上げるせいで
古いコードは序盤すら、ライブラリの不整合でエラー終了するようになり
フォークして別人が作り
それもエラーするようになり
のループで、これまで来たらしい。
Google Colabは、正常終了を保証する状態で凍結する
を目的とするサービスじゃないみたい。
Stable DiffusionやAudioCraftが流行り始めた頃の、記事で紹介されてた方法は
もう動作しないものばかりだった。
なので、ゲーミングPCに環境をインストールし
正常終了する状態で固定し、凍結させることに、興味が湧いたのです。
オフラインでいつでも使えたら便利だしー。
そこで知ったのは
などのリポジトリの更新日時が、2年前が最後とかばっかりな空気感。
1度作ったら劇的な変化なく、ゆるやかに維持する界隈っぽく見えるのは
同じ目的を達成できる自社の新しいAIへ、つっこむ資源を移行するからなのかな。
このへんの空気を勉強するのに の紳士のまとめた情報が、すごく役立った。
宗教や国家やケモナーから自由な、日本がこのジャンルに強い理由が理解った気がする。
人間賛歌って感じで、敬意を表するッ！
大事なのはStable Diffusionなどツールの機能より、各モデルの性能だし
ツールのUIだって、Extensionsで増やせるし
更新日時が古いのは、きっと土台としては完成してるからで
信用できないわけでなく、現役なんだろう。
ローカルPCに入れる手順も
2年くらい前に書かれた記事のままでは、エラーになるケースが多かった。
それは日本語で書かれた手順が、もう古いというだけであって
解決させる情報は、英語でならあった。
なので、私と同じことをしようとする（した）人たちは
みんな同じ罠にハマって、みんな同じように調べて解決する（した）だろうから
そのムダを省くために、情報を共有しておくのが、この場所です。
で書いたように、私はEndeavourOSを使ってるのだけど
Windows 11ではWSL2でArchLinuxも使ってて
それら両方に、Stable DiffusionとAudioCraftを入れてみた。
結局どっちもArch系Linuxなので、Linux内でのインストール手順は同一で
ツールより外側の、Firewallでのポート開放とかの手順が
WSL2では、Windows側にあるって程度の違いだけ。
GeForceを認識させて
nvidia-smi コマンドが使えるまでの手順も
ArchLinuxでは yay で1行実行するだけで、Ubuntuみたいな面倒がない
そんなところにハマる罠はないので、すっとばす。
Stable Diffusion
Forge版が、まだ更新日時が新しかったので、それを入れた。
の
>>> Click Here to Download One-Click Package (CUDA 12.1 + Pytorch 2.3.1) <<<
にあるワンクリック版は、.bat で実現されたものなので、Linux用じゃない。
git clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git
cd stable-diffusion-webui-forge
READMEには、この後が具体的に書かれてないけど
次にどのファイルを叩けばいいんだろう？
候補は
- launch.py
- webui-macos-env.sh
- webui-user.bat
- webui-user.sh
- webui.py
- webui.sh
直感的に、.bat と .sh の両方あるものが
最もユーザーに近い、直接実行してほしいファイルに見える。
でも、Pythonを実行する前に
importしてるライブラリたちを pip でインストールしとけ
とゆーのが、古のPythonの決まり
- requirements_versions.txt
が存在するので、昔だったら
pip install -r requirements_versions.txt
って打つ場面だろう。
でも
- pyproject.toml
も存在するので、2年前といっても
このプロジェクトは poetry コマンドでライブラリを入れる世代っぽい。
ほか
- package.json
もあるので
npm install
も必要なの？って思ったけど
中身はESLintの設定だけだったので、開発時には必要でも実行時には必要ない。
結論を書くと、今回のようなLinuxでは
./webui.sh
だけを実行すれば、あとはその中で呼んでくれる。
ただ、いきなり上記コマンドを呼ぶと、自動的に venv ディレクトリを作ろうとする。
venvは
- プロジェクトの実行に必要なライブラリは、プロジェクトごとに別々に管理しよう
- それをプロジェクトのディレクトリ内に置くルールにすれば、ユーザーもさすがに分かるっしょ
という、Nodeが2009年に npm で実現した仕組みを
2013年にPython流に再現したもので
それまで pip install するたびに、グローバルなPythonに
そのPC上でそれまで使ったすべてのライブラリが、ORをとった形で混じって貯まるという
スカムな仕組みを解決してくれた。
npmの場合は、その競合である yarn だろうと bun だろうと
ダウンロードしたライブラリを node_modules ディレクトリに入れる決まりは守ってるのだけど
Pythonの場合は、（後発なのに）なぜかそこが自由すぎて
.venv に入れる派と、venv に入れる派があるみたい。
そして、./webui.sh で自動的に作られるのは venv である。
自動的に作られたものが使われるのは気持ち悪いので
あらかじめ作っとけば認識されるだろJK……と考えて作ったのだけど
私は .venv 派だったので
.venv と venv が並ぶことになり、無駄だった。
ほかvenvには、すげー直感的でない挙動があって
生成された venv ディレクトリ内には
venv/bin/python という実行ファイルができてるから
なるほど、これがグローバルのPythonとは違う
このプロジェクトのためだけの実行ファイルかーって思うのだけど
これはシンボリックリンクにすぎず、グローバルなPythonをアンインストールすると
これも動かなくなる。
おいおいおいおいおい！
じゃあ、シンボリックリンクのない（ジャンクションという似た仕組みはあるが）Windowsにも
venvはあるのに、どうやって実現してるの？
って調べたら、Windowsだと python.exe は普通にコピーで増えてた。
あと、よく手順で
source venv/bin/activate
しろ！って書かれてることがあるのだけど、これも正しいのだけど、ややこしい。
直感的には
プロジェクトのルートディレクトリに .venv とか venv があったら
もう「そのプロジェクトのディレクトリ内では、そのプロジェクト専用のPython環境を使う」って
言ってるようなものじゃん！
勝手に切り替えてよ！
って感じなのだけど、勝手には切り替わってくれない。
私の使い方では、グローバルなPythonを使いたいユースケースが皆無なのだけど
ちゃんとアクティベートのコマンドを打ってね、がルール。
ただ、ここにも裏技？があって
いちいち source venv/bin/activate を打たない方法もある。
例えば、
python ./hoge.py と打ったら、グローバルなPythonが使われるのだけど
./venv/bin/python ./hoge.py と打ったら、アクティベート無しで venv のPythonが使われる。
そのPython内でimportに使われるライブラリも
venv に入れたライブラリたちに、自動的に切り替わる。
なので、シェルスクリプトとかで、venv なPythonを実行したいときは
activate なしで、いきなりフルパスで venv なPythonを指定すればイイだけ。
venvは以上のような仕組みなので
グローバルなPythonが入ってない環境では使えず
まずは python にパスの通った状態を作っとく必要がある。
その作り方は、直接 apt や yay で入れようと
pyenv や uvで入れようと構わないのだけど、オススメは後者。
なぜなら、最新のPythonは3.13系なのに
Stable DiffusionとAudioCraftが求めるのは、3.10系だから。
pyenv や uv など、複数バージョンを同居させて切り替える仕組みでないと
3.13系を使いたくなったときに面倒すぎる。
venv 内に作られるPythonのシンボリックリンクが
どのバージョンのPythonを指してるかが確定するのは、当然 venv を作った瞬間。
つまり
python -m venv venv
コマンドを打った時の python のバージョンで固定される。
なので、直前に python --vesion して、3.10系なことを確認しとくと良い。
結局まとめると、打つべきコマンドは
git clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git
cd stable-diffusion-webui-forge
python -m venv venv
source venv/bin/activate
./webui.sh --listen
最後の --listen は必須でない。
付けないと、127.0.0.1:7860 でホストされ
その実行したPCのブラウザでしか見られない。
--listen を付けると、0.0.0.0:7860 でホストされ
ほかのPCのブラウザからもアクセスできる。
ゲーミングPCの近くで操作すると、うるさいし暑いので
私は --listen を付けて、ほかのノートPCのブラウザから使ってる。
つまり、GPU付きのPCに ssh して起動させるよーなケースでは
--listen を付けないと、起動させても意味ないってこと。
起動直後に
Legacy Preprocessor init warning: Unable to install insightface automatically. Please try run `pip install insightface` manually.
というエラーが端末にでてるんだけど、気にしてない。
動作に問題あるようには見えないし。
何回か起動し直してるうちに、
sqlite3.OperationalError: database is locked
というエラーが起きて、起動できなくなることがある。
この解決方法は に情報があった。
export SD_WEBUI_CACHE_DIR="/tmp/cache"
という環境変数を定義すれば解決した。
ただ、ちょっとハマった。
……というのは、環境変数を追加した後、それを認識させようとして
source ~/.zshrc した。
すると、venvの中にいる状態が解除されるって知らなかった。
再び source venv/bin/activate せずに ./webui.sh --listen すると
グローバルなPythonを使おうとするので、ライブラリが入ってるはずないから起動しない。
ほか、ハマった点としては
Extensionsのインストールでエラーになったこと。
Stable Diffusionには、Image BrowserとかControlNetなど
必須級の拡張機能があって
追加方法は、それらリポジトリのURLを
Extensionsタブ内にペーストするだけなのだけど
AssertionError: extension access disabled because of command line flags
というエラーが出る。
解決方法は、分かってしまえば簡単で
./webui.sh --listen でなく
./webui.sh --listen --enable-insecure-extension-access
で起動すれば良かっただけ。
--listen 付きは、URLを知ってる誰からも使えるようになっちゃうので
拡張機能のインストールすら自由にさせるかは、別のフラグだったのね
Stable Diffusionは以上で、次はAudioCraft。
AudioCraft
Meta社が作ったBGM、SEの自動生成AIとして
MusicGenなどの、〇〇Genシリーズがあるそうで
それらを統合的に操作できるGUIとして、AudioCraftが作られたっぽい。
にInstallationの見出しがあるので、その内容をコピペすればインストールできる。
ただ、求められるPythonのバージョンが3.10系なので
venvを使わないと不便。
3.10系ってStable Diffusionと同じなので、運がイイ。
Stable Diffusionのためにグローバルに入れたPython 3.10が
AudioCraftでも、そのままvenvの元として使える。
3.9系だという情報も転がってたけど、3.10系でちゃんと動く。
打つべきコマンドをまとめると
git clone https://github.com/facebookresearch/audiocraft
cd audiocraft
python -m venv venv
source venv/bin/activate
python -m pip install 'torch==2.1.0'
python -m pip install setuptools wheel
python -m pip install -U audiocraft
python -m pip install -U git+https://git@github.com/facebookresearch/audiocraft#egg=audiocraft
python -m pip install -e .
python -m pip install -e '.[wm]'
リポジトリのルートには
- requirements.txt
- setup.py
などもあるのだけど、自分で直接それらを指定して使うことはない。
起動は
python -m demos.musicgen_app --share
audiocraft や demos ディレクトリに、事前に cd しとく必要はなく
リポジトリのルートで実行すればOK。
--share なしだと http://127.0.0.1:7860 でホストされ
そのPCのブラウザからしかアクセスできない。
--share 付きだと
のようなURLが作られ、ほかのPCのブラウザからもアクセスできる。
このへんは、Stable Diffusionでの --listen オプションと似てる。
ただ、2025/6月時点でのPython 3.10系と
降ってくるライブラリの最新バージョンと
Metaがリリース後に、追加でいじったコードとの相性のためか
そのままではエラー終了になる。
まず
AttributeError: module 'gradio' has no attribute 'make_waveform'
というエラーが起きる。
この解決方法は に情報があり、
pip install gradio==4.44.1 -e .
で解決。
それを突破すると、次に
TypeError: argument of type 'bool' is not iterable
というエラーが起きる。
この解決方法は に情報があり、
pip install pydantic==2.10.6 -e .
で解決。
これでエラーはなくなり、ブラウザでMusicGenのGUIを開けるはず。
ただし、最初はなにもモデルが入ってない状態から始まる。
画面下のほうにある
facebook/musicgen-small
などのラジオボタンで1つ選んで、Submitボタンを押すと
それが、そのモデルの初使用だった場合
曲の生成前にモデルのダウンロードが始まる。
ダウンロードされたモデルの配置場所は、Stable Diffusionのように
models ディレクトリに置かれるみたいな、理解りやすいルールになっておらず
./.cache/huggingface/hub/models--facebook--musicgen-stereo-small/blobs/4b2a5fd7544ce68f1f3576871697ee459b7a237488e352da2db073c84bd3be65
のような場所に置かれる。
facebook/musicgen-stereo-melody などの、でっかいモデルの場合
ダウンロード中の状態も見れて
./.cache/huggingface/hub/models--facebook--musicgen-stereo-melody/blobs/84ae723b002062949c69a6ae3165468c077ddf5d57fa3a183333a91d14572cb4.incomplete
のようなファイル名になっていた。
このダウンロード元は、どうせHugging Faceなんだろうと予想したのだけど
通信ログを見ると
https://cas-server.xethub.hf.co/reconstruction/5b43565ec3485f3bc1204dc3bd77b5fd4083d1bb4896eac54dec1aaf698c1dd9\
のようなURLになっていた。
XetHubはHugging Faceに買収されたので、そのサーバーを使ってるのだろう。
これは、プロキシ経由での接続が必要な研究者とかにとっては
メンドイかもしれない。
Python関連で、ドメインに接続できない系のエラーが出た場合は
たいてい
~/.config/pip/pip.conf を作って、そこに
[global]
trusted-host = pypi.org files.pythonhosted.org pypi.python.org download.pytorch.org huggingface.co
のように書いておけば、SSL認証を回避できるのだけど
実験してみたら cas-server.xethub.hf.co は回避できなかったので
pip じゃない方法でダウンロードしようとしてるのかもしれない。
英語圏にも解決方法は見つからなかった。
まとめ
最初の使用時にモデルのダウンロードが始まるので、完全にオフライン化できたとはいえないけど
モデルや拡張機能を、あらかたダウンロードし終わっとけば
将来、GitHubがなくなろうと
Hugging Faceが閉鎖されようと、Googleが倒産しようと
このゲーミングPCでだけは、画像やBGMを生成できる環境が整ったと思う。
Dr.STONE的に考えて、こーゆー自己完結は大事だと思った。
最後に注意点として、ファイアウォールの話がある。
Stable DiffusionとAudioCraftには、UIとしてGradioを採用してる
という共通点があり、デフォルトで7860ポートを使おうとする。
でも、Stable Diffusionを先に起動してれば
後から起動したAudioCraftは7680を使えず、自動的に7681ポートでホストされる。
WSL2に入れたLinuxは、そのディストリビューションの素に近い初期状態なので
デフォルトでファイアウォールが有効になってない。
WSL2を使う時は、たいていWindows側のユーザーホームに .wslconfig を作って
[wsl2]
networkingMode=mirrored
と書くことで、Windows側のIPアドレスで、WSL2内にもアクセスできるようにしてると思う。
そして、Windows 11のデフォルト設定ではファイアウォールが有効になってて
WSL2内のOSは、この影響を受ける。
ポートを指定して受信側の穴を開けないと、WSL2内で動作している
Stable DiffusionやAudioCraftの、内蔵Webサーバーに対する通信はブロックされる。
穴の空け方は、アプリ名で指定したり、ポート番号で指定したり
好きにやればイイけど、大事なのは7860だけじゃダメってこと。
7861以降を忘れないように、範囲で指定しとくとイイ。
WSL2でなく、PCに直接Linuxを入れた場合は
ファイアウォールはデフォルトで無効（一向に構わんッッ状態）なことが多いけど
KDEなどデスクトップ環境付きで入れた場合は、デフォルトで有効になってる場合がある。
Stable DiffusionやAudioCraftが起動してて
エラーも出てないのに、ほかのPCのブラウザからアクセスできない場合は
まず、--listen や --share が抜けてないか確認して
それらが大丈夫だったら、たいていファイアウォールが原因です。
実際にStable Diffusionを使ってみた感想。
2年前からある仕組みでも、ぜんぜんスゴイ。
これで綺麗な絵が出るよ、って紹介されてるプロンプト、ネガティブプロンプトを
ペーストしたら、よく見る生成AI絵がちゃんと出た。
プロンプトにペーストする言葉自体を、Copilotに提案させるコンボも強力。
いっぽう、AudioCraftはちょっと微妙……。
メガドラっぽい音源で、インストゥルメンタルを生成させたら
ちゃんとそれっぽいのが出た。
既存曲を読ませてアレンジさせる方法は
プロンプトでしっとり感を指示してるのに、余計な音が多すぎた。
その後
に同じプロンプトを実行したら
起伏のある、直感的に「良い」と感じる曲がどんどん生成された。
いまはStable Diffusionとudioの組み合わせが、私にとっての最適解っぽい。
Discussion