Claude Code × Unity CLI Loop でチュートリアルのE2Eテストを自動化してみた

• URL: https://zenn.dev/unsoluble_sugar/articles/2a1f9e08ac9980
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude CodeとUnity CLI Loopを使い、モバイルカジュアルRPGの初回起動チュートリアル全体をE2Eテスト自動化した実践報告。当初はAIが毎ステップ状態を取得して判断するインタラクティブ方式で実装したが、トークン消費が激しく実行時間が長く再現性が低いという3つの問題が発生した。テストロジックをシェルスクリプトに固めてAIの役割をシナリオ読み込みとスクリプト実行のみに絞ることで、メインループの実行時間が240秒から104秒に短縮され入力トークンも約17000〜20000程度に抑えられた。CLI呼び出しのオーバーヘッド（1〜2秒/回）をさらに削減するため、DontDestroyOnLoadなBridge GameObjectの子オブジェクト名にゲーム内ポーリング結果を書き込む「状態ブリッジ方式」を導入し、オーバーヘッドを57%削減した。

詳細

テスト対象と背景

• モバイル向けカジュアルRPGの初回起動チュートリアル（コイン獲得・バトル・装備獲得・仲間救出・強化・装備交換を含む）
• 1回通すのに数分かかり、コード変更のたびの手動確認がコスト高
• セーブデータリセットで毎回同じ状態から開始できるため再現性確保が容易

4層アーキテクチャ

• Claude Code Skill: シナリオ読み込み・スクリプト実行順制御・結果判定・レポート生成のみ
• シェルスクリプト: テストフロー制御（ループ・sleep・リトライ）を決定論的に実装
• unity-cli-loop: Unity Editorへの命令送信（execute-dynamic-codeでC#を動的実行）
• Unity内C#: ボタンクリック・状態検知・ブリッジ書き込み

AI判断方式からの転換

• 当初のAI判断方式の問題: トークン消費大・実行時間長（240秒）・AIの判断ブレによる再現性低下
• 転換後: テストロジックをシェルスクリプトに固定、AIはbash実行とレポートのみ
• 改善結果: メインループ240秒 → 104秒、入力トークン約17000〜20000で安定

UI操作アプローチ

• 決め打ち方式（今回採用）: GameObject.Find("ボタン名") + onClick.Invoke() で名前指定クリック
• 再現性・速度・コストの面でフローが固定されたテストには決め打ち方式が適切
• AI自律判断方式: UI変更が頻繁な探索的テストに向く

状態ブリッジ方式（CLIオーバーヘッド57%削減）

• 問題: unity-cli-loop 1回呼び出しに1〜2秒かかる
• 解決: DontDestroyOnLoadなBridge GameObjectをバッファとして使用、ゲーム内で非同期ポーリングした結果を子オブジェクトの名前として書き込む
• なぜ子オブジェクト名か: execute-dynamic-codeは独立コンテキストで評価されstatic変数を跨げないが、GameObject.FindはシーンオブジェクトをCLI呼び出しをまたいで読み書きできる

その他の技術的工夫

• poll_and_click: 固定sleepではなくボタン出現までポーリング（遷移完了を検知して即実行）
• ゲーム内時間基準の遅延: bash側のsleepではなくUniTask + Time.timeでゲーム内時間を基準に処理
• セーブデータのバックアップ・復元で開発中データを保護