Claude Code×Unityはどう使う？導入・CLAUDE.md・テスト自動化

Claude CodeはUnity開発で使えます。特に相性がよいのは、C#コードの調査・編集、コンパイルエラーの原因探索、テスト追加、Unity Test Frameworkのコマンドライン実行です。一方、Scene、Prefab、UI、アニメーション、操作感などの最終結果は、テキスト差分だけでは保証できません。Claude Codeへ変更を任せ、テストとUnity Editorで人が確認するところまでを一つの工程にします。

この記事は公式文書に基づく導入ガイドです。特定のUnityプロジェクトで実機検証した結果ではありません。

Claude CodeはUnity開発で何ができる？

Claude Codeの公式概要では、コードベースの読み取り、ファイル編集、コマンド実行が主要機能として説明されています。Unityでも、リポジトリ内にあるC#、テスト、設定、ドキュメントを対象にできます。

作業	相性	確認方法
C#の調査・小規模な修正	高い	コンパイル、EditModeテスト、差分レビュー
テストコードの追加	高い	Unity Test Frameworkの結果XML
重複コードの整理	高い	参照検索、テスト、Editorでの再コンパイル
Scene・Prefabの変更	慎重に扱う	差分、Editorでの再読込、Play Mode
UI・アニメーション・演出	補助用途	Game Viewと実機で目視確認
操作感・難易度・面白さの判断	代替できない	人によるプレイ確認

重要なのは、「Unityプロジェクトのファイルを編集できる」と「ゲームとして正しく見え、遊べる」を分けることです。Claude Codeは前者を高速化できますが、後者の検品責任までは自動的に引き受けません。

WindowsでClaude CodeをUnityへ導入するには？

まずClaude Codeをインストールし、Unityプロジェクトのルートで起動します。2026年6月21日時点の公式案内では、Windows PowerShellから次のコマンドでネイティブ版を導入できます。

irm https://claude.ai/install.ps1 | iex

導入後は対象プロジェクトへ移動して起動します。

cd C:\path\to\your-unity-project
claude

公式文書は、WindowsでBashコマンドを使う場合にGit for Windowsを推奨しています。PowerShellだけで運用する場合も、プロジェクトで使うコマンドの表記を統一しておくと、OS差による失敗を減らせます。

開始前に、次の状態を作ります。

1. UnityプロジェクトをGitなどのバージョン管理へ入れる
2. 未保存の変更を確認し、Claude Codeによる差分と混ざらないようにする
3. 使用中のUnityバージョンを確認する
4. Unity Editorでプロジェクトが正常に開くことを確認する
5. 可能ならEditModeテストを一度手動で成功させる

既存の不具合や大量の未コミット差分を残したまま始めると、Claude Codeの変更による問題かどうかを切り分けにくくなります。

Unity向けCLAUDE.mdには何を書く？

CLAUDE.mdは、Claude Codeがセッションごとに読むプロジェクト指示です。公式のメモリ説明では、プロジェクト構成、コーディング規約、ビルド・テストコマンド、ワークフローを記録する用途が示されています。

Unityでは、少なくとも「どこを編集するか」「どこを触らないか」「変更後に何を実行するか」を明記します。

# Unity project

- Unity version: 6000.0.x（実際のバージョンへ置換）
- Runtime code: Assets/Scripts/
- EditMode tests: Assets/Tests/EditMode/
- PlayMode tests: Assets/Tests/PlayMode/
- Do not edit generated directories: Library/, Temp/, Logs/, Obj/
- Do not change Packages/manifest.json or ProjectSettings/ without explaining the impact first.
- After C# changes, run the documented EditMode test command.
- Treat .unity, .prefab, and .asset edits as high-risk. Keep the diff small and require Editor verification.

この例はそのままコピーする完成形ではありません。実際のフォルダ、Unityバージョン、テストコマンドへ置き換えます。CLAUDE.mdを長い社内規程の置き場にせず、Claude Codeが毎回必要とする判断基準へ絞るのが実用的です。公式文書も簡潔に保つことを推奨しています。

また、CLAUDE.mdは指示文であり、強制的なアクセス制御ではありません。秘密情報や破壊的コマンドを確実に制限する場合は、次の権限設定を併用します。

権限はどこまで許可する？

Claude Codeの権限設定には、allow、ask、denyのルールがあります。Unityプロジェクトでは、最初から広い権限を与えず、読み取りと既知のテストコマンドから始めます。

初期方針は次のようにすると整理しやすくなります。

• コード検索とファイル読み取りは許可する
• C#の編集は毎回差分を確認する
• 既知のテストコマンドだけ許可候補にする
• ProjectSettings/とPackages/manifest.jsonの変更は事前説明を求める
• ファイル削除、Gitの履歴変更、外部送信は自動許可しない
• 方針検討だけを依頼するときはPlan Modeを使う

