ロボットの安全性 on Physical AI Hub

ROS 2実行時パラメータ設計：動的変更・検証・適用境界をどう決めるか

Wed, 04 Nov 2026 15:01:42 +0900

実行中に設定を変えられるROS 2の柔軟性は、適用境界をどう設計するかで安全性が変わります。

結論

ROS 2の実行時パラメータ変更は、再起動なしの運用に役立ちます。ただし、変更できることと、安全に運転中へ即時反映できることは別です。影響範囲が限定された値だけを動的変更の対象にし、型・値域・単位・相互依存関係を検証したうえで、関連パラメータを原子的に更新します。

制御ゲイン、速度・加速度上限、衝突判定閾値などは、安全な制御周期境界、またはLifecycle NodeのInactive状態で反映する設計が基本です。資源の再確保、通信設定、QoS、コンポーネント構成の変更を伴う値は、Lifecycle遷移や再起動を適用境界にします。認証・認可、監視、監査、ロールバックまでを一つの運用フローとして設計することが、運用性と安全性を両立する条件です。

なぜ適用境界が必要か

ROS 2のパラメータはノードに関連付けられ、ノードのパラメータサービスから取得・設定できます。変更はParameterEventとして通知できるため、再起動せずにセンサー閾値や診断設定を調整し、変更を監視できます。

一方、パラメータ機構が支援するのは、主に型やAPIレベルの整合性です。制御安定性、機械的安全、停止距離、センサー間の依存関係まで自動判定するわけではありません。数値として正しいゲインでも、ロボットの機構や制御周期との組み合わせによって安全とは限らないため、「変更可能か」と「運転中に反映できるか」を分けて判断します。

パラメータ変更の仕組み

パラメータは宣言して使用し、宣言時に型や説明を付与します。ParameterDescriptorでは、read_only、動的型付け、整数・浮動小数点の範囲、追加制約などを記述できます。ただし、メタデータだけでドメイン固有の安全条件が満たされるわけではありません。必要な値域や組み合わせ条件は、対象ディストリビューションのAPI仕様を確認し、ノード側の検証処理でも明示します。

ノードにはパラメータ変更コールバックを登録できます。コールバックは値が確定する前に候補を検証し、要求を受け入れるか拒否する場所です。ここでアクチュエータを操作したり、再帰的に別のパラメータ変更を呼び出したりせず、検証と実際の適用を分離します。

複数のパラメータが関係する場合は、通常のset_parametersではなくset_parameters_atomicallyを使います。set_parametersは非原子的で、各パラメータの結果を個別に返します。これに対し、set_parameters_atomicallyは候補のいずれかが失敗した場合、パラメータ全体を変更しません。ゲインと上限値など、組み合わせの整合性が必要な変更に適しています。

ただし、この原子性はパラメータ設定に関するものです。外部ハードウェア、制御器内部状態、すでに送信した指令まで自動的に元へ戻す仕組みではありません。

flowchart LR
  A["変更要求"] --> B["認証・認可"]
  B --> C["型・値域・単位・相互依存を検証"]
  C --> D{"検証に成功?"}
  D -- "いいえ" --> E["変更を拒否して記録"]
  D -- "はい" --> F["set_parameters_atomicallyで候補を更新"]
  F --> G{"適用境界を満たす?"}
  G -- "いいえ" --> H["安全な制御周期境界またはInactiveまで保留"]
  H --> I["実値へ適用"]
  G -- "はい" --> I
  I --> J["動作・制御状態・異常を監視"]
  I --> K["ParameterEventと外部監査ログを記録"]
  J --> L{"異常を検知?"}
  L -- "いいえ" --> M["変更後状態を継続監視"]
  L -- "はい" --> N["旧設定へ復元、停止、または再起動"]
  K --> M
  N --> O["復旧結果を記録"]

パラメータの受付、検証、原子的更新、適用、監視、監査、異常時の復旧を分離した安全な変更フロー。

Lifecycleと適用タイミング

Lifecycle Nodeには、Unconfigured、Inactive、Activeなどの状態と、configure、activate、deactivate、cleanupなどの遷移があります。どの状態でパラメータを適用し、どの資源を再構成するかはノード実装が定義します。Inactive状態だから自動的にアクチュエータ出力が停止する、という保証もありません。

ロボットの遠隔操作と自律制御を安全に切り替える：人間への引き継ぎ設計

Fri, 30 Oct 2026 14:33:57 +0900

自律制御と遠隔操作の境界では、切り替えの速さよりも権限の重なりをどう防ぐかが設計上の焦点になります。

先に結論

ロボットの自律制御と遠隔操作の切り替えは、単一の信頼度スコアや「人間を常に優先する」という規則だけで決めるべきではない。安全包絡への接近、認識・自己位置推定の不確実性、タスク例外、通信状態、人間からの介入要求を組み合わせたリスクベースの状態遷移として設計する。

運動指令を発行できる主体は、常に一つに限定する。自律系と遠隔操作者の指令経路から分離した安全監視層を設け、必要な場合には双方の指令を拒否・遮断できるようにする。通信断、端末の無応答、許容遅延の超過、制御権の期限切れでは、遠隔操作を継続せず、検証済みの安全停止または最小リスク状態へ移行させる。

なぜ引き継ぎ設計が難しいのか

引き継ぎは、単にモード名を書き換える処理ではない。自律系が指令を出し続けたまま遠隔操作者の指令を受け付ければ、切り替え境界で指令が競合する。逆に自律系を先に停止すると、操作者が状況を把握する前にロボットが別の状態へ移る可能性がある。

そのため、設計対象はトリガーだけではない。旧制御主体がいつ指令権を失ったか、新しい主体がいつ取得したか、操作者がどの状態を見ているか、引き継ぎに失敗した場合にどこへ遷移するかまでを、制御契約として定義する必要がある。ISO 12100:2010も、意図する使用と合理的に予見可能な誤使用を含むリスクアセスメントとリスク低減を示しており、モード切替もその対象として扱うのが妥当である。ISO 12100:2010

前提となる用語

