**最も大きな修正は⑦です。「57回→20回」は、地図で道を引く変更と、ドリンクバーを移して抜け道を作る変更を合わせた結果でした。** また、⑤は各条件1回の録画、⑪の「約88°」は厳密に確かめた作動限界として扱えません。

照合対象は、`材料/` にあるログ本文です。本文の【ファイル】表記で参照される別添・元動画・生データは材料に含まれていないため、以下は本文との整合性の判定です。

| # | 要点の主張 | ログ本文での数字・言い方（ファイル名と見出し） | 合っている／言い過ぎ／違う | 正しい言い方 |
|---|---|---|---|---|
| 1 | 実店舗の動画で、直す作業は1〜10秒、店員が来るまでは18〜45秒以上 | **LOG391.md「台帳に並べて分かった：人が来るまでの時間は、止まった場所で違う」**。動画5本のうち、店員が対応した停止3本。到着まで「41秒以上／45秒以上／約18秒」、作業「約5秒／1〜2秒／約10秒」。編集や停止開始が映らないことへの注意あり。 | **合っている**。動画上の概算・下限として扱う。 | 実店舗の動画で店員が対応した3例では、直す作業は約1〜10秒。店員が来るまでは約18秒、41秒以上、45秒以上かかっていた。 |
| 2 | 狭い通路で2台が向かい合うと、ロボットどうしでは解けず、店員が手で片方をどかしていた | **LOG434.md「これまでに集めた実物の動画4本と突き合わせた」**、**LOG400.md「①和食店：待機場所の横で KettyBot 2台が向かい合い、53秒以上」**。正面の向かい合いでは、店員到着まで41秒以上・53秒以上、手作業約5秒・約4〜5秒。LOG434は観察4本がすべて同じメーカーの機体であることも明記。 | **合っている**。観察した場面の範囲。「向かい合うと必ず解けない」への一般化は言い過ぎ。 | 実店舗の動画では、狭い通路や待機場所の横で向かい合った2台が自力で抜けられず、店員が片方を手でよけていた。 |
| 3 | 狭い28卓の店で2台にすると入店待ちが約2倍。1台が上限 | **LOG423.md「1台と比べると、どの案でも2台は1台に届かなかった」**。④・スタッフ2人・普通の混み具合で、1台13.8分、2台25.1分。1本道を1台ずつ通す案でも2台17.6分。各10種の中央値。ただし0・1台は前の版で、版を厳密にはそろえていない。**LOG393.md**の別段階では0台12.7分・1台14.4分・2台24.8分。 | **言い過ぎ**。「1台が上限」は、この店・人数・運用を超えて言えない。 | Unityの28卓・スタッフ2人の店では、普通の混み具合で1台13.8分に対し2台25.1分と、入店待ちが約2倍になった。試した改善案でも2台は1台より短くならなかった。比較には版の違いが残る。 |
| 4 | 5台にすると入店待ちが延びた。原因は待機点へ斜めに寄る入り方。決まりを変えて減らした | **LOG452.md「大型店の入店待ち（10種の中央値・分）」**。⑧・配膳だけで2台11.7分→5台17.2分。ただし台どうしの順番決めが不足する作りの影響あり。**LOG456.md「まっすぐ入る決まりの前と後」**では、5台の待機場所付近の30秒以上の詰まりが3,317秒→1,255秒。一方、入店待ちは12.22分→14.90分。**LOG465.md「人が待機点を通らない形の、前と後」**で追加変更後は詰まり809秒・入店待ち13.24分。 | **言い過ぎ**。「減らした」の対象が曖昧。斜めの入り方は大きな原因の一つで、入店待ちの原因全部ではない。 | Unityの大型店では、5台で待機場所付近の止まり合いが増えた。大きな原因の一つは、斜めに戻る台のセンサーに隣の待機台が入ること。まっすぐ入る変更で詰まりの時間は減ったが、同じ比較で入店待ちは短くならなかった。 |
| 5 | 下げ膳も任せると、通路にゆとりのある店では待ちが縮み、効率重視の細い店では延びた | **LOG444.md「6店の比較動画：配膳だけと配膳＋下げ膳を左右に並べた」**。ロボット2台・各条件1回の録画で、②⑤⑥は入店待ちが短縮、③④⑦は延長。例：⑤5.69分→4.85分、④17.48分→25.84分。本文は「ここから店ごとの答えを言い切ることはできません」と明記。**LOG440.md「依頼90・91」**の各10種の中央値では、入店待ちの向きがこの分類とそろわない店もある。 | **言い過ぎ**。各1回の録画で見えた傾向を、店の種類ごとの確定結果にしている。 | Unityの6店・ロボット2台を各条件1回ずつ録画した比較では、通路にゆとりのある3店で入店待ちが縮み、効率重視の3店で延びた。繰り返し集計では例外もあり、店の種類だけで結果は決められない。 |
| 6 | ロボットを足しても、詰まるのはレジではなく片付けと案内だった | **LOG397.md、LOG398.md、ともに「試算はレジで詰まり、3Dの店は片付けと案内で詰まる」**。46卓の店は0・1・2台で入店待ち8.1→6.6→5.5分、38卓の店は9.6→6.0→4.8分。2台でも「席は空いているのに待った」時間がそれぞれ3.4分・3.5分残った。各10種の中央値。 | **合っている**。Unity内の店全体の仕事の滞り。ロボット自体の停止とは区別が必要。 | Unityの46卓・38卓の店では、ロボットを増やすと入店待ちは縮んだが、片付けと案内が追いつかず、席が空いていても待つ時間が残った。 |
| 7 | 決まった線しか走らせない作りが詰まりの元。地図を渡すと60秒の止まりが57回から20回に | **LOG370.md「次の版：サイトは地図を渡し、道はロボットが地図の上で自分で引く」**で固定経路の問題を特定。**LOG374.md「2回目（ドリンクバーを動かした後）：60秒の止まりは20回」**の比較表は、③・2台・種0で「固定経路57回→地図で道を引く59回→ドリンクバー移動後20回」。 | **違う**。57回→20回を、地図を渡しただけの効果としている。 | Unityでは、決まった線だけを走る作りが詰まりの一因だった。地図で道を引く変更だけでは60秒以上の停止は57回→59回。さらにドリンクバーを移して抜け道を作ると20回になった。いずれも同じ条件・同じ種の1回ずつの比較。 |
| 8 | 病院で通れない所を直すと問題が増えた。元は職員の仮の動きだった | **LOG488.md「ロボットの問題は1日84件から132件に増え、37件は大廊下の東の端で起きた」**。仮の病院・秒速0.6m・種0。問題は急停止・ひやり・人によけさせた等の合計。**LOG491.md「依頼155」**で行き先を絞り132→68件、**「走っている間の問題は68件から19件」**で職員の動かし方を変更。追記では患者等の動きを足して19→51件。 | **合っている**。ただし項目名の「衝突が増えた」は**言い過ぎ**。件数は衝突事故の数ではない。 | Unityの仮の病院で、通れなかった患者・職員を通すと、急停止やひやりなどの問題が84件→132件に増えた。通行可能な場所を職員の普段の行き先にも使う仮の決まりが増加に関わっていた。 |
| 9 | 録画で長い止まりを見つける試しで、道の線を消すと拾えた割合が72%から28%に | **LOG418.md「線を消すと、長い止まりを拾えた割合は72%から28%に落ちた」**。Unity録画の切り出し画像を異常検知で判定。誤報5%の条件で、30秒以上の停止の検出率が67/93件（72%）→26/94件（28%）。撮り直しで動きも変わり、同一場面どうしの比較ではない。 | **合っている**。ただし項目名の「カメラでは見つからない」は**言い過ぎ**。この検出方法・条件での結果。 | Unity録画から切り出した画像1枚で長い停止を検出する試験では、誤報5%の条件で、画面の経路線ありは72%、線なしは28%を拾えた。実店舗のカメラの検出性能を測った値ではない。 |
| 10 | ブロックを落とす原因は電源。12V・2Aを5Aに替えると落とさなくなった | **LOG487.md「mechArm 270 の電源は40W、つないでいたアダプターは24Wだった」**では電源不足は未確定。**LOG504.md「12V・2A の日の3回と、つかんでいる間の爪の電流を並べた」**では、同じモデル・閉じる値・位置5で成功1/3回→5/5回。ただし交換後も1回は人が持ち上げを補助し、その際に電流低下あり。教えた動きの再生は計7回成功。 | **合っている**。LOG504まで含めた、今回の実機試行の結果。完全解消・全自動成功とは言えない。 | 実機mechArm 270で、12V・2Aから12V・5Aへ電源を替えると、位置5の試行は5回とも落とさず成功した。うち1回は人が持ち上げを補助し、爪の電流低下も残った。 |
| 11 | 肩を約88°より深く倒す命令が、エラーなしに捨てられた | **LOG352.md「位置2：肩95°を超える教え方では、つかむ命令が6回とも全く動かなかった」**。肩95.53〜99.22°の姿勢で6回とも動かず、87.27°に教え直すと5回成功。**「肩の上限88°は、本線の fk_lookup.py にはLOG257から入っていた」**では、88°は本線の姿勢選択上限。本文には肩88.76°での再生成功もある。 | **言い過ぎ**。冒頭の要約とは一致するが、「88°超」を厳密な拒否境界にする根拠は不足。 | 実機mechArm 270では、肩95.53〜99.22°の姿勢への命令が、エラーなしに6回とも動かなかった。肩87.27°で教え直すと5回続けて成功した。本線では肩88°以内の姿勢を選ぶ設定にしていた。 |
| 12 | 学習の誤差は下がっても、実機では爪が奥で空を閉じた | **LOG348.md「4,000ステップまでの loss は0.0030〜0.0035で、下がり方はゆるやかになった」**、**「実機の1回目は、ブロックの奥でグリッパーを閉じた」**、**「実機の2回目も、同じ場所でグリッパーを閉じた」**。学習2,000→4,000ステップ、4,000時点の誤差0.0030、実機2回とも空振り。**LOG345.md「動画で見ると、手前の爪がブロックの上に乗っていた」**は追加学習前の別の止まり方。 | **合っている**。空を閉じた事実の直接の出典はLOG348。 | 学習を2,000から4,000ステップに増やし、学習誤差が0.0030まで下がっても、実機mechArm 270は2回ともブロックの奥で爪を閉じ、つかめなかった。 |

検証環境は、**①②が実店舗の動画観察、③〜⑧がUnityのシミュレーション、⑨がUnity録画を使った画像検知試験、⑩〜⑫が実機**です。

参考のLOG439は、本文自身が「実験の記録ではなく、対話しながら考えた記録」としています。「見る・位置を知る・決める・動く」の分類は作者の考察で、各機体の内部原因を実証した結果としては扱えません。