この記事は Zenn からの転載です。
AI音楽生成で「A, B, C, D…」や「January, February, March…」のような列挙型の歌詞を書くと、他の文と同じ品質のプロンプトを書いたはずなのに発音が崩れて聞き取れなくなることがある。作曲コミュニティでは俗に**「LMNOP問題」**と呼ばれる現象で、アルファベットソングの"L-M-N-O-P"のあたりが早口言葉のように潰れて聞こえることに由来する。
この記事では、実際にAI作曲パイプライン（ACE-Step 1.5・完全ローカル）で8曲を生成し、mlx-whisperで歌詞一致率を実測したログをもとに、①LMNOP問題の原理と対策、②対策を打った上でも何が起きたか、③さらに踏み込んで「プロンプトを修正して再生成する」という一見正しい対応が、列挙型歌詞に限って逆効果になったという実測を示す。
LMNOP問題とは何か
列挙（アルファベット・数字・曜日・月名など）は歌詞の中でも特殊な構造をしている。ふつうの文なら多少発音が揺れても文脈で補完できるが、"B"と"D"、"M"と"N"のような単音節の記号列には補完の効く文脈がない。等間隔でリズムに乗せると隣接音が潰れ、リスナー（および音声認識）にとって区別がつかなくなる。
社内の音楽生成プロジェクトで蓄積した設計原則には、この対策として次が明文化されている。
- 列挙系は各項目を等間隔にせず、グルーピングを変える（例:
ABCD / EFG / HIJK / LMN / OPQ / RST / UVW / XYZ） - 数字は英単語で書く（
"30"ではなく"thirty"） - 文字は
A - B - Cのようにハイフンで区切って表記する - 1行4〜8語・6〜10音節とし、並行する行の音節数を±1〜2に揃える
- 列挙に
"and"を挟まない
実物で見る対策 — 使ったプロンプトと歌詞
アルファベットを扱う楽曲で実際に使ったcaption（ACE-Step用プロンプト）と歌詞は次の通り。設計原則をそのまま適用し、LMNOP問題を避けるためにグルーピングを変えてある。
caption: children's song, cheerful, playful, simple melody, ukulele,
glockenspiel, acoustic guitar, clear female vocals, warm, sing-along
duration: 100s / BPM 100 / C major
[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
教科書通りの対策を打った、一見「正しい」プロンプトである。
実測 — 対策済みのはずが、なぜ数値が乱れたか
生成した8曲をmlx-whisper（large-v3-turbo・完全ローカル）で文字起こしし、実使用歌詞との一致率を測った。各曲は同一プロンプトでseed違い2〜4テイクを生成しているため、同じ曲・同じプロンプトでもテイクごとの一致率にはばらつきが出る。
| 曲 | 一致率のテイク間レンジ (max-min, pp) | 備考 |
|---|---|---|
| 01 ABC Song | 58.6 | 列挙型 |
| 02 Numbers Song | 12.2 | 列挙型 |
| 05 Days & Months | 27.7 | 列挙型 |
| 04 Weather | 7.3 | 非列挙型 |
| 06 What Time Is It | 28.8 | 非列挙型 |
| 07 Seasons | 75.2 | 非列挙型（v1bで生成グリッチあり） |
| 08 Introduce Yourself | 41.0 | 非列挙型 |
正直に書くと、レンジが最大なのは非列挙型の07 Seasons（75.2pp）である。ただしこの曲のv1b（0.0%）は採点記録上「Whisperが"Thank you"を幻聴し続ける不良テイク」、01 ABC Songのv1b（16.7%）も「コーラスがループ崩れ（不良テイク）」と明記されている。つまり生成エンジン側のグリッチとテイクごとのばらつきが混ざっており、レンジの大きさだけでは「列挙型だから崩れた」とは言い切れない。
本題 — プロンプト修正は列挙型歌詞にだけ逆効果だった
生成グリッチの影響を切り分けるために、不良テイクを含む「レンジ」ではなく、各曲のベストテイク（そのプロンプトで出せた最良の一致率）だけを見る。8曲中7曲は、独立採点官のルーブリック指摘（英語の不自然さ・音節超過・演出不足など）を反映してプロンプトと歌詞を修正した「v2」を再生成している。v1のベストテイクとv2のベストテイクを比較すると、次のようになった。
プロンプト修正(v2)前後でベストテイクの一致率がどう変化したか。列挙型（青）は3曲中2曲が悪化、非列挙型（橙）は4曲中3曲が改善した。
- 列挙型3曲（ABC / Numbers / Days&Months）のv1→v2デルタ平均: -10.43pp
- 非列挙型4曲（Weather / What Time / Seasons / Introduce、v2再生成した4曲）のデルタ平均: +1.25pp
ルーブリック採点官の指摘は「歌いやすさ」「教育効果」などの観点で妥当なものだった（例: 01 ABCへのTPR動作語追加、02 Numbersの"and"混入除去）。歌詞・構成としては改善しているはずなのに、列挙型だけ聞き取りやすさが下がる方向に動いた。本記事執筆時点(2026年7月)のACE-Step 1.5はlyrics-to-song型のモデルで、プロンプト全体（caption・構成タグ含む）を一括で音響に落とし込むため、歌詞の一部だけを直しても生成全体の音響的な実現（発音の安定性）が別のseedを引いたのと同じくらい変わってしまう。列挙型の短い記号列はもともと文脈補完が効かず発音揺れの影響を直接受けるため、この「seedの揺れ」がそのまま聞き取り不能に直結しやすいという仮説が立てられる。
この記事のデータは列挙型n=3・非列挙型n=4という単一バッチの内輪データであり、統計的に有意とまでは言えない。ただし社内の採点記録自身も同じバッチから「歌詞修正(v2)とseed運は独立——v2で歌詞が良くなっても明瞭度が落ちる場合があるため、旧版を捨てず曲ごとに最良テイクを採用するのが正解」という教訓を残しており、今回のデルタ計算はこの教訓と整合する結果になった。
再現できる学び
- 列挙型歌詞（アルファベット・数字・曜日・月名）を含む曲は、プロンプトを直して1本作り直すより、同一プロンプトでseed違いの複数テイクを取ってから採点し、最良テイクを選ぶ方を優先する。 今回のデータでは、指摘反映のための書き直しが逆効果になる確率の方が高かった。
- 設計段階では、LMNOP対策（グルーピング変更・数字の英単語化・
A - B - C区切り・音節数±1〜2）を最初のプロンプトに入れておく。事後修正より効く。 - 一致率だけで判断せず、生成グリッチ（幻聴・ループ崩れ）と歌詞構造由来の揺れは分けて記録する。今回のように「レンジが大きい=歌詞が悪い」と早合点すると、07 Seasonsのような不良テイクを誤って設計原則の証拠にしてしまう。
mlx-whisperによる一致率採点の具体的な手順（uvxでのarm64ビルドの罠込み）は、既出記事「ローカルAI作曲の品質を数値で測る — mlx-whisperで歌詞一致率を採点するQAパイプラインを作った実録」で解説している。本記事では設計原則と再生成の効果測定に絞った。