==================================================================== 依頼 v12 の 5 章 A・B・C：画面なしの実行ファイルの確かめ 2026-10-26 14:20　check-in：ServiceSim/cs:15・cs:16・cs:17（保留 0） ==================================================================== 結論 ・**A（台帳）OK**。2本同時で台帳にちょうど2行入り、行は混ざらず、 前の86行は 1 byte も変わりませんでした。鍵も残りません。 ・**B（画面なしでも同じか）合っていると見ます**。20 項目のうち **17 が cs:7 の帯の中**。外れた3つも帯の縁より「良い側」で、わずかです。 ・**C（何本同時か）→ N = 4 を勧めます**（49.5 回/時・70回に 85 分）。 CPU は 8 コアのうち 4.6 コアぶん、メモリは 400 MB（16 GB のうち）。 ・**画面なしは 3.4 倍速い**（1本 151 秒 対 エディタ 488〜612 秒）。 70回が1本ずつでも3時間で終わります。 ・確かめで台帳に **16 行**足しました（名札 acheck・bcheck・c1〜c4check）。 夜の回（{夜}_night_*）とは名札で分かれるので、判定には入りません。 ・★ 気になる並びを1つ見つけました（6 章）。**Mac が空いているほど 「詰まり」が減る**ように見えます。断定はできませんが、 夜の進め方に関わるので書きます。 ==================================================================== 0. 先にやったこと ==================================================================== 台帳の退避（依頼 5 章 D） /Volumes/KIOXIA/r2r2r-data/service_sim/unity/ archive/unity_ledger_v1_preacheck_20261026/unity_ledger_v1.csv 87 行（ヘッダ込み）・28,010 byte md5 4d8486b9f75e3bef8f130bad4ba3e6b5（元と退避で一致） cmp 1 byte も違わない ※ コピーのみ。元の台帳は動かしていません。 判定の差し替え（tools/judge_night.py ← iCloud の judge_night_v1.py） cmp で一致（md5 daf8987a596cb2e984d90e0ac3177e37）。中身は触っていません。 v0 から変わった所: ・基準データの既定を 20261025_stageB_cs7_* に（cs:144 の18回は使わない） ・条件のキーに pass_by（すれ違いの入切）を入れた ・出力フォルダが無い回（failed / stopped）も台帳の行から拾う ・やり直し（_try2）は1つにまとめる（最後まで回った方を使う） → 前の報告で「既知」として残していた4件のうち3件が、これで閉じました。 check-in：cs:16 Setup の保留（cs:15） シーンは **111 行足しただけ・消した行 0**。 SimHud show: 0 / realTimeSpeed: 0（初期値は切。測る回に効かない） HeadlessRun 参照8つ全部つながっている。layouts は StoreLayout_p1_efficient_corner と StoreLayout_p5_crammed RobotSpec は cs:10 の3項目が既定値で書き出されただけ（3行）。 passByNeedPersonM: 0.4 / passByBackOffM: 0.6 / passByBackSpeedMps: 0.3 **passByEnabled: 0 はそのまま**（すれ違いは「切」）。 ほか8本（ExperimentPlan・PeopleSpec・ServiceSpec・Mat 3本・StoreLayout 2本）は Setup が書き直しただけで、cs:14 と **1字も違いません**（差分なしを確認）。 ★ 実行ファイルの不具合を2つ見つけて直しました（cs:17） 実物を1回動かしてすぐ出ました。Unity 抜きの確かめでは出ない種類です。 ① **player では SimParams.Load を誰も呼んでいなかった** 条件（unity_conditions）が空のままなので、正しい条件を渡しても 「知らない条件です」で終了コード 1 になっていました。 読んだ中身は .asset に残らない作りなので、起動のたびに読む必要があります。 段階Bの LoadParams と同じ sp.Load("") を HeadlessRun で呼ぶようにしました。 そのあと ExperimentRunner が店の形の版で読み直すので、 終わったあとは条件を名前で引き直しています（値は同じ JSON から来ます）。 ② 合わない値で回さずに抜けたとき（AbortRun）、player では 180 秒待ってからしか失敗になりませんでした。 ExperimentRunner に Aborted を足し（AbortRun で立てるだけ。 エディタの動きは変えていない）、すぐ終了コード 1 にします。 使った実行ファイル build_id cs17_20261026_1347 unity_cs ServiceSim/cs:17 pending_changes （空）＝保留 0 で作られている architecture ARM64（Apple Silicon）… 反射で入る所もきちんと効きました editor_version 2022.3.62f3 total_size 60.1 MB / 作るのに 2.1 秒 ==================================================================== 1. A：台帳に2行がきちんと入るか（③1台・種1 と 種2 を 2本同時） ==================================================================== 押したもの（1本 = 1回。実行係なしで直に起動） ServiceSim -batchmode -nographics -logFile … \ -ssCondition fam_p1_s4_r1_a42 -ssSeed 1 -ssLabel acheck \ -ssNight 20261026 -ssParallel 2 （種2 も同時に） 結果 終了コード 2本とも **0** 出力フォルダ 20261026_acheck_cs17_fam_p1_r1_s1 20261026_acheck_cs17_fam_p1_r1_s2 台帳の行 87 → **89 行**（ちょうど2行） status 2行とも completed unity_cs 2行とも ServiceSim/cs:17 列の数 2行とも **59 列**（行が混ざっていない） ヘッダ 退避版と **同一** 前の86行 **1 byte も変わっていない** 鍵ファイル 残っていない ★ 依頼の「店の中の時間30分で止める短い1回」は、ExperimentPlan を 一時的に書き換えることになるので、**丸ごと1回**で代わりにしました。 そのほうが B の比べる相手にもなるので、無駄がありません。 丸ごと回しても、2本同時で 151 秒・177 秒しかかかりませんでした。 最後まで回ったことの確かめ everyone_left 2本とも 1（全員帰った） total_minutes 183.3 分（種1）/ 208.7 分（種2） ← エディタ cs:7 の 182.2 / 206.7 分とほぼ同じ つまり「速く終わった」のは中身を省いたからではなく、 画面を作らない・Editor の重みが無いぶん速いだけです。 ★ 16回ぜんぶ足し終わったあとの台帳（最終確認） 行数 87 → **103**（足した 16 行） どの行も **59 列** status completed × 16 unity_cs ServiceSim/cs:17 × 16 run_folder 重複なし 退避版の86行 **そのまま（1 byte も違わない）** 鍵 残っていない 名札ごと acheck 2 / bcheck 1 / c1check 3 / c2check 3 / c3check 3 / c4check 4 4本同時のときの行の並びは s0 → s3 → s1 → s2 で、**終わった順**です。 鍵が順番に渡っている証拠で、狙いどおりです。 ==================================================================== 2. B：画面なしでも同じ結果か（③1台・種1） ==================================================================== 比べ方（エイイチの指示どおり） 同じ種でも揺れるので、**数字の一致ではなく cs:7 の同じ条件の近くに 入るか**で見ます。cs:7 の ③1台 は種0〜2 で 入店待ち 1.40 / 3.00 / 11.99 分 ← 種による差がこれだけ大きい 店員待ち 0.16 / 1.76 / 5.41 分 結果（画面なしを1本だけで回した回。acheck の2本同時も並べます） 項目 エディタ種1 画面なし 画面なし cs:7 種0〜2 (cs:7) 1本(B) 2本同時(A) の幅 ─────────────────────────────────────────────────────────────────── 入店待ち（分） 3.004 1.711 2.587 1.4〜12.0 帯の中 店員待ち（分） 1.758 0.468 1.351 0.16〜5.41 帯の中 料理待ち（分） 2.849 2.249 2.563 1.97〜2.85 帯の中 冷めた割合 0.413 0.248 0.316 0.175〜0.413 帯の中 ロボット分担 0.646 0.709 0.641 0.646〜0.825 帯の中 店員の忙しさ 0.772 0.721 0.768 0.579〜0.800 帯の中 ロボットの忙しさ 0.701 0.695 0.739 0.701〜0.803 ★0.006 下 店員の歩き km 2.646 2.642 2.630 2.16〜3.18 帯の中 会計待ち（分） 5.277 5.966 4.889 2.54〜6.48 帯の中 卓が空くまで（分） 1.452 0.091 1.051 0〜5.16 帯の中 回転（分） 6.949 4.355 8.098 2.90〜7.35 帯の中 卓を空けた 0 0 0 0〜0 帯の中 人のあきらめ 63 26 57 36〜63 ★10 下 動けなくなった 9 0 12 3〜9 ★3 下 往復 66 74 66 66〜84 帯の中 時間切れ 1 0 0 0〜1 帯の中 店の中（分） 182.2 182.2 183.3 174〜207 帯の中 全員帰った 1 1 1 1〜1 帯の中 片付け待ち（秒） 279.1 123.1 339.6 27.9〜308 帯の中 会計待ち仕事（秒） 177.3 166.5 144.1 99.2〜177 帯の中 見立て：**合っていると見ます。** 20 項目のうち 17 が帯の中。外れた3つは ロボットの忙しさ 帯の下端より 0.006 低いだけ（誤差の域） 人のあきらめ 帯の下端より 10 低い（＝良い側） 動けなくなった 帯の下端より 3 低い（＝良い側） どれも「悪くなった」方向ではありません。 店の中の時間（182.2 分）は **エディタと小数第1位まで一致**、 店員の歩き km も 2.642 対 2.646 でほぼ同じです。 通し番号（往復 74 対 66）は、同じ種でも揺れる所です。 ★ ただし 6 章の並びがあるので、「画面なしだから同じ」と言い切るのは まだ早いと思います。 ==================================================================== 3. C：何本同時に回せるか（③2台・fam_p1・種0〜2） ==================================================================== Mac 8 コア（高性能 6＋高効率 2）・メモリ 16 GB ★ 測っている間、**Unity エディタは開いたまま**でした。 夜は閉じるので、本番はこれより余裕があります。 結果 同時 回数 1回の平均 束が終わるまで 1時間に終わる数 70回の見込み rc ────────────────────────────────────────────────────────────────── 1本 3 151 秒 454 秒（3回） 23.8 回/時 177 分 0 2本 3 187 秒 186 秒（2回） 38.6 回/時 109 分 0 3本 3 220 秒 248 秒（3回） 43.5 回/時 96 分 0 4本 4 262 秒 291 秒（4回） 49.5 回/時 85 分 0 1本を基準にした伸び 2本 … 1.63 倍（1回の実時間は 1.23 倍に伸びる） 3本 … 1.83 倍（1回の実時間は 1.45 倍に伸びる） 4本 … 2.08 倍（1回の実時間は 1.73 倍に伸びる） CPU とメモリ（回している間の山） 同時 CPU（8コア＝800%） メモリ（RSS 合計） load1 ───────────────────────────────────────────────────── 1本 約 145%（1.5 コア） 約 100 MB 6〜11 2本 約 270%（2.7 コア） 約 195 MB 15〜19 3本 約 380%（3.8 コア） 約 290 MB 12〜40 4本 約 458%（4.6 コア） 約 400 MB 21〜22 ・メモリは **まったく問題ありません**（4本でも 400 MB。16 GB のうち 2.5%）。 ・CPU も 4本で 4.6 コアぶん。8 コアのうち 3.4 コア空いています （この空きで Unity エディタが動いていました）。 ・load1 が大きく出ますが、これは Unity の糸（スレッド）の数が そのまま乗るためで、詰まっているという意味ではありません。 1回の実時間が 40 分の上限（2400 秒）に遠く届かない（最長 291 秒）ので、 詰まりの心配はありません。 決めた N 依頼の決め方（1時間に終わる回の数がいちばん多く、メモリが足りている本数） では **N = 4** です。49.5 回/時・70回に 85 分。 ★ ただし、速さで選ぶ意味はほとんどありません。 70回は **1本ずつでも3時間**で終わり、夜は時刻で止めない決まり （並べた回が全部終わるまで回す）なので、 4本（85 分）と 2本（109 分）の差は **24 分**しかありません。 6 章の心配があるので、迷うなら少ない方が安全です。 私の案：**N = 4 で始める**（依頼の決め方どおり）。 run_info.json に parallel が入るので、あとで 「同時本数と数字に関係があったか」を台帳から確かめられます。 もし 6 章の心配をいま潰しておきたいなら、**N = 2** にしてください （夜が 24 分長くなるだけです）。 ==================================================================== 4. まだ確かめていないこと ==================================================================== ・⑦（fam_p5）での実時間は測っていません（依頼は ③2台 を指定）。 ⑦ は通路が狭く重いので、1回がもう少し長くなる見込みです。 4本同時でも 40 分の上限には遠いので、問題にはならないと思います。 ・夜の実行係（night_runner.py）を通した起動はまだです（直に起動して測りました）。 実行係の引数の組み方は、実物の引数列と突き合わせて確かめてあります。 ・stopped（途中で止まった）回・failed の回の台帳の行は、まだ実物で出していません。 5 章 D の codex レビューで、この道を重点的に見てもらうのがよいと思います。 ==================================================================== 5. 直したあとの check-in ==================================================================== cs:15 Setup でシーンに SimHud と HeadlessRun を入れた（.meta 4件も） cs:16 判定を judge_night_v1.py に差し替えた cs:17 画面なしの実行で見つかった2件を直した（SimParams.Load・Aborted） いまの保留 0。使った実行ファイルは cs:17（保留 0）で作ったものです。 ==================================================================== 6. ★ 気になる並び：Mac が空いているほど「詰まり」が減る ==================================================================== 同じ種1・同じ条件（③1台）で、こうなりました。 回し方 動けなくなった 人のあきらめ ──────────────────────────────────────────────── 画面なし・1本だけ 0 26 画面なし・2本同時 12 57 エディタ（cs:7） 9 63 ③2台 でも、同じ向きが見えます（種ごと・1本 → 2本 → 3本）。 種0 動けなくなった 22 → 35 → 31 ／ 人のあきらめ 47 → 64 → 59 種1 動けなくなった 27 → 20 → 40 ／ 人のあきらめ 49 → 82 → 47 種2 動けなくなった 42 → 37 → 61 ／ 人のあきらめ 109 → 87 → 94 筋は通ります。10/25 の切り分けで、最後まで消えなかった容疑が 「NavMeshAgent の動きが Unity の job（並列の仕事）で動いている」でした。 job の割り振りは **Mac の忙しさで変わる**ので、同時に何本走らせるかで 数字がずれる、という説明になります。 ★ ただし、これは断定できません。 ・各マスが1回ずつです ・同じ種でもずれることは 10/25 に分かっています （③1台・種1 で 958.76 秒 と 1527.18 秒） ・③2台 の並びは種1 で逆を向いています（27 → 20 → 40） つまり、既知のばらつきと見分けがつきません。 夜への効き方（ここは落ち着いて考えられます） 夜の70回は **お互いを比べる**ものです（③ 対 ⑦、ロボット 0/1/2 台、 すれ違い 入 対 切）。全部を同じ N で回せば、忙しさの効果は どの条件にも同じように乗るので、**比べる分には消えます**。 cs:7 との比較は二の次です（cs:7 はエディタで測ったものなので、 N をどうしても画面なしとは条件が違います）。 なので私の勧めは ① **N を夜の途中で変えない**（いまのコードは run_info.json の parallel に残すので、あとから確かめられます） ② 夜は **Unity エディタを閉じる**（忙しさの元を1つ減らす） ③ 比べるのは **種10個の中央値**（9/25 に決めたとおり） はっきりさせたいときの確かめ（やるなら 15 分ほど） 同じ条件・同じ種を **1本ずつ 5 回** と **4本同時で 5 回** 回して、 分布（中央値と幅）を比べる。重なれば忙しさは効いていない、 ずれれば効いている、と分かります。台帳に 10 行増えます。 やりますか。 ==================================================================== 7. 次（順に） ==================================================================== 1. N を決める（私の案は 4。6 章が気になるなら 2） 2. 6 章の確かめ（やるかどうか。1本×5回 と 4本×5回） 3. 5 章 D：codex レビューの依頼文を私が作る 見てもらう所 … 台帳の鍵（ServiceSimLedger.TakeLock / Append）・ LedgerRow・night_runner.py の stopped / failed の行 4. 夜の実行係を通した から回し（--dry-run）で70回の並びを確かめる 5. 最初の夜 70 回 （台帳を archive/unity_ledger_v1_prenight_{夜}/ に写してから） 最初の夜のコマンド（いまのところ。N は決まり次第） 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 確かめで台帳に足した 16 行（名札 acheck・bcheck・c1〜c4check）は、 夜の回（20261027_night_*）とは名札で分かれるので、判定には入りません。