TTSクレジットを守り、音声を磨き上げる：コンテンツスコアリングとテキスト正規化

Webサイトにセルフサービス型のTTSを組み込もうとすると、ボイスやモデル、APIとはほとんど関係のない2つの問題に、いつの間にか直面します。1つ目は、生のテキストがスピーカーから流れたとき、思いどおりに聞こえることはめったにないということ。2つ目は、公開ページにTTSのエンドポイントを置いた瞬間から、見知らぬ誰かがそこにアクセスできてしまうということです。TTS2Goは、この両方に専用の2つの仕組みで対処します。音声合成の前にぎこちない入力を書き換えるテキスト正規化パイプラインと、本当にあなたのサイトにふさわしいリクエストだけを自動承認するAIコンテンツスコアリングのレイヤーです。この記事では、その両方について、なぜ存在するのか、そしてなぜ組み合わせることが重要なのかを解説します。

ブラウザ向けSDKは、自分がどのプロジェクトに属しているかを知る必要があり、その識別子はユーザーが調べられるコードの中にあります。ドメインの許可リストやレート制限で守りを固めることはできますが、識別子そのものは秘密ではありません。誰かがエンドポイントを見つければ、リクエストを送れてしまいます。そうしたリクエストが音声合成まで到達すれば、その一つひとつがプロバイダーのクレジットを消費しかねません。

まず思いつくのは、生成の前に人間が各リクエストを承認する仕組みです。それは正しい考え方で、実際にTTS2Goでも最初からそう動作します。ただし、この作業は担当チームが対応できるペースを上回って増えていきます。本格的なトラフィックが来る頃には、手動承認は常に仕事を中断させるフルタイムの業務になってしまいます。

品質の面では、よくあるパターンの読み方がTTSプロバイダーによって異なります。たとえば「2026-04-21」という日付は、あるエンジンでは "April twenty-first, twenty twenty-six"、別のエンジンでは "twenty twenty-six dash oh four dash twenty-one" と読み上げられるかもしれません。通貨、時刻、略語、大きな数字も、予測できない読まれ方をします。ライターはプロバイダーの内部をコントロールできませんし、プロバイダーはあなたのコンテンツのことを知りません。

TTS2Goのすべてのプロジェクトは、手動承認から始まります。SDKが生成リクエストを送ると、それはダッシュボードのキューに入ります。あなたがそれを確認して承認または却下し、承認されたリクエストだけがクレジットを消費します。これは安全なデフォルトであり、きちんと機能します。自分たちの声として発信するすべての音声にこだわるチームは、完全なコントロールを手にできます。

ただし、時間がかかります。トラフィックが十分に増えると、機械に任せられたらいいのにと思い始めるようなワークフローになってしまいます。

AIコンテンツスコアリングこそが、その「機械」です。プロジェクトごとに、簡単なコンテンツプロファイルを設定します。サイトの内容の説明、サイトの種類、言語、そしていくつかのサンプル文です。生成リクエストが届くと、TTS2Goはリクエストのテキストとプロファイルを言語モデルに送り、言語モデルは1から10までのスコアと短い理由を返します。

あなたはしきい値を選びます。しきい値以上のリクエストは自動承認され、音声合成に送られます。しきい値未満のリクエストは、サイトに合った方法に応じて、手動キューに回すことも、そのまま却下することもできます。スコアは二択ではありません。最低の「スパムまたは悪用」から、「ゆるく関連」「一致の可能性あり」「よく一致」、そして最高の「完全に一致」まで段階があります。コンテンツの構成に応じて、どこまで厳しく、あるいは緩くするかを決められます。

その結果、エンドポイントを見つけて無関係なテキストを生成しようとする見知らぬ人は低いスコアを受け、音声合成には到達しません。あなた自身のページからの正当なコンテンツは高いスコアを得て、あなたが介入しなくてもナレーションされます。あなたが確認するのは中間の範囲だけで、それも確認したいときだけで済みます。

スコアリングは、正規化後のテキストではなく元のテキストに対して行われます。スコアリングの目的は、最終的に音声がどう聞こえるかではなく、コンテンツが適切かどうかを判断することだからです。

コンテンツの生成が承認されたら、次の問題はそれがどう聞こえるかです。TTS2Goは、承認されたすべてのリクエストを、プロバイダーに届く前にルールベースの正規化パイプラインに通します。このパイプラインは、生のテキストのうちプロバイダーによって扱いがばらつく部分を書き換えます。整数と小数、日付と時刻、さまざまな形式の通貨、パーセンテージ、ローマ数字、そして "Dr."、"Mr."、"etc." といった一般的な略語です。

"The invoice of $1,234.56 is due on 2026-04-21" は "The invoice of one thousand two hundred thirty-four dollars and fifty-six cents is due on April twenty-first, twenty twenty-six." に変換されます。"Chapter IV has 5 sections" は "Chapter four has five sections." になります。すべての変換は決定論的で、それぞれに対応する単体テストがあり、実行時のコストはかかりません。すべてローカルで処理されるため、音声合成の経路に余計なAPI呼び出しは発生しないのです。

ルールベースにしたのは、AIのレイヤーをもうひとつ重ねるのではなく、意図的に選んだ結果です。ルールは予測可能です。再現でき、説明でき、差分を比較できます。ユーザーが何か妙な読み上げを耳にしたら、その原因を正確に突き止め、それを引き起こした特定のルールを修正できます。音声はいわばパフォーマンスであり、パフォーマンスには再現可能な台本が必要なのです。

2つの仕組みは、パイプラインの両端で働きます。スコアリングは、何が音声合成に到達するかを決めます。正規化は、それがどう聞こえるかを決めます。一方は予算を守り、もう一方は出力の品質を守ります。スコアリングを外せばクレジットが無防備になり、正規化を外せば音声の品質がばらつきます。この2つを組み合わせることで、TTSの組み込みは、コンテンツモデレーターと言語の専門家を必要とするプロジェクトから、SDKのコード1行で済むものへと変わります。

どちらの仕組みも、ダッシュボードのサイドバーからライブデモを試せます。「AIコンテンツスコアリング」ページでは、サンプルテキストを貼り付けると、任意のプロジェクトのコンテンツプロファイルに照らした正確なスコア、理由、自動承認の判定を確認できます。「音声フォーマット」ページには「試してみる」ボックスがあり、入力した内容の正規化後のテキストを、変換前と変換後の例と並べて表示します。どちらもレート制限付きでクレジットは消費せず、実際のリクエストが届いたときに本番環境で行われる処理をそのまま反映しています。

すでにTTS2Goのプロジェクトをお持ちなら、ダッシュボードを開いて両方を試してみてください。これから始める方は、プロジェクトを作成し、ページにReact SDKを組み込んで、最初のいくつかのリクエストを手動キューで受け止めてみましょう。パイプライン全体が端から端まで動く様子を確認できます。