サービスロボット導入シミュレーション Log#40 | 病院の搬送ロボット、外来の廊下を避けて問題を4割減らす

この記事の素材(コード・ログ・データ 10ファイル・まとめてダウンロードあり)
AIで読む ChatGPT・Claude などで、この記事に質問できます

病院で検体を運ぶ搬送ロボットは、速さを上げるより、外来の混む廊下を通らない道にする方が、廊下で起きる問題を減らせました。仮の病院を Unity の3Dで再現し、7:30〜16:30 の1日を回したシミュレーションで、内科外来から検査部への検体の道を「外来の大廊下」から「外来の奥の職員通路(裏口の道)」に変えると、ロボットが走っている間の問題(急に止まる・人とひやりとする・人によけさせる・立ち往生・車いすの前を横切る)は1日111回から68回に約4割減り、積む所で待っている間に人とひやりとする回数は約2,600回から約190回になりました。 代わりに、検体が届くまでの平均は12.2分から14.0分へ約2分延びます(ロボット1台・0.6m/秒・乱数の種10個の中央値。実物の病院で測った数字ではありません)。

この回で分かったことと、次にできるようになったことです。

  • 病院が搬送ロボットの速さを決めるときの材料が出た。止まるまでの距離が速さで延びる作りを入れると、0.6m/秒までは速いほど1往復あたりの問題は減るが、0.8m/秒では人に止まりきれない回数が増え始めた
  • 「どこで待たせるか」「どの道を通すか」の方が速さより効くと分かった。外来の混む時間だけ裏口に切り替える案は、8時と11時に表と裏口の間を移る道で問題が増え、裏口だけの方が少なかった
  • 配膳ロボットで作ったやり方(サイトの試算を正にし、Unity で廊下の出来事を数える)を、病院の搬送にそのまま持ち出せた。慈恵医大柏病院の公表値(運行の時間帯・1日の利用回数・削減時間)と答え合わせをしながら、仮置きの値を動かして結果がどう変わるかを見る形にした

病院を題材にしたのは、配膳の次にサービスロボットが入りそうな現場の中で、病院の院内搬送がいちばん数字がそろっているからです。東京慈恵会医科大学附属柏病院は、KEENON の搬送ロボット W3 1台で、採血管などの検体と当日分の抗がん剤を同じ階の3ルートで運び、ルートごとの時間帯と、1日あたりの利用回数(内科外来→中央検査室が4〜9回、薬剤部→外来化学療法室が5〜15回)と、1日66〜172分の削減時間を発表しています(ロボスタ 2026-08-04、DFA Robotics の導入事例)。ただ、ロボットが廊下で何回止まり、人と何回ぶつかりそうになったかは、どこにも出ていません。病院が速さを上げてよいか、どこを走らせるかを決めるには、そこが要ります。

困ったのは、ファミレスのときと違って、病院には自分の働いた実感がないことでした。だから病院のフロアの形はコードで一から作り、公開値で埋まらない値(依頼の数・受け取る人が来るまでの時間・止まる割合)は仮置きにして、動かしたときに結果がどう変わるかを見る形にしました。廊下を歩く人の内訳(車いす1割・杖の人1割)も根拠のない仮置きで、実際の外来より多めに置いています。止まりきれなかった相手の多くが車いすだったので、この記事の回数は多めに出ていると見てください。内訳は次の回で調べて直します。

やったことなぜ結果
仮の病院 h0(外来の階・120m×60m)をコードで作り、SimPy で1日の試算 h0〜h1 を回した
慈恵柏の3ルートを、同じ階・ロボット1台で再現するため
h0 で人の搬送の時間は1日68分減(発表の幅の下の方)。青の依頼を1時間1.5件に下げた h1 で、便の数が発表の4〜9回に入った。1便あたりの減りは発表の半分以下で、道の長さか人の手間のどちらかが足りない
Unity で青のルートの廊下を建て、速さ4つ×混み具合2つで問題を数えた(依頼127)
病院が知りたい「速くしたら何がどれくらい起きるか」は SimPy では数えられないため
速いほど1往復あたりの問題は減った。ただしロボットは速さに関係なく同じ所で止まっていた
速さで止まるまでの距離が変わる作りを入れ、積む所を部屋の中と比べた(依頼132)
速さの悪い面を表すため
0.8m/秒で止まりきれない回数が増え始めた。部屋の中に入れても問題は減らなかった
外来の奥に職員通路を足した h0b を作り、裏口の道と比べた(依頼134)
問題の97%が、積む所から縦廊下の角までの大廊下に集まっていたため
混んでいる時間は問題がほぼ半分、止まりきれないのは5分の1。空いている時間は道が長い分だけ多い
試算 h2 に道の決め方を足し、試算の便の時刻表で Unity の1日を回した(依頼136・138)
時間帯で道を切り替える案を確かめるため
切り替えは移る道で増えた。1日を通すと裏口だけが一番少なく、届くのは約2分遅い

配膳ロボットを自分の店に入れたらどうなるかは、このシリーズの試算をもとにした別のページで試せます。病院の搬送も、試算が固まったら同じ形にしていきます。

店の立体図(席・キッチン・配膳ロボットの通り道)導入前シミュレーション配膳ロボットを、導入前に自分の店舗でシミュレーション店舗の図面と人数から、何人で回るか・どこで止まるか・月いくらかかるかを出します

作業ログ ― 仮の病院 h0 と、慈恵柏の公表値でそろえた前提の表

この記事のコード・ログ・データは、1ファイルずつ下に置いています。全文はリンク先にあります。

ファイルの一覧(10本)

01_assumptions.json_tools_hospital_sim_assumptions.json ― 前提の表 assumptions.json / tools/hospital_sim/assumptions.json(この記事を書いた時点の全文)・17,181字

02_assumptions.json_tools_hospital_layouts_make_hospital.py.txt ― 前提の表 assumptions.json / tools/hospital_layouts/make_hospital.py(仮の病院 h0・h0b を作るコード)・11,158字

03_1_tools_hospital_sim_hospital_sim.py.txt ― 慈恵柏の発表とのずれ:便の数と、1便あたりの減り / tools/hospital_sim/hospital_sim.py(試算 h0〜h2 の全文)・16,478字

04_sec02.txt ― 慈恵柏の発表とのずれ:便の数と、1便あたりの減り / 試算 h2 の結果(summary_h2.txt の全文)・7,212字

05_5_tools_hospital_sim_export_unity_params.py.txt ― 数える問題5つと、回す条件 / tools/hospital_sim/export_unity_params.py(Unity が読む条件を書き出すコード)・4,715字

06_sec03.md ― 依頼127:速いほど1往復あたりの問題は減った。ただし止まり方が速さで変わっていなかった / 依頼127 の報告(依頼箱の結果の全文)・3,486字

07_sec03.md ― 依頼132:止まるまでの距離を速さで変えると、0.8m/秒で止まりきれない回数が増え始めた / 依頼132 の報告(依頼箱の結果の全文)・3,113字

08_sec04.md ― 依頼134:混んでいる時間は、裏口の道で問題がほぼ半分 / 依頼134 の依頼文(裏口の道を建てて大廊下を通らない形と比べる)・3,335字