自律制御は、ロボット側の方策やプランナーが運動指令を生成する状態である。遠隔操作は、通信経路を通じて操作者が指令を入力する状態を指す。共有自律は、人間の方策とロボットの方策を組み合わせる設計で、意図検出、制御権の裁定、状態や意図の伝達が主要な論点になる。

共有自律には、人間とロボットの指令を連続的に混合するpolicy blendingと、明示的な裁定によって一方へ制御権を渡す方式がある。すべての用途で優れた単一方式が定まっているわけではないため、責任主体と安全制約を明確にできるかで選ぶべきである。

引き継ぎ条件の設計

引き継ぎトリガーは、次の観測項目を個別に評価し、論理条件として組み合わせる。

予測軌道が安全包絡に接近、または違反する
認識や自己位置推定の不確実性が許容範囲を超える
予定外の物体、作業対象、経路、タスク状態が現れる
遠隔操作者が介入を要求する
通信の期限、ハートビート、遅延などに異常がある

数値閾値は一般化できない。安全包絡、信頼度、通信遅延、タイムアウトの値は、ロボットの速度や質量、環境、作業対象、運用地域、適用規格によって変わるため、対象機のリスク分析と検証で定める。NIST AI Risk Management Frameworkは役割・責任、リスク測定、継続的監視、リスク対応を扱うが、具体的なロボットの切替閾値は規定していない。NIST AI RMF

状態機械と操作権限

実装では、少なくとも「自律制御」「引き継ぎ要求」「引き継ぎ待ち」「遠隔操作」「安全停止」「復旧」を明示した状態機械にする。引き継ぎ要求が発生しても、直ちに操作者へ運動指令を許可するのではなく、ロボット状態、通信品質、操作者の準備状態、停止が必要かどうかを確認する。

旧制御主体のアクチュエーション権限が失われたことを確認してから、新しい主体へ権限を渡す。制御権をリースまたはトークンとして扱い、期限切れ、二重取得、明示的な解放を検出できるようにすると、境界上の異常を追跡しやすい。

flowchart LR
  A["自律制御\n運動指令の主体: 自律系"] -->|"安全包絡への接近・認識不確実性・タスク例外・人間要求"| B["引き継ぎ要求"]
  B --> C["引き継ぎ待ち\n状態・通信・認証・準備状態を確認"]
  C -->|"旧主体の権限喪失を確認\n制御権リースを解放"| D["遠隔操作\n運動指令の主体: 操作者"]
  C -->|"確認失敗・承認失敗・危険状態"| E["安全停止または\n最小リスク状態"]
  D -->|"ハートビート途切れ・端末無応答\n許容遅延超過・リース期限切れ"| E
  D -->|"自律系への復帰条件を確認\n制御権を明示的に解放"| F["復旧"]
  E -->|"原因除去・安全確認・復旧承認"| F
  F -->|"新しい制御権を単一主体へ付与"| A
  S["独立した安全監視層\n速度・位置・侵入・停止条件を監視"] -.->|"必要時に指令を拒否・遮断"| A
  S -.->|"必要時に指令を拒否・遮断"| D
  S -.->|"通常の権限裁定とは分離"| E

引き継ぎ条件の評価、旧制御主体の権限喪失確認、新しい主体への制御権付与、通信異常時の安全遷移を状態機械として示す。

方式	指令の扱い	使いどころ	主な制約
自律制御	自律系が運動指令を発行	通常運転の自動化	想定外状態での引き継ぎ条件が必要
遠隔操作	操作者が運動指令を発行	例外状態への人間の介入	通信遅延、端末障害、状況認識が制約になる
共有自律	指令を混合または裁定	人間と自律系の協調	責任主体と指令競合の明確化が必要
安全監視・停止	指令を監視し拒否・遮断	危険状態の抑制	通常の操作権限とは分離して検証する

基本形として採用しやすいのは、単一オーナー方式である。自律系、遠隔操作者、保守・設定系のうち、運動指令を発行できる主体を常に一つにする。アクセス強制と最小権限の考え方は、主体ごとの権限分離に利用できるが、NIST SP 800-53自体はロボット安全規格ではない。NIST SP 800-53 Rev. 5

学習方策を安全に動かすランタイム保証：監視・シールド・フォールバックの設計

Thu, 29 Oct 2026 14:33:48 +0900

学習モデルの出力を、そのまま物理系へ渡してよいのか。ランタイム保証は、この素朴な疑問を実装可能な層構造へ変換する設計課題です。

先に結論

学習ベースのロボット方策は、アクチュエータへ直接接続せず、独立したランタイム監視層を間に置く構成が基本です。監視層は現在状態だけでなく、方策の出力と短時間先の予測状態を、速度・トルク・接触・関節限界などの制約と照合します。その結果に応じて、通常の指令を許可する、指令を安全側へ修正する、検証済みのリカバリ方策へ切り替える、または停止する、という経路を選びます。

ただし、シールドや制御バリア関数（CBF）があるだけで安全性が自動的に保証されるわけではありません。モデル、状態推定、入力制約、計算時間、フォールバックの妥当性が前提を満たす必要があります。実機では、監視器そのものの故障、センサー欠測、通信遅延、アクチュエータ飽和まで含めて設計対象にします。

なぜランタイム保証が必要か

VLA、模倣学習、強化学習の方策は、認識やタスク遂行を柔軟に扱える一方、出力をそのまま物理系へ適用できるとは限りません。モデルの意味的な信頼度やOODスコアだけでは、接触力、関節限界、急激な速度変化といった低レベルの危険を十分に判定できるか確認できません。

そこで、学習方策の性能と安全性を同じモジュールに背負わせず、独立した安全側の仕組みを設けます。Simplex型の考え方では、高機能だが事前に信頼性を証明しにくいコントローラと、より単純で検証しやすい安全コントローラを併用し、監視と切り替えによって安全側を選択します。

用語と方式の違い

安全シールドは、環境モデルと安全仕様を使い、危険な行動を実行前または状態遷移前に抑止する仕組みです。離散的な状態遷移やアクションの安全性を扱いやすい一方、連続ロボットの物理ダイナミクスへ適用するには、モデル化の範囲を明確にする必要があります。

