### ページの名前と URL の案

**ロボットの詰まりを、シミュレーションの作りから点検する**  
URL：`/check-robot-simulation`

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）

搬送ロボットの導入検証を任され、病院のシミュレーションを作っている開発者。

AIに原因調査を頼み、「病院の通れない所を直すと、搬送ロボットの問題が増えた」のログに来た。現場に近づけるほど結果が悪くなり、経路やロボットの設定を直し続けている。この結果を導入判断の資料に使ってよいのか、自信が持てない。

この人が次の修正に着手する前に開く、点検用のページにする。

### この人がこのページで得るもの（1文）

詰まりを生んだシミュレーション側の前提と、その発見の経緯を照合し、自分の検証で先に確かめる箇所を決められる。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）

**仮に置いた職員の動きが、搬送ロボットの問題を作っていた。**

病院の通れない所を直すと、シミュレーション内の問題が増えました。  
その後、原因として見えてきたのは、職員に仮で与えていた動きでした。  
この経緯を起点に、詰まりを直す前に点検したいモデルの前提をたどります。

### 見せ場（このページにしかないもの。ログのどの事実か）

**「観測した問題」と「原因として判明したモデルの作り」を、対で読める点検表。**

中心に置くのは、病院の通行不能箇所を修正すると問題が増えた記録と、問題が職員の仮の動きから来ていたと分かった記録。その隣に、配膳ロボットを線に縛った作りによる詰まりと、待機点への入り方による止まり合いを並べる。

各行には「観測したこと／原因として分かったこと／元ログ／自分の環境で確認する問い」を置く。確認する問いは、このページの編集として明記する。

たとえば「職員の移動に、仮の設定が残っていないか」。読者が持ち帰るのは一般論のチェックリストではなく、**実際に原因を取り違えうる作りが露出した記録付きの点検表**になる。

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）

**第1節｜病院を直したら、問題が増えた**

使うログ：  
`/record/hospital-transport-robot-blocked-paths-more-conflicts`  
`/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves`

通れない所の修正後に問題が増え、その問題が職員の仮の動きから来ていた、という順で見せる。「問題件数が増えた」という結果だけでは原因を決められなかった経緯を、このページの出発点にする。実病院での発生件数とは扱わない。

**第2節｜経路の作りが、詰まりを生んでいた**

使うログ：  
`/record/serving-robot-fixed-route-jam`  
`/record/serving-robot-map-planner`

ロボットを線に縛った作りが詰まりの元になり、地図を渡すと詰まりが減った事実を示す。点検表には「自分のモデルで、移動の自由をどう制限しているか」という問いを添える。地図を渡せばどの現場でも解決する、とは広げない。

**第3節｜台数を増やすと、モデルの穴が見えた**

使うログ：  
`/record/large-restaurant-five-serving-robots-longer-wait`  
`/record/serving-robots-jam-cause-standby-entry`

大型店で配膳ロボットを5台にした検証がシミュレーションの穴を露出させ、その後、止まり合いの原因が待機点への入り方にあると分かった経緯を扱う。「5台は多すぎる」という導入上の結論にはしない。5台は当該ログの実験条件として記す。

**第4節｜比較する土台を、先に確かめる**

使うログ：  
`/record/audit-simulator-before-unity`  
`/record/serving-robot-stage-b-18-runs`

立体の店に合わせる前に試算を点検したこと、ロボットなしの条件では試算と立体シミュレーションが合ったことを示す。照合が成立した条件を明記し、ロボットあり・実店舗まで検証済みとは読めない形にする。

**第5節｜次に直す箇所を、点検表に残す**

使うログ：  
`/record/check-serving-robot-sim-with-phone`  
`/record/serving-robot-sim-ready-for-store-data`

店のスマホで測って試算を確かめる取り組みと、店で測った数字を受け取って試算を直せる準備を示す。

点検表の末尾に「自分の環境では未確認の前提／次に取る観測／照合するログ」の記入欄を置く。これは新しい検証結果ではなく、読者用の整理欄。現場データによる検証が完了したとは書かない。

### 束ねるログ（/record/… の一覧）

上記構成に挙げた以下のログを束ねる。

- `/record/hospital-transport-robot-blocked-paths-more-conflicts`
- `/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves`
- `/record/serving-robot-fixed-route-jam`
- `/record/serving-robot-map-planner`
- `/record/large-restaurant-five-serving-robots-longer-wait`
- `/record/serving-robots-jam-cause-standby-entry`
- `/record/audit-simulator-before-unity`
- `/record/serving-robot-stage-b-18-runs`
- `/record/check-serving-robot-sim-with-phone`
- `/record/serving-robot-sim-ready-for-store-data`

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）

トップの「導入前ガイド」にページ名で追加する。相談窓口は設けない。

`/series8` の資料部分から「シミュレーションの前提を点検する」として送る。シリーズ一覧を通読する前に、困り事から入れる位置に置く。

既存の `/serving-robot-one-less-staff` では、試算結果を読む箇所から本ページへつなぐ。本ページからは「人員への効き目を検討する」導線で戻す。

個々のログの形式は変えず、本ページの各事例から元ログの全文・コード・素材へ送る。

### 公開後に見る数字（30件たまるまでは判断しない）

依頼の集計と同じく、人の操作があった表示を対象にする。まず本ページの表示が30件たまるまで判断しない。30件は依頼で定められた判断保留の基準で、十分な検証数を保証する数字とは扱わない。

見るのは、本ページから元ログへ進んだ件数と割合、点検表のある位置まで読んだ割合、再訪した人数。保存そのものは測れないため、再訪は参考にとどめる。

AIサービスのリンクからの来訪と、AI利用者の依頼による取得も分けて記録する。区分ごとの件数が30件未満なら、その差は判断できないとする。

元ログへの遷移だけで再現成功とは数えない。**このページで自分の検証を再開できる人が増えたか**を確かめる入口の数字として使う。