LOG83R2R2R2026/3/8

AIが壊して、AIが直した。Unityデータ消失から復元までの全記録

「面倒でもちゃんと動くことを優先して」

今朝、そう指示した瞬間から、地獄が始まった。

※注釈：デジタルツイン学習（R2R2R）の検証プロセス本プロジェクトは、AIの判断を物理的動作へ変換する設計を検証するものです。現実空間をデジタルツイン化し、仮想空間での大量試行（Real-to-Render）から得た最適解を、実世界のモーター駆動（to-Real）へ還元する「R2R2Rパイプライン」の実装過程を記録・考察します。

データが消えた日

AIが生成したスクリプトでUnityが壊れた

ロボットアームと小鉢が「すり抜ける」問題を解決しようとしていた。

UnityのArticulationBodyとMeshColliderが非互換という根本的な制約に直面し、「各リンクにBoxColliderを手動追加するEditorスクリプト」という泥臭い解決策を選んだ。面倒でも確実に動く方法を選んだはずだった。

ClineにEditorスクリプト AddRobotColliders.cs を生成させて実行。コンソールに表示されたのは：

Added 70 BoxColliders to RobotArmy objects.

成功に見えた。しかし再生した瞬間、コンソールが赤く染まった。

Non-convex MeshCollider with ArticulationBody is not supported.
エラー×62件

BoxColliderではなくMeshColliderが追加されていた。しかも firefighter オブジェクトにまで。Clineのクレジットも残り$0.01で止まった。

git resetで消えたシーンファイル

git reset --hard aae3712 で安定コミットに戻ろうとした。しかしシーンファイルがgitにコミットされていなかった。

続けて git clean -fd を実行した結果：

Removing Assets/Scenes/R2R2R-20260224.unity
Removing Assets/kobachi_2/
Removing Assets/Scripts/Editor/
Removing Assets/RobotMaterials/

シーン、小鉢アセット、スクリプト、マテリアル——全部消えた。背景がピンク一色になったUnityを見て、正直かなり焦った。

なぜ復元できたか：Unityはメモリを持っていた

ここで気づいた重要なこと。Unityを一度も閉じていなかった。

HierarchyにはRobotArmy10体、kobachi_2、defaultが残っていた。シーンデータはUnityのメモリ上に生きていた。すぐに File → Save As でシーンを保存した。

GeminiとUnity VCSで2月24日まで戻る

マテリアル消失による全ピンク状態はまだ残っていた。Geminiに相談しながら Unity Version Control（旧Plastic SCM） を活用する方針に切り替えた。

Changesets から cs:3（新しいSceneを作成） を右クリック → Switch to this changeset → ポップアップで Reload。

Check-in successfully completed. Changeset 4 was created.

2月24日の状態への復元、完了。

なぜこうなったのか

① AIに任せる前に、判断基準も一緒に渡すべきだった 「BoxColliderを追加して」だけでなく「ArticulationBodyと共存できる方法で」と渡すべきだった。AIは指示通りに動く。指示が曖昧なら、曖昧な結果が返ってくる。

② git cleanは危険 トラッキングされていないファイルも消える。Unityのシーンファイルは .gitignore に入りがちなので特に注意が必要だった。

③ Unityを閉じなければメモリは生きている パニックになっても、まずCmd+Sを押すべきだった。

④ VCSはCheck-inしておかないと保険にならない 今後は作業の区切りごとに必ずCheck-inを習慣化する。

なぜ「役割分担」を変えたか

午前の失敗を受け、午後の進め方を根本から設計し直した。

単に「次は気をつけよう」ではなく、AIと人間の役割を明確に分離するという方針転換だ。

人間がやること：

目で確認が必要な作業（小鉢の配置・サイズ確認）
判断が必要な局面（スケール・構造の決定）
安全確保（作業前後のVCS Check-in）

AIにやらせること：

コードの生成（ただしレビュー必須）
繰り返し作業の自動化
技術的な選択肢の提示

この「役割分担の再設計」が、午後の進め方の根幹になった。

小鉢をシーンへ、物理演算へ

小鉢（kobachi_2）の配置

3DpressoでスキャンしたOBJデータをUnityにインポート。Kobachiフォルダに Image_0（テクスチャ）、result（OBJファイル）、result（Prefab）が入った。HierarchyにドラッグしてScale 0.3で配置。kobachi_2（親）→ default（子） という構造が自然にできた。

RobotArmControllerが存在しない問題

動かしたい関節をアサインするため RobotArmController スクリプトを探した。Clineは「作成しました」と報告していたが、Projectウィンドウで検索しても何もヒットしなかった。

Geminiの分析：「Clineは作成したと報告したものの、実際にはファイルとして保存（Write）できていないか、違うディレクトリに作成してしまった可能性がある。」

AIが「完了した」と言っても、ファイルが実在するかを人間が目視確認するまで信用しない——午前の教訓がここでも証明された。

床の手動作成

物理シミュレーションには床（Collider付き）が必須だった。Clineには任せず手動で作成した。

Hierarchy右クリック → 3D Object → Plane
Scale：X/Y/Z = 10（実寸100m×100m）
マテリアル：マットなダークグレーを適用（Smoothnessを0に設定）
Mesh Collider が自動付与されていることを確認

床がマットになったことで、ロボットの白が映えて一気に「研究室」らしい雰囲気になった。

10cmグリッドのShader Graph実装——そして棚上げ

床の視認性を高めるため、Clineに10cm間隔のグリッドシェーダーを作成させた。Shader Graphを使ったワールド座標ベースの実装で、床のScaleに依存しない設計だった。

しかし途中でClineがJSON構文エラーを繰り返し引き起こした。ファイルが破損し、修正しようとするとまた破損する——という負のループに入った。

Geminiがリスクを検知：「Clineがループに入っている。トークンを浪費するだけなので棚上げにしましょう。」

「なんかできないね。別の方法させよう」

この判断は正しかった。Shader Graphの問題に時間を使いすぎることなく、本来の目的である物理演算のセットアップに切り替えられた。

小鉢の物理セットアップ

床が整ったところで、小鉢に物理的な実体を持たせる作業へ。Clineへの指示：

kobachi_2 に Box Collider（Convex）を追加
Rigidbody コンポーネントを追加、質量 0.1kg（100g）に設定
ロボットの指先が届く範囲の床の上に正確に配置
再生時に小鉢が床を突き抜けず正しく接地することを確認
ロボットの ArticulationBody の Stiffness(20,000) / Damping(2,000) には絶対に触れない

小鉢のスケールは約10.5cmとやや小さめ。エラーも出ていたが、Geminiのリスク検知により「MeshColliderではなくBox Colliderで代用するのが安全」という判断が下された。ロボットが接触できる「実体のある小鉢」としてシーンに存在するようになった。

1日を振り返って

朝から夕方まで、ほぼ1日中トラブルと向き合い続けた。

でも振り返ると、全てのトラブルが教訓に変わった。

AIを信頼しすぎると壊れる
でもAIなしでは復元もできなかった
Claude、Gemini、Clineという3つのAIを使い分けながら問題を解決した

R2R2Rプロジェクトのテーマは「Real to Render to Real」——現実をスキャンし、デジタルで再現し、また現実に戻す。

今日のこの1日も、その循環の中にある。失敗して、学んで、また前に進む。それ自体が、このプロジェクトのリアルな記録だ。