Amazon Q CLI と一緒に作る！AWS タワーディフェンスゲーム開発記

はじめに

Amazon Q CLI を触ってみたいなーと思っていたら、
Amazon Q CLI でゲームを作ろう Tシャツキャンペーン
が始まり、
JAWS-UG横浜 #85 Build Games with Amazon Q CLI
というイベントも開催してゲームを作ってみたが、出来に納得できず、作り直したという経緯です。

子どもたちがポノスさんの「にゃん〇大戦争」をやっているのをみて、子どもたちにもAWSサービスを覚えてもらおうと思い、にゃん〇大戦争的なAWSのゲームを作ってみたいと思いました。
その名も「AWSサービスのデプロイ！ずらっと防衛線！」

この記事では、Amazon Q CLIを使ったAIコーディング（Vibe Coding）の実際の体験をお伝えします。

🎮 完成したゲームの概要

ゲームコンセプト

テーマ: AWS Well-Architected Framework の6つの柱をベースにしたタワーディフェンス
プレイヤー: AWSサービスを配置して敵の攻撃から AWS 本社を守る
敵キャラ: レガシーシステムやセキュリティ脅威など、IT運用の課題を擬人化
戦略要素: サービス間の属性相性、コスト管理、クールダウンシステム

技術スタック

フロントエンド: HTML5 Canvas, JavaScript (ES6+), CSS3
開発環境: VS Code + Dev Container
AI アシスタント: Amazon Q Developer
** MCP Server **: Playwright
アセット: AWS 公式アイコンセット

🚀 開発プロセス

Phase 1: 企画・要件定義

最初は漠然とした「AWSでタワーディフェンス」というアイデアでした。
要件定義からタスク分割まで、会話で行います。

Amazon Q との対話:

私: 
ゲームを作りたい。要件定義から始めましょう。
「にゃん〇大戦争」みたいな感じでAWSのサービスを戦わせるタワーディフェンスゲームを作ります。
敵は他のクラウドベンダ・・・ではなく、人類共通の敵かつクラウドの敵っぽいものにしてください。
不明点があれば私に聞いてください。

Q: 
面白いアイデアですね！AWSサービスを使ったタワーディフェンスゲームの要件定義を一緒に考えましょう。

## ゲーム概要
「にゃん〇大戦争」スタイルのタワーディフェンスで、AWSサービスが味方ユニット、敵は人類共通の脅威という設定ですね。

## 要件定義のための質問

敵キャラクターについて：
• 「レガシーシステム」「技術的負債」「セキュリティ脅威」「ダウンタイム」「データ損失」などをモチーフにした敵はどうでしょうか？
• 敵の種類はどの程度用意したいですか？

AWSサービスユニットについて：
• EC2（基本攻撃）、Lambda（素早い攻撃）、S3（防御・回復）、CloudFront（範囲攻撃）などを想定していますが、どのサービスを優先的に含めたいです
か？
• 各サービスの特徴をゲーム内でどう表現したいですか？

ゲームの規模・技術について：
• ブラウザゲーム？モバイルアプリ？デスクトップアプリ？
• 開発期間や技術スタックの希望はありますか？
• マルチプレイヤー要素は必要ですか？

ゲームシステムについて：
• ステージ数やプログレッション要素はどの程度考えていますか？
• 課金要素やガチャ要素は入れますか？

どの部分から詳しく決めていきたいですか？

うん。いい質問です。
以下のように、早口で返します

私:
敵キャラクターについて、いい観点ですね。
この際、Well-Architected の6つの柱に沿った属性の敵を用意しましょう。
それぞれの属性ごとに2～3種類ぐらい敵を用意します。
AWSサービスユニットについて、これも敵の属性（Well-Architected）に沿って、
得意な敵を決めたキャラクターにしたいです。体力の回復はややこしくなるので不要です。
ゲームの規模・技術については、まずはブラウザで動かします。
フロントエンドはReact+TypescriptとViteでビルドするようにしてください。
まずはMVPをつくるので、バックエンドはなくてよいです。マルチプレイヤーはMVPでは不要です。
ゲームシステムについては、一旦1ステージ作ります。課金はなしで、
ガチャ要素を入れておきたいです。
また、コンセプトとしては、気軽にAWSサービスを出撃させられるようなものにしたいです。
1クリックできもかわいいAWSサービスたちが出撃します。
ゲーム性に細かいルールは設けたくないです。5歳でも遊べるようにしてください。

