# 段階C：サイトの試算と Unity のずれの一覧 v1（2026-10-24）

元のデータ：段階Bの18回（cs:140・店の形 82023936eb99・試算 v2.7）。③⑦ × ロボット0・1・2台 × 種0・1・2。
分析のコードと結果：KIOXIA `r2r2r-data/service_sim/unity/stageC_v1/`（a1〜a4.py・rows.json・carry.json・*_output.txt）。
理由の分け方は設計書 0.5 章：1 数え方の違い／2 サイトにない動き（すれ違い・混雑）／3 Unity の作りの問題。
対処を実際に入れるのは次の版。この一覧では決めるところまで。

## 1. 合っていたもの

- ロボットが1往復で走る距離：Unity 26〜36m、試算の計算式（卓までの距離＋卓から卓へ3m）25〜35m。ほぼ同じ
- 片付けを後回しにする順番（片付けは優先2、案内・配膳・会計は1、立ち往生は0）：同じ
- ロボットなしの料理の待ち：差0.2〜0.4分。ほとんどが下の表の7（スタッフが今いる所から歩く）で説明がつく

## 2. ロボットが運んだ皿の待ちの内訳（3回平均・分）

| 条件 | 受け渡し口で待った | 運ぶ（記録の値） | うち戻るまでを数えた分（表の1） | 卓に着くまで（見積もり） | 試算の式で卓に着くまで | 1往復で止まった秒 | 立ち往生した往復 |
|---|---|---|---|---|---|---|---|
| ③ 1台 | 1.20 | 2.55 | 1.24 | 1.31 | 0.72 | 33秒 | 10% |
| ③ 2台 | 1.11 | 3.04 | 1.04 | 2.01 | 0.58 | 86秒 | 18% |
| ⑦ 1台 | 1.44 | 2.59 | 1.32 | 1.27 | 0.77 | 22秒 | 6% |
| ⑦ 2台 | 0.76 | 2.60 | 1.09 | 1.51 | 0.61 | 58秒 | 11% |

試算の前提：1往復で止まるのは30%の確率で3〜10秒（平均約2秒）、立ち往生は1%。
「卓に着くまで（見積もり）」は、記録の値から、着いたあとの受け渡し25秒と残りの道のり（Unity の速さで）を引いたもの。止まりは全部着く前に起きたとして引いているので、表の1の大きさは小さめに見積もっている。

## 3. ずれの一覧

