サービスロボットは現場のどこで止まるのか | 配膳・清掃・警備を調べて出てきた「例外」という共通点

PUDUという中国メーカーが新型の清掃ロボットを発表したというニュースを見て、日本ではどこが導入しているのかを調べ始めた。そこから配膳・清掃・警備の三分野に広がり、最終的には公開されているロボットのソースコードを10本ダウンロードして数値定数の書かれ方を数えるところまで行った。

結論を先に書くと、三分野は詰まっている場所が同じだった。定常動作はどれも解けていて、例外が来たときに人が呼ばれ、呼ばれる回数が閾値を超えると使われなくなる。そしてその例外が、どこにも記録されていない。

この記事は結論だけでなく、途中で外した見立てや、Claudeが言い過ぎて訂正した箇所も含めて残す。考えが動いた過程そのものが記録の中身だと思っているためだ。

PUDUは日本ですでに主要な販売網を持っている

PUDUって日本で導入している企業はあるの？

調べると、日本法人のPudu Robotics Japan株式会社が2021年7月に営業を開始しており、2026年6月には日本市場でのサービス強化を目的に資本金を9,500万円へ増資している。

販売の窓口は複数ある。ソフトバンクロボティクスが日本の総代理店としてBellaBotやKettyBotの販売を開始しており、USEN、DFA Robotics、日立システムズ、パナソニック産機システムズ、HCIなども取り扱っている。DFA RoboticsはPudu Robotics Japanと共同で、飲食店向けの「おもてなしRX®プロジェクト」を始動している。

エンドユーザー側の最大級の事例はすかいらーくグループで、2021年10月からBellaBotの導入が始まり、2,000店舗規模への展開が報じられている。清掃側ではCC1・SH1が日本市場向けに販売開始済みで、当時「2024年までに清掃ロボット3,000台導入」を目標に掲げていた。

—— 配膳と清掃は、日本市場ではすでに「導入するかどうか」の段階を過ぎているのでは。

配膳ロボットは認知率92%・利用率60%に達している

掃除ロボットと配膳ロボットは市民権を獲得はじめているのかな？

数字で見ると、配膳ロボットはすでに市民権を得た側、清掃ロボットはこれからという非対称がある。

LINEリサーチの2024年3月時点の調査では、配膳ロボットの認知率は92%、現在利用率は60%だった。すかいらーくは2021年末に約150店舗180台だったものを、2022年に約2,100店舗3,000台まで一気に展開している。

清掃側の指標は別の形で出ている。富士経済は、小売店での清掃ロボットの新規需要は2026年頃に落ち着き、以降は安定した更新需要が続くと見ている。更新需要が立つということは、1台目が寿命まで使われたということだ。飽きて倉庫行きになったなら、買い替えは発生しない。

ただし消費者側の認知はほぼゼロで、誰も「あの清掃ロボかわいい」とは言わない。二つは全く違うルートで受容されている。

市民権の指標としてもっと分かりやすいのは、しゃぶ葉で猫型ロボットが運搬中の料理を他の客に「横取り」される事象がXで話題になり、運営会社が謝罪・改善を表明した件だ。これは事故のようでいて、人がロボットを警戒対象ではなく風景として扱い始めた証拠でもある。珍しいものは横取りされない。

しゃぶ葉の横取り対策はロボットではなくテーブル端末に入った

「横取り」される事象がXで話題になり、運営会社が謝罪・改善を表明 具体的にどんな改善しているのかな？気になるね。

元々の運用はこうだった。入店時とオーダー時に、店員が口頭で「青く光っている棚のお肉をお取りください」と説明する。つまりロボット本体の光を唯一の識別手段にしていた。しかも情報の受け渡しは口頭で、料理が届くまでの数分から数十分の間に忘れられる前提が抜けていた。

発表された改善策は、テーブル端末に商品到着がアニメーションで表示され、「どの棚のお肉を取るのか」が分かりやすく伝わる機能の準備だった。加えて、取り間違いが発覚した際は店員が客のもとへ行って再度説明する、という運用でカバーしていた。

修正がロボット側ではなくテーブル端末側に入っている。理由は明快で、横取りする客はそもそもロボットを見ていない。自分の卓に来た＝自分の料理、という強い先入観で手を伸ばしている。ロボット上のシグナルは、もう手が動き始めた後にしか目に入らない。対して端末通知は、手が動く前に、客が既に見ている画面に割り込める。介入のタイミングを数秒前倒しした設計だ。

