Kinesis Video Streams 本番運用 — 映像取り込み・WebRTC・Rekognition連携

1. この記事について — Vol1/Vol2の”外側”、デバイスからクラウドへの映像取り込み

1-1. Vol1/Vol2からの接続と棲み分け — 「配信」に対する「取り込み」

Vol1では動画・ゲーム配信の”前段”(AppStream 2.0/MediaConvert/MediaLive/GameLift)を、Vol2では”後段”のパッケージング・マネタイズ(MediaPackage v2/MediaTailor)を扱いました。いずれも軸足は クラウドから視聴者へ映像を届ける「配信(egress)」 にあります。

本Vol3が担当するのは、その手前——デバイス/カメラからクラウドへ映像を取り込む「取り込み(ingest)」 側です。監視カメラ・IoTデバイス・スマートホーム機器・車載カメラなどが生成する映像を、Kinesis Video Streams(以下KVS)で安全に取り込み・保存し、ML分析や双方向コミュニケーションへつなげる本番運用を深掘りします。

Vol1はKVSを「遅延よりシンプルさ優先の選択肢」「IoTデバイス連携先」として名前だけ前方参照しており、専用の解説は”Vol2以降でカバー予定”として予告にとどめていました。本Vol3はその予告を回収し、KVSを主役として扱います。

「取り込み(ingest)」という言葉から、Amazon IVS(視聴者向けライブ配信)やKinesis Data Streams/Firehose(データレコードのストリーム)と同じサービス群だと誤解されることがあります。しかし本Vol3で扱うKVSは、デバイスからクラウドへの映像取り込みとWebRTC双方向を担う別サービス・別レイヤであり、IVSの「一対多配信」やKDS/KDFの「イベントデータストリーム」とは目的もAPIも異なります(両者との詳細な比較は次章2-1で扱います)。Vol1/Vol2既読の方は、視聴者側の「配信」に対する入口側の「取り込み」という位置づけを押さえておくと、本Vol3全体の理解がスムーズです。

本Vol3が扱う「取り込み」を具体的にイメージできるよう、代表的なユースケースを4つ挙げます。

1. 監視カメラ映像の常時取り込みと保持 — 店舗・工場・公共施設に設置した固定カメラ群からProducer SDK/GStreamerで継続的に取り込み、Fragment単位で指定期間保持し、インシデント発生時に該当区間のみをGetMediaで取り出す運用です。
2. 車載カメラのイベントドリブン取り込み — 通常走行時は低頻度サンプリングにとどめ、急ブレーキや衝突検知などのトリガー発生時のみ高頻度取り込みに切り替え、事故検証用の映像をクラウド側に確保する設計です。
3. スマートホーム機器からのライブ視聴・双方向通話 — ドアベルカメラやベビーモニターなど、エンドユーザーがスマートフォンからリアルタイムに映像を確認し、WebRTC経由で音声双方向通話するケースです。
4. ライブイベント/ゲーム配信のソース映像取り込みとML前処理 — 会場カメラやゲームプレイ映像をKVSに取り込み、Rekognition Videoで顔・物体を検知した上で、Vol1のMediaLive/Vol2のMediaPackageへ続く配信パイプラインに引き渡す使い方です。

いずれのユースケースも、Vol1/Vol2が扱う「配信(視聴者へ映像を届ける)」とは主題が異なり、「取り込み(デバイス側からクラウドへ映像を集める)」という入口側の設計が中心になる点で共通しています。

1-2. 読者像 — メディア基盤担当とIoT/監視カメラ基盤担当

本記事は、大きく2つの読者層を想定しています。

1つ目は、Game/Media Vol1(MediaConvert/MediaLive/GameLift)・Vol2(MediaPackage v2/MediaTailor)を読み配信基盤の設計を理解した上で、「映像の入口」をどう設計すべきかを知りたいメディア配信担当の方です。ライブイベントやゲーム配信のソースとなる映像を、どのようにクラウドへ安全に取り込むかという観点でKVSを位置づけます。

2つ目は、監視カメラ・スマートホーム機器・車載カメラなどIoTデバイスの映像をクラウドに取り込み、Rekognition Videoなどで分析したいIoT/監視カメラ基盤担当の方です。配信シリーズとは独立して、KVS単体の取り込み・保存・ML連携ニーズで本記事に来られた場合もこちらに該当します。

いずれの読者も、AWSアカウントの基本操作・IAMの基礎・AWS CLIの利用経験は既読の前提とし、本記事では改めて解説しません。

1-3. なぜ今 Kinesis Video Streams か

Kinesis Video Streamsを今あらためて取り上げる理由は3つあります。

第一に、生成AIや機械学習を活用した映像分析ニーズの高まりです。Rekognition VideoのStream Processorは、KVSに取り込んだ映像をリアルタイムで顔検知・物体検知し、結果をKinesis Data Streams経由で下流のLambdaや分析パイプラインへ連携できます(詳細は§6)。「取り込むだけ」ではなく「取り込んだ映像を価値化する」用途が急速に広がっています。

第二に、WebRTC双方向配信の機能拡充です。2026年にはvideo-only modeの対応リージョンが順次拡大し(2026年4月にeu-west-1でGA)、AWS GovCloud(US)リージョンでのWebRTCサポートも同年4月に追加されるなど、低遅延双方向配信をより幅広い環境で利用できるようになっています(§5で詳述)。

