ロボットと人が協調する社会。
そんな未来を、単なる空想ではなく「あたりまえの日常」として実現しようとしている人物がいる。

株式会社ビルポの赤津 冬馬だ。

彼は大手IT企業でネットワークエンジニアとして基地局整備や鉄道の通信設計に携わったのち、株式会社ビルポへ入社。建物運用におけるIoT技術やロボットを軸としたDXの世界へと活躍の場を広げてきた。

では、彼はなぜ建物というフィールドで、ロボットと人の協調というテーマに挑み続けているのか。
その原点にある思想や、見据えている未来について、解説を交えながら本人の言葉で紐解いていく。

現場のリアルから見えた、ロボット運用の「壁」

「ロボットは本来、人の代わりに働いてくれる存在のはずなのに、
ひとつの建物にロボットが増えれば増えるほど、現場スタッフの負担が増えていく。
そんな状況がどの現場でも発生していました。」

 

赤津がビルポに参画して最初に感じたのは、ひとつの矛盾だった。
ロボットが増えれば増えるほど、現場スタッフが混乱し、負担が増えるのである。

 

「ロボットが数台動いている内は大きな問題は起きませんでした。
しかし、清掃・搬送・警備など役割の異なるロボットが、更にメーカー混在で同じ建物の中に増えていくと、途端に色々な問題が発生していったんです。」

代表的な例は次の通りだ。

メーカー混在による管理の煩雑化

メーカーごとに管理アプリが異なるため、エラー発生時の原因確認、現在位置、タスク履行状況などを見るだけでも複数アプリを横断する必要がある。
結果として、日常的な監視・対応が煩雑化し、現場の手間を増やしてしまう。

ロボット同士のデッドロック

狭い通路に複数ロボットが同時に侵入し、互いのセンサーが干渉して身動きが取れなくなる（デッドロック）。
止まったロボットを助けに行く作業が常態化すると、ロボット導入の意義が揺らぎ始める。

エレベーター（ELV）前の乗降トラブル・渋滞

ロボットがELVを呼んだ際、乗りたいロボットと降りてくるロボットが正面衝突し、ELV前で停止（スタック）する。
さらに、複数ロボットがドア前に滞留して通路を塞ぎ、人の導線を妨げる。

こうした事象が頻発する。
こうして現場は、代わりに働いてくれるはずのロボットの世話に追われる状態に陥っていた。

国内の既存群管理プラットフォーム・設備連携システムが抱える問題

「はっきり言って、ロボット単体での複数台運用では効率化につながりません。

一見、ロボットに業務を任せることで効率化できているように見えますが、
1日の業務時間全体で見るとロボットの世話をする時間が平常業務の負担になっていて、更にやることが増えてしまっている、なんてことがほとんどです。

実際に清掃中のロボットと清掃タスクが終わり帰還中のロボットが衝突し、その内の片方が破損する、なんてことがあり、修理のためにメーカーへ連絡したり、責任区分はどこにあるのかなどでもめたり……。

 

再発防止のために稼働時間をズラす、マップを調整する、といったような対応で一旦はなんとかなりましたが、ロボットの担当エリアが変わったり、台数を増やすたびにこういった調整が必要になり本当に大変な思いをしていました。

色々と試行錯誤して何とか問題が発生しないようにしても、全ての潜在的な問題までは取り除けず、何かあるたびにそれぞれのロボットに対応した個別のアプリを開いて、どこにいるか、どんな状況なのかを確認するなど、とにかくしんどい日々が続き、何のためのロボットなのか分からなくなっていました。

こういった実体験から、なるべく人の手を介在させずに運用するための“仕組み”が必要だと強く感じ、色々と調べている中で、どうやらロボットが群で管理できるようになったり、ELVと連携することでロボットが自動で階を移動できるようになるシステムみたいなものがあることがふんわりとわかったんです。

それからは、まずは日本で使われているものはどんなものなのかを調査することから始め、国内で提供されているロボットの群管理プラットフォームや設備連携できるシステムを吟味していった結果、これはこれで様々な問題が見えてきました。」

 

① 国内の既存群管理プラットフォームの課題

• 拡張性が低い
  特定メーカーのみに対応など、連携できるロボットが限られ、ユースケースに応じた入れ替えや追加が難しい。

 

• 費用が高い（初期構築費用・月額利用料）
  屋外での運用に比べ、屋内運用では管理費がシビアになりやすく、プラットフォーム費用と削減効果が釣り合わず、PoC（概念実証）では成立しても、実運用（長期運用）は難しい。

 

