# 案A「ロボットの詰まりを、シミュレーションの作りから点検する」への指摘 --- ### 指摘1【高】表のいちばん大事な列が欠けている：「シミュレーションの作りのせいか、現場でも起きることか」 **弱い所** この人がいちばん困っているのは「この結果を導入判断に使ってよいか」です。ところが点検表は、4つの事例をまとめて「原因として判明したモデルの作り」と呼んでいます。 - 職員の仮の動き（Log#44）と、線に縛った作り（Log#11）は、ログの題が「作り」が原因だと言っています。 - 待機点への入り方（Log#36）は違います。その次に「止まり合いを減らす3つの決まり」（Log#37）が続いています。店の運用で起きることを見つけた記録とも読めます。 これを「モデルの作り」と同じ列に入れると、読者が本物の詰まりを作りのせいだと見誤るおそれがあります。この点検表が防ぎたい取り違えを、表そのものが生んでしまいます。 **こう直す** 表の列を次のように変えます。 > 観測したこと／原因／**原因の側（シミュレーションの作り・現場でも起こりうる・ログで要確認）**／元ログ／自分の環境で確かめる問い 行の例： - 「病院の通れない所を直すと問題が増えた → 職員の仮の動き → **作り** → Log#43・44」 - 「配膳ロボット2台が待機点で止まり合う → 待機点への入り方 → **ログで要確認**（次の Log#37 で決まりを足して減らしている） → Log#36・37」 この列があれば、ページの約束は「作りのせいを外せば、残った詰まりは導入判断に使える」になります。ずっと強い約束です。 --- ### 指摘2【高】Log#35 と Log#36 を原因と結果でつないでいるのは、ログ一覧からは言えない **弱い所** 第3節の「5台で穴が見え、その後、止まり合いの原因が待機点への入り方と分かった」という書き方は、Log#35 の「穴」の中身が待機点のことだと決めつけています。題からは、その穴が何かは分かりません。 **こう直す** まず Log#35 の本文で「穴」の中身を確かめます。 - 待機点のことだったなら、そのまま書く。 - 違ったなら、2つを別の行に分けて次のように書く。 > 第3節｜台数を増やすと、シミュレーションの穴が出た > 大型店に配膳ロボットを5台置くと、待ちが延び、試算の穴が見えました（Log#35）。別の検証では、2台が止まり合う原因は待機点への入り方でした（Log#36）。 ログにある範囲では、これがいちばん強い言い方です。 --- ### 指摘3【高】病院の開発者に向けたページなのに、束ねるログ10本のうち8本が配膳ロボット **弱い所** Log#43 から来た人は、2節目から店の話が続くと「自分の話ではない」と感じて離れます。ログ一覧には、病院の流れがもっと続けてあります。 - Log#40：外来の廊下を避けて問題を4割減らす - Log#41：車いすを1%に直す - Log#42：病院を人ごと再現 - Log#43：通れない所を直すと問題が増えた - Log#44：原因は職員の仮の動き 特に Log#41 の「車いすを1%に直す」は、シミュレーションの前提の数字を直した記録です。表の1行にそのまま入ります。 **こう直す** 第1節を病院の連なりにして、店の事例は「同じ型が別の現場でも出た」として後ろに置きます。 > 第1節｜病院のシミュレーションを、前提ごと直していった > 車いすの割合を1%に直し（Log#41）、病院を人ごと再現し（Log#42）、通れない所を直すと問題が増えました（Log#43）。増えた問題の元は、職員に仮で与えていた動きでした（Log#44）。 注意が1つあります。Log#40 の「4割減らす」は、Log#44 で直す前の作りで出した数字かもしれません。本文で確かめるまで、表には「直す前の作りでの結果かどうか、要確認」と書いておきます。それ自体が、この人にとっていちばん役立つ点検の行になります。 --- ### 指摘4【高】この人がページにたどり着く道がない **弱い所** 個々のログの形は変えられません。なので Log#43 から本ページへのリンクは張れません。案のつなぎ方（トップ・/series8・配膳の LP）は、どれも病院の開発者の通り道ではありません。 **こう直す** この人は AI に原因調査を頼んで来ます。それならページ自体を、AI がその質問の答えとして選べる形にします。依頼の数字でも、AI の利用者の依頼で読みに来た数は週に42〜61件で、トップがいちばん多くなっています。 - 最初の段落を、この人の問いの形で書く。 > 「シミュレーションを現場に近づけたら、ロボットの問題が増えた。これはロボットのせいか、作りのせいか。病院と店の記録から確かめる表です。」 - 点検表は画像にせず、文字の表で置く。各行に元ログの URL を書く。 - トップの「導入前ガイド」には、ページ名ではなくこの問いの文で載せる。 --- ### 指摘5【中】最初の画面の3行目が、読者が得るものを言っていない **弱い所** 「この経緯を起点に、点検したいモデルの前提をたどります」は、手順の説明です。この人は「たどる」より「先に何を確かめればいいか」を知りたいはずです。 **こう直す**（見出しはそのまま） > **仮に置いた職員の動きが、搬送ロボットの問題を作っていた。** > 病院の通れない所を直すと、シミュレーションの中の問題が増えました。元は、職員に仮で与えていた動きでした。 > 病院と配膳ロボットの店で、詰まりの原因がシミュレーションの作りにあった記録を、1枚の表にしました。 > 次の修正の前に、自分の環境で確かめる問いを行ごとに付けています。 数を書く場合は、指摘1で「作り」と確かめられた行の数だけにします（いまの題から言えるのは、Log#44 と Log#11 の2つです）。 --- ### 指摘6【中】「作りの穴」の行が少ない。ログ一覧にもっと強い事例がある **弱い所** シミュレーションの作りそのものの穴を示すログが、ほかにもあるのに使われていません。 - Log#32「シミュレーションから瞬間移動が消えた」 - Log#13「隠れていた待ちが見えて」 - Log#28「道の線を消すと、詰まりは3割しか拾えない」 **こう直す** Log#32 を第2節に1行足します。 > 観測したこと：ロボットが瞬間移動していた → 原因の側：作り → 確かめる問い：「自分のシミュレーションで、ロボットや人が途中を飛ばして移動していないか」 開発者がいちばん持ち帰りたくなる行になります。中身（何がなぜ瞬間移動していたか）は本文で確かめてから書きます。Log#28 は「詰まりを見つける仕組みにも見落としがある」という行に使えますが、3割の意味は本文の言い方に合わせます。 --- ### 指摘7【中】第5節が「準備ができた」で終わっていて、締めが弱い **弱い所** 店のスマホで測る話（Log#26・27）を「取り組み」として並べると、終わりがぼやけます。 **こう直す** 「ここから先はまだ確かめていない」という境目として、はっきり書きます。正直に書くほど、点検表として信用されます。 > 第5節｜ここから先は、まだ現場の数字で確かめていない > ロボットなしの条件では、立体の店と試算は合いました（Log#10）。ロボットありの結果を店の実物で確かめるために、店のスマホで測る方法を作りました（Log#26）。数字が届けば、試算はすぐ直せる形にしてあります（Log#27）。まだ店の数字では確かめていません。 第4節と第5節はこの形で1つにまとめ、「どこまで確かめたか」の節にできます。 --- ### 指摘8【低】公開後に見る数字に、比べる相手を置く **弱い所** 「元ログへ進んだ件数と割合」には比べる相手がありません。また、再訪は保存の目安としては弱いです。 **こう直す** いまは、ログから別のログへ移る動きが「数件ずつ」しかありません（依頼の数字）。これを比べる相手にします。 > 本ページから、2本以上の元ログへ進んだ表示の数を見る。いまはログからログへ移る動きが数件ずつなので、それを上回るかを見る。30件たまるまでは判断しない。 再訪の欄は外し、AI の利用者の依頼で本ページが読まれた数を週ごとに記録します。こちらのほうが、このページの入口の役目に合っています。 --- ## 守るべき尖り **「現場に近づけたら、結果が悪くなった。原因はロボットではなく、シミュレーションの作りだった」という、失敗の向きの記録を入口にしていること。** うまくいった結果ではなく、取り違えかけた経緯を差し出すから、同じ所で迷っている開発者が「保存しておきたい」と思います。書き直すときも、見出しを成果の言い方（「問題を4割減らした」など）に変えないでください。