第三に、Game/Mediaシリーズとしての一気通貫の完成です。Vol1(エンコード)・Vol2(パッケージング・広告)が担う「配信」に対し、本Vol3で「取り込み」を扱うことで、映像がデバイスからクラウドへ入り、視聴者へ届くまでの全体像がシリーズとして完結します。

Game/Media Vol1 — AppStream 2.0 × MediaConvert × MediaLive × GameLift
Game/Media Vol2 — MediaPackage v2 × MediaTailor(パッケージング・SSAI広告挿入)

2. Kinesis Video Streams とは — 2つのAPIファミリーと全体像

2-1. 他の映像・ストリームサービスとの違い(別レイヤの明示)

KVSは名称に「Kinesis」を含みますが、Kinesis Data Streams(KDS)/Data Firehose(KDF)などのデータストリーム系とは別サービス・別用途 です。KDS/KDFがレコード(JSON/バイナリのイベントデータ)を扱うのに対し、KVSは時系列の映像・音声・センサーメディアのFragment を扱います。

また、Amazon IVS(Interactive Video Service)が視聴者向けのライブ配信(one-to-many broadcast) を担うのに対し、KVSはデバイスからの取り込み(ingest)と双方向(WebRTC) を担います。同じ「映像」でも入口/出口とトポロジが異なります。

上表を踏まえると、KVSを選ぶべき判断軸は次の3点に整理できます。第一に、扱うデータが時系列の映像・音声・センサーメディアであり、JSON/バイナリのイベントレコードではない場合はKVSが適合します。第二に、視聴者への一斉配信ではなく、デバイス側からクラウドへの取り込みや、当事者間の双方向コミュニケーション(ビデオ通話・遠隔監視)が主目的の場合はKVSを選びます。第三に、取り込んだ映像をRekognition VideoなどのMLサービスや独自の分析パイプラインへ連携したい場合、KVSはFragment単位でのアクセスとGetMedia系APIを提供するため親和性が高くなります。逆に、視聴者数千〜数万人規模へのライブ配信が主目的であればIVSやMediaLive/CloudFront側(Vol1/Vol2)を検討すべきです。

この3つの判断軸は抽象的なままでは実務で使いにくいため、以下では実際によく遭遇する5つの具体的なシナリオに当てはめて、KVSを選ぶべきか・選ぶべきでないかを整理します。

シナリオ1(常時監視・遠隔確認): 監視カメラの映像を、遠隔地のオペレーターがリアルタイムで確認しながら必要に応じて音声で呼びかけたい場合です。

このシナリオでは、映像そのものをやり取りする双方向コミュニケーションが主目的であり、視聴者への一斉配信ではないため、KVSのWebRTC(§5)が適合します。IVSは一対多配信を前提とするため、オペレーター1人がカメラ映像を確認するような一対一・一対少数の用途にはオーバースペックです。

シナリオ2(大規模ライブ配信): eスポーツ大会の実況やライブイベントを、数千〜数万人の視聴者に届けたい場合です。

このシナリオは、デバイスからの取り込みではなく視聴者への一斉配信が主目的であるため、KVSではなくIVSやMediaLive/CloudFront(Vol1/Vol2)を選ぶべきです。KVSのWebRTCは一対少数(Viewer上限10)を前提としたシグナリングモデルであり、大規模な視聴者数をさばく設計にはなっていません。

シナリオ3(事後調査・証跡確認): 監視カメラでモーション検知が発生した際、その前後数十秒だけを後から切り出して確認したい場合です。

このシナリオでは、映像をFragment単位で保存し、必要な区間だけをピンポイントで取得できることが求められるため、KVSの取り込み保存系(Producer SDK/GStreamer→Fragment保存→GetMediaForFragmentList、§3/§4)が適合します。IVSは配信特化でありアーカイブからの区間切り出しに向いた設計ではなく、KDS/KDFはそもそも映像Fragmentを扱えません。

シナリオ4(遠隔作業支援): フィールドエンジニアが装着したカメラの映像を見ながら、遠隔地の熟練者が音声で作業指示を出したい場合です。

このシナリオも、当事者間の低遅延双方向コミュニケーションが主目的であるため、KVSのWebRTCが適合します。シナリオ1との違いは、Viewer側(遠隔の熟練者)からもMaster側(現場のカメラ)へ音声を送り返す双方向性が前提になる点で、いずれもIVSの一方向配信モデルでは実現できません。

シナリオ5(スマートホームの見守り): ペットや高齢者の見守りカメラで、リアルタイムには映像を見ないものの、1日の終わりに異常があった時間帯だけをハイライトとしてまとめて確認したい場合です。

このシナリオでは、Rekognition VideoまたはRekognition Image APIによる動き・異常検知(§6)と組み合わせ、検知された時間帯周辺のFragmentだけをGetMediaForFragmentListで抽出するのが基本構成になります。リアルタイムの人手確認は不要なため、WebRTCのSignaling Channelは不要です。シナリオ3(事後調査)と近い取り込み保存系中心の構成です。ただし、切り出しのトリガーは、モーション検知(即時)ではなくRekognition Videoの分析結果(非同期)である点が異なります。

5つのシナリオを俯瞰すると、KVSの適合可否は「映像を発信するのがデバイス単体か、視聴者向けの一斉配信か」「その場で消費するだけか、後から遡って確認する必要があるか」という2つの軸で判断できることがわかります。取り込み・保存・双方向のいずれかが主目的であればKVS、視聴者への一斉配信が主目的であればIVSやMediaLive/CloudFront、というのが本Vol3全体を通じた基本方針です。

以下は、5つのシナリオと推奨されるサービス・機能の対応関係を一覧にしたものです。

