Amazon IVS ライブ配信 本番運用 Vol1 — 低遅延配信とReal-Time

1. ライブ配信の課題とAmazon IVS全体像

1-1. 本記事のゴール

Amazon IVS (Interactive Video Service) は、Twitchが長年の大規模ライブ配信で培ったノウハウをAWSのマネージドサービスとして提供したものです。自前でWebRTCサーバーやHLS変換基盤を構築・運用するコストを大幅に削減しながら、エンタープライズ品質のライブ配信基盤を短期間で構築できます。

本記事を読み終えると、次のことができるようになります。

• ユースケースに応じてIVSのチャンネルタイプ (STANDARD / ADVANCED_HD / ADVANCED_SD / BASIC) を選定できます
• Real-Time Streaming (WebRTCベース・300ミリ秒未満の双方向配信) を設計・実装できます
• IVS Chatのモデレーション設計や録画・VOD化パイプラインを本番運用レベルで構築できます
• CloudWatchとEventBridgeを使ったストリーム監視体制を整え、コスト最適化の判断基準を持てます

1-2. 読者像

本記事が想定する読者は、AWSの基本的な操作経験があり、ライブ配信基盤の設計・構築を担うバックエンドエンジニアまたはインフラエンジニアです。EC2・S3・CloudFrontの基礎知識があることを前提とし、動画配信の深い専門知識は必要ありません。

次のような方に特に役立ちます。

• ライブコマースプラットフォームの配信基盤を担当するエンジニア
• 社内イベントやウェビナーをライブ配信したい方
• ゲーム実況・eスポーツ中継の低遅延配信を検討しているメディア企業のエンジニア
• IVSの概要は知っているが、本番環境に適用するための詳細設計を学びたい方

1-3. ライブ配信基盤の4つの課題

ライブ配信基盤を自前で構築・運用しようとすると、次の4つの課題に直面します。

① 遅延

視聴者が映像を受け取るまでの遅延は、体験の質を大きく左右します。一般的なHTTP Live Streaming (HLS) の遅延は15〜30秒程度であり、視聴者のコメントや反応が映像に追いつきません。ライブコマースでは、出演者がコメントにリアルタイムで反応することが売上に直結するため、高遅延は致命的な問題になります。

② スケール

人気配信の開始時や大規模イベントでは、数万〜数十万の接続が一斉に集中します。自前インフラでこのピーク負荷に対応するには、常時ピーク相当のサーバーを保持するか、複雑なオートスケーリング設計が必要です。いずれもコストと運用負荷が高くなります。

③ インタラクション

現代のライブ配信には、テキストチャット・スタンプ・投票・商品カード表示など、視聴者が参加するリアルタイムインタラクションは不可欠です。これらをゼロから構築するには、WebSocketサーバー・メッセージキュー・モデレーション機能を、映像配信とは独立して用意する必要があります。

④ コスト構造

映像の取り込み・トランスコード・CDN配信を自前構成すると、固定費が高くなりがちです。視聴者が少ない時間帯でもトランスコードサーバーとオリジンサーバーは常時稼働が必要なためです。従量課金モデルへの移行が、スタートアップや中小企業において特に重要な課題となっています。

1-4. Amazon IVSの全体像

Amazon IVSはこれら4つの課題をまとめて解決するマネージドライブ配信サービスです。2020年にAWSがリリースし、Twitchの配信基盤技術をAPIとして提供しています。自前でCDNやトランスコードサーバーを管理することなく、APIを呼び出すだけでライブ配信エンドポイントが即座に準備されます。

IVSは大きく2つの配信モードを提供します。

Low-Latency Streaming

RTMPS / RTMP / SRT プロトコルで映像を取り込み、IVSがトランスコードしてCDN経由でHLS配信します。エンドツーエンドの遅延は3〜5秒程度です。OBS StudioなどのRTMP対応エンコーダをそのまま使えます。IVS Playerを組み合わせることで低遅延HLSプロトコルが有効になり、標準HLSプレイヤーでは実現できない3〜5秒遅延を達成できます。

チャンネルタイプは STANDARD / ADVANCED_HD / ADVANCED_SD / BASIC の4種類で、解像度・ビットレート上限とコストのバランスで選択します。

Real-Time Streaming

WebRTCベースのステージ (Stage) アーキテクチャを使い、300ミリ秒未満の双方向配信を実現します。最大12ホストが同時に映像・音声を送信でき、最大10,000人の視聴者がリアルタイムで参加できます。サーバーサイドコンポジション機能を使うと、複数のホスト映像を合成してS3に録画したり、Low-Latency Streamingに転送して大規模配信したりできます。

2024年11月にMultitrack Video対応が追加され、STANDARDチャンネルの入力コストを大幅に削減できるようになりました。2025年6月にはE-RTMPが正式サポートされ、エンコーダの選択肢が広がっています。

1-5. ユースケース別の活用パターン

IVSが特に力を発揮するユースケースを整理します。

ライブコマース

Low-Latency StreamingとIVS Chatを組み合わせることで、視聴者のコメントに素早く反応しながら商品購入を促す体験を構築できます。タイムドメタデータ機能を使うと、配信タイムラインに同期して商品カードをポップアップ表示するインタラクティブ演出も実現できます。ECプラットフォームとの統合もAPIベースで設計できます。

ゲーム実況・eスポーツ

ADVANCED_HD / ADVANCED_SD チャンネルを使うことで、高品質な映像配信を自社プラットフォームで提供できます。ゲームプレイの映像を低遅延でプレイヤーや観客に届けながら、IVS Chatでリアルタイムなコミュニケーションを成立させることができます。

ウェビナー・社内配信

Real-Time Streamingを使うと、最大12人のパネリストが双方向で発言できるウェビナー形式を構築できます。視聴者は最大10,000人対応です。終了後は自動でS3に録画されるため、そのままVODコンテンツとして公開できます。

ライブスポーツ

競技会場からRTMPSで映像を取り込み、複数チャンネルを切り替えながら大人数に同時配信するマルチカメラ構成も、IVSのAPIで制御できます。CloudFrontと組み合わせることで、グローバル配信の遅延を最小化できます。

1-6. 本記事の構成

本記事は以下の流れで進みます。

§2ではLow-Latency Streamingの取り込みプロトコルとチャンネルタイプ選定を解説します。§3ではReal-Time Streaming (WebRTCステージ) の設計を詳解します。§4ではIVS Chatのモデレーション設計とライブコマース連携パターンを扱います。§5では録画・S3保存・VOD化・CloudFront連携のパイプライン構築を解説します。§6では監視・コスト管理・本番運用のベストプラクティスをまとめます。§7はライブコマース/ウェビナー/全社配信の実戦統合パターンです。§8では詰まりポイントとアンチパターンを整理します。

1-7. 配信方式の使い分けナビ

AWSにはIVS以外にもライブ配信に利用できるサービスがあります。用途によって適切なサービスが異なるため、選定基準を整理します。

一方向の大規模配信にはIVS Low-Latencyが最適解です。双方向のインタラクションが必要な場合はIVS Real-Timeを選びます。放送局グレードの冗長構成やSCTE-35広告挿入が必要な場合はAmazon MediaLiveが適しています。

MediaLiveとIVSの組み合わせも可能です。MediaLiveで放送グレードの映像処理 (テロップ・字幕・広告挿入) を行い、その出力をIVSに流して低遅延配信するハイブリッド構成は、テレビ放送とオンライン配信を両立するケースで採用されています。前作「ゲーム・メディア基盤 本番運用 Vol1」ではMediaLiveの詳細を解説しているため、放送グレード要件の方はそちらも参照してください。

1-8. IVSのリージョン対応とサービス制限

利用可能なリージョン

IVSの制御プレーン (チャンネル管理・API) は特定リージョンでのみ利用できます。東京リージョン (ap-northeast-1) は2022年3月に追加されており、日本国内のユーザー向けにIPレイテンシを最小化した配信基盤を構築できます。データ主権や国内法令への対応が求められる日本企業のサービスにも対応できる点は、IVSを選ぶ重要な理由の一つです。

主要なサービスクォータ

IVSにはデフォルトのサービスクォータがあります。大規模イベントの実施前には必ずAWSコンソールの「Service Quotas」で上限を確認し、必要であれば事前にリミット引き上げ申請を行ってください。

大規模イベントでは複数チャンネルを事前作成しておき、必要に応じてチャンネルを切り替える構成が安全です。1チャンネルあたりストリームキーが1つのみのため、複数の配信者が同一チャンネルに接続するシナリオでは、stream takeover機能を活用してバックアップ配信者への切り替えを実現します。

IVSのブラウザサポートはChrome・Firefox・Safari・Edgeの最新2バージョンを対象としています。モバイルではiOS 14以降のSafariとAndroid ChromeでIVS Playerが動作確認されています。

2. IVS基礎 — Low-Latency Streamingとチャンネルタイプ

2-1. Low-Latency Streamingの仕組み (3〜5秒低遅延)

Amazon IVSのLow-Latency Streamingは、配信者から視聴者までの遅延を3〜5秒に抑えるマネージドライブ配信サービスです。従来の自前HLS/DASH基盤では10〜30秒の遅延が一般的でしたが、IVSはAWSのグローバルネットワークとTwitch由来の最適化技術を活用し、インフラ運用の複雑さをAWSに委ねながら低遅延を実現します。

取り込みプロトコル

IVSは以下3種類のプロトコルでエンコーダからのストリームを受け取ります。

本番環境ではRTMPS (ポート443) の使用を推奨します。ポート1935は多くの企業ファイアウォールやISPで遮断されており、予期しない接続障害の原因になります。SRTは衛星回線や不安定なネットワーク環境での配信に適しています。

映像・音声コーデック

IVSはH.264映像コーデックとAACオーディオコーデックを使用します。エンコーダから受け取ったストリームはチャンネルタイプに応じてトランスコード (再エンコード) またはトランスマックス (再多重化のみ) が行われ、視聴者向けにHLS形式で配信されます。

IVS Playerの必須性

Low-Latency Streamingで低遅延を実現するには、IVS Player SDKの使用が必須です。hls.jsやVideoJSなどのサードパーティHLSプレイヤーはIVS独自の低遅延HLS拡張プロトコルに対応していないため、通常のHLS遅延 (10〜30秒) しか実現できません。IVS Playerは以下のプラットフォーム向けにSDKが提供されています。

• Web: Amazon IVS Player (player.js)
• iOS: Amazon IVS Player SDK for iOS (Swift/Objective-C)
• Android: Amazon IVS Player SDK for Android (Kotlin/Java)
• React Native向けラッパーも提供

