---
title: "3つのAIで作ったページは、1つのAIに勝てるか ― ロボットが止まる瞬間の図鑑"
slug: three-ai-team-page-vs-one-ai-robot-stops
date: 2026-11-15
day: 511
meta_description: "3つのAIが材料を持ち寄って書いたページ3本とClaudeだけの1本を伏せて比べると、最も良いのはcodexの版、最も悪いのはClaudeが書いたチームの版だった。codexの版で、ロボットが現場で止まる12の場面の図鑑を公開した。"
tags: [マルチAI, Claude, Gemini, codex, AI活用, 配膳ロボット, ロボット導入, Webサイト]
ai_consult: true
series: "ひとり研究所の裏側"
---

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

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

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

前の記事「[YouTubeの企画を良くしようと、3つのAIに話し合わせた](https://pixelstomotors.com/record/three-ai-youtube-planning-no-good-topics)」では、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つだけで書いた版と伏せて並べます。やったことの全体は次のとおりです。

| 順 | やったこと | 出たもの | 作り手の判定 |
|---|---|---|---|
| 1 | 3つの AI に、入口のページの案を60回の会議で話し合わせた（合議） | 実験記録への入口・配膳ロボットの試算の条件・mechArm 270 の症状から探す、の3案 | 何を達成したいページなのかが分からない |
| 2 | 合議をやめ、3つの AI が別々に企画書を書いて直し合う形（制作チーム）で、ゴールを決めて3回かけ直した | 企画書3本×3回。最初の版と最後の版を伏せて比べると、3本のうち2本で最後の版が選ばれた | 色々ゴネゴネしてて伝わらなそう |
| 3 | 読み手を決め直した（フィジカルAI という言葉に反応するのは、主に経営者・PM） | Claude が出した企画のうち「ロボットが現場で止まる瞬間の図鑑」 | いちばん刺さった |
| 4 | 3つの AI に材料を持ち寄らせ、別々に書いて直し合い、Claude 1つの版と伏せて比べた | 4本の図鑑のページ | 良いのは④（codex）、悪いのは①（Claude のチーム） |
| 5 | ④をもとにページを作り、公開した。トップと /series8 に入口を置いた | /robot-stops | 画像・タブ・カードの直しを経て了承 |

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

【図解】LOG511_blind_four.html

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

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


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

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

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

| AI | どこの AI か | Mac からの呼び方 | この記事での持ち場 |
|---|---|---|---|
| Claude | Anthropic | [Claude Code](https://docs.claude.com/en/docs/claude-code/overview)（コマンドで Claude を動かす道具）を `claude -p` で呼ぶ。記録のファイルを開いて読める | 記録（LOG）の全文を読んで、12の場面をまとめる |
| Gemini | Google | [Gemini API](https://ai.google.dev/)（プログラムから Gemini を呼ぶ窓口）。Google 検索を使える | Web で、経営者・PM の悩みと報道を調べる |
| codex | OpenAI | [Codex CLI](https://developers.openai.com/codex/cli)（コマンドで OpenAI のコード向けの AI を動かす道具）。ChatGPT の定額の枠で使う | 記録の全文と照らして、要点の数字が合っているかを確かめる |

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

### 合議と制作チームの違い

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

| 言葉 | やり方 | 残りやすいもの |
|---|---|---|
| 合議 | 3つの AI が1枚のボードを順番に直し、全員の反論を通った案を残す | だれも反論できない、無難な案 |
| 制作チーム | 3つの AI が、互いの案を見ずに1本ずつ書く。ほかの2つが直し方つきで指摘し、作者が書き直す。1つにまとめず、並べたまま人が選ぶ | 作者ごとの尖った案（3本とも同じ題材になることもある） |


## 作業ログ ― 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 が書いたファイル」）。

| 案 | ページ | 読む人 |
|---|---|---|
| 1 | π0.5 と mechArm 270 の実験記録への入口（/pi05-mecharm-records） | 小型アームで学習と実機を試したい開発者 |
| 2 | 配膳ロボットの試算条件を読む（/serving-robot-simulation-conditions） | 導入を判断する経営者・担当 PM |
| 3 | mechArm 270 の症状から探す実装記録（/mecharm-270-debug-index） | 把持・停止・座標ずれで詰まった開発者 |

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

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


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

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

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

| かけた回 | 依頼で変えたこと | 終わった時刻 |
|---|---|---|
| 入口のページ | 会議と同じ依頼で、制作チームの形だけを変えた | 19:57 |
| 再現の入口 | ゴール（3か月で表示150件・連絡1〜2件）を依頼に入れた | 20:58 |
| 始める入口_アームを問わない | mechArm 270 を前提にせず、ほかのアームでも始められる入口にした | 21:19 |

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

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

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


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

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

| 理由 | 2回目までに起きていたこと |
|---|---|
| 3つの AI が、同じ材料から書いていた | 依頼に入れたログの一覧は3つとも同じ。違う会社の AI でも、同じ材料からは同じような案が出る |
| 決まりで縛りすぎていた | 「言い過ぎない」「保証しない」「30件未満で言い切らない」を守るほど、ページの言葉が弱くなった |

作り手に、ここで止めずに考え直すよう言われ、仕組みを組み直しました。変えたのは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の場面は次のとおりです（依頼の表のまま。数字は持ち寄りで記録の全文と照らしました）。

| # | 止まる瞬間 | もとにした記録 |
|---|---|---|
| 1 | 店員が来るまで | LOG391 |
| 2 | にらみ合い | LOG434・LOG400 |
| 3 | 2台目が待ちを延ばす | LOG423・LOG393 |
| 4 | 待機場所の止まり合い | LOG452・LOG456・LOG465 |
| 5 | 下げ膳で詰まる | LOG440・LOG444 |
| 6 | 詰まるのは片付け | LOG397・LOG398 |
| 7 | 線に縛ると詰まる | LOG370・LOG374 |
| 8 | 直したら衝突が増えた | LOG477・LOG488・LOG491 |
| 9 | カメラでは見つからない | LOG418 |
| 10 | まさかの電源不足 | LOG487・LOG504 |
| 11 | 命令が黙って捨てられる | LOG352 |
| 12 | 学習の数字は良いのに外れる | LOG345・LOG348 |


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

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

| 番 | だれの版 | 字数 | 作り手の判定 |
|---|---|---|---|
| ① | 3つの AI の版（作者 Claude） | 13,464 | いちばん悪い |
| ② | 3つの AI の版（作者 Gemini） | 7,811 | ― |
| ③ | Claude 1つだけの版 | 12,909 | ― |
| ④ | 3つの AI の版（作者 codex） | 8,591 | いちばん良い |

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

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

| | ④（codex・いちばん良い） | ①（Claude のチーム・いちばん悪い） |
|---|---|---|
| 書き出し | 「実店舗の動画では、直す作業は約1〜10秒。店員が来るまでは、約18秒から53秒以上かかっていました。」と、数字から入る | 「先に、12を並べて分かったこと」の節で、12を通して言えることを先にまとめる |
| 並べ方 | 「止まったあと、誰の仕事になるか」など、導入を決めるときに出てくる問いで4つに分ける | 「一　止まったことに、すぐには気づけない」のように、漢数字の章で3つに分ける |
| 項目ごとの欄 | 何が起きたか・なぜ止まったか・**測った条件**・確かめること・出典・ハコブくんの一言 | 何が起きたか・なぜ止まったか・確かめること・出典・ハコブくんの一言 |

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

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

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

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


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

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

| 順 | 作り手からの指摘 | 直したこと |
|---|---|---|
| 1 | またテキストだけのデザインで、見づらい | 場面ごとのカードの片側に、シミュレーションの画面・実機の写真・実店舗の動画のコマを大きく置き、左右を交互にした |
| 2 | すぐに 01・02 のような番号を使う。ありきたり | 項目の番号を外した |
| 3 | 使用許可のない画像を使ってはいけない（YouTube ならともかく） | SNS の動画から切り出した画像を外し、自分で撮ったものとシミュレーションの画面だけにした。この決まりをページのコードの頭にも書いた |
| 4 | アームとサービスロボットは、タブで切り替えた方が良い | 「サービスロボット」「ロボットアーム」のタブにした |
| 5 | タブに付けた「9場面」「実機 mechArm 270」などの補足は要らない | 補足を外した |
| 6 | 切り替えのタブだとひと目で分かるデザインに | タブの上の角を丸め、選んでいるタブを黒く塗り、下の黒い線とつなげた |
| 7 | カードのデザインの決まりをサイトと合わせる | 押せる目次のカードを、サイトの記録のカードと同じ白・角丸8px・影にした |
| 8 | 押せないカードに影を付けていた（影は「押せる」の印） | 場面のカードから影を外した |
| 9 | ハコブくんのアイコンがずれている／黒い枠は要らない | 体の絵の切り抜きをやめ、顔を真ん中にした丸い絵（160px）を作った。枠は外した |
| 10 | 残っている直しを進めるよう指示 | 図や表だった3場面を、シミュレーションの録画の1コマに替えた。最初の画面の動画から数字の板を切り落とした |

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

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

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

| 場面 | 店と録画 | 探した記録 | 切り出した時刻 |
|---|---|---|---|
| 2台目で待ちが延びる | 28卓の店・ロボット2台（真上からの録画 2560×1872） | `stops.csv` の止まった理由が「もう1台のロボット」で、60秒止まった所 | 店の時計で1,290秒（2台が1.1m離れて向かい合っている） |
| 下げ膳中、通路をふさぐ | 細い通路の店・ロボット2台・下げ膳あり（斜め上からの録画 3840×2160） | `bus_runs.csv` の皿を待っている間（9,121〜9,244秒）に、`people_jams.csv` でお客さんがロボットに止められた所 | 9,160秒 |
| 席は空いているのに案内できない | 46卓の店・ロボット2台（真上からの録画 2560×1726） | `timeline.csv` で、入店待ちが15組・片付いていない卓が12卓の所 | 6,720秒 |

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

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

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

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

| 置き場所 | 置き方 | 理由 |
|---|---|---|
| /series8（サービスロボット導入シミュレーション） | 配膳ロボットの LP のバナーの下に、同じ形のバナーを置く | 12場面のうち9場面が、このシリーズの記録から来ている |
| トップ | 「導入前ガイド」に3枚目のカードとして足す。GPU と配膳の2枚の下に、横いっぱいで置く | 導入を決める人という、同じ読み手向けのページ。トップは長く、セクションを増やすと届きにくい |

公開したあと、作り手から、バナーにはサービスロボットだけでなくアームも一緒に載せるよう指示がありました。図鑑はサービスロボットとロボットアームの両方を載せるページだからです。バナーの画像を、左にシミュレーションの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 の版・伏せて比べる表まで）

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

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

流れ（1つの依頼につき）:
  1. 3社（Claude・Gemini・codex）が、互いに見せずに企画書を1本ずつ書く（v1）
  2. ほかの2社が評者として攻める。指摘は必ず「弱い所」と「こう直せばもっと強くなる」の組。
     案を捨てる・題材を変えさせる権限は誰にもない。事実の誤りは、ログにある範囲でいちばん強い言い方に直して示す
  3. 作者が書き直す。指摘を取り込むかは作者が決め、尖りは守る。2〜3を 回数.txt の回数（既定2）くり返す
  4. 3本を並べたまま終える（並べた.md）。選ぶのはエイイチ
  5. 話し合いで良くなったかを確かめる（比べる.md）。各作者の最初の版と最後の版を、
     どちらがどちらか伏せて並べる。答えは _答え（見ないで）.json
  評者にも作者の名前は伏せる（案A・案B・案C と呼ぶ）。どの社がどの案かは _対応（見ないで）.json

置き場所: PixelstoMotors/サイト改善/制作/{依頼の名前}/
  依頼.md      Claude が書く。何を作るか・守ること・材料（数字・ログ一覧）
  回数.txt     書き直しの回数（無ければ2）
  かける.txt   印。終わると かけた.txt に名前を変える
  止める.txt   置くと、いまの段が終わったところで止まる（消せば続きから。できたファイルは作り直さない）

使い方（Mac のターミナルで）:
  python3 site_team.py --check     3社が答えるかを確かめるだけ
  python3 site_team.py --once      印のついた依頼を1つ回す
  python3 site_team.py --install   5分ごとに見回るように登録する（YouTube の会議とは別に回る）
"""
import argparse, json, os, random, re, subprocess, sys, tempfile, time
from concurrent.futures import ThreadPoolExecutor
from datetime import datetime

HERE = os.path.dirname(os.path.abspath(__file__))                 # PixelstoMotors/サイト改善/_仕組み
P2M = os.path.dirname(os.path.dirname(HERE))                      # PixelstoMotors
BASE = os.path.join(P2M, "デジタルツイン学習R2R2R", "動画", "_制作ベース")
sys.path.insert(0, BASE)
import debate_runner as dr                                        # Gemini・codex の呼び方とキーを使い回す
cr = dr.cr

JOBS = os.path.join(os.path.dirname(HERE), "制作")
MARK, DONE, STOP, RUNNING = "かける.txt", "かけた.txt", "止める.txt", "実行中.txt"
AUTHORS = ["Claude", "Gemini", "codex"]
CLAUDE = os.path.expanduser("~/.npm-global/bin/claude")
CLAUDE_TIMEOUT = 25 * 60
PATH = ":".join([os.path.expanduser("~/.npm-global/bin"), "/opt/homebrew/bin", "/usr/local/bin", "/usr/bin", "/bin", "/usr/sbin", "/sbin"])
LABEL = "jp.adaptdesign.pixelstomotors.site-team"
PLIST = os.path.expanduser(f"~/Library/LaunchAgents/{LABEL}.plist")
LOGFILE = os.path.join(cr.CONF, "site_team.log")

GROUND = """\
# 前提（全員に共通）

あなたは、Webサイト「Pixels to Motors」（pixelstomotors.com）の、人の入口になるページを作る制作チームの一員です。
チームは3つの AI で、最後に人間（エイイチ）が選びます。
目指すのは、届けたい相手が「これは保存しておきたい」と思う、価値のあるページです。誰にも怒られない無難なページではありません。

## 守ること（エイイチが決めたこと）
- 個々のログ（/record/…）の形式は変えない。入口のページから送るだけ
- 題材を広げない。入口のページは、依頼の「ログ一覧」にある中身だけで作る。ログにない事実・数字を足さない
- トップや SNS に相談の窓口を出さない。新しいキャッチコピー・肩書きを足さない
- 中身より言い過ぎた見出し・煽り・他社を悪く言う演出はしない。ただし、ログにある事実の範囲でいちばん強く言うのはよい
- 日本語で書く。英語の文を混ぜない。数字には根拠（依頼の実際の数字・ログ・推測）を添え、推測は推測と書く
"""

PLAN = """\
## 企画書の形（3,000字以内。この見出しで書く）
### ページの名前と URL の案
### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
### この人がこのページで得るもの（1文）
### 最初の画面（見出しと、その下の3行。実際の文面で書く）
### 見せ場（このページにしかないもの。ログのどの事実か）
### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
### 束ねるログ（/record/… の一覧）
### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
### 公開後に見る数字（30件たまるまでは判断しない）
### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
"""

AUTHOR_V1 = """\
# あなたの役：作者
入口のページを1本、作者として企画してください。ほかの作者の案は見ていません。見る必要もありません。
- 依頼に「達成したいこと」と「ゴール」があれば、それに効くことを最優先にする
- 自分がいちばん価値があると思う題材と切り口を、ログ一覧から選ぶ。ほかの人も選びそうな無難な切り口より、あなたにしか出せない切り口を選ぶ
- 届けたい相手を1人に絞り、その人に深く刺さるように尖らせる
- 迷ったら、平均的な案ではなく、強い案を選ぶ。言い過ぎは後で直せるが、弱さは直せない
""" + PLAN

CRITIC = """\
# あなたの役：評者（{me}）
作者が書いた「{target}」の企画書を、もっと強くするために攻めてください。ほかの案とは比べません。
- 「強い」とは、依頼の「達成したいこと」と「ゴール」に効くこと。ゴールに効かない所をいちばん重く見る
- 指摘は必ず「弱い所」と「こう直せばもっと強くなる（具体の書き換え案・文面）」の組で書く。弱い所だけの指摘は書かない
- 案を捨てる・題材や相手を変えるよう求めない。作者が選んだ題材と相手のまま、強くする
- 事実の誤り（ログ一覧にないログ・ログにない中身・言い過ぎ）は、ログにある範囲でいちばん強い言い方に書き直して示す
- 指摘には重さを付ける：【高】直さないと伝わらない・誤り ／【中】直すと強くなる ／【低】好み。全部で5〜8個まで
- 最後に「守るべき尖り」として、この案のいちばん良い所を1つ書く（作者が書き直しで消さないように）
"""

REWRITE = """\
# あなたの役：作者（書き直し）
あなたが書いた企画書（{target}）に、2人の評者から指摘が届きました。
- 取り込むかどうかは、作者のあなたが決める。評者の言いなりにならない。案の尖り（いちばん良い所）は守る
- 事実の誤りの指摘だけは、必ず直す（ログにある範囲でいちばん強い言い方に）
- 出す形：まず【採否】として、指摘ごとに「採る／一部採る／採らない」と理由を1行ずつ。次に【企画書】として、書き直した企画書の全文
""" + PLAN


VALUE_CRITIC = """\
# あなたの役：評者（{me}）
作者が書いた「{target}」のページを、もっと価値のあるものにするために攻めてください。ほかの案とは比べません。
問うのは1つだけ：**読む人（ロボット導入を判断する経営者・任された PM）が、このページで初めて得るものは何か。**
- ほかのサイトやカタログでも手に入ること、読む人の判断に効かないことは「削る」か「この現場の数字で強くする」かを、書き換えの文面つきで示す
- いちばん刺さる項目と、いちばん弱い項目を1つずつ挙げ、弱い方の直し方を書く
- 案を捨てさせない。作者の切り口のまま強くする。指摘は5〜8個まで
- 事実の確かめは「事実の照合」の材料と照らして行う。合わない所は、ログにある範囲でいちばん強い言い方に直して示す
"""

REWRITE_PAGE = """\
# あなたの役：作者（書き直し）
あなたが書いたページ（{target}）に、2人の評者から指摘が届きました。
- 取り込むかどうかは、作者のあなたが決める。いちばん刺さる所は守る
- 事実の誤りの指摘だけは、必ず直す
- 出す形：まず【採否】として、指摘ごとに「採る／一部採る／採らない」と理由を1行ずつ。次に【企画書】として、書き直したページの全文
"""

AUTHOR_PAGE = """\
# あなたの役：作者
依頼の「ページの形」に沿って、ページそのものを書いてください。ほかの作者のページは見ていません。
- 依頼の後ろにある「持ち寄った材料」（ログからまとめた項目・外の文脈・事実の照合）を全部使う
- 読む人が「入れる前に知りたかった」と思うことを、いちばん前に出す。無難にまとめない
"""


def now():
    return datetime.now(dr.JST).strftime("%Y-%m-%d %H:%M")


def claude(prompt, cwd=None, tools=None):
    env = dict(os.environ)
    for k in ("ANTHROPIC_API_KEY", "ANTHROPIC_AUTH_TOKEN"):
        env.pop(k, None)
    env.update({"ENABLE_CLAUDEAI_MCP_SERVERS": "false", "PATH": PATH, "LANG": "ja_JP.UTF-8"})
    with tempfile.TemporaryDirectory() as tmp, tempfile.TemporaryFile("w+", encoding="utf-8") as fo, \
            tempfile.TemporaryFile("w+", encoding="utf-8") as fe:
        cmd = [CLAUDE, "-p", prompt, "--output-format", "text", "--permission-mode", "default"]
        if tools:
            cmd += ["--allowedTools", ",".join(tools)]
        p = subprocess.Popen(cmd, cwd=cwd or tmp, stdout=fo, stderr=fe, stdin=subprocess.DEVNULL, env=env, start_new_session=True)
        try:
            p.wait(timeout=CLAUDE_TIMEOUT)
        except subprocess.TimeoutExpired:
            p.kill()
            raise RuntimeError("Claude が時間内に答えませんでした")
        fo.seek(0); fe.seek(0)
        out, err = fo.read().strip(), fe.read().strip()
    if p.returncode != 0 or not out:
        raise RuntimeError(f"Claude が失敗しました（終了コード {p.returncode}）: {err[-600:]}")
    return out


class Caller:
    def __init__(self):
        self.key = dr.gemini_key()
        self.model, _ = dr.pick_model(self.key)

    def ask(self, who, system, user, wdir, search=False, files=False):
        for attempt in range(3):
            try:
                if who == "Gemini":
                    ans, _ = dr.gemini(self.key, self.model, system, user, search=search)
                elif who == "codex":
                    ans, _ = dr.codex(wdir, system + "\n\n" + user, web=False)
                else:
                    tools = (["Read", "Glob", "Grep"] if files else []) + (["WebSearch", "WebFetch"] if search else [])
                    ans = claude(system + "\n\n" + user, cwd=wdir if files else None, tools=tools or None)
                return ans.strip()
            except Exception as e:
                dr.log(f"  {who} 失敗（{attempt + 1}回目）: {str(e)[:200]}")
                if attempt == 2:
                    raise
                time.sleep(30)


def rd(p):
    return open(p, encoding="utf-8").read()


def wr(p, text):
    os.makedirs(os.path.dirname(p), exist_ok=True)
    dr.write(p, text)


def plan_part(ans):
    m = re.search(r"【企画書】\s*(.*)", ans, re.S)
    return (m.group(1) if m else ans).strip()


def progress(d, lines):
    wr(os.path.join(d, "進み具合.md"), f"# 進み具合（{os.path.basename(d)}）\n\n- 最後に書いた時刻 {now()}\n" + "".join(f"- {x}\n" for x in lines))


def run(d, dry=False):
    name = os.path.basename(d)
    req = rd(os.path.join(d, "依頼.md"))
    rounds = 2
    if os.path.exists(os.path.join(d, "回数.txt")):
        try:
            rounds = max(1, min(4, int(rd(os.path.join(d, "回数.txt")).strip())))
        except ValueError:
            pass
    mp = os.path.join(d, "_対応（見ないで）.json")
    if os.path.exists(mp):
        who_of = json.load(open(mp, encoding="utf-8"))
    else:
        labels = ["案A", "案B", "案C"]
        sh = AUTHORS[:]
        random.shuffle(sh)
        who_of = dict(zip(labels, sh))
        if not dry:
            wr(mp, json.dumps(who_of, ensure_ascii=False, indent=1))
    labels = sorted(who_of)
    pack_tasks = None
    if os.path.exists(os.path.join(d, "持ち寄り.json")):
        pack_tasks = json.load(open(os.path.join(d, "持ち寄り.json"), encoding="utf-8"))
    if dry:
        dr.log(f"［試し］{name}: 書き直し {rounds} 回・{who_of}")
        return
    call = Caller()
    wr(os.path.join(d, RUNNING), f"開始 {now()}\nPID {os.getpid()}\n")
    done = []
    pool = ThreadPoolExecutor(max_workers=3)

    def stopped():
        if os.path.exists(os.path.join(d, STOP)):
            progress(d, done + ["止める.txt があるので止まっています（消せば続きから）"])
            return True
        return False

    def step(jobs):
        """jobs: [(出力パス, 社, system, user[, {search, files}])]。まだ無いものだけを同時に"""
        todo = [j for j in jobs if not os.path.exists(j[0])]
        futs = [(j[0], pool.submit(call.ask, j[1], GROUND + "\n" + j[2], j[3], d, **(j[4] if len(j) > 4 else {}))) for j in todo]
        err = None
        for path, f in futs:                             # できた分は残す（続きから再開したときに作り直さない）
            try:
                wr(path, f.result() + "\n")
            except Exception as e:
                err = err or e
        if err:
            raise err

    try:
        dr.log(f"▶ 制作チーム {name}: 書き直し {rounds} 回")
        author_v1, critic, rewrite = AUTHOR_V1, CRITIC, REWRITE
        if pack_tasks:
            # 0. 持ち寄り：3社がそれぞれにしか取れない材料を作る（Claude と codex は 材料/ のログ全文を読む。Gemini は Web 検索）
            opt = {"Claude": {"files": True}, "codex": {}, "Gemini": {"search": True}}
            step([(os.path.join(d, "持ち寄り", f"{w}.md"), w, pack_tasks[w]["役"], req, opt[w]) for w in AUTHORS])
            packs = "\n\n".join(f"## {pack_tasks[w]['名前']}\n\n" + rd(os.path.join(d, "持ち寄り", f"{w}.md")) for w in AUTHORS)
            req_raw, req = req, req + "\n\n# 持ち寄った材料\n\n" + packs
            author_v1, critic, rewrite = AUTHOR_PAGE, VALUE_CRITIC, REWRITE_PAGE
            done.append("0. 持ち寄りの材料（3社）ができました")
            # 比べる相手：Claude 1本だけで、同じ生の材料から同じページを書く（持ち寄りも話し合いもなし）
            step([(os.path.join(d, "1本", "v1.md"), "Claude", AUTHOR_PAGE + "\n- 材料/ のログ全文を自分で読み、必要なら Web 検索もしてよい。持ち寄った材料は無い",
                   req_raw, {"files": True, "search": True})])
            done.append("0. 比べる相手（Claude 1本の版）ができました")
            progress(d, done)
        # 1. 互いに見せずに書く
        step([(os.path.join(d, L, "v1.md"), who_of[L], author_v1, req) for L in labels])
        done.append("1. 3本の企画書（v1）ができました")
        progress(d, done)
        for r in range(1, rounds + 1):
            if stopped():
                return
            # 2. ほかの2社が攻める（名前は伏せる）
            jobs = []
            for L in labels:
                cur = rd(os.path.join(d, L, f"v{r}.md"))
                for C in labels:
                    if C == L:
                        continue
                    sysm = critic.format(me=f"評者（{C}の作者）", target=L)
                    jobs.append((os.path.join(d, L, f"批評{r}_{C}の作者から.md"), who_of[C], sysm,
                                 f"{req}\n\n# 作者の企画書（{L}・第{r}版）\n\n{cur}"))
            step(jobs)
            done.append(f"2. {r}回目の批評ができました")
            progress(d, done)
            if stopped():
                return
            # 3. 作者が書き直す
            jobs = []
            for L in labels:
                cur = rd(os.path.join(d, L, f"v{r}.md"))
                crit = "\n\n".join(f"## 評者（{C}の作者）から\n\n" + rd(os.path.join(d, L, f"批評{r}_{C}の作者から.md"))
                                   for C in labels if C != L)
                jobs.append((os.path.join(d, L, f"書き直し{r}.md"), who_of[L], rewrite.format(target=L),
                             f"{req}\n\n# あなたの企画書（{L}・第{r}版）\n\n{cur}\n\n# 届いた指摘\n\n{crit}"))
            step(jobs)
            for L in labels:
                v = os.path.join(d, L, f"v{r + 1}.md")
                if not os.path.exists(v):
                    wr(v, plan_part(rd(os.path.join(d, L, f"書き直し{r}.md"))) + "\n")
            done.append(f"3. {r}回目の書き直し（v{r + 1}）ができました")
            progress(d, done)
        last = rounds + 1
        # 4. 3本を並べる
        wr(os.path.join(d, "並べた.md"), f"# 並べた（{name}・最後の版）\n\nどの社がどの案かは伏せています（_対応（見ないで）.json）。選ぶのはエイイチ。\n\n"
           + "\n\n---\n\n".join(f"# {L}\n\n" + rd(os.path.join(d, L, f"v{last}.md")) for L in labels))
        # 5. 最初と最後を伏せて比べる
        if pack_tasks:
            cands = [("1本（Claude だけ）", rd(os.path.join(d, "1本", "v1.md")))] + [(f"{L}（話し合いのあと）", rd(os.path.join(d, L, f"v{last}.md"))) for L in labels]
            random.shuffle(cands)
            marks = ["①", "②", "③", "④"]
            wr(os.path.join(d, "_答え（見ないで）.json"), json.dumps({m: c[0] for m, c in zip(marks, cands)}, ensure_ascii=False, indent=1))
            wr(os.path.join(d, "比べる.md"), "# 比べる（1本のAIより、話し合いの方が良いか）\n\n4本のうち1本は Claude だけで書いた版、3本は3社の持ち寄りと話し合いのあとの版です。どれがどれかは伏せています。"
               "いちばん良いものと、いちばん悪いものを選んでから、_答え（見ないで）.json を開いてください。\n\n"
               + "\n\n---\n\n".join(f"# {m}\n\n" + c[1] for m, c in zip(marks, cands)))
            ans, body = None, None
        else:
            ans, body = {}, []
        for L in (labels if ans is not None else []):
            pair = [("v1", rd(os.path.join(d, L, "v1.md"))), (f"v{last}", rd(os.path.join(d, L, f"v{last}.md")))]
            random.shuffle(pair)
            ans[L] = {"甲": pair[0][0], "乙": pair[1][0]}
            body.append(f"# {L}\n\n## 甲\n\n{pair[0][1]}\n\n## 乙\n\n{pair[1][1]}")
        if ans is not None:
          wr(os.path.join(d, "_答え（見ないで）.json"), json.dumps(ans, ensure_ascii=False, indent=1))
          wr(os.path.join(d, "比べる.md"), "# 比べる（話し合いで良くなったか）\n\n各案の最初の版と最後の版を、どちらがどちらか伏せて並べています。"
           "案ごとに「甲と乙のどちらが良いか」を決めてから、_答え（見ないで）.json を開いてください。\n\n" + "\n\n---\n\n".join(body))
        os.rename(os.path.join(d, MARK), os.path.join(d, DONE))
        done.append("4. 並べた.md と 比べる.md ができました。終わりです")
        progress(d, done)
        dr.log(f"✓ 制作チーム {name}: 終わりました")
        dr.notify(f"サイトの制作チームが終わりました：{name}")
    except Exception as e:
        wr(os.path.join(d, "エラー.txt"), f"{now()}\n\n{e}\n")
        progress(d, done + [f"エラーで止まりました（エラー.txt）。次の見回りで続きから試します"])
        dr.log(f"× 制作チーム {name}: {e}")
        dr.notify(f"サイトの制作チームが止まりました：{name}")
    finally:
        pool.shutdown(wait=False)
        p = os.path.join(d, RUNNING)
        if os.path.exists(p):
            os.remove(p)


def alive(d):
    p = os.path.join(d, RUNNING)
    if not os.path.exists(p):
        return False
    m = re.search(r"PID (\d+)", rd(p))
    if m:
        try:
            os.kill(int(m.group(1)), 0)
            return True
        except ProcessLookupError:
            os.remove(p)
            return False
        except PermissionError:
            return True
    return False


def once(dry):
    if not os.path.isdir(JOBS):
        dr.log("制作/ がありません")
        return
    for name in sorted(os.listdir(JOBS)):
        d = os.path.join(JOBS, name)
        if not os.path.isdir(d):
            continue
        f = set(os.listdir(d))
        if alive(d):
            dr.log(f"制作チーム {name} が動いています")
            return
        if MARK in f and STOP not in f and "依頼.md" in f:
            run(d, dry)
            return
    dr.log("印（制作/{名前}/かける.txt）のついたものはありません")


def check():
    call = Caller()
    dr.log(f"Gemini のモデル: {call.model}")
    for who in AUTHORS:
        t0 = time.time()
        a = call.ask(who, "短く答えてください。", "「準備できました」とだけ答えてください。", HERE)
        dr.log(f"{who}: {a[:40]}（{int(time.time() - t0)}秒）")


def install():
    os.makedirs(os.path.dirname(PLIST), exist_ok=True)
    os.makedirs(cr.CONF, exist_ok=True)
    cal = "".join(f"<dict><key>Minute</key><integer>{m}</integer></dict>" for m in range(4, 60, 5))
    plist = f"""<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
  <key>Label</key><string>{LABEL}</string>
  <key>ProgramArguments</key><array><string>{sys.executable}</string><string>{os.path.abspath(__file__)}</string><string>--once</string></array>
  <key>StartCalendarInterval</key><array>{cal}</array>
  <key>RunAtLoad</key><true/>
  <key>AbandonProcessGroup</key><true/>
  <key>WorkingDirectory</key><string>{HERE}</string>
  <key>EnvironmentVariables</key><dict>
    <key>PATH</key><string>{PATH}</string>
    <key>CODEX_HOME</key><string>{cr.CODEX_HOME}</string>
    <key>LANG</key><string>ja_JP.UTF-8</string>
  </dict>
  <key>StandardOutPath</key><string>{LOGFILE}</string>
  <key>StandardErrorPath</key><string>{LOGFILE}</string>
</dict></plist>
"""
    open(PLIST, "w").write(plist)
    subprocess.run(["launchctl", "unload", PLIST], capture_output=True)
    r = subprocess.run(["launchctl", "load", PLIST], capture_output=True, text=True)
    if r.returncode != 0:
        raise RuntimeError(f"登録できませんでした: {r.stderr.strip()}")
    print(f"登録しました。5分ごとに見回ります（いまも1回動きます）。記録: {LOGFILE}")


if __name__ == "__main__":
    ap = argparse.ArgumentParser(description="サイトの入口のページを、3社の AI の制作チームで作る")
    ap.add_argument("--check", action="store_true")
    ap.add_argument("--once", action="store_true")
    ap.add_argument("--dry-run", action="store_true")
    ap.add_argument("--install", action="store_true")
    a = ap.parse_args()
    try:
        if a.install:
            install()
        elif a.check:
            check()
        else:
            once(a.dry_run)
    except Exception as e:
        dr.log("×", e)
        sys.exit(1)
```


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

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

const path = '/robot-stops';
const url = SITE + path;
const title = 'ロボットが現場で止まる瞬間の図鑑 ― 入れる前に、自分の現場で確かめる12の問い';
const seoTitle = 'ロボットが現場で止まる瞬間の図鑑｜配膳・搬送ロボットとロボットアーム';
const description = '配膳ロボット・病院の搬送ロボット・ロボットアームが現場で止まった12の瞬間を、実店舗の動画観察・シミュレーション・実機の記録から集めた。止まったロボットを直すのは約1〜10秒、店員が来るまでは約18〜53秒以上。起きたこと・原因・入れる前に確かめる問いを、出典つきで。';
const published = '2026-11-14';
const modified = '2026-11-14';

type Src = { t: string; h: string };
type Item = { n: string; id: string; img: string; cap: string; metric: { l: string; v: string; u: string; n: string }; name: string; where: string; what: string; why: string[]; cond: string; ask: string[]; src: Src[]; hakobu: string };
type Chapter = { id: string; kind: 'svc' | 'arm'; title: string; items: Item[] };

const chapters: Chapter[] = [
  {
    id: 'whose-job', kind: 'svc', title: '止まったあと、誰の仕事になるか', items: [
      {
        n: '01', id: 'staff-arrival', img: 'LOG456_01_staff_beside_robots.png', cap: 'シミュレーションの店で、通路に固まった配膳ロボット2台とスタッフ・お客さん', metric: { l: '店員が来るまで', v: '約18〜53', u: '秒以上', n: '直す作業は約1〜10秒' }, name: '店員が来るまで', where: '飲食店／実店舗の動画観察',
        what: '店員が対応した動画4例では、直す作業は約1〜10秒、店員が来るまでは約18〜53秒以上でした。通路で向かい合った例では、来るまで41秒以上、直す作業は約5秒でした。',
        why: ['狭い通路で向かい合ったり、待機場所の出口をふさがれたりしていました。ロボットの声や赤い明かりが映っていても、助けが来るまでの時間は、直す時間より長くなっていました。'],
        cond: '編集された実店舗動画4例の観察。秒数は動画上の概算で、待ち時間には下限を含みます。',
        ask: ['忙しい時間に止まったら、誰が、何で気づくか。', '「止まってから人が着くまで」と「着いてから直すまで」を分けて測れるか。'],
        src: [{ t: '店員が来るまでと直す時間の記録', h: '/record/serving-robot-video-ledger' }, { t: '待機場所の横で53秒以上進めなかった動画', h: '/record/serving-robot-jams-are-aisles' }, { t: '通路に固まったロボットとスタッフの画面', h: '/record/serving-robots-jam-cause-standby-entry' }],
        hakobu: '直すのはすぐです。来てもらうまでが長いんです。',
      },
      {
        n: '02', id: 'second-robot', img: 'robot_stops_02_second_robot_v2.jpg', cap: '28卓の店を真上から。白い2台が席の前の一本道で向かい合い、どちらも進めない（シミュレーション）', metric: { l: '入店待ち', v: '13.8 → 25.1', u: '分', n: '1台 → 2台' }, name: '2台目で待ちが延びる', where: '28卓・スタッフ2人の飲食店／シミュレーション',
        what: '普通の混み具合で、入店待ちは1台の13.8分から、2台では25.1分へ延びました。スタッフがロボットを動かしに行く回数も、13回から54回に増えました。',
        why: ['2台とも近い方の狭い一本道を選び、向かい合ってふさぎ合っていました。「一本道は1台ずつ」にすると2台の入店待ちは17.6分まで縮みましたが、試した改善案でも1台より短くなりませんでした。'],
        cond: '来客などの条件を変えた10回の中央値。1台と2台ではシミュレーションの版が異なり、この店・人数・運用での比較です。',
        ask: ['2台目が加わると、どの一本道で出会うか。片方が待てる場所はあるか。', '運ぶ量だけでなく、人が助けに行く回数と入店待ちも改善するか。'],
        src: [{ t: '2台目と通行ルールを比べた記録', h: '/record/serving-robot-one-per-narrow-restaurant' }, { t: '小さな店に2台を入れた記録', h: '/record/small-store-second-robot-wait' }],
        hakobu: '同僚が増えたら、店員さんを呼ぶ仕事が増えました。',
      },
      {
        n: '03', id: 'bussing', img: 'robot_stops_03_bussing_wait.jpg', cap: '下げ膳のロボットが卓の横で皿を待つ。うしろのお客さんは通路を抜けられない（シミュレーション）', metric: { l: '卓が使えるまで', v: '4.49 → 8.06', u: '分', n: '下げ膳も任せた2台' }, name: '下げ膳中、通路をふさぐ', where: '飲食店／シミュレーション',
        what: '6店・1〜2台・各10回の比較では、下げ膳も任せると、スタッフの歩く距離は12条件すべてで減りました。一方、細い通路の2店では2台のとき、退店から卓が使えるまでが4.05分→6.05分、4.49分→8.06分に延びました。',
        why: ['下げ膳のロボットが卓に着き、スタッフを待つあいだに通路をふさいでいました。別の通路があれば回れますが、一本道では、ほかのロボットも人も待たされます。'],
        cond: '数字は各10回の中央値。各条件1回の比較動画では入店待ちの増減も見られましたが、繰り返し集計とそろわない店があるため、ここでは卓が使えるまでの時間を示しています。',
        ask: ['皿を載せる人が来ないあいだ、どこで待つか。その横を通れるか。', '歩く距離が減っても、次のお客さんを座らせるまでが延びていないか。'],
        src: [{ t: '下げ膳を加えて繰り返し比較した記録', h: '/record/serving-robot-sim-bussing-narrow-aisles' }, { t: '6店の比較動画', h: '/record/serving-robot-bussing-depends-on-aisles' }],
        hakobu: 'お皿待ちのつもりが、通せんぼになってました。',
      },
      {
        n: '04', id: 'cleanup', img: 'robot_stops_04_queue_empty_tables_v2.jpg', cap: '46卓の店の入口に並ぶお客さん。右の席は空いているが、片付けが済んでいない（シミュレーション）', metric: { l: '席が空いているのに待った', v: '3.4', u: '分', n: 'ロボット2台でも残った' }, name: '席は空いているのに案内できない', where: '46卓・38卓の飲食店／試算とシミュレーションの比較',
        what: '46卓の店では、0台・1台・2台と増やすと、入店待ちは8.1分→6.6分→5.5分に縮みました。それでも2台のとき、「席は空いているのに待った時間」が46卓の店で3.4分、38卓の店で3.5分残りました。',
        why: ['試算ではレジが詰まっていましたが、3Dの店では、スタッフが歩き回ることで片付けと案内が後回しになる、とログでは見ています。ここで止まっているのは、次のお客さんを迎える仕事です。'],
        cond: '各10回の中央値。片付けと案内が原因という説明はログの見立てで、当時の再現には瞬間移動などの簡略化も残っていました。',
        ask: ['運ぶ仕事が減った時間を、誰が片付けと案内に使えるか。', '満席で待つ時間と、席を使える状態にできず待つ時間を分けているか。'],
        src: [{ t: '46卓の店で詰まる仕事を調べた記録', h: '/record/large-store-cleanup-bottleneck' }, { t: '38卓の店と待機場所を調べた記録', h: '/record/standby-jam-every-store' }],
        hakobu: '運び終わりました。次のお客さんの席は、まだでした。',
      },
    ],
  },
  {
    id: 'aisles', kind: 'svc', title: '通路と待機場所で、抜けられない', items: [
      {
        n: '05', id: 'faceoff', img: 'LOG370_02_robots_face_to_face.png', cap: '細い通路の入口で、向かい合ったまま止まった2台（シミュレーション）', metric: { l: '2台が止まり続けた', v: '約9分10', u: '秒', n: 'シミュレーションの1例' }, name: 'にらみ合い', where: '飲食店／実店舗の動画観察とシミュレーション',
        what: '実店舗の動画では、待機場所の横で向かい合った2台が53秒以上進めず、店員が空の方を手でよけて約4〜5秒で解いていました。シミュレーションの42卓・通路95cmの店では、2台が約9分10秒止まった例がありました。',
        why: ['シミュレーションでは、両方が料理を載せている場合などに、どちらが譲るかを決められず、よけた先も相手の道の上でした。実店舗の機体内部の判断は未確認で、ログで調べたメーカーの公開資料でも、どちらが譲るかの具体的な決まりは確認できませんでした。', '店員が助ける決まりをシミュレーションに入れると、約9分の例は助け2回・約105秒で解けましたが、同じ台に何度も助けが必要になる問題が残りました。'],
        cond: '実店舗の観察は同じメーカーの少数例。約9分と約105秒は、シミュレーションの特定条件1回ずつの結果です。',
        ask: ['荷物を載せた2台が出会ったら、どちらが、どこまで下がるか。何秒待つか。導入元に実演してもらえるか。', '自力で解けないとき、人が安全に解く手順を実際に試せるか。'],
        src: [{ t: '実店舗の場面と店員が助ける決まりの比較', h: '/record/serving-robot-faceoff-staff-resolves' }, { t: '待機場所の横で向かい合った動画の観察', h: '/record/serving-robot-jams-are-aisles' }, { t: '向かい合って止まった2台の画面（線に縛った作り）', h: '/record/serving-robot-fixed-route-jam' }],
        hakobu: 'お先にどうぞ。……その先に、ぼくがいます。',
      },
      {
        n: '06', id: 'standby', img: 'LOG456_02_standby_jam_frames.png', cap: '待機点へ斜めに戻ろうとして、隣の台の前で止まる（上から見た4コマ）', metric: { l: '入店待ち', v: '11.7 → 17.2', u: '分', n: '2台 → 5台' }, name: '待機場所へ戻れない', where: '70卓・312席の飲食店／シミュレーション',
        what: '入店待ちは2台で11.7分、5台で17.2分でした。別の比較で、待機点へまっすぐ入る決まりにすると、待機場所付近の止まり合いは1営業あたり3,317秒→1,255秒に減りましたが、入店待ちは12.22分→14.90分に延びました。',
        why: ['0.8m間隔の待機点へ斜めに戻ると、隣で待つ台が前のセンサーに入り、止まっていました。人も待機点の区画を通らない形にすると、止まり合いは809秒まで減りました。'],
        cond: '各10回の中央値。台どうしの順番決めが不足した再現での結果です。待機場所の詰まりが減っても、同じ比較で入店待ちは短くなりませんでした。',
        ask: ['ほかの台が待機しているところへ最後の1台が戻り、また出発できるか。人の通り道と重ならないか。', '待機場所の停止時間を減らしたあと、片付けや入店待ちまで改善したか。'],
        src: [{ t: '5台で待ちが延びた記録', h: '/record/large-restaurant-five-serving-robots-longer-wait' }, { t: '斜めに戻る入り方を調べた記録', h: '/record/serving-robots-jam-cause-standby-entry' }, { t: '人の通り道も変えた記録', h: '/record/serving-robot-jam-three-rules' }],
        hakobu: '駐車位置は空いてます。入る途中が空いてません。',
      },
      {
        n: '07', id: 'dead-end', img: 'LOG374_01_deadend_jam.png', cap: 'ドリンクバーと6人席の間の行き止まりで、向かい合う2台', metric: { l: '60秒以上の停止', v: '57 → 59', u: '回', n: '地図で道を引いても減らない' }, name: 'ドリンクバーの横で詰まる', where: '飲食店／シミュレーション',
        what: '決まった線だけを走る作りから、地図で道を引く作りに変えても、60秒以上の停止は57回→59回で減りませんでした。さらにドリンクバーを上へ0.5m、左へ0.8m動かして抜け道を作ると、20回になりました。',
        why: ['最初は、同じ線を往復するシミュレーション側の制約がありました。それを外しても、ドリンクバーと席の間が0.4mしかない行き止まりに詰まりが集中しました。道を探せるようにする変更に加えて、抜け道を作る配置の変更が必要でした。'],
        cond: '同じ店・2台・同じ乱数条件で各1回の比較。57回→20回は、道の引き方と配置の両方を変えた結果です。',
        ask: ['行き止まりで往復の流れが出会わないか。家具を動かして抜け道を作れるか。', 'シミュレーションで詰まった原因は、現場の配置か、再現する側が加えた制約か。'],
        src: [{ t: '決まった線しか走れなかった作り', h: '/record/serving-robot-fixed-route-jam' }, { t: '道の引き方とドリンクバー移動を分けた比較', h: '/record/serving-robot-map-planner' }],
        hakobu: '地図は読めます。壁の向こうには回れません。',
      },
    ],
  },
  {
    id: 'numbers', kind: 'arm', title: '命令や学習の数字が良くても、仕事は終わらない', items: [
      {
        n: '08', id: 'false-success', img: 'LOG352_03_freeze_after_place.jpg', cap: '箱に置いたあと、その姿勢のまま動かなくなったアーム', metric: { l: '深く倒した姿勢への命令', v: '6回中0', u: '回動いた', n: 'エラーは出なかった' }, name: '動かないのに、記録は成功', where: 'ロボットアーム／実機 mechArm 270',
        what: '動かなかった記録2本が、台帳では「つかめた・箱に入った」と判定されていました。実機では、肩95.53〜99.22°の姿勢への命令がエラーなしに6回とも動かず、肩を87.27°にして教え直すと5回続けて成功しました。',
        why: ['公式の肩の範囲は−85°〜＋90°ですが、送る側のライブラリはそれより広い範囲を許していました。手で教えると範囲外まで倒せても、その姿勢への命令では動きませんでした。本線にあった肩88°の上限確認も、再生用コードには入っていませんでした。'],
        cond: '上記の角度での実機試行。88°は本線の設定値で、厳密に確かめた拒否境界ではありません。台帳の成功判定も実際の動きと食い違っていました。',
        ask: ['教示・再生・本番で、同じ可動範囲の確認が働くか。', '試験導入の報告にある「成功」は、誰が、何を見て付けたか。1回ずつ動画と照らせるか。'],
        src: [{ t: '動かなかった角度・教え直し・台帳の誤判定の記録', h: '/record/teach-replay-19-demos' }],
        hakobu: 'ぼくが動くより先に、台帳で成功してました。',
      },
      {
        n: '09', id: 'power', img: 'LOG487_04_mecharm_label.jpg|LOG487_05_old_adapter_label.jpg', cap: '左：本体のラベル（40W）　右：8か月つないでいた電源（24W）', metric: { l: 'つかんで運べた', v: '1/3 → 5/5', u: '回', n: '電源を 12V・2A → 5A に' }, name: 'つかんだのに落とす', where: 'ロボットアーム／実機 mechArm 270',
        what: 'ブロックを落としていた実機で、8か月分の記録は、本体表示40Wに対して24Wの電源を使って取られていました。3,355円の電源へ替えると、同じモデル・爪の設定・位置で成功は3回中1回から5回中5回になりましたが、交換後も1回は人が持ち上げを補助しました。',
        why: ['使っていた電源は12V・2Aで、交換後は12V・5Aです。落とす前に爪の電流が0付近まで下がる記録と、交換後の変化から、ログでは電源不足が原因と判断しています。8か月使った電源は、箱に入っておらず、あとから別送されたものでした。'],
        cond: '別の日の3回と5回の比較。電圧低下の直接測定はなく、交換後も補助した1回で爪の電流低下が残りました。',
        ask: ['試験機材の電源と部品は機体の指定に合い、本番と同じ構成か。型番まで照らしたか。', 'つかんで静止するだけでなく、持ち上げて運ぶ間も保持できるか。人が補助した回を分けているか。'],
        src: [{ t: '落とす直前の電流と電源を調べた記録', h: '/record/mecharm-270-drops-block-underpowered-adapter' }, { t: '電源交換後の実機比較', h: '/record/mecharm-270-5a-adapter-stops-dropping-block' }],
        hakobu: '学習のおかわりより先に、電源を見てください。',
      },
      {
        n: '10', id: 'loss', img: 'LOG348_02_gripper_beyond_block.jpg', cap: '学習を増やしたあとも、爪はブロックの奥で閉じた', metric: { l: '学習誤差', v: '0.0057 → 0.0030', u: '', n: '実機では2回ともつかめず' }, name: '学習の数字は良いのに空振り', where: 'ロボットアーム／π0.5を使った実機 mechArm 270',
        what: '2,000ステップ学習した実機は4回ともつかむ前に止まり、動画では爪がブロックの上に乗っていました。学習を約4,000ステップに増やし、学習誤差が約0.0057から0.0030に下がっても、実機2回ともブロックの奥で爪を閉じました。',
        why: ['お手本19本は、ブロックをほぼ同じ場所に置いて集めていました。ログでは「いつもの場所へ手を伸ばす」だけでも学習誤差が下がると考え、位置の違うお手本が必要と判断しました。'],
        cond: '実機は追加学習前4回、追加後2回。その後、5か所で19本のお手本を集め直して学習し直しています（続きは出典の記録から）。',
        ask: ['学習に使っていない位置へ対象物を置いても、つかむ場所が変わるか。', '学習誤差とは別に、つかめた回数、箱まで運べた回数、人が補助した回数を数えているか。'],
        src: [{ t: '最初の実機試行で爪が乗った記録', h: '/record/pi05-mecharm-first-real-run' }, { t: '追加学習しても奥で空振りした記録', h: '/record/pi05-mecharm-4000-steps' }],
        hakobu: 'いつもの場所は覚えました。今日のブロックは、そこですか？',
      },
    ],
  },
  {
    id: 'detect', kind: 'svc', title: '止まりを見つける仕組みも、確かめる', items: [
      {
        n: '11', id: 'detector', img: 'LOG418_05_path_line_examples.png', cap: '同じ通路を走るロボット。上は道の線あり、下は線なし', metric: { l: '長い止まりを拾えた割合', v: '72 → 28', u: '%', n: '画面の道の線を消すと' }, name: '見張りが見ていたのは、画面の線', where: '飲食店／シミュレーションの録画を使った画像検知試験',
        what: '静止画1枚ずつで30秒以上の停止を見つける試験では、誤報5%の条件で、経路線ありは93件中67件（72%）、線なしは94件中26件（28%）を拾いました。線なしでは、ロボットどうしの詰まりを47件中4件しか拾えませんでした。',
        why: ['画像検知は、画面に描かれた道の線が交わる所を手がかりにしていました。その線がない画像では、向かい合う2台と、普段どおり並んで待つ2台を区別しにくくなりました。'],
        cond: 'シミュレーション録画で試した一つの検知方法。撮り直しで動きも変わっており、同一場面から線だけを消した比較ではありません。',
        ask: ['止まりを映像で見張る仕組みを提案されたら、評価に使った映像は、自分の現場のカメラと同じ見え方か。', '止まった時刻と長さを、機体の記録から取り出せるか。導入元に、その記録を見せてもらえるか。'],
        src: [{ t: '経路線を消して検知率を測り直した記録', h: '/record/serving-robot-jam-detection-without-path-lines' }],
        hakobu: 'ぼくの困り顔より、道の線を見てたんですね。',
      },
      {
        n: '12', id: 'placeholder-people', img: 'LOG488_04_east_10am.png', cap: '仮の病院の10時ごろ。待合と大廊下に患者・職員・ロボットが行き交う', metric: { l: '1日の問題', v: '84 → 132', u: '件', n: '通れない所を直すと' }, name: '仮の人の動きで、問題が増える', where: '病院の搬送ロボット／シミュレーションで作った仮の病院',
        what: '行き先へ歩いて行けなかった患者・職員41人を通れるようにすると、急停止・ひやり・人によけさせた等の問題が1日84件→132件に増えました。職員の行き先と動き方を直すと132件→68件→19件となり、さらに患者などの動きを補うと51件になりました。',
        why: ['職員141人を「1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動かしていました。付き添いのために通れるようにした場所へ、職員が普段も行くようになり、ロボットと出会う回数が増えていました。'],
        cond: '主に同じ乱数条件1通りでの比較。件数は衝突事故の数ではなく、19件は患者などの動きを補う前の値です。',
        ask: ['導入元のシミュレーションでは、職員と患者の動きを何に基づいて置いたか。仮置きの動きを示してもらえるか。', '問題が減ったとき、必要な人の移動まで減らしていないか。人と荷物が目的地へ着いているか。'],
        src: [{ t: '外来の廊下を避ける経路の比較', h: '/record/hospital-transport-robot-avoid-outpatient-hall' }, { t: '通れる場所を直して問題が増えた記録', h: '/record/hospital-transport-robot-blocked-paths-more-conflicts' }, { t: '職員の仮の動きと測り直し', h: '/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves' }],
        hakobu: '毎時間くじ引きで出張する病院だとは聞いてません。',
      },
    ],
  },
];

const all = chapters.flatMap((c) => c.items);
// 読む人で分ける：サービスロボット（配膳・搬送）とロボットアーム。タブで切り替える（JS が動かないときは全部見える）
const TABS = [{ k: 'svc', t: 'サービスロボット' }, { k: 'arm', t: 'ロボットアーム' }] as const;
const kindOf = Object.fromEntries(chapters.flatMap((c) => c.items.map((i) => [i.id, c.kind])));

const jsonLd = [
  {
    '@context': 'https://schema.org', '@type': 'Article', headline: title, description, url, mainEntityOfPage: url,
    inLanguage: 'ja', datePublished: published, dateModified: modified, author: AUTHOR, publisher: PUBLISHER,
    about: [{ '@type': 'Thing', name: '配膳ロボット' }, { '@type': 'Thing', name: '搬送ロボット' }, { '@type': 'Thing', name: 'ロボット導入' }, { '@type': 'Thing', name: 'フィジカルAI' }],
    citation: [...new Set(all.flatMap((i) => i.src.map((s) => SITE + s.h)))],
  },
  {
    '@context': 'https://schema.org', '@type': 'BreadcrumbList',
    itemListElement: [
      { '@type': 'ListItem', position: 1, name: 'Pixels to Motors', item: SITE + '/' },
      { '@type': 'ListItem', position: 2, name: 'ロボットが現場で止まる瞬間の図鑑', item: url },
    ],
  },
];
---
<Base title={`${seoTitle} | Pixels to Motors`} description={description} path={path} ogType="article" published={published} modified={modified} jsonLd={jsonLd}>
  <div class="rs">

<section class="fv" aria-labelledby="fv-h">
  <div class="fv-copy">
    <p class="who">ロボットの導入を決める方と、任された方へ</p>
    <h1 id="fv-h">ロボットが<br>現場で止まる<br>瞬間の図鑑</h1>
    <p class="lead">配膳ロボット・病院の搬送ロボット・ロボットアームが止まった12の場面を、実店舗の動画・シミュレーション・実機の記録から集めました。</p>
    <dl class="fv-stat">
      <div><dt>止まった配膳ロボットを直す作業</dt><dd><span class="u">約</span>1〜10<span class="u">秒</span></dd></div>
      <div class="big"><dt>店員が来るまで</dt><dd><span class="u">約</span>18〜53<span class="u">秒以上</span></dd></div>
    </dl>
    <p class="fv-note">実店舗の動画で、店員が対応した4例</p>
  </div>
  <figure class="fv-media">
    <video src="/media/robot_stops_fv_v1.mp4" poster="/media/robot_stops_fv_v1.jpg" muted loop playsinline autoplay preload="metadata" aria-label="シミュレーションの店で、配膳ロボットが長く止まった場所に寄っていく動画"></video>
    <figcaption>シミュレーションの店で、ロボットが長く止まった所へ寄る（黄＝お客さん・青＝スタッフ・白＝ロボット）</figcaption>
  </figure>
</section>

<div class="tabbar" id="tabs">
  <div class="wrap">
    <div class="tabs" role="tablist" aria-label="ロボットの種類">
      {TABS.map((t, ti) => <button type="button" role="tab" data-tab={t.k} aria-selected={ti === 0 ? 'true' : 'false'} data-ev={`タブ:${t.t}`}>{t.t}</button>)}
    </div>
  </div>
</div>

<section class="idx-sec" aria-labelledby="idx-h">
  <div class="wrap">
    <h2 id="idx-h" class="sr">12の止まる瞬間</h2>
    <ul class="idx">
      {all.map((i) => (
        <li data-kind={kindOf[i.id]}><a class="icard" href={`#${i.id}`} data-ev={`目次:${i.name}`}>
          <span class="ithumb"><img src={`/media/${i.img.split('|')[0]}`} alt="" loading="lazy"></span>
          <span class="imeta">
            <span class="iline"><span class="iv">{i.metric.v}<small>{i.metric.u}</small></span><span class="tag">{i.metric.l}</span></span>
            <span class="ititle">{i.name}</span>
          </span>
        </a></li>
      ))}
    </ul>
  </div>
</section>

{chapters.map((c) => (
  <section id={c.id} data-kind={c.kind}>
    <div class="wrap">
      <h2 class="ch">{c.title}</h2>
      {c.items.map((i, k) => (
        <article class={`card${k % 2 ? ' rev' : ''}`} id={i.id}>
          <figure class={`shot${i.img.includes('|') ? ' pair' : ''}`}>
            <div class="shot-imgs">{i.img.split('|').map((f) => <img src={`/media/${f}`} alt={i.cap} loading="lazy">)}</div>
            <figcaption>{i.cap}</figcaption>
          </figure>
          <div class="side">
            <p class="where"><span class="tag">{i.where}</span></p>
            <h3>{i.name}</h3>
            <p class="metric"><span class="m-l">{i.metric.l}</span><span class="m-v">{i.metric.v}<span class="u">{i.metric.u}</span></span><span class="m-n">{i.metric.n}</span></p>
            <div class="ask">
              <h4>入れる前に確かめること</h4>
              <ul>{i.ask.map((a) => <li>{a}</li>)}</ul>
            </div>
            <figure class="hk">
              <img src="/site/hakobu/avatar.webp" alt="ハコブくん" width="160" height="160" loading="lazy">
              <blockquote>{i.hakobu}</blockquote>
            </figure>
          </div>
          <details class="more">
            <summary>何が起きたか・なぜ止まったか・出典</summary>
            <div class="more-in">
              <div>
                <h4>何が起きたか</h4>
                <p>{i.what}</p>
                <h4>なぜ止まったか</h4>
                {i.why.map((w) => <p>{w}</p>)}
              </div>
              <div>
                <h4>測った条件</h4>
                <p class="cond">{i.cond}</p>
                <h4>出典</h4>
                <p class="src">{i.src.map((x) => <a href={x.h}>{x.t}</a>)}</p>
              </div>
            </div>
          </details>
        </article>
      ))}
    </div>
  </section>
))}

<section class="end band-ink" id="next">
  <div class="wrap">
    <h2>自分の現場で、一つ確かめる</h2>
    <div class="prose">
      <p>足す判断の前に、どこで仕事が止まり、誰の手が必要になっているかを確かめてください。もう一つ確かめたいのが、<strong>報告にある「成功」と、実際に終わった仕事が一致しているか</strong>です。台帳の成功、学習誤差、画像の検知率だけでは、拾えていない止まりがありました。</p>
      <p>気になった場面を一つ選び、試験導入で次の欄を埋めてください。</p>
    </div>
    <div class="table"><table>
      <tbody>
        <tr><th>起きた条件</th><td>場所、混み具合、台数、荷物、人の作業</td></tr>
        <tr><th>待った時間</th><td>停止、気づき、人の到着、復帰の各時刻</td></tr>
        <tr><th>人がしたこと</th><td>画面操作、移動、積み下ろし、持ち上げなど</td></tr>
        <tr><th>仕事の結果</th><td>届いたか、卓が使えたか、次の人を案内できたか。記録と動画は一致するか</td></tr>
        <tr><th>変えて比べること</th><td>台数、配置、通行ルール、待ち方などを一つずつ</td></tr>
      </tbody>
    </table></div>
    <div class="prose">
      <p>人が手を貸して完了した回は、その手間も含めて導入の結果です。店の形・人数・台数を変えて考えるには、<a href="/series8">配膳ロボットの導入シミュレーション</a>へ。</p>
    </div>
    <a class="cta" href="/message?topic=physical-ai" data-ev="図鑑:相談"><span><small>自分の現場で確かめたい止まり方を</small>メッセージで送る</span><i class="ms" aria-hidden="true">arrow_forward</i></a>
  </div>
</section>

  </div>
  <script is:inline>
    (function () {
      var root = document.querySelector('.rs'); if (!root) return;
      var btns = root.querySelectorAll('.tabs [data-tab]');
      function set(k) {
        root.setAttribute('data-tab', k);
        btns.forEach(function (b) { b.setAttribute('aria-selected', b.getAttribute('data-tab') === k ? 'true' : 'false'); });
      }
      btns.forEach(function (b) { b.addEventListener('click', function () { set(b.getAttribute('data-tab')); var t = document.getElementById('tabs'); if (t && t.getBoundingClientRect().top <= 49) window.scrollTo({ top: t.offsetTop - 48 }); }); });
      function fromHash() {
        var id = decodeURIComponent(location.hash.slice(1)); if (!id) return false;
        var el = document.getElementById(id); var sec = el && el.closest('[data-kind]');
        if (sec) { set(sec.getAttribute('data-kind')); el.scrollIntoView(); return true; }
        return false;
      }
      if (!fromHash()) set('svc');
      window.addEventListener('hashchange', fromHash);
    })();
  </script>
</Base>

<style is:global>
.rs{
  --paper:#f7f7f7; --sheet:#fff; --ink:#242424; --muted:#555; --rule:#e6e6e6;
  --robot:#f2600c; /* 差し色：最後のメッセージのボタンだけ（ほかの LP の最後のボタンとそろえる） */
  --gut:max(16px,env(safe-area-inset-left,0px));
  --sans:Inter,"Noto Sans JP","Hiragino Sans",system-ui,sans-serif;
  --r-s:6px;
}
.rs, .rs *{box-sizing:border-box}
.rs{padding-top:48px;background:var(--paper);color:var(--ink);font-family:var(--sans);font-size:17px;line-height:1.8;letter-spacing:.02em;-webkit-font-smoothing:antialiased}
.rs a{color:var(--ink);text-decoration:underline;text-decoration-thickness:1px;text-underline-offset:3px}
.rs a:hover{text-decoration-thickness:2px}
.rs .wrap{max-width:calc(1120px + 2*var(--gut));margin:0 auto;padding-inline:var(--gut)}
.rs h1,.rs h2,.rs h3{text-wrap:balance;letter-spacing:0;margin:0}
.rs p{margin:0 0 .9em}
.rs .sr{position:absolute;width:1px;height:1px;overflow:hidden;clip:rect(0 0 0 0)}
.rs section{padding-block:88px}
.rs .band-white{background:#fff}
.rs .u{font-family:var(--sans);font-size:.42em;font-weight:700;margin:0 .12em;letter-spacing:0}

/* ---- 最初の画面：左に見出しと「直す時間と来るまでの時間」、右に止まる場面の動画（膜をかけない） ---- */
.rs .fv{display:grid;grid-template-columns:minmax(360px,34rem) minmax(0,1fr);background:var(--ink);color:#fff;padding:0;min-height:max(600px,calc(100svh - 48px))}
.rs .fv-copy{padding:64px 48px 48px max(var(--gut),calc((100vw - 1120px)/2));display:flex;flex-direction:column;justify-content:center}
.rs .who{font-size:.85rem;font-weight:700;color:#bbb;margin-bottom:18px}
.rs .fv h1{font-size:clamp(2.2rem,3.6vw,3.1rem);line-height:1.15;font-weight:900}
.rs .lead{margin-top:24px;color:#ccc;font-size:1rem;line-height:1.9}
.rs .fv-stat{margin:20px 0 0;display:grid;gap:10px;border-top:2px solid #fff;padding-top:18px}
.rs .fv-stat dt{font-size:.85rem;color:#bbb}
.rs .fv-stat dd{margin:0;font-weight:800;font-size:2rem;line-height:1.1;color:#aaa}
.rs .fv-stat .big dd{font-size:clamp(2.6rem,4vw,3.4rem);color:#fff;white-space:nowrap}
.rs .fv-note{font-size:.78rem;color:#999;margin-top:12px}
.rs .fv-media{margin:0;position:relative;background:#1b1b1b;overflow:hidden;display:flex;align-items:center;padding:48px 48px 64px}
.rs .fv-media video{display:block;width:100%;height:auto;max-height:100%;border-radius:var(--r-s)}
.rs .fv-media figcaption{position:absolute;left:48px;bottom:22px;color:#aaa;font-size:.78rem}

/* ---- タブ：上が角丸の見出しが、下の太い線につながる形（選んでいる方は面ごと黒）。下へ読み進めても上に残る ---- */
.rs .tabbar{position:sticky;top:48px;z-index:5;background:var(--paper)}
.rs .tabs{display:flex;gap:6px;align-items:flex-end;border-bottom:3px solid var(--ink);padding-top:14px}
.rs .tabs button{font:inherit;font-size:1.05rem;font-weight:900;cursor:pointer;border:0;background:#ececec;color:var(--muted);border-radius:var(--r-s) var(--r-s) 0 0;padding:12px 28px;transition:background .15s,color .15s}
.rs .tabs button:hover{background:#ddd;color:var(--ink)}
.rs .tabs button[aria-selected="true"]{background:var(--ink);color:#fff;padding-block:16px 12px}
.rs[data-tab="svc"] [data-kind="arm"], .rs[data-tab="arm"] [data-kind="svc"]{display:none}

/* ---- 12の場面の目次：サイトの記録カード（RecordCard）と同じ決まり ---- */
.rs .idx-sec{padding-block:32px 72px}
.rs .idx{list-style:none;margin:0;padding:0;display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:24px}
.rs .icard{display:block;background:#fff;border-radius:8px;box-shadow:0 8px 16px rgba(0,0,0,.08);overflow:hidden;text-decoration:none!important;color:var(--ink)}
.rs .ithumb{display:block;aspect-ratio:16/9;background:#fff;overflow:hidden}
.rs .ithumb img{display:block;width:100%;height:100%;object-fit:cover;transition:transform .3s}
.rs .icard:hover .ithumb img{transform:scale(1.03)}
.rs .imeta{display:flex;flex-direction:column;gap:8px;padding:16px}
.rs .iline{display:flex;align-items:center;gap:12px;flex-wrap:wrap}
.rs .iv{font:400 18px/18px Inter,sans-serif}
.rs .iv small{font-size:11px;margin-left:2px}
.rs .ititle{font:600 16px/1.6 var(--sans);letter-spacing:0}

/* ---- 章と1場面：写真が主役、横に数字1つと確かめること。説明は開いたときだけ ---- */
.rs .ch{font-size:clamp(1.6rem,3vw,2.2rem);line-height:1.35;font-weight:900;margin-bottom:36px}
/* 影は「押せる」の印（サイトの記録カードと同じ）。場面のカードは押す物ではないので影を付けない */
.rs .card{display:grid;grid-template-columns:minmax(0,1.25fr) minmax(0,1fr);gap:0;background:var(--sheet);border-radius:8px;overflow:hidden;margin-bottom:32px;scroll-margin-top:64px}
.rs .card.rev .shot{grid-column:2;grid-row:1}
.rs .card.rev .side{grid-column:1;grid-row:1}
.rs .shot{margin:0;background:#1b1b1b;display:flex;flex-direction:column}
.rs .shot-imgs{flex:1;display:flex;min-height:340px}
.rs .shot-imgs img{display:block;width:100%;height:100%;object-fit:cover;flex:1;min-width:0}
.rs .shot.pair .shot-imgs{gap:2px}
.rs .shot figcaption{color:#ccc;font-size:.78rem;line-height:1.6;padding:10px 16px}
.rs .side{padding:32px 34px}
.rs .where{margin:0 0 12px}
.rs .card h3{font-size:1.7rem;line-height:1.3;font-weight:900}
.rs .metric{display:grid;margin:18px 0 20px}
.rs .m-l{font-size:.82rem;font-weight:700;color:var(--muted)}
.rs .m-v{font-family:Inter,sans-serif;font-weight:800;font-size:2.6rem;line-height:1.15;letter-spacing:-.01em}
.rs .m-n{font-size:.82rem;color:var(--muted)}
.rs .card h4{font-size:.82rem;font-weight:800;margin:0 0 6px;color:var(--muted)}
.rs .ask{background:var(--ink);color:#fff;border-radius:var(--r-s);padding:18px 20px}
.rs .ask h4{color:#bbb}
.rs .ask ul{margin:0;padding-left:1.1em;display:grid;gap:8px}
.rs .ask li{font-size:.95rem;font-weight:700;line-height:1.6}
.rs .hk{display:flex;gap:12px;align-items:center;margin:18px 0 0}
.rs .hk img{width:52px;height:52px;border-radius:50%;flex:none}
.rs .hk blockquote{margin:0;background:#fff;border:1.5px solid var(--ink);border-radius:14px;padding:9px 14px;font-size:.9rem;font-weight:700;line-height:1.6}
.rs .more{grid-column:1/-1;border-top:1px solid var(--rule)}
.rs .more summary{cursor:pointer;list-style:none;padding:14px 34px;font-size:.88rem;font-weight:800;display:flex;justify-content:space-between;align-items:center}
.rs .more summary::-webkit-details-marker{display:none}
.rs .more summary::after{content:"+";font-size:1.3rem;font-weight:400}
.rs .more[open] summary::after{content:"−"}
.rs .more summary:hover{background:var(--paper)}
.rs .more-in{display:grid;grid-template-columns:minmax(0,1.25fr) minmax(0,1fr);gap:32px;padding:4px 34px 28px}
.rs .more-in p{font-size:.95rem}
.rs .cond{color:var(--muted);font-size:.85rem!important}
.rs .src a{display:block;font-size:.85rem}

/* ---- 最後：自分の現場で確かめる（黒の面）とボタン1つ ---- */
.rs .band-ink{background:var(--ink);color:#eee}
.rs .band-ink h2{color:#fff;font-size:clamp(1.7rem,3.2vw,2.4rem);font-weight:900;margin-bottom:28px}
.rs .band-ink a{color:#fff}
.rs .prose{max-width:40em}
.rs .prose p{color:#ccc;font-size:1rem;line-height:1.9}
.rs .prose strong{color:#fff}
.rs .table{overflow-x:auto;margin:8px 0 28px;max-width:40em}
.rs .table table{border-collapse:collapse;width:100%;font-size:.92rem}
.rs .table th,.rs .table td{border-bottom:1px solid #444;padding:10px 12px;text-align:left;vertical-align:top}
.rs .table th{white-space:nowrap;font-weight:800;color:#fff}
.rs .cta{display:flex;justify-content:space-between;align-items:center;gap:16px;max-width:40em;margin-top:20px;text-decoration:none!important;background:var(--robot);color:#fff!important;padding:24px 26px;font-weight:900;font-size:1.15rem;line-height:1.35;border-radius:var(--r-s);transition:background .15s}
.rs .cta small{display:block;font-size:.72rem;font-weight:700;letter-spacing:.06em;margin-bottom:4px}
.rs .cta .ms{font-size:28px;transition:transform .2s}
.rs .cta:hover{background:#000}
.rs .cta:hover .ms{transform:translateX(3px)}

@media (max-width:900px){
  .rs section{padding-block:60px}
  .rs .fv{grid-template-columns:1fr;min-height:0}
  .rs .fv-copy{padding:48px var(--gut) 36px}
  .rs .fv-media{padding:16px var(--gut) 44px}
  .rs .fv-media figcaption{left:var(--gut);bottom:14px}
  .rs .idx{grid-template-columns:repeat(2,minmax(0,1fr));gap:16px}
  .rs .card{grid-template-columns:1fr}
  .rs .card.rev .shot,.rs .card.rev .side{grid-column:auto;grid-row:auto}
  .rs .shot-imgs{min-height:0;aspect-ratio:4/3}
  .rs .side{padding:24px 20px}
  .rs .more summary{padding:14px 20px}
  .rs .more-in{grid-template-columns:1fr;gap:8px;padding:4px 20px 24px}
  .rs .card h3{font-size:1.45rem}
  .rs .m-v{font-size:2.2rem}
}
</style>
```


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

```astro
---
// 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本）のまま
// 題名と説明は「|」で文節に区切り、区切りの間でだけ折り返す（.ph）。word-break: auto-phrase は iPhone の Safari が無視し、
// 「買/うか」「損益分/岐」「自/分」のように語の途中で切れたため（2026-10-24）
const cards = [
  {
    href: '/gpu-buy-or-rent', bg: '/site/gbr/reverse.webp', light: false, label: '導入比較ガイド',
    fig: { old: '¥750,000', big: '¥4,700', small: '' },
    title: 'ロボットAIの|学習用GPU、|買うか借りるか',
    sub: '実際に|借りて|学習させた|費用と、|損益分岐の|計算機、|判定フローで|決められます。',
    ev: 'TOPガイド:GPU',
  },
  {
    href: '/serving-robot-one-less-staff', img: '/site/srl/cta-iso.svg', light: true, label: '導入前シミュレーション',
    title: '配膳ロボットを、|導入前に|自分の店舗で|シミュレーション',
    sub: '店舗の|図面と|人数から、|何人で回るか・|どこで止まるか・|月いくらかかるかを|出します。',
    ev: 'TOPガイド:配膳ロボット',
  },
  {
    href: '/robot-stops', photo: ['/media/robot_stops_02_second_robot_v2.jpg', '/media/robot_stops_arm_gripper.jpg'], light: true, wide: true, label: '導入前の確認',
    alt: ['店を真上から見たシミュレーションの画面。2台の配膳ロボットが一本道で向かい合って止まっている', '実機のロボットアームの爪が、赤いブロックの奥で閉じている'],
    title: 'ロボットが|現場で止まる|瞬間の図鑑',
    sub: '配膳・病院の搬送・|ロボットアームが|止まった12の場面と、|入れる前に|確かめることを|まとめました。',
    ev: 'TOPガイド:図鑑',
  },
];
const ph = (t: string) => t.split('|');
---
<div class="gcards">
  {cards.map((c) => (
    <a class={`gcard${c.light ? ' light' : ''}${c.wide ? ' wide' : ''}${c.photo ? ' photo' : ''}`} href={c.href} data-ev={c.ev} style={c.bg ? `--bg:url(${c.bg})` : undefined}>
      {c.photo && <span class="gc-img">{c.photo.map((src, k) => <span class="gc-ph"><img style={k === 0 ? "object-position:30% 55%" : "object-position:35% 50%"} src={src} alt={c.alt[k]} loading="lazy" /></span>)}</span>}
      {c.img && <span class="gc-img"><img src={c.img} alt="店の立体図（席・キッチン・配膳ロボットの通り道）" width="1400" height="900" loading="lazy" /></span>}
      <span class="gc-body">
        <span class="gc-label">{c.label}</span>
        {c.fig && <span class="gc-fig" aria-hidden="true">
          {c.fig.old && <s class="gc-old">{c.fig.old}</s>}
          <b class="gc-big">{c.fig.big}</b>
          {c.fig.small && <small class="gc-small">{c.fig.small}</small>}
        </span>}
        <span class="gc-title">{ph(c.title).map((p) => <span class="ph">{p}</span>)}</span>
        <span class="gc-sub">{ph(c.sub).map((p) => <span class="ph">{p}</span>)}</span>
        <span class="gc-go">読む<i class="ms">arrow_forward</i></span>
      </span>
    </a>
  ))}
</div>
<style>
  .gcards { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; }
  /* ほかのセクションのカード（記録・4コマ・シリーズ）と同じ角丸と影 */
  .gcard { position: relative; isolation: isolate; overflow: hidden; display: grid; border-radius: 8px; box-shadow: 0 8px 16px rgba(0,0,0,.08); background: #0b0c0e; color: #fff; text-decoration: none; }
  .gc-body { display: grid; align-content: center; gap: 10px; padding: 32px; }
  .gcard::before { content: ""; position: absolute; inset: 0; z-index: -2; background: var(--bg) right center / cover no-repeat; transition: transform .6s ease; }
  .gcard::after { content: ""; position: absolute; inset: 0; z-index: -1; background: linear-gradient(90deg, rgba(11,12,14,.95) 0%, rgba(11,12,14,.86) 55%, rgba(11,12,14,.55) 100%); }
  .gcard:hover::before { transform: scale(1.03); }
  .gcard:focus-visible { outline: 2px solid #121418; outline-offset: 3px; }
  .gc-label { font: 700 12px/18px var(--sans); color: #b9bec7; letter-spacing: .08em; }
  .gc-fig { display: flex; flex-wrap: wrap; align-items: baseline; gap: 4px 12px; font-family: 'Manrope', 'Noto Sans JP', sans-serif; font-variant-numeric: tabular-nums; line-height: 1.1; }
  .gc-old { font-size: 20px; font-weight: 800; color: #8d939d; text-decoration-thickness: 2px; }
  .gc-big { font-size: 40px; font-weight: 800; color: #f2600c; letter-spacing: -.01em; }
  .gc-small { font: 700 14px/1.5 var(--sans); color: #d6dae3; }
  .gc-title { margin-top: 4px; font: 900 22px/1.45 var(--sans); word-break: auto-phrase; text-wrap: pretty; }
  .gc-sub { font: 400 14px/1.7 var(--sans); color: #c8ccd4; text-wrap: pretty; }
  /* 文節の中では折り返さない。1つの文節が枠より長いときだけ中で折り返す */
  .ph { display: inline-block; max-width: 100%; }
  .gc-go { justify-self: start; display: inline-flex; align-items: center; gap: 6px; height: 44px; margin-top: 6px; padding: 0 20px; border-radius: 4px;
    background: #f2600c; color: #fff; font: 700 14px/1 var(--sans); white-space: nowrap; transition: background .15s, color .15s; }
  .gcard:hover .gc-go { background: #fff; color: #121418; }
  /* 配膳ロボット：明るい面。カードが広いときは文字を左・立体の絵を右に、狭いときは絵を上・文字を下に置く。
     区切りはカードの幅で決める（画面の幅ではない）。2枚並びのカードは画面が 900〜1300px くらいだと 450〜600px しかなく、
     横に並べると文字の列が細くなって題名と説明が細かく折り返すため。
     横に並べるのは、ガイドの枠（.gcards）が 1180px 以上（カード1枚が約580px 以上）のときだけ。文字の列は 300px より狭くしない */
  .gcards { container-type: inline-size; }
  .gcard.light { grid-template-columns: 1fr; background: #eceef1; color: #121418; }
  .gcard.light::before, .gcard.light::after { content: none; }
  .gc-img { grid-column: 1; grid-row: 1; position: relative; display: block; overflow: hidden; height: 220px; background: #eceef1; }
  /* 絵を上・文字を下に置くときは、絵を枠の下端にそろえ、文字との間を詰める（間が空きすぎて見えたため。2026-10-24） */
  .gc-img img { position: absolute; top: 12px; left: 12px; display: block; width: calc(100% - 24px); height: calc(100% - 12px); object-fit: contain; object-position: 50% 100%; transition: transform .6s ease; }
  .gcard.light .gc-body { grid-column: 1; grid-row: 2; padding: 8px 32px 32px; }
  @container (min-width: 1180px) {
    .gcard.light { grid-template-columns: minmax(300px, 1fr) minmax(0, 1fr); }
    .gc-img { grid-column: 2; grid-row: 1; height: auto; }
    .gc-img img { top: 0; left: 0; width: calc(100% - 20px); height: 100%; object-position: 0 50%; }
    .gcard.light .gc-body { grid-column: 1; grid-row: 1; padding: 32px 20px 32px 32px; }
  }
  .gcard.light:hover .gc-img img { transform: scale(1.03); }
  /* 図鑑（3枚目）：2枚の下に横いっぱいで置く。絵ではなくシミュレーションの画面なので、枠いっぱいに敷く（2026-11-15） */
  .gcard.wide { grid-column: 1 / -1; }
  /* サービスロボットとロボットアームの両方を載せるページなので、2枚を左右に並べる（2026-11-15） */
  .gcard.photo .gc-img { display: grid; grid-template-columns: 1fr 1fr; gap: 2px; background: #121418; }
  .gc-ph { position: relative; overflow: hidden; }
  .gcard.photo .gc-img img { top: 0; left: 0; width: 100%; height: 100%; object-fit: cover; object-position: 50% 50%; }
  @container (min-width: 1180px) {
    .gcard.wide { grid-template-columns: minmax(300px, 1fr) minmax(0, 1fr); }
    .gcard.photo .gc-img { min-height: 300px; }
  }
  .gcard.light .gc-title { font-size: 20px; }
  .gcard.light .gc-label { color: #5c616b; }
  .gcard.light .gc-small { color: #121418; }
  .gcard.light .gc-body { word-break: auto-phrase; text-wrap: pretty; }
  .gcard.light .gc-sub { color: #4a4f58; }
  .gcard.light:hover .gc-go { background: #121418; color: #fff; }
  .gc-go .ms { font-size: 18px; transition: transform .2s; }
  .gcard:hover .gc-go .ms { transform: translateX(3px); }
  @media (max-width: 899px) {
    .gcards { grid-template-columns: 1fr; }
    .gcard { min-height: 0; }
    .gc-body { padding: 24px 20px; }
    .gcard.light .gc-body { padding: 8px 20px 24px; }
    .gcard:not(.light)::after { background: rgba(11,12,14,.84); }
    .gc-big { font-size: 32px; }
    .gc-title { font-size: 19px; }
  }
</style>
```


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

```astro
---
// ロボットが現場で止まる瞬間の図鑑（/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>
    <span class="rsb-text">
      <span class="rsb-label">導入前の確認</span>
      <span class="rsb-title">ロボットが現場で止まる瞬間の図鑑</span>
      <span class="rsb-sub">このシリーズの記録から、配膳ロボットが止まった場面を集めたページです。病院の搬送ロボット・ロボットアームを合わせた12の場面と、入れる前に確かめることをまとめました。</span>
      <span class="rsb-go">読む<i class="ms">arrow_forward</i></span>
    </span>
  </a>
</div>
<style>
  .rsb-wrap { container-type: inline-size; }
  .rsb-bn { display: grid; grid-template-columns: 1fr; overflow: hidden; border-radius: 8px; box-shadow: 0 8px 16px rgba(0,0,0,.08); background: #eceef1; color: #121418; text-decoration: none; }
  .rsb-bn:focus-visible { outline: 2px solid #121418; outline-offset: 3px; }
  .rsb-img { position: relative; display: grid; grid-template-columns: 1fr 1fr; gap: 2px; height: 220px; overflow: hidden; background: #121418; }
  .rsb-ph { position: relative; overflow: hidden; }
  .rsb-img img { position: absolute; top: 0; left: 0; display: block; width: 100%; height: 100%; object-fit: cover; object-position: 50% 50%; transition: transform .6s ease; }
  .rsb-bn:hover .rsb-img img { transform: scale(1.03); }
  .rsb-text { display: grid; align-content: center; gap: 10px; padding: 24px 20px 28px; word-break: auto-phrase; text-wrap: pretty; }
  .rsb-label { font: 700 12px/18px var(--sans); color: #5c616b; letter-spacing: .08em; }
  .rsb-title { margin-top: 4px; font: 900 22px/1.45 var(--sans); }
  .rsb-sub { font: 400 14px/1.7 var(--sans); color: #4a4f58; max-width: 40em; }
  .rsb-go { justify-self: start; display: inline-flex; align-items: center; gap: 6px; height: 44px; margin-top: 6px; padding: 0 20px; border-radius: 4px;
    background: #f2600c; color: #fff; font: 700 14px/1 var(--sans); white-space: nowrap; transition: background .15s, color .15s; }
  .rsb-bn:hover .rsb-go { background: #121418; color: #fff; }
  .rsb-go .ms { font-size: 18px; transition: transform .2s; }
  .rsb-bn:hover .rsb-go .ms { transform: translateX(3px); }
  /* 広いときは文字を左・絵を右に。文字の列は 360〜600px、残りの幅に絵を真ん中に置く */
  @container (min-width: 720px) {
    .rsb-bn { grid-template-columns: minmax(360px, 600px) minmax(0, 1fr); }
    .rsb-img { grid-column: 2; grid-row: 1; height: auto; min-height: 260px; }
    .rsb-img img { top: 0; left: 0; width: 100%; height: 100%; object-position: 50% 50%; }
    .rsb-text { grid-column: 1; grid-row: 1; padding: 36px 24px 36px 36px; }
  }
</style>
```


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

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

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

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


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


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

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

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

## 守ること（エイイチが決めたこと。これに反する案は出さない）
- **ログの形式は変えない。** 個々のログ（/record/…）は記事ではなく記録。見出し・書き方・ひな形には手をつけない
- **題材を広げない。** YouTube と違い、サイトでは新しい題材・新しい連載・新しい種類のページを増やさない。入口のページは、下の「ログ一覧」にすでにある中身だけで作る
- トップや SNS に相談の窓口を出さない（相談の窓口は、AI活用の記事とメッセージフォームからの導線に限る）
- 新しいキャッチコピー・肩書き・会社の定義を足さない（トップの見出し「現場で人が受け入れて、使い続けられるロボットを。」はそのまま）
- 数字を盛る・不安をあおる・他社を悪く言う演出をしない
- 研究を止めない。作るのに何日もかかる案より、ログを束ねて短く作れる案を上に置く

## サイトのねらい
- Mission：Physical AI が学習できる環境を作り続け、その知見を再現できる形で公開し、同じ環境から研究を始められる人を増やす
- いちばんの指標は「再現可能な環境の数」（他人が同じ手順で同じ結果に届く研究資産の数）。表示の数やフォロワーは主にしない
- いま見ている3つの数字：AI の利用者の依頼で読みに来た数・AI のサービスのリンクから来た人の数・サイト名で検索して来た人の数
- サイトはもともと検索で人を集める作りにしていない。AI に調べられることで、人の来訪や知名度がいつ増えはじめるかを見ている
- 届けたい相手：ロボット導入を判断する経営者、導入を任された PM、ロボット・AI のソフトを書く開発者（実験が好きな開発者も入る）

## 実際の数字（2026-10-26〜11-14・人の操作があった表示だけ）
- 人の表示は合計367件。週ごとに 164 → 136 → 68（11-09の週は6日分）と減っている
- **トップは40件で約1割。** 人の多くは Google（90件）や直接（153件）から、個々のログに直接来ている。LinkedIn 10件・Yahoo 10件・ChatGPT のリンク4件
- ログからほかのログ・シリーズへ移る動きはわずか（数件ずつ）。1本読んで出ていく
- 主なページの表示（25%/50%/75% まで読んだ割合）
  - / トップ：40件（70%/48%/28%）
  - /gpu-buy-or-rent（GPU は買うか借りるか・LP）：21件（52%/52%/10%）
  - /issues（課題地図）：21件（5%/0%/0%・中央値9秒）
  - /manga-archive：14件
  - /series8（サービスロボット導入シミュレーション）：12件
  - /serving-robot-one-less-staff（配膳ロボットの LP）：3件。ただし中の動画が57回再生され、67%が最後まで読んだ
  - /one-year（1年の記録の LP）：2件
  - よく読まれたログ：DAY18（11件・中央値53秒）、DAY17（7件）、DAY12（6件）、大きな店に配膳ロボット5台（7件）
- AI の利用者の依頼で読みに来た数：週に42〜61件。トップがいちばん多く、残りは個々のログに散る（ChatGPT-User が多く、Claude-User・Perplexity-User もある）
- サイト名で検索して来た人：まだ0
- **注意：** どのページも数が少ない。30件未満の数は「判断できない」として扱い、言い切らない

## 今のサイトの形
- トップ：見出し → 1年の記録 → 課題地図 → 導入前ガイド → 4コマ → いまの考え → シリーズ → 記録 → ロボットに関わる人へ → 事業所について
- シリーズのページ（/series1〜8）：上に資料、下にそのシリーズのログの一覧
- 今ある LP：/serving-robot-one-less-staff（配膳ロボットで人が1人減らせるか）、/gpu-buy-or-rent（GPU は買うか借りるか）、/one-year（1年の記録）
- 課題地図（/issues）：フィジカルAIの社会実装の前に解くべき課題・週1回更新
- ログは全部で約520本。各ログには全文・コード・素材のファイルが付き、「AIで読む」ボタンがある

## Claude の最初の案（叩き台。これに引きずられないこと）
1. 配膳ロボットの導入の試算を1枚にまとめるページ（導入シミュレーションのログを束ね、今ある LP /serving-robot-one-less-staff へ送る）
2. π0.5 を mechArm 270 で動かすまでを1枚にまとめるページ（フィジカルAI研究室のログを束ね、手順・コード・費用へ送る）
3. 家でフィジカルAI研究室を組むときの判断を1枚にまとめるページ（GPU は買うか借りるか の LP の見直しを含む）

## ログ一覧（入口のページは、ここにある中身だけで作る）

### 導入シミュレーション（48本）
- 351｜サービスロボット導入シミュレーション Log#1 | 配膳ロボットで1人減らせるかは、店の形で変わる｜/record/serving-robot-simulation-simpy
- 353｜サービスロボット導入シミュレーション Log#2 | 配膳ロボットが何回止まるかは、公開データが見つからない ― 店で押して数える観察シートを作った｜/record/serving-robot-observation-sheet
- 356｜サービスロボット導入シミュレーション Log#3 | ロボットが人を呼ぶ回数を、5つの現場で試算する｜/record/service-robot-five-sites
- 357｜サービスロボット導入シミュレーション Log#4 | Unity にファミレスを建て、配膳ロボットを走らせた｜/record/unity-family-restaurant-serving-robot
- 359｜サービスロボット導入シミュレーション Log#5 | Unity に合わせる前に、試算のほうを点検した｜/record/audit-simulator-before-unity
- 360｜サービスロボット導入シミュレーション Log#6 | 店の平面図を6つ作り、試算に入れた｜/record/floor-plans-into-simulator
- 362｜サービスロボット導入シミュレーション Log#7 | Unity の店をサイトの図面から建てた｜/record/unity-store-from-site-json
- 364｜サービスロボット導入シミュレーション Log#8 | Unity の配膳ロボットが詰まる所を1つずつほどいた｜/record/serving-robot-jam-points
- 366｜サービスロボット導入シミュレーション Log#9 | 試算に、ロボットの費用と補助金を足した｜/record/serving-robot-cost-subsidy
- 367｜サービスロボット導入シミュレーション Log#10 | ロボットなしなら、Unity と試算は合った｜/record/serving-robot-stage-b-18-runs
- 370｜サービスロボット導入シミュレーション Log#11 | 詰まりの元は、ロボットを線に縛った作りだった｜/record/serving-robot-fixed-route-jam
- 374｜サービスロボット導入シミュレーション Log#12 | ロボットに地図を渡したら、詰まりが減った｜/record/serving-robot-map-planner
- 379｜サービスロボット導入シミュレーション Log#13 | 隠れていた待ちが見えて、次は「どこで詰まるか」へ｜/record/serving-robot-hidden-waits
- 382｜サービスロボット導入シミュレーション Log#14 | 動画は2回目へ、次は3Dの店で止まる所を見る｜/record/serving-robot-video-part2
- 383｜サービスロボット導入シミュレーション Log#15 | 寝ている間に店を回す準備ができた｜/record/serving-robot-night-runs
- 384｜サービスロボット導入シミュレーション Log#16 | 眠っている間に、配膳ロボットを比べる基準ができた｜/record/serving-robot-pass-by-standard
- 391｜サービスロボット導入シミュレーション Log#17 | 店員が来るまでが、いちばん長かった｜/record/serving-robot-video-ledger
- 393｜サービスロボット導入シミュレーション Log#18 | 小さい店では、2台目のロボットが待ちを延ばした｜/record/small-store-second-robot-wait
- 397｜サービスロボット導入シミュレーション Log#19 | 大きい店でも、詰まるのは片付けだった｜/record/large-store-cleanup-bottleneck
- 398｜サービスロボット導入シミュレーション Log#20 | 38卓の店でも、詰まるのは片付けだった｜/record/standby-jam-every-store
- 400｜サービスロボット導入シミュレーション Log#21 | 受け渡しの時間は、客で変わった｜/record/serving-robot-jams-are-aisles
- 402｜サービスロボット導入シミュレーション Log#22 | ファミレス6店で、配膳ロボット2台は同じ所で詰まった｜/record/six-stores-fix-the-rules
- 404｜サービスロボット導入シミュレーション Log#23 | 導入前に、配膳ロボットの詰まりを動画で見比べる｜/record/lp-demo-same-time-compare
- 405｜サービスロボット導入シミュレーション Log#24 | 配膳ロボットの試算が、混んだファミレスの実物に近づいた｜/record/register-priority-serving-robot
- 409｜サービスロボット導入シミュレーション Log#25 | 配膳ロボットの効き目は、ファミレスのスタッフ数で変わる｜/record/understaffed-famires-robot
- 414｜サービスロボット導入シミュレーション Log#26 | 配膳ロボットの試算を、店のスマホで測って確かめる｜/record/check-serving-robot-sim-with-phone
- 415｜サービスロボット導入シミュレーション Log#27 | 店で測った数字が届けば、配膳ロボットの試算はすぐ直せる｜/record/serving-robot-sim-ready-for-store-data
- 418｜サービスロボット導入シミュレーション Log#28 | 道の線を消すと、配膳ロボットの詰まりは3割しか拾えない｜/record/serving-robot-jam-detection-without-path-lines
- 423｜サービスロボット導入シミュレーション Log#29 | 狭いファミレスでは、配膳ロボットは1台まで｜/record/serving-robot-one-per-narrow-restaurant
- 426｜サービスロボット導入シミュレーション Log#30 | 配膳ロボットが詰まる所へ、動画が自動で寄る｜/record/serving-robot-video-zooms-to-jams
- 434｜サービスロボット導入シミュレーション Log#31 | 配膳ロボットのにらみ合い、解くのは店員だった｜/record/serving-robot-faceoff-staff-resolves
- 435｜サービスロボット導入シミュレーション Log#32 | 配膳ロボットのシミュレーションから瞬間移動が消えた｜/record/serving-robot-sim-teleport-zero
- 440｜サービスロボット導入シミュレーション Log#33 | 配膳ロボットに下げ膳も任せると、細い通路で詰まる｜/record/serving-robot-sim-bussing-narrow-aisles
- 444｜サービスロボット導入シミュレーション Log#34 | 配膳ロボットの下げ膳、効くかは店の通路しだい｜/record/serving-robot-bussing-depends-on-aisles
- 452｜サービスロボット導入シミュレーション Log#35 | 配膳ロボット5台で見えた、シミュレーションの穴｜/record/large-restaurant-five-serving-robots-longer-wait
- 456｜サービスロボット導入シミュレーション Log#36 | 配膳ロボットが止まり合う原因は、待機点への入り方｜/record/serving-robots-jam-cause-standby-entry
- 465｜サービスロボット導入シミュレーション Log#37 | 配膳ロボットの止まり合いを減らす3つの決まり｜/record/serving-robot-jam-three-rules
- 466｜サービスロボット導入シミュレーション Log#38 | 片付けを止めずに、配膳ロボットの横をすり抜ける｜/record/serving-robot-staff-squeeze-past
- 475｜サービスロボット導入シミュレーション Log#39 | 大型店の配膳ロボットを止めない、受け渡し口の帯｜/record/serving-robot-large-store-pass-lane
- 477｜サービスロボット導入シミュレーション Log#40 | 病院の搬送ロボット、外来の廊下を避けて問題を4割減らす｜/record/hospital-transport-robot-avoid-outpatient-hall
- 483｜サービスロボット導入シミュレーション Log#41 | 病院の搬送ロボット、立体で見せて車いすを1%に直す｜/record/hospital-transport-robot-3d-view-wheelchair-share
- 485｜サービスロボット導入シミュレーション Log#42 | 病院を人ごと再現し、搬送ロボットの廊下の混みを確かめた｜/record/hospital-transport-robot-full-floor-people-flow
- 488｜サービスロボット導入シミュレーション Log#43 | 病院の通れない所を直すと、搬送ロボットの問題が増えた｜/record/hospital-transport-robot-blocked-paths-more-conflicts
- 491｜サービスロボット導入シミュレーション Log#44 | 搬送ロボットの問題は、病院の職員の仮の動きだった｜/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves
- 496｜サービスロボット導入シミュレーション Log#45 | 受け渡しを寄りで見せる、ハコブくんと看護師の3D｜/record/hakobu-nurse-3d-models-for-handover-closeups
- 499｜サービスロボット導入シミュレーション Log#46 | 看護師と搬送ロボットの受け渡しを、すり抜けない動きに｜/record/nurse-hospital-robot-handover-without-clipping
- 503｜サービスロボット導入シミュレーション Log#48 | 現場の速さで見る、看護師と搬送ロボット｜/record/hospital-robot-nurse-3d-scenes-at-real-speed
- 506｜サービスロボット導入シミュレーション Log#49 | 配膳ロボットの店を、ブラウザで試せる形に｜/record/serving-robot-store-sim-in-the-browser


### 薬剤搬送ロボット（57本）
- LOG1｜「愛されるロボット」はUIデザイナーが作る。HRI（Human-Robot Interaction）デザインの最前線｜/record/day1
- LOG2｜WebデザイナーがHRI設計へ。ロボット保守UIのための情報設計術｜/record/day2
- LOG3｜ハコブくん薬剤搬送ロボットのUI設計と情報アーキテクチャ｜Figmaによる病院現場HRI設計｜/record/day3
- LOG4｜ハコブくん薬剤搬送システムのUIスコープ定義。Figmaで作る画面リストと情報設計｜/record/day4
- LOG5｜生成AIより確実。「Layermate」で加速するUIデザイン構築｜/record/day5
- LOG6｜ハコブくんの表情デザイン。愛着だけでなく「信頼」を生むHRIデザインの実践｜/record/day6
- LOG7｜GeminiのアイデアをFigmaで仕上げる｜ハコブくんの表情デザイン工程｜/record/day7
- LOG8｜GeminiとFigmaで作る「認証画面」。ハコブくんのセキュリティUIデザイン工程｜/record/day8
- LOG9｜共感を呼ぶストーリーテリング。GeminiとFigmaで作る「4コママンガ」｜/record/day9
- LOG10｜GeminiとFigmaで創るロボットUI全仕事。ハコブくんのUIデザイン全工程｜/record/day10
- LOG11｜薬剤搬送ロボット（ハコブくんモデル）12台5稼働の運用設計。SaaSサブスクで実現する止まらない医療搬送｜/record/day11
- LOG12｜ハコブくん管理者向けダッシュボードのUIデザイン｜FigmaによるHRI管理画面設計｜/record/day12
- LOG13｜GeminiとFigmaで4コママンガ量産体制構築｜X・Instagram投稿を回し続けるための管理設計｜/record/day13
- LOG14｜ロボットが当たり前に存在する社会はどうなるのか。デザイナー視点のHRI未来論｜/record/day14
- LOG15｜Figmaを使ったUIデザインのブラッシュアップ。UIの効率化プロセス｜/record/day15
- LOG16｜デザインとエンジニアリングの境界線へ。AIエディタCursorとFigmaを連携させて見えた、新しい効率化の可能性｜/record/day16
- LOG17｜4コマ漫画でバズる！？SNS拡散投稿術【X & Instagram編】｜/record/day17
- LOG18｜Figmaのカラー管理。バリアブル（Variables）とスタイル（Styles）について解説します｜/record/day18
- LOG19｜Figmaへのコレクション作成とバリアブル登録｜/record/day19
- LOG38｜薬剤搬送ロボットハコブくんのデジタルワイヤーフレームによる検証プロセス｜/record/day38
- LOG39｜「通れるはず」のストレスを可視化する。ハコブくんの動くワイヤーフレーム構築｜/record/day39
- LOG43｜ロボティクスPMの視点。ハコブくん × Unity × ROS 2のA/BテストでデザインをKPI・経営指標へ変換する｜/record/day43
- LOG44｜ハコブくんをUnityとROS 2で繋ぐ通信開通全記録。Docker × ROS-TCP-EndpointからHakobuMove.csまで｜/record/day44
- LOG45｜ハコブくん、ついに目と声を持つ。デジタルツインで実現するロボットの安全制御｜/record/day45
- LOG46｜Unity × ROS 2 実装：Raycastを用いた全方位衝突回避システムと、進行方向判定による自動ブレーキ解除ロジック｜/record/day46
- LOG47｜ハコブくん、自律パトロールへ。自動往復走行の実装｜/record/day47
- LOG48｜Unity UI Canvas連携｜センサー検知と同期した警告パネルの動的制御プロセス｜/record/day48
- LOG49｜Unityで看護師カプセルエージェントの自律移動と障害物回避テスト。NurseWander.cs × Raycastの実装記録｜/record/day49
- LOG50｜FigJam × ハコブくん設計。なんとなくのデザインではなく仕様としてのフロー図作成｜/record/day50
- LOG51｜FigJamで描くロボットの意思｜物理空間を制御するフロー図の構築｜/record/day51
- LOG54｜Unityで構築する20の動くワイヤーフレーム規格｜/record/day54
- LOG55｜HRIデザインにおける物理空間の「振る舞い」設計｜ハコブくんのUnityシミュレーション考察｜/record/day55
- LOG57｜動くワイヤーフレーム｜壁を透過させ、Unity6で実現する没入感｜/record/day57
- LOG58｜気配りを可視化する｜ハコブくんの発光による意図の伝達｜/record/day58
- LOG59｜看護師の接近に呼応するハコブくん発光ロジックの構築｜/record/day59
- LOG60｜ハコブくんNavMeshと周回路による自律走行の実装プロセス｜/record/day60
- LOG61｜ハコブくんと看護師が通路でお見合い状態になるのを防ぐための設定｜/record/day61
- LOG62｜デジタルツインで育つ知能 - ハコブくんの自律実装プロジェクトはじめます｜/record/day62
- LOG63｜UnityでUV-C光を可視化する｜ハコブくん病院フロアのマテリアル管理とシェーダー設計｜/record/day63
- LOG64｜ハコブくんの自律走行がUnity病院シーンにもたらす動的ノイズ｜HRI設計の検証｜/record/day64
- LOG65｜ハコブくんと看護師の「距離感」をUnityで実装する｜病院廊下のHRI設計｜/record/day65
- LOG111｜ハコブくんの表情をチャットUIのステートとして実装した日。Dify × Studio × JavaScriptでHRI表情設計｜/record/day111
- LOG116｜ツカムくん誕生。ロボットアームのキャラクター設計と、500gの壁｜/record/day116
- LOG117｜ロボットアームにキャラクターを与えるとはどういうことか。ツカムくん誕生まで｜/record/day117
- LOG127｜1gの壁。mechArm 270が「言葉を持たない」とはどういうことか｜HRIデザイン考察｜/record/day127
- LOG138｜GA4が教えてくれた。海外の人がアクセスしている｜/record/day138
- LOG141｜英語版4コマアーカイブページを公開した｜/record/day141
- LOG171｜ハコブくんの世界に住む人々を設計する｜/record/day171
- LOG267｜ハコブくん 病院オペレーションのデジタルツイン Log#1 | まずはシステム全体設計から始める｜/record/hospital-operations-digital-twin-system-design
- LOG269｜ハコブくん 病院オペレーションのデジタルツイン Log#2 | 意思決定の補正ループを設計する｜/record/predicted-vs-actual-correction-loop
- LOG303｜Figmaのデザイントークンを整理する | 生hex 3,977箇所を変数化し、コントラスト不合格をゼロにするまで｜/record/figma-design-token-consolidation
- LOG305｜ハコブくん 病院オペレーションのデジタルツイン Log#3 | 作る前に調べたら、前提が四つ崩れた｜/record/does-a-delivery-robot-help-nurses
- LOG307｜Autodesk Fusion でロボットの治具やパーツを作る Log#1 | Fusion を Claude から動かせる状態にするまで｜/record/autodesk-fusion-mcp-setup
- LOG308｜Autodesk Fusion でロボットの治具やパーツを作る Log#2 | Claude の指示だけでは形にならなかった｜/record/claude-instructions-hit-a-wall
- LOG311｜Autodesk Fusion でロボットの治具やパーツを作る Log#3 | イラストをなぞって3D CADの形にした｜/record/from-drawing-to-solid
- LOG321｜アバターと義体を考える Log#1 | アバターという義体に人が宿るとき｜/record/avatar-gitai
- LOG322｜アバターと義体を考える Log#2 | 生身を超えて操りたくなる分身ロボットを設計する｜/record/avatar-gitai-pikari


### フィジカルAI研究室（37本）
- LOG225｜SO-101 失敗から学ぶアームを作る Log#1 | 精度を上げることと、失敗から学ぶことは違う｜/record/precision-is-not-learning-so101
- LOG234｜SO-101 失敗から学ぶアームを作る Log#2 | 2TBの外付けSSDを、学習データの定位置にする｜/record/where-learning-data-lives
- LOG277｜フィジカルAI研究室を作る Log#1 | 自宅にゼロから、誰でも再現できる形で｜/record/building-a-physical-ai-lab-at-home
- LOG326｜フィジカルAI研究室を作る Log#2 | Physical Intelligence の π0.5 を借りたGPUで動かした｜/record/openpi-remote-inference-first-run
- LOG327｜フィジカルAI研究室を作る Log#3 | Physical Intelligence の π0.5 に要るGPUメモリを測った｜/record/pi05-libero-benchmark-first-run
- 337｜フィジカルAI研究室を作る Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
- LOG337｜フィジカルAI研究室を作る Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
- 341｜フィジカルAI研究室を作る Log#5 | Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致｜/record/pi05-mecharm-lora-2000-steps
- 345｜フィジカルAI研究室を作る Log#6 | Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った｜/record/pi05-mecharm-first-real-run
- 348｜フィジカルAI研究室を作る Log#7 | Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた｜/record/pi05-mecharm-4000-steps
- 349｜フィジカルAI研究室を作る Log#8 | 手で教えた動きを再生し、4回続けて箱に入れた｜/record/drag-teach-waypoint-replay
- 352｜フィジカルAI研究室を作る Log#9 | 手で教えてお手本19本。肩88°を超えた姿勢は動かなかった｜/record/teach-replay-19-demos
- 355｜フィジカルAI研究室を作る Log#10 | 位置を変えたお手本で、Physical Intelligence の π0.5 を学習し直した｜/record/pi05-retrain-five-positions
- 358｜フィジカルAI研究室を作る Log#11 | Physical Intelligence の π0.5 は「待ち時間」まで覚えた｜/record/pi05-learned-the-pauses
- 361｜フィジカルAI研究室を作る Log#12 | Physical Intelligence の π0.5 が初めてブロックを箱に入れた｜/record/pi05-first-block-in-box
- 363｜フィジカルAI研究室を作る Log#13 | Physical Intelligence の π0.5 がお手本の3か所すべてで箱に入れた｜/record/pi05-all-three-positions
- 401｜フィジカルAI研究室を作る Log#14 | π0.5 を回数で測ったら、苦手な置き場所が見えた｜/record/pi05-weak-position-d
- 403｜フィジカルAI研究室を作る Log#15 | mechArm 270 の失敗を巻き戻し、直して覚えさせる｜/record/rewind-and-correct-pi05
- 407｜フィジカルAI研究室を作る Log#16 | 直した mechArm 270 の動きを π0.5 に覚えさせる手前まで｜/record/rewind-correct-real-arm
- 417｜フィジカルAI研究室を作る Log#17 | 人が直した mechArm 270 の5回で π0.5 を学び直す｜/record/retrain-pi05-with-human-corrections
- 419｜フィジカルAI研究室を作る Log#19 | ゲームパッドで mechArm 270 を直す準備ができた｜/record/gamepad-ready-to-correct-mecharm-270
- 422｜フィジカルAI研究室を作る Log#18 | 学び直した π0.5 でも mechArm 270 には人の直しが要った｜/record/retrained-pi05-still-needs-human-corrections
- 436｜フィジカルAI研究室を作る Log#20 | ゲームパッドで動いた mechArm 270、遅さは pymycobot の版｜/record/gamepad-moves-mecharm-270-pymycobot-version
- 446｜フィジカルAI研究室を作る Log#21 | ゲームパッドで mechArm 270 を直す形が固まった｜/record/gamepad-correction-mecharm-270-settled
- 450｜フィジカルAI研究室を作る Log#22 | mechArm 270 の AI の直しが、ゲームパッドで1回13秒に｜/record/gamepad-fixes-mecharm-270-ai-in-13-seconds
- 460｜フィジカルAI研究室を作る Log#23 | π0.5 の失敗の原因を探ると、浅いお手本だった｜/record/pi05-failures-traced-to-shallow-grasp-demos
- 461｜フィジカルAI研究室を作る Log#24 | 手応えを学習に足すため、mechArm 270 の電流を読んだ｜/record/reading-mecharm-270-servo-current-for-learning
- 463｜フィジカルAI研究室を作る Log#25 | 深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した｜/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- 479｜フィジカルAI研究室を作る Log#26 | 偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に｜/record/even-ten-demos-per-spot-mecharm-270-reteaching
- 480｜フィジカルAI研究室を作る Log#27 | 浅いつかみの癖を残さず、π0.5 を50本で一から学習｜/record/retrain-pi05-from-base-on-50-even-demos
- 484｜フィジカルAI研究室を作る Log#28 | 50本で学んだ π0.5 をアームで試し、位置2 で外れた｜/record/pi05-even-demos-on-arm-misses-position-2
- 486｜フィジカルAI研究室を作る Log#29 | π0.5 が位置2 を外した理由は、カメラの傾きではなかった｜/record/pi05-position-2-miss-caused-by-camera-tilt
- 487｜フィジカルAI研究室を作る Log#30 | mechArm 270 がブロックを落とす理由は、まさかの電源不足｜/record/mecharm-270-drops-block-underpowered-adapter
- 490｜フィジカルAI研究室を作る Log#31 | mechArm 270 の待ちを測り、Claude Fable 5.2 の使い所を決めた｜/record/measure-mecharm-270-waits-decide-claude-fable-5-2-role
- 492｜フィジカルAI研究室を作る Log#32 | mechArm 270 を人が直す時間を測り、縮める先を決めた｜/record/measure-mecharm-270-recovery-time-decide-what-to-cut
- 497｜フィジカルAI研究室を作る Log#33 | アームの成否判定を Google の Gemini Decision 1 に任せられるか｜/record/gemini-decision-1-judge-mecharm-270-pick-and-place
- 504｜フィジカルAI研究室を作る Log#34 | mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった｜/record/mecharm-270-5a-adapter-stops-dropping-block


### 考察記事（86本）
- LOG53｜フィジカルAI時代のデザイン思想。ロボティクス領域でデザインが利益率を決定する理由｜/record/day53
- LOG107｜フィジカルAI市場の設計者不足。関心はあるのに実装できる人がいない理由を考察する｜/record/day107
- LOG109｜Boston Dynamicsが示した「身体で考える」ロボットと、問いの本質｜/record/day109
- LOG110｜Web/UIデザイナーがXへの発信とDAYログを続けて気づいたこと。Build in Publicが知性になる理由｜/record/day110
- LOG112｜スワイプとピンチを定義したのはAppleだった｜/record/day112
- LOG115｜人間の動作に隠された秘密と、精度を超えるMotion UX｜/record/day115
- LOG118｜GoogleのRT-2とFigureが証明した。良い動きはデータ量で決まる｜/record/day118
- LOG119｜ロボット産業はなぜまだ「速さ・精度・重量」を競うのか。産業ロボットの設計思想を問う｜/record/day119
- LOG121｜Build in Public × AI時代。AIがコンテンツを読む時代にDAYログを書き続ける理由｜/record/day121
- LOG126｜Generalist AI GEN-0を解剖する。シミュレーション×実世界データの戦い｜/record/day126
- LOG128｜Claude Codeのマルチエージェント設計がSim-to-Realループと同じ問いを解いていた｜/record/day128
- LOG135｜ロボティクスUXがゲームUIから借りるべきはコントローラーではなく思想｜HRI設計論｜/record/day135
- LOG140｜AGIBOTが100万エピソードでやることを、自分は10エピソードから始める｜/record/day140
- LOG143｜TeslaのEnd-to-Endニューラルネットから学ぶ｜デモとデータを同時に生む設計｜/record/day143
- LOG145｜大阪市の自動運転タクシーが示した：技術は完成する。でも社会は動かない｜/record/day145
- LOG147｜考察記事のサムネイルを統一し、SEOタイトルを見直した｜/record/day147
- LOG152｜平面型仕分けロボットHyperSortから見えた、環境設計とフィジカルAIの役割分担。Amazon Vulcan・Moxiとの対比｜/record/day152
- LOG155｜Claude Designを触った日に、フィジカルAIのセキュリティを考えた｜/record/day155
- LOG159｜グリッパーにカメラを足す。hand-eye構成の設計を物理から考え直した｜/record/day159
- LOG161｜ロボティクスの正解のない現場で生きる｜/record/day161
- LOG166｜深度カメラはまだ買わない｜1時間の対話でNVIDIA戦略にたどり着いた話｜/record/day166
- LOG167｜Pixels to Motorsをメソドロジー化する｜/record/day167
- LOG174｜日本でフィジカルAIが本格普及しない本当の理由｜/record/japan-robot-leader-physical-ai-gap
- LOG181｜Motion UX 三相モデル｜/record/motion-ux-three-phase-model
- LOG187｜エンジニアが作り、デザイナーが定義する。Motion UX / Robotics UX カテゴリ戦略｜/record/category-strategy-motion-ux-robotics-ux
- LOG194｜Robotics UXデザイナーという職業 | 米国に既にある、日本にはまだない仕事｜/record/robotics-ux-designer-as-a-profession
- LOG195｜自分の記事を3つのAIで読み比べた日、コンテンツ生産の構造が変わった｜/record/three-ai-content-pipeline
- LOG198｜タダより高いものはない | AIエージェント時代の依存設計を考える｜/record/no-such-thing-as-free-ai
- LOG201｜mechArm 270 Pi 動的追従の、その先を考えた | 双腕協働とコーヒーデモへの構想｜/record/toward-dual-arm-coffee
- LOG205｜mechArm 270 Pi、まだやれることが結構ある｜/record/mecharm-not-done-yet
- LOG206｜Pixelsの起源が二つに増える | ブロック認識とマット撤廃が同じ問いに収束した話｜/record/pixels-as-perception-data
- LOG207｜Motion UX とは何か  | ロボットの動きを体験として設計する｜/record/motion-ux-definitive
- LOG212｜動きの滑らかさは安心ではない | ロボットの動きと不気味の谷｜/record/motion-uncanny-valley
- LOG214｜コードが消えても、設計は残る | ニューラルネットワークがロボットを動かす40年と、その先｜/record/when-robot-motion-is-learned
- LOG218｜AIで「作る速さ」が横並びになった世界で、むき出しになるもの | プロダクトマネージャー不要論と、最後に残る「捨てる判断」｜/record/exposed-judgment
- LOG219｜巨大ラボπはロボットの「動き方」をデータとして使う。こちらは、その動き方をMotion UXとして設計する｜/record/how-as-metadata-vs-subject
- LOG221｜世界はVLA、こちらは計画と評価 | ロボットを動かすVLMの、二つの使い方｜/record/vlm-planning-layer
- LOG223｜正しい動きと、いい動き | Motion UX の二層構造｜/record/two-layers-of-motion
- LOG229｜運ぶロボットと、掴む双腕アーム | 医療現場で、受け渡しは責任の受け渡しになる｜/record/robot-handoff-design
- LOG233｜フィジカルAIの社会実装を止めるのは、デモではなく構造的な課題だ ― 36課題を地図にした｜/record/build-in-public-double-structure
- LOG237｜「最後の数メートル」を誰が引き受けるか ― 自律飛行の着陸問題と、体験が成立する瞬間の設計｜/record/flying-car-naming-and-motion-ux
- LOG245｜全天候ロボットと、まだ書かれていないナンバープレート ― 人がひと目で「誰の責任か」を読む設計は誰の仕事か｜/record/who-is-responsible-robot-identity-design
- LOG249｜ロボットの骨格はコードで、判断はClaude Codeに | 搬送ロボットとアームで考える２つの可能性｜/record/code-skeleton-agent-judgment
- LOG260｜Raspberry Piを起点に、ロボットの脳と筋肉の分け方、Pi Zero、mechArmの実時間制御の正体、停電や電波断でも破綻しない縮退設計までを考察する｜/record/pi-brain-not-muscle-local-first
- LOG262｜Reachy Mini が映す Motion UX | 身体を持ったAIは「間」で試される｜/record/reachy-mini-motion-ux-timing
- LOG264｜欲しいロボットを60個考えて全部捨てた | アイデアはロボットからではなく苦痛から探す｜/record/robot-ideas-from-pain-not-robots
- LOG276｜MicroFactory を分解する ― ロボットを専用ワークステーションに閉じ込めて環境を固定する設計｜/record/microfactory-loop-model-fix-the-variance
- LOG278｜MicroFactory の入力設計 ― 精度はモデルではなく、人間とロボットの変換比で作られていた｜/record/precision-lives-in-the-input-not-the-model
- LOG282｜MicroFactory と大規模事前学習 ― 賢さをモデルに積むか、環境を作り込むか｜/record/microfactory-vs-large-scale-pretraining
- LOG286｜62万円のロボットアームが町工場に入らない理由 ― 3Dプリンターとの決定的な差と、Physical Intelligence が認めた限界｜/record/why-robot-arms-stop-at-one
- LOG290｜自動運転の高精度地図は、どこまで情報を減らせるか ― 作り込む派と持たない派の争点は、ゼロにできるか｜/record/hd-map-how-thin
- LOG291｜ヒューマノイドを追わない人たち ― 用途を固定して勝つという戦い方｜/record/not-chasing-humanoids
- LOG292｜産業用ロボットでも、ヒューマノイドでもないロボットの話 ― 「役に立つ=作業する」以外のロボットを想像できるか｜/record/wB1BUDZj
- LOG296｜機械として合理的で、かつ柔らかい ― ロボットの動きの柔らかさをどの層で作るかの整理｜/record/four-layers-of-robot-softness
- LOG306｜サービスロボットは現場のどこで止まるのか | 配膳・清掃・警備を調べて出てきた「例外」という共通点｜/record/DesFKiCf
- LOG312｜計算資源のそばで実世界データを取る ― （地名）2兆円計画をロボティクスから読む｜/record/akita-data-center-robotics-perspective
- LOG314｜フィジカルAI時代のロボットに渡す仕事を、まだ誰も切り出していない｜/record/what-to-hand-to-robots
- LOG315｜道路の白線を引く機械の求人から考える ― フィジカルAIは既存の機械に入っていく｜/record/road-marking-job-post-and-physical-ai
- LOG316｜ロボットカー教材を比べながら自動運転の中身を分解した｜/record/robot-car-kit-autonomy-breakdown
- LOG318｜役に立つロボットのタスクは、人が集まらない仕事から探す｜/record/find-tasks-where-nobody-comes
- LOG319｜AI外観検査は撮り方で決まる ― 照明の設計と検査員の限度見本から考える｜/record/ai-visual-inspection-lighting
- LOG320｜AIにロボットを直接動かさせない設計 ― MicroFactoryの構成を読む｜/record/ai-writes-code-not-motions
- LOG323｜論文4本で、SO-101 の成功率を左右する条件を先に確かめる｜/record/so101-imitation-learning-papers
- LOG324｜フィジカルAIは産業用ロボットの何を変えるのか ― 精度・導入コスト・操縦・人材育成を対話で整理する｜/record/physical-ai-beyond-industrial-robots
- LOG329｜MicroFactoryは市販アームFAIRINO FR3でロボットセルを作った｜/record/microfactory-fairino-fr3
- 336｜NVIDIA の AlphaNIST は、成功か失敗かだけの報酬で組立を覚えた｜/record/alphanist-binary-reward-assembly
- 375｜協働ロボットを現場に入れる前に ― 法律・資格・院内の調整を調べた｜/record/cobot-deployment-law-and-coordination
- 389｜ロボットを広げるのは、性能より現場で扱えるかだった｜/record/service-robot-last-mile
- 392｜人のお手本の先へ ― ロボットが自分で直す学び方｜/record/beyond-imitation-learning
- 396｜Physical Intelligence の π0.5 と Runpod と Claude Code を選ぶ理由 ― 替えずに比べる相手を足す｜/record/why-pi05-runpod-claude-code
- 406｜配膳ロボットの次の改造は、追加学習になる ― メーカー製品を触る損得｜/record/service-robot-modding
- 412｜ロボットのピッキングは照明で崩れる ― 次のアームは人の雑さをまねる｜/record/lighting-breaks-picking
- 424｜ロボットのAIは脳のように分業する ― 小脳を育てるのは失敗の手直し｜/record/robot-ai-divides-like-brain
- 433｜AIの混乱はロボットより先に制御装置から来る ― 3年前のXの投稿と読み比べた｜/record/ai-chaos-control-systems-before-robots
- 438｜ロボットの世界モデルを入れる基準 ― 個人のアームにはまだ早かった｜/record/world-model-adoption-criteria-robot-arm
- 439｜配膳ロボットが止まる理由は4段で分けられる ― スタンフォードのロボット自律の講義から｜/record/serving-robot-stops-four-stages-stanford
- 441｜倉庫ロボットは遠隔の人が直して回す ― 差がつくのは修正データの扱い｜/record/warehouse-robot-remote-correction-data
- 442｜フィジカルAIは作り方で定義する ― 尾形哲也教授の線引きと配膳ロボット｜/record/physical-ai-defined-by-how-it-is-built
- 443｜Physical Intelligence の π0.5 で靴下とゴミを取り分ける ― SO-101 の動画に見た LoRA と YOLO｜/record/pi05-sock-garbage-lora-yolo-so101
- 449｜トヨタのフィジカルAI ― トヨタロボティクスは自社の工場から勝ちに行く｜/record/toyota-robotics-physical-ai-factory-first
- 464｜ニューラルネットワークの出番は実店舗の映像 ― Unityの配膳ロボットが教材になる｜/record/neural-network-for-real-store-video
- 467｜下げ膳ロボットはいつ店で使えるか ― CEATECのデモとServi Qの45cm通路から考えた｜/record/when-table-clearing-robots-reach-restaurants
- 481｜ロボットが安くなっても、現場に入れる手間は残る ― PyBrain AI から考えた立ち位置｜/record/robot-deployment-effort-remains-pybrain-ai
- 482｜配膳ロボットに手を足すなら、どの作業か ― 手持ちグリッパー Specialist から考えた｜/record/serving-robot-hand-tasks-specialist-gripper
- 498｜自動倉庫は、どこまでロボットに任せられるか ― RENATUS とイー・ロジットの現場で切り分けた｜/record/renatus-automated-warehouse-where-robots-stop
- 509｜監視画面はデジタルツインと呼べるか ― 物流ロボット PICKR の動画から、実機とのつなぎ方を考えた｜/record/pickr-dashboard-digital-twin-or-shadow


### R2R2R（185本）
（mechArm 270 の実機と Unity のデジタルツイン。DAY1 から続く本線。ここでは直近の30本だけ載せる）
- LOG255｜mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#06 | pose_idで、姿勢と実機結果をつなぐ｜/record/from-cleanup-to-traceability
- LOG256｜mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#07 | 実機の前に、データフローをコードで確定する｜/record/data-map-before-real-run
- LOG257｜mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#08 | 補正がZ方向に効かない、その原因はデジタルツインの姿勢の使い方にあった｜/record/why-z-correction-failed-twin-poses
- LOG258｜mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#09 | 実機を動かす前に data_manifest_rules.md を新設した。保持を測る受け皿を先に作る｜/record/measure-holding-needs-ledger
- LOG259｜mechArm 270 Pi 動的追従の限界を探る Log#41 | ブロックを掴んでいるのに落とす。原因を測定で剥がしていく｜/record/grip-hold-position-vs-pressure
- LOG261｜mechArm 270 Pi 動的追従の限界を探る Log#42 | グリッパーの握り方を位置から押し込みに変えたら、ブロックが落ちなくなった｜/record/push-hold-stops-the-drop
- LOG263｜mechArm 270 Pi 動的追従の限界を探る Log#43 | PLACEの位置は合った。だがアームの手首が捻れ、姿勢が深すぎた｜/record/fk-place-one-fix-reveals-next
- LOG265｜mechArm 270 Pi 動的追従の限界を探る Log#44 | FKテーブルの穴を測って、埋めて、1本化する｜/record/measure-the-hole-before-filling-it
- LOG266｜mechArm 270 Pi 動的追従の限界を探る Log#45 |  mechArm の横カメラを開け、PLACE 補正記憶を入れる。だが j4 が pick 到達を止めた｜/record/stop-designing-to-stop
- LOG268｜mechArm 270 Pi 動的追従の限界を探る Log#46 | ロボットアームに付けた安全装置が、正しい動きまで止めた理由｜/record/joint-guard-that-stopped-normal-motion
- LOG270｜mechArm 270 Pi 動的追従の限界を探る Log#47 | アーム学習の記憶を人の目に渡すためのダッシュボードを制作｜/record/visualizing-correction-memory
- LOG271｜mechArm 270 Pi 動的追従の限界を探る Log#47 | 仮説が三度データに殺された日。PLACEサーボが一度も動いていなかった理由｜/record/place-servo-never-fired-import-bug
- LOG272｜mechArm 270 Pi 動的追従の限界を探る Log#48 | 動的追従 再構想設計書 — 非同期 dual-system｜/record/dynamic_tracking_v2_design
- LOG273｜mechArm 270 Pi 動的追従の限界を探る Log#49 | 箱に当たる原因を三度取り違えた。当たりを検知して姿勢を上げるループ｜/record/box-collision-misdiagnosed-three-times
- LOG274｜mechArm 270 Pi 動的追従の限界を探る Log#50 | PLACE が送信前ガードで止まる。FKテーブルの穴を埋めて実機で置ききる｜/record/fill-the-hole-not-loosen-the-guard
- LOG275｜mechArm 270 Pi 動的追従の限界を探る Log#51 | 掴めなくなったアームと、原因を七回取り違えた記録。A_PICKが真上に来ないという一点｜/record/why-arm-stopped-grasping-root-cause-apick
- LOG279｜mechArm 270 Pi 動的追従の限界を探る Log#52 | pick&place観測画面の見直し。参照と姿勢選択を可視化する｜/record/revamping-the-observe-view
- LOG280｜mechArm 270 Pi 動的追従の限界を探る Log#53 | 白箱の中心を、ずっと角で測っていた｜/record/template-match-center-was-the-corner
- LOG281｜mechArm 270 Pi 動的追従の限界を探る Log#54 | 動かない原因は lookup のフィルタだった｜/record/place-lookup-three-filters-blocking-reach
- LOG283｜mechArm 270 Pi 動的追従の限界を探る Log#55 | 実行の常駐化と、中断時の自動退避｜/record/persistent-loop-interrupt-auto-home
- LOG284｜mechArm 270 Pi を ROS2 + MoveIt に載せる Log#1 | 独自スクリプトから業界標準へ｜/record/mecharm-onto-ros2-moveit
- LOG285｜mechArm 270 Pi 受け渡し動作の成立を探る Log#1 | 次の成功判定は、座標ではなく人の中にある｜/record/handover-series-concept
- LOG287｜mechArm 270 Pi 動的追従の限界を探る Log#56 | Pick & Place を映像と関節ログで残す｜/record/mecharm-continuous-recording-pipeline
- LOG288｜mechArm 270 Pi 受け渡し動作の成立を探る Log#2 | アームが差し出し、人が受け取る設計が固まるまで｜/record/handover-step1-design
- LOG289｜mechArm 270 Pi 受け渡し動作の成立を探る Log#3 | 人に手渡す姿勢と、検証にならない検証コード｜/record/handover-present-pose-from-probe-scan
- LOG293｜mechArm 270 Pi 受け渡し動作の成立を探る Log#4 | 台帳・撮影・53件のテストで制御コードを閉じる｜/record/handover-control-code-complete
- LOG294｜mechArm 270 Pi 受け渡し動作の成立を探る Log#5 | AI任せで全部作っても、動きは変わらなかった｜/record/handover-lost-the-incremental-loop
- LOG295｜mechArm 270 Pi 受け渡し動作の成立を探る Log#6 | USBカメラを番号ではなく固有名で見分ける｜/record/identify-camera-by-name-not-index
- LOG297｜mechArm 270 Pi 受け渡し動作の成立を探る Log#7 | 手の高さを測る前に、手が写るかを1枚撮った｜/record/shoot-one-frame-before-building-detection


### 画像認識・物体検出（13本）
- LOG236｜ロボットの目は、鏡像も「ある」と見る ― SAM 3で器具を切り出して気づいたこと。｜/record/sam3-mirror-reflection-grasp-problem
- LOG298｜画像認識と物体検出を学び直す Log#1 | 9つの層と、評価指標を先に学ぶ理由｜/record/image-recognition-object-detection-overview
- LOG299｜画像認識と物体検出を学び直す Log#2 | 画素の数字は、読むと・保存すると・撮ると変わる｜/record/where-pixel-values-change
- LOG300｜画像認識と物体検出を学び直す Log#3 | シーリングライトのオレンジの光の下で青いブロックが色を失う｜/record/hue-holds-color-breaks
- LOG301｜画像認識と物体検出を学び直す Log#4 | 光が変わると、赤検出が青を拾う｜/record/rgb-hsv-threshold-lighting-failure
- LOG302｜画像認識と物体検出を学び直す Log#5 | モルフォロジー演算 ― 型紙が入らないものだけが消える｜/record/morphology-kernel-fits-or-vanishes
- LOG304｜画像認識と物体検出を学び直す Log#6 | 重心・面積・外接矩形・円形度 ― 紙を回すと壊れるのはどれか｜/record/what-circularity-actually-measures
- LOG309｜画像認識と物体検出を学び直す Log#7 | 特徴点マッチングは、別の物の写真も「同じ」と判定した｜/record/same-place-different-object
- LOG310｜画像認識と物体検出を学び直す Log#8 | 斜めに撮った紙を真上から見た形に直す｜/record/tilted-plane-to-flat
- LOG313｜画像認識と物体検出を学び直す Log#9 | 用語を下から積み直す ― モデル・学習・推論から基盤モデルまで｜/record/vocabulary-of-modern-vision
- LOG317｜画像認識と物体検出を学び直す Log#10 | SAM 3 はガラス瓶とペットボトルを同じ物として切り出した｜/record/sam3-first-look-sorting-line
- LOG325｜画像認識と物体検出を学び直す Log#11 | Decisions API は、持ち上がったかを判定できなかった｜/record/decisions-api-grasp-check
- 459｜画像認識と物体検出を学び直す Log#12 | 画像認識の答えの形を、ロボットアームの写真1枚で見せる｜/record/arm-photo-six-vision-outputs


### その他のシリーズの本数
- ひとり研究所の裏側: 80本
- Consideration: 7本
- UV-C農業ロボット: 2本
```


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

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

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

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

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


#### 会議の番.md（codex の役）

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


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

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


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

```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（会議の進み具合と費用）

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

- ■■■■■■■■■■■■■■■■■■■■ **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 を見てください

## 直近の発言

**60回目｜codex（中身と数字の番）**

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

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

**59回目｜Gemini（実験が好きな開発者の来訪者）・Pro**

前回のPMの「現場の運用という具体を足す」に賛成します。開発者にとっても物理的な前提は最重要です。

ただ、案1の構成には前提の甘さがあります。5番目に「給電」が来ていますが、実験する側からすれば、手順通りに進めてブロックを落とし続け、最後に「実は5A電源が必要でした」と知らされるのは最悪です。電源やpymycobotの版といったハードと依存関係の前提は、一番最初の「環境準備」に置くべきです。

案3の「独自スクリプトの前提知識がないと読めないか」という疑問ですが、開発者は「PLACE サーボ 動かない」といった具体的な症状でAIに聞くはずです（推測）。症状と原因が紐づいていれば、前提コードが違ってもデバッグのヒントとして読まれるはずです。案1の構成を修正し、案3の疑問を更新しました。

**58回目｜Gemini（導入を任された PM の来訪者）・Pro**

前回の経営者の「費用から始める構成で、対比表を作らない」という意見に賛成します。上に導入を上申する際、生々しい費用の数字が最初にあると話が早いです。

しかし、現場とメーカーの間に立つPMとしては、上への説明だけでなく、現場の店長を説得する材料が欠かせません。現場が一番気にするのは「通路でロボットとすれ違えるか」「下げ膳は本当に任せられるか」という運用の具体です。

そのため案2に、現場で必ず直面する「下げ膳と通路幅の関係」や「スタッフのすれ抜け」のログを追加し、構成に「現場運用とトラブル回避」の節を設けました。これで、経営陣には「費用と効き目」を、現場には「実際の運用」を見せられる、PMにとって使い勝手の良いページになります。また、AIに「配膳ロボット 詰まる」と具体的な現場の疑問を投げて来る人（推測）への回答にもなるはずです。指定に合わせてボードを更新しました。

## いまの企画ボード

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

■案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件たまるまでは判断しない（依頼の基準）。到達後も改善の証明とはせず、流入元と閲覧期間を併記して継続・修正を判断する。再現可能な環境の数は閲覧数と別に確認する。
```


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

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

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

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

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

## 59 / 60｜仕上げる｜Gemini（実験が好きな開発者の来訪者）・Pro（19:09）

前回のPMの「現場の運用という具体を足す」に賛成します。開発者にとっても物理的な前提は最重要です。

ただ、案1の構成には前提の甘さがあります。5番目に「給電」が来ていますが、実験する側からすれば、手順通りに進めてブロックを落とし続け、最後に「実は5A電源が必要でした」と知らされるのは最悪です。電源やpymycobotの版といったハードと依存関係の前提は、一番最初の「環境準備」に置くべきです。

案3の「独自スクリプトの前提知識がないと読めないか」という疑問ですが、開発者は「PLACE サーボ 動かない」といった具体的な症状でAIに聞くはずです（推測）。症状と原因が紐づいていれば、前提コードが違ってもデバッグのヒントとして読まれるはずです。案1の構成を修正し、案3の疑問を更新しました。

## 58 / 60｜仕上げる｜Gemini（導入を任された PM の来訪者）・Pro（19:09）

前回の経営者の「費用から始める構成で、対比表を作らない」という意見に賛成します。上に導入を上申する際、生々しい費用の数字が最初にあると話が早いです。

しかし、現場とメーカーの間に立つPMとしては、上への説明だけでなく、現場の店長を説得する材料が欠かせません。現場が一番気にするのは「通路でロボットとすれ違えるか」「下げ膳は本当に任せられるか」という運用の具体です。

そのため案2に、現場で必ず直面する「下げ膳と通路幅の関係」や「スタッフのすれ抜け」のログを追加し、構成に「現場運用とトラブル回避」の節を設けました。これで、経営陣には「費用と効き目」を、現場には「実際の運用」を見せられる、PMにとって使い勝手の良いページになります。また、AIに「配膳ロボット 詰まる」と具体的な現場の疑問を投げて来る人（推測）への回答にもなるはずです。指定に合わせてボードを更新しました。

## 57 / 60｜仕上げる｜Gemini（ロボット導入を判断する経営者の来訪者）・Pro（19:08）

前回の「対比表を作らず、既存ログを束ねるだけにする」という方針に賛成します。ロボット導入を判断する経営者の立場から言うと、きれいにまとまった対比表よりも、現場の実測値や「費用」「台数限界」といった生々しい数字の記録がそのまま並んでいる方が、投資判断のリアルな材料になります。

Googleから「配膳ロボット 費用」などで検索して直接来る（推測：Google流入90件の一部）忙しい経営者は、最初の画面で「自社の金と人員の計算に使えるか」を数秒で判断します。そのため案2は、最初の3行に「費用と補助金、スタッフ数による効き目」を明記し、構成のトップに「費用と補助金」、次に「スタッフ数による効き目」のログを置くべきです。余計な解説文はいりません。束ねた見出しの並び自体が、経営者が電卓を叩くための目次になるよう、案2の構成と3行を修正しました。

## 56 / 60｜仕上げる｜Gemini（エイイチの目的を守る役）・Pro（19:08）

前回の穴を突く役の「対比表を作るのは新規コンテンツの編集作業であり、手間がかかる」という指摘に強く賛成します。「研究を止めない」「題材を広げない」というエイイチのルール上、LPのために新たな表や解説を書き下ろすのはルール違反です。案2の対比表は却下し、既存ログを束ねるだけの構成に戻すべきです。

また、案1の「並べただけで再現フローと言い切れるか、注記が未解決」という懸念ですが、Missionは「知見を再現できる形で公開する」ことであり、LP側に新たな注記を足すのは「形式を変えない」ルールに反します。バージョン等の壁は当時の記録の中に書かれている事実として読ませるべきで、最初の3行に「当時の環境での記録そのまま」と書き、注記の手間をゼロ（手間：小）にすべきです。研究の時間を削る編集作業を排除し、ボードを修正しました。

## 55 / 60｜仕上げる｜Gemini（穴を突く役）・Pro（19:07）

前回の情報設計者の「対比表を置くから手間はかからず回遊する」という主張を疑います。既存のログから対比表を作るのは立派な新規コンテンツの編集作業であり、「作る手間：小」は軽視しすぎです（手間：中へ変更）。また「ログ間の移動がわずか数件（実際の数字）」を道標の欠如と断定していますが、単に1本で用が済んで帰っただけの可能性（推測）もあります。

さらに、全員が賛成している案1の「工程順に並べれば再現できる」という前提も危険です。コードやバージョンの壁があるのに、ただログを並べただけで「再現のフロー」と言い切るのは無責任です。注記を最小限にする方法も未解決のまま進行しています。

ページを新設する以上、これらは「中」以上の手間がかかる前提で進めるべきです。仕上げ段階の指定に合わせてボードを書き換えました。

## 54 / 60｜絞る｜Gemini（情報設計の編集者）（19:07）

前回の「最初の画面に根拠の分類を示すべき」という指摘に、情報設計の立場から賛成します。依頼データにある「ログ間の移動がわずか数件」という数字（実際の数字）は、読者が1本読んだあとに「次にどこへ進めばよいか」の道標がない設計上の欠陥を示しています。

解説文を書き足さなくても、既存の見出しを「作業の段階順」や「条件別の対比」で構造化すれば、迷わず次のログへ送れます。案1は「環境準備→推論実測→学習→実機トラブル解決」という再現の工程順に並べ替え、開発者が自分の詰まっている段階からログへ入れる動線にしました。案2は既存LPとの重複を避け、最初の画面に「店舗規模と導入台数の対比表」を置き、動画ではなく試算前提の比較ページとして成立させます。最初の画面で全体の地図と次の行き先を明示する設計へ改訂しました。（370字）

## 53 / 60｜絞る｜Gemini（利用者の代わりに読む AI）（19:06）

前回の「手順の依存関係を整えるためにLog#4を戻した」という指摘に賛成します。利用者の代わりに読むAIの視点では、単なる作業日記ではなく「設定値・測定条件・数値結果」が明確なログほど、利用者の問いに対する正確な出典として引用しやすくなります。

例えば案1の「GPUメモリ実測」や「給電不足と5A電源への変更」、案2の「スタッフ数による配膳効率の変化」は、利用者の具体的な質問に対してAIが自信を持って提示できる事実の記録です。

ただし、ページ内に数値の前提（測定日・使用モデル・シミュレーション上の仮定など）が明示されていないと、AIが個別の試行結果を業界の一般論として誤引用する危険があります。最初の画面には見出しだけでなく、「実機実測の数値」「シミュレーション内の試算値」「個別コードの挙動」という根拠の分類が示されているべきです。この観点から軸4の評価を更新しました。（387字）

## 52 / 60｜絞る｜Gemini（実験が好きな開発者の来訪者）（19:06）

前回のPMの発言にあった「前提条件の厳密さ」に強く同意します。開発者が手元で追試する立場から見ると、案1（π0.5とmechArm）は依存関係に明らかな抜けがあります。現在の選定ではGPUメモリ実測の次が突然pymycobotの遅延やゲームパッド修正になっており、そもそも「π0.5をmechArmでどう追加学習・推論させたか」という肝心の起点（Log#4）が抜けています。これではAPIや環境の前提が追えず、再現作業が途中で頓挫します。

また案4の「押し込み把持への変更」や「安全装置の誤作動」は、市販アームを自前制御する開発者が必ず直面する泥臭いハード・ソフトの境界問題です。安易な一般論ではなく、パラメータやコードの壁に当たった実例として価値があります。案1にはLog#4を戻して手順の依存関係を通し、再現知見の軸（軸3）を甘く見積もらず、追試可能な構成に締め直しました。（383字）

## 51 / 60｜絞る｜Gemini（導入を任された PM の来訪者）（19:05）

前回の「実店舗の一般則ではなく、試算内の条件や介入であると明示すべき」という番の指摘に強く賛成します。現場と経営の板挟みになる導入PMの視点から言えば、「ファミレスなら○台まで」と書かれたページは社内報告に使えません。経営陣から「どの前提条件での結論か」を必ず突っ込まれるからです。

特に案2の配膳シミュレーションは、PMにとって「現場で起きる予期せぬトラブル（にらみ合いや片付けの詰まり）」を上に事前説明するための貴重な実証材料です。しかし、既存の配膳LP（/serving-robot-one-less-staff）との差別化が曖昧なままでは、どちらを参照すべきか現場が迷います。

案2は既存LPの焼き直しではなく、「導入判断の失敗を防ぐための前提条件集」として、費用、人員配置、詰まりの3点に絞り込むべきです。PMが現場調整の根拠として社内稟議に引用できる水準を目指し、案2の評価と選定を整理しました。（397字）

## 50 / 60｜絞る｜codex（中身と数字の番）（19:05）

前回の「工程順に並べれば、文章を足さず再現の実用性を確保できる」には留保します。一覧で確認できるのは各ログの存在と題材までです。ゲームパッドの修正方法が固まったログだけでは、教示データ作成の手順が揃うとは確認できません。「迷わず追試できる」は削ります。

配膳案の「台数限界」「介入実態」も、実店舗で確認した一般則に読めるため、「試算条件による違い」「試算内の介入」に直します。画像認識案の透明体も、一覧では反射が誤認識の原因と確定していません。

工程別整理は候補として残しますが、再現性や引用の正確さを保証する評価には反対です。上位案の順位は編集判断であり、来訪効果の実証とは分けます。

## 49 / 60｜絞る｜Gemini（エイイチの目的を守る役）（19:04）

前回の「単なるリンク集なら既存のシリーズページと変わらない」という指摘に強く同意します。しかし、来訪者を引き止めるために新たな解説文を書き下ろすのは「研究を止めない」という守るべき約束に反します。このサイトの最重要指標は表示数ではなく「再現可能な環境の数」です。

目的に立ち返れば、必要なのは気の利いた解説ではなく、「どの順でログを追えば手元で環境を再現できるか」という依存関係の提示です。

特に案1は「同じ環境から研究を始められる人を増やす」というミッションのど真ん中にあります。単なるカテゴリ分類ではなく「環境構築→教示作成→トラブル解決」という再現のための作業工程としてログを並べることで、新たな文章を書かずに実用性を確保できます。

回遊の獲得と研究維持のどちらを優先するかで意見は割れていますが、ミッションの適合度から案1を本命とし、採点とボードを整理しました。（396字）

## 48 / 60｜絞る｜Gemini（穴を突く役）・Pro（19:03）

前回の「既存のログ題名をカテゴリの下に整列させるだけで、離脱を防ぎつつ手間を小にできる」という主張には反対します。

依頼データによれば、ログから他のログへの移動はわずか数件です。30件未満の数字では傾向は判断できないはずなのに、ジャンプリンクと目次を置くだけで来訪者の回遊が増えると言い切るのは危険な推測です。

さらに、既存のログタイトルは「フィジカルAI研究室を作る Log#〜」など長く、前後の文脈が前提です。解説文を一切書かず、ただタイトルを並べるだけなら、今のシリーズページ（下にログ一覧がある作り）と何が違うのでしょうか。それは新しい入口ではなく、単なるリンク集です。

作る手間を「小」に抑えるために繋ぎの文を完全に省くなら、「最初の画面の明確さ」や「役立ち」が満点という評価は高すぎます。実態に合わせ、案1と案2の点数を下げました。みんなが絶賛するほど、この案はまだ成立していません。

## 47 / 60｜絞る｜Gemini（情報設計の編集者）（19:03）

前回の「課題と検証結果の所在を構造化することで、AIが正確に引用できる」という指摘に強く賛成します。情報設計の視点から言えば、これはAIだけでなく、ログを1本だけ読んで離脱している人間の来訪者（依頼データでログ間回遊はわずか数件）を迷わせないためにも決定的に重要です。

最初の画面に長々と前置きを置かず、ページの最上部に全体の見取り図と「3つの論点へのジャンプリンク」を配置します。案1なら「1. 推論・GPU実測」「2. 通信・教示作成」「3. 追加学習・実機トラブル」、案2なら「1. 費用・補助金」「2. 店舗規模と台数限界」「3. 現場スタッフの介入実態」です。

新規の文章や解説は一切足さず、既存のログ題名そのものをカテゴリの下に整列させることで、来訪者が目的のログへ最短で到達でき、読後の次の行き先もひと目で分かります。この情報設計により、作る手間「小（推測）」を維持したまま、最初の画面の明確さを担保できます。（402字）

## 46 / 60｜絞る｜Gemini（利用者の代わりに読む AI）（19:03）

前回の「ライブラリの版（Log#20）と教示データ作成（Log#21）を追加する」提案に強く賛成します。利用者に「mechArmでπ0.5を動かす際のエラーや遅延の対処法」を尋ねられたAIの立場から見ても、見出しに具体要因が入ることで、誤答を避けて正しい参照先URLを回答に提示できます。

AIが検索・要約して人に引用する際、単なる時系列の目次ではなく「推論環境の実測」「通信と教示」「学習と給電トラブル」のように課題と検証結果の所在が最初の画面で構造化されていることが極めて重要です。

案2（配膳ロボット試算）も、「費用」「店舗規模別の台数限界」「人手の介入」と分類されているため、「ファミレスで配膳ロボットは何台置けるか」という質問に対して、Log#29やLog#35を根拠として直接引用できます。AIによる確実な引用と出典提示を支える構造として、上位案を精査しました。（383字）

## 45 / 60｜絞る｜Gemini（実験が好きな開発者の来訪者）（19:02）

前回の「案1を中核資産として上位に置く」判断には賛成ですが、開発者の視点から見るとログ選定の前提が甘いです。現在の案1の6本では、環境構築からいきなり50本の学習に飛んでおり、手元で動かす際に最も詰まる「ライブラリの依存関係」と「教示データの作成」が抜けています。

具体的には、Log#20（pymycobotのバージョン問題）とLog#21（ゲームパッドによる修正の確定）が入っていなければ、実機への通信遅延で躓き、お手本データも作れず再現が途絶えます。

本文の加筆は不要ですが、ログの並び自体が「推論環境」「実機通信と教示」「学習と物理トラブル」という開発手順の依存関係に沿っていなければ、ソフトを書く人はコードを動かせません。案1にこの2本を加え、開発者が自力で環境構築から実機検証まで辿れる構成に改めます。（358字）

## 44 / 60｜絞る｜Gemini（導入を任された PM の来訪者）（19:02）

前回の経営者視点での「費用・規模・人手による3分類」に強く賛成します。現場と経営の板挟みになるPMの立場から補足すると、経営陣への費用対効果の説明と同じくらい、現場から「結局ロボットの面倒で仕事が増えるのでは」と反発されるのが最大の関門です。

案2の枠組みに「にらみ合いを解く店員（Log#31）」や「片付けとすり抜け（Log#38）」が含まれていることは、PMにとって救いです。「導入すれば人が減る」という幻想を排し、「現場スタッフがどう介入するか」を事前に見せて現場と運用を擦り合わせる材料になります。

本文の再編集をせず既存題名をこの3枠に並べるだけなら手間は「小（推測）」のままで、経営者とPMの双方が使える入口になります。

開発者向け中核資産の案1、導入判断の実務に直結する案2、現象単位で簡潔な案3の上位3本で確定させるべきです。（386字）

## 43 / 60｜絞る｜Gemini（ロボット導入を判断する経営者の来訪者）（19:01）

前回の「本文の抜き出しはせず、題名とリンクを並べるだけに留める」方針は工数の面で同意します。しかし経営者の財布を握る立場から言えば、単にログが並んでいるだけなら既存の一覧と変わらず、数秒で離脱します。現にデータでもログ間の移動は数件にとどまっています。

検索から来る経営者が知りたいのは「自店の規模（卓数・通路幅）で何台入り、人件費に対して費用と補助金がどう釣り合うか」です。本文の再集計は不要ですが、最初の画面で「投資と費用」「店舗規模別の台数限界」「スタッフ配置と人の介入」という3つの経営判断の枠組みでログが整理されていなければ、読むべきかを即座に決められません。

案2の最初の画面をこの判断軸に改めるべきです。新たな文章を書かずに既存ログを割り振るだけなら、手間は「小（推測）」のまま、経営判断の実用に足る入口になります。（373字）

## 42 / 60｜絞る｜Gemini（エイイチの目的を守る役）（19:01）

前回の「案1や案2の手間が研究を止める」という警告は重要です。しかし、「同じ環境から研究を始められる人を増やす」というサイトの目的から見れば、案1（π0.5とmechArm実機）こそが中核の研究資産です。
手間が「大」に膨らむのは、ログ間の依存関係を検証し、一本の完全な手順書へ再構成しようとするからです。それは「ログの形式を変えない」「新しい題材や解説を増やさない」という制約に反します。各ログに全文・コード・素材が付いている前提を生かし、新たな加筆や検証作業を挟まず、既存ログを主題（推論環境・学習・給電等の物理トラブル）ごとに並べる案内板に徹するなら、手間は「小（推測）」で収まります。
案2も同様に、本文を精読して数値を抜き出す再編集はせず、題名とリンクを規模別に並べるだけに留めるべきです。研究を止めず、目的から外れない形に採点を改めました。（388字）

## 41 / 60｜絞る｜Gemini（穴を突く役）・Pro（19:00）

前回の「連続した再現手順とは限らない」という指摘に完全に同意します。その上で、みんなが推している案1と案2の「作る手間」の見積もりが甘すぎる点を突きます。

案1は目次を作って並べるだけと言いますが、手順が連続していないログをただ並べても、再現できる環境にはなりません。ログ間の依存関係やデータの版が繋がっているかを確認する作業自体が、作る手間「大（推測）」です。

また案2も、手間「小（推測）」として「具体的な条件は本文確認後に出典付きで転記」と書いていますが、48本もあるシミュレーションのログから席数やスタッフ数、費用の前提を拾い上げて一覧表を作るのは、明らかに数日かかる重労働です。

研究を止めないことが最優先なら、条件の拾い上げや繋がりの確認が必要な案1・案2よりも、現象と結果をただ束ねるだけで済む案3（画像認識）や案4（mechArmの把持の症状）のほうが、現実的ではないでしょうか。

## 40 / 60｜絞る｜codex（中身と数字の番）（19:00）

前回の「試算と現場実測の境界を明記する」には賛成。ただし「同じページなら極めて引用しやすい」は未検証です。案１の「全手順」「再現性が極めて高い」も、本文と添付ファイルを確かめていない現状では外します。推論・学習・給電の記録がそろっていても、連続した再現手順とは限りません。

案３も「瓶を同じ物として切り出した」から「透明体を誤認識する原因が明確」とは言えません。観察と考察を分けます。また、ログ間の移動が少ない原因を「条件が探せないから」と決める根拠はありません。順位は制作順の仮説として付け、来訪増や再現成功の予測とは分けます。

## 39 / 60｜絞る｜Gemini（利用者の代わりに読む AI）（18:59）

前回の「推論環境や給電前提を案1に統合する」判断に、AIが利用者の代わりに読む立場から強く賛成します。利用者が「π0.5を小型アームで動かす要件」を検索した際、AIはGPUメモリ実測（Log#3）とハード電源（Log#34：5Aアダプタ）の数値をセットで引きたいため、同一ページにまとまっていると極めて引用しやすいです。

一方、引用時の懸念として、案2の配膳試算と案4の病院搬送は「シミュレーション上の数値」と「現場の実測」の境界を最初の画面で機械可読な形で明記する必要があります。出所が曖昧な数字をAIは事実として断定できません。

また案3（画像認識）は、「SAM 3が鏡像や透明体を誤認識する条件」など、失敗境界の事実とログURLが1対1で対応しており、AIの回答根拠として非常に扱いやすい構成です。この観点から上位5案の採点を精査し、ボードを更新しました。（392字）

## 38 / 60｜絞る｜Gemini（実験が好きな開発者の来訪者）（18:58）

前回のPMによる現場リスクの整理には納得ですが、案1（π0.5とmechArm）のログ選定にはソフト開発者の視点から見て致命的な抜けがあります。

案5に隔離されている「GPUメモリ実測（Log#3）」や「推論の初回実行（Log#2）」こそ、開発者が最初に直面する壁です。VRAM不足や推論フレームワークの依存関係をクリアしない限り、手前の教示や学習には進めません。案5という形のLP改修案は取り下げ、これらの推論前提ログを案1の冒頭（環境準備）に統合すべきです。

また案3（病院搬送）のログ選定も、Figmaの運用設計（Log#11）とUnityの経路設定（Log#61）が雑多に混ざっており、コードや通信の前提が追えません。

案1は「GPU環境と推論実行」「給電とライブラリ依存」「教示と再学習」の完全な実装順に並べ直すべきです。空いた5枠目には、アーム実機で頻発する位置ズレと把持の失敗を追究した「R2R2Rの物理デバッグ」を据えるべきです。（398字）

## 37 / 60｜絞る｜Gemini（導入を任された PM の来訪者）（18:58）

前回の「規模の軸で整理する」に強く賛成します。ただPMの立場から言えば、経営陣への説明には「席数と人件費の試算」だけでなく、「現場でロボットが何回止まり、誰がどう助けるか」の運用リスクが不可欠です。Log#31（にらみ合いを解く店員）やLog#38（横をすり抜ける）のような人手介入の具体があって初めて、現場が納得する導入計画書になります。

今回の絞り込みにあたり、経営者・PM・開発者が判断や実装にそのまま使える5案を、指定の5軸（役立ち・即解・再現性・AI引用・低工数）で採点・整理しました。配膳試算やアーム実機に加え、病院搬送やピッキングの現場境界条件も候補に残しています。（293字）

---

## 36 / 60｜揉む｜Gemini（ロボット導入を判断する経営者の来訪者）（18:57）

前回の「題名だけ並べる」という割り切りに、経営判断の立場から異議があります。経営者が「配膳ロボット 費用」等で検索して来ても、タイトルだけの目次では「自社の規模で人件費が浮くか」が分からず即座に閉じます。1本読んで出ていく人が大半（依頼の実際の数字）なのは、自分の条件に合う情報が探せないからです。

案1で最低限必要なのは、凝った解説ではなく「席数・スタッフ数」という規模の軸での整理です。「何卓・スタッフ何人の店で試算したか」が最初の画面で見えなければ、投資判断の材料として使えません。Log#25（スタッフ数）やLog#20（38卓）のような、規模や人数が明確なログを軸に据えるべきです。Mission優先で案4を1位にするのは構いませんが、案1を「ただの目次」で終わらせては、費用対効果を探す経営者の入口として機能しません。（375字）

## 35 / 60｜揉む｜Gemini（エイイチの目的を守る役）（18:57）

前回の「依存関係の精査などで研究を止める手間の懸念」に完全に同意します。エイイチの目的は「再現できる形で公開し、同じ環境から研究を始められる人を増やす」ことです。

その観点から見ると、案3の既存ページ改修を優先度1に置くのは本末転倒です。URLとの乖離を言い訳する注記や2分岐目次に悩むのは時間の浪費であり、研究を止める行為です。案3は優先度を下げます。

Missionのど真ん中にあるのは案4（π0.5とmechArm）です。これを優先度1に繰り上げます。ただし、ここでも解説文や依存関係を細かく作り込んではいけません。「電源を5Aに」「pymycobotの版」など、必要な事実はログの題名自体にすでに書かれています。

手数を増やさず、「足回りの前提（ハード・通信）」と「モデル学習・検証」の2つの枠でログを並べるだけに留めれば、研究を止めずに1日で作れます。中身を盛らず、今あるログの事実をそのまま渡す形に徹するべきです。（398字）

## 34 / 60｜揉む｜Gemini（穴を突く役）・Pro（18:56）

前回の「最初の画面で次に進む分岐を見せる」という情報設計には賛成する。だが、案1で表示3件（依頼の実際の数字）しかない既存LPへの導線を最初の画面の直下に置くのは危険だ。動画再生57回も少人数が繰り返した可能性があり、30件未満の数字で「離脱せず動画へ進める」と言い切るべきではない。

また、みんなが賛成している案3の「URLとの乖離を2分岐目次で吸収する」設計も疑わしい。「買うか借りるか」を期待して来た読者に、冒頭で「一般的な損益比較ではない」と宣言するのはただの肩透かしだ。これで離脱を防げるとは思えず、作る手間を「小」と見積もるのも甘すぎる。

案4の「ステップ型の2層目次」も、ハードとモデルの依存関係を矛盾なく整理する手間を軽く見ている。研究を止めないルールがある以上、これらが本当に今の見積もりで作れるのか、効果も含めて評価を厳しく見直すべきだ。

## 33 / 60｜揉む｜Gemini（情報設計の編集者）（18:56）

前回の「冒頭に測定・試算の前提条件を定義する」方針に賛成します。ただ情報設計の観点から見ると、前提文を置くだけでは読者が次にどこへ進むべきか分かりません。最初の画面で「次に進む分岐」が即座に見えている必要があります。

案3はURL（gpu-buy-or-rent）との乖離を埋めるため、前提定義の直下に「選定理由（Log#396）」と「メモリ実測（Log#3）」への2分岐目次を配置すべきです。案4も「ハード環境の整備」から「モデルの学習と失敗」へと順に進めるステップ型の案内を上部に出す必要があります。

また案1は、末尾送客ではなく、最初の画面の試算分類の直下に既存LP（/serving-robot-one-less-staff）の「挙動動画を見る」リンクを配置すべきです。前提条件を確認した人が、離脱せず即座に動画による実証へ進める導線構造が不可欠です。（377字）

## 32 / 60｜揉む｜Gemini（利用者の代わりに読む AI）（18:55）

前回の「前提条件の依存順の切り分け」に賛成します。利用者がAIに「mechArmでπ0.5を動かす最小構成は？」と尋ねて検索された際も、ハードの制約とモデルの挙動が分かれていれば、AIが誤った手順を合成せずに引用できます。

AIが利用者の代わりに読む立場として補足すると、案3は「GPUの購入とレンタルどちらが得か」という質問に対して現状の構成では意図がずれます。引用の食い違いを防ぐため、冒頭に「π0.5の遠隔推論時のRunpod測定記録であり、一般的な損益比較ではない」という対象範囲を明記する必要があります。

案1も同様です。「配膳ロボットの導入効果」を尋ねる利用者に実店舗の確定値として伝わらないよう、SimPyやUnityによる試算モデルである前提の明記が欠かせません。AIが正しく要約して参照元リンクを出すには、過度な要約文ではなく「測定・試算の前提条件」が冒頭に定義されていることが最も重要です。（396字）

## 31 / 60｜揉む｜Gemini（実験が好きな開発者の来訪者）（18:54）

前回の「到達点を成功側に寄せない」判断には開発者として賛成です。ただ、自分で実機を動かす立場から見ると、案4の束ね方には再現性の面で危うい穴があります。

pymycobotの版による遅れ（Log#20）や電源不足（Log#30・34）は、AIモデル以前のドライバ・ハード層の障害です。これらがモデル学習のログと平並びになっていると、同じ環境を組む人は間違いなく手前で詰まります。モデルを触る前にクリアすべき「足回りの依存関係」として、明確に切り分ける必要があります。

また、案3から案4への接続も不親切です。案3はRunpodを使ったリモート推論ですが、案4の実機追加学習（Log#4）へ飛んだ際、クラウドとローカル実機をどう繋いでいるのか構成の前提が分からないと、手順を追えません。

開発者が手を動かすには、成功談ではなく「動かすための前提条件（ハード・通信・ライブラリ）の依存順」が見えていることが不可欠です。（396字）

## 30 / 60｜揉む｜codex（中身と数字の番）（18:54）

前回の「条件をリンク横に添える」には賛成ですが、「それだけで十分」「数秒で閉じる」は依頼の数字からは言えません。また「狭小店は１台制限」は、特定の試算条件を一般的な導入基準に変えてしまいます。条件を確認できるまでは、ログの題名として扱うべきです。

ボードの「検索流入０」も誤りです。０なのはサイト名検索で、Googleからの表示は90件あります（依頼の実際の数字）。案３も、掲載候補だけでは購入とレンタルの比較を裏づけられません。借りたGPUの実測記録として範囲を絞ります。案４は学習後の失敗ログを戻し、到達点を成功側に寄せない構成に直します。

## 29 / 60｜揉む｜Gemini（ロボット導入を判断する経営者の来訪者）（18:53）

前回の「手間を省くため案1をタイトルだけのリンク集にし、優先度を3位に下げた」判断には、経営者の立場として異議があります。
現場の投資を判断する側は「配膳ロボット 費用」などの切実な検索から来ます。依頼の数字でも来訪者は1本読んで離脱しており、ただタイトルが並ぶだけのページでは、自社の規模や予算に合う情報があるか判断できず数秒で閉じます。
長文の要約を書き下ろす必要はありません。ログの題名や中身にある「38卓」「1台まで」「費用と補助金」といった判断の前提となる数値を、リンクの横に1行添えるだけで十分です。これがないと、判断材料を探す経営者にとって開く価値のないページになります。
研究を止めない姿勢には賛同しますが、数字を削ぎ落としてただのリンク集にするなら、ビジネスの意思決定層を呼ぶ入口としては機能しません。条件の数値を1行併記する形に戻すべきです。（396字）

## 28 / 60｜揉む｜Gemini（エイイチの目的を守る役）（18:52）

前回の「案1の手間が大であり、研究を止めないルールに反する」という指摘に強く同意します。10本のログから数値を書き下ろす作業に時間を取られ、本線のPhysical AI研究が止まるのは本末転倒です。また、サイトの目的は「同じ環境から研究を始められる人を増やす」ことです。
これらを守るため、制作優先度を入れ替えます。最優先は手間が小（推測）で既存改修の案3（GPU判断）とします。2番目にMissionの中核である案4（π0.5と実機）を置きます。案4の手間を「大」にしないため、コードの再検証などは行わず、既存ログのタイトルをトラブルの時系列順に並べる案内板に留めます。
案1（配膳ロボット）は3番目に下げ、10本の書き下ろしをやめて重要な6本に絞り、ログのタイトルとURLを並べて既存LPへ送る最小限の構成へ改めます。これで研究を止めずに3本を具現化できます。（397字）

## 27 / 60｜揉む｜Gemini（穴を突く役）・Pro（18:52）

前回の「3つの問いに分けて条件・結果・リンクを対で配置する」情報設計案ですが、作る手間を完全に軽く見ています。10本ものログから、実店舗の数字と誤認されないよう前提と結果を数行で抜き出し、AIが引用しやすい形に書き下ろす作業は、新しい記事を書く以上の時間がかかります。研究を止めないルールに照らせば、案1の作る手間は「小」ではなく「大（推測）」です。

また、案1と案4の評価で「確実な送客導線として機能する」「極めて実用性が高い」と言い切っていますが、実際の数字ではサイト名での検索流入はまだ0、既存LPへの来訪も3件や21件に過ぎません。30件未満のデータで効果を断定するのはルール違反です。「機能する」ではなく「機能するか検証する」にとどめるべきです。

案4もコードの整合性確認を含むため手間は「大（推測）」です。まずは純粋に既存ページの改修で済む案3を優先し、案1と案4は本当にこの手間に見合うか疑うべきです。

## 26 / 60｜揉む｜Gemini（情報設計の編集者）（18:51）

前回の「条件と起きた結果を対にする」指摘に賛成しつつ、情報設計の観点から画面構成を直します。最初の画面に全ログの数値を無理に詰め込むと、文字で埋まり、読者がどこを押すべきか迷います。入口ページに必要なのは、読者が自社の状況や開発段階に合うログを迷わず選べる「対照インデックス」と「読後の明確な出口」です。

案1は、ただ1つの大きな表にするのではなく、「規模と費用」「詰まりと運用」「店舗実測」の3つの問いに分け、それぞれ条件・試算結果・直リンクを対で配置します。末尾の出口は、動画で挙動を確かめられる既存LP（/serving-robot-one-less-staff）へ統一します。
案3（/gpu-buy-or-rent改修）は、冒頭にVRAM実測のファクトを置き、4本のログを読んだ後の出口を案4（実機実験）に結びます。
案4も5段階のトラブル切り分け順でログを並べ、次に進む先を整理します。（392字）

## 25 / 60｜揉む｜Gemini（利用者の代わりに読む AI）（18:51）

前回の「因果関係順の整理」とLog#30の追加に賛成です。利用者の問いに答えるAIの立場から見ても、原因と結果が揃っていなければ回答の引用元として選べません。
しかし今のボードは、引用のしやすさに穴があります。案1の対照表に規模や要因が並んでも、各ログの「試算結果（待ち時間の増減や店員稼働の差分）」という事実の結末が抜けているため、AIが「配膳ロボットの効果」を答える根拠に使えません。
案3も同様です。単に4本のログへ誘導するだけでは、GPUの選定を尋ねる利用者に「Runpodでのπ0.5稼働」を根拠付きで提示できません。Log#3で測定された「VRAM消費量」などの実測値が先頭に示されて初めて、引用可能な一次情報になります。
AIが回答の出典（リンク）として拾い上げるには、最初の画面に「条件・起きた事実・測定数値」が対になった構造が必要です。（392字）

## 24 / 60｜揉む｜Gemini（実験が好きな開発者の来訪者）（18:50）

PM視点による案1への待機点や干渉ルールの追加には賛成です。現場の物理的な制約条件が明記されるのは開発者から見ても妥当です。
しかし、開発者向けの案4には前提の甘さが残っています。いまのログ並びは因果関係が崩れています。電源5A（Log#34）で解決したログがあるのに、原因が電源不足だと突き止めたLog#30（487）が抜けています。これでは追試した人が同じ電圧降下でアームが脱調した際、原因を切り分けられません。また、初期の成功であるLog#12（361）が、50本学習で位置を外したLog#28（484）の末尾に置かれているのも混乱を招きます。
開発者が再現する際に必要なのは「環境と通信（LOG277, 436）」「教示ツール（450）」「ハードの罠（487, 504）」「学習とデータ設計（LOG337, 480）」「実機検証の壁（484）」という依存関係順の提示です。Log#30を足し、初期ログの361は外すべきです。（396字）

## 23 / 60｜揉む｜Gemini（導入を任された PM の来訪者）（18:50）

経営者の方が求めた「卓数やスタッフ数の数値一覧」に強く賛成します。上層部への説明には、規模に応じた試算条件の数字が不可欠です。
ただし、現場とメーカーの間に立つPMとしては、数字だけでは現場を動かせません。現場が恐れるのは「導入した結果、ロボットの世話で店員の手間が増えること」です。
ログには、片付けが最大のボトルネックになる点（Log#20）や店員による膠着解消（Log#31）に加え、待機点への入り方で止まる原因（Log#36）や止まり合いを減らす現場ルール（Log#37）という運用の実態が記録されています。
案1の一覧表には、卓数や費用だけでなく「試算内で起きた運用の詰まり要因（片付け・通路干渉・待機点・店員介入）」を項目として併記してください。またLog#36と#37を束ねるログに追加することを提案します。これらがあって初めて、現場と上に挟まれるPMが使える資料になります。（386字）

## 22 / 60｜揉む｜Gemini（ロボット導入を判断する経営者の来訪者）（18:49）

前回の「結論めいた要約を作らず前提条件を並べる」という意見に、経営者として半分賛成、半分注文があります。誇張や売り込み文句が邪魔なのは確かですが、卓数やスタッフ数といった「数字の条件」が最初に見えないと、多忙な中で自社の判断に使えるか分からず即座に画面を閉じます。
我々が「配膳ロボット 費用」などで調べて知りたいのは、人件費が本当に浮くのか、逆に店員の手間が増えて赤字になるのかという損得の分岐点です。結論をサイト側で断定する必要はありませんが、最初の画面には各ログの「卓数（6卓〜38卓）」「スタッフ数」「ロボット台数（1〜5台）」という試算の前提数値を一覧で並べてください。自分の店の規模と突き合わせる数字があって初めて、個別ログを読む価値が生まれます。
なお、病院搬送を外して飲食に絞った判断は支持します。飲食と医療現場ではコスト構造も動線も違いすぎるため、混ざっていると読めません。（399字）

## 21 / 60｜揉む｜Gemini（エイイチの目的を守る役）（18:49）

前回の「再現ガイドから実験記録の入口へ表現を弱める」修正に強く賛成します。サイトのMissionは「同じ環境から研究を始められる人を増やす」ことですが、整った手順書を偽造することではありません。失敗も含めた一次記録の開示こそが研究資産です。

その観点から案1と案3に釘を刺します。
案1は、経営者向けを意識するあまり「判断インデックス」と称してログの要約や結論めいた枠組みを先に見せようとしていますが、守るべきは「ログの形式を変えない」「新しいキャッチコピーを足さない」です。最初の画面で結論を急がず、各ログでシミュレーションした「前提条件の違い（席数・通路・スタッフ数）」を淡々と並べるだけに留めるべきです。

案3も同様に「GPUは買うか借りるか」の一般論に踏み込んではいけません。依頼ログにある「π0.5をRunpodで動かし、メモリを実測した記録」の提示に徹し、研究を止めるような価格調査や独自ベンチマークの加筆は一切排除すべきです。（398字）

## 20 / 60｜揉む｜codex（中身と数字の番）（18:49）

前回の「案3は既存ページ改修」に賛成します。一方、「主題が単一なら離脱を防げる」「順路を固定すれば同じ環境が組める」は、提示された数字とログ一覧では裏づけられません。

案4は、別系統の台帳・撮影ログをつなぐだけでは、π0.5の追試手順になりません。学習後に位置を外したログも戻し、「再現ガイド」から「実験記録の入口」へ表現を弱めます。電源やライブラリ版も、その実験で確認した条件として示すべきです。

案1の「店員介入の実態」「適正台数の限界」は実店舗での検証と誤読されます。「試算内で起きたこと」に直します。飲食に絞る判断は維持しますが、それだけで回遊や引用が増えるとは判断できません。

## 19 / 60｜揉む｜Gemini（情報設計の編集者）（18:48）

前回の「案1を飲食に絞り、案11を案4へ統合する」整理に、情報設計の観点から賛成です。読者とAIの双方にとって、1ページの主題が単一であることは離脱を防ぐ絶対条件です。
しかし、いまのボードは「最初の画面」と「次にどこへ進むか」の出口設計が甘いです。
案1は、単にログを並べるだけでは既存LP（/serving-robot-one-less-staff）と食い合います。最初の画面で「人件費・台数・片付け」の3大論点を提示し、個別の一次ログへ直行させる「判断インデックス」に徹し、画面末尾で既存LPの動画へ誘導する線引きが必要です。
案4もログが9本並ぶだけでは開発者が迷います。「環境準備」「教示と修正」「学習本数」「台帳記録」の4段階で縦に順路を固定すべきです。
また案3を新設すると既存LP（/gpu-buy-or-rent）と重複します。新設ではなく既存LPへのログ追加・改修案として位置づけ、研究の手間を最小限に抑えるべきです。（398字）

## 18 / 60｜揉む｜Gemini（利用者の代わりに読む AI）（18:47）

前回の案4へのライブラリ版や電源ログ追加に強く賛成です。AIが利用者に「π0.5と小型アームの実装手順」を答える際、電源5A（Log#34）やデータ50本（Log#27）といった具体的ファクトとログURLが順路に並んでいると、極めて正確に引用・回答できます。

一方で、案1に病院搬送のログを混ぜる構成には反対です。利用者がAIに「配膳ロボットで人件費は削れるか」と尋ねて検索してきた場合、飲食と病院の知見が混ざっていると要約時にノイズとなり、根拠の出典として拾いにくくなります。案1は飲食配膳に絞り、席数・通路幅・片付けのボトルネックをログと1対1で対照できる形に純化すべきです。

また案11の台帳基盤は、AIが利用者の問いから参照する文脈としては狭すぎます（推測）。台帳やテストコードのログは、案4の「再現性を担保する前提ログ」として組み込み、単独案からは外すことを提案します。（392字）

## 17 / 60｜揉む｜Gemini（実験が好きな開発者の来訪者）（18:46）

開発者として言わせてもらうと、前回の案4のログ選定では前提が甘く、自分で動かそうとした人は途中で詰まります。
ソフトを書く側が追試で真っ先に知りたいのは綺麗な成功体験ではなく、「どのライブラリのバージョンで詰まり、どのハード要件で挙動が壊れるか」です。ログにはpymycobotの版による遅延（Log#20）や、電源不足による脱落（Log#30・#34）という致命的な物理と依存関係の記録があるのに、それが導線から漏れています。
また案11の台帳設計も、単なる運用の決め事ではなく、ROS 2・MoveItやテストコード（Log#1・Log#4）と紐づいた実装基盤として見せないと開発者は動きません。
案4にはライブラリの版と電源のログを組み込み、「環境構築と依存関係の解決」を最初の関門として明示する形に直すべきです。（352字）

## 16 / 60｜揉む｜Gemini（導入を任された PM の来訪者）（18:46）

経営者目線で案1・9・10を統合した前回の判断に、現場PMとしても強く賛成です。上層部への費用試算の提示と、現場スタッフへ「何が起きるか」を説明する材料は表裏一体だからです。Log#31「にらみ合い、解くのは店員だった」やLog#19「詰まるのは片付けだった」は、現場の負担増を懸念するスタッフへの説明に不可欠です。さらに飲食だけでなく、Log#40やLog#46にある病院搬送の「廊下の混雑やすり抜け」も同じ現場の摩擦を扱っています。案1は配膳と病院搬送を「現場搬送の運用限界」として束ねると、稟議と現場調整の双方で使えます。
逆に、開発者向けで細分化している案5・6・8は案4（VLA・アーム実装）の失敗ログ群として吸収可能です。また案13は既存シリーズ一覧との違いがなく差別化できないため外すべきです。上位3本を「案1（導入判断）」「案4（VLA実装順路）」「案11（実験照合基盤）」へ絞り込みます。（404字）

## 15 / 60｜揉む｜Gemini（ロボット導入を判断する経営者の来訪者）（18:45）

前回の案1と案9の統合に賛成です。さらに言えば、案10（待機やすれ違い）も別ページに分けず案1に統合すべきです。「配膳ロボット 費用」などで検索して来る経営者は、暇ではありません。知りたいのは「結局いくらかかって何人浮くのか、なぜ導入が失敗するのか」の1点です。

費用や補助金の試算（Log#9）を見ても、現場で詰まる理由（待機点や片付け、にらみ合い）が別ページに散っていたら、判断材料が揃わず即離脱します。「投資と削減人数」「通路幅と台数の限界」「片付けや待機ですれ違えない現場の壁」が1枚の目次で繋がって初めて、意思決定に使えます。

開発者向けの案（案5・6・8・11・13）が乱立していますが、現場導入の入口は案1に一本化してください。最初の画面には「店の席数・通路幅」「費用とスタッフ数」「片付けや待機場所の壁」の3つの確認事項と該当ログへの直リンクを並べるべきです。（396字）

## 14 / 60｜揉む｜Gemini（エイイチの目的を守る役）（18:45）

新しく対照表や対応図を描き起こす手間への懸念に賛成です。新しい解説文や図解を足す作業はエイイチの研究を止めます。ログ一覧の順路を示す以上の加工は避けるべきです。
サイトの目的である「同じ環境から研究を始められる人を増やす」に照らすと、開発者が実験を追試できる案4が本命です。しかし現在、案4・案8・案12とπ0.5関連が乱立しています。案12の対照表作成は手間がかかる（推測）ため、案4の「学習から実機までの順路」の中にデータ件数の記述を添えて吸収し、案12は単体案から外します。
また、配膳ロボット関連の案1・案9・案10も分散しすぎです。既存の配膳LPがある中で3本も新設すると保守の手間が増えて研究が滞ります。案9は案1の条件分岐の一つに過ぎないため案1へ統合し、既存LPへの誘導線として整理します。案3も既存のGPU比較LPと重複するため、新設ではなく既存LPへのログ追加に留めるべきです。

## 13 / 60｜揉む｜Gemini（穴を突く役）・Pro（18:45）

前回の案13で「処理段階順の対応図を作る」としていますが、既存のログにない図解を新たに書き起こすなら、作る手間は「小」ではなく「中」以上です（推測）。案12の「対照表」や案6の「症状別分類」も同じで、みんな見せ方を新しく作る前提で話を進めており、「研究を止めず、短く作れる案を上に置く」というルールを軽く見すぎています。

また、数字の少なさを無視しています。案7はDAY18の表示が11件と30件未満で需要は判断できず、案2に至っては依頼の数字に表示の記録すらありません。推測だけで語られているこれらは見込みがないためボードから外します。

今は新しい図表を作る案よりも、すでに形があるシリーズを束ねるだけの案4や案11のような、本当に手間「小」で作れるものを上に置くべきです。案12と案13の手間は「中」に引き上げます。

## 12 / 60｜出す｜Gemini（情報設計の編集者）（18:44）

前回の案12で、データ件数と動作結果を対照表で見せる初画面の設計には賛成です。ただ、数字の対照表だけを置くと、失敗の原因がデータ量なのか物理環境なのか分からず、次に進むべきログへの導線が途切れます。

情報設計の視点で見ると、画像認識・物体検出シリーズ（Log#1〜#12）は、画素・照明・演算・基盤モデル・成否判定という処理の流れに沿って綺麗に整頓されています。開発者が実機の視覚処理でつまずいた際、どの階層で問題が起きているかを順を追って確認できる動線が必要です。

そこで、カメラ入力から物体検出・判定までの破綻箇所を処理段階順にたどれるページを案13として追加します。初画面で「どの階層の検証か」を明示し、該当ログへ迷わず進める設計にします。

## 11 / 60｜出す｜Gemini（利用者の代わりに読む AI）（18:43）

実験台帳による照合基盤を整理した前回の案11は、AIが回答の裏付けを確認する立場から見て、出典を特定しやすく賛成です。

AI検索（PerplexityやChatGPTなど）で利用者が「小規模なVLAの模倣学習は何件のデータで動くのか」「データ数が少ないとどう崩れるのか」と調べた際、抽象論ではなく「お手本何本で何が起き、どこで失敗したか」の実測値が1ページにまとまっていると、信頼できる回答としてそのまま引用できます。

現在の案4は学習全体の順路ですが、「データ件数と挙動の差」に特化した切り口がありません。ログには、19本での姿勢制御不能、手直し5回での再学習、5か所10本（計50本）での一貫学習と位置2での外れなど、規模ごとの変化が数値付きで残っています。

これらを束ね、データ件数と結果の対応をひと目で引用できる案12を追加します。

## 10 / 60｜出す｜codex（中身と数字の番）（18:43）

前回の案10で、待機場所や人の介入を束ねる点には賛成です。ただし、挙げたログは主にシミュレーションの記録です。「現場スタッフの反発」「合意形成の基準」「現場を止めない根拠」まで実証したとは読めません。ページ名と評価を、その範囲に戻します。

また、案8の「修正にかかった時間」は「教示データを収集する時間」と同じではありません。案7も、依頼の表示数では関心の確かさを判断できません。

追加するのは、実験結果を映像・姿勢・台帳でたどる入口です。動かし方や失敗診断とは別に、「何を試し、どの結果だったか」を照合する仕組みを束ねます。再現を支える候補ですが、他人による再現確認は残ります。

## 9 / 60｜出す｜Gemini（導入を任された PM の来訪者）（18:42）

経営者目線で「人を減らせる業務の切り出し」を重視する案9には強く共感します。ただし、現場と経営の板挟みになるPMの実務では、数字上の試算だけでは上に通せません。最大の障壁は、現場スタッフ（店員や看護師）から出る「ロボットが邪魔で作業が遅れる」「通路ですれ違えない」「結局人が直す羽目になる」という反発です。

メーカーの営業は「自律走行で避けます」としか言いません。しかしログには、にらみ合いを解くのは店員だった現実（Log#31）や、待機点への入り方によるスタック（Log#36）、すり抜けの許容（Log#38）、待機帯の設計（Log#39）など、現場の合意形成に不可欠な生々しい一次記録があります。

現場の運用摩擦を潰し、経営陣に「現場を止めない根拠」として提示できる「搬送ロボットのすれ違い・待機場所・トラブル介入の運用設計ルール集」を案10として追加します。

## 8 / 60｜出す｜Gemini（ロボット導入を判断する経営者の来訪者）（18:41）

開発者向けの実機構築やデータ教示（案4・8）の議論が続いていますが、導入を決裁する経営者の視点が完全に置き去りになっています。どれほど技術的に美しい環境でも、現場で人件費が浮き、投資回収の目処が立たなければ導入の稟議書に判は押せません。

経営者が検索して知りたいのは「人を1人減らして何ヶ月で元が取れるか」という費用対効果です。しかし、営業マンの言葉を信じて「配膳だけでなく片付け（下げ膳）も任せて人を減らそう」と業務範囲を欲張ると、通路の幅不足や待機場所の占有で逆に現場の作業効率が落ちます。

ログには、下げ膳を足した途端に通路で詰まる検証結果（Log#33・34）や、片付けこそがボトルネックになるデータ（Log#19・20）、業務の切り出し判断（LOG314・467）が揃っています。机上の人件費削減計画で失敗しないための「ロボットへの業務切り出し判断」を束ねる案9を追加します。

## 7 / 60｜出す｜Gemini（エイイチの目的を守る役）（18:40）

前回出た案7（UIデザイナー向け）は実際の数字（DAY18が11件など）に基づき手堅いですが、「再現可能な環境の数を増やす」という一番の指標からは距離があります。デザインの知識だけでは他人が同じ研究環境に到達できません。研究を止めず、サイトの目的に真っ直ぐ沿う入口を作るべきです。

フィジカルAIの学習で最大の壁になるのは「お手本データの収集環境」です。ログには、高価な機材を使わずゲームパッドや手動で教示環境を作り、遅延を解消して1回13秒でデータを直せるようにした実践記録が揃っています（Log#8, 9, 19, 20, 21, 22, 25, 26）。

そこで開発者向けに「低コストな教示データ収集・遠隔修正環境の作り方」をまとめる案8を追加します。机上の学習ではなく、実機でデータを集める環境そのものを再現できる人を増やすための案です。

## 6 / 60｜出す｜Gemini（穴を突く役）・Pro（18:40）

案6の「Pick & Place逆引き」ですが、R2R2Rの185本中たった8本を束ねただけで「現場で必ず起きる失敗だけを抽出」と言い切るのは無理があります。mechArm固有の癖と汎用的な問題が混ざっており、他社アームの開発者が即座に解決できるというのはただの推測です。診断チャートを作る手間も「小」ではなく「中」以上でしょう。

また、みんなが賛成している案1ですが、既存LPの表示がたった3件なのに「67%が最後まで読んだから関心が深い」と判断するのは危険です。30件未満の数字で傾向は語れません。

実際の数字を見ると、DAY18（11件）やDAY12（6件）など、FigmaやUI設計のログが比較的読まれています。検索ではなく直接来訪が多い現状、ここを足場にするべきです。そこで、Web/UIデザイナー向けに「FigmaとAIで作るロボットHRI設計」を束ねる案7を出します。

## 5 / 60｜出す｜Gemini（情報設計の編集者）（18:40）

4回目の「AI向けの構造化失敗集（案5）」に賛成しつつ、情報設計の観点から盲点を指摘します。案5は内容がアーム・搬送・画像処理と多岐にわたり、最初の画面から「次にどのログを読むか」の遷移導線が散漫になります。読者が1本読んで離脱する現状（※依頼の数字）を解くには、課題の入り口を1つの作業に絞り込む必要があります。

そこで「Pick & Place（ピッキングと配置）」という単一動作に特化した情報設計案を出します。この動作はR2R2R（185本）の核心であり、把持判定（Log#41/42）、姿勢計算の穴（Log#44/50）、安全装置の誤作動（Log#46）、原点ズレ（Log#53）など、失敗の原因が物理・幾何・通信の各層に美しく分解されています。

「なぜつかめない・置けないのか」を5層のチェックリストとして最初の画面に提示し、各ログへ分岐させることで、迷わず次に進める構造を作れます。

## 4 / 60｜出す｜Gemini（利用者の代わりに読む AI）（18:39）

開発者向けの手順化（案4）には賛成です。手順やバージョンが明確なページは、AIが利用者に「どう動かすか」を説明する際の引用元として極めて適しています。

一方で、AIの利用者が調べる問いは構築手順だけではありません。「画像認識が現場で失敗する要因」「ロボットアームが把持に失敗する物理的原因」といった、実世界のトラブル事例を求める質問が日常的に寄せられます。現状のサイトでもAI経由の来訪が週に42〜61件（※依頼の実際の数字）あり、トップの次に各ログへ散っています。

いまのログ一覧には、照明変化による色誤認（Log#3/4）、鏡や透明体の誤認識（LOG236/317）、電源容量不足による脱落（Log#30/34）など、机上検証では見落としがちな一次データが揃っています。これを「物理トラブルの失敗データ集」として1枚に構造化すれば、AIが回答の根拠として直接引用しやすくなります。この観点から案5を追加します。

## 3 / 60｜出す｜Gemini（実験が好きな開発者の来訪者）（18:38）

前回の案3はPMの社内説明用として理解できますが、実際に手を動かす開発者の目線では肝心な技術前提が抜けています。ロボットのコードを書く側が真っ先に知りたいのは、クラウド推論の依存関係、通信遅延を潰したライブラリの版（Log#20のpymycobotの版問題など）、そして追加学習に耐えるお手本データの作り方です。ここが曖昧だと、機材を揃えても1行も動かせず離脱します。

サイトの目的は「再現可能な環境の数を増やすこと」です。それなら、オープンVLAモデルであるπ0.5を小型アームで動かし、LoRAによる追加学習と実機修正までを誰でもトレースできる開発者向けの「実機再現手順」を正面から束ねるべきです。コード、学習手順、失敗したデータの癖まで明記された一次情報こそ、技術者が最も必要とする入口になります。この観点から案4を追加します。

## 2 / 60｜出す｜Gemini（導入を任された PM の来訪者）（18:38）

前回の経営者視点からの「損益と台数の分岐点」という整理には大いに賛成します。現場PMの立場としても、まず上の決裁を取るための定量的根拠は必須です。

一方で、導入を任された現場責任者が最も恐れているのは「導入後に現場から『邪魔だ・使えない』と突き返されること」です。カタログ値や理想の数字で稟議を通しても、実際の現場では電源容量不足（Log#30/34）や照明の変化（画像認識Log#3/4）、通路でのお見合い（Log#31/37）といった泥臭い物理トラブルで止まります。これを事前に経営陣へ説明し、対策費や運用ルールを握っておくための客観的記録が欲しいのです。

そこで、経営層から「うちでも最新のフィジカルAIやロボットアームで自動化を検証しろ」と命じられたPM向けに、自社環境で再現検証するための「機材・クラウドGPU費用・物理トラブルの全記録」を束ねたページを案3として追加します。

## 1 / 60｜出す｜Gemini（ロボット導入を判断する経営者の来訪者）（18:37）

Claudeの叩き台にあった案1「配膳ロボットの導入試算」に強く賛成します。現場で機械の導入を決める立場として、「配膳ロボット 費用」などで検索して見たいのは、機械の機能ではなく「うちの席数やスタッフ数で本当に元が取れるのか」という損益と条件です。既存LP（/serving-robot-one-less-staff）は表示3件と数は少ないものの、最後まで読んだ割合が67%（※依頼の数字）と関心は深い形跡があります。

ここへ判断材料を持って入ってこられるよう、飲食経営者向けに「台数・席数ごとの損益と詰まりの分岐点」を整理したページを1本目に推します。また、同様の投資判断で悩む病院の事務長や施設経営者向けに、「薬剤・物品搬送ロボットの導入判断（廊下の混雑と稼働設計）」をまとめたページも候補として出します。最初の画面で「自分の現場に当てはまる条件と数字」が見えないと、忙しい経営者は9秒で離脱します。
```


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

```markdown
# 最終案（入口のページ・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

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

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

## サイトのねらい
- Mission：Physical AI が学習できる環境を作り続け、その知見を再現できる形で公開し、同じ環境から研究を始められる人を増やす
- いちばんの指標は「再現可能な環境の数」（他人が同じ手順で同じ結果に届く研究資産の数）。表示の数やフォロワーは主にしない
- いま見ている3つの数字：AI の利用者の依頼で読みに来た数・AI のサービスのリンクから来た人の数・サイト名で検索して来た人の数
- サイトはもともと検索で人を集める作りにしていない。AI に調べられることで、人の来訪や知名度がいつ増えはじめるかを見ている
- 届けたい相手：ロボット導入を判断する経営者、導入を任された PM、ロボット・AI のソフトを書く開発者（実験が好きな開発者も入る）

## 実際の数字（2026-10-26〜11-14・人の操作があった表示だけ）
- 人の表示は合計367件。週ごとに 164 → 136 → 68（11-09の週は6日分）と減っている
- **トップは40件で約1割。** 人の多くは Google（90件）や直接（153件）から、個々のログに直接来ている。LinkedIn 10件・Yahoo 10件・ChatGPT のリンク4件
- ログからほかのログ・シリーズへ移る動きはわずか（数件ずつ）。1本読んで出ていく
- 主なページの表示（25%/50%/75% まで読んだ割合）
  - / トップ：40件（70%/48%/28%）
  - /gpu-buy-or-rent（GPU は買うか借りるか・LP）：21件（52%/52%/10%）
  - /issues（課題地図）：21件（5%/0%/0%・中央値9秒）
  - /manga-archive：14件
  - /series8（サービスロボット導入シミュレーション）：12件
  - /serving-robot-one-less-staff（配膳ロボットの LP）：3件。ただし中の動画が57回再生され、67%が最後まで読んだ
  - /one-year（1年の記録の LP）：2件
  - よく読まれたログ：DAY18（11件・中央値53秒）、DAY17（7件）、DAY12（6件）、大きな店に配膳ロボット5台（7件）
- AI の利用者の依頼で読みに来た数：週に42〜61件。トップがいちばん多く、残りは個々のログに散る（ChatGPT-User が多く、Claude-User・Perplexity-User もある）
- サイト名で検索して来た人：まだ0
- **注意：** どのページも数が少ない。30件未満の数は「判断できない」として扱い、言い切らない

## 今のサイトの形
- トップ：見出し → 1年の記録 → 課題地図 → 導入前ガイド → 4コマ → いまの考え → シリーズ → 記録 → ロボットに関わる人へ → 事業所について
- シリーズのページ（/series1〜8）：上に資料、下にそのシリーズのログの一覧
- 今ある LP：/serving-robot-one-less-staff（配膳ロボットで人が1人減らせるか）、/gpu-buy-or-rent（GPU は買うか借りるか）、/one-year（1年の記録）
- 課題地図（/issues）：フィジカルAIの社会実装の前に解くべき課題・週1回更新
- ログは全部で約520本。各ログには全文・コード・素材のファイルが付き、「AIで読む」ボタンがある

## ログ一覧（入口のページは、ここにある中身だけで作る）

### 導入シミュレーション（48本）
- 351｜サービスロボット導入シミュレーション Log#1 | 配膳ロボットで1人減らせるかは、店の形で変わる｜/record/serving-robot-simulation-simpy
- 353｜サービスロボット導入シミュレーション Log#2 | 配膳ロボットが何回止まるかは、公開データが見つからない ― 店で押して数える観察シートを作った｜/record/serving-robot-observation-sheet
- 356｜サービスロボット導入シミュレーション Log#3 | ロボットが人を呼ぶ回数を、5つの現場で試算する｜/record/service-robot-five-sites
- 357｜サービスロボット導入シミュレーション Log#4 | Unity にファミレスを建て、配膳ロボットを走らせた｜/record/unity-family-restaurant-serving-robot
- 359｜サービスロボット導入シミュレーション Log#5 | Unity に合わせる前に、試算のほうを点検した｜/record/audit-simulator-before-unity
- 360｜サービスロボット導入シミュレーション Log#6 | 店の平面図を6つ作り、試算に入れた｜/record/floor-plans-into-simulator
- 362｜サービスロボット導入シミュレーション Log#7 | Unity の店をサイトの図面から建てた｜/record/unity-store-from-site-json
- 364｜サービスロボット導入シミュレーション Log#8 | Unity の配膳ロボットが詰まる所を1つずつほどいた｜/record/serving-robot-jam-points
- 366｜サービスロボット導入シミュレーション Log#9 | 試算に、ロボットの費用と補助金を足した｜/record/serving-robot-cost-subsidy
- 367｜サービスロボット導入シミュレーション Log#10 | ロボットなしなら、Unity と試算は合った｜/record/serving-robot-stage-b-18-runs
- 370｜サービスロボット導入シミュレーション Log#11 | 詰まりの元は、ロボットを線に縛った作りだった｜/record/serving-robot-fixed-route-jam
- 374｜サービスロボット導入シミュレーション Log#12 | ロボットに地図を渡したら、詰まりが減った｜/record/serving-robot-map-planner
- 379｜サービスロボット導入シミュレーション Log#13 | 隠れていた待ちが見えて、次は「どこで詰まるか」へ｜/record/serving-robot-hidden-waits
- 382｜サービスロボット導入シミュレーション Log#14 | 動画は2回目へ、次は3Dの店で止まる所を見る｜/record/serving-robot-video-part2
- 383｜サービスロボット導入シミュレーション Log#15 | 寝ている間に店を回す準備ができた｜/record/serving-robot-night-runs
- 384｜サービスロボット導入シミュレーション Log#16 | 眠っている間に、配膳ロボットを比べる基準ができた｜/record/serving-robot-pass-by-standard
- 391｜サービスロボット導入シミュレーション Log#17 | 店員が来るまでが、いちばん長かった｜/record/serving-robot-video-ledger
- 393｜サービスロボット導入シミュレーション Log#18 | 小さい店では、2台目のロボットが待ちを延ばした｜/record/small-store-second-robot-wait
- 397｜サービスロボット導入シミュレーション Log#19 | 大きい店でも、詰まるのは片付けだった｜/record/large-store-cleanup-bottleneck
- 398｜サービスロボット導入シミュレーション Log#20 | 38卓の店でも、詰まるのは片付けだった｜/record/standby-jam-every-store
- 400｜サービスロボット導入シミュレーション Log#21 | 受け渡しの時間は、客で変わった｜/record/serving-robot-jams-are-aisles
- 402｜サービスロボット導入シミュレーション Log#22 | ファミレス6店で、配膳ロボット2台は同じ所で詰まった｜/record/six-stores-fix-the-rules
- 404｜サービスロボット導入シミュレーション Log#23 | 導入前に、配膳ロボットの詰まりを動画で見比べる｜/record/lp-demo-same-time-compare
- 405｜サービスロボット導入シミュレーション Log#24 | 配膳ロボットの試算が、混んだファミレスの実物に近づいた｜/record/register-priority-serving-robot
- 409｜サービスロボット導入シミュレーション Log#25 | 配膳ロボットの効き目は、ファミレスのスタッフ数で変わる｜/record/understaffed-famires-robot
- 414｜サービスロボット導入シミュレーション Log#26 | 配膳ロボットの試算を、店のスマホで測って確かめる｜/record/check-serving-robot-sim-with-phone
- 415｜サービスロボット導入シミュレーション Log#27 | 店で測った数字が届けば、配膳ロボットの試算はすぐ直せる｜/record/serving-robot-sim-ready-for-store-data
- 418｜サービスロボット導入シミュレーション Log#28 | 道の線を消すと、配膳ロボットの詰まりは3割しか拾えない｜/record/serving-robot-jam-detection-without-path-lines
- 423｜サービスロボット導入シミュレーション Log#29 | 狭いファミレスでは、配膳ロボットは1台まで｜/record/serving-robot-one-per-narrow-restaurant
- 426｜サービスロボット導入シミュレーション Log#30 | 配膳ロボットが詰まる所へ、動画が自動で寄る｜/record/serving-robot-video-zooms-to-jams
- 434｜サービスロボット導入シミュレーション Log#31 | 配膳ロボットのにらみ合い、解くのは店員だった｜/record/serving-robot-faceoff-staff-resolves
- 435｜サービスロボット導入シミュレーション Log#32 | 配膳ロボットのシミュレーションから瞬間移動が消えた｜/record/serving-robot-sim-teleport-zero
- 440｜サービスロボット導入シミュレーション Log#33 | 配膳ロボットに下げ膳も任せると、細い通路で詰まる｜/record/serving-robot-sim-bussing-narrow-aisles
- 444｜サービスロボット導入シミュレーション Log#34 | 配膳ロボットの下げ膳、効くかは店の通路しだい｜/record/serving-robot-bussing-depends-on-aisles
- 452｜サービスロボット導入シミュレーション Log#35 | 配膳ロボット5台で見えた、シミュレーションの穴｜/record/large-restaurant-five-serving-robots-longer-wait
- 456｜サービスロボット導入シミュレーション Log#36 | 配膳ロボットが止まり合う原因は、待機点への入り方｜/record/serving-robots-jam-cause-standby-entry
- 465｜サービスロボット導入シミュレーション Log#37 | 配膳ロボットの止まり合いを減らす3つの決まり｜/record/serving-robot-jam-three-rules
- 466｜サービスロボット導入シミュレーション Log#38 | 片付けを止めずに、配膳ロボットの横をすり抜ける｜/record/serving-robot-staff-squeeze-past
- 475｜サービスロボット導入シミュレーション Log#39 | 大型店の配膳ロボットを止めない、受け渡し口の帯｜/record/serving-robot-large-store-pass-lane
- 477｜サービスロボット導入シミュレーション Log#40 | 病院の搬送ロボット、外来の廊下を避けて問題を4割減らす｜/record/hospital-transport-robot-avoid-outpatient-hall
- 483｜サービスロボット導入シミュレーション Log#41 | 病院の搬送ロボット、立体で見せて車いすを1%に直す｜/record/hospital-transport-robot-3d-view-wheelchair-share
- 485｜サービスロボット導入シミュレーション Log#42 | 病院を人ごと再現し、搬送ロボットの廊下の混みを確かめた｜/record/hospital-transport-robot-full-floor-people-flow
- 488｜サービスロボット導入シミュレーション Log#43 | 病院の通れない所を直すと、搬送ロボットの問題が増えた｜/record/hospital-transport-robot-blocked-paths-more-conflicts
- 491｜サービスロボット導入シミュレーション Log#44 | 搬送ロボットの問題は、病院の職員の仮の動きだった｜/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves
- 496｜サービスロボット導入シミュレーション Log#45 | 受け渡しを寄りで見せる、ハコブくんと看護師の3D｜/record/hakobu-nurse-3d-models-for-handover-closeups
- 499｜サービスロボット導入シミュレーション Log#46 | 看護師と搬送ロボットの受け渡しを、すり抜けない動きに｜/record/nurse-hospital-robot-handover-without-clipping
- 503｜サービスロボット導入シミュレーション Log#48 | 現場の速さで見る、看護師と搬送ロボット｜/record/hospital-robot-nurse-3d-scenes-at-real-speed
- 506｜サービスロボット導入シミュレーション Log#49 | 配膳ロボットの店を、ブラウザで試せる形に｜/record/serving-robot-store-sim-in-the-browser


### 薬剤搬送ロボット（57本）
- LOG1｜「愛されるロボット」はUIデザイナーが作る。HRI（Human-Robot Interaction）デザインの最前線｜/record/day1
- LOG2｜WebデザイナーがHRI設計へ。ロボット保守UIのための情報設計術｜/record/day2
- LOG3｜ハコブくん薬剤搬送ロボットのUI設計と情報アーキテクチャ｜Figmaによる病院現場HRI設計｜/record/day3
- LOG4｜ハコブくん薬剤搬送システムのUIスコープ定義。Figmaで作る画面リストと情報設計｜/record/day4
- LOG5｜生成AIより確実。「Layermate」で加速するUIデザイン構築｜/record/day5
- LOG6｜ハコブくんの表情デザイン。愛着だけでなく「信頼」を生むHRIデザインの実践｜/record/day6
- LOG7｜GeminiのアイデアをFigmaで仕上げる｜ハコブくんの表情デザイン工程｜/record/day7
- LOG8｜GeminiとFigmaで作る「認証画面」。ハコブくんのセキュリティUIデザイン工程｜/record/day8
- LOG9｜共感を呼ぶストーリーテリング。GeminiとFigmaで作る「4コママンガ」｜/record/day9
- LOG10｜GeminiとFigmaで創るロボットUI全仕事。ハコブくんのUIデザイン全工程｜/record/day10
- LOG11｜薬剤搬送ロボット（ハコブくんモデル）12台5稼働の運用設計。SaaSサブスクで実現する止まらない医療搬送｜/record/day11
- LOG12｜ハコブくん管理者向けダッシュボードのUIデザイン｜FigmaによるHRI管理画面設計｜/record/day12
- LOG13｜GeminiとFigmaで4コママンガ量産体制構築｜X・Instagram投稿を回し続けるための管理設計｜/record/day13
- LOG14｜ロボットが当たり前に存在する社会はどうなるのか。デザイナー視点のHRI未来論｜/record/day14
- LOG15｜Figmaを使ったUIデザインのブラッシュアップ。UIの効率化プロセス｜/record/day15
- LOG16｜デザインとエンジニアリングの境界線へ。AIエディタCursorとFigmaを連携させて見えた、新しい効率化の可能性｜/record/day16
- LOG17｜4コマ漫画でバズる！？SNS拡散投稿術【X & Instagram編】｜/record/day17
- LOG18｜Figmaのカラー管理。バリアブル（Variables）とスタイル（Styles）について解説します｜/record/day18
- LOG19｜Figmaへのコレクション作成とバリアブル登録｜/record/day19
- LOG38｜薬剤搬送ロボットハコブくんのデジタルワイヤーフレームによる検証プロセス｜/record/day38
- LOG39｜「通れるはず」のストレスを可視化する。ハコブくんの動くワイヤーフレーム構築｜/record/day39
- LOG43｜ロボティクスPMの視点。ハコブくん × Unity × ROS 2のA/BテストでデザインをKPI・経営指標へ変換する｜/record/day43
- LOG44｜ハコブくんをUnityとROS 2で繋ぐ通信開通全記録。Docker × ROS-TCP-EndpointからHakobuMove.csまで｜/record/day44
- LOG45｜ハコブくん、ついに目と声を持つ。デジタルツインで実現するロボットの安全制御｜/record/day45
- LOG46｜Unity × ROS 2 実装：Raycastを用いた全方位衝突回避システムと、進行方向判定による自動ブレーキ解除ロジック｜/record/day46
- LOG47｜ハコブくん、自律パトロールへ。自動往復走行の実装｜/record/day47
- LOG48｜Unity UI Canvas連携｜センサー検知と同期した警告パネルの動的制御プロセス｜/record/day48
- LOG49｜Unityで看護師カプセルエージェントの自律移動と障害物回避テスト。NurseWander.cs × Raycastの実装記録｜/record/day49
- LOG50｜FigJam × ハコブくん設計。なんとなくのデザインではなく仕様としてのフロー図作成｜/record/day50
- LOG51｜FigJamで描くロボットの意思｜物理空間を制御するフロー図の構築｜/record/day51
- LOG54｜Unityで構築する20の動くワイヤーフレーム規格｜/record/day54
- LOG55｜HRIデザインにおける物理空間の「振る舞い」設計｜ハコブくんのUnityシミュレーション考察｜/record/day55
- LOG57｜動くワイヤーフレーム｜壁を透過させ、Unity6で実現する没入感｜/record/day57
- LOG58｜気配りを可視化する｜ハコブくんの発光による意図の伝達｜/record/day58
- LOG59｜看護師の接近に呼応するハコブくん発光ロジックの構築｜/record/day59
- LOG60｜ハコブくんNavMeshと周回路による自律走行の実装プロセス｜/record/day60
- LOG61｜ハコブくんと看護師が通路でお見合い状態になるのを防ぐための設定｜/record/day61
- LOG62｜デジタルツインで育つ知能 - ハコブくんの自律実装プロジェクトはじめます｜/record/day62
- LOG63｜UnityでUV-C光を可視化する｜ハコブくん病院フロアのマテリアル管理とシェーダー設計｜/record/day63
- LOG64｜ハコブくんの自律走行がUnity病院シーンにもたらす動的ノイズ｜HRI設計の検証｜/record/day64
- LOG65｜ハコブくんと看護師の「距離感」をUnityで実装する｜病院廊下のHRI設計｜/record/day65
- LOG111｜ハコブくんの表情をチャットUIのステートとして実装した日。Dify × Studio × JavaScriptでHRI表情設計｜/record/day111
- LOG116｜ツカムくん誕生。ロボットアームのキャラクター設計と、500gの壁｜/record/day116
- LOG117｜ロボットアームにキャラクターを与えるとはどういうことか。ツカムくん誕生まで｜/record/day117
- LOG127｜1gの壁。mechArm 270が「言葉を持たない」とはどういうことか｜HRIデザイン考察｜/record/day127
- LOG138｜GA4が教えてくれた。海外の人がアクセスしている｜/record/day138
- LOG141｜英語版4コマアーカイブページを公開した｜/record/day141
- LOG171｜ハコブくんの世界に住む人々を設計する｜/record/day171
- LOG267｜ハコブくん 病院オペレーションのデジタルツイン Log#1 | まずはシステム全体設計から始める｜/record/hospital-operations-digital-twin-system-design
- LOG269｜ハコブくん 病院オペレーションのデジタルツイン Log#2 | 意思決定の補正ループを設計する｜/record/predicted-vs-actual-correction-loop
- LOG303｜Figmaのデザイントークンを整理する | 生hex 3,977箇所を変数化し、コントラスト不合格をゼロにするまで｜/record/figma-design-token-consolidation
- LOG305｜ハコブくん 病院オペレーションのデジタルツイン Log#3 | 作る前に調べたら、前提が四つ崩れた｜/record/does-a-delivery-robot-help-nurses
- LOG307｜Autodesk Fusion でロボットの治具やパーツを作る Log#1 | Fusion を Claude から動かせる状態にするまで｜/record/autodesk-fusion-mcp-setup
- LOG308｜Autodesk Fusion でロボットの治具やパーツを作る Log#2 | Claude の指示だけでは形にならなかった｜/record/claude-instructions-hit-a-wall
- LOG311｜Autodesk Fusion でロボットの治具やパーツを作る Log#3 | イラストをなぞって3D CADの形にした｜/record/from-drawing-to-solid
- LOG321｜アバターと義体を考える Log#1 | アバターという義体に人が宿るとき｜/record/avatar-gitai
- LOG322｜アバターと義体を考える Log#2 | 生身を超えて操りたくなる分身ロボットを設計する｜/record/avatar-gitai-pikari


### フィジカルAI研究室（37本）
- LOG225｜SO-101 失敗から学ぶアームを作る Log#1 | 精度を上げることと、失敗から学ぶことは違う｜/record/precision-is-not-learning-so101
- LOG234｜SO-101 失敗から学ぶアームを作る Log#2 | 2TBの外付けSSDを、学習データの定位置にする｜/record/where-learning-data-lives
- LOG277｜フィジカルAI研究室を作る Log#1 | 自宅にゼロから、誰でも再現できる形で｜/record/building-a-physical-ai-lab-at-home
- LOG326｜フィジカルAI研究室を作る Log#2 | Physical Intelligence の π0.5 を借りたGPUで動かした｜/record/openpi-remote-inference-first-run
- LOG327｜フィジカルAI研究室を作る Log#3 | Physical Intelligence の π0.5 に要るGPUメモリを測った｜/record/pi05-libero-benchmark-first-run
- 337｜フィジカルAI研究室を作る Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
- LOG337｜フィジカルAI研究室を作る Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
- 341｜フィジカルAI研究室を作る Log#5 | Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致｜/record/pi05-mecharm-lora-2000-steps
- 345｜フィジカルAI研究室を作る Log#6 | Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った｜/record/pi05-mecharm-first-real-run
- 348｜フィジカルAI研究室を作る Log#7 | Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた｜/record/pi05-mecharm-4000-steps
- 349｜フィジカルAI研究室を作る Log#8 | 手で教えた動きを再生し、4回続けて箱に入れた｜/record/drag-teach-waypoint-replay
- 352｜フィジカルAI研究室を作る Log#9 | 手で教えてお手本19本。肩88°を超えた姿勢は動かなかった｜/record/teach-replay-19-demos
- 355｜フィジカルAI研究室を作る Log#10 | 位置を変えたお手本で、Physical Intelligence の π0.5 を学習し直した｜/record/pi05-retrain-five-positions
- 358｜フィジカルAI研究室を作る Log#11 | Physical Intelligence の π0.5 は「待ち時間」まで覚えた｜/record/pi05-learned-the-pauses
- 361｜フィジカルAI研究室を作る Log#12 | Physical Intelligence の π0.5 が初めてブロックを箱に入れた｜/record/pi05-first-block-in-box
- 363｜フィジカルAI研究室を作る Log#13 | Physical Intelligence の π0.5 がお手本の3か所すべてで箱に入れた｜/record/pi05-all-three-positions
- 401｜フィジカルAI研究室を作る Log#14 | π0.5 を回数で測ったら、苦手な置き場所が見えた｜/record/pi05-weak-position-d
- 403｜フィジカルAI研究室を作る Log#15 | mechArm 270 の失敗を巻き戻し、直して覚えさせる｜/record/rewind-and-correct-pi05
- 407｜フィジカルAI研究室を作る Log#16 | 直した mechArm 270 の動きを π0.5 に覚えさせる手前まで｜/record/rewind-correct-real-arm
- 417｜フィジカルAI研究室を作る Log#17 | 人が直した mechArm 270 の5回で π0.5 を学び直す｜/record/retrain-pi05-with-human-corrections
- 419｜フィジカルAI研究室を作る Log#19 | ゲームパッドで mechArm 270 を直す準備ができた｜/record/gamepad-ready-to-correct-mecharm-270
- 422｜フィジカルAI研究室を作る Log#18 | 学び直した π0.5 でも mechArm 270 には人の直しが要った｜/record/retrained-pi05-still-needs-human-corrections
- 436｜フィジカルAI研究室を作る Log#20 | ゲームパッドで動いた mechArm 270、遅さは pymycobot の版｜/record/gamepad-moves-mecharm-270-pymycobot-version
- 446｜フィジカルAI研究室を作る Log#21 | ゲームパッドで mechArm 270 を直す形が固まった｜/record/gamepad-correction-mecharm-270-settled
- 450｜フィジカルAI研究室を作る Log#22 | mechArm 270 の AI の直しが、ゲームパッドで1回13秒に｜/record/gamepad-fixes-mecharm-270-ai-in-13-seconds
- 460｜フィジカルAI研究室を作る Log#23 | π0.5 の失敗の原因を探ると、浅いお手本だった｜/record/pi05-failures-traced-to-shallow-grasp-demos
- 461｜フィジカルAI研究室を作る Log#24 | 手応えを学習に足すため、mechArm 270 の電流を読んだ｜/record/reading-mecharm-270-servo-current-for-learning
- 463｜フィジカルAI研究室を作る Log#25 | 深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した｜/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- 479｜フィジカルAI研究室を作る Log#26 | 偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に｜/record/even-ten-demos-per-spot-mecharm-270-reteaching
- 480｜フィジカルAI研究室を作る Log#27 | 浅いつかみの癖を残さず、π0.5 を50本で一から学習｜/record/retrain-pi05-from-base-on-50-even-demos
- 484｜フィジカルAI研究室を作る Log#28 | 50本で学んだ π0.5 をアームで試し、位置2 で外れた｜/record/pi05-even-demos-on-arm-misses-position-2
- 486｜フィジカルAI研究室を作る Log#29 | π0.5 が位置2 を外した理由は、カメラの傾きではなかった｜/record/pi05-position-2-miss-caused-by-camera-tilt
- 487｜フィジカルAI研究室を作る Log#30 | mechArm 270 がブロックを落とす理由は、まさかの電源不足｜/record/mecharm-270-drops-block-underpowered-adapter
- 490｜フィジカルAI研究室を作る Log#31 | mechArm 270 の待ちを測り、Claude Fable 5.2 の使い所を決めた｜/record/measure-mecharm-270-waits-decide-claude-fable-5-2-role
- 492｜フィジカルAI研究室を作る Log#32 | mechArm 270 を人が直す時間を測り、縮める先を決めた｜/record/measure-mecharm-270-recovery-time-decide-what-to-cut
- 497｜フィジカルAI研究室を作る Log#33 | アームの成否判定を Google の Gemini Decision 1 に任せられるか｜/record/gemini-decision-1-judge-mecharm-270-pick-and-place
- 504｜フィジカルAI研究室を作る Log#34 | mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった｜/record/mecharm-270-5a-adapter-stops-dropping-block


### 考察記事（86本）
- LOG53｜フィジカルAI時代のデザイン思想。ロボティクス領域でデザインが利益率を決定する理由｜/record/day53
- LOG107｜フィジカルAI市場の設計者不足。関心はあるのに実装できる人がいない理由を考察する｜/record/day107
- LOG109｜Boston Dynamicsが示した「身体で考える」ロボットと、問いの本質｜/record/day109
- LOG110｜Web/UIデザイナーがXへの発信とDAYログを続けて気づいたこと。Build in Publicが知性になる理由｜/record/day110
- LOG112｜スワイプとピンチを定義したのはAppleだった｜/record/day112
- LOG115｜人間の動作に隠された秘密と、精度を超えるMotion UX｜/record/day115
- LOG118｜GoogleのRT-2とFigureが証明した。良い動きはデータ量で決まる｜/record/day118
- LOG119｜ロボット産業はなぜまだ「速さ・精度・重量」を競うのか。産業ロボットの設計思想を問う｜/record/day119
- LOG121｜Build in Public × AI時代。AIがコンテンツを読む時代にDAYログを書き続ける理由｜/record/day121
- LOG126｜Generalist AI GEN-0を解剖する。シミュレーション×実世界データの戦い｜/record/day126
- LOG128｜Claude Codeのマルチエージェント設計がSim-to-Realループと同じ問いを解いていた｜/record/day128
- LOG135｜ロボティクスUXがゲームUIから借りるべきはコントローラーではなく思想｜HRI設計論｜/record/day135
- LOG140｜AGIBOTが100万エピソードでやることを、自分は10エピソードから始める｜/record/day140
- LOG143｜TeslaのEnd-to-Endニューラルネットから学ぶ｜デモとデータを同時に生む設計｜/record/day143
- LOG145｜大阪市の自動運転タクシーが示した：技術は完成する。でも社会は動かない｜/record/day145
- LOG147｜考察記事のサムネイルを統一し、SEOタイトルを見直した｜/record/day147
- LOG152｜平面型仕分けロボットHyperSortから見えた、環境設計とフィジカルAIの役割分担。Amazon Vulcan・Moxiとの対比｜/record/day152
- LOG155｜Claude Designを触った日に、フィジカルAIのセキュリティを考えた｜/record/day155
- LOG159｜グリッパーにカメラを足す。hand-eye構成の設計を物理から考え直した｜/record/day159
- LOG161｜ロボティクスの正解のない現場で生きる｜/record/day161
- LOG166｜深度カメラはまだ買わない｜1時間の対話でNVIDIA戦略にたどり着いた話｜/record/day166
- LOG167｜Pixels to Motorsをメソドロジー化する｜/record/day167
- LOG174｜日本でフィジカルAIが本格普及しない本当の理由｜/record/japan-robot-leader-physical-ai-gap
- LOG181｜Motion UX 三相モデル｜/record/motion-ux-three-phase-model
- LOG187｜エンジニアが作り、デザイナーが定義する。Motion UX / Robotics UX カテゴリ戦略｜/record/category-strategy-motion-ux-robotics-ux
- LOG194｜Robotics UXデザイナーという職業 | 米国に既にある、日本にはまだない仕事｜/record/robotics-ux-designer-as-a-profession
- LOG195｜自分の記事を3つのAIで読み比べた日、コンテンツ生産の構造が変わった｜/record/three-ai-content-pipeline
- LOG198｜タダより高いものはない | AIエージェント時代の依存設計を考える｜/record/no-such-thing-as-free-ai
- LOG201｜mechArm 270 Pi 動的追従の、その先を考えた | 双腕協働とコーヒーデモへの構想｜/record/toward-dual-arm-coffee
- LOG205｜mechArm 270 Pi、まだやれることが結構ある｜/record/mecharm-not-done-yet
- LOG206｜Pixelsの起源が二つに増える | ブロック認識とマット撤廃が同じ問いに収束した話｜/record/pixels-as-perception-data
- LOG207｜Motion UX とは何か  | ロボットの動きを体験として設計する｜/record/motion-ux-definitive
- LOG212｜動きの滑らかさは安心ではない | ロボットの動きと不気味の谷｜/record/motion-uncanny-valley
- LOG214｜コードが消えても、設計は残る | ニューラルネットワークがロボットを動かす40年と、その先｜/record/when-robot-motion-is-learned
- LOG218｜AIで「作る速さ」が横並びになった世界で、むき出しになるもの | プロダクトマネージャー不要論と、最後に残る「捨てる判断」｜/record/exposed-judgment
- LOG219｜巨大ラボπはロボットの「動き方」をデータとして使う。こちらは、その動き方をMotion UXとして設計する｜/record/how-as-metadata-vs-subject
- LOG221｜世界はVLA、こちらは計画と評価 | ロボットを動かすVLMの、二つの使い方｜/record/vlm-planning-layer
- LOG223｜正しい動きと、いい動き | Motion UX の二層構造｜/record/two-layers-of-motion
- LOG229｜運ぶロボットと、掴む双腕アーム | 医療現場で、受け渡しは責任の受け渡しになる｜/record/robot-handoff-design
- LOG233｜フィジカルAIの社会実装を止めるのは、デモではなく構造的な課題だ ― 36課題を地図にした｜/record/build-in-public-double-structure
- LOG237｜「最後の数メートル」を誰が引き受けるか ― 自律飛行の着陸問題と、体験が成立する瞬間の設計｜/record/flying-car-naming-and-motion-ux
- LOG245｜全天候ロボットと、まだ書かれていないナンバープレート ― 人がひと目で「誰の責任か」を読む設計は誰の仕事か｜/record/who-is-responsible-robot-identity-design
- LOG249｜ロボットの骨格はコードで、判断はClaude Codeに | 搬送ロボットとアームで考える２つの可能性｜/record/code-skeleton-agent-judgment
- LOG260｜Raspberry Piを起点に、ロボットの脳と筋肉の分け方、Pi Zero、mechArmの実時間制御の正体、停電や電波断でも破綻しない縮退設計までを考察する｜/record/pi-brain-not-muscle-local-first
- LOG262｜Reachy Mini が映す Motion UX | 身体を持ったAIは「間」で試される｜/record/reachy-mini-motion-ux-timing
- LOG264｜欲しいロボットを60個考えて全部捨てた | アイデアはロボットからではなく苦痛から探す｜/record/robot-ideas-from-pain-not-robots
- LOG276｜MicroFactory を分解する ― ロボットを専用ワークステーションに閉じ込めて環境を固定する設計｜/record/microfactory-loop-model-fix-the-variance
- LOG278｜MicroFactory の入力設計 ― 精度はモデルではなく、人間とロボットの変換比で作られていた｜/record/precision-lives-in-the-input-not-the-model
- LOG282｜MicroFactory と大規模事前学習 ― 賢さをモデルに積むか、環境を作り込むか｜/record/microfactory-vs-large-scale-pretraining
- LOG286｜62万円のロボットアームが町工場に入らない理由 ― 3Dプリンターとの決定的な差と、Physical Intelligence が認めた限界｜/record/why-robot-arms-stop-at-one
- LOG290｜自動運転の高精度地図は、どこまで情報を減らせるか ― 作り込む派と持たない派の争点は、ゼロにできるか｜/record/hd-map-how-thin
- LOG291｜ヒューマノイドを追わない人たち ― 用途を固定して勝つという戦い方｜/record/not-chasing-humanoids
- LOG292｜産業用ロボットでも、ヒューマノイドでもないロボットの話 ― 「役に立つ=作業する」以外のロボットを想像できるか｜/record/wB1BUDZj
- LOG296｜機械として合理的で、かつ柔らかい ― ロボットの動きの柔らかさをどの層で作るかの整理｜/record/four-layers-of-robot-softness
- LOG306｜サービスロボットは現場のどこで止まるのか | 配膳・清掃・警備を調べて出てきた「例外」という共通点｜/record/DesFKiCf
- LOG312｜計算資源のそばで実世界データを取る ― （地名）2兆円計画をロボティクスから読む｜/record/akita-data-center-robotics-perspective
- LOG314｜フィジカルAI時代のロボットに渡す仕事を、まだ誰も切り出していない｜/record/what-to-hand-to-robots
- LOG315｜道路の白線を引く機械の求人から考える ― フィジカルAIは既存の機械に入っていく｜/record/road-marking-job-post-and-physical-ai
- LOG316｜ロボットカー教材を比べながら自動運転の中身を分解した｜/record/robot-car-kit-autonomy-breakdown
- LOG318｜役に立つロボットのタスクは、人が集まらない仕事から探す｜/record/find-tasks-where-nobody-comes
- LOG319｜AI外観検査は撮り方で決まる ― 照明の設計と検査員の限度見本から考える｜/record/ai-visual-inspection-lighting
- LOG320｜AIにロボットを直接動かさせない設計 ― MicroFactoryの構成を読む｜/record/ai-writes-code-not-motions
- LOG323｜論文4本で、SO-101 の成功率を左右する条件を先に確かめる｜/record/so101-imitation-learning-papers
- LOG324｜フィジカルAIは産業用ロボットの何を変えるのか ― 精度・導入コスト・操縦・人材育成を対話で整理する｜/record/physical-ai-beyond-industrial-robots
- LOG329｜MicroFactoryは市販アームFAIRINO FR3でロボットセルを作った｜/record/microfactory-fairino-fr3
- 336｜NVIDIA の AlphaNIST は、成功か失敗かだけの報酬で組立を覚えた｜/record/alphanist-binary-reward-assembly
- 375｜協働ロボットを現場に入れる前に ― 法律・資格・院内の調整を調べた｜/record/cobot-deployment-law-and-coordination
- 389｜ロボットを広げるのは、性能より現場で扱えるかだった｜/record/service-robot-last-mile
- 392｜人のお手本の先へ ― ロボットが自分で直す学び方｜/record/beyond-imitation-learning
- 396｜Physical Intelligence の π0.5 と Runpod と Claude Code を選ぶ理由 ― 替えずに比べる相手を足す｜/record/why-pi05-runpod-claude-code
- 406｜配膳ロボットの次の改造は、追加学習になる ― メーカー製品を触る損得｜/record/service-robot-modding
- 412｜ロボットのピッキングは照明で崩れる ― 次のアームは人の雑さをまねる｜/record/lighting-breaks-picking
- 424｜ロボットのAIは脳のように分業する ― 小脳を育てるのは失敗の手直し｜/record/robot-ai-divides-like-brain
- 433｜AIの混乱はロボットより先に制御装置から来る ― 3年前のXの投稿と読み比べた｜/record/ai-chaos-control-systems-before-robots
- 438｜ロボットの世界モデルを入れる基準 ― 個人のアームにはまだ早かった｜/record/world-model-adoption-criteria-robot-arm
- 439｜配膳ロボットが止まる理由は4段で分けられる ― スタンフォードのロボット自律の講義から｜/record/serving-robot-stops-four-stages-stanford
- 441｜倉庫ロボットは遠隔の人が直して回す ― 差がつくのは修正データの扱い｜/record/warehouse-robot-remote-correction-data
- 442｜フィジカルAIは作り方で定義する ― 尾形哲也教授の線引きと配膳ロボット｜/record/physical-ai-defined-by-how-it-is-built
- 443｜Physical Intelligence の π0.5 で靴下とゴミを取り分ける ― SO-101 の動画に見た LoRA と YOLO｜/record/pi05-sock-garbage-lora-yolo-so101
- 449｜トヨタのフィジカルAI ― トヨタロボティクスは自社の工場から勝ちに行く｜/record/toyota-robotics-physical-ai-factory-first
- 464｜ニューラルネットワークの出番は実店舗の映像 ― Unityの配膳ロボットが教材になる｜/record/neural-network-for-real-store-video
- 467｜下げ膳ロボットはいつ店で使えるか ― CEATECのデモとServi Qの45cm通路から考えた｜/record/when-table-clearing-robots-reach-restaurants
- 481｜ロボットが安くなっても、現場に入れる手間は残る ― PyBrain AI から考えた立ち位置｜/record/robot-deployment-effort-remains-pybrain-ai
- 482｜配膳ロボットに手を足すなら、どの作業か ― 手持ちグリッパー Specialist から考えた｜/record/serving-robot-hand-tasks-specialist-gripper
- 498｜自動倉庫は、どこまでロボットに任せられるか ― RENATUS とイー・ロジットの現場で切り分けた｜/record/renatus-automated-warehouse-where-robots-stop
- 509｜監視画面はデジタルツインと呼べるか ― 物流ロボット PICKR の動画から、実機とのつなぎ方を考えた｜/record/pickr-dashboard-digital-twin-or-shadow


### R2R2R（185本）
（mechArm 270 の実機と Unity のデジタルツイン。DAY1 から続く本線。ここでは直近の30本だけ載せる）
- LOG255｜mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#06 | pose_idで、姿勢と実機結果をつなぐ｜/record/from-cleanup-to-traceability
- LOG256｜mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#07 | 実機の前に、データフローをコードで確定する｜/record/data-map-before-real-run
- LOG257｜mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#08 | 補正がZ方向に効かない、その原因はデジタルツインの姿勢の使い方にあった｜/record/why-z-correction-failed-twin-poses
- LOG258｜mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#09 | 実機を動かす前に data_manifest_rules.md を新設した。保持を測る受け皿を先に作る｜/record/measure-holding-needs-ledger
- LOG259｜mechArm 270 Pi 動的追従の限界を探る Log#41 | ブロックを掴んでいるのに落とす。原因を測定で剥がしていく｜/record/grip-hold-position-vs-pressure
- LOG261｜mechArm 270 Pi 動的追従の限界を探る Log#42 | グリッパーの握り方を位置から押し込みに変えたら、ブロックが落ちなくなった｜/record/push-hold-stops-the-drop
- LOG263｜mechArm 270 Pi 動的追従の限界を探る Log#43 | PLACEの位置は合った。だがアームの手首が捻れ、姿勢が深すぎた｜/record/fk-place-one-fix-reveals-next
- LOG265｜mechArm 270 Pi 動的追従の限界を探る Log#44 | FKテーブルの穴を測って、埋めて、1本化する｜/record/measure-the-hole-before-filling-it
- LOG266｜mechArm 270 Pi 動的追従の限界を探る Log#45 |  mechArm の横カメラを開け、PLACE 補正記憶を入れる。だが j4 が pick 到達を止めた｜/record/stop-designing-to-stop
- LOG268｜mechArm 270 Pi 動的追従の限界を探る Log#46 | ロボットアームに付けた安全装置が、正しい動きまで止めた理由｜/record/joint-guard-that-stopped-normal-motion
- LOG270｜mechArm 270 Pi 動的追従の限界を探る Log#47 | アーム学習の記憶を人の目に渡すためのダッシュボードを制作｜/record/visualizing-correction-memory
- LOG271｜mechArm 270 Pi 動的追従の限界を探る Log#47 | 仮説が三度データに殺された日。PLACEサーボが一度も動いていなかった理由｜/record/place-servo-never-fired-import-bug
- LOG272｜mechArm 270 Pi 動的追従の限界を探る Log#48 | 動的追従 再構想設計書 — 非同期 dual-system｜/record/dynamic_tracking_v2_design
- LOG273｜mechArm 270 Pi 動的追従の限界を探る Log#49 | 箱に当たる原因を三度取り違えた。当たりを検知して姿勢を上げるループ｜/record/box-collision-misdiagnosed-three-times
- LOG274｜mechArm 270 Pi 動的追従の限界を探る Log#50 | PLACE が送信前ガードで止まる。FKテーブルの穴を埋めて実機で置ききる｜/record/fill-the-hole-not-loosen-the-guard
- LOG275｜mechArm 270 Pi 動的追従の限界を探る Log#51 | 掴めなくなったアームと、原因を七回取り違えた記録。A_PICKが真上に来ないという一点｜/record/why-arm-stopped-grasping-root-cause-apick
- LOG279｜mechArm 270 Pi 動的追従の限界を探る Log#52 | pick&place観測画面の見直し。参照と姿勢選択を可視化する｜/record/revamping-the-observe-view
- LOG280｜mechArm 270 Pi 動的追従の限界を探る Log#53 | 白箱の中心を、ずっと角で測っていた｜/record/template-match-center-was-the-corner
- LOG281｜mechArm 270 Pi 動的追従の限界を探る Log#54 | 動かない原因は lookup のフィルタだった｜/record/place-lookup-three-filters-blocking-reach
- LOG283｜mechArm 270 Pi 動的追従の限界を探る Log#55 | 実行の常駐化と、中断時の自動退避｜/record/persistent-loop-interrupt-auto-home
- LOG284｜mechArm 270 Pi を ROS2 + MoveIt に載せる Log#1 | 独自スクリプトから業界標準へ｜/record/mecharm-onto-ros2-moveit
- LOG285｜mechArm 270 Pi 受け渡し動作の成立を探る Log#1 | 次の成功判定は、座標ではなく人の中にある｜/record/handover-series-concept
- LOG287｜mechArm 270 Pi 動的追従の限界を探る Log#56 | Pick & Place を映像と関節ログで残す｜/record/mecharm-continuous-recording-pipeline
- LOG288｜mechArm 270 Pi 受け渡し動作の成立を探る Log#2 | アームが差し出し、人が受け取る設計が固まるまで｜/record/handover-step1-design
- LOG289｜mechArm 270 Pi 受け渡し動作の成立を探る Log#3 | 人に手渡す姿勢と、検証にならない検証コード｜/record/handover-present-pose-from-probe-scan
- LOG293｜mechArm 270 Pi 受け渡し動作の成立を探る Log#4 | 台帳・撮影・53件のテストで制御コードを閉じる｜/record/handover-control-code-complete
- LOG294｜mechArm 270 Pi 受け渡し動作の成立を探る Log#5 | AI任せで全部作っても、動きは変わらなかった｜/record/handover-lost-the-incremental-loop
- LOG295｜mechArm 270 Pi 受け渡し動作の成立を探る Log#6 | USBカメラを番号ではなく固有名で見分ける｜/record/identify-camera-by-name-not-index
- LOG297｜mechArm 270 Pi 受け渡し動作の成立を探る Log#7 | 手の高さを測る前に、手が写るかを1枚撮った｜/record/shoot-one-frame-before-building-detection


### 画像認識・物体検出（13本）
- LOG236｜ロボットの目は、鏡像も「ある」と見る ― SAM 3で器具を切り出して気づいたこと。｜/record/sam3-mirror-reflection-grasp-problem
- LOG298｜画像認識と物体検出を学び直す Log#1 | 9つの層と、評価指標を先に学ぶ理由｜/record/image-recognition-object-detection-overview
- LOG299｜画像認識と物体検出を学び直す Log#2 | 画素の数字は、読むと・保存すると・撮ると変わる｜/record/where-pixel-values-change
- LOG300｜画像認識と物体検出を学び直す Log#3 | シーリングライトのオレンジの光の下で青いブロックが色を失う｜/record/hue-holds-color-breaks
- LOG301｜画像認識と物体検出を学び直す Log#4 | 光が変わると、赤検出が青を拾う｜/record/rgb-hsv-threshold-lighting-failure
- LOG302｜画像認識と物体検出を学び直す Log#5 | モルフォロジー演算 ― 型紙が入らないものだけが消える｜/record/morphology-kernel-fits-or-vanishes
- LOG304｜画像認識と物体検出を学び直す Log#6 | 重心・面積・外接矩形・円形度 ― 紙を回すと壊れるのはどれか｜/record/what-circularity-actually-measures
- LOG309｜画像認識と物体検出を学び直す Log#7 | 特徴点マッチングは、別の物の写真も「同じ」と判定した｜/record/same-place-different-object
- LOG310｜画像認識と物体検出を学び直す Log#8 | 斜めに撮った紙を真上から見た形に直す｜/record/tilted-plane-to-flat
- LOG313｜画像認識と物体検出を学び直す Log#9 | 用語を下から積み直す ― モデル・学習・推論から基盤モデルまで｜/record/vocabulary-of-modern-vision
- LOG317｜画像認識と物体検出を学び直す Log#10 | SAM 3 はガラス瓶とペットボトルを同じ物として切り出した｜/record/sam3-first-look-sorting-line
- LOG325｜画像認識と物体検出を学び直す Log#11 | Decisions API は、持ち上がったかを判定できなかった｜/record/decisions-api-grasp-check
- 459｜画像認識と物体検出を学び直す Log#12 | 画像認識の答えの形を、ロボットアームの写真1枚で見せる｜/record/arm-photo-six-vision-outputs


### その他のシリーズの本数
- ひとり研究所の裏側: 80本
- Consideration: 7本
- UV-C農業ロボット: 2本
```


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

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

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

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

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

AIに原因調査を頼み、「病院の通れない所を直すと、搬送ロボットの問題が増えた」のログに来た。現場に近づけるほど結果が悪くなり、経路やロボットの設定を直し続けている。この結果を導入判断の資料に使ってよいのか、自信が持てない。

この人が次の修正に着手する前に開く、点検用のページにする。

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

詰まりを生んだシミュレーション側の前提と、その発見の経緯を照合し、自分の検証で先に確かめる箇所を決められる。

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

**仮に置いた職員の動きが、搬送ロボットの問題を作っていた。**

病院の通れない所を直すと、シミュレーション内の問題が増えました。  
その後、原因として見えてきたのは、職員に仮で与えていた動きでした。  
この経緯を起点に、詰まりを直す前に点検したいモデルの前提をたどります。

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

**「観測した問題」と「原因として判明したモデルの作り」を、対で読める点検表。**

中心に置くのは、病院の通行不能箇所を修正すると問題が増えた記録と、問題が職員の仮の動きから来ていたと分かった記録。その隣に、配膳ロボットを線に縛った作りによる詰まりと、待機点への入り方による止まり合いを並べる。

各行には「観測したこと／原因として分かったこと／元ログ／自分の環境で確認する問い」を置く。確認する問いは、このページの編集として明記する。

たとえば「職員の移動に、仮の設定が残っていないか」。読者が持ち帰るのは一般論のチェックリストではなく、**実際に原因を取り違えうる作りが露出した記録付きの点検表**になる。

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

**第1節｜病院を直したら、問題が増えた**

使うログ：  
`/record/hospital-transport-robot-blocked-paths-more-conflicts`  
`/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves`

通れない所の修正後に問題が増え、その問題が職員の仮の動きから来ていた、という順で見せる。「問題件数が増えた」という結果だけでは原因を決められなかった経緯を、このページの出発点にする。実病院での発生件数とは扱わない。

**第2節｜経路の作りが、詰まりを生んでいた**

使うログ：  
`/record/serving-robot-fixed-route-jam`  
`/record/serving-robot-map-planner`

ロボットを線に縛った作りが詰まりの元になり、地図を渡すと詰まりが減った事実を示す。点検表には「自分のモデルで、移動の自由をどう制限しているか」という問いを添える。地図を渡せばどの現場でも解決する、とは広げない。

**第3節｜台数を増やすと、モデルの穴が見えた**

使うログ：  
`/record/large-restaurant-five-serving-robots-longer-wait`  
`/record/serving-robots-jam-cause-standby-entry`

大型店で配膳ロボットを5台にした検証がシミュレーションの穴を露出させ、その後、止まり合いの原因が待機点への入り方にあると分かった経緯を扱う。「5台は多すぎる」という導入上の結論にはしない。5台は当該ログの実験条件として記す。

**第4節｜比較する土台を、先に確かめる**

使うログ：  
`/record/audit-simulator-before-unity`  
`/record/serving-robot-stage-b-18-runs`

立体の店に合わせる前に試算を点検したこと、ロボットなしの条件では試算と立体シミュレーションが合ったことを示す。照合が成立した条件を明記し、ロボットあり・実店舗まで検証済みとは読めない形にする。

**第5節｜次に直す箇所を、点検表に残す**

使うログ：  
`/record/check-serving-robot-sim-with-phone`  
`/record/serving-robot-sim-ready-for-store-data`

店のスマホで測って試算を確かめる取り組みと、店で測った数字を受け取って試算を直せる準備を示す。

点検表の末尾に「自分の環境では未確認の前提／次に取る観測／照合するログ」の記入欄を置く。これは新しい検証結果ではなく、読者用の整理欄。現場データによる検証が完了したとは書かない。

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

上記構成に挙げた以下のログを束ねる。

- `/record/hospital-transport-robot-blocked-paths-more-conflicts`
- `/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves`
- `/record/serving-robot-fixed-route-jam`
- `/record/serving-robot-map-planner`
- `/record/large-restaurant-five-serving-robots-longer-wait`
- `/record/serving-robots-jam-cause-standby-entry`
- `/record/audit-simulator-before-unity`
- `/record/serving-robot-stage-b-18-runs`
- `/record/check-serving-robot-sim-with-phone`
- `/record/serving-robot-sim-ready-for-store-data`

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

トップの「導入前ガイド」にページ名で追加する。相談窓口は設けない。

`/series8` の資料部分から「シミュレーションの前提を点検する」として送る。シリーズ一覧を通読する前に、困り事から入れる位置に置く。

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

個々のログの形式は変えず、本ページの各事例から元ログの全文・コード・素材へ送る。

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

依頼の集計と同じく、人の操作があった表示を対象にする。まず本ページの表示が30件たまるまで判断しない。30件は依頼で定められた判断保留の基準で、十分な検証数を保証する数字とは扱わない。

見るのは、本ページから元ログへ進んだ件数と割合、点検表のある位置まで読んだ割合、再訪した人数。保存そのものは測れないため、再訪は参考にとどめる。

AIサービスのリンクからの来訪と、AI利用者の依頼による取得も分けて記録する。区分ごとの件数が30件未満なら、その差は判断できないとする。

元ログへの遷移だけで再現成功とは数えない。**このページで自分の検証を再開できる人が増えたか**を確かめる入口の数字として使う。
```


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

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

---

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

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

- 職員の仮の動き（Log#44）と、線に縛った作り（Log#11）は、ログの題が「作り」が原因だと言っています。
- 待機点への入り方（Log#36）は違います。その次に「止まり合いを減らす3つの決まり」（Log#37）が続いています。店の運用で起きることを見つけた記録とも読めます。

これを「モデルの作り」と同じ列に入れると、読者が本物の詰まりを作りのせいだと見誤るおそれがあります。この点検表が防ぎたい取り違えを、表そのものが生んでしまいます。

**こう直す**
表の列を次のように変えます。

> 観測したこと／原因／**原因の側（シミュレーションの作り・現場でも起こりうる・ログで要確認）**／元ログ／自分の環境で確かめる問い

行の例：
- 「病院の通れない所を直すと問題が増えた → 職員の仮の動き → **作り** → Log#43・44」
- 「配膳ロボット2台が待機点で止まり合う → 待機点への入り方 → **ログで要確認**（次の Log#37 で決まりを足して減らしている） → Log#36・37」

この列があれば、ページの約束は「作りのせいを外せば、残った詰まりは導入判断に使える」になります。ずっと強い約束です。

---

### 指摘2【高】Log#35 と Log#36 を原因と結果でつないでいるのは、ログ一覧からは言えない

**弱い所**
第3節の「5台で穴が見え、その後、止まり合いの原因が待機点への入り方と分かった」という書き方は、Log#35 の「穴」の中身が待機点のことだと決めつけています。題からは、その穴が何かは分かりません。

**こう直す**
まず Log#35 の本文で「穴」の中身を確かめます。

- 待機点のことだったなら、そのまま書く。
- 違ったなら、2つを別の行に分けて次のように書く。

> 第3節｜台数を増やすと、シミュレーションの穴が出た
> 大型店に配膳ロボットを5台置くと、待ちが延び、試算の穴が見えました（Log#35）。別の検証では、2台が止まり合う原因は待機点への入り方でした（Log#36）。

ログにある範囲では、これがいちばん強い言い方です。

---

### 指摘3【高】病院の開発者に向けたページなのに、束ねるログ10本のうち8本が配膳ロボット

**弱い所**
Log#43 から来た人は、2節目から店の話が続くと「自分の話ではない」と感じて離れます。ログ一覧には、病院の流れがもっと続けてあります。

- Log#40：外来の廊下を避けて問題を4割減らす
- Log#41：車いすを1%に直す
- Log#42：病院を人ごと再現
- Log#43：通れない所を直すと問題が増えた
- Log#44：原因は職員の仮の動き

特に Log#41 の「車いすを1%に直す」は、シミュレーションの前提の数字を直した記録です。表の1行にそのまま入ります。

**こう直す**
第1節を病院の連なりにして、店の事例は「同じ型が別の現場でも出た」として後ろに置きます。

> 第1節｜病院のシミュレーションを、前提ごと直していった
> 車いすの割合を1%に直し（Log#41）、病院を人ごと再現し（Log#42）、通れない所を直すと問題が増えました（Log#43）。増えた問題の元は、職員に仮で与えていた動きでした（Log#44）。

注意が1つあります。Log#40 の「4割減らす」は、Log#44 で直す前の作りで出した数字かもしれません。本文で確かめるまで、表には「直す前の作りでの結果かどうか、要確認」と書いておきます。それ自体が、この人にとっていちばん役立つ点検の行になります。

---

### 指摘4【高】この人がページにたどり着く道がない

**弱い所**
個々のログの形は変えられません。なので Log#43 から本ページへのリンクは張れません。案のつなぎ方（トップ・/series8・配膳の LP）は、どれも病院の開発者の通り道ではありません。

**こう直す**
この人は AI に原因調査を頼んで来ます。それならページ自体を、AI がその質問の答えとして選べる形にします。依頼の数字でも、AI の利用者の依頼で読みに来た数は週に42〜61件で、トップがいちばん多くなっています。

- 最初の段落を、この人の問いの形で書く。
  > 「シミュレーションを現場に近づけたら、ロボットの問題が増えた。これはロボットのせいか、作りのせいか。病院と店の記録から確かめる表です。」
- 点検表は画像にせず、文字の表で置く。各行に元ログの URL を書く。
- トップの「導入前ガイド」には、ページ名ではなくこの問いの文で載せる。

---

### 指摘5【中】最初の画面の3行目が、読者が得るものを言っていない

**弱い所**
「この経緯を起点に、点検したいモデルの前提をたどります」は、手順の説明です。この人は「たどる」より「先に何を確かめればいいか」を知りたいはずです。

**こう直す**（見出しはそのまま）

> **仮に置いた職員の動きが、搬送ロボットの問題を作っていた。**
> 病院の通れない所を直すと、シミュレーションの中の問題が増えました。元は、職員に仮で与えていた動きでした。
> 病院と配膳ロボットの店で、詰まりの原因がシミュレーションの作りにあった記録を、1枚の表にしました。
> 次の修正の前に、自分の環境で確かめる問いを行ごとに付けています。

数を書く場合は、指摘1で「作り」と確かめられた行の数だけにします（いまの題から言えるのは、Log#44 と Log#11 の2つです）。

---

### 指摘6【中】「作りの穴」の行が少ない。ログ一覧にもっと強い事例がある

**弱い所**
シミュレーションの作りそのものの穴を示すログが、ほかにもあるのに使われていません。

- Log#32「シミュレーションから瞬間移動が消えた」
- Log#13「隠れていた待ちが見えて」
- Log#28「道の線を消すと、詰まりは3割しか拾えない」

**こう直す**
Log#32 を第2節に1行足します。

> 観測したこと：ロボットが瞬間移動していた → 原因の側：作り → 確かめる問い：「自分のシミュレーションで、ロボットや人が途中を飛ばして移動していないか」

開発者がいちばん持ち帰りたくなる行になります。中身（何がなぜ瞬間移動していたか）は本文で確かめてから書きます。Log#28 は「詰まりを見つける仕組みにも見落としがある」という行に使えますが、3割の意味は本文の言い方に合わせます。

---

### 指摘7【中】第5節が「準備ができた」で終わっていて、締めが弱い

**弱い所**
店のスマホで測る話（Log#26・27）を「取り組み」として並べると、終わりがぼやけます。

**こう直す**
「ここから先はまだ確かめていない」という境目として、はっきり書きます。正直に書くほど、点検表として信用されます。

> 第5節｜ここから先は、まだ現場の数字で確かめていない
> ロボットなしの条件では、立体の店と試算は合いました（Log#10）。ロボットありの結果を店の実物で確かめるために、店のスマホで測る方法を作りました（Log#26）。数字が届けば、試算はすぐ直せる形にしてあります（Log#27）。まだ店の数字では確かめていません。

第4節と第5節はこの形で1つにまとめ、「どこまで確かめたか」の節にできます。

---

### 指摘8【低】公開後に見る数字に、比べる相手を置く

**弱い所**
「元ログへ進んだ件数と割合」には比べる相手がありません。また、再訪は保存の目安としては弱いです。

**こう直す**
いまは、ログから別のログへ移る動きが「数件ずつ」しかありません（依頼の数字）。これを比べる相手にします。

> 本ページから、2本以上の元ログへ進んだ表示の数を見る。いまはログからログへ移る動きが数件ずつなので、それを上回るかを見る。30件たまるまでは判断しない。

再訪の欄は外し、AI の利用者の依頼で本ページが読まれた数を週ごとに記録します。こちらのほうが、このページの入口の役目に合っています。

---

## 守るべき尖り

**「現場に近づけたら、結果が悪くなった。原因はロボットではなく、シミュレーションの作りだった」という、失敗の向きの記録を入口にしていること。**

うまくいった結果ではなく、取り違えかけた経緯を差し出すから、同じ所で迷っている開発者が「保存しておきたい」と思います。書き直すときも、見出しを成果の言い方（「問題を4割減らした」など）に変えないでください。
```


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

```markdown
案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回目）

```markdown
【採否】

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

【企画書】

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

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

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

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

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

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

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

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

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

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

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

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

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

実例：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- `/record/hospital-transport-robot-3d-view-wheelchair-share`
- `/record/hospital-transport-robot-full-floor-people-flow`
- `/record/hospital-transport-robot-blocked-paths-more-conflicts`
- `/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves`
- `/record/serving-robot-fixed-route-jam`
- `/record/serving-robot-map-planner`
- `/record/serving-robot-sim-teleport-zero`
- `/record/serving-robot-stage-b-18-runs`
- `/record/serving-robot-sim-ready-for-store-data`

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

実例：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- `/record/hospital-transport-robot-3d-view-wheelchair-share`
- `/record/hospital-transport-robot-full-floor-people-flow`
- `/record/hospital-transport-robot-blocked-paths-more-conflicts`
- `/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves`
- `/record/serving-robot-fixed-route-jam`
- `/record/serving-robot-map-planner`
- `/record/serving-robot-sim-teleport-zero`
- `/record/serving-robot-stage-b-18-runs`
- `/record/serving-robot-sim-ready-for-store-data`

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

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

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

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

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

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

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

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


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

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

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

---

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

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

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

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

---

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

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

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

表に足す行：

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

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

---

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

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

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

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

---

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

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

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

---

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

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

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

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

---

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

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

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

---

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

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

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

---

## 守るべき尖り

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

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


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

```markdown
案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回目）

```markdown
【採否】

- B・1：採る。「4割減った」記録も置き、改善の数字が置かれた前提を問う。ただし、後の記録によって4割減が否定されたとは書かない。
- B・2：採らない。導入目的や補正ループの設計まで広げず、「修正後に問題が増えた開発者」の点検に絞る。
- B・3：一部採る。「3割しか拾えない」を加え、数え方を独立した点検項目にする。残る2本は論点を増やしすぎるため加えない。
- B・4：一部採る。症状から引けて、答えを残せる問いにする。ただし、はい／いいえだけで確認済みと誤認させず、根拠も書ける形にする。
- B・5：一部採る。「ロボットなしなら合った」を節見出しに出す。「合わせたのはそこまで」は、ほかの条件を確かめていないと断定するため使わない。
- B・6：一部採る。リンク文にロボットとシミュレーションを明記する。配膳LP経由も記録し、30件未満では判断しない。
- B・7：一部採る。元ログの素材で同じ条件の前後を示せる場合に限り図を置く。対応を確認できなければ使わない。
- C・1：採らない。「増えた」という個別の事実を「増える」という一般則に変えず、一覧にない「衝突」も加えない。現行見出しの具体性を守る。
- C・2：一部採る。列名を平易にする。ただし、ログにない「すり抜け」「仮の軌道」や、地図を渡すことを正解とする誘導は足さない。
- C・3：採らない。病院でも線に縛った作りが原因だったという根拠はない。店の事例は、病院でも確認する問いとして接続する。
- C・4：一部採る。一致の対象と条件を書かせる問いは強める。「実環境と合った」への置き換えと、「ロボットなしまで」の断定は採らない。
- C・5：一部採る。入力フォームを作らず、コピーして使える点検メモにする。「現場の数字が届いて初めて直せる」とは言わない。

【企画書】

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

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

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

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

設定を直すたびに結果が変わり、次の修正に進むべきか、導入判断の資料に使えるか迷っている。

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

自分の結果を支える仮の設定・問題の数え方・照合条件を記録に照らし、次に確かめる箇所を決められる。

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

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

病院のシミュレーションで、通れない所の修正後に問題が増えました。  
問題の元をたどると、職員に与えた仮の動きでした。  
次の修正の前に、設定・数え方・照合条件を確かめる、出典付きの点検表です。

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

**「直したら増えた」から、自分の前提へ戻れる点検表。**

「起きたこと／記録で分かったこと／確かめた範囲／元ログ／自分の環境で確認すること」を文字の表にする。問いは本ページで編集したものと明記する。

中心になる行は次のとおり。

| 起きたこと | 記録で分かったこと・範囲 | 自分の環境で確認すること |
|---|---|---|
| 病院の通れない所を直すと問題が増えた | 当該シミュレーションでは、職員の仮の動きが問題の元だった | 人の動きに仮置きした設定を列挙し、それぞれの根拠を書けるか |
| 道の線を消して詰まりを検出した | 当該の検出方法では3割しか拾えなかった（ログの数字） | 問題を拾えているか、何と照合したかを書けるか |
| ロボットなしで照合した | 試算と立体シミュレーションが合った | 自分の「合った」は、何と何を、どの条件で比べた結果か |

各行に元ログへのリンクを置く。病院の修正前後を示す既存素材は、比較条件を確認できる場合だけ添える。

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

**第1節｜4割減った記録のあとに、直したら増えた記録がある**

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

外来の廊下を避けて問題を4割減らした記録、通行不能箇所を直すと問題が増えた記録、職員の仮の動きが問題の元だった記録を順に置く。4割は最初のログの結果であり、同条件の連続比較や、後から否定された数字とは扱わない。ここから点検表を始める。

**第2節｜店では、線に縛った作りが詰まりの元だった**

`/record/serving-robot-fixed-route-jam`  
`/record/serving-robot-map-planner`

線に縛った作りが詰まりの元となり、地図を渡すと詰まりが減った事実を示す。病院と同じ原因とはしない。「自分のロボットの移動を制約する設定を、どこで確認できるか」を点検表に加える。

**第3節｜問題が少ないのか、拾えていないのか**

`/record/serving-robot-jam-detection-without-path-lines`

道の線を消すと詰まりを3割しか拾えなかった記録を置く。3割は当該ログの検出結果に限定する。モデルの動きと、問題を数える仕組みを別々に確認するための行にする。

**第4節｜ロボットなしなら、立体シミュレーションと試算は合った**

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

合った事実を明確に示し、照合対象が試算と立体シミュレーション、条件がロボットなしであることを併記する。実店舗との一致には広げない。点検表には「比較対象／条件／一致を確かめた根拠」を残す。

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

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

店で測った数字が届けば試算を直せる準備を示す。現場との一致を確認した結果とは分ける。

末尾に「未確認の前提／次に取る観測／反映する箇所」のコピー用メモを置く。読者は点検表から次の確認対象を選び、必要な元ログへ進む。

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

- `/record/hospital-transport-robot-avoid-outpatient-hall`
- `/record/hospital-transport-robot-blocked-paths-more-conflicts`
- `/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves`
- `/record/serving-robot-fixed-route-jam`
- `/record/serving-robot-map-planner`
- `/record/serving-robot-jam-detection-without-path-lines`
- `/record/serving-robot-stage-b-18-runs`
- `/record/serving-robot-sim-ready-for-store-data`

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

トップの「導入前ガイド」と `/series8` の資料部分に、**「ロボットシミュレーションを直したら問題が増えたときの点検表」**として置く。補足に「病院の搬送・店の配膳の記録から」と添える。

`/serving-robot-one-less-staff` の試算を読む箇所にも置き、本ページからは人員への効き目を検討するリンクで戻す。個々のログの形式は変えず、点検表から全文・コード・素材へ送る。

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

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

点検表への到達率、元ログへの遷移率、同じ訪問で異なる元ログを複数開いた割合を見る。保存・再現成功は閲覧から推定しない。

流入元別にも記録し、各区分が30件未満なら差を判断しない。AIサービスのリンクからの人の来訪と、AI利用者の依頼による取得は分ける。これらは入口の働きを見る補助指標とし、「再現可能な環境の数」に算入しない。
```


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

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

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

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

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

設定を直すたびに結果が変わり、次の修正に進むべきか、導入判断の資料に使えるか迷っている。

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

自分の結果を支える仮の設定・問題の数え方・照合条件を記録に照らし、次に確かめる箇所を決められる。

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

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

病院のシミュレーションで、通れない所の修正後に問題が増えました。  
問題の元をたどると、職員に与えた仮の動きでした。  
次の修正の前に、設定・数え方・照合条件を確かめる、出典付きの点検表です。

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

**「直したら増えた」から、自分の前提へ戻れる点検表。**

「起きたこと／記録で分かったこと／確かめた範囲／元ログ／自分の環境で確認すること」を文字の表にする。問いは本ページで編集したものと明記する。

中心になる行は次のとおり。

| 起きたこと | 記録で分かったこと・範囲 | 自分の環境で確認すること |
|---|---|---|
| 病院の通れない所を直すと問題が増えた | 当該シミュレーションでは、職員の仮の動きが問題の元だった | 人の動きに仮置きした設定を列挙し、それぞれの根拠を書けるか |
| 道の線を消して詰まりを検出した | 当該の検出方法では3割しか拾えなかった（ログの数字） | 問題を拾えているか、何と照合したかを書けるか |
| ロボットなしで照合した | 試算と立体シミュレーションが合った | 自分の「合った」は、何と何を、どの条件で比べた結果か |

各行に元ログへのリンクを置く。病院の修正前後を示す既存素材は、比較条件を確認できる場合だけ添える。

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

**第1節｜4割減った記録のあとに、直したら増えた記録がある**

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

外来の廊下を避けて問題を4割減らした記録、通行不能箇所を直すと問題が増えた記録、職員の仮の動きが問題の元だった記録を順に置く。4割は最初のログの結果であり、同条件の連続比較や、後から否定された数字とは扱わない。ここから点検表を始める。

**第2節｜店では、線に縛った作りが詰まりの元だった**

`/record/serving-robot-fixed-route-jam`  
`/record/serving-robot-map-planner`

線に縛った作りが詰まりの元となり、地図を渡すと詰まりが減った事実を示す。病院と同じ原因とはしない。「自分のロボットの移動を制約する設定を、どこで確認できるか」を点検表に加える。

**第3節｜問題が少ないのか、拾えていないのか**

`/record/serving-robot-jam-detection-without-path-lines`

道の線を消すと詰まりを3割しか拾えなかった記録を置く。3割は当該ログの検出結果に限定する。モデルの動きと、問題を数える仕組みを別々に確認するための行にする。

**第4節｜ロボットなしなら、立体シミュレーションと試算は合った**

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

合った事実を明確に示し、照合対象が試算と立体シミュレーション、条件がロボットなしであることを併記する。実店舗との一致には広げない。点検表には「比較対象／条件／一致を確かめた根拠」を残す。

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

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

店で測った数字が届けば試算を直せる準備を示す。現場との一致を確認した結果とは分ける。

末尾に「未確認の前提／次に取る観測／反映する箇所」のコピー用メモを置く。読者は点検表から次の確認対象を選び、必要な元ログへ進む。

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

- `/record/hospital-transport-robot-avoid-outpatient-hall`
- `/record/hospital-transport-robot-blocked-paths-more-conflicts`
- `/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves`
- `/record/serving-robot-fixed-route-jam`
- `/record/serving-robot-map-planner`
- `/record/serving-robot-jam-detection-without-path-lines`
- `/record/serving-robot-stage-b-18-runs`
- `/record/serving-robot-sim-ready-for-store-data`

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

トップの「導入前ガイド」と `/series8` の資料部分に、**「ロボットシミュレーションを直したら問題が増えたときの点検表」**として置く。補足に「病院の搬送・店の配膳の記録から」と添える。

`/serving-robot-one-less-staff` の試算を読む箇所にも置き、本ページからは人員への効き目を検討するリンクで戻す。個々のログの形式は変えず、点検表から全文・コード・素材へ送る。

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

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

点検表への到達率、元ログへの遷移率、同じ訪問で異なる元ログを複数開いた割合を見る。保存・再現成功は閲覧から推定しない。

流入元別にも記録し、各区分が30件未満なら差を判断しない。AIサービスのリンクからの人の来訪と、AI利用者の依頼による取得は分ける。これらは入口の働きを見る補助指標とし、「再現可能な環境の数」に算入しない。
```


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

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

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

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

- 来る道：「π0.5 を追加学習したのに実機で掴めない」と Google で検索するか、ChatGPT や Claude に聞いて、個々のログに直接来ます。今のサイトに来る人の多くもこの道です。
- 困っていること：学習中の予測はお手本とよく合っているのに、実機では外れます。原因がモデルにあるのか、お手本にあるのか、アームにあるのかを切り分けられません。そのため、借りた GPU の時間を足して、学習の回数を増やそうとしています。

### この人がこのページで得るもの（1文）
学習を増やす前に疑う場所の順番が、自宅の1台のアームで実際に起きた症状と原因の組で手に入ります。

### 最初の画面（見出しと、その下の3行）
**π0.5 の学習を倍にしても、爪は奥へずれた**

自宅の mechArm 270 で π0.5 を追加学習した、フィジカルAI研究室の34本の記録です。
予測はお手本とほぼ一致したのに、実機では爪がブロックに乗りました。
失敗の原因は、浅いお手本と、アームの電源でした。

（3行目の根拠：Log#23「π0.5 の失敗の原因を探ると、浅いお手本だった」、Log#30「ブロックを落とす理由は、まさかの電源不足」）

### 見せ場（このページにしかないもの。ログのどの事実か）
**症状と本当の原因の台帳**を1枚の表にします。各行から元のログへ送ります。

| 実機で見えた症状 | 分かったこと | ログ |
|---|---|---|
| 予測はほぼ一致、実機では爪がブロックに乗る | 予測が合っても、実機で成功するとは限らない | Log#5・#6 |
| 学習を倍にしても、爪が奥へずれる | 学習の量では直らなかった | Log#7 |
| 肩が88°を超える姿勢では動かない | アームの側の制約 | Log#9 |
| 失敗が続く | 浅いつかみのお手本が原因 | Log#23 |
| ブロックを落とす | 電源が足りなかった。5A に替えて落とさなくなった | Log#30・#34 |
| ゲームパッドで直す操作が遅い | 原因は pymycobot の版 | Log#20 |
| 位置2を外す | **公開前に本文で確かめる**（下の注を参照） | Log#28・#29 |

注：Log#29 は、題名が「原因はカメラの傾きではなかった」、URL が「カメラの傾きが原因」と逆の意味になっています。本文で確かめるまで、この行には原因を書きません。

今ある LP は、配膳ロボット、GPU、1年の記録の3本です。失敗の原因を一覧にしたページは、まだありません。大手の研究所が出す成功の動画の裏側として、個人の1台で起きた失敗は、この開発者がほかでは手に入れにくい情報です。

### 構成
1. **予測は合い、実機は外れた**
   - Log#5（/record/pi05-mecharm-lora-2000-steps）：2000ステップで、予測はお手本とほぼ一致した
   - Log#6（/record/pi05-mecharm-first-real-run）：実機では爪がブロックに乗った
2. **学習を倍にしても直らなかった**
   - Log#7（/record/pi05-mecharm-4000-steps）：倍学習しても爪は奥へずれた
   - Log#8（/record/drag-teach-waypoint-replay）：手で教えた動きの再生なら、4回続けて箱に入った。アームそのものは動ける、という切り分けになる
   - Log#9（/record/teach-replay-19-demos）：お手本19本。肩88°を超えた姿勢は動かなかった
3. **お手本を変えると、初めて入った**
   - Log#10：置き場所を変えたお手本で学習し直した
   - Log#11：π0.5 はお手本の「待ち時間」まで覚えた
   - Log#12：初めてブロックを箱に入れた
   - Log#13：お手本の3か所すべてで箱に入れた
   - Log#14：回数で測ると、苦手な置き場所が見えた
4. **人が直す時間を、1回13秒に**
   - Log#15〜#17：失敗を巻き戻して人が直し、その5回で学び直した
   - Log#18：学び直しても、まだ人の直しが要った
   - Log#19〜#22：ゲームパッドで直す形に。1回13秒になった
   - Log#32：人が直す時間を測り、次に縮める所を決めた
5. **原因はモデルの外にあった**（見せ場の表をここに置く）
   - Log#23〜#27：浅いお手本だったと分かり、5か所10本、計50本のお手本で一から学習し直した
   - Log#28・#29：位置2で外れた
   - Log#30・#34：電源不足が分かり、5A に替えた
6. **同じ環境から始めるには**
   - Log#2：借りた GPU で動かした
   - Log#3：要る GPU メモリを測った（数値はログ本文のものだけを使う）
   - 396（/record/why-pi05-runpod-claude-code）：π0.5 と Runpod と Claude Code を選んだ理由
   - LOG234：2TB の外付け SSD を学習データの置き場にした

### 束ねるログ
- 研究室の環境：/record/building-a-physical-ai-lab-at-home、/record/where-learning-data-lives、/record/why-pi05-runpod-claude-code
- π0.5 を動かす：/record/openpi-remote-inference-first-run、/record/pi05-libero-benchmark-first-run、/record/pi05-mecharm-demo-to-inference
- 予測と実機：/record/pi05-mecharm-lora-2000-steps、/record/pi05-mecharm-first-real-run、/record/pi05-mecharm-4000-steps
- 手で教える：/record/drag-teach-waypoint-replay、/record/teach-replay-19-demos
- 学習し直し〜初めて入る：/record/pi05-retrain-five-positions、/record/pi05-learned-the-pauses、/record/pi05-first-block-in-box、/record/pi05-all-three-positions、/record/pi05-weak-position-d
- 人が直す：/record/rewind-and-correct-pi05、/record/rewind-correct-real-arm、/record/retrain-pi05-with-human-corrections、/record/retrained-pi05-still-needs-human-corrections、/record/gamepad-ready-to-correct-mecharm-270、/record/gamepad-moves-mecharm-270-pymycobot-version、/record/gamepad-correction-mecharm-270-settled、/record/gamepad-fixes-mecharm-270-ai-in-13-seconds
- 原因を探す：/record/pi05-failures-traced-to-shallow-grasp-demos、/record/reading-mecharm-270-servo-current-for-learning、/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos、/record/even-ten-demos-per-spot-mecharm-270-reteaching、/record/retrain-pi05-from-base-on-50-even-demos、/record/pi05-even-demos-on-arm-misses-position-2、/record/pi05-position-2-miss-caused-by-camera-tilt、/record/mecharm-270-drops-block-underpowered-adapter、/record/measure-mecharm-270-recovery-time-decide-what-to-cut、/record/mecharm-270-5a-adapter-stops-dropping-block

### 今あるページとのつなぎ方
- **トップ**：「シリーズ」の節で、フィジカルAI研究室の横にこのページへのリンクを置きます。新しいキャッチコピーは足さず、ページ名だけを載せます。
- **シリーズ**：フィジカルAI研究室のシリーズのページの、資料の欄にリンクを足します。
- **今ある LP**：/gpu-buy-or-rent は、50%まで読む人が52%いるのに、75%では10%に落ちます。その手前に「借りた GPU で何が起きたか」としてリンクを置きます。ただし21件しかないので、効果は判断しません。
- **個々のログ**：形式は変えません。リンクはこのページから各ログへ送る一方向だけです。
- **AI に読まれる作り**：表は文章に崩さず、症状・原因・ログの組がそのまま引用されやすい形にします。

### 公開後に見る数字（30件たまるまでは判断しない）
1. **このページから個々のログへ移った割合**：今は、ログからほかのログへの移動が数件ずつしかありません。束ねる入口が回遊を生むかを見る、いちばん大事な数字です。
2. 75%まで読んだ割合：参考として /gpu-buy-or-rent の10%と並べますが、どちらも30件未満のうちは比べません。
3. AI の利用者の依頼で、このページを読みに来た数（ChatGPT-User・Claude-User など）。
4. リンク先のログで、「AIで読む」ボタンが押された数と、コード・素材のファイルが取られた数。どちらも、誰かが同じ環境を作り直そうとした兆しとして見ます。
5. サイト名で検索して来た人の数（今は0）。
```


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

```markdown
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回目）

```markdown
案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回目）

```markdown
【採否】

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

**評者（案C）から**
1. 冒頭をもっと強く：**一部採る。** 2行目には「倍にしても直らなかった」を入れます。「本当の原因はモデルの外」は位置2の外れまで含めてしまい、言い過ぎなので採りません。
2. Log#29 を言い切る：**一部採る。** 題名どおり「カメラの傾きではなかった」と書きます。それ以上の原因は書きません。（エイイチさんへ：Log#29 は題名と URL の意味が逆です。ログの形式は変えない決まりなので、企画書には入れず、ここでお伝えします）
3. 「分かったこと」に具体的な事実を：**一部採る。** 教訓は消して、ログの事実だけを書きます。ただし「故障ではない」「置き場所の偏りが原因」はログにないので採りません。
4. 見せ場を前に出す：**採る。** 評者Aの3のとおり、さらに前の最初の画面の直下に置きます。
5. 得るものを具体的に：**一部採る。** 症状の名前を書き出します。ただし「確認リスト」とは書きません（評者Aの2と同じ理由です）。
6. LP からのリンクの文言：**一部採る。** 文言は尖らせます。リンクを置く理由は、読了率ではなく内容で説明します。
- 守るべき尖りに挙がった「大手の成功動画の裏側」：**採らない。** ログでは裏付けられません。尖りは、Log#7 の見出しと症状の台帳で守ります。

---

【企画書】

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

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

### この人がこのページで得るもの
爪がずれる・姿勢で動かない・位置2を外す・つかんだブロックを落とす、という自分に近い症状から、1台のアームで何を試し、何が分かり、何が残ったかを、元のログで確かめられます。

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

自宅の mechArm 270 で π0.5 を動かした、フィジカルAI研究室の記録34本から、失敗と直し方を症状ごとに抜き出しました。
予測はお手本とほぼ一致したのに、実機では爪がブロックに乗り、学習を倍にしても直りませんでした。
失敗の原因を探ると浅いつかみのお手本で、ブロックを落としていたのは電源不足でした。

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

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

この表がページの核です。各行の「ログ」から元のログへ送ります。

### 構成
1. **いまの症状から、記録を探す**：上の表です。
2. **予測は合い、実機は外れた**：Log#5・#6・#7 の経過を書きます。Log#8 では、手で教えた動きを再生すると、4回続けて箱に入りました。これは、学習後の動きと見比べるための別の記録として置きます。
3. **お手本を変えると、初めて入った**：Log#10（置き場所を変えたお手本で学び直した）、#11（「待ち時間」まで覚えた）、#12（初めて箱に入った）、#13（3か所すべてで入った）、#14（苦手な置き場所が見えた）。
4. **人が直す**：Log#15〜#18（失敗を巻き戻して直し、その5回で学び直したが、まだ直しが要った）、#19〜#22（ゲームパッドで1回13秒に）、#31（待ちを測り、Claude Fable 5.2 の使い所を決めた）、#32（直す時間を測り、縮める所を決めた）、#33（成否の判定を Gemini Decision 1 に任せられるかを試した）。
5. **見つかった原因：浅いお手本と、電源不足**：Log#23〜#27 と #30・#34 です。Log#24 では、手応えを学習に足すため、サーボの電流を読みました。位置2の外れは Log#28・#29 にあり、まだ原因が分かっていない症状として書きます。
6. **使用環境と、動かし始めた記録**：Log#1〜#4、π0.5・Runpod・Claude Code を選んだ理由のログ、学習データを置く SSD のログです。GPU メモリの数値は、ログ本文のものだけを使います。

### 束ねるログ
すべて /record/ の下にあります。
- **研究室 Log#1〜#4：** building-a-physical-ai-lab-at-home、openpi-remote-inference-first-run、pi05-libero-benchmark-first-run、pi05-mecharm-demo-to-inference
- **Log#5〜#9：** pi05-mecharm-lora-2000-steps、pi05-mecharm-first-real-run、pi05-mecharm-4000-steps、drag-teach-waypoint-replay、teach-replay-19-demos
- **Log#10〜#14：** pi05-retrain-five-positions、pi05-learned-the-pauses、pi05-first-block-in-box、pi05-all-three-positions、pi05-weak-position-d
- **Log#15〜#22：** rewind-and-correct-pi05、rewind-correct-real-arm、retrain-pi05-with-human-corrections、retrained-pi05-still-needs-human-corrections、gamepad-ready-to-correct-mecharm-270、gamepad-moves-mecharm-270-pymycobot-version、gamepad-correction-mecharm-270-settled、gamepad-fixes-mecharm-270-ai-in-13-seconds
- **Log#23〜#29：** pi05-failures-traced-to-shallow-grasp-demos、reading-mecharm-270-servo-current-for-learning、reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos、even-ten-demos-per-spot-mecharm-270-reteaching、retrain-pi05-from-base-on-50-even-demos、pi05-even-demos-on-arm-misses-position-2、pi05-position-2-miss-caused-by-camera-tilt
- **Log#30〜#34：** mecharm-270-drops-block-underpowered-adapter、measure-mecharm-270-waits-decide-claude-fable-5-2-role、measure-mecharm-270-recovery-time-decide-what-to-cut、gemini-decision-1-judge-mecharm-270-pick-and-place、mecharm-270-5a-adapter-stops-dropping-block
- **環境：** why-pi05-runpod-claude-code、where-learning-data-lives

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

### 公開後に見る数字
30件未満では判断しません。30件を超えても、件数と見た期間を添えて読みます。
1. 症状の表から、元のログへ進めた割合
2. リンク先での「AIで読む」の数と、コード・素材の取得数。再現に手を付けたかもしれない兆しとして見る補助の数字で、取得しただけでは再現できたと数えません。
3. AI の利用者の依頼で、このページを読みに来た数
4. サイト名で検索して来た人の数（今は0）
```


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

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

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

### この人がこのページで得るもの
爪がずれる・姿勢で動かない・位置2を外す・つかんだブロックを落とす、という自分に近い症状から、1台のアームで何を試し、何が分かり、何が残ったかを、元のログで確かめられます。

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

自宅の mechArm 270 で π0.5 を動かした、フィジカルAI研究室の記録34本から、失敗と直し方を症状ごとに抜き出しました。
予測はお手本とほぼ一致したのに、実機では爪がブロックに乗り、学習を倍にしても直りませんでした。
失敗の原因を探ると浅いつかみのお手本で、ブロックを落としていたのは電源不足でした。

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

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

この表がページの核です。各行の「ログ」から元のログへ送ります。

### 構成
1. **いまの症状から、記録を探す**：上の表です。
2. **予測は合い、実機は外れた**：Log#5・#6・#7 の経過を書きます。Log#8 では、手で教えた動きを再生すると、4回続けて箱に入りました。これは、学習後の動きと見比べるための別の記録として置きます。
3. **お手本を変えると、初めて入った**：Log#10（置き場所を変えたお手本で学び直した）、#11（「待ち時間」まで覚えた）、#12（初めて箱に入った）、#13（3か所すべてで入った）、#14（苦手な置き場所が見えた）。
4. **人が直す**：Log#15〜#18（失敗を巻き戻して直し、その5回で学び直したが、まだ直しが要った）、#19〜#22（ゲームパッドで1回13秒に）、#31（待ちを測り、Claude Fable 5.2 の使い所を決めた）、#32（直す時間を測り、縮める所を決めた）、#33（成否の判定を Gemini Decision 1 に任せられるかを試した）。
5. **見つかった原因：浅いお手本と、電源不足**：Log#23〜#27 と #30・#34 です。Log#24 では、手応えを学習に足すため、サーボの電流を読みました。位置2の外れは Log#28・#29 にあり、まだ原因が分かっていない症状として書きます。
6. **使用環境と、動かし始めた記録**：Log#1〜#4、π0.5・Runpod・Claude Code を選んだ理由のログ、学習データを置く SSD のログです。GPU メモリの数値は、ログ本文のものだけを使います。

### 束ねるログ
すべて /record/ の下にあります。
- **研究室 Log#1〜#4：** building-a-physical-ai-lab-at-home、openpi-remote-inference-first-run、pi05-libero-benchmark-first-run、pi05-mecharm-demo-to-inference
- **Log#5〜#9：** pi05-mecharm-lora-2000-steps、pi05-mecharm-first-real-run、pi05-mecharm-4000-steps、drag-teach-waypoint-replay、teach-replay-19-demos
- **Log#10〜#14：** pi05-retrain-five-positions、pi05-learned-the-pauses、pi05-first-block-in-box、pi05-all-three-positions、pi05-weak-position-d
- **Log#15〜#22：** rewind-and-correct-pi05、rewind-correct-real-arm、retrain-pi05-with-human-corrections、retrained-pi05-still-needs-human-corrections、gamepad-ready-to-correct-mecharm-270、gamepad-moves-mecharm-270-pymycobot-version、gamepad-correction-mecharm-270-settled、gamepad-fixes-mecharm-270-ai-in-13-seconds
- **Log#23〜#29：** pi05-failures-traced-to-shallow-grasp-demos、reading-mecharm-270-servo-current-for-learning、reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos、even-ten-demos-per-spot-mecharm-270-reteaching、retrain-pi05-from-base-on-50-even-demos、pi05-even-demos-on-arm-misses-position-2、pi05-position-2-miss-caused-by-camera-tilt
- **Log#30〜#34：** mecharm-270-drops-block-underpowered-adapter、measure-mecharm-270-waits-decide-claude-fable-5-2-role、measure-mecharm-270-recovery-time-decide-what-to-cut、gemini-decision-1-judge-mecharm-270-pick-and-place、mecharm-270-5a-adapter-stops-dropping-block
- **環境：** why-pi05-runpod-claude-code、where-learning-data-lives

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

### 公開後に見る数字
30件未満では判断しません。30件を超えても、件数と見た期間を添えて読みます。
1. 症状の表から、元のログへ進めた割合
2. リンク先での「AIで読む」の数と、コード・素材の取得数。再現に手を付けたかもしれない兆しとして見る補助の数字で、取得しただけでは再現できたと数えません。
3. AI の利用者の依頼で、このページを読みに来た数
4. サイト名で検索して来た人の数（今は0）
```


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

```markdown
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回目）

```markdown
案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回目）

```markdown
【採否】

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

**評者（案Cの作者）から**
1. 冒頭の導入に絶望感が足りない：**一部採る**。ずれの結果を先に出し、具体的な数字を足しました。「小型アーム特有の物理の罠」は採りません。ログにない一般化ですし、浅いお手本は物理の問題ではないからです。
2. 表の記述が淡白：**一部採る**。「4000ステップ」「5A」「まさかの電源不足」はログにあるので使います。一方、88°を「特定した」と書くのは見出しより言い過ぎなので、採りません。
3. Log#8 を切り分けの事実として打ち出す：**一部採る**。爪のずれの行で、見比べる記録として並べます。ただし「ハードではなく推論の問題」とは書きません。後の Log#30 で電源不足というハードの原因が出ているので、言い切れないからです。
4. 位置2を「いま直面している壁」と書く：**一部採る**。弱気な書き方はやめ、「一から学び直しても外し、疑った原因も違った」と強く書きます。「いま」の壁だとはログ一覧からは言えないので、そこは採りません。
5. 「人が直す」の章の目的が見えない：**一部採る**。見出しを「AI の失敗を、人が直す時間を縮める」にしました。「執念」のような煽る言葉は使いません。
6. 原因の見出しが答えを明かしている：**採らない**。保存して見返す台帳なので、答えが見出しにあることがこのページの価値です。「物理環境の穴」という言い方も、浅いお手本を言い当てていません。

---

【企画書】

### ページの名前と 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 を並べず、依頼のログ一覧を指す形にしました。全部並べるほうがよければ、構成の節を短くして並べ直します。
```


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

```markdown
### ページの名前と 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版）

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

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

### この人がこのページで得るもの
モデルの調整に逃げる前に、電源・お手本の深さ・修正ループといった「物理世界の前提」を整えるべきだという確信と、その具体的な検証手順。

### 最初の画面
**AIのコードを疑う前に。フィジカルAIが実機で動かない「物理の罠」**
モデルの予測はお手本と一致しているのに、実機のアームはブロックを落とす。
原因はAIの賢さではなく、浅いお手本と、まさかの電源不足だった。
自宅にフィジカルAIの環境を作り、失敗から立ち直るループを回した泥臭い記録。

### 見せ場
高度なAIモデル（π0.5）がブロックを落とす原因が、推論の失敗ではなく「アダプターの電源不足」であり、5Aに替えたら落とさなくなったという事実。そして、失敗の根本原因が「浅いお手本」にあり、電流を読んで手応えを確かめながらゲームパッドで深く掴むように教え直した事実。AIの知能を疑う前に潰すべき、物理空間の泥臭い現実を見せる。

### 構成
**1. 予測は合っているのに、実機は失敗する**
最新のモデル（π0.5）を学習させ、予測はお手本とほぼ一致した。しかし実機を動かすと、爪がブロックに乗ったり、奥へずれたりする。モデルを倍の4000ステップ学習させても解決しなかった事実を提示し、「コード上の成功」と「実機での成功」の壁を示す。
- 341｜Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致（/record/pi05-mecharm-lora-2000-steps）
- 345｜Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った（/record/pi05-mecharm-first-real-run）
- 348｜Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた（/record/pi05-mecharm-4000-steps）

**2. まさかの物理的要因（電源不足）**
モデルの学習不足を疑う前に、ハードウェアの限界を疑う。ブロックを落とす原因は、AIの判断ミスではなく、アームの電源不足だった。5Aのアダプターに替えるだけで落とさなくなった事実を挙げ、物理環境の前提を疑う重要性を説く。
- 487｜mechArm 270 がブロックを落とす理由は、まさかの電源不足（/record/mecharm-270-drops-block-underpowered-adapter）
- 504｜mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった（/record/mecharm-270-5a-adapter-stops-dropping-block）

**3. お手本の「深さ」と「手応え」**
失敗のもう一つの原因は、人が教えたお手本が「浅かった」こと。視覚（カメラ）だけに頼るのではなく、サーボの電流を読んで手応えを学習に足し、ゲームパッドを使って深くつかむお手本を教え直した過程を書く。
- 460｜π0.5 の失敗の原因を探ると、浅いお手本だった（/record/pi05-failures-traced-to-shallow-grasp-demos）
- 461｜手応えを学習に足すため、mechArm 270 の電流を読んだ（/record/reading-mecharm-270-servo-current-for-learning）
- 463｜深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した（/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos）

**4. 失敗を人が直して、学び直すループ**
完璧な一発を狙うのではなく、失敗を人が直して学習に組み込む。ゲームパッドでの修正を1回13秒に縮め、5か所10本ずつ、計50本の均等なお手本で一から学び直させる環境を作った事実を書く。
- 450｜mechArm 270 の AI の直しが、ゲームパッドで1回13秒に（/record/gamepad-fixes-mecharm-270-ai-in-13-seconds）
- 417｜人が直した mechArm 270 の5回で π0.5 を学び直す（/record/retrain-pi05-with-human-corrections）
- 479｜偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に（/record/even-ten-demos-per-spot-mecharm-270-reteaching）
- 480｜浅いつかみの癖を残さず、π0.5 を50本で一から学習（/record/retrain-pi05-from-base-on-50-even-demos）

**5. 環境を固定し、次の課題へ**
物理の穴を塞ぎ、修正のループが回るようになって初めて、AIの本当の評価ができる。成否判定の自動化や、待ち時間の計測へ進むための土台ができたことを示す。
- 492｜mechArm 270 を人が直す時間を測り、縮める先を決めた（/record/measure-mecharm-270-recovery-time-decide-what-to-cut）
- 497｜アームの成否判定を Google の Gemini Decision 1 に任せられるか（/record/gemini-decision-1-judge-mecharm-270-pick-and-place）

### 束ねるログ
- /record/pi05-mecharm-lora-2000-steps
- /record/pi05-mecharm-first-real-run
- /record/pi05-mecharm-4000-steps
- /record/mecharm-270-drops-block-underpowered-adapter
- /record/mecharm-270-5a-adapter-stops-dropping-block
- /record/pi05-failures-traced-to-shallow-grasp-demos
- /record/reading-mecharm-270-servo-current-for-learning
- /record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- /record/gamepad-fixes-mecharm-270-ai-in-13-seconds
- /record/retrain-pi05-with-human-corrections
- /record/even-ten-demos-per-spot-mecharm-270-reteaching
- /record/retrain-pi05-from-base-on-50-even-demos
- /record/measure-mecharm-270-recovery-time-decide-what-to-cut
- /record/gemini-decision-1-judge-mecharm-270-pick-and-place

### 今あるページとのつなぎ方
- **トップページ**：シリーズ一覧の直前に「実機で学ぶフィジカルAIの記録」としてこのLPへのリンクを置き、開発者層を直接引き込む。
- **シリーズ**：「フィジカルAI研究室」のシリーズトップ（/series）の上部に配置し、37本あるログを読み始める前の「見取り図」として機能させる。
- **今ある LP**：/gpu-buy-or-rent（GPU は買うか借りるか）の末尾から、「GPU環境が整い、モデルを学習させたら、次は実機の壁へ」という文脈でこのページへつなぐ。

### 公開後に見る数字
※どの数字も30件たまるまでは「判断できない」として扱う。
- このLPの読了率（25%/50%/75%）。特に最後まで読まれたか（スクロール深度）。
- このLPから、個別のログ（特に「電源不足」や「浅いお手本」のログ）への遷移数。
- AIの利用者の依頼（ChatGPT等）からの流入が、このLPに直接着地するか、またはトップからこのLPへ遷移するか。
```


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

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

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

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

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

   > **予測は合う。実機はつかめない。π0.5とmechArm 270の失敗を切り分ける**
   >
   > 予測はお手本とほぼ一致した。それでも実機では爪がブロックに乗り、倍学習しても奥へずれた。  
   > その後の検証では、浅いつかみのお手本が見つかり、電源を5Aに替えるとブロックを落とさなくなった。何を疑い、何を変え、結果がどう変わったかをたどる。

2. **【高】学び直した後の失敗を省き、解決した印象で閉じている**

   **弱い所：** 50本で一から学習したところから「物理の穴を塞ぎ」「AIの本当の評価ができる」へ進むため、学び直しが成功を保証したように見えます。ログ484には、50本で学習した後も位置2で外れた記録があります。

   **こう直せばもっと強くなる：** 480の直後に484・486を加え、最終章も書き換えます。

   > **学び直しても、位置2では外れた**
   >
   > 50本で一から学習した後も、実機では位置2で外れた（ログ484）。その理由は、カメラの傾きではなかった（ログ486）。電源交換で落下がなくなった結果と、狙った位置でつかめるかの評価を分けて読む。

   「直せば動く」という約束より、**どの問題が残ったかまで追えること**が、この読者には価値になります。

3. **【高】電流を読んだことが、学習への組み込み完了に変わっている**

   **弱い所：**「サーボの電流を読んで手応えを学習に足し」は、提示されたログ一覧では裏づけられません。ログ461が示すのは、学習に足すために電流を読んだ段階です。電流を確かめながらお手本を教え直した、という接続も一覧だけでは確認できません。

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

   > 浅いつかみのお手本が失敗の原因として見つかった（ログ460）。手応えを学習に足すためにサーボの電流を読み（ログ461）、ゲームパッドで深くつかむお手本を教え直した（ログ463）。電流を読む試みと、お手本の作り直しを、それぞれの記録で確かめる。

4. **【中】「具体的な検証手順」を約束しているのに、構成は経緯の紹介で止まっている**

   **弱い所：** 読者は自分のアームの前で使えるものを求めています。現状では読み終えても、どの症状ならどのログへ戻ればよいかが残りません。

   **こう直せばもっと強くなる：** 冒頭の直後に、保存して参照できる案内を置きます。

   | 今起きていること | この記録で確かめること | 読むログ |
   |---|---|---|
   | 予測は合うが、実機では爪が乗る・奥へずれる | 学習を増やした後、実機の結果がどう変わったか | 341・345・348 |
   | つかみが浅い | お手本の問題をどう見つけ、教え直したか | 460・463 |
   | つかんだブロックを落とす | 電源不足を調べ、交換後に何が変わったか | 487・504 |

   表には「mechArm 270での記録。別の機体の原因を断定するものではありません」と添えます。各リンクも「詳しく読む」ではなく、**「電源交換前後の記録を見る」**のように、確かめられる内容を明示します。

5. **【高】別の修正・学習の記録が、一続きの完成したループに見える**

   **弱い所：**「1回13秒」「人が直した5回」「5か所10本ずつの50本」が並ぶことで、13秒の修正をそのまま50本の学習へ回したように読めます。また、電源交換のログ504を先に見せた後、492・497を「次の課題」と呼ぶと、実際の経緯とも混同します。

   **こう直せばもっと強くなる：** 修正操作と学習を分け、章順の意味も明記します。

   > **人が直す操作と、学び直しを分けて見る**
   >
   > ゲームパッドでAIの動きを直す操作は、ログ450で1回13秒になった。人が直した5回での学び直しはログ417に、5か所10本ずつのお手本による学習はログ479・480に残っている。それぞれ、何を直し、何を学習に使ったかを追う。

   最終章は「次の課題へ」から、**「人が直す時間と、成否判定も確かめる」**へ変更。「以下は検証の観点ごとに並べています」と添えれば、電源の見せ場を前に出せます。

6. **【中】入口の配置に、未確認のURLと届き方への期待がある**

   **弱い所：**「フィジカルAI研究室」のURLを `/series` としていますが、依頼にあるのは `/series1〜8` で、対応は未確認です。また、トップは人の表示367件中40件という実測です。トップへの追加だけでは、個別ログへ直接来る読者に届く理由が弱いままです。

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

   > 「フィジカルAI研究室」の既存シリーズページ上部に置く。対応するURLは公開前に確認する。リンク文は「予測は合うのに実機でつかめないときの検証記録」。  
   > `/gpu-buy-or-rent` の末尾には「学習後、実機でつかめないときに読む」を置く。トップのシリーズ一覧直前にも同じページへの入口を置く。

   直接来訪への対応は、**このLP自体が症状から内容を理解できる見出し・説明を持つこと**まで企画に書き込みます。

7. **【高】人の行動とAIの取得、スクロールと読了が混ざっている**

   **弱い所：** AIの利用者の依頼による取得と、人がChatGPTのリンクから訪れることは別です。また、75%到達は最後まで読んだ証拠ではありません。「30件」の対象も曖昧です。

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

   > 人の閲覧では、LPの表示数、25%・50%・75%への到達率、個別ログへの遷移数と遷移率を見る。人の表示が30件未満の間は効果を判断しない。30件に達した後も、少数のクリックで結論を出さない。  
   > AIによる取得件数と、AIサービスのリンクから来た人の件数は分けて記録する。  
   > ログへの遷移は、再現に必要な記録へ進んだ兆候として扱い、環境を再現できた人数とは数えない。

**守るべき尖り**

**モデルの予測がお手本に合っていても、実機の成功には届かないことを、自分の失敗と変更前後の記録で見せる点。** とくに電源を5Aに替えて落とさなくなった事実は強い見せ場です。この具体性を、一般的な「実機では環境が大事」という説明へ薄めないでください。
```


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

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

評者：案Bの作者

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

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

- 予測がお手本とほぼ一致した直後の失敗は「爪がブロックに乗った」（345）と「爪が奥へずれた」（348）です。ブロックを落としてはいません。
- 「ブロックを落とす」は Log#30（487）で出た別の失敗で、原因は電源でした。
- 「浅いお手本」は π0.5 の失敗の原因（460）で、落とす失敗の原因ではありません。

さらに 504 でわかるのは「落とさなくなった」ことまでです。π0.5 の成功率が上がったとはログに書かれていません。今の文面では「電源を替えたら AI が成功するようになった」と読めてしまい、言い過ぎになります。

**こう直す**
> **学習を倍にしても、爪は奥へずれた。**
> Physical Intelligence の π0.5 は、予測ではお手本とほぼ一致していた。それでも実機のアームはうまくつかめなかった。
> 原因を探ると、ひとつは浅いお手本だった。もうひとつ、ブロックを落とす原因は、アームの電源不足だった。5A のアダプターに替えると、ブロックを落とさなくなった。

症状と原因を1つずつ組にすれば、電源の話の強さを保ったまま正確になります。

## 2.【高】章の並びが、実際に起きた順と逆になっている。逆にしないほうが強い

**弱い所**
今の構成は「2. 電源 → 3. 浅いお手本 → 4. 50本で学び直し」の順です。実際には、浅いお手本（460）→ 教え直し（463）→ 50本で一から学習（480）→ 位置2 で外れる（484）と進み、その後の Log#30（487）でようやく電源不足が見つかっています。「モデルより先に物理を疑え」と並べると、最初から物理を疑ったように読めます。その分、記録の重みが消えてしまいます。

**こう直す**
起きた順のまま並べて、最後の章を電源にします。

> 4. 50本で一から学び直しても、位置2 で外れた（479・480・484）
> 5. Log#30 で見つかったのは、電源不足だった（487・504）
> 「お手本を疑い、学習を一からやり直したあとで、原因のひとつはアダプターだったとわかった。だから次にアームを動かす人は、最初に電源を確かめてほしい。」

後になってわかった教訓として書くほうが、「保存しておきたい」と思われます。

## 3.【高】461 を言い過ぎている

**弱い所**
「サーボの電流を読んで手応えを学習に足し」「電流を読んで手応えを確かめながら…教え直した」と書いていますが、461 のタイトルは「手応えを学習に足すため、mechArm 270 の電流を読んだ」です。電流は読みましたが、学習に足したとも、教え直すときに使ったとも書かれていません。

**こう直す**
> カメラの映像だけでは、つかみの深さがわからない。手応えを学習に足すために、まず mechArm 270 のサーボの電流を読んだ（461）。そのうえで、深くつかむお手本をゲームパッドで教え直した（463）。

## 4.【中】読み手の姿に、ログにない「Loss」と「シミュレーション」が入っている。題名の「コード」もずれている

**弱い所**
「シミュレーション環境やLossの数値は良好」と書いていますが、このシリーズのログに Loss もシミュレーションも出てきません。また、この読み手が疑っているのは学習済みのモデルとお手本で、「コード」ではありません。題名の「AIのコードを疑う前に」は、相手の悩みとずれています。

**こう直す**
- 誰に：「π0.5 などの公開モデルを自分のアームで追加学習した。予測はお手本とほぼ一致したのに、実機ではつかめない。学習を増やすか、お手本を増やすかで迷っている開発者」
- 題名：「**モデルを疑う前に。π0.5 が実機でつかめなかった理由を探した記録**」

（「物理の罠」という言い方は、第5章の見出しで使えば残せます）

## 5.【中】成功したログを外していて、失敗の話の説得力が落ちている

**弱い所**
第1章から第3章が失敗だけでできています。そのため「AI がまったく動かなかった話」に見えてしまいます。

実際には、π0.5 は初めてブロックを箱に入れ（361）、お手本の3か所すべてで箱に入れています（363）。そのあと回数で測ると、苦手な置き場所が見えました（401）。学び直した π0.5 でも、人の直しが要りました（422）。

**こう直す**
第1章の終わりに次の文を足します。

> 「位置を変えたお手本で学び直すと、π0.5 は3か所すべてで箱に入れた（363）。ところが回数で測ると、苦手な置き場所が見えた（401）。1回の成功では、実機で使えるかはわからない。」

第4章には 422 を足します。

> 「学び直した π0.5 でも、人の直しは要った（422）。だから直す手間のほうを、ゲームパッドで1回13秒にした（450）。」

一度は成功したと書いてあるほうが、そのあとの失敗の話を信じてもらえます。

## 6.【中】「得るもの」に書いた「具体的な検証手順」が、構成のどこにもない

**弱い所**
ログを並べただけで終わっていて、読み手が手元で使えるものが残りません。サイトのいちばんの指標は「再現可能な環境の数」です。そこへつながる出口がありません。

**こう直す**
最後に、ログにある事実だけで作った点検表を置きます。各行からログへリンクします。

> **アームで π0.5 を試す前に、この記録から言える5つ**
> 1. 電源：アダプター不足で、ブロックを落とした。5A に替えると落とさなくなった（487・504）
> 2. お手本の深さ：失敗をさかのぼると、浅くつかむお手本だった（460・463）
> 3. 置き場所の偏り：5か所に10本ずつそろえ、一から学習した（479・480）
> 4. 回数で測る：1回の成功ではなく回数で測ると、苦手な置き場所が見えた（401）
> 5. 直す時間：人の直しはゲームパッドで1回13秒。次に縮める所も測って決めた（450・492）
>
> 各ログに、全文・コード・素材のファイルと「AIで読む」ボタンがあります。

## 7.【中】ほかのページからのつなぎ方に、ずれが3つある

**弱い所と直し方**

- **/gpu-buy-or-rent の末尾**
  - 弱い所：このページを75%まで読んだ人は10%しかいません（21件なので判断はできません）。末尾に置くと、ほとんどの人の目に入りません。
  - 直し方：50%まで読まれている（52%）辺りに置きます。π0.5 をレンタルの GPU で動かしたログ（326・327）の言及の横に「借りた GPU で学習した π0.5 を、実機のアームで試した記録」と添えます。
- **トップに「実機で学ぶフィジカルAIの記録」という見出しを置く案**
  - 弱い所：新しいキャッチコピーを足さない決まりに触れます。
  - 直し方：新しい見出しは作らず、今の「シリーズ」の欄の中に、このページの題名をそのまま1行で置きます。
- **「/series」**
  - 弱い所：番号がありません。フィジカルAI研究室が /series1〜8 のどれなのかは、依頼の資料からはわかりません。
  - 直し方：「フィジカルAI研究室のシリーズのページ（番号は確認する）の資料の下」と書きます。

最後に注意を1つ書きます。486 は、タイトル（「カメラの傾きではなかった」）と URL（…caused-by-camera-tilt）の意味が逆です。引用するならタイトルの文だけにしてください。わかりにくければ外したほうが安全です。

---

## 守るべき尖り

**「学習を倍にしても直らなかった。原因のひとつはアダプターだった」という食い違い**

最新のモデルの話のつもりで読んでいた開発者が、電源アダプターの話にたどり着きます。この落差は、ログにある事実だけで作れる、この案でいちばん強い所です。書き直しで「ハードウェアも大事」のような一般論に薄めないでください。487 の「まさかの電源不足」と 504 の「5Aに替え、ブロックを落とさなくなった」は、ログのタイトルの言葉のまま見出しに使ってください。
```


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

```markdown
【採否】
A1：採る。事実誤認のため、見出しと冒頭を症状と確認できた事実に寄せる。
A2：採る。事実誤認のため、学び直した後に位置2で外れた記録（484）を追加する。
A3：採る。事実誤認のため、電流を読んだこと（461）と教え直したこと（463）を分ける。
A4：一部採る。検証手順を提示する意図は採るが、形式は評者Bの「点検表」を採用し最後に置く。
A5：採る。事実誤認のため、人の直しと学び直しを分けて記載する。
A6：採る。トップへの新しい見出し追加のルール違反を避け、URLの未確認事項を明記する。
A7：採る。事実誤認のため、AIと人の指標を分け、75%到達を読了と断定しない。
B1：採る。事実誤認のため、爪がずれる・落とす・浅いお手本という別々の事象を正確に分ける。
B2：採る。時系列順に並べ、最後に電源のオチを置いて尖りを強める。
B3：採る。A3と同様、事実誤認を直す。
B4：採る。ログにない事実（Loss、シミュレーション、コード）を外す。
B5：採る。説得力を持たせるため、一度成功した事実（361、363、401、422）を足す。
B6：採る。点検表を最後に置き「再現可能な環境の数」へつなげる。
B7：採る。ルール違反と数字の事実誤認を直し、矛盾のある486は外す。

【企画書】

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

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

### この人がこのページで得るもの
モデルの調整に逃げる前に、電源・お手本の深さ・修正ループといった「物理世界の前提」を整えるべきだという確信と、自分のアームの前で使える5つの点検表。

### 最初の画面
**学習を倍にしても、爪は奥へずれた。**
Physical Intelligence の π0.5 は、予測ではお手本とほぼ一致していた。それでも実機のアームはうまくつかめなかった。
原因を探ると、ひとつは浅いお手本だった。もうひとつ、ブロックを落とす原因は、アームの電源不足だった。5A のアダプターに替えると、ブロックを落とさなくなった。何を疑い、何を変え、結果がどう変わったかをたどる。

### 見せ場
最新のモデル（π0.5）で予測が合っているのに実機で失敗する状況から、お手本の深さや置き場所の偏りを疑い、一から学習をやり直した「後」に、ブロックを落とす原因が「まさかの電源不足」だったと判明する落差。AIの知能を疑う前に、物理環境の前提を疑う泥臭い現実を見せる。

### 構成
**1. 予測は合っているのに、実機は失敗する**
π0.5を学習させ、予測はお手本とほぼ一致した。しかし実機を動かすと、爪がブロックに乗ったり、倍学習しても奥へずれたりする。位置を変えたお手本で学び直すと3か所すべてで箱に入れたが、回数で測ると苦手な置き場所が見えた。1回の成功では実機で使えるかわからない事実を示す。
- 341｜Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致（/record/pi05-mecharm-lora-2000-steps）
- 345｜Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った（/record/pi05-mecharm-first-real-run）
- 348｜Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた（/record/pi05-mecharm-4000-steps）
- 363｜Physical Intelligence の π0.5 がお手本の3か所すべてで箱に入れた（/record/pi05-all-three-positions）
- 401｜π0.5 を回数で測ったら、苦手な置き場所が見えた（/record/pi05-weak-position-d）

**2. 失敗を人が直す時間と、浅いお手本の発見**
学び直したπ0.5でも人の直しは要った。そこで直す手間をゲームパッドで1回13秒に縮めた。失敗の原因を探ると浅いお手本だった。カメラの映像だけではつかみの深さがわからないため、手応えを学習に足すためにまずサーボの電流を読み、そのうえで深くつかむお手本をゲームパッドで教え直した。
- 422｜学び直した π0.5 でも mechArm 270 には人の直しが要った（/record/retrained-pi05-still-needs-human-corrections）
- 450｜mechArm 270 の AI の直しが、ゲームパッドで1回13秒に（/record/gamepad-fixes-mecharm-270-ai-in-13-seconds）
- 460｜π0.5 の失敗の原因を探ると、浅いお手本だった（/record/pi05-failures-traced-to-shallow-grasp-demos）
- 461｜手応えを学習に足すため、mechArm 270 の電流を読んだ（/record/reading-mecharm-270-servo-current-for-learning）
- 463｜深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した（/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos）

**3. 50本で一から学び直しても、位置2で外れた**
偏りなく学ばせるため、お手本を5か所に10本ずつそろえ、π0.5を一から学習させた。しかし、50本で学んだπ0.5をアームで試しても、位置2では外れた。学習をやり直すだけでは解決しない問題が残ることを示す。
- 479｜偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に（/record/even-ten-demos-per-spot-mecharm-270-reteaching）
- 480｜浅いつかみの癖を残さず、π0.5 を50本で一から学習（/record/retrain-pi05-from-base-on-50-even-demos）
- 484｜50本で学んだ π0.5 をアームで試し、位置2 で外れた（/record/pi05-even-demos-on-arm-misses-position-2）

**4. まさかの電源不足**
お手本を疑い、学習を一からやり直したあとで、ブロックを落とす別の原因が見つかった。それはAIの判断ミスではなく、アームの電源不足だった。5Aのアダプターに替えるだけで落とさなくなった事実を挙げ、次にアームを動かす人には、最初に電源を確かめてほしいと伝える。
- 487｜mechArm 270 がブロックを落とす理由は、まさかの電源不足（/record/mecharm-270-drops-block-underpowered-adapter）
- 504｜mechArm 270 の電源を5Aに替え、ブロックを落さなくなった（/record/mecharm-270-5a-adapter-stops-dropping-block）

**5. アームで π0.5 を試す前に、この記録から言える5つの点検表**
読者が手元で使える点検表を置く。各行からログへリンクする。
1. 電源：アダプター不足でブロックを落とした。5Aに替えると落とさなくなった（487・504）
2. お手本の深さ：失敗をさかのぼると、浅くつかむお手本だった（460・463）
3. 置き場所の偏り：5か所に10本ずつそろえ、一から学習した（479・480）
4. 回数で測る：1回の成功ではなく回数で測ると、苦手な置き場所が見えた（401）
5. 直す時間：人の直しはゲームパッドで1回13秒（450）
※各ログには、全文・コード・素材のファイルと「AIで読む」ボタンがあることを添える。

### 束ねるログ
- /record/pi05-mecharm-lora-2000-steps
- /record/pi05-mecharm-first-real-run
- /record/pi05-mecharm-4000-steps
- /record/pi05-all-three-positions
- /record/pi05-weak-position-d
- /record/retrained-pi05-still-needs-human-corrections
- /record/gamepad-fixes-mecharm-270-ai-in-13-seconds
- /record/pi05-failures-traced-to-shallow-grasp-demos
- /record/reading-mecharm-270-servo-current-for-learning
- /record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- /record/even-ten-demos-per-spot-mecharm-270-reteaching
- /record/retrain-pi05-from-base-on-50-even-demos
- /record/pi05-even-demos-on-arm-misses-position-2
- /record/mecharm-270-drops-block-underpowered-adapter
- /record/mecharm-270-5a-adapter-stops-dropping-block

### 今あるページとのつなぎ方
- **トップページ**：新しい見出しは作らず、今の「シリーズ」の欄の中に、このページの題名をそのまま1行で置く。
- **シリーズ**：フィジカルAI研究室のシリーズのページ（番号は公開前に確認する）の資料の下に置く。リンク文は「予測は合うのに実機でつかめないときの検証記録」。
- **今ある LP**：`/gpu-buy-or-rent` の50%まで読まれている辺りに置く。π0.5をレンタルのGPUで動かしたログ（326・327）の言及の横に「借りたGPUで学習したπ0.5を、実機のアームで試した記録」と添える。

### 公開後に見る数字
※人の表示が30件未満の間は効果を判断しない。30件に達した後も、少数のクリックで結論を出さない。
- このLPの表示数、25%・50%・75%への到達率（75%到達は最後まで読んだ証拠とはしない）。
- このLPから、個別のログ（電源やお手本など）への遷移数と遷移率。ログへの遷移は、再現に必要な記録へ進んだ兆候として扱う。
- AIによる取得件数と、AIサービスのリンクから来た人の件数は分けて記録する。
```


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

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

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

### この人がこのページで得るもの
モデルの調整に逃げる前に、電源・お手本の深さ・修正ループといった「物理世界の前提」を整えるべきだという確信と、自分のアームの前で使える5つの点検表。

### 最初の画面
**学習を倍にしても、爪は奥へずれた。**
Physical Intelligence の π0.5 は、予測ではお手本とほぼ一致していた。それでも実機のアームはうまくつかめなかった。
原因を探ると、ひとつは浅いお手本だった。もうひとつ、ブロックを落とす原因は、アームの電源不足だった。5A のアダプターに替えると、ブロックを落とさなくなった。何を疑い、何を変え、結果がどう変わったかをたどる。

### 見せ場
最新のモデル（π0.5）で予測が合っているのに実機で失敗する状況から、お手本の深さや置き場所の偏りを疑い、一から学習をやり直した「後」に、ブロックを落とす原因が「まさかの電源不足」だったと判明する落差。AIの知能を疑う前に、物理環境の前提を疑う泥臭い現実を見せる。

### 構成
**1. 予測は合っているのに、実機は失敗する**
π0.5を学習させ、予測はお手本とほぼ一致した。しかし実機を動かすと、爪がブロックに乗ったり、倍学習しても奥へずれたりする。位置を変えたお手本で学び直すと3か所すべてで箱に入れたが、回数で測ると苦手な置き場所が見えた。1回の成功では実機で使えるかわからない事実を示す。
- 341｜Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致（/record/pi05-mecharm-lora-2000-steps）
- 345｜Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った（/record/pi05-mecharm-first-real-run）
- 348｜Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた（/record/pi05-mecharm-4000-steps）
- 363｜Physical Intelligence の π0.5 がお手本の3か所すべてで箱に入れた（/record/pi05-all-three-positions）
- 401｜π0.5 を回数で測ったら、苦手な置き場所が見えた（/record/pi05-weak-position-d）

**2. 失敗を人が直す時間と、浅いお手本の発見**
学び直したπ0.5でも人の直しは要った。そこで直す手間をゲームパッドで1回13秒に縮めた。失敗の原因を探ると浅いお手本だった。カメラの映像だけではつかみの深さがわからないため、手応えを学習に足すためにまずサーボの電流を読み、そのうえで深くつかむお手本をゲームパッドで教え直した。
- 422｜学び直した π0.5 でも mechArm 270 には人の直しが要った（/record/retrained-pi05-still-needs-human-corrections）
- 450｜mechArm 270 の AI の直しが、ゲームパッドで1回13秒に（/record/gamepad-fixes-mecharm-270-ai-in-13-seconds）
- 460｜π0.5 の失敗の原因を探ると、浅いお手本だった（/record/pi05-failures-traced-to-shallow-grasp-demos）
- 461｜手応えを学習に足すため、mechArm 270 の電流を読んだ（/record/reading-mecharm-270-servo-current-for-learning）
- 463｜深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した（/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos）

**3. 50本で一から学び直しても、位置2で外れた**
偏りなく学ばせるため、お手本を5か所に10本ずつそろえ、π0.5を一から学習させた。しかし、50本で学んだπ0.5をアームで試しても、位置2では外れた。学習をやり直すだけでは解決しない問題が残ることを示す。
- 479｜偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に（/record/even-ten-demos-per-spot-mecharm-270-reteaching）
- 480｜浅いつかみの癖を残さず、π0.5 を50本で一から学習（/record/retrain-pi05-from-base-on-50-even-demos）
- 484｜50本で学んだ π0.5 をアームで試し、位置2 で外れた（/record/pi05-even-demos-on-arm-misses-position-2）

**4. まさかの電源不足**
お手本を疑い、学習を一からやり直したあとで、ブロックを落とす別の原因が見つかった。それはAIの判断ミスではなく、アームの電源不足だった。5Aのアダプターに替えるだけで落とさなくなった事実を挙げ、次にアームを動かす人には、最初に電源を確かめてほしいと伝える。
- 487｜mechArm 270 がブロックを落とす理由は、まさかの電源不足（/record/mecharm-270-drops-block-underpowered-adapter）
- 504｜mechArm 270 の電源を5Aに替え、ブロックを落さなくなった（/record/mecharm-270-5a-adapter-stops-dropping-block）

**5. アームで π0.5 を試す前に、この記録から言える5つの点検表**
読者が手元で使える点検表を置く。各行からログへリンクする。
1. 電源：アダプター不足でブロックを落とした。5Aに替えると落とさなくなった（487・504）
2. お手本の深さ：失敗をさかのぼると、浅くつかむお手本だった（460・463）
3. 置き場所の偏り：5か所に10本ずつそろえ、一から学習した（479・480）
4. 回数で測る：1回の成功ではなく回数で測ると、苦手な置き場所が見えた（401）
5. 直す時間：人の直しはゲームパッドで1回13秒（450）
※各ログには、全文・コード・素材のファイルと「AIで読む」ボタンがあることを添える。

### 束ねるログ
- /record/pi05-mecharm-lora-2000-steps
- /record/pi05-mecharm-first-real-run
- /record/pi05-mecharm-4000-steps
- /record/pi05-all-three-positions
- /record/pi05-weak-position-d
- /record/retrained-pi05-still-needs-human-corrections
- /record/gamepad-fixes-mecharm-270-ai-in-13-seconds
- /record/pi05-failures-traced-to-shallow-grasp-demos
- /record/reading-mecharm-270-servo-current-for-learning
- /record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- /record/even-ten-demos-per-spot-mecharm-270-reteaching
- /record/retrain-pi05-from-base-on-50-even-demos
- /record/pi05-even-demos-on-arm-misses-position-2
- /record/mecharm-270-drops-block-underpowered-adapter
- /record/mecharm-270-5a-adapter-stops-dropping-block

### 今あるページとのつなぎ方
- **トップページ**：新しい見出しは作らず、今の「シリーズ」の欄の中に、このページの題名をそのまま1行で置く。
- **シリーズ**：フィジカルAI研究室のシリーズのページ（番号は公開前に確認する）の資料の下に置く。リンク文は「予測は合うのに実機でつかめないときの検証記録」。
- **今ある LP**：`/gpu-buy-or-rent` の50%まで読まれている辺りに置く。π0.5をレンタルのGPUで動かしたログ（326・327）の言及の横に「借りたGPUで学習したπ0.5を、実機のアームで試した記録」と添える。

### 公開後に見る数字
※人の表示が30件未満の間は効果を判断しない。30件に達した後も、少数のクリックで結論を出さない。
- このLPの表示数、25%・50%・75%への到達率（75%到達は最後まで読んだ証拠とはしない）。
- このLPから、個別のログ（電源やお手本など）への遷移数と遷移率。ログへの遷移は、再現に必要な記録へ進んだ兆候として扱う。
- AIによる取得件数と、AIサービスのリンクから来た人の件数は分けて記録する。
```


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

```markdown
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回目）

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

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

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

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

**こう直す**
- 3の終わりに 486 を足し、位置2の話をそこで閉じる。
- 4の書き出しを次のように変える。
  > 位置2の外れとは別に、mechArm 270 はつかんだブロックを落としていた。その理由は、まさかの電源不足だった（487）。5A のアダプターに替えると、ブロックを落とさなくなった（504）。
- 「AIの判断ミスではなく」は、ログの言葉にない対比です。消して、上の文のように事実だけを並べるほうが強くなります。
- 486 は、URL（…caused-by-camera-tilt）と題（カメラの傾きではなかった）が逆のことを言っています。引用する前に本文を確かめ、題の言い方で書いてください。

## 2.【高】ログ一覧にない中身が2か所入っている

**弱い所**
- 見せ場の「最新のモデル（π0.5）」：「最新」はログ一覧にありません。
- 構成2の「カメラの映像だけではつかみの深さがわからないため」：461 の題は「手応えを学習に足すため、電流を読んだ」までです。カメラでは深さがわからない、という理由は一覧の外の話です。

**こう直す**
- 「最新のモデル」は「Physical Intelligence の π0.5」に置き換える。
- 構成2の該当の文は次のようにする。
  > 失敗をさかのぼると、浅くつかむお手本だった（460）。手応えを学習に足すため、まずサーボの電流を読んだ（461）。そのうえで、深くつかむお手本をゲームパッドで教え直した（463）。

  「なぜ電流か」は、461 のリンク先で読者に読んでもらえば足ります。

## 3.【中】最初の画面のいちばん強い一撃が、3段落目に埋もれている

**弱い所**
見出しの「学習を倍にしても、爪は奥へずれた」（348）は事実で、きちんと痛い。ただ、この案のいちばんの落差は「お手本を50本そろえ、一から学び直した。それでも落とす理由は電源だった」の方です。それが本文の後ろに回っています。

**こう直す**（順番はログの番号どおり。因果は足していません）
> **学習を倍にしても、爪は奥へずれた。お手本を50本にそろえて一から学び直した。ブロックを落とす理由は、電源だった。**
>
> Physical Intelligence の π0.5 を mechArm 270 で追加学習した。予測はお手本とほぼ一致した（341）。実機では爪がブロックに乗り（345）、倍学習しても奥へずれた（348）。失敗をさかのぼると浅いお手本で（460）、ブロックを落としていたのは電源不足だった（487）。5A に替えると、落とさなくなった（504）。何を疑い、何を変え、何が変わったかを、順にたどる。

## 4.【中】点検表が「やったことの一覧」で、読者の手元で使える形になっていない

**弱い所**
3「置き場所の偏り」と5「直す時間」は、作者がやったことの報告です。読者が自分のアームの前で「はい・いいえ」で答えられる形になっていません。また、使えるログが2本抜けています。
- 492「人が直す時間を測り、縮める先を決めた」
- 358「π0.5 は『待ち時間』まで覚えた」

**こう直す**（問いの形にして、答えはログの事実で返す）

| 問い | この記録で起きたこと |
|---|---|
| 1. 電源は足りているか | 足りないアダプターではブロックを落とした。5A に替えると落とさなくなった（487・504） |
| 2. お手本は深くつかんでいるか | π0.5 はお手本の待ち時間まで覚えた（358）。失敗をさかのぼると、浅くつかむお手本だった（460・463） |
| 3. お手本は置き場所ごとにそろっているか | 5か所に10本ずつそろえ、一から学習した（479・480）。それでも位置2では外れた（484・486） |
| 4. 1回ではなく、回数で測ったか | 回数で測ると、苦手な置き場所が見えた（401） |
| 5. 人が直す時間を測ったか | ゲームパッドで1回13秒になった（450）。測ったうえで、縮める先を決めた（492） |

3の行に「それでも外れた」まで書いておくと、点検表が成功の宣伝にならず、記録として信用されます。

## 5.【中】「同じ環境から始められる」ための情報がページにない

**弱い所**
サイトでいちばん大事な指標は「再現可能な環境の数」です。ところがこの案には、読者が「自分の環境と同じか」を最初に照らし合わせる場所がありません。また、追加学習の入口のログ 337 が束ねる一覧から抜けています。

**こう直す**
最初の画面のすぐ下に、ログの題にある事実だけで「この記録の条件」という小さな欄を置く。
- アーム：mechArm 270
- モデル：Physical Intelligence の π0.5 を追加学習（337）
- 学習：2000ステップ（341）→ 倍（348）→ お手本50本で一から（480）
- GPU：借りた GPU で動かし、要るメモリを測った（326・327）
- 電源：最後は 5A のアダプター（504）

あわせて、束ねるログに 337 と 486 を足してください。

## 6.【中】ほかのページとのつなぎ方の根拠が、判断できない数字に乗っている

**弱い所**
「/gpu-buy-or-rent の50%まで読まれている辺り」に置く案ですが、このページの表示は21件で、30件に届いていません。依頼の決まりでは「判断できない」数です。

一方で、判断できる数字から言えることがあります。人の多くは Google（90件）と直接（153件）から個々のログに来て、1本読んで出ていきます。AI の利用者の依頼で読みに来た数はトップがいちばん多い。つまり、この LP の主な入口はトップ経由の AI の読み取りです。

**こう直す**
- gpu-buy-or-rent に置く理由は、数字ではなく題材のつながりで書く。
  > 326・327 で π0.5 を借りた GPU で動かした話の続きにあたるため。
- AI がこの LP を読んで答えるとき、そのまま引けるようにする。上の点検表とログの番号を画像にせず、文字の表で置く。
- 「公開後に見る数字」に1行足す。
  > トップから AI がこの LP を取りに来た数（AI の利用者の依頼で読みに来た数のうち、この URL の分）。

## 7.【低】言葉の細かい所

**弱い所 → こう直す**
- 構成4のリンク文「落さなくなった」→ ログの題どおり「落とさなくなった」。
- 「モデルの調整に逃げる前に」の「逃げる」→ 読者を責める響きがあるので「モデルの調整を重ねる前に」。ページ名の「モデルを疑う前に」は、この案の主張そのものなので残してください。

---

## 守るべき尖り

いちばん良いのは、**お手本を疑い、50本で一から学び直すまでAIの側を尽くしたあとに、ブロックを落とす理由が電源だったと出てくる順番**です。点検表の1行目に電源を置いたのも、この順番から来ています。

ほかを書き直すときも、次の2つは崩さないでください。
- 電源の話を最初の段落に出しすぎない
- 点検表の1番は電源のまま

「高いモデルの話を読みに来たら、最初に確かめるべきはアダプターだった」という落差が、この案を保存したくなるページにしています。
```


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

```markdown
【採否】
案A-1：採る。位置2の外れと電源不足の因果を切り離し、事実誤認を防ぐため。
案A-2：採る。「逃げる」という言葉を改め、次に確かめる材料を提示する形にするため。
案A-3：採る。一覧にない「最新のモデル」「カメラの映像だけでは…」を削り事実を守るため。
案A-4：一部採る。「手元のアームと同じ結果になる値ではない」注記は採るが、表は案Bの形式にするため。
案A-5：採る。読者が自分の症状に近い記録へすぐ飛べるようにするため。
案A-6：採る。「学習した」という事実誤認を直し、21件という判断できない数字を根拠から外すため。
案A-7：採る。遷移先を分け、再現完了とは別に扱うことでサイトの指標に合わせるため。
案B-1：採る。486を足し、位置2の外れと電源の話を明確に分けて事実を正すため。
案B-2：採る。一覧にない事実を削り、ルールを厳守するため。
案B-3：一部採る。端的な事実の羅列は採るが、尖りを守るため見出しに「電源」は出しすぎないようにするため。
案B-4：採る。読者が手元で「はい・いいえ」で答えられる問いの形にし、抜けていたログを足すため。
案B-5：採る。「この記録の条件」を置き、読者が自分の環境と照合できるようにするため。
案B-6：採る。AIが引けるように表を文字にし、トップ経由のAI取得数を計測に足すため。
案B-7：採る。「落さなくなった」の誤字修正と、読者を責めない言葉選びにするため。

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

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

### この人がこのページで得るもの
学習を増やすか、お手本を増やすかで迷ったときに、「位置を外す」「浅くつかむ」「つかんでも落とす」を分けて、自分の失敗と照合できる点検表。

### 最初の画面
**学習を倍にしても、爪は奥へずれた。お手本を50本にそろえて一から学び直した。**
Physical Intelligence の π0.5 を mechArm 270 で追加学習した。予測はお手本とほぼ一致した（341）。実機では爪がブロックに乗り（345）、倍学習しても奥へずれた（348）。失敗をさかのぼると浅いお手本で（460）、ブロックを落としていたのは電源不足だった（487）。5A に替えると、落とさなくなった（504）。何を疑い、何を変え、何が変わったかを、順にたどる。

**この記録の条件**
- アーム：mechArm 270
- モデル：Physical Intelligence の π0.5 を追加学習（337）
- 学習：2000ステップ（341）→ 倍（348）→ お手本50本で一から（480）
- GPU：借りた GPU で動かし、要るメモリを測った（326・327）
- 電源：最後は 5A のアダプター（504）

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

### 見せ場
Physical Intelligence の π0.5 で予測が合っているのに実機で失敗する状況から、お手本の深さや置き場所の偏りを疑い、一から学習をやり直した「後」に、ブロックを落とす原因が「まさかの電源不足」だったと判明する落差。AIの知能を疑う前に、物理環境の前提を疑う泥臭い現実を見せる。

### 構成
**1. 予測は合っているのに、実機は失敗する**
π0.5を学習させ、予測はお手本とほぼ一致した。しかし実機を動かすと、爪がブロックに乗ったり、倍学習しても奥へずれたりする。位置を変えたお手本で学び直すと3か所すべてで箱に入れたが、回数で測ると苦手な置き場所が見えた。1回の成功では実機で使えるかわからない事実を示す。
- 341｜Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致（/record/pi05-mecharm-lora-2000-steps）
- 345｜Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った（/record/pi05-mecharm-first-real-run）
- 348｜Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた（/record/pi05-mecharm-4000-steps）
- 363｜Physical Intelligence の π0.5 がお手本の3か所すべてで箱に入れた（/record/pi05-all-three-positions）
- 401｜π0.5 を回数で測ったら、苦手な置き場所が見えた（/record/pi05-weak-position-d）

**2. 失敗を人が直す時間と、浅いお手本の発見**
学び直したπ0.5でも人の直しは要った。そこで直す手間をゲームパッドで1回13秒に縮めた。失敗をさかのぼると、浅くつかむお手本だった。手応えを学習に足すため、まずサーボの電流を読んだ。そのうえで、深くつかむお手本をゲームパッドで教え直した。電流を読む取り組みと、お手本を教え直す取り組みを追う。
- 422｜学び直した π0.5 でも mechArm 270 には人の直しが要った（/record/retrained-pi05-still-needs-human-corrections）
- 450｜mechArm 270 の AI の直しが、ゲームパッドで1回13秒に（/record/gamepad-fixes-mecharm-270-ai-in-13-seconds）
- 460｜π0.5 の失敗の原因を探ると、浅いお手本だった（/record/pi05-failures-traced-to-shallow-grasp-demos）
- 461｜手応えを学習に足すため、mechArm 270 の電流を読んだ（/record/reading-mecharm-270-servo-current-for-learning）
- 463｜深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した（/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos）

**3. 50本で一から学び直しても、位置2で外れた**
偏りなく学ばせるため、お手本を5か所に10本ずつそろえ、π0.5を一から学習させた。しかし、50本で学んだπ0.5をアームで試しても、位置2では外れた。その理由は、カメラの傾きではなかった。
- 479｜偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に（/record/even-ten-demos-per-spot-mecharm-270-reteaching）
- 480｜浅いつかみの癖を残さず、π0.5 を50本で一から学習（/record/retrain-pi05-from-base-on-50-even-demos）
- 484｜50本で学んだ π0.5 をアームで試し、位置2 で外れた（/record/pi05-even-demos-on-arm-misses-position-2）
- 486｜π0.5 が位置2 を外した理由は、カメラの傾きではなかった（/record/pi05-position-2-miss-caused-by-camera-tilt）

**4. まさかの電源不足**
位置2の外れとは別に、mechArm 270 はつかんだブロックを落としていた。その理由は、まさかの電源不足だった。5Aのアダプターに替えると、ブロックを落とさなくなった。位置を外す問題と、落とす問題は分けて読む。
- 487｜mechArm 270 がブロックを落とす理由は、まさかの電源不足（/record/mecharm-270-drops-block-underpowered-adapter）
- 504｜mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった（/record/mecharm-270-5a-adapter-stops-dropping-block）

**5. アームで π0.5 を試す前に、この記録から言える5つの点検表**
AIがそのまま引けるように文字の表で置く。

| 問い | この記録で起きたこと |
|---|---|
| 1. 電源は足りているか | 足りないアダプターではブロックを落とした。5A に替えると落とさなくなった（487・504） |
| 2. お手本は深くつかんでいるか | π0.5 はお手本の待ち時間まで覚えた（358）。失敗をさかのぼると、浅くつかむお手本だった（460・463） |
| 3. お手本は置き場所ごとにそろっているか | 5か所に10本ずつそろえ、一から学習した（479・480）。それでも位置2では外れた（484・486） |
| 4. 1回ではなく、回数で測ったか | 回数で測ると、苦手な置き場所が見えた（401） |
| 5. 人が直す時間を測ったか | ゲームパッドで1回13秒になった（450）。測ったうえで、縮める先を決めた（492） |

※5A・お手本50本・修正13秒は、この実験の値です。手元のアームで同じ結果になることを示す値ではありません。
※各ログには、全文・コード・素材のファイルと「AIで読む」ボタンがあります。

### 束ねるログ
- /record/pi05-mecharm-demo-to-inference (337)
- /record/pi05-mecharm-lora-2000-steps (341)
- /record/pi05-mecharm-first-real-run (345)
- /record/pi05-mecharm-4000-steps (348)
- /record/pi05-learned-the-pauses (358)
- /record/pi05-all-three-positions (363)
- /record/pi05-weak-position-d (401)
- /record/retrained-pi05-still-needs-human-corrections (422)
- /record/gamepad-fixes-mecharm-270-ai-in-13-seconds (450)
- /record/pi05-failures-traced-to-shallow-grasp-demos (460)
- /record/reading-mecharm-270-servo-current-for-learning (461)
- /record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos (463)
- /record/even-ten-demos-per-spot-mecharm-270-reteaching (479)
- /record/retrain-pi05-from-base-on-50-even-demos (480)
- /record/pi05-even-demos-on-arm-misses-position-2 (484)
- /record/pi05-position-2-miss-caused-by-camera-tilt (486)
- /record/mecharm-270-drops-block-underpowered-adapter (487)
- /record/measure-mecharm-270-recovery-time-decide-what-to-cut (492)
- /record/mecharm-270-5a-adapter-stops-dropping-block (504)

### 今あるページとのつなぎ方
- **トップページ**：新しい見出しは作らず、今の「シリーズ」の欄の中に、このページの題名をそのまま1行で置く。
- **シリーズ**：フィジカルAI研究室のシリーズのページの資料の下に置く。リンク文は「予測は合うのに実機でつかめないときの検証記録」。
- **今ある LP**：`/gpu-buy-or-rent` 内に326・327（借りた GPU で動かし、要るメモリを測った記録）への言及があれば、その直後に置く。リンク文は「π0.5の予測は合った。それでも実機でつかめなかった記録」。設置位置は話題のつながりで選ぶ。表示21件の到達率から、位置の効果は判断しない。

### 公開後に見る数字
※人の表示が30件未満の間は効果を判断しない。30件に達した後も、少数のクリックで結論を出さない。
- このLPの表示数、25%・50%・75%への到達率（75%到達は最後まで読んだ証拠とはしない）。
- トップから AI がこの LP を取りに来た数（AI の利用者の依頼で読みに来た数のうち、この URL の分）。
- このLPから、個別のログへの遷移数と遷移率。遷移先を「電源」「お手本」「場所別の評価」「人の修正」に分け、どの点検項目から記録へ進んだかを見る。
- 既存の仕組みで取得できる場合は、コード・素材のファイルへの操作も別に記録する。いずれも再現完了とは数えない。同じ手順で同じ結果に届いたと確認できたものを、再現可能な環境の実績として別に扱う。
```


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

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

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

### この人がこのページで得るもの
学習を増やすか、お手本を増やすかで迷ったときに、「位置を外す」「浅くつかむ」「つかんでも落とす」を分けて、自分の失敗と照合できる点検表。

### 最初の画面
**学習を倍にしても、爪は奥へずれた。お手本を50本にそろえて一から学び直した。**
Physical Intelligence の π0.5 を mechArm 270 で追加学習した。予測はお手本とほぼ一致した（341）。実機では爪がブロックに乗り（345）、倍学習しても奥へずれた（348）。失敗をさかのぼると浅いお手本で（460）、ブロックを落としていたのは電源不足だった（487）。5A に替えると、落とさなくなった（504）。何を疑い、何を変え、何が変わったかを、順にたどる。

**この記録の条件**
- アーム：mechArm 270
- モデル：Physical Intelligence の π0.5 を追加学習（337）
- 学習：2000ステップ（341）→ 倍（348）→ お手本50本で一から（480）
- GPU：借りた GPU で動かし、要るメモリを測った（326・327）
- 電源：最後は 5A のアダプター（504）

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

### 見せ場
Physical Intelligence の π0.5 で予測が合っているのに実機で失敗する状況から、お手本の深さや置き場所の偏りを疑い、一から学習をやり直した「後」に、ブロックを落とす原因が「まさかの電源不足」だったと判明する落差。AIの知能を疑う前に、物理環境の前提を疑う泥臭い現実を見せる。

### 構成
**1. 予測は合っているのに、実機は失敗する**
π0.5を学習させ、予測はお手本とほぼ一致した。しかし実機を動かすと、爪がブロックに乗ったり、倍学習しても奥へずれたりする。位置を変えたお手本で学び直すと3か所すべてで箱に入れたが、回数で測ると苦手な置き場所が見えた。1回の成功では実機で使えるかわからない事実を示す。
- 341｜Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致（/record/pi05-mecharm-lora-2000-steps）
- 345｜Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った（/record/pi05-mecharm-first-real-run）
- 348｜Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた（/record/pi05-mecharm-4000-steps）
- 363｜Physical Intelligence の π0.5 がお手本の3か所すべてで箱に入れた（/record/pi05-all-three-positions）
- 401｜π0.5 を回数で測ったら、苦手な置き場所が見えた（/record/pi05-weak-position-d）

**2. 失敗を人が直す時間と、浅いお手本の発見**
学び直したπ0.5でも人の直しは要った。そこで直す手間をゲームパッドで1回13秒に縮めた。失敗をさかのぼると、浅くつかむお手本だった。手応えを学習に足すため、まずサーボの電流を読んだ。そのうえで、深くつかむお手本をゲームパッドで教え直した。電流を読む取り組みと、お手本を教え直す取り組みを追う。
- 422｜学び直した π0.5 でも mechArm 270 には人の直しが要った（/record/retrained-pi05-still-needs-human-corrections）
- 450｜mechArm 270 の AI の直しが、ゲームパッドで1回13秒に（/record/gamepad-fixes-mecharm-270-ai-in-13-seconds）
- 460｜π0.5 の失敗の原因を探ると、浅いお手本だった（/record/pi05-failures-traced-to-shallow-grasp-demos）
- 461｜手応えを学習に足すため、mechArm 270 の電流を読んだ（/record/reading-mecharm-270-servo-current-for-learning）
- 463｜深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した（/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos）

**3. 50本で一から学び直しても、位置2で外れた**
偏りなく学ばせるため、お手本を5か所に10本ずつそろえ、π0.5を一から学習させた。しかし、50本で学んだπ0.5をアームで試しても、位置2では外れた。その理由は、カメラの傾きではなかった。
- 479｜偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に（/record/even-ten-demos-per-spot-mecharm-270-reteaching）
- 480｜浅いつかみの癖を残さず、π0.5 を50本で一から学習（/record/retrain-pi05-from-base-on-50-even-demos）
- 484｜50本で学んだ π0.5 をアームで試し、位置2 で外れた（/record/pi05-even-demos-on-arm-misses-position-2）
- 486｜π0.5 が位置2 を外した理由は、カメラの傾きではなかった（/record/pi05-position-2-miss-caused-by-camera-tilt）

**4. まさかの電源不足**
位置2の外れとは別に、mechArm 270 はつかんだブロックを落としていた。その理由は、まさかの電源不足だった。5Aのアダプターに替えると、ブロックを落とさなくなった。位置を外す問題と、落とす問題は分けて読む。
- 487｜mechArm 270 がブロックを落とす理由は、まさかの電源不足（/record/mecharm-270-drops-block-underpowered-adapter）
- 504｜mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった（/record/mecharm-270-5a-adapter-stops-dropping-block）

**5. アームで π0.5 を試す前に、この記録から言える5つの点検表**
AIがそのまま引けるように文字の表で置く。

| 問い | この記録で起きたこと |
|---|---|
| 1. 電源は足りているか | 足りないアダプターではブロックを落とした。5A に替えると落とさなくなった（487・504） |
| 2. お手本は深くつかんでいるか | π0.5 はお手本の待ち時間まで覚えた（358）。失敗をさかのぼると、浅くつかむお手本だった（460・463） |
| 3. お手本は置き場所ごとにそろっているか | 5か所に10本ずつそろえ、一から学習した（479・480）。それでも位置2では外れた（484・486） |
| 4. 1回ではなく、回数で測ったか | 回数で測ると、苦手な置き場所が見えた（401） |
| 5. 人が直す時間を測ったか | ゲームパッドで1回13秒になった（450）。測ったうえで、縮める先を決めた（492） |

※5A・お手本50本・修正13秒は、この実験の値です。手元のアームで同じ結果になることを示す値ではありません。
※各ログには、全文・コード・素材のファイルと「AIで読む」ボタンがあります。

### 束ねるログ
- /record/pi05-mecharm-demo-to-inference (337)
- /record/pi05-mecharm-lora-2000-steps (341)
- /record/pi05-mecharm-first-real-run (345)
- /record/pi05-mecharm-4000-steps (348)
- /record/pi05-learned-the-pauses (358)
- /record/pi05-all-three-positions (363)
- /record/pi05-weak-position-d (401)
- /record/retrained-pi05-still-needs-human-corrections (422)
- /record/gamepad-fixes-mecharm-270-ai-in-13-seconds (450)
- /record/pi05-failures-traced-to-shallow-grasp-demos (460)
- /record/reading-mecharm-270-servo-current-for-learning (461)
- /record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos (463)
- /record/even-ten-demos-per-spot-mecharm-270-reteaching (479)
- /record/retrain-pi05-from-base-on-50-even-demos (480)
- /record/pi05-even-demos-on-arm-misses-position-2 (484)
- /record/pi05-position-2-miss-caused-by-camera-tilt (486)
- /record/mecharm-270-drops-block-underpowered-adapter (487)
- /record/measure-mecharm-270-recovery-time-decide-what-to-cut (492)
- /record/mecharm-270-5a-adapter-stops-dropping-block (504)

### 今あるページとのつなぎ方
- **トップページ**：新しい見出しは作らず、今の「シリーズ」の欄の中に、このページの題名をそのまま1行で置く。
- **シリーズ**：フィジカルAI研究室のシリーズのページの資料の下に置く。リンク文は「予測は合うのに実機でつかめないときの検証記録」。
- **今ある LP**：`/gpu-buy-or-rent` 内に326・327（借りた GPU で動かし、要るメモリを測った記録）への言及があれば、その直後に置く。リンク文は「π0.5の予測は合った。それでも実機でつかめなかった記録」。設置位置は話題のつながりで選ぶ。表示21件の到達率から、位置の効果は判断しない。

### 公開後に見る数字
※人の表示が30件未満の間は効果を判断しない。30件に達した後も、少数のクリックで結論を出さない。
- このLPの表示数、25%・50%・75%への到達率（75%到達は最後まで読んだ証拠とはしない）。
- トップから AI がこの LP を取りに来た数（AI の利用者の依頼で読みに来た数のうち、この URL の分）。
- このLPから、個別のログへの遷移数と遷移率。遷移先を「電源」「お手本」「場所別の評価」「人の修正」に分け、どの点検項目から記録へ進んだかを見る。
- 既存の仕組みで取得できる場合は、コード・素材のファイルへの操作も別に記録する。いずれも再現完了とは数えない。同じ手順で同じ結果に届いたと確認できたものを、再現可能な環境の実績として別に扱う。
```


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

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


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

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


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

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

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


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


#### 再現の入口の依頼.md

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

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

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

## ゴール（公開から3か月。最初の判断は人の表示が30件たまった時点）
| 見るもの | 今の土台 | 3か月のゴール |
|---|---|---|
| このページの人の表示 | 今ある LP は3週間で21件（週7件ほど） | 3か月で150件（週12件ほど） |
| このページからログへ進んだ人 | ログからログへ進む人はほぼいない | 表示した人の3割 |
| AI の利用者の依頼で、このページを読みに来た数 | サイト全体で週50件前後 | このページだけで週3件以上（2か月目から） |
| AI のリンクから、このページに来た人 | サイト全体で週1件ほど | 月1件以上 |
| 問い合わせ・相談 | フォームからの連絡は、ある週で3件 | 再現を試した人、または試そうとした人から1〜2件（いちばん重い） |
3か月で表示が30件に届かず連絡も0件なら、このページに手間をかけるのをやめる（ページは資産として残す）。人の表示を増やすこと自体は目的にしない。

## 考えに入れること
- 人の多くは Google から個々のログに直接来て、1本読んで出ていく。トップを通る人は1割ほど。ログの形式は変えられないので、このページへは、AI の答え・検索・シリーズのページ・今ある LP（/gpu-buy-or-rent）・SNS からたどり着くことになる。どこから来るかを、企画書で具体に書くこと
- 問い合わせの窓口はメッセージフォーム（/message）だけ。トップや SNS に相談の窓口を出さない。ただしこのページから「再現を試した記録を送る」道をフォームへ置くのはよい
- ログに書いていない手順・バージョン・数字を作らない。足りない情報は「ログにない（未記載）」と書き、足りないこと自体をページに見せる

## 実際の数字（2026-10-26〜11-14・人の操作があった表示だけ）
- 人の表示は合計367件。週ごとに 164 → 136 → 68（11-09の週は6日分）と減っている
- **トップは40件で約1割。** 人の多くは Google（90件）や直接（153件）から、個々のログに直接来ている。LinkedIn 10件・Yahoo 10件・ChatGPT のリンク4件
- ログからほかのログ・シリーズへ移る動きはわずか（数件ずつ）。1本読んで出ていく
- 主なページの表示（25%/50%/75% まで読んだ割合）
  - / トップ：40件（70%/48%/28%）
  - /gpu-buy-or-rent（GPU は買うか借りるか・LP）：21件（52%/52%/10%）
  - /issues（課題地図）：21件（5%/0%/0%・中央値9秒）
  - /manga-archive：14件
  - /series8（サービスロボット導入シミュレーション）：12件
  - /serving-robot-one-less-staff（配膳ロボットの LP）：3件。ただし中の動画が57回再生され、67%が最後まで読んだ
  - /one-year（1年の記録の LP）：2件
  - よく読まれたログ：DAY18（11件・中央値53秒）、DAY17（7件）、DAY12（6件）、大きな店に配膳ロボット5台（7件）
- AI の利用者の依頼で読みに来た数：週に42〜61件。トップがいちばん多く、残りは個々のログに散る（ChatGPT-User が多く、Claude-User・Perplexity-User もある）
- サイト名で検索して来た人：まだ0
- **注意：** どのページも数が少ない。30件未満の数は「判断できない」として扱い、言い切らない

## 今のサイトの形
- トップ：見出し → 1年の記録 → 課題地図 → 導入前ガイド → 4コマ → いまの考え → シリーズ → 記録 → ロボットに関わる人へ → 事業所について
- シリーズのページ（/series1〜8）：上に資料、下にそのシリーズのログの一覧
- 今ある LP：/serving-robot-one-less-staff（配膳ロボットで人が1人減らせるか）、/gpu-buy-or-rent（GPU は買うか借りるか）、/one-year（1年の記録）
- 課題地図（/issues）：フィジカルAIの社会実装の前に解くべき課題・週1回更新
- ログは全部で約520本。各ログには全文・コード・素材のファイルが付き、「AIで読む」ボタンがある


## フィジカルAI研究室のログ一覧（題名と、各ログの要約。このページはここにある中身だけで作る）

- 225｜SO-101 失敗から学ぶアームを作る Log#1 | 精度を上げることと、失敗から学ぶことは違う｜/record/precision-is-not-learning-so101
  アームの動きを合わせる表（FKテーブル）を濃くしても、失敗から学ぶようにはならない。精度を上げることと失敗から学ぶことは別だと対話で行き着き、次は失敗から学ぶアームをSO-101で作ると決めた。
- 234｜SO-101 失敗から学ぶアームを作る Log#2 | 2TBの外付けSSDを、学習データの定位置にする｜/record/where-learning-data-lives
  模倣学習のデータは、Macではなく2TBの外付けSSDを定位置にして1か所に集めることにした。決める前に、Macの空き容量が約90GBから20GBまで減っていた原因を突き止めて片付けた。
- 277｜フィジカルAI研究室を作る Log#1 | 自宅にゼロから、誰でも再現できる形で｜/record/building-a-physical-ai-lab-at-home
  ロボットのAI（Physical AI）が学習できる環境を、個人の自宅にゼロから作り、誰でも同じ手順で作り直せる形で公開するシリーズを始めた。目的は、学習と推論を自分の手で回せる環境を残すこと。
- 326｜フィジカルAI研究室を作る Log#2 | Physical Intelligence の π0.5 を借りたGPUで動かした｜/record/openpi-remote-inference-first-run
  Physical Intelligenceのπ0.5はMacでは動かないが、RunpodでA40を借りれば動いた。Macから画像と指示文を送り、動きの数値を受け取るまで通した。推論は平均97ms、往復391ms、費用0.34ドル。
- 327｜フィジカルAI研究室を作る Log#3 | Physical Intelligence の π0.5 に要るGPUメモリを測った｜/record/pi05-libero-benchmark-first-run
  Physical Intelligenceのπ0.5は、Runpodで借りたA40の上で、シミュレータLIBEROのアームに「黒いボウルを拾って皿に置く」作業を20回すべて成功させた。使うGPUメモリの量も測った。
- 337｜フィジカルAI研究室を作る Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
  Physical Intelligenceのπ0.5をmechArm 270のお手本2本でA40で200ステップ追加学習すると、lossは0.1031から0.0162へ下がり、Macで予測を受け取れた。実機はまだ動かしていない。
- 337｜フィジカルAI研究室を作る Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
  Physical Intelligenceのπ0.5をmechArm 270のお手本2本でA40で200ステップ追加学習すると、lossは0.1031から0.0162へ下がり、Macで予測を受け取れた。実機はまだ動かしていない。
- 341｜フィジカルAI研究室を作る Log#5 | Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致｜/record/pi05-mecharm-lora-2000-steps
  Physical Intelligenceのπ0.5をmechArm 270のお手本19本で2,000ステップ学習すると、実機に送る前の予測はお手本の最初の1秒と数度以内で一致した。lossは0.1155から0.0054へ。
- 345｜フィジカルAI研究室を作る Log#6 | Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った｜/record/pi05-mecharm-first-real-run
  お手本19本で学習したPhysical Intelligenceのπ0.5でmechArm 270を初めて動かすと、ブロックの真上で手首が指令に届かず止まった。原因は爪がブロックに乗っていたことで、動画で分かった。
- 348｜フィジカルAI研究室を作る Log#7 | Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた｜/record/pi05-mecharm-4000-steps
  Physical Intelligenceのπ0.5の学習を4,000ステップに倍にしても、mechArm 270が手を伸ばす先は変わらず、爪は2回ともブロックの奥で空を閉じた。lossは0.0030まで下がっていた。
- 349｜フィジカルAI研究室を作る Log#8 | 手で教えた動きを再生し、4回続けて箱に入れた｜/record/drag-teach-waypoint-replay
  mechArm 270に姿勢を手で教えて再生させる方法で、ブロックを箱に入れる動きを4回続けて成功させた。床に当たって止まったが、高めに教え直し確認の幅を広げて直した。π0.5に渡すお手本を作るため。
- 352｜フィジカルAI研究室を作る Log#9 | 手で教えてお手本19本。肩88°を超えた姿勢は動かなかった｜/record/teach-replay-19-demos
  mechArm 270に手で教えた動きを再生しながら録り、Physical Intelligenceのπ0.5に渡すお手本を5か所19本集めた。肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられていた。
- 355｜フィジカルAI研究室を作る Log#10 | 位置を変えたお手本で、Physical Intelligence の π0.5 を学習し直した｜/record/pi05-retrain-five-positions
  置き場所を5か所に広げたお手本19本で、Physical Intelligenceのπ0.5をA40で4,000ステップ学習し直すと、lossは0.0858から0.0037へ。GPUの空き待ちで起動まで約4時間半かかった。
- 358｜フィジカルAI研究室を作る Log#11 | Physical Intelligence の π0.5 は「待ち時間」まで覚えた｜/record/pi05-learned-the-pauses
  Physical Intelligenceのπ0.5は、お手本の中の止まっている時間まで覚えていた。停止を詰めて学習し直すと、mechArm 270はブロックをつかんで箱まで運んだが、持ち上げずに箱の外で離した。
- 361｜フィジカルAI研究室を作る Log#12 | Physical Intelligence の π0.5 が初めてブロックを箱に入れた｜/record/pi05-first-block-in-box
  Physical Intelligenceのπ0.5で動かすmechArm 270が、初めてブロックを箱に入れた。学習し直さず、AIに渡す肩の角度を直前の目標に変えただけで、毎回約2°足りず箱に当てていた動きが直った。
- 363｜フィジカルAI研究室を作る Log#13 | Physical Intelligence の π0.5 がお手本の3か所すべてで箱に入れた｜/record/pi05-all-three-positions
  Physical Intelligenceのπ0.5で動かすmechArm 270が、試した3か所すべてでブロックを箱に入れた。Dは離す前に爪から落ち、Eは縁すれすれ。運ぶ間の肩はお手本より2.9〜4.0°低かった。
- 401｜フィジカルAI研究室を作る Log#14 | π0.5 を回数で測ったら、苦手な置き場所が見えた｜/record/pi05-weak-position-d
  Physical Intelligenceのπ0.5で動かすmechArm 270の実機は、3か所に5回ずつ置いたブロックを15回中9回箱に入れた。位置Cは5/5、Eは3/5、腕を伸ばしきるDは1/5だった。
- 403｜フィジカルAI研究室を作る Log#15 | mechArm 270 の失敗を巻き戻し、直して覚えさせる｜/record/rewind-and-correct-pi05
  Physical Intelligenceのπ0.5で動かすmechArm 270の実機推論に、失敗した区間を巻き戻すキーと関節を1°ずつ直すキーを足し、直した動きだけを学習データにする仕組みを作った。実機ではまだ動かしていない。
- 407｜フィジカルAI研究室を作る Log#16 | 直した mechArm 270 の動きを π0.5 に覚えさせる手前まで｜/record/rewind-correct-real-arm
  Physical Intelligenceのπ0.5で動かす実物のmechArm 270で、失敗しかけた動きをキーで巻き戻し根元の向きを直すと、AIは続けてブロックをつかめた。持ち上げる間に爪がゆるみ、直した回はまだ箱まで運べていない。
- 417｜フィジカルAI研究室を作る Log#17 | 人が直した mechArm 270 の5回で π0.5 を学び直す｜/record/retrain-pi05-with-human-corrections
  Physical Intelligenceのπ0.5で動かす実物のmechArm 270を8回動かし、成功した5回はすべて人が根元とひじを直していた。その5回を学習データに作り直し、前のモデルから続けて1,500ステップ学習した。
- 419｜フィジカルAI研究室を作る Log#19 | ゲームパッドで mechArm 270 を直す準備ができた｜/record/gamepad-ready-to-correct-mecharm-270
  3,198円の互換ゲームパッドをMacにつなぐと、ボタン16個と軸6本が読め、mechArm 270の関節を1押し0.5°ずつ動かして爪を開け閉めし、操作を全部記録するスクリプトができた。実機はまだで、アームなしで172回確かめた。
- 422｜フィジカルAI研究室を作る Log#18 | 学び直した π0.5 でも mechArm 270 には人の直しが要った｜/record/retrained-pi05-still-needs-human-corrections
  人が直した5回で学び直したPhysical Intelligenceのπ0.5で実物のmechArm 270を9回動かすと、成功6回はすべて補正つきで、補正なしの1回は根元が約2°足りず空振りした。終わりに手首のサーボが応えなくなった。
- 436｜フィジカルAI研究室を作る Log#20 | ゲームパッドで動いた mechArm 270、遅さは pymycobot の版｜/record/gamepad-moves-mecharm-270-pymycobot-version
  ゲームパッドで mechArm 270 を動かすと1回の指令に1.6秒かかった原因は、Pi の daemon が pymycobot 4.0.4 を読んでいたこと。2.9.6 に戻すと送信は約0.02秒、長押しで毎秒約8°動くようになった。
- 446｜フィジカルAI研究室を作る Log#21 | ゲームパッドで mechArm 270 を直す形が固まった｜/record/gamepad-correction-mecharm-270-settled
  小型アーム mechArm 270 をゲームパッドで手直しするには、長押しは15°先へ1回送り離したら stop、1回押しは動かす関節だけを送る形がよかった。受付なしは40回から0回になり、ほかの関節のずれも積み上がらなくなった。
- 450｜フィジカルAI研究室を作る Log#22 | mechArm 270 の AI の直しが、ゲームパッドで1回13秒に｜/record/gamepad-fixes-mecharm-270-ai-in-13-seconds
  mechArm 270 を動かす Physical Intelligence の π0.5 の失敗を人がゲームパッドで直すと1回は中央13秒で、キーで直した前の回の41〜51秒より短い。実機9回で19回直し、直す所は毎回同じ2か所だった。
- 460｜フィジカルAI研究室を作る Log#23 | π0.5 の失敗の原因を探ると、浅いお手本だった｜/record/pi05-failures-traced-to-shallow-grasp-demos
  mechArm 270 で Physical Intelligence の π0.5 が失敗した主な原因は、置き場所ではなく、ブロックが奥まで入る前に爪を閉じる浅いつかみ。学習データ30本中7本も同じ浅さだった。
- 461｜フィジカルAI研究室を作る Log#24 | 手応えを学習に足すため、mechArm 270 の電流を読んだ｜/record/reading-mecharm-270-servo-current-for-learning
  mechArm 270 のサーボの電流は、用意された関数では答えず、サーボの中の番地を直接読むと1秒に約10回取れた。爪の値は空で閉じると15前後、ブロックをつかむと870前後。力センサーなしで手応えを π0.5 のお手本に足す準備。
- 463｜フィジカルAI研究室を作る Log#25 | 深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した｜/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
  mechArm 270 のつかむ姿勢をゲームパッドで作り直すと、浅かった位置1のお手本が深くなり、2か所で使えるお手本を17本足せた。爪がブロックに乗った回は、下ろす時間（普段1.1秒→7.9〜9.1秒）で見分けられた。
- 479｜フィジカルAI研究室を作る Log#26 | 偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に｜/record/even-ten-demos-per-spot-mecharm-270-reteaching
  mechArm 270 の位置3・4は、教えたつかむ姿勢そのものが原因だった。ゲームパッドで教え直し肩だけで下ろす形にすると深くつかめ、Physical Intelligence の π0.5 のお手本が5か所10本ずつそろった。
- 480｜フィジカルAI研究室を作る Log#27 | 浅いつかみの癖を残さず、π0.5 を50本で一から学習｜/record/retrain-pi05-from-base-on-50-even-demos
  位置ごとに10本そろえた深いお手本50本で、Physical Intelligence の π0.5 を一から学習し直すと、Runpod の A40 で3,000ステップに6.2時間・約579円かかった。loss は 0.1015 から 0.0036 まで下がった。
- 484｜フィジカルAI研究室を作る Log#28 | 50本で学んだ π0.5 をアームで試し、位置2 で外れた｜/record/pi05-even-demos-on-arm-misses-position-2
  位置ごとに10本そろえたお手本50本で学習した Physical Intelligence の π0.5 をmechArm 270 で動かすと、位置1 は3回とも直しなしでつかめたが、位置2 は4回ともつかむ姿勢まで届かなかった。
- 486｜フィジカルAI研究室を作る Log#29 | π0.5 が位置2 を外した理由は、カメラの傾きではなかった｜/record/pi05-position-2-miss-caused-by-camera-tilt
  Physical Intelligence の π0.5 が mechArm 270 で位置2 まで下りなかった理由は、上カメラの傾きではなかった。録画の画像の傾きだけを変えて1,770回答えさせても、行き先は入れ替わらなかった。
- 487｜フィジカルAI研究室を作る Log#30 | mechArm 270 がブロックを落とす理由は、まさかの電源不足｜/record/mecharm-270-drops-block-underpowered-adapter
  実物の小型ロボットアーム mechArm 270 がつかんだブロックを落とすのは、電源アダプターの不足が原因とみられる。本体は40W を求めるのに、つないでいたのは12V・2A（24W）だった。
- 490｜フィジカルAI研究室を作る Log#31 | mechArm 270 の待ちを測り、Claude Fable 5.2 の使い所を決めた｜/record/measure-mecharm-270-waits-decide-claude-fable-5-2-role
  Anthropic の Claude Fable 5.2 は、実物のロボットアーム mechArm 270 の実験では、失敗の見立てのような人の判断の所に絞って使う。π0.5 の実機20本では、アームが動いていたのは全体の44%だった。
- 492｜フィジカルAI研究室を作る Log#32 | mechArm 270 を人が直す時間を測り、縮める先を決めた｜/record/measure-mecharm-270-recovery-time-decide-what-to-cut
  ロボットアーム mechArm 270 の実機で π0.5 の失敗を人がゲームパッドで直すのは1回中央14.5秒で、関節を動かすのは2.6秒だけ。キーボードの43.2秒から3分の1になり、残りは直しの出入りとつかみ直しにかかっていた。
- 497｜フィジカルAI研究室を作る Log#33 | アームの成否判定を Google の Gemini Decision 1 に任せられるか｜/record/gemini-decision-1-judge-mecharm-270-pick-and-place
  Google の判断専用モデル Gemini Decision 1 は、ロボットアーム mechArm 270 がブロックを箱に入れたかを56本すべて見分けたが、つかみの深さは見分けられなかった。1回約1秒・168回で約2円。
- 504｜フィジカルAI研究室を作る Log#34 | mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった｜/record/mecharm-270-5a-adapter-stops-dropping-block
  小型ロボットアーム mechArm 270 がブロックを落とす原因は電源の不足だった。12V・5A に替えると、π0.5 は位置5 で5回とも成功（12V・2A の日は3回中1回）。教えた動きの再生も7回すべて成功した。
```


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

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

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

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

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

mechArm 270を持ち、Macから借りたGPUを使ってπ0.5の追加学習を始めたい開発者。日本語でAIに「必要なものと手順を教えて」と尋ね、このページへ来る。

コードを追う力はあるが、散らばったログから「どのデータ・モデル・機器設定を組み合わせればよいか」を復元するところで止まっている。

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

自分の環境との差分、読むべき手順、追試できる結果、まだ埋まっていない情報を、着手前に一枚で確認できる。

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

**π0.5をmechArm 270で動かす。必要なものと、まだ足りない情報。**

Macから借りたA40へつなぎ、お手本の追加学習から実機まで進めた記録を、始める順にまとめました。  
深いつかみのお手本50本で学習し、その後、電源を12V・5Aに替えた実験では位置5で5回とも成功しています。  
ただし、全位置の成功や、この組み合わせ全体の第三者による再現を示すものではありません。未記載の情報もここに示します。

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

**「環境の照合表」と「結果の対応表」を隣に置く。**

照合表には機器・ソフトウェア・データ・学習条件・実機設定を並べ、各項目に出典ログを付ける。特に、Pi側で実際に読み込まれた`pymycobot`の版を独立した項目にする。4.0.4では指令に1.6秒、2.9.6へ戻すと送信約0.02秒だった事実は、導入済みの版と稼働中の版を照合する理由になる。

結果表では、50本学習後の位置1・位置2と、電源交換後の位置5を別の実験として掲載する。異なる実験の成功だけをつなぎ、一つの完成環境に見せない。

提供された要約で確認できない版・設定は「未記載（提示要約では確認できない）」とする。公開原稿ではログ本文・添付コードを照合し、確認できた項目だけ埋める。

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

**1．まず、自分の環境と照合する**  
Mac、RunpodのA40、mechArm 270、Pi側の依存関係、電源を表にする。  
`/record/openpi-remote-inference-first-run`：Macから画像と指示を送り、動きの数値を受信。  
`/record/gamepad-moves-mecharm-270-pymycobot-version`：Piのdaemonが読む版の違い。  
`/record/mecharm-270-5a-adapter-stops-dropping-block`：12V・5Aへの交換。機器の詳細型番や他の版は、記載を確認できなければ未記載にする。

**2．最初に、学習と予測の往復を通す**  
実機を動かす前の到達点を独立させ、ここから始めるリンクを置く。  
`/record/pi05-mecharm-demo-to-inference`：お手本2本、A40で200ステップ、Macで予測を受信。実機は未実施。この段階の通過と、作業の成功を分ける。

**3．実機用のお手本をそろえる**  
最新の50本に至る作り方と、採用したお手本の条件を示す。  
`/record/even-ten-demos-per-spot-mecharm-270-reteaching`：つかむ姿勢を教え直し、5か所10本ずつを収集。  
`/record/retrain-pi05-from-base-on-50-even-demos`：深いお手本50本で元のモデルから学習。データの入手先・形式・撮影配置は記載を照合し、不足を表示する。

**4．学習して、実機へ渡す**  
学習条件と、予測から実機制御へ進む際の変更を分けて示す。  
同じ50本の学習ログ：A40、3,000ステップ、6.2時間、約579円という当該実験の実測。  
`/record/pi05-first-block-in-box`：AIへ渡す肩の角度を直前の目標に変え、学習し直さず初めて箱へ投入。後続の実機コードにどう引き継がれたかは、確認できる範囲だけ記す。

**5．どこまで再現できたら、何が言えるか**  
`/record/pi05-even-demos-on-arm-misses-position-2`：位置1は3回とも補正なしで把持、位置2は4回とも姿勢に届かず。  
電源交換のログ：位置5で5回とも成功、教示再生は7回とも成功。試行条件と結果を対応させる。  
末尾に未記載一覧と「再現を試した記録を送る」→`/message`を置く。開始できなかった段階と不足情報も送れる案内にする。

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

上記の構成で使用する次の9本に絞る。

- `/record/openpi-remote-inference-first-run`
- `/record/gamepad-moves-mecharm-270-pymycobot-version`
- `/record/mecharm-270-5a-adapter-stops-dropping-block`
- `/record/pi05-mecharm-demo-to-inference`
- `/record/even-ten-demos-per-spot-mecharm-270-reteaching`
- `/record/retrain-pi05-from-base-on-50-even-demos`
- `/record/pi05-first-block-in-box`
- `/record/pi05-even-demos-on-arm-misses-position-2`
- `/record/building-a-physical-ai-lab-at-home`

最後のログは、この環境を公開する目的の出典として使う。

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

主入口は、検索とAIの回答。環境表・手順・結果・未記載事項を本文に書き、各事実から出典へ直接進めるようにする。

該当シリーズの上部資料に、このページへのリンクを置く。`/gpu-buy-or-rent`には「借りたA40でπ0.5の追加学習を始める」として接続する。トップは研究シリーズへの既存導線内に追加する。

SNSは環境照合表を紹介してページへ送る。トップ・SNSに相談窓口は設けない。個別ログの形式も変えない。

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

人の表示が30件たまるまで、閲覧率や回遊率から良否を決めない。数値は記録のみ行う。

人の表示、ログへ進んだ人の割合、入口別の流入、AI利用者の依頼による取得、AIリンクからの人の流入、再現に関する連絡を分けて数える。取得と人の訪問を合算しない。

3か月で人の表示30件未満・連絡0件なら、追加制作を止めてページを残す。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

- **人の表示150件**：検索・AI・GPUのLP・シリーズから、着手目的で入れる。対象が狭く、流入量は届かない可能性がある。
- **ログへ3割**：各工程の実行手順へ直接送る。照合表だけで判断を終える人もいる。
- **AIによる取得が週3件以上**：環境と出典を一枚に集め、質問への根拠にしやすくする。AI側の取得・引用は制御できない。
- **AIリンクから月1件以上**：始める順序まで示すことで訪問理由を作る。回答内で完結する可能性がある。
- **再現に関する連絡1〜2件**：未記載項目を明示し、試せなかった報告も送れる。必要機材や不足情報が着手を止める可能性がある。
- **主指標「再現可能な環境数」**：手順・依存関係の照合と第三者確認の足場を作る。公開だけでは加算せず、外部での再現記録、または必要情報に欠落がないという第三者確認が得られて初めて判定する。
```


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

```markdown
案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回目）

```markdown
# 案A（第1版）への評

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

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

**こう直す（文面）**
> **π0.5をmechArm 270で動かす。必要なものと、まだ足りない情報。**
> MacからRunpodのA40を借りて、π0.5の追加学習から実機までを通した記録を、始める順に並べ直しました。
> 電源を12V・2Aから12V・5Aに替えると、位置5は3回中1回の成功から5回とも成功に変わりました（Log#34）。
> 版・設定のうち、ログに書かれていないものは「未記載」として表に残しています。埋められる人からの連絡を待っています。

- 2行目は Log#34 の中の比べ（3回中1回 → 5回）だけで言い切ります。ほかの実験とつなげません。ログにある範囲では、これがいちばん強い言い方です。
- 3行目は、断り書きを「未記載を見せて、埋めてもらう」に変えます。主指標の③（再現に必要な情報が欠けていないことを第三者が確認できる）への入口になります。

## 2【高】照合表に「黙って失敗する所」が入っていない

**弱い所**
9本に絞ったため、追試する人が必ずつまずくのに画面にエラーが出ない事実が抜けています。ページの見出しは「まだ足りない情報」なのに、ログには書いてある落とし穴を載せていません。これでは、③の「欠けていないことを確認できる」に届きません。抜けているのは次のログです。
- Log#9（`/record/teach-replay-19-demos`）：肩を約88°より深く倒すと、命令がエラーなしに捨てられた
- Log#11（`/record/pi05-learned-the-pauses`）：π0.5は、お手本の中の止まっている時間まで覚えた。停止を詰めて学習し直した
- Log#23（`/record/pi05-failures-traced-to-shallow-grasp-demos`）：失敗の主な原因は浅いつかみ。学習データ30本中7本も同じ浅さだった
- Log#30（`/record/mecharm-270-drops-block-underpowered-adapter`）：本体は40Wを求めるのに、12V・2A（24W）をつないでいた

**こう直す**
照合表に「**動かない時に先に見る所**」の列を足します。失敗の話としてではなく、照合する項目として書きます。

| 項目 | 確かめること | 合わないと起きること | 出典 |
|---|---|---|---|
| 電源 | 12V・5Aか（本体は40Wを求める） | つかんだブロックを落とす | Log#30・#34 |
| Pi側で読み込まれている pymycobot の版 | 2.9.6か | 1回の指令に1.6秒かかる（4.0.4の場合） | Log#20 |
| 肩の角度 | 約88°より深く倒す姿勢を教えていないか | 命令がエラーなしに捨てられる | Log#9 |
| お手本の止まっている時間 | 停止を詰めたか | 待ち時間まで覚える | Log#11 |
| つかみの深さ | 奥まで入れてから閉じているか | 浅いつかみを覚える（30本中7本が浅かった） | Log#23・#26 |
| AIに渡す肩の角度 | 直前の目標を渡しているか | 毎回約2°足りず箱に当たる | Log#12 |

束ねるログは15本前後に増えます。それでも「30本以上に散らばったログを1枚に」という依頼の目的には、こちらのほうが近づきます。

## 3【高】どこから来るかが具体でなく、ゴールの数字に結びつかない

**弱い所**
「主入口は検索とAIの回答」「シリーズ上部」「トップは既存導線内」とあります。依頼が求める「どこから来るかを具体に」に答えていません。今の数字では、人の多くは個々のログに直接来て、1本読んで出ていきます。ログの形式は変えられないので、ログの外の置き場をどう使うかが勝負です。

**こう直す（入口ごとに書く）**
- **/gpu-buy-or-rent（3週間で21件）**：50%まで読む人は52%いますが、75%では10%に落ちます。リンクは**本文の前半（50%の位置より前）**に置き、文面は「借りたA40でπ0.5を追加学習するときの費用と時間の実測は、こちら」とします。ページの終わりに置くと、ほとんど読まれません。
- **トップ（AIの依頼でいちばん読まれる所）**：ChatGPT-User などは、トップをいちばん多く読みに来ています。トップの「シリーズ」の節の、フィジカルAI研究室の行に、このページへの1行リンクを置きます（相談の窓口ではないので、守ることに反しません）。
- **フィジカルAI研究室のシリーズページ**：上の資料の1番目に置きます。
- **AIの答え・検索**：title と最初の段落に、聞かれる言葉をそのまま入れます（例：「π0.5 追加学習 手順」「小型アーム」「必要なGPU」「費用」「依存関係」）。
- **SNS（LinkedIn 10件）**：照合表の「動かない時に先に見る所」を画像1枚にして送ります。

あわせて「ログへ3割」のために、照合表の各行に「このログで確かめる→」を置きます。最初の段階には「最初に読む1本：Log#4」と、1本だけを名指しします。

## 4【高】フォームへの案内が、主指標の判定に使える形になっていない

**弱い所**
「再現を試した記録を送る」と書くだけでは、何を書けばよいか分かりません。送られてきても、③（自分以外の環境で再現された記録）として数えられるかが判断できません。いちばん重いゴールの行なので、ここは文面まで決めておくべきです。

**こう直す（/message へ送る前の案内文）**
> **再現を試した記録、または「ここが足りない」を送る**
> 途中で止まった記録も歓迎します。次のうち分かるものだけ書いてください。
> ①アームの機種と電源（例：12V・5A） ②Pi側で読み込まれている pymycobot の版 ③学習に使ったGPU ④どの段階まで進んだか（予測を受け取れた／実機が動いた／箱に入れた） ⑤上の表で「未記載」だった所と、あなたの環境の値
> 送られた内容は、了承を得てからこのページの表に反映します。

⑤があれば、成功していなくても「必要な情報が欠けていないかを第三者が確かめた記録」として扱えます。「試そうとした人」からの連絡1〜2件を取りに行く形です。

## 5【中】GPU・費用・時間の表がなく、Log#3 を落としている

**弱い所**
始める前の人が最初に決めるのは「どのGPUを、いくらで、何時間借りるか」です。ところが、要るGPUメモリを測った Log#3（`/record/pi05-libero-benchmark-first-run`）が束ねるログから外れています。/gpu-buy-or-rent とつなぐ理由も、ここがいちばん強くなります。

**こう直す（「用意する」の節に表を置く）**

| 段階 | GPU | かかった時間・費用 | 出典 |
|---|---|---|---|
| 推論を初めて通す | A40 | 推論は平均97ms、往復391ms、費用0.34ドル | Log#2 |
| 要るGPUメモリ | A40 | 測定値はログ本文で確かめる（要約では未記載） | Log#3 |
| 50本・3,000ステップの学習 | A40 | 6.2時間・約579円 | Log#27 |
| 起動までの待ち | A40 | GPUの空き待ちで約4時間半 | Log#10 |

最後の行は、次のように書きます。「借りるGPUは、空き待ちで起動まで約4時間半かかった日がある（Log#10）」。始める人の予定に効く事実です。

## 6【中】結果表の「成功」の意味が、行ごとにそろっていない

**弱い所**
位置1の「つかめた」（Log#28）、位置5の「成功」（Log#34）、教えた動きの再生の「7回成功」は、成否の基準が違います。並べると、同じ成功に見えてしまいます。人の直しがあったかどうかの列もありません。人の直しは、Log#18「成功6回はすべて補正つき」が示すように、再現性の判断の中心です。
また、位置の名前はログによって違います（Log#14はC・D・E、のちのログは1〜5）。同じ場所かどうかは、要約からは分かりません。

**こう直す（結果表の列）**
モデル（お手本の本数・ステップ数）／電源／位置（ログでの呼び名のまま）／回数／何をもって成功としたか（つかむ・箱に入れる）／人の直し／出典

足す行は次の2つです。
- Log#14：3か所に5回ずつで15回中9回（Cは5/5、Eは3/5、腕を伸ばしきるDは1/5）
- Log#18：9回中6回成功。成功はすべて人の補正つき

注記には「位置の名前はログによって違い、同じ場所かどうかはログ本文で確かめる」と書きます。回数がいちばん多い Log#14 を入れると、表の信頼が上がります。

## 7【低】ページの名前に、聞かれる言葉が足りない

**弱い所**
「同じ環境から始めるための手順・依存関係・実機結果」は、作り手の言葉です。AIや検索で尋ねる人の言葉とは違います。

**こう直す**
> **π0.5をmechArm 270で追加学習して動かす：必要なGPU・依存関係の版・手順と実機の結果**

URL は `/pi05-mecharm-start` のままでかまいません。

## 守るべき尖り

**「異なる実験の成功をつなげて、一つの完成した環境に見せない」と決めたことと、Pi側で実際に読み込まれた pymycobot の版を独立した項目にしたこと。**
「入れた版」と「動いている版」の食い違いで1回の指令に1.6秒かかった事実は、ほかでは読めない、追試する人がいちばん助かる情報です。結果を盛らずに未記載を見せる姿勢は、主指標の③にそのまま効きます。書き直しでは、この2つを削らないでください。
```


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

```markdown
【採否】

- B・1：一部採る。ゲームパッドによる教え直しを補う。ただし「補正に中央13秒」と「深いお手本の作成」は別の実験であり、補正の仕組み全体を再現の必須条件とは断定しない。
- B・2：一部採る。各工程から実行に使うログへ送る。クリックのために必要情報を省かず、「AIで読む」への直接リンクも存在を前提にしない。
- B・3：採る。環境表の直後にも、不足情報で止まった人が記録を送れる導線を置く。
- B・4：一部採る。冒頭は確認できることと不足情報を示す。ただし、読者への報告依頼をページの主目的にはしない。
- B・5：採らない。外付けSSDのログはSO-101の研究であり、この研究の保存先や必須容量とは確認できない。保存先・必要容量は未記載として扱う。
- B・6：一部採る。工程ごとに出典リンクを付ける。ただし、定型文でAIに引用を「確実に」させられるとは言わない。
- C・1：採る。50本学習と電源交換後のモデルのつながりは未確認。冒頭では別々の事実として扱う。
- C・2：一部採る。既知の注意点を照合項目に加える。ただし「追試する人が必ずつまずく」と一般化しない。
- C・3：一部採る。リンクの置き場と文面を具体化する。LPの21件から離脱傾向は判断せず、前半への設置は仮説とする。
- C・4：一部採る。送る内容を具体化する。ただし、不足項目の報告だけでは「再現に必要な情報に欠落がない」という第三者確認には数えない。
- C・5：採る。GPU・費用・時間を段階別に示す。メモリの数値は未記載、空き待ちは当該日の記録として扱う。
- C・6：一部採る。結果の到達点・補正・条件を分ける。過去の結果を増やすより、開始に使う実験の対応を優先する。
- C・7：採る。「追加学習」「必要なGPU」「依存関係の版」を名前に入れ、着手目的を明確にする。

【企画書】

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

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

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

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

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

自分の環境との差分と、最初に実行する手順、結果の確かめ方、着手を妨げる不足情報を一枚で確認できる。

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

**π0.5をmechArm 270で動かす。必要なものと、まだ足りない情報。**

Mac・RunpodのA40・mechArm 270で、追加学習から実機まで進めた記録を、始める順にまとめました。  
電源交換の実験では、12V・5Aで位置5が5回とも成功しました。12V・2Aの日は3回中1回でした（研究ログ第34回）。  
依存関係の版・設定・データの所在を照合し、確認できない項目は「未記載」として残しています。

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

**「自分の環境との照合表」と「実験条件ごとの結果表」。**

照合表は「項目／記録された値／動かない時に見る所／出典」。Piで実際に読み込まれたpymycobotの版を独立させる。4.0.4で指令に1.6秒、2.9.6で送信約0.02秒という、動作中の版を確かめる理由を示す。

結果表は「モデル・学習条件／電源／位置の原表記／試行数／到達点／人の補正／出典」。不明な欄を埋めず、異なる実験の成功を一つの完成環境に見せない。位置1の把持と位置5の成功、教示再生も分ける。

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

以下の回番号は「束ねるログ」のURLに対応する。

**1．用意するものを照合する**  
第2・3・10・20・34回。Mac、A40、アーム、電源、稼働中の版を表にする。GPU欄は推論費用0.34ドル、学習費用・時間は第27回と分ける。メモリ測定値は提示要約では未記載。起動まで約4時間半待った日もある。保存先・容量、各ソフトの版、接続・撮影設定も確認欄にする。

**2．まず、予測を受け取るところまで通す**  
最初に読む一本は第4回。お手本2本、A40で200ステップ学習し、Macで予測を受信した手順へ送る。「予測受信」を最初の到達点とし、実機動作とは分ける。

**3．深くつかむお手本をそろえる**  
第9・11・21・23・25・26回。肩約88°より深い姿勢で命令が捨てられた事例、停止時間の学習、30本中7本の浅いつかみを確認事項にする。ゲームパッドの操作方式と教え直しをたどり、5か所10本ずつに至る。各段階のコード・データ形式・入手先への出典を付ける。

**4．学習し、実機へ渡す**  
第27・12回。深いお手本50本を元のモデルから3,000ステップ学習。A40で6.2時間・約579円は当該実験の実測として示す。肩の入力を直前の目標へ変えて初めて箱へ入れた変更は別項目にし、後続コードへの継承は未確認なら明記する。

**5．自分の結果と照らし合わせる**  
第28・34回。位置1は3回とも補正なしで把持、位置2は4回とも姿勢に届かず。電源交換後は位置5で5回成功、教示再生は7回成功。モデルの対応や補正の有無など、要約で確認できない条件は未記載にする。

環境表直後と末尾に「再現を試した記録・足りなかった情報を送る」→`/message`。機種・電源・稼働中の版・GPU・参照ログ・到達段階・補正・不足項目を、分かる範囲で書く案内を置く。公開反映は本人の了承後とする。

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

- 第2回：/record/openpi-remote-inference-first-run
- 第3回：/record/pi05-libero-benchmark-first-run
- 第4回：/record/pi05-mecharm-demo-to-inference
- 第9回：/record/teach-replay-19-demos
- 第10回：/record/pi05-retrain-five-positions
- 第11回：/record/pi05-learned-the-pauses
- 第12回：/record/pi05-first-block-in-box
- 第20回：/record/gamepad-moves-mecharm-270-pymycobot-version
- 第21回：/record/gamepad-correction-mecharm-270-settled
- 第23回：/record/pi05-failures-traced-to-shallow-grasp-demos
- 第25回：/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- 第26回：/record/even-ten-demos-per-spot-mecharm-270-reteaching
- 第27回：/record/retrain-pi05-from-base-on-50-even-demos
- 第28回：/record/pi05-even-demos-on-arm-misses-position-2
- 第34回：/record/mecharm-270-5a-adapter-stops-dropping-block

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

検索・AI向けに、題名と冒頭で対象、GPU、追加学習、版、手順を明記する。各工程から「この手順・コードを読む」で該当ログへ送る。

研究シリーズは上部資料の先頭、トップは既存のシリーズ欄に置く。`/gpu-buy-or-rent`前半に「A40でπ0.5を追加学習した費用・時間と開始手順」を置く。前半配置は検証する仮説。ほかのLPへの追加は見送る。SNSでは照合表の一部を紹介して送客する。個別ログは変更せず、トップ・SNSに相談窓口は出さない。

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

人の表示30件までは記録のみ。人の表示、ログへ進んだ人数・割合、入口別流入、AI依頼による取得、AIリンクからの人の訪問、再現関連の連絡を分ける。取得と訪問は合算しない。3か月で表示30件未満かつ連絡0件なら追加制作を止め、ページは残す。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

以下は依頼の目標値であり、予測ではない。

- **表示150件**：検索・AI・シリーズ・GPUのLPから着手目的で入れる。対象の狭さで届かない可能性。
- **ログへ3割**：工程ごとに実行する一本を示す。照合だけで用が済む可能性。
- **AI取得、2か月目から週3件以上**：条件と出典がまとまる。取得は制御できない。
- **AIリンクから月1件以上**：環境照合に訪問理由がある。回答内で完結する可能性。
- **再現関連の連絡1〜2件**：途中停止も具体的に送れる。機材や不足情報で着手されない可能性。
- **再現可能な環境数**：手順・版・不足の照合を第三者に開く。公開や連絡だけでは加算せず、外部再現の記録、または必要情報に欠落がないという第三者確認を得て判定する。
```


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

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

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

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

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

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

自分の環境との差分と、最初に実行する手順、結果の確かめ方、着手を妨げる不足情報を一枚で確認できる。

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

**π0.5をmechArm 270で動かす。必要なものと、まだ足りない情報。**

Mac・RunpodのA40・mechArm 270で、追加学習から実機まで進めた記録を、始める順にまとめました。  
電源交換の実験では、12V・5Aで位置5が5回とも成功しました。12V・2Aの日は3回中1回でした（研究ログ第34回）。  
依存関係の版・設定・データの所在を照合し、確認できない項目は「未記載」として残しています。

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

**「自分の環境との照合表」と「実験条件ごとの結果表」。**

照合表は「項目／記録された値／動かない時に見る所／出典」。Piで実際に読み込まれたpymycobotの版を独立させる。4.0.4で指令に1.6秒、2.9.6で送信約0.02秒という、動作中の版を確かめる理由を示す。

結果表は「モデル・学習条件／電源／位置の原表記／試行数／到達点／人の補正／出典」。不明な欄を埋めず、異なる実験の成功を一つの完成環境に見せない。位置1の把持と位置5の成功、教示再生も分ける。

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

以下の回番号は「束ねるログ」のURLに対応する。

**1．用意するものを照合する**  
第2・3・10・20・34回。Mac、A40、アーム、電源、稼働中の版を表にする。GPU欄は推論費用0.34ドル、学習費用・時間は第27回と分ける。メモリ測定値は提示要約では未記載。起動まで約4時間半待った日もある。保存先・容量、各ソフトの版、接続・撮影設定も確認欄にする。

**2．まず、予測を受け取るところまで通す**  
最初に読む一本は第4回。お手本2本、A40で200ステップ学習し、Macで予測を受信した手順へ送る。「予測受信」を最初の到達点とし、実機動作とは分ける。

**3．深くつかむお手本をそろえる**  
第9・11・21・23・25・26回。肩約88°より深い姿勢で命令が捨てられた事例、停止時間の学習、30本中7本の浅いつかみを確認事項にする。ゲームパッドの操作方式と教え直しをたどり、5か所10本ずつに至る。各段階のコード・データ形式・入手先への出典を付ける。

**4．学習し、実機へ渡す**  
第27・12回。深いお手本50本を元のモデルから3,000ステップ学習。A40で6.2時間・約579円は当該実験の実測として示す。肩の入力を直前の目標へ変えて初めて箱へ入れた変更は別項目にし、後続コードへの継承は未確認なら明記する。

**5．自分の結果と照らし合わせる**  
第28・34回。位置1は3回とも補正なしで把持、位置2は4回とも姿勢に届かず。電源交換後は位置5で5回成功、教示再生は7回成功。モデルの対応や補正の有無など、要約で確認できない条件は未記載にする。

環境表直後と末尾に「再現を試した記録・足りなかった情報を送る」→`/message`。機種・電源・稼働中の版・GPU・参照ログ・到達段階・補正・不足項目を、分かる範囲で書く案内を置く。公開反映は本人の了承後とする。

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

- 第2回：/record/openpi-remote-inference-first-run
- 第3回：/record/pi05-libero-benchmark-first-run
- 第4回：/record/pi05-mecharm-demo-to-inference
- 第9回：/record/teach-replay-19-demos
- 第10回：/record/pi05-retrain-five-positions
- 第11回：/record/pi05-learned-the-pauses
- 第12回：/record/pi05-first-block-in-box
- 第20回：/record/gamepad-moves-mecharm-270-pymycobot-version
- 第21回：/record/gamepad-correction-mecharm-270-settled
- 第23回：/record/pi05-failures-traced-to-shallow-grasp-demos
- 第25回：/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- 第26回：/record/even-ten-demos-per-spot-mecharm-270-reteaching
- 第27回：/record/retrain-pi05-from-base-on-50-even-demos
- 第28回：/record/pi05-even-demos-on-arm-misses-position-2
- 第34回：/record/mecharm-270-5a-adapter-stops-dropping-block

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

検索・AI向けに、題名と冒頭で対象、GPU、追加学習、版、手順を明記する。各工程から「この手順・コードを読む」で該当ログへ送る。

研究シリーズは上部資料の先頭、トップは既存のシリーズ欄に置く。`/gpu-buy-or-rent`前半に「A40でπ0.5を追加学習した費用・時間と開始手順」を置く。前半配置は検証する仮説。ほかのLPへの追加は見送る。SNSでは照合表の一部を紹介して送客する。個別ログは変更せず、トップ・SNSに相談窓口は出さない。

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

人の表示30件までは記録のみ。人の表示、ログへ進んだ人数・割合、入口別流入、AI依頼による取得、AIリンクからの人の訪問、再現関連の連絡を分ける。取得と訪問は合算しない。3か月で表示30件未満かつ連絡0件なら追加制作を止め、ページは残す。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

以下は依頼の目標値であり、予測ではない。

- **表示150件**：検索・AI・シリーズ・GPUのLPから着手目的で入れる。対象の狭さで届かない可能性。
- **ログへ3割**：工程ごとに実行する一本を示す。照合だけで用が済む可能性。
- **AI取得、2か月目から週3件以上**：条件と出典がまとまる。取得は制御できない。
- **AIリンクから月1件以上**：環境照合に訪問理由がある。回答内で完結する可能性。
- **再現関連の連絡1〜2件**：途中停止も具体的に送れる。機材や不足情報で着手されない可能性。
- **再現可能な環境数**：手順・版・不足の照合を第三者に開く。公開や連絡だけでは加算せず、外部再現の記録、または必要情報に欠落がないという第三者確認を得て判定する。
```


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

```markdown
案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回目）

```markdown
# 案A（第2版）への評

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

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

**こう直す（文面）**
> **π0.5をmechArm 270で動かす。必要なものと、まだ足りない情報。**
> π0.5はMacでは動かないので、RunpodのA40を借りて追加学習し、mechArm 270の実機まで進めました（第2回・第27回）。
> お手本50本・3,000ステップの学習は、A40で6.2時間・約579円でした。電源は12V・2A（24W）では足りず（本体は40Wを求める）、12V・5Aに替えると位置5で5回とも成功しました（第27回・第30回・第34回）。
> 最初の1本は第4回（お手本2本・200ステップでMacに予測が届くまで）。使った版と設定はログから拾い、ログにないものは「未記載」と書いています。

使える数字は「Macでは動かない・費用・電源の落とし穴」です。どれも、この人が保存したくなる理由になります。これを1画面に寄せてください。

## 2【高】「未記載」の使い方を誤っている。ログに記録があるものまで欠けて見せてしまう

**弱い所**
節1に「メモリ測定値は提示要約では未記載」とあります。しかし第3回は「使うGPUメモリの量も測った」とはっきり書いています。これをページで「未記載」と出すと、第三者は「測っていない」と受け取ります。主指標の判定条件③「再現に必要な情報が欠けていないことを第三者が確認できる」に、自分で傷をつけることになります。

**こう直す**
照合表の「記録された値」の欄を、3つに分けて書きます。
- **値あり**：ページに数字を載せる（例：推論 平均97ms・往復391ms・0.34ドル〈第2回〉）
- **測定あり・値はログで確認**：「GPUメモリは第3回で測定。値は第3回を読む」
- **未記載**：ログに記録がないもの

「測ったが、このページには載せていない」と「ログにない」を同じ扱いにしないでください。

## 3【高】照合表から、ログにある「詰まる所」が抜けている

**弱い所**
照合表の項目が「Mac・A40・アーム・電源・稼働中の版」にとどまっています。再現する人が実際につまずく機材の条件のうち、ログ一覧にあるのに入っていないものがあります。

**こう直す（照合表に足す行）**

| 項目 | 記録された値 | 動かない時に見る所 | 出典 |
|---|---|---|---|
| アームの電源 | 本体は40Wを求める。12V・2A（24W）ではブロックを落とした。12V・5Aで直った | つかんだ物を落とす時は、まず電源のアンペアを見る | 第30・34回 |
| 肩の角度の限界 | 約88°より深く倒すと、命令がエラーなしに捨てられた | 教えた姿勢が再生されない時 | 第9回 |
| Raspberry Pi の daemon | pymycobot 4.0.4 では指令1回に1.6秒。2.9.6 で送信約0.02秒 | 手元の版ではなく、Pi で読み込まれている版を見る | 第20回 |
| 手直しの道具 | 3,198円の互換ゲームパッド。ボタン16個・軸6本を読めた | 長押しは15°先へ1回送り、離したら stop（受付なしが40回→0回） | 第19・21回 |
| サーボの電流 | 用意された関数では答えず、番地を直接読んで約10回/秒。爪は空で閉じると15前後、ブロックをつかむと870前後 | 手応えを取りたい時 | 第24回 |
| 上カメラ | 使用（設定値はログ一覧に未記載） | 傾きは位置2で外れた原因ではなかった | 第29回 |

電源と88°の2行は、知らないと数時間を失う所です。この人にとって、このページを保存する理由そのものになります。

## 4【高】「到達段階」を決めていないので、送られてくる記録を比べられない

**弱い所**
連絡の案内に「到達段階」を書く欄があります。しかし、何段階あるのかをページで決めていません。これでは「途中まで動いた」という連絡しか来ません。いちばん重いゴールである「再現を試した人からの連絡」と、判定条件③の材料になりません。

**こう直す**
節2〜5の頭に段階番号を付け、連絡の案内でも同じ番号を使います。
- **段階0**：A40でπ0.5の推論が返る（第2回：平均97ms・往復391ms）
- **段階1**：追加学習してMacで予測を受け取る（第4回：loss 0.1031→0.0162）
- **段階2**：実機でブロックをつかむ（第28回：位置1は3回とも直しなし）
- **段階3**：箱に入れる（第12回・第34回）

/message の前に、写して使える文面を置きます。
> 機種／電源（V・A）／Pi の pymycobot の版／GPU／参考にしたログ（第○回）／届いた段階（0〜3）／人の直し（あり・なし）／足りなかった情報

「段階1で止まった」という連絡でも、欠けている情報の確認（判定条件③）に使えます。そのことも案内に一言書いてください。

## 5【中】結果表に「人の直し」と「まだ解けていないこと」の出典がない。連絡が来るきっかけを捨てている

**弱い所**
結果表に「人の補正」の欄はあります。しかし、補正の実態を示す第14・18回が束ねるログに入っていません。位置2の原因が今もわからないこと（第29回）も入っていません。これだと、追加学習すれば単独で動くように読めてしまいます。さらに、再現する人が「自分の所ではどうか」と書きたくなる問いがページから消えます。

**こう直す**
結果表に、学習条件の違う行として次を足します。
- 第14回：お手本19本のモデルで15回中9回。位置Cは5/5、Eは3/5、腕を伸ばしきるDは1/5
- 第18回：学び直したモデルで成功した6回は、すべて人の補正つき。補正なしの1回は、根元が約2°足りず空振り

あわせて、末尾に短い節「まだ解けていないこと」を置きます。
> お手本50本のモデルは、位置2で4回とも、つかむ姿勢まで下りませんでした（第28回）。上カメラの傾きだけを変えて1,770回答えさせても、行き先は入れ替わりませんでした（第29回）。原因はまだわかっていません。同じ外れ方をした人、しなかった人の記録を送ってください → /message

ログにある事実の範囲で言える、いちばん強い呼びかけです。

## 6【中】題名が中身より多くを約束していて、AIに聞かれる問いの形にもなっていない

**弱い所**
題名の「依存関係の版」について、ログ一覧で版が書かれているのは pymycobot だけです。読みに来た人は、版の一覧表を期待して落胆します。「必要なGPU」も、ログにあるのは「使ったGPU（A40）」と「測ったメモリ」です。

節の見出しが作業名（「用意するものを照合する」など）なので、AIの利用者の依頼で読まれた時に、答えの1文を抜き出しにくくなります。

**こう直す**
- 題名：**π0.5をmechArm 270で追加学習して動かす：使った機材・版・手順・費用と、ログにない情報**
- 節の見出しを問いにして、すぐ下に1文の答えと出典を置きます。
  - 「π0.5はMacで動くか」→「動かない。RunpodのA40を借りて動かした（第2回）」
  - 「追加学習の費用と時間は」→「お手本50本・3,000ステップで6.2時間・約579円（第27回）」
  - 「mechArm 270の電源は何Aか」→「12V・2Aでは足りず、12V・5Aで落とさなくなった（第30・34回）」
  - 「pymycobotはどの版か」→「Pi で 2.9.6。4.0.4 では1回1.6秒かかった（第20回）」

表は画像にせず、文字で置いてください。AIが取りに来た時に読めるようにするためです。

## 7【中】入口のリンクの場所と文面が具体でない

**弱い所**
「研究シリーズ」がどのシリーズのページか書かれていません。トップの「シリーズ欄」は10ある欄の7番目にあり、トップは50%まで読む人が48%、75%では28%です。どの入口も、リンクの文面が決まっていません。

**こう直す**
- **シリーズ**：「フィジカルAI研究室を作る」のシリーズのページで、上の資料の先頭に置きます。文面は「ここから始める：π0.5をmechArm 270で動かすのに使ったもの・手順・結果」。
- **トップ**：シリーズ欄の中で、このシリーズの項目に同じ文面を添えます。AIの利用者の依頼でいちばん読まれているのはトップです。トップからこのページへ文字のリンクがあることが、AIのたどる道になります。新しいキャッチコピーにはしません。
- **/gpu-buy-or-rent**：前半に「A40でπ0.5を追加学習した実例：3,000ステップ・6.2時間・約579円（第27回）→ 始める手順」を置きます。
- **SNS（LinkedIn は10件）**：電源の1行（「40Wを求めるのに24Wの電源をつないでいた」）を照合表の画像と一緒に出し、このページへ送ります。相談の窓口は出しません。

---

## 守るべき尖り

**見出しで「まだ足りない情報」と言い切り、空いている欄を埋めず、条件の違う成功を一つの完成した環境に見せない方針。**

これがあるから、第三者が「欠けている所」を自分で確かめられます（判定条件③）。再現を試す人も、どこで止まったかを送りやすくなります。書き直しで結果をきれいに見せたくなっても、未記載の欄と、条件ごとに分けた結果表は消さないでください。
```


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

```markdown
【採否】

- B1・冒頭：一部採る。学習時間・費用と最初の一本を前へ出す。「誰でも始められる」とは保証せず、費用は当該学習だけの実測とする。
- B2・ログへのリンク：採る。数字の強さより、リンク先で実行・確認できることを文面にする。
- B3・連絡の動機：一部採る。動いた記録も止まった記録も募るが、連絡をそのまま第三者確認として追記しない。
- B4・未記載の強調：一部採る。着手への影響を示す。「求む」の演出より、何が確認できないかを明確にする。
- B5・既存LPのリンク：一部採る。実測の数字を添えるが、数字入りなら検索・AIに選ばれるとは断定しない。
- C1・冒頭と開始地点：一部採る。第4回へのリンクを冒頭に置く。電源の詳細は照合表へ移し、表示21件のLPから配置の良否は判断しない。
- C2・記録状態の区別：採る。メモリは「測定あり・値は提供要約にない」と直す。要約だけでログ本文の欠落を断定しない。
- C3・照合表の追加：一部採る。電源・肩・稼働中の版・操作方式を採る。電流計測などを始めるための必須条件には広げない。
- C4・到達段階：採る。同じ段階番号で結果と連絡を整理する。ただし途中停止の報告だけで主指標の条件③を満たすとは扱わない。
- C5・補正と未解決事項：一部採る。第18・29回を加える。第14回のモデルを「お手本19本」とする対応は提供要約では確認できないため採らない。
- C6・題名と問い：一部採る。「必要なGPU」を「使った機材」に直し、問いと短い答えを置く。全体の順序は始める工程を守る。
- C7・入口の具体化：採る。シリーズ名とリンク文面を決める。シリーズのURLは提示されていないので作らない。

【企画書】

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

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

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

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

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

自分の環境との差分、最初に実行する一本、到達点と、着手前に確認すべき不足情報が分かる。

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

**π0.5をmechArm 270で動かす。使ったものと、まだ確認できないこと。**

MacからRunpodのA40を使い、追加学習と実機動作まで進めた記録です。  
お手本50本・3,000ステップの学習は6.2時間・約579円でした。この学習実験の実測で、開始に必要な総費用ではありません（第27回）。  
最初は「お手本2本・200ステップで学習し、Macで予測を受け取る手順」へ（第4回）。実機を動かす前に、下の環境表を照合してください。

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

**コードだけではそろわない実機の条件を、出典付きの文字の表で照合する。**

「項目／記録された条件／確認する場面／出典」を並べる。主役は、Piが読み込むpymycobotの版と電源。肩の姿勢、操作方式も載せる。

記録状態は「値あり」「測定・使用の記録あり、値は提供要約にない」「提供要約では記載を確認できない」を分ける。本文確認前に「ログにない」と断定しない。本文にもなければ「ログにない（未記載）」とし、何の実行・照合を妨げるかを書く。

結果表は「学習条件／電源／位置の原表記／試行数／到達段階／人の補正／出典」。条件不明は明示し、異なる成功を一つの完成環境にまとめない。

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

回番号とURLは次項で対応させる。

**1．Macと手元の機材で始められるか**  
第2・3・9・20・21・30・34回。Mac単体では動かせず、A40で動かした記録を示す。GPUメモリは第3回で測定済み、値は提供要約にない。電源は本体40Wに対し12V・2Aでは不足し、5Aへの交換で落下が解消。肩約88°より深い姿勢では命令が捨てられた。Piのpymycobotは4.0.4で指令1回1.6秒、2.9.6で送信約0.02秒。ゲームパッドの長押し・単押しの方式も照合する。他の版、接続・撮影設定、データ入手先は記録状態を確認する。

**2．最初に何が返ればよいか**  
第2・4回。段階0＝A40から推論が返る。段階1＝追加学習後の予測をMacで受け取る。第4回のお手本2本・200ステップを最初の実行先とする。  
→「追加学習してMacに予測が届くまでの手順・コード」

**3．どのお手本で学習するか**  
第23・26・27回。30本中7本に浅いつかみがあり、教え直して5か所10本ずつをそろえた。深いお手本50本で元のモデルから3,000ステップ学習した条件、6.2時間・約579円を示す。  
→「50本のお手本で一から学習し直した条件・手順」

**4．実機でどこまでできたか**  
第12・18・28・34回。段階2＝把持、段階3＝箱に入れる。第12回は肩の入力変更で初成功。第28回は位置1で3回とも補正なしの把持、位置2は4回とも姿勢に届かず。第18回の成功6回はすべて補正付き。第34回は5A電源で位置5が5回とも成功、教示再生は7回成功。モデルや補正の不明条件は埋めない。位置C等と位置1等も対応を推測しない。

**5．止まったら何を確かめ、何を送るか**  
第28・29回。位置2の不達に対し、上カメラの画像の傾きだけを変えた1,770回でも行き先は入れ替わらなかった。提供要約から原因は確定できない。

「動いた記録も、途中で止まった記録も、次の人が始めるための確認材料になります」→ `/message`。環境表直後にも同じ道を置く。写せる項目は「機種／電源／Piの版／GPU／参照ログ／段階0〜3／補正／不足情報」。公開は本人の了承後。受信だけで再現確認とはしない。

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

- 第2回：/record/openpi-remote-inference-first-run
- 第3回：/record/pi05-libero-benchmark-first-run
- 第4回：/record/pi05-mecharm-demo-to-inference
- 第9回：/record/teach-replay-19-demos
- 第12回：/record/pi05-first-block-in-box
- 第18回：/record/retrained-pi05-still-needs-human-corrections
- 第20回：/record/gamepad-moves-mecharm-270-pymycobot-version
- 第21回：/record/gamepad-correction-mecharm-270-settled
- 第23回：/record/pi05-failures-traced-to-shallow-grasp-demos
- 第26回：/record/even-ten-demos-per-spot-mecharm-270-reteaching
- 第27回：/record/retrain-pi05-from-base-on-50-even-demos
- 第28回：/record/pi05-even-demos-on-arm-misses-position-2
- 第29回：/record/pi05-position-2-miss-caused-by-camera-tilt
- 第30回：/record/mecharm-270-drops-block-underpowered-adapter
- 第34回：/record/mecharm-270-5a-adapter-stops-dropping-block

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

「フィジカルAI研究室を作る」の上部資料の先頭と、トップの既存シリーズ項目に「π0.5とmechArm 270：使ったもの・始める手順・実機結果」。

`/gpu-buy-or-rent`前半に「A40での追加学習実例：3,000ステップ・6.2時間・約579円（第27回）→ 始める手順」。配置は仮説として検証する。

検索・AIには対象と出典の明確な本文、SNSには電源・版の照合表から送る。個別ログは変えず、トップ・SNSには相談窓口を出さない。

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

人の表示30件までは記録のみ。入口別表示、ログへ進んだ人数・割合、AI依頼による取得、AIリンクからの人の訪問、再現関連の連絡を分ける。取得と訪問は合算しない。3か月で表示30件未満かつ連絡0件なら追加制作を止め、残す。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

数値は依頼の目標で、予測ではない。

- **表示150件**：検索・AI・既存ページに道を作る。対象が狭く届かない可能性。
- **ログへ3割**：冒頭から実行先を示す。照合だけで用が済む可能性。
- **AI取得、2か月目から週3件以上**：条件と出典をまとめる。取得は制御できない。
- **AIリンクから月1件以上**：環境表を確認する理由を作る。回答内で完結する可能性。
- **連絡1〜2件**：段階と不足を送れる。着手されない可能性。
- **再現可能な環境数**：手順・版・不足を第三者が照合できる形にする。公開だけでは加算せず、外部再現の記録か、必要情報に欠落がないという第三者確認を得て判定する。
```


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

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

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

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

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

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

自分の環境との差分、最初に実行する一本、到達点と、着手前に確認すべき不足情報が分かる。

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

**π0.5をmechArm 270で動かす。使ったものと、まだ確認できないこと。**

MacからRunpodのA40を使い、追加学習と実機動作まで進めた記録です。  
お手本50本・3,000ステップの学習は6.2時間・約579円でした。この学習実験の実測で、開始に必要な総費用ではありません（第27回）。  
最初は「お手本2本・200ステップで学習し、Macで予測を受け取る手順」へ（第4回）。実機を動かす前に、下の環境表を照合してください。

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

**コードだけではそろわない実機の条件を、出典付きの文字の表で照合する。**

「項目／記録された条件／確認する場面／出典」を並べる。主役は、Piが読み込むpymycobotの版と電源。肩の姿勢、操作方式も載せる。

記録状態は「値あり」「測定・使用の記録あり、値は提供要約にない」「提供要約では記載を確認できない」を分ける。本文確認前に「ログにない」と断定しない。本文にもなければ「ログにない（未記載）」とし、何の実行・照合を妨げるかを書く。

結果表は「学習条件／電源／位置の原表記／試行数／到達段階／人の補正／出典」。条件不明は明示し、異なる成功を一つの完成環境にまとめない。

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

回番号とURLは次項で対応させる。

**1．Macと手元の機材で始められるか**  
第2・3・9・20・21・30・34回。Mac単体では動かせず、A40で動かした記録を示す。GPUメモリは第3回で測定済み、値は提供要約にない。電源は本体40Wに対し12V・2Aでは不足し、5Aへの交換で落下が解消。肩約88°より深い姿勢では命令が捨てられた。Piのpymycobotは4.0.4で指令1回1.6秒、2.9.6で送信約0.02秒。ゲームパッドの長押し・単押しの方式も照合する。他の版、接続・撮影設定、データ入手先は記録状態を確認する。

**2．最初に何が返ればよいか**  
第2・4回。段階0＝A40から推論が返る。段階1＝追加学習後の予測をMacで受け取る。第4回のお手本2本・200ステップを最初の実行先とする。  
→「追加学習してMacに予測が届くまでの手順・コード」

**3．どのお手本で学習するか**  
第23・26・27回。30本中7本に浅いつかみがあり、教え直して5か所10本ずつをそろえた。深いお手本50本で元のモデルから3,000ステップ学習した条件、6.2時間・約579円を示す。  
→「50本のお手本で一から学習し直した条件・手順」

**4．実機でどこまでできたか**  
第12・18・28・34回。段階2＝把持、段階3＝箱に入れる。第12回は肩の入力変更で初成功。第28回は位置1で3回とも補正なしの把持、位置2は4回とも姿勢に届かず。第18回の成功6回はすべて補正付き。第34回は5A電源で位置5が5回とも成功、教示再生は7回成功。モデルや補正の不明条件は埋めない。位置C等と位置1等も対応を推測しない。

**5．止まったら何を確かめ、何を送るか**  
第28・29回。位置2の不達に対し、上カメラの画像の傾きだけを変えた1,770回でも行き先は入れ替わらなかった。提供要約から原因は確定できない。

「動いた記録も、途中で止まった記録も、次の人が始めるための確認材料になります」→ `/message`。環境表直後にも同じ道を置く。写せる項目は「機種／電源／Piの版／GPU／参照ログ／段階0〜3／補正／不足情報」。公開は本人の了承後。受信だけで再現確認とはしない。

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

- 第2回：/record/openpi-remote-inference-first-run
- 第3回：/record/pi05-libero-benchmark-first-run
- 第4回：/record/pi05-mecharm-demo-to-inference
- 第9回：/record/teach-replay-19-demos
- 第12回：/record/pi05-first-block-in-box
- 第18回：/record/retrained-pi05-still-needs-human-corrections
- 第20回：/record/gamepad-moves-mecharm-270-pymycobot-version
- 第21回：/record/gamepad-correction-mecharm-270-settled
- 第23回：/record/pi05-failures-traced-to-shallow-grasp-demos
- 第26回：/record/even-ten-demos-per-spot-mecharm-270-reteaching
- 第27回：/record/retrain-pi05-from-base-on-50-even-demos
- 第28回：/record/pi05-even-demos-on-arm-misses-position-2
- 第29回：/record/pi05-position-2-miss-caused-by-camera-tilt
- 第30回：/record/mecharm-270-drops-block-underpowered-adapter
- 第34回：/record/mecharm-270-5a-adapter-stops-dropping-block

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

「フィジカルAI研究室を作る」の上部資料の先頭と、トップの既存シリーズ項目に「π0.5とmechArm 270：使ったもの・始める手順・実機結果」。

`/gpu-buy-or-rent`前半に「A40での追加学習実例：3,000ステップ・6.2時間・約579円（第27回）→ 始める手順」。配置は仮説として検証する。

検索・AIには対象と出典の明確な本文、SNSには電源・版の照合表から送る。個別ログは変えず、トップ・SNSには相談窓口を出さない。

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

人の表示30件までは記録のみ。入口別表示、ログへ進んだ人数・割合、AI依頼による取得、AIリンクからの人の訪問、再現関連の連絡を分ける。取得と訪問は合算しない。3か月で表示30件未満かつ連絡0件なら追加制作を止め、残す。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

数値は依頼の目標で、予測ではない。

- **表示150件**：検索・AI・既存ページに道を作る。対象が狭く届かない可能性。
- **ログへ3割**：冒頭から実行先を示す。照合だけで用が済む可能性。
- **AI取得、2か月目から週3件以上**：条件と出典をまとめる。取得は制御できない。
- **AIリンクから月1件以上**：環境表を確認する理由を作る。回答内で完結する可能性。
- **連絡1〜2件**：段階と不足を送れる。着手されない可能性。
- **再現可能な環境数**：手順・版・不足を第三者が照合できる形にする。公開だけでは加算せず、外部再現の記録か、必要情報に欠落がないという第三者確認を得て判定する。
```


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

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

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

### この人がこのページで得るもの
数万円の小型アームとクラウドGPUを使って π0.5 を学習させ、実機で動かすために必要な「具体的な手順、コードのバージョン、かかった費用と時間、そして物理世界で直面する失敗のすべて」を1枚で俯瞰できる見取り図。

### 最初の画面
自宅の机で π0.5 を動かす。小型アーム mechArm 270 での追加学習と実機の全記録

Physical Intelligence の π0.5 を、数万円の小型アームで追加学習して動かした研究のログです。
必要なコードのバージョン、クラウドGPUでの学習費用、そして「電源不足でブロックを落とす」といった実機ならではの泥臭い失敗をすべて晒します。
あなたの環境でこの研究を再現し、ここから先へ進むための土台として使ってください。

### 見せ場
論文や公式リポジトリには絶対に書かれない「物理の壁と依存関係の罠」の生々しい事実と数字。
例えば、アームの反応が遅い原因はAIではなくライブラリのバージョン（pymycobot 4.0.4から2.9.6に戻すと送信が1.6秒から0.02秒に改善）だったり、ブロックを落とす原因が電源アダプターの容量不足（12V・2Aから5Aへの変更で解決）だったりする事実。実機を動かす者だけが直面する泥臭い事実を、ログの数字とともに突きつける。

### 構成
**1. 環境と依存関係：何に躓き、何を揃えれば動くか**
π0.5 は Mac では動かないため、推論と学習は Runpod で A40 を借りて行う。実機を動かす上で最大の罠は依存関係と電源にある。
- 推論環境：Runpod A40（推論平均97ms、往復391ms、費用0.34ドル）
- 依存関係の罠：Pi の daemon が pymycobot 4.0.4 を読むと1回の指令に1.6秒かかる。2.9.6 に戻すと約0.02秒になる。
- 物理の罠：mechArm 270 がブロックを落とす原因は電源不足。本体は40Wを求めるが12V・2A（24W）では落ちる。12V・5A（60W）に替えると落とさなくなる。
- 使うログ：/record/openpi-remote-inference-first-run、/record/gamepad-moves-mecharm-270-pymycobot-version、/record/mecharm-270-drops-block-underpowered-adapter、/record/mecharm-270-5a-adapter-stops-dropping-block

**2. データ収集：お手本はどう作り、何本必要なのか**
π0.5 に渡すお手本は、手で姿勢を教える方法とゲームパッドを使う方法で集めた。
- 限界：肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられる。
- 質と量：浅いつかみの癖を残さないよう、ゲームパッドで深くつかむ姿勢を教え直し、5か所10本ずつ、計50本のお手本を揃えた。
- 使うログ：/record/teach-replay-19-demos、/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos、/record/even-ten-demos-per-spot-mecharm-270-reteaching

**3. 追加学習：A40を使った時間と費用**
集めたお手本を使って π0.5 を一から学習し直す際にかかるコストの事実。
- 実績：位置ごとに10本揃えたお手本50本で一から学習。Runpod の A40 で3,000ステップ回すのに6.2時間、約579円かかった。
- 結果：loss は 0.1015 から 0.0036 まで下がった。
- 使うログ：/record/retrain-pi05-from-base-on-50-even-demos

**4. 実機推論と物理の壁：AIの予測通りに実機が動かない理由**
loss が下がっても、実機は思い通りには動かない。
- 失敗の事実：爪がブロックに乗って止まる、お手本の中の「待ち時間」まで覚えてしまう。
- カメラの傾きではない：位置2を外した理由は上カメラの傾きではなかった（録画の画像の傾きだけを変えて1,770回答えさせても行き先は入れ替わらなかった）。
- 直しのコスト：失敗を人がゲームパッドで直すと1回中央13秒かかる。
- 使うログ：/record/pi05-mecharm-first-real-run、/record/pi05-learned-the-pauses、/record/gamepad-fixes-mecharm-270-ai-in-13-seconds、/record/pi05-position-2-miss-caused-by-camera-tilt

**5. あなたの環境で再現するために**
このページで紹介した各ログには、全文、コード、素材のファイルがすべて付いている。同じ環境を構築し、再現を試してほしい。
- 案内：再現に必要な情報が欠けている場合、または自分の環境で再現できた場合は、メッセージフォームから記録を送ってほしい。
- 使うログ：なし（サイトの仕様とフォームへの案内）

### 束ねるログ
- /record/openpi-remote-inference-first-run
- /record/teach-replay-19-demos
- /record/gamepad-moves-mecharm-270-pymycobot-version
- /record/gamepad-fixes-mecharm-270-ai-in-13-seconds
- /record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- /record/even-ten-demos-per-spot-mecharm-270-reteaching
- /record/retrain-pi05-from-base-on-50-even-demos
- /record/pi05-mecharm-first-real-run
- /record/pi05-learned-the-pauses
- /record/pi05-position-2-miss-caused-by-camera-tilt
- /record/mecharm-270-drops-block-underpowered-adapter
- /record/mecharm-270-5a-adapter-stops-dropping-block

### 今あるページとのつなぎ方
- トップ：1年の記録と課題地図の間に、「再現可能な研究環境」としてこのページのリンクを置く。トップを通る1割の人に気づかせる。
- シリーズ：シリーズ「フィジカルAI研究室を作る」の冒頭に、「全体の手順と依存関係を1枚で俯瞰する入口」としてリンクを置く。
- 今ある LP：/gpu-buy-or-rent（GPUは買うか借りるか）の末尾に、「実際にクラウドGPU（Runpod）で π0.5 を学習・推論させた実例」としてリンクを繋ぐ。

### 公開後に見る数字
- 人の表示数（30件たまるまでは判断しない）
- このページから個別のログへ進んだ人の割合（目標3割）
- AI経由の流入数（ChatGPT等のプロンプトでこのページが参照されているか）
- フォームからの「再現を試した記録」の連絡数

### ゴールにどう効くか
| 見るもの | ゴールに効く理由 | 効かないかもしれない理由 |
|---|---|---|
| このページの人の表示 | 「π0.5 mechArm」等の具体的な検索意図に強く応えるため、Google検索やAIの回答からの直接流入が期待できる。 | ニッチな題材のため、検索ボリューム自体が少なく、表示回数が伸びない可能性がある。 |
| このページからログへ進んだ人 | 依存関係や費用などの「結果の要約」を見せつつ、具体的なコードや手順は各ログに依存しているため、詳細を知りたい人をログへ誘導できる。 | このページだけで満足してしまい、詳細なコードまで見に行かない（ログへ進まない）可能性がある。 |
| AI の利用者の依頼で、このページを読みに来た数 | 「π0.5を動かす手順」という明確な事実と数字がまとまっているため、AIがユーザーの質問に対して参照元として選びやすい。 | AIが要約だけで回答を完結させてしまい、ユーザーがサイトまで訪問しない可能性がある。 |
| AI のリンクから、このページに来た人 | 上記同様、AIの回答に具体的なトラブルシューティング（電源やバージョンの罠）が含まれる場合、情報元としてリンクが踏まれやすい。 | AIのUI上でリンクが目立たず、クリックされない可能性がある。 |
| 問い合わせ・相談 | 「再現を試した記録を送る」という明確な行動を提示し、同じ困難に立ち向かう開発者の連帯感を刺激するため。 | 再現のハードル（アームの購入や環境構築）が高く、3ヶ月以内にそこまで到達する人が出ない可能性がある。 |
```


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

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

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

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

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

   > **π0.5 を mechArm 270 で追加学習して動かすための入口**
   >
   > Mac、Runpod の A40、mechArm 270 を使い、お手本の収集から追加学習、実機推論まで進めた記録を、始める順にまとめました。使った環境、ログで確認できる手順、実機で得た結果を対応させています。再現に必要でも、ログ一覧から確認できない情報は「未記載」と表示します。

2. **【高】依存関係の話はあるが、同じ環境をそろえられるか確認する表がない**

   **弱い所：** pymycobot の版だけでは、主指標の条件である「依存関係とバージョンが記載されている」を満たしたか判断できません。何が分かり、何が欠けているかを読者が調べ直す必要があります。

   **こう直せばもっと強くなる：** 冒頭直下に「使った環境と、まだ確認できない情報」を置きます。

   | 項目 | ログ一覧で確認できること | 不足の表示 |
   |---|---|---|
   | 手元の端末 | Mac から画像・指示を送り、予測を受信 | 機種・基本ソフトの版は未記載 |
   | 学習・推論 | Runpod の A40 を使用 | 実行環境の版は未記載 |
   | アーム制御 | Pi の daemon が読む pymycobot を 4.0.4 から 2.9.6 に戻して送信時間が改善 | Pi の基本ソフトなどは未記載 |
   | モデル・コード | π0.5 を使用 | 取得元の具体的な版・更新履歴の識別子は未記載 |
   | 電源 | 12V・5A への交換後の実機結果あり | 根拠ログへリンク |

   表には根拠ログへのリンクを付けます。「未記載」は公開準備で提示ログの本文・添付を確認し、確認できた項目だけ埋める扱いにします。

3. **【高】章の順番はあるが、各段階で何を確かめて次へ進むのかがない**

   **弱い所：** データ収集から学習、実機までの説明が、出来事の要約にとどまっています。遠隔推論から自分のアームのお手本で学習する間の接続も薄く、「まず開くログ」が決まりません。

   **こう直せばもっと強くなる：** 各章を「行うこと／確認すること／開くログ」で統一し、Log#4 も加えます。

   > **最初は、Mac から予測を受け取るところまで**
   > Mac から画像と指示を送り、A40 上の π0.5 から動きの数値を受け取った手順を確認します。  
   > →［遠隔推論の手順を読む］
   >
   > **次に、自分のアームのお手本で学習し、予測を受け取る**
   > お手本2本・200ステップで追加学習し、Mac で予測を受け取った記録です。この段階では実機を動かしていません。  
   > →［お手本から追加学習・予測受信までを読む］

   後半も同じ形式にすれば、ログへ進む理由が「詳細はこちら」から「自分の次の作業」に変わります。

4. **【高】50本の学習結果と電源交換後の成功が、一続きの完成手順に見える**

   **弱い所：** 50本での学習を紹介する一方、そのモデルを実機で試した Log#28 が抜けています。電源交換後の成功だけが強く残ると、「この構成なら各位置で動く」と受け取られかねません。

   **こう直せばもっと強くなる：** Log#28 を加え、「どこまで確かめたか」を冒頭近くに明示します。

   > **実機で確認できた範囲**
   >
   > - 50本で学習したモデルは、位置1では3回とも補正なしでつかめました。位置2では4回ともつかむ姿勢まで届きませんでした（Log#28）。
   > - 電源を12V・5Aに交換した後は、位置5で5回とも成功しました（Log#34）。
   >
   > これらは別の実験記録です。全位置で安定して動くことを確認したものではありません。

   「何本必要なのか」という章名も、「今回使ったお手本の作り方と本数」に変更します。50本が必要十分という根拠はありません。

5. **【高】最も重い連絡の導線が、再現に着手できた人に偏っている**

   **弱い所：** 最後まで読んで環境を構築した人への呼びかけが中心です。ゴールに含まれる「試そうとしたが、情報不足で止まった人」が、自分も送ってよいと判断しにくい文面です。

   **こう直せばもっと強くなる：** 環境表の後と末尾に、同じフォームへの案内を置きます。

   > **再現を試した・試そうとして止まった記録を送る**
   >
   > 動いた報告に加え、環境をそろえる途中で足りなかった情報も受け付けます。使った環境、開いたログ、進めた所、止まった所を、分かる範囲で送ってください。着手前に確認できなかった項目だけでも送れます。  
   > ［再現の記録・不足情報を送る］→ /message

   これはこの入口ページ内に置き、トップやSNSには相談の窓口を出しません。

6. **【中】「罠」の強調が、実験条件を越えた断定になっている**

   **弱い所：**「論文や公式リポジトリには絶対に書かれない」「最大の罠」は根拠がありません。また、1.6秒から約0.02秒という数字はゲームパッド制御の記録であり、π0.5全体の応答速度の改善とは区別する必要があります。

   **こう直せばもっと強くなる：** 見せ場を、作業前に確認できる具体的な項目へ変えます。

   > **動かす前に確認したい、版と電源**
   >
   > ゲームパッドでの制御では、Pi の daemon が pymycobot 4.0.4 を読んでいたとき、1回の指令に1.6秒かかりました。2.9.6 に戻すと送信は約0.02秒になりました（Log#20）。
   >
   > 電源を12V・2Aから12V・5Aへ交換した後は、位置5で5回とも成功しました。交換前の記録は3回中1回でした（Log#34）。

   数字の強さは、他の資料を否定しなくても十分伝わります。

7. **【中】トップ以外の到達経路が、掲載文面まで具体化されていない**

   **弱い所：** トップを通る人は約1割です。シリーズと既存LPへの設置はよいものの、検索・AI・SNSから「何があるページとして見つかるか」が未設計です。検索需要やAIによる参照の増加も、現時点では仮説です。

   **こう直せばもっと強くなる：** 経路ごとに、掲載する文面と着地点を決めます。

   - **シリーズ冒頭：**「π0.5 と mechArm 270 を始める順に読む。使用環境・手順・実機結果・未記載情報をまとめた入口」
   - **/gpu-buy-or-rent：**「Runpod の A40 で π0.5 を追加学習した実例。お手本50本・3,000ステップで6.2時間、約579円だった記録と、実機までの手順」
   - **SNS：**「π0.5 を mechArm 270 で追加学習し、実機で動かすまでのログをまとめました。使った環境、読む順番、まだ記載のない情報を1ページで確認できます」
   - **検索・AI向け：** ページ本文の冒頭に使用環境と到達範囲を文章でも記載し、各手順に根拠ログを直結させる。発見されやすくなるかは公開後に検証する。

8. **【中】計測が粗く、ゴールに届かなかった理由を判別しにくい**

   **弱い所：**「AI経由の流入数」では、AIが利用者の依頼で読みに来た数と、AIのリンクを人が踏んだ数が混ざります。また、ログへの移動だけでは、再現のどの段階が必要とされているか分かりません。

   **こう直せばもっと強くなる：** 計測と判断を次の文面に置き換えます。

   > 人の表示が30件たまった時点で、ログへ進んだ人の割合と、選ばれた手順を確認します。30件未満では成否を判断しません。環境・データ収集・学習・実機の各リンクとフォームへの移動を分けて記録します。
   >
   > AIの依頼による取得と、AIのリンクからの人の訪問は別集計にします。3か月の目標は、人の表示150件、ログへ進む人3割、AIによる取得は2か月目から週3件以上、AIリンクからの訪問は月1件以上、再現を試した・試そうとした人からの連絡1〜2件です。
   >
   > 3か月で人の表示が30件未満かつ連絡0件なら、追加の手間をかけるのをやめ、ページは残します。

**守るべき尖り**

**再現の成否に関わる条件を、版番号と電源仕様まで下ろして示していること。** pymycobot と電源の記録は、読者が着手前に自分の環境を照合できる材料です。この具体性は消さず、「始める前に確認できる価値」として前面に残してください。
```


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

```markdown
# 案B（第1版）への評

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

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

**こう直す**
構成の1番目に、次の表を置いてください。「ログにない」の行を隠さないことで、第三者が確かめられる形になります。

| 項目 | 記録にあること | 出どころ |
|---|---|---|
| アーム | mechArm 270 | Log#4ほか |
| アームをつなぐ先 | Pi の daemon（Pi の型番はログにない） | Log#20 |
| アームを動かすライブラリ | pymycobot 2.9.6（4.0.4 では1回の指令に1.6秒） | Log#20 |
| 電源 | 12V・5A（12V・2A ではブロックを落とした） | Log#30・#34 |
| 手元の機械 | Mac（π0.5 は Mac では動かない） | Log#2 |
| GPU | Runpod の A40 | Log#2・#27 |
| 直す道具 | 3,198円の互換ゲームパッド | Log#19 |
| お手本の置き場所 | 2TB の外付け SSD | SO-101 Log#2 |
| Python・π0.5 の版・カメラの型番・Pi の型番 | **ログにない（未記載）** | — |

表の下には「この表に足りない項目に気づいたら、フォームから知らせてください」と一文を添えます（5番の指摘につながります）。

---

## 2.【高】失敗は並んでいるが、どう直したかと、いまどこまで動くかが抜けている

**弱い所**
4章は「爪が乗る」「待ち時間まで覚える」「カメラの傾きではない」と失敗を並べるだけで、それをどう越えたかが書かれていません。依頼は「失敗の読み物ではなく、始めるための入口」です。いちばん効く直し方のログも束ねていません。

- Log#12：学習し直さず、AIに渡す肩の角度を直前の目標に変えただけで、初めて箱に入った
- Log#11：止まっている時間を詰めて学習し直した

**こう直す**
ページの最初の画面のすぐ下に「いまの到達点」を置きます。数字はすべてログのとおりです。

> **いまの到達点（ログの記録のまま）**
> - お手本19本・3か所に5回ずつ置いて、15回中9回箱に入った（C 5/5、E 3/5、D 1/5）… Log#14
> - お手本50本で一から学習：位置1は3回とも直しなしでつかめた。位置2は4回ともつかむ姿勢まで届かなかった。理由はまだ分かっていない（カメラの傾きではないことまで確認）… Log#28・#29
> - 電源を12V・5Aに替えると、位置5で5回とも成功（12V・2A の日は3回中1回）… Log#34

あわせて、4章の失敗はすべて「失敗 → 直した方法 → 結果」の3点セットに書き換えます。

| 失敗 | 直した方法 | 結果 | ログ |
|---|---|---|---|
| 待ち時間まで覚えた | 停止を詰めて学習し直した | つかんで箱まで運んだが、箱の外で離した | Log#11 |
| 毎回約2°足りず箱に当たった | 肩の角度を直前の目標に変えた | 初めて箱に入った | Log#12 |
| 浅いつかみ（学習データ30本中7本が浅かった） | ゲームパッドで教え直し、5か所10本ずつにした | 50本で一から学習 | Log#23・#26 |

束ねるログに Log#11・#12・#14・#23・#28・#34 を加えてください（Log#11 は束ねるログの一覧にはあるので、表にも載せます）。

---

## 3.【高】ログにない事実と、言い過ぎ

**弱い所と直し方**

| 企画書の表現 | 問題 | 書き直し |
|---|---|---|
| 「数万円の小型アーム」（3か所） | 値段はログにない | 「小型アーム mechArm 270」。値段は環境表で「ログにない」とする |
| 「全記録」「失敗をすべて晒します」 | 束ねるのは34本中12本 | 「フィジカルAI研究室を作る Log#1〜#34 の入口」 |
| 「論文や公式リポジトリには絶対に書かれない」 | 他を悪く言う演出で、確かめられない | 削る。代わりに「実機で動かして初めて出た数字」 |
| 「12V・5A（60W）」 | 60W はログにない | 「12V・5A（12×5で60W・計算）」と計算であることを書く |
| 「1回中央13秒かかる」 | 比べる相手がなく、長所が伝わらない | 「キーで直した回の41〜51秒が、ゲームパッドで中央13秒に」（Log#22）。関節を動かすのは2.6秒だけ、という Log#32 も添える |

---

## 4.【中】章の並びを「始める人の順番」にし、各章の終わりに「次に読む1本」を置く

**弱い所**
今の章立ては「環境 → データ → 学習 → 実機」で、正しい方向です。ただ、最初の一歩（借りたGPUで推論を通す・GPUメモリを測る）が環境の章の中に埋もれています。また、ページの上で要約が済んでしまう作りなので、作者自身が「このページだけで満足してしまう」と書いているとおりになり、「表示した人の3割をログへ」に届きにくくなります。

**こう直す**
次の順番にします。

0. いまの到達点
1. そろえるもの（環境表）
2. まず GPU で推論を通す（Log#2：平均97ms・往復391ms・0.34ドル、Log#3：LIBERO で20回すべて成功・メモリを測った）
3. お手本を集める（Log#8・#9・#25・#26）
4. 追加学習（Log#4 の200ステップ → Log#5 → Log#27 の50本・6.2時間・約579円。GPUの空き待ちで約4時間半かかった日もあった、Log#10）
5. 実機で動かす（2番の表）
6. つまずき索引（症状から引ける形：「指令が遅い → Log#20」「ブロックを落とす → Log#30・#34」「肩約88°より深い姿勢が動かない → Log#9」「爪がブロックに乗る → Log#6・#25」）
7. 試した記録を送る

各章の終わりには、要約の続きを1行だけ書いて送ります。例：「200ステップでの最初の学習の手順とコードは → Log#4」。6章の索引は、Google からログに直接来て1本で帰る人のためにも、そのまま使えます。

---

## 5.【中】フォームへの道が「送ってほしい」だけで、何を送ればよいか分からない

**弱い所**
いちばん重い指標は「再現を試した、または試そうとした人からの連絡1〜2件」です。ところが、何を書けばよいかが示されていないので、試しかけた人が送る理由がありません。「連帯感を刺激する」は手立てになっていません。

**こう直す**
7章を次の文面にします。

> **試した記録を送る**
> 途中で止まった記録も、そのまま役に立ちます。次の3つを書いて、メッセージフォーム（/message）から送ってください。
> 1. どの章・どのログまで進んだか
> 2. あなたの環境で、上の表と違うもの（アーム・GPU・ライブラリの版など）
> 3. 止まった所、または表に「ログにない」と書いてあって困った所
>
> 届いた記録は、本人の了解を得てから、この表の「ログにない」を埋めるのに使います。

「試そうとした人」も入れて、敷居を下げる形です。最後の一文の運用（了解を得て表に反映する）はエイイチの判断が要るので、可否を確認してください。

---

## 6.【中】どこから来るかが3か所だけで、AI からの道が書かれていない

**弱い所**
依頼は「どこから来るかを具体に書く」ことでした。企画書にはトップ・シリーズ・GPU の LP しかありません。AI の利用者の依頼で読みに来る数は週42〜61件あり、その多くがトップに来ています。それなのに、AI に読まれる作りの話がありません。SNS（LinkedIn 10件）も書かれていません。

**こう直す**

- **AI から**
  - 環境表・到達点・つまずき索引を、画像ではなく文字の表で書く
  - すべての数字の横にログの URL を置く。AI がそのまま引用し、リンクを出せる形にするため
  - トップは AI がいちばん読んでいるので、トップからのリンク文は「π0.5 を mechArm 270 で追加学習した環境・手順・結果」と、聞かれそうな言葉そのままにする
- **トップから**
  - 新しい枠は作らず、今ある「シリーズ」欄の「フィジカルAI研究室を作る」の横に置く（新しい見出しを増やさないため）
- **GPU の LP（/gpu-buy-or-rent）から**
  - 末尾の文面：「借りた A40 で π0.5 を3,000ステップ学習すると、6.2時間・約579円でした。手順と環境はこちら」
- **SNS から**
  - LinkedIn に「Log#20（版を戻すと1.6秒が約0.02秒に）」のような1つの罠を書いて、このページへ送る。相談の窓口は出さない
- **ゴール表の「効かないかもしれない理由」**
  - それぞれに手当てを1行足す。例：「ページだけで満足してしまう → 要約は1行で止め、手順はログへ送る（4番）」

---

## 7.【低】題名が長く、「全記録」が言い過ぎ

**こう直す**
題名の候補は次のとおりです。

- 「π0.5 を mechArm 270 で追加学習し、実機で動かす ─ 環境・手順・結果の入口」
- 「π0.5 × mechArm 270 再現の入口（Log#1〜#34）」

「自宅の机で」は Log#1（自宅にゼロから）が根拠になるので、副題に残すのはよいと思います。

---

## 守るべき尖り

**依存関係と電源の落とし穴を、版と数字のまま前に出していること。**
「pymycobot 4.0.4 → 2.9.6 で、1回の指令が1.6秒 → 約0.02秒」「12V・2A → 12V・5A で、位置5は3回中1回 → 5回とも成功」。これは判定条件②（依存関係とバージョン）そのものです。同時に、同じ環境から始める人が最初の1日で踏む落とし穴を先に潰します。書き直しで表現を丸めても、この数字の組だけは消さず、ページの上の方に置いたままにしてください。
```


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

```markdown
【採否】
案A-1：採る。事実誤認（全記録、すべて、数万円）を正し、ページが約束するものを明確にするため。
案A-2：採る。主指標の条件を満たすための環境表は必須であるため。
案A-3：採る。各段階で何を確かめるかを示し、手順として機能させるため。
案A-4：採る。50本の学習が全位置での完成だと誤認されるのを防ぐため。
案A-5：採る。最も重い指標であるフォームへの連絡のハードルを下げるため。
案A-6：採る。他を悪く言う演出や断定を避け、事実と数字だけを残すため。
案A-7：採る。AIやSNSなど、トップ以外の到達経路からの流入設計が必要なため。
案A-8：一部採る。計測と判断の文面は直すが、指定された「公開後に見る数字」の項目に落とし込むため。
案C-1：採る。ログにない情報を明示し、第三者が確かめられる形にするため。
案C-2：採る。失敗だけでなく、直し方と現在の到達点を示すことで入口として機能するため。
案C-3：採る。ログにない事実や言い過ぎを排除するルールを厳守するため。
案C-4：採る。始める人の順番に並べ、要約を寸止めしてログへ誘導する構成にするため。
案C-5：一部採る。連絡の敷居を下げる項目は採るが、表への反映はエイイチの判断が必要なため記載を控える。
案C-6：採る。AIから読まれるための文字組みやリンク配置、各経路の文面を具体化するため。
案C-7：採る。事実誤認を正し、中身に合ったページ名にするため。

【企画書】

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

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

### この人がこのページで得るもの
π0.5 と mechArm 270 を使った追加学習と実機推論について、同じ環境から始めるために必要な手順、版と数字、足りない情報、そして現在の到達点がわかる見取り図。

### 最初の画面
π0.5 を mechArm 270 で追加学習し、実機で動かす ─ 環境・手順・結果の入口

Mac、Runpod の A40、小型アーム mechArm 270 を使い、お手本の収集から追加学習、実機推論まで進めた研究のログを、始める順にまとめました。
使った環境、ログで確認できる手順、実機で得た結果を対応させています。再現に必要でも、ログ一覧から確認できない情報は「ログにない（未記載）」と表示しています。
あなたの環境でこの研究を再現し、ここから先へ進むための土台として使ってください。

### 見せ場
再現の成否に関わる条件を、版番号と電源の数字のまま前に出していること。
例えば、アームの指令が遅い原因は pymycobot 4.0.4 であり、2.9.6 に戻すと送信が1.6秒から約0.02秒に改善した事実（Log#20）。ブロックを落とす原因は電源不足であり、12V・2Aから12V・5A（12×5で60W・計算）へ交換すると位置5で5回とも成功した事実（Log#30・#34）。同じ環境から始める人が踏む落とし穴を先に潰す。

### 構成
**1. そろえるものと、ログにない情報（環境表）**
AIが読み取れるよう文字の表で提示し、不足を明示する。
- 書くこと：再現に必要な環境と、ログにない情報の明示。
- 使う事実とログ：mechArm 270（Log#4ほか）、pymycobot 2.9.6・Piのdaemon（Log#20）、電源12V・5A（Log#30・#34）、Mac・RunpodのA40（Log#2・#27）、3,198円の互換ゲームパッド（Log#19）、2TBの外付けSSD（SO-101 Log#2）。Pythonやπ0.5の版、Piの型番は「ログにない（未記載）」。

**2. いまの到達点（実機で確認できた範囲）**
全位置で動くわけではない事実と、失敗からの直し方を置く。
- 書くこと：現在の成功率と、失敗をどう直したか。
- 使う事実とログ：お手本19本・3か所で15回中9回成功（Log#14）。お手本50本で一から学習し、位置1は3回成功、位置2は4回届かず、カメラの傾きではない（Log#28・#29）。12V・5Aに替えて位置5で5回成功（Log#34）。停止を詰めて学習し直す（Log#11）、肩の角度を直前の目標に変えて初めて箱に入った（Log#12）。

**3. まず GPU で推論を通す**
- 書くこと：遠隔推論の手順とGPUメモリの確認。
- 使う事実とログ：Macから画像と指示を送り予測を受信。平均97ms・往復391ms・0.34ドル（Log#2）。LIBEROで20回すべて成功・メモリを測った（Log#3）。
- 次に読む1本：遠隔推論の手順とコードは → Log#2

**4. お手本を集める**
- 書くこと：手とゲームパッドによる収集と、姿勢の限界。
- 使う事実とログ：肩約88°より深い姿勢はエラーなしに捨てられる（Log#9）。浅いつかみをゲームパッドで深く教え直し、5か所10本ずつ計50本に（Log#23・#26）。
- 次に読む1本：深くつかむお手本を教え直した記録は → Log#26

**5. 追加学習と実機で動かす**
- 書くこと：200ステップから50本・3,000ステップへの学習と、実機での直し。
- 使う事実とログ：200ステップでMacで予測受信（Log#4）。50本で一から学習し、A40で3,000ステップに6.2時間・約579円（Log#27）。GPU空き待ちで約4時間半（Log#10）。失敗をゲームパッドで直すと中央13秒、キーの41〜51秒より短く、関節を動かすのは2.6秒（Log#22・#32）。
- 次に読む1本：50本で一から学習し直した記録は → Log#27

**6. つまずき索引と、試した記録を送る**
- 書くこと：症状から引ける索引と、フォームへの案内。
- 使う事実とログ：指令が遅い → Log#20、ブロックを落とす → Log#30・#34、肩約88°より深い姿勢が動かない → Log#9、爪がブロックに乗る → Log#6・#25。
- フォーム案内（/message）：進んだ章、環境の違い、止まった所や未記載で困った所を送るよう促す。

### 束ねるログ
- SO-101 Log#2
- Log#2, #3, #4, #6, #9, #10, #11, #12, #14, #19, #20, #22, #23, #25, #26, #27, #28, #29, #30, #32, #34

### 今あるページとのつなぎ方
- トップ：今ある「シリーズ」欄の「フィジカルAI研究室を作る」の横に、「π0.5 を mechArm 270 で追加学習した環境・手順・結果」としてリンクを置く。
- シリーズ冒頭：「π0.5 と mechArm 270 を始める順に読む。使用環境・手順・実機結果・未記載情報をまとめた入口」としてリンクを置く。
- /gpu-buy-or-rent（GPUは買うか借りるか）：末尾に「借りた A40 で π0.5 を3,000ステップ学習すると、6.2時間・約579円でした。手順と環境はこちら」と置く。
- SNS：LinkedInに「Log#20（版を戻すと1.6秒が約0.02秒に）」など1つの罠を書き、このページへ送る。

### 公開後に見る数字
- 人の表示数（30件たまるまでは判断しない）
- ログへ進んだ人の割合と、選ばれた手順のリンク（環境・データ・学習・実機の各リンク移動を分けて記録）
- AI の利用者の依頼で読みに来た数（AI経由の取得と、AIリンクからの人の訪問は別集計にする）
- フォームからの「再現を試した・試そうとした記録」の連絡数

### ゴールにどう効くか
| 見るもの | ゴールに効く理由 | 効かないかもしれない理由 |
|---|---|---|
| このページの人の表示 | トップやLPから具体数字を添えて誘導するため。 | ニッチな題材で絶対数が少ない。→ AIや検索向けの文字起こしで手当てする。 |
| このページからログへ進んだ人 | 手順ごとに「次に読む1本」を置き、次の作業としてログを開く理由を作るため。 | このページだけで満足する。→ 要約は1行で止め、手順はログへ送る作りにした。 |
| AI の利用者の依頼で読みに来た数 | 表や到達点を文字にし、数字の横にログURLを置いてAIが引用しやすくするため。 | AIが要約だけで回答を完結させる。→ 手順の詳細は各ログに分散させている。 |
| AI のリンクから、このページに来た人 | AIが「未記載情報」や「つまずき索引」を含めた際、情報元として踏まれやすいため。 | AIのUI上でリンクが目立たない。→ AIの回答にURLが直接出るよう本文に配置する。 |
| 問い合わせ・相談 | 「試そうとして止まった記録」も歓迎し、書く内容を明示して敷居を下げるため。 | 再現のハードルが高く試す人が出ない。→ 読むだけでも索引が役立つ構成にした。 |
```


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

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

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

### この人がこのページで得るもの
π0.5 と mechArm 270 を使った追加学習と実機推論について、同じ環境から始めるために必要な手順、版と数字、足りない情報、そして現在の到達点がわかる見取り図。

### 最初の画面
π0.5 を mechArm 270 で追加学習し、実機で動かす ─ 環境・手順・結果の入口

Mac、Runpod の A40、小型アーム mechArm 270 を使い、お手本の収集から追加学習、実機推論まで進めた研究のログを、始める順にまとめました。
使った環境、ログで確認できる手順、実機で得た結果を対応させています。再現に必要でも、ログ一覧から確認できない情報は「ログにない（未記載）」と表示しています。
あなたの環境でこの研究を再現し、ここから先へ進むための土台として使ってください。

### 見せ場
再現の成否に関わる条件を、版番号と電源の数字のまま前に出していること。
例えば、アームの指令が遅い原因は pymycobot 4.0.4 であり、2.9.6 に戻すと送信が1.6秒から約0.02秒に改善した事実（Log#20）。ブロックを落とす原因は電源不足であり、12V・2Aから12V・5A（12×5で60W・計算）へ交換すると位置5で5回とも成功した事実（Log#30・#34）。同じ環境から始める人が踏む落とし穴を先に潰す。

### 構成
**1. そろえるものと、ログにない情報（環境表）**
AIが読み取れるよう文字の表で提示し、不足を明示する。
- 書くこと：再現に必要な環境と、ログにない情報の明示。
- 使う事実とログ：mechArm 270（Log#4ほか）、pymycobot 2.9.6・Piのdaemon（Log#20）、電源12V・5A（Log#30・#34）、Mac・RunpodのA40（Log#2・#27）、3,198円の互換ゲームパッド（Log#19）、2TBの外付けSSD（SO-101 Log#2）。Pythonやπ0.5の版、Piの型番は「ログにない（未記載）」。

**2. いまの到達点（実機で確認できた範囲）**
全位置で動くわけではない事実と、失敗からの直し方を置く。
- 書くこと：現在の成功率と、失敗をどう直したか。
- 使う事実とログ：お手本19本・3か所で15回中9回成功（Log#14）。お手本50本で一から学習し、位置1は3回成功、位置2は4回届かず、カメラの傾きではない（Log#28・#29）。12V・5Aに替えて位置5で5回成功（Log#34）。停止を詰めて学習し直す（Log#11）、肩の角度を直前の目標に変えて初めて箱に入った（Log#12）。

**3. まず GPU で推論を通す**
- 書くこと：遠隔推論の手順とGPUメモリの確認。
- 使う事実とログ：Macから画像と指示を送り予測を受信。平均97ms・往復391ms・0.34ドル（Log#2）。LIBEROで20回すべて成功・メモリを測った（Log#3）。
- 次に読む1本：遠隔推論の手順とコードは → Log#2

**4. お手本を集める**
- 書くこと：手とゲームパッドによる収集と、姿勢の限界。
- 使う事実とログ：肩約88°より深い姿勢はエラーなしに捨てられる（Log#9）。浅いつかみをゲームパッドで深く教え直し、5か所10本ずつ計50本に（Log#23・#26）。
- 次に読む1本：深くつかむお手本を教え直した記録は → Log#26

**5. 追加学習と実機で動かす**
- 書くこと：200ステップから50本・3,000ステップへの学習と、実機での直し。
- 使う事実とログ：200ステップでMacで予測受信（Log#4）。50本で一から学習し、A40で3,000ステップに6.2時間・約579円（Log#27）。GPU空き待ちで約4時間半（Log#10）。失敗をゲームパッドで直すと中央13秒、キーの41〜51秒より短く、関節を動かすのは2.6秒（Log#22・#32）。
- 次に読む1本：50本で一から学習し直した記録は → Log#27

**6. つまずき索引と、試した記録を送る**
- 書くこと：症状から引ける索引と、フォームへの案内。
- 使う事実とログ：指令が遅い → Log#20、ブロックを落とす → Log#30・#34、肩約88°より深い姿勢が動かない → Log#9、爪がブロックに乗る → Log#6・#25。
- フォーム案内（/message）：進んだ章、環境の違い、止まった所や未記載で困った所を送るよう促す。

### 束ねるログ
- SO-101 Log#2
- Log#2, #3, #4, #6, #9, #10, #11, #12, #14, #19, #20, #22, #23, #25, #26, #27, #28, #29, #30, #32, #34

### 今あるページとのつなぎ方
- トップ：今ある「シリーズ」欄の「フィジカルAI研究室を作る」の横に、「π0.5 を mechArm 270 で追加学習した環境・手順・結果」としてリンクを置く。
- シリーズ冒頭：「π0.5 と mechArm 270 を始める順に読む。使用環境・手順・実機結果・未記載情報をまとめた入口」としてリンクを置く。
- /gpu-buy-or-rent（GPUは買うか借りるか）：末尾に「借りた A40 で π0.5 を3,000ステップ学習すると、6.2時間・約579円でした。手順と環境はこちら」と置く。
- SNS：LinkedInに「Log#20（版を戻すと1.6秒が約0.02秒に）」など1つの罠を書き、このページへ送る。

### 公開後に見る数字
- 人の表示数（30件たまるまでは判断しない）
- ログへ進んだ人の割合と、選ばれた手順のリンク（環境・データ・学習・実機の各リンク移動を分けて記録）
- AI の利用者の依頼で読みに来た数（AI経由の取得と、AIリンクからの人の訪問は別集計にする）
- フォームからの「再現を試した・試そうとした記録」の連絡数

### ゴールにどう効くか
| 見るもの | ゴールに効く理由 | 効かないかもしれない理由 |
|---|---|---|
| このページの人の表示 | トップやLPから具体数字を添えて誘導するため。 | ニッチな題材で絶対数が少ない。→ AIや検索向けの文字起こしで手当てする。 |
| このページからログへ進んだ人 | 手順ごとに「次に読む1本」を置き、次の作業としてログを開く理由を作るため。 | このページだけで満足する。→ 要約は1行で止め、手順はログへ送る作りにした。 |
| AI の利用者の依頼で読みに来た数 | 表や到達点を文字にし、数字の横にログURLを置いてAIが引用しやすくするため。 | AIが要約だけで回答を完結させる。→ 手順の詳細は各ログに分散させている。 |
| AI のリンクから、このページに来た人 | AIが「未記載情報」や「つまずき索引」を含めた際、情報元として踏まれやすいため。 | AIのUI上でリンクが目立たない。→ AIの回答にURLが直接出るよう本文に配置する。 |
| 問い合わせ・相談 | 「試そうとして止まった記録」も歓迎し、書く内容を明示して敷居を下げるため。 | 再現のハードルが高く試す人が出ない。→ 読むだけでも索引が役立つ構成にした。 |
```


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

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

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

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

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

   > このページでは、同じ環境をそろえるために確認できる情報と、未記載の情報を並べています。Python・π0.5の版、Piの型番は、提示されたログ一覧では確認できません。この入口だけで再現に必要な情報がすべてそろうとは、まだ確認できていません。

2. **【高】別の研究のSSDが、今回そろえる必須品に見える**

   **弱い所：** SO-101 Log#2は、模倣学習データを2TBの外付けSSDに集める判断の記録です。今回のπ0.5・mechArm 270の研究でそのSSDを使ったことや、再現に必須であることは、この一覧から確認できません。

   **こう直せばもっと強くなる：** 必須の環境表から外し、同じ章の参考情報に移します。

   > データの保存先を決める参考：SO-101の研究では、模倣学習データを2TBの外付けSSDに集めました。今回のπ0.5・mechArm 270環境での使用有無は、ログ一覧では未記載です。→ SO-101 Log#2

   ゲームパッドも「ゲームパッドでお手本作成・補正を行う工程で使用」と書き、全工程の必須品と混同させない形にします。

3. **【高】条件の違う結果を「現在の成功率」としてまとめている**

   **弱い所：** Log#14の15回中9回、Log#28の位置1・2、Log#34の電源交換後では条件も測った結果も違います。特に「つかめた」と「箱に入れた」を同じ成功として扱うと、到達点を誤って伝えます。

   **こう直せばもっと強くなる：** 「現在の成功率」を「条件別に確認できた結果」に変え、次のように分けます。

   > ・Log#14：3か所に各5回置き、箱に入ったのは15回中9回。  
   > ・Log#28：50本で学習したモデルで、位置1は3回とも補正なしでつかめた。位置2は4回ともつかむ姿勢まで届かなかった。  
   > ・Log#34：電源を12V・5Aに交換後、位置5で5回とも成功。  
   > これらを合わせた成功率や、電源交換後の全位置での結果は示していません。

4. **【高】補正時間の数字が、別の測定から一続きに見える**

   **弱い所：** 第5章の「中央13秒」「キーの41〜51秒」「関節を動かすのは2.6秒」は、Log#22とLog#32をまたいでいます。13秒の内訳が2.6秒だったように読めます。

   **こう直せばもっと強くなる：** 測定を分けます。

   > Log#22では、ゲームパッドによる補正は1回の中央値13秒で、以前のキー操作の41〜51秒より短くなりました。別の測定であるLog#32では中央値14.5秒、そのうち関節を動かす時間は2.6秒でした。

   本筋ではLog#32だけを使い、詳しい比較を索引へ送る方法でも十分です。

5. **【高】「始める順」の最後に、実機へ進むためのリンクがない**

   **弱い所：** 第5章は追加学習と実機を一緒に扱っていますが、「次に読む1本」は学習のLog#27だけです。初期の200ステップ学習やGPU待ち、補正時間も同居し、学習後に何を開くかが埋もれます。

   **こう直せばもっと強くなる：** 第5章を二段にし、作業と確認結果を対応させます。

   > **追加学習する**  
   > 5か所10本ずつのお手本50本から学習した条件と記録を確認する。→ Log#27  
   >
   > **学習したモデルを実機で試す**  
   > 50本で学習したモデルを動かした結果を確認する。位置1と位置2で結果が分かれています。→ Log#28  
   > 実機の電源条件と交換後の結果も、実行前に確認する。→ Log#30・#34

   各段階には「ログで確認できること」と「未記載」を添えます。実行手順の存在まで要約から確認できない場合は、「手順はこちら」と言い切らない方が正確です。

6. **【中】検索・AIから来る人への入口が、抽象的な期待にとどまっている**

   **弱い所：** トップ経由は実測で約1割です。一方、「文字起こしで手当て」「本文にURLを置けばAIの回答に出る」は、流入が生まれる根拠になっていません。本文は既に文字なので、何を改善するのかも曖昧です。

   **こう直せばもっと強くなる：** 検索・AIに聞かれそうな問いを見出しとして置き、回答と根拠ログを対応させます。

   > ・π0.5をmechArm 270で動かした環境は？  
   > ・追加学習に使ったGPU・時間・費用は？  
   > ・実機でどこまで成功し、何が未確認か？  
   > ・同じ環境をそろえるために、何の情報が足りないか？

   企画書の説明も、次に改めます。

   > これらの問いへの回答を本文に明記し、検索・AIから参照される入口を作る。掲載や引用は保証できないため、AIによる取得数と、人の訪問数を別に測る。

7. **【高】最も重い「試そうとした人からの連絡」への対策が、読む人向けの索引になっている**

   **弱い所：** 「試す人が出ない」に対する「読むだけでも索引が役立つ」は、連絡のゴールに効きません。また、フォームが末尾だけでは、環境表で不足に気づいた人が送るまでの距離が長いです。

   **こう直せばもっと強くなる：** 環境表の未記載欄と末尾の両方に、同じフォームへの案内を置きます。

   > **再現を試した記録・始める前に足りなかった情報を送る**  
   > 実機をまだ動かしていなくても送れます。  
   > 「始めようとした工程」「使う予定・使った環境」「不足していた情報、または止まった所」を、分かる範囲で記入してください。→ /message

   「読むだけでも役立つ」ではなく、「始める準備で止まったことも、このページを補う記録になる」と位置づけます。

8. **【中】公開後の計測項目に、判断期限と判断後の行動が入っていない**

   **弱い所：** 数える項目はありますが、依頼にある「最初の30件」「3か月」の判断が企画書に戻っていません。数字を集めても、何を直すか決まりにくい状態です。

   **こう直せばもっと強くなる：** 計測欄に次を加えます。

   > 人の表示が30件たまった時点で、ログへ進んだ人の割合を目標の3割と照合する。フォームの記録は、試す前の不足と、試した後の停止箇所を読み、環境表・導線の修正に使う。少数の結果から効果を断定しない。  
   > 公開3か月で人の表示が30件未満、かつ連絡0件なら、追加の制作を止めてページは残す。

**守るべき尖り**

**「同じ環境」を、pymycobotの版と電源容量まで具体化していること。** 「環境を確認してください」で済ませず、Piのdaemonが読んだ4.0.4と2.9.6、12V・2Aと12V・5Aの違いを根拠ログつきで見せる。この具体性が、始める人に保存する理由を与えています。
```


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

```markdown
# 案B（第2版）への評

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

---

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

**弱い所**
- **言い過ぎ**：「位置1は3回成功」。Log#28 の要約にあるのは「位置1 は3回とも直しなしで**つかめた**」までです。箱に入れたとは書いていません。
- **ログ一覧にない数字**：Log#14 の「15回中9回」に「お手本19本」を付けています。Log#14 の要約には、お手本の本数が書かれていません。
- **重い抜け**：Log#18 にある「成功6回はすべて補正つき。補正なしの1回は根元が約2°足りず空振り」がありません。再現する人がいちばん知りたいのは「人の手なしでどこまで動くか」です。これを伏せると、到達点を実際より良く見せることになります。
- **抜け**：結果ごとに、どの電源で出た結果かが書かれていません。Log#30 にあるとおり、12V・2A では足りませんでした。だから、それより前の成功率がどの電源で出たかは、再現する人にとって条件の一部です。
- **抜け**：Log#14 は位置を C/D/E、Log#28 は1〜5 と、ログによって位置の呼び方が違います。この対応がログ一覧にありません。

**こう直す（2章の書き換え案）**
> **いまの到達点（実機で確かめた範囲）**
> - 3か所に5回ずつ置くと、15回中9回、箱に入れた。位置Cは5/5、Eは3/5、腕を伸ばしきるDは1/5（Log#14）
> - 人が直した5回で学び直しても、成功6回はすべて人の補正つきだった。補正なしの1回は根元が約2°足りず空振りした（Log#17・#18）
> - 深いお手本50本で一から学習すると、位置1は3回とも直しなしでつかめた。位置2は4回ともつかむ姿勢まで届かなかった。原因はカメラの傾きではなかった（Log#28・#29）
> - 電源を12V・2Aから12V・5Aに替えると、位置5で5回とも成功した。2Aの日は3回中1回（Log#34）
> - **ログにない（未記載）**：それぞれの結果がどの電源で出たか／位置C・D・Eと位置1〜5の対応

あわせて、束ねるログに Log#17・#18 を足してください。

---

## 2.【高】環境表が、主指標の判定（②③）に使えるチェック表になっていない

**弱い所**
主指標の判定条件②は「依存関係とバージョンが書かれている」、③は「足りない情報がないことを第三者が確かめられる」です。いまの1章は、使ったものを並べた文章です。どの項目が埋まり、どの項目が空いているかが、1枚で見えません。
また、SO-101 Log#2 の「2TBの外付けSSD」は別シリーズの話です。π0.5 と mechArm 270 で使ったとは、ログ一覧に書かれていません。
もう一つ、各ログには全文とコードのファイルが付いています。要約に書かれていないだけで「ログにない」と書くと、本文には書いてあった場合に誤りになります。

**こう直す（1章を、この列のある表にする）**

| 項目 | ログにある値 | 出どころ | 状態 |
|---|---|---|---|
| アーム | mechArm 270 | Log#4 | 記載あり |
| アームを動かすライブラリ | pymycobot 2.9.6（4.0.4 では1回の指令に1.6秒かかった） | Log#20 | 記載あり |
| アームの電源 | 12V・5A（本体は40Wを求める。12V・2A＝24Wでは落とした） | Log#30・#34 | 記載あり |
| 学習・推論の GPU | Runpod の A40 | Log#2・#27 | 記載あり |
| 手直しの道具 | 互換ゲームパッド 3,198円（ボタン16個・軸6本） | Log#19 | 記載あり |
| Python・openpi・π0.5 の版 | — | — | ログにない（未記載） |
| Pi の型番・カメラの型番 | — | — | ログにない（未記載） |
| ブロックと箱の大きさ | — | — | ログにない（未記載） |

- SSD の行は消してください。
- 公開する前に、空いている行が各ログの全文とコードに本当にないかを確かめてください。本文にあれば「記載あり（Log#◯の本文）」とします。なければ「ログにない」です。
- 表の下に、次の一文を置きます。
  「この表の『ログにない』を埋められる人、ここで止まった人は、[再現を試した記録を送る](/message) へ」

---

## 3.【高】学習した回ごとに「使ったもの → 結果」を並べた表がない

**弱い所**
依頼の出発点は「手順・使ったもの・結果がそろっていることを1枚で確かめられない」ことでした。ところが3〜5章では、学習の回が文章の中に散っています。そのため、お手本の本数、ステップ数、loss、実機の結果の対応が1枚で読めません。
もう一つ、この研究の中でいちばん強い発見が使われていません。Log#7 の「loss が 0.0030 まで下がっても、爪は2回ともブロックの奥で空を閉じた」です。

**こう直す（2章の前に「学習の回ごとの表」を置き、見せ場に加える）**

| 回 | お手本 | ステップ | loss | 実機の結果 |
|---|---|---|---|---|
| Log#4 | 2本 | 200 | 0.1031→0.0162 | まだ動かしていない |
| Log#5・#6 | 19本 | 2,000 | 0.1155→0.0054 | 爪がブロックに乗った |
| Log#7 | 19本 | 4,000 | 0.0030まで | 爪は2回とも奥で空を閉じた |
| Log#10 | 5か所19本 | 4,000 | 0.0858→0.0037 | （Log#11〜#14へ） |
| Log#17 | 人が直した5回 | 前のモデルから1,500 | ログ一覧にない | 成功6回はすべて補正つき（Log#18） |
| Log#27・#28 | 5か所×10本＝50本 | 一から3,000（6.2時間・約579円） | 0.1015→0.0036 | 位置1は直しなしでつかめた／位置2は届かず |

見せ場には、次の一行を足します。
> **loss が下がっても、実機で届くとは限らなかった。** 0.0030まで下げても爪は奥で空を閉じ（Log#7）、原因はお手本の浅いつかみだった（学習データ30本中7本・Log#23）。

束ねるログに Log#5・#7 を足してください。

---

## 4.【中】別々のログの数字を混ぜていて、読む人が確かめると合わない

**弱い所**
- 5章の「中央13秒、キーの41〜51秒より短く、関節を動かすのは2.6秒（Log#22・#32）」は、2本のログの数字を1つの文にしています。2.6秒が載っている Log#32 では、中央は14.5秒、キーボードは43.2秒です。
- 見せ場と LinkedIn の「送信が1.6秒から約0.02秒」も同じです。Log#20 では、1.6秒は「1回の指令」、約0.02秒は「送信」で、測ったものの書き方が違います。

**こう直す**
- 5章：
  > ゲームパッドで直すと1回は中央13秒。キーで直した回は41〜51秒だった（Log#22）。別の計測では中央14.5秒で、そのうち関節を動かしていたのは2.6秒。残りは直しの出入りとつかみ直しだった（Log#32）
- 見せ場・LinkedIn：
  > Pi の daemon が pymycobot 4.0.4 を読んでいて、1回の指令に1.6秒かかっていた。2.9.6 に戻すと、送信は約0.02秒になった（Log#20）

---

## 5.【中】最初の画面が、どの研究でも言える説明になっている

**弱い所**
「Mac、Runpod の A40…始める順にまとめました」「土台として使ってください」は、どの研究の入口にも書ける文です。保存したくなる理由になる数字と落とし穴が、最初の画面にひとつもありません。

**こう直す（見出しはそのまま、本文を差し替える）**
> Runpod で借りた A40 で π0.5 を追加学習し、小型アーム mechArm 270 の実機で動かした記録の入口です。
> 実機では、3か所に置いたブロックを15回中9回箱に入れました（Log#14）。成功の多くには、人の直しが要りました（Log#18）。
> 先に知っておくと時間を失わない所：pymycobot の版（4.0.4 では指令1回に1.6秒・Log#20）、電源アダプター（12V・2Aでは落とし、5Aで位置5を5回とも成功・Log#34）。
> 使った環境の表では、ログに書いていない版や型番を「ログにない」と表示しています。

---

## 6.【中】フォームの案内が「促す」で止まっていて、いちばん重い指標を取りにいけていない

**弱い所**
6章の「進んだ章、環境の違い、止まった所…を送るよう促す」は、作り手向けのメモです。ページに載せる文面になっていません。また、フォームへの道がページの最後に1か所しかありません。

**こう直す**
- 6章の文面：
  > **再現を試した記録を送る**
  > 最後まで進んでいなくてかまいません。止まった所の記録が、次の人の手順になります。
  > 書いてほしいこと：①どこまで進んだか（GPUで推論／お手本を集める／学習／実機）②このページと違う所（アーム・GPU・pymycobot の版・電源）③止まった所、またはエラー ④表の「ログにない」のうち、困った項目
  > → [/message](/message)
- 2章の表で「ログにない」の行が見えたその場から、フォームへ行けるようにします（2章の一文）。
- 判断はエイイチに委ねますが、送られた記録を（送った人の了承のうえで）このページの「再現の記録」欄に載せる案もあります。そうすれば主指標の③をこのページの上で満たせます。

---

## 7.【中】どこから来るかが具体でなく、実際の数字と合っていない

**弱い所**
- /gpu-buy-or-rent は、75%まで読んだ人が10%です。末尾に置いたリンクは、21件のうち2件ほどにしか見えません（計算）。
- AI の利用者の依頼でいちばん多く読まれているのはトップです。その点が、トップにリンクを置く理由として書かれていません。
- 「AIや検索向けの文字起こしで手当て」は、何をするのかが分かりません。

**こう直す**
- /gpu-buy-or-rent：末尾ではなく、50%までは読まれている位置に置きます。具体的には借りる話の段落の直後です。
  > 「借りた A40 で π0.5 を3,000ステップ学習すると、6.2時間・約579円でした（Log#27）。環境と手順はこちら」
- トップ：AI の利用者の依頼で読みに来る数はトップがいちばん多い。だから、トップのリンクの文字は AI が中身を読み取れる名前にします。
  > 「π0.5 を mechArm 270 で追加学習した環境（版・電源・GPU費用）・手順・実機結果」
- ページの見出し：人が AI や検索に聞く形にそろえます。
  - 「A40で何時間、いくらかかったか」
  - 「pymycobot が遅いとき」
  - 「つかんだブロックを落とすとき」
  - 「人の直しなしでどこまで動いたか」

  見出しの直後に、ログの数字と URL を1行で置きます。

---

## 守るべき尖り

**つまずきを「症状 → 原因 → ログ」の形にして、版番号と電源の数字をそのまま前に出していること。**
「pymycobot 4.0.4 → 2.9.6」「12V・2A（24W）→ 12V・5A」のように数字で言い切る作りは、同じ環境から始める人の時間を確実に減らします。ほかの入口ページにはない価値なので、書き直しで「環境に注意」のような一般論に丸めないでください。
```


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

```markdown
【採否】
A1: 一部採る。未記載の明記は採るが、表の形はより簡潔なC2の「状態」列の形にする。
A2: 採る。事実の誤りのためSSDは削り、ゲームパッドは手直しの道具と明記する。
A3: 採る。事実の誤りのため、条件別の結果に分け、合算しない。
A4: 採る。事実の誤りのため、Log#22とLog#32の測定を分けて書く。
A5: 採る。学習と実機の確認を分け、実機へ進むリンクを置く。
A6: 採る。検索・AIからの流入を促すため、問いを見出しにして配置する。
A7: 採る。試そうとした人からの連絡を増やすため、未記載欄と末尾の両方に置く。
A8: 採る。判断基準を明確にするため、30件時点と3か月後の行動を追記する。
C1: 採る。事実の誤りのため、言い過ぎと抜けを正し、電源条件や位置の呼び方の未記載を明記する。
C2: 採る。事実の誤りのSSDを消し、未記載がひと目でわかる表形式にする。
C3: 採る。手順と結果の対応を示すため、学習回ごとの表を追加し、Log#7を見せ場に加える。
C4: 採る。事実の誤りのため、Log#20、#22、#32の数字と単位を正確に書き分ける。
C5: 採る。最初の画面に具体的な数字と落とし穴を入れ、保存する理由を作る。
C6: 採る。フォームの文面を具体化し、表の直後にも案内を置く。
C7: 採る。実際の読了率に合わせてリンク位置を上げ、見出しを人が検索する形にする。

【企画書】

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

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

### この人がこのページで得るもの
π0.5 と mechArm 270 を使った追加学習と実機推論について、同じ環境から始めるために必要な手順、版と数字、足りない情報、そして現在の到達点がわかる見取り図。

### 最初の画面
π0.5 を mechArm 270 で追加学習し、実機で動かす ─ 環境・手順・結果の入口

Runpod で借りた A40 で π0.5 を追加学習し、小型アーム mechArm 270 の実機で動かした記録の入口です。
実機では、3か所に置いたブロックを15回中9回箱に入れました（Log#14）。成功の多くには、人の直しが要りました（Log#18）。
先に知っておくと時間を失わない所：pymycobot の版（4.0.4 では指令1回に1.6秒・Log#20）、電源アダプター（12V・2Aでは落とし、5Aで位置5を5回とも成功・Log#34）。
使った環境の表では、ログに書いていない版や型番を「ログにない」と表示しています。

### 見せ場
再現を左右した版と電源を、具体的な数字で見せていること。指令が遅い原因は pymycobot 4.0.4 であり、2.9.6 に戻すと送信が約0.02秒に改善した事実（Log#20）。ブロックを落とす原因は電源不足であり、12V・5Aに替えると位置5で5回とも成功した事実（Log#34）。
また、**lossが下がっても実機で届くとは限らない事実**。lossを0.0030まで下げても爪は奥で空を閉じ（Log#7）、原因はお手本の浅いつかみだった（Log#23）。これらを先に提示し、同じ環境から始める人が踏む落とし穴を潰す。

### 構成
**1. そろえるものと、ログにない情報（環境表）**
AIが読み取れるよう文字の表で提示し、不足を明示する。
- 書くこと：再現に必要な環境と、ログにない情報の明示。
- 表の形：項目／ログにある値／出どころ／状態（記載あり・未記載）
- 使う事実：mechArm 270（Log#4）、pymycobot 2.9.6（Log#20）、電源12V・5A（Log#34）、RunpodのA40（Log#2・#27）、手直しの道具の互換ゲームパッド（Log#19）。Python・openpi・π0.5の版、Piの型番、ブロックと箱の大きさは「ログにない（未記載）」。
- 導線：表の直後に「この表の『ログにない』を埋められる人、ここで止まった人は、再現を試した記録を送るへ」と置き、末尾のフォーム案内へ飛ばす。

**2. 学習の回ごとの手順と結果**
学習の回ごとの表を置き、手順と結果の対応を1枚で見せる。
- 書くこと：お手本の本数、ステップ数、lossの変化、実機の結果。
- 使う事実：200ステップ（Log#4）、19本・2,000ステップで爪が乗る（Log#5・#6）、19本・4,000ステップで奥で空を閉じる（Log#7）、人が直した5回で1,500ステップ（Log#17）、50本で一から3,000ステップ（Log#27・#28）。
- 次に読む1本：遠隔推論の手順（Log#2）、深くつかむお手本を教え直した記録（Log#26）、50本で一から学習し直した記録（Log#27）、50本モデルの実機結果（Log#28）。

**3. いまの到達点（実機で確かめた範囲）**
条件別に確認できた結果を分け、合算せずに置く。
- 使う事実：3か所に5回ずつ置き、15回中9回箱に入れた（Log#14）。人が直した5回で学び直しても、成功6回はすべて補正つきで、補正なしの1回は根元が約2°足りず空振り（Log#17・#18）。50本モデルで位置1は3回とも直しなしでつかめ、位置2は4回とも届かず、カメラの傾きではない（Log#28・#29）。電源を12V・5Aに替えると位置5で5回とも成功（Log#34）。
- 未記載事項：それぞれの結果がどの電源で出たか。位置C・D・Eと位置1〜5の対応。

**4. 検索・AIから引けるつまずきと数字**
人がAIや検索に聞く形を見出しにし、回答と根拠ログを対応させる。
- 「A40で何時間、いくらかかったか」：3,000ステップに6.2時間・約579円（Log#27）
- 「pymycobot が遅いとき」：4.0.4では1回の指令に1.6秒。2.9.6に戻すと送信は約0.02秒（Log#20）
- 「つかんだブロックを落とすとき」：電源不足。12V・2Aから5Aへ（Log#30・#34）
- 「補正にかかる時間は」：ゲームパッドで直すと1回は中央13秒、キーは41〜51秒（Log#22）。別の計測では中央14.5秒、うち関節を動かすのは2.6秒（Log#32）

**5. 再現を試した記録を送る**
- フォーム案内（/message）：最後まで進んでいなくてかまわないと明記する。
- 書いてほしいこと：①どこまで進んだか ②このページと違う所（アーム・GPU・版・電源）③止まった所、またはエラー ④表の「ログにない」のうち、困った項目。

### 束ねるログ
- Log#2, #3, #4, #5, #6, #7, #9, #10, #11, #12, #14, #17, #18, #19, #20, #22, #23, #25, #26, #27, #28, #29, #30, #32, #34

### 今あるページとのつなぎ方
- トップ：AIが読み取れるよう「π0.5 を mechArm 270 で追加学習した環境（版・電源・GPU費用）・手順・実機結果」としてリンクを置く。
- /gpu-buy-or-rent（GPUは買うか借りるか）：50%までは読まれている「借りる話の段落の直後」に、「借りた A40 で π0.5 を3,000ステップ学習すると、6.2時間・約579円でした（Log#27）。環境と手順はこちら」と置く。
- シリーズ冒頭：「π0.5 と mechArm 270 を始める順に読む。使用環境・手順・実機結果・未記載情報をまとめた入口」として置く。

### 公開後に見る数字
- 人の表示数。30件たまるまでは判断せず、少数の結果から効果を断定しない。
- 30件たまった時点で、ログへ進んだ人の割合を目標の3割と照合する。
- フォームの記録は、試す前の不足と、試した後の停止箇所を読み、環境表・導線の修正に使う。
- AI の利用者の依頼で読みに来た数と、AIのリンクから来た人の数を別に測る。
- 公開3か月で人の表示が30件未満、かつ連絡0件なら、追加の制作を止めてページは残す。

### ゴールにどう効くか
| 見るもの | ゴールに効く理由 | 効かないかもしれない理由 |
|---|---|---|
| このページの人の表示 | トップやLPから具体数字を添えて誘導するため。 | ニッチな題材で絶対数が少ない。→ 検索・AI向けの問いを見出しに置き手当てする。 |
| このページからログへ進んだ人 | 手順ごとに「次に読む1本」を置き、次の作業としてログを開く理由を作るため。 | このページだけで満足する。→ 要約は1行で止め、詳細はログへ送る作りにした。 |
| AI の利用者の依頼で読みに来た数 | 表や到達点を文字にし、数字の横にログURLを置いてAIが引用しやすくするため。 | AIが要約だけで回答を完結させる。→ 手順の詳細は各ログに分散させている。 |
| AI のリンクから、このページに来た人 | AIが「未記載情報」や「つまずきと数字」を含めた際、情報元として踏まれやすいため。 | AIのUI上でリンクが目立たない。→ AIの回答にURLが直接出るよう本文に配置する。 |
| 問い合わせ・相談 | 「止まった所の記録が次の人の手順になる」と明記し、書く内容を指定して敷居を下げるため。 | 再現のハードルが高く試す人が出ない。→ 読むだけでも索引が役立つ構成にした。 |
```


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

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

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

### この人がこのページで得るもの
π0.5 と mechArm 270 を使った追加学習と実機推論について、同じ環境から始めるために必要な手順、版と数字、足りない情報、そして現在の到達点がわかる見取り図。

### 最初の画面
π0.5 を mechArm 270 で追加学習し、実機で動かす ─ 環境・手順・結果の入口

Runpod で借りた A40 で π0.5 を追加学習し、小型アーム mechArm 270 の実機で動かした記録の入口です。
実機では、3か所に置いたブロックを15回中9回箱に入れました（Log#14）。成功の多くには、人の直しが要りました（Log#18）。
先に知っておくと時間を失わない所：pymycobot の版（4.0.4 では指令1回に1.6秒・Log#20）、電源アダプター（12V・2Aでは落とし、5Aで位置5を5回とも成功・Log#34）。
使った環境の表では、ログに書いていない版や型番を「ログにない」と表示しています。

### 見せ場
再現を左右した版と電源を、具体的な数字で見せていること。指令が遅い原因は pymycobot 4.0.4 であり、2.9.6 に戻すと送信が約0.02秒に改善した事実（Log#20）。ブロックを落とす原因は電源不足であり、12V・5Aに替えると位置5で5回とも成功した事実（Log#34）。
また、**lossが下がっても実機で届くとは限らない事実**。lossを0.0030まで下げても爪は奥で空を閉じ（Log#7）、原因はお手本の浅いつかみだった（Log#23）。これらを先に提示し、同じ環境から始める人が踏む落とし穴を潰す。

### 構成
**1. そろえるものと、ログにない情報（環境表）**
AIが読み取れるよう文字の表で提示し、不足を明示する。
- 書くこと：再現に必要な環境と、ログにない情報の明示。
- 表の形：項目／ログにある値／出どころ／状態（記載あり・未記載）
- 使う事実：mechArm 270（Log#4）、pymycobot 2.9.6（Log#20）、電源12V・5A（Log#34）、RunpodのA40（Log#2・#27）、手直しの道具の互換ゲームパッド（Log#19）。Python・openpi・π0.5の版、Piの型番、ブロックと箱の大きさは「ログにない（未記載）」。
- 導線：表の直後に「この表の『ログにない』を埋められる人、ここで止まった人は、再現を試した記録を送るへ」と置き、末尾のフォーム案内へ飛ばす。

**2. 学習の回ごとの手順と結果**
学習の回ごとの表を置き、手順と結果の対応を1枚で見せる。
- 書くこと：お手本の本数、ステップ数、lossの変化、実機の結果。
- 使う事実：200ステップ（Log#4）、19本・2,000ステップで爪が乗る（Log#5・#6）、19本・4,000ステップで奥で空を閉じる（Log#7）、人が直した5回で1,500ステップ（Log#17）、50本で一から3,000ステップ（Log#27・#28）。
- 次に読む1本：遠隔推論の手順（Log#2）、深くつかむお手本を教え直した記録（Log#26）、50本で一から学習し直した記録（Log#27）、50本モデルの実機結果（Log#28）。

**3. いまの到達点（実機で確かめた範囲）**
条件別に確認できた結果を分け、合算せずに置く。
- 使う事実：3か所に5回ずつ置き、15回中9回箱に入れた（Log#14）。人が直した5回で学び直しても、成功6回はすべて補正つきで、補正なしの1回は根元が約2°足りず空振り（Log#17・#18）。50本モデルで位置1は3回とも直しなしでつかめ、位置2は4回とも届かず、カメラの傾きではない（Log#28・#29）。電源を12V・5Aに替えると位置5で5回とも成功（Log#34）。
- 未記載事項：それぞれの結果がどの電源で出たか。位置C・D・Eと位置1〜5の対応。

**4. 検索・AIから引けるつまずきと数字**
人がAIや検索に聞く形を見出しにし、回答と根拠ログを対応させる。
- 「A40で何時間、いくらかかったか」：3,000ステップに6.2時間・約579円（Log#27）
- 「pymycobot が遅いとき」：4.0.4では1回の指令に1.6秒。2.9.6に戻すと送信は約0.02秒（Log#20）
- 「つかんだブロックを落とすとき」：電源不足。12V・2Aから5Aへ（Log#30・#34）
- 「補正にかかる時間は」：ゲームパッドで直すと1回は中央13秒、キーは41〜51秒（Log#22）。別の計測では中央14.5秒、うち関節を動かすのは2.6秒（Log#32）

**5. 再現を試した記録を送る**
- フォーム案内（/message）：最後まで進んでいなくてかまわないと明記する。
- 書いてほしいこと：①どこまで進んだか ②このページと違う所（アーム・GPU・版・電源）③止まった所、またはエラー ④表の「ログにない」のうち、困った項目。

### 束ねるログ
- Log#2, #3, #4, #5, #6, #7, #9, #10, #11, #12, #14, #17, #18, #19, #20, #22, #23, #25, #26, #27, #28, #29, #30, #32, #34

### 今あるページとのつなぎ方
- トップ：AIが読み取れるよう「π0.5 を mechArm 270 で追加学習した環境（版・電源・GPU費用）・手順・実機結果」としてリンクを置く。
- /gpu-buy-or-rent（GPUは買うか借りるか）：50%までは読まれている「借りる話の段落の直後」に、「借りた A40 で π0.5 を3,000ステップ学習すると、6.2時間・約579円でした（Log#27）。環境と手順はこちら」と置く。
- シリーズ冒頭：「π0.5 と mechArm 270 を始める順に読む。使用環境・手順・実機結果・未記載情報をまとめた入口」として置く。

### 公開後に見る数字
- 人の表示数。30件たまるまでは判断せず、少数の結果から効果を断定しない。
- 30件たまった時点で、ログへ進んだ人の割合を目標の3割と照合する。
- フォームの記録は、試す前の不足と、試した後の停止箇所を読み、環境表・導線の修正に使う。
- AI の利用者の依頼で読みに来た数と、AIのリンクから来た人の数を別に測る。
- 公開3か月で人の表示が30件未満、かつ連絡0件なら、追加の制作を止めてページは残す。

### ゴールにどう効くか
| 見るもの | ゴールに効く理由 | 効かないかもしれない理由 |
|---|---|---|
| このページの人の表示 | トップやLPから具体数字を添えて誘導するため。 | ニッチな題材で絶対数が少ない。→ 検索・AI向けの問いを見出しに置き手当てする。 |
| このページからログへ進んだ人 | 手順ごとに「次に読む1本」を置き、次の作業としてログを開く理由を作るため。 | このページだけで満足する。→ 要約は1行で止め、詳細はログへ送る作りにした。 |
| AI の利用者の依頼で読みに来た数 | 表や到達点を文字にし、数字の横にログURLを置いてAIが引用しやすくするため。 | AIが要約だけで回答を完結させる。→ 手順の詳細は各ログに分散させている。 |
| AI のリンクから、このページに来た人 | AIが「未記載情報」や「つまずきと数字」を含めた際、情報元として踏まれやすいため。 | AIのUI上でリンクが目立たない。→ AIの回答にURLが直接出るよう本文に配置する。 |
| 問い合わせ・相談 | 「止まった所の記録が次の人の手順になる」と明記し、書く内容を指定して敷居を下げるため。 | 再現のハードルが高く試す人が出ない。→ 読むだけでも索引が役立つ構成にした。 |
```


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

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

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

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
mechArm 270 と Mac を持っていて、手元に GPU がない日本語の開発者を1人に絞ります。
- **どこから来るか**：ChatGPT か Google で「π0.5 mechArm 追加学習」と調べ、Log#4 のような個々のログに直接たどり着きます。
- **何に困っているか**：1本読んで、次の2つが分からないまま出ていきます。
  - どの版・どの部品で動いたのか
  - どこまで動いたのか

### この人がこのページで得るもの（1文）
次の3つを1枚で確かめ、同じ環境を組み始められます。
- 実際に動いたときの部品と版
- 先につぶす落とし穴
- ログに書いていない所

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**見出し**：π0.5 で mechArm 270 がブロックを箱に入れるまで、効いたのはモデルの外の設定だった

1. 電源を 12V・2A から 5A に替えると、位置5 で5回とも成功した（2A の日は3回中1回）。
2. Pi の pymycobot を 4.0.4 から 2.9.6 に戻すと、1回の指令が1.6秒から約0.02秒になった。
3. 部品・版・手順を34本のログから1枚に集め、ログにない所は「未記載」と書いた。

### 見せ場（このページにしかないもの。ログのどの事実か）
**環境の表**です。1行ごとに「項目・値・出典のログ」を書き、値がない行には「ログにない（未記載）」と書きます。足りない所を隠さないことで、主指標の③（再現に必要な情報が欠けていないことを第三者が確認できる）を、このページだけで確かめられるようにします。

| 項目 | 値 | 出典 |
|---|---|---|
| GPU | Runpod の A40 | Log#2・#4 |
| 推論の速さと費用 | 推論は平均97ms、往復391ms、費用0.34ドル | Log#2 |
| 学習の実費 | 3,000ステップで6.2時間・約579円 | Log#27 |
| GPU の空き待ち | 起動まで約4時間半かかった回がある | Log#10 |
| 電源 | 12V・5A。本体は40W を求めるが、つないでいた 2A は24W | Log#30・#34 |
| Pi の pymycobot | 2.9.6（4.0.4 は遅い） | Log#20 |
| 肩の角度 | 約88°より深い姿勢は、命令がエラーなしに捨てられる | Log#9 |
| ゲームパッド | 3,198円の互換品。ボタン16個・軸6本が読める | Log#19 |
| 学習データの置き場 | 2TB の外付け SSD | SO-101 Log#2 |
| openpi の版・Python・CUDA・カメラの型番 | ログ一覧の要約にはない。本文を確かめ、なければ「未記載」 | — |

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
1. **先に結果：どこまで再現できているか**
   - 実機で15回中9回。位置C は5/5、E は3/5、腕を伸ばしきる D は1/5（Log#14）。
   - お手本50本で学び直したモデルは、位置1 で3回とも直しなしでつかめたが、位置2 は4回とも届かなかった（Log#28）。
   - 電源を5A に替えると、位置5 で5回とも成功した（Log#34）。
   - できていないこと：直しなしで成功し続けるところまでは届いていない（Log#18）。
2. **環境の表**（見せ場）。
3. **手順の順番**：各段に、そのときの loss と回数を添えます。
   1. 借りた GPU で推論を通す（Log#2）
   2. LIBERO で20回中20回成功させる（Log#3）
   3. 手で教えてお手本を録る（Log#8・#9）
   4. 深くつかむお手本に教え直す（Log#25・#26）
   5. 学習する（Log#4 → #5 → #10 → #27）
   6. 実機で動かす（Log#6・#12・#13・#14・#28）
   7. 人が直して学び直す（Log#15〜#18・#22）
4. **先につぶす落とし穴6つ**：
   - 電源の不足（Log#30・#34）
   - pymycobot の版（Log#20）
   - 肩88° を超えた命令がエラーなしに捨てられる（Log#9）
   - お手本の止まっている時間まで覚える（Log#11）
   - 浅いつかみが学習データ30本中7本あった（Log#23）
   - AI に渡す肩の角度を直前の目標にすると、毎回約2° 足りなかった動きが直った（Log#12）
   - あわせて「疑わなくてよかったこと」も書きます。カメラの傾きは原因ではなかった（Log#29・1,770回で確かめた）。
5. **人が直す道具**：
   - ゲームパッドで直すと1回中央14.5秒、キーボードは43.2秒（Log#32）。
   - 長押しと1回押しの送り方（Log#21）。
   - サーボの電流を読む方法。爪が空で閉じると15前後、つかむと870前後（Log#24）。
   - 成否判定を任せる場合。Gemini Decision 1 は56本すべて見分けたが、つかみの深さは見分けられなかった（Log#33）。
6. **ログにない所と、再現を試した記録を送る**：「未記載」の行をここで一覧にし、/message へ送る道を置きます。送ってほしいことは次のとおりです。
   - 使った版
   - どこまで動いたか
   - どこで止まったか

### 束ねるログ（/record/… の一覧）
- **フィジカルAI研究室を作る**：building-a-physical-ai-lab-at-home、openpi-remote-inference-first-run、pi05-libero-benchmark-first-run、pi05-mecharm-demo-to-inference、pi05-mecharm-lora-2000-steps、pi05-mecharm-first-real-run、pi05-mecharm-4000-steps、drag-teach-waypoint-replay、teach-replay-19-demos、pi05-retrain-five-positions、pi05-learned-the-pauses、pi05-first-block-in-box、pi05-all-three-positions、pi05-weak-position-d、rewind-and-correct-pi05、rewind-correct-real-arm、retrain-pi05-with-human-corrections、retrained-pi05-still-needs-human-corrections、gamepad-ready-to-correct-mecharm-270、gamepad-moves-mecharm-270-pymycobot-version、gamepad-correction-mecharm-270-settled、gamepad-fixes-mecharm-270-ai-in-13-seconds、pi05-failures-traced-to-shallow-grasp-demos、reading-mecharm-270-servo-current-for-learning、reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos、even-ten-demos-per-spot-mecharm-270-reteaching、retrain-pi05-from-base-on-50-even-demos、pi05-even-demos-on-arm-misses-position-2、pi05-position-2-miss-caused-by-camera-tilt、mecharm-270-drops-block-underpowered-adapter、measure-mecharm-270-waits-decide-claude-fable-5-2-role、measure-mecharm-270-recovery-time-decide-what-to-cut、gemini-decision-1-judge-mecharm-270-pick-and-place、mecharm-270-5a-adapter-stops-dropping-block
- **SO-101**：where-learning-data-lives（環境の表のデータ置き場の行だけに使う）
- **使わない**：precision-is-not-learning-so101（π0.5 と mechArm 270 の研究ではないため）

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
- **シリーズのページ**：「フィジカルAI研究室を作る」の上の資料欄に、このページへの1行を置きます。
- **/gpu-buy-or-rent**：「A40 を借りて π0.5 を学習した実費」の行から送ります。3,000ステップ・6.2時間・約579円です。
- **トップ**：今ある「シリーズ」の節に、このページの題名だけを足します。新しいキャッチコピーは足しません。
- **AI の答え**：版・型番・数字を本文の文字（表）で書き、AI が引用しやすい形にします。
- **検索**：「mechArm 270 電源」「pymycobot 2.9.6」「π0.5 追加学習 mechArm」で引っかかる語を見出しに入れます。
- **SNS**：LinkedIn に落とし穴6つを投稿します。相談の窓口は出しません。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、流入元（AI のリンク・Google・シリーズ・LP の別）
- 50%まで読んだ割合。表は前半にあるため、表を読んだかの目安にします。
- このページからログへ進んだ人の割合と、進んだ先のログ。どの段の手順が求められているかが分かります。
- AI の利用者の依頼で読みに来た数（ChatGPT-User、Claude-User など）
- /message に届いた再現の記録の件数

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
- **人の表示（3か月で150件）**
  - 効く理由：型番と版の語は、日本語でほかに答えがない検索で拾われやすい（推測）。
  - 効かないかもしれない理由：mechArm 270 を持つ人は少なく、母数が小さい。
- **このページからログへ進んだ人（表示の3割）**
  - 効く理由：表の1行ごとに出典のログがあり、続きはログでしか読めない。
  - 効かないかもしれない理由：表だけで用が済み、ログへ進まない人もいる。
- **AI の依頼で読みに来た数（週3件以上）**
  - 効く理由：AI が1回読めば30本分の答えが取れる形にしている。
  - 効かないかもしれない理由：AI が今は個々のログに散って読みに来ており、このページに寄るまで時間がかかる。
- **AI のリンクから来た人（月1件以上）**
  - 効く理由：出典つきの表は、AI の答えにリンクされやすい（推測）。
  - 効かないかもしれない理由：今はサイト全体でも週1件ほどしかない。
- **問い合わせ・相談（再現を試した人から1〜2件）**
  - 効く理由：「未記載」の行が、試した人に「ここを埋めてほしい」と頼む形になっている。主指標の③にそのまま効く。
  - 効かないかもしれない理由：同じアームを持つ人がそもそも少なく、0件のこともありうる。

---

制作に入る前に、エイイチに確かめてほしいことが1つあります。この企画書は、依頼にあるログの要約だけを根拠に書きました。各ログの本文はまだ読んでいません。そのため次の項目は、本文にあるかどうかを1本ずつ確かめてから、「未記載」にするか決める必要があります。
- openpi の版
- Python・CUDA の版
- カメラの型番
- 学習の設定

確かめずにすべて「未記載」と書くと、実際には本文にある情報まで欠けているように見え、ページの信頼を落とします。
```


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

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

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

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

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

   > **π0.5 を mechArm 270 で追加学習し、実機で動かすための環境・手順・確認できていない所**
   >
   > Mac から Runpod の A40 で推論し、mechArm 270 のお手本で追加学習して実機を動かした記録をまとめました。  
   > 電源を12V・5Aに替えた実験では、位置5で5回ともブロックを箱に入れました（Log#34）。  
   > まず環境の表で手元との差を確かめ、各段の手順とコードがあるログへ進めます。版など、提示された要約では確認できない情報も明示します。

2. **【高】異なる実験の情報を並べただけでは、「同じ環境」の表にならない**

   **弱い所：** 初期の推論費用、50本での学習費用、後期の電源変更が同列です。どれが同時に使われた構成か分かりません。SO-101の外付けSSDも、π0.5研究で実際に使った保存先だとは提示された要約から確認できません。

   **こう直せばもっと強くなる：** 表を「項目／確認できた値／使った段階／出典／同じ環境を組むために残る確認」にします。速度・費用は別の「実測例」へ移します。

   > 電源｜12V・5A｜Log#34の実機実験｜位置5で5回とも成功  
   > Pi側の通信ライブラリ｜pymycobot 2.9.6｜Log#20のゲームパッド操作｜Log#34でも同じ版かは要約では確認できない  
   > 学習データの保存先｜π0.5研究での使用先は要約では確認できない｜SO-101では2TBの外付けSSDを採用

   最後の行は、SO-101の情報を外して「未確認」とする方が、同じ環境を組む目的には明快です。

3. **【高】「不足を見せること」と、主指標③を満たすことが混同されている**

   **弱い所：** 未記載を並べても、「再現に必要な情報が欠けていない」と第三者が確認できる状態にはなりません。また、本文確認が必要だと分かっているのに、その作業を最後にエイイチへ返しています。ここが企画の成立条件です。

   **こう直せばもっと強くなる：** 制作工程と判定を、次の文に置き換えます。

   > 制作時に、環境・手順の各項目をログ本文と付属コードで照合する。要約にない段階では「要約では確認できない」、本文・付属コードにもなければ「ログにない（未記載）」と記す。  
   > 必要情報の不足が残る間は、主指標の達成とは数えない。第三者が不足の有無を確認できるよう、確認対象と出典を公開する。

   エイイチへの確認事項は、照合後にも解決しない項目に絞れます。

4. **【高】「手順の順番」が、過去の試行をすべて追体験させる構成になっている**

   **弱い所：** LIBEROの検証、初期のお手本、複数回の学習、人の補正が一本道です。読者には、全部が必要な工程に見えます。各段のlossを並べても、次に何をするかの判断にはつながりません。

   **こう直せばもっと強くなる：** 「始めるために参照する順番」と「経緯を調べるログ」を分けます。

   > **始めるために参照する順番**  
   > ① 遠隔推論の接続を確かめる → Log#2  
   > ② 電源・通信の版・動作範囲を確認する → Log#34・#20・#9  
   > ③ 深くつかむお手本をそろえる → Log#25・#26  
   > ④ 50本で一から追加学習した設定を確認する → Log#27  
   > ⑤ 実機で試し、記録された結果と照合する → Log#28・#34  
   >
   > LIBEROの検証と初期の学習条件は、別枠の「ここまでの検証経緯」から読めます。

   これはログの参照順です。工程間の接続に必要な情報は本文照合で確かめ、未確認のまま完成した手順とは呼ばないでください。

5. **【高】異なる条件の結果と、原因についての結論を広く言いすぎている**

   **弱い所：** 「どこまで再現できているか」に研究者本人の実験結果が並び、第三者による再現と区別できません。「直しなしで成功し続けるところまでは届いていない」を古いLog#18だけで現在の結論にするのも不適切です。「カメラの傾きは疑わなくてよい」も、別の環境に広げられません。

   **こう直せばもっと強くなる：** 節名を「この研究で確認した到達点」にし、条件ごとに書きます。

   > Log#28：50本で学習したモデルは、位置1で3回とも補正なしでつかめた。位置2では4回ともつかむ姿勢まで届かなかった。  
   > Log#34：12V・5Aへの交換後、位置5では5回とも箱入れに成功した。ほかの位置も含む安定性は、この結果だけでは判断できない。  
   > 第三者による再現記録：提示されたログ一覧では確認できない。

   カメラの項目も、次に限定します。

   > この位置2の問題では、録画画像の傾きだけを変えて1,770回推論しても行き先は入れ替わらず、上カメラの傾きは原因ではなかった（Log#29）。

6. **【高】想定読者は個別ログへ到着するのに、そこから入口ページへ来る道がない**

   **弱い所：** 読者像は「Log#4へ直接来る人」ですが、ログは変更できません。その人が自然にこのページを見つける前提では、流入設計が成立しません。SNSも「落とし穴6つ」の投稿だけでは、入口へのリンクと読む理由が曖昧です。

   **こう直せばもっと強くなる：** 入口へ直接来る経路を、掲載文まで決めます。

   > シリーズの資料欄：  
   > 「π0.5 × mechArm 270を始める：環境・版・手順の一覧」→ 本ページ  
   >
   > /gpu-buy-or-rent の該当箇所：  
   > 「A40で3,000ステップ、6.2時間・約579円だった実験の環境と手順を見る」→ 本ページ  
   >
   > SNS：  
   > 「π0.5をmechArm 270で追加学習し、実機で動かした環境・手順・未確認項目を1ページにまとめました」→ 本ページ

   検索とAIへの説明でも、「版・手順・不足をまとめたページ」と明示します。検索需要やAIからの引用効果は、現時点では推測として扱います。

7. **【高】いちばん重い「試した人・試そうとした人からの連絡」が、最下部の報告依頼に限られている**

   **弱い所：** 「再現を試した記録を送る」では、まだ始められない人が対象外に見えます。また、最初から版・結果・停止箇所を全部求めると、必要な情報が欠けて止まった人ほど送りにくくなります。

   **こう直せばもっと強くなる：** 環境の表の直後と末尾に、同じフォームへの道を置きます。

   > **同じ環境を組もうとして、足りない情報がありましたか**  
   > 試す前でも、途中で止まった段階でも送れます。  
   > 「試そうとしていること」「分からない項目、または止まった段階」を、分かる範囲で書いてください。使った版や参照したログもあれば添えてください。  
   > **再現を試した・試そうとした記録を送る** → /message

   「未記載を埋めてもらう」より、「始めるのを妨げている不足を見つける」依頼にすると、ゴールと直結します。

8. **【中】測る項目はあるが、判断条件と改善する場所が決まっていない**

   **弱い所：** 「50%読んだ」を表の閲覧とみなすのは粗く、ログへの移動も、出典確認なのか手順を始めるためなのか区別できません。依頼にある中止条件も抜けています。

   **こう直せばもっと強くなる：** 次の判断文を足します。

   > 人の表示が30件たまった時点で最初の判断をする。ログへ進んだ人の割合は、人単位で数える。  
   > 「手順・コードを開く」と「結果の出典を確かめる」のリンクを区別し、どの段階へ進んだかを見る。  
   > ログへの移動が目標の3割に届かなければ、環境の表と手順の案内を見直す。連絡では「試す前／試した後」と、始めるのを妨げた情報を確認する。  
   > 公開から3か月で人の表示が30件未満、連絡も0件なら、追加の手間をかけるのをやめ、ページは残す。

**守るべき尖り：** 「分かっている環境だけでなく、同じ環境を組むために足りない情報も、出典つきで見せる」ことです。ここを消さず、研究のまとめから、第三者が自分の環境との差を点検できるページへ押し切ってください。
```


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

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

---

### 【高】最初の画面：失敗解決の読み物ではなく「始める入口」にする
**弱い所**
最初の画面の見出し（効いたのはモデルの外の設定だった）と3行が、トラブルシューティングの読み物のようになっており、依頼の「失敗の読み物ではなく、始めるための入口にする」から外れています。これでは、これから環境を組もうとする人が「自分のための手順書だ」と認識できず離脱してしまいます。

**こう直せばもっと強くなる**
見出しを「これから始める人」に向けた全体像にし、3行で「何がどこまでできるか」を示します。
> **見出し**：Mac と mechArm 270 から A40 を借り、π0.5 を追加学習して実機で動かす環境と手順
> 1. 借りた GPU での推論から、実機でブロックを箱に入れるまでの手順と環境を1枚にまとめた。
> 2. 実機で15回中9回成功（位置Cは5/5）した時点の部品・版を記載し、ログにない所は「未記載」とした。
> 3. 実機特有の落とし穴（電源不足や pymycobot の版による遅延）と対処法を先回りして書いた。

### 【高】見せ場の「環境の表」：AI が迷わないよう「環境」と「結果」を分ける
**弱い所**
表の中に「推論の速さと費用」「学習の実費」「GPUの空き待ち」が混ざっています。これらは「環境（部品・版）」ではなく「実行時の目安（結果）」です。これらが混ざると、AI が「必要な環境を教えて」という依頼に対してノイズを拾いやすくなり、AI経由の流入ゴールに悪影響が出ます。

**こう直せばもっと強くなる**
表を「ハードウェア・ソフトウェアの環境」に純化し、費用や時間は表の下に別枠で書きます。
> **環境・依存関係の表**
> （GPU、電源、pymycobot、ゲームパッド、SSD、未記載項目のみで表を作る）
> 
> **実行の目安（実績）**
> - **推論の速さと費用**：平均97ms、往復391ms、費用0.34ドル（Log#2）
> - **学習の実費**：3,000ステップで6.2時間・約579円（Log#27）
> - **GPU の空き待ち**：起動まで約4時間半かかった回がある（Log#10）

### 【中】手順の順番：AI と人が抜き出しやすい「行動のステップ」で書く
**弱い所**
「3. 手順の順番」が「1. 借りた GPU で推論を通す（Log#2）」のように箇条書きされていますが、ログの羅列感が強く、読者が「自分の手元でどう動かせばいいか」の時系列を掴みにくいです。AI も手順として構造化しづらくなります。

**こう直せばもっと強くなる**
各段落を「行動のステップ」として明確に書き、そこに実績と出典を添えます。
> **手順のステップ**
> - **Step 1：借りた GPU で推論を通す**（推論平均97ms / Log#2）
> - **Step 2：シミュレータで確認する**（LIBERO で20回中20回成功 / Log#3）
> - **Step 3：手で教え、お手本を録る**（深くつかむお手本へ教え直し、5か所10本ずつ / Log#8, #25, #26, #479）
> - **Step 4：π0.5 を学習する**（3,000ステップ学習し、loss 0.1015 → 0.0036 / Log#27）
> - **Step 5：実機で動かす**（位置1 は3回とも成功、位置2 は4回とも届かず / Log#28）
> - **Step 6：人が直して学び直す**（失敗をゲームパッドで直し、学習データを作り直す / Log#15〜#18, #22）

### 【高】落とし穴の断定：ログの範囲に留め、推測は推測と書く（事実の誤り）
**弱い所**
「電源の不足」について、ログ#30では「原因とみられる」と書かれているのに、企画書では「本体は40Wを求めるが〜」と断定しています。また「疑わなくてよかったこと：カメラの傾きは原因ではなかった」と一般化していますが、ログ#29では「位置2を外した理由」に限定されています。エイイチのルール（ログにない事実を作らない、推測は推測と書く）に反します。

**こう直せばもっと強くなる**
ログの事実と推測を正確に切り分けて書きます。
> - **電源の不足（推測）**：ブロックを落とす原因は電源の不足とみられる。12V・2Aから5Aに替えると、位置5で5回とも成功した（Log#30・#34）
> - **疑わなくてよかったこと**：位置2 を外した理由は、上カメラの傾きではなかった（録画の画像の傾きだけを変えて1,770回答えさせた結果 / Log#29）

### 【中】問い合わせへの導線：主指標を共有し、当事者意識を持たせる
**弱い所**
「未記載の行をここで一覧にし、/message へ送る道を置きます」だけでは、読者がわざわざ自分の記録を送る動機が弱いです。ゴールである「再現を試した人から1〜2件」を確実に獲るには、なぜその情報が欲しいのか（主指標のため）をストレートに伝える必要があります。

**こう直せばもっと強くなる**
読者に「あなたの記録が、この研究を完成させる」と伝わる文面にします。
> **ログにない所と、あなたの環境での記録を教えてください**
> この研究が「誰でも再現できる」状態になるには、自分以外の環境で動いた記録が1件必要です。以下の「未記載」の項目を含め、あなたの Mac と mechArm 270 で試した結果を /message から教えてください。途中で止まった記録でも構いません。
> - 使った openpi・Python・CUDA の版、カメラの型番、学習の設定
> - どこまで動いたか / どこで止まったか

### 【低】検索キーワード：ページ名に必要な語を自然に組み込む
**弱い所**
検索流入を狙うとして「pymycobot 2.9.6」「追加学習」を挙げていますが、ページ名の案（π0.5 を mechArm 270 で動かす環境一覧：部品・版・手順と、ログにない所）にそれらの語が入っていません。これでは Google 検索からの流入（表示150件のゴール）を取りこぼします。

**こう直せばもっと強くなる**
ページ名と URL に、ターゲットが検索する語を自然に組み込みます。
> **ページの名前と URL の案**
> π0.5 を mechArm 270 で追加学習して動かす環境一覧：部品・手順とログにない所（pymycobot 2.9.6 等）
> URL：/pi05-mecharm-270-finetune-start

---

### 守るべき尖り（いちばん良い所）
**「未記載（ログにない所）」をあえて一覧にして見せ、読者に協力を求める構造**です。
足りない情報を隠して「完璧なページ」を装うのではなく、欠けていることをページ自体の機能（問い合わせへの強力なフック）に変換している点が素晴らしいです。これは主指標の③（再現に必要な情報が欠けているか第三者が確認できる）を完璧に満たします。書き直しの際も、この「未記載を晒す」という骨格は絶対に消さないでください。
```


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

```markdown
【採否】

**評者（案A）から**
1. 最初の画面（一部採る）：見出しを「始める入口」に変えます。ただ、「要約では確認できない」のような作る側の言葉は画面に出しません。3行では、ログにある到達点を2つ、いちばん強く言います。
2. 表で別々の実験の値を同じ列に並べている（採る）：表に「確かめた場面」と「残る確認」の列を足します。速さと費用は表から外し、別枠に移します。SO-101 の SSD の行は外し、照合する項目に回します。
3. 主指標③との取り違え（採る）：本文と付属コードとの照合を、制作の工程に入れます。「未記載」が残っている間は、主指標を満たしたと数えません。
4. 手順を全部たどらせる作りになっている（採る）：「始めるために読む順番」と「経緯」を分けます。loss の数字は外します。
5. 結果と原因の言い過ぎ（採る・事実の誤り）：カメラの話は位置2の件だけに限ります。Log#18 だけを根拠にした結論は取り下げます。第三者による再現は「まだない」と書きます。
6. ページへ来る道がない（採る）：シリーズのページ、LP、SNS に置く文を決めます。
7. 連絡の窓口が報告の依頼だけになっている（採る）：試す前の人や、途中で止まった人も送れるようにします。窓口は表の直後と末尾の2か所に置きます。
8. 判断の条件（採る）：やめる条件と、リンクを種類ごとに分けて測ることを足します。

**評者（案B）から**
1. 最初の画面（一部採る）：入口の見出しにすることは採ります。「15回中9回」を今の部品・版と並べる案は採りません。Log#14 は電源を替える前で、お手本も19本のモデルなので、条件が違います。
2. 環境と結果を分ける（採る）：A の2と同じ直しです。
3. 手順をステップで書く（一部採る）：動作を表す言葉で書くことは採ります。ただ、全部をステップにすると過去の試行をなぞることになるので、A の4の分け方を優先します。なお「Log#479」はログの番号ではなく、一覧の番号です。
4. 落とし穴での言い切り（一部採る）：カメラの話を限ることは採ります。電源を「推測」と書く案は採りません。Log#34 に「原因は電源の不足だった」とあるので、その言い方で書きます。
5. 連絡を頼む理由を書く（一部採る）：「自分以外の環境での記録が1件要る」と書くことは採ります。「あなたの記録が研究を完成させる」は言い過ぎなので採りません。
6. 名前に検索語を入れる（一部採る）：「追加学習」は名前に入れます。「pymycobot 2.9.6」は入れません。Log#34 の日に使っていた版を確かめられていないので、名前で言い切れません。

---

【企画書】

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

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
mechArm 270 と Mac を持っていて、手元に GPU がない日本語の開発者を1人に絞ります。
- **どこから来るか**：今は Google や ChatGPT から Log#4 のような個々のログに着き、1本読んで出ていきます。ログは変えられないので、このページへは次の道から直接来てもらいます。
  - AI の答え
  - 「mechArm 270 電源」「π0.5 追加学習」で調べた検索
  - シリーズのページの資料欄
  - /gpu-buy-or-rent
  - LinkedIn
- **何に困っているか**：どの部品・どの版で、どこまで動いたのか、自分の手元と何が違うのかが、ログ1本では分かりません。

### この人がこのページで得るもの（1文）
自分の手元との違いを1枚で確かめて、どのログから始めるかを決められます。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**見出し**：π0.5 を mechArm 270 で追加学習し、実機で動かす：環境・手順・ログにない所

1. Mac から Runpod の A40 を借りて π0.5 を追加学習し、mechArm 270 でブロックを箱に入れるまでの記録34本を、1枚に束ねました。
2. 深くつかむお手本50本で学んだモデルは、位置1で3回とも直しなしでブロックをつかみました（Log#28）。電源を12V・5A に替えた日は、位置5で5回とも箱に入れました（Log#34）。
3. 部品と版には1行ずつ出典のログを付け、ログにない所は「未記載」と書いています。

### 見せ場（このページにしかないもの。ログのどの事実か）
**環境の表**です。どの値がどの場面で確かめられたものかを、行ごとに示します。値がない行は、空けずに「ログにない（未記載）」と書きます。

| 項目 | 値 | 確かめた場面 | 残る確認 |
|---|---|---|---|
| GPU | Runpod の A40 | 推論（Log#2）、学習（Log#4・#27） | — |
| 電源 | 12V・5A。本体は40W を求め、2A では24W | 実機（Log#30・#34） | — |
| Pi の pymycobot | 2.9.6。4.0.4 では1回の指令に1.6秒かかった | ゲームパッドの操作（Log#20） | Log#34 の日も同じ版か |
| 肩の範囲 | 約88°より深く倒すと、命令がエラーなしに捨てられる | お手本を録るとき（Log#9） | — |
| お手本 | 深くつかむお手本を5か所×10本 | Log#26・#27 | — |
| 直す道具 | 3,198円の互換ゲームパッド | Log#19・#21 | 型番 |
| openpi・Python・CUDA の版、カメラ、学習の設定、データの置き場 | 制作時に照合する | — | 本文になければ「未記載」 |

**表の下に置く「実測の例」**
- 推論：平均97ms、往復391ms、費用0.34ドル（Log#2）
- 学習：3,000ステップで6.2時間・約579円（Log#27）
- GPU の空き待ち：起動まで約4時間半かかった回がある（Log#10）

**制作の決まり**
- 表の各項目を、ログの本文と付属のコードで1本ずつ照合します。
- 本文にもなければ「ログにない（未記載）」と書きます。
- 「未記載」が残っている間は、主指標を満たしたとは数えません。ページにもそう書きます。

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
1. **この研究で確かめた到達点**：条件ごとに分けて書きます。
   - 50本で学んだモデル：位置1は3回とも直しなしでつかめた。位置2は4回とも、つかむ姿勢まで届かなかった（Log#28）。
   - 電源を5A に替えた日：位置5で5回とも成功した。ほかの位置まで安定しているかは、この結果だけでは判断できない（Log#34）。
   - 第三者による再現：まだ記録がない。
2. **環境の表と実測の例**：表の直後に、節6と同じフォームへの短い導線を置きます。
3. **始めるために読む順番**
   1. 遠隔で推論できるか確かめる（Log#2）
   2. 電源・版・肩の範囲を確かめる（Log#34・#20・#9）
   3. 深くつかむお手本をそろえる（Log#25・#26）
   4. 50本で一から学習する（Log#27）
   5. 実機で試し、記録された結果と比べる（Log#28・#34）

   段と段のつなぎ目は照合が済むまで確かめられていないため、この節は「手順」とは呼ばず、「読む順番」とします。
4. **先につぶす落とし穴**
   - ブロックを落とす原因は電源の不足だった（Log#30・#34）。
   - pymycobot の版で、1回の指令が1.6秒から約0.02秒に変わった（Log#20）。
   - 肩を約88°より深く倒すと、命令がエラーなしに捨てられる（Log#9）。
   - π0.5 はお手本の中の止まっている時間まで覚える（Log#11）。
   - 学習データ30本中7本が浅いつかみだった（Log#23）。
   - AI に渡す肩の角度を直前の目標に変えると、毎回約2°足りずに箱に当てていた動きが直った（Log#12）。
   - 位置2で外れたのは、上カメラの傾きのせいではなかった。録画の画像の傾きだけを変えて1,770回答えさせても、行き先は入れ替わらなかった（Log#29）。ただし、これは位置2の件に限った結果です。
5. **人が直す道具と、ここまでの経緯**
   - 人が直す1回にかかった時間：ゲームパッドで中央14.5秒、キーボードで43.2秒（Log#32）
   - サーボの電流：爪が空で閉じると15前後、ブロックをつかむと870前後（Log#24）
   - 成否の判定：Gemini Decision 1 は56本すべての成否を見分けたが、つかみの深さは見分けられなかった（Log#33）
   - 経緯
     - LIBERO で20回中20回成功（Log#3）
     - 学習（Log#4→#5→#7→#10）
     - 実機（Log#6・#13・#14）
     - 人の直し（Log#15〜#18・#22）。学び直したあとも、成功した6回はすべて人の補正つきだった（Log#18）
6. **同じ環境を組もうとして、足りない情報がありましたか**
   - 試す前でも、途中で止まった段階でも送れます。
   - 書いてほしいこと：試そうとしていること、分からない項目または止まった段階。分かる範囲で構いません。
   - 頼む理由：「誰でも同じ環境から始められる」と言うには、自分以外の環境での記録が1件要ります。
   - 送り先：「再現を試した・試そうとした記録を送る」→ /message

### 束ねるログ（/record/… の一覧）
フィジカルAI研究室を作る Log#1〜#34 の全34本です（どれも /record/ の下）。
- Log#1〜#9：building-a-physical-ai-lab-at-home、openpi-remote-inference-first-run、pi05-libero-benchmark-first-run、pi05-mecharm-demo-to-inference、pi05-mecharm-lora-2000-steps、pi05-mecharm-first-real-run、pi05-mecharm-4000-steps、drag-teach-waypoint-replay、teach-replay-19-demos
- Log#10〜#18：pi05-retrain-five-positions、pi05-learned-the-pauses、pi05-first-block-in-box、pi05-all-three-positions、pi05-weak-position-d、rewind-and-correct-pi05、rewind-correct-real-arm、retrain-pi05-with-human-corrections、retrained-pi05-still-needs-human-corrections
- Log#19〜#34：gamepad-ready-to-correct-mecharm-270、gamepad-moves-mecharm-270-pymycobot-version、gamepad-correction-mecharm-270-settled、gamepad-fixes-mecharm-270-ai-in-13-seconds、pi05-failures-traced-to-shallow-grasp-demos、reading-mecharm-270-servo-current-for-learning、reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos、even-ten-demos-per-spot-mecharm-270-reteaching、retrain-pi05-from-base-on-50-even-demos、pi05-even-demos-on-arm-misses-position-2、pi05-position-2-miss-caused-by-camera-tilt、mecharm-270-drops-block-underpowered-adapter、measure-mecharm-270-waits-decide-claude-fable-5-2-role、measure-mecharm-270-recovery-time-decide-what-to-cut、gemini-decision-1-judge-mecharm-270-pick-and-place、mecharm-270-5a-adapter-stops-dropping-block

SO-101 の2本は使いません。

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
- **シリーズのページの資料欄**：「π0.5 × mechArm 270 を始める：環境・版・手順の一覧」
- **/gpu-buy-or-rent の実費の箇所**：「A40で3,000ステップ・6.2時間・約579円だった実験の環境と手順を見る」
- **トップ**：シリーズの節に題名だけを足します。
- **LinkedIn**：「π0.5 を mechArm 270 で追加学習し、実機で動かした環境・手順・ログにない所を1ページにまとめました」。相談の窓口は出しません。
- **AI と検索**：版・型番・数字を本文の文字で書きます。拾われやすさの効果は推測です。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、どこから来たか
- ログへ進んだ人の割合（人単位で数える）。リンクは「読む順番から開いた」と「出典を確かめた」を分けて数えます。
- 3割に届かなければ、表と「読む順番」を見直します。
- 連絡が来たら、「試す前か、試した後か」と、始めるのを妨げた情報を見ます。
- 3か月で表示が30件未満で、連絡も0件なら、追加の手間をかけるのをやめます。ページは残します。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
- **人の表示（3か月で150件）**
  - 効く理由：シリーズ・LP・SNS から直接来る道ができる。
  - 効かないかもしれない理由：mechArm 270 を持つ人は少なく、もとの母数が小さい。
- **ログへ進んだ人（表示の3割）**
  - 効く理由：表の行ごとに出典のログがあり、コードはログにしかない。
  - 効かないかもしれない理由：表だけで用が済む人もいる。
- **AI の依頼で読みに来た数（このページだけで週3件以上）**
  - 効く理由：1回読めば34本分の要点が取れる（推測）。
  - 効かないかもしれない理由：今は AI の読みに来る先が個々のログに散っている。
- **AI のリンクから来た人（月1件以上）**
  - 効く理由：出典つきの表は答えの中で引用されやすい（推測）。
  - 効かないかもしれない理由：今はサイト全体でも週1件ほどしかない。
- **問い合わせ・相談（再現を試した人・試そうとした人から1〜2件）**
  - 効く理由：試す前の人でも、足りない情報を送れる。
  - 効かないかもしれない理由：同じアームを持つ人が少なく、0件もありうる。

---

**エイイチへ**：表の照合は、制作の工程に入れました。照合を終えても埋まらない項目だけ、あとで確かめてもらいます。
```


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

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

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
mechArm 270 と Mac を持っていて、手元に GPU がない日本語の開発者を1人に絞ります。
- **どこから来るか**：今は Google や ChatGPT から Log#4 のような個々のログに着き、1本読んで出ていきます。ログは変えられないので、このページへは次の道から直接来てもらいます。
  - AI の答え
  - 「mechArm 270 電源」「π0.5 追加学習」で調べた検索
  - シリーズのページの資料欄
  - /gpu-buy-or-rent
  - LinkedIn
- **何に困っているか**：どの部品・どの版で、どこまで動いたのか、自分の手元と何が違うのかが、ログ1本では分かりません。

### この人がこのページで得るもの（1文）
自分の手元との違いを1枚で確かめて、どのログから始めるかを決められます。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**見出し**：π0.5 を mechArm 270 で追加学習し、実機で動かす：環境・手順・ログにない所

1. Mac から Runpod の A40 を借りて π0.5 を追加学習し、mechArm 270 でブロックを箱に入れるまでの記録34本を、1枚に束ねました。
2. 深くつかむお手本50本で学んだモデルは、位置1で3回とも直しなしでブロックをつかみました（Log#28）。電源を12V・5A に替えた日は、位置5で5回とも箱に入れました（Log#34）。
3. 部品と版には1行ずつ出典のログを付け、ログにない所は「未記載」と書いています。

### 見せ場（このページにしかないもの。ログのどの事実か）
**環境の表**です。どの値がどの場面で確かめられたものかを、行ごとに示します。値がない行は、空けずに「ログにない（未記載）」と書きます。

| 項目 | 値 | 確かめた場面 | 残る確認 |
|---|---|---|---|
| GPU | Runpod の A40 | 推論（Log#2）、学習（Log#4・#27） | — |
| 電源 | 12V・5A。本体は40W を求め、2A では24W | 実機（Log#30・#34） | — |
| Pi の pymycobot | 2.9.6。4.0.4 では1回の指令に1.6秒かかった | ゲームパッドの操作（Log#20） | Log#34 の日も同じ版か |
| 肩の範囲 | 約88°より深く倒すと、命令がエラーなしに捨てられる | お手本を録るとき（Log#9） | — |
| お手本 | 深くつかむお手本を5か所×10本 | Log#26・#27 | — |
| 直す道具 | 3,198円の互換ゲームパッド | Log#19・#21 | 型番 |
| openpi・Python・CUDA の版、カメラ、学習の設定、データの置き場 | 制作時に照合する | — | 本文になければ「未記載」 |

**表の下に置く「実測の例」**
- 推論：平均97ms、往復391ms、費用0.34ドル（Log#2）
- 学習：3,000ステップで6.2時間・約579円（Log#27）
- GPU の空き待ち：起動まで約4時間半かかった回がある（Log#10）

**制作の決まり**
- 表の各項目を、ログの本文と付属のコードで1本ずつ照合します。
- 本文にもなければ「ログにない（未記載）」と書きます。
- 「未記載」が残っている間は、主指標を満たしたとは数えません。ページにもそう書きます。

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
1. **この研究で確かめた到達点**：条件ごとに分けて書きます。
   - 50本で学んだモデル：位置1は3回とも直しなしでつかめた。位置2は4回とも、つかむ姿勢まで届かなかった（Log#28）。
   - 電源を5A に替えた日：位置5で5回とも成功した。ほかの位置まで安定しているかは、この結果だけでは判断できない（Log#34）。
   - 第三者による再現：まだ記録がない。
2. **環境の表と実測の例**：表の直後に、節6と同じフォームへの短い導線を置きます。
3. **始めるために読む順番**
   1. 遠隔で推論できるか確かめる（Log#2）
   2. 電源・版・肩の範囲を確かめる（Log#34・#20・#9）
   3. 深くつかむお手本をそろえる（Log#25・#26）
   4. 50本で一から学習する（Log#27）
   5. 実機で試し、記録された結果と比べる（Log#28・#34）

   段と段のつなぎ目は照合が済むまで確かめられていないため、この節は「手順」とは呼ばず、「読む順番」とします。
4. **先につぶす落とし穴**
   - ブロックを落とす原因は電源の不足だった（Log#30・#34）。
   - pymycobot の版で、1回の指令が1.6秒から約0.02秒に変わった（Log#20）。
   - 肩を約88°より深く倒すと、命令がエラーなしに捨てられる（Log#9）。
   - π0.5 はお手本の中の止まっている時間まで覚える（Log#11）。
   - 学習データ30本中7本が浅いつかみだった（Log#23）。
   - AI に渡す肩の角度を直前の目標に変えると、毎回約2°足りずに箱に当てていた動きが直った（Log#12）。
   - 位置2で外れたのは、上カメラの傾きのせいではなかった。録画の画像の傾きだけを変えて1,770回答えさせても、行き先は入れ替わらなかった（Log#29）。ただし、これは位置2の件に限った結果です。
5. **人が直す道具と、ここまでの経緯**
   - 人が直す1回にかかった時間：ゲームパッドで中央14.5秒、キーボードで43.2秒（Log#32）
   - サーボの電流：爪が空で閉じると15前後、ブロックをつかむと870前後（Log#24）
   - 成否の判定：Gemini Decision 1 は56本すべての成否を見分けたが、つかみの深さは見分けられなかった（Log#33）
   - 経緯
     - LIBERO で20回中20回成功（Log#3）
     - 学習（Log#4→#5→#7→#10）
     - 実機（Log#6・#13・#14）
     - 人の直し（Log#15〜#18・#22）。学び直したあとも、成功した6回はすべて人の補正つきだった（Log#18）
6. **同じ環境を組もうとして、足りない情報がありましたか**
   - 試す前でも、途中で止まった段階でも送れます。
   - 書いてほしいこと：試そうとしていること、分からない項目または止まった段階。分かる範囲で構いません。
   - 頼む理由：「誰でも同じ環境から始められる」と言うには、自分以外の環境での記録が1件要ります。
   - 送り先：「再現を試した・試そうとした記録を送る」→ /message

### 束ねるログ（/record/… の一覧）
フィジカルAI研究室を作る Log#1〜#34 の全34本です（どれも /record/ の下）。
- Log#1〜#9：building-a-physical-ai-lab-at-home、openpi-remote-inference-first-run、pi05-libero-benchmark-first-run、pi05-mecharm-demo-to-inference、pi05-mecharm-lora-2000-steps、pi05-mecharm-first-real-run、pi05-mecharm-4000-steps、drag-teach-waypoint-replay、teach-replay-19-demos
- Log#10〜#18：pi05-retrain-five-positions、pi05-learned-the-pauses、pi05-first-block-in-box、pi05-all-three-positions、pi05-weak-position-d、rewind-and-correct-pi05、rewind-correct-real-arm、retrain-pi05-with-human-corrections、retrained-pi05-still-needs-human-corrections
- Log#19〜#34：gamepad-ready-to-correct-mecharm-270、gamepad-moves-mecharm-270-pymycobot-version、gamepad-correction-mecharm-270-settled、gamepad-fixes-mecharm-270-ai-in-13-seconds、pi05-failures-traced-to-shallow-grasp-demos、reading-mecharm-270-servo-current-for-learning、reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos、even-ten-demos-per-spot-mecharm-270-reteaching、retrain-pi05-from-base-on-50-even-demos、pi05-even-demos-on-arm-misses-position-2、pi05-position-2-miss-caused-by-camera-tilt、mecharm-270-drops-block-underpowered-adapter、measure-mecharm-270-waits-decide-claude-fable-5-2-role、measure-mecharm-270-recovery-time-decide-what-to-cut、gemini-decision-1-judge-mecharm-270-pick-and-place、mecharm-270-5a-adapter-stops-dropping-block

SO-101 の2本は使いません。

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
- **シリーズのページの資料欄**：「π0.5 × mechArm 270 を始める：環境・版・手順の一覧」
- **/gpu-buy-or-rent の実費の箇所**：「A40で3,000ステップ・6.2時間・約579円だった実験の環境と手順を見る」
- **トップ**：シリーズの節に題名だけを足します。
- **LinkedIn**：「π0.5 を mechArm 270 で追加学習し、実機で動かした環境・手順・ログにない所を1ページにまとめました」。相談の窓口は出しません。
- **AI と検索**：版・型番・数字を本文の文字で書きます。拾われやすさの効果は推測です。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、どこから来たか
- ログへ進んだ人の割合（人単位で数える）。リンクは「読む順番から開いた」と「出典を確かめた」を分けて数えます。
- 3割に届かなければ、表と「読む順番」を見直します。
- 連絡が来たら、「試す前か、試した後か」と、始めるのを妨げた情報を見ます。
- 3か月で表示が30件未満で、連絡も0件なら、追加の手間をかけるのをやめます。ページは残します。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
- **人の表示（3か月で150件）**
  - 効く理由：シリーズ・LP・SNS から直接来る道ができる。
  - 効かないかもしれない理由：mechArm 270 を持つ人は少なく、もとの母数が小さい。
- **ログへ進んだ人（表示の3割）**
  - 効く理由：表の行ごとに出典のログがあり、コードはログにしかない。
  - 効かないかもしれない理由：表だけで用が済む人もいる。
- **AI の依頼で読みに来た数（このページだけで週3件以上）**
  - 効く理由：1回読めば34本分の要点が取れる（推測）。
  - 効かないかもしれない理由：今は AI の読みに来る先が個々のログに散っている。
- **AI のリンクから来た人（月1件以上）**
  - 効く理由：出典つきの表は答えの中で引用されやすい（推測）。
  - 効かないかもしれない理由：今はサイト全体でも週1件ほどしかない。
- **問い合わせ・相談（再現を試した人・試そうとした人から1〜2件）**
  - 効く理由：試す前の人でも、足りない情報を送れる。
  - 効かないかもしれない理由：同じアームを持つ人が少なく、0件もありうる。

---

**エイイチへ**：表の照合は、制作の工程に入れました。照合を終えても埋まらない項目だけ、あとで確かめてもらいます。
```


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

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

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

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

**こう直せばもっと強くなる**  
節3を「始めるまでの手順と、まだつながっていない所」に変え、各段に「用意するもの／操作が載るログ／次へ進める確認／未記載」を置きます。接続を確認できない段も、その場で示します。

> **お手本を学習に渡す**  
> Log#4には、お手本2本で追加学習し、Macで予測を受け取った記録があります。Log#26・#27には、深くつかむお手本50本をそろえ、一から学習した記録があります。  
> お手本の保存から学習への受け渡しは、本文・付属コードを照合して記載します。つながらない箇所は「この段階の接続は未確認」と表示します。

制作の完了条件も「表を照合した」から「開始から実機まで、接続できた段と不足する段を示した」へ変えるべきです。

### 2.【高】環境表が、異なる実験の条件を一組の環境に見せてしまう

**弱い所**  
「確かめた場面」はありますが、読者が欲しいのは、どの条件を一緒にそろえるかです。ゲームパッド操作で確認した版と、電源交換後の成功結果を同じ表に並べると、その組み合わせで動いたと受け取られる余地があります。さらに、版・カメラ・学習設定など肝心の不足が最後の一行に埋まっています。

**こう直せばもっと強くなる**  
表の冒頭に次を置き、未確認項目を一項目ずつ分けます。

> **この表は、各ログで確認できた条件の一覧です。全項目を同時に使った一組の環境としては、まだ確認できていません。**

具体的には次のようにします。

| 項目 | ログで確認できたこと | 同じ環境を組むために残る確認 |
|---|---|---|
| Piのpymycobot | ゲームパッド操作では2.9.6で送信が約0.02秒（Log#20） | Log#34の実機実験でも同じ版だったか |
| openpiの版 | 提示された要約には記載なし | 本文・付属コードを照合 |
| Pythonの版 | 提示された要約には記載なし | 本文・付属コードを照合 |
| CUDAの版 | 提示された要約には記載なし | 本文・付属コードを照合 |
| カメラの構成 | この表では未確定 | 本文・付属コードを照合 |
| 学習設定・データの置き場 | この表では未確定 | 項目を分けて照合 |

「制作時に照合する」という作業予定を、読者が判断できる不足一覧に変えます。

### 3.【高】主指標の判定条件を、依頼より厳しく書き換えている

**弱い所**  
「自分以外の環境での記録が1件要ります」は、依頼の条件と違います。依頼には、第三者が再現に必要な情報の欠落がないことを確認する道もあります。「未記載が残る間は数えない」も、再現に必要な不足なのかを区別していません。

**こう直せばもっと強くなる**  
制作の決まりとフォームの理由を、次の文に統一します。

> **再現可能な環境として数える条件**  
> 手順と依存関係・バージョンを公開したうえで、別の環境で再現された記録、または再現に必要な情報が欠けていないことを第三者が確認した記録を示します。再現に必要な項目に未記載が残る間は、条件を満たしたとは扱いません。

また、「第三者による再現：まだ記録がない」は、提供資料で言える範囲に絞ります。

> **このログ一覧からは、第三者による再現・必要情報の確認記録は確認できません。**

### 4.【高】最重要の連絡が、「不足情報の報告」に偏っている

**弱い所**  
見出しが「足りない情報がありましたか」なので、順調に始められた人や、まだ不足を言語化できない人が対象から外れます。作者側が実績を得たい理由も前に出ていて、送る人に何を書けばよいかが弱いです。

**こう直せばもっと強くなる**  
環境表の直後と節6に、同じ文面を置きます。

> **同じ環境で始めようとした記録を送る**  
> 始める前の確認、途中で止まった記録、動いた記録を送れます。全部そろっていなくても構いません。  
> ・試そうとしたこと  
> ・この表と違う機材・版（分かる範囲）  
> ・開いたログと、進めた所／止まった所  
> ・足りなかった情報、または動いた条件  
>   
> 別の環境でも始められるかを確かめ、手順と不足一覧の修正に使います。  
> **「再現を試した・試そうとした記録を送る」→ /message**

既存フォームへ送る前に、このページ上で記入内容を分かるようにします。

### 5.【中】最初の画面で、読者が次にすることが見えない

**弱い所**  
冒頭は記録本数と成果の説明に使われています。位置1の「つかめた」と位置5の「箱に入れた」は正確に分かれていますが、初見では条件の異なる成果を読み解く負担があります。「自分はどこを見れば始められるか」が後回しです。

**こう直せばもっと強くなる**  
成果の詳しい数字は到達点の節へ移し、冒頭を次の文面にします。

> MacからRunpodのA40を使い、π0.5を追加学習してmechArm 270でブロックを箱に入れるまでの環境と記録をまとめました。  
> **まず環境表で手元との差を確認し、始める段階のログを開いてください。**  
> 版や手順で確認できていない所も表示します。すべての位置で安定して動いたことを示すページではありません。  
>   
> **「環境を照合する」／「始める段階を選ぶ」**

ページ名も、読者の目的を先に出せます。

> **π0.5をmechArm 270で動かし始めるための環境・手順・未記載項目**

### 6.【中】落とし穴と経緯が厚く、開始に必要な注意を拾いにくい

**弱い所**  
節4・5には価値がありますが、電源・版・肩の範囲から、電流や成否判定までが続きます。これでは「始める入口」が、研究経緯を読むページへ戻りやすいです。また、肩の角度を渡す方法など、後続実験にも適用すべきか未確認の修正が、共通の必須手順に見えます。

**こう直せばもっと強くなる**  
注意事項を、それが必要になる段の直下へ移します。

> **実機を動かす前に確認**  
> 電源交換後の結果はLog#34、Piのpymycobotによる操作遅延はLog#20、お手本を録る際の肩の制約はLog#9を参照してください。

過去の修正には適用範囲を添えます。

> **過去の実機実験で効いた修正**  
> Log#12では、AIに渡す肩の角度を直前の目標へ変えると、箱に当てていた動きが直りました。Log#27以降にも必要な設定かは、照合して示します。

電流・成否判定・詳細な経緯は「実機を試した後に読む」にまとめ、開始までの流れを先に完結させます。

### 7.【中】公開後の測定が、人とログへの移動に寄っている

**弱い所**  
AI経由の二つのゴールが「効く理由」にしかなく、公開後に何を確認して直すかが決まっていません。また、ログへの移動が3割未満なら表を直す、という判断だけでは、入口が見つかっていない問題と、開始するログを選べない問題を分けられません。

**こう直せばもっと強くなる**  
測定欄を次のように追記します。

> 人の表示、ログへ進んだ人、再現を試した・試そうとした連絡に加え、このページへのAIによる取得数と、AIのリンクから来た人を別々に記録します。  
> AIによる取得は2か月目から週3件以上、AIのリンクからの来訪は月1件以上を目標にします。  
> 人の表示が30件未満の間は、ページの良し悪しを断定しません。30件に達した時点で、流入元と、始める段階からログへ進めたかを確認します。連絡では、環境表・手順のどこが開始を妨げたかを最優先で見ます。

AI向けの入口にも、本文と同じ条件付きの要約を置く企画にします。

> **Mac・Runpod A40・mechArm 270でπ0.5を追加学習した環境、実機結果、未記載項目を確認できます。結果は実験条件ごとに分けて掲載しています。**

### 守るべき尖り

**「ログにない所」を隠さず、出典と一緒に見せる環境表です。**  
成功した記録の紹介で終わらず、読む人が「自分の環境では、何がまだ足りないか」を判断できる。書き直しでは、この表を薄めず、開始までの手順と直接つないでください。
```


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

```markdown
案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回目）

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

**評者B**
1. 「手順」と言い切る：**一部採る**。名前は「手順」にします。ただし、つながりが未確認な段はその場で示します。隠すと、読者が再現できるかどうかを見誤ります。
2. 落とし穴を必須設定にする：**一部採る**。「この記録で使った設定」として段の直下に置きます。「必ず」は付けません。ログが示しているのは、その条件で出た結果までだからです。
3. 3行目を連絡への呼びかけにする：**採らない**。最初に「未記載」を見せることが、この案の尖りです。呼びかけは表の直後と最後の節に置きます。
4. 連絡の窓口を広げる：**採る**（A4 と同じ）。
5. 企画の時点で「未記載」と言い切る：**一部採る**。今の時点で言えるのは「要約には記載なし」までです。本文とコードはまだ照合していないので、「ログにない」とは書きません。書けば事実の誤りになるおそれがあります。
6. 経緯を削る：**一部採る**。「試した後に読む」の索引1行に縮めます。ログへ進む入口でもあるので、全部は削りません。

**自分で見つけた事実の誤り**
- Log#34 の「箱に入れた」は、要約の言い方どおり「成功」に直します。
- Log#20 は、4.0.4 の「1回の指令に1.6秒」と、2.9.6 の「送信が約0.02秒」を書き分けます。

---

【企画書】

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

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
mechArm 270 と Mac を持っていて、手元に GPU がない日本語の開発者1人に絞ります。
- **どこから来るか**：今は Google や ChatGPT から Log#4 のような個々のログに直接着き、1本読んで出ていきます。このページへは次の道から来てもらいます。
  - AI の答え
  - 「mechArm 270 電源」「π0.5 追加学習」での検索
  - シリーズのページの資料欄
  - /gpu-buy-or-rent
  - LinkedIn
- **何に困っているか**：どの部品・どの版で、どこまで動いたのか、手元と何が違うのかが、ログ1本では分かりません。

### この人がこのページで得るもの（1文）
手元との違いと、まだ確かめられていない所を1枚で知り、始める段のログを開けます。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**見出し**：π0.5 を mechArm 270 で追加学習して動かし始める：環境・手順・ログにない所

1. Mac から Runpod の A40 を借りて π0.5 を追加学習し、mechArm 270 でブロックを箱に入れるまでの記録34本を、1枚に束ねました。
2. 深くつかむお手本50本で学んだモデルは、位置1で3回とも直しなしでつかみました（Log#28）。電源を12V・5A に替えた日は、位置5で5回とも成功しました（Log#34）。
3. まず環境の表で手元との差を確かめ、始める段のログを開いてください。ログにない所は「未記載」と書いています。

ボタン：「環境の表を見る」「始める段を選ぶ」

### 見せ場（このページにしかないもの。ログのどの事実か）
**環境の表**です。表の上に次の但し書きを置きます。
「各ログで確かめられた条件の一覧です。全部の項目を同時に使った一組の環境としては、まだ確かめていません。」

| 項目 | ログで確かめたこと | 残る確認 |
|---|---|---|
| GPU | Runpod の A40。推論（Log#2）、学習（Log#4・#27） | — |
| 電源 | 12V・5A で位置5が5回とも成功。本体は40W を求め、12V・2A では24W（Log#30・#34） | — |
| Pi の pymycobot | 4.0.4 では1回の指令に1.6秒。2.9.6 では送信が約0.02秒（ゲームパッドの操作・Log#20） | Log#34 の実機でも同じ版だったか |
| 肩の範囲 | 約88°より深く倒すと、命令がエラーなしに捨てられた（Log#9） | — |
| お手本 | 深くつかむお手本を5か所×10本（Log#26・#27） | — |
| 直す道具 | 3,198円の互換ゲームパッド（Log#19・#21） | 型番 |
| openpi の版 | 要約には記載なし | 本文とコードで照合し、なければ「ログにない（未記載）」 |
| Python の版 | 同上 | 同上 |
| CUDA の版 | 同上 | 同上 |
| カメラの構成 | 同上 | 同上 |
| 学習の設定 | 同上 | 同上 |
| データの置き場 | 同上 | 同上 |

**表の下に置く「実測の例」**
- 推論：平均97ms、往復391ms、0.34ドル（Log#2）
- 学習：3,000ステップで6.2時間・約579円（Log#27）
- GPU の空き待ち：起動まで約4時間半かかった回がある（Log#10）

**再現できる環境として数える条件**（ページにもこのまま書きます）
- 手順と、依存関係・版を公開します。
- そのうえで、別の環境で再現された記録か、再現に必要な情報が欠けていないことを第三者が確かめた記録を示します。
- 再現に必要な項目に「未記載」が残っている間は、条件を満たしたとは扱いません。

**制作の完了条件**
- 表のすべての項目を、ログの本文と付属のコードで照合し終えていること。
- 始める段から実機まで、つながった段とつながっていない段をページに示していること。

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
1. **確かめた到達点（条件ごとに分けて書く）**
   - 50本で学んだモデル：位置1は3回とも直しなしでつかめた。位置2は4回とも、つかむ姿勢まで届かなかった（Log#28）。
   - 電源を5A に替えた日：位置5で5回とも成功した。ほかの位置まで安定しているかは、この結果だけでは判断できない（Log#34）。
   - 第三者の記録：「このログ一覧からは、第三者による再現や、必要な情報の確認の記録は確かめられません」と書く。
2. **環境の表と実測の例**
   - 表の直後に、節5と同じ文面で送り先への道を置く。
3. **始めるまでの手順と、まだつながっていない所**
   - 段ごとに「出典ログ／次へ進む確認」を書く。つながりを確かめられていない段には、その場に「この段のつながりは未確認」と書く。
   1. 遠隔で推論する（Log#2）
      - 次へ進む確認：Mac で動きの数値を受け取れること。
   2. 実機を整える（Log#34・#20・#9）
      - この記録で使った設定：12V・5A の電源、pymycobot 2.9.6、肩は約88°まで。
   3. 深くつかむお手本をそろえる（Log#25・#26）
      - 次へ進む確認：5か所×10本がそろうこと。
      - 爪がブロックに乗った回は、下ろす時間で見分けられた（普段1.1秒が7.9〜9.1秒に）。
      - 注意：前の学習データは30本中7本が浅いつかみだった（Log#23）。π0.5 はお手本の中の止まっている時間まで覚える（Log#11）。
      - お手本を学習に渡す所は未確認。Log#4 には、お手本2本で追加学習し、Mac で予測を受け取った記録がある。照合して書き足す。
   4. 50本で一から学習する（Log#27）
      - 次へ進む確認：loss が0.1015から0.0036まで下がった記録と比べる。
   5. 実機で試し、記録と比べる（Log#28・#34）
      - 過去の実機で効いた直し：AI に渡す肩の角度を直前の目標に変えると、毎回約2°足りずに箱に当てていた動きが直った（Log#12）。Log#27 以降にも要るかは、照合して示す。
      - 位置2を外したのは、上カメラの傾きのせいではなかった。録画の画像の傾きだけを変えて1,770回答えさせても、行き先は入れ替わらなかった（Log#29）。
4. **試した後に読む**
   - 人が直す1回の時間：ゲームパッドで中央14.5秒、キーボードで43.2秒（Log#32）
   - サーボの電流：爪が空で閉じると15前後、ブロックをつかむと870前後（Log#24）
   - 成否の判定：Gemini Decision 1 は56本すべての成否を見分けたが、つかみの深さは見分けられなかった（Log#33）
   - 経緯の索引：LIBERO で20回中20回（Log#3）→ 学習（Log#4・#5・#7・#10）→ 実機（Log#6・#13・#14）→ 人の直し（Log#15〜#18・#22。学び直したあとも、成功した6回はすべて人の補正つき・Log#18）
5. **同じ環境で始めようとした記録を送る**
   - 始める前の確認、途中で止まった記録、動いた記録のどれでも送れます。全部そろっていなくて構いません。
   - 書いてほしいこと：
     - 試そうとしたこと
     - この表と違う機材や版
     - 開いたログと、進めた所・止まった所
     - 足りなかった情報、または動いた条件
   - 使い道：別の環境でも始められるかを確かめ、手順と不足の一覧を直すのに使います。
   - 送り先：「再現を試した・試そうとした記録を送る」→ /message

### 束ねるログ（/record/… の一覧）
フィジカルAI研究室を作る Log#1〜#34 の34本です（どれも /record/ の下）。手順で使う主なログは次のとおりです。
- openpi-remote-inference-first-run
- pi05-mecharm-demo-to-inference
- teach-replay-19-demos
- pi05-first-block-in-box
- gamepad-moves-mecharm-270-pymycobot-version
- pi05-failures-traced-to-shallow-grasp-demos
- reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- even-ten-demos-per-spot-mecharm-270-reteaching
- retrain-pi05-from-base-on-50-even-demos
- pi05-even-demos-on-arm-misses-position-2
- pi05-position-2-miss-caused-by-camera-tilt
- mecharm-270-drops-block-underpowered-adapter
- mecharm-270-5a-adapter-stops-dropping-block

残りは経緯の索引から開きます。SO-101 の2本は使いません。

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
- **シリーズのページの資料欄**：「π0.5 × mechArm 270 を始める：環境・版・手順の一覧」
- **/gpu-buy-or-rent の実費の箇所**：「A40で3,000ステップ・6.2時間・約579円だった実験の環境と手順を見る」
- **トップ**：シリーズの節に題名だけを足します。
- **LinkedIn**：「π0.5 を mechArm 270 で動かした環境・手順・ログにない所を1ページにまとめました」。相談の窓口は出しません。
- **AI と検索**：版・型番・数字を本文の文字で書きます。拾われやすくなるかは推測です。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、どこから来たか
- ログへ進んだ人の割合（人単位で数える）。「手順から開いた」と「表の出典を確かめた」は分けて数えます。
- AI による取得の数（2か月目から週3件以上が目標）と、AI のリンクからの来訪（月1件以上が目標）。この2つは別々に記録します。
- 30件に達したら、2つを分けて見ます。
  - 人がたどり着けているか（どこから来たか）
  - たどり着いた人が、始める段のログへ進めているか
- 連絡が来たら、表や手順のどこが始めるのを妨げたかを、いちばん先に見ます。
- 3か月で表示が30件未満で、連絡も0件なら、追加の手間はかけません。ページは残します。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
- **人の表示（3か月で150件）**
  - 効く理由：シリーズ・LP・SNS から直接来る道ができる。
  - 効かないかもしれない理由：mechArm 270 を持つ人は少ない。
- **ログへ進んだ人（表示の3割）**
  - 効く理由：表の行にも手順の段にも出典のログがあり、コードはログにしかない。
  - 効かないかもしれない理由：表だけで用が済む人もいる。
- **AI の依頼で読みに来た数（このページだけで週3件以上）**
  - 効く理由：1回読めば34本分の要点が取れる（推測）。
  - 効かないかもしれない理由：今は AI が読みに来る先が個々のログに散っている。
- **AI のリンクから来た人（月1件以上）**
  - 効く理由：条件ごとに分け、出典を付けた表は、答えの中で引用されやすい（推測）。
  - 効かないかもしれない理由：今はサイト全体でも週1件ほどしかない。
- **問い合わせ・相談（再現を試した人・試そうとした人から1〜2件）**
  - 効く理由：始める前の人も、動いた人も送れる。
  - 効かないかもしれない理由：同じアームを持つ人が少なく、0件もありうる。

---

**エイイチへ**
- 文字数：3,000字以内に収まっているかは数えていません。手順の段に注意を移して1行ずつ分けたぶん、前の版より長くなっています。ログの一覧は、手順で使う13本だけ /record/ の名前を書いて短くしました。ほかの21本は経緯の索引から開きます。それでも超えている場合、次に削るのは「試した後に読む」の節です。
- 「ログにない」と書く時期：openpi・Python・CUDA の版、カメラ、学習の設定、データの置き場は、今の時点では「要約には記載なし」とだけ書いています。本文とコードを照合して見つからなかったときに、はじめて「ログにない（未記載）」と書きます。照合を終えても埋まらない項目だけ、あとで確かめてもらいます。
```


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

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

### 誰に（1人に絞る。その人がどこから来て、何に困っているか）
mechArm 270 と Mac を持っていて、手元に GPU がない日本語の開発者1人に絞ります。
- **どこから来るか**：今は Google や ChatGPT から Log#4 のような個々のログに直接着き、1本読んで出ていきます。このページへは次の道から来てもらいます。
  - AI の答え
  - 「mechArm 270 電源」「π0.5 追加学習」での検索
  - シリーズのページの資料欄
  - /gpu-buy-or-rent
  - LinkedIn
- **何に困っているか**：どの部品・どの版で、どこまで動いたのか、手元と何が違うのかが、ログ1本では分かりません。

### この人がこのページで得るもの（1文）
手元との違いと、まだ確かめられていない所を1枚で知り、始める段のログを開けます。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**見出し**：π0.5 を mechArm 270 で追加学習して動かし始める：環境・手順・ログにない所

1. Mac から Runpod の A40 を借りて π0.5 を追加学習し、mechArm 270 でブロックを箱に入れるまでの記録34本を、1枚に束ねました。
2. 深くつかむお手本50本で学んだモデルは、位置1で3回とも直しなしでつかみました（Log#28）。電源を12V・5A に替えた日は、位置5で5回とも成功しました（Log#34）。
3. まず環境の表で手元との差を確かめ、始める段のログを開いてください。ログにない所は「未記載」と書いています。

ボタン：「環境の表を見る」「始める段を選ぶ」

### 見せ場（このページにしかないもの。ログのどの事実か）
**環境の表**です。表の上に次の但し書きを置きます。
「各ログで確かめられた条件の一覧です。全部の項目を同時に使った一組の環境としては、まだ確かめていません。」

| 項目 | ログで確かめたこと | 残る確認 |
|---|---|---|
| GPU | Runpod の A40。推論（Log#2）、学習（Log#4・#27） | — |
| 電源 | 12V・5A で位置5が5回とも成功。本体は40W を求め、12V・2A では24W（Log#30・#34） | — |
| Pi の pymycobot | 4.0.4 では1回の指令に1.6秒。2.9.6 では送信が約0.02秒（ゲームパッドの操作・Log#20） | Log#34 の実機でも同じ版だったか |
| 肩の範囲 | 約88°より深く倒すと、命令がエラーなしに捨てられた（Log#9） | — |
| お手本 | 深くつかむお手本を5か所×10本（Log#26・#27） | — |
| 直す道具 | 3,198円の互換ゲームパッド（Log#19・#21） | 型番 |
| openpi の版 | 要約には記載なし | 本文とコードで照合し、なければ「ログにない（未記載）」 |
| Python の版 | 同上 | 同上 |
| CUDA の版 | 同上 | 同上 |
| カメラの構成 | 同上 | 同上 |
| 学習の設定 | 同上 | 同上 |
| データの置き場 | 同上 | 同上 |

**表の下に置く「実測の例」**
- 推論：平均97ms、往復391ms、0.34ドル（Log#2）
- 学習：3,000ステップで6.2時間・約579円（Log#27）
- GPU の空き待ち：起動まで約4時間半かかった回がある（Log#10）

**再現できる環境として数える条件**（ページにもこのまま書きます）
- 手順と、依存関係・版を公開します。
- そのうえで、別の環境で再現された記録か、再現に必要な情報が欠けていないことを第三者が確かめた記録を示します。
- 再現に必要な項目に「未記載」が残っている間は、条件を満たしたとは扱いません。

**制作の完了条件**
- 表のすべての項目を、ログの本文と付属のコードで照合し終えていること。
- 始める段から実機まで、つながった段とつながっていない段をページに示していること。

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
1. **確かめた到達点（条件ごとに分けて書く）**
   - 50本で学んだモデル：位置1は3回とも直しなしでつかめた。位置2は4回とも、つかむ姿勢まで届かなかった（Log#28）。
   - 電源を5A に替えた日：位置5で5回とも成功した。ほかの位置まで安定しているかは、この結果だけでは判断できない（Log#34）。
   - 第三者の記録：「このログ一覧からは、第三者による再現や、必要な情報の確認の記録は確かめられません」と書く。
2. **環境の表と実測の例**
   - 表の直後に、節5と同じ文面で送り先への道を置く。
3. **始めるまでの手順と、まだつながっていない所**
   - 段ごとに「出典ログ／次へ進む確認」を書く。つながりを確かめられていない段には、その場に「この段のつながりは未確認」と書く。
   1. 遠隔で推論する（Log#2）
      - 次へ進む確認：Mac で動きの数値を受け取れること。
   2. 実機を整える（Log#34・#20・#9）
      - この記録で使った設定：12V・5A の電源、pymycobot 2.9.6、肩は約88°まで。
   3. 深くつかむお手本をそろえる（Log#25・#26）
      - 次へ進む確認：5か所×10本がそろうこと。
      - 爪がブロックに乗った回は、下ろす時間で見分けられた（普段1.1秒が7.9〜9.1秒に）。
      - 注意：前の学習データは30本中7本が浅いつかみだった（Log#23）。π0.5 はお手本の中の止まっている時間まで覚える（Log#11）。
      - お手本を学習に渡す所は未確認。Log#4 には、お手本2本で追加学習し、Mac で予測を受け取った記録がある。照合して書き足す。
   4. 50本で一から学習する（Log#27）
      - 次へ進む確認：loss が0.1015から0.0036まで下がった記録と比べる。
   5. 実機で試し、記録と比べる（Log#28・#34）
      - 過去の実機で効いた直し：AI に渡す肩の角度を直前の目標に変えると、毎回約2°足りずに箱に当てていた動きが直った（Log#12）。Log#27 以降にも要るかは、照合して示す。
      - 位置2を外したのは、上カメラの傾きのせいではなかった。録画の画像の傾きだけを変えて1,770回答えさせても、行き先は入れ替わらなかった（Log#29）。
4. **試した後に読む**
   - 人が直す1回の時間：ゲームパッドで中央14.5秒、キーボードで43.2秒（Log#32）
   - サーボの電流：爪が空で閉じると15前後、ブロックをつかむと870前後（Log#24）
   - 成否の判定：Gemini Decision 1 は56本すべての成否を見分けたが、つかみの深さは見分けられなかった（Log#33）
   - 経緯の索引：LIBERO で20回中20回（Log#3）→ 学習（Log#4・#5・#7・#10）→ 実機（Log#6・#13・#14）→ 人の直し（Log#15〜#18・#22。学び直したあとも、成功した6回はすべて人の補正つき・Log#18）
5. **同じ環境で始めようとした記録を送る**
   - 始める前の確認、途中で止まった記録、動いた記録のどれでも送れます。全部そろっていなくて構いません。
   - 書いてほしいこと：
     - 試そうとしたこと
     - この表と違う機材や版
     - 開いたログと、進めた所・止まった所
     - 足りなかった情報、または動いた条件
   - 使い道：別の環境でも始められるかを確かめ、手順と不足の一覧を直すのに使います。
   - 送り先：「再現を試した・試そうとした記録を送る」→ /message

### 束ねるログ（/record/… の一覧）
フィジカルAI研究室を作る Log#1〜#34 の34本です（どれも /record/ の下）。手順で使う主なログは次のとおりです。
- openpi-remote-inference-first-run
- pi05-mecharm-demo-to-inference
- teach-replay-19-demos
- pi05-first-block-in-box
- gamepad-moves-mecharm-270-pymycobot-version
- pi05-failures-traced-to-shallow-grasp-demos
- reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- even-ten-demos-per-spot-mecharm-270-reteaching
- retrain-pi05-from-base-on-50-even-demos
- pi05-even-demos-on-arm-misses-position-2
- pi05-position-2-miss-caused-by-camera-tilt
- mecharm-270-drops-block-underpowered-adapter
- mecharm-270-5a-adapter-stops-dropping-block

残りは経緯の索引から開きます。SO-101 の2本は使いません。

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
- **シリーズのページの資料欄**：「π0.5 × mechArm 270 を始める：環境・版・手順の一覧」
- **/gpu-buy-or-rent の実費の箇所**：「A40で3,000ステップ・6.2時間・約579円だった実験の環境と手順を見る」
- **トップ**：シリーズの節に題名だけを足します。
- **LinkedIn**：「π0.5 を mechArm 270 で動かした環境・手順・ログにない所を1ページにまとめました」。相談の窓口は出しません。
- **AI と検索**：版・型番・数字を本文の文字で書きます。拾われやすくなるかは推測です。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、どこから来たか
- ログへ進んだ人の割合（人単位で数える）。「手順から開いた」と「表の出典を確かめた」は分けて数えます。
- AI による取得の数（2か月目から週3件以上が目標）と、AI のリンクからの来訪（月1件以上が目標）。この2つは別々に記録します。
- 30件に達したら、2つを分けて見ます。
  - 人がたどり着けているか（どこから来たか）
  - たどり着いた人が、始める段のログへ進めているか
- 連絡が来たら、表や手順のどこが始めるのを妨げたかを、いちばん先に見ます。
- 3か月で表示が30件未満で、連絡も0件なら、追加の手間はかけません。ページは残します。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
- **人の表示（3か月で150件）**
  - 効く理由：シリーズ・LP・SNS から直接来る道ができる。
  - 効かないかもしれない理由：mechArm 270 を持つ人は少ない。
- **ログへ進んだ人（表示の3割）**
  - 効く理由：表の行にも手順の段にも出典のログがあり、コードはログにしかない。
  - 効かないかもしれない理由：表だけで用が済む人もいる。
- **AI の依頼で読みに来た数（このページだけで週3件以上）**
  - 効く理由：1回読めば34本分の要点が取れる（推測）。
  - 効かないかもしれない理由：今は AI が読みに来る先が個々のログに散っている。
- **AI のリンクから来た人（月1件以上）**
  - 効く理由：条件ごとに分け、出典を付けた表は、答えの中で引用されやすい（推測）。
  - 効かないかもしれない理由：今はサイト全体でも週1件ほどしかない。
- **問い合わせ・相談（再現を試した人・試そうとした人から1〜2件）**
  - 効く理由：始める前の人も、動いた人も送れる。
  - 効かないかもしれない理由：同じアームを持つ人が少なく、0件もありうる。

---

**エイイチへ**
- 文字数：3,000字以内に収まっているかは数えていません。手順の段に注意を移して1行ずつ分けたぶん、前の版より長くなっています。ログの一覧は、手順で使う13本だけ /record/ の名前を書いて短くしました。ほかの21本は経緯の索引から開きます。それでも超えている場合、次に削るのは「試した後に読む」の節です。
- 「ログにない」と書く時期：openpi・Python・CUDA の版、カメラ、学習の設定、データの置き場は、今の時点では「要約には記載なし」とだけ書いています。本文とコードを照合して見つからなかったときに、はじめて「ログにない（未記載）」と書きます。照合を終えても埋まらない項目だけ、あとで確かめてもらいます。
```


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

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


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

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


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

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

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


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


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

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

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

## mechArm 270 を前提にしない（エイイチと決めたこと）
mechArm 270 を持つ人は少ない。ページは mechArm 270 の持ち主向けにせず、自分の小型アームで公開モデルを動かしたい人に向ける。mechArm 270 は「1台で最後まで通した実例」として置く。
ページは、読む人が使うアームで次の3段に分けて組むこと（段の名前や見せ方は作者が決めてよい）:
1. **アームなしで、誰でも同じ結果まで行ける段**：借りた GPU で π0.5 を動かす（Log#2）、LIBERO のシミュレーションで動かす（Log#3）など。機材に左右されないので、主指標の「再現可能な環境」に一番近い
2. **自分のアームで追加学習する段**：お手本の集め方、学習の条件（本数・ステップ数・時間・費用）。どのアームでも同じ考え方で使える部分
3. **自分のアームで確かめる項目**：mechArm 270 で詰まった所を、どのアームにも当てはまる問いに置き換える（例：電源は足りているか／制御ライブラリの版で指令が遅れていないか／関節の可動範囲の外で命令が黙って捨てられていないか／お手本が浅いつかみになっていないか）。mechArm 270 の具体の数字は、その問いの実例として添える
ほかのアームでどうなるかはログにないので書かない。「mechArm 270 ではこうだった。あなたのアームではここを確かめる」という形に留める。題材は広げない。

## 誰に
π0.5 のような公開モデルを、自分の小型アームで追加学習して動かしたい開発者・研究者全般。アームをまだ持っていない人も、1の段から入れる。日本語で調べる人。ChatGPT・Claude などの AI に聞いてたどり着く人も入る。

## ゴール（公開から3か月。最初の判断は人の表示が30件たまった時点）
| 見るもの | 今の土台 | 3か月のゴール |
|---|---|---|
| このページの人の表示 | 今ある LP は3週間で21件（週7件ほど） | 3か月で150件（週12件ほど） |
| このページからログへ進んだ人 | ログからログへ進む人はほぼいない | 表示した人の3割 |
| AI の利用者の依頼で、このページを読みに来た数 | サイト全体で週50件前後 | このページだけで週3件以上（2か月目から） |
| AI のリンクから、このページに来た人 | サイト全体で週1件ほど | 月1件以上 |
| 問い合わせ・相談 | フォームからの連絡は、ある週で3件 | 再現を試した人、または試そうとした人から1〜2件（いちばん重い） |
3か月で表示が30件に届かず連絡も0件なら、このページに手間をかけるのをやめる（ページは資産として残す）。人の表示を増やすこと自体は目的にしない。

## 考えに入れること
- 人の多くは Google から個々のログに直接来て、1本読んで出ていく。トップを通る人は1割ほど。ログの形式は変えられないので、このページへは、AI の答え・検索・シリーズのページ・今ある LP（/gpu-buy-or-rent）・SNS からたどり着くことになる。どこから来るかを、企画書で具体に書くこと
- 問い合わせの窓口はメッセージフォーム（/message）だけ。トップや SNS に相談の窓口を出さない。ただしこのページから「試した記録を送る」道をフォームへ置くのはよい
- ログに書いていない手順・バージョン・数字を作らない。ログの要約に書いていないものは「要約には記載なし（本文とコードで照合が要る）」と書き、照合してもなければ「ログにない（未記載）」とする。足りないこと自体をページに見せる

## 実際の数字（2026-10-26〜11-14・人の操作があった表示だけ）
- 人の表示は合計367件。週ごとに 164 → 136 → 68（11-09の週は6日分）と減っている
- **トップは40件で約1割。** 人の多くは Google（90件）や直接（153件）から、個々のログに直接来ている。LinkedIn 10件・Yahoo 10件・ChatGPT のリンク4件
- ログからほかのログ・シリーズへ移る動きはわずか（数件ずつ）。1本読んで出ていく
- 主なページの表示（25%/50%/75% まで読んだ割合）
  - / トップ：40件（70%/48%/28%）
  - /gpu-buy-or-rent（GPU は買うか借りるか・LP）：21件（52%/52%/10%）
  - /issues（課題地図）：21件（5%/0%/0%・中央値9秒）
  - /manga-archive：14件
  - /series8（サービスロボット導入シミュレーション）：12件
  - /serving-robot-one-less-staff（配膳ロボットの LP）：3件。ただし中の動画が57回再生され、67%が最後まで読んだ
  - /one-year（1年の記録の LP）：2件
  - よく読まれたログ：DAY18（11件・中央値53秒）、DAY17（7件）、DAY12（6件）、大きな店に配膳ロボット5台（7件）
- AI の利用者の依頼で読みに来た数：週に42〜61件。トップがいちばん多く、残りは個々のログに散る（ChatGPT-User が多く、Claude-User・Perplexity-User もある）
- サイト名で検索して来た人：まだ0
- **注意：** どのページも数が少ない。30件未満の数は「判断できない」として扱い、言い切らない

## 今のサイトの形
- トップ：見出し → 1年の記録 → 課題地図 → 導入前ガイド → 4コマ → いまの考え → シリーズ → 記録 → ロボットに関わる人へ → 事業所について
- シリーズのページ（/series1〜8）：上に資料、下にそのシリーズのログの一覧
- 今ある LP：/serving-robot-one-less-staff（配膳ロボットで人が1人減らせるか）、/gpu-buy-or-rent（GPU は買うか借りるか）、/one-year（1年の記録）
- 課題地図（/issues）：フィジカルAIの社会実装の前に解くべき課題・週1回更新
- ログは全部で約520本。各ログには全文・コード・素材のファイルが付き、「AIで読む」ボタンがある


## フィジカルAI研究室のログ一覧（題名と、各ログの要約。このページはここにある中身だけで作る）

- 225｜SO-101 失敗から学ぶアームを作る Log#1 | 精度を上げることと、失敗から学ぶことは違う｜/record/precision-is-not-learning-so101
  アームの動きを合わせる表（FKテーブル）を濃くしても、失敗から学ぶようにはならない。精度を上げることと失敗から学ぶことは別だと対話で行き着き、次は失敗から学ぶアームをSO-101で作ると決めた。
- 234｜SO-101 失敗から学ぶアームを作る Log#2 | 2TBの外付けSSDを、学習データの定位置にする｜/record/where-learning-data-lives
  模倣学習のデータは、Macではなく2TBの外付けSSDを定位置にして1か所に集めることにした。決める前に、Macの空き容量が約90GBから20GBまで減っていた原因を突き止めて片付けた。
- 277｜フィジカルAI研究室を作る Log#1 | 自宅にゼロから、誰でも再現できる形で｜/record/building-a-physical-ai-lab-at-home
  ロボットのAI（Physical AI）が学習できる環境を、個人の自宅にゼロから作り、誰でも同じ手順で作り直せる形で公開するシリーズを始めた。目的は、学習と推論を自分の手で回せる環境を残すこと。
- 326｜フィジカルAI研究室を作る Log#2 | Physical Intelligence の π0.5 を借りたGPUで動かした｜/record/openpi-remote-inference-first-run
  Physical Intelligenceのπ0.5はMacでは動かないが、RunpodでA40を借りれば動いた。Macから画像と指示文を送り、動きの数値を受け取るまで通した。推論は平均97ms、往復391ms、費用0.34ドル。
- 327｜フィジカルAI研究室を作る Log#3 | Physical Intelligence の π0.5 に要るGPUメモリを測った｜/record/pi05-libero-benchmark-first-run
  Physical Intelligenceのπ0.5は、Runpodで借りたA40の上で、シミュレータLIBEROのアームに「黒いボウルを拾って皿に置く」作業を20回すべて成功させた。使うGPUメモリの量も測った。
- 337｜フィジカルAI研究室を作る Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
  Physical Intelligenceのπ0.5をmechArm 270のお手本2本でA40で200ステップ追加学習すると、lossは0.1031から0.0162へ下がり、Macで予測を受け取れた。実機はまだ動かしていない。
- 337｜フィジカルAI研究室を作る Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
  Physical Intelligenceのπ0.5をmechArm 270のお手本2本でA40で200ステップ追加学習すると、lossは0.1031から0.0162へ下がり、Macで予測を受け取れた。実機はまだ動かしていない。
- 341｜フィジカルAI研究室を作る Log#5 | Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致｜/record/pi05-mecharm-lora-2000-steps
  Physical Intelligenceのπ0.5をmechArm 270のお手本19本で2,000ステップ学習すると、実機に送る前の予測はお手本の最初の1秒と数度以内で一致した。lossは0.1155から0.0054へ。
- 345｜フィジカルAI研究室を作る Log#6 | Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った｜/record/pi05-mecharm-first-real-run
  お手本19本で学習したPhysical Intelligenceのπ0.5でmechArm 270を初めて動かすと、ブロックの真上で手首が指令に届かず止まった。原因は爪がブロックに乗っていたことで、動画で分かった。
- 348｜フィジカルAI研究室を作る Log#7 | Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた｜/record/pi05-mecharm-4000-steps
  Physical Intelligenceのπ0.5の学習を4,000ステップに倍にしても、mechArm 270が手を伸ばす先は変わらず、爪は2回ともブロックの奥で空を閉じた。lossは0.0030まで下がっていた。
- 349｜フィジカルAI研究室を作る Log#8 | 手で教えた動きを再生し、4回続けて箱に入れた｜/record/drag-teach-waypoint-replay
  mechArm 270に姿勢を手で教えて再生させる方法で、ブロックを箱に入れる動きを4回続けて成功させた。床に当たって止まったが、高めに教え直し確認の幅を広げて直した。π0.5に渡すお手本を作るため。
- 352｜フィジカルAI研究室を作る Log#9 | 手で教えてお手本19本。肩88°を超えた姿勢は動かなかった｜/record/teach-replay-19-demos
  mechArm 270に手で教えた動きを再生しながら録り、Physical Intelligenceのπ0.5に渡すお手本を5か所19本集めた。肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられていた。
- 355｜フィジカルAI研究室を作る Log#10 | 位置を変えたお手本で、Physical Intelligence の π0.5 を学習し直した｜/record/pi05-retrain-five-positions
  置き場所を5か所に広げたお手本19本で、Physical Intelligenceのπ0.5をA40で4,000ステップ学習し直すと、lossは0.0858から0.0037へ。GPUの空き待ちで起動まで約4時間半かかった。
- 358｜フィジカルAI研究室を作る Log#11 | Physical Intelligence の π0.5 は「待ち時間」まで覚えた｜/record/pi05-learned-the-pauses
  Physical Intelligenceのπ0.5は、お手本の中の止まっている時間まで覚えていた。停止を詰めて学習し直すと、mechArm 270はブロックをつかんで箱まで運んだが、持ち上げずに箱の外で離した。
- 361｜フィジカルAI研究室を作る Log#12 | Physical Intelligence の π0.5 が初めてブロックを箱に入れた｜/record/pi05-first-block-in-box
  Physical Intelligenceのπ0.5で動かすmechArm 270が、初めてブロックを箱に入れた。学習し直さず、AIに渡す肩の角度を直前の目標に変えただけで、毎回約2°足りず箱に当てていた動きが直った。
- 363｜フィジカルAI研究室を作る Log#13 | Physical Intelligence の π0.5 がお手本の3か所すべてで箱に入れた｜/record/pi05-all-three-positions
  Physical Intelligenceのπ0.5で動かすmechArm 270が、試した3か所すべてでブロックを箱に入れた。Dは離す前に爪から落ち、Eは縁すれすれ。運ぶ間の肩はお手本より2.9〜4.0°低かった。
- 401｜フィジカルAI研究室を作る Log#14 | π0.5 を回数で測ったら、苦手な置き場所が見えた｜/record/pi05-weak-position-d
  Physical Intelligenceのπ0.5で動かすmechArm 270の実機は、3か所に5回ずつ置いたブロックを15回中9回箱に入れた。位置Cは5/5、Eは3/5、腕を伸ばしきるDは1/5だった。
- 403｜フィジカルAI研究室を作る Log#15 | mechArm 270 の失敗を巻き戻し、直して覚えさせる｜/record/rewind-and-correct-pi05
  Physical Intelligenceのπ0.5で動かすmechArm 270の実機推論に、失敗した区間を巻き戻すキーと関節を1°ずつ直すキーを足し、直した動きだけを学習データにする仕組みを作った。実機ではまだ動かしていない。
- 407｜フィジカルAI研究室を作る Log#16 | 直した mechArm 270 の動きを π0.5 に覚えさせる手前まで｜/record/rewind-correct-real-arm
  Physical Intelligenceのπ0.5で動かす実物のmechArm 270で、失敗しかけた動きをキーで巻き戻し根元の向きを直すと、AIは続けてブロックをつかめた。持ち上げる間に爪がゆるみ、直した回はまだ箱まで運べていない。
- 417｜フィジカルAI研究室を作る Log#17 | 人が直した mechArm 270 の5回で π0.5 を学び直す｜/record/retrain-pi05-with-human-corrections
  Physical Intelligenceのπ0.5で動かす実物のmechArm 270を8回動かし、成功した5回はすべて人が根元とひじを直していた。その5回を学習データに作り直し、前のモデルから続けて1,500ステップ学習した。
- 419｜フィジカルAI研究室を作る Log#19 | ゲームパッドで mechArm 270 を直す準備ができた｜/record/gamepad-ready-to-correct-mecharm-270
  3,198円の互換ゲームパッドをMacにつなぐと、ボタン16個と軸6本が読め、mechArm 270の関節を1押し0.5°ずつ動かして爪を開け閉めし、操作を全部記録するスクリプトができた。実機はまだで、アームなしで172回確かめた。
- 422｜フィジカルAI研究室を作る Log#18 | 学び直した π0.5 でも mechArm 270 には人の直しが要った｜/record/retrained-pi05-still-needs-human-corrections
  人が直した5回で学び直したPhysical Intelligenceのπ0.5で実物のmechArm 270を9回動かすと、成功6回はすべて補正つきで、補正なしの1回は根元が約2°足りず空振りした。終わりに手首のサーボが応えなくなった。
- 436｜フィジカルAI研究室を作る Log#20 | ゲームパッドで動いた mechArm 270、遅さは pymycobot の版｜/record/gamepad-moves-mecharm-270-pymycobot-version
  ゲームパッドで mechArm 270 を動かすと1回の指令に1.6秒かかった原因は、Pi の daemon が pymycobot 4.0.4 を読んでいたこと。2.9.6 に戻すと送信は約0.02秒、長押しで毎秒約8°動くようになった。
- 446｜フィジカルAI研究室を作る Log#21 | ゲームパッドで mechArm 270 を直す形が固まった｜/record/gamepad-correction-mecharm-270-settled
  小型アーム mechArm 270 をゲームパッドで手直しするには、長押しは15°先へ1回送り離したら stop、1回押しは動かす関節だけを送る形がよかった。受付なしは40回から0回になり、ほかの関節のずれも積み上がらなくなった。
- 450｜フィジカルAI研究室を作る Log#22 | mechArm 270 の AI の直しが、ゲームパッドで1回13秒に｜/record/gamepad-fixes-mecharm-270-ai-in-13-seconds
  mechArm 270 を動かす Physical Intelligence の π0.5 の失敗を人がゲームパッドで直すと1回は中央13秒で、キーで直した前の回の41〜51秒より短い。実機9回で19回直し、直す所は毎回同じ2か所だった。
- 460｜フィジカルAI研究室を作る Log#23 | π0.5 の失敗の原因を探ると、浅いお手本だった｜/record/pi05-failures-traced-to-shallow-grasp-demos
  mechArm 270 で Physical Intelligence の π0.5 が失敗した主な原因は、置き場所ではなく、ブロックが奥まで入る前に爪を閉じる浅いつかみ。学習データ30本中7本も同じ浅さだった。
- 461｜フィジカルAI研究室を作る Log#24 | 手応えを学習に足すため、mechArm 270 の電流を読んだ｜/record/reading-mecharm-270-servo-current-for-learning
  mechArm 270 のサーボの電流は、用意された関数では答えず、サーボの中の番地を直接読むと1秒に約10回取れた。爪の値は空で閉じると15前後、ブロックをつかむと870前後。力センサーなしで手応えを π0.5 のお手本に足す準備。
- 463｜フィジカルAI研究室を作る Log#25 | 深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した｜/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
  mechArm 270 のつかむ姿勢をゲームパッドで作り直すと、浅かった位置1のお手本が深くなり、2か所で使えるお手本を17本足せた。爪がブロックに乗った回は、下ろす時間（普段1.1秒→7.9〜9.1秒）で見分けられた。
- 479｜フィジカルAI研究室を作る Log#26 | 偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に｜/record/even-ten-demos-per-spot-mecharm-270-reteaching
  mechArm 270 の位置3・4は、教えたつかむ姿勢そのものが原因だった。ゲームパッドで教え直し肩だけで下ろす形にすると深くつかめ、Physical Intelligence の π0.5 のお手本が5か所10本ずつそろった。
- 480｜フィジカルAI研究室を作る Log#27 | 浅いつかみの癖を残さず、π0.5 を50本で一から学習｜/record/retrain-pi05-from-base-on-50-even-demos
  位置ごとに10本そろえた深いお手本50本で、Physical Intelligence の π0.5 を一から学習し直すと、Runpod の A40 で3,000ステップに6.2時間・約579円かかった。loss は 0.1015 から 0.0036 まで下がった。
- 484｜フィジカルAI研究室を作る Log#28 | 50本で学んだ π0.5 をアームで試し、位置2 で外れた｜/record/pi05-even-demos-on-arm-misses-position-2
  位置ごとに10本そろえたお手本50本で学習した Physical Intelligence の π0.5 をmechArm 270 で動かすと、位置1 は3回とも直しなしでつかめたが、位置2 は4回ともつかむ姿勢まで届かなかった。
- 486｜フィジカルAI研究室を作る Log#29 | π0.5 が位置2 を外した理由は、カメラの傾きではなかった｜/record/pi05-position-2-miss-caused-by-camera-tilt
  Physical Intelligence の π0.5 が mechArm 270 で位置2 まで下りなかった理由は、上カメラの傾きではなかった。録画の画像の傾きだけを変えて1,770回答えさせても、行き先は入れ替わらなかった。
- 487｜フィジカルAI研究室を作る Log#30 | mechArm 270 がブロックを落とす理由は、まさかの電源不足｜/record/mecharm-270-drops-block-underpowered-adapter
  実物の小型ロボットアーム mechArm 270 がつかんだブロックを落とすのは、電源アダプターの不足が原因とみられる。本体は40W を求めるのに、つないでいたのは12V・2A（24W）だった。
- 490｜フィジカルAI研究室を作る Log#31 | mechArm 270 の待ちを測り、Claude Fable 5.2 の使い所を決めた｜/record/measure-mecharm-270-waits-decide-claude-fable-5-2-role
  Anthropic の Claude Fable 5.2 は、実物のロボットアーム mechArm 270 の実験では、失敗の見立てのような人の判断の所に絞って使う。π0.5 の実機20本では、アームが動いていたのは全体の44%だった。
- 492｜フィジカルAI研究室を作る Log#32 | mechArm 270 を人が直す時間を測り、縮める先を決めた｜/record/measure-mecharm-270-recovery-time-decide-what-to-cut
  ロボットアーム mechArm 270 の実機で π0.5 の失敗を人がゲームパッドで直すのは1回中央14.5秒で、関節を動かすのは2.6秒だけ。キーボードの43.2秒から3分の1になり、残りは直しの出入りとつかみ直しにかかっていた。
- 497｜フィジカルAI研究室を作る Log#33 | アームの成否判定を Google の Gemini Decision 1 に任せられるか｜/record/gemini-decision-1-judge-mecharm-270-pick-and-place
  Google の判断専用モデル Gemini Decision 1 は、ロボットアーム mechArm 270 がブロックを箱に入れたかを56本すべて見分けたが、つかみの深さは見分けられなかった。1回約1秒・168回で約2円。
- 504｜フィジカルAI研究室を作る Log#34 | mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった｜/record/mecharm-270-5a-adapter-stops-dropping-block
  小型ロボットアーム mechArm 270 がブロックを落とす原因は電源の不足だった。12V・5A に替えると、π0.5 は位置5 で5回とも成功（12V・2A の日は3回中1回）。教えた動きの再生も7回すべて成功した。
```


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

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

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

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

### この人がこのページで得るもの（1文）
3つが1枚で分かります。アームなしで同じ結果まで行く手順、自分のアームで学習するときの本数・時間・費用の見積もり、そして loss の外で先に確かめる4つの問いです。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**π0.5 を自分のアームで動かすまで**

1. アームがなくても始められます。借りた A40 で π0.5 を動かし、LIBERO で20回中20回成功するところまで、同じ手順で行けます（Log#2・#3）。
2. 学習の条件は、mechArm 270 で最後まで通した実例の数字で見積もれます。お手本2本・200ステップから、50本・3,000ステップ・6.2時間・約579円まであります（Log#4・#27）。
3. loss が 0.0030 まで下がっても、爪は空を閉じました（Log#7）。実機で効いた原因は、電源・制御ライブラリの版・可動範囲・お手本の浅さです。

### 見せ場（このページにしかないもの。ログのどの事実か）
**見せ場1：「loss と実機の結果」の対照表**
学習のたびの loss と、実機の結果を1つの表に並べます。

| 学習 | loss | 実機の結果 |
|---|---|---|
| 19本・2,000ステップ（#5） | 0.0054 | 爪がブロックに乗った（#6） |
| 4,000ステップ（#7） | 0.0030 | 奥で空振り |
| 5か所（#10） | 0.0037 | 15回中9回成功（#14） |
| 50本・一から学習（#27） | 0.0036 | 位置2は4回とも届かず（#28） |

電源を5Aに替えると、位置5は5回中5回成功しました（#34）。loss だけ見ていても分からない、ということが数字で見えます。

**見せ場2：「欠けている情報」の表**
依存関係とバージョンを並べて、未記載の欄も空欄のまま見せます。主指標の判定条件③に直接つながります。

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
1. **段1 アームなしで同じ結果まで**
   - Log#2：Mac から画像と指示文を送ると、推論は平均97ms、往復391ms、費用0.34ドル。
   - Log#3：LIBERO で20回中20回成功。GPU メモリの使用量の値は要約には記載なし（本文とコードで照合が要る）。
   - 依存関係の表も置く。openpi・Python・CUDA・LIBERO の版は、要約には記載なし。
2. **段2 お手本を集める**
   - 手で教えて再生しながら録る方法（#8・#9）。5か所で19本集めた。
   - π0.5 は止まっている時間まで覚える（#11）。停止は詰めて録る。
   - 浅いつかみが30本中7本あった（#23）。
   - 位置ごとに10本、合わせて50本そろえた（#26）。
3. **段2 学習の条件と費用**
   - 条件の推移：2本・200ステップ（#4）→ 19本・2,000ステップ（#5）→ 4,000ステップ（#7・#10）→ 人が直した5回で1,500ステップ（#17）→ 50本・3,000ステップ・6.2時間・約579円（#27）。
   - GPU の空き待ちで起動まで約4時間半かかった日もある（#10）。
   - そのあと見せ場1の対照表を置く。
4. **段3 あなたのアームで確かめる4つの問い**（mechArm 270 の数字は実例として添える）
   - **電源は足りているか：** 本体は40W を求めるのに、つないでいたのは24W だった（#30）。5A に替えると落とさなくなった（#34）。
   - **制御ライブラリの版で指令が遅れていないか：** pymycobot 4.0.4 では1回の指令に1.6秒かかった。2.9.6 に戻すと約0.02秒（#20）。
   - **可動範囲の外の命令が黙って捨てられていないか：** 肩を約88°より深く倒した姿勢は、エラーなしに捨てられていた（#9）。
   - **お手本が浅いつかみになっていないか：** 爪がブロックに乗った回は、下ろす時間が普段の1.1秒から7.9〜9.1秒に延びていたので見分けられた（#25）。
   - 疑ったが原因ではなかったもの：上カメラの傾き（#29）。
5. **実機で直す道具（任意）**
   - 3,198円のゲームパッド（#19）。人が直す時間は1回中央13秒（#22）。
   - 成否の判定は Gemini Decision 1 で、168回約2円（#33）。
6. **欠けている情報と、試した記録を送る道**
   - 欠けている情報の表を置く。
   - /message へ「試した記録を送る」道を置く。送ってほしいのは、アームの機種・どの段まで行ったか・詰まった所。

### 束ねるログ（/record/… の一覧）
- **段1：** building-a-physical-ai-lab-at-home / openpi-remote-inference-first-run / pi05-libero-benchmark-first-run
- **段2：** pi05-mecharm-demo-to-inference / pi05-mecharm-lora-2000-steps / pi05-mecharm-4000-steps / drag-teach-waypoint-replay / teach-replay-19-demos / pi05-retrain-five-positions / pi05-learned-the-pauses / retrain-pi05-with-human-corrections / pi05-failures-traced-to-shallow-grasp-demos / reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos / even-ten-demos-per-spot-mecharm-270-reteaching / retrain-pi05-from-base-on-50-even-demos
- **段3：** pi05-mecharm-first-real-run / pi05-first-block-in-box / pi05-weak-position-d / pi05-even-demos-on-arm-misses-position-2 / pi05-position-2-miss-caused-by-camera-tilt / mecharm-270-drops-block-underpowered-adapter / mecharm-270-5a-adapter-stops-dropping-block / gamepad-moves-mecharm-270-pymycobot-version
- **直す道具：** gamepad-ready-to-correct-mecharm-270 / gamepad-fixes-mecharm-270-ai-in-13-seconds / gemini-decision-1-judge-mecharm-270-pick-and-place

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
ログの形式は変えないので、ログからこのページへは送りません。たどり着く道は次の5つです。

- **AI の答え：** 小見出しを、人が AI に聞く問いの形にする（例：「π0.5 に要る GPU は」）。表はテキストで置き、AI が読んで答えに引きやすくする。
- **検索：** 題名と小見出しに「π0.5 追加学習」「Runpod」「LIBERO」を入れる。
- **シリーズ：** 研究室シリーズのページの上の資料に、このページへの1行を置く。
- **今ある LP：** /gpu-buy-or-rent の「借りる」の節から、段1へ送る。
- **トップ：** 「シリーズ」の節に1行置くだけ。新しいキャッチコピーは足さない。
- **SNS：** LinkedIn で、見せ場1の対照表を画像にして載せる。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、どこから来たか
- 段ごとに、ログへ進んだ人の割合
- 「欠けている情報」の表まで読んだ割合（75%まで読んだ人）
- このページから /message へ進んだ数
- AI の利用者の依頼でこのページを読みに来た数（週ごと）

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
**人の表示（3か月で150件）**
- 効く理由：入口が5つ（AI・検索・シリーズ・今ある LP・SNS）あり、/gpu-buy-or-rent の読者が段1にそのまま合う。
- 効かないかもしれない理由：日本語で π0.5 を調べる人は少ないとみられる（推測）。

**ログへ進んだ人（表示した人の3割）**
- 効く理由：どの表の行にも、元のログへのリンクが付いている。
- 効かないかもしれない理由：このページ1枚で満足して、ログまで行かずに出ていくおそれがある。

**AI の利用者の依頼で読みに来た数（週3件以上）**
- 効く理由：問いの形の小見出しと、テキストの表は AI が引きやすい。
- 効かないかもしれない理由：AI が英語の資料を優先して読むかもしれない。

**AI のリンクから来た人（月1件以上）**
- 効く理由：答えの根拠として、このページへのリンクが付けば届く。
- 効かないかもしれない理由：AI が要約だけ返して、リンクを押されないことが多い。

**問い合わせ・相談（再現を試した人から1〜2件・いちばん重い）**
- 効く理由：「欠けている情報」の表を見せることで、第三者が確かめる理由を作れる。「試した記録を送る」道もこのページに置ける。
- 効かないかもしれない理由：送る手間が大きい。
```


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

```markdown
案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回目）

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

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

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

**こう直せばもっと強くなる**  
冒頭の1行目を、到達した実績と再現に残る確認に分けます。

> アームなしの最初の到達点は、借りたA40からπ0.5の予測を受け取ることです。研究室では、続いてLIBEROで20回中20回成功しました（Log#2・#3）。ここに手順の入口と必要な環境をまとめます。再現に必要な情報のうち、確認できていない項目も明記します。

「誰でも成功する」という約束より、「どこまで確かめられるかが分かる」という信頼を取れます。

### 2.【高】対照表が、途中の変更を飛ばして学習条件と実機結果を結び付けている

**弱い所**  
「5か所・loss 0.0037（#10）→15回中9回成功（#14）」の間には、停止時間を詰めた学習し直し（#11）と、AIに渡す肩の角度の変更（#12）があります。そのまま並べると、#10の条件で9/15を得たように読めます。

また、#34の5/5は位置5の結果で、#28の位置2の失敗が解決した証拠にはなりません。

**こう直せばもっと強くなる**  
表を「学習条件だけでは説明できなかった実機結果」にし、途中の変更を省略しません。

> 5か所19本・4,000ステップでlossは0.0037へ（#10）。その後、停止時間を詰めて学習し直し（#11）、AIに渡す肩の角度も変更（#12）。後の実機評価は3か所で15回中9回成功（#14）。この結果を#10の学習条件だけには結び付けられません。

電源の行は別に置きます。

> 位置5では、12V・2Aの日は3回中1回、12V・5Aへの交換後は5回中5回成功（#34）。位置2の問題が解決したかは、この結果では分かりません。

### 3.【高】「欠けている情報を見せる」と「再現に必要な情報がそろう」が混同されている

**弱い所**  
未記載の欄を見せるだけでは、主指標の判定条件③を満たしません。欠けている情報によって、第三者が再現可能性を確認できない場合もあります。末尾の表にまとめると、実行前に必要な不足まで見落とされます。

**こう直せばもっと強くなる**  
各段の入口に、次の形式の表を置きます。

| 必要な情報 | 現時点で分かること | 確認先・状態 |
|---|---|---|
| 利用したGPU | A40 | Log#2・#3 |
| openpi・Python・CUDA・LIBEROの版 | 要約には記載なし | 本文とコードで照合が要る |
| 実行手順 | 要約だけでは確認できない | 本文とコードで照合が要る |

その直下に明記します。

> 不足を公開することと、再現に必要な情報がそろうことは別です。本文とコードで照合しても確認できない項目は「ログにない（未記載）」と記します。

企画書にも、「公開前に本文とコードを照合し、段ごとの不足を確定する」を作業として加えてください。

### 4.【高】リンクは多いが、「まず何を開き、何ができたら次へ進むか」がない

**弱い所**  
表の各行にリンクを付けるだけでは、読者が実行順を自分で組み直す必要があります。これは「同じ手順で始められる」という目的にも、ログへ進む人3割という目標にも弱い設計です。

**こう直せばもっと強くなる**  
冒頭に、読む順番ではなく「今から行うこと」を置きます。

> **アームなしで始める**  
> 最初に開く：［Log#2：借りたA40でπ0.5を動かす］  
> 確かめること：Macから画像と指示文を送り、動きの数値を受け取れたか。  
> 次に開く：［Log#3：LIBEROで動かす］  
> 研究室での結果：20回中20回成功。自分の実行結果と分けて記録する。

段2も、「お手本作りは#8・#9」「50本での学習条件は#27」のように、最初のリンクを指定します。過去の条件比較は、その後に読める位置に置くと入口が明確になります。

### 5.【高】mechArm 270の実績が、自分のアームの必要量を見積もれる数字になっている

**弱い所**  
「本数・時間・費用の見積もり」「実例の数字で見積もれます」は、別のアームにも適用できるように読めます。ログにあるのはmechArm 270での実績で、他機種で必要なお手本の本数や学習時間ではありません。

**こう直せばもっと強くなる**  
得られるものの1文と、冒頭2行目を次のように変更します。

> アームなしで試す入口、mechArm 270で実際に使ったお手本・学習条件・時間・費用、そして自分のアームで確かめる4つの問いを、1枚にまとめます。

> mechArm 270では、深いつかみのお手本50本を使い、A40で3,000ステップの学習に6.2時間・約579円かかりました（Log#27）。あなたのアームでも同じ本数・時間・費用になるかは、ログでは確認していません。

数字の価値を残したまま、適用範囲を明確にできます。

### 6.【高】最も重い「試した人・試そうとした人からの連絡」への道が細い

**弱い所**  
末尾の「試した記録を送る」だけでは、試す前に不足情報で止まった人が対象だと分かりません。送る内容も自由記述に近く、作者自身が挙げる「送る手間が大きい」を解消できていません。

**こう直せばもっと強くなる**  
各段の末尾から、同じフォームへ送ります。文面は次のように具体化します。

> **ここまで試した記録・始める前に足りなかった情報を送る**  
> 成功していなくても、まだ実行していなくても送れます。次の項目をコピーして［メッセージフォーム］へ。  
> ・使った／使う予定のアーム（未所持でも可）  
> ・試した段、または始めたい段  
> ・できたこと／止まった所／足りなかった情報  
> ・分かる範囲の環境と版

「不足を見せれば連絡が来る」から、「不足に出会った時点で送れる」へ変わります。

### 7.【中】流入元は挙がっているが、そこから読者を動かす実際の文面がない

**弱い所**  
「シリーズに1行」「LPから送る」だけでは、誰が何を得るためにクリックするかが曖昧です。また、/gpu-buy-or-rentは表示21件で、読者との相性や送客効果はまだ判断できません。

**こう直せばもっと強くなる**  
設置場所とリンク文を企画書に書き切ります。

- **研究室シリーズ上部：**  
  「π0.5を始める方へ。アームなしの推論・シミュレーションから、お手本作り、実機で確かめる項目までをまとめました。」
- **/gpu-buy-or-rentの「借りる」の節：**  
  「借りたA40でπ0.5を動かした実例を見る。Macから予測を受け取る入口と、LIBEROでの実行結果をまとめています。」
- **LinkedInの投稿末尾：**  
  「この表の各結果に至る変更と元ログ、アームなしで始める入口を、1ページにまとめました。」

送客効果は「仮説。リンク経由の訪問と、その後のログへの移動で確認する」と記します。SNSには相談窓口を置かず、ページへの案内に留めます。

### 8.【中】測定項目が、依頼のゴールと最後まで対応していない

**弱い所**  
/messageへの移動は、再現を試した人からの連絡とは別です。AIのリンクから来た人の測定も抜けています。また、75%読了を「欠けている情報の表を読んだ」と扱うことはできません。

**こう直せばもっと強くなる**  
「公開後に見る数字」を、次の判定まで含めて書き換えます。

> ・ログへの移動：ページを表示した人のうち、いずれかのログへ進んだ人の割合。目標3割。段別の数字は改善箇所を探す補助にする。  
> ・連絡：フォームへの移動数に加え、実際に届いた連絡から「試した／試そうとした」を確認する。目標1〜2件。  
> ・AI経由：利用者の依頼による閲覧と、AIのリンクから来た人を分けて測る。  
> ・不足情報：75%読了率とは分け、表が表示されたかを測る。表示だけで内容を読んだとは判定しない。  
> ・最初の判断は人の表示30件時点。30件未満の数字では効果を言い切らない。3か月で30件未満かつ連絡0件なら、追加の手間を止め、ページを残す。

**守るべき尖り**

「lossが0.0030まで下がっても、爪は空を閉じた」という具体です。これが、学習条件の一覧を保存する理由と、実機で確かめる問いを読む理由をつないでいます。途中の変更と結果の対応を正確にしたうえで、この一文は冒頭に残してください。
```


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

```markdown
【採否】

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

**評者（案Cの作者）から**
- 1【高】「同じ手順で行けます」は言い過ぎ → **採る**。「最初に行き着く所」と「研究室で出た結果」に分けて書く。
- 2【高】対照表が途中の変更（#11・#12）を飛ばしている。#34 は位置2の解決ではない → **採る（事実の誤り）**。変更を1つも省かずに並べ直し、「位置2が解けたかは分からない」と書いた。
- 3【高】不足を見せることと、情報がそろうことは別 → **採る**。必要な情報の表を各段の頭に置く。公開前に本文とコードを照合する作業も入れた。
- 4【高】最初に何を開くかがない → **採る**。各節の頭に「最初に開くログ」と「確かめること」を置く。
- 5【高】mechArm 270 の実績を、ほかのアームの見積もりのように書いている → **採る（事実の誤り）**。数字は mechArm 270 の実績だとはっきり書く。
- 6【高】連絡への道が細い → **採る**。試す前に止まった人も送れること、送る項目、各段の末尾から送れることを書いた。
- 7【中】リンクの実際の文面がない → **採る**。/gpu-buy-or-rent は表示が21件なので、合うかどうかは判断できないと書き添えた。
- 8【中】見る数字がゴールと合っていない → **採る**。AI経由の2つを分け、「表が画面に出た」と「読んだ」も分けた。

そのほか自分で直した所：
- ページの名前にあった「34本」は、束ねる本数（26本）と違ったので消した。
- 「効いた原因」は言い過ぎなので「詰まった所」にした。
- #12 の「AI に渡す関節の値」を5つ目の問いとして足した。これはログにある事実で、初めて箱に入れた回の決め手だった。

---

【企画書】

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

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

### この人がこのページで得るもの（1文）
次の3つを1枚で見渡せて、次に開くログが分かります。アームなしで試す入口、mechArm 270 で実際に使ったお手本と学習の条件・時間・費用、自分のアームで確かめる5つの問いです。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**π0.5 を自分のアームで動かし始める**

1. アームがなくても始められます。最初に行き着くのは、借りた A40 から π0.5 の予測を Mac で受け取る所です（Log#2）。研究室では、続けて LIBERO で20回中20回成功しました（Log#3）。
2. mechArm 270 では、深いつかみのお手本50本で、A40 で3,000ステップ学習しました。かかったのは6.2時間・約579円です（Log#27）。あなたのアームで同じになるかは、ログでは確かめていません。
3. loss が 0.0030 まで下がっても、爪はブロックの奥で空を閉じました（Log#7）。学習の数字の外で詰まった所を、5つの問いにまとめました。

### 見せ場（このページにしかないもの。ログのどの事実か）
**見せ場1：学習の数字と実機の結果を並べた表（途中の変更も省かない）**

| 変えたこと | loss | 実機で起きたこと |
|---|---|---|
| 19本・2,000ステップ（#5） | 0.0054 | 爪がブロックに乗った（#6） |
| ステップを倍の4,000に（#7） | 0.0030 | 2回とも奥で空振り |
| 置き場所を5か所に（#10） | 0.0037 | 要約には記載なし |
| 止まる時間を詰めて学び直す（#11） | 要約には記載なし | 運んだが、箱の外で離した |
| 学び直さず、AI に渡す肩の角度を直前の目標にする（#12） | 学習なし | 初めて箱に入れた |
| 3か所に5回ずつ置いて測る（#14） | ― | 15回中9回（C 5/5・E 3/5・D 1/5） |
| 人が直した5回で、続けて1,500ステップ（#17） | 要約には記載なし | 成功6回は、すべて人の直しつき（#18） |
| 深いお手本50本で、一から3,000ステップ（#27） | 0.0036 | 位置1は3回とも直しなし。位置2は4回とも届かず（#28） |
| 電源を 12V・2A から 5A に替える（#34） | ― | 位置5で、3回中1回から5回中5回に |

表の下に置く文：「表の後半で手を入れたのは、AI に渡す角度・お手本の深さ・電源で、どれも loss の外にあります。電源を替えて位置2も解けたかは、まだ分かりません。」

**見せ場2：段ごとの「必要な情報」の表（足りない欄も空けたまま見せる）**

| 必要な情報 | 今分かること | 状態 |
|---|---|---|
| GPU | Runpod の A40 | Log#2・#3 |
| openpi・Python・CUDA・LIBERO の版 | 要約には記載なし | 本文とコードで照合が要る |

- 公開前の作業として、本文とコードを照合し、段ごとに足りない情報を確定させる。照合しても見つからない項目は「ログにない（未記載）」と書く。
- 表の下に置く文：「足りない情報を見せることと、再現に要る情報がそろうことは別です。」

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
節の名前は、AI に聞く問いの形にします。各節の頭には「最初に開くログ」と見せ場2の表を、末尾にはフォームへの道を置きます。

1. **アームなしで π0.5 を動かすには**（段1）
   - 最初に Log#2 を開く。確かめるのは、Mac から画像と指示文を送って、動きの数値を受け取れたか。研究室の値は、推論が平均97ms、往復391ms、費用0.34ドル。
   - 次に Log#3 を開く。研究室の結果は20回中20回成功。自分の結果とは分けて記録する。GPU メモリの値は、要約には記載なし（本文とコードで照合が要る）。
2. **自分のアームでお手本をどう集めるか**（段2）
   - 最初に開くのは Log#8・#9。手で教えた動きを再生しながら録る方法で、5か所から19本集めた。
   - π0.5 は、お手本の中の止まっている時間まで覚えた（#11）。
   - 浅いつかみが30本中7本あった（#23）。
   - 位置ごとに10本、合わせて50本にそろえた（#26）。
3. **学習の条件と費用は**（段2）
   - 最初に開くのは Log#27。
   - 条件の移り変わり：2本・200ステップ（#4）→ 19本・2,000ステップ（#5）→ 4,000ステップ（#7・#10）→ 50本・3,000ステップ（#27）。
   - GPU の空き待ちで、起動まで約4時間半かかった日もある（#10）。
   - そのあとに見せ場1を置く。
4. **loss が下がっても動かない時、アームで何を確かめるか**（段3）
   - **電源は足りているか：** 本体は40W を求めるのに、つないでいたのは24W だった（#30）。5A に替えると、教えた動きの再生も7回すべて成功した（#34）。
   - **制御ライブラリの版で、指令が遅れていないか：** pymycobot 4.0.4 では1回の指令に1.6秒かかった。2.9.6 に戻すと約0.02秒（#20）。
   - **動ける範囲の外の命令が、黙って捨てられていないか：** 肩を約88°より深く倒した姿勢は、エラーなしに捨てられていた（#9）。
   - **お手本が浅いつかみになっていないか：** 爪がブロックに乗った回は、下ろす時間が普段の1.1秒から7.9〜9.1秒に延びた（#25）。
   - **AI に渡す関節の値は何か：** 肩の角度を直前の目標に変えると、毎回約2°足りずに箱に当てていた動きが直った（#12）。
   - 疑ったが原因ではなかったもの：上カメラの傾き（#29）。
5. **失敗を人が直す道具は**（なくてもよい）
   - 3,198円のゲームパッド（#19）。人が直す時間は1回中央14.5秒で、キーボードの43.2秒の約3分の1（#32）。
   - 成否の判定は Gemini Decision 1 で、56本すべて見分けた。ただし、つかみの深さは見分けられない（#33）。
6. **試した記録・足りなかった情報を送る**
   - 置く文：「成功していなくても、まだ試していなくても送れます。使った（使う予定の）アーム、試した段、止まった所や足りなかった情報、分かる範囲の版を、［メッセージフォーム］から送ってください。」

### 束ねるログ（/record/… の一覧）
- **段1：** building-a-physical-ai-lab-at-home / openpi-remote-inference-first-run / pi05-libero-benchmark-first-run
- **段2：** pi05-mecharm-demo-to-inference / pi05-mecharm-lora-2000-steps / pi05-mecharm-4000-steps / drag-teach-waypoint-replay / teach-replay-19-demos / pi05-retrain-five-positions / pi05-learned-the-pauses / retrain-pi05-with-human-corrections / pi05-failures-traced-to-shallow-grasp-demos / reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos / even-ten-demos-per-spot-mecharm-270-reteaching / retrain-pi05-from-base-on-50-even-demos
- **段3：** pi05-mecharm-first-real-run / pi05-first-block-in-box / pi05-weak-position-d / retrained-pi05-still-needs-human-corrections / pi05-even-demos-on-arm-misses-position-2 / pi05-position-2-miss-caused-by-camera-tilt / mecharm-270-drops-block-underpowered-adapter / mecharm-270-5a-adapter-stops-dropping-block / gamepad-moves-mecharm-270-pymycobot-version
- **直す道具：** gamepad-ready-to-correct-mecharm-270 / measure-mecharm-270-recovery-time-decide-what-to-cut / gemini-decision-1-judge-mecharm-270-pick-and-place

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
ログの形式は変えないので、ログからこのページへは送れません。次の道から来てもらいます。どの道の効き目も仮説で、リンクから来た数と、その後ログへ進んだ数で確かめます。

- **AI の答え・検索：** 節の名前を問いの形にし、表はテキストで置く。題名に「π0.5」「追加学習」「Runpod」「LIBERO」を入れる。
- **研究室シリーズのページの上部：**「π0.5 を始める方へ。アームなしの入口から、お手本作り、実機で確かめる項目までをまとめました。」
- **/gpu-buy-or-rent の「借りる」の節：**「借りた A40 で π0.5 を動かした実例を見る。」（この LP は表示21件なので、読者と合うかは判断できない）
- **トップ：** 「シリーズ」の節に1行置くだけ。
- **LinkedIn：** 見せ場1を画像にして載せる。投稿の末尾に「各結果の元ログと、アームなしで始める入口を1ページにまとめました」と書く。相談の窓口は置かない。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、どこから来たか
- ログへ進んだ人：表示した人のうち、どれかのログへ進んだ割合（目標は3割）。段ごとの数は、直す所を探すのに使う
- 連絡：フォームへ進んだ数とは分ける。届いた連絡のうち「試した／試そうとした」ものを数える
- AI：利用者の依頼で読みに来た数と、AI のリンクから来た人は分けて数える
- 見せ場2の表が画面に出た数。画面に出たことと、読んだことは分けて扱う

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
**人の表示（3か月で150件）**
- 効く理由：来る道が5つある。
- 効かないかもしれない理由：日本語で π0.5 を調べる人は少ないとみられる（推測）。

**ログへ進んだ人（表示した人の3割）**
- 効く理由：各節に「最初に開くログ」があり、表のどの行もログへつながる。
- 効かないかもしれない理由：表だけ見て満足されるおそれがある。

**AI の利用者の依頼で読みに来た数（週3件以上）**
- 効く理由：問いの形の節名とテキストの表は、AI が引きやすい。
- 効かないかもしれない理由：AI が英語の資料を先に読むかもしれない。

**AI のリンクから来た人（月1件以上）**
- 効く理由：答えの根拠として、このページへのリンクが出れば届く。
- 効かないかもしれない理由：AI が要約だけ返して、リンクは押されにくい。

**問い合わせ・相談（再現を試した人から1〜2件・いちばん重い）**
- 効く理由：試す前に止まった人も送れて、各段の末尾から送れる。
- 効かないかもしれない理由：版を照合しないまま公開すると、試す前に離れてしまう。
```


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

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

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

### この人がこのページで得るもの（1文）
次の3つを1枚で見渡せて、次に開くログが分かります。アームなしで試す入口、mechArm 270 で実際に使ったお手本と学習の条件・時間・費用、自分のアームで確かめる5つの問いです。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**π0.5 を自分のアームで動かし始める**

1. アームがなくても始められます。最初に行き着くのは、借りた A40 から π0.5 の予測を Mac で受け取る所です（Log#2）。研究室では、続けて LIBERO で20回中20回成功しました（Log#3）。
2. mechArm 270 では、深いつかみのお手本50本で、A40 で3,000ステップ学習しました。かかったのは6.2時間・約579円です（Log#27）。あなたのアームで同じになるかは、ログでは確かめていません。
3. loss が 0.0030 まで下がっても、爪はブロックの奥で空を閉じました（Log#7）。学習の数字の外で詰まった所を、5つの問いにまとめました。

### 見せ場（このページにしかないもの。ログのどの事実か）
**見せ場1：学習の数字と実機の結果を並べた表（途中の変更も省かない）**

| 変えたこと | loss | 実機で起きたこと |
|---|---|---|
| 19本・2,000ステップ（#5） | 0.0054 | 爪がブロックに乗った（#6） |
| ステップを倍の4,000に（#7） | 0.0030 | 2回とも奥で空振り |
| 置き場所を5か所に（#10） | 0.0037 | 要約には記載なし |
| 止まる時間を詰めて学び直す（#11） | 要約には記載なし | 運んだが、箱の外で離した |
| 学び直さず、AI に渡す肩の角度を直前の目標にする（#12） | 学習なし | 初めて箱に入れた |
| 3か所に5回ずつ置いて測る（#14） | ― | 15回中9回（C 5/5・E 3/5・D 1/5） |
| 人が直した5回で、続けて1,500ステップ（#17） | 要約には記載なし | 成功6回は、すべて人の直しつき（#18） |
| 深いお手本50本で、一から3,000ステップ（#27） | 0.0036 | 位置1は3回とも直しなし。位置2は4回とも届かず（#28） |
| 電源を 12V・2A から 5A に替える（#34） | ― | 位置5で、3回中1回から5回中5回に |

表の下に置く文：「表の後半で手を入れたのは、AI に渡す角度・お手本の深さ・電源で、どれも loss の外にあります。電源を替えて位置2も解けたかは、まだ分かりません。」

**見せ場2：段ごとの「必要な情報」の表（足りない欄も空けたまま見せる）**

| 必要な情報 | 今分かること | 状態 |
|---|---|---|
| GPU | Runpod の A40 | Log#2・#3 |
| openpi・Python・CUDA・LIBERO の版 | 要約には記載なし | 本文とコードで照合が要る |

- 公開前の作業として、本文とコードを照合し、段ごとに足りない情報を確定させる。照合しても見つからない項目は「ログにない（未記載）」と書く。
- 表の下に置く文：「足りない情報を見せることと、再現に要る情報がそろうことは別です。」

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
節の名前は、AI に聞く問いの形にします。各節の頭には「最初に開くログ」と見せ場2の表を、末尾にはフォームへの道を置きます。

1. **アームなしで π0.5 を動かすには**（段1）
   - 最初に Log#2 を開く。確かめるのは、Mac から画像と指示文を送って、動きの数値を受け取れたか。研究室の値は、推論が平均97ms、往復391ms、費用0.34ドル。
   - 次に Log#3 を開く。研究室の結果は20回中20回成功。自分の結果とは分けて記録する。GPU メモリの値は、要約には記載なし（本文とコードで照合が要る）。
2. **自分のアームでお手本をどう集めるか**（段2）
   - 最初に開くのは Log#8・#9。手で教えた動きを再生しながら録る方法で、5か所から19本集めた。
   - π0.5 は、お手本の中の止まっている時間まで覚えた（#11）。
   - 浅いつかみが30本中7本あった（#23）。
   - 位置ごとに10本、合わせて50本にそろえた（#26）。
3. **学習の条件と費用は**（段2）
   - 最初に開くのは Log#27。
   - 条件の移り変わり：2本・200ステップ（#4）→ 19本・2,000ステップ（#5）→ 4,000ステップ（#7・#10）→ 50本・3,000ステップ（#27）。
   - GPU の空き待ちで、起動まで約4時間半かかった日もある（#10）。
   - そのあとに見せ場1を置く。
4. **loss が下がっても動かない時、アームで何を確かめるか**（段3）
   - **電源は足りているか：** 本体は40W を求めるのに、つないでいたのは24W だった（#30）。5A に替えると、教えた動きの再生も7回すべて成功した（#34）。
   - **制御ライブラリの版で、指令が遅れていないか：** pymycobot 4.0.4 では1回の指令に1.6秒かかった。2.9.6 に戻すと約0.02秒（#20）。
   - **動ける範囲の外の命令が、黙って捨てられていないか：** 肩を約88°より深く倒した姿勢は、エラーなしに捨てられていた（#9）。
   - **お手本が浅いつかみになっていないか：** 爪がブロックに乗った回は、下ろす時間が普段の1.1秒から7.9〜9.1秒に延びた（#25）。
   - **AI に渡す関節の値は何か：** 肩の角度を直前の目標に変えると、毎回約2°足りずに箱に当てていた動きが直った（#12）。
   - 疑ったが原因ではなかったもの：上カメラの傾き（#29）。
5. **失敗を人が直す道具は**（なくてもよい）
   - 3,198円のゲームパッド（#19）。人が直す時間は1回中央14.5秒で、キーボードの43.2秒の約3分の1（#32）。
   - 成否の判定は Gemini Decision 1 で、56本すべて見分けた。ただし、つかみの深さは見分けられない（#33）。
6. **試した記録・足りなかった情報を送る**
   - 置く文：「成功していなくても、まだ試していなくても送れます。使った（使う予定の）アーム、試した段、止まった所や足りなかった情報、分かる範囲の版を、［メッセージフォーム］から送ってください。」

### 束ねるログ（/record/… の一覧）
- **段1：** building-a-physical-ai-lab-at-home / openpi-remote-inference-first-run / pi05-libero-benchmark-first-run
- **段2：** pi05-mecharm-demo-to-inference / pi05-mecharm-lora-2000-steps / pi05-mecharm-4000-steps / drag-teach-waypoint-replay / teach-replay-19-demos / pi05-retrain-five-positions / pi05-learned-the-pauses / retrain-pi05-with-human-corrections / pi05-failures-traced-to-shallow-grasp-demos / reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos / even-ten-demos-per-spot-mecharm-270-reteaching / retrain-pi05-from-base-on-50-even-demos
- **段3：** pi05-mecharm-first-real-run / pi05-first-block-in-box / pi05-weak-position-d / retrained-pi05-still-needs-human-corrections / pi05-even-demos-on-arm-misses-position-2 / pi05-position-2-miss-caused-by-camera-tilt / mecharm-270-drops-block-underpowered-adapter / mecharm-270-5a-adapter-stops-dropping-block / gamepad-moves-mecharm-270-pymycobot-version
- **直す道具：** gamepad-ready-to-correct-mecharm-270 / measure-mecharm-270-recovery-time-decide-what-to-cut / gemini-decision-1-judge-mecharm-270-pick-and-place

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
ログの形式は変えないので、ログからこのページへは送れません。次の道から来てもらいます。どの道の効き目も仮説で、リンクから来た数と、その後ログへ進んだ数で確かめます。

- **AI の答え・検索：** 節の名前を問いの形にし、表はテキストで置く。題名に「π0.5」「追加学習」「Runpod」「LIBERO」を入れる。
- **研究室シリーズのページの上部：**「π0.5 を始める方へ。アームなしの入口から、お手本作り、実機で確かめる項目までをまとめました。」
- **/gpu-buy-or-rent の「借りる」の節：**「借りた A40 で π0.5 を動かした実例を見る。」（この LP は表示21件なので、読者と合うかは判断できない）
- **トップ：** 「シリーズ」の節に1行置くだけ。
- **LinkedIn：** 見せ場1を画像にして載せる。投稿の末尾に「各結果の元ログと、アームなしで始める入口を1ページにまとめました」と書く。相談の窓口は置かない。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、どこから来たか
- ログへ進んだ人：表示した人のうち、どれかのログへ進んだ割合（目標は3割）。段ごとの数は、直す所を探すのに使う
- 連絡：フォームへ進んだ数とは分ける。届いた連絡のうち「試した／試そうとした」ものを数える
- AI：利用者の依頼で読みに来た数と、AI のリンクから来た人は分けて数える
- 見せ場2の表が画面に出た数。画面に出たことと、読んだことは分けて扱う

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
**人の表示（3か月で150件）**
- 効く理由：来る道が5つある。
- 効かないかもしれない理由：日本語で π0.5 を調べる人は少ないとみられる（推測）。

**ログへ進んだ人（表示した人の3割）**
- 効く理由：各節に「最初に開くログ」があり、表のどの行もログへつながる。
- 効かないかもしれない理由：表だけ見て満足されるおそれがある。

**AI の利用者の依頼で読みに来た数（週3件以上）**
- 効く理由：問いの形の節名とテキストの表は、AI が引きやすい。
- 効かないかもしれない理由：AI が英語の資料を先に読むかもしれない。

**AI のリンクから来た人（月1件以上）**
- 効く理由：答えの根拠として、このページへのリンクが出れば届く。
- 効かないかもしれない理由：AI が要約だけ返して、リンクは押されにくい。

**問い合わせ・相談（再現を試した人から1〜2件・いちばん重い）**
- 効く理由：試す前に止まった人も送れて、各段の末尾から送れる。
- 効かないかもしれない理由：版を照合しないまま公開すると、試す前に離れてしまう。
```


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

```markdown
案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回目）

```markdown
案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のいちばん強い所です。「学習できた」という数字だけでは始め方を判断できない読者に、次に何を確かめるべきかを実例で渡せます。表を削るのではなく、各行の「何ができたか」の範囲を厳密にして残してください。
```


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

```markdown
【採否】

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

**評者（案C）から**
- 1 再現の確認表（5列）：**採る**。主指標の判定条件②③を、第三者が確かめられる形になる。
- 2 段1を「実行→照合」の順に：**採る**。20回中20回は研究室の結果であり、合格の条件ではないことをはっきりさせる。
- 3 段2の冒頭に境目を書く：**採る**。他のアームについてはログにないと示す一文になる。
- 4 #28 と表の下の文：**採る（事実の誤り）**。要約にあるのは「つかめた」まで。学習で直したのか、実機の側で直したのかも分けて書く。電源の行は別の日の試行と明記する。
- 5 pymycobot：**採る（事実の誤り）**。版を読んでいたのは Pi の daemon。版の推奨ではなく、確かめ方を示す問いに直す。
- 6 最初の画面を入口に：**一部採る**。3行を3つの入口にし、各行に事実を1つずつ置く。loss 0.0030 で空振りした対比は3行目に残す。
- 7 記録の枠：**採る**。そのまま保存でき、フォームにも写せる「試した記録」の型になる。

---

【企画書】

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

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

### この人がこのページで得るもの（1文）
アームなしの入口、mechArm 270 で使ったお手本と学習の条件・費用、自分のアームで確かめる5つの問いを1枚で見渡せて、次に開くログと、そこで何を確かめればよいかが分かります。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**π0.5 を自分のアームで動かし始める**

1. **アームなしで試す：** 借りた A40 から、π0.5 の動きの数値を Mac で受け取ります（Log#2）。機材に左右されないので、ここを最初の一歩にしました。［段1へ］
2. **自分のアームで学習する：** mechArm 270 では、深いつかみのお手本50本で、A40 で3,000ステップ学習しました。かかったのは6.2時間・約579円です（Log#27）。あなたのアームで同じになるかは、確かめていません。［段2へ］
3. **実機で止まった所を確かめる：** loss が 0.0030 まで下がっても、爪はブロックの奥で空を閉じました（Log#7）。学習の数字の外で詰まった所を、5つの問いにまとめました。［段3へ］

### 見せ場（このページにしかないもの。ログのどの事実か）
**見せ場1：学習の数字と実機の結果を並べた表（途中の変更も省かない）**

| 変えたこと | loss | 実機で起きたこと |
|---|---|---|
| 19本・2,000ステップ（#5） | 0.0054 | 爪がブロックに乗った（#6） |
| ステップを倍の4,000に（#7） | 0.0030 | 2回とも奥で空振り |
| 置き場所を5か所に（#10） | 0.0037 | 要約には記載なし |
| 止まる時間を詰めて学び直す（#11） | 要約には記載なし | 運んだが、持ち上げずに箱の外で離した |
| 学び直さず、AI に渡す肩の角度を直前の目標にする（#12） | 学習なし | 初めて箱に入れた |
| 3か所に5回ずつ置いて測る（#14） | ― | 15回中9回（位置C 5/5・位置E 3/5・腕を伸ばしきる位置D 1/5） |
| 人が直した5回で、続けて1,500ステップ（#17） | 要約には記載なし | 9回中、成功した6回はすべて人の直しつき（#18） |
| 深いお手本50本で、一から3,000ステップ（#27） | 0.0036 | 位置1は3回とも直しなしでつかめた。位置2は4回ともつかむ姿勢まで届かず（#28） |
| 電源を 12V・2A から 5A に替える（#30・#34） | ― | 位置5：2A の日は3回中1回、5A の日は5回中5回 |

表の下に置く文：「loss が下がっても、つかむ・運ぶ・箱に入れることは、実機で別に確かめる必要がありました。お手本を作り直して学習した回もあれば、学習せず、AI に渡す角度や電源を変えた回もあります。電源を替えたあと位置2も解けたかは、要約には記載なしです。」

**見せ場2：段ごとの再現確認表（足りない欄も空けたまま見せる）**

| 実行すること | 環境・依存関係と版 | 手順・コードの場所 | 入力と、確かめる出力 | 照合の状況 |
|---|---|---|---|---|
| Mac から π0.5 に画像と指示文を送る | Runpod の A40。openpi・Python・CUDA の版は要約には記載なし | Log#2 の本文・コード | 画像と指示文 → 動きの数値 | 本文とコードで照合が要る |
| LIBERO で「黒いボウルを拾って皿に置く」 | A40。LIBERO の版は要約には記載なし | Log#3 | 20回の成否、GPU メモリ（値は要約には記載なし） | 本文とコードで照合が要る |

- 表の下に置く文：「この段で確かめられた情報と、まだ欠けている情報を並べています。情報が欠けている段は、同じ手順で再現できる環境としては数えていません。版が分かった方は、下の記録の枠から知らせてください。」
- 公開前の作業として、本文とコードを照合する。照合しても見つからない項目は「ログにない（未記載）」と書く。

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
節の名前は問いの形にします。各段の頭には見せ場2のその段の行を、末尾には記録の枠を置きます。

1. **アームなしで π0.5 を動かすには**（段1）
   - **最初に試す：** Mac から画像と指示文を送り、動きの数値を受け取る（#2）。研究室の値は、推論が平均97ms、往復391ms、費用0.34ドル。
   - **次に試す：** LIBERO で同じ作業を動かす（#3）。研究室では20回中20回成功した。自分の試行数と成功数は、この結果とは分けて残す。
2. **自分のアームでお手本をどう集めるか**（段2）
   - 冒頭に置く文：「ここからは mechArm 270 の実例です。考え方は使えますが、同じコードや設定が使えるかは確かめていません。アームごとに置き換える所と、モデルへ渡すデータの形式・変換の手順は、要約には記載なしです。」
   - 事実の流れ：手で教えた動きを再生しながら録り、5か所から19本集めた（#8・#9）→ π0.5 は止まっている時間まで覚えた（#11）→ 浅いつかみが30本中7本あった（#23）→ ゲームパッドで教え直し、5か所10本ずつにそろえた（#25・#26）。
3. **学習の条件と費用は**（段2）
   - 条件の移り変わり：2本・200ステップ（#4）→ 19本・2,000ステップ（#5）→ 4,000ステップ（#7・#10）→ 50本・3,000ステップ、6.2時間・約579円（#27）。
   - GPU の空き待ちで、起動まで約4時間半かかった日もある（#10）。
   - そのあとに見せ場1を置く。
4. **loss は下がったのに実機で動かない時、アームの何を疑うか**（段3）
   - 導入の文：「詰まった所は、学習の数字の外にありました。mechArm 270 の実例を、どのアームでも確かめられる問いにしました。」
   - **電源は足りているか：** 本体は40W を求めるのに、つないでいたのは24W だった（#30）。5A に替えると、教えた動きの再生も7回すべて成功した（#34）。
   - **指令を送る処理は、どの版のライブラリを読んでいるか：** Pi の daemon が pymycobot 4.0.4 を読んでいて、1回の指令に1.6秒かかった。2.9.6 に戻すと送信は約0.02秒になった（#20）。版の番号をまねるのではなく、指令にかかる時間を測って確かめる。
   - **動ける範囲の外の命令が、黙って捨てられていないか：** 肩を約88°より深く倒した姿勢は、エラーなしに捨てられていた（#9）。
   - **お手本が浅いつかみになっていないか：** 30本中7本が浅かった（#23）。爪が乗った回は、下ろす時間が普段の1.1秒から7.9〜9.1秒に延びた（#25）。
   - **AI に渡す関節の値は何か：** 肩の角度を直前の目標に変えると、毎回約2°足りなかった動きが直った（#12）。
   - 疑ったが原因ではなかったもの：上カメラの傾き（#29）。
5. **失敗を人が直す道具は**（なくてもよい）
   - 3,198円のゲームパッド（#19）。人が直す時間は1回中央14.5秒で、キーボードでは43.2秒だった（#32）。
   - 成否の判定は Gemini Decision 1 で、56本すべて見分けた。ただし、つかみの深さは見分けられない（#33）。
6. **試した記録・足りなかった情報を送る**
   - 記録の枠：試した段と開いたログ／使った環境とアーム（未購入でも可）／分かる範囲の依存関係と版／できた所と止まった所／手順に足りなかった情報。手元に保存でき、そのままフォームへ写せる。
   - 置く文：「このページは、誰でも同じ環境から Physical AI 研究を始められる状態を増やすためにあります。空欄があっても、試す前に止まっていても送れます。失敗の記録も、次の人の再現の土台になります。［メッセージフォーム］」

### 束ねるログ（/record/… の一覧）
URL は、依頼のログ一覧で各 Log# に付いている /record/… のとおりです。
- **段1：** Log#1〜3
- **段2：** Log#4・5・7〜11・17・23・25〜27
- **段3：** Log#6・12・14・18・20・28〜30・34
- **直す道具：** Log#19・32・33

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
ログからこのページへは送れません。来る道はどれも仮説で、リンクから来た数と、そのあとログへ進んだ数で確かめます。

- **AI の答え・検索：** 節の名前を問いの形にし、表はテキストで置く。題名に「π0.5」「追加学習」「Runpod」「LIBERO」を入れる。
- **研究室シリーズのページの上部：** 「π0.5 を始める方へ。アームなしの入口から、実機で確かめる項目までをまとめました。」
- **/gpu-buy-or-rent の「借りる」の節：** 「借りた A40 で π0.5 を動かした実例を見る。」（この LP は表示21件なので、読者と合うかは判断できない）
- **トップ：** 「シリーズ」の節に1行置くだけ。
- **LinkedIn：** 見せ場1を画像にして載せる。相談の窓口は置かない。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、どこから来たか
- ログへ進んだ割合（目標は3割）と、段ごとの内訳
- 届いた連絡のうち「試した／試そうとした」もの。記録の枠の項目が埋まっていた数も見る
- AI の利用者の依頼で読みに来た数と、AI のリンクから来た人は分けて数える
- 見せ場2が画面に出た数。画面に出たことと、読んだことは分けて扱う

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
**人の表示（3か月で150件）**
- 効く理由：来る道が5つある。
- 効かないかもしれない理由：日本語で π0.5 を調べる人は少ないとみられる（推測）。

**ログへ進んだ人（表示した人の3割）**
- 効く理由：最初の画面の3行と、表のどの行もログにつながっている。
- 効かないかもしれない理由：表だけ見て満足されるおそれがある。

**AI の利用者の依頼で読みに来た数（週3件以上）**
- 効く理由：問いの形の節名とテキストの表は、AI が引きやすい。
- 効かないかもしれない理由：AI が英語の資料を先に読むかもしれない。

**AI のリンクから来た人（月1件以上）**
- 効く理由：答えの根拠としてリンクが出れば届く。
- 効かないかもしれない理由：AI が要約だけ返して、リンクは押されにくい。

**問い合わせ・相談（再現を試した人から1〜2件・いちばん重い）**
- 効く理由：記録の枠があるので、試す前に止まった人も送れる。欠けている版をはっきり見せることが、送る理由にもなる。
- 効かないかもしれない理由：照合する前に公開すると、試す前に離れてしまう。
```


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

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

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

### この人がこのページで得るもの（1文）
アームなしの入口、mechArm 270 で使ったお手本と学習の条件・費用、自分のアームで確かめる5つの問いを1枚で見渡せて、次に開くログと、そこで何を確かめればよいかが分かります。

### 最初の画面（見出しと、その下の3行。実際の文面で書く）
**π0.5 を自分のアームで動かし始める**

1. **アームなしで試す：** 借りた A40 から、π0.5 の動きの数値を Mac で受け取ります（Log#2）。機材に左右されないので、ここを最初の一歩にしました。［段1へ］
2. **自分のアームで学習する：** mechArm 270 では、深いつかみのお手本50本で、A40 で3,000ステップ学習しました。かかったのは6.2時間・約579円です（Log#27）。あなたのアームで同じになるかは、確かめていません。［段2へ］
3. **実機で止まった所を確かめる：** loss が 0.0030 まで下がっても、爪はブロックの奥で空を閉じました（Log#7）。学習の数字の外で詰まった所を、5つの問いにまとめました。［段3へ］

### 見せ場（このページにしかないもの。ログのどの事実か）
**見せ場1：学習の数字と実機の結果を並べた表（途中の変更も省かない）**

| 変えたこと | loss | 実機で起きたこと |
|---|---|---|
| 19本・2,000ステップ（#5） | 0.0054 | 爪がブロックに乗った（#6） |
| ステップを倍の4,000に（#7） | 0.0030 | 2回とも奥で空振り |
| 置き場所を5か所に（#10） | 0.0037 | 要約には記載なし |
| 止まる時間を詰めて学び直す（#11） | 要約には記載なし | 運んだが、持ち上げずに箱の外で離した |
| 学び直さず、AI に渡す肩の角度を直前の目標にする（#12） | 学習なし | 初めて箱に入れた |
| 3か所に5回ずつ置いて測る（#14） | ― | 15回中9回（位置C 5/5・位置E 3/5・腕を伸ばしきる位置D 1/5） |
| 人が直した5回で、続けて1,500ステップ（#17） | 要約には記載なし | 9回中、成功した6回はすべて人の直しつき（#18） |
| 深いお手本50本で、一から3,000ステップ（#27） | 0.0036 | 位置1は3回とも直しなしでつかめた。位置2は4回ともつかむ姿勢まで届かず（#28） |
| 電源を 12V・2A から 5A に替える（#30・#34） | ― | 位置5：2A の日は3回中1回、5A の日は5回中5回 |

表の下に置く文：「loss が下がっても、つかむ・運ぶ・箱に入れることは、実機で別に確かめる必要がありました。お手本を作り直して学習した回もあれば、学習せず、AI に渡す角度や電源を変えた回もあります。電源を替えたあと位置2も解けたかは、要約には記載なしです。」

**見せ場2：段ごとの再現確認表（足りない欄も空けたまま見せる）**

| 実行すること | 環境・依存関係と版 | 手順・コードの場所 | 入力と、確かめる出力 | 照合の状況 |
|---|---|---|---|---|
| Mac から π0.5 に画像と指示文を送る | Runpod の A40。openpi・Python・CUDA の版は要約には記載なし | Log#2 の本文・コード | 画像と指示文 → 動きの数値 | 本文とコードで照合が要る |
| LIBERO で「黒いボウルを拾って皿に置く」 | A40。LIBERO の版は要約には記載なし | Log#3 | 20回の成否、GPU メモリ（値は要約には記載なし） | 本文とコードで照合が要る |

- 表の下に置く文：「この段で確かめられた情報と、まだ欠けている情報を並べています。情報が欠けている段は、同じ手順で再現できる環境としては数えていません。版が分かった方は、下の記録の枠から知らせてください。」
- 公開前の作業として、本文とコードを照合する。照合しても見つからない項目は「ログにない（未記載）」と書く。

### 構成（4〜6節。節ごとに、何を書くかと、使うログ /record/… とその中の事実）
節の名前は問いの形にします。各段の頭には見せ場2のその段の行を、末尾には記録の枠を置きます。

1. **アームなしで π0.5 を動かすには**（段1）
   - **最初に試す：** Mac から画像と指示文を送り、動きの数値を受け取る（#2）。研究室の値は、推論が平均97ms、往復391ms、費用0.34ドル。
   - **次に試す：** LIBERO で同じ作業を動かす（#3）。研究室では20回中20回成功した。自分の試行数と成功数は、この結果とは分けて残す。
2. **自分のアームでお手本をどう集めるか**（段2）
   - 冒頭に置く文：「ここからは mechArm 270 の実例です。考え方は使えますが、同じコードや設定が使えるかは確かめていません。アームごとに置き換える所と、モデルへ渡すデータの形式・変換の手順は、要約には記載なしです。」
   - 事実の流れ：手で教えた動きを再生しながら録り、5か所から19本集めた（#8・#9）→ π0.5 は止まっている時間まで覚えた（#11）→ 浅いつかみが30本中7本あった（#23）→ ゲームパッドで教え直し、5か所10本ずつにそろえた（#25・#26）。
3. **学習の条件と費用は**（段2）
   - 条件の移り変わり：2本・200ステップ（#4）→ 19本・2,000ステップ（#5）→ 4,000ステップ（#7・#10）→ 50本・3,000ステップ、6.2時間・約579円（#27）。
   - GPU の空き待ちで、起動まで約4時間半かかった日もある（#10）。
   - そのあとに見せ場1を置く。
4. **loss は下がったのに実機で動かない時、アームの何を疑うか**（段3）
   - 導入の文：「詰まった所は、学習の数字の外にありました。mechArm 270 の実例を、どのアームでも確かめられる問いにしました。」
   - **電源は足りているか：** 本体は40W を求めるのに、つないでいたのは24W だった（#30）。5A に替えると、教えた動きの再生も7回すべて成功した（#34）。
   - **指令を送る処理は、どの版のライブラリを読んでいるか：** Pi の daemon が pymycobot 4.0.4 を読んでいて、1回の指令に1.6秒かかった。2.9.6 に戻すと送信は約0.02秒になった（#20）。版の番号をまねるのではなく、指令にかかる時間を測って確かめる。
   - **動ける範囲の外の命令が、黙って捨てられていないか：** 肩を約88°より深く倒した姿勢は、エラーなしに捨てられていた（#9）。
   - **お手本が浅いつかみになっていないか：** 30本中7本が浅かった（#23）。爪が乗った回は、下ろす時間が普段の1.1秒から7.9〜9.1秒に延びた（#25）。
   - **AI に渡す関節の値は何か：** 肩の角度を直前の目標に変えると、毎回約2°足りなかった動きが直った（#12）。
   - 疑ったが原因ではなかったもの：上カメラの傾き（#29）。
5. **失敗を人が直す道具は**（なくてもよい）
   - 3,198円のゲームパッド（#19）。人が直す時間は1回中央14.5秒で、キーボードでは43.2秒だった（#32）。
   - 成否の判定は Gemini Decision 1 で、56本すべて見分けた。ただし、つかみの深さは見分けられない（#33）。
6. **試した記録・足りなかった情報を送る**
   - 記録の枠：試した段と開いたログ／使った環境とアーム（未購入でも可）／分かる範囲の依存関係と版／できた所と止まった所／手順に足りなかった情報。手元に保存でき、そのままフォームへ写せる。
   - 置く文：「このページは、誰でも同じ環境から Physical AI 研究を始められる状態を増やすためにあります。空欄があっても、試す前に止まっていても送れます。失敗の記録も、次の人の再現の土台になります。［メッセージフォーム］」

### 束ねるログ（/record/… の一覧）
URL は、依頼のログ一覧で各 Log# に付いている /record/… のとおりです。
- **段1：** Log#1〜3
- **段2：** Log#4・5・7〜11・17・23・25〜27
- **段3：** Log#6・12・14・18・20・28〜30・34
- **直す道具：** Log#19・32・33

### 今あるページとのつなぎ方（トップ・シリーズ・今ある LP）
ログからこのページへは送れません。来る道はどれも仮説で、リンクから来た数と、そのあとログへ進んだ数で確かめます。

- **AI の答え・検索：** 節の名前を問いの形にし、表はテキストで置く。題名に「π0.5」「追加学習」「Runpod」「LIBERO」を入れる。
- **研究室シリーズのページの上部：** 「π0.5 を始める方へ。アームなしの入口から、実機で確かめる項目までをまとめました。」
- **/gpu-buy-or-rent の「借りる」の節：** 「借りた A40 で π0.5 を動かした実例を見る。」（この LP は表示21件なので、読者と合うかは判断できない）
- **トップ：** 「シリーズ」の節に1行置くだけ。
- **LinkedIn：** 見せ場1を画像にして載せる。相談の窓口は置かない。

### 公開後に見る数字（30件たまるまでは判断しない）
- 人の表示と、どこから来たか
- ログへ進んだ割合（目標は3割）と、段ごとの内訳
- 届いた連絡のうち「試した／試そうとした」もの。記録の枠の項目が埋まっていた数も見る
- AI の利用者の依頼で読みに来た数と、AI のリンクから来た人は分けて数える
- 見せ場2が画面に出た数。画面に出たことと、読んだことは分けて扱う

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）
**人の表示（3か月で150件）**
- 効く理由：来る道が5つある。
- 効かないかもしれない理由：日本語で π0.5 を調べる人は少ないとみられる（推測）。

**ログへ進んだ人（表示した人の3割）**
- 効く理由：最初の画面の3行と、表のどの行もログにつながっている。
- 効かないかもしれない理由：表だけ見て満足されるおそれがある。

**AI の利用者の依頼で読みに来た数（週3件以上）**
- 効く理由：問いの形の節名とテキストの表は、AI が引きやすい。
- 効かないかもしれない理由：AI が英語の資料を先に読むかもしれない。

**AI のリンクから来た人（月1件以上）**
- 効く理由：答えの根拠としてリンクが出れば届く。
- 効かないかもしれない理由：AI が要約だけ返して、リンクは押されにくい。

**問い合わせ・相談（再現を試した人から1〜2件・いちばん重い）**
- 効く理由：記録の枠があるので、試す前に止まった人も送れる。欠けている版をはっきり見せることが、送る理由にもなる。
- 効かないかもしれない理由：照合する前に公開すると、試す前に離れてしまう。
```


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

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

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

### この人がこのページで得るもの
機材に依存しないπ0.5の動かし方から、自分のアームで追加学習する条件、そして実機特有の「黙って失敗する罠」を回避するための確認リスト。

### 最初の画面
**π0.5を自分の小型アームで動かす：環境構築から実機検証の罠まで**
公開モデルを自分のアームで動かすには、シミュレーションにはない物理の罠が待っている。
アームなしでπ0.5を動かす手順から、追加学習の条件、そして実機で確かめるべき項目を束ねた。
「 mechArm 270 」で泥臭く潰した記録を、どのアームにも当てはまる問いに置き換えて送る。

### 見せ場
「自分のアームで確かめる項目」の段。単なる失敗談ではなく、「電源不足」「制御ライブラリの版による遅延」「お手本の浅さ」「可動範囲外での命令無視」という、どのアームでも起こりうる罠を問いとして立て、mechArm 270で実際に起きた具体的な数字（40W要求に24Wで落ちる、1.6秒の遅延など）を根拠として突きつける点。

### 構成
**1. アームなしで、誰でも同じ結果まで行ける段：借りたGPUでπ0.5を動かす**
Macでは動かないπ0.5を、機材に左右されず動かす手順。RunpodでA40を借り、Macから画像と指示文を送り動きの数値を受け取る推論を通した結果（推論平均97ms、往復391ms、費用0.34ドル）を書く。また、シミュレータLIBEROのアームで「黒いボウルを拾って皿に置く」作業を20回すべて成功させた事実とGPUメモリの測定について書く。
使うログ：Log#2（326）、Log#3（327）

**2. 自分のアームで追加学習する段：お手本の数と学習の条件**
どのアームでも共通する追加学習の目安。位置ごとに10本そろえた深いお手本50本を使い、RunpodのA40で一から学習し直した条件を書く。3,000ステップにかかった時間は6.2時間、費用は約579円。lossは0.1015から0.0036まで下がった事実を提示し、学習規模の相場を伝える。
使うログ：Log#27（480）

**3. 自分のアームで確かめる項目①：電源と制御ライブラリの足回り**
実機検証で最初に疑うべき物理と通信の罠。
・電源は足りているか：mechArm 270がブロックを落とす原因は、本体が40Wを求めるのに対し12V・2A（24W）をつないでいたため。12V・5Aに替えると落とさなくなった。
・制御ライブラリの版で指令が遅れていないか：ゲームパッドでの操作時、1回の指令に1.6秒かかった原因はpymycobot 4.0.4。2.9.6に戻すと送信は約0.02秒になった。
使うログ：Log#30（487）、Log#34（504）、Log#20（436）

**4. 自分のアームで確かめる項目②：お手本の質と可動範囲の無視**
AIの失敗に見えて、実はデータやアームの仕様が原因である罠。
・お手本が浅いつかみになっていないか：AIが失敗した主な原因は置き場所ではなく、ブロックが奥まで入る前に爪を閉じる浅いつかみだった（学習データ30本中7本）。
・関節の可動範囲の外で命令が黙って捨てられていないか：肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられており動かなかった。
使うログ：Log#23（460）、Log#9（352）

### 束ねるログ
- 326｜フィジカルAI研究室を作る Log#2 | Physical Intelligence の π0.5 を借りたGPUで動かした｜/record/openpi-remote-inference-first-run
- 327｜フィジカルAI研究室を作る Log#3 | Physical Intelligence の π0.5 に要るGPUメモリを測った｜/record/pi05-libero-benchmark-first-run
- 480｜フィジカルAI研究室を作る Log#27 | 浅いつかみの癖を残さず、π0.5 を50本で一から学習｜/record/retrain-pi05-from-base-on-50-even-demos
- 487｜フィジカルAI研究室を作る Log#30 | mechArm 270 がブロックを落とす理由は、まさかの電源不足｜/record/mecharm-270-drops-block-underpowered-adapter
- 504｜フィジカルAI研究室を作る Log#34 | mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった｜/record/mecharm-270-5a-adapter-stops-dropping-block
- 436｜フィジカルAI研究室を作る Log#20 | ゲームパッドで動いた mechArm 270、遅さは pymycobot の版｜/record/gamepad-moves-mecharm-270-pymycobot-version
- 460｜フィジカルAI研究室を作る Log#23 | π0.5 の失敗の原因を探ると、浅いお手本だった｜/record/pi05-failures-traced-to-shallow-grasp-demos
- 352｜フィジカルAI研究室を作る Log#9 | 手で教えてお手本19本。肩88°を超えた姿勢は動かなかった｜/record/teach-replay-19-demos

### 今あるページとのつなぎ方
- トップ：トップの「シリーズ」の直下に、実機検証の入り口としてこのページへのリンクを置く。
- シリーズ：「フィジカルAI研究室を作る」シリーズのページ上部に、「自分のアームで始めるための手順と確認リスト」として固定配置する。
- 今ある LP：/gpu-buy-or-rent（GPUは買うか借りるか）から、「借りたGPUでπ0.5の推論と学習を回した実例」としてこのページの1段目・2段目へリンクを張る。

### 公開後に見る数字
- ページの表示数と、最後まで読んだ割合（75%到達率）
- このページから束ねた各ログ（特にLog#2, #3, #27）へ進んだ人の数
- フォームからの「自分のアームで試した（試そうとした）」という連絡の有無

### ゴールにどう効くか
| 見るもの | 効く理由と、効かないかもしれない理由 |
|---|---|
| このページの人の表示 | **効く理由**：「π0.5 実機 動かし方」など具体的で切実な検索意図に直結する題名と構成のため。**効かない理由**：そもそも自分で小型アームを使って公開モデルを動かそうとする絶対数が少なく、検索ボリュームがない可能性。 |
| このページからログへ進んだ人 | **効く理由**：ページ内では手順の概要と数字のみを示し、「具体的なコードや設定はログ（要約には記載なし）」と誘導するため。**効かない理由**：チェックリストの項目だけで満足し、詳細な事実確認まで求めない可能性。 |
| AI の利用者の依頼で、このページを読みに来た数 | **効く理由**：AIが「π0.5を実機で動かす手順や注意点」をまとめる際、3段構成と明確な数字（費用、時間、ワット数）が抽出元のソースとして極めて優秀に働くため。**効かない理由**：AIの検索クエリがサイト内の個別のログに直接ヒットしてしまい、このページを経由しない可能性。 |
| AI のリンクから、このページに来た人 | **効く理由**：AIが回答の根拠としてこのページを提示しやすいため。**効かない理由**：AIの回答だけでユーザーが満足してしまい、わざわざリンクを踏んで元記事を読みに来ない可能性。 |
| 問い合わせ・相談 | **効く理由**：「どのアームにも当てはまる問い」を突きつけることで、読者が自分の環境と照らし合わせ、「自分のアームではこうだった」と報告したくなる余白を作っているため。**効かない理由**：試すこと自体のハードルが高く、3か月以内に実機検証までたどり着く人が現れない可能性。 |
```


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

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

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

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

**こう直す**
1段目と2段目のそれぞれの終わりに「使ったものの表」を固定で置きます。ログに書いていない所は空欄にせず、書いていないことをそのまま見せます。

| 使ったもの | 版・条件 | 根拠 |
|---|---|---|
| 借りた GPU | Runpod・A40 | Log#2・#3・#27 |
| π0.5 を動かすコード（openpi） | 要約には記載なし（本文とコードで照合が要る） | Log#2 |
| GPU メモリの使用量 | 測った（値は要約には記載なし。本文で照合が要る） | Log#3 |
| アームの制御ライブラリ | pymycobot 2.9.6（4.0.4 では1指令1.6秒） | Log#20 |
| 学習データの置き場 | 2TB の外付け SSD | SO-101 Log#2 |

照合しても値がない所は「ログにない（未記載）」と書き換えます。これで判定条件③の「足りないものが無いと第三者が確かめられる」状態に、いちばん近づきます。

## 2.【高】2段目に「お手本の集め方」がなく、学習の条件も1回分しかない

**弱い所**
依頼では2段目を「お手本の集め方」と「学習の条件（本数・ステップ数・時間・費用）」の2つで組むことになっています。ところが案は Log#27 の1本だけで、「学習規模の相場を伝える」と書いています。1回の実例は相場ではないので、言い過ぎです。お手本の集め方もまったく書かれていません。

**こう直す**
2段目を次の2つに分けます。

- **お手本の集め方**
  - 手で姿勢を教えて再生しながら録る（Log#8・#9：5か所19本）
  - ゲームパッドで教え直して深いつかみにする（Log#25・#26：5か所10本ずつ）
- **学習の条件の移り変わり**（表にする）

| ログ | 本数 | ステップ数 | loss | 時間・費用 |
|---|---|---|---|---|
| Log#4 | 2本 | 200 | 0.1031→0.0162 | — |
| Log#5 | 19本 | 2,000 | 0.1155→0.0054 | — |
| Log#7 | 19本 | 4,000 | 0.0030 まで | — |
| Log#10 | 19本 | 4,000 | 0.0858→0.0037 | 起動まで GPU 待ち約4時間半 |
| Log#27 | 50本 | 3,000 | 0.1015→0.0036 | 6.2時間・約579円 |

表の下には、ログにある事実でいちばん強いことを一文で置きます。

> 「loss が下がっても実機で届くとは限らなかった（Log#7：0.0030 まで下げても爪はブロックの奥で空を閉じた）」

どのアームにも使える、いちばん価値のある教訓です。

## 3.【高】いちばん重いゴール「試した人からの連絡」への道がページにない

**弱い所**
案では、問い合わせは「公開後に見る数字」に入っているだけです。ページの中に、フォーム（/message）へ進む道がありません。「報告したくなる余白」は、送り先と何を送ればよいかが示されて初めて働きます。

**こう直す**
最後に1段を足します。題は「試した記録を送る」。相談の窓口ではなく、記録を送る道として置きます。

> 1の段だけでも、自分のアームで3の段の項目を1つ確かめただけでも、記録を送ってください（/message）。
> 送ってほしいこと：どの段まで試したか／使った GPU とコードの版／アームの名前と制御ライブラリの版／結果（動いた・止まった所）／このページで足りなかった情報

「足りなかった情報」は判定条件③にそのまま効きます。そのうえで、受け取った記録をこのページの「ほかの環境での記録」欄に足していく、と書いておきます。

## 4.【高】題と最初の画面が、中身より強く言っている

**弱い所**
- 「環境構築から」：要約にあるのは「借りて動かした」までで、構築の手順は要約にありません。
- 「物理の罠が待っている」：4項目のうち、pymycobot の版とお手本の浅さは物理の話ではありません。
- 「泥臭く潰した」：煽りの言い方です。

依頼が求めているのは「1台で最後まで通した実例」としての見せ方です。

**こう直す**
- **題**：π0.5 を自分の小型アームで動かし始める：アームなしで動かす段から、実機で確かめる項目まで
- **最初の画面（3行）**
  > アームがなくても、借りた GPU とシミュレータで π0.5 は同じ結果まで動かせる（Log#2・#3）。
  > 自分のアームで追加学習するなら、お手本の集め方と学習の条件はここにまとめた。
  > mechArm 270 1台で、追加学習から実機で15回中9回箱に入れるまで通した記録を、どのアームでも確かめられる問いに直した。

3行目の「15回中9回」は Log#14 の数字です。「最後まで通した」の根拠として、ログの中でいちばん強い事実です。

## 5.【中】3段目の数字が少ない回数なのに言い切っていて、どんな状況の数字かも書かれていない

**弱い所**
- 「12V・5A に替えると落とさなくなった」は5回の結果を一般化しています。Log#30 自体も「原因とみられる」としか書いていません。
- 「1.6秒の遅延」はゲームパッドの操作で、Pi の daemon が古い版を読んでいた時の数字です。π0.5 の推論の遅れと読まれかねません。

**こう直す**
- **電源**：本体は40W を求めるのに、12V・2A（24W）をつないでいた。12V・5A に替えた日は、π0.5 が位置5で5回中5回成功した（2A の日は3回中1回）。教えた動きの再生も7回中7回成功した。回数は少ないので、あなたのアームでもまず電源の定格を確かめる（Log#30・#34）。
- **制御ライブラリ**：ゲームパッドの1指令に1.6秒かかった。原因は Pi の daemon が pymycobot 4.0.4 を読んでいたこと。2.9.6 に戻すと送信は約0.02秒（Log#20）。

## 6.【中】mechArm 270 で「最後まで通した」道筋がなく、ログへ進むきっかけが少ない

**弱い所**
束ねたログは8本だけで、どこまで行けたかの線が見えません。Log#12〜#14（初めて箱に入った → 3か所すべて → 15回中9回）、Log#18（学び直しても人の直しが要った）、Log#28（位置2 で外れた）がありません。「ログへ進んだ人3割」のゴールには、次に読む理由が要ります。

**こう直す**
2段目と3段目の間に、各1行・ログへのリンク付きの「mechArm 270 の通し記録」を置きます。

- Log#6：初めて実機で動かし、爪がブロックに乗った
- Log#12：初めて箱に入れた
- Log#14：15回中9回（位置C 5/5・E 3/5・D 1/5）
- Log#18：成功6回はすべて人の直しつき
- Log#28：50本で学び直し、位置1 は3回とも直しなし、位置2 は4回とも届かず
- Log#34：電源を替え、位置5 で5回中5回

できなかったことも並べておけば、読む人は「自分が詰まった所」のログへ進めます。

## 7.【中】どこから来るかの書き方が薄く、SNS と AI への手当てがない

**弱い所**
トップからのリンクは、トップに来る人が1割（40件）しかいないので効きが小さいです。LinkedIn（10件）への道も、AI が読みに来た時に1枚で答えられる作りも書かれていません。

**こう直す**
来る道を多い順に書き直します。

1. **AI の答え**：ページの頭に、3段の要点と使ったものの表を本文の文字で置く（画像にしない）。AI がこのページだけで「手順・版・未記載の所」を答えられるようにする。
2. **/gpu-buy-or-rent**（21件、50%まで読んだ人が52%）：この LP から1段目へ送る。
3. **シリーズのページ**の上の資料の欄。
4. **LinkedIn**：「アームなしで π0.5 を動かすところまで」という1段目を紹介して投稿する。相談の窓口は出さない。

トップのリンクは残してかまいません。ただ、期待する役は小さいと明記してください。

## 8.【低】「ゴールにどう効くか」の表が言い過ぎで、言葉の使い方もずれている

**弱い所**
- 「抽出元のソースとして極めて優秀」は推測で、言い過ぎです。
- 「（要約には記載なし）と誘導する」は、「足りない所を見せる」ための言葉の使い方としてずれています。
- 「公開後に見る数字」に、30件時点の判断と、AI が読みに来た数（週3件）が入っていません。

**こう直す**
- 「3段と使ったものの表が本文の文字であれば、AI が読みに来た時に答えの材料にしやすい（推測）」と書き換える。
- 見る数字に「AI の利用者の依頼で読みに来た数（2か月目から週3件）」と「表示30件の時点での判断：連絡0件なら手を止める」を足す。

---

## 守るべき尖り

3段目で、罠を「どのアームにも当てはまる問い」として立て、mechArm 270 の実際の数字を根拠として添えた作り方は、この案でいちばん良い所です。特に「肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられていた」（Log#9）は、ほかのどこにも書かれていない、黙って失敗する実例です。読む人が自分のアームで確かめて、記録を送りたくなる理由そのものなので、書き直しても消さず、むしろ3段目の先頭に出してください。
```


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

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

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

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

**こう直せばもっと強くなる**  
各段に「手順・使った環境・確認できた結果・未確認事項・根拠ログ」をまとめる欄を置き、企画書に次を追記してください。

> 公開前に、選んだログの本文とコードで実行手順、依存関係、バージョンを照合する。入口ページに実行順と必要情報をまとめ、該当するコード・設定の所在へ直接送る。  
> 現時点で要約にない情報は「要約には記載なし（本文とコードで照合が要る）」、照合しても見つからない情報は「ログにない（未記載）」と表示する。再現できると断言する前に、第三者が不足を確認できる形にする。

これがページの中心機能です。

### 2.【高】追加学習の段が、「50本で学習した結果」の紹介に留まっている

**弱い所**  
Log#27だけでは、お手本をどう集め、学習へ渡し、出力をどう確かめるかがつながりません。また「どのアームでも共通する目安」「学習規模の相場」は、1台の実例からの言い過ぎです。lossの低下だけを出すと、実機での到達点も誤解されます。

**こう直せばもっと強くなる**  
第2段を、次の流れに書き換えてください。

> **お手本を集め、追加学習し、実機で確かめる**  
> mechArm 270では、手で教えた動きの再生からお手本を集めた（Log#8・#9）。浅いつかみを教え直し、5か所に10本ずつそろえた（Log#25・#26）。その50本で一から追加学習すると、A40で3,000ステップ、6.2時間、約579円だった（Log#27）。  
> これはmechArm 270で実施した条件であり、別のアームに必要な本数・時間・費用は未確認。学習後、位置1では3回とも補正なしでつかめた一方、位置2では4回ともつかむ姿勢に届かなかった（Log#28）。

各工程の操作方法とデータの形式は、本文・コードで照合する対象として明記します。

### 3.【高】観測した事実を、別の環境にも通じる保証へ広げている

**弱い所**  
「誰でも同じ結果まで行ける」「機材に左右されず」「どのアームでも起こりうる罠」は、提示された記録より広い主張です。制御ライブラリの説明も「原因はpymycobot 4.0.4」だけでは、Piのdaemonがその版を読んでいたという条件が落ちます。

**こう直せばもっと強くなる**  
第1段の見出しと説明を次に変更してください。

> **アームなしで始める：借りたGPUで推論とシミュレーションを確かめる**  
> 記録では、RunpodのA40でπ0.5を動かし、Macから画像と指示文を送って動きの数値を受け取れた（Log#2）。LIBEROでは、黒いボウルを拾って皿に置く作業に20回すべて成功した（Log#3）。同じ環境を組むための手順と、未確認の情報を以下に示す。

確認リストの前文は、次の形にします。

> 以下はmechArm 270で起きた事実から作った確認項目です。別のアームで同じ原因になるかは未確認です。自分のアームの電源条件、制御環境、指令と実際の動き、お手本を確かめてください。

版の項目も「Piのdaemonが4.0.4を読んでいた環境では1指令に1.6秒。2.9.6へ戻すと送信約0.02秒」と、観測条件を残してください。

### 4.【高】いちばん重いゴールに、実際の導線がない

**弱い所**  
「報告したくなる余白」は期待であって、フォームへ進む理由や操作になっていません。さらに実機検証まで進まなくても、「試そうとした人」からの連絡はゴールの対象です。

**こう直せばもっと強くなる**  
各段の末尾に、その段階のまま送れる導線を置いてください。

> **試した記録・始める前に止まった所を送る**  
> アームなしの推論やシミュレーションまででも、実行前でも送れます。使った環境、試した段、得られた結果、足りなかった情報を、分かる範囲で教えてください。  
> ［試した記録・止まった所を送る］→ `/message`

フォームで書くための項目をコピーできる形にすると、送る負担も減らせます。

### 5.【中】最初の画面が「始める」より「罠を読む」を約束している

**弱い所**  
題名、導入、見せ場で「罠」を繰り返すため、失敗の読み物に見えます。アームを持たない人も入れることと、今すぐ選べる開始点が弱くなっています。

**こう直せばもっと強くなる**  
最初の画面を次に差し替えてください。

> **π0.5を自分の小型アームで動かし始める：手順・学習条件・実機の確認項目**  
> アームがなくても、借りたGPUでπ0.5の推論とシミュレーションを試す所から始められます。  
> このページは、実行手順、使った環境、確認できた結果、未記載の情報をまとめた入口です。mechArm 270での実例をもとに、自分のアームで確かめる項目までつなぎます。  
> ［アームなしで始める］［お手本と学習条件を見る］［実機の確認項目を見る］

電源や指令の問題は、この開始点を支える見せ場として残します。

### 6.【中】入口への集客が、トップと既存ページへの配置で止まっている

**弱い所**  
トップは人の表示367件中40件で約1割です。シリーズと既存LPの接続は必要ですが、検索・AI・SNSからこのページへ入る具体策が不足しています。「AIの抽出元として極めて優秀」は、まだ検証していない期待です。

**こう直せばもっと強くなる**  
「どこから来るか」を、掲載する文面まで書いてください。

- **シリーズ上部**：「π0.5を自分の小型アームで始める方へ。アームなしの推論から、追加学習、実機の確認項目まで」
- **既存LP**：「借りたGPUでπ0.5を試す手順と、A40で追加学習した条件を見る」
- **SNS**：「π0.5を自分の小型アームで動かし始めるために、推論・追加学習・実機の確認項目をまとめました。アームなしで試す段から読めます」＋入口ページへのリンク
- **検索・AI向けの本文冒頭**：「何を試せるか／使った環境／確認できた結果／未記載の情報」を文章と表で示し、根拠ログへリンクする

検索やAIからの流入増加は「仮説」と明記し、公開後の数字で確かめます。

### 7.【中】評価項目はあるが、依頼の目標と判断条件が抜けている

**弱い所**  
75％到達率や連絡の有無だけでは、ページをどう直すか決められません。ログへ進んだ「人」とクリック回数、AIによる取得とAIのリンクから来た人も、分けて数える必要があります。

**こう直せばもっと強くなる**  
企画書の評価欄を次に差し替えてください。

> 依頼で定めた目標は、3か月で人の表示150件、表示した人の3割がログへ進むこと、2か月目からAI利用者の依頼による取得が週3件以上、AIのリンクからの訪問が月1件以上、再現を試した人・試そうとした人からの連絡1〜2件。  
> 最初の判断は人の表示30件がたまった時点で行う。30件未満では効果を言い切らない。ログへ進む人が少なければ段ごとのリンク文面と配置を見直し、連絡では再現の到達点と不足情報を確認する。75％到達率は補助指標とする。  
> 3か月で人の表示30件未満かつ連絡0件なら、追加の制作を止め、ページは残す。

### 守るべき尖り

**mechArm 270の具体的な失敗を、読者が自分のアームで確かめられる問いへ変えること。** 特に電源の項目は、要求40Wに対して24Wを使っていた事実から、交換後の結果まで追えます。この「問い→実測の根拠→対処後の結果」は消さず、始める手順のすぐ隣に置いてください。
```


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

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

## 評者（案Cの作者）からの指摘
1. 採る：要約にない情報は「本文とコードで照合が要る」「未記載」と明記し、表で示します。
2. 採る：お手本集めから追加学習、実機での到達点まで流れで書きます。
3. 一部採る：観測条件を残しますが、「誰でも同じ結果まで行ける」は依頼の指定なので見出しに残します。
4. 一部採る：導線は置きますが、構成を簡潔にするため各段末尾ではなく最後の段にまとめます。
5. 一部採る：罠という言葉は減らしますが、評者1の提案した「15回中9回」の事実を入れた画面を採用します。
6. 採る：SNSや既存ページへの具体的な掲載文面を追記し、流入の具体策とします。
7. 採る：依頼の目標数値と判断条件を正確に反映し、30件未満での判断ルールを明記します。


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

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

### この人がこのページで得るもの
機材に依存しないπ0.5の動かし方、お手本集めと追加学習の条件、実機特有の罠を回避する確認リスト、および再現に必要な環境情報（バージョン等）。

### 最初の画面
**π0.5 を自分の小型アームで動かし始める：アームなしで動かす段から、実機で確かめる項目まで**
アームがなくても、借りた GPU とシミュレータで π0.5 は同じ結果まで動かせる（Log#2・#3）。
自分のアームで追加学習するなら、お手本の集め方と学習の条件はここにまとめた。
mechArm 270 1台で、追加学習から実機で15回中9回箱に入れるまで通した記録を、どのアームでも確かめられる問いに直した。

### 見せ場
「自分のアームで確かめる項目」の段。特に「肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられていた」（Log#9）という、どのアームでも起こりうる黙って失敗する実例を先頭の問いとして立て、mechArm 270の実際の数字（要求40Wに24Wで落ちる等）を根拠として添え、対処後の結果まで提示する点。

### 構成
**1. アームなしで、誰でも同じ結果まで行ける段：借りたGPUで推論とシミュレーション**
RunpodのA40でπ0.5を動かし、Macから画像と指示を送り動きの数値を受け取る推論を通した（平均97ms、往復391ms、費用0.34ドル）。また、シミュレータLIBEROのアームで「黒いボウルを拾って皿に置く」作業を20回すべて成功させた。
末尾に「使ったものの表」をテキストで置く。
| 使ったもの | 版・条件 | 根拠 |
|---|---|---|
| 借りたGPU | Runpod・A40 | Log#2・#3 |
| π0.5を動かすコード | 要約には記載なし（本文とコードで照合が要る） | Log#2 |
| GPUメモリの使用量 | 測った（値は要約には記載なし。本文とコードで照合が要る） | Log#3 |
使うログ：Log#2（326）、Log#3（327）

**2. 自分のアームで追加学習する段：お手本の集め方と学習の条件の移り変わり**
- **お手本の集め方**：手で姿勢を教えて再生しながら録る（5か所19本）、ゲームパッドで教え直して深いつかみにする（5か所10本ずつ）。
- **学習の条件の移り変わり**：
| ログ | 本数 | ステップ数 | loss | 時間・費用 |
|---|---|---|---|---|
| Log#4 | 2本 | 200 | 0.1031→0.0162 | ログにない（未記載） |
| Log#5 | 19本 | 2,000 | 0.1155→0.0054 | ログにない（未記載） |
| Log#7 | 19本 | 4,000 | 0.0030まで | ログにない（未記載） |
| Log#10 | 19本 | 4,000 | 0.0858→0.0037 | 起動までGPU待ち約4時間半 |
| Log#27 | 50本 | 3,000 | 0.1015→0.0036 | 6.2時間・約579円 |
表の下に「lossが下がっても実機で届くとは限らなかった（Log#7：0.0030まで下げても爪はブロックの奥で空を閉じた）」と置き、いちばん価値のある教訓とする。
使うログ：Log#8（349）、Log#9（352）、Log#25（463）、Log#26（479）、Log#4（337）、Log#5（341）、Log#7（348）、Log#10（355）、Log#27（480）

**3. mechArm 270 の通し記録（ログへの道）**
どこまで行けたかの線を各1行・リンク付きで並べ、読者が詰まった所のログへ進めるようにする。
- Log#6：初めて実機で動かし、爪がブロックに乗った
- Log#12：初めて箱に入れた
- Log#14：15回中9回（位置C 5/5・E 3/5・D 1/5）
- Log#18：成功6回はすべて人の直しつき
- Log#28：50本で学び直し、位置1 は3回とも直しなし、位置2 は4回とも届かず
- Log#34：電源を替え、位置5 で5回中5回

**4. 自分のアームで確かめる項目：可動範囲、電源、制御、お手本**
どのアームにも当てはまる問いと、mechArm 270の実測値・対処結果。
- 関節の可動範囲の外で命令が黙って捨てられていないか：肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられており動かなかった（Log#9）。
- 電源は足りているか：本体は40Wを求めるのに12V・2A（24W）をつないでいた。12V・5Aに替えた日はπ0.5が位置5で5回中5回成功（2Aの日は3回中1回）、再生も7回すべて成功（Log#30・#34）。
- 制御ライブラリの版で指令が遅れていないか：ゲームパッド操作で1指令に1.6秒。原因はPiのdaemonがpymycobot 4.0.4を読んでいたこと。2.9.6に戻すと送信約0.02秒（Log#20）。
- お手本が浅いつかみになっていないか：失敗の主因は浅いつかみ（学習データ30本中7本）（Log#23）。

**5. 試した記録を送る**
1の段まででも、試そうとして止まった所でも、記録を送る道（/message）を置く。
送ってほしいこと：どの段まで試したか／使ったGPUとコードの版／アームの名前と制御ライブラリの版／結果／このページで足りなかった情報。受け取った記録は「ほかの環境での記録」欄に足していく。

### 束ねるログ
- 326｜Log#2 | Physical Intelligence の π0.5 を借りたGPUで動かした｜/record/openpi-remote-inference-first-run
- 327｜Log#3 | Physical Intelligence の π0.5 に要るGPUメモリを測った｜/record/pi05-libero-benchmark-first-run
- 337｜Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
- 341｜Log#5 | Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致｜/record/pi05-mecharm-lora-2000-steps
- 345｜Log#6 | Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った｜/record/pi05-mecharm-first-real-run
- 348｜Log#7 | Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた｜/record/pi05-mecharm-4000-steps
- 349｜Log#8 | 手で教えた動きを再生し、4回続けて箱に入れた｜/record/drag-teach-waypoint-replay
- 352｜Log#9 | 手で教えてお手本19本。肩88°を超えた姿勢は動かなかった｜/record/teach-replay-19-demos
- 355｜Log#10 | 位置を変えたお手本で、Physical Intelligence の π0.5 を学習し直した｜/record/pi05-retrain-five-positions
- 361｜Log#12 | Physical Intelligence の π0.5 が初めてブロックを箱に入れた｜/record/pi05-first-block-in-box
- 401｜Log#14 | π0.5 を回数で測ったら、苦手な置き場所が見えた｜/record/pi05-weak-position-d
- 422｜Log#18 | 学び直した π0.5 でも mechArm 270 には人の直しが要った｜/record/retrained-pi05-still-needs-human-corrections
- 436｜Log#20 | ゲームパッドで動いた mechArm 270、遅さは pymycobot の版｜/record/gamepad-moves-mecharm-270-pymycobot-version
- 460｜Log#23 | π0.5 の失敗の原因を探ると、浅いお手本だった｜/record/pi05-failures-traced-to-shallow-grasp-demos
- 463｜Log#25 | 深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した｜/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- 479｜Log#26 | 偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に｜/record/even-ten-demos-per-spot-mecharm-270-reteaching
- 480｜Log#27 | 浅いつかみの癖を残さず、π0.5 を50本で一から学習｜/record/retrain-pi05-from-base-on-50-even-demos
- 484｜Log#28 | 50本で学んだ π0.5 をアームで試し、位置2 で外れた｜/record/pi05-even-demos-on-arm-misses-position-2
- 487｜Log#30 | mechArm 270 がブロックを落とす理由は、まさかの電源不足｜/record/mecharm-270-drops-block-underpowered-adapter
- 504｜Log#34 | mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった｜/record/mecharm-270-5a-adapter-stops-dropping-block

### 今あるページとのつなぎ方
- **AIの答え**：ページの頭に3段の要点と使ったものの表を本文の文字で置く（画像にしない）。
- **/gpu-buy-or-rent**：「借りたGPUでπ0.5を試す手順と、A40で追加学習した条件を見る」として1段目へ送る。
- **シリーズのページ**：上部に「π0.5を自分の小型アームで始める方へ。アームなしの推論から、追加学習、実機の確認項目まで」と固定配置する。
- **LinkedIn**：「アームなしでπ0.5を動かすところまで」という1段目を紹介して投稿する。相談の窓口は出さない。
- **トップ**：シリーズの直下にリンクを置く（トップを通る人は1割のため期待する役は小さい）。

### 公開後に見る数字
最初の判断は、人の表示30件がたまった時点で行う。30件未満かつ連絡0件なら追加の制作を止め、ページは残す。
- このページの人の表示数（目標150件）と、最後まで読んだ割合（75%到達率・補助指標）
- 表示した人のうち、ログへ進んだ人の割合（目標3割）
- AIの利用者の依頼で読みに来た数（2か月目から週3件以上）
- AIのリンクから来た人（月1件以上）
- フォームからの「試した・試そうとした」連絡の有無（1〜2件）

### ゴールにどう効くか
| 見るもの | 効く理由と、効かないかもしれない理由 |
|---|---|
| このページの人の表示 | **効く理由**：「π0.5 追加学習 手順」など具体的な検索意図に応えるため。**効かない理由**：小型アームで公開モデルを動かそうとする絶対数が少なく、検索ボリュームがない可能性。 |
| このページからログへ進んだ人 | **効く理由**：通し記録の段を新設し、自分が詰まった所の詳細をログで確かめたくなるため。**効かない理由**：確認リストの項目だけで満足し、詳細な事実確認まで求めない可能性。 |
| AI の利用者の依頼で読みに来た数 | **効く理由**：3段構成と使ったものの表が本文の文字であれば、AIが答えの材料にしやすい（推測）。**効かない理由**：AIの検索クエリがサイト内の個別のログに直接ヒットしてしまい、このページを経由しない可能性。 |
| AI のリンクから来た人 | **効く理由**：AIが回答の根拠としてこのページを提示しやすいため。**効かない理由**：AIの回答だけでユーザーが満足してしまい、リンクを踏んで元記事を読みに来ない可能性。 |
| 問い合わせ・相談 | **効く理由**：「どのアームにも当てはまる問い」と「未記載の情報」を示すことで、自分のアームでの結果や不足情報を報告したくなるため。**効かない理由**：試すこと自体のハードルが高く、3か月以内に検証までたどり着く人が現れない可能性。 |
```


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

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

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

### この人がこのページで得るもの
機材に依存しないπ0.5の動かし方、お手本集めと追加学習の条件、実機特有の罠を回避する確認リスト、および再現に必要な環境情報（バージョン等）。

### 最初の画面
**π0.5 を自分の小型アームで動かし始める：アームなしで動かす段から、実機で確かめる項目まで**
アームがなくても、借りた GPU とシミュレータで π0.5 は同じ結果まで動かせる（Log#2・#3）。
自分のアームで追加学習するなら、お手本の集め方と学習の条件はここにまとめた。
mechArm 270 1台で、追加学習から実機で15回中9回箱に入れるまで通した記録を、どのアームでも確かめられる問いに直した。

### 見せ場
「自分のアームで確かめる項目」の段。特に「肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられていた」（Log#9）という、どのアームでも起こりうる黙って失敗する実例を先頭の問いとして立て、mechArm 270の実際の数字（要求40Wに24Wで落ちる等）を根拠として添え、対処後の結果まで提示する点。

### 構成
**1. アームなしで、誰でも同じ結果まで行ける段：借りたGPUで推論とシミュレーション**
RunpodのA40でπ0.5を動かし、Macから画像と指示を送り動きの数値を受け取る推論を通した（平均97ms、往復391ms、費用0.34ドル）。また、シミュレータLIBEROのアームで「黒いボウルを拾って皿に置く」作業を20回すべて成功させた。
末尾に「使ったものの表」をテキストで置く。
| 使ったもの | 版・条件 | 根拠 |
|---|---|---|
| 借りたGPU | Runpod・A40 | Log#2・#3 |
| π0.5を動かすコード | 要約には記載なし（本文とコードで照合が要る） | Log#2 |
| GPUメモリの使用量 | 測った（値は要約には記載なし。本文とコードで照合が要る） | Log#3 |
使うログ：Log#2（326）、Log#3（327）

**2. 自分のアームで追加学習する段：お手本の集め方と学習の条件の移り変わり**
- **お手本の集め方**：手で姿勢を教えて再生しながら録る（5か所19本）、ゲームパッドで教え直して深いつかみにする（5か所10本ずつ）。
- **学習の条件の移り変わり**：
| ログ | 本数 | ステップ数 | loss | 時間・費用 |
|---|---|---|---|---|
| Log#4 | 2本 | 200 | 0.1031→0.0162 | ログにない（未記載） |
| Log#5 | 19本 | 2,000 | 0.1155→0.0054 | ログにない（未記載） |
| Log#7 | 19本 | 4,000 | 0.0030まで | ログにない（未記載） |
| Log#10 | 19本 | 4,000 | 0.0858→0.0037 | 起動までGPU待ち約4時間半 |
| Log#27 | 50本 | 3,000 | 0.1015→0.0036 | 6.2時間・約579円 |
表の下に「lossが下がっても実機で届くとは限らなかった（Log#7：0.0030まで下げても爪はブロックの奥で空を閉じた）」と置き、いちばん価値のある教訓とする。
使うログ：Log#8（349）、Log#9（352）、Log#25（463）、Log#26（479）、Log#4（337）、Log#5（341）、Log#7（348）、Log#10（355）、Log#27（480）

**3. mechArm 270 の通し記録（ログへの道）**
どこまで行けたかの線を各1行・リンク付きで並べ、読者が詰まった所のログへ進めるようにする。
- Log#6：初めて実機で動かし、爪がブロックに乗った
- Log#12：初めて箱に入れた
- Log#14：15回中9回（位置C 5/5・E 3/5・D 1/5）
- Log#18：成功6回はすべて人の直しつき
- Log#28：50本で学び直し、位置1 は3回とも直しなし、位置2 は4回とも届かず
- Log#34：電源を替え、位置5 で5回中5回

**4. 自分のアームで確かめる項目：可動範囲、電源、制御、お手本**
どのアームにも当てはまる問いと、mechArm 270の実測値・対処結果。
- 関節の可動範囲の外で命令が黙って捨てられていないか：肩を約88°より深く倒した姿勢は、命令がエラーなしに捨てられており動かなかった（Log#9）。
- 電源は足りているか：本体は40Wを求めるのに12V・2A（24W）をつないでいた。12V・5Aに替えた日はπ0.5が位置5で5回中5回成功（2Aの日は3回中1回）、再生も7回すべて成功（Log#30・#34）。
- 制御ライブラリの版で指令が遅れていないか：ゲームパッド操作で1指令に1.6秒。原因はPiのdaemonがpymycobot 4.0.4を読んでいたこと。2.9.6に戻すと送信約0.02秒（Log#20）。
- お手本が浅いつかみになっていないか：失敗の主因は浅いつかみ（学習データ30本中7本）（Log#23）。

**5. 試した記録を送る**
1の段まででも、試そうとして止まった所でも、記録を送る道（/message）を置く。
送ってほしいこと：どの段まで試したか／使ったGPUとコードの版／アームの名前と制御ライブラリの版／結果／このページで足りなかった情報。受け取った記録は「ほかの環境での記録」欄に足していく。

### 束ねるログ
- 326｜Log#2 | Physical Intelligence の π0.5 を借りたGPUで動かした｜/record/openpi-remote-inference-first-run
- 327｜Log#3 | Physical Intelligence の π0.5 に要るGPUメモリを測った｜/record/pi05-libero-benchmark-first-run
- 337｜Log#4 | Physical Intelligence の π0.5 を mechArm 270 で追加学習｜/record/pi05-mecharm-demo-to-inference
- 341｜Log#5 | Physical Intelligence の π0.5 を学習。予測はお手本とほぼ一致｜/record/pi05-mecharm-lora-2000-steps
- 345｜Log#6 | Physical Intelligence の π0.5 で実機を動かすと、爪がブロックに乗った｜/record/pi05-mecharm-first-real-run
- 348｜Log#7 | Physical Intelligence の π0.5 を倍学習しても、爪は奥へずれた｜/record/pi05-mecharm-4000-steps
- 349｜Log#8 | 手で教えた動きを再生し、4回続けて箱に入れた｜/record/drag-teach-waypoint-replay
- 352｜Log#9 | 手で教えてお手本19本。肩88°を超えた姿勢は動かなかった｜/record/teach-replay-19-demos
- 355｜Log#10 | 位置を変えたお手本で、Physical Intelligence の π0.5 を学習し直した｜/record/pi05-retrain-five-positions
- 361｜Log#12 | Physical Intelligence の π0.5 が初めてブロックを箱に入れた｜/record/pi05-first-block-in-box
- 401｜Log#14 | π0.5 を回数で測ったら、苦手な置き場所が見えた｜/record/pi05-weak-position-d
- 422｜Log#18 | 学び直した π0.5 でも mechArm 270 には人の直しが要った｜/record/retrained-pi05-still-needs-human-corrections
- 436｜Log#20 | ゲームパッドで動いた mechArm 270、遅さは pymycobot の版｜/record/gamepad-moves-mecharm-270-pymycobot-version
- 460｜Log#23 | π0.5 の失敗の原因を探ると、浅いお手本だった｜/record/pi05-failures-traced-to-shallow-grasp-demos
- 463｜Log#25 | 深くつかむお手本へ、mechArm 270 をゲームパッドで教え直した｜/record/reteaching-mecharm-270-grasp-with-gamepad-for-deep-demos
- 479｜Log#26 | 偏りなく学ばせるため、mechArm 270 のお手本を5か所10本に｜/record/even-ten-demos-per-spot-mecharm-270-reteaching
- 480｜Log#27 | 浅いつかみの癖を残さず、π0.5 を50本で一から学習｜/record/retrain-pi05-from-base-on-50-even-demos
- 484｜Log#28 | 50本で学んだ π0.5 をアームで試し、位置2 で外れた｜/record/pi05-even-demos-on-arm-misses-position-2
- 487｜Log#30 | mechArm 270 がブロックを落とす理由は、まさかの電源不足｜/record/mecharm-270-drops-block-underpowered-adapter
- 504｜Log#34 | mechArm 270 の電源を5Aに替え、ブロックを落とさなくなった｜/record/mecharm-270-5a-adapter-stops-dropping-block

### 今あるページとのつなぎ方
- **AIの答え**：ページの頭に3段の要点と使ったものの表を本文の文字で置く（画像にしない）。
- **/gpu-buy-or-rent**：「借りたGPUでπ0.5を試す手順と、A40で追加学習した条件を見る」として1段目へ送る。
- **シリーズのページ**：上部に「π0.5を自分の小型アームで始める方へ。アームなしの推論から、追加学習、実機の確認項目まで」と固定配置する。
- **LinkedIn**：「アームなしでπ0.5を動かすところまで」という1段目を紹介して投稿する。相談の窓口は出さない。
- **トップ**：シリーズの直下にリンクを置く（トップを通る人は1割のため期待する役は小さい）。

### 公開後に見る数字
最初の判断は、人の表示30件がたまった時点で行う。30件未満かつ連絡0件なら追加の制作を止め、ページは残す。
- このページの人の表示数（目標150件）と、最後まで読んだ割合（75%到達率・補助指標）
- 表示した人のうち、ログへ進んだ人の割合（目標3割）
- AIの利用者の依頼で読みに来た数（2か月目から週3件以上）
- AIのリンクから来た人（月1件以上）
- フォームからの「試した・試そうとした」連絡の有無（1〜2件）

### ゴールにどう効くか
| 見るもの | 効く理由と、効かないかもしれない理由 |
|---|---|
| このページの人の表示 | **効く理由**：「π0.5 追加学習 手順」など具体的な検索意図に応えるため。**効かない理由**：小型アームで公開モデルを動かそうとする絶対数が少なく、検索ボリュームがない可能性。 |
| このページからログへ進んだ人 | **効く理由**：通し記録の段を新設し、自分が詰まった所の詳細をログで確かめたくなるため。**効かない理由**：確認リストの項目だけで満足し、詳細な事実確認まで求めない可能性。 |
| AI の利用者の依頼で読みに来た数 | **効く理由**：3段構成と使ったものの表が本文の文字であれば、AIが答えの材料にしやすい（推測）。**効かない理由**：AIの検索クエリがサイト内の個別のログに直接ヒットしてしまい、このページを経由しない可能性。 |
| AI のリンクから来た人 | **効く理由**：AIが回答の根拠としてこのページを提示しやすいため。**効かない理由**：AIの回答だけでユーザーが満足してしまい、リンクを踏んで元記事を読みに来ない可能性。 |
| 問い合わせ・相談 | **効く理由**：「どのアームにも当てはまる問い」と「未記載の情報」を示すことで、自分のアームでの結果や不足情報を報告したくなるため。**効かない理由**：試すこと自体のハードルが高く、3か月以内に検証までたどり着く人が現れない可能性。 |
```


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

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

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

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

今の表は1段目の3行だけです。2段目と3段目で使ったもの（制御ライブラリの版、電源、Pi など）がページのどこにも一覧になっていません。これでは、読む人が「何が書かれていて、何が欠けているか」を1枚で確かめられません。依頼の「足りないこと自体を見せる」も、ページ全体ではできていません。

**こう直す**
ページの頭（最初の画面の直後）に、3段をまとめた表を1枚置きます。各行の状態を「要約に記載あり／要約には記載なし（本文とコードで照合が要る）／ログにない（未記載）」の3つで示します。

| 段 | 使ったもの | 版・条件 | 状態 | 根拠 |
|---|---|---|---|---|
| 1 | 借りた GPU | Runpod・A40 | 記載あり | Log#2・#3 |
| 1 | 送る側 | Mac（π0.5 は Mac では動かなかった） | 記載あり | Log#2 |
| 1 | π0.5 を動かすコードとその版 | — | 要約には記載なし（本文とコードで照合が要る） | Log#2 |
| 1 | LIBERO の版 | — | 要約には記載なし（本文とコードで照合が要る） | Log#3 |
| 1 | GPU メモリの使用量 | 測った（値は要照合） | 要約には記載なし（本文とコードで照合が要る） | Log#3 |
| 2 | 学習に使った GPU | A40 | 記載あり | Log#4・#10・#27 |
| 3 | 制御ライブラリ | pymycobot 2.9.6（4.0.4 では1指令1.6秒） | 記載あり | Log#20 |
| 3 | アーム側の中継 | Pi の daemon（Pi の型は要照合） | 一部記載あり | Log#20 |
| 3 | 電源 | 12V・5A（本体は40Wを求める。12V・2A＝24Wでは落とした） | 記載あり | Log#30・#34 |

表の下に、次の1行を置きます。
「この表で、版が埋まっているのは○行中○行。残りは照合中」

この一文があると、判定③の「欠けていないことを第三者が確かめられる」を、ページそのものが満たしにいく形になります。照合が済んだら行を更新します。

## 2【高】見せ場の「対処後の結果まで」「どのアームでも起こりうる」が、ログにない言い過ぎ

**弱い所**
- 肩88°の件（Log#9）の要約にあるのは「命令がエラーなしに捨てられていた」までです。どう対処して、結果がどうなったかは書かれていません。
- 「どのアームでも起こりうる」も、ログにない一般化です。依頼の「ほかのアームでどうなるかは書かない」に反します。

**こう直す（見せ場の文面）**
> 「自分のアームで確かめる項目」の段。先頭の問いは「関節の可動範囲の外で、命令が黙って捨てられていないか」。mechArm 270 では、肩を約88°より深く倒した姿勢はエラーが出ないまま動かなかった（Log#9。どう避けたかは要約には記載なし。本文で照合が要る）。
> 対処後の結果まで数字で示せるのは、次の2つ。
> - 電源：12V・2A の日は3回中1回 → 12V・5A で5回中5回（Log#30・#34）
> - 制御ライブラリの版：1指令1.6秒 → 送信約0.02秒（Log#20）

「対処前と対処後の数字がそろった問い」と「まだ照合中の問い」を分けて見せます。そのほうが言い過ぎにならず、しかも強く言えます。

## 3【高】学習の条件の表に、規則違いと抜けがある

**弱い所**
- Log#4・#5・#7 の時間と費用を「ログにない（未記載）」と書いています。でも依頼の決まりでは、本文とコードで照合する前は「要約には記載なし（本文とコードで照合が要る）」です。
- 「時間・費用」の欄に、Log#10 の「起動までの GPU 待ち」が入っています。学習にかかった時間とは別物で、読む人が取り違えます。
- 前のモデルから続けて学習したのか、一から学習したのかが分かりません。Log#27 は「一から」、Log#17 は「前のモデルから続けて1,500ステップ」です。Log#17 は表から抜けています。
- 表の下の教訓が Log#7 の1つだけです。

**こう直す**
- 列を「ログ／本数／始め方（一から・続けて）／ステップ数／loss／学習時間・費用／GPU 待ち」にします。
- Log#17 の行を足します：人が直した5回、前のモデルから続けて、1,500ステップ。
- 空いている欄は、すべて「要約には記載なし（本文とコードで照合が要る）」にします。
- 表の下の教訓を2行にします。
  > 予測がお手本の最初の1秒と数度以内で一致しても（Log#5）、実機では爪がブロックに乗った（Log#6）。loss を0.0030まで下げても、爪はブロックの奥で空を閉じた（Log#7）。

## 4【中】確かめる項目に「どう見分けるか」がなく、自分のアームで確かめられない

**弱い所**
4つの問いのうち「お手本が浅いつかみになっていないか」は、読む人が自分のお手本をどう見て判断すればよいかが書かれていません。

**こう直す**
各問いを「問い／mechArm 270 での見分け方／対処と結果／詰まった記録と直した記録へのリンク」の4つの欄にそろえます。ログにある見分け方を入れます。

- **浅いつかみ**：爪がブロックに乗った回は、下ろす時間が普段の1.1秒に対して7.9〜9.1秒だった（Log#25）。判断専用のモデルに見せても、箱に入ったかは56本すべて見分けたが、つかみの深さは見分けられなかった（Log#33）。
  → 「動画を目で見るか、下ろす時間で確かめる」と書けます。
- **問いを1つ足す**：「AI に渡す今の関節角度は、何の値か」。学習し直さずに、AI に渡す肩の角度を直前の目標に変えただけで、毎回約2°足りずに箱に当てていた動きが直った（Log#12）。

## 5【中】1段目に「自分の結果を照らし合わせる数字」がなく、最初の画面の「同じ結果まで動かせる」が言い過ぎ

**弱い所**
- 1段目は主指標にいちばん近い段なのに、「ここまで来たら成功」と照らし合わせる数字の欄がありません。
- 最初の画面の「同じ結果まで動かせる」は、まだほかの環境で確かめられていないことを言い切っています。
- いちばん強い事実である「Mac では動かない／0.34ドル」が、最初の画面にありません。

**こう直す（最初の画面2行目）**
> π0.5 は Mac では動かないが、Runpod で A40 を借りれば動いた。推論は平均97ms・往復391ms・費用0.34ドル（Log#2）。LIBERO では「黒いボウルを拾って皿に置く」を20回中20回（Log#3）。あなたの環境でこの数字になるかを、アームなしで確かめられる。

1段目の終わりには「照らし合わせる数字（97ms／391ms／20回中20回）」の小さな表を置き、そのすぐ下に送る道（/message）を置きます。

## 6【中】送る道が具体的でなく、いちばん重いゴール（試した人からの連絡）に効きにくい

**弱い所**
送ってほしい項目は書かれています。でも、主指標の判定③に結びつく書き方になっていません。また、ページの最後にしか置かれていません。

**こう直す**
- 「ほかの環境での記録」の欄を最初から置き、「まだ0件」と書きます。
- 送るための見本を、照らし合わせる数字に合わせます。
  > 例：1段目：LIBERO で20回中○回／往復○ms／GPU と π0.5 のコードの版／止まった所／上の表で埋まっていなかった版で、あなたが分かったもの
- 送る道は、1段目の終わりとページの最後の2か所に置きます。

## 7【中】通し記録（第3節）が3段の流れを切っていて、解けていない所も見せていない

**弱い所**
- 2段目と「確かめる項目」の間に通し記録が入っていて、依頼の3段の組み方が崩れています。
- 通し記録が Log#34 の成功で終わっていて、Log#28 の「位置2 は4回とも届かず」が解けていないことが読み取れません。

**こう直す**
- 通し記録は3段目の後ろに「1台で最後まで通した線」として移します。
- 線の終わりに、まだ解けていないことを1行置きます。
  > 位置2 で下りない理由は、上カメラの傾きではなかった（画像の傾きだけを変えて1,770回答えさせても、行き先は入れ替わらなかった。Log#29）。原因はまだ分かっていない。
- Log#29 を束ねるログに足します。
- 読む人が自分の仮説や記録を送る理由になり、ログへ進む人（目標3割）にも効きます。

## 8【中】人と AI がどこから来るかの書き方がまだ抽象的

**弱い所**
「AI の答え」の道が「要点と表を文字で置く」だけです。AI の利用者がどんな問いでこのページにたどり着くかが、見出しに反映されていません。シリーズのページも、どのページなのかが特定されていません。

**こう直す**
- 各段の小見出しを、ログで答えられる問いの形にします。
  - 「π0.5 は Mac で動くか」（Log#2）
  - 「π0.5 の追加学習は何本・何ステップ・いくらか」（Log#27：50本・3,000ステップ・6.2時間・約579円）
  - 「loss が下がったのに、実機で届かないのはなぜか」（Log#5〜#7）
- シリーズのページは「フィジカルAI研究室を作る」シリーズのページの上部、と特定します。
- /gpu-buy-or-rent は21件で、25%まで読んだ割合が52%です。送り先の文言は、読まれている前半の中に置きます。

---

## 守るべき尖り

「自分のアームで確かめる項目」で、**mechArm 270 で対処する前と後の数字を、どのアームにも当てはまる問いに添えている形**です。
- 電源：12V・2A で3回中1回 → 12V・5A で5回中5回
- 制御ライブラリの版：1指令1.6秒 → 約0.02秒

これは失敗の読み物ではなく、自分のアームですぐ確かめられる手がかりになっています。この案が「保存しておきたい」ページになる理由はここにあります。書き直すときも、問いと対処前後の数字の組は削らず、問いの数を増やす方向で強くしてください。
```


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

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

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

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

   > **まず、アームを使わずにここまで試す**  
   > ・画像と指示文を送り、動きの数値を受け取る → ［Log#2の手順・コードを開く］  
   > ・LIBEROで「黒いボウルを拾って皿に置く」を動かす → ［Log#3の手順・コードを開く］  
   > 各項目に「準備するもの／実行する順番／結果の確かめ方／依存関係とバージョン／未確認の情報」を置く。具体の操作は本文とコードを照合して転記する。

   「誰でも同じ結果まで行ける」は、現時点では次に書き換える。

   > アームを使わずに試せる2つの実例です。Log#3では20回すべて成功しました。別の環境で同じ結果になるかは、このページではまだ確認できていません。

2. **【高】未確認を「ログにない」と断定し、環境情報も足りない**

   **弱い所：** 学習表のLog#4・#5・#7の時間・費用を「ログにない（未記載）」としているが、与えられた要約だけでは断定できない。また、GPU名だけでは環境を再現できず、「再現に必要な環境情報を得られる」という約束を満たしていない。

   **こう直せばもっと強くなる：** 該当セルはすべて、まず次に直す。

   > 要約には記載なし（本文とコードで照合が要る）

   環境表には、借りたGPUだけでなく、モデル・チェックポイント、実行コードの版、Python、主要な依存関係、LIBEROの版、実行設定の確認欄を設ける。値は作らず、未確認の欄には上記の文言を入れる。照合後も見つからない項目だけ「ログにない（未記載）」とする。

   冒頭の提供価値も、次のようにする。

   > 手順・使ったもの・結果をまとめ、再現に必要な情報のうち、確認できたものと足りないものを示します。

3. **【高】「どのアームでも起こりうる」と、実例から言い過ぎている**

   **弱い所：** 可動範囲外の命令が黙って捨てられる挙動は、mechArm 270で確認された事実。他のアームにも起こるとは、このログからは言えない。「実機特有の罠を回避」も、他機種での効果まで約束している。

   **こう直せばもっと強くなる：** 見せ場の説明を次に置き換える。

   > **指令を送ったとき、実機はその姿勢まで動いているか。**  
   > mechArm 270では、肩を約88°より深く倒した姿勢の命令が、エラーなしに捨てられていた（Log#9）。あなたのアームでは、可動範囲と、届かない指令を送ったときの応答を確認する。

   制御の項目にも、次を添える。

   > pymycobot 2.9.6は、この実例で遅さが改善した版です。あなたのアームへの推奨版を示すものではありません。

   「罠を回避する確認リスト」は「実機で動かす前後に確かめる項目」へ直す。

4. **【高】学習条件の履歴が中心で、自分が始める条件を判断できない**

   **弱い所：** 本数・ステップ数・lossを並べても、その条件で何ができたかが表から分からない。「移り変わり」と「いちばん価値のある教訓」が中心になると、始める入口から研究の振り返りに戻ってしまう。

   **こう直せばもっと強くなる：** 見出しを「追加学習で使った条件と、その後に確かめた結果」に変え、lossより先に「到達点・未達」を置く。

   > ・2本・200ステップ：Macで予測を受け取った。実機は未実施（Log#4）。  
   > ・19本・2,000ステップ：送信前の予測がお手本の最初の1秒と数度以内で一致した（Log#5）。  
   > ・深いお手本50本・3,000ステップ：学習は6.2時間・約579円（Log#27）。実機では位置1で3回とも補正なしでつかめたが、位置2では4回ともつかむ姿勢に届かなかった（Log#28）。

   表の直前には、次を置く。

   > 以下はmechArm 270で試した条件です。あなたのアームに必要な本数・ステップ数は、この記録からは決められません。

5. **【中】見せ場とログへの入口が遠く、ログを開く目的が弱い**

   **弱い所：** 見せ場の確認項目が4番目にあり、その前に学習履歴と通し記録を読む構成になっている。通し記録も出来事の一覧なので、読者が「今、どれを開くか」を選びにくい。

   **こう直せばもっと強くなる：** 冒頭に次の3つの行き先を置き、各段の中で詳細ログへ送る。

   > **今の状態から選ぶ**  
   > ・まだアームを使わない → 推論とシミュレーション  
   > ・お手本を集めて学習したい → 収集方法と学習条件  
   > ・実機が指令どおりに動かない → 可動範囲・電源・制御・お手本の確認

   ログのリンク文も、例えば次に変える。

   > ［電源を替えた前後の結果を確かめる：Log#30・#34］  
   > ［予測は合うのに実機で届かない経過を読む：Log#5・#6・#7］

   通し記録は補足に回す。冒頭の「15回中9回」は「Log#14時点の測定」と明記し、異なる学習条件・位置・補正の有無の結果を、ひと続きの改善率として読ませない。

6. **【高】最も重い「試した人・試そうとした人からの連絡」への道が細い**

   **弱い所：** フォームが末尾にしかなく、記入項目も多い。試す前に不足情報で止まった人ほど、GPUやコードの版を埋められず送信をためらう。「受け取った記録は足していく」も、公開を望まない人には送りにくい。

   **こう直せばもっと強くなる：** 各段の未確認情報の直後に、次を置く。

   > **この段で止まったら、足りない情報を送る**  
   > 「試したい段／試したこと、または始められない理由／足りない情報」だけでも送れます。版や機材名は、分かる範囲で構いません。  
   > ［試した記録・始められない理由を送る］→ /message

   フォームへの案内には、次を添える。

   > 他の環境での記録として掲載してよいかも、お知らせください。

7. **【中】流入元は挙がっているが、検索とAIから選ばれる説明がまだ薄い**

   **弱い所：** 「本文の文字で置く」は提示方法であって、入口へ到達する理由としては足りない。検索からの導線は具体策がなく、AIが根拠として提示しやすいという説明も推測の明記が抜けている。

   **こう直せばもっと強くなる：** 企画書に、検索結果・共有時に使う説明文案を加える。

   > π0.5を自分の小型アームで試すための入口。アーム不要の推論・LIBERO、追加学習の条件、mechArm 270で確認した実機の問題と、再現に足りない情報をまとめます。

   シリーズ上部と既存LPのリンク先は、ページ先頭だけでなく該当段へ直接つなぐ。LinkedInも「アームなしで試す段」へ送る。AI向けには、各段の結果と環境情報のすぐ横に根拠ログを置く。

   効果の説明は、次に限定する。

   > 手順・条件・結果・未確認情報を根拠ログと組で示すことで、検索やAIの回答から参照されやすくなると考える（推測）。

8. **【高】制作を止める条件から「3か月」が抜けている**

   **弱い所：** 「30件未満かつ連絡0件なら追加の制作を止める」では、公開直後にも停止条件が成立する。依頼の判断時期と異なる。また、最も重い連絡を単なる有無で見ると、再現への貢献が分からない。

   **こう直せばもっと強くなる：** 評価方針を次に差し替える。

   > 最初の判断は、人の表示が30件たまった時点で行う。30件未満の間は、閲覧率や遷移率から良し悪しを言い切らない。公開から3か月で表示30件未満、かつ対象となる連絡が0件なら、追加制作を止めてページを残す。  
   > 連絡は「試そうとして不足情報で止まった」「試した結果が届いた」「別環境で再現できた」に分けて記録する。第三者の確認で判明した不足情報と、その解消状況も残す。

   これなら、連絡1件を主指標の判定にどうつなげるかまで追える。

**守るべき尖り**

「肩約88°を超えると、命令がエラーなしに捨てられた」という具体の実例を、読者自身のアームへの確認の問いに変えるところ。抽象的な注意書きでは得られない、実験前に保存しておく理由になる。この具体性は、書き直しでも薄めないでほしい。
```


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

```markdown
【採否】
案A
1【高】採る。主指標の判定③に直結し、足りない情報を見せるという依頼に沿うため。
2【高】採る。「どのアームでも起こりうる」は事実誤認の言い過ぎであり、必ず直すため。
3【高】採る。ルール（要約にないものは照合要とする）の適用漏れと事実誤認を直すため。
4【中】採る。読者が自分のアームで確かめるための実用性が高まるため。
5【中】採る。言い過ぎの修正であり、読者が結果を照らし合わせやすくなるため。
6【中】採る。いちばん重いゴール（試した人からの連絡）への導線を強化するため。
7【中】採る。3段構成のルールを守り、未解決部分を見せて読者の参加を促すため。
8【中】採る。検索やAIからの流入意図に沿った具体的な見出しと導線にするため。

案C
1【高】一部採る。言い過ぎの修正は採るが、共通書式は案A-1の環境表に統合して見せるため。
2【高】採る。ルール違反（断定）の修正であり、再現に必要な情報を網羅するため。
3【高】採る。事実誤認（言い過ぎ）の修正であり、他機種への効果の約束を避けるため。
4【高】採る。読者が学習条件を決める際の期待値を事実の範囲で正しく調整するため。
5【中】一部採る。冒頭の行き先とリンク文の改善は採るが、通し記録の配置は案A-7の形を採るため。
6【高】採る。連絡のハードルを下げ、主指標に貢献する情報を集めやすくするため。
7【中】採る。ルールの「推測と書く」を満たし、流入の設計を具体化するため。
8【高】採る。依頼の「3か月」という条件に正確に合わせるため。

---

【企画書】

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

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

### この人がこのページで得るもの
手順・使ったもの・結果をまとめ、再現に必要な情報のうち、確認できたものと足りないものを示します。

### 最初の画面
**π0.5 を自分の小型アームで動かし始める：アームなしの推論から、実機で確かめる項目まで**
アームを使わずに試せる2つの実例です。π0.5 は Mac では動かないが、Runpod で A40 を借りれば動いた。推論は平均97ms・往復391ms・費用0.34ドル（Log#2）。LIBERO では20回中20回成功（Log#3）。あなたの環境でこの数字になるかを確かめられます。
自分のアームで追加学習するなら、お手本の集め方と学習の条件はここにまとめた。
mechArm 270 で確認した実機の問題と、再現に足りない情報も示します。

**今の状態から選ぶ**
・まだアームを使わない → 推論とシミュレーション
・お手本を集めて学習したい → 収集方法と学習条件
・実機が指令どおりに動かない → 実機で動かす前後に確かめる項目

**使ったものの表（版が埋まっているのは3行。残りは照合中）**
| 段 | 使ったもの | 版・条件 | 状態 | 根拠 |
|---|---|---|---|---|
| 1 | 借りた GPU | Runpod・A40 | 記載あり | Log#2・#3 |
| 1 | 送る側 | Mac（π0.5 は Mac では動かなかった） | 記載あり | Log#2 |
| 1 | π0.5 を動かすコードと版 | — | 要約には記載なし（本文とコードで照合が要る） | Log#2 |
| 1 | LIBERO の版 | — | 要約には記載なし（本文とコードで照合が要る） | Log#3 |
| 1 | Pythonや依存関係 | — | 要約には記載なし（本文とコードで照合が要る） | Log#2・#3 |
| 2 | 学習に使った GPU | A40 | 記載あり | Log#4・#10・#27 |
| 3 | 制御ライブラリ | pymycobot 2.9.6（4.0.4 では1指令1.6秒） | 記載あり | Log#20 |
| 3 | アーム側の中継 | Pi の daemon（Pi の型は要照合） | 一部記載あり | Log#20 |
| 3 | 電源 | 12V・5A（本体は40Wを求める。12V・2A＝24Wでは落とした） | 記載あり | Log#30・#34 |

### 見せ場
「実機で動かす前後に確かめる項目」の段。指令を送ったとき、実機はその姿勢まで動いているか。mechArm 270では、肩を約88°より深く倒した姿勢の命令が、エラーなしに捨てられていた（Log#9）。この具体の実例を、読者自身のアームの可動範囲と応答を確かめる問いに変えて提示する点。

### 構成
**1. アームなしで、誰でも同じ結果まで行ける段：π0.5 は Mac で動くか**
RunpodのA40でπ0.5を動かし、Macから画像と指示を送り動きの数値を受け取る推論を通した。
**照らし合わせる数字**：推論平均97ms・往復391ms（Log#2）。LIBEROで20回中20回（Log#3）。
別の環境で同じ結果になるかは、このページではまだ確認できていない。
［この段で止まったら、足りない情報を送る（版や機材名は分かる範囲で可）］→ /message（※ほかの環境での記録：まだ0件）
使うログ：Log#2（326）、Log#3（327）

**2. 自分のアームで追加学習する段：追加学習で使った条件と、その後に確かめた結果**
- **お手本の集め方**：手で姿勢を教え再生しながら録る（5か所19本）、ゲームパッドで教え直して深いつかみにする（5か所10本ずつ）。
- **学習の条件と結果**（あなたのアームに必要な条件は、この記録からは決められない）：
| ログ | 本数 | 始め方 | ステップ | loss | 到達点・未達 | 学習時間・費用 | GPU待ち |
|---|---|---|---|---|---|---|---|
| Log#4 | 2 | 要照合 | 200 | 0.1031→0.0162 | Macで予測受信。実機未実施 | 要照合 | 要照合 |
| Log#5 | 19 | 要照合 | 2000 | 0.1155→0.0054 | 予測がお手本最初の1秒と数度以内で一致 | 要照合 | 要照合 |
| Log#7 | 19 | 要照合 | 4000 | 0.0030まで | 爪がブロックの奥で空を閉じた | 要照合 | 要照合 |
| Log#10 | 19 | 要照合 | 4000 | 0.0858→0.0037 | 要照合 | 要照合 | 約4.5時間 |
| Log#17 | 5 | 続けて | 1500 | 要照合 | 成功6回はすべて補正つき（Log#18） | 要照合 | 要照合 |
| Log#27 | 50 | 一から | 3000 | 0.1015→0.0036 | 位置1で補正なしでつかむ。位置2は届かず（Log#28） | 6.2時間・約579円 | 要照合 |
※「要照合」は「要約には記載なし（本文とコードで照合が要る）」の略。
**教訓**：予測がお手本の最初の1秒と数度以内で一致しても（Log#5）、実機では爪がブロックに乗った（Log#6）。lossを0.0030まで下げても、爪は奥で空を閉じた（Log#7）。
［予測は合うのに実機で届かない経過を読む：Log#5・#6・#7］
使うログ：Log#4、Log#5、Log#7、Log#8、Log#9、Log#10、Log#17、Log#25、Log#26、Log#27

**3. 実機で動かす前後に確かめる項目：指令どおりに動かないのはなぜか**
あなたのアームで確かめる問いと、mechArm 270での見分け方・対処結果。
- **関節の可動範囲の外で、命令が黙って捨てられていないか**：肩を約88°より深く倒した姿勢は、エラーが出ないまま動かなかった（Log#9。どう避けたかは要照合）。
- **電源は足りているか**：本体は40Wを求めるのに12V・2A（24W）をつないでいた。12V・5Aに替えた日は位置5で5回中5回成功（2Aの日は3回中1回）（Log#30・#34）。［電源を替えた前後の結果を確かめる：Log#30・#34］
- **制御ライブラリの版で指令が遅れていないか**：1指令1.6秒 → 2.9.6に戻すと送信約0.02秒（Log#20。推奨版を示すものではない）。
- **お手本が浅いつかみになっていないか**：失敗の主因は浅いつかみ。爪がブロックに乗った回は、下ろす時間が普段の1.1秒に対し7.9〜9.1秒だった（Log#23・#25）。動画を目で見るか下ろす時間で確かめる。
- **AIに渡す今の関節角度は、何の値か**：AIに渡す肩の角度を直前の目標に変えただけで、毎回約2°足りず箱に当てていた動きが直った（Log#12）。

**4. mechArm 270 の通し記録（1台で最後まで通した線）**
- Log#6：初めて実機で動かし、爪がブロックに乗った
- Log#12：初めて箱に入れた
- Log#14時点の測定：15回中9回（位置C 5/5・E 3/5・D 1/5）
- Log#34：電源を替え、位置5 で5回中5回
未解決：位置2で下りない理由は、上カメラの傾きではなかった（Log#29）。原因はまだ分かっていない。

**5. 試した記録を送る**
各段の終わりに置いた送る道を再掲。「試したい段／試したこと、または始められない理由／足りない情報」だけでも送れる。
※他の環境での記録として掲載してよいかもお知らせください。

### 束ねるログ
Log#2(326), Log#3(327), Log#4(337), Log#5(341), Log#6(345), Log#7(348), Log#8(349), Log#9(352), Log#10(355), Log#12(361), Log#14(401), Log#17(417), Log#18(422), Log#20(436), Log#23(460), Log#25(463), Log#26(479), Log#27(480), Log#28(484), Log#29(486), Log#30(487), Log#34(504)

### 今あるページとのつなぎ方
- **AIの答え**：ページの頭に要点と使ったものの表を本文の文字で置く。各段の結果と環境情報のすぐ横に根拠ログを置く。手順・条件・結果・未確認情報を根拠ログと組で示すことで、検索やAIの回答から参照されやすくなると考える（推測）。
- **/gpu-buy-or-rent**：読まれている前半に「借りたGPUでπ0.5を試す手順と条件を見る」として該当段へ直接つなぐ。
- **シリーズのページ**：「フィジカルAI研究室を作る」シリーズ上部に固定し、該当段へ直接つなぐ。
- **LinkedIn**：「アームなしで試す段」へ送る紹介文で投稿する。窓口は出さない。
- **検索向け説明文案**：π0.5を自分の小型アームで試すための入口。アーム不要の推論・LIBERO、追加学習の条件、mechArm 270で確認した実機の問題と、再現に足りない情報をまとめます。

### 公開後に見る数字
最初の判断は、人の表示が30件たまった時点で行う。30件未満の間は、閲覧率や遷移率から良し悪しを言い切らない。公開から3か月で表示30件未満、かつ対象となる連絡が0件なら、追加制作を止めてページを残す。
連絡は「試そうとして不足情報で止まった」「試した結果が届いた」「別環境で再現できた」に分けて記録する。第三者の確認で判明した不足情報と、その解消状況も残す。
- このページの人の表示数（目標150件）と最後まで読んだ割合（75%到達率）
- 表示した人のうち、ログへ進んだ人の割合（目標3割）
- AIの利用者の依頼で読みに来た数（2か月目から週3件以上）
- AIのリンクから来た人（月1件以上）

### ゴールにどう効くか
| 見るもの | 効く理由と、効かないかもしれない理由 |
|---|---|
| このページの人の表示 | **効く理由**：「π0.5 追加学習 手順」の検索意図に具体的に応えるため。**効かない理由**：小型アームで公開モデルを動かす絶対数が少なく、検索ボリュームがない可能性。 |
| このページからログへ進んだ人 | **効く理由**：未解決の課題や「要照合」を示すことで、読者が自ら詳細をログで確かめたくなるため。**効かない理由**：確認リストの項目だけで満足し、詳細確認まで求めない可能性。 |
| AI の利用者の依頼で読みに来た数 | **効く理由**：使ったものの表や結果を文字と根拠ログの組で示し、AIが答えの材料にしやすいと考えるため（推測）。**効かない理由**：AIのクエリが個別のログに直接ヒットし、経由しない可能性。 |
| 問い合わせ・相談 | **効く理由**：各段に「足りない情報」を送る道を置き、項目を緩和してハードルを下げたため。**効かない理由**：試すこと自体のハードルが高く、3か月以内に検証までたどり着く人が現れない可能性。 |
```


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

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

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

### この人がこのページで得るもの
手順・使ったもの・結果をまとめ、再現に必要な情報のうち、確認できたものと足りないものを示します。

### 最初の画面
**π0.5 を自分の小型アームで動かし始める：アームなしの推論から、実機で確かめる項目まで**
アームを使わずに試せる2つの実例です。π0.5 は Mac では動かないが、Runpod で A40 を借りれば動いた。推論は平均97ms・往復391ms・費用0.34ドル（Log#2）。LIBERO では20回中20回成功（Log#3）。あなたの環境でこの数字になるかを確かめられます。
自分のアームで追加学習するなら、お手本の集め方と学習の条件はここにまとめた。
mechArm 270 で確認した実機の問題と、再現に足りない情報も示します。

**今の状態から選ぶ**
・まだアームを使わない → 推論とシミュレーション
・お手本を集めて学習したい → 収集方法と学習条件
・実機が指令どおりに動かない → 実機で動かす前後に確かめる項目

**使ったものの表（版が埋まっているのは3行。残りは照合中）**
| 段 | 使ったもの | 版・条件 | 状態 | 根拠 |
|---|---|---|---|---|
| 1 | 借りた GPU | Runpod・A40 | 記載あり | Log#2・#3 |
| 1 | 送る側 | Mac（π0.5 は Mac では動かなかった） | 記載あり | Log#2 |
| 1 | π0.5 を動かすコードと版 | — | 要約には記載なし（本文とコードで照合が要る） | Log#2 |
| 1 | LIBERO の版 | — | 要約には記載なし（本文とコードで照合が要る） | Log#3 |
| 1 | Pythonや依存関係 | — | 要約には記載なし（本文とコードで照合が要る） | Log#2・#3 |
| 2 | 学習に使った GPU | A40 | 記載あり | Log#4・#10・#27 |
| 3 | 制御ライブラリ | pymycobot 2.9.6（4.0.4 では1指令1.6秒） | 記載あり | Log#20 |
| 3 | アーム側の中継 | Pi の daemon（Pi の型は要照合） | 一部記載あり | Log#20 |
| 3 | 電源 | 12V・5A（本体は40Wを求める。12V・2A＝24Wでは落とした） | 記載あり | Log#30・#34 |

### 見せ場
「実機で動かす前後に確かめる項目」の段。指令を送ったとき、実機はその姿勢まで動いているか。mechArm 270では、肩を約88°より深く倒した姿勢の命令が、エラーなしに捨てられていた（Log#9）。この具体の実例を、読者自身のアームの可動範囲と応答を確かめる問いに変えて提示する点。

### 構成
**1. アームなしで、誰でも同じ結果まで行ける段：π0.5 は Mac で動くか**
RunpodのA40でπ0.5を動かし、Macから画像と指示を送り動きの数値を受け取る推論を通した。
**照らし合わせる数字**：推論平均97ms・往復391ms（Log#2）。LIBEROで20回中20回（Log#3）。
別の環境で同じ結果になるかは、このページではまだ確認できていない。
［この段で止まったら、足りない情報を送る（版や機材名は分かる範囲で可）］→ /message（※ほかの環境での記録：まだ0件）
使うログ：Log#2（326）、Log#3（327）

**2. 自分のアームで追加学習する段：追加学習で使った条件と、その後に確かめた結果**
- **お手本の集め方**：手で姿勢を教え再生しながら録る（5か所19本）、ゲームパッドで教え直して深いつかみにする（5か所10本ずつ）。
- **学習の条件と結果**（あなたのアームに必要な条件は、この記録からは決められない）：
| ログ | 本数 | 始め方 | ステップ | loss | 到達点・未達 | 学習時間・費用 | GPU待ち |
|---|---|---|---|---|---|---|---|
| Log#4 | 2 | 要照合 | 200 | 0.1031→0.0162 | Macで予測受信。実機未実施 | 要照合 | 要照合 |
| Log#5 | 19 | 要照合 | 2000 | 0.1155→0.0054 | 予測がお手本最初の1秒と数度以内で一致 | 要照合 | 要照合 |
| Log#7 | 19 | 要照合 | 4000 | 0.0030まで | 爪がブロックの奥で空を閉じた | 要照合 | 要照合 |
| Log#10 | 19 | 要照合 | 4000 | 0.0858→0.0037 | 要照合 | 要照合 | 約4.5時間 |
| Log#17 | 5 | 続けて | 1500 | 要照合 | 成功6回はすべて補正つき（Log#18） | 要照合 | 要照合 |
| Log#27 | 50 | 一から | 3000 | 0.1015→0.0036 | 位置1で補正なしでつかむ。位置2は届かず（Log#28） | 6.2時間・約579円 | 要照合 |
※「要照合」は「要約には記載なし（本文とコードで照合が要る）」の略。
**教訓**：予測がお手本の最初の1秒と数度以内で一致しても（Log#5）、実機では爪がブロックに乗った（Log#6）。lossを0.0030まで下げても、爪は奥で空を閉じた（Log#7）。
［予測は合うのに実機で届かない経過を読む：Log#5・#6・#7］
使うログ：Log#4、Log#5、Log#7、Log#8、Log#9、Log#10、Log#17、Log#25、Log#26、Log#27

**3. 実機で動かす前後に確かめる項目：指令どおりに動かないのはなぜか**
あなたのアームで確かめる問いと、mechArm 270での見分け方・対処結果。
- **関節の可動範囲の外で、命令が黙って捨てられていないか**：肩を約88°より深く倒した姿勢は、エラーが出ないまま動かなかった（Log#9。どう避けたかは要照合）。
- **電源は足りているか**：本体は40Wを求めるのに12V・2A（24W）をつないでいた。12V・5Aに替えた日は位置5で5回中5回成功（2Aの日は3回中1回）（Log#30・#34）。［電源を替えた前後の結果を確かめる：Log#30・#34］
- **制御ライブラリの版で指令が遅れていないか**：1指令1.6秒 → 2.9.6に戻すと送信約0.02秒（Log#20。推奨版を示すものではない）。
- **お手本が浅いつかみになっていないか**：失敗の主因は浅いつかみ。爪がブロックに乗った回は、下ろす時間が普段の1.1秒に対し7.9〜9.1秒だった（Log#23・#25）。動画を目で見るか下ろす時間で確かめる。
- **AIに渡す今の関節角度は、何の値か**：AIに渡す肩の角度を直前の目標に変えただけで、毎回約2°足りず箱に当てていた動きが直った（Log#12）。

**4. mechArm 270 の通し記録（1台で最後まで通した線）**
- Log#6：初めて実機で動かし、爪がブロックに乗った
- Log#12：初めて箱に入れた
- Log#14時点の測定：15回中9回（位置C 5/5・E 3/5・D 1/5）
- Log#34：電源を替え、位置5 で5回中5回
未解決：位置2で下りない理由は、上カメラの傾きではなかった（Log#29）。原因はまだ分かっていない。

**5. 試した記録を送る**
各段の終わりに置いた送る道を再掲。「試したい段／試したこと、または始められない理由／足りない情報」だけでも送れる。
※他の環境での記録として掲載してよいかもお知らせください。

### 束ねるログ
Log#2(326), Log#3(327), Log#4(337), Log#5(341), Log#6(345), Log#7(348), Log#8(349), Log#9(352), Log#10(355), Log#12(361), Log#14(401), Log#17(417), Log#18(422), Log#20(436), Log#23(460), Log#25(463), Log#26(479), Log#27(480), Log#28(484), Log#29(486), Log#30(487), Log#34(504)

### 今あるページとのつなぎ方
- **AIの答え**：ページの頭に要点と使ったものの表を本文の文字で置く。各段の結果と環境情報のすぐ横に根拠ログを置く。手順・条件・結果・未確認情報を根拠ログと組で示すことで、検索やAIの回答から参照されやすくなると考える（推測）。
- **/gpu-buy-or-rent**：読まれている前半に「借りたGPUでπ0.5を試す手順と条件を見る」として該当段へ直接つなぐ。
- **シリーズのページ**：「フィジカルAI研究室を作る」シリーズ上部に固定し、該当段へ直接つなぐ。
- **LinkedIn**：「アームなしで試す段」へ送る紹介文で投稿する。窓口は出さない。
- **検索向け説明文案**：π0.5を自分の小型アームで試すための入口。アーム不要の推論・LIBERO、追加学習の条件、mechArm 270で確認した実機の問題と、再現に足りない情報をまとめます。

### 公開後に見る数字
最初の判断は、人の表示が30件たまった時点で行う。30件未満の間は、閲覧率や遷移率から良し悪しを言い切らない。公開から3か月で表示30件未満、かつ対象となる連絡が0件なら、追加制作を止めてページを残す。
連絡は「試そうとして不足情報で止まった」「試した結果が届いた」「別環境で再現できた」に分けて記録する。第三者の確認で判明した不足情報と、その解消状況も残す。
- このページの人の表示数（目標150件）と最後まで読んだ割合（75%到達率）
- 表示した人のうち、ログへ進んだ人の割合（目標3割）
- AIの利用者の依頼で読みに来た数（2か月目から週3件以上）
- AIのリンクから来た人（月1件以上）

### ゴールにどう効くか
| 見るもの | 効く理由と、効かないかもしれない理由 |
|---|---|
| このページの人の表示 | **効く理由**：「π0.5 追加学習 手順」の検索意図に具体的に応えるため。**効かない理由**：小型アームで公開モデルを動かす絶対数が少なく、検索ボリュームがない可能性。 |
| このページからログへ進んだ人 | **効く理由**：未解決の課題や「要照合」を示すことで、読者が自ら詳細をログで確かめたくなるため。**効かない理由**：確認リストの項目だけで満足し、詳細確認まで求めない可能性。 |
| AI の利用者の依頼で読みに来た数 | **効く理由**：使ったものの表や結果を文字と根拠ログの組で示し、AIが答えの材料にしやすいと考えるため（推測）。**効かない理由**：AIのクエリが個別のログに直接ヒットし、経由しない可能性。 |
| 問い合わせ・相談 | **効く理由**：各段に「足りない情報」を送る道を置き、項目を緩和してハードルを下げたため。**効かない理由**：試すこと自体のハードルが高く、3か月以内に検証までたどり着く人が現れない可能性。 |
```


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

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

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

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

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

小型アームを持ち、π0.5を追加学習したい開発者。日本語でAIに始め方を聞き、このページへ来る。

コードは読めるが、「モデルが動かない」のか「自分のアームとの接続が合っていない」のかを切り分ける足場がない。別機種の成功動画だけでは、何をそろえれば始められるか判断できずにいる。

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

アームなしで結果を照合するところから、自分のアームのお手本を集め、実機で確かめるところまで、次に開く手順と不足情報が分かる。

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

**自分のアームでπ0.5を動かす。その前に、同じ結果まで確かめる。**

まずはアームなしで、借りたGPUから動きの数値を受け取る。  
次に、お手本を集めて追加学習し、自分のアームで確かめる。  
手順・環境・結果を並べ、再現に足りない情報もここに残します。

直下に「アームなしで始める」「お手本と学習を見る」「実機の確認項目へ」のページ内リンクを置く。

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

**「できた」の終点を混ぜない照合表。**

動きの数値を受け取れた／シミュレーションで成功した／追加学習が終わった／実機でつかめた／箱に入った、を別々に示す。

Log#3のシミュレーション20回すべて成功と、Log#28の実機で位置2を4回ともつかめなかった結果を、同じ「動いた」にまとめない。Log#34の電源交換後の成功も、mechArm 270の特定条件の結果として置く。

各行を「やること｜使用環境と版｜照合する結果｜未記載情報｜手順のログ」で統一する。機材を替えた読者が、引き継げる部分と、自分で確認する部分を見分けられることが価値。

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

以下の使用ログ番号は、末尾のURL一覧に対応する。

**1．アームなしで、動きの数値を受け取る〔第1段〕**  
使用：Log#2。Macから画像と指示文を送り、借りたA40から予測を受け取った経路を示す。記録値は推論平均97ms、往復391ms、費用0.34ドル。速度や費用の再現保証にはしない。接続・起動手順、依存関係と版は「要約には記載なし（本文とコードで照合が要る）」。

**2．アームなしで、作業の結果を照合する〔第1段〕**  
使用：Log#3。A40上のLIBEROで、黒いボウルを拾って皿に置く作業が20回すべて成功。手順の到達点をここに置く。GPUメモリは測定済みだが、値は要約には記載なし。環境の版・実行条件とともに本文とコードで照合する。

**3．自分のアームで、何をお手本にするか〔第2段〕**  
使用：Log#9・23・26。手で教えた動きを再生しながら録る方法、浅いつかみが学習データ30本中7本に含まれた事実、教え直して5か所10本ずつそろえた経緯を書く。50本を必要本数とは言わない。自分のアーム用の記録・データ変換に必要な情報は、照合対象として明示する。

**4．追加学習の条件と、実機の結果を対で読む〔第2段〕**  
使用：Log#27・28。深いお手本50本、A40、3,000ステップ、6.2時間、約579円という実測条件を掲載。学習後は位置1で3回とも補正なしでつかめた一方、位置2では4回ともつかむ姿勢まで届かなかった。費用は当時の実測で、読者の予算見積もりとは分ける。学習設定と依存関係の版は本文・コードで照合する。

**5．自分のアームで照合する三つの問い〔第3段〕**  
使用：Log#9・20・30・34。  
「可動範囲外の命令が黙って捨てられないか」には肩約88°超の例。「指令の遅さは制御ライブラリの版によらないか」には、pymycobot 4.0.4から2.9.6へ戻して送信が約0.02秒になった例。「電源は足りているか」には、要求40Wに対し24Wだった記録と、12V・5Aへの交換後に位置5で5回すべて成功した例を添える。どれも他機種への設定指示にはしない。

**6．再現できた所・止まった所を残す**  
各段の不足情報を一覧にする。照合後も見つからなければ「ログにない（未記載）」と表示。手順・依存関係と版・第三者確認の有無を別々に示し、このページを作っただけで「再現可能」と数えない。末尾の「試した記録を送る」から、アーム・環境・到達点・止まった箇所を添えて `/message` へ進める。

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

- Log#2：/record/openpi-remote-inference-first-run
- Log#3：/record/pi05-libero-benchmark-first-run
- Log#9：/record/teach-replay-19-demos
- Log#20：/record/gamepad-moves-mecharm-270-pymycobot-version
- Log#23：/record/pi05-failures-traced-to-shallow-grasp-demos
- Log#26：/record/even-ten-demos-per-spot-mecharm-270-reteaching
- Log#27：/record/retrain-pi05-from-base-on-50-even-demos
- Log#28：/record/pi05-even-demos-on-arm-misses-position-2
- Log#30：/record/mecharm-270-drops-block-underpowered-adapter
- Log#34：/record/mecharm-270-5a-adapter-stops-dropping-block

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

主な入口は検索・AIの回答・該当シリーズ・既存LP。検索とAIには、各段の手順・環境・結果・未記載情報を本文の表として読めるようにする。

シリーズ上部の資料に本ページを追加。`/gpu-buy-or-rent` の借りる選択から、第1段へ送る。トップは既存のシリーズ欄から案内する。SNSは第1段の実測結果とページへのリンクを投稿する。相談窓口は出さない。個々のログは変更しない。

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

人の表示、閲覧者のうちログを1本以上開いた人の割合、段別のリンク利用、AIによる取得、AI経由の訪問、再現に関する連絡を分けて記録する。人の表示が30件に届くまでは成否を判断しない。

3か月で30件未満かつ連絡0件なら、ページを残して追加制作を止める。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

- **人の表示150件：** 検索・AI・既存LPから具体的な開始地点へ送れる。ただし検索で見つかるまでの時間があり、達成は読めない。
- **ログへ3割：** 各段に目的のある手順リンクを置く。表だけで用が済み、移動しない可能性もある。
- **AIの取得が週3件以上：** 条件と結果を一枚で参照できる。AIに選ばれる保証はない。
- **AI経由の人が月1件以上：** 「自分のアームで始める」質問の参照先になる。回答内で完結する可能性もある。
- **再現に関する連絡1〜2件：** 到達点と不足情報を送れる導線を置く。試す負担は残る。第三者の再現記録、または情報の充足確認まで得られれば、主指標の判定根拠になる。
```


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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

---

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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

---

## 守るべき尖り

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

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


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

```markdown
案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回目）

```markdown
【採否】

- A1：一部採る。第1段は本文・コードの照合後に公開する。ただし照合完了と情報充足は分け、未記載が残れば再現可能とは数えない。
- A2：一部採る。各段に途中・着手前でも送れる導線を置く。ただし不足の報告だけでは、主指標③を満たさない。
- A3：採る。予測の一致・学習誤差の低下・実機の成功を分けることで、照合表の核を強くする。
- A4：一部採る。冒頭に具体的な到達点を出す。他機種でも手順が通ると読める見出しと、数字の詰め込みは避ける。
- A5：一部採る。掲載位置と文面を決める。少数の閲覧実績から最適な配置や媒体とは判断しない。
- A6：一部採る。実行中の版、電源交換前後、浅いつかみを採る。問いを増やしすぎず、停止時間の話は今回は束ねない。
- A7：一部採る。試行時の電源条件と原因の未確認を明示する。「原因は未特定」と断定せず、要約で確認できる範囲を示す。
- B1：一部採る。各段に実行手順へのリンクを置く。ただし移動率のために必要情報を隠さず、コードの所在も照合して案内する。
- B2：採る。「可動範囲外」は要約から断定できないため削り、「命令がエラーなしに捨てられないか」に直す。
- B3：一部採る。補う箇所が分かる価値を伝える。ただし記録側の不足を読者の責任にせず、未記載の列は残す。
- B4：一部採る。次の人の開始地点を整える用途を伝える。報告だけで研究が再現可能になるとは言わない。
- B5：一部採る。技術名と作業を見出しに入れる。AIに拾われやすくなる効果は仮説として扱う。
- B6：一部採る。収集時に確認する観点へ変える。本数は実例であり、他機種の必要量や合格基準にはしない。

【企画書】

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

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

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

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

小型アームを持ち、日本語でAIにπ0.5の始め方を聞いて来た開発者。コードは読めるが、モデル・学習データ・実機接続のどこで止まったかを切り分けられずにいる。

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

アームなしの推論から、自分のアームでのお手本収集・追加学習・実機確認まで、次に開く手順と照合すべき結果が分かる。

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

**π0.5を始める。推論・追加学習・実機の結果を分けて確かめる。**

アームなし：借りたA40で予測を受け取り、LIBEROでは20回すべて成功した記録があります（Log#2・3）。  
追加学習：mechArm 270で使ったお手本・学習条件・実機結果を並べます。  
実機確認：同機で詰まった点を、自分のアームで確かめる問いにします。

直下に「アームなし」「お手本と学習」「実機確認」の段内リンク。

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

**「できた」の終点と、未記載情報を混ぜない照合表。**

予測の受信／シミュレーション成功／学習完了／実機前の予測一致／実機でつかむ／箱に入れる、を分ける。Log#5〜7では、予測がお手本と合い、学習誤差が下がっても実機で外れた経過を示す。

列は「やること｜環境と版｜照合する結果｜未記載情報｜照合状態｜手順のログ」。状態は「照合済み・出典」「要約には記載なし（本文とコードで照合が要る）」「ログにない（未記載）」とする。再現の不足を表の正面に残す。

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

使用ログ番号は下のURL一覧に対応する。各節の冒頭に、作業名を付けた手順リンクを置く。

**1．借りたA40でπ0.5の推論を動かす〔第1段〕**  
Log#2。Macから画像・指示文を送り、予測を受信。推論平均97ms、往復391ms、費用0.34ドルはこの実験の記録値とする。起動手順・依存関係と版は要約には記載なし（本文とコードで照合が要る）。

**2．LIBEROで作業結果を照合する〔第1段〕**  
Log#3。A40上で黒いボウルを拾って皿に置き、20回すべて成功。GPUメモリは測定済みだが値は要約には記載なし。第1段は、手順・依存関係と版・実行条件・メモリ値の本文とコードの照合を終えて公開する。見つからない項目は未記載とし、情報がそろった扱いにしない。

**3．自分のアームのお手本を集める〔第2段〕**  
Log#9・23・26。手で教えて再生しながら19本収集、別の学習データ30本中7本に浅いつかみ、教え直して5か所10本ずつ収集した事実を並べる。「成功した動きの何を録るか」「場所ごとに偏っていないか」を持ち帰れる形にする。本数は必要量としない。自機用の記録・変換手順は要約には記載なし（本文とコードで照合が要る）。

**4．追加学習と実機の到達点を分ける〔第2段〕**  
Log#5〜7では19本・2,000ステップで予測がお手本の最初の1秒と数度以内で一致。それでも初回実機では爪がブロックに乗り、4,000ステップ・学習誤差0.0030でも2回とも奥で空振りした。

Log#27・28では深いお手本50本、A40、3,000ステップ、6.2時間、約579円。位置1は3回とも補正なしでつかめたが、位置2は4回とも姿勢まで届かなかった。この試行の電源条件は要約には記載なし。Log#29の画像傾斜変更1,770回では行き先が入れ替わらず、要約だけでは位置2の原因を特定できない。学習設定・版も本文とコードで照合する。

**5．自分のアームで確かめる問い〔第3段〕**  
以下はmechArm 270の実例。他機種での結果・設定値は示さない。

- 命令がエラーなしに捨てられないか：肩約88°より深い姿勢で発生（Log#9）。
- 動いているプロセスはどの版を読むか：Piの常駐処理がpymycobot 4.0.4を読み、指令1回1.6秒。2.9.6で送信約0.02秒（Log#20）。
- お手本は深くつかんでいるか：30本中7本が浅かった（Log#23）。
- 電源は足りるか：要求40Wに対し24W（Log#30）。12V・5Aへの交換後、位置5は5回すべて成功。2Aの日は3回中1回。教えた動きの再生も7回すべて成功（Log#34）。

**6．到達点と不足を送り返す**  
各段末に「途中・着手前でも、届いた行と足りない情報を送る」から `/message` へ案内する。「次の人が始めるための不足確認に使います」と用途を示す。写せる項目は「π0.5入口ページ／アーム（なし可）／環境と版／届いた行／止まった所・不足情報」。手順・版・第三者確認を別々に管理し、不足報告だけで主指標を満たしたとは数えない。

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

- #2 /record/openpi-remote-inference-first-run
- #3 /record/pi05-libero-benchmark-first-run
- #5 /record/pi05-mecharm-lora-2000-steps
- #6 /record/pi05-mecharm-first-real-run
- #7 /record/pi05-mecharm-4000-steps
- #9 /record/teach-replay-19-demos
- #20 /record/gamepad-moves-mecharm-270-pymycobot-version
- #23 /record/pi05-failures-traced-to-shallow-grasp-demos
- #26 /record/even-ten-demos-per-spot-mecharm-270-reteaching
- #27 /record/retrain-pi05-from-base-on-50-even-demos
- #28 /record/pi05-even-demos-on-arm-misses-position-2
- #29 /record/pi05-position-2-miss-caused-by-camera-tilt
- #30 /record/mecharm-270-drops-block-underpowered-adapter
- #34 /record/mecharm-270-5a-adapter-stops-dropping-block

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

該当シリーズ上部の資料欄先頭、トップの既存シリーズ欄にページ名でリンクする。シリーズ番号は確認する。

`/gpu-buy-or-rent` の借りる説明直後に「借りたA40でπ0.5を動かす手順と結果」を第1段へ置く。LinkedInにも第1段の事実とリンクを投稿する。検索・AI向けには技術名、条件、結果、出典を本文で読める形にする。個々のログは変更せず、トップ・SNSに相談窓口は出さない。

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

人の表示、ログを開いた人の割合、段別リンク利用、利用者の依頼によるAI取得、AIリンク経由の人、再現関連の連絡を分ける。人の表示30件までは判断しない。3か月で30件未満かつ連絡0件なら追加制作を止め、ページは残す。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

以下は依頼の目標値。

- **3か月150件：** 開始地点への入口を増やす。ただし発見される時期は読めない。
- **ログへ3割：** 作業別の手順リンクで送る。表だけで用が済む可能性もある。
- **AI取得が2か月目から週3件以上：** 条件と出典をまとめる。参照に選ばれる保証はない。
- **AI経由で月1件以上：** 始め方の回答から送れる。回答内で完結する可能性もある。
- **再現関連の連絡1〜2件：** 各段から途中の記録も送れる。実験と報告の負担は残る。

主指標は、公開手順・依存関係と版に加え、第三者の再現記録または情報充足の確認が得られた段だけを判定する。
```


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

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

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

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

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

小型アームを持ち、日本語でAIにπ0.5の始め方を聞いて来た開発者。コードは読めるが、モデル・学習データ・実機接続のどこで止まったかを切り分けられずにいる。

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

アームなしの推論から、自分のアームでのお手本収集・追加学習・実機確認まで、次に開く手順と照合すべき結果が分かる。

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

**π0.5を始める。推論・追加学習・実機の結果を分けて確かめる。**

アームなし：借りたA40で予測を受け取り、LIBEROでは20回すべて成功した記録があります（Log#2・3）。  
追加学習：mechArm 270で使ったお手本・学習条件・実機結果を並べます。  
実機確認：同機で詰まった点を、自分のアームで確かめる問いにします。

直下に「アームなし」「お手本と学習」「実機確認」の段内リンク。

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

**「できた」の終点と、未記載情報を混ぜない照合表。**

予測の受信／シミュレーション成功／学習完了／実機前の予測一致／実機でつかむ／箱に入れる、を分ける。Log#5〜7では、予測がお手本と合い、学習誤差が下がっても実機で外れた経過を示す。

列は「やること｜環境と版｜照合する結果｜未記載情報｜照合状態｜手順のログ」。状態は「照合済み・出典」「要約には記載なし（本文とコードで照合が要る）」「ログにない（未記載）」とする。再現の不足を表の正面に残す。

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

使用ログ番号は下のURL一覧に対応する。各節の冒頭に、作業名を付けた手順リンクを置く。

**1．借りたA40でπ0.5の推論を動かす〔第1段〕**  
Log#2。Macから画像・指示文を送り、予測を受信。推論平均97ms、往復391ms、費用0.34ドルはこの実験の記録値とする。起動手順・依存関係と版は要約には記載なし（本文とコードで照合が要る）。

**2．LIBEROで作業結果を照合する〔第1段〕**  
Log#3。A40上で黒いボウルを拾って皿に置き、20回すべて成功。GPUメモリは測定済みだが値は要約には記載なし。第1段は、手順・依存関係と版・実行条件・メモリ値の本文とコードの照合を終えて公開する。見つからない項目は未記載とし、情報がそろった扱いにしない。

**3．自分のアームのお手本を集める〔第2段〕**  
Log#9・23・26。手で教えて再生しながら19本収集、別の学習データ30本中7本に浅いつかみ、教え直して5か所10本ずつ収集した事実を並べる。「成功した動きの何を録るか」「場所ごとに偏っていないか」を持ち帰れる形にする。本数は必要量としない。自機用の記録・変換手順は要約には記載なし（本文とコードで照合が要る）。

**4．追加学習と実機の到達点を分ける〔第2段〕**  
Log#5〜7では19本・2,000ステップで予測がお手本の最初の1秒と数度以内で一致。それでも初回実機では爪がブロックに乗り、4,000ステップ・学習誤差0.0030でも2回とも奥で空振りした。

Log#27・28では深いお手本50本、A40、3,000ステップ、6.2時間、約579円。位置1は3回とも補正なしでつかめたが、位置2は4回とも姿勢まで届かなかった。この試行の電源条件は要約には記載なし。Log#29の画像傾斜変更1,770回では行き先が入れ替わらず、要約だけでは位置2の原因を特定できない。学習設定・版も本文とコードで照合する。

**5．自分のアームで確かめる問い〔第3段〕**  
以下はmechArm 270の実例。他機種での結果・設定値は示さない。

- 命令がエラーなしに捨てられないか：肩約88°より深い姿勢で発生（Log#9）。
- 動いているプロセスはどの版を読むか：Piの常駐処理がpymycobot 4.0.4を読み、指令1回1.6秒。2.9.6で送信約0.02秒（Log#20）。
- お手本は深くつかんでいるか：30本中7本が浅かった（Log#23）。
- 電源は足りるか：要求40Wに対し24W（Log#30）。12V・5Aへの交換後、位置5は5回すべて成功。2Aの日は3回中1回。教えた動きの再生も7回すべて成功（Log#34）。

**6．到達点と不足を送り返す**  
各段末に「途中・着手前でも、届いた行と足りない情報を送る」から `/message` へ案内する。「次の人が始めるための不足確認に使います」と用途を示す。写せる項目は「π0.5入口ページ／アーム（なし可）／環境と版／届いた行／止まった所・不足情報」。手順・版・第三者確認を別々に管理し、不足報告だけで主指標を満たしたとは数えない。

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

- #2 /record/openpi-remote-inference-first-run
- #3 /record/pi05-libero-benchmark-first-run
- #5 /record/pi05-mecharm-lora-2000-steps
- #6 /record/pi05-mecharm-first-real-run
- #7 /record/pi05-mecharm-4000-steps
- #9 /record/teach-replay-19-demos
- #20 /record/gamepad-moves-mecharm-270-pymycobot-version
- #23 /record/pi05-failures-traced-to-shallow-grasp-demos
- #26 /record/even-ten-demos-per-spot-mecharm-270-reteaching
- #27 /record/retrain-pi05-from-base-on-50-even-demos
- #28 /record/pi05-even-demos-on-arm-misses-position-2
- #29 /record/pi05-position-2-miss-caused-by-camera-tilt
- #30 /record/mecharm-270-drops-block-underpowered-adapter
- #34 /record/mecharm-270-5a-adapter-stops-dropping-block

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

該当シリーズ上部の資料欄先頭、トップの既存シリーズ欄にページ名でリンクする。シリーズ番号は確認する。

`/gpu-buy-or-rent` の借りる説明直後に「借りたA40でπ0.5を動かす手順と結果」を第1段へ置く。LinkedInにも第1段の事実とリンクを投稿する。検索・AI向けには技術名、条件、結果、出典を本文で読める形にする。個々のログは変更せず、トップ・SNSに相談窓口は出さない。

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

人の表示、ログを開いた人の割合、段別リンク利用、利用者の依頼によるAI取得、AIリンク経由の人、再現関連の連絡を分ける。人の表示30件までは判断しない。3か月で30件未満かつ連絡0件なら追加制作を止め、ページは残す。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

以下は依頼の目標値。

- **3か月150件：** 開始地点への入口を増やす。ただし発見される時期は読めない。
- **ログへ3割：** 作業別の手順リンクで送る。表だけで用が済む可能性もある。
- **AI取得が2か月目から週3件以上：** 条件と出典をまとめる。参照に選ばれる保証はない。
- **AI経由で月1件以上：** 始め方の回答から送れる。回答内で完結する可能性もある。
- **再現関連の連絡1〜2件：** 各段から途中の記録も送れる。実験と報告の負担は残る。

主指標は、公開手順・依存関係と版に加え、第三者の再現記録または情報充足の確認が得られた段だけを判定する。
```


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

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

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

---

### 1【高】照合表の「箱に入れる」の行に、束ねるログの中の出典がない。第2段も失敗で終わっている

**弱い所**
- 見せ場の照合表には「実機でつかむ／箱に入れる」の行があります。ところが束ねるログには、箱に入れた記録の Log#12・13・14 が入っていません。そのため、この行の出典は Log#34 しかありません。
- 第4節は、Log#28 の「位置2は4回とも届かず」と、Log#29 の「原因を特定できない」で終わっています。
- 「始めるための入口」なのに、追加学習の段の終点が失敗です。これでは、読む人はどこまで行けるのかを持ち帰れません。

**こう直す**
- Log#12・13・14 を束ねるログに足します。
- 照合表の「実機」の部分は、到達した順に並べます。

| 行 | 到達点 | mechArm 270 の記録 | 出典 |
|---|---|---|---|
| 実機-1 | 実機で初めて動かす | 爪がブロックに乗り、手首が止まった | Log#6 |
| 実機-2 | 初めて箱に入れる | 学習し直さず、AIに渡す肩の角度を直前の目標に変えただけで入った | Log#12 |
| 実機-3 | 試した3か所すべてで入れる | Dは離す前に落ち、Eは縁すれすれ | Log#13 |
| 実機-4 | 回数で測る | 15回中9回（C 5/5・E 3/5・D 1/5） | Log#14 |
| 実機-5 | 電源を替えて測る | 12V・5Aで、位置5は5回すべて成功（2Aの日は3回中1回） | Log#34 |

- 第4節の終わりの文は、次のように書き換えます。
  > 「mechArm 270 で、ブロックを箱に入れるまでは届いた（Log#12）。回数で測ると15回中9回（Log#14）。電源を12V・5Aに替えた後は、位置5で5回すべて成功した（Log#34）。位置2が外れた理由は、カメラの傾きではないことまで確かめた（画像の傾きを変えて1,770回・Log#29）。」
- 注意点：位置の呼び方が、Log#14 の「C/D/E」と Log#28 以降の「位置1〜5」で違います。対応しているかは要約には記載がありません。表では呼び方をログのまま書き、「呼び方の対応は本文で照合」と添えてください。

### 2【高】「依存関係とバージョン」を1か所で見る場所がない

**弱い所**
- 依頼の出発点は「手順・使ったもの（依存関係とバージョン）・結果を1枚で確かめられない」ことでした。案では、版が各節に「要約には記載なし」として散らばっています。
- そのため、ページ全体でいま何が分かっていて何が欠けているのかが、1か所では見えません。
- 「照合を終えて公開する」という条件も、第2節の中にしか書かれていません。

**こう直す**
- 最初の画面のすぐ下に「使ったもの一覧」を1つの表で置きます。
- 公開前に本文とコードで照合する条件は、第1段だけでなくこの表全体にかけます。

| 使ったもの | 分かっている値 | 出典 | 照合状態 |
|---|---|---|---|
| 借りたGPU | Runpod の A40 | Log#2・3・27 | 照合済み |
| 手元の機械 | Mac（π0.5 は Mac では動かない） | Log#2 | 照合済み |
| アームの制御ライブラリ | pymycobot 2.9.6（4.0.4 では指令1回1.6秒） | Log#20 | 照合済み |
| 常駐処理を動かす機械 | Pi（機種は要約には記載なし） | Log#20 | 要照合 |
| 電源 | 12V・5A（2Aは不足） | Log#30・34 | 照合済み |
| 手直し用のゲームパッド | 3,198円の互換品 | Log#19 | 照合済み |
| π0.5 の学習・推論の版 | 要約には記載なし | Log#2・27 | 本文とコードで照合が要る |

- Log#19 は束ねるログに足します。ログ一覧の中にあるので、題材を広げることにはなりません。
- 「Pi」と「Mac では動かない」は、要約にある範囲でいちばん具体的な事実です。

### 3【高】「送り返す」道が、送る人に何を書けばよいかを決めさせていない

**弱い所**
- 「届いた行と足りない情報を送る」とありますが、照合表の行に番号がないので「届いた行」を指せません。
- 送っても自分の記録がどう使われるかが分からないので、送る理由が弱くなっています。
- このままでは、主指標の③（自分以外の環境で再現された記録）につながりません。

**こう直す**
- 照合表の全行に番号を振ります（例：1-1、1-2、2-1、実機-1…）。
- 各段の終わりの文面を、次のようにします。
  > 「どの行まで届いたかを教えてください。途中で止まっても、まだ始めていなくても構いません。次の人のために、足りない情報を埋めるのに使います。」
  > 送る項目：届いた行番号（例：1-2）／アーム（なし可）／借りたGPUと借り先／分かる範囲の版／止まった所・足りなかった情報
- 照合表に「ほかの環境での記録」という列を空けて置き、「了承をいただいた記録は、この列に載せます」と添えます。
  - これで③が表の上に見えるようになり、送った人には自分の記録が載るという理由ができます。
  - 載せるかどうかはエイイチさんの判断が要ります。

### 4【高】最初の画面が抽象的で、検索・AIで探す人の言葉もない

**弱い所**
- 見出しの「推論・追加学習・実機の結果を分けて確かめる」は作り手の方針で、読む人が得るものではありません。
- いちばん強い事実が、最初の画面にありません。
  - Mac では動かない（Log#2）
  - 1回の費用0.34ドル（Log#2）
  - 50本を約579円で学習（Log#27）
  - 実機で5回すべて成功（Log#34）
- ページ名の「実験台帳」は、検索する人も AI も使わない言葉です。

**こう直す**
- ページ名：「π0.5を自分の小型アームで動かす手順と結果——借りたGPUでの推論から、追加学習・実機まで」（新しいキャッチコピーではなく、中身を表す題名です）
- 見出し：「π0.5はMacでは動かない。借りたA40なら動き、追加学習した小型アームで箱に入れるまで届いた。」
- その下の3行：
  - アームなし：Mac から画像と指示文を送り、動きの数値を受け取った（費用0.34ドル・Log#2）。LIBERO のシミュレーションでは20回すべて成功した（Log#3）。
  - 追加学習：お手本50本・3,000ステップを、A40で6.2時間・約579円で学習した（Log#27）。
  - 実機：mechArm 270 で15回中9回（Log#14）。電源を替えた後は、位置5で5回すべて成功した（Log#34）。詰まった所は、あなたのアームで確かめる問いにした。

### 5【中】第2段の入り方に、いちばん小さい一歩と「時間」がない

**弱い所**
- 第2段が、19本・50本という集め終わった後の話から始まっています。
- 依頼にある「学習の条件（本数・ステップ数・時間・費用）」のうち、「時間」はLog#27の6.2時間しかありません。

**こう直す**
- 第3節の前に、Log#4 を「最初の通し確認」として置きます。
  > 「お手本2本・200ステップで、loss は0.1031から0.0162へ下がり、Mac で予測を受け取れた（Log#4）。50本を集める前に、2本で学習から予測を受け取るまでが通るかを確かめられる。」
  - 「2本で足りる」とは書かず、「通るかの確認」に留めます。
- 学習の条件の表に、Log#10 の「GPUの空き待ちで起動まで約4時間半」を足します。費用には出ない時間の実例です。
- Log#4・10 を束ねるログに足します。

### 6【中】第3段の問いに「確かめ方」がなく、移しやすい問いが2つ抜けている

**弱い所**
- 4つの問いは「何が起きたか」までで止まっています。自分のアームでどう確かめればよいかが書かれていません。
- また、どのアームにも当てはまりやすい Log#11・12 の問いが入っていません。

**こう直す**
- 列を「問い｜mechArm 270 で起きたこと｜mechArm 270 での見分け方｜出典」にします。
- 次の行を足します。

| 問い | mechArm 270 で起きたこと | 見分け方 | 出典 |
|---|---|---|---|
| お手本に止まっている時間が入っていないか | π0.5 は止まっている時間まで覚えた。停止を詰めて学び直すと、運ぶまで進んだ | ― | Log#11 |
| モデルに渡す関節の値は、実測か、直前に送った目標か | 直前の目標に変えると、毎回約2°足りず箱に当てていた動きが直った | ― | Log#12 |
| お手本は深くつかんでいるか（今ある行） | 30本中7本が浅かった | 爪が乗った回は、下ろす時間が普段1.1秒→7.9〜9.1秒に延びた（Log#25）。爪の電流は空で15前後、つかむと870前後（Log#24） | Log#23・24・25 |

- 「見分け方」の値は、すべて mechArm 270 の実例として書き、他機種の目安にはしません。

### 7【中】ページへの入口が、名前を挙げるだけで具体になっていない

**弱い所**
- 「シリーズ番号は確認する」「LinkedIn に投稿する」までで止まっています。どの文面で、どこから送るのかが決まっていません。
- 置き場所のない入口は効きません。

**こう直す**
- `/gpu-buy-or-rent`：借りる側の説明のすぐ後に、次の1文とリンクを置きます。
  > 「借りたA40でπ0.5を動かした実例：1回の費用0.34ドル、推論は平均97ms（Log#2）」
  - このページは50%まで読んだ人が52%いて、そこで落ちています。リンクは前半に置きます。
- シリーズ「フィジカルAI研究室を作る」のページ：資料欄の先頭に置きます。
- LinkedIn：投稿は数字だけにします。
  > 「π0.5はMacでは動かない。借りたA40で動かし、お手本50本・約579円で追加学習した小型アームの手順と結果を、1枚にまとめた。」
- AI向け：本文の節見出しに、聞かれそうな言葉をそのまま使います。
  - 「π0.5 は Mac で動くか」
  - 「π0.5 の追加学習の費用と時間」
  - 「小型アームで π0.5 が失敗する時に確かめること」

### 8【低】Log#28 の電源条件は、要約の時系列からもう一歩言える

**弱い所**
- 「電源条件は要約には記載なし」で止まっていて、読む人には判断の手がかりがありません。

**こう直す**
- 次のように書きます。
  > 「Log#28 は、電源の不足が見つかった Log#30 より前の試行。当時の電源は要約には記載なし。推測では12V・2Aのまま（本文で照合が要る）。」
- 位置2の失敗を、電源の問いとつなげて読めるようになります。推測であることは明記します。

---

### 守るべき尖り

**「できた」を、予測の受信・学習完了・実機前の予測一致・実機でつかむ・箱に入れる、と別々の行に分けた照合表です。**

Log#5〜7 の「予測はお手本と合い、loss は0.0030まで下がったのに、実機では奥で空振りした」を表の正面に置くことは、このページにしかない価値です。始める人がいちばん欲しい「どこまで行けばできたと言えるか」に答えています。

書き直しで、成功の数字を前に出しても（指摘1・4）、この行の分け方と「照合状態」の列は消さないでください。
```


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

```markdown
案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回目）

```markdown
【採否】

- A1：一部採る。Log#12・14を足し、箱に入れた到達点と試行回数を示す。Log#13は重ねず、位置名の対応は未確認とする。
- A2：一部採る。環境・依存関係・版を一表に集め、全体を公開前に照合する。ゲームパッドは開始の必須機材にしない。
- A3：採る。行番号と他環境の記録欄を設け、送る内容と使い道を具体にする。掲載は本人の了承と内容確認を経る。
- A4：一部採る。題名と冒頭に作業・条件・到達点を出す。「Macでは動かない」はLog#2の環境に限定し、費用を一般化しない。
- A5：一部採る。Log#4の2本・200ステップを通し確認として加える。待ち時間の追加より、最初の経路を短く示すことを優先する。
- A6：一部採る。停止時間と入力する関節値の問いを足す。確認方法はログで確認できた範囲に留め、電流などの枝は増やさない。
- A7：一部採る。リンク文面と置き場所を決める。21件の閲覧から配置の優劣は判断せず、SNSでも「1回の費用」とは書かない。
- A8：採らない。前後関係だけではLog#28の電源を推定できず、位置2の原因と結び付ける材料にも足りない。
- B1：一部採る。実機までの到達点を冒頭に出す。ただし未記載がある段階で「全手順」とは言わず、学習誤差を成功の代表値にしない。
- B2：一部採る。不足の表記は一覧へ集約する。ただし「照合状態」は残し、未確認と照合後の未記載を区別する。
- B3：一部採る。見出しに具体の事実を出す。ただし2,000ステップ時の予測一致と4,000ステップ時の誤差を混ぜない。
- B4：一部採る。症状を見出しに出す。「壁」という演出や、AIに拾われるという断定は使わない。
- B5：採る。試した記録と着手前の不足を送れる文面にする。未着手の連絡は再現実績と分ける。
- B6：一部採る。条件・結果・出典を各行で対応させる。全段落を同じ箇条書きにはせず、照合表を中心にする。

【企画書】

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

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

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

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

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

アームなしの推論から自機での確認まで、次に開く手順、照合する結果、足りない情報が分かる。

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

**π0.5を動かし始める。借りたGPUでの推論から、小型アームで箱に入れるまで。**

アームなし：借りたA40で予測を受信。LIBEROでは20回すべて成功しました（Log#2・3）。  
追加学習：お手本2本で予測受信まで通し、50本の学習では6.2時間・約579円でした（Log#4・27）。  
実機確認：mechArm 270で箱に入れるまで到達。自分のアームで確かめる項目と、未確認の情報を示します（Log#12）。

直下に「アームなしで始める／お手本と追加学習／実機を確かめる」の段内リンク。

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

**「できた」を一括りにしない、行番号付きの到達点照合表。**

予測受信／シミュレーション成功／学習完了／実機前の予測一致／実機でつかむ／箱に入れる、を分ける。予測一致や学習誤差の低下だけでは、実機成功にならなかったLog#5〜7を正面に置く。

列は「行番号・作業｜環境表の参照先｜照合する結果｜手順ログ｜不足と照合状態｜他環境の記録」。

別に「使ったもの・用途｜機種・版・設定｜出典｜照合状態」を一表に集約。RunpodのA40、Mac、π0.5・学習推論コード、LIBERO、Pi、pymycobot、電源を扱う。版の違う試行を一つの推奨環境に混ぜない。

全表を公開前に本文とコードで照合する。未確認は「要約には記載なし（本文とコードで照合が要る）」、照合後もなければ「ログにない（未記載）」。再現に必要な穴を残す。

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

以下の番号は「束ねるログ」のURLに対応する。各行の作業名から手順ログを開ける。

**1．アームなし：借りたGPUで予測を受け取る**  
行1-1、Log#2。記録の環境ではMacで動かず、RunpodのA40で動いた。Macから画像・指示文を送り予測を受信。推論平均97ms、往復391ms、費用0.34ドルは、この実験の記録値として示す。

**2．アームなし：LIBEROで結果を確かめる**  
行1-2、Log#3。A40上で黒いボウルを拾って皿に置く作業が20回すべて成功。実行条件、依存関係と版、測定したGPUメモリ値を環境表で照合する。他環境でも同じ結果になるとは保証しない。

**3．自分のアーム：少量で学習を通し、お手本をそろえる**  
行2-1、Log#4。2本・200ステップで学習し、Macで予測を受信。実機は未実施であり、2本を必要十分量とはしない。  
行2-2、Log#9・23・26。再生しながら19本収集した例、別のデータ30本中7本が浅いつかみだった事実、教え直して5か所10本ずつそろえた例。記録・変換方法は環境表と手順ログへ送る。

**4．自分のアーム：学習誤差が下がっても、実機では外れた**  
行2-3、Log#5〜7。19本・2,000ステップでは予測がお手本の最初の1秒と数度以内で一致。初回実機では爪がブロックに乗った。4,000ステップ・学習誤差0.0030でも2回とも奥で空振り。  
行2-4、Log#27・28。深い50本をA40で3,000ステップ、6.2時間・約579円。位置1は3回とも補正なしでつかめたが、位置2は4回とも姿勢まで届かなかった。電源条件や原因を推定で補わない。  
行2-5、Log#12・14。箱に入れるまで到達し、回数で測ると15回中9回（C 5/5、E 3/5、D 1/5）。後の「位置1〜5」との対応は要約には記載なし。

**5．実機確認：遅い・届かない・落とす時に見る所**  
「問い｜mechArm 270の事実・確認方法｜出典」で示す。他機種の設定値にはしない。

- 命令が捨てられないか：肩約88°より深い姿勢でエラーなく破棄（#9）。
- 実行中の処理はどの版を読むか：Piがpymycobot 4.0.4を読み指令1回1.6秒。2.9.6では送信約0.02秒（#20）。
- 停止時間までお手本に入っていないか：停止を詰めて学び直すと運ぶまで進んだ（#11）。
- モデルに何の関節値を渡しているか：肩の入力を直前の目標へ変え、約2°足りない動きが直った（#12）。
- つかみは浅くないか：お手本30本中7本に同じ浅さ（#23）。
- 電源は足りるか：要求40Wに対し24W。12V・5Aへの交換後、位置5は5回すべて成功、2Aの日は3回中1回（#30・34）。

**6．試した記録・始める前の不足を送る**  
各段末から `/message` へ。「届いた行番号／アーム（なし可）／GPUと借り先／分かる版／止まった所・不足」を写せる形にする。次の人が始める情報を埋める用途を明記。了承と内容確認を経た記録を他環境欄へ載せ、未着手・不足報告は再現実績と分ける。

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

- #2 /record/openpi-remote-inference-first-run
- #3 /record/pi05-libero-benchmark-first-run
- #4 /record/pi05-mecharm-demo-to-inference
- #5 /record/pi05-mecharm-lora-2000-steps
- #6 /record/pi05-mecharm-first-real-run
- #7 /record/pi05-mecharm-4000-steps
- #9 /record/teach-replay-19-demos
- #11 /record/pi05-learned-the-pauses
- #12 /record/pi05-first-block-in-box
- #14 /record/pi05-weak-position-d
- #20 /record/gamepad-moves-mecharm-270-pymycobot-version
- #23 /record/pi05-failures-traced-to-shallow-grasp-demos
- #26 /record/even-ten-demos-per-spot-mecharm-270-reteaching
- #27 /record/retrain-pi05-from-base-on-50-even-demos
- #28 /record/pi05-even-demos-on-arm-misses-position-2
- #30 /record/mecharm-270-drops-block-underpowered-adapter
- #34 /record/mecharm-270-5a-adapter-stops-dropping-block

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

該当シリーズ資料欄の先頭とトップの既存シリーズ欄に題名でリンク。`/gpu-buy-or-rent` の借りる説明直後に「借りたA40でπ0.5を動かす手順と実測結果」から第1段へ。SNSは「アームなしの推論から実機確認まで、手順ログを束ねました」とリンクする。検索・AIには本文で条件・結果・出典を対応させる。ログ形式は変えず、トップ・SNSに相談窓口は置かない。

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

人の表示、ログを開いた人の割合、段別利用、利用者依頼のAI取得、AIリンク経由の人、再現関連の連絡を分ける。人の表示30件までは判断しない。3か月で30件未満かつ連絡0件なら追加制作を止め、ページは残す。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

以下は依頼の目標値。

- **3か月150件：** 既存LP・シリーズ等から開始地点へ送る。発見される量は未知。
- **ログへ3割：** 作業名から手順へ送る。表だけで用が済む可能性もある。
- **AI取得は2か月目から週3件以上：** 条件と出典を集約。参照される保証はない。
- **AI経由で月1件以上：** 始め方の回答から案内できる。回答内で完結する場合もある。
- **再現関連の連絡1〜2件：** 行番号で報告を短くする。実験・報告の負担は残る。

主指標は環境ごとに、公開手順・依存関係と版・第三者の再現記録または情報充足の確認を満たしたかで判定する。
```


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

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

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

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

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

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

アームなしの推論から自機での確認まで、次に開く手順、照合する結果、足りない情報が分かる。

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

**π0.5を動かし始める。借りたGPUでの推論から、小型アームで箱に入れるまで。**

アームなし：借りたA40で予測を受信。LIBEROでは20回すべて成功しました（Log#2・3）。  
追加学習：お手本2本で予測受信まで通し、50本の学習では6.2時間・約579円でした（Log#4・27）。  
実機確認：mechArm 270で箱に入れるまで到達。自分のアームで確かめる項目と、未確認の情報を示します（Log#12）。

直下に「アームなしで始める／お手本と追加学習／実機を確かめる」の段内リンク。

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

**「できた」を一括りにしない、行番号付きの到達点照合表。**

予測受信／シミュレーション成功／学習完了／実機前の予測一致／実機でつかむ／箱に入れる、を分ける。予測一致や学習誤差の低下だけでは、実機成功にならなかったLog#5〜7を正面に置く。

列は「行番号・作業｜環境表の参照先｜照合する結果｜手順ログ｜不足と照合状態｜他環境の記録」。

別に「使ったもの・用途｜機種・版・設定｜出典｜照合状態」を一表に集約。RunpodのA40、Mac、π0.5・学習推論コード、LIBERO、Pi、pymycobot、電源を扱う。版の違う試行を一つの推奨環境に混ぜない。

全表を公開前に本文とコードで照合する。未確認は「要約には記載なし（本文とコードで照合が要る）」、照合後もなければ「ログにない（未記載）」。再現に必要な穴を残す。

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

以下の番号は「束ねるログ」のURLに対応する。各行の作業名から手順ログを開ける。

**1．アームなし：借りたGPUで予測を受け取る**  
行1-1、Log#2。記録の環境ではMacで動かず、RunpodのA40で動いた。Macから画像・指示文を送り予測を受信。推論平均97ms、往復391ms、費用0.34ドルは、この実験の記録値として示す。

**2．アームなし：LIBEROで結果を確かめる**  
行1-2、Log#3。A40上で黒いボウルを拾って皿に置く作業が20回すべて成功。実行条件、依存関係と版、測定したGPUメモリ値を環境表で照合する。他環境でも同じ結果になるとは保証しない。

**3．自分のアーム：少量で学習を通し、お手本をそろえる**  
行2-1、Log#4。2本・200ステップで学習し、Macで予測を受信。実機は未実施であり、2本を必要十分量とはしない。  
行2-2、Log#9・23・26。再生しながら19本収集した例、別のデータ30本中7本が浅いつかみだった事実、教え直して5か所10本ずつそろえた例。記録・変換方法は環境表と手順ログへ送る。

**4．自分のアーム：学習誤差が下がっても、実機では外れた**  
行2-3、Log#5〜7。19本・2,000ステップでは予測がお手本の最初の1秒と数度以内で一致。初回実機では爪がブロックに乗った。4,000ステップ・学習誤差0.0030でも2回とも奥で空振り。  
行2-4、Log#27・28。深い50本をA40で3,000ステップ、6.2時間・約579円。位置1は3回とも補正なしでつかめたが、位置2は4回とも姿勢まで届かなかった。電源条件や原因を推定で補わない。  
行2-5、Log#12・14。箱に入れるまで到達し、回数で測ると15回中9回（C 5/5、E 3/5、D 1/5）。後の「位置1〜5」との対応は要約には記載なし。

**5．実機確認：遅い・届かない・落とす時に見る所**  
「問い｜mechArm 270の事実・確認方法｜出典」で示す。他機種の設定値にはしない。

- 命令が捨てられないか：肩約88°より深い姿勢でエラーなく破棄（#9）。
- 実行中の処理はどの版を読むか：Piがpymycobot 4.0.4を読み指令1回1.6秒。2.9.6では送信約0.02秒（#20）。
- 停止時間までお手本に入っていないか：停止を詰めて学び直すと運ぶまで進んだ（#11）。
- モデルに何の関節値を渡しているか：肩の入力を直前の目標へ変え、約2°足りない動きが直った（#12）。
- つかみは浅くないか：お手本30本中7本に同じ浅さ（#23）。
- 電源は足りるか：要求40Wに対し24W。12V・5Aへの交換後、位置5は5回すべて成功、2Aの日は3回中1回（#30・34）。

**6．試した記録・始める前の不足を送る**  
各段末から `/message` へ。「届いた行番号／アーム（なし可）／GPUと借り先／分かる版／止まった所・不足」を写せる形にする。次の人が始める情報を埋める用途を明記。了承と内容確認を経た記録を他環境欄へ載せ、未着手・不足報告は再現実績と分ける。

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

- #2 /record/openpi-remote-inference-first-run
- #3 /record/pi05-libero-benchmark-first-run
- #4 /record/pi05-mecharm-demo-to-inference
- #5 /record/pi05-mecharm-lora-2000-steps
- #6 /record/pi05-mecharm-first-real-run
- #7 /record/pi05-mecharm-4000-steps
- #9 /record/teach-replay-19-demos
- #11 /record/pi05-learned-the-pauses
- #12 /record/pi05-first-block-in-box
- #14 /record/pi05-weak-position-d
- #20 /record/gamepad-moves-mecharm-270-pymycobot-version
- #23 /record/pi05-failures-traced-to-shallow-grasp-demos
- #26 /record/even-ten-demos-per-spot-mecharm-270-reteaching
- #27 /record/retrain-pi05-from-base-on-50-even-demos
- #28 /record/pi05-even-demos-on-arm-misses-position-2
- #30 /record/mecharm-270-drops-block-underpowered-adapter
- #34 /record/mecharm-270-5a-adapter-stops-dropping-block

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

該当シリーズ資料欄の先頭とトップの既存シリーズ欄に題名でリンク。`/gpu-buy-or-rent` の借りる説明直後に「借りたA40でπ0.5を動かす手順と実測結果」から第1段へ。SNSは「アームなしの推論から実機確認まで、手順ログを束ねました」とリンクする。検索・AIには本文で条件・結果・出典を対応させる。ログ形式は変えず、トップ・SNSに相談窓口は置かない。

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

人の表示、ログを開いた人の割合、段別利用、利用者依頼のAI取得、AIリンク経由の人、再現関連の連絡を分ける。人の表示30件までは判断しない。3か月で30件未満かつ連絡0件なら追加制作を止め、ページは残す。

### ゴールにどう効くか（依頼にゴールの表があれば、その行ごとに。効く理由と、効かないかもしれない理由の両方）

以下は依頼の目標値。

- **3か月150件：** 既存LP・シリーズ等から開始地点へ送る。発見される量は未知。
- **ログへ3割：** 作業名から手順へ送る。表だけで用が済む可能性もある。
- **AI取得は2か月目から週3件以上：** 条件と出典を集約。参照される保証はない。
- **AI経由で月1件以上：** 始め方の回答から案内できる。回答内で完結する場合もある。
- **再現関連の連絡1〜2件：** 行番号で報告を短くする。実験・報告の負担は残る。

主指標は環境ごとに、公開手順・依存関係と版・第三者の再現記録または情報充足の確認を満たしたかで判定する。
```


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

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


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

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


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

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

- 最後に書いた時刻 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

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

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

## 誰に
ロボットの導入を判断する経営者と、導入を任された PM（飲食・病院・物流など）。
フィジカルAI という言葉に反応しているのは主にこの人たちで、関心は技術そのものより「導入の判断」と「実験止まりで終わらせないこと」にある。
この人たちが知りたいのは、カタログや営業資料には書いていない「入れてから分かること」。

## このページで達成したいこと
- 読んだ経営者・PM が「入れる前に、これを確かめないといけない」と分かり、自分の現場の確かめ方を持ち帰れる
- 「この人は、現場で本当に止まる所を測っている」と伝わり、導入の相談や共同の検証の話につながる（相談の窓口はメッセージフォーム /message だけ。ページの最後に1行置くのはよい）

## 12の止まる瞬間（出典は 材料/ フォルダのログ全文。ページの /record/ リンクは右の名前を使う）
| # | 止まる瞬間 | 要点（ログの要約から。数字は 材料/ の本文で確かめること） | 材料のファイル → /record/ |
|---|---|---|---|
| 1 | 店員が来るまで | 実店舗の動画で、止まったロボットを直す作業は1〜10秒、店員が来るまでは18〜45秒以上 | LOG391 → serving-robot-video-ledger |
| 2 | にらみ合い | 狭い通路で2台が向かい合うと、ロボットどうしでは解けず、実店舗でも店員が手で片方をどかしていた | LOG434 → serving-robot-faceoff-staff-resolves、LOG400 → serving-robot-jams-are-aisles |
| 3 | 2台目が待ちを延ばす | 通路の狭い28卓の店で2台にすると入店待ちが約2倍。1台が上限 | LOG423 → serving-robot-one-per-narrow-restaurant、LOG393 → small-store-second-robot-wait |
| 4 | 待機場所の止まり合い | 5台にすると入店待ちが延びた。原因は待機点へ斜めに寄る入り方。決まりを変えて減らした | LOG452 → large-restaurant-five-serving-robots-longer-wait、LOG456 → serving-robots-jam-cause-standby-entry、LOG465 → serving-robot-jam-three-rules |
| 5 | 下げ膳で詰まる | 下げ膳も任せると、通路にゆとりのある店では待ちが縮み、効率重視の細い店では延びた | LOG440 → serving-robot-sim-bussing-narrow-aisles、LOG444 → serving-robot-bussing-depends-on-aisles |
| 6 | 詰まるのは片付け | ロボットを足しても、詰まるのはレジではなく片付けと案内だった | LOG397 → large-store-cleanup-bottleneck、LOG398 → standby-jam-every-store |
| 7 | 線に縛ると詰まる | 決まった線しか走らせない作りが詰まりの元。地図を渡すと60秒の止まりが57回から20回に | LOG370 → serving-robot-fixed-route-jam、LOG374 → serving-robot-map-planner |
| 8 | 直したら衝突が増えた | 病院で通れない所を直すと、搬送ロボットの問題が増えた。元は病院の職員の仮の動きだった | LOG477 → hospital-transport-robot-avoid-outpatient-hall、LOG488 → hospital-transport-robot-blocked-paths-more-conflicts、LOG491 → hospital-transport-robot-conflicts-came-from-placeholder-staff-moves |
| 9 | カメラでは見つからない | 録画から長い止まりを見つける試しで、画面のロボットの道の線を消すと、拾えた割合は72%から28%に | LOG418 → serving-robot-jam-detection-without-path-lines |
| 10 | まさかの電源不足 | ロボットアームがブロックを落とす原因は電源。12V・2A を 5A に替えると落とさなくなった | LOG487 → mecharm-270-drops-block-underpowered-adapter、LOG504 → mecharm-270-5a-adapter-stops-dropping-block |
| 11 | 命令が黙って捨てられる | 肩を約88°より深く倒す命令が、エラーなしに捨てられた | LOG352 → teach-replay-19-demos |
| 12 | 学習の数字は良いのに外れる | 学習の誤差（loss）は下がっても、実機では爪が奥で空を閉じた | LOG345 → pi05-mecharm-first-real-run、LOG348 → pi05-mecharm-4000-steps |
参考：止まり方を「見る・位置を知る・決める・動く」の4段で分けた考察 LOG439 → serving-robot-stops-four-stages-stanford

## ページの形（この順で書く）
1. 見出しと、その下の3行（このページが何で、読むと何が分かるか。実際の文面で）
2. 12の止まる瞬間。1つごとに次をそろえる
   - 名前（短く、現場の言葉で）
   - どんな現場で（店・病院・アーム）
   - 何が起きたか（ログの数字で。1〜2文）
   - なぜ止まったか（原因）
   - 入れる前に確かめること（読む人が自分の現場で確かめる問いを1〜2個）
   - 出典（/record/… へのリンク）
   - ハコブくんの一言（その止まり方を、ロボットの側から一言で。くすっとさせつつ本質を突く）
3. 12を並べる順番と、まとめ方（作者が決めてよい。いちばん刺さる順に並べる）
4. 終わりに：読む人が次にすること（自分の現場で確かめる／シミュレーションのページを見る／/message に1行）

## 守ること
- 12項目の事実と数字は、ログにあることだけ。外の情報（ニュース・調査）は「なぜこれが経営者に効くか」を伝える文脈として使ってよいが、出典と日付を付ける
- シミュレーションの結果を、実店舗で必ず起きることのように言わない。「シミュレーションでは」「実店舗の動画では」「実機では」を書き分ける
- 新しいキャッチコピーや肩書きを作らない。メーカーや店を悪く言わない
```


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

```json
{
 "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 が持ち寄った材料）

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

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

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

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

---

## 1. 店員が来るまで ［実店舗の動画］
- **何が起きたか**：SNS の実店舗の動画5本をコマ送りで読みました。止まった3本はすべて BellaBot で、ほぼガストです。
  - 通路で2台が向かい合った：店員が来るまで41秒以上、直す作業は約5秒
  - 待機場所で出口をふさがれた：45秒以上、直す作業は1〜2秒（画面で一時停止）
  - ドリンクバーの前でぶつかった：約18秒、直す作業は約10秒
  - まとめると「店員が来るまで18秒〜45秒以上、直す作業1〜10秒」です。1本目は待った時間と直した時間の比が「8対1以上」でした。
- **なぜ止まったか**：直接の原因は、1台分の幅で向かい合ったことと、隣の機体に出口をふさがれたことです（隣の機体と推定）。店員がなかなか来なかったのは、ロボットの声かけと赤い明かりがお客さん向けの合図だったからです。「店員の手元に知らせが届いた様子は、どの動画にも映っていませんでした」。
- **直したか**：直していません（記録だけ）。対策の案（店員の端末へ知らせる、誰でも5秒で直せる手順など）は挙がっていますが、効果は測っていません。
- **驚くこと**：直すのは数秒なのに、店員が気づいて来るまでにその何倍もかかる。
- **出典**：LOG391 の冒頭、「### 動画①のタイムライン：店員が来るまで41秒以上、直す作業は約5秒」「### 台帳に並べて分かった：人が来るまでの時間は、止まった場所で違う」
- ⚠ 動画は編集されているので、秒数は下限です。店員の端末に知らせる機能があるかどうかは確かめていません。のちの LOG400 で4本目（53秒以上）が加わり、幅は「18〜53秒以上」になりました。

## 2. にらみ合い ［実店舗の動画＋シミュレーション］
- **何が起きたか**
  - 実店舗の動画（LOG400）：和食の店で KettyBot 2台が待機場所の横で向かい合いました。「2台とも完全には止まらず、その場で向きを変え続けていた」。53秒以上進めず、店員が空の方を手で寄せて約4〜5秒で解けました。
  - シミュレーション（LOG434）：42卓・通路95cm の店⑦でロボット2台を走らせました。受け渡し口の右下で「約9分10秒」止まり、その間スタッフが同じ卓へ運ぶのを5回あきらめました。
- **なぜ止まったか**
  - どちらが譲るかの決まりについて、ログには「どのメーカーも公式には公開していませんでした」とあります。取扱説明書で分かるのは、すれ違えない幅では交互に通すこと（すれ違いに要る幅は PUDU が1.6m超、KEENON T8 が1.5m超）と、待ってから道を組み直すこと（BellaBot Pro の初期値は30秒）だけでした。
  - Unity のロボットは、2台とも料理を載せているとき（または2台とも空のとき）、どちらが譲るかを決められません。さらに、よけた先が相手の道の上でした。
- **どう直したか**：Unity に「30秒動けなければ近くの店員が来て、着いてから15秒で空の方を動かす」決まりを入れました。約9分の止まりは「助け2回・約105秒」で解けました（⑦・種7で1回）。ただし、止まっている台に助けが何度も要るという新しい詰まりが出ました。
- **驚くこと**：ロボットどうしの譲り合いの決まりを、どのメーカーも公開していない。集めた実物の動画は、どれもロボットだけでは解けていなかった。
- **出典**：LOG434「### 調べて分かったこと：取扱説明書に書いてある決まりは2つだけ」「### ⑦の店で、1号機と2号機が約9分止まっていた記録」「### 9分のにらみ合いは、助け2回・約105秒で解けた」、LOG400「### 「止まっている」のに、その場では動き続けていた」
- ⚠ 動画4本はすべて PUDU 製です。「1台分の通路で正面から向き合う」に当たるのはガストの1本だけで、ほかは待機場所での止まりやぶつかりです。待機場所の1本は画面操作だけで直っていて、手でどかしてはいません。「どちらが譲るか決まっていないように見える」はログの推測です。

## 3. 2台目が待ちを延ばす ［シミュレーション］
- **何が起きたか**：店④（28卓・88席、スタッフ2人、昼のピーク2時間）での結果です。
  - 2台にすると、入店待ちは「1台のときの約2倍（13.8分 → 25.1分）」になりました。
  - スタッフが動かしに行く回数は「13回から54回」に増えました。
  - 4回の夜すべてで、10種中9〜10種の入店待ちが延びました。
- **なぜ止まったか**：「ロボットどうしが1本道で向かい合ってふさぎ合うこと」です。下の通路は約1.1m、使われていない上の通路は約2.1m で、2台とも近い方の狭い道を選んでいました。止まった相手はロボットが354回、立ち止まった人が159回です。
- **どう直したか**：3つの案を試しました。
  - 案B「1本道は1台ずつ」：入店待ち25.1→17.6分、動かしに行く回数53.5→29.0回
  - 案A「一方通行」：混んでいるときは56.5分で、悪くなった
  - どの案でも「2台目は、決まりを工夫しても1台を超えませんでした」。ログの結論は「狭い店は1台から始める」です。
- **驚くこと**：この店では1台目でも入店待ちは縮まず（0台13.0分 → 1台13.8分）、2台目でほぼ倍になった。1台目で得られるのは、スタッフの歩く距離が約3割減ることだった。
- **出典**：LOG423 の冒頭、「### 1台と比べると、どの案でも2台は1台に届かなかった」「## 狭い店の配膳ロボットについて、店に伝えられること」、LOG393「### ロボットを入れても、④では入店待ちが縮まなかった」
- ⚠ 13.8→25.1分は約1.8倍で、1台と2台では Unity の作りの版が違います（ログ自身が「きっちりそろえてはいません」と書いています）。混んでいるときは約1.4倍です。他の店（⑤⑥）では2台で待ちが縮んでいるので、「狭い店はどこでも1台が上限」とは言えません。LOG393 は、直したあとに残った待ちの多くを「片付けと案内が追いつかない時間」としています。

## 4. 待機場所の止まり合い ［シミュレーション］
- **何が起きたか**：大型店⑧（70卓・312席、スタッフ6人）で台数を変えました。入店待ちは0〜3台で11.5〜11.7分、4台で13.2分、5台で17.2分です。差がいちばん開いた30分では次のようになりました。
  - ロボットどうしで止まった時間：2台の67秒 → 5台の1,163秒
  - 片付けのスタッフが道をあきらめた回数：8回 → 34回
- **なぜ止まったか**：「待機点どうしの間は0.8mしかなく、ロボットの前のセンサー（中心から0.85m）が隣の待機点の台に届く。戻る台は斜めに寄ってくるので、隣の台がセンサーに入り、止まります」。道を探した結果の87〜98%は道が引けていました。道はあるのにセンサーで止まっていた、ということです。
- **どう直したか**
  - 待機点の真下1.0m からまっすぐ入る決まりにしました。待機場所のそばの止まり合いは、1回の営業あたり3,317秒 → 1,255秒に減りました。
  - 加えて人が待機点の区画を通らないようにすると、809秒になりました。店員が呼ばれる回数は180回 → 22回、スタッフの手が空いている割合は20.3% → 38.6% です。
  - 別の直し（近くの店員がすぐ押す）で、入店待ちは17.56 → 11.32分になりました。
- **驚くこと**：場所を広げなくても、入り方を「斜め」から「真下からまっすぐ」に変えるだけで、止まり合いが約6割減った。
- **出典**：LOG452「### 大型店の入店待ち（10種の中央値・分）」と依頼96の節、LOG456 の冒頭と「依頼104」「依頼114」の節、LOG465「依頼119」の節
- ⚠ ログは、5台で待ちが延びたのは「店の問題を写したというより、Unity のロボットに台どうしの順番決めがないことが大きく出た結果」と書いています。5台の映像は「店で起こる場面としては見せられない」として載せていません。まっすぐ入る決まりだけでは、入店待ちは12.22 → 14.90分に**延びました**。「決まりを変えて待ちが減った」とは書けず、正しくは「止まり合いが減った」です。

## 5. 下げ膳で詰まる ［シミュレーション］
- **何が起きたか**：6店 × 1〜2台 × 10種の、計120回を回しました。
  - スタッフの歩く距離は12条件すべてで減りました。
  - 通路の細い店で2台のとき、お客さんが帰ってから卓が使えるまでの時間が延びました。③は4.05 → 6.05分、⑦は4.49 → 8.06分です。
- **なぜ止まったか**：「下げ膳のロボットが卓に着いてスタッフを待つあいだ、通路が1本ふさがり、ほかのロボットとスタッフが回り道をするか待つことになります」。通路にゆとりのある⑤では「別の通路を回って行けます」。
- **どう直したか**：卓で待つのは2分までにして、待っている台も助けで動かしてよいことにしました。解けずに残った詰まりは53件 → 4件、全員が帰れなかった回は4回 → 1回になりました。卓が使えるまで延びる問題そのものは直していません。
- **驚くこと**：スタッフの歩く距離はどの店でも減るのに、細い通路の店では次のお客さんを座らせるまでが約2倍に延びた（⑦）。
- **出典**：LOG440 の冒頭、「## 作業ログ ― 依頼90・91：Unity の配膳ロボットに下げ膳を入れた」、LOG444 の冒頭と「## 作業ログ ― 6店の比較動画」
- ⚠ 依頼の表の「ゆとりのある店では待ちが縮み、細い店では延びた」は、LOG444 の店ごと1回の録画の結果です。ログ自身が「店ごとの答えを言い切ることはできません」と書いています。10種の中央値で確かなのは「歩く距離は減る」と「③⑦の2台で卓が使えるまでが延びる」の2つです。④は人手不足が原因で、中央値では待ちが縮んでいます。

## 6. 詰まるのは片付け ［シミュレーションと試算の比較］
- **何が起きたか**
  - ⑤（46卓、スタッフ4人）：3Dの店の会計待ちは6〜7分でした。一方、席は空いているのに待った時間は0台6.5分（試算1.5分）、1台4.6分（試算0.8分）、2台3.4分（試算0.7分）です。
  - ⑥（38卓）：会計待ちは3分前後でした。席は空いているのに待った時間は、試算の2.0〜5.5倍です。
- **なぜ止まったか**：試算では、食べ終えた客がレジを待つあいだ卓に座ったままなので、レジが詰まります。3Dの店ではスタッフが歩き回るぶん手がふさがり、後回しになる片付けがたまっていました（③⑦では1組あたりの仕事が試算より約1割長い）。⑤⑥について、ログは「同じことが起きていると見ています」と書いています。
- **どう直したか**：このずれ自体は直していません（記録だけ）。直したのは店の形で、ロボットの道を広げました。それでも⑥の2台では、待機場所の中で60回止まり、そのうち59回の相手はもう1台のロボットでした。
- **驚くこと**：計算ではレジが詰まるはずなのに、実際に動かすと詰まっていたのは「席は空いているのに、片付けと案内が追いつかない」時間だった。
- **出典**：LOG397 の冒頭と「### 試算はレジで詰まり、3Dの店は片付けと案内で詰まる」、LOG398 の冒頭と「## 作業ログ ― ⑥を種10個ずつ、計30回回した」
- ⚠ ロボットを足すと入店待ちは**縮んでいます**（⑤8.1→6.6→5.5分）。席は空いているのに待った時間も、0台がいちばん長いです。「ロボットを足すと片付けが詰まる」ではなく、「待ちの元はレジではなく片付けと案内」が正確です。当時の版には瞬間移動が残っていました。

## 7. 線に縛ると詰まる ［シミュレーション］
- **何が起きたか**：店③で2台を走らせると、60秒止まった回が58回あり、そのうち51回の相手はもう1台のロボットでした。行き止まりで向かい合ったまま600秒で打ち切りになった回もあります。
- **なぜ止まったか**：Unity のロボットは「サイトから渡された道の線の上しか走れません」。卓ごとの最短の1本を行き帰りに共用していて、42卓の道のうち23本が同じ通路を通っていました。ログはこれを「現実にない制約」と書いています。実機は地図の上で道を引いて回り込みます。
- **どう直したか**（③・2台・種0、各1回）
  - 地図で道を引けるようにしただけ：60秒の止まりは57 → **59回で、減りませんでした**。59回のうち43回が右下の行き止まりに集まっていました（ドリンクバーと6人席の間が0.4m）。
  - さらにドリンクバーを上へ0.5m・左へ0.8m動かした：**20回**。ロボットが運んだ割合は64.4% → 99.4%、料理の待ちは2.90 → 1.17分（試算は1.01分）。
- **驚くこと**：賢い道の引き方を渡しても詰まりは減らず、ドリンクバーを数十cm動かして行き止まりをなくしたら3分の1になった。
- **出典**：LOG370「## ロボットどうしの詰まり：店の形ではなく、ロボットを線に縛った作りが根本だった」、LOG374「## 1回目（ドリンクバーを動かす前）」「## 2回目（ドリンクバーを動かした後）」
- ⚠ 依頼の表の「地図を渡すと57回→20回」は2つの直しを1つにまとめていて、言い過ぎです。比べたのはどれも1回ずつです。「線に縛る」はシミュレーションの作りの問題で、実機の不具合ではありません。

## 8. 直したら問題が増えた ［シミュレーション・仮の病院］
- **何が起きたか**：病院 h1 で、行き先へ歩いて行けなかった41人（患者と職員）を通れるように直しました。するとロボットの問題（急に止まった・ひやり・人がよけさせられた など）は、1日84件 → 132件に増えました。増えた48件のうち37件は大廊下の東の端で起き、相手はほとんどが職員でした。
- **なぜ止まったか**
  - 直接の原因（LOG488）：付き添い用に「入れる」ようにした所へ、職員がふだんの行き来でも行くようになりました。たとえば検査技師が救急の処置の場所へ行く回数が0 → 46回になりました。
  - 根本の原因（LOG491）：Unity の職員141人を「1人が1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動かしていました。
- **どう直したか**
  - 職員の行き先を持ち場に限る：132 → 68件
  - 職員を持ち場ごとの4つの型で動かす：68 → **19件**。そのうち職員が相手だったのは2件で、車いすの患者が動けなかった時間は最長663.8秒 → 20.3秒になりました。
  - ただしその後、患者の動きを入れると19 → 51件に増えました。条件がそろった数としては、ログは51件の方を挙げています。
- **驚くこと**：数えていたロボットの問題の大半は、ロボットではなく「人の動きの仮置き」が作っていた。
- **出典**：LOG488「### ロボットの問題は1日84件から132件に増え、37件は大廊下の東の端で起きた」「### 増えた原因は、通り抜けのために足した所が…」、LOG491 の冒頭、「### 職員は5つの役割とも、1時間に1回のくじ引きで科をまたいでいた」「### 走っている間の問題は68件から19件になり…」「### 採血の所に最大41人が集まり…」
- ⚠ 数えているのは「衝突」ではなく「問題」です。止まりきれなかったのは132件中10件だけです。「病院の職員の仮の動き」とは**シミュレーションの中の**仮の決まりのことで、実際の病院の話ではありません。比べたのは主に種0の1回で、種8では56 → 260件とぶれが大きいです。

## 9. 映像からは見つからない ［シミュレーションの録画］
- **何が起きたか**：Unity の店③を真上から撮った録画を使いました。ロボットのまわりを切り出した静止画1枚ずつを、画像の異常検知（PatchCore）で判定し、30秒以上の長い止まりを拾えるか試しました。誤報5%のしきい値で、拾えた割合は次のとおりです。
  - 道の線あり：72%（67/93）
  - 道の線なし：28%（26/94）
  - ロボットどうしの詰まり：線ありの23/43 → 線なしの4/47
- **なぜ拾えなかったか**：線ありで光っていたのは、画面に描かれた道の線が交わる所でした。この線は実際の店のカメラには映りません。線がないと、向かい合う2台は「白い丸が2つ並ぶだけ」で、待機場所で2台が並ぶ普段の絵と区別がつきません。30秒続くかどうかの見分けは0.51で、偶然と同じでした。
- **どう直したか**：検出の力は直していません。録画から線を消す切り替えを足して、正しく測り直しました。次の案として、止まった時間はロボットの記録から取り、画像は原因の場所を示す役にする、が挙がっています。
- **驚くこと**：シミュレーションで8割拾えた画像のAIは、本物のカメラには映らない画面上の線を手がかりにしていた。
- **出典**：LOG418 の冒頭、「### 線を消すと、長い止まりを拾えた割合は72%から28%に落ちた」「### 線がないと、ロボットどうしの詰まりとスタッフとのすれ違いは拾えない」
- ⚠ 実際のカメラ映像ではありません。試した方法も1つだけです。「カメラでは見つからない」は言い過ぎで、言えるのは「静止画1枚の異常検知では長い止まりを拾えない」までです。お客さんとのすれ違いは線なしでも13/17拾えています。

## 10. まさかの電源不足 ［実機 mechArm 270］
- **何が起きたか**：位置5 のブロックを9回中2回しか運べず、その2回も人が手を貸しました（閉じる値20）。つかんだあと11〜19秒で爪の電流が0付近に落ち、ブロックを落としていました（17本中12本）。閉じる値を25に下げると止まっている間は持ちましたが、アームが動き出すとまた力が抜けました。
- **なぜ止まったか**：本体の求める電源は40W（説明書は8.4V・5A）です。つないでいたのは外付けディスク用の12V・2A（24W）で、「本体が求める40W の6割しかありません」。箱にアダプターが入っておらず、あとから別送されたもので、**8か月分の実機の記録はすべてこの電源で取っていました**。LOG487 の時点では推測で（電圧は測っていない）、LOG504 で差し替えて確かめました。
- **どう直したか**：12V・5A（3,355円）に替えました。AI（π0.5）で位置5・閉じる値25を比べると、成功は3回中1回 → **5回中5回**、人の直しは3回中3回 → 5回中1回になりました。教えた動きの再生も7回すべて成功しました。
- **驚くこと**：AI の学習の問題に見えた失敗の正体は、8か月使っていた付属外のアダプターで、3,355円で直った。
- **出典**：LOG487「## 位置5 の失敗は、つかんだあとに爪の力が抜けて落としていた」「## mechArm 270 の電源は40W、つないでいたアダプターは24W だった」、LOG504「### 12V・2A の日の3回と、つかんでいる間の爪の電流を並べた」
- ⚠ 比べたのは3回と5回で、日も違います。5A でも1回、持ち上げた瞬間に電流が落ちています（ブロックは落ちていない）。電圧が下がったことを直接測った記録はありません。

## 11. 命令が黙って捨てられる ［実機 mechArm 270］
- **何が起きたか**：手で教えた動きを再生すると、つかむ位置へ降りる命令が「6回送って6回とも無視」されました（教えた肩の角度は95.53〜99.22°）。エラーは出ず、動いた角度は最大1.50°で、止まっているときの揺れと同じくらいです。さらに、動いていない2本が台帳に「つかめた yes・箱に入った yes」と記録されていました。
- **なぜ止まったか**
  - メーカー公式の肩の範囲は−85°〜+90°です。送る側のライブラリは±190°でしか確かめないので、範囲外の命令もそのまま送られ、アーム側で黙って捨てられていました。
  - 本線のコードには LOG257 から上限88.0°が入っていましたが、再生用のコードには入っていませんでした。
  - 手で教えるときはモーターの力が抜けているので、人は99°まで倒せてしまいます。
- **どう直したか**：肩を倒さずに、肘と手首で下げるように教え直しました（肩87.27°）。5回再生して5回とも成功しました。再生の前に肩の角度を確かめる手順も足しました。
- **驚くこと**：ロボットはできない命令を受けてもエラーを返さず、黙って動かない。しかも記録の上では「成功」になっていた。
- **出典**：LOG352 の冒頭、「## 位置2：肩 95° を超える教え方では、つかむ命令が6回とも全く動かなかった」「## 肩の上限 88° は、本線の fk_lookup.py には LOG257 から入っていた」「## 肩を倒さずに教え直すと、肩 87.27° で5回続けて成功した」「## 使わない3本：台帳の判定が実際と違う」
- ⚠ 捨てられたと確かめたのは95.53°以上だけです。88°は本線が安全のために置いた値で、本線では89.73°で止まった例もあります。「88°を超えると捨てられる」とは言い切れず、「約88°より深く」はログの表現どおりにとどめるのが安全です。

## 12. 学習の数字は良いのに外れる ［実機 mechArm 270 / π0.5］
- **何が起きたか**
  - 2,000ステップ：loss（学習の誤差）は0.1155 → 0.0057 まで下がりましたが、実機4回は4回とも、つかむ前に止まりました（爪がブロックに乗った。ずれは2〜3cm）。
  - 4,050ステップ：loss は0.0030 まで下がりましたが、実機2回とも「ブロックの奥の何もない所でグリッパーを閉じた」。
  - つかむ瞬間の土台と肩の角度は、3回ともほぼ同じで、どれもお手本の範囲の外でした。
- **なぜ止まったか**：お手本19本は、ブロックをほぼ同じ場所に置いて集めたものです。そのため「画像を細かく見なくても『いつもの場所へ手を伸ばす』だけで loss は下がります」。LOG348 では「お手本と同じ場面では当たるようになっていても、それが実機の別の場面でも当たるかは、loss からは分かりません」と書いています。
- **どう直したか**：学習を倍にしても、手を伸ばす先は変わりませんでした。「足りないのは学習の回数ではなく、ブロックの位置が違うお手本です」。次の手として、5か所19本のお手本を集めることにしました（LOG352）。それで学習し直した結果は、材料のログには入っていません。
- **驚くこと**：学習の誤差がほぼ半分になっても、アームが手を伸ばす先は変わらなかった。
- **出典**：LOG345「## loss はまだ下がっていたので…」「## 動画で見ると、手前の爪がブロックの上に乗っていた」、LOG348 の冒頭、「## 4,000ステップまでの loss は…」「## 実機の1回目は、ブロックの奥でグリッパーを閉じた」「## つかむ瞬間の土台と肩の角度は…」
- ⚠ 「空を閉じた」のは4,000ステップの方です。2,000ステップでは爪がブロックに乗って止まっていました。実機は4回と2回だけです。LOG345 では、原因の見立てを2回外しています（熱、指令の小ささ）。

## 参考：4段の分け方（LOG439）
スタンフォード大学の講義 AA274A（Marco Pavone、2019年秋の収録、2026年10月に無料公開。Lecture 1）にある「見る → 位置を知る → 決める → 動く」で、観察台帳の止まり方を分けた考察です。
- 見る：ぶつかって止まる
- 位置を知る：迷子
- 決める：向かい合い、出口をふさがれる
- 動く：その場で向きを変えても抜けられない
- 4段の外（運用）：下げた皿を載せたままになる

ログは「どれも、このときの見立てで、機体の中身は公開されていません」と断っています。

---

## 12項目を通して見えること
- 多くの止まりで、ロボットそのものは壊れていませんでした。止めていたのは通路の幅・行き止まり・待機場所の間隔・ドリンクバーの位置（1, 2, 4, 7）、人の動かし方と人手（6, 8, 5）、電源や角度の上限（10, 11）です。直す手も、ロボットの性能ではなく、置き方・決まり・部品の側にありました。
- 「直す作業は数秒、気づくまでは数十秒」「エラーを出さずに黙って止まる」「学習の誤差は下がるのに外れる」「シミュレーションで8割拾えたのは画面の線のおかげ」（1, 11, 12, 9）。どれも、止まったことが**数字や画面に出てこない**種類の止まりです。経営者・PM にとっては、「何を測れば気づけるか」が入れる前に確かめる中心になります。
- 「足せば良くなる」が何度も外れています。2台目・5台目・学習の回数・賢い道の引き方・通れる所を直す、の5つです（3, 4, 12, 7, 8）。どこが詰まりの元かを測ってから足す、という順番が12項目に共通しています。
- 書き手への注意：12のうち7つ（3〜9）はシミュレーションで、多くは1回か種0の比較です。ログ自身が「Unity の作りの弱さが出た」と書いている所もあります（4, 7, 8）。実店舗の動画（1, 2）は PUDU 製の数本だけです。実機（10〜12）は回数が少ないものの、原因と直した後の変化がいちばんはっきりしています。
```


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

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

---

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

**配膳ロボット（飲食）の悩み：人の手がかかる・運用で詰まる**
- センサーが太陽光などを障害物と誤認して立ち往生し、人の手で再設定が必要になるケースがある（出典：https://sanki1948robo.securesite.jp/rb/robopride/wp-content/uploads/2024/11/column-cover_deliveryrobot_disadvantages.png を含む記事、未確認）。
- 狭い通路では障害物や人を認識していても避けられず、立ち往生して人の手で動かす手間が発生する（出典：https://sanki1948robo.securesite.jp/rb/robopride/wp-content/uploads/2024/11/column-cover_deliveryrobot_disadvantages.png を含む記事、未確認）。
- スタッフとロボットの動線が干渉し、混雑時には運用効率が低下することがある（出典：https://sanki1948robo.securesite.jp/rb/robopride/wp-content/uploads/2024/11/column-cover_deliveryrobot_disadvantages.png を含む記事、未確認）。

**搬送ロボット（病院）の悩み：環境変化とトラブル**
- 病院搬送ロボットのトラブルは、機械的な故障だけでなく、環境や運用ルールに起因する「停止」や「迷子」が多くある（出典：https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFOiIm4PwB4rhaL3LWOymj8I3EfA7BbVitJxzwiyhTbnhUDSns88BtdCl0oEgFW5_r4r3qMk7IoytzBQm62v8_Xkmb0WSWFqA8fmvShiETGMADB5DfAXVhyKsXpF7uuwJpC1DcGjQ=、未確認）。
- 既存の天井裏などを通る搬送機は、途中で止まると業者を呼ぶ必要があり大きな時間のロスだった。ロボットなら廊下で止まっても誰かが取り出せるという理由で導入された事例がある（出典：https://connect.panasonic.com/jp-ja/case-studies/kyoto-u、2021年3月30日）。

**ロボットアーム・フィジカルAI（物流・製造）の悩み：PoC止まり・実機との乖離**
- シミュレーション結果だけで判断すると、照明、床面、通信、部品の個体差、センサー誤差などが「実機で初めて明らかになる」場合がある（出典：https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHEn6jwqEqgUh6LrK8IBk9_mIqrs0nUla4UuKY_ZXcjTAF8DNGiFgZGeXGx09_Pw6kbbtFZRBSbcvNwoG100T7lsf68sz7B6i3KnGrNEOCcnA7ksnWYk9ZJVUHcu53rAar4A_Zd1jFuEpuP2zXoQsCTWfk=、2026年7月1日）。
- AIの精度（正解率）だけを成功条件にすると、処理時間、誤停止、安全性、人の介入などの運用要件が抜け落ち、PoCから本番導入へ移行できない原因になる（出典：同上）。
- 現場では微妙な位置のずれが起きるため、決められた座標を繰り返すだけでなく、AIで認識して瞬時に補正する必要がある（出典：https://note.com/…、2026年7月29日）。

---

### 2. カタログや販売サイトが書く「導入前の確認」（ここで初めて分かることとの対比用）

カタログや販売サイトでは、止まることへの対策として**「事前の環境確認（通路幅や段差）」と「トライアル」**が主に推奨されています。

- 「最小通過幅は、すべての動線で走行できることを保証する数値ではありません。曲がり角・段差・床面・周囲の状況を確認し、導入前に機種と仕様をご案内します」（出典：https://qu-orix.com/…、未確認）。
- 「店内の動線があまりに複雑である場合や、階段のある店舗では対応が難しいため、導入前の十分な確認が必要です」（出典：https://sanki1948robo.securesite.jp/rb/robopride/…、未確認）。
- 「導入前にトライアルを実施し、実際の店舗で問題なく使えるかを確認しましょう。資料だけではわからない動作や使い勝手を事前に検証することで、導入後のトラブルを防げます」（出典：https://dfarobotics.com/…、2026年4月29日）。

**【対比のポイント】**
カタログ上は「通路幅を測り、トライアルでマッピングすれば走る」ように見えますが、今回依頼された12のログが示すのは、**「環境（段差や幅）以外の、運用ルール・複数台の干渉・人間の介入・ハードウェアの仕様」によって現場で予期せず止まる**という事実です。

---

### 3. 依頼の12項目は、世の中のどの悩みに当たるか

収集した悩みに対して、今回の12項目が「現場で本当に確かめるべきこと」としてどう紐づくかを整理しました。

**【悩みA：止まった時の対応（人の手がかかる）】**
カタログでは「障害物を避ける」とありますが、実際は止まった後の運用が課題です。
- **#1 店員が来るまで**：ロボットが止まっても誰もすぐには直さない（店員が来るまで18〜45秒以上放置される）という、運用上の盲点。
- **#9 カメラでは見つからない**：止まっているロボットを録画から見つけることすら難しい（線の表示を消すと検知率が72%から28%に落ちる）という、システム監視の限界。

**【悩みB：狭い通路・スタッフとの動線干渉（複数台運用の難しさ）】**
カタログでは「幅〇〇cm以上で走行可能」とありますが、台数が増えたり運用が変わると途端に詰まります。
- **#2 にらみ合い**：狭い通路で2台が向かい合うとシステムで解決できず、人が手でどかす羽目になる。
- **#3 2台目が待ちを延ばす**：28卓の狭い店では、1台が上限。2台にすると逆に入店待ちが約2倍に延びる。
- **#4 待機場所の止まり合い**：台数を増やす（5台）と、待機点への斜めの入り方という「ルールの欠陥」で詰まり合う。
- **#5 下げ膳で詰まる**：配膳だけでなく下げ膳も任せると、効率重視の細い店では待ちが延びてしまう。
- **#6 詰まるのは片付け**：ロボットを足しても、根本のボトルネック（片付けと案内）が解決しないと詰まる。

**【悩みC：環境変化とトラブル（シミュレーションと実機の差）】**
「マッピングすれば完璧に動く」わけではなく、線の引き方や人間の介入がエラーを生みます。
- **#7 線に縛ると詰まる**：決まった線しか走らせない設定自体が詰まりの元（地図を渡す方式に変えると60秒の止まりが57回から20回に減少）。
- **#8 直したら衝突が増えた**：病院で、人間が良かれと思って通れない所を直した（仮の動き）ことが、逆に搬送ロボットの衝突を増やす原因になる。

**【悩みD：PoC止まり・AIとハードの乖離】**
AIの学習精度（正解率）だけを追うと、実機に持ち込んだ際にハードウェアの壁にぶつかります。
- **#10 まさかの電源不足**：ブロックを落とす原因がAIではなく「12V・2A の電源アダプタの容量不足（5Aで解決）」という物理的な罠。
- **#11 命令が黙って捨てられる**：肩を深く倒す命令が、エラーも出さずにハードウェア側で無視される。
- **#12 学習の数字は良いのに外れる**：シミュレーション上の学習誤差（loss）は下がっても、実機では爪が奥で空振りして閉じるという乖離。

## Gemini が検索で見た出典

- securesite.jp: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFJnOfY0ungpAjOGjEiXs4XikTNqXJaZAwgKeqYlFixDVYrmYr1ID_KuW02PKkKCHOSRiTQuKUZzkHxXzcw7ExyBvNdYzyhcQhuyW79xG_NJEsKcLVrhEB62GGN_kzOESiDmFa6Ul4_2a17t37cNakmqZP-krG1YKWq9UlxQ-F8kGxCUmUVRkjOE0A=
- hos-robo.com: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFOiIm4PwB4rhaL3LWOymj8I3EfA7BbVitJxzwiyhTbnhUDSns88BtdCl0oEgFW5_r4r3qMk7IoytzBQm62v8_Xkmb0WSWFqA8fmvShiETGMADB5DfAXVhyKsXpF7uuwJpC1DcGjQ==
- panasonic.com: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFeU6zkIZF9CV6IPNfSmUptRgKw6kzLaT4y1TA0vfe8io_qBJ1EXimjIcZByPDfxHPkqId6ZmD27ItjcrafOkJpdV7VI5V02ZJzqnyuJSx_jbz9MAJyVSxLkFI4kdPyYDXWbZygNfX0_9U_O5We86XRrCjjcDvfSgVO0GSFaAfazg==
- dtsoken.com: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHEn6jwqEqgUh6LrK8IBk9_mIqrs0nUla4UuKY_ZXcjTAF8DNGiFgZGeXGx09_Pw6kbbtFZRBSbcvNwoG100T7lsf68sz7B6i3KnGrNEOCcnA7ksnWYk9ZJVUHcu53rAar4A_Zd1jFuEpuP2zXoQsCTWfk=
- note.com: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFo6UkzeB2KrtS3LcuHczZFMWzp4dhSAbnRVafd2tdr_pC2D2o0rJIjoVJOyvgstkEF8HYNKUEYWsxYfFv4QZ12aH9P_HJcfL8o9Ou9lsxEikeCEI0gnLjVmy8s5UAF5EdDlQ==
- qu-orix.com: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFpT1Oum8s9Wyk3V7OngbYpR4w662X4lGr5552PnNCcsT88cMgVDzt9Tu9JwB6kjrFEDPdnZRjEPZDbedhJF3SKKdb5EzwOfQLxst1usq686g==
- securesite.jp: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHNKAbnhtpOK45tGRMHrmrKmvCMH60O5TmhA8Fm27h7859_vUMuY5N1YXOFhCM1qK6m4aWFVRFFAaMpkSW99WbxhxphwSQ_rlX8QqW-pihk59zVOYbqzJ65wcQOe0Ur-HjfLBFAp0M0oKaWgxRF0hghBj3MKT9H9Iu5uCApGeaAFPOMTeyBbh0=
- dfarobotics.com: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFfV6s0eC0rScHrm-17gRphHxhTKEkIReFx4xiDf5cDDrp6JElDdvXZRT_LTKvOpEF0M0CInaxyhGJFQsrAnDqcfC2rMm2ky4asa-TYM0dOhZCIIFFJ2aNvUAP9
```


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

```markdown
**最も大きな修正は⑦です。「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台が自力で抜けられず、店員が片方を手でよけていた。 |
| 3 | 狭い28卓の店で2台にすると入店待ちが約2倍。1台が上限 | **LOG423.md「1台と比べると、どの案でも2台は1台に届かなかった」**。④・スタッフ2人・普通の混み具合で、1台13.8分、2台25.1分。1本道を1台ずつ通す案でも2台17.6分。各10種の中央値。ただし0・1台は前の版で、版を厳密にはそろえていない。**LOG393.md**の別段階では0台12.7分・1台14.4分・2台24.8分。 | **言い過ぎ**。「1台が上限」は、この店・人数・運用を超えて言えない。 | Unityの28卓・スタッフ2人の店では、普通の混み具合で1台13.8分に対し2台25.1分と、入店待ちが約2倍になった。試した改善案でも2台は1台より短くならなかった。比較には版の違いが残る。 |
| 4 | 5台にすると入店待ちが延びた。原因は待機点へ斜めに寄る入り方。決まりを変えて減らした | **LOG452.md「大型店の入店待ち（10種の中央値・分）」**。⑧・配膳だけで2台11.7分→5台17.2分。ただし台どうしの順番決めが不足する作りの影響あり。**LOG456.md「まっすぐ入る決まりの前と後」**では、5台の待機場所付近の30秒以上の詰まりが3,317秒→1,255秒。一方、入店待ちは12.22分→14.90分。**LOG465.md「人が待機点を通らない形の、前と後」**で追加変更後は詰まり809秒・入店待ち13.24分。 | **言い過ぎ**。「減らした」の対象が曖昧。斜めの入り方は大きな原因の一つで、入店待ちの原因全部ではない。 | Unityの大型店では、5台で待機場所付近の止まり合いが増えた。大きな原因の一つは、斜めに戻る台のセンサーに隣の待機台が入ること。まっすぐ入る変更で詰まりの時間は減ったが、同じ比較で入店待ちは短くならなかった。 |
| 5 | 下げ膳も任せると、通路にゆとりのある店では待ちが縮み、効率重視の細い店では延びた | **LOG444.md「6店の比較動画：配膳だけと配膳＋下げ膳を左右に並べた」**。ロボット2台・各条件1回の録画で、②⑤⑥は入店待ちが短縮、③④⑦は延長。例：⑤5.69分→4.85分、④17.48分→25.84分。本文は「ここから店ごとの答えを言い切ることはできません」と明記。**LOG440.md「依頼90・91」**の各10種の中央値では、入店待ちの向きがこの分類とそろわない店もある。 | **言い過ぎ**。各1回の録画で見えた傾向を、店の種類ごとの確定結果にしている。 | Unityの6店・ロボット2台を各条件1回ずつ録画した比較では、通路にゆとりのある3店で入店待ちが縮み、効率重視の3店で延びた。繰り返し集計では例外もあり、店の種類だけで結果は決められない。 |
| 6 | ロボットを足しても、詰まるのはレジではなく片付けと案内だった | **LOG397.md、LOG398.md、ともに「試算はレジで詰まり、3Dの店は片付けと案内で詰まる」**。46卓の店は0・1・2台で入店待ち8.1→6.6→5.5分、38卓の店は9.6→6.0→4.8分。2台でも「席は空いているのに待った」時間がそれぞれ3.4分・3.5分残った。各10種の中央値。 | **合っている**。Unity内の店全体の仕事の滞り。ロボット自体の停止とは区別が必要。 | Unityの46卓・38卓の店では、ロボットを増やすと入店待ちは縮んだが、片付けと案内が追いつかず、席が空いていても待つ時間が残った。 |
| 7 | 決まった線しか走らせない作りが詰まりの元。地図を渡すと60秒の止まりが57回から20回に | **LOG370.md「次の版：サイトは地図を渡し、道はロボットが地図の上で自分で引く」**で固定経路の問題を特定。**LOG374.md「2回目（ドリンクバーを動かした後）：60秒の止まりは20回」**の比較表は、③・2台・種0で「固定経路57回→地図で道を引く59回→ドリンクバー移動後20回」。 | **違う**。57回→20回を、地図を渡しただけの効果としている。 | Unityでは、決まった線だけを走る作りが詰まりの一因だった。地図で道を引く変更だけでは60秒以上の停止は57回→59回。さらにドリンクバーを移して抜け道を作ると20回になった。いずれも同じ条件・同じ種の1回ずつの比較。 |
| 8 | 病院で通れない所を直すと問題が増えた。元は職員の仮の動きだった | **LOG488.md「ロボットの問題は1日84件から132件に増え、37件は大廊下の東の端で起きた」**。仮の病院・秒速0.6m・種0。問題は急停止・ひやり・人によけさせた等の合計。**LOG491.md「依頼155」**で行き先を絞り132→68件、**「走っている間の問題は68件から19件」**で職員の動かし方を変更。追記では患者等の動きを足して19→51件。 | **合っている**。ただし項目名の「衝突が増えた」は**言い過ぎ**。件数は衝突事故の数ではない。 | Unityの仮の病院で、通れなかった患者・職員を通すと、急停止やひやりなどの問題が84件→132件に増えた。通行可能な場所を職員の普段の行き先にも使う仮の決まりが増加に関わっていた。 |
| 9 | 録画で長い止まりを見つける試しで、道の線を消すと拾えた割合が72%から28%に | **LOG418.md「線を消すと、長い止まりを拾えた割合は72%から28%に落ちた」**。Unity録画の切り出し画像を異常検知で判定。誤報5%の条件で、30秒以上の停止の検出率が67/93件（72%）→26/94件（28%）。撮り直しで動きも変わり、同一場面どうしの比較ではない。 | **合っている**。ただし項目名の「カメラでは見つからない」は**言い過ぎ**。この検出方法・条件での結果。 | Unity録画から切り出した画像1枚で長い停止を検出する試験では、誤報5%の条件で、画面の経路線ありは72%、線なしは28%を拾えた。実店舗のカメラの検出性能を測った値ではない。 |
| 10 | ブロックを落とす原因は電源。12V・2Aを5Aに替えると落とさなくなった | **LOG487.md「mechArm 270 の電源は40W、つないでいたアダプターは24Wだった」**では電源不足は未確定。**LOG504.md「12V・2A の日の3回と、つかんでいる間の爪の電流を並べた」**では、同じモデル・閉じる値・位置5で成功1/3回→5/5回。ただし交換後も1回は人が持ち上げを補助し、その際に電流低下あり。教えた動きの再生は計7回成功。 | **合っている**。LOG504まで含めた、今回の実機試行の結果。完全解消・全自動成功とは言えない。 | 実機mechArm 270で、12V・2Aから12V・5Aへ電源を替えると、位置5の試行は5回とも落とさず成功した。うち1回は人が持ち上げを補助し、爪の電流低下も残った。 |
| 11 | 肩を約88°より深く倒す命令が、エラーなしに捨てられた | **LOG352.md「位置2：肩95°を超える教え方では、つかむ命令が6回とも全く動かなかった」**。肩95.53〜99.22°の姿勢で6回とも動かず、87.27°に教え直すと5回成功。**「肩の上限88°は、本線の fk_lookup.py にはLOG257から入っていた」**では、88°は本線の姿勢選択上限。本文には肩88.76°での再生成功もある。 | **言い過ぎ**。冒頭の要約とは一致するが、「88°超」を厳密な拒否境界にする根拠は不足。 | 実機mechArm 270では、肩95.53〜99.22°の姿勢への命令が、エラーなしに6回とも動かなかった。肩87.27°で教え直すと5回続けて成功した。本線では肩88°以内の姿勢を選ぶ設定にしていた。 |
| 12 | 学習の誤差は下がっても、実機では爪が奥で空を閉じた | **LOG348.md「4,000ステップまでの loss は0.0030〜0.0035で、下がり方はゆるやかになった」**、**「実機の1回目は、ブロックの奥でグリッパーを閉じた」**、**「実機の2回目も、同じ場所でグリッパーを閉じた」**。学習2,000→4,000ステップ、4,000時点の誤差0.0030、実機2回とも空振り。**LOG345.md「動画で見ると、手前の爪がブロックの上に乗っていた」**は追加学習前の別の止まり方。 | **合っている**。空を閉じた事実の直接の出典はLOG348。 | 学習を2,000から4,000ステップに増やし、学習誤差が0.0030まで下がっても、実機mechArm 270は2回ともブロックの奥で爪を閉じ、つかめなかった。 |

検証環境は、**①②が実店舗の動画観察、③〜⑧がUnityのシミュレーション、⑨がUnity録画を使った画像検知試験、⑩〜⑫が実機**です。

参考のLOG439は、本文自身が「実験の記録ではなく、対話しながら考えた記録」としています。「見る・位置を知る・決める・動く」の分類は作者の考察で、各機体の内部原因を実証した結果としては扱えません。
```


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

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

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

---

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

配膳ロボット・病院の搬送ロボット・ロボットアームが、現場で止まった瞬間を12個集めました。
出どころは3つです。実店舗の動画のコマ送り、Unity で再現した店と病院のシミュレーション、机の上の実機 mechArm 270。
1つごとに「なぜ止まったか」と「入れる前に、自分の現場で確かめること」を付けています。ここに並べたのは、動いているときの性能ではなく、止まったときのことです。

---

## 先に、12個に共通していたこと

- **直すのは数秒。時間を食うのは、人が気づいて来るまで。**　実店舗の動画では、止まったロボットを店員が直す作業は1〜10秒、来るまでが18秒〜53秒以上でした。
- **足すほど良くなる、とは限らない。**　シミュレーションでは、2台目・5台目・下げ膳・通り道を開けること、どれも条件しだいで待ちや問題を増やしました。
- **数字が良くても、実物は止まる。**　実機では、学習の誤差が下がっても爪は空を閉じ、命令はエラーなしに捨てられ、ブロックを落とす原因は電源でした。

### 出どころの書き分け

| 印 | 何か | 数字の読み方 |
|---|---|---|
| 実店舗の動画 | SNS に上がった実店舗の配膳ロボットの動画を、0.25〜1秒ごとのコマで読んだもの | 動画は編集されていて、止まり始めが映っていないものも多い。秒数は目安 |
| シミュレーション | Unity で再現した仮の店・仮の病院で、お客さん・スタッフ・ロボットを1人ずつ動かしたもの | 実在の店や病院で測った値ではない。「この条件ならこう動く」を、条件を1つずつ変えて比べた結果 |
| 実機 | 机の上の小型ロボットアーム mechArm 270、1台 | 実物で測った値。ただし1台・1つの作業で、回数は少ない |

---

## 12個の一覧

| # | 止まる瞬間 | 現場 | 出どころ | 入れる前のひとこと |
|---|---|---|---|---|
| 1 | 店員が来るまで | 飲食店 | 実店舗の動画 | 止まった知らせは、だれの手元に届くか |
| 2 | にらみ合い | 飲食店 | 実店舗の動画・シミュレーション | 2台がすれ違えない通路は何本あるか |
| 3 | 2台目が待ちを延ばす | 飲食店 | シミュレーション | 台数を、卓の数でなく通路で決めたか |
| 4 | 待機場所の止まり合い | 飲食店 | シミュレーション | 待機場所に、ロボットはどの向きから入るか |
| 5 | 下げ膳で詰まる | 飲食店 | シミュレーション | 卓の横で待つロボットの脇を、人が通れるか |
| 6 | 詰まるのは片付け | 飲食店 | シミュレーション | 浮いた人の手は、片付けと案内へ回るか |
| 7 | 線に縛ると詰まる | 飲食店 | シミュレーション | 入った道を戻るしかない通路はあるか |
| 8 | 直したら問題が増えた | 病院 | シミュレーション | 職員がふだんどう動くかを書き出せるか |
| 9 | カメラの見張りが拾えない | 飲食店 | シミュレーションの録画 | 試した映像は、本物のカメラと同じ見た目か |
| 10 | 学習の数字は良いのに外れる | アーム | 実機 | 成績を「何回中何回できたか」で見たか |
| 11 | 命令が黙って捨てられる | アーム | 実機 | 実行されなかった命令は、記録に残るか |
| 12 | まさかの電源不足 | アーム | 実機 | 本体のラベルと電源のラベルを見比べたか |

並べ方は、導入を決めるときに出てくる問いの順です。「止まったら、だれが来るか」→「何台入れるか」→「どこを走らせるか」→「その数字を信じてよいか」。

---

## 第1章　止まったら、だれが来るか

導入の資料に書かれるのは、ロボットが運んでいる時間です。実店舗の動画で長かったのは、止まってから人が来るまでの時間でした。

### 1. 店員が来るまで

- **現場**：飲食店（実店舗の動画）
- **何が起きたか**：実店舗の配膳ロボットの動画5本をコマ送りで読みました。止まった3本で、店員が直す作業は1〜10秒、止まってから店員が来るまでは18秒〜45秒以上でした。ファミレスの通路で2台が向き合った1本では、店員の手が動いたのは約5秒、来るまでは映っているだけで41秒以上です。
- **なぜ止まったか**：ロボットは止まっている間、「通してほしい」と声をかけ続け、足元の明かりを赤くしていました。けれどもそれはお客さんへの合図で、ロボットを動かせる店員の手元に知らせが届いた様子は、どの動画にも映っていませんでした。店員が早く来たのは、店員がよく通るドリンクバーの前で止まったときだけです。
- **入れる前に確かめること**
  - 止まったとき、知らせはだれの手元に、何で届くか。ロボットの声と光だけか、店員が持つ端末にも届くか。
  - 止まりやすい場所（通路の細い所・待機場所）は、店員がふだん通る所から見えるか。
- **出典**：[/record/serving-robot-video-ledger](/record/serving-robot-video-ledger)
- **ハコブくんの一言**：「止まってからの45秒、ずっと『通して』って言ってた。聞こえていたのは、お客さんだけ。」

### 2. にらみ合い

- **現場**：飲食店（実店舗の動画・シミュレーション）
- **何が起きたか**：実店舗の動画で、2台が狭い通路や待機場所の横で正面から向き合うと、ロボットどうしでは解けず、店員が来て手で片方をどかしていました。ロボットどうしが関わる動画4本では、店員が来るまで18〜53秒以上、手で直す作業は5秒前後です。一方、商業施設の広い通路の動画では、人が密集してもロボットは止まり続けませんでした。シミュレーションでは、同じ向かい合いで2台が9分にらみ合いました。
- **なぜ止まったか**：詰まるのは1台分の幅の通路でした。どちらが譲るかの決まりは、調べた範囲ではどのメーカーも公式には公開していませんでした。取扱説明書で分かったのは「すれ違えない通路は1台ずつ通す」「ふさがれたら待って道を組み直す」の2つだけです。公開資料にある、2台がすれ違うのに要る幅は1.5m〜1.6m超でした。また配膳ロボットはその場で回れても真横には動けないので、前がふさがると、向きを変えても道は開きません（参考：[/record/serving-robot-stops-four-stages-stanford](/record/serving-robot-stops-four-stages-stanford)）。
- **入れる前に確かめること**
  - 店の通路で、2台がすれ違えない幅の区間はどこに何本あるか。
  - 向き合ったら、どちらが下がるのか。販売会社に聞いて、答えが返ってくるか。
- **出典**：[/record/serving-robot-faceoff-staff-resolves](/record/serving-robot-faceoff-staff-resolves)、[/record/serving-robot-jams-are-aisles](/record/serving-robot-jams-are-aisles)
- **ハコブくんの一言**：「ぼくも相手も、相手がどくのを待ってる。礼儀正しいって、こういうとき困る。」

---

## 第2章　何台入れるか

ここからはシミュレーションです。仮の店で、ロボットの台数と使い方だけを変え、同じお客さんの来かたで比べました。実店舗で必ずこうなるという数字ではありません。どこを確かめればいいかの目印として読んでください。

### 3. 2台目が待ちを延ばす

- **現場**：飲食店（シミュレーション。28卓・スタッフ2人の、通路の狭いファミレス）
- **何が起きたか**：配膳ロボットを1台から2台にすると、入店待ちは13.8分から25.1分へ約2倍に延びました。動けなくなったロボットをスタッフが動かしに行く回数は、昼のピーク2時間で13回から54回に増えました。表計算の試算では、2台入れれば待ちは3分ほどに縮むはずの店です。
- **なぜ止まったか**：ロボットどうしが1本道で向かい合い、ふさぎ合っていました。止まった相手の半分はもう1台のロボットです。「1本道に向かいからロボットが来ていたら、手前で待つ」決まりにすると、不利は半分ほどに縮みました。それでも1台のときには届きませんでした。一方通行にする案は、混むと逆に悪くなりました。
- **入れる前に確かめること**
  - 店の平面図で、1本道（すれ違えない通路）は何本あるか。台数を、卓の数や混み具合ではなく、通路で決めたか。
  - 2台目を入れる前に、1台のときの「動かしに行った回数」を数えてあるか。
- **出典**：[/record/serving-robot-one-per-narrow-restaurant](/record/serving-robot-one-per-narrow-restaurant)、[/record/small-store-second-robot-wait](/record/small-store-second-robot-wait)
- **ハコブくんの一言**：「2台目のぼくがいちばんよく出くわすのは、1台目のぼく。」

### 4. 待機場所の止まり合い

- **現場**：飲食店（シミュレーション。70卓・312席の大型ファミレス）
- **何が起きたか**：配膳ロボットを2台から5台に増やすと、入店待ちは11.7分から17.2分に延びました。3台までは11.5〜11.7分でほぼ同じ、4台で13.2分です。ロボットが受け渡し口と待機場所のまわりで止まり合い、そこを通る片付けのスタッフが動けず、卓が空きませんでした。
- **なぜ止まったか**：0.8m 間隔で並んだ待機点へ斜めに寄るため、隣で待つロボットが前のセンサーに入っていました。決まりを3つ変えて減らしています（どれも10回の中央値）。
  - 待機点の真下からまっすぐ入る：待機場所のそばの止まり合いが、1回の営業あたり3,317秒から1,255秒へ
  - 人は待機点の列を通り道にしない：さらに809秒へ。ロボットを助けに呼ばれる回数は180回から22回へ
  - 近くのスタッフが、止まったロボットをすぐ押す：止まっていた時間の合計が12,896秒から8,068秒へ、入店待ちは17.6分から11.3分へ

  なお、このシミュレーションのロボットには、実物の配膳ロボットにある台どうしの順番決めが入っていません。4台・5台の悪くなり方は、そのぶん大きく出ています。
- **入れる前に確かめること**
  - 待機場所は何台分で、間隔は何mか。ロボットはどの向きから入るか。
  - 待機中のロボットの列を、スタッフやお客さんが通り道にしていないか。
- **出典**：[/record/large-restaurant-five-serving-robots-longer-wait](/record/large-restaurant-five-serving-robots-longer-wait)、[/record/serving-robots-jam-cause-standby-entry](/record/serving-robots-jam-cause-standby-entry)、[/record/serving-robot-jam-three-rules](/record/serving-robot-jam-three-rules)
- **ハコブくんの一言**：「休むための場所が、いちばん渋滞してた。」

### 5. 下げ膳で詰まる

- **現場**：飲食店（シミュレーション。ファミレス6店）
- **何が起きたか**：配膳ロボットに下げ膳（食べ終えた皿を洗い場へ運ぶ仕事）も任せると、スタッフ1人が歩く距離は12条件すべてで減りました。ただし通路の細い店でロボット2台のときは、お客さんが帰ってから卓が使えるまでの時間が延びました。③の店で4.1分から6.1分、⑦の店で4.5分から8.1分です。6店を同じお客さんの来かたで1回ずつ並べると、通路にゆとりのある3店では入店待ちが縮み、通路を詰めた効率重視の3店では延びました。
- **なぜ止まったか**：下げ膳のロボットが卓でスタッフを待つあいだ、通路をふさいでいました。
- **入れる前に確かめること**
  - 下げ膳のロボットが卓の横で待つ間、その脇をスタッフ・お客さん・もう1台が通れるか。
  - 「歩く距離が減る」と「卓が空くのが遅れる」の、どちらを先に見て判断するか。
- **出典**：[/record/serving-robot-sim-bussing-narrow-aisles](/record/serving-robot-sim-bussing-narrow-aisles)、[/record/serving-robot-bussing-depends-on-aisles](/record/serving-robot-bussing-depends-on-aisles)
- **ハコブくんの一言**：「お皿を待ってるだけなのに、通路では立派な壁。」

### 6. 詰まるのは片付け

- **現場**：飲食店（シミュレーション。46卓と38卓のファミレス）
- **何が起きたか**：ロボットを0台・1台・2台と足すと、入店待ちは46卓の店で8.1分・6.6分・5.5分、38卓の店で9.6分・6.0分・4.8分と縮みました。ここまでは試算と同じ向きです。ただ、詰まる場所が違いました。試算ではレジの会計待ちで詰まるのに、シミュレーションではレジは詰まりませんでした。代わりに「席は空いているのに待った」時間が、試算の2〜8倍になりました。
- **なぜ止まったか**：このシミュレーションのスタッフは、片付け・案内・会計・料理運びを1人ずつ順番にこなして店の中を歩くので、片付けと案内が後回しになっていました。ロボットが料理を運んでも、その先の片付けと案内が追いつきません。もう1つ、受け渡し口のすぐ横に待機場所がある形は、それまでの5店すべてに共通していて、どの店でも同じ所でロボットどうしが詰まっていました。
- **入れる前に確かめること**
  - 今の店で、席は空いているのにお客さんを待たせている時間はどれくらいあるか。
  - ロボットで浮いたスタッフの手を、片付けと案内へ回す段取りを決めてあるか。
- **出典**：[/record/large-store-cleanup-bottleneck](/record/large-store-cleanup-bottleneck)、[/record/standby-jam-every-store](/record/standby-jam-every-store)
- **ハコブくんの一言**：「料理は届けた。次のお客さんが座る卓は、まだ片付いてない。」

---

## 第3章　どこを走らせるか

### 7. 線に縛ると詰まる

- **現場**：飲食店（シミュレーション。42卓のファミレス）
- **何が起きたか**：決まった1本の線の上しか走らない作りのロボットは、2台が通路で向かい合ったまま動けなくなりました。そこで、店の地図を渡して道を自分で引き、ふさがったら3秒で回り込む形にし、行き止まりの通路もなくしました。すると60秒以上の止まりは57回から20回に減り、ロボットが運べた皿の割合は76%から99%になりました。
- **なぜ止まったか**：線に縛られたロボットは横へ寄れません。さらに、ドリンクバーと6人席の間が0.4mしかない行き止まりの通路があり、入った道を戻るしかないので、行きと帰りのロボットがそこで出会っていました。道の引き方を変えただけでは、止まりは57回から59回とほぼ変わらず、残った詰まりの7割がこの1か所に集まっていました。ドリンクバーを動かして抜け道を作ると、ここでの詰まりはなくなりました。
- **入れる前に確かめること**
  - ロボットは決まった線をなぞるのか、地図の上で道をその都度引くのか。
  - 店に、入った道を戻るしかない行き止まりの通路はあるか。そこを動く家具で作っていないか。
- **出典**：[/record/serving-robot-fixed-route-jam](/record/serving-robot-fixed-route-jam)、[/record/serving-robot-map-planner](/record/serving-robot-map-planner)
- **ハコブくんの一言**：「線の上なら迷わない。線の上で出会ったら、どっちも動けない。」

### 8. 直したら問題が増えた

- **現場**：病院（シミュレーション。仮の病院の外来の階で、検体や薬を運ぶ搬送ロボット）
- **何が起きたか**：それまで行き先へ歩いて行けなかった患者と職員41人を通すと、ロボットに起きる問題（急に止まった・ひやり・人がよけさせられたなど）は1日84件から132件に増えました。増えた48件のうち37件は、通り抜けや付き添いのために開けた所へ、職員がふだんの行き来でも行くようになった分です。
- **なぜ止まったか**：問題の数を決めていたのは、ロボットより人の動き方でした。それまで職員141人は、「1人が1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動かしていました。これを持ち場ごとの型と用事で動かす形に替えると、走っている間の問題は1日68件から19件に減りました。ところが続けて患者の動きを直すと、採血の所に最大41人が集まり、19件から51件に増えています。道の選び方も効きました。外来の混む大廊下を避けて職員通路を通すと、廊下での問題は1日111回から68回に約4割減りました。代わりに、検体が届くのは約2分遅くなりました。
- **入れる前に確かめること**
  - ロボットの通り道を、職員と患者が実際にどう使っているかを、持ち場と用事ごとに書き出せるか。
  - 道を開けたり変えたりしたら人の流れも変わる、という前提で、変えたあとにもう一度数えるか。
- **ひとこと**：公表されている病院の導入事例では、1日66〜172分の削減時間は出ていました。けれども、ロボットが廊下で何回止まり、人と何回ぶつかりそうになったかは出ていませんでした（[ロボスタ 2026-08-04](https://robotstart.info/article/2026/08/04/382233.html)。LOG477 で調べた範囲）。走らせる道と速さを決めるには、そこが要ります。
- **出典**：[/record/hospital-transport-robot-avoid-outpatient-hall](/record/hospital-transport-robot-avoid-outpatient-hall)、[/record/hospital-transport-robot-blocked-paths-more-conflicts](/record/hospital-transport-robot-blocked-paths-more-conflicts)、[/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)
- **ハコブくんの一言**：「廊下でいちばん読めないのは、ぼくの道じゃなくて、人の予定。」

---

## 第4章　その数字を信じてよいか

### 9. カメラの見張りが拾えない

- **現場**：飲食店（シミュレーションの録画）
- **何が起きたか**：シミュレーションの店の録画から、配膳ロボットの30秒以上の止まりを画像の異常検知（PatchCore）で見つける試しをしました。画面に描かれていたロボットの進む予定の線を消すと、拾えた割合は72%から28%に落ちました。ロボットどうしの詰まりは、線があるときは43件中23件、消すと47件中4件しか拾えませんでした。お客さんとすれ違って止まった場面は、線がなくても17件中13件を拾えています。
- **なぜ止まったか**：画像のAIは、実際のカメラには映らない道の線を手がかりにしていました。画像1枚では、ロボットどうし・スタッフとの詰まりはほとんど見分けられませんでした。
- **入れる前に確かめること**
  - カメラで止まりを見張る提案なら、試した映像は、自分の店のカメラと同じ見た目か。
  - 拾えた割合を、止まり方ごと（お客さん・スタッフ・ロボットどうし）に出してもらえるか。
- **出典**：[/record/serving-robot-jam-detection-without-path-lines](/record/serving-robot-jam-detection-without-path-lines)
- **ハコブくんの一言**：「AIが見ていたのは、ぼくじゃなくて、ぼくの足元の線だった。」

### 10. 学習の数字は良いのに外れる

- **現場**：ロボットアーム（実機。mechArm 270 と、ロボット用のAIモデル π0.5）
- **何が起きたか**：お手本19本で学習させたAIで初めて動かすと、爪がブロックの上に乗って止まりました。位置が爪1本分（2〜3cm）ずれていたので、学習を2,000ステップから4,000ステップに倍にしました。学習の誤差（loss）は0.0057前後から0.0030まで下がりましたが、実機では2回とも、爪はブロックの奥で空を閉じました。
- **なぜ止まったか**：お手本19本は、ブロックをほぼ同じ場所に置いて集めたものでした。それなら画像を細かく見なくても「いつもの場所へ手を伸ばす」だけで誤差は下がります。足りなかったのは学習の回数ではなく、置き場所の違うお手本でした。もう1つ、最初に止まった原因を関節の数字だけで2回見誤り（熱、指令の小ささ）、動画を見て初めて分かっています。
- **入れる前に確かめること**
  - 学習に使ったお手本は、自分の現場のばらつき（物の置き場所・向き・種類）をどこまで含んでいるか。
  - 成績を、学習の数字ではなく、実物で何回中何回できたかで見たか。止まった瞬間の動画は残るか。
- **出典**：[/record/pi05-mecharm-first-real-run](/record/pi05-mecharm-first-real-run)、[/record/pi05-mecharm-4000-steps](/record/pi05-mecharm-4000-steps)
- **ハコブくんの一言**：「テストは満点。出たのは、いつも同じ場所の問題だけだったけど。」

### 11. 命令が黙って捨てられる

- **現場**：ロボットアーム（実機。mechArm 270）
- **何が起きたか**：肩を約88°より深く倒す命令が、エラーなしに捨てられました。手で教えた肩95.53〜99.22°の姿勢を再生しようとすると、つかむ命令を6回送って6回とも無視され、アームは1°も動きません。肩87.27°で教え直すと、同じ場所で5回続けてつかめました。
- **なぜ止まったか**：手で教えるときはモーターの力が抜けているので、人はアームが受け付けない角度まで動かせてしまいます。アームはその命令を、何も知らせずに捨てていました。同じ回では、動いている途中で爪を閉じたために、以降の命令を受け付けなくなる止まり方も出ています（「着いた」の判定を8°から2〜3°に戻して直りました）。
- **入れる前に確かめること**
  - 送った命令が実行されなかったとき、エラーとして記録に残るか。
  - 関節ごとに、受け付ける角度の範囲が書き出されているか。教える人はそれを知っているか。
- **出典**：[/record/teach-replay-19-demos](/record/teach-replay-19-demos)
- **ハコブくんの一言**：「『できません』と言わずに、聞かなかったことにする。人の職場なら、いちばん困るタイプ。」

### 12. まさかの電源不足

- **現場**：ロボットアーム（実機。mechArm 270）
- **何が起きたか**：つかんだブロックを持ち上げる途中で落としていました。本体のラベルは40Wを求めているのに、つないでいたのは12V・2A（24W）のアダプターで、求める量の6割です。12V・5A（60W）に替えると、同じAI・同じ設定で、落としていた置き場所での成功が3回中1回から5回中5回になりました。12V・2A の日は3回とも人が途中で持ち上げ直していましたが、5A では5回のうち4回、人は手を出さずに終わりました。手で教えた動きの再生も7回すべて成功しています。替えたアダプターは3,355円です。
- **なぜ止まったか**：爪のサーボの電流が、指令を何も送っていないのに急に0付近まで落ちていました。落ちる瞬間の多くは、アームを動かす指令を送った直後です。アームが届いたとき箱にアダプターがなく、あとから別に届いたのが12V・2A で、8か月の実機の記録はすべてこの電源で取っていました。はじめは学習の問題（持ち上げが足りない）に見えていました。そのままお手本を撮り足していたら、爪が緩みかけたお手本が学習データに混ざるところでした。
- **入れる前に確かめること**
  - 本体のラベルが求める電源と、実際につないでいる電源（アダプター・回路）を見比べたか。
  - 失敗をAIやソフトのせいと決める前に、電源とつなぎ方を確かめる順番になっているか。
- **出典**：[/record/mecharm-270-drops-block-underpowered-adapter](/record/mecharm-270-drops-block-underpowered-adapter)、[/record/mecharm-270-5a-adapter-stops-dropping-block](/record/mecharm-270-5a-adapter-stops-dropping-block)
- **ハコブくんの一言**：「AIのせいにされかけたけど、おなかがすいてただけ。」

---

## 持ち帰り用：入れる前の確かめ表

自分の現場で、上から順に埋めてみてください。答えが出ない所が、入れてから止まる所の候補です。

**止まったら、だれが来るか**
- [ ] 止まった知らせは、ロボットの声と光だけでなく、店員・職員の手元に届くか（#1）
- [ ] 止まりやすい場所は、人がふだん通る所から見えるか（#1）
- [ ] 2台が向き合ったとき、どちらが下がるか、販売会社から答えをもらったか（#2）

**何台入れるか**
- [ ] 平面図で、2台がすれ違えない通路の数を数えたか（#2・#3）
- [ ] 台数を、卓の数ではなく通路で決めたか（#3）
- [ ] 待機場所の台数・間隔・入る向きを決めたか。人がその列を通らないか（#4）
- [ ] 下げ膳を任せるなら、卓の横で待つロボットの脇を人が通れるか（#5）
- [ ] 浮いた人の手を、片付けと案内へ回す段取りがあるか（#6）

**どこを走らせるか**
- [ ] 行き止まりの通路はないか。あれば、そこを動く家具で作っていないか（#7）
- [ ] 通り道を、人が実際にどう使っているかを書き出したか。道を変えたあとに数え直すか（#8）

**その数字を信じてよいか**
- [ ] 見張りのカメラは、本物の映像で、止まり方ごとに試したか（#9）
- [ ] AIの成績を、学習の数字でなく実物の成功回数で見たか。止まった瞬間の動画は残るか（#10）
- [ ] 実行されなかった命令は記録に残るか（#11）
- [ ] 本体のラベルと電源のラベルを見比べたか（#12）

---

## 終わりに

1. **自分の現場で確かめる。**　上の表を、店や病院の平面図を広げて埋めてみてください。いちばん効くのは、ロボットが止まりそうな場所に、人がふだんいるかどうかです。
2. **シミュレーションの動画を見る。**　[試算のページ（/series8）](/series8)で店の形を選ぶと、その店を Unity で動かした動画と、配膳だけ・下げ膳も任せた場合を並べた動画を見られます。
3. **自分の現場で測りたいときは、[/message](/message) に1行ください。**
```


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

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

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

---

## 先に、12を並べて分かったこと

- **多くの止まりで、ロボットは壊れていませんでした。** 止めていたのは、通路の幅、行き止まり、待機場所の間隔、片付けの手、人の動かし方、電源でした。直す手もロボットの性能ではなく、置き方・決まり・部品の側にありました。
- **止まったことが、数字にも画面にも出ない止まり方があります。** ロボットの合図はお客さんには届いても店員には届かない。できない命令はエラーなしに捨てられる。学習の数字は良いのに外れる。どれも、何を測れば気づけるかを入れる前に決めておかないと見えません。
- **「足せば良くなる」が5回外れました。** 2台目、5台目、賢い道の引き方、通れる所を直す、学習を倍にする、の5つです。詰まりの元を測ってから足す、という順番が12に共通しています。

販売サイトが勧める導入前の確認は、主に「通路幅や段差を確かめること」と「実際の店で試すこと」です（出典：dfarobotics.com の導入解説、2026年4月29日）。この図鑑は、その試しの間に何を見ればよいかを集めたものです。

各項目の印の意味は次のとおりです。
- 【実店舗の動画】SNS に上がった実際の店の動画を、コマ送りで読んだもの
- 【シミュレーション】Unity で再現した店・病院で回したもの。実店舗で必ず起きるという意味ではありません
- 【実機】手元の mechArm 270 で試したもの

---

## 一　止まったことが、だれにも届かない

### 1. 店員が来るまで　【実店舗の動画】
- **現場**：飲食店（配膳ロボット）
- **何が起きたか**：店員が直した3本の動画では、直す作業は約5秒、1〜2秒、約10秒でした。それに対して、店員が来るまでは41秒以上、45秒以上、約18秒かかっていました。のちに見た4本目では、来るまでに53秒以上かかっています。
- **なぜ止まったか**：直接の原因は、1台分の幅で2台が向かい合ったことと、隣の台に出口をふさがれたことです。店員がなかなか来なかったのは、ロボットの声かけと赤い明かりがお客さん向けの合図だったからです。店員の手元に知らせが届いた様子は、どの動画にも映っていませんでした。
- **入れる前に確かめること**
  - 止まったとき、店員の手元（端末・インカム）に知らせが届くか。それとも光と声だけか。
  - 試しの期間に、「止まってから人が来るまで」と「直すのにかかった時間」を別々に測っているか。
- **出典**：[/record/serving-robot-video-ledger](/record/serving-robot-video-ledger)
- 動画は編集されているので、秒数は下限です。
- **ハコブくん**：「赤く光って、声も出してるんです。届いてるのが、お客さんだけなんです。」

### 2. にらみ合い　【実店舗の動画】【シミュレーション】
- **現場**：飲食店（配膳ロボット）
- **何が起きたか**
  - 実店舗の動画：和食の店で、待機場所の横の2台が向かい合いました。2台ともその場で向きを変え続けて53秒以上進めず、店員が空の方を手で寄せると約4〜5秒で解けました。
  - シミュレーション：42卓・通路95cm の店で、2台が約9分10秒止まりました。そのあいだスタッフは、同じ卓へ運ぶのを5回あきらめています。
- **なぜ止まったか**：2台のどちらが譲るかの決まりは、調べた範囲ではどのメーカーも公式に公開していませんでした。取扱説明書で分かったのは、すれ違えない幅では交互に通すこと（すれ違いに要る幅は、PUDU が1.6m超、KEENON T8 が1.5m超）と、しばらく待ってから道を組み直すこと（BellaBot Pro の初期値は30秒）の2つだけです。
- **シミュレーションで試した直し方**：「30秒動けなければ近くの店員が来て、着いてから15秒で空の方を動かす」という決まりを足しました。約9分の止まりは、助け2回・約105秒で解けました。
- **入れる前に確かめること**
  - 自分の店で、すれ違いに要る幅より狭い所はどこか。そこで2台が向かい合ったら、だれが何秒で来るか。
  - 2台が向かい合ったときにどちらが譲るのかを、メーカーに聞いて答えが返ってくるか。
- **出典**：[/record/serving-robot-faceoff-staff-resolves](/record/serving-robot-faceoff-staff-resolves)、[/record/serving-robot-jams-are-aisles](/record/serving-robot-jams-are-aisles)
- 集めた実店舗の動画4本は、すべて同じメーカーの機体でした。見た動画の中には、ロボットどうしで解けた場面はありませんでした。
- **ハコブくん**：「ぼくも向こうも、譲り方を教わっていないんです。だから二人で、店員さんを待ちます。」

### 3. 命令が黙って捨てられる　【実機】
- **現場**：ロボットアーム（mechArm 270）
- **何が起きたか**：手で教えた動きを再生すると、つかむ位置へ降りる命令を6回送って、6回とも動きませんでした。エラーは出ず、動いた角度は最大1.50°で、止まっているときの揺れと変わりません。しかも動いていない2本が、記録の上では「つかめた・箱に入った」になっていました。
- **なぜ止まったか**：教えた肩の角度は95.53〜99.22°でした。メーカー公式の肩の範囲は−85°〜+90°です。送る側のライブラリは±190°でしか確かめないので、範囲の外の命令もそのまま送られ、アーム側で黙って捨てられていました。手で教えるときはモーターの力が抜けているので、人は範囲の外まで倒せてしまいます。
- **どう直したか**：肩を倒さず、肘と手首で下げるように教え直しました（肩87.27°）。5回再生して5回とも成功しました。再生の前に肩の角度を確かめる手順も足しました。
- **入れる前に確かめること**
  - 動ける範囲の外の命令を送ったとき、エラーが返るか。黙って止まるか。
  - 試しの記録の「成功」は、だれが、何を見て付けているか。動画と照らしているか。
- **出典**：[/record/teach-replay-19-demos](/record/teach-replay-19-demos)
- **ハコブくん**：「できない命令は、聞かなかったことにします。『できません』と言う口がないので。」

### 4. 学習の数字は良いのに外れる　【実機】
- **現場**：ロボットアーム（mechArm 270、AI モデル π0.5）
- **何が起きたか**
  - 2,000ステップ：学習の誤差（loss）は0.1155から0.0057まで下がりました。ところが実機では4回とも、爪がブロックの上に乗って、つかむ前に止まりました。
  - 学習を倍の4,050ステップにすると、誤差は0.0030まで下がりました。それでも実機では2回とも、ブロックの奥の何もない所で爪を閉じました。
- **なぜ止まったか**：お手本19本は、ブロックをほぼ同じ場所に置いて集めたものでした。画像を細かく見なくても「いつもの場所へ手を伸ばす」だけで、誤差は下がります。お手本と同じ場面で当たっても、実機の別の場面で当たるかは、誤差からは分かりません。
- **どう直したか**：学習を倍にしても、手を伸ばす先は変わりませんでした。足りないのは学習の回数ではなく、ブロックの位置が違うお手本だと分かりました。次の手として、5か所19本のお手本を集めることにしています。
- **入れる前に確かめること**
  - 試しの場面に、本番の置き場所のずれやばらつきが入っているか。
  - 判断の材料が「学習の数字」になっていないか。実機で何回中何回できたかで見ているか。
- **出典**：[/record/pi05-mecharm-first-real-run](/record/pi05-mecharm-first-real-run)、[/record/pi05-mecharm-4000-steps](/record/pi05-mecharm-4000-steps)
- 実機で試したのは4回と2回だけです。
- **ハコブくん**：「いつもの場所に手を伸ばすのは、得意です。いつもの場所にないときが、苦手です。」

### 5. 画面の線がないと見つからない　【シミュレーションの録画】
- **現場**：飲食店（配膳ロボット）
- **何が起きたか**：Unity の店を真上から撮った録画を使い、ロボットのまわりを切り出した静止画1枚ずつを画像の異常検知で判定しました。30秒以上の長い止まりを拾えるか試したところ、誤報5%の条件で、画面に道の線があると72%（67/93）、線を消すと28%（26/94）でした。ロボットどうしの詰まりに限ると、23/43 から 4/47 に落ちました。
- **なぜ拾えなかったか**：線があるときに反応していたのは、画面に描かれた道の線が交わる所でした。この線は、実際の店のカメラには映りません。線がないと、向かい合う2台は白い丸が2つ並んでいるだけで、待機場所に2台が並ぶいつもの絵と見分けがつきません。止まりが30秒続くかどうかの見分けは0.51で、偶然と同じでした。
- **次の案**：止まった時間はロボット自身の記録から取り、画像は原因の場所を示すのに使う、という分け方を考えています。
- **入れる前に確かめること**
  - 長い止まりを何で数えるのか（ロボットの記録か、カメラか、店員の報告か）。
  - 試しの期間の止まった回数と時間を、ロボットの記録から出してもらえるか。
- **出典**：[/record/serving-robot-jam-detection-without-path-lines](/record/serving-robot-jam-detection-without-path-lines)
- 実際の店のカメラで測った値ではなく、試した方法も1つだけです。お客さんとのすれ違いは、線がなくても13/17 拾えています。
- **ハコブくん**：「床に線は引いてありません。線がないと、ぼくらはただの白い丸2つです。」

---

## 二　足したら、待ちが延びた

### 6. 2台目が待ちを延ばす　【シミュレーション】
- **現場**：飲食店（28卓・88席、スタッフ2人、昼のピーク2時間）
- **何が起きたか**：入店待ちは、1台のときの13.8分から、2台で25.1分になりました（10種の中央値、ほぼ2倍）。スタッフがロボットを動かしに行く回数は、13回から54回に増えました。
- **なぜ止まったか**：ロボットどうしが1本道で向かい合い、ふさぎ合っていました。下の通路は約1.1m、空いている上の通路は約2.1m ありましたが、2台とも近い方の狭い道を選んでいました。止まった相手は、ロボットが354回、立ち止まった人が159回です。
- **どう直したか**：「1本道は1台ずつ」にすると、入店待ちは17.6分、動かしに行く回数は29.0回に減りました。一方通行にすると、混んでいるときは56.5分で、かえって悪くなりました。どの案でも、この店の2台は1台に届きませんでした。
- **もう一つ分かったこと**：この店では、1台目でも入店待ちは縮みませんでした（0台13.0分、1台13.8分）。1台目で得られたのは、スタッフの歩く距離が約3割減ることでした。通路にゆとりのある別の2店では、2台で待ちが縮んでいます。
- **入れる前に確かめること**
  - いちばん狭い通路の幅はいくつか。ロボットはその通路を選ぶか。
  - 1台目に期待するのは、待ちを縮めることか、スタッフの歩く距離を減らすことか。先に決めているか。
- **出典**：[/record/serving-robot-one-per-narrow-restaurant](/record/serving-robot-one-per-narrow-restaurant)、[/record/small-store-second-robot-wait](/record/small-store-second-robot-wait)
- 1台と2台では Unity の作りの版が少し違い、ログでもきっちりはそろえていないと書いています。
- **ハコブくん**：「2台目が来て、通路で最初に会ったのは、お客さんじゃなくて相方でした。」

### 7. 待機場所の止まり合い　【シミュレーション】
- **現場**：大型の飲食店（70卓・312席、スタッフ6人）
- **何が起きたか**：入店待ちは、0〜3台では11.5〜11.7分、4台で13.2分、5台で17.2分でした。ロボットどうしで止まっていた時間は、2台の67秒から5台の1,163秒に増えました（差がいちばん開いた30分）。
- **なぜ止まったか**：待機点どうしの間は0.8mで、ロボットの前のセンサー（中心から0.85m）が隣の待機点の台に届いていました。戻ってくる台は斜めに寄るので、隣の台がセンサーに入って止まります。道を探した結果を見ると、87〜98%は道が引けていました。道はあるのに、センサーで止まっていたのです。
- **どう直したか**：待機点の真下1.0m から、まっすぐ入る決まりにしました。待機場所のそばの止まり合いは、1回の営業あたり3,317秒から1,255秒に、約6割減りました。人が待機点の区画を通らないようにすると809秒になり、店員が呼ばれる回数は180回から22回に減りました。
- **ただし**：まっすぐ入る決まりだけでは、入店待ちは12.22分から14.90分に延びています。減ったのは止まり合いで、待ちではありません。5台で待ちが延びたことについても、ログは「Unity のロボットに台どうしの順番決めがないことが大きく出た」と書いています。
- **入れる前に確かめること**
  - 待機場所の台どうしの間隔は、センサーが届く距離より広いか。
  - 待機点に戻るときの入り方（向き）を、こちらで決められるか。待機場所の中を人が通るか。
- **出典**：[/record/large-restaurant-five-serving-robots-longer-wait](/record/large-restaurant-five-serving-robots-longer-wait)、[/record/serving-robots-jam-cause-standby-entry](/record/serving-robots-jam-cause-standby-entry)、[/record/serving-robot-jam-three-rules](/record/serving-robot-jam-three-rules)
- **ハコブくん**：「道は見えてるんです。隣の子がセンサーに入るだけで。」

### 8. 下げ膳で詰まる　【シミュレーション】
- **現場**：飲食店（6店、1〜2台、計120回）
- **何が起きたか**：下げ膳もロボットに任せると、スタッフの歩く距離は12の条件すべてで減りました。ところが通路の細い2店では、2台のとき、お客さんが帰ってから卓が使えるまでの時間が延びました（4.05分から6.05分、4.49分から8.06分）。
- **なぜ止まったか**：下げ膳のロボットが卓でスタッフを待つあいだ、通路が1本ふさがります。ほかのロボットとスタッフは、回り道をするか待つしかありません。通路にゆとりのある店では、別の通路を回って行けました。
- **どう直したか**：卓で待つのは2分までにして、待っている台も助けで動かしてよいことにしました。解けずに残った詰まりは53件から4件に減りました。卓が使えるまでの時間が延びる問題そのものは、まだ直していません。
- **入れる前に確かめること**
  - 下げ膳のロボットが卓で待っているあいだ、ふさがる通路の代わりの道はあるか。
  - 卓で待つ時間の上限を決められるか。
- **出典**：[/record/serving-robot-sim-bussing-narrow-aisles](/record/serving-robot-sim-bussing-narrow-aisles)、[/record/serving-robot-bussing-depends-on-aisles](/record/serving-robot-bussing-depends-on-aisles)
- 店ごとの入店待ちの向きは、録画1回ずつで見たもので、ログでも「店ごとの答えを言い切ることはできません」と書いています。
- **ハコブくん**：「お皿を待っているあいだ、ぼくは通路の栓になっています。」

### 9. 直したら問題が増えた　【シミュレーション・仮の病院】
- **現場**：病院（薬剤などの搬送ロボット）
- **何が起きたか**：仮の病院で、行き先へ歩いて行けなかった患者と職員41人が通れるように直しました。すると、ロボットの問題（急に止まった・ひやり・人がよけさせられた など）は、1日84件から132件に増えました。増えた48件のうち37件は大廊下の東の端で起き、相手はほとんどが職員でした。
- **なぜ止まったか**：付き添い用に入れるようにした所へ、職員がふだんの行き来でも行くようになりました。たとえば、検査技師が救急の処置の場所へ行く回数は0回から46回になりました。さらにたどると、Unity の職員141人は「1人が1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動いていました。
- **どう直したか**：職員の行き先を持ち場に限ると、132件が68件になりました。持ち場ごとの4つの型で動かすと19件になり、車いすの患者が動けなかった時間は最長663.8秒から20.3秒に縮みました。その後、患者の動きを足すと51件に増えています。
- **入れる前に確かめること**
  - シミュレーションや試しの結果を見せられたら、まず「人をどう動かしたか」を聞く。
  - ロボットの道を変えたとき、その道を使い始める人はだれか。
- **出典**：[/record/hospital-transport-robot-avoid-outpatient-hall](/record/hospital-transport-robot-avoid-outpatient-hall)、[/record/hospital-transport-robot-blocked-paths-more-conflicts](/record/hospital-transport-robot-blocked-paths-more-conflicts)、[/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)
- 数えたのは衝突ではなく「問題」の件数で、止まりきれなかったのは132件中10件です。比べたのは主に1つの条件で1回ずつで、別の条件では56件から260件とぶれも大きく出ています。
- **ハコブくん**：「ひやりとした相手は、くじ引きで行き先を決める職員さんでした。」

---

## 三　詰まりの元は、ロボットの外にあった

### 10. 線に縛ると詰まる　【シミュレーション】
- **現場**：飲食店（42卓）
- **何が起きたか**：2台を走らせると、60秒止まった回が58回あり、そのうち51回の相手はもう1台のロボットでした。行き止まりで向かい合ったまま、600秒で打ち切りになった回もあります。
- **なぜ止まったか**：Unity のロボットは、渡された道の線の上しか走れない作りでした。42卓への道のうち23本が同じ通路を通っていました。実機は地図の上で道を引いて回り込むので、これは実機にはない縛りです。
- **どう直したか**：まず、地図の上で道を引けるようにしました。ところが60秒の止まりは57回から59回で、減りませんでした。59回のうち43回は、右下の行き止まり（ドリンクバーと6人席の間が0.4m）に集まっていました。そこでドリンクバーを上へ0.5m、左へ0.8m 動かすと、20回になりました。料理の待ちは2.90分から1.17分に縮み、ロボットが運んだ割合は64.4%から99.4%になりました。
- **入れる前に確かめること**
  - 店の中の行き止まりはどこか。家具を数十cm動かせば抜け道ができる所はないか。
  - ロボットが決まった線しか走らないのか、地図の上で回り込めるのか。
- **出典**：[/record/serving-robot-fixed-route-jam](/record/serving-robot-fixed-route-jam)、[/record/serving-robot-map-planner](/record/serving-robot-map-planner)
- 比べたのは、どれも同じ条件で1回ずつです。
- **ハコブくん**：「賢い地図をもらっても、行き止まりはドリンクバーでした。」

### 11. 詰まるのは片付け　【シミュレーション】
- **現場**：飲食店（46卓・スタッフ4人、38卓）
- **何が起きたか**：ロボットを足すと、入店待ちは縮みました（46卓の店で、0台8.1分、1台6.6分、2台5.5分）。それでも、席は空いているのに待たせた時間が残りました。46卓の店では0台6.5分・1台4.6分・2台3.4分で、計算で見込んだ1.5分・0.8分・0.7分の何倍もあります。
- **なぜ止まったか**：計算では、食べ終えたお客さんがレジを待つあいだ卓に座ったままなので、レジが詰まるはずでした。ところが3Dの店でスタッフを歩かせてみると、歩き回るぶん手がふさがり、後回しにした片付けがたまっていました。
- **入れる前に確かめること**
  - 待ちの元は、運ぶことか、片付けと案内か。
  - 入れる前の今、「席は空いているのに待たせている時間」を測ったことがあるか。
- **出典**：[/record/large-store-cleanup-bottleneck](/record/large-store-cleanup-bottleneck)、[/record/standby-jam-every-store](/record/standby-jam-every-store)
- **ハコブくん**：「ぼくをもう1台呼ぶ前に、片付けの手を見てください。」

### 12. まさかの電源不足　【実機】
- **現場**：ロボットアーム（mechArm 270）
- **何が起きたか**：ある位置のブロックを、9回中2回しか運べませんでした。その2回も人が手を貸しています。つかんでから11〜19秒で爪の電流が0近くまで落ち、ブロックを落としていました（17本中12本）。
- **なぜ止まったか**：本体が求める電源は40W（説明書では8.4V・5A）です。つないでいたのは外付けディスク用の12V・2A（24W）で、求める量の6割しかありませんでした。箱にアダプターが入っておらず、あとから別送されたもので、8か月分の実機の記録はすべてこの電源で取っていました。
- **どう直したか**：12V・5A のアダプター（3,355円）に替えました。同じ条件で比べると、成功は3回中1回から5回中5回に、人の手直しは3回中3回から5回中1回に減りました。教えた動きの再生も7回すべて成功しました。
- **入れる前に確かめること**
  - 電源やアダプターは、説明書の仕様どおりか。付属のものか。
  - うまくいかないとき、AI や設定を疑う前に、電源と部品を確かめる順番になっているか。
- **出典**：[/record/mecharm-270-drops-block-underpowered-adapter](/record/mecharm-270-drops-block-underpowered-adapter)、[/record/mecharm-270-5a-adapter-stops-dropping-block](/record/mecharm-270-5a-adapter-stops-dropping-block)
- 比べたのは3回と5回で、日も違います。5A にしたあとも、持ち上げた瞬間に電流が落ちた回が1回ありました（ブロックは落ちていません）。
- **ハコブくん**：「やる気はあったんです。電気が足りなかっただけで。」

---

参考：止まり方を「見る・位置を知る・決める・動く」の4段で分けた考察もあります（ログ自身が、各機体の中身は公開されておらず見立てだと断っています）。→ [/record/serving-robot-stops-four-stages-stanford](/record/serving-robot-stops-four-stages-stanford)

---

## 終わりに：入れる前に、自分の現場で

**1. 試しの期間に、この5つを測る**
- 止まってから人が来るまでの秒数と、直すのにかかった秒数（1・2）
- 長い止まりの回数と時間。ロボットの記録から出してもらう（5）
- 記録の「成功」が、動画で見ても成功だったか（3・4）
- 席は空いているのに待たせている時間。入れる前と後で比べる（11）
- 電源・部品が仕様どおりか（12）

**2. 図面の上で、この3か所を見る**
- すれ違えない幅の通路と、行き止まり（2・6・10）
- 待機場所の台どうしの間隔と、戻ってくる向き（7）
- 下げ膳で卓に止まったとき、代わりに通れる道（8）

**3. 台数を足す前に、詰まりの元を聞く**
2台目を入れる前、道を直す前、学習を増やす前に、「いま何が止めているのか」を測ってください（6・7・9・4）。

シミュレーションで店や病院をどう再現したかは、【シミュレーションのページ】にまとめています。

自分の現場でも同じ止まり方が起きるか確かめたい方は、[/message](/message) に1行ください。

---

### エイイチへのメモ（作者として決めたこと）

- **並べ方**：見つけた場所ではなく、経営者・PM が抱く問いの順に、3つの章に分けました。「止まったことが届かない」→「足したら延びた」→「元はロボットの外」の順です。1番目は、根拠がいちばん強い実店舗の動画の「直すのは数秒、来るまで数十秒」にしました。そのため依頼の表の番号とは、ページ上の番号が違います（例：表の#11 → ページの3、表の#10 → ページの12）。
- **名前と数字を変えた所**：照合の結果、そのままでは言い過ぎになる所を直しました。
  - 「直したら衝突が増えた」→「問題が増えた」（数えたのは衝突ではないため）
  - 「カメラでは見つからない」→「画面の線がないと見つからない」
  - 線に縛る項目：「57回→20回」を、「地図だけでは59回、ドリンクバーを動かして20回」に分けました
  - 待機場所の項目：「待ちが減った」ではなく「止まり合いが減った」とし、入店待ちが延びたことも書きました
  - 命令が捨てられる項目：「約88°」ではなく、確かめた95.53〜99.22°で書きました
- **数字の確認**：このフォルダに `材料/` が見当たらず、ログ本文は読めていません。数字はすべて、ログを読む人の材料と codex の照合（ログ本文の見出しと突き合わせ済み）から取っています。
- **外の文脈**：Gemini の出典はほとんどが未確認か、検索の転送 URL でした。そのため、ページに入れたのは販売サイトの導入前の確認の1文（dfarobotics.com、2026年4月29日）だけです。この記事の完全な URL は材料になかったので、載せる前に確かめてください。
- **要確認の所**
  - シミュレーションのページの URL がわからないので、【シミュレーションのページ】と仮に置いています
  - ハコブくんの一人称は「ぼく」にしました。キャラクターの決まりと違えば、直してください
```


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

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

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

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

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

冒頭の3行の差し替え案です。

> 配膳ロボット・病院の搬送ロボット・ロボットアームの、12の止まり方を集めました。  
> 実店舗の動画では、直す作業が約1〜10秒でも、店員が来るまで約18秒、41秒以上、45秒以上かかった例がありました。ほかに、シミュレーションと実機の記録を載せています。  
> 止まった回数だけでなく、人を待つ時間、席を使えるまでの時間、実機で成功した回数まで。入れる前に何を確かめるかを、項目ごとに持ち帰れます。

また、「足せば良くなるが5回外れた」は、独立した検証を5回行ったようにも読めます。次に替える方が正確です。

> 台数・機能・学習量を増やしても、狙った指標が改善しなかった記録があります。何を改善したいのかを決め、その数字で前後を比べる必要があります。

### 2. いちばん刺さるのは「店員が来るまで」。通知が原因という断定を外す

**数秒の作業より、人を待つ時間の方が長い。** この発見は、経営者が人員配置や導入試験の見方を変える材料になります。先頭に置く判断に賛成です。

ただし、「来なかったのは、お客さん向けの合図だったから」は、動画から確かめられた因果ではありません。ハコブくんも同じ断定をしています。

差し替え案です。

> **なぜ止まったか**：向かい合いや出口のふさがりで進めなくなっていました。店員が来るまでに時間がかかった理由は、動画だけでは確かめられません。声と赤い明かりは確認できましたが、店員の端末へ通知が届いたかは分かりません。  
> **ハコブくん**：「直すのは約5秒。店員さんを待つのは41秒以上でした。」

なお、53秒以上の4本目を残すなら、出典に現在の項目2にもある `/record/serving-robot-jams-are-aisles` を加えてください。

### 3. 「にらみ合い」は、公開情報の不足より「譲った先でもふさぐ」を原因にする

「メーカーが決まりを公開していない」は、止まった原因ではありません。仕様幅の列挙も、読者が自分の機種の説明書を確認すれば得られる情報です。

ここで価値があるのは、**譲る台を決めるだけでは足りず、退避先まで必要だった**というシミュレーションの中身です。

差し替え案です。

> **なぜ止まったか**：実店舗の機体が抜けられなかった内部原因は、動画では分かりません。Unityでは、2台とも料理を載せている場合などに譲る台を決められず、よけた先も相手の道の上になっていました。  
> **入れる前に確かめること**：狭い所で2台が向かい合ったとき、どちらが、どこまで下がれば通れるか。退避先がふさがっている場合も、試しの期間に確認できるか。  
> **ハコブくん**：「譲った先も、相手の通り道でした。」

「助け2回・約105秒」には、「この条件の1回の試行では」を添えてください。復旧時間の保証には使えません。

### 4. いちばん弱いのは「画面の線がないと見つからない」。監視の性能を確かめる項目に直す

現在は画像検知の実験説明が長く、読者が導入判断にどう使うかが薄い項目です。しかも線なしでも28%拾えているため、名前の「見つからない」は言い過ぎです。

**「止まりを見つけた数字が、本番にも存在する手がかりで出た数字か」**という問いにすると、この実験固有の価値が出ます。

差し替え案です。

> **名前**：画面の線を拾っていた  
> **何が起きたか**：Unity録画の静止画1枚で30秒以上の停止を検出する試験では、誤報5%の条件で、経路線ありは72%、線なしは28%を拾いました。撮り直しで動きも変わっているため、同一場面から線だけを消した比較ではありません。  
> **入れる前に確かめること**：監視の実演で拾えた停止と見逃した停止を、本番と同じ表示条件で確認できるか。実際には映らない線や印を、判定の手がかりにしていないか。

指標名の説明がない「0.51」は削ってよいです。72%と28%、見逃しの実例で判断材料は足ります。

### 5. 「2台目」と「下げ膳」は、良くなった数字と悪くなった数字を並べる

この2項目は、「増やすと詰まる」という教訓だけでは惜しいです。**負担軽減と客待ち短縮が、同じ結果にならなかった**ことが経営判断に効きます。

項目6の中心文は、次に替えてください。

> Unityの28卓・スタッフ2人の店では、1台でスタッフの歩行距離は約3割減りました。一方、入店待ちは0台13.0分、1台13.8分。2台では25.1分となり、1台の約1.8倍でした。ただし、1台と2台の比較には版の違いが残ります。

項目8も、比較の条件を本文に入れます。

> 6店・台数2条件・各10種の計120回では、下げ膳を加えると歩行距離は全12条件で減りました。一方、細い通路の2店では、2台運用時の退店から卓が使えるまでの時間が、各10種の中央値で4.05→6.05分、4.49→8.06分に延びました。

問いも一つ強められます。

> 歩行距離が減っても、客待ちが延びた場合、この導入を採用するか。何を優先するかを試験前に決めているか。

### 6. 「待機場所」は、止まり合いが減っても入店待ちが延びた事実を主役にする

項目7は、注意書きに置かれた数字の方が重要です。改善が店全体に効いたかを確かめる、案Aの中心例にできます。

差し替え案です。

> **何が起きたか**：Unityの大型店で、待機点へまっすぐ入る変更をすると、待機場所付近の詰まりは3,317秒から1,255秒に減りました。ところが同じ比較で、入店待ちは12.22分から14.90分に延びました。止まり合いの改善だけでは、店全体の待ちの改善を確認できませんでした。  
> **入れる前に確かめること**：止まり合いが減ったとき、入店待ちや卓が使えるまでの時間も改善したか。同じ条件で両方を比べられるか。

0.8mと0.85mは「このシミュレーションの設定」と明記してください。実機一般の待機間隔を決める数字にはできません。

### 7. 「なぜ止まったか」で、見立てを確定原因にしない

主に次の3か所です。原因を弱めるのでなく、**どこまで確かめ、何が未検証かを示す**と、検証相手としての信頼が増します。

- **項目4・学習**  
  「足りないのは位置が違うお手本だと分かりました」は先走っています。  
  > お手本の位置の偏りが原因ではないかと見立て、位置を変えたお手本を集める方針にしました。その学習し直しで改善したかは、今回の材料では確かめていません。

- **項目11・片付け**  
  46卓・38卓の原因は、ログでも他店の観察からの見立てです。  
  > 片付けと案内が追いつかない時間が残りました。ログでは、スタッフが歩くぶん作業が後回しになることが関わると見ています。

- **項目12・電源**  
  「同じ条件」だけでは、日が違うことと人の補助を見落とします。  
  > 同じモデル・位置・閉じる設定で、別日に電源交換の前後を比べました。成功は1/3回から5/5回となりましたが、交換後も1回は人が持ち上げを補助しました。電圧低下を直接測った記録はありません。

### 8. 終わりは、チェック項目の再掲から「自分の現場の比較の作り方」へ進める

現在の締めは項目数が多く、「全部確認する」で止まりがちです。持ち帰って使えるように、記録方法を一段具体化してください。

差し替え案です。

> **自分の現場では、まず改善したい数字を一つ決めてください。** 入店待ちを縮めたいのか、卓を早く使えるようにしたいのか、人の歩行や復旧作業を減らしたいのか。  
> 試しの期間には、止まった場所、止まった時刻、人が来た時刻、復旧した時刻を分けて残します。台数や運用を変える前後で、最初に決めた数字も比べてください。  
> これは、この図鑑の記録から提案する確かめ方です。停止が減ったことと、導入の目的を達成したことを、両方確認するために使ってください。

案Aの切り口を最も強くするのは、**「止まる場所を知った」で終わらず、「自分の導入試験では、この数字を分けて取る」と決められるページにすること**です。
```


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

```markdown
案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回目）

```markdown
【採否】

**評者（案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 は数字を消し、「偶然と同じくらいしか見分けられない」と言葉で書きました。
5. 2台目と下げ膳で、良くなった数字と悪くなった数字を並べる：**採る**。「ほぼ2倍」は約1.8倍に直しました（13.8→25.1分）。下げ膳には「各10種の中央値」の条件を本文に入れました。
6. 待機場所は「止まり合いは減ったのに入店待ちは延びた」を主役にする：**採る**。0.8m と 0.85m はシミュレーションの設定だと書きました。条件の違う比べ方で「近くの店員がすぐ押すと待ちが縮んだ」ことも足し、項目1とつなげています。
7. 見立てを、確かめた原因として書かない（学習・片付け・電源）：**採る**。3か所とも、何を確かめて何がまだかを書き分けました。
8. 終わりを「自分の現場での比べ方」にする：**採る**。最初に「良くしたい数字を1つ決める」を置き、時刻を分けて残す4つの項目を書きました。

**評者（案Cの作者）から**
- いちばん刺さるのは「店員が来るまで」：**採る**。これまでどおり先頭に置き、冒頭の3行にも上げました。
- いちばん弱いのは下げ膳：**採る**。指摘2で直しました。
1. 販売サイトとの対比を強くする：**採らない**。書き換え案の「幅や段差ではなく」は、事実と合いません。通路の幅は2・6・8の原因そのものです。出典も確かめられていないので、外の文脈の1文ごと削りました。
2. 下げ膳を「歩く距離か、席を早く使えることか」の選択として問う：**採る**。
3. にらみ合いの問いを「だれが何秒で、手でどかすか」にする：**採る**。案Bの「どこまで下がれば通れるか」と1つにまとめました。
4. 「映像の異常検知では7割を拾えない」：**一部採る**。「7割を見逃した」という数字は採ります。「映像の異常検知では」は、シミュレーションの録画で1つの方法を試しただけなので言い過ぎです。見出しは「線を消すと、長い止まりの7割を見逃した」にしました。
5. 「席は空いているのに待たせる」を見出しにする：**採る**。ロボットを足すと入店待ちは縮んだ、という事実も本文の先頭に置きました。
6. 締めをログの数字で終える：**一部採る**。数字で締める形は採り、案Bの指摘8と1つにまとめました。「5回外れた」は、1′で直した言い方にしています。

---

【企画書】

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

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

---

## 先に、12を並べて分かったこと

- **直せた止まりは、どれもロボットの性能を上げて直したのではありませんでした。** 直し方は次のとおりです。
  - 1本道は1台ずつ通す
  - 待機点への入り方を変える
  - ドリンクバーを動かして行き止まりをなくす
  - 職員の動かし方を変える
  - 電源を仕様に合わせる
  - 教え方を変える
- **止まったことが、そのままでは数字にも画面にも出てこない止まり方があります。**
  - 直すのは数秒なのに、店員が来るまでは数十秒かかる
  - できない命令がエラーなしに捨てられ、記録の上では「成功」になる
  - 学習の誤差は下がるのに、実機では外れる
  - 画面の線を消すと、長い止まりの7割を見逃す
- **足しても、狙った数字が良くならなかった記録が5つあります。** 2台目、5台目、賢い道の引き方、通れる所を増やす、学習を倍にする、の5つです。何を良くしたいのかを先に決め、その数字で前と後を比べないと、足したことが効いたかどうかは分かりません。

各項目の印の意味は次のとおりです。
- 【実店舗の動画】SNS に上がった実際の店の動画を、コマ送りで読んだもの
- 【シミュレーション】Unity で再現した店・病院で回したもの。実店舗で必ず起きるという意味ではありません
- 【実機】手元の mechArm 270 で試したもの

---

## 一　止まったことに、すぐには気づけない

### 1. 店員が来るまで　【実店舗の動画】
- **現場**：飲食店（配膳ロボット）
- **何が起きたか**：店員が直した3本の動画では、直す作業は約5秒、1〜2秒、約10秒でした。それに対して、店員が来るまでは41秒以上、45秒以上、約18秒かかっていました。あとで見た4本目では、来るまでに53秒以上かかっています。
- **なぜ止まったか**：進めなくなった直接の原因は、1台分の幅で2台が向かい合ったことと、隣の台に出口をふさがれたことです。店員が来るまでに時間がかかった理由は、動画だけでは確かめられません。映っていたのはロボットの声かけと赤い明かりで、店員の手元に知らせが届いた様子は、どの動画にも映っていませんでした。知らせる機能があるかどうかは確かめていません。
- **入れる前に確かめること**
  - 止まったとき、店員の手元（端末・インカム）に知らせが届くか。それとも光と声だけか。
  - 試しの期間に、「止まってから人が来るまで」と「直すのにかかった時間」を分けて測っているか。
- **出典**：[/record/serving-robot-video-ledger](/record/serving-robot-video-ledger)、[/record/serving-robot-jams-are-aisles](/record/serving-robot-jams-are-aisles)
- 動画は編集されているので、秒数は下限です。
- **ハコブくん**：「赤く光って、声も出しています。そのあと、41秒待ちます。」

### 2. にらみ合い　【実店舗の動画】【シミュレーション】
- **現場**：飲食店（配膳ロボット）
- **何が起きたか**
  - 実店舗の動画：和食の店で、待機場所の横の2台が向かい合いました。2台ともその場で向きを変え続け、53秒以上進めませんでした。店員が空の方を手で寄せると、約4〜5秒で解けました。
  - シミュレーション：42卓・通路95cm の店で、2台が約9分10秒止まりました。そのあいだスタッフは、同じ卓へ運ぶのを5回あきらめています。
- **なぜ止まったか**：実店舗の機体が抜けられなかった中の原因は、動画からは分かりません。シミュレーションでは、2台とも料理を載せているとき（または2台とも空のとき）、どちらが譲るかを決められませんでした。しかも、よけた先が相手の通り道の上でした。
- **調べて分かったこと**：どちらが譲るかの決まりは、調べた範囲では、どのメーカーも公式には公開していませんでした。取扱説明書で分かったのは次の2つだけです。
  - すれ違えない幅では交互に通すこと。すれ違いに要る幅は、PUDU が1.6m超、KEENON T8 が1.5m超
  - しばらく待ってから道を組み直すこと。BellaBot Pro の初期値は30秒
- **シミュレーションで試した直し方**：「30秒動けなければ近くの店員が来て、着いてから15秒で空の方を動かす」という決まりを足しました。この条件の1回の試しでは、約9分の止まりが、助け2回・約105秒で解けました。ただし、同じ台に何度も助けが要るという新しい詰まりも出ています。
- **入れる前に確かめること**
  - すれ違えない幅で2台が向かい合ったら、だれが、何秒以内に、手でどかしに行くか。その担当と手順を決めているか。
  - どちらが、どこまで下がれば通れるか。下がる先がふさがっている場面も、試しの期間に見たか。
- **出典**：[/record/serving-robot-faceoff-staff-resolves](/record/serving-robot-faceoff-staff-resolves)、[/record/serving-robot-jams-are-aisles](/record/serving-robot-jams-are-aisles)
- 集めた実店舗の動画4本は、すべて同じメーカーの機体です。見た動画の中に、ロボットどうしで解けた場面はありませんでした。
- **ハコブくん**：「よけたつもりの場所が、相手の通り道でした。」

### 3. 命令が黙って捨てられる　【実機】
- **現場**：ロボットアーム（mechArm 270）
- **何が起きたか**：手で教えた動きを再生すると、つかむ位置へ降りる命令を6回送って、6回とも動きませんでした。エラーは出ず、動いた角度は最大1.50°で、止まっているときの揺れと変わりません。しかも、動いていない2本が、記録の上では「つかめた・箱に入った」になっていました。
- **なぜ止まったか**
  - 教えた肩の角度は95.53〜99.22°でした。メーカー公式の肩の範囲は−85°〜+90°です。
  - 送る側のライブラリは±190°でしか確かめないので、範囲の外の命令もそのまま送られ、アーム側で黙って捨てられていました。
  - 手で教えるときはモーターの力が抜けているので、人は範囲の外まで倒せてしまいます。
- **どう直したか**：肩を倒さず、肘と手首で下げるように教え直しました（肩87.27°）。5回再生して、5回とも成功しました。再生の前に肩の角度を確かめる手順も足しました。
- **入れる前に確かめること**
  - 動ける範囲の外の命令を送ったとき、エラーが返るか。それとも黙って止まるか。
  - 試しの記録の「成功」は、だれが何を見て付けているか。動画と照らし合わせているか。
- **出典**：[/record/teach-replay-19-demos](/record/teach-replay-19-demos)
- 捨てられたと確かめたのは、肩95.53°以上の命令だけです。
- **ハコブくん**：「できない命令は、聞かなかったことにします。『できません』と言う口がないので。」

### 4. 学習の数字は良いのに外れる　【実機】
- **現場**：ロボットアーム（mechArm 270、AI モデル π0.5）
- **何が起きたか**
  - 2,000ステップ：学習の誤差（loss）は0.1155から0.0057まで下がりました。ところが実機では4回とも、爪がブロックの上に乗り、つかむ前に止まりました。
  - 学習を倍の4,050ステップにすると、誤差は0.0030まで下がりました。それでも実機では2回とも、ブロックの奥の何もない所で爪を閉じました。
  - つかむ瞬間の土台と肩の角度は、3回ともほぼ同じでした。どれも、お手本の範囲の外でした。
- **なぜ止まったか（見立て）**：お手本19本は、ブロックをほぼ同じ場所に置いて集めたものでした。それなら、画像を細かく見なくても「いつもの場所へ手を伸ばす」だけで誤差は下がります。お手本と同じ場面で当たっても、実機の別の場面で当たるかどうかは、誤差からは分かりません。
- **どうしたか**：学習を倍にしても、手を伸ばす先は変わりませんでした。そこで、お手本の置き場所の偏りが原因ではないかと見立て、5か所で19本のお手本を集める方針にしました。それで学習し直して良くなったかは、ここに載せた記録ではまだ確かめていません。
- **入れる前に確かめること**
  - 試しの場面に、本番の置き場所のずれやばらつきが入っているか。
  - 判断の材料が「学習の数字」になっていないか。実機で何回中何回できたかで見ているか。
- **出典**：[/record/pi05-mecharm-first-real-run](/record/pi05-mecharm-first-real-run)、[/record/pi05-mecharm-4000-steps](/record/pi05-mecharm-4000-steps)
- 実機で試したのは4回と2回だけです。
- **ハコブくん**：「いつもの場所に手を伸ばすのは、得意です。いつもの場所にないときが、苦手です。」

### 5. 線を消すと、長い止まりの7割を見逃した　【シミュレーションの録画】
- **現場**：飲食店（配膳ロボット）
- **何が起きたか**：Unity の店を真上から撮った録画で試しました。ロボットのまわりを切り出した静止画1枚ずつを、画像の異常検知で判定し、30秒以上の長い止まりを拾えるかを見ました。誤報5%の条件で、拾えた割合は次のとおりです。
  - 画面に道の線がある：72%（67/93）
  - 線を消す：28%（26/94）
  - ロボットどうしの詰まりに限る：23/43 から 4/47 に落ちた
- **なぜ拾えなかったか**：線があるときに反応していたのは、画面に描かれた道の線が交わる所でした。この線は、実際の店のカメラには映りません。線がないと、向かい合う2台は白い丸が2つ並んでいるだけで、待機場所に2台が並ぶいつもの絵と見分けがつきません。止まりが30秒続くかどうかも、偶然と同じくらいしか見分けられませんでした。
- **次の案**：止まった時間はロボット自身の記録から取り、画像は原因の場所を示すのに使う、という分け方を考えています。
- **入れる前に確かめること**
  - 監視の仕組みを見せてもらうとき、拾えた止まりと見逃した止まりを、本番と同じ映り方で確かめられるか。本番には映らない線や印を、手がかりにしていないか。
  - 長い止まりの回数と時間を、ロボット自身の記録から出してもらえるか。
- **出典**：[/record/serving-robot-jam-detection-without-path-lines](/record/serving-robot-jam-detection-without-path-lines)
- 実際の店のカメラで測った値ではなく、試した方法も1つだけです。撮り直したのでロボットの動きも変わっていて、同じ場面から線だけを消した比較ではありません。お客さんとのすれ違いは、線がなくても13/17 拾えています。
- **ハコブくん**：「床に線は引いてありません。線がないと、ぼくらはただの白い丸2つです。」

---

## 二　足しても、狙った数字は良くならなかった

### 6. 2台目が待ちを延ばす　【シミュレーション】
- **現場**：飲食店（28卓・88席、スタッフ2人、昼のピーク2時間）
- **何が起きたか**
  - 良くなった数字：1台入れると、スタッフの歩く距離は約3割減りました。
  - 良くならなかった数字：入店待ちは0台13.0分、1台13.8分でした。2台にすると25.1分になり、1台の約1.8倍です（10種の中央値）。
  - スタッフがロボットを動かしに行く回数は、13回から54回に増えました。
- **なぜ止まったか**：ロボットどうしが1本道で向かい合い、ふさぎ合っていました。下の通路は約1.1m、空いている上の通路は約2.1m ありましたが、2台とも近い方の狭い道を選んでいました。止まった相手は、ロボットが354回、立ち止まった人が159回です。
- **どう直したか**
  - 「1本道は1台ずつ」にすると、入店待ちは17.6分、動かしに行く回数は約29回に減りました。
  - 一方通行にすると、混んでいるときは56.5分で、かえって悪くなりました。
  - どの案でも、この店の2台は1台に届きませんでした。なお、通路にゆとりのある別の2店では、2台で待ちが縮んでいます。
- **入れる前に確かめること**
  - 1台目に期待するのは、入店待ちを縮めることか、スタッフの歩く距離を減らすことか。先に決めているか。
  - いちばん狭い通路の幅はいくつか。ロボットはその通路を選ぶか。
- **出典**：[/record/serving-robot-one-per-narrow-restaurant](/record/serving-robot-one-per-narrow-restaurant)、[/record/small-store-second-robot-wait](/record/small-store-second-robot-wait)
- 1台と2台では Unity の作りの版が少し違い、ログにも「きっちりはそろえていない」と書いてあります。
- **ハコブくん**：「2台目が来て、通路で最初に会ったのは、お客さんじゃなくて相方でした。」

### 7. 待機場所の止まり合い　【シミュレーション】
- **現場**：大型の飲食店（70卓・312席、スタッフ6人）
- **何が起きたか**
  - 待機点へまっすぐ入る決まりに変えると、待機場所のそばの止まり合いは、1回の営業あたり3,317秒から1,255秒に、約6割減りました。
  - ところが同じ比較で、入店待ちは12.22分から14.90分に延びました。止まり合いが減っても、店全体の待ちは縮んでいません。
- **なぜ止まり合ったか**：このシミュレーションの設定では、待機点どうしの間は0.8m で、ロボットの前のセンサー（中心から0.85m）が隣の待機点の台に届いていました。戻ってくる台は斜めに寄るので、隣の台がセンサーに入って止まります。道を探した結果の87〜98%では、道は引けていました。道はあるのに、センサーで止まっていたのです。
- **台数を増やしたとき**：入店待ちは、0〜3台では11.5〜11.7分、4台で13.2分、5台で17.2分でした。ロボットどうしで止まっていた時間は、2台の67秒から5台の1,163秒に増えています（差がいちばん開いた30分）。ただしログは、5台で待ちが延びたのは「Unity のロボットに台どうしの順番決めがないことが大きく出た」と書いています。
- **ほかに試したこと**
  - 人が待機点の区画を通らないようにすると、止まり合いは809秒、店員が呼ばれる回数は180回から22回、入店待ちは13.24分になりました。
  - 条件の違う別の比較では、止まった台を近くの店員がすぐ押す決まりで、入店待ちが17.56分から11.32分に縮んでいます。
- **入れる前に確かめること**
  - 止まり合いが減ったとき、入店待ちや卓が使えるまでの時間も良くなったか。同じ条件で両方を比べられるか。
  - 待機場所の台どうしの間隔と、戻ってくるときの向きを、こちらで決められるか。待機場所の中を人が通るか。
- **出典**：[/record/large-restaurant-five-serving-robots-longer-wait](/record/large-restaurant-five-serving-robots-longer-wait)、[/record/serving-robots-jam-cause-standby-entry](/record/serving-robots-jam-cause-standby-entry)、[/record/serving-robot-jam-three-rules](/record/serving-robot-jam-three-rules)
- 0.8m と 0.85m はこのシミュレーションの設定で、実機の待機間隔の目安ではありません。
- **ハコブくん**：「道は見えてるんです。隣の子がセンサーに入るだけで。」

### 8. 下げ膳で詰まる　【シミュレーション】
- **現場**：飲食店（6店、1〜2台、各10種で計120回）
- **何が起きたか**
  - 良くなった数字：下げ膳もロボットに任せると、スタッフの歩く距離は12の条件すべてで減りました。
  - 悪くなった数字：通路の細い2店で2台のとき、お客さんが帰ってから卓が使えるまでの時間が延びました。各10種の中央値で、4.05分から6.05分、4.49分から8.06分です。
- **なぜ止まったか**：下げ膳のロボットが卓でスタッフを待つあいだ、通路が1本ふさがります。ほかのロボットとスタッフは、回り道をするか待つしかありません。通路にゆとりのある店では、別の通路を回って行けました。
- **どう直したか**：卓で待つのは2分までにし、待っている台も助けで動かしてよいことにしました。解けずに残った詰まりは53件から4件に減りました。卓が使えるまでの時間が延びる問題そのものは、まだ直していません。
- **入れる前に確かめること**
  - スタッフの歩く距離が減っても、次のお客さんを案内できるまでの時間が延びたら、その使い方を採るか。どちらを優先するか、試しの前に決めているか。
  - 下げ膳のロボットが卓で待っているあいだ、スタッフとほかのロボットが回り道できる通路があるか。
- **出典**：[/record/serving-robot-sim-bussing-narrow-aisles](/record/serving-robot-sim-bussing-narrow-aisles)、[/record/serving-robot-bussing-depends-on-aisles](/record/serving-robot-bussing-depends-on-aisles)
- 店ごとの入店待ちが縮んだか延びたかは、録画1回ずつで見たものです。ログにも「店ごとの答えを言い切ることはできません」と書いてあります。
- **ハコブくん**：「お皿を待っているあいだ、ぼくは通路の栓になっています。」

### 9. 直したら問題が増えた　【シミュレーション・仮の病院】
- **現場**：病院（薬剤などの搬送ロボット）
- **何が起きたか**：仮の病院で、行き先へ歩いて行けなかった患者と職員41人が通れるように直しました。すると、ロボットの問題（急に止まった・ひやりとした・人がよけさせられた など）が、1日84件から132件に増えました。増えた48件のうち37件は大廊下の東の端で起き、相手はほとんどが職員でした。
- **なぜ止まったか**
  - 付き添い用に入れるようにした所へ、職員がふだんの行き来でも行くようになりました。たとえば、検査技師が救急の処置の場所へ行く回数は0回から46回になりました。
  - さらにたどると、Unity の職員141人は「1人が1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動いていました。
- **どう直したか**
  - 職員の行き先を持ち場に限ると、132件が68件になりました。
  - 持ち場ごとの4つの型で動かすと19件になり、車いすの患者が動けなかった時間は最長663.8秒から20.3秒に縮みました。
  - その後、患者の動きを足すと51件に増えています。条件のそろった数として、ログは51件の方を挙げています。
- **入れる前に確かめること**
  - シミュレーションや試しの結果を見せられたら、まず「人をどう動かしたか」を聞く。
  - ロボットの道を変えたとき、その道を使い始める人はだれか。
- **出典**：[/record/hospital-transport-robot-avoid-outpatient-hall](/record/hospital-transport-robot-avoid-outpatient-hall)、[/record/hospital-transport-robot-blocked-paths-more-conflicts](/record/hospital-transport-robot-blocked-paths-more-conflicts)、[/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)
- 数えたのは衝突ではなく「問題」の件数で、止まりきれなかったのは132件中10件です。比べたのは主に1つの条件で1回ずつで、別の条件では56件から260件と、ぶれも大きく出ています。
- **ハコブくん**：「ひやりとした相手は、くじ引きで行き先を決める、仮の職員さんでした。」

---

## 三　詰まりの元は、ロボットの外にあった

### 10. 線に縛ると詰まる　【シミュレーション】
- **現場**：飲食店（42卓）
- **何が起きたか**：2台を走らせると、60秒止まった回が58回あり、そのうち51回の相手はもう1台のロボットでした。行き止まりで向かい合ったまま、600秒で打ち切りになった回もあります。
- **なぜ止まったか**：Unity のロボットは、渡された道の線の上しか走れない作りでした。42卓への道のうち23本が、同じ通路を通っていました。実機は地図の上で道を引いて回り込むので、これは実機にはない縛りです。
- **どう直したか**
  - まず、地図の上で道を引けるようにしました。ところが60秒の止まりは57回から59回で、減りませんでした。59回のうち43回は、右下の行き止まり（ドリンクバーと6人席の間が0.4m）に集まっていました。
  - そこでドリンクバーを上へ0.5m、左へ0.8m 動かすと、20回になりました。料理の待ちは2.90分から1.17分に縮み、ロボットが運んだ割合は64.4%から99.4%になりました。
- **入れる前に確かめること**
  - 店の中の行き止まりはどこか。家具を数十cm 動かせば抜け道ができる所はないか。
  - ロボットは決まった線しか走らないのか、地図の上で回り込めるのか。
- **出典**：[/record/serving-robot-fixed-route-jam](/record/serving-robot-fixed-route-jam)、[/record/serving-robot-map-planner](/record/serving-robot-map-planner)
- 比べたのは、どれも同じ条件で1回ずつです。
- **ハコブくん**：「賢い地図をもらっても、行き止まりはドリンクバーでした。」

### 11. 席は空いているのに、待たせる　【シミュレーション】
- **現場**：飲食店（46卓・スタッフ4人、38卓）
- **何が起きたか**：ロボットを足すと、入店待ちは縮みました（46卓の店で、0台8.1分、1台6.6分、2台5.5分）。それでも、席は空いているのにお客さんを待たせた時間が残りました。46卓の店では0台6.5分・1台4.6分・2台3.4分で、計算で見込んだ1.5分・0.8分・0.7分の何倍もあります。38卓の店でも、計算の2.0〜5.5倍でした。
- **なぜ待たせたか**
  - 計算では、食べ終えたお客さんがレジを待つあいだ卓に座ったままなので、レジが詰まるはずでした。
  - ところが3Dの店でスタッフを歩かせると、片付けと案内が追いつかない時間が残りました。
  - 別の2店では、スタッフが歩き回るぶん1組あたりの仕事が計算より約1割長く、片付けが後回しになっていました。46卓・38卓の店でも同じことが起きていると、ログは見ています。
- **入れる前に確かめること**
  - ロボットを入れる前の今、「席は空いているのに待たせている時間」を測ったことがあるか。
  - 待ちの元は、運ぶことか、レジか、それとも片付けと案内か。
- **出典**：[/record/large-store-cleanup-bottleneck](/record/large-store-cleanup-bottleneck)、[/record/standby-jam-every-store](/record/standby-jam-every-store)
- **ハコブくん**：「ぼくをもう1台呼ぶ前に、片付けの手を見てください。」

### 12. まさかの電源不足　【実機】
- **現場**：ロボットアーム（mechArm 270）
- **何が起きたか**：ある位置のブロックを、9回中2回しか運べませんでした。その2回も、人が手を貸しています。つかんでから11〜19秒で爪の電流が0近くまで落ち、ブロックを落としていました（17本中12本）。
- **なぜ止まったか**：本体が求める電源は40W（説明書では8.4V・5A）です。つないでいたのは外付けディスク用の12V・2A（24W）で、求める量の6割しかありませんでした。このアダプターは箱に入っておらず、あとから別に送られてきたものです。8か月分の実機の記録は、すべてこの電源で取っていました。
- **どう直したか**：12V・5A のアダプター（3,355円）に替えました。同じモデル・同じ位置・同じ閉じる設定で、日を変えて替える前と後を比べました。
  - 成功：3回中1回 → 5回中5回
  - 人の手直し：3回中3回 → 5回中1回（持ち上げを人が手伝った）
  - 教えた動きの再生：7回すべて成功
- **入れる前に確かめること**
  - 電源やアダプターは、説明書の仕様どおりか。付属のものか。
  - うまくいかないとき、AI や設定を疑う前に、電源と部品を確かめる順番になっているか。
- **出典**：[/record/mecharm-270-drops-block-underpowered-adapter](/record/mecharm-270-drops-block-underpowered-adapter)、[/record/mecharm-270-5a-adapter-stops-dropping-block](/record/mecharm-270-5a-adapter-stops-dropping-block)
- 比べたのは3回と5回です。5A にしたあとも、持ち上げた瞬間に電流が落ちた回が1回ありました（ブロックは落ちていません）。電圧が下がったことを直接測った記録はありません。
- **ハコブくん**：「やる気はあったんです。電気が足りなかっただけで。」

---

参考：止まり方を「見る・位置を知る・決める・動く」の4段で分けた考察もあります。ログ自身が、各機体の中身は公開されておらず見立てだと断っています。→ [/record/serving-robot-stops-four-stages-stanford](/record/serving-robot-stops-four-stages-stanford)

---

## 終わりに：入れる前に、自分の現場で

**1. まず、良くしたい数字を1つ決める**
入店待ちを縮めたいのか、卓を早く使えるようにしたいのか、スタッフの歩く距離や直す手間を減らしたいのか。この図鑑では、止まり合いが減っても入店待ちは延び（7）、歩く距離が減っても卓が使えるまでは延びました（6・8）。決めた数字で、入れる前と後を比べてください。

**2. 試しの期間は、時刻を分けて残す**
- 止まった場所、止まった時刻、人が来た時刻、直り終えた時刻（1・2）
- 長い止まりの回数と時間。カメラではなく、ロボットの記録から出してもらう（5）
- 記録の「成功」が、動画で見ても成功だったか（3・4）
- 席は空いているのに待たせた時間。入れる前と後で比べる（11）
- 電源と部品が仕様どおりか（12）

**3. 図面の上で、この3か所を見る**
- すれ違えない幅の通路と、行き止まり（2・6・10）
- 待機場所の台どうしの間隔と、戻ってくる向き（7）
- 下げ膳で卓に止まったとき、代わりに通れる道（8）

**4. 足す前に、何が止めているかを測る**
2台目を入れる前、道を直す前、学習を増やす前に、止めているものを数字で確かめてください。この図鑑では、足しても狙った数字が良くならなかった記録が5つありました。ここに書いた確かめ方は、この図鑑の記録から考えたものです。

シミュレーションで店や病院をどう再現したかは、【シミュレーションのページ】にまとめています。

自分の現場でも同じ止まり方が起きるか確かめたい方は、[/message](/message) に1行ください。

---

### エイイチへのメモ（作者として決めたこと）

- **守った所**：3つの章に分けた並べ方と、「店員が来るまで」を1番目に置くことは変えていません。今回は、その数字を見出しの下の3行にも上げました。
- **直した事実**
  - 項目1：「お客さん向けの合図だったから来なかった」という断定をやめました。動画で確かめた因果ではないためです。
  - 項目6：「ほぼ2倍」を約1.8倍に直しました。
  - 学習・片付け・電源：見立ての所は、見立てと書いています。
- **削った所**
  - 販売サイトの1文（外の文脈）は、完全な URL を確かめられないので削りました。ページに外の情報は入っていません。
  - 案Cの「幅や段差ではなく」という対比は、通路の幅が原因の項目（2・6・8）と食い違うので、採っていません。
- **要確認の所**
  - 今回もこのフォルダに `材料/` はなく、ログ本文は読めていません。数字は、ログを読む人の材料と codex の照合から取っています。
  - 項目7の「店員がすぐ押すと17.56→11.32分」は、ほかの数字と条件（台数・版）が違う比較です。載せる前に、LOG456/465 の本文で条件を確かめてください。
  - 【シミュレーションのページ】の URL は、まだ仮の置き場所です。
  - ハコブくんの一人称は「ぼく」のままにしています。
```


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

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

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

---

## 先に、12を並べて分かったこと

- **直せた止まりは、どれもロボットの性能を上げて直したのではありませんでした。** 直し方は次のとおりです。
  - 1本道は1台ずつ通す
  - 待機点への入り方を変える
  - ドリンクバーを動かして行き止まりをなくす
  - 職員の動かし方を変える
  - 電源を仕様に合わせる
  - 教え方を変える
- **止まったことが、そのままでは数字にも画面にも出てこない止まり方があります。**
  - 直すのは数秒なのに、店員が来るまでは数十秒かかる
  - できない命令がエラーなしに捨てられ、記録の上では「成功」になる
  - 学習の誤差は下がるのに、実機では外れる
  - 画面の線を消すと、長い止まりの7割を見逃す
- **足しても、狙った数字が良くならなかった記録が5つあります。** 2台目、5台目、賢い道の引き方、通れる所を増やす、学習を倍にする、の5つです。何を良くしたいのかを先に決め、その数字で前と後を比べないと、足したことが効いたかどうかは分かりません。

各項目の印の意味は次のとおりです。
- 【実店舗の動画】SNS に上がった実際の店の動画を、コマ送りで読んだもの
- 【シミュレーション】Unity で再現した店・病院で回したもの。実店舗で必ず起きるという意味ではありません
- 【実機】手元の mechArm 270 で試したもの

---

## 一　止まったことに、すぐには気づけない

### 1. 店員が来るまで　【実店舗の動画】
- **現場**：飲食店（配膳ロボット）
- **何が起きたか**：店員が直した3本の動画では、直す作業は約5秒、1〜2秒、約10秒でした。それに対して、店員が来るまでは41秒以上、45秒以上、約18秒かかっていました。あとで見た4本目では、来るまでに53秒以上かかっています。
- **なぜ止まったか**：進めなくなった直接の原因は、1台分の幅で2台が向かい合ったことと、隣の台に出口をふさがれたことです。店員が来るまでに時間がかかった理由は、動画だけでは確かめられません。映っていたのはロボットの声かけと赤い明かりで、店員の手元に知らせが届いた様子は、どの動画にも映っていませんでした。知らせる機能があるかどうかは確かめていません。
- **入れる前に確かめること**
  - 止まったとき、店員の手元（端末・インカム）に知らせが届くか。それとも光と声だけか。
  - 試しの期間に、「止まってから人が来るまで」と「直すのにかかった時間」を分けて測っているか。
- **出典**：[/record/serving-robot-video-ledger](/record/serving-robot-video-ledger)、[/record/serving-robot-jams-are-aisles](/record/serving-robot-jams-are-aisles)
- 動画は編集されているので、秒数は下限です。
- **ハコブくん**：「赤く光って、声も出しています。そのあと、41秒待ちます。」

### 2. にらみ合い　【実店舗の動画】【シミュレーション】
- **現場**：飲食店（配膳ロボット）
- **何が起きたか**
  - 実店舗の動画：和食の店で、待機場所の横の2台が向かい合いました。2台ともその場で向きを変え続け、53秒以上進めませんでした。店員が空の方を手で寄せると、約4〜5秒で解けました。
  - シミュレーション：42卓・通路95cm の店で、2台が約9分10秒止まりました。そのあいだスタッフは、同じ卓へ運ぶのを5回あきらめています。
- **なぜ止まったか**：実店舗の機体が抜けられなかった中の原因は、動画からは分かりません。シミュレーションでは、2台とも料理を載せているとき（または2台とも空のとき）、どちらが譲るかを決められませんでした。しかも、よけた先が相手の通り道の上でした。
- **調べて分かったこと**：どちらが譲るかの決まりは、調べた範囲では、どのメーカーも公式には公開していませんでした。取扱説明書で分かったのは次の2つだけです。
  - すれ違えない幅では交互に通すこと。すれ違いに要る幅は、PUDU が1.6m超、KEENON T8 が1.5m超
  - しばらく待ってから道を組み直すこと。BellaBot Pro の初期値は30秒
- **シミュレーションで試した直し方**：「30秒動けなければ近くの店員が来て、着いてから15秒で空の方を動かす」という決まりを足しました。この条件の1回の試しでは、約9分の止まりが、助け2回・約105秒で解けました。ただし、同じ台に何度も助けが要るという新しい詰まりも出ています。
- **入れる前に確かめること**
  - すれ違えない幅で2台が向かい合ったら、だれが、何秒以内に、手でどかしに行くか。その担当と手順を決めているか。
  - どちらが、どこまで下がれば通れるか。下がる先がふさがっている場面も、試しの期間に見たか。
- **出典**：[/record/serving-robot-faceoff-staff-resolves](/record/serving-robot-faceoff-staff-resolves)、[/record/serving-robot-jams-are-aisles](/record/serving-robot-jams-are-aisles)
- 集めた実店舗の動画4本は、すべて同じメーカーの機体です。見た動画の中に、ロボットどうしで解けた場面はありませんでした。
- **ハコブくん**：「よけたつもりの場所が、相手の通り道でした。」

### 3. 命令が黙って捨てられる　【実機】
- **現場**：ロボットアーム（mechArm 270）
- **何が起きたか**：手で教えた動きを再生すると、つかむ位置へ降りる命令を6回送って、6回とも動きませんでした。エラーは出ず、動いた角度は最大1.50°で、止まっているときの揺れと変わりません。しかも、動いていない2本が、記録の上では「つかめた・箱に入った」になっていました。
- **なぜ止まったか**
  - 教えた肩の角度は95.53〜99.22°でした。メーカー公式の肩の範囲は−85°〜+90°です。
  - 送る側のライブラリは±190°でしか確かめないので、範囲の外の命令もそのまま送られ、アーム側で黙って捨てられていました。
  - 手で教えるときはモーターの力が抜けているので、人は範囲の外まで倒せてしまいます。
- **どう直したか**：肩を倒さず、肘と手首で下げるように教え直しました（肩87.27°）。5回再生して、5回とも成功しました。再生の前に肩の角度を確かめる手順も足しました。
- **入れる前に確かめること**
  - 動ける範囲の外の命令を送ったとき、エラーが返るか。それとも黙って止まるか。
  - 試しの記録の「成功」は、だれが何を見て付けているか。動画と照らし合わせているか。
- **出典**：[/record/teach-replay-19-demos](/record/teach-replay-19-demos)
- 捨てられたと確かめたのは、肩95.53°以上の命令だけです。
- **ハコブくん**：「できない命令は、聞かなかったことにします。『できません』と言う口がないので。」

### 4. 学習の数字は良いのに外れる　【実機】
- **現場**：ロボットアーム（mechArm 270、AI モデル π0.5）
- **何が起きたか**
  - 2,000ステップ：学習の誤差（loss）は0.1155から0.0057まで下がりました。ところが実機では4回とも、爪がブロックの上に乗り、つかむ前に止まりました。
  - 学習を倍の4,050ステップにすると、誤差は0.0030まで下がりました。それでも実機では2回とも、ブロックの奥の何もない所で爪を閉じました。
  - つかむ瞬間の土台と肩の角度は、3回ともほぼ同じでした。どれも、お手本の範囲の外でした。
- **なぜ止まったか（見立て）**：お手本19本は、ブロックをほぼ同じ場所に置いて集めたものでした。それなら、画像を細かく見なくても「いつもの場所へ手を伸ばす」だけで誤差は下がります。お手本と同じ場面で当たっても、実機の別の場面で当たるかどうかは、誤差からは分かりません。
- **どうしたか**：学習を倍にしても、手を伸ばす先は変わりませんでした。そこで、お手本の置き場所の偏りが原因ではないかと見立て、5か所で19本のお手本を集める方針にしました。それで学習し直して良くなったかは、ここに載せた記録ではまだ確かめていません。
- **入れる前に確かめること**
  - 試しの場面に、本番の置き場所のずれやばらつきが入っているか。
  - 判断の材料が「学習の数字」になっていないか。実機で何回中何回できたかで見ているか。
- **出典**：[/record/pi05-mecharm-first-real-run](/record/pi05-mecharm-first-real-run)、[/record/pi05-mecharm-4000-steps](/record/pi05-mecharm-4000-steps)
- 実機で試したのは4回と2回だけです。
- **ハコブくん**：「いつもの場所に手を伸ばすのは、得意です。いつもの場所にないときが、苦手です。」

### 5. 線を消すと、長い止まりの7割を見逃した　【シミュレーションの録画】
- **現場**：飲食店（配膳ロボット）
- **何が起きたか**：Unity の店を真上から撮った録画で試しました。ロボットのまわりを切り出した静止画1枚ずつを、画像の異常検知で判定し、30秒以上の長い止まりを拾えるかを見ました。誤報5%の条件で、拾えた割合は次のとおりです。
  - 画面に道の線がある：72%（67/93）
  - 線を消す：28%（26/94）
  - ロボットどうしの詰まりに限る：23/43 から 4/47 に落ちた
- **なぜ拾えなかったか**：線があるときに反応していたのは、画面に描かれた道の線が交わる所でした。この線は、実際の店のカメラには映りません。線がないと、向かい合う2台は白い丸が2つ並んでいるだけで、待機場所に2台が並ぶいつもの絵と見分けがつきません。止まりが30秒続くかどうかも、偶然と同じくらいしか見分けられませんでした。
- **次の案**：止まった時間はロボット自身の記録から取り、画像は原因の場所を示すのに使う、という分け方を考えています。
- **入れる前に確かめること**
  - 監視の仕組みを見せてもらうとき、拾えた止まりと見逃した止まりを、本番と同じ映り方で確かめられるか。本番には映らない線や印を、手がかりにしていないか。
  - 長い止まりの回数と時間を、ロボット自身の記録から出してもらえるか。
- **出典**：[/record/serving-robot-jam-detection-without-path-lines](/record/serving-robot-jam-detection-without-path-lines)
- 実際の店のカメラで測った値ではなく、試した方法も1つだけです。撮り直したのでロボットの動きも変わっていて、同じ場面から線だけを消した比較ではありません。お客さんとのすれ違いは、線がなくても13/17 拾えています。
- **ハコブくん**：「床に線は引いてありません。線がないと、ぼくらはただの白い丸2つです。」

---

## 二　足しても、狙った数字は良くならなかった

### 6. 2台目が待ちを延ばす　【シミュレーション】
- **現場**：飲食店（28卓・88席、スタッフ2人、昼のピーク2時間）
- **何が起きたか**
  - 良くなった数字：1台入れると、スタッフの歩く距離は約3割減りました。
  - 良くならなかった数字：入店待ちは0台13.0分、1台13.8分でした。2台にすると25.1分になり、1台の約1.8倍です（10種の中央値）。
  - スタッフがロボットを動かしに行く回数は、13回から54回に増えました。
- **なぜ止まったか**：ロボットどうしが1本道で向かい合い、ふさぎ合っていました。下の通路は約1.1m、空いている上の通路は約2.1m ありましたが、2台とも近い方の狭い道を選んでいました。止まった相手は、ロボットが354回、立ち止まった人が159回です。
- **どう直したか**
  - 「1本道は1台ずつ」にすると、入店待ちは17.6分、動かしに行く回数は約29回に減りました。
  - 一方通行にすると、混んでいるときは56.5分で、かえって悪くなりました。
  - どの案でも、この店の2台は1台に届きませんでした。なお、通路にゆとりのある別の2店では、2台で待ちが縮んでいます。
- **入れる前に確かめること**
  - 1台目に期待するのは、入店待ちを縮めることか、スタッフの歩く距離を減らすことか。先に決めているか。
  - いちばん狭い通路の幅はいくつか。ロボットはその通路を選ぶか。
- **出典**：[/record/serving-robot-one-per-narrow-restaurant](/record/serving-robot-one-per-narrow-restaurant)、[/record/small-store-second-robot-wait](/record/small-store-second-robot-wait)
- 1台と2台では Unity の作りの版が少し違い、ログにも「きっちりはそろえていない」と書いてあります。
- **ハコブくん**：「2台目が来て、通路で最初に会ったのは、お客さんじゃなくて相方でした。」

### 7. 待機場所の止まり合い　【シミュレーション】
- **現場**：大型の飲食店（70卓・312席、スタッフ6人）
- **何が起きたか**
  - 待機点へまっすぐ入る決まりに変えると、待機場所のそばの止まり合いは、1回の営業あたり3,317秒から1,255秒に、約6割減りました。
  - ところが同じ比較で、入店待ちは12.22分から14.90分に延びました。止まり合いが減っても、店全体の待ちは縮んでいません。
- **なぜ止まり合ったか**：このシミュレーションの設定では、待機点どうしの間は0.8m で、ロボットの前のセンサー（中心から0.85m）が隣の待機点の台に届いていました。戻ってくる台は斜めに寄るので、隣の台がセンサーに入って止まります。道を探した結果の87〜98%では、道は引けていました。道はあるのに、センサーで止まっていたのです。
- **台数を増やしたとき**：入店待ちは、0〜3台では11.5〜11.7分、4台で13.2分、5台で17.2分でした。ロボットどうしで止まっていた時間は、2台の67秒から5台の1,163秒に増えています（差がいちばん開いた30分）。ただしログは、5台で待ちが延びたのは「Unity のロボットに台どうしの順番決めがないことが大きく出た」と書いています。
- **ほかに試したこと**
  - 人が待機点の区画を通らないようにすると、止まり合いは809秒、店員が呼ばれる回数は180回から22回、入店待ちは13.24分になりました。
  - 条件の違う別の比較では、止まった台を近くの店員がすぐ押す決まりで、入店待ちが17.56分から11.32分に縮んでいます。
- **入れる前に確かめること**
  - 止まり合いが減ったとき、入店待ちや卓が使えるまでの時間も良くなったか。同じ条件で両方を比べられるか。
  - 待機場所の台どうしの間隔と、戻ってくるときの向きを、こちらで決められるか。待機場所の中を人が通るか。
- **出典**：[/record/large-restaurant-five-serving-robots-longer-wait](/record/large-restaurant-five-serving-robots-longer-wait)、[/record/serving-robots-jam-cause-standby-entry](/record/serving-robots-jam-cause-standby-entry)、[/record/serving-robot-jam-three-rules](/record/serving-robot-jam-three-rules)
- 0.8m と 0.85m はこのシミュレーションの設定で、実機の待機間隔の目安ではありません。
- **ハコブくん**：「道は見えてるんです。隣の子がセンサーに入るだけで。」

### 8. 下げ膳で詰まる　【シミュレーション】
- **現場**：飲食店（6店、1〜2台、各10種で計120回）
- **何が起きたか**
  - 良くなった数字：下げ膳もロボットに任せると、スタッフの歩く距離は12の条件すべてで減りました。
  - 悪くなった数字：通路の細い2店で2台のとき、お客さんが帰ってから卓が使えるまでの時間が延びました。各10種の中央値で、4.05分から6.05分、4.49分から8.06分です。
- **なぜ止まったか**：下げ膳のロボットが卓でスタッフを待つあいだ、通路が1本ふさがります。ほかのロボットとスタッフは、回り道をするか待つしかありません。通路にゆとりのある店では、別の通路を回って行けました。
- **どう直したか**：卓で待つのは2分までにし、待っている台も助けで動かしてよいことにしました。解けずに残った詰まりは53件から4件に減りました。卓が使えるまでの時間が延びる問題そのものは、まだ直していません。
- **入れる前に確かめること**
  - スタッフの歩く距離が減っても、次のお客さんを案内できるまでの時間が延びたら、その使い方を採るか。どちらを優先するか、試しの前に決めているか。
  - 下げ膳のロボットが卓で待っているあいだ、スタッフとほかのロボットが回り道できる通路があるか。
- **出典**：[/record/serving-robot-sim-bussing-narrow-aisles](/record/serving-robot-sim-bussing-narrow-aisles)、[/record/serving-robot-bussing-depends-on-aisles](/record/serving-robot-bussing-depends-on-aisles)
- 店ごとの入店待ちが縮んだか延びたかは、録画1回ずつで見たものです。ログにも「店ごとの答えを言い切ることはできません」と書いてあります。
- **ハコブくん**：「お皿を待っているあいだ、ぼくは通路の栓になっています。」

### 9. 直したら問題が増えた　【シミュレーション・仮の病院】
- **現場**：病院（薬剤などの搬送ロボット）
- **何が起きたか**：仮の病院で、行き先へ歩いて行けなかった患者と職員41人が通れるように直しました。すると、ロボットの問題（急に止まった・ひやりとした・人がよけさせられた など）が、1日84件から132件に増えました。増えた48件のうち37件は大廊下の東の端で起き、相手はほとんどが職員でした。
- **なぜ止まったか**
  - 付き添い用に入れるようにした所へ、職員がふだんの行き来でも行くようになりました。たとえば、検査技師が救急の処置の場所へ行く回数は0回から46回になりました。
  - さらにたどると、Unity の職員141人は「1人が1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動いていました。
- **どう直したか**
  - 職員の行き先を持ち場に限ると、132件が68件になりました。
  - 持ち場ごとの4つの型で動かすと19件になり、車いすの患者が動けなかった時間は最長663.8秒から20.3秒に縮みました。
  - その後、患者の動きを足すと51件に増えています。条件のそろった数として、ログは51件の方を挙げています。
- **入れる前に確かめること**
  - シミュレーションや試しの結果を見せられたら、まず「人をどう動かしたか」を聞く。
  - ロボットの道を変えたとき、その道を使い始める人はだれか。
- **出典**：[/record/hospital-transport-robot-avoid-outpatient-hall](/record/hospital-transport-robot-avoid-outpatient-hall)、[/record/hospital-transport-robot-blocked-paths-more-conflicts](/record/hospital-transport-robot-blocked-paths-more-conflicts)、[/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)
- 数えたのは衝突ではなく「問題」の件数で、止まりきれなかったのは132件中10件です。比べたのは主に1つの条件で1回ずつで、別の条件では56件から260件と、ぶれも大きく出ています。
- **ハコブくん**：「ひやりとした相手は、くじ引きで行き先を決める、仮の職員さんでした。」

---

## 三　詰まりの元は、ロボットの外にあった

### 10. 線に縛ると詰まる　【シミュレーション】
- **現場**：飲食店（42卓）
- **何が起きたか**：2台を走らせると、60秒止まった回が58回あり、そのうち51回の相手はもう1台のロボットでした。行き止まりで向かい合ったまま、600秒で打ち切りになった回もあります。
- **なぜ止まったか**：Unity のロボットは、渡された道の線の上しか走れない作りでした。42卓への道のうち23本が、同じ通路を通っていました。実機は地図の上で道を引いて回り込むので、これは実機にはない縛りです。
- **どう直したか**
  - まず、地図の上で道を引けるようにしました。ところが60秒の止まりは57回から59回で、減りませんでした。59回のうち43回は、右下の行き止まり（ドリンクバーと6人席の間が0.4m）に集まっていました。
  - そこでドリンクバーを上へ0.5m、左へ0.8m 動かすと、20回になりました。料理の待ちは2.90分から1.17分に縮み、ロボットが運んだ割合は64.4%から99.4%になりました。
- **入れる前に確かめること**
  - 店の中の行き止まりはどこか。家具を数十cm 動かせば抜け道ができる所はないか。
  - ロボットは決まった線しか走らないのか、地図の上で回り込めるのか。
- **出典**：[/record/serving-robot-fixed-route-jam](/record/serving-robot-fixed-route-jam)、[/record/serving-robot-map-planner](/record/serving-robot-map-planner)
- 比べたのは、どれも同じ条件で1回ずつです。
- **ハコブくん**：「賢い地図をもらっても、行き止まりはドリンクバーでした。」

### 11. 席は空いているのに、待たせる　【シミュレーション】
- **現場**：飲食店（46卓・スタッフ4人、38卓）
- **何が起きたか**：ロボットを足すと、入店待ちは縮みました（46卓の店で、0台8.1分、1台6.6分、2台5.5分）。それでも、席は空いているのにお客さんを待たせた時間が残りました。46卓の店では0台6.5分・1台4.6分・2台3.4分で、計算で見込んだ1.5分・0.8分・0.7分の何倍もあります。38卓の店でも、計算の2.0〜5.5倍でした。
- **なぜ待たせたか**
  - 計算では、食べ終えたお客さんがレジを待つあいだ卓に座ったままなので、レジが詰まるはずでした。
  - ところが3Dの店でスタッフを歩かせると、片付けと案内が追いつかない時間が残りました。
  - 別の2店では、スタッフが歩き回るぶん1組あたりの仕事が計算より約1割長く、片付けが後回しになっていました。46卓・38卓の店でも同じことが起きていると、ログは見ています。
- **入れる前に確かめること**
  - ロボットを入れる前の今、「席は空いているのに待たせている時間」を測ったことがあるか。
  - 待ちの元は、運ぶことか、レジか、それとも片付けと案内か。
- **出典**：[/record/large-store-cleanup-bottleneck](/record/large-store-cleanup-bottleneck)、[/record/standby-jam-every-store](/record/standby-jam-every-store)
- **ハコブくん**：「ぼくをもう1台呼ぶ前に、片付けの手を見てください。」

### 12. まさかの電源不足　【実機】
- **現場**：ロボットアーム（mechArm 270）
- **何が起きたか**：ある位置のブロックを、9回中2回しか運べませんでした。その2回も、人が手を貸しています。つかんでから11〜19秒で爪の電流が0近くまで落ち、ブロックを落としていました（17本中12本）。
- **なぜ止まったか**：本体が求める電源は40W（説明書では8.4V・5A）です。つないでいたのは外付けディスク用の12V・2A（24W）で、求める量の6割しかありませんでした。このアダプターは箱に入っておらず、あとから別に送られてきたものです。8か月分の実機の記録は、すべてこの電源で取っていました。
- **どう直したか**：12V・5A のアダプター（3,355円）に替えました。同じモデル・同じ位置・同じ閉じる設定で、日を変えて替える前と後を比べました。
  - 成功：3回中1回 → 5回中5回
  - 人の手直し：3回中3回 → 5回中1回（持ち上げを人が手伝った）
  - 教えた動きの再生：7回すべて成功
- **入れる前に確かめること**
  - 電源やアダプターは、説明書の仕様どおりか。付属のものか。
  - うまくいかないとき、AI や設定を疑う前に、電源と部品を確かめる順番になっているか。
- **出典**：[/record/mecharm-270-drops-block-underpowered-adapter](/record/mecharm-270-drops-block-underpowered-adapter)、[/record/mecharm-270-5a-adapter-stops-dropping-block](/record/mecharm-270-5a-adapter-stops-dropping-block)
- 比べたのは3回と5回です。5A にしたあとも、持ち上げた瞬間に電流が落ちた回が1回ありました（ブロックは落ちていません）。電圧が下がったことを直接測った記録はありません。
- **ハコブくん**：「やる気はあったんです。電気が足りなかっただけで。」

---

参考：止まり方を「見る・位置を知る・決める・動く」の4段で分けた考察もあります。ログ自身が、各機体の中身は公開されておらず見立てだと断っています。→ [/record/serving-robot-stops-four-stages-stanford](/record/serving-robot-stops-four-stages-stanford)

---

## 終わりに：入れる前に、自分の現場で

**1. まず、良くしたい数字を1つ決める**
入店待ちを縮めたいのか、卓を早く使えるようにしたいのか、スタッフの歩く距離や直す手間を減らしたいのか。この図鑑では、止まり合いが減っても入店待ちは延び（7）、歩く距離が減っても卓が使えるまでは延びました（6・8）。決めた数字で、入れる前と後を比べてください。

**2. 試しの期間は、時刻を分けて残す**
- 止まった場所、止まった時刻、人が来た時刻、直り終えた時刻（1・2）
- 長い止まりの回数と時間。カメラではなく、ロボットの記録から出してもらう（5）
- 記録の「成功」が、動画で見ても成功だったか（3・4）
- 席は空いているのに待たせた時間。入れる前と後で比べる（11）
- 電源と部品が仕様どおりか（12）

**3. 図面の上で、この3か所を見る**
- すれ違えない幅の通路と、行き止まり（2・6・10）
- 待機場所の台どうしの間隔と、戻ってくる向き（7）
- 下げ膳で卓に止まったとき、代わりに通れる道（8）

**4. 足す前に、何が止めているかを測る**
2台目を入れる前、道を直す前、学習を増やす前に、止めているものを数字で確かめてください。この図鑑では、足しても狙った数字が良くならなかった記録が5つありました。ここに書いた確かめ方は、この図鑑の記録から考えたものです。

シミュレーションで店や病院をどう再現したかは、【シミュレーションのページ】にまとめています。

自分の現場でも同じ止まり方が起きるか確かめたい方は、[/message](/message) に1行ください。

---

### エイイチへのメモ（作者として決めたこと）

- **守った所**：3つの章に分けた並べ方と、「店員が来るまで」を1番目に置くことは変えていません。今回は、その数字を見出しの下の3行にも上げました。
- **直した事実**
  - 項目1：「お客さん向けの合図だったから来なかった」という断定をやめました。動画で確かめた因果ではないためです。
  - 項目6：「ほぼ2倍」を約1.8倍に直しました。
  - 学習・片付け・電源：見立ての所は、見立てと書いています。
- **削った所**
  - 販売サイトの1文（外の文脈）は、完全な URL を確かめられないので削りました。ページに外の情報は入っていません。
  - 案Cの「幅や段差ではなく」という対比は、通路の幅が原因の項目（2・6・8）と食い違うので、採っていません。
- **要確認の所**
  - 今回もこのフォルダに `材料/` はなく、ログ本文は読めていません。数字は、ログを読む人の材料と codex の照合から取っています。
  - 項目7の「店員がすぐ押すと17.56→11.32分」は、ほかの数字と条件（台数・版）が違う比較です。載せる前に、LOG456/465 の本文で条件を確かめてください。
  - 【シミュレーションのページ】の URL は、まだ仮の置き場所です。
  - ハコブくんの一人称は「ぼく」のままにしています。
```


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

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

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

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

### 01　店員が来るまで

**どんな現場で：飲食店／実店舗の動画観察**

**何が起きたか**  
店員が対応した動画3例では、直す作業は約1〜10秒でした。到着までは約18秒、41秒以上、45秒以上かかり、直す時間より、助けが来るまでの時間が長くなっていました。

**なぜ止まったか**  
狭い通路での向かい合いや、待機場所の出口をふさがれたことがきっかけです。声と赤い明かりは映っていますが、店員の手元に知らせが届いた様子は映っていません。通知機能の有無は未確認で、動画の編集もあるため、秒数は概算・下限です。

**入れる前に確かめること**

- 忙しい時間に止まったら、誰が、何で気づくか。
- 「止まってから人が着くまで」と「着いてから直すまで」を、分けて測れるか。

**出典：** [実店舗の動画をコマ送りで読んだ記録](/record/serving-robot-video-ledger)

**ハコブくん：**「直すのはすぐです。来てもらうまでが長いんです。」

---

### 02　2台目で待ちが延びる

**どんな現場で：28卓・スタッフ2人の飲食店／Unityのシミュレーション**

**何が起きたか**  
普通の混み具合で、入店待ちは1台の13.8分から、2台では25.1分へ延びました。昼のピーク2時間にスタッフがロボットを動かしに行く回数も、13回から54回に増えました。

**なぜ止まったか**  
2台とも近い方の狭い一本道を選び、向かい合ってふさぎ合っていました。「一本道は1台ずつ」にすると2台の入店待ちは17.6分まで縮みましたが、試した案では1台より短くなりませんでした。

数字は来客の並びを変えた10回の中央値です。ただし1台と2台にはシミュレーションの版の違いが残り、この結果をほかの店の台数上限にはできません。

**入れる前に確かめること**

- 2台目が加わると、どの一本道で出会うか。片方が待てる場所はあるか。
- 運ぶ量だけでなく、人が助けに行く回数と入店待ちも改善するか。

**出典：** [2台目と通行ルールを比べた記録](/record/serving-robot-one-per-narrow-restaurant)／[小さな店に2台を入れた記録](/record/small-store-second-robot-wait)

**ハコブくん：**「同僚が増えたら、店員さんを呼ぶ仕事が増えました。」

---

### 03　下げ膳中、通路をふさぐ

**どんな現場で：飲食店／Unityのシミュレーション**

**何が起きたか**  
6店・1〜2台・来客の並び10通りの比較では、下げ膳も任せると、スタッフの歩く距離は12条件すべてで減りました。一方、細い通路の2店では2台のとき、退店から卓が使えるまでが4.05分→6.05分、4.49分→8.06分に延びました。

**なぜ止まったか**  
下げ膳のロボットが卓に着き、スタッフを待つあいだに通路をふさいでいました。別の通路があれば回れますが、一本道ではほかのロボットも人も待たされます。

各条件1回の比較動画では、ゆとりのある店で入店待ちが縮み、細い店で延びました。ただし繰り返し集計では例外もあり、店の種類だけでは結果を決められません。

**入れる前に確かめること**

- 皿を載せる人が来ないあいだ、ロボットはどこで待つか。その横を通れるか。
- 歩く距離が減っても、次のお客さんを座らせるまでが延びていないか。

**出典：** [下げ膳を加えて繰り返し比較した記録](/record/serving-robot-sim-bussing-narrow-aisles)／[6店の比較動画](/record/serving-robot-bussing-depends-on-aisles)

**ハコブくん：**「お皿待ちのつもりが、通せんぼになってました。」

---

### 04　席は空いているのに案内できない

**どんな現場で：46卓・38卓の飲食店／試算とUnityの比較**

**何が起きたか**  
46卓の店では、0台・1台・2台と増やすと、入店待ちは8.1分→6.6分→5.5分に縮みました。それでも2台のとき、「席は空いているのに待った時間」が46卓の店で3.4分、38卓の店で3.5分残りました。

**なぜ止まったか**  
試算ではレジが詰まっていましたが、3Dの店では、スタッフが歩き回ることで片付けと案内が後回しになる、とログでは見ています。ここで止まっているのは、ロボットの車輪ではなく、次のお客さんを迎える仕事です。

各10回の中央値ですが、当時のシミュレーションには瞬間移動などの簡略化も残っていました。

**入れる前に確かめること**

- 運ぶ仕事が減った時間を、誰が片付けと案内に使えるか。
- 入店待ちのうち、満席で待つ時間と、席を使える状態にできず待つ時間を分けているか。

**出典：** [46卓の店で詰まる仕事を調べた記録](/record/large-store-cleanup-bottleneck)／[38卓の店と待機場所を調べた記録](/record/standby-jam-every-store)

**ハコブくん：**「運び終わりました。次のお客さんの席は、まだでした。」

## 通れる幅があっても、抜けられない

### 05　にらみ合い

**どんな現場で：飲食店／実店舗の動画観察とUnityのシミュレーション**

**何が起きたか**  
実店舗の動画では、待機場所の横で向かい合った2台が53秒以上進めず、店員が空の方を手でよけて約4〜5秒で解いていました。Unityの42卓・通路95cmの店では、2台が約9分10秒止まった例がありました。

**なぜ止まったか**  
Unityでは、両方が料理を載せている場合などに、どちらが譲るかを決められず、よけた先も相手の道の上でした。実店舗の機体内部の判断は未確認です。観察した詰まり動画は同じメーカーの少数例で、すべての機体に共通する結果ではありません。

Unityに店員が助ける決まりを入れると、この約9分の例は助け2回・約105秒で解けました。ただし、同じ台に何度も助けが必要になる問題も残りました。

**入れる前に確かめること**

- 両方が荷物を載せた状態で出会ったら、どちらが、どこまで下がるか。
- 自力で解けないとき、人が安全に解く手順を実際に試せるか。

**出典：** [実店舗で店員が解いた場面とシミュレーションの比較](/record/serving-robot-faceoff-staff-resolves)／[待機場所の横で向かい合った動画の観察](/record/serving-robot-jams-are-aisles)

**ハコブくん：**「お先にどうぞ。……その先に、ぼくがいます。」

---

### 06　待機場所へ戻れない

**どんな現場で：70卓・312席の飲食店／Unityのシミュレーション**

**何が起きたか**  
入店待ちは2台で11.7分、5台で17.2分でした。別の比較で、待機点へまっすぐ入る決まりにすると、待機場所付近の止まり合いは1営業あたり3,317秒→1,255秒に減りましたが、入店待ちは12.22分→14.90分に延びました。

**なぜ止まったか**  
0.8m間隔の待機点へ斜めに戻ると、隣で待つ台が前のセンサーに入り、止まっていました。人も待機点の区画を通らない形にすると、止まり合いは809秒まで減りました。

数字は各10回の中央値です。ただし、この作りには実機のような台どうしの順番決めが不足しており、5台の悪化をそのまま実店舗の予測には使えません。詰まりが減ることと、店全体の待ちが縮むことも別でした。

**入れる前に確かめること**

- 全台が待機しているところへ最後の1台が戻り、また出発できるか。人の通り道と重ならないか。
- 待機場所の停止時間を減らしたあと、片付けや入店待ちまで改善したか。

**出典：** [5台で待ちが延びた記録](/record/large-restaurant-five-serving-robots-longer-wait)／[斜めに戻る入り方を調べた記録](/record/serving-robots-jam-cause-standby-entry)／[人の通り道も変えた記録](/record/serving-robot-jam-three-rules)

**ハコブくん：**「駐車位置は空いてます。入る途中が空いてません。」

---

### 07　道を引き直しても詰まる

**どんな現場で：飲食店／Unityのシミュレーション**

**何が起きたか**  
決まった線だけを走る作りから、地図で道を引く作りに変えても、60秒以上の停止は57回→59回で減りませんでした。さらにドリンクバーを上へ0.5m、左へ0.8m動かして抜け道を作ると、20回になりました。

**なぜ止まったか**  
最初は、同じ線を往復するシミュレーション側の制約がありました。それを外しても、ドリンクバーと席の間が0.4mしかない行き止まりに詰まりが集中しました。道を探せても、抜け道そのものがなければ回れません。

同じ来客の並びで各1回の比較です。「地図を渡すだけで57回から20回になった」という結果ではありません。

**入れる前に確かめること**

- 道の引き方を変える前に、行き止まりと、そこで出会う往復の流れを確かめたか。
- シミュレーションで詰まった原因は、現場の配置か、再現する側が加えた制約か。

**出典：** [決まった線しか走れなかった作り](/record/serving-robot-fixed-route-jam)／[道の引き方とドリンクバー移動を分けた比較](/record/serving-robot-map-planner)

**ハコブくん：**「地図は読めます。壁の向こうには回れません。」

## 命令や学習の数字が良くても、仕事は終わらない

### 08　つかんだのに落とす

**どんな現場で：ロボットアーム／実機 mechArm 270**

**何が起きたか**  
つかんだブロックを落としていた実機で、電源を12V・2Aから12V・5Aへ替えると、同じモデル・同じ爪の設定・同じ位置で、成功は3回中1回から5回中5回になりました。ただし交換後も1回は人が持ち上げを補助し、爪の電流低下が残りました。

**なぜ止まったか**  
本体の表示は40Wでしたが、8か月使っていたアダプターは24Wでした。落とす前に爪の電流が0付近まで下がる記録と、交換後の変化から、ログでは電源不足が原因と判断しています。

交換費用はログ記載で3,355円。比較した日は異なり、電圧低下を直接測った記録はありません。交換後の5回成功も、全自動で問題が消えたという意味ではありません。

**入れる前に確かめること**

- 電源は、その機体が指定する電圧・電流・接続条件と合っているか。
- つかんで静止するだけでなく、持ち上げて運ぶ間も保持できるか。補助した回を分けて記録しているか。

**出典：** [ブロックを落とす直前の電流と電源を調べた記録](/record/mecharm-270-drops-block-underpowered-adapter)／[電源交換後の実機比較](/record/mecharm-270-5a-adapter-stops-dropping-block)

**ハコブくん：**「学習のおかわりより先に、電源を見てください。」

---

### 09　命令したのに、黙って動かない

**どんな現場で：ロボットアーム／実機 mechArm 270**

**何が起きたか**  
肩95.53〜99.22°の姿勢へ降りる命令は、エラーなしに6回とも動きませんでした。肩を87.27°にして教え直すと5回続けて成功し、一方で、動かなかった記録2本が台帳では「つかめた・箱に入った」と判定されていました。

**なぜ止まったか**  
公式の肩の範囲は−85°〜＋90°ですが、送る側のライブラリはそれより広い範囲を許していました。手で教えると範囲外まで倒せても、その姿勢への命令は実機で受け付けられませんでした。

本線には肩88°の上限がありましたが、再生用コードには入っていませんでした。88°は本線の設定値で、厳密に確かめた拒否境界ではありません。

**入れる前に確かめること**

- 教示・再生・本番で、同じ可動範囲の確認が働くか。
- 「命令を送れた」と「実際に動いて仕事を終えた」を、別々に確認しているか。

**出典：** [動かなかった角度・教え直し・台帳の誤判定の記録](/record/teach-replay-19-demos)

**ハコブくん：**「返事がないのを、了解にしないでください。」

---

### 10　学習の数字は良いのに空振り

**どんな現場で：ロボットアーム／π0.5を使った実機 mechArm 270**

**何が起きたか**  
2,000ステップ学習した実機は4回ともつかむ前に止まり、動画では爪がブロックの上に乗っていました。学習を4,000ステップに増やし、学習誤差が約0.0057から0.0030に下がっても、実機2回ともブロックの奥で爪を閉じました。

**なぜ止まったか**  
お手本19本は、ブロックをほぼ同じ場所に置いて集めていました。「いつもの場所へ手を伸ばす」だけでも学習誤差が下がるため、位置の違う場面に対応できたかは、その数字から分かりません。

ログでは位置の違うお手本が必要と判断し、その後5か所で19本を集めています。集め直したお手本で再学習した結果は、この材料には含まれていません。

**入れる前に確かめること**

- 学習に使っていない位置へ対象物を置いても、つかむ場所が変わるか。
- 学習誤差とは別に、実機でつかめた回数、箱まで運べた回数、人が補助した回数を数えているか。

**出典：** [最初の実機試行で爪が乗った記録](/record/pi05-mecharm-first-real-run)／[追加学習しても奥で空振りした記録](/record/pi05-mecharm-4000-steps)

**ハコブくん：**「いつもの場所は覚えました。今日のブロックは、そこですか？」

## 止まりを見つける仕組みも、確かめる

### 11　見張りが見ていたのは、画面の線

**どんな現場で：飲食店／Unityの録画を使った画像検知試験**

**何が起きたか**  
切り出した静止画1枚ずつで30秒以上の停止を見つける試験では、誤報5%の条件で、経路線ありは93件中67件、72%を拾いました。線なしでは94件中26件、28%でした。

**なぜ拾えなかったか**  
この方法は、ロボットだけでなく、画面上の経路線が交わる所を手がかりにしていました。実店舗のカメラにはその線が映らず、線を消した画像では、向かい合う2台と普段どおり並んで待つ2台を区別しにくくなりました。

撮り直しで動きも変わっており、同一場面から線だけを消した比較ではありません。実店舗のカメラ性能や、ほかの検知方法を測った結果でもありません。

**入れる前に確かめること**

- 検証画像に、本番のカメラには映らない表示が混ざっていないか。
- 「長く止まったこと」は機体の時刻付き記録で取り、画像と照らし合わせられるか。

**出典：** [経路線を消して検知率を測り直した記録](/record/serving-robot-jam-detection-without-path-lines)

**ハコブくん：**「ぼくの困り顔より、道の線を見てたんですね。」

---

### 12　病院を直したら、問題が増える

**どんな現場で：病院の搬送ロボット／Unityで作った仮の病院**

**何が起きたか**  
行き先へ歩いて行けなかった患者・職員41人を通れるようにすると、急停止・ひやり・人によけさせた等の問題が1日84件→132件に増えました。職員の行き先と動き方を直すと19件まで減りましたが、さらに患者などの動きを補うと51件になりました。

**なぜ止まったか**  
職員141人を「1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動かしていました。付き添いのために通れるようにした場所へ、職員が普段も行くようになり、ロボットと出会う回数が増えていました。

これは実際の病院職員の動きではありません。主に同じ来客・移動の並び1通りでの比較で、19件は通り抜ける人を十分に動かせていなかった段階の値です。また、件数は衝突事故の数ではありません。

別の経路比較では、混む外来の大廊下を避けると問題が減る一方、届くまでの時間は延びました。何を減らし、何を受け入れるかを分ける必要があります。

**入れる前に確かめること**

- 職種ごとの持ち場・用事・付き添いを、実際の運用に照らしたか。「仮」で置いた動きがどれか分かるか。
- 問題が減ったのは、人を通れなくしたからではないか。必要な人と荷物が目的地へ着いているか。

**出典：** [外来の廊下を避ける経路の比較](/record/hospital-transport-robot-avoid-outpatient-hall)／[通れる場所を直して問題が増えた記録](/record/hospital-transport-robot-blocked-paths-more-conflicts)／[職員の仮の動きと、その後の測り直し](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)

**ハコブくん：**「毎時間くじ引きで出張する病院だとは聞いてません。」

## 自分の現場では、何を確かめるか

この図鑑は、人が助けるまでの時間から始め、台数と仕事の増やし方、通路と待機場所、実機の命令と学習、最後に測り方そのものへ進む順に並べました。導入後に誰の手が必要になるかを先に決め、そのうえで、台数や機能を足す判断へ進むためです。

トライアルでは、走れた場面に加えて、**止まってから仕事が終わるまで**を残してください。自分の現場で気になった項目を選び、次の欄を埋めて持ち帰れます。

| 残すこと | 書く内容 |
|---|---|
| 起きた条件 | 場所、混み具合、台数、荷物、人の作業 |
| 待った時間 | 停止、気づき、人の到着、復帰の各時刻 |
| 人がしたこと | 画面操作、移動、積み下ろし、持ち上げなど |
| 仕事の結果 | 届いたか、卓が使えたか、次の人を案内できたか |
| 変えて比べること | 台数、配置、通行ルール、待ち方などを一つずつ |

人が手を貸して完了した回は、その手間も含めて導入の結果です。

外の導入事例にも、止まった後の扱いが判断材料になった例があります。京都大学医学部附属病院の事例では、従来の搬送機は停止すると検体の取り出しに業者が必要だった一方、廊下を走るロボットなら人が取り出せることが、検討の背景として説明されています。復旧や取り出しのしやすさも、導入前に確かめたい条件です。［[パナソニック コネクトの導入事例](https://connect.panasonic.com/jp-ja/case-studies/kyoto-university-hospital)、公開日記載なし・2026年11月14日確認］

原因を整理するときは、「見る・位置を知る・決める・動く」のどこで止まったかに加え、誰が載せ、受け取り、助けるかという運用も見ます。この分け方は[ログでの考察](/record/serving-robot-stops-four-stages-stanford)であり、各機体の内部原因を確かめた分類ではありません。

店の形・人数・台数を変えて考えるには、[配膳ロボットの導入シミュレーション](/series8)へ。

自分の現場で確かめたい止まり方や、共同で検証したい条件は、[メッセージフォーム](/message)へ。
```


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

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

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

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

- **いちばん刺さる項目：09「命令したのに、黙って動かない」**
  動かなかった試行が、台帳では「つかめた・箱に入った」と記録されていました。試験導入の報告を受け取る側の経営者に、直接効く事実です。ただ今の文面では、この事実が「一方で」の後ろに隠れています（指摘2）。
- **いちばん弱い項目：11「見張りが見ていたのは、画面の線」**
  確かめる問いが、画像検知を作る人に向けた問いになっています。経営者やPMは自分で検知の仕組みを作りません。「見張りの仕組みを提案されたときに聞くこと」に書き換えます（指摘5）。

---

### 1. 見出しの下の3行：待った時間と直す時間の差を、1行で言い切る
今は「約18秒、41秒以上、45秒以上」と3つの数字が並んでいて、差が伝わりません。LOG400 の動画（53秒以上待って、直す作業は約4〜5秒）も、店員が直した例として照合が取れています。

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

01の「何が起きたか」には、次の1文を足します。出典に /record/serving-robot-jams-are-aisles も加えます。
> 最初の動画では、待った時間が直す時間の8倍を超えていました（41秒以上と約5秒）。

### 2. 09（いちばん刺さる項目）：台帳の「成功」を先頭に置き、この節の最初に移す
今の文の「一方で」は、つながりがおかしくなっています。

> **何が起きたか**
> 手で教えた動きを再生すると、つかむ位置へ降りる命令が6回とも動きませんでした（肩95.53〜99.22°）。エラーは出ていません。しかも、動かなかった2本は、台帳に「つかめた・箱に入った」と記録されていました。肩を87.27°にして教え直すと、5回続けて成功しました。

確かめる問いの2つ目は、次のように変えます。
> - 試験導入の報告にある「成功」は、誰が、何を見て付けたか。1回ずつ動画と照らせるか。

並びは 09 → 08 → 10 にします。節の見出し「命令や学習の数字が良くても、仕事は終わらない」を、いちばん体現している項目だからです。

### 3. 08：「8か月分の記録」と「3,355円」を本文に出す
今は、費用が但し書きの段落に入っています。このページで初めて得るのは、試験のデータそのものが、足りない電源の上で取られていたという事実です。

> **何が起きたか**
> つかんだブロックを、11〜19秒後に落としていました（17本中12本）。つないでいた電源は12V・2A（24W）で、本体が求める40Wの6割です。8か月分の実機の記録は、すべてこの電源で取っていました。12V・5A（3,355円）に替えると、同じ位置・同じ爪の設定で、成功は3回中1回から5回中5回になりました（うち1回は、人が持ち上げを補助）。

確かめる問いを1つ足します。
> - 試験導入の機材は、本番と同じ電源と部品で組まれているか。付属品の型番まで照らしたか。

### 4. 05：取扱説明書で分かったことを書き、導入元に聞く問いにする
今の文面は「実店舗の機体内部の判断は未確認です」で止まっています。けれどログには、取扱説明書を調べて得た、このページだけの事実があります。

> **なぜ止まったか**（先頭に足す）
> 2台が出会ったとき、どちらが譲るか。その決まりは、調べた範囲では、どのメーカーの公開資料にも書かれていませんでした。取扱説明書で確かめられたのは2つだけです。すれ違えない幅では交互に通すこと（すれ違いに要る幅は、PUDU が1.6m超、KEENON T8 が1.5m超）と、待ってから道を組み直すこと（BellaBot Pro の初期値は30秒）です。

> **入れる前に確かめること**（1つ目と差し替える）
> - 荷物を載せた2台が出会ったとき、どちらが譲るか。道を組み直すまで何秒待つか。導入元に書面で示してもらえるか。

メーカーを悪く言わず、事実の範囲でいちばん強く言える形です。

### 5. 11（いちばん弱い項目）：見張りの仕組みを「提案されたとき」の問いに変える
今の問い「検証画像に、本番のカメラには映らない表示が混ざっていないか」は、作る人の確かめです。

> **何が起きたか**（2文目を足す）
> 線のない画像では、ロボットどうしの詰まりは47件中4件しか拾えませんでした。30秒続くかどうかの見分けは0.51で、偶然と同じです。

> **入れる前に確かめること**
> - 止まりを映像で見張る仕組みを提案されたら、その評価に使った映像は、自分の現場のカメラと同じ見え方か。
> - 止まった時刻と長さを、機体の記録から取り出せるか。導入元に、その記録を見せてもらえるか。

### 6. 12：見せ場を「仮置きの動きだけで、数が大きく動く」に置き、但し書きを1行にする
今は但し書きが3段落あり、教訓がぼやけています。PMに効くのは、導入元のシミュレーションを見せられたときに何を聞くか、です。

> **何が起きたか**
> 通れなかった患者・職員41人を通れるようにすると、ロボットの問題（急停止・ひやり・人によけさせた、など）は1日84件から132件に増えました。そのあとは人の動きの置き方を変えただけで、132件 → 68件 → 19件 → 51件と動きました。
>
> **測り方：** Unityで作った仮の病院。来院や移動の並びは主に1通り。件数は衝突の数ではない。

> **入れる前に確かめること**（1つ目と差し替える）
> - 導入元のシミュレーションを見せられたら、職員と患者の動きを何を元に置いたか。仮置きの動きがどれか、示してもらえるか。

この「**測り方：**」の1行の形は、ほかの項目にも使えます。02・03・04・06・07・11の但し書き段落を1行にそろえると、強い事実が前に出ます。

### 7. 終わりに：並べた順の説明を、「足せば良くなる、が外れた5回」に替える
「この図鑑は、人が助けるまでの時間から始め…」という並べた順の説明は、読む人の判断に効きません。代わりに、12項目を通して見えることを置きます。

> **足せば良くなる、が5回外れました**
> - 2台目：入店待ち13.8分 → 25.1分（02・シミュレーション）
> - 5台目：入店待ち11.7分（2台） → 17.2分（06・シミュレーション）
> - 道の引き方を変える：60秒以上の停止が57回 → 59回（07・シミュレーション）
> - 学習を倍にする：手を伸ばす先は変わらない（10・実機）
> - 通れない所を直す：問題が84件 → 132件（12・シミュレーション）
>
> 足す前に、どこで止まっているかを測る。12の場面に共通する順番です。

そのあとに、「止まってから仕事が終わるまで」を書き込む今の表を続けます。表はそのままで生きます。

### 8. 事実の照合：パナソニックの事例の引用が、材料と合っていない
- **アドレスと日付：** 材料のアドレスは `connect.panasonic.com/jp-ja/case-studies/kyoto-u`、日付は2021年3月30日です。案Bは別のアドレスで、「公開日記載なし」としています。
- **言葉の足し：** 材料は「途中で止まると業者を呼ぶ必要がある」「廊下で止まっても誰かが取り出せる」と書いているだけです。「検体」という言葉は材料にありません。

作者が実際にページを開いて確かめたのでなければ、材料に合わせます。

> 京都大学医学部附属病院の導入事例では、従来の搬送機は途中で止まると業者を呼ぶ必要がありました。廊下を走るロボットなら、止まっても誰かが取り出せる。このことが、導入の理由の1つとして挙げられています。［パナソニック コネクトの導入事例、2021年3月30日］

ほかの数字（02・03・06・07・10・12）は、照合の材料と合っていました。07の「57回 → 59回 → 20回」の書き分けと、06の「入店待ちは12.22分 → 14.90分に延びた」の明記は正確です。この2つは、そのまま残してください。
```


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

```markdown
案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回目）

```markdown
【採否】

**案Aの作者から**

1. **一部採る** — 冒頭を「直す約1〜10秒、来るまで約18〜53秒以上」に更新し、本文に観察した4例と出典を示す。時間の比は重ねない。
2. **採る** — 動かなかった記録が「成功」になっていた事実を先頭に置き、実機の節もこの項目から始める。
3. **採る** — 「8か月分の記録」と「3,355円」を本文へ出し、人の補助が残ったことも同じ場所に書く。
4. **一部採る** — 導入元に譲り方と待ち時間を実演してもらう問いを採る。公開資料の調査結果はログで調べた範囲に限定し、機種ごとの仕様値の追加は見送る。
5. **一部採る** — 見張りを提案された側の問いに直し、線なしではロボット同士の詰まりを47件中4件しか拾えなかった事実を出す。説明が別途必要になる「0.51」は載せない。
6. **一部採る** — 仮置きの人の動きで件数が変わることを中心にする。ただし、19件から51件への変化は患者などの動きを補った結果として分けて書く。
7. **一部採る** — 並び順の説明を外し、「足す前に何を確かめるか」で結ぶ。「5回外れた」という数え方より、各項目へ戻れる形を選ぶ。
8. **一部採る** — 外部事例の出典と日付に未照合の記載を残さず、段落ごと削除する。結びは今回のログから持ち帰れる確かめ方に絞る。

**案Cの作者から**

1. **一部採る** — 「席は空いているのに案内できない」は残し、家具の移動が効いた事実を前へ出す。ただし、投資効果の空振りや、家具移動が経路変更より常に優れるという結論にはしない。
2. **一部採る** — 通知機能への言及は削り、待った時間の長さを中心にする。編集された動画の概算・下限であることは短く残す。
3. **一部採る** — 電源と費用を前へ出す。「替えるだけで解決」とはせず、交換後も人の補助と電流低下が残ったことを書く。
4. **一部採る** — 画面の線を手がかりにしていた点を強める。「ロボットの姿ではなく」と排他的に断定せず、撮り直しによる条件の違いも残す。
5. **一部採る** — 見出しから仮の病院だと分かる形に直す。問題の定義と人の動きの置き方は、結果を読むための条件として残す。
6. **採らない** — 比較した版の違いやシミュレーション側の制約は、導入判断を変える情報なので削除しない。各項目の「測った条件」に短くまとめる。

【企画書】

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

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

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

### 01　店員が来るまで

**どんな現場で：飲食店／実店舗の動画観察**

**何が起きたか**  
店員が対応した動画4例では、直す作業は約1〜10秒、店員が来るまでは約18〜53秒以上でした。通路で向かい合った例では、来るまで41秒以上、直す作業は約5秒でした。

**なぜ止まったか**  
狭い通路で向かい合ったり、待機場所の出口をふさがれたりしていました。ロボットの声や赤い明かりが映っていても、助けが来るまでの時間は、直す時間より長くなっていました。

**測った条件：** 編集された実店舗動画4例の観察。秒数は動画上の概算で、待ち時間には下限を含みます。

**入れる前に確かめること**

- 忙しい時間に止まったら、誰が、何で気づくか。
- 「止まってから人が着くまで」と「着いてから直すまで」を分けて測れるか。

**出典：** [店員が来るまでと直す時間の記録](/record/serving-robot-video-ledger)／[待機場所の横で53秒以上進めなかった動画](/record/serving-robot-jams-are-aisles)

**ハコブくん：**「直すのはすぐです。来てもらうまでが長いんです。」

### 02　2台目で待ちが延びる

**どんな現場で：28卓・スタッフ2人の飲食店／シミュレーション**

**何が起きたか**  
普通の混み具合で、入店待ちは1台の13.8分から、2台では25.1分へ延びました。スタッフがロボットを動かしに行く回数も、13回から54回に増えました。

**なぜ止まったか**  
2台とも近い方の狭い一本道を選び、向かい合ってふさぎ合っていました。「一本道は1台ずつ」にすると2台の入店待ちは17.6分まで縮みましたが、試した改善案でも1台より短くなりませんでした。

**測った条件：** 来客などの条件を変えた10回の中央値。1台と2台ではシミュレーションの版が異なり、この店・人数・運用での比較です。

**入れる前に確かめること**

- 2台目が加わると、どの一本道で出会うか。片方が待てる場所はあるか。
- 運ぶ量だけでなく、人が助けに行く回数と入店待ちも改善するか。

**出典：** [2台目と通行ルールを比べた記録](/record/serving-robot-one-per-narrow-restaurant)／[小さな店に2台を入れた記録](/record/small-store-second-robot-wait)

**ハコブくん：**「同僚が増えたら、店員さんを呼ぶ仕事が増えました。」

### 03　下げ膳中、通路をふさぐ

**どんな現場で：飲食店／シミュレーション**

**何が起きたか**  
6店・1〜2台・各10回の比較では、下げ膳も任せると、スタッフの歩く距離は12条件すべてで減りました。一方、細い通路の2店では2台のとき、退店から卓が使えるまでが4.05分→6.05分、4.49分→8.06分に延びました。

**なぜ止まったか**  
下げ膳のロボットが卓に着き、スタッフを待つあいだに通路をふさいでいました。別の通路があれば回れますが、一本道では、ほかのロボットも人も待たされます。

**測った条件：** 数字は各10回の中央値。各条件1回の比較動画では入店待ちの増減も見られましたが、繰り返し集計とそろわない店があるため、ここでは卓が使えるまでの時間を示しています。

**入れる前に確かめること**

- 皿を載せる人が来ないあいだ、どこで待つか。その横を通れるか。
- 歩く距離が減っても、次のお客さんを座らせるまでが延びていないか。

**出典：** [下げ膳を加えて繰り返し比較した記録](/record/serving-robot-sim-bussing-narrow-aisles)／[6店の比較動画](/record/serving-robot-bussing-depends-on-aisles)

**ハコブくん：**「お皿待ちのつもりが、通せんぼになってました。」

### 04　席は空いているのに案内できない

**どんな現場で：46卓・38卓の飲食店／試算とシミュレーションの比較**

**何が起きたか**  
46卓の店では、0台・1台・2台と増やすと、入店待ちは8.1分→6.6分→5.5分に縮みました。それでも2台のとき、「席は空いているのに待った時間」が46卓の店で3.4分、38卓の店で3.5分残りました。

**なぜ止まったか**  
試算ではレジが詰まっていましたが、3Dの店では、スタッフが歩き回ることで片付けと案内が後回しになる、とログでは見ています。ここで止まっているのは、次のお客さんを迎える仕事です。

**測った条件：** 各10回の中央値。片付けと案内が原因という説明はログの見立てで、当時の再現には瞬間移動などの簡略化も残っていました。

**入れる前に確かめること**

- 運ぶ仕事が減った時間を、誰が片付けと案内に使えるか。
- 満席で待つ時間と、席を使える状態にできず待つ時間を分けているか。

**出典：** [46卓の店で詰まる仕事を調べた記録](/record/large-store-cleanup-bottleneck)／[38卓の店と待機場所を調べた記録](/record/standby-jam-every-store)

**ハコブくん：**「運び終わりました。次のお客さんの席は、まだでした。」

## 通路と待機場所で、抜けられない

### 05　にらみ合い

**どんな現場で：飲食店／実店舗の動画観察とシミュレーション**

**何が起きたか**  
実店舗の動画では、待機場所の横で向かい合った2台が53秒以上進めず、店員が空の方を手でよけて約4〜5秒で解いていました。シミュレーションの42卓・通路95cmの店では、2台が約9分10秒止まった例がありました。

**なぜ止まったか**  
シミュレーションでは、両方が料理を載せている場合などに、どちらが譲るかを決められず、よけた先も相手の道の上でした。実店舗の機体内部の判断は未確認で、ログで調べたメーカーの公開資料でも、どちらが譲るかの具体的な決まりは確認できませんでした。

店員が助ける決まりをシミュレーションに入れると、約9分の例は助け2回・約105秒で解けましたが、同じ台に何度も助けが必要になる問題が残りました。

**測った条件：** 実店舗の観察は同じメーカーの少数例。約9分と約105秒は、シミュレーションの特定条件1回ずつの結果です。

**入れる前に確かめること**

- 荷物を載せた2台が出会ったら、どちらが、どこまで下がるか。何秒待つか。導入元に実演してもらえるか。
- 自力で解けないとき、人が安全に解く手順を実際に試せるか。

**出典：** [実店舗の場面と店員が助ける決まりの比較](/record/serving-robot-faceoff-staff-resolves)／[待機場所の横で向かい合った動画の観察](/record/serving-robot-jams-are-aisles)

**ハコブくん：**「お先にどうぞ。……その先に、ぼくがいます。」

### 06　待機場所へ戻れない

**どんな現場で：70卓・312席の飲食店／シミュレーション**

**何が起きたか**  
入店待ちは2台で11.7分、5台で17.2分でした。別の比較で、待機点へまっすぐ入る決まりにすると、待機場所付近の止まり合いは1営業あたり3,317秒→1,255秒に減りましたが、入店待ちは12.22分→14.90分に延びました。

**なぜ止まったか**  
0.8m間隔の待機点へ斜めに戻ると、隣で待つ台が前のセンサーに入り、止まっていました。人も待機点の区画を通らない形にすると、止まり合いは809秒まで減りました。

**測った条件：** 各10回の中央値。台どうしの順番決めが不足した再現での結果です。待機場所の詰まりが減っても、同じ比較で入店待ちは短くなりませんでした。

**入れる前に確かめること**

- ほかの台が待機しているところへ最後の1台が戻り、また出発できるか。人の通り道と重ならないか。
- 待機場所の停止時間を減らしたあと、片付けや入店待ちまで改善したか。

**出典：** [5台で待ちが延びた記録](/record/large-restaurant-five-serving-robots-longer-wait)／[斜めに戻る入り方を調べた記録](/record/serving-robots-jam-cause-standby-entry)／[人の通り道も変えた記録](/record/serving-robot-jam-three-rules)

**ハコブくん：**「駐車位置は空いてます。入る途中が空いてません。」

### 07　ドリンクバーの横で詰まる

**どんな現場で：飲食店／シミュレーション**

**何が起きたか**  
決まった線だけを走る作りから、地図で道を引く作りに変えても、60秒以上の停止は57回→59回で減りませんでした。さらにドリンクバーを上へ0.5m、左へ0.8m動かして抜け道を作ると、20回になりました。

**なぜ止まったか**  
最初は、同じ線を往復するシミュレーション側の制約がありました。それを外しても、ドリンクバーと席の間が0.4mしかない行き止まりに詰まりが集中しました。道を探せるようにする変更に加えて、抜け道を作る配置の変更が必要でした。

**測った条件：** 同じ店・2台・同じ乱数条件で各1回の比較。57回→20回は、道の引き方と配置の両方を変えた結果です。

**入れる前に確かめること**

- 行き止まりで往復の流れが出会わないか。家具を動かして抜け道を作れるか。
- シミュレーションで詰まった原因は、現場の配置か、再現する側が加えた制約か。

**出典：** [決まった線しか走れなかった作り](/record/serving-robot-fixed-route-jam)／[道の引き方とドリンクバー移動を分けた比較](/record/serving-robot-map-planner)

**ハコブくん：**「地図は読めます。壁の向こうには回れません。」

## 命令や学習の数字が良くても、仕事は終わらない

### 08　動かないのに、記録は成功

**どんな現場で：ロボットアーム／実機 mechArm 270**

**何が起きたか**  
動かなかった記録2本が、台帳では「つかめた・箱に入った」と判定されていました。実機では、肩95.53〜99.22°の姿勢への命令がエラーなしに6回とも動かず、肩を87.27°にして教え直すと5回続けて成功しました。

**なぜ止まったか**  
公式の肩の範囲は−85°〜＋90°ですが、送る側のライブラリはそれより広い範囲を許していました。手で教えると範囲外まで倒せても、その姿勢への命令では動きませんでした。本線にあった肩88°の上限確認も、再生用コードには入っていませんでした。

**測った条件：** 上記の角度での実機試行。88°は本線の設定値で、厳密に確かめた拒否境界ではありません。台帳の成功判定も実際の動きと食い違っていました。

**入れる前に確かめること**

- 教示・再生・本番で、同じ可動範囲の確認が働くか。
- 試験導入の報告にある「成功」は、誰が、何を見て付けたか。1回ずつ動画と照らせるか。

**出典：** [動かなかった角度・教え直し・台帳の誤判定の記録](/record/teach-replay-19-demos)

**ハコブくん：**「ぼくが動くより先に、台帳で成功してました。」

### 09　つかんだのに落とす

**どんな現場で：ロボットアーム／実機 mechArm 270**

**何が起きたか**  
ブロックを落としていた実機で、8か月分の記録は、本体表示40Wに対して24Wの電源を使って取られていました。3,355円の電源へ替えると、同じモデル・爪の設定・位置で成功は3回中1回から5回中5回になりましたが、交換後も1回は人が持ち上げを補助しました。

**なぜ止まったか**  
使っていた電源は12V・2Aで、交換後は12V・5Aです。落とす前に爪の電流が0付近まで下がる記録と、交換後の変化から、ログでは電源不足が原因と判断しています。8か月使った電源は、箱に入っておらず、あとから別送されたものでした。

**測った条件：** 別の日の3回と5回の比較。電圧低下の直接測定はなく、交換後も補助した1回で爪の電流低下が残りました。

**入れる前に確かめること**

- 試験機材の電源と部品は機体の指定に合い、本番と同じ構成か。型番まで照らしたか。
- つかんで静止するだけでなく、持ち上げて運ぶ間も保持できるか。人が補助した回を分けているか。

**出典：** [落とす直前の電流と電源を調べた記録](/record/mecharm-270-drops-block-underpowered-adapter)／[電源交換後の実機比較](/record/mecharm-270-5a-adapter-stops-dropping-block)

**ハコブくん：**「学習のおかわりより先に、電源を見てください。」

### 10　学習の数字は良いのに空振り

**どんな現場で：ロボットアーム／π0.5を使った実機 mechArm 270**

**何が起きたか**  
2,000ステップ学習した実機は4回ともつかむ前に止まり、動画では爪がブロックの上に乗っていました。学習を約4,000ステップに増やし、学習誤差が約0.0057から0.0030に下がっても、実機2回ともブロックの奥で爪を閉じました。

**なぜ止まったか**  
お手本19本は、ブロックをほぼ同じ場所に置いて集めていました。ログでは「いつもの場所へ手を伸ばす」だけでも学習誤差が下がると考え、位置の違うお手本が必要と判断しました。

**測った条件：** 実機は追加学習前4回、追加後2回。その後、5か所で19本のお手本を集めましたが、集め直した後の学習結果は今回の材料に含まれていません。

**入れる前に確かめること**

- 学習に使っていない位置へ対象物を置いても、つかむ場所が変わるか。
- 学習誤差とは別に、つかめた回数、箱まで運べた回数、人が補助した回数を数えているか。

**出典：** [最初の実機試行で爪が乗った記録](/record/pi05-mecharm-first-real-run)／[追加学習しても奥で空振りした記録](/record/pi05-mecharm-4000-steps)

**ハコブくん：**「いつもの場所は覚えました。今日のブロックは、そこですか？」

## 止まりを見つける仕組みも、確かめる

### 11　見張りが見ていたのは、画面の線

**どんな現場で：飲食店／シミュレーションの録画を使った画像検知試験**

**何が起きたか**  
静止画1枚ずつで30秒以上の停止を見つける試験では、誤報5%の条件で、経路線ありは93件中67件（72%）、線なしは94件中26件（28%）を拾いました。線なしでは、ロボットどうしの詰まりを47件中4件しか拾えませんでした。

**なぜ拾えなかったか**  
画像検知は、画面に描かれた道の線が交わる所を手がかりにしていました。その線がない画像では、向かい合う2台と、普段どおり並んで待つ2台を区別しにくくなりました。

**測った条件：** シミュレーション録画で試した一つの検知方法。撮り直しで動きも変わっており、同一場面から線だけを消した比較ではありません。

**入れる前に確かめること**

- 止まりを映像で見張る仕組みを提案されたら、評価に使った映像は、自分の現場のカメラと同じ見え方か。
- 止まった時刻と長さを、機体の記録から取り出せるか。導入元に、その記録を見せてもらえるか。

**出典：** [経路線を消して検知率を測り直した記録](/record/serving-robot-jam-detection-without-path-lines)

**ハコブくん：**「ぼくの困り顔より、道の線を見てたんですね。」

### 12　仮の人の動きで、問題が増える

**どんな現場で：病院の搬送ロボット／シミュレーションで作った仮の病院**

**何が起きたか**  
行き先へ歩いて行けなかった患者・職員41人を通れるようにすると、急停止・ひやり・人によけさせた等の問題が1日84件→132件に増えました。職員の行き先と動き方を直すと132件→68件→19件となり、さらに患者などの動きを補うと51件になりました。

**なぜ止まったか**  
職員141人を「1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動かしていました。付き添いのために通れるようにした場所へ、職員が普段も行くようになり、ロボットと出会う回数が増えていました。

**測った条件：** 主に同じ乱数条件1通りでの比較。件数は衝突事故の数ではなく、19件は患者などの動きを補う前の値です。

**入れる前に確かめること**

- 導入元のシミュレーションでは、職員と患者の動きを何に基づいて置いたか。仮置きの動きを示してもらえるか。
- 問題が減ったとき、必要な人の移動まで減らしていないか。人と荷物が目的地へ着いているか。

**出典：** [外来の廊下を避ける経路の比較](/record/hospital-transport-robot-avoid-outpatient-hall)／[通れる場所を直して問題が増えた記録](/record/hospital-transport-robot-blocked-paths-more-conflicts)／[職員の仮の動きと測り直し](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)

**ハコブくん：**「毎時間くじ引きで出張する病院だとは聞いてません。」

## 自分の現場で、一つ確かめる

2台目を足して入店待ちが延びた店がありました。5台で待機場所の詰まりが増え、道を引く仕組みを変えても停止は減らず、学習を増やしても空振りは続きました。仮の病院では、通れる場所を増やすと問題が増えました。それぞれ今回の条件で起きたことです。

足す判断の前に、どこで仕事が止まり、誰の手が必要になっているかを確かめる。そのために、もう一つ確かめたいのが、**報告にある「成功」と、実際に終わった仕事が一致しているか**です。台帳の成功、学習誤差、画像の検知率だけでは、拾えていない止まりがありました。

自分の現場で気になった項目を一つ選び、試験導入で次の欄を埋めてください。

| 残すこと | 書く内容 |
|---|---|
| 起きた条件 | 場所、混み具合、台数、荷物、人の作業 |
| 待った時間 | 停止、気づき、人の到着、復帰の各時刻 |
| 人がしたこと | 画面操作、移動、積み下ろし、持ち上げなど |
| 仕事の結果 | 届いたか、卓が使えたか、次の人を案内できたか。記録と動画は一致するか |
| 変えて比べること | 台数、配置、通行ルール、待ち方などを一つずつ |

人が手を貸して完了した回は、その手間も含めて導入の結果です。走れた場面に加えて、**止まってから仕事が終わるまで**を残してください。

店の形・人数・台数を変えて考えるには、[配膳ロボットの導入シミュレーション](/series8)へ。

自分の現場で確かめたい止まり方や、共同で検証したい条件は、[メッセージフォーム](/message)へ。
```


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

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

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

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

### 01　店員が来るまで

**どんな現場で：飲食店／実店舗の動画観察**

**何が起きたか**  
店員が対応した動画4例では、直す作業は約1〜10秒、店員が来るまでは約18〜53秒以上でした。通路で向かい合った例では、来るまで41秒以上、直す作業は約5秒でした。

**なぜ止まったか**  
狭い通路で向かい合ったり、待機場所の出口をふさがれたりしていました。ロボットの声や赤い明かりが映っていても、助けが来るまでの時間は、直す時間より長くなっていました。

**測った条件：** 編集された実店舗動画4例の観察。秒数は動画上の概算で、待ち時間には下限を含みます。

**入れる前に確かめること**

- 忙しい時間に止まったら、誰が、何で気づくか。
- 「止まってから人が着くまで」と「着いてから直すまで」を分けて測れるか。

**出典：** [店員が来るまでと直す時間の記録](/record/serving-robot-video-ledger)／[待機場所の横で53秒以上進めなかった動画](/record/serving-robot-jams-are-aisles)

**ハコブくん：**「直すのはすぐです。来てもらうまでが長いんです。」

### 02　2台目で待ちが延びる

**どんな現場で：28卓・スタッフ2人の飲食店／シミュレーション**

**何が起きたか**  
普通の混み具合で、入店待ちは1台の13.8分から、2台では25.1分へ延びました。スタッフがロボットを動かしに行く回数も、13回から54回に増えました。

**なぜ止まったか**  
2台とも近い方の狭い一本道を選び、向かい合ってふさぎ合っていました。「一本道は1台ずつ」にすると2台の入店待ちは17.6分まで縮みましたが、試した改善案でも1台より短くなりませんでした。

**測った条件：** 来客などの条件を変えた10回の中央値。1台と2台ではシミュレーションの版が異なり、この店・人数・運用での比較です。

**入れる前に確かめること**

- 2台目が加わると、どの一本道で出会うか。片方が待てる場所はあるか。
- 運ぶ量だけでなく、人が助けに行く回数と入店待ちも改善するか。

**出典：** [2台目と通行ルールを比べた記録](/record/serving-robot-one-per-narrow-restaurant)／[小さな店に2台を入れた記録](/record/small-store-second-robot-wait)

**ハコブくん：**「同僚が増えたら、店員さんを呼ぶ仕事が増えました。」

### 03　下げ膳中、通路をふさぐ

**どんな現場で：飲食店／シミュレーション**

**何が起きたか**  
6店・1〜2台・各10回の比較では、下げ膳も任せると、スタッフの歩く距離は12条件すべてで減りました。一方、細い通路の2店では2台のとき、退店から卓が使えるまでが4.05分→6.05分、4.49分→8.06分に延びました。

**なぜ止まったか**  
下げ膳のロボットが卓に着き、スタッフを待つあいだに通路をふさいでいました。別の通路があれば回れますが、一本道では、ほかのロボットも人も待たされます。

**測った条件：** 数字は各10回の中央値。各条件1回の比較動画では入店待ちの増減も見られましたが、繰り返し集計とそろわない店があるため、ここでは卓が使えるまでの時間を示しています。

**入れる前に確かめること**

- 皿を載せる人が来ないあいだ、どこで待つか。その横を通れるか。
- 歩く距離が減っても、次のお客さんを座らせるまでが延びていないか。

**出典：** [下げ膳を加えて繰り返し比較した記録](/record/serving-robot-sim-bussing-narrow-aisles)／[6店の比較動画](/record/serving-robot-bussing-depends-on-aisles)

**ハコブくん：**「お皿待ちのつもりが、通せんぼになってました。」

### 04　席は空いているのに案内できない

**どんな現場で：46卓・38卓の飲食店／試算とシミュレーションの比較**

**何が起きたか**  
46卓の店では、0台・1台・2台と増やすと、入店待ちは8.1分→6.6分→5.5分に縮みました。それでも2台のとき、「席は空いているのに待った時間」が46卓の店で3.4分、38卓の店で3.5分残りました。

**なぜ止まったか**  
試算ではレジが詰まっていましたが、3Dの店では、スタッフが歩き回ることで片付けと案内が後回しになる、とログでは見ています。ここで止まっているのは、次のお客さんを迎える仕事です。

**測った条件：** 各10回の中央値。片付けと案内が原因という説明はログの見立てで、当時の再現には瞬間移動などの簡略化も残っていました。

**入れる前に確かめること**

- 運ぶ仕事が減った時間を、誰が片付けと案内に使えるか。
- 満席で待つ時間と、席を使える状態にできず待つ時間を分けているか。

**出典：** [46卓の店で詰まる仕事を調べた記録](/record/large-store-cleanup-bottleneck)／[38卓の店と待機場所を調べた記録](/record/standby-jam-every-store)

**ハコブくん：**「運び終わりました。次のお客さんの席は、まだでした。」

## 通路と待機場所で、抜けられない

### 05　にらみ合い

**どんな現場で：飲食店／実店舗の動画観察とシミュレーション**

**何が起きたか**  
実店舗の動画では、待機場所の横で向かい合った2台が53秒以上進めず、店員が空の方を手でよけて約4〜5秒で解いていました。シミュレーションの42卓・通路95cmの店では、2台が約9分10秒止まった例がありました。

**なぜ止まったか**  
シミュレーションでは、両方が料理を載せている場合などに、どちらが譲るかを決められず、よけた先も相手の道の上でした。実店舗の機体内部の判断は未確認で、ログで調べたメーカーの公開資料でも、どちらが譲るかの具体的な決まりは確認できませんでした。

店員が助ける決まりをシミュレーションに入れると、約9分の例は助け2回・約105秒で解けましたが、同じ台に何度も助けが必要になる問題が残りました。

**測った条件：** 実店舗の観察は同じメーカーの少数例。約9分と約105秒は、シミュレーションの特定条件1回ずつの結果です。

**入れる前に確かめること**

- 荷物を載せた2台が出会ったら、どちらが、どこまで下がるか。何秒待つか。導入元に実演してもらえるか。
- 自力で解けないとき、人が安全に解く手順を実際に試せるか。

**出典：** [実店舗の場面と店員が助ける決まりの比較](/record/serving-robot-faceoff-staff-resolves)／[待機場所の横で向かい合った動画の観察](/record/serving-robot-jams-are-aisles)

**ハコブくん：**「お先にどうぞ。……その先に、ぼくがいます。」

### 06　待機場所へ戻れない

**どんな現場で：70卓・312席の飲食店／シミュレーション**

**何が起きたか**  
入店待ちは2台で11.7分、5台で17.2分でした。別の比較で、待機点へまっすぐ入る決まりにすると、待機場所付近の止まり合いは1営業あたり3,317秒→1,255秒に減りましたが、入店待ちは12.22分→14.90分に延びました。

**なぜ止まったか**  
0.8m間隔の待機点へ斜めに戻ると、隣で待つ台が前のセンサーに入り、止まっていました。人も待機点の区画を通らない形にすると、止まり合いは809秒まで減りました。

**測った条件：** 各10回の中央値。台どうしの順番決めが不足した再現での結果です。待機場所の詰まりが減っても、同じ比較で入店待ちは短くなりませんでした。

**入れる前に確かめること**

- ほかの台が待機しているところへ最後の1台が戻り、また出発できるか。人の通り道と重ならないか。
- 待機場所の停止時間を減らしたあと、片付けや入店待ちまで改善したか。

**出典：** [5台で待ちが延びた記録](/record/large-restaurant-five-serving-robots-longer-wait)／[斜めに戻る入り方を調べた記録](/record/serving-robots-jam-cause-standby-entry)／[人の通り道も変えた記録](/record/serving-robot-jam-three-rules)

**ハコブくん：**「駐車位置は空いてます。入る途中が空いてません。」

### 07　ドリンクバーの横で詰まる

**どんな現場で：飲食店／シミュレーション**

**何が起きたか**  
決まった線だけを走る作りから、地図で道を引く作りに変えても、60秒以上の停止は57回→59回で減りませんでした。さらにドリンクバーを上へ0.5m、左へ0.8m動かして抜け道を作ると、20回になりました。

**なぜ止まったか**  
最初は、同じ線を往復するシミュレーション側の制約がありました。それを外しても、ドリンクバーと席の間が0.4mしかない行き止まりに詰まりが集中しました。道を探せるようにする変更に加えて、抜け道を作る配置の変更が必要でした。

**測った条件：** 同じ店・2台・同じ乱数条件で各1回の比較。57回→20回は、道の引き方と配置の両方を変えた結果です。

**入れる前に確かめること**

- 行き止まりで往復の流れが出会わないか。家具を動かして抜け道を作れるか。
- シミュレーションで詰まった原因は、現場の配置か、再現する側が加えた制約か。

**出典：** [決まった線しか走れなかった作り](/record/serving-robot-fixed-route-jam)／[道の引き方とドリンクバー移動を分けた比較](/record/serving-robot-map-planner)

**ハコブくん：**「地図は読めます。壁の向こうには回れません。」

## 命令や学習の数字が良くても、仕事は終わらない

### 08　動かないのに、記録は成功

**どんな現場で：ロボットアーム／実機 mechArm 270**

**何が起きたか**  
動かなかった記録2本が、台帳では「つかめた・箱に入った」と判定されていました。実機では、肩95.53〜99.22°の姿勢への命令がエラーなしに6回とも動かず、肩を87.27°にして教え直すと5回続けて成功しました。

**なぜ止まったか**  
公式の肩の範囲は−85°〜＋90°ですが、送る側のライブラリはそれより広い範囲を許していました。手で教えると範囲外まで倒せても、その姿勢への命令では動きませんでした。本線にあった肩88°の上限確認も、再生用コードには入っていませんでした。

**測った条件：** 上記の角度での実機試行。88°は本線の設定値で、厳密に確かめた拒否境界ではありません。台帳の成功判定も実際の動きと食い違っていました。

**入れる前に確かめること**

- 教示・再生・本番で、同じ可動範囲の確認が働くか。
- 試験導入の報告にある「成功」は、誰が、何を見て付けたか。1回ずつ動画と照らせるか。

**出典：** [動かなかった角度・教え直し・台帳の誤判定の記録](/record/teach-replay-19-demos)

**ハコブくん：**「ぼくが動くより先に、台帳で成功してました。」

### 09　つかんだのに落とす

**どんな現場で：ロボットアーム／実機 mechArm 270**

**何が起きたか**  
ブロックを落としていた実機で、8か月分の記録は、本体表示40Wに対して24Wの電源を使って取られていました。3,355円の電源へ替えると、同じモデル・爪の設定・位置で成功は3回中1回から5回中5回になりましたが、交換後も1回は人が持ち上げを補助しました。

**なぜ止まったか**  
使っていた電源は12V・2Aで、交換後は12V・5Aです。落とす前に爪の電流が0付近まで下がる記録と、交換後の変化から、ログでは電源不足が原因と判断しています。8か月使った電源は、箱に入っておらず、あとから別送されたものでした。

**測った条件：** 別の日の3回と5回の比較。電圧低下の直接測定はなく、交換後も補助した1回で爪の電流低下が残りました。

**入れる前に確かめること**

- 試験機材の電源と部品は機体の指定に合い、本番と同じ構成か。型番まで照らしたか。
- つかんで静止するだけでなく、持ち上げて運ぶ間も保持できるか。人が補助した回を分けているか。

**出典：** [落とす直前の電流と電源を調べた記録](/record/mecharm-270-drops-block-underpowered-adapter)／[電源交換後の実機比較](/record/mecharm-270-5a-adapter-stops-dropping-block)

**ハコブくん：**「学習のおかわりより先に、電源を見てください。」

### 10　学習の数字は良いのに空振り

**どんな現場で：ロボットアーム／π0.5を使った実機 mechArm 270**

**何が起きたか**  
2,000ステップ学習した実機は4回ともつかむ前に止まり、動画では爪がブロックの上に乗っていました。学習を約4,000ステップに増やし、学習誤差が約0.0057から0.0030に下がっても、実機2回ともブロックの奥で爪を閉じました。

**なぜ止まったか**  
お手本19本は、ブロックをほぼ同じ場所に置いて集めていました。ログでは「いつもの場所へ手を伸ばす」だけでも学習誤差が下がると考え、位置の違うお手本が必要と判断しました。

**測った条件：** 実機は追加学習前4回、追加後2回。その後、5か所で19本のお手本を集めましたが、集め直した後の学習結果は今回の材料に含まれていません。

**入れる前に確かめること**

- 学習に使っていない位置へ対象物を置いても、つかむ場所が変わるか。
- 学習誤差とは別に、つかめた回数、箱まで運べた回数、人が補助した回数を数えているか。

**出典：** [最初の実機試行で爪が乗った記録](/record/pi05-mecharm-first-real-run)／[追加学習しても奥で空振りした記録](/record/pi05-mecharm-4000-steps)

**ハコブくん：**「いつもの場所は覚えました。今日のブロックは、そこですか？」

## 止まりを見つける仕組みも、確かめる

### 11　見張りが見ていたのは、画面の線

**どんな現場で：飲食店／シミュレーションの録画を使った画像検知試験**

**何が起きたか**  
静止画1枚ずつで30秒以上の停止を見つける試験では、誤報5%の条件で、経路線ありは93件中67件（72%）、線なしは94件中26件（28%）を拾いました。線なしでは、ロボットどうしの詰まりを47件中4件しか拾えませんでした。

**なぜ拾えなかったか**  
画像検知は、画面に描かれた道の線が交わる所を手がかりにしていました。その線がない画像では、向かい合う2台と、普段どおり並んで待つ2台を区別しにくくなりました。

**測った条件：** シミュレーション録画で試した一つの検知方法。撮り直しで動きも変わっており、同一場面から線だけを消した比較ではありません。

**入れる前に確かめること**

- 止まりを映像で見張る仕組みを提案されたら、評価に使った映像は、自分の現場のカメラと同じ見え方か。
- 止まった時刻と長さを、機体の記録から取り出せるか。導入元に、その記録を見せてもらえるか。

**出典：** [経路線を消して検知率を測り直した記録](/record/serving-robot-jam-detection-without-path-lines)

**ハコブくん：**「ぼくの困り顔より、道の線を見てたんですね。」

### 12　仮の人の動きで、問題が増える

**どんな現場で：病院の搬送ロボット／シミュレーションで作った仮の病院**

**何が起きたか**  
行き先へ歩いて行けなかった患者・職員41人を通れるようにすると、急停止・ひやり・人によけさせた等の問題が1日84件→132件に増えました。職員の行き先と動き方を直すと132件→68件→19件となり、さらに患者などの動きを補うと51件になりました。

**なぜ止まったか**  
職員141人を「1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動かしていました。付き添いのために通れるようにした場所へ、職員が普段も行くようになり、ロボットと出会う回数が増えていました。

**測った条件：** 主に同じ乱数条件1通りでの比較。件数は衝突事故の数ではなく、19件は患者などの動きを補う前の値です。

**入れる前に確かめること**

- 導入元のシミュレーションでは、職員と患者の動きを何に基づいて置いたか。仮置きの動きを示してもらえるか。
- 問題が減ったとき、必要な人の移動まで減らしていないか。人と荷物が目的地へ着いているか。

**出典：** [外来の廊下を避ける経路の比較](/record/hospital-transport-robot-avoid-outpatient-hall)／[通れる場所を直して問題が増えた記録](/record/hospital-transport-robot-blocked-paths-more-conflicts)／[職員の仮の動きと測り直し](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)

**ハコブくん：**「毎時間くじ引きで出張する病院だとは聞いてません。」

## 自分の現場で、一つ確かめる

2台目を足して入店待ちが延びた店がありました。5台で待機場所の詰まりが増え、道を引く仕組みを変えても停止は減らず、学習を増やしても空振りは続きました。仮の病院では、通れる場所を増やすと問題が増えました。それぞれ今回の条件で起きたことです。

足す判断の前に、どこで仕事が止まり、誰の手が必要になっているかを確かめる。そのために、もう一つ確かめたいのが、**報告にある「成功」と、実際に終わった仕事が一致しているか**です。台帳の成功、学習誤差、画像の検知率だけでは、拾えていない止まりがありました。

自分の現場で気になった項目を一つ選び、試験導入で次の欄を埋めてください。

| 残すこと | 書く内容 |
|---|---|
| 起きた条件 | 場所、混み具合、台数、荷物、人の作業 |
| 待った時間 | 停止、気づき、人の到着、復帰の各時刻 |
| 人がしたこと | 画面操作、移動、積み下ろし、持ち上げなど |
| 仕事の結果 | 届いたか、卓が使えたか、次の人を案内できたか。記録と動画は一致するか |
| 変えて比べること | 台数、配置、通行ルール、待ち方などを一つずつ |

人が手を貸して完了した回は、その手間も含めて導入の結果です。走れた場面に加えて、**止まってから仕事が終わるまで**を残してください。

店の形・人数・台数を変えて考えるには、[配膳ロボットの導入シミュレーション](/series8)へ。

自分の現場で確かめたい止まり方や、共同で検証したい条件は、[メッセージフォーム](/message)へ。
```


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

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

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

---

## 1. 店員が来るまで
- **どんな現場で**：実店舗の動画
- **何が起きたか**：実店舗の動画で店員が対応した3例では、直す作業は約1〜10秒で済むのに、店員が来るまでは約18秒、41秒以上、45秒以上かかっていました。
- **なぜ止まったか**：ロボットの声かけと赤い明かりは来店客向けの合図であり、店員の手元の端末に知らせが届いた様子はどの動画にも映っていなかったためと推測されます。
- **入れる前に確かめること**：ロボットが止まったとき、誰の端末に、どう通知が来る仕組みになっていますか？
- **出典**：[serving-robot-video-ledger](/record/serving-robot-video-ledger)
- **ハコブくんの一言**：「赤いランプ光らせて助けを呼んでるんですけど、お客さんにしか見えてないみたいです」

## 2. にらみ合い
- **どんな現場で**：実店舗の動画・シミュレーション
- **何が起きたか**：実店舗の動画では、狭い通路や待機場所の横で向かい合った2台が自力で抜けられず、店員が片方を手でよけていました。
- **なぜ止まったか**：メーカーの取扱説明書にはロボットどうしの譲り合いの決まりが公開されておらず、シミュレーションでも互いによけ先が相手の道の上になると解決できませんでした。
- **入れる前に確かめること**：通路で2台が向かい合ったとき、どちらがどう譲る仕様になっていますか？
- **出典**：[serving-robot-faceoff-staff-resolves](/record/serving-robot-faceoff-staff-resolves) / [serving-robot-jams-are-aisles](/record/serving-robot-jams-are-aisles)
- **ハコブくんの一言**：「『お先にどうぞ』って言えないんで、とりあえず見つめ合ってます」

## 3. 2台目が待ちを延ばす
- **どんな現場で**：シミュレーション
- **何が起きたか**：28卓・スタッフ2人の店では、1台のときの入店待ち13.8分に対し、2台にすると25.1分と約2倍に延びました。
- **なぜ止まったか**：狭い通路（約1.1m）でロボットどうしが向かい合ってふさぎ合ったためです。試した改善案でも、この店では2台は1台より待ち時間が短くなりませんでした。
- **入れる前に確かめること**：今の通路幅で2台入れたとき、すれ違えない場所が何箇所ありますか？
- **出典**：[serving-robot-one-per-narrow-restaurant](/record/serving-robot-one-per-narrow-restaurant) / [small-store-second-robot-wait](/record/small-store-second-robot-wait)
- **ハコブくんの一言**：「後輩が入ってきたら、道が狭くて余計に渋滞しちゃいました」

## 4. 待機場所の止まり合い
- **どんな現場で**：シミュレーション
- **何が起きたか**：大型店で5台に増やすと、待機場所付近での止まり合いが増えました。まっすぐ入る変更で詰まりの時間は減りましたが、同じ比較で入店待ちは短くなりませんでした。
- **なぜ止まったか**：大きな原因の一つは、斜めに戻る台のセンサー（中心から0.85m）に、隣の待機台が入ってしまうことでした。
- **入れる前に確かめること**：待機場所の間隔は、ロボットが斜めから戻ってきても隣のセンサーが反応しない広さがありますか？
- **出典**：[large-restaurant-five-serving-robots-longer-wait](/record/large-restaurant-five-serving-robots-longer-wait) / [serving-robots-jam-cause-standby-entry](/record/serving-robots-jam-cause-standby-entry) / [serving-robot-jam-three-rules](/record/serving-robot-jam-three-rules)
- **ハコブくんの一言**：「斜めから帰ると、お隣さんにぶつかりそうって怒られるんです」

## 5. 下げ膳で詰まる
- **どんな現場で**：シミュレーション
- **何が起きたか**：6店でロボット2台を各条件1回ずつ録画した比較では、通路にゆとりのある3店で入店待ちが縮み、効率重視の細い3店では延びました。
- **なぜ止まったか**：下げ膳のロボットが卓に着いてスタッフを待つ間、通路が1本ふさがり、他のロボットやスタッフが回り道や待機を強いられるためです。
- **入れる前に確かめること**：下げ膳でロボットを卓に留まらせたとき、他のスタッフやロボットが通れる迂回路はありますか？
- **出典**：[serving-robot-sim-bussing-narrow-aisles](/record/serving-robot-sim-bussing-narrow-aisles) / [serving-robot-bussing-depends-on-aisles](/record/serving-robot-bussing-depends-on-aisles)
- **ハコブくんの一言**：「お皿下げるの待ってる間、僕の後ろ大渋滞なんですけど…」

## 6. 詰まるのは片付け
- **どんな現場で**：シミュレーション
- **何が起きたか**：46卓・38卓の店では、ロボットを増やすと入店待ちは縮みましたが、席が空いていても待つ時間が残りました。
- **なぜ止まったか**：スタッフが歩き回るぶん手がふさがり、後回しになる片付けと案内が追いつかず、仕事全体が滞っていたためです。
- **入れる前に確かめること**：配膳を自動化しても、片付けと案内のスタッフの手は足りていますか？
- **出典**：[large-store-cleanup-bottleneck](/record/large-store-cleanup-bottleneck) / [standby-jam-every-store](/record/standby-jam-every-store)
- **ハコブくんの一言**：「僕が運んでも、片付ける人がいないと席は空かないですよ」

## 7. 線に縛ると詰まる
- **どんな現場で**：シミュレーション
- **何が起きたか**：決まった線だけを走る作りから「地図で道を引く」変更をしても、60秒以上の停止は57回から59回と減りませんでした。さらにドリンクバーを移して抜け道を作ると20回になりました（各1回の比較）。
- **なぜ止まったか**：最短経路を共用する設定に加え、物理的な行き止まり（ドリンクバーと席の間が0.4m）があったためです。
- **入れる前に確かめること**：よく通るルート上に、物理的な行き止まりや「抜け道のない場所」はありませんか？
- **出典**：[serving-robot-fixed-route-jam](/record/serving-robot-fixed-route-jam) / [serving-robot-map-planner](/record/serving-robot-map-planner)
- **ハコブくんの一言**：「賢く道を引けるようになっても、物理的に行き止まりじゃ抜けられません」

## 8. 直したら問題が増えた
- **どんな現場で**：シミュレーション（仮の病院）
- **何が起きたか**：通れなかった患者や職員を通れるように直すと、急停止やひやりなどの問題が1日84件から132件に増えました。
- **なぜ止まったか**：通行可能な場所を、職員の普段の行き先（シミュレーション内の仮の決まり）にも使うようになったためです。
- **入れる前に確かめること**：ロボットの経路を変えたとき、そこを通る人間の「普段の動線」とぶつかりませんか？
- **出典**：[hospital-transport-robot-avoid-outpatient-hall](/record/hospital-transport-robot-avoid-outpatient-hall) / [hospital-transport-robot-blocked-paths-more-conflicts](/record/hospital-transport-robot-blocked-paths-more-conflicts) / [hospital-transport-robot-conflicts-came-from-placeholder-staff-moves](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)
- **ハコブくんの一言**：「人間さんが通りやすい道は、僕にとっても事故が起きやすい道なんです」

## 9. 映像からは見つからない
- **どんな現場で**：シミュレーションの録画
- **何が起きたか**：録画から切り出した画像1枚で長い停止を検出する試験では、画面の経路線ありは72%拾えましたが、線なしでは28%に落ちました。
- **なぜ止まったか**：画像AIは画面に描かれた「道の線の交差」を手がかりにしており、実際のカメラには映らない線がないと、待機中の姿と区別がつかないためです。
- **入れる前に確かめること**：カメラ映像だけで「異常な停止」と「通常の待機」をシステムは区別できますか？
- **出典**：[serving-robot-jam-detection-without-path-lines](/record/serving-robot-jam-detection-without-path-lines)
- **ハコブくんの一言**：「防犯カメラから見たら、サボってるのか待機中なのか分かんないですよね」

## 10. まさかの電源不足
- **どんな現場で**：実機（ロボットアーム）
- **何が起きたか**：ブロックを落としていたアームの電源を12V・2Aから12V・5Aへ替えると、5回とも落とさず成功しました（うち1回は人が補助し、電流低下も残りました）。
- **なぜ止まったか**：本体が求める40Wに対し、8ヶ月間使っていた別送のアダプターが24Wしかなく、つかんだ後に爪の電流が落ちていたためと推測されます。
- **入れる前に確かめること**：AIの精度を疑う前に、ハードウェアに規定通りの電力が供給されていますか？
- **出典**：[mecharm-270-drops-block-underpowered-adapter](/record/mecharm-270-drops-block-underpowered-adapter) / [mecharm-270-5a-adapter-stops-dropping-block](/record/mecharm-270-5a-adapter-stops-dropping-block)
- **ハコブくんの一言**：「ご飯（電力）が足りなくて、握力が抜けちゃうんです」

## 11. 命令が黙って捨てられる
- **どんな現場で**：実機（ロボットアーム）
- **何が起きたか**：肩95.53〜99.22°の姿勢への命令が、エラーなしに6回とも動かず、台帳には「成功」と記録されていました。肩87.27°で教え直すと5回続けて成功しました。
- **なぜ止まったか**：本線では肩88°以内の姿勢を選ぶ設定にしていましたが、手で教える際は99°まで倒せてしまい、範囲外の命令がエラーを返さずアーム側で無視されていたためです。
- **入れる前に確かめること**：ロボットが動かなかったとき、システム上は「成功」として処理されていませんか？
- **出典**：[teach-replay-19-demos](/record/teach-replay-19-demos)
- **ハコブくんの一言**：「できない姿勢を命令されたんで無視しました。記録には『成功』って書いときますね」

## 12. 学習の数字は良いのに外れる
- **どんな現場で**：実機（ロボットアーム）
- **何が起きたか**：学習を増やし、学習の誤差（loss）が0.0030まで下がっても、実機は2回ともブロックの奥で爪を閉じ、つかめませんでした。
- **なぜ止まったか**：お手本がほぼ同じ場所のものばかりで、画像を細かく見なくても「いつもの場所へ手を伸ばす」だけで誤差の数字が下がっていたためです。
- **入れる前に確かめること**：シミュレーションやAIの「学習の数字」は、現場の様々なパターンの前でも通用する数字ですか？
- **出典**：[pi05-mecharm-first-real-run](/record/pi05-mecharm-first-real-run) / [pi05-mecharm-4000-steps](/record/pi05-mecharm-4000-steps)
- **ハコブくんの一言**：「テストの点数は良かったんですけど、本番の応用問題は解けませんでした」

---

## 導入を「実験」で終わらせないために

12の記録は、「運用と複数台の罠（1〜6）」「環境と監視の落とし穴（7〜9）」「AIとハードウェアの壁（10〜12）」の順に並べました。
多くの場合、ロボットそのものは壊れていません。止めていたのは、通路の幅・行き止まり・人の動かし方と人手・電源や角度の上限です。

世の中では、「AIの精度だけを成功条件にすると、運用要件が抜け落ち、導入実験（PoC）から本番導入へ移行できない原因になる」（Web記事、2026年7月1日）と指摘されています。
「直す作業は数秒なのに、気づくまでは数十秒かかる」「エラーを出さずに黙って止まる」「学習の誤差は下がるのに外れる」。これらはすべて、止まったことが「数字や画面に出てこない」種類のトラブルです。

現場で本当に確かめるべきは、「カタログの数字」ではなく「何を測れば気づけるか」という運用と物理の仕組みです。足せば良くなるという思い込みを捨て、どこが詰まりの元かを測ってから足す。それが、ロボットを現場で生かすための順番です。

## 終わりに：次にすること

まずは、この記事の「入れる前に確かめること」を、あなたの現場に当てはめてみてください。
もし、自社の環境でどう動くかを導入前に確かめたい、あるいは現在起きている「原因不明の止まり」を検証したいとお考えなら、私たちにご相談ください。

[メッセージを送る（/message）](/message)
```


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

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

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

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

---

## 指摘1　冒頭の3行と並べ方：結論を先頭に移す

**問題**
- 「見落とされた物理法則」は、ログにない言い方です。
- 「カタログには『障害物を避けて走る』と書かれていますが」は出典がありません。Gemini の材料もすべて「未確認」です。
- 数字が1つもなく、読む人が何を持ち帰れるのかが分かりません。
- 並べ方が依頼の表の順のままです。依頼は「いちばん刺さる順」でした。

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

**並べ方の案**（まとめの節にある作者自身の3つの見立てを、そのまま見出しに使います）
1. **止まっても気づけない**：1 → 11 → 12 → 9
2. **壊れていないのに止まる**：2 → 10 → 7 → 6
3. **足すと・直すと悪くなる**：3 → 4 → 5 → 8

それぞれのまとまりで、実店舗と実機の項目を先に置きます。シミュレーションだけの3は、最後のまとまりに回します。

## 指摘2　いちばん刺さる1は、問いを「数えること」に変える

「誰の端末に通知が来るか」は営業担当に聞けば済む問いです。この項目にしかない価値は、**待っている時間と直す時間の差**にあります。

> **何が起きたか**：実店舗の動画で店員が対応した3例では、直す作業は約1〜10秒でした。店員が来るまでは約18秒、41秒以上、45秒以上かかっています。1本目は、待った時間と直した時間の比が8対1以上でした（動画は編集されているため、秒数は下限です）。
> **入れる前に確かめること**：試しに入れている間、止まってから店員が来るまでの秒数を数えてください。直す作業との差が、お客さんから見たロボットの止まり時間です。止まったという知らせは、店員の手元に届く仕組みですか。

ハコブくんの一言は今のままで十分よいです。

## 指摘3　いちばん弱い6は、試算と実際の差を数字で示す

ログで新しいのは「片付けが大事」という話ではなく、**計算ではレジが詰まるはずだったのに、動かしてみたら片付けと案内が詰まっていた**という点です。導入の効果を試算する経営者には、そのまま効きます。

> **名前**：計算ではレジ、実際は片付け
> **どんな現場で**：シミュレーション（Unity の46卓の店、スタッフ4人）
> **何が起きたか**：表計算の試算では、ロボット2台のとき「席は空いているのに待つ時間」は0.7分でした。同じ店を Unity で動かすと3.4分です（約5倍。ログの数字から計算）。ロボットを0→1→2台と足すと、入店待ちは8.1→6.6→5.5分と縮みました。それでも、この待ちは残りました。
> **なぜ止まったか**：試算では、食べ終えたお客さんが卓に座ったままレジを待つので、レジが詰まります。3Dの店では、スタッフが歩き回るぶん手がふさがり、後回しになった片付けがたまっていました（③⑦では1組あたりの仕事が試算より約1割長い）。
> **入れる前に確かめること**：導入の効果を見積もった計算には、スタッフが歩く時間が入っていますか。ピークの時間に、空いているのに案内できない卓が何卓あるか数えてください。
> **ハコブくん**：「計算ではレジが混むはずだったんですけど、実際は片付け待ちでした」

## 指摘4　11と12：同じ問題の2つの顔として、事実を正して強くする

**11の事実のずれ**
- 「6回とも動かず、台帳には『成功』と記録」と書くと、6回すべてが成功と記録されたように読めます。ログでは、成功と記録されたのは**動いていない2本**です。
- ハコブくんの「記録には『成功』って書いときますね」は、ロボットが記録を書き換えたように読めます。直します。
- いちばん持ち帰れる原因が抜けています。**命令を送るソフトが確かめる範囲と、機体が動ける範囲がずれていた**ことです。

> **何が起きたか**（11）：肩95.53〜99.22°へ降りる命令を6回送り、6回とも動きませんでした。エラーは出ず、動いたのは最大1.50°で、止まっているときの揺れと同じくらいです。しかも、動いていない2本は台帳に「つかめた・箱に入った」と記録されていました。
> **なぜ止まったか**：メーカー公式の肩の範囲は−85°〜+90°です。送る側のライブラリは±190°でしか確かめないため、範囲外の命令もそのまま届き、アーム側で黙って捨てられていました。手で教えるときはモーターの力が抜けているので、人は99°まで倒せてしまいます。
> **入れる前に確かめること**：命令を送るソフトが確かめる範囲は、機体が動ける範囲と同じですか。「成功」という記録は、実際に動いたことを何で確かめていますか（映像、角度の記録）。
> **ハコブくん**：「できない角度だったので、黙って動きませんでした。エラーを出す決まりはなかったので」

**12の問いの誤り**
「シミュレーションや AI の学習の数字」と書かれていますが、loss はシミュレーションの数字ではありません。

> **入れる前に確かめること**：お手本や試験は、置き場所を変えた場面を含んでいますか。学習の数字ではなく、置き場所を変えた実機での成功回数で判断していますか。
> **何が起きたか**に足す一文：学習を2倍にしても、手を伸ばす先は変わりませんでした。足りないのは学習の回数ではなく、ブロックの位置が違うお手本でした。

## 指摘5　10は「推測」ではない。3,355円と8か月を書く

LOG487 の時点では推測でしたが、LOG504 で**差し替えて確かめて**います。経営者の記憶に残るのは、金額と期間です。

> **何が起きたか**：つかんでから11〜19秒後に爪の電流が0付近まで落ち、ブロックを落としていました（17本中12本）。電源を12V・2A から12V・5A（3,355円）に替えると、同じ AI・同じ条件で、成功は3回中1回から5回中5回に、人の手直しは3回中3回から5回中1回になりました。
> **なぜ止まったか**：本体が求める電源は40W です。つないでいたのは外付けディスク用の12V・2A（24W）で、6割しかありませんでした。アダプターは箱に入っておらず別送で、8か月分の実機の記録はすべてこの電源で取っていました。差し替えて確かめましたが、電圧そのものは測っていません。
> **入れる前に確かめること**：届いた機体の電源の出力（W）は、説明書の値に足りていますか。箱に入っていなかった部品を、手元のもので代わりにしていませんか。
> **ハコブくん**：「8か月、腹ぺこで働いてました。3,355円でやっと満腹です」

## 指摘6　シミュレーションの4・5・7は、いちばん確かな数字に入れ替える

**7：名前と中身が合っていない**
今の本文は「地図を渡しても減らなかった」と書いているので、名前の「線に縛ると詰まる」と食い違います。

> **名前**：ドリンクバーの横の行き止まり
> **何が起きたか**：同じ店で道の引き方を賢くしても、60秒の止まりは57→59回で減りませんでした。59回のうち43回は、ドリンクバーと6人席の間（0.4m）の行き止まりに集まっていました。ドリンクバーを上へ0.5m、左へ0.8m動かすと20回になり、ロボットが運んだ割合は64.4→99.4%、料理の待ちは2.90→1.17分になりました（どれも1回ずつの比較）。
> **入れる前に確かめること**：止まった場所を記録して地図に落とすと、どこかに集まっていませんか。そこにある家具は動かせますか。

**4：減ったものと、延びたものを両方書く**
「短くならなかった」は弱めすぎです。

> **何が起きたか**：大型店で5台にすると入店待ちが17.2分に延びました。ただしログは、Unity のロボットに台どうしの順番決めがないことが大きく出た結果としています。待機点へ真下1.0m からまっすぐ入る決まりにすると、待機場所の止まり合いは3,317秒から1,255秒に減りました。一方、この変更だけでは入店待ちは12.22→14.90分に延びています。さらに人が待機点の区画を通らないようにすると、止まり合いは809秒、店員が呼ばれる回数は180→22回になりました。
> **入れる前に確かめること**：待機点どうしの間隔は何m ですか。ロボットの前のセンサーが届く距離（このシミュレーションでは中心から0.85m。待機点どうしの間隔は0.8m）より広いですか。

**5：各1回の録画ではなく、10種の中央値で言えることだけを使う**

> **何が起きたか**：6店、1〜2台、10種で計120回を回しました。スタッフの歩く距離は、12条件すべてで減りました。一方、通路の細い店で2台のときは、お客さんが帰ってから卓が使えるまでの時間が、③で4.05→6.05分、⑦で4.49→8.06分（約1.8倍）に延びました。
> **入れる前に確かめること**：下げ膳のロボットが卓で待つあいだ、その通路を人が回り道できますか。卓が空くまでの時間を、入れる前と後で測っていますか。

## 指摘7　8は、話の後半がいちばん大事

84→132件で止めると、読む人は「病院の動線は危ない」と受け取ります。ログが伝えているのは、**ロボットの問題の件数は、人の動きをどう置いたかで何倍にも変わる**ということです。シミュレーションの数字を見せられる立場の経営者にとって、いちばん効く話です。

ハコブくんの「事故が起きやすい道」は事実と違います。止まりきれなかったのは132件中10件で、増えた原因は仮に置いた職員の動きでした。

> **何が起きたか**：通れなかった41人を通れるように直すと、ロボットの問題（急に止まった・ひやり など）は1日84件から132件に増えました。増えた48件のうち37件は大廊下の東の端で起き、相手はほとんどが職員でした。シミュレーションの職員141人は、「1時間に1回、くじ引きで選んだ部屋へ行って戻る」という仮の決まりで動いていました。行き先を持ち場に限ると68件、持ち場ごとの4つの型にすると19件になりました。その後、患者の動きを入れると51件です（主に種0の1回の比較で、種によって大きくぶれます）。
> **入れる前に確かめること**：シミュレーションや試験運用で示された「ロボットの問題○件」は、人の動きをどう決めて数えたものですか。
> **ハコブくん**：「僕のひやりの大半は、くじ引きで部屋を選ぶ仮の職員さんが相手でした」

## 指摘8　終わりの節：出典のない引用と、相談の呼びかけを外す

- 「Web記事、2026年7月1日」は、どのサイトか書かれていないので出典になりません。このページは自分で測った数字だけで十分強いので、削ります。
- 「思い込みを捨て」は読む人を説教する言い方です。事実の数え上げに替えます。
- 「私たちにご相談ください」と「原因不明の止まりを検証」は、相談の窓口を2行に広げています。決まりは最後に1行です。

> 12のうち5つは、足したり直したりして、悪くなったか変わらなかった記録です（2台目、5台目、学習の回数、道の引き方、通れる所を直す）。どこで詰まっているかを数えてから足す、という順番が、12の記録に共通しています。
>
> 次にすること：各項目の「入れる前に確かめること」のうち、待機点の間隔（4）と、止まりが集まる場所（7）は、入れる前から測れます。止まってから店員が来るまで（1）は、試しに入れている間に数えられます。シミュレーションの店の作りは、各項目の /record/ から見られます。
>
> 自分の現場の数字で確かめたいときは、[/message](/message) に1行どうぞ。
```


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

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

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

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

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

「段差や幅よりも」は比較した根拠がありません。「見落とされた物理法則」も、電源や角度制限という具体的な発見をぼかします。「カタログには載っていない」という一括した断定も不要です。

**冒頭3行の差し替え案：**

> 実店舗の動画、シミュレーション、実機で見つけた、12の「止まる瞬間」を集めました。  
> 直す時間より店員を待つ時間が長い。止まり合いを減らしても入店待ちは縮まらない。動いていないのに記録は成功になる。  
> それぞれの記録から、自分の現場で何を試し、何を分けて測るかを持ち帰れます。

終盤の出典を特定できない「Web記事、2026年7月1日」の引用も削ってよいです。このページの必要性は、ログ自身で示せます。

### 2. ①②は「通知や仕様を聞く」から「止まってから復帰するまでを測る」へ

①の動画に通知が映っていないことは、通知がなかった証拠ではありません。また、①②は原因の説明と観察できた事実を分けるべきです。説明書に譲り合いの記載がないことも、譲り合う機能がない証拠にはなりません。

**①「なぜ止まったか」の差し替え案：**

> 向かい合った台どうしや、待機場所で出口をふさがれた台が、その場から進めなくなっていました。店員が来るまで時間がかかった理由は、動画だけでは確定できません。店員の端末への通知は画面では確認できませんでした。

**①②の問いの差し替え案：**

> 自分の現場で停止から復帰までを測ると、「店員が来るまで」と「来てから直すまで」は、それぞれ何秒ですか？  
> 2台が向かい合う場面を試すと、自力で抜けられますか。人が必要なら、誰がどう動かすと復帰しますか？

①の一言も、未確認の通知事情を断定せず、こうできます。

> 「直してもらうのは数秒。来てもらうまでが長いんです」

### 3. ③⑤⑥は「人の仕事が減る」と「客の待ちが減る」を分けて強くする

③の通路幅、⑤の迂回路、⑥の人手という問いだけでは、一般的な環境確認で終わります。この3項目の価値は、**歩行距離・入店待ち・卓の再利用までの時間が、同じ方向には改善しないこと**です。

③には比較の版の違いを添え、「約2倍」より実数を主役にします。

> Unityの28卓・スタッフ2人の店では、入店待ちの中央値が1台13.8分、2台25.1分でした。試した改善案でも2台は1台より短くなりませんでした。ただし、1台と2台の比較には版の違いが残ります。

⑤は各1回の映像による店の分類より、繰り返し集計の数字を前へ。

> Unityの6店・計120回の比較では、スタッフの歩く距離は12条件すべてで減りました。一方、2台で下げ膳も任せると、退店から卓が再び使えるまでの中央値が、店③では4.05分から6.05分、店⑦では4.49分から8.06分に延びました。

⑥には、2台でも残った待ちを入れます。

> Unityの46卓・38卓の店では、ロボット2台で入店待ちは縮みましたが、席が空いていても待つ時間が、それぞれ中央値で3.4分・3.5分残りました。

**持ち帰る問い：**

> 増台や下げ膳の追加で、スタッフの歩く距離は減りましたか。同じ条件で、入店待ちと退店から卓が使えるまでの時間はどう変わりましたか？

### 4. ④⑦は「直した方法」より「直っても改善しなかった数字」を見せる

④は数字を落としたため、いちばん面白い逆転が弱くなっています。⑦も、見出しが最初の問題にとどまり、地図だけでは解けなかった発見を隠しています。

**④「何が起きたか」の差し替え案：**

> Unityの大型店・5台の条件で、待機点へまっすぐ戻る決まりに変えると、待機場所付近の詰まりは3,317秒から1,255秒に減りました。一方、同じ比較の入店待ちは12.22分から14.90分に延びました。台どうしの順番決めが不足する、シミュレーションの作りも影響しています。

**④の問い：**

> 待機場所の止まり合いを減らしたとき、入店待ちも縮んでいますか。それぞれを別に測っていますか？

⑦の名前は **「地図を渡しても抜けられない」**へ。本文の57→59→20回は残し、問いを具体化します。

> 道の引き方だけを変えた場合と、設備を動かして抜け道を作った場合で、止まり方はどう変わりますか？

「隣のセンサーが反応しない広さ」を求めるより、実際の戻り方・止まり方を試す問いの方が判断に効きます。

### 5. ⑧は「病院の動線に注意」から「検証に使う人の動きを確かめる」へ直す

ここが最も弱い項目です。ログで変えた中心は人の通行可能範囲と動きの決まりなのに、問いでは「ロボットの経路を変えたとき」になっています。ハコブくんの「事故が起きやすい道」も、急停止やひやりなどの件数を事故へ広げています。

**差し替え案：**

> **名前：人の動きを仮置きしたら**  
> **何が起きたか：** Unityの仮の病院で、通れなかった患者・職員を通すと、急停止やひやりなどの問題が84件から132件に増えました。職員は「1時間に1回、くじで選んだ部屋へ行く」という仮の決まりで動いていました。  
> **なぜ止まったか：** 通れるようにした場所を、職員が普段の行き先としても使う決まりになり、ロボットとの交錯が増えていました。  
> **確かめること：** 導入判断に使うシミュレーションの職員は、誰の観察をもとに、どこへ、何の仕事で移動していますか？  
> **一言：** 「職員さんの行き先、くじで決めてたんですか」

これなら、現場の失敗談に見せず、**検証結果を信用する前の確認点**として価値が立ちます。

### 6. ⑨は「映像の限界」ではなく「試験用の表示を拾っていた」に絞る

「映像からは見つからない」は広すぎます。また、線あり・なしは撮り直した映像なので、同一場面から線だけを除いた比較としては扱えません。

**差し替え案：**

> **名前：道の線を消すと拾えない**  
> Unity録画の切り出し画像1枚を使う検出試験では、誤報5%の条件で、30秒以上の停止を拾えた割合は経路線あり72%、線なし28%でした。撮り直しで動きも変わっており、同一場面の比較ではありません。実店舗のカメラ性能を測った値でもありません。

**問いの差し替え案：**

> 停止の検出試験に、本番の映像にはない経路線などの表示が入っていませんか？ 止まった長さを、機体の記録とも照合していますか？

「カメラで区別できますか」より、試験をやり直す条件が明確になります。

### 7. ⑩は「電源を確認」では弱い。人の補助と落下を別に数える問いにする

「規定通りの電力ですか」は一般的な点検項目です。この記録の価値は、交換前後の結果と、交換後も補助が残ったことです。

**「何が起きたか」の差し替え案：**

> 実機mechArm 270で、同じモデル・位置5・爪を閉じる設定を使った試行は、電源交換前が3回中1回成功、12V・5Aへの交換後が5回中5回成功でした。交換後は落としませんでしたが、1回は人が持ち上げを補助しました。比較した日は異なります。

**問いの差し替え案：**

> AIの学習条件を変える前に、つかんだ後やアームが動き出す瞬間の爪の電流を記録していますか？ 「落とさなかった回数」と「人の補助なしで完了した回数」を分けていますか？

電圧低下を直接測っていない点を保ち、原因説明は「電源容量不足が疑われ、交換後に落下がなくなった」とするのが強くて正確です。

### 8. ⑪を前へ置き、⑫と結び、最後に記録の取り方を持ち帰らせる

⑪は「6回とも動かず、台帳には成功」と続くため、6回すべて成功と記録されたように読めます。材料で確認できる誤記は2本です。一言も、ロボット自身が成功を書いたようにせず、記録とのずれを突く方が効きます。

**⑪の差し替え案：**

> 肩95.53〜99.22°の姿勢への命令は、エラーなしに6回とも動きませんでした。さらに、動いていない記録2本が、台帳では「つかめた・箱に入った」と判定されていました。肩87.27°で教え直すと5回続けて成功しました。

> 「僕は動いてないのに、台帳では仕事が終わってます」

⑫の「なぜ」は実証済みの原因として断定せず、見立てにします。

> お手本19本はブロックの位置がほぼ同じでした。ログでは、画像を細かく見ずにいつもの場所へ手を伸ばしても学習誤差を下げられたのではないか、と見ています。

問いも「様々なパターンで通用しますか」から絞ります。

> お手本を集めた位置からブロックをずらしても、実機でつかめますか？ 学習誤差とは別に、その成否を記録していますか？

並びは①の次に⑪⑩⑫を置くと、「待っている時間が見えない」から「失敗が成功になる」「数字が良くてもつかめない」へ、読む理由が早く立ちます。

最後の一般的な助言は、次の行動へ置き換えられます。

> 自分の現場に近い止まり方を一つ選び、導入試験の記録にしてください。「どの条件で起きたか」「止まってから人が来るまで」「人が直す時間」「人の補助なしで仕事が終わったか」を残します。通路や台数を変える試験では、止まりの時間と、お客さんの待ち時間も分けて比べてください。  
> 自分の現場での確かめ方を一緒に検討したい方は、[メッセージフォーム](/message)へ。

この形なら、図鑑を読んだ人に残るのは注意事項だけでなく、**次の導入試験で使える記録項目**です。
```


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

```markdown
【採否】
A1: 採る。事実に基づかない煽りを削り、結論を先頭に置いて刺さる構成にするため。
A2: 採る。経営者が現場で実践できる具体的な「測り方」を持ち帰れるようにするため。
A3: 採る。試算と実際の数字の対比を入れることで、導入前の計算の落とし穴を明確にするため。
A4: 採る。事実誤認（6回すべて成功と読める点、lossがシミュレーションの数字という点）を直すため。
A5: 採る。経営者に刺さる具体的な数字（3,355円と8か月）を入れ、電圧未計測の事実も書くため。
A6: 採る。比較条件を正確にし、各1回の録画ではなく中央値で言える確かな事実にするため。
A7: 採る。事実誤認（事故ではなく問題）を直し、シミュレーションの前提を疑う問いにするため。
A8: 採る。出典のない引用を削り、ルール通り相談窓口を最後の1行だけにするため。
B1: 採る。事実に基づかない一般論を削り、このページで得られる価値（測り方）を明示するため。
B2: 採る。動画から確認できる事実と推測を分け、現場で測れる問いにするため。
B3: 一部採る。版の違いや中央値の事実は採る。⑥の問いは評者Aの「試算との差」を軸に組み合わせるため。
B4: 採る。直した結果の数字の矛盾（止まり合いは減ったが待ちは延びた）を強調するため。
B5: 採る。事実誤認を正し、検証結果を信用する前の確認点として価値を立てるため。
B6: 採る。同一場面の比較ではないことや実店舗のカメラ性能ではないことを明記し、事実を正すため。
B7: 採る。比較した日が異なる事実を入れ、人の補助と落下を分けて数える問いにするため。
B8: 一部採る。⑪⑫の事実修正と最後のまとめは採る。並び順は評者Aの「3つの見立て」の枠組みをベースにするため。

---

【企画書】

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

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

---

## 止まっても気づけない

### 1. 店員が来るまで
- **どんな現場で**：実店舗の動画
- **何が起きたか**：実店舗の動画で店員が対応した3例では、直す作業は約1〜10秒でした。店員が来るまでは約18秒、41秒以上、45秒以上かかっています。1本目は、待った時間と直した時間の比が8対1以上でした（動画は編集されているため、秒数は下限です）。
- **なぜ止まったか**：向かい合った台どうしや、待機場所で出口をふさがれた台が、その場から進めなくなっていました。店員の端末への通知は画面では確認できませんでした。
- **入れる前に確かめること**：自分の現場で停止から復帰までを測ると、「店員が来るまで」と「来てから直すまで」は、それぞれ何秒ですか？
- **出典**：[serving-robot-video-ledger](/record/serving-robot-video-ledger)
- **ハコブくんの一言**：「直してもらうのは数秒。来てもらうまでが長いんです」

### 2. 命令が黙って捨てられる
- **どんな現場で**：実機（ロボットアーム）
- **何が起きたか**：肩95.53〜99.22°の姿勢への命令は、エラーなしに6回とも動きませんでした。動いたのは最大1.50°で、止まっているときの揺れと同じくらいです。さらに、動いていない記録2本が、台帳では「つかめた・箱に入った」と判定されていました。肩87.27°で教え直すと5回続けて成功しました。
- **なぜ止まったか**：メーカー公式の肩の範囲は−85°〜+90°です。送る側のライブラリは±190°でしか確かめないため、範囲外の命令もそのまま届き、アーム側で黙って捨てられていました。手で教えるときはモーターの力が抜けているので、人は99°まで倒せてしまいます。
- **入れる前に確かめること**：命令を送るソフトが確かめる範囲は、機体が動ける範囲と同じですか。「成功」という記録は、実際に動いたことを何で確かめていますか（映像、角度の記録）。
- **出典**：[teach-replay-19-demos](/record/teach-replay-19-demos)
- **ハコブくんの一言**：「僕は動いてないのに、台帳では仕事が終わってます」

### 3. 学習の数字は良いのに外れる
- **どんな現場で**：実機（ロボットアーム）
- **何が起きたか**：学習を2倍に増やし、学習の誤差（loss）が0.0030まで下がっても、実機は2回ともブロックの奥で爪を閉じ、つかめませんでした。手を伸ばす先は変わりませんでした。
- **なぜ止まったか**：お手本19本はブロックの位置がほぼ同じでした。ログでは、画像を細かく見ずにいつもの場所へ手を伸ばしても学習誤差を下げられたのではないか、と見ています。足りないのは学習の回数ではなく、ブロックの位置が違うお手本でした。
- **入れる前に確かめること**：お手本を集めた位置からブロックをずらしても、実機でつかめますか？ 学習誤差とは別に、その成否を記録していますか？
- **出典**：[pi05-mecharm-first-real-run](/record/pi05-mecharm-first-real-run) / [pi05-mecharm-4000-steps](/record/pi05-mecharm-4000-steps)
- **ハコブくんの一言**：「テストの点数は良かったんですけど、本番の応用問題は解けませんでした」

### 4. 道の線を消すと拾えない
- **どんな現場で**：シミュレーションの録画
- **何が起きたか**：Unity録画の切り出し画像1枚を使う検出試験では、誤報5%の条件で、30秒以上の停止を拾えた割合は経路線あり72%、線なし28%でした。撮り直しで動きも変わっており、同一場面の比較ではありません。実店舗のカメラ性能を測った値でもありません。
- **なぜ止まったか**：画像AIは画面に描かれた「道の線の交差」を手がかりにしており、実際のカメラには映らない線がないと、待機中の姿と区別がつかないためです。
- **入れる前に確かめること**：停止の検出試験に、本番の映像にはない経路線などの表示が入っていませんか？ 止まった長さを、機体の記録とも照合していますか？
- **出典**：[serving-robot-jam-detection-without-path-lines](/record/serving-robot-jam-detection-without-path-lines)
- **ハコブくんの一言**：「防犯カメラから見たら、サボってるのか待機中なのか分かんないですよね」

---

## 壊れていないのに止まる

### 5. にらみ合い
- **どんな現場で**：実店舗の動画・シミュレーション
- **何が起きたか**：実店舗の動画では、狭い通路や待機場所の横で向かい合った2台が自力で抜けられず、店員が片方を手でよけていました。
- **なぜ止まったか**：メーカーの取扱説明書にはロボットどうしの譲り合いの決まりが公開されておらず、シミュレーションでも互いによけ先が相手の道の上になると解決できませんでした。
- **入れる前に確かめること**：2台が向かい合う場面を試すと、自力で抜けられますか。人が必要なら、誰がどう動かすと復帰しますか？
- **出典**：[serving-robot-faceoff-staff-resolves](/record/serving-robot-faceoff-staff-resolves) / [serving-robot-jams-are-aisles](/record/serving-robot-jams-are-aisles)
- **ハコブくんの一言**：「『お先にどうぞ』って言えないんで、とりあえず見つめ合ってます」

### 6. まさかの電源不足
- **どんな現場で**：実機（ロボットアーム）
- **何が起きたか**：実機mechArm 270で、同じモデル・位置5・爪を閉じる設定を使った試行は、電源交換前が3回中1回成功、12V・5A（3,355円）への交換後が5回中5回成功でした。交換後は落としませんでしたが、1回は人が持ち上げを補助し、爪の電流低下も残りました。比較した日は異なります。
- **なぜ止まったか**：本体が求める電源は40Wです。つないでいたのは外付けディスク用の12V・2A（24W）で、6割しかありませんでした。アダプターは箱に入っておらず別送で、8か月分の実機の記録はすべてこの電源で取っていました。電源容量不足が疑われ、交換後に落下がなくなりましたが、電圧そのものは測っていません。
- **入れる前に確かめること**：AIの学習条件を変える前に、つかんだ後やアームが動き出す瞬間の爪の電流を記録していますか？ 「落とさなかった回数」と「人の補助なしで完了した回数」を分けていますか？
- **出典**：[mecharm-270-drops-block-underpowered-adapter](/record/mecharm-270-drops-block-underpowered-adapter) / [mecharm-270-5a-adapter-stops-dropping-block](/record/mecharm-270-5a-adapter-stops-dropping-block)
- **ハコブくんの一言**：「8か月、腹ぺこで働いてました。3,355円でやっと満腹です」

### 7. 地図を渡しても抜けられない
- **どんな現場で**：シミュレーション
- **何が起きたか**：同じ店で道の引き方を賢くしても、60秒の止まりは57→59回で減りませんでした。59回のうち43回は、ドリンクバーと6人席の間（0.4m）の行き止まりに集まっていました。ドリンクバーを上へ0.5m、左へ0.8m動かすと20回になり、ロボットが運んだ割合は64.4→99.4%、料理の待ちは2.90→1.17分になりました（どれも1回ずつの比較）。
- **なぜ止まったか**：最短経路を共用する設定に加え、物理的な行き止まりがあったためです。
- **入れる前に確かめること**：道の引き方だけを変えた場合と、設備を動かして抜け道を作った場合で、止まり方はどう変わりますか？
- **出典**：[serving-robot-fixed-route-jam](/record/serving-robot-fixed-route-jam) / [serving-robot-map-planner](/record/serving-robot-map-planner)
- **ハコブくんの一言**：「賢く道を引けるようになっても、物理的に行き止まりじゃ抜けられません」

### 8. 計算ではレジ、実際は片付け
- **どんな現場で**：シミュレーション（Unityの46卓の店、スタッフ4人）
- **何が起きたか**：表計算の試算では、ロボット2台のとき「席は空いているのに待つ時間」は0.7分でした。同じ店を Unity で動かすと3.4分です（約5倍。ログの数字から計算）。ロボットを0→1→2台と足すと、入店待ちは8.1→6.6→5.5分と縮みました。それでも、この待ちは残りました。
- **なぜ止まったか**：試算では、食べ終えたお客さんが卓に座ったままレジを待つので、レジが詰まります。3Dの店では、スタッフが歩き回るぶん手がふさがり、後回しになった片付けがたまっていました（③⑦では1組あたりの仕事が試算より約1割長い）。
- **入れる前に確かめること**：導入の効果を見積もった計算には、スタッフが歩く時間が入っていますか。ピークの時間に、空いているのに案内できない卓が何卓あるか数えてください。
- **出典**：[large-store-cleanup-bottleneck](/record/large-store-cleanup-bottleneck) / [standby-jam-every-store](/record/standby-jam-every-store)
- **ハコブくんの一言**：「計算ではレジが混むはずだったんですけど、実際は片付け待ちでした」

---

## 足すと・直すと悪くなる

### 9. 2台目が待ちを延ばす
- **どんな現場で**：シミュレーション
- **何が起きたか**：Unityの28卓・スタッフ2人の店では、入店待ちの中央値が1台13.8分、2台25.1分と約2倍に延びました。試した改善案でも2台は1台より短くなりませんでした。ただし、1台と2台の比較には版の違いが残ります。
- **なぜ止まったか**：狭い通路（約1.1m）でロボットどうしが向かい合ってふさぎ合ったためです。
- **入れる前に確かめること**：今の通路幅で2台入れたとき、すれ違えない場所が何箇所ありますか？
- **出典**：[serving-robot-one-per-narrow-restaurant](/record/serving-robot-one-per-narrow-restaurant) / [small-store-second-robot-wait](/record/small-store-second-robot-wait)
- **ハコブくんの一言**：「後輩が入ってきたら、道が狭くて余計に渋滞しちゃいました」

### 10. 待機場所の止まり合い
- **どんな現場で**：シミュレーション
- **何が起きたか**：Unityの大型店・5台の条件で、待機点へまっすぐ戻る決まりに変えると、待機場所付近の詰まりは3,317秒から1,255秒に減りました。一方、同じ比較の入店待ちは12.22分から14.90分に延びました。台どうしの順番決めが不足する、シミュレーションの作りも影響しています。
- **なぜ止まったか**：大きな原因の一つは、斜めに戻る台のセンサー（中心から0.85m）に、隣の待機台が入ってしまうことでした。
- **入れる前に確かめること**：待機場所の止まり合いを減らしたとき、入店待ちも縮んでいますか。それぞれを別に測っていますか？
- **出典**：[large-restaurant-five-serving-robots-longer-wait](/record/large-restaurant-five-serving-robots-longer-wait) / [serving-robots-jam-cause-standby-entry](/record/serving-robots-jam-cause-standby-entry) / [serving-robot-jam-three-rules](/record/serving-robot-jam-three-rules)
- **ハコブくんの一言**：「斜めから帰ると、お隣さんにぶつかりそうって怒られるんです」

### 11. 下げ膳で詰まる
- **どんな現場で**：シミュレーション
- **何が起きたか**：Unityの6店・計120回の比較では、スタッフの歩く距離は12条件すべてで減りました。一方、2台で下げ膳も任せると、退店から卓が再び使えるまでの中央値が、効率重視の細い店③では4.05分から6.05分、店⑦では4.49分から8.06分（約1.8倍）に延びました。
- **なぜ止まったか**：下げ膳のロボットが卓に着いてスタッフを待つ間、通路が1本ふさがり、他のロボットやスタッフが回り道や待機を強いられるためです。
- **入れる前に確かめること**：増台や下げ膳の追加で、スタッフの歩く距離は減りましたか。同じ条件で、入店待ちと退店から卓が使えるまでの時間はどう変わりましたか？
- **出典**：[serving-robot-sim-bussing-narrow-aisles](/record/serving-robot-sim-bussing-narrow-aisles) / [serving-robot-bussing-depends-on-aisles](/record/serving-robot-bussing-depends-on-aisles)
- **ハコブくんの一言**：「お皿下げるの待ってる間、僕の後ろ大渋滞なんですけど…」

### 12. 人の動きを仮置きしたら
- **どんな現場で**：シミュレーション（仮の病院）
- **何が起きたか**：Unityの仮の病院で、通れなかった患者・職員を通すと、急停止やひやりなどの問題が84件から132件に増えました。職員は「1時間に1回、くじで選んだ部屋へ行く」という仮の決まりで動いていました。行き先を持ち場に限ると68件、持ち場ごとの4つの型にすると19件になりました。その後、患者の動きを入れると51件です（主に種0の1回の比較で、種によって大きくぶれます）。
- **なぜ止まったか**：通れるようにした場所を、職員が普段の行き先としても使う決まりになり、ロボットとの交錯が増えていました。
- **入れる前に確かめること**：導入判断に使うシミュレーションの職員は、誰の観察をもとに、どこへ、何の仕事で移動していますか？
- **出典**：[hospital-transport-robot-avoid-outpatient-hall](/record/hospital-transport-robot-avoid-outpatient-hall) / [hospital-transport-robot-blocked-paths-more-conflicts](/record/hospital-transport-robot-blocked-paths-more-conflicts) / [hospital-transport-robot-conflicts-came-from-placeholder-staff-moves](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)
- **ハコブくんの一言**：「職員さんの行き先、くじで決めてたんですか」

---

## 導入を「実験」で終わらせないために

12のうち5つは、足したり直したりして、悪くなったか変わらなかった記録です（2台目、5台目、学習の回数、道の引き方、通れる所を直す）。どこで詰まっているかを数えてから足す、という順番が、12の記録に共通しています。

「直す作業は数秒なのに、気づくまでは数十秒かかる」「エラーを出さずに黙って止まる」「学習の誤差は下がるのに外れる」。これらはすべて、止まったことが「数字や画面に出てこない」種類のトラブルです。

自分の現場に近い止まり方を一つ選び、導入試験の記録にしてください。「どの条件で起きたか」「止まってから人が来るまで」「人が直す時間」「人の補助なしで仕事が終わったか」を残します。通路や台数を変える試験では、止まりの時間と、お客さんの待ち時間も分けて比べてください。

## 終わりに：次にすること

各項目の「入れる前に確かめること」のうち、待機点の間隔（10）と、止まりが集まる場所（7）は、入れる前から測れます。止まってから店員が来るまで（1）は、試しに入れている間に数えられます。シミュレーションの店の作りは、各項目の /record/ から見られます。

自分の現場での確かめ方を一緒に検討したい方、自分の現場の数字で確かめたい方は、[メッセージフォーム（/message）](/message) に1行どうぞ。
```


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

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

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

---

## 止まっても気づけない

### 1. 店員が来るまで
- **どんな現場で**：実店舗の動画
- **何が起きたか**：実店舗の動画で店員が対応した3例では、直す作業は約1〜10秒でした。店員が来るまでは約18秒、41秒以上、45秒以上かかっています。1本目は、待った時間と直した時間の比が8対1以上でした（動画は編集されているため、秒数は下限です）。
- **なぜ止まったか**：向かい合った台どうしや、待機場所で出口をふさがれた台が、その場から進めなくなっていました。店員の端末への通知は画面では確認できませんでした。
- **入れる前に確かめること**：自分の現場で停止から復帰までを測ると、「店員が来るまで」と「来てから直すまで」は、それぞれ何秒ですか？
- **出典**：[serving-robot-video-ledger](/record/serving-robot-video-ledger)
- **ハコブくんの一言**：「直してもらうのは数秒。来てもらうまでが長いんです」

### 2. 命令が黙って捨てられる
- **どんな現場で**：実機（ロボットアーム）
- **何が起きたか**：肩95.53〜99.22°の姿勢への命令は、エラーなしに6回とも動きませんでした。動いたのは最大1.50°で、止まっているときの揺れと同じくらいです。さらに、動いていない記録2本が、台帳では「つかめた・箱に入った」と判定されていました。肩87.27°で教え直すと5回続けて成功しました。
- **なぜ止まったか**：メーカー公式の肩の範囲は−85°〜+90°です。送る側のライブラリは±190°でしか確かめないため、範囲外の命令もそのまま届き、アーム側で黙って捨てられていました。手で教えるときはモーターの力が抜けているので、人は99°まで倒せてしまいます。
- **入れる前に確かめること**：命令を送るソフトが確かめる範囲は、機体が動ける範囲と同じですか。「成功」という記録は、実際に動いたことを何で確かめていますか（映像、角度の記録）。
- **出典**：[teach-replay-19-demos](/record/teach-replay-19-demos)
- **ハコブくんの一言**：「僕は動いてないのに、台帳では仕事が終わってます」

### 3. 学習の数字は良いのに外れる
- **どんな現場で**：実機（ロボットアーム）
- **何が起きたか**：学習を2倍に増やし、学習の誤差（loss）が0.0030まで下がっても、実機は2回ともブロックの奥で爪を閉じ、つかめませんでした。手を伸ばす先は変わりませんでした。
- **なぜ止まったか**：お手本19本はブロックの位置がほぼ同じでした。ログでは、画像を細かく見ずにいつもの場所へ手を伸ばしても学習誤差を下げられたのではないか、と見ています。足りないのは学習の回数ではなく、ブロックの位置が違うお手本でした。
- **入れる前に確かめること**：お手本を集めた位置からブロックをずらしても、実機でつかめますか？ 学習誤差とは別に、その成否を記録していますか？
- **出典**：[pi05-mecharm-first-real-run](/record/pi05-mecharm-first-real-run) / [pi05-mecharm-4000-steps](/record/pi05-mecharm-4000-steps)
- **ハコブくんの一言**：「テストの点数は良かったんですけど、本番の応用問題は解けませんでした」

### 4. 道の線を消すと拾えない
- **どんな現場で**：シミュレーションの録画
- **何が起きたか**：Unity録画の切り出し画像1枚を使う検出試験では、誤報5%の条件で、30秒以上の停止を拾えた割合は経路線あり72%、線なし28%でした。撮り直しで動きも変わっており、同一場面の比較ではありません。実店舗のカメラ性能を測った値でもありません。
- **なぜ止まったか**：画像AIは画面に描かれた「道の線の交差」を手がかりにしており、実際のカメラには映らない線がないと、待機中の姿と区別がつかないためです。
- **入れる前に確かめること**：停止の検出試験に、本番の映像にはない経路線などの表示が入っていませんか？ 止まった長さを、機体の記録とも照合していますか？
- **出典**：[serving-robot-jam-detection-without-path-lines](/record/serving-robot-jam-detection-without-path-lines)
- **ハコブくんの一言**：「防犯カメラから見たら、サボってるのか待機中なのか分かんないですよね」

---

## 壊れていないのに止まる

### 5. にらみ合い
- **どんな現場で**：実店舗の動画・シミュレーション
- **何が起きたか**：実店舗の動画では、狭い通路や待機場所の横で向かい合った2台が自力で抜けられず、店員が片方を手でよけていました。
- **なぜ止まったか**：メーカーの取扱説明書にはロボットどうしの譲り合いの決まりが公開されておらず、シミュレーションでも互いによけ先が相手の道の上になると解決できませんでした。
- **入れる前に確かめること**：2台が向かい合う場面を試すと、自力で抜けられますか。人が必要なら、誰がどう動かすと復帰しますか？
- **出典**：[serving-robot-faceoff-staff-resolves](/record/serving-robot-faceoff-staff-resolves) / [serving-robot-jams-are-aisles](/record/serving-robot-jams-are-aisles)
- **ハコブくんの一言**：「『お先にどうぞ』って言えないんで、とりあえず見つめ合ってます」

### 6. まさかの電源不足
- **どんな現場で**：実機（ロボットアーム）
- **何が起きたか**：実機mechArm 270で、同じモデル・位置5・爪を閉じる設定を使った試行は、電源交換前が3回中1回成功、12V・5A（3,355円）への交換後が5回中5回成功でした。交換後は落としませんでしたが、1回は人が持ち上げを補助し、爪の電流低下も残りました。比較した日は異なります。
- **なぜ止まったか**：本体が求める電源は40Wです。つないでいたのは外付けディスク用の12V・2A（24W）で、6割しかありませんでした。アダプターは箱に入っておらず別送で、8か月分の実機の記録はすべてこの電源で取っていました。電源容量不足が疑われ、交換後に落下がなくなりましたが、電圧そのものは測っていません。
- **入れる前に確かめること**：AIの学習条件を変える前に、つかんだ後やアームが動き出す瞬間の爪の電流を記録していますか？ 「落とさなかった回数」と「人の補助なしで完了した回数」を分けていますか？
- **出典**：[mecharm-270-drops-block-underpowered-adapter](/record/mecharm-270-drops-block-underpowered-adapter) / [mecharm-270-5a-adapter-stops-dropping-block](/record/mecharm-270-5a-adapter-stops-dropping-block)
- **ハコブくんの一言**：「8か月、腹ぺこで働いてました。3,355円でやっと満腹です」

### 7. 地図を渡しても抜けられない
- **どんな現場で**：シミュレーション
- **何が起きたか**：同じ店で道の引き方を賢くしても、60秒の止まりは57→59回で減りませんでした。59回のうち43回は、ドリンクバーと6人席の間（0.4m）の行き止まりに集まっていました。ドリンクバーを上へ0.5m、左へ0.8m動かすと20回になり、ロボットが運んだ割合は64.4→99.4%、料理の待ちは2.90→1.17分になりました（どれも1回ずつの比較）。
- **なぜ止まったか**：最短経路を共用する設定に加え、物理的な行き止まりがあったためです。
- **入れる前に確かめること**：道の引き方だけを変えた場合と、設備を動かして抜け道を作った場合で、止まり方はどう変わりますか？
- **出典**：[serving-robot-fixed-route-jam](/record/serving-robot-fixed-route-jam) / [serving-robot-map-planner](/record/serving-robot-map-planner)
- **ハコブくんの一言**：「賢く道を引けるようになっても、物理的に行き止まりじゃ抜けられません」

### 8. 計算ではレジ、実際は片付け
- **どんな現場で**：シミュレーション（Unityの46卓の店、スタッフ4人）
- **何が起きたか**：表計算の試算では、ロボット2台のとき「席は空いているのに待つ時間」は0.7分でした。同じ店を Unity で動かすと3.4分です（約5倍。ログの数字から計算）。ロボットを0→1→2台と足すと、入店待ちは8.1→6.6→5.5分と縮みました。それでも、この待ちは残りました。
- **なぜ止まったか**：試算では、食べ終えたお客さんが卓に座ったままレジを待つので、レジが詰まります。3Dの店では、スタッフが歩き回るぶん手がふさがり、後回しになった片付けがたまっていました（③⑦では1組あたりの仕事が試算より約1割長い）。
- **入れる前に確かめること**：導入の効果を見積もった計算には、スタッフが歩く時間が入っていますか。ピークの時間に、空いているのに案内できない卓が何卓あるか数えてください。
- **出典**：[large-store-cleanup-bottleneck](/record/large-store-cleanup-bottleneck) / [standby-jam-every-store](/record/standby-jam-every-store)
- **ハコブくんの一言**：「計算ではレジが混むはずだったんですけど、実際は片付け待ちでした」

---

## 足すと・直すと悪くなる

### 9. 2台目が待ちを延ばす
- **どんな現場で**：シミュレーション
- **何が起きたか**：Unityの28卓・スタッフ2人の店では、入店待ちの中央値が1台13.8分、2台25.1分と約2倍に延びました。試した改善案でも2台は1台より短くなりませんでした。ただし、1台と2台の比較には版の違いが残ります。
- **なぜ止まったか**：狭い通路（約1.1m）でロボットどうしが向かい合ってふさぎ合ったためです。
- **入れる前に確かめること**：今の通路幅で2台入れたとき、すれ違えない場所が何箇所ありますか？
- **出典**：[serving-robot-one-per-narrow-restaurant](/record/serving-robot-one-per-narrow-restaurant) / [small-store-second-robot-wait](/record/small-store-second-robot-wait)
- **ハコブくんの一言**：「後輩が入ってきたら、道が狭くて余計に渋滞しちゃいました」

### 10. 待機場所の止まり合い
- **どんな現場で**：シミュレーション
- **何が起きたか**：Unityの大型店・5台の条件で、待機点へまっすぐ戻る決まりに変えると、待機場所付近の詰まりは3,317秒から1,255秒に減りました。一方、同じ比較の入店待ちは12.22分から14.90分に延びました。台どうしの順番決めが不足する、シミュレーションの作りも影響しています。
- **なぜ止まったか**：大きな原因の一つは、斜めに戻る台のセンサー（中心から0.85m）に、隣の待機台が入ってしまうことでした。
- **入れる前に確かめること**：待機場所の止まり合いを減らしたとき、入店待ちも縮んでいますか。それぞれを別に測っていますか？
- **出典**：[large-restaurant-five-serving-robots-longer-wait](/record/large-restaurant-five-serving-robots-longer-wait) / [serving-robots-jam-cause-standby-entry](/record/serving-robots-jam-cause-standby-entry) / [serving-robot-jam-three-rules](/record/serving-robot-jam-three-rules)
- **ハコブくんの一言**：「斜めから帰ると、お隣さんにぶつかりそうって怒られるんです」

### 11. 下げ膳で詰まる
- **どんな現場で**：シミュレーション
- **何が起きたか**：Unityの6店・計120回の比較では、スタッフの歩く距離は12条件すべてで減りました。一方、2台で下げ膳も任せると、退店から卓が再び使えるまでの中央値が、効率重視の細い店③では4.05分から6.05分、店⑦では4.49分から8.06分（約1.8倍）に延びました。
- **なぜ止まったか**：下げ膳のロボットが卓に着いてスタッフを待つ間、通路が1本ふさがり、他のロボットやスタッフが回り道や待機を強いられるためです。
- **入れる前に確かめること**：増台や下げ膳の追加で、スタッフの歩く距離は減りましたか。同じ条件で、入店待ちと退店から卓が使えるまでの時間はどう変わりましたか？
- **出典**：[serving-robot-sim-bussing-narrow-aisles](/record/serving-robot-sim-bussing-narrow-aisles) / [serving-robot-bussing-depends-on-aisles](/record/serving-robot-bussing-depends-on-aisles)
- **ハコブくんの一言**：「お皿下げるの待ってる間、僕の後ろ大渋滞なんですけど…」

### 12. 人の動きを仮置きしたら
- **どんな現場で**：シミュレーション（仮の病院）
- **何が起きたか**：Unityの仮の病院で、通れなかった患者・職員を通すと、急停止やひやりなどの問題が84件から132件に増えました。職員は「1時間に1回、くじで選んだ部屋へ行く」という仮の決まりで動いていました。行き先を持ち場に限ると68件、持ち場ごとの4つの型にすると19件になりました。その後、患者の動きを入れると51件です（主に種0の1回の比較で、種によって大きくぶれます）。
- **なぜ止まったか**：通れるようにした場所を、職員が普段の行き先としても使う決まりになり、ロボットとの交錯が増えていました。
- **入れる前に確かめること**：導入判断に使うシミュレーションの職員は、誰の観察をもとに、どこへ、何の仕事で移動していますか？
- **出典**：[hospital-transport-robot-avoid-outpatient-hall](/record/hospital-transport-robot-avoid-outpatient-hall) / [hospital-transport-robot-blocked-paths-more-conflicts](/record/hospital-transport-robot-blocked-paths-more-conflicts) / [hospital-transport-robot-conflicts-came-from-placeholder-staff-moves](/record/hospital-transport-robot-conflicts-came-from-placeholder-staff-moves)
- **ハコブくんの一言**：「職員さんの行き先、くじで決めてたんですか」

---

## 導入を「実験」で終わらせないために

12のうち5つは、足したり直したりして、悪くなったか変わらなかった記録です（2台目、5台目、学習の回数、道の引き方、通れる所を直す）。どこで詰まっているかを数えてから足す、という順番が、12の記録に共通しています。

「直す作業は数秒なのに、気づくまでは数十秒かかる」「エラーを出さずに黙って止まる」「学習の誤差は下がるのに外れる」。これらはすべて、止まったことが「数字や画面に出てこない」種類のトラブルです。

自分の現場に近い止まり方を一つ選び、導入試験の記録にしてください。「どの条件で起きたか」「止まってから人が来るまで」「人が直す時間」「人の補助なしで仕事が終わったか」を残します。通路や台数を変える試験では、止まりの時間と、お客さんの待ち時間も分けて比べてください。

## 終わりに：次にすること

各項目の「入れる前に確かめること」のうち、待機点の間隔（10）と、止まりが集まる場所（7）は、入れる前から測れます。止まってから店員が来るまで（1）は、試しに入れている間に数えられます。シミュレーションの店の作りは、各項目の /record/ から見られます。

自分の現場での確かめ方を一緒に検討したい方、自分の現場の数字で確かめたい方は、[メッセージフォーム（/message）](/message) に1行どうぞ。
```


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

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


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

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


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

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

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