CBFは、安全集合の前向き不変性を保つ条件を制御入力の制約として表現します。方策が出した入力を、二次計画問題（CBF-QP）などで安全条件を満たす入力へ修正する設計に利用できます。

リカバリ方策は、通常方策とは別に、安全側へ戻すための方策を持つ方式です。危険領域や高リスク状態を検出したとき、通常のタスク方策からリカバリ方策へ切り替えます。安全フィルタの修正だけでは状態を戻せない場合に選択肢となります。

flowchart LR
  S["センサー"] --> E["状態推定"]
  E --> P["学習方策\nVLA・模倣学習・強化学習"]
  P --> M["独立したランタイム監視器"]
  E --> M
  M --> C["現在状態・方策出力・予測状態を制約評価"]
  C --> A["通常指令を許可"]
  C --> F["安全側へ指令を修正\nCBF-QP・速度制限・トルク制限"]
  C --> R["リカバリ方策へ切り替え"]
  C --> X["停止"]
  A --> W["ウォッチドッグ確認"]
  F --> W
  R --> W
  W --> O["制約検査済み指令"]
  X --> O
  O --> Act["アクチュエータ"]

学習方策をアクチュエータへ直接接続せず、独立した監視層で指令を評価・修正する構成を示します。

1制御周期の処理

実装では、監視器をアクチュエータ指令の直前に置きます。概念的なデータフローは、センサー取得、状態推定、学習方策の推論、短時間先の予測、制約評価、指令の許可または修正、ウォッチドッグ確認、アクチュエータ出力です。

監視対象は少なくとも次の三つに分けます。

人協働ロボットの近接安全設計：人の動きを推定して速度制限へつなげる方法

Fri, 09 Oct 2026 14:54:15 +0900

人の動きを予測できても、安全判断では予測の不確実性をどう扱うかが問われます。

先に結論

人と協働するロボットの近接安全は、「人を検知したら停止する」か「AIの予測に任せる」かの二択ではない。人体の占有領域をロボットの危険源と同じ座標系で扱い、検出遅延、遮蔽、位置誤差、相対速度、ロボットの停止距離を含めて保護分離距離を継続評価することが基本になる。

分離距離を保証できる間は通常速度または制限速度で運転し、制限速度でも境界を維持できない場合は保護停止へ移行する。センサー故障、追跡断絶、通信・同期異常などで保証が失われた場合は、最後の推定値や予測値で運転を継続しない。予測軌道は先回りした速度制限の補助には使えるが、それだけを安全バリアとして扱うべきではない。

なぜ動的な評価が必要か

協働ロボットでは、人が作業領域に入ること自体が直ちに異常とは限らない。ロボットの速度、工具の形状、人体との距離、制動性能に応じて、通常動作、速度制限、保護停止を使い分ける必要がある。一方、検出から制動開始までに時間がかかれば、検知時点では安全に見えても、ロボットはその間に人体へ接近する。

そのため設計対象は人体検出器だけではない。センサー、推定器、通信、制御器、ドライブ、ブレーキを含む安全機能全体を、リスクアセスメントと安全関連制御系の要求に結び付ける必要がある。ISO/TS 15066は速度・分離監視などの協働運転方式を扱い、ISO 12100は危険源の同定、リスク低減、妥当性確認を含む設計プロセスを示している。

位置・速度・予測軌道の扱い

人体の位置は一点ではなく、人体または身体部位の占有領域として表現する。人体、ロボットの危険点、工具、周辺設備を共通座標系へ変換し、センサーの位置誤差、時刻同期と検出の遅延、遮蔽、複数人の識別不確実性を危険側に評価する。

安全レーザースキャナなどが保護フィールドへの侵入状態だけを出力する場合、その出力から連続的な位置や速度を直接得られるとは限らない。連続トラッキングを利用する場合は、時刻付きの位置推定から危険源への相対速度、つまり接近速度を算出する。平滑化や外れ値除去を行う場合も、更新遅延、推定誤差、トラッキング断絶を考慮し、瞬間値をそのまま安全入力にしない。

予測軌道は、将来位置を示す一本の確定線ではない。人の動きは周囲の人、物体、環境、相互作用、作業意図に依存し、予測ホライズンが長いほど不確実性が増す。したがって短時間先の複数の軌道候補を包絡する占有領域として扱い、最大接近速度と位置不確実性を含めてロボットの停止包絡との重なりを評価する。遮蔽、信頼度低下、追跡断絶、想定外の加速度が起きた場合は、予測を無効化して保守側へ遷移させる。

flowchart LR
  A["センサー入力\n時刻付きデータ"] --> B["時刻同期・共通座標系への変換"]
  B --> C["人体・身体部位の\n占有領域を推定"]
  C --> D["追跡・接近速度・\n不確実性を推定"]
  D --> E["短時間の複数軌道を\n占有包絡として評価"]
  E --> F["ロボットの停止包絡と\n保護分離距離を評価"]
  F --> G{"分離距離を\n保証できるか"}
  G -->|"余裕がある"| H["通常動作"]
  G -->|"制限速度なら保証可能"| I["速度制限"]
  G -->|"保証できない"| J["安全関連の保護停止"]
  D --> K{"追跡・同期・検出系に\n異常があるか"}
  K -->|"いいえ"| E
  K -->|"はい"| L["保守側へ遷移"]
  L --> I
  L --> J
  E -.-> M["予測は補助情報\n安全バリア単独ではない"]
  M -.-> F

人体の位置・接近速度・不確実性とロボットの停止性能を継続的に評価し、分離距離を保証できる範囲で速度を制限し、保証できない場合は保護停止へ移行する概念フロー。

分離距離から速度制限へ

保護分離距離の考え方では、人体の接近速度、システム全体の応答時間、ロボットの停止距離、人体または身体部位の侵入距離、センサーと位置推定の不確実性を考慮する。ISO 13855の基本関係は、接近速度をK、総応答時間をT、侵入距離をCとして S=K×T+C で表される。

ロボット視覚の分布外検知：未知物体を見つけて安全に行動を保留する設計

