【ITニュース解説】From screenplay to one multi-voice MP3: parsing scripts for a multi-speaker TTS API on Cloudflare Workers

このニュース記事は、ユーザーが入力した台本を元に、複数の話者が登場する会話形式の音声ファイル（MP3）を自動で生成するウェブアプリケーションの開発について詳しく解説している。システムエンジニアを目指す初心者にとって、実際の開発における課題解決の具体的なアプローチや技術的な工夫が数多く紹介されており、非常に実践的な内容だ。

従来の音声合成（Text-to-Speech: TTS）ツールは、通常、単一のテキストブロックに対して単一の声を割り当てるものが多かった。そのため、複数のキャラクターが会話するシーンの音声を作成するには、各キャラクターのセリフを個別に生成し、音声編集ソフトで手作業で配置や間隔の調整を行う必要があり、非常に手間がかかった。しかし、最近のTTSモデルは進化し、複数の話者が登場するシーン全体を一度のリクエストで生成できるようになってきた。この新しいモデルは、各話者に異なる声を割り当てたり、台本中に演技の指示を含めたりすることも可能だ。今回開発されたウェブアプリケーションは、このような高機能なTTSモデルを活用し、ユーザーが台本を貼り付けるだけで、登場人物ごとの声で再生される一つのMP3ファイルを生成・ダウンロードできるものとなっている。

このアプリの基盤技術には、主に「Cloudflare Worker」が使われている。これはJavaScriptで記述され、サーバー管理の必要がないサーバーレス環境でアプリケーションの機能を提供する。ユーザー情報や生成履歴を保存するデータベースには「D1」が、生成されたMP3ファイルを保存するオブジェクトストレージには「R2」がそれぞれ利用されている。音声合成の核となる部分は、外部サービスである「Fish Audio」が提供する「Drama 3」というTTSモデルで、HTTP通信を通じてこのモデルのAPIを呼び出している。

このアプリケーション開発で最も重要な工程の一つは、人間が自然に記述する台本の形式を、TTSモデルが正確に理解できる厳密なデータ形式に変換する「パース（解析）」の部分だ。ユーザーが自由に入力するテキストが、システムの内部で問題を引き起こさないようにする設計が求められる。

入力される台本は、ラジオドラマのスクリプトに似た、人間が書きやすいシンプルな形式を採用している。例えば、「キャラクター名: セリフ」のように記述し、演技の指示は「[ささやくような声で]」のように角括弧で囲む。特定の単語を強調したい場合は「<emphasis>強調したい単語</emphasis>」のようなタグを使用する。特に重要なルールとして、行頭にキャラクター名がない行は自動的に「ナレーター」のセリフとして扱われる。これは、ユーザーが台本の途中に状況説明などの普通の文章を挿入した場合でも、エラーで処理を中断するのではなく、何らかの音声を生成できるようにするための配慮だ。もし名前のない行をエラーとして弾いてしまうと、ユーザー体験が大きく損なわれるため、この設計は実用上非常に効果的である。

台本の解析部分では、「正規表現」というパターンマッチングの技術が活用されている。これにより、「キャラクター名: セリフ」の形式を識別し、話者の名前、セリフのテキスト、演技指示を効率的に抽出する。解析の際に工夫されているのは、「計画は単純だった: 夜明け前に出発だ」のような、普通の文章中にコロンが含まれる場合でも、それを誤ってキャラクター名と認識しないようにすることだ。具体的には、キャラクター名と認識される文字列の長さや、含まれる文字の種類に制限を設けている。仮に誤って解析されたとしても、音声生成の前に登場人物のリストがユーザーに表示されるため、ユーザーは費用をかけることなく間違いに気づき、修正できる。このように、「予測可能で目に見える」誤解析の方が、「賢いけれど予期せぬ」結果よりも良いという判断がされている。その他にも、「[長い沈黙]」のように演技指示のみの行も有効な入力として扱ったり、空行はスキップしたりするルールが設けられている。このアプリは、最大16人のキャラクターと6,000文字の台本に対応できる。

次に、ユーザーからの入力を安全に処理する仕組みが重要だ。TTSモデルは、話者を切り替えるために「<|speaker:0|>」のような特殊な制御タグを使用する。もしユーザーがこのタグに似た文字列を台本に入力できてしまうと、話者が意図せず切り替わったり、システムエラーを引き起こしたりする可能性がある。これを防ぐため、TTSモデルにデータを送信する前に、これらの制御タグに似た文字列はすべて除去される。これは、データベースへの不正な操作を防ぐためのSQLエスケープと同様の考え方で、ユーザーの入力はあくまでデータであり、システム内部で使われる区切り文字や制御タグはシステム側で管理するという原則に基づいている。ただし、演技指示の角括弧や強調のタグは、アプリの機能として意図的に残されている。

