同時視聴の追跡で CDN リーチングを防ぐ

OTT サービスを運営しているなら、画質、再バッファリング率、次の配信権契約に多くの注意を払っているでしょう。しかし、利益率をひそかに削る別の指標があります。一組の認証情報で、今、実際に何人がコンテンツを見ているかです。ここでいう「人」には、パスワードの共有者、ボットによる収集者、複数デバイスを使うヘビーユーザーも含みます。契約者数の成長グラフには出なくても、サーバー負荷には確実に現れます。

これは同時視聴数の追跡が担う領域です。適切に実装すれば、急増する CDN リーチングという問題に対抗する、最も実用的な手段の一つになります。

本記事では、CDN リーチングとは何か、なぜ友人や家族との「単なる」パスワード共有より深刻なのかを説明します。そして Momento のような低レイテンシのデータプレーンを使うリアルタイムの同時視聴管理サービスが、ユーザー体験を損なわずに不正利用を止める方法を紹介します。

CDN リーチング：自社インフラが支える海賊版配信

大まかにいえば、CDN リーチングは、事業者の費用で動く海賊版配信です。不正配信者は自前のインフラを立ち上げる代わりに、次のことを行います。

• 有効な URL と復号鍵を入手します。多くの場合、盗まれた正規アカウントや「転売」された正規アカウントを利用します。
• ボットや再配信プラットフォームでアクセスを自動化します。
• 大量の権限のない視聴者を、事業者の CDN エンドポイントへ誘導します。

CDN から見れば、このトラフィックはすべて正当に見えます。トークンは検証を通り、セグメントはキャッシュにあり、エッジノードはギガビット単位のプレミアムコンテンツを問題なく配信します。その相手は、サービスに料金を払っていない視聴者です。

調査会社 Kearney によれば、オンライン動画の海賊版は既に世界のメディア業界に年間約 750 億ドルの損害を与え、2028 年には 1,250 億ドルに達する見込みです。CDN リーチングは、この増加を支える手口の一つです。出典

さらに、最近の海賊版サービスは、洗練された UX、ログイン機能、プロモーションコード、「サポート」窓口など、正規の配信サービスのような見た目と使い勝手を備えています。しかし裏では、多くの場合、事業者のコンテンツとインフラ容量を転売しているだけです。

CDN リーチングが OTT 事業に大きな打撃を与える理由

CDN リーチングが深刻なのは、三つの側面から同時に損害を与えるためです。

1. 契約者と ARPU の減少。 事業者自身の CDN 品質を使いながら、全作品を本来の料金のごく一部で提供する「寄生型」サービスがあれば、一部のユーザーは正規契約より海賊版を選びます。事業者の収益が失われ、不正配信者の利益になります。
2. CDN とインフラの請求増加。 不正なストリームは一つ増えるたび、以下のコストを押し上げます。
   • CDN の送信データ転送と HTTP リクエスト
   • キャッシュミス時のオリジン負荷
   • 認証、レコメンデーション、分析などの後段サービス
3. その直接的な結果として、正規の有料ユーザーの視聴品質が低下するおそれがあります。
   • バッファリングの増加
   • 低画質のレンディションへの切り替え、ABR による画質低下
   • 大規模なライブイベント中のタイムアウト

最悪の場合、特定のストリームやリージョンが過負荷になり、重要なスポーツ大会、プレミア公開、ライブコンサートなど、最も避けたい場面で目に見えるサービス品質の低下が起きます。結果として、支出は増え、収入は減り、最も大切な顧客を失望させます。

DRM だけでは足りない

多くの有料 OTT 事業者は、既にデジタル著作権管理（DRM）、安全なプレイヤー、トークン付き URL を使っています。これらは必要ですが、それだけでは不十分になりつつあります。

CDN リーチングは、それらの層の隙間を突きます。

• トークンが有効なら、CDN はそれを信頼します。 海賊版サービス全体で同じトークンを使い回しても、有効期限が切れるまではコンテンツが配信されます。
• DRM が保護するのはデータであり、ビジネスルールではありません。 認可されたデバイスだけが復号できることは保証しますが、「一世帯で同時に 2 ストリームまで」「この地域だけ」といった制限を本来の機能として強制するわけではありません。
• 不正配信者は認証情報の共有を悪用します。 一つの正規アカウントを転売したり、広く共有したりできます。各デバイスが個別に DRM チェックを通る限り、インフラは「家族のアカウント」と「海賊版の転売業者」を区別できません。

