編集コメント:AIが危険を検知できることと、機械の安全機能を担えることは同じではありません。両者の責任分界を設計段階で明確にする必要があります。
先に結論
Physical AIやAI搭載ロボットでは、非常停止をAIの判断だけに依存させるべきではありません。非常停止入力、保護センサ、安全ロジック、アクチュエータ停止までの安全関連経路を、AIの通常制御・推論経路から機能的に独立させるのが基本です。AIはカメラやセンサから危険を検知し、追加の停止要求を出す補助層として扱います。
ここでいう「分離」は、必ずしも別CPUや別配線を意味しません。必要な安全性能、故障時の安全状態、共通原因故障への耐性をリスクアセスメントで確認できるなら、安全コントローラや安全認証済みネットワークを使った統合も候補になります。ただし、AI系の停止要求が失敗しても、人間の非常停止や保護センサから安全状態へ移行する経路が機能しなければなりません。
なぜAI判断と非常停止を分けるのか
AIの認識や行動計画は、入力データ、推論処理、通信、ソフトウェアの状態に依存します。危険を認識できない場合だけでなく、推論や通常制御が停止した場合にも、安全機能まで失われる構成は避ける必要があります。
機能安全で評価する対象は、AIの認識精度だけではありません。安全関連制御部に要求される性能、故障の検出、故障時にどの安全状態へ移行するか、ソフトウェアを含む設計と統合を確認します。したがって、AIモデルの精度評価やAIリスク管理の文書だけで、非常停止回路の安全妥当性を示すことはできません。
用語を分けて仕様化する
ISO 13850:2015では、非常停止機能は単一の人間の操作で開始される機能として扱われます。すべての運転モードで利用可能かつ作動可能で、他の機能や操作より優先され、リセットだけで再起動してはなりません。また、非常停止は安全防護の代替ではなく、補完的な安全機能です。
一方、AIが自動的に出す停止要求を製品資料などで「E-stop」と呼ぶことがあります。しかし、仕様上は少なくとも次を区別する必要があります。
- 非常停止:人間の操作で開始され、他の操作より優先される安全機能
- 保護停止:センサなどが危険条件を検知したとき、安全状態へ移行する機能
- 通常停止:タスク完了や運用指示に基づく停止
- AIによる停止要求:AIの危険検知を起点とする追加の停止要求
AIによる停止要求を、非常停止の代替として扱うのではなく、保護停止や追加のリスク低減層として要件、故障時挙動、検証方法を別途定義することが妥当です。
内部の仕組み
基本構成では、非常停止ボタン、ガードスイッチ、安全スキャナなどを安全ロジックへ接続します。安全ロジックは安全関連の出力を介して、安全対応ドライブやブレーキなどを制御し、機械を定義済みの安全状態へ移行させます。AI側はカメラやセンサを入力として推論し、必要に応じて安全系へ停止要求を入力しますが、AI側から安全系を無効化する経路は設けません。
安全状態がモータトルク遮断、ブレーキ適用、電源遮断、保持状態のいずれになるかは、ロボットの機構、負荷、落下や挟圧の危険によって異なります。対象機械の情報がない段階で、停止カテゴリ、停止時間、制動距離、要求PLやSILを一律に決めることはできません。
flowchart LR
subgraph SAFETY["安全関連経路"]
E["非常停止ボタン"] --> SL["安全ロジック"]
G["ガードスイッチ"] --> SL
S["安全スキャナ"] --> SL
SL -->|"安全関連出力"| D["安全対応ドライブ"]
end
subgraph AICTRL["AI・通常制御経路"]
C["カメラ・センサ"] --> INF["AI推論"]
INF --> P["タスクプランナ"]
P --> NC["通常コントローラ"]
NC -->|"通常の駆動指令"| D
INF -->|"補助的な停止要求"| SL
end
D --> A["アクチュエータ"]
A --> SS["定義済みの安全状態"]系統ごとの比較
| 系統・方式 | 主な開始者 | 役割 | AIへの依存 | 設計・検証の焦点 |
|---|---|---|---|---|
| 非常停止 | 人間 | 危険な機能を優先的に停止 | 依存させない | 常時利用可能性、優先性、リセット後の再起動防止 |
| 保護停止 | 保護センサや安全ロジック | 検知した危険条件から安全状態へ移行 | 安全センサを使う場合は安全系として評価 | 故障検出、安全状態、要求性能 |
| 通常停止 | 運用者やタスク制御 | 通常の動作終了 | 通常制御に依存 | 停止手順と運用上の再開条件 |
| AIによる停止要求 | AIの危険検知 | 追加のリスク低減層 | 認識・推論に依存 | 未検知、誤検知、停止要求失敗時の挙動 |
物理分離か、機能的な分離か
設計判断では、まず「別CPUかどうか」ではなく、安全機能がAI系の故障に妨げられないかを確認します。AIの通常制御と安全関連制御を別の機能として定義し、入力、処理、出力、故障時挙動、検証責任を分けることが出発点です。
物理的に別CPU・別配線とする方式は、AI側の障害が安全系へ波及する経路を限定しやすい一方、構成や統合の管理対象が増えます。安全コントローラや安全認証済みネットワークで統合する方式は候補になり得ますが、AI系の故障が安全機能を妨げないことを、適用する安全性能とともに検証しなければなりません。どの方式が適切かは、危険源、運転モード、故障時の挙動、必要なリスク低減効果で判断します。
実装・利用時の判断手順
まずISO 12100:2010の考え方に沿って、危険源を同定し、リスクを見積もり・評価します。そのうえで保護方策を設計し、残留リスクを扱います。AIを使うこと自体を安全方策とみなすのではなく、AIが担う機能と、安全関連制御系が担う機能を分解して記述します。
次に、非常停止ボタンや保護センサから安全ロジックを経由し、アクチュエータを安全状態へ移行させる経路を定義します。AIからの停止要求は追加入力とし、その要求が無効、遅延、誤検知した場合にも非常停止経路が機能することを確認します。非常停止のリセットは再起動そのものにせず、再起動に必要な別の条件や操作を仕様化します。
PoCでは、AIの検知能力を示すだけでなく、AI停止要求を切断した状態でも安全系が動作するかを確認する視点が必要です。製品化では、要求性能、故障検出、故障時の安全状態、ソフトウェアと統合の検証、さらにAIモデルやデータセットを変更した場合の変更管理まで、対象とする安全ライフサイクルに組み込みます。具体的なPLr、SIL、停止時間や制動距離は、対象機械と適用規格に基づいて別途確定します。
制約と失敗しやすい点
第一に、AIの認識精度を安全機能の性能と取り違えることです。認識精度が高くても、入力欠損、モデルの不確実性、ソフトウェア障害、通信障害が起きたときの安全状態は別に評価しなければなりません。
第二に、「分離」を物理分離だけで判断することです。別CPUや別配線を採用しても、共通電源、共通通信、共通ソフトウェア、共通原因故障が残れば、期待した独立性が得られない可能性があります。逆に、物理的に統合された構成でも、要求性能と故障時挙動を満たす設計は候補になり得ます。
第三に、AIの自動停止を非常停止と呼ぶことです。非常停止の開始者や優先性に関する要件と、AIの危険検知機能の性質を混同すると、仕様、検証、責任範囲が曖昧になります。
どのような場合に採用すべきか
人が近くで作業する、可動部が大きなエネルギーを持つ、挟圧・衝突・落下などの危険がある、複数の運転モードを持つ、といった機械では、AI判断だけに非常停止を担わせない設計を前提にします。AIを使う場合も、非常停止と保護センサを含む安全関連経路を先に定義し、AIは追加の検知・停止要求として位置付けます。
適用地域の確認も必要です。EUの機械規則(EU)2023/1230は、非常停止装置について識別・操作の容易さ、危険な機能の可能な限り速やかな停止、常時利用可能であること、安全防護の代替ではないことを求めています。適用開始日は2027年1月20日であるため、2026年1月時点では販売地域、現行法令、移行措置との関係を確認します。
NIST AI RMF 1.0は、安全性やセキュリティ・レジリエンスを含むAIリスクをライフサイクル全体で管理する枠組みです。ただし、機械の非常停止回路、要求PL、SILを定める規格ではありません。AIガバナンスと機械安全の要求を補完関係として扱うことが必要です。
まとめ
非常停止は、AIの認識・計画・通常制御とは別の安全関連機能として設計するのが原則です。分離の本質は、別CPUや別配線という形式ではなく、AI系の故障が非常停止や保護停止を妨げない機能的独立性にあります。リスクアセスメントで危険源と安全状態を定義し、要求性能、故障時挙動、検証範囲を確定したうえで、AIの停止要求を追加の安全層として組み込むべきです。
参考情報
- ISO 13850:2015 — Safety of machinery — Emergency stop function — Principles for design
- ISO 13849-1:2023 — Safety-related parts of control systems
- ISO 12100:2010 — Risk assessment and risk reduction
- Regulation (EU) 2023/1230 on machinery products
- NIST AI Risk Management Framework 1.0
停止要求の種類とリセット後の再起動条件
flowchart TD
START["停止要求または停止指示が発生"] --> KIND{"要求の種類"}
KIND -->|"非常停止:人間の操作"| ESTOP["安全状態へ移行\n他の操作より優先"]
KIND -->|"保護停止:保護センサ・安全ロジック"| PSTOP["安全状態へ移行\n検知した危険条件に対応"]
KIND -->|"AIによる停止要求"| AISTOP["追加の停止要求として安全系へ入力"]
KIND -->|"通常停止:運用者・タスク制御"| NSTOP["通常の停止手順を実行"]
AISTOP --> SAFE["安全系による安全状態への移行"]
ESTOP --> HOLD["停止状態を保持"]
PSTOP --> HOLD
SAFE --> HOLD
HOLD --> RESET["リセット操作"]
RESET --> CHECK["再起動に必要な別条件・操作を確認"]
CHECK --> STARTUP["別の起動操作で再起動"]
RESET -.->|"リセットだけでは再起動しない"| HOLDAIの能力を安全機能へ組み込むほど、認識性能だけでなく、故障時に何が止まり、何が止まらないかを先に定義することが欠かせません。
AI利用に関する注記
本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。