Sun, 04 Oct 2026 14:37:40 +0900

未知物体を見つけることと、ロボットを安全に止めることは、同じ判定ではありません。この違いが設計の分かれ目です。

結論

ロボットの視覚認識で未知物体や分布外（OOD）入力を扱うには、最大ソフトマックス確率だけで行動可否を決めてはいけません。分類信頼度、OODスコア、物体の位置推定品質、モデル間の不一致、センサ健全性、フレーム間の一貫性を組み合わせた受理ゲートを設け、条件を満たさない入力は行動系へ渡さず、明示的なsafe-hold状態へ送る設計が現実的です。

safe-holdでは、状況に応じて停止または減速し、再観測、再計画、人間確認などへ切り替えます。閾値は一般的な固定値ではなく、危険な誤受理を重く扱うリスク・カバレッジ評価と、照明、遮蔽、反射、モーションブラー、センサ欠損を含む実機シナリオで決める必要があります。

なぜ未知入力への備えが必要か

OOD検知は、学習時のデータ分布から外れた入力を検出する問題です。一方、オープンセット認識は、テスト時に学習時には存在しなかった未知クラスを扱う問題として整理できます。既知クラスの精度が高くても、実環境で未知物体を既知クラスの一つとして誤認すれば、把持や進入などの行動に誤った前提を渡す可能性があります。

ただし、未知物体であること自体が物理的危険を意味するわけではありません。反対に、既知クラスでも遮蔽、異常姿勢、反射、ブラー、センサ故障によって危険な認識が生じる場合があります。そのため、OOD検知は安全性全体の判定器ではなく、視覚認識パイプラインの一つの警告信号として扱います。

信頼度とOODスコアの前提

最大ソフトマックス確率は、誤分類例やOOD例を検出する低コストなベースラインです。しかし、その値を正しさや安全性の確率として直接解釈することはできません。深層モデルでは、予測確率と実際の正解率が一致しない校正不良が起こり得るためです。必要に応じて校正を検討しても、分布シフト下で安全な確信度が保証されるわけではありません。

候補となる方法には、特徴空間での距離、クラス条件付き分布からのMahalanobis距離、複数モデルの予測分散を利用する深層アンサンブルがあります。手法ごとに検出しやすい分布外入力が異なり、画像分類、物体検出、敵対的入力、実環境のセンサ劣化を横断して論文上の数値を直接比較することはできません。

ロボットでは画像全体のOOD判定だけで不十分な場合があります。未知物体が画面の一部にあるなら、その領域を局所化し、既知物体と未知物体を区別するオープンワールド物体検出が必要です。物体検出の信頼度が低い、位置が不安定、未知領域が行動経路に重なる、といった情報を行動判断へ渡せる形にします。

flowchart LR
  A["カメラなどのセンサ入力"] --> B["物体検出・分類"]
  B --> C["物体クラス・位置・物体性・検出信頼度"]
  C --> D["OOD・不確実性の評価"]
  D --> D1["最大確率・校正済み信頼度"]
  D --> D2["特徴距離"]
  D --> D3["モデル間の予測ばらつき"]
  C --> E["未知物体の領域・局所化"]
  A --> F["センサ健全性の確認"]
  B --> G["フレーム間の位置・クラスの一貫性"]
  D1 --> H["多段の受理ゲート"]
  D2 --> H
  D3 --> H
  E --> H
  F --> H
  G --> H
  H -->|"条件を満たす"| I["行動計画へ渡す"]
  H -->|"条件を満たさない"| J["safe-hold"]
  J --> J1["停止または減速"]
  J --> J2["再観測・再計画"]
  J --> J3["人間確認"]

視覚認識の出力を直接アクチュエータへ接続せず、複数の信号を受理ゲートで確認してから行動またはsafe-holdへ分岐させる。

受理ゲートの構成

実装では、認識器の出力をそのままアクチュエータへ接続せず、次のような多段ゲートを置きます。

学習ベースのロボット機能を説明可能にする安全ケースの作り方

Thu, 01 Oct 2026 14:38:11 +0900

学習モデルの評価結果を、現場で成立する安全の説明へどう接続するかが気になるテーマです。

結論

学習ベースのロボット機能の安全ケースは、AIモデル単体の精度を証明する文書ではありません。最上位に「定義した運用範囲と制約の中で、対象機能が許容可能な安全性を満たす」という主張を置き、危険源、安全目標、安全要求、実装上の防護、検証結果、残留リスク、運用監視へ分解します。

各主張は、要求仕様、データセット、モデル、ソフトウェア構成、テスト条件、判定結果、運用記録へ追跡できるようにします。学習モデルを安全機能上の唯一の防護層とせず、異常時に停止、減速、退避などの安全側状態へ移行できる仕組みを含めることが基本です。

なぜモデル単体の評価では不十分か

ロボットの危険は、認識モデルの出力だけで決まりません。対象物、人との距離、作業空間、速度、力、照明、センサー、通信、ソフトウェア構成などが組み合わさって、実際のリスクになります。平均精度やテストデータ上の結果だけでは、どの環境で、どの失敗が起こり得て、失敗時に何が動作を制限するのかを説明できません。

ISO 12100:2010は、意図する使用と合理的に予見可能な誤使用を含む機械の限界を定め、危険源の同定、リスクの見積もり・評価、リスク低減を反復する一般原則を示しています。学習機能を含む場合も、まずこの分析を出発点にし、AI固有の不確実性、データやモデルの変更、導入後の監視をライフサイクルへ接続します。

安全ケースを構成する枠組み

安全ケースとは、安全性に関する主張と、それを支える論拠・証拠を構造化したものです。GSN（Goal Structuring Notation）では、ゴール、戦略、コンテキスト、前提、証拠などを用いて、主張がどの条件で成立するかを表します。ただし、GSN自体はモデル精度や残留リスクの合格値を定めません。

