ヒューマノイドの実運用は、デモ動画の巧拙ではなく「基盤モデルの責務分離」「現場側の失敗隔離」「監視と停止手順の運用定着」で決まる。本稿では、Figureが2025年2月20日に公開したHelixと、2026年1月27日に発表されたHelix 02の全身自律制御アーキテクチャ、さらにBoston Dynamicsが2026年1月に産業配備を開始した電動Atlas（本稿では便宜的にAtlas 2.0と呼ぶ）を参照し、統合設計の実務要件を体系的に整理する。

Figure 02はBMW工場で11カ月間稼働し、9万個以上の部品をロードして3万台以上のBMW X3の生産に貢献した。一方、電動Atlasは56自由度・最大50kg持ち上げ能力でHyundai Metaplant Americaに配備されている。両者の実績から導かれる設計原則は、「デモで動く」と「工場で止まらない」の間にある巨大なエンジニアリングギャップをどう埋めるかという問いに集約される。

1. 基盤モデル統合は「単一巨大モデル」より「制御境界つき多層」が現実的である

Figureは2025年2月20日のHelix公開時点で、上位の意味理解と下位の連続制御を分離する設計思想を示している。さらに2026年1月27日のHelix 02では、この思想を「System 0/1/2」という3層アーキテクチャとして具体化した。

Helix 02の3層制御アーキテクチャ

System 2（意味推論層）は、自然言語と視覚シーンを処理し、「食洗機まで歩いて開ける」といった高水準の目標を設定する。System 1（視覚運動ポリシー層）は200Hzで動作し、視覚・触覚データから全身の関節目標値を直接生成する。そしてSystem 0（身体基盤層）は1kHzで動作し、バランス・接触・協調を制御する。System 0は1,000時間以上の人間モーションデータで訓練され、約10万9,504行の手書きC++コードを単一のニューラルプライアーに置き換えた。

この階層化によって実現された成果が、4分間の連続キッチンタスクである。食洗機の開閉、食器の取り出し・収納、棚への配置を一切のリセットや人間介入なしで完遂した。手がふさがった状態では腰で引き出しを閉め、足で食洗機のドアを持ち上げるなど、全身を道具として使う行動も確認されている。

実装設計の観点から重要なのは、この3層がそれぞれ異なるレイテンシ要件を持つ点である。System 2は数百ミリ秒のレイテンシを許容するが、System 0は1ms以内の応答が必須となる。単一の巨大モデルにこれらを統合すると、最も厳しいレイテンシ要件に全体が引きずられるか、バッチ処理の粗さが安全制御の精度を犠牲にする。したがって、産業導入ではPlanner（自然言語指示を作業計画に変換）とSkill Runtime（把持・移動・姿勢遷移）を分離し、両者の間に命令スキーマ検証を置くべきである。これにより、上位モデルの誤推論が即座に高トルク動作へ伝播するリスクを抑制できる。

筆者がセキュリティアーキテクトとして複数企業のゼロトラスト設計に関わった経験から言えば、「信頼境界の明確な分離」は防御設計の基本中の基本である。ロボティクスでもまったく同じ原則が適用される。上位層が侵害されても下位の安全制御は独立して機能する、という設計方針は、ゼロトラストの「Never Trust, Always Verify」と本質的に同じ考え方だ。

2. タスク分解は「工程分解」ではなく「失敗モード分解」で設計する

現場導入で事故を減らすには、業務手順の順番どおりに分けるより、失敗時の被害範囲で分ける方が有効である。例えば入出庫作業なら、(a)対象認識、(b)到達計画、(c)把持、(d)搬送、(e)置き直しをそれぞれ再試行可能なステートとして定義し、各ステートでタイムアウト・最大力・人接近時の減速ルールを固定する。

BMW工場11カ月の実績データが示す失敗モード

Figure 02がBMW Spartanburg工場で実際に稼働した11カ月間のデータは、失敗モード設計の重要性を裏付けている。ロボットは月曜から金曜まで10時間シフトで稼働し、累計1,250時間の稼働実績を記録した。主要タスクはシートメタル部品をビンから持ち上げ、5mmの公差で溶接治具に配置する作業で、サイクルタイムは84秒であった。