ここで強力なのが、サーバー側での同時視聴制限です。「このデバイスがこのセグメントを復号してよいか」だけでなく、「このアカウントが今ほかに何をしているかを踏まえて、引き続きアクセスを認めてよいか」も判断します。

リーチング対策のコントロールプレーンとしての同時視聴管理

同時視聴管理サービスは、「誰が視聴を続けてよいか」を決めるリアルタイムのポリシーエンジンと考えてください。DRM、トークン化、ウォーターマークを置き換えるのではなく、それらを連携させます。

効果的なアーキテクチャの概要は次のとおりです。

1. プレイヤーが、特定のコンテンツのセグメント（HLS または DASH）を要求します。
2. API ゲートウェイやエッジ関数が、JWT、OAuth、セッション Cookie などでリクエストを認証します。
3. 署名付き CDN URL を発行または受理する前に、バックエンドが同時視聴管理サービスを呼び出します。
   • 入力：account_id、content_id、device_id（またはフィンガープリント）、必要に応じて ip/geography、および segment_id またはタイムスタンプ。
   • ロジック：カウンターを増やし、しきい値を検証して、ミリ秒単位で許可または拒否を返します。
4. 許可する場合は、短い TTL でセッションまたはセグメント単位の項目を記録し、有効な署名付き URL または 200 OK を返します。
5. 拒否する場合は、バックエンドがリクエストを拒否し、プレイヤーに停止を通知します。たとえば独自のエラーコードや「同時に視聴しているデバイスが多すぎます」という表示を使います。必要に応じて、不正分析やカスタマーサポート用のテレメトリも記録できます。

十分な効果を得るには、このチェックを毎リクエスト、または数セグメントごとにインラインで実行し、ボトルネックにしない必要があります。大規模な事業者なら、1 桁ミリ秒のレイテンシで毎秒数百万の操作を処理しなければなりません。

重要な特性は次の三つです。

• リアルタイムであること。 判断は分単位ではなくミリ秒単位です。盗んだ一つのアカウントで 200 台のデバイスを起動されても、ほぼ即座に検知して抑えます。
• 世界全体で十分な整合性があること。 銀行システム級の ACID セマンティクスを保つのが目的ではありません。短いスライディングウィンドウでポリシーを適用するため、高速で一時的なインメモリデータがよく適合します。
• すべてサーバー側で行うこと。 通常の認証以外にクライアントの変更は不要です。API 自体を迂回する方法を見つけない限り、不正配信者はチェックを回避できません。

同時視聴のモデル化：アカウントからセグメントまで

同時視聴のモデルには多くの選択肢があり、適切な方法は製品と許容できるリスクによって決まります。

アカウント単位、コンテンツ単位の同時視聴

よくあるパターンは次のとおりです。

• 主キー：account_id
• 値に含める補助的な軸：content_id、device_id、session_id、timestamp

アカウントのアクティブなセッションを追跡するインメモリのデータ構造を維持します。

• アカウントの総ストリーム数の上限。たとえばプランに応じて 2、4、10 など。
• 一つのコンテンツのストリーム数の上限。たとえば、同じアカウントでスポーツの一試合を数百台へ再配信するのを防ぎます。
• 必要に応じて、デバイス単位や IP 単位の上限。

チェックのたびに、次の処理を行います。

• 最後のセグメントのタイムスタンプに基づき、期限切れの項目を削除します。
• ルールに従ってアクティブなセッションを数えます。
• 新規セッションやセグメント要求を受け入れるか判断します。

セグメント単位の粒度

主要なスポーツ大会など、注目度の高いライブイベントでさらに細かく制御するなら、セグメント単位まで制限を適用できます。

• キー：account_id:content_id:segment_sequence
• 値：そのセグメントを現在取得している device_id の集合
• TTL：セグメントの長さより少し長く、たとえばその 2 倍または 3 倍

これにより、次のような異常を検出できます。

• ごく短時間に、同じアカウントで数百のデバイスが同じセグメントを取得する。
• 正規のログイン直後、地理的に分散した大量の IP アドレスから、同一コンテンツへの要求が突然発生する。