TTSモデルに送る最終的なデータ（ペイロード）の構築は、解析されたセリフの「ターン」（発言単位）と「キャラクター」の情報、そしてどのキャラクターにどの声が割り当てられるかの「音声マップ」を組み合わせて行われる。キャラクターの登場順に基づいて内部的なインデックスが割り振られ、そのインデックスと対応する音声IDが設定される。この処理により、TTSモデルが要求する「テキスト」と「参照IDのリスト」という形式のデータが生成される。この段階で、音声の長さやコストに関する検証を行うことで、無駄な処理を省くことができる。

ユーザーが各キャラクターの音声を手動で選択しなかった場合でも、アプリは自動的に音声を割り当てる「自動キャスティング」機能を提供する。これは、システムが事前に用意した16種類の音声の中から、重複しないように割り当てが行われるものだ。ナレーターには専用の音声が割り当てられ、残りのキャラクターには、まだ使われていない音声が順番に割り当てられる。これにより、ユーザーは声の選択に迷うことなく、すぐに音声生成を試すことができる。また、システムが許可していない音声IDは受け付けないため、不正なリクエストを防ぐこともできる。

外部のTTSモデルを呼び出す際には、いくつかの重要な注意点がある。特に、「model: 'drama-3'」というHTTPヘッダーをリクエストに含める必要があるが、このヘッダーが欠けていたり、スペルミスがあったりすると、多くのAPIはエラーを返すものだが、このTTSモデルはサイレントに（何もエラーを返さずに）別のデフォルトモデルで処理を実行してしまう。これは、テストでは成功したように見えても、実際には意図しないモデルが使われているという、発見しにくい問題を引き起こす可能性がある。そのため、開発者はこのヘッダーを明示的に指定し、なぜそれが重要なのかをコードにコメントとして残している。また、返ってきた音声データが1KB未満のような非常に小さい場合は、正常なMP3ファイルではない可能性が高いと判断し、エラーとして処理する。さらに、ユーザーの台本の内容やAPIキーのような機密情報は、システムのエラーログには決して記録しないというセキュリティ上の配慮も行われている。

音声合成サービスの料金は通常、入力されたテキストの文字数（またはバイト数）に応じて課金される。このアプリでは、TTSモデルに実際に送られる文字列のUTF-8バイト数を正確に計算し、それを基にコストを見積もる。日本語のような非ラテン文字は、ASCII文字よりもバイト数が多くなることがあるため、この計算方法はより正確な課金につながる。ユーザーに付与されるクレジットは音声の秒数でカウントされるが、実際に課金される際には「生成される音声の長さ」と「スクリプトのバイト数」のどちらか大きい方が適用される。生成が始まる前に、少し多めのクレジットを仮予約し、実際の生成が完了して正確な音声の長さが判明した後に、未使用分を返却する仕組みが採用されている。もし生成が失敗した場合は全額が返金される。クライアント（ウェブブラウザ）で表示される見積もりと、サーバー側での実際の課金計算が同じロジックで行われることが、ユーザーの信頼を得る上で非常に重要だ。また、生成されるMP3のビットレートを128 kbpsの固定（CBR: Constant Bitrate）に指定することで、音声ファイルのサイズから簡単に音声の秒数を計算できる。これにより、複雑な音声デコーダーを使う必要がなく、処理をシンプルに保つことができる。

このアプリでは、音声生成のすべての処理（入力の検証、クレジットの仮予約、TTSモデルの呼び出し、生成されたMP3の保存、決済）を、ユーザーからの1つのHTTPリクエスト内で完結させる「同期処理」を採用している。このアプローチの利点は、コードがシンプルになり、状態管理が不要で、すぐに結果をユーザーに返せることだ。しかし、長い台本の場合、処理時間が長くなり、HTTPリクエストのタイムアウトに引っかかる可能性がある。また、ユーザーが途中でウェブページを閉じると、Workerの処理がキャンセルされてしまう可能性もある。しかし、このアプリでは台本の文字数に6,000字という制限を設けているため、現時点では同期処理でも十分対応可能だと判断されている。もし将来的に、より長い台本に対応する必要が出てきた場合は、非同期キューを使ってバックグラウンドで処理を実行し、結果を後で通知する方式に切り替えることも検討されている。

開発の過程で発見された特殊な問題として、ウェブページに埋め込んだサンプルMP3ファイルが、iOS版Safariでは再生できないという事象があった。これは、iOS版Safariが音声ファイルの再生時に、HTTPの「Range」リクエストに対して「206 Partial Content」というステータスコードのレスポンスを期待するのに対し、通常のCloudflare Workersの静的ファイル配信は「200 OK」で応答していたためだ。この問題を解決するために、/samples/*.mp3 というパスに対するリクエストでは、Rangeヘッダーを解析し、ファイルの指定された部分だけを返し、ステータスコードを「206 Partial Content」に設定する特別な処理を実装した。これは、「デスクトップでは動くのにiPhoneでは動かない」というような問題に遭遇した場合、まずHTTPステータスコードを確認することの重要性を示している。

このプロジェクトは、単に技術要素を組み合わせるだけでなく、実際のユーザー体験、システムの安全性、コスト効率、そして予期せぬ技術的な課題への対応といった、システムエンジニアリングの多くの側面を学ぶ良い実践例であると言える。