注目すべきは、前腕部がハードウェア故障の最多発箇所だったという事実だ。この知見を受けて次世代のFigure 03では、手首の配電基板と動的ケーブリングを廃止し、モーターコントローラが本体コンピュータと直接通信する設計に変更された。これは、故障モードの分析が実際の設計改善に直結した好例である。

Figureが2025年11月19日に公表したBMW工場での運用拡大、そして2026年2月にはライプツィヒ工場への欧州初展開も発表されている。高電圧バッテリー組立と部品製造という、精度・安全性・人間工学のすべてが要求される工程への配備だ。この段階では新規能力の追加より、既存ステート機械の再利用率と異常時復帰時間（MTTR）を優先指標に置くべきである。

失敗モード分解の実装パターン

ステート失敗モード制限値復帰戦略
対象認識誤認識/未検出タイムアウト3秒再スキャン→人間通知
到達計画経路衝突/到達不能計画時間2秒上限代替経路→安全退避
把持把持失敗/滑り最大把持力制限再試行3回→停止
搬送障害物検知/人接近速度50%制限即時減速→一時停止
配置位置偏差超過公差±5mm微調整→再配置

このような失敗モード別のステート設計は、ヒューマノイド産業配備の転換点で分析した自動車・倉庫・製造の3セクターいずれにも適用可能なフレームワークとなる。

3. Atlas 2.0の産業配備仕様と統合設計の実務要件

Boston Dynamicsの電動Atlasは2026年1月にHyundai Motor Group Metaplant America（HMGMA、ジョージア州サバンナ）への産業配備を開始した。2026年分の配備は全量がコミットされており、HyundaiのRobotics Metaplant Application Center（RMAC）とGoogle DeepMindへのフリート出荷が順次進行している。

電動Atlasの技術仕様

電動Atlasは56自由度を持ち、油圧版のほぼ3倍の可動域を実現している。多くの関節が360度回転可能で、人間にはできない姿勢での作業が可能だ。カスタム設計の電動ダイレクトドライブアクチュエータはトルク密度220Nm/kgを達成し、持続ペイロード30kg（66ポンド）、バースト持ち上げ能力50kg（110ポンド）を備える。EV生産で扱うエンジン部品やバッテリーモジュールの重量に十分対応できる。

Hyundaiのロードマップでは、2028年までにサバンナ近郊のMetaplantで年間3万台のAtlasヒューマノイドを製造し、世界中の工場・倉庫に統合する計画が発表されている。この規模感は、ヒューマノイド統合が一過性のPoCではなく、製造インフラの構造的変革であることを示している。

FigureとBoston Dynamicsの両アプローチを統合設計の観点から比較すると、重要な差異が浮かび上がる。Figureはソフトウェア基盤モデル（Helix）の汎用性を重視し、BMW→欧州展開という水平スケールを志向している。一方、Atlas 2.0はHyundaiグループ内の垂直統合を前提とし、ハードウェアの高トルク・多自由度を活かした重量物作業に特化している。いずれの場合も、「基盤モデルのアップデートと現場の安全境界を独立に管理する」設計原則は共通して必要となる。

4. 安全設計は「モデル安全」だけでなく「設備安全」を先に固定する

ヒューマノイド導入では、AIモデル評価に注目が集まりやすいが、実害は設備側の保護境界不備から発生しやすい。したがって、非常停止系はモデル非依存、速度・トルク制限は制御器で強制、危険領域侵入検知は外部センサーで冗長化を原則にする必要がある。

ISO 10218:2025改訂とヒューマノイドへの適用

2025年に改訂されたISO 10218は、ヒューマノイドロボットの安全設計に直接影響を与える重要な変更を含んでいる。旧版ではモバイルプラットフォームを持つロボットが完全に適用対象外だったが、新版では移動機能の側面のみを除外する形に変更された。これにより、ヒューマノイドのマニピュレータ部分がISO 10218の適用範囲に入った。

さらに、従来の「協調ロボット（collaborative robot）」という用語は新版では使われず、「協調アプリケーション（collaborative application）」に統一された。これは、ロボット自体ではなく実際の使用形態を設計・テスト・確認すべきだという思想の転換を反映している。加えて、従来ISO/TS 15066で独立して定義されていた協調アプリケーション要件がISO 10218本体に統合され、サイバーセキュリティ要件も新たに追加された。

