案Aで最優先に直すべきなのは、「次に読むログが分かる」から「そのログで何を実行し、どこまで確かめれば次へ進めるかが分かる」への一歩です。現状は結果の比較が強い一方、最も重いゴールである「再現を試す人」を生むための情報が、公開前の照合に預けられています。

1. **【高】再現に必要な情報の表が、まだ再現の可否を判断できる形になっていない**

   **弱い所：** 見せ場2の例は「GPU」と「版」だけです。これでは第三者が、手順・依存関係・バージョンのどこまで確認できたか判定できません。「足りない情報を見せる」という方針を、主指標につながる確認表にする必要があります。

   **こう直せばもっと強くなる：** 段ごとに、次の列を持つ表へ変えてください。

   > 実行すること｜使った環境・依存関係と版｜手順・コードの場所｜入力と確認する出力｜本文・コードとの照合状況

   未照合の欄は、指定どおり「要約には記載なし（本文とコードで照合が要る）」と明示します。その上で公開時に、段ごとにこう書きます。

   > この段で確認できた情報と、まだ欠けている情報を以下に示します。情報が欠けている段は、同じ手順で再現できる環境としては数えていません。

2. **【高】アームなしの入口にも、「実行できた」の判定が足りない**

   **弱い所：** Log#2の「数値を受け取る」は具体的ですが、何と照らして確認するのかがありません。また、LIBEROの「20回中20回成功」が、読者も達成すべき合格条件に見えかねません。これは研究室の実測結果です。

   **こう直せばもっと強くなる：** 段1を、実行と照合の順に書き換えます。

   > **最初に試す：Macから画像と指示文を送り、π0.5の動きの数値を受け取る。**  
   > ［Log#2で手順・コードと出力を確認する］  
   > 使用する入力と出力例は、要約には記載なし（本文とコードで照合が要る）。
   >
   > **次に試す：LIBEROで「黒いボウルを拾って皿に置く」作業を動かす。**  
   > ［Log#3で実行方法を確認する］  
   > 研究室では20回中20回成功しました。試した環境・試行数・成功数を、この結果とは分けて残してください。

   これならログを開く目的が明確になり、ログへの遷移も実行につながります。

3. **【高】「自分のアーム」へ移る時の、情報の境界が見えない**

   **弱い所：** 手で教える方法や50本の条件は具体的ですが、すべてmechArm 270の実例です。読者は、自分のアームで使う際に何を調べ直す必要があるか分かりません。「あなたのアームでは未確認」という一文だけでは、始める判断を支えきれません。

   **こう直せばもっと強くなる：** 段2の冒頭に、次の案内を置きます。

   > ここからは、mechArm 270で通した実例です。お手本の停止時間やつかみの深さを確かめる観点は示せますが、あなたのアームで同じコード・設定を使えるかは未確認です。  
   > アームごとに置き換える箇所と、モデルへ渡すデータの形式・変換手順は、要約には記載なし（本文とコードで照合が要る）。

   さらに「お手本の集め方」と「自分のアームを接続するために未確認の情報」を分けて表示してください。後者の不足も、フォームへ送る具体的な理由になります。

4. **【高】見せ場1に、結果を実際より強く読ませる省略がある**

   **弱い所：** Log#28の「位置1は3回とも直しなし」は、箱に入れるところまで成功したように読めます。要約で確認できるのは「つかめた」です。また「お手本の深さもlossの外」という説明では、学習データを変えたことと、学習せず実機側を変えたことが混ざります。

   **こう直せばもっと強くなる：** 該当行と表の下の文を、次のように直します。

   > 位置1は3回とも直しなしでつかめた。位置2は4回とも、つかむ姿勢まで届かなかった（#28）。

   > lossが下がっても、実機でつかむ・運ぶ・箱に入れることは別に確かめる必要がありました。お手本を作り直して学習した回もあれば、学習し直さず、AIに渡す肩の角度を変えて箱に入った回もあります。電源交換後に位置2の問題も解けたかは、今回の要約では確認できません。

   電源交換の行も「位置5：交換前の日は3回中1回、交換後は5回中5回」として、別の日の試行であることを残してください。

5. **【高】制御ライブラリの説明が、他の環境への版の推奨に見える**

   **弱い所：** 「pymycobot 4.0.4では遅い、2.9.6に戻すと速い」では、問題が起きた実行箇所である「Piのdaemon」が抜けています。読者が手元の版だけを変えても、同じ箇所を確認したことにはなりません。

   **こう直せばもっと強くなる：**

   > **実際に指令を送っている処理は、どの版を読んでいるか。**  
   > mechArm 270では、Piのdaemonがpymycobot 4.0.4を読んでおり、1回の指令に1.6秒かかっていました。2.9.6へ戻すと送信は約0.02秒になりました（#20）。あなたのアームでは、指令を送る処理が実際に使っているライブラリの版と、指令にかかる時間を確かめてください。

   版番号を移植するのではなく、確認方法を持ち帰れる問いになります。

6. **【中】最初の画面が結果の紹介で埋まり、最初の行動が後ろにある**

   **弱い所：** 費用や空振りの事実は強いのですが、最初の画面で読む人が進路を選べません。ログへ進む人を3割にするには、数値を読むだけでなく、その場で選べる入口が必要です。

   **こう直せばもっと強くなる：** 見出し直下を、次の3つのリンクにします。

   > **アームなしで試す** — 借りたA40から、π0.5の動きの数値をMacで受け取る。［Log#2の手順へ］  
   > **自分のアームで学習する準備をする** — お手本の集め方と、mechArm 270で使った学習条件を確認する。［お手本・学習条件へ］  
   > **実機で止まった所を確かめる** — 電源、指令の遅れ、可動範囲、お手本、AIに渡す関節の値を確認する。［5つの問いへ］

   その下に、50本・6.2時間・約579円の実例と、他アームでは未確認という範囲を置きます。

7. **【中】最も重い連絡のゴールに対し、送る記録の形が曖昧**

   **弱い所：** 各節末の同じフォーム案内では、「まだ整理できていないから送れない」と止まりやすくなります。また、届いた連絡が再現の確認に使えるかも、内容次第になります。

   **こう直せばもっと強くなる：** 各段の末尾に、記録として保存でき、そのままフォームへ転記できる短い枠を置きます。

   > **この段を試した記録**  
   > ・試した段／開いたログ：  
   > ・使った環境・アーム（未購入でも可）：  
   > ・分かる範囲の依存関係と版：  
   > ・できた所／止まった所：  
   > ・手順に足りなかった情報：  
   >
   > 空欄があっても送れます。試す前に必要な情報が見つからなかった場合も、［試した記録・足りなかった情報を送る］から知らせてください。

   これは単なる連絡の誘導ではなく、「保存しておきたい」実験記録の型にもなります。

**守るべき尖り**

**lossの改善と実機の達成を、途中の変更を省かず同じ表で見せること。** ここが案Aのいちばん強い所です。「学習できた」という数字だけでは始め方を判断できない読者に、次に何を確かめるべきかを実例で渡せます。表を削るのではなく、各行の「何ができたか」の範囲を厳密にして残してください。