結論：Claude Codeは「プロジェクト全体のコンテキストを保ったまま C# / GDScript を生成できる」という点で、ゲーム開発者のコーディング工数を大幅に削減できる実用ツールです。
- 要点1：CLAUDE.mdにUnity固有のコーディング規約・プロジェクト設計を記述することで、生成コードのスタイルを統一できる
- 要点2：ScriptableObject / CSVのゲームバランスデータを一括生成するEditor拡張スクリプトを対話的に作れる
- 要点3：Godot GDScript・アセット命名規則チェック・プレイテストログ解析にも同じ手法が転用できる
対象読者：Unity 6.3 LTS / Godot 4.6を使うインディー・個人ゲーム開発者、ゲームスタジオのエンジニア
今日やること：Unityプロジェクトルートに最小構成のCLAUDE.mdを作成し、C#コンポーネントを1本生成してみる
Claude Codeとゲーム開発の相性
「Claude CodeってWebアプリ開発者向けでしょ？」
ゲーム開発のコミュニティで話すと、こういう反応が返ってくることがあります。実際のところ、Claude Codeはターミナルから動作する汎用AIコーディングツールであり、ゲームエンジン専用機能（シーンエディタへの直接操作など）は持っていません。
ただ、だからこそ面白いんです。Claude Codeが得意なのは「テキストとしてのコード」全般です。Unityのプロジェクト構造はすべてファイルシステム上のテキストです。C#スクリプト、ScriptableObjectのデータ定義、メタファイル、ProjectSettings——これらを一括で読み込んで文脈を把握した上でコードを書けるのが強みです。
動作確認環境（本記事）
- Unity 6.3 LTS（unity.com 公式、2026年リリース）
- Godot 4.6.2 stable（godotengine.org 公式、2026年4月リリース）
- Claude Code 最新版（2026年6月時点）
- macOS Sequoia / Ubuntu 22.04 LTS
CLAUDE.mdでプロジェクト規約を注入する
Claude Codeの最強機能のひとつが CLAUDE.md によるコンテキスト注入です。プロジェクトルート（Assets/ と同階層）に置くだけで、セッション開始時に自動で読み込まれます。
ゲーム開発特有の設定として、以下を書いておくと生成コードのスタイルが一気に揃います：
# Unity Project Rules — MyGame
## Engine & SDK
- Unity 6.3 LTS
- .NET Standard 2.1 / C# 9
- Universal Render Pipeline (URP)
- TextMeshPro 3.x
## Naming Conventions
- Classes: PascalCase (例: EnemyController, PlayerStats)
- Private fields: _camelCase (例: _health, _moveSpeed)
- Constants: ALL_CAPS (例: MAX_ENEMIES)
- ScriptableObject files: SO_{TypeName}_{Variant} (例: SO_EnemyConfig_Goblin)
- Prefabs: PFB_{Name} (例: PFB_Player)
- Scenes: SCN_{Name} (例: SCN_Stage01)
## Code Style
- MonoBehaviourは必ずpartialクラスで定義する
- [SerializeField]はprivateフィールドのみに使用
- NullReferenceを避けるため、GetComponent結果は必ずnullチェック
- coroutineは基本IEnumerator、複雑な非同期はUniTask使用
## Architecture
- GameManager: シングルトン、各Managerへの参照保持
- ScriptableObjectでゲームデータを一元管理
- Event-driven設計（UnityEvent / C#イベント）でマネージャー間の直接参照を減らす
## Assembly Definitions
- Core.asmdef: ゲームロジック
- Editor.asmdef: エディタ拡張（UNITY_EDITOR定義済み）
- Tests.asmdef: EditMode / PlayModeテスト
このCLAUDE.mdがあると、「PlayerのHPを管理するコンポーネントを書いて」と頼むだけで、プロジェクト固有の命名規則・アーキテクチャ方針に沿ったC#スクリプトが出力されます。
CLAUDE.md活用のポイント
- 短く・具体的に：「PascalCase」「_camelCase」のように例を1行添える。抽象的なルールだけ書いても効果が薄い
- アーキテクチャの全体像を書く：どのクラスが何を担当するか1段落で書いておくと、新しいクラスの設計も一貫する
- 外部ライブラリのバージョンを明記：UniTask / DOTween / Addressablesなど、バージョンによってAPIが変わるものは必ず書く
Unity C#スクリプト生成の実践
基本的なMonoBehaviour生成
最もシンプルな使い方は「既存スクリプトを渡してパターンを踏襲させる」です。
# プロンプト例（Claude Codeへの依頼）
EnemyController.csを読んで、同じパターンでBossEnemyController.csを作って。
追加の仕様：
- HPが50%以下で第2フェーズに移行（攻撃速度1.5倍）
- 死亡時にドロップアイテムをInstantiateする（アイテムはSO_DropTableで定義）
- デバッグ用に現在フェーズをGizmosで表示
不足している情報があれば、最初に質問してから作業を開始してください。
Claude Codeはまず EnemyController.cs を読み込み、クラス設計のパターン（イベント定義の仕方、SerializeFieldの使い方、コルーチンパターン）を把握した上でBossEnemyController.csを生成します。
生成されるコードのイメージ（一部抜粋）：
using UnityEngine;
using System;
public partial class BossEnemyController : MonoBehaviour
{
[SerializeField] private SO_DropTable _dropTable;
[SerializeField] private float _maxHp = 500f;
[SerializeField] private float _baseAttackInterval = 2f;
private float _currentHp;
private int _phase = 1;
private bool _isPhase2Active;
public event Action<int> OnPhaseChanged;
public event Action OnDeath;
private void Awake()
{
_currentHp = _maxHp;
}
public void TakeDamage(float damage)
{
_currentHp -= damage;
CheckPhaseTransition();
if (_currentHp <= 0f)
{
Die();
}
}
private void CheckPhaseTransition()
{
if (!_isPhase2Active && _currentHp / _maxHp <= 0.5f)
{
_isPhase2Active = true;
_phase = 2;
OnPhaseChanged?.Invoke(_phase);
}
}
// ... 省略
}
注意点：生成されたコードはUnityエディタで必ず動作確認してください。Claude Codeは現在のプロジェクトのコンパイルエラーを自動検知できないため、型名やメソッド名に誤りがある場合があります。特にUnity 6.3で変更されたAPIを参照している場合は、公式ドキュメント（unity.com/releases/unity-6）で確認することをお勧めします。
Input SystemとScriptableObjectを組み合わせた入力管理
Unity 6からInput Systemが標準推奨になりました。CLAUDE.mdに「Input Systemを使う」と書いておけば、InputAction関連のコードも適切に生成されます：
# プロンプト例
PlayerInputHandler.csを新規作成して。
要件：
- New Input System (InputAction)ベース
- 移動・ジャンプ・攻撃の3アクション
- InputActionAssetはResources以下のSO_PlayerInputで管理
- ジョイスティック対応（デッドゾーン0.15）
仮定した点は必ず「仮定」と明記してください。
ScriptableObjectとCSVによるゲームバランス一括生成
インディーゲーム開発で地味に時間を食うのが「ゲームバランスのデータ入力」です。敵キャラのHP・攻撃力・経験値を1体ずつUnityエディタでポチポチ入力するのは辛い作業です。Claude Codeを使えば、CSVからScriptableObjectを一括生成するエディタ拡張を素早く作れます。
CSVデータの例
name,hp,attack,defense,exp,dropItemId
Goblin,50,10,5,20,101
Orc,150,25,15,80,102
Troll,400,45,30,200,103
Dragon,2000,120,80,1000,104
ScriptableObjectクラスの定義
using UnityEngine;
[CreateAssetMenu(fileName = "SO_EnemyConfig_New", menuName = "MyGame/Enemy Config")]
public class EnemyConfigSO : ScriptableObject
{
[SerializeField] public string enemyName;
[SerializeField] public int hp;
[SerializeField] public int attack;
[SerializeField] public int defense;
[SerializeField] public int expReward;
[SerializeField] public int dropItemId;
}
Claude Codeへの依頼と生成されるEditor拡張
# プロンプト例
上記のCSVとEnemyConfigSO.csを渡して：
「このCSVの各行からEnemyConfigSOのScriptableObjectアセットをAssets/Data/Enemies/に
一括生成するエディタ拡張MenuItemを書いて。
ファイル名はSO_EnemyConfig_{name}.assetにする。
AssetDatabaseのRefreshとProgressBarも含める。」
Claude Codeが生成するエディタスクリプトの例：
#if UNITY_EDITOR
using UnityEngine;
using UnityEditor;
using System.IO;
using System.Text;
public static class EnemyDataImporter
{
private const string CSV_PATH = "Assets/Data/enemy_config.csv";
private const string OUTPUT_PATH = "Assets/Data/Enemies/";
[MenuItem("MyGame/Import Enemy Data from CSV")]
public static void ImportEnemyData()
{
if (!File.Exists(CSV_PATH))
{
Debug.LogError($"CSVファイルが見つかりません: {CSV_PATH}");
return;
}
var lines = File.ReadAllLines(CSV_PATH, Encoding.UTF8);
int total = lines.Length - 1; // ヘッダー行を除く
if (!Directory.Exists(OUTPUT_PATH))
Directory.CreateDirectory(OUTPUT_PATH);
for (int i = 1; i < lines.Length; i++)
{
EditorUtility.DisplayProgressBar(
"Enemy Data Import",
$"処理中: {i}/{total}",
(float)i / total
);
var cols = lines[i].Split(',');
if (cols.Length < 6) continue;
var so = ScriptableObject.CreateInstance<EnemyConfigSO>();
so.enemyName = cols[0].Trim();
so.hp = int.Parse(cols[1].Trim());
so.attack = int.Parse(cols[2].Trim());
so.defense = int.Parse(cols[3].Trim());
so.expReward = int.Parse(cols[4].Trim());
so.dropItemId = int.Parse(cols[5].Trim());
string assetPath = $"{OUTPUT_PATH}SO_EnemyConfig_{so.enemyName}.asset";
AssetDatabase.CreateAsset(so, assetPath);
}
EditorUtility.ClearProgressBar();
AssetDatabase.SaveAssets();
AssetDatabase.Refresh();
Debug.Log($"Enemy DataをCSVからインポートしました: {total}件");
}
}
#endif
敵キャラ100種類のバランスデータをExcel/Googleスプレッドシートで管理し、CSVエクスポート→このスクリプトで一括生成するフローにすることで、バランス調整の反復サイクルが大幅に速くなります。ただし、CSVのエンコードはUTF-8（BOMなし）に統一することと、フィールドの変更時はスクリプト側も必ず更新することを忘れないでください。
プレイテストログの解析
「プレイヤーがどこで詰まっているか」を知るためには、ゲーム内のアクションログを収集・解析する必要があります。Claude Codeはこのログ解析パイプラインを構築する作業も得意です。
Unityのログ収集スクリプト
# プロンプト例
プレイテスト用のセッションログを収集して
JSON Lines形式でApplication.persistentDataPath以下に保存する
GameAnalyticsLogger.csを書いて。
収集するイベント：
- player_death (position, cause, playtime_seconds)
- stage_clear (stage_id, clear_time, deaths)
- item_used (item_id, position, hp_at_use)
File I/Oの例外処理も含める。
生成されたJsonLines形式のログ（session_20260611_143022.jsonl）:
{"event":"player_death","position":{"x":23.4,"y":0.5,"z":8.1},"cause":"fall","playtime":142}
{"event":"player_death","position":{"x":45.2,"y":1.0,"z":8.3},"cause":"enemy","playtime":287}
{"event":"stage_clear","stage_id":1,"clear_time":380,"deaths":3}
Claude Codeを使ったログ解析
収集したJsonLinesファイルをそのままClaude Codeに渡して分析させることができます：
# プロンプト例（ログファイルを渡して）
10セッション分のJsonLinesログを渡します。
以下を分析してください：
1. player_deathのheatmap用XZ座標リスト（死亡頻度の高い座標上位10位）
2. ステージごとのクリア時間の中央値・最大値・最小値
3. HPが20%以下の時にアイテムを使用した割合
数字と固有名詞は根拠（計算式）を添えてください。
このように、ゲームのプレイデータ分析をエンジニアツールとして使えるのがClaude Codeの強みです。Pythonで可視化スクリプトを生成させることも、UnityのEditor拡張としてヒートマップ表示機能を作ることもできます。
Godot GDScriptへの対応
Godot 4.6.2（godotengine.org 公式、2026年4月リリース）でもClaude Codeは活用できます。GDScriptはPythonに近い文法のため、Claude Codeとの相性は非常に良好です。
GodotプロジェクトのCLAUDE.md例
# Godot Project Rules — MyGodotGame
## Engine
- Godot 4.6.2 (GDScript, not C# Mono)
- Rendering: Forward+ (モバイルはCompatibility)
## Naming Conventions
- Classes: PascalCase (@class_name PlayerController)
- Variables: snake_case (_health, move_speed)
- Signals: past_tense (health_changed, enemy_died)
- Node names: PascalCase (例: "EnemySpawner", "HUDManager")
- Resources: snake_case.tres (例: enemy_goblin.tres)
- Scripts: snake_case.gd (例: player_controller.gd)
## Architecture
- Autoload Singletons: GameManager, AudioManager, SaveManager
- Sceneはノード単位で分割（Instantiate方式）
- Signalでノード間通信（直接参照は最小限）
## GDScript Style
- @export変数は型ヒントを必ず書く
- match文でtype switch
- awaitはshort-form (await get_tree().process_frame)
GDScriptコード生成の例
# プロンプト例
Godot 4.6のGDScriptで、敵AIのステートマシンを実装して。
ステート：Idle, Patrol, Chase, Attack, Dead
PatrolはNavigationAgent2D使用、
ChaseはプレイヤーとのDistanceで切り替え（距離200px以下で追跡開始）
不足している情報があれば最初に質問してください。
生成されるGDScriptの例（一部抜粋）：
class_name EnemyAI
extends CharacterBody2D
enum State { IDLE, PATROL, CHASE, ATTACK, DEAD }
const CHASE_RANGE: float = 200.0
const ATTACK_RANGE: float = 60.0
const PATROL_SPEED: float = 80.0
const CHASE_SPEED: float = 150.0
@export var hp: int = 100
@onready var nav_agent: NavigationAgent2D = $NavigationAgent2D
@onready var detection_area: Area2D = $DetectionArea
var current_state: State = State.IDLE
var player_ref: CharacterBody2D = null
signal state_changed(new_state: State)
signal died
func _ready() -> void:
detection_area.body_entered.connect(_on_body_entered)
detection_area.body_exited.connect(_on_body_exited)
func _physics_process(delta: float) -> void:
match current_state:
State.IDLE:
_process_idle(delta)
State.PATROL:
_process_patrol(delta)
State.CHASE:
_process_chase(delta)
State.ATTACK:
_process_attack(delta)
State.DEAD:
pass
# ... 各ステート処理は省略
GDScript特有の注意点
Claude Codeを使う上でGodot特有の注意点が2点あります：
- ノードパスは実際のシーン構造に依存：
$NavigationAgent2Dのようなノードパスは、実際のシーン内の構造と一致している必要があります。生成コードをそのままコピーせず、自分のシーン構造に合わせて修正してください - Godot 3→4の移行コードに注意：ClaudeはGodot 3の記法を出力することがあります。CLAUDE.mdに「Godot 4.6を使用、Godot 3の記法は禁止」と明示することで回避できます
アセット命名規則チェックの自動化
複数人で開発するとアセットの命名がバラバラになりがちです。Claude Codeに命名規則とプロジェクトのディレクトリ構造を渡すことで、CI/CDに組み込める検証スクリプトを生成できます。
# プロンプト例
以下の命名規則に違反しているファイルをUnityプロジェクトのAssetsフォルダ以下から検出する
Pythonスクリプトを書いて。
規約：
- Prefabs: PFB_で始まる
- ScriptableObjects: SO_で始まる
- Textures: TEX_で始まる
- Audio: SFX_ または BGM_で始まる
- Scenes: SCN_で始まる
- *.meta ファイルと .DS_Store は除外
出力フォーマット：違反ファイルパス一覧（JSON形式）
GUIDベースの参照は壊さないので、あくまで警告リストとして出力する。
生成されるPythonスクリプト（一部）：
import os
import json
import re
from pathlib import Path
# 命名規則定義
NAMING_RULES = {
'.prefab': r'^PFB_',
'.asset': r'^SO_',
'.png': r'^TEX_',
'.jpg': r'^TEX_',
'.wav': r'^(SFX_|BGM_)',
'.mp3': r'^(SFX_|BGM_)',
'.ogg': r'^(SFX_|BGM_)',
'.unity': r'^SCN_',
}
IGNORE_EXTENSIONS = {'.meta', '.DS_Store'}
def check_naming_violations(assets_root: str) -> list[dict]:
violations = []
for path in Path(assets_root).rglob('*'):
if not path.is_file():
continue
if path.suffix in IGNORE_EXTENSIONS:
continue
rule = NAMING_RULES.get(path.suffix.lower())
if rule and not re.match(rule, path.name):
violations.append({
'path': str(path.relative_to(assets_root)),
'file': path.name,
'expected_prefix': rule.replace('^', '').replace('(', '').replace(')', '').split('|')[0]
})
return violations
if __name__ == '__main__':
import sys
root = sys.argv[1] if len(sys.argv) > 1 else './Assets'
results = check_naming_violations(root)
print(json.dumps(results, ensure_ascii=False, indent=2))
print(f'\n合計 {len(results)} 件の命名規則違反を検出しました（警告のみ・自動リネームなし）')
このスクリプトをGitHub Actions / GitLab CIに組み込めば、プルリクエスト時に命名規則違反を自動警告できます。ただし実際のリネームは行いません。UnityのGUIDベース参照システム上、ファイルリネームはUnityエディタ経由で行う必要があります。
内部リンク：他の開発用途でも活かせる
Claude Codeのゲーム開発活用は、他のソフトウェア開発の事例と多くの手法を共有しています。以下の記事も合わせて参考にしてください：
- テスト自動生成とTDDにClaude Codeを使う実践事例——ゲームのユニットテスト（EditModeテスト）生成にも応用できます
- プロトタイプ・MVP高速開発でのClaude Code活用——ゲームのプロトタイプ検証サイクルを短縮する手法
- フロントエンドReact開発でのClaude Code実践——ゲームの管理ダッシュボードやWebGL展開ページに
- パフォーマンスチューニングとClaude Code——Unityのプロファイリング結果を渡してのボトルネック分析に
- モバイルアプリ開発でのClaude Code活用——Unityのモバイルビルド設定・iOS/Android固有コードの生成に
【要注意】よくある失敗パターンと回避策
失敗1：バージョン指定をしない
❌「UnityでPlayerのHPを管理するコードを書いて」
⭕「Unity 6.3 LTS環境で、New Input System対応のPlayerHealthコンポーネントを書いて」
Unityは頻繁にAPIが変わります。CLAUDE.mdに明記するか、依頼文に毎回バージョンを含めることで、廃止APIを使ったコードが出力されるリスクを下げられます。
失敗2：コンパイルエラーを確認せずに量産する
❌ 生成→生成→生成と連続依頼して後でまとめてUnityにコピーする
⭕ 1ファイル生成→Unityでコンパイル確認→次の生成、というサイクルで進める
特にScriptableObjectの型参照や、アセンブリ定義をまたぐ参照は、Claude Codeが把握しきれずにコンパイルエラーになりやすいポイントです。
失敗3：UnityEditorクラスをランタイムコードに混入させる
❌ Editor拡張を頼んだつもりが、AssetDatabaseなどEditorクラスがRuntimeスクリプトに入り込む
⭕ 依頼時に「#if UNITY_EDITORディレクティブで囲むか、Editor.asmdefに配置する前提で書いて」と明示する
これは実機ビルド時にコンパイルエラーになる典型的なミスです。CLAUDE.mdに「Editor専用コードは必ず#if UNITY_EDITORで囲む」と書いておけば自動で対応されます。
失敗4：Godot 3と4の記法の混在
❌ Godot 4プロジェクトにGodot 3の connect("signal", self, "_on_signal") 形式が混入する
⭕ CLAUDE.mdに「Godot 4.6を使用。Godot 3の記法は厳禁（connect/callbackの旧形式など）」と明記する
導入ロードマップ（3フェーズ）
Phase 1（1週間）: CLAUDE.md整備と単発スクリプト生成
プロジェクトルートにCLAUDE.mdを作成し、既存スクリプト5本を参考に命名規則・アーキテクチャ方針を記述する。まず単純なコンポーネント（UIアニメーション、音声管理など）の生成から始めて精度を確認する。
Phase 2（2〜4週間）: データ駆動設計の整備
ScriptableObject定義とCSVパイプラインを構築する。ゲームバランスデータをスプレッドシートで管理し、CSVエクスポート→Editor拡張でのアセット一括生成フローを確立する。週次のバランス調整サイクルに組み込む。
Phase 3（1ヶ月以降）: 分析・自動化パイプライン構築
プレイテストログ収集→Claude Codeによる分析→ヒートマップ可視化のパイプラインを整備する。アセット命名規則チェックをCI/CDに組み込み、コードレビューでの指摘を減らす。
実装パターンのまとめ（想定シナリオ）
以下は本記事で紹介した実装パターンを適用した場合の想定効果です（仮説試算・モデルケース）：
| 作業 | 従来（手動） | Claude Code活用後（想定） | 備考 |
|---|---|---|---|
| C#コンポーネント1本の初稿作成 | 20〜40分 | 5〜10分（プロンプト設計含む） | 複雑なAIロジックは除く |
| ScriptableObject 50件の手動入力 | 1〜2時間 | 10〜15分（Editor拡張実装後） | CSV側の整備時間は別途 |
| アセット命名違反チェック（手動） | 30〜60分/PR | 自動（CI/CD組込後） | 初期整備に1〜2時間必要 |
| GDScriptステートマシン初稿 | 1〜3時間 | 15〜30分 | ノードパス調整は手動必要 |
これらはあくまで参考試算です。実際の効果は開発者のClaude Code習熟度、プロジェクト規模、CLAUDE.mdの整備状況によって大きく異なります。
よくある質問（FAQ）
Q：Claude Codeを使うためにUnity側で何か設定が必要ですか？
A：特別なUnity設定は不要です。Claude Codeはターミナルから動作するため、UnityプロジェクトのC#ファイルやJSONファイルをテキストとして読み書きします。生成したファイルをAssetsフォルダに配置すれば、Unityが自動でインポートします。
Q：無料プランで使えますか？
A：Claude Codeは有料のClaudeサブスクリプション（Pro / Team / Enterprise）が必要です。大規模なコードベースを扱う場合はContext上限に注意が必要です（2026年6月時点の詳細はanthropic.com公式を参照）。
Q：ShaderGraph / URP ShaderもClaude Codeで書けますか？
A：テキストベースのHLSHシェーダー（.hlslファイル）は生成可能です。ただしShaderGraphのノードベース構造（JSONファイル）を直接生成・編集するのは現実的でないため、ShaderGraphはエディタで手動設計することをお勧めします。
まとめ：今日から始める3つのアクション
- CLAUDE.mdを5分で作る：Unityプロジェクトルートに最小構成のCLAUDE.md（バージョン・命名規則の2セクションだけ）を作成し、C#コンポーネント1本を生成してみる
- 最もめんどくさい繰り返し作業を1つ特定する：ScriptableObjectの手入力、ボイラープレートコードのコピペ、ログファイルの手動集計——まず1つだけClaude Code対応スクリプトに置き換える
- CLAUDE.mdを育てる：生成したコードで「ここが違う」と思ったことを即座にCLAUDE.mdに追記する。ルールが溜まるほど、生成精度が上がっていく
Claude Codeの最大の価値は「AIに任せる部分」ではなく「人間が本当に考えるべきゲームデザイン・体験設計に集中できる時間」を作ることです。コーディングの繰り返し作業をAIに委譲して、ゲームを面白くする作業に時間を使いましょう。
著者プロフィール
佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
