# ロボットが現場で止まる瞬間の図鑑

実店舗の動画では、直す作業は約1〜10秒。店員が来るまでは、約18秒、41秒以上、45秒以上かかっていました。  
配膳ロボット・病院の搬送ロボット・ロボットアームで見つけた、12の止まり方を集めました。  
止まった原因と、導入前に自分の現場で確かめる問いを、観察・シミュレーション・実機の記録から持ち帰れます。

## 止まったあと、誰の仕事になるか

### 01　店員が来るまで

**どんな現場で：飲食店／実店舗の動画観察**

**何が起きたか**  
店員が対応した動画3例では、直す作業は約1〜10秒でした。到着までは約18秒、41秒以上、45秒以上かかり、直す時間より、助けが来るまでの時間が長くなっていました。

**なぜ止まったか**  
狭い通路での向かい合いや、待機場所の出口をふさがれたことがきっかけです。声と赤い明かりは映っていますが、店員の手元に知らせが届いた様子は映っていません。通知機能の有無は未確認で、動画の編集もあるため、秒数は概算・下限です。

**入れる前に確かめること**

- 忙しい時間に止まったら、誰が、何で気づくか。
- 「止まってから人が着くまで」と「着いてから直すまで」を、分けて測れるか。

**出典：** [実店舗の動画をコマ送りで読んだ記録](/record/serving-robot-video-ledger)

**ハコブくん：**「直すのはすぐです。来てもらうまでが長いんです。」

---

### 02　2台目で待ちが延びる

**どんな現場で：28卓・スタッフ2人の飲食店／Unityのシミュレーション**

**何が起きたか**  
普通の混み具合で、入店待ちは1台の13.8分から、2台では25.1分へ延びました。昼のピーク2時間にスタッフがロボットを動かしに行く回数も、13回から54回に増えました。

**なぜ止まったか**  
2台とも近い方の狭い一本道を選び、向かい合ってふさぎ合っていました。「一本道は1台ずつ」にすると2台の入店待ちは17.6分まで縮みましたが、試した案では1台より短くなりませんでした。

数字は来客の並びを変えた10回の中央値です。ただし1台と2台にはシミュレーションの版の違いが残り、この結果をほかの店の台数上限にはできません。

**入れる前に確かめること**

- 2台目が加わると、どの一本道で出会うか。片方が待てる場所はあるか。
- 運ぶ量だけでなく、人が助けに行く回数と入店待ちも改善するか。

**出典：** [2台目と通行ルールを比べた記録](/record/serving-robot-one-per-narrow-restaurant)／[小さな店に2台を入れた記録](/record/small-store-second-robot-wait)

**ハコブくん：**「同僚が増えたら、店員さんを呼ぶ仕事が増えました。」

---

### 03　下げ膳中、通路をふさぐ

**どんな現場で：飲食店／Unityのシミュレーション**

**何が起きたか**  
6店・1〜2台・来客の並び10通りの比較では、下げ膳も任せると、スタッフの歩く距離は12条件すべてで減りました。一方、細い通路の2店では2台のとき、退店から卓が使えるまでが4.05分→6.05分、4.49分→8.06分に延びました。

**なぜ止まったか**  
下げ膳のロボットが卓に着き、スタッフを待つあいだに通路をふさいでいました。別の通路があれば回れますが、一本道ではほかのロボットも人も待たされます。

各条件1回の比較動画では、ゆとりのある店で入店待ちが縮み、細い店で延びました。ただし繰り返し集計では例外もあり、店の種類だけでは結果を決められません。

**入れる前に確かめること**

- 皿を載せる人が来ないあいだ、ロボットはどこで待つか。その横を通れるか。
- 歩く距離が減っても、次のお客さんを座らせるまでが延びていないか。

**出典：** [下げ膳を加えて繰り返し比較した記録](/record/serving-robot-sim-bussing-narrow-aisles)／[6店の比較動画](/record/serving-robot-bussing-depends-on-aisles)

**ハコブくん：**「お皿待ちのつもりが、通せんぼになってました。」

---

### 04　席は空いているのに案内できない

**どんな現場で：46卓・38卓の飲食店／試算とUnityの比較**

**何が起きたか**  
46卓の店では、0台・1台・2台と増やすと、入店待ちは8.1分→6.6分→5.5分に縮みました。それでも2台のとき、「席は空いているのに待った時間」が46卓の店で3.4分、38卓の店で3.5分残りました。

**なぜ止まったか**  
試算ではレジが詰まっていましたが、3Dの店では、スタッフが歩き回ることで片付けと案内が後回しになる、とログでは見ています。ここで止まっているのは、ロボットの車輪ではなく、次のお客さんを迎える仕事です。

