複数ベンダー・複数機種の統合とデータ連携

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

• 「繋がらない」は技術の問題として現れるが、原因はほぼ調達の順番にある。 1台目を単独最適で選び、2台目を別の稟議・別のベンダーで入れた結果、後から統合費用が丸ごと追加で乗る。
• 統合は6つの層に分けて考える。 空間・安全・制御・データ・運用・契約。このうち現場で最初に破綻するのは制御層ではなく、運用層と契約層である。
• 統合方式は4パターンしかない。 直結（Point-to-Point）／上位オーケストレーター（WES・FMS等）／データ基盤経由の疎結合／人による運用統合。台数と変更頻度で選ぶ。安易な直結は、3台目で組み合わせ爆発を起こす。
• インターフェース仕様書（ICD）を発注前に作れるかどうかが分水嶺。 信号・API・データ項目・タイミング・異常時の振る舞い・試験方法の6点セットを、要件定義の段階でベンダーに書かせる。
• 障害時に「誰が最初の電話を取るか」を契約に書く。 これを決めていない現場は、止まった30分をベンダー間の責任確認に使う。統合の価値は、平常時ではなく異常時に出る。

複数ベンダー・複数機種の環境は、避けるべき失敗ではない。単一ベンダーで全工程を賄える現場はほとんど存在せず、搬送はAMR、ピッキングは協働ロボット、外観検査は画像AI、上位は既存のWMS——という構成はむしろ標準形である。問題は混在そのものではなく、混在することを前提に設計していないことにある。本稿は、2台目・2社目が入る前後で必ず発生する統合の論点を層ごとに整理し、発注前に潰しておくべき項目を具体的に示す。

1. なぜ「繋がらない」は後から発覚するのか

単独導入のPoCは、たいてい成功する。1台のロボットが1つの工程を、決められた条件下で動かすだけなら、ベンダーは自社の閉じた世界で最適化できるからだ。問題は2台目である。

典型的な発覚の経路は3つある。

第一に、稟議の単位が工程ごとに切られていること。搬送の自動化と検査の自動化は別の課題として起票され、別のタイミングで、別の担当者が、別のベンダーに相談する。それぞれの見積は妥当だが、両者を繋ぐ費用はどちらの見積にも入っていない。統合費用は最初から誰の予算にもない。

第二に、PoCの成功条件が「単体で動くこと」に設定されていること。PoC（実証実験）の設計と評価で述べた通り、評価軸を単体性能に置くと、統合性は検証されないまま本番に進む。他機と同じフロアで、同じ時間帯に、同じ通路を使って動いたときに何が起きるかは、単体PoCでは絶対に分からない。

第三に、「APIがあります」を統合できると読み替えてしまうこと。APIの存在と、必要な情報が必要なタイミングで取れることは別問題である。稼働状態は取れるが、進行中タスクの残り時間は取れない。エラーコードは取れるが、そのコードの意味を示す一覧は非公開。この種のギャップは、繋いでみるまで見えない。

結果として、統合費用はプロジェクトの終盤に、最も交渉力の弱いタイミングで発覚する。これを避ける唯一の方法は、RX構想策定の段階で「将来2社目・3社目が入る」を前提として書き込み、1社目の契約時点で統合に必要な条件を要求しておくことである。

2. 統合を6つの層に分解する

「統合」という一語で議論すると必ず噛み合わない。統合を層に分け、層ごとに責任者と成果物を決める。

現場で最初に破綻するのは、多くの人が想像する③制御層ではない。⑤運用層と⑥契約層である。制御が繋がっていなくても、人が間に立てば当面は回る。しかし「止まったとき誰に電話するか」が決まっていない現場は、初日から回らない。

層を分ける実務上の利点は、すべてを繋がなくてよいと判断できることにある。①②⑤⑥は必ず整合させる必要があるが、③④は投資対効果で判断してよい。2台のロボットが物理的に干渉しないなら、制御層を繋がず運用層で分離するのが最も安い解である場合が多い。

3. 統合方式の4パターンと選び方

選定の順序は、Dから疑うのが実務的である。繋がないで済むならそれが最も安く、最も壊れにくい。次にC、そしてB、最後にAを検討する。Aの直結は個別最適としては最速だが、接続点の数は台数の増加に対して急に増える。3社目を入れる時点で、既存の接続をすべて回帰試験する羽目になる。

Bを選ぶ場合の落とし穴は、上位製品が対応する下位機種の範囲である。「マルチベンダー対応」と謳っていても、実際に検証済みの組み合わせは限られる。検証済み機種リストの提出を、選定時の必須要件にする。ロボット選定の勘所とSIerの選び方で述べた「実績の確認は同一構成で」という原則は、統合においてさらに重い。

4. インターフェース仕様書（ICD）に何を書くか

ICD（Interface Control Document）は、統合における唯一の合意文書である。ロボット導入の要件定義書が「何を作るか」を定めるのに対し、ICDは「境界で何をやり取りするか」を定める。発注前に、以下の6点セットをベンダーに書かせる。

特に⑤を軽視してはならない。統合の事故はほぼ全て異常系で起きる。上位が落ちたときロボットは止まるのか動き続けるのか、通信が復旧したとき指示は再送されるのか破棄されるのか——この2問に即答できないICDは未完成である。

⑥の統合試験も、書かせておかないと必ず揉める。ベンダーAは「自社機は仕様通り」と言い、ベンダーBも同じことを言い、繋いだ状態の責任者が誰もいない状態になる。統合試験の実施責任者を1名、契約書に明記する。

5. データ連携——共通イベントスキーマを先に決める

