安全管理AIを工場へ｜AIカメラRFP・受入ガイド

工場の安全管理にAIを使うとき、比較すべきものは「AIカメラの認識率」だけではありません。危険な状況を定義し、カメラで観測し、判断を通知し、人や設備が応答し、復旧までの証跡を残せるかが導入成否を分けます。本稿ではタイの工場を想定し、RFP、PoC、FAT/SAT、PDPA対応、90日展開を、発注・受入できる形に整理します。

結論：安全管理AIは「検知から対応までの再現可能なループ」で発注する

最初に結論です。工場の安全管理AIを導入するRFPに、「AIカメラで危険を自動検知する」「高精度なモデルを提供する」とだけ書いてはいけません。発注すべき成果は、対象となる危険シナリオ、撮像範囲、モデルの判断、通知経路、現場の応答、復旧、監査証跡、プライバシー境界が一つの運用ループとして定義され、同じ試験を繰り返して合否を再現できることです。

一般的なAIカメラは観測とエスカレーションの層です。それだけで安全規格に適合した保護機能になるわけではありません。物理的な歩車分離、防護柵、インターロック、ライトカーテン、安全PLC、教育、標識、保護具を置き換えるものでもありません。自動停止を含める場合は、要求されるリスク低減に応じて、安全機能全体、構成部品、故障時の挙動、検証、適用規格を有資格者が設計・確認する必要があります。コンピュータビジョンのスコアを、そのまま安全回路の信号として扱ってはいけません。

したがってベンダー比較は、デモ映像の印象や一つのaccuracy値ではなく、次の問いに答える証跡で行います。

発注時の問い	受入時に必要な証跡
何を危険とみなすか	現場承認済みのシナリオ、対象外、優先度、危険源との対応
どこまで見えるか	カメラごとの有効範囲、死角、昼夜・遮蔽・汚れの試験結果
どう判断するか	シナリオ別のprecision/recall、誤警報、遅延、モデル版
誰へどう伝えるか	通知経路、到達確認、代替経路、acknowledgementログ
誰が何をするか	現場手順、応答責任、目標時間、エスカレーション
障害後にどう戻すか	ネットワーク断・カメラ遮蔽・モデルrollbackの復旧記録
説明できるか	イベント、判断、通知、応答、設定変更を結ぶ監査ログ
人をどう守るか	目的限定、告知、保持期間、アクセス、委託・越境管理

「安全管理 AI 工場」が意味する範囲を先に固定する

「安全管理 AI 工場」という検索語には、事故予防、監視省力化、フォークリフト対策、PPE確認、異常の早期発見など複数の期待が含まれます。しかし、用途を曖昧にしたまま「工場全体をAIで安全にする」と始めると、学習データ、カメラ配置、通知先、法的根拠、受入条件がすべて揺れます。最初のPoCは、一つか二つの危険シナリオに絞るべきです。

実務で検討しやすい用途には、次があります。

フォークリフト経路へ歩行者が進入した、または両者が定義距離内へ接近したことの検知
ロボットセル、荷役区域、高所作業区域など、定義した危険エリアへの侵入検知
ヘルメット、反射ベストなど、現場ルールで定めたPPEの着用状態の補助確認
転倒・人が倒れている可能性の通知。ただし姿勢だけで負傷を断定しない
煙・熱の異常兆候の補助監視。ただし、用途に適した煙・熱センサー等を組み合わせ、映像だけを火災検知器の代替にしない

同じ「フォークリフト歩行者検知」でも、目的は分けます。近接イベントを記録してレイアウト改善に使うのか、現場リーダーへ注意喚起するのか、運転者へ警告するのか、設備側の制御へ連携するのかで、必要な信頼性と責任が違います。「あとで分析する」用途と「今すぐ行動を変える」用途を同じ受入基準にしてはいけません。