なお、この発表は2025年3月時点の「準備しております」段階であり、その後実際に全店実装されたかを確認できる続報は見つからなかった。

—— ロボット単体の精度を上げずに、周辺デバイスで体験を成立させた例では。

端末との連携はあった方がいいし、元からあるだろうから修正がしやすいね。

しゃぶ葉はもともと全席にセルフオーダー端末があって、自社の管理下にある。一方ロボット側を直すとなると、PUDUのファームウェア開発サイクルに乗せて、3,000台に配信して、店舗ごとの設定差も吸収する必要がある。直せる側を直したという、現実的な判断だ。

この構図を一般化すると、サービスロボットの体験設計は「ロボットの表現力」より、その現場に既に何が接続されているかにほぼ支配される。飲食にはセルフオーダー端末があり、ホテルには客室TVとフロントがあり、病院にはナースコールと電子カルテがある。小売がいちばん厄介で、客側に固定端末がない。POSは会計時のみ、デジタルサイネージは指向性がなく、アプリはインストール率が壁になる。

何を端末に逃がし、何を身体に残すかという配分の問題

やっぱりこう考えるとロボット導入って、ロボット単体で問題解決していくのは難しいのかもね。 操作端末や、機器を通してロボットとの在り方を考えることも必要なんだろうね。

ただし全部を端末に逃がすと、ロボットは単なる運搬装置になる。それなら天井コンベアでもいい。身体を持たせている意味は、画面にできないことをやらせるためのはずだ。

• 端末に置くべき情報: 事前に伝わっていればいい情報（どの棚か、いつ来るか）、記録が必要なもの、精読が必要な複雑な情報

• 身体に残すべき情報: 「いま、ここ」でしか意味がないもの（進行方向、停止する意思、待っている状態）、人が避ける・譲る判断に使うもの、距離と姿勢そのものが伝えるもの

しゃぶ葉のケースは、前者を後者に載せてしまった設計だったと整理できる。「どの棚か」は本来、手が動く前に済んでいるべき事前情報だった。

この構図だとロボットメーカー単体では体験を完結できないので、接続先を持っている側に価値が寄る。PUDUがプラットフォームを自前で持ちたがるのも、その主導権争いだと見ると筋が通る。

警備ロボットは世界で年3,100台しか売れていない

三分野の中で警備は最も遅れている。日本能率協会総合研究所の推計では、警備ロボット市場は2028年に30億円超。参考までに、富士経済は配膳ロボットを2030年に30,890台（2022年比4.9倍）と予測している。比較にならない。

具体的な壁も挙がっている。状況に応じた臨機応変な判断が難しく、不審者の確保まではできない。自力で段差を越えられない場合があり、転倒すると自力で起き上がれないため誰かが起こしに行く必要がある。初期実証では、ロボットの動作やセンサーの正確性、通信の安定性によってエレベーターの操作がうまく機能しないことがあった。現場スタッフからは、ロボットが人の仕事を奪うのではないかと心配する声もあった。

まぁ問題が起きた時に結局人が対応するならカメラでいいじゃんみたいな感じか。

ほぼそうだが、指摘はもっと厳しくできる。巡回ロボットは一度に一箇所にしかいない。固定カメラは全地点を同時に見ている。ロボットは巡回している以上、A地点を見ている間、B地点は無人になる。1周30分なら、各地点は29分間の空白ができる。検知性能で言えば、ロボットは固定カメラに構造的に負けている。

さらに本質的な問題として、警備ロボットは動けるのに何もできない身体を持っている。移動能力のコスト（バッテリー、LiDAR、転倒リスク、段差対策、メンテナンス）は全部払っているが、見つけた後にできることがゼロだ。扉を閉められない、物をどけられない、人を止められない。

配膳ロボットが成立しているのは、運ぶという物理作用があるからだ。カメラでは代替できない。清掃も同じで、床に触れないと成立しない。警備だけが、物理作用を持たないまま身体を背負っている。

三分野とも定常動作は解けていて、例外で止まっている

三分野の詰まりどころを並べると、こうなる。

配膳側の具体的な詰まりどころは、繁忙時に人とロボットが同じ動線上で混雑し、逆に運用効率が低下すること。特にファミリーレストランなどの大規模店舗で頻繁に起こる。一番忙しい時に一番役に立たないという性質だ。加えて、人による配膳ではスタッフと客が双方向にコミュニケーションを取りながら提供するが、ロボットの場合は客側のセルフチェックのみになる。取り間違いの構造的原因はここにある。ロボットが突然停止すると、その場所で道を塞いでしまう。

