サービスロボット導入シミュレーション Log#16 | 店員が来るまでが、いちばん長かった

ファミレスで、配膳ロボットが通路の途中で止まっていました。向かいからもう1台が来て、どちらも道を譲れずに向き合ったままです。店員が来て画面を押し、片方を手で押してよけると、もう1台はすぐに動き出してテーブルに料理を届けました。店員の手が動いていたのは約5秒。ところが、止まってから店員が来るまでには、動画に映っているだけで41秒以上かかっていました。

配膳ロボットを入れると店がどう変わるかを、パソコンの中に作った3Dのファミレスで調べています（Unity というゲームを作る道具で作った店に、お客さん・スタッフ・ロボットを動かす、シミュレーションです）。このシミュレーションは、ロボットが止まったときに人がいつ来て、どれだけで直すかを、自分で決めた値で動かしています。その値が実物と比べてどうなのかを確かめる材料が、これまでありませんでした。

そこで、SNS に上がっている実店舗の配膳ロボットの動画を画面収録して、Claude と1秒・0.5秒ごとのコマで読み、何が起きて、どこに何秒かかったかを取り出すことにしました。正確な値ではありません。動画は編集されていて、止まり始めが映っていないことも多いからです。それでも、どこに時間がかかるかの形は見えます。5本を読んだ結果が次の表です。

止まったロボットを直す作業は1〜10秒。時間の大半は、店員が気づいて来るまでに使われていました。 ロボットは止まっている間、「仕事中だから通してほしいニャン」と声をかけ続け、足元の明かりを赤くしていました。けれども、それはお客さんに向けた合図で、ロボットを動かせる店員の手元に知らせが届いた様子は、どの動画にも映っていませんでした。店員が早く来たのは、店員がよく通るドリンクバーの前で止まったときだけです。

シミュレーションの前提とのずれも、いくつか見えました。止まって3秒で回り込む道を探すという決まりは、横に並んだ機体にふさがれた場面では効いていませんでした。待機場所を受け渡し口の近くにまとめると、待機場所の中で詰まることもありました。和食店では下げ膳だけをロボットに任せていて、ピークのあと、人が少ない時間にまとめて器を下げる使い方がありそうです。今のシミュレーションは料理を運ぶ仕事だけを、混む2時間だけで見ているので、どちらも入っていません。ずれは記録するだけにして、試算と Unity は変えていません。

やったことの全体です。

動画のコマは、ほかの人が投稿した動画で、店員やお客さん、子どもが映っているので、この記事には載せていません。投稿者と題名を書き、見えたことは文で書いています。ここから下は作業ログです。「見込める効果」と書いた所は、まだ測っていない見込みです。

作業ログ ― ①通路で向かい合った2台が、41秒以上止まった

動画①：ガストの通路の「お見合い」（@d51498com）

最初に共有したのは、次の依頼と動画1本でした。

これを見てロボットが立ち往生した時の運用や実際の時間などを分析してください。

動画は、YouTube ショート「お見合い立ち往生する猫型配膳ロボット #ガスト #ベラち…」（投稿者 @d51498com）の画面収録で、長さは約62秒、本編は約58秒でループしていました。音声は入っていません。機体は PUDU の猫型配膳ロボット BellaBot 2台で、片方は頭の上にタッチパネルが付いていました。

Claude は動画を次の手順で読みました。1秒ごとのコマに時刻を焼き込んで16枚ずつの一覧にし、場面の切り替えを2つの強さで探し、大事な場面だけ0.5秒ごとのコマと元の大きさの静止画で見ています。使ったコマンドの全量です。

ffprobe -v error -show_entries format=duration:stream=codec_type,width,height,r_frame_rate -of compact "/mnt/user-data/attachments/e3b17bed-07d2-52f9-95cd-546f4ffee470/8e4a0675-_____2026-10-26_17.28.28-compressed.mp4"
# stream|codec_type=video|width=410|height=720|r_frame_rate=120/1
# format|duration=62.511667

S=/tmp/claude-0/-home-claude/e3b17bed-07d2-52f9-95cd-546f4ffee470/scratchpad; mkdir -p $S/f; cd $S
V="/mnt/user-data/attachments/e3b17bed-07d2-52f9-95cd-546f4ffee470/8e4a0675-_____2026-10-26_17.28.28-compressed.mp4"
ffmpeg -v error -i "$V" -vf "fps=1,scale=205:-1,drawtext=text='%{pts\:hms}':x=4:y=4:fontsize=16:fontcolor=yellow:box=1:boxcolor=black" f/%03d.png
ffmpeg -v error -framerate 1 -i f/%03d.png -vf tile=8x2 sheet%d.png

# 場面の切り替え（強い切り替えだけ）
ffmpeg -i "$V" -vf "select='gt(scene,0.2)',showinfo" -f null - 2>&1 | grep -o "pts_time:[0-9.]*"
# pts_time:25.4667
# pts_time:59.195

# 場面の切り替え（弱い切り替えも）
ffmpeg -i "$V" -vf "select='gt(scene,0.08)',showinfo" -f null - 2>&1 | grep -o "pts_time:[0-9.]*" | tr '\n' ' '
# pts_time:7.39167 pts_time:25.4667 pts_time:33.07 pts_time:39.1 pts_time:42.3333 pts_time:42.5333 pts_time:52.5 pts_time:53.2667 pts_time:54.675 pts_time:55.2083 pts_time:56.5333 pts_time:57.3417 pts_time:57.4167 pts_time:57.8283 pts_time:57.8783 pts_time:57.9117 pts_time:58.02 pts_time:58.1367 pts_time:58.2033 pts_time:58.245 pts_time:58.2783 pts_time:58.3117 pts_time:58.345 pts_time:58.3783 pts_time:58.4117 pts_time:58.47 pts_time:58.5033 pts_time:58.5367 pts_time:58.57 pts_time:58.6117 pts_time:58.645 pts_time:58.6783 pts_time:58.7117 pts_time:58.745 pts_time:58.7783 pts_time:58.8367 pts_time:58.87 pts_time:59.195 pts_time:59.6867

# 大事な場面の 0.5秒ごとのコマ（24〜32秒、44〜52秒、35〜43秒）と、6.5〜8.5秒の 0.25秒ごとのコマ
ffmpeg -v error -ss 24 -t 8 -i "$V" -vf "fps=2,scale=205:-1,drawtext=text='%{pts\:hms}':x=4:y=4:fontsize=14:fontcolor=yellow:box=1:boxcolor=black" -frames:v 16 $S/g%02d.png
ffmpeg -v error -i $S/g%02d.png -vf tile=8x2 $S/sheetB.png
ffmpeg -v error -ss 44 -t 8 -i "$V" -vf "fps=2,scale=205:-1" -frames:v 16 $S/g%02d.png
ffmpeg -v error -i $S/g%02d.png -vf tile=8x2 $S/sheetC.png
ffmpeg -v error -ss 35 -t 8 -i "$V" -vf "fps=2,scale=205:-1" -frames:v 16 $S/g%02d.png
ffmpeg -v error -i $S/g%02d.png -vf tile=8x2 $S/sheetD.png
ffmpeg -v error -ss 6.5 -t 2 -i "$V" -vf "fps=4,scale=205:-1" -frames:v 8 $S/g%02d.png
ffmpeg -v error -i $S/g%02d.png -vf tile=8x1 $S/sheetE.png

