動画配信基盤のクラウド構成例

最小構成から中規模までの基本アーキテクチャ

VODの基本構成（視聴体験を崩さない王道）

VODは「アップロード→検証→トランスコード→パッケージング→公開→視聴」の一直線パイプラインが基本です。オリジンはオブジェクトストレージ、パッケージはHLS/DASH、配信はマルチCDN、プレイヤーはABR対応。ワークフローはイベント駆動で、入稿時にメタ情報（タイトル、チャプター、サムネ）を揃えます。サムネはエディタが仕上げつつ、初期案はMidjourneyでバリエーションを一括生成してA/B。メタデータ整備はChatGPTでタグ補完、Claudeで説明文の読みやすさを担保するなど、人とAIの分業が効きます。

ABRラダーは固定ではなく「Per-Title最適化」を推奨です。目安として1080p 4.5〜6Mbps、720p 2.5〜3.5Mbps、480p 1〜1.5Mbps、360p 0.6〜0.8Mbps。高動き/低動きの判別とシーンチェンジ検知を入れると平均20〜40%の帯域削減が可能です。オリジンはパブリックに晒さず、CDNからのみ到達できるプライベート構成が基本。URLはJWTで5〜15分の短命署名にし、プレイリストは短TTL、セグメントはやや長めでキャッシュ効率を上げます。

ライブ配信の追加要素（SLAを崩さない設計）

ライブは「インジェスト（RTMP/SRT）→トランスコード（GPU混在の自動スケール）→パッケージ（CMAF）→配信」の直列。低遅延は二択です。相互通話/投げ銭連動などインタラクティブ性が高いならWebRTC（0.5〜2秒）、大規模視聴で安定優先ならLow-Latency HLS/DASH（2〜5秒）。WebRTCはスケール限界とデバッグ難度が上がるため、視聴者数と機能要件で切り替え可能な二経路を用意しておくと事故時の退避がしやすいです。CDNは2社以上、トラフィックステアリングはDNS/クライアントSDK/サーバ側ヘルスの組合せで動的切替が現実的です。

スケールとレイテンシを両立する具体ティップス

• キャッシュ戦略: マニフェストのTTLは3〜10秒、セグメントは数分。ライブはパーシャルセグメント（200〜500ms）を有効化し、先読みでスタートアップを短縮。
• オリジン保護: オリジン前段にシールドキャッシュを入れ、CDNミス時でも大量同時接続が直撃しないようにする。平時RPSの20倍を想定したプリウォーム手順をRunbook化。
• アクティブ-アクティブ: 少なくとも2リージョンで同時稼働。ステートは外部化（セッションはトークン、ジョブキューは冗長化）。フェイルオーバーはヘルス×SLO違反で自動。
• 容量設計: CDNごとに30〜50%のヘッドルームを維持。トランスコードはキュー長×待機時間でスケール。GPUはピークのみスポット、ベースはオンデマンド。
• チャット/コメント: 配信と独立したPub/Subで冗長化。落ちても映像を巻き込まない分離設計が重要。

セキュリティと権利保護の実装ポイント

• 認可: 再生ごとにスコープ付きJWTを発行（タイトルID、解像度上限、期限、地域）。プレイヤーは更新可能な短命トークン方式。
• 配信制御: ドメインリファラー制限、IPレート制御、地理ブロック。スクレイピング対策にマニフェストのパス難読化とトークンバインディング。
• DRM/暗号化: CENCベースのマルチDRMに対応。キーはKMSで管理、ライセンスは視聴デバイスとリージョンに応じて発行。オフライン視聴は別ポリシー。
• 透かし: セッションID埋め込みのフォレンジック・ウォーターマークか、プレイヤー側の可変オーバーレイ。リーク発見時の追跡に有効。
• オペレーション: 秘密情報は環境ごとに分離、ローテーションは90日以内。権限はジョブ単位の最小権限、ビルドからデプロイまで署名付きアーティファクト。

コスト最適化と運用の勘どころ（AI活用含む）

ストレージ/エンコードの節約

• ライフサイクル: 公開30日以内はホット、以降はウォーム、半年後はアーカイブ。プレビューとサムネは小容量別バケット。
• ラダー最適化: VMAFターゲットでラダー自動生成。重複フレーム除去とシーン別CRFでムダを削る。多音声/字幕は必要分のみ。
• ライブ→VOD: 追っかけVODは最低3プロファイルから開始、需要に応じてバックグラウンドで増やす。

可観測性とSLO

• QoEメトリクス: 起動時間（2秒未満目標）、再生失敗率（0.5%以下）、リバッファ率（0.2%/分以下）、平均ビットレート、エラーコード分布。
• RUMと合成監視: 実ユーザーSDKで地区別可視化、加えて5分間隔の合成監視。SLO違反で自動ルート切替とアラート。
• データ活用: 視聴完了率×サムネ/タイトルA/Bの因果を日次で検証。タグの正確性はGeminiで自動チェック、差分を編集者に返す。

編集/審査の効率化

• モデレーション: 暴力/不適切表現はGeminiで一次判定、グレーは人手確認。字幕の誤変換はClaudeで自然さをレビュー。
• メタ生成: ChatGPTで要約・チャプター案、サムネはMidjourneyで３案作成→クリック率で採用。AI提案は必ず人が最終確認。

身近な企業活用例：単一CDNで詰まった中堅メディアのやり直し

地方で情報番組を配信する従業員60名のオンラインメディア。週1回の生配信（同時視聴6万）で、単一CDNと固定ラダーのまま本番を迎え、序盤10分で再生失敗が4%に達し炎上。原因はオリジン直撃（キャッシュ未命中）と、動きの激しいシーンに対してビットレート不足でリバッファが多発したことでした。

改善では、オリジン前段にシールドキャッシュを挟み、マニフェストTTLを5秒に短縮。CDNを2社化し、プレイヤーSDKでリアルタイム切替を実装。ラダーはPer-Title自動化し、動きの激しいコーナーだけ高ビットレートを許可。さらにLow-Latency HLSを導入して起動時間を平均1.7秒に短縮。モデレーションと字幕はGeminiとClaudeで一次整形、サムネはMidjourneyで3パターンを回し、ChatGPTでタグ補完。結果、再生失敗率は0.6%まで低下、ピークトラフィックでもオリジン直撃は1%未満に収まり、配信コストは月間で27%削減されました。

教訓はシンプルで、配信の安定性は「キャッシュ効率×適切なラダー×多経路化」の三点セットで決まること、そして編集と配信をつなぐメタデータ運用が視聴体験とコストを同時に良くする、ということでした。

動画プラットフォーム事業は、映像を届けるだけでなく、制作・審査・配信・計測を一本のパイプラインに束ねる設計が勝負どころです。ここで示した構成は、規模や要件に応じて部品を差し替えやすく、SLOとコストのバランスを取りやすい作りになっています。企画や収益化のテンポを落とさず、安定配信と高速な改善サイクルを両立する足場として有効です。