現場ネットワークとセキュリティ設計——情シスに止められないロボット導入

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

• ロボット導入が最後に止まる場所は、現場ではなく社内のネットワーク審査である。 機体が決まり、置き場所が決まり、投資も承認された案件が、稼働直前に情報システム部門から「この構成では社内ネットワークに繋げない」と差し戻される。技術的には正しい指摘であり、覆せない。
• 原因は対立ではなく、参加のタイミングである。 情報システム部門は反対しているのではなく、要件を知らされていない。設計が固まってから相談された側は、リスクを引き受けられない以上「不可」と答えるほかない。
• ロボットの通信要件は、機種選定の前に書き出せる。 制御・安全・映像・遠隔保守・データ収集は、必要な帯域も遅延許容も途切れたときの影響も全く違う。この五つを一つの「ネットワーク」という言葉でまとめて扱うことが、設計を破綻させる。
• 無線は「繋がるか」ではなく「切れないか」で設計する。 事務所で電波が届くことと、移動する機体が棚と人の間を通り抜けながら通信を維持できることは、別の問題である。
• 遠隔保守は、塞ぐのではなく「開き方を決める」のが正解である。 ベンダーが入れない構成にすると復旧が遅れ、常時開けておくと審査が通らない。誰が・いつ・どこまで・記録を残して入るかを設計すれば、両立できる。

ネットワークは、最後に相談される

ロボット導入プロジェクトの進み方には、ある典型がある。現場と経営で構想を固め（RX構想策定）、要件を書き（要件定義）、機種とSIerを選び（ロボット選定）、設置工事の日程まで引いたところで、初めて情報システム部門に「社内ネットワークに繋ぎたい」と依頼が行く。

そこから起きることは、おおむね決まっている。ベンダーの遠隔保守用の接続が認められない。機体が使う無線チャネルが既存の業務端末と干渉する。制御用の通信が社内の標準構成では通らない。映像を外部のクラウドへ送る設計が、社内規程の審査対象になる。どれも個別には解決できる論点だが、稼働予定日の一ヶ月前に同時に出てくると、日程は確実に崩れる。

ここで起きているのは、部門間の対立ではない。情報システム部門は、要件を知らされていないものについて責任を負えないだけである。彼らが守っているのは基幹システムであり、製造や物流の停止は経営インシデントになる。判断材料がないまま「繋いでよいか」と問われれば、答えは「不可」以外にない。

したがって解決策は、交渉術ではなく順序の変更にある。ネットワークとセキュリティの要件は、導入七工程の④システム設計で扱うものだと思われがちだが、実際には②要件定義・PoC・選定の段階で骨格を決めておかなければ間に合わない。本稿では、その骨格を「通信要件の棚卸し」「無線設計」「ゾーニング」「遠隔保守」「調達条項」「運用移管」の六つに分けて扱う。

一つの「ネットワーク」として扱わない

最初にやるべきことは、ロボットが必要とする通信を性質ごとに分解して書き出すことである。ロボット案件の通信は、少なくとも次の五種類が混在している。これらを一括りに「ネットワーク要件」と呼んでいる限り、設計も審査も進まない。

この表で決定的に重要なのは、安全系をネットワークの上に乗せないという原則である。非常停止や安全センサの信号は、通信が切れても機能しなければならない。無線や汎用ネットワーク経由の停止指示は、あくまで補助的な停止手段であって、安全機能そのものの代替にはならない。この点は安全設計の領域であり、ネットワーク設計の都合で妥協してよい部分ではない。

もう一つの要点は、途切れたときの影響が種類ごとに全く違うことである。映像が数秒欠けても生産は続くが、制御指示が数秒届かなければ機体は止まる。逆に、映像の帯域は他の四種類を合計したよりも大きくなりうる。この非対称性を無視して「全部を同じ回線に乗せて、足りなければ増速する」という設計にすると、映像のトラフィックが制御の遅延を悪化させるという、最も避けたい形の障害が起きる。

書き出しの粒度

要件定義書には、機器ごとに次を書く。ベンダーに問えば答えられる項目であり、答えられないベンダーがいるなら、それ自体が選定上の情報になる。

