0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Umamon

M1 Macで完全無料ローカルAI作曲 — ACE-Step 1.5で100秒の歌もの2曲が58秒で出るまでの実録

0
Posted at

※この記事は Zenn に投稿した記事の転載です（正本: https://zenn.dev/umamon/articles/c78d08f31659cc ）。最新版・コメントは正本の Zenn 側をご覧ください。

課金ゼロ・外部送信ゼロ。M1 Max一台で、100秒の歌もの2曲（seed違い2バリアント）が約58秒で出ます（この構成のM1 Max 64GBでの実測です。詳細は後述）。

読者として想定しているのは、ローカルでLLM/画像/動画を回しているApple Silicon勢と、クラウド課金を避けたいDTMer。「Sunoは便利だけど課金とクラウド送信が嫌だ。Macだけで歌もの生成は本当に動くのか、実速度は？」に実測で答えます。

「ローカル無料AI◯◯実録」シリーズの2本目です。前回は動画でした → M1 Macで"完全無料・ローカル"のAIショート動画パイプラインを作った全記録。今回は音楽。子ども向け英語学習ソング教材を8曲作った実録として、詰まった話（失敗談）から書きます。

TL;DR（先に結論）

  • 「ローカルで動いた」の確認は、ヘルスチェックOKではなく接続先URLとapi_modeの実査で。 リポジトリ同梱CLIの既定はクラウド（acemusic.ai）を向いていて、ローカルサーバが正常でも健診はOKを返し続けます（最大の罠。後述）。
  • M1 Max 64GBの実測: 100秒の歌もの2バリアント＝58.48秒（LM 15.70s＋DiT 42.78s）。全8曲×2バリアントの総生成は約9分。
  • 品質は耳だけで判定しない: mlx-whisper文字起こし一致率 × 独立ルーブリック × 耳、の3層採点。最終採用8本は平均一致率83.9%・独立採点平均94.1点。
  • 環境構築の地雷は前回（動画編）と同じarm64 Python。今回はuvxがanaconda由来のx86 Pythonを掴みました。

1. 事件：「ローカルのつもりがクラウド」— 健診OKでも信じるな

課金ゼロ・外部送信ゼロでAI作曲——のつもりが、生成リクエストはクラウドに飛んでいました。今回の実録で一番価値がある失敗談なので、最初に書きます。

タイムライン

  1. 導入日。git clone＋uv sync、APIサーバをlocalhost:8001で起動。ここまでは順調でした。
  2. リポジトリに.claude/skillsとしてCLI（acestep.sh）が同梱されており、これで生成を始めようとしたところ——
  3. このCLIの既定接続先はクラウドAPI（acemusic.ai）でした。 手元でAPIサーバが正常に立っていても、生成リクエストは外部へ飛ぶ設定のままです。

なぜ気づけないか：クラウド健診がOKを返す

質（たち）が悪いのはここです。CLIのヘルスチェックはクラウド側の健診として"OK"を返します。ローカルサーバの起動にも成功している。つまり「サーバ起動OK・ヘルスチェックOK・生成も通る」と、どこから見ても"動いた"ように見えて、実体は外部送信です。完全ローカル（外部送信ゼロ）を要件にしている人ほど、この見かけのOKに騙されます。

図2: クラウド健診OKの罠（Before/After）

修正は2行

接続先とAPIモードを明示的にローカルへ向けます。

bash scripts/acestep.sh config --set api_url "http://127.0.0.1:8001"
bash scripts/acestep.sh config --set api_mode native

教訓: 完全ローカル（外部送信ゼロ・商用可）を要件にするなら、「ヘルスチェックOK」ではなく接続先URLとapi_modeを実査する。健診が通ることと、リクエストがローカルに閉じていることは別問題。

以降の実測はすべて、この修正後（api_mode native・127.0.0.1宛て）のものです。

2. なぜACE-Step 1.5か — Mac視点の技術選定

「ローカルAI作曲 Mac」で候補に挙がるモデルを、歌もの（ボーカル付き）・Mac動作・ライセンスの3軸で比較しました。ライセンスは全て公式リポジトリ/モデルカードで一次裏取りしています（2026年7月時点）。

