# 配膳ロボット：通路で何が起きるかを Unity で測る（設計 v0）

作成：2026-10-20
対象：サービスロボット導入シミュレーション（配膳ロボット）
実装：Claude Code（Unity）／設計・結果の読み込み・試算への反映：Claude

## 0. 何について正か（2026-10-22 エイイチと決めた）

「サイトの試算が正で、Unity はそれに合わせる」を、何について正かで分ける。サイトの数字の一部は Unity で測るための仮の値なので、全部をサイトに合わせると話が逆になるため。

| 何について | 正 | 扱い |
|---|---|---|
| 店の形（卓・壁・部屋・止まる位置） | サイト | p2m-site の `public/sim/layouts/` の JSON を読んで建てる。Unity で形を作らない |
| 条件（スタッフ・来客・ロボットの台数） | サイト | 図面のある店の値（卓の数に合わせて増減した値）をそのまま使う |
| 店の回し方の決まりと時間（案内45秒など）、数字の定義（入店待ち・店が回らない） | サイト | 比べる物差しをそろえる |
| 通路で起きること（実際の速さ・止まる回数と長さ・立ち往生） | Unity が測る | 測った値は、サイトを先に直して入れる（`robot_speed`・`pause_rate`・`pause_s`・`stuck_rate`） |
| Unity が建てるための細かい形（通路の区画・椅子・座る位置・並ぶ点など） | サイトの店の形から、決まった規則で作る | 作り方の規則はサイト側（`tools/sim_layouts/`）に置き、JSON に書き出す。サイトの試算は使わない |
| Unity にしかないもの（組の人数・2人席・ドリンクバー・トイレ・椅子を引くなど） | Unity | 「Unity だけの値」と書いて残す。サイトとは比べない。あとで観察の数字に置き換える |

距離の測り方（サイトは通路の真ん中に50cmの余裕を取った道のり、Unity は半径25cmで家具に寄って走る）と、Unity にしかないものがあるので、Unity とサイトの数字は完全には合わない。合っているかは、向きと大きさで見る。

## 0.5 ゴールと進め方（2026-10-22 エイイチと決めた）

Unity をサイトの試算に完全に合わせることは目指さない。ズレを見つけるたびに直していると終わりがなく、何が達成できたのかが分からなくなるため。Unity は Unity の作りのまま回し切り、サイトとのズレは「直す対象」ではなく「調べる対象（結果）」として扱う。0章の表は、段階Aで店の形と条件をそろえるところまで使い、仕事の決まりや数字の数え方の違いは直さずに段階Cの一覧に入れる。

| 段階 | やること | 終わり |
|---|---|---|
| A. 店を作る | 図面（JSON）のある店を Unity で建てる。店の形と条件（1時間の組数・スタッフ数・ロボット台数）はサイトと同じ。仕事の決まりや数え方は Unity のままでよく、違いは一覧に書くだけ | どの店・どの条件でも最後まで回り切り、逃がし弁（あきらめた・移した・卓を空けた）がほぼ0 |
| B. 回して台帳にまとめる | 1回回すごとに台帳に1行足す（店・条件・乱数の種・結果の数字・ロボットの4つの値・逃がし弁の回数）。台帳の置き場所は先に MASTER の保存先の表に足す | 決めた条件と回数が全部台帳に入る |
| C. ズレを調べる | 同じ店・同じ条件でサイトと Unity の数字を並べ、ズレごとに理由を分ける（1 数え方の違い／2 サイトにない動き＝すれ違い・混雑／3 Unity の作りの問題）。何を直すか（記録する項目・店の作り・サイトの計算）を決める | ズレの一覧と、それぞれの理由・対処が書ける。対処を実際に入れるのは次の版 |