# 元の大きさの静止画（機体の銘板・店員の手の位置を見るため）
for t in 0.5 7 15 16 17 27.5 28.5 29.5 33 38 41 42 43 44 45 46 47 50 52.5 54; do ffmpeg -v error -ss $t -i "$V" -frames:v 1 $S/hi/t$t.png; done

場面の切り替えは25秒・33秒・39秒・42秒付近にありました。切り替えの前後は時間が飛んでいるかもしれないので、秒数は「最低これだけかかった」という値として扱っています。58秒あたりの細かい切り替えは、画面収録の再生が最初に戻ったところです。

動画①のタイムライン：店員が来るまで41秒以上、直す作業は約5秒

止まり始めは映っていないので、止まってから店員が来るまでは41秒以上です。待っていた時間と直していた時間の比は、8対1以上になります。

最初の返事で Claude が挙げたのは、次の5つでした。

1. 時間の大半は「気づいて来るまで」。直す作業そのものは短い
2. ロボットの声かけが、動かせない人（お客さん）に向いている。店員への知らせは映っていない
3. 原因は通路の設計。1台しか通れない通路で反対向きの2台が鉢合わせした
4. 直すのは人の手。画面で止めて、手で押してどかす
5. 料理が遅れ、店員が謝ることになった。一方で猫のキャラクターのおかげで、トラブルが「面白い出来事」として受け止められ、笑える動画として投稿されている

運用の落とし所として、詰まりやすい場所をレイアウトで潰すこと（一方通行・すれ違える待避スペース・優先のルール）、止まったら店員の端末に知らせること、現場の誰でも5秒で直せる手順にすることの3つを挙げました。

動画①のメモを research フォルダに置いた

返事のあと、Mac の PixelstoMotors のフォルダをこの会話につなぎました。フォルダの中の research（調査メモの置き場）には、1件1ファイル、research_{テーマ}_{日付}.md という名前の決まりがあります。Claude はこの決まりに合わせて分析を research_serving_robot_deadlock_video_20261026.md として保存し、research/README.md の一覧に1行足しました。メモの全量は、記事の終わりの「調査メモと台帳の全量」に載せています。

作業ログ ― 動画の読み方を、毎回同じ手順にした

定期的に動画を共有するので、分析の型を決めた

メモを置いたあと、次のように伝えました。

定期的にロボットの動画を共有するのでそこから分析するようにしてください。 正確ではなくともどのような運用がされているか、問題点はあるか、どのくらい時間が掛かっているかなど参考になることはあると思います。

Claude は、毎回同じ項目を取り出せるように、手順をスキル（Claude に読ませる手順書）にまとめて提案し、私が保存しました。中身は6つの段階です。

あわせて、動画ごとの数字を1行ずつ並べる台帳 robot_video_ledger.md を research フォルダに作り、①の行を入れました。①のメモには、シミュレーションの前提との突き合わせの表を足しました。

• ねらい：動画を読むたびに項目がばらつかないようにし、数字を動画どうしで並べて比べられるようにする
• 変わったこと：手順をスキルにし、メモ1本・README に1行・台帳に1行を毎回の出力に決めた
• 見込める効果：動画が増えるほど、「人が来るまでの時間」や「直す作業の時間」が、止まった場所・止まり方ごとに数で並ぶ。シミュレーションに入れる値を、勘ではなく実物の幅から選べるようになる（何本たまれば値を選べるかは、まだ決めていない）

スキルの全量です。

SKILL.md（robot-video-ops-analysis）

---
name: "robot-video-ops-analysis"
description: "エイイチが共有した実物のロボット動画（配膳・清掃・案内など）から、運用の形・問題点・かかった時間を読み取り、research フォルダのメモと観察台帳に記録するときに使う。"
---

# ロボット動画の運用分析

エイイチが定期的に共有する実物のロボット動画（SNS の画面収録が多い）から、どう運用されているか、問題点はあるか、どのくらい時間がかかっているかを読み取る。正確でなくてよい。参考になる数字と運用の形を取り出し、積み上げることが目的。

## 1. 動画を手元に用意する

- チャットに添付された動画：添付のファイルをそのまま使う
- エイイチのMacにある動画：その動画だけを取り込む（device_stage_files）
- 作業用のファイル（コマ画像など）は作業用フォルダに置き、エイイチのフォルダには置かない

## 2. 動画を調べる

1. ffprobe で長さ・解像度・音声の有無を見る
2. 1秒ごとのコマに時刻を焼き込み、8×2 のコマ一覧にして全体を見る
   - `fps=1,scale=205:-1,drawtext=text='%{pts\:hms}':...` → `tile=8x2`
3. 場面の切り替えを探す：`select='gt(scene,0.08)'` と `gt(scene,0.25)` の両方で時刻を出す
   - 切れ目の前後は時間が飛んでいる可能性があると扱う
   - SNS の画面収録はループ（最初に戻る）を本編の終わりとみなす
4. 大事な場面（止まる・人が来る・人が触る・動き出す・届く）は 0.5秒ごとのコマ一覧と、元の解像度の静止画で細部を見る（機体の銘板、画面の操作、手の位置）
5. 字幕・画面の文字（投稿の題、店名、ロボットの声の字幕）も読む。音声がある場合は字幕・画面から読み、必要なら文字起こしを試す

## 3. 読み取る項目（毎回同じ型で）

- 場所・業態、機体（外見からの推定は「推定」と書く）
- 運用の形：受け渡しの方法、待機場所、人の役割、台数
- タイムライン（動画上の時刻と、起きていること）
- 時間の数字。次の区切りで分ける
  - 止まってから人が気づく・来るまで
  - 人の作業
  - 再開から完了（配膳完了など）まで
- 問題点：なぜ起きたか（通路・レイアウト・知らせ方・人の手順など）
- 運用の落とし所：今の技術のままで運用に耐える対策
- 確かさの注意：編集の切れ目、始まりが映っていない、など。秒数は基本「以上」（下限値）として扱う

推測は推測と書く。映っていないことを断定しない。

## 4. 導入シミュレーション（ServiceSim）の前提と突き合わせる

- 記憶の `/projects/019cdc43-e846-75bc-9842-110a87bf53ba/areas/service-robot-sim.md` を読み、最新の前提（立ち往生の線、回り込みの秒数、スタッフが代わりに運ぶまでの時間、通路幅、ロボットどうしの優先、人のよけ方など）と比べる
- 表（前提／動画で見えたこと／ずれ）にまとめる
- 記録だけにする。サイトの試算・Unity は変えない。Claude Code への指示も出さない。直すかどうかはエイイチが決める（サイトの試算が正）

## 5. 保存する

保存先：PixelstoMotors の research フォルダ
（Mac 上：`~/Library/Mobile Documents/com~apple~CloudDocs/デスクトップ/ADAPT DESIGN/じぶんの/PixelstoMotors/research`、device_bash では `$HOME/mnt/PixelstoMotors/research`）
フォルダがつながっていなければ、つなぐよう頼む。それまではメモをファイルで送る。

1. メモ：`research_{テーマ}_video_{YYYYMMDD}.md`（日付は見た日）。見出しの型：

```
# {タイトル} — 動画メモ

見た日 / 元（投稿者・題・画面収録の長さ） / 場所・機体
※ 確かさの注意

## 一言で
## タイムライン（動画上の時間）
## 数字（動画上）
## 読み取れること
## 運用の落とし所（このメモでの見立て）
## 導入シミュレーション（ServiceSim）の前提との突き合わせ
## Pixels to Motors との関係
## 次に確かめる候補
## 検索キーワード
```

   - 「エイイチの見立て」の欄は、本人から見立てを聞いたときだけ作る
