# 案A（第2版）への評：もっと強くするための指摘

（ログ一覧のタイトルと URL だけを根拠にしています。本文の中身は確かめていないので、以下の書き換え案で数字や言い回しを使うときは、元ログの本文と食い違っていないか先に確かめてください。）

---

### 1.【高】「直したら増えた」の前にあった数字が抜けていて、話の振れ幅が伝わらない

**弱い所**
見出しは強いですが、最初の画面で分かるのは「増えた」だけです。同じ病院のシリーズには、その前に Log#40「外来の廊下を避けて問題を4割減らす」があります。「4割減った → 通れない所を直したら増えた → 元は職員の仮の動きだった」という流れがあって、初めて開発者は「自分の改善の数字も危ないかもしれない」と感じます。今の束ねるログには #40 が入っていません。

**こう直す（最初の画面の3行）**
> **通れない所を直したら、搬送ロボットの問題が増えた。**
>
> 同じ病院のシミュレーションで、先に「外来の廊下を避けて問題を4割減らす」と記録していました。
> そのあと通れない所を直すと問題は増え、元をたどると、職員に置いていた仮の動きでした。
> 直したのに悪くなったとき、次の修正の前に開く点検表です。どの行からも元の記録へ進めます。

- 束ねるログに `/record/hospital-transport-robot-avoid-outpatient-hall` を足します。
- 「4割減は間違いだった」とは書きません。ログの順番を並べるだけにします。読者への問いは「自分の改善の数字は、どの前提の上に立っているか」にします。

---

### 2.【高】相手は病院の開発者なのに、病院の「前提」を扱ったログが入っていない

**弱い所**
病院のログは #41〜#44 だけで、残りの半分以上が店の記録です。ところが一覧には、この人にいちばん刺さる題のログがあります。LOG305「作る前に調べたら、前提が四つ崩れた」と、LOG269「意思決定の補正ループを設計する」です。前提を点検する表なのに、前提を点検したログが入っていません。

**こう直す**
第1節の頭に LOG305 を置き、節の名前を変えます。
> **第1節｜作る前に、前提は四つ崩れていた**
> 病院の搬送ロボットが看護師の役に立つかを、作る前に調べた記録（/record/does-a-delivery-robot-help-nurses）。そのあと、車いすの割合を1%に直し（#41）、病院を人ごと再現した（#42）。

表に足す行：

| 起きたこと | ログで分かったこと | 確認できた範囲 | 自分への問い |
|---|---|---|---|
| 作る前に前提を調べた | 前提が四つ崩れた | 作る前の調査 | 自分のモデルの前提のうち、作る前に調べたものはいくつあるか |

LOG269 は第5節の「次に確かめる前提を残す」で、予測と実際を突き合わせる作りの例として送ります。

---

### 3.【高】点検する先が「モデルの作り」だけで、「問題の数え方」が抜けている

**弱い所**
「問題が増えた／減った」は数えた結果です。数えた数が変わったときは、作りの前提と並べて、数え方そのものも疑うべきです。一覧には、そのためのログがあります。Log#28「道の線を消すと、詰まりは3割しか拾えない」、Log#35「配膳ロボット5台で見えた、シミュレーションの穴」、Log#5「Unity に合わせる前に、試算のほうを点検した」です。とくに #5 は、タイトルそのものが点検です。

**こう直す**
第3節の名前を「**店の記録で、移動の作りと、数え方を点検する**」に変え、表に次の行を足します。

| 起きたこと | ログで分かったこと | 確認できた範囲 | 自分への問い |
|---|---|---|---|
| 道の線を消して詰まりを数えた | 3割しか拾えなかった | 当該の検出のやり方 | 自分の「問題の数」は、見落としの割合を測ったことがあるか |
| ロボットを5台に増やした | シミュレーションの穴が見えた | 当該モデル | 台数や人数を増やしたときだけ出る穴を試したか |
| Unity に合わせる前 | 試算のほうを点検した | 照合の前の点検 | 照合する前に、比べる側の点検を済ませたか |

---

### 4.【中】「自分への問い」が広すぎて、読者が答えを書けない