ヒューマノイド固有の安全規格としてはISO 25785-1が策定中であり、動的安定ロボット（dynamically stable robots）向けの要件を定義する予定だ。現時点での実装では、ISO 10218:2025とANSI/A3 R15.06-2025を基盤としつつ、ヒューマノイド特有のリスク（転倒、予期しない姿勢遷移、全身衝突）に対する追加保護をリスクアセスメントで補完することが推奨される。

NISTのAI RMF 1.0（2023年1月26日公開）が示すGovern/Map/Measure/Manageの枠組みをロボット運用に当てはめると、モデル精度はMeasureの一部に過ぎない。実運用では、責任分界（誰が停止判断を持つか）と証跡（停止理由を後追いできるか）を先に設計しなければならない。エージェンティックAI攻撃面の産業化で分析したように、自律システムの権限管理は2026年最大のセキュリティ課題であり、ヒューマノイドの安全設計もこの文脈で捉える必要がある。

5. 監視設計は「見る」ではなく「止めるために測る」へ転換する

監視基盤は、可観測性ダッシュボードを作ること自体が目的ではない。運用上重要なのは、停止条件を即時に満たせる指標を定義することである。最低限、(1)タスク成功率、(2)再試行回数分布、(3)安全関連イベント頻度、(4)介入から復帰までの時間をリアルタイム収集し、しきい値逸脱で自動的に安全モードへ遷移させるべきである。

メトリクス設計のベストプラクティス

BMW工場でのFigure 02稼働データを参考にすると、以下の指標群がヒューマノイド監視の標準フレームワークとして機能する。

カテゴリ指標目標値アラート条件
タスク効率サイクルタイム84秒（BMW基準）基準値の150%超過
信頼性タスク成功率≥99.5%1時間あたり3回以上の失敗
安全性人接近停止頻度記録・分析1時間あたり5回以上
可用性MTTR（平均復帰時間）≤5分10分超過
ハードウェア関節温度/電流定格値内定格の90%超過
モデル推論レイテンシSystem 1: ≤5ms10ms超過

Boston Dynamicsの2026年1月時点のAtlas更新が示すように、運動性能は急速に向上する。性能向上に合わせて監視の粒度を上げない場合、能力向上がそのままリスク増幅になる。導入チームはモデル更新計画と同じ優先度で、監視項目の変更管理（メトリクス定義の版管理）を運用に組み込む必要がある。

筆者がSOC構築・SIEM導入に携わった経験から強調したいのは、「SOCの価値はツールではなく、アラートから判断までの人間のプロセスにある」という点だ。ヒューマノイドの監視運用もまったく同じである。ダッシュボードに指標が並んでいても、異常時に誰が何秒以内にどの判断を下すかが定義されていなければ、監視は機能しない。パニック下でも機能する手順書は、平時に何度もドライランして初めて完成する。

6. モデル更新管理とロールバック設計

ヒューマノイドの基盤モデルは、ソフトウェアのデプロイと同様にバージョン管理とロールバック戦略が必須となる。Helix→Helix 02の進化が示すように、モデルアップデートは全身制御の挙動を根本的に変える可能性がある。10万行以上のC++コードがニューラルプライアーに置き換わったSystem 0の例は、アップデートの影響範囲が予測困難であることを端的に示している。

カナリアデプロイメント戦略

複数台のヒューマノイドが稼働する工場では、全台一斉のモデルアップデートは避けるべきだ。推奨されるのは、マルチエージェントオーケストレーションの経済学で分析したPlan-and-Executeパターンの応用である。具体的には以下の手順が推奨される。

  1. ステージング環境での検証：新モデルを模擬環境で最低100タスクサイクル実行し、全指標が閾値内であることを確認
  2. カナリア展開：全フリートの10%以下にのみ新モデルを適用し、24時間の本番データを収集
  3. 段階的ロールアウト：カナリアの指標が安定した後、25%→50%→100%と段階的に展開
  4. 即時ロールバック：任意のステップで異常が検出された場合、旧モデルへの即時復帰を可能にする

