放送局によるインターネットサービスの本格普及に向けては、ネット動画配信においても放送のような安定性や信頼性の確保が求められる。本稿では、ネット動画配信の安定化・低遅延化やコンテンツの信頼性確保に関する技術・標準化動向を解説するとともに、技研の研究開発事例を紹介する。

１．はじめに

インターネットにおける動画配信が始まった1998年ころは、ITベンダーによるMMSP（Microsoft Media Server Protocol）、RTSP（Real Time Streaming Protocol）、RTMP（Real Time Messaging Protocol）などの動画配信プロトコルにより、専用のサーバーから視聴端末にプッシュ型^＊１で配信される方式が主流であった。その後2006年ころから、上記のような動画配信プロトコルは用いずに、テキストや画像といったウェブページを構成するファイルと同様のHTTP（Hypertext Transfer Protocol）を利用して動画を配信するプル型^＊２のHTTPストリーミング方式への移行が進んだ。この方式は、動画配信用の専用のサーバーを必要としないことに加え、ウェブサイトの高速化・大規模化に利用されるCDN（Contents Delivery Network）をそのまま適用できることから、従来の動画配信システムと比べて低コストかつ大規模な配信が実現可能となった。さらに2008年ころから、このHTTPストリーミングにネットワークの混雑状況に応じて動的に映像品質を切替える機能を搭載することで安定した配信を実現するHTTPアダプティブストリーミングと呼ばれる方式が利用され始めた ^1）。今日ではその代表である国際標準のMPEG-DASH（MPEG Dynamic Adaptive Streaming over HTTP）^2）やApple社が開発したHLS（HTTP Live Streaming）^3）が主流となっている。こうした技術の登場により、今日の動画配信サービスの爆発的な普及につながった。

しかし、これらの方式にもデメリットが存在し、その一番の代償が遅延の増加である。RTSP等のUDP（User Datagram Protocol）ベースの配信方式が約１秒程度の遅延での配信が可能であったのに対し、HTTPアダプティブストリーミングに移行した当初は数十秒程度の遅延が当たり前であり、現在でも一般的な“リアルタイム”配信サービスで10秒以上の遅延が生じているのが普通である。同じ映像をテレビとネットなど異なるメディアで同時に見るわけではないので気にならないという意見も見られるが、例えばネットでスポーツを観戦しているときに、隣の家からの歓声やSNSでの投稿などによって、映像よりも先に結果が分かってしまったというのもよくある話である。これは、異なるメディアで視聴しているユーザー間におけるコミュニケーション機会の喪失につながっているとも言えるのではないだろうか。また、多様な伝送路を活用して、あらゆる場面に信頼できる情報を届けることを目指す我々にとって、映像・音声の品質確保に加え、遅延の短縮は極めて重要な課題である。

一方、インターネット上では、フェイクニュースなどの偽情報・誤情報がSNSで拡散し社会問題となっている。特に、国政選挙や大規模な自然災害の発生時においては、偽情報・誤情報を含むコンテンツが数多く流通するため、ユーザーは膨大なネット上の情報から真実の情報を見極めなければならない状況に直面している。また、生成AIを用いると、放送局になりすました偽動画を簡単に作成できてしまう。誰もが発信者になり得るオープンなインターネット上では、発信者の特定は困難であるため、放送局が発信するコンテンツの信頼性確保は重要な課題である。

本稿では、これらの課題に対し、放送と同様に信頼できる情報を確実に届ける動画配信サービスの実現に向けた技術要素として、動画配信の安定・低遅延化に関する技術と、コンテンツの信頼性確保に関する技術の最新動向を解説するとともに、技研の開発事例を紹介する。

２．動画配信の安定化・低遅延化

本章では、動画配信の安定化・低遅延化にまつわる技術動向について述べる。まず、現在主流のMPEG-DASHとHLSについて概説し、遅延が発生する要因やその回避方法について解説するとともに、視聴の安定化に重要なアダプティブビットレート制御技術に関する動向を紹介する。さらに、より低遅延化が期待できるプッシュ型による低遅延配信方式に加え、動画視聴プレーヤー技術の動向についても解説する。

２．１　MPEG-DASHとHLSの概要