一方、導入目的から明示的に外すべきものがあります。安全目的で取得した映像から、作業速度、休憩、感情、集中度、個人ランキングを密かに作ることです。目的が拡張されると、労使の信頼、データ保護、モデル妥当性が崩れます。ILOはAIによる侵襲的な監視が心理社会的リスク、プライバシー、自律性に影響し得ると注意を促しています。安全監視を生産性スコアへ転用しないことを、契約、権限、画面、ログ、変更承認にまで反映します。

EU域内でも事業を行う企業は、EU AI Actの適用評価も必要です。同法Article 5(1)(f)は、職場での感情認識について医療または安全上の理由を除き禁止を定めています。これはタイ法ではありません。また「安全」と名付ければ自動的に例外になるわけでもありません。EU拠点やEU向け共通基盤へ展開する場合は、現地の法務・DPOと用途を確認してください。

AIの位置を管理策の優先順位に置き直す

ISOの労働安全衛生解説が示す管理策の優先順位は、除去、代替、工学的対策、管理的対策、PPEの順です。まず危険源をなくせないか、より危険の少ない工程へ置き換えられないか、歩車分離、防護柵、速度制限、インターロックなどの工学的対策を取れないかを検討します。AIカメラは、残留リスクを可視化し、警告、調査、改善につなげる補完手段として位置付けるのが基本です。

たとえばフォークリフトと歩行者が交差する場所なら、最初の問いは「AIで近接を見つけられるか」ではありません。動線を分離できるか、一方通行にできるか、交差をなくせるか、柵やゲートを置けるか、速度と視界を改善できるかです。OSHAのpowered industrial truck向け資料も、可能な場合の歩車分離、視界、警告、安全な離隔を重視しています。これは危険管理の参考であり、タイ法として引用するものではありません。

AIの有効な役割は、固定対策の抜けや運用変化を発見することです。たとえば、扉が開いたままになる時間帯、仮置き品で通路が狭くなる場所、請負作業員が異なる動線を取る日、夜勤で照明条件が変わる時間帯をイベントとして集計できます。EHSが現場観察と照合し、物理対策や標準作業を改善するPDCAに使います。

通常の画像解析と安全機能を区別する

通常の画像解析システムは、カメラ、汎用ネットワーク、edge computer、AIモデル、message broker、dashboardなどで構成されることが多く、単一故障、遅延、処理停止、設定変更に対して安全側へ移る保証を持つとは限りません。画面に赤枠を出せることは、安全機能としての故障検出、診断範囲、冗長性、確定した応答時間を証明しません。

もしAIイベントから機械停止へ連携したいなら、リスクアセスメントからrequired safety functionを定義し、安全関連部のarchitecture、performance levelやsafety integrityに関する要求、検証方法を専門家が決めます。AI側と安全PLCの間にinterfaceを設ける場合も、そのinterfaceで何が失われるか、通信断時にどうするか、AIの不確実なscoreをどう扱うかを設計します。この記事は個別設備の安全認証を代替するものではありません。

ISO 45001はリスクベースの労働安全衛生management systemとPDCAを支える枠組みです。ISO 45001:2018は2024年のreviewでcurrentと確認されましたが、後継版が予定されています。未確認の「2026年版が発行済み」とは扱わず、契約時点の最新版と移行条件を公式情報で確認します。

AIカメラから応答・復旧までのアーキテクチャ

図の主経路は、CAMERA → EDGE INFERENCE → EVENT GATEWAY → ALERT ROUTER → HUMAN RESPONSEです。EVENT GATEWAYとALERT ROUTERからAUDIT LOGへ記録します。SAFETY PLCは別枠で、接続する場合もENGINEERED INTERFACEという破線を介し、「AI SCOREそのものではない」ことを示します。

CAMERAは映像を取得しますが、画角、露出、frame rate、時刻、健康状態も管理対象です。EDGE INFERENCEは対象物や関係を推定し、model ID、version、confidence、bounding region、event timeを付けます。EVENT GATEWAYは、単一frameの揺れをそのまま警報にせず、区域、継続時間、方向、再通知抑制、設備状態などのルールと結び、業務イベントへ変換します。