許可ルールは、実際に繰り返して安全性を確認できたコマンドから追加します。最初の数回は承認を残しておく方が、プロジェクト固有の副作用を把握できます。

Unity Test Frameworkをコマンドラインで実行するには？

Unity公式のTest Frameworkコマンドラインリファレンスでは、-runTestsと-batchmodeを使ってテストを実行できます。Windowsの例は次の形です。

$unity = "C:\Program Files\Unity\Hub\Editor\<UNITY_VERSION>\Editor\Unity.exe"

& $unity `
  -runTests `
  -batchmode `
  -projectPath "C:\path\to\your-unity-project" `
  -testResults "C:\path\to\test-results\editmode.xml" `
  -testPlatform EditMode

<UNITY_VERSION>、プロジェクトパス、結果ファイルの保存先は環境に合わせて変更します。-testPlatform PlayModeへ変えればPlayModeテストを指定できますが、まずは実行時間と対象を絞りやすいEditModeテストから組み込むと運用しやすくなります。

Claude Codeには「修正後にこのコマンドを実行し、失敗したテスト名と変更ファイルを報告する」と依頼します。テスト結果がXMLへ残るため、成功・失敗を会話上の自己申告だけで判断せずに済みます。

安全に任せる作業単位は？

Unityでは一度に大きく変更させるより、目的と検証方法を一つに絞ります。

1. 変更前に、原因仮説と対象ファイルを列挙させる
2. C#を中心に最小差分で修正させる
3. Git差分で無関係な変更がないか確認する
4. EditModeテストを実行する
5. 必要に応じてPlayModeテストを実行する
6. Unity Editorを開き、Console、Scene、Game Viewを確認する
7. 実際に操作し、入力、物理挙動、演出を確認する

例えば「プレイヤーが二段ジャンプできるようにして」だけでは、仕様の解釈が広すぎます。「既存の移動コンポーネントへ空中ジャンプ回数を1回追加し、着地時に回数を戻す。既存入力方式は変えず、EditModeテストを追加する」のように、変更境界と確認方法を同時に渡します。

Scene・Prefabを直接編集してよい？

最初の導入段階では、SceneとPrefabの直接編集を常用しない方が安全です。テキストとして差分を作れても、オブジェクト参照、GUID、シリアライズ順序、Inspector上の値が意図どおりとは限りません。

UnityはUnityYAMLMerge（Smart Merge）を提供しており、SceneとPrefabを意味的にマージできます。これはバージョン管理上の競合対策であり、AIによる変更がゲーム上正しいことを保証する仕組みではありません。

Scene・Prefabを変更する場合は、次を最低条件にします。

• 変更前のGit状態を明確にする
• 一つのSceneまたはPrefabだけを対象にする
• 大量の再シリアライズ差分が出たら中断する
• Unity Editorで開き直してConsoleを確認する
• 参照、Inspector値、Play Modeの挙動を確認する
• チーム開発ではUnityYAMLMergeの設定を共有する

Unity向けMCPは必要？

導入時点では必須ではありません。Claude Code本体だけでも、C#の編集、リポジトリ検索、Unityのコマンドライン実行まで進められます。

MCPやUnity Editor拡張を追加する価値が出るのは、Hierarchy取得、Editorコマンド実行、Scene操作などを会話から呼び出したい段階です。ただし、拡張ごとに提供元、対応Unityバージョン、外部送信、実行可能な操作が異なります。次の項目を確認してから導入します。

• 公式または信頼できる提供元か
• ソースコードと更新履歴を確認できるか
• 読み取りと書き込みの権限を分けられるか
• 対応するUnity・Claude Codeのバージョンが明記されているか
• Scene変更を取り消す手段があるか

MCPを入れること自体を目的にせず、ファイルとコマンドだけでは解決できない反復作業が生じてから追加する方が、原因を切り分けやすくなります。

最初に任せるなら何がよい？

最初の一件には、結果を自動検証しやすい作業を選びます。

• コンパイルエラーの原因調査と小規模修正
• 純粋なC#ロジックへのEditModeテスト追加
• 重複したユーティリティ処理の整理
• nullチェックや境界値処理の追加
• API変更に伴う呼び出し箇所の列挙
• READMEや開発手順の更新

逆に、複雑なScene再構成、Animator Controllerの全面変更、マテリアル調整、カメラ演出、ゲームバランス判断は、初回の自動化対象には向きません。

Claude Code×Unityの要点は、AIへUnity開発を丸ごと渡すことではありません。コードを速く調べて直す工程はClaude Codeへ寄せ、ゲームとして成立しているかはテストとEditorで確認する。この境界をCLAUDE.md、権限、コマンドラインテストとして固定すると、単発のチャットではなく継続可能な開発フローになります。