Unityプロジェクトでテスト設計+テストファースト開発のための Agent Skills

昨年、Unityプロジェクトでも Claude Code に自走させるワークフローという記事を投稿しました。その後も .claude/ 下を公開したリポジトリのメンテナンスを継続していましたが、改めて Agent Skills/ Claude Code プラグインとして公開しました。

github.com

実装計画スキル

代表スキルは /plan-feature <SPEC> で、これをプランモードで使用すると実装前にテスト設計を行い、プランファイルにテストケースを含めてくれます。また実装をテストファースト（TDDではなく）で進めるワークフローもプランファイルに含めます。

このスキルおよびワークフローには、次の特徴があります。

テスト設計
- 保守性の高いテスト：AIが書きがちな、冗長なテスト、アサーションのないテスト、不要なテストダブル（モック/ スタブなど）を削減
- 手動検証は最低限：統合テストレイヤでUI操作を含めたテストを実施、目視検証が必要なテストは画像解析による検証を実施*1。アニメーションや手触り感などの観点のみ人間に評価を移譲
- プラン時点でテストケースをレビュー可能：検証内容も含めてプランファイルに出力されるので、テストケースをレビューすることでプランが仕様を満たしているかどうか判断できる
テストファースト
- テストコードを先に実装・実行して、テストが失敗することを確認します。テストファーストには次の利点があります
  - テストコードの正当性（少なくとも、ちゃんと失敗できるテストである）が担保される
  - プロダクトコード（ゲーム本体コード）実装の完了基準を定義できる
  - テスト駆動開発（TDD）と比べ、変更ループが少なくトークン消費も抑えられる
コーディングガイドライン
- Unity Test Framework向けテスト実装についてのガイドライン（非同期テストは UnityTest 属性でなく async + Test 属性を使う、など）
- Unity向けコード実装についての最低限のガイドライン（Unity 2021.1以降ではオブジェクトプーリングを自前実装しないで ObjectPool<T> を使う、など）
- Scene/ Prefab の編集は、エディタスクリプトをアドホックに書いてUnityエディタで実行
- ScriptableObject などの複雑でないアセットファイルを直接編集するガイドライン
内部品質（保守性・可読性など）
- テスト可能なコードであるという点で、最低限の内部品質は確保
- ワークフローの最後に、決定論的ツールによる静的解析を実行（後述）

インストールと設定

プラグイン/ スキルのインストール

Claude Code プラグインとしてプロジェクトスコープにインストールする場合は、次のスラッシュコマンドを実行します。

/plugin marketplace add nowsprinting/unity-coding-skills
/plugin install unity-coding-skills@nowsprinting-unity-coding-skills --scope project

その他、スキル単位でインストールするツールなどが使えるはずです。

MCPサーバの設定

一部のスキルは、JetBrains RiderビルトインのMCPサーバ及び、Unityエディタを操作する拡張を使用します。設定方法は次の記事を参照してください。なお、設定ファイルを手書きする場合は、MCPサーバの名称は必ず jetbrains にしてください。

www.nowsprinting.com

Riderを使いたくない場合、一部のスキルだけ書き換えてもらえれば動作はするはずです。しかし、JetBrains MCPサーバにはファイル検索などCoding Agentを効率化するツールも含まれていますので、Riderの使用をお勧めします。無料トライアルもあります。

静的解析の設定

強制したいコーディングルールは、コンパイラやRoslynアナライザで warning 以上の診断になるように設定しておくと、ワークフローの最終フェーズで修正されます。

たとえば、（AIがやりがちな）変更で使わなくなった型やメンバを削除せず放置するのを禁止するには、次の設定を .editorconfig ファイルに追加します。

resharper_unused_type_local_highlighting = warning
resharper_unused_type_global_highlighting = warning
resharper_unused_member_global_highlighting = warning
resharper_unused_member_local_highlighting = warning

.editorconfig ファイルについて詳しくは次の記事を参照してください。

www.nowsprinting.com

またRiderを使用できる場合、プラグインによる診断も対象になります。（これもAIが書きがちな）長く複雑なメソッドを分割させるために、サイクロマティック/ コグニティブ複雑度を診断するプラグインが利用できます。詳しくは次の記事を参照してください。

www.nowsprinting.com

注意事項

ドキュメントに "TBD" と書いてある仕様は無視されます（詳細を詰められたりしない）
Scene/ Prefab 編集スクリプトは、コミットも削除もしません（中身を見たいことがあるため）
スキルにはコーディング規約を含まないため、たとえば割とカジュアルにリフレクションが使われたりします。まず静的解析で縛ることを考え、決定論的に書けないものはプロジェクト固有のガイドラインを書くなどしてください
構造的な問題や落とし穴などの観点は人間によるコードレビューが必要です
コード品質は既存のコードベースに引っ張られます。既存プロジェクトに導入する場合は、まず /refine-tests スキルでテストコードをリファインすることをお勧めします

使用感・メトリクス

主に、Slay the Spireクローンの制作に使用したときのもの。

プルリクエストにするくらいの粒度で使用して、プラン承認後1〜2時間（最近遅いので）自走して、実装・テストを完了します
- UIレイアウトは雑なものですが、ちゃんと操作できるものが出来上がります（他のGameObjectによってブロックされていないことなどもテスト済み）
- バグは出ますが仕様定義の漏れが支配的で、仕様レビューを厳密にすることで防げるはず（本プラグイン対象外）
テストケースレビューだけで、コードレビューは（テストコードもプロダクトコードも）省略することがほとんど*2。テストケースレビューも全ケースではなく、統合テストや受け入れテスト*3を中心にレビューしています
内部品質は十分とは言えませんが、Claude Codeで開発イテレーションを繰り返しても崩壊しない程度の品質はキープできています*4
ステートメントカバレッジは 97.5% *5
code : test ratio は 1 : 5.0 *6