なお、この判断フローは択一を強制するものではありません。§2-3で扱うとおり、1台のデバイスが複数のシナリオにまたがる要件(たとえば常時記録とリアルタイム確認の両方)を持つ場合は、取り込み保存系とWebRTC系を併用する構成も可能です。

2-2. 主要コンポーネント

KVSを構成する主要コンポーネントは次のとおりです。取り込み保存系(Stream/Fragment/Producer SDK/GStreamerプラグイン)とWebRTC系(Signaling Channel/STUN・TURN)の2グループに分かれる点を意識すると、後続の§3〜§5の内容と対応づけやすくなります。

• Kinesis video stream(Stream): 取り込んだメディアを保持し、リアルタイム/バッチ双方での消費を可能にするリソース。通常は1ストリームに対して1つのProducerが対応します。
• データフロー上は取り込み保存系の全経路が経由する起点であり、Producer側のPutMediaと消費側のGetMedia/HLS・DASHが、このStreamを介して疎結合になります。Stream自体はWebRTCのSignaling Channelとは独立したリソースです。
• Fragment: ストリーム内の自己完結した時系列メディアの単位。GetMedia/GetMediaForFragmentListなど消費系APIは、このFragment単位でデータを取得します。
• 保持期間(§4-1)やクリップ切り出し(GetMediaForFragmentList、§4-3)は、いずれもFragment単位でポリシーが適用されるため、Fragment境界(キーフレーム間隔)の設計が下流で扱える粒度をそのまま決定します。
• Producer SDK(Producerクライアント/Producerライブラリ): デバイス側でストリームへの接続・送信を担うSDK群。JavaとAndroidにはKinesisVideoClientクラスによるProducerクライアントが提供され、より低レベルな実装が必要な場合はAndroid/C/C++/Java向けのProducerライブラリを直接利用できます。
• アプリケーション側でフレーム送出のタイミング・バッファリング・エラーハンドリングを細かく制御したいカスタムアプリケーションや組み込み機器向けの実装で選ばれます。
• GStreamerプラグイン(kvssink): GStreamerパイプラインのsink要素としてKVSへの送信をラップするプラグインで、C++ Producer SDKに同梱されています。
• 既存のGStreamerパイプラインの終端に追加するだけで送出が完結するため、カメラベンダーのSDKやRTSPソースをすでにGStreamerで扱っている取り込み経路との親和性が高くなります(§3-1)。
• Signaling Channel: WebRTCのピア接続確立に必要なSDP/ICE候補などのシグナリングメッセージを仲介するリソース。1つのMasterと1つ以上のViewerが同一チャネルを介して接続します。
• 取り込み保存系のStreamとは独立したリソースであり、Stream本体を経由せずMasterとViewerが直接SDP/ICEを交換するため、取り込み保存系のバッファリングを挟まず低遅延性を優先した設計になっています。
• STUN/TURN: STUNはNAT/ファイアウォール越しに自身のパブリックIPアドレス/ポートを検出するために使用され、直接経路が確立できない場合はTURNがメディアをリレーします。TURNサーバー情報はGetIceServerConfig APIで取得します。
• P2P確立の可否はネットワーク環境(NAT種別)に依存するため、本番運用ではTURNへのフォールバック発生率を監視対象に含める必要があります(§5/§7で詳述)。

このように、Stream/Fragmentが「後から見る・分析する」ための取り込み保存系の基盤であるのに対し、Signaling Channel/STUN・TURNは「今この瞬間」の双方向通信を成立させるための基盤であり、両者は内部的に独立したコンポーネント群として設計されています。この独立性が、次節で述べる2つのAPIファミリーの使い分けの土台になります。

以下は、6つの主要コンポーネントがどちらのAPIファミリーに属し、本記事のどの章で詳しく扱うかを一覧にしたものです。

この独立性は、片方の構成要素に問題が起きてももう片方には影響しないという運用上のメリットにもつながります。たとえばSignaling Channelを誤って削除・再作成しても、Stream側に保存済みのFragmentや保持期間の設定には一切影響しません。逆に、Streamの保持期間設定を変更しても、進行中のWebRTCセッションのSDP/ICEネゴシエーションには影響を与えません。

もう一点、設計時に押さえておきたい数値制約として、Signaling Channelの同時接続数は1つのMasterに対し最大10 Viewerというソフトリミットがあり、これを超える一対多の双方向コミュニケーションが必要な場合はWebRTCではなく本記事の対象外であるIVSなどの検討が必要です。取り込み保存系・WebRTC系いずれについても、ストリーム数やスループットの上限はAWS公式のService Quotasページで最新値を確認することを推奨します。

2-3. 2つのAPIファミリーの使い分け — 取り込み保存系とWebRTC系の全体像

前節までで見たとおり、KVSは「取り込み保存系(Producer/GetMedia)」と「WebRTC系(Signaling)」という、内部的に独立した2つのAPIファミリーで構成されています。実際の設計では、この2つを同一ストリームに対して併用するケースと、用途に応じて一方だけを使うケースの両方が現れます。

同一ストリームで両方を使うケース: 代表例は、監視カメラの映像を、平常時はKVSのStreamに継続的に取り込んで保存しつつ(§3/§4)、異常検知時や必要なタイミングだけオペレーターがWebRTCで同じカメラ映像をリアルタイムに確認する、という併用構成です。この場合、カメラ側のアプリケーションは同一の映像ソースを、取り込み保存用のProducer SDK/kvssink経由でStreamへ、リアルタイム確認用のWebRTC Master経由でSignaling Channelへ、それぞれ独立した経路で送出する実装になります。Stream側の保存はRekognition Videoなどによる事後分析(§6)にも使えるため、「常時記録+ML分析」と「必要時のリアルタイム確認」を1台のカメラで両立できる点が併用構成のメリットです。

