====================================================================
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
