【ITニュース解説】Designing a Simulation-First Safety Gate for Strands Robots

AIが物理的なロボットを制御するシステムを開発する際、単にAIがテキストを生成するだけのチャットボットとは異なり、その失敗は物理的な衝突、ハードウェアの損傷、物の落下、あるいは人命に関わる危険な状況を引き起こす可能性がある。そのため、ロボットの行動が現実のハードウェアに適用される前に、厳格な「安全ゲート」を通過する必要がある。

この安全ゲートの考え方は、AIエージェントが生成した行動計画をすぐにロボットに実行させるのではなく、まずシミュレーション環境でテストし、そのテスト結果を記録し、安全性について評価し、最終的に人間の承認を得てから初めて実機に適用するという段階的なプロセスである。

ロボットのタスク評価と安全評価は明確に区別して考えるべきだ。例えば、「赤いキューブを箱に入れる」というタスクをロボットが成功裏に完了したとしても、その過程で関節を速く動かしすぎたり、許可された作業空間を逸脱したり、他の物体と衝突したり、異常に時間がかかったり、特定の動作を繰り返して不安定になったりする可能性がある。これらはタスクは成功したが、安全制約に違反している状態である。このようなエピソードは、物理的なハードウェアで実行を自動的に許可すべきではない。

シミュレーション環境は、このような危険な動作を物理的なリスクなしにテストできる貴重な場所である。シミュレーションは単なる開発環境ではなく、品質を保証するための重要なゲートとなる。Strands Robotsのようなシステムは、ポリシーの実行を詳細に記録する機能を提供し、これによりロボットの動作を後から検証・評価するためのデータ（エピソード記録）を収集できる。このエピソード記録には、ロボットの観測結果、実行されたアクション、ロボットの状態、カメラからのデータ、動作のタイミング、タスクの内容、最終的なエピソードの結果などが含まれ、これらはすべて客観的に測定可能な情報となる。

安全ゲートでは、主に5つのカテゴリーで決定論的なチェックを行う。第一に「作業空間の安全性」で、ロボットのアームの先端などが定められたX、Y、Zの範囲内に収まっているかをチェックする。もし範囲外に出れば安全性は不合格となる。これは単なる数値比較であり、AIに判断させる必要はない。第二に「関節速度」で、各関節の速度が許容される最大速度を超えていないかを確認する。これもプログラムで確実にチェックできる項目である。第三に「衝突と接触」で、予期せぬ衝突や自己衝突、または安全でない接触が発生していないかを検出する。たとえタスクが成功していても、衝突があれば実行は拒否されるべきである。第四に「実行時間」で、タスクの完了に通常よりも時間がかかりすぎていないかをチェックする。これは、ロボットが何らかの問題に陥り、意味のない動作を繰り返している可能性を検出するのに役立つ。第五に「行動の安定性」で、ロボットが左右に不必要に動き続けるような不収束な行動がないかを、行動の変化頻度などから評価する。

これらのチェックは、基本的に「フェイルセーフ（Fail closed）」の原則に基づいている。つまり、システムが「安全である」と明確に判断できない限り、その動作を自動的に承認せず、拒否するか、またはより詳細な人間の介入を求めるべきである。

従来の評価システムは「合格」か「不合格」の二択が一般的だが、物理的なAIにおいては「不明（UNKNOWN）」という第三の状態が必要となる。例えば、衝突がなかったことを検証するための十分な証拠がない場合、そのエピソードを「不明」として、人間のレビューを要求する。不明であることは「合格」を意味しないため、これにより不確実な状況での安全性をさらに高めることができる。

このような評価アーキテクチャでは、Amazon Bedrockのようなツールが重要な役割を果たす。しかし、AI（特に大規模言語モデル、LLM）をロボットの唯一の安全メカニズムとして使用すべきではない。代わりに、評価を二層に分ける。第一層は「決定論的評価」で、作業空間の境界、関節速度、衝突フラグ、実行時間、距離の閾値など、プログラムコードで確実に測定できる制約をチェックする。第二層は「AIベース評価」で、ロボットが要求されたタスクを達成したか、行動がタスクと一貫していたか、予期せぬ行動はなかったか、人間によるレビューが必要か、といったより高レベルで抽象的な質問を評価モデルが判断する。LLMは決定論的な安全制御を補完するものであり、決して置き換えるものではないという点が重要だ。

さらに、評価には「エージェント評価」と「ロボット評価」という二つの側面がある。エージェント評価は、AIエージェントが適切なツールを選択したか、正しい指示を生成したか、目標に従ったか、エラーから回復できたかなど、AIのロジックや意思決定の質を評価する。一方、ロボット評価は、ロボットが作業空間内に留まったか、衝突を回避したか、速度制限を尊重したかなど、物理的な動作の安全性を評価する。これら二つの層の評価を組み合わせることで、初めてハードウェアへの承認が与えられる。

また、一度の成功だけでロボットのポリシーが信頼できるとは言えない。様々なシナリオ（オブジェクトの位置や向きの変動、障害物の有無、長いタスク、予期せぬ失敗からの回復など）で、ポリシーが一貫して安全に動作するかを検証するために「バッチ評価」が不可欠である。これにより、再利用可能な評価データセットを構築し、異なるポリシー間の比較や、ポリシーの変更後の退行テストが可能になる。

最終的なリリースプロセスでは、まず「ロボットの物理的な動作が安全か」というゲートを通過させ、次に「AIエージェントの行動が正しいか」というゲートを通過させる。この二段階の品質ゲートをクリアして初めて、ポリシーは物理的なハードウェアでのテストへと進む。

失敗したエピソードも単に無視するのではなく、詳細な記録として残すことが重要だ。これにより、どのような状況で、どのような安全違反が発生したのかを分析し、ポリシーの改善のための貴重な学習データとして活用できる。この「実行→評価→失敗発見→失敗記録→ポリシー改善→再実行」というループは、継続的なシステム改善に繋がる。

シミュレーションは、物理的な制約なしに何百、何千ものエピソードをテストできるため強力だが、現実世界とは異なる点があることを忘れてはならない。センサーノイズ、校正誤差、通信遅延、機械的なばらつき、予期せぬ障害物、照明の変化など、現実世界特有の問題はシミュレーションでは完全に再現できない。したがって、シミュレーションはリスクを軽減するものであり、完全に排除するものではない。最初の物理的な実行は、常に管理され、監視されるべきである。

最終的な目標は、単にAIエージェントがロボットを制御できるかという問いに留まらず、ロボットの行動が現実世界で実行されるのに十分安全であることを測定可能かつ客観的に証明できるシステムを構築することである。そのために、シミュレーションから始まり、エピソードの記録、決定論的およびAIベースの評価、明確な安全ゲート、人間によるレビュー、そして継続的な監視と改善という、段階的で厳格なプロセスが必要となる。ロボットは、その行動が安全であるという「権利」を、このシステムを通じて獲得していくことになる。