参照する枠組みの役割は分けて扱います。ISO 12100は機械の危険源分析とリスク低減、IEC 61508は安全関連の電気・電子・プログラマブル電子システムの安全ライフサイクルや検証、ISO 10218-1:2011は産業用ロボットの安全要求を扱います。NIST AI RMF 1.0はGovern、Map、Measure、Manageの4機能でAIリスク管理を整理し、ISO/IEC 23894:2023はAIのリスク特定、分析、評価、処置、監視のガイダンスを示します。

これらは同じ適用範囲の規格ではありません。AIリスク管理の文書は一律の合格閾値や認証を定めず、ISO 10218-1もサービスロボットや移動ロボット、特定の学習機能へそのまま適用できるとは限りません。対象機械、用途、法域、国内採用版との対応を確認する必要があります。

最上位主張から証拠まで分解する

実務では、次の順に整理するとレビューしやすくなります。

運用範囲と前提：許容される環境、対象物、人との距離、速度・力の上限、センサー状態、通信条件、モデルの適用範囲を定める。
危険源と安全目標：誤認識、制御の逸脱、センサー異常、通信断、適用範囲外の入力などを危険源として整理し、避けるべき危害や安全目標へ結び付ける。
安全要求：機能要求、性能要求、環境制約、フェイルセーフ要求、監視要求、変更管理要求を記述する。
実装上の防護：学習モデル、制限器、監視器、安全関連制御系、停止・減速・退避などが、どの要求に対応するかを明確にする。
検証と妥当性確認：要求ごとに方法、条件、合格基準、結果を記録する。解析、単体試験、シミュレーション、シナリオ試験、実機試験、故障注入などを要求の性質に応じて使い分ける。
残留リスクと運用監視：残った前提、監視指標、インシデント対応、再評価条件、変更時の停止条件を明示する。

これは各規格が定める一律の文書一覧ではなく、対象システムに合わせた実務上の構成方法です。

flowchart TD
  G["最上位主張：定義した運用範囲と制約の中で、機能が許容可能な安全性を満たす"]
  C["運用範囲・前提：環境、対象物、人との距離、速度・力、照明、センサー、通信、モデル適用範囲"]
  H["危険源と安全目標：誤認識、制御逸脱、センサー異常、通信断、適用範囲外入力"]
  R["安全要求：機能、性能、環境制約、フェイルセーフ、監視、変更管理"]
  P["実装上の防護：学習モデル、制限器、監視器、安全関連制御系、停止・減速・退避"]
  V["検証・妥当性確認：単体試験、シミュレーション、シナリオ試験、実機試験、故障注入、解析"]
  L["残留リスクと運用監視：前提、監視指標、インシデント対応、再評価条件、変更時の停止条件"]
  E["証拠：試験結果、解析記録、要求との対応、構成管理情報"]
  G --> C
  G --> H
  H --> R
  C --> R
  R --> P
  R --> V
  P --> V
  V --> E
  V --> L
  L --> E

安全ケースを、成立条件と防護、検証、残留リスク、証拠まで追跡可能な形に分解した構造です。GSN風の概念図であり、特定の合格基準を定めるものではありません。

トレーサビリティを証拠の中心に置く

検証結果を安全ケースの証拠として利用するには、その結果を生んだ構成を固定できなければなりません。要求仕様、データセット、ラベル、モデル、ソフトウェア、推論ハードウェア、テスト条件、判定結果をライフサイクル成果物として版管理し、相互に追跡可能にします。ISO/IEC 5338:2023は、AIシステムの概念化、開発、検証・妥当性確認、導入、運用、保守、廃止を含むライフサイクルプロセスを扱います。

ROS 2のセキュリティ設計入門：DDS-Securityの適用範囲と性能評価

Sat, 26 Sep 2026 13:45:27 +0900

ROS 2の通信保護では、暗号化の有無だけでなく、どの情報を誰に許可するかまで設計する必要があります。

先に結論

ROS 2の通信を保護する場合は、SROS 2を入口としてDDS-SecurityをDDSのDomainParticipantとRTPS通信に適用します。ただし、すべての通信を一律に暗号化するのではなく、発見情報、RTPSメタデータ、トピックデータごとに保護レベルを選ぶことが重要です。

性能は「有効・無効」の二択では評価できません。認証のみ、完全性保護、暗号化、発見情報の保護などを段階的に比較し、採用するROS 2ディストリビューション、RMW実装、DDS実装、メッセージ特性、ハードウェアを固定して測定します。運用負荷も、初期設定だけでなく証明書・秘密鍵・権限ファイルの更新や障害対応まで含めて判断します。

なぜ適用範囲の設計が必要か

ロボットでは、センサーデータ、制御指令、状態情報などがDDSを通じて交換されます。通信相手が正しい参加者か、特定のノードにpublishやsubscribeを許すか、内容を第三者から読めなくするかは別々の課題です。認証に成功した参加者へ、すべてのトピックへのアクセスを許可する必要はありません。

また、「暗号化を有効にした」という説明だけでは保護範囲が分かりません。DDS-Securityでは、発見情報、liveliness、RTPSメタデータ、トピックデータに異なる保護レベルを指定できます。署名にとどめるか暗号化まで行うかは、機密性、完全性、性能、運用負荷を合わせて決めます。

用語と役割

DDS-Securityは、DDSのDomainParticipantとRTPS通信層に適用されるセキュリティモデルです。認証、アクセス制御、暗号、ロギングなどをプラグインとして構成します。

認証は参加者の識別と相互認証を担います。アクセス制御、つまり認可は、ドメイン、トピック、パーティションなどについて、その参加者がどの操作を実行できるかを判定します。暗号プラグインは、通信の暗号化や完全性保護を担当します。認証できたことと、アクセスを許可することは同じではありません。

ROS 2ではSROS 2がDDS-Securityを利用するツールと統合機能を提供します。キーストアに証明書、秘密鍵、ガバナンス文書、権限文書などを格納し、エンクレーブをノードの論理的なセキュリティ境界として利用します。実行時には、キーストア、エンクレーブ、セキュリティ戦略などを環境変数やCLIで指定します。

内部の仕組みと適用範囲