ALERT ROUTERは重要度、時間帯、区域、担当shiftに応じて、andon、mobile端末、control room、現場leaderなどへ通知します。一つのchat通知だけに依存せず、配信失敗、未確認、担当者不在のescalationを持ちます。HUMAN RESPONSEでは、誰が映像を確認し、現場へ連絡し、作業を止め、救護や隔離を行い、誤警報を分類し、再開を承認するかをrunbookにします。

AUDIT LOGは、単なる動画archiveではありません。元イベント、camera/model/rule version、通知先、delivery result、acknowledgement、実行した処置、再開承認を同じcorrelation IDで結びます。個人情報を必要以上に残さず、監査に必要なmetadataと映像clipの保持を分けられる設計が望まれます。

障害を正常系の外へ追い出さない

工場ではnetwork loss、camera obstruction、lens contamination、edge deviceのoverheat、clock drift、storage full、certificate expiryが起こります。監視システム自身が見えなくなったとき、「イベントがない」のか「観測できない」のかを区別できなければ、安全上の沈黙になります。

各cameraにはheartbeatとlast good frameを持たせ、映像の凍結、黒画面、blur、視野の移動を検出します。edgeからgatewayへのqueueは、offline時に保持できる範囲とoverflow時の扱いを定義します。リアルタイム警告が停止したら、現場へdegraded modeを表示し、追加の巡回、区域閉鎖など代替手段へ切り替える条件を決めます。復旧時は古いeventを現在の緊急通知として大量配信せず、historical evidenceとして再同期する規則が必要です。

カメラ配置とデータ準備：モデルより先に観測可能性を確認する

AI カメラ工場のPoCで見落とされやすいのは、学習モデルより撮像条件です。同じ交差点でも、昼夜、雨天時の反射、搬入口の逆光、床面の照り返し、振動、レンズ汚れ、積荷による遮蔽で見え方が変わります。設置前にhazard mapとcamera coverage mapを重ね、「危険が起きる場所」と「判別に必要な特徴が見える場所」が一致するかを確認します。

撮像要因	確認する内容	試験への反映
照明・逆光	昼夜、点灯切替、溶接光、搬入口、影	shift別scenario replay
遮蔽	pallet、rack、柱、車体、複数人の重なり	部分遮蔽と完全遮蔽を分ける
汚れ・水滴	粉塵、油、結露、清掃周期	徐々に劣化する画像とblocked test
振動・画角ずれ	設備振動、保全後の向き、zoom変更	baselineとの差と再校正手順
服装の差	制服、PPEの色、請負業者、visitor	group別に結果を確認
車両の差	forklift型式、積荷、速度、方向	実運用の組合せをtest pack化
network	帯域、packet loss、offline、時刻同期	latencyとevidence欠損を測る

データ収集では、「人」「フォークリフト」の画像枚数だけを数えません。危険シナリオの単位で、接近、離反、境界沿い、停止中、荷物で隠れる、複数対象が交差する、区域外を通るといったpositive/negative例をそろえます。何を正解とするか曖昧なframeは、無理に一人のannotatorへ決めさせず、EHSと現場責任者が判定規則を作ります。

少数groupだけ性能が落ちていないかも確認します。制服の色、体格、車椅子利用、雨具、請負業者のPPEなどで検知差が出れば、安全上の不均衡です。ただし、不要な属性推定や顔認識を追加する理由にはしません。目的に必要なobjectと状態だけを扱い、可能ならedgeで処理し、常時動画を外部cloudへ送らない構成を比較します。

受入指標：「accuracy」を複数の運用指標へ分解する