各プラットフォームでIVS PlayerをWebページ・モバイルアプリに組み込むことで、3〜5秒のエンドツーエンド遅延を達成できます。視聴者体験の中核となるプレイヤー実装において、IVS Playerの採用は低遅延配信の大前提となります。

配信フローの概要

Low-Latency Streamingの取り込みから配信までの基本フローは以下のとおりです。

1. 配信者 (OBSなどの配信ソフト) がRTMPS/RTMP/SRTでIVSに映像ストリームを送信します
2. IVSがチャンネルタイプに応じてトランスコード (またはトランスマックス) を実施します
3. AWSグローバルエッジネットワークでHLSセグメントが生成・配信されます
4. 視聴者側のIVS Playerが低遅延HLSを受信して再生します

このフロー全体をAWSが管理するため、CDNセットアップ・エンコードサーバー構築・スケーリングといった従来必要だったインフラ作業が不要になります。

2-2. チャンネルタイプ比較 (STANDARD/ADVANCED_HD/ADVANCED_SD/BASIC)

IVSのチャンネルタイプは4種類あり、配信品質・コスト・トランスコードの有無が異なります。用途と予算に合わせて適切なタイプを選定することが運用コスト最適化の基本です。

STANDARD

STANDARDはデフォルトのチャンネルタイプです。最大1080p60フレーム・8.5Mbpsの高品質ライブ配信に対応し、IVS側のトランスコードによりアダプティブビットレート (複数解像度) での配信が可能です。視聴者の回線速度に合わせて最適な解像度が自動選択されるため、幅広いネットワーク環境の視聴者に対して品質を最大化できます。ゲーム配信・高品質コンテンツ・大規模視聴者向け配信に適しています。

STANDARDとMultitrack入力の挙動変化

STANDARDにMultitrack入力を組み合わせた場合は重要な挙動変化があります。Multitrack入力を使用するとSTANDARDのトランスコード挙動がトランスマックス挙動に切り替わります。このとき複数解像度のアダプティブビットレート配信は、OBSなどのエンコーダ側でのマルチトラック生成によって実現されます。Multitrack入力を有効化する際はエンコーダ側で全必要解像度のトラックを設定してから行う必要があります。詳細は「2-3. Multitrack Video」を参照してください。

ADVANCED_HD

ADVANCED_HDは最大720pを上限としたトランスコードチャンネルです。名称に「HD」が含まれますが上限は720pであり、1080p配信にはSTANDARDが必要な点に注意します。プリセットが2種類用意されており、HD品質でSTANDARDよりコストを抑えたい場合に適しています。

ADVANCED_SD

ADVANCED_SDは入力解像度を上限としたトランスコードチャンネルです。入力より高い解像度へのアップコンバートは行われません。SD品質で十分な用途や、入力品質以上へのトランスコードが不要な配信に選択します。

BASIC

BASICはトランスマックス (再多重化のみ) を行うシンプルなチャンネルタイプです。IVS側での映像再エンコードを行わず、エンコーダからの入力をそのままHLSに変換します。最大1080p・3.5Mbps、または480p・1.5Mbpsのシングルレンディション (単一解像度) 配信になります。アダプティブビットレート非対応のため、視聴者全員が同一品質の映像を受信します。コストを最小化したシンプルな配信・社内配信・イベント配信に最適です。

チャンネルタイプ選定のポイント

チャンネルタイプ選定では「アダプティブビットレートが必要か」「最大解像度はどこまで必要か」「予算制約はどの程度か」の3点を整理します。アダプティブビットレートが不要な固定環境向け配信ではBASICを選択することでコストを最小化できます。視聴者の回線品質がばらつく大規模配信ではSTANDARD (またはADVANCED系) でトランスコードを活用します。入力コスト削減を優先する場合はMultitrack Videoとの組み合わせを検討します。

2-3. Multitrack Video (入力コスト削減)

2024年11月にリリースされたMultitrack Video機能は、OBSなどのエンコーダで複数品質トラックを1つのRTMPS/RTMP接続で送信することで、STANDARD入力コストを最大75%削減 ($2.00/h → $0.50/h) する機能です。

従来方式との違い

従来のSTANDARD配信では、エンコーダが単一品質のストリームをIVSに送信し、IVS側のフルトランスコードにより複数解像度を生成していました。このトランスコード処理がSTANDARDチャンネルの入力コストを高くしている要因です。

Multitrack Video使用時は、OBS v30以降のエンコーダが複数解像度・ビットレートのトラックを含むマルチトラックストリームを生成してIVSに送信します。IVSはトランスマックス (再多重化) するだけでアダプティブビットレート配信を実現するため、IVS側のトランスコード負荷が大幅に削減されます。その結果として入力料金が下がります。

OBS設定の手順

Multitrack Videoを利用するには以下の設定が必要です。

1. OBS v30以降を使用します (Multitrack Video出力対応バージョン)
2. IVSチャンネルでMultitrack Videoを有効化します (コンソールまたはCreateChannel APIで設定)
3. OBSの出力設定でMultitrack Video出力モードを選択します
4. 各トラック (1080p/720p/480pなど) の解像度・ビットレート・フレームレートを個別に設定します

重要な注意点

Multitrack入力を有効化するとSTANDARDチャンネルはトランスコード→トランスマックス挙動に切り替わります。この挙動変化を理解せずにMultitrack入力を有効化すると、IVS側でのトランスコードが行われないため、エンコーダ側で設定していないレンディションは配信されなくなります。OBSのトラック設定で意図する全解像度 (例: 1080p/720p/480p) を確認してから有効化します。

コスト削減の効果

月間100時間のSTANDARD配信の場合、Multitrack Video導入前後のコスト差は無視できない水準になります。大規模・常設の配信チャンネルを運用している場合、Multitrack Video対応環境が整っていれば積極的に採用を検討する価値があります。特に配信時間が長い番組型コンテンツやゲーム実況チャンネルでは、コスト削減効果が顕著に表れます。

2-4. エンコーダ設定とストリームテイクオーバー

推奨エンコーダ設定

IVSで安定した低遅延配信を実現するには、エンコーダ側の設定が品質を大きく左右します。

キーフレーム間隔の設定

キーフレーム間隔はHLSセグメントの生成タイミングに直接影響します。IVSでは2秒を推奨しており、2秒ごとにHLSセグメントが生成されることで低遅延配信が安定します。1秒に設定するとさらに遅延を短縮できますが、キーフレーム頻度が増加するためエンコーダの処理負荷とビットレートへの影響を考慮する必要があります。

OBS設定例: 「出力」→「エンコーダ設定」→「キーフレーム間隔: 2」

CBR (固定ビットレート) の重要性

VBR (可変ビットレート) では映像内容によってビットレートが変動し、IVSのバッファ管理が不安定になります。CBRを設定することでエンコーダが一定ビットレートを維持し、IVSが安定してHLSセグメントを生成できます。映像が激しく動くゲームシーンやアクション映像では特にCBRの効果が顕著で、低遅延配信の品質を継続的に確保できます。

ストリームテイクオーバー

同一チャンネルへ複数の接続が試みられた際の動作制御がストリームテイクオーバーです。バックアップ配信者の設定や、OBSが一時的に切断されて再接続する際の挙動をIVSのストリームキー優先度設定で制御できます。優先度の高い接続が割り込むことでシームレスな配信者切り替えが実現でき、冗長構成でのライブ配信運用を安定させます。ストリームキーごとに優先度 (0〜100) を設定でき、数値が大きいほど高優先度になります。

2-5. チャンネル設定とストリームキー管理

チャンネルの作成とパラメータ

IVSチャンネルはAWS Management ConsoleまたはCreateChannel APIで作成します。チャンネル作成時に設定できる主なパラメータは以下のとおりです。

チャンネルを作成すると取り込みエンドポイント (Ingest endpoint) と再生URL (Playback URL) が自動発行されます。取り込みエンドポイントはOBSなどのエンコーダに設定するRTMPS URLです。再生URLはIVS Playerに設定するHLS URLです。

ストリームキーの管理

ストリームキーはエンコーダがIVSチャンネルに接続する際の認証情報です。チャンネルごとに複数のストリームキーを作成でき、それぞれに優先度を設定できます。

ストリームキーの運用で重要な点は以下のとおりです。

• ストリームキーは公開しません: 漏洩すると任意のエンコーダが不正配信できるため、AWS Secrets Managerなどで安全に管理します
• 定期的な更新: 本番環境では定期的にストリームキーをローテーションします
• 環境別管理: 開発・テスト・本番でチャンネルとストリームキーを分離します

待機時間モード (Latency Mode)

チャンネルの待機時間モードは NORMAL と LOW の2種類があります。LOW モードでは視聴者の遅延をさらに短縮できます。一方、視聴者側のネットワーク品質が低い場合はバッファリング増加の可能性があります。視聴者ネットワーク環境が安定しているライブコマースや社内配信では LOW モードが有効です。一般公開の大規模配信では NORMAL モードから開始し、視聴者の品質データを確認しながら LOW への切り替えを検討します。

3. Real-Time Streaming — 300ms双方向配信

3-1. ステージとパーティシパント (最大12ホスト・10,000視聴者)

Real-Time Streamingは、Amazon IVSが提供する双方向インタラクション対応の配信方式です。Low-Latency Streamingが一方向の視聴者向け配信を前提とするのに対し、Real-Time StreamingはWebRTCを基盤に複数参加者が双方向でメディアをやり取りできます。バーチャルイベント・ライブコマース・オンライン競技など、参加者間のリアルタイムインタラクションが重要な用途に最適です。

ステージ(Stage)の基本概念

Real-Time Streamingの中心リソースは「ステージ(Stage)」です。ステージは参加者が集まる仮想空間で、参加者の接続状態やメディア配信を管理します。AWS CLIまたはAPIで作成し、複数のパーティシパント(Participant)がトークンを使って参加します。

# ステージ作成
aws ivs-realtime create-stage \
  --name my-live-stage \
  --region ap-northeast-1

ステージの主要スペックは以下のとおりです。

「ホスト」とは映像・音声を送信できる参加者であり、「視聴者」はメディアを受信するのみです。「最大12名」はホスト(参加者)の上限であり、視聴者の上限ではないことに注意してください。視聴者は最大10,000名まで同時接続できます。

パーティシパントトークンの設計

参加者はパーティシパントトークン(JWT)を使ってステージへ接続します。トークンにはホスト/視聴者の権限(capability)を設定します。

# パーティシパントトークン生成 (ホスト権限)
aws ivs-realtime create-participant-token \
  --stage-arn arn:aws:ivs:ap-northeast-1:123456789012:stage/xxxxx \
  --duration 60 \
  --capabilities PUBLISH SUBSCRIBE \
  --user-id host-user-001 \
  --attributes '{"role":"host","displayName":"配信者A"}'

