【採否】

- B・1：採る。「4割減った」記録も置き、改善の数字が置かれた前提を問う。ただし、後の記録によって4割減が否定されたとは書かない。
- B・2：採らない。導入目的や補正ループの設計まで広げず、「修正後に問題が増えた開発者」の点検に絞る。
- B・3：一部採る。「3割しか拾えない」を加え、数え方を独立した点検項目にする。残る2本は論点を増やしすぎるため加えない。
- B・4：一部採る。症状から引けて、答えを残せる問いにする。ただし、はい／いいえだけで確認済みと誤認させず、根拠も書ける形にする。
- B・5：一部採る。「ロボットなしなら合った」を節見出しに出す。「合わせたのはそこまで」は、ほかの条件を確かめていないと断定するため使わない。
- B・6：一部採る。リンク文にロボットとシミュレーションを明記する。配膳LP経由も記録し、30件未満では判断しない。
- B・7：一部採る。元ログの素材で同じ条件の前後を示せる場合に限り図を置く。対応を確認できなければ使わない。
- C・1：採らない。「増えた」という個別の事実を「増える」という一般則に変えず、一覧にない「衝突」も加えない。現行見出しの具体性を守る。
- C・2：一部採る。列名を平易にする。ただし、ログにない「すり抜け」「仮の軌道」や、地図を渡すことを正解とする誘導は足さない。
- C・3：採らない。病院でも線に縛った作りが原因だったという根拠はない。店の事例は、病院でも確認する問いとして接続する。
- C・4：一部採る。一致の対象と条件を書かせる問いは強める。「実環境と合った」への置き換えと、「ロボットなしまで」の断定は採らない。
- C・5：一部採る。入力フォームを作らず、コピーして使える点検メモにする。「現場の数字が届いて初めて直せる」とは言わない。

【企画書】

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

**通れない所を直したら、問題が増えた――ロボットシミュレーションの点検表**  
URL：`/check-robot-simulation`

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

病院の搬送ロボットの導入検証を任された開発者。AIに「シミュレーションを修正したら、ロボットの問題が増えた原因」を調べさせ、本ページへ来る想定。

設定を直すたびに結果が変わり、次の修正に進むべきか、導入判断の資料に使えるか迷っている。

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

自分の結果を支える仮の設定・問題の数え方・照合条件を記録に照らし、次に確かめる箇所を決められる。

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

**通れない所を直したら、搬送ロボットの問題が増えた。**

病院のシミュレーションで、通れない所の修正後に問題が増えました。  
問題の元をたどると、職員に与えた仮の動きでした。  
次の修正の前に、設定・数え方・照合条件を確かめる、出典付きの点検表です。

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

**「直したら増えた」から、自分の前提へ戻れる点検表。**

「起きたこと／記録で分かったこと／確かめた範囲／元ログ／自分の環境で確認すること」を文字の表にする。問いは本ページで編集したものと明記する。

中心になる行は次のとおり。

| 起きたこと | 記録で分かったこと・範囲 | 自分の環境で確認すること |
|---|---|---|
| 病院の通れない所を直すと問題が増えた | 当該シミュレーションでは、職員の仮の動きが問題の元だった | 人の動きに仮置きした設定を列挙し、それぞれの根拠を書けるか |
| 道の線を消して詰まりを検出した | 当該の検出方法では3割しか拾えなかった（ログの数字） | 問題を拾えているか、何と照合したかを書けるか |
| ロボットなしで照合した | 試算と立体シミュレーションが合った | 自分の「合った」は、何と何を、どの条件で比べた結果か |

各行に元ログへのリンクを置く。病院の修正前後を示す既存素材は、比較条件を確認できる場合だけ添える。

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

**第1節｜4割減った記録のあとに、直したら増えた記録がある**

`/record/hospital-transport-robot-avoid-outpatient-hall`  
`/record/hospital-transport-robot-blocked-paths-more-conflicts`  
`/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves`

外来の廊下を避けて問題を4割減らした記録、通行不能箇所を直すと問題が増えた記録、職員の仮の動きが問題の元だった記録を順に置く。4割は最初のログの結果であり、同条件の連続比較や、後から否定された数字とは扱わない。ここから点検表を始める。

**第2節｜店では、線に縛った作りが詰まりの元だった**

`/record/serving-robot-fixed-route-jam`  
`/record/serving-robot-map-planner`

線に縛った作りが詰まりの元となり、地図を渡すと詰まりが減った事実を示す。病院と同じ原因とはしない。「自分のロボットの移動を制約する設定を、どこで確認できるか」を点検表に加える。

**第3節｜問題が少ないのか、拾えていないのか**

`/record/serving-robot-jam-detection-without-path-lines`

道の線を消すと詰まりを3割しか拾えなかった記録を置く。3割は当該ログの検出結果に限定する。モデルの動きと、問題を数える仕組みを別々に確認するための行にする。

**第4節｜ロボットなしなら、立体シミュレーションと試算は合った**

`/record/serving-robot-stage-b-18-runs`

合った事実を明確に示し、照合対象が試算と立体シミュレーション、条件がロボットなしであることを併記する。実店舗との一致には広げない。点検表には「比較対象／条件／一致を確かめた根拠」を残す。

**第5節｜次に確かめる前提を、ひとつ残す**

`/record/serving-robot-sim-ready-for-store-data`

店で測った数字が届けば試算を直せる準備を示す。現場との一致を確認した結果とは分ける。

末尾に「未確認の前提／次に取る観測／反映する箇所」のコピー用メモを置く。読者は点検表から次の確認対象を選び、必要な元ログへ進む。

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

- `/record/hospital-transport-robot-avoid-outpatient-hall`
- `/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/serving-robot-jam-detection-without-path-lines`
- `/record/serving-robot-stage-b-18-runs`
- `/record/serving-robot-sim-ready-for-store-data`

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

トップの「導入前ガイド」と `/series8` の資料部分に、**「ロボットシミュレーションを直したら問題が増えたときの点検表」**として置く。補足に「病院の搬送・店の配膳の記録から」と添える。

`/serving-robot-one-less-staff` の試算を読む箇所にも置き、本ページからは人員への効き目を検討するリンクで戻す。個々のログの形式は変えず、点検表から全文・コード・素材へ送る。

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

人の操作があった本ページの表示が30件に届くまで判断しない。30件は依頼の判断保留基準であり、検証に十分な件数の保証ではない。

点検表への到達率、元ログへの遷移率、同じ訪問で異なる元ログを複数開いた割合を見る。保存・再現成功は閲覧から推定しない。

流入元別にも記録し、各区分が30件未満なら差を判断しない。AIサービスのリンクからの人の来訪と、AI利用者の依頼による取得は分ける。これらは入口の働きを見る補助指標とし、「再現可能な環境の数」に算入しない。