- 店の順番：③⑦で A〜C を一度通してから、ほかの店（②④⑤⑥）を足す（エイイチが (ア) を選んだ）。③⑦で一度ズレの出方を見れば、ほかの店で何を記録すべきかが分かるため
- 問題が出たときに直すのは1回だけ。それでも直らなければ、制約として書いて先へ進む
- 段階Aの区切り（2026-10-23 エイイチと決めた）：③で、助けに行く仕事（cs:117）・台どうしの譲り合い（cs:123）を直したあと、受け渡し口の前の通り方を最後の1回として直す。これで時間切れの往復が大半のままなら、段階Aは③⑦ともここで止め、段階Bへ進む。直す点（受け渡し口まわり・下の通路 z4 のすれ違いなど）は、段階B・Cを進めながら同時に考える
- ロボットの待機場所は受け渡し口の右のまま（2026-10-23 エイイチ：左は客とスタッフの行き来が多く、待機は邪魔になる）。サイトの店の形は変えない
- 次に進みながら考える直す点（2026-10-23 エイイチの指摘から。まだ入れていない）：
  1. レジの置き方。いまはレジに並ぶ点（z 3.8・4.3）が客席の下の通路のまん中にあり、「人が立ち止まっていた」止まりの1位になっている。決まり（エイイチ）：レジの向きは店によって違ってよいが、レジの台・店員の立つ所・会計で並ぶ所で通路を狭くしない。店の形なので、直すときはサイトの店の形の決まり（6店すべて）が先
     → 2026-10-23 サイト側を直して公開した（generation f282eaa6cb71）。③⑥⑦はレジを縦向きにし、客は入口の側に立って入口へ並ぶ。会計に立つ点・並ぶ点はロボットの道から0.75m以上。会計の列（幅1.0m・長さ2.15m）はロボットの道にしない（人は通れる。JSON の robot_keepout）。②はレジは記憶どおりで、ロボットは列の前を横切らずレジ横を回る。6店とも卓までの距離は変わらず、試算は計算し直していない（params は版の番号だけ更新）。Unity は③⑦を建て直す
  2. 同じ卓・同じ通路のまわりに2台のロボットを集めない。いまは2台が同じ通路の入口で鉢合わせて詰まる。料理を割り当てるとき、ほかの台が向かっている・入っている通路の卓は後に回すなど、割り当ての段階で避ける（Unity だけの決まりとして入れ、段階Cの違いの一覧に書く）
