フィジカルAI研究室を作る Log#1 | 自宅にゼロから、誰でも再現できる形で

自宅にフィジカルAI研究室を作るプロジェクトを始めます。

ロボットを所有することが目的ではありません。Physical AI が学習できる環境を、個人の手で、自宅に、ゼロから構築する。そしてその過程を、誰でも同じ環境を再現できる形で公開する。それがこのシリーズです。

mechArm 270-Pi での実機ログはこれまで積んできました。iPhone で撮り、Unity でデジタルツインを作り、実機のモーターまで届かせる。ロボットが物を掴む動作を個人が作れることは、実機で示しました。次に必要なのは、その動作を学習させられる環境そのものです。

そこがまだ手元にない。だから作ります。

この回は実装がありません。コードを一行も書いていない。代わりに、この決定に至るまでの対話をそのまま残します。要約しません。外した議論も、訂正された過程も、間違えた発言も消しません。決定そのものより、決定に至る過程のほうが後から使えるからです。

一本の論文から始まった

VLA-JEPA という論文を調べていました。

VLA（Vision Language Action）は、画像と自然言語からロボット行動を学ぶモデルです。画像と「赤いブロックを青い箱へ」という指示が入り、ロボットアームの座標が出る。この対応だけを大量のデータから学びます。OpenVLA、π0、SmolVLA、RT-2、OpenVLA-OFT という系譜があります。

ただしこれらには弱点があります。観察から行動への対応だけを学ぶので、その行動によって世界がどう変化するかを理解していない。コップを押したら倒れるのか、滑るのか、転がるのか。モデルは知らない。だから環境が少し変わるだけで失敗します。

JEPA（Joint Embedding Predictive Architecture）は Meta の Yann LeCun が提唱した枠組みです。重要なのは、画像を生成するのではなく、未来の状態を潜在空間で予測すること。

なぜ画像を生成しないのか。普通の世界モデルは未来画像を生成しますが、そのためには影・照明・ノイズ・背景・カメラ揺れまで全部再現しなければならない。非常に難しい。JEPA は特徴ベクトルだけを扱うので、位置・速度・姿勢・関係性といった本当に重要なものだけを学びます。

V-JEPA2 は Meta が公開した巨大な動画世界モデルです。インターネット上の動画を大量に学習し、物体・人・重力・動き・接触・衝突を理解している。つまり世界の物理を学習済みです。

VLA-JEPA の構造はこうなります。

通常のVLA
画像 → LLM → Action

VLA-JEPA（学習時）
画像 → Qwen3-VL → Action Token → V-JEPA2 → 未来状態予測 → Loss

VLA-JEPA（推論時）
画像 → Qwen3-VL → Action Head → Action

学習時だけ世界モデルを通し、推論時にはそれを捨てる。Loss は Action Loss と World Model Loss の和になります。普通なら毎回世界モデルを通して未来予測をするので重い。VLA-JEPA はそれを推論時に削除する。だから軽い。

公式デモは RTX3080・VRAM 6GB未満で約 10Hz 動作しています。ロボット制御として現実的な速度です。ファインチューニングに使ったデモは13個。万能ではないにせよ、少量データでも適応しやすい可能性を示す結果として注目されています。

従来の VLA は「赤コップ → 持つ」しか覚えない。VLA-JEPA は「赤コップ → 持つ → 次にこう動く → 世界がこう変わる」まで理解する。だから配置が少し変わっても対応できる。

流れとして整理すると、こうなります。

「見る → 真似る」から「世界を理解して動く」へ。ロボティクスはそこへ向かっています。

描けた図と、試せない環境

ChatGPT は、これを R2R2R に接続する構成を提案してきました。

Reality（LiDAR・動画収集）→ Digital Twin（Unity / Isaac Sim）→ V-JEPA2（物理・状態遷移の学習）→ VLA-JEPA（言語指示から行動生成）→ RL（失敗ケースや最適化の追加学習）→ Real Robot

R2R2R の Render 部分に JEPA 世界モデルを組み込む。単なる模倣ではなく、世界の変化を予測できるロボットを育てられる可能性がある。

図としては成立しています。魅力的でもある。

— ただし、この図には試す場所が書かれていない。

Isaac Sim も V-JEPA2 も、手元で動かせなければ何も検証できません。技術の魅力に引かれると、環境の話が抜け落ちる。RTX3080 で 10Hz というのは推論の話であって、学習には別の話があります。

ここで、話題は自然にワークステーションへ移りました。

75万円は妥当か

