サービスロボット導入シミュレーション Log#26 | 配膳ロボットの試算を、店のスマホで測って確かめる

配膳ロボットの試算が置いている前提（会計は1回90秒、片付けは40秒、ロボットが動けなくなるのは1往復あたり1%など）は、店の人がスマホで作業ごとの時間を測り、入ってきた組と会計した組を数えれば確かめられます。そのための観察シートを、ファミレスの店員さんが片手で迷わず使える形に作り直しました。同じ日に、Unity で再現した3Dのファミレスのスタッフの立ち位置も、実際の店に近づけました。

このシリーズでは、配膳ロボットを入れたファミレスの待ち時間を、サイトの試算（計算で出す待ち時間）と、Unity の3Dシミュレーション（店を建てて人とロボットを歩かせるもの）の2つで調べています。どちらも、元になる数字は今のところ仮の値です。仮の値のままでは、試算がどれだけ店に合っているかを言えません。 店で測った数字を入れる入り口が要ります。

ところが、前に作った観察シートは、ロボットが止まった場所と原因を細かく選ぶ形で、1画面に設定と説明がぎっしり並んでいました。店で使うのは、ロボットに詳しい人ではなく、ホールで働くおじさん・おばさんです。忙しい時間にスマホで押すなら、1画面に1つのことだけを出し、押し間違えてもすぐ戻せる形でなければ使われません。

下の図で、観察シートの項目を押すと、測った数字が試算のどの前提に入るかと、今の前提の値が出ます。

配膳ロボットを自分の店に入れたら何人で回るかは、このシリーズの試算をもとにした別のページで試せます。

導入前シミュレーション配膳ロボットを、導入前に自分の店舗でシミュレーション店舗の図面と人数から、何人で回るか・どこで止まるか・月いくらかかるかを出しますarrow_forward

作業ログ ― Unity のスタッフに、入口番と持ち場を入れた

サイトの試算・Unity・依頼箱・入口番・持ち場は、このシリーズで何をしているか

店の番号と形は次のとおりです。② 定番の郊外型（昔働いていたファミレスを記憶から起こした店）、③ 効率重視・入口が角、④ 効率重視・小さめの店、⑤ ゆったり・入口が正面、⑥ ゆったり・入口が横、⑦ 効率重視・席を詰めた店。

手が空いたスタッフが、パントリーの壁ぞいに一列に固まっていた

比較動画の素材を見ていて、エイイチが気づいたことです。

店舗の奥にスタッフが固まっていますが、実際に全員が奥に配置してしまうとお客さんが入ってきた時にわかりません。必ず1人は入り口近くに配置してください（忙しいと入り口あたりにスタッフがいない時もあるますがそれはお客様優先ですので勘違いしないように注意）

最初、Claude は「1人は入口、ほかは店が見渡せる場所」と受け取り、客席を分けて担当する点を作る案を出しました。エイイチの説明はこうでした。

店員はパントリー近くにいることが多いよ（色々準備したり片付けや掃除、配膳準備をするため。その中で散らばっているの意味ね）

そこで、持ち場はパントリーのまわりに散らす形にしました。④だけは、2番の点を入口に近い側へ寄せました（エイイチの指示「④の2番の人は入り口に近い方がいいね」）。パントリーから測る幅を0.5mから0.6mに広げると、④の2番だけが入口寄りの点に変わり、ほかの5店の点は変わりませんでした。

スタッフの持ち場を作る staff_post_points（unity_export.py）

店の形は、サイトの tools/sim_layouts/unity_export.py で作り、Unity はそれを読むだけです（サイトが正）。持ち場の点もここで作りました。候補は0.25mおきの点で、人が立てて、何かに寄っていて、ロボットのふだんの道をふさがない所です。入口・レジ・待合・受け渡し口・トイレ・ドリンクバー・ロボットの待機場所からは1.2m以上離します。パントリーから0.6m以内の候補を、受け渡し口に近い順に見て、すでに選んだ点から1.8m以上離れたものを選びます。

diff --git a/tools/sim_layouts/unity_export.py b/tools/sim_layouts/unity_export.py
index e320ba7..323f459 100644
--- a/tools/sim_layouts/unity_export.py
+++ b/tools/sim_layouts/unity_export.py
@@ -8,7 +8,7 @@
 - floor：床を敷く矩形（建物の外を除く）
 - aisles：細い通路（ボックス席の列と列の間。幅・区画・両端の入口と受け渡し口の前からの道のり）
 - tables：卓ごとの部品（天板・ベンチ・椅子・座る位置・席に着くために立つ点）と、止まる位置・通る細い通路

できた点は次のとおりです（単位は m。原点は店の外壁の内側の左下の角）。ファイル名の p0 は②、p1 は③、p2 は④、p3 は⑤、p4 は⑥、p5 は⑦の店です。卓・卓までの距離・ロボットが止まる位置・地図の数字は、6店とも前と同じです。店の形の版は 08db8a0d067c から 9b8dae7ebf8c に変わりました。

