10月21日、エンタメ業界に特化したデータエンジニアリングのイベント「エンタメ業界のデータエンジニアリング最前線」(共催:データ横丁、マイナビ)が開催された。4回目となる今回は動画がテーマだ。「ABEMA」を展開するAbemaTVと、「DMM TV」を運営するDMM.comの2社が、自社の取り組みを紹介。司会進行は吉村武氏が務めた。

難易度が高い視聴データのモデリング

最初に登壇したのは、AbemaTV Development Headquarters/Data Enablingチームマネージャーを務める田中聡太郎氏だ。動画配信サービスにおける視聴データモデリングの実践について語った。

  • AbemaTV Development Headquarters/Data Enablingチームマネージャー 田中聡太郎氏

    AbemaTV Development Headquarters/Data Enablingチームマネージャー 田中聡太郎氏

来年10周年を迎えるABEMAは、サイバーエージェントグループの中核として位置付けられる事業だ。2022年のワールドカップ配信で大きな注目を集めたことも記憶に新しい。ABEMAの特徴の1つに、スマートフォンだけでなく、コネクテッドTVやゲーム機など多様なデバイスに対応している点がある。ユーザーの利便性は上がるものの、「対応デバイスが多いことは、物理的なログ実装において大きな課題になっている」と田中氏は話す。

動画の視聴には広告もあるが、今回のセッションでは本編コンテンツの視聴に限定して取り組みを紹介した。

視聴データのモデリングの難しさの例として、同氏はまずABEMAのプレイヤー画面を示した。

「この画面を視聴したことを計測するために、どんなログをとり、データモデルを設計すると良いでしょうか。59分あるコンテンツの14分36秒時点を見ているという状態を、どう計測すべきでしょうか」(田中氏)

動画視聴は連続的なイベントであり、さらにプレイヤーは多様な状態を持つ。バックグラウンド再生、ピクチャーインピクチャー、フルスクリーン、音量調整、画質変更など、状態の組み合わせは多数考えられる。ライブ番組のリアルタイム視聴と追っかけ再生でも、状態は異なる。視聴開始、視聴、一時停止、視聴完了、離脱などイベントも多数あることを加味すると、「さまざまな状態を考慮したモデル化が必要」だと田中氏は説明する。

CMCD(Common Media Client Data)などの配信品質計測の規格は存在するが、「どの番組がどれくらい見られているか、どんな番組をレコメンドすべきかといったプロダクト用途の視聴データモデリングに特化したものはない」と続けた。

連続する視聴の線分として捉えてモデリング

ではABEMAでは視聴データのモデリングにどのような要件を設けているのだろうか。田中氏はまず、モデリングの結果が広告在庫規模の計算やコンテンツプロバイダーへの報告に直結することから、「コンテンツ毎に日単位で視聴ユーザーと視聴時間が分かることを事業上の必須要件としている」と述べた。さらに、分析や活用にあたっての要件として、視聴形態、プレイヤー状態毎の視聴時間や利用率、連続視聴と一時停止の区別、どの部分がスキップされたのか、どこで視聴を止めたかといった項目も設定しているそうだ。

ABEMAでは、実際の視聴データをモデリングする際の論理モデルを「線分」として捉えている。これは、同じ状態で連続した視聴を線分として捉え、線分を計測するアプローチだ。状態が変化するたびに線分を切り替える設計とし、通常プレイヤーからピクチャーインピクチャーへの変更など、状態が変化するたびに新しいプロセスが生成されるイメージである。

ポイントは、クライアント側で管理する値に連続的なものやカウンター、状態が変化するものを極力入れないようにすることだ。線分の開始時刻(watch_start_at)や開始位置(watch_start_position)など、線分のスコープ内で静的に管理できる値を中心に設計している。その理由として田中氏は「クライアント実装を考えても管理がしやすく、バグの温床になりにくい」と説明した。

「過去にはコンテンツの尺以上の視聴時間を計測してしまうバグ可能性を内包した仕様になっており、異常なログが発生していたこともありました。この反省から、クライアントで状態管理を極力しない設計にしました。極力staticで離散的な値の逐次ロギングとそのログからの再現で集計を実現するようにしています」(田中氏)

視聴データから実際の指標を算出する際も、ログの欠損を前提とした設計が重要だ。時系列順に記録されたユーザーログから特定レコードが欠損した場合の影響を、さまざまな角度から検証し、指標定義の頑健性を確保している。

指標の定義と管理には、LookerとGeminiの組み合わせを採用。同氏は「生成AI活用時代において、指標やディメンションの自然言語的な意味情報と、データベースでクエリ可能な言語での定義を一緒に管理することが大切」と述べたうえで、講演の最後に改めて「視聴データのモデリングはおもしろい」と力を込め、セッションを締めくくった。

ディメンショナルモデリングで直感的な分析を実現

後半は、DMM.comからデータ基盤開発部 データエンジニアの坂洋平氏と、データ活用推進部 データエンジニアの釜井克典氏が、DMM TVの事業成長を支えるデータモデリングとデータ基盤をテーマに自社の取り組みを紹介した。