| # | ずれ | 大きさ | 理由 | 対処（次の版） |
|---|---|---|---|---|
| 1 | ロボットが運んだ皿の「届いた時刻」が、卓に着いた時刻ではなく、往復を終えて受け渡し口に戻った時刻になっている。客が食べ始めるのもその時刻 | 料理の待ち +1.0〜1.3分/皿。食事の始まりが遅れ、卓が空くのも遅れる（入店待ちにも効く） | 3。ロボットは卓に着いた時点で「届いた」と数えている（ServingRobotController の StopsCompleted）が、皿を届いたにするのは往復の終わり（ServiceOps.OnRobotRunDone）だけ | Unity：卓に着いた時点（StopsCompleted が増えたとき）でその卓の皿を届いたにする。試算と同じ（受け渡し25秒の前に届いた） |
| 2 | ロボットが1往復で止まる時間が長い。立ち往生（60秒止まる）も多い | 止まり 22〜86秒/往復（試算 約2秒）。立ち往生 6〜18%の往復（試算 1%） | 1台：2。止まりの理由は人とのすれ違い・人の立ち止まり（客席の通路が4〜6割）。Unity が測るべき値そのもの。2台：止まる時間の5〜6割と、60秒止まりのほとんどが「もう1台のロボット」。試算には台どうしの邪魔がない。ただし実機の配膳ロボットは台どうしで道を調整する仕組みを持つものが多く、Unity の2台が60秒向かい合うのは作りの問題（3）の疑いが強い | 1台の止まりの値：表の1を直して測り直してから、サイトの pause・stuck に入れるかを決める。2台の台どうしの止まり：Unity の次の版で見直す |
| 3 | ロボットが運んだ料理の割合が低い | 62〜80%（試算 72〜99%） | 2の結果。往復が長いので、2分待っても戻らず人が運ぶ皿が増える | 単独では直さない。1・2の結果を見る |
| 4 | ロボットが走っているときの速さ | 毎秒0.57〜0.58m（試算 0.5m） | 1。Unity の最高速度の設定が0.6m。試算の0.5は仮の値 | どちらにそろえるか決める（Unity の速さは測った値ではなく設定） |
| 5 | ロボットなしで、卓が空くまでが短い | 片付け 5.0〜5.5分（試算 9.5〜10.2分）、席が空くのを待った時間 0.5〜0.9分（試算 2.5〜3.6分） | 未確定。仕事の順番は同じ。疑い：逃がし弁「卓を空けた」が1回に14〜31卓あり、片付けを飛ばして卓を空けている（3） | 記録：「卓を空けた」で片付けを省いた卓を、片付けの時間と分けて数える。そのうえで理由を決める |
| 6 | 逃がし弁がまだ働いている | ロボットなしでも あきらめた6〜10・移した11〜23・卓を空けた14〜31。2台で 57〜113・46〜107・4〜45 | 3。段階Aの終わりの条件（ほぼ0）は満たさずに進めた | 次の版の直す対象として残す。どの仕事で出ているかは give_ups.csv |
| 7 | スタッフが運ぶ時間が長い | 0.43〜0.62分（試算 約0.18分） | 2。試算はスタッフが受け渡し口にいる前提、Unity は今いる所から受け渡し口へ歩く | 直さない（サイトにない動き） |
| 8 | スタッフの歩く距離が長い | 1人 2.6〜3.2km（試算 1.6〜2.9km） | 1と2。道のりの測り方の違い、よける・回り道 | 直さない |
| 9 | 入店待ちが回によって大きくぶれる | 同じ条件で1.6〜15.1分 | 回数が足りない | 次の段階Bで乱数の種を増やす |
| 10 | 往復の記録（trips.csv）の皿の欄（dishes・dish_ready_s・dish_arrived_s）が、同じロボットの次の往復の行に書かれている。往復の始まりの時刻と、卓ごとに着いた時刻の欄がない | 記録だけ。動きには効かない | 3（記録） | Unity：記録を直し、始まりの時刻と卓ごとに着いた時刻を足す |

## 4. 決めること（エイイチ）

- 次の版で Unity に入れる直し：1（届いた時刻）・10（記録）を先に入れるか
- 2の2台の台どうしの止まりを、Unity の作りの問題として直すか、サイトにない動きとして残すか
- 4の速さを、試算の0.5にそろえるか、Unity の0.6にそろえるか、そのままにするか

## 5. エイイチの決定（2026-10-24）

- 1（届いた時刻）と10（往復の記録）を次の版で先に入れる。依頼は claude_code_request_v8_dish_arrival.md（v7b の押し直しの直しも、照らし合わせに Unity の版を入れて同じ依頼に入れた。v7b は送らない）。直したら段階Bの18回を回し直す
- 2の2台の台どうしの止まり（60秒向かい合う）は、Unity の作りの問題（3）として扱う。手を付けるのは、v8 で回し直したあと（どちらの直しが効いたかを分けるため）
- 4の速さは今のまま（Unity の最高 0.6m/秒、試算 0.5m/秒）。手を付けない。帳尻合わせで Unity やサイトの値を動かさない。サイトの数値が正
- v8 の確かめの1回（2026-10-24 08:59・③2台・種0）で店が止まった。原因は cs:140 からある打ち切りの戻し方（2台とも受け渡し口の同じ点に置かれて重なり、止まり続けた）。あわせて、同じ種でも動きがずれると来る客が変わる（83組→105組）ことが分かった。エイイチと決めて、打ち切りで重ねない（A）・来客と組の中身を別の乱数にする（B）を v8b として v8 に足した（claude_code_request_v8b_timeout_rng.md）。行き止まりでの台どうしの向かい合いは、回し直したあとに扱うまま
- 2の台どうしの止まりの根本：ロボットが決まった線の上しか走れない作り（routes）。現実の配膳ロボットは地図の上で自分で道を引き、回り込む。次の版で動き方を変える（unity_design_v0.md の 2026-10-24 の項）
- 動き方を変える依頼 v9（claude_code_request_v9_map_planner.md、2026-10-24）：サイトの地図の上でロボットが自分で道を引く。料理を載せている方が先・3秒で回り込む・通路の真ん中寄り（エイイチの決定）。確かめは③2台・種0を1回、v8b の同じ回（1004）と比べる。18回の回し直しはその結果を見てから