MPEG-DASHとHLSは概念的には大きな違いはなく、エンコードした動画を数秒単位に分割した「セグメント」と呼ばれる動画ファイルと、動画のエンコードパラメーター（符号化方式やビットレートなど）や、セグメントの情報（セグメントの分割単位や取得先URLなど）といったストリーミング再生に必要な情報を記述したメタデータファイルである「マニフェストファイル」で構成される。１図にアダプティブストリーミングの動作概要を示す。動画サービスの提供者は、あらかじめ１つの映像素材から品質（解像度やビットレート）が異なる複数の動画を生成し、それらを時刻の切れ目で揃そろえてセグメントに分割するとともに、すべての動画の情報を含むマニフェストを生成する。これらのファイルはWebサーバーに供給される。視聴端末は、まずWebサーバーからマニフェストを取得し、セグメントの構成を把握する（１図①）。続いて、ネットの混雑状況や視聴環境（端末の画面解像度など）に合わせた品質のセグメントを適宜選択して受信し（１図②）、分割した順番どおりにつなぎ合わせて再生する（１図③）。この動作を繰り返すことで、絶えずネットの混雑状況が変化していても途切れることなく視聴を継続できる。

セグメントのフォーマットは、MPEG-DASHではISO-BMFF（ISO Base Media File Format）^4）（いわゆるmp4形式）が一般的に利用される。HLSは、初期バージョンはMPEG-2 Transport Stream^5）（TS形式）のみを採用していたが、2016年にmp4にも対応した。さらにmp4をベースとし、セグメント形式の共通化を目的とするとともに低遅延化にも効果があるCMAF（Common Media Application Format）^6）が2018年に規格化され、現在ではMPEG-DASHとHLSの両方式でCMAFを利用可能となっている。動画配信サービスの相互運用性の向上を目的とした業界団体であるCTA-WAVE^＊３では、CMAFによるMPEG-DASHとHLSの相互運用性を図るためのエンコードやセグメント化について規定している^7）。ただし、実際の配信環境においてHLSでは過去バージョンのOSとの互換性を確保するため、現在でもTS形式を利用しているケースが多い。マニフェストは、MPEG-DASHではMPD（Media Presentation Description）と呼ばれるXML（Extensible Markup Language）形式である一方、HLSではm3u8と呼ばれるテキスト形式である。両者に互換性はないが、多くのケースにおいて同様の情報を記述可能である。

２．２　遅延の要因とその対処方法　～CMAF、HTTPチャンク伝送、Fetch ～

遅延の要因とその改善手法について、２図に示すライブストリーミングの構成要素を①ストリームの生成、②伝送・中継、③受信の３段階に分けて説明する。

セグメントに用いられるmp4形式は、３図に示すとおり、先頭から「データサイズ、データ種別、データ」が連結されたBox構造と呼ばれるフォーマットとなっている。このため、データを作り終えないとBoxの先頭にある“サイズ”が確定せず、伝送することができない。ここが遅延のそもそもの原因であり、データが大きいほど待ち時間が長くなる。つまり、“データ”を小さくすることにより遅延も短縮できることになる。４図にデータを小さくする２種類の方法を示す。

４図①は、セグメントファイル自体を細かく分割する手法である。例えば６秒のセグメントを２秒×３ファイルに分割することにより、待ち時間は1/3に短縮できる。しかし一般にセグメントはGOP（Group of Pictures）^＊４単位で構成されていることから、GOPのサイズも小さくする必要がある。GOPのサイズを小さくすると画質の低下につながるため、放送と同様の0.5秒程度が実用的な下限になる。また、分割により増えたセグメントファイルの数だけ視聴端末によるHTTPリクエスト数が増加するため、CDNの負荷が高くなり視聴安定性の低下につながる可能性がある。一方、４図②は、セグメントファイルの中身を細かく分割する手法であり、このような運用方法を想定して規格化されたのがCMAFである。セグメントファイルがGOP単位で構成されること自体は同様であるが、そのGOPをより細かく、例えばフレーム単位にまで分割した「CMAFチャンク」という形式でデータを取り扱うことができる。これにより、セグメントファイル全体が出来上がるのを待つことなく、CMAFチャンク単位で伝送できるため、ライブストリーム生成の遅延は数フレームレベルにまで短縮が見込めるようになった。また、セグメントファイルの数が変わらないため、視聴端末からのリクエスト数増加による視聴安定性の低下も避けることができる。

