エグゼクティブ・サマリー
- ロボット導入が最後に止まる場所は、現場ではなく社内のネットワーク審査である。 機体が決まり、置き場所が決まり、投資も承認された案件が、稼働直前に情報システム部門から「この構成では社内ネットワークに繋げない」と差し戻される。技術的には正しい指摘であり、覆せない。
- 原因は対立ではなく、参加のタイミングである。 情報システム部門は反対しているのではなく、要件を知らされていない。設計が固まってから相談された側は、リスクを引き受けられない以上「不可」と答えるほかない。
- ロボットの通信要件は、機種選定の前に書き出せる。 制御・安全・映像・遠隔保守・データ収集は、必要な帯域も遅延許容も途切れたときの影響も全く違う。この五つを一つの「ネットワーク」という言葉でまとめて扱うことが、設計を破綻させる。
- 無線は「繋がるか」ではなく「切れないか」で設計する。 事務所で電波が届くことと、移動する機体が棚と人の間を通り抜けながら通信を維持できることは、別の問題である。
- 遠隔保守は、塞ぐのではなく「開き方を決める」のが正解である。 ベンダーが入れない構成にすると復旧が遅れ、常時開けておくと審査が通らない。誰が・いつ・どこまで・記録を残して入るかを設計すれば、両立できる。
ネットワークは、最後に相談される
ロボット導入プロジェクトの進み方には、ある典型がある。現場と経営で構想を固め（RX構想策定）、要件を書き（要件定義）、機種とSIerを選び（ロボット選定）、設置工事の日程まで引いたところで、初めて情報システム部門に「社内ネットワークに繋ぎたい」と依頼が行く。
そこから起きることは、おおむね決まっている。ベンダーの遠隔保守用の接続が認められない。機体が使う無線チャネルが既存の業務端末と干渉する。制御用の通信が社内の標準構成では通らない。映像を外部のクラウドへ送る設計が、社内規程の審査対象になる。どれも個別には解決できる論点だが、稼働予定日の一ヶ月前に同時に出てくると、日程は確実に崩れる。
ここで起きているのは、部門間の対立ではない。情報システム部門は、要件を知らされていないものについて責任を負えないだけである。彼らが守っているのは基幹システムであり、製造や物流の停止は経営インシデントになる。判断材料がないまま「繋いでよいか」と問われれば、答えは「不可」以外にない。
したがって解決策は、交渉術ではなく順序の変更にある。ネットワークとセキュリティの要件は、導入七工程の④システム設計で扱うものだと思われがちだが、実際には②要件定義・PoC・選定の段階で骨格を決めておかなければ間に合わない。本稿では、その骨格を「通信要件の棚卸し」「無線設計」「ゾーニング」「遠隔保守」「調達条項」「運用移管」の六つに分けて扱う。