## v9 の確かめ B（2026-10-24）
- 3回の比べ（③2台・種0・64組・どれも回り切る）：v8b（1004）／v9・ドリンクバー前（1304、店の形 2fa10547a2b7）／v9・ドリンクバー後（1559、8a5b2f6a016a）
  - 60秒の止まり 57（ロボットどうし51）／59（36）／20（15）。1往復で止まった秒 110／83／33。打ち切り 11／10／1
  - ロボットが運んだ割合 0.64／0.76／0.99。料理の待ち 2.90／2.12／1.17分（試算 v2.7 は1.01）。入店待ち 1.67／1.61／1.47分（試算1.08）
  - 1304 の60秒止まりの43回は右下の行き止まり（エイイチの指摘でドリンクバーを動かし、1559 で0に）
- 残り（段階Bの18回と合わせて扱う）
  - 受け渡し口の左下（x14.3・z5.3）で1号機が2号機に7回続けて止められた（152〜160分）。止まっているロボットが受け渡し口の近くをふさいでいる疑い
  - スタッフが右下の通路の端（x20.0・z2.7、ドリンクバーの右の抜け道の入口）に4分以上立ち止まり、2号機が通れなかった
  - 逃がし弁92回のうち70回がドリンクバーの客（移した51・あきらめた19）。ドリンクバーを動かす前（1304）も72回で、人の動きの側の問題
- 進め方（エイイチ了承）：Check-in → 段階Bの18回を回し直す（⑦は新しい動き方で初めて回す）→ 残りは段階Cで扱う

## 段階Bの18回の回し直し（cs:143・店の形 8a5b2f6a016a・試算 v2.7。2026-10-24 16:33ごろ〜23:13）
集計は KIOXIA service_sim/unity/stageB_cs143/（b1_collect.py → runs.txt。cs:140 の18回も同じ形で並べた）
- 18回とも全員が店を出た。来る客は種ごとに台数に関係なく同じ（種0 64組・種1 83組・種2 102組。平均83組で試算の約84組とほぼ同じ）
- ロボットありの回は大きく良くなった（3回平均。cs:140 → cs:143、試算）
  - 2台：料理の待ち ③4.46→1.51・⑦3.53→1.38（試算1.01）。ロボットが運んだ割合 ③0.68→0.90・⑦0.77→0.95（試算0.99）。60秒止まりのロボットどうし ③94→61・⑦111→35（3回の合計）。打ち切り ③24→7・⑦21→6
  - 1台：料理の待ち ③3.61→2.41・⑦3.74→2.53（試算2.03・2.16）。割合 ③0.64→0.72・⑦0.62→0.69（試算0.73・0.71）
- 残ったずれ
  1. 入店待ちがロボットの台数で変わらない（Unity ③3.48・3.53・3.66分／⑦3.91・3.97・3.81分。試算 ③3.99→1.82→1.08・⑦4.78→2.14→1.14）。種0・1は1.4〜2.0分、種2（102組）は7〜8.5分で、平均は種2で決まる。席が空いているのに待った分（staff_wait）は種0・1で0.2〜0.7分しかなく、ロボット0台でもスタッフが回っている。試算ではロボット0台のスタッフが足りない（③3.36分）。疑い：Unity のスタッフの仕事が試算より軽い（前回の5：片付けが短い）と、逃がし弁「卓を空けた」が片付けを飛ばしている（ロボット0台で ③61・⑦92 回）
  2. ドリンクバーの逃がし弁が増えた：⑦0台で移した・あきらめた 69→148、③2台で 184→237（3回の合計）。ドリンクバーを動かしたとき、並ぶ点が2つから1つに減った（2つめが待機場所に近すぎる）のが疑い。人の動きの側
  3. v9 の確かめで見た受け渡し口の左下の止まり・抜け道の入口でのスタッフの立ち止まりは、18回で数えて確かめる

