# 案C への評（評者：案Aの作者）

ここでいう「強い」とは、ゴールに効くことです。特に、いちばん重い「再現を試した人からの連絡」と、主指標の判定条件①②③に効くかを見ています。

---

### 1【高】第1段に版を書かないまま公開すると、主指標の①②を満たさない

**弱い所**
第1段（Log#2・#3）の手順、依存関係、版、GPUメモリの値が、すべて「要約には記載なし（本文とコードで照合が要る）」のままです。このまま公開すると、主指標にいちばん近い段なのに「②依存関係とバージョンが記載されている」を満たしません。読む人も、最初の1歩で止まります。未記載を見せる方針は正しいです。ただ、照合する前の状態をそのまま出すことになっています。

**こう直す**
節6の手前に「公開の条件」を1行足します。

> 第1段の2行（Log#2・Log#3）は、本文とコードで「起動の手順・依存関係と版・GPUメモリの実測値」を照合し終えてから公開する。照合しても見つからない項目は「ログにない（未記載）」と表に出す。「要約には記載なし」のまま公開するのは第2・第3段だけにする。

あわせて、照合表に「照合の状態」の列を足し、状態を次の3つから選ぶ形にします。
- 照合済み（ログの該当箇所へのリンク）
- 要約には記載なし（照合中）
- ログにない（未記載）

---

### 2【高】記録を送る道がページの最後に1つしかなく、いちばん重いゴールに効かない

**弱い所**
「試した記録を送る」は節6の末尾にしかありません。このページは実験の横で開き直されることを狙っています。そういう読み方をする人は、自分のいる段を見たら閉じてしまいます。さらに、送るものが「アーム・環境・到達点・止まった箇所」なので、最後まで試した人しか送れないように見えます。ゴールは「再現を試した人、**または試そうとした人**」ですし、主指標の③には「再現に必要な情報が欠けていないことを第三者が確認できる」とあります。つまり「ここが足りなかった」という報告も、主指標の判定根拠になります。

**こう直す**
各段の表の直後に、同じ形の短い案内を置きます。

> **この段まで試した方へ**
> 照合表のどの行まで届いたか、どこで止まったか、表に書いていない版や手順で困った所を、メッセージフォームから送ってください。届かなかった報告も、このページの不足として表に反映します。
> 書き方の例（写してお使いください）
> ・試した記録：π0.5 入口ページ
> ・アーム（なしでも可）：
> ・GPU と借りた所：
> ・届いた行：
> ・止まった所／足りなかった情報：

1行目を「試した記録：π0.5 入口ページ」に固定しておけば、フォームの形を変えずに、このページから来た連絡を数えられます。

---

### 3【高】照合表に、いちばん切り分けたい終点（loss・予測と実機の差）が入っていない

**弱い所**
見せ場の「終点を混ぜない」は、この案の核です。ところが、今の5つの終点（数値を受け取れた／シミュレーションで成功／学習が終わった／つかめた／箱に入った）には、「学習の数値は良いのに実機で外れた」という終点が入っていません。想定読者の困りごとは「モデルが動かないのか、自分のアームとの接続が合っていないのか、切り分けられない」ことです。いちばん効くのは、まさにこの差です。

**こう直す**
終点を6つにして、「学習が終わった」と「実機でつかめた」の間に次の行を足します。

| 終点 | mechArm 270 での実例 | ログ |
|---|---|---|
| 予測がお手本と合った（実機に送る前） | お手本19本・2,000ステップで、お手本の最初の1秒と数度以内で一致。loss 0.1155→0.0054 | Log#5 |
| 実機に送ると外れた | 同じモデルで初めて動かすと、爪がブロックに乗り、手首が指令に届かず止まった | Log#6 |
| 学習を倍にしても外れた | 4,000ステップで loss 0.0030 まで下がったが、爪は2回ともブロックの奥で空を閉じた | Log#7 |

見出しは「loss が下がっても、実機でつかめるとは限らない（mechArm 270 では loss 0.0030 で空振りした）」とします。ログにある事実の範囲で、いちばん強い言い方です。束ねるログに Log#5・#6・#7 を足してください。

---

### 4【中】最初の画面が抽象的で、検索や AI の問いの言葉と合っていない

**弱い所**
「同じ結果まで確かめる」は、何と同じなのかが読めません。最初の3行に、ログの強い数字が1つもありません。ページ名の「実験台帳」も、人が検索するときや AI に聞くときの言葉ではありません。想定読者が AI にまず聞くのは「π0.5 は手元で動くか」です。この問いへの答え（Mac では動かない／A40 を借りれば動いた）がログにあるのに、使われていません。

**こう直す**（新しいキャッチコピーは足さず、ログの事実だけで組みます）

> **π0.5 を自分の小型アームで追加学習して動かす手順（mechArm 270 で1台通した記録から）**
> アームなし：π0.5 は Mac では動かなかったが、Runpod で A40 を借りれば動きの数値を受け取れた（費用0.34ドル・Log#2）。LIBERO のシミュレーションでは20回中20回成功（Log#3）。
> 自分のアームで学習：mechArm 270 ではお手本50本・3,000ステップ・6.2時間・約579円（Log#27）。
> 実機で確かめる：mechArm 270 で詰まった電源・制御ライブラリの版・可動範囲・浅いつかみを、あなたのアームで確かめる問いにして並べた。