2. `README.md` の一覧の表の最後に1行足す（ファイル・内容・原文「—」・日付）
3. `robot_video_ledger.md`（観察台帳）に1行足す：見た日／場所・業態／機体／起きたこと／止まってから人が来るまで／人の作業／再開から完了まで／誰が直したか／メモへのリンク

既存のファイルは足すだけにし、ほかの行は変えない。

## 6. 返事

短く、要点だけ。
- タイムラインの表
- 時間の数字（下限値であることを添える）
- 問題点と運用の落とし所
- シミュレーションの前提とのずれ（あれば）
- 保存したファイル名
- 過去の動画と比べて新しく分かったことがあれば一言（台帳を見て）

文章はやさしい日本語で、カタカナの専門用語はなるべく言い換える。

作業ログ ― ②③待機場所で出口をふさがれた動画と、卓での受け取りの動画

動画②③：同じ投稿者の2本（@d51498com）

翌朝、2本の動画を続けて共有しました。どちらも投稿者は @d51498com で、②は「通れなくてイライラ募らせる猫型配膳ロボット #shorts」（画面収録約64秒・本編約60秒）、③は「ガストの猫型ロボット #shorts」（画面収録約18秒・本編約15秒）です。ここからはスキルの手順で読んでいます。使ったコマンドの全量です。

S=/tmp/claude-0/-home-claude/e3b17bed-07d2-52f9-95cd-546f4ffee470/scratchpad; mkdir -p $S/v2 $S/v3; A=/mnt/user-data/attachments/e3b17bed-07d2-52f9-95cd-546f4ffee470; V2="$A/92899264-_____2026-10-27_7.50.23-compressed.mp4"; V3="$A/d8406634-_____2026-10-27_7.51.55-compressed.mp4"; for v in "$V2" "$V3"; do ffprobe -v error -show_entries format=duration:stream=codec_type,width,height -of compact "$v"; echo "cuts25:"; ffmpeg -i "$v" -vf "select='gt(scene,0.25)',showinfo" -f null - 2>&1 | grep -o "pts_time:[0-9.]*" | tr '\n' ' '; echo; echo "cuts08:"; ffmpeg -i "$v" -vf "select='gt(scene,0.08)',showinfo" -f null - 2>&1 | grep -o "pts_time:[0-9.]*" | cut -d: -f2 | awk '{printf "%.1f ",$1}'; echo; done
for n in 2 3; do eval v=\$V$n; ffmpeg -v error -i "$v" -vf "fps=1,scale=205:-1,drawtext=text='%{pts\:hms}':x=4:y=4:fontsize=16:fontcolor=yellow:box=1:boxcolor=black" $S/v$n/%03d.png; ffmpeg -v error -framerate 1 -i $S/v$n/%03d.png -vf tile=8x2 $S/v${n}_sheet%d.png; done

出力です。

stream|codec_type=video|width=410|height=720
format|duration=64.528333
cuts25:
pts_time:48.4083 pts_time:53.4117 pts_time:59.9867 
cuts08:
0.3 0.3 0.3 0.4 0.4 0.5 0.5 0.5 0.6 0.6 0.6 0.7 0.8 0.9 0.9 3.6 4.2 8.7 9.2 12.5 14.8 19.9 22.1 27.2 30.0 35.3 39.0 40.4 42.9 43.1 46.5 48.4 52.0 53.4 58.3 58.6 58.6 58.8 58.9 59.0 59.0 59.2 59.3 60.0 60.0 60.1 60.2 60.2 60.3 60.4 60.4 60.5 60.6 60.6 60.7 60.8 63.3 64.0 
stream|codec_type=video|width=410|height=720
format|duration=18.383333
cuts25:
pts_time:14.75 pts_time:15.3583 
cuts08:
5.1 5.2 5.2 5.4 5.5 5.6 5.7 5.7 5.8 5.9 6.0 6.1 6.2 7.7 8.2 10.5 10.8 10.8 10.9 11.2 11.2 11.3 11.6 11.7 11.8 12.0 12.1 12.2 12.3 12.4 12.4 12.5 12.6 12.8 12.8 12.9 12.9 13.0 13.2 13.3 13.3 13.9 14.4 14.7 14.8 15.4 

②の弱い切り替え（0.08）の多くは、字幕が入れ替わった所です。強い切り替え（0.25）は48秒・53秒にあり、60秒で最初に戻っています。0〜48秒は続いた映像として読みました。

②の45〜48秒は、店員の手が一瞬しか映らないので、0.25秒ごとのコマと、ロボットの画面の拡大で確かめました。

S=/tmp/claude-0/-home-claude/e3b17bed-07d2-52f9-95cd-546f4ffee470/scratchpad; A=/mnt/user-data/attachments/e3b17bed-07d2-52f9-95cd-546f4ffee470; V2="$A/92899264-_____2026-10-27_7.50.23-compressed.mp4"; cd $S; for t in 45.8 46.2 46.6 47.0; do ffmpeg -v error -y -ss $t -i "$V2" -frames:v 1 -vf "crop=200:140:100:180,scale=400:-1" h2/z$t.png; done; ffmpeg -v error -y -i h2/z45.8.png -i h2/z46.2.png -i h2/z46.6.png -i h2/z47.0.png -filter_complex hstack=4 zs.png; ffmpeg -v error -y -ss 38 -i "$V2" -frames:v 1 -vf "crop=410:300:0:420" zl.png
S=/tmp/claude-0/-home-claude/e3b17bed-07d2-52f9-95cd-546f4ffee470/scratchpad; A=/mnt/user-data/attachments/e3b17bed-07d2-52f9-95cd-546f4ffee470; V2="$A/92899264-_____2026-10-27_7.50.23-compressed.mp4"; cd $S; rm -f k*.png; ffmpeg -v error -y -ss 43 -t 6 -i "$V2" -vf "fps=4,scale=205:-1,drawtext=text='%{pts\:hms}':x=4:y=4:fontsize=14:fontcolor=yellow:box=1:boxcolor=black" k%02d.png; ffmpeg -v error -y -framerate 1 -i k%02d.png -vf tile=12x2 ksheet.png

画面の拡大で、45.8秒では猫の顔、46.6秒では水色の画面に「一時停止中」の文字が出ていました。46.2秒に青い手袋の手が映っています。

動画②のタイムライン：店員が来るまで45秒以上、画面の一時停止だけで直った

詰まった場所は、通路ではなく待機場所（ロボットが並んで次の仕事を待つ所）でした。並んだ機体どうしの隙間が、出入りの通り道も兼ねていたことになります。何が出口をふさいでいたかは確定できません。ロボットが隣の機体の名前を呼んでいるので隣の機体と推定しましたが、撮影している人が前に立っていた可能性も消せません。投稿者によると、前の日までは通れていたのに、この日は同じ所で何度も止まっていました。

動画③のタイムライン：客が画面を押してから約3秒で出発

受け渡しは「卓まで運び、客が自分で取り、画面を押して返す」形でした。卓番号を画面に大きく出して、料理の取り違えを防いでいます。機体は祭りの法被の柄の飾りを着ていました。料理を取る所は映っていないので、卓で止まっている時間のうち分かったのは、押してから動き出すまでの約3秒だけです。