各10回の中央値ですが、当時のシミュレーションには瞬間移動などの簡略化も残っていました。

**入れる前に確かめること**

- 運ぶ仕事が減った時間を、誰が片付けと案内に使えるか。
- 入店待ちのうち、満席で待つ時間と、席を使える状態にできず待つ時間を分けているか。

**出典：** [46卓の店で詰まる仕事を調べた記録](/record/large-store-cleanup-bottleneck)／[38卓の店と待機場所を調べた記録](/record/standby-jam-every-store)

**ハコブくん：**「運び終わりました。次のお客さんの席は、まだでした。」

## 通れる幅があっても、抜けられない

### 05　にらみ合い

**どんな現場で：飲食店／実店舗の動画観察とUnityのシミュレーション**

**何が起きたか**  
実店舗の動画では、待機場所の横で向かい合った2台が53秒以上進めず、店員が空の方を手でよけて約4〜5秒で解いていました。Unityの42卓・通路95cmの店では、2台が約9分10秒止まった例がありました。

**なぜ止まったか**  
Unityでは、両方が料理を載せている場合などに、どちらが譲るかを決められず、よけた先も相手の道の上でした。実店舗の機体内部の判断は未確認です。観察した詰まり動画は同じメーカーの少数例で、すべての機体に共通する結果ではありません。

Unityに店員が助ける決まりを入れると、この約9分の例は助け2回・約105秒で解けました。ただし、同じ台に何度も助けが必要になる問題も残りました。

**入れる前に確かめること**

- 両方が荷物を載せた状態で出会ったら、どちらが、どこまで下がるか。
- 自力で解けないとき、人が安全に解く手順を実際に試せるか。

**出典：** [実店舗で店員が解いた場面とシミュレーションの比較](/record/serving-robot-faceoff-staff-resolves)／[待機場所の横で向かい合った動画の観察](/record/serving-robot-jams-are-aisles)

**ハコブくん：**「お先にどうぞ。……その先に、ぼくがいます。」

---

### 06　待機場所へ戻れない

**どんな現場で：70卓・312席の飲食店／Unityのシミュレーション**

**何が起きたか**  
入店待ちは2台で11.7分、5台で17.2分でした。別の比較で、待機点へまっすぐ入る決まりにすると、待機場所付近の止まり合いは1営業あたり3,317秒→1,255秒に減りましたが、入店待ちは12.22分→14.90分に延びました。

**なぜ止まったか**  
0.8m間隔の待機点へ斜めに戻ると、隣で待つ台が前のセンサーに入り、止まっていました。人も待機点の区画を通らない形にすると、止まり合いは809秒まで減りました。

数字は各10回の中央値です。ただし、この作りには実機のような台どうしの順番決めが不足しており、5台の悪化をそのまま実店舗の予測には使えません。詰まりが減ることと、店全体の待ちが縮むことも別でした。

**入れる前に確かめること**

- 全台が待機しているところへ最後の1台が戻り、また出発できるか。人の通り道と重ならないか。
- 待機場所の停止時間を減らしたあと、片付けや入店待ちまで改善したか。

**出典：** [5台で待ちが延びた記録](/record/large-restaurant-five-serving-robots-longer-wait)／[斜めに戻る入り方を調べた記録](/record/serving-robots-jam-cause-standby-entry)／[人の通り道も変えた記録](/record/serving-robot-jam-three-rules)

**ハコブくん：**「駐車位置は空いてます。入る途中が空いてません。」

---

### 07　道を引き直しても詰まる

**どんな現場で：飲食店／Unityのシミュレーション**

**何が起きたか**  
決まった線だけを走る作りから、地図で道を引く作りに変えても、60秒以上の停止は57回→59回で減りませんでした。さらにドリンクバーを上へ0.5m、左へ0.8m動かして抜け道を作ると、20回になりました。

**なぜ止まったか**  
最初は、同じ線を往復するシミュレーション側の制約がありました。それを外しても、ドリンクバーと席の間が0.4mしかない行き止まりに詰まりが集中しました。道を探せても、抜け道そのものがなければ回れません。

同じ来客の並びで各1回の比較です。「地図を渡すだけで57回から20回になった」という結果ではありません。

**入れる前に確かめること**

- 道の引き方を変える前に、行き止まりと、そこで出会う往復の流れを確かめたか。
- シミュレーションで詰まった原因は、現場の配置か、再現する側が加えた制約か。