• 多台数制御に向かない
  ロボットの制御がイベントドリブン（何かしらのイベントが発生したことをきっかけに処理が実行される制御方式）ではなく、「マップ上で優先エリアや待機場所をルール定義することで制御する」方式を採用しており、台数増加に伴いルールが肥大化し再定義の頻発や、制御が追いつかずロボットがタスク中に停止する等、運用の限界が想定される。さらにルールの変更設定がベンダ依存になり、実運用までのリードタイムも増える。

 

② 建物設備との連携の課題

• ELV連携が“ロボット1台ごとの課金”
  ELVとロボットの連携をスムーズに可能にするシステムを提供しているベンダのサービスはELVと連携するロボット1台ずつにランニングコスト（ライセンス費用）がかかり、台数を増やす程コストが嵩んでしまうことでロボット運用による削減効果が出なくなり、何のためのロボットなのかわからなくなる。

ロボット台数の増加、メーカー混在、設備連携、長期運用──。
これらを前提にした時に、現状の国内プラットフォームでは複数台のロボットが協調した、
本当のロボット社会実装は厳しい道に見えた。

 

「RMF」との出会い 集中管理という発想

「国内の既存プラットフォームを活用した運用に限界を感じ、藁にも縋る思いで解決策を模索していた時に、ふと着目したのが、海外のRMF（Robotics Middleware Framework）というプラットフォームでした。」

 

RMFはシンガポール政府が主導となって開発された、ロボット導入の促進・安定した運用の実現を掲げて複数メーカー・複数台のロボットと建物設備を同じ空間で安全かつ効率的に協調制御するための、いわば共通の交通管制基盤である。

一見するとよくある群管理プラットフォームの一種に見えるが、調査を進めるほどに、RMFと他のプラットフォームとの違いが“特異な制御方式”にあることが分かった。

 

RMFは”司令塔”の役割を担い、連携しているロボット全ての位置・状態を把握し、それらの情報をもとに次の様な判断・制御を行う。

 

• 通路・部屋などの情報を全てのロボット共通の地図情報として持つ、共有の交通リソースとして扱う
• 「誰が」「いつ」「どこを通るか」を 空間だけでなく時間軸も含めて予約・調整 する
• ロボットのみならず、建物設備（ELV、自動ドア）の情報も司令塔側へ集約されている

 

RMFは“司令塔”が全体を把握し、複数ロボットの行動を一元判断・指示する方式である”集中管理制御方式”を採用していた。


集中管理制御と分散協調制御 「効く」のはどちらか

ここで、この話の核となる”集中管理制御”と”分散協調制御”の違いを整理しておきたい。

 

集中管理制御の特徴（RMF）

建物全体の地図、ロボットの位置・状態、設備情報、運用ルールや優先順位を集約し、全体最適になるよう調整する。
これは、人間社会における交通管制センターが、道路全体の状況を把握したうえで信号や交通流を制御する構造に近い。

① 全体最適を前提とした判断が可能

司令塔は全ロボットの状況を把握しているため、

• 渋滞や衝突を未然に防ぐ経路割り当て
  （何秒後にこのロボットはここを通る、という情報を元にした制御）
• ロボットの一か所への集中を避けるエリア調整
• タスクの優先順位制御

といった全体視点での最適化が可能となる。

② ロボット側をシンプルに保てる

複雑な判断を司令塔に集約することで、ロボット側は

• 指示された経路を走行する
• 指示されたタイミングで待機・移動する

といった実行主体としての役割に専念できる。

これにより、

• 機体コストの抑制
  （ロボットに高性能な機能を求めずともパフォーマンスが発揮できる）
• メーカー差分の吸収
• 混在環境での運用容易性

が実現される。

③ 運用ルール変更への耐性が高い

特定時間帯は人優先、特定エリアは通行禁止、といったルール変更も司令塔であるRMFへ、こういったルールで運行する、という設定変更を実施するのみで対応可能である。

個々のロボット毎の改修や設定変更が不要となり、実運用における現場の負担軽減や、運用の柔軟性向上へつながる。

集中管理制御の課題

一方で、集中管理制御には以下の課題が存在する。

• システム障害時の影響範囲が大きい
• 通信インフラへの依存度が高い
• 初期設計段階での全体設計が重要となる

ただし近年は冗長化やフェイルセーフ設計により、これらの課題は実用上許容可能な水準まで解消されつつある。

集中管理制御の本質は、賢くなるべき対象をロボット個体ではなく、システム側とする点にある。

個々のロボットの能力差を前提としつつ、全体で成果を最大化する構造をつくることこそが実運用における最適解であり、コスト・運用継続性を重視する建物管理の現場において最も現実的かつ持続可能なロボット制御方式のひとつと言える。


分散協調制御の特徴（国内の既存プラットフォーム）