用途によって片方のみ使うケース: 証跡としての長期保存やRekognition Videoによる分析だけが目的で、人がリアルタイムに映像を見る必要がない監視カメラ用途では、WebRTCのSignaling Channelを用意せず、Producer SDK/kvssink→Stream保存の経路だけで構成が完結します。逆に、録画・保存の要件がなく、遠隔地の担当者同士がその場限りのビデオ通話・作業支援(シナリオ4)だけを目的とする用途であれば、Streamへの継続的な取り込みは不要で、Signaling Channelを介したWebRTC接続だけで要件を満たせます。

両者のどちらを採用するか、あるいは併用するかを判断する軸は、「その映像を後から見る・分析する必要があるか(Yesなら取り込み保存系が必要)」と「今この瞬間、人が双方向でやり取りする必要があるか(YesならWebRTCが必要)」の組み合わせです。この2軸がともにYesであれば併用構成、片方だけがYesであれば該当するAPIファミリーのみを採用する、という判断フローになります。

なぜKVSはこの2つのAPIファミリーを1つに統合せず、あえて別リソース(Stream/Signaling Channel)として分離しているのでしょうか。理由は、両者に求められる特性がほぼ正反対だからです。取り込み保存系は、Fragment単位でのバッファリングと永続化、後からの再取得を前提とした「蓄積型」の設計であるのに対し、WebRTC系はバッファをできる限り排除し、SDP/ICE交換からP2P確立までを数百ミリ秒〜数秒で完了させる「即時型」の設計です。1つのリソースにこの相反する特性を持たせようとすると、蓄積型の要件はWebRTCの低遅延性を損ない、即時型の要件は取り込み保存系の耐久性・再取得性を損なうというトレードオフが生じます。

別リソースとして分離しておくことで、取り込み保存系のFragment設計(§3-3)や保持期間設計(§4-1)を変更しても、WebRTC側の低遅延特性には影響しません。逆にWebRTC側でSignaling Channelの構成を変更しても、取り込み保存系の耐久性やアーカイブ性には影響しません。この設計上の疎結合が、§2-2の「同一デバイスから両方のAPIファミリーを独立して呼び出せる」という併用のしやすさにもつながっています。

実務でよく挙がる疑問をQ&A形式で補足します。

Q. 1台のカメラから、Producer SDK(取り込み保存系)とWebRTC(Signaling Channel)を同時に使うことはできますか。

A. できます。両者は別リソース・別APIであるため、カメラ側のアプリケーションが両方のクライアントを実装すれば、同一の映像ソースを取り込み保存用とリアルタイム確認用の2経路へ並行して送出できます(§2-3の併用構成)。

Q. WebRTCで配信した映像を、後からKVSのStreamに保存されたものとして再生できますか。

A. できません。WebRTCのSignaling Channel経由のセッションはStreamへ保存されないため、後から見返す必要がある場合は、Producer SDK/kvssink経由でStreamへの取り込みを別途行う必要があります(前段落の併用構成が前提になります)。

Q. 取り込み保存系だけを使っている場合、WebRTC用のIAM権限は必要ですか。

A. 不要です。Signaling Channelを一切作成・利用しない構成であれば、WebRTC関連のAPI(ConnectAsMaster/ConnectAsViewer/GetIceServerConfigなど)へのIAM権限は付与する必要がなく、§7-1で述べる最小権限設計上もこれらのアクションは対象外にできます。

2-4. この記事のゴール状態

本記事を読み終える頃には、読者は次の4つの設計判断ができる状態を目指します。第一に、Producer SDKとGStreamer(kvssink)のどちらでデバイスからの映像取り込みを実装すべきかを選べる状態。第二に、Fragmentと保持期間(retention)をどう設計し、HLS/DASHやGetMedia系APIでどう再生・取得すべきかを判断できる状態。第三に、双方向のビデオ通話や遠隔監視にはWebRTC(Signaling Channel/STUN・TURN)をどう組み合わせるべきかを設計できる状態。第四に、取り込んだ映像をRekognition Videoによるストリーミング分析へどう連携し、下流の分析基盤へ橋渡しすべきかを構想できる状態です。

3. 映像取り込み — Producer SDK / GStreamer / エッジデバイス連携

3-1. 取り込み方式 — Producer SDK と GStreamer(kvssink)の使い分け

KVSへ映像を送り込む経路は大きく2つに分かれます。1つは自前アプリケーションに組み込むProducer SDK(C++/Javaを提供)で、フレーム単位で細かく制御したいカスタムアプリケーションや組み込み機器に向いています。もう1つはGStreamerプラグイン(kvssink)で、既存のGStreamerパイプラインの終端にkvssinkエレメントを追加するだけでKVSへの送出が完結するため、カメラベンダーのSDKやRTSPソースをすでにGStreamerで扱っている環境では導入コストが小さく済みます。AWS公式のKinesis Video Streams Producer SDK(C++)ドキュメントでも、GStreamerを使わない直接統合が必要な場合を除きkvssinkの利用が推奨されています。

以下はUSBカメラ(V4L2)の映像をH.264エンコードしてKVSへ送出する典型的なGStreamerパイプラインの例です(kvssinkはamazon-kinesis-video-streams-producer-sdk-cpp 3.x系に同梱のプラグインを想定)。

