技術 約9分で読めます

ACE-Step UIはローカル音楽生成を制作アプリっぽくする

AI 音楽生成 ローカルAI React TypeScript
いけさん目次

fspecii/ace-step-ui が気になったので調べた。
名前だけ見ると ACE-Step 1.5 の別フロントエンドだが、実際は「生成して終わり」のUIではなく、ライブラリ管理、プレイヤー、AudioMass編集、DemucsによるStem分離、動画生成までまとめた制作アプリ寄りの実装だった。

ACE-Step本体は以前に V1.0の下調べ と V1.5の刷新 を見ている。
今回の主役はモデル性能そのものではなく、そのモデルを普段使いするための外側だ。

ACE-Step本体ではなく制作環境のほう

ACE-Step UI は、ACE-Step 1.5 の Gradio API をAIエンジンとして呼び出す。
フロントエンドは React 18 + TypeScript + Tailwind CSS + Vite、バックエンドは Express.js + SQLite + better-sqlite3。
生成履歴やプレイリストをローカルDBに保存し、ブラウザ側には Spotify っぽいライブラリと下部プレイヤーを置く構成になっている。

graph LR
    A[ブラウザUI] --> B[Express API]
    B --> C[SQLite]
    B --> D[ACE-Step 1.5<br/>Gradio API]
    B --> E[FFmpeg<br/>Demucs<br/>AudioMass]
    D --> F[生成音源]
    E --> F

公式READMEでは、ACE-Step UI側の要件として Node.js 18以上、Python 3.10以上またはWindows Portable Package、FFmpeg、uvを挙げている。
GPUは4GB以上でも動作対象だが、LLM機能込みなら12GB以上を推奨している。
ここは ACE-Step 1.5 本体の低VRAM対応と同じで、「最低限生成できる」と「Thinking Modeまで快適に使う」は別物だ。

Gradioで足りない部分を埋めている

ACE-Step 1.5 本体にも Gradio UI はある。
ただし、標準UIはモデル実行とパラメータ操作に寄っている。
ACE-Step UI が足しているのは、生成後の曲をどう溜めて、聴いて、切って、使い回すかの部分だ。

領域ACE-Step UIで足されるもの
生成Simple/Custom Mode、BPM、キー、拍子、長さ、Batch生成
プロンプト歌詞エディタ、構造タグ、プロンプトテンプレート、過去設定の再利用
整理履歴、検索、Likes、プレイリスト、ローカルSQLite保存
再生下部プレイヤー、波形、進捗表示
加工AudioMass編集、Demucs Stem分離、FFmpeg処理
付帯物Pexels背景の動画生成、手元生成のグラデーションジャケット

ローカル音楽生成で地味に面倒なのは、生成そのものより生成物の散らかり方だ。
数十秒で何本も出せるモデルほど、ファイル名、設定、歌詞、バージョン違いがすぐ分からなくなる。
ACE-Step UI はそこを「音楽制作アプリの最低限」に寄せている。

Thinking Modeは低VRAM機能ではない

ACE-Step 1.5 は、LM（言語モデル）が楽曲の設計を作り、DiT（Diffusion Transformer）が音を作る構成になった。
ACE-Step UI の AI Enhance や Thinking Mode は、このLM側を使ってジャンルタグ、BPM、キー、拍子、歌詞構造などを補強する機能だ。

UI側のREADMEでは、4GB GPUではThinking Modeを切り、PTバックエンド、Batch size 1、短めの長さに寄せるトラブルシュートが書かれている。
ACE-Step 1.5本体の GPU Compatibility Guide でも、6GB以下ではLM初期化を無効化し、DiT中心で動かす方針になっている。

この差は大きい。
「4GBで動く」は、ローカルで音を出せるという意味では魅力がある。
ただし、プロンプト理解や構成作りまで丸ごと任せたいなら、12GB以上のGPUか、CPUでのLM処理待ちを受け入れる必要がある。

ACE-Step 1.5 XLとの相性