処理の流れは、参加者の起動、証明書の検証と認証ハンドシェイク、権限検証、発見情報の保護、エンドポイントの許可、トピックデータの署名または暗号化という順序で整理できます。ガバナンス設定はドメインや保護対象の方針を定め、権限ファイルは参加者やエンクレーブ単位のアクセス範囲を定めます。

flowchart LR
  node["ROS 2ノード"] --> rclrmw["rcl / RMW"]
  rclrmw --> dp["DDS DomainParticipant"]

  subgraph sec["DDS-Security"]
    auth["認証プラグイン"]
    access["アクセス制御プラグイン"]
    crypto["暗号プラグイン"]
  end

  dp --> auth
  dp --> access
  dp --> crypto

  subgraph ks["キーストア"]
    cert["Identity certificate"]
    key["Private key"]
    gov["Governance文書"]
    perm["Permissions文書"]
  end

  cert --> auth
  key --> auth
  gov --> access
  perm --> access

  auth --> participant["参加者の識別・相互認証"]
  access --> endpoint["ドメイン・トピック・パーティションの権限"]
  crypto --> discovery["発見情報・RTPSメタデータ"]
  crypto --> topic["トピックデータ"]

  participant --> rtps["DDSを経由するRTPS通信"]
  endpoint --> rtps
  discovery --> rtps
  topic --> rtps

  bypass["DDSをバイパスする経路\n独自トランスポート・実装依存のプロセス内通信など"] -.-> out["DDS-Securityの適用範囲外の可能性\n実装仕様の確認が必要"]

ROS 2のDDS通信に対するDDS-Securityの適用範囲と、キーストア資材およびDDSを経由しない経路の扱いを示します。

DDS-Securityで自動的に保護されるのは、基本的にDDSを経由する通信です。独自トランスポートや、実装によってDDS通信をバイパスするプロセス内通信・共有メモリ経路まで保護されるとは限りません。コンポーネントコンテナや共有メモリを使う場合は、実際の経路をRMWとDDS実装の仕様で確認します。

ロボット推論をエッジとクラウドに分担させる設計判断

Sun, 20 Sep 2026 23:22:26 +0900

ロボットのクラウド利用は、計算資源の問題だけでなく、通信が途切れた瞬間の振る舞いまで含めて考える必要があります。

先に結論

ロボットのクラウド推論は、通信遅延や切断が起きても安全性と制御性能を損なわない、非同期・非安全系の処理に限定するのが基本です。アクチュエータの最終制御、緊急停止、衝突回避の最終判断、ウォッチドッグ、最低限の状態推定はロボット上に残します。一方、学習、ログの再処理、フリート分析、モデルや地図の配布、遅延を許容できる高位計画はクラウドと相性がよい領域です。

クラウドを制御ループの一部に使う場合は、単に平均遅延を測るだけでは不十分です。許容遅延、ジッター、結果の有効期限、タイムアウト、通信断時の動作、古い結果の破棄条件、ローカルフォールバックをタスクごとに定義し、故障時の挙動まで検証する必要があります。

なぜ配置の境界が問題になるのか

クラウドロボティクスは、ロボット単体では不足する計算資源や知識をクラウド側で補完し、遠隔計算やデータ共有を利用する考え方です。大規模な計算や複数ロボットのデータを集約できる一方、通信接続、遅延、帯域幅、信頼性、セキュリティが制約になります。

エッジコンピューティングは、データ生成源の近くに計算資源を置く方式です。クラウドへの往復を減らし、遅延、通信量、クラウド接続への依存を抑えやすい点に意味があります。プライバシーの観点でも、すべてのセンサーデータを遠隔へ送らず、近傍で処理する構成を検討できます。

つまり設計上の対立は、クラウドかエッジかの二択ではありません。計算資源や知識共有を得る代わりに通信へ依存するか、応答性と接続独立性を優先してロボットや近接エッジへ処理を置くか、というトレードオフです。

前提となる用語

ここでいうオンデバイスは、センサーやアクチュエータを持つロボット本体で処理することです。構内エッジや地域エッジは、ロボットに近いネットワーク上の計算資源を指します。クラウドは、ロボットから離れた計算・ストレージ基盤です。

また、安全系とは、処理の遅延や失敗が安全な停止や危険回避に直接影響する機能を指します。非安全系とは、結果が遅れたり利用できなかったりしても、ロボットの安全な基本動作を直ちに損なわない処理です。

内部の仕組みと分担

安全系の基本経路は、センサー、ローカル状態推定、衝突監視、ローカル制御器、アクチュエータという閉ループにします。クラウドへの接続状態に左右されず、最低限の状態推定と停止判断を継続できることが前提です。リアルタイム処理では、予測不能なメモリ割り当て、ブロッキング、非決定的な処理を避け、期限内に完了できる実装が重視されます。

クラウド側には、センサーデータの要約やログ、学習用データ、フリート全体の分析を送ります。クラウド推論の結果は、高位計画やモデル更新などに利用できます。ただし、結果を受け取っただけで直ちにアクチュエータを動かすのではなく、期限内か、現在の状態と整合するかを確認し、無効なら破棄してローカル側へ戻します。

画像理解や意味認識のように計算負荷が高い処理はクラウドに置ける場合があります。しかし閉ループで利用するなら、ロボット側に低遅延の代替処理、安全な停止、または低機能モードを用意できることが条件です。

flowchart TD
  A["処理対象"] --> B{"安全性に直接影響するか"}
  B -->|"はい"| C["オンデバイスに配置"]
  B -->|"いいえ"| D{"許容遅延・ジッター・有効期限が厳しいか"}
  D -->|"はい"| E["オンデバイスまたは近接エッジに配置"]
  D -->|"いいえ"| F["クラウド配置を検討"]
  F --> G["タイムアウトを定義"]
  G --> H["期限切れの結果を破棄"]
  H --> I["ローカルフォールバックまたは安全停止"]

処理の安全性、許容遅延、ジッター、結果の有効期限を基準に、オンデバイス・近接エッジ・クラウドの配置を判断する。

処理カテゴリ別の配置