反対に、前述した国内の既存ロボット管理プラットフォームは”分散協調制御”方式をとっている。

ロボット制御における分散協調制御とは、司令塔を持たず、各ロボットが自律的に判断しながら、互いに協調して動作する制御方式を指す。

分散協調制御では、各ロボットが周囲の状況・共有ルールをもとに、
「次に自分がどう動くべきか」を自分自身で判断し、全体の秩序は、あらかじめ定義されたルールやローカルなやり取り（近くのロボット同士のセンサー測位による回避など）によって結果的に保たれる、という設計思想である。

これは人間社会に例えると、信号機のない交差点で、各自が譲り合いながら進む状態に近い。

①単一障害点がない

• 基幹となるシステムがダウンしても、個々のロボットは動作を継続できる。

②スケーラビリティが高い

• ロボット台数が増加しても、システムへの処理負荷が急激に増大しにくい。

③通信依存度が比較的低い

• ネットワークが不安定な環境でも、最低限の動作が可能である。

分散協調制御の課題

一方で、実運用の観点では明確な課題も存在する。

① ロボット側が高度化・高コスト化しやすい

各ロボットが状況判断を行うため、衝突回避といった機能が個々のロボットの性能に依存している。
その結果、分散協調制御を前提とした場合はロボットが高価になりやすく、メーカー間の実装差分拡大を招きやすい。

② 全体最適より「局所最適」に陥りやすい

各ロボットは「自分の周囲」しか把握できないため、

• 最適なルートを通らず全体として遠回りになる
  （タスクの遅延が起こる）
• 一部のエリアで渋滞が起こりやすい
• 暗黙の待ち合い（スタック状態）が発生する

といった問題が生じやすい。

③ 運用ルールの追加がロボット実装負荷に直結する

• 運用ルールの追加が、そのままロボット側の改修コストに直結しやすい。
  また、ロボットを追加したルールに従わせるための調整負荷も高い。

「建物の中という空間では、清掃、警備、搬送など、立場も役割も異なる多くの人たちが、同じ時間と場所を共有しながら働いています。

しかもそのルールは、時間帯や人の流れによって日々変わっていき、綿密なコミュニケーションを取りながら業務を成立させている。私はこれまで数多くの現場に関わる中で、そうした多主体・多業務が同時に重なり合う業務の難しさを、当たり前のように目にしてきました。

 

だからこそ、ロボットの導入を考えるときに、ずっと違和感があったんです。
この複雑に絡み合った業務を、ただそのままロボットに置き換えてしまっていいのか、と。

 

各ロボットがそれぞれ自律的に判断する分散協調型の制御は、一見すると簡単で柔軟性のあるやり方に見えます。
しかし、建物内業務のリアルに当てはめたとき、人同士の営みだからこそ成立している微妙な調整をロボットのみに任せるのは不可能だと思いました。

建物内業務特有の複雑さを前提に考えたとき、各ロボットに判断を委ねる構造そのものが、コスト増大、運用の不安定さにつながる。

 

結果として現場ごとの調整負荷が増え、ロボットを入れたのに、気が付けば逆に大変になったという状況を生んでしまう。

 

その課題をどうにか解決できないかと考え続けた末に、私が選択したのが、集中管理制御型のRMFでした。

RMFは、すべてのロボットを一元的に把握する“司令塔”を据え、個々のロボットに過度な判断をさせない設計思想を持っています。

 

交通管制や最適化はプラットフォーム側が担い、ロボットは自分の得意な役割に集中する。

この考え方は、現場のオペレーションがしっかりしているからこそ個々のパフォーマンスが発揮できるという、これまで現場で見てきた人達の働き方にも、どこか重なる部分がありました。

 

RMFは、単にロボット同士をうまく協調させるための仕組みではありません。
ロボットも含めた建物内の業務全体を、破綻させず、安定して回し続けるための仕組みだと私は捉えています。

 

ロボットを入れることが目的ではありません。
業務がきちんと回り、削減効果が生まれ、その結果として現場で働く人たちが本当に楽になること。
そのゴールから逆算したとき、最も筋が通っていた答えが、RMFだったんです。」

「アダプター方式」連携がもたらす価値

ここまでロボット運用における交通整理の重要性を説いてきたが、持続的なロボット運用を実現するためにはもうひとつ欠かせない要素がある。

それは、”システムと個々のロボットの連携方式”である。

 

多くのロボット群管理プラットフォームでは、ロボットを連携する際に

 

• ロボット側に特定のAPI実装を求める
• プラットフォーム側の独自プロトコルへの対応を必須とする
• 運用ルールの理解や判断機能をロボット側に持たせる
  

といったように、エッジ側（ロボット側）に適応を強要する構造になりがちである。