09_sec04.md ― 依頼134:混んでいる時間は、裏口の道で問題がほぼ半分 / 依頼134 の報告(依頼箱の結果の全文)・3,085字

10_sec04.json ― 依頼136・138:時間で切り替える案は、移る道で増えた / 試算 h2 が書き出した Unity の条件(hospital-unity-params.json の全文)・45,228字

ここから下は作業ログです。数字は、特に断りがなければシミュレーションの値です。効果の欄は、測った値か見込みかを書いています。

搬送ロボット KEENON W3 と、病院の院内搬送

KEENON の BUTLERBOT W3 は、鍵のかかる収納を持った屋内の搬送ロボットです。病院では、看護補助者(看護師の仕事を手伝うスタッフ)が歩いて運んでいた採血管・尿などの検体や薬剤を、決まった区間で運びます。このシリーズで使う値は次のとおりです。

言葉この記事での意味値と出典
最高速度W3 が出せる速さの上限0.8m/秒(公式)
収納
別々に開けられる箱の数。1回の走行で最大4か所に届けられる
4室(公式・慈恵柏の実証)
通れる最小の幅ロボットが通れる通路の幅0.7m(公式)
電池
1時間に3便・1便5分の条件で動ける時間
12時間(公式)。充電は6.5時間
便・利用回数
ロボットが積む所を出て届け先へ行く1回
慈恵柏の内科ルート1日4〜9回・薬剤ルート1日5〜15回

このプロジェクトでは、病院が速さや道を決めるときの材料を、公開値と仮置きの値を分けた前提の表から出します。

SimPy は、時間・順番・数を数える道具

SimPy は、Python で「何が、いつ、どの順番で起きるか」を回す道具です。依頼が出る・ロボットが待つ・走る・届く、を時刻つきで並べ、1日の待ち時間や便の数を数えます。廊下で人とぶつかりそうになる、のような空間の出来事は数えられないので、そこは Unity で数えます(配膳のときと同じ役割分担)。

仮の病院 h0 は、外来の階を120m×60m で起こした

部屋は通れない箱、廊下だけが床です。廊下の幅は医療法施行規則の一般の中廊下(内法2.1m以上)に合わせ、待合に面する外来の大廊下だけを4.0m(仮置き)にしました(札幌市 病院の構造設備基準)。3ルートは慈恵柏と同じ組み合わせで、距離は廊下の中心線の上で測ります。緑(救急室→検査部)21m、青(内科外来→検査部)86m、赤(薬剤部→外来化学療法室)109m です。

仮の病院 h0 の平面図。外来の大廊下・職員の中廊下と、緑・青・赤の3ルート

慈恵柏の3ルートは運行の時間帯が重なっていません(緑 7:30〜8:00、青 8:00〜11:00・13:00〜14:00・15:00〜16:30、赤 11:00〜13:00・14:00〜15:00)。1台で3ルートを持てるように時間割が組まれていると読めます。

前提の表 assumptions.json

値ごとに、根拠の種類(公開事例・仮置き・図面から・決まり・設定)と出典を持たせています。決まりの行は、この回でエイイチと決めたものです。出発は満杯(4室)か、いちばん古い依頼が10分待ったら。至急はすぐ。届くまでの平均が15分以上、または至急が5分以上で「間に合わない」の印。山場は外来の8〜11時。

検体1つが届くまでの流れと、どこにどの根拠の値が入るか

tools/hospital_sim/assumptions.json(この記事を書いた時点の全文)