Q:
素晴らしい方向性ですね！Well-Architected Framework の6つの柱に基づいた敵と
AWSサービスの組み合わせは非常に教育的で面白いアイデアです。

## 要件定義

### 敵キャラクター（Well-Architected 6つの柱ベース）

1. Operational Excellence（運用の優秀性）
• レガシー運用モンスター：手動作業に依存する古い運用方法
• 監視盲点バグ：システムの見えない部分から攻撃
• 手動デプロイデーモン：人的ミスを誘発する

2. Security（セキュリティ）
• データ漏洩ウイルス：機密情報を狙う
• 不正アクセスハッカー：認証を突破しようとする
• 脆弱性エクスプロイト：セキュリティホールを突く

3. Reliability（信頼性）
• 単一障害点ボム：システム全体を止めようとする
• カスケード障害チェーン：連鎖的に障害を起こす
• 復旧不能クラッシャー：システムを完全に破壊する

4. Performance Efficiency（パフォーマンス効率）
• レスポンス遅延スライム：処理を遅くする
• リソース枯渇ドレイン：CPUやメモリを消費する
• ボトルネックブロッカー：処理の流れを止める

5. Cost Optimization（コスト最適化）
• 無駄遣いゴースト：不要なリソースを浪費させる
• 過剰プロビジョニングビースト：必要以上のリソースを要求
• 隠れコストトラップ：予期しない課金を発生させる

6. Sustainability（持続可能性）
• エネルギー浪費モンスター：電力を無駄に消費
• 炭素排出ドラゴン：環境負荷を増大させる
• 非効率リソースゾンビ：持続不可能な使い方をする

### AWSサービスユニット（属性特化）

各サービスが特定の属性の敵に対して効果的：

Operational Excellence特化
• CloudWatch（監視・ログ）
• Systems Manager（自動化）
• CloudFormation（IaC）

Security特化
• IAM（アクセス制御）
• GuardDuty（脅威検知）
• WAF（Web攻撃防御）

Reliability特化
• Auto Scaling（自動スケール）
• ELB（負荷分散）
• Route 53（DNS冗長化）

Performance特化
• CloudFront（CDN）
• ElastiCache（キャッシュ）
• Lambda（高速処理）

Cost特化
• Cost Explorer（コスト分析）
• Reserved Instances（コスト削減）
• Spot Instances（安価な計算）

Sustainability特化
• Graviton（省電力CPU）
• S3 Intelligent Tiering（効率的ストレージ）
• Fargate（効率的コンテナ）

### 技術仕様
• **フロントエンド**: React + TypeScript + Vite
• **プラットフォーム**: ブラウザ
• **バックエンド**: なし（MVP）
• **ステージ**: 1ステージ
• **ガチャ**: AWSサービス召喚システム
• **操作**: 1クリックで出撃（5歳でも遊べる簡単操作）

### ゲームフロー
1. ガチャでAWSサービスを入手
2. 敵の波が来る
3. 1クリックでサービスを出撃
4. 属性相性で戦闘が自動進行
5. 全ての敵を倒したらクリア

この方向性で進めてよろしいですか？何か調整したい点はありますか？

あんまり読んでないけど、これで作ろう。

私:
一旦これで行きましょう。
あとから見直せるようにドキュメントにしてください。
また、タスクに分割し、管理してください。

Q: 
ゲーム要件定義をドキュメント化し、タスクに分割して管理しますね。

# AWS Tower Defense Game - タスク管理
## プロジェクト構造
### Phase 1: プロジェクトセットアップ
- [ ] **TASK-001**: プロジェクト初期化
  - [ ] Vite + React + TypeScript プロジェクト作成
  - [ ] 基本的なフォルダ構造設定
  - [ ] ESLint, Prettier設定
  - [ ] Git設定
### Phase 2: ゲームデータ設計
- [ ] **TASK-002**: 敵キャラクターデータ定義
  - [ ] Well-Architected 6属性 × 3種類 = 18体の敵データ
  - [ ] 敵の基本ステータス（HP, 攻撃力, 速度, 属性）
  - [ ] 敵のビジュアル仕様
