動画配信の課金システム｜視聴権限とDRMライセンス発行をつなぐ実装設計

動画配信の課金システムでつまずくのは、カードを切る部分ではありません。決済そのものは代行サービスに任せられます。難しいのは、決済の結果として生まれた「この人はこの作品をいつまで見てよい」という状態を、再生ボタンを押した0.5秒後に確実に答えられる形へ変換する層です。この記事では、SVODとTVODとPPVで変わる権利の単位、DRMライセンス発行時の認可、同時視聴数とデバイス上限、解約や返金から視聴が止まるまでの経路、アプリ内課金とWeb課金の併存までを実装粒度で整理します。トランスコードやCDNなど配信基盤の設計は動画配信システムの構築｜トランスコードからHLS配信・視聴制御・DRMまで実装解説に譲ります。

まとめ：課金状態を視聴可否へ変換するエンタイトルメント層の設計要点

動画配信の課金システムは、決済基盤と配信基盤の2つではなく、その間に挟まる3つ目の層で成否が決まります。この層をエンタイトルメント（視聴権利）層と呼びます。決済基盤が持つのは契約と入金の事実、配信基盤が持つのは映像と暗号鍵で、どちらも「今このユーザーがこの作品を見てよいか」には答えられません。設計の第一手は、この判定を専任で持つAPIを立てることです。

権利の有効期限は、課金モデルごとに起点が違います。SVODなら契約期間、TVODなら初回再生からの経過時間、PPVなら公演の開催枠。この違いをひとつのカラムで表そうとすると破綻するため、期限は「いつから使えるか」と「再生開始から何時間か」を別々に持ってください。Widevine のライセンスポリシーが rental_duration_seconds と playback_duration_seconds を独立した項目として持つのは、この二段構えが業界共通の前提だからです。

最後に効くのが、権利を取り消す側の設計です。付与は同期的に済みますが、取消は非同期で遅れます。解約・返金・チャージバック・ストアの取消通知という4つの入口をすべて拾い、取りこぼしに備えた定期照合を置かない限り、支払っていない視聴者が残ります。作るのは「見せる仕組み」ではなく「見せなくする仕組み」です。

課金モデルごとに変わる視聴権限の単位と、決済基盤との責務の分界点

最初に決めるのは、権利を何の単位で持つかです。曖昧なまま決済を先に組むと、後からレンタルを足せなくなります。

SVOD・TVOD・PPVで異なる権利の単位と有効期限の決め方

モデルの定義はOTTとは？意味・種類（SVOD/AVOD/TVOD）と代表的なサービス・VODとの違いで整理しています。実装で見るべきは、権利をどの粒度で持ち、いつ失効するかという一点です。

SVODだけを作るつもりでも、権利テーブルは作品単位で持てる構造にしておきます。プラン単位で持つと、単品レンタルを足す日に判定ロジック全体を書き換える羽目になるためです。プランに紐づくカタログを展開した結果として作品単位の権利を返せばよく、追加コストはテーブル1本ぶんに収まります。

課金基盤と配信基盤の間に置くエンタイトルメントAPIの責務範囲

エンタイトルメントAPIの責務は、ユーザーIDと作品IDを受け取り、可否と期限と制約を返すことだけです。カードの再請求は決済基盤、暗号鍵の受け渡しはDRMライセンスサーバー、映像の配布はCDNが持ちます。この分界を守れば、決済代行を乗り換えても配信側の改修が発生しません。

返す値は真偽値ではなく、理由コードを添えた構造体にします。「未購入」「期限切れ」「地域外」「同時視聴上限」「デバイス未登録」を区別できないと、プレイヤーは一律のエラーしか出せません。視聴できない理由が出ないサービスは、問い合わせ件数として運用コストに跳ね返ります。

契約状態から視聴可否を解決するデータモデルと、権利の粒度の設計

推奨する構造は3層です。契約（subscription）、権利（entitlement）、視聴セッション（session）を別テーブルに分け、契約から権利を導出する処理は非同期ジョブにします。契約テーブルを毎回JOINして可否を計算する実装は、カタログが数千本を超えると応答が伸びます。