accuracyは、正常状態が大半を占めるデータでは高く見えます。工場の危険イベントが稀なら、すべてを「危険なし」と答えるモデルでも数字だけは良くなる可能性があります。受入ではscenario別confusion matrixを作り、少なくともprecision、recall、false alarms per camera-hour、latency、coverage、availability、evidence completenessを分けます。

Recall：実際に危険シナリオが成立したtestのうち、検知できた割合。見逃しに注目する
Precision：危険として出したeventのうち、正しかった割合。警報疲れに注目する
False alarms per camera-hour：camera稼働時間当たりの誤警報件数。現場負荷を比較しやすい
Detection latency：シナリオ成立からevent生成まで。平均だけでなくp95/p99を見る
Alert-delivery latency：event生成から通知到達まで。AI処理時間と通信時間を分離する
Coverage / blind-zone rate：対象hazard areaのうち有効に観測・判定できる範囲と死角
Availability：観測、推論、routingが有効だった時間。計画停止と障害を区別する
Evidence completeness：event、clip、model/rule version、delivery、responseが揃う割合

閾値はこの記事から一律に提示できません。hazard severity、接近速度、現場の代替策、camera数、応答手順により異なるためです。RFPではvendorに「業界標準accuracy」を約束させるのではなく、site-specific risk assessmentから受入閾値を決め、試験母集団とconfidence intervalの扱いを合意します。

project exampleとしての受入ゲート

以下は構造を示すproject exampleであり、普遍的な合格値ではありません。

EHSがhazardごとにseverity、exposure、回避可能性、既存controlを記録する。
各scenarioをday/night、正常/遮蔽、single/multiple objectなどに分ける。
期待event、期待通知先、期待response、必要evidenceを事前に固定する。
vendorがtest setから独立したデータで実行し、confusion matrixとlatency percentileを提出する。
重大scenarioでは見逃しを中心に評価し、低重大度scenarioではfalse alarmによる運用崩壊も評価する。
一つでもcritical negative testが失敗すれば、平均点で相殺せず是正・再試験する。

モデル更新後は同じgolden test packを再実行します。overall metricが改善しても、夜勤、特定camera、請負業者の服装でregressionがあれば本番へ上げません。productionでは入力画像の明るさ、blur、object size、event rateなどを監視し、performance driftの兆候を人がreviewします。ground truthのない現場値だけで「精度が維持された」と断定しないことも重要です。

RFP成果物と責任分界を明文化する

安全監視AIは、camera vendor、AI vendor、network/infrastructure、system integrator、EHS、IT/OT、法務/DPO、現場運用がまたがります。「AIはvendor、データはcustomer」の二分では、境界障害が漏れます。RFPでは成果物とRACIを同じ表で要求します。

RFP成果物	最低限含める内容	主なowner / approver
Hazard & use-case specification	対象危険、対象外、優先度、既存control、応答	EHS / Operations
Coverage design	camera位置、画角、死角、照明、保全access	Vendor / EHS
Data specification	収集範囲、annotation規則、品質、代表性、削除	Vendor / DPO・EHS
Model card & release note	用途、制約、test結果、version、既知failure	AI vendor / EHS
Event & interface specification	schema、時刻、ID、retry、security、PLC境界	IT/OT・Integrator
Alert and response runbook	routing、acknowledgement、escalation、復旧	Operations / EHS
FAT/SAT test pack	positive/negative、期待結果、evidence、再試験	Vendor / Customer
Privacy and security package	lawful basis検討、notice、retention、access、契約	DPO・Legal / IT security
Operations package	health monitoring、cleaning、backup、rollback、drift	Vendor / IT/OT
Training and change record	operator、supervisor、maintenance、worker説明	Operations / HR・EHS

works councilやworker representativesが存在する組織では、用途設計と変更管理へ早期に参加してもらいます。法令上の手続だけでなく、誤警報への異議申立て、映像閲覧、個人への不利益利用をどう防ぐかを現場の言葉で確認できます。ILOのAI・digitalizationとOSHに関する報告も、smart monitoringの予防可能性と同時に、新たなriskへのproactive/adaptiveな管理とworker participationの必要性を示しています。