# パーティシパントトークン生成 (視聴者権限)
aws ivs-realtime create-participant-token \
  --stage-arn arn:aws:ivs:ap-northeast-1:123456789012:stage/xxxxx \
  --duration 60 \
  --capabilities SUBSCRIBE \
  --user-id viewer-001

PUBLISH 権限を持つ参加者はメディアを送信でき、SUBSCRIBE のみの参加者は受信専用となります。ホストには PUBLISH SUBSCRIBE の両方を、視聴者には SUBSCRIBE のみを付与するのが基本設計です。

トークンの有効期間 (duration) は1〜20,160分(最大14日)で設定可能です。短命トークン(60分程度)を発行し、バックエンドAPIで都度生成する設計が安全です。

attributes フィールドには最大5つのキー/バリューペアを格納でき、表示名や役職などのメタデータをクライアントから参照できます。トークン生成時に attributes を指定しておくと、他の参加者がメディア受信時にメタデータを取得でき、UI表示や権限制御に活用できます。

ステージのライフサイクル管理

ステージは長期間削除せずに使い回せます。あるいはセッションごとに作成/削除する運用も可能です。パーティシパント課金はトークンがアクティブな時間に対して発生するため、利用後は速やかに接続を切断してコストを抑えます。ステージ自体の保持コストは発生しません。イベント終了後にステージを放置すると誤接続によるパーティシパント時間課金が継続するリスクを生むため、イベント管理システムとステージのライフサイクルを連動させる設計を推奨します。

3-2. WebRTCベースの300ms低遅延配信

Real-Time StreamingはブラウザやモバイルSDKで標準サポートされるWebRTCを基盤とし、300ms未満の超低遅延を実現します。ICE(Interactive Connectivity Establishment)によるP2Pネゴシエーション、DTLSによる暗号化、SRTPによるメディア転送を使用します。

WebRTCとAmazon IVSの関係

Amazon IVSはWebRTCのシグナリングサーバーとSTUN/TURNサーバーをマネージドで提供します。開発者はシグナリングインフラを自前で構築する必要がなく、IVS Real-Time SDKを呼び出すだけで接続を確立できます。

• シグナリング: WebSocketでIVSシグナリングサーバーに接続します。SDP(Session Description Protocol)のオファー/アンサーを自動交換します。
• ICEネゴシエーション: IVS提供のSTUN/TURNサーバーでNAT越えを自動処理します。
• メディア転送: E2EのSRTP暗号化です。ホスト間でのP2P転送が基本です。

E-RTMP multitrack ingest (2025年6月対応)

2025年6月に追加されたE-RTMP multitrack ingestを使うと、OBSなどのエンコーダからRTMP/RTMPSでマルチトラックのメディアをステージへ直接取り込めます。

配信ソフト(OBS) → E-RTMP → IVS Stage → 参加者へ配信

この方式はABR(アダプティブビットレート)配信に対応しており、追加費用なしで複数品質のストリームを生成できます。モバイル視聴者と高画質視聴者に同じステージから最適品質を届けることが可能です。

従来のWebRTC SDKによる接続と比較してエンコーダ側での実装コストが低く、既存のOBSワークフローをそのままReal-Time Streamingへ移行できます。

低遅延を安定させる設計条件

300ms未満の遅延を安定させるには以下の条件を満たすことが推奨されます。

ユーザーのネットワーク品質に応じてビットレートが動的に調整されます。IVS SDKはCongestion Controlアルゴリズムでパケットロスや遅延を検知し、自動的に品質を下げて接続を維持します。急激なネットワーク劣化でもフリーズではなく品質低下で対応するため、視聴体験への影響を最小化できます。

SDK対応プラットフォーム

IVS Real-Time SDKは以下のプラットフォームをサポートします。

• Web: amazon-ivs-web-broadcast (JavaScript SDK) — Chrome/Firefox/Safari対応
• iOS: AmazonIVSBroadcast (Swift/Obj-C)
• Android: com.amazonaws:ivs-broadcast (Kotlin/Java)

サーバーサイドでのステージ管理(トークン発行・コンポジション起動)はAWS SDKやCLIで操作します。

3-3. サーバーサイドコンポジション

Real-Time Streamingのサーバーサイドコンポジション機能を使うと、複数ホストの映像をIVS側でレイアウト合成してから配信できます。クライアント側でのミキシング実装が不要となり、Low-Latency Streamingチャンネルや録画S3への出力が可能です。

コンポジションの基本構成

サーバーサイドコンポジションはステージのメディアストリームを取得し、指定レイアウトで合成して複数の出力先へ転送します。

[ホストA] ─┐
[ホストB] ─┼──→ IVS Composition ──→ Low-Latency Channel (HLS配信)
[ホストC] ─┘  │
  └──→ S3 (コンポジット録画)

コンポジションの出力先として、Low-Latency Streamingチャンネル(HLS配信)とS3への録画を同時設定できます。大規模視聴者向けにはLow-Latency Streaming(数十万人規模)経由で配信し、Real-Time Stageはホスト間双方向インタラクション専用に限定するハイブリッド設計が典型的です。

コンポジションの起動コマンド

aws ivs-realtime start-composition \
  --stage-arn arn:aws:ivs:ap-northeast-1:123456789012:stage/xxxxx \
  --layout '{"grid":{"featuredParticipantAttribute":"role"}}' \
  --destinations '[
 {
"channel": {
  "channelArn": "arn:aws:ivs:ap-northeast-1:123456789012:channel/yyyyy",
  "encoderConfigurationArns": [
 "arn:aws:ivs:ap-northeast-1:123456789012:encoder-configuration/zzzzz"
  ]
}
 },
 {
"s3": {
  "bucketName": "my-ivs-recordings",
  "prefix": "compositions/",
  "encoderConfigurationArns": [
 "arn:aws:ivs:ap-northeast-1:123456789012:encoder-configuration/zzzzz"
  ]
}
 }
  ]'

レイアウトは grid(グリッド)と pip(ピクチャーインピクチャー)を選択できます。featuredParticipantAttribute で主ホストの attribute 名を指定すると、指定ホストをメイン画面に大きく表示するレイアウトが自動適用されます。例えばトークン発行時に attributes '{"role":"main_host"}' を設定し、featuredParticipantAttribute: "role" で main_host 値を持つホストをフィーチャーする設計が実用的です。

Real-Time録画の2方式

Real-Time Streamingの録画には個別参加者録画とコンポジット録画の2方式があります。

個別参加者録画は後工程での編集用途に向いており、トリミングや再編集が容易です。コンポジット録画はライブ配信の完成形をそのまま保存し、追加処理なしでVOD配信できます。

録画ファイルはS3に保存され、EventBridgeから録画開始/終了イベントを受信できます。録画完了後にLambdaでMediaConvertを呼び出してVOD用にトランスコードするパターンが一般的です。

3-4. Low-Latencyとの使い分け基準

Real-Time StreamingとLow-Latency Streamingは技術基盤も課金体系も異なるため、要件に応じて適切に選択する必要があります。

Real-Time Streamingを選ぶ基準

• ホストが複数おり、互いのリアクションが重要な場合(バーチャルイベント・ゲーム実況・オンライン授業)
• 視聴者とホストが300ms以内でやり取りする必要がある場合(Q&Aセッション・競技配信)
• ホスト数が12名以下に収まる場合
• 双方向インタラクションが要件の中心である場合

Low-Latency Streamingを選ぶ基準

• 数万〜数十万規模の視聴者への一方向配信が主目的の場合
• 3〜5秒の遅延が許容できる場合(スポーツ中継・コンサート配信・ニュース配信)
• OBSなどの既存エンコーダワークフローをそのまま活用したい場合

ハイブリッド構成によるスケール解決

Real-Time Stagingのサーバーサイドコンポジション出力をLow-Latency Channelへ転送することで、双方向性と大規模配信を両立できます。

[ホスト 最大12名] ──→ IVS Stage (Real-Time, 300ms双方向)
↓ サーバーサイドコンポジション
IVS Low-Latency Channel ──→ 視聴者 数十万人 (HLS)

ホスト間は300msで双方向通信しながら、視聴者には3〜5秒遅延のHLSで大規模配信できます。全社総会・大規模ウェビナー・eスポーツ実況など、少数の参加者と多数の視聴者が混在するユースケースに最適な構成です。

4. チャット・インタラクション

4-1. IVS Chatの基本構成 (ルーム・トークン認証)

IVS Chatは、ライブ配信に付随するチャット機能をフルマネージドで提供するサービスです。チャットルームを作成し、参加者ごとにトークンを発行することで、視聴者とのリアルタイムインタラクションを実現します。IVSチャンネルとは独立したリソースとして設計されており、ライブ配信の有無に関係なくチャット機能を利用できます。

チャットルームの作成

チャットルームはAWS Management ConsoleまたはAPIで作成します。ルームには一意のARNが割り当てられ、最大メッセージレート (MaximumMessageRatePerSecond) や最大メッセージ文字数 (MaximumMessageLength) はルーム作成時に設定します。

aws ivschat create-room \
  --name "my-live-room" \
  --maximum-message-rate-per-second 10 \
  --maximum-message-length 500

参加者トークン (JWT) の発行フロー

IVS Chatでは、参加者がチャットへ接続する際にサーバーサイドで発行したトークンを使用します。トークンはJWT形式で、有効期限や権限情報を含みます。発行フローは次のとおりです。

1. クライアント (ブラウザ/アプリ) がバックエンドAPIにトークンリクエストを送信します
2. バックエンドがCreateChatToken APIを呼び出し、署名済みトークンを取得します
3. トークンをクライアントに返却します
4. クライアントがトークンを使用してチャットルームのWebSocketに接続します

aws ivschat create-chat-token \
  --room-identifier "arn:aws:ivschat:ap-northeast-1:123456789012:room/xxxxxxxxxxx" \
  --user-id "viewer-12345" \
  --capabilities "SEND_MESSAGE" \
  --session-duration-in-minutes 60

トークンには以下の属性を設定できます。

attributes に設定した値はChat SDKを通じて全参加者に公開されるため、機密情報 (メールアドレス・内部IDなど) は含めないように注意します。

4-2. 権限モデルとロール設計

IVS Chatの権限は capabilities フィールドで制御します。参加者ごとに異なる権限を付与することで、一般視聴者とモデレーターを区別します。

権限の種類

一般視聴者には SEND_MESSAGE のみ、モデレーターには3つすべてを付与するのが標準的な設計です。配信者本人は attributes にロール情報 (例: "role": "host") を付与し、フロントエンドで視聴者・モデレーター・配信者を視覚的に区別します。

