“1週間で消える番組”どう届ける？ 膨大過ぎる「TVerの視聴データ」を、「お薦め作品」にすぐ反映できるワケ

[平 行男，ITmedia]

　月間4470万ユーザーが利用する民放公式テレビ配信サービス「TVer」。常時、約1000番組を配信し、再生数は月間6.5億回に上る。ただし、見逃し配信は期限が限られ、1週間程度で視聴できなくなる作品も多い。配信期間が終われば、ユーザーと作品の接点は失われてしまう。

　限られた時間の中で、顧客と作品（商品）をいかに出会わせるか。ECをはじめ多くの事業に共通する課題だ。TVer（東京都港区）は、視聴データを生かした「ユーザーの好みに合う番組の推薦」によって、番組とユーザーを結び付けようとしている。

　しかし、その取り組みは一筋縄ではいかなかった。蓄積した視聴データはあまりに膨大な上、旧システムは機能ごとに分断されておりデータの連携も難しかった。番組の「推薦」「検索」を支えるデータ基盤を作り替える――工夫をこらしたTVerの挑戦は、どのような成果をもたらしたのか。

民放各局などが共同で運営するTVer（撮影：筆者、以下同。出所：TVerの講演資料）

本記事は、グーグル・クラウド・ジャパンが主催したイベント「Google Cloud Next Tokyo」（7月30〜31日開催）の講演セッションから「TVer 月間 4,460 万ユーザーの Spanner を使った視聴体験向上の取り組み」を取材したもの。

日々の視聴データが「数十億行規模」に膨張　旧システムが限界に

　TVerの小林正宗氏（サービスプロダクト本部バックエンド開発部 エンジニア）は「推薦と検索という2つの軸の質が、視聴機会を左右する」と述べる。探さなくても最適な作品が届く推薦と、探したときに確実に見つかる検索。実現したいことは3つある。

1. 類似するコンテンツ推薦：番組内容の近さを基にして推薦する
2. ユーザー行動ベース推薦：「この番組を見た人はこちらも」という具合に推薦する
3. 検索精度の改善と基盤の統合：既存の検索機能を作り替える

　ただし、従来のシステム構成には2つの課題があった。1つ目は「データ規模」だ。メインのデータベースは米Amazon Web Services（AWS）のクラウド上で稼働する「Amazon Aurora MySQL」を利用していた。しかし、日々の視聴行動から生まれるデータは数十億行の規模に膨らみ、書き込み先を1カ所に集約する構成では、処理量の増加に耐えられないという懸念があった。

　2つ目は「システム構成」である。コンテンツの検索は検索エンジン「OpenSearch」、推薦結果の保管は高速データベース「Redis」、ユーザーデータは「Amazon Aurora」というように、主要なシステムが3つに分散していた。これらを常に同期させ、障害に対処し、データの構造を1カ所でも変えたら3つ全てを直す必要がある。その運用コストは積み重なり、データの更新経路の把握や同期タイミングの制御も難しくなっていた。

既存構成の問題（出所：TVerの講演資料）

　推薦も検索も、同じデータを基に処理しているという。1つのデータベースに集約すれば、これらの課題はまとめて解消に向かう――そう考えたTVerが選んだのが、米Googleが「Google Cloud」で提供するデータベース「Spanner」だ。

　意味の近さで似た番組を探す「ベクトル検索」、ユーザーと番組のつながりをたどる「グラフ探索」、キーワードで探す「全文検索」という3つの探し方をSpannerだけで扱える。サーバを足せば、書き込み性能を拡張することも可能だ。

　一方、新データベースを選定する段階で、課題も認識していた。ランニングコストや移行作業にかかる負担の他、AWSとGoogle Cloudをまたぐ構成となることで、データのやりとりに遅延やコストが生じる。「それらを受け入れても、推薦や検索を1つのデータベースで、分散データベースの特性と併せて使える利点が上回ると判断した」と小林氏は語る。

TVerの小林正宗氏（撮影：筆者、以下同）

AWSとGoogle Cloudを連携　失敗できないデータ設計の解

　移行の流れはこうだ。Amazon Auroraに格納したデータの変更内容を、データ連携サービス「Datastream」でデータ分析基盤「BigQuery」に送り、データ変換処理が可能な「Dataform」でデータを加工して、Spannerへ書き出す。部品は多いが、いずれもGoogle Cloudの標準機能で、処理の指定はSQL（構造化問い合わせ言語）で済む。「専用のインフラや、データを運ぶ仕組みを別途管理する必要がなく、シンプルに保てている」と小林氏は説明する。

