こんにちは。DX開発事業部の矢原です。

Google Cloud Next Tokyo 26 に参加してきました。
TBS テレビさんのセッション「ニュースからドラマまで TBS が Gemini と作る表現の限界を超えた AI 音声制作の裏側」を聞いてきました！

課題

放送局では音声に関する問題に制作者が日々頭を悩ませている、として現場の声が吹き出しで並べられていました。

  • 仮ナレ作るのが大変…
  • 深夜の数分のニュースのためにアナウンサーが出勤しないといけない…
  • アナウンサー、技術スタッフ、MA 室のブッキングが大変
  • YouTube の動画にナレーションを付与したいけど発注するにはコストが…
  • 急な差し替えに対応できない…
  • 外国語ができるナレーターがいない

これを コスト / 時間 / 外国語 の 3 つに束ねて課題設定していました。

音六AI ― 原稿からスグにナレーション生成

課題に対する答えが、内製開発された AI ナレーションシステム「音六（おとろく）AI」です。キャッチコピーは「原稿からスグにナレーション生成」。ロゴのキャラクターがかわいい。

構成としては Gemini と Google Text-to-Speech を組み合わせた形で、原稿の文脈理解や翻訳まわりを Gemini が、音声生成を Text-to-Speech が担っているように見えました。

技術面で紹介されていたのは次の 3 点です。

内容
音声尺制御 「間（拍）」を加味した自由自在な音声尺コントロール
アクセント制御・ユーザ辞書 1 文字単位でアクセントを修正でき、修正内容を辞書登録できる
高度な翻訳 原稿の文脈を理解して翻訳スタイルを提案し、自然な翻訳を実現

設計思想として掲げられていたのが「標準的な基盤技術を応用し、音声尺を自在に制御する、汎用性の高いプラットフォーム」。ここで音声制御に SSML（Speech Synthesis Markup Language）という標準仕様を採用しているのがポイントで、これによって同じプラットフォーム上で様々な音声モデルを差し替えて使えるようにしている、という説明でした。

独自形式で作り込まずに標準に寄せておいたおかげで、モデルが進化しても土台を作り直さなくて済む。地味ですが、2 年後 3 年後に効いてくる判断だと思います。

デモ画面がとにかく「現場の道具」だった

デモでは、実際の W 杯のニュース原稿を読み込ませた画面が出てきました。

原稿がブロック単位に分割され、それぞれに 00:00.000 形式のタイムコードが振られている。ブロックごとに話者（Haruka、Kaito、MinatoX といった声）を割り当てられて、話速とピッチはスライダーで調整。単語をクリックすると発音（ひらがな）とアクセント核をモーラ単位で編集するダイアログが開き、「全てのプロジェクトの単語に反映」というトグルまで付いています。

「日本代表」という単語のアクセントを ニ・ホン・ダイ・ヒョウ と一音ずつ上下させて調整する UI を見て、これは放送の現場で本当に使われているやつだな、と納得しました。汎用の読み上げツールにはまず付かない機能です。

「同じ局内でも重視するポイントが異なる」

個人的に一番刺さったのがこのスライドでした。

縦軸に「正確さ」、横軸に「表現力」を取った散布図に、報道とドラマの円が置かれています。報道は正確さ寄り、ドラマは表現力寄りで、両者は重なりつつもかなりズレている。そこに「同じ局内でも重視するポイントが異なる」「多様な音声モデルが必要」と添えられていました。

続くスライドでは、従来型（RNN 等）と Transformer 型の音声モデルを比較していました。

従来型（RNN 等） Transformer 型
音声の自然さ クリアだがやや一本調子 非常に自然、感情などの表現力が高い
システム制御性 安定 パラメータ操作可能な場合は安定
計算コスト 軽量 学習・推論ともに重い
特性 局所理解 文全体考慮（Attention）

新しい方が良い、で終わらせずに「安定感 vs 表現力」というトレードオフとして整理し、だからこそ複数モデルを差し替えられるプラットフォームが要る、という話に繋げています。

開発メンバーが AD として現場に入っていた

セッション中、さらっと話されていたのですが個人的に一番驚いたのがこのエピソードでした。

開発側のメンバーが、実際に AD（アシスタントディレクター）として番組制作の現場業務に入っていた、という話です。

