ハコブくん 病院オペレーションのデジタルツイン Log#3 | 病院の搬送ロボットは看護師の負担を減らすのか ─ 作る前に調べたら、前提が四つ崩れた

薬剤搬送ロボット「ハコブくん」の病院シミュレーションを、実装に入る前の設計として進めた。Unity で病院を作り、医師・看護師・患者・業者とロボットを同じ廊下で動かし、24時間分の記録を CSV で取る。そういうものを作ろうとしていた。

結果として、この回はコードを一行も書いていない。代わりに、置いていた前提が次々に崩れた。看護師の搬送時間を測った調査はあったが、その数字は基準点として使えなかった。ロボットの比較対象は人手ではなかった。効果の一般的な数字はそもそも存在しなかった。そして高いと思っていた改装費は、高くなかった。

崩れた順に書く。設計の結論だけでなく、何を検討して何を捨てたか、どこで間違えたかも残す。

環境・地点マップ・振る舞いの3層に切る

出発点は、Unity と Claude を MCP でつなぐ話だった。ローカルの Unity と MCP で接続できるのは Claude Code か Claude Desktop で、無料の CoplayDev 版なら Unity 2021.3 から 6.x まで対応する。パッケージを git URL で入れて Auto-Setup を押せば繋がる。

ただし、MCP を繋ぐと AI が Unity エディタに直接書き込めるようになる。mechArm のデジタルツインが入っている既存プロジェクトには、絶対変更禁止の定数（ArticulationBody の Stiffness 20,000 / Damping 2,000）と、読み取り専用の FK テーブルが同居している。過去にシーン消失のインシデントも起きている。だから病院シミュレーションは別の Unity プロジェクトとして立て、MCP はそちらにだけ繋ぐことにした。分けるコストはほぼゼロで、失うものは大きい。

そのうえで、以前作った病院シミュレーションの構造を見直した。過去の実装では、病室の生成もロボットも医師も看護師も、同じスクリプトの中で生成していた。細かな修正が行いづらい。

コードを読むと、絡んでいる箇所は3つあった。ひとつ、Start() で BuildLayout() を呼んでいるので、再生ボタンを押すたびにフロアが作り直される。手でベッドを1つ動かしても、次の再生で消える。ふたつ、振る舞い側が環境をオブジェクト名の文字列で探している。obj.name.StartsWith("Bed_") で全 GameObject を舐めているので、生成側の命名を変えた瞬間に静かに壊れる。みっつ、エージェント同士が互いの型を知っている。ロボットが「看護師とは StaffPatrol が付いているもの」と知っているので、人を1種類増やすたびにロボットのコードを編集することになる。

分ける場所は「部屋とロボット」ではなく、環境と振る舞いの間に地点マップを挟む形にした。

層1  環境      病院フロアの床・壁・扉・ベッドの形と位置
       ↓ 出力するのは「地点のリスト」だけ
層2  地点マップ  Bed_301 は (x,z)、ナースステーションは (x,z)
       ↑ 参照するのは「地点」だけ
層3  振る舞い    ハコブくん・看護師・医師・患者・業者の動き

これで層1を触っても層3のコードは変わらず、層3を触っても層1は再生成されない。地点を名前で探さずマップから引く構造は、mechArm 側で姿勢を勘で作らず FK テーブルから引いているのと同じ規律だ。マップに載っていない場所へは行けない。これは制約ではなく、行き先が全部一覧できるという意味になる。

生成スクリプトは捨てず、[ContextMenu] にして手動実行にした。白紙から下書きを作る道具であって、実行時の部品ではない。

建物内シミュレーションは5つの産業に分かれている

「実際の現場では何を使っているのか」を調べたところ、これは1つの分野ではなく、別々の質問に答える5つの産業だった。

医療分野の離散事象シミュレーションを集計したレビューでは、Arena が最も多く、次いで ProModel、FlexSim、Simul8、Simio、AnyLogic。専用ツールだけでなく R と Excel も頻繁に使われている。これらは台数・待ち行列・稼働率に答えるが、動きの質は測らない。