p0_memory レジ内（入口番） [11.05, 3.3] 持ち場 (9.5, 5.5) (9.0, 7.25) (9.25, 9.25) (9.25, 11.25)
p1_efficient_corner レジ内（入口番） [4.45, 1.65] 持ち場 (14.0, 6.0) (13.75, 8.0) (13.75, 10.0) (13.75, 12.0)
p2_efficient_narrow レジ内（入口番） [13.25, 1.65] 持ち場 (9.75, 4.5) (9.75, 9.0) (11.25, 10.25)
p3_relaxed_center レジ内（入口番） [10.8, 1.55] 持ち場 (11.25, 9.0) (9.25, 9.0) (17.5, 9.0) (7.25, 9.0)
p4_relaxed_side レジ内（入口番） [4.75, 1.25] 持ち場 (13.0, 6.0) (12.5, 7.75) (12.75, 9.75) (12.75, 11.75)
p5_crammed レジ内（入口番） [4.45, 1.65] 持ち場 (14.0, 6.0) (13.5, 7.75) (13.75, 9.75) (13.75, 11.75)

試算の決まりの表（serving-robot-params.json）に足した entrance_keeper と staff_posts

Unity は、回し方の決まりもサイトの serving-robot-params.json の unity_rules から読みます。入口番（entrance_keeper）と持ち場（staff_posts）をここに足しました。試算はスタッフの立ち位置を持たないので、試算の数字は変わりません。3回のコミットの差分です。

# commit 1449063
diff --git a/public/sim/serving-robot-params.json b/public/sim/serving-robot-params.json
index be8f2cd..f00ce12 100644
--- a/public/sim/serving-robot-params.json
+++ b/public/sim/serving-robot-params.json
@@ -160,6 +160,11 @@
    "value": false,
    "role": "site_rule",

依頼41「入口番とスタッフの持ち場を入れる」の全文

---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 180
---
# 依頼：入口番とスタッフの持ち場を入れ、③と④を1本ずつ撮って確かめる（2026-10-31 昼）

エイイチの指摘（2026-10-31）：Unity では手が空いたスタッフが店の奥（パントリーの壁ぞい）に固まっている。実際は、
- 全員が奥にいると、お客さんが入ってきたときに分からない。**手が空いた人のうち1人は必ず入口が見える所にいる**（入口番）。ただし忙しくて全員が仕事中なら、入口にだれもいなくてよい（お客さん優先。入口へ戻すために仕事を止めない）
- ほかの人は、準備・片付け・掃除・配膳の準備のため**パントリーの近くにいることが多いが、1か所に固まらず散らばっている**

サイト（正）は直して公開済み（p2m-site main 0dfcc5a）：
- 店の形：6店に `places` の `StaffPost`（スタッフの持ち場 1〜4。④は1〜3）を足した。版 08db8a0d067c → **9b8dae7ebf8c**。卓・距離・止まる位置・地図の数字は6店とも前と同じ（変わったのは generation・rules の文・StaffPost だけ）
- params：`meta.layout_generation` を 9b8dae7ebf8c に。`unity_rules` に `entrance_keeper`（true）と `staff_posts`（true）を足した。中身は note を読むこと。試算の数字は変わっていない

## 始める前に確かめること（違えば回さずに報告して終わる）

1. Unity エディタが起動していない
2. /Volumes/KIOXIA がマウントされている。台帳の鍵ファイル unity_ledger_v1.lock がない
3. ServiceSim の保留が 0
4. 夜の作業（night_runner）が動いていない

## やること

1. 公開版の params と6店の unity json・map を、いつもの手順でプロジェクトに写す。`unity_rules`・`meta.layout_generation`・`places` の StaffPost 以外が今の写しと同じかを確かめて報告に書く
2. **入口番**と**持ち場**を切り替えで入れる。既定は params の `unity_rules` の値（どちらも入）＝これからの標準
   - `-ssEntranceKeeper on|off`・`-ssStaffPosts on|off`、make_queue / night_runner / rec_runner の `--entrance-keeper on|off`・`--staff-posts on|off` で回ごとに上書きできるようにする（待機場所へ戻る・案B と同じ作り）。run_info.json に書く。出力フォルダ名の末尾は、入のとき `_ek`・`_post`（名前の付け方は今の `_passon_sbret` に続ける）。台帳の列は増やさない
   - 入口番：手が空いたスタッフは、レジ内（RegisterBack）にだれもいない（向かっている人もいない）ときだけレジ内へ行って待つ。ほかの人は持ち場へ。入口番も、ほかの人と同じように仕事を取る（入口番だから仕事を取らない、はしない）。仕事を終えた人は、レジ内が空いていればまずレジ内へ
   - 持ち場：入口番の1人を除いた人数ぶん、StaffPost の 1 から順に使う。手が空いた人は、使う点のうち空いている一番近い所へ行く。点が足りないとき（④でスタッフが5人など）は今までの StaffStandby を使う
   - 切のときは、今までどおり（StaffStandby に受け渡し口に近い順）
   - キッチンのモニターに、入口番がだれかと、各スタッフの持ち場の番号が分かる表示を足す
3. check-in して、画面なしの実行ファイルを作り直す（保留 0）
4. 確かめの録画を2本撮る。依頼38と同じ録画のしくみ（rec_runner・幅2560・0.5秒ごと・15倍速）、すれ違い 入・待機場所へ戻る 入・案B 切、入口番 入・持ち場 入。名札は `postcheck`、記録は night/20261031_postcheck/
   - ③（fam_p1）普通・真ん中の人数（スタッフ4人）・ロボット2台・種7
   - ④（fam_p2）普通・真ん中の人数（スタッフ2人）・ロボット2台・種1
