カメラ1台あたりのビットレート
—
Mbit/s
無料ツール
CCTV / NVR ストレージ計算ツール
カメラ1台あたりのビットレート、総スループット、必要なストレージ容量、RAID構成、そして信頼性の高い設置のために購入すべきディスク本数を見積もります。
計算結果
総ビットレート
—
Mbit/s
生ストレージ容量
—
TB
購入が必要な容量
—
TB
ヒント：内蔵の印刷機能を使えば、クライアントや調達担当者向けに見やすい1ページの概要を出力できます。
この計算ツールの使い方
- まずカメラ台数、解像度、コーデックを設定します。動体検知時に各カメラがどれだけの帯域を必要とするかを見積もります。
- RAID レベルとディスク本数を調整して、実効容量と実際に購入すべきディスクサイズを確認します。
- 特定のレコーダーや設置仕様からカメラごとのプロファイルが既に分かっている場合は、手動ビットレートをオンにします。
- 印刷概要を使えば、チームやクライアントと調達のスナップショットをすばやく共有できます。
CCTV & NVR ストレージ計算ツール：技術リファレンスガイド
このガイドでは、当社の CCTV ストレージ計算ツールを動かす計算、経験的な公式、そして中心となる前提条件を詳しく説明します。目標ビットレート、圧縮方式の選択、ストレージのオーバーヘッドが録画保持プロファイルにどう影響するかを理解するための参考としてご利用ください。
エンジンは容量を見積もるために、ビットレートの推定、圧縮規格（H.264 と H.265 のストレージ要件）、アレイのトポロジー（CCTV RAID 計算の指標）という3つの運用領域を評価します。
1. ビットレートの推定方法
このカメラストレージ推定ツールは、一般的な固定値の参照に頼るのではなく、実世界のカメラ性能指標に基づいて帯域消費をシミュレートする動的な計算モデルを適用します。
稼働中のカメラのスループットを求める主要な公式は次のように定義されます：
Bitrate_Active = baseBR × fpsFactor × K_Codec × K_Scene
基準ビットレート（baseBR）
基準となるインフラ負荷は、センサーの解像度から直接計算されます：
baseBR = Resolution (MP) × 1.3
適用例： 標準的なフルHD 1080p カメラ（約2.07 MP）を基準の15 FPS、標準的な H.264 圧縮、中程度のシーンの複雑さで運用すると、次のようになります： 2.07 × 1.3 × 1.0 × 1.0 ≒ 2.69 Mbit/s この係数は、稼働中の監視において最適な画素密度を確保するために、ベンダーの計画ガイドから導かれた経験的な基準値です。
フレームレートのスケーリング（fpsFactor）
帯域のスケーリングは、フレームレート（FPS）の変更に対して線形には増加しません。最新のエンコーダは、静止画像を順次まるごと送信するのではなくフレーム間の時間的な差分を捉えるため、フレームレートを2倍にしても総容量への影響は線形未満にとどまります。エンジンはこの挙動を正確にモデル化するため、べき乗則の曲線を適用します：
fpsFactor = (FPS / 15)^0.45
このスケーリング係数により、高フレームレート（30 fps）の設計時に容量を過剰に割り当てることを避けられます。
2. H.264 と H.265 のストレージ要件
映像圧縮の効率は、周囲の環境ノイズと動きのエントロピーによって変化します。
| コーデックの選択肢 | 倍率（K_Codec） | 監視ストレージへの実際の影響 |
|---|---|---|
| H.264 Baseline | × 1.00 | 標準的なレガシー基準。主に古いエンコーディングハードウェアとの後方互換性のために残されています。 |
| H.264 High | × 0.60 | 高度なエントロピー符号化を利用した最適化版 H.264。容量を約40%削減します。 |
| H.265 / HEVC | × 0.40 | 高効率映像符号化。標準的な H.264 プロファイルと比べて、通常ビットレート要件を約40〜60%削減します。 |
| H.265+（スマート） | × 0.25 | 動的モード。背景モデリングを用いて静的シーンのオーバーヘッドを最小化します。ノイズの多い条件（K_Scene >= 1.4）では、継続的なシーンの変化のため自動的に × 0.38 まで引き下げられます。 |
シーンの複雑さによる補正（K_Scene）
- 低（× 0.7）： 画素の変化が最小限に抑えられた、入退室管理された環境（例：静かな倉庫や夜間の屋内通路）。
- 中（× 1.0）： 適度な人通りのある標準的な店舗環境や商業スペース。
- 高（× 1.4）： 絶え間ない動きが生じやすい、動的で制約のない屋外環境（例：交通量の多い交差点、人混み、揺れる木々、変動する照明）。ノイズが多いとフレーム間圧縮の効率が低下します。
3. 動体検知の影響
動体検知録画の構成が有効になっている場合、プラットフォームは2状態のデューティサイクルを適用します。非アクティブな期間には、データストリームはユーザーが定義した待機時 FPS の上限まで下がり、シーンの複雑さを最小限（0.7）まで引き下げます。正味の時間的要件は次のように計算されます：
Bitrate_Mean = (Bitrate_Active × M) + (Bitrate_Idle × (1 - M))
ここで M は、標準的な24時間サイクルにおける動きの活動量の推定割合を表します。加えて、音声収録が選択されている場合、標準的な G.711 PCM の音声ストリームを考慮して、カメラ1台あたり64 kbit/s（0.064 Mbit/s）の固定割り当てが稼働中の予算に追加されます。
4. RAID のストレージオーバーヘッド
物理ドライブの計画は、単純な数学的容量の枠を超えます。内蔵の CCTV RAID 計算モジュールは、標準的な耐障害性アレイを利用して、購入すべきストレージ階層の数を正確に求めます：
- RAID 1： 純粋なミラー構成。冗長性のオーバーヘッドとして正味容量のちょうど 2.0 × を必要とし、ディスクは N=2 本に限定されます。
- RAID 5： 分散シングルパリティ。最低3本のドライブが必要。ストレージ割り当ての損失はちょうどドライブ1本分に等しく、N / (N - 1) となります。
- RAID 6： 分散ダブルパリティ。最低4本のドライブが必要。パリティデータ用に2本のドライブを確保することで、2本同時のドライブ故障に耐えます：N / (N - 2)。
- RAID 10： ミラー / ストライプを組み合わせたアレイ。最低4本のドライブが必要で、偶数本の構成（N mod 2 = 0）に厳密に限定されます。物理容量の半分（50%）がオーバーヘッドに使われます。
ドライブの計算： エンジンは耐障害性の総要件をドライブ本数（N）で割り、その結果を標準的な市販 HDD の容量区分（例：2、4、6、8、12、16、20 TB）に自動的に当てはめます。
5. ストレージとファイルシステムのオーバーヘッド
体系的な容量損失を吸収するため、映像監視ストレージの計算プロセスには基準となるオーバーヘッドの設定（推奨15%）が含まれています：
- 2進数と10進数の換算： HDD ベンダーは10進表記（1 TB あたり 10^12 バイト）で容量を計算しますが、OS は2進表記（1 TB あたり 1024^3 バイト）でアレイをフォーマットします。この体系的な不一致により、物理ドライブ容量は約7.3%減少します。
- メタデータのジャーナリング： ファイルシステム（EXT4 や XFS など）は、メタデータのインデックス、ファイル復旧テーブル、セクタマッピングのために一定割合のストレージブロックを確保します。
- ガードバンド： NVR のストレージアレイは完全に満杯になると書き込み効率が低下します。標準的な5〜10%のバッファを確保しておくことで、定期的な自動 FIFO ディスク消去の際の性能低下を防げます。
6. NVR のスループット上限
システム全体の総スループットが 320 Mbit/s を超えると、本ツールは最適化の警告を表示します。
標準的なギガビットインターフェースはより高い生データ量を扱えますが、320 Mbit/s は多くの中位クラスの商用 NVR プラットフォームにおける一般的な録画スループットの上限を表しています。この境界を超えると、内部の SoC（system-on-chip）の処理経路やストレージデータベースエンジンの書き込み速度がボトルネックになります。その結果、映像フレームの欠落、ストリームの不安定化、再生の遅延が直接引き起こされます。このしきい値を超えて運用するシステムでは、複数の NVR ノードへのネットワーク分割、または高スループットのプロジェクト向けハードウェアへのアップグレードが必要になります。