歩行者シミュレーションは建築側の分野で、Arup の MassMotion は北京大興国際空港のような大規模プロジェクトに使われている。Revit や ArchiCAD の 3D データをそのまま読み込む。ただし、これらはロボットをモデル化しない。

もっとも近いのは3番目、特に Open-RMF だった。2018年、シンガポールの病院で清掃・配送・警備といった用途の違うロボットを同一空間に走らせる課題から生まれ、ROS 2 上に構築され Gazebo でシミュレーションされる。チャンギ総合病院に実際に導入されている。火災報知器が鳴ったらロボットを廊下の脇に寄せる、人が押しているベッドも交通管理の対象に入れる、平面図を GUI で注釈して通行パターンを YAML に書き出す。ハコブくんの構想とほぼ同じ場所から出発している。

そして Unity は、この地図では業界標準ではない。ロボット制御の検証は Gazebo と Isaac Sim が押さえていて、Unity 自身の Unity Simulation は2023年12月に廃止されている。一方で環境構築の速さと、顧客・関係者に見せる用途では強い。「センサーなら Isaac、ROS なら Gazebo、UX と関係者への説明なら Unity」という要約が出回っている。

この5分野を並べて、空いている場所が見えた。離散事象は台数に答えるが動きの質を測らない。歩行者シミュレーションはロボットを入れない。ロボットシミュレータは人がどう感じるかを測らない。ベンダーのものは自社製品で元が取れるかしか答えない。ハコブくんの動きが看護師に配慮あるものとして読めるかを測る枠は、どこにもなかった。

MacBook で出せる最大値は、描画ではなく試行回数

手元は MacBook 1台で、Isaac Sim は動かない。GPU が要る道（センサー再現・写実描画・強化学習）は全部閉じている。閉じていないのは、NavMesh と数値記録だけで完結する実験を大量に回す道だった。

Time.timeScale を上げて8時間のシフトを数分で回す。-batchmode -nographics でコマンドラインから叩けば描画コストが丸ごと消える。100試行を寝ているあいだに走らせて、朝 CSV を読む。実機と違って、失敗しても壊れるものがない。

ここで測る対象を、他のツールが測っていない場所に寄せた。ロボット側の効率ではなく、人とロボットの負担の配分を測る。ロボットが譲った回数と人が譲った回数の比、遭遇1回ごとの最小接近距離、減速を始めた時点の距離、減速にかけた秒数。最後の2つが「意図の読み取りやすさ」の代理指標になる。遠くから緩やかに減速するロボットは、近くで急に止まるロボットより、人から見て何をしようとしているか分かる。

ただし、この時点で書いた所要時間の見積もり ── timeScale 10倍で24時間が2.4時間、100倍で14分 ── は単純な割り算で、実測ではなかった。実行速度を測っていないのに表にしていた。同じように「病棟1フロアなら問題ない規模」「ProBuilder で30分」といった数字も、根拠なく書いていた。

実装を止めて、決定項目を10分野に分けた

そこで実装に進まず、状況整理に切り替えた。前提として置いていたものを名指しで洗い出し、決めるべき項目を10分野に分けた。位置づけ、対象と範囲、時間、エージェント、業務、攪乱、測る対象、データ、文書・ルール、公開。

依存関係を並べると、目的が決まらないと下が全部揺れることが分かった。記事のネタとして作るのか、実機ハコブくんの前段として作るのか、SIer への提案材料として作るのか。それぞれ必要なものが違う。

選んだのは3番目だった。ターゲット顧客の定義と一致し、前の調査で「攪乱からの復旧時間と人の負担配分を測るツールが無い」ことが分かっていて、空いている場所に立てる。実機で検証できないので「予測の道具」と明示する必要がある。

そこから項目を順に埋めた。新シリーズとして立て、既存の受け渡し・画像認識シリーズと3系統並行。架空病院だが実在病院を調べてベースにする。複数フロアで階を跨ぐ。1試行は24時間。患者は動く。人がハコブくんを避けるのが基本で、人の状況によってはロボットも動く。搬送タスクは定時と確率発生の両方。割り当ては最近傍。未処理タスクは人が肩代わりする。攪乱は全時刻を走査する。出力は時系列・イベント・台帳の3層。