作業ログ ― ④⑤ドリンクバーの前でぶつかった動画と、和食店の下げ膳の動画

動画④⑤：投稿者の違う2本

続けて共有した2本は、投稿者が別でした。④は「ガストでお馴染みの配膳ロボ『ベラボット』がぶつかった…」（投稿者 @rijise・画面収録約43秒・本編約40秒）、⑤は「【飲食店導入事例】陣笠さま - KEENON T9 Pro」（投稿者 @dfarobotics・画面収録約24秒・本編約21秒）です。⑤の投稿者は KEENON の販売会社と思われます。使ったコマンドの全量です。

S=/tmp/claude-0/-home-claude/e3b17bed-07d2-52f9-95cd-546f4ffee470/scratchpad; mkdir -p $S/v4 $S/v5; A=/mnt/user-data/attachments/e3b17bed-07d2-52f9-95cd-546f4ffee470; V4="$A/469ab7cb-_____2026-10-27_7.54.31-compressed.mp4"; V5="$A/05c586dc-_____2026-10-27_7.55.35-compressed.mp4"; for n in 4 5; do eval v=\$V$n; echo "== v$n"; ffprobe -v error -show_entries format=duration:stream=codec_type,width,height -of compact "$v"; echo -n "cuts25: "; ffmpeg -i "$v" -vf "select='gt(scene,0.25)',showinfo" -f null - 2>&1 | grep -o "pts_time:[0-9.]*" | cut -d: -f2 | awk '{printf "%.1f ",$1}'; echo; echo -n "cuts08: "; ffmpeg -i "$v" -vf "select='gt(scene,0.08)',showinfo" -f null - 2>&1 | grep -o "pts_time:[0-9.]*" | cut -d: -f2 | awk '{printf "%.1f ",$1}'; echo; ffmpeg -v error -i "$v" -vf "fps=1,scale=205:-1,drawtext=text='%{pts\:hms}':x=4:y=4:fontsize=16:fontcolor=yellow:box=1:boxcolor=black" $S/v$n/%03d.png; ffmpeg -v error -y -framerate 1 -i $S/v$n/%03d.png -vf tile=8x2 $S/v${n}_sheet%d.png; done; ls $S | grep "v[45]_sheet"

出力です（コマンドの中の v4 が⑤、v5 が④です）。

== v4
stream|codec_type=video|width=410|height=720
format|duration=24.183333
cuts25: 4.7 7.8 10.8 14.2 18.3 21.5 23.5 
cuts08: 2.7 4.7 7.8 10.8 10.8 14.2 18.3 21.5 23.5 
== v5
stream|codec_type=video|width=410|height=720
format|duration=42.716667
cuts25: 40.5 
cuts08: 26.3 26.5 26.6 26.6 26.7 26.7 26.7 40.5 
v4_sheet1.png
v4_sheet2.png
v5_sheet1.png
v5_sheet2.png
v5_sheet3.png

④は0〜40秒に切り替えがなく、26秒の細かい切り替えは人が横切った所でした。止まってから直るまでが1本の映像で続いているのは、5本の中で④だけです。⑤は約3秒ごとに場面が切り替わるので、時間は測れませんでした。

④の大事な場面は、0.5秒ごとのコマと、少し大きめの静止画で確かめました。

S=/tmp/claude-0/-home-claude/e3b17bed-07d2-52f9-95cd-546f4ffee470/scratchpad; A=/mnt/user-data/attachments/e3b17bed-07d2-52f9-95cd-546f4ffee470; V4="$A/469ab7cb-_____2026-10-27_7.54.31-compressed.mp4"; V5="$A/05c586dc-_____2026-10-27_7.55.35-compressed.mp4"; cd $S; rm -rf q; mkdir q; ffmpeg -v error -y -ss 5 -t 16 -i "$V5" -vf "fps=2,scale=205:-1,drawtext=text='%{pts\:hms}':x=4:y=4:fontsize=14:fontcolor=yellow:box=1:boxcolor=black" q/a%02d.png; ffmpeg -v error -y -framerate 1 -i q/a%02d.png -vf tile=16x2 v5a.png; ffmpeg -v error -y -ss 25 -t 16 -i "$V5" -vf "fps=2,scale=205:-1,drawtext=text='%{pts\:hms}':x=4:y=4:fontsize=14:fontcolor=yellow:box=1:boxcolor=black" q/b%02d.png; ffmpeg -v error -y -framerate 1 -i q/b%02d.png -vf tile=16x2 v5b.png; for t in 3.5 11.5 12.5 13.5; do ffmpeg -v error -y -ss $t -i "$V4" -frames:v 1 q/h4_$t.png; done; ffmpeg -v error -y -i q/h4_3.5.png -i q/h4_11.5.png -i q/h4_12.5.png -i q/h4_13.5.png -filter_complex hstack=4 v4h.png
S=/tmp/claude-0/-home-claude/e3b17bed-07d2-52f9-95cd-546f4ffee470/scratchpad; A=/mnt/user-data/attachments/e3b17bed-07d2-52f9-95cd-546f4ffee470; V5="$A/05c586dc-_____2026-10-27_7.55.35-compressed.mp4"; cd $S; rm -f q/r*.png; i=0; for t in 6 8 9.5 10.5 12 21 22.5 24.5 28 29.5 30.5 31.5 32.5 33.5 35 36.5 38 39; do i=$((i+1)); ffmpeg -v error -y -ss $t -i "$V5" -frames:v 1 -vf "scale=273:480,drawtext=text='$t':x=4:y=4:fontsize=20:fontcolor=yellow:box=1:boxcolor=black" q/r$(printf %02d $i).png; done; ffmpeg -v error -y -i q/r%02d.png -vf tile=9x2 v5c.png

動画④のタイムライン：店員が約18秒で来て、約10秒かけて2台を直した

店員が来るまでの時間は、①②の半分以下でした。止まった場所が、客も店員も通るドリンクバーの前だったからと推定しています。一方で、詰まりが2台にまたがっていたので、直す作業は3本の中でいちばん手間がかかっていました。ぶつかった瞬間ははっきり映っておらず、接触したのか、すぐ手前で止まったのかは確かめられません。

動画⑤：和食店で、下げ膳だけをロボットに任せていた

⑤は、石川県の和食料理「陣笠」の導入事例です。機体は KEENON T9 Pro（字幕と機体の銘板より）でした。

運用の形は、店員が座敷で器を下げてお盆ごとロボットに載せ、ロボットが洗い場まで運ぶものと推定しました（載せる場面は映っていません）。座敷の入口には段差と靴があり、ロボットは座敷に上がれません。料理を運ぶ所は人が受け持ち、重くてかさばる帰りの荷物だけをロボットに任せる分け方です。効果の言い分（席回転率・残業時間）は宣伝のもので、数字は出ていません。

下げ膳とピーク後の片付けについての私の見立て

⑤の分析で、Claude はシミュレーションの前提にないものとして、下げ膳だけをロボットに任せる店・座敷の店の形・ピーク以外の時間の使い方の3つを挙げました。それぞれについて、次のように返しました。

Unity の条件は「上げ膳だけ」だが、下げ膳だけをロボットに任せる店がある。 あるだろうね

店の形はファミレスの6つだけで、座敷の店がない。今はまだ座敷はいいや。

時間の区切りはピークの2時間だけで、閉店後の片付けのような使い方が入っていない。 バイトをしていた身からすると、ピークが終わって忙しさが落ち着く頃にまとめてお皿を下げるといったことはよくあった（人が少なかったりするとき）