次に２図②のライブストリームの伝送・中継の低遅延化について説明する。HTTPのデータ構造はメタデータであるHTTPヘッダーと、伝送するデータに相当するメッセージボディーで構成される。通常は５図①のようにHTTPヘッダーにデータ全体の“サイズ”を記載するため、せっかくCMAFチャンクに分割してもセグメント全体がそろうまで伝送できない。そこで、５図②のようにHTTPヘッダーのパラメーターであるTransfer-Encodingを“chunked”に設定するHTTPチャンク伝送方式（CTE：Chunked Transfer Encoding）を用いる。この方式はHTTPの接続を確立した状態で、「サイズ、データ」からなる“チャンク”の組み合わせで複数回に分けて次々と伝送することが可能な方式であり、CMAFチャンク単位の伝送と親和性が高い。これによりエンコーダー・CDN・視聴端末まで一貫してHTTPチャンク伝送をすることにより、極力低遅延で配信することが可能となる。

次に２図③の視聴端末での受信における低遅延化について、６図により説明する。Webアプリを構成するJavaScript^＊５におけるHTTP通信に長らく利用されていたXMLHTTPRequest^8）＊６API（Application Programming Interface）^＊７は、ファイル全体の受信が完了するまで、受信したデータを処理することができない仕様となっている。そのため、６図①に示すように、せっかくチャンク単位で次々と伝送しても、セグメントファイル全体が到着するまで受信バッファーにデータを入力することができなかった。一方、2015年ころから導入され始めたFetch API^9）＊８は、より細かい単位でのデータ処理が可能なように設計されているため、６図②に示すようにCMAFチャンク単位で順次バッファーにデータを入力することができるようになった。これにより再生開始までの待ち時間が短縮されるだけでなく、無駄な待機時間が発生せず、常にバッファーにデータを入力し続けることができるため、バッファーの枯渇に備えて不要に多くのセグメントをバッファーにため込む必要もなくなり、より低遅延化が見込める。

以上の３要素を組み合わせた方式はCMAF-ULL（Ultra Low Latency）と呼ばれ、MPEG-DASHやコミュニティベースのHLS実装であるLHLS^10）で利用可能である。通常の配信では、サーバー上にセグメントが完全に出来上がった段階でそのセグメントへのアクセスが可能となるが、CMAF-ULLに対応したサーバーでは作成中のセグメントにもアクセス可能となる。また、マニフェストについても、作成中のセグメントのURLへのアクセスを可能とする記載がある以外は、通常の配信と違いはなく、マニフェストの更新頻度がCMAFチャンク数によって影響を受けることもない。そのため、CMAFチャンクの細かさに応じた低遅延化が可能となる。なお、CMAF-ULLに非対応の視聴端末でも、通常の配信として受信することが可能である。

一方、Apple社が開発したHLSの低遅延化対応仕様としては LLHLS（Low Latency HLS）^3）がある。この方式ではマニフェストにセグメントのURLに加え、CMAFチャンクそれぞれに対するURLも併記され、視聴端末が低遅延で受信するためにはCMAFチャンク単位で個別にHTTPリクエストをすることになる。CMAFチャンク数に応じてマニフェストの更新や視聴端末のリクエスト回数が増加するため、CMAF-ULLほど細かくチャンク化できない課題はあるが、CMAF-ULLに非対応のサーバーでも低遅延配信が可能であることや、セグメント単位でリクエストすることによりLLHLS非対応の視聴端末でも通常のHLSとして受信することが可能である。

CMAF-ULLについては、放送と同程度の遅延でスマホやパソコンに異なるアングルの映像を配信し、放送とネット動画を連携して視聴できるサービスに活用した例がある^11）。また、当所でもクラウドベースのリニア配信システムに適用している^12）。本システムは、4K映像のエンコードから視聴端末までエンドツーエンドで約２秒の遅延で配信可能であることから、放送の同時配信に用いる伝送方式として十分な低遅延性を備えている。

２．３　アダプティブビットレート制御技術