- キッチンのモニター（2026-10-23 エイイチと決めた）：キッチンの屋根に、ロボット・スタッフのいまの仕事と止まりの理由、店の様子を出す板を置く。測る回でも出す（頭の上の字幕は重いので測る回では切るまま）。言葉と数字は記録と同じものだけ。倍速が落ちるなど問題があれば切れるようにする
- 人のよけ方の切り替え（2026-10-23 エイイチと決めた）：受け渡し口のまわりにロボットと人が溜まる対策として、「店員優先の版」を切り替えで入れる。店員は必ず道を空け、ロボットが通るまで待つ。客は長くて5秒止まり、回り道か横を詰めて通る。既定は今のよけ方。どちらで回したかを台帳に残し、両方回して比べる
- 段階Aの終わり（2026-10-23 エイイチと決めた）：店員優先のよけ方（切り替え）とキッチンのモニターを最後の直しにする。結果がよくても悪くても、ここで Unity の作りを固定し、版の名前と Check-in の番号をここに書く。直すたびに詰まる場所が移る（cs:125 で A01 の鉢合わせ79→0・レジのまわり112→31、受け渡し口のまわり50→81）ため。このあと見つかる詰まりは直さず、段階Cのズレの一覧に書き、次の版でまとめて直す
- 固定した版（2026-10-23）：**cs:133**。シミュレーションの動きは cs:126（店員優先のよけ方の切り替え）から変えていない。cs:127〜133 は見た目と表示だけ（回し始めの行に設定を出す・キッチンのモニターを Scene ビューに貼り付けるパネルにした。掴んで動かせ、測る回でも出す。書き出す画には写らない）。PeopleSpec.staffFirstYield の既定は off。③の比べ：1311（今のよけ方）・1536（店員優先）
- ⑦の細い通路を0.8m→0.95mに（2026-10-23 エイイチと決めた）：Unity でロボットがほとんど動けず、右端の列の横に余りがあったので、島を右へずらした。卓・席は同じ、1.0m未満なので細い通路の24卓は狭い道で入るまま。サイトの試算を v2.6 に（⑦だけ回し直し）。店の形の版は 82023936eb99。Unity の動きは cs:133 のまま、JSON を読み直して⑦を建て直す
- 保留中の変更の整理（2026-10-23）：cs:136。動きは cs:135 と同じ（.git を Unity の管理の外へ・回した跡の値を戻す・場面の配線を入れる）。持ち越し：NavMesh の種類が開き直すたびに増える（navmesh-agenttype-leak）／回すと StoreLayout_Family の2値が書き換わる
- 料理の割り当てをロボット優先に（2026-10-23 エイイチと決めた）：料理はまずロボットを待つ。2分（robot_first_wait_s=120）待っても来なければ、先に空いた方が運ぶ。サイトの試算を v2.7 にして全条件を回し直した（ロボットが運ぶ料理 69%→85%、店が回らない 3,006→2,955）。Unity も同じ決まりにそろえ、それを新しい固定版にする
- 新しい固定版（2026-10-23）：**cs:137**。料理の割り当てをロボット優先に（params v2.7 の robot_first_wait_s=120 を読む。robotFirstWaitSec=0 で前の回し方に戻せる）。dishes.csv を皿ごとの記録に（前の内容は requeues.csv）。summary に late_staff_dishes・late_staff_share。ほかの動きは cs:136 と同じ
- 新しい固定版（2026-10-23）：**cs:138**。譲る順番 ロボット＞スタッフ＞客（RobotSpec の1か所。yieldOrderEnabled で前の作りに戻せる）。譲る側は後ろへ下がらず、相手の道から横へ0.6m以上どいて待つ。staffFirstYield は既定 on に変更（エイイチの指示）。原因：広い所（細い通路の外）では譲る仕組みが動いておらず、受け渡し口と客席をつなぐ角で向かい合ったまま止まっていた。記録は yields.csv、summary に corner_stop_time_share など
- 新しい固定版（2026-10-23）：**cs:139**。スタッフが譲るのは、動いているロボットの進む先（routes の線の2.0m分）から横0.6m＋体の半径以内にいて、ロボットが近づいているときだけ（cs:138 は1.5m以内なら何でも譲り、スタッフの時間の約4割が譲りになっていた。2227 の回）
- 段階Bの回し方（2026-10-23 決めた）：③⑦ × ロボット0・1・2台 × 乱数の種3つ＝18回（スタッフ4人・1時間42組）。決まりは固定版のまま（よけ方の2通りは回さない。譲る順番はエイイチがロボット＞スタッフ＞客と決めたため）。台帳は service_sim/unity/unity_ledger_v1.csv（1回1行・追記のみ）。依頼は claude_code_request_v7_stageB.md
- 固定したあと：⑦を1回回して回り切るかだけ確かめる（回り切らなくても制約として書いて進む）→ 段階B（台帳の置き場所を先に MASTER の保存先の表に足す。③⑦ × 6条件〈ロボット0・1・2台 × 店員優先あり・なし〉× 乱数の種3つ＝36回・約8時間。夜にまとめて回す）→ 段階C → ④⑤⑥ → ②（座る位置を作ってから）
- 段階Cの候補として、いま分かっている違い：「席はあるのに待った時間」の数え方（2026-10-22 の cs:116 でサイトと同じ数え方に変えた）／片付けの時間（turn_mean。定義は同じ）／Unity にしかないもの（組の人数・2人席・ドリンクバー・トイレ・椅子を引く・歩く客の数）

## 1. なぜ Unity でやるのか

LOG351 の試算（SimPy。待ち時間・順番・数だけを計算する道具）では、ロボットが通路で止まる・動けなくなるところを、仮の数字で入れている。店の間取りがないと、ここは計算できないため。

仮の数字を1つずつ振って確かめた（simulation/sensitivity/README.md）。分かったのは次のこと。

- ロボットが何回止まるかは、ほとんど結果を変えない。止まる割合を0%から90%にしても、料理が届くまでの時間は標準ファミレスで38秒から45秒にしか変わらない
- 結果を変えるのは3つ。1回止まったときに何秒止まっているか、人が動かしに行かないと動けなくなる割合、人をよけながら実際に何 m/秒で走れるか
- この3つが悪い側に振れると、ロボットを入れた利点がなくなる。標準ファミレスでは、ロボットなしで58秒かかる料理が、ロボット2台で40秒になる。それが、動けなくなる割合30%で58秒、止まる長さ30〜60秒で54秒、速さ0.3 m/秒で64秒になる

なので Unity では、止まる回数ではなく、この3つを通路の幅と混み具合を変えて測る。

## 2. 何を測り、試算のどこに戻すか