ピーク中は、人もロボットも料理を運ぶので手一杯になり、下げ膳は後回しになります。そのぶん、下げていない卓がたまります。ピークが過ぎて人が減ったころに、たまった器をまとめて下げる。⑤の「1回にお盆3つ」は、この使い方に合っています。ロボットの効果は、ピーク中に店が回るかだけでなく、ピークのあと少ない人数で片付けが終わるかにも出るはずです。見立てはメモに書き足しました。試算と Unity は変えていません。

作業ログ ― 5本の動画と、シミュレーションの前提のずれ

台帳に並べて分かった：人が来るまでの時間は、止まった場所で違う

台帳の止まった3本を並べると、直す作業は1〜10秒、店員が来るまでは18秒〜45秒以上でした。店員が来るまでの時間は、止まった場所で違っていました。

直し方は3本とも違い、詰まりが2台にまたがると作業が長くなっていました。どこで止まったかと、そこが店員の目に入りやすいかを一緒に記録すると、店の形の評価に使えそうです。

シミュレーションの前提とのずれ（記録だけ）

5本で見えたずれを、前提ごとにまとめました。前提は、私が決めてきたシミュレーションの決まり（2026-10-27 時点）です。ずれは記録だけで、試算と Unity は変えていません。

次に確かめること

メモ5本の「次に確かめる候補」から、シミュレーションに関わるものを抜き出すと次のとおりです。

• 試算と Unity で、ロボットが止まってから人が来るまでの時間をどう置いているか
• BellaBot が止まってから回り込みを始めるまでの秒数（公表の仕様・設定）
• BellaBot が止まったときに、店員の端末へ知らせる機能の有無
• BellaBot の待機場所で必要な、機体どうしの間隔
• 受け取りの画面を押し忘れたとき、何秒で自動で戻るか

動画はこれからも共有して、台帳を伸ばしていきます。

調査メモと台帳の全量

ここからは、research フォルダに置いたファイルの全量です。メモは1本ごとに、動画1本の分析を、決めた見出しの型で書いています。

research_serving_robot_deadlock_video_20261026.md（①通路で向かい合った2台）

# 配膳ロボット2台の「お見合い」立ち往生と、店員の対応 — 動画メモ

見た日：2026-10-26
元：YouTube ショート（投稿者 @d51498com、題「お見合い立ち往生する猫型配膳ロボット #ガスト #ベラち…」）。エイイチの画面収録（約62秒、うち本編は約58秒でループ）を1秒ごと・0.5秒ごとのコマで確認した
場所・機体：ガストの店内。PUDU の猫型配膳ロボット BellaBot 2台（片方は頭の上にタッチパネルが付いた機体）

※ 編集済みの動画。25秒・33秒・39秒・42秒付近に場面の切り替えがあり、時間が飛んでいる可能性がある。冒頭の時点ですでに止まっている。以下の秒数は動画上の時間で、実際の時間はこれより長いと見るべき

## 一言で

1台分の幅しかない通路で、向かい合った2台がどちらも譲れず止まった。直す作業は店員の手で約5秒だったが、店員が来るまでに動画上だけで41秒以上かかっている。時間の大半は「止まったことが人に伝わるまで」に使われていた。

## タイムライン（動画上の時間）

| 時間 | 起きていること |
|---|---|
| 0:00〜0:25 | 2台が向かい合ったまま停止。ロボットはお客さんに向けて「仕事中だから通してほしいニャン」を繰り返す。近くの子どもが周りを歩き回る |
| 0:25〜0:31 | 片方がその場で向きを変えて抜け道を探すが、通路が狭く抜けられない |
| 0:37〜0:38 | 店員がトレーを持って横を通る。この時点では対応しない（別の作業中） |
| 0:41〜0:42 | 店員がロボットのところへ来る（対応開始） |
| 0:42〜0:47 | 店員がタッチパネルを操作し、片方を手で押してよける（手作業は約5秒） |
| 0:48〜0:52 | もう1台が動き出し、撮影者のテーブルに到着（約4〜5秒）。運んでいたのは撮影者の料理 |
| その後 | 店員がテーブルで「遅くなりまして申し訳ございません」と謝る |

## 数字（動画上）

- 止まってから店員が来るまで：41秒以上（始まりが映っていないので実際はもっと長い）
- 店員の手作業：約5秒
- 動き出してからテーブルに届くまで：約4〜5秒
- 待ち時間と作業時間の比：8対1以上

## 読み取れること

1. 時間がかかったのは「気づいて来るまで」。直す作業は短い。ロボットの性能より運用の作りの問題
2. ロボットの声かけが、動かせない人に向いている。「通してほしいニャン」はお客さんへの呼びかけで、お客さんには動かす権限も方法もない。知らせるべき相手は店員だが、店員に通知が届いた様子は映っていない（店員は手元の作業を終えてから来ている）
3. 原因は通路の設計。1台しか通れない通路で反対向きの2台が鉢合わせした。その場で向きを変えても抜けられない幅だった
4. 直すのは人の手。画面で止めて、手で押してどかす。PUDU 側の台数の多い店舗向けの機能が働いたかどうかは映像からは判断できない
5. 失敗の影響と猫キャラの効果。料理の提供が遅れ、店員が謝ることになった。一方で猫のキャラクターのおかげで、トラブルが「面白い出来事」として受け止められ、笑える動画として投稿されている。キャラクターが失敗の印象を和らげている

## 運用の落とし所（このメモでの見立て）

- 詰まりやすい場所をレイアウトで潰す：一方通行、すれ違える待避スペース、どちらが優先かのルール、狭い通路はロボットを通さない
- 止まったら店員に知らせる：「○秒以上止まったら店員の端末へ」のように、声かけの相手をお客さんから店員へ
- 現場の誰でも5秒で直せる手順にする：止める→押してどかす→再開、を全員ができるように

この3つがそろえば、今の技術のままでも十分に運用できる水準。

## 導入シミュレーション（ServiceSim）の前提との突き合わせ

記録だけ。サイトの試算・Unity は変えていない（直すかどうかはエイイチが決める）

| 前提（2026-10-25 時点） | この動画で見えたこと | ずれ |
|---|---|---|
| 立ち往生は30秒以上止まったら数える | 動画上41秒以上止まった | 30秒の線は実物でも越える。線として妥当 |
| 前がふさがって3秒空かなければ回り込む道を探す | 向きを変えて回り込もうとしたが、通路が狭く抜けられなかった | 回り込めない幅では、人が来るまで解けない |
| ロボットどうしが60秒向かい合う止まりは Unity の作りの問題 | 実物でも向かい合いが41秒以上続いた | 全部を作りの問題とは言い切れない。通路幅とすれ違いの条件次第で実物でも起きる |
| ロボットが詰まったら人がサポートする | 人の作業は約5秒。ただし来るまで41秒以上 | 試算・Unity で「人が来るまでの時間」をどう置いているかは確認していない |
| 通路幅の最低ラインは80cm（BellaBot の公表値） | ブース席とテーブルの間の1台分の通路で、すれ違えない | 実際の幅は動画からは測れない |

## Pixels to Motors との関係

- 導入シミュレーションで「止まる」を扱うときの実例。止まってから人が来るまでの時間と、人が直す時間を分けて考える材料になる
- research_robot_accident_liability_20261012.md（事故で誰に何が向いたか）とつながる。今回は事故ではないが、遅れの謝罪は店員が引き受けている
- 体験から逆算する設計思想の例：失敗をゼロにするより、失敗したときの体験（キャラクター、知らせ方、直し方）を設計する方が現実的