ヒアリングをした、現場に見学に行った、というレベルではなく、業務そのものを自分でやる。仮ナレを録るのにどれだけ時間がかかるのか、深夜にブッキングが取れないとはどういう状況なのか、原稿がどのタイミングで差し替わるのか。それを聞いた話ではなく自分の手触りとして持っている人が作っているから、あのアクセント編集 UI が出てくるのだと思います。

要件定義の精度をどう上げるかという話は普段からよく議論しますが、突き詰めると「自分がその業務をやったことがあるか」に行き着くのかもしれません。真似するのは簡単ではないですが、少なくとも現場に半日入らせてもらう程度のことは、もっと積極的にやっていいはずだと思わされました。

現場に広げるまでのプロセス

セッションの後半、「02. 現場推進の裏側」がむしろ本題だったかもしれません。

時系列はこうです。

  • 2023年末：PoC 開始。コア技術と β 版の開発
  • 2024年：β 版リリース。TBS と JNN 全局へ現場プレ導入
  • 2025年：音六AI 本リリース
  • 2026年〜：新たな取り組み。順次アップデートと新機能開発

注目したいのは β 版の位置づけです。JNN 全局にプレ導入した段階で多種多様なフィードバックを収集し、それを本開発に反映する。しかもスライドには「当事者意識の醸成・AI 音声コミュニティ作成」と明記されていました。

フィードバックを集めるのが目的ではなく、フィードバックを出す過程で現場の人たちを「使わされる側」から「一緒に作る側」に変えている。結果として JNN 系列 23 局への導入が実現しています。全国の系列局にツールを行き渡らせるのが簡単なわけがないので、ここが一番の勝ち筋だったのだろうと思います。

導入して終わりではなく、本リリース後も新機能開発にフィードバックが返るループが図示されていたのも印象的でした。

基幹システムに溶かし込む

活用事例で紹介されていたのが、報道支援システム「JNN NEWS CLOUD」との連携です。

原稿機能で書かれた原稿情報がそのまま音六AI に渡り、音声化される。実際の画面では、OA 原稿の編集画面のツールバーに「音六」ボタンが置かれていて、そこを押すと原稿がブロック分割された状態で音六AI 側に流し込まれていました。

スライドの下部には「基幹システムとの連携を行い、業務負荷を抑えて音声生成まで実現」とあります。

ここは自分の仕事に引きつけて一番考えさせられた部分でした。どれだけ良いツールを作っても、既存の業務フローの外に置いた瞬間に「わざわざ開きに行くもの」になって使われなくなる。原稿を書く場所にボタンを一つ置く、というところまでやり切れるかどうかが、定着するかしないかの分かれ目なのだと思います。

展望はストリーミングと災害報道

最後に紹介された今後の展望が、ストリーミングへの対応でした。

災害報道や外国語副音声への発展を検討しており、ストリーミングシステムの設計を進めている。人員の少ない時間帯やシーズンでも、より早く、より正確に情報を届けられるようにしていく、と。震度速報のテロップが入った画面がスライドに出ていて、用途としての切実さが伝わってきました。

そのうえで「課題は情報のレビューとアクセント調整」と正直に書かれていたのが良かったです。リアルタイムで音声を出すとなると、誰がいつ内容を確認するのか、地名の読みをどう担保するのか。速報性と正確性が真正面からぶつかる領域なので、ここを課題として明示したまま公開の場で話すのは誠実だなと感じました。

聞き終えて

「AI で内製しました」という事例は最近たくさんありますが、このセッションが良かったのは、技術の話と組織の話が同じ比重で語られていたことです。

SSML を採用してモデルを差し替え可能にしたという技術的判断と、β 版でコミュニティを作って当事者を増やしたという組織的判断が、どちらも「多様な現場に届ける」という同じ目的に向いている。そしてその手前に、開発者が AD として現場に入るという泥臭い工程がある。プラットフォームを作るというのはそういうことなんだな、と腹落ちしました。

私自身、普段は Google Cloud を使った生成 AI のプロジェクトに関わっていて、お客様の現場にどう根付かせるかで悩む場面が多いです。基幹システムにボタンを一つ置く話も、フィードバックを通じて当事者意識を作る話も、そのまま持ち帰れる示唆でした。

参考リンク

KDDIアイレットでは Google Cloud を活用した生成 AI の導入支援を行っています。お気軽にご相談ください！