==================================================================== 最初の夜：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種の分布（四分位など）で引き直す