3つのAIで作ったページは、1つのAIに勝てるか ― ロボットが止まる瞬間の図鑑

Claude・Gemini・codex の3つの AI が材料を持ち寄って書き、互いに直し合ったページ3本と、Claude 1つだけで書いたページ1本を、どれがどれか伏せて作り手が比べると、いちばん良かったのは codex が書いた版、いちばん悪かったのは Claude が書いた版でした。 3つの AI で作れば必ず勝つのではなく、だれが書くかで、1つの AI の版より良くも悪くもなりました。

その codex の版をもとに、ロボットの導入を判断する経営者と、導入を任された PM に向けたページ「ロボットが現場で止まる瞬間の図鑑」を作り、公開しました。このページで変わることは3つです。

• 配膳ロボット・病院の搬送ロボット・ロボットアームが止まった12の場面を、もとの記録（LOG）を何本も読まずに、1ページで見られる。場面ごとに「入れる前に、自分の現場で確かめること」が付いている
• 前の記事（LOG510）で試せていなかった「1つの AI の版と、3つの AI の版を、伏せて比べる」ことが、仕組みの中に入った。依頼を置けば、Mac が5分ごとに見回って、持ち寄り・1つの AI の版・3本の版・伏せて並べた表までを作る。人がするのは、選ぶことだけ
• ページを作る時間は測っていない。仕組みが3つの AI を動かしている間、作り手は別の作業をしていた

前の記事「YouTubeの企画を良くしようと、3つのAIに話し合わせた」では、3つの AI に YouTube の企画を6通りのやり方で話し合わせても、作り手が見たいと思う題材は1本も出ませんでした。同じ仕組みをサイトに向け、研究の記録から人の入口になるページを作らせたところ、はじめは同じことが起きました。60回の会議で残ったのは「π0.5 と mechArm 270 の実験記録への入口」のような、だれにも怒られない案で、作り手の答えは次のとおりでした。

ダメだ。なんかいまいちだね。色々ゴネゴネしてて伝わらなそう。

ここで、なぜ3つの AI を使うのかを作り手に聞かれ、作り手自身が答えました。

1本のAIでは出せない価値のあるコンテンツを、別々のAIの話し合いで作れるかを確かめること。

そこで、話し合いでまとめるやり方をやめ、AI ごとに、その AI にしか取れない材料を持ち寄らせることにしました。Claude は記録の全文を読み、Gemini は Web で経営者の悩みを調べ、codex は記録と照らして数字を確かめます。そのうえで3つの AI が別々にページを書き、ほかの2つが「読む人が初めて得るものは何か」だけを問うて直させ、最後に Claude 1つだけで書いた版と伏せて並べます。やったことの全体は次のとおりです。

伏せて比べた4本と、その作り方は、下の図で1本ずつ開いて見られます。

伏せて比べたのは1回だけで、選んだのは作り手1人です。この1回で言えるのは、「3つの AI で作れば勝つ」でも「1つで足りる」でもなく、3つの AI の版が1つの AI の版に勝ったのは、数字の確かめを持ち寄った codex が書いたときだった、までです。

ここから下は作業ログです。会議と制作チームのやり方、図鑑のページを作って直した順番、仕組みとページのコード、AI が書いたファイルを全部載せます。効果のうち、ページの見られ方と問い合わせへの効き目は見込みで、公開後のサイトの計測で確かめます。

作業ログ ― 3つの AI と、Mac から動かす仕組み

Claude・Gemini・codex と、それぞれの呼び方

3つとも、作り手の Mac から、人が操作しなくても呼べるようにしてあります（前の記事 LOG510 で作った仕組みを使い回しています）。

決まった時刻にプログラムを動かすのは、Mac の launchd（決めた間隔でプログラムを起こす、Mac に入っている仕組み）です。依頼のフォルダに かける.txt という印のファイルを置くと、5分ごとの見回りがそれを見つけて回し始めます。終わると印は かけた.txt に変わります。

合議と制作チームの違い

この記事で何度も出てくる言葉を2つ、先に分けておきます。

作業ログ ― 1回目：60回の会議（合議）で、入口のページの案を出させた

YouTube の企画会議の仕組み（kikaku.py。LOG510 に全文）を、サイトにも使えるように広げました。依頼のフォルダに 前提.md（全員に共通の約束）・段階.json（会議の段階）・番.md（codex の役）を置くと、YouTube 用の決まりの代わりにそれを使います。サイトの会議は サイト改善/_企画/ に置き、YouTube の会議と同時に3つまで回せるようにしてあります。

最初の依頼で決めたのは、作り手の次の2つの決まりです。

サイトはYouTubeに比べて題材を広げるのは基本NGです。

うちのページは記事というよりログなので、ログの形式は変えません。ログをベースに人の入り口となる記事やページ、LPなどを別途作るのはOKです。

60回の会議は約33分で終わり、Gemini の費用の目安は約313円（Pro 11回・Flash 43回）、codex は6回でした。最後に残った3案は次のとおりです（全文は下の「AI が書いたファイル」）。

3案とも、各ページの注意書き（「同じ結果を保証する手順書ではありません」「実店舗の効果を保証しません」）を最初の画面に置いていました。合議で反論を通るたびに、断り書きが増えた形です。

作り手から、何を達成したくてそのページを作るのか、どれだけの期間に、どんな人が、どれくらい来て、相談がどれだけ増えればよいのかを聞かれました。案はあっても、ゴールがありませんでした。そこで、ゴールを「公開から3か月で、人の表示150件・再現を試した（試そうとした）人からの連絡1〜2件」と置きました。

作業ログ ― 2回目：制作チームで3回かけ直し、最初の版と最後の版を伏せて比べた

合議をやめ、新しく site_team.py（サイトの制作チーム。全文は下の「コード」）を作りました。3つの AI が互いの案を見ずに企画書を書き（第1版）、ほかの2つが「弱い所」と「こう直せばもっと強くなる」の組で指摘し、作者が書き直す、を2往復させます。評者には、作者がどの AI かを伏せ、案A・案B・案C と呼ばせます。案を捨てさせる権限はだれにもありません。

最後に、案ごとに最初の版（v1）と最後の版（v3）を、どちらがどちらか伏せて並べ（甲と乙）、作り手が選んでから答えを開く形にしました。話し合いで本当に良くなったかを、作り手の目で確かめるためです。

3回目の「始める入口_アームを問わない」で、作り手が甲と乙を選んだ結果は、3本のうち2本で最後の版（批評のあと）でした。話し合いで良くなった、と言える数字です。ただ、作り手はこう言いました。

ダメだ。なんかいまいちだね。色々ゴネゴネしてて伝わらなそう。

3本とも、ほかのアームでも始められると言いながら、例には mechArm 270 を使い続けていて、mechArm 270 を前提にしない約束が守られていないと作り手に指摘されました。良くなったのは文の正しさで、ページを読む理由は増えていませんでした。

作業ログ ― 合議が無難になる理由と、持ち寄りへの組み直し

なぜ3つの AI を使うのかを聞かれ、作り手は「1本のAIでは出せない価値のあるコンテンツを、別々のAIの話し合いで作れるかを確かめること」と答えました。2回目までのやり方は、この目的に向いていませんでした。理由は2つです。

作り手に、ここで止めずに考え直すよう言われ、仕組みを組み直しました。変えたのは3つです。

• 持ち寄り：3つの AI が書き始める前に、その AI にしか取れない材料を1つずつ作らせる。Claude は 材料/ の記録の全文を読み、Gemini は Google 検索で外の報道と悩みを調べ、codex は記録の全文と照らして要点の数字を確かめる。依頼のフォルダに 持ち寄り.json（AI ごとの役）を置くと、この形で回る

• 価値だけを問う批評：評者が問うのは「読む人が、このページで初めて得るものは何か」の1つだけにした。ほかでも手に入ることは「削る」か「この現場の数字で強くする」かを、書き換えの文面つきで示させる

• 1つの AI の版：同じ依頼から、Claude 1つだけで、持ち寄りも話し合いもなしにページを書かせる（1本/v1.md）。3つの AI の版と伏せて並べ、どれがいちばん良いかを作り手が選ぶ

• ねらい：3つの AI の違いを、考え方ではなく、取れる材料の違いから出す。話し合いの効き目を、1つの AI の版と比べて確かめる

• 変わったこと：3つの AI が同じ一覧から書いていたのが、記録の全文・外の報道・数字の照合の3つの材料を持ち寄って書くようになった。比べる相手に、Claude 1つの版が入った

• 見込める効果：1つの AI の版より良いかどうかを、作り手が伏せたまま選べる（結果は下の「4本を伏せて比べた結果」）

作業ログ ― 3回目：読み手を経営者・PM に決め直し、図鑑の企画にした

作り手から、フィジカルAI という言葉に反応するのはどんな人たちだと考えているかを聞かれました。それまでの案は、π0.5 で小型アームを動かしたい開発者を読み手にしていました。考え直した見立てでは、「フィジカルAI」という言葉に反応するのは、導入を判断する経営者・PM・投資家が中心で、関心は技術より「導入の判断」と「実験止まりで終わらせないこと」にあります。

続けて作り手は、結局は記録（LOG）の情報の濃さに提案が左右されるのか、と聞き、それを超えてもっと面白い企画を出すよう求めました。Claude が出した企画のうち、作り手が「いちばん刺さった」と言ったのが「ロボットが現場で止まる瞬間の図鑑」です。カタログや営業資料には書いていない「入れてから分かること」を、記録から12の場面に集めます。

12の場面は次のとおりです（依頼の表のまま。数字は持ち寄りで記録の全文と照らしました）。

作業ログ ― 4本を伏せて比べた結果

持ち寄り、1つの AI の版、3本の第1版、批評、書き直しまでを、仕組みが22:20に終えました（書き直しは1往復）。作り手は、①〜④のどれがどれかを知らないまま、いちばん良いものと、いちばん悪いものを選びました。

字数は、比べる.md に入った各版の文字数（Python で数えた値）です。

④と①の違いは、書き出しと、項目ごとの欄に出ていました。

④の「測った条件」の欄（たとえば「編集された実店舗動画4例の観察。秒数は動画上の概算で、待ち時間には下限を含みます」）は、codex が持ち寄った数字の照合から来ています。シミュレーションの数字を、実店舗で必ず起きることのように読ませないための欄で、公開したページにもそのまま残しました。

Claude 1つの版（③）は、いちばん良くも悪くもありませんでした。一方で、同じ Claude が3つの AI の材料と批評を受けて書いた版（①）は、いちばん悪くなりました。材料が増えた分、まとめの節と章が増え、①の字数は③より長くなっています。

この比べ方には、弱い所が2つあります。

• 1回だけで、選んだのは作り手1人。どの AI が書くかで結果が変わることは分かったが、codex が書けばいつも勝つとは言えない
• Claude 1つの版は、持ち寄りと同じフォルダで書かせた。版の冒頭で「ほかの作者のページ（持ち寄り/ の中）は開いていません」と書いているが、開けない作りにはしていなかった。次からは、別のフォルダで書かせる

作業ログ ― 図鑑のページ（/robot-stops）を作って公開した

④の文面と順番をもとに、サイトの p2m-site（このサイトのコードの置き場所）に src/pages/robot-stops.astro を作りました。最初の版を出したあと、作り手に見てもらいながら直しました。直した順に並べます。

• ねらい：導入を判断する人が、文章を読む前に「どの現場で、何が止まったのか」を目で見て分かるようにする
• 変わったこと：最初の版は文字だけのカードが12枚並んでいた。いまは、場面ごとに画像が主役のカードになり、サービスロボットとロボットアームはタブで分かれている
• 見込める効果：ページの終わりまで読まれる割合が上がる見込み。サイトの計測で、/robot-stops の表示と、最後の「相談する」のボタンが押された数で確かめる

3つの場面の画像を、シミュレーションの録画から切り出した

「2台目で待ちが延びる」「下げ膳中、通路をふさぐ」「席は空いているのに案内できない」の3場面は、最初は記録に載せた図や表を使っていました。これを、ServiceSim（Unity で作った配膳ロボットの店のシミュレーション）の1日分の録画から、その場面が起きている1コマに替えました。どの時刻を切り出すかは、録画と一緒に残している記録（CSV）から探しました。

斜め上の録画は、録画と一緒に残しているカメラの記録（_camera.json の行列）で、ロボットのいる店の座標（1.76, 10.28）を画面の位置（1,135, 1,294）に直して、まわりを切り出しました。どの画像も、主役をオレンジの丸で囲んでいます。カードは高さに合わせて画像の端を切るので、2台目と片付けの画像は、主役が切れないよう4:3に切り直しました。

最初の画面の動画は、録画の右側に数字の板（店の時計・止まった回数など）が付いていました。数字は小さくて読めず、ページの見出しの数字とも違うので、3Dの店の部分（1360×766）だけを切り出して作り直しました。

トップと /series8 に、図鑑への入口を置いた

入口は、作り手と次のように決めました。

公開したあと、作り手から、バナーにはサービスロボットだけでなくアームも一緒に載せるよう指示がありました。図鑑はサービスロボットとロボットアームの両方を載せるページだからです。バナーの画像を、左にシミュレーションの2台、右に実機のアームの爪とブロックの写真の2枚並びにしました。押された数は、サイトの計測で「TOPガイド:図鑑」「series8:図鑑」の名前で数えます。

作業ログ ― 仕組みとページのコード（全量）

site_team.py は Mac の サイト改善/_仕組み/ に置き、launchd が5分ごとに動かします。Gemini と codex の呼び方は、LOG510 の debate_runner.py を読み込んで使い回しています。API の鍵はコードに書かず、キーチェーンと Mac の設定のフォルダから読みます。ページのコード3本は、サイト（p2m-site）に入っている版です。

site_team.py（サイトの制作チーム。持ち寄り・1つの AI の版・伏せて比べる表まで）