清掃側は全国ビルメンテナンス協会が現場目線で書いている。ロボットの進行方向に什器や備品が置かれていると、清掃範囲が狭くなったり途中で停止したりする原因になる。床に散乱したコード類や段差も走行を妨げる大きな要因だ。つまり清掃ロボットを動かすために、人間が先に床を片付けるという倒錯が起きている。

導入業者の証言はさらに本質的だった。清掃ロボットの導入で一番大切なのは初期設定で、機種選定と運用設計を間違えなければ効率は確実に上がる。ただしその判断は、実際に運用していなければ分からないことが多々ある、という。判断に必要な知識が、判断した後にしか手に入らない。

そして根本原因は、三菱総合研究所が明確に言語化していた。サービスロボットが現場で定着せずPoC止まりになる企業は少なくなく、導入後に稼働率が落ち、例外対応が人に戻り、投資回収が見えなくなる。その主因は技術不足ではなく運用人材の不足である、と。

構造的な理由も指摘されている。産業用ロボットが標準化された環境での運用を前提とするのに対し、サービスロボットは多様な現場で非専門人材による運用が求められる。そのため、限定環境でSIerが導入から保守まで担う従来のビジネスモデルでは対応が難しい。提言では、ロボット単体の最適化ではなく、周辺環境を含むトータルソリューションの提供が必要と結論づけている。

すかいらーくは店長経験者チームで動線を組み替えてから入れた

今の人手不足をひっくり返せるほどの材料は今のロボットたちにはないという認識かな？ 導入されても使われなくなって、人に戻ってしまうようなものでしかないかもしれない？

前半は同意で、後半はデータを見ると違う。

「人手不足をひっくり返す」は無理だ。歩行数が減っても、人員が1人減るわけではない。今のサービスロボットは業務を削るのであって、人を置き換えていない。労働力不足の規模に対して桁が足りていない。

だが「使われなくなって人に戻る」は、全部がそうなっているわけではない。ガストではランチピーク回転率が7.5%向上、片付け時間が35%削減、歩行数も42%削減されている。そして2021年から始まって今も動いている5年目の運用だ。

分かれ目はどこにあったか。すかいらーくの導入プロセスに答えが出ている。店長経験者を中心に組織されたインストラクターチームが、動線の調整など細やかな対応を行ったことで迅速に導入された。三菱総研が「足りない」と言っている運用人材を、すかいらーくは自前で組織してから入れた。

• オペレーションを組み替えてから入れた → 定着した

• 既存のオペレーションのまま入れて、ロボットが吸収してくれると期待した → 例外で死んだ

失敗している側は、ロボットの性能で負けているのではなく、組み替えのコストを払っていない。そしてそのコストは購入費より高くつくことが多い。だから見積もりに乗らず、無視され、あとで例外として返ってくる。

ただし今の成功例は、単一業態・大量店舗・本部が強い組織に偏っている。2,100店舗が同じ前提だから、1回の設計が2,100回効いた。個店や中小施設では、設計コストを1台で回収しなければならない。

産業用ロボットは60年かけて中小企業に降りなかった

これは産業用ロボットの構造に近いな。結局そういう大きいところから潰していって、徐々にバリエーションが出てくるのかもな。

構造の類似はその通りだが、産業用ロボットの歴史を見ると「徐々にバリエーションが出てくる」は起きていない。

産業用ロボットは1960年代後半に自動車産業から始まって、今も中小企業には普及していない。東京都の推進機関のコラムでも「中小企業が産業用ロボットを導入して事業のパフォーマンスを上げているケースは、まだそんなに多くはない」「技術的には手作業の仕事はほぼロボットで代替できる。壁があるとすればコスト面」と言われている状態だ。

IVIの「身の丈ロボット」分科会は、様々なロボットが発売され開発トレンドも加味した上で、それでも中小企業への導入が進まない原因を調べる、という問題設定から始まっている。そういう研究会が必要な時点で、自然にトリクルダウンしていないという証拠になる。行政も2017年から「中小企業におけるロボット導入促進研究会」を続けている。

