ロボットの標準化・相互運用性——なぜ繋がらないのか

エグゼクティブ・サマリー

• 「繋がらない」は一つの現象ではなく、三層の不一致である。 物理（電源・機構・設置条件）、通信（プロトコル・API）、意味（データ項目の定義とID）。現場で最も高くつくのは三番目の意味の不一致であり、これは「APIがある」だけでは解決しない。
• 標準化が進まない理由は技術ではなく、経済合理性にある。 標準に合わせる側にはコストが先に発生し、便益は業界全体に薄く広がる。この構造がある限り、個社の善意では標準化は起きない。動かすのは買い手の要求である。
• 相互運用性はゼロかイチではなく、五段階で考える。 L0共存しない／L1物理共存／L2データ取得可／L3制御連携可／L4動的入替可。多くの現場が必要としているのはL2〜L3であり、L4を最初から目指すと投資が過大になる。
• ユーザー企業の武器は調達仕様である。 「標準に対応していること」ではなく、「どの項目を、どの形式で、誰の権限で、何年間、どの手段で取得できるか」を要求文として書く。書けるかどうかが分水嶺になる。
• 「対応しています」は検証してはじめて事実になる。 適合の主張、検証済み組み合わせの一覧、実機での相互接続確認——この三段階を通していない主張は、契約上の意味を持たない。
• 標準化は一社では完結しない。 ユーザー・メーカー・SIer・運用事業者・自治体・大学が同じ参照アーキテクチャを共有し、相互接続を試せる場を持ってはじめて、個別最適の積み上げから抜け出せる。

ロボット導入の現場で「繋がらない」という言葉が出るとき、その多くは技術的に接続不可能であることを意味しない。接続はできるが、追加開発が必要で、費用と期間の見積が出ておらず、誰の予算にも入っていない——という状態を指している。つまりこれは技術課題ではなく、調達と設計の順番の問題である。本稿は、ロボットを販売しない中立の立場から、相互運用性を「あるかないか」ではなく段階と要求文として扱う方法を整理し、買い手・供給者・業界のそれぞれが取れる手を具体的に示す。

1. 「繋がらない」の正体——三層に分解する

まず、現場で発生する不一致を三つの層に分けておく。層を混ぜたまま議論すると、対策の宛先が決まらない。

①は見積に載る。②も、変換開発として見積に載せることはできる。問題は③である。意味の不一致は、繋いだ後に「数字が合わない」という形で現れる。ある機種の「稼働中」が待機時間を含み、別の機種は含まない。エラーコードの一覧が非公開で、同じ「E12」が機種ごとに別の事象を指す。この状態で稼働率を合算しても、経営が使える数字にはならない。

意味の統一は、技術者ではなく発注者側にしか決められない。どの粒度で何を「稼働」と呼ぶかは業務上の定義であり、ベンダーが決めるべき事柄ではないからである。ロボット稼働データの収集・可視化基盤で述べた共通イベントスキーマの考え方は、まさにこの③層を先に固定するための手続きである。

2. なぜ標準化は進まないのか——技術ではなく経済の問題

「なぜ業界で標準を決めないのか」という問いには、技術的な答えは存在しない。答えは費用と便益の配分にある。

第一に、コストは先、便益は後で、しかも薄く広がる。 標準に合わせるための設計変更・試験・ドキュメント整備の費用は、対応する一社が全額を負担する。一方で相互運用性の便益は、買い手と業界全体に分散する。この非対称がある限り、個社にとって標準対応は合理的な投資になりにくい。

第二に、差別化の源泉と重なる。 群制御の効率や動作計画の巧拙は、各社が投資してきた競争領域である。ここを標準化すると差が消えると考えれば、標準化への抵抗は経営判断として一貫している。実務的には、競争領域と協調領域を分ける議論を先に済ませないと前に進まない。

第三に、検証の負担が大きい。 「標準に対応している」と言うには、対応表の作成だけでなく、他社機との組み合わせ試験が要る。相手が増えるほど組み合わせは増え、試験環境を自社だけで用意することは現実的でなくなる。この点は、後述する業界共通の試験の場がなければ解決しない。

第四に、買い手が要求してこなかった。 最も大きい理由はこれである。相互運用性が選定基準に入っていなければ、供給側がそこに投資する理由はない。逆に言えば、買い手が調達仕様に書いた瞬間から、標準化は事業課題になる。標準化を動かす主体は、標準化団体ではなく発注者である。

3. 標準の四つの型と、期待できることの違い