• 機器の台数と、同時に通信する最大数
• 通信の種類（上表のどれか）と、有線／無線の別
• 想定帯域（映像は解像度・フレームレート・台数から算出させる）
• 許容できる遅延と、通信断が何秒続いたときに機体がどう振る舞うか
• 通信先（社内サーバー／ベンダーのクラウド／インターネット）と通信の向き
• 使用するポートとプロトコル、暗号化の有無

最後の二項目は、情報システム部門が審査で必ず求めるものである。ここが空欄のまま持ち込まれた依頼は、審査に入る前に差し戻される。逆にこれが埋まっていれば、審査は「可否」ではなく「どう通すか」の議論から始められる。

無線は「切れないか」で設計する

移動するロボットを入れる現場では、無線の設計が成否を分ける。ここでの失敗は、ほぼ例外なく同じ形をとる。事務所や通路で電波強度を測り、「十分届いている」と判断してしまうのである。

移動体の通信で問題になるのは、電波が届くかどうかではない。機体が移動しながらアクセスポイント間を切り替える際に、通信が維持されるかどうかである。切り替えの瞬間に接続が一度落ちる構成では、機体は通路の途中で停止する。しかもこの現象は、特定の場所・特定の時間帯・特定の積載状態でしか再現しないことが多く、稼働開始後に「ときどき止まる」という最も原因究明の難しい形で表面化する。

現場側の要因も無視できない。金属棚、液体の入ったタンク、扉の開閉、パレットの積み上げ高さ——いずれも電波の通り方を変える。倉庫であれば、在庫が満杯のときと空のときで電波環境は別物になる。したがって電波調査は、最も条件の悪い状態で、機体が実際に走る経路に沿って行う必要がある。

無線設計で先に決めておくべき論点は次の通りである。

• 業務端末・ハンディターミナル・既存機器と、周波数帯やチャネルが競合していないか
• アクセスポイントの配置は、走行経路の重なりを前提にしているか（点で置いていないか）
• 切り替え時に通信が途切れた場合、機体は「その場停止」か「減速継続」か
• 在庫満載時・扉閉鎖時など、最悪条件での調査を実施したか
• 電波環境が悪化したときに、それを検知して知らせる仕組みがあるか

なお、無線モジュールを含む機器を日本国内で使う場合は、国内の電波に関する認証を受けたものである必要がある。海外から機体を直接調達する場合は特に、この点をベンダーに書面で確認しておく。認証のない機器は、性能に関係なく国内で使えない。

複数台のAMRを走らせる場合、無線の問題はフリート管理の問題と重なって現れる。台数が増えたときに何が非線形に効いてくるかはAMRのフリート管理で扱っている。

ゾーニング——境界をどこに引くか

情報システム部門の審査で本質的に問われるのは、「ロボットが乗るネットワークが、基幹システムや業務端末とどう分けられているか」である。ここに答えがなければ、他がすべて整っていても承認は下りない。

分け方には現実的に四つの方式があり、コストと運用負荷と安全性が段階的に変わる。

多くの現場での現実解は、二段目の論理分離に、境界での通信制御を組み合わせる形である。要点は、境界を越える通信を必要なものだけに絞り、向きを固定することにある。「ロボット側から情報系サーバーへ、決められた通信だけを送る」という設計は審査を通りやすく、「情報系からロボット側へ自由に到達できる」という設計は、ほぼ確実に差し戻される。

産業用制御システムのセキュリティについては国際的な規格群（IEC 62443 など）が整備されており、ゾーンと境界という考え方はそこから来ている。導入企業が規格そのものに準拠する必要は必ずしもないが、「ゾーンを定義し、境界での通信を管理する」という考え方を採ること自体は、規模を問わず有効である。情報システム部門はこの語彙で議論することに慣れているため、この枠組みで話を持ち込むだけで会話は大きく進む。

ロボットが複数ベンダーにまたがる場合、ゾーニングは統合設計の一部になる。責任分界点の決め方はマルチベンダー統合を参照されたい。

遠隔保守——塞ぐのではなく、開き方を決める

ロボット導入で最も意見が割れるのが、ベンダーによる遠隔接続である。

現場は開けたい。遠隔で診断できれば、復旧は数時間で済む。閉じれば技術者の到着待ちになり、停止時間は一気に伸びる。稼働率を守るうえで遠隔保守は極めて有効な手段である（保守と稼働率）。

