見出し画像

ロボットが止まったとき、どうすれば元に戻せるのか？ROS 2、NVIDIA、安全設計、監視・更新・復旧から考えるフィジカルAI企業の条件

一般財団法人 木村潤 記念財団

展示会で、ロボットが箱を持ち上げました。
実証実験で、決められた経路を往復できました。
担当者は動画を撮り、社内では「これなら現場でも使えそうだ」と期待が高まります。

ところが、本番稼働を始めた翌週、搬送途中でロボットが止まりました。

センサーが人や障害物を検知したのでしょうか。
通信が切れたのでしょうか。
地図と実際の配置がずれたのでしょうか。

それとも、人との接触を避けるため、安全機能が正しく働いたのでしょうか。

問題は、ロボットが止まったことだけではありません。

誰が状態を確認するのか。
どの記録を見れば、原因を追えるのか。
現場の担当者は、その場で再起動してよいのか。
メーカー、システムインテグレーター、AI開発会社、設備管理者のうち、誰が判断するのか。

そして、ロボットが再び動けるようになったとして、止まっていた業務をどこから再開すればよいのでしょうか。

フィジカルAIを評価するとき、私たちはロボットが何をできたかに目を向けがちです。
けれども、現場で長く使うために問われるのは、一度動かせることだけではありません。

異常に気づく。
事前に設計された安全な状態へ移す。
そのときの情報を残す。
原因を切り分ける。
復旧してよいかを判断する。
ロボットだけでなく、業務全体を安全に再開する。

フィジカルAI企業の実力は、ロボットが止まったあとに見えてきます。


ロボットの「止まる」は、一つではない

「ロボットが止まった」と聞くと、故障を想像するかもしれません。
しかし、停止には複数の意味があります。

予定していた作業を終えて止まった。
経路上へ人が入り、衝突を避けるために止まった。
センサーの値が想定範囲を外れ、安全側へ移るために止まった。
通信が途切れ、次の指示を受け取れなくなった。
ソフトウェアの一部が異常終了した。
バッテリー残量や温度が基準を超え、動作を制限した。
倉庫管理システムなどから次の仕事が届かず、待機している。
人が非常停止装置を作動させた。

外から見れば、どれも「動いていないロボット」です。
しかし、必要な対応は異なります。

安全機能が正しく働いた停止なら、理由を確認せずに再起動することはできません。
通信断なら、通信が戻っただけで、途中の仕事を再開してよいとは限りません。
荷物を持った状態で停止したなら、その荷物や周辺設備の状態も確認する必要があります。
非常停止も重要です。

ただし、非常停止装置を解除しただけで、安全に作業を再開できるとは限りません。

ISO 13850は機械の非常停止機能に関する機能要件と設計原則を扱います。一方、ISO 10218シリーズでは、産業用ロボット本体の安全と、ロボットを現場へ統合し、試運転、運用、保守する際の安全が分けて扱われています。

再開する前には、少なくとも三つを分けて確認する必要があります。

危険の原因が取り除かれたか。
ロボットと周辺設備が、再び動かせる状態か。
途中で止まった業務を、どこから再開してよいか。

ここで重要なのは、「止まらないロボット」を作ることではありません。
危険や異常を見落とし、動き続けるロボットが安全とは限らないからです。

なぜ止まったのかを説明できるか。
そして、ロボットと業務を安全に戻せるか。

見るべきなのは、この二つです。

停止は復旧工程の始まりです。ロボットの再起動だけでなく、荷物、設備、上位システム、人の作業まで確認して、業務へ戻す必要があります。

ROS 2は、何をつなぎ、何を管理するのか

フィジカルAIやロボットについて調べると、ROSという名前をよく見かけます。
ROSは「Robot Operating System」の略ですが、WindowsやmacOSのような基本ソフトそのものではありません。

ロボットの機能を分割し、それぞれを通信させ、組み合わせるためのライブラリ、ミドルウェア、ツール、開発環境の集まりと考える方が実態に近いでしょう。

たとえば、

  • 車輪や関節を動かす機能

  • カメラや距離センサーから情報を受け取る機能

  • 現在位置を推定する機能

  • 目的地までの経路を計算する機能

を、別々のソフトウェア機能として構成できます。

ROS 2には、ソフトウェア機能を「未設定」「非アクティブ」「アクティブ」「終了」といった既知の状態で管理するLifecycleの考え方もあります。公式の設計文書では、この仕組みによって、すべての構成要素が正しく準備された後に動作を始めたり、ノードを再起動・交換したりしやすくすることが説明されています。