1. 決済または契約の状態が変わったイベントを受け取る
2. そのイベントから付与・剥奪すべき権利の差分を計算する
3. 権利テーブルへ書き込み、期限をエポック秒で保持する
4. 再生要求時は権利テーブルの1件参照だけで可否を返す

権利テーブルには、付与の根拠となった取引IDを必ず残します。返金やチャージバックの通知が届いたとき、取り消す権利を特定する手がかりが取引IDしかないためです。この列を後から足すと、過去ぶんの突合ができません。

DRMライセンス発行時の権利チェックと、ライセンス期限の設計指針

署名付きURLは、映像ファイルへの到達を制御する仕組みです。到達後に再生できるかを決めるのはDRMライセンスで、課金システムから見ると、ここが権利を検証する最後の関門になります。

ライセンス要求時にトークンで権利を検証する認可サーバーの組み方

プレイヤーは暗号化された映像を受け取ると、DRMライセンスサーバーへ鍵を要求します。Widevine（Google）、PlayReady（Microsoft）、FairPlay Streaming（Apple）のいずれも、この要求に事業者側が発行したトークンを添える構成を取れます。流れは、エンタイトルメントAPIへ可否を問い合わせ、許可された場合だけ短命のトークンを受け取り、それをライセンス要求に載せる順序です。

トークンの寿命は、再生開始までの猶予ぶんで足ります。数分あれば十分で、1時間の設定は攻撃面を広げるだけです。作品IDと権利の期限を含め、ライセンスサーバー側で作品IDの一致を検証してください。含めないと、安い作品のトークンで高額作品の鍵を取れる穴が残ります。

レンタル期限を2種類の有効期限で表現するライセンスポリシー設計

TVODの「購入から30日以内に再生を開始し、開始後は48時間視聴できる」という条件は、期限をひとつしか持たない設計では表現できません。Widevine のライセンスポリシーは、この要件を分解して持ちます。rental_duration_seconds が初回再生までの猶予、playback_duration_seconds が再生開始後の視聴可能時間、license_duration_seconds がライセンス自体の有効期間にあたり、いずれも0を指定すると無制限として扱われます。

注意したいのは、期限がライセンス側とサーバー側の二重管理になる点です。ライセンスに48時間を焼き込んでも、権利テーブルが期限を持たなければ、ユーザーは再取得のたびに新しい48時間を得られます。期限の正はサーバー側に置き、ライセンスの期限はその写しとして発行してください。逆にしてはいけません。

オフライン再生を許可する条件と、永続ライセンスで失効が遅れる問題

ダウンロード視聴を提供するなら、ライセンスを端末に永続化する設定が要ります。Widevine では can_persist が該当し、既定値は false。有効にすると、端末は通信のない状態でも鍵を保持したまま再生できます。

引き換えに失うのが、即時に権利を止める能力です。永続ライセンスを配った端末は、次にオンラインへ戻るまで取消要求を受け取りません。解約者が機内モードのまま視聴を続ける状況が原理的に成立します。許容できない契約条件なら、ダウンロード可能期間を短く切り、再生アプリ側に定期的なライセンス再検証を実装してください。権利者の要求が厳しい案件では、ダウンロード機能を提供しない判断が現実的です。

同時視聴数とデバイス数の制限を、課金プランへ結びつける実装方法

プラン差別化の中身は、画質と同時視聴数とデバイス数に集約されます。このうち同時視聴数は、権利テーブルの静的な値では表現できません。

同時視聴数のカウントをどこで持つか、視聴セッション管理の設計判断

同時視聴の判定には、再生中のセッションを数える仕組みが要ります。プレイヤーから一定間隔でハートビートを送り、有効期限付きのキーとしてインメモリのデータストアへ保持する方式が扱いやすいでしょう。30秒間隔で送り90秒で失効させれば、アプリを強制終了された場合も90秒後には枠が空きます。

ここでデータベースにセッションを書く設計を選ぶと、視聴者が増えたときに書き込みが詰まります。1万人が同時視聴していれば、30秒間隔でも毎秒333件の更新です。カウントは揮発してよい情報なので、永続化の対象から外してください。集計や不正検知に使う視聴ログは別系統で非同期に流します。