アダプティブビットレート（ABR：Adaptive Bit Rate）制御技術は、視聴端末における映像品質や途切れにくさを左右する極めて重要な機能である。そもそも、視聴端末に大きなバッファーが必要とされているのは、ネットワークの混雑などの影響により、セグメントが時間どおりに到着する保証がないためである。例えば、６秒のセグメントの受信中に６秒経過してしまった場合、もう少し我慢して受信し終えるまで待つか、あるいは見切りをつけて現在のセグメントの受信をキャンセルし、同時間帯のビットレートが低いセグメントを要求し直すかを判断するのは難しい。そのため、いくつかのセグメントをバッファーに溜ため込んだ状態から再生を開始することで、低遅延性を犠牲にして安定性を向上させているのが現状一般的である。これは多くの場合、利用できるネットワーク帯域よりもビットレートの高いセグメントを要求してしまっているために起こる現象である。裏を返せば利用可能なネットワーク帯域を適切に把握し、それよりも低いビットレートのセグメントを受信し続ける限り、セグメントの到着が遅れることがなくなり、視聴が途切れることがなければ、バッファーも限りなく少なくできることになる。つまり、安定性の向上と低遅延化は同義であると筆者は考えている。

さまざまなABR制御技術が提案されており^13）、基本構成は７図に示すとおり現在利用できるネットワーク帯域を計測する帯域計測部（７図①）、帯域計測の結果から次のリクエストで利用できるネットワーク帯域を予測する帯域予測部（７図②）、推定した帯域の中で、ABRとして提供されている複数のビットレートの動画のうち、どのビットレートを要求するかを決定するビットレート選択部（７図③）からなる。VoD（Video on Demand）のように既に出来上がっている動画を視聴する場合は、TCP（Transmission Control Protocol）の性質上、利用可能な帯域を最大限に利用してセグメントを受信するため、セグメントの「データ量」と「受信開始から到着までの時間」との関係から利用可能帯域は比較的簡単に算出できる。一方、低遅延なライブ配信では状況は異なる。例えば６秒のセグメントをエンコードするのに６秒かかるため、受信にも６秒かかる。VoDと同じ方法で帯域を推定すると、エンコードビットレートが６Mbpsであれば、利用可能帯域は６Mbpsと算出されるし、0.5Mbpsであれば0.5Mbpsと算出されてしまう。よって、VoDとは異なる低遅延ライブ配信に対応したARB制御アルゴリズムが必要となり、さまざまな提案がなされている。７図①②において、セグメントの伝送におけるチャンク間の短い待ち時間も考慮した帯域計測を行うことで、セグメント単位の計測よりも帯域計測・帯域予測精度を向上する手法^14）をベースとして、７図③に帯域計測値・遅延・バッファー量およびQoE（Quality of Experience）値に基づくニューラルネットワークベースのアルゴリズムを導入するとともに、再生速度制御によるバッファー量の制御を行う手法^15）16）が提案されている。また、帯域計測や帯域推定を明示的に行わず遅延とバッファー量に基づくオンライン凸最適化によってビットレートを選択する手法^17）などが提案されている。これらのアルゴリズムをオープンソースのMPEG-DASHプレーヤーdash.js^18）やHLSプレーヤーhls.js^19）に組み込んで評価を行うとともに評価環境を公開している事例がある^20）。

さらに別のアプローチとして、視聴端末において正確にネットワークの状況を把握するのは困難であることから、通信機器からネットワークの状況を視聴端末にセキュアに通知する方法に関する議論^21）がインターネット技術の標準化を推進するIETF（Internet Engineering Task Force）で始まるなど、今後も快適な視聴体験の提供に向けてさまざまな検討が進められる予定である。

２．４　プッシュ型による低遅延配信方式　～WebRTC、Media over QUIC～

ここでは、これまで述べてきた視聴端末からサーバーにストリームを要求するプル型の配信方式とは異なり、サーバー側から視聴端末にプッシュ型でストリームを送信することによる低遅延配信方式について紹介する。

