====================================================================
最初の夜：70回・4本同時（night 20261027）の結果
2026-10-26 22:11 〜 23:25（1時間15分）／ServiceSim/cs:21
====================================================================

結論

  ・**70回ぜんぶ completed・終了コード 0**。止まった回・落ちた回・
    台帳に書けなかった回（終了コード 3）は **0 件**。
  ・台帳は 121 → 191 行（ちょうど70行）。**前の121行は 1 byte も変わらず**、
    70行すべて 59 列・ServiceSim/cs:21・run_folder の重複なし。鍵も残らず。
  ・runs.csv 70行・queue.json の写しも出ました。
  ・★ ただし **1回は数字として使えません**（③2台・すれ違い入・種0）。
    店が空にならず、中の時間の上限 720 分まで回りました。
    **台帳の status は completed** です（回し方としては終わったため）。
    判定が「全員が帰っていない」で拾っています。→ 4 章で相談。
  ・基準データ v3 にするのは **勧めます**（60回・10種）。ただし
    すれ違い「入」の10回は別扱いにしてください。→ 5 章。


====================================================================
1. 回し方と、始める前の確かめ
====================================================================

  実行ファイル  cs21_20261026_1739（ServiceSim/cs:21・保留 ''・ARM64）
  並び          種ごと（種0 の全7条件 → 種1 の全7条件 → …）
  同時本数      4（決めた N）
  Unity         閉じて回した
  KIOXIA        os.path.ismount True を確認してから開始

  台帳の退避（v12 5章D）
    archive/unity_ledger_v1_prenight_20261027/unity_ledger_v1.csv
    121 行・md5 bacc1e04ffe854c29d94da20343c59c6・cmp 一致（コピーのみ）

  1つ寄せたもの
    night/20261027/ に 10/26 の --dry-run のログが残っていたので、
    夜の記録と混ざらないよう runner_log_dryrun_20261026.txt に
    **改名して退けました**（消していません）。
    出力フォルダも台帳の行も 0 件だったので、夜の名前はそのままにしました。


====================================================================
2. 実時間と同時本数
====================================================================

  70回の実時間   平均 4.2 分 / 最短 3.3 分 / 最長 14.4 分
  全体           1時間15分（22:11 〜 23:25）
                 ※ 見込みは約63分。使えなかった1回が 14.4 分かかった分が主

  runs.csv の「起動したときの同時本数」
    1 本 … 1 回（立ち上がりの1本目）
    2 本 … 1 回
    3 本 … 2 回
    4 本 … **66 回**
  → 立ち上がりの3回を除き、ぜんぶ4本の中で回りました。
    並びを種ごとにしたので、薄かったのは種0 の最初の3条件
    （③0台・③1台・③2台）だけで、すれ違い入には当たっていません。

  ★ 「回っている間」に何本だったかは、runs.csv の開始・終了の時刻
    （started_mono / ended_mono）から正確に出せます。


====================================================================
3. 台帳の健全さ
====================================================================

  退避版 121 行 → いま 191 行（足した 70）
  退避版の行          **そのまま（1 byte も違わない）**
  足した70行          すべて **59 列**
  status              completed 70
  unity_cs            ServiceSim/cs:21 70
  run_folder の重複   なし
  すれ違い            入 10 回 / 切 60 回
  鍵                  残っていない

  v14 で入れた守りは、どれも発動しませんでした（発動する場面が起きなかった）。
  鍵の取り合いは4本の実行ファイルだけで、1回も待ちで失敗していません。


