# 夜も回せる仕組み 設計 v0（2026-10-25）

サービスロボット導入シミュレーションの Unity を、人が見ていない夜のあいだも回し続け、朝には結果が振り分けられている状態にする。

## 1. 決めたこと（2026-10-25・エイイチ）

| 項目 | 決めたこと |
|---|---|
| 区切り | 基準データ v2（段階B・cs:144 の18回・試算 v2.8）。ここで Unity の作りを固定し、夜の仕組みの答え合わせはここと比べる |
| 種の数 | 1条件あたり10個（種0〜9）。種によって入店待ちが8〜11倍ばらつき、3つでは向きが読めないため |
| 立ち往生 | ロボットが1回で30秒以上止まったら立ち往生として数える（判定だけの線。Unity の「動けなくなった」60秒の作りは変えない） |
| 試算とのずれ | 差の大きさは記録だけにする。印を付けるのは、基準データ v2 から外れたときと、ロボットを増やしたときの向きが種の過半数で試算と逆のとき |
| 終わる時刻 | 時刻で止めない。並べた回が全部終わるまで回す |
| Unity のプロジェクト | サービスロボット導入シミュレーションを、mechArm の Robotics_UX_New から新しいプロジェクトに分ける |
| ビルド設定 | 「新しいシーンはビルド設定に足さない」は、Claude Code が mechArm と同居させるために自分で付けた用心で、決まりではない。新しいプロジェクトでは当てはまらない |

元のデータ：KIOXIA `service_sim/unity/stageB_cs144/c3_judge_lines.py`・`c3_judge_lines_output.txt`

## 2. 流れ

```
並べる（queue.json：条件 × 種）
  ↓
夜の実行係 night_runner.py（Mac・Python）
  ├ KIOXIA がつながっているか確かめる。外れたら新しい回を始めない
  ├ Mac をスリープさせない（caffeinate）
  ├ 画面なしの実行ファイルを N 本同時に起動（1本 = 1条件 × 1種）
  └ 終わった回は飛ばす（途中で止まっても続きから）
        ↓
実行ファイル（-batchmode -nographics）
  ├ 段階Bと同じ作り・同じ1コマ0.05秒で1回回す
  ├ 出力フォルダ service_sim/unity/{日付}_{ラベル}_{版}_{条件}_s{種}/
  └ 台帳 unity_ledger_v1.csv に1行足す（同時に書かないよう鍵をかける）
        ↓
判定 judge_night.py（全部終わったら実行係が呼ぶ）
  └ service_sim/unity/night/{日付}/judge.md・judge.csv
        ↓
朝：judge.md を読む（人が見るのは「正常」以外だけ）
```

## 3. 判定の決まり（judge_night.py）

| 振り分け | 当たるとき | 単位 |
|---|---|---|
| 回の失敗 | 台帳に行がない／最後まで回っていない／全員が帰っていない／ロボットが1コマで0.05 m を超えて動いた | 1回ごと |
| Unity の作り | 次の数字の種の中央値が、基準データの同じ条件の最大を超えた：30秒以上の止まり（1往復あたり）・そのうちもう1台のロボットが原因のもの・動けなくなった（60秒）・卓を空けた・瞬間移動・打ち切り | 条件ごと |
| 試算を見直す候補 | 入店待ち・料理の待ち・席は空いているのに待った のどれかで、(1) ロボットを1台増やしたときの向きが種の過半数で試算と逆（基準データ v2 でも逆だったものは「既知」として分けて書く）、または (2) Unity÷試算 の種の中央値が、基準データの同じ条件の範囲から外れた | 条件ごと |
| 正常 | どれにも当たらない | |

- 向きは、5%か0.2分より小さい変化を「変わらない」として数えない
- 試算の版が基準と違う回を振り分けたときは、judge.md の頭に注意を出す
- 判定は台帳を書き換えない。台帳の列も増やさない

確かめ（2026-10-25）：基準データ v2 を自分自身にかけると18回とも「正常」。1つ前の cs:143 の18回にかけると、逃がし弁を直す前の「卓を空けた」の多さ（8〜25回、基準0〜4回）で18回とも「Unity の作り」に振り分けられた。

## 4. 基準データの入れ替え

基準データ v2 は種が3つしかない。最初の夜（③⑦ × ロボット0・1・2台 × 種0〜9 の60回）を v2 と比べ、「回の失敗」と「Unity の作り」がなければ、その60回を基準データ v3 にする（入れ替えはエイイチが決める）。以後の夜は v3 と比べる。

## 5. 作る順番

| 順 | 中身 | だれが | 依頼文 |
|---|---|---|---|
| 1 | 判定のスクリプト（judge_night_v0.py） | Claude | 済み（このフォルダ） |
| 2 | 新しいプロジェクトに移し、同じ結果が出るか確かめる | Claude Code | claude_code_request_v11_project_split.md |
| 3 | 画面なしの実行ファイル・夜の実行係・何本同時に回せるかの実測 | Claude Code | claude_code_request_v12_night_runner.md |
| 4 | 最初の夜（60回）→ 基準データ v3 | エイイチが1つのコマンドで始める | v12 の中 |
| 5 | ケースの型（店の形 × 機種 × 運用の決まり × 来客の波） | 決めることはエイイチ・作るのは Claude と Claude Code | 4 のあと |
| 6 | 次に回す条件を選ぶ仕組み（試算で境目を探し、Unity は境目だけ回す） | Claude と Claude Code | 5 のあと |

## 6. 置き場所

| もの | 場所 |
|---|---|
| 新しい Unity プロジェクト | `/Users/shimazueiichi/Robotics_UX/ServiceSim/`（Unity Version Control の新しいリポジトリ） |
| 夜の実行係・判定・並べる道具 | 新しいプロジェクトの `tools/`（プロジェクトと一緒に版を管理する） |
| 画面なしの実行ファイル | 新しいプロジェクトの `Builds/headless/`（VCS に入れない。作った版は build_info.json に残す） |
| 各回の出力・台帳 | KIOXIA `service_sim/unity/`（今までどおり） |
| 夜ごとの判定と実行の記録 | KIOXIA `service_sim/unity/night/{日付}/`（Unity の出力の行の中。新しい行は作らない） |

MASTER の「Unityの絶対ルール」の作業ディレクトリは Robotics_UX_New だけが書かれている。新しいプロジェクトの場所を足す必要がある（MASTER はエイイチが直す）。

## 7. 台帳（data_manifest_rules.md 10節）

- 新しいプロジェクトは changeset の番号が1から振り直されるので、`unity_cs` は `ServiceSim/cs:N` の形で書く（今までの `cs:144` などと混ざらない）
- 何本も同時に回すので、台帳に書くときは鍵ファイル `service_sim/unity/unity_ledger_v1.lock` で順番を守る
- 実行係が途中で止めた回（時間切れ・落ちた）は、実行係が status = stopped / failed の行を1行書く
- 列は増やさない。何本同時か・どの実行ファイルかは各回の run_info.json に書く