モデル 見送り理由 ライセンス（一次裏取り済）
MusicGen / AudioCraft 重みがCC-BY-NC 4.0で商用不可（コードはMIT）。さらに学習データからボーカルをソース分離で除去済みで、公式が「The model is not able to generate realistic vocals.」と明記＝歌ものが作れない コード=MIT／重み=CC-BY-NC 4.0・モデルカード
YuE Mac動作パスなし。公式が「FlashAttention 2 is mandatory」と明記＝CUDA前提で、macOS/Apple Silicon対応の記載がない。※ライセンス自体はApache 2.0で問題なし Apache 2.0
Stable Audio Open 公式モデルカードが「The model is not able to generate realistic vocals.」と明記＝歌もの不可 Stability AI Community License
DiffRhythm コードとDiT重みはApache 2.0だが、VAEのみStability AI Community License（公式が「DiffRhythm-VAE is subject to the Stability AI Community License Agreement」と明記）でコンポーネントごとにライセンスが割れる。管理が煩雑 コード/DiT=Apache 2.0・VAE=Stability AI Community License

ちなみに前記事でBGMに使ったMusicGenは、この表の通り「商用不可＋歌えない」なので、BGM止まりでした。歌ものをやるなら別のモデルが要る、が今回の出発点です。

ACE-Step 1.5を選んだ決め手は3つ。

  1. MITライセンス（商用利用に制限なし。上の表と比べるとこの素直さは貴重）
  2. 公式のmacOS/Apple Silicon対応。start_api_server_macos.shが同梱され、LM側はMLX・DiT側はPyTorch MPSで動く
  3. REST APIサーバ同梱で、量産・自動化に組み込みやすい

LMは0.6B/1.7B/4Bがありますが、今回は0.6Bで開始しました。1.7Bはピーク42GBという外部報告があり（自前未検証）、他のローカルLLMを常駐させている環境では見送りが無難と判断しています。

3. 導入と起動（M1 Max 64GB・初回DL約7GB）

導入自体は素直です。ここは簡潔に。

環境: MacBook Pro M1 Max 64GB（Unified Memory）。サーバは起動時に「51.8GB unified memory, tier=unlimited」を検出しました。モデルはLM=acestep-5Hz-lm-0.6B＋DiT=acestep-v15-turbo。

# APIサーバ起動（ポート8001・LMはMLXバックエンド）
ACESTEP_LM_BACKEND=mlx TOKENIZERS_PARALLELISM=false \
  uv run acestep-api --host 127.0.0.1 --port 8001 --lm-model-path acestep-5Hz-lm-0.6B

# 起動確認
lsof -nP -iTCP:8001 -sTCP:LISTEN

初回はモデルのダウンロードが走ります。実測ではcheckpoints/合計約7GB（47MB/sの回線で約4分）でした。

細かい罠を3つ。

  • start_api_server_macos.shはgit更新チェックで対話プロンプトが出ることがある。uv run acestep-apiの直叩きが確実。
  • 同梱CLIscripts/acestep.shは実行bitが立っていない。bash経由で呼ぶ。
  • 初回DLや長尺の生成は、同期実行だとタイムアウトする。バックグラウンド実行推奨。

4. 実測: 100秒の歌もの2曲が58.48秒（LM 15.70s＋DiT 42.78s）

図1: パイプライン全体図

本題の実測です。生成はcaption（曲調タグ）＋構造タグ付き歌詞＋パラメータをCLIに渡すだけ。

bash scripts/acestep.sh generate -c "<caption>" -l "<構造タグ付きフル歌詞>" \
  --duration 100 --bpm 100 --key-scale "C major" --language en

1曲目（100秒のABCソング）の結果メタデータがこれです。1リクエストでseed違いの2バリアントが自動生成され、その2曲合計の生成時間が記録されます。

"generation_info": "**🎵 Total generation time (2 songs): 58.48s**
  - 29.24s per song
  - LM phase (2 songs): 15.70s
  - DiT phase (2 songs): 42.78s",
"seed_value": "1014051477,117013642"

100秒の完成曲2本が58.48秒。 曲の実尺より生成の方が速い、いわゆるリアルタイム超えです。内訳はLM（歌詞→セマンティックトークン）が15.70s、DiT（音声合成）が42.78s。この内訳が取れると「どちらを軽くすれば速くなるか」の当たりが付くので、meta.jsonは捨てずに残すのをおすすめします。

8曲通しの実測

このペースは1曲目だけのまぐれではなく、8曲を通しても安定していました。

曲 尺 2バリアント生成時間
01 100秒 58.48s
02 110秒 66.32s
03 — 62.99s
04 — 63.97s
05 — 68.92s
06 — 65.55s
07 120秒 74.91s
08 115秒 74.90s