## 次に確かめる候補

- PUDU の配膳ロボットで、止まったときに店員の端末やスマートウォッチへ知らせる機能の有無と設定
- PUDU の複数台の調整機能（すれ違い・譲り合い）の公表仕様と、条件（通路幅など）
- BellaBot が通れる最小の通路幅と、すれ違いに必要な幅の公表値
- ガスト（すかいらーく）の配膳ロボット運用で、詰まり対策を公表しているか

## 検索キーワード

BellaBot すれ違い / 配膳ロボット 立ち往生 / PUDU multi-robot / 配膳ロボット 通路幅 / すかいらーく 配膳ロボット 運用

research_serving_robot_standby_blocked_video_20261027.md（②待機場所で出口をふさがれた）

# 待機場所で隣のロボットに道をふさがれた配膳ロボットと、店員の「一時停止」 — 動画メモ

見た日：2026-10-27
元：YouTube ショート（投稿者 @d51498com、題「通れなくてイライラ募らせる猫型配膳ロボット #shorts」）。エイイチの画面収録（約64秒、本編は約60秒でループ）を1秒・0.5秒・0.25秒ごとのコマで確認した
場所・機体：ファミレスのドリンクバーの横。後ろに食器の棚があり、ロボットの待機場所・受け渡し口の近くと推定。店名は動画に出ない（同じ投稿者はガストの動画を多く上げている）。PUDU BellaBot 2台が横に並んでいる

※ 編集済みの動画。48秒・53秒付近に場面の切り替えがある。冒頭の時点ですでに止まっている。何が道をふさいでいたかは映像からは確定できない（ロボットが隣の機体の名前を呼んでいるので隣の機体と推定。撮影している人が前に立っていた可能性も消せない）。以下の秒数は動画上の時間で、実際の時間はこれより長いと見るべき

research_serving_robot_table_handoff_video_20261027.md（③卓での受け取りから出発まで）

# 卓での受け取りから出発まで（祭りの法被を着た配膳ロボット） — 動画メモ

見た日：2026-10-27
元：YouTube ショート（投稿者 @d51498com、題「ガストの猫型ロボット #shorts」）。エイイチの画面収録（約18秒、本編は約15秒でループ）を1秒・0.5秒ごとのコマで確認した
場所・機体：ガスト（題より）の客席。PUDU BellaBot 1台。祭りの法被の柄の飾り（「祭」の文字）を着せている

※ トラブルの動画ではなく、ふだんの配膳の終わりの場面。料理を取る所は映っていない（冒頭で棚はすでに空）。秒数は動画上の時間

## 一言で

卓に着いたロボットの画面に卓番号（78）が出て、卓の人が画面を押すと、約3秒で動き出した。帰りは座っている客の肩のすぐ横を通って通路へ出ていった。

## タイムライン（動画上の時間）

| 時間 | 起きていること |
|---|---|
| 0:00〜0:01.5 | ロボットが卓の横に止まっている。画面に卓番号「78」と受け取りのボタン。棚はすでに空 |
| 0:01.5〜0:02.0 | 卓の人が手を伸ばして画面を押す |
| 0:02.5〜0:04.5 | 画面が笑顔の顔に変わる |
| 0:04.5〜0:05 | 向きを変えて動き出す |
| 0:05〜0:11 | 撮影している客のすぐ横（数十cm）を通り、通路へ出る |
| 0:12〜0:14 | 通路の様子。その後ループ |

## 数字（動画上）

- 画面を押してから動き出すまで：約3秒
- 卓に着いてから料理を取り終えるまで：映っていない

## 読み取れること

1. 受け渡しは「卓まで運び、客が自分で取り、画面を押して返す」形。前に共有された台湾の事例（BellaBot、焼肉店・空港の店）と同じ
2. 受け取りの終わりの合図は客の画面操作。押されるまでロボットは卓に残る。押し忘れたときにどうなるか（一定時間で自動で戻るか）は映っていない
3. 卓の番号を画面に大きく出して、料理の取り違えを防いでいる
4. 出ていくときに座っている客のすぐ横を通る。ぶつかってはいないが、客との間隔はかなり近い
5. 法被の飾りは季節の演出。猫の顔と合わせて、キャラクターとしての見せ方をしている

## 運用の落とし所（このメモでの見立て）

- 受け取りの合図を客に任せる形は店員の手を取らない。押し忘れに備えて、一定時間で自動で戻る設定があるかを確かめる
- 卓の横の止まる位置は、出るときに客の肩をかすめない向き・距離にする

## 導入シミュレーション（ServiceSim）の前提との突き合わせ

記録だけ。サイトの試算・Unity は変えていない（直すかどうかはエイイチが決める）

| 前提（2026-10-27 時点） | この動画で見えたこと | ずれ |
|---|---|---|
| L字の6人席では天板の正面の開いている側、端の席の人が受け取れる通路の端に止まってよい | 通路側の席の横に止まり、客が自分で取った | 止まり方は前提と同じ方向 |
| 受け取りにかかる時間（試算・Unity の値は今回確認していない） | 画面を押してから動き出すまで約3秒 | 「押す→出る」の約3秒は、卓での止まり時間の内訳の材料になる |
| 通路の真ん中寄りを走る | 卓から出るときは席のすぐ横を通る | 卓に出入りする所では、真ん中寄りにならない区間がある |

## Pixels to Motors との関係

- 卓での止まり時間を「料理を取る時間」と「押してから出るまで（約3秒）」に分けて考える材料
- 台帳（robot_video_ledger.md）の、トラブルのない回の基準になる

## 次に確かめる候補

- BellaBot の受け取り画面で押し忘れたとき、何秒で自動で戻るか（設定の有無）
- 卓の横で止まる位置と客との間隔の決め方

## 検索キーワード

BellaBot 受け取り 完了 ボタン / BellaBot 自動で戻る 時間 / 配膳ロボット 卓番号 表示 / ガスト 配膳ロボット 法被

research_serving_robot_bump_staff_fix_video_20261027.md（④ドリンクバーの前でぶつかった）

# ドリンクバー前でぶつかって止まった配膳ロボットと、店員の手直し — 動画メモ

見た日：2026-10-27
元：YouTube ショート（投稿者 @rijise、題「ガストでお馴染みの配膳ロボ『ベラボット』がぶつかった…」、字幕「ぶつかった！その後どうなる？」）。エイイチの画面収録（約43秒、本編は約40秒でループ）を1秒・0.5秒ごとのコマで確認した
場所・機体：ガスト（題より）。ドリンクバーと食器棚の前、客席から撮影。PUDU BellaBot。左に青い明かりの黒い台があり、もう1台のロボットと推定（後半で2台目が映る）

※ 0〜40秒は切れ目なく続いている（26秒の乱れは人が横切っただけ）。ぶつかった瞬間ははっきり映っていない（字幕で「ぶつかった」）。秒数は動画上の時間。配膳の完了までは映っていない

## 一言で

ドリンクバーの前で、もう1台のそばに寄って止まった。向きを変えようとする合図を出したが抜けられず、動画上で約18秒後に店員が来て、約10秒かけて手で向きを変え、画面を操作し、2台目も動かした。前の2本（店員が来るまで40秒以上）より早く人が来ている。

## タイムライン（動画上の時間）

