クラウド録画PoCで「映った」だけを完了にしない ― 要求を検証証拠へ分解する

Posted at 2026-08-20

最初の映像が出ると、PoCが終わったように見える

2021年、Raspberry PiとUSBカメラを使い、Amazon Kinesis Video Streams（KVS）へ映像を送るハンズオンを試しました。その後、ローカルネットワーク内でしか映像を提供しない既存IPカメラ製品を、エッジGWを介してKVSへ接続するPoCを構築しました。

クラウド対応機能を持たない製品の映像がKVS側で見えた。PoCとしては、ここが大きな成功でした。それでも大変でしたし、ここまでで確認できたのは「クラウドへ映像を通せる」という経路です。実運用では、回線断からの復旧、認証情報の配布と更新、映像停止の検知、複数台の管理が必要になります。最終的に利用者へ提供するなら、KVSコンソールではなく独自ビュワーも必要です。

要求仕様を眺めると機能は増えていきますが、その一覧をそのままPoCへ持ち込むと、何をもって成功とするのかが曖昧になります。

この記事では、当時のクラウド録画検討資料から固有情報を取り除き、「要求を観測可能な検証証拠へ変換する」というPoCの組み立て方を整理します。

実務資料の社名、製品名、カメラ型番、台数、料金条件、ネットワーク構成は使用していません。図と条件は公開用に一般化しています。

読者と前提

対象読者：映像IoTやクラウド録画のPoCを計画する人
前提知識：IPカメラ、RTSP、クラウドサービスの基礎
経験時点：USBカメラの送信と、既存IPカメラ製品をエッジGW経由でKVSへ接続するPoCを2021年に実施
現在の未確認：現行Producer SDKでの再実行、製品運用向けの認証・監視・復旧、独自ビュワー
2026年時点の補足：技術仕様はAWSの現行Developer Guideで確認
扱わない範囲：商用サービス固有のSLA、料金試算、顧客管理、決済

当時の実施範囲と、その後の設計検討を先に分けます。

区分	この記事で扱う内容
当時の記録で確認できる実施	Raspberry PiとUSBカメラからKVSへ送信し、KVSコンソールで再生
筆者が実施したPoC	ローカル配信だけの既存IPカメラをエッジGW経由でKVSへ接続し、クラウド側で映像を確認
2021年の要求設計	ライブ表示、録画再生、時刻検索、ユーザー向けアプリ、異常検知など
未実施の製品化項目	AWS IoT証明書運用、監視通知、障害復旧、複数台運用、独自ビュワー

既存IPカメラPoCの公開可能な実行ログは残っていません。したがって、この記事は現行環境の再現ハンズオンではなく、実体験と要求資料を基にPoCの合格条件を組み直す記事です。

構成図では、製品名より先に役割を置く

クラウド録画システムは、クラウド製品名をいったん外すと、「映像を出す」「クラウドへ中継する」「取り込んで保持する」「機器を認証する」「状態を観測する」「再生・取得する」という役割に分けられます。一般図を先に置く目的は、特定サービスの紹介ではなく、責務の境界とPoCで確認すべき接続点をそろえることです。

一般的な役割	構成図で確認すること	今回の割り当て
映像源	どの形式・認証で映像を出すか	既設IPカメラ、RTSP／H.264（PoCで接続）
エッジ変換	入力をクラウド送信形式へ変える責務	エッジGW、GStreamer／Producer SDK（PoCで構築）
取込・保持	映像をどの単位で受け、保持するか	Amazon Kinesis Video Streams（PoCで確認）
デバイス認証	端末をどう識別し、権限を限定するか	AWS IoT Credentials Provider、Role Alias、IAM Role（製品化で追加）
観測	取り込み停止をどこで検知するか	CloudWatch Alarm＋端末ログ（製品化で追加）
再生・提供	ライブ再生、保存映像、クリップ取得をどう分けるか	PoC：KVSコンソール／製品：独自ビュワー

PoCで通した経路と、製品化で足す経路を分ける

内部資料の構成図をそのまま掲載すると、製品固有の境界や当時の条件まで表へ出てしまいます。公開記事では、社名、機種、台数、ネットワーク詳細を外し、上の一般的な役割へ置き換えました。そのうえで、PoCで実際に通した経路、実運用へ進むための追加設計、最終的な独自ビュワーを分けて示します。

今回の構成を一枚にするときも、映像の矢印だけでは足りません。少なくとも次の三つの経路を分けます。