aws ivschat create-chat-token \
  --room-identifier "arn:aws:ivschat:ap-northeast-1:123456789012:room/xxxxxxxxxxx" \
  --user-id "moderator-001" \
  --capabilities "SEND_MESSAGE" "DELETE_MESSAGE" "DISCONNECT_USER" \
  --session-duration-in-minutes 120 \
  --attributes role=moderator,displayName=モデレーター太郎

4-3. メッセージレビューとLambdaモデレーション

IVS Chatの中核機能の一つがメッセージレビューです。Lambda関数をチャットルームのメッセージレビューハンドラとして登録することで、メッセージの送信前・送信後に自動フィルタリングを実施できます。

フィルタリングタイミングの種類

Lambda関数の実装例 (PRE_SEND)

Lambda関数は指定されたシグネチャに従ってメッセージを受け取り、ALLOW または DENY を返します。DENY を返すとメッセージはルームに配信されません。

import json

BLOCKLIST = ["スパム", "禁止ワード"]

def handler(event, context):
 message_content = event.get("Content", "")
 user_id = event.get("Sender", {}).get("UserId", "")

 for word in BLOCKLIST:
  if word in message_content:
return {"ReviewResult": "DENY"}

 return {
  "ReviewResult": "ALLOW",
  "Content": message_content,
  "Attributes": {
"moderationPassed": "true",
"userId": user_id
  }
 }

Lambda関数をチャットルームに設定するには、ルーム作成時または更新時に messageReviewHandler を指定します。

aws ivschat create-room \
  --name "moderated-room" \
  --message-review-handler \
 uri="arn:aws:lambda:ap-northeast-1:123456789012:function:ivs-chat-moderator",\
 fallbackResult="ALLOW"

fallbackResult はLambda関数がエラーになった際の既定動作です。ALLOW (許可) または DENY (拒否) を選択します。本番環境ではLambda関数の冗長性を高めたうえで ALLOW を設定し、ユーザー体験を優先するケースが多いです。高リスクコンテンツを扱うサービスでは DENY にしてフェールセーフ動作を優先します。

4-4. モデレーション操作 — メッセージ削除とユーザー切断

モデレーター権限を持つ参加者やバックエンドシステムから、不適切なメッセージの削除や悪意あるユーザーの切断ができます。

メッセージ削除 (DeleteMessage)

削除されたメッセージは即座にルーム全参加者の画面から消えます。Chat SDKはメッセージ削除イベント (MESSAGE_DELETE) を受信し、フロントエンドのUI更新を自動的にトリガーします。

aws ivschat delete-message \
  --room-identifier "arn:aws:ivschat:ap-northeast-1:123456789012:room/xxxxxxxxxxx" \
  --id "メッセージID" \
  --reason "禁止コンテンツのため削除"

ユーザー切断 (DisconnectUser)

aws ivschat disconnect-user \
  --room-identifier "arn:aws:ivschat:ap-northeast-1:123456789012:room/xxxxxxxxxxx" \
  --user-id "spammer-999" \
  --reason "スパム行為による強制退出"

切断されたユーザーはWebSocket接続を即座に失います。同一ユーザーIDでの再接続を防ぐには、バックエンドのトークン発行ロジックでBANリストを管理し、該当ユーザーへのトークン発行を拒否する設計が必要です。IVS Chat自体にはBANリスト機能がないため、アプリケーション層での実装が求められます。

4-5. 映像モデレーション連携 — Rekognition + Lambda + IVS

テキストモデレーションに加え、映像コンテンツのモデレーションにはAmazon Rekognitionとの連携が有効です。AWSは公式サンプルパターンとしてIVS + Rekognitionの映像モデレーションアーキテクチャを公開しています。

アーキテクチャの概要

1. EventBridge + Lambda で定期的にIVSサムネイルAPIからフレーム画像を取得します
2. 取得フレームをAmazon Rekognitionの DetectModerationLabels APIで解析します
3. 不適切コンテンツ (暴力・成人向け等) を検出した場合はSNS通知またはストリームを停止します
4. 結果をモデレーターダッシュボードまたはSlackに通知します

import boto3

rekognition = boto3.client("rekognition")

def check_frame(image_bytes):
 response = rekognition.detect_moderation_labels(
  Image={"Bytes": image_bytes},
  MinConfidence=75
 )
 labels = response.get("ModerationLabels", [])
 flagged = [l for l in labels if l["Confidence"] >= 75]
 return flagged

映像モデレーションは完全自動化よりも人間のレビューを介したセミオート運用が現実的です。Rekognitionで高確信度の違反コンテンツを自動停止し、中間帯の疑義コンテンツはモデレーターキューに入れる設計が推奨されます。誤検知によるストリーム強制停止はユーザー体験を大きく損なうため、自動停止のしきい値は慎重に設定します。

4-6. ライブコマース向けインタラクション設計

IVS + IVS Chatの組み合わせは、ライブコマース (ライブショッピング) 基盤として広く活用されています。視聴者のリアルタイムインタラクション (コメント・リアクション・購入ボタン) を低遅延の映像と同期させることが重要です。

タイムドメタデータによる商品連動

IVSチャンネルの配信ストリームにタイムドメタデータを埋め込むことで、映像と同期したイベントを全視聴者に配信できます。配信者が「商品カードを表示」すると、タイムドメタデータが全視聴者に届き、商品カードUIが展開されます。

aws ivs put-metadata \
  --channel-arn "arn:aws:ivs:ap-northeast-1:123456789012:channel/xxxxxxxxxxx" \
  --metadata '{"action":"showProduct","productId":"prod-001","price":3980}'

フロントエンドでは player.addEventListener('textMetadataCue', handler) でメタデータを受信し、商品カードの表示・非表示を制御します。タイムドメタデータは映像フレームと同期して配信されるため、商品カードと映像のずれを最小化できます。

IVS Chat によるリアクション・購入イベント設計

購入リアクション・スタンプはIVS Chatのメッセージとして送信するのが一般的です。メッセージタイプを attributes で区別し、フロントエンドが通常コメントと購入イベントを分けて描画します。

{
  "action": "SEND_MESSAGE",
  "requestId": "req-001",
  "content": "購入しました！",
  "attributes": {
 "type": "purchase",
 "productId": "prod-001",
 "userId": "viewer-12345"
  }
}

購入イベントはバックエンドのLambdaメッセージレビュー (PRE_SEND) で検出し、購買データベースへの書き込みや在庫更新と連動させる設計が堅牢です。IVS Chatを購入イベントのトランスポートとして活用することで、映像・チャット・購買を一元管理できます。

複数ルーム管理と大規模イベント設計

大規模ライブコマースイベントでは、複数の配信チャンネルと複数のチャットルームを組み合わせます。ルームはチャンネルとの対応が1:1である必要はなく、商品カテゴリ別・ゲスト出演者別に複数ルームを設け、視聴者がルーム間を移動できる設計も実現可能です。大規模イベントではルームへの同時接続数の上限をAWSサポートへ事前申請し、リミット引き上げを確認してから本番に臨みます。

4-7. Chat SDK対応とプラットフォーム展開

IVS Chatは以下のプラットフォーム向けにSDKを提供しています。

各SDKはWebSocketの接続管理・再接続・メッセージイベントのハンドリングを抽象化しており、アプリケーション開発者はチャットUIの実装に集中できます。

Chat料金の目安

IVS Chatの料金はメッセージ送信数と配信数に基づきます。

1,000人が同時視聴するライブで1通のメッセージが送信されると、配信コストは $0.08 × 1,000 / 1,000 = $0.08 が発生します。コメントが活発なライブコマースでは配信コストが支配的になるため、ルームの MaximumMessageRatePerSecond を適切に設定してコストを管理します。

5. 録画・再生・配信統合

5-1. Auto-Record to S3とサムネイル生成

Amazon IVSは、チャンネルレベルでライブ配信の自動録画をサポートしています。配信開始と同時にHLSセグメントがS3バケットに保存されるため、運用者が手動でトリガーする必要はありません。

自動録画の設定手順

IVSコンソールまたはCLIでチャンネルに録画設定 (RecordingConfiguration) を紐付けます。

# 録画設定の作成
aws ivs create-recording-configuration \
  --name "s3-recording" \
  --destination-configuration s3={bucketName=my-ivs-recordings}

# 録画設定付きチャンネルの作成
aws ivs create-channel \
  --name "production-channel" \
  --recording-configuration-arn arn:aws:ivs:ap-northeast-1:123456789012:recording-configuration/abcdefgh12345

録画設定はチャンネルから分離された独立リソースとして管理されます。同一の録画設定を複数チャンネルで共有できるため、大規模なマルチチャンネル環境でも一元管理が可能です。

録画フォーマット: HLS構造

録画されたコンテンツはHLS (HTTP Live Streaming) 形式でS3に格納されます。ディレクトリ構造は以下のとおりです。

s3://my-ivs-recordings/{channel-arn}/
  └── {streamId}/
├── master.m3u8  # マスタープレイリスト
├── 480p30/
│├── playlist.m3u8  # バリアントプレイリスト
│└── media-XXXXXX.ts# TSセグメント (約2秒/セグメント)
├── 720p60/
│├── playlist.m3u8
│└── media-XXXXXX.ts
└── 1080p60/
 ├── playlist.m3u8
 └── media-XXXXXX.ts

マスタープレイリスト (master.m3u8) が全解像度バリアントへの参照を持つため、IVS PlayerやHLS対応プレイヤーはネットワーク状況に応じてアダプティブビットレートでVOD再生できます。

サムネイル自動生成

IVSはライブ配信中に定期的なサムネイルを自動生成します。デフォルトは60秒間隔ですが、最短1秒間隔まで短縮できます。2023年7月のアップデートでレンディションフィルタがサポートされ、特定解像度のみのサムネイル生成も可能になりました。

# サムネイル間隔5秒・HD解像度のみに設定
aws ivs create-recording-configuration \
  --name "thumbnail-config" \
  --destination-configuration s3={bucketName=my-ivs-recordings} \
  --thumbnail-configuration \
 recordingMode=INTERVAL,targetIntervalSeconds=5,\
 resolution=HD,storage=LATEST,SEQUENTIAL

storage パラメータで LATEST (最新1枚のみ上書き保存) と SEQUENTIAL (全サムネイルを番号付きで保存) を組み合わせて指定できます。ライブページのサムネイル表示には LATEST のみで十分ですが、アーカイブ用途では SEQUENTIAL も有効にすることで任意の時点のサムネイルをS3から取得できます。

Real-Time録画 (2024年12月 GA)

Real-Time Streamingのステージを使ったライブセッションでも、2024年12月のGA以降は録画とサムネイル生成が利用可能です。個別参加者録画 (individual recording) とコンポジット録画 (composite recording) の2つのモードがあります。