全8曲×2バリアント（16音源）の総生成時間は約9分。 成果物は各曲100〜125秒・48kHz・128kbpsのmp3で、ファイルサイズは約1.6MB（100秒）〜約2.0MB（125秒）。歌詞は入力どおり一字一句合成されていました（meta.jsonのmetas.lyrics実査で確認）。

数値はすべてこの構成のM1 Max 64GBでの実測です。M2/M3/M4では未計測のため、他チップへの外挿はしていません。「誰でも58秒」を保証するものではありません。

5. 歌詞設計：LMNOP問題という普遍ネタ

生成が速くても、歌詞設計を外すと使いものになりません。ここからは競合記事にない運用実録です。

「エレメノピー」問題

ABCの歌の伝統的メロディでは、L-M-N-O-Pが詰め込まれて「エレメノピー」と潰れて聞こえる——よく知られた既知問題です。今回はグルーピングを変えて等間隔に置き直すことで回避しました: ABCD / EFG / HIJK / LMN / OPQ / RST / UVW / XYZ。

これはアルファベットに限らず、数字・曜日など列挙系の歌詞全般に効く原則です: 各項目を等間隔に置き、列挙に"and"を挟まない（"twenty-nine and thirty"は実際に採点で指摘されました）。

AI歌声合成で発音を明瞭にする汎用テク

ACE-Stepに限らず効くはずの、実戦で固まった歌詞側のテクニックです。

  • 数字は英単語で書く（"30"→"thirty"。文字起こし採点でも数字正規化が必要でした）
  • 文字は A - B - C 区切りで1文字ずつ発音させる
  • 1行4〜8語・6〜10音節、並行する行の音節数は±1〜2で揃える
  • サビの繰り返しは一字一句同じ綴りに。バックコーラスは括弧 (happy!)、[call and response]等の構造タグを使う
  • captionはタグ4〜7個で一貫させ、captionと歌詞のムードを矛盾させない。BPM/keyはcaptionに書かず専用パラメータで渡す
  • 独立採点から出た禁則3つ: ①列挙系に"and"を入れない ②韻合わせ優先で英語を不自然にしない（"but fun, all right!"が実例） ③サビの改変は1箇所まで。同一の列挙は曲内で表記統一（fall vs autumn混在NG）

実物：1曲目のフル歌詞とパラメータ

  • パラメータ: duration 100s / BPM 100 / C major / vocal en
  • caption: children's song, cheerful, playful, simple melody, ukulele, glockenspiel, acoustic guitar, clear female vocals, warm, sing-along 
[Intro]

[Verse]
A - B - C - D
E - F - G
H - I - J - K
L - M - N

[Verse]
O - P - Q
R - S - T
U - V - W
X - Y - Z

[Chorus]
Now I know my A - B - C (A - B - C!)
Sing the alphabet with me (sing with me!)
Happy letters, you and me
Come and sing the A - B - C

[Verse]（繰り返し）
[Chorus]（繰り返し）

[Outro]
A - B - C, you and me!

この歌詞がそのまま、上の58.48秒で2バリアントになりました（実測48kHz・各100.03秒）。

6. 「自分の曲を自分で採点しない」— Whisper3層採点

16音源を全部耳で聴き比べて優劣を付けるのは、正直つらい。そこで文字起こしによる客観採点を挟みました。その導入でまた地雷を踏んだので、そこから書きます。

失敗談2：uvxがx86 Pythonを掴む

採点用にmlx-whisper（完全ローカルの文字起こし）をuvxで入れようとしたら、依存解決に失敗。原因は、このマシンの既定python3がanaconda由来のx86_64（Rosetta）ビルドで、uvxがそれを掴んだこと。mlxはarm64専用なので入りません。

前記事で「arm64 Pythonを掴ませろ」と書いた地雷の続編です。venvを自分で切るときは避けられても、uvxのような便利ラッパー越しだと再発する。--pythonでarm64のCPythonを明示すれば通ります。

uvx --python cpython-3.12-macos-aarch64-none --from mlx-whisper \
  mlx_whisper <mp3> --model mlx-community/whisper-large-v3-turbo

Apple SiliconでMLX系ツールが謎の失敗をしたら、まずpython3 -c "import platform; print(platform.machine())"でarchを確認する。anaconda併用機は特に、です。