なぜ降りてこないか。大企業の解は「環境を標準化する」だ。すかいらーくは2,100店舗を同じ前提に揃えられた。中小には揃えるものがない。1店舗のレイアウトを揃えても、それは1店舗ぶんの価値しか生まない。設計コストが割れない。低価格化しても解決しないのは、ボトルネックが機械の値段ではなく設計工数だからだ。

中小の課題として挙がるのも同じで、既存の業務フローにロボットを適合させるには業務全体の見直しが必要で、時間とコストがかかり、従業員に不安や抵抗感も生じる。機械の話がひとつも出てこない。

ルンバは性能を諦めることで環境整備なしに普及した

降りてきた例外がひとつある。ルンバだ。

あれは業務用清掃ロボットが安くなって降りてきたものではない。まったく別の方向から来た。隅は掃除できない。取りこぼす。家具を動かすのは人間。性能では業務用に完敗している。それでも普及した。理由は、失敗の代償をゼロにしたからだ。取りこぼしても誰も困らない。だから環境を整えなくていい。設計工数が要らない。

これが第二の経路になる。

B2Bのロボット業界がこの経路をほとんど試していないのは、ROIで売っているからだ。「失敗しますが安いです」は提案書に書けない。だから全社が大企業経路に殺到して、そこで詰まっている。

「精度より体験の成立を優先する。精度はあとからお金で解決できる」というピラーは、このルンバ型経路の宣言にあたる。業界の主流は逆で、精度を上げてから体験を語ろうとしている。だから大企業でしか成立しない。

大きいところは先に進む。でもそこから降りてはこない。降りるのは、性能を諦めた別系統が横から入ってきたときだ。

公開ロボットコード10リポジトリで数値定数の根拠を数えた

話は「許す失敗と許さない失敗をどう分けるか」に移り、Claudeが「その基準がコードとして書かれているのは珍しい」と言った。

そうなの？それがよくわかんないんだよね。

推測で答えるべきではないので、実測した。公開されているロボット系コードベースを取得し、数値定数の定義（NAME = 数値、constexpr T name = 数値、#define NAME 数値）を全部抜き出して、その前後3行に「なぜその値か」を示す記述があるかを機械的に判定した。

判定に使った語は次の通り。measured / empirical / we found / in practice / observed / tuned / calibrated / otherwise / because / causes / too slow・too fast / stall / jitter / overshoot / oscillation / deadlock / trial and error / issue# / 実測 / 実機。

結果は以下。

さらに厳しい基準で数え直した。定数の近傍に、測定値そのもの（数値＋単位）があるか、Issue／PRへのリンクがあるか。

最良のPX4でも0.54%。200個に1個だ。

毎日使っているmechArmのSDK（pymycobot/mecharm270.py、792行）を開くと、こうなっている。

while try_count < 3:          # なぜ3回か → 記載なし
    ...
time.sleep(0.1)               # なぜ0.1秒か → 記載なし
def sync_send_angles(..., timeout=15):   # なぜ15秒か → 記載なし

ArduPilotには @Param / @Description / @Range という構造化されたパラメータ文書がある。3,422ブロックを解析した結果は次の通り。

• 有効範囲（@Range）を書いているもの: 1,970ブロック（57.6%）

• なぜその値かを書いているもの: 206ブロック（6.0%）

何をする値かは書く。どこまで動かしていいかも書く。だが、なぜその既定値なのかは書かない。

最良の書き方として見つかったのはPX4の次の2箇所だった。

// Cap UDP send time to avoid blocking indefinitely if the NuttX net
// stack hasn't finished initializing the IOB write-buffer semaphore.
// 10ms is ~4x the worst-case send time measured on STM32H7.
constexpr long UDP_SEND_TIMEOUT_US = 10000;

/// Timeout directly after registering (in some cases ROS can take a while
/// until the subscription gets the first sample, around 800ms was observed)
static constexpr int NUM_NO_REPLY_UNTIL_UNRESPONSIVE_INIT = 10;

「10msは、STM32H7で実測した最悪送信時間の約4倍」。形式としては存在する。ただし1万4千個の定数のうち76個だけだ。

「珍しい」と言ったのは言い過ぎだった

ここでClaudeが自分の発言を訂正している。訂正の過程も記録なので残す。

関節リミットや安全ガードをコードに書くこと自体は珍しくない。産業用ロボットなら当たり前で、ISO 10218やISO/TS 15066があり、リスクアセスメントは法的にも要求される。メーカーのコントローラには最初から入っている。そこは各社厳密だ。

