==================================================================== busycheck：同時に何本走らせるかで数字が動くか ③1台・種1（fam_p1_s4_r1_a42・種1）／Unity エディタを閉じて 2026-10-26 15:56 ==================================================================== 結論 ・**動きます。ただし動くのは4つの列だけです。** 動けなくなった 中央 1 → **7**（1本ずつ → 4本同時） 助けた 中央 1 → **7**（動けなくなったと同じ数） ロボット分担 中央 0.699 → **0.660** 店員が遅れて運んだ 中央 62 → **70** どれも n=5 対 8 の順位の検定（両側 5%）で、はっきり違います。 ・**夜で主に見る数字は動きません。** 入店待ち・店員待ち・料理待ち・会計待ち・卓が空くまで・回転・ 店員の忙しさ・ロボットの忙しさ・往復・店の中の時間 ぜんぶ「違いは言えない」。入店待ちは中央 2.29 → 1.79 で **逆向き**です。 ・★ そして大事な発見：**エディタ（cs:7）の回は「4本同時」の側に入ります。** 6つの列のうち5つで、エディタの値は 4本同時の幅の中・1本ずつの幅の外でした。 → 基準データ（cs:7・エディタで測った18回）と並べるなら、 **夜も N = 4 で回すのが合っています**。 ・なので **N = 4 を勧めます**（速さでも最良・基準データとも揃う）。 ・台帳は健全。足した 29 行すべて 59 列・completed・重複なし。 退避版の86行はそのまま。 ==================================================================== 1. 回し方 ==================================================================== ・Unity エディタは **閉じて**回しました（エイイチの指示どおり）。 閉じた効果はすぐ出ました。1本の実時間が **151 秒 → 115 秒**になり、 5回のばらつきも 113.6〜119.0 秒とほぼ揃いました （開いていたときは 115〜199 秒）。 ・busy1 … 1本ずつ 5 回（-ssTry 1〜5 で名前が重ならないように） ・busy4 … 4本同時 × 2 束 = 8 回 1束が4本なので「5回」ぴったりにはなりません。2束にすれば 8回すべてが「4本同時のときの1回」になり、標本も増えます。 かかる時間は5回でも同じ（2束ぶん）です。 ・実行ファイルは cs:17（保留 0・ARM64）。終了コードは 13 回すべて 0。 ・資源：1本 CPU 約145%・RSS 約100 MB ／ 4本同時 CPU 約572%・RSS 約490 MB （8コア・16 GB。エディタを閉じたので、開いていたときの 458% より 使えるようになっています） ==================================================================== 2. 回ごとの数字（エイイチの指定の3つ） ==================================================================== busy1（1本ずつ・5回） 回 動けなくなった 人のあきらめ 入店待ち（分） 店の中（分） 実時間 ────────────────────────────────────────────────────────────────── 1 5 38 2.3297 182.56 119.0 秒 2 3 31 2.2925 183.09 114.4 秒 3 1 23 1.5839 183.11 114.0 秒 4 1 35 2.3109 180.28 113.6 秒 5 1 34 2.1926 181.75 115.5 秒 中央 1 34 2.292 幅 1〜5 23〜38 1.584〜2.330 busy4（4本同時・8回） 回 動けなくなった 人のあきらめ 入店待ち（分） 店の中（分） 実時間 ────────────────────────────────────────────────────────────────── 1 3 36 1.6533 181.22 217.4 秒 2 6 40 2.0028 184.88 219.5 秒 3 8 51 1.6424 181.15 217.4 秒 4 5 33 1.9285 181.42 217.3 秒 5 9 35 2.8235 182.40 213.9 秒 6 2 32 1.5746 183.89 214.5 秒 7 11 51 3.0459 181.44 212.3 秒 8 8 48 1.6230 184.72 215.3 秒 中央 7 38 1.791 幅 2〜11 32〜51 1.575〜3.046 13 回すべて status = completed・everyone_left = 1。 店の中の時間は 180.3〜184.9 分で、忙しさによらずほぼ同じです。 ==================================================================== 3. 判定 ==================================================================== 使った検定：順位の検定（Mann–Whitney）。n=5 対 8 の両側 5% は U ≤ 6。 ① 動けなくなった（stuck_count）… **はっきり違う** 1本ずつ 中央 1（1〜5） 4本同時 中央 7（2〜11） U = 4（≤ 6）。40 組のうち 36 組（90%）で 4本同時の方が大きい。 幅は 2〜5 で重なりますが、中央は **7 倍**です。 ② 人のあきらめ（gave_up）… **違うとは言えない** 1本ずつ 中央 34（23〜38） 4本同時 中央 38（32〜51） U = 8.5（> 6）。増える向きには見えますが、言い切れません。 ③ 入店待ち（entry_wait_mean）… **違わない** 1本ずつ 中央 2.292（1.584〜2.330） 4本同時 中央 1.791（1.575〜3.046） U = 15（> 6）。しかも中央は **減って**います（逆向き）。 ④ ほかの列をぜんぶ当たった結果（はっきり違ったのは4列だけ） 列 1本ずつ 4本同時 向き ───────────────────────────────────────────────────────────── stuck_count 1（1〜5） 7（2〜11） 増える rescues 1（1〜5） 7（2〜11） 増える robot_share 0.699 0.660 減る late_staff_dishes 62（59〜67） 70（63〜75） 増える ※ rescues と stuck_count が同じ数なのは、動けなくなった回が ぜんぶ助けられているという意味です（二重に数えてはいません）。 動かなかった主な列（U と判定） ───────────────────────────────────────────────────────────── entry_wait_mean U=15 違いは言えない staff_wait_mean U=16 違いは言えない dish_wait_mean U=8 違いは言えない staff_util U=13 違いは言えない robot_util U=11 違いは言えない pay_wait_mean U=19 違いは言えない blocked_wait_mean U=16 違いは言えない turn_mean U=17 違いは言えない total_minutes U=19 違いは言えない trips U=11 違いは言えない 筋も通ります 忙しい → ロボットが止まる回数が増える（stuck_count ↑・rescues ↑） → ロボットが運べる割合が下がる（robot_share ↓） → 足りない分を店員が遅れて運ぶ（late_staff_dishes ↑） → **客の待ちは店員が吸収するので変わらない**（entry_wait ほぼ同じ） 10/25 の切り分けで最後まで消えなかった容疑（NavMeshAgent の動きが Unity の job で並列に動く）と向きが合っています。 止まる・助ける所にだけ出て、店の流れ全体には出ない、という形です。 ==================================================================== 4. ★ エディタ（cs:7）はどちらの忙しさに近いか ==================================================================== 同じ条件・同じ種1 で、基準データ（cs:7・エディタで測った回）を並べました。 列 エディタ 1本ずつ(5回) 4本同時(8回) どちらに入るか ────────────────────────────────────────────────────────────────────── 動けなくなった 9 1〜5 2〜11 **4本同時だけ** 助けた 9 1〜5 2〜11 **4本同時だけ** ロボット分担 0.6456 0.6748〜0.7136 0.6359〜0.6942 **4本同時だけ** 店員が遅れて運んだ 73 59〜67 63〜75 **4本同時だけ** 入店待ち 3.004 1.584〜2.330 1.575〜3.046 **4本同時だけ** 人のあきらめ 63 23〜38 32〜51 どちらの外（上） 6つのうち5つで、エディタの値は **4本同時の幅の中・1本ずつの幅の外**でした。 つまり **エディタで回すのは「4本同時くらい忙しい」状態**ということです。 （エディタ自身が重いので、筋は通ります。） 人のあきらめだけは、4本同時の上（51）よりさらに上（63）でした。 この列は忙しさでは「はっきり違う」とは出なかった列なので、 同じ種でも揺れる幅が大きいのだと思います。断定はしません （エディタ側は1回しかないので）。 ここから出る結論 判定（judge_night）の基準データは **cs:7・エディタで測った18回**です。 夜を 1本ずつ（N=1）で回すと、止まる回数が減り・ロボット分担が上がるので、 判定が「基準と違う」と印を付けます。でもそれは **店が良くなったのではなく、Mac が空いていただけ**です。 → 基準データと並べるなら、夜も **N = 4** が合っています。 速さでも最良（49.5 回/時）なので、2つの決め方が同じ答えになります。 ==================================================================== 5. 夜の進め方（勧め） ==================================================================== ① **N = 4** で回す ・依頼の決め方（1時間に終わる回がいちばん多く、メモリが足りている）→ 4 ・基準データ（cs:7・エディタ）と忙しさが揃う → 4 ・メモリは 490 MB（16 GB のうち 3%）。CPU は 5.7 コア（8 のうち） ・1回 215 秒で、40 分の上限に遠く届かない ・70回の見込み **約 63 分**（エディタを閉じた実測から） ② **夜の途中で N を変えない** run_info.json の parallel に残るので、あとから確かめられます。 ③ **Unity エディタは閉じて回す** 閉じるだけで1回が 151 秒 → 115 秒（1本ずつ）になります。 ④ 判定を読むときの注意（報告書に残します） ・stuck_count・rescues・robot_share・late_staff_dishes の4列は **忙しさで動く列**です。夜どうしの比べ（③対⑦、ロボット 0/1/2 台、 すれ違い 入対切）は同じ N なので問題ありません。 ・基準データと並べるときも N=4 なら揃いますが、 「ぴったり同じ忙しさ」ではないので、この4列の小さな差は 店の違いだと決めつけないでください。 ・入店待ち・店員待ち・料理待ち・会計待ち・回転は忙しさに動かないので、 そのまま信じてよい列です。 ==================================================================== 6. 台帳 ==================================================================== 行数 87（退避版）→ **116**（足した 29 行） 退避版の86行 **そのまま** どの行も **59 列** status completed × 29 run_folder 重複なし 鍵 残っていない 名札ごと acheck 2 / bcheck 1 / c1check 3 / c2check 3 / c3check 3 / c4check 4 / **busy1 5 / busy4 8** 退避 archive/unity_ledger_v1_preacheck_20261026/unity_ledger_v1.csv 87 行・md5 4d8486b9f75e3bef8f130bad4ba3e6b5 確かめの 29 行は名札で分かれるので、夜の判定（{夜}_night_*）には入りません。 ==================================================================== 7. 次 ==================================================================== 1. 5 章 D：codex レビューの依頼文を作る 見てもらう所 … 台帳の鍵（ServiceSimLedger.TakeLock / Append）・ LedgerRow・night_runner.py の stopped / failed の行 2. 実行係を通した から回し（--dry-run）で 70 回の並びを確かめる 3. 最初の夜 70 回（台帳を archive/unity_ledger_v1_prenight_{夜}/ に写してから） cd /Users/shimazueiichi/Robotics_UX/ServiceSim python3 tools/make_queue.py --out queue.json \ --pass-by-extra fam_p1_s4_r2_a42 python3 tools/night_runner.py --queue queue.json --parallel 4 \ --night 20261027