---
title: "サービスロボット導入シミュレーション Log#32 | 配膳ロボットのシミュレーションから瞬間移動が消えた"
slug: serving-robot-sim-teleport-zero
date: 2026-11-03
day: 435
meta_description: "Unity で再現したファミレス6店・180回の配膳ロボットのシミュレーションで、瞬間移動を0回にし、同じ条件なら毎回同じ結果が出るようにした。解けずに残る詰まりは21回から2回に、1回の計算は3〜4分から1.2〜1.5分になった。"
tags: [サービスロボット導入シミュレーション, 配膳ロボット, 飲食店, ファミレス, Unity, シミュレーション, 再現性, 群衆ナビゲーション]
series: "導入シミュレーション"
---
Unity で再現したファミレス6店・180回の配膳ロボットのシミュレーションで、お客さんやロボットが一瞬で別の場所へ飛ぶ「瞬間移動」を0回にし、同じ条件で回せば毎回まったく同じ結果が出るようにした。**現実の店に瞬間移動はないので、詰まりはスタッフが歩いて行ってロボットを押して解く形に変え、解けずに残る詰まりは21回から2回まで減った。** ただ、ロボットが1.4cmの幅を行ったり来たりし続けて助けを呼ばない、という新しい形の詰まりが1つ残っている。
この回で、シミュレーションの数字を信じてよい理由が2つ増えました。
- 直す前と直したあとを、同じ条件で比べられるようになった。前は同じ種（乱数の出発点。同じなら同じお客さんの来方になる）で2回回しても、動けなくなったロボットが12回と0回に分かれるほど揺れていて、数字の差が直しのせいなのか偶然なのか言えなかった。今は12組とも記録が1行も違わない
- 現実にない動きで数字をごまかさなくなった。③⑦の店でロボット2台のとき、1回の営業で66回あった瞬間移動が0回になった。詰まったときは、スタッフが歩いて行って、人の歩く速さより遅い0.5m/秒でロボットを押す
- 1回の計算が速くなった。同じ種で同じ結果にする作りにしたら、1回の営業の計算が3〜4分から1.2〜1.5分に縮んだ（同じ Mac・同じ店で測った値）。6店180回を約1時間で回せる
そのうえで、依頼が終わるたびに1分ほどの報告動画を作るようにし、サイトに出す動画は、録画の横に店の様子のパネルを付けた形にそろえました。
もともとの困りごとは、Unity の数字がよくなったように見えても、信じてよいのか分からなかったことです。同じ店・同じ条件で回し直すと結果が大きく変わり、しかも詰まったお客さんは一瞬で席に戻され、詰まったロボットは一瞬で横へ置き直されていました。止まり方を数字にしたいのに、いちばん大事な詰まりの場面を、現実にない動きで消していたことになります。
| やったこと | なぜ | 結果 |
|---|---|---|
| 同じ種なら同じ結果が出るようにした（依頼77〜79c） | 直す前と後の差が、直しのせいか偶然か言えなかったため | 12組とも記録が1行も違わない。1回の計算 3〜4分 → 1.2〜1.5分 |
| 瞬間移動をなくした（依頼80〜82） | 現実の店に瞬間移動はないため | ③⑦ロボット2台で 66回 → 0回。助けはスタッフが歩いて押す |
| 6店180回でベースのデータを取った（依頼83） | 店ごとに、ロボットを足したときの向きが試算と合うかを見るため | 瞬間移動0。向きは12本中10本が試算と同じ。解けない詰まりが21回残った |
| 解けない詰まりを3つ直し、180回を回し直した（依頼84） | ④の入口近く・トイレ前・料理の記録の閉じ忘れが残ったため | 解けない詰まり 21回 → 2回。全員が帰らなかった回 6回 → 1回 |
| 報告動画とパネル付き動画の形を決めた | 何が変わって何が良くなかったか、最初の人にも分かるようにするため | 依頼ごとに1分ほどの動画。サイトの動画は1つの形に固定 |
配膳ロボットを自分の店に入れたらどうなるかは、このシリーズの試算をもとにした別のページで試せます。
【バナー】serving-robot-one-less-staff
## 作業ログ ― 人混みを進むロボットの動画から、動きを部品に分ける考えを決めた
始まりは、X に流れてきた研究室の実験の動画でした。人が歩き回る部屋で、小さな車輪のロボットがゴールまでの道を何度も引き直しながら進む。灰色のフーディの人のまわりだけ大きく回り込んでいます（投稿 https://x.com/clankrmedia/status/2116955134815047899 ）。
ここで使う言葉を先に置いておきます。人混みの中でロボットが道を選ぶ研究は「群衆ナビゲーション（crowd navigation）」と呼ばれます。人の今の位置と速さから少し先を読んで、ぶつからない道を毎回作り直すのが基本の形です。Unity の中の人は [NavMeshAgent](https://docs.unity3d.com/ScriptReference/AI.NavMeshAgent.html)（Unity が用意している、地図の上を歩かせる部品）で歩いていて、近くの人やロボットをよける動き（局所回避）も Unity が計算しています。
この動画を見て出てきた希望が、部品に分ける考えの始まりです。
> 経路探索の機能は追加できたり、アップデート出来たり、追加学習データを組み込めたりなど出来るといいよね。シミュレーションの価値があがるし。
今の Unity のコードは、ロボットの1コマごとの動き（センサーで前を見る・譲る・速さを決める・止まりを記録する）が、ServingRobotController.cs という3,661行の1つのファイルの中に混ざっています。人の動きも同じで、よけ方を差し替えたくても、どこを替えればよいかが決まっていません。そこで、店・条件・種・記録・サイトの決まりを「本体」、ロボットの道の選び方と人の動き方を「部品」として分ける設計を、Claude Docs の文書「ServiceSim 動きの部品の設計」にまとめました。決めたことは次のとおりです。
- 部品の入り口と出口をそろえる。どの部品でも、受け取るもの（今の位置・速さ・近くの人とロボット・行き先）と返すもの（次に進む向きと速さ・状態の名前）を同じにする。状態の名前は、止まりの原因を記録するのに使う
- 譲る順番（ロボット＞スタッフ＞お客さん）は今のままにする。部品はこの順番に従う。順番そのものを変えるかは、あとで決める
- 人どうしのよけ合いも、人の部品に入れる
- 最初に挿すのは人の部品。今の動きをそのまま部品の形に移し、中身を変えていないことを、同じ種の記録が1行も違わないことで確かめる
研究室の動画をメモにしたときの全文です（research フォルダ）。
#### research_crowd_navigation_lab_video_20261102.md（動画メモの全文）
````markdown
# 人混みの中を進むロボットの経路計画（研究室の実験）— 動画メモ
見た日：2026-11-02
元：X の投稿（投稿者 @clankrmedia、2026-11-02 3:06 の投稿、2.3万回表示）。エイイチの画面のスクリーンショット8枚で確認した。動画そのものは見ていない
場所・機体：大学か企業の研究室の広い部屋（推定）。天井に動きを測るカメラが並び、歩く人は目印付きの帽子をかぶっている。ロボットは小型の車輪型（TurtleBot に似た形。推定）
※ 投稿の本文に出典（どこの研究室・どの論文か）は書かれていない（2026-11-03 にブラウザで投稿を開いて確認。動画は18秒）。投稿者は他所の動画を紹介するまとめの発信者に見える。動画そのものは見ていないので秒数は測れない
## 一言で
人が歩き回る部屋の中で、ロボットがゴールまでの道を引き直し続ける実験。灰色のフーディの女性のまわりだけ大きく回り込んでいて、人によって空ける距離を変えているように見える。ロボットは自分のセンサーではなく、天井のカメラから全員の位置をもらっている可能性が高い。
## タイムライン（スクリーンショットの順）
| 画面 | 起きていること |
|---|---|
| 1 | ゴール（緑）へ向かう青い道。人が3〜4人歩いていて、足元に青い円が付いている |
| 2 | 灰色のフーディの女性がロボットの真横に来る。青い道は消えている（引き直している途中に見える） |
| 3 | 女性がロボットの前をふさぐ。青い道は右の壁ぞいへ大きく回り込む形に変わる |
| 4 | 人がよけると、道はまたゴールへまっすぐに近い形に戻る |
## 数字
- 測れない。動画を見ていないため
- 画面の凡例は3つ：選んだ道（Chosen plan）、ゴール（Goal）、人（Human）
## 読み取れること
1. ロボットは人の位置を全部知っている。天井のカメラと帽子の目印で、部屋の全員の位置を測っている。人混みで全員を追うには、ロボットに載せたセンサーだけでは足りず外のセンサーを使うことが多い、と論文でも書かれている
2. 道は人が動くたびに引き直される。決まった線をなぞるのではなく、毎回いまの人の位置から道を作り直している
3. 人によって空ける距離が違うように見える。女性のまわりは大回り、ほかの人の横は比較的近くを通る。人の向きや速さを見て、これから進む先を避けている可能性がある（推測）
4. 部屋が広い。壁ぞいへ大回りできる余裕がある。店の通路（80〜95cm）ではこの回り込み方はできない
5. 返信では、遠くまでの道を引くだけで、近くの障害物をよける動きはしていないのでは、という指摘がある（科技魔法羊）。真偽は確かめていない
6. ほかの返信に、速さを変えて同じ目的を果たすことができていない（neurofiber）、ずっと動き続けるのはなぜか、人なら止まって相手を先に通してから動く（prathamesh joshi）という指摘がある。道を変えるだけで、止まって待つ・ゆっくりにする、という選び方をしていないように見える、という見方。店の通路では回り込みの幅がないので、この止まって待つ・速さを落とす方がむしろ大事
## 運用の落とし所（このメモでの見立て）
店で使えるのは、通路の中でよける動きよりも、その手前で入る通路を選び直すところ。店員がこちらへ向かってくる通路には、最初から入らない。人の先読みは凝ったものでなくてよく、今の速さのまま2〜3秒進むと仮定するだけの予測が、深層学習の予測を上回ったという報告もある。
ただし注意が1つある。この種の方法は、ロボットの動きが人の動きに影響しないと仮定している。店では店員がロボットをよけるので、先読みを入れると、よけてくれる人まで避けて遠回りや待ちが増えるおそれがある。
## 導入シミュレーション（ServiceSim）の前提との突き合わせ
記録だけ。サイトの試算と Unity は変えない。
| 前提 | 動画で見えたこと | ずれ |
|---|---|---|
| 前がふさがって3秒空かなければ回り込む道を探す | 人が動くたびに、ふさがる前から道を引き直している | 今の Unity は待ってから探す。動画は先に避ける |
| 人の位置は Unity の中で全部わかる | ロボットは天井のカメラから全員の位置をもらっている | 条件が同じ。Unity で試しやすい |
| 通路の最低ラインは80cm（BellaBot の公表値の最小通過幅は70cm） | 広い部屋で大きく回り込む | 店ではこの回り込みの幅がない |
| 店員は必ずロボットをよける | 実験の人がロボットをよけているかは画面から分からない | 先読みを入れると、よける人まで避ける二重の遠慮になるおそれ |
| Unity の人は半径0.2mの円柱。人どうしで1秒詰まると横を向いて半径0.12mに細くなる（JamWatcher）。ロボットの横では0.3m空け、客が横を詰めて通るときだけ0.1mまで寄る（2026-11-03 に ServiceSim のコードで確認） | 実物の人は横向きで体の幅を半分近くにでき、ギリギリまで寄れる | 横向きは人どうしのときだけ。ロボットのそばでは横を向かず、0.1〜0.3m空ける。ロボットの横のすり抜けは実際より詰まりやすく出ている可能性 |
## エイイチの見立て（2026-11-02〜03 の会話から）
- 配膳ロボットやハコブくんに活かしたい
- 店は人を中心に作られていて、ロボットの余裕ある距離感は考えて作られていない。人はギリギリまで寄れるうえ、横向きになって動けるので、かなり狭い所でも通れる前提になっている
- 道の選び方は、あとから足したり、更新したり、学習し直したデータを組み込めたりできるとよい。そうなるとシミュレーションの価値が上がる
## 配膳ロボットが壁や机にどこまで近づけるか（公表値）
| 機体 | 本体の幅 | 通れる最小の通路幅 | 片側の余裕 |
|---|---|---|---|
| Servi Q（ソフトバンクロボティクス、2026-09 発売） | 35cm | 45cm | 約5cm |
| BellaBot（PUDU） | 56.5cm（奥行き53.7cm） | 70cm | 約7cm |
| Keenbot T8 アイリスエディション | — | 55cm | — |
どれも動かない壁がまっすぐ続く場合の限界。食事中に引かれた椅子や床の荷物があると、この余裕はすぐなくなる。ソフトバンクロボティクスは Servi Q を、ロボットに店を合わせるのではなく、ロボットが店に合わせることを目指したと説明している。
## Pixels to Motors との関係
- ServiceSim：ロボットの道の選び方と人の動き方を、差し替えられる部品にする考え。店の形・条件・乱数の種・計測は固定し、部品だけ入れ替えて夜に比べる。最初は今の動きのまま挿すので結果は変わらない。そのうえで、先読みする方式、学習させた方式、横向きですり抜ける人などを挿して比べる。どの部品も受け取るもの（地図・自分の位置・周りの人とロボットの位置・行き先）と返すもの（次にどこへどの速さで動くか）を同じにしておけば、メーカーが自社の方式を持ち込んで同じ店で比べることもできる。Mission の再現可能な環境と同じ向き
- ハコブくん：病院の廊下で、点滴スタンドを押す人・車いす・歩行器の人には広く、急ぐ看護師にはふつうに空ける、という人ごとの距離の決め方が体験の設計になる。進む道を床に映して周りに見せる見せ方もありうる。気を遣いすぎて届かないハコブくんは4コマのネタ候補
## 次に確かめる候補
- 投稿の出典（研究室・論文）。本文には書かれていないので、引用の投稿や動画の元を探す必要がある
- ロボットのそばでも横を向いて寄れるようにしたとき、止まりと立ち往生がどれだけ変わるか
- 食事中に椅子が引かれて通路が狭くなる状態を Unity に入れたときの止まりの変化
## 参考
- 予測してから計画する枠組みとその限界：https://arxiv.org/pdf/2403.01537
- 予測と計画を組み合わせて固まる問題を避ける：https://arxiv.org/pdf/2309.16838
- 外のセンサーで人を追う話：https://iris.polito.it/retrieve/handle/11583/2650938/137143
- BellaBot の仕様（最小通過幅70cm・565×537×1290mm）：https://www.kwcommercial.com.au/?p=41054
- Servi Q（幅35cm・最小通過幅45cm）：https://www.watch.impress.co.jp/docs/news/2143854.html
- Keenbot T8（最小55cm）：https://www.irisohyama.co.jp/news/2023/amp/?date=0221
## 検索キーワード
人混み 経路計画 群衆ナビゲーション crowd navigation 先読み 人の動きの予測 引き直し 回り込み 天井カメラ モーションキャプチャ 通路幅 最小通過幅 Servi Q BellaBot Keenbot 横向き すり抜け 部品の差し替え ServiceSim ハコブくん
````
このメモの見立てで、店にそのまま使えないと分かったこともあります。動画の部屋は広く、壁ぞいへ大回りできます。店の通路は80〜95cmで、回り込む幅がありません。人はぎりぎりまで寄れ、体を横にすれば狭い所も通れるので、店は人を基準に作られていて、ロボットの余裕は考えられていません。店で大事なのは、通路の中でよけることより、入る前に通路を選び直すこと、止まって待つこと、速さを落とすことです。
Unity の人についても、ここで1つ言い直しがありました。最初は「Unity の人は丸い筒のまま」と説明しましたが、コードを読むと、人どうしが詰まったときは体の半径を0.2mから0.12mに細くして（JamWatcher.cs）横向きにすり抜ける形が、すでに入っていました。
部品の切り出しは、依頼76が終わってから始める予定でした。ところが、その前に土台のほうに問題が見つかります。
## 作業ログ ― 依頼76：立ち往生の助けを入れたら、同じ所で何度も助けが要った
LOG434 の最後に、2台のロボットが30秒動けなければスタッフが助けに来る作りを入れる依頼76を置きました。依頼箱（Mac の見張り係が、置かれた依頼を Claude Code に順に渡す仕組み）に置いた依頼で、夜に180回の基準データを取り直すつもりでした。
結果は、確かめの1回で止まりました。⑦の店で、前に約9分止まっていた向かい合いは助け2回・約105秒で解けました。ところが、往復を終えて止まっている2号機に1号機が阻まれ、同じ所で8回ずつ助けが要る場面が2か所出ました。助けに行ったスタッフが詰まり、3回目に一瞬で移されて解ける場面もありました。
#### 20261103_76_直した版で基準データを取り直す.md（依頼76 の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 720
---
# 依頼76：瞬間移動を直した版で、6店の基準データを取り直す（依頼75 の後・夜）
エイイチと決めたこと（2026-11-03）：瞬間移動の直し（依頼74）で客の動きが変わったので、6店の基準データを取り直す。
**エイイチは寝ている。人に聞かないと進めない所に当たったら、その回は止めて報告に書き、ほかの回は続ける。時刻で止めず、並べた回が全部終わるまで回す。**
## 0. 回す前に入れること：立ち往生をスタッフが解く（2026-11-03 エイイチと決めた・Claude が後から足した）
基準データを取り直す前に、これを今の標準に入れる。入れてから下の 180 回を回す（入れないまま取り直すと、すぐ取り直しになるため）。
**いま起きていること**：2台のロボットが向かい合うと、どちらも相手を待ち、誰も解かない。20261102 の夜の⑦（fam_p5・種7）では、店の時刻 1472〜2022 秒のあいだ (20.4, 5.0) 付近で1号機と2号機が約9分止まり、最後は料理の打ち切り（requeues.csv・600 秒）でやっと動いた。そのあいだ料理を運ぼうとしたスタッフも3回あきらめた（give_ups.csv）。stops.csv では 60 秒ごとに「動けなくなった」が並ぶだけで、助けが来ていない。
**入れる決まり**（試算の立ち往生と同じ扱い。サイトの tools/serving_sim/haizen_sim.py の maybe_stop・assumptions.json の rescue_s）：
- ロボットが **30 秒以上** 動けなかったら（今の立ち往生の判定の線と同じ）、スタッフ1人が助けに行く。人と向かい合った場合も、ロボットどうしの場合も同じ
- 助けは **いちばん優先の高い仕事**（試算の staff_job の priority 0 と同じ）。いま手が空いているスタッフのうち近い人が行く。全員ふさがっていれば、今の仕事が終わった人から行く（待った時間も記録する）
- スタッフは歩いて行き、着いてから **15 秒**（試算の rescue_s・決まりの値。変えない）でロボットを動かす。動かすのは片方だけ
- ロボットどうしなら、動かすのは **空の方**（料理を載せていない方）。どちらも同じなら、行き先までまだ遠い方。人とロボットならロボットを動かす
- 動かした先は、相手の道（いま引いている道）から外れた、いちばん近くの空いた所。動かされたロボットはそこで道を引き直して仕事を続ける
- 作りは切り替えで入れ、**入を標準**にする（切にすると今までどおり）。ラベルなどへの載せ方は今までの切り替えと同じでよい
**記録**：回のフォルダに rescues.csv（いつ・どこで・どのロボット・相手は何か・行ったスタッフ・手が空くまで待った秒・歩いた m・解けるまでの秒）。summary.json に rescues（回数）と rescue_staff_s（スタッフが助けに使った秒の合計）。試算の meta.metrics.rescues と同じ意味にする。モニターに「助けに行く」を出す。
**確かめ**：⑦（fam_p5・種7・ロボット2台）を1回回し、30 秒以上の向かい合いが 30 秒＋スタッフが着くまで＋15 秒で解けることを（瞬間移動の直しで同じ時刻に起きるとは限らない。起きなければ向かい合いの出る種を探して確かめる） rescues.csv と stops.csv で確かめる。ほかに変な動き（助けに行ったスタッフが詰まる・同じ所で何度も助けが要る）が出たら、下の 180 回は回さずに報告して止める。
## 始める前に確かめること（違えば回さずに報告して終わる）
1. 上の 0 が入り、⑦の確かめで解けている
2. 依頼74 が合格している（依頼75 は終わっていればよい。不合格でも回してよい）
3. Unity エディタ・night_runner／rec_runner が動いていない。KIOXIA がマウントされ、unity_ledger_v1.lock がない。台帳を退避
4. ServiceSim の保留が 0
## 回すもの（画面なし・今の標準・直した版の実行ファイル）
- 基準データ v5 と同じ並び：③⑦ × 0・1・2台 × 種10個（60回）
- ④⑤⑥② の今までの夜と同じ並び：店ごとに 0・1・2台 × 種10個（各30回・計120回）
- 夜の名前は 20261103、ラベルは `tpfix_base`（立ち往生の助け 入）。同時に回す本数は今のまま
- 判定（judge_night.py）は今までどおり自動で出してよい（基準は v5 のまま。差が出るのは当たり前なので、印が付いても止めない）
## 報告
依頼箱の結果に加えて、claude_code_reports に 20261103_tpfix_base.txt として。
- 180回の completed の数・失敗・止まった回・最長の実時間
- 店ごと・台数ごとに、瞬間移動・入店待ち・料理の待ち・会計待ち・30秒以上の止まり（1往復あたり）・動けなくなった の種10個の中央値を、v5（③⑦）と今までの夜（④⑤⑥②）と並べた表
- 店ごと・台数ごとの rescues（1往復あたり）と rescue_staff_s の中央値。試算の stuck_rate 0.01 と並べる
- 0 の作りの変更点（ファイル・切り替えの名前）と⑦の確かめの結果
- 台帳の行数の変化と md5
````
#### 20261103_tpfix_base.txt（依頼76 の Claude Code の報告）
````text
====================================================================
立ち往生をスタッフが解く作りを入れた。⑦の確かめで変な動きが出たので、基準データの 180 回は回していない
依頼：20261103_76_直した版で基準データを取り直す.md（依頼75 の後・夜）
2026-11-03 10:56〜11:25 check-in：cs:63 build_id 画面なし cs63_20261103_1114（保留 0）
====================================================================
結論
・依頼の 0（立ち往生の助け）を切り替えで入れ、既定を入にした（cs:63・画面なしの実行ファイルを作り直した）
・⑦（fam_p5・種7・2台）で確かめた。前に約9分止まっていた (20.4, 5.0) 付近の向かい合いは、
助け2回・約105秒で解けた（1回目は 30 秒＋スタッフが着くまで約6秒＋15 秒＝51.3 秒）
・ただし、依頼が「180 回は回さずに止める」とした変な動きが2つとも出た
(1) 同じ所で何度も助けが要る：往復を終えて止まっている2号機に1号機が阻まれ、同じ所で助けが続いた
（待機場所の手前 (16.5, 5.9) で 9515〜9892 秒に 8 回、受け渡し口の近く (15.7, 5.0) で 10653〜11087 秒に 8 回）
(2) 助けに行ったスタッフが詰まる：4028 秒の助け（通路 A01）で、スタッフが 2 回あきらめ、3 回目に「移した」
・なので、基準データの 180 回（③⑦ 60 回・④⑤⑥② 120 回）は回していない。表は作れていない
====================================================================
1. 始める前の確かめ（10:56〜11:00）
====================================================================
1. 0 が入り、⑦の確かめで解けている … 下の 3・4 のとおり。解けた向かい合いはあるが、変な動きが出たので「解けている」とは言えない（不合格）
2. 依頼74：「済み」にあり、結果の報告がある（4 回とも completed）。合格とみた
依頼75：見張り係が止まったため「失敗」に回っている（10:52）。終わってはいる
3. Unity エディタ：起動していない（Unity Hub だけ）。night_runner・rec_runner・実行ファイル：動いていない
/Volumes/KIOXIA：マウントされている。unity_ledger_v1.lock：なし
台帳を archive/unity_ledger_v1_pre_tpfix_base_20261103/unity_ledger_v1.csv に退避：1658 行・md5 7896338a6483643ca5f88f1950795d27
4. ServiceSim の保留：0（cs:62 head）
====================================================================
2. 0 の作り（切り替えの名前・変えたファイル）
====================================================================
切り替え
・実行ファイルの引数 -ssStuckRescue on|off。付けないときは入（HeadlessRun.StuckRescueDefault）
・queue の各回の stuck_rescue（on / off）。make_queue.py --stuck-rescue・night_runner.py --stuck-rescue
params の unity_rules に項目が無いので、無いときは入（STUCK_RESCUE_DEFAULT。params は変えていない）
・入の回だけ、出力フォルダ名の末尾に _rescue（_lane の後ろ・店の指定の前）。C# と Python で同じ字
・run_info.json の stuck_rescue.enabled。judge_night.py は入切を条件に足した（基準 v5 は切なので「基準なし」になる）
・切の回は今までどおり（60 秒で動けなくなったら呼び、その場から走りを続ける）。切の回の動きは1行も変えていない
入の回の動き
・ロボットが続けて 30 秒動けなかったら助けを呼ぶ（ServiceOps.RescueCallAfterStoppedSec。judge の立ち往生の線と同じ）。
1 回の止まりに 1 度。向かい合う2台のどちらかにまだ終わっていない助けがあれば重ねない（1 つの向かい合いに 1 人）
・助けは優先 0。手が空いている人のうち、人用の面の道の長さで近い人が取る。手が空いている人がいなければ、
今の仕事を終えて取りに来た人が取る（近い人が 2 秒取らなければ、だれが取ってもよい）
・スタッフは歩いて行き（動かす台の手前 0.8 m。今までと同じ立つ点）、着いてから rescue_s（15 秒）で片方を動かす
・ロボットどうしなら空の方（料理を載せていない方）。同じなら行き先までの残りの道が長い方。人とならロボット。
相手の台が卓で受け渡し中・往復を終えて待っているときは、相手は動かさず呼んだ台を動かす
・動かす先は、相手の道（相手のロボットの先 4 m・人なら歩いている道）から 2 台の半径＋0.1 m 以上離れた、
地図で入れるマスのうち、いちばん近くでほかの台・人と重ならない所（2.5 m で無ければ 5 m まで広げる）。
見つからなければその場で道を引き直す。動かした台はそこで道を引き直して仕事を続け、呼んだ台も引き直す
・スタッフが着く前に、呼んだ台か動かす台が 2 秒続けて動けたら取り消す（スタッフは仕事に戻る）
・60 秒で「動けなくなった」の数え方は変えていない（入の回も 60 秒で数える。そのときに助けが無ければ呼ぶ）
・助けに行くスタッフは、動かす台と向かい合っている相手の台もよけない
記録
・rescues.csv（回のフォルダ）：呼んだ時刻・位置・通路・呼んだ台・動かした台・相手・原因・呼んだときに止まっていた秒・
行ったスタッフ・手が空くまで待った秒・歩いた m と秒・動かした秒・解けるまでの秒（止まり始めから）・動かした m・どうなったか
・summary.json：rescues（スタッフが着いて動かした回数）・rescue_staff_s（staff_time_s の「立ち往生」＝助けに使った秒の合計）・
stuck_rescue（呼んだ回数・取り消した回数も）。入の回は site_metrics.rescues と台帳の rescues 列も同じ回数
・stops.csv：スタッフが動かして終わった止まりの解け方は「スタッフが動かした」
・モニター：スタッフの仕事に「助けに行く」、下の段に「助けに行く：動かした n 回・自分で動き出して取り消し n 回」
変えたファイル（cs:63 で check-in）
Assets/ServiceSim/Service/ServiceOps.cs（助けの記録・呼び方・取り消し・終わり・近い人の決め方）
Assets/ServiceSim/Robot/ServingRobotController.cs（30 秒で呼ぶ・相手を見つける・動かす先・道の引き直し）
Assets/ServiceSim/People/StaffAgent.cs・PersonRobotYield.cs（近い人が取る・相手の台をよけない・歩いた m）
Assets/ServiceSim/Experiment/ExperimentRunner.cs・HeadlessRun.cs・TripLogger.cs（切り替え・フォルダ名・記録）
Assets/ServiceSim/Store/KitchenMonitor.cs（「助けに行く」）
tools/make_queue.py・night_runner.py・judge_night.py（切り替え・フォルダ名・判定の条件）
check-in 前に試しのビルド 2 回（/tmp/ss76_compiletest・/tmp/ss76_compiletest2）で error CS 0 を確かめた
画面なしの実行ファイル：Builds/headless build_id cs63_20261103_1114・unity_cs ServiceSim/cs:63・pending_changes 空
録画用の実行ファイルは作っていない（Builds/rec12_tpfix62 は助けの無い cs:62 のまま）
====================================================================
3. ⑦の確かめ（fam_p5_s4_r2_a42・種7・今の標準・助け 入）
====================================================================
ラベル rescuecheck・同時 4 本（1 回だけ）・やり直しなし。記録 night/20261103_rescuecheck/（runner 終了コード 0）
出力 20261103_rescuecheck_cs63_fam_p5_r2_s7_passon_sbret_ek_post_rescue（completed・全員帰った・実時間 2.7 分）
助けの数
呼んだ 41 回 … 動かした 33・その場で引き直した 2（動かす先が無い）・自分で動き出して取り消し 4・往復が終わって取り消し 2
rescues 35・rescue_staff_s 943.7 秒・往復 127
相手：ロボット 24・客 8・スタッフ 5・分からない 3・人が立ち止まっていた 1
解けるまでの秒（止まり始めから。35 回）：中央値 51.0・最短 45.1・最長 238.4
どの行も 30 秒＋手が空くまで待った秒＋歩いた秒＋15 秒 と一致（ずれ 0 行）
手が空くまで待った秒：中央値 0.05・最長 53.1 歩いた秒：中央値 3.2・最長 179.8
解けた向かい合い（前に約 9 分止まっていた所）
1472.7 秒 (20.56, 3.96)：1号機が 2号機と向かい合って 30 秒 → Staff02 が 0.05 秒で取り、5.9 秒歩いて着き、15 秒で
1号機を 1.16 m 動かした（止まり 51.3 秒・stops.csv の解け方「スタッフが動かした」）
1号機は引き直した道でまた2号機に向かい、1533.95 秒から 44.5 秒止まって 2 回目の助け（0.98 m 動かした）
1578 秒に2台とも動き出し、1590 秒には別の卓へ。前の回（cs:59）は 1472〜2022 秒の約 550 秒止まっていた
出た変な動き（依頼の「180 回は回さずに止める」に当たる）
(1) 同じ所で何度も助けが要る
場所は受け渡し口の右の待機場所。1号機の待機場所は (16.7, 5.9)、2号機の待機場所は (17.5, 6.0)
（中心どうし約 0.76 m・体どうしの間は約 0.26 m）
2号機が往復を終えて自分の待機場所に止まっていると、戻ってきた1号機が自分の待機場所の 0.2〜0.4 m 手前
(16.5, 5.9) で前のセンサーに2号機を見て止まり続ける
2号機は止まっていて道が無いので、「相手の道から外れた一番近い所」は1号機のいる所そのものになり、
動かした距離は 0.025 m ほど。引き直しても同じ所で止まり、約 47 秒ごとに助けが入った
9515〜9892 秒に 8 回（最後の 1 回は1号機の往復が終わって取り消し）
同じ形がもう 1 か所：2号機が受け渡し口の点 (15.3, 5.95) で往復を終えて止まり、料理を載せて卓へ向かう1号機が
(15.7, 5.0) で阻まれた。10653〜11087 秒に 8 回（最後の 1 回は取り消し）
動かした距離が 0.05 m 未満の助けは 35 回中 25 回。待機場所のあたり（x 15.5〜17.3・z 4.8〜6.4）の呼び出しは 41 回中 25 回
この止まりは助けを入れる前からある：助けの無い cs:62 の同じ回（20261103_rec_focus2_cs62_fam_p5_r2_s7・録画の回）でも、
同じあたりで 30 秒以上の止まりが 12 回あった（今回は 17 回）
(2) 助けに行ったスタッフが詰まる
4028.4 秒、通路 A01 (1.77, 9.09) で1号機がスタッフと向かい合って 30 秒 → 助けに行ったスタッフが 60 秒着けずに
2 回あきらめ（4102・4162 秒）、3 回目の 4222 秒に「移した」（瞬間移動に数える）。解けるまで 238.4 秒
ほかに 2374.9 秒にも 1 回あきらめた（通路 A01）
参考：同じ回の前の版（助け無し）との比べ（1 回ずつなので、ばらつきとの区別はできない）
| 回 | 往復 | 30秒以上の止まり | 動けなくなった（60秒） | あきらめた | 瞬間移動 | 入店待ち | 料理の待ち | 会計待ち | 店の時刻（分） |
|---|---|---|---|---|---|---|---|---|---|
| 今回 cs:63・助け入（画面なし） | 127 | 44 | 10 | 56 | 30 | 3.52 | 1.66 | 9.27 | 196.9 |
| cs:62・助け無し（録画の回） | 112 | 40 | 32 | 89 | 32 | 3.96 | 2.03 | 10.12 | 206.0 |
====================================================================
4. 基準データの 180 回
====================================================================
回していない（0 回）。completed・失敗・止まった回・最長の実時間は無し
店ごと・台数ごとの表（瞬間移動・入店待ち・料理の待ち・会計待ち・30 秒以上の止まり・動けなくなった・rescues・rescue_staff_s）も作れていない
比べる相手は次のものにするつもりだった（回すときに使える）
③⑦：v5（20261102_night_cs34_*）
④ fam_p2：20261031_p2（cs:33。0台は _passon、1・2台は _passon_sbret）
⑤ fam_p3：20261103_night・⑥ fam_p4：20261104_night・② fam_p0：20261105_night
試算の stuck_rate 0.01 との並べも、180 回の後に出す
====================================================================
5. 台帳
====================================================================
unity_ledger_v1.csv：1658 行 → 1659 行（追記 1 行だけ。⑦の確かめの 1 回・completed・unity_cs ServiceSim/cs:63）
始める前の md5：7896338a6483643ca5f88f1950795d27（退避と同じ）
終わったあとの md5：69510edef7fe2a792ba5e27a62421310
終わったあとの先頭 1658 行の md5：7896338a6483643ca5f88f1950795d27（始める前と同じ＝前の行は変わっていない）
列は今までどおり（59 列）。鍵ファイルは残っていない
====================================================================
6. 変えたもの・残したもの
====================================================================
check-in（cs:63）：上の 2 の 11 ファイル
作り直した：Builds/headless（cs:63・助けの既定は入）
新しく置いた：night/20261103_rescuecheck/・night/20261103_rescuecheck_dry/・確かめの回の出力フォルダ・
archive/unity_ledger_v1_pre_tpfix_base_20261103/
/tmp に残したもの：/tmp/req76/（並び）・/tmp/ss76_compiletest・/tmp/ss76_compiletest2（試しのビルド）・/tmp/ss76_*.log
変えていない：params（serving-robot-params.json）・店の形・切の回の動き・60 秒の線・rescue_s（15 秒）・同時に回す本数・
台帳の列と今までの行・Builds/rec12_tpfix62
注意：Builds/headless の既定が「助け 入」になったので、次の依頼77（同じ種で2回）は助け入の版で回る（依頼77 の前提どおり）
====================================================================
決めてほしいこと
====================================================================
1. 相手が止まっている台（往復を終えて待機場所・受け渡し口の点にいる台）のときの決まり。今の決まりだと、止まっている台には道が無いので、
呼んだ台がその場から動かず、同じ所で何度も助けが入る。案：
a. 相手が往復を終えて待っている台なら、その台を動かす（呼んだ台の道から外れた一番近い空いた所へ）
b. 相手に道が無いときは、相手の体から離れた所（呼んだ台の道の外）へ呼んだ台を動かす
c. 待機場所どうしの間（いま中心どうし約 0.76 m）を店の形の側で広げる（サイトの店の形の直し）
2. 助けに行くスタッフが着けないとき（細い通路で人が前にいる）の扱い。今は 60 秒であきらめ、3 回目で「移した」（瞬間移動）になる。
このままにするか、助けのときは別の決まりにするか
3. 1・2 を決めたあと、⑦の確かめをやり直して 180 回を回すか（並べ方と比べる相手は上の 4 のとおり用意できる）
4. Builds/headless の既定を「助け 入」のままにしておくか（依頼77 は入の前提。切に戻すなら -ssStuckRescue off で回せる）
````
#### 20261103_76_直した版で基準データを取り直す_20261103_1056.md（依頼76 の見張り係の記録）
````markdown
# 結果：20261103_76_直した版で基準データを取り直す
- 状態：完了
- 始めた時刻：2026-11-03 10:56
- 終わった時刻：2026-11-03 11:21（25分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume 9b93b5af-88af-4683-aa03-1c46052c18ed`
- 止められた操作：1件（いちばん下に一覧）
## Claude Code の報告
やったこと
- 始める前の確かめ：依頼74 は「済み」で、合格とみました。依頼75 は見張り係が止まったため「失敗」に回り、終わっています。Unity エディタと night_runner／rec_runner は動いておらず、KIOXIA はマウント済み、鍵ファイルはなし、保留は 0 でした。台帳は先に退避しました。
- 依頼の 0「立ち往生をスタッフが解く」を、切り替え（実行ファイルの引数 `-ssStuckRescue on|off`、queue の `stuck_rescue`）として入れました。
- 既定は入です。入の回は、出力フォルダ名の末尾に `_rescue` が付きます。
- 切の回の動きは今までと同じです。
- params には項目が無いので、params は変えずに、既定はコードの側に置きました。
- 入の回の動き：
- ロボットが 30 秒続けて動けなかったら、助けを優先 0 で呼びます。
- 手が空いている人のうち、道の長さで近い人が行きます。全員ふさがっていれば、仕事を終えた人が行きます。
- 着いてから 15 秒で片方を、相手の道から外れた一番近い空いた所へ動かし、そこで道を引き直させます。
- ロボットどうしなら空の方を、同じなら行き先まで遠い方を動かします。人とならロボットを動かします。
- スタッフが着く前に自分で動き出したら、取り消します。
- 記録：rescues.csv を書き、summary.json に `rescues`・`rescue_staff_s` を出し、モニターに「助けに行く」を出すようにしました。判定（judge_night.py）の条件にもこの入切を足しました。
- cs:63 で check-in し、画面なしの実行ファイルを作り直しました（build_id cs63_20261103_1114・保留 0）。
- ⑦（fam_p5・種7・2台）を 1 回回して確かめました。
結果
- 前に約 9 分止まっていた向かい合い（1472 秒〜）は、助け 2 回、約 105 秒で解けました。
- 1 回目は 30 秒＋手が空くまで 0.05 秒＋歩き 5.9 秒＋15 秒＝51.3 秒で、1号機を 1.16 m 動かしました。
- 解けるまでの秒は、35 回の中央値で 51.0 秒です。どの行も「30 秒＋待ち＋歩き＋15 秒」と合っていました。
- ただし、依頼が「180 回は回さずに止める」と決めている変な動きが 2 つとも出ました。
- **同じ所で何度も助けが要る**：往復を終えて止まっている2号機に、1号機が阻まれ続けました。
- 待機場所の手前 (16.5, 5.9) で 8 回、受け渡し口の近く (15.7, 5.0) で 8 回、助けが入りました。
- 2号機は止まっていて道が無いので、1号機はほとんど動かされず（35 回中 25 回が 0.05 m 未満）、同じ所でまた止まりました。
- この詰まりは、助けを入れる前の cs:62 の同じ回でも起きていました（同じあたりで 30 秒以上の止まりが 12 回）。
- **助けに行ったスタッフが詰まる**：4028 秒、通路 A01 で、助けに行ったスタッフが 2 回あきらめ、3 回目に「移した」になりました。
- このため、基準データの 180 回は回していません。店ごと・台数ごとの表と、試算の stuck_rate 0.01 との並べは作れていません。
- 確かめの 1 回の数：呼んだ 41 回、動かした 35 回、取り消し 6 回、`rescue_staff_s` 943.7 秒、往復 127 回でした。
- 台帳は 1658 → 1659 行で、追記 1 行だけです。
- 始める前の md5：7896338a6483643ca5f88f1950795d27（退避と同じ）
- 終わったあとの md5：69510edef7fe2a792ba5e27a62421310
- 先頭 1658 行の md5 は始める前と同じで、前の行は変わっていません。
変えたファイル
- Assets/ServiceSim/Service/ServiceOps.cs
- Assets/ServiceSim/Robot/ServingRobotController.cs
- Assets/ServiceSim/People/StaffAgent.cs、PersonRobotYield.cs
- Assets/ServiceSim/Experiment/ExperimentRunner.cs、HeadlessRun.cs、TripLogger.cs
- Assets/ServiceSim/Store/KitchenMonitor.cs
- tools/make_queue.py、night_runner.py、judge_night.py
- 以上 11 ファイルを cs:63 で check-in しました。
- Builds/headless を作り直しました。
- 報告は claude_code_reports/20261103_tpfix_base.txt に書きました。
決めてほしいこと
1. 相手が往復を終えて止まっている台（待機場所や受け渡し口の点にいる台）のときの決まり。今の決まりのままでは、同じ所で何度も助けが入ります。案は次の 3 つです。
- 止まっている台の方を動かす
- 相手の体から離れた所へ、呼んだ台を動かす
- 店の形の側で、待機場所どうしの間を広げる（今は中心どうし約 0.76 m）
2. 助けに行くスタッフが細い通路で着けないとき、今は 60 秒であきらめ、3 回目で「移した」（瞬間移動）になります。このままにするか、助けのときだけ別の決まりにするか。
3. 1・2 を決めたあと、⑦の確かめをやり直して 180 回を回すか。並べ方と比べる相手は用意できています。
4. 画面なしの実行ファイルの既定を「助け 入」のままにしておくか。次の依頼77 は入を前提にしているので、入のまま残しています。
## 止められた操作
- {"tool_name": "Bash", "tool_use_id": "toolu_01BWkJyFUGrXKhBhQh71ck1t", "tool_input": {"command": "cd /Users/shimazueiichi/Robotics_UX/ServiceSim/tools; python3 - <<'EOF'\ndef rep(p, old, new, cnt=1):\n s=open(p,encoding='utf-8').read()\n assert s.count(old)==cnt, (p, old[:80], s.count(old))\n s=s.replace(old,new)\n open(p,'w',encoding='utf-8').write(s)\np='make_queue.py'\nrep(p, \"\"\"決まりの値（pass_clear_m など）は Unity が params の unity_rules から読む（ここでは写さない）。\"\"\", \"\"\"立ち往生の助け（2026-11-03
````
## 作業ログ ― 依頼77：同じ種で2回回すと、動けなくなった回が12回と0回に分かれた
依頼76の結果を見て、そもそも同じ条件で回したら同じ結果になるのかを確かめました。シミュレーションで「直したら良くなった」と言うには、直す前と後で、直した所以外が同じでなければなりません。
結果は、6組とも一致しませんでした。店の時刻で約1,040〜2,620秒まではまったく同じに進み、そこから人の譲りのところで1〜数コマずれ始め、終わりには主な数字が大きく揺れていました。
| 数字 | 1回目と2回目の差（6組で最大） |
|---|---|
| 入店待ち | ±0.73分 |
| 料理の待ち | 1.16分 |
| 30秒以上の止まり | 24回 対 6回 |
| 動けなくなった | 12回 対 0回 |
| 助け（rescues） | 18回 対 2回 |
**同じ種で2回回しただけで、動けなくなったロボットが12回と0回に分かれていた。** これでは、どの直しが効いたのかを1回の比べで言えません。
#### 20261103_77_同じ種で2回回して記録が一致するかを見る.md（依頼77 の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 180
---
# 依頼77：同じ条件・同じ種で2回回して、記録が1行も違わずに一致するかを見る（依頼76 の後）
エイイチと決めたこと（2026-11-03）：ロボットと人の動きを差し替えられる部品として切り出す（設計は Claude が書いた「ServiceSim 動きの部品の設計」）。切り出しは依頼76 が終わってから始める。
この依頼はその1段目。**コードは変えない。** 切り出したあとに結果が変わっていないかを何で見るかを決めるために、今の作りで同じ回を2回回したとき記録がそろうかを調べる。
## 始める前に確かめること（違えば回さずに報告して終わる）
1. 依頼76 が「済み」にあり、結果の報告がある（76 が失敗・途中で止まっていたら、この依頼は回さずに報告して終わる）
2. Unity エディタ・night_runner／rec_runner が動いていない。KIOXIA がマウントされ、unity_ledger_v1.lock がない
3. ServiceSim の保留が 0
## やること
1. 依頼76 の後の今の標準の実行ファイル（画面なし）のまま、次の6回を2回ずつ回す（計12回）
- ③ fam_p1 と ⑦ fam_p5 × ロボット2台 × 種 0・3・7。普通の混み具合・真ん中の人数・今の標準の切り替え（依頼76 の立ち往生の助け 入）
- 1回目のラベル `det_a`、2回目のラベル `det_b`。同時に回す本数は今のまま
2. 同じ条件・同じ種の2回で、回のフォルダの trips.csv・stops.csv・people_jams.csv・yields.csv・contacts.csv・rescues.csv・give_ups.csv・summary.json を比べる。実時間（壁時計）や build_id・ラベルのように、回のたびに変わって当たり前の列は外して比べる
3. 一致しなかった回は、最初にずれた行（店の時刻・どの記録・どの列・値）を見つける。原因の当たり（同時に回す本数・実時間に頼った処理・乱数の使い方など）を調べてよいが、**直さない**
4. 台帳は追記だけ
## 変えないもの
- コード・数字・実行ファイル・台帳の列と今までの行
## 報告
依頼箱の結果に加えて、claude_code_reports に 20261103_determinism.txt として。
- 6組それぞれ、記録が全部一致したか。一致しなかった組は、最初にずれた所（店の時刻・記録・列・値）と、summary.json の主な数字（入店待ち・料理の待ち・30秒以上の止まり・動けなくなった・rescues）の2回の差
- 原因の当たり（分かった範囲で）
- 最後に一行で：「一致した」か「一致しない（揺れの大きさ）」。次の依頼78 の合格の決め方に使う
````
#### 20261103_determinism.txt（依頼77 の Claude Code の報告）
````text
====================================================================
依頼77：同じ条件・同じ種で2回回して、記録が一致するかを見た（コードは変えていません）
2026-11-03 11:22〜11:37
====================================================================
結論（一行）
一致しない。6組とも、店の時刻 約1,040〜2,620 秒までは同じで、そこから人の譲り（1〜数コマ）でずれ始め、
終わりには主な数字が大きく揺れる（入店待ち 最大 ±0.73 分・料理の待ち 最大 1.16 分・
30秒以上の止まり 24 対 6・動けなくなった 12 対 0・rescues 18 対 2）。
--------------------------------------------------------------------
0. 始める前の確かめ
--------------------------------------------------------------------
・依頼76：「済み」にあり、結果は「完了」（2026-11-03 11:21）。
ただし 76 の中の 180 回は、76 自身の止める決まりで回していない（確かめの1回だけ）。
今回は「76 は済み・報告あり」とみて進めた（決めてほしいこと 3）。
・Unity エディタ・night_runner・rec_runner：動いていない（Unity Hub だけ開いていた）。
・KIOXIA：マウント済み。unity_ledger_v1.lock：無し。
・ServiceSim の保留：0（cs:63 - head）。
・実行ファイル：Builds/headless（build_id cs63_20261103_1114・pending 空）。作り直していない。
--------------------------------------------------------------------
1. 回し方
--------------------------------------------------------------------
・条件：fam_p1_s4_r2_a42（③）・fam_p5_s4_r2_a42（⑦）× 種 0・3・7。
普通の混み具合（42組/時）・スタッフ真ん中（4人）・
すれ違い入・待機場所へ戻る入・入口番入・持ち場入・案B切・一方通行切・1本道切・立ち往生の助け 入。
・queue：make_queue.py --conditions fam_p1_s4_r2_a42,fam_p5_s4_r2_a42 --seeds 0,3,7 --label det_a / det_b
（/tmp/req77/q/det_a.json・det_b.json）
・night_runner.py --parallel 4 --night 20261103 --label det_a（続けて det_b）--no-retry
同時 4 本は依頼76 と同じ（10/26 busycheck で決めた N=4）。6 回なので、どちらも
「4本 → 残り2本」の同じ並びで走った。
・12 回すべて completed・終了コード 0。1回の実時間 3.1〜4.0 分。
・出力：KIOXIA service_sim/unity/20261103_det_a_cs63_*・20261103_det_b_cs63_*（_passon_sbret_ek_post_rescue）
・比べ方：/tmp/req77/compare.py・first2.py・rt.py（読むだけ）。
外した列：trips.csv の plan_ms_max（道を引いた実時間）、summary.json の written_at。
（run_info.json は比べる対象外。wall_seconds・run_label が違うのは当たり前）
--------------------------------------------------------------------
2. 6組の結果
--------------------------------------------------------------------
8つの記録（trips・stops・people_jams・yields・contacts・rescues・give_ups・summary.json）は、
**6組とも、8つ全部が一致しなかった**。行の数から違う（例 ⑦種0 の people_jams 1315 行 対 257 行）。
最初にずれた所（時刻でいちばん早いもの。店の時刻 = 回の中の秒）
組 最初のずれ（記録・行・列・値 a → b）
------------------------------------------------------------------------------------------
③ 種0 2373.26 秒 yields 83行 客→ロボット2号機 の譲りの x 5.4214 → 5.4207
（次は trips 2593 秒発の往復 total_s 90.40 → 90.65、stops 2697.5 秒 duration_s 3.6 → 3.85）
③ 種3 1043.21 秒発の往復 trips 8行 min_clearance_m 0.5532 → 0.5906
1072 秒 groups 13行 seated_s 1072.14 → 1072.59
1085.80 秒 yields 8行 スタッフ Staff01→2号機 の譲り t_s 1085.804 → 1085.754（1コマ）
③ 種7 2312.25 秒 rescues 13行 walk_m 16.3883 → 16.3918
（2354 秒発の往復 min_clearance_m 0.026 → 0.0386、2396.08 秒 yields 客→1号機 x 5.0767 → 5.0816）
⑦ 種0 2593.32 秒発の往復 trips 33行 distance_m 34.1402 → 34.2451
2624.31 秒 yields 103行 スタッフ Staff02→1号機 の譲り t_s 2624.305 → 2624.355（1コマ）
⑦ 種3 1043.01 秒発の往復 trips 8行 min_clearance_m 0.508 → 0.4947
1085 秒 groups 14行 seated_s 1085.403 → 1085.303、1139.01 秒 yields スタッフ Staff02→2号機 x 0.8227 → 0.8
⑦ 種7 2178 秒ごろ dishes 33行 ready_s（料理の出る時刻）2276.4 → 2178.1
2231.52 秒 yields 94行 客→2号機 の譲り t_s 2231.521 → 2231.572（1コマ）、waited_s 2.85 → 2.7
・それより前は、ロボットの位置（robot_track、5 秒ごと）・timeline・yields・stops とも小数4桁まで同じ。
・ずれ始めは、どの組も「人（スタッフか客）がロボットに譲る」所か、人の位置で、
大きさは 0.05 秒（1コマ）や数 mm。そこから連鎖して広がる。
summary.json の主な数字（a / b）
組 入店待ち(分) 料理の待ち(分) 30秒以上の止まり 動けなくなった rescues 往復 店の中(分)
---------------------------------------------------------------------------------------------------------
③ 種0 1.736 / 1.382 1.548 / 1.625 24 / 18 12 / 0 15 / 10 111 / 109 176.9 / 173.9
③ 種3 1.979 / 1.603 2.144 / 1.447 26 / 17 6 / 6 17 / 12 110 / 123 183.6 / 178.6
③ 種7 2.790 / 3.522 1.692 / 1.741 33 / 30 10 / 10 25 / 26 118 / 117 196.0 / 196.9
⑦ 種0 1.355 / 1.347 1.220 / 1.297 24 / 6 3 / 0 18 / 2 120 / 118 173.2 / 171.8
⑦ 種3 1.476 / 1.447 2.853 / 1.689 24 / 12 0 / 0 21 / 7 101 / 121 195.8 / 178.0
⑦ 種7 3.106 / 3.570 1.627 / 1.690 21 / 19 1 / 4 17 / 14 122 / 121 195.7 / 196.2
（30秒以上の止まり = stops.csv の duration_s ≧ 30 の行数。動けなくなった = summary の stops.stuck_count）
参考：依頼76 の確かめの回（同じ実行ファイル・⑦種7・同時1本で起動）は
入店待ち 3.516・料理の待ち 1.660・30秒以上の止まり 44・動けなくなった 10・rescues 35・往復 127。
⑦種7 は3回で rescues 35 / 17 / 14 と揺れている。
揺れの大きさ（2回の差）
入店待ち 0.01〜0.73 分（大きい方から見て 1〜21%）
料理の待ち 0.05〜1.16 分（同 3〜41%）
30秒以上の止まり 2〜18 回
動けなくなった 0〜12 回
rescues 1〜16 回
往復 1〜20 回
--------------------------------------------------------------------
3. 原因の当たり（直していない）
--------------------------------------------------------------------
(A) 本命：人の道の計算が非同期（10/25 の v11 確かめ B と同じ元）
・人（スタッフ・客）は NavMeshAgent.SetDestination（非同期）で道を引く
（People/PeopleNav.cs:130。同期で引く切り替え PeopleNav.SyncPaths /
ExperimentPlan.detCheckSyncPeoplePaths は今も既定で切）。
・道が引けるまで pathPending の間、譲るかの判断（PersonRobotYield.cs:780）と
着いたかの判断（StaffAgent.cs:209・GuestAgent.cs:177）がそのコマを飛ばす。
・何コマかかるかは Mac の忙しさで変わる。今回の最初のずれも、6組中5組が
「人がロボットに譲る」所の 1コマ（0.05 秒）か数 mm で、この形と合う。
(B) 同時に回す本数（4本）：忙しさを通して (A) のコマ数を変える。
10/26 busycheck で「動けなくなった・助けた・ロボット分担」が本数で動くと分かっている。
今回は2回とも同じ並び（4本→2本）だが、OS の割り当てまでは同じにならない。
1本ずつで2回回したら一致するかは、今回は見ていない。
(C) 人の局所回避（Unity の RVO・ワーカースレッド）、物理の問い合わせの返る順番：
可能性は残るが、1,000 秒以上小数4桁まで一致していたので毎コマ効く形ではない。
(D) 実時間に頼った処理：見た範囲では動きには使っていない。
GridPlanner の Stopwatch は plan_ms_max の記録だけ。Time.realtimeSinceStartup は
1回の上限（今回どれも 4 分で、上限に届いていない）と起動待ちだけ。
(E) 乱数：すべて System.Random(種から決まる値) で、組ごとに別の列（GroupManager.NewGroupRng）。
来方（arrive_s）は2回で同じだったので、乱数の使い方はずれの元ではない。
・ずれ始めがどの組も約17〜44分後なのは、ロボットと人が細い所で出会う場面が増える時間帯からと見ている。
そこから止まり・助け・卓の空き方が連鎖して、終わりの数字が上の表の幅で揺れる。
--------------------------------------------------------------------
4. 台帳・そのほか
--------------------------------------------------------------------
・台帳：1659 → 1671 行（det_a 6・det_b 6、どれも completed・59 列）。
始める前の md5 69510edef7fe2a792ba5e27a62421310（依頼76 の終わりと同じ）、
終わったあと f4bdbeb5ddd45c8b6f7c93a08a15f865。先頭 1659 行の md5 は始める前と同じ。
退避：archive/unity_ledger_v1_pre_det_20261103/
・night/20261103/ は今回新しくできたフォルダ。det_a と det_b を同じ night 名で回したので、
そこの judge.md・judge.csv・queue.json は det_b のもので上書きされている（runner_log.txt は両方）。
・変えていない：コード・params・数字・実行ファイル・台帳の列と今までの行。
--------------------------------------------------------------------
5. 依頼78 の合格の決め方に向けて
--------------------------------------------------------------------
・今の作り（同時4本）では「記録が1行も違わない」を合格の線にはできない。
切り出す前と後の実行ファイルで同じ種を回しても、上の表の幅で揺れるのが普通。
・使えそうな線（どれにするかはエイイチが決める）
a) 先にずれの元（A）を止めて一致する作りにしてから、「1行も違わない」で比べる
（同期の切り替えはコードにあるが、入れると動きが変わる＝基準が変わる）
b) 揺れはそのままにして、複数の種・複数回の幅で比べる（例：前後で中央の差が、
今回の 2回の差の幅に入るか）
c) 1本ずつで回せば一致するかを先に確かめる（今回は見ていない）
````
#### 20261103_77_同じ種で2回回して記録が一致するかを見る_20261103_1121.md（依頼77 の見張り係の記録）
````markdown
# 結果：20261103_77_同じ種で2回回して記録が一致するかを見る
- 状態：完了
- 始めた時刻：2026-11-03 11:21
- 終わった時刻：2026-11-03 11:39（19分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume 309282ed-8b1b-4a6d-9e7a-9624b2507188`
## Claude Code の報告
やったこと
- 始める前に確かめました。
- 依頼76 は「済み」にあり、報告は「完了」でした。
- Unity エディタ・night_runner／rec_runner は動いていませんでした。KIOXIA はマウント済みで、鍵ファイルはありませんでした。
- 保留は 0（cs:63）です。実行ファイルは cs63_20261103_1114 のままで、作り直していません。
- 台帳を先に退避してから回しました。退避先は archive/unity_ledger_v1_pre_det_20261103 です。
- 回した条件は ③ fam_p1 と ⑦ fam_p5、ロボット2台、種 0・3・7 です。混み具合は普通、人数は真ん中、立ち往生の助けは入です。
- 2回とも同時4本で回しました。1回目は det_a の6回、2回目は det_b の6回です。
- 8つの記録を比べました。外した列は、trips.csv の plan_ms_max（道を引くのにかかった実時間）と summary.json の written_at です。
- 最初にずれた所を探し、原因の当たりを調べました。直してはいません。
結果
- 12回すべて最後まで回りました（終了コード 0、1回 3.1〜4.0 分）。
- **6組とも一致しませんでした。8つの記録は、どの組も全部違っていました。**
- 最初のずれ（店の時刻）
- ③種3：1043 秒に出た往復の min_clearance_m が 0.5532 → 0.5906。1085.80 秒の Staff01 の譲りは、時刻が 1 コマ（0.05 秒）ずれていました。
- ⑦種3：1043 秒に出た往復の min_clearance_m が 0.508 → 0.4947。
- ⑦種7：料理の出る時刻が 2276.4 → 2178.1 秒とずれ、2231.52 秒の客の譲りが 1 コマずれました。
- ③種7：2312 秒の rescues の walk_m が 16.3883 → 16.3918。
- ③種0：2373 秒の客の譲りの x が 5.4214 → 5.4207。
- ⑦種0：2593 秒に出た往復の distance_m が 34.14 → 34.25。
- それより前は、ロボットの位置まで小数4桁で同じでした。ずれ始めは、どの組も人がロボットに譲る所か人の位置で、1 コマか数 mm です。そこから連鎖して広がります。
- summary.json の主な数字の2回の差
| 数字 | 2回の差 | 差がいちばん大きかった組（a 対 b） |
|---|---|---|
| 入店待ち | 0.01〜0.73 分（1〜21%） | ③種7：2.79 対 3.52 |
| 料理の待ち | 0.05〜1.16 分（3〜41%） | ⑦種3：2.85 対 1.69 |
| 30秒以上の止まり | 2〜18 回 | ⑦種0：24 対 6 |
| 動けなくなった | 0〜12 回 | ③種0：12 対 0 |
| rescues | 1〜16 回 | ⑦種0：18 対 2 |
- 原因の当たり
- 本命は、10/25 に見つけたのと同じ元です。人の道が非同期で引かれ、道が引けるまでの数コマのあいだ、譲るかと着いたかの判断が飛びます。その数コマは Mac の忙しさで変わります。
- 同時4本の忙しさが、このコマ数を変えている見込みです。
- 乱数は種どおりで、客の来方は2回で同じでした。
- 実時間（壁時計）の値は記録と1回の上限にしか使っておらず、上限には届いていません。
- 一行で：**一致しない**（揺れの大きさは上の表のとおり）。
- 台帳は 1659 → 1671 行で、12 行を足しただけです。先頭 1659 行の md5 は始める前と同じです。
- night/20261103 の judge.md・judge.csv・queue.json は、det_b のもので上書きされています。
変えたファイル
- claude_code_reports/20261103_determinism.txt（報告。新しく作りました）
- KIOXIA の台帳（12 行の追記だけ）と、12 回分の回のフォルダ
- コード・数字・実行ファイルは変えていません。
決めてほしいこと
1. 依頼78 の合格の決め方。今の作りでは「1行も違わない」を合格の線にできません。案は3つです。
- a) 先にずれの元を止める。人の道を同期で引く切り替えはコードにありますが、入れると動きが変わるので、基準が変わります。
- b) 揺れは残したまま、複数の種・複数回の幅で比べる。
- c) 1本ずつで回せば一致するかを先に確かめる（今回は見ていません）。
2. 次に一致を確かめるとき、同時に回す本数を 4 のままにするか、1 にするか。
3. 依頼76 は「済み」で報告も「完了」でしたが、76 の中の 180 回は、76 自身の止める決まりで回していません。私は条件を満たすとみて回しました。この見方でよいか。
````
「同じ種なら同じ結果が出るようにするか」を選ぶときには、そのメリットを確かめたうえで、決め方が次のように言い直されました。
> 同じ種なら同じ結果が出るようになるに修正 瞬間移動はしませんにしてください（現実に瞬間移動はないため）
ここで、この先の2つの目標が決まりました。同じ種なら同じ結果が出ること。瞬間移動をしないこと。
## 作業ログ ― 依頼78：人の部品の切り出しを止めたつもりが、裏で書き換えが続いた
依頼77と同じころ、人の動きを部品として切り出す依頼78を置いていました。依頼77で「同じ種でも揺れる」と分かったので、部品にする前に揺れを止めるほうが先です。依頼78は止めることにしました。
ここで依頼箱の弱いところが2つ出ました。1つは、前の依頼が止まっても次の依頼がそのまま走ったこと（依頼77と78の続け方）。もう1つは、見張り係の画面で Ctrl+C を押しても Claude Code の作業は止まらず、裏で依頼78の書き換えが続いて、変更が cs:64 として保存されたことです（cs は Unity のコードの版の番号。Unity Version Control の changeset）。
依頼79は「Unity が動いていない」「保留の変更が0」という確かめで止まり、79bは「依頼78の書きかけが保留として残っている」という前提が違っていて止まりました。79cで、依頼78の変更を cs:63 の中身に戻す版（cs:65）を作ってから進めています。
依頼箱の決まりは次のように直しました。
- 新規に置く依頼は1件だけにする。報告の最後の判定の1行（「判定：合格」／「判定：止めた（決めてほしいことあり）」／「判定：失敗」）を読んでから次を置く
- 依頼を止めるときは、見張り係の画面の Ctrl+C に加えて、`pkill -f "claude -p"` で Claude Code も止める
#### 20261103_78_人の動きを部品として切り出す.md（依頼78 の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 300
---
# 依頼78：人の動きを、差し替えられる部品として切り出す（依頼77 の後）
エイイチと決めたこと（2026-11-03）：店の形・条件・乱数の種・計測は毎回同じにしたまま、ロボットの道の選び方と人の動き方だけを入れ替えて夜に比べられるようにする。小さい方から、人を先に、ロボットを後に切り出す。人どうしのよけ合いも人の部品に入れる。譲る順番は今のまま（ロボット＞スタッフ＞客）で、部品はこの順番に従う。
この依頼は2段目で、人だけ。**動きの中身は変えない。** 最初に挿す部品は今の動きそのもので、結果が今と変わらないことが合格。
## 始める前に確かめること（違えば手を止めて報告）
1. 依頼77 が「済み」にあり、claude_code_reports/20261103_determinism.txt がある。最後の一行（一致した／一致しない）を読む
2. Unity エディタ・night_runner／rec_runner が動いていない。KIOXIA がマウントされ、unity_ledger_v1.lock がない
3. ServiceSim の保留が 0
## 今の人の動き（読んだ範囲・Claude が 2026-11-03 に確認）
- 行き先は StaffAgent・GuestAgent が決め、歩き方は NavMeshAgent（人どうしのよけ合いもここ）
- PersonRobotYield（1人に1つ）：ロボットをよける。横へどく・細い通路の入口で待つ・回り道・下がる・広い所で 0.3 m 空ける（客が横を詰めるときは 0.1 m）・まれな不注意
- JamWatcher（店に1つ）：人どうしで前に進めない状態が 1 秒続いたら半径 0.2 → 0.12 m（横を向く）、3 秒で片方が下がる。people_jams.csv を書く
## やること
1. 人の部品の受け渡しの形を作る（ファイル名・型の名前は任せる。People/ の下）。部品は毎コマ、受け取るものから返すものを決めるだけにする
- 受け取るもの：自分（位置・速さ・半径・種類・前に進めていない秒数）、行き先（StaffAgent・GuestAgent が入れた点）、周りのロボット（位置・速さ・料理の有無・進む道の先・止まっている秒数）、周りの人（位置・速さ・半径）、通路の形（細い通路の区画・よけ場所・広い通路の点。読むだけ）、譲る順番（RobotSpec の今の決まり）、助けに行く台（今の ignoreRobot）、店の時刻と1コマの長さ
- 返すもの：次の動き（2通りのどちらか。向かう点を返して人どうしのよけ合いを NavMeshAgent に任せる／進む向きと速さを返す）、横へずらす量、体の半径、いまの状態（ふつう・入口で待つ・回り道・下がる・横へどく・横を向いている・人と押し合っている）
- 本体の側：返ってきた動きを当てはめる。向きと速さが返ってきたときは、その人の NavMeshAgent のよけ合いを切り、歩ける床の外に出さず、人の最高速を超えさせない。記録（people_jams.csv・yields.csv・contacts.csv など）は本体が部品の返す状態から書く
- 部品がしてはいけないこと：位置を飛ばす、ロボットやほかの人を動かす、記録を書く、地図や通路の形を書き換える
2. 最初の部品 `current` を作る。PersonRobotYield のよけ方、JamWatcher の横を向く・下がる判断、NavMeshAgent に任せている人どうしのよけ合いを、**中身を変えずに**この部品へ移す。数字は今の PeopleSpec・RobotSpec をそのまま読む。依頼74 の瞬間移動の直しと、依頼76 の立ち往生を助けに行くスタッフの動きを崩さない
3. 部品の選び方：画面なしの引数 `-ssPersonPart`（無ければ `current`）。部品の名前を summary.json と trips.csv に残す（今の path_mode と同じ形）。台帳には列を足さない。current 以外で回すときはラベルに部品の名前を入れる
4. check-in して、画面なしと録画用の実行ファイルを作り直す（保留 0）
5. 確かめ（`current` で）
- 依頼77 が「一致した」なら：依頼77 と同じ12回（ラベル `part_p`）を回し、77 の det_a と記録が1行も違わないこと
- 「一致しない」なら：③⑦ × 0・1・2台 × 種10個の60回（ラベル `part_p`）を回し、依頼76 の同じ60回と、入店待ち・料理の待ち・会計待ち・30秒以上の止まり・動けなくなった・rescues・人の詰まり（people_jams）の種10個の中央値を並べる。差が依頼77 で見た揺れの大きさに収まっていること
- 合格しなかったら：実行ファイルを切り出す前の版に戻し（標準は切り出す前のまま）、どこがずれたかを報告して止める
6. 台帳は追記だけ
## 変えないもの
- ロボットの動き・速さ・物理の設定・逃がし弁の線・譲る順番・人とロボットの数字。台帳の列と今までの行
- ServingRobotController（ロボットの切り出しは次の依頼）
## 報告
依頼箱の結果に加えて、claude_code_reports に 20261103_person_part.txt として。
- 作った・変えたファイルと、受け渡しの形（型の名前と中身の一覧）・cs 番号と build_id
- 移したもの・本体に残したものの一覧（どの処理をどこへ）
- 確かめの結果（一致したか、または中央値の表と揺れとの比べ）
- 切り出してみて、受け渡しの形に足りなかった・余った項目（ロボットの切り出しの設計に使う）
````
#### 20261103_78_人の動きを部品として切り出す_20261103_1150.md（依頼78 の見張り係の記録）
````markdown
# 結果：20261103_78_人の動きを部品として切り出す
- 状態：失敗
- 始めた時刻：2026-11-03 11:50
- 終わった時刻：2026-11-03 11:50（0分）
- 作業フォルダ：不明
## Claude Code の報告
見張り係が止まった（Mac の再起動など）ため、この依頼は途中で終わっています。途中まで変わったファイルがあるかもしれません。やり直すかどうかは、確かめてから決めます。
````
#### README.md（依頼箱の README.md）
````markdown
# 依頼箱
Claude が書いた Claude Code あての依頼を、Mac の見張り係が自動で Claude Code に渡し、報告を書き戻す場所。
## フォルダ
| フォルダ | 中身 |
|---|---|
| 新規 | Claude が依頼を置く。見張り係が1件ずつ自動で実行する |
| 確認待ち | エイイチの確認が要る依頼。読んで良ければ「新規」へ移すと実行される |
| 実行中 | いま Claude Code が作業している依頼 |
| 済み／失敗 | 終わった依頼 |
| 結果 | Claude Code の報告（.md）と元の出力（.json） |
| _仕組み | 見張り係の元のファイル（据え付け先は Mac の `~/r2r2r-scripts/inbox/`） |
`記録.log` に、いつ何を始めて終えたかが残る。終わると Mac に通知が出る。
## 決まり
- 自動で回してよいのは `config.json` の `allowed_dirs` にある作業フォルダだけ（今は ServiceSim と r2r2r-scripts）。ほかの場所の依頼は実行せずに「失敗」へ回す
- 実機を動かす依頼は自動にしない。関節制御・姿勢系の変更は、実装とレビューまでを自動にし、実機に流す前は「確認待ち」で止める
- `git clean`・`git add .`・強制 push・`rm -rf` などは `settings.json` で拒否してある
- Claude Code が決めるべきでないことに当たったら、手を止めて報告の「決めてほしいこと」に書く
## 起動・停止
- 起動：Mac にログインすると、ターミナルの窓が自動で開いて起動する（登録は `~/Library/LaunchAgents/com.pixelstomotors.inbox.plist`）。窓は開けたまま。見張っている間は Mac がスリープしない
- 手で起動するとき：ターミナルで `python3 ~/r2r2r-scripts/inbox/inbox_runner.py`（2つ目は起動しないので、重ねて打っても大丈夫）
- 作業の途中で Mac が止まった依頼は、次に起動したときに「失敗」へ回る（自動ではやり直さない）
- 見張り係を新しくするとき：`bash ~/r2r2r-scripts/inbox/update.sh`
- 停止：その窓で Ctrl+C
- 一時停止：このフォルダに「止める」という名前のファイルを置く（消すと再開）
## 依頼の書き方（Claude が書く）
```
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 120
---
（依頼の本文）
```
上限時間は分。書かなければ180分。時間を過ぎたら止めて「時間切れ」として報告する。
## 動いている依頼を途中で止めるとき（2026-11-03 追加）
見張り係の窓で Ctrl+C を押しても、止まるのは見張り係だけで、渡した先の Claude Code は裏で動き続ける。依頼を止めるときは、Ctrl+C のあとにターミナルで次の1行も打つ。
```
pkill -f "claude -p"
```
依頼が起動した画面なしの Unity が残ることがあるので、次の依頼の最初にそれを終わらせ、書きかけの変更を取り消す手順を入れる。
## 置き方（2026-11-03 から）
- 新規に置くのは1件だけ。前の報告の判定を読んでから次を置く（前の依頼が止まっても後ろが走り出して崩れたため）
- 報告の最後の1行に「判定：合格／止めた（決めてほしいことあり）／失敗」を書いてもらう
- 依頼箱は、夜に長く回す作業を中心に使う
````
## 作業ログ ― 依頼79c：同じ種で同じ結果にした（人のよけ方の計算の順番が揺れていた）
揺れの元は、Unity が人のよけ方を何本もの流れで同時に計算していたことでした。③の種0、店の時刻1921.8秒で、スタッフ1人の位置・速さ・道・近くのお客さんの様子がまったく同じなのに、よけたあとの向き（NavMeshAgent の desiredVelocity）だけが回によって (0.119, -0.636) と (0.154, -0.702) に分かれていました。同時に計算する順番が、Mac の忙しさで変わっていたためです。
直したのは3つです。
1. 人の道を、その場で待って引く形（同期）を標準にした
2. 同期の回は、Unity の裏方の流れ（[JobsUtility.JobWorkerCount](https://docs.unity3d.com/ScriptReference/Unity.Jobs.LowLevel.Unsafe.JobsUtility.JobWorkerCount.html)）を0本にし、全部を1本の流れで順に回す
3. 往復を終えた台を待機場所へ下げる道も、同期で引く
- ねらい：同じ種なら、何度回しても同じ結果が出るようにする
- 変わったこと：③⑦×種0・3・7を2回ずつ、同時1本・同時4本の両方で回し、12組とも8つの記録が1行も違わなかった。1本の回と4本の回どうしも同じ
- 見込める効果（測った値）：1回の計算が3〜4分から1.2〜1.5分に縮んだ（同時4本でも2分前後）。流れを1本にしたほうが速くなったのは、何本もの流れを待ち合わせる手間がなくなったためとみている（確かめてはいない）
同じ依頼で、立ち往生の助けも直しました。相手が往復を終えて止まっている台なら、止まっている台のほうを動かす。助けに行くスタッフは瞬間移動しない。それでも⑦の種7で、止まっている台が0.02mしか動かず、同じ所で2回ずつ助けが要る形が残りました。
#### 20261103_79_同じ種で同じ結果にし立ち往生の助けを直す.md（依頼79 の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 180
---
# 依頼79：同じ条件・同じ種なら同じ結果が出るようにし、立ち往生の助けを瞬間移動なしに直す（昼）
エイイチと決めたこと（2026-11-03 11:46）：
- 同じ条件・同じ種なら、記録が1行も違わずに同じ結果が出るようにする
- 立ち往生の助けでは瞬間移動はしない（現実に瞬間移動はないため）
- 止まっている台にふさがれた立ち往生は、止まっている台の方を動かす
依頼76・77 の報告：iCloud の サービスロボット導入シミュレーション/unity/claude_code_reports/ の 20261103_tpfix_base.txt と 20261103_determinism.txt。今の実行ファイルは cs63_20261103_1114。
## 始める前に確かめること（違えば手を止めて報告）
Unity エディタ・night_runner／rec_runner が動いていない、KIOXIA がマウント済み、unity_ledger_v1.lock がない、保留 0。台帳は退避してから回す。台帳は追記だけ。
## 1. 同じ条件・同じ種なら同じ結果が出るようにする
- 依頼77 で、人の道が非同期で引かれるあいだの数コマで譲る・着いたの判断が飛び、Mac の忙しさで1コマずれて広がると分かった。人の道を同期で引く切り替え（コードにある）を入にして、今の標準にする
- ほかにも実時間や処理の順番で結果が変わる所があれば、同じように直す
- 確かめ：③ fam_p1 と ⑦ fam_p5 × ロボット2台 × 種 0・3・7 を2回ずつ回し、trips・stops・people_jams・yields・contacts・rescues・give_ups・summary.json が1行も違わないこと（plan_ms_max と written_at は外す）。同時に回す本数1本と4本の両方で確かめる
- 一致しなければ、最初にずれた所を見つけて直し、一致するまで続ける
## 2. 立ち往生の助けの決まりを直す（瞬間移動はしない）
- 立ち往生した台の前を、往復を終えて止まっている台（待機場所・受け渡し口の点にいて道を持たない台）がふさいでいるときは、止まっている台の方を動かす。動かした先は今と同じ決め方（相手の道から外れた、いちばん近くの空いた所）
- 助けに行くスタッフが細い通路でふさがれて着けないとき：
(1) 通路の反対側から回り込める道があればそちらから行く
(2) なければ通路の入口で待ち、空いたら入る
(3) 60 秒たっても着けなければ、その人は仕事に戻り、次に手が空いたスタッフに交代する
助けのときは「移した」（瞬間移動）を使わない。着けずに交代した回数と待った秒を rescues.csv に残す
- 助け以外の瞬間移動（客の逃がし弁・1往復の打ち切りの置き直し・料理を運べず3回で移す）は今回は変えない。回のたびの回数だけ summary.json に出す
## 3. 確かめ
- 1・2 を入れたら check-in し、画面なしと録画用の実行ファイルを作り直す（保留 0）
- ⑦ fam_p5・種7・ロボット2台を1回回し、依頼76 で同じ所に16回助けが入った詰まりが解けるか、助けに行ったスタッフが瞬間移動せずに着くか（着けずに交代した回があればその様子）、同じ所で何度も助けが要る・助けに行った人が詰まる、が残っていないかを rescues.csv と stops.csv で確かめる
- 変な動きが残ったら、そこで止めて報告
## 変えないもの
ロボットの速さ・物理の設定・譲る順番（ロボット＞スタッフ＞客）・人とロボットの数字・試算の rescue_s 15 秒・30 秒の線・台帳の列と今までの行。
## 報告
claude_code_reports/20261103_det_rescue.txt に：変えたファイルと cs・build_id、1 の一致の結果（1本・4本）、2・3 の確かめの結果、助け以外の瞬間移動の回数。
**報告の最後の1行は必ず次のどれか**：「判定：合格」／「判定：止めた（決めてほしいことあり）」／「判定：失敗」
````
#### 20261103_79b_同じ種で同じ結果にし立ち往生の助けを直す.md（依頼79b の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 180
---
# 依頼79b：同じ条件・同じ種なら同じ結果が出るようにし、立ち往生の助けを瞬間移動なしに直す（昼）
エイイチと決めたこと（2026-11-03 11:46）：
- 同じ条件・同じ種なら、記録が1行も違わずに同じ結果が出るようにする
- 立ち往生の助けでは瞬間移動はしない（現実に瞬間移動はないため）
- 止まっている台にふさがれた立ち往生は、止まっている台の方を動かす
依頼76・77 の報告：iCloud の サービスロボット導入シミュレーション/unity/claude_code_reports/ の 20261103_tpfix_base.txt と 20261103_determinism.txt。今の実行ファイルは cs63_20261103_1114。
## 0. 先に片付けること（2026-11-03 11:54 追加）
依頼78 の Claude Code が、見張り係を止めたあとも裏で動き続け、11:39〜11:53 に ServiceSim を書き換えていた（pkill で止めた）。依頼79 はこれに気づいて止まった（20261103_det_rescue.txt）。
- 依頼78 が起動した画面なしの Unity（バッチモード）が残っていれば終わらせる
- 依頼78 の書きかけは取りやめる。cs:63 の上の保留 10 件（HeadlessRun.cs・ExperimentRunner.cs・TripLogger.cs・JamWatcher.cs・PersonRobotYield.cs・night_runner.py の変更、新しい PersonPart.cs・CurrentPersonPart.cs と .meta）をすべて取り消し、cs:63 と同じ状態に戻す。check-in はしない
- 戻したあと、保留 0・Unity が動いていない・実行ファイルが cs63_20261103_1114 であることを確かめてから、下の「始める前に確かめること」に進む
## 始める前に確かめること（違えば手を止めて報告）
Unity エディタ・night_runner／rec_runner が動いていない、KIOXIA がマウント済み、unity_ledger_v1.lock がない、保留 0。台帳は退避してから回す。台帳は追記だけ。
## 1. 同じ条件・同じ種なら同じ結果が出るようにする
- 依頼77 で、人の道が非同期で引かれるあいだの数コマで譲る・着いたの判断が飛び、Mac の忙しさで1コマずれて広がると分かった。人の道を同期で引く切り替え（コードにある）を入にして、今の標準にする
- ほかにも実時間や処理の順番で結果が変わる所があれば、同じように直す
- 確かめ：③ fam_p1 と ⑦ fam_p5 × ロボット2台 × 種 0・3・7 を2回ずつ回し、trips・stops・people_jams・yields・contacts・rescues・give_ups・summary.json が1行も違わないこと（plan_ms_max と written_at は外す）。同時に回す本数1本と4本の両方で確かめる
- 一致しなければ、最初にずれた所を見つけて直し、一致するまで続ける
## 2. 立ち往生の助けの決まりを直す（瞬間移動はしない）
- 立ち往生した台の前を、往復を終えて止まっている台（待機場所・受け渡し口の点にいて道を持たない台）がふさいでいるときは、止まっている台の方を動かす。動かした先は今と同じ決め方（相手の道から外れた、いちばん近くの空いた所）
- 助けに行くスタッフが細い通路でふさがれて着けないとき：
(1) 通路の反対側から回り込める道があればそちらから行く
(2) なければ通路の入口で待ち、空いたら入る
(3) 60 秒たっても着けなければ、その人は仕事に戻り、次に手が空いたスタッフに交代する
助けのときは「移した」（瞬間移動）を使わない。着けずに交代した回数と待った秒を rescues.csv に残す
- 助け以外の瞬間移動（客の逃がし弁・1往復の打ち切りの置き直し・料理を運べず3回で移す）は今回は変えない。回のたびの回数だけ summary.json に出す
## 3. 確かめ
- 1・2 を入れたら check-in し、画面なしと録画用の実行ファイルを作り直す（保留 0）
- ⑦ fam_p5・種7・ロボット2台を1回回し、依頼76 で同じ所に16回助けが入った詰まりが解けるか、助けに行ったスタッフが瞬間移動せずに着くか（着けずに交代した回があればその様子）、同じ所で何度も助けが要る・助けに行った人が詰まる、が残っていないかを rescues.csv と stops.csv で確かめる
- 変な動きが残ったら、そこで止めて報告
## 変えないもの
ロボットの速さ・物理の設定・譲る順番（ロボット＞スタッフ＞客）・人とロボットの数字・試算の rescue_s 15 秒・30 秒の線・台帳の列と今までの行。
## 報告
claude_code_reports/20261103_det_rescue.txt に：変えたファイルと cs・build_id、1 の一致の結果（1本・4本）、2・3 の確かめの結果、助け以外の瞬間移動の回数。
**報告の最後の1行は必ず次のどれか**：「判定：合格」／「判定：止めた（決めてほしいことあり）」／「判定：失敗」
````
#### 20261103_79c_同じ種で同じ結果にし立ち往生の助けを直す.md（依頼79c の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 180
---
# 依頼79c：同じ条件・同じ種なら同じ結果が出るようにし、立ち往生の助けを瞬間移動なしに直す（昼）
エイイチと決めたこと（2026-11-03 11:46）：
- 同じ条件・同じ種なら、記録が1行も違わずに同じ結果が出るようにする
- 立ち往生の助けでは瞬間移動はしない（現実に瞬間移動はないため）
- 止まっている台にふさがれた立ち往生は、止まっている台の方を動かす
依頼76・77 の報告：iCloud の サービスロボット導入シミュレーション/unity/claude_code_reports/ の 20261103_tpfix_base.txt と 20261103_determinism.txt。今の実行ファイルは cs63_20261103_1114。
## 0. 先に片付けること（2026-11-03 11:59 決定）
依頼79b の報告どおり、依頼78 の書きかけは cs:64 として check-in されていた。
- cs:63 の中身に戻す check-in をする（cs:65 など。コメントに「依頼78 の取りやめ。cs:63 の中身に戻す」）。作業場所は切り替えない
- 依頼78 が作った実行ファイル（Builds/headless_part64・Builds/rec13_part64）と KIOXIA の part_p のフォルダは消さずに残す（使わない）
- 戻したあと、保留 0・Unity が動いていない・中身が cs:63 と同じ・Builds/headless が cs63_20261103_1114 であることを確かめてから、下へ進む
## 始める前に確かめること（違えば手を止めて報告）
Unity エディタ・night_runner／rec_runner が動いていない、KIOXIA がマウント済み、unity_ledger_v1.lock がない、保留 0。台帳は退避してから回す。台帳は追記だけ。
## 1. 同じ条件・同じ種なら同じ結果が出るようにする
- 依頼77 で、人の道が非同期で引かれるあいだの数コマで譲る・着いたの判断が飛び、Mac の忙しさで1コマずれて広がると分かった。人の道を同期で引く切り替え（コードにある）を入にして、今の標準にする
- ほかにも実時間や処理の順番で結果が変わる所があれば、同じように直す
- 確かめ：③ fam_p1 と ⑦ fam_p5 × ロボット2台 × 種 0・3・7 を2回ずつ回し、trips・stops・people_jams・yields・contacts・rescues・give_ups・summary.json が1行も違わないこと（plan_ms_max と written_at は外す）。同時に回す本数1本と4本の両方で確かめる
- 一致しなければ、最初にずれた所を見つけて直し、一致するまで続ける
## 2. 立ち往生の助けの決まりを直す（瞬間移動はしない）
- 立ち往生した台の前を、往復を終えて止まっている台（待機場所・受け渡し口の点にいて道を持たない台）がふさいでいるときは、止まっている台の方を動かす。動かした先は今と同じ決め方（相手の道から外れた、いちばん近くの空いた所）
- 助けに行くスタッフが細い通路でふさがれて着けないとき：
(1) 通路の反対側から回り込める道があればそちらから行く
(2) なければ通路の入口で待ち、空いたら入る
(3) 60 秒たっても着けなければ、その人は仕事に戻り、次に手が空いたスタッフに交代する
助けのときは「移した」（瞬間移動）を使わない。着けずに交代した回数と待った秒を rescues.csv に残す
- 助け以外の瞬間移動（客の逃がし弁・1往復の打ち切りの置き直し・料理を運べず3回で移す）は今回は変えない。回のたびの回数だけ summary.json に出す
## 3. 確かめ
- 1・2 を入れたら check-in し、画面なしと録画用の実行ファイルを作り直す（保留 0）
- ⑦ fam_p5・種7・ロボット2台を1回回し、依頼76 で同じ所に16回助けが入った詰まりが解けるか、助けに行ったスタッフが瞬間移動せずに着くか（着けずに交代した回があればその様子）、同じ所で何度も助けが要る・助けに行った人が詰まる、が残っていないかを rescues.csv と stops.csv で確かめる
- 変な動きが残ったら、そこで止めて報告
## 変えないもの
ロボットの速さ・物理の設定・譲る順番（ロボット＞スタッフ＞客）・人とロボットの数字・試算の rescue_s 15 秒・30 秒の線・台帳の列と今までの行。
## 報告
claude_code_reports/20261103_det_rescue.txt に：変えたファイルと cs・build_id、1 の一致の結果（1本・4本）、2・3 の確かめの結果、助け以外の瞬間移動の回数。
**報告の最後の1行は必ず次のどれか**：「判定：合格」／「判定：止めた（決めてほしいことあり）」／「判定：失敗」
````
#### 20261103_det_rescue.txt（依頼79・79b・79c の Claude Code の報告）
````text
====================================================================
依頼79：同じ種で同じ結果にし、立ち往生の助けを瞬間移動なしに直す
2026-11-03 11:52 始める前の確かめで止めた（コード・実行ファイル・台帳はどれも触っていない）
====================================================================
始める前の確かめ
・Unity：動いている。依頼78（人の動きを部品として切り出す）の別の作業が同時に走っていて、
Unity をバッチで起動し、試しのコンパイルをしている（ログ /tmp/req78_compile.log）
・night_runner・rec_runner：動いていない
・KIOXIA：マウント済み。unity_ledger_v1.lock：無し
・ServiceSim の保留：0 ではない（cs:63 head の上に 10 件）。依頼78 の作業中の変更
変更：Experiment/HeadlessRun.cs・ExperimentRunner.cs・TripLogger.cs・Service/JamWatcher.cs・
People/PersonRobotYield.cs・tools/night_runner.py
新規：People/PersonPart.cs・CurrentPersonPart.cs（と .meta）
→ 「Unity が動いていない」「保留 0」の2つが違うので、依頼のとおり手を止めた
やったこと
・上の確かめと、依頼76・77 の報告を読んだだけ
・台帳の退避もしていない（回していないため）
変えたファイル
・この報告ファイルだけ
決めてほしいこと
1. 依頼78 と依頼79 の順番。どちらも人の道・PersonRobotYield・HeadlessRun・ExperimentRunner・
TripLogger を触るので、同時には進められない。依頼78 の check-in（または取りやめ）が終わってから
依頼79 を回すか、依頼79 を先にするか
2. 依頼78 は「中身を変えずに切り出す」なので、依頼79 で人の道を同期にすると 78 の基準が変わる。
78 の後に 79 を回すなら、そのままでよいか
判定：止めた（決めてほしいことあり）
====================================================================
依頼79b：同じ種で同じ結果にし、立ち往生の助けを瞬間移動なしに直す
2026-11-03 11:56〜12:00 「0. 先に片付けること」で止めた（コード・実行ファイル・台帳はどれも触っていない）
====================================================================
結論（一行）
依頼78 の書きかけは保留として残っていなかった。11:53:14 に cs:64 として check-in 済みで、
そのあと実行ファイル2つ（headless_part64・rec13_part64）を作り、試しの回も1つ始めていた。
cs:63 の状態に戻すには「戻すための check-in」か「作業場所を cs:63 に切り替える」のどちらかが要る。
どちらも依頼の「check-in はしない」「保留を取り消す」の範囲を外れるので、そこで止めた。
--------------------------------------------------------------------
0. 先に片付けること で見たもの
--------------------------------------------------------------------
・バッチの Unity：残っていなかった。Unity のコンパイル用の裏方（VBCSCompiler、11:52〜11:53 起動の3つ）
だけ残っていたので終わらせた。Unity エディタ・night_runner・rec_runner・ServiceSim.app も動いていない
・ServiceSim の作業場所：cs:64 - head、保留 0
cs:64 2026/11/03 11:53:14
コメント「依頼78：人の動きを差し替えられる部品として切り出す（IPersonPart・最初の部品 current＝
今の動きそのもの。PersonRobotYield・JamWatcher は当てはめと記録だけ。-ssPersonPart、
summary.json・trips.csv に person_part）」
変更：ExperimentRunner.cs・HeadlessRun.cs・TripLogger.cs・PersonRobotYield.cs・JamWatcher.cs・
tools/make_queue.py・tools/night_runner.py
新規：People/PersonPart.cs・CurrentPersonPart.cs（と .meta）
（依頼にあった10件に make_queue.py が加わった11件）
・依頼78 が作った実行ファイル（どちらも cs64_20261103_1153・pending 空）
Builds/headless_part64（11:53:40）・Builds/rec13_part64（11:53:46）
・Builds/headless：今も cs63_20261103_1114（pending 空）。依頼どおり
・KIOXIA に依頼78 が残したもの（台帳には書いていない）
night/20261103_part_p/（11:54）
20261103_part_p_cs64_fam_p1_r0_s0_passon_sbret_ek_post_rescue_stopped（11:54・途中で止まった回）
archive/unity_ledger_v1_pre_part_20261103/（11:53・台帳の退避）
・台帳 unity_ledger_v1.csv：1671 行・md5 f4bdbeb5ddd45c8b6f7c93a08a15f865（依頼77 の終わりと同じ。変わっていない）
・unity_ledger_v1.lock：無し。KIOXIA：マウント済み
--------------------------------------------------------------------
やったこと
--------------------------------------------------------------------
・上の確かめと、依頼76・77・79 の報告を読んだ
・残っていた Unity のコンパイル用の裏方3つを終わらせた
・コードの戻し・1・2・3 はしていない。台帳の退避もしていない（回していないため）
・依頼78 が KIOXIA に残したフォルダと実行ファイルは消していない
変えたファイル
・この報告ファイルだけ（下に書き足した）
--------------------------------------------------------------------
決めてほしいこと
--------------------------------------------------------------------
1. cs:64（依頼78）をどう扱うか
a. 取りやめる：cs:63 の中身に戻す check-in（例 cs:65「依頼78 を取り消す」）をしてよいか。
そのうえで依頼79b を cs:65 の上で進める
b. 残す：cs:64 の上で依頼79b を進める（依頼78 は「中身を変えずに切り出す」だが、
動きが本当に変わっていないかは確かめられていない。途中で止められた作業のため）
c. 作業場所だけ cs:63 に切り替えて進める（あとの check-in が cs:64 と枝分かれになるので勧めない）
2. 依頼78 が残した Builds/headless_part64・Builds/rec13_part64・KIOXIA の part_p のフォルダ3つを消すか残すか
3. 1 が決まれば、依頼79b を最初からやり直すか
判定：止めた（決めてほしいことあり）
====================================================================
依頼79c：同じ種で同じ結果にし、立ち往生の助けを瞬間移動なしに直す
2026-11-03 12:00〜12:45 check-in：cs:65（戻し）・cs:66・cs:67 build_id cs67_20261103_1226（保留 0）
====================================================================
結論
・1（同じ種で同じ結果）は合格。③⑦ × 種0・3・7 を 2 回ずつ、同時1本・同時4本の両方で回し、
8つの記録（trips・stops・people_jams・yields・contacts・rescues・give_ups・summary.json）が
12 組とも 1 行も違わなかった。1本の回と4本の回どうしでも同じ
・2 は入れた。止まっている台の方を動かす・スタッフは瞬間移動しない（「移した」0 回）
・ただし 3 の⑦種7 で「同じ所で何度も助けが要る」が残った（待機場所で 2 回ずつ 2 組。前は 8 回ずつ 2 組）。
今の動かし先の決め方では、止まっている台が 0.02 m しか動かないため。依頼どおりそこで止めた
--------------------------------------------------------------------
0. 先に片付けること
--------------------------------------------------------------------
・cs:65「依頼78 の取りやめ。cs:63 の中身に戻す」を check-in（作業場所は切り替えていない）
変えた 7 ファイルを cs:63 の中身で上書きし、新しい 4 ファイル（PersonPart.cs・CurrentPersonPart.cs と .meta）を消した
・確かめ：保留 0、Unity エディタ・night_runner・rec_runner は動いていない（Unity Hub だけ）、
cs:63 と cs:65 のファイル一覧が同じ（345 件）、変えた 7 ファイルの中身が cs:63 と 1 字も違わない、
Builds/headless は cs63_20261103_1114
・Builds/headless_part64・Builds/rec13_part64・KIOXIA の part_p のフォルダは消していない
・始める前：KIOXIA マウント済み、unity_ledger_v1.lock なし、
台帳を archive/unity_ledger_v1_pre_det_rescue_20261103/ に退避（1671 行・md5 f4bdbeb5ddd45c8b6f7c93a08a15f865）
--------------------------------------------------------------------
1. 同じ条件・同じ種なら同じ結果
--------------------------------------------------------------------
直したこと（3つ）
(a) 人の道を同期で引く切り替え（ExperimentPlan.detCheckSyncPeoplePaths）を今の標準（入）にした。
.asset と既定を入にし、画面なしの回は HeadlessRun が毎回入れ直す（.asset に頼らない）
(b) 同期の回は、Unity の裏方の作業（job）の流れを 0 本にし、全部を1本の流れで順に回す
（JobsUtility.JobWorkerCount = 0。回し終わりに元へ戻す）。
★ (a) だけでは一致しなかった。1コマごとの指紋で探すと、③種0 の 1921.8 秒で、Staff01 の位置・速さ・道・
近くの客の様子がまったく同じなのに、よけ方を入れた向き（desiredVelocity）だけが回によって
(0.119,-0.636) と (0.154,-0.702) に分かれた。人のよけ方（NavMeshAgent の局所回避）を Unity が
何本もの流れで同時に計算していて、その順番が Mac の忙しさで変わるのが元だった。(b) でここが消えた
run_info.json の det_check に「sync_people_paths=入 / job_workers=0」と出る
(c) 往復を終えた台を待機場所へ下げる agent の道（GoStandby）も、同期の回は同期で引くようにした（同じ種類の元）
・(b) を入れたら 1 回の実時間が 3〜4 分 → 1.2〜1.5 分に縮んだ（同時4本でも 2 分前後）
・調べ用に -ssDetFrames on（det_frames.csv）・-ssDetPeople 秒,秒（det_people.csv）を足した（ふだんは出ない）
確かめ（cs:67 の Builds/headless・night_runner・--no-retry）
同時1本：det1a・det1b（各 6 回）／同時4本：det4a・det4b（各 6 回）。24 回すべて completed・終了コード 0
比べ方：外したのは plan_ms_max と summary.json の written_at だけ（/tmp/req79/cmp.py）
結果：
同時1本の 2 回 6 組とも 8 つ全部一致
同時4本の 2 回 6 組とも 8 つ全部一致
1本の回と4本の回 6 組とも 8 つ全部一致
（参考に dishes・groups・timeline・robot_track・passes・requeues も全部一致）
記録：night/20261103_det79_det1a・_det1b・_det4a・_det4b
--------------------------------------------------------------------
2. 立ち往生の助けの決まり
--------------------------------------------------------------------
・相手が往復を終えて止まっている台（Idle・往復おわり）なら、止まっている台の方を動かす。
動かす先の決め方は今のまま（呼んだ台の道の先 4 m から 2 台の半径＋0.1 m 以上離れた、いちばん近くの空いた所）。
止まっている台は動かした所で次の仕事を待つ（道は引かない）
・助けに行くスタッフ（ふさがれて 3 秒近づけないとき。細い通路のときだけ）
(1) 動かす台の反対側に立つ点まで、ふさいでいる所（前の人・ロボット）を通らずに行ける道を
人用の面を 0.2 m のマスにして探し、あれば途中の点をたどって回り込む（新しい PeopleDetour.cs）
(2) なければ通路の入口（店の形の entrance）へ下がり、その通路に人がいなくなったら入る
(3) 向かい始めて 60 秒たっても着けなければ、その人は仕事に戻り、助けは板へ戻る。
着けなかった人は同じ助けを取らず、次に手が空いた別の人が取る（全員が着けなければ、また全員が取れる）
助けでは「あきらめた」3 回目の「移した」を使わない
・rescues.csv の列の最後に足した：handoffs（着けずに交代した回数）・handoff_s（交代した人が使った秒）・
entrance_wait_s（入口で待った秒）・detours（回り込んだ回数）。summary.json の stuck_rescue にも合計
・summary.json に teleports（回のたびの瞬間移動の回数）を足した：
guest_escape（客の逃がし弁）・trip_timeout_reset（1往復の打ち切りの置き直し）・
staff_after_3_tries（料理などを運べず3回で移す）・rescue_staff（助け。0 のはず）
・助け以外の瞬間移動の決まりは変えていない
--------------------------------------------------------------------
3. ⑦ fam_p5・種7・ロボット2台の確かめ（rescue79・同時1本・completed・実時間 1.4 分）
--------------------------------------------------------------------
出力 20261103_rescue79_cs67_fam_p5_r2_s7_passon_sbret_ek_post_rescue
（同じ種なら同じ結果になったので、det の ⑦種7 の 4 回とも 1 行も違わない）
助けの数：呼んだ 17・動かした 14・自分で動き出して取り消し 1・往復が終わって取り消し 2
相手：ロボット2号機 7・客 5・スタッフ 4・ロボット1号機 1
解けるまで（止まり始めから）中央 51.3 秒・最短 33.9・最長 118.8
依頼76 の 16 回の詰まり（待機場所の手前・受け渡し口の近く）
受け渡し口の近く (15.7, 5.0)：呼び出し 0 回（出なくなった）
待機場所の手前：1号機が自分の待機場所の 0.35 m 手前 (16.56, 5.94) で、待機場所 (17.53, 5.90) に
止まっている2号機を前のセンサーに見て止まる形は残った。2号機を動かすようになったが、
動いた距離は 0.017〜0.026 m。2 回ずつ 2 組（8869〜8941 秒・9169〜9219 秒）助けが入り、
9156 秒からの止まりは 104 秒続いて、2号機が次の往復に出た 9235 秒にやっと解けた
わけ：1号機の道は自分の待機場所で終わるので、2号機はもとから「道から 0.6 m 以上外れた所」にいる。
決め方どおりだと、いちばん近い隣のマスへ 0.02 m 動かすだけになる。
一方、体どうしの間は 0.47 m で、前のセンサーの長さ 0.6 m より短いので、1号機は止まったまま
助けに行ったスタッフ
瞬間移動：0 回（give_ups に助けの「移した」「あきらめた」なし。teleports.rescue_staff 0）
着けずに交代 1 回：1163.6 秒、待機場所の2号機へ Staff04 が 60 秒着けず交代、次の人が着いた
（歩いた秒 73.7・解けるまで 118.8 秒）。細い通路ではないので、回り込み・入口で待つは働いていない
細い通路 A01 の助け 2 回（4834・5154 秒）は、どちらも交代なしで着いた（歩いた秒 22.5・2.8）
回り込んだ 0 回・入口で待った 0 秒（この回では (1)(2) が働く場面が無かった）
30 秒以上の止まり 16 回・60 秒以上 4 回（うち 3 回は待機場所の上の形）
助け以外の瞬間移動（この回）
客の逃がし弁 15・1往復の打ち切りの置き直し 2・スタッフが3回で移した（片付け）2・助け 0
--------------------------------------------------------------------
4. 変えたファイルと版
--------------------------------------------------------------------
cs:65 依頼78 の取りやめ（cs:63 の中身に戻す）
cs:66 People/PeopleDetour.cs（と .meta）だけ（check-in のやり方を誤り、新しいファイルだけが先に入った）
cs:67 cs:66 の続き。Experiment/ExperimentPlan.cs・ExperimentPlan.asset・ExperimentRunner.cs・HeadlessRun.cs・
TripLogger.cs、People/PeopleNav.cs・StaffAgent.cs、Robot/ServingRobotController.cs、Service/ServiceOps.cs
実行ファイル：Builds/headless と Builds/rec14_det67（どちらも build_id cs67_20261103_1226・unity_cs cs:67・保留 0）
tools/*.py は変えていない
--------------------------------------------------------------------
5. 台帳
--------------------------------------------------------------------
1671 行 → 1716 行（追記だけ。列は 59 のまま。先頭 1671 行の md5 は f4bdbeb5… で始める前と同じ）
終わったあとの md5 04d9e503b10b16b11cc5ac885b0f10da。鍵ファイルは残っていない
★ 注意：追記 45 行のうち 20 行（run_folder が 20261103_t1a〜t5b_cs65_…）は、原因を探すために
check-in 前の作りかけの実行ファイル（/tmp/ss79_t1〜t5）で回したもの。実行ファイルが自分で台帳に書くため入った。
unity_cs は ServiceSim/cs:65 と出ているが、中身は cs:65 と同じではない。基準データには使わないでください
残り 25 行：det1a・det1b・det4a・det4b 各 6・rescue79 1（cs:67）
--------------------------------------------------------------------
決めてほしいこと
--------------------------------------------------------------------
1. 待機場所で止まっている台を動かす先の決め方。今の決め方（呼んだ台の道から 2 台の半径＋0.1 m 外れた
いちばん近い所）だと 0.02 m しか動かず、詰まりが解けない。案：
a. 止まっている台を動かすときだけ、呼んだ台の道の先に前のセンサーの長さ（0.6 m）も足した範囲から外す
b. 止まっている台は、もう1台の待機場所から離れた決まった空き場所へ動かす
c. 待機場所どうしの間（中心どうし約 0.76 m）を店の形で広げる
d. 自分の待機場所のすぐ手前（例 0.5 m 以内）で止まっている台にふさがれたら、そこで往復を終えたとみなす
2. 台帳に入った作りかけの 20 行（t1a〜t5b）の扱い（台帳は追記だけなので、印の付け方を決める）
3. 同期の回で Unity の裏方を1本の流れにしたこと（(b)）をこのまま標準にしてよいか。動きの意味は変えていないが、
人のよけ方の細かい値は前の版と同じにはならない（前の版の数字とは並べて比べられない）
判定：止めた（決めてほしいことあり）
````
#### 20261103_79_同じ種で同じ結果にし立ち往生の助けを直す_20261103_1151.md（依頼79 の見張り係の記録）
````markdown
# 結果：20261103_79_同じ種で同じ結果にし立ち往生の助けを直す
- 状態：完了
- 始めた時刻：2026-11-03 11:51
- 終わった時刻：2026-11-03 11:53（2分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume 83ae29d6-0189-4302-be3e-3f271af0291f`
## Claude Code の報告
始める前の確かめで条件が2つ合わなかったため、作業には入らずに止めました。
**やったこと**
- 依頼のとおり、始める前の条件を確かめました。依頼76・77 の報告も読みました。
- 条件が合わなかったので手を止め、止めたことを報告ファイルに書きました。コード・実行ファイル・台帳には触っていません。回していないので、台帳の退避もしていません。
**結果**
- **Unity**：動いていました。依頼78（人の動きを部品として切り出す）が同時に走っていて、画面なしで Unity を起動してコンパイルを試していました。night_runner・rec_runner は動いていませんでした。
- **保留**：0 ではなく、cs:63 の上に 10 件ありました。どれも依頼78 の作業中の変更です。
- 変更：HeadlessRun.cs・ExperimentRunner.cs・TripLogger.cs・JamWatcher.cs・PersonRobotYield.cs・night_runner.py
- 新しいファイル：PersonPart.cs・CurrentPersonPart.cs（とそれぞれの .meta）
- **KIOXIA**：マウント済みです。unity_ledger_v1.lock はありませんでした。
- 依頼が決めた「Unity が動いていない」「保留 0」の2つが違ったので、そこで止めました。
**変えたファイル**
- claude_code_reports/20261103_det_rescue.txt（止めたことの報告。最後の行は「判定：止めた（決めてほしいことあり）」）
**決めてほしいこと**
1. 依頼78 と依頼79 をどちらから進めるか。どちらも人の道を引く所と、PersonRobotYield・HeadlessRun・ExperimentRunner・TripLogger を変えるので、同時には進められません。依頼78 の check-in か取りやめが済んでから依頼79 を回すか、依頼79 を先にするかを決めてください。
2. 依頼78 は「動きの中身を変えずに切り出し、結果が今と同じなら合格」という依頼です。依頼79 で人の道を同期で引くようにすると、依頼78 が比べる相手の結果が変わります。依頼78 の後に依頼79 を回す順でよいかを決めてください。
判定：止めた（決めてほしいことあり）
````
#### 20261103_79b_同じ種で同じ結果にし立ち往生の助けを直す_20261103_1155.md（依頼79b の見張り係の記録）
````markdown
# 結果：20261103_79b_同じ種で同じ結果にし立ち往生の助けを直す
- 状態：完了
- 始めた時刻：2026-11-03 11:55
- 終わった時刻：2026-11-03 11:58（2分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume e74e056c-9484-4e77-8ed2-2513d6458a86`
## Claude Code の報告
やったこと
- 依頼76・77・79 の報告を読み、「0. 先に片付けること」の確かめをしました。
- 画面なしの Unity は残っていませんでした。依頼78 が起動した Unity のコンパイル用の裏方が3つ残っていたので、終わらせました。
- コードを戻す作業と、1・2・3 には手を付けていません。前提が依頼文と違ったためです。
- 台帳の退避もしていません（何も回していないため）。
結果
- 依頼78 の書きかけは保留として残っていませんでした。11:53:14 に cs:64 として check-in 済みです。
- 変わったファイルは11件です。依頼文の10件に make_queue.py が加わっています。
- check-in のあと、実行ファイルを2つ作っていました（Builds/headless_part64・Builds/rec13_part64、どちらも cs64_20261103_1153）。
- 試しの回も1つ始めていて、途中で止まっています（KIOXIA の 20261103_part_p…_stopped）。
- 今の状態は次のとおりです。
- 作業場所は cs:64（head）で、保留 0 です。
- Builds/headless は cs63_20261103_1114 のままです。
- Unity・night_runner・rec_runner は動いていません。
- KIOXIA はマウント済みで、台帳の鍵ファイルはありません。
- 台帳は 1671 行、md5 f4bdbeb5… で、依頼77 の終わりから変わっていません。
- cs:63 の状態に戻すには、戻すための check-in をするか、作業場所を cs:63 に切り替えるしかありません。どちらも依頼の「check-in はしない」「保留を取り消す」を外れるので、そこで止めました。
変えたファイル
- claude_code_reports/20261103_det_rescue.txt（依頼79 の報告の下に、依頼79b の分を書き足しました）
決めてほしいこと
1. cs:64（依頼78）をどう扱うか。
- a. cs:63 の中身に戻す check-in（例：cs:65）をして、その上で依頼79b を進める。
- b. cs:64 を残し、その上で進める。ただし途中で止められた作業なので、動きが本当に変わっていないかは確かめられていません。
- c. 作業場所だけ cs:63 に切り替える。あとの check-in が cs:64 と枝分かれになるので勧めません。
2. 依頼78 が残した実行ファイル2つと、KIOXIA の part_p 関係のフォルダ3つを消すか、残すか。
3. 1 が決まったら、依頼79b を最初からやり直すか。
判定：止めた（決めてほしいことあり）
````
#### 20261103_79c_同じ種で同じ結果にし立ち往生の助けを直す_20261103_1159.md（依頼79c の見張り係の記録）
````markdown
# 結果：20261103_79c_同じ種で同じ結果にし立ち往生の助けを直す
- 状態：完了
- 始めた時刻：2026-11-03 11:59
- 終わった時刻：2026-11-03 12:51（53分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume 56304732-c251-4bd0-9ff4-14b746304b7a`
## Claude Code の報告
やったこと
- 依頼78 を取りやめ、cs:63 の中身に戻す check-in をしました（cs:65）。戻したあと、保留 0・Unity が動いていない・中身が cs:63 と同じ・Builds/headless が cs63_20261103_1114 であることを確かめてから進めました。依頼78 の実行ファイル2つと KIOXIA の part_p のフォルダは消していません。台帳は始める前に退避しました。
- 同じ種で同じ結果にする直しを入れました。
- 人の道を同期で引く切り替えを標準（入）にしました。
- ただし、これだけでは一致しませんでした。1コマごとに調べると、③種0 の 1921.8 秒で、スタッフの位置・速さ・道が同じなのに、よける向きだけが回によって違っていました。Unity が人のよけ方を何本もの流れで同時に計算していて、その順番が Mac の忙しさで変わるのが元でした。
- そこで、同期の回は Unity の裏方の作業を1本の流れで順に回すようにしました。
- 待機場所へ下げるロボットの道も、同期で引くようにしました。
- 立ち往生の助けを直しました。
- 止まっている台にふさがれたときは、止まっている台の方を動かします。
- 助けに行くスタッフは、反対側から回り込む → 通路の入口で待つ → 60 秒で次のスタッフに交代、の順にしました。助けでは瞬間移動を使いません。
- rescues.csv に交代した回数・交代までの秒・入口で待った秒・回り込んだ回数を足しました。
- summary.json に、助け以外の瞬間移動の回数を足しました。
- check-in し、画面なしと録画用の実行ファイルを作り直しました（保留 0）。
結果
- **1（同じ種で同じ結果）は合格です。** ③⑦ × 種 0・3・7 を2回ずつ回し、8つの記録が 12 組とも1行も違いませんでした。
- 同時1本の2回どうし：6 組とも一致
- 同時4本の2回どうし：6 組とも一致
- 1本の回と4本の回：6 組とも一致
- 24 回すべて completed です。1回の実時間は 3〜4 分から 1.2〜1.5 分に縮みました。
- **3（⑦種7・1回）は、変な動きが残ったので止めました。**
- 依頼76 で受け渡し口の近くに出ていた詰まり（8回）は、0 回になりました。
- 待機場所の詰まり（前は8回）は、2回ずつ2組に減りましたが解けていません。止まっている2号機を動かすようになったものの、今の決め方では 0.017〜0.026 m しか動きません。1号機は 104 秒止まり、2号機が次の往復に出た 9235 秒にやっと動けました。
- 助けに行ったスタッフの瞬間移動は 0 回でした。
- 着けずに交代したのは1回で、1163.6 秒の待機場所の助けです。次の人が着きました（歩いた秒 73.7）。細い通路 A01 の助け2回は、交代なしで着きました。
- 回り込みと入口で待つ決まりは、この回では働く場面がありませんでした。
- 助け以外の瞬間移動（この回）：客の逃がし弁 15、1往復の打ち切りの置き直し 2、スタッフが3回で移した 2、助け 0。
- 台帳は 1671 行から 1716 行になりました。追記だけで、前の行は変わっていません（md5 で確かめました）。
- **このうち 20 行（t1a〜t5b）は、原因を探すために check-in 前の作りかけの実行ファイルで回した分です。** 実行ファイルが自分で台帳に書くため入りました。unity_cs は cs:65 と出ていますが、中身は cs:65 と同じではないので、基準データには使わないでください。
変えたファイル
- cs:65：依頼78 の取りやめ（cs:63 の中身に戻す）
- cs:66：People/PeopleDetour.cs（と .meta）だけ。check-in のやり方を誤り、新しいファイルだけが先に入りました。
- cs:67（cs:66 の続き）：ExperimentPlan.cs・ExperimentPlan.asset・ExperimentRunner.cs・HeadlessRun.cs・TripLogger.cs・PeopleNav.cs・StaffAgent.cs・ServingRobotController.cs・ServiceOps.cs
- 実行ファイル：Builds/headless と Builds/rec14_det67（どちらも build_id cs67_20261103_1226・保留 0）
- 報告：claude_code_reports/20261103_det_rescue.txt に書き足しました。
決めてほしいこと
1. 待機場所で止まっている台を動かす先の決め方です。今の決め方だと、2号機はもともと1号機の道から外れているので、隣のマスへ 0.02 m しか動きません。一方、2台の体の間は 0.47 m で前のセンサーの長さ 0.6 m より短いため、1号機は止まったままです。案は次のどれかです。
- a. 止まっている台を動かすときだけ、前のセンサーの長さ 0.6 m も避ける範囲に足す
- b. 止まっている台は、もう1台の待機場所から離れた決まった空き場所へ動かす
- c. 待機場所どうしの間（中心どうし約 0.76 m）を店の形で広げる
- d. 自分の待機場所のすぐ手前でふさがれたら、そこで往復を終えたとみなす
2. 台帳に入った作りかけの 20 行（t1a〜t5b）の印の付け方です（台帳は追記だけのため）。
3. Unity の裏方を1本の流れにする作りを、このまま標準にしてよいかです。人のよけ方の細かい値が変わるので、前の版の数字とは並べて比べられません。
判定：止めた（決めてほしいことあり）
````
## 作業ログ ― 依頼80〜82：瞬間移動を0回にした
### 依頼80：止まっている台は、相手の前のセンサー（0.6m）にかからない所まで動かす
止まっている台が0.02mしか動かなかったのは、動かす先を「2台の半径＋0.1m」（0.6m）だけ離せばよいと決めていたためでした。相手のロボットは前に0.6mのセンサーを持っているので、0.6m離しただけでは、まだセンサーにかかって進めません。選択肢の中から選んだのは「a. 相手の前のセンサー（0.6m）にかからないところまで動かす」でした。
動かす先は、相手の体の半径0.25＋前のセンサー0.6＋自分の体の半径0.25＋今までの離れ0.1＝1.2m以上離れた、床をたどって届く所です。⑦種7の詰まりは1回の助けで解けました。ただ、すれ違いで下がる状態が解けずに残り、1往復の打ち切りの置き直し（これも瞬間移動）が2回から4回に増えたので止めました。
この依頼から、基準データに使わない回の一覧（unity_ledger_v1_excluded_runs.csv、cs:65 の t1a〜t5b の20回）も作っています。台帳は追記だけの決まりなので、行を消さずに、読むときに外す形です。
#### 20261103_80_待機場所で止まっている台を動かす先を直す.md（依頼80 の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 90
---
# 依頼80：待機場所で止まっている台を、相手の前のセンサーにかからない所まで動かす（昼）
エイイチと決めたこと（2026-11-03 12:57）：依頼79c の「決めてほしいこと」1 は a。止まっている台を動かすときは、相手の前のセンサーの長さ（0.6 m）にかからない所まで動かす。
依頼79c の報告：claude_code_reports/20261103_det_rescue.txt。今の実行ファイルは cs67_20261103_1226（同じ種で同じ結果・助けの直し入り）。
## 始める前に確かめること（違えば手を止めて報告）
Unity エディタ・night_runner／rec_runner が動いていない、KIOXIA がマウント済み、unity_ledger_v1.lock がない、保留 0、作業場所が cs:67。台帳は退避してから回す。台帳は追記だけ。
## やること
1. 立ち往生の助けで止まっている台（道を持たない台）を動かすとき、動かした先は「立ち往生した台の前のセンサーの長さ（0.6 m）と、相手の体の半径を足した範囲」にかからない、いちばん近くの空いた所にする。止まっている台どうし・壁・椅子・人と重ならないこと。届く所がなければ、今までの決め方に戻し、その回数を rescues.csv に残す
2. 依頼79c の作りかけの実行ファイルで回して台帳に入った 20 行（ラベル t1a〜t5b、unity_cs は cs:65 と出ている）を、基準データに使わない回として一覧にする。置き場所は KIOXIA の service_sim/unity/unity_ledger_v1_excluded_runs.csv（列：run_folder・理由・決めた日）。judge_night.py と台帳を読む道具がこの一覧の回を外すようにする。台帳そのものは書き換えない
3. check-in し、画面なしと録画用の実行ファイルを作り直す（保留 0）
4. 確かめ（画面なし）
- ⑦ fam_p5・種7・ロボット2台を1回：依頼79c で残った待機場所の詰まり（2回ずつ2組）が解けるか。rescues.csv と stops.csv で、動かした距離・解けるまでの秒・同じ所で何度も助けが要っていないかを見る
- 同じ回をもう1回回し、記録が1行も違わないこと（同じ種で同じ結果が崩れていないか）
- ③ fam_p1 と ⑦ fam_p5 × ロボット2台 × 種 0・3・7 を1回ずつ回し、変な動き（同じ所で何度も助け・助けに行った人が詰まる・瞬間移動の増加）が出ないこと
- 変な動きが出たら、そこで止めて報告
## 変えないもの
ロボットの速さ・物理の設定・譲る順番・人とロボットの数字・rescue_s 15 秒・30 秒の線・同じ種で同じ結果にする作り・台帳の列と今までの行。
## 報告
claude_code_reports/20261103_standby_rescue.txt に：変えたファイルと cs・build_id、⑦種7 の詰まりの解け方（動かした距離・秒）、2回の一致、6回の結果（立ち往生・30秒以上の止まり・瞬間移動・rescues・入店待ち・料理の待ちの中央値）、除外の一覧の行数。
**報告の最後の1行は必ず次のどれか**：「判定：合格」／「判定：止めた（決めてほしいことあり）」／「判定：失敗」
````
#### 20261103_standby_rescue.txt（依頼80 の Claude Code の報告）
````text
====================================================================
依頼80：待機場所で止まっている台を、相手の前のセンサーにかからない所まで動かす
2026-11-03 12:58〜13:25 check-in：cs:68 build_id cs68_20261103_1303（保留 0）
====================================================================
結論
・ねらいの詰まりは解けた。⑦種7 で依頼79c に残った「待機場所の手前で 2 回ずつ 2 組」（8869〜9219 秒）は、
8869 秒の 1 回の助けで解けた（2号機を 0.63 m 動かし、止まり始めから 72.4 秒）。そのあとの呼び出しは無い
・同じ種の 2 回は、8つの記録が 1 行も違わない
・ただし ⑦種7 で「1往復の打ち切りの置き直し」（瞬間移動）が 2 → 4 回に増えた。
増えた 2 回は助けではなく、すれ違いで下がる状態が解けずに残ったもの（下の 4）。依頼どおりここで止めた
--------------------------------------------------------------------
0. 始める前の確かめ
--------------------------------------------------------------------
Unity エディタ・night_runner・rec_runner：動いていない（Unity Hub だけ）／KIOXIA：マウント済み／
unity_ledger_v1.lock：無し／保留 0／作業場所 cs:67 - head。どれも依頼どおり
台帳を archive/unity_ledger_v1_pre_standby_rescue_20261103/ に退避（1716 行・md5 04d9e503b10b16b11cc5ac885b0f10da）
--------------------------------------------------------------------
1. 動かす先の決め方（Robot/ServingRobotController.cs の RescueMove）
--------------------------------------------------------------------
・往復を終えて止まっている台（道を持たない台）を、立ち往生した台の前から動かすときだけ使う
・相手（立ち往生した台）の道の先（いまの位置から 4 m）から、
相手の体の半径 0.25 ＋ 相手の前のセンサーの長さ 0.6 ＋ 自分の体の半径 0.25 ＋ 今までの離れ 0.1 ＝ 1.2 m
以上離れた所。前の決め方は 2 台の半径＋0.1 ＝ 0.6 m
・探すのは、いまのマスから床をたどって届く所だけ（障害物から自分の半径以上あるマスを通る。ほかの台の体の上は通らない）。
近くの 2.5 m で無ければ 5 m まで広げる。そのうち、まっすぐの距離でいちばん近い所を選ぶ
（同じ距離ならマスの番号の小さい方。乱数は使わない）
・置く所は、自分が入れるマス（free_class 1 以上）で、ほかの台・人と重ならず、椅子（引かれた椅子も）とも重ならない所
・見つからなければ今までの決め方に戻す。rescues.csv の最後に parked_fallback の列を足した（戻した回は 1、ほかは 0）
・ロボットの速さ・物理・譲る順番・人とロボットの数字・rescue_s 15 秒・30 秒の線・同じ種で同じ結果にする作りは変えていない
・メモ：依頼の「0.6 m と相手の半径」に、自分の体がかからないように自分の半径を足し、今までの離れ 0.1 m も残した
（依頼79c の案 a「今までの範囲に 0.6 m も足す」と同じ 1.2 m になる）
--------------------------------------------------------------------
2. 基準データに使わない回の一覧
--------------------------------------------------------------------
・KIOXIA の service_sim/unity/unity_ledger_v1_excluded_runs.csv（列：run_folder・理由・決めた日）
20 行（見出しを除く）。20261103_t1a〜t5b_cs65_… の 20 回（t4c・t4d を含む。台帳の unity_cs は ServiceSim/cs:65）
・judge_night.py：一覧の回を、振り分ける回からも基準データからも外す（出力フォルダが残っていても拾わない）
確かめ：--runs '20261103_t*_cs65_*' は「振り分ける回が見つからない」、det1a の 6 回はそのまま拾う
・ledger.py：excluded_folders() を足し、read_rows(..., drop_excluded=True) で外せるようにした（読み 1715 → 1695 行）。
同じ run_folder を 2 度書かない確かめ（has_row・all_folders・completed_folders）は、外さずに今までどおり見る
・台帳そのものは書き換えていない
--------------------------------------------------------------------
3. 変えたファイルと版
--------------------------------------------------------------------
cs:68 Assets/ServiceSim/Robot/ServingRobotController.cs・Service/ServiceOps.cs・Experiment/TripLogger.cs・
tools/ledger.py・tools/judge_night.py
実行ファイル：Builds/headless と Builds/rec15_standby68（どちらも build_id cs68_20261103_1303・unity_cs cs:68・保留 0）
KIOXIA：unity_ledger_v1_excluded_runs.csv を新しく作った
--------------------------------------------------------------------
4. 確かめ（画面なし・night_runner・同時 1 本・--no-retry。8 回とも completed・終了コード 0・1 回 1.2〜1.4 分）
--------------------------------------------------------------------
(1) ⑦ fam_p5・種7・ロボット2台（sb80a）
・ねらいの詰まり（依頼79c で 8869・8941・9169・9218 秒の 4 回、9156 秒から 104 秒の止まり）
→ 8869 秒の 1 回だけ。2号機を (17.49, 5.99) → (18.11, 5.99) へ 0.63 m 動かし、止まり始めから 72.4 秒で解けた
（呼ぶまで 30.0 秒＋スタッフが歩いた 20.1 秒＋動かす 15 秒ほか）。1号機は 8915 秒に往復を終えた
→ 待機場所のあたりで 30 秒以上の止まり：依頼79c は 5 回（うち 104 秒 1 回）→ 今回 3 回。
9104 秒・9705 秒にも止まりはあるが 14 秒ほどで自分で動き出した
・同じ所で何度も助け（1 m 以内・200 秒以内に 2 回以上）：0 組（依頼79c は 2 組）
・新しい決め方で動かしたのは 1 回、今までの決め方に戻したのは 0 回
・残ったもの：1163 秒と 2578 秒の待機場所の助けは、まだ 0.02 m しか動いていない（依頼79c と同じ数字）。
呼んだときは2号機が止まっていたが、スタッフが動かし終える前に2号機が次の往復に出たため（1240 秒に「卓へ」）、
動かすときには「止まっている台」でなくなり、新しい決め方の外になっている。
どちらも2号機が自分で出て行って解けた（止まり始めから 118.8 秒・60.6 秒）
・助けに行ったスタッフの瞬間移動 0 回。着けずに交代 1 回（1163 秒。依頼79c と同じ）
(2) 同じ回をもう 1 回（sb80b）
trips 121 行・stops 654 行・people_jams 516 行・yields 994 行・contacts 183 行・rescues 13 行・give_ups 63 行・
summary 309 項目、8つとも 1 行も違わない（外したのは plan_ms_max・written_at だけ。参考の 6 つも全部同じ）
(3) ③ fam_p1・⑦ fam_p5 × ロボット2台 × 種 0・3・7（sb80six。かっこ内は依頼79c の cs:67 の同じ回）
立ち往生＝60 秒で動けなくなった回数、瞬間移動＝summary.json の teleports の合計、
入店待ち＝groups.csv の waited_min の中央値（分）、料理の待ち＝dishes.csv の 届いた−できた の中央値（分）
回 立ち往生 30秒以上 瞬間移動 助け(呼んだ/動かした) 同じ所の続き 入店待ち 料理の待ち
③種0 1 (1) 12 (12) 19 (19) 10/5 (10/5) 0 (0) 1.23 (1.23) 0.94 (0.94)
③種3 3 (3) 20 (21) 31 (33) 20/14 (22/17) 4 (2) 1.36 (1.36) 1.47 (1.13)
③種7 7 (10) 28 (35) 36 (37) 26/18 (32/24) 2 (6) 1.33 (1.33) 1.44 (1.45)
⑦種0 1 (1) 20 (18) 24 (20) 20/13 (18/11) 6 (6) 1.26 (1.26) 0.86 (0.83)
⑦種3 0 (1) 7 (12) 23 (26) 7/7 (44/44) 0 (35) 1.36 (1.36) 1.34 (1.42)
⑦種7 3 (3) 13 (16) 22 (19) 13/11 (17/14) 0 (2) 1.41 (1.41) 1.43 (1.40)
6回の合計 15 (19) 100 (114) 155 (154) 96/68 (143/106) 12 (51)
・今までの決め方に戻した回：6 回とも 0。助けに行ったスタッフの瞬間移動：6 回とも 0
・⑦種3：依頼79c では (15, 6) で、止まっている2号機を 0.025 m ずつ動かす助けが 37 回続いていた（依頼79c の報告に無かった形）。
今回は 0 回。呼び出しは 44 → 7 回
・③種3・⑦種0 の「同じ所の続き」は、どれも人とロボットの助け（呼んだ台を動かす形）で、今回の直しの外。
依頼79c の回にも同じ形がある
・③種3 の交代 0 → 1（5120 秒・止まり始めから 131 秒で解けた）。ほかの回では交代は同じか減った
・瞬間移動の増えた回
⑦種0 20 → 24：客の逃がし弁 19 → 23（ドリンクバーなど）。助け・ロボットの瞬間移動は増えていない
⑦種7 19 → 22：客の逃がし弁 15 → 16、1往復の打ち切りの置き直し 2 → 4
★ ⑦種7 で増えた打ち切り 2 回（1号機の往復 117・121、どちらも卓34 行き、9063〜10261 秒）
1号機が (20.95, 6.25) で「すれ違いで下がる」状態（robot_track の backing_off=1）のまま約 500 秒止まり、
600 秒で打ち切られて置き直された。置き直したあとの往復 121 も同じ所で同じ形になった。
このとき2号機は遠く（(8.7, 6.6) や待機場所）にいて、下がる相手がいない。
stops.csv にはこの止まりが入っていない（30 秒以上の止まりにも数えられていない）。
8869 秒の助けのあと、動きの流れが前の版と変わって初めて出た形で、助けの処理の中ではなく、すれ違いの処理の中で起きている。
cs:67 の ⑦種7 の 5 回（det1a・det1b・det4a・det4b・rescue79）にはこの形は無い
--------------------------------------------------------------------
5. 台帳
--------------------------------------------------------------------
1716 行 → 1724 行（追記だけ。列は 59 のまま。先頭 1716 行の md5 は 04d9e503… で、始める前と同じ）
終わったあとの md5 3dafb380b4b46527037f948cfe494059。鍵ファイルは残っていない
追記 8 行：sb80a・sb80b 各 1、sb80six 6（どれも cs:68・completed）
記録：night/20261103_standby80_sb80a・_sb80b・_sb80six。調べに使った手順は /tmp/req80/（six.py）と /tmp/req79/（cmp.py・rescue_check.py）
--------------------------------------------------------------------
決めてほしいこと
--------------------------------------------------------------------
1. ⑦種7 の、相手がいないのに「すれ違いで下がる」状態が解けず、1往復の打ち切りになる形（瞬間移動 +2）をどうするか。
助けの直しの中ではなく、すれ違いの処理の中で起きている。案：
a. 次の依頼で、すれ違いで下がる状態に「相手がいなくなった・離れたら終える」決まりを足す（直す範囲が今回の外のため、今回は触っていない）
b. 今回の cs:68 はこのまま使い、この形は記録だけしておく
2. スタッフが着く前に、止まっていた台が次の往復に出た回（⑦種7 の 1163・2578 秒）は、今の決め方（0.02 m）のまま。
このときも 1.2 m 離す決め方を使うか（今はどちらも、出て行った台が自分で離れて解けている）
3. 動かす先の離れに、今までの 0.1 m も足して 1.2 m にした。1.1 m（0.1 m を足さない）にするか
判定：止めた（決めてほしいことあり）
````
#### 20261103_80_待機場所で止まっている台を動かす先を直す_20261103_1258.md（依頼80 の見張り係の記録）
````markdown
# 結果：20261103_80_待機場所で止まっている台を動かす先を直す
- 状態：完了
- 始めた時刻：2026-11-03 12:58
- 終わった時刻：2026-11-03 13:17（19分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume 606b900f-d6b1-4234-8218-babdaa324635`
## Claude Code の報告
**やったこと**
- 始める前の確かめはすべて依頼どおりでした（Unity エディタ・night_runner・rec_runner は止まっている、KIOXIA はマウント済み、鍵なし、保留 0、作業場所 cs:67）。台帳を退避してから回しました。
- 動かす先の決め方を直しました。止まっている台（道を持たない台）を動かすときだけ、新しい決め方を使います。
- 立ち往生した台の道の先から、相手の半径 0.25 m＋センサー 0.6 m＋自分の半径 0.25 m＋今までの離れ 0.1 m＝1.2 m 以上離します。
- その中で、床をたどって届く、いちばん近くの空いた所を選びます。止まっている台・壁・椅子・人とは重なりません。
- 届く所がなければ今までの決め方に戻し、rescues.csv の新しい列 parked_fallback に 1 を残します。
- 除外の一覧 unity_ledger_v1_excluded_runs.csv を作りました（20 行。t4c・t4d を含む cs:65 の 20 回）。judge_night.py と ledger.py は、この一覧の回を外して読みます。台帳そのものは書き換えていません。
- cs:68 で check-in し、画面なしと録画用の実行ファイルを作り直しました（build_id cs68_20261103_1303、保留 0）。続けて画面なしで 8 回回しました。
**結果**
- **⑦種7 の待機場所の詰まり**：解けました。前回は 2 回ずつ 2 組、104 秒の止まりもありましたが、今回は 8869 秒の助け 1 回だけです。2号機を 0.63 m 動かし、止まり始めから 72.4 秒で解けました。同じ所で何度も助けが要る形は 0 組です。
- **同じ回の 2 回**：8 つの記録が 1 行も違いませんでした。
- **6 回の合計**（かっこ内は依頼79c の同じ 6 回）：
- 立ち往生 15（19）
- 30 秒以上の止まり 100（114）
- 瞬間移動 155（154）
- 呼んだ助け 96（143）、動かした助け 68（106）
- 同じ所の続き 12（51）
- **入店待ちと料理の待ちの中央値**：入店待ちは 6 回とも前回と同じです（1.23〜1.41 分）。料理の待ちは 0.86〜1.47 分で、③種3 だけ 1.13 → 1.47 分と大きく増えました。ほかの 5 回は ±0.08 分以内です。
- **⑦種3**：前回の報告に書かれていなかった「0.025 m ずつ 37 回続く助け」が、今回は 0 回になりました。
- **今までの決め方に戻した回**は 0 回です。**助けに行ったスタッフの瞬間移動**も 0 回です。
- **変な動き（止めた理由）**：⑦種7 で、1往復の打ち切りによる置き直し（瞬間移動）が 2 → 4 回に増えました。
- 増えた 2 回は、1号機が「すれ違いで下がる」状態のまま (20.95, 6.25) に約 500 秒残ったものです。そのとき下がる相手のロボットは近くにいません。
- この止まりは stops.csv に入っていません。
- 起きているのは助けの処理ではなく、すれ違いの処理の中です。
- 依頼どおり、ここで止めました。
- **台帳**：1716 行 → 1724 行（追記だけ、列は 59 のまま、前の行は変わっていません）。鍵は残っていません。
**変えたファイル**
- cs:68：`ServingRobotController.cs`・`ServiceOps.cs`・`TripLogger.cs`・`tools/ledger.py`・`tools/judge_night.py`
- 実行ファイル：`Builds/headless`・`Builds/rec15_standby68`
- KIOXIA：`unity_ledger_v1_excluded_runs.csv`（新しく作った）
- 報告：`claude_code_reports/20261103_standby_rescue.txt`
**決めてほしいこと**
1. 相手がいないのに「すれ違いで下がる」状態が解けず、打ち切りになる形をどうするか。
- a. 次の依頼で直す（今回の範囲の外なので触っていません）
- b. 記録だけ残して、cs:68 をこのまま使う
2. スタッフが着く前に、止まっていた台が次の往復に出た場合（⑦種7 の 1163 秒・2578 秒）は、今の決め方では 0.02 m しか動きません。この場合も 1.2 m 離す決め方を使うか。今はどちらも、出て行った台が自分で離れて解けています。
3. 離す距離に、今までの離れ 0.1 m も足して 1.2 m にしました。足さずに 1.1 m にするか。
判定：止めた（決めてほしいことあり）
````
### 依頼81：すれ違いで下がり続ける印を消し、お客さんは移さずに道を引き直す
すれ違いの相手がいなくなっても「下がる」印だけが残り、相手のいない所で約5m下がり続けて止まっていました。下がっているあいだは「走っている」に数えていたので、止まりの記録にも出ていません。相手がいなくなったら下がる状態を抜けて道を引き直し、下がれていないときは止まりとして数えるようにしました。
お客さんの逃がし弁（60秒着けなければ席へ一瞬で戻す決まり）も外しました。60秒ごとに回り込める道を探し、なければ同じ所で待ったまま道を引き直します。ドリンクバーやトイレへ向かい始めてから180秒たったら、歩いて席へ戻ります。
⑦種7の2回とも、瞬間移動は0回になりました（依頼80の同じ回は22回）。代わりに、移さずに残った詰まりが1回の営業で合わせて26.7分になり、止める線の10分を超えました。詰まり31回はすべて、お客さんがドリンクバーから席へ戻るときで、31回とも歩いて席に着いて解けています。
ここで決めたのは、ドリンクバー帰りの混みは店が回らない印にはしない、ということです。詰まりとして記録だけ残し、店の形を直すときの手がかりにします。
#### 20261103_81_すれ違いの止まりを直し瞬間移動を0にする.md（依頼81 の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 180
---
# 依頼81：すれ違いの止まりを直し、残りの瞬間移動を0にする（昼）
エイイチと決めたこと（2026-11-03）：
- サイトに載せるシミュレーションは完璧でなくてよい。ベースとしての合格の線は次の5つ：(1) 瞬間移動0回 (2) 同じ種で同じ結果 (3) 止まったまま解けない所が残らない（30秒で助けが来て解ける）(4) 試算と向きが合う（数字の細かい差は記録だけ）(5) サイト用の図面・通しの動画・問題に寄る動画・比較動画がそろう
- Unity では瞬間移動はさせない（現実に瞬間移動はないため）
- 依頼80 の「決めてほしいこと」：1 は a（今回直す）、2 は今のまま（出て行った台が自分で離れて解けているため）、3 は 1.2 m のまま
依頼80 の報告：claude_code_reports/20261103_standby_rescue.txt。今の実行ファイルは cs68_20261103_1303。
## 始める前に確かめること（違えば手を止めて報告）
Unity エディタ・night_runner／rec_runner が動いていない、KIOXIA がマウント済み、unity_ledger_v1.lock がない、保留 0、作業場所が cs:68。台帳は退避してから回す。台帳は追記だけ。
## 1. すれ違いの止まりを直す
- ⑦ fam_p5・種7 で、1号機が相手のいない「すれ違いで下がる」状態のまま (20.95, 6.25) に約500秒残り、1往復の打ち切りになった（2回）。すれ違いの相手がいなくなったら、その状態を抜けて道を引き直すようにする
- この止まりが stops.csv に入っていなかったので、入るようにする（止まりの原因の名前を付ける）
## 2. 残りの瞬間移動を0にする（どれも、移す代わりに現実にある動きにする）
- 客の逃がし弁（ドリンクバー・トイレ・退店・会計などで60秒行き詰まると席や出口へ移す）：移さない。回り込める道があれば回り込み、なければその場の近くで待って行き直す。ドリンクバー・トイレは、行き詰まりが合わせて3分を超えたら、行かずに歩いて席へ戻る。退店・会計は、着くまで歩き続ける
- 1往復の打ち切り（600秒）の置き直し：置き直さない。打ち切りは記録だけにし、そのロボットは立ち往生として助け（30秒・15秒の決まり）で解く
- スタッフが料理などを3回あきらめたら移す：移さない。次に手が空いたスタッフに交代する（助けと同じ考え方）
- それでも動けない人・ロボットは、移さずに詰まりとして記録する（場所・時刻・秒）。summary.json に瞬間移動の回数（0のはず）と、詰まりの回数・合計秒を出す
## 3. 確かめ（画面なし）
- check-in し、画面なしと録画用の実行ファイルを作り直す（保留 0）
- ⑦ fam_p5・種7 を2回：すれ違いの止まりが解けるか、記録が1行も違わないか
- ③ fam_p1 と ⑦ fam_p5 × ロボット2台 × 種 0・3・7 を1回ずつ：瞬間移動が0回か、詰まり（移さずに残ったもの）の回数と秒、立ち往生・30秒以上の止まり・入店待ち・料理の待ちを依頼80 の同じ6回と並べる
- 瞬間移動を0にしたことで、店が回らなくなる（入店待ちや料理の待ちが依頼80 の2倍を超える、または詰まりが1回の営業で10分を超える）回が出たら、そこで止めて報告
## 変えないもの
ロボットの速さ・物理の設定・譲る順番・人とロボットの数字・rescue_s 15 秒・30 秒の線・同じ種で同じ結果にする作り・止まっている台を 1.2 m 離す決め方・台帳の列と今までの行。
## 報告
claude_code_reports/20261103_zero_warp.txt に：変えたファイルと cs・build_id、1 の直しの結果、2 で何をどう変えたか、6回の数字の表（依頼80 と並べて）、詰まりの場所の上位。
**報告の最後の1行は必ず次のどれか**：「判定：合格」／「判定：止めた（決めてほしいことあり）」／「判定：失敗」
````
#### 20261103_zero_warp.txt（依頼81 の Claude Code の報告）
````text
====================================================================
依頼81：すれ違いの止まりを直し、残りの瞬間移動を0にする
2026-11-03 13:15〜13:50 check-in：cs:69 build_id cs69_20261103_1337（画面なし・録画用とも。保留 0）
====================================================================
結論
・瞬間移動は 0 回になった（⑦種7 の2回とも。依頼80 の同じ回は 22 回）
・1 のすれ違いの止まりは出なくなった。1往復の打ち切り 4 → 0。相手がいなくなって下がりを抜け、道を引き直した回が 10 回
・同じ種の2回は、記録が1行も違わない（違ったのは時間を測る列 plan_ms_max と written_at だけ。依頼80 と同じ扱い）
・ただし、移さずに残った詰まりが 1 回の営業で合わせて 1601 秒（26.7 分）になり、止める線の 10 分を超えた。
依頼どおり、③⑦×種0・3・7 の6回は回さずに止めた
（詰まり 31 回はすべて、客がドリンクバーから席へ戻るとき。最長 223 秒。31 回とも歩いて席に着いて解けている。
回の終わりまで解けずに残ったのは 0）
--------------------------------------------------------------------
0. 始める前の確かめ（どれも依頼どおり）
--------------------------------------------------------------------
Unity エディタ・night_runner・rec_runner：動いていない（Unity Hub だけ）／KIOXIA：マウント済み／
unity_ledger_v1.lock：無し／保留 0／作業場所 cs:68 - head
台帳を archive/unity_ledger_v1_pre_zero_warp_20261103/ に退避（1724 行・md5 3dafb380b4b46527037f948cfe494059。依頼80 の終わりと同じ）
--------------------------------------------------------------------
1. すれ違いの止まりの直し（Robot/ServingRobotController.cs）
--------------------------------------------------------------------
原因：すれ違いの相手がいなくなる（離れる・譲りに入る・もう向かってこない）と相手の記録は消えるが、
「下がる」印だけが残った。そのため相手のいない所で下がり続け（依頼80 の ⑦種7 では 15.97 → 20.95 m の約 5 m）、
下がれなくなった所で止まった。下がっているあいだは速さを「走っている」側に数えていたので、stops.csv にも入らなかった
直し：
・相手がいなくなったら、下がる状態を抜けて道を引き直す（EndPassByBackOff）
・下がる状態のまま 1 コマで 1 mm も下がれていないときは「止まり」として数える。
stops.csv の原因の名前は「すれ違いで下がった」（新しく足した。ほかの原因の名前は変えていない）。
止まりとして数えるので、30 秒で助けを呼ぶ・60 秒で動けなくなる、の今の決まりがそのまま効く
結果（⑦ fam_p5・種7）：
・1号機が (20.95, 6.25) にいた回は 0（その場所の近くに 1 度も行っていない）
・下がる印が立っていたのは 4 回、どれも 5 秒以内に消えた
・1往復の打ち切り 4 → 0。下がりを抜けて道を引き直した回 10 回。「すれ違いで下がった」止まり 0 回
・注意：直したことで動きの流れが変わり、依頼80 と同じ場面（9063 秒以降の卓34 行き）はもう起きていない。
直しが「同じ場面を解いた」ことではなく「その形がもう出ない」ことを確かめた
--------------------------------------------------------------------
2. 瞬間移動を 0 にした直し
--------------------------------------------------------------------
(1) 客の逃がし弁（People/GuestAgent.cs）
・移さない。60 秒（guestGiveUpSec・guestWarpHomeSec。数字は変えていない）着けないごとに、
回り込める道があれば回り込み、なければ同じ所で待ったまま行き先へ道を引き直す
（回り込みの探し方は助けに行くスタッフ（依頼79c）と同じ。ロボットぜんぶと、1.2 m 以内のいちばん近い人を避ける。
客の入れない区画（レジの内側）を通る道は使わない）
・ドリンクバー・トイレの行き：行き詰まりが合わせて 3 分（180 秒）を超えたら、行かずに歩いて席へ戻る
（前は 60 秒で席へ戻っていた。今は 60 秒・120 秒で行き直し、180 秒で戻る）
・帰り・退店・会計の行き：着くまで歩き続ける
(2) 1往復の打ち切り（600 秒）：置き直さない・往復も終えない。trips.csv の timeout=1 として記録だけして往復を続け、
止まっていれば今の助けの決まり（30 秒で呼ぶ・rescue_s 15 秒）で解く
(3) スタッフが同じ仕事を 3 回あきらめたら：移さない。give_ups.csv に「交代した」と残し、その人を外して仕事を板へ戻す。
次に手が空いた別のスタッフが取る（助けの交代と同じく、全員が一度ずつ交代したら、また全員が取れるようにする）。
※ 台帳の gave_up の列には「交代した」も入る（前は warped に入っていた分）
(4) 移さずに残った詰まりの記録
・前なら瞬間移動していた時刻から、解ける（着く・仕事が終わる・往復が終わる）までを 1 回とする
（客＝帰り・退店・会計で初めて行き直した時刻から。スタッフ＝初めて交代した時刻から。ロボット＝打ち切りの時刻から）
・nowarp_jams.csv（新しい。列：condition_id, seed, t_s, who, job, id, x, z, aisle, end_t_s, duration_s, outcome）
・summary.json：teleports に total（足した数）を足した。nowarp_jams（count・total_s・max_s・open_at_end・
guest_detours・guest_retries・pass_by_backoff_ends）を足した
変えていないもの：ロボットの速さ・物理の設定・譲る順番・人とロボットの数字・rescue_s 15 秒・30 秒の線・
同じ種で同じ結果にする作り・止まっている台を 1.2 m 離す決め方・台帳の列と今までの行
--------------------------------------------------------------------
3. 変えたファイル・版
--------------------------------------------------------------------
cs:69 Assets/ServiceSim/Robot/ServingRobotController.cs・People/GuestAgent.cs・People/StaffAgent.cs・
Service/ServiceOps.cs・Experiment/TripLogger.cs・Experiment/ExperimentRunner.cs
実行ファイル：Builds/headless と Builds/rec16_zerowarp69（新しいフォルダ）。どちらも build_id cs69_20261103_1337・
unity_cs ServiceSim/cs:69・pending_changes 空・error CS 0。前の録画用 rec15_standby68 は残した
check-in の前に /tmp/ss81_compiletest に試しのビルドを作り、error CS 0 を確かめた
--------------------------------------------------------------------
4. 確かめ（画面なし・night_runner・同時 1 本・--no-retry。2 回とも completed・終了コード 0・1.4〜1.5 分）
--------------------------------------------------------------------
(1) ⑦ fam_p5・種7（zw81a）・(2) 同じ回をもう 1 回（zw81b）
trips 123・stops 1124・people_jams 920・yields 2938・contacts 162・rescues 28・give_ups 55・nowarp_jams 31・
dishes 209・groups 81・robot_track 4722 行、どれも 1 行も違わない。summary.json も同じ
（trips.csv の plan_ms_max・summary.json の written_at だけ違う。どちらも計算にかかった実時間）
(3) 6回：回していない（下の止めた理由のため）。並べられるのは ⑦種7 だけ
回 立ち往生 30秒以上 瞬間移動 詰まり(回/秒/最長) 入店待ち 料理の待ち 打ち切り
⑦種7 今回(cs:69) 8 25 0 31 / 1601 / 223 1.45 1.30 0
⑦種7 依頼80(cs:68) 3 13 22 （記録なし） 1.41 1.43 4
（立ち往生＝stops.csv の「動けなくなった」の数、30秒以上＝stops.csv の 30 秒以上の行、入店待ち・料理の待ちは中央値（分））
・入店待ち・料理の待ちは 2 倍の線に届いていない。詰まりの合計が 10 分の線を超えた
・立ち往生 3 → 8、30 秒以上の止まり 13 → 25 に増えた。客が席へ移されずに歩いて戻る・ドリンクバーで 3 分まで
行き直すようになり、通路にいる人が増えたことが考えられるが、確かめていない（1 回だけなのでばらつきと区別できない）
・give_ups：ドリンクバーで 3 分であきらめて席へ戻った客 34（依頼80 は 60 秒であきらめた 27＋移した 13）。
スタッフの「交代した」0、ロボットの打ち切り 0。詰まり 31 回はすべて客のドリンクバーの帰り
詰まりの場所の上位（⑦種7・1 m のマスで丸めた位置・回数・合計秒）
1. (5, 4) 5 回 690 秒 ドリンクバーの前（4.1〜4.5 m の列）
2. (5, 6) 1 回 223 秒 通路 A02
3. (6, 5) 4 回 203 秒 ドリンクバーの前
4. (5, 12) 3 回 188 秒 通路 A02
5. (8, 5) 3 回 112 秒
60 秒以上かかった詰まりは 9 回で合計 1242 秒（全体の 78%）。2336〜2578 秒に卓1・3・4 の 5 人がドリンクバーの前で重なり、
1 回で 100〜223 秒かかった分が大きい
--------------------------------------------------------------------
5. 台帳
--------------------------------------------------------------------
1724 行 → 1726 行（追記だけ。列は 59 のまま。先頭 1724 行の md5 は 3dafb380… で、始める前と同じ）
終わったあとの md5 d2f24b6e2125b42a12a58e495e53ee54。鍵ファイルは残っていない
追記 2 行：zw81a・zw81b（どちらも cs:69・completed）
記録：night/20261103_zerowarp81_zw81a・_zw81b。調べに使った手順と並べた回は /tmp/req81/（six.py・q/。q/zw81six.json は回していない）
--------------------------------------------------------------------
決めてほしいこと
--------------------------------------------------------------------
1. 詰まりの 10 分の線を超えた（26.7 分。すべて客のドリンクバーの帰り、どれも最後は歩いて席に着いている）。どうするか。案：
a. このまま進め、6 回を回して並べる（今の回は「止まったまま解けない所」は 0。帰りが長びくのは、
ドリンクバーの前の混み方として記録する）
b. ドリンクバーの前の混みを減らす直しを先にする（例：帰りで行き詰まったときに待つ所を通路の外にする など。直し方は相談）
c. 詰まりの数え方を変える（今は「前なら移していた 60 秒の時刻」から着くまでを数えている。例：その場で止まっていた秒だけを数える）
2. ドリンクバー・トイレの行きの「3 分」は、行き始めからの秒（60 秒・120 秒で行き直し、180 秒で戻る）として入れた。
前は 60 秒で席へ戻っていた。この読み方でよいか
3. 依頼の 4 つのほかに、画面で跳んで見える動きが 1 つ残っている：立ち往生の助けで、スタッフが 15 秒かけてロボットを動かす場面は、
15 秒のあと最後に動かした先（最大 1.2 m ほど）へ置いている（依頼76・80 からの作り。summary.json の瞬間移動には入れていない）。
これも少しずつ動く形にするか
（ほかに、客が席を立つときに体を席の前に出すこと・人の体を道の面に乗せ直す小さな寄せがあるが、どちらも数 cm〜席の前の出し入れで、今は瞬間移動として数えていない）
判定：止めた（決めてほしいことあり）
````
#### 20261103_81_すれ違いの止まりを直し瞬間移動を0にする_20261103_1321.md（依頼81 の見張り係の記録）
````markdown
# 結果：20261103_81_すれ違いの止まりを直し瞬間移動を0にする
- 状態：完了
- 始めた時刻：2026-11-03 13:21
- 終わった時刻：2026-11-03 13:43（22分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume 6432ed46-b270-4928-9f58-1d0da6d12ecf`
## Claude Code の報告
**やったこと**
- 始める前の確かめはすべて依頼どおりでした（Unity エディタも実行係も動いていない、KIOXIA はマウント済み、鍵ファイルなし、保留 0、cs:68）。台帳は archive/unity_ledger_v1_pre_zero_warp_20261103/ に退避しました。
- **1 のすれ違いの止まり**：原因は、すれ違いの相手がいなくなっても「下がる」印だけが残り、相手のいない所で下がり続けて止まることでした。相手がいなくなったら下がる状態を抜けて、道を引き直すようにしました。下がろうとしても動けない間は止まりとして数え、stops.csv に原因「すれ違いで下がった」で入るようにしました。
- **2 の瞬間移動を0に**：
- 客：60秒ごとに、回り込める道があれば回り込み、なければその場で道を引き直します。ドリンクバー・トイレの行きは3分で歩いて席へ戻ります。帰り・退店・会計は着くまで歩き続けます。
- 1往復の打ち切り：記録だけにして往復を続け、止まっていれば助けの決まり（30秒で呼ぶ・15秒で動かす）で解きます。
- スタッフが3回あきらめたとき：その人を外し、次に手が空いた別のスタッフに交代します。
- 移さずに残った詰まりは nowarp_jams.csv（新しく作ったファイル）と summary.json に出します。
- check-in して cs:69 にし、画面なしと録画用の実行ファイルを作り直しました（build_id cs69_20261103_1337、保留 0、文法の誤り 0）。⑦ fam_p5・種7 を2回回しました。
**結果**
- **瞬間移動**：0回（依頼80 の同じ回は 22回）。
- **1 の直し**：1往復の打ち切りは 4 → 0 回、相手がいなくなって下がりを抜けた回は 10回でした。1号機が (20.95, 6.25) に行った回は 0 です。ただし直しで動きの流れが変わり、依頼80 と同じ場面はもう起きていません。確かめられたのは「この形がもう出ない」ことで、「同じ場面が解けた」ことではありません。
- **同じ種の2回**：記録はすべて1行も違いませんでした。違ったのは計算にかかった実時間の列（plan_ms_max・written_at）だけで、依頼80 と同じ扱いです。
- **止めた理由**：移さずに残った詰まりが 31回・合計 1601秒（26.7分）で、止める線の10分を超えました。そのため ③⑦×種0・3・7 の6回は回していません。
- 31回すべてが、客がドリンクバーから席へ戻るときのものです。最長は 223秒で、どれも最後は歩いて席に着き、解けずに残ったものは 0 です。
- 多い場所はドリンクバーの前 (5, 4) で、5回・690秒でした。
- **依頼80 の同じ回との比べ（⑦種7）**：
| | 今回（cs:69） | 依頼80（cs:68） |
|---|---|---|
| 入店待ち（中央値・分） | 1.45 | 1.41 |
| 料理の待ち（中央値・分） | 1.30 | 1.43 |
| 立ち往生 | 8 | 3 |
| 30秒以上の止まり | 25 | 13 |
- 入店待ち・料理の待ちは2倍の線に届いていません。
- 立ち往生と30秒以上の止まりは増えました。理由は確かめていません。1回だけなので、ばらつきとも区別できません。
- **台帳**：1724 → 1726行で、追記だけです。もとの1724行は始める前と同じです（md5 3dafb380…）。
**変えたファイル**
- cs:69：
- Robot/ServingRobotController.cs
- People/GuestAgent.cs
- People/StaffAgent.cs
- Service/ServiceOps.cs
- Experiment/TripLogger.cs
- Experiment/ExperimentRunner.cs
- 実行ファイル：Builds/headless と Builds/rec16_zerowarp69（新しいフォルダ）
- 報告：claude_code_reports/20261103_zero_warp.txt
**決めてほしいこと**
1. 詰まりが10分の線を超えました（26.7分。すべてドリンクバーの帰りで、最後は全員席に着いています）。次の3つのどれにしますか。
- a：このまま6回を回して並べる
- b：ドリンクバーの前の混みを減らす直しを先にする
- c：詰まりの数え方を変える（たとえば、その場で止まっていた秒だけを数える）
2. ドリンクバー・トイレの「3分」は、行き始めからの秒として入れました。60秒と120秒で行き直し、180秒で席へ戻ります。前は60秒で席へ戻っていました。この読み方でよいですか。
3. 立ち往生の助けでスタッフがロボットを動かす場面は、15秒のあと動かした先（最大1.2 m ほど）へまとめて置いているので、画面では跳んで見えます。依頼76・80 からの作りで、今は瞬間移動の数に入れていません。これも少しずつ動く形にしますか。
判定：止めた（決めてほしいことあり）
````
### 依頼82：助けでロボットを動かすときも、スタッフが0.5m/秒で押す
最後に残った瞬間移動は、助けそのものでした。15秒の作業が終わった瞬間に、ロボットを1.2m先へ置いていたからです。これを、動かす先は同じ決め方で決め、スタッフが0.5m/秒（お客さん0.8m/秒・スタッフ1.0m/秒の歩く速さより遅い）で床をたどって押す形に変えました。押しているあいだは止まりに数えます。1コマで動ける距離より大きく動いたロボットを数える見張り（robot_frame_jumps）も足しました。
- ねらい：現実の店にない動きを、シミュレーションから全部なくす
- 変わったこと：③⑦×種0・3・7の6回と、ロボット0台・1台の4回、合わせて12回とも、瞬間移動0回・1コマの跳び0回・解けずに残った人とロボット0
- 見込める効果（測った値と見込み）：③⑦ロボット2台の瞬間移動は、最初の版（10/23）の66回から0回になった。代わりに、前は移して消していたふさぎが止まりとして数字に出る。6回の合計で、立ち往生は15回から39回、30秒以上の止まりは100回から132回に増えた。前は見えていなかった止まりが見えるようになったのであって、店が悪くなったわけではない、という見込み
判定は合格でした。
#### 20261103_82_6回で瞬間移動0を確かめ助けの動きを滑らかにする.md（依頼82 の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 120
---
# 依頼82：ほかの店と種でも瞬間移動0を確かめ、助けでロボットを動かすときも跳ばずに動かす（昼）
エイイチと決めた方針（2026-11-03）：サイトのシミュレーションは完璧でなくてよい。ベースの合格の線は (1) 瞬間移動0回 (2) 同じ種で同じ結果 (3) 止まったまま解けない所が残らない (4) 試算と向きが合う（細かい差は記録だけ）(5) サイト用の図面・動画がそろう。現実に瞬間移動はないので Unity でもさせない。
依頼81 の報告：claude_code_reports/20261103_zero_warp.txt。今の実行ファイルは cs69_20261103_1337。
依頼81 の「決めてほしいこと」への答え（Claude が合格の線に沿って決めた）：
- 1 は a。ドリンクバーの帰りの混み（最後は全員席に着く）は、店が回らない印にはしない。詰まりとして記録だけ残し、店の形を直すときの手がかりにする。止める線は「解けずに残った人・ロボットが出る」か「入店待ち・料理の待ちが依頼80 の2倍を超える」だけにする
- 2 は今の読み方でよい（行き始めから60秒・120秒で行き直し、180秒で歩いて席へ戻る）
- 3 は直す。助けでスタッフがロボットを動かすときも、跳ばずに、スタッフが押す速さ（人の歩く速さより遅く）で少しずつ動かす。動かしている間は止まりに数える
## 始める前に確かめること（違えば手を止めて報告）
Unity エディタ・night_runner／rec_runner が動いていない、KIOXIA がマウント済み、unity_ledger_v1.lock がない、保留 0、作業場所が cs:69。台帳は退避してから回す。台帳は追記だけ。
## やること
1. 上の 3 を入れる。check-in し、画面なしと録画用の実行ファイルを作り直す（保留 0）
2. 確かめ（画面なし）
- ⑦ fam_p5・種7 を2回：記録が1行も違わないこと
- ③ fam_p1 と ⑦ fam_p5 × ロボット2台 × 種 0・3・7 を1回ずつ：瞬間移動（助けの動きを含む）が0回か、解けずに残った人・ロボットが0か。詰まりの回数・秒・場所の上位、立ち往生、30秒以上の止まり、入店待ち・料理の待ちの中央値を依頼80 の同じ6回と並べる
- ロボット0台・1台も、③⑦ × 種0 で1回ずつ回し、瞬間移動0と、解けずに残ったものが0かだけ見る
## 変えないもの
ロボットの速さ・物理の設定・譲る順番・人とロボットの数字・rescue_s 15 秒・30 秒の線・同じ種で同じ結果にする作り・止まっている台を 1.2 m 離す決め方・依頼81 の瞬間移動をなくした作り・台帳の列と今までの行。
## 報告
claude_code_reports/20261103_zero_warp2.txt に：変えたファイルと cs・build_id、2回の一致、6回の表（依頼80 と並べて）、0台・1台の結果、詰まりの場所の上位。
**報告の最後の1行は必ず次のどれか**：「判定：合格」／「判定：止めた（決めてほしいことあり）」／「判定：失敗」
````
#### 20261103_zero_warp2.txt（依頼82 の Claude Code の報告）
````text
====================================================================
依頼82：ほかの店と種でも瞬間移動0を確かめ、助けでロボットを動かすときも跳ばずに動かす
2026-11-03 13:50〜14:20 check-in：cs:70 build_id cs70_20261103_1359（画面なし・録画用とも。保留 0）
====================================================================
結論
・助けでスタッフがロボットを動かすとき、置かずに、押す速さ 0.5 m/秒 で床をたどって少しずつ動かすようにした。
動かしているあいだは止まりに数える
・同じ種の2回（⑦種7）は、記録が1行も違わない（違ったのは時刻 written_at・計算にかかった時間 plan_ms_max・
wall_seconds・run_label だけ。依頼80・81 と同じ扱い）
・6回（③⑦×種0・3・7）と0台・1台の4回、合わせて12回とも：瞬間移動 0（助けの動きを含む）・
1コマの跳びの見張り 0・解けずに残った人・ロボット 0・全員帰った
・入店待ち・料理の待ちの中央値は、どの回も依頼80 の2倍に届いていない
--------------------------------------------------------------------
0. 始める前の確かめ（どれも依頼どおり）
--------------------------------------------------------------------
Unity エディタ・night_runner・rec_runner：動いていない（Unity Hub だけ）／KIOXIA：マウント済み／
unity_ledger_v1.lock：無し／保留 0／作業場所 cs:69 - head
台帳を archive/unity_ledger_v1_pre_push82_20261103/ に退避（1726 行・md5 d2f24b6e2125b42a12a58e495e53ee54。依頼81 の終わりと同じ）
--------------------------------------------------------------------
1. 直したこと（助けの動き）
--------------------------------------------------------------------
前：rescue_s（15 秒）が終わった瞬間に、動かす先（最大 1.2 m ほど）へ置いていた（依頼76・80 からの作り）
今：
・rescue_s（15 秒）が終わった時刻に、今までと同じ決め方で動かす先を決める（決め方は変えていない）
・そこから、スタッフが押す速さ 0.5 m/秒 で、床をたどる道に沿って動かす
（道は地図のマスをたどる。体が入る幅のマスで、ほかの台の体の上は通らない。まっすぐ通れる所は角を飛ばす。
道が見つからないときだけまっすぐ押す ― 今回の12回では 0 回）
・押す速さ 0.5 m/秒 は、人の歩く速さ（客 0.8・スタッフ 1.0）より遅い。人がロボットをよけるときの
横移動の速さ（PeopleSpec.robotNudgeSpeedMps）と同じ値にした（下の「確かめてほしいこと」）
・押しているあいだは止まりに数える：速さ 0。往復中の台は、続いている止まりの記録（stops.csv）・
動けなくなった待ちの秒にそのまま足す。押し終わってから止まりの記録を閉じ、走りを続ける
・押しているあいだ、その台に次の往復を渡さない・待機場所へ戻さない。スタッフは台について歩き、押し終わってから次の仕事へ
・助けの終わりの時刻は押し終わった時刻にした（rescues.csv の work_s・resolve_s は 15 秒＋押した秒になる）
記録に足したもの（台帳の列は変えていない）：
・rescues.csv の終わりに push_s・push_m・push_straight
・summary.json に rescue_push（count・total_s・max_s・total_m・straight・speed_mps）
・summary.json の teleports に robot_frame_jumps・robot_frame_jump_max_m（見張り。total には足さない）
＝ 1コマで、いちばん速い速さで動ける距離の 1.5 倍＋5 cm より大きく動いたロボットの回数。回の始めの並べ置きは数えない
変えていないもの：ロボットの速さ・物理の設定・譲る順番・人とロボットの数字・rescue_s 15 秒・30 秒の線・
同じ種で同じ結果にする作り・止まっている台を 1.2 m 離す決め方・依頼81 の瞬間移動をなくした作り・
台帳の列と今までの行
--------------------------------------------------------------------
2. 変えたファイル・版
--------------------------------------------------------------------
cs:70 Assets/ServiceSim/Robot/ServingRobotController.cs・Service/ServiceOps.cs・People/StaffAgent.cs・
Experiment/ExperimentRunner.cs・Experiment/TripLogger.cs
実行ファイル：Builds/headless と Builds/rec17_push70（新しいフォルダ）。どちらも build_id cs70_20261103_1359・
unity_cs ServiceSim/cs:70・pending_changes 空・error CS 0。前の録画用 rec16_zerowarp69 は残した
check-in の前に /tmp/ss82_compiletest に試しのビルドを作り、error CS 0 を確かめた
--------------------------------------------------------------------
3. 確かめ（画面なし・night_runner・同時 1 本・--no-retry。12 回とも completed・終了コード 0・0.8〜1.4 分）
--------------------------------------------------------------------
(1) ⑦ fam_p5・種7 を2回（zw82a・zw82b）
trips 119・stops 1136・people_jams 1316・yields 3150・contacts 160・rescues 26・give_ups 66・nowarp_jams 31・
dishes 210・groups 82・robot_track 4777・passes 67・timeline 200 行、どれも 1 行も違わない
（trips.csv の plan_ms_max、summary.json・conditions.json の written_at、run_info.json の run_label・written_at・
wall_seconds・speedup・plan_ms_max_per_trip だけ違う。どれも名札か計算にかかった実時間）
(2) 6回（ロボット2台）。上が今回（cs:70）、下が依頼80（cs:68）の同じ回
回 立ち往生 30秒以上 瞬間移動 見張り 詰まり(回/秒/最長/残り) 入店待ち 料理の待ち 打ち切り 押した(回/最長秒)
③種0 今回 6 16 0 0 33 / 904 / 85 / 0 1.30 1.09 0 15 / 1.3
③種0 依頼80 1 12 19 ― （記録なし） 1.23 0.94 0
⑦種0 今回 4 24 0 0 36 / 1983 / 487 / 0 1.25 0.92 1 21 / 1.1
⑦種0 依頼80 1 20 24 ― （記録なし） 1.26 0.86 0
③種3 今回 9 28 0 0 30 / 789 / 100 / 0 1.40 1.16 0 21 / 2.7
③種3 依頼80 3 20 31 ― （記録なし） 1.36 1.47 1
⑦種3 今回 2 16 0 0 23 / 792 / 110 / 0 1.33 1.04 0 12 / 1.8
⑦種3 依頼80 0 7 23 ― （記録なし） 1.36 1.34 6
③種7 今回 6 23 0 0 34 / 1848 / 461 / 0 1.31 1.50 0 18 / 1.9
③種7 依頼80 7 28 36 ― （記録なし） 1.33 1.44 0
⑦種7 今回 12 25 0 0 30 / 2941 / 388 / 0 1.44 1.53 1 22 / 2.8
⑦種7 依頼80 3 13 22 ― （記録なし） 1.41 1.43 4
合計 今回 39 132 0 0 186 / 9255 2 109
合計 依頼80 15 100 155
（立ち往生＝stops.csv の「動けなくなった」の数、30秒以上＝stops.csv の 30 秒以上の行、
瞬間移動＝summary.json の teleports の内訳の和、見張り＝teleports.robot_frame_jumps、
入店待ち・料理の待ちは中央値（分）、打ち切り＝trips.csv の timeout=1（記録だけ。置き直していない））
・瞬間移動は 155 → 0。押した 109 回はどれも床をたどる道で押せた（まっすぐ押した 0）。押した道は 1 回で最長 1.4 m・2.8 秒
・解けずに残った人・ロボット：0（どの回も nowarp_jams の残り 0・rescues の「終わる前に回が終わった」0・全員帰った）
・入店待ち・料理の待ちは、どの回も依頼80 の 2 倍に届いていない（いちばん大きいのは ⑦種7 の料理の待ち 1.43 → 1.53）
・立ち往生は 15 → 39、30 秒以上の止まりは 100 → 132 に増えた。依頼80 は客・スタッフ・ロボットを移して
ふさぎを消していた分が、今は止まって助けで解く形になったためと考えられるが、確かめていない。
どれも助け（30 秒で呼ぶ・rescue_s）か歩き直しで解けている
・詰まり 186 回の内訳：客のドリンクバー 149 回 5898 秒・退店 18 回 585 秒・トイレ 6 回 431 秒・会計 6 回 364 秒・
スタッフの片付け 5 回 1818 秒（⑦種0 に 3 回・⑦種7 と ③種7 に 1 回ずつ。どれも仕事を終えたか外して解けた）・
ロボットの1往復の打ち切り 2 回 159 秒
(3) 0台・1台（③⑦×種0）：瞬間移動と解けずに残ったものだけ見る
回 瞬間移動 見張り 解けずに残った 全員帰った （参考：詰まり 回/秒、押した回）
③0台種0 0 0 0 はい 0 / 0、0
⑦0台種0 0 0 0 はい 1 / 2、0
③1台種0 0 0 0 はい 19 / 499、14
⑦1台種0 0 0 0 はい 26 / 706、9
--------------------------------------------------------------------
4. 詰まりの場所の上位（6回の合計・1 m のマスで丸めた位置・回数・合計秒）
--------------------------------------------------------------------
1. (5, 5) 14 回 1230 秒 ドリンクバーの前（一部は通路 A02）
2. (5, 4) 8 回 1124 秒 ドリンクバーの前
3. (6, 5) 10 回 980 秒 ドリンクバーの前
4. (7, 5) 23 回 880 秒
5. (9, 5) 10 回 853 秒
6. (6, 4) 6 回 487 秒
回ごとの上位：⑦種7 (5,5) 791 秒・(5,4) 780 秒、⑦種0 (6,5) 893 秒・(6,4) 370 秒、③種7 (9,5) 461 秒（スタッフの片付け 1 回）。
依頼81 と同じく、ドリンクバーの前（x 4〜7・z 4〜5）に集まっている。決めたとおり記録だけ残す
--------------------------------------------------------------------
5. 台帳
--------------------------------------------------------------------
1726 行 → 1738 行（追記だけ。列は 59 のまま。先頭 1726 行の md5 は d2f24b6e… で、始める前と同じ）
終わったあとの md5 19a431ce554b4a087402e852ec3ad03e。鍵ファイルは残っていない
追記 12 行：zw82a・zw82b・zw82six×6・zw82r01×4（どれも cs:70・completed）
記録：night/20261103_push82_zw82a・_zw82b・_zw82six・_zw82r01。並べた回と集計の手順は /tmp/req82/（q/・six82.py）
--------------------------------------------------------------------
確かめてほしいこと（止めずに進めた）
--------------------------------------------------------------------
1. 押す速さを 0.5 m/秒 にした（依頼の「人の歩く速さより遅く」に合わせ、人がロボットをよける横移動の速さと同じ値を使った）。
今回の押しは 1 回で最長 2.8 秒なので、0.3〜0.5 m/秒 のどれにしても助けの秒はほとんど変わらない。別の値がよければ変える
2. 押す時間は rescue_s（15 秒）のあとに足した（15 秒で動かす先を決める今までの時刻を変えないため）。
助け 1 回はその分（最長 2.8 秒）長くなる。15 秒の中に押す時間も含める形がよければ変える
判定：合格
````
#### 20261103_82_6回で瞬間移動0を確かめ助けの動きを滑らかにする_20261103_1349.md（依頼82 の見張り係の記録）
````markdown
# 結果：20261103_82_6回で瞬間移動0を確かめ助けの動きを滑らかにする
- 状態：完了
- 始めた時刻：2026-11-03 13:49
- 終わった時刻：2026-11-03 14:16（27分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume d8e12514-8b02-413e-920f-5bb328a01f82`
## Claude Code の報告
**やったこと**
- 始める前の確かめはすべて依頼どおりでした。Unity エディタと実行係は動いていない、KIOXIA はつながっている、鍵ファイルはない、保留0、作業場所は cs:69 でした。台帳は `archive/unity_ledger_v1_pre_push82_20261103/` に退避しました（1726行）。
- 助けでスタッフがロボットを動かすとき、置かずに動かすようにしました。15秒（rescue_s）のあと、今までと同じ決め方で動かす先を決め、そこまで床をたどる道に沿って 0.5 m/秒で押します。押している間は止まりに数えます。押している間はその台に次の往復を渡さず、スタッフは台について歩きます。
- 記録を2つ足しました。押した秒・道の長さと、1コマで跳んだロボットを数える見張りです。台帳の列は変えていません。
- 試しのビルドでエラー0を確かめてから check-in し、cs:70 になりました（保留0）。画面なし用と録画用（`Builds/rec17_push70`）の実行ファイルを作り直しました。build_id はどちらも cs70_20261103_1359 です。
- 画面なしで、同じ種の2回・6回・0台と1台の4回、合わせて12回を回しました。12回とも最後まで回り、終了コードは0でした。
**結果**
- **同じ種の2回（⑦種7）：** 記録は1行も違いませんでした。違ったのは書いた時刻・名札・計算にかかった時間の列だけです。
- **瞬間移動：** 依頼80 の同じ6回では合わせて155回でした。今回は0回で、跳びの見張りも0です。押した109回はすべて床をたどる道で押せて、1回で最長1.4 m・2.8秒でした。
- **解けずに残った人・ロボット：** 12回とも0で、全員が帰りました。
- **待ち時間：** 入店待ち・料理の待ちの中央値は、どの回も依頼80 の2倍に届いていません。いちばん増えたのは⑦種7の料理の待ちで、1.43分から1.53分です。
- **増えたもの：** 6回の合計で、立ち往生は15回から39回、30秒以上の止まりは100回から132回に増えました。前は人やロボットを移してふさぎを消していた分が、今は止まって助けで解く形になったためと考えていますが、確かめてはいません。どれも助けか歩き直しで解けています。
- **詰まり：** 6回で186回、合わせて9255秒です。場所の上位はドリンクバーの前で、(5,5)が1230秒、(5,4)が1124秒、(6,5)が980秒です。決めたとおり記録だけ残しています。
- **台帳：** 1726行から1738行になりました。追記だけで、前の行は退避前と同じ、列は59のまま、鍵ファイルも残っていません。
- 報告は `claude_code_reports/20261103_zero_warp2.txt` に書きました。最後の行は「判定：合格」です。
**変えたファイル**
- `Assets/ServiceSim/Robot/ServingRobotController.cs`
- `Assets/ServiceSim/Service/ServiceOps.cs`
- `Assets/ServiceSim/People/StaffAgent.cs`
- `Assets/ServiceSim/Experiment/ExperimentRunner.cs`
- `Assets/ServiceSim/Experiment/TripLogger.cs`
- `claude_code_reports/20261103_zero_warp2.txt`（新しく作成）
**決めてほしいこと**
次の2つは私が決めて先へ進めました。違っていれば直します。
1. 押す速さを 0.5 m/秒にしました。依頼の「人の歩く速さより遅く」に合わせ、人がロボットをよけて横へ動く速さと同じ値を使いました。押す時間は1回で最長2.8秒なので、0.3〜0.5 m/秒のどれにしても結果はほとんど変わりません。
2. 押す時間は15秒（rescue_s）のあとに足しました。動かす先を決める時刻を今までと同じにするためで、助け1回はその分（最長2.8秒）長くなります。15秒の中に押す時間も含める形にもできます。
````
【画像】LOG435_02_report_teleport.png 報告動画の1枚。③⑦の店・ロボット2台の瞬間移動の回数が、10/23 の最初の版の66回から、依頼82・83・84 で0回になった折れ線
最初の版から依頼84までの、版ごとの数字の動きを図にしました。版を選ぶと、その版で何を直したかと4つの数字が出ます。
【図解】LOG435_versions.html
## 作業ログ ― サイトのシミュレーションは完璧でなくてよい、と合格の線を5つに決めた
依頼82のあと、Unity をどこまで作り込むかの線を決めました。きっかけは、後半に店が空いてくるとロボットの出番が少なくなる理由を聞かれたことです。今の Unity は配膳（料理を運ぶ）だけで、下げ膳（食べ終えた器を下げる）をロボットにさせていません。店の現場の流れから見た答えは、こうでした。
> お店って一回忙しくなってピークがくると洗い場にお皿が溜まったりしてくるんだよね。ピークが終わってお客さんが弾けた頃に下げ膳でロボットが活躍してくれて、スタッフが次の準備にスムーズに取り掛かれるようになるのが理想。
> もし配膳をロボットだけで行っている場合、この料理だしの後に途中でお皿を下げるのがなくなるので、お客さんが帰った後に一気にお皿を下げるというのが頻発する可能性はありますね。
> ロボットを入れる台数が多くなるほど、一気にテーブルのお皿を下げる機会が増えるというのは覚えておいた方がいいです。今はシミュレーションにそこまで細かく入れ込む必要はない（シミュレーションを本格的に頼みたい企業が現れたらそういった詳細なシミュレーションを有料で行いますとした方がビジネス的に良さそう）
> あまり完璧を目指さずまずはベースを作り上げるというのを大事にしてサイト内に図面や動画、比較動画などを充実させることを優先してください。
これを受けて、配膳ロボットの店ごとに、ベースとして合格とする線を5つ決めました（了承済み）。
| 合格の線 | 中身 |
|---|---|
| 1 | 瞬間移動が0回 |
| 2 | 同じ種なら同じ結果 |
| 3 | 止まったまま解けない所が残らない（30秒の助けで解ける） |
| 4 | ロボットを足したときの向きが、サイトの試算と合う。細かい差は記録だけ |
| 5 | サイト用の素材がそろう（図面・通しの動画・問題に寄る動画・パネル付きの比較動画） |
配膳ロボットの店が全部そろうまでは、ほかのロボットに移らないことも決めました。
## 作業ログ ― 依頼83：6店180回で、ベースのデータを取った
合格した作り（cs:70）で、6店×ロボット0・1・2台×種10個＝180回を回しました。同時4本で約1時間です。
| 合格の線 | 結果 |
|---|---|
| 1 瞬間移動0 | 合格。180回の合計0。助けで押した2,945回もすべて押す動き |
| 3 解けずに残るものがない | 届かない。回の終わりまで残った詰まり92件・21回、全員が帰らなかった回6回 |
| 4 試算と向きが合う | 12本中10本が同じ。逆は⑥の入店待ち（1→2台）と④の料理の待ち（1→2台）で、差はどちらも0.13分 |
**瞬間移動を消したぶん、前は隠れていた詰まりが見えるようになった。** 目立ったのは、④のロボット2台で入口に近い所に何時間も残る詰まり、お客さんのトイレ前の詰まり（ロボット0台の②でも出た）、スタッフの料理の詰まりが1件だけ残る回でした。
この依頼の速報で、Claude は一度「④は試算と向きが逆」と伝え、報告を読んでから訂正しています。0台と2台の両端だけを比べていたためで、試算も1台から2台では入店待ちが少し増えるので、④の入店待ちの向きは試算と同じでした。
#### 20261103_83_6店180回でベースのデータを取る.md（依頼83 の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 360
---
# 依頼83：合格した作り（cs:70）で、6店180回のベースのデータを取る（午後〜夕方）
エイイチと決めたこと（2026-11-03 14:33）：依頼82 が合格したので、6店の基準データを取り直す。これを標準ファミレスのベース（サイトに載せる元）として区切る。
ベースの合格の線：(1) 瞬間移動0回 (2) 同じ種で同じ結果 (3) 止まったまま解けない所が残らない (4) 試算と向きが合う（細かい差は記録だけ）(5) サイト用の図面・動画がそろう。この依頼では (1)(3)(4) を180回で確かめる。
依頼82 の報告：claude_code_reports/20261103_zero_warp2.txt。実行ファイルは cs70_20261103_1359。
## 始める前に確かめること（違えば回さずに報告して終わる）
Unity エディタ・night_runner／rec_runner が動いていない、KIOXIA がマウント済み、unity_ledger_v1.lock がない、保留 0、作業場所が cs:70、Builds/headless が cs70_20261103_1359。台帳は退避してから回す。台帳は追記だけ。コードは変えない。
## 回すもの（画面なし・今の標準）
- ③⑦ × ロボット0・1・2台 × 種0〜9（60回）
- ④⑤⑥② × ロボット0・1・2台 × 種0〜9（各30回・計120回）
- 普通の混み具合・真ん中の人数・今の標準の切り替え。夜の名前は 20261103pm、ラベルは `base70`。同時に回す本数は今のまま
- 判定（judge_night.py）は今までどおり出してよい（基準は v5 のまま。差が出るのは当たり前なので、印が付いても止めない）
- 途中で解けずに残った人・ロボットが出た回や、止まった回があっても、ほかの回は続ける
## 報告
claude_code_reports/20261103_base70.txt に：
- 180回の completed の数・止まった回・最長の実時間
- 合格の線 (1)：瞬間移動の回数（0のはず）と、跳びの見張りの数
- 合格の線 (3)：解けずに残った人・ロボットの数、助けの回数（1往復あたり）、詰まり（nowarp_jams）の回数・秒・場所の上位
- 合格の線 (4)：店ごとに、ロボット0→1→2台で入店待ち・料理の待ちが増えるか減るか（種10個の中央値）を、サイトの試算の同じ向き（params の site_* の値）と並べた表。向きが試算と逆になった店と数字
- 店ごと・台数ごとに、入店待ち・料理の待ち・会計待ち・立ち往生・30秒以上の止まりの中央値（サイトの試算の値と並べる）
- 台帳の行数の変化と md5
**報告の最後の1行は必ず次のどれか**：「判定：合格」／「判定：止めた（決めてほしいことあり）」／「判定：失敗」（向きが逆の店があっても、記録して合格としてよい。そのことを報告に書く）
````
#### 20261103_base70.txt（依頼83 の Claude Code の報告）
````text
====================================================================
依頼83：合格した作り（cs:70）で、6店180回のベースのデータを取る
2026-11-03 14:33〜15:45 作業場所 cs:70 build_id cs70_20261103_1359（画面なし・保留 0・コードは変えていない）
====================================================================
結論
・180回とも completed（止まった回 0・やり直し 0）。最長の実時間 6.0 分（④2台 種0）
・合格の線 (1)：瞬間移動 0・1コマの跳びの見張り 0（180回すべて）… 合格
・合格の線 (3)：解けずに残ったものがある … 不合格
詰まり（nowarp_jams）が回の終わりで残った 92 件（21回）。うち 6 回は全員が帰らず、店の時刻の上限 720 分まで回った
（④2台 種0・4・7、⑤1台 種0、⑤2台 種3、②0台 種8）。助けが終わる前に回が終わった 2 件（④2台 種0・4）
・合格の線 (4)：入店待ち・料理の待ちの向き（0→1→2台）は 12 本中 10 本が試算と同じ。逆は 2 本
⑥の入店待ち 1→2台（Unity 5.39→5.52 わずかに増／試算 3.68→2.11 減）
④の料理の待ち 1→2台（Unity 2.05→2.18 わずかに増／試算 1.29→0.47 減）
・(3) が合格の線に届かないので、ベースとしては区切れない（下の「決めてほしいこと」）
--------------------------------------------------------------------
0. 始める前の確かめ（どれも依頼どおり）
--------------------------------------------------------------------
Unity エディタ・night_runner・rec_runner：動いていない（Unity Hub だけ）／KIOXIA：マウント済み／
unity_ledger_v1.lock：無し／保留 0／作業場所 cs:70 - head／Builds/headless の build_id cs70_20261103_1359
台帳を archive/unity_ledger_v1_pre_base70_20261103/ に退避（1738 行・md5 19a431ce554b4a087402e852ec3ad03e。依頼82 の終わりと同じ）
--------------------------------------------------------------------
1. 回したもの
--------------------------------------------------------------------
make_queue.py --stores fam_p1,fam_p5,fam_p2,fam_p3,fam_p4,fam_p0 --seeds 0-9 --label base70
＝ 6店 × 0・1・2台 × 種0〜9 ＝ 180回（普通の混み具合・真ん中の人数・種ごとに並べる）
条件：③ fam_p1_s4_a42・⑦ fam_p5_s4_a42・④ fam_p2_s2_a28・⑤ fam_p3_s4_a46・⑥ fam_p4_s3_a38・② fam_p0_s2_a19
切り替え：すれ違い入・待機場所へ戻る入・案B切・入口番入・持ち場入・一方通行切・1本道切・立ち往生の助け入（今の標準。どれも既定のまま）
night_runner.py --parallel 4 --night 20261103 --record-name 20261103pm --label base70
同時 4 本（今までの大きな夜と同じ）。やり直しは既定のまま（やり直しは起きなかった）
記録：night/20261103pm/（runner_log.txt・runs.csv・queue.json・judge.md・judge.csv・logs/）
出力：20261103_base70_cs70_*（180 フォルダ）
※夜の名前は --night が 8 桁の決まりなので 20261103、記録のフォルダ名を 20261103pm にした
--------------------------------------------------------------------
2. 回の結果
--------------------------------------------------------------------
completed 180／止まった回 0／やり直し 0／runner 終了コード 0
実時間：平均 1.3 分・中央値 1.2 分・最長 6.0 分（④ fam_p2 2台 種0。全員帰らず 720 分まで回った回）
14:36 に始め 15:35 に終わった
--------------------------------------------------------------------
3. 合格の線 (1)：瞬間移動
--------------------------------------------------------------------
瞬間移動（summary.json の teleports の内訳の和）：180回の合計 0
site_run.warped：合計 0
1コマの跳びの見張り（teleports.robot_frame_jumps）：合計 0（最大の跳び 0 m）
助けで押した 2945 回のうち、道が見つからずまっすぐ押した 33 回（瞬間移動ではない）
--------------------------------------------------------------------
4. 合格の線 (3)：解けずに残ったもの・助け・詰まり
--------------------------------------------------------------------
(a) 解けずに残った人・ロボット
詰まりが回の終わりで残った（nowarp_jams の open_at_end）：92 件・21 回
スタッフ 料理 42・スタッフ 案内 40・ロボット 1往復の打ち切り 6・客 トイレ 4
助けが終わる前に回が終わった：2 件（④2台 種0 の 43177 秒 (1.6, 2.2) 相手ロボット1号機／④2台 種4 の 7413 秒 (5.3, 2.3) 相手 客）
全員が帰らなかった回（店の時刻 720 分の上限まで回った）：6 回。judge.md でも「回の失敗」6 回
回 残った詰まり 1回の最長(秒) 主な中身
④2台 種0 34 41733 スタッフ案内 19・料理 10（(2,3) 付近）・ロボット打ち切り 1
④2台 種7 31 41779 スタッフ案内 17・料理 10（(2,4) 付近）・ロボット打ち切り 2
④2台 種4 4 35428 ロボット打ち切り 2・スタッフ案内 1・料理 1（(3〜5, 2〜3)）
⑤1台 種0 1 33062 客トイレ（(14,9)）
⑤2台 種3 2 33753 客トイレ 2（(14,9)）
②0台 種8 1 32866 客トイレ（(9,6)）※ロボット 0 台の回
ほかの 15 回は全員帰ったが、スタッフの「料理」の詰まりが 1〜3 件、回の終わりまで残っていた
（③2台 種2・8 の (20〜21, 4)、⑤ の (2,13) など。1件 3363〜11082 秒）
(b) 助け
呼んだ 3274 回（動かした 2945・自分で動き出して取り消し 230・その場で引き直した 57・往復が終わって取り消し 40・終わる前に回が終わった 2）
往復 11284 → 1往復あたり 0.290
店・台数ごとの 1往復あたり：③1台 0.158・2台 0.201／⑦ 0.197・0.168／④ 0.332・2.129／⑤ 0.100・0.130／⑥ 0.052・0.085／② 0.096・0.171
（④2台の 2.129 は、全員帰らなかった 3 回で同じ所の助けが続いた分が大きい）
(c) 詰まり（nowarp_jams）
2422 回・合計 2,858,996 秒・1回の最長 41779 秒
（④2台の 3 回の長い詰まりが 2,430,502 秒で 85% を占める。同じ時間に重なっている詰まりも足しているので、秒の合計は重なりを含む）
どうなったか：着いた 1997・仕事が終わった 188・回の終わりで残った 92・仕事を外した 89・往復が終わった 50・体を返した 6
だれ・仕事：スタッフ案内 73 回 1,511,301 秒／スタッフ料理 87 回 814,526 秒／ロボット打ち切り 56 回 260,076 秒／
客トイレ 83 回 135,474 秒／客ドリンクバー 1637 回 60,008 秒／スタッフ片付け 148 回 51,371 秒／客退店 209 回 9,061 秒／
スタッフ会計 20 回 7,461 秒／スタッフ呼び出し 31 回 5,465 秒／客会計 78 回 4,252 秒
店ごと：③ 579 回 55,433 秒（最長 11082）／⑦ 482 回 47,298 秒（9566）／④ 404 回 2,443,471 秒（41779）／
⑤ 614 回 221,991 秒（33753）／⑥ 291 回 34,667 秒（9222）／② 52 回 56,135 秒（32866）
場所の上位（店・1 m のマスで丸めた位置・回数・合計秒）
1. ④ (2,3) 49 回 1,068,651 秒
2. ④ (2,4) 42 回 901,900 秒
3. ④ (3,3) 17 回 124,612 秒
4. ⑤ (14,9) 42 回 111,912 秒（客のトイレ）
5. ④ (3,2) 14 回 78,155 秒
6. ④ (4,2) 10 回 78,024 秒
7. ④ (4,3) 10 回 76,041 秒
8. ⑤ (2,13) 23 回 47,209 秒
④の (2〜4, 2〜4) は入口から案内する所の近くとみられるが、場所の意味は確かめていない
--------------------------------------------------------------------
5. 合格の線 (4)：向き（種10個の中央値。＋は増える・－は減る）
--------------------------------------------------------------------
Unity は summary.json の site_metrics（entry_wait_mean・dish_wait_mean）、試算は params の unity_conditions の site_result の同じ名前の値（分）
店 入店待ち Unity 0→1→2台 向き 試算 0→1→2台 向き 合う？
③ 3.90 → 3.31 → 2.81 －－ 4.09 → 1.68 → 1.13 －－ 合う
⑦ 4.40 → 3.23 → 4.63 －＋ 3.08 → 1.58 → 1.60 －＋ 合う
④ 12.64 → 12.62 → 18.96 －＋ 10.91 → 4.81 → 5.57 －＋ 合う
⑤ 8.13 → 6.44 → 5.63 －－ 7.51 → 3.16 → 2.37 －－ 合う
⑥ 9.45 → 5.39 → 5.52 －＋ 7.91 → 3.68 → 2.11 －－ 逆（1→2台）
② 1.90 → 1.58 → 1.50 －－ 2.61 → 1.79 → 1.30 －－ 合う
店 料理の待ち Unity 0→1→2台 向き 試算 0→1→2台 向き 合う？
③ 0.95 → 2.38 → 1.60 ＋－ 0.63 → 1.97 → 0.96 ＋－ 合う
⑦ 1.01 → 2.45 → 1.54 ＋－ 0.63 → 2.01 → 1.01 ＋－ 合う
④ 1.25 → 2.05 → 2.18 ＋＋ 0.99 → 1.29 → 0.47 ＋－ 逆（1→2台）
⑤ 1.09 → 2.66 → 1.74 ＋－ 0.77 → 2.28 → 1.27 ＋－ 合う
⑥ 1.09 → 1.98 → 1.24 ＋－ 0.84 → 2.01 → 0.82 ＋－ 合う
② 0.89 → 0.98 → 0.57 ＋－ 0.61 → 0.91 → 0.40 ＋－ 合う
逆の 2 本はどちらも差が小さい（⑥ +0.13 分・④ +0.13 分）。向きの判定は差の大きさを見ずに符号だけで決めた
全員帰らなかった 6 回を外しても向きは変わらない（④2台の中央値 入店 19.52・料理 2.39、⑤1台 7.05・2.68、⑤2台 6.26・1.78、②0台 2.06・0.89）
細かい差（大きさ）は記録だけ。⑦④⑤⑥ の 1・2台の入店待ちは試算の 2〜3 倍ある
--------------------------------------------------------------------
6. 店ごと・台数ごとの中央値（種10個。かっこ内は試算 site_result の値）
--------------------------------------------------------------------
入店待ち・料理の待ち・会計待ちは分。立ち往生＝stops.csv の「動けなくなった」の数（試算は site_result.rescues を並べた）。
30秒以上の止まり＝stops.csv の 30 秒以上の行（試算に同じ数字は無いので、参考に site_result.pauses を並べた。数え方は違う）
店・台数 入店待ち 料理の待ち 会計待ち 立ち往生 30秒以上
③0台 3.90 (4.09) 0.95 (0.63) 4.27 (4.80) 0.0 (0.00) 0.0 (0.00)
③1台 3.31 (1.68) 2.38 (1.97) 5.49 (5.64) 3.5 (0.93) 10.5 (20.88)
③2台 2.81 (1.13) 1.60 (0.96) 6.22 (6.58) 8.5 (1.82) 27.0 (44.62)
⑦0台 4.40 (3.08) 1.01 (0.63) 4.05 (4.86) 0.0 (0.00) 0.0 (0.00)
⑦1台 3.23 (1.58) 2.45 (2.01) 6.18 (5.82) 5.0 (0.88) 12.5 (19.90)
⑦2台 4.63 (1.60) 1.54 (1.01) 6.13 (6.60) 8.0 (1.62) 24.5 (44.48)
④0台 12.64 (10.91) 1.25 (0.99) 1.87 (1.66) 0.0 (0.00) 0.0 (0.00)
④1台 12.62 (4.81) 2.05 (1.29) 2.33 (1.52) 17.0 (0.68) 25.5 (26.32)
④2台 18.96 (5.57) 2.18 (0.47) 2.40 (1.54) 31.5 (1.35) 50.5 (39.70)
⑤0台 8.13 (7.51) 1.09 (0.77) 5.45 (6.09) 0.0 (0.00) 0.0 (0.00)
⑤1台 6.44 (3.16) 2.66 (2.28) 6.73 (8.58) 3.0 (0.57) 6.5 (20.55)
⑤2台 5.63 (2.37) 1.74 (1.27) 8.33 (9.92) 6.5 (1.48) 14.0 (44.85)
⑥0台 9.45 (7.91) 1.09 (0.84) 2.91 (2.45) 0.0 (0.00) 0.0 (0.00)
⑥1台 5.39 (3.68) 1.98 (2.01) 3.46 (3.00) 1.5 (0.80) 3.5 (22.05)
⑥2台 5.52 (2.11) 1.24 (0.82) 3.06 (2.98) 6.0 (1.75) 10.0 (42.00)
②0台 1.90 (2.61) 0.89 (0.61) 1.11 (0.88) 0.0 (0.00) 0.0 (0.00)
②1台 1.58 (1.79) 0.98 (0.91) 0.85 (0.74) 0.0 (0.65) 1.0 (20.75)
②2台 1.50 (1.30) 0.57 (0.40) 0.93 (0.65) 3.5 (0.75) 10.0 (25.75)
--------------------------------------------------------------------
7. 判定（judge_night.py・基準 v5 のまま）
--------------------------------------------------------------------
night/20261103pm/judge.md：正常 0・試算を見直す候補 0・Unity の作り 0・回の失敗 6・基準なし 174
基準 v5（20261102_night_cs34_*）は入口番・持ち場・助けが切なので、ほとんどの回は「基準なし」。止めずに進めた
回の失敗 6 は上の 4(a) の「全員が帰らなかった」6 回と同じ
--------------------------------------------------------------------
8. 台帳
--------------------------------------------------------------------
1738 行 → 1918 行（追記 180 行だけ。新しい行はどれも 59 列）
先頭 1738 行の md5 は 19a431ce554b4a087402e852ec3ad03e で、始める前と同じ（前の行は変わっていない）
終わったあとの md5 326414af3938f358b53d074b3ae167e2。鍵ファイルは残っていない
（前からある 36 行は 49 列のまま。今回は触っていない）
--------------------------------------------------------------------
9. 変えたもの・残したもの
--------------------------------------------------------------------
コード・params・実行ファイル：変えていない（check-in なし）
新しく置いたもの：night/20261103pm/・night/20261103pm_dry/（から回し）・出力 20261103_base70_cs70_* 180 フォルダ・
archive/unity_ledger_v1_pre_base70_20261103/
/tmp/req83/：並び base70.json・runner_base70.txt・集計の手順 base83.py・集計の出力 agg.txt
--------------------------------------------------------------------
決めてほしいこと
--------------------------------------------------------------------
1. 合格の線 (3) に届かなかった（解けずに残った詰まり 92 件・21 回、全員帰らなかった 6 回）。ベースとして区切るのを待ち、直すか。
目立つのは次の 3 つ（どれもコードを見ていないので、原因は確かめていない）
a. ④ fam_p2 の 2 台：入口に近い (2〜4, 2〜4) でスタッフの案内・料理がロボットと一緒に何時間も詰まる（種0・4・7 の 3 回）
b. 客のトイレの詰まりが回の終わりまで解けない（⑤ (14,9) 2 回・② (9,6) 1 回。② はロボット 0 台でも出た）
c. スタッフの「料理」の詰まりが 1 件だけ回の終わりまで残る回が 15 回（全員は帰っている）
2. 向きが試算と逆の 2 本（⑥入店待ち 1→2台・④料理の待ち 1→2台。どちらも差 0.13 分）は、依頼どおり記録だけにした。
④は 1 で詰まりが多い店なので、1 を直してから見直すかどうか
3. 試算との大きさの差（入店待ちが試算の 2〜3 倍、立ち往生が試算 rescues の数倍）は記録だけにした
判定：失敗
````
#### 20261103_83_6店180回でベースのデータを取る_20261103_1433.md（依頼83 の見張り係の記録）
````markdown
# 結果：20261103_83_6店180回でベースのデータを取る
- 状態：完了
- 始めた時刻：2026-11-03 14:33
- 終わった時刻：2026-11-03 15:37（63分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume fae589c8-86bc-40ae-b1cb-102396f4f284`
## Claude Code の報告
**やったこと**
- 始める前の確かめは、どれも依頼どおりでした。Unity エディタ・night_runner・rec_runner は動いておらず、KIOXIA はマウント済み、鍵ファイルなし、保留 0、作業場所 cs:70、実行ファイル cs70_20261103_1359。台帳（1738行）は退避してから回しました。
- 6店 × ロボット0・1・2台 × 種0〜9 の180回を、画面なし・今の標準で回しました。ラベルは base70、同時4本です。夜の名前は「8桁の数字」の決まりがあるので 20261103 にし、記録のフォルダ名を 20261103pm にしました。
- 判定（judge_night.py、基準 v5）も出しました。コードは変えていません。
**結果**
- **回の数**：180回とも completed で、止まった回は0回、やり直しも0回です。いちばん長くかかった回は6.0分（④の2台・種0）でした。
- **合格の線 (1)**：瞬間移動0回、跳びの見張り0件で、合格です。
- **合格の線 (3)**：不合格です。
- 回の終わりまで解けずに残った詰まりが92件（21回）ありました。内訳はスタッフの料理42、スタッフの案内40、ロボットの打ち切り6、客のトイレ4です。
- 全員が帰らず、店の時刻の上限720分まで回った回が6回ありました。④の2台が3回、⑤が2回、②の0台が1回です。
- 助けが終わる前に回が終わったものが2件ありました。
- 助けは3274回で、1往復あたり0.290回です。
- 詰まりは2422回、合計約286万秒（重なりを含む）でした。そのうち85%が、④の入口近く (2〜4, 2〜4) に集まっています。
- **合格の線 (4)**：入店待ちと料理の待ちの向き（0→1→2台）は、12本のうち10本が試算と同じでした。逆になったのは次の2本で、どちらも差は0.13分です。依頼どおり記録だけにしました。
- ⑥の入店待ち（1→2台）：Unity 5.39→5.52、試算 3.68→2.11
- ④の料理の待ち（1→2台）：Unity 2.05→2.18、試算 1.29→0.47
- **店ごと・台数ごとの中央値**：入店待ち・料理の待ち・会計待ち・立ち往生・30秒以上の止まりを、試算の値と並べた表を報告ファイルに載せました。
- **台帳**：1738行から1918行になりました（180行の追記だけ）。前からある1738行の md5 は変わっておらず、終わったあとの md5 は 326414af3938f358b53d074b3ae167e2 です。
**変えたファイル**
- 報告：claude_code_reports/20261103_base70.txt
- 台帳：unity_ledger_v1.csv に180行を追記
- 新しく置いたもの：
- 記録 night/20261103pm/ と night/20261103pm_dry/（から回し）
- 出力の180フォルダ（20261103_base70_cs70_*）
- 台帳の退避 archive/unity_ledger_v1_pre_base70_20261103/
- 並びと集計の手順 /tmp/req83/
**決めてほしいこと**
1. 合格の線 (3) に届かなかったので、ベースとして区切るのを待って直すかどうか。目立つのは次の3つです。原因は確かめていません。
- ④の2台で、入口近くのスタッフの案内・料理が何時間も詰まる
- 客のトイレの詰まりが解けない（⑤、②。② はロボット0台の回）
- スタッフの料理の詰まりが1件だけ残る回が15回ある
2. 向きが逆の2本（⑥の入店待ち・④の料理の待ち）を、1を直したあとに見直すかどうか。
3. 大きさの差を記録だけにしたままでよいか。入店待ちは試算の2〜3倍、立ち往生は試算の数倍あります。
判定：失敗
````
## 作業ログ ― 依頼84：解けない詰まりを3つ直し、21回が2回になった
依頼83で残った3つの原因を、コードと記録から確かめてから直しました（cs:71〜73）。
| 詰まり | 原因 | 直し |
|---|---|---|
| ④の入口近く（ロボット2台） | 助けで押した先が、相手の前のセンサーの中だった。2回目からは毎回2.5cmしか動かさず、同じ2台の助けが同じ所で514回続いた。助けのスタッフは手前の台にふさがれて着けなかった | 同じ所で2回目の助けなら、相手のセンサーの外まで離す。60秒着けなければ手前の台のほうを動かす。動かす台から0.8m以内まで来たら着いたとみる |
| お客さんのトイレ前 | トイレからの戻り道に「あきらめて席へ戻る」がなく、止まっているだけの相手（待機の台・手の空いたスタッフ）にふさがれていた | 30秒で0.3mも進めない人のすぐ前に止まっている相手がいたら、台なら助けを呼んで押し、スタッフなら空いた床へ歩いてどく |
| 料理の詰まりが1件だけ残る | 本当は止まっていない。仕事を外すときに詰まりの記録を閉じていなかった | 料理の仕事を外すときに記録を閉じる。届けたあとの戻り道で着けないときは、交代にせず仕事を終える |
そのうえで、依頼83と同じ180回を回し直しました。途中で KIOXIA（データを置く外付けの SSD）が一度外れ、180回は3回に分けて回しています。中身は同じ並び・同じ版です。
| 項目 | 依頼83（cs:70） | 依頼84（cs:73） |
|---|---|---|
| 瞬間移動 | 0 | 0 |
| 解けずに残った詰まり | 92件・21回 | 2件・2回 |
| 全員が帰らなかった回 | 6 | 1 |
| 助け（1往復あたり） | 0.290 | 0.193 |
| 詰まりの秒の合計 | 2,858,996 | 177,753 |
| 向きが試算と同じ | 12本中10本 | 12本中10本 |
向きが逆だった2本は直りましたが、別の2本が逆になりました。⑦の入店待ち（1→2台）は、試算の差が0.02分でほとんど横ばいです。⑤の入店待ち（1→2台）は Unity で1.45分増えていて、小さくありません。待機場所の台が人の道をふさいだら助けを呼ぶ直しで増えたとみられますが、確かめていません。
判定は失敗でした。新しく、⑦のロボット2台・種9の1回で、全員が帰りませんでした。1号機が卓42へ向かう途中で、1.4cmの幅を約50秒ごとに行ったり来たりし続けています。少しずつ動いているので「止まった」と数えられず、30秒の線に届かないため、助けを一度も呼んでいません。直すなら止まりの数え方（30秒の線の測り方）に手が入るので、ここで区切り、次に決めることにしました。
#### 20261103_84_④入口とトイレ前の解けない詰まりを直す.md（依頼84 の依頼文）
````markdown
---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 300
---
# 依頼84：④の入口近くとトイレ前の、解けずに残る詰まりを直し、180回で確かめる
エイイチと決めた方針（2026-11-03）：サイトのシミュレーションは完璧でなくてよい。ベースの合格の線は (1) 瞬間移動0回 (2) 同じ種で同じ結果 (3) 止まったまま解けない所が残らない (4) 試算と向きが合う（細かい差は記録だけ）(5) サイト用の図面・動画がそろう。現実に瞬間移動はないので Unity でもさせない。
依頼83 の報告：claude_code_reports/20261103_base70.txt（判定：失敗。(1) は合格、(4) は12本中10本、(3) が届かない）。今の作り cs:70・実行ファイル cs70_20261103_1359。
依頼83 の「決めてほしいこと」への答え（エイイチ了承）：
- 1 は直す。a・b・c の3つとも
- 2 の向きが逆の2本は、1 を直してから見直す。差が小さいままなら記録だけ
- 3 の大きさの差は記録だけ
## 始める前に確かめること（違えば手を止めて報告）
Unity エディタ・night_runner／rec_runner が動いていない、KIOXIA がマウント済み、unity_ledger_v1.lock がない、保留 0、作業場所が cs:70。台帳は退避してから回す。台帳は追記だけ。
## やること
1. 原因を確かめる（コードと依頼83 の記録を読む。直す前に、報告に原因を短く書く）
a. ④ fam_p2・2台・種0・4・7：入口に近い (2〜4, 2〜4) で、スタッフの案内・料理がロボットと何時間も詰まる。だれが何を待って、なぜ助けや歩き直しで解けないのか
b. 客のトイレ前の詰まり（⑤ (14,9)・② (9,6)。② はロボット0台）が回の終わりまで解けない理由
c. スタッフの「料理」の詰まりが1件だけ回の終わりまで残る（15回）理由
2. 直す。考え方は今までと同じ：瞬間移動はさせない。解けないときは、今ある決まり（行き直し・あきらめて別のスタッフに渡す・助けで押す・客は席へ戻る）が、人同士・人とロボットのどちらのふさぎにも届くようにする。止まり続ける相手がいるなら、どちらかが下がるか回り道する
3. check-in し、画面なしの実行ファイルを作り直す（保留 0）
4. 確かめ（画面なし）
- ⑦ fam_p5・種7 を2回：記録が1行も違わないこと
- 依頼83 と同じ 6店 × 0・1・2台 × 種0〜9 ＝ 180回（同時4本・label base71）
- 依頼83 と並べる：瞬間移動・1コマの跳び、解けずに残った詰まりの件数と回数、全員が帰らなかった回、助けの回数（1往復あたり）、詰まりの場所の上位、店・台数ごとの入店待ち・料理の待ちの中央値と試算との向き（12本）
## 変えないもの
ロボットの速さ・物理の設定・譲る順番・人とロボットの数字・rescue_s 15 秒・30 秒の線・同じ種で同じ結果にする作り・止まっている台を 1.2 m 離す決め方・瞬間移動をなくした作り・店の形・台帳の列と今までの行。
## 止める線
直したあと、瞬間移動が1回でも出たら、または入店待ち・料理の待ちの中央値が依頼83 の2倍を超える店・台数があったら、180回の途中でも止めて報告する。
## 報告
claude_code_reports/20261103_base71.txt に：a・b・c の原因、変えたファイルと cs・build_id、2回の一致、依頼83 と並べた表、向きの12本の表、残った詰まりがあればその中身と場所。
**報告の最後の1行は必ず次のどれか**：「判定：合格」／「判定：止めた（決めてほしいことあり）」／「判定：失敗」
````
#### 20261103_base71.txt（依頼84 の Claude Code の報告）
````text
====================================================================
依頼84：④の入口近くとトイレ前の、解けずに残る詰まりを直し、180回で確かめる
2026-11-03 15:43〜17:30 作業場所 cs:70 → cs:73 build_id cs73_20261103_1601（画面なし・保留 0）
====================================================================
--------------------------------------------------------------------
0. 始める前の確かめ（どれも依頼どおり）
--------------------------------------------------------------------
Unity エディタ・night_runner・rec_runner：動いていない（Unity Hub だけ）／KIOXIA：マウント済み／
unity_ledger_v1.lock：無し／保留 0／作業場所 cs:70 - head／Builds/headless は cs70_20261103_1359
台帳を archive/unity_ledger_v1_pre_base71_20261103/ に退避（1918 行・md5 326414af3938f358b53d074b3ae167e2。依頼83 の終わりと同じ）
--------------------------------------------------------------------
1. 原因（直す前に確かめたこと。依頼83 の記録とコードから）
--------------------------------------------------------------------
a. ④ fam_p2・2台・種0・4・7（入口側から来た横の通路と、左の壁ぞいの卓 T01〜T05 の細い通路の口 x 1.6〜3.8・z 2.2〜3.0）
・種0：ロボット1号機（受け渡し口へ戻る・空）と2号機（T01 へ料理）が横の通路で向かい合い（900 秒）、
助けで1号機を 1.39 m 押した先が、左下の行き止まりのへこみ (1.64, 2.19)。そこは2号機の行き先（T01 の止まる点）の
すぐ手前で、2号機の前のセンサー（0.6 m）の中だった。2台とも動けなくなり（1467 秒に両方とも 1往復の打ち切り）、
スタッフ2人も2号機の東側で、2号機を抜けられないまま止まった（(3.2, 2.65)・(2.2, 3.0)）
・助けで解けなかった理由は2つ
(1) 動かす先の決め方が「相手の道の線から 2 台の半径＋0.1 m」だけで、相手の前のセンサーの外まで離さない。
2回目からの助けは毎回 2.5 cm しか動かさず、同じ2台の助けが同じ所で 514 回（種7 は 699 回）続いた
(2) 動かす台（1号機）がへこみの奥にいて、助けのスタッフは手前の2号機にふさがれて着けない（47 回交代・3871 秒）。
交代しても動かす台は変わらないので、だれも着けないままだった
・スタッフの案内・料理は、通れないまま 3 回ずつあきらめて別のスタッフに渡すのをくり返し、そのたびに詰まりの行が
1 件ずつ増えた（種0 の 34 件の大半）。スタッフはその場から動けていなかった
・種4 は、ロボットと止まっているスタッフの助けが同じ所で毎回 1〜2 cm しか動かしていなかった（(1) と同じ形。相手が人）
b. 客のトイレ前（⑤ (14,9)・② (9,6)）
・トイレ自体ではなく、客がトイレから席へ戻る途中で止まっていた。戻り道には「あきらめて席へ戻る」が無く
（行きだけ）、60 秒ごとに行き直すだけ。回り込みの道も毎回見つからなかった（行き直し 546〜1107 回）
・ふさいでいたのは、止まっているだけで自分からは動かない相手だった
⑤：往復を終えて待機場所 (14.8, 8.8) に止まっているロボット。パントリーの壁とのすき間 0.33 m を人の道が通り、
客とスタッフが台をはさんで向かい合ったまま。ロボットは「止まっている」だけで動けなくなってはいないので、助けを呼ばない
②（ロボット 0 台）：持ち場 (9.5, 5.5) に立つ手の空いたスタッフが、パントリーの壁の角を回る人の道をふさいでいた
・人どうしの詰まりの決まり（JamWatcher：体を横に向ける → 3 秒で下がる）は、止まっている相手（立っているだけの人・
待機の台）を相手にしないので、どちらも届いていなかった
c. スタッフの「料理」の詰まりが 1 件だけ残る（全員帰った 15 回・19 件）
・どれも本当に止まっていたのではなく、記録の閉じ忘れだった（料理は 19 件ともすべて届いていた）
C（10 件）：3回あきらめて交代した料理を、そのあとロボットが積んだ。仕事を板から外すとき（RemoveServeJob）に詰まりを閉じていなかった
A（7 件）：料理を卓に届けたあと、受け渡し口へ戻る途中で 60 秒着けず、済んだ仕事を「交代」に回して新しく詰まりを始めていた。
済んだ仕事なのでだれも取らず、閉じなかった
A'（2 件）：交代のあと別のスタッフが届けたが、戻り道でまた交代になり、閉じなかった
結論（先に）
・a・b・c の原因を確かめて直した（cs:71・72・73。実行ファイル cs73_20261103_1601）
・同じ種の2回（⑦種7）は記録が1行も違わない
・180回（cs:73）：瞬間移動 0・1コマの跳び 0。解けずに残った詰まり 92 件・21 回 → 2 件・2 回、全員帰らなかった回 6 → 1、
1往復あたりの助け 0.290 → 0.193。止める線（瞬間移動・中央値2倍）には当たらなかった
・ただし新しく ⑦2台 種9 の1回が全員帰らなかった（下の 4 (4)）。合格の線 (3) にはまだ届かない
・向きは 12 本中 10 本が試算と同じ（依頼83 の逆2本は直り、別の2本が逆になった。どちらも ⑦⑤ の入店待ち 1→2台）
・途中で KIOXIA が一度外れ、180回は3回に分けて回した（中身は同じ並び・同じ版。下の 5）
--------------------------------------------------------------------
2. 直したこと
--------------------------------------------------------------------
a（cs:71・73）
・同じ2台（または同じ台と同じ人）の助けが、前にもこの台の 2 m 以内であったら、動かす先を
止まっている台と同じ決め方（相手の体の半径＋相手の前のセンサー 0.6 m＋自分の半径＋0.1 m。人なら人の半径＋自分のセンサー＋自分の半径＋0.1 m）
で、床をたどって届く所に探す。見つからなければ今までの決め方。1.2 m の決め方そのものは変えていない（使う場面を広げただけ）
・助けのスタッフが 60 秒着けずに交代したら、相手がロボットで動かせる台なら、手前の相手の台の方を動かすことにする（どちらかが下がる）
・助けのスタッフが、もう動かす台から 0.8 m（立つ点の距離）以内にいれば着いたとみる（cs:73。2台のあいだに挟まれた人が、
もう1台の側にある立つ点へ届かず、交代を 95〜107 回くり返していた。試しの ④2台 種4・7 で見つけた）
b（cs:72）
・歩きたいのに 30 秒（30 秒の線）0.3 m も進めない人のすぐ前（体どうしの間 0.6 m 以内）に、止まっているだけの相手がいたら相手をどかす
往復を終えて止まっている台 → 立ち往生の助けを呼び、スタッフが押して人の道の外へ動かす（今の助けの決まりをそのまま使う）
手の空いて立っているスタッフ → 人の道から 0.7 m 以上離れた、歩いて行ける空いた床へ歩いてどき、次の仕事までそこで待つ
・どちらも瞬間移動なし。助けが切の回は何もしない
c（cs:71）
・料理の仕事を板から外すとき（料理が届いた・ロボットに渡した・戻された）に、交代で始めた詰まりを閉じる
・料理を卓に届けたあと、受け渡し口へ戻る途中で 60 秒着けないときは、交代にせず仕事を終えて次の仕事を取る
（前は give_ups.csv に「あきらめた／交代した」の行が出ていた所。今は出ない）
記録に足したもの（台帳の列は変えていない）
・rescues.csv の終わりに wide_clear・swaps
・summary.json の stuck_rescue に blocked_robot_calls・blocked_staff_steps
変えていないもの：ロボットの速さ・物理の設定・譲る順番・人とロボットの数字・rescue_s 15 秒・30 秒の線・同じ種で同じ結果にする作り・
止まっている台を 1.2 m 離す決め方・瞬間移動をなくした作り・店の形・台帳の列と今までの行
--------------------------------------------------------------------
3. 変えたファイル・版
--------------------------------------------------------------------
cs:71 Service/ServiceOps.cs・Robot/ServingRobotController.cs・People/StaffAgent.cs・Experiment/TripLogger.cs（a の広く離す・入れ替え、c）
cs:72 Service/ServiceOps.cs・People/StaffAgent.cs・Experiment/TripLogger.cs・Experiment/ExperimentRunner.cs（b）
cs:73 People/StaffAgent.cs（a の「0.8 m 以内なら着いた」）
実行ファイル：Builds/headless build_id cs73_20261103_1601・unity_cs ServiceSim/cs:73・pending_changes 空・error CS 0
（どの check-in の前も /tmp/req84/try1〜3 に試しのビルドを作り error CS 0 を確かめた）
--------------------------------------------------------------------
4. 確かめ
--------------------------------------------------------------------
(1) 同じ種の2回（⑦ fam_p5・2台・種7。det84a・det84b、cs:73）
conditions・contacts・dishes・give_ups・groups・nowarp_jams・passes・people_jams・requeues・rescues・robot_track・
stops・summary・timeline・yields、どれも 1 行も違わない。trips.csv は最後の列 plan_ms_max だけ違う、
run_info.json は run_label・wall_seconds・speedup・plan_ms_max_per_trip だけ違う（どれも名札か計算にかかった実時間。前と同じ扱い）
(2) 直しの途中の試し（どれも completed・瞬間移動 0）
t84a（cs:71）④2台 種0・4・7：3回とも全員帰った・残り 0（依頼83 は 3回とも全員帰らず）
t84b（cs:72）上の3回＋⑤1台 種0・⑤2台 種3・②0台 種8・③2台 種2：7回とも全員帰った・残り 0
ただし ④ 種4・7 で 5000 秒を超える詰まりが1件ずつ（解けはした）→ cs:73 の直しにつながった
t84c（cs:73）④2台 種0〜9＋⑤1台 種0・⑤2台 種3・②0台 種8・③2台 種2 の 14回：全員帰った・残り 0・助けが終わる前に回が終わった 0
④2台（種10個の中央値）：入店待ち 17.96 分（依頼83 18.96）・料理の待ち 1.73 分（依頼83 2.18）・1往復あたりの助け 0.570（依頼83 2.129）
依頼83 で解けなかった4回：⑤1台 種0 入店 1.66・⑤2台 種3 1.96・②0台 種8 1.64（どれも全員帰った）
残った長い詰まり：④2台 種4 の 5166 秒（左の壁ぞいの細い通路 x 2.1 に2台が入り、奥の台の助けのスタッフが手前の台にふさがれて 69 回交代。
相手が客なので、台どうしの入れ替えが働かない。回の中で解けた）
(3) 180回（label base71・同時4本・cs:73。並びは依頼83 と同じ 6店 × 0・1・2台 × 種0〜9）
180 回とも completed。実時間 中央値 1.2 分・最長 4.1 分（⑦2台 種9。依頼83 の最長は 6.0 分）
依頼83 と並べる（全体）
項目 依頼83（cs:70） 今回（cs:73）
瞬間移動（teleports の内訳の和） 0 0
1コマの跳びの見張り 0 0
解けずに残った詰まり（件・回） 92 件・21 回 2 件・2 回
全員帰らなかった回 6 1（⑦2台 種9）
助けが終わる前に回が終わった 2 3（⑤2台 種0・6・7。どれも全員が帰ったあと）
助け（回／往復／1往復あたり） 3274／11284／0.290 2244／11650／0.193
詰まり（回・秒・1回の最長） 2422・2,858,996・41779 2170・177,753・31402
店・台数ごと（種10個の中央値。入店待ち・料理の待ちは分、助けは1往復あたり）
店・台数 入店待ち 83→今回 料理の待ち 83→今回 助け 83→今回 詰まり秒 83→今回
③1台 3.31 → 3.19 2.38 → 2.40 0.158 → 0.155 7294 → 5507
③2台 2.81 → 2.50 1.60 → 1.48 0.201 → 0.167 48139 → 15096
⑦1台 3.23 → 3.04 2.45 → 2.40 0.197 → 0.160 15933 → 7144
⑦2台 4.63 → 2.82 1.54 → 1.48 0.168 → 0.145 31337 → 43412（種9 の 31402 秒が大半）
④1台 12.62 → 10.76 2.05 → 1.89 0.332 → 0.253 12969 → 4995
④2台 18.96 → 17.96 2.18 → 1.73 2.129 → 0.570 2430502 → 50936
⑤1台 6.44 → 6.17 2.66 → 2.68 0.100 → 0.219 58089 → 11439
⑤2台 5.63 → 7.62 1.74 → 1.68 0.130 → 0.238 163882 → 24302
⑥1台 5.39 → 5.38 1.98 → 1.98 0.052 → 0.049 2714 → 3270
⑥2台 5.52 → 4.83 1.24 → 1.11 0.085 → 0.084 31953 → 7537
②0台 1.90 → 1.86 0.89 → 0.88 ― 32897 → 55
②1台 1.58 → 1.60 0.98 → 1.02 0.096 → 0.090 3522 → 2345
②2台 1.50 → 1.59 0.57 → 0.58 0.171 → 0.148 19716 → 1666
（0台の ③⑦④⑤⑥ は依頼83 と同じ値。2倍を超えた店・台数は無い。いちばん増えたのは ⑤2台の入店待ち 1.35 倍。
⑤ の助けが増えたのは、待機場所の台が人の道をふさいだときに助けを呼ぶようにした（b）ためとみられるが、確かめていない）
向きの12本（＋は増える・－は減る）
店 入店待ち Unity 0→1→2台 向き 試算 0→1→2台 向き 合う？
③ 3.90 → 3.19 → 2.50 －－ 4.09 → 1.68 → 1.13 －－ 合う
⑦ 4.40 → 3.04 → 2.82 －－ 3.08 → 1.58 → 1.60 －＋ 逆（1→2台。Unity －0.22・試算 ＋0.02）
④ 12.64 → 10.76 → 17.96 －＋ 10.91 → 4.81 → 5.57 －＋ 合う
⑤ 8.13 → 6.17 → 7.62 －＋ 7.51 → 3.16 → 2.37 －－ 逆（1→2台。Unity ＋1.45・試算 －0.79）
⑥ 9.45 → 5.38 → 4.83 －－ 7.91 → 3.68 → 2.11 －－ 合う（依頼83 は逆）
② 1.86 → 1.60 → 1.59 －－ 2.61 → 1.79 → 1.30 －－ 合う
店 料理の待ち Unity 0→1→2台 向き 試算 0→1→2台 向き 合う？
③ 0.95 → 2.40 → 1.48 ＋－ 0.63 → 1.97 → 0.96 ＋－ 合う
⑦ 1.01 → 2.40 → 1.48 ＋－ 0.63 → 2.01 → 1.01 ＋－ 合う
④ 1.25 → 1.89 → 1.73 ＋－ 0.99 → 1.29 → 0.47 ＋－ 合う（依頼83 は逆）
⑤ 1.09 → 2.68 → 1.68 ＋－ 0.77 → 2.28 → 1.27 ＋－ 合う
⑥ 1.09 → 1.98 → 1.11 ＋－ 0.84 → 2.01 → 0.82 ＋－ 合う
② 0.88 → 1.02 → 0.58 ＋－ 0.61 → 0.91 → 0.40 ＋－ 合う
12 本中 10 本が合う。逆の2本のうち ⑦ は試算の差が 0.02 分でほとんど横ばい。⑤ は Unity の差 1.45 分で小さくない
詰まりの場所の上位（店・1 m のマス・回数・合計秒）
依頼83：④(2,3) 1,068,651 秒・④(2,4) 901,900・④(3,3) 124,612・⑤(14,9) 111,912 …
今回 ：⑦(17,6) 1 回 31,402 秒（種9）・④(2,3) 24 回 11,392・④(2,4) 10 回 8,558・④(2,5) 10 回 6,938・④(5,3) 18 回 4,221・
⑤(16,9) 12 回 3,797・⑤(14,9) 23 回 3,622・⑤(20,3) 54 回 3,157
だれ・仕事：ロボット 1往復の打ち切り 33 回 58,084 秒・客ドリンクバー 1601 回 52,825・スタッフ片付け 105 回 35,697・
スタッフ料理 31 回 10,638（依頼83 は 87 回 814,526）・スタッフ案内 32 回 5,884（依頼83 は 73 回 1,511,301）・客トイレ 90 回 3,054（依頼83 は 135,474）
(4) 残った詰まりの中身と場所
・⑦2台 種9（全員帰らなかった。11798 秒〜回の終わり 31402 秒）：1号機が卓42 へ向かう途中の (16.85, 5.77) で、
1.4 cm の幅を約 50 秒ごとに行ったり来たりし続けた。卓の前の (17.94, 5.98) には往復を終えた2号機が止まっていた。
1号機は少しずつ動いているので「止まった」と数えられず、30 秒の線に届かないため、助けを一度も呼んでいない（種9 の助け 30 回はどれもこの前）
・⑤2台 種0：1号機の 1往復の打ち切り (16.37, 8.52)、1218 秒。全員が帰ったあとで、待機場所の近くの台どうしの助けが終わる前に回が終わった
（⑤2台 種6・7 も同じ所 (14〜15, 8.7〜8.8) で、助けが終わる前に回が終わった。客は全員帰っている）
--------------------------------------------------------------------
5. 途中で止めたこと・KIOXIA が外れたこと
--------------------------------------------------------------------
・16:42 に私の見張りが「② の入店待ちの中央値が 0・1・2台とも依頼83 の2倍を超えた」と出し、止める線どおり 180回を止めた
（走っていた4回は「手で止めた」で、出力フォルダは _stopped。台帳には completed の行だけが入るので、この4回の行は無い）。
調べると、見張りが「今回の種0〜4 の中央値」を「依頼83 の種0〜9 の中央値」と比べていた誤りだった。
② は種によって入店待ちが 1 分台と 8 分台に分かれる店で、同じ種どうしではどの回も依頼83 とほぼ同じ
（例：0台 種0〜4 の中央値 依頼83 8.06 → 今回 8.24）。見張りを同じ種どうしの比べ方に直し、同じ並びの続きから回した
・16:57:30 に KIOXIA が外れ、夜の実行係は新しい回を始めずに書き込みの失敗で落ちた（148 回 completed の時点）。
走っていた実行ファイル3本は、KIOXIA の無いまま Mac の中へ書かせないよう私が止めた。
17:0x に KIOXIA がつながり直したので、鍵ファイルが無いこと・前の行が変わっていないことを確かめてから、残り 32 回を続きとして回した
・180 回の出力は 3 回に分けて回したが、版（cs:73）・並び・設定は同じ。記録：night/20261103_base71/
（runner_log・runs.csv・judge.md。judge は 回の失敗 5（止めた4回＋⑦2台種9）・基準なし 179）、/tmp/req84/（並び・見張り・集計の手順と出力 agg71.txt）
--------------------------------------------------------------------
6. 台帳
--------------------------------------------------------------------
1918 行 → 2124 行（追記 206 行だけ。どれも 59 列。先頭 1918 行の md5 は 326414af… で始める前と同じ）
終わったあとの md5 a8e0a251e3f0de7ba1fe9436bb7d53ca。鍵ファイルは残っていない
追記：t84a 3・t84b 7・t84c 14（直しの途中の試し。夜の実行係は check-in していない版では回さないので、どれも check-in した cs:71〜73）・
det84a 1・det84b 1・base71 180
--------------------------------------------------------------------
決めてほしいこと
--------------------------------------------------------------------
1. ⑦2台 種9 の形（ロボットが少しずつ行ったり来たりして「止まった」と数えられず、助けを呼ばない）を直すかどうか。
直すなら「30 秒のあいだに 0.3 m も進めていなければ止まりと同じに扱って助けを呼ぶ」のように、止まりの数え方（30 秒の線の測り方）に
手が入る。今回は「30 秒の線は変えない」ので手を入れていない
2. 全員が帰ったあとに残るロボットどうしの助け（⑤2台 種0・6・7）は、回の終わりに残った詰まりに数えるか、記録だけにするか
3. 向きが逆の2本（⑦入店待ち 1→2台：試算の差 0.02 分・⑤入店待ち 1→2台：Unity の差 1.45 分）を記録だけにするか。
⑤ は b の直し（待機場所の台が人の道をふさいだら助けを呼ぶ）で 2台の入店待ちが 5.63 → 7.62 分に増えたためとみられるが、確かめていない
4. ④2台 種4 のように、奥の台の相手が客で、助けのスタッフが手前の別の台にふさがれる形は、回の中で解けるが 1 時間を超えることがある（5166 秒）。
このままにするか
判定：失敗
````
#### 20261103_84_④入口とトイレ前の解けない詰まりを直す_20261103_1543.md（依頼84 の見張り係の記録）
````markdown
# 結果：20261103_84_④入口とトイレ前の解けない詰まりを直す
- 状態：完了
- 始めた時刻：2026-11-03 15:43
- 終わった時刻：2026-11-03 17:22（99分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume 2c7968ff-3518-44ca-81d8-c2e068a00eb9`
## Claude Code の報告
a・b・c の原因を確かめて直し、180回で確かめました。前回より大きく良くなりましたが、新しく1回だけ全員が帰らない回が出たので、判定は「失敗」です。
**やったこと**
- 始める前の確かめは、どれも依頼どおりでした。台帳は退避してから回しました（1918 行）。
- 原因（報告ファイルの 1 章に詳しく書きました）
- a（④2台）：助けで動かす先が「相手の道の線から少し外す」だけで、相手のセンサーの中に残っていました。そのため同じ助けが 514〜699 回くり返され、毎回 2.5 cm しか動いていませんでした。さらに、動かす台が行き止まりのへこみの奥にあり、助けのスタッフは手前の台にふさがれて着けませんでした（47 回交代）。
- b（トイレ前）：客は、トイレから席へ戻る途中で止まっていました。ふさいでいたのは、⑤では待機場所に止まっているロボット、②では持ち場に立つ手の空いたスタッフです。どちらも止まっているだけなので、助けも人どうしの決まりも届いていませんでした。戻り道には「あきらめる」決まりもありません。
- c（料理）：19 件とも記録の閉じ忘れで、料理はすべて届いていました。仕事を板から外すときに詰まりの記録を閉じていなかった件と、料理を届けたあとの戻り道で、済んだ仕事を「交代」に回していた件です。
- 直したこと（cs:71〜73）
- 同じ相手との助けが同じ所でくり返されたら、動かす先を相手のセンサーの外まで離します。止まっている台に使っている 1.2 m の決め方を、そのまま使いました。
- 助けのスタッフが着けずに交代したら、手の届く相手の台の方を動かします。
- 助けのスタッフが台から 0.8 m 以内にいれば、着いたとみなします。
- 30 秒動けない人のすぐ前に、止まっている台か手の空いたスタッフがいれば、そちらをどかします。台は助けを呼んで押し、スタッフは自分で歩いてどきます。
- c の記録の閉じ忘れを直しました。
- ⑦種7 の2回を比べ、そのあと 180 回（base71）を回しました。
**結果**
- 同じ種の2回は、記録が1行も違いません（違うのは計算にかかった時間の欄と名札だけで、前回と同じ扱い）。
| 項目 | 依頼83 | 今回 |
|---|---|---|
| 瞬間移動・1コマの跳び | 0・0 | 0・0 |
| 解けずに残った詰まり | 92 件・21 回 | 2 件・2 回 |
| 全員が帰らなかった回 | 6 回 | 1 回（⑦2台 種9） |
| 助け（1往復あたり） | 0.290 | 0.193 |
| ④2台の入店待ち／料理の待ち（中央値） | 18.96／2.18 分 | 17.96／1.73 分 |
- 中央値が依頼83 の2倍を超えた店・台数はありません。いちばん増えたのは ⑤2台の入店待ちで、5.63 → 7.62 分（1.35 倍）です。
- 向きは 12 本中 10 本が試算と同じです。依頼83 で逆だった2本は直り、⑦と⑤の入店待ち 1→2台が新しく逆になりました。
- 新しい1回（⑦2台 種9）：ロボットが卓の手前で 1.4 cm の幅を行ったり来たりし続けました。少しずつ動いているので「止まった」と数えられず、30 秒の線に届かないまま、助けを一度も呼んでいません。
- 残る1件は ⑤2台 種0 の 1往復の打ち切りで、全員が帰ったあとに残っています。⑤2台 種0・6・7 では、助けが終わる前に回が終わりました。
- 途中で2回止まりました。
- 私の見張りの誤りで、180 回を一度止めました。今回の種0〜4 の中央値を、依頼83 の種0〜9 の中央値と比べていました。同じ種どうしでは超えていなかったので、続きから回しました。
- 16:57 に KIOXIA が一度外れました。つながり直したあと、鍵ファイルが無く前の行も変わっていないことを確かめてから、残り 32 回を回しました。
- 台帳は 1918 → 2124 行です。追記だけで前の行は変わっておらず、鍵ファイルも残っていません。
**変えたファイル**
- Assets/ServiceSim/Service/ServiceOps.cs・Robot/ServingRobotController.cs・People/StaffAgent.cs・Experiment/TripLogger.cs・Experiment/ExperimentRunner.cs
- 版は cs:73、実行ファイルは build_id cs73_20261103_1601（保留 0）
- 報告は claude_code_reports/20261103_base71.txt に書きました（最後の行は「判定：失敗」）。
**決めてほしいこと**
1. ⑦種9 の形を直すかどうか。直すなら「30 秒で 0.3 m も進めなければ止まりと同じに扱う」のように、30 秒の線の測り方に手が入ります。
2. 全員が帰ったあとに残るロボットどうしの助け（⑤2台 種0・6・7）を、解けずに残った詰まりに数えるか、記録だけにするか。
3. 向きが逆の2本を記録だけにするか。⑦は試算の差が 0.02 分でほぼ横ばいです。⑤は Unity の差が 1.45 分で、b の直しで増えたとみていますが、確かめていません。
4. ④2台 種4 のように、回の中で解けるが 1 時間を超える詰まり（5166 秒）を、このままにするか。
````
【画像】LOG435_04_report_83_84.png 報告動画の1枚。依頼83 から依頼84 で、残った詰まりが92件・21回から2件・2回に、全員が帰らなかった回が6回から1回に減ったことを並べた表
## 作業ログ ― 依頼が終わるたびに、最初からの変化を1分の報告動画にした
依頼が続くと、何が変わって何が良くなかったのかが分かりにくくなります。そこで出た頼みは次のとおりです。
> 最近何が変更になって、何が良くなかったのかがわかりづらくなっています。定期的に何がどうなっているのかわかりやすく報告を動画で作ってください。
> 特に最初の頃からどのくらい良くなったのか変化の差を知りたいです。
頻度は依頼が終わるたび、形は図と字幕の1〜2分、範囲は ServiceSim だけ、と決めました。数字は台帳（unity_ledger_v1.csv）の③⑦・ロボット2台・普通の混み具合の中央値で、10/23 の最初の版から並べます。置き場所は KIOXIA の service_sim/status_videos/ にし、MASTER の保存先の表にも1行足しました。
作り方は、スライドの並び・数字・字幕を書いた JSON を、Playwright で 1920×1080 の画像にして、ffmpeg でつなぐだけです。
【画像】LOG435_03_report_entry_wait.png 報告動画の1枚。③⑦の店・ロボット2台の入店待ちが、10/23 の6.0分から依頼84 の2.5分に縮み、サイトの試算1.4分に近づいた折れ線
この日に作った報告動画は7本です。
| 時刻 | 中身 | 判定 |
|---|---|---|
| 12:30 | 最初の頃からの変化（立ち往生・止まり・瞬間移動・入店待ち） | ― |
| 13:00〜13:50 | 依頼79c・80・81 | 合格／止めた |
| 14:20 | 依頼82：瞬間移動0 | 合格 |
| 15:45 | 依頼83：6店180回 | 失敗 |
| 17:25 | 依頼84：詰まり 21回 → 2回 | 失敗 |
#### make_video.py（報告動画を作るコードの全文）
````python
"""ServiceSim の報告動画を作る。spec.json（スライドの並び）→ 1920x1080 の mp4。
使い方: python3 make_video.py spec.json out.mp4
スライドの種類: title / chart / rows / steps
"""
import json, sys, subprocess, html, pathlib, tempfile
from playwright.sync_api import sync_playwright
W, H = 1920, 1080
INK, QUIET, LINE, BG = "#1d1d1b", "#6b6a64", "#d9d6cc", "#faf9f5"
ACC, GOOD, BAD, SITE = "#2f6fdf", "#1d9e75", "#d85a30", "#9a9890"
E = html.escape
CSS = f"""
*{{margin:0;padding:0;box-sizing:border-box}}
body{{width:{W}px;height:{H}px;background:{BG};font-family:'Noto Sans CJK JP';color:{INK};position:relative;overflow:hidden}}
.top{{position:absolute;left:96px;top:64px;font-size:30px;color:{QUIET}}}
h1{{position:absolute;left:96px;top:120px;right:96px;font-size:60px;font-weight:700;line-height:1.3}}
.main{{position:absolute;left:96px;right:96px;top:260px;bottom:220px}}
.sub{{position:absolute;left:0;right:0;bottom:0;height:180px;background:#1d1d1b;color:#fff;font-size:40px;line-height:1.5;padding:30px 120px;display:flex;align-items:center;justify-content:center;text-align:center}}
.row{{display:flex;align-items:center;gap:28px;font-size:38px;line-height:1.4;margin-bottom:30px}}
.tag{{flex:none;min-width:150px;padding:8px 20px;border-radius:10px;font-size:30px;font-weight:700;text-align:center;color:#fff}}
.note{{font-size:28px;color:{QUIET};margin-top:16px}}
"""
def svg_chart(s):
xs = s["x"]; series = s["series"]; unit = s.get("unit", "")
cw, ch = 1728, 500; l, r, t, b = 120, 360, 30, 70
vals = [v for se in series for v in se["values"] if v is not None]
vmax = s.get("ymax") or max(vals) * 1.15
X = lambda i: l + i * (cw - l - r) / (len(xs) - 1)
Y = lambda v: t + (ch - t - b) * (1 - v / vmax)
out = [f'')
return "".join(out)
def body(s):
if s["kind"] == "title":
return f'{E(s["title"])}
{"
".join(E(x) for x in s.get("lines", []))}
'
h = f'{E(s["title"])}
'
if s["kind"] == "chart":
note = f'{E(s["note"])}
' if s.get("note") else ""
return h + f'{svg_chart(s)}{note}
'
if s["kind"] in ("rows", "steps"):
cols = {"good": GOOD, "bad": BAD, "acc": ACC, "quiet": SITE}
rows = "".join(f'{E(r["tag"])}{E(r["text"])}
' for r in s["rows"])
return h + f'{rows}
'
raise ValueError(s["kind"])
def main(spec_path, out):
spec = json.load(open(spec_path, encoding="utf-8"))
tmp = pathlib.Path(tempfile.mkdtemp())
segs = []
with sync_playwright() as p:
br = p.chromium.launch(); pg = br.new_page(viewport={"width": W, "height": H})
for i, s in enumerate(spec["slides"]):
doc = f'{E(spec["header"])} {i+1}/{len(spec["slides"])}
{body(s)}{E(s["sub"])}
'
pg.set_content(doc); pg.wait_for_timeout(150)
png = tmp / f"s{i:02d}.png"; pg.screenshot(path=str(png))
seg = tmp / f"s{i:02d}.mp4"
subprocess.run(["ffmpeg", "-y", "-loglevel", "error", "-loop", "1", "-i", str(png), "-t", str(s.get("sec", 10)),
"-vf", "fade=in:0:8,format=yuv420p", "-r", "30", "-c:v", "libx264", "-preset", "veryfast", str(seg)], check=True)
segs.append(seg)
br.close()
lst = tmp / "list.txt"; lst.write_text("".join(f"file '{x}'\n" for x in segs))
subprocess.run(["ffmpeg", "-y", "-loglevel", "error", "-f", "concat", "-safe", "0", "-i", str(lst), "-c", "copy", out], check=True)
print(out)
if __name__ == "__main__":
main(sys.argv[1], sys.argv[2])
````
#### spec_20261103_1230.json（最初の報告動画の中身）
````json
{
"header": "ServiceSim 報告 11/3 12:30",
"slides": [
{"kind": "title", "title": "最初の頃から、どれだけ良くなったか",
"lines": ["比べたのは ③ と ⑦ の店、ロボット2台、普通の混み具合", "10/23 の最初の Unity から、今日の版まで"],
"sub": "まず最初の頃からの変化。そのあと今日あったことと、次にやることを見ます", "sec": 8},
{"kind": "chart", "title": "立ち往生は、1往復あたり 0.54回 → 0.04回",
"x": ["10/23 最初", "10/25 v2", "10/27 v3", "10/29 v4", "11/02 v5", "11/03 今日"],
"series": [{"name": "Unity", "values": [0.541, 0.156, 0.156, 0.154, 0.124, 0.04], "color": "good"}],
"unit": "立ち往生の回数（1往復あたり・中央値）", "dp": 2,
"note": "今日の数字は立ち往生をスタッフが助ける版で、まだ6回分だけ。同じ種でも結果が揺れるので、夜の180回で確かめる",
"sub": "いちばん大きく良くなったのは立ち往生。最初は2往復に1回止まって動けなくなっていた", "sec": 14},
{"kind": "chart", "title": "止まっていた時間は、1往復あたり 50秒 → 20秒前後",
"x": ["10/23 最初", "10/25 v2", "10/27 v3", "10/29 v4", "11/02 v5", "11/03 今日"],
"series": [{"name": "Unity", "values": [49.5, 28.9, 26.3, 24.7, 18.1, 22.7], "color": "good"}],
"unit": "止まっていた秒（1往復あたり・中央値）", "dp": 0,
"note": "今日は助けを待つ30秒が入ったので少し増えた。かわりに、何分も動けない回がなくなった",
"sub": "道を自分で引く動き方と、すれ違い・待機場所へ戻る決まりで、止まりは半分以下になった", "sec": 13},
{"kind": "chart", "title": "客の瞬間移動は、1回の営業で 66回 → 33回",
"x": ["10/23 最初", "10/25 v2", "10/27 v3", "10/29 v4", "11/02 v5", "11/03 今日"],
"series": [{"name": "Unity", "values": [66, 82.5, 67.5, 63.5, 62.5, 33], "color": "bad"}],
"unit": "瞬間移動の回数（1回の営業・中央値）", "dp": 0,
"note": "今日の半減は、ドリンクバー・トイレから席へ戻るときの数え方の誤りを直したため。大型店も 181回 → 38回",
"sub": "現実にはない瞬間移動はまだ残っている。助けのときの瞬間移動は、いま直している最中", "sec": 13},
{"kind": "chart", "title": "入店待ちは、試算との差が 4.8分 → 0.5分",
"x": ["10/23 最初", "10/25 v2", "10/27 v3", "10/29 v4", "11/02 v5", "11/03 今日"],
"series": [{"name": "Unity", "values": [5.97, 3.07, 3.74, 4.51, 3.99, 1.86], "color": "acc"},
{"name": "サイトの試算", "values": [1.21, 1.57, 1.18, 1.57, 1.57, 1.37], "color": "site", "dash": true, "below": true}],
"unit": "入店待ち（分・中央値）", "dp": 1,
"note": "サイトの試算が正。Unity は試算に近づくほど、店で起きることを正しく映せている",
"sub": "Unity の入店待ちは、サイトの試算にかなり近づいた。料理の待ちは 4.1分 → 1.7分（試算は 1.0分）", "sec": 14},
{"kind": "steps", "title": "今日あったこと",
"rows": [
{"tag": "74 合格", "c": "good", "text": "客の瞬間移動の数え方を直した"},
{"tag": "75 済", "c": "good", "text": "問題に寄る動画を6店で撮り直した（報告の前に再起動）"},
{"tag": "76 止めた", "c": "bad", "text": "立ち往生の助けを入れたが、同じ所で16回助けが要った"},
{"tag": "77 止めた", "c": "bad", "text": "同じ種で2回回すと、結果が揺れた（動けない回 12回 対 0回）"},
{"tag": "78 取りやめ", "c": "quiet", "text": "人の部品の切り出し。止めたあとも裏で動き続けた"},
{"tag": "79c 実行中", "c": "acc", "text": "同じ種で同じ結果にする・助けを瞬間移動なしに直す"}
],
"sub": "今日は直しが2つ入ったが、つなぎ方の失敗で依頼が3つ止まった", "sec": 15},
{"kind": "rows", "title": "良くなかったこと",
"rows": [
{"tag": "つなぎ方", "c": "bad", "text": "前の依頼が止まっても、次の依頼がそのまま走った"},
{"tag": "止め方", "c": "bad", "text": "Ctrl+C では Claude Code が止まらず、裏で書き換えが続いた"},
{"tag": "揺れ", "c": "bad", "text": "同じ種でも結果が変わり、良くなったかを言い切れなかった"}
],
"sub": "直したこと：新規に置くのは1件だけ。判定を読んでから次を置く。止めるときは pkill も打つ", "sec": 13},
{"kind": "steps", "title": "次にやること",
"rows": [
{"tag": "1", "c": "acc", "text": "79c の判定を見る（同じ種で同じ結果になったか）"},
{"tag": "2", "c": "acc", "text": "合格なら、夜に6店180回の基準データを取り直す"},
{"tag": "3", "c": "acc", "text": "人の動きを部品として切り出す（中身は変えない）"},
{"tag": "4", "c": "acc", "text": "残りの瞬間移動3つをなくす"}
],
"sub": "次の報告は、79c が終わったときに作ります", "sec": 10}
]
}
````
#### spec_20261103_1300.json
````json
{
"header": "ServiceSim 報告 依頼79c 11/3 13:00",
"slides": [
{"kind": "title", "title": "依頼79c：同じ種で同じ結果になった",
"lines": ["同じ種で同じ結果にする → 合格", "立ち往生の助けの直し → 待機場所の詰まりが1つ残った", "判定：止めた（決めてほしいことが1つ）"],
"sub": "大きな山だった、同じ種で同じ結果が出るようになりました", "sec": 9},
{"kind": "rows", "title": "同じ種で同じ結果：合格",
"rows": [
{"tag": "1本ずつ", "c": "good", "text": "同じ条件・同じ種の2回が、6組とも1行も違わない"},
{"tag": "4本同時", "c": "good", "text": "4本同時に回しても、6組とも一致"},
{"tag": "1本と4本", "c": "good", "text": "1本の回と4本の回も一致"},
{"tag": "速さ", "c": "acc", "text": "1回あたり 3〜4分 → 1.2〜1.5分に縮んだ"}
],
"sub": "人のよけ方の計算を1本の流れで順番に回すようにして、Mac の忙しさで結果が変わらなくなった", "sec": 13},
{"kind": "chart", "title": "立ち往生は、1往復あたり 0.54回 → 0.02回",
"x": ["10/23 最初", "10/25 v2", "10/27 v3", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c"],
"series": [{"name": "Unity", "values": [0.541, 0.156, 0.156, 0.154, 0.124, 0.04, 0.017], "color": "good"}],
"unit": "立ち往生の回数（1往復あたり・中央値・③⑦ロボット2台）", "dp": 2,
"note": "79c は6回分。同じ種なら同じ結果になったので、ここからの差は揺れではなく直しの効き目",
"sub": "立ち往生は最初の30分の1まで減った", "sec": 11},
{"kind": "chart", "title": "客の瞬間移動は、1回の営業で 66回 → 20回",
"x": ["10/23 最初", "10/25 v2", "10/27 v3", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c"],
"series": [{"name": "Unity", "values": [66, 82.5, 67.5, 63.5, 62.5, 33, 19.5], "color": "bad"}],
"unit": "瞬間移動の回数（1回の営業・中央値）", "dp": 0,
"note": "残りは客の逃がし弁（ドリンクバーがほとんど）・1往復の打ち切り・スタッフが3回で移す。助けの瞬間移動は0回",
"sub": "まだ0ではない。現実にはないので、次の段で0にする", "sec": 11},
{"kind": "chart", "title": "入店待ちは、試算との差が 4.8分 → 0.2分",
"x": ["10/23 最初", "10/25 v2", "10/27 v3", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c"],
"series": [{"name": "Unity", "values": [5.97, 3.07, 3.74, 4.51, 3.99, 1.86, 1.55], "color": "acc"},
{"name": "サイトの試算", "values": [1.21, 1.57, 1.18, 1.57, 1.57, 1.37, 1.37], "color": "site", "dash": true, "below": true}],
"unit": "入店待ち（分・中央値）", "dp": 1,
"note": "料理の待ちは 4.1分 → 1.6分（試算は 1.0分）",
"sub": "Unity はサイトの試算にさらに近づいた", "sec": 11},
{"kind": "rows", "title": "立ち往生の助けの直し",
"rows": [
{"tag": "解けた", "c": "good", "text": "受け渡し口の近くの詰まり 8回 → 0回"},
{"tag": "解けた", "c": "good", "text": "助けに行ったスタッフの瞬間移動 0回"},
{"tag": "残った", "c": "bad", "text": "待機場所の詰まり 8回 → 4回。止まっている台を2cmしか動かせない"}
],
"sub": "止まっている台は相手の道から外れているので、今の決め方だと隣のマスへ2cmしか動かない", "sec": 12},
{"kind": "rows", "title": "決めてほしいこと：待機場所で止まっている台をどこへ動かすか",
"rows": [
{"tag": "a", "c": "acc", "text": "相手の前のセンサーの長さ 0.6m も避けるところまで動かす"},
{"tag": "b", "c": "acc", "text": "決まった空き場所へ動かす"},
{"tag": "c", "c": "acc", "text": "待機場所どうしの間を店の形で広げる（今は約0.76m）"},
{"tag": "d", "c": "acc", "text": "自分の待機場所のすぐ手前でふさがれたら、往復を終えたとみなす"}
],
"sub": "決まったら直して、夜に6店180回の基準データを取り直す", "sec": 13}
]
}
````
#### spec_20261103_1320.json
````json
{
"header": "ServiceSim 報告 依頼80 11/3 13:20",
"slides": [
{"kind": "title", "title": "依頼80：待機場所の詰まりが解けた",
"lines": ["止まっている台を 1.2m 離すように直した", "同じ種で同じ結果も崩れていない", "判定：止めた（すれ違いの所に別の止まりが1つ）"],
"sub": "合格の線の3つ目「止まったまま解けない所が残らない」に近づいた", "sec": 9},
{"kind": "rows", "title": "直したこと・解けたこと",
"rows": [
{"tag": "解けた", "c": "good", "text": "⑦の待機場所の詰まり 2回ずつ2組 → 1回（72秒で解けた）"},
{"tag": "減った", "c": "good", "text": "同じ所で何度も助けが要る形 51 → 12（6回の合計）"},
{"tag": "減った", "c": "good", "text": "呼んだ助け 143 → 96 ・ 立ち往生 19 → 15"},
{"tag": "残った", "c": "bad", "text": "相手がいないのに「すれ違いで下がる」まま約500秒止まる回が2つ"}
],
"sub": "残った止まりは助けではなく、すれ違いの処理の中で起きている。打ち切りで瞬間移動になっていた", "sec": 14},
{"kind": "chart", "title": "立ち往生と止まり時間は、最初から大きく減った",
"x": ["10/23 最初", "10/25 v2", "10/27 v3", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c", "11/03 80"],
"series": [{"name": "止まり秒", "values": [49.5, 28.9, 26.3, 24.7, 18.1, 22.7, 17.9, 16.1], "color": "good"}],
"unit": "止まっていた秒（1往復あたり・中央値・③⑦ロボット2台）", "dp": 0,
"note": "立ち往生は 1往復あたり 0.54回 → 0.02回。入店待ちの試算との差は 4.8分 → 0.1分",
"sub": "止まっていた時間は最初の3分の1になった", "sec": 11},
{"kind": "steps", "title": "次にやること",
"rows": [
{"tag": "81", "c": "acc", "text": "すれ違いの止まりを直し、残りの瞬間移動を0にする"},
{"tag": "夜", "c": "acc", "text": "6店180回でベースのデータを取る"},
{"tag": "サイト", "c": "acc", "text": "標準ファミレスの通しの動画・パネル付きの比較動画"},
{"tag": "次の店", "c": "quiet", "text": "大型店⑧⑨ → 小型店・洗い場が遠い店・焼肉食べ放題"}
],
"sub": "合格の線の1つ目「瞬間移動0」が次の山", "sec": 10}
]
}
````
#### spec_20261103_1350.json
````json
{
"header": "ServiceSim 報告 依頼81 11/3 13:50",
"slides": [
{"kind": "title", "title": "依頼81：瞬間移動が 0回 になった",
"lines": ["⑦種7で 22回 → 0回", "すれ違いで下がったまま止まる形も出なくなった", "判定：止めた（ドリンクバーの帰りの混み）"],
"sub": "合格の線の1つ目「瞬間移動0」を、まず1回分で達成", "sec": 9},
{"kind": "chart", "title": "客の瞬間移動は、66回 → 0回",
"x": ["10/23 最初", "10/25 v2", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c", "11/03 81"],
"series": [{"name": "Unity", "values": [66, 82.5, 63.5, 62.5, 33, 19.5, 0], "color": "good"}],
"unit": "瞬間移動の回数（1回の営業）", "dp": 0,
"note": "81 は⑦種7の1回分。ほかの店と種は次の確かめで見る",
"sub": "移す代わりに、回り込む・待って行き直す・歩いて席へ戻る・次のスタッフに交代する、にした", "sec": 12},
{"kind": "rows", "title": "かわりに見えてきたこと",
"rows": [
{"tag": "混み", "c": "bad", "text": "ドリンクバーから席へ戻る客が混む 31回・合わせて27分"},
{"tag": "場所", "c": "bad", "text": "いちばん多いのはドリンクバーの前（5回・690秒）"},
{"tag": "結果", "c": "good", "text": "最後は全員席に着いた。解けずに残った人は0"},
{"tag": "待ち", "c": "good", "text": "入店待ち 1.41分→1.45分、料理の待ち 1.43分→1.30分（ほぼ同じ）"}
],
"sub": "前は瞬間移動で隠れていた、ドリンクバーまわりの混みが数字に出てきた", "sec": 13},
{"kind": "steps", "title": "次にやること（依頼82）",
"rows": [
{"tag": "1", "c": "acc", "text": "③⑦×種3つを回し、ほかの店と種でも瞬間移動0か確かめる"},
{"tag": "2", "c": "acc", "text": "助けでロボットを動かすときも、跳ばずに少しずつ動かす"},
{"tag": "3", "c": "acc", "text": "ドリンクバーの混みは詰まりとして記録する（店の形の直しの手がかり）"},
{"tag": "夜", "c": "quiet", "text": "合格なら、6店180回でベースのデータを取る"}
],
"sub": "ドリンクバーの混みは、店の形を直すときの手がかりとして残す", "sec": 11}
]
}
````
#### spec_20261103_1420.json（依頼82）
````json
{
"header": "ServiceSim 報告 依頼82 11/3 14:20",
"slides": [
{"kind": "title", "title": "依頼82：合格。瞬間移動 0回 を6回とも確かめた",
"lines": ["③⑦×種3つ・ロボット0〜2台の12回すべてで瞬間移動0", "助けでロボットを動かすときも、跳ばずに押して動かす", "判定：合格"],
"sub": "合格の線の1つ目「瞬間移動0」と3つ目「止まったまま解けない所が残らない」を満たした", "sec": 9},
{"kind": "chart", "title": "客の瞬間移動は、66回 → 0回",
"x": ["10/23 最初", "10/25 v2", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c", "11/03 82"],
"series": [{"name": "Unity", "values": [66, 82.5, 63.5, 62.5, 33, 19.5, 0], "color": "good"}],
"unit": "瞬間移動の回数（1回の営業・中央値・③⑦ロボット2台）", "dp": 0,
"note": "12回とも解けずに残った人・ロボットは0。全員が帰った",
"sub": "現実にない動きは、これでなくなった", "sec": 11},
{"kind": "chart", "title": "入店待ちは、試算との差が 4.8分 → 0.2分のまま",
"x": ["10/23 最初", "10/25 v2", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c", "11/03 82"],
"series": [{"name": "Unity", "values": [5.97, 3.07, 4.51, 3.99, 1.86, 1.55, 1.53], "color": "acc"},
{"name": "サイトの試算", "values": [1.21, 1.57, 1.57, 1.57, 1.37, 1.37, 1.37], "color": "site", "dash": true, "below": true}],
"unit": "入店待ち（分・中央値）", "dp": 1,
"note": "料理の待ちは 1.5分（試算は 1.0分）。瞬間移動をなくしても、待ち時間はほとんど増えなかった",
"sub": "瞬間移動をなくしても、試算との近さは保てた", "sec": 11},
{"kind": "rows", "title": "代わりに見えてきたこと",
"rows": [
{"tag": "増えた", "c": "bad", "text": "立ち往生 15 → 39回、30秒以上の止まり 100 → 132回（6回の合計）"},
{"tag": "理由", "c": "quiet", "text": "前は移して消していたふさぎが、今は止まって助けで解く形になった（見込み）"},
{"tag": "詰まり", "c": "bad", "text": "ドリンクバーの前が上位 3か所。6回で合わせて約2.6時間"},
{"tag": "解けた", "c": "good", "text": "どれも助けか歩き直しで解けている"}
],
"sub": "ドリンクバーの前の混みは、店の形を直すときの手がかりとして記録している", "sec": 13},
{"kind": "steps", "title": "次にやること",
"rows": [
{"tag": "夜", "c": "acc", "text": "6店×ロボット0・1・2台×種10個＝180回で、ベースのデータを取る"},
{"tag": "サイト", "c": "acc", "text": "標準ファミレスの通しの動画・パネル付きの比較動画"},
{"tag": "次の店", "c": "quiet", "text": "大型店⑧⑨ → 小型店・洗い場が遠い店・焼肉食べ放題"}
],
"sub": "夜の180回で、合格の線の4つ目「試算と向きが合う」を確かめる", "sec": 10}
]
}
````
#### spec_20261103_1545.json（依頼83）
````json
{
"header": "ServiceSim 報告 依頼83 11/3 15:45",
"slides": [
{"kind": "title", "title": "依頼83：失敗。瞬間移動は0、でも解けない詰まりが残った",
"lines": ["6店 × ロボット0・1・2台 × 種10個 ＝ 180回（cs70・コードは変えていない）", "180回とも最後まで回った。瞬間移動は合計0回", "判定：失敗（合格の線3つ目「解けずに残るものがない」に届かない）"],
"sub": "合格の線の1つ目と4つ目はほぼ満たした。止めたのは3つ目", "sec": 10},
{"kind": "chart", "title": "瞬間移動は、180回に広げても 0回",
"x": ["10/23 最初", "10/25 v2", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c", "11/03 82", "11/03 83"],
"series": [{"name": "Unity", "values": [66, 82.5, 63.5, 62.5, 33, 19.5, 0, 0], "color": "good"}],
"unit": "瞬間移動の回数（1回の営業・中央値・③⑦ロボット2台）", "dp": 0,
"note": "180回の合計も0。助けで押した2945回も、すべて歩く速さで押している",
"sub": "6回で確かめた「瞬間移動0」は、6店・180回でも崩れなかった", "sec": 10},
{"kind": "chart", "title": "入店待ちは、種を10個にすると 3.0分（試算 1.4分）",
"x": ["10/23 最初", "10/25 v2", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c", "11/03 82", "11/03 83"],
"series": [{"name": "Unity", "values": [5.97, 3.07, 4.51, 3.99, 1.86, 1.55, 1.53, 3.00], "color": "acc"},
{"name": "サイトの試算", "values": [1.21, 1.57, 1.57, 1.57, 1.37, 1.37, 1.37, 1.37], "color": "site", "dash": true, "below": true}],
"unit": "入店待ち（分・中央値・③⑦ロボット2台）", "dp": 1,
"note": "82までは種3つ・83は種10個。③は2.8分、⑦は4.6分。大きさの差は記録だけにしている",
"sub": "種を増やすと試算との差は広がって見えた。それでも最初の6.0分の半分", "sec": 12},
{"kind": "rows", "title": "ロボットを足したときの向き：12本中10本が試算と同じ",
"rows": [
{"tag": "③ ⑤ ②", "c": "good", "text": "入店待ち・料理の待ちとも、試算と同じ向き"},
{"tag": "⑦", "c": "good", "text": "入店待ちが1→2台で少し増えるのも、試算と同じ"},
{"tag": "④ 入店", "c": "good", "text": "2台で増える向きは試算と同じ（12.6 → 19.0分）"},
{"tag": "④ 料理", "c": "bad", "text": "1→2台で 2.05 → 2.18分 と少し増える（試算は減る）"},
{"tag": "⑥ 入店", "c": "bad", "text": "1→2台で 5.39 → 5.52分 と少し増える（試算は減る）"}
],
"sub": "逆の2本はどちらも差0.13分。④は詰まりが多い店なので、詰まりを直してから見直したい", "sec": 14},
{"kind": "rows", "title": "解けずに残ったもの",
"rows": [
{"tag": "④ 2台", "c": "bad", "text": "入口近くでスタッフの案内・料理がロボットと何時間も詰まる（3回）"},
{"tag": "トイレ", "c": "bad", "text": "客のトイレ前の詰まりが最後まで解けない（3回・ロボット0台の回も）"},
{"tag": "料理", "c": "bad", "text": "スタッフの料理の詰まりが1件だけ残る回が15回（全員は帰った）"},
{"tag": "合わせて", "c": "quiet", "text": "残った詰まり92件・21回。全員が帰らなかった回が6回"}
],
"sub": "瞬間移動を消したぶん、前は隠れていた詰まりが見えるようになった", "sec": 13},
{"kind": "steps", "title": "次にやること（決めてもらってから）",
"rows": [
{"tag": "1", "c": "acc", "text": "④の入口近くの詰まりと、トイレ前の詰まりを直す"},
{"tag": "2", "c": "acc", "text": "直したら同じ180回を回し、合格の線3つ目を確かめる"},
{"tag": "並行", "c": "quiet", "text": "標準ファミレス（③）のサイト用の動画は、今の版で作り始められる"}
],
"sub": "③は全員が帰らなかった回が0。サイト用の動画は先に進められる", "sec": 11}
]
}
````
#### spec_20261103_1725.json（依頼84）
````json
{
"header": "ServiceSim 報告 依頼84 11/3 17:25",
"slides": [
{"kind": "title", "title": "依頼84：失敗。でも解けない詰まりは 21回 → 2回",
"lines": ["④の入口近く・トイレ前・料理の詰まりを直して、同じ180回を回し直した（cs73）", "全員が帰らなかった回は 6回 → 1回。瞬間移動は0回のまま", "判定：失敗（新しく ⑦ の1回で、ロボットが少しずつ行ったり来たりして助けを呼ばなかった）"],
"sub": "合格の線3つ目まであと少し。残ったのは、今までと違う形の詰まり1つ", "sec": 11},
{"kind": "chart", "title": "瞬間移動は、180回でも 0回のまま",
"x": ["10/23 最初", "10/25 v2", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c", "11/03 82", "11/03 83", "11/03 84"],
"series": [{"name": "Unity", "values": [66, 82.5, 63.5, 62.5, 33, 19.5, 0, 0, 0], "color": "good"}],
"unit": "瞬間移動の回数（1回の営業・中央値・③⑦ロボット2台）", "dp": 0,
"note": "直しを3つ入れても、跳ぶ動きは出なかった",
"sub": "詰まりを直すときも、瞬間移動に頼らない決まりは守れている", "sec": 9},
{"kind": "chart", "title": "入店待ちは 2.5分（試算 1.4分）。最初の 6.0分から半分以下に",
"x": ["10/23 最初", "10/25 v2", "10/29 v4", "11/02 v5", "11/03 朝", "11/03 79c", "11/03 82", "11/03 83", "11/03 84"],
"series": [{"name": "Unity", "values": [5.97, 3.07, 4.51, 3.99, 1.86, 1.55, 1.53, 3.00, 2.50], "color": "acc"},
{"name": "サイトの試算", "values": [1.21, 1.57, 1.57, 1.57, 1.37, 1.37, 1.37, 1.37, 1.37], "color": "site", "dash": true, "below": true}],
"unit": "入店待ち（分・中央値・③⑦ロボット2台）", "dp": 1,
"note": "83・84 は種10個。82までは種3つ。詰まりが減ったぶん、待ちも 3.0分 → 2.5分 に縮んだ",
"sub": "詰まりを解くと、待ち時間も試算に近づいた", "sec": 11},
{"kind": "rows", "title": "依頼83 → 依頼84 で変わったこと",
"rows": [
{"tag": "残った詰まり", "c": "good", "text": "92件・21回 → 2件・2回"},
{"tag": "帰れない回", "c": "good", "text": "全員が帰らなかった回 6回 → 1回"},
{"tag": "④ 2台", "c": "good", "text": "助けの回数 1往復あたり 2.13回 → 0.57回"},
{"tag": "詰まりの秒", "c": "good", "text": "合計 約286万秒 → 約18万秒"},
{"tag": "向き", "c": "acc", "text": "12本中10本が試算と同じ（逆の2本は入れ替わった）"}
],
"sub": "④の入口近く・トイレ前・料理の閉じ忘れの3つは、どれも直った", "sec": 13},
{"kind": "rows", "title": "残ったこと（決めてもらうこと）",
"rows": [
{"tag": "⑦ 2台", "c": "bad", "text": "ロボットが1.4cmを行ったり来たりし、止まったと数えられず助けを呼ばない"},
{"tag": "⑤ 2台", "c": "bad", "text": "入店待ちが 1→2台で増えた（6.2 → 7.6分。試算は減る）"},
{"tag": "閉店後", "c": "quiet", "text": "全員が帰ったあとに残るロボットどうしの助け（3回）"},
{"tag": "④ 2台", "c": "quiet", "text": "相手がお客さんのとき、解けるまで1時間を超える回がある"}
],
"sub": "⑦の形は、止まりの数え方（30秒の線）に手を入れるかどうかの判断が要る", "sec": 13},
{"kind": "steps", "title": "このあと",
"rows": [
{"tag": "区切り", "c": "acc", "text": "ここで一度区切って、LOG435 に記事にする"},
{"tag": "別の場", "c": "quiet", "text": "残った4つを決めて直す・③の録画・下げ膳の比較動画"}
],
"sub": "次の報告は、残りを直す依頼が終わったときに作ります", "sec": 8}
]
}
````
## 作業ログ ― サイトに出す動画は、録画の横に店の様子のパネルを付けた形にそろえた
サイトに出す動画（通しの動画・問題に寄る動画・配膳だけと配膳＋下げ膳の比較動画）は、初めて見る人が、ロボットとスタッフがいま何をしているかを読めないと意味がありません。そこで、録画の右に、1分ごとの店の様子（timeline.csv）を出すパネルを付けました。
【画像】LOG435_01_panel_video.png パネル付き動画の試作の1コマ。左に③の店の Unity の録画と色の説明、右にスタッフ4人がしていること・ロボット2台の様子・入口で待つ組・席にいる組・片付けを待つ卓・入口で待つ組の一日の線
この画像は形を確かめるための試作で、録画（cs:62）とパネルの数字（cs:70 の別の回）が違う回です。本番は、合格した版で③を録画し直し、同じ回の数字を出します。
試作を見ての指摘で、形を3か所直しました。
| 指摘 | 直したこと |
|---|---|
| ここの色は立体の色に合わせた方がいいね。スタッフ青、ロボット白 | パネルのスタッフの四角は全部青、ロボットは白（運んでいる＝黒い縁、待機＝薄い）。録画の左上に色の説明を足した |
| 客だと少し乱暴な書き方？ | 色の説明を「お客さん」にした。「スタッフ」「ロボット」と並べて硬すぎない言い方 |
| これってなんの時間の単位？（「開店から 1:54」を見て） | 「開店から 1時間54分」と書く。1時間に満たないうちは「45分」 |
> あとはこのフォーマットに揃えて崩れないようにしてください。
形はスクリプトの中に固定し、決まりを PANEL_VIDEO_FORMAT.md に書きました。題が長いときや人数・台数が多いときは字や四角を小さくして収め、パネルがはみ出す・数字の列が足りない・出来た動画が 1920×1080 でないときは作るのを止めます。スタッフ9人・ロボット3台と、ロボット0台の場合で崩れないことを確かめました。
- ねらい：サイトの動画を、初めて見る人でも、だれが何をしているか読める形にする
- 変わったこと：店・台数が変わっても、同じスクリプトから同じ形の動画が出る
- 見込める効果（見込み）：比較動画で、ロボットを入れた側と入れない側のスタッフの手の空き方を、同じ並びのパネルで見比べられる。伝わったかは、サイトに出したあとの見られ方で確かめる
#### PANEL_VIDEO_FORMAT.md（パネル付き動画の決まり）
````markdown
# ServiceSim パネル付き動画の形（決まり）
サイトに出す ServiceSim の動画（通し・問題に寄る・比較）は、すべてこの形にそろえる。2026-11-03 エイイチ了承。変えるときはエイイチに確かめてから。
作り方：`tools/make_panel_video.py rec.mp4 frames.csv timeline.csv out.mp4 --title "③ 標準ファミレス・ロボット2台"`（形はこのスクリプトに固定してある。手で別の形を作らない）
- 画面：1920x1080・30fps。左 1360px が録画、右 560px がパネル
- 色：立体と同じ。お客さん＝黄・スタッフ＝青・ロボット＝白。録画の左上に色の説明「お客さん／スタッフ／ロボット」
- パネル（上から）：題（店・台数）→「開店から 1時間54分」→ スタッフ N人がしていること（案内・料理・呼び出し・会計・片付け・ロボットの助け・手すき。1人＝青い四角1つ）→ ロボット N台（運んでいる＝白・黒縁／待機＝薄い）→ 入口で待つ組・席にいる組・片付けを待つ卓 → 入口で待つ組の一日の線
- 言葉：「客」ではなく「お客さん」。時間は「1時間54分」と書き、「1:54」とは書かない
- 数字：録画と同じ回の timeline.csv を使う。別の回を重ねるのは試しのときだけ（--trial、題に（試作）が付く）
- 崩れ防止：長い題・人数や台数が多いときは字や四角を小さくして収める。パネルがはみ出す・列が足りない・出来た動画が 1920x1080 でないときは止まる
````
#### make_panel_video.py（パネル付き動画を作るコードの全文）
````python
"""ServiceSim のパネル付き動画を作る（サイトに出す動画・報告に使う動画はすべてこの形）。
使い方: python3 make_panel_video.py rec.mp4 frames.csv timeline.csv out.mp4 --title "③ 標準ファミレス・ロボット2台"
[--from 店の秒] [--to 店の秒] [--speed 倍] [--trial]
決まった形（2026-11-03 エイイチ了承。変えるときはエイイチに確かめてから）
画面 1920x1080・30fps。左 1360px が録画、右 560px がパネル
色 立体と同じ。お客さん＝黄・スタッフ＝青・ロボット＝白。録画の左上に色の説明（お客さん／スタッフ／ロボット）
パネル 上から：題（店・台数）→ 開店からの時間（「1時間54分」の形。1:54 とは書かない） → スタッフ N人がしていること（案内・料理・呼び出し・会計・片付け・
ロボットの助け・手すき。1人＝青い四角1つ）→ ロボット N台（運んでいる＝白・黒縁／待機＝薄い）→
入口で待つ組・席にいる組・片付けを待つ卓 → 入口で待つ組の一日の線（いまの時刻に縦線・映っている範囲を薄く）
言葉 「客」と書かずに「お客さん」。数字の欄は「〜組」「〜卓」
数字 録画と同じ回の timeline.csv を使う（違う回の数字を重ねるのは --trial のときだけ。題に（試作）が付く）
"""
import csv, argparse, subprocess, tempfile, pathlib, json
from PIL import Image, ImageDraw, ImageFont
W, H, PW = 1920, 1080, 560
VW = W - PW
FPS = 30
BG, INK, QUIET, LINE, SHADE = "#faf9f5", "#1d1d1b", "#6b6a64", "#d9d6cc", "#eeece4"
BAD, WARN = "#d85a30", "#c98a1a"
STAFF_C, ROBOT_C, GUEST_C = "#2a55c8", "#ffffff", "#e8c520" # 立体の色
FONT = "/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc"
FONTB = "/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc"
F = lambda s, b=False: ImageFont.truetype(FONTB if b else FONT, s, index=0)
STAFF = [("staff_guide", "案内"), ("staff_serve", "料理"), ("staff_call", "呼び出し"), ("staff_pay", "会計"),
("staff_clear", "片付け"), ("staff_rescue", "ロボットの助け"), ("staff_idle", "手すき")]
COUNTS = [("waiting_groups", "入口で待つ組", BAD), ("seated_groups", "席にいる組", INK), ("tables_dirty_untaken", "片付けを待つ卓", WARN)]
NEED = ["t_s", "robots_busy"] + [k for k, _ in STAFF] + [k for k, _, _ in COUNTS]
def hm(t):
t = int(t); h, m = t // 3600, t % 3600 // 60
return f"{h}時間{m:02d}分" if h else f"{m}分"
def fit(d, text, size, maxw, bold=False):
"""幅に収まるまで字を小さくする（崩れ防止）"""
while size > 14 and d.textlength(text, font=F(size, bold)) > maxw:
size -= 1
return F(size, bold)
def panel(row, rows, robots, staff_n, t_from, t_to, title):
im = Image.new("RGB", (PW, H), BG); d = ImageDraw.Draw(im)
x0, xr = 40, PW - 40; inner = xr - x0
d.text((x0, 36), title, font=fit(d, title, 26, inner), fill=QUIET)
clock = f"開店から {hm(row['t_s'])}"
d.text((x0, 76), clock, font=fit(d, clock, 52, inner, True), fill=INK)
y = 170
d.text((x0, y), f"スタッフ {staff_n}人 がしていること", font=F(28, True), fill=INK); y += 52
bx = x0 + 210; step = min(46, (xr - bx) // max(staff_n, 1)); box = step - 10
for k, name in STAFF:
v = int(float(row[k]))
d.text((x0, y), name, font=F(26), fill=INK if v else QUIET)
for i in range(v):
d.rounded_rectangle((bx + i * step, y + 4, bx + i * step + box, y + 4 + min(box, 32)), 6, fill=STAFF_C)
y += 44
y += 16
rb = int(float(row["robots_busy"]))
d.text((x0, y), f"ロボット {robots}台", font=F(28, True), fill=INK); y += 52
if robots == 0:
d.text((x0, y + 8), "入れていない", font=F(26), fill=QUIET)
else:
rstep = min(150, inner // robots); rw = rstep - 14
for i in range(robots):
busy = i < rb; lab = "運んでいる" if busy else "待機"
d.rounded_rectangle((x0 + i * rstep, y, x0 + i * rstep + rw, y + 50), 10,
fill=ROBOT_C if busy else BG, outline=INK if busy else LINE, width=3)
d.text((x0 + i * rstep + rw / 2, y + 25), lab, font=fit(d, lab, 24, rw - 12, True), fill=INK if busy else QUIET, anchor="mm")
y += 86
for k, name, c in COUNTS:
v = int(float(row[k]))
d.text((x0, y + 8), name, font=F(28), fill=INK)
d.text((xr - 10, y), str(v), font=F(48, True), fill=c if v else QUIET, anchor="ra")
y += 66
y += 14; gh = 120
d.text((x0, y), "入口で待つ組（営業の始めから終わり）", font=F(22), fill=QUIET); y += 36
ts = [r["t_s"] for r in rows]; vs = [int(float(r["waiting_groups"])) for r in rows]
vmax = max(max(vs), 1); tmax = ts[-1] or 1
X = lambda t: x0 + inner * min(max(t, 0), tmax) / tmax; Y = lambda v: y + gh - gh * v / vmax
d.rectangle((X(t_from), y, X(t_to), y + gh), fill=SHADE)
d.line([(X(t), Y(v)) for t, v in zip(ts, vs)], fill=BAD, width=3)
d.line((x0, y + gh, xr, y + gh), fill=LINE, width=2)
cx = X(row["t_s"]); d.line((cx, y, cx, y + gh), fill=INK, width=3)
assert y + gh <= H - 20, "パネルが下にはみ出す"
return im
def legend(path):
items = [(GUEST_C, "お客さん"), (STAFF_C, "スタッフ"), ("#f2f2f2", "ロボット")]
d0 = ImageDraw.Draw(Image.new("RGB", (1, 1))); f = F(26)
w = 20 + sum(38 + d0.textlength(n, font=f) + 34 for _, n in items)
im = Image.new("RGBA", (int(w), 64), (250, 249, 245, 230)); d = ImageDraw.Draw(im); x = 20
for c, name in items:
d.ellipse((x, 18, x + 28, 46), fill=c, outline=QUIET, width=2)
d.text((x + 38, 32), name, font=f, fill=INK, anchor="lm")
x += 38 + d.textlength(name, font=f) + 34
im.save(path)
def main():
ap = argparse.ArgumentParser()
ap.add_argument("rec"); ap.add_argument("frames"); ap.add_argument("timeline"); ap.add_argument("out")
ap.add_argument("--title", required=True)
ap.add_argument("--from", dest="t_from", type=float, default=0); ap.add_argument("--to", dest="t_to", type=float, default=None)
ap.add_argument("--speed", type=float, default=1.0)
ap.add_argument("--trial", action="store_true", help="録画と数字が別の回のとき（題に（試作）を付ける）")
a = ap.parse_args()
title = a.title + ("（試作）" if a.trial else "")
fr = [(int(r["frame"]), float(r["t_s"])) for r in csv.DictReader(open(a.frames))]
dt = fr[1][1] - fr[0][1] # 1コマが店の何秒か
rows = []
for r in csv.DictReader(open(a.timeline)):
r = dict(r); r["t_s"] = float(r["t_s"]); rows.append(r)
miss = [k for k in NEED if k not in rows[0]]
assert not miss, f"timeline.csv に列がない: {miss}"
cid = rows[0].get("condition_id", "")
robots = int(cid.split("_r")[1].split("_")[0]) if "_r" in cid else 0
staff_n = max(sum(int(float(r[k])) for k, _ in STAFF) for r in rows)
probe = json.loads(subprocess.run(["ffprobe", "-v", "error", "-select_streams", "v:0", "-show_entries", "stream=width,height",
"-of", "json", a.rec], capture_output=True, text=True, check=True).stdout)["streams"][0]
assert probe["width"] * 9 == probe["height"] * 16, "録画は 16:9 にする"
t_to = a.t_to if a.t_to is not None else fr[-1][1]
f_from = next(f for f, t in fr if t >= a.t_from); f_to = max(f for f, t in fr if t <= t_to)
v_from, v_dur = f_from / FPS, (f_to - f_from) / FPS
tmp = pathlib.Path(tempfile.mkdtemp())
sel = [r for r in rows if a.t_from - (rows[1]["t_s"] - rows[0]["t_s"]) < r["t_s"] <= t_to]
lst, p = [], None
for i, r in enumerate(sel):
t0 = max(r["t_s"], a.t_from); t1 = sel[i + 1]["t_s"] if i + 1 < len(sel) else t_to
if t1 <= t0: continue
p = tmp / f"p{i:04d}.png"; panel(r, rows, robots, staff_n, a.t_from, t_to, title).save(p)
lst.append(f"file '{p}'\nduration {(t1 - t0) / dt / FPS / a.speed:.4f}\n")
lst.append(f"file '{p}'\n")
(tmp / "p.txt").write_text("".join(lst))
legend(tmp / "lg.png")
vf = (f"[0:v]trim=start={v_from}:duration={v_dur},setpts=(PTS-STARTPTS)/{a.speed},"
f"scale=-2:{H},crop={VW}:{H}[v0];[2:v]format=rgba[lg];[v0][lg]overlay=32:32[v];"
f"[1:v]fps={FPS},setpts=PTS-STARTPTS[p];[v][p]hstack=inputs=2,format=yuv420p")
subprocess.run(["ffmpeg", "-y", "-loglevel", "error", "-i", a.rec, "-f", "concat", "-safe", "0", "-i", str(tmp / "p.txt"),
"-loop", "1", "-i", str(tmp / "lg.png"), "-filter_complex", vf, "-t", f"{v_dur / a.speed:.3f}",
"-r", str(FPS), "-c:v", "libx264", "-preset", "veryfast", "-crf", "22", a.out], check=True)
out = json.loads(subprocess.run(["ffprobe", "-v", "error", "-select_streams", "v:0", "-show_entries", "stream=width,height",
"-of", "json", a.out], capture_output=True, text=True, check=True).stdout)["streams"][0]
assert (out["width"], out["height"]) == (W, H), "出来た動画の大きさが違う"
print(a.out, f"{v_dur / a.speed:.1f}s")
if __name__ == "__main__":
main()
````
## 作業ログ ― 残ったことと、次に決めること
依頼84の報告の「決めてほしいこと」4つは、次の作業で決めます。
| 残ったこと | 決めること |
|---|---|
| ⑦2台 種9：ロボットが1.4cmを行ったり来たりし、止まったと数えられず助けを呼ばない | 「30秒のあいだに0.3mも進めていなければ止まりと同じに扱う」のように、止まりの数え方に手を入れるか |
| ⑤2台 種0・6・7：全員が帰ったあとに残るロボットどうしの助け | 回の終わりに残った詰まりに数えるか、記録だけにするか |
| ⑦・⑤の入店待ち（1→2台）が試算と逆 | 記録だけにするか。⑤は直しの影響を確かめるか |
| ④2台 種4：相手がお客さんのとき、解けるまで1時間を超える | このままにするか |
そのあとは、合格した版で③を録画し直してパネル付きの通しの動画を作り、Unity に下げ膳（お客さんが卓でロボットに器を入れる形と、スタッフが下げてロボットが洗い場へ運ぶ形の2通り）を入れて、配膳だけと配膳＋下げ膳の比較動画を作ります。人の動きを部品として切り出すのは、配膳ロボットの店がそろってからです。