監視カメラの構成は、型番から選ぶと失敗する — 設置環境の5要件から必要仕様を導く

「おすすめの監視カメラ、型番で教えてください」

現場からよくいただく相談です。そして、このままでは答えられません。要件が決まっていないと、仕様は決まらないからです。

同じ「監視カメラ」でも、昼だけ映ればいいのか夜も撮るのか、5m先を映すのか50m先なのか、リアルタイムで見たいのか翌朝まとめて見ればいいのか — この違いで正解の構成は真逆になります。型番から入ると、この違いを飛ばして「無難そうな高機能機」を選び、現場で「夜が真っ黒」「遠くて誰か分からない」「回線が細くて送れない」と気づくことになります。

私の進め方は逆です。設置環境の5つの要件を先に埋める。そうすると、接続方式・電源・保存・製品候補が自動的に絞れてきます。 型番は、いちばん最後に落ちてくる結論です。

この記事では、その5要件と導出の手順を、実際に自分の圃場カメラを設計した例まで通して説明します。

5つの要件

順に見ていきます。各要件で「何が決まるか」と「見落としがちな落とし穴」を押さえれば、あとは自分の案件に当てはめるだけです。

① 照度 — 昼だけか、夜もか

最初に決めるのは明るさです。これが暗視機構の要否を決めます。

明るさは lux(ルクス、照度の単位。その場所がどれだけ明るいか)で表します。桁を押さえておきます。

夜間に撮るなら、可視光カメラは 0.1 lux あたりから急激に苦しくなります。対策は主に2つ。赤外(IR)照明を足す(850nmは薄赤く光る、940nmは人の目に見えない)か、対象自身が熱を持つならPIR/サーモで補う。多くの屋外カメラは昼はIRカットフィルタを入れて色を出し、夜は外してIRで白黒撮影する「デイナイト切替」を持っています。

逆光にも触れておきます。西日や、明るい空を背に暗い対象を撮る構図では、**WDR(ワイドダイナミックレンジ)**が無いと対象が黒く潰れます。照度は「暗さ」だけでなく「明暗差」の問題でもあります。

落とし穴は「高画素なら夜も安心」です。 画素数は明るさを作りません。夜が主戦場の用途では、解像度より先に照度対策を決めないと、どれだけ高画素でも真っ黒な画像が並びます。目的が「夜間の対象」なら、この要件が最優先になります。なお、その暗視照明を「IRを足す」で終わらせず距離と画角から設計する手順は、暗視・IR光源の設計編にまとめました。

② 撮影距離と画角 — 必要な解像度は計算できる

「4Kにしておけば安心」とよく言われますが、これは半分だけ正しい。広く撮るほど、対象1つあたりの画素は減ります。 必要な解像度は、感覚ではなく計算で出せます。

順序はこうです。

1. 対象までの距離と、必要な画角から「写る幅」が決まる
2. 写る幅と、対象の大きさから「対象に乗る画素数」が決まる
3. 用途が要求する画素数を満たす解像度を選ぶ

3の基準には、国際規格の DORI(IEC 62676-4) が使えます。px(ピクセル、画素)を使い、シーンの横1mあたり何画素あるか(px/m)で、何が判別できるかを定義したものです。

計算してみます。1080p(横 1920 px)のカメラで、5m先を横幅いっぱいに撮るとします。

画素密度 = 1920 px ÷ 5m = 384 px/m
（シーンの横1mを 384 画素で表せる）

384 px/m は DORI の識別レベル(250 px/m)を超えています。つまり、この距離・この画角なら1080pでも人物の識別ができる。逆に、同じ1080pで横20mを撮ろうとすると 96 px/m まで落ち、検知はできても認識は苦しくなります。「4Kか1080pか」ではなく、「距離と画角を決めてから必要な画素数を逆算する」 のが正しい順序です。

③ 許容できる遅延 — リアルタイムは高い

意外に見落とされ、そしてコストを最も動かすのがこれです。「どれくらい遅れて見えても許容できるか」。

3つに分かれます。

• リアルタイム(数百ミリ秒) — 遠隔操作や、その場で対応する監視。WebRTC や低遅延RTSPが要る
• 準リアルタイム(数秒) — 通常の監視映像。RTSP/HLS で十分
• バッチ(分〜時間〜日) — 記録、定点モニタ。定期的に静止画や短い動画を送るだけでよい

遅延要件は、通信方式・電源・装置・回線費用のすべてに波及します。落とし穴は、要らないリアルタイムを前提に設計してしまうこと。 「翌朝まとめて見れば足りる」用途に常時ライブ配信を組むと、常時通電・常時通信が必要になり、電源も回線も装置も一段跳ね上がります。日次のスナップショットで足りるなら、電池とたまの通信で済むこともある。遅延要件を1段緩めるだけで、構成全体が軽くなることは珍しくありません。

④ 保存期間 — どこに、いつまで

保存期間は、容量・録画方式・保存先を連鎖的に決めます。まず容量。映像の重さは bps(ビット毎秒、1秒あたりに送る/記録するデータ量)で表します。

2 Mbps（メガビット毎秒）で連続録画した場合:
2 Mbit/s × 86,400秒 = 約 21.6 GB/日 = 約 650 GB/月

これを「動体検知したときだけ録画」に変えると、実際の録画時間が数十分の一になり、容量も費用も激減します。保存期間の長さが、常時録画か動体録画かを決める ということです。

保存先も要件次第です。