gst-launch-1.0 -v v4l2src device=/dev/video0 ! videoconvert \
  ! x264enc bframes=0 key-int-max=45 tune=zerolatency bitrate=512 \
  ! h264parse ! kvssink stream-name="camera-01-stream" \
 storage-size=128 aws-region="ap-northeast-1"

key-int-maxでキーフレーム間隔を制御している点がポイントです。後述のとおりKVSのFragmentはキーフレームから始まる必要があるため、キーフレーム間隔がFragment長を左右します。

3-2. 認証設計 — IAMロール・一時クレデンシャルとカメラの長期運用

Producer SDK/kvssinkのいずれも、内部的にはPutMedia(後継のストリーミングAPIを含む)を呼び出すためにAWS認証情報を必要とします。開発・検証環境ではIAMユーザーのアクセスキーを直接渡すことも可能ですが、本番運用ではSTSによる一時クレデンシャル、あるいはEC2/ECS上で動作させる場合はIAMロールのインスタンスプロファイルを利用し、長期的な静的キーを持たせない設計が基本方針になります。

現場に設置されたカメラのように長期間クレデンシャルをローテーションし続けたいデバイスに対しては、AWS IoT CoreのX.509証明書とIoTクレデンシャルプロバイダーを組み合わせ、証明書ベースで一時的なAWS認証情報を都度取得させる構成がAWS公式ドキュメントで案内されています。IAMポリシーはストリーム単位(kinesisvideo:StreamARN)でPutMedia/GetDataEndpointなどのアクションを絞り込み、最小権限を徹底することが重要です。

3-3. フレーム/Fragmentの単位とPutMediaの挙動

KVSにおけるデータの最小の管理単位はFragmentです。Fragmentは1つ以上のフレームの集まりで構成され、必ずキーフレーム(IDRフレーム)から開始するという制約があります。Producer SDK/kvssinkはこの制約を踏まえてバッファリングを行い、内部的にMKV(Matroska)形式のチャンクとしてPutMediaエンドポイントへストリーミング送信します。

Fragmentの長さ(キーフレーム間隔)は、後述するFragment単位での取得(GetMediaForFragmentList)や保持期間の粒度に直結するため、エンコーダ側のGOP設定と合わせて事前に設計しておく必要があります。GOPを短くするとランダムアクセス性(任意の時点から再生を開始しやすい)が向上する一方、キーフレーム比率が上がり同一ビットレートでの画質・帯域効率はやや低下します。

3-4. エッジ連携 — AWS IoT Greengrass上のKVS Edge Agent

回線が不安定な現場や、常時クラウドへ映像を送り続けるとコストが嵩む監視カメラ用途では、クラウドへ直接Producer SDKで送出する構成に加えて、AWS IoT Greengrass上で動作するKinesis Video Streams Edge Agentという選択肢があります。Edge Agentはローカルストレージへ映像を保持しつつ、設定したスケジュールや条件に応じてクラウド側のKVSストリームへアップロード(store-and-forward)する構成を取れます。ネットワーク断時でもエッジ側にバッファが残るため、復旧後にアップロードを再開できる点が、常時ライブ送出前提のProducer SDK直結構成との大きな違いです。エッジ運用時のコスト・監視設計は§7で扱います。

4. 保存・再生 — Fragment/保持期間・HLS/DASH/GetMedia・タイムシフト

4-1. Fragmentと保持期間(Data Retention)の設計

ストリーム作成時(または後から)に設定するデータ保持期間(Data Retention Period)は、KVSに取り込んだFragmentをどれだけの時間クラウド側に保持するかを決めるパラメータです。保持期間を0(未設定)にすると、Fragmentは短時間のバッファを経て消費されるのみで永続保存されず、リアルタイム消費専用のパイプラインになります。一方、時間〜日単位で保持期間を設定すると、後述のHLS/DASH再生やタイムシフト、GetMediaForFragmentListによる過去データの取り出しが可能になります。

保持期間はストリーム単位で設定するため、「直近数時間だけ確認できればよい監視カメラ映像」と「証跡として長期保存したい映像」を同じ設計方針で扱うと無駄なストレージコストが発生します。用途ごとにストリームを分ける、あるいは長期保存が必要な範囲だけ別途Amazon S3へエクスポートする設計が現実的です。

4-2. HLS/DASHストリーミング再生 — 再生URLの発行

保存されたFragmentをブラウザやモバイルアプリで再生する場合、GetHLSStreamingSessionURL(HLS)またはGetDASHStreamingSessionURL(DASH)を呼び出して一時的な再生セッションURLを発行します。発行されたURLをそのまま<video>タグやHLS/DASH対応プレーヤーに渡すだけで、KVS側がFragmentをHLSの.m3u8/DASHの.mpdセグメントへ変換して配信します。

再生モードには、現在取り込み中の映像を追いかけるLIVE、保持期間内の任意区間を指定して再生するON_DEMAND、ライブに近い遅延で少し過去から再生を開始し追いつくLIVE_REPLAYがあり、用途(リアルタイム監視かタイムシフト視聴か)に応じて選択します。

4-3. GetMedia/GetMediaForFragmentListによる個別取得

