# ACE-Step 1.5 究極ガイド（必読）

**Language / 语言 / 言語:** [English](../en/Tutorial.md) | [中文](../zh/Tutorial.md) | [日本語](Tutorial.md)

---

こんにちは、ACE-Stepの開発者、龔俊民です。このチュートリアルを通じて、ACE-Step 1.5の設計哲学と使用方法をご紹介します。

## メンタルモデル

始める前に、適切な期待管理のために正しいメンタルモデルを確立する必要があります。

### 人間中心の設計

このモデルは**ワンクリック生成**のためではなく、**人間中心の生成**のために設計されています。

この違いを理解することが重要です。

### ワンクリック生成とは？

プロンプトを入力し、生成をクリックし、いくつかのバージョンを聞いて、良さそうなものを選んで使用します。別の人が同じプロンプトを入力すると、おそらく似た結果が得られます。

このモードでは、あなたとAIは**クライアントとベンダー**の関係です。明確な目的を持って来て、頭の中に曖昧な期待があり、AIがその期待に近い製品を提供することを望みます。本質的には、Googleで検索したり、Spotifyで曲を探したりするのと大差ありません——カスタマイズが少し増えただけです。

AIはサービスであり、創造的なインスピレーションを与えるものではありません。

Suno、Udio、MiniMax、Mureka——これらのプラットフォームはすべてこの設計思想を持っています。モデルを大きくしてサービスとして提供すればよいのです。あなたが生成した音楽は彼らの契約に縛られます；ローカルで実行できず、パーソナライズされた探索のために微調整できません；彼らが密かにモデルや条項を変更しても、あなたはそれを受け入れるしかありません。

### 人間中心の生成とは？

AIの層を弱め、人間の層を強化する——より多くの人間の意志、創造性、インスピレーションがAIに生命を与える——これが人間中心の生成です。

ワンクリック生成の強い目的性とは異なり、人間中心の生成はより**遊び**の性質を持っています。それは対話的なゲームのようなもので、あなたとモデルは**協力者**の関係です。

ワークフローは次のとおりです：いくつかのインスピレーションの種を投げ、いくつかの曲を得て、そこから興味深い方向を選択して反復を続けます——
- プロンプトを調整して再生成
- **Cover**を使用して構造を維持し、詳細を調整
- **Repaint**で局所的な変更
- **Add Layer**で楽器の層を追加または削除

この時点で、AIはあなたにとってサービス提供者ではなく、**インスピレーションを与えるもの**です。

### この設計はどのような条件を満たす必要があるか？

人間中心の生成を真に機能させるには、モデルがいくつかの重要な条件を満たす必要があります：

**第一に、オープンソースで、ローカルで実行可能で、訓練可能でなければなりません。**

これは技術的な純粋主義ではなく、所有権の問題です。クローズドソースのプラットフォームを使用すると、モデルを所有せず、生成した作品も彼らの契約に縛られます。バージョン更新、条項変更、サービスの停止——これらはすべてあなたの制御下にありません。

しかし、モデルがオープンソースでローカル実行可能な場合、すべてが変わります：**あなたは永遠にこのモデルを所有し、あなたとモデルが一緒に作成したすべての産物を永遠に所有します。** サードパーティの契約の煩わしさがなく、プラットフォームのリスクもなく、微調整、改造、それに基づいて独自の創作システムを構築できます。あなたの作品は永遠にあなたのものです。それは楽器を買うようなものです——いつでもどこでも使用でき、いつでもどこでも調整できます。

**第二に、速くなければなりません。**

人間の時間は貴重ですが、さらに重要なのは——**遅い生成はフロー状態を破壊する**ことです。

人間中心のワークフローの核心は、「試す、聞く、調整する」の迅速なサイクルです。各生成に数分かかる場合、待機中にインスピレーションが消え、「遊び」の体験が「待つ」苦痛に退化します。

したがって、私たちはACE-Stepをこれに特化して最適化しました：品質を保証しながら、生成を十分に速くし、スムーズな人間と機械の対話リズムを支えることができるようにしました。

### 有限ゲーム vs 無限ゲーム

ワンクリック生成は**有限ゲーム**です——明確な目標、結果指向、終点で終了します。ある程度、それは音楽産業を冷たく空洞化し、多くの人の仕事を置き換えました。

人間中心の生成は**無限ゲーム**です——楽しみはプロセスの中にあり、プロセスは決して終わらないからです。

私たちのビジョンは、AI音楽生成を民主化することです。ACE-Stepをあなたのポケットの中の大きなおもちゃにし、音楽を**Play**そのものに戻す——創造的な「遊び」であり、単に再生をクリックするだけではありません。

---

## 象使いのメタファー