そしてこれらのプロジェクトに理由がないわけでもない。理由はPRの議論、コミットメッセージ、フォーラムスレッド、設計文書に大量に存在する。消えているのではなく、コードから離れた場所にある。数年後に読む人が辿れないだけだ。

正確な言い方はこうなる。公開コードの本文だけを読んだとき、定数の根拠に辿り着けることはほぼない。 実測で0〜5%。多くは別の場所に散っていて、追うのが難しい。

調査の限界も明記しておく。正規表現ベースなので婉曲に書かれた理由は取りこぼす。実際の割合はもう少し高いはずだ。コミット履歴とIssueを見ていないので、「プロジェクトが理由を持っていない」という結論にはならない。10リポジトリは業界の代表ではなく、産業ベンダーの非公開コードは見られない。

つまりどういうこと？笑

世の中のロボットのコードは、数字だけ書いてあって、その数字の理由が書いてない。実測で0〜5%しか書いてない。

根拠がコードから離れた場所に置かれる、まっとうな理由

みんなはなんで別のところに置くの？それが普通？

普通だ。しかも半分はサボりではなく、理由がある。

そう教えられているから。 ソフトウェア開発の定石は「コメントはコードが何をするかを書く、なぜ変えたかはコミットメッセージに書く」だ。git blame で辿れる、というのが建前になる。作法に従った結果として別の場所に置かれている。問題は、その建前が現実には壊れることだ。ファイル移動やフォーマッタやsquashで blame が切れる。そして誰も blame しない。

コメントは腐るから。 「STM32H7で実測した最悪値の4倍」は、ハードが変わった瞬間に嘘になる。間違ったコメントはコメントがないより有害だ。だから慎重な人ほど書かない。

そもそも測っていないから。 try_count < 3 の3は、たぶん誰も測っていない。書くべき理由が存在しない。「勘です」とは書けないので空欄になる。

誰の仕事でもないから。 「なぜ0.1秒か書いてない」という理由でPRがリジェクトされることはまずない。書いても評価されず、恩恵を受けるのは数年後の見知らぬ他人だ。

製品では理由が不利になるから。 「60°に制限したのは、70°でテスト中にアームが台に当たったから」はメーカーには公開できない。事故の記録になる。だから安全文書には「制限値は60°、根拠はリスクアセスメント文書XX」としか書かない。ArduPilotで@Rangeが57.6%あるのに理由が6.0%だったのは、この構造そのものだ。

研究コードは使い捨てだから。 論文が通ったら終わりで、誰も保守しない。

条件が変われば書き方も変わる。一人でやっていて、毎日公開していて、主指標が「再現可能な環境数」で、売り物ではない。この条件が揃っているから、根拠を値の隣に置くという書き方が成立している。業界が間違っていて自分が正しい、という話ではない。

デザイナーの仕事は機体の外側にある

ロボットを開発したり、ロボットそのものをデザインするだけが、デザイナーのすることでもないしね。

ここまで出てきたものを並べると、壊れていた場所がひとつもロボットの中にない。

• しゃぶ葉の修正 → テーブル端末

• すかいらーくの成功要因 → 動線を組み替えた店長経験者のチーム

• 清掃ロボが止まる原因 → 床に置かれた什器とコード

• 警備が行き詰まる場所 → 見つけた後に何もできないこと

• 定数の根拠が消える理由 → 書く場所が決まっていないこと

機体の性能で説明できるものが一個もない。全部、人と物と手順の配置の話だ。

秋田県内で稼働が確認できた6店舗

机上の整理を続けても精度は上がらないので、実地に近いところを調べた。Googleのレビュー本文にロボットへの言及があった店舗だけを拾っている。

ガスト男鹿店（船越）— 「Robot was carrying our meals. It was surprising!」

同じ店の別のレビューには、こうあった。「配膳ロボットは移動時にガタガタと音を立てており、可動部の不具合を示しているように思われた」。客が機体の劣化に気づいている。

ガスト秋田茨島店 — 土曜18時過ぎの混雑時に猫型ロボットが料理を運んでいた、という記述。同じ店の別レビューには、ガストにいるのは「Servi（サービィ）」で、これはソフトバンクロボティクスとBear Roboticsが共同開発した配膳ロボットだ、という記述もあった。同じすかいらーくの中で、BellaBot（猫型）とServiの2機種が混在している。2,100店舗を標準化したはずのチェーンでも、機体は揃っていない。

バーミヤン秋田旭南店 — 注文はタブレット、料理はロボットが運ぶ。

