概要

unityroomのゲームジャムイベント、unity1weekに参加しました。

今回も参加したので、その記録を残そうと思います。
構想に6日、実装に3日程度かかりました。(遅刻)

作ったものは以下です。
30分くらいかかりますが、よければぜひ遊んでいただけると嬉しいです。

前に参加した時の記録は以下にまとめています。今回は利用しているツールがより便利になっています。前回より圧倒的に楽に開発できると思います。

Gemini CLI

今回はAIエージェントとしてGemini CLIを利用しました。

ここで何を使うかはあまり本質的ではなく、任意のMCPサーバーと接続できるAIエージェントであればCursor / Claude Code / Codex CLI / GitHub Copilot とかその他なんでもいいです。

今回はGemini AI Proプラン(1ヶ月無料トライアル、2ヶ月間トライアル価格月額1450円, 通常時月額2900円)を課金して利用しました。これでトークン不足で困ることはなかったので十分だと思います。

導入

以下でインストールできます。

npm install -g @google/gemini-cli

下記コマンドで起動。自動でログイン処理を行うので、いい感じに進めてください。

gemini

モデル選択もできます。

/model

と打つと以下の選択肢が出ます。Auto(Gemini 3)の設定でいいでしょう。

╭──────────────────────────────────────────────────────────╮
│                                                          │
│ Select Model                                             │
│                                                          │
│ ● 1. Auto (Gemini 3)                                     │
│      Let Gemini CLI decide the best model for the task:  │
│      gemini-3-pro, gemini-3-flash                        │
│   2. Auto (Gemini 2.5)                                   │
│      Let Gemini CLI decide the best model for the task:  │
│      gemini-2.5-pro, gemini-2.5-flash                    │
│   3. Manual                                              │
│      Manually select a model                             │
│                                                          │
│ To use a specific Gemini model on startup, use the       │
│ --model flag.                                            │
│                                                          │
│ (Press Esc to close)                                     │
│                                                          │
╰──────────────────────────────────────────────────────────╯

MCPサーバーの設定

前回使ったものとは別のMCPサーバー uLoopMCP を利用します。

日本人作成なのでドキュメントを読むのが楽
コンパイル、テスト実行、メニュー項目の実行、エディタ内での動的なC#コードの実行等の多様な操作ができる

特に後者が大きくて、Unityでの画面上での操作をほとんど行わずにゲームの作成を行うことができます。

なお、他の選択肢としては今調べて見かけたのは以下のツールでした。多分同じようなことができる。こちらは試してないのでわかりませんが、一旦不足を感じていないので前者で進めていきます。

導入

クイックスタートに従い、

Unityプロジェクトにパッケージをインストール
ウィンドウを開き、サーバーを起動
- その際、以下の画像を参考に設定してください
  - (赤線) ターゲットをGemini CLI(使うツールに合わせてください)に設定
  - (緑線) Gemini CLIが読むためのSettingを作成
  - (青線) 実行権限の設定(画像では全権限を付与していますが、もちろんセキュリティの問題があるので読者の各自の判断にお任せします)

なお、上記の設定を行うと以下のウィンドウが出て設定できないことがあります。

ここに書いてある通りに、

Edit -> Project Settings -> Package Managerから以下のような設定をする
Window -> Package Management -> PackageManager -> My Registories からMicrosoft.CodeAnalysis.Csharpをinstallする

という手順を行ってください。

動かしてみよう

Unityのプロジェクトのディレクトリでコンソールを開き、geminiコマンドでgemini cliを起動します。
ここまでできていれば、uloopMCPの画面で以下のような表示がでているはずです。

(windowsの場合はwslを利用すると疎通が面倒なのでコンソールもwindowsで起動しましょう)

一旦疎通確認を行ってみましょう。

ログ取得か何かができればOKです。

ゲーム制作

構想を練る

まずどんなゲームを作るのか決めましょう。
ブラウザ上で、チャットのGeminiに壁打ちします。

いくつかアイデアを上げてもらいつつ、気になったものに関してはCanvas機能を利用して簡単にHTMLで実装してもらいました。

簡単なイメージを伝えると、画像のようにCanvasで高速で作ってくれます。簡単に動くものを作りたいだけなら、Canvasを使うのが圧倒的に早い。