　類似コンテンツ推薦に使うデータも、番組のタイトルや説明文を「Gemini Enterprise Agent Platform」のモデルで変換し、前述の仕組み内で生成している。

　一方、スキーマ（データの持たせ方）の設計思想はAmazon Aurora時代から変える必要があった。Spannerはデータを自動で分割して複数のサーバに分散させるため、ユーザーIDやコンテンツIDなど「どのIDを軸にするのか」を誤ると特定のサーバに負荷が集中してしまう。TVerはユーザーIDなどを軸に据え直し、同時に読み込むことが多い視聴履歴を、近い場所へ配置した。

　厄介なのは、この設計を後から変えられない点だ。変更にはデータの全件移し替えが伴う。「設計初期の段階で、どこにどうアクセスが来るかを分析し、決めておく必要がある」と小林氏は述べる。

番組の推薦にかかる時間「120秒→164ミリ秒」に短縮できた工夫の数々

　新システム開発の難所は、ユーザー行動ベース推薦の性能だった。Aさんが見た作品を基に、同じ作品を見た別のユーザーを経由し、その人たちが見ている作品をAさんに推薦する。この探索を専用の問い合わせ言語で書くこと自体は容易だったが、応答が遅過ぎた。

　初期段階では、索引のない状態で全データをスキャンした。120秒経っても結果が出てこない状態だったという。1つの番組を見た人を洗い出すための索引を追加したところ推薦に成功したが、複数番組を条件にすると全データのスキャンに戻ってしまった。

　第2段階では、索引をユーザーデータと同じ場所に置いた。離れた場所にある索引を突き合わせずに済み、読み取る行数は11.4億行から340万行へと減少。それでも応答時間は19〜48秒かかっていた。好みが似ているユーザーを全員探す処理が残っており、高い即応性が求められる用途には使えない。

　第3段階のサンプリングでは、数十万人に上ることもある視聴傾向の似たユーザー全員を追わず、先頭の1000人の探索で打ち切ることにした。その結果、読み取る行数は2万3000行、応答時間は164ミリ秒まで下がった。推薦の精度も、全員を探した場合と比べて上位30件の顔ぶれはほぼ変わらない。

　索引の追加、配置の見直し、サンプリングの3段階をへたことで、応答速度の問題が解決し、数十億行規模の探索がようやくオンラインで使える水準に収まった。

　課題はまだある。次に現れた事象は、結果の偏りだ。好みが共通するユーザー数だけで作品をランキングにすると、人気のドラマやバラエティーが誰に対しても同じように並んでしまう。小林氏は「パーソナルな推薦になっていなかった」と振り返る。

　そこで順位付けを、単純な視聴人数から、好みの似たユーザーの間でどれだけ見られているかという指標に変更した。速度、精度、スコアリングの方式の3つがそろって初めて、パーソナルな推薦ができるようになった。

新データ基盤のおかげで「AIコンシェルジュ」リリース可能に

　運用面では課題も残る。一つは反映の遅れだ。新しい番組が登録されてから推薦結果に現れるまで数時間かかる。原因はAmazon AuroraからBigQuery、Spannerへとデータが渡る流れ全体にあり、配信期間の短いTVerには悩ましい問題だ。

　もう一つは索引の手入れだ。検証段階では、データが1件もない状態で索引を作ったために設定が最小のまま固定され、毎回全データを走査していた。データ量に見合う設定で作り直すと、CPU使用率は56％減り、探し漏れもほぼなかった。全件を探索した場合と比べて97％一致したという。ここから、データが増えるたびに手を入れる必要があると分かった。

　懸念していたコストは、移行済みの処理が限定的で単純比較はできないとしつつ、既存の3システム分と同等の規模に収まっているという。

　「推薦も検索も同じ鮮度のデータで動くようになり、整合性の管理も1つに収まった」と小林氏は総括する。現在、類似コンテンツ推薦はA／Bテスト段階にある。ベクトル検索の仕組みが整ったことで、対話形式で番組を探せる「AIコンシェルジュ」のベータ版をリリースできた。全文検索によるOpenSearchのリプレースも性能検証が進んでいる。

　データ量とシステム構成に起因する課題によって、多数の作品を抱えながらも生かしきれていなかったTVer。新システムによって諸課題を改善できた今、TVerの視聴体験は次の段階に入ろうとしている。

既存構成とSpanner統合後の比較（出所：TVerの講演資料）

視聴無料・LIVE配信：
AI時代の経営リスクが分かる「ITmedia Security Week 2026 夏」

---

• 開催日：8月31日（月）〜 9月7日（月）
• 形式：オンラインセミナー
• 参加費：無料

講演内容を詳しく見る