要件定義書 v2 ─ すべての数値に出典区分を付けた

機体側の仕様を書き直した。v1 には数値に出典がなく、どれが決めた値でどれが置いた値か区別できなかった。台帳の列数や FK テーブルの点数で繰り返してきた「焼き付いた数字が実体とズレる」を、この文書では最初から塞ぐことにした。

v1 に無かった数値を、実機から参照値として補充した。最大走行速度 1.0 m/s、連続運転時間 約7時間、充電時間 約2.5時間。いずれも HOSPI のカタログ値で、ハコブくんは実機が存在しない以上、これ以外に根拠を持てない。この3つを使って結果を出す場合、「HOSPI 相当の性能を仮定した場合の結果」であることを結果と一緒に記録する。

廊下幅は訂正した。v1 の「有効幅員 1.2 m〜」は診療所の基準で、稼働環境として掲げている総合病院の病棟には該当しない。医療法施行規則 第16条第1項第10号による患者用廊下の幅は、一般病床で片側居室 1.8 m 以上・両側居室 2.1 m 以上（いずれも内法）。過去のシミュレーションコードで使っていた 2.7 m は療養病床・両側居室の値で、一般病棟としては広すぎた。

そして譲り合いの設計を新設した。v1 は「衝突を回避する」としか書いておらず、どちらが避けるかが定義されていなかった。減速開始距離、停止距離、譲歩時の速度低下率、ロボットが能動的に避けに転じる条件、膠着の解除方法。この5項目は全部「未定」のままにした。決める項目ではなく測る項目だからだ。

薬剤と配膳を同じ機体で運ばない

決定項目を埋めるなかで、矛盾が1つ出た。搬送物として配膳・リネン・廃棄物を含めていたが、要件定義書のハコブくんは薬剤専用で、15kg・シングルドロワー・トレー4枚では配膳車もリネンも運べない。

実際の病院で何を運んでいるのかを調べると、答えははっきりしていた。技術的に混載できないのではなく、運用として分けている。

HOSPI のカタログの搬送物欄は「一般薬品／要管理薬品／検体／カルテなどの文書類」で、配膳・リネン・廃棄物は含まれず、大型荷物には HOSPI Cargo という別機種がある。Aethon も薬剤・検査材料用の Zena RX とカート搬送用の T3 を機種として分けている。同社のマーケティング担当者はこう語っている。同じ TUG が清潔リネンを運んだあと向きを変えて食事を運ぶこともできるが、顧客のほとんどは TUG を部門ごとに分けている、と。

「できるが、やらない」。これが答えだった。

理由は3つある。建築が先に分けている ── 病院設計の基本原則は清潔／準清潔／不潔のゾーン設定で、建物が動線を分けているのにロボットだけが跨ぐのは設計として通らない。廃棄物は法令上の別カテゴリで、感染性廃棄物は特別管理産業廃棄物にあたり、薬剤と同じ庫に入る余地が制度上ない。セキュリティの粒度が違う ── 薬剤庫は施錠と認証記録が必須だが、配膳とリネンに同じ機構を付けると運用が回らない。

この調査で、要件定義書に書かれていなかった数値がほぼ全部埋まった。走行速度・連続運転時間・充電時間・全高・収納庫寸法。7時間稼働・2.5時間充電が実機の実績値だと分かったことで、24時間シミュレーションの充電サイクル設計が推測でなくなった。

エレベーターの扱いも実機に答えがあった。HOSPI はエレベータ使用時に一時的に専用モードへ切り替える。利用者の不安と、乗降時にロボットが障害になることを避けるためだ。つまり人と同乗させない。ロボットが乗るあいだ、そのかごは人が使えない。

停電時はその場で停止して発光する

攪乱として初版に含めるのは、ロボット故障と停電の2種にした。地震は入れない。人の避難行動という測れない仮定が大量に入り、出力の根拠が説明できなくなるからだ。

停電を入れると、バッテリーが初めて結果に効く。充電器が止まり、充電できず、7時間の稼働時間を使い切った機体から順に止まる。停電は「遅れて効く故障」を生む。実機由来の参照値がここで初めて出力に効き、24時間である理由が成立した。

