動画暗号化とは？AES-128の仕組み・DRMとの違い・導入時の注意点
動画暗号化の仕組みとAES-128、DRMとの違いを整理し、暗号化で守れる範囲、画面録画など防げないリスク、導入時の確認項目を解説します。
社内研修や業務マニュアルを動画で共有するとき、「暗号化しておけば、URLが外部へ漏れても安全なのか」「ダウンロードや画面録画まで防げるのか」と疑問を持つ担当者は少なくありません。
動画暗号化は、配信データをそのままでは読み取れない状態にする重要な対策です。しかし、暗号化方式だけで安全性が決まるわけではありません。復号に使う鍵を誰に渡すか、動画ごとの視聴権限をどう確認するか、正規利用者による持ち出しへどう備えるかまで設計する必要があります。
この記事では、動画配信で使われるAES-128暗号化の基本、DRMやHTTPSとの違い、守れる範囲と限界、導入前に確認したい項目を解説します。
結論：暗号化は必要だが、鍵と視聴権限を守らなければ機能しない
暗号化された動画データを取得しても、正しい鍵がなければ通常はそのまま再生できません。そのため、保存先や配信経路からデータの一部が取得された場合の対策になります。
一方、再生を許可された端末には、映像を表示するための鍵または復号処理が必要です。鍵の取得先が誰でもアクセスできる状態なら、動画だけを暗号化しても十分な保護にはなりません。また、正規に再生された画面の録画や、別のスマートフォンによる撮影は、配信データの暗号化だけでは防げません。
したがって、実際の動画配信では「データの暗号化」「鍵の保護」「利用者認証」「動画ごとの視聴権限」「持ち出しへの抑止と記録」を組み合わせます。
動画暗号化とは
暗号化とは、元のデータを一定の規則と鍵によって変換し、鍵を持たない人には内容を読み取りにくくする処理です。AESは代表的な共通鍵暗号方式で、NIST（米国国立標準技術研究所）の標準ではAES-128、AES-192、AES-256が定義されています。数字は鍵の長さを表し、いずれもデータを128ビットのブロック単位で処理します（NIST FIPS 197、2023年5月更新）。
動画配信の暗号化を考えるときは、次の3つを分けて確認する必要があります。
- 通信経路の暗号化：アップロードや再生時の通信をHTTPSで保護する
- 保存データの暗号化：サーバーやストレージに置かれたファイルを保護する
- 配信データの暗号化：視聴端末へ送る動画データを暗号化し、再生時に復号する
どれか一つだけでは、動画の保管から視聴までを一貫して守れません。「暗号化対応」という説明だけで判断せず、どの区間が暗号化され、鍵をどのように渡すのかを確認します。
HLSでAES-128暗号化動画が再生される仕組み
Webで長い動画を配信する方法の一つにHLS（HTTP Live Streaming）があります。HLSでは、動画を短いメディアセグメントに分割し、プレイリストに記載された順序で取得しながら再生します。
HLSの仕様でAES-128を使用する場合、各メディアセグメントは128ビットの鍵を使ったAES-CBC方式で暗号化されます。プレイリストには復号鍵の取得先を示すURIが入り、再生側は必要なセグメントと鍵を取得して復号します。RFC 8216は、鍵の配信をTLSと安全な認証領域またはセッショントークンなどで保護することも示しています（RFC 8216「HTTP Live Streaming」）。
概略は次のとおりです。
- 元の動画を配信用の形式へ変換する
- 動画を複数のメディアセグメントへ分割する
- 各セグメントを鍵で暗号化する
- ログイン状態と視聴権限を確認する
- 許可された再生セッションへプレイリスト、セグメント、鍵を提供する
- 視聴端末で復号しながら動画を再生する
重要なのは、動画データと鍵を別々に置くだけでは不十分だという点です。鍵の取得先、プレイリスト、動画セグメントのそれぞれに対して、必要なアクセス制御を設計します。
AES-128暗号化で守れること
1. 取得した動画データの単純な再利用を難しくする
暗号化済みのセグメントは、鍵がなければ通常の動画ファイルとしてそのまま再生できません。サーバー上のファイルを直接開く、取得した一部のデータだけを別のプレイヤーへ渡すといった単純な再利用への対策になります。
2. 平文の動画ファイルをそのまま配信する状態を避ける
一般的なMP4ファイルを誰でも取得できるURLへ置く方法と比べると、暗号化された複数のセグメントと鍵を使う構成は、動画ファイルがそのまま露出するリスクを減らせます。
3. 認証・権限管理と組み合わせて視聴範囲を制御する
ログインした利用者について、対象動画を視聴できるか確認したうえで鍵を提供すれば、利用者や部署、役割ごとに視聴範囲を分けられます。認証は「誰か」を確認する処理、認可は「その人が何を許可されているか」を確認する処理です。OWASPも両者を区別し、認証済みの利用者がすべての資源へアクセスできるわけではないと説明しています（OWASP Authorization Cheat Sheet）。
ただし、「URLを知っている人」ではなく「現在視聴を許可されている人」だけが鍵を取得できる設計になっていることが前提です。
暗号化だけでは防げない4つのリスク
1. 鍵や取得先の公開設定
暗号化されたセグメントと復号鍵の両方を、認証なしで取得できる状態にしてしまうと、暗号化の効果は大きく下がります。動画URLだけでなく、プレイリストと鍵の取得先まで確認が必要です。
2. 正規利用者による画面録画・スマートフォン撮影
正規に視聴できる利用者の画面には、復号された映像が表示されます。その表示をOSの録画機能や別端末のカメラで記録する行為は、配信データの暗号化とは別の問題です。画面録画対策については「研修動画の画面録画・スマホ直撮りは防げる？」で詳しく解説しています。
3. アカウントの共有・認証情報の漏えい
利用者がIDとパスワードを共有した場合や、認証情報を第三者に取得された場合、システム上は正規のログインに見えることがあります。個人単位のアカウント、不要アカウントの停止、接続元制限などを組み合わせます。
4. 視聴端末そのものの問題
端末がマルウェアに感染している、ブラウザやOSが更新されていない、共用端末に認証状態が残っているといった問題は、動画の暗号化方式だけでは解決できません。視聴環境をどこまで管理するかも要件に含めます。
AES-128暗号化・HTTPS・アクセス制御・DRMの違い
| 対策 | 主に守る対象 | 単独では対応できないこと |
|---|---|---|
| AES-128による動画暗号化 | 配信される動画データ | 利用者の本人確認、画面撮影、アカウント共有 |
| HTTPS | ブラウザ・アプリとサーバー間の通信 | 保存済みデータの公開設定、正規利用者の持ち出し |
| 認証・アクセス制御 | 誰がどの動画へアクセスできるか | 再生後の画面撮影、端末外への持ち出し |
| DRM | ライセンス・鍵の提供と対応環境での再生制御 | 別端末による撮影を含む、すべての持ち出し |
| 動的ウォーターマーク | 正規再生後の不正撮影への抑止と事後確認 | 動画データや鍵そのものの暗号化 |
「AES-128で暗号化している」ことと「DRMを導入している」ことは同じではありません。W3CのEncrypted Media Extensions（EME）は、ブラウザが暗号化コンテンツと鍵システムを扱うための共通APIを定めていますが、仕様自体が特定のDRM方式を定義するものではなく、認証・認可はアプリケーション側の役割とされています（W3C Encrypted Media Extensions）。
製品を比較するときは、「暗号化」「DRM対応」といった名称だけでなく、鍵の発行条件、有効期間、対応ブラウザ、端末制御、オフライン再生、同時視聴制御など、必要な要件を個別に確認します。
導入前に確認したい7つの項目
1. どの動画を暗号化するか
公開情報、一般的な社内案内、部署限定、経営情報、個人情報を含む研修など、動画の重要度を分類します。すべてを同じ強度・同じ運用にすると、必要以上に管理が複雑になることがあります。
2. 誰が鍵を取得できるか
ログインしているだけで全動画の鍵を取得できるのか、動画ごとに権限を確認するのかを確認します。管理者、一般社員、委託先など、役割ごとの違いも整理します。
3. プレイリスト・セグメント・鍵をまとめて保護できているか
動画本体だけを非公開にしても、鍵やプレイリストが公開されていれば十分ではありません。それぞれの取得条件と、権限がない場合の拒否動作をテストします。
4. 権限変更がいつ反映されるか
退職者の停止、部署異動、期間限定公開の終了が、鍵の取得や再生へいつ反映されるかを確認します。長時間有効なURLや認証状態が残る設計では、管理画面で権限を変更しても直ちに止まらない場合があります。
5. 対応する端末・ブラウザ
社内PC、スマートフォン、タブレット、会議室端末など、実際の利用環境で再生を検証します。暗号化方式やDRM方式によって、対応状況や必要な実装が異なります。
6. 問題発生時に確認できる記録
ログイン、動画へのアクセス、鍵の取得、権限変更など、実際に取得できる記録と保存期間を確認します。記録があっても、誰がどの手順で確認するか決まっていなければ活用できません。
7. 暗号化以外の対策と運用できるか
本人認証、視聴権限、IP制限、動的ウォーターマーク、アカウント管理、社内ルールを含めて、担当者が無理なく続けられる構成にします。動的ウォーターマークの考え方は「動画の動的ウォーターマークとは？」もあわせてご覧ください。
Nobishiro合同会社の動画配信システムでできること
Nobishiro合同会社では、社内研修や重要情報の共有に合わせて、AES-128による暗号化を含む動画配信システムを設計します。
- 動画を保護した状態で配信するためのAES-128暗号化
- 社員アカウントの追加・削除と視聴権限の設定
- 許可した接続元からの視聴に限定するIP制限
- 社員IDとIPアドレスを再生画面へ表示する動的ウォーターマーク
- 動画登録後の変換・暗号化・クラウド送信・配信準備の簡略化
- 既存の業務や社内環境に合わせたオーダーメイド対応
資料上の「AES-128」という名称だけで安全性を断定するのではなく、動画の機密度、視聴者、利用場所、現在のアカウント管理方法を確認し、必要な対策を組み合わせます。配信方法全体を整理したい場合は「社内研修動画を安全に配信するには？」もご覧ください。
現在の配信方法と必要な保護範囲からご相談ください
「共有リンクだけで配信している」「暗号化とDRMの違いが分からない」「現在の社内環境に必要な対策を整理したい」といった検討段階からご相談いただけます。
対象となる動画、視聴者、端末、ネットワーク、運用担当者を確認し、過剰な機能を増やさず、必要な保護範囲を整理します。まずはお問い合わせフォームからご相談ください。