最初の問いはこれでした。

RTX5090 は結構価格が高いですが、Linux ワークステーション75万円というのは合っていますか

このやり取りの中で、いくつか根本的な確認が挟まりました。記録として残しておきます。

RTX5080 Linux の購入は、このファンのついた GPU を購入して MacBook に外付けする、の意味であっていますか

違います。GPU をノートPCに外付けするという話ではありません。Linux が動くタワー型の PC を1台組む、という話です。

要は Linux のタワー型の PC を横に置いて学習環境を作るということですか。こんな感じ？

そうです。机の横に一台立てる。そこで学習を回す。

見た目こんな感じですか？

そういう見た目になります。

Fractal Design Define / Fractal North / be quiet! / SilverStone / Corsair 4000D。この辺は単にケースのメーカーってことですか？

そうです。中身ではなく箱です。この時点でケースの選定に入りました。North XL を確認しています。

— ここが重要な分岐点だった。

「75万円は妥当か」という問いに、妥当か否かで答えると、その先には「では何を買うか」しかありません。だが実際に確認していたのは、そもそも何を買う話なのか（eGPU なのかタワーなのか）というレベルでした。

知らないことは知らないと確認しながら進む。ここを飛ばして構成表だけ埋めると、後で全部やり直しになります。

デジタルツインまでは閉じた。学習では閉じない

iPhone と Unity だけで、ロボットが物を掴む動作を個人が作れる。これは R2R2R のコアメッセージで、実機で示しました。

しかし学習を回す段になると、iPhone と Unity では閉じない。GPU が要る。

Journal にこう書きました。

重要なのは Robot ではなく Robot Learning である。

機体を増やすことは目的ではない。データ収集・学習・評価・実験の 4 つが自分の手で回ること。それが目的です。

— ここで判断が要る。買うのか、借りるのか、作るのか。

クラウドで借りる選択肢はあります。ただ、借りた環境は他人が再現できません。「誰でも同じ環境から始められる状態を増やす」を目的に置くなら、その環境は他人の手元に立ち上げられるものである必要があります。

自宅に、自分で組む。ワークステーションは自作します。

Unity を捨てない

ではなぜ Isaac Sim なのか。Unity ではだめなのか。

Unity の物理はゲームには十分です。ロボット研究には少し足りません。

コップを掴む場合、Unity ではこの程度までは作れます。

コップがある → グリッパが閉じる → 持てた

実機ではこうなります。

指先が0.3mmずれた → 摩擦係数が違う → 少し滑る → 傾く → 落とす

これが毎回起きます。ここを計算するのが NVIDIA PhysX（Isaac Sim）です。

双腕になるとさらに差が出ます。左手で持って右手に渡す。それだけで接触・摩擦・関節トルク・衝突・重心移動が全部絡みます。Unity でも作れますが、かなり自分で実装することになる。Isaac Sim は最初から持っています。

センサーも違います。

ロボットが実際に見ている世界を再現できるかどうか、という差です。

— だが、それは Unity を捨てる理由にはならない。

なりません。むしろ逆です。

ロボティクス研究者は ROS・Isaac・Python に強い。ただし「顧客に伝わるデジタルツイン」を作るのは得意でないことが多い。デザインと UX と Unity を軸にしてロボティクスへ入るなら、そこが持ち場になります。

役割を分けます。

R2R2R は Unity を Isaac Sim の代わりにするのではありません。Unity をロボット開発の入口にするという発想です。

現場
↓
Unity で数時間でデジタルツイン作成
↓
「ここはロボット化できそう」
↓
USD で Isaac Sim へ渡す
↓
AI学習
↓
SO-101 で PoC
↓
本番ロボットへ

Unity が得意な人と Isaac Sim が得意な人は、コミュニティもツールも分かれています。Unity で作ったデジタルツインを、AI が学習できる環境へ変換する。この橋渡しができれば、それ自体が価値になります。

iPhone を入り口にした低コスト化と、同じ思想の別の面です。

ステーションの写真から読んだこと

同じ日、SO-101 のステーションを撮った動画を静止画にスキャンし、そこから仕様とサイズ感を読み取る作業もしていました。バージョン違いの動画を2種類。

読み取れたのは、カメラの扱いです。

まず、カメラはロボット側ではなくステーション側に付いています。黒いスタンドが2本立ち、その上にカメラと LED が載っている。ロボットとは独立した構造です。

ステーション
    │
Camera Stand
    │
  Camera