こういった制約の中ではメーカー側に工数や負担を強いる結果となり、連携できるロボットの機種数に制限がかかる、連携開発におけるリードタイムが長くなり現地実装が遅れるといった問題が生じる。

この点において、RMFが他のロボット群管理システムと比べて優れている最大のポイントが、アダプター（Adapter）という思想と構造である。

 

RMFにおけるアダプターとは、ロボット本体や既存設備を改造することなく、RMFの共通制御層と接続するための変換レイヤーを指す。

 

RMFは、 「すべてのロボットを同じ仕様・同じ思想に揃える」という発想ではなく

• ロボットはロボットごとに癖（長所と短所）がある
• メーカーごとに開発思想や制御方式が異なる
• 建物設備は既存資産としてすでに存在している（既設物件の場合）

という現実を前提条件として開発されている。

そのうえでRMFは、違いを吸収する場所をロボット側ではなく、アダプター側に集約する方式を採用している為、

• ロボットは「自分の得意な動き」だけを実装していればよい

• RMFとの接続仕様はアダプター側で持つ
  

• 交通整理や優先順位判断はRMF本体が担う

という明確な責務分離がなされており、この点が思想レベルで他システムと決定的に異なる。

 

アダプターがもたらす実運用上の価値

① メーカー混在環境に強い

アダプター方式により、

• 清掃ロボット
• 搬送ロボット
• 警備ロボット

といったメーカーも用途も異なるロボットを、同一の管理・交通整理ロジックで扱うことが可能となる。

これは、建物内運用において極めて重要な特性であると同時に個々のロボット毎に制御ロジックの調整を行う必要が無く、開発工数を抑えることでスムーズな現地導入を可能にしている。

また、機種毎のアダプターは1度作成すれば他物件でRMFと接続する際もそのまま活用でき、導入時の立ち上げやロボットの途中付け替えをスムーズにできる。

 

② 既存設備に大きく干渉しない

ELV、自動ドア、セキュリティシステムなどの設備との連携も、RMFでは個々のロボット毎ではなくアダプターを介して接続される。

そのため、

• 建物設備側の大規模なシステム変更を必要としない
• 設備ベンダー依存を最小化できる

という構図が成立する。

また、最大のメリットはELVと直接連携するのはロボットでは無くRMFであり、
RMFがアダプターを介して連携しているロボットを内包しているため、ひとつのライセンス費用でELVとの連携が可能であり、設備連携時の費用を最小化できる点である。

 

③ システム全体の価値が積み上がる

アダプターは一度作ればそれで終わりではなく、

• 新しいロボットが増える
• 新しい設備が増える
• 新しい運用ルールが生まれる

このたびに、アダプターを追加・拡張するだけでプラットフォームとしての全体価値が向上する。
これはロボット1台ごとに個別開発を積み重ねる方式とは異なり、価値が蓄積していく構造である。

 

RMFの特徴は高度な交通整理アルゴリズムそのものだけではなく、

• ロボット側やメーカー側へ負担をかけすぎない
• 建物設備への干渉を最小限に抑える
• 将来の拡張を前提に設計されている

これらの前提を基にしたアダプターを採用している。

この構造こそが、 RMFを実運用・実ビジネスに耐えるロボット群管理プラットフォームにたらしめている最大の理由である。


「ロボット群管理プラットフォームを現場で導入する際、必ずと言っていいほど壁になるのが、”導入したいロボットと、システム側をどうつなぐか”」という連携開発の部分でした。

 

私自身、これまでいくつもの現場でロボット導入に関わってきましたが、
ロボットそのものよりも、このつなぎ込みの工程がボトルネックとなり導入計画が止まってしまうケースを何度も見てきました。

 

その点で、RMFのアダプター方式は非常に現実的だと感じています。新規でロボットを導入する場合でも、ロボットの機種を増やす場合でも、運用の途中で別の機種へ入れ替える場合でも、さらにはエレベーターや自動扉といった設備と連携する場合でも、同じ考え方で実装を進めることができるからです。

 

アダプターがロボットや設備ごとの違いを吸い上げて、連携に必要な制御や接続の手順を分かりやすく整理してくれる。そのおかげで、現場ごとにゼロから作り直すような負担を大きく減らすことができます。

 

これは単にシステム的な開発がしやすいという話ではありません。
導入時の立ち上げがスムーズになるだけでなく、将来、ロボットや設備が増えたときにも無理なく拡張していける土台になるという点が重要なんです。

 

よく耳にする話ですが、そもそも”効率化のためにこのプラットフォームやシステムを入れるから、それと連携できる、これまで連携実績のあるロボットを導入する”という考え自体がおかしいと思うんです。