5. 4 の2本の数字を、昨夜のストック（night/20261030_rec の同じ店・同じ条件・同じ種）と並べる

## 変えないもの

- 店の回し方のほかの決まり・人とロボットの動き・速さ・物理の設定・すれ違いの作り
- 台帳の列（59列）と今までの行、昨夜のストック（20261030_rec）と基準データ

## 報告

依頼箱の結果に加えて、claude_code_reports に 20261031_staff_posts.txt として書く（場所：~/Library/Mobile Documents/com~apple~CloudDocs/デスクトップ/ADAPT DESIGN/じぶんの/PixelstoMotors/デジタルツイン学習R2R2R/サービスロボット導入シミュレーション/unity/claude_code_reports/）。

- 始める前の確かめ4つの結果、1 の写しの比べ
- 入れた cs 番号・build_id と保留の有無・変えたファイル・作りで決めたところ
- 4 の2本の動画のパスと、5 の比べ：入店待ち・そのうち席は空いているのに待った時間・料理の待ち・会計待ち・入れた組の数・30秒以上の止まり・動けなくなった（60秒）・ロボット救出・スタッフ1人が歩いた距離
- 4 の2本で、手が空いたスタッフがレジ内にいた時間の割合と、だれも入口番がいなかった時間の割合（全員が仕事中だった時間とそうでない時間に分けて）
- 全員が帰らなかった回・失敗した回があればその名前
- 決めてほしいこと（なければ「なし」）

依頼41 の結果（依頼箱の報告）

# 結果：20261031_41_入口番とスタッフの持ち場を入れる