| 時間 | 起きていること |
|---|---|
| 0:00〜0:09 | 奥の通路から1台が出てきて、撮影者の卓の前で向きを変える |
| 0:10 | 左の黒い台（もう1台のロボットと推定）のそばで止まる（字幕「ぶつかった！」） |
| 0:10〜0:20 | その場で止まったまま |
| 0:21〜0:25 | 背面に左向き「<<<<」、次に右向き「>>>>」の矢印を出し、少し向きを変える。抜けられない |
| 0:26 | 客が撮影者とロボットの間を横切る |
| 0:28 | 店員（黒い制服・マスク）が奥から来る |
| 0:29〜0:31 | 店員がロボットの頭に手を添え、手で向きを変える |
| 0:32〜0:34 | 店員が画面を操作する（画面が顔から操作画面に変わる） |
| 0:35〜0:38 | 店員がもう1台にも触れて位置を直す。2台とも顔の表示に戻る |
| 0:39〜0:40 | 店員が離れて見守る。ここでループ |

## 数字（動画上）

- 止まってから店員が来るまで：約18秒（10秒ごろに止まり、28秒に到着）
- 店員の作業：約10秒（手で向きを変える＋画面操作＋2台目の位置直し）
- 向きを変えようとした時間：約4秒（矢印の合図）
- 再開から完了まで：映っていない

## 読み取れること

1. 止まった場所はドリンクバーの前。客も店員も通り、ロボットも行き来する所。客が横切った2秒後に店員が来ている
2. 店員が来るまでが約18秒と、前の2本（41秒以上・45秒以上）より短い。ドリンクバーの前は店員の目に入りやすい所だからと推定
3. 直し方は3本目にして一番手間がかかった。手で向きを変える、画面を操作する、もう1台も動かす、の3つで約10秒。詰まりが2台にまたがると、両方を直す必要がある
4. ロボットは止まったあと、矢印の合図を出しながら向きを変えて抜け道を探している（前回の待機場所の動画では回り込まなかった）。ただし狭くて抜けられなかった
5. 撮影者の字幕は「ぶつかった」。接触したのか、すぐ手前で止まったのかは映像では確かめられない

## 運用の落とし所（このメモでの見立て）

- ドリンクバーの前のように人もロボットも集まる所は、ロボットの道を1本に決め、待機・すれ違いをさせない
- 店員の目に入る所で止まると早く直る（約18秒）。止まりやすい所を、店員がよく通る所に寄せる、という考え方もある
- 2台にまたがる詰まりの直し方（どちらを先に動かすか）を手順にしておく

## 導入シミュレーション（ServiceSim）の前提との突き合わせ

記録だけ。サイトの試算・Unity は変えていない（直すかどうかはエイイチが決める）

| 前提（2026-10-27 時点） | この動画で見えたこと | ずれ |
|---|---|---|
| ③⑦はドリンクバーを寄せ、回遊性を作らないと詰まる（2026-10-24） | ドリンクバーの前で詰まった | 実店舗でもドリンクバーの前は詰まりやすい所 |
| 立ち往生は30秒以上止まったら数える | 店員が来て直し終えるまで約28秒（止まってから） | 30秒の線の手前で直っている。早く人が来る所では、立ち往生として数えられない止まりもある |
| 前がふさがって3秒空かなければ回り込む道を探す | 約11秒止まってから向きを変え始めた（矢印の合図） | 実物は回り込みを始めるまでの待ちが3秒より長い可能性（この1本だけでは言えない） |
| ロボットが詰まったら人がサポートする | 人の作業は約10秒で、2台とも触った | 人の作業時間は、詰まりが1台か2台かで変わる |

## Pixels to Motors との関係

- 台帳（robot_video_ledger.md）で「人が来るまでの時間」が場所によって違う例が出た（通路・待機場所は40秒台以上、ドリンクバー前は約18秒）。止まる場所と、店員の目に入りやすいかどうかを合わせて記録すると、店の形の評価に使える

## 次に確かめる候補

- BellaBot の背面の矢印の合図が何を表すか（曲がる向き・回り込み中）
- BellaBot が止まってから回り込みを始めるまでの秒数（公表仕様・設定）
- ぶつかったときに止まる仕組み（バンパー・センサー）の公表仕様

## 検索キーワード

BellaBot 背面 矢印 ライト / BellaBot 回り込み 何秒 / BellaBot 衝突 停止 / ガスト ドリンクバー 配膳ロボット 詰まる

research_keenon_bussing_jingasa_video_20261027.md（⑤和食店の下げ膳）

# 和食店の下げ膳を任された KEENON T9 Pro（石川県「陣笠」の導入事例） — 動画メモ

見た日：2026-10-27
元：YouTube ショート（投稿者 @dfarobotics、題「【飲食店導入事例】陣笠さま - KEENON T9 Pro」）。投稿者は KEENON の販売会社と思われる。エイイチの画面収録（約24秒、本編は約21秒でループ）を1秒ごとのコマで確認した
場所・機体：石川県の和食料理「陣笠」（字幕より）。座敷の並ぶ店。KEENON T9 Pro（字幕と機体の銘板より）

※ 販売会社の宣伝動画。約3秒ごとに場面が切り替わるので、時間は測れない。効果（席回転率の向上、残業時間の削減など）は投稿者の言い分で、数字は出ていない

## 一言で

座敷の並ぶ和食店で、下げ膳（使った器を下げる仕事）をロボットに任せている。1回にお盆を3つ載せて、座敷の前の板張りの通路から洗い場まで運ぶ。閉店後の片付けにも使っている、という宣伝。

## エイイチの見立て（2026-10-27）

- 下げ膳だけをロボットに任せる店は、あるだろう
- 座敷の店の形は、今はまだシミュレーションに入れなくてよい
- アルバイトをしていた経験から：ピークが終わって忙しさが落ち着くころに、まとめてお皿を下げることはよくあった（人が少ないときなど）

## 場面（動画上の時間）

| 時間 | 映っていること |
|---|---|
| 0:00〜0:04 | 座敷の前の通路を走る T9 Pro。棚に食べ終わったお盆（器・箸・紙ナプキン）が載っている |
| 0:05〜0:07 | 障子の前の通路。字幕「石川県にある和食料理『陣笠』ではバッシングをロボットに任せています」 |
| 0:08〜0:10 | 座敷の入口の前を走る。字幕「一度に3つのお盆を運べるため、スタッフの身体的負荷は削減！」 |
| 0:11〜0:13 | 洗い場（緑のかご・重ねたお盆の横）に着く。字幕「バッシングのスピードもアップし、席回転率が向上」 |
| 0:14〜0:17 | 狭い通路に止まっている。字幕「閉店後の片付け作業もロボットでまとめて運べるから残業時間削減にも」 |
| 0:18〜0:20 | 字幕「飲食店のみなさま、ロボットで下げ膳業務を効率化しませんか？」 |

## 数字（動画上）

- 1回に運ぶお盆：3つ（字幕）
- 時間：測れない（場面が短く切り替わるため）

## 読み取れること