デバイス登録の上限とリセット周期の決め方と、実務での初期値の目安

デバイス上限は同時視聴数とは別の制約で、「今」ではなく「累積」を数えます。アカウント共有を抑えたい場合に効くのは後者ですが、締めすぎると機種変更のたびに問い合わせが来ます。

初期値は同時視聴数の2倍から3倍に置き、登録解除を月1回まで許す設定から始めるのが無難です。上限に達した端末を単純に拒否せず、既存端末の一覧を返して選ばせるUIまで設計します。DRMのデバイス識別子は端末の初期化で変わるため、識別子だけの厳密な管理は運用に耐えません。

解約・返金・チャージバックで視聴を止めるまでの経路と反映の遅延

課金システムの品質は、止め方に出ます。剥奪の経路は4本あり、通知の形式も遅延もそれぞれ違います。

解約時に即時停止するか期間末まで見せるか、契約状態で決まる挙動

解約には2種類あります。ユーザーが自発的に更新を止める場合は、支払い済みの期間末まで視聴を許すのが一般的な扱い。支払いが失敗して契約が終了する場合は、猶予期間の設計次第で挙動が変わります。

この分岐を権利テーブルの期限だけで表そうとすると混乱します。契約テーブルに「更新予定なし」の状態を持たせ、権利の期限は支払い済み期間の末日に置く。分けて持てば、解約直後の画面に「◯月◯日まで視聴できます」と正確に出せます。決済側の更新失敗と督促の設計はサブスクリプション課金とは？継続課金の仕組み・オフセッション決済と更新失敗対策の実装を開発視点で解説が扱うため、ここでは視聴側の反映だけに絞ります。

返金とチャージバックの通知で権利を取り消すサーバー間連携の実装

返金は、決済代行の管理画面から人が操作する場合と、ストア側で自動処理される場合があります。どちらの経路でもWebhookが届くため、その受信をトリガーに権利を落とす設計にしてください。Apple の App Store Server Notifications V2 では REFUND 通知に revocationDate と revocationReason が含まれ、どの取引が取り消されたかを originalTransactionId から特定できます。Google Play なら Real-time developer notifications の SUBSCRIPTION_REVOKED が有効期限前の取消を表し、返金やチャージバックの一覧は Voided Purchases API からも取得可能です。

チャージバックは返金と挙動が違います。カード会社経由で数週間遅れて届くため、その時点でユーザーは視聴済みです。権利を落とすだけでなく、当該アカウントを再購入時の追加認証の対象に入れる運用まで設計すると、繰り返しの被害を抑えられます。

通知の取りこぼしと重複に備える冪等処理と、定期照合のフォールバック

Webhookは必ず取りこぼします。受信側の一時的な障害、送信側のリトライ上限、通知順序の逆転のいずれもが現実に起きるためです。Google の公式ガイドが、通知の受信後に Play Developer API を呼んで完全な状態を取得するよう求めるのは、通知を最終的な真実として扱わせないためです。

実装では次の3点を揃えます。第一に、通知IDを主キーにした受信記録を持ち、同じ通知が2回来ても2回処理しない冪等性の確保。第二に、通知の内容を信じず、提供元のAPIへ現在の状態を問い合わせて確定させること。第三に、1日1回の全件照合バッチで、通知が来なかった契約の食い違いを拾うことです。3番目を省いた実装は、半年ほどで「解約したのに見られる」という問い合わせから破綻が露見します。

アプリ内課金とWeb課金を併存させる判断軸と、外部課金導線の設計

ここからは判断を示します。モバイルアプリを持つ動画サービスは、ストア課金とWeb課金の両方を扱うか必ず問われます。

ストアの購入通知を権利へ反映するレシート検証と、状態同期の実装