{
 "about": "サービスロボット導入シミュレーション 病院の搬送ロボット(検体・薬剤、同じ階)の前提の表。試算 hospital_sim.py はこの表を読んで回す。値を直すときは、ここを直して git に残す",
 "model": "h2",
 "layout": "../hospital_layouts/hospital_h0.json",
 "basis_kinds": {
  "仮置き": "まだ根拠がない仮の値。幅(range)を動かして結果がどう変わるかを見る",
  "公開事例": "メーカーの仕様・導入事例など、公開されている値",
  "図面から": "仮の病院のフロアの形(hospital_layouts)から決まる値",
別のタブで開く保存

tools/hospital_layouts/make_hospital.py(仮の病院 h0・h0b を作るコード)

# -*- coding: utf-8 -*-
"""仮の病院のフロアの形(同じ階・案 h0)を作る。

サービスロボット導入シミュレーション 病院の搬送ロボット(検体・薬剤)用。
実在の病院ではなく、外来・検査部・薬剤部・外来化学療法室・救急室の
典型的な並びをコードで一から起こしたもの(2026-11-09 エイイチと決めた)。

決まり
別のタブで開く保存

作業ログ ― SimPy の試算 h0〜h2 と、慈恵柏の発表とのずれ

試算 h0:ロボット1台で、人の搬送の時間は1日103分から35分に

青の依頼を1時間8件と仮置きした最初の版です。ロボット1台で人が搬送に使う時間は1日68分減り、慈恵柏の発表(66〜172分)の下の方に入りました。2台にしても76分減でほとんど変わりません。届くまでの時間は、人が歩くより少し延びます(青で8.1分→10.7分)。

試算 h0。届くまでの平均・至急・人の時間の減り

至急の決まりは、空いているロボットがいればロボットが運ぶ形のままにしました。2台だと赤の至急が5.5分になり5分の線を超えますが、赤の109mをロボットが走るためで、決まりは変えないことにしました。

慈恵柏の発表とのずれ:便の数と、1便あたりの減り

発表の表(2026年8月4日)で、1日の利用回数を原文で確かめました。青の便は試算で1日18.8回、発表は4〜9回。1便あたりの人の時間の減りは、試算で青2.2分・赤3.0分、発表を割ると5〜9分です。

試算 h0 と慈恵柏の発表のずれ。便の数と1便あたりの減り
  • ねらい:便の数を発表に合わせ、残るずれがどこから来るかを分ける
  • 変わったこと:h1 で青の依頼を1時間8件から1.5件に下げ、便の数は1日6.4回になった(依頼1件=送る側がロボットに1回で預けるひとまとまり)
  • 見込める効果:1便あたりの減りのずれは残る。道を2倍にしても(案2)、人が運ぶときの歩く以外の手間を1回3〜4分足しても(案3)発表の幅に届く。違いは、案2だと検体が届くのも遅くなり(青12.7分→15.6分)、案3では変わらないこと。どちらが本当かは病院の現場でしか分からないので、両方を並べたままにした
案2(道を長く)と案3(人の手間を足す)の比べ

ロボットの速さは平均0.5m/秒の仮置きです。0.8m/秒(最高速度)なら、道が2倍でも青は13.3分で15分の内側に戻ります。速さは機械の数字であると同時に、病院がロボットをどれだけ信じて走らせるかの数字でもあります。だから病院が知りたいのは、速くしたときにどんな問題がどんな頻度で起きるかで、それを Unity で数えることにしました。

tools/hospital_sim/hospital_sim.py(試算 h0〜h2 の全文)

# -*- coding: utf-8 -*-
"""サービスロボット導入シミュレーション 病院の搬送ロボット(検体・薬剤、同じ階)試算

版の記録
  h0(2026-11-09):最初の版
  h2(2026-11-09):青の道の決め方(route_plan:廊下だけ/裏口だけ/時間で切替)を足した。時間で切替は
     back_door_hours(外来の混む 8〜11時)の間だけロボットが裏口から積む(Unity 依頼134 で、混む時間は裏口で
     問題がほぼ半分、空いている時間は今の道の方が少なかったため)。人が歩くときはいつも表の短い道。
別のタブで開く保存

試算 h2 の結果(summary_h2.txt の全文)

04_sec02.txt7,212字・75行・text
試算 h2(仮の病院 h0(外来の階))乱数の種 10 個の平均

■ 標準の条件
ロボット0台  人が搬送に使った時間 52.8分/日(0台より 0.0分減)
  緑 依頼3件 届くまで 平均5.7分 90%4.7分 最大9.7分 至急0.7分 山場-分 便0.0 人が歩いた1.8回 人の時間1.9分
  青 依頼8件 届くまで 平均9.7分 90%11.8分 最大11.8分 至急1.8分 山場9.1分 便0.0 人が歩いた6.5回 人の時間20.8分
  赤 依頼13件 届くまで 平均9.0分 90%12.2分 最大12.2分 至急2.2分 山場-分 便0.0 人が歩いた7.6回 人の時間30.1分
ロボット1台  人が搬送に使った時間 14.5分/日(0台より 38.3分減)  ロボットが走った 100分・2.92km
別のタブで開く保存

作業ログ ― Unity で病院の廊下を建て、速さごとの問題を数える

数える問題5つと、回す条件

数える問題はエイイチと決めました。1 急に止まった(走っていて1秒以内に止まった)、2 ひやり(人とロボットの外形が0.3m未満)、3 人がよけさせられた(2m以内で人が止まるか向きを変えた)、4 立ち往生(30秒以上動けず人が動かしに行った)、5 車いす・杖の人・ストレッチャーの進む先1.5m以内を横切った。速さは0.4・0.5・0.6・0.8m/秒、大廊下に同時にいる人は空いている20人・混んでいる60人(仮置き)です。Unity は値を自分で決めず、サイトから書き出した hospital-unity-params.json を読みます。

tools/hospital_sim/export_unity_params.py(Unity が読む条件を書き出すコード)

# -*- coding: utf-8 -*-
"""病院の搬送ロボットの Unity が読む条件 hospital-unity-params.json を、前提の表(assumptions.json)とフロアの形から書き出す。

Unity は値を自分で決めず、このファイルを読む(配膳の serving-robot-params.json と同じ考え方。正はサイト側)。
使い方:python3 export_unity_params.py
"""
import hashlib
import json
別のタブで開く保存

依頼127:速いほど1往復あたりの問題は減った。ただし止まり方が速さで変わっていなかった

混んでいるとき、ひやりは0.4m/秒で1往復19.9回、0.8m/秒で10.9回。廊下にいる時間が短くなるからです。1日の便の数は依頼の数で決まって速さでは変わらないので、1日あたりも減ることになります。ただ、Unity のロボットは速さに関係なく同じ所で止まっていて、速い方が安全とはまだ言えませんでした。問題の97%は、積む所から縦廊下の角までの約12mに集まっていました。

【画像】LOG477_06_u127_speed.png 依頼127。速さごとの1往復あたりの問題 【画像】LOG477_07_hotspots127.png 依頼127。問題が起きた場所(積む所から縦廊下の角に集まる)

依頼127 の依頼文(病院の廊下を建てて速さごとに問題を数える)

---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 600
---
# 依頼127:病院の廊下(青のルート)を建て、搬送ロボットの速さごとに廊下で起きる問題を数える

サービスロボット導入シミュレーションの病院編の最初の Unity の依頼。サイトの試算(SimPy)では答えられない「ロボットを速くしたら、どんな問題がどんな頻度で起きるか」を Unity で数える。病院はこの表を見て、自分で速さを決められるようにしたい(2026-11-09 エイイチと決めた)。

**配膳の場面・配膳の実行ファイル・配膳の台帳には触らない。** 病院は別の場面(例 Assets/ServiceSim/Hospital/)として作る。配膳と共通の部品(ロボットの道探し・よけ方・センサーで止まる・人のよけ方)は、中身を変えずに使ってよい。共通の部品を直さないと作れないときは、直さずに止めて報告する。
**エイイチは見ていない。人に聞かないと進めない所に当たったら、その項目は止めて報告に書き、ほかは続ける。夜の間も続けてよい。**

## 正(読むもの)
- 条件:p2m-site main の `tools/hospital_sim/hospital-unity-params.json`(md5 9887bf36e0384e0b3d044840c8d94f54)。値を Unity で決めない。違う md5 なら回さずに報告して終わる
- フロアの形:p2m-site main の `tools/hospital_layouts/hospital_h0.json`(params の layout.md5 と一致すること)。部屋は通れない箱、廊下(corridors の rect)が床。単位 m、x 右・y 奥 → Unity の X・Z
- 範囲:params の route(青のルート)の道の上と、外来の大廊下(x0〜70 の人の多い区間)。そのほかは建てなくてよい

## 始める前に確かめること(違えば回さずに報告して終わる)
1. 作業場所に保留がない(配膳の依頼126 の後の状態)。Unity・night_runner・rec_runner が動いていない。KIOXIA がマウント済み
2. 上の2つのファイルの md5

## 1. 病院の場面を作る
- 床と壁:hospital_h0.json から建てる。外来の大廊下 4.0m・職員の中廊下 2.1m・縦の廊下 2.1m(玄関の通りは 8.0m)
- ロボット:W3 の大きさ(params の robot.size_m)。積む所(内科外来の処置室)と届け先(検査部の検体受付)を往復し続ける。往復の間の止まり(積む・受け取りを待つ)は入れない(廊下で起きることだけを数えるため)。速さは params の speeds の1つを引数で選ぶ。センサーで止まる・よける・道探しは配膳の標準と同じ
- 人:外来の大廊下に params の people.crowd の人数を保つ(出入りしても数が一定になるように)。内訳は people.mix。歩く速さ・止まり方・よけ方は Unity だけの値として決めてよい(報告に一覧で書く)。目安:歩く患者・付き添い 1.0〜1.3m/秒、杖の人 0.6m/秒、車いす 0.8m/秒、スタッフ 1.3m/秒。患者の一部は待合の前で立ち止まる。スタッフはロボットをよける(配膳と同じ)。杖の人・車いすは自分からは大きくよけない
- ストレッチャー:params の stretcher_per_h の回数、職員の中廊下と縦の廊下を通す(押す人1人を含めた大きさ)
- 瞬間移動はさせない。同じ条件・同じ種なら同じ結果になるようにする

## 2. 数えるもの(params の count_rules が正。線の値を変えない)
1回の往復(片道ずつ)ごとに数える。
1. 急に止まった:走っている状態から sudden_stop 秒以内に止まった回数
2. ひやり:人(車いす・ストレッチャーを含む)とロボットの外形どうしが near_miss_m 未満になった回数(同じ相手と離れずに続いている間は1回)。一番近づいた距離も残す
3. 人がよけさせられた:ロボットから yield_m 以内で、人が止まるか向きを変えた回数
4. 立ち往生:stuck_s 秒以上動けなかった回数(解けるまでの秒も。人が動かしに行く作りは配膳と同じ)
5. 車いす・杖の人・ストレッチャーの進む先 cross_front_m 以内をロボットが横切った回数
あわせて、片道にかかった秒・平均の速さ(実際に出ていた速さ)を残す。

## 3. 回す
- 確かめ(違えば 4 は回さない):0.5m/秒・混んでいる・種0 を2回回して一致すること、瞬間移動 0。0.8m/秒・空いている・種0 で往復が最後まで回ること
- 本番:速さ4つ × 混み具合2つ × 種0〜9 = 80回。1回は店の時間で60分(画面なし・同時4本まで)
- 出力:/Volumes/KIOXIA/r2r2r-data/service_sim/unity/hospital/20261109_speed127/(回ごとの往復の記録・数えた問題の一覧(いつ・どこ x,z・相手の種類)・条件ごとのまとめ)。配膳の台帳には書かない。この依頼の索引 CSV を同じフォルダに置く

## 4. 録画(3 の本番が通れば撮る)
- 混んでいる・種0 で、0.5m/秒 と 0.8m/秒 を2分ずつ、真上から外来の大廊下の人の多い区間を撮り、左右に並べた動画を1本。数えた問題が起きた所に印(色は問題の種類ごと)を出す。置き場所は 3 と同じフォルダ

## 止める線
瞬間移動が1回でも出たとき、または同じ種の2回が違ったとき。止めたら報告に書き、ほかの項目は続ける。

## 報告
claude_code_reports/20261109_hospital_127.txt に:始める前の確かめ、1 で作ったもの(ファイルと場所・Unity だけの値の一覧)、確かめの結果、
表(速さ×混み具合ごと、種10個の中央値と最小・最大):往復の数・片道の秒・実際の平均の速さ・1〜5 の問題の数(1往復あたり)・ひやりの一番近い距離、
問題が多かった場所の上から3つ(どこで・何と・なぜ)と上から見た図の置き場所、4 の動画の名前と長さ、check-in の番号、決めてほしいこと(直し方の候補は作らない)。
**報告の最後の1行は必ず次のどれか**:「判定:合格」/「判定:止めた(決めてほしいことあり)」/「判定:失敗」

依頼127 の報告(依頼箱の結果の全文)

06_sec03.md3,486字・68行・markdown
# 結果:20261109_127_病院の廊下を建てて搬送ロボットの速さごとに起きる問題を数える

- 状態:完了
- 始めた時刻:2026-11-09 11:32
- 終わった時刻:2026-11-09 12:48(76分)
- 作業フォルダ:/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき:作業フォルダで `claude --resume 1b38a38e-a86b-410b-93d7-4ac7c782ec37`
- 止められた操作:1件(いちばん下に一覧)
別のタブで開く保存

依頼132:止まるまでの距離を速さで変えると、0.8m/秒で止まりきれない回数が増え始めた

止まるまでの距離=速さ×0.2秒+速さ²÷(2×0.5m/秒²)(どちらも仮置き)。0.4m/秒で約0.24m、0.8m/秒で約0.80m です。止まりきれなかった回数(動いたまま人と重なった)は、廊下・混んでいるとき、1往復あたり0.6m/秒の0.92回が一番少なく、0.8m/秒で1.12回に増えました。積む所を部屋の中に入れても、問題は扉の口に移っただけで減りませんでした。

依頼132。止まりきれなかった・速いままのひやり・急に止まった

依頼132 の依頼文(速さで変わる止まり方を入れ、積む所を部屋の中と比べる)

---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 480
---
# 依頼132:病院の搬送ロボットに「速さで変わる止まり方」を入れ、積む所を廊下と部屋の中で比べる

依頼127 の報告(claude_code_reports/20261109_hospital_127.txt)を読んで、エイイチと決めたこと(2026-11-09):
- 依頼127 では速いほど1往復あたりの問題が減ったが、ロボットが速さに関係なく同じ所で止まっていたので、速さの悪い面(止まりきれない・速いまま近づく)が表れていなかった。これを入れる
- 問題の97%が積む所から縦廊下の角までの約12mに集まっていた。積む所を部屋の中に入れた形と比べる
- 決めてほしいことへの答え:1 数えるときも動くときと同じ丸(直径0.549m)で見る/2 地図を Unity で床から作るのはこのままでよい/3 壁ぞいを走るのはこのままでよい/4 積む所は下の 1-2 のとおり両方を回す/5 数え方の細かい線(設定の速さの半分以上・30度・45〜135度・よけた理由を分けない)はこのままでよい/6 人・ストレッチャーの値、扉の置き方、ストレッチャーの通り道、録画の範囲はこのままでよい

**配膳の場面・配膳の実行ファイル・配膳の台帳、配膳と共通の部品には触らない。** 止まり方は病院の側(Assets/ServiceSim/Hospital/ の中)で、共通の部品の外から入れる。共通の部品を直さないと入れられないときは、直さずに止めて報告する。
**エイイチは見ていない。人に聞かないと進めない所に当たったら、その項目は止めて報告に書き、ほかは続ける。夜の間も続けてよい。**

## 正(読むもの)
- 条件:p2m-site main の `tools/hospital_sim/hospital-unity-params.json`(md5 0507fd8d5cdf2b3ff8bcb010a4f48493)。依頼127 の写し(9887bf36…)との違いは braking・loading_point・loading_point_what・count_shape・near_miss_speed_mps の5項目だけのはず。ほかにも違いがあれば回さずに報告して終わる
- フロアの形:依頼127 と同じ hospital_h0.json(md5 が params の layout.md5 と一致すること)

## 始める前に確かめること(違えば回さずに報告して終わる)
1. 作業場所に保留がない(cs:111 のあと)。Unity・回し係が動いていない。KIOXIA がマウント済み
2. 上の md5 と、違いが5項目だけであること

## 1. 作りの直し(病院の側だけ)
1. 速さで変わる止まり方(params の braking が正)
   - 止まるまでの距離=速さ×react_s+速さ²÷(2×decel_mps2)。ロボットは前方の「止まるまでの距離+notice_margin_m」の中に人や物が入ったら、react_s のあと decel_mps2 で減速して止まる(速いほど遠くで気づく)
   - 気づく距離より内側に急に入られたとき(横から出てきた人など)は、止まりきれずに近づくことがある。そのまま起きるようにする(無理に止めない・瞬間移動しない)
   - 加速は今のままでよい(使った値を報告に書く)
2. 積む所(params の loading_point):「廊下」=依頼127 と同じ(扉から廊下へ0.5m)、「部屋の中」=扉から処置室の中へ1.0m。引数で選べるようにする。届け先(検体受付)は今のまま
3. 数える形(params の count_shape):ひやりの距離は、動くときと同じ丸(直径0.549m)と相手の外形で測る
4. ひやりのそれぞれに、近づいたときのロボットの速さ(一番近づいた瞬間と、その1秒前の最大)を残す。near_miss_speed_mps 以上を「速いままのひやり」として分けて数える
5. 止まりきれなかった:ロボットが 0.1m/秒以上で動いているあいだに、丸と相手の外形が重なった(距離0未満)回数も分けて数える
- 引数がないときは、1〜5 を入れた形を既定にする。依頼127 の形(止まり方なし・長方形で数える)にも引数で戻せるようにする
- check-in(保留0)して、病院の実行ファイル(Builds/hospital132/)を作る。依頼127 の実行ファイルは残す

## 2. 確かめ(違えば 3 は回さない)
- 0.5m/秒・混んでいる・廊下・種0 を2回回して一致すること、瞬間移動0
- 0.8m/秒・空いている・部屋の中・種0 で往復が最後まで回ること
- 依頼127 の形に戻す引数で 0.5m/秒・混んでいる・種0 を回し、依頼127 の同じ回と、名前・時刻・cs・計算時間以外が一致すること(違ったら、どこが違うかを書く。止めない)

## 3. 回す
- 速さ4つ × 混み具合2つ × 積む所2つ × 種0〜9 = 160回。1回は店の時間で60分(画面なし・同時4本まで)
- 出力:/Volumes/KIOXIA/r2r2r-data/service_sim/unity/hospital/20261109_brake132/(依頼127 と同じ形の記録とまとめ・索引 CSV)。依頼127 のフォルダは変えない

## 4. 録画(3 が通れば撮る)
- 混んでいる・種0 で、0.4m/秒・廊下 と 0.8m/秒・廊下 を2分ずつ左右に並べた動画を1本、0.8m/秒・廊下 と 0.8m/秒・部屋の中 を2分ずつ並べた動画を1本。撮り方・印は依頼127 と同じ。速いままのひやりと止まりきれなかったには、ほかと違う目立つ印を出す

## 止める線
瞬間移動が1回でも出たとき、または同じ種の2回が違ったとき。止めたら報告に書き、ほかの項目は続ける。

## 報告
claude_code_reports/20261109_hospital_132.txt に:始める前の確かめ、1 の直し(どのファイルのどこ・加速の値)、2 の確かめ、
表(速さ×混み具合×積む所ごと、種10個の中央値と最小・最大):往復の数・片道の秒・実際の平均の速さ・1〜5 の問題の数(1往復あたり)・速いままのひやり(1往復あたり)・止まりきれなかった(1往復あたり)・ひやりのときのロボットの速さ(中央値と90%)・ひやりの一番近い距離、
依頼127 との並べ(廊下の形で、速さごとに 1〜5 の増え減り)、積む所を部屋の中にして問題がどこからどこへ移ったか(上から見た図)、4 の動画の名前と長さ、check-in の番号、決めてほしいこと(直し方の候補は作らない)。
**報告の最後の1行は必ず次のどれか**:「判定:合格」/「判定:止めた(決めてほしいことあり)」/「判定:失敗」

依頼132 の報告(依頼箱の結果の全文)

07_sec03.md3,113字・72行・markdown
# 結果:20261109_132_病院の搬送ロボットに速さで変わる止まり方を入れ積む所を部屋の中と比べる

- 状態:完了
- 始めた時刻:2026-11-09 13:27
- 終わった時刻:2026-11-09 14:12(45分)
- 作業フォルダ:/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき:作業フォルダで `claude --resume 42316e13-c5df-4924-b11e-337209a59784`
別のタブで開く保存

作業ログ ― 外来の廊下を通らない裏口の道と、1日を通した比べ

仮の病院 h0b:外来の奥に職員通路を足した

内科外来・ほかの外来の奥(北の壁ぞい)に職員通路2.1m を足し、青のルートは処置室の裏口から出ます。大廊下は人の少ない東の端(x99)で横切るだけになり、道は86mから153mに延びます。h0 の形のファイルは中身を変えていません。

仮の病院 h0b。外来の奥の職員通路と、裏口から出る青のルート

依頼134:混んでいる時間は、裏口の道で問題がほぼ半分

0.6m/秒のとき、1日あたりの問題は廊下の161回から裏口の81回、止まりきれなかったのは7.0回から1.4回です。空いている時間は、道が長い分と職員通路でスタッフとすれ違う分だけ、裏口の方が多くなりました(35回と52回)。

依頼134。積む所(廊下・部屋の中・裏口)と速さごとの1日あたりの問題

依頼134 の依頼文(裏口の道を建てて大廊下を通らない形と比べる)

08_sec04.md3,335字・56行・markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 600
---
# 依頼134:病院に「外来の奥の職員通路(裏口の道)」を足し、大廊下を通らない形と比べる

依頼132 の報告(claude_code_reports/20261109_hospital_132.txt)を読んで、エイイチと決めたこと(2026-11-09):
- 依頼132 の決めてほしいことへの答え:
別のタブで開く保存

依頼134 の報告(依頼箱の結果の全文)

09_sec04.md3,085字・57行・markdown
# 結果:20261109_134_病院の裏口の道を建てて大廊下を通らない形と比べる

- 状態:完了
- 始めた時刻:2026-11-09 16:01
- 終わった時刻:2026-11-09 17:24(83分)
- 作業フォルダ:/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき:作業フォルダで `claude --resume d6e6e29e-a760-45db-826b-e8fee151bbb5`
- 止められた操作:1件(いちばん下に一覧)
別のタブで開く保存

依頼136・138:時間で切り替える案は、移る道で増えた

外来の混む8〜11時だけ裏口から積み、ほかの時間は表から積む案を、試算 h2 が決めた便の時刻表どおりに Unity で1日回しました。結果は、時間で切替が廊下だけより多くなりました。8時と11時に表と裏口の間を移る道(約200m のうち約90m が大廊下)で問題が起き、特に8時は人が増えていく最中の大廊下を通るためです。

  • ねらい:混む時間だけ裏口を使い、届くまでの遅れを混む時間だけにする
  • 変わったこと:1日あたりの走っている間の問題(0.6m/秒)は、廊下だけ111回・時間で切替129回(うち移る間66.5回)・裏口だけ68回。廊下に止まっている間のひやりは約2,600回・約1,100回・約190回(依頼138 の中央値)
  • 見込める効果:裏口だけにすれば、廊下での問題は約4割減り、廊下に止まる時間はほぼなくなる。届くまでの平均は12.2分から14.0分に延びる(試算 h2)。どちらも15分の線の内側
1日を通した比べ。走っている間の問題・待っている間のひやり・届くまでの平均

依頼138 では、16:30 を過ぎる便も最後まで回し(時刻表の572便すべて)、積む所で待っている間のひやりを問題1〜5と別に数えました。16:30 までの数は依頼136 と同じでした。

依頼136 の依頼文(病院の1日を回し、時間で切り替える形と比べる)

---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 600
---
# 依頼136:病院の1日(7:30〜16:30)を回し、青の道を時間で切り替える形を比べる

依頼134 の報告(claude_code_reports/20261109_hospital_134.txt)を読んで、エイイチと決めたこと(2026-11-09):
- 外来の混む時間は裏口の道で廊下の問題がほぼ半分、空いている時間は今の道(廊下)の方が少なかった。そこで**時間で道を切り替える**(外来の混む 8〜11時だけ裏口から積み、ほかの時間は表から積む)形を、1日を通して回して比べる
- 決めてほしいことへの答え:
  1 職員通路のスタッフの通る間隔(平均60秒)はサイトの条件に入れた(params の staff_corridor_interval_s。値は同じ)
  2 狭い中廊下でストレッチャーと向き合ったら、ロボットが譲って最大20秒待つ、のままでよい(params の stretcher_yield。値は同じ)
  3 東の端の人数の四捨五入、4 東の端の扉の場所など Unity で決めた細部は、このままでよい
  5 説明の文の違いで止めなかったのは問題ない(依頼の書き漏れだった)

**配膳の場面・配膳の実行ファイル・配膳の台帳、配膳と共通の部品には触らない。** 変えるのは Assets/ServiceSim/Hospital/ の中だけ。
**エイイチは見ていない。人に聞かないと進めない所に当たったら、その項目は止めて報告に書き、ほかは続ける。夜の間も続けてよい。**

## 正(読むもの)
- 条件:p2m-site main の `tools/hospital_sim/hospital-unity-params.json`(md5 f25037c48d34b4c3e8d4ebac8558b347)。依頼134 の写し(d1c177bd…)との違いは staff_corridor_interval_s・stretcher_yield・crowd_by_time・back_door_hours・day_schedule の5項目だけのはず。ほかに違いがあれば回さずに報告して終わる
- フロアの形:依頼134 と同じ h0・h0b(md5 は params の layout.md5・layout_back_door.md5 と一致すること)
- **day_schedule**:サイトの試算(hospital_sim.py の h2・ロボット1台)が決めた、青のロボットの便の時刻表。plans(廊下だけ/時間で切替/裏口だけ)× 速さ(0.5・0.6・0.8)× 種0〜9。depart は 7:30 からの秒、from は積む所(「内科外来の処置室」=表、「内科外来の処置室(裏口)」=裏口)。**ロボットはこの時刻に from を出て検体受付へ行き、表の積む所(次の便が裏口なら裏口)へ戻って待つ。** 便の時刻・積む所は Unity で決めない。積む所が表と裏口で入れ替わるときは、その間を走って移る(瞬間移動しない)。前の便から戻りきる前に次の時刻が来たら、着いてすぐ出る(遅れた秒を残す)
- crowd_by_time:大廊下の混み具合を時刻で変える(8〜11時だけ混んでいる)。人数の変え方(いっぺんに増やす/数分かけて増やす)は Unity で決めてよい(報告に書く)

## 始める前に確かめること(違えば回さずに報告して終わる)
1. 作業場所に保留がない(cs:113 のあと)。Unity・回し係が動いていない。KIOXIA がマウント済み
2. 上の md5 と、違いが5項目だけであること

## 1. 作りの直し(病院の側だけ)
- 1日(9時間)を回せるようにする:時刻表どおりに便を出す、混み具合を時刻で変える、積む所を表と裏口で入れ替える
- ロボットの作り・数え方・人・ストレッチャー・職員通路のスタッフは依頼134 の既定のまま
- 依頼134 の形(60分・往復し続ける)にも引数で戻せるようにする
- check-in(保留0)して、病院の実行ファイル(Builds/hospital136/)を作る。前の実行ファイルは残す

## 2. 確かめ(違えば 3 は回さない)
- 時間で切替・0.6m/秒・種0 を2回回して一致すること、瞬間移動0、時刻表の便がすべて走ること(走れなかった便があれば数と理由)、11:00 の前後で積む所が裏口から表に移ること
- 依頼134 の形に戻す引数で 0.6m/秒・混んでいる・裏口・種0 を回し、依頼134 の同じ回と一致すること(違ったら、どこが違うかを書く。止めない)

## 3. 回す
- 道の決め方3つ(廊下だけ・時間で切替・裏口だけ)× 速さ3つ(0.5・0.6・0.8)× 種0〜9 = 90回。1回は 7:30〜16:30(画面なし・同時4本まで)
- 出力:/Volumes/KIOXIA/r2r2r-data/service_sim/unity/hospital/20261109_day136/(依頼134 と同じ形の記録・まとめ・索引 CSV)。前のフォルダは変えない

## 4. 録画(3 が通れば撮る)
- 時間で切替・0.6m/秒・種0 の、10:55〜11:10(裏口から表へ移る所を含む)を、移る道が入る範囲で撮る。印は依頼134 と同じ

## 止める線
瞬間移動が1回でも出たとき、または同じ種の2回が違ったとき。止めたら報告に書き、ほかの項目は続ける。

## 報告
claude_code_reports/20261109_hospital_136.txt に:始める前の確かめ、1 の直し(どのファイルのどこ・人数の変え方)、2 の確かめ、
表(道の決め方×速さごと、種10個の中央値と最小・最大):**1日あたり**の 1〜5 の問題・ひやり(ロボットが動いていた/止まっていた)・速いままのひやり・止まりきれなかった、便の数・片道の秒(表と裏口で分けて)・時刻表からの遅れ(秒)、
時間帯ごと(7:30〜8:00・8:00〜11:00・11:00 以降)の問題の数、積む所を入れ替えるときに起きた問題、上から見た図、4 の動画の名前と長さ、check-in の番号、決めてほしいこと(直し方の候補は作らない)。
**報告の最後の1行は必ず次のどれか**:「判定:合格」/「判定:止めた(決めてほしいことあり)」/「判定:失敗」

依頼136 の報告(依頼箱の結果の全文)

# 結果:20261109_136_病院の1日を回して青の道を時間で切り替える形と比べる

- 状態:完了
- 始めた時刻:2026-11-09 17:59
- 終わった時刻:2026-11-09 20:34(155分)
- 作業フォルダ:/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき:作業フォルダで `claude --resume 08fb7262-46b8-496f-b38c-5fa32352bcd3`

## Claude Code の報告

**やったこと**
- 始める前の確かめ:保留は0で(cs:113)、Unity も回し係も動いていませんでした。KIOXIA はマウント済みです。params(f25037c4)、h0、h0b の md5 はすべて合っていました。違いは5項目のほかに、いちばん上の `model` が h1 → h2 に変わっていました。依頼文が「h2」と書いているので時刻表の版の名前とみて、止めずに回しました(決めてほしいことの5)。
- 1:病院の1日(7:30〜16:30)を回せるようにしました。直したのは Assets/ServiceSim/Hospital/ の中だけです。
  - 便は時刻表どおりに出し、「積む所 → 検体受付 → 積んだ所」と走ります。
  - 待つ所は 8:00〜11:00 だけ裏口、ほかは表です。8:00 と 11:00 に、表と裏口の間を走って移ります。
  - 人数は、増えるときは5分かけて1人ずつ増やします。減るときは出た人を入れ直さないだけで、約1分で減りきります。
  - 引数 `-h136Mode 134` で依頼134 の形に戻せます。
  - check-in は cs:114 で、実行ファイルは Builds/hospital136 に作りました。前の実行ファイルは残しています。
- 2:確かめ(同じ種の2回・瞬間移動・便・11:00 の入れ替え・依頼134 の形との一致)はすべて通りました。数は「結果」に書きました。
- 3:本番90回(3つの道の決め方 × 3つの速さ × 種0〜9、同時4本、約2時間10分)を回しました。
- 4:時間で切替・0.6m/秒・種0 の 10:55〜11:10 を撮りました。

**結果**
- 確かめ(2):
  - 同じ種の2回は、記録7つが1バイトも違いませんでした。瞬間移動は0です。
  - 時刻表の5便はすべて走りました。11:00 より前の便は裏口から、後の便は表から出ました。11:00:00 に裏口を出て、11:05:47 に表に着きました。
  - 依頼134 の形に戻す引数の回は、依頼134 の同じ回と記録4つが1バイトも違いませんでした。
- 本番:90回すべて completed、瞬間移動0です。
- 便:時刻表の572便のうち552便が走りました。
  - 2便は 16:30 の時点で帰りの途中でした。
  - 18便は時刻が 16:30:30〜35 で、回の終わりより後なので走らせていません。
  - 遅れは1便だけで、11:00 に移る途中で時刻が来て68秒遅れて出ました。
- 片道の秒(0.6m/秒):表から 140〜149、裏口から 249〜250 です。
- 1日あたり、走っている間の1〜5の問題(中央値。廊下だけ/時間で切替/裏口だけ):

| 速さ | 廊下だけ | 時間で切替 | 裏口だけ |
|---|---|---|---|
| 0.5m/秒 | 132 | 159 | 86 |
| 0.6m/秒 | 111 | 125 | 68 |
| 0.8m/秒 | 73.5 | 93 | 43 |

- 時間で切替が廊下だけより多いのは、8:00 と 11:00 の移る道(約200m、そのうち大廊下を約90m)の分です。0.6m/秒では 125 のうち 66.5 が移る間でした。
  - 8〜11時だけを見ると、廊下だけ 91/時間で切替 85.5/裏口だけ 47 です。
  - 移る間の問題は、8:00 の表 → 裏口(1,373件)が 11:00 の裏口 → 表(643件)の倍ほどでした。8:00 は人が増えていく最中に大廊下を通るためです。
- 積む所で待っている間の数えは、別に出しました。1日あたり 廊下だけ 約2,600、時間で切替 約1,100、裏口だけ 約190 です。表の積む所は大廊下の中にあるので、止まったロボットの横を人が通るたびに「ひやり」になります。
- 表のすべて(ひやりの内訳・止まりきれなかった・時間帯ごとの数)、上から見た図、録画の中身は報告ファイルに書きました。
- 動画は hospital136_0.6_switch_s0_1055-1110.mp4(900秒)です。

**変えたファイル**
- Assets/ServiceSim/Hospital/HospitalRun.cs
- Assets/ServiceSim/Hospital/Editor/HospitalSetup.cs
- Assets/ServiceSim/Hospital/Data/hospital-unity-params.json
- 上の3つは cs:114 で check-in しました。
- 新しく作ったもの:Builds/hospital136
- KIOXIA の 20261109_day136/(回し係・まとめ・図・動画・記録・索引)
- 報告:claude_code_reports/20261109_hospital_136.txt と 20261109_hospital_136_files/

**決めてほしいこと**
1. 待つ所を入れ替える時刻:依頼文の「表(次の便が裏口なら裏口)へ戻って待つ」のとおりにすると、11:00 の前後に移る所がありません。そこで、依頼の「その間を走って移る」「10:55〜11:10 を撮る」とサイトの h2 に合わせ、「積んだ所へ戻り、8:00・11:00 に表と裏口の間を走って移る」にしました。この形でよいか。
2. 表の積む所(大廊下の中)で待っている間の数え(1日 約2,600)を、問題に入れるか。
3. 16:30 より後の18便と、16:30 で途中の2便:最後の便が終わるまで回すか。
4. 人数の変え方(増えるときは5分かけて1人ずつ、減るときは入れ直さず約1分で減りきる)でよいか。
5. params の `model`(h1 → h2)が5項目の外で変わっていたのを、止めずに回してよかったか。

判定:止めた(決めてほしいことあり)

依頼138 の依頼文(1日を最後の便まで回し直し、待っている間のひやりを分けて出す)

---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 480
---
# 依頼138:病院の1日を最後の便まで回し直し、待っている間のひやりを分けて出す

依頼136 の報告(claude_code_reports/20261109_hospital_136.txt)を読んで、エイイチと決めたこと(2026-11-09):
1 待つ所の移り方は依頼136 の形(積んだ所へ戻り、8:00・11:00 に表と裏口の間を走って移る)でよい(params の switch_move)
2 積む所で止まって待っている間のひやりは、問題1〜5に混ぜず「廊下に止まっている間のひやり」として別に並べる(params の waiting_near_miss)
3 16:30 を過ぎる便も、最後の便が積んだ所へ戻るまで回す。16:30 以降も人と混み具合は空いているのまま(params の day_end_rule)
4 人数の変え方(増えるときは5分かけて1人ずつ、減るときは入れ直さず約1分)はこのままでよい
5 params の model の違いで止めなかったのは問題ない(依頼の書き漏れだった)

**配膳の場面・配膳の実行ファイル・配膳の台帳、配膳と共通の部品には触らない。** 変えるのは Assets/ServiceSim/Hospital/ の中だけ。
**エイイチは見ていない。人に聞かないと進めない所に当たったら、その項目は止めて報告に書き、ほかは続ける。夜の間も続けてよい。**

## 正(読むもの)
- 条件:p2m-site main の `tools/hospital_sim/hospital-unity-params.json`(md5 f72d3810674b31dadd9dfa4ce0141178)。依頼136 の写し(f25037c4…)との違いは waiting_near_miss・day_end_rule・switch_move の3項目だけのはず(day_schedule は同じ)。ほかに違いがあれば回さずに報告して終わる
- フロアの形:h0・h0b(依頼136 と同じ md5)

## 始める前に確かめること(違えば回さずに報告して終わる)
1. 作業場所に保留がない(cs:114 のあと)。Unity・回し係が動いていない。KIOXIA がマウント済み
2. 上の md5 と、違いが3項目だけであること

## 1. 作りの直し(病院の側だけ)
- 回の終わりを「最後の便が積んだ所へ戻るまで」にする(day_end_rule)。依頼136 の形(16:30 で終わる)にも引数で戻せるようにする
- まとめで、積む所で止まって待っている間のひやりを「廊下に止まっている間のひやり」として問題1〜5と別の列にする(依頼136 で別に出した数え方のまま)
- check-in(保留0)して、病院の実行ファイル(Builds/hospital138/)を作る。前の実行ファイルは残す

## 2. 確かめ(違えば 3 は回さない)
- 時間で切替・0.6m/秒・種0 を2回回して一致すること、瞬間移動0、時刻表の便がすべて走り終わること
- 依頼136 の形に戻す引数で同じ回を回し、依頼136 の同じ回と一致すること(違ったら、どこが違うかを書く。止めない)

## 3. 回す
- 道の決め方3つ × 速さ3つ(0.5・0.6・0.8)× 種0〜9 = 90回(依頼136 と同じ並び)
- 出力:/Volumes/KIOXIA/r2r2r-data/service_sim/unity/hospital/20261109_day138/。前のフォルダは変えない

## 止める線
瞬間移動が1回でも出たとき、または同じ種の2回が違ったとき。止めたら報告に書き、ほかの項目は続ける。

## 報告
claude_code_reports/20261109_hospital_138.txt に:始める前の確かめ、1 の直し、2 の確かめ、
表(道の決め方×速さごと、種10個の中央値と最小・最大):**1日あたり**の 1〜5 の問題(走っている間)・そのうち表と裏口を移る間の数・廊下に止まっている間のひやり・ひやり(ロボットが動いていた/止まっていた)・速いままのひやり・止まりきれなかった、便の数(走った/時刻表)・片道の秒・時刻表からの遅れ、
時間帯ごと(7:30〜8:00・8:00〜11:00・11:00〜16:30・16:30 以降)の問題の数、依頼136 との違い(16:30 以降の便の分)、check-in の番号、決めてほしいこと(直し方の候補は作らない)。
**報告の最後の1行は必ず次のどれか**:「判定:合格」/「判定:止めた(決めてほしいことあり)」/「判定:失敗」

依頼138 の報告(依頼箱の結果の全文)

# 結果:20261109_138_病院の1日を最後の便まで回し直し待っている間のひやりを分けて出す

- 状態:完了
- 始めた時刻:2026-11-09 21:21
- 終わった時刻:2026-11-09 23:47(146分)
- 作業フォルダ:/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき:作業フォルダで `claude --resume d3864dfb-2c65-47f2-a360-d5b6c3cebb3b`

## Claude Code の報告

**やったこと**
- 始める前の確かめをしました。作業場所は cs:114 で保留0、Unity と回し係は止まっていて、KIOXIA もマウント済みでした。params の md5 は f72d3810 で依頼と同じです。依頼136 の写しとの違いは、足された3項目(waiting_near_miss・day_end_rule・switch_move)だけでした。h0・h0b の md5 も依頼136 と同じです。
- 作りを直しました(Assets/ServiceSim/Hospital/ の中だけ)。
  - 新しい引数 `-h138Mode 138` で、最後の便が積んだ所へ戻るまで回します(既定)。`-h138Mode 136` で依頼136 の形(16:30 で終える)に戻せます。
  - 16:30 以降も混み具合は空いているのままです。ストレッチャーは同じ間隔で続け、16:30 より後の分だけ別の乱数で決めます。こうすると 16:30 までの流れが依頼136 と同じになります。
  - 積む所で止まって待っている間の数えは、「廊下に止まっている間のひやり」として問題1〜5とは別の列にしました。
- check-in は cs:115(保留0)です。実行ファイルは Builds/hospital138 に作り、前の実行ファイルは残しました。
- 確かめ4つを回したあと、本番90回を回しました。

**結果**
- 確かめはすべて合いました。
  - 時間で切替・0.6m/秒・種0 の2回は、記録7つが1バイトも違いませんでした。瞬間移動0で、時刻表の5便すべて走り終えました。
  - 依頼136 の形に戻す引数で回した同じ回も、依頼136 の回と記録7つが1バイトも違いませんでした。
  - 16:30 を過ぎる回(裏口だけ・0.5m/秒・種3)も2回回し、1バイトも違いませんでした。
- 本番90回はすべて completed、瞬間移動0です。止める線には当たっていません。
- 時刻表の572便はすべて走り終えました(依頼136 は552便)。
- 16:30 を過ぎたのは20回で、過ぎた長さは78〜633秒です。上限(16:30+60分)に当たった回は0でした。
- 90回すべてで、16:30 までの時間帯ごとの数が依頼136 の同じ回と同じでした。違いは 16:30 以降の分だけです。

1日あたりの中央値(廊下だけ/時間で切替/裏口だけ):

| 速さ | 走っている間の1〜5 | 廊下に止まっている間のひやり |
|---|---|---|
| 0.5m/秒 | 136/167.5/86 | 2572/1078/188 |
| 0.6m/秒 | 111/129/68 | 2601/1103/185 |
| 0.8m/秒 | 78/93/47.5 | 2668.5/1096.5/192.5 |

- 時間で切替のうち、表と裏口を移る間の数は 87.5/66.5/42.5(0.5/0.6/0.8m/秒)です。
- 16:30 以降に増えた分(合計):

| 道の決め方 | 16:30 を過ぎた回 | 便 | 1〜5 | 止まりきれなかった |
|---|---|---|---|---|
| 廊下だけ | 6回 | +6 | +62 | +3 |
| 時間で切替 | 6回 | +6 | +54 | +5 |
| 裏口だけ | 8回 | +8 | +52 | 0 |

- 報告は claude_code_reports/20261109_hospital_138.txt に書きました。最後の行は「判定:止めた(決めてほしいことあり)」です。決めてほしいことが3つあるためです。
- データは KIOXIA の 20261109_day138/ にあります。

**変えたファイル**
- Assets/ServiceSim/Hospital/HospitalRun.cs
- Assets/ServiceSim/Hospital/Editor/HospitalSetup.cs
- Assets/ServiceSim/Hospital/Data/hospital-unity-params.json(f72d3810 に入れ替え)
- 新しく作ったもの:Builds/hospital138/、KIOXIA 20261109_day138/(run138.py・agg138.py・集計の表と図)、報告ファイルとその付録フォルダ

**決めてほしいこと**
1. 「廊下に止まっている間のひやり」の列に入れる数をどちらにするか。いまは依頼136 と同じく、待っている間の1〜5の合計(ひやり+人がよけさせられた)にしています。ひやりだけの数も横に並べました。
2. 最後の便が 16:30 より前に戻った回は、依頼136 と同じく 16:30 まで回しました(その間に止まっている分も数えています)。戻った時刻で終える形にはしていません。これでよいか。
3. params に決めが無かったので、次の2つは私が決めました。これでよいか。
   - 16:30 以降のストレッチャーは、同じ間隔(1時間2台)で続けました。
   - 最後の便を待つ上限を 16:30+60分にしました(本番で当たった回は0)。

判定:止めた(決めてほしいことあり)

試算 h2 が書き出した Unity の条件(hospital-unity-params.json の全文)

10_sec04.json45,228字・2,694行・json
{
 "about": "病院の搬送ロボットの Unity(ServiceSim の病院の場面)が読む条件。export_unity_params.py が assumptions.json から書き出す。直すときは assumptions.json を直して書き出し直す",
 "model": "h2",
 "layout": {
  "file": "tools/hospital_layouts/hospital_h0.json",
  "md5": "a29cd1d981e5b3086fb623fc647926d9",
  "name": "仮の病院 h0(外来の階)"
 },
別のタブで開く保存

残したずれと、次に見ること

  • 1便あたりの人の時間の減りは、道の長さと人の手間のどちらで埋まるかを決めていない(現場で聞くまで両方を並べる)
  • 速さの悪い面は、止まるまでの距離(減速0.5m/秒²・気づいてから0.2秒)が仮置きのままの結果。病院の設定やメーカーの値が分かれば置き換える
  • 至急は1ルートで1日1件もなく、10日分の平均でもぶれが大きい
  • Unity の Hospital の場面は ServiceSim の Assets/ServiceSim/Hospital/(cs:110〜115)。配膳の場面と共通の部品は1行も変えていない
  • 結果は KIOXIA の service_sim/unity/hospital/ の 20261109_speed127・brake132・backdoor134・day136・day138