⟐ Claude Code/2026-04-25上級

Claude Code で Unity ゲーム開発を加速する — C# 生成・MCP 連携・実機検証

Unity プロジェクトで Claude Code を最大限活用するための実践ガイド。C# スクリプト生成、Editor 拡張、Unity MCP、シーン操作の自動化、テスト戦略までを体系的に解説します。

✦ プレミアム記事

Unity でゲームを作っていて、「この処理は Claude Code に書いてもらった方が速いな」と感じる場面が増えてきました。一方で、Web 開発と違って Unity は「シーンの状態」「アセットインポート設定」「ビルド設定」など、エディタ内でしか観測できない要素が多く、Claude Code だけでは完結しない場面も多いのが現実です。

このガイドは、私が個人開発で Unity と Claude Code を併用する中で見つけた「効くやり方」と「効かなかったやり方」を、実コードと共にまとめたものです。Unity 6 系（2026 年時点）と Claude Code v2 を前提とします。

なぜ Unity 開発で Claude Code が刺さるのか

Unity 開発の作業時間を分解すると、シーン構築、アセット調整、C# 実装、ビルド検証、の 4 つに大別できます。このうち C# 実装は、Web 開発のコード生成とほぼ同じスキルセットで AI に任せられます。

しかし Unity ならではの難しさは、「コードを書いただけでは動作確認ができない」点にあります。スクリプトをアタッチする GameObject の構造、SerializeField で公開する変数の値、Layer や Tag の設定——これらが揃って初めて意図通りに動きます。

Claude Code が Unity で本当に効くのは、後述する Unity MCP サーバー を組み合わせて、エディタ内の状態を直接操作できるようにしてからです。コード生成と環境セットアップが切り離せないのが Unity の特徴であり、ここを連結できるかどうかで生産性が一桁変わります。

CLAUDE.md の書き方 — Unity プロジェクト固有の文脈を渡す

Unity プロジェクトで Claude Code を起動した時、最初に読み込まれるのが CLAUDE.md です。私が現在使っているテンプレートの抜粋を共有します。

# プロジェクト概要
 
これは Unity 6.0.x で作っている縦スクロールアクションゲームです。
ターゲット: iOS / Android（IL2CPP, ARM64）
レンダリングパイプライン: URP 17.x
入力: Input System Package（旧 Input Manager は使用しない）
 
# ディレクトリ規約
 
- Assets/Scripts/Gameplay/ — ゲームロジック（MonoBehaviour 中心）
- Assets/Scripts/Systems/ — 永続データ・SaveLoad・Audio
- Assets/Scripts/UI/ — UI Toolkit ベースの UI
- Assets/_Project/Prefabs/ — プレイヤー・敵・アイテム
 
# コーディング規約
 
- using ステートメントは alphabetical sort
- private フィールドは _camelCase、public は PascalCase
- async/await は UniTask（Cysharp）を優先。素の Task は禁止
- DOTween を使う場合は SetLink で寿命管理
- ScriptableObject を「設定値の入れ物」として積極利用
 
# テスト方針
 
- PlayMode テストは Tests/PlayMode/ に配置
- EditMode テストは Tests/EditMode/
- アサーション: NUnit + UnityEngine.TestTools

ポイントは「Web 開発の常識を持ち込ませない」ための制約を明示することです。たとえば「Task は禁止、UniTask を使う」と書かないと、Claude は素の await Task.Delay() を平気で生成します。Unity では Task.Delay は MonoBehaviour のライフサイクルと連動せず、シーン遷移後にも走り続けてバグの温床になります。

また「URP を使っている」「Input System を使っている」は本当に重要で、書かないと URP 非対応のシェーダーや、旧 Input Manager 用の Input.GetKeyDown を生成されることがあります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦Unity プロジェクト構造に最適化した CLAUDE.md と AGENTS.md の書き方

✦Unity MCP サーバーを使ったシーン操作・コンポーネント生成の自動化

✦実機ビルド・PlayMode テストまでを Claude Code に委ねる開発フロー

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

Unity MCP サーバーで「シーン操作」まで自動化する

Unity 公式の Unity MCP（Model Context Protocol）サーバーを導入すると、Claude Code から直接 Unity Editor の操作ができるようになります。具体的には次のような操作です。

アクティブなシーンの GameObject 一覧の取得
新しい GameObject の生成、コンポーネントの追加
Inspector フィールドの設定、Prefab 化
メニューコマンドの実行（File > Build Settings 等）
Console ログのリアルタイム取得