契約では、modelやcloud serviceのsubprocessor、データ所在、security incident通知、脆弱性対応、support時間、export形式、契約終了時のデータ返却・削除を確認します。vendor lock-inを避けるには、event log、configuration、annotation guideline、test pack、model release historyをmachine-readableな形で引き渡せることが重要です。

既製品で足りない場合の要件整理や開発体制は、タイでのAI開発外注ガイドも参照してください。なお、製品欠陥を判定する画像検査は安全監視とは異なる用途です。AI外観検査の導入ガイドでは、検査対象、ground truth、工程連携の設計を別に解説しています。

PoC・FAT・SATはnegative testまで含める

PoCは、きれいなdemoで物体を囲めるかを見る場ではありません。現場条件で仮説が成立するか、失敗したとき何が見えるか、運用負荷が許容できるかを調べます。FATは供給者の管理環境で、固定したversionとtest dataを使い、機能、interface、failure handlingを再現します。SATは本番のcamera、照明、network、通知端末、担当者、shiftで端から端まで受け入れます。

図のacceptance matrixは、DAY、NIGHT、OCCLUSION、NETWORK LOSS、CAMERA BLOCKEDを行に、DETECT、ALERT、RESPOND、EVIDENCEを列に置き、各cellをPASS/FAILで閉じる形です。割合を図に埋め込まず、詳細な測定値はtest reportへ紐付けます。NETWORK LOSSでは「検知できないからN/A」と終わらせず、観測不能の検出、degraded notification、現場の代替response、復旧evidenceを評価します。

最低限のtest caseには次を含めます。

Positive scenario：定義した区域・方向・継続時間で対象が侵入／接近する
Boundary：境界線上、閾値前後、短時間通過、複数対象、対象の一部だけが見える
Negative：区域外通行、posterやreflection、停止車両、許可された保全作業を誤検知しない
Occlusion：柱、pallet、積荷、別車両で一部または全部が隠れる
Environmental：day/night、点灯切替、逆光、雨、粉塵、振動、lens汚れ
Network loss：camera-edge、edge-gateway、gateway-routerの各区間を切り分ける
Camera blocked/moved：黒画面だけでなく、静止画、blur、角度ずれを検知する
Alert delivery：primary route失敗、backup route、ack timeout、escalationを確認する
Model rollback：新versionでregressionが出たとき承認済みversionへ戻せる
Clock anomaly：時刻ずれ、offline後の再送、重複eventで順序と監査を壊さない
Human response：受信者がrunbookに沿って確認、介入、記録、再開できる
Evidence：同じcorrelation IDで入力、判断、通知、応答、変更履歴を再構成できる

FAT/SATの合否は「vendorの画面で確認した」ではなく、test ID、precondition、input、expected result、actual result、log/evidence link、reviewer、date、software/model/config versionを記録します。不合格を修正した後は、該当testだけでなく影響を受けるregression setを再実行します。

応答時間をAI推論だけで測らない

危険成立から人の行動までを、T_total = T_capture + T_inference + T_gateway + T_delivery + T_ack + T_actionに分解します。この式は設計用であり、各項の許容値は現場risk assessmentで決めます。demoで表示が速くても、夜勤の通知先が不在、mobile端末がsilent、ack後の作業が曖昧ならtotal responseは成立しません。

p95/p99を使うのはtail latencyを隠さないためです。ただしsampleが少なければpercentileは不安定です。test回数、対象shift、network conditionをreportに残し、「p99」というlabelだけで信頼性を装わないようにします。自動停止を行う安全機能では、統計的な平均やpercentileだけではなく、規格に沿ったworst-case response timeとfailure behaviorの設計・validationが別途必要です。

タイPDPAと越境・輸出ガバナンス