3層の構成

  1. 客観層: mlx-whisper（large-v3-turbo・Apache 2.0・完全ローカル）で各音源を文字起こしし、実際に合成に使われた歌詞（meta.json実査）との単語列一致率を出す。数字は英単語に正規化して比較（"1,2,3"転写による偽低スコアを補正）
  2. 独立層: 別コンテキストのエージェントにルーブリック採点させる（英語の正しさ25／設計原則遵守25／教育効果25／歌いやすさ25＝100点）。作った本人（同じ文脈のセッション）に採点させると甘くなるので分離する
  3. 最終層: 人間の耳。Whisperの測定限界（後述）を人が埋める

実測データの物語

一致率は思った以上にばらけます。v1の16音源で最低0.0%（Whisperが"Thank you"を幻聴し続ける不良テイク）から最高97.1%（3曲目のバリアントb・ほぼ完全聴取）まで。このばらつきが見えること自体が、自動採点を入れた最大の収穫でした。

独立ルーブリックの指摘を反映してv2を7曲再生成（差し戻し1回）した後の、v1/v2比較が面白いところです。

図3: v1/v2採点比較チャート

  • 修正が効いた例: 8曲目は92.5→100.0（完璧な聞き取り）
  • 修正したのに落ちた例: 1曲目は75.3→53.2。歌詞は良くなったのに明瞭度が下がった。つまり歌詞修正とseed運は独立——ここから「旧テイクを捨てず、曲ごとに最良テイクを採用する」運用に切り替えました
  • 触らない裁定: 3曲目のバリアントbは一致率97.1%（16音源中最高）・独立採点97点。修正提案は出ていたが「触るリスク＞益」で不採用にしました。最高スコアのテイクをいじらない勇気も運用のうちです

最終採用の8本は平均一致率83.9%（v1採用時点では81.9%）、独立ルーブリック平均94.1点（最高98・最低89で、89の曲は指摘4件を全部修正）。

測定限界も正直に書く

Whisper一致率は発音明瞭度の代理指標であって、品質スコアそのものではありません。特に「文字の歌唱（A - B - C）」はWhisperが誤転写しやすく、一致率が下振れします（1曲目で"EBC"等の誤転写を確認）。数値だけで切らず、最終判定は耳です。また0.0%のような不良テイクは出ますが、サンプル数が小さいので「失敗率◯%」のような一般化はしません。1リクエスト2バリアント生成が不良テイク保険として機能し、今回は2本の不良テイクを追加コストゼロで回避できました。

7. 再現レシピ（最短手順まとめ）

  1. 導入: git clone→uv sync→APIサーバ起動（ACESTEP_LM_BACKEND=mlxで§3のコマンド。初回DL約7GBはバックグラウンドで）
  2. 接続先の実査: 生成前に接続先URLとapi_modeを確認（§1のconfig --set2行。健診OKを信じない）
  3. 生成: caption／構造タグ付き歌詞／duration・bpm・key-scaleで生成（§4のコマンド。1リクエストで2バリアント出る）
  4. 採点: mlx-whisperで文字起こし→歌詞との一致率（§6のコマンド。arm64 Pythonを--pythonで明示。数字は英単語に正規化して比較）
  5. 最終判定は耳: 一致率は代理指標。文字歌唱の下振れ等はWhisperの限界なので、最後は聴いて決める

8. ローカルAI勢へ（まとめ）

課金ゼロ・外部送信ゼロで、歌もの16音源＋再生成14音源をこのMac一台で作れました。100秒の曲2本が約58秒、8曲×2バリアントで約9分（この構成のM1 Max 64GBでの実測）。「Macで歌もの生成は現実的か？」への私の答えは、この構成に関しては、生成速度はもう問題ではないです。時間を食うのは歌詞設計と品質判定で、だからこそ採点の自動化が効きました。

教訓を3行で。

  • 健診OKを信じない。 接続先URLとapi_modeを実査してから「ローカルで動いた」と言う
  • arm64 Pythonを先に確認する。 uvx等のラッパー越しでもx86地雷は再発する
  • 自分の曲を自分で採点しない。 Whisper一致率×独立ルーブリック×耳の3層。そして歌詞修正とseed運は独立——旧テイクは捨てない

動画編はこちら → M1 Macで"完全無料・ローカル"のAIショート動画パイプラインを作った全記録。同じMacの中で、シリーズは続けるつもりです。あなたのローカル作曲の詰まりどころも、どこかで聞かせてください。

（数値・所要時間はいずれもこのM1 Max 64GB環境での実測に基づき、憶測の数字・保証表現は含みません。ライセンス・公式仕様の引用は2026年7月時点の各公式リポジトリ/モデルカードの記載です。）

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?