案Aで読む人が初めて得られるのは、**「ロボットが止まる理由の一覧」よりも、「導入試験で、何を分けて測れば判断を誤らないか」**です。

直す時間と人を待つ時間、歩行距離と入店待ち、止まり合いと店全体の待ち、学習誤差と実機の成功。この違いを、現場の数字で示せるのが案Aの価値です。切り口と12項目は残し、次の8点を直すと強くなります。以下は、提示された「事実の照合」とログ読解材料に基づく評です。

### 1. 冒頭は、一般論より「何を測り分けられるか」を先に出す

「多くの止まりで、ロボットは壊れていませんでした」は、故障の有無を全件で確かめたように読めます。「カタログには書いていない」も、カタログ全般を調べた根拠がありません。未確認の販売サイトの一文と合わせて削り、案A自身の数字で入口を作ってください。

冒頭の3行の差し替え案です。

> 配膳ロボット・病院の搬送ロボット・ロボットアームの、12の止まり方を集めました。  
> 実店舗の動画では、直す作業が約1〜10秒でも、店員が来るまで約18秒、41秒以上、45秒以上かかった例がありました。ほかに、シミュレーションと実機の記録を載せています。  
> 止まった回数だけでなく、人を待つ時間、席を使えるまでの時間、実機で成功した回数まで。入れる前に何を確かめるかを、項目ごとに持ち帰れます。

また、「足せば良くなるが5回外れた」は、独立した検証を5回行ったようにも読めます。次に替える方が正確です。

> 台数・機能・学習量を増やしても、狙った指標が改善しなかった記録があります。何を改善したいのかを決め、その数字で前後を比べる必要があります。

### 2. いちばん刺さるのは「店員が来るまで」。通知が原因という断定を外す

**数秒の作業より、人を待つ時間の方が長い。** この発見は、経営者が人員配置や導入試験の見方を変える材料になります。先頭に置く判断に賛成です。

ただし、「来なかったのは、お客さん向けの合図だったから」は、動画から確かめられた因果ではありません。ハコブくんも同じ断定をしています。

差し替え案です。

> **なぜ止まったか**：向かい合いや出口のふさがりで進めなくなっていました。店員が来るまでに時間がかかった理由は、動画だけでは確かめられません。声と赤い明かりは確認できましたが、店員の端末へ通知が届いたかは分かりません。  
> **ハコブくん**：「直すのは約5秒。店員さんを待つのは41秒以上でした。」

なお、53秒以上の4本目を残すなら、出典に現在の項目2にもある `/record/serving-robot-jams-are-aisles` を加えてください。

### 3. 「にらみ合い」は、公開情報の不足より「譲った先でもふさぐ」を原因にする

「メーカーが決まりを公開していない」は、止まった原因ではありません。仕様幅の列挙も、読者が自分の機種の説明書を確認すれば得られる情報です。

ここで価値があるのは、**譲る台を決めるだけでは足りず、退避先まで必要だった**というシミュレーションの中身です。

差し替え案です。

> **なぜ止まったか**：実店舗の機体が抜けられなかった内部原因は、動画では分かりません。Unityでは、2台とも料理を載せている場合などに譲る台を決められず、よけた先も相手の道の上になっていました。  
> **入れる前に確かめること**：狭い所で2台が向かい合ったとき、どちらが、どこまで下がれば通れるか。退避先がふさがっている場合も、試しの期間に確認できるか。  
> **ハコブくん**：「譲った先も、相手の通り道でした。」

「助け2回・約105秒」には、「この条件の1回の試行では」を添えてください。復旧時間の保証には使えません。

### 4. いちばん弱いのは「画面の線がないと見つからない」。監視の性能を確かめる項目に直す

現在は画像検知の実験説明が長く、読者が導入判断にどう使うかが薄い項目です。しかも線なしでも28%拾えているため、名前の「見つからない」は言い過ぎです。

**「止まりを見つけた数字が、本番にも存在する手がかりで出た数字か」**という問いにすると、この実験固有の価値が出ます。

差し替え案です。

> **名前**：画面の線を拾っていた  
> **何が起きたか**：Unity録画の静止画1枚で30秒以上の停止を検出する試験では、誤報5%の条件で、経路線ありは72%、線なしは28%を拾いました。撮り直しで動きも変わっているため、同一場面から線だけを消した比較ではありません。  
> **入れる前に確かめること**：監視の実演で拾えた停止と見逃した停止を、本番と同じ表示条件で確認できるか。実際には映らない線や印を、判定の手がかりにしていないか。