映像・再生経路：IPカメラからRTSPを受信し、エッジGWからKVSへ送り、PoCではKVSコンソールで再生する
認証経路：エッジGWをデバイスとして識別し、KVSへ送るための一時認証情報を得る
観測経路：KVSのサービスメトリクスとエッジGWのログを分け、停止検知と通知を設計する

筆者が2021年に構築したのは、USBカメラによる最小送信と、既存IPカメラ製品の映像をエッジGWからKVSへ送り、クラウド側で確認するPoCです。図の青い主経路がこの実体験に当たります。AWS IoTを使った証明書運用、CloudWatch Alarmを含む監視、利用者向けの独自ビュワーは、そのPoCを製品として運用・提供するための追加設計です。

AWS IoTのCredentials Providerを使う構成では、エッジGWがX.509証明書で認証し、ロールエイリアスが指すIAMロールから一時的な認証情報を受け取ります。長期利用するアクセスキーを端末へ固定保存しないための候補ですが、「映像が送れた」とは別の試験項目として扱います。

また、CloudWatchへ自動的に出るのはKVSのサービスメトリクスです。映像停止を通知するには、Alarmの評価期間や欠損データの扱い、通知先を別途決めます。エッジGWのGStreamerログや再接続ログまで集約するなら、ログ転送の仕組みも必要です。図では、KVSメトリクスと端末ログを同じものとして描いていません。

PoCの閲覧にはKVSコンソールを使えますが、最終的なソリューションでは独自ビュワーからライブ映像、保存映像、クリップ取得を提供する想定でした。利用者認証とカメラごとの閲覧権限は、デバイスがKVSへ送信するための認証とは別の設計対象です。

図中のAWSサービスアイコンは、AWS公式のArchitecture Iconsを色や縦横比を変えずに使用しています。この図はAWSによる認定・推奨構成を示すものではありません。

要求をそのまま試験項目にしない

例えば「録画できること」という要求だけでは、次の違いを区別できません。

カメラから映像を受信できた
KVSへフレームが届いた
KVS上に保持された映像を再生できた
指定した時間帯をクリップとして取得できた
回線断後も欠落範囲を説明できた

要求をPoCへ落とすときは、要求、観測点、証拠を分けます。

要求	PoCでの問い	残す証拠
映像を取り込める	RTSPまたはUSB映像がKVSへ届くか	端末ログ、`PutMedia.IncomingFrames`、時刻
ライブ表示できる	現在映像を再生できるか	再生画面、開始時刻、体感ではない測定条件
過去映像を扱える	指定時刻の映像を再生・取得できるか	対象時刻、取得結果、フラグメント情報
回線断に耐える	切断後に自動復旧するか	切断時刻、再接続時刻、欠落区間
安全に接続できる	端末ごとに認証と権限を分けられるか	許可時の送信ログ、権限外アクセスの拒否、失効試験
障害を検知できる	映像停止を運用側で発見できるか	Alarm設定、欠損データの扱い、端末ログ、通知履歴

図では、要求が合格判定へ変わるまでの順序を示します。

例えば「回線断から復旧できる」を試験ケースにする

これは当時の実測結果ではなく、製品化へ進む際に使う試験ケースの形です。未測定の復旧秒数を作らず、まず判定に必要な欄を決めます。

項目	記録する内容
前提	KVSへの取り込みを確認済み、エッジGWと観測側の時刻を同期
操作	RTSPソース停止またはネットワーク切断を行い、予定した時刻に復旧
観測点	エッジGWの再接続ログ、`IncomingFrames`、Alarm状態、再生可能な時刻範囲
合格条件	手動再起動なしで復帰し、復旧時間と映像の欠落区間を説明できる。許容時間は要件決定後に設定
残す証拠	切断・復旧時刻、端末ログ、メトリクス、通知履歴、保存映像の確認結果

PoCを5段階に分ける

私は、クラウド録画のPoCを次の段階に分けるのがよいと考えています。

段階1：最小の映像を通す

1台のUSBカメラまたは再現用映像からKVSへ送ります。ここでは、Producer SDK、認証、リージョン、ストリーム名が正しくつながることだけを確認します。

筆者が2021年に最初に確認したのは、この入口です。

段階2：実際の入力境界へ近づける

次に、映像源を既設IPカメラのRTSPへ置き換えます。RTSP認証、RTP、H.264、GStreamerの各境界を分けて確認します。