”どんなことをロボットにやらせたいのか”という考えが前提としてあるはずで、ロボット達はそれぞれ得意、不得意がはっきりしています。

 

清掃ロボットであれば、この子は水ぶきが得意、とかこの子は除塵が得意、といった特徴があり、更に深掘りしていけば、ブラシの形状によって清掃させたい床材との相性差があって、価格もできることもロボット毎に区々、といった中で目的に合ったロボットを選定した上で導入、あるいは付け替えしていくのが正しいと考えています。

 

ネットサーフィンや事務処理が目的であれば安価なノートパソコンを選びますし、
最新のゲームや高度な動画制作がしたいなら高価なデスクトップのパソコンを選ぶ、
このゲームがやりたいからプレステを買う、ってなりますよね。

 

ロボットも同じで、まずは最適なロボットを入れて、それらをもっと便利に使うためにプラットフォームをくっつける、私はこういった思想でロボットを導入しており、アダプターで連携や付け替えがスムーズなRMFはベストマッチでした」

 

シンガポールで見た「運用が回る」光景

「RMFの原産国であるシンガポールは、国土が非常に狭く東京23区とほぼ同じ、
その限られた土地の中に、空港、病院、大学、商業施設、研究施設といった高密度・複合用途の建物が、都市のあらゆる場所に建っている誰もが知る先進国です。

一方で、

• 慢性的な人手不足
• 高い人件費
• 労働生産性向上という国家的な要請

こうした背景から、国全体でロボットを活用せざるを得ない状況に置かれていました。
この状況は現在日本が直面している課題とまったく同じだと感じました。

 

百聞は一見に如かず、です。
RMFの存在を知った直後、私は迷わずシンガポールへ飛び、実際にRMFを活用している現場をこの目で見に行った時に、現地で建物運営に携わっている方から、こんな話を聞きました。

 

「ロボット導入の初期は、ぶつかる、止まる、スタックする、といったトラブルが頻発し、多台数が同時に動く環境では、とても実用に耐えられなかった。しかし、RMFが導入されてからは、ほぼ手放しでロボットを運用できるようになり、今では立派な労働力として現場を支えてくれている」と。

 

話だけではなく、ロボットがRMFの制御によって稼働しているところも見学しましたが、
日本にいるだけでは想像もできないほどの台数（小さいAMRはなんと50台越え！！）かつ、多種多様なロボットが、当たり前のように建物内を行き交っている光景を目の当たりにし、正直、びっくりしたなんてレベルじゃなかったです。

 

そこで気づいたんです。
シンガポールにおけるRMFの開発から実導入に至るまでの試行錯誤の歴史は、私がこれまで日本でロボット導入に取り組んできた道のりと完全に重なっている、と。

 

そして、その課題がすでに“実社会の中で解かれている姿”を目の前で見たことで、
”この仕組みを日本にも持ち込むことができれば、ロボットと人が本当の意味で協調する未来は、必ず実現できる”
そうした明確なビジョンがはっきりと見え、またこれが私自身の使命なんだと思いました。

 

RMFは、シンガポールという高密度都市国家が、自国の課題から目を背けず、真正面から向き合った末に生まれた“答え”です。

 

力技で押し切るのではなく、構造として問題を解こうとした。その思想にとても感銘を受けました。

結局、国ごとのロボット運用における課題や求められている技術に大きな違いは無いと考えています。

RMFは特定の用途や国に限った仕組みではなく、世界中の建物で再現可能なロボット運用のスタンダードになっていく、という確信を持っています。」

代表的なユースケースに関するRMFの機能対応表

① 統合制御・メーカー混在

ユースケース	具体例	RMFによる解決	補足
メーカー混在で一括管理できない	清掃ロボットはA社、搬送ロボットはB社で、それぞれ別の管理画面を見ている	各メーカーのロボットをRMFにまとめて連携し、一元管理	アダプター連携方式によりメーカー差を吸収
ベンダーロックイン（運用途中のロボット入れ替えが困難）	システム連携上の制約によりロボットの機種入れ替え（メーカー変更）が難しい	メーカーに依存しない中立的な管理基盤として機能	将来的な入れ替え・追加が容易
ロボットの稼働状況が把握できない	今どのロボットが動いているのか、止まっているのか分からない	全ロボットの稼働・停止・エラー状態を一画面で可視化	全ロボットのステータス情報を統合管理

 

補足
これはロボット運用の中で最も多いユースケースであり、RMFは開発時点からメーカー混在を前提に設計されている。

 

② 動線競合・衝突回避（交通整理）