実際に動くものを見ると湧いてくるイメージもあります。そうしたことをして構想が練れてきました。

いろいろ試して方針は決まったので、実装を始めていきましょう。

方針

開発は以下のような方針で行いました。

実装・Unityの操作(ヒエラルキーの操作等)は基本全てGeminiにおまかせする
まず最低限動くものを作る。そこから一つずつ欲しい機能を指示していく
実装が完了するたびにコンパイルを行わせ、それが完了することをGemini側に確認させる
そこまで完了したら自分が手動で動作確認を行う
コンテキストに依存しないように、全ての記録をファイルとして残す
あくまで個人・短期間の開発なので、git管理や自動テストは省略する
- (git管理はした方がいいと思います)

Docsによる管理

実行計画等をファイルとして管理します。最終的には以下のような構成になるようにします。

    project
    ├──/Docs/
    │  ├── concept.md           # ゲームのコンセプト、ルール、異変一覧、日記の内容など
    │  ├── planning.md          # 開発マイルストーンと進捗状況
    │  ├── progress-log.md      # 修正履歴、バランス調整、バグ修正の記録
    │  ├── technical-note.md    # 技術仕様、アセットの向き、生成ロジック、注意点
    │  └── uloop_mcp_insights.md # uLoopMCPの使用に関する知見と制約
    └──GEMINI.md

まず、Docs/というディレクトリを作成し、そこに以下のようなファイルを置きます。

concept.md

# コンセプト

## やること

- Unity1Week用のゲームを作る
- できるだけ低コストに、高速で個人開発を行う

## 重視したいこと

- 「動くものを作って動作確認する」ことを優先する。何か機能が増えるたびに動作確認を取れるようにプランを組む。また動作確認のフェーズに入るたびにユーザーに伺うこと
- ツールは https://github.com/hatayama/uLoopMCP を利用し、ユーザーの操作を可能な限り省力化すること

## ゲーム内容

- 8番出口ライクの1人称視点3Dゲーム。
- 0番出口(スタート地点)の姿と比べて異変がないなら前進、異変があるなら後退するのが正解となる。
- 異変がない時に前進すれば次の数字に進む(異変がない時に後退しても失敗ではないが、次のステージには進まないでやり直しとなる)
- ...
(ゲーム内容の詳細になるので略)

これを使って以下のような指示を出します。

実際にはこのような指示で一発で作られたものはあまりうまくいっていません。
GEMINIファイルに関しては、継ぎ足し継ぎ足しやって最終的に以下のようなGEMINI.mdになりました。よければ参考にしてください。

GEMINI.md

# Project Gemini: Game Development Principles

This document outlines the core principles and workflow for game development in this project, optimized for collaboration with the Gemini agent.

## 1. Core Philosophy: Rapid & Robust Development

Our primary goal is to build and iterate on playable prototypes as quickly as possible. We prioritize creating "working software" over extensive documentation, enabling frequent feedback and course correction.

- **Principle 1: Rapid Prototyping & Iteration**
  - We focus on building the simplest possible version of a feature first, ensuring it works, and then iterating on it.
  - The agent (Gemini) should always aim to deliver a functional, testable piece of the game.

- **Principle 2: Incremental Development & Frequent Feedback**
  - Development will proceed in small, incremental steps.
  - After each significant feature addition or change, the agent will perform a verification (manual or automated) and present the result to the user for feedback.

- **Principle 3: Autonomous Development Cycle with uLoopMCP**
  - We will leverage `uLoopMCP` to establish an autonomous development loop.
  - The agent is expected to proactively use `uLoopMCP` to **compile -> run tests -> analyze logs -> fix code**, automating the development cycle to enhance speed and quality.

- **Principle 4: Modularity and Reusability**
  - All code and assets should be designed with reusability in mind.
  - We will create modular, loosely-coupled components that can be easily adapted for future projects, avoiding hardcoded logic specific to this single game.

## 2. Agent Directives

- **Language**: Always respond in **Japanese**. Code, comments, and technical identifiers will follow the project's conventions (typically English).