ただし、ここには重要な区別があります。

ソフトウェア機能を非アクティブにすることと、機械を安全な状態へ移すことは同じではありません。

ソフトウェア上で機能を止めても、

  • モーターの動力

  • ブレーキ

  • 保持している荷物

  • 周辺設備

  • 人との距離

  • 再起動時の危険

まで自動的に管理されるわけではないからです。

ROS 2を使えば、機能を分け、つなぎ、調べやすくなります。

けれども、

  • 現場で何を危険と判断するか

  • どの状態へ移せば安全なのか

  • 誰が再起動を承認するか

  • 故障時に誰が現地へ行くか

  • 止まっていた業務をどう再開するか

までは、ROS 2が決めてくれません。

ROS 2は重要な開発基盤です。

基盤を使えることと、現場を引き受けられることの間には、まだ多くの設計が残っています。

NVIDIAは開発を速める。現場の運用は別に設計する

フィジカルAIの文脈では、NVIDIAの名前も頻繁に登場します。
ここでも、「NVIDIAを使う」という言葉だけでは、何を指しているのか分かりません。

NVIDIAのロボティクス関連基盤には、それぞれ異なる役割があります。

Isaac Simは、物理的な挙動を含む仮想環境で、AIロボットを設計、シミュレーション、テスト、学習するための基盤です。Isaac ROSは、ROS 2を利用するロボット向けに、認識、画像処理、ナビゲーションなどを高速化するソフトウェア群です。Jetsonは、ロボット本体やエッジ側でAI処理を実行する計算基盤として使われます。

NVIDIAは、複数台への仕事の割り当てや進捗管理を支援するMission DispatchとMission Clientも公開しています。ただし、これはフリート管理システムとROS 2ロボットの間で、仕事を割り当て、追跡するための構成要素です。現場の業務や安全、保守のすべてを管理する仕組みではありません。

これらは、ロボット開発を大きく前進させる基盤です。
しかし、現場の業務そのものを自動的に設計するわけではありません。

倉庫で箱を運ぶロボットを導入するとします。
認識処理や経路計画が動いても、

  • どの箱を先に運ぶか

  • 通路が塞がったときにどうするか

  • 人とロボットの仕事をどう分けるか

  • ロボットが止まった間、業務をどう代替するか

  • 荷物が破損していないか誰が確認するか

  • 復旧後に途中の指示を再実行するか

は、別に決める必要があります。

強い基盤を使うことは重要です。
そのうえで問われるのは、

その基盤を使って何を作り、どこまでの失敗を引き受けるのか

ということです。

ROS 2やNVIDIA Isaacは、ロボット開発を支える重要な基盤です。一方、業務、安全、監視、代替運用、保守、復旧、責任分界は、導入する現場ごとに設計する必要があります。

原因を追うには、止まる前の状態が必要になる

ロボットが停止したあと、画面に「エラー」と表示されるだけでは、原因を十分に追えません。

必要なのは、その瞬間だけのエラーコードではなく、止まる前後に何が起きていたかを復元できる情報です。

最低限でも、次の情報が関係します。

  • 発生した時刻

  • ロボットの識別番号

  • ソフトウェアの版

  • AIモデルの版

  • 設定値

  • センサーが捉えていた情報

  • ロボットが出していた制御指示

  • 通信状態

  • バッテリーや温度

  • 人が行った遠隔・手動操作

  • 倉庫や製造の管理システムから届いた指示

  • 安全装置が作動した理由

こうした外部から得られる情報を使って、システム内部で何が起きたかを調べられる状態を、IT運用では「可観測性」と呼びます。

単にログファイルを保存することではありません。

複数の機器やシステムで起きた出来事を、同じ時間軸の上で結びつけられる必要があります。

カメラが障害物を検知した。
経路計画が別のルートを選んだ。
倉庫管理システムから新しい搬送指示が届いた。
安全機能が停止を要求した。

それぞれの機器の時計がずれていれば、出来事の順番を正しく復元できないことがあります。

ROS 2には、実行状況や通信の流れを追跡するためのros2_tracingがあります。公式リポジトリでは、ROS 2の中核パッケージへトレース用の計測機能を提供し、起動時やコマンドラインから記録を設定できると説明されています。

ただし、ロボットの内部記録だけで十分とは限りません。

ロボットの外側には、

  • 設備を制御するPLC

  • 倉庫管理システム

  • 製造実行システム

  • 企業の基幹システム

  • クラウド

  • 安全装置

  • 人の作業と連絡

があります。