情報システム部門は閉じたい。外部の事業者が社内ネットワークへ恒常的に到達できる経路は、管理対象として重い。特に、ベンダー側の作業者が誰であるかを発注者が把握できない構成は、承認しづらい。

この対立は、「開けるか閉じるか」の二択で議論する限り解けない。解けるのは、開き方を設計したときである。次の五点を決めれば、多くの組織で承認は取れる。

1. 常時接続にしない。 保守が必要なときに、発注者側の操作で経路を開く。作業終了後に閉じる。
2. 到達範囲を限定する。 対象のロボットと制御機器にのみ到達でき、社内の他のシステムには到達できないようにする。
3. 誰が入るかを特定できるようにする。 ベンダー共有のアカウントではなく、個人が識別できる形にする。
4. 記録を残す。 いつ、誰が、何をしたかのログを取得し、発注者側が後から確認できるようにする。
5. できることを明示する。 状態の閲覧までか、設定変更まで許すか、プログラムの書き換えまで許すかを、契約書に段階として書く。

この五点は、そのまま調達条件になる。契約前に提示すれば、ベンダーは自社の標準的な保守手順との差分を説明できる。稼働後に持ち出すと、「その構成では保守できない」と言われて、保守条件そのものの再交渉になる。順序を間違えないことが重要である。

調達時にベンダーへ確認すること

ネットワークとセキュリティに関する確認事項は、選定段階の質問票に組み込んでおく。稼働直前に問い合わせても、答えは「確認します」以外に返ってこない。

下の三項目は見落とされやすいが、影響は長い。ロボットは十年単位で使われる一方、そこに載るソフトウェアの保守期間はそれより短いことがある。保守が終わった機器を、更新されないまま社内ネットワークに繋ぎ続ける状態は、導入時には見えない負債として残る。契約時点で終了時期の見通しを聞き、稼働データの持ち出し可否と併せて条項に落としておく。

映像や音声を扱う場合は、ネットワーク設計と同時に、取得したデータの保持方針と使用範囲も決める必要がある。この点は現場AIのガバナンスで扱っている。

運用に引き渡す

設計と工事が終わっても、ネットワークは完成しない。誰が見続けるのかを決めない限り、半年後には誰も状態を把握していない状態になる。定着（工程⑥）と運用（工程⑦）へ引き渡す際には、次を明文化しておく。

• 監視の主体。 通信状態の異常を、誰がどの画面で見るのか。現場か、情報システム部門か。
• 一次切り分けの手順。 「機体が止まった」ときに、機械の問題か通信の問題かを、現場の担当者が数分で切り分けられる手順があるか。これが無いと、すべての停止がベンダー呼び出しになる。
• 変更管理。 現場のレイアウト変更、棚の増設、他システムの導入時に、ロボットの通信への影響を誰が確認するか。ネットワークは工事ではなく設定変更で壊れる。
• 定期確認。 アクセスポイントの状態、ソフトウェアの更新状況、遠隔保守ログの確認を、いつ誰が行うか。

現場が自分たちで一次切り分けまでできる状態を作れるかどうかが、稼働率の実感を大きく変える。運用体制の設計全般は定着化と運用を参照されたい。

まとめ

ロボットのネットワークとセキュリティは、専門性の高い領域に見えるため、後回しにされやすい。しかし本稿で挙げた論点の大半は、高度な技術判断ではなく、「先に書き出して、先に相談する」だけで解ける段取りの問題である。

要点は三つに集約できる。第一に、通信を五種類に分解して要件として書くこと。第二に、情報システム部門を設計が固まる前に巻き込むこと。第三に、遠隔保守を塞ぐのではなく開き方を設計すること。この三つを②要件定義の段階で済ませておけば、稼働直前の差し戻しはほぼ起きない。

RobiZyは、ロボットを売らないNPO法人として、導入企業の側に立つ中立のコーディネーターの立場をとっている。だからこそ、特定ベンダーの標準構成に合わせるのではなく、その現場の情報システム部門が承認できる形はどれかという観点で、要件の書き出しからベンダーへの確認事項の設計まで伴走できる。

「ロボットを入れたいが、社内のネットワークやセキュリティの審査をどう通せばよいか分からない」——構想段階のご相談を歓迎する。機種も予算も決まっていない段階のほうが、打てる手は多い。