目次
  1. 「カメラ何台まで処理できますか」と聞く前に
  2. 見込み8台、実測4台
  3. 疑われたのは推論のほうでした
  4. 詰まっていたのは、渡すところでした
  5. 数字が表で出ています
  6. AIチーム側にも手を入れています
  7. チップもモデルも変えていません
  8. 提案を受けたときに確認すること
  9. 思い込みの向きが、探す場所を決めます

「カメラ何台まで処理できますか」と聞く前に

現場の端末で映像をAI処理する製品やシステムを検討していて、性能の見積もりをどう読むか迷っている方に向けて書いています。

先に結論を書きます。部品ごとのベンチマークを足しても、その台数は出ません。

見込み8台、実測4台

セーフィーが2026年8月27日に、自社製品の性能改善記を公開しました(セーフィー テックブログ)。

対象はSafie Trail Station AI。店舗などに設置した多数のネットワークカメラの映像を本体のHDDへ記録し、そこにAI処理用のアクセラレーターチップを足して、指定エリアへの立ち入り検知や通過人数のカウントをエッジで処理する製品です。

重要な目標として置かれたのは「カメラ何台分の映像をAI処理できるか」でした。

立ち上げ当初、推論モデルの選定とアクセラレーターのベンチマークから、およそ8台分という見込みが立ちます。これなら製品として十分だ、として開発が進みました。

ところが終盤、システムとして組み上げて全体の使用率を測り始めたところ、出ていたのは4台分程度でした。

疑われたのは推論のほうでした

まず議論に上ったのは、推論モデルの最適化と、画像の前処理におけるリサイズ処理の重さだったと書かれています。

自然な発想です。AIの性能が出ないなら、AIを疑う。

詰まっていたのは、渡すところでした

筆者が着目したのは別の可能性でした。前職で携帯電話向けの画像処理システムを開発した経験から、画像データを各処理段階へ受け渡すだけでも想像以上のコストがかかるという感覚を持っていたためです。

そこで既存のコードを1行ずつ追い、その処理が何のために何をどう扱っているかを逐一確認していきます。記事は「極めて泥臭い作業でした」と書いています。

浮かび上がった改善点は3つでした。

映像がAIへ届くまでに通る道 改善前 デコード → メモリへ保存 → コピー → ソケットで送受信 → 形式を変換 → 推論 100 改善後 デコード → 共有メモリへ直接 → 推論 62
推論そのものは変えていません。減らしたのは、そこへ届くまでの手数です。数字は改善前を100とした比率です。

1つ目は不要なメモリコピーの削除です。映像をデコードした結果を一度メモリ領域へ保存し、それをあらためてプロセス間通信用のソケットへコピーしていました。デコード結果を直接渡せば、このコピーは要りません。

2つ目はプロセス間通信の方式です。ソケットで送受信するのをやめ、共有メモリに切り替えて、それぞれのプロセスが同じ領域を直接読み書きするようにしました。

3つ目は画像フォーマットの変換除去です。AI側が求めるNV12と、デコーダーが出力するYUV420Pが違っていたため、内部で変換していました。この2つは同じ情報のメモリ上の配置が違うだけで、どのみち推論の前にRGBへ変換していると推察されたため、変換自体を省けると判断しています。

数字が表で出ています

改善前を100とした比率が公開されています。

データ転送方法 従来実装 コピー削減 フォーマット変更
ソケット 100 77 未測定
共有メモリ 88 70 62

プラットフォーム部分の処理コストは100から62へ。AIチーム担当部分の改善と合わせ、製品として8台分という当初の目標を達成しています。

AIチーム側にも手を入れています

ここは実務的で、読み飛ばしたくない部分です。

共有メモリへの切り替えと、フォーマットの統一は、映像を受け取るAIアプリケーション側の実装にも変更が必要でした。プラットフォーム側の都合だけでは終わりません。

そこで課題と実現したいことを説明し、AI機能を開発しているチームに協力を仰いでいます。記事は、この2つのチームが同じ目標に向かえたことが改善の大きな要因だったと書いています。

性能の問題が、組織の担当境界をまたいだところに座っていた、という話です。

チップもモデルも変えていません

2倍にした手段が、この記事の要点です。

アクセラレーターは同じ。推論モデルも同じ。変えたのは、映像がそこへ届くまでの経路だけです。

エッジAIの選定をチップ選びから始めない理由は以前書きました。今回はその続きにあたります。選び終えた後にも、同じくらい台数を動かす要素が残っています。

現場メモ

私たちが現場のシステムで性能の相談を受けるとき、最初に見るのは処理そのものではなく、データがどこを何回通っているかです。ログの出力、シリアライズ、プロセスをまたぐ受け渡し。1回あたりは小さくても、フレーム単位で回ると積み上がります。

見積もりの段階では、この部分を数えないまま台数を出してしまいがちです。部品の性能表は手に入るのに、つなぎの部分の実測は自分で作るしかないからです。

なので、性能が要件になる案件では、早い段階で通しの測定だけをやる工程を分けて置きます。作り込む前に半分だと分かれば、設計を変える余地が残ります。組み上がってから分かると、直せる場所が減っています。

提案を受けたときに確認すること

エッジAIの処理台数を示されたときの4つの質問

  • その台数はどう測りましたか。部品ごとのベンチマークか、通しで組んだ状態か

  • 通しで測る工程はいつ入りますか。開発終盤ではなく、設計を変えられる時期にありますか

  • データはAIへ届くまでに何回コピーされますか。プロセスをまたぐ回数と方式が決まっていますか

  • 入出力の形式は揃っていますか。途中に変換が入るなら、それは省けないものですか

    エッジAI製品の選定、システム開発の提案レビューにそのまま転記して使えます

思い込みの向きが、探す場所を決めます

記事の結びは「AIの性能改善=モデルやアクセラレーターの最適化」と思い込みすぎないこと、と書かれています。

これは測定の話でもあります。AIを疑っている間は、AIしか測りません。 一歩引いてシステム全体をデータの流れとして眺めたから、別の場所が見えた。

倍率や台数の数字を見たら、何を測った数字かを先に聞く。この連載で繰り返し書いていることが、性能の見積もりでもそのまま当てはまります。

現場の端末でどこまで処理し、どこから既存システムへ返すかを整理する段階でしたら、お問い合わせからご相談ください。通しの測定を設計に組み込むところからご一緒します。


出典

開発のご相談はこちらAIネイティブ開発支援を見る