ハコブくん 病院オペレーションのデジタルツイン Log#2 | ただのダッシュボードではなく、意思決定の補正ループを設計する

商用サービスロボットのソフト側がどこまで開いているかを調べたところから、この回は始まった。PUDU のような搬送ロボットは、クラウド API・プライベートクラウド API・OS SDK の三層で外部連携を受け付けていて、タスクや稼働データを外から引ける。「メーカーが作ったものしか使えない箱」ではない。ここまでは事実確認だった。

そこから問いが一段ずれた。ロボットから取れるデータを使って、オリジナルのダッシュボードを作る、業務システムと連携させる――そういう仕事を個人で請け負うのは、事業として成り立つのか。成り立つとして、可視化を売り物にするのは筋がいいのか。

結論から言うと、可視化そのものを売る構えは筋が悪い。そう判断するために市場の形を四つの角度から確かめ、その代わりに何を設計の中心に置いたかを、この回では残す。

配膳ロボットは一万台規模、施設内デリバリーが最速で伸びる

まず台数から。商用サービスロボットは導入ベースで着実に増えている。国内の配膳ロボットの累計稼働台数は、数年のうちに一万台に迫る規模まで来た。象徴的なのはすかいらーくで、全国約2,100店舗に約3,000台の PUDU 製ネコ型ロボット（BellaBot）を導入し終えている。街の飲食チェーンの床を、すでに数千台の搬送ロボットが走っている。

より伸び率が急なのは、配膳ではなく施設内デリバリーだ。病院・宿泊・小売といった、建物の中を回って物を運ぶ用途。母数はまだ小さく、国内では年に数百台の規模にとどまるが、数年で桁が変わる予測が出ている。富士経済は施設内デリバリーロボットが2030年に向けて配膳をしのぐ倍率で伸びると見ている。ハコブくんが照準を合わせている病院搬送は、まさにこの最速で伸びるセグメントに当たる。参照実機に置いている PUDU FlashBot は、この用途の代表機だ。

台数が増えれば、その一台一台が稼働ログを吐く。搬送回数、走行距離、停止、充電サイクル。運用データを扱う余地そのものは、放っておいても広がっていく。ここまでは追い風だ。

PUDU・Keenon・Bear・Gausium で開き方に差がある

次にデータの開放度。ロボットが取れるデータを外に出せるのか、それともメーカーの箱に閉じているのか。主要四社を当たると、いずれも API か SDK を開放していた。ただし開き方に明確な段差がある。

PUDU が最も体系的だ。2023年に一般提供を始めた Open Platform は、クラウド API・プライベートクラウド API・OS SDK の三層構成で、医療の HIS・LIS、宿泊の PMS、飲食の POS・ERP、物流の WMS・MES といった業務システムとの連携を、公式のユースケースとして掲げている。Keenon は KONE エレベーターとの API 連携などを持つが、開放は主に法人パートナーシップ経由で、個人が公開サインアップで入れる形は確認できなかった。Bear Robotics は gRPC と REST の SDK を公開し、公開サンプルもあるが、自ら「開発初期段階」と明記していて、認証には Bear 発行の資格情報が要る。Gausium は四社の中で最も個人開発者に開かれていて、開発者ポータルでキーを取得できる。

開き方はバラバラだが、方向は共通している。「メーカーが作ったものしか使えない箱」ではない。外から手を入れる余地は、確かにある。

二次開発は黎明期で、個人専業の市場は存在しない

問題は三つ目、その余地を今つかんでいるのが誰か、だった。

二次開発の担い手は、現状ではロボットを配るディストリビューターと、数社のシステム会社に限られている。個人がこの四社の API を専業で叩いて受託している確立した市場は、探しても見当たらなかった。汎用の ROS・ダッシュボード系フリーランスはいるが、「PUDU 特化」「Keenon 特化」を掲げる個人の専業プレイヤーは見つからない。PUDU 自身が、開発ツールとドキュメントの不足が二次開発レベルのイノベーションを難しくしてきた、と認めている。市場はまだ黎明期だ。