当時のPoCでは、この段階まで実際に進みました。USBカメラで通ったあとも、既設IPカメラでは入力経路が変わり、失敗する場所が増えました。ただし、現在のSDKと匿名化した環境による再現ログは改めて取得します。

段階3：取り込みと再生を分ける

CloudWatchのPutMedia.IncomingFramesが増えることと、HLSなどで再生できることを別々に確認します。

取り込みメトリクスが増えていれば、少なくともKVSへ完全なフレームが届いています。それでも再生できない場合は、コーデック情報、フラグメント、時刻、再生セッションなどへ調査範囲を進められます。

段階4：意図的に壊す

製品化へ進むPoCでは、正常系だけでなく次の障害を意図的に起こします。当時ここまでは実施していません。

RTSPソースを停止する
ネットワークを切断する
認証を失敗させる
送信プロセスを再起動する
端末時刻を確認する

復旧できたかだけでは足りません。いつ停止し、いつ再接続し、映像のどこが欠けたのかを説明できる状態にします。

段階5：台数を増やす前に運用モデルを広げる

PoCの終盤で複数台へ広げる場合も、単にカメラ数を増やすのではなく、次を確認します。これも当時の実施結果ではなく、製品運用へ進むための検証案です。

1台ごとのストリーム識別
端末ごとの認証と失効
ログとメトリクスの識別
更新、再起動、設定変更の手順
障害端末だけを切り離せるか

段階を図にすると、どこから製品運用の評価になるかが見えます。

エッジGWは「カメラをつなぐ箱」ではない

当時のPoCでは、ローカル配信を前提とした既設カメラとKVSの間へエッジGWを置きました。公開記事では製品固有の構成を再現しませんが、実際にクラウド化を試したことで、GWが引き受ける責務が見えてきました。

エッジGWを置く理由は、カメラにクラウド送信機能がないから、だけではありません。

RTSPやメーカー固有入力をクラウド側の形式へ合わせる
カメラ認証とAWS認証の境界を分ける
ネットワーク断の間にどこまでバッファリングし、どう再送するかを設計する
ログ、再接続、死活監視を集約する
カメラを外部ネットワークへ直接公開しない

一方で、GWを増やすと、OS更新、証明書更新、ストレージ枯渇、プロセス監視など新しい運用対象も増えます。PoCでは「置けるか」ではなく、「GWが引き受ける責務は何か」を確認します。

ライブ再生とファイル取得は別の機能である

PoCではKVSコンソールで映像を確認しましたが、最終的には独自ビュワーとして提供する想定でした。要求仕様では「再生」という言葉が一つでも、技術的には複数の経路があります。

現在映像を見る
保存済み映像をオンデマンド再生する
指定時間帯をMP4クリップとして取得する
フレームを取り出して解析する

AWSの現行資料では、HLSはライブ映像と保存映像の再生に使えます。保存映像をオンデマンド再生するには、対象時間帯のデータが保持されている必要があります。GetClipは、指定時間範囲の保存映像をMP4として取得するAPIで、データ保持期間が0より大きいことなどの成立条件があります。

したがって「ブラウザで映った」を、録画ファイル取得の合格証拠にはできません。

合格条件には観測手段を書く

PoCのチェックリストを「できた／できない」だけにすると、後から再検証できません。最低限、次を残します。

実行日時とタイムゾーン
カメラまたは映像源の種類
コーデックとストリーム設定
Producer SDK／GStreamerのバージョン
ストリーム名を匿名化した識別子
端末ログとCloudWatchの対応時刻
切断操作と復旧時刻
成功画面だけでなく失敗ログ

当時のPoCで映像経路を通した経験はありますが、公開可能な匿名ログと現行環境の実測値は残っていません。この記事では記憶から復旧秒数や遅延値を補わず、製品化時に記録すべき条件と証拠だけを示しています。

「映った」の次に何を確認するか

このPoCでは、ローカル配信しかできなかった既存製品の映像をKVSまで届けるところまで構築しました。しかし、PoCの価値は、その成功をそのまま製品完成と呼ぶことではなく、どこまで確認済みかを線引きすることにあります。

次に確認するのは、保存、時刻指定、復旧、認証、監視、そして独自ビュワーからの提供です。これらを別々の証拠で確認できれば、PoCはデモから実運用とソリューション設計の材料へ変わります。

参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up