処理	基本配置	理由・条件
アクチュエータ制御	オンデバイス	通信遅延や切断を前提にできない
緊急停止・衝突回避の最終判断	オンデバイス	安全動作をローカルで完結させる
ウォッチドッグ	オンデバイス	接続状態に依存せず異常を検出する
最低限の状態推定	オンデバイス	制御継続に必要な状態を確保する
高負荷の画像理解・意味認識	エッジまたはクラウド	代替処理や安全停止を用意できる場合に限定
高位計画	エッジまたはクラウド	結果の遅延を許容できる場合
ログ再処理・フリート分析	クラウド	即時の安全動作を決めない
学習・モデルや地図の配布	クラウド	集約計算と配布に向く

通信品質に応じたフォールバック

クラウド推論を採用する処理には、まず結果の有効期限を設定します。期限を過ぎた結果は、通信が復旧して届いたとしても現在の状態に対して古い可能性があるため、破棄します。要求を送ってから一定時間以内に返らない場合も、待ち続けるのではなく、代替モデル、速度制限、低機能モード、安全停止、手動介入など、あらかじめ定めた動作へ遷移させます。

ロボットのセンサー異常処理設計：検出から安全な縮退運転まで

Fri, 15 May 2026 01:02:32 +0900

センサーが値を返し続けているときほど、通信監視だけでは異常を見逃しやすい点が気になります。

先に結論

ロボットのセンサー異常は、単一の監視箇所に集約せず、通信・データ取得、値の妥当性、状態推定、センサー間整合性、行動・安全監視の複数層で検出する設計が適しています。各層で観測できる異常が異なるためです。

欠損、異常値、不一致は同じ故障として扱いません。欠損や遅延は鮮度低下、範囲外や急激な外れ値は測定拒否、センサー間不一致は比較と故障候補の隔離として扱います。安全機能を維持できるなら速度や機能を制限し、代替観測が使えなければ停止へ移行します。

なぜ検出層を分けるのか

センサーが停止した場合、メッセージの到着間隔や通信相手の生存性を監視する層で検出しやすくなります。しかし、センサーが値を送り続けていても、固定値や環境に対してもっともらしい誤値を出すことがあります。通信が正常でも、値の意味まで正常とは限りません。

逆に、状態推定層で観測値を拒否できても、複数センサーの不一致や、安全機能に必要な観測が残っているかは別途確認が必要です。異常検出と行動決定を分け、どの層がどの種類の異常を検出したかを診断情報として伝える構成が扱いやすくなります。

前提となる用語

本稿では、欠損をメッセージが届かない、または許容される鮮度を失った状態、範囲外を扱える値域から外れた状態、外れ値を推定状態などから大きく乖離した値、不一致を複数センサーや推定結果が整合しない状態とします。

ROSの診断メッセージ仕様であるREP-107は、診断状態をOK、WARN、ERROR、STALEに分類します。ただし、各状態で停止するか、速度を制限するか、継続するかまでは規定していません。診断状態と行動ポリシーは、システム側で対応付けます。

各層の検出責務

通信・データ取得層

メッセージが期待周期で届くか、通信相手が生存しているかを確認します。ROS 2のDeadline QoSは、連続するメッセージ間の許容最大時間を定義し、期限超過をイベントとして検出できます。Liveliness QoSは、パブリッシャーなど通信相手の生存性を監視します。

これらは到着間隔や生存性を扱う機能であり、値の妥当性やタイムスタンプの意味まで検証するものではありません。

センサー値の妥当性層

型、値域、更新状態、センサー固有の自己診断などを確認し、明らかに利用できない値を上位へ渡さない層です。ただし、範囲内に収まる固定値や誤値は、この検査だけでは十分に検出できません。

状態推定層

推定状態と観測値の差を調べます。robot_localizationの資料では、マハラノビス距離による拒否しきい値を設定し、予測状態から大きく外れたpose、twist、accelerationの測定値を拒否できます。通信が正常でも、推定と整合しない観測を取り込まないための方法です。

整合性・安全監視層

冗長センサーがあれば、複数入力の整合性を比較できます。PX4には、センサーの状態や整合性を監視し、投票で使用センサーを選び、不健全なセンサーを投票から除外し、必要に応じてフェイルセーフへ移行する実装があります。

Nav2 Collision Monitorには、入力が一定時間届かない場合にソースをstaleとして扱い、速度指令の制限や停止へ移行させる実装があります。いずれも特定のソフトウェア構成に依存する実装例であり、すべてのロボットへそのまま一般化できるわけではありません。

flowchart LR
  A["センサー入力"] --> B["通信・データ取得層\n到着周期・生存性・タイムアウト"]
  B --> C["センサー値の妥当性層\n型・範囲・更新状態"]
  C --> D["状態推定層\n予測状態との差・外れ値拒否"]
  D --> E["センサー間整合性監視層\n冗長入力・推定結果の比較"]
  E --> F["行動・安全監視層\n安全機能の可用性を判定"]

  B -. "欠損・遅延・配信停止" .-> G["STALEとして診断"]
  C -. "範囲外" .-> H["異常値を上位へ渡さない"]
  D -. "推定と大きく乖離" .-> I["測定値を推定更新から除外"]
  E -. "センサー間不一致" .-> J["故障入力を隔離・冗長系を検討"]

  F --> K{ "安全機能を維持できるか" }
  K -->|"維持できる"| L["速度・加速度・可動範囲・自律機能を制限"]
  K -->|"代替観測を利用できる"| M["冗長センサーへ切替"]
  K -->|"必要な観測を確保できない"| N["停止"]

  G --> F
  H --> F
  I --> F
  J --> F

センサー異常を単一の監視ノードで判定せず、検出責務を複数層に分けて行動ポリシーへ結び付ける構成を示します。

異常種別と行動の比較

異常の種類	主な検出層	処理の例	行動の例
欠損・到着間隔超過	通信・安全監視	STALE相当として鮮度を評価	速度制限、機能停止、停止
範囲外	値の妥当性	入力から除外	代替入力の検討、継続可否判定
急激な外れ値	状態推定	イノベーションや距離で拒否	推定更新から除外、機能制限
センサー間不一致	整合性監視	比較、故障候補の隔離	冗長系切替、必要なら停止
安全観測の喪失	行動・安全監視	安全機能の可用性を評価	保守的状態、停止