| Unity で測るもの | 定義 | 戻す先（haizen_sim.py の COMMON） |
|---|---|---|
| 実際に走れる速さ | 走った距離 ÷（往復にかかった時間 − 止まっていた時間） | `robot_speed` |
| 止まっていた長さ | 1回止まってから、自分で動き出すまでの秒数の分布 | `pause_s` |
| 動けなくなった割合 | 1往復のうち、60秒以上動けなかった往復の割合（人が動かしに行く扱い） | `stuck_rate` |
| 止まった割合（参考） | 1往復のうち、1回以上止まった往復の割合 | `pause_rate` |
| 急に止まったときの減速の強さ（記録だけ） | 止まる直前の減速（m/秒²）の最大値 | まだ戻さない。こぼれを扱う回の手がかりとして残す |

戻したあと、LOG351 の表（スタッフを1人減らしてロボット2台にしたとき）を回し直し、仮の数字の版と並べる。

## 3. 作る店

（2026-10-20 改訂。最初の版は同じ卓を格子に並べ、奥が行き止まりの通路が3本ある形で、実在のファミレスに近くなかった。実際のファミレスの図面を参考に、どの場所がどこに並ぶかと寸法の目安だけを借りて作り直した。図面そのものは写さず、記事・動画にも載せない）

- 店は「部品をどこに置くかの一覧」（StoreLayout の .asset）から組み立てる。新しい形は .asset を1つ足して作る。最初の格子の店は StoreLayout_Grid として比べる用に残す
- 最初の店（StoreLayout_Family）：左に客席、右に厨房。厨房と客席のさかいに、奥から「料理の受け渡し口」「パントリー（水・おしぼり・カトラリー）」「下げ膳の返却口」が並ぶ。その前を太い通路（幅1.6 m）が南北に通る。下の壁に入口（風除室つき）、入口を入ったところに待合とレジ。トイレは入口の右、事務所・更衣室は厨房の下
- 席は4人掛けで35卓：左の壁ぞいのブース8、上の壁ぞいの卓6、下の壁ぞいの卓3、中央の島18（上と下に3列×3卓ずつ）。島のまわりは回れて、行き止まりがない
- ロボットは料理の受け渡し口の前から出て、太い通路を通って卓へ行く。太い通路には、パントリーに立ち寄るスタッフ・返却口へ向かうスタッフ・待合やレジ・トイレへ向かう客がいて、人とロボットが交わる場所がここに集まる
- 背中合わせの席のあいだの仕切りは、ボックス席の背もたれの高さ 1.1 m
- ドリンクバー（2026-10-21 追記・仮）：壁ぞいのカウンター 長さ 3.6 m（機械4台分）×奥行き 0.7 m。前に立つ場所は奥行き 1.5 m で、同時に4人まで。5人目からはカウンターの端に3人まで並び、それも埋まっていたら席に戻る。最初の版は 1 m ほどの台1つで、ファミレスのドリンクバーとしては狭すぎた。今の外寸では、カウンターと待合の両方が下の壁ぞいに入らなかったので、店を広げて置く（35卓は保つ。前に立つ場所と並ぶ点が通路と重なるなら、ドリンクバーのところをくぼみにする）
- レジ（2026-10-21 追記）：カウンターをはさんで客の側とスタッフの側を分ける。客と反対の側に、太い通路からだけ入れるスタッフの場所（奥行き 0.8 m・幅 1.2 m・仮）を作り、会計のスタッフはそこに立つ。最初の版はスタッフが客と同じ側から立っていて、待合・入口・退店する客の流れに会計のスタッフが混ざり、レジのまわりに10人以上が固まった。待合・レジ・入口を 4.8 m² の帯に詰めたことも効いていた
- 壁沿いの卓（2026-10-21 追記）：4人席（壁側ベンチ2＋通路側の椅子2）をやめ、2人席（壁側ベンチ1＋通路側の椅子1）にした。卓と卓のあいだを仕切りでふさいでいたため、壁側の奥の席に人が入れなかった。卓のあいだに人が入れるすき間を空け、壁の長さに入るだけ並べる。全部の席に通路から人が入れることを Build Store で確かめる
- 壁ぞいのボックス席（2026-10-21 追記）：ベンチの奥行き 0.55 m（座面 0.45 m＋背もたれ 0.1 m）、ブース1つの幅 1.85 m。最初の版は座面が実質 0.35 m・ブースの幅 1.65 m で、4人掛けとしては狭かった
- 細い通路の幅を3段階で切り替える：0.8 m／1.0 m／1.2 m。BellaBot の通過幅は 70 cm 以上（ソフトバンクロボティクス）／約 80 cm（シャープ）、客席間の通路の目安は 60 cm 以上・スタッフがよく通る場所は 80 cm 以上（法令ではない一般的な目安）
- 細かい寸法と人の動きは unity/claude_code_request_v1_store.md
- あとで足す形：L字型、カウンター・大人数席あり