識別可能な作業者の映像はpersonal dataになり得ます。タイPDPA対応では、lawful basis、notice、purpose limitation、必要最小化、retention、access control、data subject対応、processor/cloud契約、越境移転、securityを、タイの法務担当またはDPOと確認してください。本稿は個別案件への法的助言ではありません。

安全の重要性は、無制限な監視を正当化しません。「事故防止のため」という広いpurposeだけでなく、対象区域、event、利用者、保存期間、二次利用を具体化します。常時録画が必要か、event前後の短いclipで足りるか、edgeで匿名化できるか、顔認識を使わずに目的を達成できるかを比較します。

governance項目	RFPで確認する質問
Purpose	どのhazardの予防・応答に使い、何には使わないか
Lawful basis	誰がどの根拠を評価し、記録し、変更時に再評価するか
Notice	worker、contractor、visitorへ何をどの言語で伝えるか
Minimization	解像度、区域mask、audio、顔認識、常時送信は本当に必要か
Retention	raw video、event clip、metadata、audit logを別々に何日保持するか
Access	live、playback、export、設定変更を誰が行い、どう記録するか
Processor/cloud	subprocessor、保存国、security、incident、削除証明は何か
Secondary use	disciplinary actionやproductivity scoringへの転用をどう禁止するか
Rights & grievance	照会・異議・訂正の窓口と、報復を防ぐprocessは何か

保持期間は一つの数字で一律に決めず、目的と証跡の必要性に対応させます。raw videoは短く、anonymized event statisticsは長く、incident evidenceはformal holdで別管理する、といった層別が考えられます。具体的な日数は法務、保険、労務、顧客要求、事故調査processを踏まえて決定します。

ThailandとILOが2025年3月25日に行ったOSH statistics改善のnational workshopは、労働災害・疾病の記録と通知の質を高める取組を示しています。AI cameraのevent数を公式事故件数と混同してはいけませんが、定義、欠損、訂正履歴を整え、予防活動のevidence qualityを高めるという方向は共通します。

費用・TCO・ROIは市場価格を置かず式で比較する

工場AIカメラの費用は、camera台数やlicenseだけでは決まりません。既存cameraの再利用可否、照明、edge compute、network工事、OT連携、labeling、privacy対策、24時間support、model更新で大きく変わるため、「一般的な価格」を根拠なく置くべきではありません。RFPでは3〜5年など、購買側が定める評価期間で項目を揃えます。

TCO = 初期設備 + 設計・設置 + edge/cloud + integration + data/labeling + FAT/SAT + security/privacy + training + 年間運用×評価年数 + refresh/retraining + exit cost

Annual benefit = 回避可能なincident期待損失 + 調査時間削減 + downtime削減 + 巡回の再配分価値 + 保険・監査上の確認可能な効果

ROI = (評価期間のbenefit - TCO) / TCO

これらは入力構造を示す式です。事故回避額や削減率をvendorの想定だけで埋めず、EHS、Finance、Operationsがrangeを置きます。incident probabilityが低く影響が大きい場合、単一の平均値より、conservative/base/upside scenarioで感度分析する方が判断しやすくなります。

TCO分類	見落としやすい項目
Hardware	housing、mount、lighting、UPS、spare、清掃access
Compute/network	GPU/edge refresh、帯域、segmentation、certificate、storage
Integration	alert、MES/SCADA、identity、ticket、audit、engineered interface
Data/MLOps	現場収集、annotation review、golden set、drift、rollback
Operations	health monitoring、lens cleaning、false-alarm triage、on-call
Privacy/security	assessment、notice、masking、access review、processor監査
Change	worker briefing、training、shift展開、SOP改訂、再受入
Exit	event/export、設定、test pack、data deletion、交換工事

