MirAI-V2

システム構成図

オンプレミス AI 映像管理システム（VMS）のシステム構成・データフローに関する説明書

バージョン / Version	2.0.3
発行日 / Issue Date	2026-06-17
発行 / Issued by	MarkAny Co., Ltd.

改訂履歴 / Revision History

版数	発行日	改訂内容	承認
1.0	2026-06-17	初版作成	—

目次 / Contents

システム概要
構成図
構成要素
ネットワーク構成
物理構成
データフロー
備考・前提条件

1. システム概要

MirAI-V2 は、MarkAny Co., Ltd. が提供するオンプレミス型 AI 映像管理システム（VMS）です。IP カメラ（ONVIF / RTSP）から映像を取り込み、NVIDIA GPU 上の AI 推論エンジンによりリアルタイムで物体検知・火災／煙・転倒・侵入等のイベントを検出し、録画・再配信・通知・専用クライアントによる監視を一体的に提供します。AI 推論を含むすべての処理はお客様構内のサーバー内で完結し、映像データを外部クラウドへ送信することはありません。

本システムは、大きく次の 3 つの層（サブシステム）で構成されます。

カメラ層：標準プロトコル（ONVIF / RTSP）に準拠した IP カメラ群。サーバーがカメラへ接続し、RTSP プルにより映像を取得します。
サーバー層（MirAI サーバー）：システムの中核。映像取り込み（GStreamer）、AI 推論エンジン（GPU / TensorRT）、REST／WebSocket／TCP API、PostgreSQL データベース、RTSP 再ストリーミングサーバー、録画ストレージを担います。Rust（Axum）で実装され、AI 推論エンジンはプロセス内 DLL として動作します。
クライアント層（MirAI クライアント）： Qt / C++ で実装された専用監視アプリケーション。ライブ映像のグリッド表示、AI パイプライン編集、通知・インシデント履歴の閲覧等を行います。サーバーとは暗号化通信（HTTPS / WSS / TCP）で接続します。

主なサブシステムは次のとおりです。

サブシステム	役割
映像取り込み（Ingest）	カメラから RTSP で映像を取得し、GStreamer の tee ベースパイプラインで「録画・再配信用（パススルー）」と「AI 推論用（デコード）」の 2 系統に分岐。
AI 推論エンジン	GPU（TensorRT 10.8 / ONNX Runtime）上で検知・分類・トラッキングを実行し、定義されたルールに基づきイベントを生成。
API サービス	REST（CRUD 操作）、WebSocket（イベント・状態のリアルタイム同期）、TCP（映像・画像のバイナリ転送）を提供。
データベース	PostgreSQL によりユーザー・カメラ設定・AI パイプライン・インシデント履歴・通知ルール・監査証跡等の永続データを保管。
録画・再配信	録画ファイル（セグメント分割）の生成と、RTSP 再ストリーミングサーバーによるクライアントへの映像再配信。

2. 構成図

本システムの構成要素と、カメラ・サーバー・クライアント間のデータ／制御フローを以下のブロック図に示します。矢印にはプロトコルとポートを併記しています。

図 1. MirAI-V2 システム構成ブロック図（データ／制御フロー、矢印にプロトコル・ポートを併記）

カメラからの映像は GStreamer の tee により 2 系統に分岐します。録画・RTSP 再配信用の「パススルー系統」はエンコード済みパケットをそのまま扱い、CPU 負荷を最小化します。AI 推論用の「デコード系統」は NVDEC（GPU ハードウェアデコーダー）でデコードし、フレームレートを抑制（既定で最大 7〜10 fps）したうえで AI エンジンへ送ります。

3. 構成要素

各構成要素の役割と採用技術を以下に示します。

