IBC 2025 動画技術関連レポート / IBC 2025 Report

Transcript

1. IBC2025 動画技術関連レポート 株式会社 AbemaTV 五藤 佑典 | 福永 亘 | 山村 英貴
2. アジェンダ • Ice Break • グローバル／ヨーロッパの動画技術ト レンド俯瞰 • 欧州を中心とした標準規格に学ぶ動 画技術進化の行方 • 変わりゆくメディア業界の事業戦略ト レンド • AI 進化によって変わる技術領域 • 進化するスポーツコンテンツ最前線 • より安定／安全に熱狂を届けるライブ 動画配信を実現する技術 • エンターテイメントエコシステムを作る 広告戦略と技術 • メディアとエンターテインメントを大きく 変えるデータ技術の潮流 • 標準規格化する新しい表現技術
3. 五藤 佑典 YUSUKE GOTO https://ygoto3.com/ @ygoto3_ • California State University, San Bernardino グラフィックデザイン専攻 • CyberAgent Developer Expert @（株）サイバーエージェント • Director of Device Engineering @（株）AbemaTV Career History 1. Graphic / Web Designer 2. Marketer 3. Web Engineer 4. Video Engineer 5. Technical Product Manager
4. in Video Technology and Product Design
5. 福永 亘 WATARU FUKUNAGA 株式会社AbemaTV ビジネスディベロップメント本部 開発局 局長 @wataru420 2011 年、株式会社サイバーエージェントに⼊社。 2017 年9 ⽉よりビジネスディベロップメント本部にて、広告配信 サーバーの開発などを担当。「ABEMA」のマネタイズを、主に広告 技術領域から⽴案‧遂⾏。現在はOTTメディアにおける新しい視聴 体験‧広告体験の創出をテーマに開発を⾏っている。
6. 山村 英貴 HIDEKI YAMAMURA https://hidekiy.com/ @hidekiy • 京都大学工学部電気電子工学科 • サーバーサイドエンジニア（ 2013年4月〜） @ 株式会社サイバーエージェント • データエンジニア（2019年7月〜） @ 株式会社AbemaTV Career History 1. Server Side Engineer (Java, Go) 2. Data Engineer (AWS, Google Cloud)
7. Ice Break
8. IBC とは
9. IBC とは IBC - International Broadcasting Convention • 欧州最大の放送関連イベント • IBC 2025 は 9/12 - 9/15 にかけて開催 • オランダ・アムステルダム RAI で開催 来場者数 / 国 出展社数 IBC 2025 43,858 / 170カ国 1,300 IBC 2024 45,085 / 170カ国 1,350 NAB Show 2025 55,000 / 163カ国 1,100 Inter BEE 2024 33,853 / 36カ国 1,058 規模：昨年対比／類似イベント対比 https://www.instagram.com/p/DPT3y2sjCn1/
10. Motivation AbemaTV を始めとするサイバーエージェントの動画事業を技術的に前進させる • 業界トレンドの定点観測 • 欧州を中心とする技術標準化の動向キャッチアップ • 複数の海外パートナー会社との一挙ミーティング • 業界先端企業の将来への見解や実践例などの情報収集 • 汎用ソリューションの進化状況の確認 • 以前に目をつけていた技術の進化状況の確認
11. グローバル／ヨーロッパの 動画技術トレンド俯瞰
12. メディア企業が 直面する矛盾的状況 先が見えない市場の中で メディア技術への投資予算を絞りながらも イノベーションの必要性に迫られている
13. テレビ視聴における不動となった OTT の存在感 YouTube CTV シェアをリード • 2025 年 2 月から 6 ヶ月連続で米国の テレビで 1 番視聴さ れているサービスに
14. グローバルの広告消費量トレンド CTV 広告費は大幅な成長が見込まれる • グローバルの CTV 広告消費量 成長率年平均 14% で 2029 年まで推移する予想
15. 技術投資トレンド • AI と機械学習への投資は 圧倒的に高い優先度 • IP 伝送が投資量の 増加率で AI ／機械学習に次ぐ
16. 技術投資トレンド 四半期ごとに見ると AI と機械学習に対する投資を 優先する加速度も圧倒的に高 いことが分かる
17. 継続する Software-Defined への移行 Software-Defined なメディア制作が 増加している傾向が分かる • ソフトウェアによるソリューションの 売上がハードウェアのそれを超えて いる
18. サステナビリティに対する意識 メディアテック業界においても、サステナビリティは近年のキーワード だが、メディア業界の国際コミュニティ DPP の調査によると、 欧州と米国の間では その意識に差が表れている 欧州のほぼ全放送局がサステナビ リティの優先度を並以上と捉えてい るのに対して、米国は 3/4 程度は 優先度を追いていない
19. サステナビリティに対する意識 先が見えない市場状況において他の懸念事項に押され グローバルでサステナビリティの優先度はダウントレンド ダウントレンドの中でも優先度の維持を努める意識に 欧州と米国間の差がある
20. 欧州を中心とした標準規格に学ぶ 動画技術進化の行方
21. 『DVB』が描くハイブリッド配信の次のユビキタス DVB とは • DVB = Digital Video Broadcasting • 国際的標準規格のデジタルテレビジョン放送方式の一つ • 主に、ヨーロッパ諸国、オーストラリア、南アフリカ共和国で標準的に採用 • DVB-NIP（NativeIP）など放送とブロードバンド配信を同等に扱おうとする規格 の 策定などが特徴
22. 『DVB』が描くハイブリッド配信の次のユビキタス DVB とは • DVB = Digital Video Broadcasting • 国際的標準規格のデジタルテレビジョン放送方式の一つ • 主に、ヨーロッパ諸国、オーストラリア、南アフリカ共和国で標準的に採用 • DVB-NIP（NativeIP）など放送とブロードバンド配信を同等に扱おうとする規格 の 策定などが特徴 放送とのハイブリッド配信における技術適用のノウハウを学ぶ
23. DVB の次の目標： 5G マルチキャスト／ブロードキャストとの融合 • 5G がカバーする地上ネットワークを NTN（非地上系ネットワーク）もカバーする DVB-NIP で拡張 • いつでもどこでも高品質でインタラクティブなマルチキャスト・ブロードキャス トサービスを受信可能に 『DVB』が描くハイブリッド配信の次のユビキタス
24. 『DVB』が描くハイブリッド配信の次のユビキタス DVB-NIP + 5G-TN/NTN マルチキャスト／ブ ロードキャスト • 将来的に 5G 通信ではアプリケーション層 以上で DVB-NIP プロトコルを再利用 • コンテンツ情報の規格は両者の流通経路 で共通化できるものを定義 地上系通信と衛星通信（ 5G-NTN）で流通経路を補完し合う
25. 『DVB』が描くハイブリッド配信の次のユビキタス ユビキタス性に重要な DVB の コンポーネント • DVB-I ◦ 地上波番組もインターネットコンテ ンツも一緒にリスト • DVB-NIP ◦ 物理的インフラに依存しない伝送 • DVB-HB ◦ インホーム・ネットワークデバイスか らのアクセス拡張
26. 5G ブロードキャストの現状 イタリア放送協会「RAI」による調査 • 歩行／運転時の 5G での メディア視聴はまだ不安定 ◦ スマートフォンの種類や 視聴時の向きで 視聴の安定性が大きく異なる
27. 5G ブロードキャストの現状 イタリア放送協会「RAI」による調査 • 歩行／運転時の 5G での メディア視聴はまだ不安定 ◦ スマートフォンの種類や 視聴時の向きで 視聴の安定性が大きく異なる 5G 安定提供までにはまだ時間を要するか
28. 立ち上がった最先端のデジタルテレビ放送規格『 DTV+』 DTV+ とは • ブラジルの地上デジタルテレビ放送の最新規格 • デジタルテレビ放送規格として世界最先端の技術仕様 • アプリケーション機能を持ったチャンネル • 広告のパーソナライゼーション／ターゲティング • 4K60p x HDR10（VVC + MPEG-5 LCEVC） • イマーシブ・オーディオ（MPEG-H Immersive Audio）
29. 立ち上がった最先端のデジタルテレビ放送規格『 DTV+』 2025 年 4 月 29 日 ブラジルの大手放送局 Globo がリオデジャネイロの Jardim Botânicoで、DTV+（TV 3.0）のパイロット放送局 を立ち上げ https://globoir.globo.com/Download.aspx?Arquivo=VT1MJB1eIJA5jqVIgdFHoQ==&linguagem=en
30. 立ち上がった最先端のデジタルテレビ放送規格『 DTV+』
31. 立ち上がった最先端のデジタルテレビ放送規格『 DTV+』 MIMO • MIMO = Multiple-Input Multiple-Output • 送信側と受信側の両方で複数のアンテナを使用 • 同一ビットレートであれば SISO（Single-Input Single-Output）比較で 5 - 6 倍低い電力で送信可能 ◦ 受信体験を堅牢なものにするために 巨大な電力を必要 としない
32. DTV+ の実験プロジェクト「 Lighthouse」 実験局 Sumaré Hill • リオデジャネイロでメインで一番高い送信拠点 • 3 kW の MIMO 送信機 実験局 Sumaré Hill • リオデジャネイロで3番目に重要な送信拠点 • 1 kW の MIMO 送信機
33. 立ち上がった最先端のデジタルテレビ放送規格『 DTV+』 LDM • LDM = Layered Division Multiplexing • 階層化し、複数のサービスレイヤーの同時伝送 • DTV+ に新しいビジネスモデルである地理的なセグメンテーションで異なる広告を インターネットなしで放送 する技術 • 実験プロジェクト「Lighthouse」でのユースケース ◦ コアレイヤーに全国的に共通で提供されるメインの 4K HDR プログラムを割り当て ◦ エンハンストレイヤーに地理的なユーザーケースのセグメンテーションを目的とした HD HDR フィードを割り当て
34. 立ち上がった最先端のデジタルテレビ放送規格『 DTV+』 デジタルテレビ放送規格としての UX 再定義
35. 立ち上がった最先端のデジタルテレビ放送規格『 DTV+』 「Lighthouse」の成功を経て、いよいよ 2026 年商用展開開始予定
36. 変わりゆくメディア業界の 事業戦略トレンド
37. 放送局とプラットフォーマーの戦略的提携モデル Channel 4 × YouTube の補完戦略 視聴者層の違い TV平均年齢64歳 → YouTube 34歳 グローバルリーチ UK外視聴が50%(BBC 80%) 成長率 他プラットフォーム比 +169% ビジネスモデル • パートナーセールスプログラム : ◦ 放送局が長尺コンテンツの広告を直接販売 • 収益分配 ◦ 広告収益の50%以上を放送局が受領 • コンテンツ戦略: ◦ アーカイブ・ニッチ番組で既存ビジネスと競合回避 YouTubeは2クリックでライブ放送に誘導。 プラットフォームは視聴者を外部に送ることに前向
38. CTVエコシステムの主導権争い プラットフォーム事業者の台頭 Roku: 9,000万グローバルユーザー TVOSとして発見体験を支配 The Trade Desk: Project Ventura でTVOS参入 問題提起:広告費$10のうち $4.50しかコンテンツ提供者に届かない 通信事業者の課題 (Vodafone等) • CTVアプリストアの収益分配モデルが機能せず • 既存顧客維持の「衛生要因」として位置づけ • 新規獲得チャネルとして活用できていない ハードウェア販売 サプライヤー収益: ソフトウェア40% vs ハードウェア41%(同等に) ソフトウェア /サービス収益へ移行
39. 広告マーケットプレイスの構造変化 プログラマティック広告の拡大 Fox事例: 月間視聴者2.25億人(リニア5ch + AVOD Tubi) プログラマティック比率30%、ライブイベントで急成長 Converged Media Platform: オフラインも含め？ インプレッションベース購入に移行 広告技術の進化 • SGAI (Server-Guided Ad Insertion):L字・サイドバイサイド等の新フォーマット • アドレッサブル広告: 個人レベルターゲティング A/Bテスト実績 : 広告在庫販売 +30%(Google共同テスト ) リテールメディアネットワーク • 小売業者とのデータ提携で ID Graph強化 • ファーストパーティデータが競争優位の源泉 • 購買習慣データと視聴データの統合
40. 事業戦略の 3つの転換 1. デジタルファースト化の加速 • COVID-19でデジタル採用+30%加 速(英国) • 現状: リニア72% / デジタル28% → 2030年には逆転予測 • デジタル視聴者の収益化率が高い (CPM向上) 2. ビジネスモデルの多様化 • SVOD一極集中 → AVOD/FAST/ハ イブリッドモデルへ • Netflixも広告ティア導入、業界全体 が収益源多様化 • YouTube: 米国TV視聴シェア6ヶ月 連続トップ 3. データ主導の意思決定 • マルチアドサーバー対応とリアルタ イム最適化 • AIによるコンテクスチュアルターゲ ティング(Mobian等) • 測定の高度化:ビデオダウンロード 計測(真の視聴を捕捉) 日本市場への示唆 プラットフォーム依存 vs 自社プラットフォーム戦略 ファーストパーティデータ基盤の構築急務 グローバル標準技術(SGAI等)への早期対応
41. AI 進化によって変わる技術領域
42. AI 技術戦略 - プリプロダクション 企画・コンセプト開発： Storyboarder AI 1. プリプロダクションの課題 - 時間とコストの肥大化 - 手作業によるストーリーボード・ Vコン作成の非効率性 - イメージ共有の困難さ - 制作チーム間の認識齟齬 - 専門スキルへの依存 - イラストレーター・デザイナーのリソース確保 2. Storyboard AI：複数AIモデル統合によるプリプロ効率化 開発元: ドイツ発、プロフェッショナル向けツール 主要機能: AIストーリーボード生成 → Vコン（ビデオコンテ）生成まで対応 特徴: 複数AIモデルの組み合わせ、現場目線で作り込まれた実用性 3. 活用の可能性 - オリジナルコンテンツ企画 - ドラマ・バラエティの企画段階での活用 - プレゼンテーション強化 - 広告主への提案資料の視覚化 - 制作リードタイム短縮 - 企画→Vコン→撮影準備の高速化
43. AI 技術戦略 - プリプロダクション： 生成AI動画制作フレームワーク 複数企業による混合プロジェクト TV Globo （ブラジル） YLE （フィンランド） RAI （イタリア） AI動画クリエイター 目的: ストーリーボードから完成までを統合したモジュール型生成 AI動画制作システムの構築 フレームワークの特徴 • アーキテクチャ: API + ComfyUIベース • 統合ツール: 16種以上（Gemini、ChatGPT、Runway、Kling、 Veo3、Udio、Act Oneなど） • 2つのワークフロー : ◦ ラピッドプロトタイピング（ 15分で10秒動画生成） ◦ 本格的動画制作 技術的成果 • キャラクター一貫性の確保 • リップシンク技術（ Act One活用） • プロンプトの自動生成とバージョン管理 短期: コンセプトアート、予告編制作への応用　 中長期: 完全AI生成コンテンツの可能性
44. AI 技術戦略 - プリプロダクション 1. プリプロダクションの課題 - コンセプト共有の遅延 - チームへの新アイデア伝達に時間がかかる - デザイン制作の工数 - コンセプトアート・衣装デザインの手作業 - 制作中の方向転換 - 土壇場でのクリエイティブ変更への対応困難 2. バンクーバー・メディアの AI活用（Netflix『ペーパー・ハウス』等） - コンセプトアート・衣装デザインの迅速化 - AIツールで制作・共有を加速 - 「プリプロダクションのアクセラレーター」 - 企画段階の意思決定スピード向上 - 創造的な問題解決 - 制作中の土壇場でのクリエイティブ方向転換をサポート - AI活用の哲学 - 人間が最終判断、責任を持って活用
45. AI 技術戦略 - プリプロダクション 1. ロケーション撮影の課題 - 市民・交通への影響 - 街中での長時間撮影による混雑・迷惑 - 天候・時間の制約 - ロケーション撮影の再スケジュール困難 - 撮影許可の複雑さ - 公共スペースでの撮影調整コスト 2. バンクーバー・メディアの 3Dスキャン活用（ Netflix作品） Boleyn? AIツールによるデジタルツイン作成 - 3Dロケーションスキャン - 実際の街や建物をデジタル化 - バーチャルセット構築 - スキャンデータからバーチャル版のセットを作成 - 市民への配慮 - 街の中心部をスキャンして、現地での長時間撮影を回避 ロケーションスキャン デジタルツイン作成 スタジオ撮影 ワークフロー
46. AI 技術戦略 - プロダクション： デュアルユニット撮影の効率化 従来の撮影体制の課題 撮影スケジュールの逼迫 単一ユニットでの順次撮影による長期 化 ロケーション制約 天候・時間帯・撮影許可による待機時 間 リソースの非効率 俳優・スタッフの待機時間によるコスト 増 制作期間の延長 複雑なロケーションでの撮影待ち 技術アプローチ • 実際のセット + バーチャルセットの同時撮影 • 3Dロケーションスキャン（ Boleyn） - 実ロケをデジタル化してバー チャルセット作成 • デジタルツイン活用 バンクーバー・メディアのデュアルユニット撮影（ Netflix作品） ビジネスインパクト 撮影期間の大幅短縮 単順次撮影から並行撮影への転換 ロケーション制約からの解放 天候・時間帯に左右されない撮影 市民への配慮 街中での長時間撮影を回避しながらリ アルな映像制作 コスト最適化 待機時間削減による人件費・拘束費の 削減 デジタルツイン技術が実現する次世代の映像制作：効率化と品質の両立
47. AI 技術戦略 - プロダクション（スポーツ） Google Cloud: Vertex AIによる参加者のペナルティキックのライブ採点デモ 汎用撮影機材（Pixelのカメラ）で、スポーツライブにクラウド支援のリアルタイムなAI処理 が簡単に導入できる事を示しています。
48. AI 技術戦略 - プロダクション VVERTIGO • AI リフレーミング技術による 推しカメラサービス • 韓国の公共放送局 KBS が開発元 • チッケムの制作コストダウンに成功 ◦ ※ チッケム = ファンが好きなパフォーマーだけを 追って撮影した映像 • 8Kカメラ1台 で全体撮影、AI でパフォー マーを自動でトラッキング／トリミング 開発をプロのフォトグラファーが リード（カメラ設置位置の重要性）
49. AI 技術戦略 - ポストプロダクション FilmLight Naraは、撮影時の光源情報を一貫して記録管理し、AIによるVFX追加など後 続のワークフローを支援する製品を紹介 バーチャルスタジオ等で全編を既知の光源で 撮影出来れば問題ないが、そうではない場合 は、光源情報が後続のVFX等のワークフロー で本来必要なので、それを使いやすく管理する 製品にのようです。
50. AI 技術戦略 - 配信・放送段階 従来の編成業務の課題 - 人的リソースの逼迫 - 20チャンネル規模での手作業編成の限界 - 判断基準の属人化 - 編成担当者のノウハウに依存 - 複数データソースの統合困難 - 編成データ・SNS情報・視聴データの分散管理 - FAST等複数チャンネル管理の複雑化 - チャンネル数増加に伴う運用負荷 Amagi AIによる編成業務自動化の事例 - メタデータ自動付与 - コンテンツインジェスト後にサマリー・出演者情報・キーワードを自動抽出 - 自動スケジューリング - 編成データ・情報データ・ SNS情報を組み合わせた最適編成 - チャットインターフェース - チャットから指示すると編成の調整を実行 - 判断根拠の説明機能 - AIが編成判断の理由を提示、運用者が基準を理解可能 - シーン切り替わり検出 - 広告ポイントの自動設定
51. AI 技術戦略 - 配信・放送段階 Actus（LiveUにより買収）は、ライブストリームのコンプライアンス・品質モニタリングと記 録のソリューションを基礎として、AIを活用した追加の情報取得機能を追加していた。 映像監視ソリューションの全体的な方向性を整理する と以下のようになっていた。 • 専用の処理を用いた規格化された異常監視 • 汎用のマルチモーダルなモデルを使ったもの
52. AI 技術戦略 - 配信・放送段階 AWSブースでは、MVADモデル（参照データなしで視覚的な異常検知が可能）を動画 ファイルに対して適用して、品質値を出力するデモが展示されていて、今後の映像監視 の方向性が示されていた。 MVAD: A multiple visual artifact detector for video streaming - Amazon Science
53. AI 技術戦略 - 配信・放送段階 第 6 世代移動通信技術は AI で ネットワークを賢くすることをターゲット デバイス搭載のローカル AI と クラウドやエッジの AI が リアルタイムにコンテキストを 共有するネットワークを作ることにフォーカス 6G
54. AI 技術戦略 - 配信・放送段階 5G の焦点 6G の焦点 速度 AI 容量 センシング 低遅延 インテリジェンス
55. AI 技術戦略 - 配信・放送段階 5G の焦点 6G の焦点 速度 AI 容量 センシング 低遅延 インテリジェンス 6G は AI ネイティブな通信技術
56. AI 技術戦略 - 配信・放送段階 デバイス搭載型 AI による UX 向上 デバイス搭載型 AI による処理 デバイス内の文脈情報 アプリケーション要件 ユーザー意図 デバイスの動作条件 エッジ AI による処理 ネットワークパラメータ調整
57. AI 技術戦略 - 配信・放送段階 デバイス搭載型 AI による UX 向上 デバイス搭載型 AI による処理 デバイス内の文脈情報 アプリケーション要件 ユーザー意図 デバイスの動作条件 エッジ AI による処理 ネットワークパラメータ調整 6G システム E2E で 性能と効率性を最適化
58. AI 技術戦略 - 配信・放送段階 UX-aware RAN（ユーザー体験を認識した無線アクセスネットワーク） 例えば、デバイス搭載型 AI が低遅延アプリケーションを使用していること、バッテリー残量が 30%未満であること、そ してパフォーマンスが最適状態ではないことを推論 → ネットワークと共有、それに基づいてネットワークパラメータや QoS 設定、リソース割り当てを調整
59. AI 技術戦略 - 配信・放送段階 UX-aware RAN（ユーザー体験を認識した無線アクセスネットワーク） 例えば、デバイス搭載型 AI が低遅延アプリケーションを使用していること、バッテリー残量が 30%未満であること、そ してパフォーマンスが最適状態ではないことを推論 → ネットワークと共有、それに基づいてネットワークパラメータや QoS 設定、リソース割り当てを調整 ユースケース固有の需要に対応できる AI ネイティブなネットワーク
60. AI 技術戦略 - 運用・分析・マネタイズ段階 ワーナーブラザース・ディスカバリーでは、あるシーンから3種のメタデータを抽出して いる事を紹介 広告マネタイズでの利用を意図したメタを主に付 与しており、目的が明確となっている。 • GARM: ブランドセーフティ区分（広 告） • IAB: カテゴリー情報（広告） • シーンのテキスト表現
61. AI 技術戦略 - 運用・分析・マネタイズ段階 ワーナーブラザース・ディスカバリーでは、あるシーンから3種のメタデータを抽出して いる事を紹介 広告マネタイズでの利用を意図したメタを主に付 与しており、目的が明確となっている。 • GARM: ブランドセーフティ区分（広 告） • IAB: カテゴリー情報（広告） • シーンのテキスト表現
62. AI 技術戦略 - 運用・分析・マネタイズ段階 Vionlabsは、VODコンテンツ向けのバッチ分析ソ リューションを提供していて、動画を5秒毎に区切っ たものに対して、感情を推定し、全体的な感情動 向に対して、ジャンル等では表現できなかったコン テンツの雰囲気のようなものを推定でき、テイスト の似た作品を集めたプレイリストを自動生成でき る。 動画ファイル 動画の5秒毎の エンべディング 感情分析 イントロスキップ キューポイント
63. AI 技術戦略 - 運用・分析・マネタイズ段階 ワーナーブラザース・ディスカバリーでは、シーンから抽出した、雰囲気、タイミング、意 味合いのメタデータを取得している。 • 誕生パーティー • 指輪（青）、ブレスレット（オレンジ）、男性用 ブレザー（ピンク） • 場所: リビングルーム（緑） • ブランド広告差し込み適合箇所（黄） 本編と広告で感情の飛躍を避けるなど、プ レースメント精度を高める目的で活用
64. AI 技術戦略 - 運用・分析・マネタイズ段階 ワーナーブラザース・ディスカバリーは、他にも多数の事例も紹介しています。 ドロップインモーメント（プレビュー動画）の切り出し CTR、視聴時間中央値を高めるよ うな動画を切り出す
65. AI 技術戦略 - 運用・分析・マネタイズ段階 ワーナーブラザース・ディスカバリー、セマンティック検索 ユーザーの意図を汲み取る検索 で、検索結果0件を減らし、検索 経由の再生を伸ばす
66. AI 技術戦略 - 運用・分析・マネタイズ段階 ワーナーブラザース・ディスカバリー、映像からキャプションを生成 キャプションを多言語で整備し、コ ンテンツが世界中から見られるよ うにする
67. AI 技術戦略 - 運用・分析・マネタイズ段階 DAZNはストリームログ収集集計ソリューションのHydrolixを使って、FIFA ワールドカップのマ ルチCDN構成システムの不具合を分析、対応したかを発表していました。ストリーム処理の 利点をどのように活かすかについて、リアルタイムに課題解決し、AIによる自動的な異常検 知の指針が示されました。 緻密な行動ログベースの異常検知により、 • ユーザー体験の全般的な向上 • ユーザーサポート対応品質精度向上
68. 進化するスポーツコンテンツ最前線
69. BBCバーチャルスタジオ戦略 コスト削減ではなく、放送クオリティの革新 「コスト削減、それは必ずしも真実ではありません。特に初 めてこれを行う場合、デザインに関して非常に高コストに なる可能性があります」 真の価値：表現力とクオリティの向上 1. ストーリーテリングの革新 - 複数仮想空間の活用:1つのデスクから3-4の異なるロケーションへ移動 - 没入型体験:物理的制約なしの説得力あるコンテンツ制作 2. 視覚的インパクト - 視聴者がリアル放送と錯覚するほどのクオリティ - タレント自身が感動する体験（通常得られない反応） - SNSでの大きな反響とブランド価値向上 採用技術 - Unreal Engine + LED技術 + XR/AR - ハイブリッド統合（グリーンスクリーン＋バーチャル環境）
70. 放送・制作における AI 活用 ライブスポーツ中継の自動化・高度化 事例1：KBS パラリンピック（2024） 世界初のライブ AI適用 - 水泳:自動レーン検出 +国旗オーバーレイ（ CLR-EARNETモデル） - フェンシング : 小さな得点ライト自動検出・拡大表示 - Unity + SDIパイプライン統合、ゼロ遅延 「KBSは強化グラフィックをライブ追加した唯一の放送局」 事例2：自転車レース（ヘント大学） - ライダー認識 : YOLOベース+センサーデータ統合 - 3D AR: リアルタイム統計表示（処理速度 250ms） - ランドマーク自動検出 : AI自動認識・ラベリング 「完全自動化されたコンテキスト認識型放送へ移行」 事例3：ゴルフ中継（ボールトラッキング） - AIボール追跡 :コンピュータービジョンによる高速ボール軌道解析 - 軌跡可視化 : リアルタイムで飛距離・弾道を自動表示 - 統計自動生成 :飛距離、着地点、スピンレートの即時算出 技術要素 : 高速カメラ + AI解析 + AR表示 リアルタイム処理 人間と AIの協働 マルチモーダルデータ統合
71. 多言語対応 技術のトレンド概要 ソリューション 遅延 言語数 特徴 適用シーン AI-MEDIA 6-8秒 - カスタム辞書、高信頼性 スポーツ、ニュース Harmonic 45秒 70カ国語 声質保持 K-POP、エンタメ AWS DeepTube 30秒 - 超高速合成 リアルタイム配信 ingopal.ai - - 生放送特化 ライブ番組 リアルタイム化の加速 遅延の大幅短縮 - 従来の人手による字幕・翻訳：数時間〜数日 - AI翻訳：30秒〜8秒まで短縮 - ライブ配信での実用レベルに到達 音声合成の高品質化 声質保持技術の進化 - オリジナル話者の声質・感情を維持したまま多言語化 - 単なる機械音声から「自然な話し方」へ - 10-15種類の声・感情バリエーション選択可能
72. TikTok の絶大な影響 :プラットフォームとコンテンツの融合 1. TikTokのスポーツユーザー概況 8人に1人がTikTokを利用 89% 月次でスポーツコンテンツを視聴 女性視聴者 46% 従来リーチしづらい層 ショート動画が 新たなスポーツ入口に 2. TikTokの5つのスーパーパワー 1. リーチ困難層への到達 - 若年層・女性層の開拓 2. パーソナライズされた発見体験 - アルゴリズムによるコンテンツ推薦 3. 文化的トレンドの創造 - ハッシュタグキャンペーン 4. ファンコンテンツ創出 - UGC促進 5. カスタムスポーツプロダクト - ゲーミフィケーション・ディープリンク 3. ビジネスインパクト TikTokでスポーツにふれると +42% 高いライブスポーツ視聴意向 DAZN事例: ROAS +187%　新規顧客獲得 +88% IOC/La Liga: 急速なフォロワー成長 （数百万規模） 4. 学び - ショート動画 → ライブ視聴の導線設計 | UGC活用によるエンゲージメント向上 - 女性・若年層への新規リーチ戦略 | ゲーミフィケーションの検討価値
73. FAST とスポーツ： DAZNのファネル型会員獲得戦略 1. FAST市場の現状 北米中心に急成長 70% グローバル FAST市場でAmagi製品 スポーツとの親和性が高い イベント性とアーカイブ価値の両立 EPG統合によるネイティブ体験 収益分配モデル確立 プラットフォームと配信者間の 広告収益シェア 2. DAZNの戦略：無料から有料への導線設計 ファネル上部（FAST層） - ドキュメンタリー配信 - 過去の試合アーカイブ - チーム/選手特化コンテンツ ファネル下部（有料会員転換） - 決勝戦などのライブイベント - 会員限定コンテンツ 3. 学び 既存アーカイブの有効活用 過去の名試合・ドキュメンタリーを FAST配信 イベント前のファン育成 決勝戦前にコンテキスト提供でエンゲージメント 向上 段階的マネタイズ設計 無料視聴 → 興味喚起 → 有料会員転換の導線 柔軟なチャンネル運用 W杯・五輪などイベント時のみの展開検討
74. リアルタイムイベント連動型広告 1. 従来の課題 ニュース・スポーツでの 広告配信困難 - 視聴体験との両立 - 従来のオーバーレイ広告による 違和感 - パーソナライゼーション限界 - サーバーサイドのみでは 表現力に制約 2. TGI スポーツ技術：クライアントサイド処理によるリアルタイム広告 技術アプローチ - メタデータ配信 - 広告挿入位置、ディストーション、リフレクション 情報をサーバーから配信 - クライアントサイドレンダリング - デバイス側で広告を自然に合成 - 物理的整合性 - スタジアムの看板やフィールド上に違和感なく 表示 - パーソナライゼーション - 視聴者ごとに異なる広告表示 - 視聴体験の維持 - コンテンツ本編を阻害しない広告
75. スポーツイベントデータ スポーツイベントにおいて、イベントストリームデータ（得点タイミング等）は、より良い ユーザー体験のための基幹コンポーネントとなりつつある。 ライブ イベント ストリームデータ 切り出し動画 イベントタイムライ ンの付加 アーカイブ動画 レコメンド活用 イベント駆動 広告挿入
76. AWS テーブルフットボールゲーム盤面解析のデモ AWSのConnected Table Footballデモでは以 下のような構成のデモを実施していた。 1. クラウドでモデルを学習 2. ローカルにモデルをデプロイ 3. ローカルで動画の解析を実施 4. イベント情報のみアップロード
77. ワーナーブラザース・ディスカバリー インジェストストリーム解析画面 ワーナーブラザース・ディスカバリーで は、システムに取り込まれたスポーツコ ンテンツに対して以下を付与する。 • 動画を解析したイベントタイムライン • 個々のイベントの盛り上がり度（歓声を利 用する）
78. Gracenote Sports Data Gracenoteは、70スポーツ、30万試合 を対象としてスポーツデータを提供して いる Gracenote Sports Data
79. より安定／安全に熱狂を届ける ライブ動画配信を実現する技術
80. HTTP Video Streaming で安定した低遅延配信を実現 低遅延動画配信を提供する際の問題を解決する 2 つの技術を紹介 • CMMF ◦ マルチ CDN 切替の課題 を解決 • Server Side ABR Streaming ◦ アダプティブ・ビットレート切替（ ABR）の課題を解決
81. マルチ CDN 切替の課題 複数の CDN を切り替えながらダウンロード
82. マルチ CDN 切替の課題 複数の CDN を切り替えながらダウンロード 切り替えのタイミングはネットワーク品質の低下を検知した後
83. マルチ CDN 切替の課題 複数の CDN を切り替えながらダウンロード 切り替えのタイミングはネットワーク品質の低下を検知した後 一時的にネットワーク品質の低下が発生する
84. マルチ CDN 切替の課題 複数の CDN を切り替えながらダウンロード 切り替えのタイミングはネットワーク品質の低下を検知した後 一時的にネットワーク品質の低下が発生する 切り替えるのではなく 複数の CDN から平行してダウンロードするのはどうか？
85. CMMF CMMF = Coded Multi-source Media Format • 複数のネットワークソースや CDN から同時に動画データをダウンロードしてプレイ ヤーが再生できるフォーマット
86. CMMF CMMF = Coded Multi-source Media Format • 複数のネットワークソースや CDN から同時に動画データをダウンロードしてプレイ ヤーが再生できるフォーマット
87. CMMF CMMF = Coded Multi-source Media Format • 複数のネットワークソースや CDN から同時に動画データをダウンロードしてプレイ ヤーが再生できるフォーマット
88. CMMF CMMF = Coded Multi-source Media Format • 複数のネットワークソースや CDN から同時に動画データをダウンロードしてプレイ ヤーが再生できるフォーマット
89. CMMF CMMF = Coded Multi-source Media Format • 複数のネットワークソースや CDN から同時に動画データをダウンロードしてプレイ ヤーが再生できるフォーマット
90. CMMF の仕組み ネットワーク符号化技術の応用 • ネットワーク符号化 ◦ ネットワークの中継ノードに複数のパケットを 論理演算で結合して 1 つの符号にまとめて 効率良く伝送する技術 https://en.wikipedia.org/wiki/Linear_network_coding
91. CMMF の仕組み CMMF のエンコード 1. HLS ／ MPEG-DASH セグメントを単一のブロッ クとして入力 2. ネットワークコード （RLC、RaptorQ、Reed-Solomon など）を利 用し、パーティションして相関があるビット列を、 交換可能な情報のパケットにマップ 3. デコードに必要なメタデータ （ブロックサイズ、シンボルサイズ、 エンコードシンボル ID など）と併せて、1つ以上のCMMFビッ トストリーム内にパッケージ
92. CMMF の仕組み CMMF のエンコード 1. HLS ／ MPEG-DASH セグメントを単一のブロッ クとして入力 2. ネットワークコード （RLC、RaptorQ、Reed-Solomon など）を利 用し、パーティションして相関があるビット列を、 交換可能な情報のパケットにマップ 3. デコードに必要なメタデータ （ブロックサイズ、シンボルサイズ、 エンコードシンボル ID など）と併せて、1つ以上のCMMFビッ トストリーム内にパッケージ ネットワークの異なるロケーション（ CDN など）から利用可能
93. CMMF の仕組み CMMF のデコード 1. クライアントが複数の CMMF ビットストリームを並行してダウンロード 2. CMMF ビットストリームの任意の組み合わせ元のコンテンツをデコードするために必要な量の符号化情 報を取得（個々の CMMF ビットストリームの全部を取得しなくてもよい） 3. クライアントに搭載された CMMF デコーダーが CMMF ビットストリームを共同でデコードし、元のセグメン トが復元できたメディアプレイヤーに供給
94. CMMF の仕組み CMMF のデコード 1. クライアントが複数の CMMF ビットストリームを並行してダウンロード 2. CMMF ビットストリームの任意の組み合わせ元のコンテンツをデコードするために必要な量の符号化情 報を取得（個々の CMMF ビットストリームの全部を取得しなくてもよい） 3. クライアントに搭載された CMMF デコーダーが CMMF ビットストリームを共同でデコードし、元のセグメン トが復元できたメディアプレイヤーに供給 ネットワークの一部に障害やパフォーマンス低下が発生しても 他のソースからより多くダウンロードすることで自動的に補償可能 QoS の低下を抑制
95. CMMF 組込みのポイント ネットワーク符号化するための追加の 独立したレイヤー（ CMMF）を挿入 レイヤー化アプローチにより、 既存のパッケージ形式の動画データと 通信プロトコルで並列配信可能 • HLS など既存の手段でパッケージ化された動画 データを CMMF でカプセル化 • HTTP/TCP で配信 • クライアントはコンテンツを複数の CDN から 並列にダウンロード • クライアントの CMMF レイヤーで カプセル化を解く • カプセル化を解いた後は HLS ＝ プレイヤーが再生
96. CMMF の効果：マルチ CDN 切替との比較 • 再生までの時間（Join Time） ◦ 46% 短縮 • リバッファリング率 ◦ 75% 低減 • 平均再生ビットレート ◦ 12.7% 改善 • 再生開始失敗率 ◦ 86.3% 減少 • 再生失敗率 ◦ 58.9% 削減
97. CMMF の効果：マルチ CDN 切替との比較
98. サーバーサイド ABR が解決する課題 クライアントサイド ABR の課題 • クライアントがネットワークの状態を知らない • クライアントは直前のセグメントの配信にかかった 時間は計測できるが、それ以外の（カーネルで制 御される）TCP の挙動は知らない
99. サーバーサイド ABR が解決する課題 クライアントサイド ABR の課題 • クライアントがネットワークの状態を知らない • クライアントは直前のセグメントの配信にかかった 時間は計測できるが、それ以外の（カーネルで制 御される）TCP の挙動は知らない 最適な映像品質／ビットレートの 決定が難しい
100. 再生停止リスクと遅延低減のトレードオフの関係 最適なビットレートを決定できない
101. 再生停止リスクと遅延低減のトレードオフの関係 最適なビットレートを決定できない 再生停止リスクを抑えるために取得したセグメントを複数バッファリング
102. 再生停止リスクと遅延低減のトレードオフの関係 最適なビットレートを決定できない 遅延が大きくなる 再生停止リスクを抑えるために取得したセグメントを複数バッファリング
103. Amazon Sye ※ Net Insight 開発の低遅延ストリーミングプロトコル（ 2020 年 1 月 Amazon 買収） 特徴 • サーバーサイドでの ビットレート決定 • UDP による伝送 ◦ 伝送速度を厳密に制御 • 独自ストリーミングプロトコル
104. Amazon Sye ※ Net Insight 開発の低遅延ストリーミングプロトコル（ 2020 年 1 月 Amazon 買収） 特徴 • サーバーサイドでの ビットレート決定 • UDP による伝送 ◦ 伝送速度を厳密に制御 • 独自ストリーミングプロトコル 標準ストリーミングプロトコルで Sye のパフォーマンスを実現できないか？
105. QUIC を使った標準プロトコルでのサーバーサイド ABR QUIC の特性 • 応用的な通信処理の実装時の TCP の課題を解決する TCP 代替プロトコル TCP QUIC 輻輳応答やパケットロス回復 処理をカーネル空間で実装 アプリケーションごとのカスタ マイズは難しい 輻輳応答やパケットロス回復 処理はユーザー空間で実装 アプリケーションごとのカスタ マイズが容易
106. Go を使ったサーバーサイド ABR 実装
107. Go を使ったサーバーサイド ABR 実装 QUIC Command Channel • アプリケーションが QUIC トランスポートプロトコルに配信コマンドを送信するチャンネル 配信コマンド 目的 最大伝送レート データを配信する最大のビットレートを設定 バースト配信ではなくペース配信を実現するために使用 ファイルサイズと伝送期限 配信すべきデータ量と、そのすべてのデータを配信完了すべき期限を定義 例：セグメントまたはチャンクのサイズと、コンテンツの途切れのない再生を達成するためにデータを受信する必要 がある期限を指定 最小伝送レート ファイルサイズが不明な場合に使用 例：公称のエンコード済みメディアレートに設定可能 QUIC レポート期間 QUIC トランスポートプロトコルから HTTP サーバーにレポートが送信されるまでの希望時間 最大保存 RTTサンプル 保存および報告する最大ラウンドトリップタイム（ RTT）サンプルの数
108. Go を使ったサーバーサイド ABR 実装 QUIC Report Channel • QUIC トランスポートプロトコルが HTTP サーバーアプリケーションに 配信性能に関する統計情報を報告するチャンネル 統計パラメータ 情報 QUIC レポート時間 QUICレポートが作成された時刻 パケット伝送 最初のパケット送信時刻／最新のパケット送信時刻／合計送信パケット数／合計送信バイト数 確認応答 最新の確認応答時刻／確認応答されたバイト数／未処理のバイト数 輻輳ウィンドウ 輻輳ウィンドウのサイズ、現在の帯域幅の推定値 パケットロス 最新のパケットロス時刻、合計パケットロス数
109. サーバーサイド ABR ストリーミング w/ 標準プロトコル クライアント ABR の決定
110. サーバーサイド ABR ストリーミング w/ 標準プロトコル クライアントサイドの取得ビット レート決定をサーバーサイドで の転送ビットレート決定で上書 き クライアント ABR の決定
111. サーバーサイド ABR ストリーミング w/ 標準プロトコル クライアントサイドの取得ビット レート決定をサーバーサイドで の転送ビットレート決定で上書 き QUIC による 輻輳検知＋ データ転送速度指示 クライアント ABR の決定
112. サーバーサイド ABR ストリーミング w/ 標準プロトコル クライアントサイドの取得ビット レート決定をサーバーサイドで の転送ビットレート決定で上書 き QUIC による 輻輳検知＋ データ転送速度指示 バースト的転送タイミ ングがない平坦で予 測しやすい通信 クライアント ABR の決定
113. サーバーサイド ABR ストリーミング w/ 標準プロトコル クライアントサイドの取得ビット レート決定をサーバーサイドで の転送ビットレート決定で上書 き QUIC による 輻輳検知＋ データ転送速度指示 バースト的転送タイミ ングがない平坦で予 測しやすい通信 クライアント ABR の決定は 上書かれているが、クライ アントはそれに無自覚でい い
114. サーバーサイド ABR パフォーマンス実験 条件 • プレイヤー ◦ dash.js • 生成するレンディション ◦ 1 / 2 / 4 / 6 Mbit/s • セグメント ◦ 6.4 秒尺 ◦ 0.4 秒チャンク • 配信サーバーの出力制限 ◦ 最大 10 Mbit/s 競合トラフィック 挙動を観測する プレイヤー・アプリケーション
115. サーバーサイド ABR パフォーマンス実験 Client Side ABR Server Side ABR
116. サーバーサイド ABR パフォーマンス実験 Client Side ABR タイムライン • 10 秒 ◦ プレイヤー・アプリケーション起動 • 30 秒 ◦ ファイル・ダウンロード（競合トラフィック）開始 • 90 秒 ◦ ファイル・ダウンロード（競合トラフィック）終了 • 130 秒 ◦ プレイヤー・アプリケーション終了
117. サーバーサイド ABR パフォーマンス実験 Client Side ABR タイムライン • 10 秒 ◦ プレイヤー・アプリケーション起動 • 30 秒 ◦ ファイル・ダウンロード（競合トラフィック）開始 • 90 秒 ◦ ファイル・ダウンロード（競合トラフィック）終了 • 130 秒 ◦ プレイヤー・アプリケーション終了 プレイヤーは 6 Mbit/s のセ グメントをリクエストしている が、実際の配信は 4.5 Mbit/s でされている
118. サーバーサイド ABR パフォーマンス実験 Client Side ABR タイムライン • 10 秒 ◦ プレイヤー・アプリケーション起動 • 30 秒 ◦ ファイル・ダウンロード（競合トラフィック）開始 • 90 秒 ◦ ファイル・ダウンロード（競合トラフィック）終了 • 130 秒 ◦ プレイヤー・アプリケーション終了 ダウンロード時間が 徐々に長く 競合トラフィック開始 バッファ枯渇 遅延も増加
119. サーバーサイド ABR パフォーマンス実験 Client Side ABR タイムライン • 10 秒 ◦ プレイヤー・アプリケーション起動 • 30 秒 ◦ ファイル・ダウンロード（競合トラフィック）開始 • 90 秒 ◦ ファイル・ダウンロード（競合トラフィック）終了 • 130 秒 ◦ プレイヤー・アプリケーション終了 プレイヤーリセット 1つのセグメントのリク エストをスキップ＋ 遅延 10 秒で再生再開
120. サーバーサイド ABR パフォーマンス実験 Client Side ABR タイムライン • 10 秒 ◦ プレイヤー・アプリケーション起動 • 30 秒 ◦ ファイル・ダウンロード（競合トラフィック）開始 • 90 秒 ◦ ファイル・ダウンロード（競合トラフィック）終了 • 130 秒 ◦ プレイヤー・アプリケーション終了 4 Mbit/s のセグメントを 終了までリクエスト ※ 6 Mbit/s のセグメン トを取得可能にも関わ らず
121. サーバーサイド ABR パフォーマンス実験 Server Side ABR プレイヤーは 6 Mbit/s のセ グメントをリクエスト プレイヤーは 1.1 倍速で再生 遅延が 4 秒→ 3 秒に短縮 バッファー安定 タイムライン • 10 秒 ◦ プレイヤー・アプリケーション起動 • 30 秒 ◦ ファイル・ダウンロード開始 • 90 秒 ◦ ファイル・ダウンロード終了 • 130 秒 ◦ プレイヤー・アプリケーション終了
122. サーバーサイド ABR パフォーマンス実験 Server Side ABR QUIC 輻輳制御により ダウンロード時間は安定 タイムライン • 10 秒 ◦ プレイヤー・アプリケーション起動 • 30 秒 ◦ ファイル・ダウンロード開始 • 90 秒 ◦ ファイル・ダウンロード終了 • 130 秒 ◦ プレイヤー・アプリケーション終了 クライアントは 6 Mbit/s のセグメ ントをリクエストしているが、サー バーが 4 Mbit/s に引き下げ バッファー安定
123. サーバーサイド ABR パフォーマンス実験 （配信ビットレート） Client Side ABR Server Side ABR TCP の バースト的なオン／ オフ配信が確認できる ペース配信が確認できる
124. サーバーサイド ABR パフォーマンス実験 （配信ビットレート） Client Side ABR Server Side ABR TCP の バースト的なオン／ オフ配信が確認できる ペース配信が確認できる 標準プロトコルによるサーバーサイド ABR で 低遅延と安定したバッファを実現
125. HTTP Video Streaming で安全なライブ配信を実現 ライブ配信を提供する際の問題を解決する 2 つの技術を紹介 • High-frequency key rotation ◦ ライブ・コンテンツが盗まれるリスク を低減 • C2PA ◦ 生成 AI によるディープフェイクの脅威に ライブ・コンテンツに対する信頼性が落とされる課題 を解 決
126. HTTP Video Streaming で安全なライブ配信を実現 ライブ配信を提供する際の問題を解決する 2 つの技術を紹介 • High-frequency key rotation ◦ ライブ・コンテンツが盗まれるリスク を低減 • C2PA ◦ 生成 AI によるディープフェイクの脅威に ライブ・コンテンツに対する信頼性が落とされる課題 を解 決 コアバリューに動画を扱うサービスにとっては どちらも大きな悩みの種を取り除く技術
127. ライブ・コンテンツが盗まれるリスクへのアプローチ コンテンツ保護と言えば …
128. ライブ・コンテンツが盗まれるリスクへのアプローチ コンテンツ保護と言えば … DRM
129. ライブ・コンテンツが盗まれるリスクへのアプローチ コンテンツ保護と言えば … DRM しかし、近年の DRM エコシステムには課題も
130. ライブ・コンテンツが盗まれるリスクへのアプローチ 近年の DRM エコシステムが抱える課題 • Google Widevine / Microsoft PlayReady で保護されたコンテンツは既に漏洩しや すい状態 ◦ PlayReady のソースコードが漏洩している ◦ Widevine はハックが容易 • 素人でも簡単に暗号鍵を取得できるツールが存在 • 海賊行為コミュニティで鍵を共有
131. ライブ・コンテンツが盗まれるリスクへのアプローチ 近年の DRM エコシステムが抱える課題 • Google Widevine / Microsoft PlayReady で保護されたコンテンツは既に漏洩しや すい状態 ◦ PlayReady のソースコードが漏洩している ◦ Widevine はハックが容易 • 素人でも簡単に暗号鍵を取得できるツールが存在 • 海賊行為コミュニティで鍵を共有 今こそ DRM によるコンテンツ保護の改善が必要
132. DRM をどう改善するか？ 保護する側と海賊行為を行う側のゲームはイタチごっこ • 暗号鍵を盗まれないように対策を打っても、回避策は必ず発明される • 暗号鍵は漏洩するものとして考える
133. DRM をどう改善するか？ 保護する側と海賊行為を行う側のゲームはイタチごっこ • 暗号鍵を盗まれないように対策を打っても、回避策は必ず発明される • 暗号鍵は漏洩するものとして考える 漏洩する暗号鍵に対して何ができるか
134. DRM をどう改善するか？ 保護する側と海賊行為を行う側のゲームはイタチごっこ • 暗号鍵を盗まれないように対策を打っても、回避策は必ず発明される • 暗号鍵は漏洩するものとして考える 暗号鍵をより頻繁に変更する 漏洩する暗号鍵に対して何ができるか
135. 高頻度の暗号鍵ローテーション Pros • 暗号鍵のローテーション頻度が上がれば、鍵を盗む側もその頻度で盗む必要がある Cons • Thundering Herd 問題 ◦ ライブエッジにいる 100 万人の視聴者の暗号鍵が一気に 変更され、DRM サーバーへのライセンス・チャレンジ・ リクエストがスパイクする ◦ 制御難易度が高い ▪ スパイクのタイミングは予測不可能 ▪ DRM システムをスケールさせる難易度が高い • ライセンス・チャレンジ・レスポンスは キャッシュ不可 → 全てオリジン処理
136. 高頻度の暗号鍵ローテーション Pros • 暗号鍵のローテーション頻度が上がれば、鍵を盗む側もその頻度で盗む必要がある Cons • Thundering Herd 問題 ◦ ライブエッジにいる 100 万人の視聴者の暗号鍵が一気に 変更され、DRM サーバーへのライセンス・チャレンジ・ リクエストがスパイクする ◦ 制御難易度が高い ▪ スパイクのタイミングは予測不可能 ▪ DRM システムをスケールさせる難易度が高い • ライセンス・チャレンジ・レスポンスは キャッシュ不可 → 全てオリジン処理 いかにスパイクをならすか
137. Thundering Herd 回避デモ スパイクをならすための DRM 鍵システム DRM ライセンス・チャレンジ・リクエストのタイミングを変更 • プレイヤーは下記 2 点の情報を取得 ◦ 動画ストリームのインバンドから ISO BMFF の pssh ボックスによるシグナリング ◦ DRM 鍵システムからタイミング情報を取得 ▪ キー・システムは自身の負荷を知っているので、プレイヤーに対し x 秒リクエストを待つように タイミング情報を調整
138. Thundering Herd 回避デモ スパイクをならすための DRM 鍵システム DRM ライセンス・チャレンジ・リクエストのタイミングを変更 • プレイヤーは下記 2 点の情報を取得 ◦ 動画ストリームのインバンドから ISO BMFF の pssh ボックスによるシグナリング ◦ DRM 鍵システムからタイミング情報を取得 ▪ キー・システムは自身の負荷を知っているので、プレイヤーに対し x 秒リクエストを待つように タイミング情報を調整 DRM ライセンス・チャレンジ・リクエストが分散される
139. 高頻度の暗号鍵ローテーション：再生プレイヤー側の負荷 再生クライアントの CPU 消費量増加 • DASH の場合 Period 要素数が激増 ◦ Period 要素を分割して鍵 ID の変更をシグナ ルする ▪ 頻度増加 → Period 数増加 ◦ 10 秒 Period + 1 時間 DVR ウィンドウ = MPD 内に 360 Periods
140. 高頻度の暗号鍵ローテーション：再生プレイヤー側の負荷 再生クライアントの CPU 消費量増加 • DASH の場合 Period 要素数が激増 ◦ Period 要素を分割して鍵 ID の変更をシグナ ルする ▪ 頻度増加 → Period 数増加 ◦ 10 秒 Period + 1 時間 DVR ウィンドウ = MPD 内に 360 Periods インバンド・シグナリングを利用して Period に依存しない鍵変更 • ISO BMFF の sgpd 関連ボックスで各サンプルがどの鍵 ID に属するか伝達 • pssh ボックスをメディアセグメント内にも挿入
141. Thundering Herd 回避デモ 10 秒間隔での暗号鍵ローテーションでのデモ
142. C2PA とは C2PA = Coalition for Content Provenance and Authenticity コンテンツ来歴と信頼性に関する標準化団体 • ビデオが作成されてから視聴されるまで 一貫して信頼できる 方法でのみ編集され てきたことを証明することを目的に技術仕 様を策定 • arm / BBC / Intel / Microsoft / Truepic / Adobe などが中心に創設 • 最新バージョンは 2.2（2025 年 5 月 1 日版） https://spec.c2pa.org/specifications/specifications/2.2/specs/_attachments/C2PA_Specification.pdf
143. C2PA C2PA に関する過去のレポート https://speakerdeck.com/cyberagentdevelopers/nab-show-2024-report?slide=73 https://speakerdeck.com/cyberagentdevelopers/ibc-2024-report?slide=42
144. C2PA とは C2PA = Coalition for Content Provenance and Authenticity • コンテンツの来歴と信頼性に関する連合 • ビデオが作成されてから視聴されるまで一貫して信頼できる方法でのみ編集されて きたことを証明することが目的 ABEMA のように報道を扱い、 社会インフラを目指すサービスでは避けて通れないトピック
145. 来歴証明技術のライブコンテンツ適用 目的 • C2PA とライブコンテンツに信頼性 を付与 要件 • C2PA 情報をリアルタイムで検証 できること 課題 • C2PA の証明情報を追加するため、必要な帯域幅が増えてしまう
146. アプローチの基本コンセプト • C2PA 情報をイベントストリームとして伝送し、その瞬間のコンテンツに対して来歴 を証明する（見ているコンテンツが信頼できることを証明） 繰り返し送る C2PA 情報によって増える帯域幅をどう削減するか • C2PA のマニフェスト情報本体は上記に含まれなくてもいい ◦ マニフェストへの URL だけ含んでいればいい • 全てのセグメントには C2PA 情報を含めない 来歴証明技術のライブコンテンツ適用
147. MPEG-DASH へ適用 C2PA マニフェストを emsg ボックスに 入れて ストリームを配信 来歴証明技術のライブコンテンツ適用
148. ライブストリーミングのワークフローに焦点 を当てて PoC • 条件 ◦ C2PA マニフェストは事前にオフライン生 成 ◦ ライブ映像は VOD2Live でシミュレート PoC - ライブ MPEG-DASH の C2PA 適用 2 段階パッケージング セグメントを生成するタイミングでは、メディアアセットの完全な情報がない セグメントごとのC2PA情報を生成して、そのマニフェストを emsg ボックスに入れる ために 2 回パッケージ
149. C2PA マニフェスト情報はシンプルなものであればセグメントごとに 18 KB 程 • PoC では無圧縮 • Zip 圧縮で 10 KB 程度に • C2PA としては Brotli で圧縮することを推奨（Zip 圧縮以上の効率を期待） • C2PA 情報を毎セグメントごとに送らず、数セグメント毎に 1 回送ることでオーバー ヘッドを制御する ◦ 全てのセグメントの正当性ではなく、多くのセグメントの正当性で判断する 現行の C2PA の仕様に対する変更 の必要性 • 現行の C2PA の ISO BMFF に対する仕様では、C2PA 情報作成のためにアセット 全体のハッシュが必要 ◦ アセット全体ではなく、セグメントベースでの生成＋イベントメッセージでの配信 PoC 結果
150. PoC 結果
151. 超低遅延ライブ配信とそれに関連する技術の標準規格化 収益性を持った超低遅延ライブ配信を実現する 標準規格の組み合わせ • 超低遅延ライブストリーミング ◦ DASH 6th Edition - L3D-DASH（2 秒程度の遅延） • パーソラナイズド／ In-Content 広告 ◦ DASH 6th Edition - Alternative MPD Events（広告トリガー） ◦ SCTE 214-1（L 字などオーバーレイ広告） ◦ CTA 5004-A CMCDv2（広告ビーコン） • テレメトリー ◦ CTA 5004-A CMCDv2（監視／KPI ログ）
152. 超低遅延ライブ配信とそれに関連する技術の標準規格化 収益性を持った超低遅延ライブ配信を実現する 標準規格の組み合わせ • 超低遅延ライブストリーミング ◦ DASH 6th Edition - L3D-DASH（2 秒程度の遅延） • パーソラナイズド／ In-Content 広告 ◦ DASH 6th Edition - Alternative MPD Events（広告トリガー） ◦ SCTE 214-1（L 字などオーバーレイ広告） ◦ CTA 5004-A CMCDv2（広告ビーコン） • テレメトリー ◦ CTA 5004-A CMCDv2（監視／KPI ログ） オープンな標準規格かつ 数秒程度の超遅延で 最先端の広告技術を扱え モニタリングも可能
153. 超低遅延ライブ配信とそれに関連する技術の標準規格化
154. 超低遅延ライブ配信とそれに関連する技術の標準規格化 DASH 6th Edition - L3D-DASH https://speakerdeck.com/cyberagentdevelopers/ibc-2024-report?slide=206
155. 超低遅延ライブ配信とそれに関連する技術の標準規格化 CTA 5004-A CMCDv2 https://speakerdeck.com/cyberagentdevelopers/nab-show-2025-report?slide=173
156. 超低遅延ライブ配信とそれに関連する技術の標準規格化 CTA 5004-A CMCDv2 https://speakerdeck.com/cyberagentdevelopers/nab-show-2025-report?slide=173
157. 超低遅延ライブ配信とそれに関連する技術の標準規格化 <EventStream schemeIdUri= "urn:mpeg:dash:event:alternativeMPD:insert:2025" value="ad-break-1" timescale="1000"> <Event id="ad1_insert" presentationTime="10000"> <InsertMPD xmlns= "urn:mpeg:dash:event:alternativeMPD:2025"> <MPDURL value= "http://adserver.com/E.alt.mpd?ad=42&lang=en"/> </InsertMPD> </Event> </EventStream> Alternative MPD による Server-Guided Ad Insertion
158. 超低遅延ライブ配信とそれに関連する技術の標準規格化 超低遅延 OTT ストリーミング 通常の OTT ストリーミング 地上デジタル テレビ放送
159. 超低遅延ライブ配信とそれに関連する技術の標準規格化 超低遅延 OTT ストリーミング 通常の OTT ストリーミング 地上デジタル テレビ放送 地上デジタル テレビ放送より 低い遅延
160. エンターテイメントエコシステムを作る 広告戦略と技術
161. 広告挿入技術の進化 - SSAI から SGAI へ 現在の状況と 5年後の予測 • 現在: SSAI 95% / SGAI 5% • 5年後: SSAI 5% / SGAI 95% 理由: レイテンシ削減 + 柔軟性向上 方式 レイテンシー 処理場所 利点 SSAI 1,000セッション: 2秒 100,000セッション: 10秒 サーバー側でマニフェスト操作 プライバシー保護既存プレーヤー対応 SGAI 大幅削減 サーバー誘導+クライアント実行 スケーラビリティ高度なフォーマット対 応 標準化への動き • IAB: 決定・取引(OpenRTB、VAST) • SVTA: シグナリング、STAI(測定) • CTA Wave: CMCD V2、プレイヘッドレ ポート 実装事例 • Ateme: カスタムHLSタグでL字・サイドバイ サイド対応 • Harmonics: パリ五輪・FIFA W杯決勝 1,500万同時接続 • G-mana: A/Bテストで広告在庫+30%改善 (Google共同) 課題 • SGAIは測定標準が未整備 (プロプライエタ リ手法が必要) • レガシープレイヤー対応のため SSAIは無 期限に必要
162. AIによるコンテキシャル広告の進化 1. AIコンテンツ解析技術 マルチモーダル分析 - 映像・音声・メタデータの統合解析 - リッチメタデータの自動生成 - 最適な広告挿入タイミングの自動判定 2. AIターゲティングの高度化 3. Mobian：次世代ソリューション コンテクスチュアルインテリジェンス - ペルソナベースの視聴者分析 - 複数シグナルの統合による高度なマッチング - ブランドセーフティの自動確保 4. シグナル分析の仕組み 視聴者シグナル （視聴履歴・行動パターン・デバイス） コンテンツシグナル （シーン分類・感情検出・音声解析） コンテクストシグナル （時間帯・視聴環境・イベント） AI統合分析 最適な広告体験の設計 ABEMAへの適用 - 恋愛番組: 感情ピークシーンでの最適化 - スポーツ: 試合展開連動の動的挿入 - 効果: 広告効果向上 + ブランドセーフティ確保 従来型 AI主導型 キーワードマッチング 多次元シグナル分析 静的セグメント リアルタイム最適化 デモグラフィック ペルソナ ×コンテクスト
163. 広告フォーマットの進化とエコシステム設計 1. 新しい広告フォーマット 高度な表示形式 (SGAI対応) TiledMedia - 複数視点広告技術 - F1と同じ技術を広告に応用 - 5ユーザー同時に5種類の異なる広告配信 - ユーザーがリサイズ・非表示可能(広告主制御可) - AWS MediaTailor、YoSpace統合済み G-mana - ノンストップコンテンツ収益化 広告ブレイクなし24時間放送(ビッグブラザー等)への挿 入 ユーザー毎にストリームをずらして個別広告配信 体験を損なわない広告の実現 コンテンツ 広告 コンテンツ継続+広告 サイドバイサイド PIP オーバーレイ/バナー 2. クリエイティブの進化 生成AIによるリバージョンニング • アドレッサブルキャンペーン向け大量バリエーション生成 • 昼→夜変換、数千フレーム自動追加 • 人間監視による品質維持は必須 リアルタイムパーソナライゼーション • 視聴者シグナルベースの動的メッセージ変更 • 機械学習による個人レベル最適化
164. メディアとエンターテインメントを 大きく変えるデータ技術の潮流
165. データ技術の潮流を踏まえた結論 ライブのイベントデータ 広告挿入で必要なものから整備を進め る。 ビデオのレコメンド向けコ ンテンツ分析 感情分析を起点として初期構築し、活 用状況を見ながら拡充する。 ストリームでのログ連携 カスタマーサポートで重要なユーザー を救う目的で整備する。
166. データ関連の事例の整理 事例 目的 ストリームイベントデータ 広告挿入（ワーナーブラザース・ ディスカバリー, Harmonic, G-mana） 広告収益化 感情分析データ レコメンド（ワーナーブラザース・ディ スカバリー, Vionlabs) 広告収益化、サブスク継続 ストリームユーザーログ 不具合を迅速に解決するためのAI 支援 (AWS, DAZN, Hydrolix) サブスク継続 Harmonic: SSAIの全般的なソリューションを提供 G-mana: イベント駆動型パーソナライズSSAI基盤を提供 Vionlabs: ビデオ分析SaaSを提供 Hydrolix: ストリーミングログ分析基盤を提供
167. 何がどう変わるのか ライブ ビデオ ユーザーサポート 変化前 手動の広告挿入 同ジャンルのコンテン ツが主軸 複数回の対話、遅い対 応時間 変化後 イベント駆動広告挿 入 ジャンルを超えたコン テンツの提案 迅速な原因特定と解 決 一貫したスムーズな体験を通じて、ユーザーに高い価値を提供する方向性
168. 付与対象データごとの論点補足（コンテンツ） スポーツ等ライブで、何が起こったかを記録したメタデータは、大規模かつざっくりしたも のであれば人力で入力しても賄え、小規模もしくは詳細なものは自動入力が今後必要 になる（AWS, Google Cloud）
169. 付与対象データごとの論点補足（サステナビリティ） 現状、似たようなコンテンツを、似たようなモデルで別々で処理しないといけない非効率 性がある。もし、ライブ、ビデオ業界の垣根を越え、グローバルコンテンツIDと、標準化さ れた分析手法が確立すれば、分析結果を共有でき、環境持続可能性が高まる。 IBC2025 Session Summary: The Responsible Media Revolution: Data-driven Sustainable Infrastructure IMDb: Ratings, Reviews, and Where to Watch the Best Movies &amp; TV Shows
170. 付与対象データごとの論点補足（ユーザー体験） • バッチ連携データ ◦ KPI集計はこちらが本流で、データチームはここに目が行きがちである。 • ストリーム連携データ ◦ 複数社のデモを通じて、間違いなく今後の注力ポイントであると感じた。 ◦ カスタマーサポートや障害対応の際に備え、必要なコストをかけ整備し、 顧客満足向上を目指そうとしている。 バッチ処理 基本的な集計処理 効率的でスケーラブル 即時性には欠ける ストリーム処理 付加的な集計処理 負荷予測が必要 即時性を担保出来る
171. 具体的な導入イメージ • ライブはサッカーのハーフタイムや、ゴールのタイミングをストリームに記録し、それ に基づいてL字フォーマットの広告挿入をしたり、ビデオ切り出し時に参照出来るよ うになる。 • ビデオはジャンルの垣根を超えた、興味のあるコンテンツへの出会いを今までにな い軸で提案出来る（担当者の知らないような類似性を使えるため） • ユーザーログのストリーム連携は、問い合わせに対して迅速に返答出来るようにな る（プロバイダーの問題、自宅回線の問題、我々側のサーバーの問題等）
172. 標準規格化する新しい表現技術
173. 比較的新しい表現技術 • XR ◦ ライブ・コンテンツにおける体験の拡張 • メタバース／アバター ◦ XR - AR - メタバース上で共有可能な体験
174. XR がスポーツ・コンテンツにもたらす可能性 ライブ・コンテンツにおける体験の拡張 特にスポーツにおいては従来の映像では体験することができない スリリングな没入感がある体験をファンに提供できる無限大の可能性 Photo taken by Chris Chow @ Unsplash
175. XR が抱えている 4 つの課題 • 大規模配信 ◦ 没入感を十分に得られるレベルの品質でとてつもなく多くのファンに配信する難しさ • 帯域幅と忠実な表現精度のバランス ◦ ライブ配信ではこのバランス制御に安定的にコンテンツを伝送できるかがかかっている • 技術的な将来性の保証 ◦ 変化が速い技術分野では将来的にも長く使える技術は少ない • ベンダー・ロックインの回避 ◦ プロプライエタリに特有のプラットフォームに閉じて開発されている技術も多い
176. XR が抱えている 4 つの課題 • 大規模配信 ◦ 没入感を十分に得られるレベルの品質でとてつもなく多くのファンに配信する難しさ • 帯域幅と忠実な表現精度のバランス ◦ ライブ配信ではこのバランス制御に安定的にコンテンツを伝送できるかがかかっている • 技術的な将来性の保証 ◦ 変化が速い技術分野では将来的にも長く使える技術は少ない • ベンダー・ロックインの回避 ◦ プロプライエタリに特有のプラットフォームに閉じて開発されている技術も多い 課題に対する高い解像度を持つ 有識者による標準規格が求められる
177. OpenXR API Khronos が開発する標準 API • デバイス網羅性を意識した技術 設計 • ゲームや XR 分野に適用
178. OpenXR API によるマルチプラットフォーム開発 アプリケーションエンジンとデバイス種別ごとに それぞれ異なるコードを書いて実装
179. OpenXR API によるマルチプラットフォーム開発 アプリケーションエンジンとデバイス種別ごとに それぞれ異なるコードを書いて実装 複数のアプリケーションエンジン／デバイスで OpenXR API を介した共通コードで実装
180. OpenXR API を採用するデバイスとエンジン
181. OpenXR API を採用するデバイスとエンジン オープンソース OpenXR ランタイム
182. OpenXR API を採用するデバイスとエンジン
183. OpenXR API を採用するデバイスとエンジン • 相互運用性があり、多くの視聴者にリーチ可能 • 技術的な将来性の保証も高い • 透明性が高く、ベンダー・ロックインがない
184. アバターの重要性 • カメラに映りたくないユーザーがアイデンティティを表現 したコミュニケーションを 可能にする手段 ◦ カスタマイズもでき、自分のありたい姿を表現可能 • 視線やジェスチャー などリアルコミュニケーションには大事な役割を果たす細かな 表現を可能 ◦ リアルタイム・視線トラッキングによるアバターのアニメーション • 特に 3D アバター ◦ XR - AR - メタバース上で共有可能な体験 を伴ったコラボレーションが可能に なる
185. アバター技術が抱えている課題 メタバースの断片化 1 つのサービスのアバターを別のサービスで 利用できない • アイデンティティをサービスごとに再作成 する必要 ◦ 仮想コミュニティでの関係性も サービスに閉じられる
186. アバター技術が抱えている課題 メタバースの断片化 1 つのサービスのアバターを別のサービスで 利用できない • アイデンティティをサービスごとに再作成 する必要 ◦ 仮想コミュニティでの関係性も サービスに閉じられる どのサービスでも同じアイデンティティを表現できる 普遍的なアバター形式が求められる
187. アバターの重要性 • カメラに映りたくないユーザーがアイデンティティを表現 したコミュニケーションを 可能にする手段 ◦ カスタマイズもでき、自分のありたい姿を表現可能 • 視線やジェスチャー などリアルコミュニケーションには大事な役割を果たす細かな 表現を可能 ◦ リアルタイム・視線トラッキングによるアバターのアニメーション • 特に 3D アバター ◦ XR - AR - メタバース上で共有可能な体験 を伴ったコラボレーションが可能に なる
188. アバター技術が抱えている課題 メタバースの断片化 1 つのサービスのアバターを別のサービスで 利用できない • アイデンティティをサービスごとに再作成 する必要 ◦ 仮想コミュニティでの関係性も サービスに閉じられる
189. アバター技術が抱えている課題 メタバースの断片化 1 つのサービスのアバターを別のサービスで 利用できない • アイデンティティをサービスごとに再作成 する必要 ◦ 仮想コミュニティでの関係性も サービスに閉じられる どのサービスでも同じアイデンティティを表現できる 普遍的なアバター形式が求められる
190. ARF ARF = Avatar Representation Format • MPEG による相互運用可能な標準規格 • 3D アバターの保存、伝送、アニメーションに関する情報を標準化 • 準拠するプラットフォームでは同じように動作可能
191. ARF の仕組み ARF の 2 つのコア要素 • Base Avatar Format ◦ アバターの外見を定義 ◦ ジオメトリ／テクスチャ／骨格情報 • Animation Stream Format ◦ アバターの動きを定義 ◦ 表情／ジェスチャー情報 JSON 形式の ARF Document で表現
192. ARF アーキテクチャ外観
193. ARF アーキテクチャ外観 Animation Stream Format OpenXR API と互換性があ ると関節のポーズアニメー ションとブレンドシェイプアニ メーション
194. ARF アーキテクチャ外観 Animation Stream Format OpenXR API と互換性がある と関節のポーズアニメーショ ンとブレンドシェイプアニメー ション
195. ブレンドシェイプ アニメーション • パラメータを調整するだけで 複雑な表情を作り出す ◦ weight = 0 → 無表情 ◦ weight = 0.5 → 微笑 ◦ weight = 1 → 満面の笑顔
196. ARF が拡張する 5G の未来 3GPP（移動体通信システムの国際標準規格策定プロジェクト）のワーキンググループで アバター通信とメタバースなど XR サービスの要件を 2021 年に定義 • 3GPP Release 18 仕様に「AR calls（拡張現実通話）」 • 3GPP Release 19 仕様ではメタバースのユースケースを拡張 ◦ 特定の地理的・物理的な場所に結びついたメタバース体験を実現するための「 Localized Mobile Metaverse」 • 3GPP SA4 で ARF 採用 ◦ コーデックやアプリケーション層のプロトコル、マルチメディアサービスの標準化を担当するワーキンググループ でアバター通信のためのフォーマット（ ARF）／シグナリング／伝送などの手段を指定
197. ARF が拡張する 5G の未来 3GPP（移動体通信システムの国際標準規格策定プロジェクト）のワーキンググループで アバター通信とメタバースなど XR サービスの要件を 2021 年に定義 • 3GPP Release 18 仕様に「AR calls（拡張現実通話）」 • 3GPP Release 19 仕様ではメタバースのユースケースを拡張 ◦ 特定の地理的・物理的な場所に結びついたメタバース体験を実現するための「 Localized Mobile Metaverse」 • 3GPP SA4 で ARF 採用 ◦ コーデックやアプリケーション層のプロトコル、マルチメディアサービスの標準化を担当するワーキンググループ でアバター通信のためのフォーマット（ ARF）／シグナリング／伝送などの手段を指定 OpenXR x ARF x 5G で電話と同じように アバターを用いた没入感が高いコミュニケーションの未来
198. まとめ • グローバルのメディア企業は見通し不透明な市場感の中でイノベーションに投資するジレンマを抱えている • 『DVB』と 5G マルチキャスト／ブロードキャストは融合を進め、よりユビキタスな放送／配信を実現していく • メディア業界の事業戦略トレンドは、デジタルファースト化／ビジネスモデル多様化／データ駆動意思決定、という 3 つの軸 で転換している • AI の進化により、プリプロダクションから配信やマネタイズまで各領域でインパクトが大きいユースケースが示され、同時に各 メディア企業の技術的な採用哲学も確立されていっている • 特に、スポーツコンテンツの AI とイベントデータによる効率化と更なる高品質化、高収益化を実現できる可能性を示す戦略 や事例は注視するべき • 地上波からの切替が進むヨーロッパでは、スポーツコンテンツを含めたライブ動画配信の重要度と緊急度が年々増す背景も あり、より安定より安全に配信できるライブ動画配信の新技術が規格化されている • グローバルに見るデータ技術の潮流を踏まえ、ライブのイベントデータ、レコメンド向けコンテンツ分析、ストリームでのログ連 携に投資するべき • XR やアバターなどの新しい表現も標準規格化され、技術的にも事業的にも投資が容易になるタイミングが来つつある
199. ありがとうございました