ロボットソフトウェアの安全なOTA設計：互換性・段階展開・ロールバックの実践

Wed, 07 Oct 2026 14:41:10 +0900

ロボットの更新では、配布できたことと安全に復旧できることを分けて考える必要があります。

結論

ロボットのOTAを安全にするには、イメージの署名検証だけでは不十分です。機体互換性をマニフェストで定義し、サーバーと機体の双方で適用可否を確認したうえで、少数のカナリアから段階展開します。さらに、起動後のセンサー、アクチュエータ、通信、バッテリー、制御ループなどをヘルスゲートとして監視し、異常時には許可された既知の正常版へ戻せるようにします。

復旧方式としては、対応するブートローダーとストレージ構成がある場合、A/Bまたはデュアルバンクが有力です。ただし、運用上のロールバックと、脆弱な旧版へのダウングレードを防ぐアンチロールバックは別の制御として設計しなければなりません。

なぜ機体互換性が難しいのか

同じ製品系列のロボットでも、ハードウェアリビジョン、接続されたセンサーやアクチュエータ、MCUファームウェア、OS、ブートローダーが異なることがあります。アプリケーションが起動しても、通信プロトコルやファームウェアABIが合わなければ、制御系全体を正常に動かせるとは限りません。

また、アプリケーションだけを旧版へ戻しても、設定・データスキーマの移行、ブートローダー更新、他ECUとのプロトコル変更が残れば復旧は不完全です。OTAの単位は単一バイナリではなく、依存関係と適用順序を含むリリースとして定義する必要があります。

互換性契約をマニフェスト化する

更新マニフェストと機体インベントリを比較し、適用対象を限定します。契約に含める項目は、少なくとも次のように整理できます。

製品系列、機体モデル、機体識別子
ハードウェアリビジョン、センサー・アクチュエータ構成
ブートローダー、OS、カーネル、ファームウェアABI
接続ECUと通信プロトコル
更新対象コンポーネント、依存関係、適用順序
設定・データスキーマ
シーケンス番号、最低限必要なセキュリティバージョン

RFC 9124は、ベンダーID、クラスID、コンポーネント、依存関係、シーケンス番号、条件、検証アルゴリズムなどをマニフェストで表す情報モデルを定義しています。Uptaneは、一般的な更新情報と、個別の車両やECUに対する適用指示を分離する構成を示しています。

サーバー側では属性やインベントリによって対象を絞り込み、機体側でも受信後に再検証します。サーバーの選定だけに頼ると、古いインベントリや誤登録による誤配布を止められません。

flowchart LR
  A["更新イメージとマニフェストを生成"] --> B["署名・ハッシュ・メタデータを検証"]
  B --> C["サーバー側で対象機体を選定"]
  C --> D["機体側でインベントリと互換性契約を再検証"]
  D -->|"不一致"| X["インストール拒否"]
  D -->|"一致"| E["更新前の安全条件を確認"]
  E --> F["カナリア機へ展開"]
  F --> G["起動後ヘルスゲート"]
  G --> H{"異常があるか"}
  H -->|"いいえ"| I["次のコホートへ拡大"]
  I --> J{"全コホート完了か"}
  J -->|"いいえ"| F
  J -->|"はい"| K["展開完了"]
  H -->|"はい"| L["新規展開を停止"]
  L --> M["許可された既知の正常版へロールバック"]
  M --> N["復旧状態を確認"]
  N -->|"復旧"| O["再開または中止を判断"]
  N -->|"未復旧"| P["リカバリー手順へ移行"]

署名検証だけでなく、互換性契約、更新前後の安全条件、段階展開、ヘルスゲート、ロールバックを組み合わせるOTAの全体フロー。

署名だけに依存しない検証

安全なOTAは、未承認変更を防止する、変更を検出する、信頼できる状態へ復旧する、という多層構成で考えます。NIST SP 800-193は、プラットフォームファームウェアの保護をprevent、detect、recoverの三機能で整理しています。これはロボットの物理安全全体を直接規定するものではありませんが、更新設計の基本的な分解として利用できます。

署名検証 on Physical AI Hub

ロボットソフトウェアの安全なOTA設計：互換性・段階展開・ロールバックの実践

結論

なぜ機体互換性が難しいのか

互換性契約をマニフェスト化する

署名だけに依存しない検証