# 案C への評：止まりが数字や画面に出てこないことを、冒頭の切り口にする 案Cは、作者がまとめの節に書いた「止まったことが数字や画面に出てこない」がいちばん鋭いところです。経営者や PM がこのページで初めて得るのは、この点と、それを自分の現場で測る方法です。ところが、この点は最後に置かれていて、冒頭の3行は誰でも書ける一般論になっています。各項目も、照合のときに安全な言い方に寄せた結果、ログにある強い数字が抜けています。作者の切り口はそのまま使い、見せる順番と数字を強くする方向で、指摘を8つ挙げます。 - **いちばん刺さる項目：1「店員が来るまで」。** 唯一の実店舗の数字で、経営者が自分の店の人手に置き換えて読めます。直す作業は1〜10秒なのに、店員が来るまでは18〜45秒以上かかっています。 - **いちばん弱い項目：6「詰まるのは片付け」。** 確かめる問いが「片付けの手は足りていますか」で、営業資料にも書いてある助言と変わりません。直し方は指摘3に書きます。 --- ## 指摘1　冒頭の3行と並べ方：結論を先頭に移す **問題** - 「見落とされた物理法則」は、ログにない言い方です。 - 「カタログには『障害物を避けて走る』と書かれていますが」は出典がありません。Gemini の材料もすべて「未確認」です。 - 数字が1つもなく、読む人が何を持ち帰れるのかが分かりません。 - 並べ方が依頼の表の順のままです。依頼は「いちばん刺さる順」でした。 **書き換えた文面（見出しはそのまま）** > 配膳ロボット・病院の搬送ロボット・ロボットアームが止まった12の場面を、実店舗の動画、Unity で再現した店と病院、実機の mechArm 270 から集めました。 > 多くはロボットが壊れたのではなく、通路の幅、待機場所の間隔、人の動き、電源で止まっていました。しかもその止まりは、画面にも記録にもすぐには出てきません（実店舗の動画では、直す作業は1〜10秒、店員が来るまでは18〜45秒以上）。 > 1つごとに、入れる前や試しに入れている間に、あなたの現場で数えること・確かめることを付けています。 **並べ方の案**（まとめの節にある作者自身の3つの見立てを、そのまま見出しに使います） 1. **止まっても気づけない**：1 → 11 → 12 → 9 2. **壊れていないのに止まる**：2 → 10 → 7 → 6 3. **足すと・直すと悪くなる**：3 → 4 → 5 → 8 それぞれのまとまりで、実店舗と実機の項目を先に置きます。シミュレーションだけの3は、最後のまとまりに回します。 ## 指摘2　いちばん刺さる1は、問いを「数えること」に変える 「誰の端末に通知が来るか」は営業担当に聞けば済む問いです。この項目にしかない価値は、**待っている時間と直す時間の差**にあります。 > **何が起きたか**：実店舗の動画で店員が対応した3例では、直す作業は約1〜10秒でした。店員が来るまでは約18秒、41秒以上、45秒以上かかっています。1本目は、待った時間と直した時間の比が8対1以上でした（動画は編集されているため、秒数は下限です）。 > **入れる前に確かめること**：試しに入れている間、止まってから店員が来るまでの秒数を数えてください。直す作業との差が、お客さんから見たロボットの止まり時間です。止まったという知らせは、店員の手元に届く仕組みですか。 ハコブくんの一言は今のままで十分よいです。 ## 指摘3　いちばん弱い6は、試算と実際の差を数字で示す ログで新しいのは「片付けが大事」という話ではなく、**計算ではレジが詰まるはずだったのに、動かしてみたら片付けと案内が詰まっていた**という点です。導入の効果を試算する経営者には、そのまま効きます。 > **名前**：計算ではレジ、実際は片付け > **どんな現場で**：シミュレーション（Unity の46卓の店、スタッフ4人） > **何が起きたか**：表計算の試算では、ロボット2台のとき「席は空いているのに待つ時間」は0.7分でした。同じ店を Unity で動かすと3.4分です（約5倍。ログの数字から計算）。ロボットを0→1→2台と足すと、入店待ちは8.1→6.6→5.5分と縮みました。それでも、この待ちは残りました。 > **なぜ止まったか**：試算では、食べ終えたお客さんが卓に座ったままレジを待つので、レジが詰まります。3Dの店では、スタッフが歩き回るぶん手がふさがり、後回しになった片付けがたまっていました（③⑦では1組あたりの仕事が試算より約1割長い）。 > **入れる前に確かめること**：導入の効果を見積もった計算には、スタッフが歩く時間が入っていますか。ピークの時間に、空いているのに案内できない卓が何卓あるか数えてください。 > **ハコブくん**：「計算ではレジが混むはずだったんですけど、実際は片付け待ちでした」 ## 指摘4　11と12：同じ問題の2つの顔として、事実を正して強くする **11の事実のずれ** - 「6回とも動かず、台帳には『成功』と記録」と書くと、6回すべてが成功と記録されたように読めます。ログでは、成功と記録されたのは**動いていない2本**です。 - ハコブくんの「記録には『成功』って書いときますね」は、ロボットが記録を書き換えたように読めます。直します。 - いちばん持ち帰れる原因が抜けています。**命令を送るソフトが確かめる範囲と、機体が動ける範囲がずれていた**ことです。 > **何が起きたか**（11）：肩95.53〜99.22°へ降りる命令を6回送り、6回とも動きませんでした。エラーは出ず、動いたのは最大1.50°で、止まっているときの揺れと同じくらいです。しかも、動いていない2本は台帳に「つかめた・箱に入った」と記録されていました。 > **なぜ止まったか**：メーカー公式の肩の範囲は−85°〜+90°です。送る側のライブラリは±190°でしか確かめないため、範囲外の命令もそのまま届き、アーム側で黙って捨てられていました。手で教えるときはモーターの力が抜けているので、人は99°まで倒せてしまいます。 > **入れる前に確かめること**：命令を送るソフトが確かめる範囲は、機体が動ける範囲と同じですか。「成功」という記録は、実際に動いたことを何で確かめていますか（映像、角度の記録）。 > **ハコブくん**：「できない角度だったので、黙って動きませんでした。エラーを出す決まりはなかったので」 **12の問いの誤り** 「シミュレーションや AI の学習の数字」と書かれていますが、loss はシミュレーションの数字ではありません。 > **入れる前に確かめること**：お手本や試験は、置き場所を変えた場面を含んでいますか。学習の数字ではなく、置き場所を変えた実機での成功回数で判断していますか。 > **何が起きたか**に足す一文：学習を2倍にしても、手を伸ばす先は変わりませんでした。足りないのは学習の回数ではなく、ブロックの位置が違うお手本でした。 ## 指摘5　10は「推測」ではない。3,355円と8か月を書く LOG487 の時点では推測でしたが、LOG504 で**差し替えて確かめて**います。経営者の記憶に残るのは、金額と期間です。 > **何が起きたか**：つかんでから11〜19秒後に爪の電流が0付近まで落ち、ブロックを落としていました（17本中12本）。電源を12V・2A から12V・5A（3,355円）に替えると、同じ AI・同じ条件で、成功は3回中1回から5回中5回に、人の手直しは3回中3回から5回中1回になりました。 > **なぜ止まったか**：本体が求める電源は40W です。つないでいたのは外付けディスク用の12V・2A（24W）で、6割しかありませんでした。アダプターは箱に入っておらず別送で、8か月分の実機の記録はすべてこの電源で取っていました。差し替えて確かめましたが、電圧そのものは測っていません。 > **入れる前に確かめること**：届いた機体の電源の出力（W）は、説明書の値に足りていますか。箱に入っていなかった部品を、手元のもので代わりにしていませんか。 > **ハコブくん**：「8か月、腹ぺこで働いてました。3,355円でやっと満腹です」 ## 指摘6　シミュレーションの4・5・7は、いちばん確かな数字に入れ替える **7：名前と中身が合っていない** 今の本文は「地図を渡しても減らなかった」と書いているので、名前の「線に縛ると詰まる」と食い違います。 > **名前**：ドリンクバーの横の行き止まり > **何が起きたか**：同じ店で道の引き方を賢くしても、60秒の止まりは57→59回で減りませんでした。59回のうち43回は、ドリンクバーと6人席の間（0.4m）の行き止まりに集まっていました。ドリンクバーを上へ0.5m、左へ0.8m動かすと20回になり、ロボットが運んだ割合は64.4→99.4%、料理の待ちは2.90→1.17分になりました（どれも1回ずつの比較）。 > **入れる前に確かめること**：止まった場所を記録して地図に落とすと、どこかに集まっていませんか。そこにある家具は動かせますか。 **4：減ったものと、延びたものを両方書く** 「短くならなかった」は弱めすぎです。 > **何が起きたか**：大型店で5台にすると入店待ちが17.2分に延びました。ただしログは、Unity のロボットに台どうしの順番決めがないことが大きく出た結果としています。待機点へ真下1.0m からまっすぐ入る決まりにすると、待機場所の止まり合いは3,317秒から1,255秒に減りました。一方、この変更だけでは入店待ちは12.22→14.90分に延びています。さらに人が待機点の区画を通らないようにすると、止まり合いは809秒、店員が呼ばれる回数は180→22回になりました。 > **入れる前に確かめること**：待機点どうしの間隔は何m ですか。ロボットの前のセンサーが届く距離（このシミュレーションでは中心から0.85m。待機点どうしの間隔は0.8m）より広いですか。 **5：各1回の録画ではなく、10種の中央値で言えることだけを使う** > **何が起きたか**：6店、1〜2台、10種で計120回を回しました。スタッフの歩く距離は、12条件すべてで減りました。一方、通路の細い店で2台のときは、お客さんが帰ってから卓が使えるまでの時間が、③で4.05→6.05分、⑦で4.49→8.06分（約1.8倍）に延びました。 > **入れる前に確かめること**：下げ膳のロボットが卓で待つあいだ、その通路を人が回り道できますか。卓が空くまでの時間を、入れる前と後で測っていますか。 ## 指摘7　8は、話の後半がいちばん大事 84→132件で止めると、読む人は「病院の動線は危ない」と受け取ります。ログが伝えているのは、**ロボットの問題の件数は、人の動きをどう置いたかで何倍にも変わる**ということです。シミュレーションの数字を見せられる立場の経営者にとって、いちばん効く話です。 ハコブくんの「事故が起きやすい道」は事実と違います。止まりきれなかったのは132件中10件で、増えた原因は仮に置いた職員の動きでした。 > **何が起きたか**：通れなかった41人を通れるように直すと、ロボットの問題（急に止まった・ひやり など）は1日84件から132件に増えました。増えた48件のうち37件は大廊下の東の端で起き、相手はほとんどが職員でした。シミュレーションの職員141人は、「1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動いていました。行き先を持ち場に限ると68件、持ち場ごとの4つの型にすると19件になりました。その後、患者の動きを入れると51件です（主に種0の1回の比較で、種によって大きくぶれます）。 > **入れる前に確かめること**：シミュレーションや試験運用で示された「ロボットの問題○件」は、人の動きをどう決めて数えたものですか。 > **ハコブくん**：「僕のひやりの大半は、くじ引きで部屋を選ぶ仮の職員さんが相手でした」 ## 指摘8　終わりの節：出典のない引用と、相談の呼びかけを外す - 「Web記事、2026年7月1日」は、どのサイトか書かれていないので出典になりません。このページは自分で測った数字だけで十分強いので、削ります。 - 「思い込みを捨て」は読む人を説教する言い方です。事実の数え上げに替えます。 - 「私たちにご相談ください」と「原因不明の止まりを検証」は、相談の窓口を2行に広げています。決まりは最後に1行です。 > 12のうち5つは、足したり直したりして、悪くなったか変わらなかった記録です（2台目、5台目、学習の回数、道の引き方、通れる所を直す）。どこで詰まっているかを数えてから足す、という順番が、12の記録に共通しています。 > > 次にすること：各項目の「入れる前に確かめること」のうち、待機点の間隔（4）と、止まりが集まる場所（7）は、入れる前から測れます。止まってから店員が来るまで（1）は、試しに入れている間に数えられます。シミュレーションの店の作りは、各項目の /record/ から見られます。 > > 自分の現場の数字で確かめたいときは、[/message](/message) に1行どうぞ。