PoCから量産への単純な掛け算も危険です。cameraが増えるほど、監視対象の多様性、network segment、通知routing、保全動線、false alarm対応が非線形に増えます。controlled scaleの前に、1 camera-hour当たりの誤警報と1 event当たりのreview時間から運用負荷を算出します。

なお、Thailand BOIは2026年上期について、承認した投資促進projectが1,300件、約THB 1.31 trillion、machinery・digital technology・automation・roboticsのupgrade projectがTHB 17.2 billionと発表しています。これは投資環境の参考情報であり、すべてのAI camera案件が優遇対象になる意味ではありません。対象activity、申請時期、条件はBOIまたは専門家へ個別に確認してください。

90日で進めるcontrolled rollout

図は0–30日 MAP HAZARD & DATA、31–60日 POC & NEGATIVE TESTS、61–90日 SAT & GOVERNANCE、そしてCONTROLLED SCALEへ進むproject exampleです。ownerはEHS、OPERATIONS、IT/OT、DPO、VENDORです。90日で全工場を完成させる約束ではなく、一つの優先areaで発注・受入判断に必要なevidenceを揃える枠組みです。

0〜30日：hazardとdata boundaryを固定する

EHSとOperationsがincident、near miss、動線、既存controlを確認し、一つか二つのscenarioを選びます。現場walkthroughでcamera候補位置、照明、遮蔽、保全accessを調べます。IT/OTはnetwork zone、edge設置、時刻同期、alert接続を整理します。DPO/Legalはpurpose、lawful basis、notice、retention、access、worker consultationを確認します。

この段階の出口は、承認済みuse-case sheet、hazard/coverage map、data flow、対象外、RACI、test outlineです。vendorへ「まず撮って学習させる」と丸投げせず、収集前に範囲を承認します。

31〜60日：PoCとnegative testを回す

代表するday/night shiftでdataを収集し、annotation ruleとgolden test packを作ります。camera/edge/gateway/routerを接続し、positive、boundary、negative、occlusion、network loss、camera blockedを実行します。precision/recallだけでなくfalse alarms per camera-hour、p95/p99 latency、evidence completeness、operator workloadを測ります。

週次reviewでは、threshold調整で誤警報を隠していないか、あるscenarioの改善が別scenarioのrecallを落としていないかを確認します。変更はmodel/rule/config versionと理由を記録し、元へ戻せるようにします。

61〜90日：SAT、教育、governanceを閉じる

本番相当のnetwork、通知端末、shift、担当者でSATを実施します。alert acknowledgement、現場response、escalation、障害時のdegraded mode、復旧、model rollbackをrunbookで確認します。workerへ目的、対象区域、利用禁止事項、問い合わせ窓口を説明し、supervisorとmaintenanceを教育します。

すべてのcritical testが閉じ、未解決riskにownerと期限が付き、privacy/security承認、operation capacity、support体制がそろってからcontrolled scaleへ進みます。次のareaは、同じtest packを流用するだけでなく、そのarea固有のhazard、lighting、traffic、制服、vehicleを追加します。

NIST AI RMFで運用を継続管理する

NIST AI Risk Management Frameworkは、Govern、Map、Measure、Manageの四機能でAI risk managementを整理しています。これはタイの法的義務として引用するものではありませんが、工場AIのgovernance scaffoldingとして使えます。

Govern：policy、owner、承認、competence、vendor責任、worker participation、記録を定める
Map：hazard、利用者、影響を受ける人、data flow、既存control、failure contextを把握する
Measure：scenario metric、subgroup、latency、availability、privacy/security、human factorsを試験する
Manage：riskを優先し、導入、制限、停止、是正、rollback、廃止を判断する

運用会議では、AI event数を「安全が改善した証拠」と短絡しません。導入直後にeventが増えたのは、危険が増えたのではなく観測可能性が上がったためかもしれません。反対にeventが減ったのは、対策が効いたのか、cameraが汚れたのか、thresholdが変わったのかを区別します。near miss、現場観察、設備変更、worker feedbackと突き合わせます。