- [ ] **TASK-003**: AWSサービスユニットデータ定義
  - [ ] 18種類のAWSサービスデータ
  - [ ] サービスの基本ステータス（攻撃力, 攻撃速度, 射程, 特化属性）
  - [ ] サービスのビジュアル仕様
- [ ] **TASK-004**: 属性相性システム設計
  - [ ] 相性マトリックス定義
  - [ ] ダメージ計算ロジック
  - [ ] 効果的/非効果的な組み合わせ
### Phase 3: コアゲームシステム
- [ ] **TASK-005**: ゲーム状態管理
  - [ ] Redux Toolkit または Zustand でのステート管理
  - [ ] ゲーム進行状態（待機、戦闘中、終了）
  - [ ] プレイヤーリソース管理
- [ ] **TASK-006**: ガチャシステム
  - [ ] AWSサービス召喚ロジック
  - [ ] レアリティシステム
  - [ ] 所持サービス管理
- [ ] **TASK-007**: 戦闘システム
  - [ ] 敵の出現・移動ロジック
  - [ ] AWSサービスの攻撃ロジック
  - [ ] 衝突判定・ダメージ計算
  - [ ] 勝利/敗北判定
### Phase 4: UI/UXコンポーネント
- [ ] **TASK-008**: ゲーム画面レイアウト
  - [ ] メインゲーム画面
  - [ ] ガチャ画面
  - [ ] 結果画面
  - [ ] レスポンシブ対応
- [ ] **TASK-009**: ゲームフィールド
  - [ ] 敵の移動経路表示
  - [ ] AWSサービス配置エリア
  - [ ] 戦闘エフェクト表示
- [ ] **TASK-010**: インタラクション
  - [ ] 1クリック出撃システム
  - [ ] ドラッグ&ドロップ配置（オプション）
  - [ ] タッチデバイス対応
### Phase 5: ビジュアル・アセット
- [ ] **TASK-011**: キャラクターデザイン
  - [ ] AWSサービスのかわいいキャラクター化
  - [ ] 敵キャラクターのデザイン
  - [ ] アニメーション仕様
- [ ] **TASK-012**: UI素材
  - [ ] ボタン、アイコン類
  - [ ] 背景、エフェクト
  - [ ] フォント選定
### Phase 6: 音響・演出
- [ ] **TASK-013**: サウンド実装
  - [ ] BGM選定・実装
  - [ ] 効果音（攻撃、召喚、勝利など）
  - [ ] 音量調整機能
- [ ] **TASK-014**: エフェクト・アニメーション
  - [ ] 攻撃エフェクト
  - [ ] 召喚エフェクト
  - [ ] UI遷移アニメーション
### Phase 7: テスト・最適化
- [ ] **TASK-015**: ゲームバランス調整
  - [ ] 敵の強さ調整
  - [ ] AWSサービスの性能調整
  - [ ] ゲーム難易度調整
- [ ] **TASK-016**: パフォーマンス最適化
  - [ ] レンダリング最適化
  - [ ] メモリ使用量最適化
  - [ ] ロード時間短縮
- [ ] **TASK-017**: テスト
  - [ ] ユニットテスト
  - [ ] 統合テスト
  - [ ] ユーザビリティテスト（5歳児でも遊べるか）
### Phase 8: デプロイ・公開
- [ ] **TASK-018**: ビルド・デプロイ
  - [ ] 本番ビルド設定
  - [ ] 静的サイトホスティング（Vercel, Netlify等）
  - [ ] CI/CD設定