「標準」と一括りにすると期待値がずれる。成立の仕方によって、拘束力も普及の速度も異なる。

産業用の通信基盤や、ロボットソフトウェアの共通ミドルウェア、軽量なメッセージ通信の枠組みなど、既に広く使われている技術要素は存在する。重要なのは、これらを採用すれば相互運用性が得られると考えないことである。共通のプロトコルを使っていても、意味の層が揃っていなければ繋がらない。プロトコルの一致は前提条件であって、十分条件ではない。

実務上の使い分けは単純である。安全と用語はデジュールに寄せ、機器と上位系の接続はフォーラム標準またはデファクトに寄せ、社内の意味定義（データ辞書）は自社で決めて全ベンダーに強制する。三つ目だけは、外部の標準に委ねられない。

4. 相互運用性を五段階で定義する

「繋がる／繋がらない」の二分法をやめ、必要な水準を段階で指定する。これだけで見積の精度と交渉の質が変わる。

多くの現場が実際に必要としているのはL2、多くてもL3である。L4は魅力的に聞こえるが、達成には仕様の全面的な外部化と継続的な適合性確認が要り、台数と変更頻度が相当に大きい事業でなければ投資が回収できない。複数ベンダー・複数機種の統合とデータ連携で示した通り、繋がずに運用で分離するL1が最も安く壊れにくい場合も多い。

目標レベルは、RX構想策定の段階で、工程ごとに宣言しておく。搬送はL3、検査はL2、清掃はL1——という形で書き分けられていれば、その後の見積とベンダー選定は一気に具体化する。

5. 調達仕様に書く——要求文の型

「標準に準拠していること」という一文は、契約上ほとんど効力を持たない。準拠の範囲が定義されていないためである。次の六点を、機能要件と同じ強さで書く。

1. 取得できるデータ項目：機体ID、時刻、拠点、状態、イベント種別、作業量、エラーコードと、その意味の一覧を含む。
2. 形式と手段：どの方式で（API・ファイル出力・ローカル接続等）、どの粒度で、どの頻度で取得できるか。
3. 権限と所有：データの所有者は発注者であること。第三者提供の可否。解約後の返還と消去。
4. 期間と可用性：保持期間、遡及取得の可否、仕様変更時の事前通知期間と後方互換の扱い。
5. 制御インターフェース：目標レベルがL3以上の場合、指示・中断・優先度・異常時の振る舞いを含むインターフェース仕様書（ICD）の提出。
6. 適合の証明方法：後述する三段階の検証をどう実施し、誰が費用を持つか。

この六点は、ロボット選定の勘所とSIerの選び方で扱う選定プロセスの中で、RFP段階の必須回答項目として置くのが最も効く。契約後に依頼すると、ほぼ確実に有償の追加開発になる。

6. 「対応しています」を検証する三段階

適合性の確認は、次の三段階で行う。段階を飛ばした主張は、事実として扱わない。

第一段階：適合の主張と対応表。 どの仕様の、どの範囲に、どのバージョンで対応しているかを文書で提出させる。「対応」ではなく「未対応の項目」を書かせると精度が上がる。

第二段階：検証済み組み合わせの一覧。 自社が実際に接続確認を行った相手機種・上位システムの一覧と、確認日・確認条件。マルチベンダー対応を謳う上位システムほど、この一覧の提出を必須にする。

第三段階：実機での相互接続確認。 発注者の環境に近い条件で、対象の組み合わせを実際に動かす。確認項目は、正常系よりも異常系に比重を置く。片方が停止したとき、通信が切れたとき、時刻がずれたとき、想定外のエラーコードが来たときに何が起きるか。相互運用性の価値は平常時ではなく異常時に出る。

第三段階の費用と場所をどう確保するかが、実務上の最大の障害になる。個社で試験環境を用意できるのは大手に限られる。ここが、業界として場を持つ意味が最も明確に現れる論点である。

7. 供給側にとっての損得——標準対応を投資回収に載せる

供給側から見れば、標準対応は費用である。しかし回収の道筋がないわけではない。

• 案件獲得の条件になる。 相互運用性を調達仕様に書く発注者が増えれば、対応そのものが入札参加の条件になる。対応が遅れた側が失うのは開発費ではなく案件である。
• 統合工数の削減が原価を下げる。 SIerにとっては、案件ごとの個別変換開発が減ることが直接の利益になる。ロボットSIerという事業で述べた通り、SIerの収益性は再利用可能な資産の比率で決まる。
• 保守の予見性が上がる。 接続の仕様が外部化されていれば、障害時の切り分けが速くなり、保守原価のばらつきが縮む。これはRaaS事業のように稼働率が収益に直結するモデルで効いてくる。
• 競争領域を守れる。 協調領域を先に決めておけば、標準化の議論が競争領域に及ぶことを防げる。何を出すかを自ら定義する方が、外から線を引かれるより有利である。

