==================================================================== 依頼 v13 の 依頼1 の確かめ：すれ違い 入／切 を調べた（まだ直していません） 2026-10-26 12:02 ==================================================================== 比べた回（③ fam_p1・スタッフ4・ロボット2台・種1・ServiceSim/cs:9・枠 100） 20261026_pass_on_cs9_fam_p1_r2_s1 すれ違い 入 20261026_pass_off_cs9_fam_p1_r2_s1 すれ違い 切 片付け RobotSpec.asset は「切で1回回す」が最後だったので passByEnabled: 0 に戻っていました。 中身が cs:9 と同じことを確かめて印だけ落としました。**保留 0・cs:9・check-in なし**です。 結論（先に） ・すれ違い自体は **狙いどおり働いています**。 向かい合って止まった 28回/1252秒 → **16回/841秒**、 「すれ違い中」だった秒 6084 → **2012 秒**。 ・店が悪くなった原因は **2つ**で、どちらも「すれ違いの作り」ではなく **「すれ違いの失敗の後始末」と「人の居場所を見ていないこと」**です。 ① 1.2 m の通路で2台が寄ると、**人の通る隙間が無くなる**（計算上 0.05 m） ② 体の間が 0.1 m より詰まると **2台とも止まって抜けられない**。 しかもその位置は、昔の作りなら絶対に起きない「鼻先 0.06 m」で、 今までの立て直し（譲る順番・回り込み）が効きません（545 秒の正体） ・直し方は 4 章に3つ出しました。**①+②の2つを直せば、入を夜の条件に入れて 種10個で比べる価値があります。** ==================================================================== 1. 入で悪くなった所と、その場所 ==================================================================== 数字（入 / 切） 入店待ち 6.11 / 2.05 分 席は空いているのに待った 4.87 / 0.75 分 客が帰ってから卓まで 13.64 / 5.02 分 ロボットが運んだ割合 0.80 / 0.81（同じ） 立ち往生 40 / 26 卓を空けた 1 / 0 スタッフのあきらめ 70 / 32 客のあきらめ 28 / 19 止まりの回数 1440 / 2687 止まりの合計 4517 / 4077 秒 うち「もう1台のロボット」1141 / 2381 → 止まりの **回数は半分に減った**のに、**合計の秒は増えた**。 短い止まりが消えて、長い行き詰まりに置き換わっています。 場所（人どうしの詰まり。people_jams.csv を場所で分けた） 場所 入 切 ---------------------------------------------------------------- 客席の下の横通路（z≦4.6） 546件 634秒 211件 249秒 細い通路 A03（x8.6–9.8） 486件 511秒 29件 30秒 ← 16倍 細い通路 A01（x1.2–2.4） 353件 371秒 0件 0秒 ← 0→353 細い通路 A02 6件 6秒 51件 54秒 受け渡し口そのもの (15.3,5.95) 15件 16秒 107件 266秒 ← 入で激減 合計 1483件1957秒 453件 737秒 ・**細い通路の中の詰まりが 35件→845件**。入では通路が詰まり場所に変わっています。 ・一方 **受け渡し口の詰まりは 107件→15件** に減っています （切では2台が受け渡し口で向かい合って固まる＝26/28件がここ。入はそれを解いた）。 ・人がロボットに近づきすぎた回数：330 / 243。**うち細い通路の中は 45 / 7（6.4倍）**。 ・細い通路の中でロボットが止まっていた秒：**425 / 70（6倍）**。 ★ 原因①：1.2 m の通路で2台が寄ると、人の隙間が無くなる 寄せ幅は RobotSpec.PassByShiftM = (直径 0.5 ＋ 間 0.1) ÷ 2 = **0.3 m**。 ③の通路は 3本ともちょうど 1.2 m（A01・A02・A03）。 通路の幅 1.20 m 2台の中心を ±0.3 m に置く 体は −0.55〜−0.05 と +0.05〜+0.55 m 壁は ±0.60 m → 空くのは 2台の間の 0.10 m と、壁際の **0.05 m ずつ** 人は半径 0.2 m（直径 0.4 m）なので、**どこにも入れません**。 すれ違っている数秒のあいだ、通路は人に対して完全にふさがります。 依頼文の条件「寄った位置で通れる幅が ロボットの幅×2 ＋ 間 に足りないとき」は 1.1 m なので、1.2 m の通路は **条件を満たしてしまい**、今の決まりに渡りません。 実物の動画は「台車の横」＝相手が止まっている物で、 **人が同じ通路を歩いてくる場面ではなかった**のだと思います。 コードでも裏が取れました。寄せ先の可否は CanShiftRight → NavMesh.SamplePosition(位置 + 右 × 0.3, 0.05, RobotFilter) PassByTarget → 同じく RobotFilter で寄せ先を確かめ、乗らなければ 0.67倍・0.33倍に減らす と **ロボット用の NavMesh だけ**を見ています。ロボット用の面は半径 0.25 m で 削ってあるので 1.2 m の通路でも ±0.35 m まで乗り、0.3 m の寄せは通ります。 **人が通れるかは1か所も見ていません。** ★ 原因②：体の間が 0.1 m より詰まると、2台とも抜けられない passes.csv のいちばん長い行（入） 545.1 秒 x=13.27 z=7.02 台1-2 いちばん近づいた間 **0.0642 m** 最遅 0 m/秒 → 「向かい合って止まった」 0.0642 m は **狙いの 0.1 m より詰まっています**。全停止を抑える条件が if (PassByMoving && blocked && reading.nearestIsRobot && … && reading.nearestDistance > spec.passBySeparationM) blocked = false; なので、間が 0.1 m 以下になった瞬間に **両方とも blocked に戻って速さ 0**。 1コマ 0.05 秒 × 0.3 m/秒 = 15 mm ずつ詰まるので、0.1 m をまたいで 行き過ぎることがあります（0.064 m はその行き過ぎ）。 そこから先、間を広げる動きが1つも無いので **両方が止まったまま**になります。 逃げ道（detourAfterSec 3 秒で今の決まりに渡す）は入っていて、働いています。 けれど渡された先の状態が **鼻先 0.064 m** です。 昔の作りなら前のセンサー（0.6 m）で止まるので、立て直しには 0.6 m の余地がありました。 0.064 m からでは、よける場所（2台の半径の和＋0.1 m 以上離れた所）も 回り込む道も見つからず、545 秒かかっています。 この行き詰まりの場所（x13.27 z7.02）は **スタッフが待つ列（x13.75・z6.8〜9.8）の真上**です。 受け渡し口と客席を行き来するスタッフの通り道をふさぐので、 スタッフのあきらめ（70件）と立ち往生（40件）に直接つながっています。 ==================================================================== 2. 「向かい合って止まった」は本当に向かい合っていたか ==================================================================== ご懸念のとおり、**切の方は「待っているだけ」を数えていました。** ただし待機場所ではなく **受け渡し口そのもの** です。 切：28件のうち **26件が受け渡し口 (15.3, 5.95) のそば** いちばん長い 559.0 秒は x=6.62 z=4.22（客席の下の横通路）で、 いちばん近づいた間が **−0.0412 m ＝ 体が重なっている** 2番目〜5番目はぜんぶ受け渡し口（x14.7〜15.6, z5.4〜5.8）で 168/164/82/51 秒 入：16件のうち 受け渡し口のそばは 9件。 いちばん長い 545 秒は x13.27 z7.02（スタッフ待機の列。1 章の②） ロボットの待機場所（x16.9/17.7/18.5, z6.05）のそばは **入 1件・切 0件**。 → **待機場所で並んでいるだけを数えてはいません。** ご懸念はここでは外れです。 問題は受け渡し口です。受け渡し口は **点が1つ (15.3, 5.95)** しかないので、 2台が同じ点へ向かうと必ず向かい合い、両方止まります。 これは「通路でふさぎ合っている」のとは別の現象で、 **数え方としては混ぜない方がよい**と思います（依頼 v8b の A で 「打ち切りで2台を同じ点に置くと重なる」を直したのと同じ場所です）。 いまの数え方（依頼 v13 の定義そのまま） 2台が 2.0 m 以内・向きの差 135度以上・2台とも 0.05 m/秒 以下が 1 秒以上 受け渡し口で荷積みを待っている2台は、この3つをぜんぶ満たします。 体が重なっている（間が負）行まで「向かい合って止まった」に入っているので、 **いまの 28件/1252秒（切）は、通路のふさぎ合いの数としては多すぎます。** ==================================================================== 3. まとめ（何が起きたか） ==================================================================== すれ違いは、受け渡し口の固まり（107件→15件）と 向かい合いの秒（1252→841）を **確かに減らしました**。 けれど代わりに ・1.2 m の通路を人がまったく通れない時間を作り（通路の詰まり 35→845件） ・失敗したときに鼻先 0.06 m という、立て直せない位置に2台を残しました（545秒） この2つで、スタッフが動けず（あきらめ 32→70）、 卓が回らず（回転 5.02→13.64分）、入店待ちが 2.05→6.11分 になりました。 つまり **考え方は合っていて、2か所の作りが足りない**状態です。 ==================================================================== 4. 直し方の案（3つ。①②は必須、③は選び） ==================================================================== ① 人の通る分を見てから寄る（原因①） いまは寄せ先をロボット用の NavMesh でしか見ていません。 **人用の NavMesh（半径 0.2 m）で、寄ったあとも人が通れるか**を見ます。 ・寄る前に、2台が寄った位置の間を人が通れるか（人用の面が残るか）を確かめる いちばん簡単なのは「地図の clear_mm（障害物までの実距離）」を使う形: 要る幅 = ロボット直径×2 ＋ 間 ＋ **人の直径 0.4 m** = 0.5×2 ＋ 0.1 ＋ 0.4 = **1.5 m** ③の通路は 1.2 m なので **細い通路では すれ違いをしない**ことになります （＝今までの決まり：料理を載せた方が先・3秒で回り込む） ・広い所（受け渡し口の前の廊下など）では今までどおり すれ違う 効き方：A01・A03 の詰まり（845件）がほぼ消え、 受け渡し口の固まりを減らす効果（107→15件）は残る見込み。 ただし ③の通路が3本とも 1.2 m なので、**すれ違いが働く場所は廊下だけ**になります。 「それでも入れる価値があるか」は種10個の比べで決める形です。 ★ 1.5 m の内訳（ロボット2台＋人1人）を RobotSpec の値にして出し入れできるようにします （passByNeedPersonM = 0.4 のような形。人の半径は PeopleSpec から取ってもよい） ② 詰まりすぎたら離れる（原因②） いま：間 ≤ 0.1 m で両方 blocked → 速さ 0 → そのまま 直し：次の3つを足します (a) 行き過ぎないように、狙う速さを間に応じて落とす （残りの間 ÷ 1コマ より速く進まない。15 mm の行き過ぎを無くす） (b) それでも 0.1 m を割ったら、**0.1 m になるまで少し下がる** （2台とも同じだけ下がるので、どちらが譲るかを決めなくてよい） (c) 3 秒で今の決まりに渡すとき、**渡す前に 0.6 m（前のセンサーの届く距離）まで 離れてから渡す**。昔の作りが立て直せる位置に戻してから渡す 効き方：545 秒の行き詰まりが無くなる見込み。 立ち往生 40 とスタッフのあきらめ 70 の多くはこれが元なので、 ①と合わせれば入店待ちは切に近づくはずです。 ③ 「向かい合って止まった」の数え方を分ける（2 章） 受け渡し口で荷積みを待っている2台を、通路のふさぎ合いと混ぜないようにします。 ・受け渡し口の rect（14.3,6.5〜16.3,6.9）とロボット待機場所の rect の中は、 別の欄に数える（face_stop_at_pass / face_stop_in_aisle のように分ける） ・体が重なっている（間が負）行は、別に「重なった」として数える （v8b で直した「同じ点に2台」の再発を見張る欄になります） これは **記録だけ**の直しなので、動きは変わりません。 ①②の効果を正しく読むために、先に入れておく方がよいと思います。 ※ 依頼 v13 の「数の定義」を変えることになるので、入れるかはエイイチの判断です。 ==================================================================== 5. 夜の条件に入れるときの形（提案） ==================================================================== ①②を入れた版を作り、夜の条件に すれ違い 入／切 × 種0〜9 × ③ロボット2台 ＝ 20 回 を足す形がよいと思います（⑦は通路 0.95 m なので、①を入れると すれ違いがまったく働きません。③2台でだけ比べれば足ります）。 見る数字 pass_count / すれ違えた・幅が足りず・向かい合って止まった の内訳 face_stop_count・face_stop_max_s（③で分けたあとの「通路のふさぎ合い」だけ） 入店待ち・席は空いているのに待った・回転・立ち往生・スタッフのあきらめ 細い通路の中の詰まり（people_jams を場所で分けた数。私の集計で出します） 判定は「切より良くなったか」で、種10個の中央値で見ます。 いまは何も直していません。①②③のどれを入れるか決めてください。 決まれば cs:10 として入れ、そのあと 依頼2（店の時計と倍率の画面）に進みます。 ==================================================================== 6. ①②③ を入れた（cs:10）と、夜の70回（cs:11）／2026-10-26 12:20 追記 ==================================================================== cs:10：すれ違いの直し①②③ ① 人が横を通れる幅があるときだけ寄る RobotSpec に passByNeedPersonM = 0.4（人の直径）を足し、 要る幅 PassByNeedWidthM = 体 0.5×2 ＋ 間 0.1 ＋ 人 0.4 = **1.5 m** 判定は CanShiftRight（ロボット用の NavMesh）をやめ、**地図の clear_mm** （そのマスから障害物までの実距離）で通路の幅そのものを見る形にした （CanPassByHere）。足元と 0.5 m・1.0 m 先の3点を見る。 地図が無いとき（SiteRoutes）は すれ違わない。 → ③の通路 1.2 m・⑦の通路 0.95 m は **どちらも 1.5 m に足りないので すれ違わず、今までの決まり（料理を載せた方が先・3秒で回り込む）に渡る**。 すれ違いが働くのは受け渡し口の前の廊下などの広い所だけになります。 ② 行き過ぎない・詰まったら離れてから渡す (a) すれ違い中の速さの上限に「残りの間 ÷ 2 ÷ 1コマ」を足した （2台で近づくので間は2台ぶんの速さで縮む）。0.1 m を行き過ぎない (b) 間が passBySeparationM を割ったら、3 秒を待たずに渡しに入る (c) 渡す前に passByBackOffM = **0.6 m**（前のセンサーが届く距離）まで 後ろへ下がる（passByBackSpeedMps 0.3 m/秒）。 下がれない所では下がらずに渡す。 FaceAndMove の頭で道を追うのだけを飛ばすので、 記録の後始末（止まりの開き・閉じ）は今までどおり動く ③ 向かい合いを場所で分けて数えた（数の定義の変更。エイイチ了承） summary.json に足した欄 face_stop_in_aisle_count / _max_s ← **通路のふさぎ合い。直しの効果はここで見る** face_stop_at_pass_count / _max_s 受け渡し口のそば（荷積みの順番待ち） face_stop_at_standby_count / _max_s 待機場所のそば face_stop_overlap_count そのうち体が重なっていた数 face_stop_count / face_stop_max_s（ぜんぶ合わせた数）は今までどおり残す。 場所は受け渡し口・待機場所の点から 1.2 m 以内で見分ける （ExperimentRunner が store.PassPoint と store.RobotStandbyPoints を渡す）。 ★「切」の動きが cs:9 と変わらないことの確かめ（ご指定の分） 行の増減（cs:9 → cs:10） RobotSpec.cs +25 −0 RobotPassBy.cs +92 −2 ServingRobotController.cs +128 −6 ExperimentRunner.cs +12 −0 TripLogger.cs +23 −0 **既存の行を置き換えたのは 8 行だけ**で、中身は次のとおりです。 ServingRobotController（6行）… ぜんぶ UpdatePassBy の中。 ・3秒の判定に tooClose を足した行 ・CanShiftRight(…) → CanPassByHere(…) の行 ・CanShiftRight の宣言と中身（CanPassByHere に置き換えて消えた） RobotPassBy（2行）… コメント1行と、FaceStopMaxS を入れる行 （置き換え後も同じように FaceStopMaxS を入れ、場所ごとの最長を足しただけ） 新しく足した動きは、ぜんぶ入のときだけ通る枝の中にあります。 速さの上限 → if (PassByMoving && _passByOther != null && dt > 0f) 離れ → if (_passByBackingOff) { BackOffStep(dt); return; } そして UpdatePassBy は入口で if (spec == null || !spec.passByEnabled || …) { _passByOther = null; _passByHasLane = false; _passByStallS = 0f; _passByGaveUp = false; _passByBackingOff = false; ← 2026-10-26 に足した return; } と戻るので、切のときは ・PassByMoving は false（_passByOther が null） ・_passByBackingOff は false になり、**新しい枝に1つも入りません**。 _passByBackingOff を true にしうる代入は **1か所だけ**（UpdatePassBy の 渡しの中）であることも数えて確かめました。 ③ は記録だけです。PassByWatch は自分の記録（Live と数）にしか書かず、 **ロボットには1つも書き込みません**（正規表現で当たって 0 件）。 なので切の **動き** は cs:9 と同じで、**記録の欄が増えるだけ**です。 確かめは 38 項目ぜんぶ OK、組み立ては 55 本・エラー 0。 cs:11：夜の70回を並べられるようにした make_queue.py --pass-by（ふだんの回。既定 off＝基準データ cs:7 と同じ動き） --pass-by-extra（その条件だけ、同じ種で入の回も足す） python3 tools/make_queue.py --out queue.json \ --pass-by-extra fam_p1_s4_r2_a42 → 条件 6 / 種 0〜9 / 合わせて **70 回**（切 60 回・入 10 回） 入は ③2台（fam_p1_s4_r2_a42）の種0〜9 の10回だけ queue.json の各回に pass_by: on / off が入ります。 night_runner.py ・回ごとに **-ssPassBy on|off** を実行ファイルに渡す （依頼 v12 の 2 章の引数に1つ足す形。実行ファイル側は v12 で受けます） ・入の回だけフォルダ名に **_passon** を付ける 20261027_night_cs10_fam_p1_r2_s0 （切） 20261027_night_cs10_fam_p1_r2_s0_passon （入） 切の回の名前は付ける前と同じなので、基準データと並べられます （付けないと同じ条件・同じ種で名前がぶつかります） ==================================================================== 7. 既知として残すもの（今は直しません。エイイチの決定） ==================================================================== 受け渡し口の点が1つしかないため、「切」でも2台が向かい合う ・受け渡し口は点が1つ（15.3, 5.95）しかなく、2台が同じ点へ向かうと 必ず向かい合って両方止まります。 2026-10-26 の確かめでは、切の向かい合い 28 件のうち **26 件がここ**でした。 ・いちばん長い 559 秒の回（x6.62 z4.22）は、いちばん近づいた間が **−0.0412 m ＝ 体が重なっていました**。 依頼 v8b の A で直した「打ち切りで2台を同じ点に置くと重なる」と同じ場所です。 ・直す案（やっていません）：受け渡し口に並ぶ点を2つ以上作る、 または荷積みを1台ずつにする（レジの payAtRegisterByOne と同じ形）。 ・いまは ③ の分け方で **face_stop_at_pass_count** として別に数えるので、 通路のふさぎ合い（face_stop_in_aisle_count）と混ざりません。 夜の70回でこの数が大きいままなら、次の版で扱います。 次（このあと） ・依頼2（店の時計と倍率の画面。SimHud） ・そのあと v12 の Unity の中の部分（画面なしの実行ファイル・-ssPassBy の受け）