## 4. ロボット

- 実在の機種の形は使わない。直径0.5 m、高さ1.2 m の円柱に近い棚型（仮）
- 最高速度 0.6 m/秒（仮）
- 止まる決まり（仮。実機の多くは前方の距離センサーで人を見て止まる。その動きを単純にしたもの）
  - 進む方向の前0.6 m 以内に人か物があれば止まる
  - 前が1秒空いたら動き出す
  - 止まって10秒たったら、別の道を探す
  - 60秒動けなかったら「動けなくなった」と記録し、その往復を終える
- Unity の NavMeshAgent（地図の上で道を探して進む部品）の、自動でよける機能はロボットには使わない。実機のよけ方と違うため。道探しだけ使い、止まる・動き出すは上の決まりで書く

## 5. 人

（2026-10-21 改訂。最初の版は「歩く客 1／4／8人がずっと行き来する」作りで、通路を歩く客が実際よりずっと多く、卓に戻った客が通路に立つ・人どうしが押し合って動けなくなることも起きていた。どれもロボットが止まる回数と長さを大きく見せるので、客に「入ってから出るまで」の流れを持たせた）

- 客は1組ごとに：入店 → 席が空くまで待合 → スタッフの案内で卓へ → 座る → 注文・食事（ときどきドリンクバー・トイレへ行き、戻って座る）→ 1人がレジ → 全員で出る → スタッフが片付けて卓が空く
- 来客のペース・食事の時間・料理の数・ロボットとスタッフの運び分けは、試算（haizen_sim.py の family）と同じにする。ロボットは料理を頼んだ卓にだけ行く
- 試算にない値は仮：組の人数（1人20%・2人35%・3人20%・4人25%）、ドリンクバー（1人平均1.5回・20秒）、トイレ（1組0.3回・180秒）。店で観察するときに、観察シートで数える項目に足す
- スタッフ2人は、そのとき起きている仕事（案内・料理・呼び出し・レジ・片付け）を試算と同じ優先で選ぶ。手が空いたらパントリーの前で待つ
- 座らせ方（2026-10-21 追記）：1〜2人の組は空いている2人席を優先し、なければ4人席。3〜4人の組は4人席だけ。試算（LOG351）には卓の大きさの区別がないので、入店待ちが試算とずれる要因の1つになる
- 人はロボットをよける（2026-10-21 追記）：細い通路の中にロボットがいたら入らずに入口で待つか、5 m 以内の回り道を通る。通路の中で向かい合ったら人のほうが交差点や卓のすき間へ下がる。広い通路ではロボットから 0.3 m 以上空けてすれ違う。これを守らない不注意な人を 1 回の行動につき 2%（仮）混ぜる。最初の版では人がロボットを気にせず歩き、細い通路でロボットを両側から押す場面が出た。実際の店で人は自分からロボットに当たりに行かない（わざとか子どもくらい）
- 人どうしのすれ違い：前に進めないと体を横に向け（半径 0.20→0.12 m）、それでも抜けられなければ客のほうが下がる
- 細かい値は unity/claude_code_request_v2_guests.md

## 6. 回す条件

（2026-10-21 改訂）

- 通路の幅 3 × 来客のペース 3（空いている 25・普通 35・混雑 45 組/時。試算と同じ）× ロボットの台数（1台・2台）= 18条件
- 1回の実行は、店の中の時間で120分（試算と同じピークの長さ）。卓の80%（仮）が食事中の状態から始め、最初の15分は数えない
- 乱数の種の数は、段階2で分かる1回の実行時間を見て決める
- 時間を速めても結果が変わらないことを、段階2で確かめる（等倍・10倍・1コマ固定の3通り）

