# 段階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 の項）