### Critical Communication & Verification Protocols
- **No Unilateral Decisions**: The agent must never force a solution (e.g., by stating "Discussion is unnecessary"). All significant changes must be proposed with a clear rationale, and the agent must always wait for explicit user approval before execution. The user is the final authority.
- **Wait for Explicit Confirmation**: The agent must not assume user actions are complete (e.g., after requesting a test run). It must wait for an explicit confirmation signal (e.g., "完了しました") from the user before proceeding with tasks that depend on those actions.
- **Prioritize All User Questions**: Always provide a direct answer to a user's question before proposing or executing any further actions. The agent's planned workflow is secondary to user inquiries.
- **Strict Separation of Analysis and Action**: When the user asks for a status check, investigation, or explanation (e.g., "How is it currently?", "Check the implementation"), the agent MUST restrict its output to the analysis result. Do NOT generate code fixes or modifications in the same turn unless the user explicitly included a request to fix it (e.g., "Fix it if broken").
- **Verify Own Actions**: After performing a file modification (`write_file`), the agent must immediately verify the result with `read_file` to ensure its internal state matches the actual file state, and report the verified outcome to the user.
- **Mandatory Compilation**: コードの変更（`write_file` や `replace`）を行った後は、必ずそのターンの終了前に `compile` ツールを実行し、`get_logs` を用いてエラーが発生していないことを確認しなければなりません。エラーがある場合は、そのターンのうちに修正を試みるか、状況を詳細に報告してください。
- **Knowledge Documentation**: The agent must document significant operational methods, tool insights (especially regarding `uLoopMCP` limitations and workarounds), and project-specific conventions under the `Docs/` directory. This documentation should be context-independent and reusable for future projects.
- **Startup Protocol**: セッション開始時に、エージェントは必ず `Docs/` ディレクトリ内のすべてのファイルを読み込み、プロジェクトの現在の状態、仕様、規約、および進捗状況を完全に把握しなければなりません。
- **Continuous Documentation**: 開発の進捗、現在の仕様、意思決定の経緯などを常に `Docs/` ディレクトリ内のドキュメント（例: `planning.md`, `progress-log.md`）に最新の状態で記録しなければなりません。これは作業完了の必須条件です。各ターンの返答の最後には、必ず「ドキュメント更新：[ファイル名]」の形式で更新状況を報告してください。実装とドキュメントに齟齬が生じた場合は、最優先でドキュメントを更新するか、ユーザーに確認を行ってください。
- **Documentation Mandate**: ゲームの仕様や開発の進捗は、すべて `Docs/` ディレクトリ内の Markdown ファイルに記録してください。適切なファイル名（例: `Docs/game-mechanics.md`, `Docs/progress-log.md`）で新規作成・更新を行うことはエージェントの義務です。これを行わずにタスクを完了させることは許されません。
- **Workflow Adherence**: Strictly follow the core philosophy, especially the autonomous development cycle.
- **Proactive Tool Utilization**: Actively use `uLoopMCP`'s capabilities—such as `run_tests`, `get_logs`, `compile`, `execute_dynamic_code`, and scene manipulation tools—to automate the entire workflow.
- **User-in-the-Loop**: For significant architectural decisions, ambiguous requirements, or after completing an implementation step, always consult the user for confirmation and feedback.
- **Best Practices**: Adhere to modern C# and Unity development best practices, including clean code, clear naming conventions, and performance considerations.
- **Autonomous Execution**: Once a task is approved, proceed autonomously to complete it, including analysis, planning, implementation, and verification.

---
**Primary Language:** Japanese
---

実装

作られたプランをレビューし、問題のある点を一部修正してから再度読ませ直します。そんなやり取りを何度か繰り返し、実装の指示を始めます。

上記による実装、コンパイルが完了したら手動で動作確認を行います。その機能が想定通り動いていれば次の工程へ。直したいところがあれば追加で指示をしていきます。

ヒエラルキー上に置くオブジェクトや、prefabとして管理する3Dモデルのオブジェクト追加・位置変更とかもuLoopMCPの範囲でできます。マジでUnity側を手動で触る回数は圧倒的に減りました。

デバッグ

うまく動作しない時は分析を行います。

プラン外の機能追加

プランとは別に機能を新たに追加する/変更する際は、一度現在の実装を確認させた方がいいです。現状の実装と重複してしまうことがあります。

確認した実装のうち、この部分を変更するというように明言しておくといいと思います。

ドキュメントを読ませての実装