構成要素	役割	技術
MirAI サーバー（API）	REST API（全 CRUD）・WebSocket（イベント／状態の同期）・TCP（映像／画像転送）の提供、認証・認可、カメラライフサイクル管理。	Rust / Axum、JWT + RBAC、TLS
AI 推論エンジン	GPU 上で検知（YOLO/SSD 系）→分類（火災・転倒等）→トラッキング（ByteTrack）→ルール評価を実行しイベントを生成。サーバー内 DLL として動作。	C++ / CUDA、TensorRT 10.8、ONNX Runtime
映像取り込み（Ingest）	カメラへ RTSP 接続して映像を取得。tee で録画・再配信用とAI 推論用に分岐し、GPU デコード・フレーム抽出を実施。	GStreamer、NVDEC（nvh264dec / nvh265dec）
データベース	ユーザー・カメラ・AI パイプライン・インシデント履歴・通知ルール・監査証跡・セッション・システム設定の永続化。	PostgreSQL（接続プール 10、ポート 5432）
RTSP 再ストリーミングサーバー	取り込んだ映像をクライアントへ再配信。メイン（高解像度）とサブ（グリッド表示用の低解像度）を提供。	RTSP サーバー（メイン 8554 / サブ 8555）
録画ストレージ	連続録画／イベント録画ファイルの保存（60 秒単位のセグメント分割）。最低空きディスク率保護を内蔵。	専用録画ドライブ（HDD / NVMe）、リングバッファ
MirAI クライアント	ライブ映像のグリッド表示、AI パイプラインのノードベース編集、通知・インシデント履歴の閲覧、多言語 UI（日本語 / 英語 / 韓国語）。	Qt 6 / C++（ダークテーマ）
IP カメラ	映像ソース。標準プロトコル準拠の既設カメラ資産を活用可能。	ONVIF（自動検出）／ RTSP（手動 URL）
GPU（推論アクセラレーター）	AI 推論・映像デコードを担うハードウェア。同時処理可能なカメラ台数を左右する。	NVIDIA GPU、CUDA 12.8、TensorRT 10.8

初回起動時、AI エンジンはお客様の GPU 向けに最適化モデル（TensorRT エンジン）をビルドします。この処理には 15〜30 分程度を要し、初回のみ発生します。

4. ネットワーク構成

MirAI-V2 はクライアント／サーバー間およびカメラとの通信に以下のポート・プロトコルを使用します。クライアントとサーバーが別機器の場合は、サーバー側ファイアウォールで該当ポートの受信を許可してください。

4.1 サービスポート（クライアント ↔ サーバー）

用途	ポート	プロトコル	認証
REST API（全 CRUD 操作）	7878	HTTPS / TCP	Bearer JWT
リアルタイム同期（イベント・状態通知）	7575	WSS（WebSocket over TLS）/ TCP	接続初回メッセージでトークン認証
バイナリファイル転送（映像クリップ・画像）	7979	TCP	トークンヘッダー
RTSP 再ストリーミング（メイン）	8554	RTSP / TCP	—
RTSP 再ストリーミング（サブ：低解像度）	8555	RTSP / TCP	—
ライブ映像ストリーミング	7676	UDP	—

4.2 サーバー ↔ カメラ／データベース

用途	ポート	プロトコル	備考
カメラ映像取り込み（RTSP）	554	RTSP / TCP	カメラ標準ポート（機種により異なる場合あり）
カメラ検出・制御（ONVIF）	80 / 443	HTTP / HTTPS	ONVIF デバイス検出・設定取得
データベース接続	5432	TCP（PostgreSQL）	サーバーローカル（localhost）接続を推奨

TLS（暗号化）について：MirAI-V2 は既定で TLS（TLS 1.3）を有効化しており、HTTPS（7878）および WSS（7575）で通信します。初回起動時にサーバーが自己署名証明書を自動生成します（Trust On First Use 方式）。お客様の認証局（CA）が発行した証明書への差し替えにも対応可能です。なお、転送中のパスワードは AES-128-CBC で暗号化され、保存時は bcrypt / Argon2id でハッシュ化されます。

5. 物理構成

MirAI-V2 は、小規模からの単一サーバー構成と、高密度運用に向けたマルチ GPU 構成の双方に対応します。GPU を増設することで、収容カメラ台数を水平方向に拡張できます。

5.1 単一サーバー構成（標準）

1 台の GPU 搭載 Windows サーバー上で、ランチャー（Windows サービス）、MirAI サーバー（API・AI エンジン・取り込み）、PostgreSQL、録画ストレージをすべて稼働させる標準構成です。クライアントは同一機器、または LAN / VPN 経由で別機器から接続します。

区分	構成内容
サーバー機器	GPU 搭載 Windows サーバー（ワークステーション）1 台
稼働プロセス	ランチャー（Windows サービス）／ MirAI サーバー（API・AI エンジン DLL・GStreamer 取り込み）／ PostgreSQL
クライアント	1 台以上のクライアント機器（同一機器または LAN / VPN 経由）
GPU	NVIDIA GPU × 1

