【採否】

- B・指摘1：一部採る。原因と確認範囲を分ける。ただし、作りの問題を除いても、残る結果を導入判断に使えるとは保証しない。
- B・指摘2：採る。ログ一覧では原因のつながりを確認できないため、第35・36回を結び付けた記述を削る。
- B・指摘3：一部採る。病院の前提修正を入口に加える。「4割減」の結果は、この点検表では扱わない。
- B・指摘4：一部採る。問いを含む本文と文字の表を置く。AIに選ばれることや、元ログから来訪できることは前提にしない。
- B・指摘5：採る。最初の画面で「次に何を確かめるかを決める」と明示する。
- B・指摘6：一部採る。瞬間移動が消えた記録を加える。発生原因や検出の割合は、一覧以上に補わない。
- B・指摘7：一部採る。照合済みの範囲と現場データを受け入れる準備を分ける。「現場では未検証」とも一覧だけでは断定しない。
- B・指摘8：一部採る。複数ログへの遷移を見る。ただし、既存の「数件ずつ」と母数の違う件数で優劣を決めない。
- C・指摘1：一部採る。結果が悪化した場面を先頭に置く。「衝突」「経路ではない」「現実に近づけるほど」は一覧を越えるため使わない。
- C・指摘2：一部採る。病院の開発者が使う問いにつなぐ。ただし、試算と立体シミュレーションの一致を、現実との一致に置き換えない。
- C・指摘3：一部採る。「点検表」を名前に入れる。「破綻」「本当の原因」はページ全体の約束として強すぎる。
- C・指摘4：一部採る。点検表の実例を書く。「新たな衝突を生んだ」とは補わない。
- C・指摘5：一部採る。移動制約を確認する問いを置く。「現実には起きない詰まり」とは断定しない。
- C・指摘6：採る。最後は現場データを受け入れる準備と、読者が次に確かめることを残す欄にする。

【企画書】

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

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

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

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

経路や設定を直し続けているが、その結果を導入判断の資料に使ってよいか迷っている。次の修正前に開く点検表を作る。

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

問題を生んだモデルの前提と、確かめられた範囲を記録に照らし、自分の環境で次に確認する箇所を決められる。

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

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

病院のシミュレーションで、問題の元は職員に与えた仮の動きでした。  
直したのに問題が増えたとき、モデルのどの前提を確かめるか。  
病院と店の記録を照合し、次に確かめる箇所を決める点検表です。

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

**結果の悪化から、作りの前提へ戻れる、出典付きの点検表。**

列は「観測・変更／ログで分かったこと／確認できた範囲／元ログ／自分への問い」。問いは本ページで編集したものと明記する。

実例：

| 観測・変更 | ログで分かったこと | 確認できた範囲 | 自分への問い |
|---|---|---|---|
| 病院の通れない所を直すと問題が増えた | 問題の元は職員の仮の動き | 当該シミュレーション内の原因 | 人の動きに仮の設定が残っていないか |
| 配膳ロボットの詰まり | 線に縛った作りが元だった。地図を渡すと減った | 当該モデルの変更結果 | 移動にどんな制約を与えているか |

各行から元ログへ送る。「作りを直せば現場を予測できる」とは約束せず、確認範囲を表の中に残す。表は画像にせず、文字で読める形にする。

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

**第1節｜病院では、何を前提として置き直したか**

`/record/hospital-transport-robot-3d-view-wheelchair-share`  
`/record/hospital-transport-robot-full-floor-people-flow`

車いすの割合を1%に直した記録と、病院を人ごと再現した記録を示す。1%は当該ログの設定値として扱い、病院一般の割合にはしない。「自分のモデルで、根拠を確認していない設定はどれか」を問う。

**第2節｜直した場所と、問題の原因は同じではなかった**

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

通行不能箇所の修正後に問題が増え、職員の仮の動きが問題の元と分かった記録を対にする。ここに点検表を置き、以降の事例を追加する。実病院で起きた問題とは扱わない。

**第3節｜店の記録で、移動の作りを点検する**

`/record/serving-robot-fixed-route-jam`  
`/record/serving-robot-map-planner`  
`/record/serving-robot-sim-teleport-zero`

線に縛った作りによる詰まり、地図を渡した後の減少、瞬間移動が消えた記録を示す。病院でも同じ原因だとはせず、「移動制約は何か」「途中を飛ばす動きが残っていないか」を読者の確認項目にする。

**第4節｜一致したのは、どの条件までか**

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

ロボットなしでは、試算と立体シミュレーションが合った記録を示す。一致した対象と条件を明記する。「自分の検証では、何と何を、どの条件で照合したか」を問う。実店舗との一致には広げない。

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

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

店で測った数字が届けば試算を直せる準備を示す。準備と検証結果を分け、この記録を現場との一致の証拠にはしない。

表の末尾に「未確認の前提／次に取る観測／結果を反映する箇所」の記入欄を置く。読者用の整理欄であり、新しい実験結果ではない。

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

- `/record/hospital-transport-robot-3d-view-wheelchair-share`
- `/record/hospital-transport-robot-full-floor-people-flow`
- `/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-sim-teleport-zero`
- `/record/serving-robot-stage-b-18-runs`
- `/record/serving-robot-sim-ready-for-store-data`

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

トップの「導入前ガイド」と `/series8` の資料部分に「直したら問題が増えたときの点検表」として置く。

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

個々のログは変更せず、点検表から全文・コード・素材へ送る。元ログから本ページへの移動は見込まず、本ページ自体が調査の入口になるかを確かめる。

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

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

元ログへの遷移率、同じ訪問で元ログを2本以上開いた割合、点検表まで読んだ割合を見る。2本は複数事例の照合を見るための企画上の区切りで、再現成功の基準ではない。

AIサービスのリンクからの来訪と、AI利用者の依頼による取得は別に記録する。区分ごとも30件未満では差を判断しない。保存や再現成功を閲覧から推定せず、再現に必要な記録へ進めたかを見る。