個別録画モードでは参加者ごとに独立したHLSファイルが生成されるため、収録後に自由にレイアウトを再構成できます。コンポジット録画モードはステージの合成映像をそのままHLS録画するため、即時VOD提供に適しています。

5-2. 再生SDK実装パターンとBroadcast SDK

Web: player.js

IVS Web Player (amazon-ivs-player) はAmazonのCDNから配信されるJavaScriptライブラリです。IVS独自の超低遅延配信プロトコルをサポートし、HLSフォールバックも内蔵しています。

<script src="https://player.live-video.net/1.x.x/amazon-ivs-player.min.js"></script>
<video id="video-player"></video>
<script>
const { isPlayerSupported } = IVSPlayer;
if (isPlayerSupported) {
  const player = IVSPlayer.create();
  player.attachHTMLVideoElement(document.getElementById('video-player'));
  player.load('https://PLAYBACK_URL.m3u8');
  player.play();
}
</script>

ライブストリームのPlayback URLはIVSチャンネルのレスポンスから取得します。VODの場合は録画されたHLSのマスタープレイリストURLを指定します。player.jsはライブとVODで同一APIを使用するため、切り替えはURLの変更だけで完了します。

iOS SDK (AmazonIVSPlayer)

Swift Package Manager (SPM) または CocoaPods で追加できます。

import AmazonIVSPlayer

let player = IVSPlayer()
player.delegate = self
player.load(URL(string: "https://PLAYBACK_URL.m3u8")!)
player.play()

// プレイヤーをUIViewに組み込む
let playerView = IVSPlayerView()
playerView.player = player
view.addSubview(playerView)

iOSではAVFoundationとIVS SDKの橋渡しが内部で処理されるため、アプリ側はIVSPlayerのAPIだけを扱います。バックグラウンド再生やAirPlay対応も標準でサポートされています。

Android SDK (AmazonIVSPlayer)

Gradle依存関係に追加後、以下のパターンで実装します。

val player = IVSPlayer.create(context)
player.addListener(playerListener)
player.load(Uri.parse("https://PLAYBACK_URL.m3u8"))
player.play()

// PlayerViewにバインド
playerView.player = player

VODとライブで同一のAPIを使用します。ExoPlayerとの連携も公式にサポートされており、既存のExoPlayerベースのプレイヤーにIVSソースを組み込む形も選択できます。

Broadcast SDK: ライブ配信クライアントとauto-reconnect

IVS Broadcast SDKを使用することで、ブラウザやモバイルアプリから直接RTMPSで配信を行えます。OBSなどの外部ソフトウェアなしで、Webカメラ・マイクを使ったライブ配信アプリを構築できます。

import { create, BroadcastClientEvents, ConnectionState } from 'amazon-ivs-web-broadcast';

const client = create({
  ingestEndpoint: 'rtmps://INGEST_ENDPOINT:443/app/',
  streamConfig: IVSBroadcastClient.BASIC_LANDSCAPE,
});

await client.addVideoInputDevice(videoDevice, 'camera1', { index: 0 });
await client.addAudioInputDevice(audioDevice, 'mic1');
await client.startBroadcast('sk_ap-northeast-1_STREAMKEY');

ネットワーク断が発生した場合、Broadcast SDKは自動的に再接続を試みます。IVSのstream takeover機能により、再接続後も同一のPlayback URLで配信が継続されます。視聴者側への影響を最小限に抑えるため、断線後の再接続は別のstream keyを使わずに同一チャンネルへの再接続として処理されます。

client.on(BroadcastClientEvents.CONNECTION_STATE_CHANGE, (state) => {
  if (state === ConnectionState.DISCONNECTED) {
 const delay = Math.min(1000 * Math.pow(2, retryCount), 30000);
 setTimeout(() => client.startBroadcast(streamKey), delay);
  }
});

5-3. VOD化とCloudFront連携

録画されたHLSコンテンツをVODとして配信する最も一般的な構成は、S3 + CloudFrontの組み合わせです。

S3→CloudFront VOD配信の構成

S3バケットにはCloudFrontからのアクセスのみ許可するOAC (Origin Access Control) を設定し、直接S3 URLを公開しない構成が基本です。

視聴者
  └── CloudFront Distribution (エッジキャッシュ)
  ├── Origin: S3バケット (録画HLS格納) + OAC
  └── Behavior:
  ├── /*/master.m3u8 → Cache TTL短め (プレイリスト更新対応)
  └── /*/media-*.ts  → Cache TTL長め (セグメント不変)

CloudFront経由でVOD配信することで、グローバルエッジキャッシュにより視聴者への配信レイテンシを削減できます。特にライブ後のアーカイブ視聴が世界中から発生するケースでは、S3直接配信に比べてスループットと応答速度が大幅に改善します。

IVS Playerとの統合

CloudFrontのドメインを使ったPlayback URLは、IVS Playerで直接再生できます。player.jsはHLSプロトコルをネイティブサポートしているため、CloudFront経由のVODをライブストリームと同一のAPIで再生できます。

// ライブ: IVS Playback URL
player.load('https://XXXXXXXX.live-video.net/api/video/v1/...');

// VOD: CloudFront経由S3のmaster.m3u8
player.load('https://d1234567890.cloudfront.net/{streamId}/master.m3u8');

ライブ終了後に録画URLへ自動切り替えする実装では、IVSのEventBridgeイベント (Stream End) を受信した時点でフロントエンドに通知し、PlayerのloadメソッドにVOD URLを渡すパターンが一般的です。

EventBridgeによる録画完了通知とVODパイプライン

録画が完了すると、EventBridgeに IVS Recording State Change イベントが送信されます。

{
  "source": "aws.ivs",
  "detail-type": "IVS Recording State Change",
  "detail": {
 "recording_status": "Recording End",
 "channel_name": "production-channel",
 "recording_s3_key_prefix": "{channel-arn}/{streamId}"
  }
}

recording_ended イベントをトリガーにLambdaを起動し、recording_s3_key_prefix からmaster.m3u8のURLを構築してDynamoDBに登録することで、VODライブラリの自動更新パイプラインを実現できます。また、MediaConvertと連携してHLSをMP4に変換したり、Rekognitionでコンテンツを解析したりする拡張パイプラインも構築できます。

これらのコンポーネントを組み合わせることで、ライブ配信の録画→S3保存→CloudFront配信→IVS Player再生までの一貫したパイプラインを構築できます。ライブ後の即時VOD提供が求められるスポーツ・eスポーツ・オンラインセミナー用途では、自動録画とEventBridgeによる完了通知を組み合わせたパイプラインが実績ある設計パターンとなっています。

6. 監視・運用・コスト

6-1. CloudWatchによるストリーム監視

IVSはCloudWatchにストリームの健全性と視聴状況を示すメトリクスを自動で送信します。主要なメトリクスは次のとおりです。

取り込み関連メトリクス

IngestVideoBitrateを監視することで、エンコーダ側の帯域不足や設定ミスを早期に検知できます。正常な配信であればIngestVideoBitrateはチャンネルタイプの上限近くで安定します。値が著しく低下した場合は、ストリームが切断または劣化しているサインです。

CloudWatchのアラームを設定してIngestVideoBitrateが閾値を下回った際にSNSで通知することで、配信者やオペレーターが即時対応できる体制を整えられます。

視聴関連メトリクス

ConcurrentViewsは1分単位で集計されます。ピーク視聴者数をCloudWatch Dashboardでリアルタイムに可視化することで、CDN負荷の見積もりやキャパシティプランニングに活用できます。

Real-Time Streaming固有のメトリクス

Real-Time Streamingではステージ単位のメトリクスが追加されます。

PublishParticipantsが上限12人に近づいている場合は、新規参加者の受け入れ制御が必要になります。アプリケーション層でトークン発行数を管理することで、オーバーサブスクリプションを防げます。

6-2. EventBridgeによるストリームイベント処理

IVSはストリームの状態変化をEventBridgeのイベントとして発行します。EventBridgeルールを設定することで、LambdaやSNSへの連携が容易になります。

主なイベントタイプ

IVS Stream StartイベントをLambdaで受け取り、Slack通知やダッシュボードを更新する構成が一般的です。IVS Recording Endイベントで録画S3パスを取得し、自動的にMediaConvertに投入してVOD変換するパイプラインも構築しやすい構成です。

詰まりポイント: キーフレーム間隔とイベント遅延

IVS Stream Startイベントは、エンコーダがストリームを送り始めてからすぐには発行されません。IVSはキーフレームを受信した後にストリームを認識するため、エンコーダのキーフレーム間隔が長いほどStream Startイベントの発行が遅れます。

キーフレーム間隔が2秒の場合、Stream Startイベントの発行まで6〜7秒かかることがあります。配信開始のトリガーとしてIVS Stream Startイベントを使う場合は、この遅延を考慮した設計が必要です。

エンコーダのキーフレーム間隔は2秒以下に設定することを推奨します。OBS Studioでは「エンコーダの設定」→「キーフレーム間隔」で設定できます。

6-3. 視聴分析とQoS監視

CloudWatchのConcurrentViewsに加えて、IVSプレイヤーSDK側からのQoSデータを収集することで、視聴品質の全体像を把握できます。

IVS Playerはエラーイベントや品質変更イベントをコールバックで通知します。フロントエンドでこれらのイベントをキャプチャし、CloudWatch カスタムメトリクスやサードパーティの分析サービス (Datadog・New Relic等) に送信する設計が推奨されます。

player.addEventListener('error', (event) => {
  console.error('Player error:', event.detail);
});

player.addEventListener('qualityChanged', () => {
  const quality = player.getQuality();
  console.log('Quality changed to:', quality.name, quality.bitrate);
});

同時視聴者数が急激に増加しているにもかかわらず視聴品質が低下している場合、CDN側の帯域が逼迫している可能性があります。CloudWatchアラームでConcurrentViewsとエラー率を組み合わせて監視することで、早期に問題を検知できます。

6-4. 料金体系の整理

IVSの料金は「入力 (取り込み)」と「出力 (視聴)」の2軸で課金されます。料金はリージョンと利用段階によって変動するため、最新の単価は必ずAWS公式料金ページで確認してください。以下は参考値であり、変更される場合があります。

取り込み (入力) 料金

入力料金はチャンネルタイプと取り込み時間 (時/月) で決まります。

STANDARDのMultitrack Video機能を使うと、取り込み料金を約75%削減できます。OBSやその他のMultitrack対応エンコーダからの映像を取り込む場合に有効です。

視聴出力料金

視聴出力料金は視聴者数×視聴時間で計算されます。段階課金構造があり、視聴時間が多いほど単価が下がります。視聴時間の合計が増えるにつれて単価が段階的に低下するため、大規模配信ほどコスト効率が高まります。視聴者数のピーク管理と長時間視聴セッションの比率を把握することが、コスト見積もりの鍵です。