• ローカル(SDカード / NVR) — 通信が要らない。ただし機器の故障・盗難・回収の手間がリスク
• クラウド(S3等) — 遠隔から見られ、冗長性も確保できる。ただし送るための回線が必須

クラウドなら、ライフサイクル設定で「一定期間後に安価な階層へ移す/削除する」を自動化できます。落とし穴は「念のため長く」。 保存期間を延ばすほど、容量・録画方式・回線がすべて重くなります。実際に見返す期間を現場と詰めておくと、構成が締まります。

⑤ 回線条件 — 回線が構成を縛る

最後に、その画像をどう運ぶか。回線の上り帯域(アップロード方向の速度)が、送れる画質と頻度の上限を決めます。

回線ごとの帯域の目安を並べます(単位は bps。1,000 bps = 1 kbps、100万 bps = 1 Mbps)。

ここは強調させてください。LoRa は画像を運べません。 1枚数百KBの画像に対して、LoRaの帯域は桁が3つも4つも足りません。加えて電波の占有時間に規制があり、大きなデータを連続送信できない。LoRa はセンサ値や「動きがあった」というイベント通知を、極低電力で遠くへ運ぶための回線であって、画像用ではありません。

「IoTカメラだから LoRa」というのは、役割の取り違えです。画像を運ぶ回線(WiFi/LTE)と、イベントを運ぶ回線(LoRa)は目的が違う。両方が要るなら、二段構成にします。常時は LoRa か PIR で「動いた」を低電力で送り、そのトリガのときだけ LTE で画像を1枚送る。こうすれば、電力を食う通信を必要な瞬間に絞れます。

要件が決まると、構成が落ちてくる

5要件が埋まると、接続方式・電源・保存・製品候補がほぼ機械的に絞れます。組み合わせの例を挙げます。

同じ「屋外カメラが欲しい」でも、要件次第で答えがこれだけ変わります。逆に言えば、要件を先に固めれば、製品カタログを眺める前に構成の方向が決まるということです。

そのまま使えるチェックリスト

初回に、この5つを埋めてみてください。埋まった時点で、構成の8割は決まっています。

• ① 照度:昼だけか、夜もか。夜があるなら対象は光るか(IR/PIRの要否)。逆光はあるか
• ② 撮影距離と画角:対象までの距離は。どこまで(検知/認識/識別)必要か。→ 必要な px/m を逆算する
• ③ 許容できる遅延:リアルタイムか、数秒か、翌日でよいか
• ④ 保存期間:どこに、いつまで残すか。常時録画か、イベント録画か
• ⑤ 回線条件:上りは何が使えるか(有線/WiFi/LTE/LoRa/なし)。従量か定額か

ワークショップ:自分の圃場カメラを5要件で通す

抽象論だけでは腹に落ちないので、実際に自分の畑に付けるカメラを、この5要件で設計した過程を通します。目的は「畑に来る人や獣を把握したい。ついでに作物(朝顔)の育ちも記録したい」。

① 照度 — 対象は人と獣。ここで最初の発見がありました。狙っている獣(タヌキ・ハクビシン・アライグマ)はほぼ夜行性です。つまり主戦場は夜。この瞬間に、この案件の決定的要件は解像度ではなく照度だと決まりました。IR暗視が無ければ、どれだけ高画素でも目的を達成できない。

② 撮影距離と画角 — 畑は3×5m。支柱を1mに立て、水平に向けます(獣は体高20〜40cmと低く、真上から見下ろすより横から見た方が背景に対して輪郭が出る。トレイルカメラの定石です)。5m先をOV2640の横幅(1600px)いっぱいに撮ると 320 px/m、幅30cmの獣で約96画素。DORIの識別レベルを超えており、1台で全域をカバーできます。朝顔は支柱を縦に登るので、水平撮影なら成長も同じフレームに収まります。

③ 許容できる遅延 — 生育モニタは日次で十分、冠水チェックは雨の直後に見たい、人獣は動いたとき。常時ライブは要らないと決まりました。イベント時 + 定期スナップで足ります。

④ 保存期間 — S3に保存。日付とカメラIDでキーを切り、定点の日次比較(タイムラプス)が成立する形にします。

⑤ 回線条件 — 今の畑は自宅のWiFiが届き、商用電源も引けます。ここは恵まれた条件。ただし将来はリモートの圃場も監視したい。そこで二つ目の発見 — リモート化すると LoRa は画像を運べない。だから将来構成は、LoRa/PIRで「動いた」を送り、トリガ時に LTE で画像を送る二段になります。

ここまで埋めると、構成が落ちてきます。手持ちの Seeed XIAO ESP32-S3 Sense(親指サイズ・カメラ付き)を IR化(IRカット除去 + 850nm LED)して3Dプリンタで筐体を作り、画像は presigned URL で S3 に上げる(デバイスに AWS の認証情報を焼き込まない — 署名付きURLを基盤側で発行する)。閲覧用のWebページを別に用意する。 — 型番の暗記ではなく、5要件からここまで導けました。

まとめ

型番は、要件のあとにしか決まりません。照度・撮影距離と画角・許容できる遅延・保存期間・回線条件 — この5つを先に埋めれば、接続方式も電源も保存も製品候補も、機械的に絞れてきます。そして選定の根拠が残るので、後から環境や要件が変わっても、自分で構成を見直せます。

「おすすめの型番は?」の前に、この5つ。カメラ構成で迷ったら、ここから始めてみてください。