各セグメントのキーは自然に期限切れになるため、システムが自動的に不要データを回収します。巨大な履歴データベースを維持するのではなく、常に「今起きていること」に対して同時視聴制限を適用できます。

ミリ秒単位のキャッシュが重要な理由

同時視聴制限は、ホットパスに置けるほど高速でなければ機能しません。

毎秒数百万のリクエストを処理する OTT 事業者には、次のような余裕はありません。

• セグメント要求ごとに、遠くのデータベースまで往復する。
• ストリームを許可するかどうかだけのために、重い結合や複雑なトランザクションを実行する。

Momento のような低レイテンシのデータプレーンが適している理由は次のとおりです。

• スループット。 リージョンをまたいで毎秒数百万の操作を継続処理するために構築されています。
• レイテンシ。 p99 が 1 桁ミリ秒なら、セグメントの処理時間の予算に十分収まります。
• 一時性が利点になる。 同時視聴の状態は短期間で自動的に消えることが望ましいデータです。TTL を使うモデルなら手動のクリーンアップが不要で、コストも予測しやすくなります。
• アプリケーションチームにとっての単純さ。 同時視聴のチェックは、独自の分散システムを手作りする作業ではなく、単純な GET / SET / INCR のパターンになります。

つまり、同時視聴管理を、新しいプラットフォームの開発と保守ではなく、単純なサービス呼び出しとして扱えます。

同時視聴の追跡が CDN リーチング対策になる仕組み

ここまでの仕組みは、CDN リーチングにどう結び付くのでしょうか。リーチングは、主に次の前提に依存しています。

1. トークンが有効なら、CDN はそれを提示できる誰にでも配信する。
2. 帯域幅の使用量とライセンス数が食い違っても、事業者は気づかない。
3. 人間が介入するまでは、認証情報の共有は事実上無制限である。

堅牢な同時視聴管理サービスは、これらの前提を崩します。

• アカウントごとの同時利用数に厳格な上限を設けます。 一つのアカウントを数百人に転売しようとしても、すぐに上限に達します。バックエンドがセグメント要求を拒否し始め、不正な「サービス」は使い物にならなくなります。
• アカウントとコンテンツ単位で異常を検出します。 アカウント、コンテンツ、デバイス別にリアルタイムの利用を集計するため、一つのアカウントが数十か国から同じ試合を 40 ストリーム視聴する、といった疑わしいパターンを発見できます。そのデータを海賊版対策や不正検知システムに渡せます。
• ライセンスと帯域幅を対応させます。 DRM ライセンスの発行と同時視聴の追跡を結び付けると、「カウント済みのアクティブなセッションがなければセグメントを配信しない」という制約を適用できます。鍵やトークンが想定範囲を超えて再利用される隙間を狭められます。
• 影響範囲を小さく抑えます。 大規模イベント中にはリスクの高い IP 範囲全体の遮断や CDN エンドポイントの停止をせず、不正なアカウントと関連するストリームだけを的確に停止できます。正規ユーザーは影響を受けずに視聴を続けられます。

CDN リーチングは、事業者のサービスを海賊版向けの無料 CDN に変えてしまいます。同時視聴の追跡は、不正利用を停止するスイッチになります。 アカウント、作品、セグメントなど、必要な粒度で制御できます。

多層防御の一部としての同時視聴管理

同時視聴制限は万能ではありません。次のような対策と組み合わせる多層戦略の中で、大きな効果を持つ要素です。

• 堅牢な DRM 実装と定期的な鍵のローテーション
• 有効期間が短く、対象範囲を厳しく限定した CDN トークン
• リバースエンジニアリングに耐えるアプリケーションの強化
• 流出元を追跡するフォレンジックウォーターマーク
• AI による異常検知
• 法的な削除要請と権利行使

ただし、独自の利点があります。完全に事業者の管理下にあり、自社サーバーで実装され、個々のリクエストにコンテンツを渡すかどうかを直接制御できます。

Momento のような低レイテンシで高い拡張性を持つデータプレーンを基盤にすれば、プレイヤーを複雑にしたりインフラを肥大化させたりせず、同時視聴管理サービスはリアルタイムに判断できます。しかも、非常に大きな規模で実行できます。