====================================================================
4. ★ 使えなかった1回（相談したいこと）
====================================================================

  20261027_night_cs21_fam_p1_r2_s0_passon
    （③ロボット2台・すれ違い「入」・種0）

    everyone_left   **False**（全員が帰っていない）
    total_minutes   **720.0001 分**（中の時間の上限まで回った）
    stopped_early   False
    実時間          14.4 分
    入店待ち        1.46 分（低い）
    動けなくなった   3 / あきらめた 29 / 卓を空けた 0

  同じ条件のほかの9種は 182〜222 分で全員帰っています。種0 だけ
  **720 分まで回って終わらなかった**ので、どこかで流れが止まったままに
  なったと見ています（入店待ちが低いので、客が溜まったわけではありません）。
  すれ違い「入」はエイイチが「標準は切のまま」と決めた側なので、
  **夜の標準の60回には影響しません**。

  ★ 相談：**台帳の status が completed になっています。**
    回し方としては最後まで回った（途中で止めていない）ので completed ですが、
    数字としては使えません。いまは判定だけが「全員が帰っていない」で拾います。

    直し方の案（どれも数の定義の変更なので、勝手には入れません）
      (ア) いまのまま。status は completed、判定で拾う
           → 台帳だけ見ると「70回成功」に見える
      (イ) everyone_left が false なら status を **unfinished** にする
           → 台帳だけで使える回が分かる。列は増えない（status の値が増える）
      (ウ) status は completed のまま、判定の「回の失敗」を
           台帳の行からも分かるようにする（列を足す）
           → 列を足すのは 10節の決まりで相談が要る

    私は **(イ)** を勧めます。「最後まで回った」と「数字が使える」は
    別のことなので、台帳の1列目近くで見分けられるほうが安全です。
    ただし過去の行の status は書き換えません（これからの回だけ）。


====================================================================
5. 判定（judge.md）と、基準データ v3 にするか
====================================================================

  判定の振り分け（基準は cs:7 の18回）

    正常                30 回
    試算を見直す候補      0 回
    Unity の作り         30 回
    回の失敗             1 回   ← 4 章のこれ
    基準なし             9 回   ← すれ違い「入」（基準に同じ条件が無い）

  「Unity の作り」の印は4つ（条件ごと・種の中央値が基準の最大を超えた）

    ③1台  30秒以上の止まり（1往復あたり） 0.203（基準 0.083〜0.182）
    ⑦1台  30秒以上の止まり（1往復あたり） 0.152（基準 0.075〜0.119）
    ⑦1台  動けなくなった（60秒）          6.5 （基準 3.0〜3.0）
    ⑦2台  瞬間移動                       69.0（基準 47.0〜59.0）

  ★ この印は **あまり強い証拠ではありません**。基準（cs:7）は
    **種が3つしかない**ので、幅が偶然狭く出ます。10種の幅と並べると：

    ③1台 動けなくなった   夜 中央 8  （幅 1〜14） ／ 基準 中央 4（幅 3〜9）
                          夜の10回のうち基準の最大を超えたのは 4 回
    ⑦1台 動けなくなった   夜 中央 6.5（幅 3〜15） ／ 基準 中央 3（幅 3〜3）
                          夜の10回のうち基準の最大を超えたのは 8 回
    ⑦2台 瞬間移動         夜 中央 69 （幅 47〜78）／ 基準 中央 57（幅 47〜59）
                          夜の10回のうち基準の最大を超えたのは 7 回

    「基準の幅 3〜3」のような所を超えたかどうかで判定しても、
    何も言えません。**10種の夜のほうが基準にふさわしい**です。

  夜（10種の中央値）と cs:7（3種の中央値）の並び

    条件        入店待ち          ロボット分担        動けなくなった      回転
    ─────────────────────────────────────────────────────────────────────
    ③0台       4.084（3.801）    0（0）            0（0）            10.74（10.74）
    ③1台       4.564（3.004）    0.675（0.701）    8（4）            5.272（6.949）
    ③2台       3.038（2.407）    0.930（0.908）    20.5（23）        5.07（6.214）
    ⑦0台       4.224（4.182）    0（0）            0（0）            11.4（11.47）
    ⑦1台       4.984（2.042）    0.691（0.709）    6.5（3）          21.5→6.813（5.599）
    ⑦2台       2.894（1.625）    0.939（0.893）    21.5（32）        4.135（5.11）
    ③2台・入   6.194（基準なし）  0.912             23                7.608
                （）内は cs:7

    ・**ロボット0台は基準とほぼ同じ**（③ 4.08 対 3.80／⑦ 4.22 対 4.18）。
      ロボットが居ない条件は再現できています。
    ・ロボット有りの入店待ちは夜のほうが大きく出ていますが、
      基準が3種しかないためと見ています（③1台 の cs:7 は
      種0〜2 が 1.40 / 3.00 / 11.99 分で、中央値 3.00 は偶然の位置）。
    ・ロボット分担はどれも基準に近い（差は 0.03 以内）。

  ★ 勧め：**基準データ v3 を、この夜の「すれ違い切」60回にする**。

      理由
        ・種が10個（基準の3個より散らばりを押さえられる）
        ・画面なし・4本同時で揃っている（これからの夜と同じ条件）
        ・cs:7 はエディタで測ったもの。busycheck で
          「エディタは4本同時くらい忙しい」と分かったので向きは近いが、
          測り方が違うものを基準に置き続ける理由がない
      扱い
        ・すれ違い「入」の10回は **基準に入れない**（標準は「切」）。
          使えない種0 を除いた9回を、別の比べ用に取っておく
        ・判定の既定（judge_night.py の BASELINE_DEFAULT）を
          20261027_night_cs21_* に替える。
          ただし glob が「入」も拾うので、切だけに絞る形にする必要がある
          → 判定側の直しが要ります（やりますか）

  「試算を見直す候補」は 0 件でした。
  記録として残っている Unity÷試算 で範囲から外れたのは2つだけです。
    ⑦1台 料理の待ち 1.24倍（基準 0.95〜1.22倍）
    ⑦2台 料理の待ち 1.40倍（基準 1.52〜1.57倍）