原因が複数のシステムをまたぐ場合、ロボットのログだけを見ても分からないことがあります。

さらに、すべての映像やセンサーデータを無制限に保存すればよいわけでもありません。

詳しく残すほど原因を追いやすくなりますが、

  • 保存容量

  • 通信費

  • 顧客の機密情報

  • 作業者の映像や音声

  • 閲覧できる人の権限

  • 保存期間

も問題になります。

何を常時記録するのか。
異常が起きた前後だけ詳細なデータを残すのか。
誰が閲覧できるのか。
いつ削除するのか。

これらも、ロボットの継続運用を設計する仕事です。

ロボットの中を見るだけではなく、業務全体の出来事を、必要な範囲でつなげて見られるか。

復旧の速さは、停止する前に何を記録する設計にしていたかで変わります。

SIL・HIL・実機試験は、何を分担するのか

本番で起こるすべての問題を、実機だけで試すことは現実的ではありません。

危険な異常を何度も起こすことはできません。

大量の条件を試すには、時間も設備も必要です。

そのため、ロボット開発では、シミュレーションと実機を組み合わせます。

SIL――ソフトウェア上で繰り返し試す

SILは、Software in the Loopの略です。

実際の制御装置やロボットを使わず、ソフトウェアや制御ロジックを仮想環境で試します。

障害物の位置を変える。
照明条件を変える。
センサーの値を意図的に乱す。
通信を遅らせる。

こうした条件を大量に反復できることが利点です。

HIL――実際の計算機を仮想環境へつなぐ

HILは、Hardware in the Loopの略です。

実際にロボットへ搭載する計算機や制御装置を、シミュレーターへ接続します。

ソフトウェア上では問題なく動いても、対象機器では処理が間に合わないことがあります。

通信周期や入出力の挙動が、想定と異なる場合もあります。

Isaac Simの公式資料では、シミュレーションが大きな開発システムの一部として利用され、ロボット、環境、センサー、ROS 2などを組み合わせて検証する構成が説明されています。

実機試験――物理世界の例外を確かめる

それでも、仮想環境だけでは分からないことがあります。

床の摩擦。
モーターや部品の振動。
センサーの汚れ。
配線の接触。
温度上昇。
部品の摩耗。
ロボットごとの個体差。
人の予測しにくい動き。

これらは、実際の機械と現場で確かめる必要があります。

SIL、HIL、実機試験は、どれか一つを選ぶものではありません。

SILで多くの条件を試す。
HILで対象機器との接続や処理を確かめる。
実機で物理世界の差を確認する。
実機で見つかった問題を、再びシミュレーションへ戻して再現する。

重要なのは、三つを一方向の工程ではなく、往復する検証の仕組みとして持つことです。

シミュレーションは、実機を不要にするためではありません。
実機で確かめるべき範囲を、より深く、より安全に絞り込むために使います。

SIL、HIL、実機試験は、どれか一つを選ぶものではありません。実機で見つかった問題をシミュレーションへ戻し、繰り返し確かめる仕組みが必要です。


更新できることより、戻せることが重要になる

ロボットは、一度導入したら同じ状態で動き続ける機械ではありません。

ソフトウェアの不具合を修正します。
AIモデルを更新します。
センサーの設定を変更します。
セキュリティ上の問題へ対応します。
業務変更に合わせて、経路や作業手順を変えます。

ネットワークを通じて更新するOTAは、複数台のロボットを運用するうえで重要になります。
ただし、ネットワーク経由で配布できても、安全に更新できるとは限りません。

新しいAIモデルを配ったところ、認識精度は上がったものの処理が重くなり、動作のタイミングへ影響するかもしれません。

一部のロボットだけ、センサーや計算機の世代が異なるかもしれません。

ロボット側のソフトウェアは更新できても、倉庫管理システムや設備制御との通信仕様が合わなくなる可能性もあります。

そこで必要になるのが、段階的な配信です。

最初に試験機へ適用する。
次に、限定した一部の機体へ適用する。
正常性を確認したうえで対象を広げる。
問題があれば、配信を止める。

ただし、「前のバージョンへ戻せばよい」とも限りません。

AIモデル、設定、データ形式、ファームウェア、周辺システムが同時に変わっていれば、ソフトウェアだけを旧版へ戻しても整合しない場合があります。

さらに、

  • 更新内容が正規の提供元から届いたものか

  • 誰が更新を承認したか

  • 誰が配信を実行できるか

  • 更新前にどの構成で動いていたか

を確認できなければ、戻す判断もできません。

ロールバックは、戻るボタンを作ることではありません。