ACE-Step 1.5側では、2026年4月2日に 4B DiT の XL 系列が追加された。
xl-base、xl-sft、xl-turbo の3種類で、公式READMEでは12GB以上（オフロードあり）または20GB以上（オフロードなし）を目安にしている。

ACE-Step UI自体は「きれいなUI」だけではなく、ACE-Step 1.5 のAPIを前提にした薄い制作レイヤーなので、モデル側の世代更新を受けやすい。
本体のGradio APIを --enable-api 付きで起動し、UI側の ACESTEP_API_URL を http://localhost:8001 に向ける作りになっている。

cd /path/to/ACE-Step-1.5
uv run acestep --port 8001 --enable-api --backend pt --server-name 127.0.0.1

cd /path/to/ace-step-ui
./start.sh

Windows Portable Packageの場合は C:\ACE-Step-1.5 を想定した start-all.bat が用意されている。
Linux/macOSでは ../ACE-Step-1.5 を探す start-all.sh があり、場所が違う場合は ACESTEP_PATH を指定する。

ローカルSuno代替と言い切る前の引っかかり

READMEはかなり強く「Open Source Suno Alternative」と押し出している。
ただ、現時点で見るなら、比較対象はSunoそのものより「ACE-Step 1.5を制作アプリとして扱えるか」だと思う。

GitHub上では2026年4月27日時点でACE-Step UIは約1.1k stars、リリースは未作成。
コミットは56件で、勢いはあるが安定版パッケージとしての区切りはまだ見えない。
一方で、ACE-Step 1.5本体は同日時点で約9.7k stars、12件のリリースがあり、最新リリースは2026年4月24日の v0.1.7 だった。

商用クラウドサービスの代替として見るなら、音質、歌詞追従、著作権リスク、生成物の権利、プロジェクト継続性まで見る必要がある。
制作補助ツールとして見るなら、ローカル保存、履歴、編集、Stem分離が同じ画面にある時点でかなり試す価値がある。

試す順番

いきなりACE-Step UIから入るより、先にACE-Step 1.5本体が自分のGPUで安定するか確認したほうがいい。
本体のGradio UIかAPIで1曲出せる状態を作ってから、UIを上に載せるほうが切り分けしやすい。

最低限の確認点はこのあたり。

確認点見る理由
ACE-Step 1.5単体で生成できるかUI以前にモデル・GPU・PyTorch環境が詰まりやすい
--enable-api 付きで起動できるかACE-Step UIはGradio APIに接続する
FFmpegが入っているか曲の長さ表示や音声処理で必要になる
GPU VRAMに合ったLM設定かThinking ModeやAI Enhanceの成否に直結する
生成履歴の保存場所SQLiteと音源ファイルが増えるのでバックアップ方針に関わる

音楽生成は画像生成より「あとで探す」「聴き比べる」「少し切る」が多い。
ACE-Step UIが気になる理由もそこにある。
モデルのベンチマークではなく、ローカル生成物を制作物として扱うための棚が増えている。

MacではMLXとMPSの二本立てになる

ACE-Step 1.5はMacで動く。
ただし内部構成がLinux/Windowsとは違っていて、LM（言語モデル）側はAppleのMLXフレームワーク、DiT側はPyTorchのMPSバックエンドという二本立てになる。
Linux/WindowsではLMもDiTもPyTorch + CUDAで統一されるが、MacではMLXとMPSが混在する形だ。

ACE-Step 1.5のmacOS用スクリプト start_gradio_ui_macos.sh や start_api_server_macos.sh は、起動時に ACESTEP_LM_BACKEND=mlx と --backend mlx を自動で設定する。
nano-vllm（高速LM推論エンジン）はmacOS arm64では除外されていて、代わりにmlx-lmがLM推論を担当する。