## 優先度付けタスク（MVP版）
### 高優先度（必須）
1. TASK-001: プロジェクトセットアップ
2. TASK-002: 敵キャラクターデータ定義
3. TASK-003: AWSサービスユニットデータ定義
4. TASK-005: ゲーム状態管理
5. TASK-007: 戦闘システム
6. TASK-008: ゲーム画面レイアウト
### 中優先度（重要）
7. TASK-006: ガチャシステム
8. TASK-009: ゲームフィールド
9. TASK-010: インタラクション
10. TASK-015: ゲームバランス調整
### 低優先度（あると良い）
11. TASK-011: キャラクターデザイン
12. TASK-013: サウンド実装
13. TASK-014: エフェクト・アニメーション
14. TASK-018: デプロイ
## 進捗管理
### 完了済み
- [x] 要件定義
- [x] タスク分割
### 進行中
- [ ] 現在作業中のタスクをここに記載
### 次のアクション
1. TASK-001から開始
2. 各タスク完了時にチェックマークを更新
3. 問題や変更があれば要件定義書を更新
## 見積もり時間（概算）
- **MVP版完成まで**: 40-60時間
- **フル機能版完成まで**: 80-120時間
## 注意事項
- 5歳でも遊べる簡単操作を常に意識
- Well-Architected Frameworkの教育効果を重視
- パフォーマンスよりもシンプルさを優先（MVP版）

Phase 2: 設計・基本システム実装

タスクをある程度作ったので、実装部分は、以下のようなプロンプトです。

私:
 とりあえず動く状態に持っていけるようにします。タスクを進めてください

バグがあるとき

バグに関するエラーがでたらエラーメッセージも含めて渡したりしています。

私:
サーバは起動しましたが、画面が真っ白です。
Playwrightで動かして確認してください。

ちなみに、Playwright のMCPは以下のようなコマンドでQ CLIに追加しています。

qchat mcp add --name playwright --command npx --args @playwright/mcp@latest

/mcpで認識されているか確認

Phase 3: ゲームバランス調整

この段階で最も多くの試行錯誤がありました。

最初の画面はこんな感じです。

ClaudWatch は、、、この見た目なら敵にしようかな。。。

そもそも動かないので、以下の指示を与えています。

私: 
画面が表示されています！出撃についてですが、
AWSサービスをクリックしたら出撃するようにしてください。
ゲームフィールド内をクリックしたくないです。
キャラクターは直線上に相手の城を目指して移動し、敵とぶつかったら戦うようなイメージです。

なんか動くようになった。

でも、敵を普通にすり抜けちゃう。。。しかも敵が攻撃してこない。。。

私: 
なんとなく動きました！敵が攻撃してこないのと、敵をすり抜けてしまうので、
すり抜けはないようにしてください。敵とぶつかったら（攻撃をするときは）止まってください。

Q:
了解しました！敵の攻撃システムと衝突判定を追加して、ぶつかったら止まるように修正します。

なんとなく動く。
この後、AWSサービスの出撃（デプロイ）にAWSクレジットを消費するシステムを導入したり、クールダウンを実装したり、敵陣と自陣にお城を置いてみたり、といったことをしてゲームを整えていきました。
これで、AWSサービスをデプロイ放題！！！

問題1: 敵が強すぎる

どう考えても勝てない。

私: 
ちょっと敵が強すぎました。出現頻度はそのままで弱くしてください

Q:
バランス調整ですね。HPを25-40%減少、攻撃力を24-30%減少させて、移動速度も調整しましょう

まだ勝てない。。。

問題2: 敵を倒したときにAWSクレジットがもらえるようにするのを忘れてた

私: 
敵を倒したときにAWSクレジットがもらえるようにしてください。
もらえる量は敵の強さに合わせて適切に設定してください。
Q: 
敵撃破時のクレジット報酬システムが完了しました！

やっと勝てました。
やっぱりクレジットが大事ですね。

📊 開発統計

開発期間: 3時間
総コード行数: 約1,500行
Amazon Q との対話回数: 約50回
実装した機能数: 15個以上
バランス調整回数: 8回

💡 まとめ

途中までしか作っていませんが、
Amazon Q Developer との協働でのゲーム開発は、想像以上に生産的でした。特に：

Amazon Q の強み

技術的な実装サポート: 具体的なコード例と説明
AWS 知識の活用: サービス特徴をゲームに反映
バランス調整: 数値調整の的確なアドバイス
24/7 対応: いつでも相談できる安心感

人間の役割

創造的なアイデア: ゲームコンセプトの発想
ユーザー体験: 楽しさの判断と調整
最終判断: 品質とバランスの最終決定
統合的視点: 全体システムの整合性確保

開発効率

従来なら1週間ぐらいかかりそうな開発を3時間で完成しました。AIとの協働により、開発速度が約10-20 倍向上したと感じています。