数少ない具体例を挙げると、実在するのは企業インテグレーターと、ごく一部の個人開発者だ。オーストリアの ToolSense は PUDU と API 連携し、清掃タスクと稼働監視を一元化するダッシュボードを、資産管理 SaaS の付加価値として提供している。米 RobotLAB は複数メーカーを扱うディストリビューター兼インテグレーターで、フリート管理と週次レポートまでをサービスに含める。Transitive Robotics はフリート管理ダッシュボードのテンプレートをオープンソースで公開し、ロボット単位で機能を課金する形を示している。個人では、Gausium の Open API を AI アシスタントから叩けるツールを作って公開した開発者がいる――四社のうち、個人単独の二次開発が確認できたのは Gausium だけだった。

「空白がある」と読むこともできるし、「需要がまだ育っていない」と読むこともできる。両方本当だ。ここは正直に、先行リスクとして受け止めておく。

成長の主戦場はソフト層、しかし可視化はその中で最初にコモディティ化する

四つ目、成長の主戦場がどこに移るか。ここが判断を決めた。

複数の調査が、ハードウェアの伸びより、その上に乗るソフトウェア・サービス層の伸びの方が速いと一致して予測している。Mordor Intelligence はホスピタリティ・ロボット市場で、ハードが支出の約6割を占める一方、ソフト層が最速で伸びると分析している。機体そのものではなく、機体が生むデータをどう扱うかの層に、成長が移っていく。可視化を事業にしたい者には、一見これも追い風に見える。

だが同じ調査は、その層で何が起きるかも書いている。システムインテグレーターが、複数ブランド・複数用途のロボットの導入効果を、統合された導入対効果のダッシュボードに束ね始めている。可視化・レポーティングは、放っておいてもこの層が標準機能として埋めていく。ロボットのメーカー側も、純正のアナリティクス機能を厚くしている。台数が増えるほど、純正のダッシュボードも厚くなる。つまり、成長するソフト層の中でも、可視化そのものは最も早くコモディティ化する場所だった。

ただのデータの可視化はビジネスとして筋が悪そう。

そこに個人がきれいなダッシュボードだけで参入すると、育つ市場のなかで最初に価格が溶ける場所に立つことになる。しかも、参入するだけでも壁がある。PUDU・Keenon・Bear の API は、実機を持っているか、ディストリビューター契約があることが事実上の前提で、個人が機体なしに単独で叩くのは難しい。可視化スキルの側は参入障壁が低く、API アクセスの側は障壁が高い。この組み合わせは、個人にとって最も不利な形をしている。可視化を売り物にしない。ここが設計の出発点になった。

産業用との違い：量は工場、伸びしろと設計者の適性は施設内サービス

ひとつ補助線を引いておく。産業用ロボットのデータ可視化は、工場の稼働監視や設備効率の可視化として既に成熟した受託領域だ。MES・WMS 連携も確立していて、案件の絶対量はこちらが圧倒的に厚い。ただし競争も激しく、エンジニアリング主導で、デザインの入る余地は薄い。

一方、フィジカルAIの文脈は熱量が別次元で立ち上がっている。ロボティクス関連の論文数はこの数年で桁違いに増え、民間ロボティクス投資も過去最高の水準に達している。母数はまだ薄いが、伸びと注目は急だ。加えて、顧客の顔ぶれが産業用と違う。飲食・宿泊・医療といった、必ずしもITが主業でない現場に、広く散っている。数字を羅列されても読めない相手が多い、ということだ。

この非対称が効く。エンジニアが作る生データの羅列を、意思決定者が一目で読める形に設計し直せる者は、この層では稀少になる。可視化そのものは価格が溶けるが、可視化を「読める設計」に変える仕事は、まだ空いている。量で戦うなら産業用、伸びしろと設計者の適性で戦うなら施設内サービス。後者を選ぶ、という土台がここで固まった。

補正記憶システムと、経営者向け ROI シミュレーター

可視化の代わりに何を核にするか。候補は二つ出た。ひとつは補正記憶システムの構築。ロボットが同じ場所で詰まる・遅れるパターンを学習して直していく仕組み。もうひとつは経営者向けの ROI シミュレーター。ロボットを入れると搬送時間・距離・コストがどう変わるかを、意思決定の前に見せるツール。

