# 検証依頼（敵対的検証）：Pixels to Motors データ索引と、データの質を上げる仕組みの「作る前の設計」

作成：Claude（2026-11-01）　依頼者：エイイチ
対象：まだ作っていない索引の **設計案**（「設計案」節）、**データの質を上げる仕組みの設計案**（「追加の設計案」節）と、その前提にした Claude の調査結果

---

## あなたの役割

この設計案は Claude が書いた。同じ書き手の確認は同じ盲点を持つ。
あなたは **「この設計案は前提が間違っているか、作っても役に立たないか、データを壊す危険がある」という前提で、その証拠を探す** 役割を担う。

- 「たぶん大丈夫」は書かない。OK と判定する項目には、**実行したコマンド・数えた件数・比べた値** を証拠として添える。
- 下の「Claude の調査結果」を **信用しない**。実フォルダを自分で数え、自分で開いて確かめる。
- 「もっと良い方法がある」と思ったら、遠慮なく対案を出す。設計案を守る必要はない。

---

## 守ること（禁止事項）

- 下の対象フォルダは **すべて読むだけ**。変更・移動・削除・リネームをしない。
- 書いてよいのは `PixelstoMotors/_index_review/` の中だけ（報告と一時ファイル）。
- git 操作（commit・push・clean・checkout 等）をしない。
- `/Volumes/KIOXIA` 直下の `*_api_key.txt`・`*_token.txt`・`*_key.txt`・`keys/` は **開かない**（存在の確認だけ可）。
- KIOXIA は外付け SSD で `find` が遅い。全体を何度も走査せず、深さを絞るか1回の結果をファイルに保存して使い回す。

---

## 対象フォルダ（Mac 上のパス）

| 呼び名 | パス | 中身 |
|---|---|---|
| iCloud | `~/Library/Mobile Documents/com~apple~CloudDocs/デスクトップ/ADAPT DESIGN/じぶんの/PixelstoMotors/` | 記事の作業ファイル・調査メモ・サイトアーカイブ・依頼箱など |
| KIOXIA | `/Volumes/KIOXIA/r2r2r-data/` | 実機ログ・台帳・データセット・checkpoint・録画・lab・vision・動画 |
| コード | `~/r2r2r-scripts/` | 実機・学習のコード（git） |
| その他 | `~/pixelstomotors/`（cad のみ）、GitHub `PixelstoMotors/p2m-site`（公開サイト） | |

置き場所のルールの正：`iCloud/マスターMD/MASTER.md` の「保存先テーブル」と、KIOXIA の台帳ルール `data_manifest_rules.md`（Claude の Project 側にあり、手元にない場合はスキップ可）。

---

## Claude の調査結果（設計の前提。すべて疑って確かめること）

1. **既にある索引**
   - 公開記事・マンガ・図解・動画：`iCloud/site_archive/README.md` と `site_archive/index/00〜09`。2026-10-12 時点で止まっている。
   - 調査メモ：`iCloud/research/README.md`（10/30 まで更新）。
   - 実機の台帳：`KIOXIA/runs/README.md`・`runs/pick_place_ledger_v3.csv`・`runs/run_pick_place/index.csv`・`runs/handover_ledger_v1.csv`。
   - データセット：`KIOXIA/datasets/*/index.json`・`README.md`（フォルダごと）。
   - 依頼箱：`iCloud/依頼箱/README.md`。
2. **KIOXIA の `r2r2r-data/README.md` が古い**（最終更新 2026-06-13）。書かれているフォルダは datasets / recordings / runs / checkpoints / fk_tables / archive の6つだが、実際には lab / vision / videos / service_sim / diag / mecharm_calibration なども含めて13ある。
3. **3か所（iCloud・KIOXIA・コード）を横断して「何がどこにあるか」を引ける入口がない。**
4. **記事の Log 番号からデータ（runs・lab・datasets・checkpoints・recordings）へたどる対応表がない。** フォルダ名（例 `teach_poses_LOG352`・`lab/Log17`・`*_DAY281`）から推測するしかない。

## 設計案

- 新しく足すのは2つだけ：
  - `iCloud/INDEX.md`（索引本体・自動生成）
  - 生成スクリプト1本（置き場所は未定。候補は `~/r2r2r-scripts/tools/` か `iCloud/_index/`）
- 既存ファイルは読むだけ。書き換え・移動はしない。
- `INDEX.md` の中身：
  - **入口**：「知りたいこと → 開く場所」の表（3か所横断。既存の索引へリンクする）
  - **Log 対応表**：シリーズ／Log ↔ 記事の作業フォルダ ↔ KIOXIA のデータ。フォルダ名と日付から自動で結びつけ、結びつかないものは「未対応」として一覧に出す
  - **鮮度チェック**：中身と食い違っている README を一覧にする（例：KIOXIA の README に載っていないフォルダ）
- 更新：週1回スクリプトを実行して作り直す。数字は焼き付けず、毎回実測する。

---

## 確かめてほしいこと

### A. 前提は正しいか
A1. 調査結果 1〜4 はそれぞれ正しいか（証拠つき）。
A2. Claude が見落とした **既存の索引・台帳・一覧** はないか（`README*`・`*index*`・`*ledger*`・`*MANIFEST*`・`*一覧*`・`*台帳*` などを3か所で探す）。見落としがあれば、設計案の「足りないところ」は実在するのか。