**出典：** [決まった線しか走れなかった作り](/record/serving-robot-fixed-route-jam)／[道の引き方とドリンクバー移動を分けた比較](/record/serving-robot-map-planner)

**ハコブくん：**「地図は読めます。壁の向こうには回れません。」

## 命令や学習の数字が良くても、仕事は終わらない

### 08　つかんだのに落とす

**どんな現場で：ロボットアーム／実機 mechArm 270**

**何が起きたか**  
つかんだブロックを落としていた実機で、電源を12V・2Aから12V・5Aへ替えると、同じモデル・同じ爪の設定・同じ位置で、成功は3回中1回から5回中5回になりました。ただし交換後も1回は人が持ち上げを補助し、爪の電流低下が残りました。

**なぜ止まったか**  
本体の表示は40Wでしたが、8か月使っていたアダプターは24Wでした。落とす前に爪の電流が0付近まで下がる記録と、交換後の変化から、ログでは電源不足が原因と判断しています。

交換費用はログ記載で3,355円。比較した日は異なり、電圧低下を直接測った記録はありません。交換後の5回成功も、全自動で問題が消えたという意味ではありません。

**入れる前に確かめること**

- 電源は、その機体が指定する電圧・電流・接続条件と合っているか。
- つかんで静止するだけでなく、持ち上げて運ぶ間も保持できるか。補助した回を分けて記録しているか。

**出典：** [ブロックを落とす直前の電流と電源を調べた記録](/record/mecharm-270-drops-block-underpowered-adapter)／[電源交換後の実機比較](/record/mecharm-270-5a-adapter-stops-dropping-block)

**ハコブくん：**「学習のおかわりより先に、電源を見てください。」

---

### 09　命令したのに、黙って動かない

**どんな現場で：ロボットアーム／実機 mechArm 270**

**何が起きたか**  
肩95.53〜99.22°の姿勢へ降りる命令は、エラーなしに6回とも動きませんでした。肩を87.27°にして教え直すと5回続けて成功し、一方で、動かなかった記録2本が台帳では「つかめた・箱に入った」と判定されていました。

**なぜ止まったか**  
公式の肩の範囲は−85°〜＋90°ですが、送る側のライブラリはそれより広い範囲を許していました。手で教えると範囲外まで倒せても、その姿勢への命令は実機で受け付けられませんでした。

本線には肩88°の上限がありましたが、再生用コードには入っていませんでした。88°は本線の設定値で、厳密に確かめた拒否境界ではありません。

**入れる前に確かめること**

- 教示・再生・本番で、同じ可動範囲の確認が働くか。
- 「命令を送れた」と「実際に動いて仕事を終えた」を、別々に確認しているか。

**出典：** [動かなかった角度・教え直し・台帳の誤判定の記録](/record/teach-replay-19-demos)

**ハコブくん：**「返事がないのを、了解にしないでください。」

---

### 10　学習の数字は良いのに空振り

**どんな現場で：ロボットアーム／π0.5を使った実機 mechArm 270**

**何が起きたか**  
2,000ステップ学習した実機は4回ともつかむ前に止まり、動画では爪がブロックの上に乗っていました。学習を4,000ステップに増やし、学習誤差が約0.0057から0.0030に下がっても、実機2回ともブロックの奥で爪を閉じました。

**なぜ止まったか**  
お手本19本は、ブロックをほぼ同じ場所に置いて集めていました。「いつもの場所へ手を伸ばす」だけでも学習誤差が下がるため、位置の違う場面に対応できたかは、その数字から分かりません。

ログでは位置の違うお手本が必要と判断し、その後5か所で19本を集めています。集め直したお手本で再学習した結果は、この材料には含まれていません。

**入れる前に確かめること**

- 学習に使っていない位置へ対象物を置いても、つかむ場所が変わるか。
- 学習誤差とは別に、実機でつかめた回数、箱まで運べた回数、人が補助した回数を数えているか。

**出典：** [最初の実機試行で爪が乗った記録](/record/pi05-mecharm-first-real-run)／[追加学習しても奥で空振りした記録](/record/pi05-mecharm-4000-steps)

**ハコブくん：**「いつもの場所は覚えました。今日のブロックは、そこですか？」

## 止まりを見つける仕組みも、確かめる

### 11　見張りが見ていたのは、画面の線

**どんな現場で：飲食店／Unityの録画を使った画像検知試験**

**何が起きたか**  
切り出した静止画1枚ずつで30秒以上の停止を見つける試験では、誤報5%の条件で、経路線ありは93件中67件、72%を拾いました。線なしでは94件中26件、28%でした。