プレーヤーでの再生ではなく、映像データそのものを自前のパイプラインで処理したい場合(例: 独自のトランスコード、長期アーカイブへのエクスポート、後述のRekognition Video以外のML処理)には、GetMediaとGetMediaForFragmentListを使います。GetMediaはストリームの任意時点からのFragmentを順次ストリーミング取得するAPIで、GetMediaForFragmentListはListFragmentsで取得したFragment番号を指定し、特定区間のFragmentだけをピンポイントで取得するAPIです。イベント検知(モーション検知など)をトリガーに該当時刻前後のFragmentだけを抽出するような、いわゆる「クリップ切り出し」用途では後者が適しています。

4-4. タイムシフト再生と保持期間がコストに与える影響

タイムシフト再生(ON_DEMAND/LIVE_REPLAY)やGetMediaForFragmentListによるクリップ切り出しは、いずれも保持期間内にFragmentがクラウド側に残っていることが前提です。つまり「どこまで遡って見られるようにするか」という要件がそのまま保持期間の長さを決め、保持期間の長さがそのままストレージコスト(保存GB時間あたりの課金)に直結します。取り込み側のビットレート設計(§3)と保持期間の掛け算がストレージコストの主要因になるため、本記事の本番運用コスト設計(§7)ではこの保持期間をコストの中心的な変数として扱います。

5. WebRTC — 低遅延双方向・Signaling/STUN/TURN・video-only mode(2026)

WebRTCが対応する用途は、ビデオ通話のような双方向コミュニケーションと、監視カメラ映像を管理者がリアルタイムで確認しながら音声で呼びかけるような双方向監視の2つに大別されます。§3/§4で解説した取り込み保存系(Producer SDK/GStreamer → PutMedia → Fragment保存)が「後から見る・分析する」ためのアーカイブ用途であるのに対し、WebRTCは「今この瞬間」を低遅延でやり取りする用途に特化しています。両者は同じKVSサービス内の別APIファミリーであり、取り込んだ映像をリアルタイムで人が確認したいか、後から蓄積・分析したいかで使い分けます。

WebRTCによるピアツーピア接続を仲介するのがSignaling Channelです。Signaling Channelはアプリケーション同士がSDP(Session Description Protocol)やICE候補といったシグナリングメッセージを交換し、接続の確立・制御・終了のためのリソースです。接続方式は「1対少数(one-to-few)」モデルを採っており、接続を開始する側がConnectAsMaster APIでMasterとなり、それに対して最大10台のアプリケーションがConnectAsViewer APIでViewerとして接続します。Viewer同士は互いを発見・通信できず、常にMasterを介した接続関係になります。

MasterとViewerがSDPを交換した後は、実際にメディアを流すための経路を確立する必要があります。ここで使われるのがSTUN(Session Traversal Utilities for NAT)とTURN(Traversal Using Relays around NAT)です。STUNは各アプリケーションがNAT配下でも自身のパブリックIP/ポートを把握するために使い、ICEの仕組みで得た候補同士の疎通確認を行います。疎通確認に成功したIP/ポートの組み合わせがあれば、その経路でP2P(ピアツーピア)の直接通信が確立します。一方、双方のネットワーク環境(Symmetric NATなど)によってP2P経路が確立できない場合は、TURNサーバーを経由したメディアリレーにフォールバックします。TURN経由は追加の課金対象であり(§7でコスト観点を扱います)、本番設計ではTURNへのフォールバック発生率をモニタリングし、想定外のコスト増加がないか確認することが重要です。

2026年にはWebRTCまわりの機能拡充が続いています。まずvideo-only modeは、音声を含まず映像のみをストリーミングするモードで、マイクを持たないカメラでの監視用途や、音声帯域を使わずに映像品質を優先したい用途に向いています。2026年3月時点でeu-west-1・AWS GovCloud(US)・中国(北京、Sinnet運用)リージョンを除く全リージョンでGA(一般提供)となり、2026年4月2日にeu-west-1(ダブリン)でもGAとなりました。日本のap-northeast-1(東京)リージョンはKinesis Video Streams WebRTC自体がすでに提供対象であり、video-only modeも利用可能です。あわせてWebRTCの提供リージョンそのものも拡大が続いているため、本番設計時には利用予定リージョンでの機能提供状況を都度、AWS公式のリージョン別対応表で確認することを推奨します。

6. ML連携 — Rekognition Video ストリーミング / 下流出力

「取り込んだ映像を、どう価値に変えるか」——本記事の核心はここにあります。KVSに取り込んだストリームは、Rekognition Videoと連携させることで顔検知・物体検知のMLパイプラインへ接続できます。ただし2026年に入り、この連携方式には重要な提供条件の変化がありましたので、まず正確な現状を押さえたうえで、設計上どう対応すべきかを解説します。

6-1. Rekognition Video Stream Processor — KVSとの連携アーキテクチャ

Rekognition VideoはKVSのストリームをそのまま入力として受け取り、映像を解析する仕組みを持っています。CreateStreamProcessor APIで作成するStream Processorには、大きく2種類があります。

• 顔検索(Face Search)ストリームプロセッサ: FaceSearchSettingsで、入力元のKVSストリームARN・出力先のKinesis Data StreamARN・照合に使うFace Collection IDを指定します。フレームごとの解析結果は、どのFragment/フレーム由来かという情報と、マッチした顔のバウンディングボックス・信頼度スコア・顔特徴点を含むJSONレコードとして、指定したKinesis Data Streamへ出力されます。
• ラベル検出(人物/パッケージ/ペット検知)ストリームプロセッサ: ConnectedHomeSettingsで検知したい対象種別を指定し、結果はKinesis Data Streamではなく Amazon SNS通知・Amazon S3保存という形で受け取ります。