次に、完全固定ではない。スタンドの角度が画像ごとに変わっています。ボールジョイントか自由雲台と思われます。柱は長く、固定ネジが見当たらない。アルミ支柱をクランプで留める構造なら、上下位置も変えられます。

カメラ自体も交換できそうです。USB カメラ、マシンビジョンカメラ、RealSense。おそらく載せ替え前提の設計です。

なぜ固定しないのか。

学習では固定したい。しかし開発では調整したい。最初 45°で撮って見えなければ 30°にして、学習して、良かったら固定する。この流れが要るからです。

Adjustable but Repeatable. 調整できるが、再現できる。

— ただしこれは写真から読んだ推測であって、実測ではない。実機が来るまで確定しない。

推測は推測として書きます。手元にないハードの仕様を、映像から読んだ値で上位文書に書けば、それは焼き付いた数字になります。

環境そのものをデータにする

ここで、この推測から一つ先が見えました。

調整できる、ということは、その調整をどこかに記録しなければ再現できないということです。角度を変えた。高さを変えた。良かったので固定した。その「良かった状態」は、誰かの手の記憶の中にしかありません。

主指標に「再現可能な環境数」を置いたのだから、ここは避けて通れません。他人が同じ環境を立ち上げるには、カメラがどこにあってどこを向いていたかを、手順として渡せる必要があります。

だから、環境の設定そのものをデータにします。

支柱に目盛りを刻む。高さ 10 / 20 / 30 / 40 / 50。角度 0° / 15° / 30° / 45°。読み取った値を JSON に書く。

{
  "camera_id": "front_cam_01",
  "position_mm": { "x": 500, "y": -300, "z": 620 },
  "rotation_deg": { "pitch": 35, "yaw": 0, "roll": 0 },
  "lens": { "fov": 78 }
}

Unity 側はこれを読み、仮想カメラの Transform に反映する。

カメラだけではありません。ロボットベース位置、トレイ位置、治具位置、照明位置、対象物の初期位置。全部座標として持つ。

{
  "station_id": "station_001",
  "world_origin": "front_left_marker",
  "robot": {
    "id": "so101_left",
    "position_mm": { "x": 250, "y": 300, "z": 0 },
    "rotation_deg": { "x": 0, "y": 0, "z": 45 }
  },
  "camera": {
    "id": "front_cam",
    "position_mm": { "x": 500, "y": -250, "z": 600 },
    "rotation_deg": { "x": 35, "y": 0, "z": 0 }
  },
  "tray": {
    "position_mm": { "x": 500, "y": 300, "z": 0 }
  }
}

これができると、ワークステーションは単なるハードウェアではなく、現実とデジタルツインを同期する基準装置になります。

そして半年後にロボットを載せ替えても、カメラ位置を変えても、設定を保存して Unity を更新すれば済む。

最初は手入力でいい

自動化の手段は3段階あります。

v2 の流れはこうです。ステーションに基準マーカーを貼る。カメラで撮影する。OpenCV で姿勢推定する。カメラの position / rotation を取得して JSON に保存する。Unity へ反映する。

— ここで、v2 から始めたくなる。自動のほうが正しく見えるから。

始めません。v1 は手入力にします。

いま一番重要なのは、カメラ位置を自動取得することではありません。Reality と Unity で同じ環境を再現できることです。前者は後者の手段のひとつでしかない。

手入力なら最初は表計算でも足ります。

Excel → CSV → JSON → Unity → 自動化。この順番で進めます。

カメラ位置を 30秒で入力できるなら、誰も困りません。その代わり Unity 側が全部更新してくれれば十分です。

全部自動を目指す必要はない。ただし、後から自動化しやすいデータ構造で最初から設計しておく。この2つは両立します。設計として正しい順番であって、妥協ではありません。

Unity で再現できるもの、近似になるもの

Unity 側で現実をどこまで再現できるか。ここには境界があります。

かなり正確に合わせられるもの。

ステーション寸法 / 天板サイズ / ロボット位置 / カメラ位置
治具位置 / トレイ位置 / 対象物の初期位置 / 背景パネル

天板 W900 × D700、カメラ X450 / Y-300 / Z520、Pitch -35°、ロボット X250 / Y200。この程度の値を入れれば、物理ステーションとかなり一致します。

照明も設定はできます。ライトの種類、位置、角度、明るさ、色温度、影の柔らかさ、反射、環境光。上部照明なら Area Light、5000K、Soft Shadows でそれらしくなります。

