Amazon Polly - テキストを音声に変換すると、効果が非常に顕著です。
PollyはAmazonのクラウドプラットフォームの一つのサービスで、テキストを音声に変換する(text to speech)ことができます。テキストを音声に変換すること自体は珍しくなく、Google翻訳でも簡単に行えますが、Pollyはテキストに基づいてできる限り自然な音声を生成するため、言語学習者にとって大きな福音となります。その上、活用できる範囲も広く、例えば字幕を音声に変換したり、スクリプトやナレーション、ダイアログに利用したり、さらにはPollyを使ってPodcastを録音することも可能です。効果を試してみたい読者は、Amazon Pollyにアクセスしてください。
よく使われる言語のテスト
使用範囲に関しては、中国語、英語、日本語、韓国語をテストしたいと思います。ここに私がPollyで変換した音声サンプルをいくつか掲載します:
- 日本語
- 中国語(華語)
- 英語(米国)
- 英語(英国)
- 韓国語
英語については言うまでもなく、非常に多様な選択肢があり、米国と英国の発音に加え、さまざまな声を選ぶことができます。聴いていると非常に自然に聞こえ、注意していないと本物の人間の声だと思ってしまうほどです。中国語は少し不自然に聞こえ、台湾華語ではなく、普通話とも異なる印象です。日本語のサポートは私の想像を超えており、文が非常にスムーズに聞こえるだけでなく、英語が混ざる場合にはPollyがその英語を日本語の発音に変えてから読み上げます。例えば、「この件についてはbug ticket必要でしょうか?」(この問題に対してチケットは必要ですか?)とPollyが読むと:
声優のようにシーンに応じた豊かな音声変化を持つことはできませんが、私にとっては非常に実用的なツールです。
Pollyは2つのオプションを提供しています。一つは「ニューラル音声」で、できる限り自然で人間に近い声を生成します。もう一つは「スタンダード」で、こちらはすでにかなり自然な人声ですが、機械音であることは聞き取れます。現時点では一部の言語のみが「ニューラル音声」に対応しています。中国語、英語、日本語、韓国語の中では英語、日本語、韓国語が「ニューラル音声」をサポートしています。
PollyはSSML(Speech Synthesis Markup Language)1をサポートしており、特定の文に対してポーズを取ったり、シーンに応じて声のトーンを変えたりするためにマークアップを使用することができ、音声に臨場感を与えることができます。
料金
料金表は公式サイトを参照してください。100万文字あたり4ドル、ニューラル音声を使用する場合は16ドルです。製品自体が大量のテキストを音声に変換する必要がない限り、一般的に補助的に使用する場合は非常に安価な価格で、独立した開発者でも簡単に利用できます。
毎月、処理したテキストの文字数に応じて料金が発生します。Amazon Pollyのスタンダード音声の音声または音声マークリクエストは、1百万文字あたり4.00 USDで請求されます(無料プランを超えた場合)。Amazon Pollyのニューラル音声の音声または音声マークリクエストは、1百万文字あたり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 を出し、どれだけ review を残し、どれだけ ticket を解決したかを集計し、数字で上司に成果を示そうとした。上司はただ、評価は成果だけで決まるわけではないと言った。数年後になって僕はようやく理解した——測定が目標になった瞬間、それはもはや良い測定ではなくなるのだと。イギリスの窓税からハノイのネズミ懸賞金、そして今日の PR 数による開発者評価まで、仕組みはまったく同じである。
- 画像のストレージと変換を Cloudflare Images に任せる Web ページに画像を一枚置くのはフロントエンドで一番簡単なことだ。でもそれをちゃんとやる——リサイズし、各フォーマットを生成し、トラフィックにも耐える——となると、実はひとつの解決策まるごとになる。だから僕は結局、原画一枚だけ渡して全部 Cloudflare Images に任せた。
- Access Keyはもう使うな Access KeyはAWSで見落とされがちなセキュリティリスクだ。OIDCとIAM Roleを組み合わせれば、GitHub Actionsはsecretなしで安全にAWSリソースを操作できる
- データベースの主キー: AUTO_INCREMENT、UUID、UUIDv7 バックエンド開発では主キーをどうするかをよく決める必要がある。auto increment か UUID か、衝突はどうするか、UUIDv7 と created_at + index の性能差はどれくらいか。実際に 2000 万件のデータで検証し、設計判断までまとめる。