補正記憶システムの方は、見送った。これは精度を上げる仕事で、「体験の成立を先に、精度はあとから」という設計哲学と逆を向く。ロボットが詰まるパターンを学習して直すのは、フリート管理としてメーカー純正が最も取りにいきたい中核機能でもある。個人が食い込む隙間は構造的に薄い。何より、ここで効くのはロボット制御のエンジニアリング力で、29年のデザイナーという強みが働かない。契約層のシステムインテグレーターから見ても「それはメーカーがやる」と言われる領域だ。

ROI シミュレーターの方は逆に、いま設計しているハコブくんそのものだった。体験から逆算する設計思想、UX と AI と Robotics の交差点、導入判断でロボットの効果を示したいという契約層のニーズ、すべてに乗る。純正が出しにくい理由も明確で、メーカーが自社ロボの導入効果を「買う前の、中立であるべき意思決定段階」で正直に見せるツールを作るのは、売り込みバイアスと構造的に相性が悪い。第三者のデザイナーだからこそ立てる場所だった。

補正記憶を、ロボット制御ではなく意思決定に注入する

ここで話が畳まれた。補正記憶と ROI シミュレーターは、どちらを選ぶかの二択ではなかった。片方の思想を、もう片方に注入できる。

補正記憶の本質は「試行して、実測と照合して、ズレを次に活かす」というループだ。これをロボット単体の制御ではなく、経営の意思決定に適用するとこうなる。導入前はデータがないので、ハコブくんで「この前提ならこうなる」を探索する。これは中立の意思決定支援だ。導入後は搬送ロボットの API から実測が取れる。そこで、導入前に置いた前提と実測のズレを照合して、次の導入判断の前提精度を上げていく。

純正のダッシュボードの中心は、いま起きている運用の可視化にある。これから設計するツールは、導入前に置いた予測と導入後の実測を照合し、そのズレを次の判断の前提に還す。

「予測と実測のズレを学習して、次の判断を補正する」。これはデータの可視化ではなく、意思決定の補正ループ。

言葉にするとこうなる。可視化はスナップショットを見せる。補正ループは、外した予測を次の予測の材料にする。売っているものが違う。

実測層は空の器として、記録スキーマだけ先に二層で持つ

ただ、補正記憶をこの ROI ツールに組み込むと言ったとき、その中身を正確に定義しないと過剰設計に転ぶ。ここは慎重に線を引いた。

補正ループは、時間軸の違う二つのフェーズをまたぐ。導入前はデータがないので、探索シミュレーションで予測する。導入後は顧客が実際にロボットを運用していて、API から実測が取れる。ループが回るのは、この実測が入ってきてからだ。つまりループの実測側は、契約が生まれ、導入が起き、運用データが溜まって初めて動く。時期で言えば先の話になる。

だから、いまの構想段階で「補正記憶の構造を組み込む」の正しい解釈は、いますぐ実データ連携を作ることではない。記録の構造を、最初から「予測層」と「実測層」の二層で設計しておくことだ。実測層は当面ずっと空でいい。器だけ先に空けておく。実データが手に入る将来のフェーズで、そこに実測を差し込めば、予測と実測が同じ一件の記録の中で照合できる。いまのフェーズで実データ連携そのものを作り込むのは、顧客も運用実績もない段階での過剰設計になる。そこには踏み込まない。

二層の中身を並べるとこうなる。

予測層はいま作る。実測層は列だけ用意して空にしておく。差分は、実測層が埋まって初めて計算できる。

この二層構造は、新しく発明したものではない。R2R2R 側で既にやっていることの移植だ。あちらは pose_id という照合キーで、予測姿勢・予測器・実機結果の三系統を結んで、後から予測と実測を突き合わせられるようにしている。一件の試行を「設定 + 結果」として記録し、状態語で「どこまで到達したか」を残す。ハコブくんの記録は、この型を移動体の運用シミュレーション版に翻訳する。一件の記録を「シナリオ設定 + 予測結果（＋後で入る実測結果）」として定義する。新しいバズワードは要らない。既存の型をそのまま再利用する。

支出側は ROI・回収期間まで乗せる

この構造が決まると、開いていた宿題が連鎖して閉じた。

