工場や施設の現場では、炎や煙、機械の異音、ガス漏れ、油漏れ、過熱 ― といった「危機の兆し」が、いつどこで起きるか分かりません。人が四六時中すべてを見張るのは現実的ではなく、かといってAIに丸投げすれば安心というものでもありません。
危機管理 認知技術スイートは、こうした現場の危機を 5つの専用モジュールで認識し、その結果を MCP（Model Context Protocol）経由でAIエージェント（当社 Luqua 等）へ渡す仕組みです。エージェントにとっての“感覚器”を、危機ごとに一つずつ、着実に増やしていく ― それがこのスイートの狙いです。
デモ映像
VISION ― AIエージェントに「危機を認識する力」を
いま当社が目指しているのは、AIエージェントが現実世界の危機を的確に認識し、自ら判断してアクションできるようにすることです。そのためには、エージェントの手前に「何が起きているか」を正しく捉える認識処理が要ります。
- 認識処理をモジュール化 ― 炎・異音・ガス・油漏れ・過熱。危機ごとに専用の認識器を実装し、それぞれ独立して育てます。
- MCPでエージェントへ接続 ― 各認識器の結果（アラームと、その根拠）をMCPツールとして公開。エージェントが呼び出して状況を理解します。
- 的確な判断とアクション ― エージェントは複数の危機認識を統合し、通報・停止・回避といった行動を選べます。
- FOS の一機能に ― 危機認識は、Forcesteed OS “FOS” の感覚器にあたります。機能を確実に、一つずつ増やしていきます。
FSRの方針 ― 「確実に使える技術」を積み上げる
AIエージェントの認識というと、つい LLM/VLM そのものをファインチューニングして解く方向に流れがちです。しかしそれだけに頼ると、学習コスト・再現性・説明性に課題が残り、中身がブラックボックスになりがちです。
当社の立場は明快です。「確実に使える技術」を積み上げること。
- 従来技術を大いに活用 ― 画像処理（CV）・信号処理・統計といった、実績のある手法を土台にします。
- 危機ごとに検証済みの認識器 ― それぞれの危機に、目的に合った認識器を実装します。
- 定量評価・単体テストで品質を担保 ― 「たぶん動く」ではなく、数値と自動テストで確かめてから出します。
- MCPで確実に接続 ― 認識結果を、エージェントが確実に取得できる形で公開します。
結果として、説明可能で監査できる危機認識、現場データで再学習・改善しやすい構成、そして FOS を着実に拡張できる土台が得られます。巨大モデル一本槍ではなく、堅実な技術の積み重ねでいく ― これがFSRの選択です。
アーキテクチャ ― 危機認識 → MCP → AIエージェント
スイート全体は、「危機認識」→「MCP」→「AIエージェント」という素直な3段構成です。
ポイントは、5つの認識器が同じ共通インターフェースに乗っていることです。入力・前処理・認識・発報・記録の“型”をそろえてあるので、新しい危機を足すときも、既存の危機を実センサーへ載せ替えるときも、同じ作法で拡張できます。
5つの危機認識
α版時点で、次の5つの危機認識が実装済みです。いずれも公開データセットで定量評価しています。
1. 炎・煙 検知
サーモ／可視カメラの映像から、火災の初期段階（炎・煙）を検出します。手法は物体検出の定番 Faster R-CNN（ResNet-50 FPN）。fire → ALARM / smoke → WARNING とクラス別に発報し、検出根拠（バウンディングボックスとスコア）をMCPへ提供します。
2. モーター異音 検知
マイクアレイで拾った音を log-mel スペクトログラムに変換し、GMM による異常検知にかけます。正常音の分布を学習し、そこから外れた音を異常として捉える方式なので、教師なしで運用を開始でき、現場への適応が容易です。クリップ単位のスコアが閾値を超えると ALARM/WARNING を出し、異常区間をスペクトログラム上に可視化します。
3. ガス 検知
化学センサーアレイ（16センサー × 8特徴）の信号から、ガス種の分類と濃度の回帰（ppm）を同時に行います。ppm 閾値（許容濃度に相当）で ALARM/WARNING を出し、確信度の低い検出は発報を抑制して誤報を減らします。センサーは経年で特性がずれる（ドリフトする）ため、36ヶ月分のドリフトを定量評価し、再校正の要否を判断できるようにしています。
4. 油漏れ 検知
可視カメラの映像から、床面や設備の油漏れ・油こぼれを検出します。手法は Faster R-CNN（油・水・その他の3クラス）。oil → ALARM / water → WARNING と区別して発報し、発報したフレームは後から確認・再学習に回せるよう記録しておきます。
5. 過熱・温度異常 検知
放射温度計の温度時系列から、過熱・異常な降下・挙動変化を検出します。時刻別の正常プロファイル（時間帯ごとの平常値）に対し、EWMA 残差の z スコアで外れ具合を測る統計手法です。統計スコアと絶対温度閾値の2系統でアラームを出し、異常区間をチャート上に注記します。軽量なので、22,695点をCPUで約1.3秒とすばやくスコアリングできます。
α版の稼働状況 ― 5技術すべてが「連続監視アプリ」として動く
現在、上記の5技術はすべて連続監視アプリケーションとして稼働しています。入力データを順に流し込み、認識 → 発報 → イベント記録までが一連で回る状態です。
すべての認識器は同じ共通インターフェースに乗っています ― センサー入力を受け取る部分を差し替えるだけで、評価用データのリプレイから実機センサーへ載せ替えられる設計です。品質は単体テストで担保しており、5技術あわせて 計105件のテストが全てPASSしています。
| 危機認識 | 稼働の流れ | 単体テスト |
|---|---|---|
| 炎・煙 | 画像リプレイ → 検出 → 発報 → イベント記録 | 13件 PASS |
| モーター異音 | 音リプレイ → GMMスコア → 発報 | 14件 PASS |
| ガス | バッチリプレイ → 種別・濃度 → 発報 | 23件 PASS |
| 油漏れ | 画像リプレイ → 検出 → 発報 | 24件 PASS |
| 過熱 | 温度リプレイ → 逐次スコア → 発報 | 31件 PASS |
「動いたはず」ではなく、動くことをテストで確かめてある ― α版とはいえ、ここは崩さずに積み上げています。
ロードマップ ― β版へ、確実に
次のステップは、β版の骨格づくりと現場適応、そしてプラットフォーム統合です。
- 直近（β版の骨格）
- 5つの認識器を MCP サーバとしてツール公開
- 発報抑制（ヒステリシス・連続N点確認）で誤報をさらに低減
- 常時稼働（systemd）と通知連携
- 現場適応
- 実センサードライバの実装
- 現場データでの再学習（ドメイン適応）
- ガスのドリフト再校正の自動化
- プラットフォーム
- AIエージェント（Luqua）との統合デモ
- 複数の危機を統合した判断・アクション選択
- FOS への機能追加を継続
方針は一貫しています ― LLM/VLM のファインチューニングだけに依存せず、従来技術も大いに活用して、「確実に使える危機認識」を FOS へ積み上げる。
まとめ
- 課題 ― 現場の危機（炎・煙／異音／ガス／油漏れ／過熱）は、人がすべて見張るのも、AIに丸投げするのも難しい。
- 解 ― 危機ごとに専用の認識器を実装し、MCPでAIエージェントへ接続。エージェントの“感覚器”にする。
- 方針 ― 巨大モデル頼みにせず、画像処理・信号処理・統計という実績ある技術を、定量評価と単体テストで固めて積み上げる。
- 現状 ― 全5技術がα版として連続監視アプリで稼働し、単体テスト計105件が全PASS。
危機管理 認知技術スイートは、AIエージェントに「危機を認識する力」を、確実に使える技術で一つずつ与えていく取り組みです。デモやご相談を承っています。