ここで重要なのは、モデルバイナリだけでなく、対応するメトリクス閾値・安全パラメータ・ステートマシン定義もバージョン管理の対象とすることだ。モデルだけ更新して安全パラメータが旧版のままでは、新しい運動能力に安全制限が追従しない。

7. ROI設計と段階的導入フレームワーク

ヒューマノイド導入のROI算定は、単純な人件費置換モデルでは不十分である。BMW工場の実績データを基に、より現実的な経済性評価フレームワークを提示する。

コスト構造の分解

Figure 02のBMW導入事例では、84秒サイクルタイム・10時間シフト・月〜金稼働で、11カ月間に9万部品を処理した。ここから逆算すると、1台あたり1日約430部品（10時間 × 3,600秒 ÷ 84秒）の処理能力が見込まれる。ただし、初期導入コスト、保守コスト、ダウンタイムコスト、人間オペレーターの監視コストを含めた総保有コスト（TCO）で評価すべきである。

段階的導入のフレームワークとしては、(1) 単一セルPoC（3カ月）→ (2) 同一工程複数台展開（6カ月）→ (3) 異工程水平展開（12カ月）→ (4) 複数拠点展開という4段階が推奨される。各段階でMTTR・タスク成功率・TCOを再評価し、次段階への移行判断を行う。

FAQ

Helixと既存のロボット制御スタックは置き換え関係か。

全面置き換えではなく、上位意思決定を拡張する関係で設計するのが現実的である。Helix 02のSystem 0/1/2アーキテクチャが示すように、安全停止やトルク制限は1kHzで動作するSystem 0が担い、従来の確定的制御系と同等の応答性を維持している。Helix系はタスク計画と状況理解に責務を限定し、安全クリティカルな制御は分離するべきである。

「Atlas 2.0」という呼称は公式か。

公式製品名ではない。本稿では2026年1月にHyundai Metaplant Americaへの産業配備が開始された電動Atlas（56自由度、最大50kg持ち上げ能力）を、2013〜2023年の油圧版と区別するための便宜的表現として使用している。

現場PoCで最初に計測すべきKPIは何か。

デモ成功率ではなく、失敗時の復帰時間（MTTR）と安全停止の発生頻度である。BMW工場の11カ月稼働データでは、前腕部の故障が最多であったことが報告されている。この種の具体的な故障分布データこそが本番移行時の運用コストを直接規定する。

ISO 10218:2025の改訂はヒューマノイド導入にどう影響するか。

旧版ではモバイルプラットフォームを持つロボットが適用対象外だったが、新版では移動機能のみを除外し、マニピュレータ部分を適用範囲に含めた。また、ISO/TS 15066の協調アプリケーション要件が本体に統合され、サイバーセキュリティ要件も追加された。ヒューマノイド特有の規格ISO 25785-1は策定中であり、現時点ではISO 10218:2025をベースにリスクアセスメントで補完する形が推奨される。

監視システムはどの粒度でログを持つべきか。

最低でも「指示ID」「ステート遷移」「安全イベント」「操作者介入」「復帰結果」を同一トレースIDで紐付ける粒度が必要である。BMW工場で前腕部の故障パターンが特定できたのも、こうした粒度のログが保持されていたからこそである。事故調査と再発防止の速度が大きく変わる。

FigureとBoston Dynamicsのアプローチはどちらが有利か。

一概に比較できない。Figureはソフトウェア基盤モデル（Helix）の汎用性を軸にBMW→欧州への水平展開を志向し、Atlas 2.0はHyundaiグループ内の垂直統合で重量物作業に特化している。導入企業の業態（多品種少量 vs 大量生産）、既存設備との統合要件、安全規制環境によって最適解は異なる。重要なのは、いずれを選んでも「基盤モデルのアップデートと安全境界の独立管理」が必須だという点が共通していることだ。

モデルアップデート時の最大リスクは何か。

最大リスクは、新モデルが獲得した新しい運動能力に既存の安全パラメータが追従しないことである。Helix 02でSystem 0が10万行以上のC++コードを置き換えたように、基盤モデルの更新は制御挙動を根本的に変える可能性がある。モデルバイナリだけでなく、安全パラメータ・メトリクス閾値・ステートマシン定義を一体でバージョン管理し、カナリアデプロイメントで段階的に検証するプロセスが必須である。

参考文献