支出側を「効果だけ」に留めると、照合ループが回らない。予測した効果と実測した効果を突き合わせるだけでなく、予測したコストと実測したコスト（保守費・消耗品）も突き合わせて初めて、次の導入判断の前提が締まる。だから支出側は実測まで乗せる構えに倒れる。

前に出しすぎない、という制約

最後に、自分に対する制約をひとつ残しておく。

この ROI の方向は、「動きの品質・体験の設計」という本来のポジションから少しストレッチしている。「導入判断の可読性」を Robotics UX の枠――意図の可読性、学習しやすさの設計――の延長に置く理屈は通る。通るが、いまのフェーズで前面に出す主指標は別にある。ROI ツールを事業の柱として前に押し出しすぎると、いま集中すべき足場が薄まる。

だからこれは、静かに仕込む設計思想として据える。前面に置くのは、あくまで Physical AI UX の実装ログのままにしておく。補正ループは、器を先に用意しておいて、実データが来る将来のフェーズで動き出す。それまでは設計として持っておく。

可視化は売らない。いま起きていることを、きれいに見せるだけでは足りない。導入前に置いた予測と、導入後に返ってくる実測を、同じ一件の記録に並べる。外した予測を、次の判断の材料にする。ハコブくんで設計するのは、ダッシュボードではない。意思決定を補正するための、記録の器だ。

<!-- ===== 以下は調査メモ（備忘録）。Log#02 本文とは主題が異なり記事としての辻褄は合わない。市場調査・職務構造・支払者予測の記録として保全する。 ===== -->

サービスロボット市場の定着の失敗と、業務フロー設計という空白

このセクションは Log#02 本文の続きではない。可視化を売らないと決めた後、「では市場そのものは満足しているのか」「業務フロー設計とは誰の仕事か」「その仕事に金を払うのは誰か」を掘った記録を、備忘録として残す。記事としての整合は取らない。

市場は満足していない：台数は増えても定着していない

台数が増えていることと、現場が人手不足を解消できたと感じていることは別だった。調べると、両者は大きくズレている。

導入側が効果を実感している面は確かにある。あるアンケートでは、導入後に「配膳・下げ膳の負担が減った」と答えた従業員が66.3%、「他業務に時間を使えるようになった」が49.5%に上り、約3割が「40〜60%の業務負担軽減」を実感したと報告されている。下膳業務の9割をロボットが担い、体力的理由での退職がほとんどなくなった施設の事例もある。

しかし同じ現場から、不満と限界の声が構造的に出ている。費用対効果が回りきらない（買い切りで約200〜350万円、高機能モデルは500〜600万円前後で、導入後すぐの回収は難しいケースが多い）。繁忙時に人とロボットが同じ動線で混雑し、逆に効率が落ちる。太陽光がセンサーに入るとロボットが障害物と誤認して立ち往生し、人の手で再設定が要る。料理のトレイへの積み込みや食器の積み込みは依然スタッフの手作業で残る。突発的な状況への対応が不得手で、「人手不足の解消」ではなく「特定の定型業務の肩代わり」にとどまる。複数機種を扱う事業者自身が、導入後に「現場に合わなかった」「思ったほど活用できなかった」という声が一定数あると書いている。

公的統計は、この定着の失敗をさらに踏み込んで示している。介護分野では、介護労働安定センターの令和3年度調査で全事業者の80.9%が介護ロボット未導入。最も普及している見守り・コミュニケーション（施設型）でも導入率13.9%。数年前の調査では未導入が75.4%で、導入しない最大の理由は「導入する予算がない」が59.3%だった。台数が増えているのは事実だが、母数の大半はまだ入れていない。

さらに、入れた現場でも定着していない。国の政策文書（ロボットアクションプラン）自身が、ロボットや個々の技術は進化したが、ロボット導入現場のニーズとの間に未だギャップがあると明記している。第三者の分析では、補助金1,000万円を使っても普及率4割止まりで、介護テクノロジーは機器の導入自体が目的化し使いこなせるかは後回しになりがちだった、という構造的盲点が指摘されている。