導入手順は次の通りです（Unity Package Manager 経由）。

# 1. Unity プロジェクトのルートで package.json を編集
# Packages/manifest.json に以下を追加:
{
  "dependencies": {
    "com.unity.mcp.server": "1.x.x"
  }
}
 
# 2. Claude Code 側の設定
claude mcp add unity-editor \
  --command "node" \
  --args "/path/to/unity-mcp-bridge/index.js" \
  --env UNITY_PROJECT_PATH=/path/to/your/project

私が特に重宝しているのは「シーン内のオブジェクト名を一覧して、その中の特定のコンポーネント設定を読む」ためのツールです。これがあると、Claude にシーン構造を説明する手間がほぼゼロになります。

実際の使用例を一つ。「プレイヤーの移動速度を 5.0 から 7.5 に変えて、その変更を加速度センサーで微調整できるようにしたい」と頼むと、Claude Code は次の流れで作業を進めます。

unity_get_scene_objects を呼んで Player GameObject を特定
既存の PlayerMovement スクリプトを Read
moveSpeed フィールドを 7.5 に書き換え
IAccelerometerInput インターフェースを新規作成
PlayerMovement を編集して新インターフェース対応に
Inspector で SerializeField の参照を Wire-up
PlayMode テストを起動して挙動確認

ここまでを人間の介入なしで完了します。これは Web 開発の感覚で言えば、「テキスト指示→実装→ステージング環境で動作確認」までを通しで AI に任せられるということです。

C# スクリプト生成の精度を上げるための小技

MonoBehaviour ライフサイクルを明示する

Unity の MonoBehaviour には Awake、Start、OnEnable、Update、FixedUpdate、LateUpdate など多くのライフサイクルメソッドがあります。Claude Code は Web 開発寄りの学習データの影響で、何でも Start に書きがちです。

依頼時に「初期化は Awake、有効化のたびのリスナー登録は OnEnable、解除は OnDisable」のようにライフサイクル方針を伝えると、出力の質が大きく上がります。

名前空間を必ず指定する

using UnityEngine; だけ書かれて、UnityEngine.UI や UnityEngine.InputSystem の追加 using が抜けているケースがよくあります。CLAUDE.md に「UI Toolkit を使う」「Input System を使う」と明示しておくと、必要な using を揃えてくれる確率が上がります。

ScriptableObject 経由の設定値を提案させる

ゲームバランス調整に関わる数値（ジャンプ力、敵の HP、アイテムの効果時間など）は、コード内のリテラルで持つよりも ScriptableObject で外出しする方が後の調整が楽です。Claude Code は明示的に頼まないと数値をハードコードしがちなので、「数値パラメータは ScriptableObject に分離してください」と最初に伝えてください。

実機ビルドの検証まで自動化する

Unity MCP の execute_menu_item を使うと、File > Build And Run までを Claude Code から実行できます。実機（iOS/Android）への転送は Xcode や Android Studio に渡る部分が残るため完全自動化はまだ難しいですが、ビルドが通るかどうかの確認 までは AI に任せられます。

私が回しているフローは次の通りです。

1. Claude Code に新機能を実装してもらう
2. PlayMode テストを書いて、エディタ内で動作確認
3. unity_execute_menu_item で「Player Settings の検証」を呼ぶ
4. ビルドエラーがあれば Console ログを取得して Claude に修正依頼
5. 通ったら Build And Run

このサイクルで、人間がチェックするのは「実機での操作感」だけになります。「コードがビルドエラーを起こさないか」を AI に任せられるだけで、開発体験は別物になります。

エディタ拡張（Editor Window）の生成は意外と得意

Unity 開発で地味に時間を取られるのが、自作のエディタウィンドウ（バランス調整パネル、ステージエディタ、デバッグ用ツールなど）の作成です。EditorWindow を継承して OnGUI を書く、というおなじみの作業ですが、Claude Code はこれを驚くほどきれいに書きます。

たとえば「敵パラメータを ScriptableObject から読み込んで一覧表示し、その場で編集して保存できるエディタウィンドウを作って」と頼むと、SerializedObject と EditorGUILayout を駆使した適切な実装が返ってきます。Web 開発で「管理画面を作って」と頼むのと同じ感覚で、Unity 内ツールを生成できると考えるとイメージしやすいでしょう。

やってはいけないこと

