発見のあとに何が起きるのか — AIが代わりに見る現場
2026-08-07
管制室にモニターが十六あります。人の目は二つです。
この算数がCCTVの古い限界です。カメラは増え続けたのに見る人の数はそのままで、だからほとんどのCCTVは事故を防ぐ装置でなく事故のあとに見返す記録装置になりました。何かが間違っているという事実は、たいてい映像でなく叫び声や電話で先に伝わります。
AI映像分析がこの問題を解くという話はもう新しくありません。もっと重要な問いはその先にあります。AIがヘルメットを着用していない作業者を発見したとします。で、何が起きますか。
アラート一覧に一行積むだけで終わるのなら、その一覧は一週間で誰も見なくなります。「ORBRO OSの話」今回はAIアプリ四つを扱いますが、半分は発見のあとについての話です。
I. まず、人が見る画面 — Multi Cam
AIの話の前に人の話をしておきます。
Multi Camは登録されたカメラ映像を一つの画面に集めて見せるビューワです。最大12画面を同時に出し、必要なカメラを押して拡大し、オンラインのものだけ選んで見られます。映像はHLS方式でストリームして遅延と途切れを減らしています。
設定機能がないことがむしろこのアプリの性格を表しています。カメラを登録し設定するのは機器管理アプリの仕事で、Multi Camは見ることだけをします。イベントが発生したときに周边カメラを一緒に広げて状況を把握する用途です。
そして冒頭の算数は依然として有効です。画面をどんなにうまく並べても、十二つを同時に見つめられる人はいません。Multi Camは必要ですが十分ではありません。
II. AIが代わりに見るもの — AI Event
AI Eventはカメラ映像から決められた状況を見つけ出します。現在検知する種類は五つです。
- 人の転倒 — 作業者が倒れて一定時間動かない状態
- 火災 — 炎・煙の発生
- ヘルメット未着用 — 安全帽をかぶっていない人
- 危険区域進入 — 指定したエリアに人が入る
- 衝突検知 — 人と設備、設備と設備が危険に接近
検知されたイベントは時刻、カメラ、種類、そして信頼度と共に記録されます。信頼度が一緒に残ることが実務で重要です。画面には「ヘルメット未着用検知 (95%)」のように表示され、この数字があれば確実なものから先に処理する運用ができます。検知瞬間のスナップショットと映像クリップも保存されるので、あとで人が目で確かめて判断できます。
規模感のために実際の運用数値を一つ挙げると、カメラ六台を運用するある産業現場で一日に290件のイベントが検知されます。人が十六の画面を見つめて捕らえられる数ではありません。同時に、290件を全部人に通知したらそれも管制ではありません。だから次の話が必要です。
III. タグを付けられないもの — AI RTLSとLPR
AIカメラは状況だけを見るのではありません。位置も見ます。
AI RTLSはカメラ映像の座標と図面の座標を合わせておくアプリです。映像内の基準点と図面上の同じ地点を対応させておけば、カメラが捕らえた人と車が図面上の正しい位置に表示されます。追跡する領域は映像の上に多角形で描いて指定し、その外のオブジェクトは追跡対象から除外されます。
このアプリが埋める空白があります。位置測位はタグを付けられる対象にしか適用できません。社員には社員証を渡せますが来訪者には難しい、自社のフォークリフトにはタグを付けられますが協力会社のトラックには付けられません。AI RTLSはタグのない対象をカメラで追跡し、同じ地図の上に乗せます。 タグで捕らえた位置とカメラで捕らえた位置が一つの画面で出会う構造です。
LPRは車のナンバープレートを読みます。登録したカメラが通過する車の番号を認識して記録に残し、いま何台駐車しているかも見せます。人の入退室を扱うアプリが別にあるので、両方を使えば正門を通ったものが人であれ車であれ一つの記録体系に集まります。
一つ正直に申し上げておくことがあります。ナンバー認識率はカメラの角度と照明、プレートの状態に大きく左右されます。 設置位置を間違えれば、どんなに良いモデルを使っても読めません。ソフトウェアより設置設計が結果を多く決める領域で、この部分は導入前に現場で確認しておくほうが安全です。
IV. 発見のあとに何が起きるのか
ここで冒頭の問いに戻ります。AIが何かを発見しました。その次は。
ORBRO OSでは三つの分岐が同時に起きます。
第一に、現場が即時に反応します。 イベント種類ごとに案内文句を登録しておけば、検知即時に現場スビーカーから音声で放送されます。ヘルメット未着用なら「ヘルメットを着用してください」、火災なら「火災が発生しました。避難してください」がその場で流れます。警報灯をつなげておけば、色と点滅パターン、ブザー音、動作時間までイベント別に違う設定にできます。
管制室を経由しないところが核心です。ヘルメットをかぶっていない作業者が3秒後に放送を聞くのと、管制室の担当者がアラートを見て無線を入れるのとの間には数分の差があります。安全において数分は長い時間です。
第二に、条件等級でふるいにかけられます。 先に述べた一日290件を全て緊急として扱えば何も緊急でなくなります。ORBRO OSの条件は緊急・警告・注意・関心・正常の五段階に分かれ、等級に応じて通知対象と処理方法が変わります。
第三に、標準対応手順が開きます。 これが最も重要な部分です。
V. マニュアルを探さなくてもよくするアプリ — SOP
非常対応マニュアルはたいてい文書として存在します。キャビネットにあるか共有フォルダにあって、いざ状況が起きると誰も探しません。
SOPはそのマニュアルを画面に移したアプリです。条件が成立すれば担当グループに対応手順が自動で開き、担当者はステップを一つずつ踏んでいきます。実際に運用中の危険区域進入対応手順は六ステップで構成されています。
- 近くのカメラ確認 — 画面に当該区域のカメラが自動で出ます
- 進入者の身元確認 — 選択式で選ぶ
- 関係者へメール・メッセージ送信 — 登録された担当者に状況を伝達
- 進入時刻の記録 — 日付と時間を入力
- 負儀者の有無確認 — 記述式入力
- 状況終了報告 — 記述式入力
ステップは選択式、記述式、日付・時刻入力、メッセージ送信、案内画像、カメラ確認の六種を組み合わせて作ります。現場ごとに手順が違うので順序も自由に変えられます。
この構造の価値は二つのところから出てきます。一つはうろたえた人が次に何をすればよいか分からずに止まることがないこと、もう一つは対応自体が記録に残ることです。誰がいつどのステップを踏んだか、どれくらいで終了したかが自動で積まります。事故報告書をあとから記憶で再構成する必要がありません。
VI. 映像は現場の外に出ない
最後に、これらすべてがどこで計算されるのかを指摘しておきます。
ORBRO OSの映像分析は現場に設置したエッジ機器で処理されます。カメラ映像が外部クラウドに上がって分析され、結果だけ戻ってくる方式ではありません。理由は三つです。
帯域 — カメラ複数台の映像を常に外に上げるのは回線コストと安定性の両方で負担です。遅延 — 危険を検知して放送が出るまでの時間は短ければ短いほうがよい。そしてプライバシー — 作業者の顔と動線が入った映像は最もセンシティブなデータに属します。公共機関と製造現場ではこのデータを外へ出すこと自体が許されないケースが多いです。
映像は現場の中で分析され、外に出るのは「11時48分に3ラインでヘルメット未着用が検知された」という事実だけです。
おわりに
管制室のモニターは十六で人の目は二つという算数は依然変わっていません。変わったのは、その十六を人が全部見なければならないという前提です。
AIが代わりに見るところまではもういろんなところがやっています。差が生まれるのはその先です。発見が放送に、放送が手順に、手順が記録につながる輪がつながっているか。この輪が切れたシステムでAIはアラートを作る機械にすぎず、アラートは無視されるために積まります。
目につきにくい七つのアプリの話は別にあります。誰も自慢しませんが、なければここまで紹介した十五つが全部止まるものたちです。
現場のカメラでどんなイベントを捕らえられるか気になる方は、ORBROまでお問い合わせください。