StartStreamProcessorで解析を開始し、DescribeStreamProcessorで状態確認、DeleteStreamProcessorで削除するというライフサイクルはどちらの方式でも共通です。出力されたKinesis Data StreamをLambda等で消費し、下流の通知・ダッシュボード表示・監査ログ記録へつなげる設計が基本形になります。

6-2. 新規実装での推奨アーキテクチャ — フレームサンプリング + Rekognition Image API

Stream Processorが新規利用不可となった現在、新規設計で現実的なのは、KVSから映像フレームを定期的にサンプリング抽出し、フレーム単位でRekognition Image API(DetectLabels/DetectFaces/DetectModerationLabelsなど、ストリーミング専用ではない通常の画像解析API)を呼び出すアーキテクチャです。

具体的には、KVSのGetMedia/HLS出力からフレームを一定間隔(たとえば1〜5秒間隔)で抽出し、Lambda(またはコンテナ)からRekognition Image APIへ渡して解析、結果をAmazon SNSで通知し、画像はAmazon S3に保存、メタデータはAmazon DynamoDBに記録するという形で下流に連携する構成です。AWS公式ブログ「Create a Serverless Solution for Video Frame Analysis and Alerting」が、この種のフレームサンプリング+Rekognition Image API連携パターンの参考実装として公開されています。ストリーミングAPIのようなフレーム単位の連続解析ではなく、一定間隔のサンプリングになる点はトレードオフですが、監視カメラの異常検知やIoT映像の定期チェックといった用途では十分に実用的です。

6-3. 生成AI/SageMaker/Bedrock連携の拡張余地

顔検知・物体検知の結果を起点に、さらに一段踏み込んだ分析へ拡張する余地もあります。たとえば検知結果(検知対象・時刻・該当Fragment)をトリガーにAmazon Bedrockを呼び出し、検知シーンの状況説明文を生成して通知に添える、あるいは自社データで学習したAmazon SageMakerのカスタムモデル(業種特化の異常検知・欠陥検知等)を下流Lambdaから呼び出し、汎用的な顔・物体検知では拾えない業務固有の判定を追加する、といった設計です。

これらはAWSが提供するマネージドな自動連携機能ではなく、Lambda等の下流処理としてユーザー側で組み込む拡張パターンである点に注意してください。KVS→(Stream ProcessorまたはフレームサンプリングによるRekognition解析)→下流Lambda、という基本形の先に、用途に応じて生成AI・独自MLモデルを差し込める余地がある、という位置づけです。

7. 本番運用 — セキュリティ・監視・コスト・リージョン

7-1. IAM — ストリーム単位の最小権限設計(具体シナリオ)

KVSのIAM設計で押さえるべき原則は、「書き込み(取り込み)」と「読み取り(消費・解析)」の権限を役割ごとに分離し、対象ストリームのARNで絞り込むことです。ここでは、現場のカメラデバイス(Producer)と、解析用Lambda(Consumer)を分離する具体的なシナリオで考えます。

カメラデバイス用のIAMロールには、対象ストリームへのPutMediaと、送信先エンドポイントを取得するGetDataEndpointのみを、ストリーム単位のARN(arn:aws:kinesisvideo:ap-northeast-1:<account-id>:stream/camera-01-stream/<stream-id>)に限定して付与します。逆に解析用Lambdaには、GetMedia/GetDataEndpoint/DescribeStreamなど読み取り系のアクションのみを許可し、PutMediaは含めません。カメラ側の認証情報が万一漏えいしても解析基盤を読み取れない、解析側の認証情報が漏えいしても映像を偽装送信できない、という形で被害範囲を分離できます。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "ProducerPutMediaOnly",
"Effect": "Allow",
"Action": ["kinesisvideo:PutMedia", "kinesisvideo:GetDataEndpoint"],
"Resource": "arn:aws:kinesisvideo:ap-northeast-1:123456789012:stream/camera-01-stream/*"
 },
 {
"Sid": "ConsumerReadOnly",
"Effect": "Allow",
"Action": ["kinesisvideo:GetMedia", "kinesisvideo:GetDataEndpoint", "kinesisvideo:DescribeStream"],
"Resource": "arn:aws:kinesisvideo:ap-northeast-1:123456789012:stream/camera-01-stream/*"
 }
  ]
}

Rekognition Video Stream Processor(§6-1、既存アカウントで利用中の場合)を使う構成では、出力先のKinesis Data Stream側の権限も同様に分離が必要です。Rekognitionのサービスロールには当該Kinesis Data StreamへのPutRecord/PutRecordsのみを、下流LambdaにはGetRecords/GetShardIteratorなどの読み取り系のみを付与し、Lambda側に書き込み権限を持たせない設計とします。

7-2. 暗号化 — 保存時(KMS)と転送時

KVSはストリームのデータを常にサーバーサイド暗号化した状態で保存します。ストリーム作成時に暗号化キーを指定しなければAWS管理キー(aws/kinesisvideo)が自動的に使われ、これは追加料金なしで利用できます。より厳格な鍵管理・監査要件がある場合は、カスタマー管理のKMSキーをストリーム作成時(CreateStreamのKmsKeyIdパラメータ、またはコンソールのEncryptionタブ)に指定できます。暗号化・復号はKVSのストレージ層で透過的に行われるため、ProducerやConsumer側のアプリケーションコードに暗号処理を組み込む必要はありません。

転送時の保護については、Producer SDK/kvssinkからのPutMedia、Consumer側のGetMedia/HLS・DASH再生URL、いずれもHTTPS(TLS)での通信が前提です。エッジデバイスからのアップロードを含め、平文でのメディア転送経路が発生しない構成になっています。