どの構成へ、どの順番で戻せば、安全に業務を再開できるのかを、更新前に設計しておくこと。

更新は、新しい機能を入れる工程であると同時に、以前の安定した状態へ戻れることを確かめる工程でもあります。

人が助けることを、隠さずに測る

ロボットが自律的に動く映像を見ると、人が介入しないことが完成形のように感じます。

けれども、実際の運用では、人がロボットを助ける場面があります。

遠隔で次の動作を指示する。
カメラ映像を見て、進行可能か判断する。
現地で障害物を動かす。
停止した機体を安全な場所へ移す。
部品を交換する。

問題は、人が助けたかどうかではありません。

その人手が、どれだけ必要なのかです。

見るべき指標には、たとえば次があります。

  • 何回の作業に一度、介入が必要になるか

  • 一回の介入に何分かかるか

  • 遠隔対応で済むか、現地対応が必要か

  • 一人の担当者が何台を支援できるか

  • 介入後に自律動作へ復帰できるか

  • 同じ原因で再び止まっていないか

  • 介入コストを含めても業務として成立するか

完全自律だけを成功とすると、現場で役立つ段階的な導入を見落とす可能性があります。

一方で、人間介入を隠したまま「自律運用」と説明すれば、必要な人員や費用を正しく評価できません。

どの例外を機械へ任せ、どの例外を人間へ戻すのか。

それを測定可能な形で設計する必要があります。

ロボットが戻っても、業務が戻るとは限らない

停止原因を特定し、ロボットを再起動できたとします。

それでも、業務をすぐに再開できるとは限りません。

ロボットが持っていた荷物は、正しい場所にあるでしょうか。

倉庫管理システム上では、その搬送は完了、未完了、処理中のどれになっているでしょうか。

停止している間に、人が代わりの作業を始めているかもしれません。

製造工程なら、前後の設備が別の状態へ進んでいる可能性もあります。

ロボット側が正常になっても、上位システムと現場の状態が食い違っていれば、同じ作業を二重に実行したり、必要な工程を飛ばしたりする危険があります。

そこで必要になるのが、業務復旧の設計です。

停止中の仕事を誰が引き継ぐか。
途中の荷物や製品をどう確認するか。
管理システム上の状態をどう修正するか。
ロボットなしで業務を続ける手順があるか。
予備機や保守部品があるか。
現地保守が来るまでに何時間かかるか。
作業者や次のシフトへ、何を引き継ぐか。

ロボットが再び動けることではなく、現場が安全に仕事を再開できることを、復旧の完了条件にする。

ロボットの復旧と業務の復旧を分けて考えることで、必要な体制も見えやすくなります。

一台から増えるのは、台数だけではない

PoCでは、一台のロボットを、一つの場所で、限られた担当者が見ています。

問題が起きれば、開発者がその場へ行けるかもしれません。

設定もソフトウェアの版も一つです。

ところが、導入が進むと状況が変わります。

同じ拠点で台数が増える。
異なる機種が加わる。
別のメーカーのロボットが入る。
拠点ごとに通路や設備が異なる。
ソフトウェアの版が揃わなくなる。
保守会社や担当者が変わる。
接続する倉庫管理や製造管理のシステムも異なる。

一台から増えるのは、台数だけではありません。

違いの数が増えます。

複数台を運用するには、単に地図上へロボットの位置を表示するだけでなく、

  • 仕事をどのロボットへ割り当てるか

  • 充電の順番をどうするか

  • 通路で渋滞したときにどうするか

  • 停止した機体の仕事を誰へ引き継ぐか

  • どの版がどの拠点で動いているか

  • 誰が遠隔操作できるか

  • どの保守会社がどの機体を担当するか

  • どの部品をどこに置くか

まで管理する必要があります。

Open-RMFは、複数のロボット群と、ドア、エレベーター、建物管理システムなどの物理設備の相互運用を支援する、オープンソースのモジュール型基盤です。各ロボットの安全機能や現場全体の安全性を代行するものではなく、異なるロボットや施設設備を調整する上位層の一例です。

経済産業省も、所与の環境へロボットを置くだけでなく、ユーザー側の業務フローや施設環境をロボットが利用しやすい状態へ変える「ロボットフレンドリー」な環境整備を進めています。

ロボット側だけを高度化しても、

  • 通路が狭い

  • 荷物の置き方が毎回違う

  • エレベーターと通信できない

  • 異常時の連絡先が決まっていない

といった環境では安定運用しにくくなります。

企業の運用能力を見るときは、導入台数だけでなく、