表の状態名と行動の対応は、REP-107の一般規則ではありません。許容時間や安全上の意味を、対象システムごとに定義する必要があります。

Physical AIのモデル更新を監視する：評価・カナリアリリース・ロールバック設計

Sun, 05 Apr 2026 00:41:46 +0900

ロボットAIの更新では、精度の改善がそのまま安全な運用を意味するのかが気になります。

先に結論

Physical AIのモデル更新は、オフラインの認識精度だけで合否を決めてはいけません。更新前に固定シナリオ、シミュレーション、実機リプレイなどで基準性能と安全限界を記録し、更新後はタスク結果、安全イベント、入力変化、推論・通信の健全性を継続的に比較します。リリースはシャドー実行から低リスクのロボットや作業へ段階的に広げ、異常時には独立した安全系で停止またはフォールバックしたうえで、モデルだけでなく関連する実行環境を含む既知の正常版へ戻します。

なぜモデル更新の監視が難しいのか

Webサービスなら、エラー率やレイテンシーをリクエスト単位で追跡しやすい一方、ロボットの性能は環境、個体、作業シナリオ、センサー状態、通信状態に左右されます。入力分布が変わってもタスク結果が維持される場合があり、反対に入力変化が小さくても制御遅延やキャリブレーションのずれが危険動作につながる場合があります。

NISTのAI RMF 1.0も、AIのリスクと性能はデプロイ前だけでなく運用中も測定・監視し、問題への対応や変更管理を行う考え方を示しています。したがって、更新を「モデルファイルの交換」ではなく、変更を観測し、止め、戻せる運用プロセスとして設計する必要があります。

前提となる用語

データセットシフトは、学習時と運用時でデータの分布が変わる現象です。共変量シフト、事前確率シフト、概念シフトなどに分けられます。ただし、入力や予測の分布変化を検出しただけでは、タスク性能の低下や安全リスクを直接証明できません。

カナリアリリースは、新版を一部の対象に限定して投入し、旧版との差を確認してから展開範囲を拡大する方法です。ロボットでは、単純なリクエスト比率ではなく、ロボット個体、拠点、作業シナリオ、危険度を単位にするほうが安全側です。

シャドー実行は、新版を判断や制御への作用なしに動かし、出力や遅延を観測する段階です。実際の作業へ影響を与えない構成にできるなら、低リスクな初期評価になります。

監視すべき指標は一層では足りない

監視項目は、少なくとも次の層に分けて設計します。

入力層：センサー分布、欠損、異常値、OOD（学習分布外）兆候
モデル層：信頼度、予測分布、アクションの飽和や異常な偏り
タスク層：タスク成功率、完了時間、人手介入率
安全層：衝突、ニアミス、接触力や軌道の制約違反
システム層：推論遅延、通信欠落、QoSのdeadline違反、liveliness

これらは更新前の基準値および既知の正常版と比較します。成功率が維持されていても、介入率や推論遅延が増えていれば、将来の失敗や安全余裕の縮小を示す可能性があります。逆に入力ドリフトだけを理由に直ちにロールバックするのではなく、タスク、安全、システムの観測と組み合わせて判断します。共通の閾値や必要サンプル数は製品ごとに異なるため、固定の標準値として扱ってはいけません。

flowchart LR
  subgraph input["入力層"]
    I1["センサー分布"]
    I2["欠損・異常値"]
    I3["OOD兆候"]
  end
  subgraph model["モデル層"]
    M1["信頼度"]
    M2["予測分布"]
    M3["アクションの飽和・偏り"]
  end
  subgraph task["タスク層"]
    T1["タスク成功率"]
    T2["完了時間"]
    T3["人手介入率"]
  end
  subgraph safety["安全層"]
    S1["衝突"]
    S2["ニアミス"]
    S3["接触力・軌道の制約違反"]
  end
  subgraph system["システム層"]
    Y1["推論遅延"]
    Y2["通信欠落・Deadline違反"]
    Y3["Liveliness"]
  end
  I1 --> G["旧版・基準値との比較"]
  I2 --> G
  I3 --> G
  M1 --> G
  M2 --> G
  M3 --> G
  T1 --> G
  T2 --> G
  T3 --> G
  S1 --> G
  S2 --> G
  S3 --> G
  Y1 --> G
  Y2 --> G
  Y3 --> G
  G --> H["リリース・安全ゲート"]
  H --> D["継続監視・展開判断"]

入力分布やモデル出力だけでなく、タスク結果、安全イベント、システム健全性を旧版および更新前の基準値と比較する。

更新から全体展開までの流れ

まず、モデル、前処理・後処理、設定、制御ソフト、依存ライブラリ、キャリブレーション、実行環境を識別できる形で記録します。その組み合わせで固定シナリオと実機・シミュレーションの評価を行い、品質ゲートと安全ゲートを分けて判定します。スループットやコストの改善があっても、衝突、危険動作、安全制約違反を防ぐゲートを通過しなければ展開しません。

AIロボットの安全設計：非常停止とAI判断を分離する理由

Thu, 15 Jan 2026 00:01:44 +0900

編集コメント：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への依存	設計・検証の焦点
非常停止	人間	危険な機能を優先的に停止	依存させない	常時利用可能性、優先性、リセット後の再起動防止
保護停止	保護センサや安全ロジック	検知した危険条件から安全状態へ移行	安全センサを使う場合は安全系として評価	故障検出、安全状態、要求性能
通常停止	運用者やタスク制御	通常の動作終了	通常制御に依存	停止手順と運用上の再開条件
AIによる停止要求	AIの危険検知	追加のリスク低減層	認識・推論に依存	未検知、誤検知、停止要求失敗時の挙動

物理分離か、機能的な分離か

設計判断では、まず「別CPUかどうか」ではなく、安全機能がAI系の故障に妨げられないかを確認します。AIの通常制御と安全関連制御を別の機能として定義し、入力、処理、出力、故障時挙動、検証責任を分けることが出発点です。