# 制作の依頼：「ロボットが現場で止まる瞬間の図鑑」のページを書く

## 何を作るか（エイイチと決めたこと）
配膳ロボット・病院の搬送ロボット・ロボットアームが、現場で「止まる瞬間」を1つずつ集めた図鑑のページ。
シミュレーション（Unity で再現した店や病院）と実機（mechArm 270）と実店舗の動画の観察で見つけた、12の止まり方を載せる。
1つの止まり方に、ハコブくん（このサイトの薬剤搬送ロボットのキャラクター）の一言を付ける。

## 誰に
ロボットの導入を判断する経営者と、導入を任された PM（飲食・病院・物流など）。
フィジカルAI という言葉に反応しているのは主にこの人たちで、関心は技術そのものより「導入の判断」と「実験止まりで終わらせないこと」にある。
この人たちが知りたいのは、カタログや営業資料には書いていない「入れてから分かること」。

## このページで達成したいこと
- 読んだ経営者・PM が「入れる前に、これを確かめないといけない」と分かり、自分の現場の確かめ方を持ち帰れる
- 「この人は、現場で本当に止まる所を測っている」と伝わり、導入の相談や共同の検証の話につながる（相談の窓口はメッセージフォーム /message だけ。ページの最後に1行置くのはよい）

## 12の止まる瞬間（出典は 材料/ フォルダのログ全文。ページの /record/ リンクは右の名前を使う）
| # | 止まる瞬間 | 要点（ログの要約から。数字は 材料/ の本文で確かめること） | 材料のファイル → /record/ |
|---|---|---|---|
| 1 | 店員が来るまで | 実店舗の動画で、止まったロボットを直す作業は1〜10秒、店員が来るまでは18〜45秒以上 | LOG391 → serving-robot-video-ledger |
| 2 | にらみ合い | 狭い通路で2台が向かい合うと、ロボットどうしでは解けず、実店舗でも店員が手で片方をどかしていた | LOG434 → serving-robot-faceoff-staff-resolves、LOG400 → serving-robot-jams-are-aisles |
| 3 | 2台目が待ちを延ばす | 通路の狭い28卓の店で2台にすると入店待ちが約2倍。1台が上限 | LOG423 → serving-robot-one-per-narrow-restaurant、LOG393 → small-store-second-robot-wait |
| 4 | 待機場所の止まり合い | 5台にすると入店待ちが延びた。原因は待機点へ斜めに寄る入り方。決まりを変えて減らした | LOG452 → large-restaurant-five-serving-robots-longer-wait、LOG456 → serving-robots-jam-cause-standby-entry、LOG465 → serving-robot-jam-three-rules |
| 5 | 下げ膳で詰まる | 下げ膳も任せると、通路にゆとりのある店では待ちが縮み、効率重視の細い店では延びた | LOG440 → serving-robot-sim-bussing-narrow-aisles、LOG444 → serving-robot-bussing-depends-on-aisles |
| 6 | 詰まるのは片付け | ロボットを足しても、詰まるのはレジではなく片付けと案内だった | LOG397 → large-store-cleanup-bottleneck、LOG398 → standby-jam-every-store |
| 7 | 線に縛ると詰まる | 決まった線しか走らせない作りが詰まりの元。地図を渡すと60秒の止まりが57回から20回に | LOG370 → serving-robot-fixed-route-jam、LOG374 → serving-robot-map-planner |
| 8 | 直したら衝突が増えた | 病院で通れない所を直すと、搬送ロボットの問題が増えた。元は病院の職員の仮の動きだった | LOG477 → hospital-transport-robot-avoid-outpatient-hall、LOG488 → hospital-transport-robot-blocked-paths-more-conflicts、LOG491 → hospital-transport-robot-conflicts-came-from-placeholder-staff-moves |
| 9 | カメラでは見つからない | 録画から長い止まりを見つける試しで、画面のロボットの道の線を消すと、拾えた割合は72%から28%に | LOG418 → serving-robot-jam-detection-without-path-lines |
| 10 | まさかの電源不足 | ロボットアームがブロックを落とす原因は電源。12V・2A を 5A に替えると落とさなくなった | LOG487 → mecharm-270-drops-block-underpowered-adapter、LOG504 → mecharm-270-5a-adapter-stops-dropping-block |
| 11 | 命令が黙って捨てられる | 肩を約88°より深く倒す命令が、エラーなしに捨てられた | LOG352 → teach-replay-19-demos |
| 12 | 学習の数字は良いのに外れる | 学習の誤差（loss）は下がっても、実機では爪が奥で空を閉じた | LOG345 → pi05-mecharm-first-real-run、LOG348 → pi05-mecharm-4000-steps |
参考：止まり方を「見る・位置を知る・決める・動く」の4段で分けた考察 LOG439 → serving-robot-stops-four-stages-stanford

## ページの形（この順で書く）
1. 見出しと、その下の3行（このページが何で、読むと何が分かるか。実際の文面で）
2. 12の止まる瞬間。1つごとに次をそろえる
   - 名前（短く、現場の言葉で）
   - どんな現場で（店・病院・アーム）
   - 何が起きたか（ログの数字で。1〜2文）
   - なぜ止まったか（原因）
   - 入れる前に確かめること（読む人が自分の現場で確かめる問いを1〜2個）
   - 出典（/record/… へのリンク）
   - ハコブくんの一言（その止まり方を、ロボットの側から一言で。くすっとさせつつ本質を突く）
3. 12を並べる順番と、まとめ方（作者が決めてよい。いちばん刺さる順に並べる）
4. 終わりに：読む人が次にすること（自分の現場で確かめる／シミュレーションのページを見る／/message に1行）

## 守ること
- 12項目の事実と数字は、ログにあることだけ。外の情報（ニュース・調査）は「なぜこれが経営者に効くか」を伝える文脈として使ってよいが、出典と日付を付ける
- シミュレーションの結果を、実店舗で必ず起きることのように言わない。「シミュレーションでは」「実店舗の動画では」「実機では」を書き分ける
- 新しいキャッチコピーや肩書きを作らない。メーカーや店を悪く言わない