ただし照明は完全一致しません。LED の拡散具合、壁の反射、天板の反射、カメラの露出、ホワイトバランス、レンズ特性。これらが絡みます。

だから照明は「物理的に完全一致」ではなく、「学習に必要な見え方を近づける」という使い方になります。むしろ完全一致より、明るめ・暗め・影あり・影なし・色温度違いを Unity 側でランダム化したほうが、実機に強くなります。

合わせる順番はこうです。

1. 寸法

2. カメラ位置

3. ロボット位置

4. 対象物サイズ

5. 治具位置

6. 照明

7. 素材の反射

照明は大事ですが、最初から沼る場所でもあります。

目指すのは現実との完全一致ではありません。学習に使えるくらい一致した標準環境です。

何を成果とみなすか

このプロジェクトの位置づけを、はっきりさせておきます。

新しいブランドではありません。Pixels to Motors の中で進む、環境そのものを対象にした研究です。外に出す名前は Pixels to Motors のみで、名前は増やしません。

そして、これは「発信をやめて研究に潜る」という話でもありません。記事は最初から研究の記録として書いてきました。それ自体を主役にしたことは一度もない。

変わったのは、何を成果とみなすかです。

読まれることではなく、再現されること。ここを主指標に置きました。

理由は単純です。記事の本数も、動画の本数も、コミット数も、増やそうと思えばいくらでも増やせる。量を主指標にした瞬間、薄い記事を毎日出すのが最適解になります。一方、他人が同じ手順で同じ結果に到達できる環境を1つ作ることは、水増しできません。

最初に出した案は「研究資産の総量」でした。Journal 数・GitHub 公開数・実験ログ数・動画数・再現可能な環境数を並べ、蓄積を評価する形です。

— その案の危険は一箇所にある。Journal数・動画数・ログ数は増やそうと思えばいくらでも増やせる。量を主指標にした瞬間、薄い記事を毎日出すのが最適解になる。

指摘を受けて絞りました。

❌ Journal 100本 / ❌ YouTube 50本 / ❌ GitHub 300コミット ✅ SO-101学習環境 v1 / ✅ デジタルツイン Pick&Place環境 / ✅ Sim-to-Real環境 / ✅ VLA学習環境

Journal や動画は「再現可能な環境を説明するための媒体」という位置付けで十分です。

「再現可能」の定義

主指標に置いた以上、定義がないと数は水増しできます。3つの条件を置きました。

1. 手順が公開されている（GitHub / 記事）

2. 依存関係とバージョンが記載されている

3. 自分以外の環境で再現された記録が1件以上ある、または再現に必要な情報が欠けていないことを第三者が確認できる

3 を満たさないものは「構築中」であって、再現可能な環境に数えません。

— この 3 が重い。自分の手元で動いただけでは、数に入らない。

入りません。動いたことと、他人が動かせることは別です。前者は自分で確認できる。後者は自分では確認できない。

このシリーズが積み上げるのは、後者です。

Mission

このプロジェクトの目的を3行にしました。

Physical AI が学習できる環境を継続的に構築する。 その知見を再現可能な形で公開する。 誰でも同じ環境から Physical AI 研究を始められる状態を増やす。

最初に書いた3行目は「社会へ還元する」でした。

— それは誰でも書ける。前2行には実体があるが、3行目だけ抽象度が跳ねていて、この一文だけでは何も判断できない。Mission が全体の判断軸になるなら、ここが飾りだと軸が効かない。

還元先を具体化しました。ロボットに手が届かなかった人が、同じ環境を再現できる状態にする。これなら Mission と主指標が同じ言葉でつながります。環境を作る。再現可能にする。数える。

事業か、転職か

もう一つ、決めたことがあります。

以前は転職か事業かで揺れていました。ロボット企業への転職も実現していない、と Journal に書いています。

研究室を作る時点で「個人として研究基盤を持つ」という意思決定をしている。研究室は会社に依存しない。

だから主は事業。従は共同研究・アドバイザー・R&D契約・必要なら企業参加。転職は「可能なら歓迎」の位置づけです。

— これを上位文書に書くなら、その決定が何を捨てる決定なのかまで書かないと後で効かない。事業を主にするなら、収入は当面デザインの本業から出続ける前提になり、設備投資の回収も同じだけ先に伸びる。これは意気込みではなく家計の判断だ。

事業と転職は取るべき動きが逆になります。事業は概念オーソリティを、転職は実装力の証明を要求する。両方を同時に最適化しようとすると、どちらの打ち手も中途半端になる。この一文を上位文書に入れました。