Webブラウザー間でリアルタイムに映像・音声通信を実現するWebRTC（Web Real-Time Communication）は、低遅延化に有効な技術であり、IETFで通信プロトコル^22）が、Webの標準化団体であるW3C（World Wide Web Consortium）でWebブラウザーのAPI^23）が規格化されている。数百ミリ秒の遅延で伝送が可能であり、近年ではZoom、Microsoft Teams、Google Meet 等のWeb会議ツールで広く活用されている。当所でも、360度映像のストリーミングコンテンツのテレビ上でのインタラクティブな視聴を可能とするため、ユーザーの操作に応じた映像処理をクラウド上のレンダラーで実行し、WebRTCによりテレビに低遅延で伝送するシステムを開発した事例がある^24）。一般的なCDNを活用できないことから大規模配信には向かないとされていたが、メディアストリームを中継するSFU（Selective Forwarding Unit）機能を用いてサーバーを多段に接続することにより数万規模のユーザーに配信する検証も行われている^25）。一方、視聴端末となるWebブラウザーの実装がリアルタイム双方向通信に特化されているため、遅延した瞬間にすぐスキップするといった現象が発生するなど、実装に依存する部分が課題となり、一方向通信である動画視聴で用いるにはユーザーへの提示品質の制御が難しいなど安定性の課題も指摘されている^{26）27）28）}。

また、高速だがデータ到達の保証がないUDPに、TCPのような輻ふく輳そう制御の仕組みを組み込むことで、低遅延性と信頼性を兼ね備えたQUIC（Quick UDP Internet Connections）^29）を活用した通信プロトコル等の規格化が進行している。QUICには、接続確立までの高速化やTLS（Transport Layer Security）による通信の暗号化に加え、TCPに存在するIPパケットが欠落するとそれ以降のデータが届いていても処理が進まないヘッドオブラインブロッキング（HoL：Head of Line Blocking）と呼ばれる現象を回避できる機能などが備わっている。このような利点をHTTPに取り入れるため、トランスポート層をTCPからQUICに置き換えたHTTPの３番目のメジャーバージョンであるHTTP/3^30）が、2022年にIETFで規格化された。同様にWebブラウザーとサーバー間での双方向通信のための規格であるWebSocketにQUICの利点を活用したいという背景から、HTTP/3をベースとして低遅延な双方向通信を実現するWebTransportの規格化がIETFとW3Cで進められている^{31）32）33）}。

ここで、当所が取り組んでいるWebTransportを活用したプッシュ型配信と、サーバーサイドでの配信品質制御を組み合わせた低遅延配信技術について紹介する。システムの実験構成を８図に示す。本システムは、ライブエンコーダーで複数の品質の映像ストリームをフレーム単位でCMAFチャンク化し、CTEによりクラウド上のオリジンサーバーに伝送する。オリジンサーバーは受信したCMAFチャンクを即座に視聴端末が接続している配信サーバーに中継し、配信サーバーがWebTransportによって視聴端末にプッシュ配信することで低遅延配信を実現する。オリジンサーバーの中継機能にデータの送信先を動的に増減可能なPub/Subメッセージングモデル^＊９を導入することにより、配信規模に応じて配信サーバー数の増減が可能な構成としている。また、サーバーサイドでの品質制御におけるネットワーク帯域推定には、第２．３節で述べたアプリケーションレイヤーのパラメーターを利用する手法とは異なり、QUICレイヤーの通信パラメーターを利用して推定精度の向上を試みている点が特徴である。本手法は、映像のGOPの中でも情報量が大きいキーフレーム送信時のQUICの輻輳制御情報を基に送信可能帯域を推定し、推定値以下で最も高品質の動画ストリームを選択して配信することで安定かつ高品質な配信を実現した。８図の構成で、端末１の受信バッファー時間を300msに設定し、ネットワークに周期的に帯域制限をかけて配信実験を行ったところ、９図のようにカメラ映像から視聴画面までの遅延が約400msであることを確認した。また10図のように、サーバーで算出した帯域推定値が帯域制限値と近い値となっていること、および配信品質が帯域推定値を超えない最大の品質に制御できることを確認した^34）。