データ層で起きる問題は、技術ではなく語彙の不一致である。ベンダーAの「稼働中」とベンダーBの「稼働中」が同じ状態を指していない。Aは電源が入っていれば稼働、Bはタスク実行中のみ稼働、という具合だ。この状態で稼働率を比較しても意味がない。

対策は、発注者側が共通イベントスキーマを先に定義し、各ベンダーにそこへの写像を要求することである。ベンダー独自の状態を捨てさせる必要はない。「あなたの状態Xは、当社の共通状態のどれに当たるか」の対応表を出させればよい。

最小限の共通スキーマは、次の要素で足りることが多い。

• 時刻：タイムゾーンと精度を統一する。機器ごとの時刻ずれは、後から原因分析を不可能にする
• 機器ID：発注者側で採番する。ベンダーのシリアル番号をそのまま使わない
• 場所ID：エリア・棚・工程の呼び名を全社で1つに統一する
• イベント種別：開始／完了／異常／停止／復旧／待機の粒度に丸める
• タスクID：どの指示に紐づくかを追跡できるようにする。これが無いと工程横断の分析ができない
• 異常コードと分類：ベンダー固有コードに加え、発注者側の分類（設備要因／運用要因／外部要因）を持つ

このスキーマを持てば、ロボット導入のKPI設計と効果測定で扱った稼働率や停止要因の分析が、機種をまたいで初めて成立する。逆に言えば、共通スキーマ無しに「全ロボットのダッシュボードを作りたい」という要求は実現しない。ダッシュボードは表示の問題ではなく、語彙の問題である。

なお、データ層の統合は制御層より先に着手できる。制御を繋ぐには停止時間と試験が必要だが、データを集めるだけなら現行運用を止めずに進められる。順序として、まずデータ層で全体像を見えるようにし、その実データを根拠に制御層の投資判断をするのが、失敗の少ない進め方である。

6. 責任分界点と契約——「誰が最初の電話を取るか」

統合環境の運用で最も重要な設計は、技術ではなく体制である。

搬送ロボットが検査工程の前で止まった。原因は、検査装置からの完了信号が来ていないからかもしれないし、ロボット側の受信不良かもしれないし、上位システムの指示ミスかもしれない。このとき現場が最初に電話するのは誰か。

これを決めていない現場は、3社に順番に電話をかけ、3社ともが「当社の範囲ではありません」と答える時間を過ごす。統合の価値は、平常時の効率ではなく、この30分を5分にすることにある。

契約段階で決めるべきことは4つ。

1. 一次窓口（Single Point of Contact）を1社に定める。 統合責任を負う1社を決め、その対価を払う。無料で引き受ける会社は、実際には引き受けていない。
2. 切り分け手順を文書化する。 現場の担当者が5分でできる一次切り分け（どのランプが点いているか、どの画面に何が出ているか）を手順書にする。ベンダーに電話する前に、切り分け結果が揃っている状態を作る。
3. 責任分界点を図で描く。 文章ではなく図にする。信号線1本、API1本の単位で、どちらの側かを塗り分ける。曖昧な箇所が残ったら、そこが将来揉める箇所である。
4. 変更時の費用負担ルールを先に決める。 統合環境では、片方の機器のソフト更新が他方を止める。「更新時の相互影響確認は誰の費用か」を書いていない契約は、更新のたびに交渉になる。

これらは定着化・運用設計の一部として設計するのが自然である。統合は導入時の一度きりの作業ではなく、機器が増減し更新されるたびに再発する継続的な運用課題だからである。

安全に関わる連動——非常停止の相互連動や、人が入域したときの全機停止——については、ロボットの安全とリスクアセスメントで扱った通り、統合構成そのものを対象にリスクアセスメントをやり直す必要がある。単体で評価済みの機器を並べても、組み合わせた状態の評価にはならない。

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

2社目以降を発注する前に、以下を確認する。1つでも「不明」が残るなら、その項目は追加費用として顕在化すると考えてよい。

このチェックリストの目的は、ベンダーを追い詰めることではない。統合に必要な作業を、誰かの見積の中に必ず入れることにある。どの見積にも入っていない作業は、誰もやらないか、後から追加で請求される。

まとめ

複数ベンダー・複数機種は、避けるべき状態ではなく、自動化を進めれば必ず到達する標準的な状態である。問題は混在そのものではなく、混在を前提としない調達と設計にある。

要点を再掲する。統合は6層に分けて考え、破綻しやすい運用層と契約層を最優先で設計する。統合方式は「繋がない」から順に検討し、安易な直結を避ける。ICDの6点セット、とりわけ異常時の振る舞いと試験責任を発注前に確定させる。データ層は共通イベントスキーマを発注者側で先に定義し、制御層より先に着手する。そして障害時の一次窓口を1社に定め、その対価を払う。

これらの判断は、いずれも特定のベンダーの利害と衝突しやすい領域にある。どのベンダーも自社の範囲では正しいことを言うが、境界線の上に立って全体の損得を判断する役割は、構造的に空席になりがちである。

RobiZyはロボットを売らないNPO法人であり、特定のメーカー・SIerの立場を取らない中立のコーディネーターとして、導入7工程（①RXビジョン／構想策定 ②要件定義・PoC・選定・組成 ③構築スケジュール／ToBe業務設計 ④システム設計 ⑤開発・導入 ⑥定着化 ⑦運用）の全体を伴走している。統合方式の選定、ICDの要求水準の設定、責任分界点の設計といった「境界線の上の意思決定」は、まさに中立の立場が最も価値を出す領域である。

「2台目を入れたいが、既存機とどう繋ぐか分からない」「複数社の見積を比べたいが、統合費用がどこに入っているか読めない」——このような構想段階のご相談を歓迎する。仕様が固まっていない段階、あるいは何から手を付けるべきか分からない段階であるほど、早くご相談いただく価値がある。