Amazon Q CLI: Vibe Codingでデオキシスの遭遇イベントを再現してみた
経緯
今回2025年6月29日にてAWS中国語コミュニティのイベントに参加して、こちらのキャンペーンがあると知り、イベント中各講師の話を聞きながら片手間でAmazon Q CLIを使い、ちょっとしたミニゲームのMVPを作ってみました。
以前出来心でClaudeを使って「ポケットモンスター ファイアレッド・リーフグリーン」での劇場版特典イベント、「たんじょうのしま」でのデオキシス遭遇イベントをHTML&Javascriptで作ってみた経緯もあり（こちらのリポジトリで見れます）、せっかくなので各種設定を流用して、Amazon Q CLIを使って一行もコードを書かずに、何なら一行も読まずに、PyGameで再度再現しようと考えました。
私自身二週間前からClaude Codeを使い始めていて、ある程度Amazon Q CLIのようなCLI Coding Agentに使い慣れ始めてきたので、この記事ではその感想や経験もシェアしていこうと思います。
プロンプトテクニック
1. game_idea.mdの作成
game_idea.md
ポケットモンスターファイアレッド・リーフグリーンの「たんじょうのしま」でのデオキシス遭遇ギミックをPyGamesで再現しようと思います。オフラインで使えるのをお願いします。絵や背景などは現状一旦不要で、プレイヤーを表す●と、ギミック対象の三角形の石▲だけを表示してください。
操作方法：十字キーで移動、スペースキーでインタラクト
ゲーム詳細：
* ゲーム盤は、左上から0-indexの9x11の形状です。
* プレイヤーは●、石は▲です。プレイヤーと石は同じマスに存在することはできません。
* プレイヤーは、石の上下左右1マス以内にいるとき、スペースキーを押すことで石とインタラクトできます。
* 三角形はプレイヤーがインタラクトするたびに移動します。正しくインタラクトできれば、合計10回移動し、11回目のインタラクトでゲームクリアとなります。
* 三角形の色は最初は真っ黒で、移動するたびにだんだん赤くなっていき、10回目の移動を終えたときは真っ赤になります。
* インタラクトの間には、歩数制限があります。歩数制限を超えてインタラクトすると、石は最初の状態に戻ります。最初のインタラクトに歩数制限はなく、石は合計10回移動し、インタラクトは11回あります。
* 歩数制限は以下のようです、10回それぞれ異なります：
1. 4
2. 8
3. 8
4. 8
5. 4
6. 4
7. 4
8. 6
9. 3
10. 3
* 石のそれぞれの配置は以下のようです：
* [(5, 5), (7, 1), (1, 5), (7, 9), (4, 2), (4, 8), (7, 5), (7, 1), (7, 9), (8, 5), (3, 5)]
* ゲームクリア後、(3, 5)の位置に対象のデオキシスを表示します
まず最初に、AIに自分が作りたいゲームを教えなければいけません。Amazon Q CLIは/editorコマンドで入力方式をvimに設定できるので、そこに長文プロンプトを書くことができます。しかし今後の指示のContextを記録するのにも、mdファイルを作成して書いた方がいろいろ後ほど便利になります。
2. 開発言語、環境を決める
今回イベント記事内で、
STEP 2 : Install Amazon Q CLI in your machine. Here are two guides from Ricardo Sueiras on how you can install in Linux and in Windows. Install PyGame or some other gaming library on your laptop.
と書かれていたので、ゲーム制作にはPyGameを使用。
自分は最近uvを愛用しているので、環境管理はuvに決定。
と、事前準備はこれだけです。
3. Amazon Q CLIを使って開発ロードマップを作成する
簡単な開発だとこの時点でAIにコードを書かせ始めてもよいのですが、長期プロジェクトを想定して、まずはAIに開発ロードマップを練らせます。
完全一致しなくてもよいので、以下のようなニュアンスのプロンプトをAIに伝えます。
> i'm going to create a simple game with python and PyGame package. read `game_idea.md` for the details of the game. we will use uv as our package management tool. write a comprehensive development roadmap in markdown under docs directory
するとCLIは作業を始めます。色々なコマンドの使用許可を聞いてくるので、全部yで通すか、面倒ならtでこれ以降全部同意にすることもできます。
DEVELOPMENT_ROADMAP.md
# Deoxys Birth Island Puzzle - Development Roadmap
## Project Overview
Recreation of the Deoxys encounter puzzle from Pokémon FireRed/LeafGreen's Birth Island using PyGame.
### Game Specifications
- **Grid**: 9x11 (rows x columns), 0-indexed from top-left
- **Player**: Circle (●) representation
- **Stone**: Triangle (▲) representation
- **Controls**: Arrow keys (movement) + Spacebar (interact)
- **Objective**: Complete 11 interactions with the stone following specific movement patterns
## Development Phases
### Phase 1: Environment Setup & Project Structure
**Estimated Time**: 1-2 hours
#### Tasks:
- [ ] Initialize uv environment
- [ ] Create project structure
- [ ] Install PyGame dependency
- [ ] Set up basic project files
#### Deliverables:
```
amazon_q_game/
├── pyproject.toml
├── src/
│ ├── __init__.py
│ ├── main.py
│ ├── game/
│ │ ├── __init__.py
│ │ ├── game_state.py
│ │ ├── player.py
│ │ ├── stone.py
│ │ └── constants.py
│ └── utils/
│ ├── __init__.py
│ └── helpers.py
├── tests/
└── README.md
```
### Phase 2: Core Game Engine
**Estimated Time**: 3-4 hours
#### Tasks:
- [ ] Implement basic PyGame window setup
- [ ] Create grid system (9x11)
- [ ] Implement basic game loop
- [ ] Add keyboard input handling
- [ ] Create coordinate system management
#### Key Components:
- Window initialization (recommended: 660x540 pixels for 60px cells)
- Grid rendering system
- Input event handling
- Frame rate management (60 FPS)
### Phase 3: Player Implementation
**Estimated Time**: 2-3 hours
#### Tasks:
- [ ] Create Player class
- [ ] Implement player movement (arrow keys)
- [ ] Add collision detection with grid boundaries
- [ ] Add collision detection with stone
- [ ] Implement step counter
- [ ] Add player rendering (circle)
#### Features:
- Grid-based movement
- Boundary checking
- Step tracking for puzzle mechanics
### Phase 4: Stone System
**Estimated Time**: 4-5 hours
#### Tasks:
- [ ] Create Stone class
- [ ] Implement stone positions array
- [ ] Add interaction detection (adjacent cells)
- [ ] Implement color progression system (black → red)
- [ ] Add stone rendering (triangle)
- [ ] Implement stone state management
#### Stone Positions:
```python
STONE_POSITIONS = [
(5, 5), (7, 1), (1, 5), (7, 9), (4, 2),
(4, 8), (7, 5), (7, 1), (7, 9), (8, 5), (3, 5)
]
```
### Phase 5: Puzzle Logic Implementation
**Estimated Time**: 5-6 hours
#### Tasks:
- [ ] Implement step limit system
- [ ] Add puzzle state tracking
- [ ] Implement reset mechanism
- [ ] Add interaction validation
- [ ] Create puzzle progression logic
#### Step Limits:
```python
STEP_LIMITS = [None, 4, 8, 8, 8, 4, 4, 4, 6, 3, 3]
# Index 0 = first interaction (no limit)
# Index 1-10 = subsequent interactions with limits
```
### Phase 6: Game States & UI
**Estimated Time**: 3-4 hours
#### Tasks:
- [ ] Implement game state management
- [ ] Add puzzle completion detection
- [ ] Create Deoxys appearance (final state)
- [ ] Add basic UI elements (step counter, interaction count)
- [ ] Implement game over/reset functionality
#### Game States:
- Playing
- Puzzle Complete
- Game Reset
### Phase 7: Visual Polish & Testing
**Estimated Time**: 2-3 hours
#### Tasks:
- [ ] Refine rendering system
- [ ] Add visual feedback for interactions
- [ ] Implement smooth color transitions
- [ ] Add debugging information (optional)
- [ ] Comprehensive testing
### Phase 8: Final Integration & Documentation
**Estimated Time**: 1-2 hours
#### Tasks:
- [ ] Final code cleanup
- [ ] Add comprehensive comments
- [ ] Create user documentation
- [ ] Final testing and bug fixes
## Technical Specifications
### Dependencies
```toml
[dependencies]
pygame = "^2.5.0"
```
### Key Constants
```python
# Grid dimensions
GRID_ROWS = 9
GRID_COLS = 11
CELL_SIZE = 60
# Colors
BLACK = (0, 0, 0)
RED = (255, 0, 0)
WHITE = (255, 255, 255)
BLUE = (0, 0, 255)
# Stone color progression (11 states: black → red)
STONE_COLORS = [
(0, 0, 0), # Black (initial)
(25, 0, 0), # Very dark red
(51, 0, 0), # Dark red
(76, 0, 0), # ...
(102, 0, 0),
(127, 0, 0),
(153, 0, 0),
(178, 0, 0),
(204, 0, 0),
(229, 0, 0),
(255, 0, 0) # Pure red (final)
]
```
## Success Criteria
- [ ] Player can move smoothly on 9x11 grid
- [ ] Stone interaction works when adjacent
- [ ] Step limits are enforced correctly
- [ ] Stone color progresses through 11 states
- [ ] Puzzle resets on step limit violation
- [ ] Game completes after 11th interaction
- [ ] Deoxys appears at final position (3, 5)
## Estimated Total Development Time
**20-30 hours** across 8 phases
## Risk Mitigation
- Start with minimal viable product in each phase
- Test each component thoroughly before moving to next phase
- Keep backup saves of working versions
- Document any deviations from original puzzle mechanics
## Next Steps
1. Set up the development environment with uv
2. Initialize the project structure
3. Begin with Phase 1 implementation
Would you like me to proceed with setting up the initial project structure?
このロードマップを作成することによって、今後の開発でのプロジェクトの方向性をAIにContextとして随時教えることができます。
4. Progress Documentの作成
ロードマップを作成後、Amazon Q CLIに実装開始の指示を出します。
> now we have created `DEVELOPMENT_ROADMAP.md`. let's start our implementation
驚くことに、ずっと各コマンド確認を許可していって、面倒だと思いtで全許可したら、一気にMVPまで作成してくれました。おそらくゲームロジックが簡単だったからだと思います。
しかしCLIだと何が起こって何が書かれたのかが見難いので、実装時各変更毎の詳細をdocs/progress/ディレクトリのもとに保存するよう指示しました。
5. ゲームテスト
uv run python src/main.pyでゲームをテストしていきます。ここから各種UIや、game_idea.mdでは語り切れなかったゲームロジックの細部を修正していきます。
6. git-strategy.mdの作成
開発途中からGit Repoの作成を忘れていたのを思い出して、Amazon Q CLIに指示しました。
> I found that we forgot to manage each change we made with Git. let's define the branching and commit strategy first and apply that to all the tasks after
これでここからは新しいFixや新しい機能を実装するたびにGitでバージョン管理できるようになります。
完成したゲーム画面
オリジナルと同じように、インタラクトしていくたびに三角の石がどんどん赤くなっていきます。
Amazon Q CLIの設定
- オート実行
- 完全Vibe Codingの場合、判断はAIに任せた方がよいので、毎度アクションを実行するたびにyを入力するのは面倒なので、tで完全自動化すると作業効率がぐんと上がります。
-
git-strategy.mdの作成- しかし全部AIに任し切ってしまうと、どこかで間違えた場合取り返しがつかなくなります。そのためGitによるバージョン管理はとても大切です。
-
progress-log-strategy.mdの作成- 今回はかなり雑に記録していましたが、本来であればプロジェクトの進行度を記録するstrategyも必要だと思います。
AIが書いたコードを見てみよう
コードはGitHubにて公開しています。
amazon_q_game/
├── pyproject.toml
├── src/
│ ├── __init__.py
│ ├── main.py
│ ├── game/
│ │ ├── __init__.py
│ │ ├── game_state.py
│ │ ├── player.py
│ │ ├── stone.py
│ │ └── constants.py
│ └── utils/
│ ├── __init__.py
│ └── helpers.py
├── tests/
└── README.md
実際にコードを見てみると、きれいなOODで作られています。
src/game/game_state.py, src/game/player.py, src/game/stone.pyはそれぞれゲームの重要な要素：進行度、プレイヤー、三角の石を定義していることがわかります。この3つのクラスをsrc/main.pyのDeoxysGameクラスで管理して、ゲームを動かせています。
ちょっと興味深いのはsrc/game/constants.pyです。オリジナルの「たんじょうのしま」をなぞって地面マスに色を付けましたが、どのマスを薄緑色にするかはもちろんsrc/game/constants.pyの仕事です。最初は各マスをハードコーディングで記録していくのかと思いきや、for loopを使って楽に実装しているのが見られます：
# Special colored cells (light green #9DCCC1)
SPECIAL_CELLS = set()
# Add special cell ranges
# (0, 5)
SPECIAL_CELLS.add((0, 5))
# (1, 4) ~ (1, 6)
for col in range(4, 7):
SPECIAL_CELLS.add((1, col))
# (2, 3) ~ (2, 7)
for col in range(3, 8):
SPECIAL_CELLS.add((2, col))
# (3, 3) ~ (3, 7)
for col in range(3, 8):
SPECIAL_CELLS.add((3, col))
# (4, 2) ~ (4, 8)
for col in range(2, 9):
SPECIAL_CELLS.add((4, col))
# (5, 1) ~ (5, 9)
for col in range(1, 10):
SPECIAL_CELLS.add((5, col))
# (6, 1) ~ (6, 9)
for col in range(1, 10):
SPECIAL_CELLS.add((6, col))
# (7, 0) ~ (7, 10)
for col in range(0, 11):
SPECIAL_CELLS.add((7, col))
他にもsrc/utils/helpers.pyで使いまわす計算やメソッドを定義していて、メンテナンスしやすくしています。
感想
今回は自分はコードを一行も書かず、完全にAIまかせで簡単なゲームを実装することができました。今後どんどんとSEを付けて行ったり、グラフィックもオリジナルに寄せていけるだろうと信じています。
特に重要だと感じたのが、コンテキストの設定です。現状のLLMは明確に指示しないと本当に自由奔放に開発を進めていってしまうので、我々人間側がプロジェクトを管理するとなると、やはり明示的にGitを使わせたり、進行度を記録させておくようにしないと、プロジェクトが大きくなっていく毎に、いずれ人間が把握できないくらいになってしまいます。
しかしすべての人間がプロジェクト管理に詳しいわけではありません。ファイル構造だったり使うパッケージの詳細だったり、知らないことだらけだと思います。そこに関しては、AIに任せっきりにするよりも、今回のロードマップ作成のように、AIと会話を通して策を練っていくのが有効だと思いました。
Discussion