設備を買う理由と、買わない理由

ワークステーションを自作するということは、ケース・電源・GPU・メモリと、一点ずつ買っていくということです。一括購入より歯止めが要ります。

投資方針をこう書きました。

設備投資は短期回収を目的としない。Physical AI で活動し続けるための研究基盤への投資である。 設備単体での ROI ではなく、研究成果・知見・ネットワーク・共同研究を含めた長期価値を評価対象とする。

半年後に RTX6080 や RTX7080 が出ても、判断基準がブレないようにするためです。

— ROI で判断しないと決めたなら、代わりの歯止めが要る。「短期回収を目的としない」だけでは、買わない条件がどこにもない。

そこで買う条件を3つ置きました。現在進行中の研究で実測されたボトルネックを解消するものであること。そのボトルネックがログまたは計測値として提示できること。解消後に何が可能になるかが Mission に照らして説明できること。

これは「測る手段を持つことが推論に先立つ」という原則の、設備投資版です。RTX6080 が出たとき、答えは自動的に出ます。いまの構成が何かのボトルネックになっているか。実測はあるか。なければ買わない。

— ただしこの条文は、最初の一台に適用できない。まだ存在しないマシンのボトルネックは実測できないからだ。

その通りでした。このままでは、最初の購入が条文違反になるか、条文を無視することになる。どちらでも文書は死にます。

初期構築と増強を分けました。

初期構築（1台目）
  Mission の3行を回すのに必要な最小構成で組む。
  用途が動くことが条件であり、余裕を持たせることは条件ではない。
  足りないことは実測できるが、余っていることは実測できない。

  上位グレードで迷ったら下を買う。
  ただし後から交換すると他のパーツまで巻き込むもの（電源・ケース・マザーボード）は、
  想定する増設まで届く構成で選ぶ。挿し替えで済むもの（GPU・メモリ・SSD）は下を買う。

  余裕・所有欲・将来不安は、上位を買う理由にならない。

増強（2台目以降・パーツ追加）
  1. 現在進行中の研究で、実測されたボトルネックを解消するものであること
  2. そのボトルネックが、ログまたは計測値として提示できること
  3. 解消後に何が可能になるかが、Mission の3行に照らして説明できること

「迷ったら下を買う」という一文には、こういう懸念があります。

GPUや電源のように交換コスト・安定性に直結するものでは、下を買うことで逆に高くつく可能性がある。

対案として出たのは、「Mission に直結する差分だけを残し、余裕・所有欲・将来不安だけなら下を買う」という書き方でした。

— 意図は正しい。ただ、その書き方だと、何が Mission に直結するかを買う直前の自分が決めることになる。GPU を前にした人間は、たいてい直結すると判断できる。歯止めとして緩む。

判定できる基準に置き換えました。後から交換するときに、他のパーツまで巻き込むかどうか。電源・ケース・マザーボードは交換すると全部バラすことになるので、想定する増設まで届く構成で選ぶ。GPU・メモリ・SSD は挿し替えで済むので、迷ったら下を買う。

これなら、電源 1200W が正当化されるかどうかも自動的に決まります。GPU 増設を想定するなら妥当。想定しないなら過剰です。

最初の適用に耐えられないルールは、はじめからルールではありませんでした。

メモリ128GBと電源1200Wの話

構成の検討では、メモリ 128GB、電源 1200W Platinum という案が出ていました。

9950X で 128GB は 4枚差しになり、DDR5 のクロックが落ちます。まず 64GB（32×2）、足りなければ 96GB（48×2）が定石です。Isaac Sim 用途でも 128GB が要る場面は限定的です。

5080 + 9950X なら電源は 850〜1000W Platinum で足ります。1200W は余剰ですが、GPU 増設を将来計画に入れているなら妥当。どちらの理由で選んだのかを書いておかないと、後で迷います。

Ubuntu のバージョンも未記載でした。ROS2 と Isaac Sim は対応 Ubuntu が縛られます。ここは変わりうる値なので、購入前に実測・確認する項目として置きます。

— ここまで書いた時点で、これらは上位文書に書くべきではないと分かった。

上位文書から数字を消した

このプロジェクトを始めるにあたり、すべての判断の上位参照ソースになっている文書を書き換えました。ドラフトは 578 行ありました。

設備構成表が入っていました。メモリ 128GB、電源 1200W、Ubuntu のバージョン。どれもまだ買っていない。「未確定」が4つ並んでいました。