> 推奨読書：[The Complete Guide to Mastering Suno](https://www.notion.so/The-Complete-Guide-to-Mastering-Suno-Advanced-Strategies-for-Professional-Music-Generation-2d6ae744ebdf8024be42f6645f884221)——このブログチュートリアルは、AI音楽の基礎理解を確立するのに役立ちます。

AI音楽生成は、心理学の有名な**象使いのメタファー**のようなものです。

意識は潜在意識の上に乗り、人間は象の上に乗ります。方向を与えることはできますが、象にすべての命令を正確に、即座に実行させることはできません。それは独自の慣性、独自の気質、独自の意志を持っています。

この象が、音楽生成モデルです。

### 氷山モデル

オーディオと意味の間には、隠された氷山があります。

言語で説明できるもの——スタイル、楽器、音色、感情、シーン、展開、歌詞、ボーカルスタイル——これらは私たちが知っている言葉で、触れることができる部分です。しかし、それらを合わせても、オーディオという氷山が海面から浮かび上がっている小さな一角に過ぎません。

最も正確な制御とは何ですか？期待されるオーディオを入力し、モデルがそれを変更せずに返すことです。

しかし、テキスト記述、参照、プロンプトを使用する限り——モデルには遊ぶ余地があります。これはバグではなく、物事の本質です。

### 象とは何か？

この象は無数の要素の融合です：データ分布、モデル規模、アルゴリズム設計、注釈の偏り、評価の偏り——**それは人間の音楽史とエンジニアリングのトレードオフの抽象的な結晶です。**

これらの要素のいずれかの偏差は、あなたの好みや期待を正確に反映できない原因となります。

もちろん、データ規模を拡大し、アルゴリズム効率を向上させ、注釈精度を向上させ、モデル容量を拡大し、より専門的な評価システムを導入できます——これらはすべて、モデル開発者として最適化できる方向です。

しかし、技術的に「完璧」を達成したとしても、回避できない根本的な問題があります：**好み。**

### 好みと期待

好みは人によって異なります。

音楽生成モデルがすべてのリスナーを喜ばせようとすると、その出力は人間の音楽史の流行平均に向かいます——**これは極めて平凡になります。**

音に意味、感情、経験、生命、文化的象徴的価値を与えるのは人間です。少数のアーティストグループが独特の好みを作り出し、その後、一般の人々を消費し、追随させ、ニッチが大衆の人気になりました。これらの少数派の先駆的なアーティストが伝説になりました。

したがって、モデルの出力が「好みに合わない」と感じた場合、これはモデルの問題ではない可能性があります——**あなたの好みがその「平均」の外にあるということです。** これは良いことです。

これは意味します：**象を自動的に理解することを期待するのではなく、この象を導く方法を学ぶ必要があるということです。**

---

## 象の群れを知る：モデルアーキテクチャと選択

今、あなたは「象」のメタファーを理解しています。しかし実際には——

**これは1頭の象ではなく、大小さまざまな象の群れ——家族を形成しています。** 🐘🐘🐘🐘

### アーキテクチャの原理：2つの脳

ACE-Step 1.5は、2つのコアコンポーネントが協力して動作する**ハイブリッドアーキテクチャ**を使用します：

```
ユーザー入力 → [5Hz LM] → セマンティックブループリント → [DiT] → オーディオ
              ↓
         メタデータ推論
         Caption最適化
         構造計画
```

**5Hz LM（言語モデル）—— 計画者（オプション）**

LMは「全能的計画者」で、あなたの意図を理解し、計画を立てる責任があります：
- **Chain-of-Thought**を通じて音楽メタデータ（BPM、キー、時間など）を推論
- あなたのキャプションを最適化および拡張——あなたの意図の理解と補足
- **セマンティックコード**を生成——作曲メロディ、オーケストレーション、およびいくつかの音色情報を暗黙的に含む

LMは訓練データから**世界知識**を学びます。それは可用性を向上させ、迅速にプロトタイプを生成するのに役立つ計画者です。

**しかし、LMは必須ではありません。**

何が欲しいかが非常に明確である場合、または明確な計画目標が既にある場合——`thinking`モードを使用せず、LMの計画ステップを完全にスキップできます。

例えば、**Coverモード**では、参照オーディオを使用して作曲、和音、構造を制約し、DiTに直接生成させます。ここでは、**あなたがLMの仕事を置き換えます**——あなた自身が計画者になります。

別の例：**Repaintモード**では、参照オーディオをコンテキストとして使用し、音色、ミキシング、詳細を制約し、DiTに局所的に直接調整させます。この時点で、DiTは創造的なブレインストーミングパートナーのようなもので、創造的なアイデア出しを助け、局所的な不調和を修正するために使用できます。

**DiT（Diffusion Transformer）—— 実行者**

DiTは「オーディオ職人」で、計画を現実に変える責任があります：
- LMが生成したセマンティックコードと条件を受信
- **拡散プロセス**を通じてノイズから徐々にオーディオを「彫刻」
- 最終的な音色、ミキシング、詳細を決定

**なぜこの設計なのか？**

従来の方法では、拡散モデルがテキストから直接オーディオを生成しますが、テキストからオーディオへのマッピングは曖昧すぎます。ACE-Stepは中間層としてLMを導入します：
- LMは意味の理解と計画が得意
- DiTは高忠実度オーディオの生成が得意
- 2つが協力し、それぞれの役割を果たす

### 計画者の選択：LMモデル

LMには4つの選択肢があります：**LMなし**（thinkingモードを無効化）、**0.6B**、**1.7B**、**4B**。

それらの訓練データは完全に同一で、違いは純粋に**知識容量**にあります：
- モデルが大きいほど、世界知識が豊富
- モデルが大きいほど、記憶能力が強い（例：参照オーディオのメロディを記憶）
- モデルが大きいほど、ロングテールのスタイルや楽器で相対的に優れたパフォーマンス

| 選択 | 速度 | 世界知識 | 記憶能力 | 使用ケース |
|------|:----:|:--------:|:--------:|----------|
| LMなし | ⚡⚡⚡⚡ | — | — | あなたが計画を行う（例：Coverモード） |
| `0.6B` | ⚡⚡⚡ | 基本 | 弱い | 低VRAM（< 8GB）、迅速なプロトタイピング |
| `1.7B` | ⚡⚡ | 中程度 | 中程度 | **デフォルト推奨** |
| `4B` | ⚡ | 豊富 | 強い | 複雑なタスク、高品質生成 |

**選択方法は？**

ハードウェアに基づいて：
- **VRAM < 8GB** → LMなしまたは`0.6B`
- **VRAM 8–16GB** → `1.7B`（デフォルト）
- **VRAM > 16GB** → `1.7B`または`4B`

### 実行者の選択：DiTモデル

計画スキームがあっても、実行者を選択する必要があります。DiTはACE-Step 1.5の核心——さまざまなタスクを処理し、LMが生成したコードを解釈する方法を決定します。

私たちは**4つのTurboモデル**、**1つのSFTモデル**、**1つのBaseモデル**をオープンソース化しました。

#### Turboシリーズ（日常使用に推奨）

Turboモデルは蒸留訓練を受け、わずか8ステップで高品質オーディオを生成します。4つのバリアントの核心的な違いは、**蒸留時のshiftハイパーパラメータ設定**です。

**shiftとは何か？**

shiftはDiTのノイズ除去時の「注意配分」を決定します：
- **shiftが大きい** → 初期ノイズ除去（純粋なノイズから大きな構造を構築）により多くの労力を費やす、**セマンティクスが強い**、全体的なフレームワークがより明確
- **shiftが小さい** → ステップ配分がより均等、**詳細が多い**、ただし詳細はノイズの可能性もある

簡単な理解：高shiftは「輪郭を先に描いてから詳細を埋める」、低shiftは「描きながら修正する」ようなものです。

| モデル | 蒸留設定 | 特徴 |
|--------|----------|------|
| `turbo`（デフォルト） | shift 1、2、3で共同蒸留 | **創造性とセマンティクスの最良のバランス**、十分にテスト済み、推奨の第一選択 |
| `turbo-shift1` | shift=1のみで蒸留 | 詳細がより豊富だが、セマンティクスは弱い |
| `turbo-shift3` | shift=3のみで蒸留 | 音色がより明確で豊富だが、「乾いた」感じになり、オーケストレーションはミニマル |
| `turbo-continuous` | 実験的、shift 1–5の連続調整をサポート | 調整が最も柔軟だが、十分にテストされていない |

目標音楽スタイルに基づいて選択できます。特定のバリアントに好みを見つけるかもしれません。**デフォルトのturboから始めることを推奨します**——最もバランスが取れて、実証済みの選択です。

#### SFTモデル

Turboと比較して、SFTモデルには2つの顕著な特徴があります：
- **CFG（Classifier-Free Guidance）をサポート**、プロンプトの遵守度を細かく調整可能
- **ステップ数が多い**（50ステップ）、モデルに「考える」時間をより多く与える

代償：ステップ数が多いということは、誤差の蓄積を意味し、オーディオの明瞭度はTurboよりわずかに劣る可能性があります。しかし、その**詳細表現とセマンティック解析はより良い**です。

推論時間を気にせず、CFGとステップ数の調整が好きで、その豊かな詳細感を好む場合——SFTは良い選択です。LMが生成したコードもSFTモデルで機能します。

#### Baseモデル

Baseは**タスクの集大成**で、SFTとTurboを超える3つの独占タスクがあります：

| タスク | 説明 |
|--------|------|
| `extract` | 混合オーディオから単一トラックを抽出（例：ボーカルを分離） |
| `lego` | 既存のトラックに新しいトラックを追加（例：ギターにドラムを追加） |
| `complete` | 単一トラックに混合伴奏を追加（例：ボーカルにギター+ドラムの伴奏を追加） |

さらに、Baseは**可塑性が最も強い**です。大規模な微調整のニーズがある場合、Baseから実験を開始し、独自のSFTモデルを訓練することを推奨します。

#### 独自のカスタムモデルの作成

公式モデルに加えて、**LoRA微調整**を使用して独自のカスタムモデルを作成することもできます。

サンプルLoRAモデルをリリースします——20曲以上の「新年おめでとう」テーマの曲で訓練され、祝祭の雰囲気を表現するのに適しています。これは出発点に過ぎません。

**カスタムモデルとは何を意味するか？**

独自のデータレシピでDiTの能力と好みを再形成できます：
- 特定の音色スタイルが好きですか？そのタイプの曲で訓練
- モデルを特定のジャンルに優れさせたいですか？関連データを収集して微調整
- 独自の独特な美的趣味がありますか？それをモデルに「教える」

これは**カスタマイズと遊びやすさ**を大幅に拡張します——あなたの美的趣味で、あなた専用のモデルを訓練します。

> LoRA訓練の詳細ガイドについては、[LoRA トレーニングチュートリアル](./LoRA_Training_Tutorial.md)を参照してください。Gradio UIの「LoRA Training」タブからワンクリックで訓練することもできます。

#### XL (4B) モデル

XLモデルは、より大きな4BパラメータのDiTデコーダを使用し、生成品質が向上します。標準モデルと同じ3つのバリアント（base、sft、turbo）で、動作は完全に同じです。**すべてのLMモデル（0.6B / 1.7B / 4B）がXLと完全互換です。**

**必要条件:** XLモデルの重みは約9GB（bf16）、2Bは約4.7GB。最小12GB VRAM（オフロード + 量子化が必要）、20GB+推奨。

| XLモデル（フルネーム） | ステップ | CFG | VRAM | 備考 |
|----------------------|:-------:|:---:|:----:|------|
| `acestep-v15-xl-turbo` | 8 | ❌ | ≥12GB | 高速 + 高品質、20GB+ GPUの最適な日常選択 |
| `acestep-v15-xl-sft` | 50 | ✅ | ≥12GB | 最高品質、CFG調整可能 |
| `acestep-v15-xl-base` | 50 | ✅ | ≥12GB | extract/lego/completeを含む全タスク対応 |

#### DiT選択のまとめ

| モデル | ステップ | CFG | 速度 | 独占タスク | 推奨シナリオ |
|--------|:-------:|:---:|:----:|----------|------------|
| `turbo`（デフォルト） | 8 | ❌ | ⚡⚡⚡ | — | 日常使用、迅速な反復 |
| `sft` | 50 | ✅ | ⚡ | — | 詳細を追求、調整が好き |
| `base` | 50 | ✅ | ⚡ | extract, lego, complete | 特殊タスク、大規模微調整 |
| **`acestep-v15-xl-turbo`** | 8 | ❌ | ⚡⚡ | — | 20GB+ GPUの最適な日常選択 |
| **`acestep-v15-xl-sft`** | 50 | ✅ | ⚡ | — | 最高品質、≥12GB VRAM |
| **`acestep-v15-xl-base`** | 50 | ✅ | ⚡ | extract, lego, complete | より高品質な全タスク対応、≥12GB VRAM |

### 組み合わせ戦略

デフォルト設定は**turbo + 1.7B LM**で、ほとんどのシナリオに適しています。

| ニーズ | 推奨組み合わせ |
|--------|--------------|
| 最速 | `turbo` + LMなしまたは`0.6B` |
| 日常使用 | `turbo` + `1.7B`（デフォルト） |
| 詳細を追求 | `sft` + `1.7B`または`4B` |
| 特殊タスク | `base` |
| 大規模微調整 | `base` |
| 低VRAM（< 4GB） | `turbo` + LMなし + CPUオフロード |

### モデルのダウンロード

```bash
# デフォルトモデルをダウンロード（turbo + 1.7B LM）
uv run acestep-download

# すべてのモデルをダウンロード
uv run acestep-download --all

# 特定のモデルをダウンロード
uv run acestep-download --model acestep-v15-base
uv run acestep-download --model acestep-5Hz-lm-0.6B

# 利用可能なモデルを表示
uv run acestep-download --list
```

モデルは`checkpoints`フォルダにダウンロードする必要があります。識別しやすくするためです。

---

## 象を導く：何を制御できるか？

今、あなたはこの象の群れを知っています。次に、それらとコミュニケーションを取る方法を学びましょう。

各生成は、**入力制御**、**推論ハイパーパラメータ**、**ランダム要因**の3種類の要因によって決定されます。

### I. 入力制御：何が欲しいか？

これは、モデルと「創造的意図」をコミュニケーションする部分——どのような音楽を生成したいか。

| カテゴリ | パラメータ | 機能 |
|----------|-----------|------|
| **タスクタイプ** | `task_type` | 生成モードを決定：text2music、cover、repaint、lego、extract、complete |
| **テキスト入力** | `caption` | 音楽の全体的な要素の説明：スタイル、楽器、感情、雰囲気、音色、ボーカルの性別、展開など |
| | `lyrics` | 時間的要素の説明：歌詞内容、音楽構造の進化、ボーカルの変化、ボーカル/楽器の演奏スタイル、開始/終了スタイル、発声スタイルなど（インストゥルメンタル音楽には`[Instrumental]`を使用） |
| **音楽メタデータ** | `bpm` | テンポ（30–300） |
| | `keyscale` | キー（例：C Major、Am） |
| | `timesignature` | 拍子記号（4/4、3/4、6/8） |
| | `vocal_language` | ボーカル言語 |
| | `duration` | 目標時間（秒） |
| **オーディオ参照** | `reference_audio` | 音色またはスタイルのグローバル参照（cover、スタイル転送用） |
| | `src_audio` | 非text2musicタスク用のソースオーディオ（text2musicはデフォルトでサイレント、入力不要） |
| | `audio_codes` | Coverモードでモデルに入力するセマンティックコード（高度な使用：コードを再利用してバリアントを生成、曲をコードに変換して拡張、DJのように組み合わせてミックス） |
| **間隔制御** | `repainting_start/end` | 操作の時間間隔（repaint再描画領域 / lego新規トラック領域） |

---

#### Captionについて：最も重要な入力

**Captionは生成音楽に影響を与える最も重要な要因です。**

複数の入力形式をサポート：簡単なスタイル単語、カンマ区切りのタグ、複雑な自然言語記述。訓練でさまざまな形式と互換性があるようにし、テキスト形式がモデルのパフォーマンスに大きく影響しないようにしました。

**良いキャプションを書くための少なくとも5つの方法を提供します：**

1. **ランダムダイス** — UIのランダムボタンをクリックして、サンプルのキャプションの書き方を確認します。この標準化されたキャプションをテンプレートとして使用し、LLMに希望の形式に書き換えてもらうことができます。

2. **Format自動書き換え** — `format`機能を使用して、手書きの簡単なキャプションを自動的に複雑な記述に拡張することをサポートします。

3. **CoT書き換え** — LMが初期化されている場合、`thinking`モードが有効かどうかに関わらず、Chain-of-Thoughtを通じてキャプションを書き換えおよび拡張することをサポートします（設定で明示的に無効にしない限り、またはLMが初期化されていない場合）。

4. **オーディオからCaptionへ** — 私たちのLMは、入力オーディオをキャプションに変換することをサポートします。精度は限られていますが、曖昧な方向は正しい——出発点として十分です。

5. **Simpleモード** — 簡単な曲の説明を入力するだけで、LMが自動的に完全なキャプション、歌詞、メタサンプルを生成します——迅速な開始に適しています。

どの方法でも、現実の問題を解決します：**普通の人として、私たちの音楽語彙は貧弱です。**

生成された音楽をより興味深く、期待に応えるものにしたい場合、**Promptingは常に最適なオプション**です——それは最高の限界収益と驚きをもたらします。

**Caption作成の一般的な次元：**

| 次元 | 例 |
|------|-----|
| **スタイル/ジャンル** | pop, rock, jazz, electronic, hip-hop, R&B, folk, classical, lo-fi, synthwave |
| **感情/雰囲気** | melancholic, uplifting, energetic, dreamy, dark, nostalgic, euphoric, intimate |
| **楽器** | acoustic guitar, piano, synth pads, 808 drums, strings, brass, electric bass |
| **音色テクスチャ** | warm, bright, crisp, muddy, airy, punchy, lush, raw, polished |
| **時代参照** | 80s synth-pop, 90s grunge, 2010s EDM, vintage soul, modern trap |
| **制作スタイル** | lo-fi, high-fidelity, live recording, studio-polished, bedroom pop |
| **ボーカル特性** | female vocal, male vocal, breathy, powerful, falsetto, raspy, choir |
| **速度/リズム** | slow tempo, mid-tempo, fast-paced, groovy, driving, laid-back |
| **構造ヒント** | building intro, catchy chorus, dramatic bridge, fade-out ending |

**いくつかの実用的な原則：**

1. **具体的は曖昧より優れている** — 「sad piano ballad with female breathy vocal」は「a sad song」より効果的です。

2. **複数の次元を組み合わせる** — 単一次元の記述はモデルに遊ぶ余地を与えすぎます。スタイル+感情+楽器+音色を組み合わせることで、希望する方向をより正確に固定できます。

3. **参照をうまく使用する** — 「in the style of 80s synthwave」または「reminiscent of Bon Iver」は、複雑な美的好みを迅速に伝えることができます。

4. **テクスチャ単語は有用** — warm、crisp、airy、punchyなどの形容詞は、ミキシングと音色の傾向に影響を与える可能性があります。

5. **完璧な記述を追求しない** — Captionは出発点であり、終点ではありません。まず一般的な方向を書き、結果に基づいて反復調整します。

6. **記述粒度が自由度を決定** — 省略された記述が多いほど、モデルの遊ぶ余地が大きくなり、ランダム要因の影響が大きくなります。詳細な記述が多いほど、モデルはより制約されます。ニーズに基づいて具体性を決定——驚きが欲しい場合は少なく書き、制御したい場合は詳細に書きます。

7. **衝突する単語を避ける** — 衝突するスタイルの組み合わせは、劣化した出力を引き起こしやすいです。たとえば、「クラシック弦楽」と「ハードコアメタル」を同時に要求する——モデルは融合を試みますが、通常は理想的ではありません。特に`thinking`モードが有効な場合、LMはDiTよりもキャプションの汎化性が弱いです。プロンプティングが不合理な場合、驚きが出る確率は低くなります。

   **衝突を解決する方法：**
   - **繰り返し強化** — 特定の単語を繰り返すことで、ミックススタイルでより欲しい要素を強化
   - **衝突を進化に変える** — スタイルの衝突を時間的なスタイルの進化に変換。たとえば：「始まりは柔らかい弦楽、中間は騒々しい動的なメタルロック、終わりはhip-hopに変わる」——これにより、モデルは異なるスタイルを混ぜるのではなく、それらを処理する方法について明確なガイダンスを得ます

> より多くのプロンプティングのヒントについては、[The Complete Guide to Mastering Suno](https://www.notion.so/The-Complete-Guide-to-Mastering-Suno-Advanced-Strategies-for-Professional-Music-Generation-2d6ae744ebdf8024be42f6645f884221)を参照してください——Sunoのチュートリアルですが、プロンプティングのアイデアは普遍的です。

---

#### Lyricsについて：時間的スクリプト

Captionが音楽の「全体的な肖像」——スタイル、雰囲気、音色——を記述する場合、**Lyricsは音楽の「時間的スクリプト」**であり、音楽が時間とともにどのように展開するかを制御します。

Lyricsは単なる歌詞内容ではありません。以下を含みます：
- 歌詞テキスト自体
- **構造タグ**（[Verse]、[Chorus]、[Bridge]...）
- **ボーカルスタイルのヒント**（[raspy vocal]、[whispered]...）
- **楽器セクション**（[guitar solo]、[drum break]...）
- **エネルギー変化**（[building energy]、[explosive drop]...）

**構造タグが重要**

構造タグ（Meta Tags）はLyricsで最も強力なツールです。モデルに「このセクションは何で、どのように実行すべきか」を伝えます。

**一般的な構造タグ：**

| カテゴリ | タグ | 説明 |
|----------|------|------|
| **基本構造** | `[Intro]` | オープニング、雰囲気を確立 |
| | `[Verse]` / `[Verse 1]` | 主歌、物語の進行 |
| | `[Pre-Chorus]` | プレコーラス、エネルギーを構築 |
| | `[Chorus]` | コーラス、感情のクライマックス |
| | `[Bridge]` | ブリッジ、転換または高揚 |
| | `[Outro]` | エンディング、結論 |
| **動的セクション** | `[Build]` | エネルギーが徐々に上昇 |
| | `[Drop]` | エレクトロニックミュージックのエネルギー解放 |
| | `[Breakdown]` | 楽器編成の削減、スペース |
| **楽器セクション** | `[Instrumental]` | 純粋なインストゥルメンタル、ボーカルなし |
| | `[Guitar Solo]` | ギターソロ |
| | `[Piano Interlude]` | ピアノ間奏 |
| **特殊タグ** | `[Fade Out]` | フェードアウトエンディング |
| | `[Silence]` | サイレンス |

**タグの組み合わせ：適度に使用**

構造タグは`-`で組み合わせて、より細かい制御が可能：

```
[Chorus - anthemic]
これはコーラスの歌詞
夢が燃えている

[Bridge - whispered]
そっとその言葉をささやく
```

これは`[Chorus]`だけを書くよりも効果的——モデルにこのセクションが何であるか（Chorus）と、どのように歌うか（anthemic）の両方を伝えます。

**⚠️ 注意：タグを積み重ねすぎないでください。**

```
❌ 推奨されない：
[Chorus - anthemic - stacked harmonies - high energy - powerful - epic]

✅ 推奨：
[Chorus - anthemic]
```

タグを積み重ねすぎると2つのリスクがあります：
1. モデルがタグの内容を歌詞として誤って歌う可能性がある
2. 指示が多すぎるとモデルが混乱し、効果が悪化する

**原則**：構造タグは簡潔に保ち、複雑なスタイル記述はCaptionに配置します。

**⚠️ 重要：CaptionとLyricsの一貫性を維持**

**モデルは衝突を解決するのが得意ではありません。** CaptionとLyricsの記述が矛盾する場合、モデルは混乱し、出力品質が低下します。

```
❌ 衝突例：
Caption: "violin solo, classical, intimate chamber music"
Lyrics: [Guitar Solo - electric - distorted]

✅ 一貫した例：
Caption: "violin solo, classical, intimate chamber music"
Lyrics: [Violin Solo - expressive]
```

**チェックリスト：**
- Captionの楽器 ↔ Lyricsの楽器セクションタグ
- Captionの感情 ↔ Lyricsのエネルギータグ
- Captionのボーカル記述 ↔ Lyricsのボーカル制御タグ

Captionを「全体的な設定」、Lyricsを「ショットスクリプト」と考えてください——それらは同じ物語を語るべきです。

**ボーカル制御タグ：**

| タグ | 効果 |
|------|------|
| `[raspy vocal]` | かすれた、テクスチャのあるボーカル |
| `[whispered]` | ささやき |
| `[falsetto]` | ファルセット |
| `[powerful belting]` | 力強い、高音の歌唱 |
| `[spoken word]` | ラップ/朗読 |
| `[harmonies]` | 層状のハーモニー |
| `[call and response]` | コールアンドレスポンス |
| `[ad-lib]` | 即興の装飾 |

**エネルギーと感情タグ：**

| タグ | 効果 |
|------|------|
| `[high energy]` | 高エネルギー、情熱的 |
| `[low energy]` | 低エネルギー、抑制的 |
| `[building energy]` | エネルギー増加 |
| `[explosive]` | 爆発的なエネルギー |
| `[melancholic]` | 憂鬱 |
| `[euphoric]` | 多幸感 |
| `[dreamy]` | 夢のような |
| `[aggressive]` | 攻撃的 |

**歌詞テキストの書き方のヒント**

**1. 音節数を制御**

**1行あたり6-10音節**が通常最適です。モデルは音節をビートに合わせます——1行が6音節で次の行が14音節の場合、リズムが奇妙になります。

```
❌ 悪い例：
我站在窗前看着外面的世界一切都在改变（18音節）
你好（2音節）

✅ 良い例：
我站在窗前（5音節）
看着外面世界（6音節）
一切都在改变（6音節）
```

**ヒント**：同じ位置の行（例：各節の最初の行）は類似の音節数を保ちます（±1-2の偏差）。

**2. 大文字小文字で強度を制御**

大文字はより強いボーカル強度を示します：

```
[Verse]
walking through the empty streets（通常の強度）

[Chorus]
WE ARE THE CHAMPIONS!（高強度、叫び）
```

**3. 括弧で背景ボーカルを表す**

```
[Chorus]
We rise together (together)
Into the light (into the light)
```

括弧内の内容は背景ボーカルまたはハーモニーとして処理されます。

**4. 母音を延長**

母音を繰り返すことで音を延長できます：

```
Feeeling so aliiive
```

ただし、慎重に使用してください——効果は不安定で、無視されたり誤って発音されたりする場合があります。

**5. セクションを明確に分離**

各セクションを空行で区切ります：

```
[Verse 1]
最初の節の歌詞
最初の節を続ける

[Chorus]
コーラスの歌詞
コーラスを続ける
```

**「AI風」の歌詞を避ける**

これらの特徴は歌詞を機械的で人間味のないものにします：

| 赤旗 🚩 | 説明 |
|---------|------|
| **形容詞の積み重ね** | 「neon skies, electric hearts, endless dreams」——セクションに曖昧なイメージを詰め込む |
| **韻の混乱** | 一貫性のない韻パターン、または強制的な韻による意味の断裂 |
| **セクション境界の曖昧さ** | 歌詞内容が構造タグを越え、Verseの内容がChorusに「流れる」 |
| **呼吸感がない** | 各行が長すぎて、一息で歌えない |
| **混合メタファー** | 最初の節が水のイメージを使用し、2番目が突然火になり、3番目が飛翔——リスナーは固定できない |

**メタファーの規律**：1曲につき1つのコアメタファーに固執し、その複数の側面を深く掘り下げます。たとえば、「水」をメタファーとして選択すると、愛が水のように障害を回避する方法、細かい雨でも洪水でもあり得る、相手の姿を反映できる、掴めないが存在する、を探索できます。1つのイメージ、複数の側面——これにより歌詞に結束力が生まれます。

**インストゥルメンタル音楽の書き方**

ボーカルなしの純粋なインストゥルメンタル音楽を生成する場合：

```
[Instrumental]
```

または、構造タグを使用してインストゥルメンタルの展開を記述：

```
[Intro - ambient]

[Main Theme - piano]

[Climax - powerful]

[Outro - fade out]
```

**完全な例**

Captionが次のとおりと仮定：`female vocal, piano ballad, emotional, intimate atmosphere, strings, building to powerful chorus`

```
[Intro - piano]

[Verse 1]
月光洒在窗台上
我听见你的呼吸
城市在远处沉睡
只有我们还醒着

[Pre-Chorus]
这一刻如此安静
却藏着汹涌的心

[Chorus - powerful]
让我们燃烧吧
像夜空中的烟火
短暂却绚烂
这就是我们的时刻

[Verse 2]
时间在指尖流过
我们抓不住什么
但至少此刻拥有
彼此眼中的火焰

[Bridge - whispered]
如果明天一切消散
至少我们曾经闪耀

[Final Chorus]
让我们燃烧吧
像夜空中的烟火
短暂却绚烂
THIS IS OUR MOMENT!

[Outro - fade out]
```

注意：この例では、Lyricsのタグ（piano、powerful、whispered）はCaptionの記述（piano ballad、building to powerful chorus、intimate）と一貫しており、衝突はありません。

---

#### 音楽メタデータについて：オプションの細かい制御

**ほとんどの場合、メタデータを手動で設定する必要はありません。**

`thinking`モードを有効にした場合（または`use_cot_metas`を有効にした場合）、LMはCaptionとLyricsに基づいて適切なBPM、キー、拍子記号などを自動的に推論します。これは通常十分です。

ただし、明確なアイデアがある場合は、手動で制御することもできます：

| パラメータ | 制御範囲 | 説明 |
|-----------|----------|------|
| `bpm` | 30–300 | テンポ。一般的な分布：遅い曲60–80、中速90–120、速い曲130–180 |
| `keyscale` | キー | 例：`C Major`、`Am`、`F# Minor`。全体的なピッチと感情の色に影響 |
| `timesignature` | 拍子記号 | `4/4`（最も一般的）、`3/4`（ワルツ）、`6/8`（スイング感） |
| `vocal_language` | 言語 | ボーカル言語。LMは通常歌詞から自動検出 |
| `duration` | 秒 | 目標時間。実際の生成はわずかに異なる場合があります |

**制御の境界を理解する**

これらのパラメータは**ガイダンス**であり、**正確なコマンド**ではありません：

- **BPM**：一般的な範囲（60–180）は良好に機能します。極端な値（30や280など）は訓練データが少なく、不安定な可能性があります
- **キー**：一般的なキー（C、G、D、Am、Em）は安定しています。まれなキーは無視されたりシフトされたりする可能性があります
- **拍子記号**：`4/4`が最も信頼性が高い。`3/4`、`6/8`は通常OK。複雑な拍子記号（`5/4`、`7/8`など）は高度で、スタイルによって効果が異なります
- **時間**：短い曲（30–60秒）と中程度の長さ（2–4分）は安定しています。非常に長い生成は繰り返しや構造の問題が発生する可能性があります

**モデルの「参照」アプローチ**

モデルは`bpm=120`を機械的に実行するのではなく、次のようにします：
1. `120 BPM`を**アンカーポイント**として使用
2. このアンカー付近の分布からサンプリング
3. 最終結果は118または122の可能性があり、正確に120ではない

それはミュージシャンに「約120のテンポ」と言うようなものです——彼らはこの範囲内で自然に演奏し、メトロノームに厳密に従うのではありません。

**手動設定が必要な場合**

| シナリオ | 提案 |
|----------|------|
| 日常生成 | 気にしない、LMに自動推論させる |
| 明確なテンポ要件 | `bpm`を手動設定 |
| 特定のスタイル（例：ワルツ） | `timesignature=3/4`を手動設定 |
| 他の素材と一致させる必要がある | `bpm`と`duration`を手動設定 |
| 特定のキーの色を追求 | `keyscale`を手動設定 |

**ヒント**：メタデータを手動で設定したが、生成結果が明らかに一致しない場合——Caption/Lyricsとの衝突を確認してください。たとえば、Captionに「slow ballad」と書いて`bpm=160`の場合、モデルは混乱します。

**推奨される実践**：Captionにテンポ、BPM、キーなどのメタデータ情報を書かないでください。これらは専用のメタデータパラメータ（`bpm`、`keyscale`、`timesignature`など）を通じて設定すべきであり、Captionで記述すべきではありません。Captionはスタイル、感情、楽器、音色などの音楽的特徴に焦点を当て、メタデータ情報は対応するパラメータに任せます。

---

#### オーディオ制御について：音で音を制御する

**テキストは次元削減された抽象化です。最良の制御は、やはりオーディオで制御することです。**

オーディオで生成を制御する方法は3つあり、それぞれ異なる制御範囲と用途があります：

---

##### 1. 参照オーディオ（Reference Audio）：グローバル音響特徴制御

参照オーディオ（`reference_audio`）は、生成音楽の**音響特徴**——音色、ミキシングスタイル、演奏スタイルなど——を制御するために使用されます。それは**時間次元情報を平均化**し、**グローバルに**作用します。

**参照オーディオは何を制御するか？**

参照オーディオは主に生成音楽の**音響特徴**を制御します：
- **音色テクスチャ**：ボーカル音色、楽器音色
- **ミキシングスタイル**：空間感、ダイナミックレンジ、周波数分布
- **演奏スタイル**：ボーカルテクニック、演奏テクニック、表現
- **全体的な雰囲気**：参照オーディオを通じて伝えられる「感覚」

**バックエンドは参照オーディオをどのように処理するか？**

参照オーディオを提供すると、システムは次の処理を実行します：

1. **オーディオ前処理**：
   - オーディオファイルを読み込み、**ステレオ48kHz**形式に統一標準化
   - サイレンスを検出し、オーディオが完全にサイレントの場合は無視
   - オーディオの長さが30秒未満の場合、少なくとも30秒まで繰り返して埋める
   - 前、中、後の3つの位置からそれぞれ10秒のセグメントをランダムに選択し、30秒の参照セグメントに連結

2. **エンコーディング変換**：
   - **VAE（変分オートエンコーダー）**の`tiled_encode`メソッドを使用して、オーディオを**潜在表現（latents）**にエンコード
   - これらのlatentsは音響特徴情報を含みますが、特定のメロディ、リズム、その他の構造情報を除去
   - エンコードされたlatentsは、DiTの生成プロセスに条件として入力され、**時間次元情報を平均化し、生成プロセス全体にグローバルに作用**

---

##### 2. ソースオーディオ（Source Audio）：セマンティック構造制御

ソースオーディオ（`src_audio`）は**Coverタスク**に使用され、**メロディ構造制御**を実行します。その原理は、入力したソースオーディオをセマンティックに構造化された情報に量子化することです。

**ソースオーディオは何を制御するか？**

ソースオーディオは**セマンティックに構造化された情報**に変換されます：
- **メロディ**：音符の方向とピッチ
- **リズム**：ビート、アクセント、グルーヴ
- **和音**：和声進行と変化
- **オーケストレーション**：楽器の配置と層
- **いくつかの音色**：部分的な音色情報

**それで何ができるか？**

1. **スタイルを制御**：ソースオーディオの構造を維持し、スタイルと詳細を変更
2. **スタイルを転送**：ソースオーディオの構造を異なるスタイルに適用
3. **Retake抽選**：類似の構造だが異なるバリアントを生成し、複数の生成を通じて異なる解釈を得る
4. **影響度を制御**：`audio_cover_strength`パラメータ（0.0–1.0）を通じてソースオーディオの影響強度を制御
   - 強度が高い：生成結果がソースオーディオの構造により厳密に従う
   - 強度が低い：生成結果により多くの自由な遊びの余地がある

**Coverの高度な使用法**

Coverを使用して**曲をリミックス**でき、CaptionとLyricsの変更をサポートします：

- **リミックス作成**：曲をソースオーディオとして入力し、CaptionとLyricsを変更して再解釈
  - スタイルを変更：異なるCaption記述を使用（例：popからrockに変更）
  - 歌詞を変更：新しいLyricsで歌詞を書き直し、元のメロディ構造を維持
  - 感情を変更：Captionを通じて全体的な雰囲気を調整（例：悲しいから楽しいに変更）

- **複雑な音楽構造を構築**：必要な構造影響度に基づいて、複雑なメロディ方向、層、グルーヴを構築
  - `audio_cover_strength`を通じて構造遵守度を細かく調整
  - CaptionとLyricsの変更を組み合わせ、コア構造を維持しながら新しい表現を作成
  - 複数のバージョンを生成でき、各バージョンは構造、スタイル、歌詞で異なる重点を持つ

---

##### 3. ソースオーディオコンテキストベースの制御：局所的な補完と変更

これは**Repaintタスク**で、ソースオーディオのコンテキストに基づいて補完または変更を実行します。

**Repaintの原理**

Repaintは**コンテキスト補完**の原理に基づいています：
- **始まり**、**中間局所**、**終わり**、または**任意の領域**を補完可能
- 操作範囲：**3秒から90秒**
- モデルはソースオーディオのコンテキスト情報を参照し、指定された間隔内で生成

**それで何ができるか？**

1. **局所的な変更**：指定された間隔の歌詞、構造、または内容を変更
2. **歌詞を変更**：メロディとオーケストレーションを維持し、歌詞内容のみを変更
3. **構造を変更**：指定された間隔で音楽構造を変更（例：VerseをChorusに変更）
4. **続きを書く**：コンテキストに基づいて始まりまたは終わりを続きを書く
5. **音色をクローン**：コンテキストに基づいてソースオーディオの音色特徴をクローン

**Repaintの高度な使用法**

Repaintを使用して、より複雑な創造的ニーズを実現できます：

- **無限時間生成**：
  - 複数のRepaint操作を通じて、オーディオを継続的に拡張し、無限時間生成を実現
  - 各継続は前のセグメントのコンテキストに基づき、自然な遷移と一貫性を維持
  - セグメントごとに生成でき、各セグメントは3–90秒、最終的に完全な作品に連結

- **インテリジェントオーディオステッチング**：
  - 2つのオーディオをインテリジェントに組織してステッチ
  - 最初のオーディオの終わりでRepaintを使用して続きを書き、遷移を自然に接続
  - または、2つのオーディオ間の接続部分をRepaintで変更し、スムーズな遷移を実現
  - モデルはコンテキストに基づいてリズム、和声、音色の接続を自動的に処理し、ステッチされたオーディオを完全な作品のように聞こえさせます

---

##### 4. Baseモデルの高度なオーディオ制御タスク

**Baseモデル**では、より高度なオーディオ制御タスクもサポートしています：

**Legoタスク**：既存のトラックに基づいてインテリジェントに新しいトラックを追加
- 既存のオーディオトラックを入力（例：ボーカル）
- モデルはインテリジェントに新しいトラックを追加（例：ドラム、ギター、ベースなど）
- 新しいトラックは元のトラックとリズムと和声で協調

**Completeタスク**：単一トラックに混合トラックを追加
- 単一トラックオーディオを入力（例：アカペラボーカル）
- モデルは完全な混合伴奏トラックを生成
- 生成された伴奏はボーカルとスタイル、リズム、和声で一致

**これらの高度なコンテキスト補完タスク**は、制御方法を大幅に拡張し、よりインテリジェントにインスピレーションと創造性を提供します。

---

これらのパラメータの組み合わせが、あなたが「欲しいもの」を決定します。後で入力制御の**原則**と**テクニック**を詳しく説明します。

### II. 推論ハイパーパラメータ：モデルはどのように生成するか？

これは「生成プロセス動作」に影響を与える部分——何が欲しいかは変えませんが、モデルがそれをどのように行うかを変えます。

**DiT（拡散モデル）ハイパーパラメータ：**

| パラメータ | 機能 | デフォルト | 調整アドバイス |
|-----------|------|-----------|---------------|
| `inference_steps` | 拡散ステップ | 8（turbo） | ステップが多いほど細かいが遅い。Turboは8、Baseは32–100を使用 |
| `guidance_scale` | CFG強度 | 7.0 | 高いほどプロンプト遵守度が高いが、過適合の可能性。Baseモデルのみ有効 |
| `use_adg` | 適応的デュアルガイダンス | False | 有効にすると、CFGを動的に調整、Baseモデルのみ |
| `cfg_interval_start/end` | CFG有効間隔 | 0.0–1.0 | どの段階でCFGを適用するかを制御 |
| `shift` | タイムステップオフセット | 1.0 | ノイズ除去軌跡を調整し、生成スタイルに影響 |
| `infer_method` | 推論方法 | "ode" | `ode`決定論的、`sde`ランダム性を導入 |
| `timesteps` | カスタムタイムステップ | None | 高度な使用法、ステップとshiftを上書き |
| `audio_cover_strength` | 参照オーディオ/コードの影響強度 | 1.0 | 0.0–1.0、高いほど参照に近く、低いほど自由度が高い |

**5Hz LM（言語モデル）ハイパーパラメータ：**

| パラメータ | 機能 | デフォルト | 調整アドバイス |
|-----------|------|-----------|---------------|
| `thinking` | CoT推論を有効化 | True | 有効にするとLMがメタデータとコードを推論 |
| `lm_temperature` | サンプリング温度 | 0.85 | 高いほどランダム/創造的、低いほど保守的/決定論的 |
| `lm_cfg_scale` | LM CFG強度 | 2.0 | 高いほど正のプロンプト遵守度が高い |
| `lm_top_k` | Top-Kサンプリング | 0 | 0は無効、候補単語数を制限 |
| `lm_top_p` | Top-Pサンプリング | 0.9 | 核サンプリング、累積確率を制限 |
| `lm_negative_prompt` | ネガティブプロンプト | "NO USER INPUT" | LMに何を生成しないかを伝える |
| `use_cot_metas` | CoTメタデータ推論 | True | LMにBPM、キーなどを自動推論させる |
| `use_cot_caption` | CoTキャプション書き換え | True | LMに記述を最適化させる |
| `use_cot_language` | CoT言語検出 | True | LMにボーカル言語を自動検出させる |
| `use_constrained_decoding` | 制約付きデコーディング | True | 正しい出力形式を保証 |

これらのパラメータの組み合わせが、モデルが「どのように行うか」を決定します。

**パラメータ調整について**

強調すべきは、**調整要因とランダム要因は時として同等の影響を持つ**ことです。パラメータを調整する場合、パラメータ自体の影響なのか、ランダム性による変化なのかを判断するのが難しい場合があります。

したがって、**調整時にランダム要因を固定することを推奨します**——固定された`seed`値を設定することで、各生成が同じ初期ノイズから開始されることを保証し、パラメータが生成オーディオに与える実際の影響を正確に感じることができます。そうしないと、パラメータ変更の効果がランダム性によってマスクされ、パラメータの役割を誤って判断する可能性があります。

### III. ランダム要因：不確実性の源

入力とハイパーパラメータが完全に同じでも、2つの生成が異なる結果を生む場合があります。これは次の理由によるものです：

**1. DiTの初期ノイズ**
- 拡散モデルはランダムノイズから開始し、徐々にノイズを除去
- `seed`パラメータがこの初期ノイズを制御
- 異なるseed → 異なる開始点 → 異なる終了点

**2. LMのサンプリングランダム性**
- `lm_temperature > 0`の場合、サンプリングプロセス自体にランダム性がある
- 同じプロンプトでも、各サンプリングは異なるトークンを選択する可能性がある

**3. `infer_method = "sde"`の場合の追加ノイズ**
- SDEメソッドはノイズ除去プロセス中に追加のランダム性を注入

---

#### ランダム要因の利点と欠点

ランダム性は両刃の剣です。

**ランダム性の利点：**
- **創造的空間を探索**：同じ入力が異なるバリアントを生成し、より多くの選択肢を提供
- **予期しない驚きを発見**：時としてランダム性が予期しない優れた結果をもたらす
- **繰り返しを避ける**：各生成が異なり、単一パターンのループに陥らない

**ランダム性の課題：**
- **結果が制御不能**：生成結果を正確に予測できず、複数回生成しても満足できない可能性がある
- **再現が困難**：入力が完全に同じでも、特定の良い結果を再現するのが困難
- **調整が困難**：パラメータを調整する場合、パラメータの影響なのかランダム性の変化なのかを判断するのが困難
- **スクリーニングコスト**：満足のいくものを見つけるために複数のバージョンを生成する必要があり、時間コストが増加

#### ランダム要因にどのような心構えで向き合うか？

**1. 不確実性を受け入れる**
- ランダム性はAI音楽生成の本質的な特徴であり、バグではなく機能です
- すべての生成が完璧であることを期待せず、ランダム性を探索ツールとして扱う

**2. 探索プロセスを受け入れる**
- 生成プロセスを「ガチャ」または「宝探し」として扱う——複数回試すと、常に驚きが見つかる
- 一度の成功にこだわるのではなく、予期しない良い結果を発見するプロセスを楽しむ

**3. 固定seedをうまく使用する**
- **パラメータの影響を理解したい**場合、`seed`を固定してランダム性の干渉を排除
- **創造的空間を探索したい**場合、`seed`をランダムに変化させる

**4. バッチ生成 + インテリジェントスクリーニング**
- 単一生成に依存せず、複数のバージョンをバッチ生成
- 自動スコアリングメカニズムを利用して初期スクリーニングを行い、効率を向上

#### 私たちのソリューション：大バッチ + 自動スコアリング

推論が非常に高速なため、GPU VRAMが十分であれば、**大バッチでランダム空間を探索**できます：

- **バッチ生成**：一度に複数のバージョンを生成（例：batch_size=2,4,8）、ランダム空間を迅速に探索
- **自動スコアリングメカニズム**：初期スクリーニングに役立つ自動スコアリングメカニズムを提供し、**test time scaling**を実行

**自動スコアリングメカニズム**

複数のスコアリングメトリクスを提供しており、その中で**私のお気に入りはDiT Lyrics Alignment Score**です：

- **DiT Lyrics Alignment Score**：このスコアは歌詞の正確性に暗黙的に影響します
  - 生成オーディオ内の歌詞とオーディオの整列度を評価
  - スコアが高いほど、歌詞がオーディオ内でより正確に配置され、歌唱と歌詞の一致度が良いことを意味
  - これは歌詞付きの音楽生成に特に重要で、歌詞の正確性が高いバージョンをスクリーニングするのに役立ちます

- **その他のスコアリングメトリクス**：他の品質評価メトリクスも含まれ、複数の次元から生成結果を評価できます

**推奨ワークフロー：**

1. **バッチ生成**：より大きな`batch_size`を設定（例：2、4、8）、一度に複数のバージョンを生成
2. **AutoGenを有効化**：自動生成機能を有効化し、システムがバックグラウンドで継続的に新しいバッチを生成
   - **AutoGenのメカニズム**：AutoGenは、現在のバッチ結果を表示している間に、バックグラウンドで同じパラメータ（ただしランダムseed）を使用して次のバッチを自動生成します
   - これにより、手動で生成ボタンをクリックすることなく、ランダム空間を継続的に探索できます
   - 各新しいバッチは新しいランダムseedを使用し、結果の多様性を保証
3. **自動スコアリング**：自動スコアリング機能を有効化し、システムが各バージョンを自動的にスコアリング
4. **初期スクリーニング**：DiT Lyrics Alignment Scoreなどのメトリクスに基づいて、スコアが高いバージョンをスクリーニング
5. **手動選択**：スクリーニングされたバージョンから、ニーズに最も合う最終バージョンを手動で選択

これにより、ランダム性を最大限に活用して創造的空間を探索しながら、自動化ツールを通じて効率を向上させ、大量の生成結果の中での盲目的な検索を避けることができます。AutoGenにより、「聞きながら生成」が可能になり、現在の結果を閲覧している間に、次のバッチがバックグラウンドで準備されています。

---

## 結語

このチュートリアルは現在、ACE-Step 1.5の核心概念と使用方法をカバーしています：

- **メンタルモデル**：人間中心の生成設計哲学を理解
- **モデルアーキテクチャ**：LMとDiTがどのように協力するかを理解
- **入力制御**：テキスト（Caption、Lyrics、メタデータ）とオーディオ（参照オーディオ、ソースオーディオ）の制御方法を習得
- **推論ハイパーパラメータ**：生成プロセスに影響を与えるパラメータを理解
- **ランダム要因**：ランダム性を利用して創造的空間を探索する方法を学び、大バッチ + AutoGen + 自動スコアリングを通じて効率を向上

これは始まりに過ぎません。あなたと共有したい内容はまだたくさんあります：

- より多くのPromptingテクニックと実践的なケース
- 異なるタスクタイプの詳細な使用ガイド
- 高度なテクニックと創造的なワークフロー
- よくある問題と解決策
- パフォーマンス最適化の提案

**このチュートリアルは継続的に更新および改善されます。** 使用中に質問や提案がある場合は、フィードバックを歓迎します。一緒にACE-Stepをあなたのポケットの中の創造的なパートナーにしましょう。

---

*続く...*