停電を検知したときの挙動について、退避地点へ移動してから停止する案を出した。廊下を塞がないからだ。だが選ばれたのは、その場で停止し、発光する案だった。

停電を検知では発光して、その場で停止。まずは周りを照らして自分の存在を知らせるのと、緊急の室内灯がわりになるようにする。それで邪魔になるようなら次考えます（停電時にどのように人が動くかわからないため）

この判断のほうが正しかった。退避地点案は「廊下を塞ぐと邪魔になるはず」という仮定に基づいて、退避地点という仕組みを先に足す設計だった。まず塞がせて、邪魔かどうかを測ってから決める。シミュレーションを持っている意味がそこにある。それに退避地点案を選んでいたら、「停電時に人がどう動くか」という測れない仮定を、退避地点の配置という形で先に埋め込むことになっていた。

発光を持たせたことで、測る対象が増えた。停電中に人がどこを通るかは事前に分からない。だからこそ走らせて、光が実際に使われる場所に落ちているかを見る。

復旧を人が判断する設計と、その適用範囲

停電から正常への復帰を誰が判断するか。決まったのは、システム管理者または管理者キーを持つ現場スタッフが判断し、ロボットの自律判断は持たせない、だった。停電は稀な事象であり、安全性を最優先する。

これでインフラとロボットが二層に分かれた。電気は自動で戻るが、ロボットは勝手に動き出さない。結果として、復電から業務回復までの時間がほぼ全部「人の作業時間」になる。15分の停電が何時間の業務影響になるかは、機械の性能ではなく人の動きで決まる。

故障時も同じ扱いにした。理由づけが効いている。

勝手にロボットで判断する能力は今の段階ではできたとしてもハードやソフトのオーバースペックを招きやすいため。

「できるかどうか」ではなく「持たせると何が過剰になるか」で決めている。判断能力を足すと、その判断を成立させるためのセンサー・計算資源・検証コストが連鎖的に必要になる。判断を人に置けば、機体はシンプルなまま済む。

ただしこの判断には範囲があった。

あくまでもロボットが数台、もしくは十数台稼働までかな。もし将来ロボットが数百台、数千台同時稼働する状況になった時に、全てを人が管理者キーで復旧させるのはかなりの重稼働になるため。

条件付きのルールとして書き直した。いつまで有効かを書いた設計方針になる。そして重要なのは、この境界がシミュレーションで測れることだ。台数を 4/8/16/32/64 と振って復旧時間と管理者の作業時間を測れば、台数を増やすほど搬送効率は上がるが、ある台数を超えると復旧作業が管理者の勤務時間を食い潰す。その交点が「人による復旧が成立する上限」になる。

「ロボットを増やせば効率が上がる」の反対側 ── どこで頭打ちになるか ── を出すツールは、5分野のどれも持っていなかった。

主指標が決まった ─ 看護師の負担は増えるかもしれない

何を知りたいのかが、ここで明確になった。

ロボットの稼働を高くするには、看護師や医師の対応の素早さも必要だが、それが新たな負担になるのか？ならないのかを事前に知れるシミュレーションにしたい

測るのは引き算だった。搬送に費やしていた時間（減る）から、ロボット対応に費やす時間（増える）を引く。この差がマイナスになる条件がある。それを見つけるのがこのシミュレーションの目的になる。

ロボットを入れたのに看護師が忙しくなる。受け取りに呼ばれる回数が増え、廊下で待たされ、故障のたびに復旧に行く。台数を増やすほどそれが増える。どこで反転するかを事前に知る。

だから看護師の負担の増減とロボットの稼働率を、同じ行に並べる。片方だけ見ると必ず間違える。稼働率を上げたければ看護師が処置を中断して駆けつければいい ── そのとき負担は悪化する。この2つを一緒に見て初めて、成立点が見える。

出力は1つの数字ではなく、条件を振った比較表になる。台数8までは負担が減り続けるが、12を超えると受け取り対応と復旧作業が削減分を食い始め、夜勤帯では6台で反転する ── そういう文が出ればいい。

そして比較の基準点として、ロボットがいない状態が必要になった。