**弱い所**
「移動にどんな制約を与えているか」は、読んでうなずけても、その場で答えが出ません。保存したくなる点検表は、はい／いいえで答えられ、答えが一覧になる問いでできています。また、読者は「直したら増えた」という症状を持って来ます。それなのに、表の左の列は記録の側から書かれています。

**こう直す**
- 列の順番を「**起きたこと（症状）／ログで分かったこと／確認できた範囲／元ログ／自分への問い**」にします。
- 問いを、答えが書ける形に書き換えます。
  - 「人の動きに仮の設定が残っていないか」→「**職員・患者の動きのうち、観察や資料ではなく仮に置いた値を全部書き出せるか。いくつあるか**」
  - 「移動にどんな制約を与えているか」→「**ロボットは決まった線の上しか動けないか、地図の上を自由に動けるか。どちらか言えるか**」（#11・#12）
  - 「途中を飛ばす動きが残っていないか」→「**1回の実行で、位置が飛んだ回数を数えたか。0回か**」（#32）

---

### 5.【中】第4節が言い控えすぎて、ログにある一番強い事実が埋もれている

**弱い所**
「一致したのは、どの条件までか」という書き方だと、合ったこと自体が目立ちません。Log#10 のタイトルは「ロボットなしなら、Unity と試算は合った」と言い切っています。この事実の範囲なら、いちばん強く言ってよい所です。

**こう直す**
> **第4節｜ロボットなしなら、Unity と試算は合った。合わせたのはそこまで**
> 照合したのは、ロボットを入れない条件の試算と Unity の店です。ロボットを入れたあとの照合と、実店舗との照合は、この記録には含まれません。
> 問い：**自分の「合った」は、何と何を、どの条件で比べた結果か。1行で書けるか**

URL に「18-runs」とあります。回数を書くなら、本文で回数を確かめてから「（〇回）」と添えてください。

---

### 6.【中】入口のリンク文が、AI にも人にも中身が伝わらない

**弱い所**
AI の利用者の依頼で読みに来る数は、トップがいちばん多いです。この企画の相手も、AI に調べさせて来る想定です。つまり、トップの「導入前ガイド」に置く1行が、AI に拾われる見出しになります。「直したら問題が増えたときの点検表」だけでは、ロボットの話か、何の記録かが分かりません。もう一つ、`/serving-robot-one-less-staff` から送る案も、表示が3件の LP です。病院の開発者が通る道でもありません。

**こう直す**
- トップと /series8 のリンク文：
  > **シミュレーションを直したら問題が増えたときの点検表 ― 病院の搬送ロボットと配膳ロボットの記録から**
- 本ページの最初の段落に、読者が AI に聞くときの言い方をそのまま入れます。たとえば「シミュレーションの修正で、ロボットの問題が増えた」です。
- 配膳 LP からの導線は残してかまいません。ただし、公開後に見る数字の対象からは外すと書いておきます（数が少なく判断できないため）。

---

### 7.【低】見せ場が表だけで、目で見て分かるものがない

**弱い所**
このシリーズには、Log#41「立体で見せて」、Log#23「動画で見比べる」、Log#48「現場の速さで見る」と、見せる工夫の記録があります。配膳 LP では、中の動画が57回再生されています（ページの表示は3件なので、判断はしない）。点検表が文字だけだと、病院で何が起きたのかが頭に入りにくくなります。

**こう直す**
第2節の表の直前に、#43 と #44 の素材から、修正の前後が分かる図を1枚ずつ置きます。
キャプションは「**通れない所を直す前／直した後。問題の元は、職員の仮の動きだった（#43・#44）**」とします。
素材に該当する図がなければ置きません。新しく作った図をログの結果のように見せないためです。表は今の案どおり、画像にせず文字で残します。

---

## 守るべき尖り

**「直したら、悪くなった」という失敗を入口にしていること。**

ほかの導入ページは、ほとんどが「こうすれば良くなる」から入ります。この案は「通れない所を直したら問題が増え、元は仮に置いた動きだった」という、作った本人にしか書けない逆向きの事実から入ります。検証を任された開発者が保存したくなるのは、この部分です。
書き直しの途中で、見出しを「シミュレーションの精度を上げる点検表」のような前向きで無難な形に丸めないでください。「増えた」という言葉は、見出しにそのまま残してください。