ユースケース	具体例	RMFによる解決	補足
ロボット同士の動線競合	廊下やエレベーター前でロボットが詰まる	通行ルートとタイミングを事前に調整	空間だけでなく、時間も含めてを予約する仕組み
デッドロック	お互いに譲れず、両方のロボットが停止	司令塔で優先順位を判断し、自動で解消	ロボット任せにしない設計
台数増加で不安定	数台までは問題ないが、数十台になると運用が破綻	台数増加を前提にしたスケーラブル設計	最初からマルチ台数での運用想定

 

補足
「台数を増やして初めて問題が顕在化する」ケースが多いが、RMFは初期段階から複数台運用を前提としているため、台数増加後も大きくロジックを変えずに段階的 / 持続的な運用が可能。

③ エレベーター・建物設備連携

ユースケース	具体例	RMFによる解決	補足
エレベーター呼び出し競合	複数ロボットが同時にEVを呼び混乱	RMFが呼び出し順を自動整理・制御	ロボットと同じように建物設備もRMFから制御可能
EV前でロボットが滞留	待ち順を管理できず、ELV前に複数のロボットが渋滞し通路を塞ぐ	ELV前が混雑しないように待機場所の指定が可能	先に到着した方を優先する、人と同じ考え方
建物ごとの設備仕様差	建物ごとに毎回個別開発 / 実装が必要	条件付きで対応	※ELV側のAPI整備が前提

 

補足
RMFはロボットと建物設備を含めた交通制御が可能。
RMFは紐づいたロボットを包括できるため、1ライセンスで複数台のELV連携が可能であり低コストな連携を実現。

 

④ タスク割当・再割当（運用面）

ユースケース	具体例	RMFによる解決	補足
作業負荷の偏り	特定のロボットだけが酷使される	各ロボットの作業量を見て自動的にタスクを分散	タスクを持たず遊んでいるロボットの発生も防げる
突発タスクへの対応	急な追加清掃や搬送依頼に対応できない	稼働中でもタスクを自動で追加・再配分	※外部システムとの連携が必要
ロボット停止時の代替	止まるたびに人が再指示	自動で代替機を選定しタスクを引継ぎ	※外部システムとの連携が必要

 

補足
「止まったら人が何とかする」運用から、
「止まっても全体が回り続ける」運用への移行が可能。
多くのシステムは「計画通りに進む」を前提としているが、
RMFは真逆の思想で「計画は必ず崩れる」を前提として設計されている。

 

⑤ 異常時・フェイルセーフ

ユースケース	具体例	RMFによる解決	補足
1台停止で全体が停止	工程全体が崩壊	エラー原因のロボットを切り分けし、他に影響が出ないよう制御	自動で全体工程を再計画
人の割り込み	人が通る / 道を塞ぐとロボットが固まる	自動で経路を引き直し再開	動的な再ルーティングが可能
システム動作不良時のエラー原因が不明	ログがバラバラでどこが原因で問題が起きたかわからない（分析に時間がかかる）	共通のイベントモデルでログを集約	全ロボットのログを一元で管理し、横断的な分析が可能

補足
RMFは「1台の安全」ではなく、「全体として止まらない設計」

 

BILLMSという答え ロボットと人の協調を実現するロボット群管理プラットフォーム

「これまでRMFの実用性について話してきましたが、実は日本でのロボット運用における障壁は、RMFだけですべて解決できるわけではないと考えています。

これは、実際に現場と向き合ってきたからこそ、強く感じている課題です。

日本はロボットを稼働させる為に必要な安全に対する要求水準が、他の国と比べて非常に高いんです。

例えば、シンガポールは人よりロボットの行動が優先される風潮があるので、新人研修は搬送ロボットに轢かれるところから始まる、なんて話を現地で聞きました（笑）

 

ですが、日本では単にロボット同士が衝突しない、というレベルでは、とても受け入れられません。

 

例えば、

• 人とロボットが同じ空間で稼働することを前提とした、接触・接近時の安全配慮
• 利用者の属性や混雑状況に応じて、そもそも稼働させて良いかの判断

こうした、日本ならではの安全基準や運用における要件が存在します。

 

RMFは、ロボットの交通整理やタスク管理という点では非常に優れています。 ただ、これらの安全要求を満たすという観点で見ると、RMF単体で十分とは言えない。

さらに、安全面だけでなく建物内業務のリアルな目線で見たとき、必要な要素がまだ足りない、という課題も残っています。

 

例えば、

 

• 人の業務とロボット業務を複合したスケジュール調整
  
• ロボットの稼働実績や停止理由まで含めた業務実績の可視化
  
• トラブル発生時の原因、対応履歴や改善履歴を残せる運用管理の仕組み
  
• 多物件、多台数を横断して把握するための統合的な管理視点
  

 