まずロボットを導入する前に人だけの状況で、看護師や医師が薬や書類の受け取りのためにどのくらい移動の時間を使っているかのデータも作らないと比較検討ができないね。

これで基準点が2段になった。ロボット0台の状態と、ロボットあり・攪乱なしの状態。前者がなければ主指標そのものが計算できない。設計上は、搬送タスクを「ロボットのタスク」ではなく「人にもロボットにも割り当てられるもの」として持つ必要がある。

前提1が崩れた ─ 搬送時間を測った調査はあったが、基準点には使えなかった

基準点を作るために、実際の搬送業務量を調べた。ここで最初の前提が崩れた。ただし崩れ方が、想定と違った。

日本の全国タイムスタディがある。厚生労働科学特別研究「効率的な看護業務の推進に向けた実態調査研究」で、47病院50病棟・看護師955名を対象に、24時間×3日間の調査を行っている。看護業務85項目のうち、搬送・移送【薬・検体・書類】の行為時間は、1病棟1人当り24時間換算で2.0分、構成比 0.1% だった。上位は看護記録 173.1分、排泄介助 112.8分、バイタルサイン測定 79.5分。

数字だけ見れば「看護師は搬送にほとんど時間を使っていない」と読める。実際、最初はそう読んだ。だが報告書の方法欄を読むと、そのまま基準点にはできないことが分かる。

理由は3つある。

ひとつ、測定はサンプリングだった。「実施している看護業務を10分間隔で85項目から選んでタブレットに入力」する方式で、連続観察ではない。10分ごとに「いま何をしているか」を1つ選ぶ。3分の搬送がサンプリング点に当たらなければ、記録に現れない。短くて頻繁な作業は、この方法では構造的に少なく出る。そして搬送は、まさにその種類の作業だ。

ふたつ、単位が個人の1日ではない。分析方法は「病棟ごとに4時間ごとに区分し、看護師1人当たり平均で240分中何分間各業務を実施していたかを算出」で、6区分を合計して1440分になる。つまり病棟の看護時間を、24時間連続の1人分に正規化した値だ。実在の看護師1人が1日に使った時間ではない。同じ表に休憩 141.8分が含まれていることからも、これが個人の勤務時間ではないと分かる。

みっつ、同じ表に「未入力」が 70.9分（4.9%）ある。何をしていたか記録されていない時間が、搬送 2.0分の35倍ある。

つまりこの調査から言えるのは「搬送は看護師の業務時間の構成比としては小さく出た」までで、「搬送に費やしている実時間は2分だ」ではない。基準点の数値としては使えない。

そしてもうひとつ、噛み合わない数字がある。移譲可能と考える看護業務の調査で、搬送【薬・検体・書類】は全体の上位10項目には入っていない。上位はリネン交換 96.3%、環境整備 94.7%、見守り・付き添い 93.6%。搬送が上位に入るのは病棟の属性を絞ったときで、500床以上で 93.3%、200から499床で 93.2%、慢性期で 91.0% となる。

規模の大きい病棟ほど、搬送を手放したいと答える割合が上がる。構成比としては 0.1% しかない業務が、である。報告書自身も考察で、移譲を「すべてできる」と考える業務群に搬送移送業務を挙げ、結論では「看護周辺業務は看護補助者への移譲やロボットやアウトソーシングの活用」が必要だと書いている。

この食い違いに、考えられる説明を4つ並べた。別の職種が運んでいる（看護補助者・SPD・メッセンジャー）。機械が運んでいる（気送管・軌道台車）。85項目の分類のしかたで、歩いている時間が別項目に計上されている。あるいは、時間としては本当に短く、問題は回数と中断のほうにある。

このうち実例で確認できたのは2番目だけだった。神戸市立医療センター中央市民病院は本館の天井裏に高速トレイ搬送システムを持っていて、南館との350m だけが空いていたところに HOSPI を入れた。京都大学医学部附属病院は老朽化した検体搬送機の置き換えだった。どちらも「元から機械が運んでいた」。