ここまで効果的な使い方を紹介してきましたが、避けた方がよいパターンも共有します。

シェーダー（HLSL）の生成は要注意

URP の Shader Graph 経由ではなく、生の HLSL を Claude に書かせると、シェーダーのバージョン違い・パイプライン違いで動かないコードが出ることが多いです。シェーダーは Shader Graph で組んで、Custom Function Node 内のコードだけ Claude に頼むのが安全です。

アセットの import 設定を一括変更させない

AssetImporter を経由したテクスチャ圧縮設定の一括変更などを Claude に頼むと、想定外のアセットまで巻き込んで圧縮形式が変わることがあります。バッチ処理は必ず対象を絞ってからお願いしてください。

シーン.unity ファイルの直接編集は避ける

.unity ファイルは YAML ですが、人間が直接編集してもよい構造ではありません。Claude が「このシーンファイルを編集します」と言い出したら止めて、Unity Editor 内での操作に切り替えてください。

エディタを開かずに検証する — Unity バッチモードで compile とテストを回す

前節の Unity MCP を使った検証は、Unity Editor が起動していることが前提です。ただ、個人開発で夜間の自動処理に回したいときや、Editor を開かずにコンパイルだけ先に通しておきたいときには、別の経路が要ります。

Unity には、GUI を開かずにコマンドラインから起動する -batchmode があります。ここに -runTests を足すと、EditMode テストまでヘッドレスで走ります。

# コンパイル + EditMode テストをヘッドレスで実行
"/Applications/Unity/Hub/Editor/6000.0.30f1/Unity.app/Contents/MacOS/Unity" \
  -batchmode -quit \
  -projectPath "$PWD" \
  -runTests -testPlatform EditMode \
  -testResults "$PWD/TestResults/editmode.xml" \
  -logFile "$PWD/Logs/unity-batch.log"

-quit を付けると、テスト終了後に Unity が自分で閉じます。コンパイルエラーがあればこの時点で -logFile に落ちるので、Editor を開いてコンソールを目で追う手間が要りません。

Claude Code からは、この一連を薄いラッパーにして呼ばせるのが実用的です。私は次のようなスクリプトを用意し、実装のたびに走らせています。

#!/usr/bin/env bash
# run-unity-tests.sh — 失敗だけを Claude に戻す
set -euo pipefail
UNITY="/Applications/Unity/Hub/Editor/6000.0.30f1/Unity.app/Contents/MacOS/Unity"
"$UNITY" -batchmode -quit -projectPath "$PWD" \
  -runTests -testPlatform EditMode \
  -testResults "$PWD/TestResults/editmode.xml" \
  -logFile "$PWD/Logs/unity-batch.log" || true
 
# NUnit XML から失敗ケースだけ抜き出す
if grep -q 'result="Failed"' "$PWD/TestResults/editmode.xml" 2>/dev/null; then
  echo "=== FAILED TESTS ==="
  grep -A2 'result="Failed"' "$PWD/TestResults/editmode.xml"
  exit 1
fi
echo "All EditMode tests passed."

このスクリプトが exit 1 を返したときだけ、失敗ケースのログを Claude Code に渡して直してもらいます。全ログを毎回貼るより、失敗箇所に絞る方が対話が速く、トークンも無駄にしません。

コンパイルエラーはこの経路で早く拾えますが、シーン依存の不具合はバッチモードでは再現しないことがあります。どちらの経路で拾うべきかを最初に決めておくと、無駄な手戻りを回避できます。MCP 経由の検証は「Editor の中で今どう動くか」を確かめる用途に、バッチモードは「Editor を開かずにコンパイルとロジックのテストを通す」用途に、と切り分けています。私自身、個人開発で Dolice のアプリを一人で回していると、この二段構えが夜間の自動処理でそのまま効いてきます。

次に試すこと

このガイドの内容のうち、まず一つだけ試すなら Unity MCP の導入 です。CLAUDE.md の整備は後からでも追加できますが、エディタ操作が AI から呼べるようになると、Claude Code との対話の質そのものが変わります。「シーン内に何があるか」を毎回テキストで説明する手間がなくなるだけで、Unity 開発における AI ペアプログラミングは現実的なものになります。

そこまで来たら、CLAUDE.md を自分のプロジェクト固有の規約で埋めて、いつもの C# コーディング規約・命名規則・利用ライブラリを書き出してみてください。Claude Code の出力品質は、この設計図の精度にほぼ比例します。