8. 業界として持つべき二つの共有資産

個社の努力では埋まらない部分が二つある。

一つは参照アーキテクチャ。 層の分け方、各層の責任範囲、最小限の共通データ項目、用語の定義を、業種ごとに一枚の図と一冊の用語集にまとめたもの。これがあると、発注者ごとに一から設計する必要がなくなり、見積の比較も可能になる。

もう一つは相互接続を試せる場。 実機を持ち寄って組み合わせを確認し、結果を共有できる環境である。個社が自前で用意すると重複投資になるうえ、自社に有利な条件で試験してしまう。中立の場で実施し、うまくいかなかった組み合わせも記録として残すことに価値がある。

この二つは、コンソーシアム型プロジェクトの進め方で扱う集団的な取り組みの典型例である。参加者の顔ぶれ——ユーザー企業、メーカー、SIer、運用事業者、自治体、大学——が揃っていることが成立条件になる。

9. 現実的なロードマップ

第1段階と第2段階は、ベンダーに依頼せず自社で完了できる。ここを外部に委ねると、結局は特定ベンダーの実装が自社の定義になる。

10. 落とし穴

• プロトコルの一致を相互運用性と読み替える。 意味の層が揃っていなければ、同じ形式でずれた数字が集まるだけである。
• L4を最初から目指す。 動的入替の達成コストは、台数が少ない段階では回収できない。
• 「マルチベンダー対応」の文字を信用する。 検証済み組み合わせの一覧が出ないなら、その主張は未検証である。
• 正常系だけ確認する。 相互運用性は異常系で試さなければ確認したことにならない。
• 安全を標準化の議論に混ぜる。 安全は相互運用性より上位の制約であり、別の手続き（リスクアセスメント）で扱う。産業用ロボットの安全規格と法令対応の枠組みを崩さない。
• 一社で標準化しようとする。 買い手が一社で要求しても、供給側の投資判断は動きにくい。同じ要求文を複数の発注者が使うことに意味がある。

11. 発注前チェックリスト

• 工程ごとに目標の相互運用性レベル（L1〜L4）を宣言したか
• 自社のデータ辞書とID体系を、ベンダー選定より前に決めたか
• 取得データの項目・形式・権限・期間を、要求文として書いたか
• 解約後のデータ返還と消去を契約に含めたか
• 仕様変更時の事前通知期間と後方互換の扱いを合意したか
• 「未対応の項目」を提出させたか
• 検証済み組み合わせの一覧を入手したか
• 実機での相互接続確認を、異常系を含めて計画したか
• 適合性確認の費用負担を、契約前に決めたか
• 安全に関する要件を、相互運用性の議論と分けて管理しているか

まとめ

相互運用性は、技術の到達点ではなく調達の設計である。三層のうち意味の層は外部の標準では埋まらず、発注者が自ら定義するしかない。そして標準化が進むかどうかは、買い手が調達仕様に書くかどうかでほぼ決まる。供給側の善意や標準化団体の努力を待つ構図では、いつまでも「繋がらない」は繰り返される。

現実的な出発点は小さい。工程ごとに目標レベルを宣言し、自社のデータ辞書を決め、次の調達から六点セットを要求文に加える。この三つは外注せずに始められ、費用もほとんどかからない。にもかかわらず、これをやっている発注者はまだ少ない。

同時に、一社では埋まらない領域があることも事実である。参照アーキテクチャと、実機を持ち寄って相互接続を試せる場——この二つは、当事者が同じテーブルに着かなければ生まれない。うまくいった組み合わせよりも、うまくいかなかった組み合わせの記録の方が価値を持つが、それは自社単独では絶対に集まらない情報である。

RobiZyは、ユーザー企業・メーカー・SIer・運用事業者・自治体・大学が同席するNPO法人の会員組織である。ロボットを売らない中立の立場だからこそ、特定製品の利害から離れて、層の切り方や要求文の書き方、他社が実際にどの組み合わせでつまずいたかといった、通常は社外に出てこない情報が行き交う場になっている。標準化と相互運用性は、個社の努力より当事者の集合で動く領域である。関心のある方は、正会員としての参加をご検討いただきたい。