Real-Time Streamingのパーティシパント料金

Real-Time Streamingは、映像を送信するPublish参加者と映像を視聴するSubscribe参加者それぞれに時間単位で課金されます。料金はリージョンによって異なるため、公式料金ページで確認してください。

30日間無料トライアル

IVSは初回利用から30日間、一定量まで無料で利用できる無料枠があります。新規サービス立ち上げ時にコストをかけずに本番検証できるため、積極的に活用してください。

6-5. コスト最適化パターン

チャンネルタイプの適切な選定

配信品質要件が高くない場合はBASICチャンネルを選択することで取り込みコストを抑えられます。社内向け告知配信や品質要件が低い一般配信ではBASIC ($0.20/時) を、スポーツや高品質ゲーム実況ではSTANDARDまたはADVANCEDを使う形で使い分けると効果的です。

Multitrack Videoの活用 (STANDARD)

STANDARDチャンネルでMultitrack Videoを有効にすると、取り込み料金が $2.00/時 から $0.50/時 に削減されます。Multitrack対応のエンコーダ (OBS 30.0以降、FFmpegなど) が必要ですが、高品質を維持しながらコストを最大75%削減できます。月間200時間の配信であれば、Multitrack導入だけで月額 $300 の削減になります。

視聴時間コストの管理

IVSのコストは取り込みよりも視聴出力に支配されるケースが多いです。同時視聴者数と視聴継続時間の積がコスト総量を決めます。CloudWatchのConcurrentViewsを定期的に監視し、予算超過リスクを早期に検知するコストアラームを設定することを推奨します。

本番運用チェックリスト

以下の項目を本番移行前に確認してください。

• チャンネルの取り込みエンドポイントURLとストリームキーをAWS Secrets Managerで安全に管理している
• CloudWatchアラームがIngestVideoBitrateの低下時にSNS通知するよう設定されている
• EventBridgeルールがIVS Stream StartイベントでLambdaを起動するよう設定されている
• IVS Recording Endイベントの未受信時にアラートが上がる設計になっている
• IAMポリシーでIVSのリソースアクセスが最小権限になっている (ivs:PutMetadata / ivs:StopStream 等の必要な権限のみ付与)
• ConcurrentViewsの月次予算アラームを設定している
• エンコーダのキーフレーム間隔が2秒以下になっていることを確認している

6-6. ストリーム切断と自動再接続の運用設計

本番配信では、ネットワーク不安定・エンコーダクラッシュ・配信者の誤操作などに起因したストリーム切断に備える設計が必要です。再接続時の視聴者体験への影響を最小限に抑えることが、本番品質の鍵となります。

IVSのstream takeover機能

IVSチャンネルへの再接続は、同一のストリームキーを使用することで「stream takeover」として扱われます。配信が再開されると視聴者側のPlayback URLは変わらず、数秒以内に新しい映像が届きます。再接続のたびに新しいチャンネルを作成する必要がないため、運用がシンプルです。

エンコーダ側の自動再接続設定

OBS StudioではAdvanced Outputの「Automatically reconnect」を有効にすることで、切断後に自動的に再接続を試みます。リトライ遅延は初回2秒、最大遅延30秒のエクスポネンシャルバックオフが推奨されます。再接続頻度が高い場合は、エンコーダのCPU負荷・ネットワーク帯域・ISP側の問題を順番に調査します。

EventBridgeによる切断検知と通知

IVS Stream Endイベントを受信したLambdaから、SNS/Slack/PagerDutyへ即時通知する設計を入れておくと、配信停止を素早く検知できます。Stream Startイベントで自動復旧を確認し、一定時間 (例: 5分) 以内にStream Startが届かない場合は緊急対応フローを起動する仕組みを合わせて用意しておくことを推奨します。

7. 実戦統合パターン — ライブコマース/全社配信/ウェビナー基盤

7-1. ライブコマース基盤のE2E設計

ライブコマースはAmazon IVSの代表的な活用事例です。配信中に商品カードを表示し視聴者が購入できる体験を実現するには、IVS + IVS Chat + バックエンドAPIの組み合わせが必要です。

基本アーキテクチャ

[配信者] → IVS Channel (Low-Latency) / IVS Stage (Real-Time)
  ↓ タイムドメタデータ
[視聴者] ← IVS Player SDK (Web/iOS/Android)
  ↓ 商品カード表示トリガー
[購入フロー] API Gateway → Lambda → DynamoDB (商品/在庫)
  ↓
SQS → 注文処理 → 決済

IVSのタイムドメタデータ機能を活用し、配信者が商品紹介のタイミングでメタデータをストリームに埋め込むと、視聴者のプレーヤーに自動で商品カードが表示されます。

タイムドメタデータの実装例

import boto3
import json

ivs = boto3.client('ivs', region_name='ap-northeast-1')

def push_product_card(channel_arn: str, product_id: str, price: int):
 metadata = json.dumps({
  "type": "product_card",
  "product_id": product_id,
  "price": price,
  "action": "show"
 })
 ivs.put_metadata(
  channelArn=channel_arn,
  metadata=metadata
 )

視聴者側のIVS Player SDKは onTimedMetadata イベントで受信し、UIに商品カードをオーバーレイ表示します。タイムドメタデータは映像フレームと同期して配信されるため、商品カードと映像のタイミングのずれを最小化できます。

IVS Chatによるライブ購入フロー

IVS ChatのMessage Reviewを活用すると、チャット経由での購入命令をLambdaで処理できます。例えば視聴者が /buy product-001 と入力したメッセージをLambdaが傍受し、購入フローを起動するパターンが実用的です。

[視聴者] チャット送信 "/buy product-001"
↓
IVS Chat Message Review Lambda
  ・購入コマンド検出
  ・SQSへエンキュー
↓
購入処理Lambda → DynamoDB 在庫チェック → 決済API
↓
EventBridge → 配信者通知 (購入者名・商品名)

Step Functionsによる購入フロー管理

複数ステップの購入処理(在庫確保→決済→配送予約→通知)をStep Functionsで管理すると、部分失敗時のリカバリが容易です。在庫確保に成功して決済に失敗した場合、Step Functionsのエラーハンドラで在庫を自動返却します。

{
  "Comment": "ライブコマース購入フロー",
  "StartAt": "CheckInventory",
  "States": {
 "CheckInventory": {
"Type": "Task",
"Resource": "arn:aws:lambda:::function:check-inventory",
"Next": "ProcessPayment",
"Catch": [{"ErrorEquals": ["OutOfStock"], "Next": "NotifyOutOfStock"}]
 },
 "ProcessPayment": {
"Type": "Task",
"Resource": "arn:aws:lambda:::function:process-payment",
"Next": "ReserveShipping",
"Catch": [{"ErrorEquals": ["PaymentFailed"], "Next": "ReleaseInventory"}]
 },
 "ReserveShipping": {"Type": "Task", "Resource": "...", "Next": "NotifySuccess"},
 "NotifySuccess": {"Type": "Task", "Resource": "...", "End": true},
 "NotifyOutOfStock": {"Type": "Task", "Resource": "...", "End": true},
 "ReleaseInventory": {"Type": "Task", "Resource": "...", "Next": "NotifyPaymentFailed"},
 "NotifyPaymentFailed": {"Type": "Task", "Resource": "...", "End": true}
  }
}

DynamoDBによる商品/在庫管理

ライブコマース中は急激なリクエスト増加が想定されます。DynamoDB On-DemandモードとDAXキャッシュの組み合わせで、在庫参照のスパイクを吸収します。在庫更新はCondition Expressionで楽観ロックを実装し、在庫のダブルデクリメントを防止します。

table.update_item(
 Key={"product_id": product_id},
 UpdateExpression="SET stock = stock - :dec",
 ConditionExpression="stock >= :dec",
 ExpressionAttributeValues={":dec": 1}
)

7-2. 全社配信・ウェビナー基盤の設計

全社配信やウェビナーは、Real-Time Stagingのハイブリッド構成(Real-Time + Low-Latency)が適しています。登壇者間はReal-Timeで双方向インタラクション、聴衆にはLow-Latency HLSで大規模配信します。

全社配信アーキテクチャ

[役員/登壇者 最大12名] → IVS Stage (Real-Time, 300ms双方向)
↓ サーバーサイドコンポジション
IVS Low-Latency Channel → CloudFront → 全社員 (HLS配信)
↓
  S3 (録画) → MediaConvert → VOD配信 (後日閲覧)

最大12名の登壇者をステージで接続し、サーバーサイドコンポジションで合成したストリームをLow-Latencyチャンネルへ転送します。CloudFront経由で数万人の社員へHLS配信が可能です。

Cognito認証による有料配信・社内限定配信

視聴者を認証で制限するには、Amazon Cognitoとバックエンドトークン発行APIを組み合わせます。

[視聴者] → Cognito認証 → ID Token取得
 ↓
 API Gateway (Cognito Authorizerで保護)
 ↓
 Lambda: パーティシパントトークン発行
 ・Cognitoグループで視聴権限チェック
 ・有料会員/社員にのみSUBSCRIBEトークン発行

Cognitoユーザープールのグループ機能を使い、有料会員グループのみトークン発行APIへのアクセスを許可します。無料会員は別チャンネルへリダイレクトするか、機能制限版の視聴体験を提供します。

Q&Aインタラクション設計

ウェビナーのQ&AセッションをIVS Chatで実現するパターンです。IVS Chatのモデレーション機能を活用し、承認済みの質問のみ登壇者に届けます。

[聴衆] IVS Chat送信 (質問)
 ↓
Message Review Lambda
  ・NGワードフィルタ
  ・質問タイプを attributes に付与
 ↓ (承認)
モデレーターダッシュボードに表示
 ↓ (登壇者への転送)
登壇者が回答 → 全聴衆のチャットに配信

EventBridgeによる配信状態管理

配信の開始/終了/録画完了をEventBridgeで自動処理します。

7-3. メディアサービス連携 (MediaConvert/CloudFront/GameLift)

IVSは単体ではなく、周辺AWSサービスと連携することでエンタープライズ規模のメディアインフラを構成できます。

CloudFront + IVS: VOD再生最適化

IVSの録画S3バケットをCloudFrontで配信することで、VOD再生のレイテンシを最小化できます。

aws cloudfront create-distribution --distribution-config '{
  "Origins": [{
 "DomainName": "my-ivs-recordings.s3.ap-northeast-1.amazonaws.com",
 "S3OriginConfig": {
"OriginAccessIdentity": "origin-access-identity/cloudfront/XXXXX"
 }
  }],
  "DefaultCacheBehavior": {
 "AllowedMethods": ["GET","HEAD"],
 "CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6",
 "ViewerProtocolPolicy": "redirect-to-https"
  }
}'

