アルファベットを歌うことは、AI音声にとって最も簡単なことであるはずだ。A-B-C-D-E-F-G。地球上のあらゆる子供にとって馴染みのある、7つの独立した音。しかし、AI音楽生成を試したことがある人なら、現実はもっと厄介であることを知っているだろう。モデルにアルファベットを歌わせると、L、M、N、O、Pの文字が、しばしば一つのぼやけた音節に崩れ落ちてしまう。「Elemmennopee」は文字ではない。それは一つの「症状」なのだ。

これが「LMNOP問題」であり、その影響は童謡の枠をはるかに超えている。曜日、番号付きの指示、あらゆる種類の順序付きリストが、同じ弱点を露呈させる。最近、ある開発者が、AIパイプラインを通じて8つの楽曲を生成し、自動音声認識ツールである mlx-whisper を用いて出力を測定することで、この問題を検証した。主観的な聴取に頼るのではなく、文字起こしソフトウェアにAIが実際に歌った内容を正確に報告させたのだ。結果は明白だった。列挙（Enumeration）は、通常の言語では起こり得ない方法で、合成歌手を躓かせるのである。

なぜリストはAI音声を壊すのか

話し言葉には文脈がある。もし誰かが「I'm taking the dog to the park（犬を公園に連れて行くよ）」と口ごもって言い、「dog」という単語を聞き逃したとしても、文章の意味は通じる。周囲の単語が空白を埋めてくれるからだ。しかし、リストにはそのようなセーフティネットがない。各項目は独立している。もしモデルが「B」と「D」の違いを曖昧に発音しても、聞き手は部分的な意味を受け取ることはできない。ただのノイズとしてしか聞こえないのだ。

アルファベットの歌において、LMNOPの塊は最も顕著な失敗点である。音声モデルはそのシーケンスを5つの別々の文字としてではなく、単一の音素の塊（phonetic blob）として扱ってしまう。各音を固定するための文脈的な手がかりがないため、シンセサイザーは子音間の遷移を推測することになる。そして、たいていその推測は外れる。同じことが曜日や番号付きの手順でも起こる。モデルはシーケンスを急いで通り過ぎ、個々の項目を判別不能な泥状の音へと圧縮してしまうのだ。

被害の測定

これを客観的に研究するために、開発者は8つの楽曲を生成し、mlx-whisper を通して歌詞の正確性をスコア化した。パイプラインは単純だ。プロンプトを書き、オーディオを生成し、結果を文字起こしし、文字起こしされたテキストを意図した歌詞と比較する。

標準的な物語形式の歌詞では、出力はかなり忠実だった。単語は適切な位置に配置されていた。しかし、プロンプトにリスト、アルファベット、または列挙が含まれていると、mlx-whisper は支離滅裂な内容を返した。文字は消えたり、混ざり合ったりした。数字は認識不能な音節へと変わった。この実験により、リストを多用する歌詞は、散文（prose）よりも明らかに明瞭性が低いことが確認された。

役立つプロンプト・アーキテクチャ

ぐちゃぐちゃになったリストを修正するために、後処理に頼ることはできない。修正は、最初の音符が生成される前に行われなければならない。注意深く構築された最初のプロンプトによって、モデルに明瞭な発音を強制することができる。これらの調整にコストはかからないが、モデルの呼吸やポーズの仕方を変えることができる。

  • 長い連続を小さなグループに分割する。 A-B-C-D-E の代わりに、A-B-C-D と E-F-G のように構成する。グループ間のわずかなリセットにより、モデルは音を混ぜ合わせるのではなく、正しい子音に着地するチャンスを得られる。

  • 数字を綴る。 「30」の代わりに「thirty」を使用する。数字は抽象的な記号であり、モデルは時としてそれらを短く、無声音のノイズへと圧縮してしまう。英語の単語として記述することで、音素としての実体を与えることができる。

  • 文字の周囲に視覚的なスペースを挿入する。 「ABC」ではなく、「A - B - C」のようにハイフンやスペースを使って書く。視覚的な分離は、これらが単一のアクロニム（頭字語）や単語ではなく、独立した項目であることをモデルに伝える。

  • 音節数を固定する。 各行を6音節から10音節の間に収める。極端な変動は、モデルに短い行を急がせ、長い行を引き伸ばさせる原因となる。リストにはすでに精密さが求められている。リズムが不揃いだと、正確なデリバリーはほぼ不可能になる。

  • リストから "and" を取り除く。 自然な話し言葉では、"and" は接続詞として機能する。しかし、歌われるリストにおいて、"and" は柔らかな音節を加え、それが前の項目の鋭いエッジを飲み込んでしまうことがよくある。「Monday, Tuesday, Wednesday」の方が、「Monday, Tuesday, and Wednesday」よりも明快に区切れる。

再生成の罠

ここで、人間の直感が裏目に出る。通常の歌詞であれば、反復的なプロンプト（iterative prompting）によって結果は改善される。フレーズが変だと感じたら、言葉を微調整して再度生成する。次のバージョンはより良くなる。テストの結果、このアプローチは列挙を含まない曲には有効であることが示された。しかし、リストを含む曲の場合、プロンプトを書き直すと、出力はむしろ理解しにくくなったのである。

データは明白だった。リストを含まない曲はプロンプトの修正後に改善したが、列挙を含む曲は悪化したのだ。

原因はアコースティック・シード（acoustic seed）にあります。歌詞から楽曲を生成するモデルにおいて、プロンプトを変更することは、単に既存のオーディオを編集することではありません。生成の基盤全体を再構成してしまうのです。モデルはパフォーマンスをゼロから作り直します。物語的なテキストであれば、新しいダイスの目がよりクリアなテイクをもたらすかもしれません。しかし、リスト形式の場合、通常はよりひどい不明瞭さを招くことになります。ある文字のタイミングを修正できたとしても、次の試行ではモデルが「J」「K」「L」を潰してしまうかもしれません。元のテイクに欠陥があったとしても、修正によって別の音韻的な混乱が生じてしまうことがよくあります。

リストが多い歌詞のための、よりスマートなワークフロー

再生成は明瞭さを損なうリスクがあるため、プロセスを変える必要があります。完璧な書き直しを追い求めるのはやめましょう。代わりに、最初のプロンプトをキャスティング（配役決定）のように扱ってください。

異なるランダムシードを使用して、全く同じプロンプトから複数のバージョンを生成します。テキストには手を触れないでください。歌詞を固定したまま、モデルにパフォーマンスのバリエーションを出させます。あなたが行っているのは編集作業ではなく、オーディションなのです。

次に、すべての候補をスコアリングします。各バージョンを mlx-whisper や同様の文字起こしツールに通し、どのテイクが最も忠実にプロンプトに一致しているかを測定します。伴奏やボーカルのトーンが多少洗練されていなくても、歌詞の正確性に基づいて勝者を選んでください。リストが多いコンテンツでは、雰囲気よりも明瞭さが重要です。

最も重要なのは、修正を前倒しで行うことです。生成ボタンを押す前に、スペースのルール、音節の制限、グルーピングを適用してください。アルファベットの歌を普通の英語で書いて、後から修正しようとしてはいけません。リストが含まれる場合、モデルは事後的な修正に対して寛容ではありません。A