こうした点は、RMF単体ではカバーしきれません。

つまり、「本当にロボットを使い続けられる現場」を実現できる仕組みが存在していなかったのです。

 

日本の現場でロボットを、安全に、継続的に、そして価値ある形で運用するためには、
RMFに加えて、運用・安全・管理を一元的に可能にする“プラスアルファ”の機能がどうしても必要だと感じていました。

 

しかし、いくら探してもその条件を満たすものは見つからなかった。
ないものは、ない。
であれば、自分で作るしかない。

 

そうした考えから生まれたのが、
RMFによる群制御を核にしながら、日本の建物運用に本当に必要な機能を統合したプラットフォーム、”BILLMS”でした。」

 

ビルポが提供するロボット群管理プラットフォーム「BILLMS」

既存のロボット群管理プラットフォームの多くは、複数台のロボットをどう安全に動かすか、異なるロボットをどう一元管理するかを主眼に設計されている。

それらは、ロボット同士の衝突回避やひとつの建物における稼働状況の可視化といった観点では有効であり、製造業や物流倉庫など、ロボット専用空間においては一定の完成度を持つ。

 

しかし、ビルメンテナンスの現場はそれとは大きく異なる。
建物毎に特徴があり、人が常に存在し、時間帯、混雑状況、利用者が変化し続ける建物内では、ロボットだけを最適化しても業務全体は最適化されない。

 

既存の群管理プラットフォームがロボットのための管理に留まるのに対し、BILLMSは”建物内の業務全体を前提としたロボット群管理プラットフォーム”として設計されている点に本質的な違いがある。

 

BILLMSは、ロボット単体やロボット群を管理対象とするのではなく、ロボットが担う業務と人が担う業務を同一の土俵で扱い、建物の業務そのものを最適化することを目的としている。

 

BILLMSは基幹プラットフォームとしてRMFが採用されている。
しかし、RMFはあくまでロボット同士を安全かつ効率的に動かすための基盤であり、建物運用そのものを効率化させる思想で設計されたものではない。

 

人の業務、運用ルール、説明責任、現場管理といった要素は、RMFのスコープ外に置かれている。

BILLMSはRMFをロボット業務の管理における中核として活かしながらも、
そのロボット運行はこの時間帯に適切か
人の作業とどう役割分担されているのか
安全性を確保したうえで運行できているか
といった、日本の建物運用で必須となる機能を組み込んでいる。

 

「制御／運用／安全」の3レイヤー構造

BILLMSの機能と設計思想は、「制御」「運用」「安全」という3つのレイヤーで構成されている。

制御レイヤー

制御レイヤーは、RMFを中核としたロボット群制御の領域である。
マルチベンダロボットの統合管理、経路調整、交通管制による衝突回避、設備との連携制御など、ロボットを安定的かつ効率的に動かすための基盤がここに含まれる。

運用レイヤー

運用レイヤーは、BILLMSの最大の特徴と言える領域である。

RMFのダッシュボードでは、各ロボットの現在地やルート、停止やオフラインなどの簡素なステータス、タスクの履行状況といったロボットに関する基本情報が表示されるのみだが、BILLMSはそれらに加え、下記の機能をユーザー目線で使いやすいUIで提供する。

 

• 人の業務+ロボット業務を統合するスケジューラー機能
  人とロボットの業務を統合スケジューリングし、それぞれがどの作業を担当しているかが可視化されることで無駄のない作業工程を実現。
  また、ロボットが停止しタスク履行が不能となった際は他ロボットへ自動で再スケジューリングする機能も搭載。

 

• 多物件、多台数を横断して把握できる多棟管理機能
  同一プラットフォーム上で複数物件、物件毎のロボット管理が可能。
  物件名やロボットネームでの検索、ソート機能で欲しい情報をすぐに閲覧でき管理上の煩雑化を解消。

 

• エラーログ収集機能
  エラー発生時の通知内容を自動でログ化。対応履歴や改善履歴もあわせて入力することで原因究明や再発防止の検討を可能に。
  また、各ロボットのエラー通知を代表的なSNSやメールなどで通知しトラブル時の迅速な対応を実現する。

 

• 自動レポーティング機能
  各ロボットの稼働ログを自動で収集し、タスクの完了率などを自動集計しレポート出力。エラーログ収集機能とあわせて効率的な稼働実績の振り返りや透明性を持った報告などを可能にする。レポーティング範囲は週毎、月毎などの指定も可。

安全レイヤー

安全レイヤーは、日本におけるロボット運用において不可欠な要素である。
人とロボットが同一空間で稼働することを前提とした運用ルール、状況に応じた運行判断機能が含まれる。

 

