24本のログ（約1.5MB）を4つに分けて、それぞれ全文を読む作業を並行で進めています。結果が出そろったら、こちらでも主要な数字を本文と突き合わせてから、12項目の材料にまとめます。 Items 1〜3 checked. Waiting for the remaining three readers. # ログを読む人からの材料：止まる瞬間 12項目 `材料/` にあるログ24本と参考の LOG439 を全文読みました。作業は4つに分けて並行で読み、主な数字と引用は本文の該当行で照らし合わせてあります。依頼の表の要点がログ本文と違う所は、各項目の「⚠」に書きました。 --- ## 1. 店員が来るまで ［実店舗の動画］ - **何が起きたか**：SNS の実店舗の動画5本をコマ送りで読みました。止まった3本はすべて BellaBot で、ほぼガストです。 - 通路で2台が向かい合った：店員が来るまで41秒以上、直す作業は約5秒 - 待機場所で出口をふさがれた：45秒以上、直す作業は1〜2秒（画面で一時停止） - ドリンクバーの前でぶつかった：約18秒、直す作業は約10秒 - まとめると「店員が来るまで18秒〜45秒以上、直す作業1〜10秒」です。1本目は待った時間と直した時間の比が「8対1以上」でした。 - **なぜ止まったか**：直接の原因は、1台分の幅で向かい合ったことと、隣の機体に出口をふさがれたことです（隣の機体と推定）。店員がなかなか来なかったのは、ロボットの声かけと赤い明かりがお客さん向けの合図だったからです。「店員の手元に知らせが届いた様子は、どの動画にも映っていませんでした」。 - **直したか**：直していません（記録だけ）。対策の案（店員の端末へ知らせる、誰でも5秒で直せる手順など）は挙がっていますが、効果は測っていません。 - **驚くこと**：直すのは数秒なのに、店員が気づいて来るまでにその何倍もかかる。 - **出典**：LOG391 の冒頭、「### 動画①のタイムライン：店員が来るまで41秒以上、直す作業は約5秒」「### 台帳に並べて分かった：人が来るまでの時間は、止まった場所で違う」 - ⚠ 動画は編集されているので、秒数は下限です。店員の端末に知らせる機能があるかどうかは確かめていません。のちの LOG400 で4本目（53秒以上）が加わり、幅は「18〜53秒以上」になりました。 ## 2. にらみ合い ［実店舗の動画＋シミュレーション］ - **何が起きたか** - 実店舗の動画（LOG400）：和食の店で KettyBot 2台が待機場所の横で向かい合いました。「2台とも完全には止まらず、その場で向きを変え続けていた」。53秒以上進めず、店員が空の方を手で寄せて約4〜5秒で解けました。 - シミュレーション（LOG434）：42卓・通路95cm の店⑦でロボット2台を走らせました。受け渡し口の右下で「約9分10秒」止まり、その間スタッフが同じ卓へ運ぶのを5回あきらめました。 - **なぜ止まったか** - どちらが譲るかの決まりについて、ログには「どのメーカーも公式には公開していませんでした」とあります。取扱説明書で分かるのは、すれ違えない幅では交互に通すこと（すれ違いに要る幅は PUDU が1.6m超、KEENON T8 が1.5m超）と、待ってから道を組み直すこと（BellaBot Pro の初期値は30秒）だけでした。 - Unity のロボットは、2台とも料理を載せているとき（または2台とも空のとき）、どちらが譲るかを決められません。さらに、よけた先が相手の道の上でした。 - **どう直したか**：Unity に「30秒動けなければ近くの店員が来て、着いてから15秒で空の方を動かす」決まりを入れました。約9分の止まりは「助け2回・約105秒」で解けました（⑦・種7で1回）。ただし、止まっている台に助けが何度も要るという新しい詰まりが出ました。 - **驚くこと**：ロボットどうしの譲り合いの決まりを、どのメーカーも公開していない。集めた実物の動画は、どれもロボットだけでは解けていなかった。 - **出典**：LOG434「### 調べて分かったこと：取扱説明書に書いてある決まりは2つだけ」「### ⑦の店で、1号機と2号機が約9分止まっていた記録」「### 9分のにらみ合いは、助け2回・約105秒で解けた」、LOG400「### 「止まっている」のに、その場では動き続けていた」 - ⚠ 動画4本はすべて PUDU 製です。「1台分の通路で正面から向き合う」に当たるのはガストの1本だけで、ほかは待機場所での止まりやぶつかりです。待機場所の1本は画面操作だけで直っていて、手でどかしてはいません。「どちらが譲るか決まっていないように見える」はログの推測です。 ## 3. 2台目が待ちを延ばす ［シミュレーション］ - **何が起きたか**：店④（28卓・88席、スタッフ2人、昼のピーク2時間）での結果です。 - 2台にすると、入店待ちは「1台のときの約2倍（13.8分 → 25.1分）」になりました。 - スタッフが動かしに行く回数は「13回から54回」に増えました。 - 4回の夜すべてで、10種中9〜10種の入店待ちが延びました。 - **なぜ止まったか**：「ロボットどうしが1本道で向かい合ってふさぎ合うこと」です。下の通路は約1.1m、使われていない上の通路は約2.1m で、2台とも近い方の狭い道を選んでいました。止まった相手はロボットが354回、立ち止まった人が159回です。 - **どう直したか**：3つの案を試しました。 - 案B「1本道は1台ずつ」：入店待ち25.1→17.6分、動かしに行く回数53.5→29.0回 - 案A「一方通行」：混んでいるときは56.5分で、悪くなった - どの案でも「2台目は、決まりを工夫しても1台を超えませんでした」。ログの結論は「狭い店は1台から始める」です。 - **驚くこと**：この店では1台目でも入店待ちは縮まず（0台13.0分 → 1台13.8分）、2台目でほぼ倍になった。1台目で得られるのは、スタッフの歩く距離が約3割減ることだった。 - **出典**：LOG423 の冒頭、「### 1台と比べると、どの案でも2台は1台に届かなかった」「## 狭い店の配膳ロボットについて、店に伝えられること」、LOG393「### ロボットを入れても、④では入店待ちが縮まなかった」 - ⚠ 13.8→25.1分は約1.8倍で、1台と2台では Unity の作りの版が違います（ログ自身が「きっちりそろえてはいません」と書いています）。混んでいるときは約1.4倍です。他の店（⑤⑥）では2台で待ちが縮んでいるので、「狭い店はどこでも1台が上限」とは言えません。LOG393 は、直したあとに残った待ちの多くを「片付けと案内が追いつかない時間」としています。 ## 4. 待機場所の止まり合い ［シミュレーション］ - **何が起きたか**：大型店⑧（70卓・312席、スタッフ6人）で台数を変えました。入店待ちは0〜3台で11.5〜11.7分、4台で13.2分、5台で17.2分です。差がいちばん開いた30分では次のようになりました。 - ロボットどうしで止まった時間：2台の67秒 → 5台の1,163秒 - 片付けのスタッフが道をあきらめた回数：8回 → 34回 - **なぜ止まったか**：「待機点どうしの間は0.8mしかなく、ロボットの前のセンサー（中心から0.85m）が隣の待機点の台に届く。戻る台は斜めに寄ってくるので、隣の台がセンサーに入り、止まります」。道を探した結果の87〜98%は道が引けていました。道はあるのにセンサーで止まっていた、ということです。 - **どう直したか** - 待機点の真下1.0m からまっすぐ入る決まりにしました。待機場所のそばの止まり合いは、1回の営業あたり3,317秒 → 1,255秒に減りました。 - 加えて人が待機点の区画を通らないようにすると、809秒になりました。店員が呼ばれる回数は180回 → 22回、スタッフの手が空いている割合は20.3% → 38.6% です。 - 別の直し（近くの店員がすぐ押す）で、入店待ちは17.56 → 11.32分になりました。 - **驚くこと**：場所を広げなくても、入り方を「斜め」から「真下からまっすぐ」に変えるだけで、止まり合いが約6割減った。 - **出典**：LOG452「### 大型店の入店待ち（10種の中央値・分）」と依頼96の節、LOG456 の冒頭と「依頼104」「依頼114」の節、LOG465「依頼119」の節 - ⚠ ログは、5台で待ちが延びたのは「店の問題を写したというより、Unity のロボットに台どうしの順番決めがないことが大きく出た結果」と書いています。5台の映像は「店で起こる場面としては見せられない」として載せていません。まっすぐ入る決まりだけでは、入店待ちは12.22 → 14.90分に**延びました**。「決まりを変えて待ちが減った」とは書けず、正しくは「止まり合いが減った」です。 ## 5. 下げ膳で詰まる ［シミュレーション］ - **何が起きたか**：6店 × 1〜2台 × 10種の、計120回を回しました。 - スタッフの歩く距離は12条件すべてで減りました。 - 通路の細い店で2台のとき、お客さんが帰ってから卓が使えるまでの時間が延びました。③は4.05 → 6.05分、⑦は4.49 → 8.06分です。 - **なぜ止まったか**：「下げ膳のロボットが卓に着いてスタッフを待つあいだ、通路が1本ふさがり、ほかのロボットとスタッフが回り道をするか待つことになります」。通路にゆとりのある⑤では「別の通路を回って行けます」。 - **どう直したか**：卓で待つのは2分までにして、待っている台も助けで動かしてよいことにしました。解けずに残った詰まりは53件 → 4件、全員が帰れなかった回は4回 → 1回になりました。卓が使えるまで延びる問題そのものは直していません。 - **驚くこと**：スタッフの歩く距離はどの店でも減るのに、細い通路の店では次のお客さんを座らせるまでが約2倍に延びた（⑦）。 - **出典**：LOG440 の冒頭、「## 作業ログ ― 依頼90・91：Unity の配膳ロボットに下げ膳を入れた」、LOG444 の冒頭と「## 作業ログ ― 6店の比較動画」 - ⚠ 依頼の表の「ゆとりのある店では待ちが縮み、細い店では延びた」は、LOG444 の店ごと1回の録画の結果です。ログ自身が「店ごとの答えを言い切ることはできません」と書いています。10種の中央値で確かなのは「歩く距離は減る」と「③⑦の2台で卓が使えるまでが延びる」の2つです。④は人手不足が原因で、中央値では待ちが縮んでいます。 ## 6. 詰まるのは片付け ［シミュレーションと試算の比較］ - **何が起きたか** - ⑤（46卓、スタッフ4人）：3Dの店の会計待ちは6〜7分でした。一方、席は空いているのに待った時間は0台6.5分（試算1.5分）、1台4.6分（試算0.8分）、2台3.4分（試算0.7分）です。 - ⑥（38卓）：会計待ちは3分前後でした。席は空いているのに待った時間は、試算の2.0〜5.5倍です。 - **なぜ止まったか**：試算では、食べ終えた客がレジを待つあいだ卓に座ったままなので、レジが詰まります。3Dの店ではスタッフが歩き回るぶん手がふさがり、後回しになる片付けがたまっていました（③⑦では1組あたりの仕事が試算より約1割長い）。⑤⑥について、ログは「同じことが起きていると見ています」と書いています。 - **どう直したか**：このずれ自体は直していません（記録だけ）。直したのは店の形で、ロボットの道を広げました。それでも⑥の2台では、待機場所の中で60回止まり、そのうち59回の相手はもう1台のロボットでした。 - **驚くこと**：計算ではレジが詰まるはずなのに、実際に動かすと詰まっていたのは「席は空いているのに、片付けと案内が追いつかない」時間だった。 - **出典**：LOG397 の冒頭と「### 試算はレジで詰まり、3Dの店は片付けと案内で詰まる」、LOG398 の冒頭と「## 作業ログ ― ⑥を種10個ずつ、計30回回した」 - ⚠ ロボットを足すと入店待ちは**縮んでいます**（⑤8.1→6.6→5.5分）。席は空いているのに待った時間も、0台がいちばん長いです。「ロボットを足すと片付けが詰まる」ではなく、「待ちの元はレジではなく片付けと案内」が正確です。当時の版には瞬間移動が残っていました。 ## 7. 線に縛ると詰まる ［シミュレーション］ - **何が起きたか**：店③で2台を走らせると、60秒止まった回が58回あり、そのうち51回の相手はもう1台のロボットでした。行き止まりで向かい合ったまま600秒で打ち切りになった回もあります。 - **なぜ止まったか**：Unity のロボットは「サイトから渡された道の線の上しか走れません」。卓ごとの最短の1本を行き帰りに共用していて、42卓の道のうち23本が同じ通路を通っていました。ログはこれを「現実にない制約」と書いています。実機は地図の上で道を引いて回り込みます。 - **どう直したか**（③・2台・種0、各1回） - 地図で道を引けるようにしただけ：60秒の止まりは57 → **59回で、減りませんでした**。59回のうち43回が右下の行き止まりに集まっていました（ドリンクバーと6人席の間が0.4m）。 - さらにドリンクバーを上へ0.5m・左へ0.8m動かした：**20回**。ロボットが運んだ割合は64.4% → 99.4%、料理の待ちは2.90 → 1.17分（試算は1.01分）。 - **驚くこと**：賢い道の引き方を渡しても詰まりは減らず、ドリンクバーを数十cm動かして行き止まりをなくしたら3分の1になった。 - **出典**：LOG370「## ロボットどうしの詰まり：店の形ではなく、ロボットを線に縛った作りが根本だった」、LOG374「## 1回目（ドリンクバーを動かす前）」「## 2回目（ドリンクバーを動かした後）」 - ⚠ 依頼の表の「地図を渡すと57回→20回」は2つの直しを1つにまとめていて、言い過ぎです。比べたのはどれも1回ずつです。「線に縛る」はシミュレーションの作りの問題で、実機の不具合ではありません。 ## 8. 直したら問題が増えた ［シミュレーション・仮の病院］ - **何が起きたか**：病院 h1 で、行き先へ歩いて行けなかった41人（患者と職員）を通れるように直しました。するとロボットの問題（急に止まった・ひやり・人がよけさせられた など）は、1日84件 → 132件に増えました。増えた48件のうち37件は大廊下の東の端で起き、相手はほとんどが職員でした。 - **なぜ止まったか** - 直接の原因（LOG488）：付き添い用に「入れる」ようにした所へ、職員がふだんの行き来でも行くようになりました。たとえば検査技師が救急の処置の場所へ行く回数が0 → 46回になりました。 - 根本の原因（LOG491）：Unity の職員141人を「1人が1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動かしていました。 - **どう直したか** - 職員の行き先を持ち場に限る：132 → 68件 - 職員を持ち場ごとの4つの型で動かす：68 → **19件**。そのうち職員が相手だったのは2件で、車いすの患者が動けなかった時間は最長663.8秒 → 20.3秒になりました。 - ただしその後、患者の動きを入れると19 → 51件に増えました。条件がそろった数としては、ログは51件の方を挙げています。 - **驚くこと**：数えていたロボットの問題の大半は、ロボットではなく「人の動きの仮置き」が作っていた。 - **出典**：LOG488「### ロボットの問題は1日84件から132件に増え、37件は大廊下の東の端で起きた」「### 増えた原因は、通り抜けのために足した所が…」、LOG491 の冒頭、「### 職員は5つの役割とも、1時間に1回のくじ引きで科をまたいでいた」「### 走っている間の問題は68件から19件になり…」「### 採血の所に最大41人が集まり…」 - ⚠ 数えているのは「衝突」ではなく「問題」です。止まりきれなかったのは132件中10件だけです。「病院の職員の仮の動き」とは**シミュレーションの中の**仮の決まりのことで、実際の病院の話ではありません。比べたのは主に種0の1回で、種8では56 → 260件とぶれが大きいです。 ## 9. 映像からは見つからない ［シミュレーションの録画］ - **何が起きたか**：Unity の店③を真上から撮った録画を使いました。ロボットのまわりを切り出した静止画1枚ずつを、画像の異常検知（PatchCore）で判定し、30秒以上の長い止まりを拾えるか試しました。誤報5%のしきい値で、拾えた割合は次のとおりです。 - 道の線あり：72%（67/93） - 道の線なし：28%（26/94） - ロボットどうしの詰まり：線ありの23/43 → 線なしの4/47 - **なぜ拾えなかったか**：線ありで光っていたのは、画面に描かれた道の線が交わる所でした。この線は実際の店のカメラには映りません。線がないと、向かい合う2台は「白い丸が2つ並ぶだけ」で、待機場所で2台が並ぶ普段の絵と区別がつきません。30秒続くかどうかの見分けは0.51で、偶然と同じでした。 - **どう直したか**：検出の力は直していません。録画から線を消す切り替えを足して、正しく測り直しました。次の案として、止まった時間はロボットの記録から取り、画像は原因の場所を示す役にする、が挙がっています。 - **驚くこと**：シミュレーションで8割拾えた画像のAIは、本物のカメラには映らない画面上の線を手がかりにしていた。 - **出典**：LOG418 の冒頭、「### 線を消すと、長い止まりを拾えた割合は72%から28%に落ちた」「### 線がないと、ロボットどうしの詰まりとスタッフとのすれ違いは拾えない」 - ⚠ 実際のカメラ映像ではありません。試した方法も1つだけです。「カメラでは見つからない」は言い過ぎで、言えるのは「静止画1枚の異常検知では長い止まりを拾えない」までです。お客さんとのすれ違いは線なしでも13/17拾えています。 ## 10. まさかの電源不足 ［実機 mechArm 270］ - **何が起きたか**：位置5 のブロックを9回中2回しか運べず、その2回も人が手を貸しました（閉じる値20）。つかんだあと11〜19秒で爪の電流が0付近に落ち、ブロックを落としていました（17本中12本）。閉じる値を25に下げると止まっている間は持ちましたが、アームが動き出すとまた力が抜けました。 - **なぜ止まったか**：本体の求める電源は40W（説明書は8.4V・5A）です。つないでいたのは外付けディスク用の12V・2A（24W）で、「本体が求める40W の6割しかありません」。箱にアダプターが入っておらず、あとから別送されたもので、**8か月分の実機の記録はすべてこの電源で取っていました**。LOG487 の時点では推測で（電圧は測っていない）、LOG504 で差し替えて確かめました。 - **どう直したか**：12V・5A（3,355円）に替えました。AI（π0.5）で位置5・閉じる値25を比べると、成功は3回中1回 → **5回中5回**、人の直しは3回中3回 → 5回中1回になりました。教えた動きの再生も7回すべて成功しました。 - **驚くこと**：AI の学習の問題に見えた失敗の正体は、8か月使っていた付属外のアダプターで、3,355円で直った。 - **出典**：LOG487「## 位置5 の失敗は、つかんだあとに爪の力が抜けて落としていた」「## mechArm 270 の電源は40W、つないでいたアダプターは24W だった」、LOG504「### 12V・2A の日の3回と、つかんでいる間の爪の電流を並べた」 - ⚠ 比べたのは3回と5回で、日も違います。5A でも1回、持ち上げた瞬間に電流が落ちています（ブロックは落ちていない）。電圧が下がったことを直接測った記録はありません。 ## 11. 命令が黙って捨てられる ［実機 mechArm 270］ - **何が起きたか**：手で教えた動きを再生すると、つかむ位置へ降りる命令が「6回送って6回とも無視」されました（教えた肩の角度は95.53〜99.22°）。エラーは出ず、動いた角度は最大1.50°で、止まっているときの揺れと同じくらいです。さらに、動いていない2本が台帳に「つかめた yes・箱に入った yes」と記録されていました。 - **なぜ止まったか** - メーカー公式の肩の範囲は−85°〜+90°です。送る側のライブラリは±190°でしか確かめないので、範囲外の命令もそのまま送られ、アーム側で黙って捨てられていました。 - 本線のコードには LOG257 から上限88.0°が入っていましたが、再生用のコードには入っていませんでした。 - 手で教えるときはモーターの力が抜けているので、人は99°まで倒せてしまいます。 - **どう直したか**：肩を倒さずに、肘と手首で下げるように教え直しました（肩87.27°）。5回再生して5回とも成功しました。再生の前に肩の角度を確かめる手順も足しました。 - **驚くこと**：ロボットはできない命令を受けてもエラーを返さず、黙って動かない。しかも記録の上では「成功」になっていた。 - **出典**：LOG352 の冒頭、「## 位置2：肩 95° を超える教え方では、つかむ命令が6回とも全く動かなかった」「## 肩の上限 88° は、本線の fk_lookup.py には LOG257 から入っていた」「## 肩を倒さずに教え直すと、肩 87.27° で5回続けて成功した」「## 使わない3本：台帳の判定が実際と違う」 - ⚠ 捨てられたと確かめたのは95.53°以上だけです。88°は本線が安全のために置いた値で、本線では89.73°で止まった例もあります。「88°を超えると捨てられる」とは言い切れず、「約88°より深く」はログの表現どおりにとどめるのが安全です。 ## 12. 学習の数字は良いのに外れる ［実機 mechArm 270 / π0.5］ - **何が起きたか** - 2,000ステップ：loss（学習の誤差）は0.1155 → 0.0057 まで下がりましたが、実機4回は4回とも、つかむ前に止まりました（爪がブロックに乗った。ずれは2〜3cm）。 - 4,050ステップ：loss は0.0030 まで下がりましたが、実機2回とも「ブロックの奥の何もない所でグリッパーを閉じた」。 - つかむ瞬間の土台と肩の角度は、3回ともほぼ同じで、どれもお手本の範囲の外でした。 - **なぜ止まったか**：お手本19本は、ブロックをほぼ同じ場所に置いて集めたものです。そのため「画像を細かく見なくても『いつもの場所へ手を伸ばす』だけで loss は下がります」。LOG348 では「お手本と同じ場面では当たるようになっていても、それが実機の別の場面でも当たるかは、loss からは分かりません」と書いています。 - **どう直したか**：学習を倍にしても、手を伸ばす先は変わりませんでした。「足りないのは学習の回数ではなく、ブロックの位置が違うお手本です」。次の手として、5か所19本のお手本を集めることにしました（LOG352）。それで学習し直した結果は、材料のログには入っていません。 - **驚くこと**：学習の誤差がほぼ半分になっても、アームが手を伸ばす先は変わらなかった。 - **出典**：LOG345「## loss はまだ下がっていたので…」「## 動画で見ると、手前の爪がブロックの上に乗っていた」、LOG348 の冒頭、「## 4,000ステップまでの loss は…」「## 実機の1回目は、ブロックの奥でグリッパーを閉じた」「## つかむ瞬間の土台と肩の角度は…」 - ⚠ 「空を閉じた」のは4,000ステップの方です。2,000ステップでは爪がブロックに乗って止まっていました。実機は4回と2回だけです。LOG345 では、原因の見立てを2回外しています（熱、指令の小ささ）。 ## 参考：4段の分け方（LOG439） スタンフォード大学の講義 AA274A（Marco Pavone、2019年秋の収録、2026年10月に無料公開。Lecture 1）にある「見る → 位置を知る → 決める → 動く」で、観察台帳の止まり方を分けた考察です。 - 見る：ぶつかって止まる - 位置を知る：迷子 - 決める：向かい合い、出口をふさがれる - 動く：その場で向きを変えても抜けられない - 4段の外（運用）：下げた皿を載せたままになる ログは「どれも、このときの見立てで、機体の中身は公開されていません」と断っています。 --- ## 12項目を通して見えること - 多くの止まりで、ロボットそのものは壊れていませんでした。止めていたのは通路の幅・行き止まり・待機場所の間隔・ドリンクバーの位置（1, 2, 4, 7）、人の動かし方と人手（6, 8, 5）、電源や角度の上限（10, 11）です。直す手も、ロボットの性能ではなく、置き方・決まり・部品の側にありました。 - 「直す作業は数秒、気づくまでは数十秒」「エラーを出さずに黙って止まる」「学習の誤差は下がるのに外れる」「シミュレーションで8割拾えたのは画面の線のおかげ」（1, 11, 12, 9）。どれも、止まったことが**数字や画面に出てこない**種類の止まりです。経営者・PM にとっては、「何を測れば気づけるか」が入れる前に確かめる中心になります。 - 「足せば良くなる」が何度も外れています。2台目・5台目・学習の回数・賢い道の引き方・通れる所を直す、の5つです（3, 4, 12, 7, 8）。どこが詰まりの元かを測ってから足す、という順番が12項目に共通しています。 - 書き手への注意：12のうち7つ（3〜9）はシミュレーションで、多くは1回か種0の比較です。ログ自身が「Unity の作りの弱さが出た」と書いている所もあります（4, 7, 8）。実店舗の動画（1, 2）は PUDU 製の数本だけです。実機（10〜12）は回数が少ないものの、原因と直した後の変化がいちばんはっきりしています。