@Yodokoroさんの「Claude Code×Udon Sharpで同期付きギミックをVibe Codingする」に触発されました。
結論は「同期はまだ早い」「完全なVibesだけでは無理」というもので、多くの人の肌感覚と一致する内容だと思いますが、わたしの経験ではかなり重厚なギミックをClaude Codeで開発することができました。
全てが完全なVibesで通ったわけではありませんが、一度パターンを確立すれば、以降は参考にさせるだけでかなり上手くいくというのが大きな発見でした。
開発スタイル
前提として、私はUdonSharp開発経験あり、Claude Code課金勢、Unity用MCPは不使用です。
開発フローとしては、まずClaude chat（claude.ai）で設計検討を行い、アーキテクチャや同期方式をMarkdownの設計ドキュメントにまとめます。次にそのMarkdownを元にClaude Codeで実装を進めます。実装中に問題が見つかればClaude Code上で設計を修正し、そのまま実装に反映するというサイクルを回しています。「何を作るか」はClaude chatで設計し、「どう書くか」はClaude Codeに委ねる分業です。
これは実装精度の向上もありますが、私が外出先で思いついたアイデアをすぐさま設計に落とし込んでいるため、Chatを利用する方が便利だからです。
作ったもの
TeamLotterySystem
VRChatワールド用のチーム抽選システムです。プレイヤーが立候補し、抽選ボタンで2チームにランダム振り分けします。PlayerObjectとSendCustomNetworkEventを活用し、複数プレイヤーの同時操作に耐える同期パターンを確立しました。
VAIRS（Virtual Aviation Integrated Radar System）
VRChat航空向けの統合航空システムです。Managerコンポーネントはワールド内航空機や無線標識などの位置・高度・速度そのほかSquawkなど情報はBeaconとして定義し、一元管理する仕組みで、Displayを実装・拡張すればさまざまな用途に対応できる拡張性を持たせています。管制レーダー、ND、PFD、ILSになど対応しました。地形画像はエディタ上で事前ベイクしています。
うまくいったこと
「参考にさせる」戦略
VRCSDKの同期はClaude Codeにとって鬼門です。OnDeserializationのタイミング、オーナーシップ、Late Joiner対応など、学習データに十分な情報がなく、何も知らない状態で書かせると矛盾だらけになります。これはYodokoroさんの記事の通りです。
しかし、一度正しく動く同期パターンを作れば状況は一変します。 TeamLotterySystemで確立した同期パターンの実装をVAIRS開発時に参考コードとして渡したところ、試行錯誤が大幅に減りました。最初の1システムは人間が深く関与して確立し、2つ目以降はそれを参照させるということが非常に有効でした。
現在開発中の別システムでも、同様に既存実装を参照させることで実装・デバッグに掛かる工数を大幅に削減できています。
設計ドキュメント駆動
Claude chatでの設計結果がMarkdownとしてそのままClaude Codeへの入力になるため、意図が伝わりやすくなります。VAIRSの「Managerコンポーネントのデータ取得」と「Display」の分離アーキテクチャもClaude chatでMarkdownにまとめてから実装に入りました。設計が明文化されていたおかげで、各Display（管制レーダー、ND/PFD、ILS）の実装を迷いなく書けました。
エディタ拡張・Gizmo・レイキャスト
VRCSDKの制約がほとんど及ばない領域なので本領発揮してくれます。これはYodokoroさんの記事とも一致する結論です。
VAIRSではコンポーネント自動検出、ILSアプローチパスのGizmo可視化、レイキャストによる地形画像ベイク（等高線検出・高度別色分け含む）を書かせました。TeamLotterySystemではUdonSharpのstruct制約を回避するインスペクタUIを構築させました。
最初から完璧でなくとも、「エディタ側で変換してUdonSharp互換の配列のみシリアライズせよ」と方向を示せば軌道修正できます。
Gizmoについては、たしかに最初マップ生成範囲の可視化でかなり躓いていましたが、ILSアプローチパス周りは本当にうまくやってくれました。このあたりも同期実装同様に、実装例を蓄積することで精度が格段に向上する領域のようです。
うまくいかなかったこと
同期の初回実装
同期パターンの最初の確立には人間の深い関与が必要でした。OnEnableで同期変数を初期化しようとしたり、オーナーシップを無視した状態遷移を書いたりします。トラブルシューティングもかなり的外れだった事もあります。同期の設計は人間がアーキテクチャレベルで決定し、「この設計に従って実装して」と渡す形が最も効率的でした。
リファクタリングの一発通し
まとめてリファクタリングを依頼すると、構造的な改善よりコメント書き換えに注力してしまいます。観点を分けて段階的に依頼する（「コメントの日本語化」→「処理のモジュール化」→「不要コード削除」）のが有効でした。
まとめ
Yodokoroさんの「完全なVibesだけではまだ無理」には同意します。ですが、道の示し方次第でかなり遠くまで行けるというのが自分の実感です。
- Claude chatで設計→Markdown→Claude Codeで実装のフローで実装精度&生産性向上
- 同期パターンは最初に人間が確立し、2つ目以降は参照させるのが有効です
- エディタ拡張・Gizmoは存分に任せられます
- リファクタリングは観点を分けて段階的に依頼するのがコツです
エンジニアの言葉で方向を示せるなら、UdonSharpの重厚なギミック開発は十分に実用段階にあると感じています。