一方で、正しく設計すれば効果は定量的に出る。厚労省の実証はタイムスタディ（導入前後の業務時間比較）と心理的ストレス反応測定で効果を検証しており、個別事例では見守りロボット導入で月平均訪室回数25%減・残業3時間減という数字も出ている。効果は出る。ただし「入れれば出る」のではなく、業務フローとの噛み合わせ設計と組み合わせて初めて出る。定着の失敗の正体は、機体の性能ではなく、業務フロー設計の欠落だった。

業務フロー設計は誰の仕事か：専任者が存在しない

業務フロー設計とは、ロボットという新しい働き手を、既存の人の仕事の流れのどこに、どう差し込むかを決める仕事だ。機体を買うのがハードの話、その機体を中心に人の動き・タスクの順序・時間帯配分・例外処理を組み直すのが業務フロー設計になる。

これを専任する単一の職種は、ロボット企業の中に存在しない。近接する職種は三つあるが、それぞれ範囲が違う。デプロイメントエンジニアは据付・立ち上げを納期通りに回す実行にフォーカスした役割で、業務フローの組み替えは主務でない。フィールドエンジニアは顧客サイトでの設置・較正・保守が中心で、動かし続ける側。アプリケーションエンジニアは既存ワークフローへの統合を担うが、実態はプログラミングとシステム統合が重心のエンジニア職だ。

ここで重要な事実が二つある。ひとつ、これらは例外なくエンジニア職で、要件は機械・電気・CS系の学位、Python・C++・ROS、CAD、制御系。業務フローを人間側から設計し直す役割としては定義されていない。ふたつ、この仕事は複数の職種にまたがって分散し、誰の中心的責務でもない。据付を回す者、保守する者、プログラムして統合する者、契約を維持する者――全員の責務の縁に少しずつぶら下がっている。

つまり欠落しているのは能力ではなく主体だ。「この病院の看護師の1日の動線の、どこにロボットを差し込めば人手不足が実際に軽くなるか」を、現場の業務を主語にして設計する専任者が、職種表に存在しない。エンジニアがついでにやるか、現場に丸投げされるか、大手SIerが高額コンサルとして重量級で提供するかのどれかで、その狭間に落ちている。定着の失敗はここで起きている。

業務フロー設計を時間軸で分解する（病院搬送・200床5階建てを想定）

薬剤部が1階、病棟が2〜5階。従来は看護助手や薬剤部スタッフが薬剤・検体・リネン・給食・医療物品を台車で運ぶ。ここに搬送ロボットを2〜3台入れる、という設定で、業務フロー設計者は時間軸ごとに違う仕事をする。

日次（観察と微修正）。 ロボットが動く1日に張り付いて、人の仕事と噛み合っているかを見る。朝6〜9時の最繁忙帯（配膳・採血・検体・薬剤が集中）で人とロボットが廊下で詰まっていないか。昼の面会・給食帯でエレベーター待ちが何分か実測し、想定と乖離すればスケジュールをずらす。夜は静音・減灯すべきか、速度を上げられるか。日次のアウトプットは「詰まった場所・待たされた場所・人が手で運び直した場所」の記録で、これが補正ループの実測データになる。

週次（パターンの発見）。 曜日の波を見る。月曜は入院が多く金曜は退院が多い、手術日は器材・検体が跳ねる。1週間分のログを集計し、どの曜日のどの時間帯に搬送需要がピークになるかを出して、足りない時間だけ人がカバーする、ルートを組み替える。あわせて現場スタッフに「ロボットのせいで増えた手間はないか」を聞き、翌週に反映する。人の使いにくさを言語化する力が効く層。

月次（効果測定と経営への翻訳）。 導入前の予測（シミュレーションで出した搬送時間・移動距離・人件費の削減見込み）と1ヶ月の実測を突き合わせる。予測層と実測層の照合そのもの。タイムスタディを月次で回し、往復回数や訪室回数が実際に何%減ったかを測る。そのうえで、ズレを経営層が読める形に翻訳する。「予測30%減・実測18%減、差の12%は朝の繁忙帯でロボットが人に道を譲って待機した時間」というように、数字だけでなく原因まで示す。純正ダッシュボードは現在値を映すだけ。ここで原因と次月の打ち手まで示すのが「読める設計」の核心。