看護補助者と SPD については、制度は確認できた。急性期看護補助体制加算という診療報酬があり、看護補助者を配置すると病院に点数が付く。目的も「看護職員の負担の軽減」と明記されている。SPD は院内物流の外部委託で、点滴の運搬を含む。ただし何割を担っているかのデータは見つからなかった。

どれが主因かは決められないままだ。4つとも成り立つ。崩れたのは「看護師が搬送に時間を使っている」という前提ではなく、「公的な調査の数字を持ってくれば基準点が置ける」という前提のほうだった。

前提2が崩れた ─ 比較対象は人手ではなく既存の機械かもしれない

2番目の説明が実例で確認できたことは、設計に効いた。

ハコブくんのような自律ロボットは、人の代わりというより、古い機械の置き換えとして入っている。神戸の事例は「気送管を延長するか、ロボットを入れるか」の選択だった。京大の事例は「天井裏の搬送機は止まると人が触れないが、ロボットなら廊下で止まっても誰かが検体を取り出せる」という比較だった。

基準点を「人だけの状態」で組むと、効果を過大評価する。現実の病院は、ロボットを入れる前からすでに看護師以外が ── 別の職種か、機械かのどちらかが ── 搬送を担っている。

そして機械化されていても人はゼロにならない。気送管も軌道台車も両端に人がいる。薬剤部でカプセルに詰める人と、病棟で取り出して確認する人。この両端の作業が、そのままハコブくんの積み込みと受け取りに対応する。受け取り待ちは、機械搬送の時代からずっと存在していた作業だった。

前提3が崩れた ─ 効果の一般的な数字は存在しない

3つ目に崩れたのは、「搬送ロボットの効果」という数字が存在するという前提だった。

既存の搬送設備があるかないか、搬送を誰が担っているか、建物が単棟か別棟か、動線が数十mか350mか、エレベーターが専用か共用か、夜間に搬送要員がいるか。この掛け算の数だけ「導入前の状態」がある。

だから独立した査読研究で「導入前後の純減」を厳密に計測したものが乏しい。誰も測っていないのではなく、一般化できる形では測れない。企業の公表値も、特定の1病院の特定の条件下の数字だ。HOSPI の「1日約7時間20分の創出」も、臨時14回・定時8回・往復20分という前提が明示されている。前提が違えば結果は変わる。

つまり搬送のコストは病院側がどのような対策をしてきたかで大きく違ってまちまちで効果を測定しずらいってことかな？

測れないのは絶対値だけだった。「何時間削減できるか」は言えないが、「この条件では削減でき、あの条件では削減できない」は言える。そして最初に置いた目的 ── どういう状況で効果が高く、低くなるのかを知りたい、議論の叩き台として機能させたい ── は、まさに後者だった。

単一の数字を出そうとしていたら行き詰まっていた。病院ごとにバラバラなら、そのバラつき自体を軸にする。相手の病院がどのマスに当たるかを聞いて、そこの数字を見せる。それが叩き台の価値になる。

実機検証の不在も、これで位置づけが変わった。「実測していないので参考値です」という弁明ではなく、「搬送ロボットの効果は病院の前提条件に強く依存し、一般化した数値は存在しない。本シミュレーションは条件間の比較を目的とし、絶対値の予測を目的としない」と書けばいい。弱点ではなく設計方針になる。

独立した査読研究からは、効果を減殺する要因も具体的に出てきた。韓国の三次病院での実証（薬剤部から救急部への日常ルート、122ミッション）では、全体成功率 87.03%。エレベーター稼働率が 59.01% を下回る時間帯では 95.52% に上がるが、混雑時には失敗が集中し、乗客6人以上で失敗率が 90% を超えた。そして受容性の調査で、看護師のスコアが最も低かった。論文はその理由を、ロボットを迎えに遠くまで歩く・タッチスクリーンを操作する・内容を確認するという追加のマイクロタスクが生じたことに帰している。

「ロボットが来たら受け取りに行かなければならない」が新たな中断になる。主指標がマイナスに振れる可能性の、直接の裏付けだった。

前提4が崩れた ─ 改装費はエレベーター1基30万円だった

最後に崩れたのが、改装費だった。