- 状態：完了
- 始めた時刻：2026-10-31 09:54
- 終わった時刻：2026-10-31 10:27（33分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume 8f6da939-a9ba-4604-b3fa-168b0c332a87`

③の店では、手が空いた人がいる時間のうち63.8%で「入口番がいない」と数えられました。理由は、会計の人がレジ内を使っている間、入口番が入れない作りにしたためです。Claude Code は、会計の人を「入口が見える人」に数えてよいかを聞いてきました。

会計中のスタッフも入口番に数える

実際の現場では、会計中の人が入り口を兼ねる場合と他のスタッフが案内するのケースバイケースです。

エイイチの答えで、会計中の人も入口番に数えることにしました。動きは変えず、数え方だけを変えています。

• ねらい：入口が見える人がいた時間を、現場の感覚に合う形で数える
• 変わったこと：③で「手が空いた人がいる時間のうち、入口番がいた」が36.2%から90.9%に、④で79.6%から94.0%になった（依頼42の報告。今ある記録から出した値で、多めに出る）
• 見込める効果：今夜の66本から、入口番がいた割合を正しい数え方で比べられる。値は依頼43の報告で確かめる

依頼42「入口番の数え方と判定の条件と片付け」の全文

---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 90
---
# 依頼：入口番の数え方を直し、判定に入口番・持ち場の条件を足し、試しの残りを片付ける（2026-10-31 昼）

前の報告（20261031_staff_posts.txt）の「決めてほしいこと」へのエイイチの答え：
1. **会計中の人を入口番に数える**（レジ内にいて入口が見えるため）。動き（会計の人がいる間、手が空いた人は持ち場で待つ）は今のまま。実際の現場では、会計の人が入口を兼ねるか、ほかの人が案内するかはケースバイケース。サイトの params の entrance_keeper の説明も直した（p2m-site 5cbfa59。値・ほかの項目は変わっていない）
2. 今夜は予定どおり66本を撮り直す（別の依頼43。この依頼では回さない）
3. 判定（judge_night.py）に入口番・持ち場の入切を条件として足す
4. 試しの残り（smoketest41 の途中の記録・Builds/rec4_compiletest・tools/__pycache__ の night_runner の pyc）は消す
5. cs:50 と cs:51 に分かれたのはこのままでよい

## 始める前に確かめること（違えば回さずに報告して終わる）

1. Unity エディタが起動していない・night_runner／rec_runner が動いていない
2. /Volumes/KIOXIA がマウントされている。unity_ledger_v1.lock がない
3. ServiceSim の保留が 0（cs:51 head）

## やること

1. 公開版の params（5cbfa59）をプロジェクトに写す。entrance_keeper の note 以外が今の写しと同じかを確かめる
2. summary.json の staff_places の数え方：「入口番がいた」を、手が空いた人がレジ内にいる時間＋会計中の人がレジ内にいる時間にする（今の「だれかがレジ内にいた」に当たるもの）。前の数え方の値も消さずに残す（名前を分ける）。動きは変えない
3. judge_night.py：入口番（entrance_keeper）と持ち場（staff_posts）の入切を、待機場所へ戻る・案B と同じように条件に足す。run_info.json に記録がない前の回は「切・切」として扱う。基準データ（v5 など）の決め方・判定の決まりそのものは変えない
4. 3 の確かめ：night/20261031_postcheck/ を判定し直し、③の回が「入・入」の条件として扱われる（基準のない条件になる）ことを見る。今までの夜（20261102 など）の判定結果が変わらないことも1つ確かめる
5. 4 の残りを消す（KIOXIA の 20261031_smoketest41_…_stopped/・プロジェクトの Builds/rec4_compiletest・tools/__pycache__ の night_runner の pyc）。台帳にその回の行がないことも確かめる
6. check-in して、画面なしの実行ファイル（Builds/headless）と録画用の実行ファイルを作り直す（保留 0）。今夜の依頼43はこの実行ファイルで撮る

## 変えないもの

- 人とロボットの動き・店の回し方・速さ・物理の設定
- 台帳の列（59列）と今までの行、昨夜のストック（20261030_rec）と基準データ、確かめの2本（20261031_postcheck）の出力

## 報告

依頼箱の結果に加えて、claude_code_reports に 20261031_keeper_count.txt として書く。
- 始める前の確かめ・1 の比べ
- cs 番号・build_id・保留・変えたファイル
- 確かめの2本（③④）の、新しい数え方での「入口番がいた／いなかった」の割合（手が空いた人がいる時間・全員が仕事中の時間に分けて）
- 4 の判定の結果、5 で消したもの
- 決めてほしいこと（なければ「なし」）

依頼42 の結果（依頼箱の報告）

# 結果：20261031_42_入口番の数え方と判定の条件と片付け

- 状態：完了
- 始めた時刻：2026-10-31 10:32
- 終わった時刻：2026-10-31 10:40（8分）
- 作業フォルダ：/Users/shimazueiichi/Robotics_UX/ServiceSim
- この続きを Claude Code で話すとき：作業フォルダで `claude --resume e49739a6-bfc2-419b-986a-e359b7b6e4f5`
- 止められた操作：1件（いちばん下に一覧）

依頼43「比較動画の素材を入口番と持ち場ありで撮り直す」の全文

前の夜に撮った比較動画の素材66本は、スタッフが固まっていたころの動きです。比較動画をこのまま作ると、現実と違う並び方を見せることになるので、撮り直してから作ることにしました（エイイチの判断「直してから撮り直す」）。依頼43は今夜、依頼42の結果を確かめてから依頼箱へ入れます。

---
作業フォルダ: /Users/shimazueiichi/Robotics_UX/ServiceSim
上限時間: 720
---
# 依頼：比較動画の素材66本を、入口番と持ち場ありで撮り直す（夜・2026-10-31）

エイイチと決めたこと：昨夜のストック（night/20261030_rec・依頼38）は、手が空いたスタッフが店の奥に固まる前の動きで撮った。入口番（レジ内）と持ち場（パントリーのまわりに散らす）を入れたので（依頼41・42、版 9b8dae7ebf8c）、比較動画の素材を同じ形で撮り直す。比較動画はこの新しい素材から作る。
**エイイチは寝ている。人に聞かないと進めない所に当たったら、その作業は止めて報告に書き、ほかの作業は続ける。**

## 始める前に確かめること（違えば回さずに報告して終わる）

1. Unity エディタが起動していない・ほかの night_runner／rec_runner が動いていない
2. /Volumes/KIOXIA がマウントされている。unity_ledger_v1.lock がない。台帳を archive/unity_ledger_v1_prerec_20261031/ に控え、行数と md5 を報告に書く
3. ServiceSim の保留が 0。依頼42の check-in のあとに作り直した実行ファイル（画面なし・録画用）で、build_info の pending_changes が空
4. プロジェクトの params の unity_rules が entrance_keeper=true・staff_posts=true・standby_return=true・pass_one_robot=false・same_table_one_robot=false。店の形の版が 9b8dae7ebf8c

## 撮る回（6店 × 11条件 × 種1つ = 66 回）

依頼38（night/20261030_rec/README.md）と**同じ条件・同じ種・同じ順・同じ映し方**で撮る。違うのは、入口番 入・持ち場 入（今の標準）と、実行ファイル・cs だけ。
- 種：③ 7・⑦ 7・④ 1・⑤ 1・⑥ 1・② 8（昨夜と同じ。選び直さない）
- 条件の順：普通・真ん中の人数（0・1・2台）→ スタッフが少ない（0・2台）→ 混んでいる（0・2台）→ スタッフが多い（0・2台）→ 空いている（0・2台）。店の順は ③⑦④⑤⑥②
- すれ違い 入・待機場所へ戻る 入・案B 切・入口番 入・持ち場 入
- 映し方：真上・全体（外寸に0.8mの余白）・幅2560・0.5秒ごと・30コマ/秒（15倍速）・回の最初から全員が帰るまで
- 回し方：night/20261030_rec/rec_runner.py と同じやり方（必要なら night/20261031_rec/ に写して使う）。名札は `rec`、夜の名前は 20261031。記録は night/20261031_rec/
- 同時に回す本数は2本（昨夜と同じ）
- 時刻で止めず、並べた回が全部終わるまで回す。途中で止まっても同じ回を回し直さない（そのまま報告する）
- 回している間は、ほかの作業をしない。Unity を開かない
- **Mac をスリープさせない**こと（昨夜は回し終わったあと、依頼箱の見張り係が止まっていた。回し終わったら、スリープの設定を戻す前に報告と一覧を書き終える）

## 素材の一覧

night/20261031_rec/ に、昨夜と同じ形の `rec_index.csv` と `README.md` を置く。rec_index.csv の列は昨夜と同じにし、最後に「入口番がいた割合（手が空いた人がいる時間のうち・依頼42の数え方）」の列を足す。

## 変えないもの

- 店の回し方・人とロボットの動き・速さ・物理の設定・実行ファイルの中身
- 台帳の列と今までの行。昨夜のストック（20261030_rec）とその動画

## 報告

依頼箱の結果に加えて、claude_code_reports に 20261031_rec_stock_v2.txt として書く。
- 始める前の確かめ4つ・台帳の控えの md5
- cs 番号・build_id
- 66 回の結果（completed の数・失敗・止まった回・最長の実時間・夜全体の始まりと終わり）
- 動画の合計の大きさ
- 台帳の行数と、先頭の行の md5 が控えと同じか
- rec_index.csv の全文
- 昨夜（20261030_rec）の同じ店・同じ条件の回との比べ（入店待ち・席は空いているのに待った・料理の待ち・会計待ち・動けなくなった）。66組を表で。原因は調べなくてよい

• ねらい：比較動画に映るスタッフの動きを、実際のファミレスの待ち方に合わせる
• 変わったこと：手が空いた人は、1人がレジ内、ほかはパントリーのまわりに散って待つ
• 見込める効果：店の人が動画を見て「うちと違う」と感じる所が減る。66本の数字が前の夜とどう違うかは、依頼43の報告で確かめる

作業ログ ― サイトの試算と Unity のずれを見直した

試算と Unity を、同じ条件の72組で並べた compare_site_unity.py

エイイチの問いは「サイトの試算は Unity のシミュレーションから見て妥当か」でした。台帳には、Unity の回ごとの値と、同じ条件の試算の値が1行に入っています。直近の2つの夜（6店 × 条件 × 種10、合わせて720回・72条件）を、条件ごとに種10本の平均にして並べました。台帳は KIOXIA の service_sim/unity/unity_ledger_v1.csv を写したものです。

# サイトの試算（SimPy）と Unity の3Dシミュレーションの数字を、同じ条件で並べる。
# 入力：KIOXIA の台帳 unity_ledger_v1.csv（Unity の値と、同じ条件の試算の値 site_* が1行に入っている）
# 対象：直近の2つの夜（20261106_busy・20261107_staff）。どちらも6店 × 条件 × 種10
import csv, sys, statistics as st
from collections import defaultdict

LEDGER = sys.argv[1] if len(sys.argv) > 1 else 'unity_ledger_v1.csv'
NIGHTS = ('20261106', '20261107')

$ python3 compare_site_unity.py unity_ledger_v1.csv
行数 720・条件 72（種ごとの平均で比べる）

■ 条件ごとの平均（分）。U=Unity・S=サイトの試算
夜,店,スタッフ,ロボット,来店/時,種,入店待ちU,入店待ちS,料理の待ちU,料理の待ちS,会計待ちU,会計待ちS,動けなくなった/往復
20261106,②定番の郊外型,2,0,14,10,1.54,0.43,0.72,0.38,0.82,0.82,
20261106,②定番の郊外型,2,0,24,10,11.69,9.98,1.02,0.72,1.44,2.02,
20261106,②定番の郊外型,2,1,14,10,1.38,0.34,1.05,0.73,0.76,0.63,0.019

人だけの店なら、Unity の入店待ちは試算の約1.2〜1.8倍

ロボット0台の条件では、店ごとの中央値で Unity の入店待ちが試算の1.17〜1.82倍でした。Unity では、スタッフが通路で人とすれ違い、お客さんが席に着くまでに歩きます。試算はその歩く時間を細かく持たないので、Unity のほうが長くなるのは自然です。人の側の差は、店の形による違いはあっても、倍率で言える大きさに収まっています。

ロボットが動けなくなる割合は、試算の1%に対して Unity は13.1%

違いが大きいのはロボットの側です。試算はロボットが動けなくなる（立ち往生する）割合を1往復あたり0.01で置いています。Unity でロボットが60秒止まったまま動けなくなった回数を往復の回数で割ると、6店まとめて13.1%、いちばん狭い④では39.8%でした。0台から2台に増やしたときに入店待ちが減るか増えるかの向きも、24組のうち10組で試算と Unity が逆でした。逆になった組は、ほとんどが「試算は減る・Unity は増える」で、④に大きな差が集まっています。

ただし、Unity の「60秒止まった」と、試算の「立ち往生」が同じものかは、まだ決めていません。Unity では、人とすれ違うために少し待つだけの止まりも、長引けば60秒を超えます。今は試算の値を変えず、どちらに合わせるかは現場で測った数字を見てから決めることにしました。

現場の数字を入れる土台は、半分まで

エイイチの次の問いは「将来現場のデータが集まってきた時に、正確に素早くシミュレーションを更新するための土壌はできていますか？」でした。

今の作りでは、試算の前提はすべて serving-robot-params.json の1か所にあり、値ごとに「サイトで決めた（site_rule）」「Unity で測って戻す（unity_measures）」の印が付いています。Unity もこのファイルを読むので、値を1つ直せば試算と Unity の両方に届きます。ここまではできています。

足りないのは、値ごとに「この数字はどこから来たか（仮に置いた・Unity で測った・どの店で何回測った）」を持つ欄と、店で測った記録を前提の値へ移す手順です。エイイチは、測れる項目を次のように整理しました。

現場のデータを集める時事細かに全てを計測することは困難です。…実際に計測できそうなのは席数と席と席の幅や通路の間隔、スタッフの人数、各タスクの計測などになるかと思います。

そこで、測る項目と、それが入る前提を表にしました。観察シートの作り直しは、この表の C・D・E を店で集めるためのものです。

店の写真や図面から A を読み取る案も話しました。奥行きを測るセンサーの付いたスマホと間取りのアプリなら、スマホで撮影するだけで部屋の寸法が取れるものがあります。ただ、店の写真にはお客さんが写ります。お客さんのいない時間に撮れば済みますが、その時間には作業を測れません。写真や動画は、シートでは扱わないことにしました（後の節）。

作業ログ ― 観察シートを、店の人がスマホで迷わず使える形に作り直した

前の観察シートは、店の人が使うには設定と説明が多すぎた

前の観察シートは、ロボットの出発・卓に着いた・止まった・戻ったを押し、止まった場所と原因を選ぶ形でした。記録する人の立場（客席から・店のスタッフ・導入や保守の担当）で選択肢が切り替わります。1画面目から説明と設定がぎっしり並んでいます。

エイイチの方針はこうでした。

前提として、店舗のおじさん、おばさんたちが観察シートを使うことを想定してください。観察シートはスマホで使う可能性が高いです。…大事なのは詳細な画面設計よりもわかりやすさや、手順を迷わせない工夫が大事だと思います。必要ない情報は画面の中に見せない、計測作業が失敗しても、すぐに元に戻してやり直せる簡素なUI/UX。など考慮して考え直してみてください。必要ないくつかページを提示して比較させてください。

その前に、観察シートを使う人を3つに分けていました。ロボットの導入を考えている人、ロボット導入後の改善策を検討したい人、ロボットはないが店の回し方を試算したい人です。新しいシートは、この3つを入り口で選ぶところから始めます。

試作3案を並べて、A を元に B のカードの並びにした

3案をスマホの幅で作り、並べて見てもらいました。A は1つずつ案内する形（何を測るかを選び、スタート・ストップを押す）。B は作業のボタンを押すだけの形（始まったら押し、終わったら同じボタンをもう一度押す）。C は押してから選ぶ形（始まったら大きな丸を押し、何の作業かは終わってから選ぶ）です。

Aをベースに カードの並ぶ順はBの見た目かな。あと回数の数字が大きい方がいいね

そのあと、スマホで実際に押してもらいながら、次の直しを重ねました。

• ストップウォッチとカードを、画面の縦の真ん中に置いた（上に寄っていた）
• 文字を大きくし、カードを細い線から影のある形にした
• 「記録を見る」を、カードのすぐ下のアイコン付きの丸いボタンにした（画面の一番下では遠かった）
• すべての画面に「最初に戻る」を置いた（「目的やお店を変える」より伝わる言葉にした）
• 入り口の目的のカードの上下の余白を44pxに増やした（押しやすくするため）
• お店のことに、時間帯（開いた時刻から自動で選ぶ）と今日のようす（いくつでも選ぶ＋自由に書く欄）を足した
• 「全部消す」は、1回押すと5秒から数字が減り、もう一度押すと消える。押さなければ元に戻る。消した直後も取り消せる

• ねらい：店の人が、説明を読まずに1回目を測り終えられるようにする
• 変わったこと：1画面目に並んでいた説明と設定を、目的・お店のこと・作業を選ぶ・測るの4つの画面に分け、1画面に1つのことだけを出した
• 見込める効果：測り始めるまでの迷いが減る。実際に店で使えたかは、店で使ってもらったあとの記録の数で確かめる（今は見込み）

食べている時間は測らず、入ってきた組と会計した組から回転率を出す

最初の試作には、卓ごとの食べている時間を測る項目がありました。エイイチの判断で外しました。

観測シートでどこまでの情報を入力するかだね。食べる時間は人たちによって全然違うし、計測もかなり大変（待ち時間がかなり必要）だからそのコストを払えないんじゃないかな？だから入店の客数とレジで大体わかるように設計した方がいいね。お店によってその辺りから回転率とか出そうだし

代わりに「お客さんの出入り」の画面を足しました。入ってきたら・会計を終えたら押すだけです。数えはじめにお客さんがいる卓の数を入れておくと、回転率（1時間に1卓が何組入れ替わるか）と、滞在時間の目安が出ます。滞在時間の目安は、店にいる組の数の平均を、帰っていくペースで割って出します（待ち行列で使う リトルの法則。店に平均20組いて、1時間に30組帰るなら、1組は平均40分いる）。

写真と動画はシートで扱わず、送る記録は人が読める文にした

店の写真や動画を添付できるようにする案も考えました。エイイチの判断です。

店舗の人にお客さんを映らないようにと伝えるのは難しいかな。人のいない店舗だと計測できないし。写真や動画はやはりやめておくか。添付できるようにだけしておいて責任はスタッフや店舗、業者に考えてもらった方が安全かな。

シートは写真を受け取らず、送る画面に「写真や図面があれば、LINE やメールで一緒に送れます。写っている人の扱いは、お店の決まりに合わせてください。」と書くだけにしました。

送り方も変えました。最初は記録を文字ごとコピーする形で、エイイチから「記録を送る だけど、コピペするってこと？わかりにくいよ」と言われ、「LINEで送る」「メールで送る」の2つのボタンにしました。送る文に入れていた取り込み用のデータ（JSON）も「メールの内容これでもいいの？コードみたいのついてるけど？」と言われて外し、人が読める行だけにしました。下は、試しの記録（店で測ったものではありません）で作った送る文です。

観察シートの記録
日付：2026/10/31
目的：ロボットを入れていて、改善したい
お店：〇〇店　スタッフ4人　ロボット2台
卓の数：約35卓
時間帯：昼（ランチ）　混んでいる
会計：だいたい57秒（2回）
片付け：だいたい1分35秒（1回）
ロボットの往復：だいたい2分28秒（1回）
出入り：入ってきた3組・会計した2組（数えはじめに20卓にお客さん）
1時間あたり：来店 約7組・会計 約5組
回転率：0.1回転／時
滞在時間の目安：約263分

--- 1回ずつの記録 ---
12:05:10　会計　52秒
12:09:40　会計　61秒
12:12:02　片付け　95秒
12:15:30　ロボットの往復　148秒（止まった1回・人が動かした0回）

--- 入ってきた時刻 ---
12:00:00、12:10:00、12:20:00

--- 会計した時刻 ---
12:05:00、12:25:00

試しの記録は25分で入ってきた3組・会計した2組なので、回転率と滞在時間の目安は意味のある値になっていません。数える時間が短いと、こうなります。

記録は店の中の人へ送る。シートの作り手には届かない

送る画面に「送った記録の扱い」を、開くと読める形で置きました。書く中身を相談したとき、エイイチはシートの使われ方の前提をこう話しました。

これって大前提として、観察シートは各店舗で使う前提で、オレに報告はしない前提なんだけど、あるとしたら店舗のデータをまとめた担当者や企業担当がオレに直接連絡してくるってパターンと思っているけど違う？

この前提に合わせて、メールは宛先を空にして開くようにしました（前は Pixels to Motors のアドレスが入っていました）。送る画面には「店長・お店の管理の方・ロボットの担当の方に送ります。」と書いています。データの扱いで書くのは、シートが記録をどこにも送らないこと、送る相手は自分で選ぶこと、送った記録は受け取った相手の決まりで扱われること、このスマホの記録の消し方、の4つだけにしました。入り口の下には「このシートは Pixels to Motors が作りました」とだけ出しています。

前の記録が残っているときは、同じ目的のカードから続きを測る

入り口に戻って測り直すと、前の記録が消えない作りでした。リセットのボタンを足す案に対して、エイイチは「ボタンを増やすと迷いが増えるよね」と言い、こう決めました。

前の記録が残っているときは、設定をそのまま継続で計測し始める必要があると思うから、例えばロボットを入れていて改善したいをまた押したら、直接継続ページに遷移した方がいいんじゃない？

記録が残っているときだけ、入り口に「前の記録が残っています」と「記録を消して新しく始める」を出し、前と同じ目的のカードに「続きから」の札を付けました。そのカードを押すと、お店のことを飛ばして作業を選ぶ画面へ進みます。

サイトのシリーズのページに組み込んだ表示で、入り口を飛ばして作業を選ぶ画面から始まっていたことがありました。前に目的を選んだことがあれば作業を選ぶ画面から始める、という最初の作りが残っていたためです。「続きから」のカードができたので、いつも入り口から始めるように直しました。

前のシートは noindex で残し、サイトを新しいシートに切り替えた

前のもサイトに表示させておいて残すという意味です（seoで表示されないようにメタデータを設定）

新しいシートを今までの住所（/sim/serving-robot-observation）に置き、前のシートは /sim/serving-robot-observation-v1 に移しました。前の版には <meta name="robots" content="noindex"> を入れ、検索結果に出ないようにしています。シリーズのページ（/series8）では、「観察シートを開く」のボタンの下に前の版へのリンクを置き、説明の文も新しいシートに合わせて書き直しました。試作の A・B・C は、比べた記録として残しています（どれも noindex）。

観察シートの作り直しのコミットの一覧

試作から切り替えまでの、p2m-site のコミットです（新しい順）。

99cf0c6 10-31 13:23 観察シート：送った記録の扱いから「Pixels to Motors には届きません」を消す
d449e5a 10-31 13:22 観察シート：記録は店の中の人（店長・管理の方・ロボットの担当の方）へ送る前提にする。メールは宛先を空で開き、Pixels to Motors には届かないと書く
ad1d089 10-31 13:16 観察シート：入り口に「記録はこのスマホの中にだけ残る」の1行と作った人を足し、送る画面に開くと読める「送った記録の扱い」を置く
a255a46 10-31 13:08 観察シート：前に目的を選んだことがあっても、いつも入り口の画面から始める（記録が残っていれば「続きから」のカードで続ける）
33b9f29 10-31 12:59 観察シートを作り直した版に切り替える。前の版は /sim/serving-robot-observation-v1.html に残し（検索に出ないよう noindex）、/series8 の観察シートの説明の下にリンクを置く。一覧の「← もどる」は前にいた画面に戻す
f7ec80e 10-31 12:44 観察シート：前の記録が残っているとき、前と同じ目的のカードに「続きから」を付け、押すとお店のことを飛ばして作業を選ぶ画面へ進む
8b739ca 10-31 12:38 観察シート：入り口に、前の記録が残っているときだけ「記録を消して新しく始める」を出す（続けるときは目的を選ぶだけ。消すのは5秒の数字つきで2回押し、取り消せる）
73cb414 10-31 12:37 観察シート：食べている時間は測らず、お客さんの出入り（入ってきた・会計した）を数えて、回転率と滞在時間の目安を出す。卓の数と、数えはじめにいる卓の数を足した
d63d30e 10-31 12:32 観察シート：送る文から取り込み用のデータ（JSON）を外し、1回ずつの記録を人が読める行（時刻・作業・秒）にした。日付も足した
ce19031 10-31 12:30 観察シート：写真や図面はシートで受け取らず、LINE・メールで一緒に送れることだけを書いた（写っている人の扱いはお店の決まりに合わせる）
095571c 10-31 12:28 観察シート：「LINEで送る」を LINE の緑と吹き出しのアイコン、「メールで送る」に封筒のアイコンを付けた
f38f523 10-31 12:26 観察シート：入り口の目的のカードの上下の余白をさらに増やした（30px → 44px）
4d54c92 10-31 12:24 観察シート：「全部消す」を1回押したあと、5秒から数字が減っていき、押さなければ元に戻ることを見せる
a6ea80c 10-31 12:20 観察シート：「記録を見る」をアイコン付きの丸いボタンにした（何を測りますか・記録した直後・来店の数）
d206efd 10-31 12:17 観察シート：入り口とお店のこと以外のすべての画面に「最初に戻る」を置いた（「目的やお店を変える」をこの言葉に。記録は消えない）
d6db848 10-31 12:15 観察シート：画面を移るとき、前の画面のお知らせ（取り消すの帯）を消す
977f66f 10-31 12:15 観察シート：「記録を送る」を「LINEで送る」「メールで送る」の2つのボタンにした（送る文が入った状態で開く。メールは宛先・件名つき）。送るデータを短くした
127c60d 10-31 12:09 観察シート：来店の数の画面に「ほかの作業を測る」と「記録を見る」を足した（作業を選ぶ画面へ戻れるように）
4af6500 10-31 12:08 観察シート：お店のことに時間帯（1つ選ぶ・開いた時刻から自動で選ぶ）と今日のようす（いくつでも選ぶ＋自由に書く欄）を足した。送る記録にも入る
ed8b6df 10-31 12:06 観察シート：入り口の目的のカードの上下の余白を増やした（押しやすくするため）
6be7ebb 10-31 12:04 観察シート：「記録を見る」を画面の一番下から、カードとボタンのすぐ下に上げた（試作Aと全体のページ）
6376d88 10-31 12:02 観察シートの作り直し（試作Aをもとに全体）：入り口（目的）→ お店のこと → 何を測りますか → 測る → 記録した直後 → 来店の数 → 記録（まとめ・送る・はじめから）。検索には出さない
7275812 10-31 11:57 観察シートの試作A：「記録を見る」を画面の下に移し、記録した直後の画面にも足した
0b37a74 10-31 11:56 観察シートの試作A：カードを細い線から影のある形にした（作業のカード・ストップウォッチ・記録の一覧）
5eb72c3 10-31 11:53 観察シートの試作A：記録の画面に「はじめから記録する」を足した（2回押すと全部消える。消した直後は取り消せる）
7be2cf6 10-31 11:50 観察シートの試作A：上の「観察シート」「記録を見る」の文字を大きくし、作業を選ぶカードを画面の縦の真ん中に置いた
e0e66ea 10-31 11:47 観察シートの試作A：測る画面と記録した直後の画面を、スマホの画面の縦の真ん中に置いた
74d95e5 10-31 11:41 観察シートの試作A：作業を選ぶ画面を2列のカードにし、回数の数字を大きくした
8be6d8d 10-31 11:29 観察シートの作り直しの試作3案（店の方がスマホで使う前提）：A 1つずつ案内する・B 作業のボタンを押すだけ・C 押してから選ぶ。検索には出さない
286be6f 10-31 11:20 観察シートの試作：計測中の作業のボタンを黒くして経過時間を出し、計測の行に黒い枠と点滅する「計測中」の札を付けた
6698e2b 10-31 11:18 観察シートの試作：最初に目的を選ぶ入り口（導入を考えている・導入後に改善したい・ロボットなしで店の回し方を試算したい）。ロボットのない2つではロボットの記録を隠す
40d3a64 10-31 11:14 配膳ロボット観察シートの試作：作業の時間を測るストップウォッチ（案内・会計・片付け・拭く・料理を置く・呼び出し・卓ごとの食べている時間）。公開中のシートとは別の住所・別の保存先、検索には出さない

観察シートの全コード serving-robot-observation.html

<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
<!-- 2026-10-31 観察シートを作り直した版（店の方がスマホで使う前提）。前の版は serving-robot-observation-v1.html に残す。記録はこの端末の中だけに残る（保存のキーは試作 obs-sheet-v2 と同じ） -->
<title>観察シート</title>
<link rel="preconnect" href="https://fonts.googleapis.com">

作業ログ ― 66本の撮り直しと比較動画は、次の記録で

今夜、依頼42の結果を確かめてから、依頼43（66本の撮り直し）を依頼箱に入れます。撮り直した素材から、6店の比較動画42本を作ります。比較動画を作る道具（make_compare_stock.py）はできていますが、まだ回していません。試算のロボットが動けなくなる割合（0.01）を Unity の値に合わせるかは、店で測った数字が入ってから決めます。