指標名の説明がない「0.51」は削ってよいです。72%と28%、見逃しの実例で判断材料は足ります。

### 5. 「2台目」と「下げ膳」は、良くなった数字と悪くなった数字を並べる

この2項目は、「増やすと詰まる」という教訓だけでは惜しいです。**負担軽減と客待ち短縮が、同じ結果にならなかった**ことが経営判断に効きます。

項目6の中心文は、次に替えてください。

> Unityの28卓・スタッフ2人の店では、1台でスタッフの歩行距離は約3割減りました。一方、入店待ちは0台13.0分、1台13.8分。2台では25.1分となり、1台の約1.8倍でした。ただし、1台と2台の比較には版の違いが残ります。

項目8も、比較の条件を本文に入れます。

> 6店・台数2条件・各10種の計120回では、下げ膳を加えると歩行距離は全12条件で減りました。一方、細い通路の2店では、2台運用時の退店から卓が使えるまでの時間が、各10種の中央値で4.05→6.05分、4.49→8.06分に延びました。

問いも一つ強められます。

> 歩行距離が減っても、客待ちが延びた場合、この導入を採用するか。何を優先するかを試験前に決めているか。

### 6. 「待機場所」は、止まり合いが減っても入店待ちが延びた事実を主役にする

項目7は、注意書きに置かれた数字の方が重要です。改善が店全体に効いたかを確かめる、案Aの中心例にできます。

差し替え案です。

> **何が起きたか**：Unityの大型店で、待機点へまっすぐ入る変更をすると、待機場所付近の詰まりは3,317秒から1,255秒に減りました。ところが同じ比較で、入店待ちは12.22分から14.90分に延びました。止まり合いの改善だけでは、店全体の待ちの改善を確認できませんでした。  
> **入れる前に確かめること**：止まり合いが減ったとき、入店待ちや卓が使えるまでの時間も改善したか。同じ条件で両方を比べられるか。

0.8mと0.85mは「このシミュレーションの設定」と明記してください。実機一般の待機間隔を決める数字にはできません。

### 7. 「なぜ止まったか」で、見立てを確定原因にしない

主に次の3か所です。原因を弱めるのでなく、**どこまで確かめ、何が未検証かを示す**と、検証相手としての信頼が増します。

- **項目4・学習**  
  「足りないのは位置が違うお手本だと分かりました」は先走っています。  
  > お手本の位置の偏りが原因ではないかと見立て、位置を変えたお手本を集める方針にしました。その学習し直しで改善したかは、今回の材料では確かめていません。

- **項目11・片付け**  
  46卓・38卓の原因は、ログでも他店の観察からの見立てです。  
  > 片付けと案内が追いつかない時間が残りました。ログでは、スタッフが歩くぶん作業が後回しになることが関わると見ています。

- **項目12・電源**  
  「同じ条件」だけでは、日が違うことと人の補助を見落とします。  
  > 同じモデル・位置・閉じる設定で、別日に電源交換の前後を比べました。成功は1/3回から5/5回となりましたが、交換後も1回は人が持ち上げを補助しました。電圧低下を直接測った記録はありません。

### 8. 終わりは、チェック項目の再掲から「自分の現場の比較の作り方」へ進める

現在の締めは項目数が多く、「全部確認する」で止まりがちです。持ち帰って使えるように、記録方法を一段具体化してください。

差し替え案です。

> **自分の現場では、まず改善したい数字を一つ決めてください。** 入店待ちを縮めたいのか、卓を早く使えるようにしたいのか、人の歩行や復旧作業を減らしたいのか。  
> 試しの期間には、止まった場所、止まった時刻、人が来た時刻、復旧した時刻を分けて残します。台数や運用を変える前後で、最初に決めた数字も比べてください。  
> これは、この図鑑の記録から提案する確かめ方です。停止が減ったことと、導入の目的を達成したことを、両方確認するために使ってください。

案Aの切り口を最も強くするのは、**「止まる場所を知った」で終わらず、「自分の導入試験では、この数字を分けて取る」と決められるページにすること**です。