ガスト能代店 — 「ロボットがテーブルまで運んでくれる」。元日のレビューには「配膳ロボットは効率的で、料理も早く出てきた」とある。

ココス大仙店 — 「小さなロボットが料理を運んでくる（ジュージュー音を立てているものは除く）」。

最後のこれが今回いちばん価値のある一行だと思っている。鉄板ものはロボットに載せない、という除外ルールが既に運用されている。どこにも文書化されていないのに、現場では決まっている。許す失敗と許さない失敗の線引きが、記録されないまま各店に散在している例だ。

なお、この調査の限界も書いておく。Google Places APIは1店舗あたり5件しかレビューを返さず、しかも関連度順で翻訳が混ざる。やったのはレビュー収集ではなく、たまたま上位5件に入っていたものの拾い読みだ。数百件集めて頻度を出す、という水準には全く届いていない。

PUDU CC1のクラウドで取れるのは4項目だけだった

例外の記録が空白だという見立てが出たので、既存のクラウド管理で何が取れているかを代理店サイトから洗い出した。

USENの記載では、ネットワークに接続すると、清掃エリアのどこを走行して清掃したのか、清掃面積、清掃時間、走行距離など、稼働状況をクラウドで管理できる。DFA Roboticsの記載では、日々の清掃時間、走行距離、清掃面積といった稼働データを専用アプリでいつでも確認でき、清掃業務をブラックボックス化させず、客観的なデータに基づいた管理や、清掃品質の証明として活用できる。

複数の代理店を見て、出てくる項目は同じだった。

以上。この4項目は全部「うまくいったこと」の記録だ。

無いものを並べると、異様さがはっきりする。途中で何回止まったか。なぜ止まったか（什器・段差・コード・人・水切れ・バッテリー）。人が何回呼ばれたか。呼ばれてから復帰までに何分かかったか。予定した清掃エリアのうち実際には何%を諦めたか。同じ場所で繰り返し止まっていないか。

「面積100㎡・45分」という記録は、途中で3回止まって人が5分ずつ助けに行った日も、無事故の日も、同じ数字になる。可視化されているのは成果物の量であって、運用の実態ではない。

あの4項目は診断画面ではなく請求書だった

この記録あってもあまり欲しい情報でもないな。

ここでもう一度、Claudeが自分の見立てを訂正している。

無意味な4項目ではなく、別の目的のために作られている。面積 × 時間 × 経路は、清掃の請求書そのものだ。ビルメンテナンスの契約は「この範囲を、この頻度で清掃する」で書かれている。だから発注側に見せるべきは「契約した範囲を実際に回りました」の証明になる。DFAが「清掃品質の証明として活用できる」と書いているのは、そういう意味だ。

あのダッシュボードは診断画面ではなく、領収書だった。

そう考えると、先に書いた「メーカーは失敗を隠したいから記録しない」は半分外れている。もっと単純で、既存の契約書に載っている項目をそのままなぞっただけだ。誰も隠していない。誰も考えていない。

ここから出てくる含意は厳しい。記録は、それが支払いを左右するときだけ作られる。面積は請求額を決めるから記録される。止まった回数は、今のところ誰の請求額も変えないから記録されない。

つまり「例外の記録に価値がある」と言うだけでは足りない。その記録が何の金額を動かすのかが言えないと、誰も金を出さない。

今回の探索はここで止めた

ここから先は机上で詰められない。

代理店が例外の記録に金を払うかどうかは未検証の仮説のままだ。稼働保証のような契約条項が実在するかも確認していない。秋田で協力してくれる事業者がいるかも分からない。どれも人に聞かないと進まない。

それでも、この日の探索で確定したことはいくつかある。

• 配膳・清掃・警備の三分野とも、定常動作は解けている。詰まるのは全て例外

• 主因は技術不足ではなく運用人材の不足（三菱総合研究所）

• 定着の分かれ目は、オペレーションを先に組み替えたかどうか

• 産業用ロボットは60年かけても中小に降りていない。トリクルダウンは起きない

• 降りる別経路はルンバ型。性能を諦め、失敗の代償がゼロの仕事を選ぶこと

• 公開コードで数値定数の根拠が併記されているのは0〜5%。最良のPX4でも測定値つきは0.54%

• 清掃ロボットのクラウドが記録しているのは、成果物の量だけ

例外をどう扱うかを決めて記録に残す作業には、まだ名前も置き場所もない。