四半期（構造の組み替え）。 微修正で埋まらないズレに構造で手を入れる。3ヶ月回すと「ロボットに向く搬送（定時のリネン・給食）」と「向かない搬送（即時性が要る緊急検体）」がデータで分離できる。台数の再判断もここ。2台で足りるか、3台目か、特定時間帯だけ稼働で1台減らせるか。費用対効果の再試算で、支出側（本体・保守・消耗品）の実測が効く。導入判断をもう一度やり直す層。

年次（横展開と再現性）。 1年回すとこの病院の搬送フローが安定する。そこで得た知見を「この病院固有の事情」と「他院にも通じる汎用パターン」に分離する。環境非依存の計算エンジン＋環境ごとのシナリオ設定という構造と同じで、病院Aの設計を病院Bにはシナリオ差し替えで移せるようにする。季節変動（インフル流行期の搬送増、年末年始の人員体制）を捉えられる唯一の層でもある。

この5層は、時間軸が上がるほど観察から設計へ、現場から経営へ重心が移る。そして全部が補正ループの時間解像度違いだ。日次で詰まりを記録し（実測）、月次で予測と照合し（補正）、四半期で導入判断をやり直し（次の予測）、年次で横展開する（型の再利用）。予測層／実測層の二層スキーマは、この5つの時間軸すべてに同じ構造で効く。ロボット企業のエンジニア職が担うのは据付前後の一瞬と保守だけで、日次の観察・週次のヒアリング・月次の経営翻訳・四半期の構造組み替え・年次の横展開という継続的な設計の層は、専任者不在のまま現場に丸投げされている。

この設計に金を払うのは誰か（構造予測）

受益者（価値を感じる人）と支払者（予算を持って発注できる人）は分けて考える必要がある。この領域の罠は、受益者は明確なのに支払者が曖昧なことだ。支払者候補を可能性の高い順に置く。

第一予測：ディストリビューター／販売代理店（最も可能性が高い）。 機体を売って終わりでなく、定着しないと解約・返品・悪評で次が売れないため、定着率が売上に直結する。彼ら自身は業務フロー設計の専任者を抱えていない。「ロボット×システム連携マーケティング」を次の成長領域と明言する代理店もある。持っていない設計能力を外部調達する動機がある。ただし彼らが払うのは自分の機体を売るコストを回収できる範囲まで。付帯サービス扱いで、単価は販売マージンに制約される。

第二予測：大規模・多拠点の導入企業（受益者と支払者が一致する稀なケース）。 チェーン飲食、病院グループ、ホテルチェーン、大手物流。多拠点だと定着の失敗のコストが桁で効く（1拠点で数百万の損が、50拠点で数億溶ける）。横展開の前に「一つの拠点で確実に定着する型」に独立予算を出す動機がある。ただし多くは「ロボット導入プロジェクト」の一部としてで、情報システム部門・業務改善部門・経営企画のどこが予算を持つかは企業で割れる。

第三予測：ロボットメーカー本体（可能性はあるが構造的に弱い）。 定着率向上でリピートと横展開が生まれる理屈は通るが、メーカーは純正アナリティクスを自社で厚くする＝内製化に動いており、外部デザイナーに払うより自社機能にする確率が高い。機体単価を下げる競争の中で付帯サービスに外注コストを乗せる余裕も薄い。

第四予測：SIer（契約層。ただし役割が反転する）。 この文脈ではSIerは金を払う側であると同時に、同じ仕事を高額コンサルで上位から押さえる競合でもある（病院向けに費用対効果試算までやる事業者が実在する）。SIerが払うとすれば、手が回らない・デザイン品質が足りない部分を下請けに出す形。元請けSIer→下請け、という流れ。

畳むと、最も可能性が高いのは、最終受益者（病院・飲食チェーン）から直接ではなく、ディストリビューターかSIerを経由して受け取る構造だ。最終受益者は「業務フロー設計」という商品を単体では認識しておらず、認識しているのは「ロボットを入れる」プロジェクト全体で、その予算は機体購入費に紐づいて経由業者に流れる。設計・体験の部分を、その流れの中から受け取る。

留保：これは支払者の構造予測であって実額の一次データではない。「業務フロー設計」という商品の確立した相場は市場が黎明期のため存在しない。誰の財布から出るかの構造までは予測できるが、いくらかは市場未形成ゆえに確定できない。