ランキング機能の実装も行いました。
https://help.unityroom.com/how-to-implement-scoreboard を参考にする必要があります。ドキュメントも自分で勝手にwebから読んで利用方法を把握してもらいます。

こうしたことを地道に繰り返し、最終的にゲームができました。

Tips

GEMINI.mdの更新

デバッグが長引くと、マジでひどい応答をし始めることがありました。

トンチンカンな分析を行い、議論は不要ですとか言い出して許可すら取らずに既存の実装全てを破壊しだしたシーン。いいわけないだろ

こういった何かのコミュニケーションがうまくいかない/思い通りの流れにならないたびに「自分がどう問題視しているか」を伝えます。

その後、「なぜうまくいかなかったのか」を分析させます。その流れをGEMINI.mdに反映させます。

なお、こういうプロンプトは自動でアップデートしてくれれば楽ですが、いろいろ工夫してもイマイチうまくいきませんでした。いい指示があれば教えてください。

コンテキストの定期的なリセット

Gemini CLIはClaude Code等と比べてコンテキストを長く保持し続ける傾向を感じました。なんならコンテキストの圧縮操作を自分で行ったところを見たことがない。

そして、コンテキストが長くなればなるほど、応答の精度は低下します。

多分Gemini CLIの設定でどのタイミングで圧縮するかを管理できますが、不意のタイミングで圧縮操作が入るのもストレスなので機能がある程度追加されるたびに手動でリセットする(Gemini CLIを立ち上げ直す)ようにしていました。

- **Startup Protocol**: セッション開始時に、エージェントは必ず `Docs/` ディレクトリ内のすべてのファイルを読み込み、プロジェクトの現在の状態、仕様、規約、および進捗状況を完全に把握しなければなりません。
- **Continuous Documentation**: 開発の進捗、現在の仕様、意思決定の経緯などを常に `Docs/` ディレクトリ内のドキュメント（例: `planning.md`, `progress-log.md`）に最新の状態で記録しなければなりません。これは作業完了の必須条件です。各ターンの返答の最後には、必ず「ドキュメント更新：[ファイル名]」の形式で更新状況を報告してください。実装とドキュメントに齟齬が生じた場合は、最優先でドキュメントを更新するか、ユーザーに確認を行ってください。

いつリセットが入ってもいいように、これまで何をしたか、現状何があるか、これから何をしたいかといった情報を必ずファイルとして残させるようにします。また、それを起動時に必ず読むようにGEMINI.mdに記載しておきます。

テストの実行について

uLoopMCPはtest-runner実行の権限も持っています。最初はテストの実行まで含めて自動化しようと思いましたが、難しくて今回は諦めました。ロジック面はテストとして管理した方がいいんだろうけど、「何を自動テスト化すべきか」を定義するのが難しい。そして結局画面にどう表示されるかとかUXについては手動で確認するほかないので、そこは省略ができない。結局全部手動でやった方が今回の場合は早いと判断しました。個人開発だし急ぎだし。

結果として、１つ機能を追加するたびに動作確認は手動、かつそれまでの機能が壊れていないことを確認したり壊れていないことを祈ったりしていました。ダルすぎる

ここはまだ工夫しようがありうると思っているので、ちょっと次回の課題とします。

感想

できたもの

前回の手法と比べて圧倒的に楽でした。

「実装」と「Unityの操作」が相互に必要でお互いが影響を与え合うことが今までUnity開発における個人的な大きなストレスでした。

Unityを触ってコンパイルが失敗していたからVScodeをまた開く
必要なオブジェクトの設定をUnityの画面で行ってからそれをコード上で取得する

のような操作が不要になり、コードの実装だけでなくUnityの操作までほとんどAIエージェントにより自動化できるようになったのが大きな進歩です。
「ゲームの内容を考える」という何よりもやりたいことにちゃんと集中できた印象があります。
(遅刻はしていますが)妥協なしで作れました。

Googleとツールの作成者に感謝。お金もGeminiに定額プランに課金した1500円(とアセット代の20ドル)くらいしかかかっていません。

現在個人ゲーム開発のハードルは大幅に下がったように思います。(知識はあった方がもちろんいいですが)ある程度知識がなくても誰でもゲーム作りを楽しめるようになったと思うので、今まで手を出したことのない方もぜひ試してみてほしいです。