SunoとACE-Step 1.5はどのくらい違うのか？

目次

1. ACE-Step 1.5の基本的な考え方
2. LM＋音楽生成モデルという構造
3. モデルの種類と音質の違い
4. プロンプトと歌詞の上限
5. 文字数目安に関する注意点
6. プロンプトの書式はSunoと異なる
7. まとめ

何となく調べたデータをチャッピーにまとめさせました。

ACE-Step 1.5の基本的な考え方

ACE-Step 1.5は、従来の音楽生成とは異なるアプローチを取っています。

一般的な方法では、拡散モデルがテキストから直接オーディオを生成しますが、ACE-Step 1.5では中間層としてLM（言語モデル）を挟む構造になっています。

つまり、

• ユーザーの入力をそのまま音に変換するのではなく

• いったんLMで整形・補正したうえで

• 音楽生成モデルに渡す

という流れです。

---

LM＋音楽生成モデルという構造

この構造から見えてくる特徴は次の通りです。

• 入力内容は、LMを経由してモデルに伝えられる

• LMの性能次第で、モデルに渡る情報の質が変わる

• LMを使わない選択肢もあるが、内部的に何が最適な指示なのかは分からない

ACE-Step 1.5は、プロンプトの書き方そのものよりも、
LMがどのように入力を解釈するかが結果に影響する設計だと考えられます。

---

モデルの種類と音質の違い

ACE-Step 1.5には、以下の3種類のモデルがあります。

• turboモデル

• SFTモデル

• Baseモデル

デフォルト設定で「音質があまり良くない」と感じる場合、turboモデルを使用していることが一因である可能性があります。

ここから自然に出てくる疑問は、

• モデルを変えると音質はどう変わるのか

• step数を増やすことで改善は見込めるのか

といった点です。
このあたりは、実際に試して検証していく必要があります。

---

プロンプトと歌詞の上限

ACE-Step 1.5では、プロンプトや歌詞に明確な上限が設けられています。

運用上限

• プロンプト：256トークン（目安として約200文字）

• 歌詞：2048トークン（目安として約1500文字）

この上限は、超過分を切り捨てる設定になっています。handler.py を編集することで変更可能ですが、モデルがこの設定に最適化されていることが予想されますので、現実的には簡単に触れる部分ではありません。

システム上限

一方で、Text Encoder（Qwen3-Embedding-0.6B）には
32768トークンというシステム上限が存在します。

---

文字数目安に関する注意点

トークン数と文字数の対応は言語によって異なります。表示されている「文字数目安」は英語を前提にしている可能性があり、日本語では体感的に制限が厳しく感じる場合があります。

そのため、実運用では
文字数ではなくトークン制限を意識する必要があると言えます。

---

プロンプトの書式はSunoと異なる

Sunoでは、歌詞の上部にもスタイル指定のプロンプトを書く形式が一般的ですが、ACE-Step 1.5では、そのような明確な指定方法は見当たりません。

また、文字数制限を考えると、

• セクションごとに細かいプロンプトを書く

• 歌詞と併せて詳細な指示を入れる

といった使い方は、現実的に難しく感じます。

この点からも、ACE-Step 1.5は入力を細かく制御するというより、全体方針を渡す設計に近い印象です。

---

まとめ

現時点で整理できる違いは次の通りです。

• 音質の第一印象はSunoの方が良い

• ACE-Step 1.5は、LMを介した構造により内部の仕組みが見える

• モデルの種類やstep数によって結果が変わる余地がある

• プロンプト・歌詞には運用上限とシステム上限が存在する

• 入力設計には制約を意識する必要がある

Sunoは「最初から完成度の高い音を出す」方向性であり、ACE-Step 1.5は「設定や構造を理解した上で調整する余地がある」設計です。

どちらが優れているかというよりも、完成度を重視するか、仕組みを理解して詰めていくかで選択が変わるツールだと言えます。