あるメーカーで作った動作が別メーカーのロボットでは動かず、機種が変わるたびにゼロから作り直しになる。
動作のポータビリティ不在は、単なる規格の不統一ではなく、ロボット導入工数の大半が「同じ動作の作り直し」に費やされ続ける産業構造の問題である。
30秒要約
- 主要メーカーはそれぞれ独自のロボット言語・教示方式を持ち（FANUC、安川、KUKA、ABB等で各社各様）、あるメーカー向けに設計した動作プログラムは他社機にそのまま移植できない。
- 導入の律速はハード価格ではなくエンジニアリング工数であり、システムインテグレーション費用が本体価格を上回ることが常態化している（※比率の具体値は要出典確認）。
- 最初の一歩は、「動作の意味（タスク）」「動作の軌跡（データ）」「動作の実行（各社SDK）」を分離する中間表現と抽象化層（HAL）を、オープンなデータ形式とともに育てること。
実装判断サマリー
| 項目 | 内容 |
|---|---|
| いま何が問題か | 機種ごとに動作をゼロから作り直すため、導入工数が下がらず普及が頭打ちになる |
| なぜ今か | 学習ベース制御（VLA・模倣学習）の登場で「動作＝データ」になり、ポータビリティを設計できる初めての機会が来ている |
| 最大の制約 | メーカーにとって囲い込み（ロックイン）が経済合理的であり、標準化の主導者が不在 |
| 主なレバー | 中間表現の標準化、HAL（抽象化層）のOSS化、オープンな動作データ形式の普及 |
| 最重要KPI | 同一タスクを別機種へ移植する際の工数（時間・コスト）の削減率 |
| 争点 | 標準を誰が握るか（メーカー連合／OSSコミュニティ／海外プラットフォーマー） |
課題の定義（扱う／扱わない）
- 扱う：設計済みの動作（タスク・軌跡・スキル）を異なるメーカー・機種の間で再利用できない問題。およびそれが生むSIer工数の高止まり。
- 扱わない：ハードウェア規格（コネクタ・フランジ・電源等）そのものの統一。通信プロトコルの標準化（OPC UA等）は関連するが、本カードの中心ではない。
- 似て非なる：SIer工数のボトルネック（別カード）は人と業務プロセスの問題を含むが、本カードは「動作データが資産として持ち運べない」という技術構造に絞る。
何が起きているか（データ）
- 主要産業用ロボットメーカーは各社独自のプログラミング言語と教示環境を持つ（FANUC：TP/KAREL、安川：INFORM、KUKA：KRL、ABB：RAPID 等）。動作プログラムの互換性はない。
- 研究領域ではROS/ROS 2が事実上の共通基盤になっているが、産業現場での採用は部分的にとどまる。ROS-Industrialのような橋渡しの取り組みはあるが、メーカー公式SDKとの二重構造が残る（※産業採用率の定量データは要出典確認）。
- URDF等の記述形式はロボットの「構造」を記述するものであり、「動作」を機種間で持ち運ぶ標準は存在しない。
- 模倣学習の領域ではLeRobot（Hugging Face）のように動作データセット形式をオープンに標準化する動きが出ており、「動作＝持ち運べるデータ」という発想が学習ベース制御側から先に実現しつつある。
- 国内では、導入時のシステムインテグレーション費がロボット本体価格と同等以上になるケースが指摘されており、SIer人材の不足が経産省等の文書でも継続的に課題とされている（※最新の統計値は要出典確認）。
なぜ先送りされてきたか
- メーカーにとって独自言語・独自エコシステムは顧客を囲い込む合理的な戦略であり、互換性を高める動機が構造的に弱い。
- SIerにとっても移植・再設計は売上の源泉であり、業界内部から標準化を主導する力学が生まれにくい。
- ユーザー企業は個別案件の納期に追われ、「次の機種でも使える形で動作を残す」ことに投資する余裕がない。
- 標準化団体・国の取り組みは通信や安全が中心で、「動作の表現形式」はスコープに入りにくかった。
原因構造
- 供給側：各社独自言語＋独自教示環境。互換を作らないことが競争戦略として機能してきた。
- 需要側：導入企業は単発案件として発注するため、動作を再利用可能な資産として要求する買い手が育っていない。
- 構造側：「タスク（What）」「軌跡（How）」「実行（Execute）」が分離されておらず、最下層のハード依存コードに全てが埋め込まれる設計が業界標準のまま。
- これらが相互に強化し合い、動作の作り直し→工数高止まり→導入が大企業に偏る→データも資産も蓄積しない、という悪循環になっている。
誰が、どう困るか（影響）
- SIer：案件ごとのゼロからの動作設計で工数が高止まりし、人材不足と相まって受注能力が頭打ちになる。
- 中小・地方の現場：エンジニアリング費を吸収できず導入を断念。人手不足が最も深刻な層にロボットが届かない。
- メーカー：短期的にはロックインで守られるが、長期的にはエコシステムの閉鎖性が新規開発者の参入を妨げ、プラットフォーム競争で海外オープン勢に劣後する。
- 新規参入者・個人開発者：機種ごとに学び直しが必要で、参入障壁として機能する。動作データのマーケットも成立しない。
放置するとどうなるか（時間軸）
- 数年：SIer工数の高止まりが続き、人手不足対策としてのロボット導入が「体力のある大企業の工場」に偏ったまま進む。
- 中期（2030年代）：学習ベース制御が主流化し、動作データを大量に持つ海外プラットフォームが事実上の標準を握る。国内勢は「データ形式の決定権がない側」に固定される。
- 長期（2040年前後）：動作資産の蓄積差が産業競争力の差として顕在化する。機種を跨いで動作を再利用できる経済圏と、案件ごとに作り直す経済圏の生産性格差が開く。
解決の方向性
- 3層分離：「動作の意味（タスク定義）」「動作の軌跡（中間データ）」「動作の実行（各社SDK変換）」を分離するアーキテクチャを設計原則として普及させる。ハード依存を最下層（HAL）に閉じ込める。
- 中間表現のオープン化：関節角度・軌跡・スキルの記述形式をオープンなデータ形式として整備する。LeRobot等、学習側から生まれた形式との互換を意識する。
- HALのOSS化：シリアル・UART・TCP/IP等、制御方式が異なる機種を同一インターフェースで扱う抽象化層を、特定メーカーに依存しない形で育てる。
- リターゲティング技術：機構が異なるアーム間で軌跡を変換する手法（運動学リターゲティング・学習ベース変換）の実用化。
選択肢の比較
| 選択肢 | 効果 | コスト | 実現難度 | 主な副作用 | 前提・備考 |
|---|---|---|---|---|---|
| 中間表現＋HALのOSS整備 | 高 | 中 | 中 | メーカーの非協力で形骸化の恐れ | コミュニティと先行事例が鍵 |
| メーカー連合による業界標準 | 高 | 高 | 高 | 最小公倍数化・策定の長期化 | 囲い込み動機との正面衝突 |
| 学習ベース制御への全面移行待ち | 中 | 低 | 中〜高 | 移行期の現場が放置される | 海外形式が標準を握るリスク |
| SIer側の社内ライブラリ蓄積 | 中 | 低〜中 | 低 | 業界全体には波及しない | 即効性はあるが閉じた資産 |
主体別アクション
メーカー
- レバー：公式SDKのオープン化、サードパーティ開発者プログラム、中間表現のインポート/エクスポート対応。
- 変えるもの：閉じたエコシステムから、動作資産が流入するプラットフォームへ。
- 制約：ロックイン収益との両立。既存SIerチャネルとの関係。
- 成果指標：サードパーティ製ツール・動作データの流通量。
SIer・導入事業者
- レバー：案件成果物を再利用可能な中間表現で納品・蓄積する社内標準。
- 変えるもの：作り直し工数の売上から、動作資産ストックの売上へ。
- 制約：短期的には案件単価の見直しが必要。
- 成果指標：類似案件の動作設計工数の削減率。
ユーザー企業・現場
- レバー：発注仕様に「動作データの再利用可能な形式での納品」を含める。
- 変えるもの：ベンダーロックインされた設備から、機種更新に耐える動作資産へ。
- 制約：仕様を書ける人材の不足（タスク定義能力の未成熟・別カード参照）。
- 成果指標：機種更新・増設時の再設計費用。
研究者・コミュニティ・個人開発者
- レバー：オープンなHAL実装・リターゲティング手法・動作データセットの公開。安価アームでの検証事例の蓄積。
- 変えるもの：「動作は機種固有」という業界前提そのもの。
- 制約：産業用高価格帯ハードへのアクセス。
- 成果指標：複数機種で動いた同一動作の公開事例数。
争点
- 標準の主導権：オープンコミュニティ主導か、メーカー連合か、海外プラットフォーマーの事実上標準か。
- 抽象化の深さ：どこまでをハード非依存にできるか（ペイロード・リーチ・自由度の差をどの層が吸収するか）。
- 安全との関係：移植された動作の安全検証を誰がどの基準で行うか（共存安全基準・別カードと交差）。
反対論・トレードオフ
- 「機種ごとの最適化こそが品質であり、抽象化は性能を落とす」（最も強い反対）：精度・タクトタイムを極限まで詰める用途では、ハード直結の作り込みが今後も必要である。
- 応答：全用途の置き換えではなく、「作り直し工数が導入を阻んでいる中間層の用途」が対象。精度要求が緩いタスクから動作資産の再利用を始め、最適化が必要な箇所だけ各社SDK層で詰める分業が成立する。
- 公平性：標準化はしばしば先行者（標準を書いた側)に有利に働く。国内勢が参加しないまま標準が固まると、参加コストだけが残る。
- 副作用：中間表現が普及すると、動作データの流出・模倣が容易になり、ノウハウ保護との緊張が生まれる。
失敗のシナリオ（プレモーテム）
- 標準が乱立して終わる：複数の中間表現が互換性のないまま並立し、「標準を変換する工数」が新たに発生する。
- メーカー不参加で形骸化する：OSS側の整備が進んでも公式SDKが閉じたままで、変換層の保守コストがコミュニティに転嫁され続ける。
- 学習ベース一本足で現場が置き去りになる：「いずれVLAが解決する」という期待で中間層の整備が止まり、移行期の10年間、現場は作り直しを続ける。
- 安全検証がボトルネックに移動する：移植自体は容易になったが、移植後の安全検証の標準がなく、結局案件ごとの個別検証工数が残る。
KPI
- 結果指標：同一タスクの別機種移植に要する工数（時間・費用）。動作再設計費がシステム導入費に占める比率。
- 中間指標：オープンな中間表現・HALの対応機種数。再利用可能な形式で納品された案件の比率。
- 副作用指標：移植動作に起因する事故・不具合件数。ノウハウ流出に関する紛争件数。
未解決の問い
- 動作の「意味」をどの粒度で記述すれば、機構の異なるアーム間で意図が保存されるか。
- 精度・タクトタイムの劣化をどこまで許容する用途が、市場のどれだけを占めるか。
- 移植された動作の安全責任は、元の設計者・変換層・実行機メーカーのどこに置くべきか。
- 動作データのマーケットが成立する場合、品質保証と価格付けの基準は何か。
すでにある良い事例
- ROS / ROS 2・ROS-Industrial：研究領域での共通基盤として確立し、産業機との橋渡しを進めている。動作レベルの標準ではないが、抽象化層の前例として最大のもの。
- OPC UA Robotics（コンパニオン仕様）：通信・状態監視のレイヤーでメーカー横断の標準化が成立した例。動作レイヤーへの拡張可能性の参照点になる（※仕様の最新状況は要出典確認）。
- LeRobot（Hugging Face）：模倣学習用の動作データセット形式をオープンに標準化。「動作＝共有可能なデータ」という前提を学習側から作りつつある。
- 個人・小規模の検証事例：安価アーム（数万〜十数万円帯）を使い、同一の動作設計を複数機種で動かす検証が個人開発者レベルで始まっている。エンジニアリングではなく設計の問題として解く視点の供給源。
10年後の望ましい状態
- 動作設計の成果物が、機種更新・増設・他社機への移行に耐える資産として扱われている。
- SIerの工数構成が「ゼロからの作り直し」から「資産の適用と差分調整」に移り、中小・地方の現場に導入が届いている。
- 国内の現場・開発者が、動作データ形式の決定に参加する側にいる。
出典・関連課題・更新履歴
- 出典：各社ロボット言語の存在（FANUC TP/KAREL、安川 INFORM、KUKA KRL、ABB RAPID）は各社公式ドキュメントで確認可。SIer工数・SI費比率・人材不足の定量値は経産省「ロボットを取り巻く環境変化」関連資料等で要出典確認。ROS-Industrial・OPC UA Robotics・LeRobotは各公式サイト。
- 関連課題：SIer工数のボトルネック / タスク定義能力の未成熟 / エコシステムの主導権 / 人とロボットの共存安全基準
- 更新履歴：2026-06-12 初版（draft・定量データ未検証）