## 7. 出力

保存先：KIOXIA の `r2r2r-data/service_sim/unity/{YYYYMMDD}_{run_name}/`（MASTER の保存先テーブルに行を足してから使う）

- `trips.csv`：1往復1行。列は condition_id, aisle_width_m, crowd, robots, seed, trip_id, distance_m, total_s, stopped_s, n_stops, stop_durations_s（; 区切り）, stuck（0/1）, max_decel_mps2, min_clearance_m, met_robot（0/1）
- `conditions.json`：18条件の中身と、上の仮の値すべて
- `summary.json`：条件ごとの、実際に走れる速さ・止まっていた長さ（中央値と90%点）・動けなくなった割合・止まった割合
- `stops.csv`：止まった1回が1行（時刻・位置・通路・原因・秒数・どう解けたか・左右の空き）。原因の分け方は観察シート（LOG353）の選択肢にそろえる（2026-10-21 追記）
- `scripts/`：この回の Unity の C# スクリプトのコピー（データと対のコード）

## 8. 映像にする場面（記事・動画用）

Unity Recorder で、各10〜20秒。

1. 幅0.8 m の通路で、料理を持ったスタッフとロボットが向かい合う。ロボットが止まって待つ
2. 幅0.8 m の通路で、ロボット2台が向かい合う。どちらも下がれず、60秒で「動けなくなった」になる
3. 客が椅子を引いて通路をふさぐ。ロボットが別の道を探す

## 8.5 ファイルの分け方（店・ロボット・人を別々に直せるようにする）

店・ロボット・人・実験の回し方を、別々のフォルダとファイルに分ける。数字（通路の幅、止まる距離、歩く速さ、人数など）はコードに書かず、それぞれの設定ファイル（Unity の ScriptableObject。インスペクターで値を変えられるファイル）に置く。

```
Assets/ServiceSim/
├── Scenes/ServiceSim_Family.unity   … 店・ロボット・人・実験を置くだけ。中身は持たない
├── Store/                           … 店
│   ├── StoreLayout_Family.asset     … 卓の数と並び、太い通路と細い通路の幅、厨房の位置
│   ├── StoreBuilder.cs              … StoreLayout から床・壁・卓・椅子を並べる
│   └── Prefabs/（Table_Booth4, Chair, KitchenPass, Wall）
├── Robot/                           … ロボット
│   ├── RobotSpec.asset              … 大きさ、最高速度、止まる距離、動き出すまでの秒数、別の道を探すまでの秒数、動けなくなったとみなす秒数
│   ├── ServingRobot.prefab
│   ├── ServingRobotController.cs    … 往復・止まる・動き出す・別の道を探す
│   └── FrontSensor.cs               … 前に人や物があるかを見る
├── People/                          … 人
│   ├── PeopleSpec.asset             … 混み具合ごとの人数、歩く速さ、椅子を引く頻度とはみ出す長さ
│   ├── Staff.prefab / Guest.prefab / SeatedGuest.prefab
│   └── StaffAgent.cs / GuestAgent.cs / SeatedGuest.cs
├── Experiment/                      … 実験の回し方と記録
│   ├── ExperimentPlan.asset         … 回す条件（通路の幅・混み具合・台数）、乱数の種、往復の回数、出力先
│   ├── ExperimentRunner.cs          … 条件を順に回す
│   └── TripLogger.cs                … trips.csv・conditions.json・summary.json を書く
└── Recording/                       … 映像にする3場面のカメラ位置と、場面ごとの再現の設定
```

決まり
- 1つのスクリプトは、店・ロボット・人・実験のどれか1つだけを扱う。ロボットのスクリプトの中で人を動かさない、などの混ぜ方をしない
- 数字を直すときは設定ファイル（.asset）だけを変える。コードは触らない
- 店の形を直すときは StoreLayout だけを変える。ロボットと人のファイルは触らない
- 設定ファイルの値は、実行のたびに conditions.json にそのまま書き出す（どの値で回した結果かを後から分かるように）

見た目
- 計測に使う店とロボットと人は、箱と円柱だけで作る（形の作り込みは結果に効かないため）
- 映像にする3場面は、計測と同じシーンを使い、色と照明だけ整えて Unity Recorder で撮る