URL の `/start-pi05` はこのままでかまいません。ページ名は上の見出しに寄せます。

---

### 5【中】入口の説明が一般論にとどまり、「どこから来るか」が具体になっていない

**弱い所**
「検索・AI・シリーズ・既存 LP」と並べているだけで、どのページのどこに、何と書いて置くかが書かれていません。依頼の数字を使えば、置き場所まで決められます。

**こう直す**
- **/gpu-buy-or-rent**：50%まで読む人は52%いますが、75%では10%に落ちます（21件なので判断はできませんが、置き場所の手がかりにはなります）。案内は末尾ではなく、「借りる」を選んだ段落の直後に置きます。文面は「借りた A40 で π0.5 を動かした手順と結果は、こちらの第1段に並べています」。
- **トップ**：AI の利用者の依頼で読みに来る数は、トップがいちばん多いです。既存の「シリーズ」欄だけでなく、「記録」欄にもページ名を文字のリンクで1行置きます（相談の窓口ではありません）。AI がトップを読んだときに、このページへたどれるようにするためです。
- **シリーズのページ**：「フィジカルAI研究室を作る」シリーズのページ（番号は確認が要ります）の上の資料欄の、いちばん上に置きます。
- **SNS**：来た人が10件あった LinkedIn に絞ります。投稿は第1段の事実（Mac では動かず、A40 を借りれば動いた・0.34ドル）とリンクだけにします。

---

### 6【中】第3段の問いで、ログのいちばん強い数字と切り分けの手がかりを落としている

**弱い所**
- 版の問いに「1回の指令に1.6秒」が抜けています。原因が「**Pi の daemon が**読んでいた版」だったことも抜けていて、ただの「ライブラリの版」になっています。
- 電源の問いに、比べる相手（12V・2A の日は3回中1回）と、「教えた動きの再生も7回すべて成功」が抜けています。後者は、モデルではなく電源の問題だと切り分けた証拠です。
- 依頼が例に挙げた「お手本が浅いつかみになっていないか」が、第3段の問いになっていません。

**こう直す**（問いは4つにします）

> **制御ライブラリは、実際に動いているプロセスがどの版を読んでいるか**
> mechArm 270 では、Pi の daemon が pymycobot 4.0.4 を読んでいて、1回の指令に1.6秒かかった。2.9.6 に戻すと送信は約0.02秒になった（Log#20）。
>
> **電源は足りているか。モデルを使わない再生でも同じ失敗が出るか**
> 本体は40W を求めるのに、つないでいたのは12V・2A（24W）だった（Log#30）。12V・5A に替えると、π0.5 は位置5 で5回とも成功した（2A の日は3回中1回）。教えた動きの再生も7回すべて成功した（Log#34）。
>
> **可動範囲の外の命令が、エラーなしに捨てられていないか**
> 肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられていた（Log#9）。
>
> **お手本が浅いつかみになっていないか。止まっている時間が混じっていないか**
> 学習データ30本中7本が浅いつかみだった（Log#23）。爪がブロックに乗った回は、下ろす時間が普段の1.1秒から7.9〜9.1秒に延びていて、そこで見分けられた（Log#25）。π0.5 はお手本の中の止まっている時間まで覚えていた（Log#11）。

どの問いの下にも「ほかのアームでどうなるかはログにありません。あなたのアームでこの数字を測ってください」を1行添えます。束ねるログに Log#11・#25 を足します。

---

### 7【中】節4の「学習条件と実機結果を対で読む」が、因果を言い過ぎる読み方を招く

**弱い所**
Log#27（学習条件）の直後に Log#28（位置2 で4回とも届かず）を対で置くと、学習が原因だと読まれます。ところが Log#28 は、電源不足が分かった Log#30 より前の記録です。そのときの電源の条件は要約には書かれていません。また、位置2 の原因を調べた Log#29 が束ねるログに入っていません。

**こう直す**
節4の結果の行に、次の注を付けます。

> Log#28 は、電源が足りていないと分かる（Log#30）前の記録です。この試行での電源の条件は要約には記載なし（本文で照合が要る）。位置2 を外した理由は、上カメラの傾きではありませんでした。画像の傾きだけを変えて1,770回答えさせても、行き先は入れ替わりませんでした（Log#29）。原因はまだ特定されていません。

「特定されていない」こと自体を表に残すと、読む人は自分の環境で確かめる項目として持ち帰れます。

---

## 守るべき尖り

**「できた」の終点を混ぜない照合表と、そこに「未記載」の列を正面から置くこと。**

ほかの人の成功の報告は、たいてい「動いた」の1語で終わります。このページは、LIBERO で20回中20回と、実機で位置2 が4回中0回を同じ「動いた」にまとめず、足りない情報まで表に出します。主指標の③（再現に必要な情報が欠けていないことを第三者が確認できる）を、ページの形そのもので満たしにいく、この案だけの骨格です。書き直しで表を読み物に溶かしたり、未記載の列を「注」に格下げしたりしないでください。