UCSF の事例では、25台のロボットを350万ドルで購入し、さらに250万ドルを建物側の改修に費やしている。総額の4割強が工事だ。この数字をもとに「改装費が高いから対象病院を絞るべき」という理屈を組み立てていた。新築が有利、既存の多階層は不利、と。

だが日本の現状を調べると、前提が違っていた。エレベーターとロボットを直接連携させる場合は 100万〜1,000万円の工事が必要だが、「通信機能付きエレベーターアダプター」を後付けする方式なら、工事費用は30万円程度、工期は最短半日。旧型エレベータにも対応する。

ここで一度、比較を誤った。「250万ドルが30万円になった、桁が3つ違う」と書いたが、UCSF の250万ドルは25台・80万平方フィート・エレベーター6基・数百の扉の総額で、30万円はエレベーター1基のアダプタ1個だ。比べているものが違った。数字を並べて印象を作ってしまった。

正しくは、変わったのはエレベーター連携の1項目だけだ。ただしそこは本当に安くなった。「エレベーターを入れ替える」から「箱を1個付ける」への変化は実在する。

日本にはロボットフレンドリー施設推進機構（RFA）があり、規格も出揃っている。エレベーター連携、セキュリティ連携（扉）、物理環境の分類と指標、画像標識、防災システム連携。3番目の「物理環境の分類と指標」は、建物側の環境を等級として表し、そのレベルで動けるロボットを選ぶという考え方で、まさに「どこまで改修されているか」を段階化したものだ。5番目の防災システム連携は、停電・地震の設計に直結する。

病院での実証も国の事業として進んでいる。経産省の令和6年度事業に「病院パブリックエリアでの AMR 搬送テストによる、人との共存を可能にするシステムとルール作り」が採択され、幹事組織は京都大学医学部附属病院。別枠で「ロボットが簡易かつ廉価にエレベータに自律的に乗降する手法の確立」も採択されている。

解決済みなら国が予算を付けない。エレベーター連携サービスを導入している施設は2024年時点で全国74。日常的な技術になっているとは言えない。だが、UCSF の250万ドルのような額が前提ではなくなったことは確かだ。

そして要件定義書の設計が、たまたま有利に働いていることに気づいた。ハコブくんは薬剤庫を施錠している。だからロボット本体が制限エリアの中まで入る必要がない。廊下で待って、認証者が来て開ける。セキュリティ扉の連携が要らない。

「庫を施錠する」という設計判断が、そのまま工事の削減に効いている。一方で、同じ判断が人の負担を増やす ── 認証者が来るまで待つ。コストを下げ、手間を増やす。このトレードオフこそ、シミュレーションで測るべきものだった。

この回で決まったこと

主指標は、看護師の負担の増減。搬送に費やしていた時間の削減から、ロボット対応に費やす時間の増加を引いた差。これとロボットの稼働率を同じ行に並べる。

基準点は2段。ロボット0台の状態と、ロボットあり・攪乱なしの状態。ただし前者は「看護師が全搬送を行う」ではない。看護補助者・SPD・既存の機械搬送がすでに担っている前提を含む形に組み直す必要がある。

出力は単一の数字ではなく、条件を振った比較表。既存設備の有無、フロア数、動線距離、夜間人員、ロボット台数。絶対値の予測はしない。

搬送物は薬剤・検体・文書のみ。配膳・リネン・廃棄物は人が押す台車として廊下に登場させる。攪乱は故障と停電の2種。停電時はその場で停止して発光する。復旧は人が管理者キーで判断し、この設計が有効なのは十数台まで。

崩れた前提を並べ直すと、こうなる。公的調査の数字を持ってくれば基準点が置けると思っていたが、測り方が搬送に向いていなかった。比較対象は人手ではなく既存の機械かもしれない。効果の一般的な数字は存在しない。改装費は高くなかった。

4つとも、調べる前は逆を信じていた。そして4つとも、実装に入る前に崩れた。コードを書いてから崩れていたら、書いたものを捨てることになっていた。

次は対象病院のプロファイルを組み直す。建物の新旧が判断材料でなくなった以上、絞り込みの基準は搬送量と夜間の人員体制になる。そこから病床規模を決め、フロア構成と人数と搬送量が芋づるで決まる。