7-3. CloudWatch監視 — 主要メトリクスとアラーム設計

KVSはAmazon CloudWatchに取り込み側・消費側それぞれのメトリクスを発行しており、これらを監視することでパイプラインの健全性を追跡できます。取り込み側では、PutMediaリクエスト数や受信バイト数に加えて、Fragment/フレームの受信完了数、接続確立時のエラー数、Fragmentの最初と最後のバイトを受信するまでの時間差といったメトリクスが提供されます。消費側では、GetMedia.SuccessやGetMediaForFragmentList.Successの成功率、GetMedia.ConnectionErrorsの発生数が主要な監視対象です。

実運用でのアラーム設計としては、GetMedia.ConnectionErrorsの増加をコンシューマ側の再接続頻発(消費が追いついていない兆候)の検知に、PutMediaの接続エラー増加をカメラ側のネットワーク不調やクレデンシャル失効の検知に、それぞれ紐づけるのが基本パターンです。CloudWatchのメトリクスはKVSのコンソールから「Video streams」タブのダッシュボード、またはストリーム詳細ページの「Monitoring」タブでも直接確認できます。

7-4. コスト設計 — 従量課金の4つの軸

KVSのコストは、大きく4つの軸で発生します。

• 取り込み: GBあたりの従量課金
• 保存: GB-月あたりの従量課金。保持期間の長さがそのまま保存量を左右し、§4-4で述べたとおりコストの主要因になります
• 消費: GetMediaによるGBあたりの取得課金。HLS消費はさらに別レートが設定されています
• WebRTC: アクティブなSignaling Channelの月額課金・シグナリングメッセージ100万件あたりの課金・TURN経由のリレー分あたりの課金

AWS公式の料金ページに掲載されている参考値(US Eastリージョン)では、取り込み・消費が概ねGBあたり数セント未満、TURNリレーが1,000分あたり0.12ドル程度という水準ですが、実際の料金はリージョンごとに異なるため、東京(ap-northeast-1)での本番試算時にはAWS Pricing CalculatorまたはKinesis Video Streamsの料金ページで最新の東京リージョン単価を確認してください。

保持期間とビットレートの掛け算が保存コストを決めるという§4-4の設計方針は本番運用フェーズでも変わらず重要で、「本当にその保持期間が必要か」を用途(リアルタイム監視のみか、証跡としての長期保存が必要か)に照らして定期的に見直すことがコスト最適化の第一歩になります。またWebRTCについては、STUN越しの直接P2P確立に失敗しTURNへフォールバックする比率が高いネットワーク環境では、想定よりTURN課金がかさむため、§5で触れたフォールバック発生率のモニタリングとあわせてコストを追跡することを推奨します。

7-5. リージョン — 東京(ap-northeast-1)の提供状況

Kinesis Video Streams本体、およびWebRTC機能はいずれも東京(ap-northeast-1)リージョンで一般提供(GA)されています。ただしWebRTCの対応リージョンはKVS本体の対応リージョンと完全には一致せず(AWS GovCloud(US)や中国リージョンの一部など、WebRTCのみ非対応のリージョンが存在します)、また§5-3で触れたvideo-only modeのようにWebRTC内の個別機能ごとにリージョン展開のタイミングがずれることもあります。本番設計・新リージョンへの展開時には、都度AWS公式のリージョン別対応表で機能単位の提供状況を確認する運用を徹底してください。

7-6. エッジ運用

§3-4で紹介したAWS IoT Greengrass上のKinesis Video Streams Edge Agentを使う構成では、運用面での考慮点がクラウド直結構成とは異なります。ローカルストレージの容量設計(store-and-forwardでバッファできる期間)、ネットワーク復旧後のアップロード再開時に帯域を圧迫しないためのアップロードスケジュール調整、エッジ側デバイスの証明書ローテーション(§3-2のIoT Core X.509証明書)状況の監視などが運用項目に加わります。エッジ運用ではクラウド側のCloudWatchメトリクスだけでは状態が見えないため、Greengrass側のログ・デバイスシャドウなど、エッジ固有の監視経路もあわせて設計しておく必要があります。

8. まとめ — 取り込みから配信までの一気通貫と、シリーズの結線

本記事では、Kinesis Video Streamsを軸に、Producer SDK/GStreamerによる映像取り込み、Fragment/保持期間に基づく保存・再生(HLS/DASH/GetMedia)、Signaling Channel経由のWebRTC低遅延双方向、Rekognition Videoとの連携によるML分析までを一貫して解説しました。

Vol1(AppStream 2.0/MediaConvert/MediaLive/GameLift)が配信の前段(エンコード)を、Vol2(MediaPackage v2/MediaTailor)が配信の後段(パッケージング・マネタイズ)を担うのに対し、本Vol3はその手前——デバイスからクラウドへ映像を取り込む「入口」を担います。3つのVolを通して、映像がカメラ・エッジデバイスから取り込まれ、加工・パッケージングされ、視聴者へ届くまでの一気通貫がGame/Mediaシリーズとして完結しました。

Kinesis Video Streamsは、IVSのような視聴者向け配信サービスでも、Kinesis Data Streams/Firehoseのようなデータレコードのストリームサービスでもなく、デバイスからの映像取り込み・保存・双方向・ML連携を担う専用サービスです。この位置づけを踏まえたうえで、自身のユースケースにKVSが適合するかどうかを判断していただければ幸いです。

Game/Media Vol1 を読む
Game/Media Vol2 を読む