さらに注目すべき動向として、ライブ配信・オンラインゲーム・会議等のユースケースに対応する、低遅延なメディア配信方式として、11図に示す、ライブ映像のアップロード（11図①）、サーバー間の中継（11図②）、端末への配信（11図③）の全フローにQUICを活用するMOQ（Media over QUIC）の規格化が進行している^35）。Facebook（Meta）によるライブ映像のアップロード方式であるRUSH^36）、Twitchによる低遅延ライブ配信方式であるWarp^37）、Ciscoによる端末間・サーバー間のデータリレー方式であるQUICR^38）といった、それぞれQUICを活用したプロトコルの提案が基となっている^39）。12図にプロトコルスタックを示す。現在、QUICおよびWebTransport 上でのメディア転送手法を規定するMOQT（Media over QUIC Transport）^40）と、ストリーミングフォーマットを規定するWARP Streaming Format^41）に分けてドラフト化が進められるとともに、 オープンソースの実装や検証が進められている^42）43）。なお、動画視聴プレーヤーは、MPEG-DASHやHLSでも活用される動画再生制御APIであるMSE（Media Source Extensions）^44）や、映像をフレーム単位で処理可能なAPIでありW3Cで規格化中のWebCodecs^45）等を活用して開発することになるが、ユーザーへの提示品質制御等はサービス提供者側で設計・開発して組み込む必要がある。このような機能も含めたオープンソース実装等が今後出てくるものと考えられるが、実装の自由度は低いが10年来の実績があるWebRTCか、今後の発展が期待されるMOQか、メディア配信にとってどちらが主流となるのか動向を注視したい。

２．５　動画視聴プレーヤー技術　～Media Source Extensions / Managed Media Source ～

ここではWebブラウザーにおける動画再生技術の動向について紹介する。現在、ほとんどの動画配信サイトでは、2013年にW3Cで標準化が開始された動作再生制御APIであるMSEが利用されている。MSEを用いることで、サービス提供者は、動画視聴プレーヤーをWebアプリとして開発することが可能となり、PC・スマホ・テレビなど多様なデバイスで共通の視聴環境を整えられるものと期待された。ところが、主要なデバイスではiPhoneのみがMSEを搭載せず、Webブラザーから独自のプレーヤーを呼び出す実装となっているため、視聴環境の共通化は実現しなかった。Apple社は、MSEを搭載しない主な理由として消費電力の大きさを挙げている。長らくこのような状況が続く中、Apple社は2023年６月にMSEを改善した新たなAPIであるMMS（Managed Media Source）を発表した^46）。MSEにおけるネットワークやメモリーの制御機構を改善することにより消費電力の抑制を実現しているとしておりiOS17.2以降で利用可能となっている。２つのAPIの名称は異なるが、利用方法に差異は少ないため、既存のMSE対応の動画視聴プレーヤーに軽微な修正を加えるだけで、MMSにも対応させることが可能である。これによりiPhoneを含めた共通の視聴環境を整えることがようやく可能となった（13図）。現在MMSは、MSEの次期バージョンを検討しているWGに提案され、標準化に向けた活発な議論が行われている。

これまでiPhoneはHLSのみに対応していたが、MMSによりMPEG-DASHを始めとする多様な動画配信方式への対応が可能となった。実際に、当所がオープンソースとして提供するMPEG-DASH視聴プレーヤーであるbasjoo.js^47）をMMSに対応させることでiPhoneでのMPEG-DASH動画の再生動作を確認している。また当所は、動画ストリームに任意のタイミングでトリガー信号（MTE：Media Timed Event）を挿入し、視聴端末にプッシュ通知することにより緊急情報を即時提示する技術の開発・検証^48）を行っている。iPhoneでMMSを活用することにより、他のデバイス同様にこのような技術の検証が可能となるなど、動画視聴制御に関する新技術の積極的な導入が可能となることが期待される。

３．コンテンツの信頼性確保

インターネット上の情報空間において、意図的または意図せずに、正確でない情報や誤った情報（フェイクニュース）を発信されることがある^49）。特に、生成AIを用いると、誰でも簡単に放送局になりすました偽動画を作成することが可能である。生成AI技術の進展により、偽動画の品質は年々向上しており、誰でも簡単に放送局になりすました高品質な偽動画を作成することが可能である。このため、放送局が発信する「正確な情報」と、偽情報の見分けが困難な状況となっている。その結果、ユーザーが「真実である」と信じてSNSで偽動画を拡散する、という事態が生じている。従来の電波による放送サービスの場合、誰が発信者であるかを知ることは容易であるが、インターネットは誰もが発信者になり得るオープンな世界であるため、発信者の特定は困難である。このため、放送局によるインターネットサービスでは、コンテンツの信頼性確保が重要な課題となっている。本章では、この課題を解決する手段の１つである来歴情報提示技術について解説する。

