ハコブくん 病院オペレーションのデジタルツイン Log#1 | まずはシステム全体設計から始める
薬剤搬送ロボット「ハコブくん」の開発を、あらためて動かし始める。以前は病院の廊下を走る自律移動と、看護師に反応して光る表情のプロトタイプまで作っていた。カプセルのエージェントが徘徊し、ロボットがそれを避け、発光と表情で意図を伝える。人とロボットが同じ空間にいるときの振る舞いを、見た目として組み上げた段階だった。
今回はそこから方向を変える。作りたいのは、見た目のリアルさではなく、病院の運用そのものをシミュレーションできる仕組みだ。医師や看護師、患者がそれぞれの業務を持って動き、そこにロボットを一台入れたら、何がどれだけ変わるのか。搬送の往復が減るのか、浮いた時間はどれくらいか、経営的にはどういう効果になるのか。そこまで含めて数値で見られるものを目指す。
このシリーズの第1回は、コードを一行も書かない。まずシステムそのものの全体設計をする回にする。何を作るのか、何は作らないのか。そこを決めないまま手を動かすと、大きなスコープに溺れるのが目に見えている。だからこの記事は、設計の結論だけでなく、その結論にたどり着くまでに何を検討して何を捨てたのか、考えが動いた過程を残す。
最初の取り違え ── 「現実的」が指していたもの
出発点で、言葉の解釈が何度かずれた。それを直していく過程自体が、この設計の骨格を決めたので順に書く。
最初に「デジタルツインシミュレーションを現実的なシミュレーションに近づけたい」と考えたとき、真っ先に浮かんだのは忠実度の話だった。カプセルではなく質量と慣性を持った機体、理想化されたセンサーではなく死角やノイズを持つセンサー、そういう物理的なリアルさを上げていく方向。実機に載せ替えられる構造にするという話。
だがこれは違った。「現実的に近づける」で意図していたのは、シミュレーションを実機に近づけることではなく、シミュレーションを現実の病院運用に近づけることだった。real が指すのは実機ではなく、現実の病院で今まさに起きているオペレーションのほうだ。照合する相手は機体のスペックではなく、病院という現場で人がどう動き、何に時間を使っているか、である。
ここが定まると、作るものの正体が変わる。これは移動ロボットの見た目や振る舞いのデジタルツインではなく、病院オペレーションのデジタルツインだ。病院を「タスクが発生し、人という資源がそれを消費する系」として捉える。薬剤搬送・処置・巡回・緊急対応といったタスクが時間帯ごとに発生し、医師や看護師がそれを処理する。処理には移動と時間が伴い、それが負担やコストになる。そこにロボットをもう一種類の資源として入れると、搬送タスクが肩代わりされ、人の時間が空く。その差分を時間・距離・コストに変換して見せる。それがこのシミュレーションだ。
実データは取れない、だから可変にする
次に引っかかったのが、「現実の病院はこうだ」という数字をどこから取るか、だった。実際の病院の業務動線、搬送回数、所要時間。これらにアクセスできなければ、シミュレーションはただの数字遊びになりかねない。一度はこの「実データの出所」がシリーズの背骨だと考えた。
しかし実際の病院データを取得するのは困難だ。そこで方針を切り替えた。実データを当てにいくのをやめて、状況設定を自分で選べる可変シミュレーションにする。
この切り替えで、いちばんやっかいな問題が解けた。前提が甘いと数字が信用できない、という問題は、前提をユーザー自身が明示的に置く構造にした瞬間に消える。これは「現実の病院はこうだ」と主張する予測ツールではなく、「あなたが置いた前提のもとでは、こうなる」を見せる探索ツールになる。前提が隠れた主張ではなく、前提そのものが操作画面になる。だから正直で、防御可能だ。現実を当てにいくのではなく、置いた条件の帰結を可視化して比較させる。これがこのシミュレーションの性格になった。
適用範囲を最初から病院に限定しない
もう一つ、最初に決めておかないと後から接げないものがあった。適用範囲だ。
このシステムは、設計しだいで他の環境にも適用できるものにしたい。病院で成立した仕組みが、工場でも倉庫でも通じる形。ここを後付けにすると、環境を差し替えるたびに作り直しになる。
だから構造を二つに分ける。計算のエンジン ── 「タスクが誰かの時間と移動を消費する」「ロボットを入れるとどれだけ肩代わりされるか」を計算する部分 ── は、環境に依存させない。病院でも工場でも、この構造は同じだからだ。環境ごとに変わるのは、空間・役割・タスク種別・発生率といったシナリオの設定だけ。これは設定データであって、コードではない。病院を工場に差し替えるのは「別のシナリオ設定を読み込む」ことであって、「作り直す」ことではない。病院は最初から、シナリオの一例として作る。ここを外すと汎用化は後から接げない。
数字が主、動きは後
「実際の動きのシミュレーション」と「効果のダッシュボード」は、どちらが大事かという話ではない。見る相手が違うだけで、両方いる。経営を判断する側は数字を見るし、現場や発信の受け手は動きを見る。優劣ではなく役割の違いだ。
ただし作る順番はある。まず数字が主のシミュレーションで、複数のパターンを回す。夜勤の看護師を2人にするか3人にするか、ロボットを1台にするか2台にするか。そうやって条件を変えた結果を並べて、良さそうなサンプルを選ぶ。そのうえで、選んだ良さそうなサンプルだけを、動きが主のシミュレーションに起こす。
この順番には理由がある。動きは作るのが重い。全パターンを動かすのは無駄で、数字で当たりをつけてから、見せる価値のあるものだけ動かせばいい。数字が動きの絞り込み器になる。そして両者は別物ではなく、同じシナリオ設定を共有する関係にする。数字シミュレーションで置いた前提を、そのまま動きシミュレーションが受け取れる構造にしておけば、選んだサンプルが素直に流れていく。
何を作り、何を作らないか
方向が定まったところで、要素を一つずつ並べて、必要・不要を仕分けた。ここが全体設計の実体になる。
数字が主のシミュレーションを動かすのに要るものは、次のとおり。
まず空間。簡単な間取りを置いて、そこから距離を自動で算出する。拠点間の距離を手で入力する方式ではなく、部屋・廊下・拠点（ナースステーション、薬剤庫、病室）をノードとして置き、つながりと距離を持つグラフとして扱う。この方式なら、間取りを差し替えるだけで距離が出る。病院を工場に替えるとき、全部の距離を打ち直す必要がない。間取りに拠点座標を持たせておけば、後段の動きシミュレーションが同じ間取りを舞台として受け取れる。空間の面でも数字と動きがつながる。
次にシナリオ設定。ユーザーが動かせるつまみだ。空間（廊下の長さ・部屋数・拠点の位置）、人員（役割ごとの人数・シフト）、タスク（時間帯ごとの発生率）、ロボット（台数・速度・積載）。この四つのグループが「状況設定を自分で選べる」の実体になる。
そしてエンジン、導入前後の差分算出、パターン間を並べて比較できるダッシュボード、どの設定でどの結果が出たかを残す前提の記録、それらを操作する画面と間取りを置くエディタ。以上が数字シミュレーションの必要物になる。
逆に、数字シミュレーションに要らないものもはっきりした。3Dの精密な描画、人やロボットのアニメーション、経路計画や障害物回避の精密な再現、衝突判定、機体の物理、センサーのモデル化、実空間のスキャン。これらは動きシミュレーションの側に寄るか、そもそも今回は不要だ。数字シミュレーションは、平面の間取りと数値計算だけで完結する。だから軽く作れる。
この「要らないものが確定した」ことが、今回いちばんの収穫だった。何を作らないかが決まると、何を作るかの輪郭が固まる。
効果として何を数えるか
ダッシュボードに出す指標は、導入前と後の比較が土台になる。これがなければ「効果」というものが存在しない。
出すのは、時間（浮いた時間・搬送に費やした時間）、距離（移動距離の削減）、コスト（時間を金額に換算したもの）。この三つを主軸にする。そして必ず「この前提のもとで」を画面に残す。実データではなくユーザーが置いた前提から出た数字だから、その但し書きが正直さの担保になる。
今回の手順では、もう一つ格上げした要素がある。パターン間の比較だ。単発の結果を表示するだけでなく、複数の条件を並べて見比べられるようにする。「夜勤2人と3人」「ロボット1台と2台」を横に並べて、どれが効くかを見る。ここで、動きに起こす価値のあるサンプルを選ぶことになる。だからダッシュボードは、単発表示ではなく、パターンを並べて選べるものになる。
参照する実機 ── FlashBot
ロボットのスペックには、実在する機体を参照先に置いた。PUDU Robotics の製品群だ。医療を含む多くの導入事例を持ち、完成度の高いロボット企業のひとつだと考えている。
当初は重量物搬送や汎用配膳の機種を見ていたが、ハコブくんにいちばん近いのは FlashBot だった。ビル内配送のロボットで、要件と照らすと設計思想が重なる。廊下や部屋への配達、認証によるロック、エレベーター連携。ハコブくんが想定してきた「病院の廊下を薬剤トレーを載せて走り、患者を怖がらせず、セキュリティを保つ」という姿に、実在の対応物として最も近い。
公式の製品概要から、確定したスペックを参照値として押さえた。寸法は538×534×1052mm、重量60kg、積載は10kg/層、コンパートメントは2〜4分割で調整可能。稼働時間9時間・充電時間4時間。ナビゲーションはVSLAM＋Lidar SLAM。走行速度は0.5〜1.2m/sで調整可能。最小通路幅60cm。認証はパスワード・電話番号・NFCに対応し、エレベーターとはクラウド連携する。複数台のスケジューリングにも対応する。
これらの数値は、シミュレーションのつまみの初期値になる。速度が0.5〜1.2m/sで可変だという事実は、そのまま速度つまみのレンジの根拠になる。10kg×2〜4層という積載は、コンパートメント数を変えられる＝1回で何タスク運べるかのつまみに直結する。9時間稼働・4時間充電は、1日の実働時間を出す根拠になる。実在機の値なので、「それっぽい数字」ではなく根拠を示せる。
ただし、可変シミュレーションである以上、これらの数値は正解ではなくプリセットの初期値・現実的なレンジの根拠として使う。ユーザーが動かせるつまみに、実在機の値を初期値として置いておく、という役回りだ。
ひとつ、FlashBotと並べたときにはっきりしたことがある。FlashBotは顔を持たない。天面のリング状の光と、角のない佇まいだけで存在を伝える設計だ。一方ハコブくんは、顔のディスプレイ（表情）と発光を持たせてきた。実在の高完成度機が「光と形だけで信頼を作る」ところに、ハコブくんは「表情」という一段踏み込んだ層を乗せている。実機と比較したことで、逆にこちらの固有の価値 ── 親しみと信頼を表情で設計する部分 ── が際立った。
この回で決まったこと
第1回として、シリーズの入口はここまで固まった。
主題は、病院運用の可変シミュレーション。状況設定を自分で置き、ロボット導入の効果を数値で見る探索ツール。背骨は、環境に依存しないエンジンと、差し替え可能なシナリオ設定に分けること。手順は、数字が主のシミュレーションで複数パターンを回し、良さそうなものを動きが主のシミュレーションに起こすこと。空間は、簡単な間取りから距離を自動算出すること。参照する実機はFlashBotで、ハコブくんはそこに表情という層を足した存在として位置づける。
コードは書いていない。だが、何を作り何を作らないかが決まった。次は、費用対効果をどこまで作り込むか ── 浮いた時間を主指標にとどめるか、投資回収まで出すか ── を決め、FlashBotのスペックを反映したつまみの一覧を具体化していく。
作る前に、作らないものを決める。今回はそれをやった回だった。