ストア課金を入れる場合、クライアントが受け取ったレシートを信じてはいけません。検証はサーバー側でストアのAPIへ問い合わせて行い、その結果だけを権利の根拠にします。購入後の状態変化は通知で追ってください。Apple 側は SUBSCRIBED・DID_RENEW・EXPIRED・GRACE_PERIOD_EXPIRED といった種別で契約の遷移が届き、更新失敗から復旧した場合は DID_RENEW に BILLING_RECOVERY のサブタイプが付きます。Google 側は Cloud Pub/Sub を経由して同種の通知が配信されます。

ストア課金とWeb課金を併存させると、ひとりのユーザーに権利の供給元が2つできます。契約テーブルに供給元の列を持たせ、付与処理は供給元ごとに独立して動かします。統合するのは最終的な視聴可否だけに留めるのが安全です。

スマホ新法の全面施行で変わった外部課金導線と、手数料から見た採否

2025年12月18日、スマホソフトウェア競争促進法が全面施行され、アプリ内から外部の決済サイトへ誘導する導線が日本でも解禁されました。日本向けガイドラインの改定では、Appleが大規模事業者向けの手数料を30%から26%へ引き下げ、外部リンク経由には別途の店舗手数料を課す一方、Googleは30%と15%の体系を維持したと報じられています（2026年8月12日時点の公開情報にもとづく整理）。

押さえるべきは、手数料がゼロにはならない点です。外部導線へ切り替えても十数%規模の店舗手数料が残るため、削減できるのは差分だけ。その差分と引き換えに、決済基盤の自前運用、返金対応の内製化、権利供給元の二重化という運用負荷を引き受けます。月間の課金額が数百万円に届かない規模なら、この交換は割に合いません。まずストア課金で立ち上げ、規模が見えてから外部導線を足す順序を推奨します。

併存させないほうがよい条件と、権利の二重付与が起きる失敗パターン

併存を見送るべき条件を明示します。ひとつ、同一プランをストアとWebの両方で販売する場合。ふたつ、無料トライアルを両経路で提供する場合。当てはまるなら、併存は採用しないでください。

理由は、権利の二重付与が構造的に起きるためです。Webで月額契約したことを忘れてアプリからも購入すると、権利テーブルには2件の有効な権利が並びます。視聴はできてしまうため、当人が気づくのは二重の請求を見た翌月。返金対応はストア側とWeb側で別々に走り、残った1件の権利を消さずに保つ処理も要ります。重複購入を購入前に検知して拒否する仕組みを先に作れないうちは、販売経路をひとつに寄せる判断が正しいです。

エンタイトルメント層の自社実装と既製プラットフォームを分ける判断

ここまでを踏まえ、どこから自社で持つべきかを線引きします。

権利管理を自前で持つべき要件と、ASPで足りる場面の具体的な線引き

ASPで足りるのは、課金モデルがSVODの単一プランか作品単位のTVODだけで、判定条件が「契約中かどうか」に収まる場合です。社内研修動画や会員向けアーカイブの提供はここに入ります。ASPと自社構築の選定軸は動画配信システムとは？仕組み・配信方式と、ASP/自社開発の選び方を受託開発目線で解説で整理しています。

自前で持つ判断になるのは、次のいずれかに当てはまるときです。既存の会員基盤や基幹システムが権利の正を持ち、そちらと同期する必要がある場合。プランと単品と法人契約が混在し、権利の由来が3系統以上になる場合。権利者との契約で配信可能期間が作品ごとに決まり、満了と同時にカタログから外す処理が要る場合。3つ目は既製サービスでの表現が難しく、実務で自社実装へ倒れる典型例です。決済側を含めた設計の相談は決済・サブスクリプションシステム開発で扱う領域にあたります。

受託開発で先に固める仕様と、見積もりから抜けやすい運用要件の項目

要件定義で先に確定させるのは、権利の単位と有効期限の起点、そして取消の経路です。この3つが決まっていれば、課金モデルが増えても差分開発で吸収できます。画質やプラン名から議論を始めた案件は、レンタル追加の段階で作り直しになります。

見積もりから抜けやすいのは、次の項目です。

• 返金・チャージバック受信時の権利取消と、CS担当の手動操作画面
• 通知の取りこぼしを検出する日次照合バッチと、差分が出たときの通知
• デバイス登録の解除リクエストに対応する管理機能
• 権利の付与根拠を残す監査ログと、権利者への視聴実績レポート
• ストア側の通知仕様が変わったときの追随（年次で更新される）

