「せっかく高価な4Kカメラを導入したのに、遠くにいる不審者や小さな異常箇所がまったく検知されない」
AI監視システムの開発現場では、このような課題に直面するケースが頻繁に見受けられます。開発チームは検知精度（mAP）を向上させるため、最新のYOLOv10の検証、学習データの増強（Augmentation）、モデルサイズのNanoからLargeへの変更など、様々なアプローチを試みています。
しかし、推論速度が低下してGPUサーバーのコストが増大するだけで、肝心の「小さなターゲット」は依然として検知されないまま、行き詰まりを感じるプロジェクトも少なくありません。
この問題の本質は、AIモデルのアルゴリズム自体にあるのではなく、モデルに入力する前の「データ処理パイプライン」において、重要な情報が欠落してしまっていることに原因があるケースが大半です。
本記事では、モデル自体を複雑にすることなく、データの扱い方を工夫するだけで検出率を劇的に底上げするアプローチ「サブ領域サンプリング（Slicing）」について解説します。理論だけでなく、計算リソースの制約が厳しい環境での実装方法や、注意すべきポイントについて体系的に紐解いていきます。
なぜ監視カメラ映像の小物体検知は失敗するのか
まず、多くのプロジェクトで直面する「映像に映っているのに検知できない」という現象を、データの視点から論理的に分解します。AIモデルの性能不足を疑う前に、物理的なピクセル情報の欠落という現実を直視する必要があります。
リサイズによる情報消失のメカニズム
現在主流となっている物体検知モデル（YOLOやSSD、EfficientDetなど）は、入力画像のサイズが固定されている設計がほとんどです。一般的には640×640ピクセル、大きくても1280×1280ピクセル程度で学習されています。
最新のYOLOでは、従来必須だったNMS（Non-Maximum Suppression）を不要とする「One-to-One Head」の採用や、DFL（Distribution Focal Loss）の撤廃により、エッジデバイスでの推論速度が劇的に向上しています。しかし、アーキテクチャがどれほど進化し処理が高速化されても、入力サイズが固定である以上、物理的な情報の制約は変わりません。
ここで、一般的な監視カメラのスペックを想定します。現在の標準である4K解像度（3840×2160ピクセル）の映像を、そのまま640×640のモデルに入力した場合の挙動を論理的に考えてみます。
単純な計算になりますが、画像の面積は約30分の1以下に圧縮されます。これは、元の映像で「30×30ピクセル」程度の大きさで映っていた遠方の人物や小さな部品が、モデルに入力される時点ではわずか「5×5ピクセル」程度の情報の塊になってしまうことを意味します。
5×5ピクセル。つまり25個のドットだけです。この情報量で、それが「人」なのか「ただのノイズ」なのかを判別するのは、最新のAIにとっても至難の業です。人間がモニターを見て「あそこに人がいる」と分かるのは、高解像度のまま全体を見ているからです。しかし、AIモデルには、極端に解像度が低下した（リサイズされた）状態の画像しか渡されていないのです。
学習データと実運用データの解像度ギャップ
もう一つの課題は、学習データセットと実運用環境の間に存在するギャップです。
物体検知のベンチマークとして有名なCOCOデータセットでは、「小物体（Small Object）」は32×32ピクセル未満の領域を持つ物体と定義されています。しかし、一般的に公開されている学習済みモデルは、被写体が比較的大きく、明瞭に映っている画像（FlickrなどのWeb画像）を多く含んで学習されています。
一方で、監視カメラの映像はどうでしょうか。広角レンズで広い範囲を撮影するため、対象物が相対的に非常に小さくなります。さらに、カメラの設置位置が高いため、対象物を真上や斜め上から見下ろす形になり、特徴的なシルエットが見えにくくなることもあります。
この「ドメインギャップ（データの性質の違い）」に加え、前述のリサイズ処理による情報の喪失が重なることで、小物体検知の精度指標である mAP@0.5:0.95 small のスコアは、全体平均のmAPに比べて著しく低くなる傾向があります。テスト環境と実運用環境での精度乖離は、この要因によって引き起こされます。
モデルサイズを大きくしても解決しない理由
ここで強調しておきたいのは、「モデルのパラメータ数を増やしても、入力情報が潰れていれば意味がない」という事実です。
精度向上が課題となると、より大規模なモデルの採用が検討されることがよくあります。例えば、YOLOのモデルサイズをMediumからExtra Largeに変更するアプローチや、最新の「One-to-Many Head（高精度オプション）」を採用して精度向上を図るケースです。確かに、パラメータ数を増やしたり高精度なHeadオプションを選択したりすれば、より複雑な特徴を捉える能力は高まります。
しかし、入力画像の時点で特徴量（エッジやテクスチャ、形状）が消失していれば、高度なアーキテクチャであっても検知は困難です。エッジデプロイ時に推奨される「One-to-One Head」を使用して推論速度を優先する場合でも、結局は入力の解像度がボトルネックとなります。
したがって、小物体検知の課題解決においては、モデルの変更や後処理の調整よりも「いかに解像度を維持したままモデルに画像を渡すか」という前処理エンジニアリングの方が、はるかに高いROI（投資対効果）を生み出します。これは、AI導入プロジェクトを成功に導くための重要なポイントとなります。
サブ領域サンプリング（Slicing）の基本原理と安心設計
解像度を維持したまま推論を行う手法として有効なのが、「サブ領域サンプリング（Slicing）」、あるいは「タイリング」と呼ばれるアプローチです。概念自体はシンプルですが、実務に適用する際にはいくつかの定石を押さえておく必要があります。
画像を「意味のある単位」で分割するロジック
基本的な考え方は、高解像度の元画像を無理やりリサイズして縮小するのではなく、「モデルの入力サイズに合わせて切り刻む（スライスする）」ことです。
例えば、3840×2160の4K画像を、640×640のウィンドウでタイル状に切り出していくとします。こうすれば、切り出された画像内の物体は、元画像の解像度（ピクセル密度）を100%維持したままモデルに入力されます。先ほどの例で言えば、30×30ピクセルの人物は、モデルにとっても30×30ピクセルのまま認識されるわけです。これなら、特徴量が十分に保存されており、検知率は飛躍的に向上します。
この手法の最大の利点は、「既存の学習済みモデルをそのまま利用できる」という点にあります。高解像度画像専用の特殊なモデルをゼロから設計したり、膨大なコストをかけて再学習させたりする必要はありません。既存のYOLOv8やv10などのモデルを、再学習なし（推論のみ）で活用できるため、導入コストとリスクを最小限に抑えられます。これはプロジェクトマネジメントの観点からも、ROIを最大化する上で非常に重要なポイントとなります。
オーバーラップ率の黄金比
ただし、画像を単純に格子状に分割すると、新たな問題が発生します。「分割境界線上にいる物体」の問題です。
ちょうどハサミを入れるライン上に人物がいた場合、上半身と下半身に分断されてしまい、モデルはそれを「人」として認識できなくなります。これでは本末転倒です。
これを防ぐために、スライシング処理では必ず「オーバーラップ（のりしろ）」を設定します。隣り合うスライス画像同士を少しずつ重ねて切り出すのです。
一般的な傾向として、検知したい対象物の平均的なサイズの1.5倍〜2倍程度のピクセル数をオーバーラップ領域として確保することが推奨されます。実務においては、スライスサイズの20%〜25%程度をオーバーラップさせることが多く見られます。例えば、640pxのスライスなら128px程度の重複を持たせます。これにより、境界付近の物体も、どちらかのスライス画像には「完全な形」で含まれる可能性が高まり、見逃しを防ぐことができます。
SAHI（Slicing Aided Hyper Inference）等の既存手法との関係
この概念を体系化し、使いやすいオープンソースライブラリとして実装されたものに「SAHI（Slicing Aided Hyper Inference）」があり、広く知られている手法の一つです。
SAHIは非常に優れたツールで、導入のハードルを下げてくれます。しかし、実務で使用する際は、これを単なるブラックボックスとして使うのではなく、内部で行われている処理フローを理解しておくことが重要です。
監視カメラシステムのようなリアルタイム性が求められる環境では、SAHIのデフォルト設定では処理負荷が高くなるケースがあるためです。処理遅延による実用性の低下を避けるため、次章からはこの処理フローをパイプラインに最適化して組み込むための具体的な実装ステップを解説します。
実装ステップ1：スライシングと前処理のパイプライン
実際のデータ処理パイプラインを構築する際、最初のステップとなるのが「画像をどう切り出すか」というスライシングの設計です。この前処理における工夫が、システム全体のパフォーマンスと安定稼働を決定づけます。
元画像解像度に応じた動的なタイルサイズ決定
固定のサイズで切り出すアプローチもありますが、カメラの設置環境によって最適なスライスサイズは異なります。現場の状況に合わせた柔軟な設計が不可欠です。
例えば、カメラが非常に高い位置にあり、全体的に物体が米粒のように小さい場合は、スライスサイズを小さく（例えば320×320や416×416など）設定し、相対的に物体を大きく見せる処理が有効です。これにより、モデルへの入力サイズ（例えば640×640）に合わせてアップスケールされる効果が得られます。
逆に、ある程度近くを映している場合は、大きめのスライス（1024×1024など）にして、推論回数を減らす方が効率的です。運用時には、コードに値をハードコーディングするのではなく、設定ファイル（config.yamlなど）でカメラごとにスライスサイズとオーバーラップ率を柔軟に変更できるアーキテクチャにしておくことを推奨します。
メモリ溢れを防ぐバッチ処理の設計
4K画像を640×640、オーバーラップ20%でスライスすると、1フレームあたり数十枚のパッチ画像が生成されます。これを一度にGPUメモリに載せようとすると、VRAM容量を一瞬で圧迫し、プロセスが強制終了する原因となります。
一般的に「CUDA Out of Memory」として知られるエラーを防ぐため、最新の環境に合わせたメモリ管理と環境構築が重要です。NVIDIAの公式情報によると、最新バージョンであるCUDA 13.1（2025年12月リリース）環境下では、スレッドレベルよりも効率的な処理を可能にする「CUDA Tile」の導入が進んでおり、Pythonでの先行利用によって効率的なデータ処理の記述が容易になっています。また、Blackwellアーキテクチャへの対応強化など、生成AIや大規模処理に向けた最適化も進んでいます。
一方で注意が必要なのは、GTX 980（Compute Capability 5.2）などの古いGPUは最新のCUDAサポート対象外となっている点です。レガシー環境に依存した実装は予期せぬエラーの原因となるため、最新のアーキテクチャに対応できる設計へ移行することが求められます。
実用的な実装において推奨される環境構築の手順は、NVIDIA NGCコンテナを利用してCUDA 13.1.1環境（適切なディスプレイドライバやPython 3.11以上を要件とする）を月次で更新し、環境をクリーンに保つことです。その上で、生成されたスライス画像を適切なバッチサイズにまとめて推論器に送るキューイング機構を構築します。Pythonのジェネレータなどを活用してストリーム処理を行い、画像をメモリ上に展開しすぎないよう制御することが、エッジデバイスでもクラウドGPUでも安定稼働の要となります。
無駄な推論を省くための背景除去フィルタリング
推論効率を最大化する上で、非常に重要な最適化ポイントとなるのが背景のフィルタリングです。
監視カメラの映像では、空や壁、道路のアスファルトなど、「何も映っていない領域」が大半を占めるという課題は珍しくありません。すべてのスライス画像を律儀に推論にかけるのは、貴重な計算リソースの浪費につながります。
そこで、推論エンジンの手前に簡易的なフィルタリング（ゲートキーパー）を導入するアプローチが有効です。
- 分散値チェック: 切り出した画像の画素値の分散（Variance）を計算します。単色に近い壁や空などは分散値が極端に低くなる性質を利用し、閾値を設けてこれ以下の画像は推論せずにスキップします。
- 背景差分/動き検知: 前フレームとの差分を取り、動きがあった領域を含むスライスのみを推論対象に絞り込みます。
この工夫を取り入れることで、推論が必要なパッチ数を半分以下に減らせるケースも多く報告されています。「見る価値のある画像か？」を軽量な計算で事前に判断し、GPUによる重い推論処理を節約するアーキテクチャが、実践的なシステム構築における鍵となります。
実装ステップ2：推論結果の統合（マージ）と重複排除
スライスごとの推論が終わると、手元には「バラバラの画像に対する大量の検出結果」が残ります。これを元の4K画像上の座標に戻し、一つの整合性のある結果にまとめる必要があります。ここでの実装ミスは、誤検知（False Positive）の増加に直結します。
分割推論で発生する「バウンディングボックスの重複」問題
オーバーラップを設定しているため、境界付近にある物体は、隣り合う複数のスライス画像で重複して検知されます。そのまま統合すると、一人の人物に対して複数の枠（バウンディングボックス）が表示されてしまい、員数カウントなどの後続処理で大きな誤差を生みます。システム導入後の誤検知に関する課題の多くは、この現象に起因します。
これを解消するためには、以下の2段階の処理を確実に行う必要があります。
- 座標変換: 各スライスのローカル座標を、元画像のグローバル座標に変換する。
- 重複排除: 重なった枠を一つにまとめる。
グローバル座標への変換ロジック
これは単純な算数ですが、間違えやすいポイントでもあります。スライス画像 $i$ の左上原点が、元画像上の $(X_i, Y_i)$ にあるとします。スライス画像内で検知された物体の座標が $(x, y, w, h)$ だとすると、元画像上での座標は $(X_i + x, Y_i + y, w, h)$ となります。
この変換を全ての検出結果に対して行い、一つの巨大なリストにまとめます。この時点では、まだ重複だらけの状態です。
NMS（Non-Maximum Suppression）の最適化設定
重複排除には、通常の物体検知でも使われるNMS（Non-Maximum Suppression）アルゴリズムを使用します。ただし、スライシング特有の調整が必要です。
通常のYOLOのNMSは、同じ物体クラスの重複を消すためにIoU（Intersection over Union：重なり具合）の閾値を0.45〜0.6程度に設定します。しかし、スライシングのマージ処理では、「全く同じ物体が、わずかな座標ズレで複数回検知されている」という状況を扱います。
この場合、IoU閾値は比較的高め（例えば0.5〜0.7）に設定しつつ、「信頼度スコア（Confidence Score）」が高い方を優先して残すロジックを確実に動作させる必要があります。また、NMSの処理はPythonのループで書くと遅くなりやすいため、TorchVisionなどの高速なライブラリを使用するか、NumPyを使ったベクトル演算、あるいはC++での実装を検討すべき箇所でもあります。
処理速度と精度のトレードオフを制御する
精度向上と処理速度（FPS）の維持は、プロジェクトマネジメントにおいて必ず直面するトレードオフの課題です。サブ領域サンプリングは推論回数を増やすため、単純に実装すればFPSは確実に低下します。ここで必要になるのが、速度と精度のバランスを論理的に制御する「ハイブリッド戦略」です。
全領域スキャン vs 重要領域サンプリング
全てのフレームに対して全領域のスライシングを行う必要はありません。以下のような戦略を組み合わせることで、実用的な速度を維持できます。
全体推論＋部分詳細推論:
まず、元画像をリサイズした全体画像で1回推論を行います（通常のYOLOの使い方）。ここで「何かありそうだが確信度が低い」領域や、事前に指定した「重点監視エリア（入り口付近など）」だけをスライスして詳細に推論します。これなら推論回数の増加を最小限に抑えられます。時間的な間引き:
映像は30fpsで流れていても、小物体検知（スライシング処理）は5fps（6フレームに1回）だけ行い、その間のフレームはトラッキング（追跡）技術で補完するというアプローチです。監視カメラの対象物はそこまで高速移動しないことが多いため、この方法は非常に有効です。
推論レイテンシの許容範囲設定
システム要件定義の段階で、「検知までの遅延」をどこまで許容できるかを明確に定義しておくことも重要です。リアルタイム性が厳密に求められる（例：工場のライン制御）のか、数秒の遅延は許容される（例：防犯監視の通知）のかによって、スライスできる枚数の上限が決まります。
例えば、Jetson Orin NXのようなエッジデバイスでYOLOv8sを動かす場合、1回の推論に約15ms〜30msかかるとします。1フレームの処理時間を100ms以内（10fps）に抑えたいなら、スライス数は最大でも3〜4枚に制限する必要があります。この制約条件から逆算して、スライスサイズや重点領域を決定することが、システム設計における重要なポイントとなります。
導入に向けた技術選定と検証チェックリスト
最後に、プロジェクトへ導入する際の具体的なアクションについて解説します。車輪の再発明を避け、効率よく進めるための実践的なガイドです。
Pythonライブラリ選定（SAHI, OpenCVなど）
PoC（概念実証）段階であれば、前述のSAHI (Slicing Aided Hyper Inference) ライブラリを利用するのが最短ルートです。YOLOv5, v8, v10, Nasなどの主要モデルに対応しており、数行のコードでスライシング推論を試すことができます。まずはこれで効果測定を行いましょう。
しかし、製品化フェーズでさらなる高速化や特殊なパイプライン（DeepStreamやGStreamerとの連携など）が必要な場合は、OpenCVとONNX Runtimeを使って自前でスライシングと前処理クラスを実装することをお勧めします。SAHIは汎用的すぎるがゆえにオーバーヘッドがあるため、専用設計にすることで20〜30%の高速化が見込めます。
PoCで確認すべきデータ品質指標
導入効果を測定する際は、漫然と全体のmAPを見るのではなく、以下の指標に注目してください。
- mAP@0.5:0.95 small: COCO基準の「小物体」に対する精度。ここが改善されているかが最重要です。
- False Positive (FP) Rate: 誤検知の数。画像を細切れにすることで、壁のシミなどを誤って検知するリスクも増えます。ここが増加していないか監視が必要です。
- Inference Time per Frame: 前処理（スライス）、推論、後処理（マージ）を含めたトータルの処理時間。これが許容範囲内かをチェックします。
段階的導入のロードマップ
いきなり本番環境の全カメラに適用するのではなく、まずは「遠方の検知が必要な特定のカメラ」や「夜間の不審者検知」など、解像度が重要になるシーンに限定して導入を始めましょう。
データ処理パイプラインの変更は、モデルの変更よりもシステム全体への影響範囲が広くなります。しかし、一度堅牢なパイプライン（分割・推論・統合）を構築してしまえば、将来的にAIモデルがYOLOv11、v12と進化した際にも、その枠組みをそのまま使い続けることができます。これは長期的なシステム資産となります。
まとめ
監視カメラ映像における小物体検知の課題は、AIモデルの性能限界というよりも、入力データの解像度不足に起因するケースが大半です。モデルを巨大化させる前に、まずは「今ある高解像度データを捨てずに使う」ことを考えてみてください。
- リサイズによる情報損失を理解する: 4Kを640pxに縮小するのは、データを自ら捨てているのと同じです。
- スライシングで解決する: 画像を分割して推論し、後で統合するアプローチが有効です。再学習も不要です。
- パイプラインを最適化する: 必要な部分だけを推論し、計算リソースを守る工夫が実用化のカギです。
AI監視カメラの世界においては、精度は解像度に大きく依存します。ぜひ、今後のプロジェクトにおいて、このサブ領域サンプリングの導入を検討してみてください。これまで検知が困難だった対象物を捉えるための、強力なアプローチとなるはずです。
コメント