# 制作の依頼：今あるログから、人の入口になるページを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本