1. 運用の形は「店員が座敷で器を下げてお盆ごとロボットに載せ、ロボットが洗い場まで運ぶ」と推定（載せる場面は映っていない）。前に共有された台湾の事例の下げ膳の3通りのうち、「店員が卓で下げ、ロボットが洗い場へ運ぶ」と同じ形
2. 配膳ではなく下げ膳に絞っている。料理を運ぶ所は店員が受け持ち、重くてかさばる帰りの荷物をロボットに任せる分け方
3. 座敷の店は、座敷の前に板張りの通路が1本通る形。通路はロボット1台分ほどで、すれ違いは難しそう。座敷の入口には段差と靴があり、ロボットは座敷に上がれない。だから「座敷の入口まで人、そこから洗い場までロボット」という分け方になっていると推定
4. 閉店後の片付けにも使うという点は、ピーク時間以外の使い道。ピークの2時間だけを見ると見えない効果
5. 宣伝動画なので、うまくいっている所だけが映っている。詰まり・止まりは映っていない

## 運用の落とし所（このメモでの見立て）

- 座敷の店では、配膳より下げ膳の方がロボットに向く（料理を座敷の中まで運べないため、どちらにしても人の手が要る。帰りの重い荷物だけ任せる方が分担がはっきりする）
- 1本道の通路では、ロボットの台数を増やすより、1台で3つずつまとめて運ぶ方が詰まらない

## 導入シミュレーション（ServiceSim）の前提との突き合わせ

記録だけ。サイトの試算・Unity は変えていない（直すかどうかはエイイチが決める）

| 前提（2026-10-27 時点） | この動画で見えたこと | ずれ |
|---|---|---|
| Unity で回す条件は「上げ膳だけ」 | 下げ膳だけをロボットに任せる店がある | 下げ膳だけの条件は今のところない |
| 店の形はファミレスの6つ | 座敷の並ぶ和食店（板張りの1本道、段差と靴） | 座敷の店の形は前提にない |
| 時間の区切りはピークの2時間 | 閉店後の片付けにも使う（投稿者談） | ピーク以外の使い道は試算に入っていない |
| 1往復で何卓回すかは決めない（2026-10-25） | 下げ膳でお盆3つ＝3卓分をまとめて運ぶ | 下げ膳では「1往復で3卓」がそのまま実例になる |

## Pixels to Motors との関係

- 今後の拡張候補（KettyBot 型・宴会場）に加えて、「座敷の店の下げ膳」も候補になりうる材料
- 宣伝動画は、メーカー・販売会社がどこを売りにしているか（身体の負担・席の回転・残業）を知る材料。導入シミュレーションの LP の読み手（飲食店とメーカー・販売会社）に合わせた見せ方の参考になる

## 次に確かめる候補

- KEENON T9 Pro の公表仕様（積める重さ・棚の数・最小通過幅）
- 陣笠の導入事例の詳しい記事（販売会社のサイトなど）があるか
- 座敷の店での配膳ロボットの使い方の事例

## 検索キーワード

KEENON T9 Pro 下げ膳 / KEENON T9 Pro 仕様 通過幅 / 陣笠 配膳ロボット / 和食店 座敷 配膳ロボット / DFA Robotics 導入事例

robot_video_ledger.md（観察台帳）

# ロボット動画の観察台帳

共有された実物のロボット動画から読み取った運用と時間を、1動画1行で並べる。詳しくは各メモ（research_*_video_*.md）へ

- 秒数は動画上の時間。編集・切れ目・始まりが映っていないことが多いので、基本は下限値（「以上」）
- 機種は外見からの推定を含む

| 見た日 | 場所・業態 | 機体 | 起きたこと | 止まってから人が来るまで | 人の作業 | 再開から完了まで | 誰が直したか | メモ |
|---|---|---|---|---|---|---|---|---|
| 2026-10-26 | ガスト（ファミレス） | PUDU BellaBot ×2 | 1台分の通路で正面から向き合い立ち往生 | 41秒以上 | 約5秒（画面操作＋手で押してよける） | 約4〜5秒 | 店員（別の作業を終えてから） | [research_serving_robot_deadlock_video_20261026.md](research_serving_robot_deadlock_video_20261026.md) |
| 2026-10-27 | ファミレス（ドリンクバー横の待機場所。店名は不明） | PUDU BellaBot ×2 | 待機場所で並んだ隣の機体に出口をふさがれ、声かけを繰り返して停止。同じ日に何度も起きていた（投稿者談） | 45秒以上 | 1〜2秒（画面で一時停止） | 一時停止から約1秒で動き出す（完了は映っていない） | 店員 | [research_serving_robot_standby_blocked_video_20261027.md](research_serving_robot_standby_blocked_video_20261027.md) |
| 2026-10-27 | ガスト（ファミレス） | PUDU BellaBot ×1 | トラブルなし。卓で客が料理を取り、画面を押して返す | — | — | 押してから動き出すまで約3秒 | — | [research_serving_robot_table_handoff_video_20261027.md](research_serving_robot_table_handoff_video_20261027.md) |
| 2026-10-27 | ガスト（ドリンクバーの前） | PUDU BellaBot ×2 | もう1台のそばでぶつかって止まった（字幕より）。矢印の合図を出して向きを変えようとしたが抜けられず | 約18秒 | 約10秒（手で向きを変える＋画面操作＋2台目の位置直し） | 映っていない | 店員 | [research_serving_robot_bump_staff_fix_video_20261027.md](research_serving_robot_bump_staff_fix_video_20261027.md) |
| 2026-10-27 | 和食料理「陣笠」（石川県・座敷の店） | KEENON T9 Pro ×1 | トラブルなし（販売会社の宣伝動画）。下げ膳でお盆3つを洗い場へ運ぶ | — | — | 測れない（場面が短く切り替わる） | — | [research_keenon_bussing_jingasa_video_20261027.md](research_keenon_bussing_jingasa_video_20261027.md) |

research/README.md に足した行

一覧の表に5行と、台帳の節を足しました。

| [research_serving_robot_deadlock_video_20261026.md](research_serving_robot_deadlock_video_20261026.md) | ガストの配膳ロボット2台が狭い通路で向かい合って立ち往生した動画の分析：直す作業は約5秒、店員が来るまでが41秒以上。時間の大半は気づくまでに使われていた | — | 2026-10-26 |
| [research_serving_robot_standby_blocked_video_20261027.md](research_serving_robot_standby_blocked_video_20261027.md) | 待機場所で隣の配膳ロボットに出口をふさがれた動画の分析：店員が来るまで45秒以上、直す作業は画面の一時停止だけで1〜2秒。同じ日に何度も起きていた | — | 2026-10-27 |
| [research_serving_robot_table_handoff_video_20261027.md](research_serving_robot_table_handoff_video_20261027.md) | 配膳ロボットの卓での受け取りから出発まで：客が自分で取り画面を押す形、押してから約3秒で出発 | — | 2026-10-27 |
| [research_serving_robot_bump_staff_fix_video_20261027.md](research_serving_robot_bump_staff_fix_video_20261027.md) | ガストのドリンクバー前でぶつかって止まった配膳ロボットの分析：店員が来るまで約18秒（前の2本より早い）、手で向きを変え2台目も直して約10秒 | — | 2026-10-27 |
| [research_keenon_bussing_jingasa_video_20261027.md](research_keenon_bussing_jingasa_video_20261027.md) | 石川県の和食店「陣笠」の KEENON T9 Pro 導入事例（販売会社の宣伝動画）：座敷の店で下げ膳だけを任せ、お盆3つずつ洗い場へ | — | 2026-10-27 |

## ロボット動画の観察台帳

共有されたロボットの動画は、1本ごとに `research_{テーマ}_video_{YYYYMMDD}.md` にまとめ、数字は [robot_video_ledger.md](robot_video_ledger.md) に1行ずつ足す。