３．１　来歴情報提示技術

コンテンツの出どころや制作過程などの来歴情報をコンテンツに埋め込み、ユーザーに提示する来歴情報提示技術が2018年頃から検討され始めた。放送局などの発信者にとっては、ユーザーがコンテンツの信頼性を判断するための情報として、自身が発信したことの証明を示すものとなる。来歴情報が偽・誤情報対策として有効に機能するためには、来歴情報の付与技術が普及し、インターネット上に流通する多くのコンテンツに来歴情報が付与されることとともに、来歴情報に関する認知が拡大することが求められる。そこで、来歴情報提示技術に関する共通技術仕様の策定および普及を目的として、コンテンツの出どころと認証に関する国際標準化団体C2PA（Coalition for Content Provenance and Authenticity）が設立され、技術仕様が公開されている^50）。14図で示すように、C2PAではコンテンツに対し、制作者が撮影・編集・配信などの各工程において来歴情報およびデジタル署名を付与する。ユーザー側では、デジタル署名の検証によりコンテンツと来歴情報の改ざん有無を確認するとともに、来歴情報や署名者の情報をもとに、コンテンツの信頼性を判断する。

３．２　C2PAの概要

C2PAは、Adobe社、 Microsoft社、 BBCなどによって2021年2月に設立された、コンテンツの出どころと認証に関する標準仕様を策定している国際標準化団体である。C2PAの設立にあたり、基となった団体が２つある。１つはコンテンツの撮影から視聴までの過程において、コンテンツの出どころ（制作者）、編集履歴、著作権等の属性情報を提示するツールを開発し、ユーザーにコンテンツの信頼度を測る判断材料を提供することを目的に、Adobe社やTwitter社などが主導して設立したCAI（Content Authenticity Initiative）^51）である。現在はC2PAで標準化した仕様に基づいたツールを開発し、オープンソースソフトウェアの提供を通して、C2PA標準技術の普及を促進している。もう１つは、SNSにおけるデマを排除するため、ニュースコンテンツの出どころ（発信者）、および発信から視聴までの過程でコンテンツが改変されていないことを保証することを目的に、BBCやMicrosoft社などが主導し設立したProject Origin^52）である。これらの取り組みを統合し、The Linux Foundation傘下のJoint Development Foundationの標準化プロジェクトの１つとしてC2PAが設立された。放送局やカメラメーカー、IT企業など、コンテンツの制作や配信に関わる、インターネットにおける信頼できる情報発信に関心のある国内外の企業が多数参加している。なお、C2PAはCAIやProject Originが策定した要求条件やユースケースに基づいて技術仕様を策定しており、これら３つの団体は密接な関係にある。

C2PAの技術仕様では、来歴情報の付与方法や検証・提示方法などが定められている^53）。コンテンツ制作における「撮影」、「編集」、「配信」など、コンテンツに対するアクションを誰がいつ行ったかを、デジタル署名を用いて改ざん検知可能な形式でコンテンツのメタデータとして埋め込む。来歴情報が付与されたコンテンツに新たなアクションが加えられる際は、新しく生成された来歴情報を追記することで、ユーザーにコンテンツが届くまでのすべての過程を示す来歴情報を届けることができる。来歴情報にはデジタル署名の生成に用いた公開鍵証明書が含まれており、ユーザーは証明書に含まれる公開鍵を用いて署名を検証することにより、コンテンツおよび来歴情報の改ざんを検知できる（15図）。なお、C2PA仕様は、デジタル署名を検証することにより、コンテンツや来歴情報が改ざんされていないこと、および来歴を付与した人・組織が本物である（なりすましなどの詐称がされていない）ことを保証する仕組みであり、来歴情報の有無がコンテンツの真偽そのものや、来歴を付与した人・組織が信頼できるかどうかを判断するものではないため、ユーザー自身による判断が必要である。

３．３　C2PAの研究開発事例