同じ人数で、何台、何機種、何拠点を、同じ品質で維持できるか。

を見る必要があります。

導入台数が増えると、機種、メーカー、ソフトウェア版、拠点、業務ルール、保守体制の違いも増えます。

誰が、停止から業務復旧までをつなぐのか

ロボットの本体メーカーは、機体と制御装置を提供します。
AI企業は、認識モデルや行動モデルを提供するかもしれません。

ROSやNVIDIAは、開発のための基盤を提供します。
倉庫管理や製造管理の事業者は、業務情報を管理します。
保守会社は、現地で部品交換や点検を行います。
導入企業は、実際の業務と作業者を管理します。

問題は、それぞれが正しく仕事をしていても、境界部分に責任が残ることです。

AIモデルは正しく物体を認識した。
ロボットも指示どおり動いた。
倉庫管理システムも正しい搬送先を送った。

しかし、実際の通路には、その時間だけ別の荷物が置かれていた。

誰か一社のシステムが悪いとは、単純には言えません。

けれども、業務は止まっています。

ここで必要になるのが、技術と業務の間を接続する役割です。

フィジカルAIの統合を担う会社には、次の仕事が求められる可能性があります。

  • 顧客業務を分解する

  • 適切なロボットやセンサーを選ぶ

  • 既存設備や業務システムと接続する

  • リスクを確認し、安全方策を設計する

  • ログと監視方法を決める

  • SIL、HIL、実機試験を組み合わせる

  • 更新とロールバックを設計する

  • 人間介入の方法を決める

  • 停止中の代替運用を決める

  • 障害時の連絡、判断、復旧手順を定める

  • メーカー、導入企業、保守会社の責任を分ける

すべてを一社で実行する必要はありません。

むしろ、ロボットメーカー、AI企業、システムインテグレーター、設備会社、導入企業が連携する方が合理的な場合もあります。

ただし、誰かが全体を見て、

どの会社が、どの状態まで責任を持つのか。

を決める必要があります。

ISO 10218-1は産業用ロボット本体を、ISO 10218-2はロボットを具体的な用途やロボットセルへ統合し、試運転、運用、保守する領域を扱っています。機体の安全設計と、現場全体の安全な統合・運用は、分けて考える必要があります。

サービスロボットについても、ISO 31101は製品安全規格ではなく、ロボットを使ったサービスを提供する組織の安全管理システムを対象としています。複数の組織が関わる場合、それぞれの役割に応じて安全管理を分担できることも示されています。

フィジカルAI時代のインテグレーターに問われるのは、機器を接続できることだけではありません。

技術、安全、業務、保守の境界をつなぎ、停止後に誰が何をするかまで設計できることです。

動かせたかではなく、戻せたかを見る

ロボットは止まります。
センサーが汚れます。
通信が切れます。
ソフトウェアに不具合が見つかります。
部品は摩耗します。
人や物の動きは、常に計画どおりではありません。

止まらないことだけを目標にすると、異常を無視して動き続ける危険もあります。
必要なのは、止まることを前提にした設計です。

異常に気づく。
事前に設計された安全な状態へ移す。
そのときの情報を残す。
原因を切り分ける。
復旧できるか判断する。
段階的に再起動する。
ロボット、上位システム、荷物、設備、人の状態を確認する。
業務へ戻す。
失敗を次の改善へつなげる。

フィジカルAI企業を見るとき、ロボットが一度動いた映像だけでは分からないことがあります。

見るべきなのは、次の三つです。

必要なときに、ロボットを安全な状態へ移せるか。
止まった理由を追えるか。
そして、現場の業務を戻せるか。

では、その能力を会社が持つには、どれだけの人、設備、時間、資金が必要なのでしょうか。

すべてを自社で作るべきなのでしょうか。
専門企業と提携するべきなのでしょうか。
組み込みやロボティクスの会社を買収すれば、能力を得られるのでしょうか。

次回は、フィジカルAIへの転換を、技術ではなく資本配分の側から考えます。

連載一覧

関連マガジン

情報源・参考URL

一次資料・公式資料

論文・専門資料

  • Christophe Bédard、Ingo Lütkebohle、Michel Dagenais「ros2_tracing: Multipurpose Low-Overhead Framework for Real-Time Tracing of ROS 2」https://arxiv.org/abs/2201.00393

note内の関連・参考記事

いいなと思ったら応援しよう！

一般財団法人 木村潤 記念財団 よろしければサポートお願いします！ いただいたサポートは本財団としての活動費に使わせていただきます！