DMM TVは、アニメ約6300作品を中心に20万本以上のコンテンツを月額550円(税込)で提供する動画配信サービスだ。定額制に加え、都度課金、DMMプラットフォームの他のサービスへの送客という3つのビジネススキームを持つ。2022年12月にサービスを開始、わずか3年弱で累計登録者数400万人を突破している。この急成長を支えているのが、データモデリングとデータ基盤だ。

※2025年10月時点。 App Store、Google Playからの登録は月額650円(税込)

釜井氏によると、DMM.comのデータ部門は、データ基盤開発部、データ活用推進部、データ戦略部の3つで構成され、多くの事業を横断的に支えている。各部門が連携してデータの集約から分析、施策立案まで一気通貫で担う体制だ。

  • DMM.com データ活用推進部 データエンジニア 釜井克典氏

    DMM.com データ活用推進部 データエンジニア 釜井克典氏

データモデリングについて、釜井氏はまず、DMM TVの可視化戦略から説明した。同社では、BigQueryで構成するデータレイクとデータマート、Lookerという3層構造の基盤を構築している。そこからBIツールを通じて役員やデータアナリストなどさまざまなユーザーがデータを活用している。

「単なるデータの可視化にとどまらず、あらゆるデータをビジネス価値につなげることを目指しています」(釜井氏)

中でも、分析負荷の軽減と専門業務への集中、分析レポート作成の迅速化と精度向上などの役割を担うデータマートでは「ディメンショナルモデリング」という手法を採用して設計している。分析をシンプルかつ直感的なものにするために、視聴履歴や入会履歴といったファクトテーブルを中心に、コンテンツやプランといったディメンションテーブルを配置することで、直感的な分析を可能にしているという。

「以前は20個以上に分散していたコンテンツテーブルを1つに統合しました。複雑なデータをシンプルにすることで、直感的な分析が可能になっています」(釜井氏)

このデータマートでDMM TVが重視しているのが、「初回視聴」の概念だ。入会履歴と視聴履歴を組み合わせて初回視聴データマートを生成し、ユーザーが最初に視聴したコンテンツを分析することで、DMMグループの他事業へのクロスセル戦略に活用している。「DMM TVは単なる動画配信サービスではなく、DMMの多様なサービスへのゲートウェイとしての役割を担っている」と釜井氏は説明し、「他事業部貢献」という独自指標で他サービスでの収益やユーザー数を定量評価していると明かした。

可視化の要となるのがLookerだ。「LookML」という独自のモデリング言語により、ビジネス指標をコードベースで一元管理できるという特徴を活かすことで、「単なる可視化ツールでなくデータガバナンスプラットフォームとしての役割を実現している」(釜井氏)そうだ。これにより、セマンティックレイヤーとして、データの一貫性と信頼性を確保している。

今後は、AIによる動画の要約やシーン分析を導入し、ユーザーの潜在的な嗜好を把握した画像ベースのレコメンドを実現する計画だ。また、Lookerと生成AIの親和性の高さを活用し、自然言語でのデータアクセスや可視化も視野に入れている。

BigQueryとGoogle Cloudで構築する柔軟なデータ基盤

続いて坂氏がDMM TVのデータ基盤の技術的な側面を解説した。DMM TVのデータ基盤はBigQueryを中心にGoogle Cloudのサービスを組み合わせて構築しており、全社のデータを対象に集め、施策の分析からアプリケーション開発まで幅広く活用している。

  • DMM.com データ基盤開発部 データエンジニア 坂洋平氏

    DMM.com データ基盤開発部 データエンジニア 坂洋平氏

主要データベースはGoogle CloudのリレーショナルデータベースであるSpannerで、20のデータセット、140のテーブルをBigQueryに取り込んでいる。取り込み手法として、大容量データにはDataflowを、少量データにはFederated Queryを、と使い分けているという。

「Dataflowはマネージドサービスなので負荷に応じて自動スケールします。一方、Federated QueryはBigQueryのSQL1つで完結できるので、運用コストを抑えられるのです」(坂氏)

両手法とも、ジョブ実行時に独立したコンピューティングリソースを割り当てるSpannerのData Boostオプションを採用することで、本番環境に影響を与えずにデータ取り込みを実現しているそうだ。

利便性向上にあたっては、Google Cloudのメタデータ管理サービスであるDataplexのリネージを用いて、BigQueryテーブル間の関係追跡と可視化をしている。これにより、アナリストが新たに分析する際に類似したマートが存在しないかを確認できたり、上流のBigQueryのテーブルに障害が発生した際に影響の出る下流のテーブルを特定したりすることを可能にしている。

さらに上流テーブルの更新を検知して下流テーブルを即座に更新するイベント駆動型の仕組みを導入し、従来のスケジュール実行による待ち時間を解消した。「ユーザーにいち早く新しいデータを提供できるようになった」と坂氏はその成果を語った。

  • 司会進行の吉村武氏

    司会進行の吉村武氏