model change、camera移設、layout変更、制服変更、vehicle追加、software updateは再評価triggerです。変更の前後でgolden testを走らせ、critical regressionがあればreleaseを止めます。監査では「最新versionを使っている」だけでなく、なぜ変更したか、誰が承認したか、どのtestに合格したかを示します。

FAQ：工場のAI安全監視を発注する前の疑問

安全管理AIとは何ですか？

映像やsensor dataから、定義した危険scenarioの兆候を観測し、通知、対応、改善へつなげる仕組みです。一般的なAI cameraは観測・escalation層であり、それだけでsafety-rated protective functionにはなりません。hazardの除去、代替、工学的対策を先に検討し、残留riskへの補完として位置付けます。

AIカメラを工場へ入れれば安全柵やライトカーテンを外せますか？

一般には、そのように考えてはいけません。通常の画像解析を物理分離、防護、interlock、安全PLC、light curtainの代替にしないでください。自動停止を含む場合は、required risk reductionに応じた安全機能全体を専門家が設計し、適用規格に沿ってvalidationする必要があります。

フォークリフトと歩行者の検知では何を試験しますか？

距離だけでなく、方向、速度、交差、停止、積荷による遮蔽、複数人、day/night、区域境界をscenario化します。recall、precision、false alarms per camera-hour、p95/p99 detection/alert latency、coverage、evidence completenessを分け、通知後に人が応答できたかまで受け入れます。

安全監視AIの認識率は何％なら合格ですか？

普遍的な合格率はありません。hazard severity、回避可能性、既存control、応答時間、現場条件に基づいてsite-specific thresholdを決めます。overall accuracy一つではなく、critical scenarioのrecall、false alarm、latency、availability、blind zoneを個別に評価します。

工場の危険エリア検知でネットワークが切れたらどうしますか？

観測不能を検知し、現場へdegraded modeを通知し、巡回強化や区域制限など代替controlへ切り替えます。offline buffer、復旧時の再同期、古いeventの扱い、evidence欠損をFAT/SATで試験します。通信断時にも安全を維持する方法はrisk assessmentで決めます。

作業者の映像はタイPDPAの対象ですか？

識別可能な映像はpersonal dataになり得ます。lawful basis、notice、purpose limitation、retention、access、processor/cloud契約、越境移転、securityをタイの法務担当またはDPOと確認してください。安全映像を無断でproductivity scoringやdisciplinary rankingへ転用しない仕組みも必要です。

PoC、FAT、SATの違いは何ですか？

PoCは現場条件でuse caseと運用仮説が成立するかを学ぶ段階、FATはvendor環境で固定versionとtest packを再現する段階、SATは本番相当のcamera、network、通知、人員で端から端まで受け入れる段階です。いずれもnegative testとevidenceを含めます。

工場AIカメラの費用やROIはどう比較しますか？

camera価格だけでなく、設置、lighting、edge、network、integration、data/labeling、FAT/SAT、privacy/security、training、運用、retraining、exit costをTCOへ含めます。便益は事故回避の期待値だけに依存せず、調査時間、downtime、巡回再配分などをrangeで評価し、感度分析します。

まとめ：安全を「AIの点数」ではなく運用証跡で強くする

工場の安全管理AIで調達すべきものは、印象的な検知demoではありません。hazard、coverage、model decision、alert、human response、recovery、audit、privacyを一つの再現可能なloopにし、PoC、FAT、SATでpositive/negative双方を検証することです。AI cameraは管理策の優先順位の中で補完層として使い、安全機能との境界を曖昧にしません。

TOMAS TECHでは、フォークリフト動線や危険エリアの整理、camera/edge構成、RFP、PoC、FAT/SAT、IT/OT連携、タイPDPAを含む運用設計まで、検討初期からご相談いただけます。製品を決める前の要件整理や一つのareaでの90日検証からでも、お問い合わせください。