⑦で 21 卓が「経路がつながらない」になった件。原因しらべと、コストをやめて手順に直した分です。 Unity は押していません（Editor が開いたままのため）。 ──────────────────────────────────────────────────────── 1. 原因しらべ（私の側でできたところまで） ──────────────────────────────────────────────────────── (1) 区画の箱の位置は、通路の区画どおりでした　← 原因ではない AddNarrowAisleAreas が作る箱を、JSON の数字から計算して突き合わせました。 A01 JSON rect [1.2, 4.6, 2.0, 12.2] → 箱 x 1.20..2.00 / z 4.60..12.20（中心 y=0.5・高さ 2.0） A02 JSON rect [4.5, 4.8, 5.3, 14.05] → 箱 x 4.50..5.30 / z 4.80..14.05 A03 JSON rect [7.8, 4.8, 8.6, 14.05] → 箱 x 7.80..8.60 / z 4.80..14.05 3 本とも、JSON の通路の区画と小数点以下までぴったりです（ずれ 0）。 (2) 判定の厳しさは、段階1 と同じでした　← 原因ではない 段階1 で使っていた NavMeshBaker.PathLength も、PathComplete でなければ -1 を返す作りです （「経路が途中まで」もエラー扱い）。段階1 は 42/42 が ok だったので、 判定が厳しくなったのではなく、**道探しの結果そのものが変わっています**。 変えたのは「区画 4 を焼いたこと」と「コスト 20」の 2 つだけです。 (3) いちばん疑わしいのは、コストの入れ方です（仮説。まだ確かめていません） エイイチの見立て（道探しが上限に当たって PathPartial）も考えましたが、 落ちた卓の並びが合いません。 落ちた: A02 の 9 卓・A03 の 9 卓・通路の外の T27〜T30（受け渡し口にいちばん近い側） 通った: A01 の 8 卓（受け渡し口からいちばん遠い） 探索の上限なら「遠いものから落ちる」はずで、逆になっています。 また ⑦ のロボット用の面は三角形 148 枚しかないので、上限には当たりにくいはずです。 疑っているのは NavMeshQueryFilter.SetAreaCost の使い方です。 この構造体は agentTypeID を入れた時点で全区画のコストが入りますが、 そこへ SetAreaCost を混ぜると、ほかの区画のコストが思ったとおりにならないことがあります （0 のまま、など）。そうなると A* の見積もり（直線距離）と実際のコストが合わなくなり、 近い行き先でも途中で打ち切られて PathPartial になります。 T27〜T30（狭い通路をまったく通らない卓）まで落ちたのは、これで説明が付きます。 **確かめは、次の実行で自動的に出ます。** CSV に 2 列足しました。 wide_status … 狭い通路を外して探したときの結果 all_status … 狭い通路も入れて、**コストを使わずに**探したときの結果 all_status が全卓 ok なら、「コストを使わなければ段階1 と同じに戻る」＝コストが原因、と確定します。 ──────────────────────────────────────────────────────── 2. 直した内容（コストをやめて、サイトの決まりをそのまま手順に） ──────────────────────────────────────────────────────── RobotSpec narrowAisleCost（20）を削除 → avoidNarrowAisles（true/false）に ServingRobotController ・SetAreaCost をやめた（agent の区画コストは触らない） ・SetDestination を 2 段にした ① 狭い通路の区画を外して探す（RobotFilterWithoutNarrow） → 完全につながればそれを使って終わり ② つながらない行き先だけ、狭い通路も入れて（コストはそのまま 1） いちばん短い道を使う どちらも引けないときは、今までどおり「途中までの道」で進みます （あきらめる道の仕組みは変えていません） ・UsedNarrowAisle（その道が ② だったか）を記録用に出せるようにした ServiceSimJsonStore 確かめも **まったく同じ 2 段** にした。via_narrow は ② のときだけ 1 agent.areaMask は変えていません。狭い通路の中に立っているときに足もとの面を外すと、 その場で動けなくなるためです（道を引くときだけ外します）。 あわせて、走るときと確かめで「止まる位置を面へ寄せる半径」がずれていたのをそろえました。 走行 spec.Radius * 4 = 1.0 m（前からこの値） 確かめ 0.5 m（段階1 のまま）→ **1.0 m にそろえた** 寄せた距離は CSV の snap_m に出します（0.3 m 以上動いた卓は報告にも並べます）。 寄せる先は「いちばん近い面の点」なので、半径を広げても測る場所は変わりません。 届くかどうかの判定だけが、走行と同じになります。 ──────────────────────────────────────────────────────── 3. こうなるはず（JSON の寸法から計算した予測） ──────────────────────────────────────────────────────── 止まる位置から、障害物（卓・ベンチ・椅子・壁・通れない部屋）に 0.25 m 以上空けて 「狭い通路の区画の外」に出られるかを、0.02 m 刻みで調べました。 via_narrow = 0（狭い通路を使わずに届く）: **24 卓** via_narrow = 1（狭い通路でしか届かない）: **18 卓** A01: T02 T03 T04 T06 T07 T08 A02: T10 T11 T12 T14 T15 T16 A03: T19 T20 T21 T24 T25 T26 **T17 と T22 は via_narrow = 0 の側に入ります**（ご依頼の期待どおり）。 T17 止まる位置 [4.812, 13.888] … A02 の北の口まで 0.16 m。口の外へ 0.18 m で出られる T22 止まる位置 [8.588, 12.688] … A03 の東のふちまで 0.012 m。 T22 の東（z 12.2 以上）は卓が無く空き床なので、0.02 m 外へ出れば広い床 サイトの「narrow（ロボットが行けない）24 卓」との差は 6 卓（T01・T05・T09・T13・T18・T23）。 この 6 卓は止まる位置が通路の口から 0.16〜0.38 m しかなく、Unity では **口の外に立ったまま届く**ので、狭い通路に入らずに済みます。 サイトは「通路の真ん中に 50 cm の余裕がある道のり」で見ているので、ここは食い違います。 どちらに寄せるかは段階2 の前に決めたいです（Unity 側では埋めていません）。 ──────────────────────────────────────────────────────── 4. お願い ──────────────────────────────────────────────────────── ServiceSim/JSON Store/⑦ p5_crammed を建てて確かめる を押して、{日付}_p5_crammed_table_dist.csv と _json_check.txt を送ってください。見たいのは 1. all_status が全卓 ok か（＝コストが原因だったかの確定） 2. via_narrow が 1 になった卓が、上の 18 卓と合っているか 3. T17・T22 が via_narrow = 0 で、道のりが JSON の dist（17.05 / 12.0 m）に近いか 4. snap_m が大きい卓（0.3 m 以上）がどれか ③ も一度押していただけると、via_narrow が全卓 0 のままか（1.2 m なので区画を付けていない）が 確かめられます。 触ったファイル Robot/RobotSpec.cs narrowAisleCost → avoidNarrowAisles Robot/ServingRobotController.cs SetAreaCost をやめ、SetDestination を 2 段に（SolvePath） Editor/ServiceSimJsonStore.cs 確かめも 2 段に。wide_status / all_status / snap_m を追加 NavMeshBaker（区画 4 を焼くところ）と JsonStoreLayout（normal_width で印を付けるところ）は そのままです。区画を焼くこと自体は、2 段の手順でもそのまま使います。