Amazon Polly - テキスト音声変換のクオリティが驚くほど高い
Polly は Amazon のクラウドプラットフォームが提供するサービスの1つで、テキストを音声に変換(text to speech)できる。テキスト音声変換自体は珍しいものではなく、Google 翻訳でも簡単にできるが、Polly はテキストに応じて極めて自然な音声を生成できるため、語学学習者にとって大きな福音だ。それだけでなく応用範囲も非常に広く、字幕の音声化、台本、ナレーション、対話、さらには Polly で直接 Podcast を収録することすら不可能ではない。試してみたい読者は Amazon Polly から試すことができる。
よく使う言語でのテスト
僕の利用範囲から考えると、中国語、英語、日本語、韓国語をテストしてみたい。ここでは、僕が Polly で変換した音声サンプルをいくつか載せておく:
- 日本語
- 中国語(標準中国語)
- 英語(アメリカ英語)
- 英語(イギリス英語)
- 韓国語
英語は言うまでもなくサポートが非常に充実しており、アメリカ英語とイギリス英語を選べるだけでなく、様々な声質(ボイス)を組み合わせることができる。聞いていて極めて自然で、注意深く聞かないと本物の人間と勘違いしてしまうほどだ。中国語は少し不自然に聞こえ、台湾華語ではないようだが、普通話ともまた少し違った感じがする。日本語のサポート度合いは僕の想像を超えており、文章が非常に流暢に聞こえるだけでなく、英語が混ざっている場合、Polly は英語を日本語風の発音に変換してから読み上げてくれることさえある。例えば「この件についてはbug ticket必要でしょうか?」の場合、Polly は次のように読み上げる:
声優のようにシーンに応じた豊かな感情表現をつけることはできないが、僕にとってはすでに極めて実用的なツールだ。
Polly には2つの選択肢が用意されている。1つは「ニューラル音声」で、最も自然で人間に近い音声を可能な限り出力する。もう1つは「スタンダード」で、これでも十分に自然な人間の声に聞こえるが、まだ機械音声らしさが感じられる。現在「ニューラル音声」に対応しているのは一部の言語のみだ。中・英・日・韓の中では、英語、日本語、韓国語が「ニューラル音声」に対応している。
Polly は SSML(Speech Synthesis Markup Language)1 に対応しており、マークアップによって特定の文でポーズを入れたり、シーンに合わせて声のトーンを変更したりできるため、音声の臨場感をさらに高めることができる。
価格
価格表は公式サイトを参照してほしい。100万文字あたり4米ドル、ニューラル音声の場合は16米ドルだ。プロダクト自体に大量のテキスト読み上げ需要がある場合を除けば、一般的な補助用途であれば非常に安価な価格設定であり、個人開発者でも手軽に利用できる。
毎月処理したテキストの文字数に応じて課金される。Amazon Polly スタンダード音声の音声または音声マークのリクエストは、100 万文字あたり 4.00 USD で請求される (無料利用枠を超えた場合)。Amazon Polly ニューラル音声の音声または音声マークのリクエストは、100 万文字あたり 16.00 USD で請求される (無料利用枠を超えた場合)。
連携(Node.js の例)
Polly と連携するのは非常に簡単で、aws-sdk を使うだけで済む。以下はサンプルコードだ:
polly.synthesizeSpeech(
{
Text: "おはようございます",
TextType: "text",
VoiceId: "Takumi",
LanguageCode: "ja-JP",
OutputFormat: "mp3",
},
(err, data) => {
if (err) {
console.log(err);
}
fs.writeFileSync("./result.mp3", data.AudioStream);
}
);
polly.startSpeechSynthesisTask()
このように書くことで、変換後の音声が result.mp3 に保存される。
まとめ
Polly というサービスは使い勝手が良く、かつ安価で、様々なアプリケーションに組み込んでコンテンツの表現力を高めることができそうだ。僕の場合なら語学学習に使い、テキストを入力すればリアルタイムで本物に近い発音が聞けるので非常に重宝する。
中国語話者にとっては、音声自体は許容範囲内であるものの、やはり台湾人が聞き慣れたアクセントではないため抵抗感が生じやすいのが少し残念な点だ。今後、台湾ローカルのアクセントがサポートされることを期待したい。
Footnotes
関連記事
- 測定が目標になるとき:窓税からPull Request数まで かつて僕は小さなツールを自作し、四半期で自分がどれだけPRに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計して、上司にアウトプットを証明しようとしたことがある。上司は淡々と、評価はアウトプットだけで見るものではないと言った。数年後、僕はようやく理解した――測定が目標になるとき、それはもはや良い測定ではなくなるのだ。英国の窓税、ハノイのネズミ駆除の報奨金から、現代のPR数による開発者評価に至るまで、そのメカニズムはまったく同じだ。
- Cloudflare Images を画像ストレージ・変換ソリューションとして使う ウェブページに画像を1枚置くのはフロントエンドにとって最も簡単なことだが、リサイズや各種フォーマットの生成、さらにはトラフィックの負荷に耐えることまで完璧にやろうとすると、実際には一つの包括的なソリューションが必要になる。僕はその後、すべて Cloudflare Images に任せるようになり、オリジナル画像1枚だけを渡すようにしている。
- もう AWS Access Key を使うのはやめよう Access Key は AWS において見落とされがちなセキュリティリスクだ。OIDC と IAM Role を組み合わせることで、GitHub Actions にシークレットを一切保持させることなく、安全に AWS リソースを操作できるようにする。
- データベース主キー:AUTO_INCREMENT、UUID、そしてUUIDv7 バックエンド開発で度々直面する主キーの決定。auto incrementを使うべきか、それともUUIDか?衝突への懸念は?UUIDv7とcreated_at + インデックスの性能差はどれほどか?実際に2,000万件のデータで検証したベンチマークと設計上の意思決定を解説する。