— 内容が定期的に変わり、いつの時点のものかも分からない記述は、必要ないだけでなくプロジェクトの硬直化にもつながるのではないか。

これは FK テーブルの点数を文書に焼き、実体とズレたことに気づけなかった反省と、まったく同じ構造です。書いた瞬間から古くなる数字を上位文書に置くと、次に読む自分と AI を、静かに間違った方向へ引っ張ります。

判断基準を一本にしました。

残す = 判断の軸（迷ったときに答えが出るもの。滅多に変わらない） 消す = 時点の値（実測・別文書・その場で調べれば分かるもの）

これで消えたもの。設備構成表。フェーズロードマップの年表。市場の観察（誰がいま困っているか）。旧い値の表。制定経緯。長文の更新履歴。578 行が 292 行になりました。

冒頭に文書方針を1行入れました。「判断の軸だけを書く。時点の値は書かない」。これがあれば、次に誰かが設備表を足そうとしたときに止まります。

削らなかったものが一つあります。更新履歴です。

以前、上位文書に複製された旧方針が無注記のまま残り、数ヶ月「学習は自分の仕事ではない」という誤った枠組みで応答が続いた事故がありました。履歴を消すと、新しい値を旧い値と取り違える経路が復活します。ただし長文である必要はない。「何を判断として変えたか」だけを1行で残し、旧い値は本文に残さない。

硬直化させるのは「古い値が現行として残ること」であって、「変わった記録があること」ではありません。

もう一つ消しました。「月1回は 5,000字以上の重い記事を必ず書く」です。

5,000字は重くありません。フルコード・実機ログ全量掲載のルールがある以上、字数は勝手に積み上がる。しかも字数を基準にすると、文字数を数える作業が発生します。かつて wc -m をバイト数と取り違えて「1万字超」と誤判断し、足踏みしたことがありました。数字を消せば、あの計測作業ごと消えます。

「月1回は、研究ログをもとにした重い考察記事を出す。字数を基準にしない」に変えました。

タイトルが決まらなかった

この記事のタイトルは、何度も外しました。その過程も残します。

最初に出したのは「焼き付いた数字を消す ― MASTER をv2に書き換えた記録」でした。

えっ？そういう話じゃないけど？

その通りでした。上位文書の書き換えは、この日に起きたことの帰結にすぎない。しっぽを主題にしていました。

次に「主役が変わった」という構図を立てました。

Pixels to Motors の主役が変わった ― 記事を書くことから、研究環境を作ることへ

これに対して。

記事を書くことをメインにしていたつもりはないですよ。

これも正しい。記事は最初から研究の記録として書いてきた。それ自体を主役にしたことはない。「記事を書くフェーズが終わる」という構図は、実態とズレていました。

次は「サイトから研究環境へ」。

サイトから？どういうことですか？説明してください。

adaptdesign.jp/pixelstomotors のことですが、記事の外から見れば「何のサイト」で終わります。上位文書の名前を弾いたのと同じ理由で、内部の言葉をそのまま出していました。

「公開ログから研究環境へ」も出ました。これも一般名詞ばかりで、一覧に並んだとき何の記事か判別できません。

固有名詞がはっきりしなくて、何の記事かさっぱりわかりません修正してください。

そして着地したのがこれです。

今回は「考え方が変わった」が主役ではなく、「フィジカルAI研究室を作るプロジェクトを始める」が主役

宣言記事として書けばよかった。過去の総括ではなく、これから始めるものの第1回として。

この往復には、もう一つ副産物がありました。「約9ヶ月」と書いていたのを訂正されたことです。

7ヶ月ね

LOG276 という数字から月数を逆算していました。DAY は日数ではなく通し番号です。最初は1日1本だった。数字を割り算して期間を出すのは、実測ではなく推測です。この記事から期間の記述を落としました。

このシリーズで作るもの

環境を、順番に立ち上げていきます。

• ワークステーション（自作・Ubuntu）

• データ収集の経路

• 学習を回す環境

• 評価の仕組み

• 実験のループ

この4つ（データ収集・学習・評価・実験）が自分の手で回ることが、研究室が完成したという意味です。機体が何台あるかではありません。

途中で失敗したものも公開します。組み間違いも、選定ミスも、動かなかった構成も残します。それが再現可能性の一部だからです。成功した手順だけを並べたドキュメントは、他人の環境では動きません。

この記事自体も、そのやり方で書いています。外したタイトル案も、訂正された発言も、間違えた計算も残しました。

個人で作れるフィジカルAI の研究環境を、誰でも再現できる形で公開する。