NewsPicks AI 記事読み上げの開発:TTS モデルの選定

こんにちは、ソーシャル経済メディア「NewsPicks」のサーバーサイドエンジニアの池川 @takapiro_ikeike です。

クリスマスですね!

NewsPicks Advent Calendar 2025 の 最終日です。 qiita.com

昨日は nakamichi さんによる CDK for TerraformによるSnowflakeインフラ管理 でした!

今回のブログは、NewsPicks の「AI 記事読み上げ機能」の開発にまつわる概要と、そこでの TTS (Text-to-Speech) モデルの選定 に関するお話です。

AI 記事読み上げ機能とは

NewsPicks の AI 記事読み上げは、以下のような音声再生プレイヤーを通じて記事を聴くことができる機能です。

AI 記事読み上げプレイヤー。以下の記事を NewsPicks アプリで開くことで音声を聞くことが可能です。

newspicks.com

NewsPicks のオリジナル記事を対象としていますが、全ての記事で音声を生成するにはコストがかかるため、特定の時期以降に作られた記事や、任意に選んだ「よく読まれる記事」を中心に音声を生成・提供しています。

このプロジェクト自体は 2025 年の 3 月頃から始まりました。 最初は社内版としてリリースし、その後 TTS モデルをいくつか切り替えたり、不具合修正を行いながら、最終的に有料会員のユーザー様向けにリリースしました。

音声の TTS モデル切り替え以外にも、Web 側の音声再生プレイヤーの実装や、モバイルアプリ連携なども含んだプロジェクトでした。

本記事では、TTS モデルが AWS Polly から始まり、Azure TTS を検討し、最終的には Google Cloud TTS (Chirp 3) に落ち着いた経緯について、Good / More の観点で振り返ってみたいと思います。

開発初期:AWS Polly

aws.amazon.com docs.aws.amazon.com

最初の開発段階では、AWS Polly の音声モデルを採用しました。

採用の背景

NewsPicks の既存インフラの多くが AWS で実装されているため、AWS のサービスを利用することで実装上のメリットが大きく得られると考えたためです。

Good / More

Good

  • インフラとの親和性: 既存基盤に乗っかる形なので、開発・導入がスムーズでした。

  • 実装のしやすさ: 特に AWS Polly には長文を渡して音声合成を行う「Long Text API」(最大 10 万文字対応)があり、生成結果をそのまま指定の S3 バケットに Put してくれる機能がありました。NewsPicks の記事は数千文字程度なので、1 回の API 呼び出しで完結でき、初期検証には最適でした。

  • SSML 対応: SSML(Speech Synthesis Markup Language)は、テキストの読み上げ方を制御できるマークアップ言語です。読み仮名の指定やポーズの挿入などができ、読み間違いの修正がやりやすかったです。

More

  • 機械音声っぽさ: 実装のしやすさに対して、音声のクオリティ(自然さ)はそこまで相関せず、やはり「機械音声っぽい」印象が強かったです。Google の Chirp 3 と比較しても、どうしてもロボット感が否めませんでした。

  • チューニング不足: 当時は開発初期で、聞きやすい音声を作るための知見が不足していたこともあり、品質面で課題が残りました。

とりあえず初期実装を行い、社内リリースまで持っていくには十分な選択肢でした。

品質向上への挑戦:Azure TTS

azure.microsoft.com learn.microsoft.com

AWS Polly でのリリース後、特に「音声品質を良くしたい」という思いから Azure TTS への移行を模索し始めました。

採用の背景

当時(Google Chirp 3 が GA する前)、Azure TTS は他社と比較しても発音が良く、最も品質が高いと感じていました。NewsPicks では Azure を利用している箇所はほぼありませんでしたが、このために契約作業を進めました。

Good / More

Good

  • 音声品質: 当時の比較では一番流暢で、品質は間違いなく良かったです。

More

  • 契約と開発のタイムラグ: 新規契約周りに時間がかかってしまいました。

  • Long Text 非対応: 無料枠の検証環境では、AWS Polly で利用していたような長文音声合成処理が利用できず、開発が一部ストップしてしまいました。

そうこうしているうちに、後述する Google の Chirp 3 が登場したため、Azure 版は実装を進めていたものの、日の目を見ることはありませんでした。

最終決定:Google Cloud TTS "Chirp 3"

cloud.google.com docs.cloud.google.com

最終的に採用されたのが、Google の Chirp 3 モデルです。

採用の背景

2025 年 5 月頃に Chirp 3 が GA(一般提供開始)されました。触ってみたところ、Azure 以上に流暢な日本語表現が可能でした。 また、Azure との契約に時間がかかっていた背景もあり、すでに社内で利用実績のある Google Cloud (Vertex AI 等) を利用することで、契約フローをスキップできるメリットもありました。

Good / More

Good

  • 圧倒的な流暢さ: 日本語の発話品質が非常に高いです。

  • 導入のしやすさ: 既に使用している Google Cloud プロジェクトにサービスを追加するだけで済みました。

  • コストメリット: 毎月の無料枠があるほか、AWS や Azure の初期割引(最初の100万文字無料など)と比較しても、継続的なコストメリットが大きいです。なぜこれほど安いのか逆に不安になるレベルですが、恩恵を受けています。

More (と、その解決策)

  • SSML 未対応 (当時): 当時は Chirp 3 が SSML(音声合成マークアップ言語)に未対応でした。

    • 解決策: 読み仮名などは、音声モデルに渡すテキスト自体を直接文字列置換することで対応しました。
    • 補足: 当時は読み仮名の機能対応がない認識だったのですが、今はもしかしたら違うかもしれません。
  • 長文合成機能がない: AWS のような GA されたロングテキスト処理がありませんでした。

    • 解決策: 記事の日本語テキストを大量のチャンク(塊)に分割して生成し、最後に ffmpeg で音声を結合することで解消しました。

その他の開発・運用について

TTS モデルを使った音声合成処理の実装以外にも、以下のような開発を行いました。

Android 通知パネルの実装

iOS では記事ページでの音声再生時、OS デフォルトで通知パネル(ロック画面等の操作パネル)での再生・一時停止・10秒スキップが機能しましたが、Android では実装が必要でした。 私はサーバーサイドエンジニアですが、Android チームのリポジトリに PR を出し、通知パネル操作の実装を行いました。

辞書登録とチューニング

音声の読み間違いについて細かく辞書(Dictionary)を追加したり、合成エラーの原因調査・修正を日々行いました。

無料ユーザーへの体験提供

有料限定機能ですが、無料ユーザーの方にも体験してもらうため、サンプル音声を用意する導線を作ったりもしました。 サンプル音声自体を作る処理も用意しました。

開発スタイルと今後

このプロジェクトの特徴として、自分自身がコードをゼロから書くことはほとんどありませんでした。

  • 初期:GitHub Copilot、Gemini、ChatGPT にコードを出力してもらう

  • 6月以降:Claude Code に作業をほぼ丸投げ

基本的には平日の 1 日 1 時間程度、時期によっては全く作業しない日もありましたが、AI ツールを活用することで、サーバーサイドから Android 実装までを概ね 1 人作業で進めることができました。 この「AI エージェントを活用した開発」については、また次回以降の記事で触れられればと思います。

今後は、Podcast 形式でその日のニュース概要をお伝えする「デイリー・ブリーフィング」のような番組を参考に、オリジナル記事の解説として自動生成する機能開発などをやっていきたいと考えています。

newspicks.com

終わりに

読んでいただきありがとうございました。
良いお年をお迎えください!

Page top