ここで引っかかるのが ACE-Step UI の start-all.sh だ。
このスクリプトは uv run acestep-api --port 8001 でACE-Step本体を起動するが、--backend mlx を渡していない。
つまり start-all.sh で一括起動すると、LMバックエンドがPyTorchにフォールバックする可能性がある。
Macで使うなら、ACE-Step本体は start_api_server_macos.sh で別に起動して、ACE-Step UI側は start.sh だけ走らせるほうが安全だ。
あるいは ACE-Step 側の .env に ACESTEP_LM_BACKEND=mlx を書いておく手もある。

Apple Siliconのメモリとモデルサイズ

Apple Siliconはユニファイドメモリなので、GPU専用VRAMという概念がない。
ACE-Step 1.5の推奨VRAM表はそのまま「使えるメモリ量」に読み替える。

16GBのMacだと、2B turbo DiTのみ（LMなし）で量子化とオフロード併用が現実的なライン。
32GBなら2B turbo/sft + 0.6Bまたは1.7B LMは載る。
XL系列（4B DiT）は32GBだとギリギリで、Autoscore時にLMの重複ロードが起きてクラッシュするissue（#1081）が報告されている。
64GB以上ならXLも回せるが、このAutoscoreのメモリリークは未修正のままだ。

macOSでほぼ必須の環境変数が2つある。

export PYTORCH_MPS_HIGH_WATERMARK_RATIO=0.0
export PYTORCH_ENABLE_MPS_FALLBACK=1

HIGH_WATERMARK_RATIO=0.0 はMPSのメモリ上限を外す設定で、これがないとOOMエラーで落ちやすい。
ただしシステムレベルのメモリ保護もなくなるので、メモリが足りない状態で走らせるとmacOS自体が不安定になる。
MPS_FALLBACK=1 はMPS未対応の演算をCPUに逃がすフラグで、これも設定しないとランタイムエラーが出る場面がある。

Stem分離はブラウザ側で完結する

MacでDemucsが動くかという問題は、ACE-Step UIに限っては気にしなくていい。
ACE-Step UIのStem分離はPython版Demucsではなく、ONNX Runtime Webによるブラウザ内実行になっている。
htdemucs_embedded.onnxモデルをWebGPUまたはWASMで動かす実装なので、OS側のGPUバックエンドには依存しない。
Safari 18以降ならWebGPUが使えるし、対応していなければWASMにフォールバックする。

ACE-Step 1.5本体のGradio UIにもトラック分離機能はあるが、こちらはPython版DemucsがPyTorch MPS経由で動く。
MPS上のDemucsは一部演算がCPUフォールバックになるので速度は出にくい。

LoRAとトレーニングはMacだと厳しい

ACE-Step UIから将来的にLoRAを使いたい場合、Macは現状かなり制約がある。

LoRA適用はMLX DiTでは機能しない（issue #559）。
UIはLoRA設定を受け付けるが、出力はLoRAなしと同一になる。
LoRAを効かせるにはMLX DiTを無効にしてPyTorch MPSで動かす必要があり、速度が落ちる上にMPSのメモリリークが出やすくなる。

LoRAのトレーニング自体も、M3 Pro 36GBで即OOM（issue #282）という報告がある。
トレーニングが約45GBを要求するためMPSの上限を超えるという話で、HIGH_WATERMARK_RATIO=0.0 でも安定しない。
LoRAを本格的にやるならCUDA環境が要る。

生成速度はCUDAの数倍遅い

公式ベンチマークではA100が1曲2秒未満、RTX 3090が10秒未満とされている。
Macの公式ベンチマークは出ていないが、CUDAの3〜10倍遅いという体感報告がある。
torch.compile() がMPSでは使えないこと、INT8量子化のMPS最適化が限定的なこと、nano-vllmが除外されていることが重なる。

ただ、ACE-Step UIの用途は「1曲出して終わり」ではなく、生成物をライブラリに溜めて整理するワークフローだ。
生成が数十秒かかっても、その間に前の曲を聴いたり歌詞を直したりする使い方なら、CUDA並のスループットがなくても回る。
Batch生成で寝てる間に回す場合は話が別だが、対話的に使うぶんにはMacでも成立しそうな線はある。