• 人との接触回避機能
  AIカメラや3DLiderセンサーを連携させることで、”角でロボットと人が鉢合わせた時の衝突”の様なRMFやロボット本体のセンサーでは検知しきれない運用上の死角までフォローし、BILLMSが該当のロボットを一時停止。病院などの特に安全性が問われるシチュエーションにおいてもロボットの安全運行を実現する。
  

 

• 自動稼働判断機能
  AIカメラや3DLiDERセンサーを連携させることで、BILLMSが混雑時は稼働しない、身体の不自由な人がいる場合は一時停止する、といった制御を自動で実施。
  また、ダッシュボード上で該当のエリアのロボットのスケジュールを一斉にオン、オフにする、といったマニュアル操作も可能であり、イベント日などの事前に混雑が予想される日は停止させる、といった運用を実現。

BILLMSは、この3レイヤーをひとつのプラットフォームとして統合することで、ロボットの効率的かつ安全な運行と、建物業務全体で見た削減効果の両立を実現する。

 

既存ロボット群管理プラットフォームとBILLMSの機能比較表

比較項目	既存ロボット群管理プラットフォーム	BILLMS
設計思想	ロボットを安全かつ効率的に動かすことが目的	建物内の業務全体（人＋ロボット）を最適化することが目的
主な適用領域	製造業・物流倉庫などロボット専用空間	病院、商業施設など人が常に存在する建物
管理対象	ロボット単体・ロボット群	ロボット業務と人の業務を同一プラットフォームで管理
基盤技術	独自制御	RMFを中核に据えつつ独自拡張
マルチベンダー対応	対応（数メーカー）	対応（多メーカー）
ロボットの衝突回避・交通整理	◯	◯（RMFによる高精度制御）
設備連携（EV・自動ドアなど）	◯（ロボット毎に連携）	◯（RMFとの連携で低コスト）
ダッシュボード機能	ロボット位置・状態・タスク状況の可視化	ロボット＋人の業務状況を統合可視化
人の業務との連携	×（ロボット管理に限定）	◯（人＋ロボット統合スケジューリング）
統合スケジューラー	×	◯（人＋ロボット）
タスク再割当	ロボット単位で限定的	ロボット停止時に他ロボットへ自動再割当
多棟・多物件管理	× または物件単位で分断	◯（複数物件・多台数を横断管理）
検索・ソート性	限定的	物件名・ロボット名などで即時検索可能
エラーログ管理	簡易的（ログ閲覧が中心）	通知・対応履歴・改善履歴まで一元管理
外部通知連携	限定的	SNS・メールなどと連携し即時通知
稼働レポーティング	手動集計 or 簡易	自動集計・週次／月次レポート出力
KPI可視化	ロボット稼働率中心	業務完了率・改善履歴を含めた業務視点の指標
人とロボットの共存安全設計	ロボット側センサー依存	AIカメラ・3D LiDAR連携による死角対策
混雑時の稼働制御	×	◯（混雑・利用者属性に応じた自動判断）
手動での一斉稼働制御	×	◯（エリア単位でON／OFF制御）
日本の運用ルール対応	想定外	日本の建物運用・安全要求を前提に設計
説明責任・履歴管理	×	◯（ログ・レポートで説明可能）
拡張性	ロボット追加中心	業務・ルール・安全要件まで拡張可能

 

ロボットを入れるのではなく、根づかせる

「ロボットやシステムの話をしていると、どうしても技術的な言葉が先に立ってしまいます。でも、私がここまで話したかったのは、ロボットそのものの話ではありません。
 

現場で働く人が、少しでも無理をせずに働けること。
ロボットに仕事を奪われるという不安に怯えずに、ロボットと協調することで人らしい仕事を胸を張ってできる環境をつくること。

 

そして、人不足と言われる中でも、建物を使うすべての人が当たり前のように安心、安全、快適を享受できる社会を継続させること。

そのために、何が足りないのか？
何を変えなければいけないのか？

 

その問いに向き合い続けた結果が、RMFであり、BILLMSであり、私だけではない株式会社ビルポとしての在り方です。

 

ロボットは使えば便利な魔法の道具ではありません。
正しく管理し、正しく制御し、人の業務ときちんと噛み合わせて初めて、最大の価値を生みます。

 

だからこそ私はロボットを入れる人ではなく、”ロボットが根づく仕組みをつくる人”であり続けたい、その積み重ねの先にしか持続可能な建物運用はないと思っています。

ビルポはまだまだ道半ばです。

ですが、これからも日々建物運用の現場と真正面から向き合い、ロボットと人が本当の意味で協調する未来を、必ずこの国で実現する！！
その覚悟だけは、誰にも負けないつもりです。」