C2PAの仕組みを導入するためには、コンテンツの制作・配信を行う事業者側、配信されたコンテンツを視聴するユーザー側のそれぞれの機器やソフトウェアがC2PAに対応していることが必要である。ソニー（株）は、C2PAの技術規格に対応したミラーレス一眼カメラを開発している^54）。カメラの撮影時にリアルタイムで静止画に署名付き来歴情報を付与するとともに、ソニーが提供する検証用サイトで来歴情報を検証・提示することが可能である。現在は静止画のみ対応しているが、今後の動画への対応が期待される。Adobe社は、C2PAに対応した動画編集ソフトPremiere Proを開発している^55）。本ソフトを用いて動画コンテンツを編集すると、どのような編集を行ったかを表す来歴情報がコンテンツに付与される。また、生成AIツール「Adobe Firefly」を用いて編集されたコンテンツには、生成AIを使用したことを表す来歴情報が付与される。このように、撮影・編集などコンテンツ制作のワークフローごとにC2PAの来歴情報をコンテンツに付与できる環境が整いつつある。一方、来歴情報が付与されたコンテンツをユーザーが視聴する際に、来歴情報を検証・提示する環境の整備も重要である。当所では、C2PAを前提とするエコシステム全体や要素ごとの課題抽出、ユーザーが実際にコンテンツの信頼性を判断するために重要な要素の調査・検証を目的に、C2PAに準拠した来歴情報をストリーミング用動画コンテンツに付与するシステム、およびコンテンツを再生しながら来歴情報をリアルタイムで検証・提示する動画視聴プレーヤーを試作した。来歴情報付与システムでは、CAIが公開しているRustライブラリー^56）を用いて、MPEG-DASH形式のストリーミング用動画コンテンツに来歴情報を付与する機能を実装した。動画視聴プレーヤーでは、当所で開発したMPEG-DASH動画視聴プレーヤーbasjoo.js^47）にCAIが公開しているJavaScriptライブラリー^57）を用いて来歴情報検証機能を組み込むとともに、検証結果をユーザーに提示する処理を追加した。ユーザー提示処理では、コンテンツの信頼性を判断する要素を分かりやすく提供することを目的に、以下に示す４つの機能を組み込んだ。なお、本プレーヤーはPCだけでなくスマートTV上でも動作可能である。

・来歴情報の有無の視覚的提示

来歴情報が付与されたコンテンツを再生する場合、C2PAの公式アイコンであるcrアイコンを画面右上に提示することで、来歴情報があることをユーザーに示す（16図(a)）。来歴情報が付与されていないコンテンツを再生する場合、crアイコンを提示しないことで、来歴情報がないコンテンツであることをユーザーが一目でわかるようにした。

・シークバーによる検証結果の提示

動画コンテンツが改ざんされていないかどうかの検証結果はシークバーで確認できる（16図(b)）。試作したプレーヤーはMPEG-DASHのセグメントごとに改ざん検知が可能であり、検証に成功したセグメントは青、改ざんが検知されたセグメントは赤、未再生のセグメントは灰色で表示することで、検証結果をユーザーに分かりやすく提示する。また、再生前であっても、改ざんされたセグメントをプレーヤーが読み込んだ際は、事前に改ざんの通知を行う機能も備えており、ユーザーは落ち着いて適切な対処ができる。

・来歴情報の提示

ユーザーの要求（crアイコンのクリックやリモコンのボタン押下）により、現在再生しているコンテンツの来歴情報を提示することができる（16図(a)）。検証に成功した来歴情報を実際に確認することで、コンテンツの出どころと制作過程を把握でき、コンテンツの信頼のための判断材料として活用することができる。

・改ざんの検知と注意喚起

セグメントの改ざんを検知した場合、文字とcrアイコンを用いてユーザーに通知する（16図(b)）。再生中のコンテンツが改ざんされている場合、偽・誤情報の可能性をユーザーに提示することで、コンテンツを注意深く視聴する、または、視聴をやめるなどの行動を喚起することができる。

４．まとめ

本稿では、放送のように安定性や信頼性の高い動画配信サービスの実現に向けた技術要素として、動画配信の安定・低遅延化に関する技術や、コンテンツの信頼性確保に関する技術の最新動向を解説するとともに、技研の開発事例について紹介した。引き続き、放送やインターネットを利用して、いつでも、どこでも、誰にでも、信頼できる情報をすばやく確実に届ける技術の研究開発を推進し、実用化に取り組んでいく。