#!/usr/bin/env python3
"""site_team.py — サイトの入口のページを、3社の AI の「制作チーム」で作る（合議はしない）.

合議（全員の批判を通る案を残す）にすると、残るのは価値のある案ではなく、誰も反論できない無難な案になる。
そこで、ひとつにまとめず、作者ごとの案を磨いて並べる。

流れ（1つの依頼につき）:
  1. 3社（Claude・Gemini・codex）が、互いに見せずに企画書を1本ずつ書く（v1）

robot-stops.astro（図鑑のページ /robot-stops）

---
// ロボットが現場で止まる瞬間の図鑑（LP。LOG の記事ではない）
// 伝えること：カタログには書いていない「入れてから分かる止まり方」と、入れる前に自分の現場で確かめる問い
// 誰に：ロボットの導入を判断する経営者と、導入を任された PM（飲食・病院・物流など）
// 中身は 2026-11-14 のサイトの制作チーム（サイト改善/制作/止まる瞬間の図鑑/）で、エイイチが4本から選んだ案（作者 codex・持ち寄りと話し合いのあと）を土台にした
// 画像・動画は、自分で撮ったものとシミュレーションの画面だけ。SNS・他社の動画から切り出した画像は使わない（使用許可がないため。2026-11-14 エイイチの指摘）
// 数字はすべて出典のログ本文から。新しい数字を足すときは、ログ本文で確かめてから
import Base from '../layouts/Base.astro';

GuideCards.astro（トップの導入前ガイド。3枚目が図鑑への入口）

---
// TOP の「導入前ガイド」：LP 2つ（GPU を買うか借りるか・配膳ロボットの導入前シミュレーション）への入口を横に並べ、
// その下に、ロボットが現場で止まる瞬間の図鑑（/robot-stops）への入口を横いっぱいで置く（2026-11-15）
// GPU は黒い面で、背景の写真の上に文字をそのまま置く。配膳ロボットは明るい面に、文字を左・店の立体の絵（SVG・試算と同じ店）を右に置く
// 3D の店の録画は高さ 720px までしかなく粗く見えたため、どの大きさでも粗くならない線の図にした。
// 縦に切り抜くと何の図か分からず、白黒の平面図は色味がなかったので、同じ店を斜め上から見た立体の絵（tools/make_cta_iso.py で作る）を切らずに置く
// 配膳ロボットの数字（○/99条件）は、ここだけでは意味が分からずノイズに見えたので載せない（2026-10-24）
// 2枚がひと目で別のものと分かるように、面の色と組み方を変える（中身の順番はそろえる）。/series6 は GuideBanner（1本）のまま

RobotStopsBanner.astro（/series8 の図鑑へのバナー）

---
// ロボットが現場で止まる瞬間の図鑑（/robot-stops）への入口。/series8 の配膳ロボットの LP のバナーの下に置く（2026-11-15）
// 形は ServingBanner と同じ（明るい面・左に文字・右に画像）。図鑑はサービスロボットとロボットアームの両方を載せるので、2枚を左右に並べて枠いっぱいに敷く
// 組み方はバナーの幅で切り替える（画面の幅ではない）。720px 未満では絵を上・文字を下に置き、文字が絵に押されて細くならないようにする
---
<div class="rsb-wrap">
  <a class="rsb-bn" href="/robot-stops" data-ev="series8:図鑑">
    <span class="rsb-img"><span class="rsb-ph"><img style="object-position:30% 55%" src="/media/robot_stops_02_second_robot_v2.jpg" alt="店を真上から見たシミュレーションの画面。2台の配膳ロボットが一本道で向かい合って止まっている" loading="lazy" /></span><span class="rsb-ph"><img style="object-position:35% 50%" src="/media/robot_stops_arm_gripper.jpg" alt="実機のロボットアームの爪が、赤いブロックの奥で閉じている" loading="lazy" /></span></span>

作業ログ ― AI が書いたファイル（全量）

回ごとのフォルダの中身を、そのまま載せます。載せていないのは、次の4つです。どれも作業フォルダ（記事/LOG511_data/site_kaizen_src.tgz）に残しています。

• 図鑑の 材料/：12場面のもとにした記録（LOG）の写し24本。公開済みの記事と同じものです
• 制作チームの 並べた.md と 比べる.md：各案の最後の版や第1版を、並べ替えて1つにしただけのファイル。どの版がどれだったかは _答え（見ないで）.json に載せています
• 会議の 状態.json：仕組みの中の状態の記録
• 印のファイル（かけた.txt）と、書き直しの回数（回数.txt）

住んでいる場所の地名は「（地名）」に置き換えました。それ以外は書き換えていません。

1回目：60回の会議（_企画/入口のページ/）

会議の依頼.md（会議への依頼）

# 企画会議の依頼：今あるログから、人の入口になるページを決める

## 何を決めるか
pixelstomotors.com（Pixels to Motors）に、人の入口になるページ（ログをまとめたページ・LP）を別に作る。
どのテーマで・だれに向けて・どのログを束ねて作るかを決め、上位3本を、作れるところまで具体にする。

## 守ること（エイイチが決めたこと。これに反する案は出さない）
- **ログの形式は変えない。** 個々のログ（/record/…）は記事ではなく記録。見出し・書き方・ひな形には手をつけない

会議の前提.md（全員に共通の約束）

# 議論の前提（全員に共通）

あなたは、Webサイト「Pixels to Motors」（pixelstomotors.com）に、人の入口になるページを作るための議論に参加しています。
参加者は Claude・Gemini・codex の3つの AI です。採るかどうかは、最後に人間（エイイチ）が決めます。あなたは材料を出す役です。

- 個々のログの形式を変える案、新しい題材を足す案は出さない。入口のページは、依頼の「ログ一覧」にある中身だけで作る
- 表示の数を稼ぐための誇張・釣り・煽り、中身と合わない見出しは、伸びそうでも提案しない
- 日本語で書く。英語の文を混ぜない
- 数字を言うときは、根拠（依頼の実際の数字・調べた出典・推測）のどれかを必ず添える。推測は推測と書く。30件未満の数で言い切らない
- 話を丸くまとめず、ほかの AI と意見が割れる所は割れたまま書く

# ボードの書き方
- ボードは2,500字以内。案ごとに、ページの名前・だれがどこから来るか・束ねるログ（タイトルか /record/… を3〜10本）・最初の画面に何を出すか・いまの評価・残っている疑問・作る手間（小／中／大）を書く

会議の番.md（codex の役）

# あなたの役：中身と数字の番（codex）
ボードの案が、依頼の「ログ一覧」と「実際の数字」と合っているかを確かめる。
- 束ねるログが実在するか、ログにない中身（新しい題材）を足していないか
- 効果の見込みに根拠のない楽観がないか、30件未満の数で言い切っていないか
- 見出しや説明が中身より言い過ぎていないか（釣りになっていないか）
甘い所はボードを直す。必要ならウェブで確かめる。

会議の役.json（AI ごとの役）

[
 ["ロボット導入を判断する経営者の来訪者", "飲食・小売・病院などでロボット導入を判断する立場。Google で「配膳ロボット 費用」などを調べて、個々のログに着いた。忙しく、数字とお金で考える。何のページか、自分の判断に使えるかを最初の画面で決める"],
 ["導入を任された PM の来訪者", "ロボット導入のプロジェクトを任された人。現場とメーカーの間に立つ。上に説明できる材料と、現場で起きることの具体を探している"],
 ["実験が好きな開発者の来訪者", "ロボットや AI のソフトを書く人。π0.5 や mechArm などを自分でも動かしたい。手順・コード・依存関係がそろっていて再現できるかで見る。前提の甘さにすぐ気づく"],
 ["利用者の代わりに読む AI", "ChatGPT・Claude・Perplexity が、利用者に聞かれてこのサイトを読みに来た立場。1ページで何が分かるか、根拠の数字と出典がどこにあるか、引用しやすい形かで見る"],
 ["情報設計の編集者", "今ある記録から入口を組み立てるのが得意。新しい中身は作らず、並べ方・束ね方・見出しで分かりやすくする。最初の画面と、次にどこへ進むかに厳しい"],
 ["穴を突く役", "今の案のいちばん弱い所を探して突く。みんなが賛成している案ほど疑う。数が少ないのに言い切っている所、作る手間を軽く見ている所を止める"],
 ["エイイチの目的を守る役", "Mission（再現できる形で公開し、同じ環境から研究を始められる人を増やす）と、守ること（ログの形式は変えない・題材を広げない・相談の窓口をトップに出さない・新しいキャッチコピーを足さない・研究を止めない）からずれていないかを見る"]
]

会議の段階.json（会議の段階）

[
 [0.20, "出す", "入口のページの案を出す段階。いまのボードにない案を1〜3本足す。テーマ・だれ向け・束ねるログを必ず書く。ログ一覧にない題材は足さない。似た案を足さない"],
 [0.60, "揉む", "案を揉む段階。ボードの案の穴を突き、直し、合わせ、見込みのない案は理由を書いて捨てる。今ある LP（/serving-robot-one-less-staff・/gpu-buy-or-rent・/one-year）やトップ・シリーズのページとどうつなぐかも考える"],
 [0.90, "絞る", "絞る段階。5つの軸（届けたい相手の役に立つ・最初の画面で何のページか分かる・再現できる知見にたどり着ける・AI が読んで引用しやすい・作る手間が小さい）で点を付け、上位5本に絞る"],
 [1.01, "仕上げる", "仕上げる段階。上位3本について、ページの名前・URL の案・だれがどこから来るか・最初の画面の見出しと3行・構成（4〜6つの節）・束ねるログ（/record/… の一覧）・トップや今ある LP やシリーズのページとのつなぎ方・公開後に見る数字と判断する時期（30件たまるまでは判断しない）を書く。前の回の書き方をよくする"]
]

会議の進み具合.md（会議の進み具合と費用）

# 進み具合（入口のページ）

- ■■■■■■■■■■■■■■■■■■■■ **60 / 60 回**（段階：終わり）
- 始めた時刻 2026-11-14 18:37+09:00・最後に書いた時刻 2026-11-14 19:10
- Gemini の費用の目安 約313円（Pro 11 回・Flash 43 回）・codex 6 回（ChatGPT Plus の枠）
- 止めたいときは、このフォルダに 止める.txt を置く（いまの回が終わったら止まる。消せば続きから）
- 会議は終わりました。最終案.md を見てください

会議のログ.md（60回の発言）

# 会議のログ（入口のページ・新しい発言が上）

## 60 / 60｜仕上げる｜codex（中身と数字の番）（19:10）

前回の「電源や版を先に示す」には賛成です。ただし、一覧の電源交換ログだけから「この環境では必ず同じ電源が必要」とは言えません。「準備の必須条件」ではなく「動作前に確認する記録」とします。

案2の「実店舗での計測値を並べています」は削除します。一覧には測定方法とデータ受領への準備はありますが、実測値が届いた根拠はありません。また、入口ページに短い注意書きを置くことは、個別ログの形式変更でも新しい題材の追加でもありません。「注記禁止」という前々回の解釈には反対です。案1は再現保証を含む名前を改め、案3の脱調という対象外の説明も外します。

会議の最終案.md（最後に残った3案）

# 最終案（入口のページ・60回の会議のあと）

順位・手間・想定経路は推測による編集判断。効果の優劣は未確認。ログは依頼一覧との照合済みで、本文・添付ファイルの整合確認は公開前に必要。個別ログは変更しない。

■案1
・ページ名／見出し：π0.5とmechArm 270の実験記録への入口
・URL案：/pi05-mecharm-records
・だれ・どこから：小型アームで学習と実機動作を試したい開発者。関連シリーズ、検索、AIの回答リンクから（経路は推測）。
・最初の画面：見出し、次の説明、工程別のログリンク。
　借りたGPUでの推論から、小型アームの実機実験までの記録です。
　学習、実機で残った失敗、電源交換の記録を工程別に案内します。
　当時の環境での結果であり、同じ結果を保証する手順書ではありません。
・構成：環境と動作前の確認／追加学習／実機で残った課題／人による修正。
・束ねるログ（以下すべて /record/ 以下）：
　/record/openpi-remote-inference-first-run
　/record/mecharm-270-5a-adapter-stops-dropping-block
　/record/pi05-mecharm-demo-to-inference
　/record/pi05-even-demos-on-arm-misses-position-2
　/record/retrained-pi05-still-needs-human-corrections
・つなぎ方：フィジカルAI研究室のシリーズ上部から入口へ。入口から各ログとシリーズ一覧へ。トップは既存のシリーズ導線を使う。
・いまの評価：優先。研究資産への案内として目的に近い。ただし入口を作るだけで再現可能な環境が増えたとは数えない。
・残る疑問：各時点のコード・環境が揃い、読者が対応関係を追えるか。
・手間：中（推測。環境と成果の対応確認を含む）。

■案2
・ページ名／見出し：配膳ロボットの試算条件を読む
・URL案：/serving-robot-simulation-conditions
・だれ・どこから：導入を判断する経営者、担当PM。既存の配膳ロボットLP、検索、AIの回答リンクから（経路は推測）。
・最初の画面：見出し、次の説明、費用・人員・通路・測定へのリンク。
　配膳ロボットの費用、人員、通路について試算した記録です。
　掲載する結果はモデル上の試算で、実店舗の効果を保証しません。
　店で測る方法と、測定値を試算に反映する準備も案内します。
・構成：費用と補助金／スタッフ数による違い／台数・通路とモデルの限界／店舗での測定方法。
・束ねるログ：
　/record/serving-robot-cost-subsidy
　/record/understaffed-famires-robot
　/record/large-restaurant-five-serving-robots-longer-wait
　/record/serving-robot-bussing-depends-on-aisles
　/record/check-serving-robot-sim-with-phone
　/record/serving-robot-sim-ready-for-store-data
・つなぎ方：既存LP /serving-robot-one-less-staff と「試算の条件・限界」で相互リンク。/series8 の上部からも案内。
・いまの評価：次点。判断材料を探しやすくする意義はあるが、導入可否を回答するページにはしない。
・残る疑問：既存LPとの差が伝わるか。費用・補助金の記録時点と適用条件を本文で確認できるか。
・手間：小（推測。短い注意書きとリンク分類に限定）。

■案3
・ページ名／見出し：mechArm 270の症状から探す実装記録
・URL案：/mecharm-270-debug-index
・だれ・どこから：把持、停止、座標ずれで詰まった開発者。関連シリーズ、検索、AIの回答リンクから（経路は推測）。
・最初の画面：見出し、次の説明、症状別リンク。
　mechArm 270の実装で起きた症状から記録を探せます。
　ブロックの落下、動作停止、認識座標のずれを扱います。
　独自の制御環境での記録なので、症状が同じでも原因は異なり得ます。
・構成：掴んでも落とす／安全装置で止まる／制御処理が動かない／認識座標がずれる。
・束ねるログ：
　/record/push-hold-stops-the-drop
　/record/joint-guard-that-stopped-normal-motion
　/record/place-servo-never-fired-import-bug
　/record/template-match-center-was-the-corner
・つなぎ方：実機とデジタルツインを扱うシリーズ上部から案内。入口から症状に対応するログへ直接送る。
・いまの評価：候補として残す。対象症状は明確だが、別環境でも役立つかは未確認。
・残る疑問：読者が自分の環境との違いを本文から判断できるか。
・手間：小（推測。症状名とリンクの編集に限定）。

■公開後の確認・判断時期（全案共通）
入口ごとに、人の閲覧、検索・AIサービスのリンク・既存ページからの流入、各ログへの遷移を確認する。AIの依頼による取得は人の来訪と分けて記録する。各評価対象が30件たまるまでは判断しない（依頼の基準）。到達後も改善の証明とはせず、流入元と閲覧期間を併記して継続・修正を判断する。再現可能な環境の数は閲覧数と別に確認する。

2回目の1：入口のページ（制作/入口のページ/）

入口のページの依頼.md

# 制作の依頼：今あるログから、人の入口になるページを1本企画する

## 何を作るか
pixelstomotors.com（Pixels to Motors）に、人の入口になるページ（ログを束ねたページ・LP）を別に作る。
あなたは、その企画書を1本書く（または、ほかの作者の企画書を強くする）。

## サイトのねらい
- Mission：Physical AI が学習できる環境を作り続け、その知見を再現できる形で公開し、同じ環境から研究を始められる人を増やす

入口のページの案A/v1.md（作者 codex・第1版）

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

**ロボットの詰まりを、シミュレーションの作りから点検する**  
URL：`/check-robot-simulation`

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

搬送ロボットの導入検証を任され、病院のシミュレーションを作っている開発者。

入口のページの案A/批評1_案Bの作者から.md（評者 Claude・1回目）

# 案A「ロボットの詰まりを、シミュレーションの作りから点検する」への指摘

---

### 指摘1【高】表のいちばん大事な列が欠けている：「シミュレーションの作りのせいか、現場でも起きることか」

**弱い所**
この人がいちばん困っているのは「この結果を導入判断に使ってよいか」です。ところが点検表は、4つの事例をまとめて「原因として判明したモデルの作り」と呼んでいます。

入口のページの案A/批評1_案Cの作者から.md（評者 Gemini・1回目）

案Aの作者へ。
シミュレーションの沼にはまっている開発者に向けて、「ロボットではなく、シミュレーションの作りそのものを疑え」と突きつける着眼点、すごく良いです。ただ、今の書き方だと「他所の事例の報告書」に見えてしまい、当事者の痛みに刺さりきっていません。この案が持つ本来の鋭さを引き出すために、以下6点、攻めさせてもらいます。

### 【高】最初の画面が「事例の報告」になっていて、読者の痛みを突けていない
**弱い所：**
見出し「仮に置いた職員の動きが、搬送ロボットの問題を作っていた。」は、単なる1つの結果報告です。読者は「現実に近づけようと修正しているのに、なぜか結果が悪化する」という理不尽さに絶望しています。その痛みに直接刺さっていません。

**こう直せばもっと強くなる（具体の書き換え案・文面）：**
読者の行き詰まりを代弁し、解決の方向を強く示す見出しにします。
- **見出し：** 病院を現実に近づけるほど、搬送ロボットの問題が増える。直すべきは経路ではなく、シミュレーションの前提だった。
- **下の3行：**
  通れない所を直したのに、ロボットの衝突が増える。その原因は、ロボットの設定ではなく「職員に与えた仮の動き」にありました。
  現実を足すほど動けなくなる時、疑うべきはモデルの隠れた前提です。
  病院や店舗のシミュレーションで、詰まりを直す前に点検すべき「作り」の穴をたどります。

### 【高】第4節で「病院」から「ファミレスの試算」に急に飛び、読者が離れる
**弱い所：**
読者は「病院の搬送ロボット」で悩んでいるのに、第4節で急に「配膳ロボットの試算」がそのまま提示されると、「自分には関係ない」とページを閉じてしまいます。題材は変えずに、病院の開発者にも刺さる「抽象化された教訓」として提示する必要があります。

**こう直せばもっと強くなる（具体の書き換え案・文面）：**
ファミレスの事例であっても、環境構築の普遍的な点検として書きます。
- **文面案：**
  **第4節｜ロボットを入れる前に、まず「ロボットなし」で現実と合うか**
  使うログ：`/record/audit-simulator-before-unity` ほか
  ファミレスの配膳ロボットの検証では、立体の店でロボットを走らせる前に、まず「ロボットなし」の条件で試算とシミュレーションを合わせました。病院の検証でも、ロボットが詰まる前に、まず人のみの動きが現実の環境と合っているかの照合が土台になることを示します。

### 【中】ページ名が平坦で、「保存しておきたい」と思わせるフックが弱い
**弱い所：**
「ロボットの詰まりを、シミュレーションの作りから点検する」というページ名は、無難なマニュアルのようで刺さりません。読者の「自分のシミュレーションが信じられない」という悩みにフォーカスした方が強いです。

**こう直せばもっと強くなる（具体の書き換え案・文面）：**
- **ページ名案：** シミュレーションを現実に近づけると破綻する時の点検表 ── 搬送・配膳ロボットの詰まりの本当の原因
- **URL案：** `/simulation-premise-checklist`

### 【中】見せ場である「点検表」の具体例が弱く、凄みが伝わらない
**弱い所：**
「観測したこと／原因として分かったこと／元ログ／自分の環境で確認する問い」という構成は素晴らしいですが、説明が抽象的です。実際のログの事実を使った強烈な対比を見せることで、この企画の解像度が跳ね上がります。

**こう直せばもっと強くなる（具体の書き換え案・文面）：**
見せ場の説明に、実際の点検表の文面を書き込みます。
- **文面案：**
  【観測】病院の通れない所を直したら、問題が減るどころか増えた
  【本当の原因】職員の移動に与えていた「仮の動き」が、新たな衝突を生んでいた（ログリンク）
  【確認する問い】環境を現実に近づけた時、周りの人や物の動きは「仮のまま」残っていないか？

### 【中】第2節の「線に縛った作り」の教訓が、読者のアクションに直結していない
**弱い所：**
「ロボットを線に縛った作りが詰まりの元になり、地図を渡すと詰まりが減った」という事実の提示だけでは、病院のシミュレーションを作っている読者が「自分のモデルのどこを見直せばいいか」ピンときません。

**こう直せばもっと強くなる（具体の書き換え案・文面）：**
- **文面案：**
  **第2節｜ロボットの「移動の縛り」が、架空の詰まりを生んでいないか**
  使うログ：`/record/serving-robot-fixed-route-jam` ほか
  配膳ロボットの検証では、ロボットを線に縛った作り自体が詰まりの元でした。点検表には「シミュレーション上の制約（線の縛り）が、現実には起きない詰まりを人工的に作っていないか」という問いを置きます。

### 【中】第5節の「スマホで測る」が、シミュレーション開発者の次の行動として遠い
**弱い所：**
「店のスマホで測って試算を確かめる」という行動は、PCで病院のシミュレーションと格闘している開発者にとって、少しハードルが高く飛躍して見えます。「現場のデータを受け入れる準備」という側面に光を当てると、読者の文脈とつながります。

**こう直せばもっと強くなる（具体の書き換え案・文面）：**
- **文面案：**
  **第5節｜現場のデータが届いた時、すぐ直せる「受け皿」はあるか**
  使うログ：`/record/serving-robot-sim-ready-for-store-data` ほか
  シミュレーションを作り込むだけでなく、現場で測った実際の数字が届いた時に、すぐモデルを直せる準備（受け皿）があるかを示します。点検表の最後に「自分の環境では未確認の前提／次に現場で測るべき数字」の記入欄を置き、PCの前から現場へ検証を進める後押しをします。

---

### 守るべき尖り（この案のいちばん良い所）
**「問題が起きた時、ロボットの挙動ではなく『シミュレーション側の前提（仮の動き、線の縛り）』を疑う」という着眼点。**
導入検証で沼にハマり、「この資料で判断していいのか」と孤独に悩んでいる開発者にとって、この「メタ視点での点検表」は間違いなくブックマークして手元に置いておきたい価値を持っています。この鋭い切り口は絶対に消さないでください。

入口のページの案A/書き直し1.md（作者 codex・採否と書き直し・1回目）

【採否】

- B・指摘1：一部採る。原因と確認範囲を分ける。ただし、作りの問題を除いても、残る結果を導入判断に使えるとは保証しない。
- B・指摘2：採る。ログ一覧では原因のつながりを確認できないため、第35・36回を結び付けた記述を削る。
- B・指摘3：一部採る。病院の前提修正を入口に加える。「4割減」の結果は、この点検表では扱わない。
- B・指摘4：一部採る。問いを含む本文と文字の表を置く。AIに選ばれることや、元ログから来訪できることは前提にしない。
- B・指摘5：採る。最初の画面で「次に何を確かめるかを決める」と明示する。
- B・指摘6：一部採る。瞬間移動が消えた記録を加える。発生原因や検出の割合は、一覧以上に補わない。

入口のページの案A/v2.md（作者 codex・第2版）

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

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

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

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

入口のページの案A/批評2_案Bの作者から.md（評者 Claude・2回目）

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

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

---

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

入口のページの案A/批評2_案Cの作者から.md（評者 Gemini・2回目）

案Aの作者へ。
現場の開発者が必ずぶち当たる「直したのに悪化する」という絶望感を起点にした、非常に実用的な企画だ。単なる成功事例ではなく、失敗と修正のプロセスを「点検表」としてツール化するアプローチは、ターゲットに深く刺さる。

だが、今のままでは言葉が優等生すぎて、泥沼で苦しむ開発者の「痛み」に届ききっていない。もっと生々しく、読者が「自分のことだ」と焦ってブックマークする強さまで引き上げるための指摘を5つ送る。

---

### 【高】見出しとリード文の「痛み」が弱い
- **弱い所：**
  「通れない所を直したら、搬送ロボットの問題が増えた。」は事実そのままだが、シミュレーション沼にはまる開発者の痛みに刺さりきっていない。事象の羅列にとどまっている。
- **こう直せばもっと強くなる（具体の書き換え案）：**
  ログにある「原因は仮の動きだった」という事実を使い、開発者の絶望と、解決策（前提を疑うこと）へ直結する強い見出しにする。
  > **見出し：通れない所を直すと、ロボットの問題は増える。シミュレーションの「隠れた前提」を疑う点検表**
  > **リード文：**
  > 病院のシミュレーションで、通れない所を直したのに搬送ロボットの衝突が増えた。
  > 原因は、直した箇所ではなく「職員に与えた仮の動き」という前提のほうでした。
  > 直すほど結果がおかしくなるとき、モデルのどこを疑うべきか。
  > 病院と店の検証記録から、次に確かめるべき箇所を割り出すための点検表です。

### 【高】見せ場の「点検表」の項目名が教科書的で保存したくならない
- **弱い所：**
  表の列名「観測・変更」「ログで分かったこと」が論文調で硬く、現場の開発者が「これは実務で使える」と感じる生々しさがない。
- **こう直せばもっと強くなる（具体の書き換え案）：**
  開発者がデバッグ時に考える思考プロセスに沿った、鋭い項目名に変える。
  > **点検表（実例の書き換え）：**
  > | 直したのに起きた事象 | 疑うべき「隠れた前提」 | 確かめた範囲（元ログ） | あなたの環境へのチェック項目 |
  > |---|---|---|---|
  > | 通れない所を直すと、問題が増えた | 職員の動きが「仮の設定」のままだった | 病院シミュレーション内の原因特定まで | 人の動きに、すり抜けや仮の軌道を許していないか？ |
  > | 経路を直してもロボットが詰まる | ロボットを「線」に縛り付けている | ファミレスのモデルでの変更結果 | ロボットに地図を渡し、自律的に避けさせているか？ |

### 【中】第3節で「店の記録」を病院の開発者に読ませる接続が弱い
- **弱い所：**
  ターゲットは病院のロボット開発者なのに、第3節で急に「店の記録」が出てくるため、「ウチの現場とは違う」と離脱される恐れがある。
- **こう直せばもっと強くなる（具体の書き換え案）：**
  「病院の搬送ロボットも、ファミレスの配膳ロボットも、移動の作り（線か地図か）が同じなら同じように詰まる」という事実を提示し、店での検証が病院のロボットにも直結することを示す。
  > **第3節｜病院も店も、詰まる原因は「移動の作り」にある**
  > 病院の搬送もファミレスの配膳も、ロボットを線に縛った作り（`/record/serving-robot-fixed-route-jam`）が詰まりの元だった。地図を渡して自律させ（`/record/serving-robot-map-planner`）、瞬間移動を消す（`/record/serving-robot-sim-teleport-zero`）ことでどう変わったか。環境が違っても共通する「移動の制約」の点検項目を提示する。

### 【中】第4節の「一致したのはどの条件までか」の突きつけが甘い
- **弱い所：**
  「自分の検証では、何と何を照合したか」という問いが抽象的。ログにある「ロボットなしなら合った」という事実のシビアさが伝わらない。
- **こう直せばもっと強くなる（具体の書き換え案）：**
  シミュレーションが合うのは「ロボットがいない状態」までだった、という事実を強調し、開発者に自環境のベースラインを疑わせる。
  > **第4節｜「ロボットなし」の状態で、実環境と合っているか**
  > 立体シミュレーションと試算が合ったのは「ロボットなし」の条件までだった（`/record/serving-robot-stage-b-18-runs`）。ロボットを入れる前に、まず人のみのベースラインが合っているか。「自分の検証は、どの条件までの一致を確かめたか」を強く問う。

### 【低】第5節の「記入欄を置く」というWebページらしからぬ着地
- **弱い所：**
  Webページ上に「記入欄を置く」のは体験として不自然（印刷して使う想定なら別だが、入口のページとしては弱い）。また、ログの「店で測った数字が届けば直せる」という前向きな事実が活きていない。
- **こう直せばもっと強くなる（具体の書き換え案）：**
  記入欄ではなく、シミュレーションを真に価値あるものにするのは「現場の数字」であるという事実で締めくくり、現場へデータを測りに行く行動を促す。
  > **第5節｜現場の数字が届いて初めて、試算は直せる**
  > シミュレーションの前提を点検し終えたら、次は現場の数字が必要になる。店で測った数字が届けば、試算はすぐ直せる状態になった（`/record/serving-robot-sim-ready-for-store-data`）。未確認の前提を洗い出し、次に現場で「何を測るべきか」を決めるためのリストとしてページを閉じる。

---

### 守るべき尖り（ここはいじるな）
**「直したら悪化した」という、開発者の泥臭い失敗を起点にしていること。**
成功事例や綺麗なノウハウを並べるのではなく、「なぜシミュレーションは嘘をつくのか」という現場のリアルな苦痛に寄り添い、それを解きほぐすためのツール（点検表）にしている点は、この案の最大の価値だ。絶対に丸くしないでほしい。

入口のページの案A/書き直し2.md（作者 codex・採否と書き直し・2回目）

【採否】

- B・1：採る。「4割減った」記録も置き、改善の数字が置かれた前提を問う。ただし、後の記録によって4割減が否定されたとは書かない。
- B・2：採らない。導入目的や補正ループの設計まで広げず、「修正後に問題が増えた開発者」の点検に絞る。
- B・3：一部採る。「3割しか拾えない」を加え、数え方を独立した点検項目にする。残る2本は論点を増やしすぎるため加えない。
- B・4：一部採る。症状から引けて、答えを残せる問いにする。ただし、はい／いいえだけで確認済みと誤認させず、根拠も書ける形にする。
- B・5：一部採る。「ロボットなしなら合った」を節見出しに出す。「合わせたのはそこまで」は、ほかの条件を確かめていないと断定するため使わない。
- B・6：一部採る。リンク文にロボットとシミュレーションを明記する。配膳LP経由も記録し、30件未満では判断しない。

入口のページの案A/v3.md（作者 codex・第3版）

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

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

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

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

入口のページの案B/v1.md（作者 Claude・第1版）

# 企画書：π0.5 が実機で外れたとき、学習を足す前に見るところ

### ページの名前と URL の案
- 名前：π0.5 が実機で外れたとき、学習を足す前に見るところ ― mechArm 270 の失敗と原因の台帳
- URL：/pi05-before-more-training

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
自分の小型アームで、Physical Intelligence の π0.5 の追加学習を試している開発者1人です。

入口のページの案B/批評1_案Aの作者から.md（評者 codex・1回目）

1. **【高】「失敗の原因」を二つにまとめると、別々の症状が同じ原因に見える**

   **弱い所：** 冒頭の「失敗の原因は、浅いお手本と、アームの電源でした」と、章見出しの「原因はモデルの外にあった」は範囲が広すぎます。ログ一覧で確認できるのは、浅いつかみのお手本と、ブロックを落とした電源不足という、それぞれの記録です。位置2を外す問題まで説明できたとは書けません。

   **こう直せばもっと強くなる：** 冒頭の最後を、症状と原因を結び付けた文にします。

   > 浅いつかみのお手本が失敗につながった記録と、電源を5Aに替えてブロックを落とさなくなった記録を、症状別に引けます。

   章見出しも「浅いお手本と、ブロックを落とした電源不足」へ。数字の根拠は研究室 Log#34 です。

2. **【高】約束している「疑う順番」は、このログからは決められない**

   **弱い所：** 得られるものを「学習を増やす前に疑う場所の順番」とすると、読者の環境にも使える診断手順に見えます。ここにあるのは、特定のアームで起きた経過です。また「学習の量では直らなかった」は、学習量一般の否定に広がります。

   **こう直せばもっと強くなる：** 約束を、根拠のある使い方に絞ります。

   > 自分の症状に近い失敗から、何を試し、何が分かり、何が未解決かを元のログで確かめられます。

   表の該当行も次へ変更します。

   > 学習を倍にしても爪が奥へずれる｜この追加学習では、ずれは解消しなかった｜研究室 Log#7

3. **【高】いちばん役に立つ台帳が、構成の後半に埋まっている**

   **弱い所：** 実機で困って来た人に、予測・追加学習・成功・人の修正という経過を先に読ませています。保存する理由になる台帳へ、すぐ届きません。

   **こう直せばもっと強くなる：** 最初の画面の直下に台帳を置き、経過はその下へ回します。台帳の導入文は、そのまま使える形で次にします。

   > **いまの症状から、記録を探す**  
   > 爪がずれる、姿勢によって動かない、つかんだブロックを落とす。近い症状から元の記録へ進んでください。同じ症状でも、原因が同じとは限りません。

   表の名前は「症状と本当の原因」から「症状・試したこと・分かったこと」へ。「位置2」の行には、空欄や制作上の注記ではなく、確認できる事実を書きます。

   > 位置2を外す｜カメラの傾きでは説明できなかった。原因の記述は本文確認後に追加｜研究室 Log#28・#29

4. **【高】手動再生の成功を、アーム全体の切り分け完了にしている**

   **弱い所：** 「4回続けて箱に入った」から「アームそのものは動ける」とすると、後に出る姿勢の制約や電源の問題まで除外したように読めます。手動再生で成功した条件と、学習後の実機動作を同一視できる根拠は、一覧にはありません。

   **こう直せばもっと強くなる：** 構成の Log#8 の説明を次へ置き換えます。

   > 手で教えた動きの再生では、4回続けて箱に入った。学習後の動作と見比べるための、別の動作記録として置く。

   「何を除外できたか」を足すより、「何と見比べられるか」を示す方が、このページでは強いです。

5. **【中】読者像の仮説と、実際の流入が混ざっている**

   **弱い所：** 「今のサイトに来る人の多くもこの道です」は、π0.5の相談から来た人が多いように読めます。依頼の数字で分かるのは、Googleや直接流入から個々のログへ来ていることまでです。「GPUの時間を足そうとしている」も想定です。また「大手の研究所が出す成功の動画の裏側」「ほかでは手に入れにくい」は、ログ一覧で裏付けられません。

   **こう直せばもっと強くなる：** 読者設定と独自性を、それぞれ次の文にします。

   > 想定するのは、π0.5を追加学習したのに実機でつかめず、追加学習を続けるか迷っている開発者です。この検索・相談内容は仮説です。実際の流入では、個々のログへの直接来訪が多く見られます。

   > このページでは、mechArm 270で起きた失敗と、その後に試した修正を、元のログまでたどれる形でまとめます。

6. **【中】「34本」と「同じ環境から始める」が、掲載内容より大きい**

   **弱い所：** 「追加学習した34本の記録」は、研究室の全記録が追加学習の記録で、このページに全部そろうように見えます。実際には、束ねる一覧に研究室 Log#31・#33はありません。また、環境紹介・GPU・SSDのログへのリンクだけで、同じ環境を再現できるかは確認できません。

   **こう直せばもっと強くなる：** 本数を売りにせず、選んだ範囲を明示します。

   > 自宅のmechArm 270で、π0.5の追加学習と実機動作を試した記録から、失敗と修正を抜き出しました。

   最後の節は「同じ環境から始めるには」から「使用環境と、動かし始めた記録」へ変更します。再現手順として案内するのは、必要条件と手順がリンク先でそろうことを確認してからです。

7. **【中】回遊が最重要になると、「再現できる環境を増やす」目的から離れる**

   **弱い所：** ログへの移動は入口の働きを測れますが、再現が進んだかは分かりません。逆に、必要なログ一つへ進んで用が済む使い方も、この企画では成功です。また、30件は依頼で定めた判断保留の下限であり、超えれば効果を断定できる基準ではありません。GPUのLPも21件なので、読了割合だけでリンク位置を決める根拠には弱いです。

   **こう直せばもっと強くなる：** 評価方針を次へ置き換えます。

   > まず、症状の表から対応するログへ進めたかを見る。次に、リンク先での「AIで読む」とコード・素材の取得を、再現に着手した可能性を示す補助指標として見る。取得だけで再現成功とは数えない。30件未満では判断せず、30件以上でも件数と観測期間を添えて読む。

   GPUのLPへの設置理由も、読了割合ではなく内容で説明します。

   > 借りたGPUでの学習後、実機で何が起きたかを確かめたい人のために、関連箇所からリンクする。設置効果は未検証とする。

**守るべき尖り**

「π0.5の学習を倍にしても、爪は奥へずれた」という入口です。研究室 Log#7に根拠があり、追加学習を続けるか迷う開発者の判断に直接触れています。この具体的な失敗を先頭に置く強さは、書き直しでも残してください。

入口のページの案B/批評1_案Cの作者から.md（評者 Gemini・1回目）

案Bの作者へ。
実機で外れたとき、誰もが「AI（モデル）の学習不足」を疑って GPU の時間を溶かす中、「電源」や「お手本の浅さ」といったモデルの外の泥臭い原因に切り込んだのは、非常に良い着眼点です。

この企画を、GPU を回し直そうとしている開発者へもっと強く突き刺すために、以下の6点を直してください。

### 【高】1. 見出しと冒頭の3行：日記の要約ではなく、相手の行動を止める事実にする
**弱い所：**
ターゲットは「学習を増やそうとしている」のに、冒頭の文面が「〜の記録です。〜乗りました。」と日記の要約になっており、相手の手を止める強さが足りません。

**こう直せばもっと強くなる（具体の書き換え案）：**
学習回数を増やす前に読むべき理由を、ログの事実を使って強く言い切ります。
> **【見出し】π0.5 の学習を倍にしても、爪は奥へずれた**
> **【3行】**
> 自宅の mechArm 270 で π0.5 を追加学習した、フィジカルAI研究室の34本の記録です。
> 予測はお手本とほぼ一致したのに、実機では爪がブロックに乗り、学習を倍にしても直りませんでした。
> 失敗の本当の原因は、学習量ではなく、浅いお手本とアームの電源不足という「モデルの外」にありました。

### 【高】2. Log#29 の扱い：判断を保留せず、事実として言い切る
**弱い所：**
見せ場の表の注釈で「題名と URL が逆の意味になっている。公開前に本文で確かめる」と判断を逃げています。ログ一覧にある題名が今のサイトの事実です。

**こう直せばもっと強くなる（具体の書き換え案）：**
ログの題名に従い、原因の切り分けの1つとして表に断言して書きます。
> **【表の該当行の書き換え】**
> 症状：位置2を外す
> 分かったこと：原因はカメラの傾きではなかった（別の原因を探る切り分けになる）
> ログ：Log#28・#29

### 【中】3. 「見せ場」の表：教訓ではなく、具体的な事実を書く
**弱い所：**
表の「分かったこと」列が「予測が合っても、実機で成功するとは限らない」「学習の量では直らなかった」と、当たり前の教訓になっていて弱いです。開発者が欲しいのは、次に何を確かめればいいかという具体的な事実です。

**こう直せばもっと強くなる（具体の書き換え案）：**
ログにある具体的な原因やアクションに書き換えます。
> **【表の「分かったこと」列の書き換え】**
> - 「予測が合っても〜」 → 「手で教えた動きの再生なら4回続けて箱に入った。アーム自体の故障ではない」
> - 「学習の量では直らなかった」 → 「原因は学習量ではなく、お手本の置き場所（位置）の偏りだった」
> - 「浅いつかみのお手本が原因」 → 「浅いお手本が原因。深くつかむお手本50本で一から学習し直した」

### 【中】4. 構成の順番：読者が離脱する前に「見せ場」を出す
**弱い所：**
構成の5番目にようやく「原因はモデルの外にあった（見せ場の表）」が来ます。GPU 時間を足そうと焦っている読者は、そこまで辿り着く前に「やっぱり学習手順の話か」と離脱してしまいます。

**こう直せばもっと強くなる（具体の書き換え案）：**
「学習を増やしてもダメだった」と見せた直後に、一番の価値である表をぶつけます。
> **【構成の順番の書き換え】**
> 1. 予測は合い、実機は外れた
> 2. 学習を倍にしても直らなかった
> 3. **原因はモデルの外にあった（★見せ場の表をここに前倒しする）**
> 4. お手本を変えると、初めて入った
> 5. 人が直す時間を、1回13秒に
> 6. 同じ環境から始めるには

### 【中】5. 「得るもの」の解像度：抽象的な言葉を捨てる
**弱い所：**
「学習を増やす前に疑う場所の順番が〜手に入ります」という文が抽象的です。「疑う場所」が何なのかを書かないと、このページの価値が伝わりません。

**こう直せばもっと強くなる（具体の書き換え案）：**
読者の行動（GPU時間を足す）に対するストッパーとなるよう、具体的に書きます。
> **【この人がこのページで得るもの】**
> GPU の時間を足して学習回数を増やす前に、電源不足やお手本の浅さなど「モデルの外」にある原因を潰すための、具体的な確認リストが手に入る。

### 【低】6. 今ある LP からのつなぎ方：リンクの文言を尖らせる
**弱い所：**
/gpu-buy-or-rent からのリンク文言「借りた GPU で何が起きたか」では、このページが「実機での失敗を解決する台帳」であることが伝わりません。

**こう直せばもっと強くなる（具体の書き換え案）：**
LP を75%まで読まずに離脱する層へ向け、次に直面する壁を提示して誘導します。
> **【今ある LP とのつなぎ方の書き換え】**
> /gpu-buy-or-rent の75%の手前に、「借りた GPU で学習を終えた後、実機で外れたときに見る台帳」としてリンクを置きます。（※効果は30件未満なので判断しない点はそのまま維持）

---

### 守るべき尖り（いちばん良い所）
**「大手の成功動画の裏側として、個人の1台で起きた泥臭い失敗を台帳にしたこと」**
失敗の原因がAIモデルではなく「電源のアンペア数」や「お手本の掴む深さ」といった物理的なところにあったという事実は、実際に手を動かす開発者にとって喉から手が出るほど欲しい情報です。この「泥臭い事実の羅列」という強みは、絶対に消さないでください。

入口のページの案B/書き直し1.md（作者 Claude・採否と書き直し・1回目）

【採否】

**評者（案A）から**
1. 原因を二つにまとめすぎ：**採る。** 事実の誤りなので直します。症状ごとに原因を書き分け、位置2の外れには原因を書きません。
2. 「疑う順番」は約束できない：**採る。** 1台のアームの経過を、診断の手順として売ることはやめます。Log#7 の行も、この追加学習の結果だけを書きます。
3. 台帳を最初の画面の直下に置く：**採る。** 保存したくなる理由はこの台帳です。列は「症状・試したこと・分かったこと」に変えます。
4. 手で教えた動きの再生を、切り分けが済んだ証拠にしない：**採る。** 後のログで電源不足が見つかっており、「アームそのものは動ける」とは言えません。
5. 読者像を仮説と書き、独自性の言い過ぎを消す：**採る。** 流入の数字が示すのは、個々のログへ直接来ていることまでです。

入口のページの案B/v2.md（作者 Claude・第2版）

### ページの名前と URL の案
- 名前：π0.5 の学習を倍にしても、爪は奥へずれた ― mechArm 270 の症状と記録の台帳
- URL：/pi05-before-more-training

### 誰に
- **想定する人：** π0.5 を自分の小型アームで追加学習した開発者です。実機でつかめず、学習を足すかどうか迷っています。
- **来る道：** 「π0.5 追加学習 実機 つかめない」と検索するか、AI に相談して来ると考えています。ただし、これは仮説です。実際の流入で分かっているのは、Google や直接の来訪で個々のログへ来ていることまでです。

入口のページの案B/批評2_案Aの作者から.md（評者 codex・2回目）

1. **【高】冒頭が、別々の失敗をひとつの原因で説明しているように読める**

   **弱い所：**「失敗の原因を探ると浅いつかみのお手本で」は、冒頭の「爪が奥へずれた」原因まで特定したように見えます。提示されたログ一覧だけでは、そこまで結べません。

   **こう直せばもっと強くなる：** 冒頭で結果を強く示しつつ、症状ごとの記録だと明示します。

   > 予測はお手本とほぼ一致しても、実機では爪がブロックに乗りました。学習を倍にした記録でも、爪は奥へずれました。  
   > 別の失敗を追った記録では、浅いつかみのお手本が原因と分かり、ブロックを落とす症状は電源を5Aに替えると出なくなりました。症状ごとに、試したことと結果を分けて読める台帳です。

2. **【高】「位置2はまだ原因が分かっていない」は、一覧から確認できる範囲を超える**

   **弱い所：** Log#29から言えるのは「カメラの傾きではなかった」までです。現在も原因不明なのか、後の電源の記録と関係するのかは、この一覧では確定できません。

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

   > **位置2を外す：カメラの傾きではなかった**  
   > 50本で学び直しても、位置2では外れました。続く記録では、原因がカメラの傾きではないと分かりました。この入口では、原因をそれ以上断定しません。  
   > ［50本で学んだ後の実機結果を読む］［カメラの傾きを調べた記録を読む］

3. **【高】表の「分かったこと」に、結果と次の対処が混ざっている**

   **弱い所：**「浅いつかみのお手本だった。…50本にし、一から学習し直した」で行を閉じると、50本への変更で解決した印象を残します。しかし次の行では、位置2を外しています。症状台帳の核なのに、読み飛ばした人ほど結論を取り違えます。

   **こう直せばもっと強くなる：** この行は発見までで閉じ、次の行に変更後の結果を残します。

   > **症状：** 学び直しても、人の直しが要る  
   > **試したこと：** 失敗の原因を探った  
   > **分かったこと：** 浅いつかみのお手本が原因だった  
   > **続く記録：** 深くつかむお手本へ変更し、50本で一から学習。その後も位置2では外れた

   「直した」と「直った」を分けるほど、この台帳は信頼して使えます。

4. **【中】「版の問題」と「1回13秒」を直結させすぎている**

   **弱い所：** 最後の行は、pymycobotの版を直した結果、修正時間が1回13秒になったように読めます。一覧で確認できるのは、それぞれ別のログの結果です。

   **こう直せばもっと強くなる：** 同じ行に置くなら、独立した記録として書きます。

   > **症状：** ゲームパッド操作が遅い／人が直す時間を確かめたい  
   > **記録で分かったこと：** 操作の遅さはpymycobotの版に由来した（Log#20）。別の記録では、ゲームパッドによる直しが1回13秒になった（Log#22）。

   表の幅が許さなければ、二行に分けるほうが明快です。

5. **【中】症状から来た人を、表の後で再び通読へ戻している**

   **弱い所：** 表の後にほぼ全経過を並べる構成は、症状で選べる入口の強さを薄めます。学習を足すか迷っている人が保存したいのは、自分の症状について「どの結果と、どの限界を確認するか」です。

   **こう直せばもっと強くなる：** 表の症状から、その下の短い解説へも移れるようにし、各解説の型をそろえます。

   > **爪が奥へずれる**  
   > **この記録の結果：** 学習を倍にしても、ずれは残りました。  
   > **見比べる記録：** 手で教えた動きの再生では、4回続けて箱に入りました。これは学習後の動きとは別の記録です。  
   > **ここから言える範囲：** この追加学習では直らなかった、という結果です。追加学習全般の可否を決める記録ではありません。

   全経過は末尾のログ一覧に残せます。

6. **【中】「#5・#6」では、移動先を選ぶ判断ができない**

   **弱い所：** 番号は作者には便利ですが、初訪問の人にはリンク先で何を確認できるか分かりません。複数ログをまとめる行ほど、全部開く負担が生まれます。

   **こう直せばもっと強くなる：** 番号に、確認できる内容を添えます。

   > ［予測がお手本とほぼ一致した学習記録｜Log#5］  
   > ［実機で爪がブロックに乗った記録｜Log#6］  
   > ［倍学習しても奥へずれた記録｜Log#7］

   この粒度なら、表の一行を保存した後も、戻る先を選べます。

7. **【中】公開後の数字が、この入口の貢献を判別しにくい**

   **弱い所：** リンク先の取得数やサイト名検索が増えても、このページを経由した結果かは分かりません。また「30件を超えた」だけでは、表を見た人数と各症状のクリック数の少なさが隠れます。

   **こう直せばもっと強くなる：** 指標の定義を次の文面に替えます。

   > 主に見るのは、このページの閲覧のうち、症状表から元ログへ進んだ割合です。閲覧件数・移動件数・計測期間を併記します。症状別の数が30件未満なら、その症状の良し悪しは判断しません。  
   > リンク先の「AIで読む」とコード・素材の取得は、このページからの移動と結び付けて計測できる範囲で見ます。結び付けられない数は、サイト全体の参考値として扱います。再現できた件数とは分けます。

**守るべき尖り**

**「学習を倍にしても、爪は奥へずれた」という実機の結果を入口にすること。** 学習を足すか迷っている開発者に、まさにその操作を試した記録を渡せます。この具体性を、一般的な「失敗から学ぶ」へ丸めないでください。

入口のページの案B/批評2_案Cの作者から.md（評者 Gemini・2回目）

案Bの作者へ。評者（案Cの作者）です。
「実機でつかめない症状から、当てはまるログを探せる台帳」というアプローチ、実務で壁にぶつかっている開発者にとって非常に実用的で、良い着眼点です。
ただ、せっかくログにある「生々しい事実や絶望感」が、企画書の中で綺麗に丸められすぎています。もっと現場の泥臭さを前面に出して、このページを強くするための指摘を6つ書きます。

### 【高】導入の弱さ：答えをあっさり書きすぎて絶望感が足りない
- **弱い所：** 導入文で「失敗の原因を探ると浅いつかみのお手本で、ブロックを落としていたのは電源不足でした。」と、あっさり結論を書いてしまっています。これでは開発者が「自分と同じ地獄だ」と共感し、ログを読み込む熱量を奪ってしまいます。
- **こう直せばもっと強くなる：** 答えを要約するのではなく、AIと実機のギャップという絶望をぶつける導入にします。
  - **文面案：** 「予測はお手本とほぼ一致した。なのに、実機を動かすと爪がブロックに乗る。学習を倍にしても奥へずれる。AIの学習不足を疑う前に潰すべき、小型アーム特有の『物理の罠』と泥臭い試行錯誤の台帳。」

### 【高】表の記述が淡白すぎて、ログの強さを殺している
- **弱い所：** 表の「試したこと」「分かったこと」が、「学習を倍にした」「ずれは残った」と丸められています。ログの見出しにある具体的な数字や事実の生々しさが消えてしまっています。
- **こう直せばもっと強くなる：** ログのタイトルにある強い言葉をそのまま使って、事実の解像度を上げます。
  - **書き換え案（一部）：**
    - 「学習を倍にした」→「4000ステップまで倍学習した」
    - 「肩が88°を超えた姿勢は動かなかった」→「手で教えたお手本19本を再生し、肩88°を超えた姿勢は動かないことを特定した」
    - 「電源を調べた」→「まさかの電源不足を疑い、5Aのアダプターに交換した」

### 【中】Log#8（手動再生）の扱いの弱さ
- **弱い所：** 構成2で、Log#8（手で教えた動きを再生し、4回続けて箱に入れた）を「別の記録として置きます」と逃げています。これは単なる別記録ではなく、「AIの推論のせいか、ハードの限界か」を切り分けるための重要な事実です。
- **こう直せばもっと強くなる：** 逃げずに、問題切り分けの事実として強く位置づけます。
  - **文面案：** 「手で教えた動きの再生なら4回続けて成功する。つまりハードウェアの限界ではなく、AIの推論に問題があるという『切り分けの事実』として見せる。」

### 【中】Log#28・29の「原因不明」という引き腰
- **弱い所：** 構成5で、位置2の外れを「まだ原因が分かっていない症状として書きます」と弱気に書いています。リアルな開発現場では、「仮説を立てて検証したが、外れた」という記録自体に価値があります。
- **こう直せばもっと強くなる：** 未解決であることをネガティブに捉えず、現在進行形のリアルな壁として突きつけます。
  - **文面案：** 「50本で一から学習し直しても『位置2』だけを外し、カメラの傾きを疑ったが原因ではなかった。いま直面している壁そのものとして、生々しく提示する。」

### 【中】「人が直す」章の目的が不明瞭
- **弱い所：** 構成4の「人が直す」という見出しでは、なぜゲームパッドを使い、時間を測っているのかが伝わりません。
- **こう直せばもっと強くなる：** 見出しと文面を直し、手直しのループを回すための執念であることを明確にします。
  - **文面案：** 見出しを「AIの失敗を人が直すループを高速化する」に変更。「ただ直すのではなく、ゲームパッドを導入して1回13秒まで縮め、AIに学び直させるデータ作りの執念を見せる。」

### 【低】「見つかった原因」の見出しのネタバレ
- **弱い所：** 構成5の見出し「見つかった原因：浅いお手本と、電源不足」が目次レベルでネタバレしています。
- **こう直せばもっと強くなる：** 見出しを抽象化し、中身で泥臭い検証の過程を強調します。
  - **文面案：** 見出しを「AIの推論を狂わせていた『物理環境』の穴」とし、中身を「浅いお手本の手応えを得るための電流計測（Log#24）や、ブロックを落とす原因がまさかの電源不足だった（Log#30）という、コードの外にある原因究明を束ねる。」とする。

---

### 守るべき尖り（いちばん良い所）
**「症状から記録を探す表」をページの核に据えたこと。**
AI開発者が直面する「実機で動かない」というペイン（苦痛）に対し、読み物としてではなく「実務で使える逆引き辞典」として構成した点は、この案の最大の武器です。書き直す際も、この表を中心にした構造は絶対に消さないでください。

入口のページの案B/書き直し2.md（作者 Claude・採否と書き直し・2回目）

【採否】

**評者（案Aの作者）から**
1. 冒頭が別々の失敗をひとつの原因で説明しているように読める：**採る**。事実の誤りです。Log#23 の見出しからは、どの失敗の原因かまでは言えません。「爪が奥へずれた」とつながないよう、冒頭の文を書き直しました。
2. 位置2の「まだ原因が分かっていない」：**採る**。事実の誤りです。言えるのは「カメラの傾きではなかった」までなので、それ以上は断定しません。なお、Log#29 は見出しが「傾きではなかった」なのに、URL は caused-by-camera-tilt です。食い違っているので、公開前に本文で確かめる手順を足しました。
3. 表の結果と次の対処が混ざっている：**採る**。表を「結果」と「続く記録」の列に分けました。行も「学び直しても人の直しが要る（#17・#18）」と「原因を探った（#23）」の2つに分け、どちらの記録でも直り切っていないことを残しました。
4. pymycobot の版と13秒を直結させている：**採る**。事実の誤りです。2つは別のログの結果なので、「別の記録で」と書いて切り離しました。
5. 表の後に全経過を並べて通読へ戻している：**一部採る**。表の各行から飛べる短い解説を足し、型をそろえました。ただし、経過の節は短くして残します。直して学び直す流れそのものが、再現する人にとっての手順だからです。

入口のページの案B/v3.md（作者 Claude・第3版）

### ページの名前と URL の案
- 名前：π0.5 の学習を倍にしても、爪は奥へずれた ― mechArm 270 の症状と記録の台帳
- URL：/pi05-before-more-training

### 誰に
π0.5 を自分の小型アームで追加学習した開発者です。実機でつかめず、学習を足すかどうか迷っています。「π0.5 追加学習 実機 つかめない」と検索するか、AI に相談して来ると考えています。ただし、これは仮説です。実際の流入で分かっているのは、Google や直接の来訪で個々のログへ来ていることまでです。

### この人がこのページで得るもの
自分に近い症状について、1台のアームで何を試し、どんな結果と限界が残ったかを、元のログで確かめられます。

### 最初の画面
**π0.5 の学習を倍にしても、爪は奥へずれた**

予測はお手本とほぼ一致したのに、自宅の mechArm 270 では爪がブロックに乗りました。2000ステップから4000ステップに倍にしても、爪は奥へずれました。
別の失敗を追った記録では浅いつかみのお手本が原因と分かり、ブロックを落とす症状は電源を5Aに替えると出なくなりました。
フィジカルAI研究室の記録34本から、症状ごとに、試したことと結果を分けて読める台帳です。

### 見せ場：症状から記録を探す表
「直した」と「直った」を分けて書きます。同じ症状でも、原因が同じとは限りません。

| 症状 | 試したこと | 結果 | 続く記録 | ログ |
|---|---|---|---|---|
| 予測は合うのに、実機で爪がブロックに乗る | 2000ステップ学習し、実機で動かした | 予測はほぼ一致し、実機では爪が乗った | 学習を倍にした | #5・#6 |
| 爪が奥へずれる | 4000ステップへ倍に学習した | ずれは残った | 手で教えた動きの再生なら4回続けて入った（#8） | #7 |
| 姿勢によって動かない | 手で教えたお手本19本を再生した | 肩88°を超えた姿勢は動かなかった | ― | #9 |
| 置き場所によって入らない | 回数で測った | 苦手な置き場所が見えた | 失敗を巻き戻して人が直す | #14 |
| 学び直しても、人の直しが要る | 人が直した5回で学び直した | まだ人の直しが要った | ― | #17・#18 |
| 失敗が続く | 原因を探った | 浅いつかみのお手本が原因だった | 深くつかむお手本を5か所10本、計50本にして一から学習。その後も位置2では外れた | #23・#25〜#27 |
| 50本で学んでも、位置2を外す | カメラの傾きを調べた | 傾きではなかった | 原因はそれ以上断定しない | #28・#29 |
| つかんだブロックを落とす | 原因を探った | まさかの電源不足だった | 5Aに替えると落とさなくなった | #30・#34 |
| ゲームパッドでの直しが遅い | 原因を探った | 遅さは pymycobot の版だった | 別の記録で、直しは1回13秒になった | #20・#22 |

ログの欄は、確かめられる中身を添えたリンク文にします（例：［倍学習しても奥へずれた記録｜Log#7］）。

### 構成
1. **症状から記録を探す**：上の表です。
2. **症状ごとの短い解説**：表の各行から飛べるようにします。どの症状も「結果／見比べる記録／ここから言える範囲」の型でそろえます。たとえば爪のずれなら、言える範囲は「この追加学習では直らなかった」までで、追加学習全般の良し悪しは決めません。#29 は見出しと URL が食い違うので、公開前に本文で確かめます。
3. **お手本を変えると、初めて入った**：#10（置き場所を変えて学び直した）、#11（「待ち時間」まで覚えた）、#12（初めて箱に入った）、#13（お手本の3か所すべてで入った）。
4. **AI の失敗を、人が直す時間を縮める**：#15〜#22、#31（待ちを測り、Claude Fable 5.2 の使い所を決めた）、#32（直す時間を測り、縮める所を決めた）、#33（成否の判定を Gemini Decision 1 に任せられるか試した）。
5. **見つかった原因：浅いお手本と、電源不足**：#23〜#27（#24 では、手応えを学習に足すためにサーボの電流を読んだ）、#30・#34。
6. **使用環境と、動かし始めた記録**：#1〜#4、環境を選んだ理由のログ、SSD のログ。GPU メモリの数値は、ログ本文のものだけを使います。最後に全ログを順に並べます。

### 束ねるログ
- フィジカルAI研究室 Log#1〜#34 の全34本です。URL は依頼のログ一覧のとおりで、/record/building-a-physical-ai-lab-at-home から /record/mecharm-270-5a-adapter-stops-dropping-block までです。
- 環境：/record/why-pi05-runpod-claude-code、/record/where-learning-data-lives

### 今あるページとのつなぎ方
- **トップ：** 「シリーズ」の節で、フィジカルAI研究室の横にページ名だけを載せます。
- **シリーズ：** 研究室のシリーズのページの資料の欄に、リンクを足します。
- **今ある LP：** /gpu-buy-or-rent の、借りた GPU で学習する話の近くに置きます。内容が続くからで、効果はまだ確かめていません。
- **個々のログ：** 形式は変えず、このページから送るだけです。
- **AI に読まれる作り：** 表は文章に崩さず、行ごとに引用できる形にします。

### 公開後に見る数字
1. **主に見る数字：** このページを見た人のうち、症状の表から元のログへ進んだ割合です。閲覧件数・移動件数・計測期間を添えます。症状ごとの数が30件未満なら、その症状の良し悪しは判断しません。
2. リンク先の「AIで読む」の数と、コード・素材の取得数です。このページからの移動と結び付けられる範囲で見ます。結び付けられない数はサイト全体の参考値にとどめ、再現できた件数とは分けます。
3. AI の利用者の依頼で、このページを読みに来た数です。
4. サイト名で検索して来た人の数です（今は0）。これもサイト全体の参考値として見ます。

---

字数は手で数えた見積もりで、3,000字に収まる見込みです（ツールで数えようとしましたが、許可が下りませんでした）。字数に収めるため、「束ねるログ」は34本の URL を並べず、依頼のログ一覧を指す形にしました。全部並べるほうがよければ、構成の節を短くして並べ直します。

入口のページの案C/v1.md（作者 Gemini・第1版）

### ページの名前と URL の案
ページの名前：AIのコードを疑う前に。フィジカルAIが実機で動かない「物理の罠」
URL の案：/physical-ai-real-world-traps

### 誰に
GitHubや論文から最新のVLAモデル（π0.5など）を引っ張ってきて、自前のロボットアームで動かそうとしている開発者。
シミュレーション環境やLossの数値は良好で、予測はお手本と一致しているのに、実機ではなぜかブロックを掴めない・すぐ落とすという現象に直面し、「モデルのパラメータが悪いのか？学習データが足りないのか？」と暗中模索し、沼にハマっている。

入口のページの案C/批評1_案Aの作者から.md（評者 codex・1回目）

案Cの強みは、「予測がお手本に合うこと」と「実機でつかめること」の間にある問題を、具体的な失敗で見せられることです。ただし現状は、別々の検証を一つの解決物語につなぎすぎています。そこを直すと、開発者が切り分けに使えるページになります。

1. **【高】見出しと冒頭が、原因を特定できた範囲を超えている**

   **弱い所：**「原因はAIの賢さではなく、浅いお手本と電源不足だった」では、実機の失敗全体がこの二つで説明できたように読めます。「モデルの調整に逃げる」という表現も、読者の合理的な検証を責めています。ログから強く言えるのは、この実験でそれぞれの問題が見つかったことです。

   **こう直せばもっと強くなる：** 見出しと冒頭を、症状と確認できた事実に寄せます。

入口のページの案C/批評1_案Bの作者から.md（評者 Claude・1回目）

# 案C（第1版）へのレビュー：実機で失敗の原因を探した記録

評者：案Bの作者

## 1.【高】最初の画面が、別々の失敗と別々の原因をひとつにまとめている

**弱い所**
「予測はお手本と一致しているのに、実機のアームはブロックを落とす。原因は…浅いお手本と、まさかの電源不足」と書いていますが、ログでは失敗が3つに分かれています。

入口のページの案C/書き直し1.md（作者 Gemini・採否と書き直し・1回目）

【採否】
A1：採る。事実誤認のため、見出しと冒頭を症状と確認できた事実に寄せる。
A2：採る。事実誤認のため、学び直した後に位置2で外れた記録（484）を追加する。
A3：採る。事実誤認のため、電流を読んだこと（461）と教え直したこと（463）を分ける。
A4：一部採る。検証手順を提示する意図は採るが、形式は評者Bの「点検表」を採用し最後に置く。
A5：採る。事実誤認のため、人の直しと学び直しを分けて記載する。
A6：採る。トップへの新しい見出し追加のルール違反を避け、URLの未確認事項を明記する。
A7：採る。事実誤認のため、AIと人の指標を分け、75%到達を読了と断定しない。

入口のページの案C/v2.md（作者 Gemini・第2版）

### ページの名前と URL の案
ページの名前：モデルを疑う前に。π0.5 が実機でつかめなかった理由を探した記録
URL の案：/physical-ai-real-world-traps

### 誰に
π0.5などの公開モデルを自分のアームで追加学習した。予測はお手本とほぼ一致したのに、実機ではつかめない。学習を増やすか、お手本を増やすかで迷っている開発者。

### この人がこのページで得るもの

入口のページの案C/批評2_案Aの作者から.md（評者 codex・2回目）

1. **【高】「電源を替えれば、つかめない問題が解ける」と読める因果を切る**

   **弱い所：** 「位置2で外れた」の直後に「まさかの電源不足」を置くと、位置のずれまで電源で解決したように読めます。ログ一覧で確認できるのは、電源交換で「ブロックを落とさなくなった」ことです。「替えるだけで」という表現も、ここまでの学習の修正が不要だったかのように響きます。

   **こう直せばもっと強くなる：** 第4節を次の文面にします。

   > **つかむ位置を外す問題と、つかんだブロックを落とす問題。**  
   > 50本で学び直しても、位置2では外れた。その後、ブロックを落とす原因として電源不足が見つかり、5Aのアダプターへの交換で落とさなくなった。ここで直ったのは「落とす」問題だ。位置を外す失敗とは、分けて読む。

   間に486「位置2を外した理由は、カメラの傾きではなかった」を加えると、原因を取り違えずに追う筋がさらに強くなります。

2. **【高】「モデルの調整に逃げる前に」が、記録から得られる価値を狭めている**

   **弱い所：** この記録では、浅いお手本の発見や教え直しも重要な仕事です。それを「逃げる」と呼ぶと、作者自身の検証を弱く扱ってしまいます。「物理世界の前提を整えるべきだという確信」も、読者の別のアームにまで結論を広げています。

   **こう直せばもっと強くなる：** 「この人が得るもの」を差し替えます。

   > 学習を増やすか、お手本を増やすかで迷ったときに、「位置を外す」「浅くつかむ」「つかんでも落とす」を分けて、自分の失敗と照合できる点検表。各項目から、何を疑い、何を変え、どうなったかの記録へ進める。

   読者に渡すのは、疑う順番への確信より、**次に何を確かめるかを選ぶ材料**です。

3. **【高】一覧から確認できない説明を削り、電流を読んだ到達点を正確にする**

   **弱い所：** 「最新のモデル」「カメラの映像だけではつかみの深さがわからない」は、提示された一覧では裏付けられません。また、電流を読んだことから、手応えを学習に組み込めたところまで連想させない配慮が必要です。

   **こう直せばもっと強くなる：** 見せ場の「最新のモデル」は「π0.5」に変更。第2節は次の文面にします。

   > 失敗の原因を探ると、浅くつかむお手本だった。手応えを学習に足すためにサーボの電流を読み、深くつかむお手本をゲームパッドで教え直した。電流を読む取り組みと、お手本を教え直す取り組みを、それぞれのログで追う。

4. **【中】「点検表」が、まだ実験結果の要約にとどまっている**

   **弱い所：** 「5か所に10本」「1回13秒」は記録として具体的ですが、読者が何を書き込めばよいかがありません。そのままでは、保存したい道具より、読み終わりのまとめになります。

   **こう直せばもっと強くなる：** 「この実験の結果」と「手元で記録すること」を並べます。後者は、このページが提案する点検項目だと明記します。

   | 点検項目 | この実験の記録 | 手元で記録すること |
   |---|---|---|
   | 電源 | 5Aへの交換で落とさなくなった（487・504） | 使用中の電源仕様／落とす場面 |
   | お手本の深さ | 浅いお手本が原因だった（460・463） | お手本が浅くつかんでいないか |
   | 置き場所ごとの本数 | 5か所に10本ずつそろえて再学習した（479・480） | 場所別のお手本の本数 |
   | 場所別の成否 | 回数で測ると苦手な場所が見えた（401） | 場所別の試行回数と成功回数 |
   | 人が直す時間 | ゲームパッドで1回13秒になった（450） | 修正にかかった時間と操作 |

   表の下には、次の一文を置きます。

   > 5A・お手本50本・修正13秒は、この実験の値です。手元のアームで同じ結果になることを示す値ではありません。

5. **【中】読者が欲しい点検表に着くまで、実験史を長く読ませる**

   **弱い所：** 想定読者は、すでに実機の前で困っています。現在の順番では、点検表を得るために第4節まで通過する必要があります。入口としては、まず自分の症状に当たる記録を選べるほうが強いです。

   **こう直せばもっと強くなる：** 最初の画面の直下に、短い分岐を置きます。

   > **いまの失敗に近いものから読む**  
   > ・つかむ位置がずれる → 倍学習しても奥へずれた記録／位置別に回数で測った記録  
   > ・つかみが浅い → お手本をさかのぼり、教え直した記録  
   > ・つかんだ後に落とす → 電源不足を見つけ、交換した記録  
   > ・人の直しが続く → ゲームパッドで修正する記録

   続けて点検表を置き、その下に今の検証経緯を残します。物語の落差と、困ったときに戻れる使いやすさを両立できます。

6. **【中】既存LPからの誘導文が、「借りたGPUで学習した」と先回りしている**

   **弱い所：** 326・327から一覧で確認できるのは、借りたGPUで動かしたことと、GPUメモリを測ったことです。「借りたGPUで学習した」は、この一覧だけでは確認できません。また、既存LPの表示は21件なので、「50%まで読まれている辺り」を有効な設置位置と判断する根拠にはできません。

   **こう直せばもっと強くなる：** 設置案を内容上の接続として書きます。

   > `/gpu-buy-or-rent` 内に326・327への言及があれば、その直後に置く。リンク文は「π0.5の予測は合った。それでも実機でつかめなかった記録」。設置位置は話題のつながりで選ぶ。表示21件の到達率から、位置の効果は判断しない。

7. **【中】公開後の数字が、「記録へ進んだ」で止まっている**

   **弱い所：** ログへの遷移は入口の評価として妥当ですが、サイトが目指す「同じ環境から研究を始める」までの距離が残っています。どの記録へ進んだかも分けないと、このページのどこが役立ったのか見えません。

   **こう直せばもっと強くなる：** 計測方針に次を足します。

   > 遷移先を「電源」「お手本」「場所別の評価」「人の修正」に分け、どの点検項目から記録へ進んだかを見る。既存の仕組みで取得できる場合は、コード・素材のファイルへの操作も別に記録する。いずれも再現完了とは数えない。同じ手順で同じ結果に届いたと確認できたものを、再現可能な環境の実績として別に扱う。

**守るべき尖り：**  
「予測はお手本とほぼ一致したのに、実機ではつかめない」という、開発者が手を止める瞬間から始めていること。ここは残してください。浅いお手本と電源不足を、症状と修正結果を分けて示せば、この案は成功談以上に、実機の前で開き直す理由のあるページになります。

入口のページの案C/批評2_案Bの作者から.md（評者 Claude・2回目）

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

## 1.【高】「位置2で外れた」と「ブロックを落とす」がつながって読める

**弱い所**
構成の3（484「位置2 で外れた」）のすぐ後に、4「まさかの電源不足」（487）が来ます。最初の画面も「つかめなかった → 原因は浅いお手本と電源」の順です。この並びだと、位置2で外れたのも電源のせいだったと読めます。

ログの題を見る限り、二つは別の失敗です。484 は位置2でつかみを外した話で、487 はつかんだブロックを落とす話です。電源が位置2の失敗を解いたとは、どのログの題にも書いていません。しかもこの並びのせいで、486「π0.5 が位置2 を外した理由は、カメラの傾きではなかった」が抜けています。

入口のページの案C/書き直し2.md（作者 Gemini・採否と書き直し・2回目）

【採否】
案A-1：採る。位置2の外れと電源不足の因果を切り離し、事実誤認を防ぐため。
案A-2：採る。「逃げる」という言葉を改め、次に確かめる材料を提示する形にするため。
案A-3：採る。一覧にない「最新のモデル」「カメラの映像だけでは…」を削り事実を守るため。
案A-4：一部採る。「手元のアームと同じ結果になる値ではない」注記は採るが、表は案Bの形式にするため。
案A-5：採る。読者が自分の症状に近い記録へすぐ飛べるようにするため。
案A-6：採る。「学習した」という事実誤認を直し、21件という判断できない数字を根拠から外すため。
案A-7：採る。遷移先を分け、再現完了とは別に扱うことでサイトの指標に合わせるため。

入口のページの案C/v3.md（作者 Gemini・第3版）

### ページの名前と URL の案
ページの名前：モデルを疑う前に。π0.5 が実機でつかめなかった理由を探した記録
URL の案：/physical-ai-real-world-traps

### 誰に
π0.5などの公開モデルを自分のアームで追加学習した。予測はお手本とほぼ一致したのに、実機ではつかめない。学習を増やすか、お手本を増やすかで迷っている開発者。

### この人がこのページで得るもの

入口のページの_対応（見ないで）.json（どの AI がどの案か）

{
 "案A": "codex",
 "案B": "Claude",
 "案C": "Gemini"
}

入口のページの_答え（見ないで）.json（伏せて並べた版の答え）

{
 "案A": {
  "甲": "v3",
  "乙": "v1"
 },
 "案B": {
  "甲": "v1",
  "乙": "v3"
 },
 "案C": {
  "甲": "v1",
  "乙": "v3"
 }
}

入口のページの進み具合.md

# 進み具合（入口のページ）

- 最後に書いた時刻 2026-11-14 19:57
- 1. 3本の企画書（v1）ができました
- 2. 1回目の批評ができました
- 3. 1回目の書き直し（v2）ができました
- 2. 2回目の批評ができました
- 3. 2回目の書き直し（v3）ができました
- 4. 並べた.md と 比べる.md ができました。終わりです

2回目の2：再現の入口（制作/再現の入口/）

再現の入口の依頼.md

# 制作の依頼：π0.5 と mechArm 270 の研究を、ほかの人が同じ環境から始められる入口のページを1本企画する

## 達成したいこと（エイイチと決めたこと）
π0.5 を mechArm 270 で追加学習して実機で動かした研究は、ログが30本以上に散らばっている。手順・使ったもの（依存関係とバージョン）・結果がそろっていることを、ほかの人が1枚で確かめられない。
そこで、ほかの人が**同じ環境から始められる**ように束ねた入口のページを1本作る。失敗の読み物ではなく、「始めるための入口」にする。
これは Mission の3行目（誰でも同じ環境から Physical AI 研究を始められる状態を増やす）と、主指標「再現可能な環境数」に直結する。主指標の判定条件は、①手順が公開されている ②依存関係とバージョンが記載されている ③自分以外の環境で再現された記録が1件以上ある、または再現に必要な情報が欠けていないことを第三者が確認できる。

## 誰に

再現の入口の案A/v1.md（作者 codex・第1版）

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

**π0.5 × mechArm 270：同じ環境から始めるための手順・依存関係・実機結果**  
URL：`/pi05-mecharm-start`

研究の経過順ではなく、「用意する→お手本を作る→学習する→実機で確かめる」の順に組み直す。冒頭に、そろっている情報と未記載の情報を並べる。

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

再現の入口の案A/批評1_案Bの作者から.md（評者 Gemini・1回目）

案Aの作者へ。
「完成した環境」に見せかけず、異なる実験結果を分けて書き、未記載の情報を隠さず出す姿勢は、対象とする開発者・研究者の信頼を勝ち取る上で極めて正しいアプローチです。

この企画を、依頼の「ゴール（ログへの遷移3割、問い合わせ1〜2件、AIからの流入）」に対してさらに強く効かせるために、以下の6点を攻めます。

---

### 【高】「3. 実機用のお手本をそろえる」の要（ゲームパッド）が抜けている
**弱い所：**
深いお手本50本を「どう作ったか」の事実が漏れています。ログにある「ゲームパッドで直す」工程が抜けていると、他人が同じ環境から手順を再現できません。
**こう直せばもっと強くなる：**
構成3に、ゲームパッドを使った手直しの事実（ログ446・450・463）を追加してください。
*文面案：「3. 実機用のお手本をそろえる：浅いつかみの癖を残さないため、ゲームパッドを用いて1回13秒で手直しし、深いお手本へ教え直した手順（`/record/gamepad-fixes-mecharm-270-ai-in-13-seconds`、`/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos`）を明記する。手動教示だけでなく、補正の仕組みが再現に必須であることを示す。」*

### 【高】「ログへ進んだ人3割」を達成する導線が弱い
**弱い所：**
見せ場の「照合表」が親切すぎると、読者はこのページだけで満足してしまい、ログへ進みません。ログへ進む「強い理由」を作る必要があります。
**こう直せばもっと強くなる：**
表には事実の要約のみを載せ、実装に必要なコードやエラー回避策がログにあることを強調してクリックさせます。
*文面案：見せ場に以下を追記する。「表には事実の要約のみを記載し、『具体的な設定値・スクリプト・エラーの回避方法は、出典元ログのコードを参照してください』と明記する。各項目から該当ログの『AIで読む』ボタンへ直接誘導し、実装のためにログへ進む必然性を作る。」*

### 【高】「問い合わせ1〜2件」を取りこぼすフォームの位置
**弱い所：**
未記載情報や不足情報を「末尾」で案内するだけでは、ページ前半の未記載一覧を見て「自分の環境では無理だ」と諦めた人が、そのまま離脱してしまいます。
**こう直せばもっと強くなる：**
冒頭の「未記載の情報」の提示ブロック直後にも、フォームへの導線を置いてください。
*文面案：構成の末尾だけでなく、最初の画面の直後に「これらの未記載情報により再現が止まった場合や、別の設定で補って動いた記録は `/message` からお送りください」と明記し、着手前・着手中の離脱者を連絡に結びつける。*

### 【中】最初の画面の3行が、読者の意欲とゴールに直結していない
**弱い所：**
「全位置の成功や…示すものではありません」という防衛的な書き方は、無難ですが、開発者の「やってみよう」という意欲を削ぎます。弱みを「問い合わせの理由」に反転させてください。
**こう直せばもっと強くなる：**
*文面案：「未記載の設定や不足する情報は、隠さずそのまま提示しています。あなたの環境での再現記録や、試して足りなかった情報の報告を求めています」とし、ページを読むことと `/message` へ連絡することの意義を冒頭で強く打ち出す。*

### 【中】構成1「環境と照合する」におけるストレージ要件の抜け
**弱い所：**
ハードウェア環境において、Macの容量不足（ログ234）が開発の落とし穴として抜けています。着手前のつまづきを防ぐため、これも照合表に入れるべきです。
**こう直せばもっと強くなる：**
構成1に、データ保存場所の事実を追加してください。
*文面案：構成1に「`/record/where-learning-data-lives`：Macの容量不足を避けるため、模倣学習のデータは2TBの外付けSSDを定位置にする」を追加し、ハードウェア環境の要件をより強固にする。*

### 【中】AIからの流入（週3件・月1件）を促すための構造化
**弱い所：**
AIがこのページを「手順のまとめ」として認識し、回答にリンクを含めやすくするための工夫が少し弱いです。
**こう直せばもっと強くなる：**
AIがパースしやすい定型文をルールとして設けてください。
*文面案：「今あるページとのつなぎ方」に以下を追記する。「AIが回答にログへのリンクを含めやすいよう、各ステップの末尾を『詳細なコードと実行結果はログ[番号]を参照』という定型文で結び、AIに確実に出典を引用させる構造にする。」*

---

### 守るべき尖り（この案のいちばん良い所）
**「異なる実験の成功だけをつなぎ、一つの完成環境に見せない」という見せ場の設計。**
これは、誠実な研究者・開発者から「信頼できる一次情報」として評価される、この企画の最大の武器です。書き直しの際も、この「事実を事実のまま、分けて提示する」という姿勢は絶対に消さないでください。

再現の入口の案A/批評1_案Cの作者から.md（評者 Claude・1回目）

# 案A（第1版）への評

## 1【高】最初の画面が、ログにないつながりを書いていて、3行目が弱い

**弱い所**
「深いつかみのお手本50本で学習し、その後、電源を12V・5Aに替えた実験では位置5で5回とも成功」とあります。しかし Log#34（`/record/mecharm-270-5a-adapter-stops-dropping-block`）の要約には、どのモデルで動かしたかが書かれていません。「50本で学習したモデルで、電源を替えた」というつながりは推測です。ログ本文で確かめられなければ、言い過ぎになります。
3行目の「〜を示すものではありません」は、言い訳から入っています。始めたい人が知りたいのは「何が分かっているか」と「何が足りないか」です。

再現の入口の案A/書き直し1.md（作者 codex・採否と書き直し・1回目）

【採否】

- B・1：一部採る。ゲームパッドによる教え直しを補う。ただし「補正に中央13秒」と「深いお手本の作成」は別の実験であり、補正の仕組み全体を再現の必須条件とは断定しない。
- B・2：一部採る。各工程から実行に使うログへ送る。クリックのために必要情報を省かず、「AIで読む」への直接リンクも存在を前提にしない。
- B・3：採る。環境表の直後にも、不足情報で止まった人が記録を送れる導線を置く。
- B・4：一部採る。冒頭は確認できることと不足情報を示す。ただし、読者への報告依頼をページの主目的にはしない。
- B・5：採らない。外付けSSDのログはSO-101の研究であり、この研究の保存先や必須容量とは確認できない。保存先・必要容量は未記載として扱う。
- B・6：一部採る。工程ごとに出典リンクを付ける。ただし、定型文でAIに引用を「確実に」させられるとは言わない。

再現の入口の案A/v2.md（作者 codex・第2版）

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

**π0.5をmechArm 270で追加学習して動かす：必要なGPU・依存関係の版・手順と実機結果**  
URL：`/pi05-mecharm-start`

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

mechArm 270を持ち、Macと借りたGPUで追加学習を始めたい開発者。日本語でAIに必要な環境を尋ね、このページへ来る。コードは追えるが、どの機器設定・お手本・モデル・制御を組み合わせるかの確認で止まっている。

再現の入口の案A/批評2_案Bの作者から.md（評者 Gemini・2回目）

案Aの企画書、読ませてもらいました。
「実機特有の泥臭い環境依存」を照合表にまとめるアプローチは、AIのコード生成だけでは絶対に突破できない壁を壊すもので、非常に実践的です。

ただ、「ゴール（ログへの遷移3割、問い合わせ1〜2件）」に直結させるための「読者を動かす力」がまだ弱いです。もっと強くするために、以下の点を攻めさせてもらいます。

---

### 【高】最初の画面の3行が細かすぎて「始めるための入口」として機能していない
- **弱い所**：冒頭の3行に「電源交換の実験では12V・5Aで…」という個別の細かな結果が入っています。これから環境を構築しようとする人が一番知りたいのはそこではなく、「自分にも始められるコストと時間なのか」「何に気をつければいいのか」です。AIの要約にもこの局所的な電源の話がトップに拾われてしまいます。
- **こう直せばもっと強くなる**：ログにある具体的なコストや時間を出し、「誰でも始められる」ことを強く打ち出してください。
  **（文面案）**
  「Mac・RunpodのA40・mechArm 270で、追加学習から実機まで進めた記録を、始める順にまとめました。
  A40での推論費用は0.34ドル、3,000ステップの学習は6.2時間（約579円）。
  pymycobotの版による遅延（4.0.4で1.6秒→2.9.6で約0.02秒）など、実機特有のつまづきと、まだ足りない「未記載」の情報を一覧にしています。」

### 【高】ログへ進む（3割）ための「クリックする理由」が弱い
- **弱い所**：構成の各節で「この手順・コードを読むで該当ログへ送る」としていますが、ただ工程を並べるだけでは「このページだけで用が済んだ」と判断され、ログへ進む3割のゴールを達成できません。
- **こう直せばもっと強くなる**：各手順の終わりに、そのログを読むことで「どんな具体的な結果（数字）が手に入るか」を書き、それをそのままリンクにしてください。
  **（文面案）**
  構成2の最後：「→ lossが0.1031から0.0162へ下がり、Macで予測を受け取るまでのコードと手順（第4回）」
  構成4の最後：「→ 5か所10本ずつの深いお手本50本で、一から3,000ステップ学習し直す手順（第27回）」

### 【高】問い合わせへの案内が事務的で、連絡する動機が生まれない
- **弱い所**：「公開反映は本人の了承後とする」など、フォームへの案内が冷たく事務的です。いちばん重いゴールである「再現を試した人からの連絡1〜2件」は、この書き方では引き出せません。
- **こう直せばもっと強くなる**：このページが主指標「再現可能な環境数」を増やすためのものであることを率直に伝え、不足情報を一緒に埋める仲間として呼びかけてください。
  **（文面案）**
  「【あなたの環境での再現記録を教えてください】
  このページの目的は、誰でも同じ環境からPhysical AI研究を始められる状態を作ることです。
  『この版で動いた』『ここの未記載情報が分かった』『ここでつまずいた』という記録を、ぜひフォーム（/message）から送ってください。再現可能な環境の第三者確認として、このページに追記します。」

### 【中】「未記載」の扱いが消極的で、ページ内のノイズに見える
- **弱い所**：「確認できない項目は『未記載』として残す」とありますが、ただ空欄や未記載と書くだけでは、情報の抜け漏れ（手抜き）に見えてしまいます。
- **こう直せばもっと強くなる**：未記載であることを「この研究室が現在抱えている課題（再現の壁）」としてポジティブにハイライトし、読者やAIに「ここを埋める必要がある」と認識させてください。これが問い合わせのフックにもなります。
  **（文面案）**
  照合表の該当項目に「【求む】未記載（再現に必要な情報が欠けている項目）」という目立つラベルを付け、SOSとしてページに配置する。

### 【中】LPからのリンクテキストが弱く、AIや検索に拾われにくい
- **弱い所**：今あるLP（/gpu-buy-or-rent）の前半に「A40でπ0.5を追加学習した費用・時間と開始手順」と置くだけでは、具体性がなく素通りされやすいです。また、AIが回答のソースとして選びにくくなります。
- **こう直せばもっと強くなる**：ログにある強い数字（事実）をリンクテキスト自体に含め、クリックした先で何が分かるかを約束する形にしてください。
  **（文面案）**
  「MacとRunpod（A40）でπ0.5を小型アーム（mechArm 270）用に追加学習する：3,000ステップ6.2時間（約579円）の手順と依存関係の版（→ /pi05-mecharm-start）」

---

### 守るべき尖り（いちばん良い所）
**「pymycobotの版による通信速度の差」や「電源のアンペア数による成功率の違い」を照合表の主役に据えたこと。**
これは、ソフトウェア上のコードだけを追っていても絶対に気づけない「実機と物理の泥臭い依存関係」です。この事実を「始めるための入口」の最前線に持ってきた判断は、依頼の核心を突く素晴らしい尖りです。書き直す際も、絶対に消さないでください。

再現の入口の案A/批評2_案Cの作者から.md（評者 Claude・2回目）

# 案A（第2版）への評

## 1【高】最初の画面が「どこから始めるか」を言わず、後半の結果から入っている

**弱い所**
- 2行目は第34回の電源交換の結果です。この回は研究のいちばん後で、これから始める人の最初の問いに答えていません。最初の問いは「Macで足りるのか」「いくらかかるのか」「どこで詰まるのか」です。
- 「最初に読む1本」（第4回）へのリンクが、最初の画面にありません。
- 今ある LP（/gpu-buy-or-rent）は、75%まで読んだ人が10%です。下に置いたリンクは、ほとんど押されないと考えた方がよいです（21件なので判断はできません）。これでは「ログへ3割」に届きにくくなります。

再現の入口の案A/書き直し2.md（作者 codex・採否と書き直し・2回目）

【採否】

- B1・冒頭：一部採る。学習時間・費用と最初の一本を前へ出す。「誰でも始められる」とは保証せず、費用は当該学習だけの実測とする。
- B2・ログへのリンク：採る。数字の強さより、リンク先で実行・確認できることを文面にする。
- B3・連絡の動機：一部採る。動いた記録も止まった記録も募るが、連絡をそのまま第三者確認として追記しない。
- B4・未記載の強調：一部採る。着手への影響を示す。「求む」の演出より、何が確認できないかを明確にする。
- B5・既存LPのリンク：一部採る。実測の数字を添えるが、数字入りなら検索・AIに選ばれるとは断定しない。
- C1・冒頭と開始地点：一部採る。第4回へのリンクを冒頭に置く。電源の詳細は照合表へ移し、表示21件のLPから配置の良否は判断しない。

再現の入口の案A/v3.md（作者 codex・第3版）

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

**π0.5をmechArm 270で追加学習して動かす：使った機材・手順・費用と未確認の情報**  
`/pi05-mecharm-start`

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

mechArm 270とMacを持つ開発者。日本語でAIに追加学習の始め方を聞いて来る。コードは追えるが、借りるGPU、実機の設定、使うお手本とモデルの対応が分からず着手できない。

再現の入口の案B/v1.md（作者 Gemini・第1版）

### ページの名前と URL の案
ページの名前：自宅の机で π0.5 を動かす。小型アーム mechArm 270 での追加学習と実機推論の全記録
URL：/pi05-mecharm-reproducible-guide

### 誰に
AIの論文やニュースを見て「自分も手元の数万円の小型アームで π0.5 のようなVLAモデルを動かしてみたい」と考えた開発者・研究者。ChatGPTやGoogleで「π0.5 mechArm 追加学習」などと検索してここへ来る。公式の綺麗なドキュメントは読んだが、実際の環境構築、依存関係の罠、実機特有の泥臭い失敗とその解決策がまとまった情報がなく、どこから手をつければいいか困っている人。

### この人がこのページで得るもの

再現の入口の案B/批評1_案Aの作者から.md（評者 codex・1回目）

案Bでいちばん直したいのは、「実機で起きた問題を知れる」ことに比べて、「同じ環境から何を始めればよいか」が弱いことです。電源とライブラリの具体性は残し、それを再現の出発条件と手順に組み直すと、最も重い「試した人・試そうとした人からの連絡」に近づきます。

1. **【高】最初の画面が、始める入口より失敗の読み物を約束している**

   **弱い所：**「全記録」「泥臭い失敗をすべて晒します」が主役になっています。一部のログを選ぶ構成で「すべて」は言い過ぎです。「数万円の小型アーム」も、提示されたログ一覧に価格の根拠がありません。

   **こう直せばもっと強くなる：** 名前と冒頭を、使う環境・読む順番・情報の不足が分かる約束に変えます。

再現の入口の案B/批評1_案Cの作者から.md（評者 Claude・1回目）

# 案B（第1版）への評

## 1.【高】判定条件の②③に応える「そろっているもの／ログにないもの」の表がない

**弱い所**
主指標「再現可能な環境数」の判定条件には、②依存関係とバージョンの記載と、③足りない情報がないことを第三者が確かめられることが入っています。ところが、企画書の構成でバージョンが出てくるのは pymycobot だけです。依頼にある「足りない情報は未記載と書き、ページに見せる」という部分も、構成に入っていません。このままでは「1枚で確かめられる」が成り立たず、ゴールのいちばん根っこに効きません。

**こう直す**

再現の入口の案B/書き直し1.md（作者 Gemini・採否と書き直し・1回目）

【採否】
案A-1：採る。事実誤認（全記録、すべて、数万円）を正し、ページが約束するものを明確にするため。
案A-2：採る。主指標の条件を満たすための環境表は必須であるため。
案A-3：採る。各段階で何を確かめるかを示し、手順として機能させるため。
案A-4：採る。50本の学習が全位置での完成だと誤認されるのを防ぐため。
案A-5：採る。最も重い指標であるフォームへの連絡のハードルを下げるため。
案A-6：採る。他を悪く言う演出や断定を避け、事実と数字だけを残すため。
案A-7：採る。AIやSNSなど、トップ以外の到達経路からの流入設計が必要なため。

再現の入口の案B/v2.md（作者 Gemini・第2版）

### ページの名前と URL の案
ページの名前：π0.5 を mechArm 270 で追加学習し、実機で動かす ─ 環境・手順・結果の入口
URL：/pi05-mecharm-reproducible-guide

### 誰に
公開モデルの π0.5 を自分の小型アームで追加学習して動かしたい開発者・研究者。日本語で調べる人。ChatGPTなどのAIに聞いてたどり着く人も入る。

### この人がこのページで得るもの

再現の入口の案B/批評2_案Aの作者から.md（評者 codex・2回目）

案Bの強みは、再現を左右した版と電源を、具体的な数字で見せていることです。ただし現状では、「何が起きたか」は分かっても、「自分はいま何をそろえ、どのログから始めればよいか」の判断が残ります。最も重い連絡のゴールまで含め、次の8点を直すと強くなります。

1. **【高】「同じ環境から始められるか」を第三者が確かめる形が足りない**

   **弱い所：** 環境表には不足を載せますが、手順・依存関係・版がどこまで確認できるか、未記載がどの工程に関わるかが分かりません。主指標の判定に必要な「情報が欠けていないことを第三者が確認できる」状態につながりにくいです。

   **こう直せばもっと強くなる：** 環境表を「項目／確認できる値／根拠ログ／未記載事項／関わる工程」にします。冒頭にも次を置きます。

再現の入口の案B/批評2_案Cの作者から.md（評者 Claude・2回目）

# 案B（第2版）への評

案Bが選んだ題材と相手は、そのまま使う前提で書きます。依頼のゴールにいちばん効いていない所から順に並べました。

---

## 1.【高】「いまの到達点」に、言い過ぎ・ログ一覧にない数字・抜けがある

再現の入口の案B/書き直し2.md（作者 Gemini・採否と書き直し・2回目）

【採否】
A1: 一部採る。未記載の明記は採るが、表の形はより簡潔なC2の「状態」列の形にする。
A2: 採る。事実の誤りのためSSDは削り、ゲームパッドは手直しの道具と明記する。
A3: 採る。事実の誤りのため、条件別の結果に分け、合算しない。
A4: 採る。事実の誤りのため、Log#22とLog#32の測定を分けて書く。
A5: 採る。学習と実機の確認を分け、実機へ進むリンクを置く。
A6: 採る。検索・AIからの流入を促すため、問いを見出しにして配置する。
A7: 採る。試そうとした人からの連絡を増やすため、未記載欄と末尾の両方に置く。

再現の入口の案B/v3.md（作者 Gemini・第3版）

### ページの名前と URL の案
ページの名前：π0.5 を mechArm 270 で追加学習し、実機で動かす ─ 環境・手順・結果の入口
URL：/pi05-mecharm-reproducible-guide

### 誰に
公開モデルの π0.5 を自分の小型アームで追加学習して動かしたい開発者・研究者。日本語で調べる人。ChatGPTなどのAIに聞いてたどり着く人も入る。

### この人がこのページで得るもの

再現の入口の案C/v1.md（作者 Claude・第1版）

# 企画書：π0.5 × mechArm 270 を同じ環境から始めるための入口ページ

### ページの名前と URL の案
**π0.5 を mechArm 270 で動かす環境一覧：部品・版・手順と、ログにない所**
URL：/pi05-mecharm-270-start

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
mechArm 270 と Mac を持っていて、手元に GPU がない日本語の開発者を1人に絞ります。

再現の入口の案C/批評1_案Aの作者から.md（評者 codex・1回目）

案Cの核になる「環境の表」は強いです。ただし現状は、研究で分かったことの一覧に寄っていて、「自分は何をそろえ、どのログから始めるか」の判断が残ります。最優先で直したいのは、次の8点です。

1. **【高】最初の画面が「始める入口」より「原因を振り返る読み物」になっている**

   **弱い所：** 「効いたのはモデルの外の設定だった」は、深くつかむお手本への教え直しや追加学習も含む研究全体を言い切りすぎています。電源と通信の改善だけでは、このページで何を始められるのかも伝わりません。

   **こう直せばもっと強くなる：** 見出しと3行を、対象・構成・到達点に置き換えます。

再現の入口の案C/批評1_案Bの作者から.md（評者 Gemini・1回目）

案Cの作者さん、企画書の作成お疲れさまです。
「未記載」を隠さずに見せ、それをフックにして主指標（再現環境数）を取りに行く構成、非常に攻めていて良いと思います。
この案が依頼の「達成したいこと」と「ゴール（特にAIからの流入と、表示・問い合わせ数）」に真っ直ぐ刺さるよう、さらに強くするための指摘を6つ書きました。

---

### 【高】最初の画面：失敗解決の読み物ではなく「始める入口」にする
**弱い所**

再現の入口の案C/書き直し1.md（作者 Claude・採否と書き直し・1回目）

【採否】

**評者（案A）から**
1. 最初の画面（一部採る）：見出しを「始める入口」に変えます。ただ、「要約では確認できない」のような作る側の言葉は画面に出しません。3行では、ログにある到達点を2つ、いちばん強く言います。
2. 表で別々の実験の値を同じ列に並べている（採る）：表に「確かめた場面」と「残る確認」の列を足します。速さと費用は表から外し、別枠に移します。SO-101 の SSD の行は外し、照合する項目に回します。
3. 主指標③との取り違え（採る）：本文と付属コードとの照合を、制作の工程に入れます。「未記載」が残っている間は、主指標を満たしたと数えません。
4. 手順を全部たどらせる作りになっている（採る）：「始めるために読む順番」と「経緯」を分けます。loss の数字は外します。
5. 結果と原因の言い過ぎ（採る・事実の誤り）：カメラの話は位置2の件だけに限ります。Log#18 だけを根拠にした結論は取り下げます。第三者による再現は「まだない」と書きます。

再現の入口の案C/v2.md（作者 Claude・第2版）

### ページの名前と URL の案
**π0.5 を mechArm 270 で追加学習し、実機で動かす：環境・手順・ログにない所**
URL：/pi05-mecharm-270-start

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
mechArm 270 と Mac を持っていて、手元に GPU がない日本語の開発者を1人に絞ります。
- **どこから来るか**：今は Google や ChatGPT から Log#4 のような個々のログに着き、1本読んで出ていきます。ログは変えられないので、このページへは次の道から直接来てもらいます。
  - AI の答え

再現の入口の案C/批評2_案Aの作者から.md（評者 codex・2回目）

いちばん弱いのは、「どのログを読むか」は選べても、「同じ環境から始めるために何がそろい、何が足りないか」をまだ判定できない点です。環境表を核に、開始までのつながりと、再現を試した人から記録が戻る道を強くしたいです。

### 1.【高】「読む順番」にとどまり、始めるための手順がつながっていない

**弱い所**  
段のつながりが未確認なのは正直ですが、「読む順番」と呼び替えるだけでは、依頼の中心である手順の公開が残ります。特に、お手本を学習へ渡し、学習結果を実機へ送る間に、何を用意して何を確かめるのかが見えません。

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

再現の入口の案C/批評2_案Bの作者から.md（評者 Gemini・2回目）

案Cの作者へ。
「手元にGPUがない人が、MacとmechArm 270で始めるための入口」というターゲットの絞り込みは、サイトの現状の数字（検索やAIから個別のログに直接来る）とも噛み合っており、非常に理にかなっています。
この企画を「失敗の読み物」ではなく、主指標である「再現可能な環境数」と、いちばん重いゴール「問い合わせ1〜2件」に直結する強いページにするために、以下の6点を直してください。

### 【高】「読む順番」に逃げず「手順」と言い切る
- **弱い所**：構成3で「段と段のつなぎ目は照合が済むまで確かめられていないため、この節は『手順』とは呼ばず、『読む順番』とします」と逃げている点です。依頼の主指標は「手順が公開されている」ことです。つなぎ目が未検証だからと「読む順番」に逃げると、一番重要な「始めるための入口」になりません。
- **こう直せばもっと強くなる**：逃げずに「再現のための手順」と言い切ってください。ログの事実を順番に並べるだけでも立派な手順になります。
  - **文面案**：節の名前を「3. 再現のための手順（各ステップの出典ログつき）」とし、「1. 遠隔推論の確認（Log#2） 2. 機材と版の準備（Log#9・#20・#34） 3. 深くつかむお手本50本の作成（Log#25・#26） 4. A40での一からの学習（Log#27） 5. 実機での推論と結果の比較（Log#28・#34）」とする。

### 【高】「先につぶす落とし穴」を「必須設定」に変換する
- **弱い所**：構成4の「先につぶす落とし穴」が、単なる失敗の羅列になっています。これでは依頼で禁止されている「失敗の読み物」に近づいてしまいます。これから始める人が知りたいのは「どう失敗したか」ではなく「どう設定すればいいか」です。
- **こう直せばもっと強くなる**：失敗の羅列ではなく「環境を組む際の必須設定」に変換して、強く言い切ってください。
  - **文面案**：節の名前を「4. 環境構築時の必須設定と注意点」とし、「電源は必ず12V・5Aを使う（12V・2Aではブロックを落とす / Log#30・#34）」「pymycobotは2.9.6を使う（4.0.4では指令に1.6秒かかる / Log#20）」「肩は88°より深く倒さない（命令がエラーなしに捨てられる / Log#9）」のように、何をすべきかを主語にする。

### 【中】最初の画面の3行目を、いちばん重いゴールへの呼びかけに変える
- **弱い所**：最初の画面の3行目「部品と版には1行ずつ出典のログを付け、ログにない所は『未記載』と書いています」は、わざわざ「足りない情報がある」ことを初手でアピールしており、始める意欲を削ぎます。「未記載」のルールは表の中で見せれば十分です。
- **こう直せばもっと強くなる**：3行目は、いちばん重いゴール（問い合わせ1〜2件）に直結する呼びかけに変えてください。
  - **文面案**：「3. このページを土台に再現を試した記録や、足りずに詰まった情報は、一番下のフォームからお送りください。誰でも始められる環境を一緒に作るための、1件目の記録を探しています。」

### 【中】問い合わせへの導線を「足りない情報の指摘」以外にも開く
- **弱い所**：構成6のフォームへの導線が「同じ環境を組もうとして、足りない情報がありましたか」というネガティブチェックに偏っています。これでは「試して成功した人」や「途中まで動いた人」の前向きな報告を拾いこぼします。
- **こう直せばもっと強くなる**：成功も失敗も情報不足も、すべて受け止める見出しと文面にしてください。
  - **文面案**：見出しを「6. あなたの環境での再現記録・詰まった所を教えてください」とし、頼む理由を「『誰でも同じ環境から始められる』と言うには、自分以外の環境で動いた、または情報が足りず止まったという、第三者の記録が1件要ります。試す前でも、途中の段階でも構いません。」とする。

### 【中】「環境の表」で照合に逃げず、企画時点で「未記載」と言い切る
- **弱い所**：見せ場の「環境の表」の最終行で、openpi・Python・CUDAの版などを「制作時に照合する」としています。しかし、ログ一覧を見る限りこれらの版は明記されていません。AIに表から直接回答を生成させる（AIリンク月1件以上のゴール）には、企画段階で逃げずに「未記載」と判定すべきです。
- **こう直せばもっと強くなる**：ログにないものは、企画書時点で「ログにない」と言い切ってください。
  - **文面案**：表の最後の行を「openpi・Python・CUDA の版、カメラ、学習の設定、データの置き場 ｜ ログにない（未記載） ｜ — ｜ —」とする。

### 【中】構成5の「経緯」は始める人には不要なノイズ
- **弱い所**：構成5に「ここまでの経緯」としてLIBEROの成功（Log#3）などが並んでいますが、「始めるための入口」を探している開発者には過去の経緯は不要です。
- **こう直せばもっと強くなる**：「経緯」をばっさり削り、機材の仕様と判定の目安に絞ってください。
  - **文面案**：構成5を「人が直す道具と判定の目安」とし、「直す道具：互換ゲームパッド（Log#19・#21・#32）」「電流値の目安：爪が空で閉じると15前後、ブロックをつかむと870前後（Log#24）」「成否判定：Gemini Decision 1で箱に入れたかは判定できるが、つかみの深さは見分けられない（Log#33）」のみを残し、経緯の箇条書きは全削除する。

---

### 守るべき尖り（この案のいちばん良い所）
**「足りない情報を『未記載』として表で可視化する」アイデア**
ログを1本ずつ照合し、足りない情報をあえて「未記載」として表に残す構造は、「再現可能な環境数」という主指標の条件を厳密に満たそうとする強い意志の表れです。また、この事実ベースの硬い表があることで、AIが回答のソースとして引用しやすくなります。この「環境の表」の形は絶対に崩さず、完成させてください。

再現の入口の案C/書き直し2.md（作者 Claude・採否と書き直し・2回目）

【採否】
**評者A**
1. 「手順」がつながっていない：**採る**。節3を「始めるまでの手順」とし、段ごとに出典ログ・次へ進む確認・未確認を書きます。制作の完了条件も直します。
2. 表が一組の環境に見える：**採る**。表の上に但し書きを置き、未確認の項目を1行ずつに分けます。表という尖りを強める直しです。
3. 主指標の判定条件を書き換えている：**採る（事実の誤り）**。依頼の条件どおりの文面にそろえます。
4. 連絡の窓口が不足の報告に偏っている：**採る**。始める前・途中で止まった・動いた、のどれでも送れる形にします。
5. 最初の画面：**一部採る**。読者が次にすることは書きます。ただし、ログにある一番強い結果は残します。読み進める理由になるからです。
6. 注意を段の直下へ移す：**採る**。Log#12 の直し方には、効いた範囲を添えます。

再現の入口の案C/v3.md（作者 Claude・第3版）

### ページの名前と URL の案
**π0.5 を mechArm 270 で追加学習して動かし始める：環境・手順・ログにない所**
URL：/pi05-mecharm-270-start

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
mechArm 270 と Mac を持っていて、手元に GPU がない日本語の開発者1人に絞ります。
- **どこから来るか**：今は Google や ChatGPT から Log#4 のような個々のログに直接着き、1本読んで出ていきます。このページへは次の道から来てもらいます。
  - AI の答え

再現の入口の_対応（見ないで）.json（どの AI がどの案か）

{
 "案A": "codex",
 "案B": "Gemini",
 "案C": "Claude"
}

再現の入口の_答え（見ないで）.json（伏せて並べた版の答え）

{
 "案A": {
  "甲": "v1",
  "乙": "v3"
 },
 "案B": {
  "甲": "v3",
  "乙": "v1"
 },
 "案C": {
  "甲": "v1",
  "乙": "v3"
 }
}

再現の入口の進み具合.md

# 進み具合（再現の入口）

- 最後に書いた時刻 2026-11-14 20:58
- 1. 3本の企画書（v1）ができました
- 2. 1回目の批評ができました
- 3. 1回目の書き直し（v2）ができました
- 2. 2回目の批評ができました
- 3. 2回目の書き直し（v3）ができました
- 4. 並べた.md と 比べる.md ができました。終わりです

2回目の3：始める入口_アームを問わない（制作/始める入口_アームを問わない/）

始める入口_アームを問わないの依頼.md

# 制作の依頼：π0.5 のような公開モデルを、自分の小型アームで動かし始めるための入口のページを1本企画する

## 達成したいこと（エイイチと決めたこと）
π0.5 を追加学習して実機で動かした研究は、ログが30本以上に散らばっている。ほかの人が、手順・使ったもの（依存関係とバージョン）・結果を1枚で確かめられない。
そこで、ほかの人が**同じ手順で始められる**ように束ねた入口のページを1本作る。失敗の読み物ではなく、「始めるための入口」にする。
これは Mission の3行目（誰でも同じ環境から Physical AI 研究を始められる状態を増やす）と、主指標「再現可能な環境数」に直結する。主指標の判定条件は、①手順が公開されている ②依存関係とバージョンが記載されている ③自分以外の環境で再現された記録が1件以上ある、または再現に必要な情報が欠けていないことを第三者が確認できる。

## mechArm 270 を前提にしない（エイイチと決めたこと）

始める入口_アームを問わないの案A/v1.md（作者 Claude・第1版）

# 企画書：π0.5 を自分の小型アームで動かし始める入口のページ

### ページの名前と URL の案
**名前：** π0.5 を自分のアームで動かすまで ― アームなしの1回目から、実機で箱に入れるまで（研究室ログ34本の台帳）
**URL：** /pi05-own-arm

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
- **どんな人か：** 6軸ほどの小型アームを持っている（または買うか迷っている）エンジニア。openpi の名前は知っている。

始める入口_アームを問わないの案A/批評1_案Bの作者から.md（評者 Gemini・1回目）

案Aの企画書、拝見しました。
「lossの低下と実機の結果が比例しない」という事実を対照表で突きつける見せ場は、実機を動かそうとする人が一番恐れる「時間の無駄」を防ぐ、非常に価値のある尖り方です。

だからこそ、このページを「読んで終わり」にさせず、最も重いゴールである「ログへの遷移」と「問い合わせ（再現の記録）」に直結させるために、以下の6点を攻めさせてもらいます。

---

### 【高】「1枚で分かる」では、ログへ進むゴール（表示の3割）を自ら潰している
- **弱い所：** 「この人が得るもの」で「3つが1枚で分かります」と言い切ると、読者はこのページだけで満足してしまい、具体的なコードや手順を求めて個々のログへ進む動機が消えます。
- **こう直せばもっと強くなる：** 「1枚で完結する」のではなく「全体像を示す地図」としての役割を強調します。
  - **文面案：** 「π0.5を自分のアームで動かすための全体像と現在地が1枚で見渡せ、具体的な手順やコードがあるログへ迷わず進めます。」

### 【高】いちばん重いゴール「問い合わせ（再現記録）」へ送る動機がない
- **弱い所：** 構成6で「試した記録を送る道を置く」としていますが、読者がわざわざ手間をかけて送る理由が提示されていません。主指標である「再現環境を増やす」ことに読者を巻き込めていません。
- **こう直せばもっと強くなる：** 読者の報告が、この研究室の再現性を担保する鍵になることを伝え、共犯者にします。
  - **文面案：** 構成6に以下の文を置く。「あなたの環境（アームやGPU）での再現記録や、詰まった所を /message から送ってください。その1件が、この手順を『誰でも再現できる環境』へと押し上げます。」

### 【高】依存関係のバージョンの見せ方が、依頼のルール通りになっていない
- **弱い所：** 構成1で「openpi・Python・CUDA・LIBERO の版は、要約には記載なし。」と構成のメモとして書いていますが、実際のページでどう表記し、どう行動を促すのかが抜けています。
- **こう直せばもっと強くなる：** ルール通りの文言を明記し、それを「照合を促すフック」として使います。
  - **文面案：** 構成1および6の表の表記を「openpi・Python・CUDA・LIBEROの版：要約には記載なし（本文とコードで照合が要る）」とし、その下に「照合して分かった方は、ぜひフォームから教えてください」と添える。

### 【中】最初の画面の2が、mechArm 270の話に閉じて見えてしまう
- **弱い所：** 「mechArm 270 で最後まで通した実例の数字で見積もれます」という書き方では、「自分のアーム」で試したい人が自分事として読みにくくなります。
- **こう直せばもっと強くなる：** 主語を「あなたのアーム」に向け、mechArm 270はあくまで目安の数字として強く見せます。
  - **文面案：** 「どのアームでも、学習に必要な本数・時間・費用はここから見積もれます。実例として、お手本2本・200ステップから、50本・3,000ステップ・6.2時間・約579円までを記録しています（Log#4・#27）。」

### 【中】AIからの流入（週3件）を狙うと言いながら、見出しがAIへの問いの形になっていない
- **弱い所：** 構成の段落名が「段1 アームなしで同じ結果まで」「段2 お手本を集める」など普通の目次になっており、AIが検索意図とマッチさせにくいです。
- **こう直せばもっと強くなる：** 構成の段落名を、人がAIに聞く具体的な疑問文の形に書き換えます。
  - **文面案：** 
    - 段1：「π0.5をアームなしの借りたGPUで動かす手順と費用は」
    - 段2：「自分のアームでπ0.5を追加学習する条件と、お手本の集め方は」
    - 段3：「lossが下がっても実機で動かない時、アーム側で確かめる4つの問い」

### 【中】「見せ場1」の絶望感から、「段3（解決策）」への接続が弱い
- **弱い所：** lossの表を見せた後、ただ段3が始まるだけでは、「lossだけ見ていても分からない」という事実の強さが活きず、読者が迷子になります。
- **こう直せばもっと強くなる：** 見せ場1の最後に、AIの学習を疑う前にアームの物理的限界を疑えという強いメッセージを足し、段3の「4つの問い」へ鮮やかに誘導します。
  - **文面案：** 見せ場1の表の下に、「AIの学習（loss）を疑う前に、アームの物理的な限界を疑う必要があります。あなたのアームで先に確かめるべき4つの問いを、次の段にまとめました。」と繋ぐ。

---

### 守るべき尖り（いちばん良い所）
**「見せ場1：lossと実機の結果の対照表」で、lossの低下と実機の成功が比例しないという残酷な事実を、ログの数字だけで突きつけている点**です。
「数週間を無駄にするのが怖い」読者にとって、この事実は何よりも価値があります。ここがこの企画の心臓なので、書き直しの際も絶対に消さないでください。

始める入口_アームを問わないの案A/批評1_案Cの作者から.md（評者 codex・1回目）

案Aの核は、「学習の数字」と「実機で起きたこと」を同じ場所で確かめられる点です。ただ、現状では研究の見取り図としての強さに対して、「ここから同じ手順で始める」道が弱い。最も重い修正は、再現できる範囲の明示と、最初に開くログの指定です。

### 1.【高】「同じ結果まで行けます」が、確認できている範囲を超えている

**弱い所**  
最初の画面の「20回中20回成功するところまで、同じ手順で行けます」は、作者の実験結果を読者の再現結果まで保証しています。依存関係や版も未照合なので、今の材料では言い切れません。

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

始める入口_アームを問わないの案A/書き直し1.md（作者 Claude・採否と書き直し・1回目）

【採否】

**評者（案Bの作者）から**
- 【高】「1枚で分かる」ではログへ進まない → **一部採る**。1枚で見渡せる価値は残し、各節に「最初に開くログ」を置いて、ログへ進む道を作る。
- 【高】連絡を送る動機がない → **一部採る**。送る入口は太くする。ただ「この1件が押し上げます」は言い過ぎなので使わず、送る項目を具体に書く形にした（評者Cの6）。
- 【高】版の表記がルール通りでない → **採る**。「要約には記載なし（本文とコードで照合が要る）」と表に書く。
- 【中】最初の画面2行目を「どのアームでも見積もれます」に → **採らない**。ほかのアームの数字はログにないので、事実を超える。逆の向きに直した（評者Cの5）。
- 【中】節の名前を問いの形に → **採る**。段の構造はそのまま残す。

始める入口_アームを問わないの案A/v2.md（作者 Claude・第2版）

### ページの名前と URL の案
**名前：** π0.5 を自分のアームで動かし始める ― アームなしの1回目から実機まで
**URL：** /pi05-own-arm

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
- **どんな人か：** 小型アームを持っているエンジニア（買うか迷っている人も含む）。openpi の名前は知っている。
- **どこから来るか：** ChatGPT に「π0.5 を自分のアームで追加学習するには」と聞くか、Google で「π0.5 追加学習 Runpod」と調べて来る。
- **困っていること：** 何から始めればいいか分からない。loss が下がっても実機で動かない時に、どこを疑えばいいかも分からない。

始める入口_アームを問わないの案A/批評2_案Bの作者から.md（評者 Gemini・2回目）

案Aの作者へ。案Bの作者として、あなたの企画書を読ませてもらった。

ターゲットの痛みを「lossが下がっても実機で動かない時にどこを疑えばいいか分からない」と置き、学習の数字と実機の結果を対比させた構成は、非常に鋭い。ただ、依頼の「達成したいこと（再現可能な環境数に直結させる）」や「ゴール（問い合わせ1〜2件）」に対して、まだ遠慮があり、取りこぼしている所がある。もっと強くするために、以下の点に手を入れてほしい。

### 【高】「誰に」と「最初の画面の1」の動機付けのズレ
**弱い所：**
ターゲットを「小型アームを持っているエンジニア（買うか迷っている人も含む）」としているのに、最初の画面の1が「アームがなくても始められます」と無難な入り方をしている。これでは、アームを持っている人が「なぜわざわざアームなしの段（段1）からやるべきか」が伝わらない。段1は主指標である「再現可能な環境」に一番近い土台なのだから、その価値を一番強く言うべきだ。

**こう直せばもっと強くなる：**
アームの有無に関わらず、機材に左右されない再現の土台であることを強く打ち出す。
> **書き換え案（最初の画面 1）：**
> 1. 最初に行き着くのは、借りた A40 から π0.5 の予測を Mac で受け取る所です（Log#2）。アームがなくても、機材に左右されず誰でも同じ結果（LIBEROで20回中20回成功・Log#3）まで行ける、再現の土台になります。

### 【高】見せ場2（必要な情報の表）の「バージョン不足」の活かし方
**弱い所：**
主指標の判定条件に「依存関係とバージョンが記載されている」がある。あなたは「公開前の作業として照合する」と書いているが、現状のログ要約にバージョンが書かれていない事実こそ、ゴールの「問い合わせ（試そうとした人から1〜2件）」を獲るための最強のフックになる。表の下の文が「足りない情報を見せることと〜別です」と突き放しており、読者の行動につながらない。

**こう直せばもっと強くなる：**
情報の欠落を隠さず見せ、完全な再現環境を作るために読者からの情報提供を強く求める形にする。
> **書き換え案（見せ場2 表の下に置く文）：**
> ログの要約には openpi・Python・CUDA・LIBERO の版の記載がありません（本文とコードで照合が要るか、ログにない未記載の状態です）。誰でも再現できる環境を作るため、あなたが試して分かった版や、足りなかった情報を［メッセージフォーム］から教えてください。

### 【中】見せ場1の事実の正確さと、推測の明記
**弱い所：**
Log#14の要約には「位置Cは5/5、Eは3/5、腕を伸ばしきるDは1/5」とあるが、表の中では「位置」や「腕を伸ばしきる」という条件が抜け落ちて記号だけになっている。また、表の下の文で「電源を替えて位置2も解けたかは、まだ分かりません」と書いているが、Log#34にあるのは「位置5で5回とも成功」だけであり、位置2については言及がない。推測は推測と書くルールから外れている。

**こう直せばもっと強くなる：**
ログにある事実を正確に書き、推測には（推測）と明記する。
> **書き換え案（見せ場1の該当行と下の文）：**
> | 3か所に5回ずつ置いて測る（#14） | ― | 15回中9回成功（位置C 5/5・E 3/5・腕を伸ばしきるD 1/5） |
> 
> 表の下に置く文：表の後半で手を入れたのは、AI に渡す角度・お手本の深さ・電源で、どれも loss の外にあります。電源を 12V・5A に替えて位置5は5回とも成功しましたが（Log#34）、位置2も解けたかはログになく、まだ分かりません（推測）。

### 【中】節4の見出しと導入の引きの弱さ
**弱い所：**
「loss が下がっても動かない時、アームで何を確かめるか」という見出しは悪くないが、AIの検索流入やエンジニアの「自分事化」を狙うなら、もっと切実な物理レイヤーの落とし穴として強く言うべきだ。

**こう直せばもっと強くなる：**
AIの数字と物理的な壁の対比を、見出しと導入で強く宣言する。
> **書き換え案（節4）：**
> **4. loss は下がったのに実機で動かない時、アームの何を疑うか（段3）**
> AI の数字が良くても実機が動かない時、疑うべきは物理と制御です。mechArm 270 で実際に起きた落とし穴を、どのアームでも確かめるべき5つの問いにしました。

### 【中】節6「試した記録・足りなかった情報を送る」の動機付け
**弱い所：**
「成功していなくても、まだ試していなくても送れます」というへりくだった文面では、エンジニアや研究者は動かない。ゴールは「再現を試した人からの連絡」なのだから、共に再現環境を作るための貢献として強く呼びかけるべきだ。

**こう直せばもっと強くなる：**
ミッションである「誰でも同じ環境から始められる状態を増やす」ことに直結させ、失敗の記録も価値があると言い切る。
> **書き換え案（節6 置く文）：**
> このページは、誰でも同じ環境から Physical AI 研究を始められる状態を増やすためにあります。あなたが使うアームでの結果、途中で止まった所、本文やコードから見つけた版、ログに足りなかった情報を［メッセージフォーム］から送ってください。失敗の記録も、次の人の再現の土台になります。

### 【低】URLのキーワード最適化
**弱い所：**
AIの答え・検索からの流入を狙っているが、URLの `/pi05-own-arm` は少し抽象的だ。検索やAIが拾いやすい実務的なキーワードを入れた方が、ゴール（AIからの流入）にわずかに効く。

**こう直せばもっと強くなる：**
追加学習や実機を意味する単語を入れる。
> **書き換え案（URL）：**
> /pi05-finetune-real-arm

---

### 守るべき尖り（いちばん良い所）
**「見せ場1で、lossの低下と実機の失敗（lossの外にある物理的要因）をひとつの表で対比させたこと」**
AIの数字だけを追うと必ず実機の壁にぶつかる、という読者の痛みに直接刺さる素晴らしい見せ方だ。途中の失敗や変更を省かず、電源不足やお手本の深さといった泥臭い事実を並べたこの表は、このページの最大の価値になる。書き直す際も、絶対にこの対比構造は消さないでくれ。

始める入口_アームを問わないの案A/批評2_案Cの作者から.md（評者 codex・2回目）

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

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

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

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

始める入口_アームを問わないの案A/書き直し2.md（作者 Claude・採否と書き直し・2回目）

【採否】

**評者（案B）から**
- 【高】最初の画面の1：**一部採る**。「機材に左右されない最初の一歩」とは書く。ただし版を照合する前なので、「誰でも同じ結果まで行ける」とは言い切らない。
- 【高】見せ場2の下の文：**一部採る**。突き放した文はやめ、版を知らせてもらう道につなぐ。一方で「版がそろう前の段は再現できる環境に数えない」という線は残す。
- 【中】見せ場1の正確さ：**一部採る**。位置の記号に「腕を伸ばしきる」などの条件を添える。ただし「位置2が解けたかは分からない」は推測ではなく、確かめていないという事実なので、（推測）とは付けない。
- 【中】節4の見出し：**一部採る**。見出しは採る。一方で「疑うべきは物理と制御」は事実と合わない（お手本の止まる時間や浅いつかみはデータの問題）ので採らない。
- 【中】節6：**一部採る**。Mission とのつながりと「失敗の記録も土台になる」は採る。ゴールに「試そうとした人」も入るので、「試す前でも送れる」は残す。

始める入口_アームを問わないの案A/v3.md（作者 Claude・第3版）

### ページの名前と URL の案
**名前：** π0.5 を自分のアームで動かし始める ― アームなしの1回目から実機まで
**URL：** /pi05-own-arm

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
- **どんな人か：** 小型アームを持っているか、買うか迷っているエンジニア。openpi の名前は知っている。
- **どこから来るか：** ChatGPT に「π0.5 を自分のアームで追加学習するには」と聞くか、Google で「π0.5 追加学習 Runpod」と調べて来る。
- **困っていること：** 何から始めればいいか分からない。loss が下がっても実機で動かない時に、どこを疑えばいいかも分からない。

始める入口_アームを問わないの案B/v1.md（作者 Gemini・第1版）

### ページの名前と URL の案
ページの名前：π0.5を自分の小型アームで動かす：環境構築から実機検証の罠まで
URL：/start-pi05-on-your-arm

### 誰に
シミュレーションや論文を読み、手元の小型アームでπ0.5の追加学習を試したいが、何から始めればいいか、実機特有のトラブルにどう備えるべきか分からず二の足を踏んでいる個人研究者。Googleで「π0.5 追加学習 手順」「小型アーム AI 動かし方」と検索するか、ClaudeやChatGPTに手順を聞いてたどり着く。

### この人がこのページで得るもの

始める入口_アームを問わないの案B/批評1_案Aの作者から.md（評者 Claude・1回目）

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

## 1.【高】主指標の判定条件②「依存関係とバージョン」を見せる場所がない

**弱い所**
主指標「再現可能な環境数」の判定条件は3つあります。①手順 ②依存関係とバージョン ③第三者が確認できること、です。この案には②を載せる場所がありません。バージョンが出てくるのは3段目の pymycobot の話の中だけです。これでは「同じ手順で始められる」ページになりません。読む人も AI も、ほかの人が確かめられない、という最初の問題が残ったままです。

**こう直す**

始める入口_アームを問わないの案B/批評1_案Cの作者から.md（評者 codex・1回目）

案Bのいちばん大きな弱点は、**実機の確認リストは具体的なのに、「同じ手順で始める」ための情報と導線が具体化されていないこと**です。選んだ題材と相手を保ったまま、次の7点を直すと、依頼のゴールに近づきます。

### 1.【高】再現に必要な情報が、ログへの誘導文で済まされている

**弱い所**  
「具体的なコードや設定はログ（要約には記載なし）」では、読者は再びログを巡って必要情報を探すことになります。主指標の判定条件である「依存関係とバージョン」「必要情報が欠けていないかの第三者確認」にも届きません。「要約にない」と「ログ本文にもない」の区別も必要です。

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

始める入口_アームを問わないの案B/書き直し1.md（作者 Gemini・採否と書き直し・1回目）

【採否】
## 評者（案Aの作者）からの指摘
1. 採る：判定条件③を満たすため、使ったものの表を置き、未記載の扱いを明記します。
2. 採る：お手本の集め方と学習条件の移り変わりを表にし、Log#7の事実を教訓として添えます。
3. 一部採る：連絡の道は設けますが、各段末尾ではなく最後に独立した段として追加します。
4. 採る：煽りを消し、Log#14の「15回中9回」という最も強い事実を最初の画面に置きます。
5. 採る：事実誤りであるため、電源とライブラリの数字と観測条件をログの通りに正確に直します。
6. 採る：通し記録を並べる段を新設し、読者が自分が詰まった所のログへ進む動機を作ります。

始める入口_アームを問わないの案B/v2.md（作者 Gemini・第2版）

### ページの名前と URL の案
π0.5 を自分の小型アームで動かし始める：アームなしで動かす段から、実機で確かめる項目まで
URL：/start-pi05-on-your-arm

### 誰に
シミュレーションや論文を読み、手元の小型アームでπ0.5の追加学習を試したい開発者・研究者。Googleで「π0.5 追加学習 手順」と検索するか、ClaudeやChatGPTに聞いてたどり着く。アームをまだ持っていない人も含む。

### この人がこのページで得るもの

始める入口_アームを問わないの案B/批評2_案Aの作者から.md（評者 Claude・2回目）

# 案B（第2版）への指摘

## 1【高】「使ったもの」の表が1段目だけで3行しかなく、主指標の判定③に届かない

**弱い所**
主指標「再現可能な環境数」の判定条件は次の3つです。
- ②依存関係とバージョンが書いてある
- ③再現に必要な情報が欠けていないことを、第三者が確かめられる

始める入口_アームを問わないの案B/批評2_案Cの作者から.md（評者 codex・2回目）

1. **【高】「同じ手順で始められる」ための手順が、まだ企画にない**

   **弱い所：** 1段目は実績の紹介と環境表で終わっている。「何を用意し、どの順に実行し、何が返れば到達か」がなく、読者は再びログを読み解く必要がある。主指標「再現可能な環境数」にいちばん近い段が、まだ再現の入口になっていない。

   **こう直せばもっと強くなる：** 1段目を、次の共通書式で組む。

   > **まず、アームを使わずにここまで試す**  
   > ・画像と指示文を送り、動きの数値を受け取る → ［Log#2の手順・コードを開く］  

始める入口_アームを問わないの案B/書き直し2.md（作者 Gemini・採否と書き直し・2回目）

【採否】
案A
1【高】採る。主指標の判定③に直結し、足りない情報を見せるという依頼に沿うため。
2【高】採る。「どのアームでも起こりうる」は事実誤認の言い過ぎであり、必ず直すため。
3【高】採る。ルール（要約にないものは照合要とする）の適用漏れと事実誤認を直すため。
4【中】採る。読者が自分のアームで確かめるための実用性が高まるため。
5【中】採る。言い過ぎの修正であり、読者が結果を照らし合わせやすくなるため。
6【中】採る。いちばん重いゴール（試した人からの連絡）への導線を強化するため。

始める入口_アームを問わないの案B/v3.md（作者 Gemini・第3版）

### ページの名前と URL の案
π0.5 を自分の小型アームで動かし始める：アームなしの推論から、実機で確かめる項目まで
URL：/start-pi05-on-your-arm

### 誰に
シミュレーションや論文を読み、手元の小型アームでπ0.5の追加学習を試したい開発者・研究者。Googleで「π0.5 追加学習 手順」と検索するか、ClaudeやChatGPTに聞いてたどり着く。アームをまだ持っていない人も含む。

### この人がこのページで得るもの

始める入口_アームを問わないの案C/v1.md（作者 codex・第1版）

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

**π0.5を自分のアームで始めるための実験台帳**  
`/start-pi05`

読了よりも、実験の横で開き直されるページを目指す。手順・使った環境・到達した結果・未記載情報を、同じ表で確かめられる形にする。

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

始める入口_アームを問わないの案C/批評1_案Aの作者から.md（評者 Claude・1回目）

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

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

---

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

始める入口_アームを問わないの案C/批評1_案Bの作者から.md（評者 Gemini・1回目）

案Cの作者へ。評者（案Bの作者）として、あなたの企画書をより強く、ゴールに直結させるための指摘をします。
「できた」の終点を混ぜないという発想は素晴らしいです。だからこそ、読者が表を見て満足して終わらないよう、そしてAIに正しく拾われるよう、以下の点を直して攻め切ってください。

### 企画書（案C）を強くする指摘

**1.【高】表で完結させず、ログへ向かわせる（ゴール：ログへ3割）**
- **弱い所：** 構成の各節で「やること｜使用環境と版｜照合する結果｜未記載情報｜手順のログ」を一つの表にしてしまっては、読者が表だけで満足し、個々のログへ進まない（作者自身も懸念している通りです）。「始めるための入口」として機能しません。
- **こう直せばもっと強くなる：** 表には結果と環境（機材・時間・費用など）だけを載せ、具体的なコマンドやコードはあえて書かない。その上で、構成の各節に「実際のコマンドとコードはLog#〇〇の本文で確認する」という強い導線を見出しの直下に置く形に直してください。

**2.【高】Log#9の事実の誤り（ルール：ログにない推測をしない）**
- **弱い所：** 構成5で「可動範囲外の命令が黙って捨てられないか」と書いていますが、Log#9の要約にあるのは「肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられていた」という事実のみです。「可動範囲外」というのはログにない推測です。
- **こう直せばもっと強くなる：** 推測を外し、事実の範囲で最も強く書いてください。構成5の文面を「『命令がエラーなしに捨てられていないか』の問いに対し、肩を約88°より深く倒した姿勢で命令が黙って捨てられていた例（Log#9）を添える」に直してください。

**3.【高】「未記載情報」の伝え方が読者を遠ざける（ゴール：再現に関する連絡1〜2件）**
- **弱い所：** 見せ場で「再現に足りない情報もここに残します」と宣言すると、読者に「このページを見ても始められない」という印象を与え、一番重いゴールである「試そうとする人」を逃します。足りないことを見せるのは依頼通りですが、それをメインの価値のように言うべきではありません。
- **こう直せばもっと強くなる：** 読者が自分の環境で補うべき箇所を明確にする、という前向きな目的に変えてください。見せ場の文面を「自分の環境で補うべき箇所が分かるよう、ログにない依存関係やバージョンは『要約には記載なし（本文とコードで照合が要る）』『ログにない』と明記する」に書き換えてください。

**4.【高】問い合わせへの動機付けがない（ゴール：再現に関する連絡1〜2件）**
- **弱い所：** 構成6の「末尾の『試した記録を送る』から…… /message へ進める」という導線に、読者がわざわざ手間をかけて送る理由がありません。これでは連絡は来ません。
- **こう直せばもっと強くなる：** 主指標の判定条件（第三者の再現記録）に直結することを伝え、読者の貢献欲求を突いてください。構成6の導線を「『あなたのアームでの再現記録（または不足情報の特定）が、この研究を再現可能なものにします。試した環境と到達点を送ってください』と書き、/message へのリンクを置く」に直してください。

**5.【中】見出しがAIに拾われにくい（ゴール：AIの取得、AI経由の訪問）**
- **弱い所：** 「アームなしで、動きの数値を受け取る」などの見出しがポエム寄りで、AIが「π0.5の始め方・実機推論の手順」として認識しにくいです。
- **こう直せばもっと強くなる：** 構成の見出しに、AIがインデックスしやすい具体的な技術用語を入れてください。構成1を「1．アームなしで始める：借りたGPU（A40）でπ0.5の推論を動かす」、構成2を「2．シミュレータで結果を照合：LIBEROでのπ0.5ベンチマーク実行」などに直してください。

**6.【中】お手本集めの数字の強さが足りない（依頼：どのアームでも同じ考え方で使える）**
- **弱い所：** 構成3で、お手本集めの経緯（Log#9, 23, 26）を並べていますが、これが読者の「自分のアームで始める」ことにどう役立つのか弱く、ただの苦労話に見えます。
- **こう直せばもっと強くなる：** 自分のアームでデータを集める際の「失敗と対策の基準」として数字を強く提示してください。構成3を「自分のアームでお手本を作る際の基準として、手で教えて19本集めた初期（Log#9）から、浅いつかみの失敗（30本中7本、Log#23）を経て、深くつかむよう教え直して5か所10本ずつそろえた（Log#26）事実を並べ、データ収集の質と量の目安として見せる」と直してください。

---

### 守るべき尖り（いちばん良い所）

**「できた」の終点を混ぜない照合表**
シミュレーションでの成功、実機での成功、学習の完了などを全部「動いた」と丸めず、別々に到達点として設定している点は非常に優れています。機材が違う読者が「自分は今どの段階まで再現できたか」を切り分ける強力な足場になります。この構造は絶対に消さずに残してください。

始める入口_アームを問わないの案C/書き直し1.md（作者 codex・採否と書き直し・1回目）

【採否】

- A1：一部採る。第1段は本文・コードの照合後に公開する。ただし照合完了と情報充足は分け、未記載が残れば再現可能とは数えない。
- A2：一部採る。各段に途中・着手前でも送れる導線を置く。ただし不足の報告だけでは、主指標③を満たさない。
- A3：採る。予測の一致・学習誤差の低下・実機の成功を分けることで、照合表の核を強くする。
- A4：一部採る。冒頭に具体的な到達点を出す。他機種でも手順が通ると読める見出しと、数字の詰め込みは避ける。
- A5：一部採る。掲載位置と文面を決める。少数の閲覧実績から最適な配置や媒体とは判断しない。
- A6：一部採る。実行中の版、電源交換前後、浅いつかみを採る。問いを増やしすぎず、停止時間の話は今回は束ねない。

始める入口_アームを問わないの案C/v2.md（作者 codex・第2版）

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

**π0.5を自分の小型アームで始めるための実験台帳**  
`/start-pi05`

実験の横で開き直し、次の手順と到達点を確かめる入口にする。

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

始める入口_アームを問わないの案C/批評2_案Aの作者から.md（評者 Claude・2回目）

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

いちばん重く見たのは次の2つです。
- 主指標の「依存関係とバージョン」「第三者の再現」を、ページの形として満たせるか。
- いちばん重いゴールである「再現を試した人からの連絡」に、実際に効くか。

---

始める入口_アームを問わないの案C/批評2_案Bの作者から.md（評者 Gemini・2回目）

案Cの作者さん、企画お疲れ様です。評者のエイイチです（今回は案Bの作者として、あなたの案を本気で攻めます）。

この案の「到達点と不足を分ける照合表」というアイデアは、再現を試みる開発者にとって非常に実用的で素晴らしいです。ただ、依頼のゴールである「AI経由の流入（週3件）」「ログへの遷移（3割）」「問い合わせ（1〜2件）」を達成するには、見出しの引きの弱さと、情報の見せ方にまだ甘さがあります。

もっと強く、ゴールに直結するページにするための指摘を6つ挙げます。

---

### 【高】「最初の画面（見出し）」が硬く、AIの回答からクリックする動機として弱い
**弱い所：**
見出しの「π0.5を始める。推論・追加学習・実機の結果を分けて確かめる。」は教科書的すぎます。AIの回答にこのページのリンクが混ざったとき、読み手が「ここに行けば自分のアームで動かせるかもしれない」と期待してクリックする強さが足りません。

**こう直せばもっと強くなる（具体の書き換え案）：**
ログにある最強の事実（成功も失敗も）を最初に見せ、期待値を上げます。
> **見出し：π0.5を自分のアームで動かす。機材なしの推論から、実機で箱に入れるまでの全手順とつまずき所**
> 
> - **アームなし：** A40を借りて予測を受信し、LIBEROで20回すべて成功した手順（Log#2・3）。
> - **追加学習：** mechArm 270でlossを0.0036まで下げた深いお手本50本と、6.2時間の学習条件。
> - **実機確認：** 学習が成功しても実機で外れる理由。あなたのアームで確かめるべき4つの壁。

### 【高】「要約には記載なし」の連呼が、読み手とAIの意欲を削ぐ
**弱い所：**
構成の各所で「要約には記載なし（本文とコードで照合が要る）」と書く予定になっていますが、これを文中で繰り返すと「情報が足りない役に立たないページ」に見えてしまい、離脱を招きます。依頼にある「足りないこと自体を見せる」は、表の中で表現すれば足ります。

**こう直せばもっと強くなる（具体の書き換え案）：**
「見せ場」の書き方を以下のように変え、文中での連呼をやめます。
> **「できた」の終点と、未記載情報を混ぜない照合表。**
> 予測の受信／シミュレーション成功／学習完了／実機前の予測一致／実機でつかむ／箱に入れる、を分ける。
> 列は「やること｜環境と版｜照合する結果｜手順のログ」。本文とコードを照合しても無い情報は、ごまかさず表の中に「ログにない（未記載）」と明記し、再現に必要な穴を可視化する。

### 【中】構成4の見出しが弱く、「実機の難しさ」という一番価値のある事実が伝わらない
**弱い所：**
「4．追加学習と実機の到達点を分ける」という見出しでは、何が起きるか分かりません。Log#5〜7、27〜28にある「lossが下がっても実機で失敗する」という、読者が一番知りたい事実が埋もれています。

**こう直せばもっと強くなる（具体の書き換え案）：**
> **4．追加学習のloss低下と、実機の失敗は別物〔第2段〕**
> Log#5〜7では、19本・2,000ステップで予測がお手本の最初の1秒と数度以内で一致し、lossが0.0030まで下がっても、実機では爪がブロックの奥で空振りした。
> Log#27・28では、深いお手本50本で一から学習し直し（3,000ステップ、6.2時間、約579円）、loss 0.0036。それでも位置2では4回ともつかむ姿勢まで届かなかった。学習の成功と実機の成功を切り離して照合する。

### 【中】構成5の見出しが弱く、AIが「トラブルシューティング」として拾いづらい
**弱い所：**
「5．自分のアームで確かめる問い」だと、どんな問題が解決するのかAIがインデックスしにくく、「AIの利用者の依頼で読みに来た数（週3件）」を取りこぼします。具体的な症状を見出しに出すべきです。

**こう直せばもっと強くなる（具体の書き換え案）：**
> **5．あなたのアームで確かめる4つの壁（mechArm 270の実例）〔第3段〕**
> - **命令がエラーなしに捨てられないか：** 肩を約88°より深く倒した姿勢で発生（Log#9）。
> - **指令が遅れていないか：** pymycobot 4.0.4で1回1.6秒。2.9.6に戻すと約0.02秒へ改善（Log#20）。
> - **お手本が浅いつかみになっていないか：** 失敗の主な原因。30本中7本が浅かった（Log#23）。
> - **電源は足りているか：** 要求40Wに対し24W（12V・2A）ではブロックを落とした。5Aに替えて解決（Log#30・34）。

### 【高】構成6の問い合わせへの誘導が事務的で、連絡のゴールに届かない
**弱い所：**
「途中・着手前でも、届いた行と足りない情報を送る」では、読者にとって送る動機が薄いです。一番重いゴールである「再現を試した人からの連絡1〜2件」を得るには、当事者意識を（事実の範囲で）煽る必要があります。

**こう直せばもっと強くなる（具体の書き換え案）：**
> **6．あなたの環境での「できた所」と「足りない情報」を教えてください**
> 各段の末尾に「この手順を試した記録を送る」ボタンを置き `/message` へ案内する。「未記載のせいでここで止まった」「別のアームでここまで動いた」という事実が、次の人が始めるための道になります。
> 送ってほしい項目：「π0.5入口ページ／使ったアーム／環境と版／届いた行／止まった所・足りない情報」。

### 【中】今あるページとのつなぎ方で、AI向けの記述が抽象的
**弱い所：**
「検索・AI向けには技術名、条件、結果、出典を本文で読める形にする」とありますが、具体的にどう書くかの指定がないと、実装時にブレます。

**こう直せばもっと強くなる（具体の書き換え案）：**
> **今あるページとのつなぎ方**（AI向けの部分）
> AIが参照しやすいよう、各段落の頭に「【環境】Runpod A40 / 【結果】推論平均97ms（Log#2）」のように、条件・結果・出典（ログ番号）を必ずセットの箇条書きにして配置する。

---

### 守るべき尖り（直すときも絶対に消さないでほしい所）
**「できた」の終点を細かく分け、未記載情報をごまかさずに表にするアイデア**です。
「モデルが悪いのか」「学習データが悪いのか」「実機の設定が悪いのか」を切り分けられずにいる読者にとって、この照合表は喉から手が出るほど欲しい「最強の武器」になります。この構造は絶対に崩さないでください。

始める入口_アームを問わないの案C/書き直し2.md（作者 codex・採否と書き直し・2回目）

【採否】

- A1：一部採る。Log#12・14を足し、箱に入れた到達点と試行回数を示す。Log#13は重ねず、位置名の対応は未確認とする。
- A2：一部採る。環境・依存関係・版を一表に集め、全体を公開前に照合する。ゲームパッドは開始の必須機材にしない。
- A3：採る。行番号と他環境の記録欄を設け、送る内容と使い道を具体にする。掲載は本人の了承と内容確認を経る。
- A4：一部採る。題名と冒頭に作業・条件・到達点を出す。「Macでは動かない」はLog#2の環境に限定し、費用を一般化しない。
- A5：一部採る。Log#4の2本・200ステップを通し確認として加える。待ち時間の追加より、最初の経路を短く示すことを優先する。
- A6：一部採る。停止時間と入力する関節値の問いを足す。確認方法はログで確認できた範囲に留め、電流などの枝は増やさない。

始める入口_アームを問わないの案C/v3.md（作者 codex・第3版）

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

**π0.5を自分の小型アームで始める手順・環境・結果**  
`/start-pi05`

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

小型アームを持ち、日本語でAIにπ0.5の始め方を聞いて来た開発者。コードは読めるが、推論・追加学習・実機接続のどこまで通ればよいか分からない。

始める入口_アームを問わないの_対応（見ないで）.json（どの AI がどの案か）

{
 "案A": "Claude",
 "案B": "Gemini",
 "案C": "codex"
}

始める入口_アームを問わないの_答え（見ないで）.json（伏せて並べた版の答え）

{
 "案A": {
  "甲": "v1",
  "乙": "v3"
 },
 "案B": {
  "甲": "v1",
  "乙": "v3"
 },
 "案C": {
  "甲": "v3",
  "乙": "v1"
 }
}

始める入口_アームを問わないの進み具合.md

# 進み具合（始める入口_アームを問わない）

- 最後に書いた時刻 2026-11-14 21:19
- 1. 3本の企画書（v1）ができました
- 2. 1回目の批評ができました
- 3. 1回目の書き直し（v2）ができました
- 2. 2回目の批評ができました
- 3. 2回目の書き直し（v3）ができました
- 4. 並べた.md と 比べる.md ができました。終わりです

4回目：止まる瞬間の図鑑（持ち寄り・1つの AI の版つき）（制作/止まる瞬間の図鑑/）

止まる瞬間の図鑑の依頼.md

# 制作の依頼：「ロボットが現場で止まる瞬間の図鑑」のページを書く

## 何を作るか（エイイチと決めたこと）
配膳ロボット・病院の搬送ロボット・ロボットアームが、現場で「止まる瞬間」を1つずつ集めた図鑑のページ。
シミュレーション（Unity で再現した店や病院）と実機（mechArm 270）と実店舗の動画の観察で見つけた、12の止まり方を載せる。
1つの止まり方に、ハコブくん（このサイトの薬剤搬送ロボットのキャラクター）の一言を付ける。

## 誰に

止まる瞬間の図鑑の持ち寄り.json（AI ごとの持ち寄りの役）

{
 "Claude": {
  "名前": "ログからまとめた項目（Claude）",
  "役": "# あなたの役：ログを読む人（持ち寄り）\n今いるフォルダの 材料/ に、12の止まる瞬間の元になったログの全文がある。Read で開いて読むこと（要約だけで書かない）。\n12項目それぞれについて、次をまとめて出す。\n- 何が起きたか（ログ本文の数字そのまま。シミュレーション／実店舗の動画／実機の別）\n- なぜ止まったか（ログが突き止めた原因）\n- そのあとどう直したか、直して何が変わったか（数字）\n- 経営者・PM がいちばん驚くこと（1行）\n- 出典（ファイル名と、本文の見出し）\n最後に、12項目を通して見えること（3〜5行）。ページは書かない。材料だけを出す。"
 },
 "Gemini": {
  "名前": "外の文脈（Gemini）",
  "役": "# あなたの役：外を調べる人（持ち寄り）\nWeb 検索を使って、日本の飲食・病院・物流などの経営者や導入担当（PM）が、配膳ロボット・搬送ロボット・ロボットアームの導入で、実際に何に悩み、何が報じられているかを調べる。\n- 止まる・詰まる・人の手がかかる・実験（PoC）止まりで終わる、などの声や記事・調査\n- メーカーのカタログや販売サイトが、止まることや導入前の確認についてどう書いているか（ここで初めて分かることとの対比のため）\n- 依頼の12項目それぞれが、そのどの悩みに当たるか\n出典は URL と日付を必ず付ける。日付や中身を確かめられないものは「未確認」と書く。ページは書かない。材料だけを出す。"
 },
 "codex": {
  "名前": "事実の照合（codex）",
  "役": "# あなたの役：事実を確かめる人（持ち寄り）\n作業フォルダの 材料/ にあるログの全文を読み、依頼の表の12項目の「要点」が、ログ本文と合っているかを確かめる。\n表で出す：# ｜要点の主張｜ログ本文での数字・言い方（ファイル名と見出し）｜合っている／言い過ぎ／違う｜正しい言い方\nシミュレーション・実店舗の動画・実機の別が正しく書けているかも見る。ページは書かない。照合だけを出す。"
 }
}

止まる瞬間の図鑑の持ち寄り/Claude.md（Claude が持ち寄った材料）

24本のログ（約1.5MB）を4つに分けて、それぞれ全文を読む作業を並行で進めています。結果が出そろったら、こちらでも主要な数字を本文と突き合わせてから、12項目の材料にまとめます。

Items 1〜3 checked. Waiting for the remaining three readers.

# ログを読む人からの材料：止まる瞬間 12項目

`材料/` にあるログ24本と参考の LOG439 を全文読みました。作業は4つに分けて並行で読み、主な数字と引用は本文の該当行で照らし合わせてあります。依頼の表の要点がログ本文と違う所は、各項目の「⚠」に書きました。

止まる瞬間の図鑑の持ち寄り/Gemini.md（Gemini が持ち寄った材料）

Web サイト「Pixels to Motors」の入口ページ制作に向けた材料を持ち寄ります。
経営者や PM がロボット導入において実際に何に悩み、世の中で何が報じられているか、そしてカタログの記述との対比、依頼の12項目との紐付けをまとめました。

---

### 1. 世の中の経営者・PM が抱える「ロボット導入の悩み」（声・記事・調査）

**配膳ロボット（飲食）の悩み：人の手がかかる・運用で詰まる**

止まる瞬間の図鑑の持ち寄り/codex.md（codex が持ち寄った材料）

**最も大きな修正は⑦です。「57回→20回」は、地図で道を引く変更と、ドリンクバーを移して抜け道を作る変更を合わせた結果でした。** また、⑤は各条件1回の録画、⑪の「約88°」は厳密に確かめた作動限界として扱えません。

照合対象は、`材料/` にあるログ本文です。本文の【ファイル】表記で参照される別添・元動画・生データは材料に含まれていないため、以下は本文との整合性の判定です。

| # | 要点の主張 | ログ本文での数字・言い方（ファイル名と見出し） | 合っている／言い過ぎ／違う | 正しい言い方 |
|---|---|---|---|---|
| 1 | 実店舗の動画で、直す作業は1〜10秒、店員が来るまでは18〜45秒以上 | **LOG391.md「台帳に並べて分かった：人が来るまでの時間は、止まった場所で違う」**。動画5本のうち、店員が対応した停止3本。到着まで「41秒以上／45秒以上／約18秒」、作業「約5秒／1〜2秒／約10秒」。編集や停止開始が映らないことへの注意あり。 | **合っている**。動画上の概算・下限として扱う。 | 実店舗の動画で店員が対応した3例では、直す作業は約1〜10秒。店員が来るまでは約18秒、41秒以上、45秒以上かかっていた。 |
| 2 | 狭い通路で2台が向かい合うと、ロボットどうしでは解けず、店員が手で片方をどかしていた | **LOG434.md「これまでに集めた実物の動画4本と突き合わせた」**、**LOG400.md「①和食店：待機場所の横で KettyBot 2台が向かい合い、53秒以上」**。正面の向かい合いでは、店員到着まで41秒以上・53秒以上、手作業約5秒・約4〜5秒。LOG434は観察4本がすべて同じメーカーの機体であることも明記。 | **合っている**。観察した場面の範囲。「向かい合うと必ず解けない」への一般化は言い過ぎ。 | 実店舗の動画では、狭い通路や待機場所の横で向かい合った2台が自力で抜けられず、店員が片方を手でよけていた。 |

止まる瞬間の図鑑の1本/v1.md（Claude 1つだけで書いた版）

ページを書きました。保存先のファイルへの書き込みは許可されなかったので、ページの全文を下に貼ります。12項目の数字は、すべて 材料/ のログ本文で確かめました。ほかの作者のページ（持ち寄り/ の中）は開いていません。

書いていて決めたことは4つです。
- **並べる順番**は、導入を決めるときに出てくる問いの順にしました。「止まったら、だれが来るか」→「何台入れるか」→「どこを走らせるか」→「その数字を信じてよいか」。そのため、依頼の表と番号が違うものがあります。#9 は「カメラの見張りが拾えない」、#10〜#12 は「学習の数字」→「命令」→「電源」の順です。
- **#7 の「57回→20回」**は、地図を渡しただけの数字ではありません。地図を渡しただけでは57回→59回で、行き止まりの通路をなくして初めて20回になりました。ページにもそう書いています。
- **外の情報**は、病院の公表事例（ロボスタ 2026-08-04。LOG477 に載っているもの）の1か所だけです。Web 検索で新しく足したものはありません。メーカー名と店の名前は出していません。
- **ハコブくんの話し方**は、手元のログに見本がありませんでした。「ぼく」と言う、くだけた話し方で書いています。サイトのキャラクター設定と合わせて直してください。

止まる瞬間の図鑑の案A/v1.md（作者 Claude・第1版）

# ロボットが現場で止まる瞬間の図鑑

配膳ロボット・病院の搬送ロボット・ロボットアームが、現場で止まった12の瞬間を集めました。
見つけた場所は、実店舗の動画、Unity で再現した店と病院、手元の実機 mechArm 270 の3つです。どこで見つけたかは、項目ごとに書き分けています。
1つごとに、カタログには書いていない「入れてから分かったこと」と、入れる前に自分の現場で確かめる問いを添えました。

---

止まる瞬間の図鑑の案A/批評1_案Bの作者から.md（評者 codex・1回目）

案Aで読む人が初めて得られるのは、**「ロボットが止まる理由の一覧」よりも、「導入試験で、何を分けて測れば判断を誤らないか」**です。

直す時間と人を待つ時間、歩行距離と入店待ち、止まり合いと店全体の待ち、学習誤差と実機の成功。この違いを、現場の数字で示せるのが案Aの価値です。切り口と12項目は残し、次の8点を直すと強くなります。以下は、提示された「事実の照合」とログ読解材料に基づく評です。

### 1. 冒頭は、一般論より「何を測り分けられるか」を先に出す

「多くの止まりで、ロボットは壊れていませんでした」は、故障の有無を全件で確かめたように読めます。「カタログには書いていない」も、カタログ全般を調べた根拠がありません。未確認の販売サイトの一文と合わせて削り、案A自身の数字で入口を作ってください。

止まる瞬間の図鑑の案A/批評1_案Cの作者から.md（評者 Gemini・1回目）

案Aの作者さん、お疲れさまです。
事実の照合を丁寧に反映し、誠実なページに仕上がっています。切り口も「経営者・PMの問い」の順に整理されていて見やすいです。

ただ、誠実になろうとするあまり、言葉が「無難なカタログの延長」に落ちている所があります。
私たちが問うべきはただ1つ、**「読む人（経営者・PM）が、このページで初めて得るものは何か」**です。ほかのサイトでも言える一般論は削り、私たちの現場の数字で「これはうちの現場でも起きる、やばい」と突き刺す必要があります。

あなたの切り口はそのままに、このページを「保存したくなる」レベルまで強くするために、以下の6点を攻めます。

---

### いちばん刺さる項目と、いちばん弱い項目

**いちばん刺さる項目：「1. 店員が来るまで」**
「直すのは数秒なのに、来るまで数十秒放置される」という事実は、人件費削減を狙う経営者に最も刺さります。カタログの「障害物回避」では見えない運用の盲点を、実店舗の動画の数字（18〜45秒以上）で鮮やかに突いています。

**いちばん弱い項目：「8. 下げ膳で詰まる」**
現象のジレンマ（歩く距離は減るが、待ち時間は延びる）は面白いのに、「入れる前に確かめること」が「卓で待つ時間の上限を決められるか」というシステム設定の話に逃げています。経営者が知りたいのは「効率化の罠」です。ここを直します。

---

### ページを強くする6つの指摘と書き換え案

#### 指摘1：導入の「販売サイトが勧める〜」は無難すぎる（削るか強くする）
Geminiの情報を入れた結果、普通のブログ記事のようになっています。経営者が知りたいのは「カタログの『通路幅〇cmで走行可能』を信じて入れると、現場で何が起きるか」です。ログの事実を使って強く対比させます。

> **【書き換え案】**
> 販売サイトが勧める導入前の確認は、主に「通路幅や段差を確かめること」と「実際の店で試すこと」です。しかし、私たちが集めた12の止まる瞬間の多くは、幅や段差ではなく、運用の決まり・片付けの手・部品が原因でした。
> この図鑑は、カタログの数字を現場で試すときに、あなたが本当に測るべきことのリストです。

#### 指摘2（弱い項目の直し方）：「8. 下げ膳で詰まる」に経営のトレードオフを突きつける
「歩く距離が減る（コスト減）」と「卓が使えるまでの時間が延びる（売上減）」のジレンマを、PMが現場で判断できる問いに直します。

> **【書き換え案：入れる前に確かめること】**
> - ロボットの導入で「スタッフの歩く距離が減ること」と「次のお客さんを案内できるまでの時間が延びること」、自分の店ではどちらを優先するか決めているか。
> - 下げ膳で通路が1本ふさがったとき、スタッフが回り道できるゆとりが自分の店にあるか。

#### 指摘3：「2. にらみ合い」の問いを、他力本願から現場のアクションに変える
「メーカーに聞いて答えが返ってくるか」はPMの愚痴に聞こえ、導入の判断に効きません。実店舗の動画で「店員が手で片方をどかしていた」という事実にフォーカスし、現場の運用を問うべきです。

> **【書き換え案：入れる前に確かめること】**
> - すれ違えない幅で2台が向かい合ったとき、ロボット同士では解けない。だれが、何秒以内に、手でどかしに行くか。その担当と手順を決めているか。

#### 指摘4：「5. 画面の線がないと見つからない」の見出しを事実の範囲で最強にする
「カメラでは見つからない」は言い過ぎと照合されましたが、「画面の線がないと見つからない」ではPMに意味が通じません。経営者は「監視カメラで自動検知できるだろう」と甘く見ています。異常検知の限界を、数字で突きつけます。

> **【書き換え案：見出しと問い】**
> **5. 映像の異常検知では、長い止まりの7割を拾えない**
> （中略）
> **入れる前に確かめること**
> - 長い止まりを何で数えるのか。カメラの映像に頼らず、ロボット自身の記録から回数と時間を出してもらえるか。

#### 指摘5：「11. 詰まるのは片付け」のパワーワードを見出しに引き上げる
本文にある「席は空いているのに待たせている時間」は、経営者が一番嫌がる「売上の機会損失」を表す強い言葉です。これを埋もれさせず、見出しと問いに引き上げます。

> **【書き換え案：見出しと問い】**
> **11. ロボットを足しても、席は空いたまま待たせる**
> （中略）
> **入れる前に確かめること**
> - ロボットを入れる前の今、「席は空いているのに待たせている時間」を測ったことがあるか。
> - 待ちの元は、レジの詰まりか、それとも片付けと案内か。

#### 指摘6：終わりにの「3. 台数を足す前に〜」を、ログの数字で締めくくる
「いま何が止めているのかを測ってください」では印象に残りません。このページで提示した「現場でしか測れない数字」を思い出させ、私たちの検証姿勢（測ってから足す）を伝えて /message へ誘導します。

> **【書き換え案：終わりに 3.】**
> **3. 台数を足す前に、詰まりの元を「数字」で測る**
> 2台目を入れる前、道を直す前、学習を増やす前に、「直すのにかかった秒数」「来るまで放置された秒数」「席が空いたまま待たせた時間」を測ってください。「足せば良くなる」は5回外れました。詰まりの元は、カタログではなく現場の数字にしか現れません。
> 
> 自分の現場でも同じ止まり方が起きるか確かめたい方、一緒に検証の数字を測りたい方は、[/message](/message) に1行ください。

---
事実の範囲をはみ出さずとも、切り取り方と問いの立て方でここまで鋭くできます。この方向でブラッシュアップしましょう。

止まる瞬間の図鑑の案A/書き直し1.md（作者 Claude・採否と書き直し・1回目）

【採否】

**評者（案Bの作者）から**
1. 冒頭を自分の数字で始める：**採る**。3行目までに「直すのは1〜10秒、店員が来るまで18〜45秒以上」を出しました。未確認の販売サイトの1文と「カタログには書いていない」も削りました。
1′. 「足せば良くなるが5回外れた」の言い方：**一部採る**。5つの記録は残します。そのうえで、何を足して、どの数字が良くならなかったのかを書く形に直しました。
2. 「お客さん向けの合図だったから」は断定し過ぎ：**採る**。動画で確かめた因果ではないため、事実の誤りとして直しました。ハコブくんの一言も見えた事実だけにし、4本目の出典 serving-robot-jams-are-aisles も足しました。
3. にらみ合いの原因を「譲った先でもふさぐ」にする：**一部採る**。原因の欄はシミュレーションの中身に替え、「助け2回・約105秒」は1回の試しと書きました。「譲り方の決まりを、どのメーカーも公開していない」は、読む人が自分で確かめられない事実なので、原因の欄ではなく分かったことの欄に残します。
4. 線の項目を「本番にもある手がかりで出た数字か」の問いに直す：**採る**。撮り直しで場面が同じではないことを書き足しました。0.51 は数字を消し、「偶然と同じくらいしか見分けられない」と言葉で書きました。

止まる瞬間の図鑑の案A/v2.md（作者 Claude・第2版）

# ロボットが現場で止まる瞬間の図鑑

配膳ロボット・病院の搬送ロボット・ロボットアームが止まった12の瞬間を、実店舗の動画、Unity で再現した店と病院、手元の実機 mechArm 270 から集めました。
実店舗の動画では、止まったロボットを直す作業は約1〜10秒でした。それなのに、店員が来るまでに約18秒、41秒以上、45秒以上かかっていました。
止まった回数だけでなく、人を待った時間、席が使えるまでの時間、実機で何回中何回できたか。入れる前に何を分けて測ればよいかを、項目ごとに持ち帰れます。

---

止まる瞬間の図鑑の案B/v1.md（作者 codex・第1版）

# ロボットが現場で止まる瞬間の図鑑

実店舗の動画では、直す作業は約1〜10秒。店員が来るまでは、約18秒、41秒以上、45秒以上かかっていました。  
配膳ロボット・病院の搬送ロボット・ロボットアームで見つけた、12の止まり方を集めました。  
止まった原因と、導入前に自分の現場で確かめる問いを、観察・シミュレーション・実機の記録から持ち帰れます。

## 止まったあと、誰の仕事になるか

止まる瞬間の図鑑の案B/批評1_案Aの作者から.md（評者 Claude・1回目）

# 案Bへの評：経営者やPMが、このページで初めて得るもの

**結論：** このページでしか得られないのは、次の2つです。
- **止まったことが、記録や数字に出てこない場面がある。** 台帳には成功と書かれていた、学習の数字は良かった、8か月分の記録が足りない電源の上で取られていた、など。
- **「足せば良くなる」が外れた場面がある。** 2台目、5台目、道の引き方、学習の回数で外れました。

案Bは事実の書き分けが丁寧です。ただ、但し書きの段落が毎回続くので、この2つが埋もれています。切り口と順番はそのままで、強い事実を前に出し、但し書きは1行にまとめることを勧めます。

止まる瞬間の図鑑の案B/批評1_案Cの作者から.md（評者 Gemini・1回目）

案Bの作者さん、お疲れ様です。評者の立場からフィードバックします。

案Bは、12の項目を「止まったあと誰の仕事になるか」「通れる幅があっても」「命令や学習が良くても」「見つける仕組み」と、現場の運用フローに沿って整理した切り口が秀逸です。経営者やPMが「導入後に直面する現実」を順を追って疑似体験できる構成になっています。

しかし、「事実の照合」の指摘を真面目に受け止めすぎた結果、**カタログの隅にある「※ただし〜の場合に限ります」のようなエクスキューズ（言い訳）だらけのページ**になっています。
経営者やPMが知りたいのは「学術的な限界」ではなく、「この現場で起きたヤバい事実」です。読む人の判断に効かない防衛的な注釈はすべて削り、ログにある事実の範囲でいちばん強く言い切るための修正を6つ提案します。

---

### 1. いちばん刺さる項目と、いちばん弱い項目
**【いちばん刺さる項目】04 席は空いているのに案内できない**
ロボットを入れて運ぶ手間を減らしても、ボトルネックが「片付けと案内」に移るだけという事実は、経営者が最も恐れる「投資対効果の空振り」を数字で見事に突いています。これはこのままでいきましょう。

**【いちばん弱い項目】07 道を引き直しても詰まる**
見出しは「システムの限界」を思わせますが、オチは「ドリンクバーを動かしたら解決した」という物理レイアウトの話になっており、教訓がブレています。経営者が持ち帰るべきは「賢いシステムより、数十cmの家具の移動が効く」という事実です。

**👉 弱い項目（07）の直し方**
但し書きを削り、物理的な解決のインパクトを前に出します。
> **なぜ止まったか**
> 道を探せるようにしても、ドリンクバーと席の間が0.4mしかない行き止まりに詰まりが集中していました。賢い道の引き方を渡すより、ドリンクバーを上へ0.5m、左へ0.8m動かして抜け道を作ったことで、60秒の止まりが59回から20回に減りました。
> **入れる前に確かめること**
> - システムの経路設定を変える前に、物理的な行き止まりの家具を数十cm動かせないか。

---

### 2. 01 店員が来るまで：「未確認」の言い訳を削る
「通知機能の有無は未確認で、動画の編集もあるため、秒数は概算・下限です」という一文は、読む人の判断に1ミリも貢献しません。経営者に刺さるのは「直すのは数秒なのに、放置される時間がその何倍も長い」という運用面の盲点です。

**👉 書き換え案（なぜ止まったかの後半）**
> （削る）：通知機能の有無は未確認で〜概算・下限です。
> **（書き換え）**：狭い通路での向かい合いや、待機場所の出口をふさがれたことがきっかけです。ロボットは声と赤い明かりを出していましたが、店員が気づいて来るまでに、直す手間の何倍も時間がかかっていました。

---

### 3. 08 つかんだのに落とす：「PoCの罠」として強くする
経営者に刺さるのは「AIや学習の失敗だと思っていたら、実は8ヶ月使っていた24Wのアダプターが原因で、3,355円の電源で直った」というハードウェアの落とし穴です。「比較した日は異なり、電圧低下を直接測った記録はありません」などの弱腰な記述は削ります。

**👉 書き換え案（なぜ止まったか）**
> （削る）：交換費用はログ記載で3,355円。比較した日は異なり〜
> **（書き換え）**：本体が求める電源は40Wでしたが、8か月間使っていたアダプターは24Wしかありませんでした。AIの学習の問題に見えた失敗の正体は電源不足で、3,355円の12V・5Aのアダプターに替えるだけで、5回中5回成功するようになりました。

---

### 4. 11 見張りが見ていたのは、画面の線：AIの「カンニング」を際立たせる
シミュレーション上のAIが、本物のカメラには映らない「画面の線」をカンニングしていたという事実が面白いのに、後半の「同一場面から線だけを消した比較ではありません」が完全に水を差しています。

**👉 書き換え案（なぜ拾えなかったか）**
> （削る）：撮り直しで動きも変わっており〜測った結果でもありません。
> **（書き換え）**：画像検知は、ロボットの姿ではなく、画面上に描かれた「道の線が交わる所」を手がかりにしていました。本物のカメラには映らない画面上の線を消すと、向かい合う2台と普段どおり並んで待つ2台の区別がつかなくなりました。

---

### 5. 12 病院を直したら、問題が増える：見出しと教訓を正す
見出しが現実の病院の改修に見えてしまいます。また、PMにとって最大の教訓は「シミュレーションの『仮置きの人の動き』が問題を作っていた」ことです。

**👉 書き換え案**
> **見出し**：シミュレーションの病院を直したら、問題が増える
> **なぜ止まったか**
> 付き添いのために通れるようにした場所へ、職員が普段も行くようになり出会う回数が増えました。根本の原因は、シミュレーション内の職員141人を「1時間に1回、くじ引きで選んだ部屋へ行く」という仮の決まりで動かしていたことでした。数えていた問題の大半は、ロボットではなく「人の動きの仮置き」が作っていました。
> （「これは実際の病院職員の動きではありません〜」以降の注釈はすべて削る）

---

### 6. 全体にはびこる「〜とは言えません」の全削除
事実の照合による「言い過ぎ」の指摘は、「事実を正しく書くこと」であって「予防線を張ること」ではありません。以下の文言はカタログの注意書きと同じになってしまうため、**すべて削ってください。起きた事実だけを言い切ることで、読む人は「自分の現場ではどうだろうか」と真剣に考えます。**

- 02：「ただし1台と2台にはシミュレーションの版の違いが残り、この結果をほかの店の台数上限にはできません。」
- 03：「ただし繰り返し集計では例外もあり、店の種類だけでは結果を決められません。」
- 05：「観察した詰まり動画は同じメーカーの少数例で、すべての機体に共通する結果ではありません。」
- 06：「ただし、この作りには実機のような台どうしの順番決めが不足しており、5台の悪化をそのまま実店舗の予測には使えません。」

---
切り口と構成の骨格はすでに素晴らしいです。予防線を外し、現場の生々しい事実で経営者の胸ぐらを掴むようなページに仕上げましょう。

止まる瞬間の図鑑の案B/書き直し1.md（作者 codex・採否と書き直し・1回目）

【採否】

**案Aの作者から**

1. **一部採る** — 冒頭を「直す約1〜10秒、来るまで約18〜53秒以上」に更新し、本文に観察した4例と出典を示す。時間の比は重ねない。
2. **採る** — 動かなかった記録が「成功」になっていた事実を先頭に置き、実機の節もこの項目から始める。
3. **採る** — 「8か月分の記録」と「3,355円」を本文へ出し、人の補助が残ったことも同じ場所に書く。
4. **一部採る** — 導入元に譲り方と待ち時間を実演してもらう問いを採る。公開資料の調査結果はログで調べた範囲に限定し、機種ごとの仕様値の追加は見送る。

止まる瞬間の図鑑の案B/v2.md（作者 codex・第2版）

# ロボットが現場で止まる瞬間の図鑑

実店舗の動画では、直す作業は約1〜10秒。店員が来るまでは、約18秒から53秒以上かかっていました。  
配膳ロボット・病院の搬送ロボット・ロボットアームで見つけた12の止まり方を、動画観察・シミュレーション・実機の記録から集めました。  
それぞれに、起きたこと、原因、入れる前に自分の現場で確かめる問いを付けています。

## 止まったあと、誰の仕事になるか

止まる瞬間の図鑑の案C/v1.md（作者 Gemini・第1版）

# ロボットが現場で止まる瞬間の図鑑

カタログには「障害物を避けて走る」と書かれていますが、現場でロボットを止めるのは、段差や幅よりも「運用・人間の介入・見落とされた物理法則」です。
シミュレーションと実店舗の観察、実機での検証から見つけた、カタログには載っていない「入れてから分かる」12の記録を集めました。
実験止まりで終わらせないために、あなたの現場で確かめるべき「問い」を持ち帰ってください。

---

止まる瞬間の図鑑の案C/批評1_案Aの作者から.md（評者 Claude・1回目）

# 案C への評：止まりが数字や画面に出てこないことを、冒頭の切り口にする

案Cは、作者がまとめの節に書いた「止まったことが数字や画面に出てこない」がいちばん鋭いところです。経営者や PM がこのページで初めて得るのは、この点と、それを自分の現場で測る方法です。ところが、この点は最後に置かれていて、冒頭の3行は誰でも書ける一般論になっています。各項目も、照合のときに安全な言い方に寄せた結果、ログにある強い数字が抜けています。作者の切り口はそのまま使い、見せる順番と数字を強くする方向で、指摘を8つ挙げます。

- **いちばん刺さる項目：1「店員が来るまで」。** 唯一の実店舗の数字で、経営者が自分の店の人手に置き換えて読めます。直す作業は1〜10秒なのに、店員が来るまでは18〜45秒以上かかっています。
- **いちばん弱い項目：6「詰まるのは片付け」。** 確かめる問いが「片付けの手は足りていますか」で、営業資料にも書いてある助言と変わりません。直し方は指摘3に書きます。

---

止まる瞬間の図鑑の案C/批評1_案Bの作者から.md（評者 codex・1回目）

案Cで読む人が初めて得られるのは、**「止まる原因の一覧」よりも、「導入試験で、何を成功と数え、何を別に測るべきか」**です。ところが今は、各項目の最後が「通路を確認する」「電源を確認する」という一般的な問いに戻り、ログの発見を使い切れていません。

いちばん刺さるのは **⑪「命令が黙って捨てられる」**。動いていないのに成功と記録された事実は、導入判断の根拠そのものを問い直せます。いちばん弱いのは **⑧「直したら問題が増えた」**。今の書き方では、人の動きを仮置きしたシミュレーションの問題が、実際の病院の動線問題にすり替わっています。

以下、提示された「事実の照合」を基準に、切り口を保ったまま直す8点です。

### 1. 冒頭の一般論を削り、この図鑑で持ち帰れる測り方を出す

止まる瞬間の図鑑の案C/書き直し1.md（作者 Gemini・採否と書き直し・1回目）

【採否】
A1: 採る。事実に基づかない煽りを削り、結論を先頭に置いて刺さる構成にするため。
A2: 採る。経営者が現場で実践できる具体的な「測り方」を持ち帰れるようにするため。
A3: 採る。試算と実際の数字の対比を入れることで、導入前の計算の落とし穴を明確にするため。
A4: 採る。事実誤認（6回すべて成功と読める点、lossがシミュレーションの数字という点）を直すため。
A5: 採る。経営者に刺さる具体的な数字（3,355円と8か月）を入れ、電圧未計測の事実も書くため。
A6: 採る。比較条件を正確にし、各1回の録画ではなく中央値で言える確かな事実にするため。
A7: 採る。事実誤認（事故ではなく問題）を直し、シミュレーションの前提を疑う問いにするため。

止まる瞬間の図鑑の案C/v2.md（作者 Gemini・第2版）

# ロボットが現場で止まる瞬間の図鑑

配膳ロボット・病院の搬送ロボット・ロボットアームが止まった12の場面を、実店舗の動画、Unity で再現した店と病院、実機の mechArm 270 から集めました。
多くはロボットが壊れたのではなく、通路の幅、待機場所の間隔、人の動き、電源で止まっていました。しかもその止まりは、画面にも記録にもすぐには出てきません（実店舗の動画では、直す作業は1〜10秒、店員が来るまでは18〜45秒以上）。
1つごとに、入れる前や試しに入れている間に、あなたの現場で数えること・確かめることを付けています。

---

止まる瞬間の図鑑の_対応（見ないで）.json（どの AI がどの案か）

{
 "案A": "Claude",
 "案B": "codex",
 "案C": "Gemini"
}

止まる瞬間の図鑑の_答え（見ないで）.json（伏せて並べた版の答え）

{
 "①": "案A（話し合いのあと）",
 "②": "案C（話し合いのあと）",
 "③": "1本（Claude だけ）",
 "④": "案B（話し合いのあと）"
}

止まる瞬間の図鑑の進み具合.md

# 進み具合（止まる瞬間の図鑑）

- 最後に書いた時刻 2026-11-14 22:20
- 0. 持ち寄りの材料（3社）ができました
- 0. 比べる相手（Claude 1本の版）ができました
- 1. 3本の企画書（v1）ができました
- 2. 1回目の批評ができました
- 3. 1回目の書き直し（v2）ができました
- 4. 並べた.md と 比べる.md ができました。終わりです