## 8.6 画面に出す情報（段階4の撮影の前に作る。2026-10-21 追記）

参考：清水秀樹さんが LinkedIn に投稿した、Unity で隅田川を再現した操船シミュレーターの画面。建物も船も白い箱なのに説得力があるのは、出している数字（桁下と船の高さ、次の変針、時刻と倍速、海図）が本物だから。見た目より、画面に出す情報の選び方を借りる。

決まり：画面に出す数字は、記録（trips.csv・stops.csv）に書く数字と同じものにする。見た目のためだけの数字は出さない。

| 場所 | 出すもの |
|---|---|
| 画面の上（いつも出す） | 店の中の時刻と倍速、条件（店の形・細い通路の幅・混み具合・台数）、受け渡し口で待っている料理の数、止まった回数・止まっていた秒数の合計・動けなくなった回数 |
| ロボットの上の字幕 | 次の行動（「卓12へ」「受け渡し口へ戻る」「通路の入口で待つ：先に1台」「止まっている：前に客 0.4 m」）。色は 走っている＝白／止まっている＝黄／動けなくなった＝赤（あと何秒で人を呼ぶか） |
| 人の上の字幕 | スタッフ・客・待合の客が今していること（「料理を運ぶ → 卓12」「トイレへ」「卓に戻る」「待っている」など）。ロボットが止まった相手が何をしていたかが画面で分かる。確認用の表示（Scene ビューだけ）は段階2のあとに先に作る（2026-10-21 追記） |
| 床の塗り分け | ロボットの体が入れる床（水色）と、人だけが入れる床（薄い黄色）を塗り分け、凡例を付ける。Unity の NavMesh の表示（ロボットの中心が行ける範囲）は、見る人に「この細い帯しか通れない」と読まれるので、人に見せる絵には使わない（2026-10-21 追記） |
| 余裕の数字 | 「通路 80 cm・ロボット 50 cm・左右に 15 cm ずつ」。椅子が引かれたら「残り 50 cm・通れない」を赤。人との一番近い距離が決めた値を下回ったら黄（値は RobotSpec） |
| 右下の全体図 | 店の見取り図に、ロボット全台・スタッフ・客の点。止まった場所に印を残して重ねる（どこで止まりやすいかの地図） |
| 視点 | ロボットの目線／真上／店全体の斜め上／止まった場所に寄る |

なぜ「余裕の数字」を先に置くか：すかいらーくは配膳ロボットを、まず通路に余裕のある店から入れた。築年数のたった店では「通路の狭さやカーペットなどによる段差といった問題もありました」（Business Insider Japan の記事での担当者の発言）。どこで何 cm 足りないかが画面で見えると、SimPy の待ち時間の数字に理由が付く。

## 9. Claude Code への依頼で守ること

- 新しいシーン `Assets/ServiceSim/ServiceSim_Family.unity` を作る。mechArm のシーンとスクリプトには触らない
- ArticulationBody は使わない（この回はアームを使わない）。既存の ArticulationBody の設定にも触らない
- NavMesh の部品（com.unity.ai.navigation）が入っているかを最初に確かめる。入っていなければ、入れる前に報告する
- 作業の区切りごとに VCS Check-in。`git clean` は使わない
- 書き出しの前に KIOXIA がつながっているかを確かめ、つながっていなければ止めて報告する。同じ名前のフォルダがあれば上書きせずに止める
- Claude Code が書いたコードは、実行する前にエイイチが読む

## 10. この回で分からないこと

- 人の動き（何人が、どれくらいの頻度で通路を歩くか）が仮なので、Unity の結果は「通路の幅と混み具合で、3つの数字がどう変わるか」の形を示すところまで。店の実際の値は、観察シート（LOG353）で測って置き換える
- 料理のこぼれは、この回では扱わない。急に止まったときの減速の強さだけ記録しておく
- cs:140（2026-10-23）：段階Bのまとめて回す仕組みと台帳（unity_ledger_v1.csv・49列）を入れた。動きは cs:139 と同じ。出力フォルダは {日付}_stageB_{店}_r{台数}_s{種}。台帳に行がある回は status に関係なく回し直さない。pause_rate・stuck_rate は台帳では空欄（サイトの hop_m は試算の中だけの設定で Unity は読まないため）。段階Cで summary.json の stops と trips.distance_m_total から割り出す。