S3への直接アクセスをOAC(Origin Access Control)でブロックし、CloudFront経由のみに制限することでセキュリティを確保します。

録画からVOD変換の自動化

import boto3
import json

MC_ENDPOINT = "https://mediaconvert.ap-northeast-1.amazonaws.com"

def handler(event, context):
 detail = event['detail']
 s3_prefix = detail['recordingS3KeyPrefix']

 mc = boto3.client('mediaconvert', endpoint_url=MC_ENDPOINT)
 mc.create_job(
  Role='arn:aws:iam:::role/MediaConvertRole',
  Settings={
"Inputs": [{"FileInput": f"s3://my-ivs-recordings/{s3_prefix}"}],
"OutputGroups": [{
 "OutputGroupSettings": {
  "Type": "HLS_GROUP_SETTINGS",
  "HlsGroupSettings": {
"Destination": f"s3://my-vod-bucket/outputs/{detail['channel']}/",
"SegmentLength": 6
  }
 },
 "Outputs": [
  {"VideoDescription": {"Width": 1280, "Height": 720}},
  {"VideoDescription": {"Width": 854, "Height": 480}}
 ]
}]
  }
 )

EventBridgeから録画完了イベントを受信したLambdaがMediaConvertジョブを起動し、HLSセグメントをVOD用S3バケットへ出力します。CloudFrontで配信することで、ライブ配信終了直後にVODが自動公開されます。

GameLiftとの組み合わせ (ゲーム実況パターン)

ゲーム実況配信では、GameLiftのゲームセッションとIVSの配信セッションを連携させます。

GameLift ゲームセッション開始
 ↓ EventBridge
Lambda: IVS Stage作成 + 参加者トークン発行
 ↓
ゲームクライアント → IVS Stage参加 (配信開始)
 ↓
IVS Chat (ゲーム内チャット連動・スコア表示)
 ↓
GameLift ゲームセッション終了
 ↓ EventBridge
Lambda: IVS Stage終了 + 録画アーカイブ処理

GameLiftのフリートスケールに合わせてIVSステージを動的に作成/削除することで、スケーラブルなゲーム実況インフラを構築できます。IVS Chatの attributes にゲームスコアやランク情報を連携し、チャット上にリアルタイムで表示するパターンも実用的です。

コスト最適化の設計指針

IVSとCloudFrontを組み合わせる際のコスト最適化ポイントをまとめます。

8. 詰まりポイントとアンチパターン・まとめ

8-1. よくある詰まりポイントと解決策

[1] サードパーティHLSプレイヤーで低遅延が出ない

症状: hls.jsやVideoJSなどのプレイヤーでIVSを再生すると、遅延が10〜30秒程度になる。

原因: IVSのLow-Latency Streamingは独自の低遅延HLS拡張プロトコルを使用しており、サードパーティHLSプレイヤーはこの拡張に対応していません。

解決策: IVS純正のPlayer SDK (Web: player.js, iOS/Android対応) を使用します。IVS Playerは低遅延HLS拡張を完全に実装しており、3〜5秒の低遅延配信を実現します。サードパーティHLSプレイヤーをどうしても使いたい場合は、低遅延の実現を諦めて標準的なHLS遅延 (10〜30秒) になることを認識したうえで選択します。

[2] キーフレーム間隔/CBR未設定で遅延が増大する

症状: 配信開始直後は低遅延でも、配信が続くにつれて遅延が徐々に増大します。または遅延が安定しない状態になります。

原因: エンコーダのキーフレーム間隔が長い (例: 10秒) か、VBR設定になっている場合、IVSがHLSセグメントを生成するタイミングがずれ、バッファが積み上がります。

解決策: OBSなどのエンコーダ設定でキーフレーム間隔を2秒に設定し、レート制御をCBRに変更します。OBSでは「出力」→「エンコーダ設定」→「キーフレーム間隔: 2」「レート制御: CBR」で対応できます。設定変更後は配信を再起動して遅延が安定していることを確認します。

[3] STANDARDでMultitrack入力するとトランスマックス挙動に変わり想定外の品質になる

症状: Multitrack Videoを有効化後、特定の解像度が配信されなくなった。アダプティブビットレートが期待通りに動作しない。

原因: STANDARD + Multitrack入力時はIVS側のトランスコードが無効になりトランスマックス (再多重化のみ) 挙動に切り替わります。これはAWS公式ドキュメントに明記されていますが見落としやすい仕様です。

解決策: Multitrack Video使用時は、OBSなどエンコーダ側で必要な全解像度 (例: 1080p/720p/480p) のトラックを生成する必要があります。IVSはそれを受け取り多重化するだけです。エンコーダ設定を変更せずにMultitrack入力だけ有効化すると、配信できる解像度が入力トラック数に依存します。Multitrack Video有効化前にOBSのトラック設定を必ず確認します。

[4] サポートされていないリージョンで制御プレーンエラーが発生する

症状: 特定リージョンでCreateChannel APIが失敗する。コンソールでチャンネル作成ができない。

原因: IVSの制御プレーン (チャンネル管理・録画設定など) はすべてのリージョンで利用できるわけではありません。東京リージョンの場合はap-northeast-1が対象です。リージョンの組み合わせを誤ると制御プレーンとデータプレーンの不一致エラーが発生します。

解決策: AWS公式ドキュメントで最新のIVSサポートリージョンを確認します。コンソール・CLIで操作するリージョンが正しいか再確認します。AWS CLIで --region ap-northeast-1 を明示的に指定してリージョン誤りを防ぎます。

[5] Real-Timeの「12人」を全参加者上限と誤認する

症状: ステージに12人以上の視聴者を参加させようとするとエラーになる。

原因: Real-Time Streamingではホスト (画面/音声を送信する参加者) が最大12人です。ただし、視聴のみのパーティシパント (SUBSCRIBER) は別途最大10,000人まで参加できます。12人はPUBLISHER (送信者) の上限であり、全参加者の上限ではありません。

解決策: IVSのReal-Timeでは参加者タイプを「PUBLISHER (送信者)」と「SUBSCRIBER (受信のみ)」に分けて管理します。インタラクティブ参加 (画面/音声送信) が必要なユーザーをPUBLISHER、視聴のみのユーザーをSUBSCRIBERとして設定します。PUBLISHER数が12を超えないようにアプリケーション側で制御が必要です。

[6] RTMP (非TLS) でポート1935がファイアウォールにブロックされる

症状: OBSから配信開始しても接続が確立されない。特に企業ネットワークや一部のISP環境で発生する。

原因: RTMPのデフォルトポートは1935ですが、多くのファイアウォールや企業ネットワークポリシーでポート1935は遮断されています。

解決策: IVSのRTMPS (TLS暗号化) はポート443を使用します。ポート443はHTTPS通信と同ポートのため、ほぼすべてのネットワーク環境で通過できます。OBSのサーバー設定を rtmps:// スキームのIVSエンドポイントURLに変更します。IVSコンソールから取得できるRTMPS取り込みエンドポイントURLをそのまま使用します。

[7] Real-Timeステージの録画設定を見落とす

症状: Real-Timeステージで配信したが録画が残っていない。または個別録画とコンポジット録画の違いを理解せずに設定した。

原因: Real-Time Streamingのステージ録画は自動ではなく、明示的な設定が必要です。また録画形式に「個別録画 (Individual Recording)」と「コンポジット録画 (Composite Recording)」の2種類があり、用途に応じて選択が必要です。

解決策: ステージ作成時にAuto-Record設定を有効化します。個別録画は各パーティシパントのストリームを別々のファイルとして録画します。コンポジット録画はサーバーサイドコンポジションにより全パーティシパントを合成した単一ファイルとして録画します。後から動画編集が必要な場合は個別録画、視聴者向けVOD配信が目的の場合はコンポジット録画を選択します。

[8] ADVANCED_HDとADVANCED_SDの命名で1080p対応と誤認する

症状: ADVANCED_HDが「HD品質 = 最大1080p」を意味すると思い込んでいたところ、実際には720pが上限でした。

原因: チャンネルタイプ名から最大解像度を誤推測しやすい点があります。ADVANCED_HDの「HD」は一般的な「高解像度」を意味するのではなく、IVSの「ADVANCED tier HD品質」を指します。1080p60配信にはSTANDARDが必要です。

解決策: IVSコンソールでチャンネルタイプを確認する際は、各タイプの最大解像度・ビットレートをドキュメントで明示的に確認します。STANDARD = 最大1080p60 (8.5Mbps)、ADVANCED_HD = 最大720p、ADVANCED_SD = 入力解像度上限、BASIC = シングルレンディション (1080p/3.5Mbps or 480p/1.5Mbps) です。

[9] 録画のレンディションフィルタ未設定で全解像度が保存されコスト増大につながる

症状: 録画設定後、S3のストレージコストが想定以上に高い。複数の解像度のHLSセグメントが全てS3に保存されている。

原因: デフォルトの録画設定では全レンディション (全解像度バリアント) がS3に保存されます。STANDARD + トランスコードの場合は1080p/720p/480p/360pの全てが保存されるため、ストレージ・転送コストが増大します。

解決策: 録画設定でレンディションフィルタを設定し、必要な解像度のみを録画対象にします。VOD配信で使用する解像度のみに絞ることで、S3ストレージコストを大幅に削減できます。録画設定のRenditionFilterパラメータで不要なレンディションを除外します。

8-2. アンチパターン → 正解

❌ すべての配信用途にSTANDARDチャンネルを使用する

アンチパターン: 配信用途を問わず一律にSTANDARDチャンネルを選択し、入力コストを最大化してしまう。

✅ 正解: 配信要件に合わせてチャンネルタイプを選択します。シンプルな1〜2人配信・社内配信でアダプティブビットレートが不要な場合はBASICを選択します。HD品質でコストを抑えたい場合はADVANCED_HDを検討します。STANDARDはゲーム配信・高品質コンテンツなど最大1080p60が必要な場合に使用します。チャンネルタイプ選定だけで入力コストを数分の1に抑えられます。

❌ Real-Time Streamingを「低遅延配信の強化版」として一方向配信に使用する

アンチパターン: Real-Time Streamingをライブ配信の上位互換と誤解し、単純な一方向ライブ配信にReal-Timeを使用してしまう。

✅ 正解: Real-Time Streamingはインタラクティブ参加型のWebRTC双方向通信です。視聴者が画面・音声を送信するホストとして参加するライブコマース・ウェビナー・ゲームショーに適しています。一般的な一方向ライブ配信 (視聴者は見るだけ) にはLow-Latency Streamingが適切です。用途を混同すると不要なコストと複雑な実装が発生します。