====================================================================
6. すれ違い 入 と 切（同じ夜・同じ条件・種の中央値）
====================================================================

  条件            入店待ち  料理の待ち  席は空いているのに待った  動けなくなった  あきらめた  ロボット分担
  ───────────────────────────────────────────────────────────────────────────
  ③2台（10回）     3.04     1.49      1.36                20.5        59.5     0.93
  ③2台・入（9回）   6.19     1.54      4.20                23.0        66.0     0.91

  10種で回しても、やはり **「入」は店全体が悪くなります**
  （入店待ち 3.04 → 6.19 分・席が空いているのに待った 1.36 → 4.20 分）。
  10/26 に1種で見たときと同じ向きで、種を10個にしても変わりませんでした。
  さらに「入」は10回のうち1回が **720 分まで終わらない**（4 章）。

  → 「標準は切のまま」というエイイチの判断は、10種でも裏づけられました。
    すれ違いの作り（cs:10 の①②③）は、入れても店は良くなりません。
    直すか・置いておくかは別途ご相談です。


====================================================================
7. 出たもの
====================================================================

  night/20261027/
    runner_log.txt                 … 夜の記録（70回ぶん）
    runs.csv                       … 70行・16列（開始・終了・単調時計つき）
    queue.json                     … 並べた回の写し
    logs/                          … 1回ごとの Unity のログ 70 本
    judge.csv / judge.md           … 判定
    runner_log_dryrun_20261026.txt … 10/26 の から回しのログ（退けたもの）

  20261027_night_cs21_*            … 70 フォルダ（1回ぶんの記録）
  unity_ledger_v1.csv              … 191 行
  archive/unity_ledger_v1_prenight_20261027/ … 夜の前の退避（121 行）


====================================================================
8. 次（相談したいこと3つ）
====================================================================

  1. 4 章：使えない回の status をどうするか（私の案は (イ) unfinished）
  2. 5 章：基準データ v3 をこの夜の「切」60回にするか。
     するなら judge_night.py の既定を替え、glob を「切」だけに絞る
  3. 6 章：すれ違いの作りを直すか、置いておくか

  そのほか、今夜のうちにできること
  ・使えなかった1回（③2台・入・種0）を、画面を出して1倍で見てみる
    （依頼 v13 の 依頼2 の SimHud が使えます）。
    720 分終わらない原因が目で見えるはずです。
  ・判定の「Unity の作り」の線を、基準の最小〜最大ではなく
    10種の分布（四分位など）で引き直す