これらは初期リリースに無くても動きますが、運用開始から3か月以内に必ず要ります。見積もり段階で別フェーズに切り出しておくと、後の追加依頼が予算の争点になりません。カードの保存方式やMIT・CITなど決済側の前提はリカーリング決済とは？カードオンファイルとMIT・CITの仕組み・実装パターンを開発視点で解説を参照してください。

動画配信の課金システムでよくある質問｜権限とDRMと解約反映の疑問

実装の相談で繰り返し挙がる論点を5つ挙げます。

動画配信の課金システムは決済代行を導入すれば作れますか？

決済代行が担うのはカードの処理と契約の管理までで、「誰がどの作品を見てよいか」の判定は含まれません。エンタイトルメント層は決済代行の管理画面にも配信ASPの標準機能にも入っていないことが多く、自社側で作る前提になります。決済代行で省けるのはカード情報の保持とPCI DSSへの対応であり、そこは大きな節約ですが、課金システム全体では半分程度と見ておくのが実態に近い見積もりです。

無料会員と有料会員で見せる動画を分けるだけならDRMは必要ですか？

不要な場合があります。判断軸は、流出したときの損害と、権利者との契約でDRMが要求されているかの2点です。社内研修や自社製品の説明動画なら、署名付きURLとAES-128の暗号化で足ります。映画やアニメなど外部から権利許諾を受けたコンテンツでは、DRMの適用が契約条件になっている例が大半で、選択の余地がありません。DRMを入れるとライセンスサーバーの費用と互換性検証の工数が加わるため、要否は契約書を確認してから決めてください。

解約したユーザーの視聴はどのくらいで止まりますか？

設計次第ですが、標準的な構成では数秒から数分です。権利テーブルを即時更新すれば次の再生要求から止まります。ただし再生中のセッションは、次のライセンス要求まで継続します。ダウンロード視聴を許可している場合はさらに遅れ、端末がオンラインに戻って再検証するまで止まりません。即時停止が契約上の要件なら、永続ライセンスの発行を避ける設計が前提です。

レンタル作品の視聴期限はどこで管理するのが確実ですか？

サーバー側の権利テーブルを正とし、DRMライセンスの期限はその写しとして発行する構成が確実です。ライセンス側だけで管理すると、再取得のたびに期限が延びる抜け道が生まれます。端末のローカル時刻を基準にした判定も避けてください。時刻を過去へ変更されると期限判定が効かなくなるためです。期限はサーバー時刻のエポック秒で保持し、判定もサーバー側で行います。

アプリ内課金とWeb課金の両方に対応すると開発量はどれくらい増えますか？

権利の供給元が増えるぶん、契約と権利の同期処理が経路ごとに必要になります。追加されるのは、レシート検証、サーバー通知の受信と冪等処理、経路別の返金対応、重複購入の検知という4つ。AppleとGoogleで通知の種別も名称も異なるため、両対応は片方だけの2倍近い工数になります。売上規模が小さい段階では、販売経路をひとつに寄せる判断のほうが投資対効果は高くなります。

関連記事

• 動画配信システムとは？仕組み・配信方式と、ASP/自社開発の選び方を受託開発目線で解説：配信方式の全体像とASPと自社開発の選定軸を発注判断の視点で整理。
• 動画配信システムの構築｜トランスコードからHLS配信・視聴制御・DRMまで実装解説：配信基盤側の設計を、署名付きURLとDRM暗号化まで扱います。
• サブスクリプション課金とは？継続課金の仕組み・オフセッション決済と更新失敗対策の実装を開発視点で解説：更新失敗のリトライや督促など、決済側の継続課金設計を補完。
• リカーリング決済とは？カードオンファイルとMIT・CITの仕組み・実装パターンを開発視点で解説：カード保存と自動課金のネットワーク層の前提を確認。
• OTTとは？意味・種類（SVOD/AVOD/TVOD）と代表的なサービス・VODとの違い：本記事で実装対象にした課金モデルの定義と位置づけを扱います。