解説: 通信 — 映像が届かなければ巡視は成立しない
画素密度が足りていても、映像が届かなければ遠隔巡視は成り立ちません。 このページでは、通信をどう扱うか、なぜ点数ではなくハードゲートで判定するのかを説明します。
1. 経路のどこが細いかで決まる
現場のカメラから監視端末までは、撮像 → 圧縮 → 回線 → 表示という経路をたどります。 画素の流れと同じく、ここでも一番細いところが全体を決めます。 現場側の上り帯域（アップリンク）が不足すると、まず fps が落ち、次に画質が落ち、 最後に切断します。
図1: 映像が届くまでの経路。多くの現場では回線が最も細い
2. 圧縮は「画素の質」を落とす
帯域が足りないときエンコーダは圧縮を強めます。解像度（画素の数）は同じでも、 細部のコントラストが失われ、ブロックノイズやにじみが出ます。画素密度は「量」の指標で、圧縮による「質」の劣化は含みません。
図2: 同じ画素数でも、強い圧縮では細部の情報が落ちる
このため、本アプリのカバレッジ判定は「これだけあれば必ず判別できる」ことの保証ではありません。 実運用の圧縮条件・照度・動きの速さで結果は変わります。実機 PoC での確認が前提です。
3. なぜ帯域を「計算」しないのか
必要ビットレートはコーデック（H.264 / H.265）、被写体の動き、シーンの複雑さ、 エンコーダの設定で大きく変わります。もっともらしい式を置くことはできますが、 その数字は根拠のない断定になります。本アプリは計算しない代わりに、計画値を人が宣言する方式を採っています。
- 上り帯域（Mbps）・想定遅延（ms）・通信途絶時の代替手段をシナリオに記録する
- 記録がなければ「未確認（UNKNOWN）」として扱い、合格にはしない
- レポートには宣言した計画値がそのまま出力され、後から検証できる
プリセットの Stream（解像度・fps・ビットレート）はカタログ値です。 実運用の配信設定に合わせて調整してください。
4. ハードゲートとしての通信
通信は「良い / 悪い」を点数化して他の項目と足し合わせられる性質のものではありません。 途絶すれば、どれだけカバレッジが良くても巡視は成立しないからです。 そのため第 1 段階のハードゲートで判定します。
| ゲート | 合格の条件 | 未設定のとき |
|---|---|---|
| 通信途絶時の代替手段 | 冗長化が「なし」以外（固定回線・モバイル等のバックアップ） | 未確認（UNKNOWN） |
| 異常時に対応する現場担当者 | 現地対応者ありと宣言されている | 未確認（UNKNOWN） |
| 定期的な直接巡視計画 | 直接巡視の間隔が設定されている | 未確認（UNKNOWN） |
ハードゲートの不適合・未確認は、カバー率が 100% でも点数で相殺されません。総合判定は「要実測検証」か「不適合」に留まります。
5. 現場で決めておくとよいこと
- 上り帯域の実測値（カタログ値ではなく、その場所・その時間帯で測った値）。 LTE/5G は場所と時間で大きく変わります
- 途絶したときの代替手段と、切り替えの判断者・手順
- 遅延の許容範囲。PTZ を遠隔操作するなら、操作から画が動くまでの往復遅延が効きます
- 録画の保存場所（現場側 SD / クラウド）。途絶中の記録が後から回収できるか
将来的には、カメラの Stream ビットレートの合計と宣言帯域を突き合わせる簡易チェックを 追加する余地があります（現時点では未実装）。