**なぜ拾えなかったか**  
この方法は、ロボットだけでなく、画面上の経路線が交わる所を手がかりにしていました。実店舗のカメラにはその線が映らず、線を消した画像では、向かい合う2台と普段どおり並んで待つ2台を区別しにくくなりました。

撮り直しで動きも変わっており、同一場面から線だけを消した比較ではありません。実店舗のカメラ性能や、ほかの検知方法を測った結果でもありません。

**入れる前に確かめること**

- 検証画像に、本番のカメラには映らない表示が混ざっていないか。
- 「長く止まったこと」は機体の時刻付き記録で取り、画像と照らし合わせられるか。

**出典：** [経路線を消して検知率を測り直した記録](/record/serving-robot-jam-detection-without-path-lines)

**ハコブくん：**「ぼくの困り顔より、道の線を見てたんですね。」

---

### 12　病院を直したら、問題が増える

**どんな現場で：病院の搬送ロボット／Unityで作った仮の病院**

**何が起きたか**  
行き先へ歩いて行けなかった患者・職員41人を通れるようにすると、急停止・ひやり・人によけさせた等の問題が1日84件→132件に増えました。職員の行き先と動き方を直すと19件まで減りましたが、さらに患者などの動きを補うと51件になりました。

**なぜ止まったか**  
職員141人を「1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動かしていました。付き添いのために通れるようにした場所へ、職員が普段も行くようになり、ロボットと出会う回数が増えていました。

これは実際の病院職員の動きではありません。主に同じ来客・移動の並び1通りでの比較で、19件は通り抜ける人を十分に動かせていなかった段階の値です。また、件数は衝突事故の数ではありません。

別の経路比較では、混む外来の大廊下を避けると問題が減る一方、届くまでの時間は延びました。何を減らし、何を受け入れるかを分ける必要があります。

**入れる前に確かめること**

- 職種ごとの持ち場・用事・付き添いを、実際の運用に照らしたか。「仮」で置いた動きがどれか分かるか。
- 問題が減ったのは、人を通れなくしたからではないか。必要な人と荷物が目的地へ着いているか。

**出典：** [外来の廊下を避ける経路の比較](/record/hospital-transport-robot-avoid-outpatient-hall)／[通れる場所を直して問題が増えた記録](/record/hospital-transport-robot-blocked-paths-more-conflicts)／[職員の仮の動きと、その後の測り直し](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)

**ハコブくん：**「毎時間くじ引きで出張する病院だとは聞いてません。」

## 自分の現場では、何を確かめるか

この図鑑は、人が助けるまでの時間から始め、台数と仕事の増やし方、通路と待機場所、実機の命令と学習、最後に測り方そのものへ進む順に並べました。導入後に誰の手が必要になるかを先に決め、そのうえで、台数や機能を足す判断へ進むためです。

トライアルでは、走れた場面に加えて、**止まってから仕事が終わるまで**を残してください。自分の現場で気になった項目を選び、次の欄を埋めて持ち帰れます。

| 残すこと | 書く内容 |
|---|---|
| 起きた条件 | 場所、混み具合、台数、荷物、人の作業 |
| 待った時間 | 停止、気づき、人の到着、復帰の各時刻 |
| 人がしたこと | 画面操作、移動、積み下ろし、持ち上げなど |
| 仕事の結果 | 届いたか、卓が使えたか、次の人を案内できたか |
| 変えて比べること | 台数、配置、通行ルール、待ち方などを一つずつ |

人が手を貸して完了した回は、その手間も含めて導入の結果です。

外の導入事例にも、止まった後の扱いが判断材料になった例があります。京都大学医学部附属病院の事例では、従来の搬送機は停止すると検体の取り出しに業者が必要だった一方、廊下を走るロボットなら人が取り出せることが、検討の背景として説明されています。復旧や取り出しのしやすさも、導入前に確かめたい条件です。［[パナソニック コネクトの導入事例](https://connect.panasonic.com/jp-ja/case-studies/kyoto-university-hospital)、公開日記載なし・2026年11月14日確認］

原因を整理するときは、「見る・位置を知る・決める・動く」のどこで止まったかに加え、誰が載せ、受け取り、助けるかという運用も見ます。この分け方は[ログでの考察](/record/serving-robot-stops-four-stages-stanford)であり、各機体の内部原因を確かめた分類ではありません。

店の形・人数・台数を変えて考えるには、[配膳ロボットの導入シミュレーション](/series8)へ。

自分の現場で確かめたい止まり方や、共同で検証したい条件は、[メッセージフォーム](/message)へ。