### B. Log 対応表は作れるのか（いちばん重要）
B1. 番号の体系が何種類あるか数える（例：`DAY{NNN}`・`LOG{NNN}`・シリーズ内の `Log{NN}`・日付 `YYYYMMDD`・`run_{NNNN}`）。互いの対応は機械的に決まるか、決まらないか。
B2. 実際に **10件以上サンプル** を取り、記事の作業フォルダ ↔ KIOXIA のデータを手で結びつけてみる。フォルダ名・日付だけで正しく結びついた件数／誤って結びついた件数／結びつかなかった件数を数える。
B3. 自動の結びつけが **間違った対応を自信ありげに出す** パターンはあるか（同じ番号が別の意味で使われている等）。

### C. 作っても役に立つか・害はないか
C1. 自動生成した INDEX.md が古くなる・誤るパターン（KIOXIA 未接続で実行、iCloud の同期待ちのファイル、途中の書き込み中のフォルダ等）。
C2. iCloud 直下に生成ファイルを置くことの問題（同期の衝突・`INDEX 2.md` のような複製）。
C3. 走査のコスト（KIOXIA の videos/ や archive/ のように重いフォルダ）。週1回で現実的か。
C4. 秘密情報が索引に載る危険（KIOXIA 直下のキー類、`.env`、トークンなど）。除外の仕組みが要るか。
C5. 索引が MASTER の「保存先テーブル」と二重管理になり、食い違う危険はないか。どちらを正にすべきか。

### D. 対案
D1. 「索引ファイルを作る」より良い方法があれば出す（例：既存の各 README を最新化するだけで足りる／MASTER の保存先テーブルに「何があるか」の列を足す／各データフォルダに Log 番号のメタデータを置く規則を作る、など）。
D2. 設計案と対案のどちらを勧めるか、理由つきで。

---

## 追加の設計案：データの質を上げる仕組み（元データは変えない）

前提：**既存のデータ・LOG は一切変えない**（改変を始めるとキリがないため）。質は「元データの上と、これから取るデータ」で上げる。
ここでいう質は、中身の数値の良し悪しではなく、①由来がわかる ②抜けがない（対になるものがそろう）③使ってよいかがわかる ④一貫している、の4つ。

- **方法1：注記の台帳** — 元データの横に「このデータをどう扱うか」だけを書いた台帳を1本置く（正誤表の考え方）。列の案：対象パス／判定（学習に使う・参考のみ・使わない）／理由／根拠（LOG番号・記事DAY）／記入日。行は足すだけで、判定が変わったら新しい行を足す（書き換え・削除しない）。
- **方法2：これから取るデータに、取るときに情報を付ける** — 実機・学習のスクリプトが出力時に `meta.json` を横に自動で置く。中身の案：Log番号・コードの版（git のコミット番号）・使ったデータセット／checkpoint 名・機体・カメラ・主な設定値・成功／失敗／中断。規則（MASTER の保存先テーブルか data_manifest_rules.md）を先に書き、実装は Claude Code（r2r2r-scripts）。
- **方法3：自動の点検** — 索引の生成スクリプトに点検を持たせる。**見つけて報告するだけで直さない**。対象の案：台帳に行がない実行ログ／実行ログがない台帳の行、開けない・空・途中で切れたファイル（壊れた mp4・行数が合わない CSV）、中身が同じファイルの二重保存、`meta.json` のないこれからのデータ。
- **方法4：使うデータは選んで新しい版として作る** — 既に行っている形（`teach_v1` → `trim2` → `corr_v3`）を正式な規則にし、新しい版には「元はどれで何をしたか」を必ず書く。

勧める順番（Claude の案）：方法2 → 方法1 → 方法3 → 方法4。索引・注記の台帳・点検は1つの設計にまとめる想定。

### E. 確かめてほしいこと（データの質）

E1. 既存の仕組みとの重複：注記の台帳（方法1）は、既存の台帳（`pick_place_ledger_v3.csv` の verdict・reason 列、`handover_ledger_v1.csv`、datasets の README・index.json、MASTER・data_manifest_rules）と役割が重ならないか。重なるなら既存側で足りるのでは。新しい台帳を作ることが「1種類 = 1ルート」（MASTER）に反しないか。
E2. 方法2の現状：既に出力時にメタ情報を書いているスクリプト・データはあるか（例：`recording_meta.json`、runs の JSON、lab/Log の記録、datasets の index.json）。あるなら何が欠けていて、何が既に満たされているか。git のコミット番号が残っているデータはあるか。実在の例を3件以上挙げる。
E3. 方法3の点検を **実際に一部やってみる**：(a) `runs/run_pick_place/` の run と `pick_place_ledger_v3.csv` の行の突き合わせ（片方にしかないものの件数）、(b) datasets・checkpoints のうち元データや由来の記載がないものの件数。重い走査は避け、件数と例を報告する。
E4. 方法4：既存の派生データセット（trim・corr 系）に「元はどれで何をしたか」が実際に書かれているか。書かれていないものはどれか。
E5. 方法1〜4の優先順位は妥当か。元データを変えないという前提の下で、もっと効く方法はないか（対案があれば D と同じく理由つきで）。

---

## 報告の形

`_index_review/codex_report_YYYYMMDD.md` に書く。

各項目（A1〜E5）について：
- ✅ **OK** — 証拠（コマンド・件数・比べた値）
- ⚠️ **要注意** — 何が懸念か・どう直すか
- ❌ **NG** — 前提の誤り・明確な問題（具体的なパスと修正案）

最後にサマリ：
- この設計案のまま作り始めてよいか
- 作る前に変えるべき点（優先順）
- データの質の仕組み（方法1〜4）について、採る・変える・採らないの判定と理由