5.2 マルチ GPU 構成（高密度運用）

多数台のカメラを同時に AI 推論する高密度運用には、2 CPU／4〜8 GPU のマルチ GPU 構成に対応します。各 GPU に推論エンジンインスタンスを 1 つずつ割り当て、カメラを GPU 単位に分配（フレームルーター）することで負荷を分散します。GPU メモリ（VRAM）容量別の収容台数の目安は以下のとおりです。

GPU メモリ（VRAM）	推奨カメラ台数（1 GPU あたり）	推論バッチサイズ（目安）
8 GB	8 〜 12 台	16
12 GB	12 〜 20 台	24
16 GB	16 〜 24 台	30
24 GB	24 〜 32 台	32

サーバー構成	GPU 数	収容カメラ台数（目安）
単一 GPU 構成	1	GPU の VRAM 容量に応じ上表のとおり
4 GPU 構成	4	約 64 台（1 GPU あたり 16 台）
8 GPU 構成	8	約 128 台（1 GPU あたり 16 台）

上表は設計上の目安であり、実際の収容台数は解像度・解析 FPS・有効化する AI 機能・カメラのフレームレートにより変動します。マルチ GPU 構成では、いずれかの GPU に障害が発生した場合でも、対象カメラを健全な GPU へ再割り当てし、縮退運転で稼働を継続します。最終的な構成・収容台数は導入前検証（PoC）およびサイジングにて確定いたします。
具体的なサーバー仕様（CPU・GPU 機種・台数・ストレージ容量）： [サイジング結果に基づき確定]

6. データフロー

カメラ映像が取り込まれてからクライアントに表示・通知されるまでの一連の流れを、番号順に示します。

映像取り込み（カメラ → サーバー）： サーバーが各カメラへ RTSP（ポート 554）で接続し、GStreamer により映像を取得します。tee により「録画・再配信用（パススルー）」と「AI 推論用（デコード）」の 2 系統へ分岐します。
デコード・フレーム抽出（取り込み → AI）： AI 系統では NVDEC（GPU ハードウェアデコーダー）で映像をデコードし、解析用にフレームレートを抑制（既定で最大 7〜10 fps）したうえでフレームを抽出します。
AI 推論（AI エンジン）： 抽出フレームを GPU（TensorRT / ONNX Runtime）でバッチ処理し、検知 → 分類 → トラッキングを実行します。マルチ GPU 構成ではフレームルーターがカメラを GPU 単位に振り分けます。
イベント判定（ルール評価）： 検知結果を、定義済みのイベントルールおよび誤検知抑制のしきい値（例：火災 0.45 / 煙 0.40 / 転倒 0.80）に照らして評価し、条件成立時にインシデントを生成します。
録画・保存（パススルー系統 → ストレージ・DB）： パススルー系統のエンコード済み映像を録画ファイル（60 秒単位のセグメント）として保存し、インシデント情報（サムネイル・映像パス・種別・信頼度・タイムスタンプ）を PostgreSQL に記録します。
通知・配信（サーバー → クライアント）： 通知ルール（レート制限・サイレント時間帯等）を適用のうえ、設定チャネル（メール／Webhook／SNMP／HTTP）へ配信するとともに、WebSocket（7575）で接続中クライアントへインシデントをブロードキャストします。
クライアント表示（クライアント）： クライアントは WebSocket で受信したインシデントを通知パネルに表示し、サムネイルや映像クリップを HTTP（7878）／ TCP（7979）で取得、ライブ映像は RTSP 再配信（8554 / 8555）で表示します。

7. 備考・前提条件

本システムはオンプレミス（お客様構内設置）型です。AI 推論はサーバー内で完結し、映像データを外部クラウドへ送信することはありません。
AI 推論には NVIDIA GPU が必須です。NVIDIA 以外の GPU、または GPU 非搭載環境では AI 機能は動作しません。
本書記載のポート・プロトコル・採用技術等の確定値は、MirAI-V2 v2.0.3 の標準構成に基づきます。
図中および本文で示した収容台数・フレームレート等の目安は、お客様の運用条件（カメラ台数・解像度・解析 FPS・保存期間等）に基づくサイジングにて確定します。詳細は別冊「動作環境・システム要件書」を併せてご参照ください。
本書の内容は、製品改良等により予告なく変更される場合があります。