## 段階Cの2回目：入店待ちがロボットの台数で変わらない原因（2026-10-25・調べただけ。Unity は触っていない）
- 記録：KIOXIA service_sim/unity/stageB_cs143/b5_register_and_valve.py・_output.txt（cs:143 の18回）
- スタッフの仕事は軽くない。来た組が試算に近い種1（83組）で、手のふさがりは ③0台 0.77（試算0.75）・⑦0台 0.82（試算0.74）
- 原因1 レジ：Unity はレジの内側に1人だけで、会計は1組ずつ（1組あたり93〜102秒）。1時間にさばけるのは約36〜39組で、試算の来客42組/時より少ない。ロボットを足してもこの詰まりは減らない。試算は会計（pay_s 90秒）をスタッフのだれでも同時にできる
- 原因2 逃がし弁「卓を空けた」：会計・片付けで600秒止まった卓を、片付けずに空ける。片付けの仕事を待っている間（まだだれも取っていない）も数えている。種1の ③0台で83組のうち24卓（会計7・片付け17）、消えたスタッフの仕事は全体の10%。試算では片付けを10分以上待つのは普通（③0台の回転9.7分）なので、Unity はその待ちを打ち切り、席は空いているのに待った時間が小さく出る（種1で0.55分、試算3.36分）
- 種の偏り：来た組は種0・1・2で64・83・102組。試算の平均84組に近いのは種1だけで、種0と種2は大きく外れている。3回の平均で試算と比べない
- 決めること（エイイチ）：会計の時間とレジの数をどちらに合わせるか／逃がし弁の数え方を変えるか
- 決めたこと（2026-10-25）：会計の時間は実感どおり90秒のまま。試算にレジを入れ、レジ1つ・2つを選べるようにした（全部の店。大型店は2つを最初に見せる）→ 試算 v2.8 として公開（p2m-site f26f27c・simulation/v2_8/）。会計待ちが10分以上なら「レジが詰まる」の印を別に出し、「店が回らない」の決め方は変えない。逃がし弁はスタッフが仕事を取ってから止まった時間だけ数える（Unity の直し。まだ Claude Code に出していない）
- v2.8 の③⑦・普通・4人・レジ1つ（Unity の6条件と同じ）：入店待ち ③ 3.30→2.60→1.18分・⑦ 2.76→1.82→1.97分、会計待ち 12.3→8.0→8.0分・11.7→8.1→8.0分。Unity の会計（会計に立ってから退店まで3.5〜5分）とは、逃がし弁を直してから比べる

## v10 の確かめ B（2026-10-25・20261025_p1_efficient_corner_fam_p1_s4_r0_a42_s1_1013・③4人0台・種1・83組）
- 逃がし弁の直しは効いた：卓を空けた 24 → 0。あきらめた7・移した11（ほぼ変わらず）。最後まで回り切った
- 隠れていた片付け待ちが出た：片付けの仕事が取られるまで平均511秒・最大1,145秒・600秒超え37回。客が帰ってから卓が使えるまで 4.95 → 10.76分
- 入店待ち 1.74 → 3.91分（試算 v2.8 3.30・v2.7 3.99）。席は空いているのに待った 0.55 → 2.71分（v2.8 0.95・v2.7 3.36）。会計待ち 4.71分（v2.8 12.28）。手のふさがり 0.78（v2.8 0.72）
- 読み：入店待ちの大きさは試算に近づいたが、詰まる場所が違う。試算 v2.8 はレジ（会計待ち12分・片付けは2.5分で回る）、Unity は片付け（回転10.8分・会計待ち4.7分）で、v2.7 の形に近い。仕事1件あたりの時間（案内67秒・配膳34秒・会計93秒・片付け2.1分）は試算とそろっているので、仕事の取り方か、ピークの時間帯の手の空き方の違いを疑う。段階Bの18回の回し直しと合わせて、時間帯ごとに並べて調べる

## 基準データ v2（段階Bの18回・cs:144・2026-10-25）
- KIOXIA の service_sim/unity/stageB_cs144/README.md に、比べ（c1）と時間帯（c2）と見立てをまとめた
- 要点：卓を空けたはほぼ0に。③はロボットで入店待ちが縮む向きが試算と同じになった。⑦は外れる。詰まる場所は Unity が片付け・試算がレジ。仕事1件あたりのスタッフの時間が Unity の方が ③7%・⑦18% 長く、ピークで手が95%ふさがっている試算では、その差で片付けがたまる
- 決めたこと（2026-10-25）：スタッフの歩く距離の差は、今は試算に入れず、ずれとして記録だけにする。基準データ v2 で区切り、夜に回す仕組みづくりに移る。候補として残す直し方：案内は入口→卓、片付けは卓→洗い場の距離を平面図から取る（図面のある店だけ回し直し）／人をよける分の遅れは Unity の実測を入れる