❌ Multitrack Video未使用でSTANDARD入力料金を払い続ける

アンチパターン: STANDARDチャンネルで通常のシングルトラックストリームを送り続け、IVSのトランスコード費用を最大化してしまう。

✅ 正解: OBS v30以降 + Multitrack Video対応環境では、Multitrack入力を有効化することでSTANDARD入力コストを最大75%削減できます。配信時間が長い・常設配信チャンネルを運用している場合は積極的にMultitrack Videoを検討します。エンコーダ側で全解像度トラックを設定してから有効化することを忘れずに確認します。

❌ CBRを設定せずVBRで配信する

アンチパターン: OBSのレート制御をVBR (可変ビットレート) のままにして配信を開始する。高品質シーンでビットレートが急上昇し、IVSバッファが溢れて遅延が増大する。

✅ 正解: OBSなどの配信ソフトでレート制御をCBR (固定ビットレート) に設定します。CBRにすることで安定したビットレートを維持し、IVS側のバッファ管理が安定して低遅延配信を継続できます。キーフレーム間隔2秒と組み合わせることで最良の効果が得られます。

❌ 録画設定なしでReal-Timeステージを稼働させVOD配信の機会を逃す

アンチパターン: Real-Timeステージを立ち上げて配信したが、録画設定を入れていなかったためアーカイブが残らない。配信終了後にVOD活用ができず機会損失になる。

✅ 正解: Real-Timeステージを作成する際に録画設定 (Auto-Record) を有効化します。コンポジット録画を有効化することで、全パーティシパントを合成した単一ファイルがS3に保存され、配信終了後のVOD配信やアーカイブ活用が可能になります。録画設定はステージ作成後でも変更できますが、設定変更前の配信分は録画されないため、初期設定で必ず有効化します。

❌ ストリームキーをソースコードや設定ファイルにハードコーディングする

アンチパターン: OBSの設定ファイルや配信スクリプトにストリームキーをプレーンテキストで埋め込み、Gitリポジトリにコミットしてしまう。Publicリポジトリへの誤コミットや社内リポジトリの権限設定の不備で露出すると、不正配信のリスクが生じます。

✅ 正解: ストリームキーはAWS Secrets ManagerまたはAWS Systems Manager Parameter Store (SecureString) で管理します。配信スクリプトからはAPIで動的に取得する設計にします。OBSの設定ファイルは .gitignore に追加してバージョン管理対象から除外します。漏洩が疑われる場合はすぐにストリームキーを削除・再発行します。IAMポリシーでストリームキーの取得権限を最小化することも重要です。

❌ サービスクォータを確認せずに大規模ライブイベントを本番移行する

アンチパターン: 数万人規模のライブイベントを計画しているにもかかわらず、IVSのサービスクォータ (チャンネル数・同時配信数) を事前確認せずに本番当日を迎え、クォータ超過で配信が停止する。

✅ 正解: AWS Consoleの「Service Quotas」でIVSの制限を事前確認します。デフォルトのチャンネル数上限は100です。大規模イベントやマルチチャンネル配信では本番2週間前にAWSサポートへクォータ引き上げリクエストを送り、承認を得ておきます。EventBridgeでストリームイベントを監視し、クォータ超過による配信停止を検知できる体制も整えます。

8-3. まとめ

Amazon IVSは、Twitchの技術基盤から生まれたマネージドライブ配信サービスです。インフラ構築・管理の複雑さをAWSが吸収し、開発チームはアプリケーションとコンテンツ品質に集中できます。

本記事ではIVSのLow-Latency Streamingを中心に、チャンネルタイプの選定・Multitrack Videoによるコスト削減・エンコーダ設定の最適化について解説しました。特に重要なポイントは以下の3点です。

第一に、IVS Player SDKの使用は低遅延配信の絶対条件です。サードパーティHLSプレイヤーでは3〜5秒の低遅延は実現できません。第二に、STANDARDのMultitrack入力時はトランスコード→トランスマックス挙動に切り替わる点を理解したうえで設定します。第三に、チャンネルタイプとMultitrack Videoの選定・組み合わせによって、品質を維持しながら入力コストを大幅に最適化できます。

本番運用に向けたセットアップチェックリスト

IVSを本番環境に導入する際は、以下の項目を確認します。

• チャンネルタイプを配信要件に合わせて選定している (STANDARD/ADVANCED_HD/ADVANCED_SD/BASIC)
• IVS Player SDKを組み込んでいる (サードパーティHLSプレイヤー不使用)
• エンコーダのキーフレーム間隔を2秒、レート制御をCBRに設定している
• ストリームキーをSecrets ManagerまたはParameter Storeで管理している
• RTMPS (ポート443) を取り込みプロトコルとして使用している
• 録画が必要な配信ではAuto-Recordを有効化している
• 大規模イベントでは事前にサービスクォータを確認・引き上げ申請している
• CloudWatchアラームでストリームイベントを監視している

Amazon IVSが提供するビジネス価値

Amazon IVSは単なる「低遅延ライブ配信API」ではなく、視聴者とのエンゲージメントを深めるプラットフォーム基盤です。IVS Chat・タイムドメタデータ・Real-Time Streamingを組み合わせることで、視聴者参加型のインタラクティブ体験が実現します。

ライブコマースでは配信者と視聴者のリアルタイムコミュニケーションが購買転換率を高めます。ウェビナーでは双方向質疑応答が視聴者の満足度を向上させます。eスポーツ中継では低遅延配信と観客との同期体験が視聴者を引き付けます。これらのユースケースすべてにおいて、IVSは自前インフラ構築コストの数分の1で同等以上の配信品質を提供します。

ライブコマース・ウェビナー・ゲーム配信など、視聴者とのリアルタイムなエンゲージメントが競争優位を生む現代において、IVSは低コスト・高信頼な配信基盤として有力な選択肢です。本シリーズ続編ではReal-Time Streaming・録画・監視・コスト最適化の実践設計を解説します。

IVS導入でよくある初期のつまずきを防ぐ3ステップ

IVSを初めて本番導入するチームがつまずきやすいポイントは、概念誤解・設定ミス・クォータ問題の3つです。これらを事前に整理することで、スムーズな本番移行が実現します。

まず概念誤解として、「Real-Time Streaming = Low-Latency Streamingの上位互換」という誤解が最も多いです。それぞれが別の用途のために設計されたサービスであり、一方向配信にはLow-Latency、双方向参加型にはReal-Timeを選択します。次に設定ミスとして、OBSのキーフレーム・CBR設定とIVS Playerの実装を見落とすケースが多いです。これらは遅延品質に直結するため、開発環境で必ず動作確認します。最後にクォータ問題として、大規模イベントでは本番2週間前にはクォータ引き上げ申請を完了させます。

コスト感覚のキャリブレーション

IVSのコストは入力 (取り込み時間) と出力 (視聴時間) の2軸で発生します。視聴者数が少ない小規模配信では入力コストが支配的になります。視聴者数が多いリッチな配信では出力コスト (帯域) が支配的になります。Multitrack Videoは入力コストを削減する機能であり、出力コストには影響しません。コスト最適化の方向性を「入力削減か出力削減か」で整理し、適切な施策を選ぶことが重要です。

STANDARDからBASICへの変更は入力コストを大幅に下げる一方でアダプティブビットレートが失われます。視聴者ネットワーク環境が均質な社内配信ではトレードオフが許容できますが、一般向け大規模配信では慎重な判断が必要です。コスト削減と配信品質のバランスをCloudWatchの視聴品質データで判断する運用習慣が、長期的なIVS活用の鍵となります。

IVSと周辺サービスの組み合わせで広がる活用シナリオ

IVSは単体でも強力ですが、AWS周辺サービスと組み合わせることでさらに多彩なシナリオが実現します。

MediaConvertとの連携では、IVSで録画した映像をMediaConvertでVOD用にトランスコードし、CloudFrontで配信するVODパイプラインが構築できます。配信直後のアーカイブ公開まで完全自動化が可能です。

Amazon Rekognitionとの連携では、IVSのサムネイルAPIと組み合わせた映像コンテンツモデレーションが実現します。EventBridgeでストリームイベントを受け取り、Lambda経由でRekognitionの不適切コンテンツ検出を定期実行するパターンが代表的です。

Amazon Cognitoとの連携では、IVSの再生URLに対してCognito認証を組み合わせることで有料視聴・会員限定配信が実現します。CloudFront Signed URLとCognitoトークンを組み合わせたコンテンツ保護が標準的なパターンです。

IVSはこれらのAWSサービスとのネイティブな統合ポイントが多く、サービス間のデータ連携をAWSのイベント駆動アーキテクチャ (EventBridge/Lambda/S3) でつなぐことで、スケーラブルなライブ配信プラットフォームを構築できます。本シリーズでは続編ごとに各統合パターンを実践設計レベルで解説します。

メディア系マネージドサービス比較と選定指針

AWSのメディア関連サービスは複数あり、ユースケースによって選定が異なります。以下の視点で整理することで、IVSが最適か他サービスを検討すべきかを判断できます。

IVSはライブ配信の「素早く・シンプルに・マネージドで」という要求を満たす選択肢です。放送グレードの高可用性や複雑なトランスコードパイプラインが必要な場合はMediaLive/MediaConvertが適します。ユースケースの要件を「遅延」「双方向性」「スケール」「運用複雑度」の4軸で整理することで、最適なサービス選定ができます。

IVSとMediaLiveを比較した場合、IVSはAPI操作だけで取り込みエンドポイントが即座に準備される手軽さが強みです。MediaLiveは高い可用性と冗長系構成が必要な放送グレード配信に向いています。スタートアップや中小企業での新規ライブ配信基盤立ち上げはIVSを選び、成長に合わせて必要な周辺サービスを追加していくアプローチが運用負荷を最小化します。

IVS・IVS Chat・Real-Time Streamingのすべてがパブリックプレビューを経て一般提供済みです。本番環境での採用実績も増えており、サービスの成熟度と安定性は十分です。新しいライブ配信基盤を構築する際のファーストチョイスとして、IVSの評価から始めることをお勧めします。

8-4. 関連記事

AWS GameTech・メディアサービス基盤Vol1 — AppStream/MediaConvert/MediaLive/GameLift

AWS EUC本番運用Vol1 — WorkSpaces/AppStream 2.0でDaaS基盤を構築する

AWS CDN/CloudFront本番運用Vol1 — Lambda@Edge・Route 53で構築するエッジ配信基盤

AWSアプリ統合本番運用Vol1 — SQS/SNS/EventBridge/API Gateway/AppSyncの設計パターン

Amazon Cognito認証・アイデンティティ本番運用Vol1 — ユーザープール設計から本番運用まで