Claude CodeでUnity開発を並列化する方法【git worktree×複数セッション】
はじめに
1つのUnityプロジェクトで、複数の機能を同時に開発できたらいいなと、
そんなことを考えたことはないでしょうか。
僕は最近、個人で開発しているゲーム内の2つの機能
- パズル
- ストーリーエンジン
を同時並行で進めるという実験をしました。
Claude Codeのセッションを1つのUnityプロジェクトで2つ起動し、それぞれに別の機能を担当させる感じです。
結果として、同時に複数の機能が同時に進捗していく体験はかなり面白いものでした。
ただし上手くやるにはコツがあります。
本記事ではClaude Codeを使ったUnity並列開発の具体的なやり方と、実際にやってみて分かった注意点をまとめます。
結論
Claude Code × git worktreeで、1つのUnityプロジェクトの複数機能を同時開発できます。
ポイントは3つ。
- 機能ごとにワークツリーを分け、ファイルが競合しない設計にする
- AssemblyDefinitionでコードの依存関係を物理的に分離する
- チーム開発の作法（シーンやPrefabの排他管理）をそのまま適用する
git worktreeとは？
並列開発の核となるのが git worktree です。
普段のgit開発では、1つのリポジトリに1つの作業ディレクトリがあります。
ブランチを切り替えるには git checkout や git switch を使いますよね。
git worktreeは、1つのリポジトリから複数の作業ディレクトリを作る機能です。
# メインの作業ディレクトリ（通常通り）
~/Projects/MyGame/ ← feature/puzzle ブランチ
# worktreeで追加した作業ディレクトリ
~/Projects/MyGame-story/ ← feature/story-engine ブランチ
こんなイメージになります。
それぞれのディレクトリが独立したブランチで動作するため、片方でコードを変更しても、もう片方には影響しません。
worktreeの作り方
# リポジトリのルートで実行
git worktree add ../MyGame-story feature/story-engine
これだけで ../MyGame-story/ に新しい作業ディレクトリが作られます。
Unityプロジェクトの場合、ワークツリーごとにUnityエディタを起動できます。
初回だけLibraryフォルダの生成に時間がかかりますが、以降は快適に使えます。
worktreeの削除
# 不要になったら削除
git worktree remove ../MyGame-story
並列開発の全体像
僕が実践した構成はこうです。
| セッション | 担当機能 | ブランチ | 作業ディレクトリ |
|---|---|---|---|
| Claude Code #1 | パズル（InGame） | feature/puzzle | ~/Projects/MyGame/ |
| Claude Code #2 | ストーリーエンジン | feature/story-engine | ~/Projects/MyGame-story/ |
2つのClaude Codeセッションを別々のターミナルで起動し、それぞれに機能開発を指示していきます。
競合しない設計が最重要
なぜ「別機能」でないとダメなのか
同じセクションを2つのセッションで同時に開発すると、ほぼ確実にコンフリクトします。
同じファイルを両方が編集してしまうためです。
gitのマージで解決できる場合もありますが、C#コードならまだしも、Unityのシーンファイル（.unity）やPrefab（.prefab）がコンフリクトすると手動解決はかなり厳しいです。
だから 「そもそもファイルが被らない」設計 が大前提になります。
実際のディレクトリ分離
僕のプロジェクトでは、パズルとストーリーエンジンでファイルの配置場所を完全に分けました。
Assets/Project/
├── StoryEngine/ ← ストーリーエンジン専用
│ ├── Runtime/
│ └── Tests/
├── Presentation/
│ └── InGame/ ← パズル専用（View層）
├── Domain/
│ └── InGame/ ← パズル専用（ドメイン層）
└── Application/
└── InGame/ ← パズル専用（アプリケーション層）
ストーリーエンジンは Assets/Project/StoryEngine/ に完全に閉じています。
パズルは Presentation/InGame、Domain/InGame、Application/InGame に分散していますが、いずれもストーリーエンジンとはディレクトリが被りません。
仕様書やプランデータも同様です。
Docs/Plans/
├── StoryEngine/ ← ストーリーエンジンの仕様
└── InGame/ ← パズルの仕様
こうすることで、2つのセッションが同時にファイルを触っても、コンフリクトが起きる可能性は極めて低くなります。
AssemblyDefinitionで依存を物理的に断つ
ディレクトリを分けただけでは、コード上の依存関係までは制御できません。
ここで活きてくるのが AssemblyDefinition（asmdef） です。
App.StoryEngine.asmdef ← ストーリーエンジン専用
App.Presentation.InGame.asmdef ← パズルView専用
App.Domain.InGame.asmdef ← パズルドメイン専用
App.Application.InGame.asmdef ← パズルアプリケーション層専用
asmdefでアセンブリを分割すると、明示的に参照を追加しない限り他のアセンブリのコードにアクセスできません。
つまり 仕組みとして不正な参照を弾ける わけです。
パズル側のコードからストーリーエンジンのクラスを参照しようとしても、コンパイルエラーになります。
これは並列開発において非常に心強い安全装置になります。
Claude Codeが「便利だから」と別セクションのコードを勝手にusingしてしまう事故を、アーキテクチャレベルで防げるからです。
チーム開発の作法がそのまま活きる
並列開発で気をつけるべきことは、実はチーム開発で当たり前にやっていることと同じです。
- 被りそうなシーンファイルを同時に更新しない
- 被りそうなPrefabを同時に更新しない
- 共有リソース（共通UI、設定ファイル）は事前に整えておく
ゲーム開発では昔からこの作法が根付いています。
シーンファイルやPrefabはバイナリ的な性質を持つため、マージが困難だからです。
Claude Codeに作業を任せる場合も全く同じ。
つまり、チーム開発の経験がある人なら、並列AI開発への移行は自然にできます。
共通UIコンポーネントの扱い
ただし、完全に干渉ゼロにするのは難しいケースもあります。
僕のプロジェクトでは、パズルとストーリーエンジンの両方が使う可能性があるのは 共通UIコンポーネント くらいでした。
ボタンやリストといった汎用的なUI部品です。
これに対する対策は2つ。
1. 並列開発を始める前に共通UIコンポーネントを整えておく
僕の場合、CommonButton などの共通ボタンコンポーネントを事前に Shared 層に作っておきました。
並列開発中にこの層を変更する必要が出ないように、先に基盤を固めておくのがコツです。
2. 共通コンポーネントには変更を加えない前提で進める
もし共通UIの変更が必要になった場合は、片方のセッションを止めてから対応します。
「同時に同じファイルを触らない」原則を守ることが大切です。
CLAUDE.mdなどの共通ファイル
CLAUDE.md や CODING_GUIDELINES.md は全セッションが参照する共通ファイルです。
これらでコンフリクトが起きる可能性はゼロではありません。
ただ、経験上そこまで頻繁に変更が入るファイルではないので、許容範囲として割り切っています。
実際にやってみて分かったこと
今回Claude CodeでUnity並列開発を試してみて、面白かった点と、問題点がわかったので簡単にまとめてみました。
面白い点
同時に2つの機能が進捗していくのは、純粋に面白いです。
パズルの方でドラッグ&ドロップの実装が進んでいる横で、ストーリーエンジンのDSLパーサーが出来上がっていく。
仕様に沿って必要コマンドの作成から、テストケースまで一気に作ってもらいました。余談ですが、テストはもはやAIが書く時代だなって思いました。
パズル側ではボード復元、パズルピースの放出、マージ判定と、ゲームプレイの核となる部分が並行して組み上がっていきました。
1人でやっていたら直列にしか進められないところが、同時に動いている。
この感覚はかなり新鮮です。
問題点その1：マシンスペック
UnityEditor × 2、Rider × 2と、重めのアプリケーションを同時に起動することになります。
さらにClaude Codeも2セッション分のターミナルが必要です。
ある程度のマシンスペックがないと、全体がもたつきます。
メモリは最低でも32GB、できれば64GBは欲しいところです。
問題点その2：脳の疲労
これは想像以上でした。
パズルの実装状況を確認して指示を出し、すぐにストーリーエンジン側に切り替えてレビューする。
しょっちゅう頭の切り替えをする必要があるので、思っている以上に脳が疲れます。
同じUnityプロジェクトを複数起動しているため、時々どちらのエディタで作業しているのか間違えてしまうこともありました。
この「コンテキストスイッチのコスト」は、チーム開発でリーダーをやった経験がある人なら分かるかもしれません。
複数のメンバーの進捗を同時に追いかける感覚に近いです。
問題点その3：Unityエディタの取り違え
同じプロジェクトのUnityエディタが2つ開いていると、見た目がほぼ同じです。
「あ、こっちストーリーエンジン側だった」と気づいて戻ることが何度かありました。
ウィンドウのタイトルバーにブランチ名が表示されるわけではないので、自分で工夫が必要です。
Claude Code × Unity並列開発を始めるためのチェックリスト
これから試してみたい方向けに、チェックリストをまとめてみました。
- 並列開発する機能同士のディレクトリが完全に分離しているか
- AssemblyDefinitionで機能間の依存を断っているか
- 共通UIコンポーネントは事前に整備済みか
- 仕様書・プランデータのディレクトリも分離しているか
- 共有シーン・共有Prefabを同時に編集しない運用ルールがあるか
- マシンのメモリは十分か（32GB以上推奨）
- 複数のUnityエディタを区別する方法を決めているか
まとめ
Claude Code × git worktreeで、Unityプロジェクトの並列開発は実現できます。
ポイントを簡単に振り返ります。
- git worktreeでブランチごとに独立した作業ディレクトリを作る
- 競合しないようにディレクトリ設計とAssemblyDefinitionで物理的に分離する
- チーム開発の作法（シーン・Prefabの排他管理）がそのまま使える
- 同時進行は面白いが、マシンスペックと脳の疲労はネックになりそう
個人開発でも「チーム開発の経験」が活きる場面が数多くありそうです。
AIに複数のタスクを並列で任せやすい環境構築が今後重要になる気がしています。
今回の検証からAI時代のゲーム開発について色々考えたのでnoteにまとめました。
※メンバーシップ記事です
AI時代のゲーム開発と並列開発の話
Discussion